Discovering MNA Capabilities Using LSP Ping

Introduction The MPLS Network Actions (MNA) framework provides a general mechanism for encoding network actions and their data in the MPLS label stack. Network actions are encoded in Network Action Sub-stacks (NAS) that are placed within (ISD) or follow after (PSD) the MPLS label stack. The MNA header encoding is defined in . To correctly construct MPLS label stacks containing network actions, the ingress LER needs to know the MNA capabilities of each node along the path. For Post-Stack MNA, the ingress LER additionally needs to discover whether nodes support Post-Stack MPLS Headers and what Post-Stack network actions they can process, as required by Section 5.3 of . These capabilities include:

In-Stack MNA capabilities:
- The Readable Label Depth (RLD): the number of Label Stack Entries (LSEs) a node can parse without performance impact.
- The NAS Maximum Label Depth (MLD_NAS): the maximum supported NAS size for each scope (select, HBH, I2E).
- The supported In-Stack network action opcodes.
Post-Stack MNA capabilities:
- Whether the node supports Post-Stack MNA processing as defined in ,
- The maximum Post-Stack MPLS Header (PSMH) size (MLD_PSMH),
- The RLD including the PSMH (RLD_PSMH),
- The supported Post-Stack network action opcodes.

This document defines new TLVs for the MPLS echo request/reply messages to query and report MNA capabilities. The mechanism supports both "ping" mode (querying only the egress node) and "traceroute" mode (querying all nodes along the path). MNA capabilities could alternatively be advertised through routing protocols, similar to the advertisement of the Entropy Readable Label Depth (ERLD) in IS-IS and OSPF , or through BGP-LS . However, the full MNA capability set, i.e., supported opcodes, per-scope NAS size limits, and Post-Stack parameters, is too voluminous to flood through the IGP to all nodes in a domain, most of which never use it. This document therefore uses LSP Ping to collect capabilities on demand, only for the specific path on which the ingress LER intends to use MNA, and verified against the actual forwarding path in the data plane. The relationship between MNA capability discovery and path selection is discussed in .

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

Abbreviations This document makes use of the terms defined in and in . Abbreviations.

Abbreviation	Name	Description	Reference
NAS	Network Action Sub-stack	A stack of related LSEs in the MPLS stack containing network actions and ancillary data.
RLD	Readable Label Depth	The number of LSEs a node can parse.
MLD_NAS	NAS Maximum Label Depth	The maximum number of LSEs in a NAS that a node can process, defined per scope.	This document
PSMH	Post-Stack MPLS Header	The header after the BOS carrying post-stack network actions and ancillary data.
PSD	Post-Stack Data	Network actions and data encoded after the MPLS label stack.
ISD	In-Stack Data	Network actions and data encoded within the MPLS label stack.
MLD_PSMH	Maximum PSMH Size	The maximum PSMH size a node can process, in 4-octet units.	This document
RLD_PSMH	RLD including PSMH	The total parseable depth including label stack and PSMH, in 4-octet units.	This document

Definition of MNA Capabilities This section defines the parameters that an LSR uses to signal its MNA capabilities to the ingress LER.

In-Stack MNA Capabilities

The Readable Label Depth (RLD) The Readable Label Depth (RLD) is the number of LSEs an LSR can parse without performance impact . An LSR is required to search the MPLS stack for NAS that have to be processed by the LSR. To that end, the network actions must be within the RLD of the node. For HBH-scoped network actions, the ingress LER that pushes the network actions MUST ensure that the actions are readable at each LSR on the path, i.e., that they are placed within the RLD of each node.

Example An example for the RLD parameter is given in . With an RLD of 5, an LSR is capable of reading labels A, B, C, D, and E but not F. An RLD of 8 is required in this example to read the entire MPLS stack.

Example MPLS stack of 8 MPLS LSEs illustrating the concept of RLD.

Maximum NAS Sizes (MLD_NAS) This section gives a motivation for signaling maximum NAS sizes and then introduces the NAS Maximum Label Depth (MLD_NAS).

Motivation A NAS in the MNA header encoding is at least 2 LSEs and at most 17 LSEs large . At an LSR, one or more NAS, e.g., a select-scoped and a hop-by-hop-scoped NAS, are possible. With two maximum-sized NAS, an LSR is required to reserve 34 LSEs in hardware to be able to process network actions. This consumes hardware resources that may be needed to encode other LSEs, e.g., forwarding labels for SR-MPLS paths, or are not available in less capable devices. Many use cases in the MNA framework do not require a maximum-sized NAS of 17 LSEs to encode network actions and their ancillary data. Therefore, a NAS can be up to 17 LSEs but nodes can also support smaller maximum NAS. Signaling the maximum supported NAS size to the ingress LER prevents an LSR from receiving packets with a larger NAS than it supports. This way, the allocated resources for NAS can be reduced if smaller maximum NAS are supported. More resources are available for other purposes, and hardware with a low RLD can be made MNA-capable .

NAS Maximum Label Depth The maximum supported number of LSEs in a NAS that an LSR can process is referred to as NAS Maximum Label Depth (MLD_NAS) in this document. For each scope in MNA, a separate parameter for the MLD_NAS exists, called MLD_NAS_Select, MLD_NAS_HBH, and MLD_NAS_I2E. An LSR SHOULD signal the maximum-supported size of a NAS for each scope, i.e., the parameters MLD_NAS_Select, MLD_NAS_HBH, and MLD_NAS_I2E. Those parameters include the Format A, B, C, and D LSEs from in a NAS. Based on the signaled parameters, the ingress LER MUST ensure the following when pushing the MPLS stack and NAS on a packet:

The ingress LER MUST NOT push a select-scoped NAS that is larger than the signaled MLD_NAS_Select value of the node that will process the select-scoped NAS.
The ingress LER MUST NOT push an HBH-scoped NAS that is larger than the minimum of all signaled MLD_NAS_HBH values of all nodes on the path.
The ingress LER MUST NOT push an I2E-scoped NAS that is larger than the signaled MLD_NAS_I2E value of the egress node.

Example illustrates the different MLD_NAS sizes in an MPLS stack that are signaled by the LSR. In this example, a select-scoped NAS has a maximum size of 4 LSEs, a hop-by-hop-scoped NAS of 7 LSEs, and an I2E-scoped NAS of 4 LSEs.

Example MPLS stack illustrating the different NAS sizes.

Supported In-Stack Network Action Opcodes When an LSR reports its In-Stack capabilities, it MUST include all In-Stack network action opcodes it supports. If a network action opcode is not signaled, it is assumed that this opcode is not supported by the node.

Post-Stack MNA Capabilities The Post-Stack MNA solution allows network actions and their ancillary data to be encoded after the bottom of the MPLS label stack in a Post-Stack MPLS Header (PSMH). Section 5.3 of requires that each participating node signals its Post-Stack capabilities to the encapsulating node. This section defines the parameters for that purpose.

Post-Stack MNA Support A node MAY support Post-Stack MNA processing. The encapsulating node MUST NOT add a Post-Stack MPLS Header to a packet if the decapsulating node does not support Post-Stack MNA processing . Therefore, the ingress LER needs to discover whether each node on the path supports Post-Stack MNA.

Maximum Post-Stack MPLS Header Size (MLD_PSMH) The PSMH-LEN field in the Post-Stack MPLS Header indicates the total length of the Post-Stack MPLS Header in 4-octet units, excluding the 4-byte PSMH type header . Hardware implementations may have limits on the maximum PSMH size they can process. The maximum supported PSMH length is referred to as MLD_PSMH in this document, analogous to the scope-specific values of MLD_NAS for ISD. It is expressed in 4-octet units, consistent with the PSMH-LEN field encoding. An LSR SHOULD signal its MLD_PSMH to the ingress LER. Based on the signaled parameters, the ingress LER MUST ensure the following:

The ingress LER MUST NOT add a PSMH with a PSMH-LEN exceeding the MLD_PSMH of any node that will process that PSMH.

Readable Label Depth Including Post-Stack MPLS Header (RLD_PSMH) Section 5.3 of defines the "Readable Label Depth including Post-Stack MPLS Header" as the total depth a node can parse, including both the MPLS label stack and the PSMH. This parameter is referred to as RLD_PSMH in this document and is expressed in 4-octet units. When the RLD_PSMH is signaled, the ingress LER MUST ensure that the combined size of the MPLS label stack and any PSMH intended for a node does not exceed that node's RLD_PSMH.

Supported Post-Stack Network Action Opcodes The Post-Stack network action opcode space (MNA-PS-OP) is 7 bits, supporting 128 opcodes . When a node reports its Post-Stack capabilities, it MUST include all Post-Stack network action opcodes it supports. The Post-Stack opcode space is separate from the In-Stack opcode space; a node may support an opcode in-stack, post-stack, or both.

LSP Ping MNA Operation Overview The MNA capability discovery mechanism operates as follows:

The ingress LER sends MPLS echo request messages containing the MNA Capabilities Query TLV. In traceroute mode, echo requests are sent with incrementing TTL values to reach each node on the path. In ping mode, a single echo request is sent to the egress LER.
Each node that receives the echo request and supports MNA capability discovery responds with an MPLS echo reply containing the MNA Capabilities Response TLV. The response includes sub-TLVs corresponding to the queried capabilities.
The ingress LER aggregates the received responses to determine path-wide MNA constraints. Specifically:
- The path-wide RLD is the minimum RLD reported by any node on the path.
- The path-wide MLD_NAS_HBH is the minimum MLD_NAS_HBH reported by any node.
- The MLD_NAS_Select for a specific node is the value reported by that node.
- The MLD_NAS_I2E is the value reported by the egress node.
- The path-wide supported opcodes for HBH-scoped NAS are the intersection of opcodes supported by all nodes. The supported opcodes for a select-scoped NAS are those reported by the node processing that NAS, and for an I2E-scoped NAS those reported by the egress node.
- Post-Stack capabilities are aggregated in the same way: Post-Stack MNA is available only if the decapsulating node reports PS_SUPPORTED, the path-wide MLD_PSMH and RLD_PSMH are the minima of the values reported by the nodes that process the PSMH, and the supported Post-Stack opcodes are aggregated per scope like the In-Stack opcodes.

The ingress LER SHOULD perform MNA capability discovery before pushing MNA-enabled label stacks onto a path. The ingress LER SHOULD re-query capabilities when the path changes, e.g., due to IGP reconvergence or Fast Reroute activation.

Relationship to Path Selection MNA capability discovery is not an input to path computation. Paths are selected by existing mechanisms without MNA capability information, and the mechanism defined in this document informs the ingress LER about the MNA constraints of the selected path before network actions are pushed onto it. Only coarse feasibility information needs to be available at path selection time, and such information already has an IGP home: the RLD can be advertised as MSD-Type 3 using the MSD advertisements of IS-IS and OSPF . In contrast, the detailed capability set, i.e., supported opcodes, per-scope NAS size limits, and Post-Stack parameters, is voluminous and only relevant for the specific paths on which an ingress LER intends to use MNA. Flooding this information through the IGP would burden all nodes in the domain with information that most of them never use. This document therefore probes the detailed capability set on demand and per path. If the discovered capabilities are not sufficient for the intended network actions, the ingress LER can adapt the NAS construction to the discovered constraints, or refrain from using MNA on that path. If the ingress LER can steer traffic, e.g., using SR-TE candidate paths or RSVP-TE explicit routes, it can also select an alternate candidate path or egress node and repeat the discovery there. In particular, when multiple candidate egress nodes exist, the ingress LER can probe each candidate in ping mode to select an egress node that supports the required network actions, e.g., the required MLD_NAS_I2E or Post-Stack decapsulation support. This iterative approach keeps the amount of flooded information minimal and requires neither routing protocol extensions nor a central controller.

MNA Capabilities Query TLV The MNA Capabilities Query TLV is carried in the MPLS Echo Request message. Its format is as follows:

MNA Capabilities Query TLV. The fields are defined as follows:

Type: Indicates the MNA Capabilities Query TLV. The value is TBA1.
Length: The length of the Value field in octets. For this TLV, Length is 4 octets.
Query Flags: An 8-bit field indicating which capabilities are being queried. Bit 0 is the most significant bit of the field:

Query Flags.

Bit	Name	Description
0	QUERY_RLD_MLD_NAS	Query the Readable Label Depth and NAS Maximum Label Depth (scopes)
1	QUERY_ISD_OPCODES	Query supported network action opcodes for ISD
2	QUERY_PS_MNA	Query Post-Stack MNA capabilities (support, MLD_PSMH, RLD_PSMH)
3	QUERY_PS_OPCODES	Query supported network action opcodes for PSD
4-7	Reserved	MUST be set to zero on transmit, ignored on receipt

Reserved: MUST be set to zero on transmit and MUST be ignored on receipt.

A node that receives an MNA Capabilities Query TLV with all Query Flags set to zero SHOULD respond with all available MNA capabilities.

MNA Capabilities Response TLV The MNA Capabilities Response TLV is carried in the MPLS Echo Reply message. Its format is as follows:

MNA Capabilities Response TLV. The fields are defined as follows:

Type: Indicates the MNA Capabilities Response TLV. The value is TBA2.
Length: The length of the Value field in octets.

The Value field consists of one or more sub-TLVs as defined in the following sections. The responding node MUST include sub-TLVs corresponding to the flags set in the Query TLV. If no flags were set in the query, the responding node SHOULD include all sub-TLVs for which it has information.

RLD and MLD_NAS Sub-TLV The RLD and MLD_NAS Sub-TLV reports the Readable Label Depth of the responding node together with the maximum supported NAS sizes for each scope.

RLD and MLD_NAS Sub-TLV.

Sub-type: 1 (RLD and MLD_NAS).
Length: 4 octets.
RLD Value: An 8-bit unsigned integer indicating the number of LSEs the node can parse without performance impact. A value of 0 indicates that the node did not provide an RLD value.
MLD_NAS_Select: An 8-bit unsigned integer indicating the maximum number of LSEs in a select-scoped NAS that the node can process. Valid range: 2-17. A value of 0 indicates that select-scoped NAS are not supported. Values of 1 and 18-255 are invalid and MUST NOT be sent; receivers MUST treat them as 0.
MLD_NAS_HBH: An 8-bit unsigned integer indicating the maximum number of LSEs in an HBH-scoped NAS that the node can process. Valid range: 2-17. A value of 0 indicates that HBH-scoped NAS are not supported. Values of 1 and 18-255 are invalid and MUST NOT be sent; receivers MUST treat them as 0.
MLD_NAS_I2E: An 8-bit unsigned integer indicating the maximum number of LSEs in an I2E-scoped NAS that the node can process. Valid range: 2-17. A value of 0 indicates that I2E-scoped NAS are not supported. Values of 1 and 18-255 are invalid and MUST NOT be sent; receivers MUST treat them as 0.

Supported In-Stack Opcodes Sub-TLV The Supported In-Stack Opcodes Sub-TLV reports the In-Stack network action opcodes supported by the responding node using a bitmap encoding. The MNA opcode space is 7 bits, supporting 128 opcodes. Each bit in the bitmap corresponds to one opcode value.

Supported In-Stack Opcodes Sub-TLV.

Sub-type: 2 (Supported In-Stack Opcodes).
Length: 16 octets.
Supported In-Stack Opcodes bitmap: A 128-bit bitmap where bit N (counting from bit 0 as the most significant bit of the first octet) corresponds to opcode value N. If bit N is set to 1, the node supports opcode N. If bit N is set to 0, the node does not support opcode N.

Post-Stack MNA Capabilities Sub-TLV The Post-Stack MNA Capabilities Sub-TLV reports whether the node supports Post-Stack MNA processing, the maximum PSMH size, and the RLD including PSMH.

Post-Stack MNA Capabilities Sub-TLV.

Sub-type: 3 (Post-Stack MNA Capabilities).
Length: 4 octets.
PS Flags: An 8-bit field. Bit 0 is the most significant bit of the field.
- Bit 0: PS_SUPPORTED. If set to 1, the node supports Post-Stack MNA processing as defined in . If set to 0, Post-Stack MNA is not supported and the remaining fields in this sub-TLV SHOULD be ignored.
- Bits 1-7: Reserved. MUST be set to zero on transmit and MUST be ignored on receipt.
MLD_PSMH: An 8-bit unsigned integer indicating the maximum Post-Stack MPLS Header length (in 4-octet units, excluding the PSMH type header) that the node can process. A value of 0 indicates that the node did not provide this value. The valid range corresponds to the 8-bit PSMH-LEN field defined in .
RLD_PSMH: An 8-bit unsigned integer indicating the Readable Label Depth including the Post-Stack MPLS Header, in 4-octet units. A value of 0 indicates that the node did not provide this value.
Reserved: MUST be set to zero on transmit and MUST be ignored on receipt.

Supported Post-Stack Opcodes Sub-TLV The Supported Post-Stack Opcodes Sub-TLV reports the Post-Stack network action opcodes supported by the responding node. The Post-Stack opcode space is 7 bits (128 values), identical to the In-Stack Opcodes Sub-TLV format in but independent from it. For the Supported Post-Stack Opcodes Sub-TLV, the sub-type 4 (Supported Post-Stack Opcodes) is used. The format is identical to .

Processing Rules This section defines the processing rules for querying and responding nodes.

Ingress LER (Querier) The ingress LER constructs MPLS echo request messages containing the MNA Capabilities Query TLV. In traceroute mode, the ingress LER sends echo requests with TTL values from 1 to the path length. This allows discovery of MNA capabilities at each hop. Traceroute mode SHOULD be used when HBH-scoped network actions are planned, as the ingress LER needs the capabilities of every node to correctly place NAS copies within each node's RLD. In ping mode, a single echo request with TTL set to 255 is sent. This is sufficient when only I2E-scoped network actions are planned, as only the egress node's capabilities are needed. After collecting responses, the ingress LER computes path-wide constraints as described in . The ingress LER MUST ensure the following when constructing MPLS stacks with MNA:

A select-scoped NAS pushed for a specific node MUST NOT exceed that node's MLD_NAS_Select.
An HBH-scoped NAS MUST NOT exceed the minimum MLD_NAS_HBH across all nodes on the path.
An I2E-scoped NAS MUST NOT exceed the egress node's MLD_NAS_I2E.
All NAS intended for a node MUST be within that node's RLD.

When Post-Stack MNA is used, the ingress LER MUST additionally ensure:

The ingress LER MUST NOT add a Post-Stack MPLS Header to a packet if the decapsulating node does not have the PS_SUPPORTED flag set.
The PSMH-LEN of any Post-Stack MPLS Header MUST NOT exceed the MLD_PSMH of any node that will process the PSMH.
The combined size of the MPLS label stack and any PSMH intended for a node MUST NOT exceed that node's RLD_PSMH.

Responding Node A node that supports MNA and receives an MPLS echo request containing the MNA Capabilities Query TLV MUST respond with an MPLS echo reply containing the MNA Capabilities Response TLV. The responding node MUST include sub-TLVs corresponding to the flags set in the query:

If the QUERY_RLD_MLD_NAS flag is set, the RLD and MLD_NAS Sub-TLV MUST be included.
If the QUERY_ISD_OPCODES flag is set, the Supported In-Stack Opcodes Sub-TLV MUST be included.
If the QUERY_PS_MNA flag is set, the Post-Stack MNA Capabilities Sub-TLV (sub-type 3) MUST be included.
If the node supports Post-Stack MNA and the QUERY_PS_OPCODES flag is set, the Supported Post-Stack Opcodes Sub-TLV (sub-type 4) MUST also be included.

If no Query Flags are set (all zero), the responding node SHOULD include all available sub-TLVs. The reported capabilities are those of the node as a whole. If capabilities vary per interface, the node SHOULD report the capabilities applicable to the interface on which the echo request was received.

MNA-incapable Nodes A node that does not support MNA will not recognize the MNA Capabilities Query TLV. The TLV type for the MNA Capabilities Query TLV is assigned from the mandatory TLV range of (types 0-32767), so a node that does not recognize the TLV returns Return Code 2 ("One or more of the TLVs was not understood") in the echo reply. This allows the ingress LER to detect nodes that do not support MNA. If a node does not support MNA, but recognizes the MNA Capabilities Query TLV, it MUST include Return Code TBA3 in the MPLS echo reply message.

Example Consider an SR-MPLS path with three LSRs: R1, R2 (transit), and R3 (egress). The ingress LER R0 wants to push an HBH-scoped NAS and a select-scoped NAS for R2 along this path. R0 sends MPLS echo requests in traceroute mode with all Query Flags set. The responses are: Example MNA Capabilities Responses.

Node	RLD	MLD_NAS_Select	MLD_NAS_HBH	MLD_NAS_I2E	PS_Supported	MLD_PSMH	RLD_PSMH
R1	20	9	9	0 (not egress)	Yes	16	36
R2	51	9	3	0 (not egress)	Yes	8	59
R3	35	9	9	9	Yes	16	51

From these responses, R0 determines:

Path-wide RLD: min(20, 51, 35) = 20 LSEs
Path-wide MLD_NAS_HBH: min(9, 3, 9) = 3 LSEs
MLD_NAS_Select for R2: 9 LSEs
MLD_NAS_I2E: 9 LSEs (from R3)
Post-Stack MNA is supported on all nodes (PS_SUPPORTED set at R1, R2, R3).
Path-wide MLD_PSMH for HBH-scoped PSMH: min(16, 8, 16) = 8 (in 4-octet units).
MLD_PSMH for I2E-scoped PSMH: 16 (from R3).
Path-wide RLD_PSMH: min(36, 59, 51) = 36 (in 4-octet units).

R0 can now construct a label stack ensuring that all NAS are within each node's RLD and do not exceed the per-scope MLD_NAS constraints. For Post-Stack MNA, R0 ensures that the PSMH does not exceed the path-wide MLD_PSMH and that the combined label stack and PSMH do not exceed any node's RLD_PSMH.

Security Considerations The security considerations described in apply to this document. The MNA capability discovery mechanism reveals information about node capabilities, which could potentially be exploited by an attacker to craft targeted attacks against nodes with limited MNA support. Nodes that support MNA capability discovery SHOULD support configuration options to enable or disable the MNA Capabilities Query/Response functionality. By default, MNA capability discovery SHOULD be enabled only within an MNA-capable MPLS domain. The security considerations from and also apply.

IANA Considerations This section requests new TLVs and sub-TLVs.

TLV Assignments IANA is requested to assign two new TLVs from the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group. The TLV values are requested from the range 0-16383 (Standards Action), in which a TLV MUST either be supported by an implementation or result in Return Code 2 ("One or more of the TLVs was not understood") in the echo reply . New TLVs.

Value	TLV Name	Reference	Sub-TLV Registry
TBA1	MNA Capabilities Query	This document	No
TBA2	MNA Capabilities Response	This document	See

New Sub-TLV Registry IANA is requested to create a new "Sub-TLVs for TLV Type TBA2" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group. The value ranges and registration procedures of this registry are the same as those of the "TLVs" registry , i.e., 0-16383 and 32768-49161 (Standards Action), 16384-31739 and 49162-64507 (RFC Required), 31740-31743 and 64508-64511 (Experimental Use), and 31744-32767 and 64512-65535 (First Come First Served). The initial entries are as follows; all other values are Unassigned. Sub-TLV Registry for TLV TBA2.

Sub-Type	Sub-TLV Name	Reference
0	Reserved	This document
1	RLD and MLD_NAS	This document
2	Supported In-Stack Opcodes	This document
3	Post-Stack MNA Capabilities	This document
4	Supported Post-Stack Opcodes	This document

Query Flags and PS Flags Registries IANA is requested to create a new "MNA Capabilities Query Flags" registry for the 8-bit Query Flags field of the MNA Capabilities Query TLV. The registration procedure is Standards Action. The initial entries are as follows; bits 4-7 are Unassigned. MNA Capabilities Query Flags Registry.

Bit	Name	Reference
0	QUERY_RLD_MLD_NAS	This document
1	QUERY_ISD_OPCODES	This document
2	QUERY_PS_MNA	This document
3	QUERY_PS_OPCODES	This document

IANA is further requested to create a new "Post-Stack MNA Capabilities Flags" registry for the 8-bit PS Flags field of the Post-Stack MNA Capabilities Sub-TLV. The registration procedure is Standards Action. The initial entry is as follows; bits 1-7 are Unassigned. Post-Stack MNA Capabilities Flags Registry.

Bit	Name	Reference
0	PS_SUPPORTED	This document

Return Code Assignment IANA is requested to assign a new Return Code from the "Return Code" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group as follows. New return code.

Value	Meaning	Reference
TBA3	MNA not supported	This document