idnits 2.17.00 (12 Aug 2021) /tmp/idnits43597/draft-ietf-detnet-ip-over-tsn-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2021) is 449 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-detnet-security has been published as RFC 9055 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga, Ed. 3 Internet-Draft J. Farkas 4 Intended status: Informational Ericsson 5 Expires: August 23, 2021 A. Malis 6 Malis Consulting 7 S. Bryant 8 Futurewei Technologies 9 February 19, 2021 11 DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN) 12 draft-ietf-detnet-ip-over-tsn-07 14 Abstract 16 This document specifies the Deterministic Networking IP data plane 17 when operating over a TSN sub-network. This document does not define 18 new procedures or processes. Whenever this document makes statements 19 or recommendations, these are taken from normative text in the 20 referenced RFCs. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 23, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 59 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 60 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 3 61 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network . . . . 4 62 4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 5 63 4.2. TSN requirements of IP DetNet nodes . . . . . . . . . . . 6 64 4.3. Service protection within the TSN sub-network . . . . . . 7 65 4.4. Aggregation during DetNet flow to TSN Stream mapping . . 7 66 5. Management and Control Implications . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative references . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative references . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Deterministic Networking (DetNet) is a service that can be offered by 78 a network to DetNet flows. DetNet provides these flows extremely low 79 packet loss rates and assured maximum end-to-end delivery latency. 80 General background and concepts of DetNet can be found in the DetNet 81 Architecture [RFC8655]. 83 [RFC8939] specifies the DetNet data plane operation for IP hosts and 84 routers that provide DetNet service to IP encapsulated data. This 85 document focuses on the scenario where DetNet IP nodes are 86 interconnected by a TSN sub-network. 88 The DetNet Architecture decomposes the DetNet related data plane 89 functions into two sub-layers: a service sub-layer and a forwarding 90 sub-layer. The service sub-layer is used to provide DetNet service 91 protection and reordering. The forwarding sub-layer is used to 92 provides congestion protection (low loss, assured latency, and 93 limited reordering). As described in [RFC8939] no DetNet specific 94 headers are added to support DetNet IP flows. So, only the 95 forwarding sub-layer functions can be supported inside the DetNet IP 96 domain. Service protection can be provided on a per sub-network 97 basis as shown here for the IEEE802.1 TSN sub-network scenario. 99 2. Terminology 101 2.1. Terms Used In This Document 103 This document uses the terminology and concepts established in the 104 DetNet architecture [RFC8655]. TSN (Time-Sensitive Networking) 105 specific terms are defined in the TSN TG of IEEE 802.1 Working Group. 106 The reader is assumed to be familiar with these documents and their 107 terminology. 109 2.2. Abbreviations 111 The following abbreviations used in this document: 113 DetNet Deterministic Networking. 115 FRER Frame Replication and Elimination for Redundancy (TSN 116 function). 118 L2 Layer-2. 120 L3 Layer-3. 122 TSN Time-Sensitive Networking, TSN is a Task Group of the 123 IEEE 802.1 Working Group. 125 3. DetNet IP Data Plane Overview 127 [RFC8939] describes how IP is used by DetNet nodes, i.e., hosts and 128 routers, to identify DetNet flows and provide a DetNet service. From 129 a data plane perspective, an end-to-end IP model is followed. DetNet 130 uses "6-tuple" based flow identification, where "6-tuple" refers to 131 information carried in IP and higher layer protocol headers as 132 defined in [RFC8939]. . 134 DetNet flow aggregation may be enabled via the use of wildcards, 135 masks, prefixes and ranges. IP tunnels may also be used to support 136 flow aggregation. In these cases, it is expected that DetNet aware 137 intermediate nodes will provide DetNet service assurance on the 138 aggregate through resource allocation and congestion control 139 mechanisms. 141 Congestion protection, latency control and the resource allocation 142 (queuing, policing, shaping) are supported using the underlying link 143 / sub-net specific mechanisms. Service protections (packet 144 replication and packet elimination functions) are not provided at the 145 IP DetNet layer end-to-end due to the lack of a unified end-to-end 146 sequencing information that would be available for intermediate 147 nodes. However, such service protection can be provided on a per 148 underlying L2 link and sub-network basis. 150 DetNet routers ensure that DetNet service requirements are met per 151 hop by allocating local resources, both receive and transmit, and by 152 mapping the service requirements of each flow to appropriate sub- 153 network mechanisms. Such mappings are sub-network technology 154 specific. DetNet nodes interconnected by a TSN sub-network are the 155 primary focus of this document. The mapping of DetNet IP flows to 156 TSN streams and TSN protection mechanisms are covered in Section 4. 158 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network 160 This section covers how DetNet IP flows operate over an IEEE 802.1 161 TSN sub-network. Figure 1 illustrates such a scenario, where two IP 162 (DetNet) nodes are interconnected by a TSN sub-network. Dotted lines 163 around the Service components of the IP (DetNet) Nodes indicate that 164 they are DetNet service aware but do not perform any DetNet service 165 sub-layer function. Node-1 is single homed and Node-2 is dual-homed 166 to the TSN sub-network and they are treated as Talker or Listener 167 inside the TSN sub-network. Note, that from TSN perspective dual- 168 homed characteristics of Talker or Listener nodes are transparent to 169 the IP Layer. 171 IP (DetNet) IP (DetNet) 172 Node-1 Node-2 174 ............ ............ 175 <--: Service :-- DetNet flow ---: Service :--> 176 +----------+ +----------+ 177 |Forwarding| |Forwarding| 178 +--------.-+ <-TSN Str-> +-.-----.--+ 179 \ ,-------. / / 180 +----[ TSN-Sub ]---+ / 181 [ Network ]--------+ 182 `-------' 183 <----------------- DetNet IP -----------------> 185 Figure 1: DetNet (DN) Enabled IP Network over a TSN sub-network 187 At the time of this writing, the Time-Sensitive Networking (TSN) Task 188 Group of the IEEE 802.1 Working Group have defined (and are defining) 189 a number of amendments to [IEEE8021Q] that provide zero congestion 190 loss and bounded latency in bridged networks. Furthermore, 191 [IEEE8021CB] defines frame replication and elimination functions for 192 reliability that should prove both compatible with and useful to 193 DetNet networks. All these functions have to identify flows that 194 require TSN treatment. 196 TSN capabilities of the TSN sub-network are made available for IP 197 (DetNet) flows via the protocol interworking function described in 198 Annex C.5 of [IEEE8021CB]. For example, applied on the TSN edge port 199 it can convert an ingress unicast IP (DetNet) flow to use a specific 200 L2 multicast destination MAC address and a VLAN, in order to forward 201 the packet through a specific path inside the bridged network. A 202 similar interworking function pair at the other end of the TSN sub- 203 network would restore the packet to its original L2 destination MAC 204 address and VLAN. 206 Placement of TSN functions depends on the TSN capabilities of nodes. 207 IP (DetNet) Nodes may or may not support TSN functions. For a given 208 TSN Stream (i.e., a mapped DetNet flow) an IP (DetNet) node is 209 treated as a Talker or a Listener inside the TSN sub-network. 211 4.1. Functions for DetNet Flow to TSN Stream Mapping 213 Mapping of a DetNet IP flow to a TSN Stream is provided via the 214 combination of a passive and an active stream identification function 215 that operate at the frame level (Layer-2). The passive stream 216 identification function is used to catch the 6-tuple of a DetNet IP 217 flow and the active stream identification function is used to modify 218 the Ethernet header according to the ID of the mapped TSN Stream. 220 Clause 6.7 of [IEEE8021CB] defines an IP Stream identification 221 function that can be used as a passive function for IP DetNet flows 222 using UDP or TCP. Clause 6.8 of [IEEEP8021CBdb] defines a Mask-and- 223 Match Stream identification function that can be used as a passive 224 function for any IP DetNet flows. 226 Clause 6.6 of [IEEE8021CB] defines an Active Destination MAC and VLAN 227 Stream identification function, what can replace some Ethernet header 228 fields namely (1) the destination MAC-address, (2) the VLAN-ID and 229 (3) priority parameters with alternate values. Replacement is 230 provided for the frame passed down the stack from the upper layers or 231 up the stack from the lower layers. 233 Active Destination MAC and VLAN Stream identification can be used 234 within a Talker to set flow identity or a Listener to recover the 235 original addressing information. It can be used also in a TSN bridge 236 that is providing translation as a proxy service for an End System. 238 4.2. TSN requirements of IP DetNet nodes 240 This section covers the required behavior of a TSN-aware DetNet node 241 using a TSN sub-network. The implementation of TSN packet processing 242 functions must be compliant with the relevant IEEE 802.1 standards. 244 From the TSN sub-network perspective DetNet IP nodes are treated as 245 Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. 247 In cases of TSN-unaware IP DetNet nodes the TSN relay nodes within 248 the TSN sub-network must modify the Ethernet encapsulation of the 249 DetNet IP flow (e.g., MAC translation, VLAN-ID setting, Sequence 250 number addition, etc.) to allow proper TSN specific handling inside 251 the sub-network. There are no requirements defined for TSN-unaware 252 IP DetNet nodes in this document. 254 IP (DetNet) nodes being TSN-aware can be treated as a combination of 255 a TSN-unaware Talker/Listener and a TSN-Relay, as shown in Figure 2. 256 In such cases the IP (DetNet) node must provide the TSN sub-network 257 specific Ethernet encapsulation over the link(s) towards the sub- 258 network. 260 IP (DetNet) 261 Node 262 <----------------------------------> 264 ............ 265 <--: Service :-- DetNet flow ------------------ 266 +----------+ 267 |Forwarding| 268 +----------+ +---------------+ 269 | L2 | | L2 Relay with |<--- TSN --- 270 | | | TSN function | Stream 271 +-----.----+ +--.------.---.-+ 272 \__________/ \ \______ 273 \_________ 274 TSN-unaware 275 Talker / TSN-Bridge 276 Listener Relay 277 <----- TSN Sub-network ----- 278 <------- TSN-aware Tlk/Lstn -------> 280 Figure 2: IP (DetNet) node with TSN functions 282 A TSN-aware IP (DetNet) node impementations must support the Stream 283 Identification TSN component for recognizing flows. 285 A Stream identification component must be able to instantiate the 286 following functions (1) Active Destination MAC and VLAN Stream 287 identification function, (2) IP Stream identification function, (3) 288 Mask-and-Match Stream identification function and (4) the related 289 managed objects in Clause 9 of [IEEE8021CB] and [IEEEP8021CBdb]. 291 A TSN-aware IP (DetNet) node implementation must support the 292 Sequencing function and the Sequence encode/decode function as 293 defined in Clause 7.4 and 7.6 of [IEEE8021CB] if FRER is used inside 294 the TSN sub-network. 296 The Sequence encode/decode function must support the Redundancy tag 297 (R-TAG) format as per Clause 7.8 of [IEEE8021CB]. 299 A TSN-aware IP (DetNet) node implementations must support the Stream 300 splitting function and the Individual recovery function as defined in 301 Clause 7.7 and 7.5 of [IEEE8021CB] when the node is a replication or 302 elimination point for FRER. 304 4.3. Service protection within the TSN sub-network 306 TSN Streams supporting DetNet flows may use Frame Replication and 307 Elimination for Redundancy (FRER) as defined in Clause 8. of 308 [IEEE8021CB] based on the loss service requirements of the TSN 309 Stream, which is derived from the DetNet service requirements of the 310 DetNet mapped flow. The specific operation of FRER is not modified 311 by the use of DetNet and follows [IEEE8021CB]. 313 FRER function and the provided service recovery is available only 314 within the TSN sub-network as the TSN Stream-ID and the TSN sequence 315 number are not valid outside the sub-network. An IP (DetNet) node 316 represents a L3 border and as such it terminates all related 317 information elements encoded in the L2 frames. 319 4.4. Aggregation during DetNet flow to TSN Stream mapping 321 Implementations of this document shall use management and control 322 information to map a DetNet flow to a TSN Stream. N:1 mapping 323 (aggregating DetNet flows in a single TSN Stream) shall be supported. 324 The management or control function that provisions flow mapping shall 325 ensure that adequate resources are allocated and configured to 326 provide proper service requirements of the mapped flows. 328 5. Management and Control Implications 330 DetNet flow and TSN Stream mapping related information are required 331 only for TSN-aware IP (DetNet) nodes. From the Data Plane 332 perspective there is no practical difference based on the origin of 333 flow mapping related information (management plane or control plane). 335 The following summarizes the set of information that is needed to 336 configure DetNet IP over TSN: 338 o DetNet IP related configuration information according to the 339 DetNet role of the DetNet IP node, as per [RFC8939]. 341 o TSN related configuration information according to the TSN role of 342 the DetNet IP node, as per [IEEE8021Q], [IEEE8021CB] and 343 [IEEEP8021CBdb]. 345 o Mapping between DetNet IP flow(s) and TSN Stream(s). DetNet IP 346 flow identification is summarized in Section 5.1 of [RFC8939], and 347 includes all wildcards, port ranges and the ability to ignore 348 specific IP fields). For TSN Streams stream identification 349 information are defined in [IEEE8021CB] and [IEEEP8021CBdb]). 350 Note, that managed objects for TSN Stream identification can be 351 found in [IEEEP8021CBcv]. 353 This information must be provisioned per DetNet flow. 355 Mappings between DetNet and TSN management and control planes are out 356 of scope of this document. Some of the challenges are highligthed 357 below. 359 TSN-aware IP DetNet nodes are members of both the DetNet domain and 360 the TSN sub-network. Within the TSN sub-network the TSN-aware IP 361 (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific 362 management and control plane functionalities must be implemented. 363 There are many similarities in the management plane techniques used 364 in DetNet and TSN, but that is not the case for the control plane 365 protocols. For example, RSVP-TE and MSRP behaves differently. 366 Therefore management and control plane design is an important aspect 367 of scenarios, where mapping between DetNet and TSN is required. 369 In order to use a TSN sub-network between DetNet nodes, DetNet 370 specific information must be converted to TSN sub-network specific 371 ones. DetNet flow ID and flow related parameters/requirements must 372 be converted to a TSN Stream ID and stream related parameters/ 373 requirements. Note that, as the TSN sub-network is just a portion of 374 the end-to-end DetNet path (i.e., single hop from IP perspective), 375 some parameters (e.g., delay) may differ significantly. Other 376 parameters (like bandwidth) also may have to be tuned due to the L2 377 encapsulation used within the TSN sub-network. 379 In some cases it may be challenging to determine some TSN Stream 380 related information. For example, on a TSN-aware IP (DetNet) node 381 that acts as a Talker, it is quite obvious which DetNet node is the 382 Listener of the mapped TSN stream (i.e., the IP Next-Hop). However 383 it may be not trivial to locate the point/interface where that 384 Listener is connected to the TSN sub-network. Such attributes may 385 require interaction between control and management plane functions 386 and between DetNet and TSN domains. 388 Mapping between DetNet flow identifiers and TSN Stream identifiers, 389 if not provided explicitly, can be done by a TSN-aware IP (DetNet) 390 node locally based on information provided for configuration of the 391 TSN Stream identification functions (IP Stream identification, Mask- 392 and-match Stream identification and active Stream identification 393 function). 395 Triggering the setup/modification of a TSN Stream in the TSN sub- 396 network is an example where management and/or control plane 397 interactions are required between the DetNet and TSN sub-network. 398 TSN-unaware IP (DetNet) nodes make such a triggering even more 399 complicated as they are fully unaware of the sub-network and run 400 independently. 402 Configuration of TSN specific functions (e.g., FRER) inside the TSN 403 sub-network is a TSN domain specific decision and may not be visible 404 in the DetNet domain. 406 6. Security Considerations 408 Security considerations for DetNet are described in detail in 409 [I-D.ietf-detnet-security]. General security considerations are 410 described in [RFC8655]. DetNet IP data plane specific considerations 411 are summarized in [RFC8939]. This section considers exclusively 412 security considerations which are specific to the DetNet IP over TSN 413 sub-network scenario. 415 The sub-network between DetNet nodes needs to be subject to 416 appropriate confidentiality. Additionally, knowledge of what DetNet/ 417 TSN services are provided by a sub-network may supply information 418 that can be used in a variety of security attacks. The ability to 419 modify information exchanges between connected DetNet nodes may 420 result in bogus operations. Therefore, it is important that the 421 interface between DetNet nodes and TSN sub-network are subject to 422 authorization, authentication, and encryption. 424 The TSN sub-network operates at Layer-2 so various security 425 mechanisms defined by IEEE can be used to secure the connection 426 between the DetNet nodes (e.g., encryption may be provided using 427 MACSec [IEEE802.1AE-2018]). 429 7. IANA Considerations 431 None. 433 8. Acknowledgements 435 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, 436 Christophe Mangin and Jouni Korhonen for their various contributions 437 to this work. 439 9. References 441 9.1. Normative references 443 [IEEE8021CB] 444 IEEE 802.1, "Standard for Local and metropolitan area 445 networks - Frame Replication and Elimination for 446 Reliability (IEEE Std 802.1CB-2017)", 2017, 447 . 449 [IEEEP8021CBdb] 450 Mangin, C., "Extended Stream identification functions", 451 IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020, 452 . 455 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 456 "Deterministic Networking Architecture", RFC 8655, 457 DOI 10.17487/RFC8655, October 2019, 458 . 460 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 461 Bryant, "Deterministic Networking (DetNet) Data Plane: 462 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 463 . 465 9.2. Informative references 467 [I-D.ietf-detnet-security] 468 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 469 Networking (DetNet) Security Considerations", draft-ietf- 470 detnet-security-13 (work in progress), December 2020. 472 [IEEE802.1AE-2018] 473 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 474 Security (MACsec)", 2018, 475 . 477 [IEEE8021Q] 478 IEEE 802.1, "Standard for Local and metropolitan area 479 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 480 2018)", 2018, . 482 [IEEEP8021CBcv] 483 Kehrer, S., "FRER YANG Data Model and Management 484 Information Base Module", IEEE P802.1CBcv 485 /D0.4 P802.1CBcv, August 2020, 486 . 489 Authors' Addresses 491 Balazs Varga (editor) 492 Ericsson 493 Magyar Tudosok krt. 11. 494 Budapest 1117 495 Hungary 497 Email: balazs.a.varga@ericsson.com 499 Janos Farkas 500 Ericsson 501 Magyar Tudosok krt. 11. 502 Budapest 1117 503 Hungary 505 Email: janos.farkas@ericsson.com 507 Andrew G. Malis 508 Malis Consulting 510 Email: agmalis@gmail.com 512 Stewart Bryant 513 Futurewei Technologies 515 Email: stewart.bryant@gmail.com