Path Segment Identifier in MPLS-Based Segment Routing Networks
Extracted elements (22)
A PSID enables passive performance measurement by allowing ingress and egress nodes (or a centralized controller) to correlate packet counts and timestamps for a specific SR path, making packet loss and delay calculation possible end-to-end.
A PSID is assigned from the SRLB of the egress node — making it a local segment — so only the ingress and egress nodes of the associated path learn the PSID value; intermediate nodes do not, limiting its exposure.
For end-to-end 1+1 path protection (Live-Live), the egress node needs unique per-path identifiers to select primary path packets and discard secondary ones; a PSID allocated by the egress node serves this role in SR-MPLS.
In SR-MPLS, segment labels are swapped or popped as a packet transits the network, leaving no label or only the last label at the egress node. This makes it impossible for the egress to determine which SR path the packet traversed, motivating the PSID as a persistent path identifier.
PSIDs can be nested with Binding SIDs (BSIDs) to achieve both sub-path and end-to-end path monitoring in multi-domain scenarios. Each sub-path carries an s-PSID, while the end-to-end path is identified by an e-PSID appended after the list of BSIDs.
PSIDs support bidirectional SR paths by identifying and correlating traffic for two unidirectional SR paths at both endpoints of a bidirectional path, since the current SR architecture treats SR paths as unidirectional.
Behavior relating to the use of an explicit null label directly preceding the PSID is explicitly undefined in this document.
Similar to Synonymous Flow Labels (RFC 8957), the introduction of a PSID to an existing flow may cause that flow to take a different path under ECMP; therefore the SFL considerations in Section 5 of RFC 8957 also apply to PSIDs.
The Maximum SID Depth (MSD) signaled per RFC 8491 includes the PSID label in the total count of MPLS labels that can be imposed; path computation must account for this when determining if a computed path's SID stack fits within the ingress node's capability.
Under ECMP conditions, SR packets may traverse multiple paths, meaning the PSID can only identify the SID list rather than the actual forwarding path. Introducing a PSID to an existing flow may also cause it to take a different ECMP path, potentially invalidating performance measurement results.
When an Entropy Label (EL) is used per RFC 6790, the EL and ELI are placed before the tunnel label and therefore do not interfere with the PSID, which is placed below the last routing segment label.
A PSID MAY be used by the egress node for path identification; per-path state will be maintained in the egress node for use cases such as performance measurement and path protection.
If a PSID is the bottom label, the S bit MUST be set; if the PSID is NOT the bottom label, the S bit MUST be 0.
One PSID MAY be used to identify multiple segment lists, for example to aggregate all segment lists in a candidate path or SR policy for operational purposes.
The egress node MUST pop the PSID. The egress node MAY use the PSID for further processing such as triggering packet counting or timestamping for performance measurement.
The TTL field in the MPLS label stack entry containing a PSID can be set to any value except 0.
When a PSID is used, it MUST immediately follow the last label of the SR path — i.e., it must be inserted after the routing segment pointing to the egress node.
A Path Segment Identifier (PSID) is a single MPLS label assigned from the Segment Routing Local Block (SRLB) of the egress node of an SR path, used to uniquely identify that SR path at the egress node.
A PSID must be used only within an SR-MPLS trusted domain and must not leak outside the domain. SR domain boundary routers MUST filter any external traffic destined to a label associated with a segment within the trusted domain, including PSIDs.
The data plane processing of a PSID follows the same logic as existing MPLS data plane processing and is a local implementation of the ingress or egress node; no new security threats are introduced compared to current SR-MPLS.
When a PSID is used in nested sub-path scenarios (Section 3.4) without BSIDs, the PSID must be distributed in a trusted domain under the considerations defined in Section 8.1 of RFC 8402, since an ingress node that is not the path's own ingress may impose it.
A PSID is encoded as a standard MPLS label stack entry placed immediately after the last routing segment label (Label n) and before the payload. The S bit indicates whether the PSID is the bottom of stack.