<?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="std" docName="draft-xiong-idr-detnet-flow-mapping-06" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.22.0 -->
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <title abbrev="BGP Flowspec for DetNet and TSN Flow Mapping">BGP Flow Specification for DetNet and TSN Flow Mapping</title>
    <seriesInfo name="Internet-Draft" value="draft-xiong-idr-detnet-flow-mapping-06"/>
    <author fullname="Quan Xiong" initials="Q" surname="Xiong">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone/>
        <email>xiong.quan@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Haisheng Wu" initials="H" surname="Wu">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone/>
        <email>wu.haisheng@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Junfeng Zhao" initials="J" surname="Zhao">
      <organization>CAICT</organization>
      <address>
        <postal>
          <street/>
          <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <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/>
          <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone/>
        <email>dyang@bjtu.edu.cn</email>
      </address>
    </author>
    <date year="2024"/>
    <area>Routing</area>
    <workgroup>IDR</workgroup>
    <keyword/>
    <abstract>
      <t>This document proposes a set of 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 networks and the mapping 
	 between TSN streams and DetNet flows in the control plane.</t>
    </abstract>
  </front>
  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC8655" format="default"/> specifies the architecture of Deterministic
   Networking (DetNet), which provide a capability for the delivery of
   data flows with extremely low packet loss rates and bounded 
   end-to-end delivery latency. DetNet-enabled end systems and DetNet nodes 
   can be interconnected by sub-networks, i.e., Layer 2 technologies 
   such as IEEE 802.1 Time-Sensitive Networking (TSN).</t>
      <t>As defined in <xref target="RFC8655" format="default"/>, the DetNet IP and MPLS flows can be carried 
   over TSN sub-networks. DetNet needs to be mapped to the sub-networks 
   technology which are used to interconnect DetNet nodes. For example, 
   a TSN node may be used to interconnect DetNet-aware nodes, and these 
   DetNet nodes can map DetNet flows to TSN streams. When the DetNet
   provides the deterministic service for the TSN end system, a DetNet
   edge node may be used to interconnect the TSN end system, and the 
   DetNet nodes can map the TSN streams to DetNet flows. </t>
      <t>Moreover, for scaling networks, <xref target="I-D.ietf-detnet-scaling-requirements" format="default"/> 
	has described the enhancement requirements for DetNet enhanced 
	data plane, such as aggregated flow identification and deterministic
	latency guarantees. <xref target="I-D.ietf-detnet-dataplane-taxonomy" format="default"/>
	has discussed the data plane enhancement solutions and queuing
	mechanisms in DetNet, and also described the classification 
	criteria and the suitability of the solutions for various 
	services. The DetNet-specific metadata is required to be carried
	in packets to help the functions of ensuring deterministic latency.
	When L2 networks being interconnected with the large-scale network
	such as DetNet, the DetNet edge nodes should map the TSN streams
	to DetNet flows with selecting a specific queuing and scheduling
	mechanism.  </t>
      <t>As described in <xref target="RFC8938" format="default"/>, one of the primary requirements of the 
   DetNet control plane is restricting flows to IEEE 802.1 TSN and
   the requirement could use the centralized network management provisioning
   mechanisms such as BGP protocol. As defined in <xref target="RFC8955" format="default"/>, the Flow 
   Specifications for BGP is an n-tuple consisting of several matching
   criteria which is comprised of traffic filtering rules and is 
   associated with actions that can be applied to the traffic flows.
   The DetNet edge nodes can provide the capability to process the 
   traffic including classifying, shaping, rate limiting, filtering, 
   and redirecting packets based on the policies configured by the 
   BGP Flow Specification.</t>
      <t>BGP flow specification version 1 (FSv1) has been defined in <xref target="RFC8955" format="default"/>
   and version 2 of the BGP flow specification (FSv2) protocol has been
   proposed in <xref target="I-D.ietf-idr-flowspec-v2" format="default"/>. This 
   document proposes extensions to BGP FSv2 for the interconnection of 
   DetNet and TSN. The BGP flowspec is 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 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"/>, <xref target="RFC8938" format="default"/>, 
	<xref target="RFC8955" format="default"/> and <xref target="I-D.ietf-idr-flowspec-v2" 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>The Requirements for DetNet Control Plane</name>
      <section numbered="true" toc="default">
        <name>Functions for DetNet Flow to TSN Stream Mapping</name>
        <t>As described in <xref target="RFC9024" format="default"/>, TSN networks 
   can be interconnected over a DetNet MPLS Network. And as discussed
   in <xref target="RFC9023" format="default"/> and <xref target="RFC9037" format="default"/>, DetNet 
   IP or MPLS networks can be operating over a TSN sub-network.
   The mapping between TSN Streams and DetNet flows is required 
   for the service proxy function at DetNet Edge nodes. And the 
   mapping table can be configured and maintained in the control 
   plane. When a DetNet Edge Node receives a packet, it MUST 
   identify and check whether such flow is present in its mapping 
   table and decide to drop (when not match) or to forward the 
   packet (when match) to the associated service. </t>
        <t>As Figure 1 shows, it is required to configure the identification 
   information when mapping received TSN Streams to the DetNet flows at 
   Edge Node-1. Mechanisms and Parameters of TSN stream identification 
   (e.g.,Mask-and-Match Stream identification) defined in [IEEE8021CB] 
   and [IEEEP8021CBdb] can be used for service proxy function. After 
   the identification of the TSN stream, it need to map the packet to 
   the DetNet flow information such as S-Label, d-CW when in DetNet 
   MPLS data plane and handle the packet as defined in <xref target="RFC8964" format="default"/>. </t>
        <t>When the DetNet Edge Node-2 receives a DetNet flow, it MUST 
   identify the DetNet flow-ID information such as IP 6-tuple in 
   DetNet IP data plane or S-Label and d-CW information in DetNet 
   MPLS data plane. Then the Service proxy function need to map 
   the DetNet flow-ID and flow related parameters to the associated 
   TSN Stream IDs and streams related parameters.</t>
        <figure>
          <name>Flow Mapping in TSN over DetNet Network</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
   
   TSN             Edge             Transit       Edge         TSN
   End System      Node-1           Node          Node-2       End System
   +----------+                                             +----------+
   |   TSN    | <---------End to End TSN Service----------> |   TSN    |
   |  Applic. |                                             |  Applic. |
   +----------+  +.........+                   +.........+  +----------+
   |          |  |Service-Proxy             Service-Proxy|  |          |
   |   TSN    |  |   +.+---+<-- DetNet flow -->+---+.|   |  |   TSN    |
   |          |  |TSN| |Svc|                   |Svc| |TSN|  |          |
   +----------+  +---+ +---+    +----------+   +---+ +---+  +----------+
   |   L2     |  | L2| |Fwd|    |Forwarding|   |Fwd| |L2 |  |   L2     |
   +------.---+  +-.-+ +-.-+    +---.----.-+   +--.+ +-.-+  +---.------+
          :  Link  :     /  ,-----.  \   :  Link  :   /  ,-----. \
          +........+     +-[  Sub  ]-+   +........+   +-[  TSN  ]-+
                           [Network]                    [Network]
                            `-----'                      `-----'
Flow Mapping: 
       |TSN : DetNet|<--------- DetNet ---------->|DetNet : TSN|

			 
			     ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
      </section>
      <section numbered="true" toc="default">
        <name>Aggregation during DetNet Flow to TSN Stream Mapping</name>
        <t>As described in <xref target="RFC8938" format="default"/>, the DetNet data plane allows for the 
   aggregation of DetNet flows, which should also be accomplished in the 
   control plane. IP, MPLS and TSN aggregation has both data plane and controller 
   plane aspects. Bandwidth reservations, resource assignment, path computation, 
   delay, delay variation and aggregate number should be taken into considerations
   in the control plane. Moreover, as defined in <xref target="RFC9023" format="default"/> and <xref target="RFC9037" format="default"/>, 
   N:1 mapping (aggregating multiple TSN Streams in a single DetNet flow) MUST 
   be supported. </t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>BGP Extensions for Flow Specification Encoding</name>
      <t>As defined in <xref target="RFC8955" format="default"/>, the nodes that applied a Flow Specification 
   can filter the received packets according to the matching 
   criteria and can forward the flows based on the associated actions. 
   This document proposes extensions to BGP Flow Specification for 
   the mapping of DetNet flows and TSN streams by using the traffic 
   filtering rules to identify the packet and using the associated
   action to map the packet to the related service.</t>
      <section numbered="true" toc="default">
        <name>Filtering Rules for TSN Streams</name>
        <t>As IEEE Std 802.1Q defined, a Stream ID is a 64-bit field that uniquely 
   identifies a stream and can be generated by the system offering the stream, 
   or possibly a device controlling that system. But it is not carried in the
   header of the TSN Stream. As defined in [IEEE8021CB] and [IEEEP8021CBdb], 
   five specific Stream identification functions are described: Null Stream 
   identification, Source MAC and VLAN Stream identification, Active 
   Destination MAC and VLAN Stream identification, and IP Stream identification,
   and Mask-and-match Stream identification. It needs to examines the header
   of the streams such as destination_address, vlan_identifier, IP source 
   address, IP destination address, DSCP, IP next protocol, source port, 
   destination port and mac_service_data_unit. </t>
        <t>As defined in <xref target="I-D.ietf-idr-flowspec-l2vpn" format="default"/>, the Ethernet Layer 2 (L2) 
   related fields has been covered by the L2 traffic filtering rules except 
   the mac_service_data_unit in Mask-and-Match Stream identification.
   A mac_service_data_unit mask is defined to identify communication
   flows supported by various higher-layer protocols. L2 Traffic Rules 
   and L2 header TLV in BGP FSv2 of has been defined in 
   <xref target="I-D.ietf-idr-flowspec-v2" format="default"/> section 3.4.
   This document proposes a new L2 SubTLV for TSN Streams in L2 Flow
   Specification Component shown in Figure 2.</t>
        <figure>
          <name>TSN SubTLV</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
   
       +----------------------------------+
       |  SubTLV type = TBD1 (1 octet)    |
       +----------------------------------+
       |  length (1 octet)                |
       + ---------------------------------+
       |  Mac Service Data Unit (6 octets)|
       +----------------------------------+
 			     ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <t>SubTLV type = TBD1: Mac Service Data Unit</t>
        <t>Encoding: &lt;type (1 octet), length (1 octet), [op, value]+&gt; </t>
        <t>Defines a list of {operation, value} pairs used to match 6-octet 
   Mac Service Data Unit field. Values are encoded as 6-octet
   quantities. op is encoded as specified in Section 4.2.1.1 of
   <xref target="RFC8955" format="default"/>.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Traffic Action for TSN Streams</name>
        <t>The action for an TSN traffic filtering flowspec is to accept the TSN 
  streams that matches that particular rule and map the streams to the DetNet 
  flows. The action for L3 traffic with extended communities types per <xref target="RFC8955" format="default"/> 
  and <xref target="RFC8956" format="default"/> such as traffic-rate, traffic-marking, traffic-action, and 
  redirect can be used for TSN to DetNet IP flow mapping. The Wide Community 
  has been proposed for FSv2 actions in <xref target="I-D.ietf-idr-flowspec-v2" format="default"/> 
  section 3.2. </t>
        <t>The DetNet flow is identified by a S-Label and the DetNet Header consists 
  of d-CW and F-Labels. The MPLS label related action for an TSN stream mapping 
  to a DetNet MPLS network can use the Label-action defined 
  in <xref target="I-D.ietf-idr-bgp-flowspec-label" format="default"/>. And the action for 
  the information ensuring deterministic latency, this document proposes a new 
  Action SubTLV in BGP FSv2 Wide Community for TSN Streams as following shown.</t>
        <table anchor="table1" align="center">
          <thead>
            <tr>
              <th align="center"> type </th>
              <th align="left"> Wide Community </th>
              <th align="center"> encoding </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">TBD2</td>
              <td align="left">Deterministic Latency Action</td>
              <td align="center">bitmask </td>
            </tr>
          </tbody>
        </table>
        <t>The Deterministic Latency Action SubTLV is shown in Figure 3.</t>
        <figure>
          <name>Deterministic Latency Action</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
      0                                              15
      +-----------------------------------------------+
      |        SubTLV type = TBD2 (2 octet)           |
      +-----------------------------------------------+
      |               length (2 octet)                |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |    Flag   |Deterministic Latency Information  |
      +--+--+--+--+                                   +
      |                      ~                        |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

             
    ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <t>Flag: 4 bits, indicates the type of deterministic latency
   information and related queuing and scheduling mechanisms:</t>
        <t>Deterministic Latency Information: variable length, the 
   information when implementing the DetNet queuing mechanisms 
   to guarantee the deterministic latency. For instance, the 
   cycle ID for cyclic queuing and forwarding or the latency
   related information for deadline time based queuing in order 
   to enable the applicability of the respective queuing and/or
   scheduling mechanisms in the large scale network.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Filtering Rules for DetNet Flows</name>
        <t>The L3 traffic filtering rules defined in <xref target="RFC8955" format="default"/> and <xref target="RFC8956" format="default"/> 
	can be used for DetNet IP flow. </t>
        <t>As defined in RFC8964, the MPLS-based DetNet data plane 
	encapsulation consists of d-CW, S-Label and F-Labels. The MPLS 
	label filtering rules have been defined in <xref target="I-D.ietf-idr-flowspec-mpls-match" format="default"/>.
	IP header TLV in BGP FSv2 of has been defined in 
   <xref target="I-D.ietf-idr-flowspec-v2" format="default"/> section 3.1.</t>
        <t>This document proposes a new IP header SubTLV for DetNet MPLS 
	flows shown in Figure 4.</t>
        <figure>
          <name>DetNet SubTLV</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
   
       +----------------------------------+
       |  SubTLV type = TBD3 (1 octet)    |
       +----------------------------------+
       |  length (1 octet)                |
       + ---------------------------------+
       | Deterministic Latency Information|
       |            ~                     |
       +----------------------------------+
 			     ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <t>SubTLV Type TBD3:indicates deterministic latency information.</t>
        <t>Encoding: &lt;type (1 octet), length (1 octet), [op, value]+&gt; </t>
        <t> Defines a list of {operation, value} pairs used to match Deterministic 
	Latency Information. Values are encoded as variable length. op is encoded as
   specified in Section 4.2.1.1 of <xref target="RFC8955" format="default"/>.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Traffic Action for DetNet Flows</name>
        <t>The extended action for an DetNet traffic filtering flowspec is to 
   accept the DetNet flows that matches that particular rule and map the 
   flows to the TSN streams. This document proposes a new Action SubTLV 
   in BGP FSv2 Wide Community for DetNet flows as the following shown.</t>
        <table anchor="table2" align="center">
          <thead>
            <tr>
              <th align="center"> type </th>
              <th align="left"> Wide Community </th>
              <th align="center"> encoding </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">TBD4</td>
              <td align="left">TSN Action</td>
              <td align="center">bitmask </td>
            </tr>
          </tbody>
        </table>
        <t>The TSN Action SubTLV is shown in Figure 3.</t>
        <figure>
          <name>TSN Action</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[

      0                                              15
      +-----------------------------------------------+
      |        SubTLV type = TBD4 (2 octet)           |
      +-----------------------------------------------+
      |        length (2 octet)                       |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |        Type           |       Resv            |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                TSN-Profile                    |                
      |                    ~                          |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	
	   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <t>Type: 1-octet, indicates the type of TSN profiles. The value of the 
   types is TBD:</t>
        <t>Resv: 1-octet, reserved for future use.  MUST be sent as zero and ignored on
   receipt.</t>
        <t>TSN-profile: 4-octet, can be converted to the TSN Stream ID and 
   stream related parameters and requirements as the following
   shown.</t>
        <t>stream_handle: identifying the Stream to which the packet belongs 
   in TSN networks.</t>
        <t>sequence_number: identifying the order in which the packet was 
   transmitted relative to other packets in the same Compound Stream
   in TSN networks.</t>
        <t>traffic_scheduling: identifying the traffic scheduling mechanisms
   including traffic policy, queuing and forwarding methods in TSN networks.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document defines new SubTLVs for DetNet and TSN flow mapping, which do not 	
 	introduce any new security considerations beyond those already listed	
 	in <xref target="I-D.ietf-idr-flowspec-v2" format="default"/>.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to create new IP SubTLV Types for IP Filters as per
   <xref target="I-D.ietf-idr-flowspec-v2" format="default"/>.</t>
      <table anchor="table3" align="center">
        <thead>
          <tr>
            <th align="center"> Value </th>
            <th align="left"> Definition </th>
            <th align="center"> Reference </th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">TBD1</td>
            <td align="left">TSN: Mac Service Data Unit</td>
            <td align="center">this document</td>
          </tr>
          <tr>
            <td align="center">TBD3</td>
            <td align="left">DetNet: Deterministic Latency Information</td>
            <td align="center">this document</td>
          </tr>
        </tbody>
      </table>
      <t>IANA is requested to create new Flow Specification v2 Action Types as per
	<xref target="I-D.ietf-idr-flowspec-v2" format="default"/>.</t>
      <table anchor="table4" align="center">
        <thead>
          <tr>
            <th align="center"> Type </th>
            <th align="left"> Use </th>
            <th align="center"> Reference </th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">TBD2</td>
            <td align="left">DetNet action</td>
            <td align="center">this document</td>
          </tr>
          <tr>
            <td align="center">TBD5</td>
            <td align="left">TSN action</td>
            <td align="center">this document</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Lou Berger, Jeffrey Haas
	for their review, suggestions and comments to this document.</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="RFC8955" target="https://www.rfc-editor.org/info/rfc8955" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml">
        <front>
          <title>Dissemination of Flow Specification Rules</title>
          <author fullname="C. Loibl" initials="C." surname="Loibl"/>
          <author fullname="S. Hares" initials="S." surname="Hares"/>
          <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
          <author fullname="D. McPherson" initials="D." surname="McPherson"/>
          <author fullname="M. Bacher" initials="M." surname="Bacher"/>
          <date month="December" year="2020"/>
          <abstract>
            <t>This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.</t>
            <t>It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.</t>
            <t>This document obsoletes both RFC 5575 and RFC 7674.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8955"/>
        <seriesInfo name="DOI" value="10.17487/RFC8955"/>
      </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="RFC9037" target="https://www.rfc-editor.org/info/rfc9037" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9037.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane: MPLS 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 (DetNet) MPLS data plane when operating over an IEEE 802.1 Time-Sensitive Networking (TSN) sub-network. This document does not define new procedures or processes. Whenever this document makes statements or recommendations, they are taken from normative text in the referenced RFCs.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9037"/>
        <seriesInfo name="DOI" value="10.17487/RFC9037"/>
      </reference>
      <reference anchor="I-D.ietf-idr-flowspec-mpls-match" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-mpls-match-02" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-idr-flowspec-mpls-match.xml">
        <front>
          <title>BGP Flow Specification Filter for MPLS Label</title>
          <author fullname="Lucy Yong" initials="L." surname="Yong">
            <organization>Huawei</organization>
          </author>
          <author fullname="Susan Hares" initials="S." surname="Hares">
            <organization>Huawei</organization>
          </author>
          <author fullname="liangqiandeng" initials="" surname="liangqiandeng">
            <organization>Huawei</organization>
          </author>
          <author fullname="Jianjie You" initials="J." surname="You">
            <organization>Huawei</organization>
          </author>
          <date day="20" month="October" year="2022"/>
          <abstract>
            <t>This draft proposes BGP flow specification rules that are used to filter MPLS labeled packets.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-mpls-match-02"/>
      </reference>
      <reference anchor="I-D.ietf-idr-bgp-flowspec-label" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-flowspec-label-02" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-idr-bgp-flowspec-label.xml">
        <front>
          <title>Carrying Label Information for BGP FlowSpec</title>
          <author fullname="liangqiandeng" initials="" surname="liangqiandeng">
            <organization>Huawei</organization>
          </author>
          <author fullname="Susan Hares" initials="S." surname="Hares">
            <organization>Huawei</organization>
          </author>
          <author fullname="Jianjie You" initials="J." surname="You">
            <organization>Huawei</organization>
          </author>
          <author fullname="Robert Raszuk" initials="R." surname="Raszuk">
            <organization>Nozomi</organization>
          </author>
          <author fullname="Dan Ma" initials="D." surname="Ma">
            <organization>Cisco Systems</organization>
          </author>
          <date day="20" month="October" year="2022"/>
          <abstract>
            <t>This document specifies a method in which the label mapping information for a particular FlowSpec rule is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the FlowSpec rule. Based on the proposed method, the Label Switching Routers (LSRs) (except the ingress LSR) on the Label Switched Path (LSP) can use label to indentify the traffic matching a particular FlowSpec rule; this facilitates monitoring and traffic statistics for FlowSpec rules.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-flowspec-label-02"/>
      </reference>
      <reference anchor="I-D.ietf-idr-flowspec-l2vpn" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-23" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-idr-flowspec-l2vpn.xml">
        <front>
          <title>BGP Dissemination of L2 Flow Specification Rules</title>
          <author fullname="Hao Weiguo" initials="H." surname="Weiguo">
            <organization>Huawei Technologies</organization>
          </author>
          <author fullname="Donald E. Eastlake 3rd" initials="D. E." surname="Eastlake">
            <organization>Independent</organization>
          </author>
          <author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
            <organization>Cisco Systems, Inc.</organization>
          </author>
          <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
            <organization>Huawei Technologies</organization>
          </author>
          <date day="15" month="April" year="2024"/>
          <abstract>
            <t>This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/ SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-l2vpn-23"/>
      </reference>
      <reference anchor="I-D.ietf-idr-flowspec-v2" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-v2-04" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-idr-flowspec-v2.xml">
        <front>
          <title>BGP Flow Specification Version 2</title>
          <author fullname="Susan Hares" initials="S." surname="Hares">
            <organization>Hickory Hill Consulting</organization>
          </author>
          <author fullname="Donald E. Eastlake 3rd" initials="D. E." surname="Eastlake">
            <organization>Futurewei Technologies</organization>
          </author>
          <author fullname="Chaitanya Yadlapalli" initials="C." surname="Yadlapalli">
            <organization>ATT</organization>
          </author>
          <author fullname="Sven Maduschke" initials="S." surname="Maduschke">
            <organization>Verizon</organization>
          </author>
          <date day="28" month="April" year="2024"/>
          <abstract>
            <t>BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. Multiple applications have used BGP FSv1 to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion. During the deployment of BGP FSv1 a number of issues were detected due to lack of consistent TLV encoding for rules for flow specifications, lack of user ordering of filter rules and/or actions, and lack of clear definition of interaction with BGP peers not supporting FSv1. Version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-v2-04"/>
      </reference>
      <reference anchor="I-D.ietf-detnet-scaling-requirements" target="https://datatracker.ietf.org/doc/html/draft-ietf-detnet-scaling-requirements-06" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-detnet-scaling-requirements.xml">
        <front>
          <title>Requirements for Scaling Deterministic Networks</title>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Yizhou Li" initials="Y." surname="Li">
            <organization>Huawei</organization>
          </author>
          <author fullname="Toerless Eckert" initials="T. T." surname="Eckert">
            <organization>Futurewei Technologies USA</organization>
          </author>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
            <organization>ETRI</organization>
          </author>
          <author fullname="zhushiyin" initials="" surname="zhushiyin">
            <organization>New H3C Technologies</organization>
          </author>
          <author fullname="Xuesong Geng" initials="X." surname="Geng">
            <organization>Huawei</organization>
          </author>
          <date day="22" month="May" year="2024"/>
          <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-06"/>
      </reference>
      <reference anchor="I-D.ietf-detnet-dataplane-taxonomy" target="https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dataplane-taxonomy-00" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-detnet-dataplane-taxonomy.xml">
        <front>
          <title>Dataplane Enhancement Taxonomy</title>
          <author fullname="Jinoo Joung" initials="J." surname="Joung">
            <organization>Sangmyung University</organization>
          </author>
          <author fullname="Xuesong Geng" initials="X." surname="Geng">
            <organization>Huawei</organization>
          </author>
          <author fullname="Shaofu Peng" initials="S." surname="Peng">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Toerless Eckert" initials="T. T." surname="Eckert">
            <organization>Futurewei Technologies</organization>
          </author>
          <date day="24" month="May" year="2024"/>
          <abstract>
            <t>This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also briefly mentioned.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-dataplane-taxonomy-00"/>
      </reference>
    </references>
  </back>
</rfc>
