| Internet-Draft | PCEP Extensions for Multipath | March 2026 |
| Koldychev, et al. | Expires 3 September 2026 | [Page] |
A Segment Routing (SR) Policy Candidate Path can contain multiple Segment Lists, allowing for load-balancing and protection across diverse paths. However, current PCEP extensions for SR Policy only allow signaling of a single Segment List per Candidate Path. This document defines PCEP extensions to encode multiple Segment Lists within an SR Policy Candidate Path, enabling multipath capabilities such as weighted or equal-cost load-balancing across Segment Lists. The extensions are designed to be generic and reusable for future path types beyond SR Policy, and are applicable to both stateless and stateful PCEP.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 September 2026.¶
Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) 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.¶
Segment Routing Policy for Traffic Engineering [RFC9256] 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 [RFC9862] specifically avoids defining how to signal multiple Segment Lists.¶
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 data plane types.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are used in this document:¶
ECMP:¶
Equal Cost Multi Path, equally distributing traffic among multiple paths/links, where each path/link gets the same share of traffic as others.¶
W-ECMP:¶
Weighted ECMP, 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.¶
Path:¶
In the context of this document, a path refers to a single forwarding path encoded in an ERO or RRO object. 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. In the context of PCEP for SR Policy [RFC9862], an LSP object represents an SR Policy Candidate Path, which may contain multiple paths (Segment Lists).¶
Segment List:¶
An ordered list of segments that defines a forwarding path in Segment Routing, as defined in [RFC9256]. In PCEP for SR Policy, each Segment List is encoded as an ERO object.¶
ERO:¶
This extension is motivated by the use-cases described below.¶
The Candidate Path of an SR Policy is the unit of signaling in PCEP [RFC9862]. A single Candidate Path can consist of multiple Segment Lists. Each Segment List is represented by an Explicit Route Object (ERO). In existing PCEP RFCs, 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.¶
A Path Computation Client (PCC) may request a path with 80 Gbps of bandwidth, but all links in the network have only 60 Gbps capacity. The Path Computation Element (PCE) can return two paths, that can together carry 80 Gbps. The PCC can then equally or unequally split the incoming 80 Gbps of traffic among the two paths. Section 3.3 introduces a new TLV that carries the path weight that facilitates control of load-balancing of traffic among the multiple paths.¶
Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional LSPs [RFC9059] 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 [RFC9059] 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 [I-D.ietf-spring-cs-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.¶
This document defines the PATH-ATTRIB object that is used to carry per-path information and to act as a separator between ERO/RRO objects in the <intended-path>/<actual-path> Routing Backus-Naur Form (RBNF) [RFC5511] element. The PATH-ATTRIB object always precedes the ERO or RRO that it applies to. If multiple ERO or RRO objects are present, then each ERO or RRO object MUST be preceded by an 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 Figure 1.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |R| O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (32 bits):¶
O (Operational - 3 bits): operational state of the path, same values as the identically named field in the LSP object [RFC8231].¶
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 serve only informational purpose to the PCC.¶
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 Section 4.2 for details.¶
Optional TLVs: Variable length field that can contain one or more TLVs that carry additional per-path information. The specific TLVs that can be included are defined in subsequent sections of this document.¶
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.¶
New MULTIPATH-WEIGHT TLV is optional in the PATH-ATTRIB object.¶
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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16 bits): 61 for "MULTIPATH-WEIGHT" TLV.¶
Length (16 bits): 4 bytes.¶
Weight (32 bits): unsigned integer weight of this path within the multipath, 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 other paths: see Section 4.3 for details.¶
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.¶
New MULTIPATH-BACKUP TLV is optional in the PATH-ATTRIB object.¶
This TLV is used to describe a set of backup paths protecting a primary path within a PCEP LSP: see Section 4.4 for details. This is similar to path protection, but works at the ECMP path level instead of at the PCEP LSP level.¶
This functionality is not part of the SR Policy Architecture [RFC9256], but is something optional that may be implemented for certain specialized use cases. One such use case is the Point-to-Multipoint (P2MP) SR Policy [I-D.draft-ietf-pce-sr-p2mp-policy].¶
Support for the MULTIPATH-BACKUP TLV is currently defined only for P2MP paths. Support for Point-to-Point (P2P) paths is out of scope for this document. If needed in the future, support for P2P paths using the MULTIPATH-BACKUP TLV can be defined in future documents. Future documents that extend this TLV to support P2P paths SHOULD also define explicit capability exchange mechanisms to allow PCEP peers to negotiate support for MULTIPATH-BACKUP with P2P paths.¶
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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path Count | Flags |B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16 bits): 62 for "MULTIPATH-BACKUP" TLV¶
Length (16 bits): 4 + (N * 4) bytes (where N is the Backup Path Count)¶
Backup Path Count (16 bits): Number of backup paths.¶
Flags (16 bits):¶
B (Pure Backup): If set, indicates the path is a backup path (e.g., for protection) and not used for load balancing under normal conditions. A pure backup path only carries rerouted traffic after the protected paths fail. If this flag is not set, or if the MULTIPATH-BACKUP TLV is absent, then the path is assumed to be primary that carries normal traffic.¶
Unassigned bits MUST be set to 0 on transmission and MUST be ignored on receipt.¶
Backup Path IDs: A series of 4-octet identifiers that reference the Path ID field (see Section 4.2) of other PATH-ATTRIB objects within the same PCEP LSP. These referenced paths act as backup paths that protect this primary path. Each Backup Path ID value MUST match the Path ID of a PATH-ATTRIB object in the same LSP that has the B-flag set (indicating it is a pure backup path).¶
If a PCEP speaker receives a MULTIPATH-BACKUP TLV applied to a P2P path, it MUST reject the path and send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = 20 ("Not supported path backup").¶
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. See Section 4.5 for operational details.¶
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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |L|N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opposite Direction Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16 bits): 63 for "MULTIPATH-OPPDIR-PATH" TLV¶
Length (16 bits): 8 bytes.¶
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.¶
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 Section 4.2) of a PATH-ATTRIB object that identifies a path going in the opposite direction to this path. If no opposite-direction path exists, then this field MUST be set to 0, a value reserved to indicate the absence of a Path ID.¶
SR Policy Architecture [RFC9256] 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, we make use of the COLOR TLV, defined in [RFC9863]. 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. If multiple COLOR TLVs are contained in the PATH-ATTRIB object, the first one is processed and the others MUST be ignored.¶
An ERO object 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 [RFC8231]. 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 Section 10.3 for an example of the encoding.¶
Per-Flow Candidate Path builds on top of 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.¶
New MULTIPATH-FORWARD-CLASS TLV is optional in the PATH-ATTRIB object.¶
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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | FC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16 bits): TBD1 for "MULTIPATH-FORWARD-CLASS" TLV.¶
Length (16 bits): 4 bytes.¶
Reserved: This field MUST be set to zero on transmission and MUST be ignored on receipt.¶
FC (3 bits): Forwarding class value as defined in Section 8.6 of [RFC9256]. 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.¶
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.¶
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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Multipaths | Flags |C|F|O|B|W| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16 bits): 60 for "MULTIPATH-CAP" TLV.¶
Length (16 bits): 4 bytes.¶
Number of Multipaths (16 bits): When sent from a PCC, it indicates how many multipaths the PCC can install in forwarding. From a PCE, it indicates how many multipaths the PCE can compute. The value 255 indicates an unlimited number. The value 0 is reserved.¶
Flags (16 bits):¶
W-flag: whether MULTIPATH-WEIGHT TLV is supported.¶
B-flag: whether MULTIPATH-BACKUP TLV is supported.¶
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.¶
F-flag: whether MULTIPATH-FORWARD-CLASS TLV is supported.¶
C-flag: whether Composite Candidate Path (Section 3.6) is supported.¶
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, i.e., F-flag can be set, but C-flag not set, etc.¶
When a PCE computes an LSP path, it MUST NOT return more forward multipaths than the minimum of the "Number of Multipaths" values advertised by both the PCE and PCC in their respective MULTIPATH-CAP TLVs during capability negotiation. 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), then the "Number of Multipaths" is assumed to be 1.¶
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").¶
From the PCC, the MULTIPATH-CAP TLV MAY also be present 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-BACKUP, 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").¶
The Path ID uniquely identifies a Path within the context of an LSP. Note that when the LSP is an SR Policy Candidate Path, the Paths within that LSP are the Segment Lists.¶
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.¶
If a PCEP speaker detects that there are two Paths with the same non-zero Path ID, then the PCEP speaker MUST send PCError message with Error-Type = 1 ("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.¶
The PATH-ATTRIB object can be used to signal multiple paths and indicate (un)equal loadbalancing amongst the set of multipaths. In this case, the PATH-ATTRIB is populated for each ERO as follows:¶
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).¶
The PCE MAY include the MULTIPATH-WEIGHT TLV inside the PATH-ATTRIB object, populating a weight value to reflect the relative loadshare that is 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 loadshare.¶
The PCC derives the fraction of flows carried by a specific primary path from the ratio of its weight to the sum of all other multipath weights.¶
The PATH-ATTRIB object can be used to describe a set of backup paths protecting a primary path within a PCEP LSP. This capability is currently defined only for P2MP paths. Support for P2P paths with the MULTIPATH-BACKUP TLV is out of scope for this document. In this case, the PATH-ATTRIB is populated for each ERO as follows:¶
The PCE assigns a unique Path ID to each ERO path and populates it inside the PATH-ATTRIB object. The Path ID is unique within the context of a PLSP (PCE Label Switched Path).¶
The PCE MAY include the MULTIPATH-BACKUP TLV inside the PATH-ATTRIB object for each ERO that is protected, specifying the backup path IDs to reflect the set of backup paths protecting the primary path. The PCE updates the Length field and Backup Path Count in the MULTIPATH-BACKUP according to the number of backup path IDs included.¶
The PCE MAY include the MULTIPATH-BACKUP TLV inside the PATH-ATTRIB object for each ERO that is unprotected. In this case, MULTIPATH-BACKUP does not carry any backup path IDs in the TLV. If the path acts as a pure backup (i.e., the path only carries rerouted traffic after the protected paths fail), then the B flag MUST be set.¶
Primary paths which do not include the MULTIPATH-BACKUP TLV are assumed to be protected by all the backup paths (i.e., omitting the TLV is equivalent to including the TLV with all the backup path IDs filled in).¶
Note that a given PCC may not support certain backup combinations, such as a backup path that is itself protected by another backup path, etc. If a PCC does not support a requested backup scenario, the PCC MUST send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = 20 ("Not supported path backup"). Additionally, if a P2P path is sent with a MULTIPATH-BACKUP TLV, the PCC or PCE SHOULD reject it with the same PCError as above.¶
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:¶
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).¶
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.¶
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.¶
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.¶
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 atomically. The opposite-direction path associations MUST be symmetric within the same LSP. When path A references path B as its opposite-direction path, path B MUST also reference path A as its opposite-direction path. Additionally, their R-flags in the PATH-ATTRIB object 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 Section 10.4 for an example of usage.¶
The RBNF of PCRpt and PCUpd messages, as defined in [RFC8231], use a combination of <intended-path> and/or <actual-path>. PCReq and PCRep messages, as defined in [RFC5440] and extended by [RFC8231], directly include ERO and RRO objects within their respective message structures rather than encapsulating them within <intended-path> or <actual-path> constructs.¶
As specified in Section 6.1 of [RFC8231], within the context of messages that use these constructs, <intended-path> is represented by the ERO object and <actual-path> is represented by the RRO object:¶
<intended-path> ::= <ERO> <actual-path> ::= <RRO>¶
This document extends [RFC8231] by allowing multiple ERO/RRO objects to be present in the <intended-path>/<actual-path>:¶
<intended-path> ::= <ERO> |
<PATH-ATTRIB><ERO>[<intended-path-multipath>]
<intended-path-multipath> ::= <PATH-ATTRIB><ERO>
[<intended-path-multipath>]
<actual-path> ::= <RRO> |
<PATH-ATTRIB><RRO>[<actual-path-multipath>]
<actual-path-multipath> ::= <PATH-ATTRIB><RRO>
[<actual-path-multipath>]
¶
Similarly, this document extends [RFC8281] by allowing multiple paths in the PCInitiate message by allowing multiple ERO objects with their associated path attributes. The PCE-initiated LSP instantiation format is updated to:¶
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<intended-path>
[<attribute-list>]
¶
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.¶
Note to the RFC Editor - remove this section before publication, as well as remove the reference to [RFC7942].¶
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 [RFC7942]. 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 [RFC7942], "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".¶
Organization: Cisco Systems Implementation: IOS-XR PCC and PCE Description: Circuit-Style SR Policies Maturity Level: Supported feature Coverage: Multiple Segment Lists and reverse paths in SR Policy Contact: mkoldych@cisco.com¶
Organization: Ciena Corp Implementation: Head-end and controller Maturity Level: Proof of concept Coverage: Partial Contact: byadav@ciena.com¶
Organization: Huawei Technologies Co.,Ltd. Implementation: Huawei's Router and Controller Maturity Level: Proof of concept Coverage: Partial Contact: tanren@huawei.com¶
IANA is requested to confirm the following allocation in the "PCEP Objects" within the "Path Computation Element Protocol (PCEP) Numbers" registry group:¶
+--------------+-------------+-------------------+-----------------+ | Object-Class | Name | Object-Type | Reference | | Value | | Value | | +--------------+-------------+-------------------+-----------------+ | 45 | PATH-ATTRIB | 0: Reserved | | | | | 1: PATH-ATTRIB | This document | | | | 2-15: Unassigned | | +--------------+-------------+-------------------+-----------------+¶
Object-Type values are managed via the IETF Review policy as per [RFC8126].¶
IANA is requested to confirm the following allocations within the "PCEP TLV Type Indicators" within the "Path Computation Element Protocol (PCEP) Numbers" registry group:¶
+------------+-----------------------------------+-----------------+ | TLV Type | TLV Name | Reference | | Value | | | +------------+-----------------------------------+-----------------+ | 60 | MULTIPATH-CAP | This document | +------------+-----------------------------------+-----------------+ | 61 | MULTIPATH-WEIGHT | This document | +------------+-----------------------------------+-----------------+ | 62 | MULTIPATH-BACKUP | This document | +------------+-----------------------------------+-----------------+ | 63 | MULTIPATH-OPPDIR-PATH | This document | +------------+-----------------------------------+-----------------+¶
IANA is requested to make new allocations within the "PCEP TLV Type Indicators" within the "Path Computation Element Protocol (PCEP) Numbers" registry group:¶
+------------+-----------------------------------+-----------------+ | TLV Type | TLV Name | Reference | | Value | | | +------------+-----------------------------------+-----------------+ | TBD1 | MULTIPATH-FORWARD-CLASS | This document | +------------+-----------------------------------+-----------------+¶
IANA is requested to confirm the following allocations within the "PCEP-ERROR Object Error Types and Values" within the "Path Computation Element Protocol (PCEP) Numbers" registry group:¶
+------------+-----------------------------------+-----------------+ | Error-Type | Error-Value | Reference | +------------+-----------------------------------+-----------------+ | 10 | 38 - Conflicting Path ID | This document | +------------+-----------------------------------+-----------------+ | 19 | 20 - Not supported path backup | This document | +------------+-----------------------------------+-----------------+ | 19 | 21 - Non-empty path | This document | +------------+-----------------------------------+-----------------+¶
IANA is requested to make new allocations within the "PCEP-ERROR Object Error Types and Values" within the "Path Computation Element Protocol (PCEP) Numbers" registry group:¶
+------------+-----------------------------------+-----------------+ | Error-Type | Error-Value | Reference | +------------+-----------------------------------+-----------------+ | 10 | TBD2 - Unexpected PATH-ATTRIB | This document | | | Object | | +------------+-----------------------------------+-----------------+ | 19 | TBD3 - Unsupported multipath | This document | | | capability | | +------------+-----------------------------------+-----------------+ | 19 | TBD4 - Invalid opposite-direction | This document | | | path mapping | | +------------+-----------------------------------+-----------------+¶
IANA is requested to create a new sub-registry to manage the Flag field of the MULTIPATH-CAP TLV, called "Flags in MULTIPATH-CAP TLV" within the "Path Computation Element Protocol (PCEP) Numbers" registry group. New values are to be assigned by "IETF review" [RFC8126]¶
+------------+-----------------------------------+-----------------+ | Bit | Description | Reference | +------------+-----------------------------------+-----------------+ | 0-10 | Unassigned | This document | +------------+-----------------------------------+-----------------+ | 11 | C-flag: Composite Candidate | This document | | | Path support | | +------------+-----------------------------------+-----------------+ | 12 | F-flag: MULTIPATH-FORWARD-CLASS | This document | | | TLV support | | +------------+-----------------------------------+-----------------+ | 13 | 0-flag: MULTIPATH-OPPDIR-PATH | This document | | | TLV support | | +------------+-----------------------------------+-----------------+ | 14 | B-flag: MULTIPATH-BACKUP TLV | This document | | | support | | +------------+-----------------------------------+-----------------+ | 15 | W-flag: MULTIPATH-WEIGHT TLV | This document | | | support | | +------------+-----------------------------------+-----------------+¶
IANA is requested to create a new sub-registry to manage the Flag field of the PATH-ATTRIB object, called "Flags in PATH-ATTRIB Object" within the "Path Computation Element Protocol (PCEP) Numbers" registry group. New values are to be assigned by "IETF review" [RFC8126]¶
+------------+-----------------------------------+-----------------+ | Bit | Description | Reference | +------------+-----------------------------------+-----------------+ | 0-12 | Unassigned | This document | +------------+-----------------------------------+-----------------+ | 13-15 | O-flag: Operational state | This document | +------------+-----------------------------------+-----------------+¶
IANA is requested to create a new sub-registry to manage the Flag field of the MULTIPATH-BACKUP TLV, called "Flags in MULTIPATH-BACKUP TLV" within the "Path Computation Element Protocol (PCEP) Numbers" registry group. New values are to be assigned by "IETF review" [RFC8126]¶
+------------+-----------------------------------+-----------------+ | Bit | Description | Reference | +------------+-----------------------------------+-----------------+ | 0-14 | Unassigned | This document | +------------+-----------------------------------+-----------------+ | 15 | B-flag: Pure backup | This document | +------------+-----------------------------------+-----------------+¶
IANA is requested to create a new sub-registry to manage the flag fields of the MULTIPATH-OPPDIR-PATH TLV, called "Flags in the MULTIPATH-OPPDIR-PATH TLV" within the "Path Computation Element Protocol (PCEP) Numbers" registry group. New values are to be assigned by "IETF review" [RFC8126]¶
+------------+-----------------------------------+-----------------+ | Bit | Description | Reference | +------------+-----------------------------------+-----------------+ | 0-12 | Unassigned | This document | +------------+-----------------------------------+-----------------+ | 14 | L-flag: Link co-routed | This document | +------------+-----------------------------------+-----------------+ | 15 | N-flag: Node co-routed | This document | +------------+-----------------------------------+-----------------+¶
The security considerations described in [RFC5440], [RFC8231], [RFC8281], [RFC8664], [RFC9256], [RFC9862] and [RFC9863] are applicable to this specification.¶
As per [RFC8231], 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) [RFC8253] [I-D.ietf-pce-pceps-tls13] as per the recommendations and best current practices in [RFC9325].¶
All manageability requirements and considerations listed in [RFC5440], [RFC8231], [RFC8664], and [RFC9256] apply to the PCEP protocol extensions defined in this document. In addition, the requirements and considerations listed in this section apply.¶
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 Section 4).¶
It is expected that a future version of the PCEP YANG module [I-D.ietf-pce-pcep-yang] will be extended to include the PCEP extensions defined in this document.¶
The mechanisms defined in this document do not introduce any new liveness detection or monitoring requirements in addition to those already defined in [RFC5440] and [RFC8231].¶
In addition to the verification requirements in [RFC5440] and [RFC8231], 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, backup information, and opposite-direction path associations.¶
An implementation SHOULD provide a mechanism to log and display the new PCEP errors defined in this document¶
The PCEP extensions defined in this document do not impose any new requirements on other protocols.¶
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.¶
Consider the following sample SR Policy.¶
SR policy POL1 <headend, color, endpoint>
Candidate Path CP1 <protocol-origin = 20, originator-asn = 100,
originator-address = 192.0.2.1,
discriminator = 1>
Preference 200
Weight W1, SID-List1 <SID11...SID1i>
Weight W2, SID-List2 <SID21...SID2j>
Candidate Path CP2 <protocol-origin = 20, originator-asn = 100,
originator-address = 198.51.100.1,
discriminator = 2>
Preference 100
Weight W3, SID-List3 <SID31...SID3i>
Weight W4, SID-List4 <SID41...SID4j>
¶
As specified in [RFC9862], 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 [RFC8231]) for CP1 can be encoded as:¶
<state-report> =
<LSP PLSP-ID=100>
<ASSOCIATION>
<END-POINT>
<PATH-ATTRIB Path ID=1 <WEIGHT-TLV Weight=W1>>
<ERO SID-List1>
<PATH-ATTRIB Path ID=2 <WEIGHT-TLV Weight=W2>>
<ERO SID-List2>
¶
The state-report for CP2 can be encoded as:¶
<state-report> =
<LSP PLSP-ID=200>
<ASSOCIATION>
<END-POINT>
<PATH-ATTRIB Path ID=1 <WEIGHT-TLV Weight=W3>>
<ERO SID-List3>
<PATH-ATTRIB Path ID=2 <WEIGHT-TLV Weight=W4>>
<ERO SID-List4>
¶
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¶
<PATH-ATTRIB Path ID=1 <WEIGHT-TLV Weight=W1>>¶
means that this is PATH-ATTRIB object with Path ID field set to 1 and with a MULTIPATH-WEIGHT TLV carrying weight of "W1".¶
Suppose there are 3 paths: A, B, C. Where A and B are primary and C is to be used only when A or B fail. Suppose the Path IDs for A, B, C are respectively 1, 2, 3. This would be encoded in a state-report as:¶
<state-report> =
<LSP>
<ASSOCIATION>
<END-POINT>
<PATH-ATTRIB Path ID=1 <BACKUP-TLV B=0, Backup_Paths=[3]>>
<ERO A>
<PATH-ATTRIB Path ID=2 <BACKUP-TLV B=0, Backup_Paths=[3]>>
<ERO B>
<PATH-ATTRIB Path ID=3 <BACKUP-TLV B=1, Backup_Paths=[]>>
<ERO C>
¶
Note that the syntax¶
<PATH-ATTRIB Path ID=1 <BACKUP-TLV B=0, Backup_Paths=[3]>>¶
means that this is PATH-ATTRIB object with Path ID field set to 1 and with a MULTIPATH-BACKUP TLV that has B-flag cleared and contains a single backup path with Backup Path ID of 3.¶
Consider the following Composite Candidate Path.¶
SR policy POL100 <headend = H1, color = 100, endpoint = E1>
Candidate Path CP1 <protocol-origin = 20, originator-asn = 100,
originator-address = 192.0.2.1,
discriminator = 1>
Preference 200
Weight W1, SR policy <color = 1>
Weight W2, SR policy <color = 2>
¶
This is signaled in PCEP as:¶
<LSP PLSP-ID=100>
<ASSOCIATION>
<END-POINT>
<PATH-ATTRIB Path ID=1
<WEIGHT-TLV Weight=W1>
<COLOR-TLV Color=1>>
<ERO (empty)>
<PATH-ATTRIB Path ID=2
<WEIGHT-TLV Weight=W2>
<COLOR-TLV Color=2>>
<ERO (empty)>
¶
Consider the two opposite-direction SR Policies between endpoints H1 and E1.¶
SR policy POL1 <headend = H1, color, endpoint = E1>
Candidate Path CP1
Preference 200
Bidirectional Association = A1
SID-List = <H1,M1,M2,E1>
SID-List = <H1,M3,M4,E1>
Candidate Path CP2
Preference 100
Bidirectional Association = A2
SID-List = <H1,M5,M6,E1>
SID-List = <H1,M7,M8,E1>
SR policy POL2 <headend = E1, color, endpoint = H1>
Candidate Path CP1
Preference 200
Bidirectional Association = A1
SID-List = <E1,M2,M1,H1>
SID-List = <E1,M4,M3,H1>
Candidate Path CP2
Preference 100
Bidirectional Association = A2
SID-List = <E1,M6,M5,H1>
¶
The state-report for POL1, CP1 can be encoded as:¶
<state-report> =
<LSP PLSP-ID=100>
<BIDIRECTIONAL ASSOCIATION = A1>
<PATH-ATTRIB Path ID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=3>>
<ERO <H1,M1,M2,E1>>
<PATH-ATTRIB Path ID=2 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=4>>
<ERO <H1,M3,M4,E1>>
<PATH-ATTRIB Path ID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=1>>
<ERO <E1,M2,M1,H1>>
<PATH-ATTRIB Path ID=4 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=2>>
<ERO <E1,M4,M3,H1>>
¶
The state-report for POL1, CP2 can be encoded as:¶
<state-report> =
<LSP PLSP-ID=200>
<BIDIRECTIONAL ASSOCIATION = A2>
<PATH-ATTRIB Path ID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=3>>
<ERO <H1,M5,M6,E1>>
<PATH-ATTRIB Path ID=2 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=0>>
<ERO <H1,M7,M8,E1>>
<PATH-ATTRIB Path ID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=1>>
<ERO <E1,M6,M5,H1>>
¶
The state-report for POL2, CP1 can be encoded as:¶
<state-report> =
<LSP PLSP-ID=100>
<BIDIRECTIONAL ASSOCIATION = A1>
<PATH-ATTRIB Path ID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=3>>
<ERO <E1,M2,M1,H1>>
<PATH-ATTRIB Path ID=2 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=4>>
<ERO <E1,M4,M3,H1>>
<PATH-ATTRIB Path ID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=1>>
<ERO <H1,M1,M2,E1>>
<PATH-ATTRIB Path ID=4 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=2>>
<ERO <H1,M3,M4,E1>>
¶
The state-report for POL2, CP2 can be encoded as:¶
<state-report> =
<LSP PLSP-ID=200>
<BIDIRECTIONAL ASSOCIATION = A2>
<PATH-ATTRIB Path ID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=3>>
<ERO <E1,M6,M5,H1>>
<PATH-ATTRIB Path ID=2 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=0>>
<ERO <H1,M7,M8,E1>>
<PATH-ATTRIB Path ID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=1>>
<ERO <H1,M5,M6,E1>>
¶
Thanks to Adrian Farrel for shepherding this document, Dhruv Dhody for ideas and discussion, and Giuseppe Fioccola, Italo Busi, Yuan Yaping, and Cheng Li for their reviews.¶
Bhupendra Yadav Ciena Email: byadav@ciena.com Gyan Mishra Verizon Inc. Email: gyan.s.mishra@verizon.com Zafar Ali Cisco Systems Email: zali@cisco.com Andrew Stone Nokia Email: andrew.stone@nokia.com Chen Ran ZTE Email: chen.ran@zte.com.cn¶