<?xml version='1.0'?>   
    <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ 
    	<!ENTITY rfc2629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'> 
		]>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-xiong-idr-detnet-flow-mapping-02"
     ipr="trust200902">
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <title abbrev="BGP Flow Specification for DetNet and TSN Flow Mapping">BGP Flow Specification for DetNet and TSN Flow Mapping</title>
	
    <author fullname="Quan Xiong" initials="Q" surname="Xiong">
      <organization>ZTE Corporation</organization>

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

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

        <phone></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></street>
          
          <city>Nanjing</city>
          
          <region>Jiangsu</region>
  
          <code></code>

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

        <phone></phone>

        <email>wu.haisheng@zte.com.cn</email>
      </address>
    </author>
	
  <author fullname="Junfeng Zhao" initials="J" surname="Zhao">
      <organization>CAICT</organization>

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

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

        <phone></phone>

        <email>zhaojunfeng@caict.ac.cn</email>
      </address>
    </author>
    
   <date month="March" year="2022"/>	
    <area>Routing</area>
    <workgroup>IDR</workgroup>
    <keyword></keyword>
    <abstract>
     <t>This document proposes extensions to BGP Flow Specification for the flow 
	 mapping of Deterministic Networking (DetNet) when interconnected with 
	 IEEE 802.1 Time-Sensitive Networking (TSN). The BGP flowspec is used for 
	 the filtering of the packets that match the DetNet newtworks and the mapping 
	 between TSN streams and DetNet flows in the control plane.</t>
	 
    </abstract>
  </front>

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

  <middle>
  
    <section title="Introduction">
	
	<t><xref target="RFC8655"></xref> 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"></xref>, the DetNet IP and MPLS flows can be carried 
   over TSN sub-networks. DetNet needs to be mapped to the sub-networks 
   technology 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
   provide 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>As described in <xref target="RFC8938"></xref>, one of the primary requirements of the 
   DetNet Controller 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"></xref>, 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 classifing, 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"></xref>
   and version 2 of the BGP flow specification (FSv2) protocol has been
   proposed in <xref target="I-D.hares-idr-flowspec-v2"></xref>. 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 newtworks and the mapping between TSN 
   streams and DetNet flows in the control plane.</t>
   
   </section>

    <section title="Conventions used in this document">	 	
    <section title="Terminology">
	<t>The terminology is defined as <xref target="RFC8655"></xref>, <xref target="RFC8938"></xref>, 
	<xref target="RFC8955"></xref> and <xref target="I-D.hares-idr-flowspec-v2"></xref>.</t>
   </section>
   
   <section title="Requirements Language">
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in BCP
    14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when,
    and only when, they appear in all capitals, as shown here.</t>
    </section>
	
   </section>
   <section title="The Requirements for DetNet Control Plane">
   

   <section title="Functions for DetNet Flow to TSN Stream Mapping">
   
   <t>As described in <xref target="RFC9024"></xref>, TSN networks 
   can be interconnected over a DetNet MPLS Network. And as discussed
   in <xref target="RFC9023"></xref> and <xref target="RFC9037"></xref>, 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 configue 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"></xref>. </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 title="Figure 1: Flow Mapping in TSN over DetNet Network" align="center">
     <artwork align="center"><![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>
   <postamble></postamble>
   </figure> 
   
   
   </section>
   
   <section title="Aggregation during DetNet Flow to TSN Stream Mapping">
   
   <t>As described in <xref target="RFC8938"></xref>, 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 controller plane. Moreover, as defined in <xref target="RFC9023"></xref> and <xref target="RFC9037"></xref>, 1:1 and 
   N:1 mapping (aggregating multiple TSN Streams in a single DetNet flow) MUST 
   be supported.</t>
   
 
   </section>
   </section>
   
   <section title="BGP Extensions for Flow Specification Encoding">
   
   <t>As defined in <xref target="RFC8955"></xref>, the nodes that applied a Flow Specification 
   can fillter the received pakects 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 title="Filtering Rules for TSN Streams">
 
   <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"></xref>, 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.hares-idr-flowspec-v2"></xref> section 3.4.
   This document proposes a new L2 SubTLV for TSN Streams in L2 Flow
   Specification Component shown in Figure 2.</t>
   

    <figure title="Figure 2: TSN SubTLV" align="center">
     <artwork align="center"><![CDATA[
   
       +----------------------------------+
       |  SubTLV type = TBD1 (1 octet)    |
       +----------------------------------+
       |  length (1 octet)                |
       + ---------------------------------+
       |  Mac Service Data Unit (6 octets)|
       +----------------------------------+
 			     ]]></artwork>
   <postamble></postamble>
   </figure> 
   
   <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"></xref>.</t> 
  
   </section>
    
  <section title="Traffic Action for TSN Streams">
  
  <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"></xref> 
  and <xref target="RFC8956"></xref> 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.hares-idr-flowspec-v2"></xref> 
  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"></xref>. And the action for the sequence in 
  d-CW field, this document proposes a new Action SubTLV in BGP FSv2 Wide Community
  for TSN Streams as following shown.</t>
  
   <texttable anchor="table1">
     <ttcol align = 'center'> type </ttcol>
     <ttcol align = 'left'> Wide Community </ttcol>
     <ttcol align = 'center'> encoding </ttcol>
	 <c>TBD2</c>
     <c>Sequence Action</c>
     <c>bitmask </c>
     </texttable>
  
  <t>The The Sequence Action SubTLV is shown in Figure 3.</t>
   
  
  <figure title="Figure 3: Sequence Action" align="center">
     <artwork align="center"><![CDATA[
      0                                              15
      +-----------------------------------------------+
      |        SubTLV type = TBD2 (2 octet)           |
      +-----------------------------------------------+
      |               length (2 octet)                |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |    Type   |        Sequence Number            |
      +--+--+--+--+                                   +
      |                       ~                       |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

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

   <t>Type: 4 bits, indicates the length type of the sequence number:</t>
   <t>0: 0 bits</t>
   <t>1: 16 bits</t>
   <t>2: 28 bits</t>
   <t>Sequence Number: 28 bits, an unsigned value implementing the DetNet 
   sequence number.</t>

   </section>
  
   <section title="Filtering Rules for DetNet Flows">
   
    <t>The L3 traffic filtering rules defined in <xref target="RFC8955"></xref> and <xref target="RFC8956"></xref> 
	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"></xref>.
	IP header TLV in BGP FSv2 of has been defined in 
   <xref target="I-D.hares-idr-flowspec-v2"></xref> section 3.1.</t>
	
	<t>This document proposes a new IP header SubTLV for DetNet MPLS 
	flows shown in Figure 4.</t>
	
	   <figure title="Figure 4: DetNet SubTLV" align="center">
     <artwork align="center"><![CDATA[
   
       +----------------------------------+
       |  SubTLV type = TBD3 (1 octet)    |
       +----------------------------------+
       |  length (1 octet)                |
       + ---------------------------------+
       |  d-CW (4 octets)                  |
       +----------------------------------+
 			     ]]></artwork>
   <postamble></postamble>
   </figure> 
   
    <t>MPLS Match Type TBD3: d-CW , indicates Sequence in Label stack.</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 Sequence.
   Values are encoded as 4-octet quantities, where the four most
   significant bits are set to zero and ignored for matching and the 28
   least significant bits contain the sequence value. op is encoded as
   specified in Section 4.2.1.1 of <xref target="RFC8955"></xref>.</t>
   
    </section>
	
	
  <section title="Traffic Action for DetNet Flows">
  
   <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>
   
   <texttable anchor="table2">
     <ttcol align = 'center'> type </ttcol>
     <ttcol align = 'left'> Wide Community </ttcol>
     <ttcol align = 'center'> encoding </ttcol>
	 <c>TBD4</c>
     <c>TSN Action</c>
     <c>bitmask </c>
     </texttable>
   
   <t>The TSN Action SubTLV is shown in Figure 3.</t>
    
   <figure title="Figure 5: TSN Action" align="center">
         <artwork align="center"><![CDATA[

      0                                              15
      +-----------------------------------------------+
      |        SubTLV type = TBD4 (2 octet)           |
      +-----------------------------------------------+
      |        length (2 octet)                       |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |        Type           |       Resv            |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                TSN-Profile                    |                
      |                    ~                          |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	
	   ]]></artwork>
  <postamble></postamble>
 </figure>
 
   <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 title="Security Considerations">
    <t>TBA</t>
   </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBA</t>
    </section>
	
	<section anchor="IANA" title="IANA Considerations">
	 <t>TBA</t>
	 
    </section>
	
  </middle>

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

  <back>
  
    <references title="Normative References">
    <?rfc include='reference.RFC.2119'?>
	<?rfc include='reference.RFC.8174'?>
	<?rfc include='reference.RFC.8655'?>
	<?rfc include='reference.RFC.8955'?>
	<?rfc include='reference.RFC.8938'?>
    <?rfc include='reference.RFC.8964'?>
    <?rfc include='reference.RFC.8956'?>	
	<?rfc include='reference.RFC.9023'?>
    <?rfc include='reference.RFC.9024'?>
    <?rfc include='reference.RFC.9037'?>
    <?rfc include='reference.I-D.ietf-idr-flowspec-mpls-match'?>
    <?rfc include='reference.I-D.ietf-idr-bgp-flowspec-label'?>
	<?rfc include='reference.I-D.ietf-idr-flowspec-l2vpn'?>
	<?rfc include='reference.I-D.hares-idr-flowspec-v2'?>
	
	

    </references>
        
  </back>
</rfc>
