Segment Routing over IPv6 Overview
Segment Routing (SR) can be applied on both MPLS and IPv6 data planes. Segment Routing over IPv6 (SRv6) extends Segment Routing support with IPv6 data plane.
In an SR-MPLS enabled network, an MPLS label represents an instruction. The source nodes programs the path to a destination in the packet header as a stack of labels.
SRv6 introduces the Network Programming framework that enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier (SID) in the packet. The SRv6 Network Programming framework is defined in IETF RFC 8986 SRv6 Network Programming.
In SRv6, an IPv6 address represents an instruction. SRv6 uses a new type of IPv6 Routing Extension Header, called the Segment Routing Header (SRH), in order to encode an ordered list of instructions. The active segment is indicated by the destination address of the packet, and the next segment is indicated by a pointer in the SRH.
The SRv6 SRH is documented in IETF RFC IPv6 Segment Routing Header (SRH).
The SRH is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[0] (128-bit IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
...
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[n] (128-bit IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following list explains the fields in SRH:
-
Next header—Identifies the type of header immediately following the SRH.
-
Hdr Ext Len (header extension length)—The length of the SRH in 8-octet units, not including the first 8 octets.
-
Segments left—Specifies the number of route segments remaining. That means, the number of explicitly listed intermediate nodes still to be visited before reaching the final destination.
-
Last Entry—Contains the index (zero based) of the last element of the segment list.
-
Flags— Contains 8 bits of flags.
-
Tag—Tag a packet as part of a class or group of packets like packets sharing the same set of properties.
-
Segment list—128-bit IPv6 addresses representing the nth segment in the segment list. The segment list encoding starts from the last segment of the SR policy (path). That means the first element of the segment list (Segment list [0]) contains the last segment of the SR policy, the second element contains the penultimate segment of the SR policy and so on.
In SRv6, a SID represents a 128-bit value, consisting of the following three parts:
-
Locator: This is the first part of the SID with most significant bits and represents an address of a specific SRv6 node.
-
Function: This is the portion of the SID that is local to the owner node and designates a specific SRv6 function (network instruction) that is executed locally on a particular node, specified by the locator bits.
-
Args: This field is optional and represents optional arguments to the function.
The locator part can be further divided into two parts:
-
SID Block: This field is the SRv6 network designator and is a fixed or known address space for an SRv6 domain. This is the most significant bit (MSB) portion of a locator subnet.
-
Node Id: This field is the node designator in an SRv6 network and is the least significant bit (LSB) portion of a locator subnet.
SRv6 Node Roles
Each node along the SRv6 packet path has a different functionality:
-
Source node—A node that can generate an IPv6 packet with an SRH (an SRv6 packet), or an ingress node that can impose an SRH on an IPv6 packet.
-
Transit node—A node along the path of the SRv6 packet (IPv6 packet and SRH). The transit node does not inspect the SRH. The destination address of the IPv6 packet does not correspond to the transit node.
-
Endpoint node—A node in the SRv6 domain where the SRv6 segment is terminated. The destination address of the IPv6 packet with an SRH corresponds to the end point node. The segment endpoint node executes the function bound to the SID
SRv6 Head-End Behaviors
The SR Headend with Encapsulation behaviors are documented in the IETF RFC 8986 SRv6 Network Programming.
The SR Headend with Insertion head-end behaviors are documented in the following IETF draft:
https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-net-pgm-insertion/
This section describes a set of SR Policy headend behaviors. The following list summarizes them:
-
H.Encaps—SR Headend Behavior with Encapsulation in an SRv6 Policy
-
H.Encaps.Red—H.Encaps with Reduced Encapsulation
-
H.Insert—SR Headend with insertion of an SRv6 Policy
-
H.Insert.Red—H.Insert with reduced insertion
SRv6 Endpoint Behaviors
The SRv6 endpoint behaviors are documented in the IETF RFC 8986 SRv6 Network Programming.
The following is a subset of defined SRv6 endpoint behaviors that can be associated with a SID.
-
End—Endpoint function. The SRv6 instantiation of a Prefix SID [RFC8402].
-
End.X—Endpoint with Layer-3 cross-connect. The SRv6 instantiation of an Adj SID [RFC8402].
-
End.DX6—Endpoint with decapsulation and IPv6 cross-connect (IPv6-L3VPN - equivalent to per-CE VPN label).
-
End.DX4—Endpoint with decapsulation and IPv4 cross-connect (IPv4-L3VPN - equivalent to per-CE VPN label).
-
End.DT6—Endpoint with decapsulation and IPv6 table lookup (IPv6-L3VPN - equivalent to per-VRF VPN label).
-
End.DT4—Endpoint with decapsulation and IPv4 table lookup (IPv4-L3VPN - equivalent to per-VRF VPN label).
-
End.DT46—Endpoint with decapsulation and specific IP table lookup (IP-L3VPN - equivalent to per-VRF VPN label).
-
End.DX2—Endpoint with decapsulation and L2 cross-connect (L2VPN use-case).
-
End.B6.Encaps—Endpoint bound to an SRv6 policy with encapsulation. SRv6 instantiation of a Binding SID.
-
End.B6.Encaps.RED—End.B6.Encaps with reduced SRH. SRv6 instantiation of a Binding SID.
SRv6 Endpoint Behavior Variants
Depending on how the SRH is handled, different behavior variants are defined for the End and End.X behaviors. The End and End.X behaviors can support these variants, either individually or in combinations.
-
Penultimate Segment Pop (PSP) of the SRH variant—An SR Segment Endpoint Nodes receive the IPv6 packet with the Destination Address field of the IPv6 Header equal to its SID address.
A penultimate SR Segment Endpoint Node is one that, as part of the SID processing, copies the last SID from the SRH into the IPv6 Destination Address and decrements the Segments Left value from one to zero.
The PSP operation takes place only at a penultimate SR Segment Endpoint Node and does not happen at non-penultimate endpoint nodes. When a SID of PSP-flavor is processed at a non-penultimate SR Segment Endpoint Node, the PSP behavior is not performed since Segments Left would not be zero.
The SR Segment Endpoint Nodes advertise the SIDs instantiated on them via control plane protocols. A PSP-flavored SID is used by the Source SR Node when it needs to instruct the penultimate SR Segment Endpoint Node listed in the SRH to remove the SRH from the IPv6 header.
-
Ultimate Segment Pop (USP) of the SRH variant—The SRH processing of the End and End.X behaviors are modified as follows:
If Segments Left is 0, then:
-
Update the Next Header field in the preceding header to the Next Header value of the SRH
-
Decrease the IPv6 header Payload Length by 8*(Hdr Ext Len+1)
-
Remove the SRH from the IPv6 extension header chain
-
Proceed to process the next header in the packet
One of the applications of the USP flavor is when a packet with an SRH is destined to an application on hosts with smartNICs implementing SRv6. The USP flavor is used to remove the consumed SRH from the extension header chain before sending the packet to the host.
-
-
Ultimate Segment Decapsulation (USD) variant—The Upper-layer header processing of the End and End.X behaviors are modified as follows:
-
End behavior: If the Upper-layer Header type is 41 (IPv6), then:
-
Remove the outer IPv6 Header with all its extension headers
-
Submit the packet to the egress IPv6 FIB lookup and transmission to the new destination
-
Else, if the Upper-layer Header type is 4 (IPv4)
-
Remove the outer IPv6 Header with all its extension headers
-
Submit the packet to the egress IPv4 FIB lookup and transmission to the new destination
-
Else, process as per Section 4.1.1 (Upper-Layer Header) of IETF RFC 8986 SRv6 Network Programming
-
-
End.X behavior: If the Upper-layer Header type is 41 (IPv6) or 4 (IPv4), then:
-
Remove the outer IPv6 Header with all its extension headers
-
Forward the exposed IP packet to the L3 adjacency J
-
Else, process as per Section 4.1.1 (Upper-Layer Header) of IETF RFC 8986 SRv6 Network Programming
-
One of the applications of the USD flavor is the case of TI-LFA in P routers with encapsulation with H.Encaps. The USD flavor allows the last Segment Endpoint Node in the repair path list to decapsulate the IPv6 header added at the TI-LFA Point of Local Repair and forward the inner packet.
-