Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR)

describes the Path Computation Element (PCE) Communication Protocol (PCEP). PCEP enables the communication between a Path Computation Client (PCC) and a PCE, or between PCE and PCE, for the purpose of computation of Multiprotocol Label Switching (MPLS) as well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP) characteristics. specifies a set of extensions to PCEP to enable stateful control of TE LSPs within and across PCEP sessions in compliance with . It includes mechanisms to effect LSP State Synchronization between PCCs and PCEs, delegation of control over LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions. The model of operation where LSPs are initiated from the PCE is described in . specify the procedures and PCEP protocol extensions for using the PCE as the central controller for static LSPs, where LSPs can be provisioned as explicit label instructions at each hop on the end-to-end path. Segment routing (SR) leverages the source routing and tunneling paradigms and supports steering packets into an explicit forwarding path at the ingress node. An SR path needs to be identified in some use cases such as performance measurement. In order to identify an SR path, SR-MPLS Path Segment is identified in while the SRv6 Path Segment is identified in . specifies extensions to the Path Computation Element Protocol (PCEP) for SR networks, that allow a stateful PCE to compute and initiate SR-TE paths, as well as a PCC to request, report or delegate SR paths. specifies the PCEP extension to signal candidate paths of the SR Policy. specifies the procedures and PCEP protocol extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers (SR SID distribution in this case), in addition to computing the paths for packet flows in a segment routing network and telling the edge routers what instructions to attach to packets as they enter the network. This document specifies a set of extensions to carry the SR path identification information in PCEP messages . The SR path identifier can be a Path Segment in SR-MPLS and SRv6 , or other IDs that can identify an SR path. Although defines the PCE as the central controller (PCECC) model, where the PCE can instruct each hop (including the egress) on the end-to-end path, PCE (as per , , and ) typically only communicates with the ingress node. However, since the path segment identifies the SR path on the egress node, the PCE must also communicate with the egress node. This document also outlines a mechanism to use the existing stateful message exchange with the egress node to signal both the SR path and the path segment.

This memo makes use of the terms defined in , , and .

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.

This document specifies a mechanism of allocating Path Segment and extends PCEP to encode it in PCEP messages. For supporting Path Segment in PCEP, several TLVs and flags are defined. The formats of the objects and TLVs are described in . The procedures of Path Segment allocation are described in . There are various modes of operations, such as - The Path Segment can be allocated by Egress PCC. The PCE should request the Path Segment from egress PCC by PCInitiate message and inform the ingress PCC by PCUpd message as described in section 5.1.2. The PCE (or the ingress PCC would first request the path segment to PCE) can allocate a Path Segment on its own accord and inform the ingress/egress PCC by PCInitiate or PCUpd message as described in section 5.2.2. Ingress PCC can also request PCE to allocate the Path Segment, in this case, the PCE would either allocate and inform the assigned Path Segment to the ingress/egress PCC using PCInitiate or PCUpd message, or first request egress PCC for Path Segment and then inform it to the ingress PCC as described in section 5.1.1. The path information to the ingress PCC and PCE is exchanged via an extension to and . The Path Segment information (for SR-MPLS) to the egress PCC can be informed via an extension to the PCECC-SR procedures . For the PCE to allocate a Path Segment on its own, the PCE needs to be aware of the MPLS label space from the PCCs. This is done via mechanism as described in . Otherwise, the PCE should request the egress PCC for Path Segment allocation.

defined a new Path Setup Type (PST) and SR-PCE-CAPABILITY sub-TLV for SR-MPLS. PCEP speakers use this sub-TLV to exchange information about their SR capability. The TLV defines a Flags field . This document adds an additional flag for Path Segment allocation, as follows - P (Path Segment Identification bit): A PCEP speaker sets this flag to 1 to indicate that it has the capability to encode SR path identification (Path Segment, as per ).

defined a new Path Setup Type (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use this sub-TLV to exchange information about their SRv6 capability. This document adds an additional flag for Path Segment allocation, as follows - P (Path Segment Identification bit): A PCEP speaker sets this flag to 1 to indicate that it has the capability to encode SRv6 Path Segment ).

Along with the SR sub-TLVs, the PCECC Capability as per should be advertised if the PCE allocates the Path Segment and acts as a Central Controller that manages the Label space. The PCECC Capability should be advertised on the egress PCEP session, along with the SR sub-TLVs. This is needed to ensure that the PCE can use the PCECC objects/mechanism to request/inform the egress PCC of the Path Segment as described in .

The LSP Object is defined in Section 7.3 of . defines a new P flag in the LSP object for the PCE-allocated binding label/SID. The same flag can also be used for the Path Segment as described here - A PCC would set this bit to 1 and include a PATH-SEGMENT TLV to request for allocation of Path Segment by the PCE in the PCEP message. A PCE would also set this bit to 1 and include a PATH-SEGMENT TLV to indicate that the Path Segment is allocated by PCE and encoded in the PCEP message towards PCC. Further, a PCE would set this bit to 0 and include a PATH-SEGMENT TLV to indicate that the Path Segment should be allocated by the PCC as described in .

The PATH-SEGMENT TLV is an optional TLV for use in the LSP Object for Path Segment allocation. The type of this TLV is to be allocated by IANA (TBA4). The format is as shown below.

The type (16-bit) of the TLV is TBA4 (to be allocated by IANA). The length (16-bit) has a variable length. The value contains the following fields: ST (The Segment type - 8 bits): The ST field specifies the type of the Path Segment field, which carries a Path Segment corresponding to the SR path. 0: MPLS Path Segment, which is an MPLS label as defined in . The PST type MUST be set to SR (MPLS). 1: SRv6 Path Segment, which is a 16-octet value as defined in . The PST type MUST be set to SRv6. 2-255: Reserved for future use. Flags (8 bits): One flag is currently defined: L-Bit (Local/Global - 1 bit): If set, then the Path Segment carried by the PATH-SEGMENT TLV has local significance. If not set, then the Path Segment carried by this TLV has global significance (i.e. Path Segment is global within an SR domain). The unassigned bits MUST be set to 0 and MUST be ignored at receipt. Reserved (16 bits): MUST be set to 0 and MUST be ignored at receipt. Path Segment: The Path Segment of an SR path. The Path Segment type is indicated by the ST field. When the ST is 0, it is a MPLS Path Segment in the MPLS label format. When the ST is 1, the path segment is a 16-octet value. In general, only one instance of PATH-SEGMENT TLV will be included in LSP object. If more than one PATH-SEGMENT TLV is included, the first one is processed and others MUST be ignored. Multiple Path Segment allocation for use cases like alternate-making will be considered in future version of this draft. When the Path Segment allocation is enabled, a PATH-SEGMENT TLV MUST be included in the LSP object. If the label space is maintained by PCC itself, and the Path Segment is allocated by Egress PCC, then the PCE should request the Path Segment from Egress PCC as described in . In this case, the PCE should send a PCUpdate or PCInitiate message to the egress PCC to request the Path Segment. The P-flag in LSP should be unset in this case. If a PCEP node does not recognize the PATH-SEGMENT TLV, it would behave in accordance with and ignore the TLV. If a PCEP node recognizes the TLV but does not support the TLV, it MUST send PCErr with Error-Type = 2 (Capability not supported).

The FEC Object is used to specify the FEC information and carried within PCInitiate or PCRpt message for the PCECC-SR operations. The PCE MUST inform the Path Identification information to the Egress PCC. To do this, this document extends the procedures of by defining a new FEC object type for Path. FEC Object-Type is TBA6 'Path'.

One or more following TLV(s) are allowed in the 'path' FEC object - SYMBOLIC-PATH-NAME TLV: As defined in , it is a human-readable string that identifies an LSP in the network. LSP-IDENTIFIERS TLVs: As defined in , it is optional for SR, but could be used to encode the source, destination and other identification information for the path. SPEAKER-ENTITY-ID TLV: As defined in , a unique identifier for the PCEP speaker, it is used to identify the Ingress PCC. Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of each TLV is processed, if more than one TLV of each type is included, the first one is processed and others MUST be ignored.

The Central Control Instructions (CCI) Object is used by the PCE to specify the forwarding instructions as defined in . Further defined a CCI object type for SR. The Path Segment information is encoded directly in the CCI SR object. The Path Segment TLV as described in the , MUST also be included in the CCI SR object as the TLV (as it includes additional information regarding the Path Segment identifier). The C flag in CCI object is used to indicate if the allocation needs to be done by the PCC.

The defines the PATH-ATTRIB object, which carries per-path information and serves as a separator between multiple ERO/RRO objects, enabling the encoding of multiple segment lists in a Candidate Path, as described in . The Path Segment TLV can be optionally included in the PATH-ATTRIB object to associate a segment list with the Path Segment Identifier (PSID). It is important to note that the Path Segment TLV in the PATH-ATTRIB object applies to the path (the immediately following ERO/RRO), whereas the Path Segment TLV in the LSP object applies to all paths in the PCEP message. If the PSID is encoded in the PATH-ATTRIB object, it MUST be used to identify the SR path. The usage of P flag in the LSP object for Path Segment as specified in Section 4.2 also applies to all PSIDs encoded in the PATH-ATTRIB object.

The Path Segment allocation and encoding is as per the Stateful PCE operations for segment routing. The procedures are as per the corresponding extensions defined in and (which are further based on and ). The additional operations for Path Segment are defined in this section. To notify (or request) the Path Segment to the Egress PCC, the procedures are as per the PCECC-SR (which is based on ). The additional operations are defined in this section.

As defined in , a Path Segment can be allocated by the egress PCC. In this case, the label space is maintained on the PCC itself. This section describes the mechanism of Path Segment allocation by using PCInitiate and PCUpd message in Stateful PCE model.

The ingress PCC could request the Path Segment to be allocated by the PCE via PCRpt message. The delegate flag (D-flag) MUST also be set for this LSP. Also, the P-flag in the LSP object MUST be set. On receiving a delegation request with Path Segment allocation request from an ingress PCC, a stateful PCE requests the egress PCC to allocate a Path Segment. The PATH-SEGMENT TLV MUST be included in an LSP object in the PCInitiate message sent from the PCE to the egress to request Path Segment allocation by the egress PCC. The P flag in LSP object MUST be set to 0. This PCInitiate message to egress PCC would be the similar to the one sent to ingress PCC as per , but the egress PCC would only allocate the Path Segment and would not trigger the LSP initiation operation (as it would be the egress for this LSP). The ASSOCIATION object MUST also be carried in PCInitiate message to indicate the SR policy association parameters as per , if this SR path belongs to an SR policy. If the value of Path Segment is 0x0, it indicates that the PCE is requesting a Path Segment for this LSP. If the Path Segment is set to a value 'n' and the P flag is unset in the LSP object, it indicates that the PCE requests a specific value 'n' of Path Segment. If the Path Segment is allocated successfully, the egress PCC reports the Path Segment via PCRpt message with PATH-SEGMENT TLV in LSP object. Else, it MUST send a PCErr message with Error-Type = TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If the value of Path Segment is valid, but the PCC is unable to allocate the Path Segment, it MUST send a PCErr message with Error-Type = TBA7 ("Path SID failure") and Error Value = 2 ("Unable to allocate the specified label/SID"). Once the PCE receives the PCRpt message, it can obtain the Path Segment information from the egress PCC and then update the path with Path Segment by sending PCUpd message to the ingress PCC. If the Path Segment is updated successfully, the ingress PCC will acknowledge with a PCRpt message to the PCE. In case of error, an PCErr message with Error-Type = TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST roll back the Path Segment value to the previous value (if any) by sending a PCUpd message to synchronize with the egress PCC.

| | Delegate | Delegate=1 | | | P=1 |2) PCE update | | | the LSP-DB and | | | request Path SID | | | | | | --- PCInitiate ---> | Egress | | PATH-SEGMENT | allocates | | TLV in LSP | a Path-SID | | | from its | | <----- PCRpt ------ | space | | Path SID | | | | |<---- PCUpd ---- |3)Paths update with | | PATH-SEGMENT TLV | Path SID | | | | 4) LSP State | ----- PCRpt ---> | | Report | | | | | | ]]> If the ingress PCC wishes to withdraw or modify a previously reported Path Segment value, it MUST send a PCRpt message without any PATH-SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path Segment respectively. In this case, the PCE should synchronize with egress PCC via PCUpd message. The Path Segment MUST be withdrawn when the corresponding LSP is removed. When the LSP is deleted, the PCE MUST request the egress PCC to withdraw the LSP and associated Path Segment via PCInitiate message with the R flag is set in the SRP object. If an egress PCC receives a valid Path Segment value from a PCE which is different than the current Path Segment, it MUST try to allocate the new value. If the new Path Segment is successfully allocated, the egress PCC MUST report the new value to the PCE. Otherwise, it MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID failure") and Error Value = 2 ("Unable to allocate the specified label/SID").

A stateful PCE also can initiate or update an LSP with Path Segment actively via requesting the egress PCC to allocate a Path Segment. If a PCE wishes to modify a previously requested Path Segment value or allocate a Path Segment for an PCE-Initiated LSP, it MUST request the egress PCC to allocate a new value by sending a PCUpd message to the egress PCC with PATH-SEGMENT TLV containing the new Path Segment value. Also, the P flag in LSP object is unset. Absence of the PATH-SEGMENT TLV in PCUpd message means that the PCE wishes to withdraw the Path Segment. The mechanism of requesting Path Segment is as per . Once the PCE receives the PCRpt message, it can obtain the Path Segment information from the egress PCC and then update or initiate an LSP with Path Segment. If the SR-Path is setup, the ingress PCC will acknowledge with a PCRpt message to the PCE. In case of error, as described in , an PCErr message will be sent back to the PCE. The PCE MUST request the egress PCC to withdraw the LSP and associated Path Segment via PCInitiate message with the R flag is set in the SRP object. If the Path Segment is updated successfully, the ingress PCC will acknowledge with a PCRpt message to the PCE. In case of error, an PCErr message with Error-Type = TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST roll back the Path Segment value to the previous value (if any) by sending a PCUpd message to synchronize with the egress PCC.

| | Delegate if| Delegate=1 | | the LSP exists| |2)PCE actively update| | | the LSP-DB and | | | request Path SID | | | | | | --- PCInitiate ---> | Egress | | PATH-SEGMENT | allocates | | TLV in LSP | a Path-SID | | | from its | | <----- PCRpt ------ | space | | Path SID | | | | |<-- PCUpd/PCInit -- |3)Paths update with | | PATH-SEGMENT TLV | Path SID | | | | 4) LSP State | ----- PCRpt ---> | | Report | | | | | | ]]>

For allocating the Path Segments to SR paths by the PCEs, the PCE controlled label space MUST be known at PCEs via configurations or any other mechanisms. The PCE controlled label spaces MAY be advertised as described in .

The PCE could allocate the Path Segment on its own for a PCE-Initiated (or delegated LSP). The allocated Path Segment needs to be informed to the Ingress and Egress PCC. The PCE would use the PCInitiate message or PCUpd message towards the Ingress PCC and MUST include the PATH-SEGMENT TLV in the LSP object. The PCE would further inform the egress PCC about the Path Segment allocated by the PCE using the PCInitiate message as described in .

| (Confirm) | | | | |3) PCE informs the | --- PCInitiate ---> | | Path SID to Egress| FEC=Path | | | | | | <-------- PCRpt --- | | | | ]]>

The ingress PCC could request the Path Segment to be allocated by the PCE via PCRpt message as per . The delegate flag (D-flag) MUST also be set for this LSP. Also, the P-flag in the LSP object MUST be set. A PATH-SEGMENT TLV MUST be included in the LSP object. If the value of Path Segment is 0x0, it indicates that the Ingress PCC is requesting a Path Segment for this LSP. If the Path Segment is set to a value 'n', it indicates that the ingress PCC requests a specific value 'n' of Path Segment. If the Path Segment is allocated successfully, the PCE would further respond to Ingress PCC with PCUpd message as per and MUST include the PATH-SEGMENT TLV in a LSP object. Else, it MUST send a PCErr message with Error-Type = TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If the value of Path Segment is valid, but the PCC is unable to allocate the Path Segment, it MUST send a PCErr message with Error-Type = TBA7 ("Path SID failure") and Error Value = 2 ("Unable to allocate the specified label/SID"). The active PCE would allocate the Path Segment as per the PATH-SEGMENT flags and in case PATH-SEGMENT is not included, the PCE MUST act based on the local policy. The PCE would further inform the egress PCC about the Path Segment allocated by the PCE using the PCInitiate message as described in .

| | Delegate | Delegate=1 | | | P=1 |2) PCE update | | | the LSP-DB and | | | allocate Path SID | |<---- PCUpd ---- |3)Paths update with | | PATH-SEGMENT TLV | Path SID | | | | 4) LSP State Report | ----- PCRpt ---> | | | | | |5) PCE informs the | --- PCInitiate ---> | | Path SID to Egress| FEC=Path | | | | | | <-------- PCRpt --- | | | | ]]>

As described in , in an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped. So that no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node cannot determine from which SR path the packet comes. For this reason, it introduces the Path Segment. Apart from allocation and encoding of the Path Segment (described in this document) for the LSP, it would also be included in the SID/Label stack of the LSP (usually for processing by the egress). To support this, the Path Segment MAY also be a part of SR-ERO as prepared by the PCE as per . The PCC MAY also include the Path Segment while preparing the label stack based on the local policy and use-case. It is important that the PCE learns the Maximum SID Depth (MSD) that can be imposed at each node/link of a given SR path to ensure that the SID stack depth does not exceed the number of SIDs the node is capable of imposing. As a new type of segment, Path Segment will be inserted in the SID list just like other SIDs. Thus, the PCE needs to consider the affect of Path Segment when computing a LSP with Path Segment allocation. Similar to SR-MPLS, when SRv6 Path Segment is implemented, SRv6 dataplane is required to be supported on PCCs.

[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".

The feature of SR-MPLS Path Segment has been developed based on Huawei VRP8. Organization: Huawei Implementation: Huawei's Commercial Delivery implementation based on VRP8. Description: The implementation is under development and follows the mechanism as defined in section-5.1.1. Maturity Level: Product Contact: tanren@huawei.com

The feature of SR-MPLS Path Segment has been developed based on Rosng v8. Organization: ZTE Implementation: ZTE's Commercial Delivery implementation based on Rosng v8. Description: The implementation is under development and follows the mechanism as defined in section-5.1.1. Maturity Level: Product Contact: zhan.shuangping@zte.com.cn

SR PCE Capability TLV is defined in , and the registry to manage the Flag field of the SR PCE Capability TLV is requested in . IANA is requested to make the following allocation in the "SR Capability Flag Field" sub-registry.

SRv6 PCE Capability TLV is defined in defined in , and the registry to manage the Flag field of the SRv6 PCE Capability Flags is requested in . IANA is requested to make the following allocation in the aforementioned registry.

defines the LSP object; per that RFC, IANA created a registry to manage the value of the LSP object's Flag field. IANA has allocated a new bit in the "LSP Object Flag Field" sub-registry, as follows:

IANA is requested to add the assignment of a new allocation in the existing "PCEP TLV Type Indicators" sub-registry as follows:

This document requests that a new sub-registry named "PATH-SEGMENT TLV Segment Type (ST) Field" to be created to manage the value of the ST field in the PATH-SEGMENT TLV. New values are assigned by Standards Action .

Further, this document also requests that a new sub-registry named "PATH-SEGMENT TLV Flag Field" to be created to manage the Flag field in the PATH-SEGMENT TLV. New values are assigned by Standards Action . Each bit should be tracked with the following qualities: Bit number (counting from bit 0 as the most significant bit) Capability description Defining RFC

A new PCEP object called FEC is defined in . IANA is requested to allocate a new Object-Type for FEC object in the "PCEP Objects" sub-registry.

IANA is requested to allocate code-points in the "PCEP-ERROR Object Error Types and Values" sub-registry for the following new error-types and error-values:

The security considerations described in ], , and are applicable to this specification. No additional security measure is required. As described and , SR allows a network controller to instantiate and control paths in the network. A rogue PCE can manipulate Path SID allocations to have impact based on the usage of Path SID such as accounting, bi-directional etc. Thus, as per , it is RECOMMENDED that these PCEP extensions 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 (unless explicitly set aside in ).

All manageability requirements and considerations listed in , , and apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section also should be applied.

A PCEP implementation SHOULD allow the operator to configure the policy based on which it allocates the Path SID. This includes the Path SID scope.

The PCEP YANG module is defined in . In future, this YANG module should be extended or augmented to provide the following additional information relating to Path SID. An implementation SHOULD allow the operator to view the Path SID allocated to the LSP as well as Path SID as part of the computed SID list for the SR path.

Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in .

Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in , , and .

Mechanisms defined in this document do not imply any new requirements on other protocols.

Mechanisms defined in , , and also apply to PCEP extensions defined in this document. Further, the mechanism described in this document can help the operator to request control of the LSPs at a particular PCE.

Many thanks for Jeff Tantsura, Khasanov Boris, Aijun Wang,Loa Andersson,Greg Mirsky,Shunwan Zhuang, Huanan Chen, Fengwei Qin, Julien Meuric's professional comements. Best wishes to them and their families in this special period.

The following people have substantially contributed to this document: