rfc9791.original   rfc9791.txt 
MPLS Working Group T. Saad Internet Engineering Task Force (IETF) T. Saad
Internet-Draft Cisco Systems, Inc. Request for Comments: 9791 Cisco Systems, Inc.
Intended status: Informational K. Makhijani Category: Informational K. Makhijani
Expires: 27 March 2025 Independent ISSN: 2070-1721 Independent
H. Song H. Song
Futurewei Technologies Futurewei Technologies
G. Mirsky G. Mirsky
Ericsson Ericsson
23 September 2024 May 2025
Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data
draft-ietf-mpls-mna-usecases-15
Abstract Abstract
This document presents use cases that have a common feature that may This document presents use cases that have a common feature that may
be addressed by encoding network action indicators and associated be addressed by encoding network action indicators and associated
ancillary data within MPLS packets. There is community interest in ancillary data within MPLS packets. There is community interest in
extending the MPLS data plane to carry such indicators and ancillary extending the MPLS data plane to carry such indicators and ancillary
data to address the use cases that are described in this document. data to address these use cases.
The use cases described in this document are not an exhaustive set, The use cases described in this document are not an exhaustive set
but rather the ones that are actively discussed by members of the but rather the ones that have been actively discussed by members of
IETF MPLS, PALS, and DetNet working groups from the beginning of work the IETF MPLS, PALS, and DetNet Working Groups from the beginning of
on the MPLS Network Action until the publication of this document. work on MPLS Network Action (MNA) until the publication of this
document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 27 March 2025. 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/rfc9791.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
1.2. Conventions used in this document . . . . . . . . . . . . 3 1.2. Abbreviations
1.2.1. Acronyms and Abbreviations . . . . . . . . . . . . . 3 2. Use Cases
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. No Further Fast Reroute
2.1. No Further Fast Reroute . . . . . . . . . . . . . . . . . 4 2.2. Applicability of Hybrid Measurement Methods
2.2. Applicability of Hybrid Measurement Methods . . . . . . . 4 2.2.1. In Situ OAM
2.2.1. In-situ OAM . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Alternate Marking Method
2.2.2. Alternate Marking Method . . . . . . . . . . . . . . 5 2.3. Network Slicing
2.3. Network Slicing . . . . . . . . . . . . . . . . . . . . . 6 2.4. NSH-Based Service Function Chaining
2.4. NSH-based Service Function Chaining . . . . . . . . . . . 6 2.5. Network Programming
2.5. Network Programming . . . . . . . . . . . . . . . . . . . 7 3. Coexistence with the Existing MPLS Services Using Post-Stack
3. Co-existence with the Existing MPLS Services Using Post-Stack Headers
Headers . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Coexistence of the MNA Use Cases
4. Co-existence of the MNA Use Cases . . . . . . . . . . . . . . 8 5. IANA Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Use Cases for Continued Discussion
8.2. Informative References . . . . . . . . . . . . . . . . . 9 A.1. Generic Delivery Functions
Appendix A. Use Cases for Continued Discussion . . . . . . . . . 13 A.2. Delay Budgets for Time-Bound Applications
A.1. Generic Delivery Functions . . . . . . . . . . . . . . . 13 A.3. Stack-Based Methods for Latency Control
A.2. Delay Budgets for Time-Bound Applications . . . . . . . . 13 Acknowledgements
A.3. Stack-Based Methods for Latency Control . . . . . . . . . 14 Contributors
Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document describes use cases that introduce functions that This document describes use cases that introduce functions that
require special processing by forwarding hardware. The current state require special processing by forwarding hardware. The current state
of the art requires allocating a new special-purpose label (SPL) of the art requires allocating a new Special-Purpose Label (SPL)
[RFC3032] or extended special-purpose label (eSPL). SPLs are a very [RFC3032] or Extended Special-Purpose Label (eSPL). SPLs are a very
limited resource, while eSPL requires an extra Label Stack Entry per limited resource, while eSPL requires an extra label stack entry per
Network Action, which is expensive. Therefore, an MPLS Network network action, which is expensive. Therefore, an MPLS Network
Action (MNA) [RFC9613] approach was proposed to extend the MPLS Action (MNA) [RFC9613] approach was proposed to extend the MPLS
architecture. MNA is expected to enable functions that may require architecture. MNA is expected to enable functions that may require
carrying additional ancillary data within the MPLS packets, as well carrying additional ancillary data within the MPLS packets, as well
as a means to indicate the ancillary data is present and a specific as a means to indicate that the ancillary data is present and a
action needs to be performed on the packet. specific action needs to be performed on the packet.
This document lists various use cases that could benefit extensively This document lists various use cases that could benefit extensively
from the MNA framework [I-D.ietf-mpls-mna-fwk]. Supporting a from the MNA framework [RFC9789]. Supporting a solution of the
solution of the general MNA framework provides a common foundation general MNA framework provides a common foundation for future network
for future network actions that can be exercised in the MPLS data actions that can be exercised in the MPLS data plane.
plane.
1.1. Terminology 1.1. Terminology
The following terminology is used in the document: The following terminology is used in the document:
RFC 9543 Network Slice RFC 9543 Network Slice:
is interpreted as defined in [RFC9543]. Furthermore, this Interpreted as defined in [RFC9543]. This document uses "network
document uses "network slice" interchangeably as a shorter version slice" interchangeably as a shorter version of the term "RFC 9543
of the RFC 9543 Network Slice term. Network Slice".
The MPLS Ancillary Data is classified as: MPLS Ancillary Data:
* residing within the MPLS label stack and referred to as In- Data that can be classified as:
Stack Data, and
* residing after the Bottom of Stack (BoS) and referred to as * residing within the MPLS label stack (referred to as "in-stack
Post-Stack Data. data"), and
1.2. Conventions used in this document * residing after the Bottom of Stack (BoS) (referred to as "post-
stack data").
1.2.1. Acronyms and Abbreviations 1.2. Abbreviations
MNA: MPLS Network Action MNA: MPLS Network Action
DEX: Direct Export DEX: Direct Export
I2E: Ingress to Edge I2E: Ingress to Edge
HbH: Hop by Hop HbH: Hop by Hop
PW: Pseudowire PW: Pseudowire
BoS: Bottom of Stack BoS: Bottom of Stack
ToS: Top of Stack ToS: Top of Stack
NSH: Network Service Header NSH: Network Service Header
FRR: Fast Reroute FRR: Fast Reroute
IOAM: In-situ Operations, Administration, and Maintenance
G-ACh: Generic Associated Channel IOAM: In situ Operations, Administration, and Maintenance
LSP: Label Switched Path G-ACh: Generic Associated Channel
LSR: Label Switch Router LSP: Label Switched Path
NRP: Network Resource Partition LSR: Label Switching Router
SPL: Special Purpose Label NRP: Network Resource Partition
eSPL: extended Special Purpose Label SPL: Special-Purpose Label
AMM: Alternative Marking Method eSPL: extended Special-Purpose Label
AMM: Alternative Marking Method
2. Use Cases 2. Use Cases
2.1. No Further Fast Reroute 2.1. No Further Fast Reroute
MPLS Fast Reroute [RFC4090], [RFC5286], [RFC7490], and MPLS Fast Reroute [RFC4090] [RFC5286] [RFC7490] [SR-TI-LFA] is a
[I-D.ietf-rtgwg-segment-routing-ti-lfa] is a useful and widely useful and widely deployed tool for minimizing packet loss in the
deployed tool for minimizing packet loss in the case of a link or case of a link or node failure.
node failure.
Several cases exist where, once a Fast Reroute (FRR) has taken place Several cases exist where, once a Fast Reroute (FRR) has taken place
in an MPLS network and a packet is rerouted away from the failure, a in an MPLS network and a packet is rerouted away from the failure, a
second FRR impacts the same packet on another node and may result in second FRR impacts the same packet on another node and may result in
traffic disruption. traffic disruption.
In such a case, the packet impacted by multiple FRR events may In such a case, the packet impacted by multiple FRR events may
continue to loop between the label switch routers (LSRs) that continue to loop between the Label Switching Routers (LSRs) that
activated FRR until the packet's TTL expires. That can lead to link activated FRR until the packet's TTL expires. That can lead to link
congestion and further packet loss. To avoid that situation, packets congestion and further packet loss. To avoid that situation, packets
that FRR has redirected will be marked using MNA to preclude further that FRR has redirected will be marked using MNA to preclude further
FRR processing. FRR processing.
2.2. Applicability of Hybrid Measurement Methods 2.2. Applicability of Hybrid Measurement Methods
MNA can be used to carry information essential for collecting MNA can be used to carry information essential for collecting
operational information and measuring various performance metrics operational information and measuring various performance metrics
that reflect the experience of the packet marked by MNA. Optionally, that reflect the experience of the packet marked by MNA. Optionally,
the operational state and telemetry information collected on the LSR the operational state and telemetry information collected on the LSR
may be transported using MNA techniques. may be transported using MNA techniques.
2.2.1. In-situ OAM 2.2.1. In Situ OAM
In-situ Operations, Administration, and Maintenance (IOAM), defined In situ Operations, Administration, and Maintenance (IOAM), defined
in [RFC9197] and [RFC9326], might be used to collect operational and in [RFC9197] and [RFC9326], might be used to collect operational and
telemetry information while a packet traverses a particular path in a telemetry information while a packet traverses a particular path in a
network domain. network domain.
IOAM can run in two modes: Ingress to Edge (I2E) and Hop by Hop IOAM can run in two modes: Ingress to Edge (I2E) and Hop by Hop
(HbH). In I2E mode, only the encapsulating and decapsulating nodes (HbH). In I2E mode, only the encapsulating and decapsulating nodes
will process IOAM data fields. In HbH mode, the encapsulating and will process IOAM data fields. In HbH mode, the encapsulating and
decapsulating nodes and intermediate IOAM-capable nodes process IOAM decapsulating nodes and intermediate IOAM-capable nodes process IOAM
data fields. The IOAM data fields, defined in [RFC9197], can be used data fields. The IOAM data fields, defined in [RFC9197], can be used
to derive the operational state of the network experienced by the to derive the operational state of the network experienced by the
skipping to change at page 5, line 33 skipping to change at line 217
* Pre-allocated Trace * Pre-allocated Trace
* Incremental Trace * Incremental Trace
* Edge-to-Edge * Edge-to-Edge
* Proof-of-Transit * Proof-of-Transit
* Direct Export (DEX) * Direct Export (DEX)
With all IOAM Option-Types except for the Direct Export (DEX), the With all IOAM Option-Types except for Direct Export (DEX), the
collected information is transported in the trigger IOAM packet. In collected information is transported in the trigger IOAM packet. In
the IOAM DEX Option [RFC9326], the operational state and telemetry the IOAM DEX Option-Type [RFC9326], the operational state and
information are collected according to a specified profile and telemetry information are collected according to a specified profile
exported in a manner and format defined by a local policy. In IOAM and exported in a manner and format defined by a local policy. In
DEX, the user data packet is only used to trigger the IOAM data to be IOAM DEX, the user data packet is only used to trigger the IOAM data
directly exported or locally aggregated without being carried in the to be directly exported or locally aggregated without being carried
IOAM trigger packets. in the IOAM trigger packets.
2.2.2. Alternate Marking Method 2.2.2. Alternate Marking Method
The Alternate Marking Method (AMM), defined in [RFC9341] and The Alternate Marking Method (AMM), defined in [RFC9341] and
[RFC9342]) is an example of a hybrid performance measurement method [RFC9342]), is an example of a hybrid performance measurement method
([RFC7799]) that can be used in the MPLS network to measure packet [RFC7799] that can be used in the MPLS network to measure packet loss
loss and packet delay performance metrics. [RFC8957] defined the and packet delay performance metrics. [RFC8957] defines the
Synonymous Flow Label framework to realize AMM in the MPLS network. Synonymous Flow Label framework to realize AMM in the MPLS network.
The MNA is an alternative mechanism that can be used to support AMM The MNA is an alternative mechanism that can be used to support AMM
in the MPLS network. in the MPLS network.
2.3. Network Slicing 2.3. Network Slicing
An RFC 9543 Network Slice service ([RFC9543]) provides connectivity An RFC 9543 Network Slice Service [RFC9543] provides connectivity
coupled with network resource commitments and is expressed in terms coupled with network resource commitments and is expressed in terms
of one or more connectivity constructs. Section 5 of of one or more connectivity constructs. Section 5 of [NS-IP-MPLS]
[I-D.ietf-teas-ns-ip-mpls] defines a Network Resource Partition (NRP) defines a Network Resource Partition (NRP) Policy as a policy
Policy as a policy construct that enables the instantiation of construct that enables the instantiation of mechanisms to support one
mechanisms to support one or more network slice services. The or more network slice services. The packets associated with an NRP
packets associated with an NRP may carry a marking in their network may carry a marking in their network-layer header to identify this
layer header to identify this association, referred to as an NRP association, which is referred to as an NRP Selector. The NRP
Selector. The NRP Selector maps a packet to the associated network Selector maps a packet to the associated network resources and
resources and provides the corresponding forwarding treatment onto provides the corresponding forwarding treatment onto the packet.
the packet.
A router that requires the forwarding of a packet that belongs to an A router that requires the forwarding of a packet that belongs to an
NRP may have to decide on the forwarding action to take based on NRP may have to decide on the forwarding action to take based on
selected next-hop(s), and the forwarding treatment (e.g., scheduling selected next hop(s) and decide on the forwarding treatment (e.g.,
and drop policy) to enforce based on the associated per-hop behavior. scheduling and drop policy) to enforce based on the associated per-
hop behavior.
In this case, routers that forward traffic over a physical link In this case, routers that forward traffic over a physical link
shared by multiple NRPs need to identify the NRP to which the packet shared by multiple NRPs need to identify the NRP to which the packet
belongs to enforce their respective forwarding actions and belongs to enforce their respective forwarding actions and
treatments. treatments.
MNA technologies can signal actions for MPLS packets and carry data MNA technologies can signal actions for MPLS packets and carry data
essential for these actions. For example, MNA can carry the NRP essential for these actions. For example, MNA can carry the NRP
Selector [I-D.ietf-teas-ns-ip-mpls] in MPLS packets. Selector [NS-IP-MPLS] in MPLS packets.
2.4. NSH-based Service Function Chaining 2.4. NSH-Based Service Function Chaining
[RFC8595] describes how Service Function Chaining can be realized in [RFC8595] describes how Service Function Chaining can be realized in
an MPLS network by emulating the Network Service Header (NSH) an MPLS network by emulating the Network Service Header (NSH)
[RFC8300] using only MPLS label stack elements. [RFC8300] using only MPLS label stack elements.
The approach in [RFC8595] introduces some limitations discussed in The approach in [RFC8595] introduces some limitations, which are
[I-D.lm-mpls-sfc-path-verification]. However, that approach can discussed in [SFP-VERIF]. However, the approach can benefit from the
benefit from the framework introduced with MNA in MNA framework introduced in [RFC9789].
[I-D.ietf-mpls-mna-fwk].
MNA can be used to extend NSH emulation using MPLS labels [RFC8595] MNA can be used to extend NSH emulation using MPLS labels [RFC8595]
to support the functionality of NSH Context Headers, whether fixed or to support the functionality of NSH Context Headers, whether fixed or
variable-length. For example, MNA could support Flow ID [RFC9263] variable length. For example, MNA could support Flow ID [RFC9263]
that may be used for load-balancing among Service Function Forwarders that may be used for load-balancing among Service Function Forwarders
and/or the Service Functions within the same Service Function Path. and/or the Service Functions within the same Service Function Path.
2.5. Network Programming 2.5. Network Programming
In Segment Routing (SR), an ingress node steers a packet through an In Segment Routing (SR), an ingress node steers a packet through an
ordered list of instructions called "segments". Each of these ordered list of instructions called "segments". Each of these
instructions represents a function to be called at a specific instructions represents a function to be called at a specific
location in the network. A function is locally defined on the node location in the network. A function is locally defined on the node
where it is executed and may range from simply moving forward in the where it is executed and may range from simply moving forward in the
segment list to any complex user-defined behavior. segment list to any complex user-defined behavior.
Network Programming combines SR functions to achieve a networking Network Programming combines SR functions to achieve a networking
objective beyond mere packet routing. objective beyond mere packet routing.
Encoding a pointer to a function and its arguments within an MPLS Encoding a pointer to a function and its arguments within an MPLS
packet transport header may be desirable. MNA can be used to encode packet transport header may be desirable. MNA can be used to encode
the FUNC::ARGs to support the functional equivalent of FUNC::ARG in the FUNC::ARGs to support the functional equivalent of FUNC::ARG in
SRv6 as described in [RFC8986]. Segment Routing over IPv6 as described in [RFC8986].
3. Co-existence with the Existing MPLS Services Using Post-Stack 3. Coexistence with the Existing MPLS Services Using Post-Stack Headers
Headers
Several services can be transported over MPLS networks today. These Several services can be transported over MPLS networks today. These
include providing Layer-3 (L3) connectivity (e.g., for unicast and include providing Layer 3 (L3) connectivity (e.g., for unicast and
multicast L3 services), and Layer-2 (L2) connectivity (e.g., for multicast L3 services) and Layer 2 (L2) connectivity (e.g., for
unicast Pseudowires (PWs), multicast E-Tree, and broadcast E-LAN L2 unicast PWs, multicast E-Tree, and broadcast Ethernet LAN (E-LAN) L2
services). In those cases, the user service traffic is encapsulated services). In those cases, the user service traffic is encapsulated
as the payload in MPLS packets. as the payload in MPLS packets.
For L2 service traffic, it is possible to use Control Word (CW) For L2 service traffic, it is possible to use a Control Word (CW)
[RFC4385] and [RFC5085] immediately after the MPLS header to [RFC4385] [RFC5085] immediately after the MPLS header to disambiguate
disambiguate the type of MPLS payload, prevent possible packet the type of MPLS payload, prevent possible packet misordering, and
misordering, and allow for fragmentation. In this case, the first allow for fragmentation. In this case, the first nibble of the data
nibble the data that immediately follows after the MPLS BoS is set to that immediately follows the MPLS BoS is set to 0b0000 to identify
0b0000 to identify the presence of PW CW. the presence of the PW CW.
In addition to providing connectivity to user traffic, MPLS may also In addition to providing connectivity to user traffic, MPLS may also
transport OAM data (e.g., over MPLS Generic Associated Channels transport OAM data (e.g., over MPLS Generic Associated Channels
(G-AChs) [RFC5586]). In this case, the first nibble of the data that (G-AChs) [RFC5586]). In this case, the first nibble of the data that
immediately follows after the MPLS BoS is set to 0b0001. It immediately follows the MPLS BoS is set to 0b0001. It indicates the
indicates the presence of a control channel associated with a PW, presence of a control channel associated with a PW, LSP, or section.
LSP, or Section.
Bit Index Explicit Replication (BIER) [RFC8296] traffic can also be Bit Index Explicit Replication (BIER) [RFC8296] traffic can also be
encapsulated over MPLS. In this case, BIER has defined 0b0101 as the encapsulated over MPLS. In this case, BIER has defined 0b0101 as the
value for the first nibble in the data that immediately appears after value for the first nibble of the data that immediately follows the
the bottom of the label stack for any BIER-encapsulated packet over bottom of the label stack for any BIER-encapsulated packet over MPLS.
MPLS.
For pseudowires, the Generic Associated Channel [RFC7212] uses the For PWs, the G-ACh [RFC7212] uses the first four bits of the PW
first four bits of the PW control word to provide the initial control word to provide the initial discrimination between data
discrimination between data packets and packets belonging to the packets and packets belonging to the associated channel, as described
associated channel, as described in [RFC4385]. in [RFC4385].
MPLS can be used as the data plane for DetNet [RFC8655]. The DetNet MPLS can be used as the data plane for Deterministic Networking
sub-layers, forwarding, and service are realized using the MPLS label (DetNet) [RFC8655]. The DetNet sub-layers, forwarding, and service
stack, the DetNet Control Word [RFC8964], and the DetNet Associated are realized using the MPLS label stack, the DetNet control word
Channel Header [RFC9546]. [RFC8964], and the DetNet Associated Channel Header [RFC9546].
MNA-based solutions for the use cases described in this document and MNA-based solutions for the use cases described in this document and
proposed in the future are expected to allow for coexistence and proposed in the future are expected to allow for coexistence and
backward compatibility with all existing MPLS services. backward compatibility with all existing MPLS services.
4. Co-existence of the MNA Use Cases 4. Coexistence of the MNA Use Cases
Two or more of the discussed cases may co-exist in the same packet. Two or more of the discussed cases may coexist in the same packet.
That may require the presence of multiple ancillary data (whether In- That may require the presence of multiple ancillary data (whether in-
stack or Post-stack ancillary data) to be present in the same MPLS stack or post-stack ancillary data) to be present in the same MPLS
packet. packet.
For example, IOAM may provide essential functions along with network For example, IOAM may provide essential functions along with network
slicing to help ensure that critical network slice SLOs are being met slicing to help ensure that critical network slice Service Level
by the network provider. In this case, IOAM can collect key Objectives (SLOs) are being met by the network provider. In this
performance measurement parameters of network slice traffic flow as case, IOAM can collect key performance measurement parameters of a
it traverses the transport network. network slice traffic flow as it traverses the transport network.
5. IANA Considerations 5. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
Section 7 of "MPLS Network Action (MNA) Framework", Section 7 of the MNA framework [RFC9789] outlines security
[I-D.ietf-mpls-mna-fwk] outlines security considerations for non- considerations for documents that do not specify protocols. The
protocol specifying documents. The authors have verified that these authors have verified that these considerations are fully applicable
considerations are fully applicable to this document. to this document.
In-depth security analysis for each specific use case is beyond the In-depth security analysis for each specific use case is beyond the
scope of this document and will be addressed in future solution scope of this document and will be addressed in future solution
documents. It is strongly recommended that these solution documents documents. It is strongly recommended that these solution documents
undergo security expert review early in their development, ideally undergo review by a security expert early in their development,
during the Working Group Last Call phase. ideally during the Working Group Last Call phase.
7. Acknowledgement
The authors gratefully acknowledge the input of the members of the
MPLS Open Design Team. Also, the authors sincerely thank Loa
Andersson, Xiao Min, Jie Dong, and Yaron Sheffer. for their
thoughtful suggestions and help in improving the document.
8. References
8.1. Normative References
[I-D.ietf-mpls-mna-fwk]
Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Network Actions (MNA) Framework", Work in Progress,
Internet-Draft, draft-ietf-mpls-mna-fwk-10, 6 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-fwk-10>.
8.2. Informative References
[I-D.ietf-rtgwg-segment-routing-ti-lfa] 7. References
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
17, 5 July 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rtgwg-segment-routing-ti-lfa-17>.
[I-D.ietf-teas-ns-ip-mpls] 7.1. Normative References
Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli,
D., Halpern, J. M., Peng, S., Chen, R., Liu, X.,
Contreras, L. M., Rokui, R., and L. Jalil, "Realizing
Network Slices in IP/MPLS Networks", Work in Progress,
Internet-Draft, draft-ietf-teas-ns-ip-mpls-04, 28 May
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
teas-ns-ip-mpls-04>.
[I-D.lm-mpls-sfc-path-verification] [RFC9789] Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Liu, Y. and G. Mirsky, "MPLS-based Service Function Network Action (MNA) Framework", RFC 9789,
Path(SFP) Consistency Verification", Work in Progress, DOI 10.17487/RFC9789, May 2025,
Internet-Draft, draft-lm-mpls-sfc-path-verification-03, 11 <https://www.rfc-editor.org/info/rfc9789>.
June 2022, <https://datatracker.ietf.org/doc/html/draft-
lm-mpls-sfc-path-verification-03>.
[I-D.stein-srtsn] 7.2. Informative References
Stein, Y. J., "Segment Routed Time Sensitive Networking",
Work in Progress, Internet-Draft, draft-stein-srtsn-01, 29
August 2021, <https://datatracker.ietf.org/doc/html/draft-
stein-srtsn-01>.
[I-D.zzhang-intarea-generic-delivery-functions] [GDF] Zhang, Z., Bonica, R., Kompella, K., and G. Mirsky,
Zhang, Z. J., Bonica, R., Kompella, K., and G. Mirsky,
"Generic Delivery Functions", Work in Progress, Internet- "Generic Delivery Functions", Work in Progress, Internet-
Draft, draft-zzhang-intarea-generic-delivery-functions-03, Draft, draft-zzhang-intarea-generic-delivery-functions-03,
11 July 2022, <https://datatracker.ietf.org/doc/html/ 11 July 2022, <https://datatracker.ietf.org/doc/html/
draft-zzhang-intarea-generic-delivery-functions-03>. draft-zzhang-intarea-generic-delivery-functions-03>.
[NS-IP-MPLS]
Saad, T., Beeram, V., Dong, J., Halpern, J., and S. Peng,
"Realizing Network Slices in IP/MPLS Networks", Work in
Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-05, 2
March 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-teas-ns-ip-mpls-05>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005, DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>. <https://www.rfc-editor.org/info/rfc4090>.
skipping to change at page 13, line 5 skipping to change at line 517
Administration, and Maintenance (OAM) for Deterministic Administration, and Maintenance (OAM) for Deterministic
Networking (DetNet) with the MPLS Data Plane", RFC 9546, Networking (DetNet) with the MPLS Data Plane", RFC 9546,
DOI 10.17487/RFC9546, February 2024, DOI 10.17487/RFC9546, February 2024,
<https://www.rfc-editor.org/info/rfc9546>. <https://www.rfc-editor.org/info/rfc9546>.
[RFC9613] Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements [RFC9613] Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements
for Solutions that Support MPLS Network Actions (MNAs)", for Solutions that Support MPLS Network Actions (MNAs)",
RFC 9613, DOI 10.17487/RFC9613, August 2024, RFC 9613, DOI 10.17487/RFC9613, August 2024,
<https://www.rfc-editor.org/info/rfc9613>. <https://www.rfc-editor.org/info/rfc9613>.
[SFP-VERIF]
Yao, L. and G. Mirsky, "MPLS-based Service Function
Path(SFP) Consistency Verification", Work in Progress,
Internet-Draft, draft-lm-mpls-sfc-path-verification-03, 11
June 2022, <https://datatracker.ietf.org/doc/html/draft-
lm-mpls-sfc-path-verification-03>.
[SR-TI-LFA]
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
21, 12 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
segment-routing-ti-lfa-21>.
[SRTSN] Stein, Y(J)., "Segment Routed Time Sensitive Networking",
Work in Progress, Internet-Draft, draft-stein-srtsn-01, 29
August 2021, <https://datatracker.ietf.org/doc/html/draft-
stein-srtsn-01>.
Appendix A. Use Cases for Continued Discussion Appendix A. Use Cases for Continued Discussion
Several use cases for which MNA can provide a viable solution have Several use cases for which MNA can provide a viable solution have
been discussed. The discussion of these aspirational cases is been discussed. The discussion of these aspirational cases is
ongoing at the time of publication of the document. ongoing at the time of publication of the document.
A.1. Generic Delivery Functions A.1. Generic Delivery Functions
The Generic Delivery Functions (GDFs), defined in Generic Delivery Functions (GDFs), defined in [GDF], provide a new
[I-D.zzhang-intarea-generic-delivery-functions], provide a new
mechanism to support functions analogous to those supported through mechanism to support functions analogous to those supported through
the IPv6 Extension Headers mechanism. For example, GDF can support the IPv6 Extension Headers mechanism. For example, GDF can support
fragmentation/reassembly functionality in the MPLS network by using fragmentation/reassembly functionality in the MPLS network by using
the Generic Fragmentation Header. MNA can support GDF by placing a the Generic Fragmentation Header. MNA can support GDF by placing a
GDF header in an MPLS packet within the Post-Stack Data block GDF header in an MPLS packet within the post-stack data block
[I-D.ietf-mpls-mna-fwk]. Multiple GDF headers can also be present in [RFC9789]. Multiple GDF headers, organized as a list of headers, can
the same MPLS packet organized as a list of headers. also be present in the same MPLS packet.
A.2. Delay Budgets for Time-Bound Applications A.2. Delay Budgets for Time-Bound Applications
The routers in a network can perform two distinct functions on The routers in a network can perform two distinct functions on
incoming packets, namely forwarding (where the packet should be sent) incoming packets: forwarding (where the packet should be sent) and
and scheduling (when the packet should be sent). IEEE-802.1 Time scheduling (when the packet should be sent). IEEE-802.1 Time-
Sensitive Networking (TSN) and Deterministic Networking provide Sensitive Networking (TSN) and DetNet provide several mechanisms for
several mechanisms for scheduling under the assumption that routers scheduling under the assumption that routers are time-synchronized.
are time-synchronized. The most effective mechanisms for delay The most effective mechanisms for delay minimization involve per-flow
minimization involve per-flow resource allocation. resource allocation.
Segment Routing (SR) is a forwarding paradigm that allows encoding Segment Routing (SR) is a forwarding paradigm that allows encoding
forwarding instructions in the packet in a stack data structure forwarding instructions in the packet in a stack data structure
rather than being programmed into the routers. The SR instructions rather than being programmed into the routers. The SR instructions
are contained within a packet in the form of a First-in, First-out are contained within a packet in the form of a First-In, First-Out
stack dictating the forwarding decisions of successive routers. stack, dictating the forwarding decisions of successive routers.
Segment routing may be used to choose a path sufficiently short to be Segment routing may be used to choose a path sufficiently short to be
capable of providing a bounded end-to-end latency but does not capable of providing bounded end-to-end latency but does not
influence the queueing of individual packets in each router along influence the queueing of individual packets in each router along
that path. that path.
When carried over the MPLS data plane, a solution is required to When carried over the MPLS data plane, a solution is required to
enable the delivery of such packets that can be delivered to their enable the delivery of such packets to their final destination within
final destination within a given time budget. One approach to a given time budget. One approach to address this use case in SR
address this use case in SR-MPLS was described in [I-D.stein-srtsn]. over MPLS (SR-MPLS) is described in [SRTSN].
A.3. Stack-Based Methods for Latency Control A.3. Stack-Based Methods for Latency Control
One efficient data structure for inserting local deadlines into the One efficient data structure for inserting local deadlines into the
headers is a "stack", similar to that used in Segment Routing to headers is a "stack", similar to that used in SR to carry forwarding
carry forwarding instructions. The number of deadline values in the instructions. The number of deadline values in the stack equals the
stack equals the number of routers the packet needs to traverse in number of routers the packet needs to traverse in the network, and
the network, and each deadline value corresponds to a specific each deadline value corresponds to a specific router. The Top of
router. The Top-of-Stack (ToS) corresponds to the first router's Stack (ToS) corresponds to the first router's deadline, while the
deadline, while the MPLS BoS refers to the last. All local deadlines MPLS BoS refers to the last. All local deadlines in the stack are
in the stack are later or equal to the current time (upon which all later than or equal to the current time (upon which all routers
routers agree), and times closer to the ToS are always earlier or agree), and times closer to the ToS are always earlier than or equal
equal to times closer to the MPLS BoS. to times closer to the MPLS BoS.
The ingress router inserts the deadline stack into the packet The ingress router inserts the deadline stack into the packet
headers; no other router needs to know the time-bound flows' headers; no other router needs to know the requirements of the time-
requirements. Hence, admitting a new flow only requires updating the bound flows. Hence, admitting a new flow only requires updating the
ingress router's information base. ingress router's information base.
MPLS LSRs that expose the ToS label can also inspect the associated MPLS LSRs that expose the ToS label can also inspect the associated
"deadline" carried in the packet (either in the MPLS stack as In- deadline carried in the packet (either in the MPLS stack as in-stack
Stack Data or after BoS as Post-Stack Data). data or after BoS as post-stack data).
Contributors' Addresses Acknowledgements
The authors gratefully acknowledge the input of the members of the
MPLS Open Design Team. Also, the authors sincerely thank Loa
Andersson, Xiao Min, Jie Dong, and Yaron Sheffer for their thoughtful
suggestions and help in improving the document.
Contributors
Loa Anderssen Loa Anderssen
Bronze Dragon Consulting Bronze Dragon Consulting
Email: loa@pi.nu Email: loa@pi.nu
Authors' Addresses Authors' Addresses
Tarek Saad Tarek Saad
Cisco Systems, Inc. Cisco Systems, Inc.
Email: tsaad.net@gmail.com Email: tsaad.net@gmail.com
 End of changes. 79 change blocks. 
251 lines changed or deleted 239 lines changed or added

This html diff was produced by rfcdiff 1.48.