Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6)

Segment routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node by inserting an ordered list of instructions, called segments. When segment routing is deployed on an MPLS data plane, called SR-MPLS , a segment identifier (SID) is present as an MPLS label. When segment routing is deployed on an IPv6 data plane, a SID is presented as a 128-bit value, and it can be an IPv6 address of a local interface but it does not have to be. To support SR in an IPv6 network, a Segment Routing Header (SRH) is used. In SR, a path needs to be identified for several use cases such as binding bidirectional paths and end-to-end performance measurement . Additionally, 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 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 ingress node or SR path the packet came. To identify an SR-MPLS path, a Path Segment Identifier is defined in . An SRv6 path could be identified by the content of a segment list. However, the segment list is not be a good key identifier, since the length of a segment list is flexible according to the number of required SIDs. Also, the length of a segment list may be too long to be a key when it contains many SIDs. For instance, if packet A uses an SRH with 3 SIDs while Packet B uses an SRH with 10 SIDs, the key to identify these two paths will be a 384-bits value and a 1280-bits value, respectively. Further, an SRv6 path cannot be identified by the information carried by the SRH in reduced mode as the first SID is not present in the SRH. In the cases that different SRv6 policies use the same segment list in different candidate paths, the traffic of different SRv6 policies are merged on the egress segment node because the segment list in the SRH cannot distinguish the path in different SR policy, resulting in the inability to measure the performance of a specific path within its SRv6 policy. However, an SRv6 policy may need to measure a segment list in its own candidate path, where the packets statistics associated with this segment list is independent with other segment lists in other SRv6 policies even if the same segment list is used. Without a Path ID to specify the path will cause the statistic of the traffic from multiple paths using the same segment list under different SRv6 policies merge into an aggregated result on the egress endpoint node. To solve the above issues, this document defines a new SRv6 segment called the "SRv6 Path Segment Identifier (PSID)", which in total is an 128-bits value, to identify an SRv6 path. Using a 128-bit Path ID has the better processing performance than using a flexible length of Segment list as a path ID. Using an SRv6 PSID is used in reduced mode SRH can solve the problem of cannot identifying a segment list by the reduced segment list, while the overhead is equivalent to the SRH in normal mode. Furthermore, by using SRv6 PSIDs, any SRv6 path within an SRv6 policy can be identified and measured, even when they use the same segment list.

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.

PM: Performance Measurement. SID: Segment Identifier. SR: Segment Routing. SR-MPLS: Segment Routing with MPLS data plane. SRH: Segment Routing Header. SR path: A path described by a segment list . SRv6 path: A path described by an SRv6 segment list. PSID: Path Segment Identifier. PSP: Penultimate Segment Popping. Further, this document makes use of the terms defined in and .

Similar to SR-MPLS PSID , SRv6 PSID may also be used to identify an SRv6 Path in some use cases: Performance Measurement: For Passive measurement , path identification at the measuring points is the pre-requisite . SRv6 PSIDs can be used by the measuring points (e.g., the ingress/egress nodes of an SRv6 path) or a centralized controller to correlate the packets counts/timestamps, then packet loss/delay can be calculated. Bi-directional SRv6 Path Association: In some scenarios, such as mobile backhaul transport networks, there are requirements to support bidirectional paths. Like SR-MPLS , to support bidirectional SRv6 paths, a straightforward way is to bind two unidirectional SRv6 paths to a single bidirectional path. SRv6 PSIDs can be used to correlate the two unidirectional SRv6 paths at both ends of the path. defines how to use PCEP and PSID to initiate a bidirectional SR path. End-to-end Path Protection: For end-to-end 1+1 path protection (i.e., Live-Live case), the egress node of an SRv6 path needs to know the set of paths that constitute the primary and the secondary(s), to select the primary packet for onward transmission, and to discard the packets from the secondary(s), so each SRv6 path needs a unique path identifier at the egress node, which can be an SRv6 PSID.

As defined in , an SRv6 segment identifier is a 128-bit value. To identify an SRv6 path, this document defines a new segment called SRv6 Path Segment, and the Path Segment Identifier (PSID) is a 128-bit value. An SRv6 PSID MUST NOT be used for routing so it MUST NOT be copied to the IPv6 destination address. states that the SR segment endpoint node creates Forwarding Information Base (FIB) entries for its local SIDs (without constraining the details of implementation). In order to provide a new independent 128-bit ID space for PSID, the PSID is required to be stored separating from the other SIDs (for example in a different table from the FIB). A PSID is used for identify a SRv6 path represented by a segment list. On the egress node, the statistics of this path will be identified by its PSID. In normal cases, each segment list will have a its own PSID with different value. However, depending on the use case, different segment list might use the same value PSID, causing the statistics of these SRv6 path are merged on the egress node. For example, a use case may use the same PSID for some or all the segment list under a Candidate path, or even some or all Candidate Path within an SRv6 policy. Moreover, a segment list may be identified by more than one PSID if needed. For example, the same segment list in different Candidate Path or SR policy may use different PSIDs for identifying its path to distinguish the statistics data of other SRv6 path in other SRv6 policies using the same segment list. This document does not define and limit the value allocation scheme for PSID, the value allocation scheme is designed depending on the use cases.

As mentioned above, an SRv6 PSID is stored independent from the FIB, so that the total 128-bit can be programmed in use. To avoid the value conflict, the value of a PSID MUST be global unique within the SRv6 domain.

| Figure 1. 128-bit PSID ]]> A use case can define its specific structure of the PSID. In order to reuse the existing mechanism of SRv6 control plane and forwarding plane, this document suggests a structure of SID reusing the structure of a SID defined in . A future document MAY add further new formats for the SRv6 PSID, provided the SRv6 PSID value remains unique irrespective of the format.

As per , an SRv6 SID consists of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). L, the locator length, is flexible, and an operator is free to use the locator length of their choice. F and A may be any value as long as L+F+A <= 128. When L+F+A is less than 128, then the remaining bits of the SID MUST be zero. SRv6 PSID follows this structure, where the LOC part identifies the egress node that allocates the PSID, and the FUNCT part is a unique local ID to identify an SRv6 Path and its endpoint behavior, which is END.PSID (End Function with Path Segment Identifier). The code point of END.PSID is 0x0064. The Argument part is set as 0 by default. Future use cases may define the detailed usage of Arguments part. Although the PSID is not used for forwarding, its structure is suggested to follows the standard SRv6 SID format to ensure uniqueness, simplify management, and maintain consistency with other SRv6 behaviors.

| Figure 2. PSID Format following LOC:FUNCT:ARG ]]>

This section describes the SRv6 PSID encoding in SRH. The SRv6 PSID MUST appear only once in the segment list. As depicted in figure.3, PSID MUST be placed at SegmentList[n] in the SRH, where n equals SRH.LastEntry.

To enable the carriage of optional generic metadata within the Segment Routing Header, this document defines a G-flag (Generic Metadata Flag) in the SRH Flags field. This flag indicates that the last entry of the Segment List contains a 128-bit metadata object rather than a standard routing SID. The allocation of the G-flag bit is detailed in the IANA Considerations section.

Field Definitions: A specific bit (TBA1) within the 8-bit Flags field.

Set (1): Indicates that Segment List[n] (the last entry) contains a Generic Metadata object. The content of this 128-bit field is not treated as a standard IPv6 destination address for routing lookup but as an opaque identifier or data payload defined by the specific application (e.g., a Path Segment Identifier).
Unset (0): Indicates that Segment List[n] is not valid.

When the G-flag is set, this 128-bit field at Segment List[n] (Generic Metadata) carries the metadata value. The internal structure of these 128 bits is not fixed by this base mechanism. It is determined by the specific use case (e.g., for PSID, it follows the Locator:Function:Argument structure; for other future applications, it may follow different encoding rules). SRH.G-flag processing can be enabled or disabled by configuration on devices, it can be done by CLI, NETCONF YANG or other ways, and this is out of the scope of this document. Some use cases only require the ingress node and egress node to process the PSID, while the intermediate nodes ignore the PSID. Some use cases may require all the segment nodes along the path to process the PSID. In order to distinguish if the PSID processing is supported on the intermediate nodes, implementations SHOULD support mechanisms to control whether intermediate SR Endpoint nodes process the PSID. Such control MAY be configured per device or per interface, depending on implementation capabilities. The pseudo code of PSID processing is described as below. The intermediate node processing of PSID can be enabled by configuration like CLI , NETCONF YANG or other ways.

Ref1 : When SRv6 compression is not supported, SRH.SL==0 indicates the node is the egress node, which is the last segment endpoint node. When SRv6 compression is supported, an implementation identifies a node as the egress node by checking whether the SID is the last SID in the last C-SID container in the SRH as per . This document does not define the details of pseudo code of the implementation. Ref2: The SRv6 PSID processing is associated with the specific application, such as SRv6 PSID based Performance measurement, so this is out of the scope of this document. When the SRH.G-flag is set, it indicates that a PSID is encoded in the SRH and needs to be processed when processing the packet. In the cases that the intermediate processing of PSID is disabled, a node will process the PSID only when it is the last segment endpoint node. In this case, when the nodes are an intermediate node, it ignores the processing of PSID. When the intermediate processing is enabled, all the segment endpoint nodes along the path are able to process the PSID if a PSID is encoded in the SRH. There might be some use cases that metadata of the packets need to be collected and processed on the intermediate nodes, especially for the stateful use cases. The details of these use cases are out of the scope of this document, and might be described in other documents in the future.

A Path Segment is a segment on the egress node, and its identifier can be allocated through several ways, such as CLI configuration on the egress node, or allocated from the central controller by using BGP , PCEP or other ways. The mechanisms of allocating and distributing a PSID are out of scope of this document. When a PSID is allocated on the egress, it MUST be distributed to the ingress node of the path that identified by the PSID. In this case, only the egress will process the PSID, and other nodes specified by SIDs in the segment list do not know how to process the PSID. Depending on the use case, a PSID may be distributed to the SRv6 nodes along the SRv6 path. In this case, the SRv6 nodes that learned the PSID may process the PSID depending on the use case. This is out of the scope of this document, and may be studied in the future if needed.

When the SRv6 PSID is used, the following rules also apply: The SRv6 PSID MUST appear only once in a segment list, and it MUST appear as the last entry. Placing an SRv6 PSID at any other location in the SID list will result in unpredictable forwarding behavior. Only the one that appears as the last entry in the SID list will be processed. The ingress needs to set the G-flag when an SRv6 PSID is inserted in the SID List. Nodes that support SRv6 PSID processing will inspect the last entry to process SRv6 PSID when the G-flag is set. When the G-flag is unset, the nodes will not inspect the last entry. When an SRv6 PSID is inserted and the Last Entry is greater than 0, the SL MUST be initiated to be less than the value of Last Entry, and MUST NOT point to SRv6 PSID. For instance, when the Last entry is 4, the SID List[4] is the SRv6 PSID, so the SL MUST be set to 3 or other numbers less than Last entry. When an SRv6 PSID is inserted and the PSID is the only segment in the SRH(in the case that only one NEXT-C-SID container is used in the IPv6 DA), then the SL and Last entry are set to 0. The SRv6 PSID MUST NOT be copied to the IPv6 destination address. Penultimate Segment Popping (PSP, as defined in ) MUST be disabled for the penultimate Segment in the SRH. In other words, a SID with PSP flavor MUST NOT be used in the penultimate segment in the SRH to avoid removing the SRH before reaching the egress node.

This I-D requests the IANA to allocate, within the "SRv6 Endpoint Behaviors" sub-registry belonging to the top-level "Segment-routing with IPv6 data plane (SRv6) Parameters" registry, the following allocations:

This document also requests IANA to allocate bit position TBA1 within the "Segment Routing Header Flags" registry defined in [RFC8402].

This document does not introduce additional security requirements and mechanisms other than the ones described in . Similar to SR-MPLS PSID , the data plane processing of a PSID is a local implementation of an SRv6 segment endpoint node, which follows the same logic of an existing SRv6 data plane. In this document, only the egress node and the ingress node of the associated path will learn the information of a PSID. The intermediate nodes of this path will not learn it. However, in some cases, the whole Segment list with PSID may be used in a sub-set of a longer path. In this case, the whole segment list may be shared to the ingress node of the longer path. Similar to other SIDs defined in , the PSID must be distributed in a trusted domain under the considerations defined in Section 8.2 of . A PSID is used within an SRv6 trusted domain and must not leak outside the domain; therefore, no new security threats are introduced compared to current SRv6. As per , SR domain boundary routers MUST filter any external traffic destined to an SID associated with a segment within the trusted domain; this applies to a PSID as well. Other security considerations of SRv6 described in Section 8.2 of [RFC8402] apply to this document. The distribution of a PSID from an egress node to an ingress node is performed within an SR-trusted domain, and it is out of the scope of this document. The details of the mechanism and related security considerations will be described in other documents.

The authors would like to thank Adrian Farrel, Stefano Previdi, Zafar Ali, Lijie Deng, Zehua Hu, Joel Halpern, Yao Liu, Greg Mirsky, Quan Xiong, Changwang Lin, Weier Li and Xinyue Zhang for their valuable comments and suggestions.