Support MPLS Network Actions using Post-Stack Extension Headers

Abstract

Motivated by the need to support multiple in-network services and functions in an MPLS network (a.k.a. MPLS Network Actions (MNA)), this document describes a generic and extensible method to encapsulate MNA instructions as well as possible ancillary data in an MPLS packet. All the post-stack MNAs are encapsulated in a structure called Post-stack MNA Header (PAH). A PAH is composed of a common header plus a chain of extension headers; each extension header is a container for an MNA. The encapsulation method allows chaining multiple post-stack extension headers and provides the means to enable fast access to them as well as the original upper layer headers. This document confines to the solution of PAH encoding and leaves the specification of PAH indicator to the overall MNA solution. We show how PAH can be used to support several new MNAs as a generic post-stack mechanism.¶

1. Motivation

Some applications require adding sizable action instructions and/or ancillary data to packets within an MPLS network. Such examples include In-situ OAM (IOAM) [RFC9197] and Service Function Chaining (SFC) [RFC7665]. New applications are emerging. It is possible that the instructions and/or ancillary data for multiple MNAs are stacked together in one packet to support a compound service.¶

Such instructions and/or ancillary data would need to be encoded and encapsulated as new headers in packets. Such headers may require to be processed in fast path due to performance considerations. 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 need and requirements to support such applications in MPLS networks, i.e., MPLS Network Actions (MNA), are described in [I-D.ietf-mpls-mna-usecases] and [I-D.ietf-mpls-mna-requirements]. It is clear that some header should be located after the MPLS label stack. We call such a header Post-stack MNA Header (PAH). The encapsulation of PAH poses some challenges to MPLS networks, because the MPLS label stack contains no explicit indicator for the upper layer protocols by design.¶

The mechanism to indicate the presence of the PAH is outside the scope of this document. The indication for the presence of the PAH can be achieved using several mechanisms, including carrying a Special Purpose Label (SPL) or signaling it with the label Forwarding Equivalence Class (FEC) as described in [I-D.ietf-mpls-mna-fwk]. In this document, we focus on the encoding and encapsulation of the PAH in an MPLS packet.¶

The conventional header encoding and encapsulation methods face some challenges in the case of post-stack MNA:¶

• A solution may 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 headers. This method requires each node to be able to parse the new header, which is unrealistic in an incremental deployment environment.¶
• Some works provide only piecemeal solutions which assume the new header is the only extra header and its location in the packet is fixed by default (e.g., Encapsulation of SFC NSH in MPLS [RFC8596]). It is impossible or difficult to support multiple new headers in one packet due to the conflicting location assumption.¶
• Some previous work such as G-ACH [RFC5586] was explicitly defined for control channel only, but we need the mechanism to also work for user packets.¶

To solve the aforementioned problems, we introduce PAH as a general and extensible means to support new MNAs which involve instructions and/or ancillary data for each MNA. The concept is similar to IPv6 extension headers which offer a huge potential for extending IPv6's capability (e.g, network security, SRv6 [RFC8754], network programming [RFC8986], SFC [I-D.ietf-spring-sr-service-programming], etc.). Thanks to the mechanism of extension headers, it is straightforward to continue introducing new network services into IPv6 networks.¶

Nevertheless, when applying the extension headers to MPLS, some issues of the IPv6 EH should be avoided:¶

• 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., Deep Packet Inspection (DPI) and Equal Cost Multi Path (ECMP)). The new PAH scheme for MPLS needs to improve this.¶
• [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 Post-stack Network Action Header

The concept and design of the PAH comply with the requirements laid out in [I-D.ietf-mpls-mna-requirements]. All the post-stack MNAs are encapsulated in a PAH. A PAH is composed of a common header plus a chain of extension headers; each extension header is a container for an MNA. Here we highlight some design objectives of PAH (Note: these should be covered by the MNA requirement document):¶

Performance:

Unnecessary full extension header chain scanning for all MNAs or the upper layer headers should be avoided. The extension headers should be ordered according to the access need. Each extension header should serve only one MNA to avoid the need of packing multiple TLV options in one extension header.¶

Scalability:

New MNAs 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 PAH should still be able to forward the packets based on the top label as usual. If a PAH-aware device recognizes some of the MNAs but not the others in an extension header chain, it can process the known MNAs only while ignoring the others.¶

Flexibility:

A node (i.e., an LER or LSR) 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 PAH. The actual PAH is inserted between the MPLS label stack and the original upper layer header. The format of the MPLS packets with PAH is shown in Figure 1.¶

 0                                  31
 +--------+--------+--------+--------+
 |                                   |
 ~         MPLS Label Stack          ~
 |                                   |
 +--------+--------+--------+--------+
 |             BoS Label             |
 +--------+--------+--------+--------+
 |    Common Header of PAH (CH)      |  \
 +--------+--------+--------+--------+  |
 |                                   |  |
 ~     Extension Header (EH) 1       ~  |
 |                                   |  |
 +--------+--------+--------+--------+   >MPLS PAH
 ~             ... ...               ~  |
 +--------+--------+--------+--------+  |
 |                                   |  |
 ~     Extension Header (EH) n       ~  |
 |                                   |  /
 +--------+--------+--------+--------+
 |             Original              |
 ~    Upper Layer Headers/Payload    ~
 |                                   |
 +--------+--------+--------+--------+

Following the MPLS label stack is the 4-octet Common Header of PAH (CH), which indicates the total number of extension headers in this packet, the overall length of the PAH, the type of the original upper layer header, and the type of the next extension header. The format of the CH 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 a CH is as follows:¶

R:

reserved nibble. The nibble value means to avoid any potential conflicting with IP version numbers and other well-defined semantics [I-D.kbbma-mpls-1stnibble].¶

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 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 EHs in this packet, not including the CH itself.¶

OUL:

8-bit Original Upper Layer protocol number indicating the original upper layer protocol type. It can be set to "UNKNOWN" (value TBD) if unknown. Sometimes the MPLS FEC may indicate the type of payload. In this case either OUL is redundant or OUL can be used to replace the control plane mechanism.¶

NH:

8-bit indicator for the Next Header. This field identifies the type of the MNA in the extension header immediately following the CH.¶

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 EHs in one step if the original upper layer 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(opt)    |
   +--------+--------+--------+-------+
   |                                  |
   ~  MNA Instruction/Ancillary Data  ~
   |                                  |
   +--------+--------+----------------+

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

NH:

8-bit indicator for the Next Header type. This field identifies the type of the MNA in 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:

16-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. For example, IOAM has several different options, such as trace and DEX. It is too expensive to assign an EH type for each of it. In this case, it is better to have a single EH type value for IOAM, and use the EXT to specify the option types. This field is optional and only specified for some specific MNA types. This field can also be used to encode other information.¶

MNA Instruction/Ancillary Data:

A variable length field for the specification of an MNA. This field may need to be padded to make the EH 4-octet aligned.¶

The extension headers as well as the first original upper layer protocol header are chained together through the NH field in CH and EHs. The encoding of NH can share the same value registry for IPv4/IPv6 protocol numbers. Values for new MNA types (i.e., NH number) shall be assigned by IANA from the same registry as for the ipv4 and ipv6 protocol numbers (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).¶

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 EH. 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 (Note: need to work with 6MAN).¶

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 next protocol header is still of MPLS type and another MPLS label stack follows.¶

These NH values can only appear in the last EH in an PAH. Note that the original upper layer protocol can be of type "MPLS", which implies that a packet may contain multiple logically independent label stacks separated by PAH. 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 Pseudo Wire (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