idnits 2.17.1 draft-ietf-detnet-ip-06.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 (April 23, 2020) is 1436 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 259, 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-04 == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-07 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-ip-over-mpls-05 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-02 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-05 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-09 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-tsn-vpn-over-mpls-02 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-yang-05 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga, Ed. 3 Internet-Draft J. Farkas 4 Intended status: Standards Track Ericsson 5 Expires: October 25, 2020 L. Berger 6 D. Fedyk 7 LabN Consulting, L.L.C. 8 S. Bryant 9 Futurewei Technologies 10 April 23, 2020 12 DetNet Data Plane: IP 13 draft-ietf-detnet-ip-06 15 Abstract 17 This document specifies the Deterministic Networking data plane when 18 operating in an IP packet switched network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 25, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 57 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 58 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 60 4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 7 61 4.1. End-system-specific Considerations . . . . . . . . . . . 7 62 4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7 63 4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 10 64 4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 10 65 4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10 66 4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 11 67 4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 11 68 4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 12 69 5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 12 70 5.1. DetNet IP Flow Identification Procedures . . . . . . . . 13 71 5.1.1. IP Header Information . . . . . . . . . . . . . . . . 13 72 5.1.2. Other Protocol Header Information . . . . . . . . . . 14 73 5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 15 74 5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 16 75 6. Management and Control Information Summary . . . . . . . . . 16 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 79 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 11.1. Normative references . . . . . . . . . . . . . . . . . . 19 82 11.2. Informative references . . . . . . . . . . . . . . . . . 20 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 85 1. Introduction 87 Deterministic Networking (DetNet) is a service that can be offered by 88 a network to DetNet flows. DetNet provides these flows with 89 extremely low packet loss rates and assured maximum end-to-end 90 delivery latency. General background and concepts of DetNet can be 91 found in the DetNet Architecture [RFC8655]. 93 This document specifies the DetNet data plane operation for IP hosts 94 and routers that provide DetNet service to IP encapsulated data. No 95 DetNet-specific encapsulation is defined to support IP flows, instead 96 the existing IP and higher layer protocol header information is used 97 to support flow identification and DetNet service delivery. Common 98 data plane procedures and control information for all DetNet data 99 planes can be found in the [I-D.ietf-detnet-data-plane-framework]. 101 The DetNet Architecture models the DetNet related data plane 102 functions as two sub-layers: a service sub-layer and a forwarding 103 sub-layer. The service sub-layer is used to provide DetNet service 104 protection (e.g., by packet replication and packet elimination 105 functions) and reordering. The forwarding sub-layer is used to 106 provide congestion protection (low loss, assured latency, and limited 107 out-of-order delivery). The service sub-layer generally requires 108 additional header fields to provide its service; for example see 109 [I-D.ietf-detnet-mpls]. Since no DetNet-specific fields are added to 110 support 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 (Time-Sensitive Networking) task group 115 (referred to in this document simply 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 [RFC8655], and the reader is assumed to be 130 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 L2 Layer-2 147 L3 Layer-3 149 LSP Label-switched path 151 MPLS Multiprotocol Label Switching 153 PREOF Packet Replication, Elimination and Ordering Function 155 QoS Quality of Service 157 TSN Time-Sensitive Networking, TSN is a Task Group of the 158 IEEE 802.1 Working Group. 160 2.3. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 3. DetNet IP Data Plane Overview 170 This document describes how IP is used by DetNet nodes, i.e., hosts 171 and routers, to identify DetNet flows and provide a DetNet service 172 using an IP data plane. From a data plane perspective, an end-to-end 173 IP model is followed. As mentioned above, existing IP and higher 174 layer protocol header information is used to support flow 175 identification and DetNet service delivery. Common data plane 176 procedures and control information for all DetNet data planes can be 177 found in the [I-D.ietf-detnet-data-plane-framework]. 179 The DetNet IP data plane primarily uses "6-tuple" based flow 180 identification, where 6-tuple refers to information carried in IP and 181 higher layer protocol headers. The 6-tuple referred to in this 182 document is the same as that defined in [RFC3290]. Specifically 183 6-tuple is (destination address, source address, IP protocol, source 184 port, destination port, and differentiated services (DiffServ) code 185 point (DSCP). General background on the use of IP headers, and 186 5-tuples, to identify flows and support Quality of Service (QoS) can 187 be found in [RFC3670]. [RFC7657] also provides useful background on 188 the delivery of DiffServ and "tuple" based flow identification. Note 189 that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP 190 component. 192 For some of the protocols 5-tuples and 6-tuples cannot be used 193 because the port information is not available (e.g., ICMP, IPSec 194 ESP). Same can be valid for flow aggregates. In such cases using 195 smaller tuples are appropriate, e.g., a 3-tuple (2 IP addresses, IP 196 protocol) or even a 2-tuple (all IP traffic between two IP 197 addresses). 199 The DetNet IP data plane also allows for optional matching on the 200 IPv6 flow label field, as defined in [RFC8200]. 202 Non-DetNet and DetNet IP packets are identical on the wire. 203 Generally the fields used in flow identification are forwarded 204 unmodified, however modification of these fields is allowed, for 205 example changing the DSCP value, when required by the DetNet service. 207 DetNet flow aggregation may be enabled via the use of wildcards, 208 masks, lists, prefixes and ranges. IP tunnels may also be used to 209 support flow aggregation. In these cases, it is expected that 210 DetNet-aware intermediate nodes will provide DetNet service on the 211 aggregate through resource allocation and congestion control 212 mechanisms. 214 DetNet IP Relay Relay DetNet IP 215 End System Node Node End System 217 +----------+ +----------+ 218 | Appl. |<------------ End to End Service ----------->| Appl. | 219 +----------+ ............ ........... +----------+ 220 | Service |<-: Service :-- DetNet flow --: Service :->| Service | 221 +----------+ +----------+ +----------+ +----------+ 222 |Forwarding| |Forwarding| |Forwarding| |Forwarding| 223 +--------.-+ +-.------.-+ +-.---.----+ +-------.--+ 224 : Link : \ ,-----. / \ ,-----. / 225 +......+ +----[ Sub ]----+ +-[ Sub ]-+ 226 [Network] [Network] 227 `-----' `-----' 229 |<--------------------- DetNet IP --------------------->| 231 Figure 1: A Simple DetNet (DN) Enabled IP Network 233 Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled 234 end systems originate IP encapsulated traffic that is identified 235 within the DetNet domain as DetNet flows. Relay nodes understand the 236 forwarding requirements of the DetNet flow and ensure that node, 237 interface and sub-network resources are allocated to ensure DetNet 238 service requirements. The dotted line around the Service component 239 of the Relay Nodes indicates that the transit routers are DetNet 240 service aware but do not perform any DetNet service sub-layer 241 function, e.g., PREOF (Packet Replication, Elimination and Ordering 242 Function). 244 Note: The sub-network can represent a TSN, MPLS network or other 245 network technology that can carry DetNet IP traffic. 247 IP Edge Edge IP 248 End System Node Node End System 250 +----------+ +.........+ +.........+ +----------+ 251 | Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. | 252 +----------+ +.........+ +.........+ +----------+ 253 | IP |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->| IP | 254 +----------+ +---+ +---+ +---+ +---+ +----------+ 255 |Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding| 256 +--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ 257 : Link : \ ,-----. / / ,-----. \ 258 +.......+ +----[ Sub ]----+ +--[ Sub ]--+ 259 [Network] [Network] 260 `-----' `-----' 262 |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->| 264 Figure 2: Non-DetNet-aware IP end systems with DetNet IP Domain 266 Figure 2 illustrates a variant of Figure 1 where the end systems are 267 not DetNet aware. In this case, edge nodes sit at the boundary of 268 the DetNet domain and provide DetNet service proxies for the end 269 applications by initiating and terminating DetNet service for the 270 application's IP flows. The existing header information or an 271 approach such as described in Section 4.4 can be used to support 272 DetNet flow identification. 274 Note, that Figure 1 and Figure 2 can be collapsed, so IP DetNet End 275 Systems can communicate over DetNet IP network with IP End System. 277 As non-DetNet and DetNet IP packets are identical on the wire, from 278 data plane perspective, the only difference is that there is flow- 279 associated DetNet information on each DetNet node that defines the 280 flow related characteristics and required forwarding behavior. As 281 shown above, edge nodes provide a Service Proxy function that 282 "associates" one or more IP flows with the appropriate DetNet flow- 283 specific information and ensures that the flow receives the proper 284 traffic treatment within the domain. 286 Note: The operation of IEEE802.1 TSN end systems over DetNet enabled 287 IP networks is not described in this document. TSN over MPLS is 288 discribed in [I-D.ietf-detnet-tsn-vpn-over-mpls]. 290 4. DetNet IP Data Plane Considerations 292 This section provides informative considerations related to providing 293 DetNet service to flows which are identified based on their header 294 information. 296 4.1. End-system-specific Considerations 298 Data-flows requiring DetNet service are generated and terminated on 299 end systems. This document deals only with IP end systems. The 300 protocols used by an IP end system are specific to an application, 301 and end systems peer with other end systems. DetNet's use of 6-tuple 302 IP flow identification means that DetNet must be aware of not only 303 the format of the IP header, but also of the next protocol carried 304 within an IP packet (see Section 5.1.1.3). 306 When IP end systems are DetNet-aware, no application-level or 307 service-level proxy functions are needed inside the DetNet domain. 308 For DetNet unaware IP end systems service-level proxy functions are 309 needed inside the DetNet domain. 311 End systems need to ensure that DetNet service requirements are met 312 when processing packets associated to a DetNet flow. When forwarding 313 packets, this means that packets are appropriately shaped on 314 transmission and receive appropriate traffic treatment on the 315 connected sub-network, see Section 4.3.2 and Section 4.2 for more 316 details. When receiving packets, this means that there are 317 appropriate local node resources, e.g., buffers, to receive and 318 process the packets of that DetNet flow. 320 In order to maximize reuse of existing mechanisms, DetNet-aware 321 applications and end systems SHOULD NOT mix DetNet and non-DetNet 322 traffic within a single 5-tuple. 324 4.2. DetNet Domain-Specific Considerations 326 As a general rule, DetNet IP domains need to be able to forward any 327 DetNet flow identified by the IP 6-tuple. Doing otherwise would 328 limit the number of 6-tuple flow ID combinations that could be used 329 by the end systems. From a practical standpoint this means that all 330 nodes along the end-to-end path of DetNet flows need to agree on what 331 fields are used for flow identification. 333 From a connection type perspective two scenarios are identified: 335 1. DN attached: the end system is directly connected to an edge 336 node, or the end system is behind a sub-network (See ES1 and ES2 337 in figure below) 339 2. DN integrated: the end system is part of the DetNet domain. (See 340 ES3 in figure below) 342 L3 (IP) end systems may use any of these connection types. A DetNet 343 domain allows communication between any end-systems using the same 344 encapsulation format, independent of their connection type and DetNet 345 capability. DN attached end systems have no knowledge about the 346 DetNet domain and its encapsulation format. See Figure 3 for L3 end 347 system connection examples. 349 ____+----+ 350 +----+ _____ / | ES3| 351 | ES1|____ / \__/ +----+___ 352 +----+ \ / \ 353 + | 354 ____ \ _/ 355 +----+ __/ \ +__ DetNet IP domain / 356 | ES2|____/ L2/L3 |___/ \ __ __/ 357 +----+ \_______/ \_______/ \___/ 359 Figure 3: Connection types of L3 end systems 361 Within a DetNet domain, the DetNet-enabled IP Routers are 362 interconnected by links and sub-networks to support end-to-end 363 delivery of DetNet flows. From a DetNet architecture perspective, 364 these routers are DetNet relays, as they must be DetNet service 365 aware. Such routers identify DetNet flows based on the IP 6-tuple, 366 and ensure that the DetNet service required traffic treatment is 367 provided both on the node and on any attached sub-network. 369 This solution provides DetNet functions end to end, but does so on a 370 per link and sub-network basis. Congestion protection and latency 371 control and the resource allocation (queuing, policing, shaping) are 372 supported using the underlying link / sub net specific mechanisms. 373 However, service protection (packet replication and packet 374 elimination functions) is not provided at the DetNet layer end to 375 end. Instead service protection can be provided on a per underlying 376 L2 link and sub-network basis. 378 The DetNet Service Flow is mapped to the link / sub-network specific 379 resources using an underlying system-specific means. This implies 380 each DetNet-aware node on path looks into the forwarded DetNet 381 Service Flow packet and utilize e.g., a 6-tuple to find out the 382 required mapping within a node. 384 As noted earlier, service protection must be implemented within each 385 link / sub-network independently, using the domain specific 386 mechanisms. This is due to the lack of unified end-to-end sequencing 387 information that could be used by the intermediate nodes. Therefore, 388 service protection (if enabled) cannot be provided end-to-end, only 389 within sub-networks. This is shown for a three sub-network scenario 390 in Figure 4, where each sub-network can provide service protection 391 between its borders. "R" and "E" denotes replication and elimination 392 points within the sub-network. 394 <-------------------- DenNet IP ------------------------> 395 ______ 396 ____ / \__ 397 ____ / \__/ \___ ______ 398 +----+ __/ +====+ +==+ \ +----+ 399 |src |__/ SubN1 ) | | \ SubN3 \____| dst| 400 +----+ \_______/ \ Sub-Network2 | \______/ +----+ 401 \_ _/ 402 \ __ __/ 403 \_______/ \___/ 405 +---+ +---------E--------+ +-----+ 406 +----+ | | | | | | | +----+ 407 |src |----R E--------R +---+ E------R E------+ dst| 408 +----+ | | | | | | | +----+ 409 +---+ +-----R------------+ +-----+ 411 Figure 4: Replication and elimination in sub-networks for DetNet IP 412 networks 414 If end to end service protection is desired, it can be implemented, 415 for example, by the DetNet end systems using Layer-4 (L4) transport 416 protocols or application protocols. However, these protocols are out 417 of scope of this document. 419 Note that not mixing DetNet and non-DetNet traffic within a single 420 5-tuple, as described above, enables simpler 5-tuple filters to be 421 used (or re-used) at the edges of a DetNet network to prevent non- 422 congestion-responsive DetNet traffic from escaping the DetNet domain. 424 4.3. Forwarding Sub-Layer Considerations 426 4.3.1. Class of Service 428 Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is 429 provided using the standard differentiated services (DSCP) field 430 [RFC2474] and related mechanisms. 432 One additional consideration for DetNet nodes which support CoS 433 services is that they MUST ensure that the CoS service classes do not 434 impact the congestion protection and latency control mechanisms used 435 to provide DetNet QoS. This requirement is similar to the 436 requirement for MPLS LSRs that CoS LSPs cannot impact the resources 437 allocated to TE LSPs [RFC3473]. 439 4.3.2. Quality of Service 441 Quality of Service (QoS) for DetNet service flows carried in IP MUST 442 be provided locally by the DetNet-aware hosts and routers supporting 443 DetNet flows. Such support leverages the underlying network layer 444 such as 802.1 TSN. The traffic control mechanisms used to deliver 445 QoS for IP encapsulated DetNet flows are expected to be defined in a 446 future document. From an encapsulation perspective, the combination 447 of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and 448 previously mentioned optional field (i.e., flow label), uniquely 449 identifies a DetNet IP flow. 451 Packets that are identified as part of a DetNet IP flow but that have 452 not been the subject of a completed reservation, can disrupt the QoS 453 offered to properly reserved DetNet flows by using resources 454 allocated to the reserved flows. Therefore, the network nodes of a 455 DetNet network MUST ensure that no DetNet allocated resources, e.g., 456 queue or shaper, is used by such flows. There are multiple methods 457 that MAY be used by an implementation to defend service delivery to 458 reserved DetNet flows, including but not limited to: 460 o Treating packets associated with an incomplete reservation as non- 461 DetNet traffic. 463 o Discarding packets associated with an incomplete reservation. 465 o Remarking packets associated with an incomplete reservation. 466 Remarking can be accomplished by changing the value of the DSCP 467 field to a value that results in the packet no longer matching any 468 other reserved DetNet IP flow. 470 4.3.3. Path Selection 472 While path selection algorithms and mechanisms are out of scope of 473 the DetNet data plane definition, it is important to highlight the 474 implications of DetNet IP flow identification on path selection and 475 next hops. As mentioned above, the DetNet IP data plane identifies 476 flows using "6-tuple" header information as well as the additional 477 optional header field. DetNet generally allows for both flow- 478 specific traffic treatment and flow-specific next-hops. 480 In non-DetNet IP forwarding, it is generally assumed that the same 481 series of next hops, i.e., the same path, will be used for a 482 particular 5-tuple or, in some cases, e.g., [RFC5120], for a 483 particular 6-tuple. Using different next hops for different 5-tuples 484 does not take any special consideration for DetNet-aware 485 applications. 487 Care should be taken when using different next hops for the same 488 5-tuple. As discussed in [RFC7657], unexpected behavior can occur 489 when a single 5-tuple application flow experience reordering due to 490 being split across multiple next hops. Understanding of the 491 application and transport protocol impact of using different next 492 hops for the same 6-tuple is required. Again, this impacts path 493 selection for DetNet flows and this document only indirectly. 495 4.4. DetNet Flow Aggregation 497 As described in [I-D.ietf-detnet-data-plane-framework], the ability 498 to aggregate individual flows, and their associated resource control, 499 into a larger aggregate is an important technique for improving 500 scaling by reducing the state per hop. DetNet IP data plane 501 aggregation can take place within a single node, when that node 502 maintains state about both the aggregated and individual flows. It 503 can also take place between nodes, where one node maintains state 504 about only flow aggregates while the other node maintains state on 505 all or a portion of the component flows. In either case, the 506 management or control function that provisions the aggregate flows 507 must ensure that adequate resources are allocated and configured to 508 provide combined service requirements of the individual flows. As 509 DetNet is concerned about latency and jitter, more than just 510 bandwidth needs to be considered. 512 From a single node perspective, the aggregation of IP flows impacts 513 DetNet IP data plane flow identification and resource allocation. As 514 discussed above, IP flow identification uses the IP "6-tuple" for 515 flow identification. DetNet IP flows can be aggregated using any of 516 the 6-tuple, and an additional optional field (i.e., flow label). 517 The use of prefixes, wildcards, lists, and value ranges allows a 518 DetNet node to identify aggregate DetNet flows. From a resource 519 allocation perspective, DetNet nodes ought to provide service to an 520 aggregate rather than on a component flow basis. 522 It is the responsibility of the DetNet controller plane to properly 523 provision the use of these aggregation mechanisms. This includes 524 ensuring that aggregated flows have compatible e.g., the same or very 525 similar QoS and/or CoS characteristics, see Section 4.3.2. It also 526 includes ensuring that per component-flow service requirements are 527 satisfied by the aggregate, see Section 5.3. 529 4.5. Bidirectional Traffic 531 While the DetNet IP data plane must support bidirectional DetNet 532 flows, there are no special bidirectional features with respect to 533 the data plane other than the need for the two directions of a co- 534 routed bidirectional flow to take the same path. That is to say that 535 bidirectional DetNet flows are solely represented at the management 536 and control plane levels, without specific support or knowledge 537 within the DetNet data plane. Fate sharing and associated or co- 538 routed bidirectional flows can be managed at the control level. 540 Control and management mechanisms need to support bidirectional 541 flows, but the specification of such mechanisms are out of scope of 542 this document. An example control plane solution for MPLS can be 543 found in [RFC7551]. 545 5. DetNet IP Data Plane Procedures 547 This section provides DetNet IP data plane procedures. These 548 procedures have been divided into the following areas: flow 549 identification, forwarding and traffic treatment. Flow 550 identification includes those procedures related to matching IP and 551 higher layer protocol header information to DetNet flow (state) 552 information and service requirements. Flow identification is also 553 sometimes called Traffic classification, for example see [RFC5777]. 554 Forwarding includes those procedures related to next hop selection 555 and delivery. Traffic treatment includes those procedures related to 556 providing an identified flow with the required DetNet service. 558 DetNet IP data plane establishment and operational procedures also 559 have requirements on the control and management systems for DetNet 560 flows and these are referred to in this section. Specifically this 561 section identifies a number of information elements that require 562 support via the management and control interfaces supported by a 563 DetNet node. The specific mechanism used for such support is out of 564 the scope of this document. A summary of the requirements for 565 management and control related information is included. Conformance 566 language is not used in the summary since it applies to future 567 mechanisms such as those that may be provided in YANG models 568 [I-D.ietf-detnet-yang]. 570 5.1. DetNet IP Flow Identification Procedures 572 IP and higher layer protocol header information is used to identify 573 DetNet flows. All DetNet implementations that support this document 574 MUST identify individual DetNet flows based on the set of information 575 identified in this section. Note, that additional flow 576 identification requirements, e.g., to support other higher layer 577 protocols, may be defined in the future. 579 The configuration and control information used to identify an 580 individual DetNet flow MUST be ordered by an implementation. 581 Implementations MUST support a fixed order when identifying flows, 582 and MUST identify a DetNet flow by the first set of matching flow 583 information. 585 Implementations of this document MUST support DetNet flow 586 identification when the implementation is acting as a DetNet end 587 systems, a relay node, or as an edge node. 589 5.1.1. IP Header Information 591 Implementations of this document MUST support DetNet flow 592 identification based on IP header information. The IPv4 header is 593 defined in [RFC0791] and the IPv6 is defined in [RFC8200]. 595 5.1.1.1. Source Address Field 597 Implementations of this document MUST support DetNet flow 598 identification based on the Source Address field of an IP packet. 599 Implementations SHOULD support longest prefix matching for this 600 field, see [RFC1812] and [RFC7608]. Note that a prefix length of 601 zero (0) effectively means that the field is ignored. 603 5.1.1.2. Destination Address Field 605 Implementations of this document MUST support DetNet flow 606 identification based on the Destination Address field of an IP 607 packet. Implementations SHOULD support longest prefix matching for 608 this field, see [RFC1812] and [RFC7608]. Note that a prefix length 609 of zero (0) effectively means that the field is ignored. 611 Note: any IP address value is allowed, including an IP multicast 612 destination address. 614 5.1.1.3. IPv4 Protocol and IPv6 Next Header Fields 616 Implementations of this document MUST support DetNet flow 617 identification based on the IPv4 Protocol field when processing IPv4 618 packets, and the IPv6 Next Header Field when processing IPv6 packets. 619 An implementation MUST support flow identification based on the next 620 protocol values defined in Section 5.1.2. Other, non-zero values, 621 MUST be used for flow identification. Implementations SHOULD allow 622 for these fields to be ignored for a specific DetNet flow. 624 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields 626 These fields are used to support Differentiated Services [RFC2474] 627 [RFC2475]. Implementations of this document MUST support DetNet flow 628 identification based on the DSCP field in the IPv4 Type of Service 629 field when processing IPv4 packets, and the DSCP field in the IPv6 630 Traffic Class Field when processing IPv6 packets. Implementations 631 MUST support list based matching of DSCP values, where the list is 632 composed of possible field values that are to be considered when 633 identifying a specific DetNet flow. Implementations SHOULD allow for 634 this field to be ignored for a specific DetNet flow. 636 5.1.1.5. IPv6 Flow Label Field 638 Implementations of this document SHOULD support identification of 639 DetNet flows based on the IPv6 Flow Label field. Implementations 640 that support matching based on this field MUST allow for this field 641 to be ignored for a specific DetNet flow. When this field is used to 642 identify a specific DetNet flow, implementations MAY exclude the IPv6 643 Next Header field and next header information as part of DetNet flow 644 identification. 646 5.1.2. Other Protocol Header Information 648 Implementations of this document MUST support DetNet flow 649 identification based on header information identified in this 650 section. Support for TCP, UDP, ICMP and IPsec flows is defined. 651 Future documents are expected to define support for other protocols. 653 5.1.2.1. TCP and UDP 655 DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is 656 achieved based on the Source and Destination Port fields carried in 657 each protocol's header. These fields share a common format and 658 common DetNet flow identification procedures. 660 The rules defined in this section only apply when the IPv4 Protocol 661 or IPv6 Next Header Field contains the IANA defined value for UDP or 662 TCP. 664 5.1.2.1.1. Source Port Field 666 Implementations of this document MUST support DetNet flow 667 identification based on the Source Port field of a TCP or UDP packet. 668 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.1.2. Destination Port Field 676 Implementations of this document MUST support DetNet flow 677 identification based on the Destination Port field of a TCP or UDP 678 packet. Implementations MUST support flow identification based on a 679 particular value carried in the field, i.e., an exact value. 680 Implementations SHOULD support range-based port matching. 681 Implementation MUST also allow for the field to be ignored for a 682 specific DetNet flow. 684 5.1.2.2. ICMP 686 DetNet flow identification for ICMP is achieved based on the 687 protocol's header. Note that ICMP type is not included in the flow 688 definition. 690 5.1.2.3. IPsec AH and ESP 692 IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security 693 Payload (ESP) [RFC4303] share a common format for the Security 694 Parameters Index (SPI) field. Implementations MUST support flow 695 identification based on a particular value carried in the field, 696 i.e., an exact value. Implementation SHOULD also allow for the field 697 to be ignored for a specific DetNet flow. 699 The rules defined in this section only apply when the IPv4 Protocol 700 or IPv6 Next Header Field contains the IANA defined value for AH or 701 ESP. 703 5.2. Forwarding Procedures 705 General requirements for IP nodes are defined in [RFC1122], [RFC1812] 706 and [RFC8504], and are not modified by this document. The typical 707 next-hop selection process is impacted by DetNet. Specifically, 708 implementations of this document SHALL use management and control 709 information to select the one or more outgoing interfaces and next 710 hops to be used for a packet associated with a DetNet flow. 712 The use of multiple paths or links, e.g., ECMP, to support a single 713 DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet 714 flows within a DetNet domain. 716 The above implies that management and control functions will be 717 defined to support this requirement, e.g., see 718 [I-D.ietf-detnet-yang]. 720 5.3. DetNet IP Traffic Treatment Procedures 722 Implementations of this document MUST ensure that a DetNet flow 723 receives the traffic treatment that is provisioned for it via 724 configuration or the controller plane, e.g., via 725 [I-D.ietf-detnet-yang]. General information on DetNet service can be 726 found in [I-D.ietf-detnet-flow-information-model]. Typical 727 mechanisms used to provide different treatment to different flows 728 includes the allocation of system resources (such as queues and 729 buffers) and provisioning or related parameters (such as shaping, and 730 policing). Support can also be provided via an underlying network 731 technology such as MPLS [I-D.ietf-detnet-ip-over-mpls] or IEEE802.1 732 TSN [I-D.ietf-detnet-ip-over-tsn]. Other mechanisms than the ones 733 used in the TSN case are outside the scope of this document. 735 6. Management and Control Information Summary 737 The following summarizes the set of information that is needed to 738 identify individual and aggregated DetNet flows: 740 o IPv4 and IPv6 source address field. 742 o IPv4 and IPv6 source address prefix length, where a zero (0) value 743 effectively means that the address field is ignored. 745 o IPv4 and IPv6 destination address field. 747 o IPv4 and IPv6 destination address prefix length, where a zero (0) 748 effectively means that the address field is ignored. 750 o IPv4 protocol field. A limited set of values is allowed, and the 751 ability to ignore this field, e.g., via configuration of the value 752 zero (0), is desirable. 754 o IPv6 next header field. A limited set of values is allowed, and 755 the ability to ignore this field, e.g., via configuration of the 756 value zero (0), is desirable. 758 o For the IPv4 Type of Service and IPv6 Traffic Class Fields: 760 * Whether or not the DSCP field is used in flow identification. 761 Use of the DSCP field for flow identification is optional. 763 * If the DSCP field is used to identify a flow, then the flow 764 identification information (for that flow) includes a list of 765 DSCPs used by that flow. 767 o IPv6 flow label field. This field can be optionally used for 768 matching. When used, can be used instead of matching against the 769 Next Header field. 771 o TCP and UDP Source Port. Exact and wildcard matching is required. 772 Port ranges can optionally be used. 774 o TCP and UDP Destination Port. Exact and wildcard matching is 775 required. Port ranges can optionally be used. 777 o IPsec Header SPI field. Exact matching is required. Support for 778 wildcard matching is recommended. 780 This information MUST be provisioned per DetNet flow via 781 configuration, e.g., via the controller or management plane. 783 Information identifying a DetNet flow is ordered and implementations 784 use the first match. This can, for example, be used to provide a 785 DetNet service for a specific UDP flow, with unique Source and 786 Destination Port field values, while providing a different service 787 for the aggregate of all other flows with that same UDP Destination 788 Port value. 790 It is the responsibility of the DetNet controller plane to properly 791 provision both flow identification information and the flow specific 792 resources needed to provided the traffic treatment needed to meet 793 each flow's service requirements. This applies for aggregated and 794 individual flows. 796 7. Security Considerations 798 Security considerations for DetNet are described in detail in 799 [I-D.ietf-detnet-security]. General security considerations are 800 described in [RFC8655]. This section considers exclusively security 801 considerations which are specific to the DetNet IP data plane. 803 Security aspects which are unique to DetNet are those whose aim is to 804 provide the specific quality of service aspects of DetNet, which are 805 primarily to deliver data flows with extremely low packet loss rates 806 and bounded end-to-end delivery latency. 808 The primary considerations for the data plane is to maintain 809 integrity of data and delivery of the associated DetNet service 810 traversing the DetNet network. Application flows can be protected 811 through whatever means is provided by the underlying technology. For 812 example, encryption may be used, such as that provided by IPSec 813 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 814 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 816 From a data plane perspective this document does not add or modify 817 any header information. 819 At the management and control level DetNet flows are identified on a 820 per-flow basis, which may provide controller plane attackers with 821 additional information about the data flows (when compared to 822 controller planes that do not include per-flow identification). This 823 is an inherent property of DetNet which has security implications 824 that should be considered when determining if DetNet is a suitable 825 technology for any given use case. 827 To provide uninterrupted availability of the DetNet service, 828 provisions can be made against DOS attacks and delay attacks. To 829 protect against DOS attacks, excess traffic due to malicious or 830 malfunctioning devices can be prevented or mitigated, for example 831 through the use of existing mechanism such as policing and shaping 832 applied at the input of a DetNet domain. To prevent DetNet packets 833 from being delayed by an entity external to a DetNet domain, DetNet 834 technology definition can allow for the mitigation of Man-In-The- 835 Middle attacks, for example through use of authentication and 836 authorization of devices within the DetNet domain. 838 8. IANA Considerations 840 This document does not require an action from IANA. 842 9. Acknowledgements 844 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 845 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 846 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 847 Bernardos for their various contributions to this work. David Black 848 served as technical advisor to the DetNet working group during the 849 development of this document and provided many valuable comments. 851 10. Contributors 853 RFC7322 limits the number of authors listed on the front page of a 854 draft to a maximum of 5. The editor wishes to thank and acknowledge 855 the follow authors for contributing text to this draft. 857 Jouni Korhonen 858 Email: jouni.nospam@gmail.com 860 Andrew G. Malis 861 Malis Consulting 862 Email: agmalis@gmail.com 864 11. References 866 11.1. Normative references 868 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 869 DOI 10.17487/RFC0768, August 1980, 870 . 872 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 873 DOI 10.17487/RFC0791, September 1981, 874 . 876 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 877 RFC 793, DOI 10.17487/RFC0793, September 1981, 878 . 880 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 881 RFC 1812, DOI 10.17487/RFC1812, June 1995, 882 . 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, 886 DOI 10.17487/RFC2119, March 1997, 887 . 889 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 890 "Definition of the Differentiated Services Field (DS 891 Field) in the IPv4 and IPv6 Headers", RFC 2474, 892 DOI 10.17487/RFC2474, December 1998, 893 . 895 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 896 Switching (GMPLS) Signaling Resource ReserVation Protocol- 897 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 898 DOI 10.17487/RFC3473, January 2003, 899 . 901 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 902 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 903 December 2005, . 905 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 906 DOI 10.17487/RFC4302, December 2005, 907 . 909 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 910 RFC 4303, DOI 10.17487/RFC4303, December 2005, 911 . 913 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 914 Length Recommendation for Forwarding", BCP 198, RFC 7608, 915 DOI 10.17487/RFC7608, July 2015, 916 . 918 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 919 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 920 May 2017, . 922 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 923 (IPv6) Specification", STD 86, RFC 8200, 924 DOI 10.17487/RFC8200, July 2017, 925 . 927 11.2. Informative references 929 [I-D.ietf-detnet-data-plane-framework] 930 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 931 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 932 data-plane-framework-04 (work in progress), February 2020. 934 [I-D.ietf-detnet-dp-sol-mpls] 935 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 936 Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in 937 progress), March 2019. 939 [I-D.ietf-detnet-flow-information-model] 940 Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D. 941 Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- 942 flow-information-model-07 (work in progress), March 2020. 944 [I-D.ietf-detnet-ip-over-mpls] 945 Varga, B., Berger, L., Fedyk, D., Malis, A., Bryant, S., 946 and J. Korhonen, "DetNet Data Plane: IP over MPLS", draft- 947 ietf-detnet-ip-over-mpls-05 (work in progress), February 948 2020. 950 [I-D.ietf-detnet-ip-over-tsn] 951 Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet 952 Data Plane: IP over IEEE 802.1 Time Sensitive Networking 953 (TSN)", draft-ietf-detnet-ip-over-tsn-02 (work in 954 progress), March 2020. 956 [I-D.ietf-detnet-mpls] 957 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 958 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 959 draft-ietf-detnet-mpls-05 (work in progress), February 960 2020. 962 [I-D.ietf-detnet-security] 963 Mizrahi, T. and E. Grossman, "Deterministic Networking 964 (DetNet) Security Considerations", draft-ietf-detnet- 965 security-09 (work in progress), March 2020. 967 [I-D.ietf-detnet-tsn-vpn-over-mpls] 968 Varga, B., Farkas, J., Malis, A., Bryant, S., and D. 969 Fedyk, "DetNet Data Plane: IEEE 802.1 Time Sensitive 970 Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- 971 mpls-02 (work in progress), March 2020. 973 [I-D.ietf-detnet-yang] 974 Geng, X., Chen, M., Ryoo, Y., Li, Z., Rahman, R., and D. 975 Fedyk, "Deterministic Networking (DetNet) Configuration 976 YANG Model", draft-ietf-detnet-yang-05 (work in progress), 977 March 2020. 979 [IEEE802.1AE-2018] 980 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 981 Security (MACsec)", 2018, 982 . 984 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 985 Communication Layers", STD 3, RFC 1122, 986 DOI 10.17487/RFC1122, October 1989, 987 . 989 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 990 and W. Weiss, "An Architecture for Differentiated 991 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 992 . 994 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 995 Informal Management Model for Diffserv Routers", RFC 3290, 996 DOI 10.17487/RFC3290, May 2002, 997 . 999 [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and 1000 W. Weiss, "Information Model for Describing Network Device 1001 QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, 1002 January 2004, . 1004 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1005 Topology (MT) Routing in Intermediate System to 1006 Intermediate Systems (IS-ISs)", RFC 5120, 1007 DOI 10.17487/RFC5120, February 2008, 1008 . 1010 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 1011 Ed., and A. Lior, "Traffic Classification and Quality of 1012 Service (QoS) Attributes for Diameter", RFC 5777, 1013 DOI 10.17487/RFC5777, February 2010, 1014 . 1016 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 1017 Extensions for Associated Bidirectional Label Switched 1018 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1019 . 1021 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 1022 (Diffserv) and Real-Time Communication", RFC 7657, 1023 DOI 10.17487/RFC7657, November 2015, 1024 . 1026 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 1027 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 1028 January 2019, . 1030 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1031 "Deterministic Networking Architecture", RFC 8655, 1032 DOI 10.17487/RFC8655, October 2019, 1033 . 1035 Authors' Addresses 1037 Balazs Varga (editor) 1038 Ericsson 1039 Magyar Tudosok krt. 11. 1040 Budapest 1117 1041 Hungary 1043 Email: balazs.a.varga@ericsson.com 1045 Janos Farkas 1046 Ericsson 1047 Magyar Tudosok krt. 11. 1048 Budapest 1117 1049 Hungary 1051 Email: janos.farkas@ericsson.com 1053 Lou Berger 1054 LabN Consulting, L.L.C. 1056 Email: lberger@labn.net 1058 Don Fedyk 1059 LabN Consulting, L.L.C. 1061 Email: dfedyk@labn.net 1063 Stewart Bryant 1064 Futurewei Technologies 1066 Email: stewart.bryant@gmail.com