Generalized Segment Routing Header

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 the IPv6 data plane, it is called SRv6 . For support of SR, a new routing header called Segment Routing Header (SRH), which contains a list of SIDs and other information, has been defined in . In use cases like Traffic Engineering, an ordered SID List with multiple SIDs is inserted into the SRH to steer packets along an explicit path. The overhead of SIDs (16 bytes per SID) in SRH proposes challenges for packet processing and payload efficiency. proposes a mechanism for reducing the overhead of SRv6 by using the Compressed SID (C-SID) in SRH. However it requires all the middle segment endpoint nodes to support compression. [I-D.cl-spring-generalized-srv6-np] proposes Generalized Segment Routing over IPv6 (G-SRv6) Networking Programming, which supports to encode multiple types of Segments in an SRH, called Generalized SRH(G-SRH). These segments can be called Generalized Segment, and the ID can be Generalized Segment Identifier(G-SID), which may include an SRv6 SID(128 bits), C-SIDs, MPLS labels, or IPv4 tunnel information. Therefore, G-SRv6 does not require all the nodes along the path to be compression capable, which supports incremental deployment, and brings benefits to the networks. Moreover it provides more flexibilities for network programming. This document defines the encapsulation and packet processing of Generalized SRH.

This document makes use of the terms defined in , and , and the reader is assumed to be familiar with that terminology. This document introduces the following new terms: C-SRH: Compressed Segment Routing Header C-SID: Compressed Segment Identifier G-SRH: Generalized Segment Routing Header G-SID: Generalized Segment Identifier.

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.

A G-SID is a 128 bits value, and it can be used for carry multiple types of Segment ID or segment information, so may contain: an SRv6 SID a compression G-SID an MPLS G-SID an IPv4 G-SID

SRv6 SID is a type of G-SID. A G-SID contains a single SRv6 SID, and does not change anything of SRv6 SID.

As per , a C-SID is a sub-set of a compressable SRv6 SID, which can be used for routing the packets in compressed SRv6 network programming. The format of compressable SID and C-SID is shown below. The argument part is specified by use cases, and it is zero by default. It is shared by the compressable SRv6 SIDs in a C-SRv6 sub-path.

|<-FuncID->|<--Argument -->| |<--->| | Different part of Locator Figure 1. 32 bits C-SID in Compressable SRv6 SID ]]> A compression G-SID shown in Figure 2 may contain several C-SIDs and optional padding. when C-SID is a 32 bits value, a compression G-SID can consist of 4 C-SIDs. If the length of C-SIDs in a G-SID is less than 128 bits, then padding is required.

An MPLS G-SID shown in Figure 3 can contain 4 MPLS Label Encapsulations, if number of MPLS Label Encapsulations is less than 4, then padding is required in G-SID to align with 128 bits.

An IPv4 G-SID shown in Figure 4 can contain 128 bits information of IPv4 tunnel. The format of the IPv4 G-SID is shown below.

Generalized Segment Routing Header (G-SRH) is an enhancement of the SRH, and it supports to encode different types of G-SIDs in a single SRH. The format of G-SRH is shown as below.

Where: Next Header, Hdr Ext Len, Routing Type, Segments Left, Last Entry and Tag are the same as those defined in . CL (C-SID Left): 2-bit unsigned integer to indicate the index of C-SID in the Compression G-SID. There can be four 32-bit C-SIDs within a Compression G-SID. Segment List[n]: 128-bit G-SID representing the nth Generalized Segment in the Segment List. In G-SRH, the Generalized Segment can be an SRv6 SID, Compression G-SID, MPLS G-SID, or IPv4 G-SID, etc. Type Length Value (TLV): It is the same as that defined in .

When an SRv6 path travels normal SRv6 domains and compressed SRv6 domains, the SRv6 SID and Compression G-SID(containing C-SIDs) can be encoded in a single G-SRH. For easier understanding, this document assumes that the compressable consists of 96 bits common prefix and 32 bits C-SID, while actually the length of common prefix can be configured as less than 96 to fit the address planning of the networks. The encoding can be shown as follows.

Where: Common Prefix: 96-bit value for the common prefix shared by a group of Compressable SRv6 SIDs. Operators are free to configure the length and the value of the common prefix based on the address planning of their networking. In a Compressable SRv6 SID, when the length of Common prefix is less than 96, and the length of the C-SID is less than 32 bits, the the rest bits can be used as arguments. C-SID: 32-bit compressed SID of a Compressable SRv6 SID. Padding: Must be zero. When the length of C-SIDs within G-SID is less than 128 bits within a compression G-SID, then padding is needed.

The G-SRH support to encode the MPLS labels and SRv6 SID or Compression G-SID within a G-SRH. The G-SRv6 path for crossing SR-MPLS domains can be encoded in the G-SRH as follows:

Where: Label: 32-bit MPLS label. TC: 3-bit value for traffic class of MPLS label encapsulation. S: 1-bit flag to indicate the bottom of MPLS label stack. It can be used for indicating the end of the MPLS label stack. TTL: 8-bit value for TTL of MPLS label encapsulation. Padding: When the number of MPLS labels is less than 4 in an MPLS G-SID, then padding is required to align with 128 bits.

The G-SRv6 path for crossing IPv4 domains can be encoded in the G-SRH as follows:

Where: Type: 4-bit value to indicate the types of IPv4 tunnel. IPv4 Src Address: 32-bit value for the source address of the IPv4 tunnel. IPv4 Dest Address: 32-bit value for the destination address of the IPv4 tunnel. Tunnel Parameters: tunnel parameters of the IPv4 tunnel except the source address and destination address. This document defines the encoding for IPv4 UDP tunnel and VxLAN tunnel. The IPv4 UDP tunnel information encapsulated in the G-SRH is as follows:

Where, Reserved: It is the reserved field and MUST be set as 0. Src Port: 16-bit value for the source port of the IPv4 UDP tunnel. Dest Port: 16-bit value for the destination port of the IPv4 UDP tunnel. The IPv4 VXLAN tunnel information encapsulated in the G-SRH is as follows:

Where, Resv: It is the reserved field and MUST be set as 0. VN ID: 24-bit value for the VN ID of the IPv4 VXLAN tunnel. Src Port: 16-bit value for the source port of the IPv4 VXLAN tunnel. Dest Port: 16-bit value for the destination port of the IPv4 VXLAN tunnel. The other types of IPv4 tunnel information will be described in the future.

This section describes the packet processing of G-SRH.

There are several cases when encoding the SRv6 SID and Compressable SRv6 SID in a single G-SRH. SRv6 path Compressed SRv6 path SRv6 path -> Compressed SRv6 path Compressed SRv6 path -> SRv6 path Combination of the above options. The ingress node of G-SRv6 encodes the G-SID list in G-SRH based on the type of path and the order of SIDs. If the beginning of the G-SRv6 path is a Compressed SRv6 sub-path, the CL MUST be initiated accordingly. If the first Compressable SRv6 SID is inserted in the G-SRH, then the CL MUST be set as 0. If the first Compressable SRv6 SID is reduced, the the CL MUST set to 3, which points to the first C-SID in the first G-SID. If the beginning of the G-SRv6 path is a SRv6 sub-path, and there is any compressable SRv6 SID in the list, the CL MUST be set to 0. If the G-SRv6 path is a SRv6 path , then the CL SHOULD be set to 0, and it MUST be ignored in G-SRH processing. When a compression G-SID is encoded in the G-SRH, new actions should be defined for processing it. When the SL >0, the pseudo code is shown below:

Ref1: nothing is changed when the IPv6 DA is an SRv6 SID, the SID will be processed as per , so G-SRH is compatible with SRH. Ref2: when the IPv6 DA is a local compressable SRv6 SID, the node should process it based on the type of SID and update the IPv6 DA based on the value of CL. If the CL is 0, the next C-SID should be selected from the first C-SID in the next compression G-SID and updated to the IPv6 DA. If the CL is greater than 0, then the next C-SID in this G-SID should be updated to the IPv6 DA. Ref3: If the IPv6 DA is a local Compressable SRv6 SID with EOC flavor, means this is the last C-SID of the C-SIDs list of this compression SRv6 sub-path. The next G-SID should be updated to the IPv6 DA, and the CL is set to 0 in order to help the process of the next Compression SRv6 SID. When SL = 0, the pseudo code is shown below.

Ref1: nothing is changed when the IPv6 DA is an SRv6 SID, the SID will be processed as per , so G-SRH is compatible with SRH. Ref2: when the IPv6 DA is a local compressable SRv6 SID, the node should process it based on the type of SID and update the IPv6 DA based on the value of CL. If the CL is 0, meaning this C-SID is the last segment, the node should process the SID and the G-SID processing should be finished. If the CL is greater than 0, the next C-SID in the G-SID should be updated to the IPv6 DA. Ref3: If the IPv6 DA is a local Compressable SRv6 SID with EOC flavor, meaning this is the last C-SID in the C-SIDs list of this compression SRv6 sub-path, the node should process the SID and the G-SID processing should be finished.

In some scenarios such as SD-WAN, an SRv6 packet may cross MPLS networking. Usually, the packet can be steered into an SR-MPLS policy based on END.BM SID . For reducing configuration in the middle nodes, this document proposes END.M (End function with SR-MPLS path instantiation) to indicate the SR-MPLS/MPLS path by the MPLS label stack carried after it.

An End.M SID indicates the beginning of the SR-MPLS SID list/MPLS Label stack, and the S-bit in MPLS label indicates the end of the MPLS label stack. When a node processes an END.M SID, it copies the SR-MPLS SID list/MPLS labels to the outer MPLS header, and updates the SL pointing to the next G-SID after these MPLS G-SIDs, set the IPv6 DA as the G-SRH[SL], and then forwards the packet based on the active MPLS label. The pesudo code is shown below:

Ref1. The Node will copy the MPLS labels within the MPLS G-SID to the outer MPLS header. The end of the MPLS labels is indicated by the S-bit in the MPLS label. The MPLS G-SID MUST NOT be the last G-SID in the G-SID list.

In some scenarios such as SD-WAN, an SRv6 packet may cross IPv4 networking. Usually, the packet will be transported by an IPv6 over IPv4 tunnel. This document proposes END.4 (End with IPv4 tunnel instantiation) and END.B4 (End binding to an IPv4 tunnel) behaviors for indicating the IPv4 tunnel.

The End.4 indicates the instantiation of an IPv4 Tunnel, and the parameter of this IPv4 Tunnel is carried by the IPv4 G-SID. An End.4 SID is never the last segment in a G-SID list. When a node processes a END.4 SID, it will encapsulate an outer IPv4 tunnel header according to the tunnel information in the associated IPv4 G-SID, and set the SL point the next G-SID after the IPv4 G-SIDs, update the inner IPv6 DA by G-SRH[SL], and then forward the packet based on the outer IPv4 DA. The pesudo code is shown below:

Ref1: When encapsulating the outer IPv4 tunnel header, the source address and destination address and tunnel related parameters are learned from the IPv4 G-SID. The IPv4 G-SID MUST NOT be the last G-SID in the G-SID list.

This is a variation of the End behavior, and it will be bound to an IPv4 tunnel initiated at endpoint node, while the parameters of this tunnel are not carried by SRH but maintained by node. The parameters of the IPv4 tunnel associated to the END.B4 SID can be configured and advertised in SID instantiation. This is out of scope of this document, and will be described in other documents. An End.B4 SID is never the last segment in a SID list. When a node processes an END.B4 SID, it will encapsulate an outer IPv4 tunnel header based on the parameters binding to the End.B4 SID, and set the SL point the next G-SID, update the inner IPv6 DA by G-SRH[SL], and then forward the packet based on the outer IPv4 DA. The pseudo code is shown below.

Ref1: When encapsulating the outer IPv4 tunnel header, the source address and destination address and tunnel related parameters are learned from the parameters binding to the SID, the information is maintained at the node.

TBD