RFC 9613

Requirements for Solutions that Support MPLS Network Actions (MNAs)

📅 published August 2024, from ietf

RFC 9613: Requirements for Solutions that Support MPLS Network Actions (MNAs) 🦋

Okay bestie, let's get the vitals first 💅. This is RFC 9613, published in August 2024 as an Informational document, so it's published for information and isn't a Standards Track spec 🎀. It was written by M. Bocci (editor) from Nokia, S. Bryant from the University of Surrey ICS, and J. Drake, who's independent 🌸. Its ISSN is 2070-1721. It doesn't list any RFCs that it obsoletes or updates ✨.

Abstract

Heyy so this doc lays out the requirements for building MPLS Network Actions (MNAs), which are the things that change how MPLS packets get forwarded or processed 🔥. The ideas came from a bunch of proposals to add extra info to the labeled packet, so that a transit router or a terminating LSR (aka the Label Edge Router, or LER) can actually do these actions 💖.

Status of This Memo

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

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🙈.

For the latest status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9613 ✨.

Copyright (c) 2024 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 document 👑. Any Code Components pulled out of this document 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 describes 🫶.

Table of Contents

1.  Introduction
  1.1.  Terminology
2.  Requirements Language
3.  MPLS Network Action Requirements
  3.1.  General Requirements
  3.2.  Requirements on the MNA Alert Mechanism
  3.3.  Requirements on Network Actions
  3.4.  Requirements on Network Action Indicators
  3.5.  Requirements on Ancillary Data
4.  IANA Considerations
5.  Security Considerations
6.  Acknowledgements
7.  References
  7.1.  Normative References
  7.2.  Informative References
Authors' Addresses

1. Introduction

Okay so MPLS wants to level up its data plane to handle new use cases [MNA-USECASES] 🦋. The big idea is a general mechanism called MPLS Network Actions (MNAs). It lets the network make a forwarding or processing decision using info other than the top label and the Traffic Class (TC) bits. It can also use the Network Action Indicator (NAI) and ancillary data (MNA information) ✨. To support all of this, we need extensions to the MPLS architecture and label-stack operations that work across every use case. The goal is less implementation complexity and better interoperability and extensibility 💅. Any protocol extensions also have to fit the existing MPLS architecture from [RFC3031], [RFC3032], and [RFC6790] 🎀.

Here's the thing to remember 👀: the MPLS architecture in [RFC3031] lets packets get forwarded through a network without intermediate nodes (Label Switching Routers, or LSRs) having to look at the network layer header of the payload. Formally, inspection can only happen at network ingress (the Label Edge Router, or LER), where the packet gets assigned to a Forwarding Equivalence Class (FEC) 🌸.

This doc sets the requirements for solutions that encode MNAs and the ancillary data needed to process those actions 🧚. The requirements come from a bunch of proposals to add info to the labeled packet so these actions can happen at either a transit or terminating LSR. We expect two kinds of solution specifications to come out of this 💖:

  • MNA solution specification: A spec that describes a common protocol supporting all forms of MNAs.
  • Network Action solution specifications: One or more specs describing the protocol extensions for the MNA solution, each one addressing a use case.

On its own, the term "solutions" refers to both MNA and Network Action solutions 🫶. The requirements are there to constrain the MNA solution design so implementations can interoperate 👑.

1.1. Terminology

  • Network Action (NA): An operation to be performed on an MPLS packet, or as a consequence of an MPLS packet being processed by a router. An NA may affect router state or MPLS packet forwarding, or it may affect the MPLS packet in some other way 💜.
  • Network Action Indicator (NAI): An indication in the MPLS packet that a certain NA is supposed to be performed 🎀.
  • Ancillary Data (AD): Data in an MPLS packet that's tied to a given NA. It can be used as input to process the NA, or it can be the result of processing the NA. Ancillary data may be associated with:
    • Both the control or maintenance information and the data traffic carried by the Label Switched Path (LSP).
    • Only the control or maintenance information.
    • Only the data traffic carried by the LSP.
  • In-Stack Data: Ancillary data carried within the MPLS label stack 🌈.
  • Post-Stack Data: Ancillary data carried in an MPLS packet between the bottom of the MPLS label stack and the first octet of the user payload. This doc doesn't prescribe whether post-stack data comes before or after any other post-stack header, such as a Control Word or Associated Channel Header (ACH) 🦋.
  • Scope: The set of nodes that should perform a given action ✨.

2. Requirements Language

Okay, the BCP 14 part 💅. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like this 🔥.

Even though this doc isn't a protocol spec, we're using this convention anyway so the requirements are clear to read 🌸.

3. MPLS Network Action Requirements

This section sets the requirements for MNAs and the tech that supports them in MPLS. That includes NAIs, the associated AD, and the alert mechanism that tells an LSR the NAIs are in an MPLS packet 💖.

The requirements describe how the protocol mechanisms and procedures behave. They're the building blocks you put together to make the indicators for an NA and its ancillary data. They don't spell out the detailed actions and processing an LSR or LER does for any NA or ancillary data 🧚.

How big the post-stack ancillary data is end to end in an MPLS packet is something the ingress and egress provider edges (PEs) agree on, so it isn't part of these requirements 🎀. Since in-stack ancillary data and per-hop post-stack data have to be parsed and processed by transit LSRs along the Label Switched Path (LSP), the size requirements for that data are written out in the sections below 👑.

3.1. General Requirements

  1. Okay rule number one 💅: any solutions MUST keep the extensibility, flexibility, and efficiency that come from splitting the control plane context from the simple data plane in MPLS, and the specification SHOULD explain how that's achieved.
  2. Any solutions to these requirements MUST be based on the MPLS architecture [RFC3031] [RFC3032] [RFC5331] and MUST NOT restrict its generality 🦋.
  3. If the MPLS data plane needs extensions, they MUST stay consistent with the MPLS architecture [RFC3031] [RFC3032] [RFC5331] ✨.
  4. Solutions that meet these requirements MUST be able to coexist with existing MPLS mechanisms 🌸.
  5. Within these constraints, a Network Action solution MAY carry MNA information in-stack, post-stack, or in both places 🧚.
  6. Solution specifications MUST NOT require an implementation to support in-stack ancillary data, unless that implementation chooses to support an NA that uses in-stack ancillary data 💜.
  7. Solution specifications MUST NOT require an implementation to support post-stack ancillary data, unless that implementation chooses to support an NA that uses post-stack ancillary data 🎀.
  8. The design of any MNA solution MUST minimize the processing needed to parse the label stack at an LSR 🔥.
  9. Solutions MUST minimize any additions to the size of the MPLS label stack 💖.
  10. Solution specifications that increase the size of the MPLS label stack in a way the ingress LER doesn't control MUST discuss the consequences 👀.
  11. Solution specifications MUST discuss the ECMP consequences of the design 🌈.
  12. A Network Action solution MUST NOT expose information to the LSRs that isn't already exposed to the LER 🫶.
  13. The design of any NA MUST NOT expose any information that a user of any service using the LSP considers confidential [RFC6973] [RFC3552] 🔒.
  14. Solution specifications MUST document any new security considerations they introduce ⭐.
  15. An MNA solution MUST allow MPLS packets carrying NAI and ancillary data (where it exists) to coexist on the same LSP with MPLS packets that don't carry this info 🦋.

3.2. Requirements on the MNA Alert Mechanism

  1. An MNA solution specification MUST define how a node figures out whether NAIs are present in the MPLS packet ✨.
  2. Special Purpose Labels (SPLs) are a mechanism of last resort 🙈. So an MNA solution specification that defines their use MUST minimize the number of new SPLs that get allocated 💅.

3.3. Requirements on Network Actions

  1. It is RECOMMENDED that an MNA solution include support for NAs for Private Use (see Section 4.1 of [RFC8126]) 🌸.
  2. Network Action solution specifications MUST define whether the NA needs to be processed as part of the immediate forwarding operation, and whether MPLS packet misordering is allowed to happen because of the time it takes to process the NA 🧚.
  3. If a Network Action solution specification allows more than one scope for an NA, it MUST define a mechanism to indicate the precedence of the scopes or any combination of the scopes 👑.
  4. If a network action needs an NAI with in-stack ancillary data that has to be imposed at an LSR on an LSP, then the Network Action solution MUST specify how this is achieved in all circumstances 🔥.
  5. If a network action needs an NAI with post-stack ancillary data imposed at an LSR on an LSP, then the Network Action solution specification MUST describe how this is achieved in all circumstances 💖.

3.4. Requirements on Network Action Indicators 🎀

  1. Okay so inserting, parsing, processing, and disposing of NAIs SHOULD make use of existing MPLS data plane operations. No reinventing the wheel, bestie 🧚
  2. Without constraining the mechanism, an MNA solution MUST enable a node inserting or modifying NAIs to determine if the target of the NAI, or any other LSR that may expose the NAI, can accept and process an MPLS packet containing the NAI. Like, you need to be able to check before you send 👀
  3. An NAI MUST NOT be imposed for delivery to a node unless it is known that the node supports processing the NAI. Never send a surprise to a node that can't handle it 🙅‍♀️
  4. The NAI design MUST support setting the scope of network actions. 💅
  5. A given Network Action solution specification MUST define which scope or scopes are applicable to the associated NAI. Scope has to be spelled out, no vibes-only guessing 🔍
  6. An MNA solution specification SHOULD define the support of NAIs for both Point-to-Point (P2P) and Point-to-Multipoint (P2MP) paths. The Network Action solution specification MAY limit a specific NAI to only one of these path types, but only if there is a clear reason to do so ✨
  7. An MNA solution specification defining data plane mechanisms for NAIs MUST be consistent across different control plane protocols. Consistency is everything, periodt 💜
  8. An MNA solution MUST allow the deployed MPLS control and management planes to determine the ability of downstream LSRs to accept and/or process a given NAI. 🧠
  9. An MNA solution MUST allow indicators for multiple network actions in the same MPLS packet. Multitasking queen 👑
  10. An MNA solution specification MUST NOT require an implementation to process all NAIs present in an MPLS packet. You don't have to process everything, and that's totally valid 🌸
  11. NAIs MUST only be inserted at LSRs that push a label onto the stack, but they can be processed by LSRs along the path of the LSP. Two examples of LSRs that push a label onto the stack are head-end LSRs and points of local repair (PLRs). So the head-end and the PLRs are the ones doing the inserting 🦋
  12. If a network action requires in-stack ancillary data, the NAI that indicates this network action MUST be present in the label stack. No NAI, no in-stack ancillary data, that's the deal 💖
  13. All NAIs MUST be encoded in a manner consistent with [RFC3031]. 📝
  14. If there is post-stack ancillary data for an NAI that is present in the label stack, it MUST be possible to infer the presence of the ancillary data without having to parse below the bottom of the label stack. Nobody should have to dig past the bottom of the stack just to find out it's there 🙈
  15. Any processing that removes an NAI from the label stack MUST also remove all associated ancillary data from the MPLS packet, unless the ancillary data is required by any remaining NAIs. Clean up after yourself, but don't delete what someone else still needs 🧹
  16. MNA solution specifications MUST request that IANA create registries and make allocations from those registries for NAIs as necessary to ensure unambiguous identification of standardized network actions. An MNA solution specification MAY request that IANA reserve a range of a registry for Private Use. Unambiguous names only, no confusion allowed 📚
  17. A Network Action solution specification MUST state where the NAIs are to be placed in the MPLS packet, that is, whether they are placed in-stack or post-stack. Location, location, location 📍

3.5. Requirements on Ancillary Data 🌈

  1. Network Action solution specifications MUST state whether ancillary data is required to fulfill the action, and whether it is in-stack and/or post-stack. Spill the tea on what ancillary data is needed and where it lives 🫖
  2. Network Action solution specifications MUST state if in-stack or post-stack ancillary data that is already present in the MPLS packet MAY be rewritten by an LSR. Be clear about whether anyone's allowed to rewrite it 💅
  3. Solutions for in-stack ancillary data MUST be able to coexist with and MUST NOT obsolete existing MPLS mechanisms. Such solutions MUST be described in a Standards Track RFC. Respect the OG mechanisms and document it properly 👑
  4. Network Action solutions MUST take care to limit the quantity of in-stack ancillary data to the minimum amount required. Less is more in the label stack, fr fr 🪶
  5. A Network Action solution SHOULD NOT use post-stack ancillary data unless the size of that ancillary data could prevent the coexistence of the network action with other in-use MPLS network functions if it were inserted into the label stack. Only go post-stack when the in-stack option would actually cause a clash 🧚
  6. The structure of the NAI and any associated ancillary data MUST enable skipping of unknown NAIs and any associated AD. If you don't know an NAI, you can skip it along with its AD, no drama 🦋
  7. Any MNA solution specification MUST describe whether the solution can coexist with existing post-stack data mechanisms (e.g., control words and the Generic Associated Channel Header [RFC5586]), and if so, how coexistence operates. Show me how you play nice with the existing post-stack crew 💜
  8. An MNA solution MUST allow an LER that inserts ancillary data to determine whether each node that needs to process the ancillary data can read the required distance into the MPLS packet at that node (compare with the mechanism in [RFC9088]). The inserting LER has to know if each node can actually reach the data it needs 🔭
  9. For scoped in-stack or post-stack ancillary data, any MNA solution MUST allow an LER inserting NAIs whose network actions make use of that ancillary data to determine if the NAI and ancillary data will be processed by LSRs within the scope along the path. Such a solution may need to determine if LSRs along the path can process a specific type of AD implied by the NAI at the depth in the stack that it will be presented to the LSR. Checking the whole route, depth and all, is giving thorough 🗺️
  10. A mechanism MUST exist to notify an egress LER of the presence of ancillary data so that it can dispose of it appropriately. The egress LER needs a heads-up so it can clean up 🧹
  11. In-stack ancillary data MUST only be inserted in conjunction with an operation conforming with [RFC3031]. ✨
  12. Post-stack ancillary data MUST only be inserted in conjunction with an operation conforming with [RFC3031]. ✨
  13. Processing of ancillary data below a swapped label MAY include rewriting the ancillary data. Swap it and maybe rewrite it, the choice is yours 🔄
  14. If a Network Action solution needs to change the size of the ancillary data, its specification MUST analyze the implications on MPLS packet forwarding and specify how these are addressed. Changing the size is a big deal, so you gotta explain the forwarding fallout 💀
  15. Not more than one Standards Track solution specification SHOULD be defined for encoding in-stack ancillary data. One clear winner, not a pile-up 🏆
  16. Not more than one Standards Track solution specification SHOULD be defined for encoding post-stack ancillary data. Same energy for the post-stack side 🫶

4. IANA Considerations 📋

This document has no IANA actions. Nothing to register here, bestie 🌸

5. Security Considerations 🔐

Okay, this part is serious, so listen up 👀 Solutions designed according to the requirements in this document may introduce new security considerations to MPLS, whose forwarding plane on its own does not provide any built-in security mechanisms [RFC5920].

In particular, such solutions may embed information derived from the MPLS payload in the MPLS headers. This may expose data that a user of the MPLS-based service might otherwise assume is opaque to the MPLS network. Furthermore, an LSR may insert information into the labeled packet such that the forwarding behavior is no longer purely a function of the top label or another label with forwarding context. Instead, the forwarding behavior may be the result of a more complex heuristic. This creates an implicit trust relationship between the LSR whose forwarding behavior is being changed and the upstream LSR inserting the data causing that change. Trust issues are literally the whole vibe here 😭

Several requirements above address some of these considerations. The MNA framework [MNA-FRAMEWORK] also provides security considerations resulting from any extensions to the MPLS architecture, and these SHOULD be taken together with the security considerations herein. Read the framework's security notes alongside these ones, no skipping!

Individual solution specifications meeting the requirements in this document MUST address any security considerations introduced by the MNA design. Every solution has to own its own security story 🔥

6. Acknowledgements 🫶

The authors gratefully acknowledge the contributions from Joel Halpern, Greg Mirsky, Yingzhen Qu, Haoyu Song, Tarek Saad, Loa Andersson, Tony Li, Adrian Farrel, Jie Dong, Bruno Decraene, and participants in the MPLS Working Group who have provided comments. Thank you all, you're the real MVPs 💖

The authors also gratefully acknowledge the input of the members of the MPLS Open Design Team. Big thanks to the design team too ✨

7. References 📚

7.1. Normative References

7.2. Informative References

Authors' Addresses ✨

okay the squad 🫶 here are the people who wrote this one

Matthew Bocci is the editor 👑 and he's at Nokia. You can reach him at matthew.bocci@nokia.com 💌

Stewart Bryant is at the University of Surrey ICS 🎓 and his email is sb@stewartbryant.com 🦋

John Drake is independent 🌈 with the email je_drake@yahoo.com 💜

the MPLS brainiacs are literally iconic 😭💅

📦 where this page comes from