Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing 华为技术有限公司
华为北研所 北京 100095 中国 c.l@huawei.com
RtBrick Inc
Bangalore Karnataka India prejeeth@rtbrick.com
Ciena Corporation
msiva282@gmail.com
Ciena Corporation
Canada mkoldych@ciena.com
China Telecom
109 West Zhongshan Ave, Tianhe District Bangalore Guangzhou China zhuyq8@chinatelecom.cn
RTG pce PCEP SRv6 IPv6 Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. An SR Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since SR can be applied to both MPLS and IPv6 data planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data planes. The Path Computation Element Communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data plane within PCEP.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
    • .  Requirements Language
  • .  Terminology
  • .  Overview of PCEP Operation in SRv6 Networks
    • .  Operation Overview
    • .  SRv6-Specific PCEP Message Extensions
  • .  Object Formats
    • .  The OPEN Object
      • .  The SRv6 PCE Capability sub-TLV
    • .  The RP/SRP Object
    • .  ERO
      • .  SRv6-ERO Subobject
        • .  SID Structure
        • .  Order of the Optional Fields
    • .  RRO
      • .  SRv6-RRO Subobject
  • .  Procedures
    • .  Exchanging the SRv6 Capability
    • .  ERO Processing
      • .  SRv6 ERO Validation
      • .  Interpreting the SRv6-ERO
    • .  RRO Processing
  • .  Security Considerations
  • .  Manageability Considerations
    • .  Control of Function and Policy
    • .  Information and Data Models
    • .  Liveness Detection and Monitoring
    • .  Verify Correct Operations
    • .  Requirements on Other Protocols
    • .  Impact on Network Operations
  • .  IANA Considerations
    • .  PCEP ERO and RRO Subobjects
    • .  New SRv6-ERO NAI Type Registry
    • .  New SRv6-ERO Flag Registry
    • .  LSP-ERROR-CODE TLV
    • .  PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
    • .  SRv6 PCE Capability Flags
    • .  New Path Setup Type
    • .  ERROR Objects
  • .  References
    • .  Normative References
    • .  Informative References
  • Acknowledgements
  • Contributors
  • Authors' Addresses
Introduction As defined in , Segment Routing (SR) architecture allows the source node to steer a packet through a path indicated by an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based, and it can have a semantic local to an SR node or global within an SR domain. describes Path Computation Element Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a PCE or between a pair of PCEs. A PCE or a PCC operating as a PCE (in a hierarchical PCE environment) computes paths for MPLS Traffic Engineering Label Switched Paths (MPLS-TE LSPs) based on various constraints and optimization criteria. specifies extensions to PCEP that allow a stateful PCE to compute and recommend network paths in compliance with and defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide synchronization of LSP state between a PCC and a PCE or between a pair of PCEs, delegation of LSP control, reporting of LSP state from a PCC to a PCE, and controlling the setup and path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions are intended for an operational model in which LSPs are configured on the PCC, and control over them is delegated to the PCE. A mechanism to dynamically initiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE is specified in . As per , it is possible to use a stateful PCE for computing one or more SR-TE paths taking into account various constraints and objective functions. Once a path is computed, the stateful PCE can initiate an SR-TE path on a PCC using PCEP extensions specified in and the SR-specific PCEP extensions specified in . specifies PCEP extensions for supporting an SR-TE LSP for the MPLS data plane. This document extends to support SR for the IPv6 data plane. Additionally, using procedures described in this document, a PCC can request an SRv6 path from either a stateful or stateless PCE. This specification relies on the PATH-SETUP-TYPE TLV and procedures specified in . This specification provides a mechanism for a network controller (acting as a PCE) to instantiate candidate paths for an SR Policy onto a head-end node (acting as a PCC) using PCEP. For more information on the SR Policy architecture, see , which applies to both SR-MPLS and SRv6.
Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Terminology This document uses the following terms defined in : PCC, PCE, PCEP, PCEP Peer. This document uses the following terms defined in : Stateful PCE, Delegation. Further, the following terms are used in the document:
MSD:
Maximum SID Depth
PST:
Path Setup Type
SR:
Segment Routing
SID:
Segment Identifier
SRv6:
Segment Routing over IPv6 data plane
SRH:
IPv6 Segment Routing Header
SRv6 path:
IPv6 Segment List (A list of IPv6 SIDs representing a path in IPv6 SR domain in the context of this document.)
Further, note that the term "LSP" used in the PCEP specifications would be equivalent to an SRv6 path (represented as a list of SRv6 segments) in the context of supporting SRv6 in PCEP.
Overview of PCEP Operation in SRv6 Networks Basic operations for PCEP speakers are built on . In PCEP messages, route information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects. defined a new ERO subobject denoted by "SR-ERO subobject" that is capable of carrying a SID as well as the identity of the node/adjacency represented by the SID for SR-MPLS. SR-capable PCEP speakers can generate and/or process such an ERO subobject. An ERO containing SR-ERO subobjects can be included in the PCEP Path Computation Reply (PCRep) message defined in , the PCEP LSP Initiate Request message (PCInitiate) defined in , as well as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in . also defines a new Reported Route Object (RRO), called "SR-RRO", to represent the SID list that was applied by the PCC, which is the actual path taken by the LSP in SR-MPLS network. The SRv6 paths computed by a PCE can be represented as an ordered list of SRv6 segments. This document defines new subobjects "SRv6-ERO" and "SRv6-RRO" in the ERO and the RRO, respectively, to carry the SRv6 SID. SRv6-capable PCEP speakers MUST be able to generate and/or process these subobjects. When a PCEP session between a PCC and a PCE is established, both PCEP speakers exchange their capabilities to indicate their ability to support SRv6-specific functionality as described in . In summary, this document defines:
  • a new PCEP capability for SRv6,
  • a new subobject SRv6-ERO in ERO,
  • a new subobject SRv6-RRO in RRO, and
  • a new Path Setup type (PST) , carried in the PATH-SETUP-TYPE and PATH-SETUP-TYPE-CAPABILITY TLVs.
Operation Overview In SR networks, an SR source node steers a packet into an SR Policy resulting in a segment list. When SR leverages the IPv6 data plane (i.e., SRv6), the PCEP procedures and mechanisms are extended in this document. This document describes the extension to support SRv6 in PCEP. A PCC or PCE indicates its ability to support SRv6 during the PCEP session initialization phase via a new SRv6-PCE-CAPABILITY sub-TLV (see details in ).
SRv6-Specific PCEP Message Extensions As defined in , a PCEP message consists of a common header followed by a variable-length body made up of mandatory and/or optional objects. This document does not require any changes in the format of PCReq and PCRep messages specified in , the PCInitiate message specified in , or PCRpt and PCUpd messages specified in . However, PCEP messages pertaining to SRv6 MUST include PATH-SETUP-TYPE TLV in the Request Parameters (RP) or Stateful PCE Request Parameters (SRP) object to clearly identify that SRv6 is intended.
Object Formats
The OPEN Object
The SRv6 PCE Capability sub-TLV This document defines a new Path Setup Type (PST) for SRv6, as follows:
PST=3:
Path is set up using SRv6.
A PCEP speaker indicates its support of the function described in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this new PST (value 3) included in the PST list. This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP speakers use this sub-TLV to exchange information about their SRv6 capability. If a PCEP speaker includes PST=3 in the PST list of the PATH-SETUP-TYPE-CAPABILITY TLV, then it MUST also include the SRv6-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. For further error handling, please see . The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in .
SRv6-PCE-CAPABILITY Sub-TLV Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=27 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | MSD-Type | MSD-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // ... // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is 27, and the format is compliant with the PCEP TLV format defined in . That is, the sub-TLV is composed of 2 octets for the type, 2 octets specifying the length, and a Value field. When set to 27, the Type field identifies the SRv6-PCE-CAPABILITY sub-TLV, and the presence of the sub-TLV indicates the support for the SRv6 paths in PCEP. The Length field defines the length of the value portion in octets. The sub-TLV is padded to 4-octet alignment, and padding is not included in the Length field. The (MSD-Type,MSD-Value) pairs are OPTIONAL. The number of (MSD-Type,MSD-Value) pairs can be determined by the Length field of the TLV. The value is comprised of:
  • Reserved: 2 octets; this field MUST be set to 0 on transmission and ignored on receipt.
  • Flags: 2 octets; one bit is currently assigned in
    • N bit (bit position 14): A PCC sets this flag bit to 1 to indicate that it is capable of resolving a Node or Adjacency Identifier (NAI) to an SRv6-SID.
    • Unassigned bits MUST be set to 0 on transmission and ignored on receipt
  • A pair of (MSD-Type,MSD-Value): Where MSD-Type (1 octet) is as per the IGP MSD Type registry created by and populated with SRv6 MSD types as per , and where MSD-Value (1 octet) is as per .
The SRv6 MSD information advertised via SRv6-PCE-Capability sub-TLV conveys the SRv6 capabilities of the PCEP speaker alone. However, when it comes to the computation of an SR Policy for the SRv6 data plane, the SRv6 MSD capabilities of the intermediate SRv6 Endpoint node and the tail-end node also need to be considered to ensure those midpoints are able to correctly process their segments and for the tail-end to dispose of the SRv6 encapsulation. The SRv6 MSD capabilities of other nodes might be learned as part of the topology information via the Border Gateway Protocol - Link State (BGP-LS) or via PCEP if the PCE also happens to have PCEP sessions with those nodes. It is recommended that the SRv6 MSD information not be included in the SRv6-PCE-Capability sub-TLV in deployments where the PCE is able to obtain this via IGP/BGP-LS as part of the topology information.
The RP/SRP Object This document defines a new Path Setup Type (PST=3) for SRv6. In order to indicate that the path is for SRv6, any RP or SRP object MUST include the PATH-SETUP-TYPE TLV as specified in , where PST is set to 3.
ERO In order to support SRv6, a new "SRv6-ERO" subobject is defined for inclusion in the ERO.
SRv6-ERO Subobject An SRv6-ERO subobject is formatted as shown in .
SRv6-ERO Subobject Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=40 | Length | NT | Flags |V|T|F|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 SID (conditional) | | (128-bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NAI (variable, conditional) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SID Structure (conditional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the SRv6-ERO subobject are as follows:
  • The "L" flag: Indicates whether the subobject represents a loose hop (see ). If this flag is set to zero, a PCC MUST NOT overwrite the SID value present in the SRv6-ERO subobject. Otherwise, a PCC MAY expand or replace one or more SID values in the received SRv6-ERO based on its local policy.
  • Type: Indicates the content of the subobject, i.e., when the field is set to 40, the subobject is an SRv6-ERO subobject representing an SRv6 SID.
  • Length: Contains the total length of the subobject in octets. The Length MUST be at least 24 and MUST be a multiple of 4. An SRv6-ERO subobject MUST contain at least one of an SRv6-SID or an NAI. The S and F bits in the Flags field indicates whether the SRv6-SID or NAI fields are absent.
  • NAI Type (NT): Indicates the type and format of the NAI contained in the object body, if any are present. If the F bit is set to one (see below), then the NT field has no meaning and MUST be ignored by the receiver. This document creates a new PCEP SRv6-ERO NAI Types registry in and allocates the following values:
    • If NT value is 0, the NAI MUST NOT be included.
    • When NT value is 2, the NAI is as per the "IPv6 node ID" format defined in , which specifies an IPv6 address. This is used to identify the owner of the SRv6 Identifier. This is optional, as the LOC (the locator portion) of the SRv6 SID serves a similar purpose (when present).
    • When NT value is 4, the NAI is as per the "IPv6 adjacency" format defined in , which specify a pair of IPv6 addresses. This is used to identify the IPv6 adjacency and used with the SRv6 Adj-SID.
    • When NT value is 6, the NAI is as per the "link-local IPv6 addresses" format defined in , which specify a pair of (global IPv6 address, interface ID) tuples. It is used to identify the IPv6 adjacency and used with the SRv6 Adj-SID.
  • Flags: Used to carry additional information pertaining to the SRv6-SID. This document defines the following flag bits. The other bits MUST be set to zero by the sender and MUST be ignored by the receiver. This document creates a new registry SRv6-ERO Flag Field registry in and allocates the following values.
    • S: When this bit is set to 1, the SRv6-SID value in the subobject body is absent. In this case, the PCC is responsible for choosing the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI that, in this case, MUST be present in the subobject. If the S bit is set to 1, then the F bit MUST be set to zero.
    • F: When this bit is set to 1, the NAI value in the subobject body is absent. The F bit MUST be set to 1 if NT=0; otherwise, it MUST be set to zero. The S and F bits MUST NOT both be set to 1.
    • T: When this bit is set to 1, the SID Structure value in the subobject body is present. The T bit MUST be set to 0 when the S bit is set to 1. If the T bit is set when the S bit is set, the T bit MUST be ignored. Thus, the T bit indicates the presence of an optional 8-byte SID Structure when SRv6 SID is included. The SID Structure is defined in .
    • V: The "SID verification" bit usage is as per . If a PCC "Verification fails" for a SID, it MUST report this error by including the LSP-ERROR-CODE TLV with LSP Error-value "SID Verification fails" in the LSP object in the PCRpt message to the PCE.
  • Reserved: MUST be set to zero while sending and ignored on receipt.
  • Endpoint Behavior: A 16-bit field representing the behavior associated with the SRv6 SIDs. This information is optional, but providing it is recommended whenever possible. It could be used for maintainability and diagnostic purposes. If behavior is not known, value "0xFFFF" as defined in the "SRv6 Endpoint Behaviors" registry is used .
  • SRv6 SID: SRv6 Identifier is a 128-bit value representing the SRv6 segment.
  • NAI: The NAI associated with the SRv6-SID. The NAI's format depends on the value in the NT field and is described in .
At least one SRv6-SID or the NAI MUST be included in the SRv6-ERO subobject, and both MAY be included.
SID Structure The SID Structure is an optional part of the SR-ERO subobject, as described in . defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). A locator may be represented as B:N where B is the SRv6 SID locator block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the identifier of the parent node instantiating the SID called "locator node". The SID Structure is formatted as shown in .
SID Structure Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LB Length | LN Length | Fun. Length | Arg. Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
  • LB Length: 1 octet; SRv6 SID Locator Block length in bits
  • LN Length: 1 octet; SRv6 SID Locator Node length in bits
  • Fun. Length: 1 octet; SRv6 SID Function length in bits
  • Arg. Length: 1 octet; SRv6 SID Arguments length in bits
The sum of all four sizes in the SID Structure must be less than or equal to 128 bits. If the sum of all four sizes advertised in the SID Structure is larger than 128 bits, the corresponding SRv6 SID MUST be considered invalid and a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 37 ("Invalid SRv6 SID Structure") is returned.
  • Reserved: MUST be set to zero while sending and ignored on receipt.
  • Flags: Currently no flags are defined.
  • Unassigned bits must be set to zero while sending and ignored on receipt.
The SRv6 SID Structure provides the detailed encoding information of an SRv6 SID, which is helpful in the use cases that require the SRv6 SID structure to be known. When a PCEP speaker receives the SRv6 SID and its structure information, the SRv6 SID can be parsed based on the SRv6 SID Structure and/or possible local policies. The SRv6 SID Structure could be used by the PCE for ease of operations and monitoring. For example, this information could be used for validation of SRv6 SIDs being instantiated in the network and checked for conformance with the SRv6 SID allocation scheme chosen by the operator as described in . In the future, PCE might also be utilized to verify and automate the security of the SRv6 domain by provisioning filtering rules at the domain boundaries as described in . The details of these potential applications are outside the scope of this document.
Order of the Optional Fields The optional elements in the SRv6-ERO subobject, i.e., SRv6 SID, NAI, and the SID Structure, MUST be encoded in the order as depicted in . The presence or absence of each of them is indicated by the respective flags, i.e., S flag, F flag, and T flag. In order to ensure future compatibility, any optional elements added to the SRv6-ERO subobject in the future must specify their order and request that the Internet Assigned Numbers Authority (IANA) allocate a flag to indicate their presence from the subregistry created in .
RRO In order to support SRv6, a new "SRv6-RRO" subobject is defined for inclusion in the RRO.
SRv6-RRO Subobject A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per . The RRO on this message represents the SID list that was applied by the PCC, that is, the actual path taken. The procedures of with respect to the RRO apply equally to this specification without change. An RRO contains one or more subobjects called "SRv6-RRO subobjects", whose format is shown in .
SRv6-RRO Subobject Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=40 | Length | NT | Flags |V|T|F|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 SID(optional) | | (128-bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NAI (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SID Structure (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the SRv6-RRO subobject is the same as that of the SRv6-ERO subobject but without the L flag. The V flag has no meaning in the SRv6-RRO and is ignored on receipt at the PCE. The ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as per . The ordering of optional elements in the SRv6-RRO subobject is the same as described in .
Procedures
Exchanging the SRv6 Capability A PCC indicates that it is capable of supporting the head-end functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCE. A PCE indicates that it is capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCC. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=3, but the SRv6-PCE-CAPABILITY sub-TLV is absent, then the PCEP speaker MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 34 ("Missing PCE-SRv6-CAPABILITY sub-TLV") and MUST then close the PCEP session. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with an SRv6-PCE-CAPABILITY sub-TLV, but the PST list does not contain PST=3, then the PCEP speaker MUST ignore the SRv6-PCE-CAPABILITY sub-TLV. In case the MSD-Type in the SRv6-PCE-CAPABILITY sub-TLV received by the PCE does not correspond to one of the SRv6 MSD types, the PCE MUST respond with a PCErr message (Error-Type = 1 ("PCEP session establishment failure") and Error-Value = 1 ("reception of an invalid Open message or a non Open message.")). Note that the (MSD-Type,MSD-Value) pair exchanged via the SRv6-PCE-CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the sender PCC node only. However, if a PCE learns these via alternate mechanisms, e.g., routing protocols , then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE learns any other SRv6 MSD types that may be defined in the future via alternate mechanisms, it MUST use those values regardless of the values exchanged in the SRv6-PCE-CAPABILITY sub-TLV. During path computation, a PCE must consider the MSD information of all the nodes along the path instead of only the MSD information of the ingress PCC since a packet may be dropped on any node in a forwarding path because of the SID depth exceeding the MSD of the node. The MSD capabilities of all SR nodes along the path can be learned as part of the topology information via IGP/BGP-LS or via PCEP if the PCE also happens to have PCEP sessions with those nodes. A PCE MUST NOT send SRv6 paths that exceed the SRv6 MSD capabilities of the PCC. If a PCC needs to modify the SRv6 MSD value signaled via the Open message, it MUST close the PCEP session and re-establish it with the new value. If the PCC receives an SRv6 path that exceeds its SRv6 MSD capabilities, the PCC MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 40 ("Unsupported number of SRv6-ERO subobjects"). The N flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE-CAPABILITY sub-TLV are meaningful only in the Open message sent to a PCE. As such, the flags MUST be set to zero and a (MSD-Type,MSD-Value) pair MUST NOT be present in the SRv6-PCE-CAPABILITY sub-TLV in an Open message sent to a PCC. Similarly, a PCC MUST ignore flags and any (MSD-Type,MSD-Value) pair in a received Open message. If a PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the first sub-TLV received.
ERO Processing The processing of ERO remains unchanged in accordance with both and .
SRv6 ERO Validation If a PCC does not support the SRv6 PCE Capability and thus cannot recognize the SRv6-ERO or SRv6-RRO subobjects, it should respond according to the rules for a malformed object as described in . On receiving an SRv6-ERO, a PCC MUST validate that the Length field, the S bit, the F bit, the T bit, and the NT field are consistent, as follows:
  • If NT=0, the F bit MUST be 1, the S bit MUST be zero, and the Length MUST be 24.
  • If NT=2, the F bit MUST be zero. If the S bit is 1, the Length MUST be 24; otherwise, the Length MUST be 40.
  • If NT=4, the F bit MUST be zero. If the S bit is 1, the Length MUST be 40; otherwise, the Length MUST be 56.
  • If NT=6, the F bit MUST be zero. If the S bit is 1, the Length MUST be 48; otherwise, the Length MUST be 64.
  • If the T bit is 1, then the S bit MUST be zero.
If a PCC finds that the NT field, Length field, S bit, F bit, and T bit are not consistent, it MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object"). If a PCC does not recognize or support the value in the NT field, it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 41 ("Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject"). If a PCC receives an SRv6-ERO subobject in which the S and F bits are both set to 1 (that is, both the SID and NAI are absent), it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 42 ("Both SID and NAI are absent in the SRv6-ERO subobject"). If a PCC receives an SRv6-ERO subobject in which the S bit is set to 1 and the F bit is set to zero (that is, the SID is absent and the NAI is present), but the PCC does not support NAI resolution, it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 4 ("Not supported object") and Error-value = 4 ("Unsupported parameter"). If a PCC detects that the subobjects of an ERO are a mixture of SRv6-ERO subobjects and subobjects of other types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 43 ("ERO mixes SRv6-ERO subobjects with other subobject types"). In case a PCEP speaker receives an SRv6-ERO subobject, when the PST is not set to 3 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged, it MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-value = 19 ("Attempted SRv6 when the capability was not advertised"). If a PCC receives an SRv6 path that exceeds the SRv6 MSD capabilities, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 40 ("Unsupported number of SRv6-ERO subobjects") as per .
Interpreting the SRv6-ERO The SRv6-ERO contains a sequence of subobjects. According to , each SRv6-ERO subobject in the sequence identifies a segment that the traffic will be directed to, in the order given. That is, the first subobject identifies the first segment the traffic will be directed to, the second SRv6-ERO subobject represents the second segment, and so on.
RRO Processing The syntax-checking rules that apply to the SRv6-RRO subobject are identical to those of the SRv6-ERO subobject, except as noted below. If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 SID and NAI are absent, it MUST consider the entire RRO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 35 ("Both SID and NAI are absent in SRv6-RRO subobject"). If a PCE detects that the subobjects of an RRO are a mixture of SRv6-RRO subobjects and subobjects of other types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 36 ("RRO mixes SRv6-RRO subobjects with other subobject types"). The mechanism by which the PCC learns the path is outside the scope of this document.
Security Considerations The Security Considerations described in , , , , , and are applicable to this specification. Note that this specification enables a network controller to instantiate an SRv6 path in the network. This creates an additional vulnerability if the security mechanisms of , , and are not used. If there is no integrity protection on the session, then an attacker could create an SRv6 path that may not be subjected to the further verification checks. Further, the MSD field in the Open message could disclose node forwarding capabilities if suitable security mechanisms are not in place. Hence, securing the PCEP session using Transport Layer Security (TLS) is RECOMMENDED.
Manageability Considerations All manageability requirements and considerations listed in , , , and apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.
Control of Function and Policy A PCEP implementation SHOULD allow the operator to configure the SRv6 capability. Further, a policy to accept NAI only for the SRv6 SHOULD be allowed to be set.
Information and Data Models The PCEP YANG module is out of the scope of this document; it is defined in other documents, for example, . An augmented YANG module for SRv6 is also specified in that allows for SRv6 capability and MSD configurations as well as to monitor the SRv6 paths set in the network.
Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in .
Verify Correct Operations Verification of the mechanisms defined in this document can be built on those already listed in , , and .
Requirements on Other Protocols Mechanisms defined in this document do not imply any new requirements on other protocols.
Impact on Network Operations Mechanisms defined in , , and also apply to PCEP extensions defined in this document.
IANA Considerations
PCEP ERO and RRO Subobjects This document defines a new subobject type for the PCEP Explicit Route Object (ERO) and a new subobject type for the PCEP Reported Route Object (RRO). These have been registered in the "Resource Reservation Protocol (RSVP) Parameters" registry group as shown below. IANA has allocated the following new subobject in the "Subobject type - 20 EXPLICIT_ROUTE - Type 1 Explicit Route" registry:
Value Description
40 SRv6-ERO (PCEP-specific)
IANA has allocated the following new subobject in the "Subobject type - 21 ROUTE_RECORD - Type 1 Route Record" registry:
Value Description
40 SRv6-RRO (PCEP-specific)
New SRv6-ERO NAI Type Registry IANA has created the "PCEP SRv6-ERO NAI Types" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the 4-bit NT field in the SRv6-ERO subobject. The registration policy is IETF Review . IANA has registered the values in .
Value Description Reference
0 NAI is absent. RFC 9603
2 NAI is an IPv6 node ID. RFC 9603
4 NAI is an IPv6 adjacency with global IPv6 addresses. RFC 9603
6 NAI is an IPv6 adjacency with link-local IPv6 addresses. RFC 9603
New SRv6-ERO Flag Registry IANA has created the "SRv6-ERO Flag Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the 12-bit Flag field of the SRv6-ERO subobject. New values are to be assigned by Standards Action . Each registration should include the following information:
  • Bit (counting from bit 0 as the most significant bit)
  • Description
  • Reference
The following values are defined in this document:
Bit Description Reference
8 SID Verification (V) RFC 9603
9 SID Structure is present (T) RFC 9603
10 NAI is absent (F) RFC 9603
11 SID is absent (S) RFC 9603
LSP-ERROR-CODE TLV This document defines a new value in "LSP-ERROR-CODE TLV Error Code Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group.
Value Meaning Reference
10 SID Verification fails RFC 9603
PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators IANA maintains the "PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the type indicator space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA has registered the following value:
Value Meaning Reference
27 SRv6-PCE-CAPABILITY RFC 9603
SRv6 PCE Capability Flags IANA has created the "SRv6 Capability Flag Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the 16-bit Flag field of the SRv6-PCE-CAPABILITY sub-TLV. New values are to be assigned by Standards Action . Each registration should include the following information:
  • Bit (counting from bit 0 as the most significant bit)
  • Description
  • Reference
The following value is defined in this document.
Bit Description Reference
14 Node or Adjacency Identifier (NAI) is supported (N) RFC 9603
New Path Setup Type created the "PCEP Path Setup Types" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA has allocated the following value:
Value Description Reference
3 Traffic engineering path is set up using SRv6. RFC 9603
ERROR Objects IANA has allocated the following Error-values in the "PCEP-ERROR Object Error Types and Values" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group:
Error-Type Meaning Error-value
10 Reception of an invalid object 34: Missing PCE-SRv6-CAPABILITY sub-TLV
35: Both SID and NAI are absent in SRv6-RRO subobject
36: RRO mixes SRv6-RRO subobjects with other subobject types
37: Invalid SRv6 SID Structure
40: Unsupported number of SRv6-ERO subobjects
41: Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject
42: Both SID and NAI are absent in the SRv6-ERO subobject
43: ERO mixes SRv6-ERO subobjects with other subobject types
19 Invalid Operation 19: Attempted SRv6 when the capability was not advertised
References Normative References RSVP-TE: Extensions to RSVP for LSP Tunnels This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] Path Computation Element (PCE) Communication Protocol (PCEP) This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session. Signaling Maximum SID Depth (MSD) Using IS-IS This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled. PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP. This document updates RFC 5440 in regards to the PCEP initialization phase procedures. Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408. Segment Routing over IPv6 (SRv6) Network Programming The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments". These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3. This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Path Computation Element (PCE) Communication Protocol Generic Requirements The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community. Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518. Applicability of a Stateful Path Computation Element (PCE) A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents. Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. IPv6 Segment Routing Header (SRH) Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. Segment Routing Policy Architecture Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. A YANG Data Model for Path Computation Element Communications Protocol (PCEP) Huawei Juniper Networks Microsoft Nvidia Work in Progress A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP) Huawei Technologies Ciena Corporation Huawei Technologies Cisco Systems, Inc. MTN Cameroon This document augments a YANG data model for the management of Path Computation Element Communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6 (SRv6) and SR Policy. The data model includes configuration data and state data (status information and counters for the collection of statistics). Work in Progress
Acknowledgements The authors would like to thank , , , , , , , , , , and for valuable suggestions. Thanks to , , , and for their comments during the IESG review.
Contributors RtBrick Inc
Bangalore Karnataka India mahend.ietf@gmail.com
Huawei
India dhruv.ietf@gmail.com
Huawei Technologies
Huawei Building, No. 156 Beiqing Rd. Beijing 100095 China huangwumin@huawei.com
Huawei Technologies
Huawei Building, No. 156 Beiqing Rd. Beijing 100095 China pengshuping@huawei.com
ZTE Corporation
China chen.ran@zte.com.cn
Authors' Addresses 华为技术有限公司
华为北研所 北京 100095 中国 c.l@huawei.com
RtBrick Inc
Bangalore Karnataka India prejeeth@rtbrick.com
Ciena Corporation
msiva282@gmail.com
Ciena Corporation
Canada mkoldych@ciena.com
China Telecom
109 West Zhongshan Ave, Tianhe District Bangalore Guangzhou China zhuyq8@chinatelecom.cn