RFC 9789

MPLS Network Actions (MNAs) Framework

📅 published July 2025, from ietf

RFC 9789: MPLS Network Actions (MNAs) Framework 🎀

okay bestie, we are diving into RFC 9789 and I am so ready 💅✨ It's an IETF document from July 2025 about the MPLS Network Actions framework. Here's the lowdown so you can keep up!

  • RFC number: 9789
  • Title: MPLS Network Actions (MNAs) Framework
  • Category: Informational 📚 (so not a Standards Track spec, it's published "for informational purposes")
  • Date: July 2025
  • ISSN: 2070-1721
  • Authors: L. Andersson (Huawei Technologies), S. Bryant (University of Surrey 5GIC), M. Bocci (Nokia), and T. Li (Juniper Networks) 🫶
  • Obsoletes / Updates: The original title block doesn't list any, so there's nothing it obsoletes or updates 🙈

The IETF is the group that makes the Internet's protocols, and this doc is a whole main character moment for MPLS 🦋

Abstract

This document describes an architectural framework for MPLS Network Action (MNA) technologies. MNA technologies are used to indicate actions that impact the forwarding or other processing (such as monitoring) of the packet along the Label Switched Path (LSP) of the packet and to transfer any additional data needed for these actions.

This document provides the foundation for the development of a common set of network actions and information elements supporting additional operational models and capabilities of MPLS networks. 🌸

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9789.

Copyright (c) 2025 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
  1.1.  Requirements Language
  1.2.  Normative Definitions
  1.3.  Abbreviations
2.  Structure
  2.1.  Scopes
  2.2.  Partial Processing
  2.3.  Signaling
    2.3.1.  Readable Label Depth
  2.4.  State
3.  Encoding
  3.1.  The MNA Label
    3.1.1.  Existing Base SPL
    3.1.2.  New Base SPL
    3.1.3.  New Extended SPL
    3.1.4.  User-Defined Label
  3.2.  TC and TTL
    3.2.1.  TC and TTL Retained
    3.2.2.  TC and TTL Repurposed
  3.3.  Length of the NAS
    3.3.1.  Last/Continuation Bits
    3.3.2.  Length Field
  3.4.  Encoding of Scopes
  3.5.  Encoding a Network Action
    3.5.1.  Bit Catalogs
    3.5.2.  Operation Codes
  3.6.  Encoding of Post-Stack Data
    3.6.1.  First Nibble Considerations
4.  Semantics
5.  Definition of a Network Action
6.  Management Considerations
7.  Security Considerations
8.  IANA Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌈

This document describes an architectural framework for MPLS Network Action (MNA) technologies. MNA technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions.

This document provides the foundation for the development of a common set of network actions and information elements supporting additional operational models and capabilities of MPLS networks. MNA solutions derived from this framework are intended to address the requirements found in [RFC9613]. In addition, MNA may support actions that overlap existing MPLS functionality. This may be beneficial for numerous reasons, such as making it more efficient to combine existing functionality and new functions in the same MPLS packet.

MPLS forwarding actions are instructions to MPLS routers to apply additional actions when forwarding a packet. These might include load-balancing a packet given its entropy, indicating whether or not to perform Fast Reroute on a failure, and indicating whether or not a packet has metadata relevant to the forwarding actions along the path.

This document generalizes the concept of MPLS "forwarding actions" to "network actions" that include any action that an MPLS router is requested to take on the packet. Network actions include any MPLS forwarding actions but may also include other operations (such as security functions, Operations, Administration, and Maintenance (OAM) procedures, etc.) that are not directly related to forwarding of the packet. MPLS network actions are always triggered by an MNA packet but may have implications for subsequent traffic, including non-MNA packets, as discussed in Section 2.4.

MNA technologies may redefine the semantics of the Label, Traffic Class (TC), and Time to Live (TTL) fields in an MPLS Label Stack Entry (LSE) within a Network Action Sub-Stack (NAS).

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

Although this is an Informational document, these conventions are applied to achieve clarity in the requirements that are presented.

1.2. Normative Definitions

This document adopts the definitions of the following terms and abbreviations from [RFC9613] as normative: "Network Action", "Network Action Indicator (NAI)", "Ancillary Data (AD)", and "Scope".

In addition, this document defines the following terms:

  • Network Action Sub-Stack (NAS): A set of related, contiguous LSEs in the MPLS label stack for carrying information related to network actions. The Label, TC, and TTL values in the LSEs in the NAS may be redefined, but the meaning of the S bit is unchanged.
  • Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS, which contains a special-purpose label that indicates the start of the NAS.

1.3. Abbreviations

+==============+=====================+===========================+
| Abbreviation | Meaning             | Reference                 |
+==============+=====================+===========================+
| AD           | Ancillary Data      | [RFC9613]                 |
+--------------+---------------------+---------------------------+
| BIER         | Bit Index Explicit  | [RFC8279]                 |
|              | Replication         |                           |
+--------------+---------------------+---------------------------+
| BoS          | Bottom of Stack     | [RFC6790]                 |
+--------------+---------------------+---------------------------+
| bSPL         | Base Special-       | [RFC9017]                 |
|              | Purpose Label       |                           |
+--------------+---------------------+---------------------------+
| ECMP         | Equal-Cost          | [RFC9522]                 |
|              | Multipath           |                           |
+--------------+---------------------+---------------------------+
| EL           | Entropy Label       | [RFC6790]                 |
+--------------+---------------------+---------------------------+
| ERLD         | Entropy Readable    | [RFC8662]                 |
|              | Label Depth         |                           |
+--------------+---------------------+---------------------------+
| eSPL         | Extended Special-   | [RFC9017]                 |
|              | Purpose Label       |                           |
+--------------+---------------------+---------------------------+
| HbH          | Hop by Hop          | In the MNA context, this  |
|              |                     | document.                 |
+--------------+---------------------+---------------------------+
| I2E          | Ingress to Egress   | In the MNA context, this  |
|              |                     | document.                 |
+--------------+---------------------+---------------------------+
| IGP          | Interior Gateway    |                           |
|              | Protocol            |                           |
+--------------+---------------------+---------------------------+
| ISD          | In-Stack Data       | [RFC9613]                 |
+--------------+---------------------+---------------------------+
| LSE          | Label Stack Entry   | [RFC3032]                 |
+--------------+---------------------+---------------------------+
| LSP          | Label Switched Path |                           |
+--------------+---------------------+---------------------------+
| MNA          | MPLS Network Action | [RFC9613]                 |
+--------------+---------------------+---------------------------+
| MSD          | Maximum SID Depth   | [RFC8491]                 |
+--------------+---------------------+---------------------------+
| NAI          | Network Action      | [RFC9613]                 |
|              | Indicator           |                           |
+--------------+---------------------+---------------------------+
| NAS          | Network Action Sub- | This document             |
|              | Stack               |                           |
+--------------+---------------------+---------------------------+
| NSI          | Network Action Sub- | This document             |
|              | Stack Indicator     |                           |
+--------------+---------------------+---------------------------+
| PSD          | Post-Stack Data     | [RFC9613] and Section 3.6 |
|              |                     | of this document          |
+--------------+---------------------+---------------------------+
| RLD          | Readable Label      | This document             |
|              | Depth               |                           |
+--------------+---------------------+---------------------------+
| SID          | Segment Identifier  | [RFC8402]                 |
+--------------+---------------------+---------------------------+
| SPL          | Special-Purpose     | [RFC9017]                 |
|              | Label               |                           |
+--------------+---------------------+---------------------------+
| TC           | Traffic Class       |                           |
+--------------+---------------------+---------------------------+
| TTL          | Time to Live        |                           |
+--------------+---------------------+---------------------------+

Table 1: Abbreviations

That's part 1 done, bestie! 🧚 Part 2 is coming up next with Section 2 (Structure) and all the good stuff about scopes and signaling 💜

2. Structure ✨

okay so bestie, this is the part where MNA gets its shape 🦋 An MNA solution tells you which network actions to apply to an MPLS packet 💅 Those actions, plus their ancillary data, can ride in sub-stacks inside the MPLS label stack and/or in post-stack data. And a solution MUST say where the network action sub-stacks sit in the label stack, whether and how often they get copied into the label stack, and how the sub-stack and post-stack data are encoded 🎀

Here's the vibe check 🌸 Ancillary data is probably going to be needed at lots of points along an LSP 😭 Copying it through the whole label stack would be wildly wasteful, and so would rewriting the entire label stack at every hop. So MNA lets you encode actions and ancillary data deeper in the stack, which means implementations have to look past the first LSE 👑 Going past the top-of-stack LSE first showed up with the Entropy Label (EL) [RFC6790] 🧚

A network action sub-stack has three pieces 💖

  • Network Action Sub-Stack Indicator (NSI): the first LSE in the NAS. It carries a special-purpose label called the MNA label, which says "a network action sub-stack starts here" 🫶
  • Network Action Indicators (NAIs): optional indicators that describe the set of network actions. If they aren't in the sub-stack, a solution could put them in post-stack data instead 💅 A network action counts as present if there's an indicator in the packet that invokes it ✨
  • In-Stack Data (ISD): zero or more LSEs carrying ancillary data for the network actions that are present. NAIs are NOT ancillary data, so don't mix them up 🙈

Each present network action can have zero or more LSEs of in-stack data 🍓 The order of those ISD LSEs matches the order of the NAIs. The document that defines a network action MUST specify how its in-stack data is encoded, if it has any 🌈 And in-stack data can be referenced by more than one network action 🦋

Here's an example of a label stack with an embedded NAS 💜

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |0|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |0|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |0|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Network Action Sub-Stack     |0|               |
   ~                                                               ~
   |         Network Action Sub-Stack continued  |0|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |0|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |1|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Payload                             |

Figure 1: A Label Stack with an Embedded Network Action Sub-Stack 📸

Some network actions can also say that data rides after the label stack 🧳 That's post-stack data. The document defining the network action MUST specify how its post-stack data is encoded, if any 💅 When several present network actions have post-stack data, the order of that data matches the order of the NAIs 🔥

Here's a packet with post-stack data: a label stack, then post-stack data, then the payload 🌸

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |0|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |1|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Post-Stack Data                         |
   ~                                                               ~
   |                  Post-Stack Data continued                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Payload                             |

Figure 2: A Label Stack Followed by Post-Stack Data 🎀

A solution MUST specify the order in which network actions are applied to the packet, so the actions have consistent semantics 👑 There are a LOT of possible orderings, especially with bit catalogs (Section 3.5.1), so the solution MUST provide an unambiguous specification 😵‍💫 What an action actually does depends on the packet contents, including any ancillary data, and on the state of the router 🧠

This document assumes that the MPLS WG will select a single solution for encoding ISD and not more than one solution for encoding PSD 🦋

2.1. Scopes 🌈

A network action might need to be handled by every node on the path, or just some of them 🛤️ The scopes an action can have include:

  • Hop by Hop (HbH): every node along the path performs the action 🔁
  • Ingress to Egress (I2E): only the last node on the path performs the action 🏁
  • Select: only specific nodes along the path perform the action 🎯

If a solution supports the select scope, it MUST describe how it specifies the set of nodes that perform the actions 💖

This framework puts NO constraints on the scope of, or the ancillary data for, a network action 🙌 Any network action can appear in any scope or combination of scopes, can have no ancillary data, and can need in-stack data and/or post-stack data. Some combinations might be suboptimal, but the framework doesn't restrict them 🤷‍♀️ A specific MNA solution MAY define such constraints 💅

2.2. Partial Processing 🧩

As described in [RFC3031], legacy devices that don't recognize the MNA label will discard the packet if the top label is the MNA label 🗑️

Devices that DO recognize the MNA label might not implement every present network action 😬 A solution MUST specify how unrecognized present network actions should be handled 📋

One option: an implementation SHOULD stop processing network actions when it hits an unrecognized one. Any later present network actions would NOT be applied 🛑 The result depends on the solution's order of operations 🔢

Another option: an implementation SHOULD drop any packet that contains any unrecognized present network action 🚮

A third option: an implementation SHOULD perform all recognized present network actions and ignore all unrecognized ones 🍬

Other options might also be possible 🌟 The solution SHOULD specify which option it adopts 💜

In some solutions, the packet or the action can indicate how the forwarder should proceed if it doesn't recognize the action 🧭 When an action has to be processed at every hop, it is RECOMMENDED to take care NOT to construct an LSP that traverses nodes that don't support that action 🚧 It's acknowledged that, in some circumstances, it might not be possible to build an LSP that avoids such nodes, like when a network is reconverging after a failure or when IP Fast Reroute (IPFRR) [RFC5714] is happening 🔄😭

2.3. Signaling 📣

A node that wants to use MNA and apply network actions to a packet MUST understand the nodes the packet will transit, whether or not those nodes support MNA, and the network actions to be invoked 🗺️ These capabilities are presumed to be signaled by protocols that are out of scope for this document, and are presumed to have per-network-action granularity 📡 If a solution requires alternate signaling, it MUST specify that explicitly 🫶

2.3.1. Readable Label Depth 📏

Readable Label Depth (RLD) is the number of LSEs, counting from the top of the stack, that a router can read in an incoming MPLS packet with no performance impact 👀 [RFC8662] introduced Entropy Readable Label Depth (ERLD) 🌸 Readable Label Depth is the same concept, just generalized, and isn't specifically tied to the Entropy Label (EL) or MNA 💖

ERLD isn't redundant with RLD, because ERLD is ZERO if a system doesn't support the Entropy Label 🙃 A system could reasonably support MNA or other MPLS functions and still need to advertise an RLD value without supporting the Entropy Label, so another advertised value is REQUIRED 🎯

A node that pushes a NAS onto the label stack is responsible for making sure every node expected to process the NAS has the entire NAS within its RLD 🧳 A node SHOULD use signaling (for example, the signaling described in [RFC9088] and [RFC9089]) to figure this out 📡 An exception might be when the node has out-of-band knowledge that all nodes along the path have no RLD limitations, so it can skip the extra overhead of signaling 🙌

Per [RFC8662], a node that doesn't support EL advertises a value of zero for its ERLD, so advertising ERLD alone doesn't cut it in every case 😤 A node MAY advertise both ERLD and RLD, and it SHOULD do so if its ERLD and RLD values differ 💅 Again, if a node has out-of-band knowledge that not all nodes have RLD limitations, signaling can be skipped ✨ If a node's ERLD and RLD values are the same, it MAY advertise only ERLD for efficiency reasons 🍓 If a node supports MNA but not EL, it SHOULD advertise RLD unless it has out-of-band knowledge that no nodes in the domain have RLD restrictions 🫧

RLD is advertised by an IGP MSD-Type value of 3, and it MAY be advertised as a Node MSD, a Link MSD, or both 📢

An MNA node MUST use the RLD determined by picking the first advertised non-zero value from the following, in order 🥇

  • The RLD advertised for the link
  • The RLD advertised for the node
  • The non-zero ERLD for the node

A node's RLD is a function of its hardware capabilities, and it is NOT expected to depend on the specifics of the MNA solution 🔧

2.4. State 🧠

A network action can affect the state stored in the network 🗄️ That means one packet can affect how subsequent packets get handled, and in particular, one packet may affect later packets in the same LSP 🎀

More to come in the next part, bestie 💅🌈

3. Encoding 🎀

okay bestie, so there are a bunch of ways people have proposed to encode NAIs 💅 this section basically gives us the tea on each option and what to think about with each one ✨

when network actions ride in the MPLS label stack, they're all represented as a set of LSEs called a Network Action Sub-Stack (NAS) 🦋 a NAS starts with a special-purpose label, and then optionally has LSEs that say which network actions to perform on the packet, plus the in-stack ancillary data for each action. different network actions can hang out together in one NAS or be split across different sub-stacks, your call 💖

[RFC9613] says a solution must not add unnecessary LSEs to the sub-stack (see requirement 9 in Section 3.1 of [RFC9613]) 😭 so solutions should also make efficient use of the bits in the sub-stack (except the S-bit), because wasting bits could lead to extra LSEs getting added. no wasted bits, periodt 🫶

3.1. The MNA Label 🌸

the first LSE in a network action sub-stack has a special-purpose label that says "hey, this is a network action sub-stack" 🧚 a solution has a few choices for that label ✨

3.1.1. Existing Base SPL 🍓

a solution may reuse an existing Base SPL (bSPL) 💅 if it does that, it MUST explain how the usage is backward compatible, including the case where there is ISD 👑

if an existing inactive bSPL gets picked and it won't be backward compatible, it MUST first be retired per [RFC7274] and then reallocated 💀 no skipping steps, bestie

3.1.2. New Base SPL 🦋

a solution may select a new bSPL ✨

3.1.3. New Extended SPL 💜

a solution may select a new Extended SPL (eSPL) 🎀 if it does, it MUST address the requirement for the minimal number of LSEs 🔥

3.1.4. User-Defined Label 🌈

a solution may let the network operator define the label that indicates the network action sub-stack 🫠 this creates management overhead for the operator, who has to coordinate the use of this label across all nodes on the path using management or signaling protocols 😩 the user-defined label could be network-wide or LSP-specific 💖 if a solution goes with a user-defined label, it SHOULD justify that overhead 🙈

3.2. TC and TTL 🌷

in the first LSE of the network action sub-stack, only the 20 bits of the Label value and the Bottom of Stack bit are used by the NSI 💅 the TC field (3 bits) and the TTL (8 bits) aren't used, which could leave 11 bits open for MNA purposes 🦋

3.2.1. TC and TTL Retained ✨

if the solution keeps the TC and TTL fields, then the first LSE of the network action sub-stack looks like what [RFC3032] describes 👑

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 3: A Label Stack Entry with TC and TTL Retained

Label: Label value, 20 bits TC: Traffic Class, 3 bits S: Bottom of Stack, 1 bit TTL: Time To Live, 8 bits

more LSEs would be needed to encode NAIs 🌸 if a solution keeps the TC and TTL fields, it MUST address the requirement for the minimal number of LSEs 💅

3.2.2. TC and TTL Repurposed 💖

if the solution reuses the TC and TTL fields, then the first LSE of the network action sub-stack looks like this 🧚

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Label                  |x x x|S|x x x x x x x x|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 4: A Label Stack Entry with TC and TTL Repurposed

Label: Label value, 20 bits x: Bit available for use in solution definition S: Bottom of Stack, 1 bit

the solution may use more LSEs to hold NAIs 🦋 if it does, it MUST address the requirement for the minimal number of LSEs ✨

3.3. Length of the NAS 🎀

a solution MUST have a mechanism (such as an indication of the length of the NAS) so an implementation can find the end of the NAS 🔥 this MUST be easily processed even by implementations that don't understand the full contents of the NAS 💅 two options are described below, but other solutions may be possible 🌈

3.3.1. Last/Continuation Bits 🫶

a solution may use a bit per LSE to indicate whether or not the NAS continues into the next LSE 💜 the bit may indicate continuation by being set or by being clear 🦋 the overhead is one bit per LSE, and the big win is that it can encode an arbitrarily sized NAS ✨ this approach is efficient if the NAS is small 🍓

3.3.2. Length Field 🌸

a solution may opt for a fixed-size Length field at a fixed location within the NAS 💖 the fixed size of the Length field may not be large enough to support all possible NAS contents 😬 this approach may be more efficient if the NAS is long, but not longer than the Length field can describe 🧚

one hardware designer recommends a Length field because it minimizes branching in the logic 🔥

3.4. Encoding of Scopes 💅

a solution may choose to explicitly encode the scope of each action in a network action sub-stack 🦋 for example, a NAS might contain Action A (HbH), Action B (HbH), and Action C (HbH) ✨ a solution may instead encode the scope implicitly, based on the actions present in the network action sub-stack 👑 for example, a NAS might contain the following actions with HbH scope: A, B, and C 🎀 this choice may have performance implications, since an implementation might have to parse the network actions in a sub-stack just to discover there's nothing for it to do 😩

here's an example 🌷 suppose a NAS is embedded in a label stack at a depth of six LSEs and the NAS contains three actions, each with Select scope 💖 those actions aren't applicable at the current node and should be ignored 🙈 if the scope is encoded explicitly with each action, then an implementation MUST parse each action 😭 but if the scope is encoded as part of the NAS, then an implementation only needs to parse the start of the NAS and not the individual actions 🫶

solutions need to think about the order of scoped NAIs and their associated AD within individual sub-stacks, and the order of per-scope sub-stacks 🧚 that way network actions and the AD can be found easily and aren't processed by nodes that don't need to handle them ✨

3.5. Encoding a Network Action 🌈

two options for encoding NAIs are described below, but other solutions may be possible 💅 any solution SHOULD allow the encoding of an arbitrary number of NAIs 💖

3.5.1. Bit Catalogs 🦋

a solution may opt to encode the set of network actions as a list of bits, sometimes called a catalog 🍓 the solution MUST provide a mechanism to determine how many LSEs are devoted to the catalog when the NAIs are carried in-stack 🔥 a set bit in the catalog indicates that the corresponding network action is present 🎀

catalogs are efficient if the number of present network actions is relatively high and the necessary catalog is small 💜 for example, if the first 16 actions are all present, a catalog can encode this in 16 bits ✨ but if the number of possible actions is large, a catalog can get inefficient 😩 selecting only one action, the 256th action, would require a catalog of 256 bits, which would need more than one LSE when the NAIs are carried in-stack 💀

a solution may include a bit-remapping mechanism so a given domain can optimize for its commonly used actions 🌸

3.5.2. Operation Codes 🧚

a solution may opt to encode the set of present network actions as a list of operation codes (opcodes) 💅 each opcode is a fixed number of bits 🦋 the size of the opcode bounds the number of network actions the solution can support 👑

opcodes are efficient if there are only one or two active network actions 💖 for example, if an opcode is 8 bits, then two active network actions could be encoded in 16 bits ✨ but if 16 actions are required, opcodes would consume 128 bits 😭 opcodes are efficient at encoding a large number of possible actions 🌈 if only the 256th action is selected, that still requires 8 bits 🫶

3.6. Encoding of Post-Stack Data 🎀

a solution may carry NAI and AD as PSD 🌷 for ease of parsing, all AD SHOULD be co-located with its NAI 💜

if there are multiple instances of post-stack data, they SHOULD occur in the same order as their relevant network action sub-stacks, and then in the same order as their relevant network actions occur within the network action sub-stacks 💖

3.6.1. First Nibble Considerations 🧚

the first nibble after the label stack has been used to convey information in certain cases [RFC4385] ✨ a consolidated view of the uses of the first nibble is provided in [RFC9790] 💅

for example, in [RFC4928], this nibble is checked to see if it has the value "4" or "6" 🦋 if it doesn't, the packet payload is assumed not to be IPv4 or IPv6, and Equal-Cost Multipath (ECMP) is not performed 🌸

it should be noted that this is an inexact method 🙈 for example, an Ethernet pseudowire without a control word might have "4" or "6" in the first nibble and will therefore be subject to ECMP forwarding 😬

nevertheless, the method is implemented and deployed 💖 it is used today and will be for the foreseeable future 👑

the use of the first nibble for Bit Index Explicit Replication (BIER) is specified in [RFC8296] 🌈 BIER sets the first nibble to 5 🎀 the same is true for a BIER payload as for any use of the first nibble: it isn't possible to conclude that the payload is BIER even if the first nibble is set to 5, because an Ethernet pseudowire without a control word might begin with a 5 😭 however, the BIER approach meets the design goal of [RFC8296] to determine that the payload is IPv4, IPv6, or a packet with a header that includes a pseudowire control word 🫶

[RFC4385] allocates 0b0000 for the pseudowire control word and 0b0001 as the control word for the pseudowire Associated Channel Header (ACH) 🧚

a PSD solution SHOULD specify the contents of the first nibble, the actions to be taken for each value, and the interaction with post-stack data used concurrently by other MPLS applications 💅

4. Semantics 👑

for MNA to be consistent across implementations and predictable in operational environments, its semantics need to be entirely predictable 🔥 an MNA solution MUST specify a deterministic order for processing each of the network actions in a packet 💖 each network action MUST specify how it interacts with all other previously defined network actions 🦋 private network actions are network actions that are not publicly documented 🌸 private network actions MUST be included in the ordering of network actions, but the interactions of private actions with other actions are outside the scope of this document 🙈✨

5. Definition of a Network Action 📝✨

okay bestie, this is the checklist for writing up a brand new network action 💅 a document defining one must contain the following:

  • Name: the name of the network action 🏷️
  • Network Action Indicator: the bit position or opcode that shows the network action is active 🚦
  • Scope: a description of which nodes should perform the network action, as described in Section 2.1 🎯
  • State: whether the network action can modify state in the network and, if so, which state that may be and what the side effects are 🌀
  • Required/Optional: whether a node is required to perform the network action 🫶
  • In-Stack Data: the number of LSEs of in-stack data, if there is any, and how that in-stack data is encoded 🧚. If the in-stack data is variable length, the solution must spell out how an implementation can work out the length without implementing the network action 👀
  • Post-Stack Data: how post-stack data is encoded, if there is any 🎀. If it's variable length, the solution must spell out how an implementation can work out the length without implementing the network action 💀

A solution should create an IANA registry for network actions 📚✨

6. Management Considerations 🧑‍💻

network operators are gonna need to be cognizant of which network actions are supported by which nodes, and they'll need to make sure that gets signaled 📡. some solutions might need network-wide configuration so the labels that mark the start of a NAS stay in sync 🔄. solution documents must clearly state what management considerations apply to the solutions they describe 📝. and they must describe mechanisms for doing network diagnostics when MNAs are around 🔍 no skipping this part, periodt 💅

7. Security Considerations 🔐😭

okay this section is SERIOUS, so buckle up 🎢. there's an analysis of MPLS security in [RFC5920], which also points out that the MPLS forwarding plane has no built-in security mechanisms 🫣

operational security is central to keeping MPLS networks safe, and honestly operators are already super experienced with this 🛡️. deploying link-level security (for example [MACsec]) stops someone watching link traffic from quietly grabbing the label stack to attack with 🕵️‍♀️. this matters a lot for a network deploying MNA, because the MNA information might be sensitive 🚨. so the confidentiality and authentication you get from link-level security is especially useful here 💜

some extra proposals to add encryption to the MPLS forwarding plane have been floated in [MPLS-OPP-SEC], but no mechanisms had been agreed on when this document was published 🙃. [MPLS-OPP-SEC] offers hop-by-hop security that encrypts the label stack, and it's functionally equivalent to what [MACsec] provides 🔒. it can also do end-to-end encryption of the MPLS payload, but then there's no cryptographic integrity protection of the MPLS label stack 😬

be extra careful when you add any end-to-end security mechanism if your in-stack MNA solution needs on-path modification of the MNA data, or if post-stack MNA data has to be examined on-path 🧐. this is a whole thing, bestie 🫠

a cornerstone of MPLS security is protecting the network from processing MPLS labels that came from outside the network 🏰✨

operators have lots of experience keeping MPLS-encoded packets out at network boundaries 🚧. for example, they exclude all MPLS packets, and all packets revealed to be carrying an MPLS packet as the payload of IP tunnels. when packets get accepted into an MPLS network from an untrusted third party, non-MPLS packets are immediately encapsulated in an MPLS label stack that the MPLS network operator specifies, and MPLS packets get additional label stack entries imported as the operator specifies. so it's really hard for an attacker to sneak an MPLS-encoded packet into a network or give the network forwarding system any instructions 🙅‍♀️💅

inside a single well-managed domain, an adjacent domain can be considered trusted, as long as it's sufficiently shielded from third-party traffic ingress and third-party traffic observation 🧱. in that setup, MNA doesn't introduce any new security vulnerabilities 🎉

⚠️ watch out for inter-domain setups, including carrier's carrier. there, a first network's MPLS traffic is encapsulated directly over a second MPLS network by simply pushing additional MPLS LSEs. the contents of the first network's payload and label stack may be visible to the forwarders in the second network. historically this has been benign, and honestly useful for ECMP 🌈. but if the first network's traffic carries MNA information, that info could get exposed to MNA-capable forwarders. that could cause unpredictable behavior, or modification of the customer MPLS label stack or MPLS payload 😱. this is an increased vulnerability that MNA introduces, and it SHOULD be addressed in any MNA solution 🚨

operators have several mitigations available to them 🛠️:

  • a. reject all incoming packets containing MNA information that don't come from a trusted network. it may be acceptable to accept and process MNA information from a trusted network, though 🤷‍♀️
  • b. fully encapsulate the inbound packet in a new additional MPLS label stack, so the forwarder finds a Bottom of Stack (BoS) bit imposed by the carrier network and only finds MNA information added by the carrier network 🎀

a mitigation the authors reject as unsafe: having the ingress Label Switching Router (LSR) push enough additional labels so that any MNA information received in packets entering from a third-party network is made inaccessible by being below the RLD ❌. this is unsafe with an overly conservative RLD value, and it can end with third-party MNA information becoming visible to, and acted on by, an MNA forwarder in the carrier network 😭

8. IANA Considerations 🦋

IANA has allocated the following code point in the "IGP MSD-Types" registry [MSD] within the "Interior Gateway Protocol (IGP) Parameters" registry group 📋✨

      +=======+======================+============+===========+
      | Value | Name                 | Data Plane | Reference |
      +=======+======================+============+===========+
      | 3     | Readable Label Depth | MPLS       | RFC 9789  |
      +-------+----------------------+------------+-----------+

                         Table 2: New IGP MSD-Type

9. References 📚🎀

9.1. Normative References 💖

9.2. Informative References 📚

okay bestie, these are the "for more reading" sources, the ones the spec points to but doesn't depend on to work 🤓 I'm keeping every single entry word for word so nothing gets lost 💅

[MACsec]   IEEE, "IEEE Standard for Local and metropolitan area
           networks-Media Access Control (MAC) Security", IEEE Std
           802.1AE-2018, DOI 10.1109/ieeestd.2018.8585421, 26
           December 2018,
           <https://ieeexplore.ieee.org/document/8585421>.

[MPLS-OPP-SEC]
           Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
           Networks", Work in Progress, Internet-Draft, draft-ietf-
           mpls-opportunistic-encrypt-03, 28 March 2017,
           <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
           opportunistic-encrypt-03>.

[MSD]      IANA, "IGP MSD-Types",
           <https://www.iana.org/assignments/igp-parameters/>.

[RFC4928]  Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
           Cost Multipath Treatment in MPLS Networks", BCP 128,
           RFC 4928, DOI 10.17487/RFC4928, June 2007,
           <https://www.rfc-editor.org/info/rfc4928>.

[RFC5714]  Shand, M. and S. Bryant, "IP Fast Reroute Framework",
           RFC 5714, DOI 10.17487/RFC5714, January 2010,
           <https://www.rfc-editor.org/info/rfc5714>.

[RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
           L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
           RFC 6790, DOI 10.17487/RFC6790, November 2012,
           <https://www.rfc-editor.org/info/rfc6790>.

[RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
           Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
           Explicit Replication (BIER)", RFC 8279,
           DOI 10.17487/RFC8279, November 2017,
           <https://www.rfc-editor.org/info/rfc8279>.

[RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
           Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
           for Bit Index Explicit Replication (BIER) in MPLS and Non-
           MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
           2018, <https://www.rfc-editor.org/info/rfc8296>.

[RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
           Decraene, B., Litkowski, S., and R. Shakir, "Segment
           Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
           July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8491]  Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
           "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
           DOI 10.17487/RFC8491, November 2018,
           <https://www.rfc-editor.org/info/rfc8491>.

[RFC8662]  Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
           Shakir, R., and J. Tantsura, "Entropy Label for Source
           Packet Routing in Networking (SPRING) Tunnels", RFC 8662,
           DOI 10.17487/RFC8662, December 2019,
           <https://www.rfc-editor.org/info/rfc8662>.

[RFC9088]  Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
           and M. Bocci, "Signaling Entropy Label Capability and
           Entropy Readable Label Depth Using IS-IS", RFC 9088,
           DOI 10.17487/RFC9088, August 2021,
           <https://www.rfc-editor.org/info/rfc9088>.

[RFC9089]  Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
           and M. Bocci, "Signaling Entropy Label Capability and
           Entropy Readable Label Depth Using OSPF", RFC 9089,
           DOI 10.17487/RFC9089, August 2021,
           <https://www.rfc-editor.org/info/rfc9089>.

[RFC9522]  Farrel, A., Ed., "Overview and Principles of Internet
           Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
           January 2024, <https://www.rfc-editor.org/info/rfc9522>.

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

Acknowledgements 🫶

this whole doc came out of work kicked off by the MPLS Open Design Team 🌈 and it had people from the MPLS, PALS, and DETNET Working Groups all hyping it up together, which is so iconic ✨

the authors want to big-up Adrian Farrel for his contributions 👑 they also thank John Drake, Toerless Eckert, and Jie Dong for their comments 💜

Authors' Addresses 💌

here are the people who wrote it, with where they work and how to reach them 🦋

Loa Andersson
Huawei Technologies
Email: loa@pi.nu


Stewart Bryant
University of Surrey 5GIC
Email: sb@stewartbryant.com


Matthew Bocci
Nokia
Email: matthew.bocci@nokia.com


Tony Li
Juniper Networks
Email: tony.li@tony.li
📦 where this page comes from