<?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-xiong-detnet-enhanced-detnet-gap-analysis-01" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.4 -->
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <title abbrev="Gap Analysis for Enhanced DetNet Data Plane">Gap Analysis for Enhanced DetNet Data Plane</title>
    <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-enhanced-detnet-gap-analysis-01"/>
    <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>
    <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 describes the requirements for multiple deterministic services 
   with differentiated DetNet QoS, discusses the characteristics of scaling 
   networks and analyzes the gaps of the existing technologies especially applying 
   the DetNet data plane as per RFC8938.</t>
    </abstract>
  </front>
  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>As per <xref target="RFC8655" format="default"/>, it defined the
   overall architecture for Deterministic Networking (DetNet) , which provides a capability for 
   real-time applications with extremely low data loss rates and bounded 
   latency within a network domain. It has three goals: minimum and maximum 
   end-to-end latency from source to destination, bounded jitter (packet 
   delay variation), packet loss ratio and upper bound on out-of-order 
   packet delivery. To achieve the above objectives, multiple techniques 
   need to be used in combination, including explicit routes, service 
   protection and resource allocation defined by DetNet.</t>
      <t>As defined in <xref target="RFC8938" 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. The enhanced 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. 
   It is required to analyse the applicability in DetNet for large-scale
   networks.</t>
      <t>This document describes the requirements for multiple deterministic services 
   with differentiated DetNet QoS, discusses the characteristics of large-scale 
   networks and analyzes the gaps of the existing technologies especially applying 
   the DetNet data plane as per <xref target="RFC8938" format="default"/>.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Conventions used in this document</name>
      <section numbered="true" toc="default">
        <name>Terminology</name>
        <t>The terminology is defined as <xref target="RFC8655" format="default"/> and <xref target="RFC8938" format="default"/>.</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>Service Requirements of Scaling Deterministic Networks</name>
      <section numbered="true" toc="default">
        <name>Support the Differentiated DetNet QoS of Multiple Services</name>
        <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" 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" format="default"/>, DetNet applications differ in their 
	network topologies and specific desired behavior and different services 
	requires differentiated DetNet QoS. In large-scale networks, multiple 
	services with differentiated DetNet QoS can be co-existed in the same DetNet 
	network. The classification of the deterministic flows within different 
	levels 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>
          <name>The classification of multiple services</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[	
		 
   +-------------+-----------+----------+----------+----------+-----------+
   | Item        | Level-1   | Level-2  | Level-3  | Level-4  |  Level-5  |
   +-------------+-----------+----------+----------+----------+-----------+
   | Applications| Email     |  Voice   | Audio and| AR/VR    | Industrial|
   | Examples    |           |          | Video    |          |           |
   +-------------+-----------+----------+----------+----------+-----------+   
   | DetNet QoS  | Bandwidth | Jitter   | Delay    | Low      | Ultra-low |
   |             | Guarantee | Guarantee| Guarantee| delay    |  delay and|
   |             |           |          |          |and jitter|  jitter   |
   +-------------+-----------+----------+----------+----------+-----------+
  
   	   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <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: delay 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 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 numbered="true" toc="default">
        <name>Support the Utilization of Network Resources</name>
        <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" 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 numbered="true" toc="default">
      <name>Characteristics of Scaling Deterministic Networks</name>
      <section numbered="true" toc="default">
        <name>Large-scale Dynamic Flows</name>
        <t>As described in <xref target="RFC8557" 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" 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 numbered="true" toc="default">
        <name>Large-scale Network Topology</name>
        <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" 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 numbered="true" toc="default">
      <name>Gap Analysis of Scaling Deterministic Networks</name>
      <t>As defined in <xref target="RFC8938" 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.
   <xref target="I-D.xiong-detnet-large-scale-enhancements" format="default"/> has
   proposed the overall framework of DetNet enhancements for scaling
   deterministic networks based on the gaps.</t>
      <section numbered="true" toc="default">
        <name>Gap Analysis of Providing Flows Identification</name>
        <t>In <xref target="RFC8938" 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" 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. It may provide traffic class scheduling
   than the flow scheduling. And the traffic class for DetNet should
   consider the requirements of multiple services with differentiated DetNet QoS.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Gap Analysis of Providing Deterministic Latency</name>
        <t>As described in <xref target="RFC8655" 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" 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 numbered="true" toc="default">
          <name>Gap Analysis of Explicit Routes</name>
          <t>Traditional routes only have reachability. As per <xref target="RFC8938" 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" 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 numbered="true" toc="default">
          <name>Gap Analysis of Resources Allocation</name>
          <t>As per <xref target="RFC8938" format="default"/>, the forwarding sub-layer uses buffer resources for
   packet queuing, as well as reservation and allocation of bandwidth
   capacity resources. The reservation of the bandwidth can not guarantee
   the deterministic latency. In large-scale networks, the bandwidth, buffer 
   and scheduling resources are combined with queuing mechanisms to 
   guarantee the deterministic latency. The deterministic resources may 
   be include the resources that can guarantee the deterministic latency
   such as the nodes, links, interfaces, buffers, bandwidth, queuing and
   scheduling mechanisms and so on. The planning, reservation and allocation
   of deterministic resources should be taken into consideration in DetNet 
   data plane.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Gap Analysis of Queuing Mechanisms</name>
          <t>As per <xref target="RFC8938" 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.eckert-detnet-tcqf" format="default"/>, 
	<xref target="I-D.dang-queuing-with-multiple-cyclic-buffers" format="default"/> and 
	<xref target="I-D.chen-detnet-sr-based-bounded-latency" 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"/>, timeslot-scheduling
    queuing mechanism <xref target="I-D.peng-detnet-packet-timeslot-mechanism" format="default"/> and 	
    asynchronous queuing mechanism <xref target="I-D.joung-detnet-asynch-detnet-framework" format="default"/> and 
	<xref target="I-D.joung-detnet-stateless-fair-queuing" format="default"/>.
	The queuing-based requirements in DetNet enhanced data plane has been 
	described in <xref target="I-D.ietf-detnet-scaling-requirements" format="default"/>.
	The function of multiple queuing mechanisms and related DetNet-Specific 
	metadata should be defined in DetNet data plane as per <xref target="I-D.xiong-detnet-data-fields-edp" format="default"/>.</t>
        </section>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>TBA</t>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>TBA</t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</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="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="RFC8964" target="https://www.rfc-editor.org/info/rfc8964" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane: MPLS</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"/>
          <author fullname="J. Korhonen" initials="J." surname="Korhonen"/>
          <date month="January" year="2021"/>
          <abstract>
            <t>This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network.  It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms.  This document builds on the DetNet architecture and data plane framework.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8964"/>
        <seriesInfo name="DOI" value="10.17487/RFC8964"/>
      </reference>
      <reference anchor="RFC8956" target="https://www.rfc-editor.org/info/rfc8956" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8956.xml">
        <front>
          <title>Dissemination of Flow Specification Rules for IPv6</title>
          <author fullname="C. Loibl" initials="C." role="editor" surname="Loibl"/>
          <author fullname="R. Raszuk" initials="R." role="editor" surname="Raszuk"/>
          <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
          <date month="December" year="2020"/>
          <abstract>
            <t>"Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets.</t>
            <t>This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8956"/>
        <seriesInfo name="DOI" value="10.17487/RFC8956"/>
      </reference>
      <reference anchor="RFC9023" target="https://www.rfc-editor.org/info/rfc9023" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9023.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)</title>
          <author fullname="B. Varga" initials="B." role="editor" surname="Varga"/>
          <author fullname="J. Farkas" initials="J." surname="Farkas"/>
          <author fullname="A. Malis" initials="A." surname="Malis"/>
          <author fullname="S. Bryant" initials="S." surname="Bryant"/>
          <date month="June" year="2021"/>
          <abstract>
            <t>This document specifies the Deterministic Networking IP data plane when operating over a Time-Sensitive Networking (TSN) sub-network.  This document does not define new procedures or processes.  Whenever this document makes statements or recommendations, these are taken from normative text in the referenced RFCs.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9023"/>
        <seriesInfo name="DOI" value="10.17487/RFC9023"/>
      </reference>
      <reference anchor="RFC9024" target="https://www.rfc-editor.org/info/rfc9024" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9024.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS</title>
          <author fullname="B. Varga" initials="B." role="editor" surname="Varga"/>
          <author fullname="J. Farkas" initials="J." surname="Farkas"/>
          <author fullname="A. Malis" initials="A." surname="Malis"/>
          <author fullname="S. Bryant" initials="S." surname="Bryant"/>
          <author fullname="D. Fedyk" initials="D." surname="Fedyk"/>
          <date month="June" year="2021"/>
          <abstract>
            <t>This document specifies the Deterministic Networking data plane when Time-Sensitive Networking (TSN) networks are interconnected over a DetNet MPLS network.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9024"/>
        <seriesInfo name="DOI" value="10.17487/RFC9024"/>
      </reference>
      <reference anchor="RFC8578" target="https://www.rfc-editor.org/info/rfc8578" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8578.xml">
        <front>
          <title>Deterministic Networking Use Cases</title>
          <author fullname="E. Grossman" initials="E." role="editor" surname="Grossman"/>
          <date month="May" year="2019"/>
          <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="RFC8557" target="https://www.rfc-editor.org/info/rfc8557" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8557.xml">
        <front>
          <title>Deterministic Networking Problem Statement</title>
          <author fullname="N. Finn" initials="N." surname="Finn"/>
          <author fullname="P. Thubert" initials="P." surname="Thubert"/>
          <date month="May" year="2019"/>
          <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="I-D.stein-srtsn" target="https://datatracker.ietf.org/doc/html/draft-stein-srtsn-01" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.stein-srtsn.xml">
        <front>
          <title>Segment Routed Time Sensitive Networking</title>
          <author fullname="Yaakov (J) Stein" initials="Y. J." surname="Stein">
            <organization>RAD</organization>
          </author>
          <date day="29" month="August" 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" target="https://datatracker.ietf.org/doc/html/draft-peng-detnet-deadline-based-forwarding-05" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.peng-detnet-deadline-based-forwarding.xml">
        <front>
          <title>Deadline Based Deterministic Forwarding</title>
          <author fullname="Shaofu Peng" initials="S." surname="Peng">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Dong Yang" initials="D." surname="Yang">
            <organization>Beijing Jiaotong University</organization>
          </author>
          <date day="12" month="March" year="2023"/>
          <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="I-D.dang-queuing-with-multiple-cyclic-buffers" target="https://datatracker.ietf.org/doc/html/draft-dang-queuing-with-multiple-cyclic-buffers-00" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.dang-queuing-with-multiple-cyclic-buffers.xml">
        <front>
          <title>A Queuing Mechanism with Multiple Cyclic Buffers</title>
          <author fullname="Bingyang Liu" initials="B." surname="Liu">
            <organization>Huawei</organization>
          </author>
          <author fullname="Joanna Dang" initials="J." surname="Dang">
            <organization>Huawei</organization>
          </author>
          <date day="22" month="February" 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.joung-detnet-asynch-detnet-framework" target="https://datatracker.ietf.org/doc/html/draft-joung-detnet-asynch-detnet-framework-02" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.joung-detnet-asynch-detnet-framework.xml">
        <front>
          <title>Asynchronous Deterministic Networking Framework for Large-Scale Networks</title>
          <author fullname="Jinoo Joung" initials="J." surname="Joung">
            <organization>Sangmyung University</organization>
          </author>
          <author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
            <organization>ETRI</organization>
          </author>
          <author fullname="Taesik Cheung" initials="T." surname="Cheung">
            <organization>ETRI</organization>
          </author>
          <author fullname="Yizhou Li" initials="Y." surname="Li">
            <organization>Huawei</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <date day="26" month="March" year="2023"/>
          <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 strict time-synchronization of network nodes.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-joung-detnet-asynch-detnet-framework-02"/>
      </reference>
      <reference anchor="I-D.xiong-detnet-large-scale-enhancements" target="https://datatracker.ietf.org/doc/html/draft-xiong-detnet-large-scale-enhancements-02" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.xiong-detnet-large-scale-enhancements.xml">
        <front>
          <title>Enhanced DetNet Data Plane (EDP) Framework for Scaling Deterministic Networks</title>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Zongpeng Du" initials="Z." surname="Du">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Junfeng Zhao" initials="J." surname="Zhao">
            <organization>CAICT</organization>
          </author>
          <author fullname="Dong Yang" initials="D." surname="Yang">
            <organization>Beijing Jiaotong University</organization>
          </author>
          <date day="13" month="March" year="2023"/>
          <abstract>
            <t>The Enhanced Deterministic Networking (EDN) is required to provide the enhancement of flow identification and packet treatment for Deterministic Networking (DetNet) to achieve the DetNet QoS in large- scale networks. This document proposes the enhancement of packet treatment to support the functions and metadata for Enhanced DetNet Data plane (EDP). It describes related enhanced controller plane considerations as well.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-large-scale-enhancements-02"/>
      </reference>
      <reference anchor="I-D.peng-detnet-packet-timeslot-mechanism" target="https://datatracker.ietf.org/doc/html/draft-peng-detnet-packet-timeslot-mechanism-02" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.peng-detnet-packet-timeslot-mechanism.xml">
        <front>
          <title>Generic Packet Timeslot Scheduling Mechanism</title>
          <author fullname="Shaofu Peng" initials="S." surname="Peng">
            <organization>ZTE</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Kashinath Basu" initials="K." surname="Basu">
            <organization>Oxford Brookes University</organization>
          </author>
          <author fullname="Aihua Liu" initials="A." surname="Liu">
            <organization>ZTE</organization>
          </author>
          <author fullname="Dong Yang" initials="D." surname="Yang">
            <organization>Beijing Jiaotong University</organization>
          </author>
          <date day="22" month="May" year="2023"/>
          <abstract>
            <t>IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. In this case, the service flow does not occupy a fixed timeslot, and the length of the timeslot is not fixed, but depends on the size of the packet. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS, and its delay performance is dependent on the the used queueing mechanism. This document further describes a generic time division multiplexing scheme in IP/MPLS networks, which we call packet timeslot scheme. It aims to make it easier for the control plane to calculate the delay performance and more flexible to allocate deterministic resources, and also make it easier for the data plane to create more flexible timeslot mapping.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-peng-detnet-packet-timeslot-mechanism-02"/>
      </reference>
      <reference anchor="I-D.ietf-detnet-scaling-requirements" target="https://datatracker.ietf.org/doc/html/draft-ietf-detnet-scaling-requirements-02" xml:base="https://bib.ietf.org/public/rfc/bibxml3/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="24" month="May" 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-02"/>
      </reference>
      <reference anchor="I-D.xiong-detnet-data-fields-edp" target="https://datatracker.ietf.org/doc/html/draft-xiong-detnet-data-fields-edp-00" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.xiong-detnet-data-fields-edp.xml">
        <front>
          <title>Data Fields for DetNet Enhanced Data Plane</title>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Dong Yang" initials="D." surname="Yang">
            <organization>Beijing Jiaotong University</organization>
          </author>
          <date day="10" month="March" year="2023"/>
          <abstract>
            <t>This document discusses the specific metadata which should be carried in Enhanced Data plane (EDP), proposes the DetNet data fields and option types for EDP such as Deterministic Latency Action Option. DetNet Data-Fields for EDP can be encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-data-fields-edp-00"/>
      </reference>
      <reference anchor="I-D.eckert-detnet-tcqf" target="https://datatracker.ietf.org/doc/html/draft-eckert-detnet-tcqf-03" xml:base="https://bib.ietf.org/public/rfc/bibxml3/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="Yizhou Li" initials="Y." surname="Li">
            <organization>Huawei Technologies</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="Jeong-dong Ryoo" initials="J." surname="Ryoo">
            <organization>ETRI</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Guangpeng Li" initials="G." surname="Li">
            <organization>Huawei Technologies</organization>
          </author>
          <author fullname="Shoushou Ren" initials="S." surname="Ren">
            <organization>Huawei Technologies</organization>
          </author>
          <author fullname="Fan Yang" initials="F." surname="Yang">
            <organization>Huawei Technologies</organization>
          </author>
          <date day="19" month="June" year="2023"/>
          <abstract>
            <t>This memo specifies a forwarding method for bounded latency and bounded jitter for Deterministic Networks and is a variant of the IEEE TSN Cyclic Queuing and Forwarding (CQF) method. Tagged CQF (TCQF) supports more than 2 cycles and indicates the cycle number via an existing or new packet header field called the tag to replace the cycle mapping in CQF which is based purely on synchronized reception clock. This memo standardizes TCQF as a mechanism independent of the tagging method used. It also specifies tagging via the (1) the existing MPLS packet Traffic Class (TC) field for MPLS packets, (2) the IP/IPv6 DSCP field for IP/IPv6 packets, and (3) a new TCQF Option header for IPv6 packets. 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 as well as low accuracy clock synchronization.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-eckert-detnet-tcqf-03"/>
      </reference>
      <reference anchor="I-D.chen-detnet-sr-based-bounded-latency" target="https://datatracker.ietf.org/doc/html/draft-chen-detnet-sr-based-bounded-latency-02" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.chen-detnet-sr-based-bounded-latency.xml">
        <front>
          <title>Segment Routing (SR) Based Bounded Latency</title>
          <author fullname="Mach Chen" initials="M." surname="Chen">
            <organization>Huawei</organization>
          </author>
          <author fullname="Xuesong Geng" initials="X." surname="Geng">
            <organization>Huawei</organization>
          </author>
          <author fullname="Zhenqiang Li" initials="Z." surname="Li">
            <organization>China Mobile</organization>
          </author>
          <date day="13" month="March" year="2023"/>
          <abstract>
            <t>One of the goals of DetNet is to provide bounded end-to-end latency for critical flows. This document defines how to leverage Segment Routing (SR) to implement bounded latency. Specifically, the SR Identifier (SID) is used to specify transmission time (cycles) of a packet. When forwarding devices along the path follow the instructions carried in the packet, the bounded latency is achieved. This is called Cycle Specified Queuing and Forwarding (CSQF) in this document. Since SR is a source routing technology, no per-flow state is maintained at intermediate and egress nodes, SR-based CSQF naturally supports flow aggregation that is deemed to be a key capability to allow DetNet to scale to large networks.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-chen-detnet-sr-based-bounded-latency-02"/>
      </reference>
      <reference anchor="I-D.joung-detnet-stateless-fair-queuing" target="https://datatracker.ietf.org/doc/html/draft-joung-detnet-stateless-fair-queuing-00" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.joung-detnet-stateless-fair-queuing.xml">
        <front>
          <title>Latency Guarantee with Stateless Fair Queuing</title>
          <author fullname="Jinoo Joung" initials="J." surname="Joung">
            <organization>Sangmyung University</organization>
          </author>
          <author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
            <organization>ETRI</organization>
          </author>
          <author fullname="Taesik Cheung" initials="T." surname="Cheung">
            <organization>ETRI</organization>
          </author>
          <author fullname="Yizhou Li" initials="Y." surname="Li">
            <organization>Huawei</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <date day="24" month="June" year="2023"/>
          <abstract>
            <t>This document specifies the framework and the operational procedure for deterministic networks with work conserving packet schedulers that guarantees end-to-end latency bounds to flows. Schedulers in core nodes of the network do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update FT by adding a delay factor, which is a function of the flow and upstream nodes. The packets in the queue are served in the ascending order of the FT. This technique is called fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters, except the maximum packet length among other flows sharing each output link with the flow.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-joung-detnet-stateless-fair-queuing-00"/>
      </reference>
    </references>
  </back>
</rfc>
