MPLS Extension Header

Some applications require adding instructions and/or metadata to user packets within a network. Such examples include In-situ OAM (IOAM) and Service Function Chaining (SFC). New applications are emerging. It is possible that the instructions and/or metadata for multiple applications are stacked together in one packet to support a compound service. However, the encapsulation of the new header(s) poses some challenges to the ubiquitous MPLS networks. The MPLS protocol header contains no explicit indicator for the upper layer protocols by design. The compact MPLS header, while beneficial to forwarding, allows little room for any extra information. Moreover, the backward compatibility issue discourages any attempts trying to overload the semantics of the existing MPLS header fields. While it is possible to designate "service labels" with special semantics by an operator, the non-standard approach burdens the control plane and impairs the interoperability. The similar "header extension" requirement for MPLS has led to several proposals. A special Generic Associated Channel Label (GAL) is assigned to support the identification of an Associated Channel Header (ACH). Later, it was proposed to use GAL to indicate the presence of a Metadata Channel Header (MCH) as well. GAL has several limitations: It must be located at the bottom of a label stack for its chief use case of MPLS-TP. An LSR needs to search the entire label stack for the BoS bit and check if the corresponding label is GAL. This can impact the performance when the label stack is deep. When GAL is present, the first nibble of the word following the GAL needs to be checked to determine the header type. Since the value of the nibble cannot be greater than 3 to avoid any possible confliction with IP version numbers, this approach is not scalable. By design, GAL can only indicate the presence of a single header. Therefore, the solution alone is not sufficient to support adding multiple headers at the same time. The presence of GAL makes the network load balancing or deep packet inspection based on upper layer protocol headers and payload difficult. In addition to the above limitations, it is not desirable to keep overloading GAL with new semantics. Instead of trying to patch on existing schemes, we propose a new mechanism to solve the above mentioned issues and create new innovation opportunities, similar to the way that IPv6 supports extension headers, which offer a huge innovation potential (e.g, network security, SRv6, network programming, SFC, etc.). Thanks to the existing of extension headers, it is straightforward to introduce new in-network services into IPv6 networks. For example, it has been proposed to carry IOAM header and NSH as new extension headers in IPv6 networks. Nevertheless, IPv6 is not perfect either. It has two main issues. First, IPv6's header is large compared to MPLS, claiming extra bandwidth overhead and complicating the packet processing. We prefer to retain the header compactness in MPLS networks. Second, IPv6's extension headers are chained with the original upper layer protocol headers in a flat stack. One must scan all the extension headers to access the upper layer protocol headers and the payload. This is inconvenient and raises some performance concerns for some applications (e.g., DPI and ECMP). The new scheme for MPLS header extension needs to address these issues too.

From the previous discussion, we have laid out the design requirements to support extension headers in MPLS networks: If possible, unnecessary label stack scanning for a label and extension header stack scanning for the upper layer protocol should be avoided. New applications can be easily supported by introducing new extension headers. Multiple extension headers can be easily stacked together to support multiple services simultaneously. Legacy devices which do not recognize the extension header option should still be able to forward the packets as usual. If a device recognize some of the extension headers but not the others in an extension header stack, it can process the known headers only while ignoring the others. Extension headers can be be supported in several ways in an MPLS network, we have outlined some of them in this document. However, it should be noted that we do not intend to close this discussion yet, and are prepared to listen to arguments why and how any other methods could be used. One interesting line of thought is whether it would be possible to let a label that is received on top of the stack indicate whether there are extension headers beneath the stack. Our investigations indicate that a special purpose label and/or an extended special purpose label will be the optimal way to go. A new special purpose label, namely the Extension Header Label (EHL), can be used to indicate EHs. So far 8 special purpose label values are left unsigned by IANA (which are 4 to 6 and 8 to 12). Alternatively, a two label scheme with the use of the extension label (XL) plus an EHL is possible, but it does use one more label. It is also possible to use FEC labels to indicate the presence of extension headers. Although this approach avoid the need of a new special purpose label, it introduces a good deal of complexity into the control plane. In the remaining of the document, we assume a special EHL is assigned and use it as an example to illustrate the scheme. A formal recommendation on the Extension Header (EH) indicator approach will be given in a future revision of this document. The format of the MPLS packets with extension headers is shown in . An EHL can be located in anywhere in an MPLS label stack. However, if there are legacy devices which do not recognize the EHL in the network, then for backward compatibility, the EHL must be located at the bottom of the stack (i.e., only the MPLS tunnel ends and EHL-aware nodes will look up and process it). Otherwise, the EHL can be located close to the top of the stack for better lookup performance. The format of an EHL is the same as an MPLS label. The first 20-bit label value will be assigned by IANA. The BoS bit is used to indicate the location of the label. The other fields, CoS and TTL, are unused in the context of EHL.

Following the MPLS label stack is the 4-octet Header of Extension Headers (HEH), which indicates the total number of extension headers in this packet, the overall length of the extension headers, and the type of the next header. The format of the HEH is shown in .

The meaning of the fields in an HEH is as follows: 4-bit reserved. 8-bit unsigned integer for the Extension Header Counter. This field keeps the total number of extension headers included in this packet. It does not count the original upper layer protocol headers. 12-bit unsigned integer for the Extension Header Total Length in 4-octet units. This field keeps the total length of the extension headers in this packet, not including the HEH itself. 8-bit selector for the Next Header. This field identifies the type of the header immediately following the HEH. The EHCNT field can be used to keep track of the number of extension headers when some headers are inserted or removed at some network nodes. The EHLEN field can help to skip all the extension headers in one step if the original upper layer protocol headers or payload need to be accessed. The format of an Extension Header (EH) is shown in .

The meaning of the fields in an EH is as follows: 8-bit selector for the Next Header. This field identifies the type of the EH immediately following this EH. 8-bit unsigned integer for the Extension Header Length in 4-octet units, not including the first 4 octets. Variable length field for the specification of the EH. This field is 4-octet aligned. The extension headers as well as the first original upper layer protocol header are chained together through the NH field in HEH and EHs. The encoding of NH uses the same values as the IPv4 protocol field. Values for new EH types shall be assigned by IANA. Specifically, the NH field of the last EH in a chain can have two special values, which shall be assigned by IANA: Indicates that there is no other header and payload after this header. This can be used to transport packets with only extension header(s). Indicates that the type of the header after this header is unknown. This is intended to be compatible with the original MPLS design in which the upper layer protocol type is unknown from the MPLS header alone.

When the first EH X needs to be added to an MPLS packet, an EHL is inserted into the proper location in the MPLS label stack. A HEH is then inserted after the MPLS label stack, in which EHCNT is set to 1, EHTLEN is set to the length of X in 4-octet units, and NH is set to the header value of X. At last, X is inserted after the HEH, in which NH and HELN are set accordingly. Note that if this operation happens at a PE device, the upper layer protocol is known before the MPLS encapsulation, so its value can be saved in the NH field if desired. Otherwise, the NH field is filled with the value of "UNKNOWN". When an EH Y needs to be added to an MPLS packet which already contains extension header(s), the EHCNT and EHTLEN in the HEH are updated accordingly (i.e., EHCNT is incremented by 1 and EHTLEN is incremented by the size of Y in 4-octet units). Then a proper location for Y in the EH chain is located. Y is inserted at this location. The NH field of Y is copied from the previous EH's NH field (or from the HEH's NH field, if Y is the first EH in the chain). The previous EH's NH value, or, if Y is the first EH in the chain, the HEH's NH, is set to the header value of Y. Deleting an EH simply reverses the above operation. If the deleted EH is the last one, the EHL and HEH can also be deleted. When processing an MPLS packet with extension headers, the node needs to scan through the entire EH chain and process the EH one by one. The node should ignore any unrecognized EH.

In this section, we show how MPLS extension header can be used to support several new network applications. In-situ OAM (IOAM) records flow OAM information within user packets while the packets traverse a network. The instruction and collected data are kept in an IOAM header . When applying IOAM in an MPLS network, the IOAM header can be encapsulated as an MPLS extension header. Network Service Header (NSH) provides a service plane for Service Function Chaining (SFC). NSH maintains the SFC context and metadata. If MPLS is used as the transport protocol for NSH, NSH can be encapsulated as an MPLS extension header. A network telemetry and instruction header can be carried as an extension header to instruct a node what type of network measurements should be done. For example, the method described in can be implemented in MPLS networks since the EH provides a natural way to color MPLS packets. Security related functions often require user packets to carry some metadata. In a DoS limiting network architecture, a "packet passport" header is used to embed packet authentication information for each node to verify. MPLS extension header can support the implementation of a new flavor of the MPLS-based segment routing, with better performance and richer functionalities. The details will be described in another draft. With MPLS extension headers, multiple in-network applications can be stacked together. For example, IOAM and SFC can be applied at the same time to support network OAM and service function chaining. A node can stop scanning the extension header stack if all the known headers it can process have been located. For example, if IOAM is the first EH in a stack and a node is configured to process IOAM only, it will stop searching the EH stack when the IOAM EH is found.

Evidenced by the existing and emerging use cases, MPLS networks need a standard way to support extension headers. In , we summarize the potential schemes that allow MPLS packets to carry extension headers and list the main issues for each scheme.

Through comprehensive considerations on the pros and cons of each scheme, we currently recommend the scheme No.5. The proposed MPLS extension header scheme provides a generic way to support in-network services and functions in MPLS networks.

TBD

If the EHL approach is adopted to indicate the presence of MPLS extension header(s), this document requests IANA to assign a new Special-Purpose MPLS Label Value from the Special-Purpose Multiprotocol Label Switching (MPLS) Label Values Registry of "Extension Header Label (EHL)". This document also requests IANA to assign two new Internet Protocol Numbers from the "Protocol Numbers" Registry to indicate "No Next Header" or "Unknown Next Header". This document does not create any new registries.

The other contributors of this document are listed as follows. James Guichard Stewart Bryant Andrew Malis

TBD.