<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8964 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml">
<!ENTITY RFC3031 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC8655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml">
<!ENTITY RFC8938 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml">
<!ENTITY RFC9055 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml">
<!ENTITY RFC9320 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9320.xml">
<!ENTITY I-D.ietf-mpls-mna-hdr SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-mna-hdr.xml">
<!ENTITY I-D.ietf-mpls-mna-usecases SYSTEM "https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mpls-mna-usecases-10.xml">
<!ENTITY I-D.ietf-mpls-mna-requirements SYSTEM "https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mpls-mna-requirements-16.xml">
<!ENTITY I-D.ietf-mpls-mna-fwk SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-mna-fwk.xml">
<!ENTITY I-D.ietf-detnet-scaling-requirements SYSTEM "https://datatracker.ietf.org/doc/bibxml3/draft-ietf-detnet-scaling-requirements-06.xml">
<!ENTITY I-D.ietf-detnet-dataplane-taxonomy SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-detnet-dataplane-taxonomy.xml">
<!ENTITY I-D.stein-srtsn SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.stein-srtsn.xml">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-sxg-mpls-mna-deterministic-latency-01" consensus="true" submissionType="IETF" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 -->
  <front>
    <title abbrev="MNA for Deterministic Latency"> MPLS Network Action for Deterministic Latency
    </title>
    <seriesInfo name="Internet-Draft" value="draft-sxg-mpls-mna-deterministic-latency-01"/>
    <author fullname="Xueyan Song" initials="X." surname="Song">
      <organization>ZTE Corp.</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city/>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>song.xueyan2@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <author fullname="Quan Xiong" initials="Q." surname="Xiong">
      <organization>ZTE Corp.</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city/>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone/>
        <email>xiong.quan@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city/>
          <region/>
          <code/>
          <country>Canada</country>
        </postal>
        <phone/>
        <email>rgandhi@cisco.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <date month="July" day="21" year="2024"/>
    <area>Routing</area>
    <workgroup>MPLS Working Group</workgroup>
    <keyword>Request for Comments</keyword>
    <keyword>RFC</keyword>
    <keyword>Internet Draft</keyword>
    <keyword>I-D</keyword>
    <abstract>
       <t>  This document specifies formats and principles for the MPLS Network Action for Deterministic Latency 
    to provide guaranteed latency services. They are used to make scheduling decisions
    for time-sensitive services running on Deterministic Network (DetNet) nodes that operate within a single or multiple domains.</t>
    </abstract>
  </front>
  <middle>
    <section>
      <name>Introduction</name>
      <t> <xref target="RFC8655"/> defines Deterministic Network (DetNet) architecture.
      The overall framework for DetNet data plane is introduced in <xref target="RFC8938"/>.
      Deterministic Networking 
   (DetNet) operates at the IP layer and delivers services with low data loss rates and bounded latency guarantee within a network domain. </t>

      <t> <xref target="RFC8964"/> introduces the DetNet MPLS data plane technology, providing a foundation of building 
  blocks to enable PREOF (Packet Replication, Elimination and Ordering Functions (PREOF)) functions to the DetNet service sub-layer and forwarding sub-layer. 
  The DetNet service sub-layer includes a DetNet Control Word (d-CW), service label (S-Label), and aggregation label (A-Label) in special case of 
  S-Label used for aggregation. The DetNet forwarding sub-layer supports one or more forwarding labels (F-Labels) to forward a DetNet flow 
  over MPLS domains. The DetNet forwarding sub-layer provides corresponding forwarding assurance with resource allocations and 
  explicit routes. </t>

      <t> To support time-sensitive services with ultra-low loss rates and deterministic latency, feasible scheduling mechanisms must be applied to specific 
	applications for deterministic networking. As described in <xref target="RFC9320"/>, the end-to-end bounded latency is the sum of non-queuing 
	and queuing delay bounds along with the queuing mechanisms. </t>

      <t> The queuing mechanisms, as mentioned in <xref target="RFC9320"/> and <xref target="RFC8655"/>, which include Time Aware Shaping IEEE802.1Qbv, 
 Asynchronous Traffic Shaping IEEE802.1Qcr, cyclic-scheduling queuing mechanism proposed in IEEE802.1Qch. In terms of delay guarantee for different 
 applications, selecting the right scheduling/queuing mechanism applied to a specific application is required. Based on the existing DetNet MPLS 
 encapsulations and mechanisms <xref target="RFC8964"/>, the document defines the encoding format for the Deterministic Latency Network Action (DLNA) option
 in the MPLS data plane.</t>

      <t> But with DetNet network scaling up or flows number increased in the same work, some enhanced data plane requirements for DetNet network are brought, 
  which are described at the <xref target="I-D.ietf-detnet-scaling-requirements"/>. This document follows the enhanced data plane requirements and introduces the MPLS Network Actions (MNA) 
  solution to address the requirements specified in section 4.2 of <xref target="I-D.ietf-detnet-scaling-requirements"/>. The deterministic network should support synchronized 
  or asynchronized queuing mechanisms. Different queuing mechanisms require different information to be defined as the DetNet-specific metadata to help ensure deterministic latency, 
  including regulation, queue management, etc.</t>

      <t> The use case Delay Budgets for Time Bound Applications are under discussion in the MPLS MNA <xref target="I-D.ietf-mpls-mna-usecases"/> document. MPLS Network Actions (MNA) 
  indicate actions for LSPs and/or MPLS packets and transfer data needed for these actions. <xref target="I-D.ietf-mpls-mna-hdr"/> defined the MNA solution 
  for carrying Network Actions with Sub-Stack Data and associated Ancillary Data (AD) (i.e., in the MPLS label stack).</t>

      <t> This document presents one MPLS MNA solution for Deterministic Latency. It follows the MPLS MNA requirements specified at <xref target="I-D.ietf-mpls-mna-requirements"/> and 
  MPLS MNA header specifid at <xref target="I-D.ietf-mpls-mna-hdr"/> to support basic DetNet service and DetNet service with enhanced DetNet data plane requirements specified at 
  <xref target="I-D.ietf-detnet-scaling-requirements"/> .</t>

    </section>
    <section>
      <name>Conventions</name>
      <section>
        <name>Requirements Language</name>
        <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", 
    "NOT RECOMMENDED", "MAY", and   "OPTIONAL" in this document are to be interpreted as described in BCP 14 
    <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
      </section>
      <section>
        <name>Terminology</name>

    <t> Refer to <xref target="RFC8655"/>, <xref target="RFC8964"/>, <xref target="I-D.ietf-mpls-mna-hdr"/>, <xref target="I-D.ietf-mpls-mna-fwk"/>, <xref target="I-D.ietf-mpls-mna-requirements"/>
	and <xref target="RFC9320"/> for the key terms used in this document.</t>
    <t> Deterministic Latency (DL):  The ability to precisely determine the delay in the network from source to destination(s). The delay is variable and depends on the queuing mechanisms used for network 
	flows and the operations of the network nodes. The delay variation is acceptable but should be bounded and measurable.</t> 
    <t> Deterministic Latency Network Action (DLNA): Used to indicate deterministic latency network action for MPLS data plane.</t>

      </section>
    </section>
    <section>
      <name>Enhanced Deterministic Network Requirements</name>
      <section>
        <name>Queuing Delay</name>
        <t> <xref target="RFC8655"/> provides the architecture for deterministic networking (DetNet), which enables the service delivery of DetNet flows with extremely
     low packet loss rates and deterministic latency. The forwarding sub-layer provides corresponding forwarding assurance but can not provide the deterministic latency 
     (including bounded latency, low packet loss and in-order delivery). As described at <xref target="RFC9320"/>, the end-to-end bounded latency 
     for one DetNet flow is the sum of the delay bound of non-queuing and queuing processing latency. The delay bound for non-queuing processing may include output delay, 
     link delay, frame preemption delay, and processing delay, the delay bound for queuing processing may include regulator delay, queuing delay. It is assumed that the 
     delay of non-queuing processing is fixed or be ignorable, the delay of queuing processing is variable. To realize the guarantee of bounded latency service, it is important 
     to select the right queuing methodology applied to specific applications and carry necessary queuing delay information for the computation of end-to-end latency. </t>

        <t> The existing switches and routers have the ability to classify traffic and provide independent queuing mechanisms based on Class of Service (CoS) that CoS is used in 
     the Priority Code Point (PCP) field of the 802.1Q, DSCP field in IPv4 header and Traffic Class field in IPv6 field. CoS defines the priority levels of traffic and QoS uses
     these CoS values to handle traffic to optimize traffic transmission. To achieve deterministic/bounded latency service requirements, the queuing mechanisms, as mentioned 
     in <xref target="RFC9320"/> and <xref target="RFC8655"/>, Time Aware Shaping IEEE802.1Qbv, Asynchronous Traffic Shaping IEEE802.1Qcr, cyclic-scheduling queuing mechanism
     proposed in IEEE802.1Qc are used in single or multiple domains network. </t>
      </section>

      <section>
        <name>Deterministic Latency</name>
        <t> The DetNet data plane encapsulation in the transport network using the MPLS data plane is specified in <xref target="RFC8964"/>. 
     A deterministic latency option is required to address the DetNet scaling question and support the enhanced data plane requirements described at <xref target="I-D.ietf-detnet-scaling-requirements"/>. The option
     should include end-to-end and hop-by-hop processing of packets to be adaptive to different queuing mechanisms in DetNet networks.</t>

        <t> The DetNet routers in the data plane perform MPLS forwarding functions using a feasible way with sufficient network resources for the incoming packets 
     and make the right selection on the queuing or scheduling mechanisms applied for specific DetNet flows to satisfy strict deterministic service criteria in the forwarding output port.
     The queuing or scheduling mechanism information is carried in the MPLS header. Refer to <xref target="I-D.stein-srtsn"/>, considering the time latency 
     information is processed per hop so that the time latency information (such as deadline time, cycle identify, etc.) of each DetNet node for DetNet flows is expected 
     to be carried as a set of lists of LSEs in MPLS data plane. </t>
      </section>
    </section>

    <section>
      <name> MPLS Extensions for Deterministic Latency</name>
        <t> This document provides an optional MNA header to address enhanced DetNet data plane requirements described at <xref target="I-D.ietf-detnet-scaling-requirements"/> to 
        support different deterministic service categories such as bandwidth guarantee, bounded latency, loss ratio guarantee, etc.</t>

      <section>
        <name>Enhanced DetNet MPLS Header for Deterministic Latency</name>
        <t> To support deterministic bounded latency service, this document introduces an MNA option for Deterministic Latency Network Action (DLNA). As shown in Figure 1, the MNA label is 
		inserted to indicate the presence of MPLS Network Actions. The format for DLNA follows the DetNet data plane MPLS encapsulation specified at <xref target="RFC8964"/> and MNA encapsulation specified in <xref target="I-D.ietf-mpls-mna-hdr"/> and <xref target="I-D.ietf-mpls-mna-fwk"/>, which is comprised of a set of Label 
Stack Entries (LSEs) that carry the DLNA Indicator and Ancillary Data to perform DLNA actions for MPLS packets. </t>
        <figure anchor="Figure_1">
          <name>Enhanced DetNet MPLS Header for Deterministic Latency</name>
          <artwork align="center"><![CDATA[          
+---------------------------+
|       DetNet App-Flow     |
|       Payload Packet      |
+---------------------------+--\ 
|     DetNet Control Word   |   | 
+---------------------------+<--|-- Bottom of Stack
|          S-Label          |   |    
+---------------------------+   | DetNet
|          DLNA             |   | Data Plane
+---------------------------+   | MPLS Encapsulation    
|          MNA Label        |   |  
+---------------------------+   | 
|          F-Label(s)       |   /
+---------------------------+<-/--- Top of Stack
|          Data-Link        |
+---------------------------+
|          Physical         |
+---------------------------+                    
]]></artwork>
        </figure>

     <t> As defined in  <xref target="RFC8964"/>, the DetNet functionality PREOF (Packet Replication, Elimination and Ordering Functions) is supported through d-CW,S-label and F-label. 
      The queue mechanism for DetNet networks
      is expected to use the existing COS mechanism, such as PCP for VLAN, DSCP for IPv4, Traffic Class for IPv6. The S-lable is at the bottom of MPLS label stack and is normally followed by d-CW (DetNet Control-Word, i.e., sequence number). 
      The S-label is used to identify DetNet service-type. F-lable(s) identify explicit route and allocated resources for DetNet nodes, the route schedule and resource reservation are achieved via provision by the controller. 
      D-CW (i.e., sequence number) is used for the ordering function of DetNet packets. To support backward compatibility, the aspects (DetNet d-CW, S-label, F-label and A-label) are kept shown in MPLS sub-stack but 
       outside of MPLS MNA sub-stack. The base DetNet data plane MPLS encapsulation follows specification at <xref target="RFC8964"/>. 
        For base DetNet services, it's assumed that the requirements can be satisfied via deploying CoS mechanisms (i.e., PCP for VLAN, DSCP for IPv4 and Traffic Class for IPv6) to DetNet network nodes. 
       </t>

    <t>For enhanced DetNet services, enhanced queuing mechanisms are expected to be deployed, and the queueing information may be carried in data packets.
      The enhanced DetNet data plane 
      requirements are specified in <xref target="I-D.ietf-detnet-scaling-requirements"/>. To support enhanced deterministic services, strict queuing technologies may be required for DetNet devices. Its related latency requirements
      may involve different categories: (1) Industrial, tight jitter, strict latency limit; (2) Industrial, strict latency limit; (3) Non-periodic, relatively loose latency requirements; (4) Best effort. And different
      network implementations require different SLA requirements with different queueing mechanisms implemented in single or multiple network domains. </t>

      </section>

      <section>
        <name>Deterministic Latency Network Action</name>
        <t> The Deterministic Latency Network Action Sub-Stack format for MNA is shown in Figure 2. The network action follows LSE format C to carry DLNA Opcode and LSE format D for Additional Data as specified in <xref target="I-D.ietf-mpls-mna-hdr"/>. </t>

        <figure anchor="Figure_2">
          <name>DLNA Sub-Stack </name>
          <artwork align="left"><![CDATA[ 
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |                         |R|IHS|S|U|  NASL | NAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLNA Opcode |   Reserved          |DLNA Flag|S|U| Res   | NAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|               Deterministic Latency Data  |S|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|               Deterministic Latency Data  |S|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t> As specified in <xref target="I-D.ietf-mpls-mna-hdr"/>, The header for MPLS Sub-Stack Network Action encodes: </t>   
        <t> R (1 bit) : Reserved bit.  This MUST be transmitted as zero and ignored upon receipt.</t> 
        <t> IHS (2 bits) : The processing scope of the sub-stack. The IHS scope values refer to <xref target="I-D.ietf-mpls-mna-hdr"/>. The filed is set as 00 for End-to-End processing and 01 for Hop-By-Hop processing.</t>   
        <t> S (1 bit) : The Bottom of Stack [RFC3032].</t> 
        <t> Res (3 bits) : Reserved bits.  These MUST be transmitted as zeros and ignored upon receipt.</t> 
        <t> U (1 bit): Unknown Action Handling. This field MUST be transmited as zero and ignore upon receipt.</t>   
        <t> NASL (4 bits) : The Network Action Sub-Stack Length (NASL).  The number of additional LSEs in the sub-stack, not including the
      leading Format A LSE and the Format B LSE.</t> 
        <t> DLNA Opcode (7 bits): This is the first 7-bit value in the Label Field. The value is used to indicate DLNA network action with Data and to be assigned  by IANA as value TBA1. </t>
        <t> DLNA Flags (5 bits): A bit map that specifies the type of enhanced Deterministic latency.  The supported Deterministic latency type is listed in
      Table 1.</t>
      <table anchor="Table_1">
        <name>Deterministic Latency Type</name>
        <thead>
          <tr>
            <th align="left">Bit</th>
            <th align="left">Deterministic Latency Type</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0</td>
            <td align="left">Reserved</td>
          </tr>
          <tr>
            <td align="left">1</td>
            <td align="left">Latency Bound</td>
          </tr>
          <tr>
            <td align="left">2</td>
            <td align="left">Queuing Delay Bound</td>
          </tr>
        </tbody>
      </table>

        <t> Deterministic Latency Data (60 bits): The ancillary data LSEs for the Deterministic Latency Type. </t>
        <t> The ancillary data carried in Format D LSE is not mandatory. In common DetNet scenario (i.e., not network topo at scale or network flows at scale), the traditional mechanisms such 
		as DSCP and Traffic Class are used for queue processing. The basic DetNet functionality PREOF (Packet Replication, Elimination and Ordering Functions) is supported through sequence number 
		and S-label and the aggregated flow function is supported via MPLS A-label. In this case, the DLNA is assumed to be the only MNA data carried in LSE format B. The value for Opcode in 
		Format B LSE will be set as 2 and not perform the DLNA network action. </t>
		
        <t> The Deterministic Latency Data speicification refers to <xref target="RFC9320"/> and <xref target="I-D.ietf-detnet-dataplane-taxonomy"/>, which introduces DetNet Bounded Latency Model. 
        To support deterministic latency services the latency variation across the DetNet-aware or DetNet-unaware islands should be bounded and computable. The Deterministic Latency Bound of 
        End-to-End and each nodes along with the DetNet flows should be included. It is important to select the right queuing method applied to specific applications and carry necessary queuing 
		delay information in data plane. The End-to-End latency and jitter information (e.g., deadline, timestamp, etc.) and hop-by-hop queuing information (e.g., cycle, queuing method, etc.) should 
		be carried. And network delay is related to network topology scale and network flows scale, hop counts for delay assessment is an important factor. The possible parameters for ancillary data 
		carried in Format D LSE is showed as Figure 3.</t>	
        <figure anchor="Figure_3">
          <name>Ancillary Data Format</name>
          <artwork align="center"><![CDATA[   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|               Queuing_method              |S|  Hop_count    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|                 Timestamp                 |S|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
		
		<t> Packet-by-packet load-sharing e.g., via ECMP is not utilized in DETNET <xref target="RFC8938"/>, Section 3.5.1.5, hence timestamp can be added in In-Stack Data as label stack will not be used for hashing. </t>
	  </section>

    </section>

    <section>
      <name>IANA Considerations</name>
      <t> This document requests one new IANA-managed code-point for Deterministic Latency processing. IANA maintains the "Network Action Opcodes" registry when created from IANA request in 
<xref target="I-D.ietf-mpls-mna-hdr"/>. IANA is requested to allocate a value for MPLS Network Action Opcode for Deterministic Latency Network Action from this registry:</t>
      <table anchor="Table_2">
        <name>MPLS Network Action Opcode for Deterministic Latency</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBA1</td>
            <td align="left">DLNA Opcode</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
    </section>


    <section>
      <name>Security Considerations</name>
      <t> Security considerations for DetNet are covered in the DetNet Architecture <xref target="RFC8655"/>, DetNet Data Plane Framework <xref target="RFC8938"/> and DetNet Security Considerations 
<xref target="RFC9055"/>. MPLS security considerations are covered in <xref target="RFC8964"/>, <xref target="RFC3031"/>, <xref target="RFC3032"/>. 
These security considerations also apply to this document. The MNA security considerations speicified at <xref target="I-D.ietf-mpls-mna-hdr"/>
and <xref target="I-D.ietf-mpls-mna-fwk"/> are also applicable to the procedures defined in this document.</t>
    </section>

    <section>
      <name>Acknowledgements</name>
      <t> The authors would like to acknowledge Adrian Farrel, Lou Berger, Gregory Mirsky, Loa Andersson for their helpful comments and Shaofu Peng for his thorough review and very helpful comments. </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
    &RFC2119; 
    &RFC8174;
    &RFC8964;
    &I-D.ietf-mpls-mna-hdr;
    </references>
    <references title="Informative References">
    &RFC3031;
    &RFC3032;
    &RFC8655;
    &RFC8938;
    &RFC9055;
    &RFC9320;
    &I-D.ietf-mpls-mna-usecases;
	&I-D.ietf-mpls-mna-requirements;
    &I-D.ietf-mpls-mna-fwk;
	&I-D.ietf-detnet-scaling-requirements;
	&I-D.ietf-detnet-dataplane-taxonomy;
	&I-D.stein-srtsn;
    </references>
  </back>
</rfc>
