rfc9791xml2.original.xml   rfc9791.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-mpls-mna-usecases-15" -ietf-mpls-mna-usecases-15" number="9791" consensus="true" updates="" obsoletes=
category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs= "" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRe
"true"> fs="true" version="3" xml:lang="en">
<front>
<title abbrev="MNA Use Cases">Use Cases for MPLS Network Action Indicators a
nd MPLS Ancillary Data</title>
<front>
<title abbrev="MNA Use Cases">Use Cases for MPLS Network Action Indicators
and Ancillary Data</title>
<seriesInfo name="RFC" value="9791"/>
<author initials="T." surname="Saad" fullname="Tarek Saad"> <author initials="T." surname="Saad" fullname="Tarek Saad">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<email>tsaad.net@gmail.com</email> <email>tsaad.net@gmail.com</email>
</address> </address>
</author> </author>
<author initials="K." surname="Makhijani" fullname="Kiran Makhijani"> <author initials="K." surname="Makhijani" fullname="Kiran Makhijani">
<organization>Independent</organization> <organization>Independent</organization>
<address> <address>
<email>kiran.ietf@gmail.com</email> <email>kiran.ietf@gmail.com</email>
skipping to change at line 41 skipping to change at line 40
<address> <address>
<email>haoyu.song@futurewei.com</email> <email>haoyu.song@futurewei.com</email>
</address> </address>
</author> </author>
<author initials="G." surname="Mirsky" fullname="Greg Mirsky"> <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<date year="2025" month="July"/>
<area>RTG</area>
<workgroup>mpls</workgroup>
<date year="2024"/> <keyword>Special Purpose Label</keyword>
<keyword>MPLS data plane</keyword>
<workgroup>MPLS Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>
<t>
This document presents use cases that have a common feature This document presents use cases that have a common feature
that may be addressed by encoding network action indicators that may be addressed by encoding network action indicators
and associated ancillary data within MPLS packets. There is community and associated ancillary data within MPLS packets. There is community
interest in extending the MPLS data plane to carry such indicators interest in extending the MPLS data plane to carry such indicators
and ancillary data to address the use cases that are described and ancillary data to address these use cases.
in this document. </t>
</t> <t>
The use cases described in this document are not an exhaustive set
<t> but rather the ones that have been actively discussed by members of the
The use cases described in this document are not an exhaustive set, IETF MPLS, PALS, and DetNet Working Groups from the beginning of work
but rather the ones that are actively discussed by members of the on MPLS Network Action (MNA) until the publication of this document.
IETF MPLS, PALS, and DetNet working groups from the beginning of work </t>
on the MPLS Network Action until the publication of this document.
</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<section anchor="introduction"><name>Introduction</name> <name>Introduction</name>
<t>This document describes use cases that introduce functions that require
<t>This document describes use cases that introduce functions that require
special processing by forwarding hardware. The current state of the art requires special processing by forwarding hardware. The current state of the art requires
allocating a new special-purpose label (SPL) <xref target="RFC3032"/> or extende allocating a new Special-Purpose Label (SPL) <xref target="RFC3032"/> or Extende
d special-purpose label (eSPL). d Special-Purpose Label (eSPL).
SPLs are a very limited resource, while eSPL requires an extra Label Stack Entry SPLs are a very limited resource, while eSPL requires an extra label stack entry
per Network Action, which is expensive. per network action, which is expensive.
Therefore, an MPLS Network Action (MNA) <xref target="RFC9613"/> approach was pr oposed to extend the MPLS architecture. Therefore, an MPLS Network Action (MNA) <xref target="RFC9613"/> approach was pr oposed to extend the MPLS architecture.
MNA is expected to enable functions that may require carrying additional MNA is expected to enable functions that may require carrying additional
ancillary data within the MPLS packets, as well as a means to indicate the 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 ancillary data is present and a specific action needs to be performed on the
packet.</t> packet.</t>
<t> <t>
This document lists various use cases that could benefit extensively This document lists various use cases that could benefit extensively
from the MNA framework <xref target="I-D.ietf-mpls-mna-fwk"/>. from the MNA framework <xref target="RFC9789"/>.
Supporting a solution of the general MNA framework provides Supporting a solution of the general MNA framework provides
a common foundation for future network actions that can be exercised a common foundation for future network actions that can be exercised
in the MPLS data plane. in the MPLS data plane.
</t> </t>
<section anchor="terminology"><name>Terminology</name> <section anchor="terminology">
<name>Terminology</name>
<t>The following terminology is used in the document:</t> <t>The following terminology is used in the document:</t>
<dl newline="true"> <dl newline="true" spacing="normal">
<dt>RFC 9543 Network Slice</dt> <dt>RFC 9543 Network Slice:</dt>
<dd> <dd>Interpreted as defined in <xref target="RFC9543"/>.
<t> is interpreted as defined in <xref target="RFC9543"/>. This document uses "network slice" interchangeably as a
Furthermore, this document uses "network slice" interchangeably as a shorter ver shorter version of the term "RFC 9543 Network Slice".</dd>
sion <dt>MPLS Ancillary Data (also referred to in this document as "ancilla
of the RFC 9543 Network Slice term.</t> ry data"):</dt>
</dd> <dd><t>Data that can be classified as:</t>
<dt>The MPLS Ancillary Data is classified as:</dt> <ul spacing="normal">
<dd> <li>residing within the MPLS label stack (referred to as "in-stack
<t><list style="symbols"> data"), and</li>
<t>residing within the MPLS label stack and referred to as In-Stack Data, and< <li>residing after the Bottom of Stack (BoS) (referred to as "post
/t> -stack data").</li>
<t>residing after the Bottom of Stack (BoS) and referred to as Post-Stack Data </ul>
.</t> </dd>
</list> </dl>
</t> </section>
</dd> <section anchor="acronyms-and-abbreviations">
</dl>
</section>
<section numbered="true" toc="default">
<name>Conventions used in this document</name>
<section anchor="acronyms-and-abbreviations"><name>Acronyms and Abbreviations</n
ame>
<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 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 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 Switched Path</t>
</li></ul>
<ul empty="true"><li>
<t>LSR: Label Switch Router</t>
</li></ul>
<ul empty="true"><li>
<t>NRP: 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>
</section>
</section>
<section anchor="use-cases"><name>Use Cases</name>
<section anchor="no-further-fastreroute"><name>No Further Fast Reroute</name> <name>Abbreviations</name>
<dl spacing="normal" newline="false">
<dt>AMM:</dt><dd>Alternative Marking Method</dd>
<dt>BoS:</dt><dd>Bottom of 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 Maintenanc
e</dd>
<dt>LSP:</dt><dd>Label Switched 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</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>
<t>MPLS Fast Reroute <xref target="RFC4090"/>, <xref target="RFC5286"/>, <xref t <section anchor="use-cases">
arget="RFC7490"/>, <name>Use Cases</name>
and <xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/> is a useful <section anchor="no-further-fastreroute">
<name>No Further Fast Reroute</name>
<t>MPLS Fast Reroute <xref target="RFC4090"/> <xref target="RFC5286"/> <
xref 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 and widely deployed tool for minimizing packet loss in the case of a link or
node failure.</t> node failure.</t>
<t>Several cases exist where, once a Fast Reroute (FRR) has taken place in an MP LS network and <t>Several cases exist where, once a Fast Reroute (FRR) has taken place in an MP LS network and
a packet is rerouted away from the failure, a second FRR impacts 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> the same packet on another node and may result in traffic disruption.</t>
<t>
<t>
In such a case, the packet impacted by multiple FRR events may continue to loop In such a case, the packet impacted by multiple FRR events may continue to loop
between the label switch routers (LSRs) that activated FRR until the packet's TT L between the Label Switching Routers (LSRs) that activated FRR until the packet's TTL
expires. That can lead to link congestion and further packet loss. expires. That can lead to link congestion and further packet loss.
To avoid that situation, packets that FRR has redirected will be marked using MN A to preclude further FRR processing. To avoid that situation, packets that FRR has redirected will be marked using MN A to preclude further FRR processing.
</t> </t>
</section> </section>
<section anchor="hybrid-pmm-sec">
<section anchor="hybrid-pmm-sec"> <name>Applicability of Hybrid Measurement Methods</name>
<name>Applicability of Hybrid Measurement Methods</name> <t>MNA can be used to carry information essential for collecting operati
<t>MNA can be used to carry information essential for collecting operational inf onal information
ormation
and measuring various performance metrics that reflect the experience of the pac ket marked by MNA. and measuring various performance metrics that reflect the experience of the pac ket marked by MNA.
Optionally, the operational state and telemetry information collected on Optionally, the operational state and telemetry information collected on
the LSR may be transported using MNA techniques.</t> the LSR may be transported using MNA techniques.</t>
<section anchor="in-situ-oam"><name>In-situ OAM</name> <section anchor="in-situ-oam">
<t>In-situ Operations, Administration, and Maintenance (IOAM), <name>In Situ OAM</name>
<t>In situ Operations, Administration, and Maintenance (IOAM),
defined in <xref target="RFC9197"/> and <xref target="RFC9326"/>, might be used to collect 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 operational and telemetry information while a packet traverses a particular path
in a network domain.</t> in a network domain.</t>
<t>IOAM can run in two modes: Ingress to Egress (I2E) and Hop by Hop (
<t>IOAM can run in two modes: Ingress to Edge (I2E) and Hop by Hop (HbH). In I2 HbH). In I2E
E
mode, only the encapsulating and decapsulating nodes will process IOAM data mode, only the encapsulating and decapsulating nodes will process IOAM data
fields. In HbH mode, the encapsulating and decapsulating nodes fields. In HbH mode, the encapsulating and decapsulating nodes
and intermediate IOAM-capable nodes process IOAM data fields. The IOAM data fiel ds, and intermediate IOAM-capable nodes process IOAM data fields. The IOAM data fiel ds,
defined in <xref target="RFC9197"/>, can be used to derive the operational state of the network 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 t he IOAM domain.</t> experienced by the packet with the IOAM Header that traversed the path through t he IOAM domain.</t>
<t>Several IOAM Option-Types have been defined:</t> <t>Several IOAM Option-Types have been defined:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Pre-allocated Trace</t> <t>Pre-allocated Trace</t>
<t>Incremental Trace</t> </li>
<t>Edge-to-Edge</t> <li>
<t>Proof-of-Transit</t> <t>Incremental Trace</t>
<t>Direct Export (DEX)</t> </li>
</list></t> <li>
<t> <t>Edge-to-Edge</t>
With all IOAM Option-Types except for the Direct Export (DEX), the collected </li>
<li>
<t>Proof-of-Transit</t>
</li>
<li>
<t>Direct Export (DEX)</t>
</li>
</ul>
<t>
With all IOAM Option-Types except for Direct Export (DEX), the collected
information is transported in the trigger IOAM packet. information is transported in the trigger IOAM packet.
In the IOAM DEX Option <xref target="RFC9326"/>, the operational state and telem etry information are In the IOAM DEX Option-Type <xref target="RFC9326"/>, the operational state and telemetry information are
collected according to a specified profile and exported in a manner and 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 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 used to trigger the IOAM data to be directly exported or locally aggregated
without being carried in the IOAM trigger packets.</t> without being carried in the IOAM trigger packets.</t>
</section> </section>
<section anchor="ater-mark-sec">
<section anchor="ater-mark-sec"> <name>Alternate Marking Method</name>
<name>Alternate Marking Method</name> <t>
<t> The Alternate Marking Method (AMM), defined in <xref target="RFC9341"/> and <xre
The Alternate Marking Method (AMM), defined in <xref target="RFC9341"/> and <xre f target="RFC9342"/>), is an example
f target="RFC9342"/>) is an example of a hybrid performance measurement method <xref target="RFC7799"/> that can be
of a hybrid performance measurement method (<xref target="RFC7799"/>) that can b used in the MPLS network
e used in the MPLS network to measure packet loss and packet delay performance metrics. <xref target="RFC89
to measure packet loss and packet delay performance metrics. <xref target="RFC89 57"/> defines
57"/> defined
the Synonymous Flow Label framework to realize AMM in the MPLS network. 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. The MNA is an alternative mechanism that can be used to support AMM in the MPLS network.
</t> </t>
</section> </section>
</section> </section>
<section anchor="network-slicing">
<section anchor="network-slicing"><name>Network Slicing</name> <name>Network Slicing</name>
<t>An RFC 9543 Network Slice service (<xref target="RFC9543"/>) <t>An RFC 9543 Network Slice Service <xref target="RFC9543"/>
provides connectivity coupled with network resource commitments and is expressed in terms of one or more 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"/> defines a Network Resource Partition (NRP) Policy connectivity constructs. <xref 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 on e or more network slice services. as a policy construct that enables the instantiation of mechanisms to support on e or more network slice services.
The packets associated with an NRP may carry a The packets associated with an NRP may carry a
marking in their network layer header to identify this association, referred to as an NRP Selector. The NRP Selector maps marking in their network-layer header to identify this association, which is ref erred to as an NRP Selector. The NRP Selector maps
a packet to the associated network resources and provides the a packet to the associated network resources and provides the
corresponding forwarding treatment onto the packet.</t> corresponding forwarding treatment onto the packet.</t>
<t>A router that requires the forwarding of a packet that belongs to an
<t>A router that requires the forwarding of a packet that belongs to an NRP NRP
may have to decide on the forwarding action to take based on selected may have to decide on the forwarding action to take based on selected
next-hop(s), and the forwarding treatment (e.g., scheduling and drop policy) to next hop(s) and decide on the forwarding treatment (e.g., scheduling and drop po licy) to
enforce based on the associated per-hop behavior.</t> enforce based on the associated per-hop behavior.</t>
<t>In this case, routers that forward traffic over a physical link share
<t>In this case, routers that forward traffic over a physical link shared by mul d by multiple
tiple
NRPs need to identify the NRP to which the packet belongs to enforce their respe ctive forwarding actions and treatments.</t> NRPs need to identify the NRP to which the packet belongs to enforce their respe ctive forwarding actions and treatments.</t>
<t>MNA technologies can signal actions for MPLS packets
<t>MNA technologies can signal actions for MPLS packets
and carry data essential for these actions. For example, MNA can carry the NRP S elector <xref target="I-D.ietf-teas-ns-ip-mpls"/> in MPLS packets.</t> and carry data essential for these actions. For example, MNA can carry the NRP S elector <xref target="I-D.ietf-teas-ns-ip-mpls"/> in MPLS packets.</t>
</section>
</section> <section anchor="nsh-based-service-function-chaining">
<name>NSH-Based Service Function Chaining</name>
<section anchor="nsh-based-service-function-chaining"><name>NSH-based Service Fu <t><xref target="RFC8595"/> describes how Service Function Chaining can
nction Chaining</name> be realized in
an MPLS network by emulating the Network Service Header (NSH) <xref target="RFC8
<t><xref target="RFC8595"/> describes how Service Function Chaining can be reali 300"/> using only MPLS label stack entries.</t>
zed in <t>The approach in <xref target="RFC8595"/> introduces some limitations,
an MPLS network by emulating the Network Service Header (NSH) <xref target="RFC8 which are discussed in
300"/> using only MPLS label stack elements.</t> <xref target="I-D.lm-mpls-sfc-path-verification"/>. However, the approach can be
nefit
<t>The approach in <xref target="RFC8595"/> introduces some limitations discusse from the MNA framework introduced in <xref target="RFC9789"/>.</t>
d in <t>MNA can be used to extend NSH emulation using MPLS
<xref target="I-D.lm-mpls-sfc-path-verification"/>. However, that approach can b labels <xref target="RFC8595"/> to support the functionality of NSH Context Head
enefit ers,
from the framework introduced with MNA in <xref target="I-D.ietf-mpls-mna-fwk"/> whether fixed or variable length. For example, MNA could support Flow ID
.</t>
<t>MNA can be used to extend NSH emulation using MPLS
labels <xref target="RFC8595"></xref> to support the functionality of NSH Contex
t Headers,
whether fixed or variable-length. For example, MNA could support Flow ID
<xref target="RFC9263"/> that may be used for load-balancing among <xref target="RFC9263"/> that may be used for load-balancing among
Service Function Forwarders and/or the Service Functions Service Function Forwarders and/or the Service Functions
within the same Service Function Path.</t> within the same Service Function Path.</t>
</section>
</section> <section anchor="network-programming">
<section anchor="network-programming"><name>Network Programming</name> <name>Network Programming</name>
<t>In Segment Routing (SR), an ingress node steers a packet through an o
<t>In Segment Routing (SR), an ingress node steers a packet through an ordered l rdered list of instructions
ist of instructions
called "segments". Each of these instructions represents a called "segments". Each of these instructions represents a
function to be called at a specific location in the network. 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 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 range from simply moving forward in the segment list to any complex
user-defined behavior.</t> user-defined behavior.</t>
<t>Network Programming combines SR functions to achieve a
<t>Network Programming combines SR functions to achieve a
networking objective beyond mere packet routing.</t> networking objective beyond mere packet routing.</t>
<t>Encoding a pointer to a function and its arguments within an MPLS packet tran sport header may be desirable. <t>Encoding a pointer to a function and its arguments within an MPLS packet tran sport header may be desirable.
MNA can be used to encode the FUNC::ARGs to support the functional MNA can be used to encode the FUNC::ARGs to support the functional
equivalent of FUNC::ARG in SRv6 as described in <xref target="RFC8986"/>.</t> equivalent of FUNC::ARG in Segment Routing over IPv6 as described in <xref targe
t="RFC8986"/>.</t>
</section> </section>
</section> </section>
<section anchor="existing-mpls-use-cases"><name>Co-existence with the Existing M <section anchor="existing-mpls-use-cases">
PLS Services Using Post-Stack Headers</name> <name>Coexistence with the Existing MPLS Services Using Post-Stack Headers
</name>
<t>Several services can be transported over MPLS networks today. <t>Several services can be transported over MPLS networks today.
These include providing Layer-3 (L3) connectivity (e.g., for unicast and These include providing Layer 3 (L3) connectivity (e.g., for unicast and
multicast L3 services), and Layer-2 (L2) connectivity (e.g., for unicast multicast L3 services) and Layer 2 (L2) connectivity (e.g., for unicast
Pseudowires (PWs), multicast E-Tree, and broadcast E-LAN L2 services). In PWs, multicast E-Tree, and broadcast Ethernet LAN (E-LAN) L2 services). In
those cases, the user service traffic is encapsulated as the payload in MPLS pac kets.</t> those cases, the user service traffic is encapsulated as the payload in MPLS pac kets.</t>
<t>For L2 service traffic, it is possible to use a Control Word (CW) <xref
<t>For L2 service traffic, it is possible to use Control Word (CW) <xref target= target="RFC4385"/>
"RFC4385"/> and
<xref target="RFC5085"/> immediately after the MPLS header to disambiguate the t ype of MPLS payload, <xref target="RFC5085"/> immediately after the MPLS header to disambiguate the t ype of MPLS payload,
prevent possible packet misordering, and allow for fragmentation. In this case, prevent possible packet misordering, and allow for fragmentation. In this case,
the first nibble the data that immediately follows after the MPLS BoS is the first nibble of the data that immediately follows the MPLS BoS is
set to 0b0000 to identify the presence of PW CW.</t> set to 0b0000 to identify the presence of the PW CW.</t>
<t>In addition to providing connectivity to user traffic, MPLS may also tr
<t>In addition to providing connectivity to user traffic, MPLS may also transpor ansport OAM
t OAM
data (e.g., over MPLS Generic Associated Channels (G-AChs) <xref target="RFC558 6"/>). In this case, the first nibble of data (e.g., over MPLS Generic Associated Channels (G-AChs) <xref target="RFC558 6"/>). In this case, the first nibble of
the data that immediately follows after the MPLS BoS is set to 0b0001. It the data that immediately follows the MPLS BoS is set to 0b0001. It
indicates the presence of a control channel associated with a PW, LSP, or Sectio indicates the presence of a control channel associated with a PW, LSP, or sectio
n.</t> n.</t>
<t>Bit Index Explicit Replication (BIER) <xref target="RFC8296"/> traffic can al so be encapsulated <t>Bit Index Explicit Replication (BIER) <xref target="RFC8296"/> traffic can al so be encapsulated
over MPLS. In this case, BIER has defined 0b0101 as the value for the first nibb le over MPLS. In this case, BIER has defined 0b0101 as the value for the first nibb le
in the data that immediately appears after the bottom of the label stack for any of the data that immediately appears after the BoS for any
BIER-encapsulated packet over MPLS.</t> BIER-encapsulated packet over MPLS.</t>
<t>For PWs, the G-ACh <xref target="RFC7212"/> uses the first four bits of
<t>For pseudowires, the Generic Associated Channel <xref target="RFC7212"/> uses the PW control word
the first four bits of the PW control to provide the initial discrimination between data packets and
word to provide the initial discrimination between data packets and
packets belonging to the associated channel, as described in packets belonging to the associated channel, as described in
<xref target="RFC4385"></xref>.</t> <xref target="RFC4385"/>.</t>
<t>MPLS can be used as the data plane for DetNet <xref target="RFC8655"/>. <t>MPLS can be used as the data plane for Deterministic Networking (DetNet ) <xref target="RFC8655"/>.
The DetNet sub-layers, forwarding, and service The DetNet sub-layers, forwarding, and service
are realized using the MPLS label stack, the DetNet Control Word <xref target=" RFC8964"/>, are realized using the MPLS label stack, the DetNet control word <xref target=" RFC8964"/>,
and the DetNet Associated Channel Header <xref target="RFC9546"/>.</t> and the DetNet Associated Channel Header <xref target="RFC9546"/>.</t>
<t>MNA-based solutions for the use cases described in this document and pr
<t>MNA-based solutions for the use cases described in this document and proposed oposed
in the future are expected to allow for coexistence and backward compatibility w ith all existing MPLS services.</t> in the future are expected to allow for coexistence and backward compatibility w ith all existing MPLS services.</t>
</section>
</section> <section anchor="co-existence-of-usecases">
<section anchor="co-existence-of-usecases"><name>Co-existence of the MNA Use Cas <name>Coexistence of the MNA Use Cases</name>
es</name> <t>Two or more of the discussed cases may coexist in the same packet.
<t>Two or more of the discussed cases may co-exist in the same packet.
That may require the presence of multiple ancillary data That may require the presence of multiple ancillary data
(whether In-stack or Post-stack ancillary data) to be present in the same MPLS p (whether in-stack or post-stack ancillary data) to be present in the same MPLS p
acket.</t> acket.</t>
<t>For example, IOAM may provide essential functions along with network sl
<t>For example, IOAM may provide essential functions along with network slicing icing to help
to help ensure that critical network slice Service Level Objectives (SLOs) are being met
ensure that critical network slice SLOs are being met by the network provider. by the network provider.
In this case, IOAM can collect key performance measurement parameters of In this case, IOAM can collect key performance measurement parameters of a
network slice traffic flow as it traverses the transport network.</t> network slice traffic flow as it traverses the transport network.</t>
</section>
</section> <section anchor="iana-considerations">
<section anchor="iana-considerations"><name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<t>This document has no IANA actions.</t> </section>
<section anchor="security-considerations">
</section> <name>Security Considerations</name>
<section anchor="security-considerations"><name>Security Considerations</name> <t><xref target="RFC9789" sectionFormat="of" section="7"/>
outlines security considerations for documents that do not specify protocols.
<t>Section 7 of "MPLS Network Action (MNA) Framework",
<xref target="I-D.ietf-mpls-mna-fwk"/> outlines security considerations for non-
protocol specifying documents.
The authors have verified that these considerations are fully applicable to this document. The authors have verified that these considerations are fully applicable to this document.
</t> </t>
<t> <t>
In-depth security analysis for each specific use case is beyond the scope of thi s document In-depth security analysis for each specific use case is beyond the scope of thi s document
and will be addressed in future solution documents. It is strongly recommended and will be addressed in future solution documents. It is strongly recommended
that these solution documents undergo security expert review early in their deve lopment, that these solution documents undergo review by a security expert early in their development,
ideally during the Working Group Last Call phase. ideally during the Working Group Last Call phase.
</t> </t>
</section>
</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> </middle>
<back> <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> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mpls-mna-f <!-- draft-ietf-mpls-mna-fwk-15 companion document RFC 9789 -->
wk.xml"/> <reference anchor="RFC9789" target="https://www.rfc-editor.org/info/rfc9789">
</references> <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="July" year="2025" />
</front>
<seriesInfo name="RFC" value="9789"/>
<seriesInfo name="DOI" value="10.17487/RFC9789"/>
</reference>
<references title='Informative References'> </references>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9543. <references>
xml"/> <name>Informative References</name>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-zzhang-intarea- <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
generic-delivery-functions.xml"/> 543.xml"/>
<!-- [I-D.zzhang-intarea-generic-delivery-functions] IESG State: Expired; Long W
ay 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 IPv
6 or even IP entirely. This document proposes to provide those functionalities a
t 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-f
unctions-03"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-stein-srtsn.xml <!-- [I-D.stein-srtsn] IESG State: Expired; Long Way because of author initials
"/> -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-lm-mpls-sfc-pat <reference anchor="I-D.stein-srtsn" target="https://datatracker.ietf.org/doc/htm
h-verification.xml"/> l/draft-stein-srtsn-01">
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-rtgwg-segm <front>
ent-routing-ti-lfa.xml"/> <title>Segment Routed Time Sensitive Networking</title>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4090 <author fullname="Yaakov (J) Stein" initials="Y(J)." surname="Stein">
.xml"/> <organization>RAD</organization>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5286. </author>
xml"/> <date day="29" month="August" year="2021"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7490. </front>
xml"/> <seriesInfo name="Internet-Draft" value="draft-stein-srtsn-01"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9197. </reference>
xml"/> <!-- [I-D.lm-mpls-sfc-path-verification] IESG State: Expired as of 02/06/25; Lov
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9326. e Way because of author name -->
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8595.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8986.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4385.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5085.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5586.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8296.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9263.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7799.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9341.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9342.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8957.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9613.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7212. <reference anchor="I-D.lm-mpls-sfc-path-verification" target="https://datatracke
xml"/> r.ietf.org/doc/html/draft-lm-mpls-sfc-path-verification-03">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655. <front>
xml"/> <title>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8964. MPLS-based Service Function Path(SFP) Consistency Verification
xml"/> </title>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9546. <author fullname="Yao Liu" initials="Y." surname="Liu">
xml"/> <organization>ZTE</organization>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-ns-ip </author>
-mpls.xml"/> <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
</references> <organization>Ericsson</organization>
</references> </author>
<date day="11" month="June" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-lm-mpls-sfc-path-verification-03"
/>
</reference>
<!-- [I-D.ietf-rtgwg-segment-routing-ti-lfa] EDIT as of 7/2/25 -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-rtgwg-segment-routing-ti-lfa.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
090.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
286.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
490.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
197.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
326.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
595.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
385.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
085.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
586.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
263.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
799.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
342.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
957.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
613.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
212.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
655.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
964.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
546.xml"/>
<!-- [I-D.ietf-teas-ns-ip-mpls] IESG State: I-D Exists; Long Way for author init
ials-->
<reference anchor="I-D.ietf-teas-ns-ip-mpls" target="https://datatracker.ietf.or
g/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, s
tructures, and functions so that each slice can be dedicated to specific service
s or customers. Multiple network slices can be realized on the same network whil
e ensuring slice elasticity in terms of network resource allocation. This docume
nt 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 o
n compliant domains and nodes to provide forwarding treatment (scheduling, drop
policy, resource usage) on to packets that carry identifiers that indicate the s
licing 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>
<section anchor="futuristic-functions"><name>Use Cases for Continued Discussion< </references>
/name> </references>
<t>Several use cases for which MNA can provide a viable solution have been discu <section anchor="futuristic-functions">
ssed. <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> The discussion of these aspirational cases is ongoing at the time of publication of the document.</t>
<section anchor="generic-delivery-functions">
<name>Generic Delivery Functions</name>
<section anchor="generic-delivery-functions"><name>Generic Delivery Functions</n <t>Generic Delivery Functions (GDFs), defined in
ame>
<t>The Generic Delivery Functions (GDFs), defined in
<xref target="I-D.zzhang-intarea-generic-delivery-functions"/>, provide a new me chanism to <xref target="I-D.zzhang-intarea-generic-delivery-functions"/>, provide a new me chanism to
support functions analogous to those supported through the IPv6 Extension support functions analogous to those supported through the IPv6 Extension
Headers mechanism. For example, GDF can support fragmentation/reassembly Headers mechanism. For example, GDF can support fragmentation/reassembly
functionality in the MPLS network by using the Generic Fragmentation Header. 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 MNA can support GDF by placing a GDF header in an MPLS packet within the
Post-Stack Data block <xref target="I-D.ietf-mpls-mna-fwk"/>. Multiple GDF heade post-stack data block <xref target="RFC9789"/>. Multiple GDF headers, organized
rs can also as a list of headers, can also
be present in the same MPLS packet organized as a list of headers.</t> be present in the same MPLS packet.</t>
</section>
</section> <section anchor="delay-budgets-for-time-bound-applications">
<name>Delay Budgets for Time-Bound Applications</name>
<section anchor="delay-budgets-for-time-bound-applications"><name>Delay Budgets <t>The routers in a network can perform two distinct functions on incomi
for Time-Bound Applications</name> ng
packets: forwarding (where the packet should be sent) and scheduling
<t>The routers in a network can perform two distinct functions on incoming (when the packet should be sent). IEEE-802.1 Time-Sensitive Networking (TSN) and
packets, namely forwarding (where the packet should be sent) and scheduling DetNet provide several mechanisms for scheduling under the
(when the packet should be sent). IEEE-802.1 Time Sensitive Networking (TSN) and
Deterministic Networking provide several mechanisms for scheduling under the
assumption that routers are time-synchronized. The most effective mechanisms assumption that routers are time-synchronized. The most effective mechanisms
for delay minimization involve per-flow resource allocation.</t> for delay minimization involve per-flow resource allocation.</t>
<t>Segment Routing (SR) is a forwarding paradigm that allows encoding forwarding <t>Segment Routing (SR) is a forwarding paradigm that allows encoding forwarding
instructions in the packet in a stack data structure rather than being instructions in the packet in a stack data structure rather than being
programmed into the routers. The SR instructions are contained within a packet programmed into the routers. The SR instructions are contained within a packet
in the form of a First-in, First-out stack dictating the forwarding decisions of in the form of a First-In, First-Out stack, dictating the forwarding decisions o f
successive routers. Segment routing may be used to choose a path sufficiently 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 short to be capable of providing bounded end-to-end latency but does
not influence the queueing of individual packets in each router along that path. </t> 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 enab
<t>When carried over the MPLS data plane, a solution is required to enable the le the
delivery of such packets that can be delivered to their final destination within delivery of such packets to their final destination within a
a given time budget. One approach to address this use case in SR over MPLS (SR-MPL
given time budget. One approach to address this use case in SR-MPLS was S) is
described in <xref target="I-D.stein-srtsn"/>.</t> described in <xref target="I-D.stein-srtsn"/>.</t>
</section>
</section> <section anchor="stack-based-methods-for-latency-control">
<name>Stack-Based Methods for Latency Control</name>
<section anchor="stack-based-methods-for-latency-control"><name>Stack-Based Meth <t>One efficient data structure for inserting local deadlines into
ods for Latency Control</name> the headers is a "stack", similar to that used in SR to
<t>One efficient data structure for inserting local deadlines into
the headers is a "stack", similar to that used in Segment Routing to
carry forwarding instructions. The number of deadline values in the carry forwarding instructions. The number of deadline values in the
stack equals the number of routers the packet needs to traverse in stack equals the number of routers the packet needs to traverse in
the network, and each deadline value corresponds to a specific the network, and each deadline value corresponds to a specific
router. The Top-of-Stack (ToS) corresponds to the first router's router. The Top of Stack (ToS) corresponds to the first router's
deadline, while the MPLS BoS refers to the last. All deadline, while the MPLS BoS refers to the last. All
local deadlines in the stack are later or equal to the current time 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 (upon which all routers agree), and times closer to the ToS are
always earlier or equal to times closer to the MPLS BoS.</t> 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
<t>The ingress router inserts the deadline stack into the packet headers; no oth ; no other
er router needs to know the requirements of the time-bound flows.
router needs to know the time-bound flows' requirements.
Hence, admitting a new flow only requires updating the ingress router's informat ion base.</t> Hence, admitting a new flow only requires updating the ingress router's informat ion base.</t>
<t>MPLS LSRs that expose the ToS label can also inspect the
<t>MPLS LSRs that expose the ToS label can also inspect the associated deadline carried in the packet (either in the MPLS stack as in-stack
associated "deadline" carried in the packet (either in the MPLS stack as In-Stac data or
k Data or after BoS as post-stack data).</t>
after BoS as Post-Stack Data).</t> </section>
</section> </section>
</section> <section anchor="acknowledgement" numbered="false">
<name>Acknowledgements</name>
<section anchor="contr-sec" numbered="false" toc="default"> <t>The authors gratefully acknowledge the input of the members of the
<name>Contributors' Addresses</name> MPLS Open Design Team. Also, the authors sincerely thank <contact
fullname="Loa Andersson"/>, <contact fullname="Xiao Min"/>, <contact
<contact fullname="Loa Anderssen" initials="L." surname="Anderssen"> fullname="Jie Dong"/>, and <contact fullname="Yaron Sheffer"/> for their
<organization>Bronze Dragon Consulting</organization> thoughtful suggestions and help in improving the document.</t>
<address> </section>
<email>loa@pi.nu</email> <section anchor="contr-sec" numbered="false" toc="default">
</address> <name>Contributors</name>
</contact> <contact fullname="Loa Anderssen" initials="L." surname="Anderssen">
<organization>Bronze Dragon Consulting</organization>
<address>
<email>loa@pi.nu</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 75 change blocks. 
430 lines changed or deleted 459 lines changed or added

This html diff was produced by rfcdiff 1.48.