Segment Routing with MPLS Extension Header

Segment Routing (SR) allows a node to steer a packet based on an ordered list of segments. It can be applied on an MPLS data plane (i.e., SR-MPLS) or an IPv6 data plane (i.e., SRv6). In SR-MPLS, each segment identifier (SID) is encoded in an MPLS label . The SID list forms an MPLS label stack. Each hop will pop the top label from a packet's label stack and forward the packet based on the SID encoded in the label. MPLS has a wide deployment base and SR-MPLS can be directly applied on an MPLS data plane without any change. Meanwhile, SR-MPLS's SID overhead is small and each SID in SR-MPLS is only 4 bytes. However, SR-MPLS has several drawbacks: The SID label stack may be deep, which can hurt the forwarding performance when the bottom of stack needs to be accessed or deep packet inspection needs to be performed. For example, network load balancing based on entropy label or IP header, and other network services such as In-situ OAM, rely on headers deeply embedded in a packet. A deep MPLS label stack is unfavorable in such occasions. While the compactness of an MPLS label helps to reduce the header overhead, it leaves no room to encode extra information other than SID. Because of this, a noticeable missing feature of SR-MPLS is the network programming. Network programming is a powerful feature of SRv6. It enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Obviously, it is preferred for SR-MPLS to support the same feature as well. In MPLS networks, MPLS Network Action (MNA) extends the MPLS label stack by supporting extra network actions encoded both in stack and post stack. The post-stack actions are encapsulated in MPLS extension headers. SR in MPLS can be implemented with an extension header. If other post-stack MNA encoding style is adopted, the method is still valid. The new approach not only retains MPLS's advantages but also overcomes its drawbacks.

With the presence of MPLS extension header, the SID label stack is kept in an extension header. Only the current SID label is copied to the top of the MPLS label stack. An example for the packet format is shown in Figure 1.

The format of the extension header for the SID list, or the Segment Routing Header (SRH), is shown in Figure 2.

The meaning of the fields in an SRH is as follows: As defined in . As defined in . 8-bit unsigned integer for the number of SIDs in the segment list. 8-bit index (zero based) of the current SID in the segment list. The i-th 20-bit SID. SID[0] is the first segment of the path. The i-th 108-bit instructions and parameters for network programming at the i-th segment. Optional Type-Length-Value, TBD. The operator is free to partition the FUNCT and ARGS field to encode the function and parameters at a segment.

The SR source node generates the SRH. The Segment Pointer field of the SRH is initialized to 0. The SRH is inserted into the MPLS packet as an MPLS extension header. The SID[0] in the SRH is copied into an MPLS label. The TTL field in the label is initialized to a configured value. The label is pushed to the top of the label stack. The packet is then forwarded based on the top label. At each node, if the SID in the top label matches the local SID, the function associated with the SID in the SRH is executed. If there are still segment(s) left in the segment list (i.e., Segment Count > Segment Pointer + 1), then the Segment Pointer in the SRH is incremented by 1, and the SID pointed by the Segment Pointer is copied to the top label in the MPLS label stack. The TTL field in the top label is decremented by 1. The packet is then forwarded based on the top label. If the current segment is the last segment, the top label is popped and the SRH extension header is deleted. The packet is then forwarded based on the header of the remaining packet.

The document describes how the SFC can be achieved through SR-MPLS. Similarly, the Segment Routing with MPLS Extension Header can also realize the service chaining, with additional advantages over the previous proposal. A noticeable issue of the SR-MPLS based SFC is its lack of metadata carrying capability. Metadata may be critical for message passing and information sharing between service functions. This drawback limits the applicability of SR-MPLS for SFC. In our solution, the metadata can be carried in the optional TLVs in the SRH. Another document proposes to integrate the SR and the NSH to better support SFC, in which NSH provides a service plane and SR supports transport. Again, in our proposal, the NSH can be encapsulated into a TLV in the SRH.

This document shares the same security considerations with the SR-MPLS, network-programming, and SFC.

This document requires IANA to assign a new protocol number (TBA1) to indicate the SID list.

TBD.