idnits 2.17.1 draft-ietf-detnet-ip-over-tsn-06.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 12, 2021) is 1170 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-13 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 16, 2021 A. Malis 6 Malis Consulting 7 S. Bryant 8 Futurewei Technologies 9 February 12, 2021 11 DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN) 12 draft-ietf-detnet-ip-over-tsn-06 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 August 16, 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 . . . . . . . . . . . . . 8 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, only the forwarding 95 sub-layer functions are supported inside the DetNet domain. Service 96 protection can be provided on a per sub-network basis as shown here 97 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 specific terms are defined in the 105 TSN TG of IEEE 802.1 Working Group. The reader is assumed to be 106 familiar with these documents and their 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 3. DetNet IP Data Plane Overview 130 [RFC8939] describes how IP is used by DetNet nodes, i.e., hosts and 131 routers, to identify DetNet flows and provide a DetNet service. From 132 a data plane perspective, an end-to-end IP model is followed. DetNet 133 uses "6-tuple" based flow identification, where "6-tuple" refers to 134 information carried in IP and higher layer protocol headers. 136 DetNet flow aggregation may be enabled via the use of wildcards, 137 masks, prefixes and ranges. IP tunnels may also be used to support 138 flow aggregation. In these cases, it is expected that DetNet aware 139 intermediate nodes will provide DetNet service assurance on the 140 aggregate through resource allocation and congestion control 141 mechanisms. 143 Congestion protection, latency control and the resource allocation 144 (queuing, policing, shaping) are supported using the underlying link 145 / sub-net specific mechanisms. Service protections (packet 146 replication and packet elimination functions) are not provided at the 147 IP DetNet layer end-to-end due the lack of a unified end-to-end 148 sequencing information that would be available for intermediate 149 nodes. However, such service protection can be provided on a per 150 underlying L2 link and sub-network basis. 152 DetNet routers ensure that DetNet service requirements are met per 153 hop by allocating local resources, both receive and transmit, and by 154 mapping the service requirements of each flow to appropriate sub- 155 network mechanisms. Such mappings are sub-network technology 156 specific. DetNet nodes interconnected by a TSN sub-network are the 157 primary focus of this document. The mapping of DetNet IP flows to 158 TSN streams and TSN protection mechanisms are covered in Section 4. 160 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network 162 This section covers how DetNet IP flows operate over an IEEE 802.1 163 TSN sub-network. Figure 1 illustrates such a scenario, where two IP 164 (DetNet) nodes are interconnected by a TSN sub-network. Dotted lines 165 around the Service components of the IP (DetNet) Nodes indicate that 166 they are DetNet service aware but do not perform any DetNet service 167 sub-layer function. Node-1 is single homed and Node-2 is dual-homed 168 to the TSN sub-network. 170 IP (DetNet) IP (DetNet) 171 Node-1 Node-2 173 ............ ............ 174 <--: Service :-- DetNet flow ---: Service :--> 175 +----------+ +----------+ 176 |Forwarding| |Forwarding| 177 +--------.-+ <-TSN Str-> +-.-----.--+ 178 \ ,-------. / / 179 +----[ TSN-Sub ]---+ / 180 [ Network ]--------+ 181 `-------' 182 <----------------- DetNet IP -----------------> 184 Figure 1: DetNet (DN) Enabled IP Network over a TSN sub-network 186 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 187 Working Group have defined (and are defining) a number of amendments 188 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 189 bounded latency in bridged networks. Furthermore, IEEE 802.1CB 190 [IEEE8021CB] defines frame replication and elimination functions for 191 reliability that should prove both compatible with and useful to 192 DetNet networks. All these functions have to identify flows that 193 require TSN treatment. 195 TSN capabilities of the TSN sub-network are made available for IP 196 (DetNet) flows via the protocol interworking function described in 197 Annex C.5 of IEEE 802.1CB [IEEE8021CB]. For example, applied on the 198 TSN edge port it can convert an ingress unicast IP (DetNet) flow to 199 use a specific Layer-2 multicast destination MAC address and a VLAN, 200 in order to direct the packet through a specific path inside the 201 bridged network. A similar interworking function pair at the other 202 end of the TSN sub-network would restore the packet to its original 203 Layer-2 destination MAC address and VLAN. 205 Placement of TSN functions depends on the TSN capabilities of nodes. 206 IP (DetNet) Nodes may or may not support TSN functions. For a given 207 TSN Stream (i.e., a mapped DetNet flow) an IP (DetNet) node is 208 treated as a Talker or a Listener inside the TSN sub-network. 210 4.1. Functions for DetNet Flow to TSN Stream Mapping 212 Mapping of a DetNet IP flow to a TSN Stream is provided via the 213 combination of a passive and an active stream identification function 214 that operate at the frame level (Layer-2). The passive stream 215 identification function is used to catch the 6-tuple of a DetNet IP 216 flow and the active stream identification function is used to modify 217 the Ethernet header according to the ID of the mapped TSN Stream. 219 Clause 6.7 of IEEE 802.1CB [IEEE8021CB] defines an IP Stream 220 identification function that can be used as a passive function for IP 221 DetNet flows using UDP or TCP. Clause 6.8 of IEEE P802.1CBdb 222 [IEEEP8021CBdb] defines a Mask-and-Match Stream identification 223 function that can be used as a passive function for any IP DetNet 224 flows. 226 Clause 6.6 of IEEE 802.1CB [IEEE8021CB] defines an Active Destination 227 MAC and VLAN Stream identification function, what can replace some 228 Ethernet header fields namely (1) the destination MAC-address, (2) 229 the VLAN-ID and (3) priority parameters with alternate values. 230 Replacement is provided for the frame passed down the stack from the 231 upper layers or 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 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 IEEE 802.1CB [IEEE8021CB] and IEEE 290 P802.1CBdb [IEEEP8021CBdb]. 292 A TSN-aware IP (DetNet) node implementations must support the 293 Sequencing function and the Sequence encode/decode function as 294 defined in Clause 7.4 and 7.6 of IEEE 802.1CB [IEEE8021CB] if FRER is 295 used inside the TSN sub-network. 297 The Sequence encode/decode function must support the Redundancy tag 298 (R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB]. 300 A TSN-aware IP (DetNet) node implementations must support the Stream 301 splitting function and the Individual recovery function as defined in 302 Clause 7.7 and 7.5 of IEEE 802.1CB [IEEE8021CB] when the node is a 303 replication or elimination point for FRER. 305 4.3. Service protection within the TSN sub-network 307 TSN Streams supporting DetNet flows may use Frame Replication and 308 Elimination for Redundancy (FRER) as defined in Clause 8. of IEEE 309 802.1CB [IEEE8021CB] based on the loss service requirements of the 310 TSN Stream, which is derived from the DetNet service requirements of 311 the DetNet mapped flow. The specific operation of FRER is not 312 modified by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB]. 314 FRER function and the provided service recovery is available only 315 within the TSN sub-network as the TSN Stream-ID and the TSN sequence 316 number are not valid outside the sub-network. An IP (DetNet) node 317 represents a L3 border and as such it terminates all related 318 information elements encoded in the L2 frames. 320 4.4. Aggregation during DetNet flow to TSN Stream mapping 322 Implementations of this document shall use management and control 323 information to map a DetNet flow to a TSN Stream. N:1 mapping 324 (aggregating DetNet flows in a single TSN Stream) shall be supported. 325 The management or control function that provisions flow mapping shall 326 ensure that adequate resources are allocated and configured to 327 provide proper service requirements of the mapped flows. 329 5. Management and Control Implications 331 DetNet flow and TSN Stream mapping related information are required 332 only for TSN-aware IP (DetNet) nodes. From the Data Plane 333 perspective there is no practical difference based on the origin of 334 flow mapping related information (management plane or control plane). 336 The following summarizes the set of information that is needed to 337 configure DetNet IP over TSN: 339 o DetNet IP related configuration information according to the 340 DetNet role of the DetNet IP node, as per [RFC8939]. 342 o TSN related configuration information according to the TSN role of 343 the DetNet IP node, as per [IEEE8021Q], [IEEE8021CB] and 344 [IEEEP8021CBdb]. 346 o Mapping between DetNet IP flow(s) (as flow identification defined 347 in [RFC8939], it is summarized in Section 5.1 of that document, 348 and includes all wildcards, port ranges and the ability to ignore 349 specific IP fields) and TSN Stream(s) (as stream identification 350 information defined in [IEEE8021CB] and [IEEEP8021CBdb]). Note, 351 that managed objects for TSN Stream identification can be found in 352 [IEEEP8021CBcv]. 354 This information must be provisioned per DetNet flow. 356 Mappings between DetNet and TSN management and control planes are out 357 of scope of the document. Some of the challanges are highligthed 358 below. 360 TSN-aware IP DetNet nodes are member of both the DetNet domain and 361 the TSN sub-network. Within the TSN sub-network the TSN-aware IP 362 (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific 363 management and control plane functionalities must be implemented. 364 There are many similarities in the management plane techniques used 365 in DetNet and TSN, but that is not the case for the control plane 366 protocols. For example, RSVP-TE and MSRP behaves differently. 367 Therefore management and control plane design is an important aspect 368 of scenarios, where mapping between DetNet and TSN is required. 370 In order to use a TSN sub-network between DetNet nodes, DetNet 371 specific information must be converted to TSN sub-network specific 372 ones. DetNet flow ID and flow related parameters/requirements must 373 be converted to a TSN Stream ID and stream related parameters/ 374 requirements. Note that, as the TSN sub-network is just a portion of 375 the end-to-end DetNet path (i.e., single hop from IP perspective), 376 some parameters (e.g., delay) may differ significantly. Other 377 parameters (like bandwidth) also may have to be tuned due to the L2 378 encapsulation used within the TSN sub-network. 380 In some case it may be challenging to determine some TSN Stream 381 related information. For example, on a TSN-aware IP (DetNet) node 382 that acts as a Talker, it is quite obvious which DetNet node is the 383 Listener of the mapped TSN stream (i.e., the IP Next-Hop). However 384 it may be not trivial to locate the point/interface where that 385 Listener is connected to the TSN sub-network. Such attributes may 386 require interaction between control and management plane functions 387 and between DetNet and TSN domains. 389 Mapping between DetNet flow identifiers and TSN Stream identifiers, 390 if not provided explicitly, can be done by a TSN-aware IP (DetNet) 391 node locally based on information provided for configuration of the 392 TSN Stream identification functions (IP Stream identification, Mask- 393 and-match Stream identification and active Stream identification 394 function). 396 Triggering the setup/modification of a TSN Stream in the TSN sub- 397 network is an example where management and/or control plane 398 interactions are required between the DetNet and TSN sub-network. 399 TSN-unaware IP (DetNet) nodes make such a triggering even more 400 complicated as they are fully unaware of the sub-network and run 401 independently. 403 Configuration of TSN specific functions (e.g., FRER) inside the TSN 404 sub-network is a TSN domain specific decision and may not be visible 405 in the DetNet domain. 407 6. Security Considerations 409 Security considerations for DetNet are described in detail in 410 [I-D.ietf-detnet-security]. General security considerations are 411 described in [RFC8655]. DetNet IP data plane specific considerations 412 are summarized in [RFC8939]. This section considers exclusively 413 security considerations which are specific to the DetNet IP over TSN 414 sub-network scenario. 416 The sub-network between DetNet nodes needs to be subject to 417 appropriate confidentiality. Additionally, knowledge of what DetNet/ 418 TSN services are provided by a sub-network may supply information 419 that can be used in a variety of security attacks. The ability to 420 modify information exchanges between connected DetNet nodes may 421 result in bogus operations. Therefore, it is important that the 422 interface between DetNet nodes and TSN sub-network are subject to 423 authorization, authentication, and encryption. 425 The TSN sub-network operates at Layer-2 so various security 426 mechanisms defined by IEEE can be used to secure the connection 427 between the DetNet nodes (e.g., encryption may be provided using 428 MACSec [IEEE802.1AE-2018]). 430 7. IANA Considerations 432 None. 434 8. Acknowledgements 436 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, 437 Christophe Mangin and Jouni Korhonen for their various contributions 438 to this work. 440 9. References 442 9.1. Normative references 444 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 445 Bryant, "Deterministic Networking (DetNet) Data Plane: 446 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 447 . 449 9.2. Informative references 451 [I-D.ietf-detnet-security] 452 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 453 Networking (DetNet) Security Considerations", draft-ietf- 454 detnet-security-13 (work in progress), December 2020. 456 [IEEE802.1AE-2018] 457 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 458 Security (MACsec)", 2018, 459 . 461 [IEEE8021CB] 462 IEEE 802.1, "Standard for Local and metropolitan area 463 networks - Frame Replication and Elimination for 464 Reliability (IEEE Std 802.1CB-2017)", 2017, 465 . 467 [IEEE8021Q] 468 IEEE 802.1, "Standard for Local and metropolitan area 469 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 470 2018)", 2018, . 472 [IEEEP8021CBcv] 473 Kehrer, S., "FRER YANG Data Model and Management 474 Information Base Module", IEEE P802.1CBcv 475 /D0.4 P802.1CBcv, August 2020, 476 . 479 [IEEEP8021CBdb] 480 Mangin, C., "Extended Stream identification functions", 481 IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020, 482 . 485 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 486 "Deterministic Networking Architecture", RFC 8655, 487 DOI 10.17487/RFC8655, October 2019, 488 . 490 Authors' Addresses 492 Balazs Varga (editor) 493 Ericsson 494 Magyar Tudosok krt. 11. 495 Budapest 1117 496 Hungary 498 Email: balazs.a.varga@ericsson.com 500 Janos Farkas 501 Ericsson 502 Magyar Tudosok krt. 11. 503 Budapest 1117 504 Hungary 506 Email: janos.farkas@ericsson.com 508 Andrew G. Malis 509 Malis Consulting 511 Email: agmalis@gmail.com 513 Stewart Bryant 514 Futurewei Technologies 516 Email: stewart.bryant@gmail.com