| Internet-Draft | MPLS Extension Header Indicator | January 2022 |
| Song, et al. | Expires 7 July 2022 | [Page] |
The intention of this document is to enumerate and describe the candidate schemes that can be used to indicate the presence of the MPLS extension header(s) following the MPLS label stack. After a careful evaluation of these options by comparing their pros and cons, it is expected that one should be chosen as the final standard scheme for MPLS extension header indicator.¶
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 7 July 2022.¶
Copyright (c) 2022 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.¶
The document [I-D.song-mpls-extension-header] presents the motivation, specification, and use cases of MPLS Extension Header (EH). An indicator is needed in the MPLS label stack to indicate the presence of the extension header(s). Multiple options are possible for this purpose. As the discussion progresses, more options could emerge.¶
In this document, we propound three categories of methods which can be further partitioned into five unique schemes. Four of them use explicit data plane encoding to indicate the EH and the last one implies the EH through control plane configuration. This document details and compares these schemes, in order to foster further discussions until a final decision is made.¶
A straightforward method is to directly encode an Extension Header Label (EHL) in the MPLS label stack. Two derived schemes are as follows.¶
A new special purpose label, EHL, can be used to indicate EHs. As specified in [RFC7274], so far eight special purpose label values are still left unsigned by IANA (which are 4 to 6 and 8 to 12). This single label scheme is elegant but arguably demands a scarce resource. We cannot rule out the possibility of requiring more than one label value to differentiate EH classes (e.g., Hop-by-Hop, End-to-End, or both). If this happens, it can only aggravate the situation.¶
Another benefit of this scheme is that an EHL can potentially be located anywhere in an MPLS label stack. It is easier and quicker for a router to figure out the existence of extension header(s) if the EHL is close to or at the top of the label stack. However, if there are legacy devices which can reach the EHL but do not recognize it in a 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).¶
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, currently have no use in the context of EHL. However, these two fields can potentially be used to encode other information. If such code points are open for other purpose, it will make the single EHL idea more compelling. E.g., the EH category and/or other information, if needed, can be encoded in these fields, so that only one special label value is needed.¶
The following figure shows a potential scheme in which one bit from the CoS field ('H') is used to indicate the presence of HbH EHs in the packet. If 'H' bit is 0, it means no HbH EH follows so a P-router will not need to check the EH. The last 8 bits can be used to find the location of the extension headers (i.e., the first byte after the MPLS label stack). This information can help to avoid the scan of the label stack in case the extension headers need to be accessed.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EHL (TBD) |H| |S| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the Cos/TTL fields can be encoded to include more information. For example, in addition to indicate the EH, it can also indicate the presence of some other label-based services (e.g., EL). If we want to explore such possibilities, we have 11 bits in total at our disposal.¶
[RFC7274] specifies the Extension Label (XL) with the value of 15. An extended special purpose label (ESPL) following XL can be used as EHL. A large number of ESPL values are available for allocation. The XL+EHL scheme eases the concern on the reserved label space at the cost of one more label in the label stack.¶
Except for the fact that one more label is needed, The XL+EHL scheme shares the same property as the single special purpose EHL scheme.¶
The similar "header extension" requirement for MPLS has led to some proposals before. A special Generic Associated Channel Label (GAL) [RFC5586] with the value of 13 has been assigned to support the identification of an Associated Channel Header (ACH). We can extend this existing mechanism to encode the MPLS EH indicator.¶
The ACH is located below the bottom label. It has a 16-bit Channel Type field which provides abundant space to encode the MPLS EH indicator. This scheme has the same header overhead as the XL+EHL scheme. The format is depicted in Figure 2.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (13) | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Extension Header Indicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HEH and EH(s) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GAL has several applications already yet its heritage also has several limitations. The GAL must be located at the bottom of a label stack for its chief use cases such as MPLS-TP. So a router 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. A more serious concern is that [RFC5586] states that GAL+ACH MUST NOT be used to transport user traffic and an ACH is supposed to be followed by a non-service payload.¶
None of these is insurmountable but it does require an overhaul of the existing RFC in order to extend the usage of GAL.¶
To avoid changing the established semantics of ACH, a variation can be used. ACH starts with a nibble value "0001". A different nibble value may be used to redefine the remaining part of the word. The idea has been exploited by [I-D.guichard-sfc-mpls-metadata] to define a Metadata Channel Header (MCH) with the leading nibble value "0000". Similarly, we can use another nibble value (e.g., "0010") to define a new header, namely the MPLS Extension Header Indicator (EHI).¶
The format of the GAL and EHI is depicted in Figure 3.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL (13) | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0|Version| Reserved | Extension Header Class |<-EHI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HEH and EH(s) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Extension Header Class field in EHI is used to differentiate the extension headers. Potentially there are three classes: Hop-by-Hop (HbH), End-to-End (E2E), or both. If finally we decide to not differentiate the extension headers, we have the opportunity to merge the HEH (see [I-D.song-mpls-extension-header] for details) into EHI, so we can reduce the header overhead by four bytes. The header format is depicted in Figure 4.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL (13) | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0| EHCNT | EHTLEN | NH |<-HEH +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | EH(s) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Instead of introducing a new SPL as the EH indicator, we can piggyback the indicator in some existing SPL to avoid claiming extra SPL resource and save a label overhead. The best candidate is the entropy label (EL) [RFC6790]. If we can make EL default for every MPLS packet, we can encode the EH indicator in the unused ELI/EL label fields such as CoS and TTL.¶
In Figure 5 we show a possible encoding method, in which the first bit of the CoS field in ELI is used to indicate the presence of EH and the TTL field in ELI can be used to indicate the location of the EH. Note that the CoS field of the EL can also be used to encode other information, if necessary.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ELI (7) |I| |S| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EL | |S| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is also possible to use FEC labels to indicate the presence of extension headers. An FEC label has the same forwarding semantics as the original label, but it also means that one or more extension headers exist below the label stack.¶
Although this approach avoids the need of new header encoding standards, it introduces a good deal of complexity into the control plane. Since every label needs an FEC label to indicate EH, this scheme also significantly reduces the available label space. Another issue is that this solution may not work for incremental deployment where some legacy routers cannot understand and apply the FEC labels for EH. Moreover, this configuration-based solution certainly makes the cross-domain interoperability more difficult. Hence, this is the least preferred option. We only include it here for the completeness of the discussion.¶
Evidenced by the existing and emerging use cases, MPLS networks need a standard way to support extension headers. In Figure 6, we summarize the potential schemes that allow MPLS packets to carry extension headers and list the main pros and cons for each scheme.¶
+---+---------------------------+---------------------------------+ |No.| Description | Pros and Cons | +---+---------------------------+---------------------------------+ | 1 | Special purpose EHL |+ Single label | | | |+ Location freedom | | | |- Need standard extension | | | |- Use scarce resource | +---+---------------------------+---------------------------------+ | 2 | XL(15) + EHL |+ Location freedom | | | |+ Established mechanism | | | |+ Abundant resource | | | |- One extra label than Option 1 | | | |- Need standard extension | +---+---------------------------+---------------------------------+ | 3 | GAL + ACH with channel |+ Reuse existing mechanism | | | type extension |+ Abundant resource | | | |- Label location limitation | | | |- One more word than Option 1 | | | |- Not for user traffic | | | |- Need standard extension/update | +---+---------------------------+---------------------------------+ | 4 | GAL + another nibble value|+ No change to ACH semantics | | | to indicate EHs (e.g., |+ Potential overhead saving | | | "0010") |- Label location limitation | | | |- Hack scarce resource (nibble) | | | |- Need standard extension | +---+---------------------------+---------------------------------+ | 5 | Extend ELI/EL |+ No need for new label | | | |- Need standard update | | | |- Need to make EL mandatory | | | |- One extra label than Option 1 | +---+---------------------------+---------------------------------+ | 6 | FEC label as EH indicator |+ No need for header standard | | | |- Complex control plane | | | |- Cross-domain interoperability | | | |- Label space issue | | | |- Not for incremental deployment | +---+---------------------------+---------------------------------+
Basically we have three groups of solutions. The scheme 1 and 2 introduce new labels, the scheme 3, 4, and 5 extend the existing solutions, and the scheme 6 relies on the control plane. Through comprehensive considerations on the pros and cons of each scheme, we expect a working group consensus can be reached to pick the final winner.¶
The existence of Extension Headers will make the ECMP based on inner IP packet header impossible or harder. If legacy routers need to conduct this kind of ECMP, the process either fails or generates unexpected results. EH-aware routers can do this kind of ECMP but they need to skip all the EHs in order to access the inner packet header which may not be efficient (we make provision in HEH to help accelerate this process). In this case, the Entropy Label (EL) is preferred for ECMP. The Entropy Label Indicator (ELI) and EL should be put in front of the EHI to avoid confusing the legacy routers.¶
If the EHL approach is adopted to indicate the presence of MPLS extension header(s), this document requests IANA to assign one or more new Special-Purpose MPLS Label Values from the Special-Purpose Multiprotocol Label Switching (MPLS) Label Values Registry of "Extension Header Label (EHL)".¶
The other contributors of this document are listed as follows.¶
TBD.¶