idnits 2.17.1 draft-ietf-detnet-ip-over-tsn-02.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 (March 6, 2020) is 1510 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Network' is mentioned on line 170, but not defined == Unused Reference: 'I-D.ietf-detnet-flow-information-model' is defined on line 453, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-05 == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-07 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-08 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: Standards Track Ericsson 5 Expires: September 7, 2020 A. Malis 6 Independent 7 S. Bryant 8 Futurewei Technologies 9 March 6, 2020 11 DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN) 12 draft-ietf-detnet-ip-over-tsn-02 14 Abstract 16 This document specifies the Deterministic Networking IP data plane 17 when operating over a TSN sub-network. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 7, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 56 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 3 59 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network . . . . 5 60 4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 6 61 4.2. TSN requirements of IP DetNet nodes . . . . . . . . . . . 6 62 4.3. Service protection within the TSN sub-network . . . . . . 8 63 4.4. Aggregation during DetNet flow to TSN Stream mapping . . 8 64 5. Management and Control Implications . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Normative references . . . . . . . . . . . . . . . . . . 10 70 9.2. Informative references . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 Deterministic Networking (DetNet) is a service that can be offered by 76 a network to DetNet flows. DetNet provides these flows extremely low 77 packet loss rates and assured maximum end-to-end delivery latency. 78 General background and concepts of DetNet can be found in the DetNet 79 Architecture [RFC8655]. 81 [I-D.ietf-detnet-ip] specifies the DetNet data plane operation for IP 82 hosts and routers that provide DetNet service to IP encapsulated 83 data. This document focuses on the scenario where DetNet IP nodes 84 are interconnected by a TSN sub-network. 86 The DetNet Architecture decomposes the DetNet related data plane 87 functions into two sub-layers: a service sub-layer and a forwarding 88 sub-layer. The service sub-layer is used to provide DetNet service 89 protection and reordering. The forwarding sub-layer is used to 90 provides congestion protection (low loss, assured latency, and 91 limited reordering). As described in [I-D.ietf-detnet-ip] no DetNet 92 specific headers are added to support DetNet IP flows, only the 93 forwarding sub-layer functions are supported inside the DetNet 94 domain. Service protection can be provided on a per sub-network 95 basis as shown here for the IEEE802.1 TSN sub-network scenario. 97 2. Terminology 99 2.1. Terms Used In This Document 101 This document uses the terminology and concepts established in the 102 DetNet architecture [RFC8655], and the reader is assumed to be 103 familiar with that document and its terminology. 105 2.2. Abbreviations 107 The following abbreviations used in this document: 109 DetNet Deterministic Networking. 111 DF DetNet Flow. 113 FRER Frame Replication and Elimination for Redundancy (TSN 114 function). 116 L2 Layer-2. 118 L3 Layer-3. 120 PREOF Packet Replication, Ordering and Elimination Function. 122 TSN Time-Sensitive Networking, TSN is a Task Group of the 123 IEEE 802.1 Working Group. 125 2.3. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. DetNet IP Data Plane Overview 135 [I-D.ietf-detnet-ip] describes how IP is used by DetNet nodes, i.e., 136 hosts and routers, to identify DetNet flows and provide a DetNet 137 service. From a data plane perspective, an end-to-end IP model is 138 followed. DetNet uses "6-tuple" based flow identification, where 139 "6-tuple" refers to information carried in IP and higher layer 140 protocol headers. 142 DetNet flow aggregation may be enabled via the use of wildcards, 143 masks, prefixes and ranges. IP tunnels may also be used to support 144 flow aggregation. In these cases, it is expected that DetNet aware 145 intermediate nodes will provide DetNet service assurance on the 146 aggregate through resource allocation and congestion control 147 mechanisms. 149 Congestion protection, latency control and the resource allocation 150 (queuing, policing, shaping) are supported using the underlying link 151 / sub-net specific mechanisms. Service protections (packet 152 replication and packet elimination functions) are not provided at the 153 DetNet layer end to end due the lack of a unified end to end 154 sequencing information that would be available for intermediate 155 nodes. However, such service protection can be provided on a per 156 underlying L2 link and sub-network basis. 158 Edge Transit Relay 159 Node Node Node 161 +.........+ 162 <--:Svc Proxy:-- End to End Service -----------> 163 +-----....+ +..........+ 164 |IP | :Svc:<-- DetNet flow ---: Service :---> 165 +---+ +---+ +---------+ +---------+ 166 |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| 167 +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ 168 : / ,-----. \ : Link : : 169 .....+ +-[TSN Sub]-+ +........+ +..... 170 [Network] 171 `-----' 172 <------------- DetNet IP ------------- 174 Figure 1: Part of a Simple DetNet (DN) Enabled IP Network using a TSN 175 sub-net 177 Figure 1 illustrates an extract of a DetNet enabled IP network, that 178 uses a TSN sub-network as interconnection between two DetNet Nodes. 179 In this figure, an Edge Node sits at the boundary of the DetNet 180 domain and provide DetNet service proxies for the end applications by 181 initiating and terminating DetNet service for the application's IP 182 flows. Node and interface resources are allocated to ensure DetNet 183 service requirements. Dotted lines around the Service components of 184 the Edge and Relay Nodes indicate that they are DetNet service aware 185 but do not perform any DetNet service sub-layer function, e.g., PREOF 186 (Packet Replication, Elimination, and Ordering Functions). In this 187 example the Edge Node and the Transit Node are interconnected by a 188 TSN sub-network, being the primary focus of this document. 190 DetNet routers ensure that detnet service requirements are met per 191 hop by allocating local resources, both receive and transmit, and by 192 mapping the service requirements of each flow to appropriate sub- 193 network mechanisms. Such mappings are sub-network technology 194 specific. The mapping of DetNet IP flows to TSN streams and TSN 195 protection mechanisms are covered in Section 4. 197 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network 199 This section covers how DetNet IP flows operate over an IEEE 802.1 200 TSN sub-network. Figure 2 illustrates such a scenario, where two IP 201 (DetNet) nodes are interconnected by a TSN sub-network. Node-1 is 202 single homed and Node-2 is dual-homed to the TSN sub-network. 204 IP (DetNet) IP (DetNet) 205 Node-1 Node-2 207 ............ ............ 208 <--: Service :-- DetNet flow ---: Service :--> 209 +----------+ +----------+ 210 |Forwarding| |Forwarding| 211 +--------.-+ <-TSN Str-> +-.-----.--+ 212 \ ,-------. / / 213 +----[ TSN-Sub ]---+ / 214 [ Network ]--------+ 215 `-------' 216 <----------------- DetNet IP -----------------> 218 Figure 2: DetNet (DN) Enabled IP Network over a TSN sub-network 220 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 221 Working Group have defined (and are defining) a number of amendments 222 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 223 bounded latency in bridged networks. Furthermore IEEE 802.1CB 224 [IEEE8021CB] defines frame replication and elimination functions for 225 reliability that should prove both compatible with and useful to 226 DetNet networks. All these functions have to identify flows that 227 require TSN treatment. 229 TSN capabilities of the TSN sub-network are made available for IP 230 (DetNet) flows via the protocol interworking function defined in IEEE 231 802.1CB [IEEE8021CB]. For example, applied on the TSN edge port it 232 can convert an ingress unicast IP (DetNet) flow to use a specific 233 Layer-2 multicast destination MAC address and a VLAN, in order to 234 direct the packet through a specific path inside the bridged network. 235 A similar interworking function pair at the other end of the TSN sub- 236 network would restore the packet to its original Layer-2 destination 237 MAC address and VLAN. 239 Placement of TSN functions depends on the TSN capabilities of nodes. 240 IP (DetNet) Nodes may or may not support TSN functions. For a given 241 TSN Stream (i.e., DetNet flow) an IP (DetNet) node is treated as a 242 Talker or a Listener inside the TSN sub-network. 244 4.1. Functions for DetNet Flow to TSN Stream Mapping 246 Mapping of a DetNet IP flow to a TSN Stream is provided via the 247 combination of a passive and an active stream identification function 248 that operate at the frame level. The passive stream identification 249 function is used to catch the 6-tuple of a DetNet IP flow and the 250 active stream identification function is used to modify the Ethernet 251 header according to ID of the mapped TSN Stream. 253 IEEE 802.1CB [IEEE8021CB] defines an IP Stream identification 254 function that can be used as a passive function for IP DetNet flows 255 using UDP or TCP. IEEE P802.1CBdb [IEEEP8021CBdb] defines a Mask- 256 and-Match Stream identification function that can be used as a 257 passive function for any IP DetNet flows. 259 IEEE 802.1CB [IEEE8021CB] defines an Active Destination MAC and VLAN 260 Stream identification function, what can replace some Ethernet header 261 fields namely (1) the destination MAC-address, (2) the VLAN-ID and 262 (3) priority parameters with alternate values. Replacement is 263 provided for the frame passed down the stack from the upper layers or 264 up the stack from the lower layers. 266 Active Destination MAC and VLAN Stream identification can be used 267 within a Talker to set flow identity or a Listener to recover the 268 original addressing information. It can be used also in a TSN bridge 269 that is providing translation as a proxy service for an End System. 271 4.2. TSN requirements of IP DetNet nodes 273 This section covers required behavior of a TSN-aware DetNet node 274 using a TSN sub-network. 276 From the TSN sub-network perspective DetNet IP nodes are treated as 277 Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. 279 In cases of TSN-unaware IP DetNet nodes the TSN relay nodes within 280 the TSN sub-network must modify the Ethernet encapsulation of the 281 DetNet IP flow (e.g., MAC translation, VLAN-ID setting, Sequence 282 number addition, etc.) to allow proper TSN specific handling inside 283 the sub-network. There are no requirements defined for TSN-unaware 284 IP DetNet nodes in this document. 286 IP (DetNet) nodes being TSN-aware can be treated as a combination of 287 a TSN-unaware Talker/Listener and a TSN-Relay, as shown in Figure 3. 288 In such cases the IP (DetNet) node must provide the TSN sub-network 289 specific Ethernet encapsulation over the link(s) towards the sub- 290 network. 292 IP (DetNet) 293 Node 294 <----------------------------------> 296 ............ 297 <--: Service :-- DetNet flow ------------------ 298 +----------+ 299 |Forwarding| 300 +----------+ +---------------+ 301 | L2 | | L2 Relay with |<--- TSN --- 302 | | | TSN function | Stream 303 +-----.----+ +--.------.---.-+ 304 \__________/ \ \______ 305 \_________ 306 TSN-unaware 307 Talker / TSN-Bridge 308 Listener Relay 309 <----- TSN Sub-network ----- 310 <------- TSN-aware Tlk/Lstn -------> 312 Figure 3: IP (DetNet) node with TSN functions 314 A TSN-aware IP (DetNet) node impementations MUST support the Stream 315 Identification TSN component for recognizing flows. 317 A Stream identification component MUST be able to instantiate the 318 following functions (1) Active Destination MAC and VLAN Stream 319 identification function, (2) IP Stream identification function, (3) 320 Mask-and-Match Stream identification function and (4) the related 321 managed objects in Clause 9 of IEEE 802.1CB [IEEE8021CB] and IEEE 322 P802.1CBdb [IEEEP8021CBdb]. 324 A TSN-aware IP (DetNet) node implementations MUST support the 325 Sequencing function and the Sequence encode/decode function as 326 defined in IEEE 802.1CB [IEEE8021CB] if FRER is used inside the TSN 327 sub-network. 329 The Sequence encode/decode function MUST support the Redundancy tag 330 (R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB]. 332 A TSN-aware IP (DetNet) node implementations MUST support the Stream 333 splitting function and the Individual recovery function as defined in 334 IEEE 802.1CB [IEEE8021CB] when the node is a replication or 335 elimination point for FRER. 337 4.3. Service protection within the TSN sub-network 339 TSN Streams supporting DetNet flows may use Frame Replication and 340 Elimination for Redundancy (FRER) as defined in IEEE 802.1CB 341 [IEEE8021CB] based on the loss service requirements of the TSN 342 Stream, which is derived from the DetNet service requirements of the 343 DetNet mapped flow. The specific operation of FRER is not modified 344 by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB]. 346 FRER function and the provided service recovery is available only 347 within the TSN sub-network as the TSN Stream-ID and the TSN sequence 348 number are not valid outside the sub-network. An IP (DetNet) node 349 represents a L3 border and as such it terminates all related 350 information elements encoded in the L2 frames. 352 4.4. Aggregation during DetNet flow to TSN Stream mapping 354 Implementations of this document SHALL use management and control 355 information to map a DetNet flow to a TSN Stream. N:1 mapping 356 (aggregating DetNet flows in a single TSN Stream) SHALL be supported. 357 The management or control function that provisions flow mapping SHALL 358 ensure that adequate resources are allocated and configured to 359 provide proper service requirements of the mapped flows. 361 5. Management and Control Implications 363 DetNet flow and TSN Stream mapping related information are required 364 only for TSN-aware IP (DetNet) nodes. From the Data Plane 365 perspective there is no practical difference based on the origin of 366 flow mapping related information (management plane or control plane). 368 TSN-aware IP DetNet nodes are member of both the DetNet domain and 369 the TSN sub-network. Within the TSN sub-network the TSN-aware IP 370 (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific 371 management and control plane functionalities must be implemented. 372 There are many similarities in the management plane techniques used 373 in DetNet and TSN, but that is not the case for the control plane 374 protocols. For example, RSVP-TE and MSRP behaves differently. 375 Therefore management and control plane design is an important aspect 376 of scenarios, where mapping between DetNet and TSN is required. 378 In order to use a TSN sub-network between DetNet nodes, DetNet 379 specific information must be converted to TSN sub-network specific 380 ones. DetNet flow ID and flow related parameters/requirements must 381 be converted to a TSN Stream ID and stream related parameters/ 382 requirements. Note that, as the TSN sub-network is just a portion of 383 the end2end DetNet path (i.e., single hop from IP perspective), some 384 parameters (e.g., delay) may differ significantly. Other parameters 385 (like bandwidth) also may have to be tuned due to the L2 386 encapsulation used within the TSN sub-network. 388 In some case it may be challenging to determine some TSN Stream 389 related information. For example, on a TSN-aware IP (DetNet) node 390 that acts as a Talker, it is quite obvious which DetNet node is the 391 Listener of the mapped TSN stream (i.e., the IP Next-Hop). However 392 it may be not trivial to locate the point/interface where that 393 Listener is connected to the TSN sub-network. Such attributes may 394 require interaction between control and management plane functions 395 and between DetNet and TSN domains. 397 Mapping between DetNet flow identifiers and TSN Stream identifiers, 398 if not provided explicitly, can be done by a TSN-aware IP (DetNet) 399 node locally based on information provided for configuration of the 400 TSN Stream identification functions (IP Stream identification, Mask- 401 and-match Stream identification and active Stream identification 402 function). 404 Triggering the setup/modification of a TSN Stream in the TSN sub- 405 network is an example where management and/or control plane 406 interactions are required between the DetNet and TSN sub-network. 407 TSN-unaware IP (DetNet) nodes make such a triggering even more 408 complicated as they are fully unaware of the sub-network and run 409 independently. 411 Configuration of TSN specific functions (e.g., FRER) inside the TSN 412 sub-network is a TSN domain specific decision and may not be visible 413 in the DetNet domain. 415 6. Security Considerations 417 The security considerations of DetNet in general are discussed in 418 [RFC8655] and [I-D.ietf-detnet-security]. DetNet IP data plane 419 specific considerations are summarized in [I-D.ietf-detnet-ip]. 420 Encryption may provided by an underlying sub-net using MACSec 421 [IEEE802.1AE-2018] for DetNet IP over TSN flows. 423 7. IANA Considerations 425 None. 427 8. Acknowledgements 429 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, 430 Christophe Mangin and Jouni Korhonen for their various contributions 431 to this work. 433 9. References 435 9.1. Normative references 437 [I-D.ietf-detnet-ip] 438 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 439 and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet- 440 ip-05 (work in progress), February 2020. 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, 444 DOI 10.17487/RFC2119, March 1997, 445 . 447 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 448 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 449 May 2017, . 451 9.2. Informative references 453 [I-D.ietf-detnet-flow-information-model] 454 Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D. 455 Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- 456 flow-information-model-07 (work in progress), March 2020. 458 [I-D.ietf-detnet-security] 459 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 460 J., Austad, H., and N. Finn, "Deterministic Networking 461 (DetNet) Security Considerations", draft-ietf-detnet- 462 security-08 (work in progress), February 2020. 464 [IEEE802.1AE-2018] 465 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 466 Security (MACsec)", 2018, 467 . 469 [IEEE8021CB] 470 Finn, N., "Draft Standard for Local and metropolitan area 471 networks - Seamless Redundancy", IEEE P802.1CB 472 /D2.1 P802.1CB, December 2015, 473 . 476 [IEEE8021Q] 477 IEEE 802.1, "Standard for Local and metropolitan area 478 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 479 2014)", 2014, . 481 [IEEEP8021CBdb] 482 Mangin, C., "Extended Stream identification functions", 483 IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019, 484 . 487 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 488 "Deterministic Networking Architecture", RFC 8655, 489 DOI 10.17487/RFC8655, October 2019, 490 . 492 Authors' Addresses 494 Balazs Varga (editor) 495 Ericsson 496 Magyar Tudosok krt. 11. 497 Budapest 1117 498 Hungary 500 Email: balazs.a.varga@ericsson.com 502 Janos Farkas 503 Ericsson 504 Magyar Tudosok krt. 11. 505 Budapest 1117 506 Hungary 508 Email: janos.farkas@ericsson.com 510 Andrew G. Malis 511 Independent 513 Email: agmalis@gmail.com 515 Stewart Bryant 516 Futurewei Technologies 518 Email: stewart.bryant@gmail.com