<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 2.6.10) --><?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<!-- [rfced] *AD: We see that consensus is set to "Unknown"
for this document in the datatracker. See
<https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>.
This document was sent to Last Call, so we have used the
consensus Status of This Memo. Please let us know if any updates
are needed.
-->
<!-- [rfced] The document title includes two instances of "MPLS". Are both needed?
Original:
Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data
Perhaps:
Use Cases for MPLS Network Action Indicators and Ancillary Data
-->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-mpls-mna-usecases-15" number="9791" consensus="true" updates="" obsoletes="" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" version="3" xml:lang="en">
<front>
<title abbrev="MNA Use Cases">Use Cases for MPLS Network Action Indicators
and MPLS Ancillary Data</title>
<seriesInfo name="RFC" value="9791"/>
<author initials="T." surname="Saad" fullname="Tarek Saad">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>tsaad.net@gmail.com</email>
</address>
</author>
<author initials="K." surname="Makhijani" fullname="Kiran Makhijani">
<organization>Independent</organization>
<address>
<email>kiran.ietf@gmail.com</email>
</address>
</author>
<author initials="H." surname="Song" fullname="Haoyu Song">
<organization>Futurewei Technologies</organization>
<address>
<email>haoyu.song@futurewei.com</email>
</address>
</author>
<author initials="G." surname="Mirsky" fullname="Greg Mirsky">
<organization>Ericsson</organization>
<address>
<email>gregimirsky@gmail.com</email>
</address>
</author>
<date year="2024"/>
<workgroup>MPLS Working Group</workgroup>
<keyword>Internet-Draft</keyword> year="2025" month="May"/>
<area>RTG</area>
<workgroup>mpls</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract>
<t>
This document presents use cases that have a common feature
that may be addressed by encoding network action indicators
and associated ancillary data within MPLS packets. There is community
interest in extending the MPLS data plane to carry such indicators
and ancillary data to address the these use cases that are described
in this document. cases.
</t>
<t>
The use cases described in this document are not an exhaustive set, set
but rather the ones that are have been actively discussed by members of the
IETF MPLS, PALS, and DetNet working groups Working Groups from the beginning of work
on the MPLS Network Action (MNA) until the publication of this document.
</t>
</abstract>
</front>
<middle>
<section anchor="introduction"><name>Introduction</name> anchor="introduction">
<name>Introduction</name>
<t>This document describes use cases that introduce functions that require
special processing by forwarding hardware. The current state of the art requires
allocating a new special-purpose label Special-Purpose Label (SPL) <xref target="RFC3032"/> or extended special-purpose label Extended Special-Purpose Label (eSPL).
SPLs are a very limited resource, while eSPL requires an extra Label Stack Entry label stack entry per Network Action, network action, which is expensive.
Therefore, an MPLS Network Action (MNA) <xref target="RFC9613"/> approach was proposed to extend the MPLS architecture.
MNA is expected to enable functions that may require carrying additional
ancillary data within the MPLS packets, as well as a means to indicate that the
ancillary data is present and a specific action needs to be performed on the
packet.</t>
<t>
This document lists various use cases that could benefit extensively
from the MNA framework <xref target="I-D.ietf-mpls-mna-fwk"/>. target="RFC9789"/>.
Supporting a solution of the general MNA framework provides
a common foundation for future network actions that can be exercised
in the MPLS data plane.
</t>
<section anchor="terminology"><name>Terminology</name> anchor="terminology">
<name>Terminology</name>
<t>The following terminology is used in the document:</t>
<dl newline="true">
<dt>RFC
<!-- [rfced] We see that "MPLS Ancillary Data" appears in Section 1.1
("Terminology"). We see instances of "ancillary data" (no "MPLS") in the
document, but we only see "MPLS Ancillary Data" used in the document
title. Are any updates needed?
Also, note that we slightly updated the definition list as follows to clearly
note the terms and their definitions.
Original:
RFC 9543 Network Slice</dt>
<dd>
<t> Slice
is interpreted as defined in <xref target="RFC9543"/>. [RFC9543]. Furthermore, this
document uses "network slice" interchangeably as a shorter version
of the RFC 9543 Network Slice term.</t>
</dd>
<dt>The term.
The MPLS Ancillary Data is classified as:</dt>
<dd>
<t><list style="symbols">
<t>residing as:
* residing within the MPLS label stack and referred to as In-Stack In-
Stack Data, and</t>
<t>residing and
* residing after the Bottom of Stack (BoS) and referred to as
Post-Stack Data.</t>
</list>
</t> Data.
Updated:
RFC 9543 Network Slice:
Interpreted as defined in [RFC9543]. This document
uses "network slice" interchangeably as a shorter version of the
term "RFC 9543 Network Slice".
MPLS Ancillary Data:
Data that can be classified as:
* residing within the MPLS label stack (referred to as "in-stack
data"), and
* residing after the Bottom of Stack (BoS) (referred to as "post-
stack data").
-->
<dl newline="true" spacing="normal">
<dt>RFC 9543 Network Slice:</dt>
<dd>Interpreted as defined in <xref target="RFC9543"/>.
This document uses "network slice" interchangeably as a
shorter version of the term "RFC 9543 Network Slice".</dd>
<dt>MPLS Ancillary Data:</dt>
<dd><t>Data that can be classified as:</t>
<ul spacing="normal">
<li>residing within the MPLS label stack (referred to as "in-stack data"), and</li>
<li>residing after the Bottom of Stack (BoS) (referred to as "post-stack data").</li>
</ul>
</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Conventions used anchor="acronyms-and-abbreviations">
<!-- [rfced] Would you like for the abbreviations listed in this document</name>
<section anchor="acronyms-and-abbreviations"><name>Acronyms and Abbreviations</name>
<ul empty="true"><li>
<t>MNA: MPLS Section 1.2
("Abbreviations") to be alphabetized? Or do you prefer the current order?
-->
<name>Abbreviations</name>
<dl spacing="normal" newline="false">
<dt>MNA:</dt><dd>MPLS Network Action</t>
</li></ul>
<ul empty="true"><li>
<t>DEX: Direct Export</t>
</li></ul>
<ul empty="true"><li>
<t>I2E: Ingress Action</dd>
<dt>DEX:</dt><dd>Direct Export</dd>
<dt>I2E:</dt><dd>Ingress to Edge</t>
</li></ul>
<ul empty="true"><li>
<t>HbH: Hop Edge</dd>
<dt>HbH:</dt><dd>Hop by Hop</t>
</li></ul>
<ul empty="true"><li>
<t>PW: Pseudowire</t>
</li></ul>
<ul empty="true"><li>
<t>BoS: Bottom Hop</dd>
<dt>PW:</dt><dd>Pseudowire</dd>
<dt>BoS:</dt><dd>Bottom of Stack</t>
</li></ul>
<ul empty="true"><li>
<t>ToS: Top Stack</dd>
<dt>ToS:</dt><dd>Top of Stack</t>
</li></ul>
<ul empty="true"><li>
<t>NSH: Network Stack</dd>
<dt>NSH:</dt><dd>Network Service Header</t>
</li></ul>
<ul empty="true"><li>
<t>FRR: Fast Reroute</t>
</li></ul>
<ul empty="true"><li>
<t>IOAM: In-situ Header</dd>
<dt>FRR:</dt><dd>Fast Reroute</dd>
<dt>IOAM:</dt><dd>In situ Operations, Administration, and Maintenance</t>
</li></ul>
<ul empty="true"><li>
<t>G-ACh: Generic Maintenance</dd>
<dt>G-ACh:</dt><dd>Generic Associated Channel</t>
</li></ul>
<ul empty="true"><li>
<t>LSP: Label Channel</dd>
<dt>LSP:</dt><dd>Label Switched Path</t>
</li></ul>
<ul empty="true"><li>
<t>LSR: Label Switch Router</t>
</li></ul>
<ul empty="true"><li>
<t>NRP: Network Path</dd>
<dt>LSR:</dt><dd>Label Switching Router</dd>
<dt>NRP:</dt><dd>Network Resource Partition</t>
</li></ul>
<ul empty="true"><li>
<t>SPL: Special Purpose Label</t>
</li></ul>
<ul empty="true"><li>
<t>eSPL: extended Special Purpose Label</t>
</li></ul>
<ul empty="true"><li>
<t>AMM: Alternative Partition</dd>
<dt>SPL:</dt><dd>Special-Purpose Label</dd>
<dt>eSPL:</dt><dd>extended Special-Purpose Label</dd>
<dt>AMM:</dt><dd>Alternative Marking Method</t>
</li></ul>
</section> Method</dd>
</dl>
</section>
</section>
<section anchor="use-cases"><name>Use anchor="use-cases">
<name>Use Cases</name>
<section anchor="no-further-fastreroute"><name>No anchor="no-further-fastreroute">
<name>No Further Fast Reroute</name>
<t>MPLS Fast Reroute <xref target="RFC4090"/>, target="RFC4090"/> <xref target="RFC5286"/>, target="RFC5286"/> <xref target="RFC7490"/>,
and target="RFC7490"/>
<xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/> is a useful
and widely deployed tool for minimizing packet loss in the case of a link or
node failure.</t>
<t>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 second FRR impacts
the same packet on another node and may result in traffic disruption.</t>
<t>
In such a case, the packet impacted by multiple FRR events may continue to loop
between the label switch routers Label Switching Routers (LSRs) that activated FRR until the packet's TTL
expires. That can lead to link congestion and further packet loss.
To avoid that situation, packets that FRR has redirected will be marked using MNA to preclude further FRR processing.
</t>
</section>
<section anchor="hybrid-pmm-sec">
<name>Applicability of Hybrid Measurement Methods</name>
<t>MNA can be used to carry information essential for collecting operational information
and measuring various performance metrics that reflect the experience of the packet marked by MNA.
Optionally, the operational state and telemetry information collected on
the LSR may be transported using MNA techniques.</t>
<section anchor="in-situ-oam"><name>In-situ anchor="in-situ-oam">
<name>In Situ OAM</name>
<t>In-situ
<t>In situ Operations, Administration, and Maintenance (IOAM),
defined in <xref target="RFC9197"/> and <xref target="RFC9326"/>, might be used to collect
operational and telemetry information while a packet traverses a particular path
in a network domain.</t>
<t>IOAM can run in two modes: Ingress to Edge (I2E) and Hop by Hop (HbH). In I2E
mode, only the encapsulating and decapsulating nodes will process IOAM data
fields. In HbH mode, the encapsulating and decapsulating nodes
and intermediate IOAM-capable nodes process IOAM data fields. The IOAM data fields,
defined in <xref target="RFC9197"/>, can be used to derive the operational state of the network
experienced by the packet with the IOAM Header that traversed the path through the IOAM domain.</t>
<t>Several IOAM Option-Types have been defined:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>Pre-allocated Trace</t>
</li>
<li>
<t>Incremental Trace</t>
</li>
<li>
<t>Edge-to-Edge</t>
</li>
<li>
<t>Proof-of-Transit</t>
</li>
<li>
<t>Direct Export (DEX)</t>
</list></t>
</li>
</ul>
<t>
With all IOAM Option-Types except for the Direct Export (DEX), the collected
information is transported in the trigger IOAM packet.
In the IOAM DEX Option Option-Type <xref target="RFC9326"/>, the operational state and telemetry information are
collected according to a specified profile and exported in a manner and
format defined by a local policy. In IOAM DEX, the user data packet is only
used to trigger the IOAM data to be directly exported or locally aggregated
without being carried in the IOAM trigger packets.</t>
</section>
<section anchor="ater-mark-sec">
<name>Alternate Marking Method</name>
<t>
The Alternate Marking Method (AMM), defined in <xref target="RFC9341"/> and <xref target="RFC9342"/>) target="RFC9342"/>), is an example
of a hybrid performance measurement method (<xref target="RFC7799"/>) <xref target="RFC7799"/> that can be used in the MPLS network
to measure packet loss and packet delay performance metrics. <xref target="RFC8957"/> defined defines
the Synonymous Flow Label framework to realize AMM in the MPLS network.
The MNA is an alternative mechanism that can be used to support AMM in the MPLS network.
</t>
</section>
</section>
<section anchor="network-slicing"><name>Network anchor="network-slicing">
<name>Network Slicing</name>
<!-- [rfced] Please review "Policy as a policy construct". May we update as
follows (i.e., remove "policy")?
Original:
Section 5 of
[I-D.ietf-teas-ns-ip-mpls] defines a Network Resource Partition (NRP)
Policy as a policy construct that enables the instantiation of
mechanisms to support one or more network slice services.
Perhaps:
Section 5 of [NS-IP-MPLS]
defines a Network Resource Partition (NRP) Policy as a
construct that enables the instantiation of mechanisms to support one
or more network slice services.
-->
<t>An RFC 9543 Network Slice service (<xref target="RFC9543"/>) Service <xref target="RFC9543"/>
provides connectivity coupled with network resource commitments and is expressed in terms of one or more
connectivity constructs. Section 5 of <xref target="I-D.ietf-teas-ns-ip-mpls"/> target="I-D.ietf-teas-ns-ip-mpls" sectionFormat="of" section="5"/> defines a Network Resource Partition (NRP) Policy
as a policy construct that enables the instantiation of mechanisms to support one or more network slice services.
The packets associated with an NRP may carry a
marking in their network layer network-layer header to identify this association, which is referred to as an NRP Selector. The NRP Selector maps
a packet to the associated network resources and provides the
corresponding forwarding treatment onto the packet.</t>
<t>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 selected
next-hop(s),
next hop(s) and decide on the forwarding treatment (e.g., scheduling and drop policy) to
enforce based on the associated per-hop behavior.</t>
<t>In this case, routers that forward traffic over a physical link shared by multiple
NRPs need to identify the NRP to which the packet belongs to enforce their respective forwarding actions and treatments.</t>
<t>MNA technologies can signal actions for MPLS packets
and carry data essential for these actions. For example, MNA can carry the NRP Selector <xref target="I-D.ietf-teas-ns-ip-mpls"/> in MPLS packets.</t>
</section>
<section anchor="nsh-based-service-function-chaining"><name>NSH-based anchor="nsh-based-service-function-chaining">
<name>NSH-Based Service Function Chaining</name>
<!-- [rfced] We believe that "label stack elements" here should be updated to
"label stack entries", which is used earlier in this document and in RFC 8595.
Please confirm. Also note that "label stack element" has not been
used in the RFC Series.
Original:
[RFC8595] describes how Service Function Chaining can be realized in
an MPLS network by emulating the Network Service Header (NSH)
[RFC8300] using only MPLS label stack elements.
-->
<t><xref target="RFC8595"/> describes how Service Function Chaining can be realized in
an MPLS network by emulating the Network Service Header (NSH) <xref target="RFC8300"/> using only MPLS label stack elements.</t>
<t>The approach in <xref target="RFC8595"/> introduces some limitations limitations, which are discussed in
<xref target="I-D.lm-mpls-sfc-path-verification"/>. However, that the approach can benefit
from the MNA framework introduced with MNA in <xref target="I-D.ietf-mpls-mna-fwk"/>.</t> target="RFC9789"/>.</t>
<t>MNA can be used to extend NSH emulation using MPLS
labels <xref target="RFC8595"></xref> target="RFC8595"/> to support the functionality of NSH Context Headers,
whether fixed or variable-length. variable length. For example, MNA could support Flow ID
<xref target="RFC9263"/> that may be used for load-balancing among
Service Function Forwarders and/or the Service Functions
within the same Service Function Path.</t>
</section>
<section anchor="network-programming"><name>Network anchor="network-programming">
<name>Network Programming</name>
<t>In Segment Routing (SR), an ingress node steers a packet through an ordered list of instructions
called "segments". Each of these instructions represents a
function to be called at a specific 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 segment list to any complex
user-defined behavior.</t>
<t>Network Programming combines SR functions to achieve a
networking objective beyond mere packet routing.</t>
<!-- [rfced] Please confirm that "FUNC::ARG" is correct here. We ask because
we see "LOC:FUNCT:ARG" in RFC 8986.
Original:
MNA can be used to encode
the FUNC::ARGs to support the functional equivalent of FUNC::ARG in
SRv6 as described in [RFC8986].
-->
<t>Encoding a pointer to a function and its arguments within an MPLS packet transport header may be desirable.
MNA can be used to encode the FUNC::ARGs to support the functional
equivalent of FUNC::ARG in SRv6 Segment Routing over IPv6 as described in <xref target="RFC8986"/>.</t>
</section>
</section>
<section anchor="existing-mpls-use-cases"><name>Co-existence anchor="existing-mpls-use-cases">
<name>Coexistence with the Existing MPLS Services Using Post-Stack Headers</name>
<t>Several services can be transported over MPLS networks today.
These include providing Layer-3 Layer 3 (L3) connectivity (e.g., for unicast and
multicast L3 services), services) and Layer-2 Layer 2 (L2) connectivity (e.g., for unicast
Pseudowires (PWs),
PWs, multicast E-Tree, and broadcast E-LAN Ethernet LAN (E-LAN) L2 services). In
those cases, the user service traffic is encapsulated as the payload in MPLS packets.</t>
<t>For L2 service traffic, it is possible to use a Control Word (CW) <xref target="RFC4385"/> and
<xref target="RFC5085"/> immediately after the MPLS header to disambiguate the type of MPLS payload,
prevent possible packet misordering, and allow for fragmentation. In this case,
the first nibble of the data that immediately follows after the MPLS BoS is
set to 0b0000 to identify the presence of the PW CW.</t>
<t>In addition to providing connectivity to user traffic, MPLS may also transport OAM
data (e.g., over MPLS Generic Associated Channels (G-AChs) <xref target="RFC5586"/>). In this case, the first nibble of
the data that immediately follows after the MPLS BoS is set to 0b0001. It
indicates the presence of a control channel associated with a PW, LSP, or Section.</t> section.</t>
<!-- [rfced] Would you like to update "bottom of the label stack" here to
"BoS" or leave as is?
Original:
In this case, BIER has defined 0b0101 as the
value for the first nibble in the data that immediately appears after
the bottom of the label stack for any BIER-encapsulated packet over
MPLS.
Perhaps:
In this case, BIER has defined 0b0101 as the
value for the first nibble in the data that immediately appears after
the BoS for any BIER-encapsulated packet over
MPLS.
-->
<t>Bit Index Explicit Replication (BIER) <xref target="RFC8296"/> traffic can also be encapsulated
over MPLS. In this case, BIER has defined 0b0101 as the value for the first nibble
in
of the data that immediately appears after follows the bottom of the label stack for any
BIER-encapsulated packet over MPLS.</t>
<t>For pseudowires, PWs, the Generic Associated Channel G-ACh <xref target="RFC7212"/> uses the first four bits of the PW control word
to provide the initial discrimination between data packets and
packets belonging to the associated channel, as described in
<xref target="RFC4385"></xref>.</t> target="RFC4385"/>.</t>
<t>MPLS can be used as the data plane for DetNet Deterministic Networking (DetNet) <xref target="RFC8655"/>.
The DetNet sub-layers, forwarding, and service
are realized using the MPLS label stack, the DetNet Control Word control word <xref target="RFC8964"/>,
and the DetNet Associated Channel Header <xref target="RFC9546"/>.</t>
<t>MNA-based solutions for the use cases described in this document and proposed
in the future are expected to allow for coexistence and backward compatibility with all existing MPLS services.</t>
</section>
<section anchor="co-existence-of-usecases"><name>Co-existence anchor="co-existence-of-usecases">
<name>Coexistence of the MNA Use Cases</name>
<t>Two or more of the discussed cases may co-exist coexist in the same packet.
That may require the presence of multiple ancillary data
(whether In-stack in-stack or Post-stack post-stack ancillary data) to be present in the same MPLS packet.</t>
<t>For example, IOAM may provide essential functions along with network slicing to help
ensure that critical network slice SLOs Service Level Objectives (SLOs) are being met by the network provider.
In this case, IOAM can collect key performance measurement parameters of a
network slice traffic flow as it traverses the transport network.</t>
</section>
<section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="security-considerations"><name>Security anchor="security-considerations">
<name>Security Considerations</name>
<t>Section
<!-- [rfced] Please confirm that the citation is correct here. We ask because
we do not see the specific wording "non-protocol specifying document" in
RFC-to-be 9789 (ietf-mpls-mna-fwk).
Also, to improve readability, we upddated "non-protocol specifying documents"
as follows. Let us know any concerns.
Original:
Section 7 of "MPLS Network Action (MNA) Framework",
<xref target="I-D.ietf-mpls-mna-fwk"/>
[I-D.ietf-mpls-mna-fwk] outlines security considerations for non-protocol non-
protocol specifying documents.
Updated:
Section 7 of the MNA framework [RFC9789] outlines security
considerations for documents that do not specify protocols.
-->
<t>Section <xref target="RFC9789" sectionFormat="bare" section="7"/> of the MNA framework
<xref target="RFC9789"/> outlines security considerations for documents that do not specify protocols.
The authors have verified that these considerations are fully applicable to this document.
</t>
<t>
In-depth security analysis for each specific use case is beyond the scope of this document
and will be addressed in future solution documents. It is strongly recommended
that these solution documents undergo review by a security expert review early in their development,
ideally during the Working Group Last Call phase.
</t>
</section>
<section anchor="acknowledgement"><name>Acknowledgement</name>
<t>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.
</t>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-rtgwg-segment-routing-ti-lfa" to="SR-TI-LFA"/>
<displayreference target="I-D.ietf-teas-ns-ip-mpls" to="NS-IP-MPLS"/>
<displayreference target="I-D.lm-mpls-sfc-path-verification" to="SFP-VERIF"/>
<displayreference target="I-D.stein-srtsn" to="SRTSN"/>
<displayreference target="I-D.zzhang-intarea-generic-delivery-functions" to="GDF"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mpls-mna-fwk.xml"/>
<!-- draft-ietf-mpls-mna-fwk-15 companion document RFC 9789 -->
<reference anchor="RFC9789" target="https://www.rfc-editor.org/info/rfc9789">
<front>
<title>MPLS Network Action (MNA) Framework</title>
<author initials="L." surname="Andersson" fullname="Loa Andersson">
<organization>Huawei Technologies</organization>
</author>
<author initials="S." surname="Bryant" fullname="Stewart Bryant">
<organization>University of Surrey 5GIC</organization>
</author>
<author initials="M." surname="Bocci" fullname="Matthew Bocci">
<organization>Nokia</organization>
</author>
<author initials="T." surname="Li" fullname="Tony Li">
<organization>Juniper Networks</organization>
</author>
<date month="May" year="2025" />
</front>
<seriesInfo name="RFC" value="9789"/>
<seriesInfo name="DOI" value="10.17487/RFC9789"/>
</reference>
</references>
<references title='Informative References'>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9543.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-zzhang-intarea-generic-delivery-functions.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-stein-srtsn.xml"/>
<references>
<name>Informative References</name>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-lm-mpls-sfc-path-verification.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9543.xml"/>
<!-- [I-D.zzhang-intarea-generic-delivery-functions] IESG State: Expired as of 02/06/25; Long Way for author initials-->
<reference anchor="I-D.zzhang-intarea-generic-delivery-functions" target="https://datatracker.ietf.org/doc/html/draft-zzhang-intarea-generic-delivery-functions-03">
<front>
<title>Generic Delivery Functions</title>
<author fullname="Zhaohui (Jeffrey) Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks</organization>
</author>
<author fullname="Ron Bonica" initials="R." surname="Bonica">
<organization>Juniper Networks</organization>
</author>
<author fullname="Kireeti Kompella" initials="K." surname="Kompella">
<organization>Juniper Networks</organization>
</author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization>ZTE</organization>
</author>
<date day="11" month="July" year="2022"/>
<abstract>
<t>
Some functionalities (e.g., fragmentation/reassembly and Encapsulating Security Payload) provided by IPv6 can be viewed as delivery functions independent of IPv6 or even IP entirely. This document proposes to provide those functionalities at different layers (e.g., MPLS, BIER or even Ethernet) independent of IP.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-zzhang-intarea-generic-delivery-functions-03"/>
</reference>
<!-- [I-D.stein-srtsn] IESG State: Expired; Long Way because of author initials -->
<reference anchor="I-D.stein-srtsn" target="https://datatracker.ietf.org/doc/html/draft-stein-srtsn-01">
<front>
<title>Segment Routed Time Sensitive Networking</title>
<author fullname="Yaakov (J) Stein" initials="Y(J)." surname="Stein">
<organization>RAD</organization>
</author>
<date day="29" month="August" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-stein-srtsn-01"/>
</reference>
<!-- [I-D.lm-mpls-sfc-path-verification] IESG State: Expired as of 02/06/25 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-rtgwg-segment-routing-ti-lfa.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.lm-mpls-sfc-path-verification.xml"/>
<!-- [I-D.ietf-rtgwg-segment-routing-ti-lfa] EDIT as of 5/13/25 -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4090.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-segment-routing-ti-lfa.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4090.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7490.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7490.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8595.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8595.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4385.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5085.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4385.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9263.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9263.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9341.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9342.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9341.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8957.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9342.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9613.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8957.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7212.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9613.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7212.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9546.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-ns-ip-mpls.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9546.xml"/>
<!-- [I-D.ietf-teas-ns-ip-mpls] IESG State: Expired as of 02/06/25; Long Way for author initials-->
<reference anchor="I-D.ietf-teas-ns-ip-mpls" target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-ip-mpls-05">
<front>
<title>Realizing Network Slices in IP/MPLS Networks</title>
<author fullname="Tarek Saad" initials="T." surname="Saad">
<organization>Cisco Systems Inc.</organization>
</author>
<author fullname="Vishnu Pavan Beeram" initials="V." surname="Beeram">
<organization>Juniper Networks</organization>
</author>
<author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Joel M. Halpern" initials="J." surname="Halpern">
<organization>Ericsson</organization>
</author>
<author fullname="Shaofu Peng" initials="S." surname="Peng">
<organization>ZTE Corporation</organization>
</author>
<date day="2" month="March" year="2025"/>
<abstract>
<t>
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ns-ip-mpls-05"/>
</reference>
</references>
</references>
<section anchor="futuristic-functions"><name>Use anchor="futuristic-functions">
<name>Use Cases for Continued Discussion</name>
<t>Several use cases for which MNA can provide a viable solution have been discussed.
The discussion of these aspirational cases is ongoing at the time of publication of the document.</t>
<section anchor="generic-delivery-functions"><name>Generic anchor="generic-delivery-functions">
<name>Generic Delivery Functions</name>
<t>The Generic
<t>Generic Delivery Functions (GDFs), defined in
<xref target="I-D.zzhang-intarea-generic-delivery-functions"/>, provide a new mechanism to
support functions analogous to those supported through the IPv6 Extension
Headers mechanism. For example, GDF can support fragmentation/reassembly
functionality in the MPLS network by using the Generic Fragmentation Header.
MNA can support GDF by placing a GDF header in an MPLS packet within the
Post-Stack Data
post-stack data block <xref target="I-D.ietf-mpls-mna-fwk"/>. target="RFC9789"/>. Multiple GDF headers headers, organized as a list of headers, can also
be present in the same MPLS packet organized as a list of headers.</t> packet.</t>
</section>
<section anchor="delay-budgets-for-time-bound-applications"><name>Delay anchor="delay-budgets-for-time-bound-applications">
<name>Delay Budgets for Time-Bound Applications</name>
<t>The routers in a network can perform two distinct functions on incoming
packets, namely
packets: forwarding (where the packet should be sent) and scheduling
(when the packet should be sent). IEEE-802.1 Time Sensitive Time-Sensitive Networking (TSN) and
Deterministic Networking
DetNet provide several mechanisms for scheduling under the
assumption that routers are time-synchronized. The most effective mechanisms
for delay minimization involve per-flow resource allocation.</t>
<t>Segment Routing (SR) is a forwarding paradigm that allows encoding forwarding
instructions in the packet in a stack data structure rather than being
programmed into the routers. The SR instructions are contained within a packet
in the form of a First-in, First-out stack First-In, First-Out stack, dictating the forwarding decisions of
successive routers. 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 influence the queueing of individual packets in each router along that path.</t>
<t>When carried over the MPLS data plane, a solution is required to enable the
delivery of such packets that can be delivered to their final destination within a
given time budget. One approach to address this use case in SR-MPLS was SR over MPLS (SR-MPLS) is
described in <xref target="I-D.stein-srtsn"/>.</t>
</section>
<section anchor="stack-based-methods-for-latency-control"><name>Stack-Based anchor="stack-based-methods-for-latency-control">
<name>Stack-Based Methods for Latency Control</name>
<t>One efficient data structure for inserting local deadlines into
the headers is a "stack", similar to that used in Segment Routing SR to
carry forwarding instructions. The number of deadline values in the
stack equals the number of routers the packet needs to traverse in
the network, and each deadline value corresponds to a specific
router. The Top-of-Stack Top of Stack (ToS) corresponds to the first router's
deadline, while the MPLS BoS refers to the last. All
local deadlines in the stack are later than or equal to the current time
(upon which all routers agree), and times closer to the ToS are
always earlier than or equal to times closer to the MPLS BoS.</t>
<t>The ingress router inserts the deadline stack into the packet headers; no other
router needs to know the requirements of the time-bound flows' requirements. flows.
Hence, admitting a new flow only requires updating the ingress router's information base.</t>
<t>MPLS LSRs that expose the ToS label can also inspect the
associated "deadline" deadline carried in the packet (either in the MPLS stack as In-Stack Data in-stack data or
after BoS as Post-Stack Data).</t> post-stack data).</t>
</section>
</section>
<section anchor="acknowledgement" numbered="false">
<name>Acknowledgements</name>
<t>The authors gratefully acknowledge the input of the members of the
MPLS Open Design Team. Also, the authors sincerely thank <contact
fullname="Loa Andersson"/>, <contact fullname="Xiao Min"/>, <contact
fullname="Jie Dong"/>, and <contact fullname="Yaron Sheffer"/> for their
thoughtful suggestions and help in improving the document.</t>
</section>
<section anchor="contr-sec" numbered="false" toc="default">
<name>Contributors' Addresses</name>
<name>Contributors</name>
<contact fullname="Loa Anderssen" initials="L." surname="Anderssen">
<organization>Bronze Dragon Consulting</organization>
<address>
<email>loa@pi.nu</email>
</address>
</contact>
</section>
</back>
<!-- [rfced] FYI - We lowercased "post-stack data" and "in-stack data" per
usage in RFC-to-be 9789 (ietf-mpls-mna-fwk).
-->
<!-- [rfced] Abbreviations
a) This document uses "Ingress to Edge" as the expansion for I2E, but
RFC-to-be 9789 (ietf-mpls-mna-fwk) and other documents in the RFC Series
use "Ingress to Egress". If no objetions, we will update this document
accordingly.
Current:
Ingress to Edge
Perhaps:
Ingress to Egress
b) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Deterministic Networking (DetNet)
Segment Routing over IPv6 (SRv6)
Segment Routing over MPLS (SR-MPLS)
Service Level Objectives (SLOs)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</rfc>