<?xml version="1.0" encoding="iso-8859-1" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" ipr="trust200902" docName="draft-sx-detnet-mpls-queue-06" consensus="true" submissionType="IETF">

<front>
        <title abbrev="MPLS Sub-Stack for DLA"> MPLS Sub-Stack Encapsulation for Deterministic Latency Action
 </title>

  <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 year="2023"/>
  
    <area>Routing</area>
    <workgroup>DetNet 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 principals for the MPLS header which contains the Deterministic Latency Action (DLA) option, designed for use over a 
	DetNet network with MPLS data plane. It enables guaranteed latency support and makes scheduling decisions for time-sensitive service running on
	DetNet nodes that operate within a constrained network domain.</t>
    </abstract>
    
</front>
  
<middle>

  <section title="Introduction">
  
   <t> As specified in <xref target="RFC8655"/> and <xref target="RFC8938"/>, Deterministic Networking (DetNet) operates at the IP layer and delivers
   service with low data loss rates and bounded latency guarantee within a network domain. </t>
  
  <t> As defined in <xref target="RFC8964"/>, the DetNet MPLS data plane provides a foundation of building 
  blocks to enable PREOF (Packet Replication, Elimination and Ordering Functions (PREOF)) functions to DetNet service and forwarding sub-layer. 
  The DetNet service sub-layer includes a DetNet Control Word (d-CW), service label (S-Label), an 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) used to forward a DetNet flow 
  over MPLS domains. The DetNet forwarding sub-layer provides corresponding forwarding assurance with IETF existing functions using resource allocations and 
  explicit routes. But these functions may not be enough to provide the deterministic latency (including bounded latency, low packet loss and in-order 
  delivery) assurance. Because latency variation in one DetNet system results in the need for extra buffer space in the next-hop DetNet system(s), which
in turn increases the worst-case per-hop latency. So standard queuing and scheduling algorithms are required to compute and reserve the sufficient buffer 
space for DetNet nodes along the path of DetNet flows.</t> 
  
  <t> To support time-sensitive service with ultra-low loss rates and deterministic latency, it is required to apply feasible 
  scheduling mechanisms to specific applications for deterministic networking. As described in <xref target="RFC9320"/>, 
the end-to-end bounded latency is considered as the sum of non-queuing and queuing delay bounds along with the queuing mechanisms. The value for 
non-queuing delay bounds (which consist of packet output delay, link delay, frame preemption delay and processing delay) is relative with the physical
 capability of on-used networks and can be considered to be stable. The unstable latency delay bounds are mainly from queuing delay and regulation 
 delay. The regulation delay is mainly from regulation policy. To simplify the question this draft assumes there is no regulation policy. So the 
 question is left to address the selection for queuing mechanisms and queuing delay information encapsulation in data plane. </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. There are also discussions on new queuing or scheduling mechanisms
 such as <xref target="I-D.peng-6man-deadline-option"/> and <xref target="I-D.dang-queuing-with-multiple-cyclic-buffers"/>. In terms of delay guarantee for different 
 applications, to select the right scheduling/queuing mechanism applied to a specific application is required. </t>
  
  <t> Based on the existing DetNet MPLS encapsulations and mechanisms <xref target="RFC8964"/>, the draft defines the encoding format for Deterministic Latency Action (DLA) option 
  carried in MPLS sub-stack.</t>
  
  </section>
  
  <section title="Conventions">
 
  <section title="Requirements Language">  
	<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 title="Terminology"> 
   <t> Refer to <xref target="RFC8655"/>, <xref target="RFC8964"/>, <xref target="I-D.ietf-mpls-mna-hdr"/> and <xref target="RFC9320"/> for the key 
   terms used in this document.</t>  
    <t> Deterministic Latency (DL):the bound of network latency and delay variation between two DetNet endpoints. It may includes parameters such as bounded latency, bounded
	delay variation, etc.  </t> 
    <t> Deterministic Latency Action (DLA): used to indicate deterministic latency actions for MPLS Sub-Stack.</t> 
  </section>
  
  </section>

  <section title="DetNet DLA Option">
  
	<section title="Queuing delay">  
	
     <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 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 right queuing methodology applied to specific applications and carry necessary queuing delay information for computation of end-to-end latency. </t>

	 </section>  
	
	<section title="DLA Option">  
	
     <t> The DetNet data plane encapsulation in transport network with MPLS data plane is specified in <xref target="RFC8964"/>. <xref target="I-D.xiong-detnet-data-fields-edp"/> has 
	 proposed a commom DetNet data fields for enhanced DetNet data plane and defined a DLA option to carry queuing-based metadata.This document provides 
	 additional encapsulation for the DLA in MPLS data plane. </t>	
	 
	 <t> The DetNet routers in data plane perform MPLS forwarding functions to choose a feasible way with sufficient network resources for the incoming packets, 
	 and makes right selection on the queuing or scheduling mechanisms applied for specific DetNet flows to satisfy strict QoS criteria in the forwarding output port.
	 The information for the queuing or scheduling mechanisms are carried in DetNet DLA header. Refer to <xref target="I-D.stein-srtsn"/>, considering the time latency 
	 information are processed per hop so the time latency informations (such as deadline time, cycle identify, etc.) of each DetNet node for DetNet flows are expected 
	 to be carried as a set of lists of LSEs in MPLS data plane. </t>
	 
	</section> 

  </section>  	

  <section title="MPLS Extension for DLA">  

	<section title="DetNet MPLS Header for DLA">  
	
<t> The DetNet MPLS header follows <xref target="RFC8964"/>, as showed the below figure 1, the SP-Lable (SPL) is added to indicate Deterministic Latency Action (DLA).</t>		

<figure anchor="Figure_1" title="DetNet MPLS Header">
<artwork align="center"> <![CDATA[		 
+---------------------------+
|       DetNet App-Flow     |
|       Payload Packet      |
+---------------------------+--\
|     DetNet Control Word   |   | 
+---------------------------+   | 
|          S-Label          |   | DetNet Data Plane  
+---------------------------+   | MPLS Encapsulation    
|          SP-Lable         |   |  
+---------------------------+   | 
|          F-Label(s)       |   |
+---------------------------+--/
|         Data-Link         |
+---------------------------+
|          Physical         |
+---------------------------+					
]]></artwork>
 </figure>	 
	 
<t> The SP-L (Special Purpose-Label) may be B-SPL <xref target="RFC9017"/>, new-SPL, extended SPL <xref target="RFC9017"/>. 
This draft follows the MNA (MPLS Network Action) solution specified in <xref target="I-D.ietf-mpls-mna-hdr"/> and <xref target="I-D.ietf-mpls-mna-fwk"/>, and uses b-SPL to indicate the presence of  the MPLS Network Action Sub-Stack (NASS).
The value for the bSPL value is to be assigned by IANA and follows the assignment in <xref target="I-D.ietf-mpls-mna-hdr"/>. The SP-Label field is formatted as below figure.</t>

	</section>  
	
	<section title="MPLS ISD for DLA">  	

<figure anchor="Figure_2" title="SP-Label Format">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI Label = bSPL (TBA3)          | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

   <t> NASI Label: </t>
     <t>A new bSPL value is to be assigned by IANA. It is used to indicate the presence of the MPLS Network Action Sub-Stack (NASS). The assignment for this field value refers to <xref target="I-D.ietf-mpls-mna-hdr"/>.</t>
	 
<t> The MPLS sub-stack encoding format for DLA option is showed as figure 3. The format provides DetNet Latency Network Action Indicator (NAI) indicates the specific DLA. Its detailed information is carried in Ancillary Data. </t>

<figure anchor="Figure_3" title="MPLS LSE Format for DLA">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-DLA=TBA1 |                Flag           |S|  Data |  NAL  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|             AD LSE1                       |S|    AD LSE1    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|             AD LSE2                       |S|    AD LSE2    | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 ...  ...  ...                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|             AD LSEn                       |S|    AD LSEn    | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>


   <t> IS-DLA (7 bits): This is the first 7-bit value in the Label Field. The value is used to indicate In-Stack DLA and to be assigned by IANA as value TBA1. </t>
   
   <t> Flag (16 bits): identifies the type of queuing mechanisms used in the network. The queuing type format is defined in section 4.2 of <xref target="I-D.xiong-detnet-data-fields-edp"/>.</t>
   
   <t> S (1 bit) : The Bottom of Stack <xref target="RFC3032"/>. </t> 
   
   <t> Data (4 bits) : Reserved bits for future use. </t>
   
   <t> NAL (4 bits): The DLA action length. It indicates the number of AD LSEs in the sub-stack. </t>   
   
   <t> The first bit in the Label field of the following AD LSEs MUST be set to "1". As specified in <xref target="I-D.ietf-mpls-mna-hdr"/> this is to prevent aliasing the label field with other bSPLs on the legacy routers.	</t>
   
   <t> Ancillary Data:</t>
   <t> The 19-bit Label field and 4-bit TC field and 8-bit TTL field (except S bit) in the additional LSEs are used to carry the Ancillary Data for specific DLA latency information.</t>  
   <t> The Ancillary Data LSE1 is expected to carry the latency informationDLA option data defined in section 4.2.2 of <xref target="I-D.xiong-detnet-data-fields-edp"/> of the edge DetNet node. Depend on 
   specific queuing mechanisms used in the network the DLA field length for the latency information for one DetNet node is variable. The specific queuing (including cycle, deadline, etc.) data encapsulation are described in 
   <xref target="I-D.xiong-detnet-data-fields-edp"/>. </t> 
   <t> The first AD LSE is expected to carry the latency information for edge DetNet node. When the length of latency information is more than 32bits less than 64bits, both AD 
   LSE1 and LSE2 are expected to carry the latency information for edge DetNet node. In this case, the DLA option data of next hop is carried in AD LSE3 and LSE4. Along the path of DetNet flows the
   AD LSE(n-1) and LSEn carry the DLA option data for the peer edge DetNet node.  With the DetNet flows are being forwarded in its output ports the corresponding node latency information carried 
   in DLA options are processed hop by hop. </t> 

    </section> 
	<section title="MPLS PSD for DLA"> 
   <t> There are some limitaions to use MPLS ISD for DLA. For example, the total length for ISD LSEs seems small (no more than 16LSEs), but on the other hand the time-latency information of each nodes 
   (nodes number may be more than 16 in DetNet) along the path of DetNet flows needs be carried in the MPLS sub-stack. Besides HBH scenario brings high packet overload and low encapsulation efficiency. This document does 
   not exclude MPLS PSD option for DLA. Considering the MPLS PSD is under discussion and has not been reached consensus in MPLS WG whether to use MPLS ISD or PSD for DLA is left for future decision.</t>
   <t> The MPLS PSD indicator format refers to <xref target="I-D.ietf-mpls-mna-hdr"/> and <xref target="I-D.jags-mpls-ps-mna-hdr"/> showed as figure 4.</t>

<figure anchor="Figure_4" title="MPLS PSD for DLA">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Label=MNA bSPL              | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-DLA=TBA1 |          Flag           |1|IHS|S| Res |U| NASL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                             |1|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                        
~                   Post-Stack Network Actions                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|N N N N|Version| PS-MNA-LEN    | TYPE = POST-STACK-MNA         | TH
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|<-+
| PS-DLA=TBA2 |       DLA Ancillary Data      |R|R| DLA-HDR-LEN |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  D
|                                                               |  L
~              DLA Option and Ancillary Data                    ~  A
|                                                               |  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+

]]></artwork></figure>
   <t> As specified at <xref target="I-D.ietf-mpls-mna-hdr"/>, The header for In-Stack Network Action encodes: </t>   
   <t> P (1 Bit) : This document sets the value to 1 to identify the presence of Post-Stack Network Action.</t>   
   <t> IHS (2 Bit) : Indicates the combined scope of the In-Stack and the Post-Stack Network Actions. </t>
   <t> U (1 Bit) : Indicates the combined Unknown Action Handling of the In-Stack and the Post-Stack Network Actions.</t>  

   <t> As specified at <xref target="I-D.jags-mpls-ps-mna-hdr"/>, The header for Post-Stack Network Action encodes: </t> 
   <t> NNNN (4 bits): This first nibble identifies the start of the Post-Stack Network Actions. A new value can be assigned 
       by IANA (value TBA1). Generic Associated Channel (0001b) can be used instead. </t> 
   <t> Version (4 bits): This is Post-Stack MNA version.</t> 
   <t> PS-MNA-LEN (8 bits): Post-Stack MNA Total Length in words. This excludes the Post-Stack Top header.</t> 
   <t> TYPE (16 bits): Type is set to POST-STACK-MNA. In case of DetNet MPLS, this is DLA Type.</t> 
   <t> PS-DLA (7 bits): Post-Stack Network Action Opcode. The value is used to indicate Post-Stack DLA and to be assigned by IANA as value TBA2.</t> 
   <t> DLA Ancillary Data (16 bits): Post-Stack Ancillary Data associated with the DLA.</t> 
   <t> R (2 bits): Reserved bits.</t>
   <t> DLA-HDR-LEN (7 bits): Post-Stack Network Action Length for the DLA Action.</t>    
   
   <t> The detailed MNA PSD encapsulation of the DLA will refer to the MNA PSD WG document once the MNA PSD option is adopted in MPLS WG.</t>	
	</section> 
 
</section>   
  
<section title="IANA Considerations">
<t> This document requests two new IANA-managed code-points for DetNet application processing. IANA maintains the "In-Stack MNA Opcode" registry when created from IANA request in <xref target="I-D.ietf-mpls-mna-hdr"/>. 
IANA is requested to allocate a value for In-Stack Network Action Opcode for DLA application from this registry:</t>

<texttable title="In-Stack DLA Indicator" anchor="IS-DLA">
      <ttcol align='left'>Value</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>TBA1</c>
      <c>IS-DLA</c>
      <c>this document</c>
</texttable>

<t> IANA maintains the "Post-Stack MNA Opcode" registry when created from IANA request in <xref target="I-D.jags-mpls-ps-mna-hdr"/>. 
IANA is requested to allocate a value for Post-Stack Network Action Opcode for DLA application from this registry:</t>
<texttable title="Post-Stack DLA Indicator" anchor="PS-DLA">
      <ttcol align='left'>Value</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>TBA2</c>
      <c>PS-DLA</c>
      <c>this document</c>
</texttable>

</section>

  
<section title="Security Considerations">
<t> Security considerations for DetNet are covered in the DetNet Architecture RFC8655 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. </t>
</section>

<section title="Acknowledgements">
<t> The authors would like to acknowledge Shaofu Peng for his thorough review and very helpful comments. </t>
</section>  
  
</middle>
  
<back>
    <references title="Normative References">
		<?rfc include="reference.RFC.2119"?>
		<?rfc include="reference.RFC.3031"?>
		<?rfc include="reference.RFC.3032"?>
		<?rfc include="reference.RFC.8655"?>
		<?rfc include="reference.RFC.8174"?>
		<?rfc include="reference.RFC.8964"?>
		<?rfc include="reference.RFC.9017"?>	
    </references>
	
    <references title="Informative References">
		<?rfc include="reference.RFC.8938"?>
		<?rfc include="reference.RFC.9055"?>	
		<?rfc include="reference.RFC.9320"?>
	    <?rfc include='reference.I-D.ietf-mpls-mna-fwk'?>
	    <?rfc include='reference.I-D.ietf-mpls-mna-hdr'?>	
	    <?rfc include='reference.I-D.dang-queuing-with-multiple-cyclic-buffers'?>	
	    <?rfc include='reference.I-D.peng-6man-deadline-option'?>	
	    <?rfc include='reference.I-D.stein-srtsn'?>		
		<?rfc include='reference.I-D.xiong-detnet-data-fields-edp'?>
		<?rfc include='reference.I-D.jags-mpls-ps-mna-hdr'?>
    </references>	
</back>

</rfc>

