]> IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack Juniper Networks
1133 Innovation Way Sunnyvale CA 94089 United States of America kireeti.ietf@gmail.com
University of Surrey 5GIC
sb@stewartbryant.com
Nokia
matthew.bocci@nokia.com
Ericsson
gregimirsky@gmail.com
Huawei Technologies
loa@pi.nu
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China jie.dong@huawei.com
RTG mpls This document creates a new IANA registry (called the "Post-Stack First Nibble" registry) for the first nibble (4-bit field) immediately following an MPLS label stack. Furthermore, this document presents some requirements for registering new values and making the processing of MPLS packets easier and more robust. The relationship between the IANA "Post-Stack First Nibble" registry and the "IP Version Numbers" registry (RFC 2780) is described in this document. This document updates RFC 4928 by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS.
Introduction An MPLS packet consists of a label stack, an optional Post-Stack Header (PSH), and an optional embedded packet (in that order). Examples of PSHs include existing headers such as control words , BIER (Bit Index Explicit Replication) headers and the like, as well as new types of PSH being discussed by the MPLS Working Group. However, in the data plane, there are very few clues regarding the PSH and no clue as to the type of embedded packet; this information is communicated via other means, such as the routing protocols that signal the labels in the stack. Nonetheless, in order to better handle an MPLS packet in the data plane, it is common practice for network equipment to "guess" the type of embedded packet. Such equipment may also need to process the PSH. Both of these require parsing the data after the label stack. To do this, the "first nibble" (the top four bits of the first octet following the label stack) is often used. Although some existing network devices may use such a method, it needs to be stressed that the correct interpretation of the Post-stack First Nibble (PFN) in a PSH can be made only in the context established through the control or management plane with the Label Stack Entry (LSE) or group of LSEs in the preceding label stack that characterizes the type of the PSH. Any attempt to rely on the value in any other context is unreliable. Because the PFN value should not be used to deduce the type of PSH by itself and the space of PFN values is limited, the reuse of PFN values is encouraged when possible. The semantics and usage of the first nibble are not well documented, nor are the assignments of values. This document serves four purposes:
  • To document the values already in use.
  • To provide a mechanism to document future assignments through the creation of a new IANA "Post-Stack First Nibble" registry and describe the relationship between it and the IANA "IP Version Numbers" registry .
  • Provide a method for tracking usage by requiring more detailed documentation.
  • To stress that any MPLS packet not carrying plain IPv4 or IPv6 packets contains a PSH. This also applies to packets of any new version of IP (see ).
of this document includes an analysis of load-balancing techniques; based on this, introduces a requirement that deprecates the use of the heuristic method for identifying the type of packet encapsulated in MPLS and recommends using a dedicated label value for load balancing. The intent is for legacy routers to continue operating as they have, with no new problems introduced as a result of this document. However, new implementations that follow this document enable more robust network operation. Furthermore, this document updates by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS. This document clearly states that the type of encapsulated packet cannot be determined based on the PFN alone.
Requirements Language 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 when, and only when, they appear in all capitals, as shown here.
Definitions
Deprecation:
Regardless of how the deprecation is understood in other IETF documents, the interpretation in this document is that if a practice has been deprecated, that practice should not be included in new implementations or deployed in new deployments.
Embedded Packet:
A packet that follows immediately after the MPLS label stack and an optional PSH. The embedded packet could be an IPv4 or IPv6 packet, an Ethernet packet (for Virtual Private LAN Service (VPLS) or EVPN ), or some other type of Layer 2 frame .
Label Stack:
A label stack is represented as a consecutive sequence of "label stack entries" (four-octet fields) after the Layer 2 header but before any network layer header. The last label stack entry of a label stack has its Bottom of Stack bit set.
MPLS Packet:
A packet whose Layer 2 header declares the type to be MPLS. For example, the Ethertype is 0x8847 or 0x8848 for Ethernet, and the Protocol field is 0x0281 or 0x0283 for PPP.
MPLS Payload:
All data after the label stack and any optional PSHs. It is possible that more than one type of PSH may be present in a packet, and some PSH specifications might allow multiple PSHs of the same type. The presence rules for multiple PSHs are a matter for the documents that define those PSHs, e.g., .
Post-stack First Nibble (PFN):
The most significant four bits of the first octet following the label stack.
Post-Stack Header (PSH):
A field containing information that may be of interest to the egress Label Switching Router (LSR) or transit LSRs. Examples include a control word or an associated channel header .
Abbreviations
BIER:
Bit Index Explicit Replication
FAT:
Flow-Aware Transport
LSE:
Label Stack Entry
LSR:
Label Switching Router
MNA:
MPLS Network Action
PFN:
Post-stack First Nibble
PSH:
Post-Stack Header
PW:
Pseudowire
SPL:
Special-Purpose Label
Reference Figures echoes the format of MPLS packets as defined in where TC indicates the Traffic Class field that replaced the EXP (Experimental Use) field, S is the Bottom of Stack flag, and TTL is the Time to Live field.
Example of an MPLS Packet with Label Stack
Examples of an MPLS Packet Payload With and Without a Preceding Post&nbhy;Stack Header
shows an MPLS packet with a Layer 2 header X and a label stack Y ending with Label-n. displays three examples of an MPLS payload:
Example A:
The first payload is a bare IP packet, i.e., no PSH. The PFN in this case overlaps with the IP version number.
Example B:
The next payload is a bare non-IP packet; again, no PSH. The PFN here is the first nibble of the payload, whatever it happens to be.
Example C:
This example is an MPLS Payload that follows a PSH. Here, the embedded packet could be IP or non-IP.
Thus, the complete MPLS packet would consist of [X Y A], [X Y B], or [X Y C].
Rationale
Why Look at the First Nibble An MPLS packet can contain one of many types of embedded packets. Three common types are:
  1. An IPv4 packet (whose IP header has version number 4).
  2. An IPv6 packet (whose IP header has version number 6).
  3. A Layer 2 Ethernet frame (i.e., not including the Preamble or the Start frame delimiter), starting with the destination Media Access Control (MAC) address.
Many other packet types are possible; in principle, any Layer 2 embedded packet is permissible. Indeed, at some points in time, packets of the Point-to-Point Protocol, Frame Relay, and Asynchronous Transfer Mode were reasonably common and may become so again. In addition, there may be a PSH ahead of the embedded packet. The value of PFN is considered to ensure that the PSH can be correctly parsed.
ECMP Load Balancing There are four common ways to load balance an MPLS packet:
  1. Use the top label alone.
  2. Use all of the non-SPLs in the stack. This is better than using the top label alone.
  3. "Divine" the type of embedded packet and use fields from the guessed header. The ramifications of using this load-balancing technique are discussed in detail in . This way is better than the two ways above.
  4. Use either an Entropy Label or a Flow-Aware Transport (FAT) Pseudowire Label (see ). This is the best way.
Load balancing based on just the top label means that all packets with that top label will go the same way, which is far from ideal. Load balancing based on the entire label stack (not including SPLs) is better, but it may still be uneven. However, if the embedded packet is an IP packet, then the combination of (<source IP address>, <dest IP address>, <transport protocol>, <source port>, and <dest port>) from the IP header of the embedded packet forms an excellent basis for load balancing. This is what is typically used for load balancing IP packets. An MPLS packet doesn't, however, carry a payload type identifier. There is a simple (but risky) heuristic that is commonly used to guess the type of the embedded packet. The first nibble of an IP header, i.e., the four most significant bits of the first octet, contains the IP version number. That, in turn, indicates where to find the relevant fields for load balancing. The heuristic goes roughly as described in .
Heuristic for ECMP Load Balancing
  1. If the PFN is 0x4 (0100b), treat the payload as an IPv4 packet, and find the relevant fields for load balancing on that basis.
  2. If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet, and find the relevant fields for load balancing on that basis.
  3. If the PFN is anything else, the MPLS payload is not an IP packet; fall back to load balancing using the label stack.
This heuristic has been implemented in many (legacy) routers and performs well in the case of example A in . However, this heuristic can work very badly for the non-IP packet as shown in example B in . For example, if payload B is an Ethernet frame, then the PFN is the first nibble of the Organizationally Unique Identifier of the destination MAC address, which can be 0x4 or 0x6. This would lead to the packet being treated as an IPv4 or IPv6 packet such that data at the offsets of specific relevant fields would be used as input to the load-balancing heuristic, resulting in unpredictable load balancing. This behavior can happen to other types of non-IP payloads as well. That, in turn, led to the idea of inserting a PSH (e.g., a pseudowire control word , a Deterministic Networking (DetNet) control word , a Network Service Header (NSH) , or a BIER header ) where the PFN is not 0x4 or 0x6; this explicitly prevents forwarding engines from confusing the MPLS payload with an IP packet. recommends the use of a control word when the embedded packet is an Ethernet frame. was published at the request of the operator community and the IEEE Registration Authority Committee as a result of operational difficulties with pseudowires that did not contain the control word. Where load balancing of MPLS packets is desired, it is RECOMMENDED that the load-balancing mechanism use the value of a dedicated label, for example, either an Entropy Label or a FAT Pseudowire Label . Furthermore, the heuristic of guessing the type of the embedded packet, as discussed above, SHOULD NOT be used. A consequence of the heuristic approach is that while legacy routers may look for a PFN of 0x4 or 0x6 , no legacy router will look for any other PFN for load-balancing purposes, regardless of what future IP version numbers will be. This means that the values 0x4 and 0x6 are used to (sometimes incorrectly) identify IPv4 and IPv6 packets, but no other PFN values will be used to identify IP packets. This document creates a new registry for all 16 possible values (see ).
Updates to RFC 4928 The text in RFC 4928 concerning the first nibble after the MPLS label stack has been updated by this document, and the heuristic for snooping this nibble has been deprecated. is updated as follows: OLD TEXT:
It is REQUIRED, however, that applications depend upon in-order packet delivery restrict the first nibble values to 0x0 and 0x1. This will ensure that their traffic flows will not be affected if some future routing equipment does similar snooping on some future version(s) of IP.
NEW TEXT:
Network equipment MUST use a PSH (Post-Stack Header) with a PFN (Post-stack First Nibble) value that is neither 0x4 nor 0x6 in all cases where the MPLS payload is neither an IPv6 nor an IPv4 packet.
The following requirement (discussed is ) replaces paragraph 4 in as follows: OLD TEXT:
This behavior implies that if in the future an IP version is defined with a version number of 0x0 or 0x1, then equipment complying with this BCP would be unable to look past one or more MPLS headers, and loadsplit traffic from a single LSP across multiple paths based on a hash of specific fields in the IPv0 or IPv1 headers. That is, IP traffic employing these version numbers would be safe from disturbances caused by inappropriate loadsplitting, but would also not be able to get the performance benefits.
NEW TEXT:
The practice of deducing the payload type based on the PFN value is deprecated to avoid inaccurate load balancing. This MUST NOT be part of new implementations or deployments. This also means that concerns about load balancing for future IP versions with a version number of 0x0 or 0x1 are no longer relevant.
Furthermore, the following text is appended to : NEW TEXT:
PSH:
Post-Stack Header
PFN:
Post-stack First Nibble
Why Create a Registry The framework for MPLS Network Actions (MNAs) is described in and is an enhancement to the MPLS architecture. The use of Post-Stack Data (PSD) to encode the MNA indicators and ancillary data (described in ) might place data in the PFN, which could conflict with other uses of that nibble. This issue is described in and is further illustrated by the PFN value of 0x0, which has two different formats depending on whether the PSH is a pseudowire control word or a DetNet control word; disambiguation requires the context of the service label. With a registry, PSHs become easier to identify and parse. In addition, they do not need a means outside the data plane to interpret them correctly, and their semantics and usage are documented and referenced in the registry.
IP Version Numbers Versus Post-Stack First Nibble Values The use of the PFN stemmed from the desire to heuristically identify IP packets for load-balancing purposes. It was then discovered that non-IP packets, misidentified as IP when the heuristic failed, were being badly load balanced, leading to the scenario described in . This situation may confuse some as to the relationship between the "Post-Stack First Nibble" registry and the "IP Version Numbers" registry. These registries are quite different:
  1. The explicit purpose of the "IP Version Numbers" registry is to track IP version numbers in an IP header.
  2. The purpose of the "Post-Stack First Nibble" registry is to track PSH types.
The only intersection points between the two registries are the values 0x4 and 0x6 (for backward compatibility).
Next Step to More Deterministic Load Balancing in MPLS Networks Network evolution is impossible to control, but it develops over a period of time determined by various factors. This document discourages further proliferation of the implementations that could lead to undesired effects on data flows. In doing so, it limits the scope of future protocol developments and thus helps to ensure that future network evolution will be smoother. suggests the use of a PSH solely for the purpose of avoiding IP ECMP treatment of non-IP payloads encapsulated in MPLS. Obsoleting this use of a PSH would assist with the progress toward a simpler, more coherent system of MPLS data encapsulation. (Other uses of a PSH may still be valid.) However, before that can be done, it is important to collect sufficient evidence that there are no marketed or deployed implementations using the heuristic practice to load balance MPLS data flows. Therefore, the next steps toward more deterministic load balancing in MPLS networks are to gradually deprecate non-PSH MPLS encapsulations of non-IP data, to cease using heuristic load balancing, and to survey the available and deployed implementations to determine when obsoletion may be achieved.
IANA Considerations Per this document, IANA has created a registry group called "Post-Stack First Nibble" that consists of a single registry called the "Post-Stack First Nibble" registry. The initial contents of the registry are shown in . The assignment policy is Standards Action . It is important to note that the same PFN value can be used in more than one protocol. The correct interpretation of the PFN in a PSH can be made only in the context of the LSE or group of LSEs in the preceding label stack that characterizes the type of the PSH and, consequently, the PFN. Post-Stack First Nibble Registry
Protocol Value Description Reference
DetNet 0x0 DetNet Control Word
NSH 0x0 NSH Base Header, payload
PW 0x0 PW Control Word
DetNet 0x1 DetNet Associated Channel
MPLS 0x1 MPLS Generic Associated Channel
PW 0x1 PW Associated Channel
NSH 0x2 NSH Base Header, OAM
0x3 Unassigned
0x4 Reserved RFC 9790
BIER 0x5 BIER Header
0x6 Reserved RFC 9790
0x7 - 0xF Unassigned
Security Considerations This document creates a new IANA registry for PFNs and specifies changes to the treatment of packets in the data plane based on the first nibble of data beyond the MPLS label stack. One intent of this is to reduce or eliminate errors in determining whether or not a packet being transported by MPLS is IP. While such errors have primarily caused unbalanced, and thus inefficient, multipathing, they have the potential to cause more severe security problems. For general security considerations involving the MPLS label stack, see .
References Normative References MPLS Network Actions (MNAs) Framework Huawei Technologies University of Surrey 5GIC Nokia Juniper Networks Informative References Post-Stack MPLS Network Action (MNA) Solution Cisco Systems, Inc. Cisco Systems, Inc. Broadcom Juniper Networks Huawei Technologies
Acknowledgements The authors express their appreciation and gratitude to for the review, insightful questions, and helpful comments. Also, the authors are grateful to for helping organize the IANA registry in a clear and concise manner. , , , , and provided helpful comments during IESG review. The authors would also like to thank for his patient and careful shepherding and for helping to finalize the text.