Internet-Draft BGP Flowspec for DetNet and TSN Flow Map March 2023
Xiong, et al. Expires 13 September 2023 [Page]
Workgroup:
IDR
Internet-Draft:
draft-xiong-idr-detnet-flow-mapping-04
Published:
Intended Status:
Standards Track
Expires:
Authors:
Q. Xiong
ZTE Corporation
H. Wu
ZTE Corporation
J. Zhao
CAICT
D. Yang
Beijing Jiaotong University

BGP Flow Specification for DetNet and TSN Flow Mapping

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 13 September 2023.

Table of Contents

1. Introduction

[RFC8655] 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).

As defined in [RFC8655], 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.

As described in [RFC8938], 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 [RFC8955], 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.

BGP flow specification version 1 (FSv1) has been defined in [RFC8955] and version 2 of the BGP flow specification (FSv2) protocol has been proposed in [I-D.ietf-idr-flowspec-v2]. 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.

2. Conventions used in this document

2.1. Terminology

The terminology is defined as [RFC8655], [RFC8938], [RFC8955] and [I-D.ietf-idr-flowspec-v2].

2.2. Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. The Requirements for DetNet Control Plane

3.1. Functions for DetNet Flow to TSN Stream Mapping

As described in [RFC9024], TSN networks can be interconnected over a DetNet MPLS Network. And as discussed in [RFC9023] and [RFC9037], 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.

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 [RFC8964].

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.


   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|


Figure 1: Figure 1: Flow Mapping in TSN over DetNet Network

3.2. Aggregation during DetNet Flow to TSN Stream Mapping

As described in [RFC8938], 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 [RFC9023] and [RFC9037], 1:1 and N:1 mapping (aggregating multiple TSN Streams in a single DetNet flow) MUST be supported.

4. BGP Extensions for Flow Specification Encoding

As defined in [RFC8955], 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.

4.1. Filtering Rules for TSN Streams

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.

As defined in [I-D.ietf-idr-flowspec-l2vpn], 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 [I-D.ietf-idr-flowspec-v2] section 3.4. This document proposes a new L2 SubTLV for TSN Streams in L2 Flow Specification Component shown in Figure 2.


       +----------------------------------+
       |  SubTLV type = TBD1 (1 octet)    |
       +----------------------------------+
       |  length (1 octet)                |
       + ---------------------------------+
       |  Mac Service Data Unit (6 octets)|
       +----------------------------------+
Figure 2: Figure 2: TSN SubTLV

SubTLV type = TBD1: Mac Service Data Unit

Encoding: <type (1 octet), length (1 octet), [op, value]+>

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 [RFC8955].

4.2. Traffic Action for TSN Streams

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 [RFC8955] and [RFC8956] 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 [I-D.ietf-idr-flowspec-v2] section 3.2.

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 [I-D.ietf-idr-bgp-flowspec-label]. 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.

Table 1
type Wide Community encoding
TBD2 Deterministic Latency Action bitmask

The Deterministic Latency Action SubTLV is shown in Figure 3.

      0                                              15
      +-----------------------------------------------+
      |        SubTLV type = TBD2 (2 octet)           |
      +-----------------------------------------------+
      |               length (2 octet)                |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |    Flag   |Deterministic Latency Information  |
      +--+--+--+--+                                   +
      |                      ~                        |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


Figure 3: Figure 3: Deterministic Latency Action

Flag: 4 bits, indicates the type of queuing mechanisms:

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.

4.3. Filtering Rules for DetNet Flows

The L3 traffic filtering rules defined in [RFC8955] and [RFC8956] can be used for DetNet IP flow.

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 [I-D.ietf-idr-flowspec-mpls-match]. IP header TLV in BGP FSv2 of has been defined in [I-D.ietf-idr-flowspec-v2] section 3.1.

This document proposes a new IP header SubTLV for DetNet MPLS flows shown in Figure 4.


       +----------------------------------+
       |  SubTLV type = TBD3 (1 octet)    |
       +----------------------------------+
       |  length (1 octet)                |
       + ---------------------------------+
       | Deterministic Latency Information|
       |            ~                     |
       +----------------------------------+
Figure 4: Figure 4: DetNet SubTLV

SubTLV Type TBD3:indicates deterministic latency information.

Encoding: <type (1 octet), length (1 octet), [op, value]+>

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 [RFC8955].

4.4. Traffic Action for DetNet Flows

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.

Table 2
type Wide Community encoding
TBD4 TSN Action bitmask

The TSN Action SubTLV is shown in Figure 3.


      0                                              15
      +-----------------------------------------------+
      |        SubTLV type = TBD4 (2 octet)           |
      +-----------------------------------------------+
      |        length (2 octet)                       |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |        Type           |       Resv            |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                TSN-Profile                    |
      |                    ~                          |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Figure 5: Figure 5: TSN Action

Type: 1-octet, indicates the type of TSN profiles. The value of the types is TBD:

Resv: 1-octet, reserved for future use. MUST be sent as zero and ignored on receipt.

TSN-profile: 4-octet, can be converted to the TSN Stream ID and stream related parameters and requirements as the following shown.

stream_handle: identifying the Stream to which the packet belongs in TSN networks.

sequence_number: identifying the order in which the packet was transmitted relative to other packets in the same Compound Stream in TSN networks.

traffic_scheduling: identifying the traffic scheduling mechanisms including traffic policy, queuing and forwarding methods in TSN networks.

5. Security Considerations

TBA

6. IANA Considerations

TBA

7. Acknowledgements

TBA

8. Normative References

[I-D.ietf-idr-bgp-flowspec-label]
liangqiandeng, Hares, S., You, J., Raszuk, R., and D. Ma, "Carrying Label Information for BGP FlowSpec", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-flowspec-label-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-flowspec-label-02>.
[I-D.ietf-idr-flowspec-l2vpn]
Weiguo, H., Eastlake, D. E., Litkowski, S., and S. Zhuang, "BGP Dissemination of L2 Flow Specification Rules", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-l2vpn-20, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-20>.
[I-D.ietf-idr-flowspec-mpls-match]
Yong, L., Hares, S., liangqiandeng, and J. You, "BGP Flow Specification Filter for MPLS Label", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-mpls-match-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-mpls-match-02>.
[I-D.ietf-idr-flowspec-v2]
Hares, S., Eastlake, D. E., Yadlapalli, C., and S. Maduschke, "BGP Flow Specification Version 2", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-v2-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-v2-01>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8655]
Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, , <https://www.rfc-editor.org/info/rfc8655>.
[RFC8938]
Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane Framework", RFC 8938, DOI 10.17487/RFC8938, , <https://www.rfc-editor.org/info/rfc8938>.
[RFC8955]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, , <https://www.rfc-editor.org/info/rfc8955>.
[RFC8956]
Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, , <https://www.rfc-editor.org/info/rfc8956>.
[RFC8964]
Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, "Deterministic Networking (DetNet) Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, , <https://www.rfc-editor.org/info/rfc8964>.
[RFC9023]
Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023, DOI 10.17487/RFC9023, , <https://www.rfc-editor.org/info/rfc9023>.
[RFC9024]
Varga, B., Ed., Farkas, J., Malis, A., Bryant, S., and D. Fedyk, "Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS", RFC 9024, DOI 10.17487/RFC9024, , <https://www.rfc-editor.org/info/rfc9024>.
[RFC9037]
Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9037, DOI 10.17487/RFC9037, , <https://www.rfc-editor.org/info/rfc9037>.

Authors' Addresses

Quan Xiong
ZTE Corporation
No.6 Huashi Park Rd
Wuhan
Hubei, 430223
China
Haisheng Wu
ZTE Corporation
Nanjing
Jiangsu,
China
Junfeng Zhao
CAICT
Beijing
China
Dong Yang
Beijing Jiaotong University
Beijing
China