<?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] 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>
<keyword>Special Purpose Label</keyword>
<keyword>MPLS data plane</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"> newline="true" spacing="normal">
<dt>RFC 9543 Network Slice</dt>
<dd>
<t> is interpreted Slice:</dt>
<dd>Interpreted as defined in <xref target="RFC9543"/>.
Furthermore, this
This document uses "network slice" interchangeably as a
shorter version of the RFC term "RFC 9543 Network Slice term.</t>
</dd>
<dt>The MPLS Slice".</dd>
<dt>MPLS Ancillary Data is (also referred to in this document as "ancillary data"):</dt>
<dd><t>Data that can be classified as:</dt>
<dd>
<t><list style="symbols">
<t>residing as:</t>
<ul spacing="normal">
<li>residing within the MPLS label stack and referred (referred to as In-Stack Data, and</t>
<t>residing "in-stack data"), and</li>
<li>residing after the Bottom of Stack (BoS) and referred (referred to as Post-Stack Data.</t>
</list>
</t> "post-stack data").</li>
</ul>
</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Conventions used in this document</name>
<section anchor="acronyms-and-abbreviations"><name>Acronyms and Abbreviations</name>
<ul empty="true"><li>
<t>MNA: MPLS Network Action</t>
</li></ul>
<ul empty="true"><li>
<t>DEX: Direct Export</t>
</li></ul>
<ul empty="true"><li>
<t>I2E: Ingress to Edge</t>
</li></ul>
<ul empty="true"><li>
<t>HbH: Hop by Hop</t>
</li></ul>
<ul empty="true"><li>
<t>PW: Pseudowire</t>
</li></ul>
<ul empty="true"><li>
<t>BoS: Bottom of Stack</t>
</li></ul>
<ul empty="true"><li>
<t>ToS: Top anchor="acronyms-and-abbreviations">
<name>Abbreviations</name>
<dl spacing="normal" newline="false">
<dt>AMM:</dt><dd>Alternative Marking Method</dd>
<dt>BoS:</dt><dd>Bottom of Stack</t>
</li></ul>
<ul empty="true"><li>
<t>NSH: 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 Stack</dd>
<dt>DEX:</dt><dd>Direct Export</dd>
<dt>eSPL:</dt><dd>extended Special-Purpose Label</dd>
<dt>FRR:</dt><dd>Fast Reroute</dd>
<dt>G-ACh:</dt><dd>Generic Associated Channel</dd>
<dt>HbH:</dt><dd>Hop by Hop</dd>
<dt>I2E:</dt><dd>Ingress to Egress</dd>
<dt>IOAM:</dt><dd>In situ Operations, Administration, and Maintenance</t>
</li></ul>
<ul empty="true"><li>
<t>G-ACh: Generic Associated Channel</t>
</li></ul>
<ul empty="true"><li>
<t>LSP: Label Maintenance</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: Path</dd>
<dt>LSR:</dt><dd>Label Switching Router</dd>
<dt>MNA:</dt><dd>MPLS Network Action</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 Marking Method</t>
</li></ul>
</section> Partition</dd>
<dt>NSH:</dt><dd>Network Service Header</dd>
<dt>PW:</dt><dd>Pseudowire</dd>
<dt>SPL:</dt><dd>Special-Purpose Label</dd>
<dt>ToS:</dt><dd>Top of Stack</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 Egress (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>
<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>
<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> entries.</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>
<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>
<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 the bottom of the label stack BoS 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 7 of "MPLS Network Action (MNA) Framework",
<xref target="I-D.ietf-mpls-mna-fwk"/>
<t><xref target="RFC9789" sectionFormat="of" section="7"/>
outlines security considerations for non-protocol specifying documents. 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 Actions (MNAs) 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>
</rfc>