idnits 2.17.1 draft-ietf-detnet-ip-03.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 27, 2019) is 1635 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 251, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 2475 == 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 (-13) exists of draft-ietf-detnet-mpls-01 == 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: 2 errors (**), 0 flaws (~~), 10 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 29, 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 27, 2019 15 DetNet Data Plane: IP 16 draft-ietf-detnet-ip-03 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 29, 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 . . . . . . . . . . . . . . . . . 19 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 as two sub-layers: functions into two sub-layers: a service 105 sub-layer and a forwarding sub-layer. The service sub-layer is used 106 to provide DetNet service protection (e.g., by packet replication and 107 packet elimination functions) and reordering. The forwarding sub- 108 layer is used to provides congestion protection (low loss, assured 109 latency, and limited out-of-order delivery). The service sub-layer 110 generally requires additional fields to provide its service; for 111 example see [I-D.ietf-detnet-mpls]. Since no DetNet-specific fields 112 are added to support DetNet IP flows, only the forwarding sub-layer 113 functions are supported using the DetNet IP defined by this document. 114 Service protection can be provided on a per sub-net basis using 115 technologies such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet 116 as specified in the IEEE 802.1 TSN task group(referred to in this 117 document simply as IEEE802.1 TSN). 119 This document provides an overview of the DetNet IP data plane in 120 Section 3, considerations that apply to providing DetNet services via 121 the DetNet IP data plane in Section 4. Section 5 provides the 122 procedures for hosts and routers that support IP-based DetNet 123 services. Section 6 summarizes the set of information that is needed 124 to identify an individual DetNet flow. 126 2. Terminology 128 2.1. Terms Used In This Document 130 This document uses the terminology and concepts established in the 131 DetNet architecture [I-D.ietf-detnet-architecture], and the reader is 132 assumed to be familiar with that document and its terminology. 134 2.2. Abbreviations 136 The following abbreviations used in this document: 138 CoS Class of Service. 140 DetNet Deterministic Networking. 142 DN DetNet. 144 DiffServ Differentiated Services 145 DSCP Differentiated Services Code Point 147 L2 Layer-2. 149 L3 Layer-3. 151 LSP Label-switched path. 153 MPLS Multiprotocol Label Switching. 155 PREOF Packet Replication, Elimination and Ordering 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, to identify DetNet flows and provide a DetNet service 174 using an IP data plane. From a data plane perspective, an end-to-end 175 IP model is followed. As mentioned above, existing IP and higher 176 layer protocol header information is used to support flow 177 identification and DetNet service delivery. Common data plane 178 procedures and control information for all DetNet data planes can be 179 found in the [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 the 193 IPv6 flow label field, as defined in [RFC8200]. 195 Non-DetNet and DetNet IP packets are identical on the wire. 196 Generally the fields used in flow identification are forwarded 197 unmodified, however modification of these fields is allowed, for 198 example to a DSCP value, 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 203 DetNet-aware intermediate nodes will provide DetNet service 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 those are identified 228 within the DetNet domain as DetNet flows, relay nodes understand the 229 forwarding requirements of the DetNet flow and ensure that node, 230 interface and sub-network resources are allocated to ensure DetNet 231 service requirements. The dotted line around the Service component 232 of the Relay Nodes indicates that the transit routers are DetNet 233 service aware but do not perform any DetNet service sub-layer 234 function, e.g., PREOF. 236 Note: The sub-network can represent a TSN, MPLS or IP network 237 segment. 239 IP Edge Edge IP 240 End System Node Node End System 242 +----------+ +.........+ +.........+ +----------+ 243 | Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. | 244 +----------+ +.........+ +.........+ +----------+ 245 | IP |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->| IP | 246 +----------+ +---+ +---+ +---+ +---+ +----------+ 247 |Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding| 248 +--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ 249 : Link : \ ,-----. / / ,-----. \ 250 +.......+ +----[ Sub ]----+ +--[ Sub ]--+ 251 [Network] [Network] 252 `-----' `-----' 254 |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->| 256 Figure 2: Non-DetNet-aware IP end systems with DetNet IP Domain 258 Figure 2 illustrates a variant of Figure 1 where the end systems are 259 not DetNet aware. In this case, edge nodes sit at the boundary of 260 the DetNet domain and provide DetNet service proxies for the end 261 applications by initiating and terminating DetNet service for the 262 application's IP flows. The existing header information or an 263 approach such as described in Section 4.4 can be used to support 264 DetNet flow identification. 266 Note, that Figure 1 and Figure 2 can be collapsed, so IP DetNet End 267 Systems can communicate over DetNet IP network with IP End System. 269 As non-DetNet and DetNet IP packets are identical on the wire, from 270 data plane perspective, the only difference is that there is flow- 271 associated DetNet information on each DetNet node that defines the 272 flow related characteristics and required forwarding behavior. As 273 shown above, edge nodes provide a Service Proxy function that 274 "associates" one or more IP flows with the appropriate DetNet flow- 275 specific information and ensures that the receives the proper traffic 276 treatment within the domain. 278 Note: The operation of IEEE802.1 TSN end systems over DetNet enabled 279 IP networks is not described in this document. TSN over MPLS is 280 discribed in [I-D.ietf-detnet-tsn-vpn-over-mpls]. 282 4. DetNet IP Data Plane Considerations 284 This section provides informative considerations related to providing 285 DetNet service to flows which are identified based on their header 286 information. 288 4.1. End-system-specific Considerations 290 Data-flows requiring DetNet service are generated and terminated on 291 end systems. This document deals only with IP end systems. The 292 protocols used by an IP end system are specific to an application, 293 and end systems peer with other end systems. DetNet's use of 6-tuple 294 IP flow identification means that DetNet must be aware of not only 295 the format of the IP header, but also of the next protocol carried 296 within an IP packet (see Section 5.1.1.3). 298 When IP end systems are DetNet-aware, no application-level or 299 service-level proxy functions are needed inside the DetNet domain. 300 For DetNet unaware IP end systems service-level proxy functions are 301 needed inside the DetNet domain. 303 End systems need to ensure that DetNet service requirements are met 304 when processing packets associated to a DetNet flow. When forwarding 305 packets, this means that packets are appropriately shaped on 306 transmission and receive appropriate traffic treatment on the 307 connected sub-network, see Section 4.3.2 and Section 4.2 for more 308 details. When receiving packets, this means that there are 309 appropriate local node resources, e.g., buffers, to receive and 310 process the packets of that DetNet flow. 312 In order to maximize reuse of 5-tuple based mechanisms, e.g, 313 traceroute, DetNet-aware applications and end systems SHOULD NOT mix 314 DetNet and non-DetNet traffic within a single 5-tuple. 316 4.2. DetNet Domain-Specific Considerations 318 As a general rule, DetNet IP domains need to be able to forward any 319 DetNet flow identified by the IP 6-tuple. Doing otherwise would 320 limit the number of 6-tuple flow ID combinations that could be used 321 by the end systems. From a practical standpoint this means that all 322 nodes along the end-to-end path of DetNet flows need to agree on what 323 fields are used for flow identification, and the transport protocols 324 (e.g., TCP/UDP/IPsec) which can be used to identify 6-tuple protocol 325 ports. 327 From a connection type perspective two scenarios are identified: 329 1. DN attached: the end system is directly connected to an edge 330 node, or the end system is behind a sub-network (See ES1 and ES2 331 in figure below) 333 2. DN integrated: the end system is part of the DetNet domain. (See 334 ES3 in figure below) 336 L3 (IP) end systems may use any of these connection types. A DetNet 337 domain allows communication between any end-systems using the same 338 encapsulation format, independent of their connection type and DetNet 339 capability. DN attached end systems have no knowledge about the 340 DetNet domain and its encapsulation format. See Figure 3 for L3 end 341 system connection examples. 343 ____+----+ 344 +----+ _____ / | ES3| 345 | ES1|____ / \__/ +----+___ 346 +----+ \ / \ 347 + | 348 ____ \ _/ 349 +----+ __/ \ +__ DetNet IP domain / 350 | ES2|____/ L2/L3 |___/ \ __ __/ 351 +----+ \_______/ \_______/ \___/ 353 Figure 3: Connection types of L3 end systems 355 Within a DetNet domain, the DetNet-enabled IP Routers are 356 interconnected by links and sub-networks to support end-to-end 357 delivery of DetNet flows. From a DetNet architecture perspective, 358 these routers are DetNet relays, as they must be DetNet service 359 aware. Such routers identify DetNet flows based on the IP 6-tuple, 360 and ensure that the DetNet service required traffic treatment is 361 provided both on the node and on any attached sub-network. 363 This solution provides DetNet functions end to end, but does so on a 364 per link and sub-network basis. Congestion protection and latency 365 control and the resource allocation (queuing, policing, shaping) are 366 supported using the underlying link / sub net specific mechanisms. 367 However, service protection (packet replication and packet 368 elimination functions) is not provided at the DetNet layer end to 369 end. Instead service protection can be provided on a per underlying 370 L2 link and sub-network basis. 372 The DetNet Service Flow is mapped to the link / sub-network specific 373 resources using an underlying system-specific means. This implies 374 each DetNet-aware node on path looks into the forwarded DetNet 375 Service Flow packet and utilize e.g., a 6-tuple to find out the 376 required mapping within a node. 378 As noted earlier, service protection must be implemented within each 379 link / sub-network independently, using the domain specific 380 mechanisms. This is due to the lack of unified end-to-end sequencing 381 information that could be used by the intermediate nodes. Therefore, 382 service protection (if enabled) cannot be provided end-to-end, only 383 within sub-networks. This is shown for a three sub-network scenario 384 in Figure 4, where each sub-network can provide service protection 385 between its borders. "R" and "E" denotes replication and elimination 386 points within the sub-network. 388 <-------------------- DenNet IP ------------------------> 389 ______ 390 ____ / \__ 391 ____ / \__/ \___ ______ 392 +----+ __/ +====+ +==+ \ +----+ 393 |src |__/ SubN1 ) | | \ SubN3 \____| dst| 394 +----+ \_______/ \ Sub-Network2 | \______/ +----+ 395 \_ _/ 396 \ __ __/ 397 \_______/ \___/ 399 +---+ +---------E--------+ +-----+ 400 +----+ | | | | | | | +----+ 401 |src |----R E--------R +---+ E------R E------+ dst| 402 +----+ | | | | | | | +----+ 403 +---+ +-----R------------+ +-----+ 405 Figure 4: Replication and elimination in sub-networks for DetNet IP 406 networks 408 If end to end service protection is desired, it can be implemented, 409 for example, by the DetNet end systems using Layer-4 (L4) transport 410 protocols or application protocols. However, these protocols are out 411 of scope of this document. 413 Note that not mixing DetNet and non-DetNet traffic within a single 414 5-tuple, as described above, enables simpler 5-tuple filters to be 415 used (or re-used) at the edges of a DetNet network to prevent non- 416 congestion-responsive DetNet traffic from escaping the DetNet domain. 418 4.3. Forwarding Sub-Layer Considerations 420 4.3.1. Class of Service 422 Class of Service (CoS) for DetNet flows carried in IPv6 is provided 423 using the standard differentiated services code point (DSCP) field 424 [RFC2474] and related mechanisms. 426 One additional consideration for DetNet nodes which support CoS 427 services is that they MUST ensure that the CoS service classes do not 428 impact the congestion protection and latency control mechanisms used 429 to provide DetNet QoS. This requirement is similar to the 430 requirement for MPLS LSRs that CoS LSPs cannot impact the resources 431 allocated to TE LSPs [RFC3473]. 433 4.3.2. Quality of Service 435 Quality of Service (QoS) for DetNet service flows carried in IP MUST 436 be provided locally by the DetNet-aware hosts and routers supporting 437 DetNet flows. Such support leverages the underlying network layer 438 such as 802.1 TSN. The traffic control mechanisms used to deliver 439 QoS for IP encapsulated DetNet flows are expected to be defined in a 440 future document. From an encapsulation perspective, the combination 441 of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and 442 previously mentioned optional field, uniquely identifies a DetNet IP 443 flow. 445 Packets that are identified as part of a DetNet IP flow but that have 446 not been the subject of a completed reservation, can disrupt the QoS 447 offered to properly reserved DetNet flows by using resources 448 allocated to the reserved flows. Therefore, the network nodes of a 449 DetNet network MUST ensure that no DetNet allocated resources, e.g., 450 queue or shaper, is used by such flows. There are multiple methods 451 that MAY be used by an implementation to defend service delivery to 452 reserved DetNet flows, including but not limited to: 454 o Treating packets associated with an incomplete reservation as non- 455 DetNet traffic. 457 o Discarding packets associated with an incomplete reservation. 459 o Remarking packets associated with an incomplete reservation. 460 Remarking can be accomplished by changing the value of the DSCP, 461 or optional, field to a value that results in the packet no longer 462 matching any other reserved DetNet IP flow. 464 4.3.3. Path Selection 466 While path selection algorithms and mechanisms are out of scope of 467 the DetNet data plane definition, it is important to highlight the 468 implications of DetNet IP flow identification on path selection and 469 next hops. As mentioned above, the DetNet IP data plane identifies 470 flows using "6-tuple" header information as well as the additional 471 optional header field. DetNet generally allows for both flow- 472 specific traffic treatment and flow-specific next-hops. 474 In non-DetNet IP forwarding, it is generally assumed that the same 475 series of next hops, i.e., the same path, will be used for a 476 particular 5-tuple or, in some cases, e.g., [RFC5120], for a 477 particular 6-tuple. Using different next hops for different 5-tuples 478 does not take any special consideration for DetNet-aware 479 applications. 481 Care should be taken when using different next hops for the same 482 5-tuple. As discussed in [RFC7657], unexpected behavior can occur 483 when a single 5-tuple application flow experience reordering due to 484 being split across multiple next hops. Understanding of the 485 application and transport protocol impact of using different next 486 hops for the same 6-tuple is required. Again, this impacts path 487 selection for DetNet flows and this document only indirectly. 489 4.4. DetNet Flow Aggregation 491 As described in [I-D.ietf-detnet-data-plane-framework], the ability 492 to aggregate individual flows, and their associated resource control, 493 into a larger aggregate is an important technique for improving 494 scaling by reducing the state per hop. DetNet IP data plane 495 aggregation can take place within a single node, when that node 496 maintains state about both the aggregated and individual flows. It 497 can also take place between nodes, where one node maintains state 498 about only flow aggregates while the other node maintains state on 499 all or a portion of the component flows. In either case, the 500 management or control function that provisions the aggregate flows 501 must ensure that adequate resources are allocated and configured to 502 provide combined service requirements of the individual flows. As 503 DetNet is concerned about latency and jitter, more than just 504 bandwidth needs to be considered. 506 From a single node perspective, the aggregation of IP flows impacts 507 DetNet IP data plane flow identification and resource allocation. As 508 discussed above, IP flow identification uses the IP "6-tuple" for 509 flow identification. DetNet IP flows can be aggregated using any of 510 the 6-tuple, and an additional optional field defined in Section 5.1. 511 The use of prefixes, wildcards, lists, and value ranges allows a 512 DetNet node to identify aggregate DetNet flows. From a resource 513 allocation perspective, DetNet nodes must provide service to an 514 aggregate and not on a component flow basis. 516 It is the responsibility of the DetNet controller plane to properly 517 provision the use of these aggregation mechanisms. This includes 518 ensuring that aggregated flows have compatible e.g., the same or very 519 similar QoS and/or CoS characteristics, see Section 4.3.2. It also 520 includes ensuring that per component-flow service requirements are 521 satisfied by the aggregate, see Section 5.3. 523 4.5. Bidirectional Traffic 525 While the DetNet IP data plane must support bidirectional DetNet 526 flows, there are no special bidirectional features with respect to 527 the data plane other than the need for the two directions of a co- 528 routed bidirectional flow to take the same path. That is to say that 529 bidirectional DetNet flows are solely represented at the management 530 and control plane levels, without specific support or knowledge 531 within the DetNet data plane. Fate sharing and associated or co- 532 routed bidirectional flows can be managed at the control level. 534 Control and management mechanisms need to support bidirectional 535 flows, but the specification of such mechanisms are out of scope of 536 this document. An example control plane solution for MPLS can be 537 found in [RFC7551]. 539 5. DetNet IP Data Plane Procedures 541 This section provides DetNet IP data plane procedures. These 542 procedures have been divided into the following areas: flow 543 identification, forwarding and traffic treatment. Flow 544 identification includes those procedures related to matching IP and 545 higher layer protocol header information to DetNet flow (state) 546 information and service requirements. Flow identification is also 547 sometimes called Traffic classification, for example see [RFC5777]. 548 Forwarding includes those procedures related to next hop selection 549 and delivery. Traffic treatment includes those procedures related to 550 providing an identified flow with the required DetNet service. 552 DetNet IP data plane establishment and operational procedures also 553 have requirements on the control and management systems for DetNet 554 flows and these are referred in this section. Specifically this 555 section identifies a number of information elements that require 556 support via the management and control interfaces supported by a 557 DetNet node. The specific mechanism used for such support is out of 558 the scope of this document. A summary of the requirements for 559 management and control related information is included. Conformance 560 language is not used in the summary since applies to future 561 mechanisms such as those that may be provided in YANG models 562 [I-D.ietf-detnet-yang]. 564 5.1. DetNet IP Flow Identification Procedures 566 IP and higher layer protocol header information is used to identify 567 DetNet flows. All DetNet implementations that support this document 568 MUST identify individual DetNet flows based on the set of information 569 identified in this section. Note, that additional flow 570 identification requirements, e.g., to support other higher layer 571 protocols, may be defined in the future. 573 The configuration and control information used to identify an 574 individual DetNet flow MUST be ordered by an implementation. 575 Implementations MUST support a fixed order when identifying flows, 576 and MUST identify a DetNet flow by the first set of matching flow 577 information. 579 Implementations of this document MUST support DetNet flow 580 identification when the implementation is acting as a DetNet end 581 systems, a relay node, or as an edge node. 583 5.1.1. IP Header Information 585 Implementations of this document MUST support DetNet flow 586 identification based on IP header information. The IPv4 header is 587 defined in [RFC0791] and the IPv6 is defined in [RFC8200]. 589 5.1.1.1. Source Address Field 591 Implementations of this document MUST support DetNet flow 592 identification based on the Source Address field of an IP packet. 593 Implementations SHOULD support longest prefix matching for this 594 field, see [RFC1812] and [RFC7608]. Note that a prefix length of 595 zero (0) effectively means that the field is ignored. 597 5.1.1.2. Destination Address Field 599 Implementations of this document MUST support DetNet flow 600 identification based on the Destination Address field of an IP 601 packet. Implementations SHOULD support longest prefix matching for 602 this field, see [RFC1812] and [RFC7608]. Note that a prefix length 603 of zero (0) effectively means that the field is ignored. 605 Note: any IP address value is allowed, including an IP multicast 606 destination address. 608 5.1.1.3. IPv4 Protocol and IPv6 Next Header Fields 610 Implementations of this document MUST support DetNet flow 611 identification based on the IPv4 Protocol field when processing IPv4 612 packets, and the IPv6 Next Header Field when processing IPv6 packets. 613 An implementation MUST support flow identification based on the next 614 protocol values defined in Section 5.1.2. Other, non-zero values, 615 MUST be used for flow identification. Implementations SHOULD allow 616 for these fields to be ignored for a specific DetNet flow. 618 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields 620 These fields are used to support Differentiated Services [RFC2474] 621 [RFC2475]. Implementations of this document MUST support DetNet flow 622 identification based on the DSCP field in the IPv4 Type of Service 623 field when processing IPv4 packets, and the DSCP field in the IPv6 624 Traffic Class Field when processing IPv6 packets. Implementations 625 MUST support list based matching of DSCP values, where the list is 626 composed of possible field values that are to be considered when 627 identifying a specific DetNet flow. Implementations SHOULD allow for 628 this field to be ignored for a specific DetNet flow. 630 5.1.1.5. IPv6 Flow Label Field 632 Implementations of this document SHOULD support identification of 633 DetNet flows based on the IPv6 Flow Label field. Implementations 634 that support matching based on this field MUST allow for this field 635 to be ignored for a specific DetNet flow. When this field is used to 636 identify a specific DetNet flow, implementations MAY exclude the IPv6 637 Next Header field and next header information as part of DetNet flow 638 identification. 640 5.1.2. Other Protocol Header Information 642 Implementations of this document MUST support DetNet flow 643 identification based on header information identified in this 644 section. Support for TCP, UDP and IPsec flows is defined. Future 645 documents are expected to define support for other protocols. 647 5.1.2.1. TCP and UDP 649 DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is 650 achieved based on the Source and Destination Port fields carried in 651 each protocol's header. These fields share a common format and 652 common DetNet flow identification procedures. 654 5.1.2.1.1. Source Port Field 656 Implementations of this document MUST support DetNet flow 657 identification based on the Source Port field of a TCP or UDP packet. 658 Implementations MUST support flow identification based on a 659 particular value carried in the field, i.e., an exact value. 660 Implementations SHOULD support range-based port matching. 661 Implementation MUST also allow for the field to be ignored for a 662 specific DetNet flow. 664 5.1.2.1.2. Destination Port Field 666 Implementations of this document MUST support DetNet flow 667 identification based on the Destination Port field of a TCP or UDP 668 packet. Implementations MUST support flow identification based on a 669 particular value carried in the field, i.e., an exact value. 670 Implementations SHOULD support range-based port matching. 671 Implementation MUST also allow for the field to be ignored for a 672 specific DetNet flow. 674 5.1.2.2. IPsec AH and ESP 676 IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security 677 Payload (ESP) [RFC4303] share a common format for the Security 678 Parameters Index (SPI) field. Implementations MUST support flow 679 identification based on a particular value carried in the field, 680 i.e., an exact value. Implementation SHOULD also allow for the field 681 to be ignored for a specific DetNet flow. 683 5.2. Forwarding Procedures 685 General requirements for IP nodes are defined in [RFC1122], [RFC1812] 686 and [RFC6434], and are not modified by this document. The typical 687 next-hop selection process is impacted by DetNet. Specifically, 688 implementations of this document SHALL use management and control 689 information to select the one or more outgoing interfaces and next 690 hops to be used for a packet associated with a DetNet flow. 692 The use of multiple paths or links, e.g., ECMP, to support a single 693 DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet 694 flows within a DetNet domain. 696 The above implies that management and control functions will be 697 defined to support this requirement, e.g., see 698 [I-D.ietf-detnet-yang]. 700 5.3. DetNet IP Traffic Treatment Procedures 702 Implementations if this document MUST ensure that a DetNet flow 703 receives the traffic treatment that is provisioned for it via 704 configuration or the controller plane, e.g., via 705 [I-D.ietf-detnet-yang]. General information on DetNet service can be 706 found in [I-D.ietf-detnet-flow-information-model]. Typical 707 mechanisms used to provide different treatment to different flows 708 includes the allocation of system resources (such as queues and 709 buffers) and provisioning or related parameters (such as shaping, and 710 policing). Support can also be provided via an underlying network 711 technology such as MPLS [I-D.ietf-detnet-ip-over-mpls] or IEEE802.1 712 TSN [I-D.ietf-detnet-ip-over-tsn]. Other than in the TSN case, the 713 specific mechanisms used by a DetNet node to ensure DetNet service 714 delivery requirements are met for supported DetNet flows is outside 715 the scope of this document. 717 6. Management and Control Information Summary 719 The following summarizes the set of information that is needed to 720 identify individual and aggregated DetNet flows: 722 o IPv4 and IPv6 source address field. 724 o IPv4 and IPv6 source address prefix length, where a zero (0) value 725 effectively means that the address field is ignored. 727 o IPv4 and IPv6 destination address field. 729 o IPv4 and IPv6 destination address prefix length, where a zero (0) 730 effectively means that the address field is ignored. 732 o IPv4 protocol field. A limited set of values is allowed, and the 733 ability to ignore this field, e.g., via configuration of the value 734 zero (0), is desirable. 736 o IPv6 next header field. A limited set of values is allowed, and 737 the ability to ignore this field, e.g., via configuration of the 738 value zero (0), is desirable. 740 o For the IPv4 Type of Service and IPv6 Traffic Class Fields: 742 * If the DSCP field is to be used in flow identification. 743 Ignoring the DSCP filed is optional. 745 * When the DSCP field is used in flow identification, a list of 746 field values that may be used by a specific flow. 748 o IPv6 flow label field. This field can be optionally used for 749 matching. When used, can be used instead of matching against the 750 Next Header field. 752 o TCP and UDP Source Port. Exact and wildcard matching is required. 753 Port ranges can optionally be used. 755 o TCP and UDP Destination Port. Exact and wildcard matching is 756 required. Port ranges can optionally be used. 758 o IPsec Header SPI field. Exact matching is required. 760 This information MUST be provisioned per DetNet flow via 761 configuration, e.g., via the controller or management plane. 763 Information identifying a DetNet flow is ordered and implementations 764 use the first match. This can, for example, be used to provide a 765 DetNet service for a specific UDP flow, with unique Source and 766 Destination Port field values, while providing a different service 767 for the aggregate of all other flows with that same UDP Destination 768 Port value. 770 It is the responsibility of the DetNet controller plane to properly 771 provision both flow identification information and the flow specific 772 resources needed to provided the traffic treatment needed to meet 773 each flow's service requirements. This applies for aggregated and 774 individual flows. 776 7. Security Considerations 778 Security considerations for DetNet are described in detail in 779 [I-D.ietf-detnet-security]. General security considerations are 780 described in [I-D.ietf-detnet-architecture]. This section considers 781 exclusively security considerations which are specific to the DetNet 782 IP data plane. 784 Security aspects which are unique to DetNet are those whose aim is to 785 provide the specific quality of service aspects of DetNet, which are 786 primarily to deliver data flows with extremely low packet loss rates 787 and bounded end-to-end delivery latency. 789 The primary considerations for the data plane is to maintain 790 integrity of data and delivery of the associated DetNet service 791 traversing the DetNet network. Application flows can be protected 792 through whatever means is provided by the underlying technology. For 793 example, encryption may be used, such as that provided by IPSec 794 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 795 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 797 From a data plane perspective this document does not add or modify 798 any header information. 800 At the management and control level DetNet flows are identified on a 801 per-flow basis, which may provide controller plane attackers with 802 additional information about the data flows (when compared to 803 controller planes that do not include per-flow identification). This 804 is an inherent property of DetNet which has security implications 805 that should be considered when determining if DetNet is a suitable 806 technology for any given use case. 808 To provide uninterrupted availability of the DetNet service, 809 provisions can be made against DOS attacks and delay attacks. To 810 protect against DOS attacks, excess traffic due to malicious or 811 malfunctioning devices can be prevented or mitigated, for example 812 through the use of existing mechanism such as policing and shaping 813 applied at the input of a DetNet domain. To prevent DetNet packets 814 from being delayed by an entity external to a DetNet domain, DetNet 815 technology definition can allow for the mitigation of Man-In-The- 816 Middle attacks, for example through use of authentication and 817 authorization of devices within the DetNet domain. 819 8. IANA Considerations 821 This document does not require an action from IANA. 823 9. Acknowledgements 825 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 826 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 827 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 828 Bernardos for their various contributions to this work. David Black 829 served as technical advisor to the DetNet working group during the 830 development of this document and provided many valuable comments. 832 10. References 834 10.1. Normative references 836 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 837 DOI 10.17487/RFC0768, August 1980, 838 . 840 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 841 DOI 10.17487/RFC0791, September 1981, 842 . 844 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 845 RFC 793, DOI 10.17487/RFC0793, September 1981, 846 . 848 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 849 RFC 1812, DOI 10.17487/RFC1812, June 1995, 850 . 852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 853 Requirement Levels", BCP 14, RFC 2119, 854 DOI 10.17487/RFC2119, March 1997, 855 . 857 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 858 "Definition of the Differentiated Services Field (DS 859 Field) in the IPv4 and IPv6 Headers", RFC 2474, 860 DOI 10.17487/RFC2474, December 1998, 861 . 863 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 864 and W. Weiss, "An Architecture for Differentiated 865 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 866 . 868 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 869 Switching (GMPLS) Signaling Resource ReserVation Protocol- 870 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 871 DOI 10.17487/RFC3473, January 2003, 872 . 874 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 875 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 876 December 2005, . 878 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 879 DOI 10.17487/RFC4302, December 2005, 880 . 882 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 883 RFC 4303, DOI 10.17487/RFC4303, December 2005, 884 . 886 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 887 Length Recommendation for Forwarding", BCP 198, RFC 7608, 888 DOI 10.17487/RFC7608, July 2015, 889 . 891 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 892 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 893 May 2017, . 895 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 896 (IPv6) Specification", STD 86, RFC 8200, 897 DOI 10.17487/RFC8200, July 2017, 898 . 900 10.2. Informative references 902 [I-D.ietf-detnet-architecture] 903 Finn, N., Thubert, P., Varga, B., and J. Farkas, 904 "Deterministic Networking Architecture", draft-ietf- 905 detnet-architecture-13 (work in progress), May 2019. 907 [I-D.ietf-detnet-data-plane-framework] 908 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 909 Bryant, S., and J. Korhonen, "DetNet Data Plane 910 Framework", draft-ietf-detnet-data-plane-framework-02 911 (work in progress), September 2019. 913 [I-D.ietf-detnet-dp-sol-mpls] 914 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 915 Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in 916 progress), March 2019. 918 [I-D.ietf-detnet-flow-information-model] 919 Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D. 920 Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- 921 flow-information-model-05 (work in progress), September 922 2019. 924 [I-D.ietf-detnet-ip-over-mpls] 925 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 926 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over 927 MPLS", draft-ietf-detnet-ip-over-mpls-01 (work in 928 progress), July 2019. 930 [I-D.ietf-detnet-ip-over-tsn] 931 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 932 Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time 933 Sensitive Networking (TSN)", draft-ietf-detnet-ip-over- 934 tsn-00 (work in progress), May 2019. 936 [I-D.ietf-detnet-mpls] 937 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 938 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 939 draft-ietf-detnet-mpls-01 (work in progress), July 2019. 941 [I-D.ietf-detnet-security] 942 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 943 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 944 Networking (DetNet) Security Considerations", draft-ietf- 945 detnet-security-05 (work in progress), August 2019. 947 [I-D.ietf-detnet-tsn-vpn-over-mpls] 948 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 949 Korhonen, "DetNet Data Plane: IEEE 802.1 Time Sensitive 950 Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- 951 mpls-00 (work in progress), May 2019. 953 [I-D.ietf-detnet-yang] 954 Geng, X., Chen, M., Ryoo, Y., Li, Z., and R. Rahman, 955 "Deterministic Networking (DetNet) Configuration YANG 956 Model", draft-ietf-detnet-yang-03 (work in progress), July 957 2019. 959 [IEEE802.1AE-2018] 960 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 961 Security (MACsec)", 2018, 962 . 964 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 965 Communication Layers", STD 3, RFC 1122, 966 DOI 10.17487/RFC1122, October 1989, 967 . 969 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 970 Informal Management Model for Diffserv Routers", RFC 3290, 971 DOI 10.17487/RFC3290, May 2002, 972 . 974 [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and 975 W. Weiss, "Information Model for Describing Network Device 976 QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, 977 January 2004, . 979 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 980 Topology (MT) Routing in Intermediate System to 981 Intermediate Systems (IS-ISs)", RFC 5120, 982 DOI 10.17487/RFC5120, February 2008, 983 . 985 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 986 Ed., and A. Lior, "Traffic Classification and Quality of 987 Service (QoS) Attributes for Diameter", RFC 5777, 988 DOI 10.17487/RFC5777, February 2010, 989 . 991 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 992 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 993 2011, . 995 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 996 Extensions for Associated Bidirectional Label Switched 997 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 998 . 1000 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 1001 (Diffserv) and Real-Time Communication", RFC 7657, 1002 DOI 10.17487/RFC7657, November 2015, 1003 . 1005 Authors' Addresses 1007 Balazs Varga (editor) 1008 Ericsson 1009 Magyar Tudosok krt. 11. 1010 Budapest 1117 1011 Hungary 1013 Email: balazs.a.varga@ericsson.com 1015 Janos Farkas 1016 Ericsson 1017 Magyar Tudosok krt. 11. 1018 Budapest 1117 1019 Hungary 1021 Email: janos.farkas@ericsson.com 1023 Lou Berger 1024 LabN Consulting, L.L.C. 1026 Email: lberger@labn.net 1028 Don Fedyk 1029 LabN Consulting, L.L.C. 1031 Email: dfedyk@labn.net 1033 Andrew G. Malis 1034 Independent 1036 Email: agmalis@gmail.com 1037 Stewart Bryant 1038 Futurewei Technologies 1040 Email: stewart.bryant@gmail.com 1042 Jouni Korhonen 1044 Email: jouni.nospam@gmail.com