MPLS Extension Header

Abstract

Motivated by the need to support multiple in-network services and functions in an MPLS network, this document describes a generic and extensible method to encapsulate extension headers into MPLS packets. The encapsulation method allows stacking multiple extension headers and quickly accessing any of them as well as the original upper layer protocol header and payload. We show how the extension header can be used to support several new network applications and optimize some existing network services.¶

1. Motivation

Some applications require adding instructions and/or metadata to user packets within a network. Such examples include In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] and Service Function Chaining (SFC) [RFC7665]. 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.¶

Conceivably, such instructions and/or metadata would be encoded as new headers and encapsulated in user packets. Such headers may require to be processed in fast path or in slow path. Moreover, such headers may require being attended at each hop on the forwarding path (i.e., hop-by-hop or HBH) or at designated end nodes (i.e., end-to-end or E2E).¶

The encapsulation of the new header(s) poses some challenges to MPLS networks, because the MPLS protocol header contains no explicit indicator for the upper layer protocols by design. We leave the discussion on the indicator of new header(s) in an MPLS packet to another companion document [I-D.song-mpls-eh-indicator]. In this document, we focus on the encode and encapsulation of new headers in an MPLS packet.¶

The similar problem has been tackled for some particular application before. However, these solutions have some drawbacks:¶

• The solutions rely on either the built-in next-protocol indicator in the header or the knowledge of the format and size of the header to access the following packet data. The node is required to be able to parse the new header, which is unrealistic in an incremental deployment environment.¶
• These works only provide piecemeal solution which assumes the new header is the only extra header and its location in the packet is fixed by default. It is impossible or difficult to support multiple new headers in one packet due to the conflicted assumption.¶
• Some previous work such as G-ACH [RFC5586] was explicitly defined for control channel only but what we need is the user packet service.¶

To solve these problems, we introduce extension header as a general and extensible means to support new in-network functions and applications in MPLS networks. The idea is similar to IPv6 extension headers which offer a huge innovation potential (e.g, network security, SRv6 [RFC8754], network programming [I-D.ietf-spring-srv6-network-programming], SFC [I-D.xu-clad-spring-sr-service-chaining], etc.). Thanks to the existence 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 [I-D.brockners-inband-oam-transport] as a new extension header option in IPv6 networks.¶

Nevertheless, IPv6 EH is not perfect either. It has three issues:¶

• 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.¶
• 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.¶
• [RFC8200] enforces many constraints to IPv6 extension headers (e.g., EH can only be added or deleted by the end nodes specified by the IP addresses in the IPv6 header, and there is only one Hop-by-Hop EH that can be processed on the path nodes), which are not suitable for MPLS networks. For example, MPLS label stacks are added and changed in network, and there could be tunnel within tunnel, so the extension headers need more flexibility.¶

2. MPLS Extension Header

From the previous discussion, we have laid out the design requirements to support extension headers in MPLS networks:¶

Performance:

Unnecessary label stack scanning for a label and the full extension header stack scanning for the upper layer protocol should be avoided. The extension headers a node needs to process should be located as close to the MPLS label stack as possible. Each extension header is better to serve only one application to avoid the need of packing multiple TLV options in one extension header.¶

Scalability:

New applications can be supported by introducing new extension headers. Multiple extension headers can be easily stacked together to support multiple services simultaneously.¶

Backward Compatibility:

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.¶

Flexibility:

A node can be configured to process or not process any EH. Any tunnel end nodes in the MPLS domain can add new EH to the packets which shall be removed on the other end of the tunnel.¶

We assume the MPLS label stack has included some indicator of the extension header(s). The actual extension headers are inserted between the MPLS label stack and the original upper layer packet header. The format of the MPLS packets with extension headers is shown in Figure 1.¶

   0                                  31
   +--------+--------+--------+--------+  \
   |                                   |  |
   ~     MPLS Label Stack              ~  |
   |                                   |  |
   +--------+--------+--------+--------+  |
   |     EH Indicator (TBD)            |   > MPLS Label Stack
   +--------+--------+--------+--------+  |  (extended with EHI)
   |                                   |  |
   ~     MPLS Label Stack              ~  |
   |                                   |  |
   +--------+--------+--------+--------+ <
   | Header of Extension Headers (HEH) |  |
   +--------+--------+--------+--------+  |
   |                                   |  |
   ~     Extension Header (EH) 1       ~  |
   |                                   |  |
   +--------+--------+--------+--------+   > MPLS EH Fields
   ~                                   ~  |  (new)
   +--------+--------+--------+--------+  |
   |                                   |  |
   ~     Extension Header (EH) N       ~  |
   |                                   |  |
   +--------+--------+--------+--------+ <
   |                                   |  |
   ~    Upper Layer Headers/Payload    ~   > MPLS Payload
   |                                   |  |  (as is)
   +--------+--------+--------+--------+  /

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, the type of the original upper layer header, and the type of the next header. The format of the HEH is shown in Figure 2.¶

    0           1         2          3
    0123 4567 89012345 67890123 45678901
   +----+----+--------+--------+--------+
   | R  |EHC |  EHTL  |  OUL   |   NH   |
   +----+----+--------+--------+--------+

The meaning of the fields in an HEH is as follows:¶

R:

4-bit reserved. The nibble value means to avoid conflicting with IP version numbers.¶

EHC:

4-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. At most 15 EHs are allowed in one packet.¶

EHTL:

8-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.¶

OUL:

8-bit Original Upper Layer protocol number indicating the original upper layer protocol type. It can be set to "UNKNOWN" if unknown.¶

NH:

8-bit selector for the Next Header. This field identifies the type of the header immediately following the HEH.¶

The value of the reserved nibble needs further consideration. The EHC 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 EHTL 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 OUL field can help identify the type of the original upper layer protocol.¶

The format of an Extension Header (EH) is shown in Figure 3.¶

    0          1          2          3
    01234567 89012345 67890123 45678901
   +--------+--------+--------+-------+
   |  NH    |  HLEN  |EXT     |       |
   +--------+--------+--------+       |
   |                                  |
   ~        Header Specific Data      ~
   |                                  |
   +--------+--------+----------------+

The meaning of the fields in an EH is as follows:¶

NH:

8-bit indicator for the Next Header. This field identifies the type of the EH immediately following this EH.¶

HLEN:

8-bit unsigned integer for the Extension Header Length in 4-octet units, not including the first 4 octets.¶

EXT:

8-bit optional type extension. To save the Next Header numbers and extend the number space, it is possible to use one "Next Header" code to cover a set of sub-types. Each sub-type is assigned a new code in a different name space. This field is optional and it is only specified for some specific EH type.¶

Header Specific Data:

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 can share the same value registry for IPv4/IPv6 protocol numbers. Values for new EH types shall be assigned by IANA.¶

Specifically, the NH field of the last EH in a chain can have some special values, which shall be assigned by IANA as well:¶

NONE (No Next Header):

Indicates that there is no other header and payload after this header. This can be used to transport packets with only extension header(s), for example, the control packets for control or the probe packets for measurements. Note that value 59 was reserved for "IPv6 No Next Header" indicator. It may be possible for MPLS EH to share this value.¶

UNKNOWN (Unknown Next Header):

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.¶

MPLS:

Indicates that the original upper layer protocol is still MPLS and another MPLS label stack follows.¶

Note that the original upper layer protocol can be of type "MPLS", which implies that in a packet there might be multiple label stacks separated by EHs. Having more than one independent label stack is not new. For example, A Bier header could separate the transport/bier labels and the payload labels; An MPLS PW network could be implemented on the top of another infrastructure MPLS network. In such cases, we have the flexibility to apply different services to different label stacks.¶

10. References