<?xml version='1.0' encoding='ascii'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-xiong-detnet-large-scale-enhancements-01" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <title abbrev="DetNet Data Plane Enhancements for Large-Scale Deterministic Networks">DetNet Data Plane Enhancements for Large-Scale Deterministic Networks</title>
	
	<author fullname="Quan Xiong" initials="Q" surname="Xiong">
      <organization>ZTE Corporation</organization>

      <address>
        <postal>
          <street>No.6 Huashi Park Rd</street>
          
          <city>Wuhan</city>
          
          <region>Hubei</region>
  
          <code>430223</code>

          <country>China</country>
        </postal>

        <phone/>

        <email>xiong.quan@zte.com.cn</email>
      </address>
    </author>
	
	<author fullname="ZongPeng Du" initials="Z" surname="Du">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street></street>
          
          <city>Beijing</city>
          
          <region></region>
  
          <code></code>

          <country>China</country>
        </postal>

        <phone/>

        <email>duzongpeng@chinamobile.com</email>
      </address>
    </author>	
	
	<author fullname="Junfeng Zhao" initials="J" surname="Zhao">
      <organization>CAICT</organization>

      <address>
        <postal>
          <street></street>
          
          <city></city>
          
          <region></region>
  
          <code></code>

          <country>China</country>
        </postal>

        <phone></phone>

        <email>zhaojunfeng@caict.ac.cn</email>
      </address>
    </author>
	
	  <author fullname="Dong Yang" initials="D" surname="Yang">
      <organization>Beijing Jiaotong University</organization>

      <address>
        <postal>
          <street></street>
          
          <city>Beijing</city>
          
          <region></region>
  
          <code></code>

          <country>China</country>
        </postal>

        <phone></phone>

        <email>dyang@bjtu.edu.cn</email>
      </address>
    </author>	
   
    <area>Routing</area>
    <workgroup>DETNET</workgroup>
    <keyword/>
    <abstract>
	
	<t>From charter and milestones, the enhanced Deterministic Networking (DetNet) is 
	required to provide the enhancement of flow identification and packet treatment 
	for data plane to achieve the DetNet QoS in large-scale networks. </t>

	<t>This document analyzes the gaps of the existing technologies especially applying
	the DetNet data plane as per RFC8938 and proposes the enhancement  of 
	packet treatment to support the functions and metadata for enhanced DetNet data 
	plane. It describes related enhanced controller plane considerations as well.</t>

	 
	 
    </abstract>
  </front>

  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
  
    <section title="Introduction" numbered="true" toc="default">
	
	<t>According to <xref target="RFC8655" pageno="false" format="default"/>, Deterministic Networking 
	(DetNet) operates at the IP layer and delivers service which provides 
	extremely low data loss rates and bounded latency within a network 
	domain. The framework of DetNet data planes has been specified in RFC8938.
	The IP and MPLS DetNet data plane has been defined respectively in RFC8939 and
	RFC8964. The DetNet IP data plane primarily uses 6-tuple-based 
	flow identification. And the DetNet MPLS data plane leverages 
	existing pseudowire (PW) encapsulations and MPLS Traffic
    Engineering (MPLS-TE) encapsulations. </t>
	
	<t>The applications in 5G networks demand much more deterministic and 
	precise properties in large-scale networks. The existing deterministic 
	technologies are facing large-scale number of nodes and long-distance 
	transmission, traffic scheduling, dynamic flows, and other controversial 
	issues in large-scale networks. The enhanced DetNet Data plane is required 
	to support a data plane method of flow identification and packet treatment. 
	<xref target="I-D.liu-detnet-large-scale-requirements" pageno="false" format="default"/> has described the 
	enhancement requirements for DetNet data plane.</t>
	
	<t>The enhanced DetNet data plane aims to describe how to use IP and/or MPLS, 
    and related OAM, to support a data plane method of flow identification and 
    packet treatment over Layer 3. The enhanced QoS-related functions and metadata 
    should be provided in large-scale networks. For example, as described in
	<xref target="I-D.ietf-detnet-bounded-latency" pageno="false" format="default"/>,
	the end-to-end bounded latency depends on the value of queuing delay 
	bound along with the queuing mechanisms. Mutiple queuingmechanisms 
	can be used to guarantee the bounded latency in DetNet.  New 
	DetNet-specific metadata should be carried in enhanced DetNet
	IP/MPLS/SRv6 Data Plane.  </t>
	
   <t>This document analyzes the gaps of the existing technologies especially applying
	the DetNet data plane as per RFC8938 and proposes the enhancement of 
	packet treatment to support the functions and metadata for enhanced DetNet data 
	plane. It describes related enhanced controller plane considerations as well.</t>
	
	</section>

    <section title="Conventions used in this document" numbered="true" toc="default">	 	
    <section title="Terminology" numbered="true" toc="default">
	<t>The terminology is defined as <xref target="RFC8655" pageno="false" format="default"/> and <xref target="RFC8938" pageno="false" format="default"/>.</t>
   </section>
   
   <section title="Requirements Language" numbered="true" toc="default">
    <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" pageno="false" format="default"/> <xref target="RFC8174" pageno="false" format="default"/> when,
    and only when, they appear in all capitals, as shown here.</t>
    </section>
	
   </section>
   
   <section title="Gap Analysis of DetNet Data Plane" numbered="true" toc="default">
   
   <section title="Service Requirements of Large-Scale Deterministic Networks" numbered="true" toc="default">
   
   <section title="Support the Differentiated DetNet QoS of Multiple Services" numbered="true" toc="default">
   
   	<t>5G network is oriented to the internet of everything. It need to supports 
	the Ultra-reliable Low Latency Communications (uRLLC) services. The uRLLC services
	demand SLA guarantees such as low latency and high reliability and other 
	deterministic and precise properties especially in Wide Area Network (WAN) 
	applications.The uRLLC services should be provided in large-scale networks 
	which cover the  industries such as intelligent electrical network, intelligent 
	factory, internet of vehicles, industry automation and other industrial internet 
	scenarios. The industrial internet is the key infrastructure that coordinate various 
	units of work over various system components, e.g. people, machines and things 
	in the industrial environment including big data, cloud computing, Internet of 
	Things (IOT), Augment Reality (AR), industrial robots, Artificial Intelligence 
	(AI) and other basic technologies. For the intelligent electrical network, 
	there are deterministic requirements for communication delay, jitter and packet
	loss rate. For example, in the electrical current difference model, a delay of
	3~10ms and a jitter variation is no more than 100us are required. For the 
	automation control, it is one of the basic application and the the core is 
	closed-loop control system. The control process cycle is as low as millisecond 
	level, so the system communication delay needs to reach millisecond level or 
	even lower to ensure the realization of precise control. There are three 
	levels of real-time requirements for industrial interconnection: factory 
	level is about 1s, and process level is 10~100ms, and the highest real-time 
	requirement is motion control, which requires less than 1ms. So the 
	deterministic latency requirements are different with varying services 
	and network scenarios.</t>
   
    <t>As defined in <xref target="RFC8655" pageno="false" format="default"/>, the DetNet QoS can be expressed in terms of :
	Minimum and maximum end-to-end latency, bounded jitter (packet delay 
	variation), packet loss ratio and an upper bound on out-of-order packet 
	delivery.  As described in <xref target="RFC8578" pageno="false" format="default"/>, DetNet applications differ in their 
	network topologies and specific desired behavior and different services 
	requires differentiated DetNet QoS. In the large-scale networks, multiple 
	services with differentiated DetNet QoS is co-existed in the same DetNet 
	network. The classification of the deterministic flows within different 
	levels is should be taken into considerations. It is required to provide 
	Latency, bounded jitter and  packet loss dynamically and flexibly in all 
	scenarios for each characterized flow.</t>
	
	<t>As the Figure 1 shows, the services can be divided into 5 levels and level 
	2~5 is the DetNet flows and level-1 is non-DetNet flow.  DetNet applications 
	and DetNet QoS is differentiated within each level.</t>
	
   <figure title="The classification of multiple services" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">	
		 
   +-------------+-----------+----------+----------+----------+-----------+
   | Item        | Level-1   | Level-2  | Level-3  | Level-4  |  Level-5  |
   +-------------+-----------+----------+----------+----------+-----------+
   | Applications| Broadcast |  Voice   | Audio and| AR/VR    | Industrial|
   | Examples    |           |          | Video    |          |           |
   +-------------+-----------+----------+----------+----------+-----------+   
   | DetNet QoS  | Bandwidth | Jitter   | Latency  | Low      | Ultra-low |
   |             | Guarantee | Guarantee| Guarantee| latency  |latency and|
   |             |           |          |          |and jitter| jitter    |
   +-------------+-----------+----------+----------+----------+-----------+
  
   	   </artwork>
  <postamble/>
 </figure>
	
	<t>From the perspective of deterministic service requirements, 
	deterministic Quality of Service (QoS) in the network can be 
	divided into five types or levels:</t>
    <t>Level-1: bandwidth guarantee. The indicator requirements 
	include basic bandwidth guarantee and certain packet loss 
	tolerance. There is no requirement for the upper bound of 
	the latency, and no requirement for the jitter. Typical 
	services include download and FTP services.</t>	
    <t>Level-2: jitter guarantee. The indicator requirements 
	include: jitter 50ms, delay 300ms. Typical services include 
	synchronous voice services, such as voice call. </t>
    <t>Level-3: Latency guarantee. The indicator requirements include: 
	delay 50ms, jitter 50ms. Typical services include real-time 
	communication services, such as video, production monitoring, 
	and communication services. </t>
    <t>Level-4: low delay and low jitter guarantee. The indicator 
	requirements include: delay 20ms, jitter 5ms. Typical services 
	include video interaction services, such as AR/VR, holographic
	communication, cloud video and cloud games.</t>
    <t>Level-5: ultra-low delay and jitter guarantee. The indicator
	requirements include: delay 10ms, jitter 100us. Typical services 
	include production control services, such as power protection 
	and remote control.</t>
	
   <t>Moreover, different DetNet services is required to tolerate different 
	percentage of packet loss ratio such as 99.9%, 99.99%, 99.999%, and so on. </t>
  
   </section>
   <section title="Support the Utilization of Network Resources" numbered="true" toc="default">
   
   <t>Traditional Ethernet, IP and MPLS networks which is based on statistical
	multiplexing provides best-effort packet service and offers no delivery and 
	SLA guarantee. As described in <xref target="RFC8655" pageno="false" format="default"/>, the primary 
	technique by which DetNet achieves its QoS is to allocate sufficient resources.
	But it can not be achieved by not sufficient resource which can be allocated 
	due to practical and cost reason. So it is required to achieve the high-efficiency
	of resources utilization when provide the DetNet service.</t>
   </section>
   </section>   
	
   <section title="Characteristics of Large-Scale Deterministic Networks " numbered="true" toc="default">

   <section title="Large-scale Dynamic Flows " numbered="true" toc="default">
   
    <t>As described in <xref target="RFC8557" pageno="false" format="default"/>, deterministic forwarding can only apply to 
	flows with such well-defined characteristics as periodicity and burstiness. 
	As defined in DetNet architecture <xref target="RFC8655" pageno="false" format="default"/>, the traffic characteristics 
	of an App-flow can be CBR (constant bit rate) or VBR (variable bit rate) 
	of L1, L2 and L3 layers (VBR takes the maximum value when reserving resources). 
	But the current scenarios and technical solutions only consider CBR flow, 
	without considering the coexistence of VBR and CBR, the burst and aperiodicity
	of flows. The operations such as shaping or scheduling have not been specified.
	Even TSN mechanisms are based on a constant and forecastable traffic
    characteristics.</t>

    <t>It will be more complicated in a large-scale network where much more flows 
	coexist and the traffic characteristics is more dynamic. A huge number of 
	flows with different DetNet QoS requirements is dynamically concurrent 
	and the state of each flow cannot be maintained.  It is required to offer 
	reliable delivery and SLA guarantee for dynamic flows. For example,
	periodic flow and aperiodic flow (including micro burst flow, etc.), CBR 
	and VBR flow, flow with different periods or phases, etc. When the network
	needs to forward these deterministic flows at the same time, it must solve
	the problems of time micro bursts, queue processing and aggregation 
	of multiple flows. </t>
   
   </section>
   
   <section title="Large-scale Network Topology" numbered="true" toc="default">
   
    <t>In large-scale applications, the network topology may consists of a large 
	number of nodes and links which leads to difficulty with controlling the
	end-to-end delay and jitter. High speed, long-distance transmission and asymmetric
	links may also co-exists and affects the bounded latency such as increasing 
	transmission latency, jitter and packet loss in large-scale networks.</t>
	
	<t>The network topology in a large-scale network may across multiple 
	domains within a single administrative control or a closed group of 
	administrative control as per <xref target="RFC8655" pageno="false" format="default"/>. Moreover, DetNet domains or 
	nodes may be interconnected with different sub-network technologies 
	such as FlexE tunnels, TSN sub-network, IP/MPLS/SRv6 tunnels and so on.
	It is required to support the inter-domain deterministic
	metric and routes to achieve the end-to-end bounded latency.</t>

	</section>

   </section>
   
   <section title="Gap Analysis of Large-Scale Deterministic Networks" numbered="true" toc="default">
   
   <t>As defined in <xref target="RFC8938" pageno="false" format="default"/>, the DetNet data plane 
   describes how application flows, or App-flows are carried over DetNet networks 
   and it is provided by the DetNet service and forwarding sub-layers with DetNet-related
   data plane functions and mechanisms. This section analyzes the DetNet technical 
   gaps when applying the DetNet data plane as per RFC8938 in large-scale networks. </t>
      
   <section title="Gap Analysis of Providing Aggregated Flows Identification" numbered="true" toc="default">  
   
   <t>In <xref target="RFC8938" pageno="false" format="default"/>, the DetNet data plane can provide the DetNet-Specific 
   Metadata such as Flow-ID for both the service and forwarding sub-layers.
   The flow-based state information is required to be maintained 
   for per-flow processing rules. For example, the resource reservation 
   configuration is required for each flow. DetNet as per <xref target="RFC8938" pageno="false" format="default"/> 
   provides the capability to aggregate the individual flows to 
   downscale the operations of flow states. However, it still 
   requires large amount of control signaling to establish and 
   maintain DetNet flows. It may be challenging for network 
   operations with a large number of deterministic flows and network
   nodes in large-scale networks.</t>

   </section>
   
   <section title="Gap Analysis of Providing Deterministic Latency" numbered="true" toc="default"> 
   
   <t>As described in <xref target="RFC8655" pageno="false" format="default"/>, the primary goals are to achieve the 
   DetNet QoS to provide minimum and maximum end-to-end latency and
   bounded jitter, low packet loss ratio and an upper bound on 
   out-of-order packet delivery. But the data plane <xref target="RFC8938" pageno="false" format="default"/>
   particularly focuses on the DetNet service sub-layer which
   provides a set of Packet Replication, Elimination, and Ordering 
   Functions (PREOF) functions to provide end-to-end service assurance. 
   It mainly provides the capabilities for DetNet to guarantee the 
   reliability.</t>
   
   <t>The DetNet forwarding sub-layer provides corresponding
   forwarding assurance with IETF existing functions using resource 
   allocations and explicit routes. But these functions can not provide 
   the deterministic latency (bounded latency, low packet loss and in-order
   delivery) assurance in large-scale networks. The following sections
   mainly discuss the gap analysis for the forwarding sub-layer functions
   to provide deterministic latency assurance.</t>

    <section title="Gap Analysis of Explicit Routes" numbered="true" toc="default">
   
   <t>Traditional routes only have reachability. As per <xref target="RFC8938" pageno="false" format="default"/>,
   explicit optimized paths with allocation of resources should be
   provided to achieve the DetNet QoS. But the deterministic 
   requirements such as end-to-end delay and jitter are only used 
   as path computation constraints. Multiple network metrics
   which are measured and distributed by the routing system should
   be taken into consideration. </t> 
   
   <t>In large-scale networks, it may be challenging to compute the
   best path to meet all of the requirements. In multi-domain
   scenarios, the inter-domain deterministic routes need to be established
   and provisioned. Especially when interconnecting with sub-networks,
   the selection of intra-domain paths acrossing cooperating domains 
   should consider the bounded latency in each domain and the stitching
   of the paths.   </t>
   
   <t>Moreover, the paths vary with the real-time change of the network 
   topology. On the basic of the resources, the steering path and 
   routes for deterministic flows should be programmed before the flows coming 
   and able to provide SLA capability. And the routes should be considered to 
   be established in distributed and centralized control Plane.</t>

   <t>As described in <xref target="RFC8557" pageno="false" format="default"/>, the packet
   replication and elimination service protection should be provided to achieve the 
   low packet loss ratio. It will copy the flows and spread the data over multiple
   disjoint forwarding paths. The bounded latency and jitter of each path should
   be meet service deterministic requirement. And the difference of latency within
   these paths should be limited. So the replication and elimination deterministic 
   routes with configured latency and jitter policy should be taken into consideration. 
   It is required to generate two disjoint paths with very close delay to
   form 1+1 protection and perform concurrent transmission and dual reception, 
   and make replication and elimination on the egress PE. </t>  
   </section>
   
    <section title="Gap Analysis of Resources Allocation" numbered="true" toc="default">
  
   <t>As per <xref target="RFC8938" pageno="false" format="default"/>, the forwarding sub-layer uses buffer resources for
   packet queuing, as well as reservation and allocation of bandwidth
   capacity resources. In large-scale networks, the bandwidth, buffer 
   and scheduling resources are combined with queuing mechanisms to 
   guarantee the deterministic latency. The reservation and allocation
   of queuing related resources or deterministic latency resources 
   should be taken into consideration in DetNet data plane.</t>

   </section>

    <section title="Gap Analysis of Queuing Mechanisms" numbered="true" toc="default">
     
	<t>As per <xref target="RFC8938" pageno="false" format="default"/>, the forwarding sub-layer provides the QoS-related 
	functions needed by the DetNet flow including the use of queuing
    techniques. But the queuing techniques which are defined in existing 
	IETF technologies can not guarantee the bounded latency such as 
	Active Queue Management(AQM). And the queuing mechanisms which are
	defined in IEEE802.1 TSN can not be directly applied in large-scale 
	networks such Time Aware Shaping [IIEEE802.1Qbv] and Cyclic Queuing
	and Forwarding [IEEE802.1Qch] with time synchronization. </t>
	
	<t>Enhancement of queuing mechanisms have been discussed in DetNet 
	such as cyclic-scheduling queuing mechanism <xref target="I-D.dang-queuing-with-multiple-cyclic-buffers" format="default"/>,
	deadline-scheduling queuing mechanism <xref target="I-D.stein-srtsn" format="default"/> and 
	<xref target="I-D.peng-detnet-deadline-based-forwarding" format="default"/>, and 	
    asynchronous queuing mechanism <xref target="I-D.joung-detnet-asynch-detnet-framework" format="default"/>.
	The function of multiple queuing mechanisms and related DetNet-Specific 
	Metadata has not been defined in DetNet data plane.</t>
 

   </section>
   
   
   </section>

   </section>
  
   </section>
	
   <section title="Enhancements of DetNet Data Plane" numbered="true" toc="default">
   
    <t>As defined in <xref target="RFC8938" pageno="false" format="default"/>, the DetNet data plane 
   describes how application flows, or App-flows are carried over DetNet networks 
   and it is provided by the DetNet service and forwarding sub-layers with DetNet-related
   data plane functions and mechanisms. From charter and milestones, the enhanced 
   DetNet data plane is required to provide the enhancemant of flow identification and 
   packet treatment including the enhanced QoS-related functions and metadata 
   in large-scale networks.</t>

   <section title="Enhancements of Packet Treatment" numbered="true" toc="default">
   
   <t>This section proposes the enhancement for the DetNet Data Plane 
   Protocol Stack as shown in Figure 1 and the enhanced DetNet-related data plane
   functions and mechanisms should be provided by the DetNet service and 
   forwarding sub-layers.</t>
   
   <figure title="Enhanced Functions in DetNet Data Plane Protocol Stack" align="center" suppress-title="false" alt="" width="" height="">
   <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">

                 |  packets going  |            ^  packets coming   ^
                 v down the stack  v            |   up the stack    |
           +-----------------------------+   +----------------------------+
           |           Source            |   |        Destination         |
           +-----------------------------+   +----------------------------+
           |Service sub-layer:           |   |Service sub-layer:          |
           |  Flow Identification        |   |  Flow Identification       |
           +-----------------------------+   +----------------------------+
           |Forwarding sub-layer:        |   |Forwarding sub-layer:       |
           |  Deterministic Routes       |   |  Deterministic Routes      |
           |  Deterministic Resources    |   |  Deterministic Resources   |		   
           |  Queuing treatment          |   |  Queuing treatment         |  
           +-----------------------------+   +----------------------------+
           |       Lower layers          |   |       Lower layers         |
           +-----------------------------+   +----------------------------+
                             v                           ^
                              \_________________________/

  
   	</artwork>
  <postamble/>
 </figure>

	
    <section title="Flow Identification" numbered="true" toc="default">
	
   <t>From the perspective of differentiated services requirements in section 3.1.1, 
   a large-scale network needs to provide the deterministic service for 
   various applications. And the deterministic service may demand different
   DetNet QoS levels according to different application scenarios. The DetNet
   data plane should support the identification of multiple flows and the
   differentiated deterministic QoS for each DetNet flow. </t>
   
   <t>According to the gap described in section 3.3.1, this document proposes
   the enhanced DetNet data plane to support flow identification of DetNet 
   differentiated services with service-level identification. It may downscale 
   the network operations with a large number of deterministic flows and network
   nodes in large-scale networks.</t>

    </section>

   <section title="Deterministic Routes" numbered="true" toc="default">
   
   <t>As discussed in section 3.3.2.1, it may be challenging to compute the
   best path to meet all of the requirements and the the paths vary with 
   the real-time change of the network topology in large-scale networks.
   The explicit routes may be not appropriate for large-scale networks.
   This document propose the deterministic routes which can be strict explicit
   paths or loose routes. The former is applicable to centralized scenarios 
   with controllers, and the latter is applicable to distributed scenarios. </t>
   
   <section title="Deterministic Links" numbered="true" toc="default">
   
   <t>As discussed in section 3.3.2.1, it may be challenging to compute the
   best path to meet all of the requirements within a large-scale network
   topology pool including multiple network metrics.  This document proposes
   the deterministic links to provide a one-dimensional deterministic metric
   to guarantee for the deterministic forwarding capabilities at different levels.</t>
   
   <t>The computing end-to-end delay bounds is defined in <xref target="I-D.ietf-detnet-bounded-latency" pageno="false" format="default"/>.
   It is the sum of non-queuing delay bound and queuing delay bound in DetNet 
   bounded latency model. The upper bounds of queuing delay depends on the 
   queuing mechanisms deployed along the path. For example, a link with a 
   queuing mechanism that does not guarantee a bounded delay a non-determinisitc
   link and a link with a queuing mechanism that can provide deterministic delay
   is called a deterministic link. The delay of a a deterministic link is
   consist of the propagation delay of the packet on the link and the
   queuing delay of the packet at the node. A deterministic link can be 
   a sub-network that provides deterministic transmission or a Point-to-Point (P2P)
   link. The deterministic links could be distributed by IGP protocol as 
   per <xref target="I-D.peng-lsr-flex-algo-deterministic-routing" pageno="false" format="default"/>.</t>
   
   </section>
   
   <section title="Inter-domain Deterministic Routes" numbered="true" toc="default">
   
   <t>As discussed in section 3.3.2.1, the inter-domain deterministic routes need to 
   be established and provisioned in multi-domain scenarios. The stitching
   of the intra-domain paths should be considered in DetNet data plane.</t>
   
   <t>In the centralized scenario, when the source and destination PEs of a 
   deterministic service are located at the two ends with a limited physical range,
   one controller (single domain) or multiple controllers (cross domains) compute
   one or more paths with deterministic SLA according to the typical Traffic 
   Specification (T-SPEC) based on the collected deterministic resources, 
   or compute dynamically according to the service T-SPEC as required by 
   the services. </t>
   
   <t>In the distributed scenario, deterministic loose routes are computed 
   on the device through routing protocols. Interior Gateway Protocol (IGP)
   is used to compute deterministic routes based on deterministic-delay inside a
   domain, and Border Gateway Protocol (BGP) is used to compute deterministic 
   routes based on accurate delay/jitter across domains.</t>
   
  </section>
  </section>

   <section title="Deterministic Resources" numbered="true" toc="default">
   
   
   <t>As discussed in section 3.3.2.2, the reservation and allocation
   of queuing related resources or deterministic latency resources 
   should be taken into consideration in DetNet data plane. The networks need to 
   shield the differences between network capabilities. Deterministic resource 
   is the basis for providing deterministic network services. It refers to the 
   resources that meet the deterministic indicators of a node and link processing
   as well as the corresponding resource processing mechanisms (such as link 
   bandwidth, queues, and scheduling algorithms). It is required to make unified 
   modeling for all the deterministic resources. The deterministic links are 
   provided and distributed to support the deterministic resource and forwarding
   capabilities.</t>
   
   <t>As discussed in section 3.1.2, it is necessary to make overall resource
   planning and scheduling for the network to achieve the high-efficiency of 
   resources utilization when provide multiple DetNet services. The admission
   control policy of a flow should take into account the deterministic resource. 
   </t>
  
   </section>
   
   <section title="Queuing treatment" numbered="true" toc="default">   
   
   <t>As dicussed in section 3.3.2.3, it is required to support the
   enhancement of queuing mechanisms. Multiple queuingmechanisms can provide
   different levels of latency, jitter and other guarantees. The 
   DetNet forwarding sub-layer may provide the function and technology
   such as multiple queuing and traffic treatment for DetNet application
   flows. The DetNet data plane may also encode the queuing related 
   information in packets. The encapsulation of a DetNet flow allows
   the packets to be sent over an unique queuing technology. The DetNet 
   forwarding nodes along the path can follow the queue scheduling 
   carried in the packet to achieve the end-to-end bounded latency.</t>
   
   <t>The DetNet forwarding sub-layer may provide capabilities applying 
   existing queuing mechanisms or traffic treatment. For example, 
   the traffic treatment has been proposed in [draft-du-detnet-layer3-low-latency] 
   to decrease the micro-bursts in layer3 network for low-latency traffic.
   The time-scheduling queuing mechanisms includes the Time Aware Shaping 
   [IIEEE802.1Qbv] and priority-scheduling includes the Credit-Based 
   Shaper[IEEE802.1Q-2014] with Asynchronous Traffic Shaping[IEEE802.1Qcr]. 
   The cyclic-scheduling queuing mechanism has been proposed in 
   [IEEE802.1Qch] and improved in <xref target="I-D.dang-queuing-with-multiple-cyclic-buffers" pageno="false" format="default"/>.
    The deadline-scheduling queuing mechanism has been proposed in 
	<xref target="I-D.stein-srtsn" pageno="false" format="default"/> and improved in <xref target="I-D.peng-detnet-deadline-based-forwarding" pageno="false" format="default"/>.	
    The per-flow queuing mechanism includes Guaranteed-Service Integrated 
	service (IntServ) <xref target="RFC2212" pageno="false" format="default"/>. </t>
   </section> 
   
   </section>
   
   <section title="Enhancements of DetNet-Specific Metadata" numbered="true" toc="default">

   <t>1. deterministic latency information</t>
  
   <t>DetNet forwarding sub-layer may provide the function and technology
   such as multiple queuing and traffic treatment for DetNet application
   flows to guarantee the deterministic latency. The DetNet data plane 
   may also encode the deterministic latency related information in packets.</t>
   
   <t>The information ensuring deterministic latency should be provided 
   for enhanced data plane as defined in <xref target="I-D.xiong-detnet-6man-queuing-option" pageno="false" format="default"/> 
   and <xref target="I-D.sx-detnet-mpls-queue" pageno="false" format="default"/>.
   For example, the encapsulation of a DetNet flow allows the packets to
   be sent over an unique queuing mechanism. It is required to carry 
   queuing related information in data plane so as to make appropriate
   packet forwarding and scheduling decisions to meet the time bounds. </t>
   
   </section> 
   
   <section title="Enhancements of DetNet IP/MPLS/SRv6 Data Plane" numbered="true" toc="default">
   
   <t>An IP data plane may operate natively or through the use of an
   encapsulation. IP encapsulation can satisfy enhanced DetNet
   requirements. Explicit inclusion of the flow identification, path 
   selection, queuing and traffic treatment is possible through the 
   use of IP options, IP extension headers or existing IP headers.
   For example, the queuing information has been carried in IPv6/SRv6 
   networks as defined in <xref target="I-D.xiong-detnet-6man-queuing-option" pageno="false" format="default"/>.
   </t>
   
   <t>MPLS provides a service sub-layer for traffic by adding 
   specific flow attributes (S-label and d-cw) in packets. MPLS provides
   a forwarding sub-layer for traffic over implicit and explicit paths
   such as F-Labels. Explicit inclusion of queuing and traffic treatment
   is possible through the use of MPLS metadata or MPLS TC field as defined
   in <xref target="I-D.sx-detnet-mpls-queue" pageno="false" format="default"/> and 
   <xref target="I-D.eckert-detnet-mpls-tc-tcqf" pageno="false" format="default"/>.</t>
   
   </section>
   
   
   </section>

   <section title="Controller Plane (Management and Control) Considerations" numbered="true" toc="default">
   
   <section title="Management and Scheduling of Multiple Queuing Mechanisms" numbered="true" toc="default"> 
	
    <t>As described in <xref target="I-D.liu-detnet-large-scale-requirements" pageno="false" format="default"/> 
	section 3.6.1, it is required to support the configuration of multiple 
	queuing mechanisms. Different queuing mechanisms may be supported at
    different levels of latency, jitter and other guarantees. The type of
	queuing mechanism and the related queuing parameters should be 
	advertised and configured. For example, the deterministic links with 
	queuing resource could be distributed by IGP protocol as per
	<xref target="I-D.peng-lsr-flex-algo-deterministic-routing" pageno="false" format="default"/>.
	And the queuing parameters are carried in deterministic latency
    information may be selected in path computation as per <xref target="I-D.xiong-pce-detnet-bounded-latency" pageno="false" format="default"/>.	
	</t>
   
   </section>
   
   <section title="Distributed Deterministic Path" numbered="true" toc="default">
   
   <t>The deterministic routes may be loose routes in distributed scenarios. 
   It is required to support the distributed deterministic routes which are 
   established by distributed protocols such as IGP as defined in 
   <xref target="I-D.peng-lsr-flex-algo-deterministic-routing" pageno="false" format="default"/>.</t>
   
   </section>
   
   <section title="Inter-domain Deterministic Path" numbered="true" toc="default"> 
    <t>In large-scale deterministic networks, it may across multiple network 
	domains, it is required to support the inter-domain deterministic routes
    to achieve the end-to-end latency, bounded jitter. And the deadline of 
	latency and jitter of each domain and segment should be determined and 
	controlled. The inter-domain mechanism MUST be considered at the boundary
	nodes such as BGP configurations defined in <xref target="I-D.peng-idr-bgp-metric-credit" pageno="false" format="default"/>.</t>
   
   </section>
   
   <section title="Deterministic Path Computation" numbered="true" toc="default"> 
   <t>As defined in <xref target="I-D.xiong-pce-detnet-bounded-latency" pageno="false" format="default"/>, the deterministic latency
   constraints can be carried in PCEP extensions and the end-to-end deterministic 
   path computation should be achieved for DetNet service.</t>
   
   </section>
   
   <section title="Configuration of Flow Mapping" numbered="true" toc="default"> 
   <t>As defined in  <xref target="I-D.xiong-idr-detnet-flow-mapping" pageno="false" format="default"/>, the BGP flowspec 
   can be used for the filtering of the packets that match the DetNet networks
   and the mapping between TSN streams and DetNet flows in the control plane.</t>
   </section> 
   
   </section>
   
   <section title="Security Considerations" numbered="true" toc="default">
    <t>TBA</t>
   </section>

   <section anchor="Acknowledgements" title="Acknowledgements" numbered="true" toc="default">
    <t>The authors would like to thank Peng Liu, Bin Tan, Aihua Liu 
	Shaofu Peng for their review, suggestions and comments to this document.</t>
    </section>
	
	<section anchor="IANA" title="IANA Considerations" numbered="true" toc="default">
	<t>TBA</t>
    </section>

	
 </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
  
    <references title="Normative References">
    <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
<date year="1997" month="March"/>
<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="RFC8655" target="https://www.rfc-editor.org/info/rfc8655">
<front>
<title>Deterministic Networking Architecture</title>
<author initials="N." surname="Finn" fullname="N. Finn"><organization/></author>
<author initials="P." surname="Thubert" fullname="P. Thubert"><organization/></author>
<author initials="B." surname="Varga" fullname="B. Varga"><organization/></author>
<author initials="J." surname="Farkas" fullname="J. Farkas"><organization/></author>
<date year="2019" month="October"/>
<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="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba"><organization/></author>
<date year="2017" month="May"/>
<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="RFC8557" target="https://www.rfc-editor.org/info/rfc8557">
<front>
<title>Deterministic Networking Problem Statement</title>
<author initials="N." surname="Finn" fullname="N. Finn"><organization/></author>
<author initials="P." surname="Thubert" fullname="P. Thubert"><organization/></author>
<date year="2019" month="May"/>
<abstract><t>This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties.</t></abstract>
</front>
<seriesInfo name="RFC" value="8557"/>
<seriesInfo name="DOI" value="10.17487/RFC8557"/>
</reference>
<reference anchor="RFC8578" target="https://www.rfc-editor.org/info/rfc8578">
<front>
<title>Deterministic Networking Use Cases</title>
<author initials="E." surname="Grossman" fullname="E. Grossman" role="editor"><organization/></author>
<date year="2019" month="May"/>
<abstract><t>This document presents use cases for diverse industries that have in common a need for "deterministic flows".  "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data.  These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet).  For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.</t></abstract>
</front>
<seriesInfo name="RFC" value="8578"/>
<seriesInfo name="DOI" value="10.17487/RFC8578"/>
</reference>
<reference anchor="RFC8938" target="https://www.rfc-editor.org/info/rfc8938" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane Framework</title>
          <author fullname="B. Varga" initials="B." role="editor" surname="Varga"/>
          <author fullname="J. Farkas" initials="J." surname="Farkas"/>
          <author fullname="L. Berger" initials="L." surname="Berger"/>
          <author fullname="A. Malis" initials="A." surname="Malis"/>
          <author fullname="S. Bryant" initials="S." surname="Bryant"/>
          <date month="November" year="2020"/>
          <abstract>
            <t>This document provides an overall framework for the Deterministic Networking (DetNet) data plane.  It covers concepts and considerations that are generally common to any DetNet data plane specification.  It describes related Controller Plane considerations as well.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8938"/>
        <seriesInfo name="DOI" value="10.17487/RFC8938"/>
      </reference>
<reference anchor="RFC2212" target="https://www.rfc-editor.org/info/rfc2212" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2212.xml">
        <front>
          <title>Specification of Guaranteed Quality of Service</title>
          <author fullname="S. Shenker" initials="S." surname="Shenker"/>
          <author fullname="C. Partridge" initials="C." surname="Partridge"/>
          <author fullname="R. Guerin" initials="R." surname="Guerin"/>
          <date month="September" year="1997"/>
          <abstract>
            <t>This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2212"/>
        <seriesInfo name="DOI" value="10.17487/RFC2212"/>
      </reference>
<reference anchor="I-D.ietf-detnet-bounded-latency" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-detnet-bounded-latency.xml" target="https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-10.txt">
        <front>
          <title>DetNet Bounded Latency</title>
          <author fullname="Norman Finn">
            <organization>Huawei Technologies Co. Ltd</organization>
          </author>
          <author fullname="Jean-Yves Le Boudec">
            <organization>EPFL</organization>
          </author>
          <author fullname="Ehsan Mohammadpour">
            <organization>EPFL</organization>
          </author>
          <author fullname="Jiayi Zhang">
            <organization>Huawei Technologies Co. Ltd</organization>
          </author>
          <author fullname="Balazs Varga">
            <organization>Ericsson</organization>
          </author>
          <date month="April" day="8" year="2022"/>
          <abstract>
            <t>   This document presents a timing model for sources, destinations, and
   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="Internet-Draft" value="draft-ietf-detnet-bounded-latency-10"/>
      </reference>
<reference anchor="I-D.ietf-detnet-controller-plane-framework" target="https://www.ietf.org/archive/id/draft-ietf-detnet-controller-plane-framework-02.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-detnet-controller-plane-framework.xml">
        <front>
          <title>Deterministic Networking (DetNet) Controller Plane Framework</title>
          <author fullname="Andrew G. Malis">
            <organization>Independent</organization>
          </author>
          <author fullname="Xuesong Geng">
            <organization>Huawei</organization>
          </author>
          <author fullname="Mach (Guoyi) Chen">
            <organization>Huawei</organization>
          </author>
          <author fullname="Fengwei Qin">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Balazs Varga">
            <organization>Ericsson</organization>
          </author>
          <date day="28" month="June" year="2022"/>
          <abstract>
            <t>This document provides a framework overview for the Deterministic Networking (DetNet) controller plane. It discusses concepts and requirements for DetNet controller plane which could be basis for future solution specification.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-controller-plane-framework-02"/>
      </reference>
<reference anchor="I-D.liu-detnet-large-scale-requirements" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.liu-detnet-large-scale-requirements.xml" target="https://www.ietf.org/archive/id/draft-liu-detnet-large-scale-requirements-02.txt">
        <front>
          <title>Requirements for Large-Scale Deterministic Networks</title>
          <author fullname="Peng Liu">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Yizhou Li">
            <organization>Huawei</organization>
          </author>
          <author fullname="Toerless Eckert">
            <organization>Futurewei Technologies USA</organization>
          </author>
          <author fullname="Quan Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Jeong-dong Ryoo">
            <organization>ETRI</organization>
          </author>
          <date month="April" day="10" year="2022"/>
          <abstract>
            <t>   Aiming at the large-scale deterministic network, this document
   describes the technical and operational requirements when the
   different deterministic levels of applications co-exist and are
   transported over a wide area.  This document also describes the
   corresponding Deterministic Networking (DetNet) data plane
   enhancement requirements.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-liu-detnet-large-scale-requirements-02"/>
      </reference>
<reference anchor="I-D.sx-detnet-mpls-queue" target="https://www.ietf.org/archive/id/draft-sx-detnet-mpls-queue-00.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.sx-detnet-mpls-queue.xml">
        <front>
          <title>DetNet Queue Encapsulation with MPLS Data Plane</title>
          <author fullname="Xueyan Song">
            <organization>ZTE Corp.</organization>
          </author>
          <author fullname="Quan Xiong">
            <organization>ZTE Corp.</organization>
          </author>
          <date day="24" month="June" year="2022"/>
          <abstract>
            <t>This document specifies format and principals for the MPLS header which contains the queuing delay information, designed for use over a DetNet network with MPLS data plane. The guaranteed delay support enables forwarding and scheduling decisions for time-sensitive service running on DetNet transit nodes that operate within a constrained network domain. This document also specifies a representation for the delay field values in such networks.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-sx-detnet-mpls-queue-00"/>
      </reference>
<reference anchor="I-D.pthubert-detnet-ipv6-hbh" target="https://www.ietf.org/archive/id/draft-pthubert-detnet-ipv6-hbh-07.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.pthubert-detnet-ipv6-hbh.xml">
        <front>
          <title>IPv6 Options for DetNet</title>
          <author fullname="Pascal Thubert">
            <organization>Cisco Systems, Inc</organization>
          </author>
          <author fullname="Fan Yang">
            <organization>Huawei Technologies</organization>
          </author>
          <date day="22" month="February" year="2022"/>
          <abstract>
            <t>RFC 8938, the Deterministic Networking Data Plane Framework relies on the 6-tuple to identify an IPv6 flow. But the full DetNet operations require also the capabilities to signal meta-information such as a sequence within that flow, and to transport different types of packets along the same path with the same treatment, e.g., Operations, Administration, and Maintenance packets and/or multiple flows with fate and resource sharing. This document introduces new IPv6 options that signal that path and redundancy information to the intermediate DetNet relay and forwarding nodes.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-pthubert-detnet-ipv6-hbh-07"/>
      </reference>
<reference anchor="I-D.xiong-detnet-6man-queuing-option" target="https://www.ietf.org/archive/id/draft-xiong-detnet-6man-queuing-option-02.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.xiong-detnet-6man-queuing-option.xml">
        <front>
          <title>DetNet Deterministic Latency Option for IPv6</title>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Aihua Liu" initials="A." surname="Liu">
            <organization>ZTE Corporation</organization>
          </author>
          <date day="29" month="September" year="2022"/>
          <abstract>
            <t>This document introduces new IPv6 options to identify the Deterministic Latency related information for DetNet flows in IPv6 and SRv6 networks.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-6man-queuing-option-02"/>
      </reference>	
<reference anchor="I-D.joung-detnet-asynch-detnet-framework" target="https://www.ietf.org/archive/id/draft-joung-detnet-asynch-detnet-framework-00.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.joung-detnet-asynch-detnet-framework.xml">
        <front>
          <title>Asynchronous Deterministic Networking Framework for Large-Scale Networks</title>
          <author fullname="Jinoo Joung">
            <organization>Sangmyung University</organization>
          </author>
          <author fullname="Jeong-dong Ryoo">
            <organization>ETRI</organization>
          </author>
          <author fullname="Taesik Cheung">
            <organization>ETRI</organization>
          </author>
          <author fullname="Yizhou Li">
            <organization>Huawei</organization>
          </author>
          <author fullname="Peng Liu">
            <organization>China Mobile</organization>
          </author>
          <date day="26" month="June" year="2022"/>
          <abstract>
            <t>This document describes an overall framework of Asynchronous Deterministic Networking (ADN) for large-scale networks. It specifies the functional architecture and requirements for providing latency and jitter bounds to high priority traffic, without time- synchronization of network nodes.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-joung-detnet-asynch-detnet-framework-00"/>
      </reference>
<reference anchor="I-D.dang-queuing-with-multiple-cyclic-buffers" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.dang-queuing-with-multiple-cyclic-buffers.xml" target="https://www.ietf.org/archive/id/draft-dang-queuing-with-multiple-cyclic-buffers-00.txt">
        <front>
          <title>A Queuing Mechanism with Multiple Cyclic Buffers</title>
          <author fullname="Bingyang Liu">
            <organization>Huawei</organization>
          </author>
          <author fullname="Joanna Dang">
            <organization>Huawei</organization>
          </author>
          <date month="February" day="22" year="2021"/>
          <abstract>
            <t>   This document presents a queuing mechanism with multiple cyclic
   buffers.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-dang-queuing-with-multiple-cyclic-buffers-00"/>
      </reference>
<reference anchor="I-D.stein-srtsn" 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="I-D.peng-detnet-deadline-based-forwarding" 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-01.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-01"/>
      </reference>	  
<reference anchor="I-D.eckert-detnet-mpls-tc-tcqf" target="https://www.ietf.org/archive/id/draft-eckert-detnet-mpls-tc-tcqf-03.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.eckert-detnet-mpls-tc-tcqf.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane - MPLS TC Tagging for Cyclic Queuing and Forwarding (MPLS-TC TCQF)</title>
          <author fullname="Toerless Eckert" surname="Toerless Eckert">
            <organization>Futurewei Technologies USA</organization>
          </author>
          <author fullname="Stewart Bryant" surname="Stewart Bryant">
            <organization>University of Surrey ICS</organization>
          </author>
          <author fullname="Andrew G. Malis" initials="G." surname="Andrew Malis">
            <organization>Malis Consulting</organization>
          </author>
          <date day="11" month="July" year="2022"/>
          <abstract>
            <t>This memo defines the use of the MPLS TC field of MPLS Label Stack Entries (LSE) to support cycle tagging of packets for Multiple Buffer Cyclic Queuing and Forwarding (TCQF). TCQF is a mechanism to support bounded latency forwarding in DetNet network. 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-mpls-tc-tcqf-03"/>
      </reference>
<reference anchor="I-D.peng-lsr-flex-algo-deterministic-routing" target="https://www.ietf.org/archive/id/draft-peng-lsr-flex-algo-deterministic-routing-03.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.peng-lsr-flex-algo-deterministic-routing.xml">
        <front>
          <title>IGP Flexible Algorithm with Deterministic Routing</title>
          <author fullname="Shaofu Peng" surname="Shaofu Peng">
            <organization>ZTE</organization>
          </author>
          <author fullname="Tony Li" surname="Tony Li">
            <organization>Juniper Networks</organization>
          </author>
          <date day="24" month="August" year="2022"/>
          <abstract>
            <t>IGP Flexible Algorithm proposes a solution that allows IGPs to compute constraint based paths over the network and specifies a way of using Segment Routing (SR) Prefix-SIDs, SRv6 locators, or pure IP prefixes to steer packets along the constraint-based paths. This document describes how to compute deterministic delay paths within a Flex-Algorithm topology.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-peng-lsr-flex-algo-deterministic-routing-03"/>
      </reference>
<reference anchor="I-D.xiong-pce-detnet-bounded-latency" target="https://www.ietf.org/archive/id/draft-xiong-pce-detnet-bounded-latency-01.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.xiong-pce-detnet-bounded-latency.xml">
        <front>
          <title>PCEP Extension for DetNet Bounded Latency</title>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <date day="9" month="October" year="2022"/>
          <abstract>
            <t>In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions to PCEP to carry deterministic latency constraints and distribute deterministic paths for end-to-end path computation in DetNet service.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-pce-detnet-bounded-latency-01"/>
      </reference>  
<reference anchor="I-D.peng-idr-bgp-metric-credit" target="https://www.ietf.org/archive/id/draft-peng-idr-bgp-metric-credit-00.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.peng-idr-bgp-metric-credit.xml">
        <front>
          <title>BGP Metric Credit Based Routing</title>
          <author fullname="Shaofu Peng" surname="Shaofu Peng">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Bin Tan" surname="Bin Tan">
            <organization>ZTE Corporation</organization>
          </author>
          <date day="28" month="December" year="2021"/>
          <abstract>
            <t>This document defines an optional metric related BGP path attribute that can be advertised with BGP intent routes, to provide more clear intent information used for the next-hop resolution.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-peng-idr-bgp-metric-credit-00"/>
      </reference>
<reference anchor="I-D.xiong-idr-detnet-flow-mapping" target="https://www.ietf.org/archive/id/draft-xiong-idr-detnet-flow-mapping-03.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.xiong-idr-detnet-flow-mapping.xml">
        <front>
          <title>BGP Flow Specification for DetNet and TSN Flow Mapping</title>
          <author fullname="Quan Xiong" surname="Quan Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Haisheng Wu" surname="Haisheng Wu">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Junfeng Zhao" surname="Junfeng Zhao">
            <organization>CAICT</organization>
          </author>
          <author fullname="Dong Yang" surname="Dong Yang">
            <organization>Beijing Jiaotong University</organization>
          </author>
          <date day="13" month="September" year="2022"/>
          <abstract>
            <t>This document proposes extensions to BGP Flow Specification for the flow mapping of Deterministic Networking (DetNet) when interconnected with IEEE 802.1 Time-Sensitive Networking (TSN). The BGP flowspec is used for the filtering of the packets that match the DetNet newtworks and the mapping between TSN streams and DetNet flows in the control plane.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-idr-detnet-flow-mapping-03"/>
      </reference>	  
	  
	  </references>
        
  </back>
</rfc>
