]> Ciena Corporation

mkoldych@ciena.com

Cisco Systems.

ssidor@cisco.com

Routing PCE Working Group This document defines Path Computation Element Communication Protocol (PCEP) extensions to signal multipath information, associating multiple forwarding paths with a single PCEP Label Switched Path (LSP) to allow load-balancing and redundancy across diverse paths. The extensions are generic and applicable to both stateless and stateful PCEP, and are designed to be reusable for future path types. Their primary application is Segment Routing (SR) Policy, where a Candidate Path can contain multiple Segment Lists: current PCEP extensions for SR Policy only allow signaling of a single Segment List per Candidate Path. These extensions enable multipath capabilities such as weighted or equal-cost load-balancing across paths.

Introduction Segment Routing Policy for Traffic Engineering details the concepts of Segment Routing (SR) Policy and approaches to steering traffic into an SR Policy. In particular, it describes the SR Candidate Path as a collection of one or more Segment Lists. The current PCEP specifications only allow for signaling of one Segment List per Candidate Path. The PCEP extension to support Segment Routing Policy Candidate Paths specifically kept the signaling of multiple Segment Lists outside its scope. This document defines the required extensions that allow the signaling of multipath information via PCEP. Although these extensions are motivated by the SR Policy use case, they are also applicable to other technologies. For SR Policy, support for is a prerequisite for using the multipath extensions defined in this document with SR Policy Candidate Paths.

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 The following terms are used in this document: ECMP:

• Equal-Cost Multipath, equally distributing traffic among multiple paths/links, where each path/link gets the same share of traffic as others.

W-ECMP:

• Weighted Equal-Cost Multipath, unequally distributing traffic among multiple paths/links, where some paths/links get more traffic than others.

PLSP:

• PCE Label Switched Path, a path or set of paths computed or controlled by the PCE. In the context of SR Policy, a PLSP corresponds to a Candidate Path.

Segment List:

• An ordered list of segments that defines a forwarding path in Segment Routing, as defined in . In PCEP for SR Policy, each Segment List is encoded as an ERO or RRO.

ERO:

• Explicit Route Object, defined in , encodes an explicit path. In the context of SR Policy, an ERO encodes a Segment List.

RRO:

• Record Route Object, defined in , encodes the actual signaled path. In the context of SR Policy, an RRO reports a Segment List.

Path:

• In the context of this document, a path refers to a single forwarding path encoded in an ERO or RRO. For SR Policy, a path corresponds to a Segment List. The mechanisms defined in this document use the generic term "path" to allow applicability beyond SR Policy.

LSP:

• Label Switched Path. The base PCEP specification originally defined the use of the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol . Over time, support for additional path setup types such as SRv6 has been introduced . The term "LSP" is used extensively in PCEP specifications and, while the multipath extensions defined in this document are applicable beyond SR Policy, in the context of PCEP for SR Policy , an LSP object represents an SR Policy Candidate Path, which may be an SRv6 path (still represented using the LSP object as specified in ). A single LSP may contain multiple paths (Segment Lists).

SR Policy:

• A Segment Routing Policy as defined in , identified by the tuple (headend, color, endpoint).

Motivation This extension is motivated by the use-cases described below.

Signaling Multiple Segment Lists of an SR Candidate Path The Candidate Path of an SR Policy is the unit of signaling in PCEP . A single Candidate Path can consist of multiple Segment Lists. Each Segment List is represented by an Explicit Route Object (ERO). In existing PCEP specifications, a PCEP Label Switched Path (LSP) object is associated with exactly one ERO. This restriction prevents the encoding of multiple Segment Lists (i.e., multiple EROs) within the single LSP.

Splitting of Requested Bandwidth For example, a Path Computation Client (PCC) may request a path whose bandwidth demand cannot be accommodated on any single link along an available path in the network. The Path Computation Element (PCE) can return multiple paths that together can carry the requested bandwidth. The PCC can then equally or unequally split the incoming traffic among these paths.

Reverse Path Information Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional LSPs defines a mechanism in PCEP to associate two opposite direction SR Policy Candidate Paths. However, within each Candidate Path there can be multiple Segment Lists, and does not define a mechanism to specify mapping between Segment Lists of the forward and reverse Candidate Paths. Certain applications such as Circuit Style SR Policy , require the knowledge of reverse paths per Segment List, not just per Candidate Path. For example, when the headend knows the reverse Segment List for each forward Segment List, then Performance Measurement (PM)/Bidirectional Forwarding Detection (BFD) can run a separate session on every Segment List, by imposing a double stack (forward stack followed by reverse stack) onto the packet. If the reverse Segment List is co-routed with the forward Segment List, then the PM/BFD session would traverse the same links in the forward and reverse directions, thus allowing detection of link/node failures in both directions.

Protocol Extensions

PATH-ATTRIB Object This document defines the PATH-ATTRIB object that is used to carry per-path information and to act as a separator between EROs/RROs in the <intended-path>/<actual-path> Routing Backus-Naur Form (RBNF) element. The PATH-ATTRIB object always precedes the ERO or RRO that it applies to. If multiple EROs or RROs are present, then each ERO or RRO MUST be preceded by a PATH-ATTRIB object that describes it. The PATH-ATTRIB Object-Class value is 45. The PATH-ATTRIB Object-Type value is 1. The format of the PATH-ATTRIB object is shown in .

PATH-ATTRIB object format

Flags (32 bits):

• O (Operational - 3 bits): operational state of the path, same values as the identically named field in the LSP object . The relationship between the per-path Operational state and the LSP-level Operational state in the LSP object is outside the scope of this document; for SR Policy, the Candidate Path validity criterion is defined in Section 2.8 of .
• R (Reverse - 1 bit): Indicates this path is reverse, i.e., it originates on the LSP destination and terminates on the LSP source (usually the PCC headend itself). Paths with this flag set are not installed in forwarding for load-balancing purposes, but MAY be used by the PCC for operations such as Performance Measurement (PM) or Bidirectional Forwarding Detection (BFD).
• Unassigned bits MUST be set to 0 on transmission and MUST be ignored on receipt.

Path ID (32 bits): 4-octet identifier that identifies a path (encoded in the ERO/RRO) within the set of multiple paths under the PCEP LSP. See for details. Optional TLVs: Variable length field that can contain zero or more Type-Length-Value (TLV) elements that carry additional per-path information. The specific TLVs that can be included are defined in subsequent sections of this document.

METRIC Object The PCEP METRIC object can continue to be used at the LSP level to describe properties of the overall LSP. Mechanisms for encoding per-path metrics (e.g., a separate METRIC for each path) are outside the scope of this document and would require further extensions.

MULTIPATH-WEIGHT TLV A new MULTIPATH-WEIGHT TLV is optional in the PATH-ATTRIB object.

MULTIPATH-WEIGHT TLV format

Type (16 bits): 61 for "MULTIPATH-WEIGHT" TLV. Length (16 bits): MUST be set to 4. Weight (32 bits): unsigned integer weight of the path described by the enclosing PATH-ATTRIB object, if W-ECMP is desired. The fraction of flows that a specific ERO/RRO carries is derived from the ratio of its weight to the sum of the weights of all paths in the multipath (including that path): see for details. For SR Policy, if the Weight value is 0, the corresponding Segment List is declared invalid per Section 5.1 of and carries no traffic. If all paths within an LSP have Weight 0, the sum of weights is zero, making the candidate path invalid per Section 2.11 of . Signaling a zero-weight path alongside paths with non-zero weights can be used to drain traffic from a path while retaining its forwarding instructions. When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object, or the PATH-ATTRIB object is absent from the <intended-path>/<actual-path>, then the Weight of the corresponding path is taken to be 1.

MULTIPATH-OPPDIR-PATH TLV A new MULTIPATH-OPPDIR-PATH TLV is optional in the PATH-ATTRIB object. Multiple instances of the TLV are allowed in the same PATH-ATTRIB object. Each TLV instance identifies one opposite-direction path for the path described by this PATH-ATTRIB object. This provides per-path level opposite-direction mapping within an LSP. In the context of SR Policy, this corresponds to per-Segment List mapping within a Candidate Path, complementing the Candidate Path level bidirectional association defined in , which also describes the usage of this TLV in the context of associated bidirectional SR Paths. See for operational details.

MULTIPATH-OPPDIR-PATH TLV format

Type (16 bits): 63 for "MULTIPATH-OPPDIR-PATH" TLV Length (16 bits): MUST be set to 8. Reserved: This field MUST be set to zero on transmission and MUST be ignored on receipt. Flags (16 bits):

• N (Node co-routed): If set, indicates this path is node co-routed with its opposite direction path specified in this TLV. Two opposite direction paths are node co-routed if they traverse the same nodes, but MAY traverse different links. If not set, the paths are not guaranteed to be node co-routed (they may or may not traverse the same set of nodes).
• L (Link co-routed): If set, indicates this path is link co-routed with its opposite direction path, specified in this TLV. Two opposite direction paths are link co-routed if they traverse the same links (but in opposite directions). Link co-routing implies node co-routing; therefore, it is not necessary to set the N flag when the L flag is set.
• The terms "link" and "node" used by the N-flag and L-flag refer to the links and nodes as represented in the topology that the PCE uses for path computation. The exact nature of a link is determined by the PCE's topology view and is out of scope of this document. The same notion of "link" and "node" MUST be used consistently for both the forward and the opposite-direction path when evaluating co-routing; a path and its opposite-direction path are represented in the same topology view.
• Unassigned bits MUST be set to 0 on transmission and MUST be ignored on receipt.

Opposite Direction Path ID (32 bits): References the Path ID field (see ) of a PATH-ATTRIB object that identifies a path going in the opposite direction to this path. The value 0 is reserved and MUST NOT be used in this field. If no opposite-direction path exists, the MULTIPATH-OPPDIR-PATH TLV MUST NOT be included in the PATH-ATTRIB object (see ). If a PCEP speaker receives a MULTIPATH-OPPDIR-PATH TLV with Opposite Direction Path ID set to 0, it MUST send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = TBD4 ("Invalid opposite-direction path mapping").

Composite Candidate Path SR Policy Architecture defines the concept of a Composite Candidate Path. A regular SR Policy Candidate Path outputs traffic to a set of Segment Lists, while an SR Policy Composite Candidate Path outputs traffic recursively to a set of SR Policies on the same headend. In PCEP, the Composite Candidate Path still consists of PATH-ATTRIB objects, but ERO is replaced by Color of the recursively used SR Policy. To signal the Composite Candidate Path, this document makes use of the COLOR TLV, defined in . For a Composite Candidate Path, the COLOR TLV is included in the PATH-ATTRIB Object, thus allowing each Composite Candidate Path to do ECMP/W-ECMP among SR Policies identified by its constituent Colors. To achieve W-ECMP, the MULTIPATH-WEIGHT TLV () is included alongside the COLOR TLV in each PATH-ATTRIB object. If multiple COLOR TLVs are contained in the PATH-ATTRIB object, the first one is processed and the others MUST be ignored. An ERO MUST be included as per the existing RBNF; this ERO MUST contain no sub-objects. This empty ERO serves as a placeholder to maintain compatibility with existing implementations based on the RBNF defined in . If the head-end receives a non-empty ERO for a Composite Candidate Path, it MUST send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = 21 ("Non-empty path"). See for an example of the encoding.

Per-Flow Candidate Path Per-Flow Candidate Path builds on the concept of the Composite Candidate Path. Each Path in a Per-Flow Candidate Path is assigned a 3-bit forwarding class value, which allows Quality of Service (QoS) classified traffic to be steered depending on the forwarding class. A new MULTIPATH-FORWARD-CLASS TLV is optional in the PATH-ATTRIB object.

MULTIPATH-FORWARD-CLASS TLV format

Type (16 bits): TBD1 for "MULTIPATH-FORWARD-CLASS" TLV. Length (16 bits): MUST be set to 4. Flags (32 bits):

• T (1 bit): MPLS TC type. This is the most significant bit of the Flags field. When set, indicates that the FC value is derived from the MPLS Traffic Class (TC) bits as described in Section 8.6 of . When not set, the interpretation of the FC value is reserved for future use; a future specification MAY define a wider, right-aligned classifier value occupying additional low-order bits of the Flags field (e.g., for a non-MPLS dataplane).
• FC (3 bits): Forwarding class value. When the T flag is set, this carries the MPLS TC-based forwarding class value as defined in Section 8.6 of . This value is given by the QoS classifier to traffic entering the given Candidate Path. Different classes of traffic that enter the given Candidate Path can be differentially steered into different Colors. The FC field allows up to 8 different forwarding classes (values 0-7). The semantics of specific FC values are significant at the headend node (PCC) that implements the SR Policy and are determined by that node's local QoS policy or configuration. Coordination of FC value meanings between PCEP peers (e.g., through out-of-band configuration management or operational procedures) is outside the scope of this document.
• Unassigned bits MUST be set to 0 on transmission and MUST be ignored on receipt.

Operation

Capability Negotiation

Multipath Capability TLV A new MULTIPATH-CAP TLV is defined. This TLV MAY be present in the OPEN object during PCEP session establishment. It MAY also be present in the LSP object for each individual LSP from the PCC.

MULTIPATH-CAP TLV format

Type (16 bits): 60 for "MULTIPATH-CAP" TLV. Length (16 bits): MUST be set to 4. Number of Multipaths (16 bits): When sent from a PCC, it indicates how many forward primary multipaths the PCC can install in forwarding. From a PCE, it indicates how many forward primary multipaths the PCE can compute. This value is per-LSP when carried in the LSP object; the effective value governing a given LSP is the LSP object value if present, otherwise the OPEN object value (see below). This count does not include reverse paths (R-flag=1, where the R flag is defined in ), which are not installed in forwarding for load-balancing purposes. Therefore, the total number of PATH-ATTRIB objects in an LSP may exceed this value when reverse paths are also signaled. The value 0 indicates an unlimited number. Flags (16 bits):

• W-flag: whether MULTIPATH-WEIGHT TLV is supported. This flag covers the use of MULTIPATH-WEIGHT for both regular and Composite Candidate Paths.
• O-flag: In the OPEN object, this flag indicates whether the MULTIPATH-OPPDIR-PATH TLV is supported. In the LSP object, this flag indicates that opposite-direction path information is requested or provided for that specific LSP. When set by the PCC (in PCRpt/PCReq), it requests the PCE to provide reverse path information. When set by the PCE (in PCInit/PCUpd/PCRep), it indicates the PCE is providing or will provide reverse path information. In both cases, the PCE SHOULD provide the reverse path information, if it is able to. For PCC-Initiated LSPs, if the PCC has not set the O-flag in the MULTIPATH-CAP TLV of the LSP object, the PCE SHOULD NOT include reverse path information in the corresponding response. If the PCC receives unsolicited reverse path information, it MAY ignore it.
• F-flag: whether MULTIPATH-FORWARD-CLASS TLV is supported.
• C-flag: whether Composite Candidate Path () is supported, including the use of the COLOR TLV in the PATH-ATTRIB object.
• Unassigned bits MUST be set to 0 on transmission and MUST be ignored on receipt.

Note that F-flag and C-flag can be set independently for capability negotiation purposes. While Per-Flow Candidate Path () builds on top of Composite Candidate Path, the F-flag reflects whether the MULTIPATH-FORWARD-CLASS TLV is supported, and the C-flag reflects whether Composite Candidate Path signaling is supported. A peer that supports Per-Flow Candidate Path MUST set both C-flag and F-flag. Note that the F-flag is defined independently of the C-flag to allow for future use cases that may use the MULTIPATH-FORWARD-CLASS TLV for purposes other than Per-Flow Candidate Path; in such cases, the F-flag MAY be set without the C-flag. When a PCE computes an LSP path, it MUST NOT return more forward multipaths than the minimum of the effective "Number of Multipaths" values of both the PCE and PCC. The effective value for a given LSP is determined by the per-LSP MULTIPATH-CAP TLV in the LSP object if present; otherwise, it defaults to the value from the MULTIPATH-CAP TLV in the OPEN object. This ensures the PCE does not exceed either its own computation capability or the PCC's installation capability. If this TLV is absent from both OPEN and LSP objects, the PCEP speaker does not support multipath and the behavior is consistent with existing PCEP specifications, where a single path is associated with each LSP. If a PCC receives more paths than it advertised support for, it MUST send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = TBD3 ("Unsupported multipath capability"). When a PCE receives a PCRpt message containing more paths than its own computation capability, it MUST NOT treat this as an error condition; PCRpt conveys PCC-reported operational state and is not subject to the PCE's computation limits. The PCC MAY also include the MULTIPATH-CAP TLV in the LSP object for each individual LSP, to specify per-LSP values. The PCC MUST NOT include this TLV in the LSP object if the TLV was not present in the OPEN objects of both PCEP peers. TLV values in the LSP object override the session default values in the OPEN object. If a PCEP speaker receives a PATH-ATTRIB object but the multipath capability was not successfully negotiated during session establishment, it MUST treat this as an error. The PCEP speaker MUST send a PCError message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD2 ("Unexpected PATH-ATTRIB object"). For example, the PCC includes this TLV in the OPEN object at session establishment, setting "Number of Multipaths" to 4 and "O-flag" to 0. The PCC also includes this TLV in the LSP object for a particular LSP, setting "Number of Multipaths" to 16 and "O-flag" to 1. This indicates that the PCC only wants to receive the reverse path information for that particular LSP and that this LSP can have up to 16 multipaths, while other LSPs can only have up to 4 multipaths. Additionally, if a PCEP speaker receives a TLV within the PATH-ATTRIB object (such as MULTIPATH-WEIGHT, MULTIPATH-OPPDIR-PATH, or MULTIPATH-FORWARD-CLASS) but the corresponding capability flag was not set in the negotiated MULTIPATH-CAP TLV, it MUST treat this as an error. The PCEP speaker MUST send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = TBD3 ("Unsupported multipath capability").

Path ID The Path ID uniquely identifies a Path within the context of an LSP. A single Path ID space is shared among all paths within the LSP, including forward paths and reverse paths (R-flag=1). Path IDs MUST be unique across forward and reverse paths within the same LSP. The meaning of "Path" depends on the type of LSP:

• For a regular SR Policy Candidate Path, the Paths within that LSP are the Segment Lists.
• For a Composite Candidate Path (), the Paths within that LSP are the constituent SR Policies, each of which is identified by its Color (carried in the COLOR TLV within the corresponding PATH-ATTRIB object).

Value 0 indicates an unallocated Path ID. The value of 0 MAY be used when this Path is not referenced and the allocation of a Path ID is not necessary. Path IDs are allocated by the PCEP peer that owns the LSP. If the LSP is delegated to the PCE, then the PCE allocates the Path IDs and sends them in the PCReply/PCUpd/PCInitiate messages. If the LSP is locally computed on the PCC, then the PCC allocates the Path IDs and sends them in the PCReq/PCRpt messages. When LSP delegation changes (e.g., the PCC revokes delegation from the PCE), the new path owner SHOULD retain the existing Path IDs to simplify path correlation in the event of re-delegation. If the new owner cannot retain them, it MAY allocate new Path IDs. If a PCEP speaker detects that there are two Paths with the same non-zero Path ID, then the PCEP speaker MUST send a PCError message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 38 ("Conflicting Path ID"). Multiple paths MAY have Path ID set to 0, as this value indicates those paths are not referenced and do not require unique identification.

Signaling Multiple Paths for Load-Balancing The PATH-ATTRIB object can be used to signal multiple paths and indicate equal or unequal load-balancing among the set of multipaths. In this case, the PATH-ATTRIB is populated for each ERO as follows:

1. The PCE MAY assign a unique Path ID to each ERO path and populate it inside the PATH-ATTRIB object. The Path ID is unique within the context of a PLSP (PCE Label Switched Path) (when non-zero).
2. The PCE MAY include the MULTIPATH-WEIGHT TLV inside the PATH-ATTRIB object, populating a weight value to reflect the relative share of traffic to be carried by the path. If the MULTIPATH-WEIGHT is not carried inside a PATH-ATTRIB object, the PCC MUST assume the default weight of 1 when computing the traffic share.
3. The PCC derives the fraction of flows carried by a specific primary path from the ratio of its weight to the sum of the weights of all paths in the multipath. For SR Policy, the use of weights for load-balancing between Segment Lists of a Candidate Path is described in Section 2.11 of .

Signaling Opposite-Direction Path Information The PATH-ATTRIB object can be used to signal opposite-direction path associations within a PCEP LSP. This capability is used to establish bidirectional path relationships where forward and reverse paths can be explicitly mapped to each other. In this case, the PATH-ATTRIB is populated for each ERO as follows:

1. The PCEP peer (PCC or PCE) allocates a unique Path ID to each path and populates it inside the PATH-ATTRIB object. The Path ID is unique within the context of a PLSP (PCE Label Switched Path).
2. For paths that have opposite-direction counterparts, the MULTIPATH-OPPDIR-PATH TLV is added to the PATH-ATTRIB object. The Opposite Direction Path ID field is set to reference the Path ID of the corresponding opposite-direction path.
3. Multiple instances of the MULTIPATH-OPPDIR-PATH TLV MAY be present in the same PATH-ATTRIB object to support many-to-many mappings between forward and reverse paths. This allows a single forward path to map to multiple reverse paths and vice versa. Many-to-many mapping can occur when a Segment List contains Node Segment(s) that traverse parallel links at a midpoint. The reverse of this Segment List may require multiple Reverse Segment Lists to cover all the parallel links at the midpoint.
4. The N-flag and L-flag in the MULTIPATH-OPPDIR-PATH TLV MAY be set to indicate node co-routing or link co-routing respectively. These flags inform the receiver about the relationship between the forward and reverse paths.
5. For paths that have no opposite-direction counterpart, the MULTIPATH-OPPDIR-PATH TLV is omitted from the PATH-ATTRIB object.

Forward paths (R-flag=0) and reverse paths (R-flag=1) are included in the same PCEP LSP, allowing bidirectional relationships to be established in a single message exchange. The opposite-direction path associations MUST be symmetric within the same LSP: for each (A -> B) reference expressed via a MULTIPATH-OPPDIR-PATH TLV instance in path A's PATH-ATTRIB object, the corresponding (B -> A) reference MUST also be present as a MULTIPATH-OPPDIR-PATH TLV instance in path B's PATH-ATTRIB object. Multiple MULTIPATH-OPPDIR-PATH TLV instances per PATH-ATTRIB object are permitted, supporting many-to-many mappings. Additionally, the R-flags of opposite-direction paths MUST have opposite values (one set to 0, the other to 1). If a PCEP speaker receives an opposite-direction path mapping that is asymmetric or where the R-flags are inconsistent, it MUST send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = TBD4 ("Invalid opposite-direction path mapping"). See for an example of usage.

PCEP Message Extensions The RBNF of PCRpt and PCUpd messages, as defined in , uses a combination of <intended-path> and/or <actual-path>. PCReq and PCRep messages, as defined in and extended by , directly include ERO and RRO within their respective message structures rather than encapsulating them within <intended-path> or <actual-path> constructs. As specified in Section 6.1 of , within the context of messages that use these constructs, <intended-path> is represented by the ERO and <actual-path> is represented by the RRO: ::= ::= ]]> This document extends by allowing multiple EROs/RROs to be present in the <intended-path>/<actual-path>: ::= | [] ::= [] ::= | [] ::= [] ]]> Similarly, this document extends by allowing multiple paths in the PCInitiate message by allowing multiple EROs with their associated path attributes. The PCE-initiated LSP instantiation format is updated to: ::= [] [] ]]> where <intended-path> follows the recursive definition above, allowing multiple paths to be signaled in a single PCInitiate message. When multiple paths are present, each ERO MUST be preceded by a PATH-ATTRIB object that describes it. A single path MAY be sent as a bare ERO without PATH-ATTRIB for backward compatibility. This document also extends the PCRep and PCReq messages, defined in , to carry multipath information. Because these messages include the ERO and RRO directly rather than within the <intended-path>/<actual-path> constructs, the extension allows a PATH-ATTRIB object to precede each ERO or RRO that it describes. In the PCRep message, the <path> element is updated to allow a PATH-ATTRIB object to precede the ERO, with multiple <path> elements in the existing <path-list> used to signal multiple paths: ::= | ]]> When multiple paths are returned for load-balancing, each <path> in the <path-list> MUST include a PATH-ATTRIB object preceding its ERO. A single <path> MAY be sent as a bare ERO without PATH-ATTRIB for backward compatibility. In the PCReq message, the existing path reported for reoptimization is updated to allow multiple RROs, each preceded by a PATH-ATTRIB object: ::= [] [] [] [] [] [] [] ::= [] | [] [] ::= [] [] ]]> When multiple existing paths are reported, each RRO MUST be preceded by a PATH-ATTRIB object. A single reported path MAY be sent as a bare RRO without PATH-ATTRIB for backward compatibility. The LOAD-BALANCING object and the multipath extensions defined in this document are two different mechanisms for requesting multiple paths and MUST NOT be combined. The LOAD-BALANCING object requests a set of independent TE LSPs, each with its own bandwidth, whereas these extensions return multiple paths within a single LSP. Accordingly, a PCReq message MUST NOT contain both a LOAD-BALANCING object and a MULTIPATH-CAP TLV (in the LSP object) for the same request. A PCEP speaker that receives such a request MUST send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = TBD5 ("LOAD-BALANCING and MULTIPATH-CAP TLV in the same request"). The capability negotiation and error handling defined in apply equally to the PCReq and PCRep messages. In particular, a PCEP speaker that receives a PATH-ATTRIB object, or a TLV within it, in a PCReq or PCRep message without having negotiated the corresponding capability in the MULTIPATH-CAP TLV MUST treat it as an error as specified in . The RBNF extensions defined in this section are additive and apply only to sessions where the capabilities from the MULTIPATH-CAP TLV have been successfully negotiated (). Legacy PCEP peers that do not advertise the MULTIPATH-CAP TLV will not receive PATH-ATTRIB objects introduced by the updated RBNF.

Implementation Status Note to the RFC Editor - remove this section before publication, as well as remove the reference to . This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Cisco Systems

Ciena Corp

Huawei Technologies

IANA Considerations All IANA actions in this section pertain to the "Path Computation Element Protocol (PCEP) Numbers" registry group, available at https://www.iana.org/assignments/pcep/.

PCEP Object IANA is requested to confirm the following allocation in the "PCEP Objects" registry (https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): Object-Type values are managed via the IETF Review policy as per .

PCEP TLV IANA is requested to confirm the following allocations in the "PCEP TLV Type Indicators" registry (https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators): IANA is requested to make new allocations in the "PCEP TLV Type Indicators" registry:

PCEP-Error Object IANA is requested to confirm the following allocations in the "PCEP-ERROR Object Error Types and Values" registry (https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object): IANA is requested to make new allocations in the "PCEP-ERROR Object Error Types and Values" registry:

Flags in the MULTIPATH-CAP TLV IANA is requested to create a new registry called "Flags in MULTIPATH-CAP TLV" to manage the Flag field of the MULTIPATH-CAP TLV. New values are to be assigned by "IETF review"

Flags in the PATH-ATTRIB Object IANA is requested to create a new registry called "Flags in PATH-ATTRIB Object" to manage the Flag field of the PATH-ATTRIB object. New values are to be assigned by "IETF review"

Flags in the MULTIPATH-OPPDIR-PATH TLV IANA is requested to create a new registry called "Flags in MULTIPATH-OPPDIR-PATH TLV" to manage the Flag field of the MULTIPATH-OPPDIR-PATH TLV. New values are to be assigned by "IETF review"

Flags in the MULTIPATH-FORWARD-CLASS TLV IANA is requested to create a new registry called "Flags in MULTIPATH-FORWARD-CLASS TLV" to manage the Flag field of the MULTIPATH-FORWARD-CLASS TLV. New values are to be assigned by "IETF review"

Security Considerations The security considerations described in , , , , , and are applicable to this specification. As per , it is RECOMMENDED that these PCEP extensions can only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) as per the recommendations and best current practices in . The multipath extensions defined in this document allow a PCE to signal multiple paths per LSP, which increases the per-LSP state maintained by the PCC. A misbehaving or compromised PCE could exploit this to amplify state at the PCC by maximizing multipath fan-out. The "Number of Multipaths" field in the MULTIPATH-CAP TLV provides an upper bound on the number of paths a PCC will accept per LSP, and operators SHOULD configure a non-zero value to limit exposure. The existing PCEP authentication and encryption recommendations (TLS per ) mitigate the risk of unauthorized PCE access.

Operational Considerations All manageability requirements and considerations listed in , , , and apply to the PCEP protocol extensions defined in this document. In addition, the requirements and considerations listed in this section apply.

Control of Function and Policy A PCEP speaker (PCC or PCE) implementation should allow an operator to enable or disable the multipath capabilities advertised in the MULTIPATH-CAP TLV (see ).

Information and Data Models It is expected that a future version of the PCEP YANG module will be extended to include the PCEP extensions defined in this document.

Liveness Detection and Monitoring The mechanisms defined in this document do not introduce any new liveness detection or monitoring requirements in addition to those already defined in and .

Verify Correct Operations In addition to the verification requirements in and , the following considerations apply:

• An implementation should allow an operator to view the capabilities advertised in the MULTIPATH-CAP TLV by each PCEP peer for a session and for individual LSPs.
• An implementation should allow an operator to view the PATH-ATTRIB object and all its associated TLVs for each path within an LSP. This includes the Path ID, weight, and opposite-direction path associations.
• An implementation should provide a mechanism to log and display the new PCEP errors defined in this document.

Requirements On Other Protocols The PCEP extensions defined in this document do not impose any new requirements on other protocols.

Impact On Network Operations The mechanisms in this document allow for more complex LSP structures with multiple paths. Network operators should be aware of the potential increase in PCEP message sizes and the additional state that must be maintained by PCEP speakers. The "Number of Multipaths" field in the MULTIPATH-CAP TLV can be used to control the scale of multipath computations and state. Paths within a single LSP may have significantly different properties, such as MTU, latency, and available bandwidth. When flow-based load-balancing is used across such paths, individual flows are hashed to a single path, so per-path MTU or latency divergence is a per-flow concern rather than a per-packet one. However, operators should be aware that advertising weighted load-balancing across paths with very different latencies can degrade application performance. Similarly, if paths have different MTUs, the effective MTU for flows on each path will differ; operators should ensure that PMTUD or consistent MTU configuration is in place. For bidirectional applications relying on Performance Measurement (PM) or BFD, note that forward and reverse paths may have asymmetric properties, and implementations should account for this. PCE implementations should minimize unnecessary churn in multipath state. With multiple paths per LSP, frequent re-computation or weight changes cause flow redistribution across Segment Lists, which may perturb congestion control state and trigger PMTUD re-discovery on a broader scale than with single-path LSPs. For Composite Candidate Paths, recursive policy resolution is therefore bounded, as Section 2.2 of prohibits constituent SR Policies of a composite Candidate Path from themselves using composite Candidate Paths.

Acknowledgements Thanks to Adrian Farrel for shepherding this document, Ketan Talaulikar for his thorough AD review, Dhruv Dhody for ideas and discussion, and Diego Achaval, Quan Xiong, Giuseppe Fioccola, Italo Busi, Yuan Yaping, Cheng Li, Eric Vyncke, Mohamed Boucadair, Gunter Van de Velde, Christopher Inacio, Mike Bishop, Mahesh Jethanandani, Vidhi Goel, Gorry Fairhurst, and David Mandelberg for their reviews.

Contributors

Original Authors The following individuals are the original authors who initiated and developed the core work of this document. Mike Koldychev is also listed as editor in the Authors' Addresses section. The remaining individuals appear here rather than in the Authors' Addresses section due to the IETF guidelines on the maximum number of listed authors, but should be considered co-authors of this document. Samuel Sidor joined the effort at a later stage as an additional editor.

Additional Contributors The following individuals made contributions to this document:

References Normative References 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. 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. A Segment Routing (SR) Policy is an ordered list of instructions called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. An SR Policy is made of one or more Candidate Paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal Candidate Paths of an SR Policy. Additionally, this document updates RFC 8231 to allow delegation and setup of an SR Label Switched Path (LSP) without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). 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. 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] 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. 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. Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF. There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation. Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work. This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK] Color is a 32-bit numerical (unsigned integer) attribute used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective. For example, a TE Tunnel constructed to deliver low latency services and whose path is optimized for delay can be tagged with a color that represents "low latency." This document specifies extensions to the Path Computation Element Protocol (PCEP) to carry the color attribute. 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. 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. 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. Huawei sn3rd Vigil Security, LLC Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for PCEP (Path Computation Element Communication Protocol). This document adds restrictions to specify what PCEPS implementations do if they support more than one version of the TLS protocol and to restrict the use of TLS 1.3's early data. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. Informative References Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. 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] This document defines Path Computation Element Communication Protocol (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP. These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or using a stateless PCE. The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling. Cisco Systems, Inc. Cisco Systems, Inc. Airtel India Ciena Nokia This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a SR network. The association of two co- routed unidirectional SR Policies satisfying these requirements is called "Circuit Style" SR Policy (CS-SR Policy). Huawei Technologies Huawei Technologies China Mobile Cisco Systems, Inc. ZTE Corporation Segment Routing (SR) steers packets through a network using the IPv6 or MPLS data planes via source routing. Stateful Path Computation Element Communication Protocol (PCEP) extensions are defined for SR Traffic Engineering (TE) LSPs. PCEP supports grouping two RSVP-TE signaled, unidirectional MPLS-TE Label-Switched Paths (LSPs) with one in each direction in a network into an associated bidirectional LSP. This document extends PCEP support to group two unidirectional SR LSPs into an associated bidirectional SR LSP. The mechanisms defined in this document apply to both stateless and stateful PCEs for PCE-initiated and PCC- initiated LSPs. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. 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. This document defines a YANG data model for the management of the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.

Examples

SR Policy Candidate Path with Multiple Segment Lists Consider the following sample SR Policy. Candidate Path CP1 Preference 200 Weight W1, SID-List1 Weight W2, SID-List2 Candidate Path CP2 Preference 100 Weight W3, SID-List3 Weight W4, SID-List4 ]]> As specified in , CP1 and CP2 are signaled as separate state-report elements and each has a unique PLSP-ID, assigned by the PCC. For this example, PLSP-ID 100 is assigned to CP1 and PLSP-ID 200 to CP2. The state-report (as defined in ) for CP1 can be encoded as: = > > ]]> The state-report for CP2 can be encoded as: = > > ]]> The above sample state-report elements only specify the minimum mandatory objects, of course other objects like SRP, LSPA, METRIC, etc., are allowed to be inserted. Note that the syntax > ]]> means that this is PATH-ATTRIB object with Path ID field set to 1 and with a MULTIPATH-WEIGHT TLV carrying weight of "W1".

Composite Candidate Path Consider the following Composite Candidate Path. Candidate Path CP1 Preference 200 Weight W1, SR policy Weight W2, SR policy ]]> This is signaled in PCEP as: > > ]]>

Opposite Direction Tunnels Consider the two opposite-direction SR Policies between endpoints H1 and E1. Candidate Path CP1 Preference 200 Bidirectional Association = A1 SID-List = SID-List = Candidate Path CP2 Preference 100 Bidirectional Association = A2 SID-List = SID-List = SR policy POL2 Candidate Path CP1 Preference 200 Bidirectional Association = A1 SID-List = SID-List = Candidate Path CP2 Preference 100 Bidirectional Association = A2 SID-List = ]]> The state-report for POL1, CP1 can be encoded as: = > > > > > > > > ]]> The state-report for POL1, CP2 can be encoded as: = > > > > > ]]> The state-report for POL2, CP1 can be encoded as: = > > > > > > > > ]]> The state-report for POL2, CP2 can be encoded as: = > > > > > ]]>