Supporting In Situ Operations, Administration, and Maintenance Using MPLS Network Actions
draft-ietf-mpls-mna-ioam-07

MPLS Working Group                                        R. Gandhi, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                          G. Mirsky, Ed.
Expires: 19 January 2027                                      Individual
                                                                 H. Song
                                                  Futurewei Technologies
                                                                  B. Wen
                                                                V. Kozak
                                                                 Comcast
                                                            18 July 2026

  Supporting In Situ Operations, Administration, and Maintenance Using
                          MPLS Network Actions
                      draft-ietf-mpls-mna-ioam-07

Abstract

   In situ Operations, Administration, and Maintenance (IOAM), defined
   in RFC 9197, is an on-path telemetry method to collect and record the
   operational state and telemetry information using, for example, Pre-
   allocated Trace, Proof-of-Transit, Edge-to-Edge, or Incremental Trace
   Option-Types that can be used to calculate various performance
   metrics.  RFC 9326 defines the IOAM Direct Export (IOAM-DEX) Option-
   Type in which the operational state and telemetry information are
   collected according to the specified profile and exported in a manner
   and format defined by a local policy on each node along the path.

   MPLS Network Actions (MNA) techniques are meant to indicate actions
   to be performed on any combination of Label Switched Paths, MPLS
   packets, and the node itself, and to transport data needed for these
   actions.  This document employs the MNA mechanisms to collect and
   transport the on-path operational state, and telemetry information
   using IOAM data fields as well as using direct export.

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 19 January 2027                [Page 1]
Internet-Draft       IOAM Using MPLS Network Actions           July 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 19 January 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.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   3.  Applicability of IOAM and IOAM-DEX in an MPLS Network . . . .   5
   4.  Realization of IOAM and IOAM-DEX as MPLS Network Actions  . .   5
     4.1.  Realization of IOAM and IOAM-DEX as Post-Stack MNA  . . .   5
       4.1.1.  MPLS Network Action Post-Stack MPLS Header for IOAM and
               IOAM-DEX  . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Realization of IOAM-DEX as In-Stack MNA . . . . . . . . .   9
       4.2.1.  IOAM-DEX Option-Type Encoding as MNA ISD  . . . . . .  10
   5.  Considerations for IOAM and IOAM-DEX in MPLS Networks . . . .  13
     5.1.  Ingress-to-Egress Scope IOAM and IOAM-DEX Network
           Actions . . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.2.  Hop-by-Hop Scope IOAM and IOAM-DEX Network Actions  . . .  14
     5.3.  Node Capability . . . . . . . . . . . . . . . . . . . . .  15
     5.4.  Nested MPLS Encapsulation . . . . . . . . . . . . . . . .  15
     5.5.  Readable Label Depth Consideration  . . . . . . . . . . .  15
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     8.1.  MPLS Network Action Opcodes . . . . . . . . . . . . . . .  16
   9.  Appendix A: Examples  . . . . . . . . . . . . . . . . . . . .  16
     9.1.  In-Stack and Post-Stack Network Action Processing
           Order . . . . . . . . . . . . . . . . . . . . . . . . . .  16

Gandhi, et al.           Expires 19 January 2027                [Page 2]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     10.2.  Informational References . . . . . . . . . . . . . . . .  18
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  19
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   In situ OAM (IOAM) [RFC9197] is an on-path telemetry method used to
   collect and record the operational state and telemetry information
   that can be used to calculate various performance metrics.  Several
   IOAM Option-Types (e.g., Pre-allocated Trace, Proof-of-Transit (POT),
   Edge-to-Edge (E2E), and Incremental Trace) use user packets to
   collect the operational state and telemetry information.  Such
   mechanisms transport the collected information to an IOAM
   decapsulating node (typically located at the edge of the IOAM domain
   within the data path).

   IOAM Direct Export (IOAM-DEX) [RFC9326] is an IOAM Option-Type in
   which the operational state and telemetry information are collected
   according to the specified profile and exported in a manner and
   format defined by a local policy on each node along the path.

   MPLS Network Actions (MNA) techniques [RFC9789] indicate actions to
   be performed on any combination of Label Switched Paths, MPLS
   packets, and the node itself, and also allow for the transport of
   data needed for these actions.  [RFC9994] defines mechanisms for
   carrying the 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 the IOAM and IOAM-DEX.

   This document employs the MNA mechanisms to collect and transport the
   on-path operational state and telemetry information using IOAM data
   fields for IOAM Option-Types, IOAM Pre-allocated Trace, POT, E2E, and
   IOAM-DEX.  The mechanism for exporting the collected information for
   the IOAM-DEX Option-Type is outside the scope of this document.
   Also, support for Incremental Trace IOAM Option-Type is outside the
   scope of this document.

Gandhi, et al.           Expires 19 January 2027                [Page 3]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

2.  Conventions Used in This Document

2.1.  Acronyms

   OAM: Operations, Administration, and Maintenance

   HBH: Hop-by-Hop

   I2E: Ingress-to-Egress

   IHS: Ingress-to-Egress (I2E), Hop-by-Hop (HBH) or Select Scope

   IOAM: In situ OAM

   IOAM-DEX: IOAM Direct Export

   IOAM-DEX-ISD-MNA: IOAM Direct Export as MPLS Network Action ISD

   ISD: In-Stack Data

   PFN: Post-Stack First Nibble

   PSD: Post-Stack Data

   PSMH: Post-Stack MPLS Header

   LSE: Label Stack Entry

   MPLS: Multiprotocol Label Switching

   MNA: MPLS Network Action

   NAI: Network Action Indicator

   NAS: Network Action Sub-Stack

   NASL: Network Action Sub-Stack Length

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.

Gandhi, et al.           Expires 19 January 2027                [Page 4]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

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 supporting Pre-allocated Trace,
   POT, and E2E IOAM Option-Types (Section 4.1).

   However, for some use cases, e.g., mobile backhaul, in which network
   resources are closely controlled, collecting and transporting the
   telemetry information within a user packet may noticeably decrease
   the cost-efficiency of network operations.  As such, collecting and
   transporting the operational state and telemetry information using
   the management plane is a viable option for some environments.  IOAM-
   DEX [RFC9326] is capable of collecting the IOAM data fields defined
   in [RFC9197].  In this document, the In-Stack and Post-Stack
   realizations of IOAM-DEX are defined in Section 4.2 and Section 4.1,
   respectively.

   The procedure defined in this document to carry IOAM Option-Types
   using the MNA solution can be applied to user traffic packets and
   active measurement test packets.  [I-D.gandhi-ippm-stamp-mpls-hdr]
   uses the mechanisms to transport IOAM Option-Types using the MNA
   solution defined in this document, with Simple Two-Way Active
   Measurement Protocol (STAMP) test packets for Hop-by-Hop (HBH) and
   E2E measurements.

4.  Realization of IOAM and IOAM-DEX as MPLS Network Actions

4.1.  Realization of IOAM and IOAM-DEX as Post-Stack MNA

   The presence of a corresponding Post-Stack MPLS Header (PSMH) is
   indicated in the NAS as defined in [I-D.ietf-mpls-mna-ps-hdr] and is
   shown in Figure 1.

Gandhi, et al.           Expires 19 January 2027                [Page 5]
Internet-Draft       IOAM Using MPLS Network Actions           July 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  |S|  TTL          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Opcode     |  13-bit Data (Format B) |P|IHS|S|  NASL |U| NAL |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Opcode     |  16-bit Data (Format C)       |S|4b Data|U| NAL |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Label                  | TC  |1|  TTL          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~ Post-Stack MPLS Header for IOAM and IOAM-DEX as per Figure 2  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                Optional Payload + Padding                     ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 1: An Example of In-Stack Network Action Sub-Stack for
             Post-Stack MPLS Header Carrying IOAM and IOAM-DEX

   The MNA Label (value 4) is defined in [RFC9994].

   The IHS scope field defined in [RFC9994] is used to indicate that
   I2E, HBH, or Select processing is required for the Network Action and
   Ancillary Data.

   If both edge and intermediate nodes need to process the IOAM data
   fields, then the IHS scope MUST be set to "HBH, value 0x1".  If only
   edge nodes need to process the IOAM data fields, then the IHS scope
   MUST be set to "I2E, value 0x0".  The I2E scope allows skipping the
   IOAM data processing on the intermediate nodes, i.e., it avoids the
   need to parse all IOAM data fields to detect the HBH Option-Type.

   U: The U flag for Unknown Action Handling is specified in [RFC9994].

   S: The Bottom of Stack bit [RFC3032].

   IHS (2-bit): The IHS field is set as specified in [RFC9994].

   P: The P flag is set as specified in [I-D.ietf-mpls-mna-ps-hdr].

   NASL (4-bit): The Network Action Sub-Stack Length (NASL) is set as
   specified in [RFC9994].

Gandhi, et al.           Expires 19 January 2027                [Page 6]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

   Opcode (7-bit): Opcode TBA1 for Network Action for IOAM and IOAM-DEX
   in PSD, for carrying an IOAM Option-Type and the associated data
   fields defined in [RFC9197] and the IOAM-DEX Option-Type and the
   associated data fields defined in [RFC9326], both in the PSMH.  This
   network action is optional and can be carried in a Format B or Format
   C Label Stack Entry (LSE).

   The Data (13-bit, next to the Opcode field) in the LSE contains the
   PSMH offset for this In-Stack Network Action in 4-octet units after
   the BoS LSE to the start of the corresponding Post-Stack Network
   Action Opcode.  Due to the Post-Stack MPLS Base Header, the minimum
   value for the offset is 1 (i.e., 4 octets).

   NAL (3-bit): The Length of Network Action (NAL) [RFC9994] is set to 0
   for the In-Stack Network Action for the IOAM and IOAM-DEX Option-Type
   in Post-Stack ancillary data.

   A packet may carry more than one In-Stack Network Action in an MNA
   Sub-Stack for IOAM and IOAM-DEX in the PSMH (for example, for
   different IOAM Option-Types as identified in Post-Stack ancillary
   data).  There may be a different In-Stack Network Action (other than
   for the IOAM and IOAM-DEX) in the In-Stack MNA Sub-Stack.

4.1.1.  MPLS Network Action Post-Stack MPLS Header for IOAM and IOAM-DEX

   An example encoding for IOAM and IOAM-DEX carried in a PSMH 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  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  MNA-PS-OP  |R|R|   PS-NAL    | Block-Number  |R|IOAM-Opt-Type|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~       IOAM Option-Type and Data Space [RFC9197] [RFC9326]     ~
    ~       Beginning from Namespace-ID                             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: An Example of Post-Stack MPLS Header Carrying IOAM and
                                  IOAM-DEX

   The Post-Stack MPLS Base Header is added that contains the following
   fields as defined in [I-D.ietf-mpls-mna-ps-hdr].

   PFN (4-bit):  The Post-Stack First Nibble (PFN) (value 0x0) as
     defined in [I-D.ietf-mpls-mna-ps-hdr].

Gandhi, et al.           Expires 19 January 2027                [Page 7]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

   PSMH-Len (8-bit):  The PSMH total length as defined in
     [I-D.ietf-mpls-mna-ps-hdr].

   Type (16-bit):  Type for MNA Post-Stack Header (value 1) as defined
     in [I-D.ietf-mpls-mna-ps-hdr].

   The PSMH is added after the Post-Stack MPLS Base Header and contains
   the Post-Stack Network Action Opcode for IOAM and IOAM-DEX, the
   length in number of 4-octet units, and the IOAM Option-Type with IOAM
   data fields in the Post-Stack ancillary data as shown in Figure 2.
   The IOAM data fields MUST follow the definitions corresponding to
   their IOAM Option-Types (e.g., see Section 4.4 of [RFC9197] and the
   IOAM-DEX Option-Type in Section 3 of [RFC9326]).

   An IOAM Option-Type is added in the PSMH containing the following
   fields:

   MNA-PS-OP (7-bit):  Opcode TBA1 (Network Action Opcode for IOAM and
     IOAM-DEX in PSD) for the IOAM Option-Type defined in [RFC9197], and
     the IOAM-DEX Option-Type defined in [RFC9326].

   IOAM-Opt-Type (7-bit):  The field to carry the IOAM Option-Type, as
     defined in the "IOAM Option-Type Registry" in [RFC9197] and
     [RFC9326].

   PS-NAL (7-bit):  The unsigned integer.  Length of the IOAM data
     fields in 4-octet units for the MNA-PS-OP.  This excludes the first
     4-octet unit.

   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
     (e.g., see Section 4.4 of [RFC9197] and Section 3 of [RFC9326]).

   Block-Number (8-bit):  The block number for the alternate marking
     method can be used to aggregate the IOAM data collected in the data
     plane, e.g., to compute measurement metrics for each block of a
     data flow.  It is also used to correlate the collected IOAM data
     from different nodes along the packet path.  The block number is
     incremented sequentially at every measurement interval provisioned
     on the encapsulating node.

4.1.1.1.  Multiple IOAM and IOAM-DEX Option-Types in PSMH

   An example of multiple Post-Stack network actions with the same scope
   carrying different IOAM Option-Types is shown in Figure 3.

Gandhi, et al.           Expires 19 January 2027                [Page 8]
Internet-Draft       IOAM Using MPLS Network Actions           July 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-OP  |R|R|   PS-NAL    | Block-Number  |R|IOAM-Opt-Type|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~  IOAM Option-Type and Data Space [RFC9197] [RFC9326]          ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  MNA-PS-OP  |R|R|   PS-NAL    | Block-Number  |R|IOAM-Opt-Type|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~  IOAM Option-Type and Data Space [RFC9197] [RFC9326]          ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                 Optional Payload + Padding                    ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 3: Example of Multiple Post-Stack Network Actions with
                   IOAM and IOAM-DEX with the Same Scope

4.2.  Realization of IOAM-DEX as In-Stack MNA

   This document uses all the elements of the IOAM-DEX Option-Type
   format defined in [RFC9326] to support IOAM-DEX in an MPLS network
   using MNA ISD [RFC9994].

   To support the direct export of the operational state and telemetry
   information, the IOAM-DEX-ISD-MNA blob (binary large object) is
   placed as part of the ISD block in an MPLS label stack according to
   the MNA encoding procedures defined in [RFC9994].

   Using the IHS field, the IOAM-DEX-ISD-MNA can operate in Hop-by-Hop,
   Ingress-to-Egress, or Select modes [RFC9789] to collect the
   operational state and telemetry information using an MNA Opcode
   (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        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Opcode = TBA2|  13-bit Data (Format B) |P|IHS|S|  NASL |U| NAL |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~1|     IOAM-DEX-ISD-MNA as per Figure 5      |S|               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gandhi, et al.           Expires 19 January 2027                [Page 9]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

      Figure 4: An Example of IOAM-DEX Encapsulation as an MNA Opcode

   Here, the enclosed elements are defined as follows:

   *  The MNA Label (value 4) as defined in [RFC9994].

   *  S: The Bottom of Stack bit [RFC3032].

   *  P: The P flag is set as specified in [I-D.ietf-mpls-mna-ps-hdr].

   *  The IHS, U, and NAL fields are set as specified in [RFC9994].

   *  NASL (4-bit): The number of LSEs that compose the IOAM-DEX-ISD-MNA
      blob.

   *  Opcode (7-bit): Set to TBA2 for MNA-IOAM-DEX.

   *  Data: Data field is not used and set to 0.

   *  IOAM-DEX-ISD-MNA: IOAM-DEX in MPLS Network Action ISD encoding.

   Policies controlling the processing of the collected operational
   state and telemetry information, and their transport, are outside the
   scope of this document.

4.2.1.  IOAM-DEX Option-Type Encoding as MNA ISD

   The IOAM-DEX-ISD-MNA blob in a NAS uses the LSE Format D, as defined
   in Section 4.4 of [RFC9994], that maps to the IOAM-DEX Option-Type
   format [RFC9326].  In addition to the requirement to preserve the S
   bit, the most significant bit in LSE Format D 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-ISD-MNA blob in
   an 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 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|         Flow ID MNA (Optional)            |S|  Flow ID MNA  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|         Sequence Number MNA (Optional)    |S|  Seq Num MNA  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gandhi, et al.           Expires 19 January 2027               [Page 10]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

     Figure 5: IOAM-DEX Option-Type Format for MPLS Network Action ISD

   Where fields are defined as follows:

   *  Namespace-ID (16-bit): Identifier of the IOAM Namespace, as
      defined in [RFC9197].

   *  Reserved (6-bit): The Reserved field MUST be set to 0 on transmit
      and ignored on receipt.

   *  S: The Bottom of Stack bit [RFC3032].

   *  Flags (8-bit): The flags field comprises of 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].

   *  IOAM-Trace-Type-MNA (22-bit): The interpretation of bit positions
      in the IOAM-Trace-Type-MNA is as specified in [RFC9197], from bit
      0 through bit 21.  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: This is a one-bit flag identical to the interpretation of bit
      22 marked as "variable-length Opaque State Snapshot" as defined in
      [RFC9197] and assigned code points found in IANA's IOAM Trace-Type
      registry [IANA-IOAM-Trace-Type].

   *  R: This is a one-bit flag identical to the interpretation of bit
      23 marked as "reserved" as defined in [RFC9197] and assigned code
      points found in IANA's IOAM Trace-Type registry
      [IANA-IOAM-Trace-Type].  Similarly to [RFC9197], 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 concatenation of the 22-bit IOAM-Trace-Type-MNA field with O
      and R flags, explained above, is identical to the 24-bit IOAM-
      Trace-Type field in Section 3.2 of [RFC9326], and in the
      interpretation of its bits as defined in [RFC9197] and assigned
      code points found in IANA's IOAM Trace-Type registry
      [IANA-IOAM-Trace-Type].

Gandhi, et al.           Expires 19 January 2027               [Page 11]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

   *  Ext-Flags (6-bit): This field comprises of six one-bit subfields.
      The allocation of the subfields in the Ext-Flags field is
      according to Section 4.3 of [RFC9326].  The allocated flags
      indicate the presence of the optional Flow ID MNA and/or Sequence
      Number MNA fields in the IOAM-DEX-ISD-MNA header.  The length of
      the Ext-Flags field in the IOAM-DEX Option-Type in MNA is shorter
      by two one-bit fields compared to the length of the Extension
      Flags field defined in Section 3.2 of [RFC9326].  However,
      currently only two flags have been assigned by IANA as defined in
      Section 4.3 of [RFC9326], and six flags have not been assigned by
      IANA.  Similarly, in the Ext-Flags of the IOAM-DEX-ISD-MNA header,
      two flags have been mapped to those IANA assigned flags in the
      IOAM-DEX Option-Type, and four flags remain unmapped.  Figure 6
      displays the detailed format of the Ext-Flags field.

   *  According to Section 3.2 in [RFC9326], the Reserved field is used
      to align optional fields at the 4-octet word boundary in IOAM-DEX
      Option-Type.  In the case of the IOAM-DEX in MNA, for optional
      fields such as Flow ID MNA and Sequence Number MNA, such alignment
      is achieved without adding such Reserved field as padding.

   *  Flow ID MNA: An optional 4-octet field and carries a 30-bit Flow
      ID (after removing leading 1 and S bits).  The semantics of the
      Flow ID MNA field are as those of the Flow ID field defined in
      Section 3.2 of [RFC9326].  The most significant bit MUST be set to
      1.  The bit 23 MUST be set according to the definition of the S
      bit in [RFC3032].

   *  Sequence Number MNA: An optional 4-octet field and carries a
      30-bit sequence number (after removing leading 1 and S bits).  The
      semantics of the Sequence Number MNA field are as those of the
      Sequence Number field defined in Section 3.2 of [RFC9326].  The
      most significant bit MUST be set to 1.  The bit 23 MUST be set
      according to the definition of the S bit in [RFC3032].  In MPLS
      network environments where 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 that the value of the Flow
      ID MNA field identifies.  In MPLS networks, where other load-
      balancing techniques are used, all bits of the Sequence Number MNA
      field can be varied.

                             0 1 2 3 4 5
                            +-+-+-+-+-+-+
                            |F|N|U|U|U|U|
                            +-+-+-+-+-+-+

Gandhi, et al.           Expires 19 January 2027               [Page 12]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

                      Figure 6: Ext-Flags Field Format

   Where fields are defined as follows:

   *  F: One-bit flag.  When the F flag is set to 1, it indicates the
      presence of the Flow ID field in the IOAM-DEX-ISD-MNA header.

   *  N: One-bit flag.  When the N flag is set to 1, it indicates the
      presence of the Sequence Number field in the IOAM-DEX-ISD-MNA
      header.

   *  U: Unassigned one-bit flag.  It MUST be set to zero on
      transmission and the value MUST be ignored upon receipt.

5.  Considerations for IOAM and IOAM-DEX in MPLS Networks

5.1.  Ingress-to-Egress Scope IOAM and IOAM-DEX Network Actions

   The I2E IOAM data fields carry IOAM Option-Types that require
   processing on the encapsulating and decapsulating nodes only.

   The IOAM Option-Type carried can be the IOAM E2E Option-Type (value
   3) defined in [RFC9197] as well as the IOAM-DEX Option-Type (value 4)
   defined in [RFC9326].  The I2E IOAM data fields SHOULD NOT carry any
   IOAM Option-Type that requires IOAM processing on the intermediate
   nodes, as it will not be processed by them when the IHS scope is set
   to "I2E, value 0x0".

   The I2E IOAM and IOAM-DEX Network Action procedure is summarized as
   follows:

   *  The encapsulating node inserts an MNA Sub-Stack with the MNA Label
      with the IHS scope set to "I2E, value 0x0", one or more In-Stack
      Network Actions, and one or more IOAM data fields in the MPLS
      packet.

   *  The intermediate nodes do not process the I2E IOAM data fields.

   *  The decapsulating node MAY punt the IOAM data fields from the
      packet with the receive timestamp to the slow path for processing.
      The receive timestamp is required by the various I2E IOAM use
      cases, including streaming telemetry.  Note that the packet is not
      necessarily punted to the control-plane.

   *  The decapsulating 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.

Gandhi, et al.           Expires 19 January 2027               [Page 13]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

   *  The decapsulating node MUST remove the Network Actions and IOAM
      data fields from the received packet.  The decapsulated packet is
      forwarded downstream or terminated locally similar to the regular
      data packets.

5.2.  Hop-by-Hop Scope IOAM and IOAM-DEX Network Actions

   The HBH IOAM data fields carry IOAM Option-Types that require
   processing at the intermediate and/or encapsulating and decapsulating
   nodes.

   The IOAM Option-Type carried can be the Pre-allocated Trace (value
   0), the POT (value 2), and the E2E (value 3) defined in [RFC9197] as
   well as the IOAM-DEX (value 4) defined in [RFC9326].

   Note that the MPLS Network Action defined in this document is not
   supported for the HBH IOAM Incremental Trace Option-Type (value 1).

   The Hop-by-Hop IOAM and IOAM-DEX Network Action procedure is
   summarized as follows:

   *  The encapsulating node inserts an MNA Sub-Stack containing the MNA
      Label, with the IHS scope set to "HBH, value 0x1", one or more In-
      Stack Network Actions for IOAM, and one or more IOAM data fields
      in the MPLS packet.

   *  The intermediate node that is enabled for the HBH IOAM function
      processes the data packet including the IOAM data fields as
      defined in [RFC9197] and [RFC9326] when the node recognizes the
      HBH scope in the MNA Sub-Stack.

   *  The intermediate node MAY punt the IOAM data fields from the
      packet with the receive timestamp to the slow path for processing
      when the node recognizes the HBH scope.  The receive timestamp is
      required by the various HBH IOAM use cases, including streaming
      telemetry.  Note that the packet is not necessarily punted to the
      control-plane.

   *  The intermediate node forwards the data packet downstream.

   *  The processing on the decapsulating node is the same as in the I2E
      case.

   Both HBH and I2E Scope IOAM may be carried in the Post-Stack MNA in
   an MPLS packet.  In this case, the PSMH with HBH IOAM data fields
   MUST be added after the BoS and before the PSMH with I2E IOAM data
   fields.  This way, the RLD required to process them on the
   intermediate nodes is minimized.

Gandhi, et al.           Expires 19 January 2027               [Page 14]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

5.3.  Node Capability

   The decapsulating node that needs to remove the IOAM and IOAM-DEX
   data fields and perform the IOAM and IOAM-DEX functions may not be
   capable of supporting them.  The encapsulating node needs to know if
   the decapsulating node can support the IOAM and IOAM-DEX functions.
   The signaling extension for this capability exchange is outside the
   scope of this document.

   The intermediate node that is not capable of supporting the IOAM and
   IOAM-DEX functions defined in this document can simply skip the IOAM
   and IOAM-DEX processing.

5.4.  Nested MPLS Encapsulation

   When a packet is received with an MPLS encapsulated Network Action
   for IOAM and IOAM-DEX, and the nested MPLS encapsulating node needs
   to add a different Network Action for IOAM and IOAM-DEX, the node
   MUST add a new MNA Sub-Stack with the Network Action for IOAM and
   IOAM-DEX as part of the new MPLS encapsulation.

5.5.  Readable Label Depth Consideration

   The encapsulating node needs to make sure that the IOAM and IOAM-DEX
   data fields in the MNA are added within the Readable Label Depth
   (RLD) of the downstream MNA-capable nodes in order for them to be
   able to process the IOAM and IOAM-DEX.

6.  Operational Considerations

   Operational considerations discussed in [RFC9994] and
   [I-D.ietf-mpls-mna-ps-hdr], management considerations discussed in
   [RFC9789], and management and deployment considerations discussed in
   [RFC9197] apply to this document.  The performance considerations
   discussed in Section 5 of [RFC9326] are also applicable here.

7.  Security Considerations

   Security considerations discussed in [RFC9197], [RFC9326], [RFC9994],
   [I-D.ietf-mpls-mna-ps-hdr] and [RFC9789] apply to this document.

Gandhi, et al.           Expires 19 January 2027               [Page 15]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

   The usage of MPLS Network Actions defined in this document for IOAM
   and IOAM-DEX is intended for deployment in a single network
   administrative domain.  As such, it assumes that the operator
   enabling the IOAM and IOAM-DEX operations has previously verified the
   integrity of the path.  Still, operators need to properly secure the
   IOAM and IOAM-DEX in the domain to avoid malicious configuration and
   use, which could include injecting malicious IOAM and IOAM-DEX
   packets into the domain.

8.  IANA Considerations

8.1.  MPLS Network Action Opcodes

   IANA is requested to assign code points from its Network Action
   Opcodes registry (creation requested in [RFC9994] and update
   requested in [I-D.ietf-mpls-mna-ps-hdr]) as specified in Table 1.

      +========+=================+======================+===========+
      | Opcode | Description     | In-Stack Only, Post- | Reference |
      |        |                 | Stack Only, In-Stack |           |
      |        |                 | and Post-Stack       |           |
      +========+=================+======================+===========+
      | TBA1   | Network Action  | In-Stack and Post-   | This      |
      |        | for IOAM and    | Stack                | document  |
      |        | IOAM-DEX in PSD |                      |           |
      +--------+-----------------+----------------------+-----------+
      | TBA2   | Network Action  | In-Stack Only        | This      |
      |        | for IOAM-DEX in |                      | document  |
      |        | ISD             |                      |           |
      +--------+-----------------+----------------------+-----------+

                    Table 1: MPLS Network Action Opcodes

9.  Appendix A: Examples

9.1.  In-Stack and Post-Stack Network Action Processing Order

   The In-Stack Network Action with Post-Stack Data can be added to
   interleave Post-Stack network actions with In-Stack network actions.
   The following example shows how to process the Post-Stack NA before
   some of the In-Stack NAs.

Gandhi, et al.           Expires 19 January 2027               [Page 16]
Internet-Draft       IOAM Using MPLS Network Actions           July 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=8    |      Ancillary Data     |1|IHS|0| NASL=3|U|NAL=0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Opcode=1    |      Flag-Based NAIs          |0| NAIs  |U|NAL=0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Opcode=TBA1 |      Post-Stack Offset=1      |0|PS-NAI |U|NAL=0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Opcode=7    |      Ancillary Data           |1|  AD   |U|NAL=0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | PFN   |Reserve|    PSMH-Len=1 | Type = MNA Post-Stack Header  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | PS-OP=TBA1  |R|R|  PS-NAL=0   |       Post-Stack Data         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 7: Post-Stack and In-Stack NA Processing Order

   In this example, opcode 8 is processed first, followed by opcode 1
   for Flag-Based NAIs, then opcode TBA1 (which has the corresponding
   Network Action opcode TBA1 in Post-Stack at an offset of 1 word,
   i.e., 4 octets from the BoS), and finally opcode 7.

10.  References

10.1.  Normative References

   [I-D.ietf-mpls-mna-ps-hdr]
              Rajamanickam, J., Gandhi, R., Zigler, R., Dong, J., and J.
              Bhattacharya, "Post-Stack MPLS Network Action (MNA) Header
              Specification", Work in Progress, Internet-Draft, draft-
              ietf-mpls-mna-ps-hdr-10, 18 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              mna-ps-hdr-10>.

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

Gandhi, et al.           Expires 19 January 2027               [Page 17]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

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

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

   [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.  Informational References

   [I-D.gandhi-ippm-stamp-mpls-hdr]
              Gandhi, R., Zhou, T., Li, Z., and F. Ihle, "Simple Two-Way
              Active Measurement Protocol (STAMP) Extensions for
              Reflecting STAMP Packet MPLS Extension Headers", Work in
              Progress, Internet-Draft, draft-gandhi-ippm-stamp-mpls-
              hdr-07, 5 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-gandhi-ippm-
              stamp-mpls-hdr-07>.

   [IANA-IOAM-Trace-Type]
              IANA, "IOAM Trace-Type",
              <https://www.iana.org/assignments/ioam/ioam.xhtml#trace-
              type>.

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

Gandhi, et al.           Expires 19 January 2027               [Page 18]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

Acknowledgments

   The authors would like to thank Adrian Farrel and Xueyan Song for
   reviewing this document and providing review comments.  The authors
   would also 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 the 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.

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)
   Individual
   Email: gregimirsky@gmail.com

   Haoyu Song
   Futurewei Technologies
   United States of America
   Email: haoyu.song@futurewei.com

Gandhi, et al.           Expires 19 January 2027               [Page 19]
Internet-Draft       IOAM Using MPLS Network Actions           July 2026

   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 19 January 2027               [Page 20]