idnits 2.17.1 draft-ietf-detnet-ip-over-tsn-05.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 (December 13, 2020) is 1229 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-12 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: June 16, 2021 A. Malis 6 Malis Consulting 7 S. Bryant 8 Futurewei Technologies 9 December 13, 2020 11 DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN) 12 draft-ietf-detnet-ip-over-tsn-05 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 June 16, 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 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], and the reader is assumed to be 105 familiar with that document and its terminology. 107 2.2. Abbreviations 109 The following abbreviations used in this document: 111 DetNet Deterministic Networking. 113 DF DetNet Flow. 115 FRER Frame Replication and Elimination for Redundancy (TSN 116 function). 118 L2 Layer-2. 120 L3 Layer-3. 122 PREOF Packet Replication, Ordering and Elimination Function. 124 TSN Time-Sensitive Networking, TSN is a Task Group of the 125 IEEE 802.1 Working Group. 127 3. DetNet IP Data Plane Overview 129 [RFC8939] describes how IP is used by DetNet nodes, i.e., hosts and 130 routers, to identify DetNet flows and provide a DetNet service. From 131 a data plane perspective, an end-to-end IP model is followed. DetNet 132 uses "6-tuple" based flow identification, where "6-tuple" refers to 133 information carried in IP and higher layer protocol headers. 135 DetNet flow aggregation may be enabled via the use of wildcards, 136 masks, prefixes and ranges. IP tunnels may also be used to support 137 flow aggregation. In these cases, it is expected that DetNet aware 138 intermediate nodes will provide DetNet service assurance on the 139 aggregate through resource allocation and congestion control 140 mechanisms. 142 Congestion protection, latency control and the resource allocation 143 (queuing, policing, shaping) are supported using the underlying link 144 / sub-net specific mechanisms. Service protections (packet 145 replication and packet elimination functions) are not provided at the 146 IP DetNet layer end-to-end due the lack of a unified end-to-end 147 sequencing information that would be available for intermediate 148 nodes. However, such service protection can be provided on a per 149 underlying L2 link and sub-network basis. 151 DetNet routers ensure that DetNet service requirements are met per 152 hop by allocating local resources, both receive and transmit, and by 153 mapping the service requirements of each flow to appropriate sub- 154 network mechanisms. Such mappings are sub-network technology 155 specific. DetNet nodes interconnected by a TSN sub-network are the 156 primary focus of this document. The mapping of DetNet IP flows to 157 TSN streams and TSN protection mechanisms are covered in Section 4. 159 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network 161 This section covers how DetNet IP flows operate over an IEEE 802.1 162 TSN sub-network. Figure 1 illustrates such a scenario, where two IP 163 (DetNet) nodes are interconnected by a TSN sub-network. Dotted lines 164 around the Service components of the IP (DetNet) Nodes indicate that 165 they are DetNet service aware but do not perform any DetNet service 166 sub-layer function. Node-1 is single homed and Node-2 is dual-homed 167 to the TSN sub-network. 169 IP (DetNet) IP (DetNet) 170 Node-1 Node-2 172 ............ ............ 173 <--: Service :-- DetNet flow ---: Service :--> 174 +----------+ +----------+ 175 |Forwarding| |Forwarding| 176 +--------.-+ <-TSN Str-> +-.-----.--+ 177 \ ,-------. / / 178 +----[ TSN-Sub ]---+ / 179 [ Network ]--------+ 180 `-------' 181 <----------------- DetNet IP -----------------> 183 Figure 1: DetNet (DN) Enabled IP Network over a TSN sub-network 185 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 186 Working Group have defined (and are defining) a number of amendments 187 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 188 bounded latency in bridged networks. Furthermore, IEEE 802.1CB 189 [IEEE8021CB] defines frame replication and elimination functions for 190 reliability that should prove both compatible with and useful to 191 DetNet networks. All these functions have to identify flows that 192 require TSN treatment. 194 TSN capabilities of the TSN sub-network are made available for IP 195 (DetNet) flows via the protocol interworking function desribed in 196 Annex C.5 of IEEE 802.1CB [IEEE8021CB]. For example, applied on the 197 TSN edge port it can convert an ingress unicast IP (DetNet) flow to 198 use a specific Layer-2 multicast destination MAC address and a VLAN, 199 in order to direct the packet through a specific path inside the 200 bridged network. A similar interworking function pair at the other 201 end of the TSN sub-network would restore the packet to its original 202 Layer-2 destination MAC address and VLAN. 204 Placement of TSN functions depends on the TSN capabilities of nodes. 205 IP (DetNet) Nodes may or may not support TSN functions. For a given 206 TSN Stream (i.e., a mapped DetNet flow) an IP (DetNet) node is 207 treated as a Talker or a Listener inside the TSN sub-network. 209 4.1. Functions for DetNet Flow to TSN Stream Mapping 211 Mapping of a DetNet IP flow to a TSN Stream is provided via the 212 combination of a passive and an active stream identification function 213 that operate at the frame level (Layer-2). The passive stream 214 identification function is used to catch the 6-tuple of a DetNet IP 215 flow and the active stream identification function is used to modify 216 the Ethernet header according to the ID of the mapped TSN Stream. 218 Clause 6.7 of IEEE 802.1CB [IEEE8021CB] defines an IP Stream 219 identification function that can be used as a passive function for IP 220 DetNet flows using UDP or TCP. Clause 6.8 of IEEE P802.1CBdb 221 [IEEEP8021CBdb] defines a Mask-and-Match Stream identification 222 function that can be used as a passive function for any IP DetNet 223 flows. 225 Clause 6.6 of IEEE 802.1CB [IEEE8021CB] defines an Active Destination 226 MAC and VLAN Stream identification function, what can replace some 227 Ethernet header fields namely (1) the destination MAC-address, (2) 228 the VLAN-ID and (3) priority parameters with alternate values. 229 Replacement is provided for the frame passed down the stack from the 230 upper layers or up the stack from the lower layers. 232 Active Destination MAC and VLAN Stream identification can be used 233 within a Talker to set flow identity or a Listener to recover the 234 original addressing information. It can be used also in a TSN bridge 235 that is providing translation as a proxy service for an End System. 237 4.2. TSN requirements of IP DetNet nodes 239 This section covers required behavior of a TSN-aware DetNet node 240 using a TSN sub-network. The implementation of TSN packet processing 241 functions must be compliant with the relevant IEEE 802.1 standards. 243 From the TSN sub-network perspective DetNet IP nodes are treated as 244 Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. 246 In cases of TSN-unaware IP DetNet nodes the TSN relay nodes within 247 the TSN sub-network must modify the Ethernet encapsulation of the 248 DetNet IP flow (e.g., MAC translation, VLAN-ID setting, Sequence 249 number addition, etc.) to allow proper TSN specific handling inside 250 the sub-network. There are no requirements defined for TSN-unaware 251 IP DetNet nodes in this document. 253 IP (DetNet) nodes being TSN-aware can be treated as a combination of 254 a TSN-unaware Talker/Listener and a TSN-Relay, as shown in Figure 2. 255 In such cases the IP (DetNet) node must provide the TSN sub-network 256 specific Ethernet encapsulation over the link(s) towards the sub- 257 network. 259 IP (DetNet) 260 Node 261 <----------------------------------> 263 ............ 264 <--: Service :-- DetNet flow ------------------ 265 +----------+ 266 |Forwarding| 267 +----------+ +---------------+ 268 | L2 | | L2 Relay with |<--- TSN --- 269 | | | TSN function | Stream 270 +-----.----+ +--.------.---.-+ 271 \__________/ \ \______ 272 \_________ 273 TSN-unaware 274 Talker / TSN-Bridge 275 Listener Relay 276 <----- TSN Sub-network ----- 277 <------- TSN-aware Tlk/Lstn -------> 279 Figure 2: IP (DetNet) node with TSN functions 281 A TSN-aware IP (DetNet) node impementations must support the Stream 282 Identification TSN component for recognizing flows. 284 A Stream identification component must be able to instantiate the 285 following functions (1) Active Destination MAC and VLAN Stream 286 identification function, (2) IP Stream identification function, (3) 287 Mask-and-Match Stream identification function and (4) the related 288 managed objects in Clause 9 of IEEE 802.1CB [IEEE8021CB] and IEEE 289 P802.1CBdb [IEEEP8021CBdb]. 291 A TSN-aware IP (DetNet) node implementations must support the 292 Sequencing function and the Sequence encode/decode function as 293 defined in Clause 7.4 and 7.6 of IEEE 802.1CB [IEEE8021CB] if FRER is 294 used inside 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 IEEE 802.1CB [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 IEEE 802.1CB [IEEE8021CB] when the node is a 302 replication or 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 IEEE 308 802.1CB [IEEE8021CB] based on the loss service requirements of the 309 TSN Stream, which is derived from the DetNet service requirements of 310 the DetNet mapped flow. The specific operation of FRER is not 311 modified by the use of DetNet and follows IEEE 802.1CB [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) (as flow identification defined 346 in [RFC8939], it is summarized in Section 5.1 of that document, 347 and includes all wildcards, port ranges and the ability to ignore 348 specific IP fields) and TSN Stream(s) (as stream identification 349 information defined in [IEEE8021CB] and [IEEEP8021CBdb]). Note, 350 that managed objects for TSN Stream identification can be found in 351 [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 the document. Some of the challanges are highligthed 357 below. 359 TSN-aware IP DetNet nodes are member 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 case 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 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 444 Bryant, "Deterministic Networking (DetNet) Data Plane: 445 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 446 . 448 9.2. Informative references 450 [I-D.ietf-detnet-security] 451 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 452 Networking (DetNet) Security Considerations", draft-ietf- 453 detnet-security-12 (work in progress), October 2020. 455 [IEEE802.1AE-2018] 456 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 457 Security (MACsec)", 2018, 458 . 460 [IEEE8021CB] 461 IEEE 802.1, "Standard for Local and metropolitan area 462 networks - Frame Replication and Elimination for 463 Reliability (IEEE Std 802.1CB-2017)", 2017, 464 . 466 [IEEE8021Q] 467 IEEE 802.1, "Standard for Local and metropolitan area 468 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 469 2018)", 2018, . 471 [IEEEP8021CBcv] 472 Kehrer, S., "FRER YANG Data Model and Management 473 Information Base Module", IEEE P802.1CBcv 474 /D0.4 P802.1CBcv, August 2020, 475 . 478 [IEEEP8021CBdb] 479 Mangin, C., "Extended Stream identification functions", 480 IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020, 481 . 484 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 485 "Deterministic Networking Architecture", RFC 8655, 486 DOI 10.17487/RFC8655, October 2019, 487 . 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