idnits 2.17.1 draft-xiong-idr-detnet-flow-mapping-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 2021) is 914 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE8021CB' is mentioned on line 201, but not defined == Missing Reference: 'IEEEP8021CBdb' is mentioned on line 201, but not defined == Missing Reference: 'Network' is mentioned on line 166, but not defined == Outdated reference: A later version (-02) exists of draft-ietf-idr-bgp-flowspec-label-01 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-17 == Outdated reference: A later version (-02) exists of draft-ietf-idr-flowspec-mpls-match-01 ** Downref: Normative reference to an Informational RFC: RFC 8938 ** Downref: Normative reference to an Informational RFC: RFC 9023 ** Downref: Normative reference to an Informational RFC: RFC 9037 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Q. Xiong 3 Internet-Draft H. Wu 4 Intended status: Standards Track ZTE Corporation 5 Expires: 27 April 2022 J. Zhao 6 CAICT 7 October 2021 9 BGP Flow Specification for DetNet Flow Mapping 10 draft-xiong-idr-detnet-flow-mapping-01 12 Abstract 14 This document proposes extensions to BGP Flow Specification for the 15 flow mapping of Deterministic Networking (DetNet) when interconnected 16 with IEEE 802.1 Time-Sensitive Networking (TSN). The BGP flowspec is 17 used for the filtering of the packets that match the DetNet newtworks 18 and the mapping between TSN streams and DetNet flows in the control 19 plane. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 4 April 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . 3 56 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 3. The Requirements for DetNet Control Plane . . . . . . . . . . 3 59 3.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 3 60 3.2. Aggregation during DetNet Flow to TSN Stream Mapping . . 5 61 4. BGP Extensions for Flow Specification Encoding . . . . . . . 5 62 4.1. Filtering Rules for TSN Streams . . . . . . . . . . . . . 5 63 4.2. Traffic Action for TSN Streams . . . . . . . . . . . . . 6 64 4.3. Filtering Rules for DetNet Flows . . . . . . . . . . . . 7 65 4.4. Traffic Action for DetNet Flows . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 [RFC8655] specifies the architecture of Deterministic Networking 75 (DetNet), which provide a capability for the delivery of data flows 76 with extremely low packet loss rates and bounded end-to-end delivery 77 latency. DetNet-enabled end systems and DetNet nodes can be 78 interconnected by sub-networks, i.e., Layer 2 technologies such as 79 IEEE 802.1 Time-Sensitive Networking (TSN). 81 As defined in [RFC8655], the DetNet IP and MPLS flows can be carried 82 over TSN sub-networks. DetNet needs to be mapped to the sub-networks 83 technology used to interconnect DetNet nodes. For example, a TSN 84 node may be used to interconnect DetNet-aware nodes, and these DetNet 85 nodes can map DetNet flows to TSN streams. When the Detnet provide 86 the deterministic service for the TSN end system, a DetNet edge node 87 may be used to interconnect the TSN end system, and the DetNet nodes 88 can map the TSN streams to DetNet flows. 90 As described in [RFC8938], one of the primary requirements of the 91 DetNet Controller Plane is restricting flows to IEEE 802.1 TSN and 92 the requirement could use the centralized network management 93 provisioning mechanisms such as BGP protocol. As defined in 94 [RFC8955], the Flow Specifications for BGP is an n-tuple consisting 95 of several matching criteria which is comprised of traffic filtering 96 rules and is associated with actions that can be applied to the 97 traffic flows. The DetNet edge nodes can provide the capability to 98 process the traffic including classifing, shaping, rate limiting, 99 filtering, and redirecting packets based on the policies configured 100 by the BGP Flow Specification. 102 This document proposes extensions to BGP Flow Specification for the 103 interconnection of DetNet and TSN. The BGP flowspec is used for the 104 filtering of the packets that match the DetNet newtworks and the 105 mapping between TSN streams and DetNet flows in the control plane. 107 2. Conventions used in this document 109 2.1. Terminology 111 The terminology is defined as [RFC8655], [RFC8938], and [RFC8955]. 113 2.2. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 3. The Requirements for DetNet Control Plane 123 3.1. Functions for DetNet Flow to TSN Stream Mapping 125 As described in [RFC9024], TSN networks can be interconnected over a 126 DetNet MPLS Network. And as discussed in [RFC9023] and [RFC9037], 127 DetNet IP or MPLS networks can be operating over a TSN sub-network. 128 The mapping between TSN Streams and DetNet flows is required for the 129 service proxy function at DetNet Edge nodes. And the mapping table 130 can be configured and maintained in the control plane. When a DetNet 131 Edge Node receives a packet, it MUST identify and check whether such 132 flow is present in its mapping table and decide to drop (when not 133 match) or to forward the packet (when match) to the associated 134 service. 136 As Figure 1 shows, it is required to configue the identification 137 information when mapping received TSN Streams to the DetNet flows at 138 Edge Node-1. Mechanisms and Parameters of TSN stream identification 139 (e.g.,Mask-and-Match Stream identification) defined in [IEEE8021CB] 140 and [IEEEP8021CBdb] can be used for service proxy function. After 141 the identification of the TSN stream, it need to map the packet to 142 the DetNet flow information such as S-Label, d-CW when in DetNet MPLS 143 data plane and handle the packet as defined in [RFC8964]. 145 When the DetNet Edge Node-2 receives a DetNet flow, it MUST identify 146 the DetNet flow-ID information such as IP 6-tuple in DetNet IP data 147 plane or S-Label and d-CW information in DetNet MPLS data plane. 148 Then the Service proxy function need to map the DetNet flow-ID and 149 flow related parameters to the associated TSN Stream IDs and streams 150 related parameters. 152 TSN Edge Transit Edge TSN 153 End System Node-1 Node Node-2 End System 154 +----------+ +----------+ 155 | TSN | <---------End to End TSN Service----------> | TSN | 156 | Applic. | | Applic. | 157 +----------+ +.........+ +.........+ +----------+ 158 | | |Service-Proxy Service-Proxy| | | 159 | TSN | | +.+---+<-- DetNet flow -->+---+.| | | TSN | 160 | | |TSN| |Svc| |Svc| |TSN| | | 161 +----------+ +---+ +---+ +----------+ +---+ +---+ +----------+ 162 | L2 | | L2| |Fwd| |Forwarding| |Fwd| |L2 | | L2 | 163 +------.---+ +-.-+ +-.-+ +---.----.-+ +--.+ +-.-+ +---.------+ 164 : Link : / ,-----. \ : Link : / ,-----. \ 165 +........+ +-[ Sub ]-+ +........+ +-[ TSN ]-+ 166 [Network] [Network] 167 `-----' `-----' 168 Flow Mapping: 169 |TSN : DetNet|<--------- DetNet ---------->|DetNet : TSN| 171 Figure 1: Figure 1: Flow Mapping in TSN over DetNet Network 173 3.2. Aggregation during DetNet Flow to TSN Stream Mapping 175 As described in [RFC8938], the DetNet data plane allows for the 176 aggregation of DetNet flows, which should also be accomplished in the 177 control plane. IP, MPLS and TSN aggregation has both data plane and 178 controller Plane aspects. Bandwidth reservations, resource 179 assignment, path computation, delay, delay variation and aggregate 180 number should be taken into considerations in the controller plane. 181 Moreover, as defined in [RFC9023] and [RFC9037], 1:1 and N:1 mapping 182 (aggregating multiple TSN Streams in a single DetNet flow) MUST be 183 supported. 185 4. BGP Extensions for Flow Specification Encoding 187 As defined in [RFC8955], the nodes that applied a Flow Specification 188 can fillter the received pakects according to the matching criteria 189 and can forward the flows based on the associated actions. This 190 document proposes extensions to BGP Flow Specification for the 191 mapping of DetNet flows and TSN streams by using the traffic 192 filtering rules to identify the packet and using the associated 193 action to map the packet to the related service. 195 4.1. Filtering Rules for TSN Streams 197 As IEEE Std 802.1Q defined, a Stream ID is a 64-bit field that 198 uniquely identifies a stream and can be generated by the system 199 offering the stream, or possibly a device controlling that system. 200 But it is not carried in the header of the TSN Stream. As defined in 201 [IEEE8021CB] and [IEEEP8021CBdb], five specific Stream identification 202 functions are described: Null Stream identification, Source MAC and 203 VLAN Stream identification, Active Destination MAC and VLAN Stream 204 identification, and IP Stream identification, and Mask-and-match 205 Stream identification. It needs to examines the header of the 206 streams such as destination_address, vlan_identifier, IP source 207 address, IP destination address, DSCP, IP next protocol, source port, 208 destination port and mac_service_data_unit. 210 As defined in [I-D.ietf-idr-flowspec-l2vpn], the Ethernet Layer 2 211 (L2) related fields has been covered by the L2 traffic filtering 212 rules except the mac_service_data_unit in Mask-and-Match Stream 213 identification. A mac_service_data_unit mask is defined to identify 214 communication flows supported by various higher-layer protocols. 215 This document proposes a new type in L2 components flowspec Type for 216 TSN Streams. 218 Type TBD1 - Mac Service Data Unit 220 Encoding: 221 Defines a list of {operation, value} pairs used to match 6-octet Mac 222 Service Data Unit field. Values are encoded as 6-octet quantities. 223 op is encoded as specified in Section 4.2.1.1 of [RFC8955]. 225 4.2. Traffic Action for TSN Streams 227 The action for an TSN traffic filtering flowspec is to accept the TSN 228 streams that matches that particular rule and map the streams to the 229 DetNet flows. The action for L3 traffic with extended communities 230 types per [RFC8955] and [RFC8956] such as traffic-rate, traffic- 231 marking, traffic-action, and redirect can be used for TSN to DetNet 232 IP flow mapping. 234 The DetNet flow is identified by a S-Label and the DetNet Header 235 consists of d-CW and F-Labels. The MPLS label related action for an 236 TSN stream mapping to a DetNet MPLS network can use the Label-action 237 defined in [I-D.ietf-idr-bgp-flowspec-label]. And the action for the 238 sequence in d-CW field, this document specifies the following BGP 239 extended communitiy for TSN Streams as following shown. 241 +======+====================+==========+ 242 | type | extended community | encoding | 243 +======+====================+==========+ 244 | TBD2 | Sequence-action | bitmask | 245 +------+--------------------+----------+ 247 Table 1 249 The The Sequence-action extended community is shown as the Figure 2. 251 0 15 252 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 253 |Type | Resv | 254 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 255 | Resv | Sequence Number | 256 +--+--+--+--+ + 257 | ~ | 258 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 260 Figure 2: Figure 2: Sequence-action 262 Type: 2 bits, indicates the length of the sequence number: 264 0: 0 bits 266 1: 16 bits 268 2: 28 bits 270 Resv: 18 bits, reserved for future use. MUST be sent as zero and 271 ignored on receipt. 273 Sequence Number: 28 bits, an unsigned value implementing the DetNet 274 sequence number. 276 4.3. Filtering Rules for DetNet Flows 278 The L3 traffic filtering rules defined in [RFC8955] and [RFC8956] can 279 be used for DetNet IP flow. 281 As defined in RFC8964, the MPLS-based DetNet data plane encapsulation 282 consists of d-CW, S-Label and F-Labels. The MPLS label filtering 283 rules have been defined in [I-D.ietf-idr-flowspec-mpls-match]. 285 This document proposes a new community type in L3 components flowspec 286 Type for DetNet MPLS flows. 288 Type TBD3 - d-CW 290 Encoding: 292 Defines a list of {operation, value} pairs used to match Sequence. 293 Values are encoded as 4-octet quantities, where the four most 294 significant bits are set to zero and ignored for matching and the 28 295 least significant bits contain the sequence value. op is encoded as 296 specified in Section 4.2.1.1 of [RFC8955]. 298 4.4. Traffic Action for DetNet Flows 300 The extended action for an DetNet traffic filtering flowspec is to 301 accept the DetNet flows that matches that particular rule and map the 302 flows to the TSN streams. This document specifies the following BGP 303 extended communitiy as the following shown. 305 +======+====================+==========+ 306 | type | extended community | encoding | 307 +======+====================+==========+ 308 | TBD4 | TSN-action | bitmask | 309 +------+--------------------+----------+ 311 Table 2 313 The The TSN-action extended community is shown as the Figure 3. 315 0 15 316 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 317 | Type | Resv | 318 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 319 | TSN-Profile | 320 | ~ | 321 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 323 Figure 3: Figure 3: TSN-action 325 Type: 1-octet, indicates the type of TSN profiles. The value of the 326 types is TBD: 328 Resv: 1-octet, reserved for future use. MUST be sent as zero and 329 ignored on receipt. 331 TSN-profile: 4-octet, can be converted to the TSN Stream ID and 332 stream related parameters and requirements as the following shown. 334 stream_handle: identifying the Stream to which the packet belongs in 335 TSN networks. 337 sequence_number: identifying the order in which the packet was 338 transmitted relative to other packets in the same Compound Stream in 339 TSN networks. 341 traffic_scheduling: identifying the traffic scheduling mechanisms 342 including traffic policy, queuing and forwarding methods in TSN 343 networks. 345 5. Security Considerations 347 TBA 349 6. Acknowledgements 351 TBA 353 7. IANA Considerations 355 TBA 357 8. Normative References 359 [I-D.ietf-idr-bgp-flowspec-label] 360 Liang, Q., Hares, S., You, J., Raszuk, R., and D. Ma, 361 "Carrying Label Information for BGP FlowSpec", Work in 362 Progress, Internet-Draft, draft-ietf-idr-bgp-flowspec- 363 label-01, 6 December 2016, 364 . 367 [I-D.ietf-idr-flowspec-l2vpn] 368 Hao, W., Eastlake, D. E., Litkowski, S., and S. Zhuang, 369 "BGP Dissemination of L2 Flow Specification Rules", Work 370 in Progress, Internet-Draft, draft-ietf-idr-flowspec- 371 l2vpn-17, 12 May 2021, . 374 [I-D.ietf-idr-flowspec-mpls-match] 375 Yong, L., Hares, S., Liang, Q., and J. You, "BGP Flow 376 Specification Filter for MPLS Label", Work in Progress, 377 Internet-Draft, draft-ietf-idr-flowspec-mpls-match-01, 6 378 December 2016, . 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, 383 DOI 10.17487/RFC2119, March 1997, 384 . 386 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 387 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 388 May 2017, . 390 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 391 "Deterministic Networking Architecture", RFC 8655, 392 DOI 10.17487/RFC8655, October 2019, 393 . 395 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 396 Bryant, "Deterministic Networking (DetNet) Data Plane 397 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 398 . 400 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 401 Bacher, "Dissemination of Flow Specification Rules", 402 RFC 8955, DOI 10.17487/RFC8955, December 2020, 403 . 405 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 406 "Dissemination of Flow Specification Rules for IPv6", 407 RFC 8956, DOI 10.17487/RFC8956, December 2020, 408 . 410 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 411 S., and J. Korhonen, "Deterministic Networking (DetNet) 412 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 413 2021, . 415 [RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, 416 "Deterministic Networking (DetNet) Data Plane: IP over 417 IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023, 418 DOI 10.17487/RFC9023, June 2021, 419 . 421 [RFC9024] Varga, B., Ed., Farkas, J., Malis, A., Bryant, S., and D. 422 Fedyk, "Deterministic Networking (DetNet) Data Plane: IEEE 423 802.1 Time-Sensitive Networking over MPLS", RFC 9024, 424 DOI 10.17487/RFC9024, June 2021, 425 . 427 [RFC9037] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, 428 "Deterministic Networking (DetNet) Data Plane: MPLS over 429 IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9037, 430 DOI 10.17487/RFC9037, June 2021, 431 . 433 Authors' Addresses 435 Quan Xiong 436 ZTE Corporation 437 No.6 Huashi Park Rd 438 Wuhan 439 Hubei, 430223 440 China 442 Email: xiong.quan@zte.com.cn 444 Haisheng Wu 445 ZTE Corporation 446 Nanjing 447 Jiangsu, 448 China 450 Email: wu.haisheng@zte.com.cn 451 Junfeng Zhao 452 CAICT 453 China 455 Email: zhaojunfeng@caict.ac.cn