idnits 2.17.1 draft-ietf-detnet-ip-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 (October 16, 2019) is 1655 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 252, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-02 == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-05 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-ip-over-mpls-01 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-00 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-05 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-tsn-vpn-over-mpls-00 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-yang-03 -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 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: April 18, 2020 L. Berger 6 D. Fedyk 7 LabN Consulting, L.L.C. 8 A. Malis 9 Independent 10 S. Bryant 11 Futurewei Technologies 12 J. Korhonen 13 October 16, 2019 15 DetNet Data Plane: IP 16 draft-ietf-detnet-ip-02 18 Abstract 20 This document specifies the Deterministic Networking data plane when 21 operating in an IP packet switched network. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 18, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 60 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 61 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 63 4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 6 64 4.1. End-System Specific Considerations . . . . . . . . . . . 7 65 4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7 66 4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 9 67 4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 9 68 4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10 69 4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 10 70 4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 11 71 4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 12 72 5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 12 73 5.1. DetNet IP Flow Identification Procedures . . . . . . . . 12 74 5.1.1. IP Header Information . . . . . . . . . . . . . . . . 13 75 5.1.2. Other Protocol Header Information . . . . . . . . . . 14 76 5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 15 77 5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 15 78 6. Management and Control Information Summary . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 10.1. Normative references . . . . . . . . . . . . . . . . . . 18 84 10.2. Informative references . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 87 1. Introduction 89 Deterministic Networking (DetNet) is a service that can be offered by 90 a network to DetNet flows. DetNet provides these flows extremely low 91 packet loss rates and assured maximum end-to-end delivery latency. 92 General background and concepts of DetNet can be found in the DetNet 93 Architecture [I-D.ietf-detnet-architecture]. 95 This document specifies the DetNet data plane operation for IP hosts 96 and routers that provide DetNet service to IP encapsulated data. No 97 DetNet specific encapsulation is defined to support IP flows, instead 98 the existing IP and higher layer protocol header information is used 99 to support flow identification and DetNet service delivery. Common 100 data plane procedures and control information for all DetNet data 101 planes can be found in the [I-D.ietf-detnet-data-plane-framework]. 103 The DetNet Architecture models the DetNet related data plane 104 functions decomposed into two sub-layers: functions into two sub- 105 layers: a service sub-layer and a forwarding sub-layer. The service 106 sub-layer is used to provide DetNet service protection and 107 reordering. The forwarding sub-layer is used to provides congestion 108 protection (low loss, assured latency, and limited out-of-order 109 delivery). Since no DetNet specific headers are added to support 110 DetNet IP flows, only the forwarding sub-layer functions are 111 supported using the DetNet IP defined by this document. Service 112 protection can be provided on a per sub-net basis using technologies 113 such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified 114 in the IEEE 802.1 TSN task group(referred to in this document simply 115 as IEEE802.1 TSN). 117 This document provides an overview of the DetNet IP data plane in 118 Section 3, considerations that apply to providing DetNet services via 119 the DetNet IP data plane in Section 4. Section 5 provides the 120 procedures for hosts and routers that support IP-based DetNet 121 services. Section 6 summarizes the set of information that is needed 122 to identify an individual DetNet flow. 124 2. Terminology 126 2.1. Terms Used In This Document 128 This document uses the terminology and concepts established in the 129 DetNet architecture [I-D.ietf-detnet-architecture], and the reader is 130 assumed to be familiar with that document and its terminology. 132 2.2. Abbreviations 134 The following abbreviations used in this document: 136 CoS Class of Service. 138 DetNet Deterministic Networking. 140 DN DetNet. 142 DiffServ Differentiated Services 144 DSCP Differentiated Services Code Point 145 ECN Explicit Congestion Notification. 147 L2 Layer-2. 149 L3 Layer-3. 151 LSP Label-switched path. 153 MPLS Multiprotocol Label Switching. 155 PREOF Packet Replication, Ordering and Elimination Function. 157 QoS Quality of Service. 159 TSN Time-Sensitive Networking, TSN is a Task Group of the 160 IEEE 802.1 Working Group. 162 2.3. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 3. DetNet IP Data Plane Overview 172 This document describes how IP is used by DetNet nodes, i.e., hosts 173 and routers, identify DetNet flows and provide a DetNet service using 174 an IP data plane. From a data plane perspective, an end-to-end IP 175 model is followed. As mentioned above, existing IP and higher layer 176 protocol header information is used to support flow identification 177 and DetNet service delivery. Common data plane procedures and 178 control information for all DetNet data planes can be found in the 179 [I-D.ietf-detnet-data-plane-framework]. 181 The DetNet IP data plane primarily uses "6-tuple" based flow 182 identification, where 6-tuple refers to information carried in IP and 183 higher layer protocol headers. The 6-tuple referred to in this 184 document is the same as that defined in [RFC3290]. Specifically 185 6-tuple is (destination address, source address, IP protocol, source 186 port, destination port, and differentiated services (DiffServ) code 187 point (DSCP). General background on the use of IP headers, and 188 5-tuples, to identify flows and support Quality of Service (QoS) can 189 be found in [RFC3670]. [RFC7657] also provides useful background on 190 the delivery of DiffServ and "tuple" based flow identification. 192 The DetNet IP data plane also allows for optional matching on two 193 additional data fields. The optional fields are the ECN Field, as in 194 [RFC3168], and the IPv6 flow label field, as defined in [RFC8200]. 196 Generally the fields used in flow identification are forward 197 unmodified but modification is allowed, for example to a DSCP value, 198 when required by the DetNet service. 200 DetNet flow aggregation may be enabled via the use of wildcards, 201 masks, lists, prefixes and ranges. IP tunnels may also be used to 202 support flow aggregation. In these cases, it is expected that DetNet 203 aware intermediate nodes will provide DetNet service assurance on the 204 aggregate through resource allocation and congestion control 205 mechanisms. 207 DetNet IP Relay Relay DetNet IP 208 End System Node Node End System 210 +----------+ +----------+ 211 | Appl. |<------------ End to End Service ----------->| Appl. | 212 +----------+ ............ ........... +----------+ 213 | Service |<-: Service :-- DetNet flow --: Service :->| Service | 214 +----------+ +----------+ +----------+ +----------+ 215 |Forwarding| |Forwarding| |Forwarding| |Forwarding| 216 +--------.-+ +-.------.-+ +-.---.----+ +-------.--+ 217 : Link : \ ,-----. / \ ,-----. / 218 +......+ +----[ Sub ]----+ +-[ Sub ]-+ 219 [Network] [Network] 220 `-----' `-----' 222 |<--------------------- DetNet IP --------------------->| 224 Figure 1: A Simple DetNet (DN) Enabled IP Network 226 Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled 227 end systems originate IP encapsulated traffic that is identified as 228 DetNet flows, relay nodes understand the forwarding requirements of 229 the DetNet flow and ensure that node, interface and sub-network 230 resources are allocated to ensure DetNet service requirements. The 231 dotted line around the Service component of the Relay Nodes indicates 232 that the transit routers are DetNet service aware but do not perform 233 any DetNet service sub-layer function, e.g., PREOF. IEEE 802.1 TSN 234 is an example sub-network type which can provide support for DetNet 235 flows and service. 237 Note: The sub-network can represent a TSN, MPLS or IP network 238 segment. 240 IP Edge Edge IP 241 End System Node Node End System 243 +----------+ +.........+ +.........+ +----------+ 244 | Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. | 245 +----------+ +.........+ +.........+ +----------+ 246 | IP |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->| IP | 247 +----------+ +---+ +---+ +---+ +---+ +----------+ 248 |Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding| 249 +--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ 250 : Link : \ ,-----. / / ,-----. \ 251 +.......+ +----[ Sub ]----+ +--[ Sub ]--+ 252 [Network] [Network] 253 `-----' `-----' 255 |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->| 257 Figure 2: Non-DetNet aware IP end systems with DetNet IP Domain 259 Figure 2 illustrates a variant of Figure 1 where the end systems are 260 not DetNet aware. In this case, edge nodes sit at the boundary of 261 the DetNet domain and provide DetNet service proxies for the end 262 applications by initiating and terminating DetNet service for the 263 application's IP flows. The existing header information or an 264 approach such as described in Section 4.4 can be used to support 265 DetNet flow identification. 267 Note, that Figure 1 and Figure 2 can be combined, so IP DetNet End 268 Systems can communicate over DetNet IP network with IP End System. 270 Non-DetNet and DetNet IP packets are identical on the wire. From 271 data plane perspective, the only difference is that there is flow- 272 associated DetNet information on each DetNet node that defines the 273 flow related characteristics and required forwarding behavior. As 274 shown above, edge nodes provide a Service Proxy function that 275 "associates" one or more IP flows with the appropriate DetNet flow- 276 specific information and ensures that the receives the proper traffic 277 treatment within the domain. 279 Note: The operation of IEEE802.1 TSN end systems over DetNet enabled 280 IP networks is not described in this document. TSN over MPLS is 281 discribed in [I-D.ietf-detnet-tsn-vpn-over-mpls]. 283 4. DetNet IP Data Plane Considerations 285 This section provides informative considerations related to providing 286 DetNet service to flows which are identified based on their header 287 information. 289 4.1. End-System Specific Considerations 291 Data-flows requiring DetNet service are generated and terminated on 292 end systems. This document deals only with IP end systems. The 293 protocols used by an IP end system are specific to an application and 294 end systems peer with end systems using the same application 295 encapsulation format. This said, DetNet's use of 6-tuple IP flow 296 identification means that DetNet must be aware of not only the format 297 of the IP header, but also of the next protocol carried within an IP 298 packet. 300 When IP end systems are DetNet aware, no application-level or 301 service-level proxy functions are needed inside the DetNet domain. 302 For DetNet unaware IP end systems service-level proxy functions are 303 needed inside the DetNet domain. 305 End systems need to ensure that DetNet service requirements are met 306 when processing packets associated with a DetNet flow. When 307 forwarding packets, this means that packets are appropriately shaped 308 on transmission and received appropriate traffic treatment on the 309 connected sub-network, see Section 4.3.2 and Section 4.2 for more 310 details. When receiving packets, this means that there are 311 appropriate local node resources, e.g., buffers, to receive and 312 process a DetNet flow packets. 314 In order to maximize reuse of 5-tuple based mechanisms, e.g, 315 traceroute, DetNet aware applications and end systems SHOULD NOT mix 316 DetNet and non-DetNet traffic within a single 5-tuple. 318 4.2. DetNet Domain-Specific Considerations 320 As a general rule, DetNet IP domains need to be able to forward any 321 DetNet flow identified by the IP 6-tuple. Doing otherwise would 322 limit end system encapsulation format. From a practical standpoint 323 this means that all nodes along the end-to-end path of DetNet flows 324 need to agree on what fields are used for flow identification, and 325 the transport protocols (e.g., TCP/UDP/IPsec) which can be used to 326 identify 6-tuple protocol ports. 328 From a connection type perspective two scenarios are identified: 330 1. DN attached: end system is directly connected to an edge node or 331 end system is behind a sub-network. (See ES1 and ES2 in figure 332 below) 334 2. DN integrated: end system is part of the DetNet domain. (See ES3 335 in figure below) 337 L3 (IP) end systems may use any of these connection types. A DetNet 338 domain allows communication between any end-systems using the same 339 encapsulation format, independent of their connection type and DetNet 340 capability. DN attached end systems have no knowledge about the 341 DetNet domain and its encapsulation format. See Figure 3 for L3 end 342 system connection examples. 344 ____+----+ 345 +----+ _____ / | ES3| 346 | ES1|____ / \__/ +----+___ 347 +----+ \ / \ 348 + | 349 ____ \ _/ 350 +----+ __/ \ +__ DetNet IP domain / 351 | ES2|____/ L2/L3 |___/ \ __ __/ 352 +----+ \_______/ \_______/ \___/ 354 Figure 3: Connection types of L3 end systems 356 Within a DetNet domain, the DetNet enabled IP Routers are 357 interconnected by links and sub-networks to support end-to-end 358 delivery of DetNet flows. From a DetNet architecture perspective, 359 these routers are DetNet relays, as they must be DetNet service 360 aware. Such routers identify DetNet flows based on the IP 6-tuple, 361 and ensure that the DetNet service required traffic treatment is 362 provided both on the node and on any attached sub-network. 364 This solution provides DetNet functions end to end, but does so on a 365 per link and sub-network basis. Congestion protection and latency 366 control and the resource allocation (queuing, policing, shaping) are 367 supported using the underlying link / sub net specific mechanisms. 368 However, service protections (packet replication and packet 369 elimination functions) are not provided at the DetNet layer end to 370 end. Instead service protection can be provided on a per underlying 371 L2 link and sub-network basis. 373 The DetNet Service Flow is mapped to the link / sub-network specific 374 resources using an underlying system specific means. This implies 375 each DetNet aware node on path looks into the forwarded DetNet 376 Service Flow packet and utilize e.g., a 6-tuple to find out the 377 required mapping within a node. 379 As noted earlier, the Service Protection is done within each link / 380 sub-network independently using the domain specific mechanisms (due 381 the lack of a unified end to end sequencing information that would be 382 available for intermediate nodes). Therefore, service protection (if 383 enabled) cannot be provided end-to-end, only within sub-networks. 384 This is shown for a three sub-network scenario in Figure 4, where 385 each sub-network can provide service protection between its borders. 386 "R" and "E" denotes replication and elimination points within the 387 sub-network. 389 <-------------------- DenNet IP ------------------------> 390 ______ 391 ____ / \__ 392 ____ / \__/ \___ ______ 393 +----+ __/ +====+ +==+ \ +----+ 394 |src |__/ SubN1 ) | | \ SubN3 \____| dst| 395 +----+ \_______/ \ Sub-Network2 | \______/ +----+ 396 \_ _/ 397 \ __ __/ 398 \_______/ \___/ 400 +---+ +---------E--------+ +-----+ 401 +----+ | | | | | | | +----+ 402 |src |----R E--------R +---+ E------R E------+ dst| 403 +----+ | | | | | | | +----+ 404 +---+ +-----R------------+ +-----+ 406 Figure 4: Replication and elimination in sub-networks for DetNet IP 407 networks 409 If end to end service protection is desired, it can be implemented, 410 for example, by the DetNet end systems using Layer-4 (L4) transport 411 protocols or application protocols. However, these protocols are out 412 of scope of this document. 414 Note that not mixing DetNet and non-DetNet traffic within a single 415 5-tuple, as described above, enables simpler 5-tuple filters to be 416 reused at the edges of a DetNet network to prevent non-congestion 417 responsive DetNet traffic from escaping the DetNet domain. 419 4.3. Forwarding Sub-Layer Considerations 421 4.3.1. Class of Service 423 Class of Service (CoS) for DetNet flows carried in IPv6 is provided 424 using the standard differentiated services code point (DSCP) field 425 [RFC2474] and related mechanisms. The 2-bit explicit congestion 426 notification (ECN) [RFC3168] field MAY also be used. 428 One additional consideration for DetNet nodes which support CoS 429 services is that they MUST ensure that the CoS service classes do not 430 impact the congestion protection and latency control mechanisms used 431 to provide DetNet QoS. This requirement is similar to requirement 432 for MPLS LSRs to that CoS LSPs do not impact the resources allocated 433 to TE LSPs via [RFC3473]. 435 4.3.2. Quality of Service 437 Quality of Service (QoS) for DetNet service flows carried in IP MUST 438 be provided locally by the DetNet-aware hosts and routers supporting 439 DetNet flows. Such support leverages the underlying network layer 440 such as 802.1 TSN. The traffic control mechanisms used to deliver 441 QoS for IP encapsulated DetNet flows are expected to be defined in a 442 future document. From an encapsulation perspective, the combination 443 of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and 444 previously mentioned two optional fields, uniquely identifies a 445 DetNet service flow. 447 Packets that are marked with a DetNet Class of Service value, but 448 that have not been the subject of a completed reservation, can 449 disrupt the QoS offered to properly reserved DetNet flows by using 450 resources allocated to the reserved flows. Therefore, the network 451 nodes of a DetNet network must: 453 o Defend the DetNet QoS by discarding or remarking (to a non-DetNet 454 CoS) packets received that are not the subject of a completed 455 reservation. 457 o Not use a DetNet reserved resource, e.g. a queue or shaper 458 reserved for DetNet flows, for any packet that does not carry a 459 DetNet Class of Service marker. 461 4.3.3. Path Selection 463 While path selection algorithms and mechanisms are out of scope of 464 the DetNet data plane definition, it is important to highlight the 465 implications of DetNet IP flow identification on path selection and 466 next hops. As mentioned above, the DetNet IP data plane identifies 467 flows using "6-tuple" header information as well as two additional 468 optional header fields. DetNet generally allows for both flow- 469 specific traffic treatment and flow-specific next-hops. 471 In non-DetNet IP forwarding, it is generally assumed that the same 472 series of next hops, i.e., the same path, will be used for a 473 particular 5-tuple or, in some cases, e.g., [RFC5120], for a 474 particular 6-tuple. Using different next hops for different 5-tuples 475 does not take any special consideration for DetNet aware 476 applications. 478 Care should be taken when using different next hops for the same 479 5-tuple. As discussed in [RFC7657], unexpected behavior can occur 480 when a single 5-tuple application flow experience reordering due to 481 being split across multiple next hops. Understanding of the 482 application and transport protocol impact of using different next 483 hops for the same 6-tuple is required. Again, this impacts path 484 selection for DetNet flows and this document only indirectly. 486 4.4. DetNet Flow Aggregation 488 As described in [I-D.ietf-detnet-data-plane-framework], the ability 489 to aggregate individual flows, and their associated resource control, 490 into a larger aggregate is an important technique for improving 491 scaling by reducing the state per hop. DetNet IP data plane 492 aggregation can take place within a single node, when that node 493 maintains state about both the aggregated and individual flows. It 494 can also take place between nodes, where one node maintains state 495 about only flow aggregates while the other node maintains state on 496 all or a portion of the component flows. In either case, the 497 management or control function that provisions the aggregate flows 498 must ensure that adequate resources are allocated and configured to 499 provide combined service requirements of the individual flows. As 500 DetNet is concerned about latency and jitter, more than just 501 bandwidth needs to be considered. 503 From a single node perspective, the aggregation of IP flows impacts 504 DetNet IP data plane flow identification and resource allocation. As 505 discussed above, IP flow identification uses the IP "6-tuple" for 506 flow identification. DetNet IP flows can be aggregated using any of 507 the 6-tuple, or two additional optional fields defined in 508 Section 5.1. The use of prefixes, wildcards, lists, and value ranges 509 allows a DetNet node to identify aggregate DetNet flows. From a 510 resource allocation perspective, DetNet nodes must provide service to 511 a aggregate and not on a component flow basis. 513 It is the responsibility of the DetNet controller plane to properly 514 provision the use of these aggregation mechanisms. This includes 515 ensuring that aggregated flows have compatible e.g., the same or very 516 similar QoS and/or CoS characteristics, see Section 4.3.2. It also 517 includes ensuring that per component-flow service requirements are 518 satisfied by the aggregate, see Section 5.3. 520 4.5. Bidirectional Traffic 522 While the DetNet IP data plane must support bidirectional DetNet 523 flows, there are no special bidirectional features with respect to 524 the data plane other than the need for the two directions of a co- 525 routed bidirectional flow to take the same path. That is to say that 526 bidirectional DetNet flows are solely represented at the management 527 and control plane levels, without specific support or knowledge 528 within the DetNet data plane. Fate sharing and associated or co- 529 routed bidirectional flows can be managed at the control level. 531 Control and management mechanisms need to support bidirectional 532 flows, but the specification of such mechanisms are out of scope of 533 this document. An example control plane solution for MPLS can be 534 found in [RFC7551]. 536 5. DetNet IP Data Plane Procedures 538 This section provides DetNet IP data plane procedures. These 539 procedures have been divided into the following areas: flow 540 identification, forwarding and traffic treatment. Flow 541 identification includes those procedures related to matching IP and 542 higher layer protocol header information to DetNet flow (state) 543 information and service requirements. Flow identification is also 544 sometimes called Traffic classification, for example see [RFC5777]. 545 Forwarding includes those procedures related to next hop selection 546 and delivery. Traffic treatment includes those procedures related to 547 providing an identified flow with the required DetNet service. 549 DetNet IP data plane establishment and operational procedures also 550 have requirements on the control and management systems for DetNet 551 flows and these are referred in this section. Specifically this 552 section identifies a number of information elements that require 553 support via the management and control interfaces supported by a 554 DetNet node. The specific mechanism used for such support is out of 555 the scope of this document. A summary of the requirements for 556 management and control related information is included. Conformance 557 language is not used in the summary since applies to future 558 mechanisms such as those that may be provided in YANG models 559 [I-D.ietf-detnet-yang]. 561 5.1. DetNet IP Flow Identification Procedures 563 IP and higher layer protocol header information is used to identify 564 DetNet flows. All DetNet implementations that support this document 565 MUST identify individual DetNet flows based on the set of information 566 identified in this section. Note, that additional flow 567 identification requirements, e.g., to support other higher layer 568 protocols, may be defined in future. 570 The configuration and control information used to identify an 571 individual DetNet flow MUST be ordered by an implementation. 572 Implementations MUST support a fixed order when identifying flows, 573 and MUST identify a DetNet flow by the first set of matching flow 574 information. 576 Implementations of this document MUST support DetNet flow 577 identification when the implementation is acting as a DetNet end 578 systems, a relay node or as an edge node. 580 5.1.1. IP Header Information 582 Implementations of this document MUST support DetNet flow 583 identification based on IP header information. The IPv4 header is 584 defined in [RFC0791] and the IPv6 is defined in [RFC8200]. 586 5.1.1.1. Source Address Field 588 Implementations of this document MUST support DetNet flow 589 identification based on the Source Address field of an IP packet. 590 Implementations SHOULD support longest prefix matching for this 591 field, see [RFC1812] and [RFC7608]. Note that a prefix length of 592 zero (0) effectively means that the field is ignored. 594 5.1.1.2. Destination Address Field 596 Implementations of this document MUST support DetNet flow 597 identification based on the Destination Address field of an IP 598 packet. Implementations SHOULD support longest prefix matching for 599 this field, see [RFC1812] and [RFC7608]. Note that a prefix length 600 of zero (0) effectively means that the field is ignored. 602 Note: any IP address value is allowed, including an IP multicast 603 destination address. 605 5.1.1.3. IPv4 Protocol and IPv6 Next Header Fields 607 Implementations of this document MUST support DetNet flow 608 identification based on the IPv4 Protocol field when processing IPv4 609 packets, and the IPv6 Next Header Field when processing IPv6 packets. 610 An implementation MUST support flow identification based based the 611 next protocol values defined in Section 5.1.2. Other, non-zero 612 values, MUST be used for flow identification. Implementations SHOULD 613 allow for these fields to be ignored for a specific DetNet flow. 615 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields 617 These fields are used to support Differentiated Services [RFC2474] 618 and Explicit Congestion Notification [RFC3168]. Implementations of 619 this document MUST support DetNet flow identification based on the 620 IPv4 Type of Service field when processing IPv4 packets, and the IPv6 621 Traffic Class Field when processing IPv6 packets. Implementations 622 MUST support list based matching of DSCP values, where the list is 623 composed of possible field values that are to be considered when 624 identifying a specific DetNet flow. Implementations SHOULD allow for 625 this field to be ignored for a specific DetNet flow. 627 Implementations of this document MUST allow the ECN field to be 628 ignored as part of DetNet flow identification. Additionally, 629 implementations SHOULD support identification of DetNet flows based 630 on the value carried in the ECN field. When this field is used to 631 identify a specific DetNet flow, implementations MUST support a list 632 of ECN values that match a specific slow. 634 5.1.1.5. IPv6 Flow Label Field 636 Implementations of this document SHOULD support identification of 637 DetNet flows based on the IPv6 Flow Label field. Implementations 638 that support matching based on this field MUST allow for this field 639 to be ignored for a specific DetNet flow. When this field is used to 640 identify a specific DetNet flow, implementations MAY exclude the IPv6 641 Next Header field and next header information as part of DetNet flow 642 identification. 644 5.1.2. Other Protocol Header Information 646 Implementations of this document MUST support DetNet flow 647 identification based on header information identified in this 648 section. Support for TCP, UDP and IPsec flows is defined. Future 649 documents are expected to define support for other protocols. 651 5.1.2.1. TCP and UDP 653 DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is 654 achieved based on the Source and Destination Port fields carried in 655 each protocol's header. These fields share a common format and 656 common DetNet flow identification procedures. 658 5.1.2.1.1. Source Port Field 660 Implementations of this document MUST support DetNet flow 661 identification based on the Source Port field of a TCP or UDP packet. 662 Implementations MUST support flow identification based on a 663 particular value carried in the field, i.e., an exact value. 664 Implementations SHOULD support range-based port matching. 665 Implementation MUST also allow for the field to be ignored for a 666 specific DetNet flow. 668 5.1.2.1.2. Destination Port Field 670 Implementations of this document MUST support DetNet flow 671 identification based on the Destination Port field of a TCP or UDP 672 packet. Implementations MUST support flow identification based on a 673 particular value carried in the field, i.e., an exact value. 674 Implementations SHOULD support range-based port matching. 675 Implementation MUST also allow for the field to be ignored for a 676 specific DetNet flow. 678 5.1.2.2. IPsec AH and ESP 680 IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security 681 Payload (ESP) [RFC4303] share a common format for the Security 682 Parameters Index (SPI) field. Implementations MUST support flow 683 identification based on a particular value carried in the field, 684 i.e., an exact value. Implementation SHOULD also allow for the field 685 to be ignored for a specific DetNet flow. 687 5.2. Forwarding Procedures 689 General requirements for IP nodes are defined in [RFC1122], [RFC1812] 690 and [RFC6434], and are not modified by this document. The typical 691 next-hop selection process is impacted by DetNet. Specifically, 692 implementations of this document SHALL use management and control 693 information to select the one or more outgoing interfaces and next 694 hops to be used for a packet belonging to a DetNet flow. 696 The use of multiple paths or links, e.g., ECMP, to support a single 697 DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet 698 flows within a DetNet domain. 700 The above implies that management and control functions will be 701 defined to support this requirement, e.g., see 702 [I-D.ietf-detnet-yang]. 704 5.3. DetNet IP Traffic Treatment Procedures 706 Implementations if this document MUST ensure that a DetNet flow 707 receives the traffic treatment that is provisioned for it via 708 configuration or the controller plane, e.g., via 709 [I-D.ietf-detnet-yang]. General information on DetNet service can be 710 found in [I-D.ietf-detnet-flow-information-model]. Typical 711 mechanisms used to provide different treatment to different flows 712 includes the allocation of system resources (such as queues and 713 buffers) and provisioning or related parameters (such as shaping, and 714 policing). Support can also be provided via an underlying network 715 technology such as MPLS [I-D.ietf-detnet-ip-over-mpls]. and 716 IEEE802.1 TSN [I-D.ietf-detnet-ip-over-tsn]. Other than in the TSN 717 case, the specific mechanisms used by a DetNet node to ensure DetNet 718 service delivery requirements are met for supported DetNet flows is 719 outside the scope of this document. 721 6. Management and Control Information Summary 723 The following summarizes the set of information that is needed to 724 identify individual and aggregated DetNet flows: 726 o IPv4 and IPv6 source address field. 728 o IPv4 and IPv6 source address prefix length, where a zero (0) value 729 effectively means that the address field is ignored. 731 o IPv4 and IPv6 destination address field. 733 o IPv4 and IPv6 destination address prefix length, where a zero (0) 734 effectively means that the address field is ignored. 736 o IPv4 protocol field. A limited set of values is allowed, and the 737 ability to ignore this field, e.g., via configuration of the value 738 zero (0), is desirable. 740 o IPv6 next header field. A limited set of values is allowed, and 741 the ability to ignore this field, e.g., via configuration of the 742 value zero (0), is desirable. 744 o For the IPv4 Type of Service and IPv6 Traffic Class Fields: 746 * If the DSCP field is to be used in flow identification. 747 Ignoring the DSCP filed is optional. 749 * When the DSCP field is used in flow identification, a list of 750 field values that may be used by a specific flow. 752 * If the ECN field is to be used in flow identification. 753 Matching based on ECN filed values is optional. 755 * When ECN field is used in flow identification, a list of field 756 values that may be used by a specific flow. 758 o IPv6 flow label field. This field can be optionally used for 759 matching. When used, can be exclusive of matching against the 760 next header field. 762 o TCP and UDP Source Port. Exact and wildcard matching is required. 763 Port ranges can optionally be used. 765 o TCP and UDP Destination Port. Exact and wildcard matching is 766 required. Port ranges can optionally be used. 768 o IPsec Header SPI field. Exact matching is required. 770 This information MUST be provisioned per DetNet flow via 771 configuration, e.g., via the controller or management plane. 773 Information identifying a DetNet flow is ordered and implementations 774 use the first match. This can, for example, be used to provide a 775 DetNet service for a specific UDP flow, with unique Source and 776 Destination Port field values, while providing a different service 777 for the aggregate of all other flows with that same UDP Destination 778 Port value. 780 It is the responsibility of the DetNet controller plane to properly 781 provision both flow identification information and the flow specific 782 resources needed to provided the traffic treatment needed to meet 783 each flow's service requirements. This applies for aggregated and 784 individual flows. 786 7. Security Considerations 788 Security considerations for DetNet are described in detail in 789 [I-D.ietf-detnet-security]. General security considerations are 790 described in [I-D.ietf-detnet-architecture]. This section considers 791 exclusively security considerations which are specific to the DetNet 792 IP data plane. 794 Security aspects which are unique to DetNet are those whose aim is to 795 provide the specific quality of service aspects of DetNet, which are 796 primarily to deliver data flows with extremely low packet loss rates 797 and bounded end-to-end delivery latency. 799 The primary considerations for the data plane is to maintain 800 integrity of data and delivery of the associated DetNet service 801 traversing the DetNet network. Application flows can be protected 802 through whatever means is provided by the underlying technology. For 803 example, encryption may be used, such as that provided by IPSec 804 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 805 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 807 From a data plane perspective this document does not add or modify 808 any header information. 810 At the management and control level DetNet flows are identified on a 811 per-flow basis, which may provide controller plane attackers with 812 additional information about the data flows (when compared to 813 controller planes that do not include per-flow identification). This 814 is an inherent property of DetNet which has security implications 815 that should be considered when determining if DetNet is a suitable 816 technology for any given use case. 818 To provide uninterrupted availability of the DetNet service, 819 provisions can be made against DOS attacks and delay attacks. To 820 protect against DOS attacks, excess traffic due to malicious or 821 malfunctioning devices can be prevented or mitigated, for example 822 through the use of existing mechanism such as policing and shaping 823 applied at the input of a DetNet domain. To prevent DetNet packets 824 from being delayed by an entity external to a DetNet domain, DetNet 825 technology definition can allow for the mitigation of Man-In-The- 826 Middle attacks, for example through use of authentication and 827 authorization of devices within the DetNet domain. 829 8. IANA Considerations 831 This document does not require an action from IANA. 833 9. Acknowledgements 835 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 836 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 837 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 838 Bernardos for their various contributions to this work. 840 10. References 842 10.1. Normative references 844 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 845 DOI 10.17487/RFC0768, August 1980, 846 . 848 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 849 DOI 10.17487/RFC0791, September 1981, 850 . 852 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 853 RFC 793, DOI 10.17487/RFC0793, September 1981, 854 . 856 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 857 RFC 1812, DOI 10.17487/RFC1812, June 1995, 858 . 860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 861 Requirement Levels", BCP 14, RFC 2119, 862 DOI 10.17487/RFC2119, March 1997, 863 . 865 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 866 "Definition of the Differentiated Services Field (DS 867 Field) in the IPv4 and IPv6 Headers", RFC 2474, 868 DOI 10.17487/RFC2474, December 1998, 869 . 871 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 872 of Explicit Congestion Notification (ECN) to IP", 873 RFC 3168, DOI 10.17487/RFC3168, September 2001, 874 . 876 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 877 Switching (GMPLS) Signaling Resource ReserVation Protocol- 878 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 879 DOI 10.17487/RFC3473, January 2003, 880 . 882 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 883 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 884 December 2005, . 886 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 887 DOI 10.17487/RFC4302, December 2005, 888 . 890 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 891 RFC 4303, DOI 10.17487/RFC4303, December 2005, 892 . 894 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 895 Length Recommendation for Forwarding", BCP 198, RFC 7608, 896 DOI 10.17487/RFC7608, July 2015, 897 . 899 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 900 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 901 May 2017, . 903 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 904 (IPv6) Specification", STD 86, RFC 8200, 905 DOI 10.17487/RFC8200, July 2017, 906 . 908 10.2. Informative references 910 [I-D.ietf-detnet-architecture] 911 Finn, N., Thubert, P., Varga, B., and J. Farkas, 912 "Deterministic Networking Architecture", draft-ietf- 913 detnet-architecture-13 (work in progress), May 2019. 915 [I-D.ietf-detnet-data-plane-framework] 916 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 917 Bryant, S., and J. Korhonen, "DetNet Data Plane 918 Framework", draft-ietf-detnet-data-plane-framework-02 919 (work in progress), September 2019. 921 [I-D.ietf-detnet-dp-sol-mpls] 922 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 923 Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in 924 progress), March 2019. 926 [I-D.ietf-detnet-flow-information-model] 927 Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D. 928 Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- 929 flow-information-model-05 (work in progress), September 930 2019. 932 [I-D.ietf-detnet-ip-over-mpls] 933 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 934 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over 935 MPLS", draft-ietf-detnet-ip-over-mpls-01 (work in 936 progress), July 2019. 938 [I-D.ietf-detnet-ip-over-tsn] 939 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 940 Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time 941 Sensitive Networking (TSN)", draft-ietf-detnet-ip-over- 942 tsn-00 (work in progress), May 2019. 944 [I-D.ietf-detnet-security] 945 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 946 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 947 Networking (DetNet) Security Considerations", draft-ietf- 948 detnet-security-05 (work in progress), August 2019. 950 [I-D.ietf-detnet-tsn-vpn-over-mpls] 951 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 952 Korhonen, "DetNet Data Plane: IEEE 802.1 Time Sensitive 953 Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- 954 mpls-00 (work in progress), May 2019. 956 [I-D.ietf-detnet-yang] 957 Geng, X., Chen, M., Ryoo, Y., Li, Z., and R. Rahman, 958 "Deterministic Networking (DetNet) Configuration YANG 959 Model", draft-ietf-detnet-yang-03 (work in progress), July 960 2019. 962 [IEEE802.1AE-2018] 963 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 964 Security (MACsec)", 2018, 965 . 967 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 968 Communication Layers", STD 3, RFC 1122, 969 DOI 10.17487/RFC1122, October 1989, 970 . 972 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 973 Informal Management Model for Diffserv Routers", RFC 3290, 974 DOI 10.17487/RFC3290, May 2002, 975 . 977 [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and 978 W. Weiss, "Information Model for Describing Network Device 979 QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, 980 January 2004, . 982 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 983 Topology (MT) Routing in Intermediate System to 984 Intermediate Systems (IS-ISs)", RFC 5120, 985 DOI 10.17487/RFC5120, February 2008, 986 . 988 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 989 Ed., and A. Lior, "Traffic Classification and Quality of 990 Service (QoS) Attributes for Diameter", RFC 5777, 991 DOI 10.17487/RFC5777, February 2010, 992 . 994 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 995 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 996 2011, . 998 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 999 Extensions for Associated Bidirectional Label Switched 1000 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1001 . 1003 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 1004 (Diffserv) and Real-Time Communication", RFC 7657, 1005 DOI 10.17487/RFC7657, November 2015, 1006 . 1008 Authors' Addresses 1010 Balazs Varga (editor) 1011 Ericsson 1012 Magyar Tudosok krt. 11. 1013 Budapest 1117 1014 Hungary 1016 Email: balazs.a.varga@ericsson.com 1018 Janos Farkas 1019 Ericsson 1020 Magyar Tudosok krt. 11. 1021 Budapest 1117 1022 Hungary 1024 Email: janos.farkas@ericsson.com 1026 Lou Berger 1027 LabN Consulting, L.L.C. 1029 Email: lberger@labn.net 1031 Don Fedyk 1032 LabN Consulting, L.L.C. 1034 Email: dfedyk@labn.net 1036 Andrew G. Malis 1037 Independent 1039 Email: agmalis@gmail.com 1040 Stewart Bryant 1041 Futurewei Technologies 1043 Email: stewart.bryant@gmail.com 1045 Jouni Korhonen 1047 Email: jouni.nospam@gmail.com