RFC 9791

Use Cases for MPLS Network Action Indicators and Ancillary Data

📅 published July 2025, from ietf

RFC 9791: Use Cases for MPLS Network Action Indicators and Ancillary Data ✨

Okay bestie, let's talk about RFC 9791 🎀. The title is Use Cases for MPLS Network Action Indicators and Ancillary Data, and it's Informational, so it's published for information and isn't a Standards Track spec 🌸. It came out in July 2025 with ISSN 2070-1721. The four authors are T. Saad (Cisco Systems, Inc.), K. Makhijani (Independent), H. Song (Futurewei Technologies), and G. Mirsky (Ericsson) 💜. The header doesn't list anything it obsoletes or updates, so it stands on its own 🦋.

Abstract

This doc shows some use cases that share one thing: they can all be handled by encoding network action indicators and their ancillary data inside MPLS packets 🧚. The community is really into extending the MPLS data plane to carry that stuff for these cases ✨.

The use cases here aren't a complete list. They're the ones the IETF MPLS, PALS, and DetNet Working Groups actively talked about from the start of MPLS Network Action (MNA) work until this doc was published 💅.

Status of This Memo

This doc is not an Internet Standards Track specification. It's published for informational purposes 🌈.

It's a product of the Internet Engineering Task Force (IETF), so it reflects IETF community consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🤓.

You can find the current status, any errata, and where to send feedback at https://www.rfc-editor.org/info/rfc9791 🔥.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this doc must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License says 🫶.

Table of Contents

   1.  Introduction
     1.1.  Terminology
     1.2.  Abbreviations
   2.  Use Cases
     2.1.  No Further Fast Reroute
     2.2.  Applicability of Hybrid Measurement Methods
       2.2.1.  In Situ OAM
       2.2.2.  Alternate Marking Method
     2.3.  Network Slicing
     2.4.  NSH-Based Service Function Chaining
     2.5.  Network Programming
   3.  Coexistence with the Existing MPLS Services Using Post-Stack
           Headers
   4.  Coexistence of the MNA Use Cases
   5.  IANA Considerations
   6.  Security Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Appendix A.  Use Cases for Continued Discussion
     A.1.  Generic Delivery Functions
     A.2.  Delay Budgets for Time-Bound Applications
     A.3.  Stack-Based Methods for Latency Control
   Acknowledgements
   Contributors
   Authors' Addresses

1. Introduction 💖

This doc covers use cases that need special handling from the forwarding hardware 🔥. Right now, the way to do that is to allocate a brand-new Special-Purpose Label (SPL) [RFC3032] or an Extended Special-Purpose Label (eSPL). The thing is, SPLs are super scarce, and an eSPL costs an extra label stack entry for every network action, which is pricey 💸. So the MPLS Network Action (MNA) [RFC9613] approach was proposed to extend the MPLS architecture 🦋. MNA is meant to support functions that might need extra ancillary data inside MPLS packets. It also gives a way to say that the ancillary data is there and that a specific action has to happen to the packet ✨.

This doc lists a bunch of use cases that could really benefit from the MNA framework [RFC9789]. Building on the general MNA framework gives everyone a shared base for future network actions in the MPLS data plane 👑.

1.1. Terminology

The following terminology is used in the document:

  • RFC 9543 Network Slice: Interpreted as defined in [RFC9543]. This document uses "network slice" interchangeably as a shorter version of the term "RFC 9543 Network Slice". 🍓
  • MPLS Ancillary Data (also referred to in this document as "ancillary data"): Data that can be classified as:
    • residing within the MPLS label stack (referred to as "in-stack data"), and
    • residing after the Bottom of Stack (BoS) (referred to as "post-stack data"). 🧚

1.2. Abbreviations

  • AMM: Alternative Marking Method 💜
  • BoS: Bottom of Stack
  • DEX: Direct Export
  • eSPL: extended Special-Purpose Label
  • FRR: Fast Reroute
  • G-ACh: Generic Associated Channel
  • HbH: Hop by Hop
  • I2E: Ingress to Egress
  • IOAM: In situ Operations, Administration, and Maintenance
  • LSP: Label Switched Path
  • LSR: Label Switching Router
  • MNA: MPLS Network Action
  • NRP: Network Resource Partition
  • NSH: Network Service Header
  • PW: Pseudowire
  • SPL: Special-Purpose Label
  • ToS: Top of Stack 🌸

2. Use Cases 🎀

2.1. No Further Fast Reroute

MPLS Fast Reroute [RFC4090] [RFC5286] [RFC7490] [SR-TI-LFA] is a really useful, widely deployed tool for cutting down packet loss when a link or node fails 🙌.

There are situations where a packet gets rerouted away from a failure by one FRR, and then a second FRR hits that same packet on another node and can cause traffic disruption 😭.

In that case, the packet hit by multiple FRR events can keep looping between the Label Switching Routers (LSRs) that activated FRR, until its TTL runs out. That can cause link congestion and more packet loss 💀. To avoid this, packets that FRR has redirected get marked using MNA so that no further FRR processing happens ✨.

2.2. Applicability of Hybrid Measurement Methods

MNA can carry the info needed to collect operational data and measure performance metrics that reflect what the marked packet actually experienced 📊. Optionally, the operational state and telemetry gathered on the LSR may also be transported using MNA techniques 🫶.

2.2.1. In Situ OAM

In situ Operations, Administration, and Maintenance (IOAM), defined in [RFC9197] and [RFC9326], might be used to collect operational and telemetry information while a packet travels a particular path through a network domain 🛤️.

IOAM can run in two modes: Ingress to Egress (I2E) and Hop by Hop (HbH). In I2E mode, only the encapsulating and decapsulating nodes process IOAM data fields. In HbH mode, the encapsulating and decapsulating nodes, plus the intermediate IOAM-capable nodes, all process IOAM data fields 🔥. The IOAM data fields, defined in [RFC9197], can be used to figure out the operational state of the network as experienced by the packet carrying the IOAM Header on its trip through the IOAM domain 👀.

Several IOAM Option-Types have been defined:

  • Pre-allocated Trace
  • Incremental Trace
  • Edge-to-Edge
  • Proof-of-Transit
  • Direct Export (DEX)

For every IOAM Option-Type except Direct Export (DEX), the collected info rides along in the trigger IOAM packet. With IOAM DEX [RFC9326], the operational state and telemetry get collected according to a specified profile, then exported in a manner and format set by a local policy 📤. With IOAM DEX, the user data packet only serves to trigger the IOAM data to be directly exported or aggregated locally, so it doesn't get carried in the IOAM trigger packets 💅.

2.2.2. Alternate Marking Method

The Alternate Marking Method (AMM), defined in [RFC9341] and [RFC9342]), is an example of a hybrid performance measurement method [RFC7799] that can measure packet loss and packet delay performance metrics in an MPLS network 📈. [RFC8957] defines the Synonymous Flow Label framework for doing AMM in an MPLS network. MNA is an alternative mechanism that can also support AMM in an MPLS network 🦋.

2.3. Network Slicing

An RFC 9543 Network Slice Service [RFC9543] gives you connectivity paired with network resource commitments, and it's described in terms of one or more connectivity constructs 🍰. Section 5 of [NS-IP-MPLS] defines a Network Resource Partition (NRP) Policy as a policy construct that lets you instantiate the mechanisms behind one or more network slice services 🧩. Packets tied to an NRP may carry a marking in their network-layer header to show that association, called an NRP Selector. The NRP Selector maps a packet to its network resources and applies the matching forwarding treatment 💜.

A router forwarding a packet that belongs to an NRP might have to pick the forwarding action based on the selected next hop(s), and also pick the forwarding treatment (for example, scheduling and drop policy) to enforce based on the associated per-hop behavior 🧠.

So in this case, routers forwarding traffic over a physical link shared by multiple NRPs need to figure out which NRP each packet belongs to, so they can enforce the right forwarding actions and treatments 🚦.

MNA technologies can signal actions for MPLS packets and carry the data those actions need. For example, MNA can carry the NRP Selector [NS-IP-MPLS] in MPLS packets 🌈.

2.4. NSH-Based Service Function Chaining

[RFC8595] describes how Service Function Chaining can be done in an MPLS network by emulating the Network Service Header (NSH) [RFC8300] using only MPLS label stack entries 🔗.

The approach in [RFC8595] has some limitations, which [SFP-VERIF] talks about. Even so, the approach can benefit from the MNA framework introduced in [RFC9789] 💅.

MNA can extend the NSH emulation using MPLS labels [RFC8595] to support the functionality of NSH Context Headers, whether they're fixed or variable length. For example, MNA could support Flow ID [RFC9263], which may be used for load-balancing among Service Function Forwarders and/or the Service Functions within the same Service Function Path 🎀.

2.5. Network Programming

In Segment Routing (SR), an ingress node steers a packet through an ordered list of instructions called "segments". Each instruction represents a function to be called at a specific location in the network. A function is defined locally on the node where it runs, and it can be anything from simply moving forward in the segment list to any complex user-defined behavior 🪄.

Network Programming combines SR functions to reach a networking goal that goes beyond plain packet routing 🧚.

It may be desirable to encode a pointer to a function and its arguments within an MPLS packet transport header 💖. MNA can be used to encode the FUNC::ARGs, supporting the functional equivalent of FUNC::ARG in Segment Routing over IPv6 as described in [RFC8986] 👑.

3. Coexistence with the Existing MPLS Services Using Post-Stack Headers ✨

okay so MPLS is already carrying a LOT of stuff today 🚇 Layer 3 (L3) connectivity for unicast and multicast L3 services, and Layer 2 (L2) connectivity like unicast PWs, multicast E-Tree, and broadcast Ethernet LAN (E-LAN) L2 services. In all of those, the user's service traffic just rides along as the payload inside the MPLS packets. Main character energy, honestly 💅

For L2 service traffic, you can put a Control Word (CW) [RFC4385] [RFC5085] right after the MPLS header. It helps tell apart what kind of MPLS payload you're looking at, keeps packets from getting misordered, and allows for fragmentation 🧩 When the CW is there, the first nibble of the data right after the MPLS BoS is set to 0b0000, which is how you know the PW CW is present.

MPLS can also carry OAM data 🔍 (for example over MPLS Generic Associated Channels (G-AChs) [RFC5586]). In that case the first nibble of the data right after the MPLS BoS is set to 0b0001, which says there's a control channel tied to a PW, LSP, or section.

Bit Index Explicit Replication (BIER) [RFC8296] traffic can be encapsulated over MPLS too 🌈 BIER picked 0b0101 as the value for the first nibble of the data that shows up right after the BoS for any BIER-encapsulated packet over MPLS.

For PWs, the G-ACh [RFC7212] uses the first four bits of the PW control word to do the initial sorting between data packets and packets belonging to the associated channel, as described in [RFC4385]. Sorting, but make it networking 🎀

MPLS can even be the data plane for Deterministic Networking (DetNet) [RFC8655] 🦋 The DetNet sub-layers, forwarding, and service are all realized using the MPLS label stack, the DetNet control word [RFC8964], and the DetNet Associated Channel Header [RFC9546]. Iconic.

The MNA-based solutions for the use cases in this document, plus any proposed in the future, are expected to allow for coexistence and backward compatibility with all existing MPLS services 🫶 Nobody gets left behind!

4. Coexistence of the MNA Use Cases 🧚

Two or more of the discussed cases can coexist in the same packet 👯‍♀️ When that happens, you may need multiple ancillary data (whether in-stack or post-stack ancillary data) sitting in the same MPLS packet. Stacking is a whole vibe.

For example, IOAM can provide essential functions alongside network slicing 🍰 That helps make sure critical network slice Service Level Objectives (SLOs) are being met by the network provider. In this setup, IOAM can collect key performance measurement parameters of a network slice traffic flow while it travels across the transport network. Accountability, bestie 📊

5. IANA Considerations 🌸

This document has no IANA actions. Quiet, chill, zero registry drama 🍓

6. Security Considerations 💀

Section 7 of [RFC9789] outlines security considerations for documents that do not specify protocols. The authors have verified that these considerations are fully applicable to this document. Verified means verified, no cap 🔐

In-depth security analysis for each specific use case is beyond the scope of this document. That work will be addressed in future solution documents 😭 It is strongly recommended that those solution documents undergo review by a security expert early in their development, ideally during the Working Group Last Call phase. Get the security people in early, periodt 🛡️

7. References 📚

7.1. Normative References

7.2. Informative References

Appendix A. Use Cases for Continued Discussion ✨

Okay bestie, this appendix is where the spec gets a little dreamy. It's a list of use cases where MNA could be a viable solution 🦋 The discussion on these is still ongoing at the time this document gets published, so think of them as the "we're still cooking" section 🍳

A.1. Generic Delivery Functions

Generic Delivery Functions (GDFs), defined in [GDF], are a new mechanism for doing stuff that's kinda like what the IPv6 Extension Headers mechanism does 🎀 For example, GDF can handle fragmentation and reassembly in the MPLS network by using the Generic Fragmentation Header 🧩 MNA can support GDF by putting a GDF header in an MPLS packet, inside the post-stack data block [RFC9789] 💜 And it's not just one: multiple GDF headers can be organized as a list of headers and live in the same MPLS packet. Lowkey iconic 👑

A.2. Delay Budgets for Time-Bound Applications

Okay so routers do two different jobs with incoming packets. First is forwarding, which is deciding where the packet should go 🧭 Second is scheduling, which is deciding when the packet should go 🕰️ IEEE-802.1 Time-Sensitive Networking (TSN) and DetNet both give you a bunch of mechanisms for scheduling, and they assume the routers are time-synchronized ⏰ The most effective delay-minimizing mechanisms involve per-flow resource allocation, which is very much a "give each flow its own VIP section" energy 💅

Segment Routing (SR) is a forwarding paradigm where the forwarding instructions get encoded in the packet, in a stack data structure, instead of being programmed into the routers 🧚 The SR instructions ride inside the packet as a First-In, First-Out stack, and they dictate the forwarding decisions of each successive router, in order 📚 Segment routing can be used to pick a path that's short enough to offer a bounded end-to-end latency, but it does NOT influence how individual packets get queued at each router along that path 🙈 (The word "NOT" there is just me being dramatic, not a spec keyword, lol.)

When this is carried over the MPLS data plane, a solution is required to deliver these packets to their final destination within a given time budget ⏳ One approach to tackling this in SR over MPLS (SR-MPLS) is described in [SRTSN] 🌸

A.3. Stack-Based Methods for Latency Control

Here's a cute trick: one efficient way to put local deadlines into the headers is a "stack", kinda like the one SR already uses to carry forwarding instructions 🥞 The number of deadline values in the stack equals the number of routers the packet needs to cross in the network, and each deadline value matches up with one specific router 🎯 The Top of Stack (ToS) is the first router's deadline, and the MPLS BoS is the last one 🫶 All the local deadlines in the stack are later than or equal to the current time (which every router agrees on) ⭐ And the times closer to the ToS are always earlier than or equal to the times closer to the MPLS BoS. Very ordered, very slay 💖

The ingress router is the one that inserts the deadline stack into the packet headers, and no other router needs to know the requirements of the time-bound flows 🌈 So admitting a new flow only means updating the ingress router's information base. Easy peasy 🍓

MPLS LSRs that expose the ToS label can also inspect the associated deadline carried in the packet, whether it's in the MPLS stack as in-stack data or after the BoS as post-stack data 🔍

Acknowledgements

The authors gratefully acknowledge the input of the members of the MPLS Open Design Team 🫶 They also sincerely thank Loa Andersson, Xiao Min, Jie Dong, and Yaron Sheffer for their thoughtful suggestions and help in making the document better. Main character supporting cast energy 🌟

Contributors

Loa Anderssen Bronze Dragon Consulting Email: loa@pi.nu

Authors' Addresses

Tarek Saad Cisco Systems, Inc. Email: tsaad.net@gmail.com

Kiran Makhijani Independent Email: kiran.ietf@gmail.com

Haoyu Song Futurewei Technologies Email: haoyu.song@futurewei.com

Greg Mirsky Ericsson Email: gregimirsky@gmail.com 💜

📦 where this page comes from