| Internet-Draft | MPLS Post-Stack Action Header | April 2023 |
| Song, et al. | Expires 16 October 2023 | [Page] |
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 Action 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.¶
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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 16 October 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 Action 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:¶
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:¶
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):¶
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:¶
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:¶
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:¶
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.¶
Basically, MPLS EHs have two application scopes based on the nature of the contained MNA: HBH and E2E. E2E means that the EH is only supposed to be inserted/removed and processed at the MPLS tunnel end points where the MPLS header is inserted or removed. The EHs that need to be processed on path nodes within the MPLS tunnel are of the HBH type. However, any node in the tunnel can be configured to ignore an HBH EH, even if it is capable of processing it.¶
If there are two types of EHs in a packet, the HBH EHs must take precedence over the E2E EHs.¶
Making a distinction of the EH types and ordering the EHs in a packet help improve the forwarding performance. For example, if a node within an MPLS tunnel finds only E2E EHs in a packet, it can avoid scanning the EH list.¶
The scope of an EH (i.e., HBH or E2E) is an intrinsic property of the contained MNA. In other words, such information can be inferred from the NH value.¶
An encapsulation node (i.e., an MPLS router) on an MPLS Label Switched Path (LSP), when receiving a packet that matches the policy for applying one or more post-stack MNAs, will include them in the PAH as EHs, process the MNAs if needed, and then forward the packet to a next node on the path. The other nodes on the LSP, when receiving this packet, will process the MNAs if needed (e.g., for the HBH type of EH) and forward the packet. Finally, each post-stack MNA has a decapsulation node on the LSP. When receiving the packet, the decapsulation node will process the MNA, remove the corresponding EH, update the PAH, and forward the packet. The encapsulation/decapsulation nodes are configured through control plane for which the mechanism is out of scope of this document.¶
Each post stack MNA is contained in an EH. A new EH to be inserted may or may not be the first EH in the packet. Similarly, an EH to be removed may or may not be the last EH is the packet. The details on MNA encapsulation and decapsulation are described as follows:¶
A suitable indication for the presence of PAH is ensured before adding the first EH X to an MPLS packet. Then the PAH is inserted after the MPLS label stack. In the CH of the PAH, EHC is set to 1, EHTL is set to the length of X in 4-octet units, OUL is set to a proper value, and NH is set to the header type value of X. At last, X is inserted after the CH, in which NH and HLEN 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 OUL and 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 the PAH, the EHC and EHTL in the CH are updated accordingly (i.e., EHC is incremented by 1 and EHTL 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 CH'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 CH's NH value, is set to the NH value of Y.¶
Deleting an EH simply reverses the above operation. If the deleted EH is the last one, the PAH indicator and the PAH can also be removed.¶
When processing an MPLS packet with multiple extension headers in an PAH, the node needs to parse through the entire EH chain and process the EH one by one (but not necessarily in the parsing order). The node should ignore any EH that is not recognized or is configured as "Do not Processing" by the control plane.¶
The EH can be categorized into HBH or E2E. Since EHs are ordered based on their type (i.e., HBH EHs are located before E2E EHs), a node can avoid some unnecessary EH scan.¶
In this section, we show how PAH can be used to support several new network applications.¶
With PAH, multiple in-network applications can be chained together as extension headers. 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 chain if all the known headers it can process have been located. For example, if IOAM is the first EH in a chain and a node is configured to process IOAM only, it can stop searching the EH chain when the IOAM EH is found.¶
Details on some of these use cases and discussions on some other use cases are covered in [I-D.ietf-mpls-mna-usecases].¶
The major security concerns may come from the MNAs that encapsulated in the PAH. So we need to be careful to admit actions and take measures to avoid the security threats such as information leak or DoS attack.¶
This document requests IANA to assign two new Internet Protocol Numbers from the "Protocol Numbers" Registry to indicate "No Next Header" and "Unknown Next Header".¶
This document does not create any other new registries. New registries for protocol numbers and type extension numbers should be requested by each MNA use case document.¶
The other coauthors of this document are listed as follows.¶
The other contributors of this document are listed as follows.¶
We thank Tarek Saad and the other members of MPLS ODT for helping improve this document.¶