MPLS Network Actions for In Situ Operations, Administration, and Maintenance
draft-ietf-mpls-mna-ioam-15
| Document | Type | Active Internet-Draft (mpls WG) | |
|---|---|---|---|
| Authors | Rakesh Gandhi , Greg Mirsky , Haoyu Song , Bin Wen , Voitek Kozak | ||
| Last updated | 2026-10-26 (Latest revision 2026-10-25) | ||
| Replaces | draft-gandhi-mpls-mna-ioam-dex, draft-mb-mpls-ioam-dex | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews |
OPSDIR Early review
(of
-11)
by Sheng Jiang
Has issues
SECDIR IETF Last Call Review due 2026-10-30
Incomplete
OPSDIR IETF Last Call Review due 2026-10-30
Incomplete
GENART IETF Last Call Review due 2026-10-26
Incomplete
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Associated WG milestone |
|
||
| Document shepherd | Adrian Farrel | ||
| Shepherd write-up | Show Last changed 2026-09-09 | ||
| IESG | IESG state | Waiting for AD Go-Ahead | |
| Action Holder | |||
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Jim Guichard | ||
| Send notices to | adrian@olddog.co.uk | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-mpls-mna-ioam-15
MPLS Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track G. Mirsky, Ed.
Expires: 28 April 2027 Ciena Corporation
H. Song
Futurewei Technologies
B. Wen
V. Kozak
Comcast
25 October 2026
MPLS Network Actions for In Situ Operations, Administration, and
Maintenance
draft-ietf-mpls-mna-ioam-15
Abstract
In situ Operations, Administration, and Maintenance (IOAM), defined
in RFC 9197, collects operational and telemetry information in the
packet using IOAM-Data-Fields while the packet traverses a path
between two points in the network. Several IOAM Option-Types are
available, including Pre-allocated Trace, Proof of Transit (POT),
Edge-to-Edge (E2E), and Incremental Trace. These Option-Types can be
used to collect information for calculating various performance
metrics. RFC 9326 defines the IOAM Direct Export (IOAM-DEX) Option-
Type, which is used as a trigger for IOAM data to be directly
exported or locally aggregated without being pushed into in-flight
data packets.
MPLS Network Action (MNA) mechanisms indicate actions to be performed
on any combination of Label Switched Paths, MPLS packets, and the
node itself, and transport the data needed for these actions. This
document defines MNAs to collect and transport the operational state
and telemetry information using IOAM-Data-Fields as well as IOAM-DEX.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Gandhi, et al. Expires 28 April 2027 [Page 1]
Internet-Draft MPLS Network Actions for IOAM October 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 6
3. Applicability of IOAM and IOAM-DEX in an MPLS Network . . . . 6
4. Realization of IOAM and IOAM-DEX as Post-Stack MNA . . . . . 6
4.1. NAS for IOAM and IOAM-DEX as Post-Stack MNA . . . . . . . 7
4.2. PSMH for IOAM and IOAM-DEX as Post-Stack MNA . . . . . . 8
4.2.1. Example of Multiple IOAM and IOAM-DEX Option-Types as
Post-Stack MNA . . . . . . . . . . . . . . . . . . . 10
4.3. Procedure for IOAM and IOAM-DEX as Post-Stack MNA . . . . 11
4.3.1. Ingress-to-Egress Scope IOAM and IOAM-DEX as Post-Stack
MNA . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. Hop-by-Hop Scope IOAM and IOAM-DEX as Post-Stack
MNA . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Realization of IOAM-DEX as In-Stack MNA . . . . . . . . . . . 13
5.1. NAS for IOAM-DEX as In-Stack MNA . . . . . . . . . . . . 13
5.2. IOAM-DEX Option-Type Encoding as MNA ISD . . . . . . . . 15
5.2.1. Ext-Flags Definition . . . . . . . . . . . . . . . . 18
6. Considerations for IOAM and IOAM-DEX in MPLS Networks . . . . 19
6.1. Node Capability . . . . . . . . . . . . . . . . . . . . . 19
6.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 20
6.3. Readable Label Depth . . . . . . . . . . . . . . . . . . 20
6.4. Nested MPLS Encapsulation . . . . . . . . . . . . . . . . 21
7. Operational Considerations . . . . . . . . . . . . . . . . . 21
Gandhi, et al. Expires 28 April 2027 [Page 2]
Internet-Draft MPLS Network Actions for IOAM October 2026
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. Network Action Opcodes . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A: In-Stack and Post-Stack Network Action Processing Order
Example . . . . . . . . . . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction
In situ Operations, Administration, and Maintenance (IOAM) [RFC9197]
collects operational and telemetry information in the packet using
IOAM-Data-Fields while the packet traverses a path between two points
in the network. Several IOAM Option-Types are available, for
example, Pre-allocated Trace, Proof of Transit (POT), Edge-to-Edge
(E2E), and Incremental Trace, that can be used to collect information
for calculating various performance metrics. Such mechanisms
transport the collected information from an IOAM encapsulating node
to an IOAM decapsulating node (both typically located at the edge of
the IOAM domain within the data path).
IOAM Direct Export (IOAM-DEX) [RFC9326] is an IOAM Option-Type used
as a trigger for IOAM data to be directly exported or locally
aggregated without being pushed into in-flight data packets. The
exporting method and format are outside the scope of [RFC9326].
MPLS Network Action (MNA) mechanisms [RFC9789] indicate actions to be
performed on any combination of Label Switched Paths, MPLS packets,
and the node itself, and allow for the transport of data needed for
these actions. [RFC9994] defines mechanisms for carrying a Network
Action Sub-Stack (NAS) as part of the MPLS label stack, i.e., the In-
Stack MNA solution. [I-D.ietf-mpls-mna-ps-hdr] defines mechanisms
for carrying MNA and Ancillary Data (AD) below the MPLS label stack,
i.e., as the Post-Stack MNA solution. [RFC9791] describes various
use cases that can be realized using the MNA solution, including IOAM
and IOAM-DEX.
This document defines MNAs to collect and transport the operational
state and telemetry information using IOAM Option-Types, including
Pre-allocated Trace, POT, and E2E, as well as IOAM-DEX. The
mechanism for exporting the collected information for the IOAM-DEX
Option-Type is outside the scope of this document. Also,
transporting the Incremental Trace IOAM Option-Type is outside the
scope of this document.
Gandhi, et al. Expires 28 April 2027 [Page 3]
Internet-Draft MPLS Network Actions for IOAM October 2026
2. Conventions Used in This Document
2.1. Abbreviations
The terminology defined in [RFC9789], [RFC9994], and
[I-D.ietf-mpls-mna-ps-hdr] is used in this document.
+==================+=================+============================+
| Abbreviation | Meaning | Reference |
+==================+=================+============================+
| AD | Ancillary Data | [RFC9613] |
+------------------+-----------------+----------------------------+
| Blob | Binary Large | This document |
| | Object | |
+------------------+-----------------+----------------------------+
| BoS | Bottom of Stack | [RFC3032] |
+------------------+-----------------+----------------------------+
| HbH | Hop-by-Hop | [RFC9789] |
+------------------+-----------------+----------------------------+
| I2E | Ingress to | [RFC9789] |
| | Egress | |
+------------------+-----------------+----------------------------+
| E2E | Edge to Edge | [RFC9197] |
+------------------+-----------------+----------------------------+
| IHS | I2E, HbH, or | [RFC9994] and |
| | Select | [I-D.ietf-mpls-mna-ps-hdr] |
+------------------+-----------------+----------------------------+
| IOAM | In situ | [RFC9197] |
| | Operations, | |
| | Administration, | |
| | and Maintenance | |
+------------------+-----------------+----------------------------+
| IOAM-DEX | IOAM Direct | [RFC9326] |
| | Export | |
+------------------+-----------------+----------------------------+
| IOAM-DEX-MNA-ISD | IOAM Direct | This document |
| | Export as MPLS | |
| | Network Action | |
| | ISD | |
+------------------+-----------------+----------------------------+
| ISD | In-Stack Data | [RFC9613] |
+------------------+-----------------+----------------------------+
| LSE | Label Stack | [RFC3032] |
| | Entry | |
+------------------+-----------------+----------------------------+
| MNA | MPLS Network | [RFC9789] |
| | Action | |
+------------------+-----------------+----------------------------+
Gandhi, et al. Expires 28 April 2027 [Page 4]
Internet-Draft MPLS Network Actions for IOAM October 2026
| MPLS | Multiprotocol | [RFC3032] |
| | Label Switching | |
+------------------+-----------------+----------------------------+
| MTU | Maximum | [RFC3032] |
| | Transmission | |
| | Unit | |
+------------------+-----------------+----------------------------+
| NAI | Network Action | [RFC9613] |
| | Indicator | |
+------------------+-----------------+----------------------------+
| NAL | Network Action | [RFC9994] |
| | Length | |
+------------------+-----------------+----------------------------+
| NAS | Network Action | [RFC9789] |
| | Sub-Stack | |
+------------------+-----------------+----------------------------+
| NASL | Network Action | [RFC9994] |
| | Sub-Stack | |
| | Length | |
+------------------+-----------------+----------------------------+
| OAM | Operations, | [RFC6291] |
| | Administration, | |
| | and Maintenance | |
+------------------+-----------------+----------------------------+
| P bit | Post-Stack Data | [I-D.ietf-mpls-mna-ps-hdr] |
| | Presence bit | |
+------------------+-----------------+----------------------------+
| POT | Proof of | [RFC9197] |
| | Transit | |
+------------------+-----------------+----------------------------+
| RLD | Readable Label | [RFC9789] and |
| | Depth | [I-D.ietf-mpls-mna-ps-hdr] |
+------------------+-----------------+----------------------------+
| PFN | Post-Stack | [RFC9790] |
| | First Nibble | |
+------------------+-----------------+----------------------------+
| PSD | Post-Stack Data | [RFC9613] |
+------------------+-----------------+----------------------------+
| PSMH | Post-Stack MPLS | [I-D.ietf-mpls-mna-ps-hdr] |
| | Header | |
+------------------+-----------------+----------------------------+
| S bit | Bottom of Stack | [RFC3032] |
| | bit | |
+------------------+-----------------+----------------------------+
| TC | Traffic Class | [RFC5462] |
+------------------+-----------------+----------------------------+
| TTL | Time to Live | [RFC3032] |
+------------------+-----------------+----------------------------+
Gandhi, et al. Expires 28 April 2027 [Page 5]
Internet-Draft MPLS Network Actions for IOAM October 2026
| U bit | Unknown Network | [RFC9994] and |
| | Action Handling | [I-D.ietf-mpls-mna-ps-hdr] |
| | bit | |
+------------------+-----------------+----------------------------+
Table 1: Abbreviations
2.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Applicability of IOAM and IOAM-DEX in an MPLS Network
Pre-allocated Trace, POT, and E2E IOAM Option-Types [RFC9197] use
user packets to collect and transport the operational state and
telemetry information. This document defines the Post-Stack MNA
[I-D.ietf-mpls-mna-ps-hdr] solution for transporting the Pre-
allocated Trace, POT, and E2E IOAM Option-Types (see Section 4).
However, in some use cases, such as mobile backhaul, where network
resources are closely controlled, collecting and transporting
telemetry information within a user packet may increase the
complexity of network operations. In such environments, IOAM nodes
can use IOAM-DEX, an IOAM Option-Type used as a trigger for IOAM data
to be directly exported or locally aggregated without being pushed
into in-flight data packets, as defined in [RFC9326]. IOAM-DEX
collects the on-path telemetry information defined as IOAM data in
[RFC9197]. In this document, transporting IOAM-DEX is realized as
In-Stack Data (see Section 5) and as Post-Stack Data (see Section 4).
4. Realization of IOAM and IOAM-DEX as Post-Stack MNA
The procedure defined in this document utilizes the Post-Stack MNA
mechanisms [I-D.ietf-mpls-mna-ps-hdr] to transport IOAM Option-Types
defined in Section 4 of [RFC9197] and the IOAM-DEX Option-Type
defined in Section 3.2 of [RFC9326] as Post-Stack MNA in MPLS
networks.
Gandhi, et al. Expires 28 April 2027 [Page 6]
Internet-Draft MPLS Network Actions for IOAM October 2026
4.1. NAS for IOAM and IOAM-DEX as Post-Stack MNA
The presence of the associated Post-Stack MPLS Header (PSMH) is
indicated by setting the P bit to 1 in the NAS as defined in
[I-D.ietf-mpls-mna-ps-hdr]. Figure 1 shows an example of a NAS with
a Format B LSE and an associated PSMH carrying a network action and
ancillary data for IOAM and IOAM-DEX in PSD.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| MNA Label (value 4) | TC |S| TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| Opcode | 13-bit Data (Format B) |P|IHS|S| NASL |U| NAL | A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
| Label | TC |1| TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
~ PSMH for IOAM and IOAM-DEX in PSD per Figure 2 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional Payload + Padding ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
Figure 1: Example of NAS with Format B LSE and PSMH Carrying IOAM
and IOAM-DEX in PSD
The fields in a NAS are defined as follows:
* The MNA Label (value 4) is defined in [RFC9994].
* TC (3-bit): The TC field is defined in [RFC5462].
* S (1-bit): The S bit is defined in [RFC3032].
* TTL (8-bit): The TTL field is defined in [RFC3032].
* Opcode (7-bit): The opcode is set as specified in [RFC9994].
* Data: The data is set as specified in [RFC9994].
* P (1-bit): The P bit is set to 1 as specified in
[I-D.ietf-mpls-mna-ps-hdr].
* IHS (2-bit): The IHS scope field is set as defined in [RFC9994]
and updated in [I-D.ietf-mpls-mna-ps-hdr].
* NASL (4-bit): The NASL field is set as specified in [RFC9994].
Gandhi, et al. Expires 28 April 2027 [Page 7]
Internet-Draft MPLS Network Actions for IOAM October 2026
* U (1-bit): The U bit is set as specified in [RFC9994] and updated
in [I-D.ietf-mpls-mna-ps-hdr].
* NAL (3-bit): The NAL field is set as specified in [RFC9994].
If both edge nodes and intermediate nodes need to process the IOAM
Option-Types, then the IHS scope MUST be set to "HbH, value 0x1". If
only edge nodes need to process the IOAM Option-Types, then the IHS
scope MUST be set to "I2E, value 0x0". The I2E scope allows skipping
IOAM processing on the intermediate nodes, i.e., it avoids the need
to parse all IOAM Option-Types to detect the one that requires HbH
processing.
4.2. PSMH for IOAM and IOAM-DEX as Post-Stack MNA
An example encoding of a PSMH carrying IOAM and IOAM-DEX in Post-
Stack MNA is shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| PFN |Reserve| PSMH-Len | Type = MNA Post-Stack Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
| MNA-PS-OP |R|R| PS-NAL | Block-Number |R|IOAM-Opt-Type| S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M
~ IOAM Option-Type and Data Space [RFC9197] [RFC9326] ~ H
~ Beginning from Namespace-ID ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
Figure 2: Example of Post-Stack MPLS Header Carrying IOAM and
IOAM-DEX
The Post-Stack MPLS Base Header is added and contains the following
fields as defined in [I-D.ietf-mpls-mna-ps-hdr].
* PFN (4-bit): The Post-Stack First Nibble (PFN) has the value 0x0,
as defined in [I-D.ietf-mpls-mna-ps-hdr].
* Reserve (4-bit): The Reserve field MUST be set to 0 on transmit
and MUST be ignored on receipt.
* PSMH-Len (8-bit): The PSMH total length in units of 4 octets as
defined in [I-D.ietf-mpls-mna-ps-hdr]. The value excludes the
first 4-octet unit for Post-Stack MPLS Base Header. When a PSMH
carries N IOAM and IOAM-DEX network actions, each with the same
PS-NAL value, PSMH-Len equals (1 + PS-NAL) * N.
Gandhi, et al. Expires 28 April 2027 [Page 8]
Internet-Draft MPLS Network Actions for IOAM October 2026
* Type (16-bit): Type for MNA Post-Stack Header (value 1) as defined
in [I-D.ietf-mpls-mna-ps-hdr].
The Post-Stack network actions are added after the Post-Stack MPLS
Base Header.
The network action for IOAM and IOAM-DEX in PSD (opcode TBA1) carries
the IOAM Option-Type and associated IOAM-Data-Fields in Post-Stack
ancillary data. The PS-NAL field specifies the ancillary-data length
in 4-octet units, as shown in Figure 2. It has the following fields:
* MNA-PS-OP (7-bit): MUST be set to the network action for IOAM and
IOAM-DEX in PSD (opcode TBA1) to carry the IOAM Option-Type
defined in [RFC9197], and the IOAM-DEX Option-Type defined in
[RFC9326] in PSD.
The U bit for this network action is set in the NAS where this
PSMH is associated with as specified in [RFC9994] and updated in
[I-D.ietf-mpls-mna-ps-hdr].
The IHS scope field for this network action is set in the NAS
where this PSMH is associated with as defined in [RFC9994] and
updated in [I-D.ietf-mpls-mna-ps-hdr].
* R (three 1-bit fields): Three reserved bits appear in the PSMH
row: two bits following MNA-PS-OP and one bit preceding IOAM-Opt-
Type. All reserved bits MUST be set to 0 on transmission and MUST
be ignored on receipt.
* IOAM-Opt-Type (7-bit): This field carries the IOAM Option-Type, as
defined in the "IOAM Option-Type Registry" in [RFC9197] and
[RFC9326].
* PS-NAL (7-bit): An unsigned integer representing the length of the
IOAM-Data-Fields in 4-octet units for the MNA-PS-OP. The value
excludes the first 4-octet unit carrying the opcode.
* IOAM Option-Type and Data Space: IOAM-Data-Fields as specified by
the IOAM-Opt-Type field, beginning from the Namespace-ID field.
IOAM-Data-Fields are defined according to the IOAM Option-Type
(see, for example, Section 4 of [RFC9197] and Section 3.2 of
[RFC9326]).
* Block-Number (8-bit): The Block-Number is used for the alternate
marking method [RFC9341] to aggregate the IOAM-Data-Fields
collected in the data plane and to correlate IOAM-Data-Fields
exported from different nodes along the packet path, e.g., to
compute measurement metrics for each block of a data flow.
Gandhi, et al. Expires 28 April 2027 [Page 9]
Internet-Draft MPLS Network Actions for IOAM October 2026
- When the Flow ID field is present in the IOAM-Data-Fields in
the PSMH, the Block-Number is scoped per data flow within the
IOAM Namespace identified by the Namespace-ID field.
- When the Flow ID field is absent, the Block-Number is scoped
per IOAM Namespace (identified by the Namespace-ID field) and
applies to all flows sharing that Namespace.
- The Block-Number MUST be initialized to 0 at the start of
operation and wraps from 255 back to 0 on overflow. It is
incremented sequentially at every measurement interval
configured at the encapsulating node. When the alternate
marking method is not used, the Block-Number MUST be set to 0.
The following processing rules apply to the network action for IOAM
and IOAM-DEX in PSD (opcode TBA1).
* An MPLS packet MAY carry multiple network actions for IOAM and
IOAM-DEX in PSD (opcode TBA1) in the same PSMH for different
Option-Types.
* An MPLS packet MAY carry the network action for IOAM and IOAM-DEX
in PSD (opcode TBA1) in more than one PSMH for different
processing scopes.
* An MPLS packet MUST NOT carry the network action for IOAM and
IOAM-DEX in PSD (opcode TBA1) in a NAS. Otherwise, the packet is
treated as malformed and MUST be dropped.
4.2.1. Example of Multiple IOAM and IOAM-DEX Option-Types as Post-Stack
MNA
Figure 3 shows multiple Post-Stack Network Actions with the same IHS
scope, each carrying a different IOAM or IOAM-DEX Option-Type.
Gandhi, et al. Expires 28 April 2027 [Page 10]
Internet-Draft MPLS Network Actions for IOAM October 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| PFN |Reserve| PSMH-Len | Type = MNA Post-Stack Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MNA-PS-OP1 |R|R| PS-NAL1 | Block-Number |R|IOAM-Opt-Type| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
~ IOAM Option-Type and Data Space [RFC9197] [RFC9326] ~ S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M
| MNA-PS-OP2 |R|R| PS-NAL2 | Block-Number |R|IOAM-Opt-Type| H
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ IOAM Option-Type and Data Space [RFC9197] [RFC9326] ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
~ Optional Payload + Padding ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
Figure 3: Example of Multiple IOAM and IOAM-DEX Option-Types as
Post-Stack MNA
In this example, the PSMH carries the Network Action for IOAM and
IOAM-DEX in PSD in MNA-PS-OP1 (value TBA1) with length PS-NAL1 and in
MNA-PS-OP2 (value TBA1) with length PS-NAL2, both for different IOAM
Option-Types.
4.3. Procedure for IOAM and IOAM-DEX as Post-Stack MNA
4.3.1. Ingress-to-Egress Scope IOAM and IOAM-DEX as Post-Stack MNA
The network actions with I2E scope carry IOAM Option-Types that
require processing by the encapsulating and egress nodes only.
The IOAM Option-Type carried can be the IOAM E2E Option-Type (value
3) defined in [RFC9197] or the IOAM-DEX Option-Type (value 4) defined
in [RFC9326]. The network actions with I2E scope MUST NOT carry an
IOAM Option-Type that requires processing by intermediate nodes,
because those nodes will not process it when the IHS scope is set to
"I2E, value 0x0".
The IOAM and IOAM-DEX network action procedure with I2E scope is
summarized as follows:
* The encapsulating node inserts a NAS with the IHS scope set to
"I2E, value 0x0", as well as one or more network actions for IOAM
and IOAM-DEX in the MPLS packet.
* The encapsulating node MUST ensure that the packet with all NASs
and PSMHs added does not exceed the path maximum transmission unit
(MTU), as described in Section 6.2.
Gandhi, et al. Expires 28 April 2027 [Page 11]
Internet-Draft MPLS Network Actions for IOAM October 2026
* The egress node processes the IOAM-Data-Fields using the
procedures defined in [RFC9197] and [RFC9326]. An example of IOAM
processing is to export the IOAM-Data-Fields for streaming
telemetry.
* The egress node MUST remove the NAS, the associated PSMH, the IOAM
and IOAM-DEX network actions, and the IOAM-Data-Fields from the
received packet. The decapsulated packet is forwarded downstream
in the same manner as a regular data packet, or it is terminated
locally.
4.3.2. Hop-by-Hop Scope IOAM and IOAM-DEX as Post-Stack MNA
The network actions with HbH scope carry IOAM Option-Types that
require processing at intermediate nodes, encapsulating nodes, egress
nodes, or any combination thereof.
The IOAM Option-Type carried can be Pre-allocated Trace (value 0),
POT (value 2), or E2E (value 3) defined in [RFC9197], or the IOAM-DEX
Option-Type (value 4) defined in [RFC9326].
Note that the network actions defined in this document do not support
the IOAM Incremental Trace Option-Type (value 1), which requires HbH
processing.
The IOAM and IOAM-DEX network action procedure with HbH scope is
summarized as follows:
* The encapsulating node inserts a NAS with the IHS scope set to
"HbH, value 0x1", as well as one or more network actions for IOAM
and IOAM-DEX in the MPLS packet.
* The intermediate node that is enabled for the IOAM function
processes the IOAM-Data-Fields as defined in [RFC9197] and
[RFC9326] when the node recognizes the HbH scope in the NAS.
* The intermediate node forwards the data packet downstream.
* Processing at the egress node follows the I2E procedure.
Both HbH and I2E scope network actions for IOAM and IOAM-DEX MAY be
carried in the Post-Stack MNA in an MPLS packet. In this case, the
PSMH carrying HbH-scoped network actions MUST be added after the BoS
and before the PSMH carrying I2E-scoped network actions. This
minimizes the Readable Label Depth (RLD) [I-D.ietf-mpls-mna-ps-hdr]
required on intermediate nodes for processing IOAM and IOAM-DEX.
Gandhi, et al. Expires 28 April 2027 [Page 12]
Internet-Draft MPLS Network Actions for IOAM October 2026
5. Realization of IOAM-DEX as In-Stack MNA
The procedure in this section adopts the IOAM-DEX Option-Type format
defined in [RFC9326] using MNA In-Stack Data (ISD) [RFC9994] to
support direct export in MPLS networks.
5.1. NAS for IOAM-DEX as In-Stack MNA
To enable direct export of operational state and telemetry
information, the IOAM-DEX-MNA-ISD Binary Large Object (blob) is
placed in a NAS according to the procedure defined in [RFC9994]. An
example NAS with Format B LSE and Format D LSE to carry IOAM-DEX-MNA-
ISD is shown in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| MNA Label (value 4) | TC |S| TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
|Opcode = TBA2| 13-bit Data (Format B) |P|IHS|S| NASL |U| NAL | A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
~1| IOAM-DEX-MNA-ISD per Figure 5 (Format D) |S| ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
Figure 4: Example of NAS with Format B LSE and Format D LSE to
Carry IOAM-DEX as In-Stack MNA
The NAS carrying the network action for IOAM-DEX in ISD (opcode TBA2)
has the following fields:
* The MNA Label (value 4) is defined in [RFC9994].
* TC (3-bit): The TC field is defined in [RFC5462].
* S (1-bit): The S bit is defined in [RFC3032].
* TTL (8-bit): The TTL field is defined in [RFC3032].
* Opcode (7-bit): Set to the network action for IOAM-DEX in ISD
(opcode TBA2).
The opcode TBA2 can be carried in Format B or Format C LSE
[RFC9994].
* Data: MUST be set to 0 in both cases, 13-bit data in Format B LSE
and 20-bit data in Format C LSE [RFC9994].
* P (1-bit): The P bit is defined in [I-D.ietf-mpls-mna-ps-hdr].
Gandhi, et al. Expires 28 April 2027 [Page 13]
Internet-Draft MPLS Network Actions for IOAM October 2026
* IHS (2-bit): The IHS scope field is set as defined in [RFC9994]
and updated in [I-D.ietf-mpls-mna-ps-hdr].
* NASL (4-bit): The NASL field is set as specified in [RFC9994]. It
indicates the number of LSEs that compose the IOAM-DEX-MNA-ISD
blob.
* U (1-bit): The U bit is set as specified in [RFC9994] and updated
in [I-D.ietf-mpls-mna-ps-hdr].
* NAL (3-bit): The NAL field is set as specified in [RFC9994].
* IOAM-DEX-MNA-ISD: IOAM-DEX in MNA ISD encoding in Format D LSE
[RFC9994].
By setting the IHS field [RFC9994], the IOAM-DEX-MNA-ISD can be
operated in HbH, I2E, or Select scopes [RFC9789] to collect the
operational state and telemetry information.
The following processing rules apply to the network action for IOAM-
DEX in ISD (opcode TBA2).
* An MPLS packet MUST NOT carry multiple network actions for IOAM-
DEX in ISD (opcode TBA2) in the same NAS. Otherwise, the packet
is treated as malformed and MUST be dropped.
* An MPLS packet MAY carry the network action for IOAM-DEX in ISD
(opcode TBA2) in more than one NAS for different processing
scopes.
* An MPLS packet MUST NOT carry the network action for IOAM-DEX in
ISD (opcode TBA2) in a PSMH. Otherwise, the packet is treated as
malformed and MUST be dropped.
The following processing rules apply when an MPLS packet carries both
the network action for IOAM and IOAM-DEX in PSD (opcode TBA1), with
the IOAM-DEX Option-Type in a PSMH, and the network action for IOAM-
DEX in ISD (opcode TBA2) in a NAS:
* The network action for IOAM-DEX in ISD (opcode TBA2) in a NAS and
the network action for IOAM and IOAM-DEX in PSD (opcode TBA1)
carrying the IOAM-DEX Option-Type in the associated PSMH MUST NOT
both be carried in an MPLS packet with the same IHS scope;
otherwise, the packet MUST be treated as malformed and MUST be
dropped.
Gandhi, et al. Expires 28 April 2027 [Page 14]
Internet-Draft MPLS Network Actions for IOAM October 2026
* The network action for IOAM and IOAM-DEX in PSD (opcode TBA1)
carrying the IOAM-DEX Option-Type in a PSMH and the network action
for IOAM-DEX in ISD (opcode TBA2) in a NAS MAY be carried for
different IHS scopes in an MPLS packet.
* Each network action for the IOAM-DEX Option-Type operates
independently: the network action for IOAM-DEX in ISD (opcode
TBA2) triggers direct export at nodes processing the In-Stack MNA,
while the network action for IOAM and IOAM-DEX in PSD (opcode
TBA1) with IOAM Option-Type triggers direct export at nodes
processing the Post-Stack MNA.
5.2. IOAM-DEX Option-Type Encoding as MNA ISD
The IOAM-DEX-MNA-ISD blob in a NAS uses a Format D LSE, as specified
in Section 4.4 of [RFC9994], which maps to the IOAM-DEX Option-Type
format defined in [RFC9326]. In addition to the requirement to
preserve the S bit, the most significant bit in Format D LSE is
always set to 1, avoiding a possible mix-up of the LSE with one of
the Base Special Purpose Labels [RFC9994]. The format of the IOAM-
DEX-MNA-ISD blob in a NAS is shown in Figure 5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|1| Namespace-ID | Reserved |S| Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|1| IOAM-Trace-Type-MNA |S|O|R| Ext-Flags | I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
|1| Flow ID MNA (Optional) |S| Flow ID MNA | D
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|1| Sequence Number MNA (Optional) |S| Seq Num MNA | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
Figure 5: IOAM-DEX Option-Type Format for MNA ISD
Here, the fields are defined as follows:
* Namespace-ID (16-bit): Identifier of the IOAM Namespace, as
defined in Section 3.2 of [RFC9326].
* Reserved (6-bit): The Reserved field MUST be set to 0 on transmit
and MUST be ignored on receipt.
* Flags (8-bit): The Flags field comprises eight one-bit subfields.
The subfields in the Flags field are allocated by IANA in the IOAM
DEX Flags registry, as defined in Section 4.2 of [RFC9326].
Gandhi, et al. Expires 28 April 2027 [Page 15]
Internet-Draft MPLS Network Actions for IOAM October 2026
* IOAM-Trace-Type-MNA (22-bit): The IOAM-Trace-Type-MNA corresponds
to the IOAM-Trace-Type field defined in Section 3.2 of [RFC9326].
- The interpretation of bit positions, from bit 0 through bit 21,
is as specified in [RFC9197].
- Note that bits as specified in [RFC9197] are right-shifted one
bit, so for example, bit 0 in [RFC9197] (leftmost bit for
hop_Lim and node_id in short format) is mapped to bit 1 (second
leftmost bit) in the MNA encoding.
- The registry that contains the assigned code points is found in
IANA's IOAM Trace-Type registry [IANA-IOAM-Trace-Type].
* O (1-bit): This is a one-bit flag identical to the interpretation
of bit 22 of the IOAM-Trace-Type field as defined in Section 3.2
of [RFC9326], marked as "variable-length Opaque State Snapshot"
per [RFC9197]; assigned code points are found in IANA's IOAM
Trace-Type registry [IANA-IOAM-Trace-Type].
* R (1-bit): This is a one-bit flag identical to the interpretation
of bit 23 of the IOAM-Trace-Type field as defined in Section 3.2
of [RFC9326], marked as "reserved" per [RFC9197]; assigned code
points are found in IANA's IOAM Trace-Type registry
[IANA-IOAM-Trace-Type].
- As in [RFC9326], the R bit is reserved to allow for future
extensions of the IOAM-Trace-Type-MNA bit field, i.e., it
indicates the presence of the extended IOAM-Trace-Type-MNA
field in the next LSE in Format D. The format of the extended
IOAM-Trace-Type-MNA field in the next LSE in Format D is
outside the scope of this document.
* The 24-bit value formed by concatenating the 22-bit IOAM-Trace-
Type-MNA field with the O and R flags is identical to the 24-bit
IOAM-Trace-Type field in Section 3.2 of [RFC9326]. Its bit
interpretation follows [RFC9197], with assigned code points in
IANA's IOAM Trace-Type registry [IANA-IOAM-Trace-Type].
* Ext-Flags (6-bit): The Ext-Flags field comprises six one-bit
subfields. The allocation of the subfields in this field is
according to the Extension-Flags field defined in Section 4.3 of
[RFC9326].
Gandhi, et al. Expires 28 April 2027 [Page 16]
Internet-Draft MPLS Network Actions for IOAM October 2026
- Four flags have been assigned by IANA: two as defined in
Section 4.3 of [RFC9326] indicating the presence of the
optional Flow ID and Sequence Number fields, and two as defined
in Section 4.1 of [RFC9630] indicating the presence of the
optional Multicast Branch ID field.
- Section 5.2.1 describes the detailed format of the Ext-Flags
field.
* In the IOAM-DEX Option-Type defined in [RFC9326], the IOAM-Trace-
Type and Reserved fields together form the second 32-bit word,
aligning the optional fields to 4-octet boundaries.
- For IOAM-DEX in MNA, optional fields such as Flow ID MNA and
Sequence Number MNA are aligned without adding a Reserved field
for padding.
* The Flow ID MNA and Sequence Number MNA fields are each encoded in
a complete 32-bit Format D LSE. When the F flag is clear, the
Flow ID MNA Format D LSE, including its leading 1 bit and S bit,
MUST be omitted. When the Q flag is clear, the Sequence Number
MNA Format D LSE, including its leading 1 bit and S bit, MUST be
omitted.
* Flow ID MNA: An optional 4-octet field containing a 30-bit Flow ID
(after removing leading 1 and S bits).
- The semantics of the Flow ID MNA field are the same as those of
the Flow ID field defined in Section 3.2 of [RFC9326], with the
following two differences:
1. The Flow ID MNA field carries a 30-bit value, compared to
the 32-bit Flow ID field in [RFC9326]; therefore, the Flow
ID space differs accordingly, and the 30-bit value will
wrap around faster than the 32-bit value.
2. The most significant bit MUST be set to 1. Bit 23 MUST be
set according to the definition of the S bit in [RFC3032].
* Sequence Number MNA: An optional 4-octet field containing a 30-bit
sequence number (after removing leading 1 and S bits).
- The semantics of the Sequence Number MNA field are the same as
those of the Sequence Number field defined in Section 3.2 of
[RFC9326], with the following two differences:
Gandhi, et al. Expires 28 April 2027 [Page 17]
Internet-Draft MPLS Network Actions for IOAM October 2026
1. The Sequence Number MNA field carries a 30-bit value,
compared to the 32-bit Sequence Number field in [RFC9326];
therefore, the sequence number space differs accordingly,
and the 30-bit value will wrap around faster than the
32-bit value.
2. The most significant bit MUST be set to 1. Bit 23 MUST be
set according to the definition of the S bit in [RFC3032].
- In MPLS networks, when it is known that the label stack
information is used for load-balancing flows, the 19-bit-long
part of the Sequence Number MNA, starting from the bit 1
position of the LSE, MUST remain immutable for a particular
packet flow identified by the value of the Flow ID MNA field.
- In MPLS networks, when it is known that other load-balancing
techniques are used, all bits of the Sequence Number MNA field
can be varied.
- In MPLS networks, when the load-balancing technique used by a
node is not known, the 19-bit-long part of the Sequence Number
MNA, starting from the bit 1 position of the LSE, MUST remain
immutable for a particular packet flow identified by the value
of the Flow ID MNA field.
- Mechanisms to learn about the load-balancing techniques used by
the nodes in MPLS networks are outside the scope of this
document.
5.2.1. Ext-Flags Definition
The length of the Ext-Flags field in the IOAM-DEX Option-Type in MNA
is shorter by two one-bit fields than the length of the Extension-
Flags field defined in Section 3.2 of [RFC9326]. In the 6-bit Ext-
Flags field of the IOAM-DEX-MNA-ISD header, four flags have been
mapped to flags assigned by IANA in the IOAM-DEX Option-Type, and two
flags (corresponding to unassigned bits in the [RFC9326] Extension-
Flags field) remain unassigned.
0 1 2 3 4 5
+-+-+-+-+-+-+
|F|Q|N|I|A|A|
+-+-+-+-+-+-+
Figure 6: Ext-Flags Field Format
The Ext-Flags field is defined as follows:
Gandhi, et al. Expires 28 April 2027 [Page 18]
Internet-Draft MPLS Network Actions for IOAM October 2026
* F and Q (1-bit each): These flags correspond to the Flow ID and
Sequence Number flags, respectively, in the IOAM DEX Extension-
Flags registry defined in Section 4.3 of [RFC9326]. Q corresponds
to the Sequence Number flag labeled "S" in that registry; Q is
used here to avoid confusion with the MPLS Bottom-of-Stack (BoS) S
bit.
* N and I (1-bit each): These flags correspond to the Multicast
Branching Node ID and Multicast Branching Interface Index flags,
respectively, as defined in Section 4.1 of [RFC9630]. The N and I
flags MUST be both set or both cleared; otherwise the header is
considered malformed and the packet MUST be dropped.
* A (1-bit): Unassigned one-bit flags. They MUST be set to 0 on
transmission and MUST be ignored upon receipt.
6. Considerations for IOAM and IOAM-DEX in MPLS Networks
6.1. Node Capability
The encapsulating node needs to know if the intermediate and egress
nodes can support the IOAM and IOAM-DEX network actions. Information
about the IOAM and IOAM-DEX capabilities of the nodes may be
configured, collected through management protocols, or distributed by
control protocols (such as advertising by routing protocols). The
encapsulating node learns about the IOAM and IOAM-DEX capabilities of
nodes using mechanisms that are out of scope for this document.
The following additional behaviors apply to node capabilities:
* An MNA-capable egress node that supports the network action for
IOAM and IOAM-DEX might not support a specific IOAM Option-Type or
particular IOAM-Data-Fields carried in the packet. In that case,
the egress node MUST handle the network action according to the U
bit as defined in [RFC9994] and updated in
[I-D.ietf-mpls-mna-ps-hdr].
* An MNA-capable intermediate node that does not support the network
action for IOAM and IOAM-DEX, the IOAM Option-Type, or the IOAM-
Data-Fields carried in the packet, MUST handle the network action
according to the U bit as defined in [RFC9994] and updated in
[I-D.ietf-mpls-mna-ps-hdr].
* An intermediate node that does not support MNA skips processing
the IOAM and IOAM-DEX network actions.
Gandhi, et al. Expires 28 April 2027 [Page 19]
Internet-Draft MPLS Network Actions for IOAM October 2026
6.2. MTU Considerations
The path MTU is the maximum size of the complete packet carried over
the LSP that can be forwarded over every link in the path. This
includes the MPLS label stack, all Network Action Sub-Stacks (NASs),
Post-Stack MPLS Headers (PSMHs), IOAM Option-Types and their
associated IOAM-Data-Fields, and any other encapsulation overhead.
The encapsulating node MUST ensure that the packet, with all labels
and MNA data added, does not exceed the path MTU, as specified in
Section 8 of [RFC9994] and [I-D.ietf-mpls-mna-ps-hdr].
The node responsible for selecting a path through the MPLS network
needs to know the path MTU along that path [RFC3032]. Information
about the path MTU may be configured, collected through management
protocols, or distributed by control protocols (such as MTU signaling
for Label Distribution Protocol [RFC3988]). The mechanisms used to
learn the path MTU of nodes in the path are out of scope for this
document.
Path MTU Discovery (PMTUD), including IPv6 PMTUD [RFC8201] and
Packetization Layer Path MTU Discovery (PLPMTUD) [RFC8899] can also
be used where applicable. PLPMTUD probing can be used in a canary
mode to validate candidate packet sizes; probes need to include the
MPLS and MNA overhead and follow the same path whose MTU is being
assessed.
Packets that exceed the path MTU cannot be fragmented by an MPLS
transit node. For IPv4, an ingress LSR may fragment a packet with
the Don't Fragment (DF) bit clear before imposing labels, as
described in Section 3.4 of [RFC3032]; it MUST NOT fragment an IPv4
packet with DF set. For IPv6, an MPLS node MUST NOT fragment a
packet; any IPv6 fragmentation is performed by the source before the
packet enters the MPLS network, as described in Section 3.5 of
[RFC3032]. Although an MPLS LSP is not an IP tunnel, tunnel MTU
guidance provides a useful analogy for accounting for encapsulation
overhead and avoiding fragmentation [I-D.ietf-intarea-tunnels]. When
fragmentation is not permitted or is not performed, the packet needs
to be sized to fit the path MTU, and the applicable ICMP error
handling can be used to reduce the packet size.
6.3. Readable Label Depth
The encapsulating node needs to know the RLD of each downstream MNA-
capable node on the path, as described in Section 2.3.1 of [RFC9789]
and updated in [I-D.ietf-mpls-mna-ps-hdr]. The encapsulating node
MUST ensure that the IOAM Option-Types, their IOAM-Data-Fields, and
the IOAM-DEX data in a NAS and its associated PSMH fit within the RLD
of the downstream MNA-capable nodes so that they can process the
Gandhi, et al. Expires 28 April 2027 [Page 20]
Internet-Draft MPLS Network Actions for IOAM October 2026
data. Information about the RLD of the nodes may be configured,
collected through management protocols, or distributed by control
protocols (such as advertising by routing protocols). The mechanisms
to learn about the RLD of nodes in the path are out of scope for this
document.
6.4. Nested MPLS Encapsulation
The following processing rules apply to nested MPLS encapsulation
when adding a new MPLS encapsulation:
* When a packet is received with a network action for IOAM-DEX in
ISD (opcode TBA2) or the network action for IOAM and IOAM-DEX in
PSD (opcode TBA1), and the nested MPLS encapsulating node needs to
add the network action for IOAM-DEX in ISD (opcode TBA2) for a
different scope, the node MUST add a new NAS with the network
action for IOAM-DEX in ISD (opcode TBA2) as part of the new MPLS
encapsulation.
* When a packet is received with a network action for IOAM-DEX in
ISD (opcode TBA2) or the network action for IOAM and IOAM-DEX in
PSD (opcode TBA1), the nested MPLS encapsulating node MUST NOT add
the network action for IOAM-DEX in ISD (opcode TBA2) for the same
scope as part of the new MPLS encapsulation.
* When a packet is received with an MPLS header, the nested MPLS
encapsulating node MUST NOT add the new network action for IOAM
and IOAM-DEX in PSD (opcode TBA1) as part of the new MPLS
encapsulation. This eliminates the requirement to insert a PSMH
in an MPLS-encapsulated packet received from the network.
7. Operational Considerations
Operational considerations discussed in [RFC9994] and
[I-D.ietf-mpls-mna-ps-hdr] apply to this document.
Management considerations discussed in [RFC9789], management and
deployment considerations discussed in [RFC9197], and performance
considerations discussed in Section 5 of [RFC9326] also apply to this
document.
Further operational considerations include policies controlling the
processing of the collected operational state and telemetry
information, and their transport in MPLS networks. The impact of
direct export on CPU utilization at nodes along the path SHOULD be
analyzed carefully. Additional considerations are described in
Section 6 for deploying IOAM and IOAM-DEX in MPLS networks.
Gandhi, et al. Expires 28 April 2027 [Page 21]
Internet-Draft MPLS Network Actions for IOAM October 2026
An implementation MAY collect the following counters:
* Packets received with the network action for IOAM and IOAM-DEX in
PSD.
* Packets dropped with the network action for IOAM and IOAM-DEX in
PSD due to an unknown IOAM function.
* Packets dropped with the network action for IOAM and IOAM-DEX in
PSD due to a malformed network action.
* Packets received with the network action for IOAM-DEX in ISD.
* Packets dropped with the network action for IOAM-DEX in ISD due to
an unknown IOAM-DEX function.
* Packets dropped with the network action for IOAM-DEX in ISD due to
a malformed network action.
Nodes MAY generate rate-limited notifications or alarms to alert
operators to significant operational events, such as sustained high
rates of IOAM-related packet drops. Comprehensive logging of IOAM
and IOAM-DEX network action processing details can aid in network
diagnostics and post-mortem analysis.
8. Security Considerations
The security considerations discussed in [RFC3032], [RFC9197],
[RFC9326], [RFC9378], [RFC9341], and [RFC9630] apply to this
document.
The security considerations discussed in [RFC9789], [RFC9994], and
[I-D.ietf-mpls-mna-ps-hdr] also apply to this document.
In addition, IOAM and IOAM-DEX using MNA introduce a new security
consideration: the semantics of the associated network actions are
not inherently constrained to safe behavior, and malformed actions or
ancillary data could affect the confidentiality, integrity, or
availability of the MPLS domain. A node that encounters an
unsupported or malformed action, or a malformed NAS or PSMH, MUST
apply the applicable unknown-action and malformed-packet handling
rules defined in [RFC9994] and [I-D.ietf-mpls-mna-ps-hdr].
MPLS domain border nodes MUST ensure that MPLS packets carrying IOAM
and IOAM-DEX network actions from any other administrative domain or
untrusted source are filtered before they are admitted to the
provider MPLS domain. Filtering SHOULD be enforced via local policy.
The filtering node SHOULD have a greater RLD than the other nodes in
Gandhi, et al. Expires 28 April 2027 [Page 22]
Internet-Draft MPLS Network Actions for IOAM October 2026
the domain as specified in [I-D.ietf-mpls-mna-ps-hdr], and the
network action opcode, ancillary data, and length or offset fields
MUST be validated before they are processed.
The use of network actions for IOAM and IOAM-DEX is intended for
deployment within a single trusted administrative domain. As such,
operators are assumed to have verified path integrity and correctly
configured the MNA-capable nodes along the path that support IOAM and
IOAM-DEX. Operators MUST protect against malicious configuration and
misuse, including the injection of spoofed or malformed IOAM and
IOAM-DEX packets, through path validation and operational monitoring
of packet drops and malformed NAS or PSMH events.
The MNA architecture allows ancillary data to be carried in the label
stack or after the label stack [RFC9789]. Such data may be
transmitted in the clear. Therefore, any sensitive IOAM or IOAM-DEX
data MUST be encrypted in transit or MUST NOT be carried using these
mechanisms. Network functions MUST NOT rely on ancillary data
integrity unless additional protection is provided.
9. IANA Considerations
9.1. Network Action Opcodes
IANA is requested to assign code points from its Network Action
Opcodes sub-registry of the MPLS Network Actions registry (see:
https://www.iana.org/assignments/mpls-network-actions).
+========+=========================+===============+===========+
| Opcode | Description | Applicability | Reference |
+========+=========================+===============+===========+
| TBA1 | Network Action for IOAM | Post-Stack | This |
| | and IOAM-DEX in PSD | Only | document |
+--------+-------------------------+---------------+-----------+
| TBA2 | Network Action for | In-Stack Only | This |
| | IOAM-DEX in ISD | | document |
+--------+-------------------------+---------------+-----------+
Table 2: Network Action Opcodes
10. References
10.1. Normative References
[I-D.ietf-mpls-mna-ps-hdr]
Rajamanickam, J., Gandhi, R., Zigler, R., Dong, J., and J.
Bhattacharya, "MPLS Network Action (MNA) Post-Stack Header
Specification", Work in Progress, Internet-Draft, draft-
Gandhi, et al. Expires 28 April 2027 [Page 23]
Internet-Draft MPLS Network Actions for IOAM October 2026
ietf-mpls-mna-ps-hdr-19, 6 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-ps-hdr-19>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
Mizrahi, "In Situ Operations, Administration, and
Maintenance (IOAM) Direct Exporting", RFC 9326,
DOI 10.17487/RFC9326, November 2022,
<https://www.rfc-editor.org/info/rfc9326>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[RFC9630] Song, H., McBride, M., Mirsky, G., Mishra, G., Asaeda, H.,
and T. Zhou, "Multicast On-Path Telemetry Using In Situ
Operations, Administration, and Maintenance (IOAM)",
RFC 9630, DOI 10.17487/RFC9630, August 2024,
<https://www.rfc-editor.org/info/rfc9630>.
[RFC9789] Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Network Actions (MNAs) Framework", RFC 9789,
DOI 10.17487/RFC9789, July 2025,
<https://www.rfc-editor.org/info/rfc9789>.
Gandhi, et al. Expires 28 April 2027 [Page 24]
Internet-Draft MPLS Network Actions for IOAM October 2026
[RFC9994] Rajamanickam, J., Ed., Gandhi, R., Ed., Zigler, R., Song,
H., and K. Kompella, "MPLS Network Action (MNA) Sub-Stack
Specification Including In-Stack Network Actions and
Data", RFC 9994, DOI 10.17487/RFC9994, June 2026,
<https://www.rfc-editor.org/info/rfc9994>.
10.2. Informative References
[I-D.ietf-intarea-tunnels]
Touch, J. D. and M. Townsley, "IP Tunnels in the Internet
Architecture", Work in Progress, Internet-Draft, draft-
ietf-intarea-tunnels-15, 9 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
tunnels-15>.
[IANA-IOAM-Trace-Type]
IANA, "IOAM Trace-Type",
<https://www.iana.org/assignments/ioam/ioam.xhtml#trace-
type>.
[RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit
Signalling Extensions for the Label Distribution
Protocol", RFC 3988, DOI 10.17487/RFC3988, February 2005,
<https://www.rfc-editor.org/info/rfc3988>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8899] Fairhurst, G., Jones, T., Tuxen, M., Rungeler, I., and T.
Volker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
Gandhi, et al. Expires 28 April 2027 [Page 25]
Internet-Draft MPLS Network Actions for IOAM October 2026
[RFC9378] Brockners, F., Ed., Bhandari, S., Ed., Bernier, D., and T.
Mizrahi, Ed., "In Situ Operations, Administration, and
Maintenance (IOAM) Deployment", RFC 9378,
DOI 10.17487/RFC9378, April 2023,
<https://www.rfc-editor.org/info/rfc9378>.
[RFC9613] Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements
for Solutions that Support MPLS Network Actions (MNAs)",
RFC 9613, DOI 10.17487/RFC9613, August 2024,
<https://www.rfc-editor.org/info/rfc9613>.
[RFC9790] Kompella, K., Bryant, S., Bocci, M., Mirsky, G., Ed.,
Andersson, L., and J. Dong, "IANA Registry and Processing
Recommendations for the First Nibble Following a Label
Stack", RFC 9790, DOI 10.17487/RFC9790, July 2025,
<https://www.rfc-editor.org/info/rfc9790>.
[RFC9791] Saad, T., Makhijani, K., Song, H., and G. Mirsky, "Use
Cases for MPLS Network Action Indicators and Ancillary
Data", RFC 9791, DOI 10.17487/RFC9791, July 2025,
<https://www.rfc-editor.org/info/rfc9791>.
Appendix A: In-Stack and Post-Stack Network Action Processing Order
Example
As described in Section 5.5 of [RFC9994], the network actions in a
NAS are processed in order starting from the top of the label stack.
The Post-Stack MPLS Header Start network action (opcode 6) defined in
[I-D.ietf-mpls-mna-ps-hdr] can be added to interleave Post-Stack
Network Actions with In-Stack Network Actions to define processing
order. The following example shows how to process the Post-Stack
Network Action before some of the In-Stack Network Actions in a NAS.
Gandhi, et al. Expires 28 April 2027 [Page 26]
Internet-Draft MPLS Network Actions for IOAM October 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| MNA Label (value 4) | TC |0| TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Opcode=L | Ancillary Data |1|IHS|0| NASL=3|U|NAL=0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| Opcode=1 | Flag-Based NAIs |0| NAIs |U|NAL=0| A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
| Opcode=6 | 0 |0| 0 |U|NAL=0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Opcode=M | Ancillary Data |1| AD |U|NAL=0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| PFN |Reserve| PSMH-Len | Type = MNA Post-Stack Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
| Opcode=TBA1 |R|R| PS-NAL | Block-Number |R|IOAM-Opt-Type| S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M
~ IOAM Option-Type and Data Space [RFC9197] [RFC9326] ~ H
~ Beginning from Namespace-ID ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
~ Optional Payload + Padding ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
Figure 7: Example of In-Stack and Post-Stack Network Action
Processing Order
In this example, shown in Figure 7, the network actions in the NAS
are processed in the following order:
* Opcode L (Network action allocated outside of this document) is
processed first.
* Opcode 1 (Network action for Flag-Based NAIs defined in [RFC9994])
is processed next.
* Opcode 6 (Network action for Post-Stack MPLS Header Start Offset
defined in [I-D.ietf-mpls-mna-ps-hdr]) is processed next. The
Data value set to 0 indicates that the associated PSMH starts
immediately after the BoS.
* Opcode TBA1 (Network action for IOAM and IOAM-DEX in PSD) in the
associated PSMH is processed next.
* Opcode M (Network action allocated outside of this document) is
processed finally.
Gandhi, et al. Expires 28 April 2027 [Page 27]
Internet-Draft MPLS Network Actions for IOAM October 2026
Acknowledgments
The authors would like to thank Patrick Khordoc, Sagar Soni, Shwetha
Bhandari, Vengada Prasad Govindan, Tarek Saad, Stewart Bryant, Xiao
Min, Jaganbabu Rajamanickam, and Cheng Li for reviewing an early
version of this document. The authors would also like to thank Mach
Chen, Andrew Malis, Matthew Bocci, and Nick Delregno for the MPLS-RT
expert review of the early version of this document.
The authors would like to thank Adrian Farrel, Jie Dong, and Xueyan
Song for reviewing this document and providing review comments. The
authors also thank Matthew Bocci for the early Rtgdir review, Sheng
Jiang for the early Opsdir review, Giuseppe Fioccola for the
PerfMetrDir review, Adrian Farrel for the Shepherd's review, and
Joseph Touch for the Tsvart review. These reviews helped improve
this document.
Contributors
The following people have substantially contributed to this document:
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Frank Brockners
Cisco Systems, Inc.
Germany
Email: fbrockne@cisco.com
Loa Andersson
Huawei Technologies
Email: loa@pi.nu
Authors' Addresses
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Greg Mirsky (editor)
Ciena Corporation
Email: gregimirsky@gmail.com
Gandhi, et al. Expires 28 April 2027 [Page 28]
Internet-Draft MPLS Network Actions for IOAM October 2026
Haoyu Song
Futurewei Technologies
United States of America
Email: haoyu.song@futurewei.com
Bin Wen
Comcast
United States of America
Email: Bin_Wen@cable.comcast.com
Voitek Kozak
Comcast
United States of America
Email: Voitek_Kozak@comcast.com
Gandhi, et al. Expires 28 April 2027 [Page 29]