<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-zhu-detnet-cycle-mapping-learning-01" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <title abbrev="Cycle Mapping Learning Method for Scaling DetNet">Cycle Mapping Learning Method for Scaling DetNet</title>
    <seriesInfo name="Internet-Draft" value="draft-zhu-detnet-cycle-mapping-learning-01"/>
    <author fullname="Xiangyang Zhu" initials="X" surname="Zhu">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street>No.50 Software Avenue</street>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code>211100</code>
          <country>China</country>
        </postal>
        <phone/>
        <email>zhu.xiangyang@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Jinghai Yu" initials="J" surname="Yu">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code/>
          <country>China</country>
        </postal>
        <phone/>
        <email>yu.jinghai@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Chenqiang Gao" initials="C" surname="Gao">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone/>
        <email>gao.chenqiang@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Quan Xiong" initials="Q" surname="Xiong">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <city>Wuhan</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone/>
        <email>xiong.quan@zte.com.cn</email>
      </address>
    </author>
    <date year="2023"/>
    <area>forwarding</area>
    <workgroup>DetNet</workgroup>
    <keyword/>
    <abstract>
      <t>The scaling DetNet (Deterministic Networking) technology based on cyclic
	  queuing and scheduling is expected to solve the scalability problem of
	  DetNet, and is hoped to extend the adaptive domain of DetNet to wide area
	  network or even backbone network. One of the keys of this technology is 
	  to accurately obtain the cyclic mapping relationship between adjacent
	  nodes, based on which DetNet packets can be end-to-end deterministically
	  forwarded . This draft proposes a method for nodes to learn the cycle
	  mapping relationship through sending learning messages.</t>
    </abstract>
  </front>
  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="I-D.ietf-detnet-scaling-requirements" format="default"/> proposes the requirements
	  for deterministic forwarding of services in scaling DetNet(Deterministic Networking) networks. Typical
	  characteristics of large-scale networks include long single-hop delay,
	  no time sync, and large network dimensions (typically, greater than 16 hops),
	  etc., these requirements cannot be met by the DetNet architecture and 
	  technology proposed by <xref target="RFC8655" format="default"/>, because the architecture andtechnology
	  proposed by RFC8655 are mainly intend for limited-scale networks. In order
	  to provide deterministic services in large-scale networks, the industry has
	  proposed a variety of improving ideas, such as <xref target="SR-TSN" format="default"/>, <xref target="Deadline" format="default"/> and
	  <xref target="TCQF" format="default"/>, and one of the promising and first-deployed solutions is based 
	  on the idea of cyclic scheduling and forwarding from <xref target="IEEE802.1Qch" format="default"/>. </t>
	  
      <t>In this draft, for two adjacent nodes, one is called upstream node (UN)
	  and the other downstream node (DN). The cycle-mapping relationship refers to
	  the correspondence between the cycle label carried by the upstream node`s
	  egress packet and the cycle label encapsulated by the downstream node`s
	  egress port. The packet is forwarded under the guidance of the cycle mapping
	  relationship. For example, as shown in Figure 1, if there is a cycle mapping
	  relationship x->z between UN and DN, when the packet with the cycle label x
	  arrives at the downstream node , the downstream node will obtain the downstream
	  egress cycle label according to the mapping relationship x->z, then z will be
	  encapsulated into and the packet will be scheduled and forwarded according to
	  the cycle slot z.</t>
	  
	  
	  <figure>
          <name>Cycle Forwarding Process</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
   
   |  cycle x  |           |
UN +-----------+-----------+
          \     
           \   Packet
            \  received with x
           | V         |           |  cycle z  |
DN         +-----------+  ... ...  +-----------+
                                       \     
                                        \   Packet
                                         \  sent with z
                                          V
										  
			     ]]></artwork>
      </figure>
	  <t keepWithPrevious="true"/>
	  
	  
      <t>To obtain the cycle mapping relationship, we have many optional methods,
	  for example, one can use control plane for calculation and configure the 
	  result to forwarding node, and one can also leave the task to forwarding plane
	  self-learning. In the forwarding plane learning mode, cycle mapping learning
	  messages are exchanged between upstream node and downstream node, and the
	  downstream node have to calculate and store the cycle mapping relationship
	  according to the learning messages.</t>
	  
      <t>This draft gives the general idea, problems and corresponding solutions for
	  cycle mapping self-learning. This draft only considers the general learning
	  process of the forwarding plane , and does not consider the underlying protocol
	  (e.g., OAM) and protocol extension format of the learning message, nor does it
	  consider the interaction protocol extension between the control plane and the
	  forwarding plane. The consideration of related extensions will be described in
	  detail in future drafts.</t>
	  
    </section>
	
    <section numbered="true" toc="default">
      <name>Conventions used in this document</name>
      <section numbered="true" toc="default">
        <name>Terminology</name>
		<t>UN: Upstream Node</t>
		<t>DN: Downstream Node</t>
      </section>
      <section numbered="true" toc="default">
        <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" format="default"/> <xref target="RFC8174" format="default"/> when,
    and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
	
	
    <section numbered="true" toc="default">
      <name>Cycle Mapping Learning Message</name>
	  
	  <t>The cycle mapping learning process requires UN to send learning messages
	  to DN. No restriction is put on the detailed encapsulation format, the sending
	  frequency, sending times and how the downstream node can identify the message,
	  for example, it can be configured by the control plane.</t>
	  
      <t>At least three optional cycle mapping learning message types can be used. </t>
	  
      <section numbered="true" toc="default">
        <name>Based on Special Purpose Message</name>
		
        <t>In order to clearly mark the egress cycle slot boundary, the UN can constructs
		and sends special protocol messages (such as PAUSE, TWAMP) as learning messages
		at the beginning and the ending of the cycle. In order to avoid occupying too
		much bandwidth, special messages are sent at a reasonable frequency, for example,
		sent once a physical cycle. The start time of cycle learning may be the time of
		system startup, controller configuration time, user triggering and so on. When a
		learning message arrives at a DN, it can be used to clearly mark the boundary of
		the UN egress cycle at local, which is called a UN virtual cycle. </t>
		
        <t>Advantages: easy to mark cycle boundaries, out-of-band, flexible and controllable; </t>
		
        <t>Disadvantages: Bandwidth consumption is required, and special message construction
		brings hardware overhead;</t>
		
      </section>
      <section numbered="true" toc="default">
	  
        <name>Based on DetNet Flows</name>
        <t>Before DetNet flow enters the network, the cycle mapping relationship does
		not work and is meaningless. At the same time, in order to avoid bandwidth
		consumption in the active mode, learning can be based on actual DetNet flow
		packets, because when deterministic packets are sent from the source node, they
		will inevitably carry the egress cycle label of the UN egress. There is no
		restriction on the packet type, for example, it may be an SRv6 extended packet
		or an SR-MPLS extended packet.</t>
		
		<t>Advantages: In-band mode can realize packets multiplexing;</t>
		
		<t>Disadvantages: The number and time of sending actual flow packets are uncertain,
		resulting in uncertain positions of flow packets within the cycle, and cannot be
		directly used to calibrate the cycle boundary;</t>
		
      </section>
	  <section numbered="true" toc="default">
	     <name>Based on Enhanced DetNet Flows</name>
		 
		 <t>In this manner, the field of the flow packet is extended, and the value of
		 "deviation from the beginning of the cycle slot" is additionally encapsulated,
		 which can be used to clearly identify the position of the flow packet in the
		 UN egress cycle, thereby assisting the DN to determine the virtual cycle boundary
		 where the flow packet is located.</t>
		 
		 <t>Advantages: In-band mode, multiplexing can be realized, and downstream nodes
		 are easy to learn;</t>
		 
		 <t>Disadvantage: The purpose of the extra encapsulation field is only for
		 periodic learning, occupying the effective field of the business message. Both
		 encapsulation and decapsulation logic need to be modified, increasing hardware
		 resource consumption.</t>
		 
		 <t>According to specific scenarios, one of the above methods can be selected 
		 for cycle mapping learning messages.</t>
		 
	   </section>	
    </section>
    <section numbered="true" toc="default">
      <name>Cycle Mapping Learning Principle</name>
	  
      <t>The cycle mapping self-learning process is carried out by the DN, relying
	  on the cycle mapping learning message sent by the UN. It is assumed that the
	  number of queues and cache capacity configured by the UN are sufficient. The
	  functions of packet routing and forwarding are independent from learning process
	  described here and will not be described.</t>
	  
      <section numbered="true" toc="default">
        <name>Obtain the Maximum Processing Delay of the DN</name>
		
        <t>According to the latency reference model proposed in the <xref target="RFC9320" format="default"/>,
		the node regulation subsystem must be able to absorb the maximum
		node processing delay. Typically, the processing delay variation scope only
		depends on the hardware implementation of a specific device, including shaping,
		table lookup algorithm, the packet counter resources and etc. For a specific
		network device, the maximum value of processing delay is determined at the product,
		and usually includes two components, namely the packet length related part and
		packet length independent part. For instance, packet-length-independent part
		include forwarding table lookup, CRC check, etc., and the packet length-related
		part includes packet cache and scheduling and so on. If the processing delay is
		known and can be queried by the self-learning module, no active OAM probing is 
		required. </t>
		
        <t>Though processing delay may depend on enabled functions (such as shaping, 
		packet slicing)  and packet length, the processing delay range can also be obtained
		through some active detection tools. Specifically, for a given device with enabled
		function sets, one can randomly send packets that meet the packet length limit and
		up to wire-speed, and then it is easy to measure the maximum processing delay. 
		Further, the delay value can be configured in a device-specific field , and then
		can be used by the cycle mapping self-learning module.</t>
		
		<t>The processing delay can also be configured by the control plane as needed. For
		example, when the control plane needs to control the end-to-end delay of the DetNet
		domain, it may actively increase the single-hop process delay of the device.</t>
		
      </section>
      <section numbered="true" toc="default">
        <name>DN Determines the Ingress Cycle of Learning Message</name>
		
        <t>Suppose that the special purpose cycle learning message described in Section 
		2.1 is sent by UN, it is easy for DN to correctly identify the boundary of UN
		egress virtual cycle slot. Different from the IEEE802.1Qch mechanism, since the 
		upstream and downstream nodes are not time synchronized and there are long links,
		the packets carrying the same UN egress cycle label x, may not necessarily fall
		into the same DN cycle y-1, in fact some packets may also fall into cycle y,
		as shown in Figure 2.</t>
		
		<figure>
          <name>DN determines ingress cycle</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
   
       |  cycle x        |                 |
UN     +-----------------+-----------------+
        \                 \
         \                 \
          \ learning msg    \learning msg
           \ P1 received     \P2 received
            \ in cycle y-1    \in cycle y
   |         V       |         V       |                 |
DN +-----------------+-----------------+-----------------+
            y-1               y                   y+1        			 
			     ]]></artwork>
      </figure>
	  <t keepWithPrevious="true"/>
      <t>In order to correctly obtain the egress cycle number of the downstream node,
	  it is necessary to take the arrival time of the latest packet belonging to UN
	  egress cycle x as the baseline, that is, y as the final receiving cycle. In the
	  implementation, it is necessary to have a table storing the cycle mapping relationship
	  between the UN egress and the DN ingress cycle label. When the first learning message
	  P1 carrying the cycle label x is received, the mapping relationship x->y-1 is obtained
	  and stored. When the second learning message carrying cycle label x is received ,
	  UN will obtain x->y relationship and update the table.</t>
      </section>
	  
      <section numbered="true" toc="default">
        <name>DN Determines the Message Sending Cycle</name>
        <t>The DN calculates the local ingress->egress port cycle mapping relationship
		according to the maximum processing delay obtained in Section 4.1, as shown in
		Figure 3. </t>
        <figure>
          <name>DN Determines Egress Cycle</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
   
UN      |     cycle x     |                 |
egress  +-----------------+-----------------+
         \                 \
          \P1(x)            \P2(x)
           \                 \
            V                 V              
            <--virtual cycle-->          
DN ingress+-----------------+--*--------------+ ....+-----------------+
          |                 |  *              |     |                 |
          |                 |  <-max process delay->|                 |
          |    cycle y-1    |     cycle y     |     | *    cycle z    |                 
DN egress +-----------------+-----------------+ ....+-*---------------+
                                                       \        \
                                                        \P1(z)   \P2(z)
                                                         \        \
                                                          V        V 
 			     ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <t>The calculation method of the egress cycle label of DN is no very simple and
		intuitive, it  needs to consider the cycle slot size, the slot offset of the P2
		message falling in the cycle and the maximum processing delay of UN at the same
		time. Assuming that the cycle slot size is T and the receiving cycle is y, the
		formula is as follows:</t>
		<t>UN egress cycle z=y+ ceil((processing delay-T+offset)/T) +   1</t>
		<t> In formula above, ceil means to round-up the division result.</t>	
        <t>In particular, if (processing delay-T+offset) happens to be an integer multiple
		of T, in order to avoid the last flow packet of cycle x sent to thez queue 
		cannot be forwarded in time and cause an error, because, for example, hardware
		implementationprecision, z can be proactively increased by 1 for redundant
		configuration .</t>	
		
        <t>Then can get the DN ingress and egress cycle mapping relationship y->z.</t>		
      </section>
	  
	  
	  <section numbered="true" toc="default">
        <name>DN Cycle Mapping Relationship Maintenance </name>	 
		
		<t>After obtaining the mapping relationship x->y from the upstream egress to the
		downstream ingress and the mapping relationship y->z from the downstream ingress
		to the egress, the mapping relationship x->z can be easily obtained. Since there
		are multiple circular queues, assuming that the number of circular queues of
		template T is N, the final cycle mapping relationship can be further obtained:</t>
		<t>(x+i) MOD N -> (z+i) MOD N </t>
		<t>For example, the UN and DN concurrently maintain a eight-cycle-queue template.
		Through learning, the cycle mapping relationship between the upstream egress
		and the downstream egress port is 4->6, then the mapping relationship maintained
		at the DN is:</t>
		<t>4->6, 5->7, 6->0, 7->1,0->2,1->3,2->4,3->5.</t>
	  </section>
    </section>
	<section numbered="true" toc="default">
      <name>Considerations for Cycle Mapping Operations</name>
      <section numbered="true" toc="default">	
        <name>Cycle Learning Based on DetNet Flows</name>
		<t>Among the three cycle self-learning messages mentioned in Section 2, both 3.1
		and 3.3 can accurately identify the virtual cycle boundary where the message is
		located at the downstream node. When learning based on flow packets proposed in
		3.2, since the arrival frequency and time of flow packets are random in cycle slot,
		flow packets cannot be directly used to accurately identify cycle boundaries.</t>
		<t>Considering the scenario shown in the figure 4 upper half, since all packets
		of cycle 1 arrive at the downstream node, they all fall in the cycle 3, so the
		mapping relationship of UN egress and DN ingress, 1->3 is formed. In Figure 4
		lower half, when the number of service packets increases, some packets fall into
		cycle 4. According to Section 4.2, it must be considered that the packet receiving
		cycle is 4, and the mapping relationship is adjusted to 1->4.</t>
		<figure>
          <name>Ambiguous Ingress Cycle Example</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
       |  cycle 1        |                 |
UN     +-----------------+-----------------+
        \ \ \ \              
         \ \ \ \              
          \ \ \ \
           \ \ \ \
            \ \ \ \
   |         V V V V |                 |                 |
DN +-----------------+-----------------+-----------------+
            3                4                  5    
				 
			
       |  cycle x        |                 |
UN     +-----------------+-----------------+
        \ \ \ \\  \ \ \           
         \ \ \ \\  \ \ \     
          \ \ \ \\  \ \ \
           \ \ \ \\  \ \ \
            \ \ \ \\  \ \ \
   |         V V V VV| V V V           |                 |
DN +-----------------+-----------------+-----------------+
            3                4                  5  
 			     ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
		<t>Which add a T to the single-hop jitter after adjustment in figure 4 . From
		the perspective of the entire service flow, the end-to-end jitter requirement
		of 2T cannot be met.</t>
		<t>Idea 1 . When learning the mapping relationship for the first time, if all
		the UN egress cycle packets fall into the same DN ingress cycle, for example,
		fall into cycle y, then take the automatic adjustment and supposed it to fall
		into cycle y+1. At this time, by introducing a redundancy delay of T, the
		uncertainty introduced by flow packets can be avoided . The end-to-end delay
		increases by N*T, where N is the number of hops, and the max end-to-end jitter
		is still 2T.</t>
		<t>Idea 2. Reshape the business message, and if there is more than flow packets
		in the cycle, since the queue is a FIFO, there will always be a flow packets
		to be sent at the beginning of the cycle, so only one message needs to be reserved
		and be used to mark the end of the cycle There is always a message at every 
		moment. This method does not affect packet forwarding characteristics and bandwidth
		occupation.</t>
		<t> Idea 3. The network construction is divided into two phases: testing and
		operation. When the flow packets requests access, it is required to send test
		flow packets at random or full flow for a predefined period. After the period,
		actual DetNet flow packets are sent according to the requirements of the traffic
		characteristics.</t>
      </section>
      <section numbered="true" toc="default">	
        <name>Monitoring of UN and DN Mapping Relationships</name>
        <t>After the cycle mapping relationship is established, flow packets can directly
		search the mapping table to obtain the egress cycle label, and then deterministic 
		forwarding can be obtained. However, when some problems occur, for example, the
		fiber switching occurs , forwarding node restarts, link attenuation occurs, or the
		learning process is re-triggered by the control plane or user, the mapping
		relationship of the upstream and downstream nodes may change. If such anomalies are
		not detected in time, errors will occur in the cycle mapping process, and DetNet
		flow determinism cannot be guaranteed.</t>
		<t>In order to detect changes in time and update the mapping relationship,for each
		receiving flow packets, the DN still needs to detect ingress cycle, and compare it
		with the cycle mapping relationship maintained in Section 4.4. If it is inconsistent,
		it indicates that cycle mapping relationship has changed. For example, if the mapping
		relationship 2->5 is maintained in 4.4, when a UN flow packet is received and the
		ingress cycle of the DN is 4 or 5, it is considered correct, and in other cases it
		is considered problems has take place, it is necessary to re-execute the cycle
		mapping relationship calculation process described in Sections 4.</t>
      </section>	
      <section numbered="true" toc="default">	
        <name>Cycle Mapping Relationship Storage</name>
        <t>Consider the situation where multiple upstream nodes establish a cycle mapping
		to a single downstream node . When the downstream node maintains the mapping
		relationship, it needs to ensure the uniqueness of the table key value.</t>
		<t>i.For point-to-point links, you can simply use {DN ingress port, DN egress port}
		as the key value;</t>
		<t>ii.In the case of LAN (many-to-many or many-to-one) , multiple UN may reach Dn
		through the same ingress port, as shown in the figure 5, at this time, the downstream
		node entry is the same for multiple upstream nodes and cannot be used as a key value.
		Considering that in routing and forwarding, the MAC address of the upstream node
		will be carried in the message, so the MAC address can uniquely identify the upstream
		node. At this time, the UN egress source mac can be added to the key value:{mac,
		 DN ingress port , DN egress port}.</t>
        <figure>
          <name>UN and DN Connected by LAN</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
/-----\                                                    
| UN1 |             ________                             
+--+--+   _____    /        \                  
   |     /     \__/          \ 
   |    /                     \_____       
   |   /                            \_____           
   +-->|                                  \   
       |                                   |
   +-->|                 LAN                |
   |    \                                   |      /-----\
   |     \                                  |------>| DN1 | 
   |      \                                 |      +--+--+
/-----\    \                                /  
| UN2 |     \___                          /
+--+--+         \                       / 
                 \_____/  \___________/                                                                                           
 			     ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>		
      </section>
      <section numbered="true" toc="default">	
        <name>UN and DN Concurrently Support Multiple Cycle Templates</name>	
        <t>If the upstream and downstream nodes support multiple cycle templates at the same
		time, for each cycle template, a mapping relationship can be formed through cycle
		self-learning process described in this draft, and the process of cycle mapping self
		-learning is exactly the same as that of a single cycle template.</t>	
        <t>In order to identify the periodic template at the downstream node, in addition
		to the time slot number, the periodic template T needs to be encapsulated in the
		learning message . The downstream node first extracts T and then performs learning
		based on the corresponding template. In addition, after the periodic self-learning 
		calculation is completed, the entry key needs to be added with a template when storing,
		that is, {T, mac, DN ingress port , DN egress port} .</t>		
	  </section>
	</section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>TBA</t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>TBA</t>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>TBA</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
	  
      <reference anchor="RFC8655" target="https://www.rfc-editor.org/info/rfc8655" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml">
        <front>
          <title>Deterministic Networking Architecture</title>
          <author fullname="N. Finn" initials="N." surname="Finn"/>
          <author fullname="P. Thubert" initials="P." surname="Thubert"/>
          <author fullname="B. Varga" initials="B." surname="Varga"/>
          <author fullname="J. Farkas" initials="J." surname="Farkas"/>
          <date month="October" year="2019"/>
          <abstract>
            <t>This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain.  Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path.  DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8655"/>
        <seriesInfo name="DOI" value="10.17487/RFC8655"/>
      </reference>
      <reference anchor="Deadline" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.peng-detnet-deadline-based-forwarding.xml" target="https://www.ietf.org/archive/id/draft-peng-detnet-deadline-based-forwarding-05.txt">
        <front>
          <title>Deadline Based Deterministic Forwarding</title>
          <author fullname="Shaofu Peng">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Bin Tan">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Peng Liu">
            <organization>China Mobile</organization>
          </author>
          <date month="March" day="1" year="2022"/>
          <abstract>
            <t>   This document describes a deterministic forwarding mechanism based on
   deadline.  The mechanism enhances strict priority scheduling
   algorithm with dynamically adjusting the priority of the queue
   according to its deadline attribute.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-peng-detnet-deadline-based-forwarding-05"/>
      </reference>
      
	  <reference anchor="TCQF" target="https://datatracker.ietf.org/doc/html/draft-eckert-detnet-tcqf-02" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.eckert-detnet-tcqf.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets</title>
          <author fullname="Toerless Eckert" initials="T. T." surname="Eckert">
            <organization>Futurewei Technologies USA</organization>
          </author>
          <author fullname="Stewart Bryant" initials="S." surname="Bryant">
            <organization>University of Surrey ICS</organization>
          </author>
          <author fullname="Andrew G. Malis" initials="A. G." surname="Malis">
            <organization>Malis Consulting</organization>
          </author>
          <author fullname="Guangpeng Li" initials="G." surname="Li">
            <organization>Huawei Network Technology Laboratory</organization>
          </author>
          <date day="6" month="November" year="2022"/>
          <abstract>
            <t>This memo specifies a forwarding method for bounded latency for Deterministic Networks. It uses cycle tagging of packets for cyclic queuing and forwarding with multiple buffers (TCQF). This memo standardizes tagging via the MPLS packet Traffic Class (TC) field for MPLS links and the IP/IPv6 DSCPfield for IP/IPv6 links. The short- hand for this mechanism is Tagged Cyclic Queuing and Forwarding (TCQF). Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-eckert-detnet-tcqf-02"/>
      </reference>
	  <reference anchor="IEEE802.1Qch">
        <front>
          <title>IEEE Standard for Local and metropolitan area networks --
          Bridges and Bridged Networks - Amendment 29: Cyclic Queuing and
          Forwarding</title>

          <author>
            <organization>IEEE</organization>
          </author>

          <date day="28" month="June" year="2017"/>
        </front>

        <seriesInfo name="IEEE" value="802.1Qch-2017"/>

        <seriesInfo name="DOI" value="10.1109/IEEESTD.2017.7961303"/>
      </reference>
      
   
    
    </references>
	<references>
      <name>Informative References</name>
	  <reference anchor="I-D.ietf-detnet-scaling-requirements" target="https://datatracker.ietf.org/doc/html/draft-ietf-detnet-scaling-requirements-01" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-detnet-scaling-requirements.xml">
        <front>
          <title>Requirements for Scaling Deterministic Networks</title>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Yizhou Li" initials="Y." surname="Li">
            <organization>Huawei</organization>
          </author>
          <author fullname="Toerless Eckert" initials="T. T." surname="Eckert">
            <organization>Futurewei Technologies USA</organization>
          </author>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
            <organization>ETRI</organization>
          </author>
          <author fullname="zhushiyin" initials="" surname="zhushiyin">
            <organization>New H3C Technologies</organization>
          </author>
          <author fullname="Xuesong Geng" initials="X." surname="Geng">
            <organization>Huawei</organization>
          </author>
          <date day="1" month="March" year="2023"/>
          <abstract>
            <t>Aiming at scaling deterministic networks, this document describes the technical and operational requirements when the network has large variation in latency among hops, great number of flows and/or multiple domains without the same time source. Different deterministic levels of applications co-exist and are transported in such a network. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-scaling-requirements-01"/>
      </reference>
	  <reference anchor='DIP' target='https://datatracker.ietf.org/doc/html/draft-qiang-detnet-large-scale-detnet-05'>
      <front>
      <title>Large-Scale Deterministic IP Network</title>
      <author fullname='Li Qiang' initials='L.' surname='Qiang'>
         <organization>Huawei</organization>
      </author>
      <author fullname='Xuesong Geng' initials='X.' surname='Geng'>
         <organization>Huawei</organization>
      </author>
      <author fullname='Bingyang Liu' initials='B.' surname='Liu'>
         <organization>Huawei</organization>
      </author>
      <author fullname='Toerless Eckert' initials='T. T.' surname='Eckert'>
         <organization>Huawei</organization>
      </author>
      <author fullname='Liang Geng' initials='L.' surname='Geng'>
         <organization>China Mobile</organization>
      </author>
      <author fullname='Guangpeng Li' initials='G.' surname='Li'>
         </author>
      <date day='2' month='September' year='2019'/>
      <abstract>
	 <t>   This document presents the overall framework and key method for
   Large-scale Deterministic Network (LDN).  LDN can provide bounded
   latency and delay variation (jitter) without requiring precise time
   synchronization among nodes, or per-flow state in transit nodes.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-qiang-detnet-large-scale-detnet-05'/>
   </reference>
   <reference anchor="SR-TSN" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.stein-srtsn.xml" target="https://www.ietf.org/archive/id/draft-stein-srtsn-01.txt">
        <front>
          <title>Segment Routed Time Sensitive Networking</title>
          <author fullname="Yaakov (J) Stein">
            <organization>RAD</organization>
          </author>
          <date month="August" day="29" year="2021"/>
          <abstract>
            <t>   Routers perform two distinct user-plane functionalities, namely
   forwarding (where the packet should be sent) and scheduling (when the
   packet should be sent).  One forwarding paradigm is segment routing,
   in which forwarding instructions are encoded in the packet in a stack
   data structure, rather than programmed into the routers.  Time
   Sensitive Networking and Deterministic Networking provide several
   mechanisms for scheduling under the assumption that routers are time
   synchronized.  The most effective mechanisms for delay minimization
   involve per-flow resource allocation.

   SRTSN is a unified approach to forwarding and scheduling that uses a
   single stack data structure.  Each stack entry consists of a
   forwarding portion (e.g., IP addresses or suffixes) and a scheduling
   portion (deadline by which the packet must exit the router).  SRTSN
   thus fully implements network programming for time sensitive flows,
   by prescribing to each router both to-where and by-when each packet
   should be sent.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-stein-srtsn-01"/>
      </reference>
	   <reference anchor="RFC9320" target="https://www.rfc-editor.org/info/rfc9320" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9320.xml">
        <front>
          <title>Deterministic Networking (DetNet) Bounded Latency</title>
          <author fullname="N. Finn" initials="N." surname="Finn"/>
          <author fullname="J.-Y. Le Boudec" initials="J.-Y." surname="Le Boudec"/>
          <author fullname="E. Mohammadpour" initials="E." surname="Mohammadpour"/>
          <author fullname="J. Zhang" initials="J." surname="Zhang"/>
          <author fullname="B. Varga" initials="B." surname="Varga"/>
          <date month="November" year="2022"/>
          <abstract>
            <t>This document presents a timing model for sources, destinations, and Deterministic Networking (DetNet) transit nodes.  Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods.  The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9320"/>
        <seriesInfo name="DOI" value="10.17487/RFC9320"/>
      </reference>
	</references>
  </back>
</rfc>
