]> 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 TBA) 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.
• MMSID: Maximum MPLS Stack Inspection Depth.
• 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 (after the MNA Label and the second LSE).
• NASI: Network Action Sub-Stack Indicator.
• NASS: Network Action Sub-Stack.
• UOH: Unknown Opcode Handling.
• PS-NA: Post-Stack Network Action.
• P: Post-Stack Network Action 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

Network Action Sub-Stack Header

MPLS Network Action (MNA) Header Encoding contains two main parts: 1. Network Action Sub-Stack Header:

• a. MNA Label to indicate the presence of Network Action Sub-Stack (NASS).
• b. NASS Encoding parameters indicating the NASS scope, length, ordering, etc. parameters of the NASS.

2. In-Stack Network Action Encoding: In-Stack Network Action is encoded in the TLV format as following:

• a. Type - Network Action Indicator Opcode
• b. Length - Network Action Length (NAL)
• c. Value - Ancillary Data (Optional)

The detailed description of the MNA encoding solution is described below sections.

Network Action Sub-Stack Header Network Action Sub-Stack Header contains MNA Label and NASS encoding parameters as described below. MNA Label: A new bSPL value (value TBA) 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 MNA bSPL (value TBA) e.g., in case of non-MNA capable network, this can cause NASS parameters in the TTL of the MNA label to be corrupted. NASS Encoding Parameters: The TTL and TC field of the second LSE is used to encode NASS encoding parameters. The NASS encoding parameters contain the following.

• P-Bit (Post-Stack Network Action Presence Bit) - This bit indicates the presence of Post-Stack Network Actions.
• IHS (I2E, HBH and Select Scope): This 2-bit value indicates the scope of the In-Stack and Post-Stack NAIs encoded in that specific NASS.

In-Stack and Post-Stack NAI Scope Table

Bits	Scope
00	I2E
01	HBH
10	Select
11	Reserved

• 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.
• HBH (Hop-By-Hop) - This scope indicates that the NASS should be processed by the midpoint nodes as well.
• Select - This scope indicates that the NASS should be processed only on selected set of nodes.
• I2E (Ingress To Egress) - This scope indicates that the NASS Should be processed by the Egress node.
• Separate NASS Per Scope:
• Single NASS carries only one of the three scopes (HBH/SEL/I2E). MNA packet could carry more than one NASS scope, in those cases each scope is encoded as part of a single NASS. While encoding multiple NASS with the different scope, the I2E scope MUST be encoded after the HBH/SEL scope. This will make sure that the I2E scoped NASS is added closer to the BOS whereas HBH/SEL 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.

• NASL (Network Action Sub-Stack Length):

• This is a 4-bit value in the TTL field. This indicates the total length number of additional LSEs (not including the MNA Label and the second LSE) used to encoding the In-Stack NAIs for that specific NASS. This value is used by the node to pop the NASS or skip the processing NASS from the label stack.

• R-Bits:

• R bits in the TTL field is Reserved for future use.

• O-Bit (Ordering Bit):

• When O-Bit is set then it indicates that the NAIs MUST be processed in the order that is encoded in the NASS. If the Node is not capable of Processing the NAIs in the order then that specific packet MUST be dropped. Processing the NAIs in order is a complex process, some of the ASICs May not be capable of processing the NAIs in order, so this option gives the flexibility for the nodes to drop these packet, just by inspecting the O-Bit.

The second LSEs First 20-Bit field could be used to encode In-Stack NA that requires maximum of 13 bits of Ancillary data.

In-Stack MPLS Network Action Encoding

MPLS Label Stack Entry (LSE) Format

The In-Stack MPLS Network Action are encoded in the TLV format.

• a. Type - Network Action Indicator Opcode: This is the 7-Bit value used for indicating the Network Actions. This is also called as NAI-Opcode.
• b. Length - Network Action Length (NAL): This is the 2-Bit valued used of indicating additional number of LSEs used to encode additional Ancillary Data.
• c. Value - Ancillary Data (Optional): This is the optional Data that will be used while processing the NAIs.

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. The Base In-Stack Network Action Encoding formats are described in detail below: NAI-Opcode:

• This is the first 7-Bit value in the Label Field. This indicates the Network Action that needs to be executed. The Opcode value ranges from 1 to 127.

Ancillary Data: This is the additional Ancillary Data carried to process the Network Action specified by the NAI-Opcode.

• The 16 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 4-Bit TTL field.
• Some applications need to change the Ancillary Data for the same flow, in those cases the data is encoded in the the TTL field of the LSE.

UOH (Unknown Opcode Handling):

• This is a 2-Bit value that defines the action that needs to be taken by a node that does not understands this corresponding opcode value. In a brown field there are possibilities that some of the midpoint nodes may not understand a specific NA opcode, this 2-Bit value will indicate the actions that needs to taken. This action could be different for different NA opcodes. When the Network Action is defined by the application, the application MUST specify the "Unknown Opcode Handling". The different type of Unknown Opcode Handling Actions are defined below.

Unknown Opcode Handling Table

Bits	Actions
00	Skip and Process Next NA
01	Drop the packet
10	Stop processing MNA and forward the packet
11	Reserved

NOTE: ECMP Hash Using Label Stack:

• If the intermediate node changes any label field value for the same flow then it may affect the ECMP Flow. So the intermediate node MUST node change the Label field value for the same flow.

In-Stack MPLS Network Opcodes Allocation Procedure This section discusses about the procedures and requirement for an applications allocating a new In-Stack MPLS Network Opcode. The application May request for a new Network Action Indicator with AD or without AD. More information about the NAI without AD is described in the next section. The Network Action Opcode ranges from 0 till 127. There us an IANA registry maintained for allocating the In-Stack MPLS Network Action Opcodes. Opcode "0" is considered as an invalid opcode and a Packet received with the Opcode "0" MUST be dropped. Some of the opcodes are reserved for building the basic framework for MNA. Those reserved Network Action Opcodes are defined in the next section (This is described as part of the Reserved opcode). When an application requires a new MPLS Network Action Opcode, then it MUST provide the following information: NA Opcode Value:

• The application MUST request for an Opcode value. Based on the request, IANA will allocate a new Opcode value for the application. If the application requested for an opcode without Ancillary data then an offset Bit-Flag position will be allocated by IANA (This is described as part of the Reserved opcode).

NA Scope:

• The application MUST specify at-least one scope (I2E, HBH, Select) for the Network Action. Depending on the applications requirement, they MAY specify more than one scopes for the same Network Action.

Unknown Opcode Handling:

• This is the behaviour, that a node should follow when it does not understand this specific NA opcode (Check the "Unknown Opcode Handling Table" for different options). This is an optional information that May be provided by the application. By default "Skip and process Next NA".

Presence of Ancillary Data:

• The application MUST specify whether it requires Ancillary Data to process the Network Action. Incase the application does not need any AD, then it would use "Opcode-2" and the Flag-Based NAI offset will be assign by the IANA (This is described as part of the Reserved opcode).

Ancillary Data Length:

• If the applications Network Action requires AD, then it MUST specify the maximum length of the AD. The Maximum length MUST NOT exceed 110 bits. If it is exceeding 110 bits, then those Network Actions MUST be encoded as part of Post-Stack Network Actions.

Ancillary Data Format:

• The application MUST specify the format in which they encode their Ancillary data in detail. All the possible options should be provided.

Network Action Processing Procedure:

• The application MUST specify the detailed procedure for processing their respective Network Action. The known dependencies MUST be clearly listed out in their processing procedures.

Reserved In-Stack MPLS Network Action Opcodes Some of the opcodes are reserved as described below for the basic functionality and the rest of the opcodes are assigned by IANA.

NAI Opcode Value 1 (PSD Offset) 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 BOS in octets. This allows to carry Generic Control Word (0000b) and G-ACh (0001b) [RFC5586] fields immediately after the BOS. In the absence of this opcode, the node should understand that the PSD is encoded right after the MPLS BOS. "PSD Offset" value is encoded in next 13 bits.

In-Stack PSD offset Encoding Format

NA Opcode Value: 1 NA Scope: Depending on the NASS scope. This could be any one of the three scopes (I2E, HBH and SEL) Unknown Opcode Handling: MUST drop (Value = 1) Ancillary Data Length: 13 bits Ancillary Data Format: The 13-bit value provides the offset to the start of the Post-Stack from the MPLS BOS in octets.

NAI Opcode Value 2 (Flag-Based NAIs without AD) This opcode is 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

NA Opcode Value: 2 NA Scope: Scope depends on the scope of the Flag-Based NAI. This could be any one of the three scopes (I2E, HBH and SEL) Unknown Opcode Handling: Depends on the Flag-Bases NAIs that are encoded. If one of the encoded NAIs handling is Drop (Value: 1), then this packet MUST be Dropped. Ancillary Data Length: Max 110 bits. To extend this range, a new opcode could be allocated from IANA registry in the future. Ancillary Data Format: Each bit position represents a single Flag-Based NAI, that does not require AD. The bit positions are read from left to right. These bit positions will be allocated and maintained by IANA.

NAI Opcode Value 3 (Combination of multiple NAIs) This Opcode reserved to support a combination of multiple IS-Stack NAI with the Ancillary data. The combination of NAIs in this case, are represented as the offset bits in the first 20 bits, the Flag bit position for a specific application will be allocated and maintained by IANA. The next 3 LSE's are used to encode the AD for the specific Flag bits in the first 20 bits.

In-Stack Flag-Based NAs with Ancillary Data

NA Opcode Value: 3 NA Scope: Scope depends on the Flag-Based NAI's scope. This could be any one of the three scopes (I2E, HBH and SEL) Unknown Opcode Handling: Depends on the Flag-Bases NAIs that are encoded. If one of the encoded NAIs handling is Drop (Value: 1), then this MUST to Drop. Ancillary Data Length: Max 110 bits Ancillary Data Format: Each bit position represents a single Flag-Based NAI, that does not require AD. The bit positions are read from left to right. These bit positions will be allocated and maintained by IANA.

NAI-Opcode Value 4 (PSD-ISD Ordering) This Opcode is reserved to indicate the specific order of execution between Post-Stack and In-Stack NAIs.

In-Stack PSD Opcode Indicator Encoding Format

NA Opcode Value: 4 NA Scope: Scope depends on the Scope of NASS that requires ordering. This could be any one of the three scopes (I2E, HBH and SEL) Unknown Opcode Handling: MUST drop (Value = 1) Ancillary Data Length: Max 20 bits Ancillary Data Format: When this opcode is present in the NASS then the "O-Bit" in the NASS parameters MUST be set. If not the packet MUST be dropped. Ancillary Data is encoded with the Post-Stack NAIs (8-Bit value) that is required to be processed before processing the next In-Stack NAs encoded. This opcode could hold maximum of two Post-Stack NAIs that could be executed serially.

NAI-Opcode Value 126 (No Operation) This opcode is reserved to fill-in unused 20 bits of 2nd LSE.

In-Stack No-Operation Opcode Encoding Format

NA Opcode Value: 126 NA Scope: Follows the scope of NASS Unknown Opcode Handling: MUST Skip and Proceed (Value = 0) Ancillary Data Length: Max 13 bits Ancillary Data Format: This could be any value as this opcode is a No-Operation Opcode. This value will be ignored.

NAI-Opcode Value 127 (Extended Opcode) This opcode is reserved to extend the current opcode range beyond 127. The Extended 7-bit opcode value will be encoded next to the base opcode value 127.

In-Stack Extended Opcode Encoding Format

NA Opcode Value: 127 NA Scope: Scope depends on the Extended NAI opcode. This could be any one of the three scopes (I2E, HBH and SEL) Unknown Opcode Handling: Depends on the Extended NAI opcode handling Ancillary Data Length: Depends on the Length supported by the extended opcode. The Maximum length of this opcode is 103 bits Ancillary Data Format: In the above example, the extended Opcode "9" is encoded in the packet. In this case only 13 bits of AD could be encoded in the same LSE, if the application requires to encode more than 13 bits then it had to use next LSE to encode the rest of the AD

Post-Stack MPLS Network Action Encoding The details of the Post-Stack Network Action Extension Header encodings are specified in .

MNA carrying Only Post-Stack NAs

MNA Encoding only Post-Stack NAs

In some cases the MNA header may encode only the Post-Stack NAs. In this case, the P-Bit is set to indicate the presence of Post-Stack NAs. The IHS field indicates the scope of the Post-Stack NAs (I2E, HBH, SEL).

MNA carrying both In-Stack and Post-Stack NAs

MNA Encoding In-Stack and Post-Stack NAs

In some cases the MNA header may encode both In-Stack and Post-Stack NAs. In this case, P-Bit is set to indicate the presence of Post-Stack NAs. The NASL is set to "1", indicates the presence of an In-Stack NA LSE. The IHS field indicates the scope of both the In-Stack Post-Stack NAs (I2E, HBH, SEL).

MNA carrying In-Stack and Post-Stack NA with different scope

MNA Encoding In-Stack and Post-Stack NAs with diff scope

In some cases the MNA may carry In-Stack NAs with Hop-By-Hop scope and Post-Stack NAs with I2E scope. In this case, there will be two NASS will be encoded. In this case, the First NASS will encode the In-Stack NA with the Hop-By-Hop scope and the second NASS will encode the presence of I2E scoped Post-Stack NAs.

Post-Stack MPLS Network Opcodes Allocation Procedure The Post-Stack MPLS Network Action opcode specific informations are provided in the draft .

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 "7". In some cases, some Flag-Based NAIs may need to be processed before the NAI-Opcode "7" and some Flag-Based NAIs may need to be process after the NAI-Opcode "7".

Example In-Stack NA Processing Order

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

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 "7". 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 "7".

Multiple MNA Copies in Label Stack When adding a large size MPLS label stack, a copy of NASS with HBH and Select scope may be placed at regular stack 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 also remove the NASS after processing the NASS assuming it supports the MNA label, and it will not forward the NASS at the top to the next node. For HBH scope, the node that receives the NASS at the top of the label stack MUST remove the NASS, assuming that it supports the MNA label. For I2E scope, only one copy of NASS needs to be added and it is added just before the bottom of the stack.

Node Capability Signaling The headend Node which is encapsulating the MNA header MUST make sure that the egress Nodes removes the MNA header. The headend Node May make sure that the MNA encoded in the packet could be able to process my midpoint and egress nodes. The following are the Node capabilities that are required for the headend Node to decide the encoding patten:

• Each participating Node MUST signal their capabilities of NASS processing like ordering, maximum NASL, etc.
• Each Participating Node MUST signal their capabilities of supporting each In-Stack and Post-Stack NAs and its parameters.
• Each Participating Node MUST signal their Maximum MPLS Stack Inspection Depth (MMSID). This will indicate the headend node to encode the MNA at a specific stack depth.

The above 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 following are the security considerations that May inherit from this MNA architecture

• If the untrusted source encode the MNA's NASL/NAL with incorrect length, then this may affect the MNA processing and the packet could be router in an illegitimate manner.

Backward Compatibility

• For the non-MNA capable 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 non-MNA capable nodes 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 Special Purpose Label.
• The MPLS Network Actions can co-exist with the existing GAL / G-ACh based encoding of data.
• The TC and TTL fields of the MNA 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 MNA bSPL (value TBA), this can cause encoding format flags in the TTL of the NASI (label TBA) 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.

Transit 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 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
20	Post-Stack Network Action Presence Indicator	This document
21-22	In-Stack Scope value E2H/HBH/SEL(IHS)	This document
23	End of Stack (S)	RFC 3032
24-27	In-Stack Network Action Sub-Stack Length (NASL)	This document
28-30	Reserved Bit - May be used in future	This document
31	O-Bit - MUST process NAs in the Order of encoding, Else drop the packet	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 application request. Based on the need this registry can be extended beyond 20 bit positions (MAX: 110 bits) using additional LSEs. The bit positions are read and processed from Left to Right. All code-points in the range 0 through 109 in this registry shall be allocated according to the "IETF Review" procedure as specified in . In-Stack MPLS Network Action Indicator Flags Registry

Bit Position	Description	Reference
0-109	Unassigned	This document

IANA Considerations for IS-NAI-Opcode IANA is requested to create a new registry with name "In-Stack MPLS Network Action Indicator Opcodes" to assign IS-NAI-Opcode values and the meaning to the Network Action upon the application request. All code-points in the range 1 through 110 in this registry shall be allocated according to the "IETF Review" procedure as specified in . Code points in the range 111 through 125 in this registry shall be allocated according to the "First Come First Served" procedure as specified in . Remaining code-points are allocated according to : In-Stack MPLS Network Action Indicator Opcodes Registry

Value	Description	Reference
0 - 110	IETF Review	This document
111 - 125	Experimental Use	This document

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

Value	Description	Reference
0	Invalid opcode, Packet MUST be dropped	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
126	No Operation	This document
127	Opcode Range Extension Beyond 255	This document

IANA Considerations for MNA bSPL Label IANA is requested to allocate a value TBA for the MNA 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

This is the example of MNA carrying Flag-Based NAIs that does not require Ancillary Data. Third LSE:

• NAI-Opcode=2: This is 7 bits reserved opcode to carry Flag-Based NAIs with out any AD.
• Flag-Based NAIs: This is the Flag-Based NAIs.
• S: This is the LSEs stack-bit.
• NAIs: Continuation of Flags-Based NAIs.
• UOH: Action that is required to take by a node if one of the NAIs are not recognized by the processing node.
• NAL: The last two bits NAL field is set to "0", as there are no additional LSE is used to encode.

Example NASS carrying Flag-Based NA with more than 20 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 MSB 2nd bit in the fourth LSE field will be set to indicate the Flags position "21". NAL is set to "1" and indicates the Flag-Based NAIs are also encoded in the next LSE. NASL is set to "2" and indicates the additional 2 In-Stack LSE are encoded. While encoding the Additional Ancillary Data in the 4th LSEs Most Significant bit MUST be set to "1" to prevent from aliasing with the reserved bSPLs.

Example-2 - In-Stack NA with 13-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 13-bit Ancillary Data. The Opcode that are encoded MUST be optional and the processing node could skip this opcode if it does not understand. Second LSE:

• NAI-Opcode=8: In-Stack Network Action opcode "8".
• Ancillary Data: 13 bit ancillary data that is required to process the opcode 8.

Example-3 - 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 "9" 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:

• NAI-Opcode=9: In-Stack Network Action opcode "9".
• Ancillary Data9: 16 bits of Ancillary Data encoded to process opcode "9"
• AD9: 4 bits of additional Ancillary Data.

Fourth LSE:

• 0th Bit: This bit is set to "1" to prevent aliasing with the bSPLs.
• Ancillary Data9: 22 bits of additional Ancillary data.
• Ancillary Data9: 8 bits of additional Ancillary Data.

References Normative References Informative References Futurewei Technologies Huawei Huawei Bronze Dragon Consulting Juniper Networks 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 Open 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. The authors would like to thank Darren Dukes, Loa Andersson, Stewart Bryant and Greg Mirsky for reviewing our draft and providing many useful suggestions.

Contributors The following people have substantially contributed to this document: