]> Cisco Systems, Inc.

Canada jrajaman@cisco.com

Cisco Systems, Inc.

Canada rgandhi@cisco.com

Broadcom

royi.zigler@broadcom.com

Futurewei Technologies

haoyu.song@futurewei.com

Juniper Networks

United States kireeti.ietf@gmail.com

MPLS Working Group This document defines the MPLS Network Action (MNA) Header encoding formats to carry Network Actions and optionally Ancillary Data in the label stack and post label stack. The MPLS Network Action can be used for example, to influence the forwarding decisions or to carry additional OAM information in the MPLS packet. This document addresses the MNA requirements specified in draft-ietf-mpls-mna-requirements. This document follows the MNA framework specified in draft-ietf-mpls-mna-fwk.

Introduction defines MPLS Header for carrying a stack of MPLS labels which are used to forward packets in an MPLS network. Today's new applications require the MPLS packets to carry network action indicators and optional Ancillary Data (AD) that can be used for example, in MPLS packet forwarding decision or for OAM purpose. Ancillary Data can be used to carry additional information, for example, a network slice identifier, In-Situ OAM (IOAM) data, etc. Several MNA applications are described in . This document defines a solution to encode MPLS Network Actions (MNA) in an MPLS Label Stack those are efficient to process in hardware. The MPLS Network Actions are encoded in the form of flags and opcodes. These MPLS Network Actions can be encoded without Ancillary Data (AD) or with In-Stack Ancillary Data (ISD) or with Post-Stack Ancillary Data (PSD) (i.e., after the Bottom of the Stack (BOS)). A new base Special Purpose Label (bSPL) (value TBA1) is to be assigned to indicate the presence of MPLS Network Action Sub-Stack (MNAS) in the MPLS packet. This document addresses the MNA requirements specified in . This document follows the MNA framework specified in .

Conventions Used in This Document

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when, and only when, they appear in all capitals, as shown here.

Abbreviations The MNA terminology defined in and are used in this document.

• AD: Ancillary Data.
• BOS: Bottom Of Stack.
• IHS: I2E, HBH, Select Scope.
• I2E: Ingress-To-Egress.
• HBH: Hop-By-Hop Scope.
• ISD: In-Stack Data.
• IS-NA: In-Stack Network Action.
• IS-NAI-Opcode: In-Stack Network Action Opcode.
• LSE: 32-bit Label Stack Entry.
• MPLS: Multiprotocol Label Switching.
• MNA: MPLS Network Action.
• NAI: Network Action Indicator.
• NAI-OP: Network Action Indicator Opcode.
• NAL: Length of Network Action in number of LSEs, excluding the LSE for Opcode.
• NASL: Length of Network Action sub-stack in number of LSEs.
• NASI: Network Action Sub-Stack Indicator.
• NASS: Network Action Sub-Stack.
• PS-NA: Post-Stack Network Action.
• P,H: Post-Stack Network Action Presence and Post-Stack Hop-By-hop presence Indicator.
• PSD: Post-Stack Data.
• bSPL: Base Special Purpose Label in the range of 0-15.
• TC: Traffic Class.
• TTL: Time To Live.

Overview The solution for encoding MPLS Network Actions includes two high-level parts as shown in Figure 1.

• 1. Network Action Sub-Stack Header - The Network Action Sub-Stack Indicator label indicates the presence of MPLS Network Action Sub-Stack in the MPLS label stack. The NASS encoding parameters indicate the structure of the NASS.
• 2. In-Stack Network Actions Encoding - The encoding in which the MPLS Network Actions are carried in the MPLS header. This includes Network Action Indicator (NAI) and Ancillary Data (AD). The Network Action can be In-Stack and Post-Stack.

Network Action Sub-Stack Header | ]]>

Both parts of the encoding solution are described below.

Network Action Sub-Stack Header Network Action Sub-Stack Header contains NASI Label and NASS encoding parameters as described below. NASI Label: A new bSPL value (value TBA1) is assigned to indicate the presence of the MPLS Network Action Sub-Stack (NASS). Note: The TC and TTL fields of the new bSPL are not re-purposed for NASS encoding parameters, as the penultimate node on the MPLS packet path may propagate TTL and TC fields from the transport (or forwarding) LSE to the next LSE on the label stack, overwriting the TTL and TC fields of the next LSE, as specified in Section 3.5 of . When the penultimate node is not aware of the NASI bSPL (value TBA1) e.g., in case of legacy network, this can cause NASS parameters in the TTL of the NASI label to be corrupted. NASS Encoding Parameters: The TTL field in the second LSE is used to encode NASS encoding parameters. The NASS encoding parameters contain scope and the length of NASS as well as presence flags for Post-Stack Network Action and Ancillary Data. NASS Scope: This indicates the scope (HBH / Select / I2E) of NASS for different nodes (e.g., midpoint nodes and egress node) where it needs to be processed. Separate NASS Per Scope: If a packet requires to carry both HBH and I2E scoped In-Stack NAs, then one NASS with scope of HBH and one NASS with scope I2E are added in the MPLS label stack. The I2E scoped NASS is added closer to the BOS whereas HBH and Select scoped NASS are added closer to the top of the label stack. This makes it easier for the midpoint nodes to process only the NASS with HBH scope in hardware.

• IHS (I2E, HBH, and Select Scope): This 2-bit value indicates the scope of In-Stack NAIs.

In-Stack NAI Scope Table

Bits	Scope
00	I2E
01	HBH
10	Select
11	Reserved

• P,H (Post-Stack Network Action Presence and Post-Stack Hop-By-hop processing Indicator):

• This is 2-bit flag, where "P" bit indicates the presence of Post-Stack Network Actions and "H" bit indicates the presence of Post-Stack Hop-By-Hop and/or Select processing scope options. While encoding the Post-Stack NAs, the HBH/Select scope NAs MUST be encoded first (closer to the BOS) and then I2E.

NASL (Network Action Sub-Stack Length): This is a 4-bit field in the TTL. This indicates the total length of the current NASS. This value does not include the first two LSEs in the NASS. This value is used by the ASICs to process the NASS. NAL (Network Action Length): The 2-bit field in TC is used to carry the number of additional LSEs used to carry the Ancillary Data for the Network Action. It does not include the 1st LSE that contains the NAI-Opcode. In the case where the node does not support the NAI-Opcode value, the NA length is used to skip the NAI-Opcode and move to the next Opcode and continue processing. R bit: R bit in the TC field is Reserved for future use.

In-Stack Network Action Encoding The MPLS Network Action encoding carried as part of the MPLS label stack uses Opcodes for indicating Network Actions (called NAI-Opcodes). The encoding format defined is flexible (e.g., stackable opcodes in desired order), extensible (by defining new NAI-Opcodes) and ASIC friendly (by using Sub-Stack Length, Opcode and Data in the same LSE). This encoding format also allows to carry the Flag-Based NAIs that do not require AD and the Flag-Based NAIs that require AD in the same packet. The opcode method of identifying a specific Network Actions are common in today's hardware ASICs (Similar to any IPv4/IPv6/VxLAN header processing), so this method is easy to be adopted by the existing hardware. This will allow the hardware ASICs to serially or in-parallel process the Network Actions.

MPLS Label Stack Entry (LSE) Format

In-Stack Network Actions are encoded in the TLV format. NAI-Opcode represents NA Indicator Type, NAL represents NA Length and Ancillary Data represents NA Value.

• It uses MPLS Label field to carry the Network Action Indicator Opcode and associated In-Stack Ancillary Data (can be NAI Flags).
• It uses Traffic Class (TC) field to carry the Length of the In-Stack Network Action's Ancillary Data.
• It uses MPLS Label and Time-To-Live (TTL) fields to carry the In-Stack Ancillary Data (can be NAI Flags).

NAI-Opcode: This is the first 8-bit value in the Label Field. Ancillary Data: This is the additional Data carried to process the Network Action specified by the NAI-Opcode.

• The 12 bits of the Label field is used to carry the Ancillary Data
• Apart from the Label field, part of AD is also carried in the 8-bit TTL field except for the 2nd LSE in the NASS. If an application needs only 12-bit of AD, then 2nd LSE can be used for NAI-Opcode otherwise it can use the next LSE for 20-bit of AD.
• Some applications need to change the Ancillary Data for the same flow, in those cases the data is encoded in the the TTL field.

NOTE: ECMP Hash Using Label Stack:

• A midpoint node may use the entire MPLS Label Stack for ECMP hash computation hence the In-Stack MPLS extension header MUST NOT change the Label Field part of the Ancillary Data within the same traffic flow. But the TTL part of In-Stack Ancillary Data can change for the same traffic flow without affecting the ECMP hash. The In-Stack Network Action encoding defined above ensures this.

Reserved In-Stack MPLS Network Action Opcodes This opcode ranges from 1 to 255. NAI-Opcode value of 0 is marked as invalid to avoid the label value from aliasing with the reserved bSPLs. Some of the opcodes are reserved as described below for the basic functionality and the rest of the opcodes are assigned by IANA.

• IS-NAI-Opcode Value:1 (PSD Offset) - Opcode reserved to indicate the start offset of the Post-Stack Network Actions header after the MPLS Label Bottom of the Stack. This can allow to carry Generic Control Word (0000b) and G-ACh (0001b) [RFC5586] fields immediately after the BOS. Adding of this opcode is not required when the BOS data starts immediately after the Bottom of the Label Stack (i.e. when offset is 0)

• IS-NAI-Opcode Value:2 (Flag-Based NAIs with No AD) - Opcode reserved to carry the Flag-Based NAIs those do not require Ancillary Data. These NAI flag bits are carried in the Ancillary Data field of the Opcode.

In-Stack Flags-Based NA Encoding Format

• The Flags bit position for a specific application will be maintained and allocated by IANA.

• IS-NAI-Opcode Value:3 (Flag-Based NAIs with ADs) - Opcode reserved to carry the Flag-based NAIs with ADs in the next LSEs.

In-Stack Flag-Based NAs with Ancillary Data

• The NASS is carrying the reserved opcode 3 for Flags-Based NAIs that require ADs.

• IS-NAI-Opcode Value:4 (PSD Network Action Indicator Opcode) - Opcode reserved to indicate that a specific Post-Stack Network Action has to be executed in order with respect to the In-Stack Opcode.

In-Stack PSD Opcode Indicator Encoding Format

• A NAI-Opcode 4 is reserved to carry Post-Stack NA as AD. This NAI-Opcode can be used to specify the ordering between In-Stack and Post-Stack Network Actions.

• IS-NAI-Opcode Value:5-254 (Application Defined Opcode) - MUST be assigned by IANA. When this opcode is allocated for a specific applications Network Action, the respective application MUST define the Ancillary Data format and other required attributes like functionality, scope (I2E / HBH/ SEL) of the Network Action.
• IS-NAI-Opcode Value:255 (Extended Opcode) - IANA Allocated for IS-NAI-Opcode range extension. This gives the extensibility for opcode range beyond 255. The Extended 8-bit opcode value will be encoded next to base opcode value 255.

In-Stack Extended Opcode Encoding Format

• In the above example, the extended Opcode "9" is encoded in the packet. In this case only 12 bits of AD could be encoded in the same LSE, if the application requires to encode more than 12 bits then it had to use next LSE to encode the rest of the AD.

Post-Stack MPLS Network Action Encoding Based on the P and H flags, the Post-Stack Network Actions are processed. The details of the Post-Stack Network Action Extension Header encoding is specified in .

Network Action Processing Order Depending on the application, each NA will be processed at different stages of the ASICs pipeline. But in some cases, there may be contention between processing two NAs at the same stage of ASICs, in those cases the processing order should be maintained, so that the result of the packet forwarding and OAM data collection will be predictable.

In-Stack NA Processing Order This section talks about maintaining the ordering between the In-Stack NA processing. The order of processing the NA should follow the order of NAs encoded in the NASS.

Example In-Stack NA Processing Order

In the above example, a node will process the Flags-Based-NAIs first and then the NAI-Opcode "5". In some cases, some Flag-Based NAIs may need to be processed before the NAI-Opcode "5" and some Flag-Based NAIs may need to be process after the NAI-Opcode "5".

Example In-Stack NA Processing Order

In the above example, the Flag-Based NAI "0x1" is processed before the NAI-Opcode "5" and the Flags-Based NAI "0x2" is processed after the NAI-Opcode "5".

Post-Stack NA Processing Order Post-Stack NAs follow ordering specified in .

Mix of In-Stack and Post-Stack NA Processing Order In some cases, Post-Stack NA needs to be processed before In-Stack NA. This section describes how to prioritize the Post-Stack NAs over the In-Stack NAs.

Example Post-Stack and In-Stack NA Processing Order

In the above example, the Flag-Based NAIs required to be processed first, followed by the Post-Stack NA "6" and then In-Stack NAI-Opcode "5". The NAI-Opcode "4" is a reserved opcode which can be used for ordering between the In-Stack and Post-Stack. In this example, the AD field of the NAI-Opcode "4" carries the Post-Stack NA that is processed before processing the NAI-Opcode "5".

Handling of Unsupported Network Actions When a node encounters an unsupported NAI-Opcode in the NASS it is processing, the node skips processing that NAI-Opcode using the NAL field and moves to processing the next NAI-Opcode. When a node encounters a Flag-based NAI that it doesn’t support, it stops further processing the Flag-Based NAIs in that NAI-Opcode. This is because the Flag-Based NAI may or may not have AD and a node will not be able to know the length for each Flag-Based-NAI. The node MUST NOT drop the packet when it encounters any NA in the MNA NASS that it does not support.

MNA for Segment Routing Label Stack For packets with Segment Routing [RFC8662] MPLS label stack, a copy of NASS with HBH and Select scope is placed at regular depth throughout the MPLS label stack, with the understanding that the current copy of the NASS will eventually rise to the top of the label stack. For HBH scope, every node processes the current copy of the NASS and the node that pops the forwarding label that exposes the NASS will not remove it but forward it to the next node (i.e., segment endpoint node). The segment endpoint node that receives the NASS at the top of the label stack has to remove it. For I2E scope, only one copy of NASS needs to be added and it is added near the bottom of the stack.

Node Capability Signaling The node capability for the MPLS Network Action must be signaled before the MPLS Encapsulating node can add the necessary MPLS Network Action in the MPLS Label Stack. The capability signaling will be added in LDP, RSVP-TE, BGP, IS-IS, OSPF, BGP-LS, etc. This is outside the scope of this document.

Security Considerations The security considerations in also apply to the procedures defined in this document. The NASI Label (bSPL TBA1) MUST NOT be exposed on the node which does not support it.

Backward Compatibility

• For the legacy node that does not advertise the MPLS Network Action capability, the Encapsulating node MUST make sure that the MPLS Network Action Sub-Stack indicator is not at the top of the MPLS Label Stack to avoid dropping the packets. Based on the signalling, if the MPLS egress node is not capable of the processing MPLS Network Actions then it should not add MNA in the packet. In the worst case, if the legacy routes that does not understand the new bSPL allocated then those routers will drop the packets.
• The MPLS Network Action Encoding format is designed to make sure that it does not alias with any reserved bSPL.
• The MPLS Network Actions can co-exist with the existing GAL / G-ACh based encoding of data.
• The TC and TTL fields of the NASI bSPL are not re-purposed for encoding, as the penultimate node on the MPLS packet path may propagate TTL from the transport (or forwarding) label to the next label on the label stack, overwriting the TTL on the next label. When the penultimate node is not aware of the NASI bSPL (value TBA1), this can cause encoding format flags in the TTL of the NASI (label TBA1) label to be corrupted.

Processing In-Stack MPLS Network Actions Encapsulating Node:

• MUST NOT add In-Stack MPLS Network Action Sub-Stack if the decapsulation node is not capable of In-Stack MPLS Network Action.
• SHOULD NOT change the IS-NAI-Opcode and the first 12 bits of the In-Stack Ancillary Data for the same packet flow to avoid ECMP path change.
• MAY change In-Stack Ancillary Data part present only in the TTL field for the same packet flow.
• MUST ensure that the penultimate node does not remove the NASS.

Midpoint Node:

• MUST ignore the IS-NAI-Opcode that are not supported.
• MUST NOT add In-Stack NASS if the decapsulation node is not capable of In-Stack MPLS Network Actions.
• SHOULD NOT change the IS-NAI-Opcode and the first 12 bits of the In-Stack Ancillary Data for the same packet flow.
• MAY change In-Stack Ancillary Data part present only in the TTL field for the same packet flow.
• MAY remove the IS-NAI-Opcode and its Ancillary Data for all matching packet flow.

Penultimate Node:

• MUST ignore the IS-NAI-Opcode that are not supported.
• MUST NOT remove the NASS when it is exposed after removing the forwarding (transport) label.

Decapsulating Node:

• MUST remove the MPLS Network Action Sub-Stack.

IANA Considerations Below are the IANA actions which this document is requesting. The registries created by this document will be collected in a new registry grouping called “MPLS Network Action,” which will be located at https://www.iana.org/assignments/mpls-network-action.

IANA Considerations for MNA NASS Encoding Parameters IANA is requested to create a new registry with name "MNA NASS Encoding Parameters" to assign the bit position and the meaning to the Parameters that re-purpose TTL and TC fields in the Label Stack Entry (LSE). MNA NASS Encoding Parameters Registry

Bit Position	Description	Reference
20-31	IETF Review	This document

Following NASS Encoding Parameter values are assigned from this registry. MNA NASS Encoding Parameter Values

Value	Description	Reference
28-31	In-Stack Network Action Sub-Stack Length (NASL)	This document
26-27	In-Stack Scope value E2H/HBH/SEL(IHS)	This document
25	Post-Stack Hop-By-Hop Processing Indicator	This document
24	Post-Stack Network Action Presence Indicator	This document
23	End of Stack (S)	RFC 3032
21-22	In-Stack Network Action Length (NAL)	This document
20	Reserved Bit (R)	This document

IANA Considerations Flag-Based Network Actions IANA is requested to create a new registry with name "In-Stack MPLS Network Action Indicator Flags" to assign a bit position and the meaning to the Flag-Based Network Action upon the user request. Based on the need this registry can be extended beyond 12 bit positions. In-Stack MPLS Network Action Indicator Flags Registry

Bit Position	Description	Reference
11-0	Unassigned	This document

IANA Considerations for I2E and HBH/Select IS-NAI-Opcode IANA is requested to create a new registry with name "I2E In-Stack MPLS Network Action Indicator Opcodes" to assign IS-NAI-Opcode values. All code-points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure as specified in . Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in . Remaining code-points are allocated according to : I2E In-Stack MPLS Network Action Indicator Opcodes Registry

Value	Description	Reference
0 - 175	IETF Review	This document
176 - 239	First Come First Served	This document
240 - 251	Experimental Use	This document
252 - 254	Private Use	This document

Following I2E IS-NAI-Opcode Indicator values are assigned from this registry. I2E In-Stack Network Action Indicator Opcode Values

Value	Description	Reference
0	Reserved	This document
1	Offset of start of Post-Stack Network Action Header	This document
2	Flag-Based Network Action Indicators with No AD	This document
3	Flag-Based Network Action Indicators with AD	This document
4	Post-Stack Network Action Indicator	This document
255	Opcode Range Extension Beyond 255	This document

IANA is requested to create a new registry with name "HBH and Select In-Stack MPLS Network Action Indicator Opcodes" to assign IS-NAI-Opcode values. This registry is also used for Select scope. All code-points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure as specified in . Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in . Remaining code-points are allocated according to : HBH and Select In-Stack MPLS Network Action Indicator Opcodes Registry

Value	Description	Reference
0 - 175	IETF Review	This document
176 - 239	First Come First Served	This document
240 - 251	Experimental Use	This document
252 - 254	Private Use	This document

Following HBH and Select IS-NAI-Opcode Indicator values are assigned from this registry. HBH and Select In-Stack Network Action Indicator Opcode Values

Value	Description	Reference
0	Reserved	This document
1	Offset of start of Post-Stack Network Action Header	This document
2	Flag-Based Network Action Indicators with No AD	This document
3	Flag-Based Network Action Indicators with AD	This document
4	Post-Stack Network Action Indicator	This document
255	Opcode Range Extension Beyond 255	This document

IANA Considerations for NASI bSPL Label IANA is requested to allocate a value TBA1 for the NASI bSPL label from the "Base Special-Purpose MPLS Label Values" registry to indicate the presence of MNA Sub-Stack in MPLS header.

Appendix

Network Action Encoding Examples

Example-1 - Flag-Based In-Stack NA without AD

Example NASS with In-Stack Network Action Encoding Carrying Flag-Based NA

Second LSE: Label Field:

• NAI-Opcode is set to "2".
• Next 12 bits are used to encode the Flag-Based Network Actions that do not need Ancillary Data. Each bit encoded is a unique Flag-Based Network Action. This bit position will be assigned by IANA. For example, an application A can be allocated Flag position as "2" and another application B can be allocated Flag position as "5". If application A and B needs to set their Network Actions then the bit positions "2" and "5" will be set to 1.

TC Field:

• NAL - This value depends on the number of LSEs carrying the NAI Flags in the MPLS In-Stack header is carrying. In this case, the packet is carrying only bit position "1" and "3", both in one LSE, the NAL will be set to "0".

TTL Field:

• NASL value is set to "0" as no additional LSEs are encoded.

Example NASS carrying Flag-Based NA with more than 12 Flags

In this example, let us assume that an application-C has been allocated a Flag position of "21" by IANA, If the application-C needs to execute its Network Action on the MPLS packet then the 2nd bit in the third Label field will be set to indicate the Flags position "13". NAL is set to "1" indicates the Flag-Based NAIs are also encoded in the next LSE. NASL is set to "1" indicates the additional In-Stack LSE is encoded. While encoding the Additional Ancillary Data in the 3rd LSE, the Most Significant bit MUST be set to "1" to prevent from aliasing with the reserved bSPLs.

Example-2 - In-Stack NA with 12-bit AD

Example NASS carrying In-Stack Network Action that requires Ancillary Data

In this example, the NASS is carrying only the In-Stack Network Action that requires 12-bit Ancillary Data. The 8-bit value contains the NAI-Opcode. Next 12 bits carries the AD for the NAI-Opcode "6". No additional LSE is encoded so NAL value is set to "0".

Example-3 - Carry only Post-Stack NA Indicator

Example NASS carrying only Post-Stack NA Indicator

In this example, the NASS is carrying only the indicator for the presence of Post-Stack NA and its Hop-By-Hop Option. In this case only "P" and "H" bits are set to "1" as required.

Example-4 - In-Stack NA with more than 20-bit AD An In-Stack Network Action may require more than 20 bits of Ancillary Data. In this example, the following Ancillary Data encoding is used.

Example In-Stack Network Action With Additional Ancillary Data Encoding Format

In this example, the In-Stack NAI-Opcode "8" requires more than 20 bits of Ancillary Data to be encoded. The NA and AD are encoded in the 3rd and 4th LSEs. Third LSE: Label Field

• The 8-bit in the Label Field carries the NAI-Opcode value "8".
• Next 12 bits in the Label Field carries the part of AD.

TC Field

• The 2-bit of the TC field carries Network Action Length (NAL). In this case, since it uses additional LSE to carry its AD the NAL value is set to "1".

TTL Field

• This 8-bit field carries second part of the AD.

Fourth LSE: Label Field

• The first bit in the Label field MUST be set to "1". This is to prevent aliasing the label field with other bSPLs on the legacy routers. The AD value encoded could vary and it cannot be controlled. If we assume in the above example, the application encodes the 4th LSEs Label field as value "7", then legacy node could miss-understood for Entropy label indicator and may start processing the packet accordingly, which could end-up in wrong packet forwarding behaviour.
• Next 19 bits in the Label field carries 3rd part of AD.

TC Field

• 3-bit TC field carries the continuation of 3rd part of AD.

TTL Field

• 8-bit TTL field carries the rest of AD.

Example-5 - Carry Both I2E and HBH Scope NASS

Example NASS carrying Both I2E and HBH Scope NAs

In this example, one NASS is added for HBH scope with IHS field set to 01b and another NASS is added for I2E scope with IHS field set to 00b.

Example-6 - Carry Both Select and HBH Scope NASS

Example NASS carrying Both Select and HBH Scope NAs

In this example, one NASS is added for HBH scope with IHS field set to 01b and another NASS is added for Select scope with IHS field set to 10b.

References Normative References Informative References Futurewei Technologies Huawei Huawei Bronze Dragon Consulting Juniper Networks Cisco Systems Cisco Systems Cisco Systems Nokia University of Surrey 5GIC Juniper Networks Juniper Networks Futurewei Technologies Futurewei Technologies

Acknowledgments The authors of this document would like to thank the MPLS Working Group Design Team for the discussions and comments on this document. The authors would also like to thank Amanda Baber for reviewing the IANA Considerations and providing many useful suggestions.

Contributors The following people have substantially contributed to this document: