idnits 2.17.1 draft-ietf-detnet-ip-over-tsn-00.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 (May 5, 2019) is 1819 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 269, but not defined == Unused Reference: 'RFC0768' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'RFC1812' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC2211' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'RFC2212' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 732, but no explicit reference was found in the text == Unused Reference: 'RFC3270' is defined on line 737, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'RFC4302' is defined on line 749, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'RFC6003' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC7608' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'G.8275.1' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'G.8275.2' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-detnet-flow-information-model' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-pce-native-ip' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'IEEE1588' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 844, but no explicit reference was found in the text == Unused Reference: 'RFC2386' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'RFC5575' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC5654' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'RFC5777' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'RFC7551' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC8040' is defined on line 893, but no explicit reference was found in the text == Unused Reference: 'RFC8169' is defined on line 897, but no explicit reference was found in the text == Unused Reference: 'RFC8283' is defined on line 902, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-12 == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-03 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-04 == Outdated reference: A later version (-17) exists of draft-ietf-teas-pce-native-ip-03 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 1 error (**), 0 flaws (~~), 40 warnings (==), 3 comments (--). 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: November 6, 2019 A. Malis 6 S. Bryant 7 Huawei Technologies 8 J. Korhonen 9 May 5, 2019 11 DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN) 12 draft-ietf-detnet-ip-over-tsn-00 14 Abstract 16 This document specifies the Deterministic Networking IP data plane 17 when operating over a TSN 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 November 6, 2019. 36 Copyright Notice 38 Copyright (c) 2019 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 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 58 4. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 59 5. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 7 60 5.1. DetNet Routers . . . . . . . . . . . . . . . . . . . . . 8 61 5.2. Networks With Multiple Technology Segments . . . . . . . 9 62 6. Mapping DetNet IP Flows to IEEE 802.1 TSN . . . . . . . . . . 10 63 6.1. TSN Stream ID Mapping . . . . . . . . . . . . . . . . . . 11 64 6.2. TSN Usage of FRER . . . . . . . . . . . . . . . . . . . . 13 65 6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 14 66 7. Management and Control Implications . . . . . . . . . . . . . 14 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 11.1. Normative references . . . . . . . . . . . . . . . . . . 16 72 11.2. Informative references . . . . . . . . . . . . . . . . . 18 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 75 1. Introduction 77 [Editor's note: Introduction to be made specific to DetNet IP over 78 TSN scenario. May be similar to intro of DetNet MPLS over TSN.]. 80 Deterministic Networking (DetNet) is a service that can be offered by 81 a network to DetNet flows. DetNet provides these flows extremely low 82 packet loss rates and assured maximum end-to-end delivery latency. 83 General background and concepts of DetNet can be found in the DetNet 84 Architecture [I-D.ietf-detnet-architecture]. 86 This document specifies the DetNet data plane operation for IP hosts 87 and routers that provide DetNet service to IP encapsulated data. No 88 DetNet specific encapsulation is defined to support IP flows, rather 89 existing IP and higher layer protocol header information is used to 90 support flow identification and DetNet service delivery. 92 The DetNet Architecture decomposes the DetNet related data plane 93 functions into two sub-layers: a service sub-layer and a forwarding 94 sub-layer. The service sub-layer is used to provide DetNet service 95 protection and reordering. The forwarding sub-layer is used to 96 provides congestion protection (low loss, assured latency, and 97 limited reordering). As no DetNet specific headers are added to 98 support DetNet IP flows, only the forwarding sub-layer functions are 99 supported using the DetNet IP defined by this document. Service 100 protection can be provided on a per sub-net basis using technologies 101 such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and IEEE802.1 TSN. 103 2. Terminology 105 [Editor's note: Needs clean up.]. 107 2.1. Terms Used In This Document 109 This document uses the terminology and concepts established in the 110 DetNet architecture [I-D.ietf-detnet-architecture], and the reader is 111 assumed to be familiar with that document and its terminology. 113 2.2. Abbreviations 115 The following abbreviations used in this document: 117 CE Customer Edge equipment. 119 CoS Class of Service. 121 DetNet Deterministic Networking. 123 DF DetNet Flow. 125 L2 Layer-2. 127 L3 Layer-3. 129 LSP Label-switched path. 131 MPLS Multiprotocol Label Switching. 133 OAM Operations, Administration, and Maintenance. 135 PE Provider Edge. 137 PREOF Packet Replication, Ordering and Elimination Function. 139 PSN Packet Switched Network. 141 PW Pseudowire. 143 QoS Quality of Service. 145 TE Traffic Engineering. 147 TSN Time-Sensitive Networking, TSN is a Task Group of the 148 IEEE 802.1 Working Group. 150 3. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 4. DetNet IP Data Plane Overview 160 [Editor's note: simplify this section and highlight DetNet IP over 161 subnets scenario being the focus in the remaining part of the 162 document.]. 164 This document describes how IP is used by DetNet nodes, i.e., hosts 165 and routers, to identify DetNet flows and provide a DetNet service. 166 From a data plane perspective, an end-to-end IP model is followed. 167 As mentioned above, existing IP and higher layer protocol header 168 information is used to support flow identification and DetNet service 169 delivery. 171 DetNet uses "6-tuple" based flow identification, where "6-tuple" 172 refers to information carried in IP and higher layer protocol 173 headers. General background on the use of IP headers, and 174 "5-tuples", to identify flows and support Quality of Service (QoS) 175 can be found in [RFC3670]. [RFC7657] also provides useful background 176 on the delivery differentiated services (DiffServ) and "6-tuple" 177 based flow identification. 179 DetNet flow aggregation may be enabled via the use of wildcards, 180 masks, prefixes and ranges. IP tunnels may also be used to support 181 flow aggregation. In these cases, it is expected that DetNet aware 182 intermediate nodes will provide DetNet service assurance on the 183 aggregate through resource allocation and congestion control 184 mechanisms. 186 DetNet IP Relay Relay DetNet IP 187 End System Node Node End System 189 +----------+ +----------+ 190 | Appl. |<------------ End to End Service ----------->| Appl. | 191 +----------+ ............ ........... +----------+ 192 | Service |<-: Service :-- DetNet flow --: Service :->| Service | 193 +----------+ +----------+ +----------+ +----------+ 194 |Forwarding| |Forwarding| |Forwarding| |Forwarding| 195 +--------.-+ +-.------.-+ +-.---.----+ +-------.--+ 196 : Link : \ ,-----. / \ ,-----. / 197 +......+ +----[ Sub ]----+ +-[ Sub ]-+ 198 [Network] [Network] 199 `-----' `-----' 201 |<--------------------- DetNet IP --------------------->| 203 Figure 1: A Simple DetNet (DN) Enabled IP Network 205 Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled 206 end systems originate IP encapsulated traffic that is identified as 207 DetNet flows, relay nodes understand the forwarding requirements of 208 the DetNet flow and ensure that node, interface and sub-network 209 resources are allocated to ensure DetNet service requirements. The 210 dotted line around the Service component of the Relay Nodes indicates 211 that the transit routers are DetNet service aware but do not perform 212 any DetNet service sub-layer function, e.g., PREOF. IEEE 802.1 TSN 213 is an example sub-network type which can provide support for DetNet 214 flows and service. The mapping of DetNet IP flows to TSN streams and 215 TSN protection mechanisms is covered in Section 6. 217 Note: The sub-network can represent a TSN, MPLS or IP network 218 segment. 220 DetNet IP Relay Transit Relay DetNet IP 221 End System Node Node Node End System 223 +----------+ +----------+ 224 | Appl. |<-------------- End to End Service ---------->| Appl. | 225 +----------+ .....-----+ +-----..... +----------+ 226 | Service |<--: Service |-- DetNet flow ---| Service :-->| Service | 227 | | : |<- DN MPLS flow ->| : | | 228 +----------+ +---------+ +----------+ +---------+ +----------+ 229 |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| 230 +--------.-+ +-.-+ +-.-+ +---.----.-+ +-.-+ +-.-+ +----.-----+ 231 : Link : / ,-----. \ : Link : / ,-----. \ 232 +.......+ +-[ Sub ]-+ +.......+ +--[ Sub ]--+ 233 [Network] [Network] 234 `-----' `-----' 236 |<---- DetNet MPLS --->| 237 |<--------------------- DetNet IP ------------------->| 239 Figure 2: DetNet IP Over DetNet MPLS Network 241 Figure 2 illustrates a variant of Figure 1, with an MPLS based DetNet 242 network as a sub-network between the relay nodes. It shows a more 243 complex DetNet enabled IP network where an IP flow is mapped to one 244 or more PWs and MPLS (TE) LSPs. The end systems still originate IP 245 encapsulated traffic that is identified as DetNet flows. The relay 246 nodes follow procedures defined in RRR to map each DetNet flow to 247 MPLS LSPs. While not shown, relay nodes can provide service sub- 248 layer functions such as PREOF using DetNet over MPLS, and this is 249 indicated by the solid line for the MPLS facing portion of the 250 Service component. Note that the Transit node is MPLS (TE) LSP aware 251 and performs switching based on MPLS labels, and need not have any 252 specific knowledge of the DetNet service or the corresponding DetNet 253 flow identification. See RRR for details on the mapping of IP flows 254 to MPLS, and [I-D.ietf-detnet-dp-sol-mpls] for general support of 255 DetNet services using MPLS. 257 IP Edge Edge IP 258 End System Node Node End System 260 +----------+ +.........+ +.........+ +----------+ 261 | Appl. |<--:Svc Proxy:-- E2E Service ---:Svc Proxy:-->| Appl. | 262 +----------+ +.........+ +.........+ +----------+ 263 | IP |<--:IP : :Svc:----- IP flow ----:Svc: :IP :-->| IP | 264 +----------+ +---+ +---+ +---+ +---+ +----------+ 265 |Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding| 266 +--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ 267 : Link : \ ,-----. / / ,-----. \ 268 +.......+ +-----[ Sub ]----+ +--[ Sub ]--+ 269 [Network] [Network] 270 `-----' `-----' 272 |<--- IP --->| |<------ DetNet IP ------->| |<--- IP --->| 274 Figure 3: Non-DetNet aware IP end systems with DetNet IP Domain 276 Figure 3 illustrates another variant of Figure 1 where the end 277 systems are not DetNet aware. In this case, edge nodes sit at the 278 boundary of the DetNet domain and provide DetNet service proxies for 279 the end applications by initiating and terminating DetNet service for 280 the application's IP flows. The existing header information or an 281 approach used for aggregation can be used to support DetNet flow 282 identification. 284 Non-DetNet and DetNet IP packets are identical on the wire. From 285 data plane perspective, the only difference is that there is flow- 286 associated DetNet information on each DetNet node that defines the 287 flow related characteristics and required forwarding behavior. As 288 shown above, edge nodes provide a Service Proxy function that 289 "associates" one or more IP flows with the appropriate DetNet flow- 290 specific information and ensures that the receives the proper traffic 291 treatment within the domain. 293 Note: The operation of IEEE802.1 TSN end systems over DetNet enabled 294 IP networks is not described in this document. While TSN flows could 295 be encapsulated in IP packets by an IP End System or DetNet Edge Node 296 in order to produce DetNet IP flows, the details of such are out of 297 scope of this document. 299 5. DetNet IP Data Plane Considerations 301 [Editor's note: Sort out what data plane considerations are relevant 302 for sub-net scenarios.]. 304 5.1. DetNet Routers 306 Within a DetNet domain, the DetNet enabled IP Routers interconnect 307 links and sub-networks to support end-to-end delivery of DetNet 308 flows. From a DetNet architecture perspective, these routers are 309 DetNet relays, as they must be DetNet service aware. Such routers 310 identify DetNet flows based on the IP 6-tuple, and ensure that the 311 DetNet service required traffic treatment is provided both on the 312 node and on any attached sub-network. 314 This solution provides DetNet functions end to end, but does so on a 315 per link and sub-network basis. Congestion protection and latency 316 control and the resource allocation (queuing, policing, shaping) are 317 supported using the underlying link / sub net specific mechanisms. 318 However, service protections (packet replication and packet 319 elimination functions) are not provided at the DetNet layer end to 320 end. But such service protection can be provided on a per underlying 321 L2 link and sub-network basis. 323 +------+ +------+ 324 | X | | X | 325 +======+ +------+ 326 End-system | IP | | IP | 327 -----+------+-------+======+--- --+======+-- 328 DetNet |L2/SbN| |L2/SbN| 329 +------+ +------+ 331 Figure 4: Encapsulation of DetNet Routing in simplified IP service L3 332 end-systems 334 The DetNet Service Flow is mapped to the link / sub-network specific 335 resources using an underlying system specific means. This implies 336 each DetNet aware node on path looks into the forwarded DetNet 337 Service Flow packet and utilize e.g., a 5- (or 6-) tuple to find out 338 the required mapping within a node. 340 As noted earlier, the Service Protection is done within each link / 341 sub-network independently using the domain specific mechanisms (due 342 the lack of a unified end to end sequencing information that would be 343 available for intermediate nodes). Therefore, service protection (if 344 any) cannot be provided end-to-end, only within sub-networks. This 345 is shown for a three sub-network scenario in Figure 5, where each 346 sub-network can provide service protection between its borders. 348 ______ 349 ____ / \__ 350 ____ / \__/ \___ ______ 351 +----+ __/ +====+ +==+ \ +----+ 352 |src |__/ SubN1 ) | | \ SubN3 \____| dst| 353 +----+ \_______/ \ Sub-Network2 | \______/ +----+ 354 \_ _/ 355 \ __ __/ 356 \_______/ \___/ 358 +---+ +---------E--------+ +-----+ 359 +----+ | | | | | | | +----+ 360 |src |----R E--------R +---+ E------R E------+ dst| 361 +----+ | | | | | | | +----+ 362 +---+ +-----R------------+ +-----+ 364 Figure 5: Replication and elimination in sub-networks for DetNet IP 365 networks 367 If end to end service protection is desired that can be implemented, 368 for example, by the DetNet end systems using Layer-4 (L4) transport 369 protocols or application protocols. However, these are out of scope 370 of this document. 372 5.2. Networks With Multiple Technology Segments 374 There are network scenarios, where the DetNet domain contains 375 multiple technology segments (IEEE 802.1 TSN, MPLS) and all those 376 segments are under the same administrative control (see Figure 6). 377 Furthermore, DetNet nodes may be interconnected via TSN segments. 379 DetNet routers ensure that detnet service requirements are met per 380 hop by allocating local resources, both receive and transmit, and by 381 mapping the service requirements of each flow to appropriate sub- 382 network mechanisms. Such mapping is sub-network technology specific. 383 The mapping of DetNet IP Flows to MPLS is covered RRR . The mapping 384 of IP DetNet Flows to IEEE 802.1 TSN is covered in Section 6. 386 ______ 387 _____ / \__ 388 ____ / \__/ \___ ______ 389 +----+ __/ +======+ +==+ \ +----+ 390 |src |__/ Seg1 ) | | \ Seg3 \__| dst| 391 +----+ \_______+ \ Segment-2 | \+_____/ +----+ 392 \======+__ _+===/ 393 \ __ __/ 394 \_______/ \___/ 396 Figure 6: DetNet domains and multiple technology segments 398 6. Mapping DetNet IP Flows to IEEE 802.1 TSN 400 [Authors note: how do we handle control protocols such as ICMP, 401 IPsec, etc.] 403 This section covers how DetNet IP flows operate over an IEEE 802.1 404 TSN sub-network. Figure 7 illustrates such a scenario, where two IP 405 (DetNet) nodes are interconnected by a TSN sub-network. Node-1 is 406 single homed and Node-2 is dual-homed. IP nodes can be (1) DetNet IP 407 End System, (2) DetNet IP Edge or Relay node or (3) IP End System. 409 IP (DetNet) IP (DetNet) 410 Node-1 Node-2 412 ............ ............ 413 <--: Service :-- DetNet flow ---: Service :--> 414 +----------+ +----------+ 415 |Forwarding| |Forwarding| 416 +--------.-+ <-TSN Str-> +-.-----.--+ 417 \ ,-------. / / 418 +----[ TSN-Sub ]---+ / 419 [ Network ]--------+ 420 `-------' 421 <----------------- DetNet IP -----------------> 423 Figure 7: DetNet (DN) Enabled IP Network over a TSN sub-network 425 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 426 Working Group have defined (and are defining) a number of amendments 427 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 428 bounded latency in bridged networks. Furthermore IEEE 802.1CB 429 [IEEE8021CB] defines frame replication and elimination functions for 430 reliability that should prove both compatible with and useful to, 431 DetNet networks. All these functions have to identify flows those 432 require TSN treatment. 434 As is the case for DetNet, a Layer 2 network node such as a bridge 435 may need to identify the specific DetNet flow to which a packet 436 belongs in order to provide the TSN/DetNet QoS for that packet. It 437 also may need additional marking, such as the priority field of an 438 IEEE Std 802.1Q VLAN tag, to give the packet proper service. 440 TSN capabilities of the TSN sub-network are made available for IP 441 (DetNet) flows via the protocol interworking function defined in IEEE 442 802.1CB [IEEE8021CB]. For example, applied on the TSN edge port 443 connected to the IP (DetNet) node it can convert an ingress unicast 444 IP (DetNet) flow to use a specific multicast destination MAC address 445 and VLAN, in order to direct the packet through a specific path 446 inside the bridged network. A similar interworking pair at the other 447 end of the TSN sub-network would restore the packet to its original 448 destination MAC address and VLAN. 450 Placement of TSN functions depends on the TSN capabilities of nodes. 451 IP (DetNet) Nodes may or may not support TSN functions. For a given 452 TSN Stream (i.e., DetNet flow) an IP (DetNet) node is treated as a 453 Talker or a Listener inside the TSN sub-network. 455 6.1. TSN Stream ID Mapping 457 DetNet IP Flow and TSN Stream mapping is based on the active Stream 458 Identification function, that operates at the frame level. IEEE 459 802.1CB [IEEE8021CB] defines an Active Destination MAC and VLAN 460 Stream identification function, what can replace some Ethernet header 461 fields namely (1) the destination MAC-address, (2) the VLAN-ID and 462 (3) priority parameters with alternate values. Replacement is 463 provided for the frame passed down the stack from the upper layers or 464 up the stack from the lower layers. 466 Active Destination MAC and VLAN Stream identification can be used 467 within a Talker to set flow identity or a Listener to recover the 468 original addressing information. It can be used also in a TSN bridge 469 that is providing translation as a proxy service for an End System. 470 As a result IP (DetNet) flows can be mapped to use a particular {MAC- 471 address, VLAN} pair to match the Stream in the TSN sub-network. 473 From the TSN sub-network perspective DetNet IP nodes without any TSN 474 functions can be treated as TSN-unaware Talker or Listener. In such 475 cases relay nodes in the TSN sub-network MUST modify the Ethernet 476 encapsulation of the DetNet IP flow (e.g., MAC translation, VLAN-ID 477 setting, Sequence number addition, etc.) to allow proper TSN specific 478 handling of the flow inside the sub-network. This is illustrated in 479 Figure 8. 481 IP (DetNet) 482 Node-1 483 <----------> 485 ............ 486 <--: Service :-- DetNet flow ------------------ 487 +----------+ 488 |Forwarding| 489 +----------+ +---------------+ 490 | L2 | | L2 Relay with |<--- TSN ---- 491 | | | TSN function | Stream 492 +-----.----+ +--.---------.--+ 493 \__________/ \______ 495 TSN-unaware 496 Talker / TSN-Bridge 497 Listener Relay 498 <-------- TSN sub-network ------- 500 Figure 8: IP (DetNet) node without TSN functions 502 IP (DetNet) nodes being TSN-aware can be treated as a combination of 503 a TSN-unaware Talker/Listener and a TSN-Relay, as shown in Figure 9. 504 In such cases the IP (DetNet) node MUST provide the TSN sub-network 505 specific Ethernet encapsulation over the link(s) towards the sub- 506 network. An TSN-aware IP (DetNet) node MUST support the following 507 TSN components: 509 1. For recognizing flows: 511 * Stream Identification 513 2. For FRER used inside the TSN domain, additionally: 515 * Sequencing function 517 * Sequence encode/decode function 519 3. For FRER when the node is a replication or elimination point, 520 additionally: 522 * Stream splitting function 524 * Individual recovery function 526 [Editor's note: Should we added here requirements regarding IEEE 527 802.1Q C-VLAN component?] 528 IP (DetNet) 529 Node-2 530 <----------------------------------> 532 ............ 533 <--: Service :-- DetNet flow ------------------ 534 +----------+ 535 |Forwarding| 536 +----------+ +---------------+ 537 | L2 | | L2 Relay with |<--- TSN --- 538 | | | TSN function | Stream 539 +-----.----+ +--.------.---.-+ 540 \__________/ \ \______ 541 \_________ 542 TSN-unaware 543 Talker / TSN-Bridge 544 Listener Relay 545 <----- TSN Sub-network ----- 546 <------- TSN-aware Tlk/Lstn -------> 548 Figure 9: IP (DetNet) node with TSN functions 550 A Stream identification component MUST be able to instantiate the 551 following functions (1) Active Destination MAC and VLAN Stream 552 identification function, (2) IP Stream identification function and 553 (3) the related managed objects in Clause 9 of IEEE 802.1CB 554 [IEEE8021CB]. IP Stream identification function provides a 6-tuple 555 match. 557 The Sequence encode/decode function MUST support the Redundancy tag 558 (R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB]. 560 6.2. TSN Usage of FRER 562 TSN Streams supporting DetNet flows may use Frame Replication and 563 Elimination for Redundancy (FRER) [802.1CB] based on the loss service 564 requirements of the TSN Stream, which is derived from the DetNet 565 service requirements of the DetNet mapped flow. The specific 566 operation of FRER is not modified by the use of DetNet and follows 567 IEEE 802.1CB [IEEE8021CB]. 569 FRER function and the provided service recovery is available only 570 within the TSN sub-network (as shown in Figure 5) as the Stream-ID 571 and the TSN sequence number are not valid outside the sub-network. 572 An IP (DetNet) node represents a L3 border and as such it terminates 573 all related information elements encoded in the L2 frames. 575 6.3. Procedures 577 [Editor's note: This section is TBD - covers required behavior of a 578 TSN-aware DetNet node using a TSN underlay.] 580 This section provides DetNet IP data plane procedures to interwork 581 with a TSN underlay sub-network when the IP (DetNet) node acts as a 582 TSN-aware Talker or Listener (see Figure 9). These procedures have 583 been divided into the following areas: flow identification, mapping 584 of a DetNet flow to a TSN Stream and ensure proper TSN encapsulation. 586 Flow identification procedures are described in RRR . A TSN-aware IP 587 (DetNet) node SHALL support the Stream Identification TSN components 588 as per IEEE 802.1CB [IEEE8021CB]. 590 Implementations of this document SHALL use management and control 591 information to map a DetNet flow to a TSN Stream. N:1 mapping 592 (aggregating DetNet flows in a single TSN Stream) SHALL be supported. 593 The management or control function that provisions flow mapping SHALL 594 ensure that adequate resources are allocated and configured to 595 provide proper service requirements of the mapped flows. 597 For proper TSN encapsulation implementations of this document SHALL 598 support active Stream Identification function as defined in chapter 599 6.6 in IEEE 802.1CB [IEEE8021CB]. 601 A TSN-aware IP (DetNet) node SHALL support Ethernet encapsulation 602 with Redundancy tag (R-TAG) as per chapter 7.8 in IEEE 802.1CB 603 [IEEE8021CB]. 605 Depending whether FRER functions are used in the TSN sub-network to 606 serve the mapped TSN Stream, a TSN-aware IP (DetNet) node SHALL 607 support Sequencing function and Sequence encode/decode function as 608 per chapter 7.4 and 7.6 in IEEE 802.1CB [IEEE8021CB]. Furthermore 609 when a TSN-aware IP (DetNet) node acting as a replication or 610 elimination point for FRER it SHALL implement the Stream splitting 611 function and the Individual recovery function as per chapter 7.7 and 612 7.5 in IEEE 802.1CB [IEEE8021CB]. 614 7. Management and Control Implications 616 [Editor's note: This section is TBD Covers Creation, mapping, removal 617 of TSN Stream IDs, related parameters and,when needed, configuration 618 of FRER. Supported by management/control plane.] 620 DetNet flow and TSN Stream mapping related information are required 621 only for TSN-aware IP (DetNet) nodes. From the Data Plane 622 perspective there is no practical difference based on the origin of 623 flow mapping related information (management plane or control plane). 625 TSN-aware DetNet IP nodes are member of both the DetNet domain and 626 the TSN sub-network. Within the TSN sub-network the TSN-aware IP 627 (DetNet) node has a TSM-aware Talker/Listener role, so TSN specific 628 management and control plane functionalities must be implemented. 629 There are many similarities in the management plane techniques used 630 in DetNet and TSN, but that is not the case for the control plane 631 protocols. For example, RSVP-TE and MSRP behaves differently. 632 Therefore management and control plane design is an important aspect 633 of scenarios, where mapping between DetNet and TSN is required. 635 In order to use a TSN sub-network between DetNet nodes, DetNet 636 specific information must be converted to TSN sub-network specific 637 ones. DetNet flow ID and flow related parameters/requirements must 638 be converted to a TSN Stream ID and stream related parameters/ 639 requirements. Note that, as the TSN sub-network is just a portion of 640 the end2end DetNet path (i.e., single hop from IP perspective), some 641 parameters (e.g., delay) may differ significantly. Other parameters 642 (like bandwidth) also may have to be tuned due to the L2 643 encapsulation used in the TSN sub-network. 645 In some case it may be challenging to determine some TSN Stream 646 related information. For example on a TSN-aware IP (DetNet) node 647 that acts as a Talker, it is quite obvious which DetNet node is the 648 Listener of the mapped TSN stream (i.e., the IP Next-Hop). However 649 it may be not trivial to locate the point/interface where that 650 Listener is connected to the TSN sub-network. Such attributes may 651 require interaction between control and management plane functions 652 and between DetNet and TSN domains. 654 Mapping between DetNet flow identifiers and TSN Stream identifiers, 655 if not provided explicitly, can be done by a TSN-aware IP (DetNet) 656 node locally based on information provided for configuration of the 657 TSN Stream identification functions (IP Stream identification and 658 active Stream identification function). 660 Triggering the setup/modification of a TSN Stream in the TSN sub- 661 network is an example where management and/or control plane 662 interactions are required between the DetNet and TSN sub-network. 663 TSN-unaware IP (DetNet) nodes make such a triggering even more 664 complicated as they are fully unaware of the sub-network and run 665 independently. 667 Configuration of TSN specific functions (e.g., FRER) inside the TSN 668 sub-network is a TSN specific decision and may not be visible in the 669 DetNet domain. 671 8. Security Considerations 673 The security considerations of DetNet in general are discussed in 674 [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. Other 675 security considerations will be added in a future version of this 676 draft. 678 9. IANA Considerations 680 TBD. 682 10. Acknowledgements 684 Thanks for Norman Finn and Lou Berger for their comments and 685 contributions. 687 11. References 689 11.1. Normative references 691 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 692 DOI 10.17487/RFC0768, August 1980, 693 . 695 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 696 DOI 10.17487/RFC0791, September 1981, 697 . 699 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 700 RFC 793, DOI 10.17487/RFC0793, September 1981, 701 . 703 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 704 RFC 1812, DOI 10.17487/RFC1812, June 1995, 705 . 707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 708 Requirement Levels", BCP 14, RFC 2119, 709 DOI 10.17487/RFC2119, March 1997, 710 . 712 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 713 Network Element Service", RFC 2211, DOI 10.17487/RFC2211, 714 September 1997, . 716 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 717 of Guaranteed Quality of Service", RFC 2212, 718 DOI 10.17487/RFC2212, September 1997, 719 . 721 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 722 "Definition of the Differentiated Services Field (DS 723 Field) in the IPv4 and IPv6 Headers", RFC 2474, 724 DOI 10.17487/RFC2474, December 1998, 725 . 727 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 728 of Explicit Congestion Notification (ECN) to IP", 729 RFC 3168, DOI 10.17487/RFC3168, September 2001, 730 . 732 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 733 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 734 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 735 . 737 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 738 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 739 Protocol Label Switching (MPLS) Support of Differentiated 740 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 741 . 743 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 744 Switching (GMPLS) Signaling Resource ReserVation Protocol- 745 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 746 DOI 10.17487/RFC3473, January 2003, 747 . 749 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 750 DOI 10.17487/RFC4302, December 2005, 751 . 753 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 754 RFC 4303, DOI 10.17487/RFC4303, December 2005, 755 . 757 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 758 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 759 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 760 2009, . 762 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 763 RFC 6003, DOI 10.17487/RFC6003, October 2010, 764 . 766 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 767 Length Recommendation for Forwarding", BCP 198, RFC 7608, 768 DOI 10.17487/RFC7608, July 2015, 769 . 771 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 772 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 773 May 2017, . 775 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 776 (IPv6) Specification", STD 86, RFC 8200, 777 DOI 10.17487/RFC8200, July 2017, 778 . 780 11.2. Informative references 782 [G.8275.1] 783 International Telecommunication Union, "Precision time 784 protocol telecom profile for phase/time synchronization 785 with full timing support from the network", ITU-T 786 G.8275.1/Y.1369.1 G.8275.1, June 2016, 787 . 789 [G.8275.2] 790 International Telecommunication Union, "Precision time 791 protocol telecom profile for phase/time synchronization 792 with partial timing support from the network", ITU-T 793 G.8275.2/Y.1369.2 G.8275.2, June 2016, 794 . 796 [I-D.ietf-detnet-architecture] 797 Finn, N., Thubert, P., Varga, B., and J. Farkas, 798 "Deterministic Networking Architecture", draft-ietf- 799 detnet-architecture-12 (work in progress), March 2019. 801 [I-D.ietf-detnet-dp-sol-mpls] 802 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 803 Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in 804 progress), March 2019. 806 [I-D.ietf-detnet-flow-information-model] 807 Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet 808 Flow Information Model", draft-ietf-detnet-flow- 809 information-model-03 (work in progress), March 2019. 811 [I-D.ietf-detnet-security] 812 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 813 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 814 Networking (DetNet) Security Considerations", draft-ietf- 815 detnet-security-04 (work in progress), March 2019. 817 [I-D.ietf-teas-pce-native-ip] 818 Wang, A., Zhao, Q., Khasanov, B., Chen, H., and R. Mallya, 819 "PCE in Native IP Network", draft-ietf-teas-pce-native- 820 ip-03 (work in progress), April 2019. 822 [IEEE1588] 823 IEEE, "IEEE 1588 Standard for a Precision Clock 824 Synchronization Protocol for Networked Measurement and 825 Control Systems Version 2", 2008. 827 [IEEE8021CB] 828 Finn, N., "Draft Standard for Local and metropolitan area 829 networks - Seamless Redundancy", IEEE P802.1CB 830 /D2.1 P802.1CB, December 2015, 831 . 834 [IEEE8021Q] 835 IEEE 802.1, "Standard for Local and metropolitan area 836 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 837 2014)", 2014, . 839 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 840 Communication Layers", STD 3, RFC 1122, 841 DOI 10.17487/RFC1122, October 1989, 842 . 844 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 845 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 846 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 847 September 1997, . 849 [RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A 850 Framework for QoS-based Routing in the Internet", 851 RFC 2386, DOI 10.17487/RFC2386, August 1998, 852 . 854 [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and 855 W. Weiss, "Information Model for Describing Network Device 856 QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, 857 January 2004, . 859 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 860 and D. McPherson, "Dissemination of Flow Specification 861 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 862 . 864 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 865 Sprecher, N., and S. Ueno, "Requirements of an MPLS 866 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 867 September 2009, . 869 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 870 Ed., and A. Lior, "Traffic Classification and Quality of 871 Service (QoS) Attributes for Diameter", RFC 5777, 872 DOI 10.17487/RFC5777, February 2010, 873 . 875 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 876 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 877 2011, . 879 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 880 Extensions for Associated Bidirectional Label Switched 881 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 882 . 884 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 885 (Diffserv) and Real-Time Communication", RFC 7657, 886 DOI 10.17487/RFC7657, November 2015, 887 . 889 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 890 RFC 7950, DOI 10.17487/RFC7950, August 2016, 891 . 893 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 894 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 895 . 897 [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 898 and A. Vainshtein, "Residence Time Measurement in MPLS 899 Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, 900 . 902 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 903 Architecture for Use of PCE and the PCE Communication 904 Protocol (PCEP) in a Network with Central Control", 905 RFC 8283, DOI 10.17487/RFC8283, December 2017, 906 . 908 Authors' Addresses 910 Balazs Varga (editor) 911 Ericsson 912 Magyar Tudosok krt. 11. 913 Budapest 1117 914 Hungary 916 Email: balazs.a.varga@ericsson.com 918 Janos Farkas 919 Ericsson 920 Magyar Tudosok krt. 11. 921 Budapest 1117 922 Hungary 924 Email: janos.farkas@ericsson.com 926 Andrew G. Malis 927 Huawei Technologies 929 Email: agmalis@gmail.com 931 Stewart Bryant 932 Huawei Technologies 934 Email: stewart.bryant@gmail.com 936 Jouni Korhonen 938 Email: jouni.nospam@gmail.com