idnits 2.17.1 draft-ietf-detnet-dp-sol-ip-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 (June 30, 2018) is 2099 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 264, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-05 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet J. Korhonen, Ed. 3 Internet-Draft 4 Intended status: Standards Track B. Varga, Ed. 5 Expires: January 1, 2019 Ericsson 6 June 30, 2018 8 DetNet IP Data Plane Encapsulation 9 draft-ietf-detnet-dp-sol-ip-00 11 Abstract 13 This document specifies Deterministic Networking data plane operation 14 for IP encapsulated user data. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 1, 2019. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Terms used in this document . . . . . . . . . . . . . . . 3 53 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 54 2.3. Requirements language . . . . . . . . . . . . . . . . . . 4 55 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 56 3.1. DetNet IP Flow Identification . . . . . . . . . . . . . . 7 57 3.2. DetNet Data Plane Requirements . . . . . . . . . . . . . 8 58 4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 8 59 4.1. End-system specific considerations . . . . . . . . . . . 9 60 4.2. DetNet domain specific considerations . . . . . . . . . . 10 61 4.2.1. DetNet Routers . . . . . . . . . . . . . . . . . . . 11 62 4.3. Networks with multiple technology segments . . . . . . . 12 63 4.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 4.5. Class of Service . . . . . . . . . . . . . . . . . . . . 12 65 4.6. Quality of Service . . . . . . . . . . . . . . . . . . . 13 66 4.7. Cross-DetNet flow resource aggregation . . . . . . . . . 14 67 4.8. Time synchronization . . . . . . . . . . . . . . . . . . 15 68 5. Management and control plane considerations . . . . . . . . . 15 69 5.1. Explicit routes . . . . . . . . . . . . . . . . . . . . . 16 70 5.2. Service protection . . . . . . . . . . . . . . . . . . . 16 71 5.3. Congestion protection and latency control . . . . . . . . 16 72 5.4. Flow aggregation control . . . . . . . . . . . . . . . . 16 73 5.5. Bidirectional traffic . . . . . . . . . . . . . . . . . . 16 74 6. DetNet IP Encapsulation Procedures . . . . . . . . . . . . . 17 75 6.1. Multi-Path Considerations . . . . . . . . . . . . . . . . 17 76 7. Mapping IP DetNet Flows to IEEE 802.1 TSN . . . . . . . . . . 17 77 7.1. TSN Stream ID Mapping . . . . . . . . . . . . . . . . . . 18 78 7.2. TSN Usage of FRER . . . . . . . . . . . . . . . . . . . . 18 79 7.3. Management and Control Implications . . . . . . . . . . . 18 80 8. Security considerations . . . . . . . . . . . . . . . . . . . 18 81 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 82 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 12.1. Normative references . . . . . . . . . . . . . . . . . . 20 86 12.2. Informative references . . . . . . . . . . . . . . . . . 22 87 Appendix A. Example of DetNet data plane operation . . . . . . . 24 88 Appendix B. Example of pinned paths using IPv6 . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Introduction 93 Deterministic Networking (DetNet) is a service that can be offered by 94 a network to DetNet flows. DetNet provides these flows extremely low 95 packet loss rates and assured maximum end-to-end delivery latency. 97 General background and concepts of DetNet can be found in the DetNet 98 Architecture [I-D.ietf-detnet-architecture]. 100 This document specifies the DetNet data plane operation for IP hosts 101 and routers that provide DetNet service to IP encapsulated data. No 102 DetNet specific encapsulation is defined to support IP flows, rather 103 existing IP header information is used to support flow identification 104 and DetNet service delivery. General background on the use of IP 105 headers, and "5-tuples", to identify flows and support Quality of 106 Service (QoS) can be found in [RFC3670]. [RFC7657] also provides 107 useful background on the delivery differentiated services (DiffServ) 108 and "6-tuple" based flow identification. 110 The DetNet Architecture decomposes the DetNet related data plane 111 functions into two layers: a service layer and a transport layer. 112 The service layer is used to provide DetNet service protection and 113 reordering. The transport layer is used to provides congestion 114 protection (low loss, assured latency, and limited reordering). As 115 no DetNet specific headers are added to support IP DetNet flows, only 116 the transport layer functions are supported using the IP DetNet 117 defined by this document. Service protection can be provided on a 118 per sub-net basis using technologies such as MPLS 119 [I-D.ietf-detnet-dp-sol-mpls] and IEEE802.1 TSN. 121 This document provides an overview of the DetNet IP data plane in 122 Section 3, considerations that apply to providing DetNet services via 123 the DetNet IP data plane in Section 4 and Section 5. Section 6 124 provides the requirements for hosts and routers that support IP-based 125 DetNet services. Finally, Section 7 provides rules for mapping IP- 126 based DetNet flows to IEEE 802.1 TSN streams. 128 2. Terminology 130 2.1. Terms used in this document 132 This document uses the terminology and concepts established in the 133 DetNet architecture [I-D.ietf-detnet-architecture] the reader is 134 assumed to be familiar with that document. 136 2.2. Abbreviations 138 The following abbreviations used in this document: 140 CE Customer Edge equipment. 142 CoS Class of Service. 144 DetNet Deterministic Networking. 146 DF DetNet Flow. 148 L2 Layer-2. 150 L3 Layer-3. 152 LSP Label-switched path. 154 MPLS Multiprotocol Label Switching. 156 OAM Operations, Administration, and Maintenance. 158 PE Provider Edge. 160 PREOF Packet Replication, Ordering and Elimination Function. 162 PSN Packet Switched Network. 164 PW Pseudowire. 166 QoS Quality of Service. 168 TE Traffic Engineering. 170 TSN Time-Sensitive Networking, TSN is a Task Group of the 171 IEEE 802.1 Working Group. 173 2.3. Requirements language 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in BCP 178 14 [RFC2119] [RFC8174] when, and only when, they appear in all 179 capitals, as shown here. 181 3. DetNet IP Data Plane Overview 183 This document describes how IP is used by DetNet nodes, i.e., hosts 184 and routers, to identify DetNet flows and provide a DetNet service. 185 From a data plane perspective, an end-to-end IP model is followed. 187 IP DetNet Relay Relay IP DetNet 188 End System Node Node End System 190 +---------+ +---------+ 191 | Appl. |<--------------- End to End Service ---------->| Appl. | 192 +---------+ ........... ........... +---------+ 193 | Service |<---: Service :-- DetNet flow ---: Service :-->| Service | 194 +---------+ +---------+ +---------+ +---------+ 195 |Transport| |Transport| |Transport| |Transport| 196 +-------.-+ +-.-----.-+ +-.-----.-+ +---.-----+ 197 : Link : \ ,-----. / / ,-----. \ 198 +........+ +-----[ Sub ]----+ +-[ Sub ]-+ 199 [Network] [Network] 200 `-----' `-----' 202 |<-DN IP->| |<----- DetNet IP ---->| |<-DN IP->| 204 Figure 1: A Simple DetNet (DN) Enabled IP Network 206 Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled 207 end systems originate IP encapsulated traffic that is identified as 208 DetNet flows, relay nodes understand the transport requirements of 209 the DetNet flow and ensure that node, interface and sub-network 210 resources are allocated to ensure DetNet service requirements. The 211 dotted line around the Service component of the Relay Nodes indicates 212 that the transit routers are DetNet service aware but do not perform 213 any DetNet service layer function, e.g., PREOF. IEEE 802.1 TSN is an 214 example sub-network type which can provide support for DetNet flows 215 and service. The mapping of IP DetNet flows to TSN streams and TSN 216 protection mechanisms is covered in Section 7. 218 IP DetNet Relay Transit Relay IP DetNet 219 End System Node Node Node End System 221 +---------+ +---------+ 222 | Appl. |<--------------- End to End Service ---------->| Appl. | 223 +---------+ .....-----+ +-----..... +---------+ 224 | Service |<---: Service |-- DetNet flow ---| Service :-->| Service | 225 +---------+ +---------+ +---------+ +---------+ +---------+ 226 |Transport| |Trp| |Trp| |Transport| |Trp| |Trp| |Transport| 227 +-------.-+ +-.-+ +-.-+ +---.---.-+ +-.-+ +-.-+ +---.-----+ 228 : Link : / ,-----. \ : Link : / ,-----. \ 229 +........+ +-[ Sub ]-+ +........+ +-[ Sub ]-+ 230 [Network] [Network] 231 `-----' `-----' 233 |<-DN IP->| |<---- DetNet MPLS ---->| |<-DN IP->| 235 Figure 2: DetNet (DN) IP Over MPLS Network 237 Figure 2 illustrates a more complex DetNet enabled IP network where 238 an IP flow is mapped to one or more PWs and MPLS (TE) LSPs. The end 239 systems still originate IP encapsulated traffic that is identified as 240 DetNet flows. The relay nodes follow procedures defined in 241 [I-D.ietf-detnet-dp-sol-mpls] to map each DetNet flow to MPLS LSPs. 242 While not shown, relay nodes can provide service layer functions such 243 as PREOF over the MPLS transport layer, and this is indicated by the 244 solid line for the MPLS facing portion of the Service component. 245 Note that the Transit node is MPLS (TE) LSP aware and performs 246 switching based on MPLS labels, and need not have any specific 247 knowledge of the DetNet service or the corresponding DetNet flow 248 identification. See [I-D.ietf-detnet-dp-sol-mpls] for details on the 249 mapping of IP flows to MPLS as well as general support for DetNet 250 services using MPLS. 252 IP Edge Edge IP 253 End System Node Node End System 255 +---------+ +.........+ +.........+ +---------+ 256 | Appl. |<---:Svc Proxy:-- E2E Service ---:Svc Proxy:-->| Appl. | 257 +---------+ +---------+ +---------+ +---------+ 258 | IP | |IP | |Svc|<-- DetNet flow ->|Svc| |IP | | IP | 259 +---------+ +---+ +---+ +---+ +---+ +---------+ 260 |Transport| |Trp| |Trp| |Trp| |Trp| |Transport| 261 +-------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.-----+ 262 : Link : \ ,-----. / / ,-----. \ 263 +........+ +-----[ Sub ]---+ +-[ Sub ]-+ 264 [Network] [Network] 265 `-----' `-----' 267 |<----IP --->| |<----- DetNet IP ------>| |<----IP --->| 269 Figure 3: Non-DetNet aware IP end systems with IP DetNet Domain 271 Figure 3 illustrates a variant of Figure 1 where the end systems are 272 not DetNet aware. In this case, edge nodes sit at the boundary of 273 the DetNet domain and act as DetNet service proxies for the end 274 applications by initiating and terminating DetNet service for the 275 non-DetNet aware IP flows. The existing header information or an 276 approach such as described in Section 4.7 can be used to support 277 DetNet flow identification. 279 3.1. DetNet IP Flow Identification 281 DetNet IP flows are identified based on IP, both IPv4 [RFC0791] and 282 IPv6 [RFC8200], header information. 6 header fields are used and 283 this set of fields is commonly referred to as the IP header 284 "6-tuple". The 6 fields include the IP source and destination 285 address fields, the next level protocol or header field, the next 286 level protocol (e.g. TCP or UDP) source and destination ports, and 287 the IPv4 Type of Service or IPv6 Traffic Class field (i.e., DSCP). 288 As part of single DetNet flow identification, any of the fields can 289 be ignored (wildcarded), and bit masks, prefix based longest match, 290 and ranges can also be used. 292 DetNet flow aggregation may be enabled via the use of wildcards, 293 masks, prefixes and ranges. IP tunnels may also be used to support 294 flow aggregation. In these cases, it is expected that DetNet aware 295 intermediate nodes will provide DetNet service assurance on the 296 aggregate through resource allocation and congestion control 297 mechanisms. 299 3.2. DetNet Data Plane Requirements 301 Two major groups of scenarios can be distinguished which require flow 302 identification during transport: 304 1. DetNet function related scenarios: 306 Congestion protection and latency control: 308 Usage of allocated resources (queuing, policing, shaping) to 309 ensure that the congestion-related loss and latency/jitter 310 requirements of a DetNet flow are met. 312 Explicit routes: a reservation that maps a flow to a specific 313 path, which also limits miss-ordering and jitter. The 314 spreading of a single DetNet flow across multiple paths, e.g., 315 via ECMP, also impacts ordering and end-to-end jitter, and as 316 such use of multiple paths for support of a single DetNet flow 317 is is out of scope this document. 319 Service protection: 321 Which in the case of this document translates to changing the 322 explicit path after a failure is detected while maintaining 323 the required DetNet service characteristics. Path changes, 324 even in the case of failure recovery, can lead to the out of 325 order delivery of data. Note: DetNet PREOF is not provided by 326 the mechanisms defined in this document. 328 2. OAM function related scenarios: 330 Troubleshooting: 332 For example, identify misbehaving flows. 334 Recognize flow(s) for analytics: 336 For example, increase counters. 338 Correlate events with flows: 340 For example, volume above threshold. 342 4. DetNet IP Data Plane Considerations 344 This section provides informative considerations related to providing 345 DetNet services via IP. 347 4.1. End-system specific considerations 349 Data-flows requiring DetNet service are generated and terminated on 350 end systems. The specific protocols used by an end system are 351 specific to an application. This said, DetNet's use of 6-tuple IP 352 flow identification means that DetNet must be aware of not only the 353 format of the IP header, but also of the next protocol carried within 354 an IP packet. 356 When IP end systems are DetNet aware, no application-level or 357 service-level proxy functions are needed inside the DetNet domain, so 358 end systems peer with end systems using the same application 359 encapsulation format (see Figure 4). 361 +-----+ 362 | X | +-----+ 363 +-----+ | X | 364 | IP | ________ +-----+ 365 +-----+ _____ / \ | IP | 366 \ / \__/ \___ +-----+ 367 \ / \ / 368 0========= flow-1 =========0_ 369 | \ 370 \ | 371 0========== flow-2 ==========0 372 / \ __/ \ 373 +-----+ \__ DetNet domain / \ 374 | X | \ __ / +-----+ 375 +-----+ \_______/ \_____/ | X | 376 | IP | +-----+ 377 +-----+ | IP | 378 +-----+ 380 Figure 4: End-systems and the DetNet domain 382 End systems need to ensure that DetNet service requirements are met 383 when processing packets associated with a DetNet flow. When 384 transporting packets, this generally means that packets are 385 appropriately shaped on transmission and received appropriate traffic 386 treatment on the connected sub-network, see Section 4.6 and 387 Section 4.2.1 for more details. When receiving packets, this 388 generally means that there are appropriate local node resources, 389 e.g., buffers, to receive and process a DetNet flow packets. 391 4.2. DetNet domain specific considerations 393 As a general rule, DetNet domains need to be able to forward any 394 DetNet flow identified by the IP 6-tuple. Doing otherwise would 395 limit end system encapsulation format. From a practical standpoint 396 this means that all nodes along the end-to-end path of a DetNet flows 397 need to agree on what fields are used for flow identification, and 398 the transport protocols (e.g., TCP/UDP/IPsec) which can be used to 399 identify 6-tuple protocol ports. 401 [Editor's note: Update accordingly. BV to take a pass at update.] 403 From a connection type perspective three scenarios are identified: 405 1. Directly attached: end system is directly connected to an edge 406 node. 408 2. Indirectly attached: end system is behind a (L2-TSN / L3-DetNet) 409 sub-networks. 411 3. DN integrated: end system is part of the DetNet domain. 413 L3 end systems may use any of these connection types, however L2 end 414 systems may use only the first two (directly or indirectly attached). 415 DetNet domain MUST allow communication between any end-systems of the 416 same type (L2-L2, L3-L3), independent of their connection type and 417 DetNet capability. However, directly attached and indirectly 418 attached end systems have no knowledge about the DetNet domain and 419 its encapsulation format at all. See Figure 5 for L3 end system 420 connection scenarios. 422 ____+----+ 423 +----+ _____ / | ES3| 424 | ES1|____ / \__/ +----+___ 425 +----+ \ / \ 426 + | 427 ____ \ _/ 428 +----+ __/ \ +__ DetNet domain / 429 | ES2|____/ L2/L3 |___/ \ __ __/ 430 +----+ \_______/ \_______/ \___/ 432 Figure 5: Connection types of L3 end systems 434 4.2.1. DetNet Routers 436 Within a DetNet domain, the DetNet enabled IP Routers interconnect 437 links and sub-networks to support end-to-end delivery of DetNet 438 flows. From a DetNet architecture perspective, these routers are 439 DetNet relays, as they must be DetNet service aware. Such routers 440 identify DetNet flows based on the IP 6-tuple, and ensure that the 441 DetNet service required traffic treatment is provided both on the 442 node and on any attached sub-network. 444 This solution provides DetNet functions end to end, but does so on a 445 per link and sub-network basis. Congestion protection and latency 446 control and the resource allocation (queuing, policing, shaping) are 447 supported using the underlying link / sub net specific mechanisms. 448 However, service protections (packet replication and packet 449 emilination functions) are not provided at the DetNet layer end to 450 end. But such service protection can be provided on a per underlying 451 L2 link and sub-network basis. 453 +------+ +------+ 454 | X | | X | 455 +======+ +------+ 456 End-system | IP | | IP | 457 -----+------+-------+======+--- --+======+-- 458 DetNet |L2/SbN| |L2/SbN| 459 +------+ +------+ 461 Figure 6: Encapsulation of DetNet Routing in simplified IP service L3 462 end-systems 464 Note: the DetNet Service Flow MUST be mapped to the link / sub- 465 network specific resources using an underlying system specific means. 466 This implies each DetNet aware node on path MUST look into the 467 transported DetNet Service Flow packet and utilize e.g., a 5- (or 6-) 468 tuple to find out the required mapping within a node. As noted 469 earlier, the Service Protection is done within each link / sub- 470 network independently using the domain specific mechanisms (due the 471 lack of a unified end to end sequencing information that would be 472 available for intermediate nodes). If end to end service protection 473 is desired that can be implemented, for example, by the DetNet end 474 systems using Layer-4 (L4) transport protocols or application 475 protocols. However, these are out of scope of this document. 477 [Editor's note: the service protection to be clarified further.] 479 4.3. Networks with multiple technology segments 481 There are network scenarios, where the DetNet domain contains 482 multiple technology segments (IEEE 802.1 TSN, MPLS) and all those 483 segments are under the same administrative control (see Figure 7). 484 Furthermore, DetNet nodes may be interconnected via TSN segments. 486 DetNet routers ensure that detnet service requirements are met per 487 hop by allocating local resources, both receive and transmit, and by 488 mapping the service requirements of each flow to appropriate sub- 489 network mechanisms. Such mapping is sub-network technology specific. 490 The mapping of IP DetNet Flows to MPLS is covered 491 [I-D.ietf-detnet-dp-sol-mpls]. The mapping of IP DetNet Flows to 492 IEEE 802.1 TSN is covered in Section 7. 494 ______ 495 _____ / \__ 496 ____ / \__/ \___ ______ 497 +----+ __/ +======+ +==+ \ +----+ 498 |src |__/ Seg1 ) | | \ Seg3 \__| dst| 499 +----+ \_______+ \ Segment-2 | \+_____/ +----+ 500 \======+__ _+===/ 501 \ __ __/ 502 \_______/ \___/ 504 Figure 7: DetNet domains and multiple technology segments 506 4.4. OAM 508 [Editor's note: This section is TBD] 510 4.5. Class of Service 512 [Editor's note: this section is TBD] 514 Class and quality of service, i.e., CoS and QoS, are terms that are 515 often used interchangeably and confused. In the context of DetNet, 516 CoS is used to refer to mechanisms that provide traffic forwarding 517 treatment based on aggregate group basis and QoS is used to refer to 518 mechanisms that provide traffic forwarding treatment based on a 519 specific DetNet flow basis. Examples of existing network level CoS 520 mechanisms include DiffServ which is enabled by IP header 521 differentiated services code point (DSCP) field [RFC2474] and MPLS 522 label traffic class field [RFC5462], and at Layer-2, by IEEE 802.1p 523 priority code point (PCP). 525 CoS for DetNet flows carried in PWs and MPLS is provided using the 526 existing MPLS Differentiated Services (DiffServ) architecture 527 [RFC3270]. Both E-LSP and L-LSP MPLS DiffServ modes MAY be used to 528 support DetNet flows. The Traffic Class field (formerly the EXP 529 field) of an MPLS label follows the definition of [RFC5462] and 530 [RFC3270]. The Uniform, Pipe, and Short Pipe DiffServ tunneling and 531 TTL processing models are described in [RFC3270] and [RFC3443] and 532 MAY be used for MPLS LSPs supporting DetNet flows. MPLS ECN MAY also 533 be used as defined in ECN [RFC5129] and updated by [RFC5462]. 535 CoS for DetNet flows carried in IPv6 is provided using the standard 536 differentiated services code point (DSCP) field [RFC2474] and related 537 mechanisms. The 2-bit explicit congestion notification (ECN) 538 [RFC3168] field MAY also be used. 540 One additional consideration for DetNet nodes which support CoS 541 services is that they MUST ensure that the CoS service classes do not 542 impact the congestion protection and latency control mechanisms used 543 to provide DetNet QoS. This requirement is similar to requirement 544 for MPLS LSRs to that CoS LSPs do not impact the resources allocated 545 to TE LSPs via [RFC3473]. 547 4.6. Quality of Service 549 [Editor's note: Keep this section. We should document the used 550 technologies but the detailed discussion may go somewhere else. We 551 should start having it here and then decide whether to move to some 552 other document.] 554 Quality of Service (QoS) mechanisms for flow specific traffic 555 treatment typically includes a guarantee/agreement for the service, 556 and allocation of resources to support the service. Example QoS 557 mechanisms include discrete resource allocation, admission control, 558 flow identification and isolation, and sometimes path control, 559 traffic protection, shaping, policing and remarking. Example 560 protocols that support QoS control include Resource ReSerVation 561 Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. 562 The existing MPLS mechanisms defined to support CoS [RFC3270] can 563 also be used to reserve resources for specific traffic classes. 565 In addition to explicit routes, and packet replication and 566 elimination, DetNet provides zero congestion loss and bounded latency 567 and jitter. As described in [I-D.ietf-detnet-architecture], there 568 are different mechanisms that maybe used separately or in combination 569 to deliver a zero congestion loss service. These mechanisms are 570 provided by the either the MPLS or IP layers, and may be combined 571 with the mechanisms defined by the underlying network layer such as 572 802.1TSN. 574 A baseline set of QoS capabilities for DetNet flows carried in PWs 575 and MPLS can provided by MPLS with Traffic Engineering (MPLS-TE) 576 [RFC3209] and [RFC3473]. TE LSPs can also support explicit routes 577 (path pinning). Current service definitions for packet TE LSPs can 578 be found in "Specification of the Controlled Load Quality of 579 Service", [RFC2211], "Specification of Guaranteed Quality of 580 Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003]. 581 Additional service definitions are expected in future documents to 582 support the full range of DetNet services. In all cases, the 583 existing label-based marking mechanisms defined for TE-LSPs and even 584 E-LSPs are use to support the identification of flows requiring 585 DetNet QoS. 587 QoS for DetNet service flows carried in IP MUST be provided locally 588 by the DetNet-aware hosts and routers supporting DetNet flows. Such 589 support will leverage the underlying network layer such as 802.1TSN. 590 The traffic control mechanisms used to deliver QoS for IP 591 encapsulated DetNet flows are expected to be defined in a future 592 document. From an encapsulation perspective, the combination of the 593 "6 tuple" i.e., the typical 5 tuple enhanced with the DSCP code, 594 uniquely identifies a DetNet service flow. 596 Packets that are marked with a DetNet Class of Service value, but 597 that have not been the subject of a completed reservation, can 598 disrupt the QoS offered to properly reserved DetNet flows by using 599 resources allocated to the reserved flows. Therefore, the network 600 nodes of a DetNet network must: 602 o Defend the DetNet QoS by discarding or remarking (to a non-DetNet 603 CoS) packets received that are not the subject of a completed 604 reservation. 606 o Not use a DetNet reserved resource, e.g. a queue or shaper 607 reserved for DetNet flows, for any packet that does not carry a 608 DetNet Class of Service marker. 610 4.7. Cross-DetNet flow resource aggregation 612 [Editor's note: Aggregation is FFS. The addregation can be provided 613 via encapsulation or header wildcards] 615 The ability to aggregate individual flows, and their associated 616 resource control, into a larger aggregate is an important technique 617 for improving scaling of control in the data, management and control 618 planes. This document identifies the traffic identification related 619 aspects of aggregation of DetNet flows. The resource control and 620 management aspects of aggregation (including the queuing/shaping/ 621 policing implications) will be covered in other documents. The data 622 plane implications of aggregation are independent for PW/MPLS and IP 623 encapsulated DetNet flows. 625 DetNet flows transported via IP have more limited aggregation 626 options, due to the available traffic flow identification fields of 627 the IP solution. One available approach is to manage the resources 628 associated with a DSCP identified traffic class and to map (remark) 629 individually controlled DetNet flows onto that traffic class. This 630 approach also requires that nodes support aggregation ensure that 631 traffic from aggregated LSPs are placed (shaped/policed/enqueued) in 632 a fashion that ensures the required DetNet service is preserved. 634 In both the MPLS and IP cases, additional details of the traffic 635 control capabilities needed at a DetNet-aware node may be covered in 636 the new service descriptions mentioned above or in separate future 637 documents. Management and control plane mechanisms will also need to 638 ensure that the service required on the aggregate flow (H-LSP or 639 DSCP) are provided, which may include the discarding or remarking 640 mentioned in the previous sections. 642 4.8. Time synchronization 644 While time synchronization can be important both from the perspective 645 of operating the DetNet network itself and from the perspective of 646 DetNet-based applications, time synchronization is outside the scope 647 of this document. This said, a DetNet node can also support time 648 synchronization or distribution mechanisms. 650 For example, [RFC8169] describes a method of recording the packet 651 queuing time in an MPLS LSR on a packet by per packet basis and 652 forwarding this information to the egress edge system. This allows 653 compensation for any variable packet queuing delay to be applied at 654 the packet receiver. Other mechanisms for IP networks are defined 655 based on IEEE Standard 1588 [IEEE1588], such as ITU-T [G.8275.1] and 656 [G.8275.2]. 658 A more detailed discussion of time synchronization is outside the 659 scope of this document. 661 5. Management and control plane considerations 663 [Editor's note: This section needs to be different for MPLS and IP 664 solutions. Most solutions are technology dependant.] 666 While management plane and control plane are traditionally considered 667 separately, from the Data Plane perspective there is no practical 668 difference based on the origin of flow provisioning information. 669 This document therefore does not distinguish between information 670 provided by a control plane protocol, e.g., RSVP-TE [RFC3209] and 671 [RFC3473], or by a network management mechanisms, e.g., RestConf 672 [RFC8040] and YANG [RFC7950]. 674 [Editor's note: This section is a work in progress. discuss here 675 what kind of enhancements are needed for DetNet and specifically for 676 PREOF and DetNet zero congest loss and latency control. Need to 677 cover both traffic control (queuing) and connection control (control 678 plane).] 680 5.1. Explicit routes 682 [Editor's note: this is TBD.] 684 5.2. Service protection 686 [Editor's note: this is TBD.] 688 5.3. Congestion protection and latency control 690 [Editor's note: this is TBD.] 692 5.4. Flow aggregation control 694 [Editor's note: this is TBD.] 696 5.5. Bidirectional traffic 698 [Editor's note: This is managed at the management plane or controller 699 level.] 701 Some DetNet applications generate bidirectional traffic. While the 702 DetNet data plane must support bidirectional DetNet flows, there are 703 no special bidirectional features with respect to the data plane 704 other than need for the two directions take the same paths. That is 705 to say that bidirectional DetNet flows are solely represented at the 706 management and control plane levels, without specific support or 707 knowledge within the DetNet data plane. Fate sharing and associated 708 vs co-routed bidirectional flows can be managed at the control level. 709 Note, that there is no stated requirement for bidirectional DetNet 710 flows to be supported using the same 6-tuple in each direction. 711 Control mechanisms will need to support such bidirectional flows but 712 such mechanisms are out of scope of this document. An example 713 control plane solution for MPLS can be found in [RFC7551]. 715 6. DetNet IP Encapsulation Procedures 717 [Editor's note: RFC2119 conformance language goes here Need to 718 support flow identification Based on 4 IP header fields {ip addrs, 719 dscp, nct protocol} need to support port identification for TCP/UDP, 720 IPsec spi (?), what else? Service proxies -- basically same from 721 data plane, different from management map to local resources] 723 6.1. Multi-Path Considerations 725 [Note: talk about implications of ECMP/LAG/parallel links -- perhaps 726 just say support for such is not covered in the document.] 728 7. Mapping IP DetNet Flows to IEEE 802.1 TSN 730 [Editor's note: This section is TBD - it covers how IP DetNet flows 731 operate over an IEEE 802.1 TSN sub-network. BV to take a pass at 732 filling in this section] 734 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 735 Working Group have defined (and are defining) a number of amendments 736 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 737 bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB] 738 defines packet replication and elimination functions that should 739 prove both compatible with and useful to, DetNet networks. 741 As is the case for DetNet, a Layer 2 network node such as a bridge 742 may need to identify the specific DetNet flow to which a packet 743 belongs in order to provide the TSN/DetNet QoS for that packet. It 744 also will likely need a CoS marking, such as the priority field of an 745 IEEE Std 802.1Q VLAN tag, to give the packet proper service. 747 Although the flow identification methods described in IEEE 802.1CB 748 [IEEE8021CB] are flexible, and in fact, include IP 5-tuple 749 identification methods, the baseline TSN standards assume that every 750 Ethernet frame belonging to a TSN stream (i.e. DetNet flow) carries 751 a multicast destination MAC address that is unique to that flow 752 within the bridged network over which it is carried. Furthermore, 753 IEEE 802.1CB [IEEE8021CB] describes three methods by which a packet 754 sequence number can be encoded in an Ethernet frame. 756 Ensuring that the proper Ethernet VLAN tag priority and destination 757 MAC address are used on a DetNet/TSN packet may require further 758 clarification of the customary L2/L3 transformations carried out by 759 routers and edge label switches. Edge nodes may also have to move 760 sequence number fields among Layer 2, PW, and IPv6 encapsulations. 762 7.1. TSN Stream ID Mapping 764 [Editor's Note: This section covers the data plane aspects of mapping 765 an IP DetNet flow to one or more TSN Stream-IDs.] 767 7.2. TSN Usage of FRER 769 [Core point] TSN Streams support DetNet flows may use Frame 770 Replication and Elimination for Redundancy (FRER) [802.1CB] based on 771 the loss service requirements of the TSN Stream, which is derived 772 from the DetNet service requirements of the DetNet mapped flow. The 773 specific operation of the FRER is not modified by the use of DetNe 774 and follows IEEE 802.1CB [IEEE8021CB]. 776 7.3. Management and Control Implications 778 [Editor's note: This section is TBD Covers Creation, mapping, removal 779 of TSN Stream IDs, related parameters and,when needed, configuration 780 of FRER. Supported by management/control plane.] 782 8. Security considerations 784 The security considerations of DetNet in general are discussed in 785 [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. Other 786 security considerations will be added in a future version of this 787 draft. 789 9. IANA considerations 791 TBD. 793 10. Contributors 795 RFC7322 limits the number of authors listed on the front page of a 796 draft to a maximum of 5, far fewer than the 20 individuals below who 797 made important contributions to this draft. The editor wishes to 798 thank and acknowledge each of the following authors for contributing 799 text to this draft. See also Section 11. 801 Loa Andersson 802 Huawei 803 Email: loa@pi.nu 805 Yuanlong Jiang 806 Huawei 807 Email: jiangyuanlong@huawei.com 809 Norman Finn 810 Huawei 811 3101 Rio Way 812 Spring Valley, CA 91977 813 USA 814 Email: norman.finn@mail01.huawei.com 816 Janos Farkas 817 Ericsson 818 Magyar Tudosok krt. 11 819 Budapest 1117 820 Hungary 821 Email: janos.farkas@ericsson.com 823 Carlos J. Bernardos 824 Universidad Carlos III de Madrid 825 Av. Universidad, 30 826 Leganes, Madrid 28911 827 Spain 828 Email: cjbc@it.uc3m.es 830 Tal Mizrahi 831 Marvell 832 6 Hamada st. 833 Yokneam 834 Israel 835 Email: talmi@marvell.com 837 Lou Berger 838 LabN Consulting, L.L.C. 839 Email: lberger@labn.net 841 11. Acknowledgements 843 The author(s) ACK and NACK. 845 The following people were part of the DetNet Data Plane Solution 846 Design Team: 848 Jouni Korhonen 849 Janos Farkas 851 Norman Finn 853 Balazs Varga 855 Loa Andersson 857 Tal Mizrahi 859 David Mozes 861 Yuanlong Jiang 863 Carlos J. Bernardos 865 The DetNet chairs serving during the DetNet Data Plane Solution 866 Design Team: 868 Lou Berger 870 Pat Thaler 872 Thanks for Stewart Bryant for his extensive review of the previous 873 versions of the document. 875 12. References 877 12.1. Normative references 879 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 880 DOI 10.17487/RFC0791, September 1981, 881 . 883 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 884 Requirement Levels", BCP 14, RFC 2119, 885 DOI 10.17487/RFC2119, March 1997, 886 . 888 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 889 Network Element Service", RFC 2211, DOI 10.17487/RFC2211, 890 September 1997, . 892 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 893 of Guaranteed Quality of Service", RFC 2212, 894 DOI 10.17487/RFC2212, September 1997, 895 . 897 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 898 "Definition of the Differentiated Services Field (DS 899 Field) in the IPv4 and IPv6 Headers", RFC 2474, 900 DOI 10.17487/RFC2474, December 1998, 901 . 903 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 904 of Explicit Congestion Notification (ECN) to IP", 905 RFC 3168, DOI 10.17487/RFC3168, September 2001, 906 . 908 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 909 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 910 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 911 . 913 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 914 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 915 Protocol Label Switching (MPLS) Support of Differentiated 916 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 917 . 919 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 920 in Multi-Protocol Label Switching (MPLS) Networks", 921 RFC 3443, DOI 10.17487/RFC3443, January 2003, 922 . 924 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 925 Switching (GMPLS) Signaling Resource ReserVation Protocol- 926 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 927 DOI 10.17487/RFC3473, January 2003, 928 . 930 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 931 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 932 2008, . 934 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 935 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 936 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 937 2009, . 939 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 940 RFC 6003, DOI 10.17487/RFC6003, October 2010, 941 . 943 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 944 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 945 May 2017, . 947 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 948 (IPv6) Specification", STD 86, RFC 8200, 949 DOI 10.17487/RFC8200, July 2017, 950 . 952 12.2. Informative references 954 [G.8275.1] 955 International Telecommunication Union, "Precision time 956 protocol telecom profile for phase/time synchronization 957 with full timing support from the network", ITU-T 958 G.8275.1/Y.1369.1 G.8275.1, June 2016, 959 . 961 [G.8275.2] 962 International Telecommunication Union, "Precision time 963 protocol telecom profile for phase/time synchronization 964 with partial timing support from the network", ITU-T 965 G.8275.2/Y.1369.2 G.8275.2, June 2016, 966 . 968 [I-D.ietf-detnet-architecture] 969 Finn, N., Thubert, P., Varga, B., and J. Farkas, 970 "Deterministic Networking Architecture", draft-ietf- 971 detnet-architecture-05 (work in progress), May 2018. 973 [I-D.ietf-detnet-dp-sol-mpls] 974 Korhonen, J., Varga, B., "DetNet MPLS Data Plane 975 Encapsulation", 2018. 977 [I-D.ietf-detnet-security] 978 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 979 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 980 Networking (DetNet) Security Considerations", draft-ietf- 981 detnet-security-02 (work in progress), April 2018. 983 [IEEE1588] 984 IEEE, "IEEE 1588 Standard for a Precision Clock 985 Synchronization Protocol for Networked Measurement and 986 Control Systems Version 2", 2008. 988 [IEEE8021CB] 989 Finn, N., "Draft Standard for Local and metropolitan area 990 networks - Seamless Redundancy", IEEE P802.1CB 991 /D2.1 P802.1CB, December 2015, 992 . 995 [IEEE8021Q] 996 IEEE 802.1, "Standard for Local and metropolitan area 997 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 998 2014)", 2014, . 1000 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1001 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1002 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1003 September 1997, . 1005 [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and 1006 W. Weiss, "Information Model for Describing Network Device 1007 QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, 1008 January 2004, . 1010 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 1011 Extensions for Associated Bidirectional Label Switched 1012 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1013 . 1015 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 1016 (Diffserv) and Real-Time Communication", RFC 7657, 1017 DOI 10.17487/RFC7657, November 2015, 1018 . 1020 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1021 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1022 . 1024 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1025 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1026 . 1028 [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 1029 and A. Vainshtein, "Residence Time Measurement in MPLS 1030 Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, 1031 . 1033 Appendix A. Example of DetNet data plane operation 1035 [Editor's note: Add a simplified example of DetNet data plane and how 1036 labels etc work in the case of MPLS-based PSN and utilizing PREOF. 1037 The figure is subject to change depending on the further DT decisions 1038 on the label handling..] 1040 Appendix B. Example of pinned paths using IPv6 1042 TBD. 1044 Authors' Addresses 1046 Jouni Korhonen (editor) 1048 Email: jouni.nospam@gmail.com 1050 Balazs Varga (editor) 1051 Ericsson 1052 Magyar Tudosok krt. 11. 1053 Budapest 1117 1054 Hungary 1056 Email: balazs.a.varga@ericsson.com