idnits 2.17.00 (12 Aug 2021) /tmp/idnits49260/draft-ietf-detnet-ip-over-tsn-04.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 565 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-detnet-flow-information-model' is defined on line 469, but no explicit reference was found in the text == Outdated reference: draft-ietf-detnet-ip has been published as RFC 8939 == Outdated reference: draft-ietf-detnet-flow-information-model has been published as RFC 9016 == Outdated reference: draft-ietf-detnet-security has been published as RFC 9055 Summary: 0 errors (**), 0 flaws (~~), 6 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: May 6, 2021 A. Malis 6 Malis Consulting 7 S. Bryant 8 Futurewei Technologies 9 November 2, 2020 11 DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN) 12 draft-ietf-detnet-ip-over-tsn-04 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 19 requirements statements or recommendations, these are taken from 20 normative text in the 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 May 6, 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 3 62 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network . . . . 4 63 4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 5 64 4.2. TSN requirements of IP DetNet nodes . . . . . . . . . . . 6 65 4.3. Service protection within the TSN sub-network . . . . . . 8 66 4.4. Aggregation during DetNet flow to TSN Stream mapping . . 8 67 5. Management and Control Implications . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.1. Normative references . . . . . . . . . . . . . . . . . . 10 73 9.2. Informative references . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 Deterministic Networking (DetNet) is a service that can be offered by 79 a network to DetNet flows. DetNet provides these flows extremely low 80 packet loss rates and assured maximum end-to-end delivery latency. 81 General background and concepts of DetNet can be found in the DetNet 82 Architecture [RFC8655]. 84 [I-D.ietf-detnet-ip] specifies the DetNet data plane operation for IP 85 hosts and routers that provide DetNet service to IP encapsulated 86 data. This document focuses on the scenario where DetNet IP nodes 87 are interconnected by a TSN sub-network. 89 The DetNet Architecture decomposes the DetNet related data plane 90 functions into two sub-layers: a service sub-layer and a forwarding 91 sub-layer. The service sub-layer is used to provide DetNet service 92 protection and reordering. The forwarding sub-layer is used to 93 provides congestion protection (low loss, assured latency, and 94 limited reordering). As described in [I-D.ietf-detnet-ip] no DetNet 95 specific headers are added to support DetNet IP flows, only the 96 forwarding sub-layer functions are supported inside the DetNet 97 domain. Service protection can be provided on a per sub-network 98 basis as shown here for the IEEE802.1 TSN sub-network scenario. 100 2. Terminology 102 2.1. Terms Used In This Document 104 This document uses the terminology and concepts established in the 105 DetNet architecture [RFC8655], and the reader is assumed to be 106 familiar with that document and its terminology. 108 2.2. Abbreviations 110 The following abbreviations used in this document: 112 DetNet Deterministic Networking. 114 DF DetNet Flow. 116 FRER Frame Replication and Elimination for Redundancy (TSN 117 function). 119 L2 Layer-2. 121 L3 Layer-3. 123 PREOF Packet Replication, Ordering and Elimination Function. 125 TSN Time-Sensitive Networking, TSN is a Task Group of the 126 IEEE 802.1 Working Group. 128 2.3. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 3. DetNet IP Data Plane Overview 138 [I-D.ietf-detnet-ip] describes how IP is used by DetNet nodes, i.e., 139 hosts and routers, to identify DetNet flows and provide a DetNet 140 service. From a data plane perspective, an end-to-end IP model is 141 followed. DetNet uses "6-tuple" based flow identification, where 142 "6-tuple" refers to information carried in IP and higher layer 143 protocol headers. 145 DetNet flow aggregation may be enabled via the use of wildcards, 146 masks, prefixes and ranges. IP tunnels may also be used to support 147 flow aggregation. In these cases, it is expected that DetNet aware 148 intermediate nodes will provide DetNet service assurance on the 149 aggregate through resource allocation and congestion control 150 mechanisms. 152 Congestion protection, latency control and the resource allocation 153 (queuing, policing, shaping) are supported using the underlying link 154 / sub-net specific mechanisms. Service protections (packet 155 replication and packet elimination functions) are not provided at the 156 IP DetNet layer end-to-end due the lack of a unified end-to-end 157 sequencing information that would be available for intermediate 158 nodes. However, such service protection can be provided on a per 159 underlying L2 link and sub-network basis. 161 DetNet routers ensure that DetNet service requirements are met per 162 hop by allocating local resources, both receive and transmit, and by 163 mapping the service requirements of each flow to appropriate sub- 164 network mechanisms. Such mappings are sub-network technology 165 specific. DetNet nodes interconnected by a TSN sub-network are the 166 primary focus of this document. The mapping of DetNet IP flows to 167 TSN streams and TSN protection mechanisms are covered in Section 4. 169 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network 171 This section covers how DetNet IP flows operate over an IEEE 802.1 172 TSN sub-network. Figure 1 illustrates such a scenario, where two IP 173 (DetNet) nodes are interconnected by a TSN sub-network. Dotted lines 174 around the Service components of the IP (DetNet) Nodes indicate that 175 they are DetNet service aware but do not perform any DetNet service 176 sub-layer function. Node-1 is single homed and Node-2 is dual-homed 177 to the TSN sub-network. 179 IP (DetNet) IP (DetNet) 180 Node-1 Node-2 182 ............ ............ 183 <--: Service :-- DetNet flow ---: Service :--> 184 +----------+ +----------+ 185 |Forwarding| |Forwarding| 186 +--------.-+ <-TSN Str-> +-.-----.--+ 187 \ ,-------. / / 188 +----[ TSN-Sub ]---+ / 189 [ Network ]--------+ 190 `-------' 191 <----------------- DetNet IP -----------------> 193 Figure 1: DetNet (DN) Enabled IP Network over a TSN sub-network 195 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 196 Working Group have defined (and are defining) a number of amendments 197 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 198 bounded latency in bridged networks. Furthermore, IEEE 802.1CB 199 [IEEE8021CB] defines frame replication and elimination functions for 200 reliability that should prove both compatible with and useful to 201 DetNet networks. All these functions have to identify flows that 202 require TSN treatment. 204 TSN capabilities of the TSN sub-network are made available for IP 205 (DetNet) flows via the protocol interworking function desribed in 206 Annex C.5 of IEEE 802.1CB [IEEE8021CB]. For example, applied on the 207 TSN edge port it can convert an ingress unicast IP (DetNet) flow to 208 use a specific Layer-2 multicast destination MAC address and a VLAN, 209 in order to direct the packet through a specific path inside the 210 bridged network. A similar interworking function pair at the other 211 end of the TSN sub-network would restore the packet to its original 212 Layer-2 destination MAC address and VLAN. 214 Placement of TSN functions depends on the TSN capabilities of nodes. 215 IP (DetNet) Nodes may or may not support TSN functions. For a given 216 TSN Stream (i.e., a mapped DetNet flow) an IP (DetNet) node is 217 treated as a Talker or a Listener inside the TSN sub-network. 219 4.1. Functions for DetNet Flow to TSN Stream Mapping 221 Mapping of a DetNet IP flow to a TSN Stream is provided via the 222 combination of a passive and an active stream identification function 223 that operate at the frame level (Layer-2). The passive stream 224 identification function is used to catch the 6-tuple of a DetNet IP 225 flow and the active stream identification function is used to modify 226 the Ethernet header according to the ID of the mapped TSN Stream. 228 Clause 6.7 of IEEE 802.1CB [IEEE8021CB] defines an IP Stream 229 identification function that can be used as a passive function for IP 230 DetNet flows using UDP or TCP. Clause 6.8 of IEEE P802.1CBdb 231 [IEEEP8021CBdb] defines a Mask-and-Match Stream identification 232 function that can be used as a passive function for any IP DetNet 233 flows. 235 Clause 6.6 of IEEE 802.1CB [IEEE8021CB] defines an Active Destination 236 MAC and VLAN Stream identification function, what can replace some 237 Ethernet header fields namely (1) the destination MAC-address, (2) 238 the VLAN-ID and (3) priority parameters with alternate values. 239 Replacement is provided for the frame passed down the stack from the 240 upper layers or up the stack from the lower layers. 242 Active Destination MAC and VLAN Stream identification can be used 243 within a Talker to set flow identity or a Listener to recover the 244 original addressing information. It can be used also in a TSN bridge 245 that is providing translation as a proxy service for an End System. 247 4.2. TSN requirements of IP DetNet nodes 249 This section covers required behavior of a TSN-aware DetNet node 250 using a TSN sub-network. The implementation of TSN packet processing 251 functions must be compliant with the relevant IEEE 802.1 standards. 253 From the TSN sub-network perspective DetNet IP nodes are treated as 254 Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. 256 In cases of TSN-unaware IP DetNet nodes the TSN relay nodes within 257 the TSN sub-network must modify the Ethernet encapsulation of the 258 DetNet IP flow (e.g., MAC translation, VLAN-ID setting, Sequence 259 number addition, etc.) to allow proper TSN specific handling inside 260 the sub-network. There are no requirements defined for TSN-unaware 261 IP DetNet nodes in this document. 263 IP (DetNet) nodes being TSN-aware can be treated as a combination of 264 a TSN-unaware Talker/Listener and a TSN-Relay, as shown in Figure 2. 265 In such cases the IP (DetNet) node must provide the TSN sub-network 266 specific Ethernet encapsulation over the link(s) towards the sub- 267 network. 269 IP (DetNet) 270 Node 271 <----------------------------------> 273 ............ 274 <--: Service :-- DetNet flow ------------------ 275 +----------+ 276 |Forwarding| 277 +----------+ +---------------+ 278 | L2 | | L2 Relay with |<--- TSN --- 279 | | | TSN function | Stream 280 +-----.----+ +--.------.---.-+ 281 \__________/ \ \______ 282 \_________ 283 TSN-unaware 284 Talker / TSN-Bridge 285 Listener Relay 286 <----- TSN Sub-network ----- 287 <------- TSN-aware Tlk/Lstn -------> 289 Figure 2: IP (DetNet) node with TSN functions 291 A TSN-aware IP (DetNet) node impementations must support the Stream 292 Identification TSN component for recognizing flows. 294 A Stream identification component must be able to instantiate the 295 following functions (1) Active Destination MAC and VLAN Stream 296 identification function, (2) IP Stream identification function, (3) 297 Mask-and-Match Stream identification function and (4) the related 298 managed objects in Clause 9 of IEEE 802.1CB [IEEE8021CB] and IEEE 299 P802.1CBdb [IEEEP8021CBdb]. 301 A TSN-aware IP (DetNet) node implementations must support the 302 Sequencing function and the Sequence encode/decode function as 303 defined in Clause 7.4 and 7.6 of IEEE 802.1CB [IEEE8021CB] if FRER is 304 used inside the TSN sub-network. 306 The Sequence encode/decode function must support the Redundancy tag 307 (R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB]. 309 A TSN-aware IP (DetNet) node implementations must support the Stream 310 splitting function and the Individual recovery function as defined in 311 Clause 7.7 and 7.5 of IEEE 802.1CB [IEEE8021CB] when the node is a 312 replication or elimination point for FRER. 314 4.3. Service protection within the TSN sub-network 316 TSN Streams supporting DetNet flows may use Frame Replication and 317 Elimination for Redundancy (FRER) as defined in Clause 8. of IEEE 318 802.1CB [IEEE8021CB] based on the loss service requirements of the 319 TSN Stream, which is derived from the DetNet service requirements of 320 the DetNet mapped flow. The specific operation of FRER is not 321 modified by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB]. 323 FRER function and the provided service recovery is available only 324 within the TSN sub-network as the TSN Stream-ID and the TSN sequence 325 number are not valid outside the sub-network. An IP (DetNet) node 326 represents a L3 border and as such it terminates all related 327 information elements encoded in the L2 frames. 329 4.4. Aggregation during DetNet flow to TSN Stream mapping 331 Implementations of this document shall use management and control 332 information to map a DetNet flow to a TSN Stream. N:1 mapping 333 (aggregating DetNet flows in a single TSN Stream) shall be supported. 334 The management or control function that provisions flow mapping shall 335 ensure that adequate resources are allocated and configured to 336 provide proper service requirements of the mapped flows. 338 5. Management and Control Implications 340 DetNet flow and TSN Stream mapping related information are required 341 only for TSN-aware IP (DetNet) nodes. From the Data Plane 342 perspective there is no practical difference based on the origin of 343 flow mapping related information (management plane or control plane). 345 The following summarizes the set of information that is needed to 346 configure DetNet IP over TSN: 348 o DetNet IP related configuration information according to the 349 DetNet role of the DetNet IP node, as per [I-D.ietf-detnet-ip]. 351 o TSN related configuration information according to the TSN role of 352 the DetNet IP node, as per [IEEE8021Q], [IEEE8021CB] and 353 [IEEEP8021CBdb]. 355 o Mapping between DetNet IP flow(s) (as flow identification defined 356 in [I-D.ietf-detnet-ip], it is summarized in Section 5.1 of that 357 document, and includes all wildcards, port ranges and the ability 358 to ignore specific IP fields) and TSN Stream(s) (as stream 359 identification information defined in [IEEE8021CB] and 360 [IEEEP8021CBdb]). Note, that managed objects for TSN Stream 361 identification can be found in [IEEEP8021CBcv]. 363 This information must be provisioned per DetNet flow. 365 Mappings between DetNet and TSN management and control planes are out 366 of scope of the document. Some of the challanges are highligthed 367 below. 369 TSN-aware IP DetNet nodes are member of both the DetNet domain and 370 the TSN sub-network. Within the TSN sub-network the TSN-aware IP 371 (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific 372 management and control plane functionalities must be implemented. 373 There are many similarities in the management plane techniques used 374 in DetNet and TSN, but that is not the case for the control plane 375 protocols. For example, RSVP-TE and MSRP behaves differently. 376 Therefore management and control plane design is an important aspect 377 of scenarios, where mapping between DetNet and TSN is required. 379 In order to use a TSN sub-network between DetNet nodes, DetNet 380 specific information must be converted to TSN sub-network specific 381 ones. DetNet flow ID and flow related parameters/requirements must 382 be converted to a TSN Stream ID and stream related parameters/ 383 requirements. Note that, as the TSN sub-network is just a portion of 384 the end-to-end DetNet path (i.e., single hop from IP perspective), 385 some parameters (e.g., delay) may differ significantly. Other 386 parameters (like bandwidth) also may have to be tuned due to the L2 387 encapsulation used within the TSN sub-network. 389 In some case it may be challenging to determine some TSN Stream 390 related information. For example, on a TSN-aware IP (DetNet) node 391 that acts as a Talker, it is quite obvious which DetNet node is the 392 Listener of the mapped TSN stream (i.e., the IP Next-Hop). However 393 it may be not trivial to locate the point/interface where that 394 Listener is connected to the TSN sub-network. Such attributes may 395 require interaction between control and management plane functions 396 and between DetNet and TSN domains. 398 Mapping between DetNet flow identifiers and TSN Stream identifiers, 399 if not provided explicitly, can be done by a TSN-aware IP (DetNet) 400 node locally based on information provided for configuration of the 401 TSN Stream identification functions (IP Stream identification, Mask- 402 and-match Stream identification and active Stream identification 403 function). 405 Triggering the setup/modification of a TSN Stream in the TSN sub- 406 network is an example where management and/or control plane 407 interactions are required between the DetNet and TSN sub-network. 408 TSN-unaware IP (DetNet) nodes make such a triggering even more 409 complicated as they are fully unaware of the sub-network and run 410 independently. 412 Configuration of TSN specific functions (e.g., FRER) inside the TSN 413 sub-network is a TSN domain specific decision and may not be visible 414 in the DetNet domain. 416 6. Security Considerations 418 Security considerations for DetNet are described in detail in 419 [I-D.ietf-detnet-security]. General security considerations are 420 described in [RFC8655]. DetNet IP data plane specific considerations 421 are summarized in [I-D.ietf-detnet-ip]. This section considers 422 exclusively security considerations which are specific to the DetNet 423 IP over TSN sub-network scenario. 425 The sub-network between DetNet nodes needs to be subject to 426 appropriate confidentiality. Additionally, knowledge of what DetNet/ 427 TSN services are provided by a sub-network may supply information 428 that can be used in a variety of security attacks. The ability to 429 modify information exchanges between connected DetNet nodes may 430 result in bogus operations. Therefore, it is important that the 431 interface between DetNet nodes and TSN sub-network are subject to 432 authorization, authentication, and encryption. 434 The TSN sub-network operates at Layer-2 so various security 435 mechanisms defined by IEEE can be used to secure the connection 436 between the DetNet nodes (e.g., encryption may be provided using 437 MACSec [IEEE802.1AE-2018]). 439 7. IANA Considerations 441 None. 443 8. Acknowledgements 445 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, 446 Christophe Mangin and Jouni Korhonen for their various contributions 447 to this work. 449 9. References 451 9.1. Normative references 453 [I-D.ietf-detnet-ip] 454 Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. 455 Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 456 (work in progress), July 2020. 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, 460 DOI 10.17487/RFC2119, March 1997, 461 . 463 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 464 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 465 May 2017, . 467 9.2. Informative references 469 [I-D.ietf-detnet-flow-information-model] 470 Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. 471 Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- 472 flow-information-model-11 (work in progress), October 473 2020. 475 [I-D.ietf-detnet-security] 476 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 477 Networking (DetNet) Security Considerations", draft-ietf- 478 detnet-security-12 (work in progress), October 2020. 480 [IEEE802.1AE-2018] 481 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 482 Security (MACsec)", 2018, 483 . 485 [IEEE8021CB] 486 IEEE 802.1, "Standard for Local and metropolitan area 487 networks - Frame Replication and Elimination for 488 Reliability (IEEE Std 802.1CB-2017)", 2017, 489 . 491 [IEEE8021Q] 492 IEEE 802.1, "Standard for Local and metropolitan area 493 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 494 2018)", 2018, . 496 [IEEEP8021CBcv] 497 Kehrer, S., "FRER YANG Data Model and Management 498 Information Base Module", IEEE P802.1CBcv 499 /D0.4 P802.1CBcv, August 2020, 500 . 503 [IEEEP8021CBdb] 504 Mangin, C., "Extended Stream identification functions", 505 IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020, 506 . 509 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 510 "Deterministic Networking Architecture", RFC 8655, 511 DOI 10.17487/RFC8655, October 2019, 512 . 514 Authors' Addresses 516 Balazs Varga (editor) 517 Ericsson 518 Magyar Tudosok krt. 11. 519 Budapest 1117 520 Hungary 522 Email: balazs.a.varga@ericsson.com 524 Janos Farkas 525 Ericsson 526 Magyar Tudosok krt. 11. 527 Budapest 1117 528 Hungary 530 Email: janos.farkas@ericsson.com 532 Andrew G. Malis 533 Malis Consulting 535 Email: agmalis@gmail.com 537 Stewart Bryant 538 Futurewei Technologies 540 Email: stewart.bryant@gmail.com