idnits 2.17.1 draft-ietf-detnet-ip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 5, 2019) is 1810 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 256, but not defined == Missing Reference: 'YANG-REF-TBD' is mentioned on line 705, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-12 == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-03 -- No information found for draft-ietf-detnet-framework - is the name correct? == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-04 -- No information found for draft-ietf-detnet-tsn-over-mpls - is the name correct? -- No information found for draft-ietf-ip-over-tsn - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga, Ed. 3 Internet-Draft J. Farkas 4 Intended status: Standards Track Ericsson 5 Expires: November 6, 2019 L. Berger 6 D. Fedyk 7 LabN Consulting, L.L.C. 8 A. Malis 9 S. Bryant 10 Huawei Technologies 11 J. Korhonen 12 May 5, 2019 14 DetNet Data Plane: IP 15 draft-ietf-detnet-ip-00 17 Abstract 19 This document specifies the Deterministic Networking data plane when 20 operating in an IP packet switched network. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 6, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 59 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 60 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 62 4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 6 63 4.1. End-System Specific Considerations . . . . . . . . . . . 7 64 4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7 65 4.2.1. DetNet Routers . . . . . . . . . . . . . . . . . . . 8 66 4.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.4. Class of Service . . . . . . . . . . . . . . . . . . . . 10 68 4.5. Quality of Service . . . . . . . . . . . . . . . . . . . 10 69 4.6. Cross-DetNet Flow Resource Aggregation . . . . . . . . . 10 70 4.7. Flow Identification and Aggregation . . . . . . . . . . . 11 71 4.8. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 11 72 4.9. Aggregation Considerations . . . . . . . . . . . . . . . 12 73 5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 12 74 5.1. DetNet IP Flow Identification Procedures . . . . . . . . 13 75 5.1.1. IP Header Information . . . . . . . . . . . . . . . . 13 76 5.1.2. Other Protocol Header Information . . . . . . . . . . 14 77 5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 15 78 5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 16 79 6. Flow Identification Management and Control Information . . . 16 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 11.1. Normative references . . . . . . . . . . . . . . . . . . 19 86 11.2. Informative references . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 Deterministic Networking (DetNet) is a service that can be offered by 92 a network to DetNet flows. DetNet provides these flows extremely low 93 packet loss rates and assured maximum end-to-end delivery latency. 94 General background and concepts of DetNet can be found in the DetNet 95 Architecture [I-D.ietf-detnet-architecture]. 97 This document specifies the DetNet data plane operation for IP hosts 98 and routers that provide DetNet service to IP encapsulated data. No 99 DetNet specific encapsulation is defined to support IP flows, instead 100 the existing IP and higher layer protocol header information is used 101 to support flow identification and DetNet service delivery. Common 102 data plane procedures and control information for all DetNet data 103 planes can be found in the [I-D.ietf-detnet-framework]. 105 The DetNet Architecture models the DetNet related data plane 106 functions decomposed into two sub-layers: functions into two sub- 107 layers: a service sub-layer and a forwarding sub-layer. The service 108 sub-layer is used to provide DetNet service protection and 109 reordering. The forwarding sub-layer is used to provides congestion 110 protection (low loss, assured latency, and limited reordering). 111 Since no DetNet specific headers are added to support DetNet IP 112 flows, only the forwarding sub-layer functions are supported using 113 the DetNet IP defined by this document. Service protection can be 114 provided on a per sub-net basis using technologies such as MPLS 115 [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified in the IEEE 116 802.1 TSN task group(referred to in this document simply as IEEE802.1 117 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. 125 2. Terminology 127 2.1. Terms Used In This Document 129 This document uses the terminology and concepts established in the 130 DetNet architecture [I-D.ietf-detnet-architecture], and the reader is 131 assumed to be familiar with that document and its terminology. 133 2.2. Abbreviations 135 The following abbreviations used in this document: 137 CoS Class of Service. 139 DetNet Deterministic Networking. 141 DN DetNet. 143 DiffServ Differentiated Services 144 DSCP Differentiated Services Code Point 146 L2 Layer-2. 148 L3 Layer-3. 150 LSP Label-switched path. 152 MPLS Multiprotocol Label Switching. 154 OAM Operations, Administration, and Maintenance. 156 PE Provider Edge. 158 PREOF Packet Replication, Ordering and Elimination Function. 160 PSN Packet Switched Network. 162 PW Pseudowire. 164 QoS Quality of Service. 166 TE Traffic Engineering. 168 TSN Time-Sensitive Networking, TSN is a Task Group of the 169 IEEE 802.1 Working Group. 171 2.3. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 3. DetNet IP Data Plane Overview 181 This document describes how IP is used by DetNet nodes, i.e., hosts 182 and routers, identify DetNet flows and provide a DetNet service using 183 an IP data plane. From a data plane perspective, an end-to-end IP 184 model is followed. As mentioned above, existing IP and higher layer 185 protocol header information is used to support flow identification 186 and DetNet service delivery. Common data plane procedures and 187 control information for all DetNet data planes can be found in the 188 [I-D.ietf-detnet-framework]. 190 The DetNet IP data plane uses "6-tuple" based flow identification, 191 where 6-tuple refers to information carried in IP and higher layer 192 protocol headers. The 6-tuple referred to in this document is the 193 same as that defined in [RFC3290]. Specifically 6-tuple is 194 (destination address, source address, IP protocol, source port, 195 destination port, and differentiated services (DiffServ) code point 196 (DSCP). General background on the use of IP headers, and 5-tuples, 197 to identify flows and support Quality of Service (QoS) can be found 198 in [RFC3670]. [RFC7657] also provides useful background on the 199 delivery of DiffServ and "tuple" based flow identification. 200 Referring to a 6-tuple allows DetNet nodes to forward packets with 201 the 6-tuple as is or remap the DSCP where required by the DetNet 202 service. 204 DetNet flow aggregation may be enabled via the use of wildcards, 205 masks, prefixes and ranges. IP tunnels may also be used to support 206 flow aggregation. In these cases, it is expected that DetNet aware 207 intermediate nodes will provide DetNet service assurance on the 208 aggregate through resource allocation and congestion control 209 mechanisms. 211 DetNet IP Relay Relay DetNet IP 212 End System Node Node End System 214 +----------+ +----------+ 215 | Appl. |<------------ End to End Service ----------->| Appl. | 216 +----------+ ............ ........... +----------+ 217 | Service |<-: Service :-- DetNet flow --: Service :->| Service | 218 +----------+ +----------+ +----------+ +----------+ 219 |Forwarding| |Forwarding| |Forwarding| |Forwarding| 220 +--------.-+ +-.------.-+ +-.---.----+ +-------.--+ 221 : Link : \ ,-----. / \ ,-----. / 222 +......+ +----[ Sub ]----+ +-[ Sub ]-+ 223 [Network] [Network] 224 `-----' `-----' 226 |<--------------------- DetNet IP --------------------->| 228 Figure 1: A Simple DetNet (DN) Enabled IP Network 230 Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled 231 end systems originate IP encapsulated traffic that is identified as 232 DetNet flows, relay nodes understand the forwarding requirements of 233 the DetNet flow and ensure that node, interface and sub-network 234 resources are allocated to ensure DetNet service requirements. The 235 dotted line around the Service component of the Relay Nodes indicates 236 that the transit routers are DetNet service aware but do not perform 237 any DetNet service sub-layer function, e.g., PREOF. IEEE 802.1 TSN 238 is an example sub-network type which can provide support for DetNet 239 flows and service. 241 Note: The sub-network can represent a TSN, MPLS or IP network 242 segment. 244 IP Edge Edge IP 245 End System Node Node End System 247 +----------+ +.........+ +.........+ +----------+ 248 | Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. | 249 +----------+ +.........+ +.........+ +----------+ 250 | IP |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->| IP | 251 +----------+ +---+ +---+ +---+ +---+ +----------+ 252 |Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding| 253 +--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ 254 : Link : \ ,-----. / / ,-----. \ 255 +.......+ +----[ Sub ]----+ +--[ Sub ]--+ 256 [Network] [Network] 257 `-----' `-----' 259 |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->| 261 Figure 2: Non-DetNet aware IP end systems with DetNet IP Domain 263 Figure 2 illustrates a variant of Figure 1 where the end systems are 264 not DetNet aware. In this case, edge nodes sit at the boundary of 265 the DetNet domain and provide DetNet service proxies for the end 266 applications by initiating and terminating DetNet service for the 267 application's IP flows. The existing header information or an 268 approach such as described in Section 4.6 can be used to support 269 DetNet flow identification. 271 Non-DetNet and DetNet IP packets are identical on the wire. From 272 data plane perspective, the only difference is that there is flow- 273 associated DetNet information on each DetNet node that defines the 274 flow related characteristics and required forwarding behavior. As 275 shown above, edge nodes provide a Service Proxy function that 276 "associates" one or more IP flows with the appropriate DetNet flow- 277 specific information and ensures that the receives the proper traffic 278 treatment within the domain. 280 Note: The operation of IEEE802.1 TSN end systems over DetNet enabled 281 IP networks is not described in this document. TSN over MPLS is 282 discribed in [I-D.ietf-detnet-tsn-over-mpls]. 284 4. DetNet IP Data Plane Considerations 286 This section provides informative considerations related to providing 287 DetNet service to flows which are identified based on their header 288 information. 290 4.1. End-System Specific Considerations 292 Data-flows requiring DetNet service are generated and terminated on 293 end systems. This document deals only with IP end systems. The 294 protocols used by an IP end system are specific to an application and 295 end systems peer with end systems using the same application 296 encapsulation format. This said, DetNet's use of 6-tuple IP flow 297 identification means that DetNet must be aware of not only the format 298 of the IP header, but also of the next protocol carried within an IP 299 packet. 301 When IP end systems are DetNet aware, no application-level or 302 service-level proxy functions are needed inside the DetNet domain. 303 For DetNet unaware IP end systems service-level proxy functions are 304 needed inside the DetNet domain. 306 End systems need to ensure that DetNet service requirements are met 307 when processing packets associated with a DetNet flow. When 308 forwarding packets, this means that packets are appropriately shaped 309 on transmission and received appropriate traffic treatment on the 310 connected sub-network, see Section 4.5 and Section 4.2.1 for more 311 details. When receiving packets, this means that there are 312 appropriate local node resources, e.g., buffers, to receive and 313 process a DetNet flow packets. 315 4.2. DetNet Domain-Specific Considerations 317 As a general rule, DetNet IP domains need to be able to forward any 318 DetNet flow identified by the IP 6-tuple. Doing otherwise would 319 limit end system encapsulation format. From a practical standpoint 320 this means that all nodes along the end-to-end path of DetNet flows 321 need to agree on what fields are used for flow identification, and 322 the transport protocols (e.g., TCP/UDP/IPsec) which can be used to 323 identify 6-tuple protocol ports. 325 From a connection type perspective two scenarios are identified: 327 1. DN attached: end system is directly connected to an edge node or 328 end system is behind a sub-network. (See ES1 and ES2 in figure 329 below) 331 2. DN integrated: end system is part of the DetNet domain. (See ES3 332 in figure below) 334 L3 (IP) end systems may use any of these connection types. A DetNet 335 domain allows communication between any end-systems using the same 336 encapsulation format, independent of their connection type and DetNet 337 capability. DN attached end systems have no knowledge about the 338 DetNet domain and its encapsulation format. See Figure 3 for L3 end 339 system connection examples. 341 ____+----+ 342 +----+ _____ / | ES3| 343 | ES1|____ / \__/ +----+___ 344 +----+ \ / \ 345 + | 346 ____ \ _/ 347 +----+ __/ \ +__ DetNet IP domain / 348 | ES2|____/ L2/L3 |___/ \ __ __/ 349 +----+ \_______/ \_______/ \___/ 351 Figure 3: Connection types of L3 end systems 353 4.2.1. DetNet Routers 355 Within a DetNet domain, the DetNet enabled IP Routers interconnect 356 links and sub-networks to support end-to-end delivery of DetNet 357 flows. From a DetNet architecture perspective, these routers are 358 DetNet relays, as they must be DetNet service aware. Such routers 359 identify DetNet flows based on the IP 6-tuple, and ensure that the 360 DetNet service required traffic treatment is provided both on the 361 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 protections (packet replication and packet 368 elimination functions) are 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 +------+ +------+ 373 | X | | X | 374 +======+ +------+ 375 End-system | IP | | IP | 376 -----+------+-------+======+--- --+======+-- 377 DetNet |L2/SbN| |L2/SbN| 378 +------+ +------+ 380 Figure 4: Encapsulation of DetNet Routing in simplified IP service L3 381 end-systems 383 The DetNet Service Flow is mapped to the link / sub-network specific 384 resources using an underlying system specific means. This implies 385 each DetNet aware node on path looks into the forwarded DetNet 386 Service Flow packet and utilize e.g., a 5- (or 6-) tuple to find out 387 the required mapping within a node. 389 As noted earlier, the Service Protection is done within each link / 390 sub-network independently using the domain specific mechanisms (due 391 the lack of a unified end to end sequencing information that would be 392 available for intermediate nodes). Therefore, service protection (if 393 enabled) cannot be provided end-to-end, only within sub-networks. 394 This is shown for a three sub-network scenario in Figure 5, where 395 each sub-network can provide service protection between its borders. 397 ______ 398 ____ / \__ 399 ____ / \__/ \___ ______ 400 +----+ __/ +====+ +==+ \ +----+ 401 |src |__/ SubN1 ) | | \ SubN3 \____| dst| 402 +----+ \_______/ \ Sub-Network2 | \______/ +----+ 403 \_ _/ 404 \ __ __/ 405 \_______/ \___/ 407 +---+ +---------E--------+ +-----+ 408 +----+ | | | | | | | +----+ 409 |src |----R E--------R +---+ E------R E------+ dst| 410 +----+ | | | | | | | +----+ 411 +---+ +-----R------------+ +-----+ 413 Figure 5: Replication and elimination in sub-networks for DetNet IP 414 networks 416 If end to end service protection is desired, it can be implemented, 417 for example, by the DetNet end systems using Layer-4 (L4) transport 418 protocols or application protocols. However, these protocols are out 419 of scope of this document. 421 4.3. OAM 423 [Editor's note: This section is TBD. OAM may be dropped from this 424 document and left for future study.] 426 4.4. Class of Service 428 Class of Service (CoS) for DetNet flows carried in IPv6 is provided 429 using the standard differentiated services code point (DSCP) field 430 [RFC2474] and related mechanisms. The 2-bit explicit congestion 431 notification (ECN) [RFC3168] field MAY also be used. 433 One additional consideration for DetNet nodes which support CoS 434 services is that they MUST ensure that the CoS service classes do not 435 impact the congestion protection and latency control mechanisms used 436 to provide DetNet QoS. This requirement is similar to requirement 437 for MPLS LSRs to that CoS LSPs do not impact the resources allocated 438 to TE LSPs via [RFC3473]. 440 4.5. Quality of Service 442 Quality of Service (QoS) for DetNet service flows carried in IP MUST 443 be provided locally by the DetNet-aware hosts and routers supporting 444 DetNet flows. Such support leverages the underlying network layer 445 such as 802.1 TSN. The traffic control mechanisms used to deliver 446 QoS for IP encapsulated DetNet flows are expected to be defined in a 447 future document. From an encapsulation perspective, the combination 448 of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP code, 449 uniquely identifies a DetNet service flow. 451 Packets that are marked with a DetNet Class of Service value, but 452 that have not been the subject of a completed reservation, can 453 disrupt the QoS offered to properly reserved DetNet flows by using 454 resources allocated to the reserved flows. Therefore, the network 455 nodes of a DetNet network must: 457 o Defend the DetNet QoS by discarding or remarking (to a non-DetNet 458 CoS) packets received that are not the subject of a completed 459 reservation. 461 o Not use a DetNet reserved resource, e.g. a queue or shaper 462 reserved for DetNet flows, for any packet that does not carry a 463 DetNet Class of Service marker. 465 4.6. Cross-DetNet Flow Resource Aggregation 467 The ability to aggregate individual flows, and their associated 468 resource control, into a larger aggregate is an important technique 469 for improving scaling of messaging in the data, management and 470 control planes. This document identifies the traffic identification 471 related aspects of aggregation of DetNet flows. The resource control 472 and management aspects of aggregation (including the queuing/shaping/ 473 policing implications) will be covered in other documents. The data 474 plane implications of aggregation are independent for PW/MPLS and IP 475 encapsulated DetNet flows. 477 DetNet flows forwarded via IP have more limited aggregation options, 478 due to the available traffic flow identification fields of the IP 479 solution. One available approach is to manage the resources 480 associated with a DSCP identified traffic class and to map (remark) 481 individually controlled DetNet flows onto that traffic class. This 482 approach also requires that nodes support aggregation ensure that 483 traffic from aggregated LSPs are placed (shaped/policed/enqueued) in 484 a fashion that ensures the required DetNet service is preserved. 486 In both the MPLS and IP cases, additional details of the traffic 487 control capabilities needed at a DetNet-aware node may be covered in 488 the new service descriptions mentioned above or in separate future 489 documents. Management and control plane mechanisms will also need to 490 ensure that the service required on the aggregate flow (H-LSP or 491 DSCP) are provided, which may include the discarding or remarking 492 mentioned in the previous sections. 494 4.7. Flow Identification and Aggregation 496 Section 3 introduces the use of the IP "6-tuple" for flow 497 identification, and Section 4.5 goes on to discuss how identified 498 flows use specific QoS mechanisms for flow-specific traffic 499 treatment, including path control and resource allocation. 500 Section 5.1 contains detailed DetNet IP flow identification 501 procedures. Flow identification plays an important role for the 502 DetNet controller plane. 504 Section 4.6 and Section 4.9 discuss the use of flow aggregation in 505 DetNet. Flow aggregation can be accomplished using any of the 506 6-tuple fields defined in Section 5.1, using a DSCP identified 507 traffic class or other field. It will be the responsibility of the 508 DetNet controller plane to be able to properly provision the use of 509 these aggregation mechanisms. 511 4.8. Bidirectional Traffic 513 While the DetNet IP data plane must support bidirectional DetNet 514 flows, there are no special bidirectional features with respect to 515 the data plane other than the need for the two directions of a co- 516 routed bidirectional flow to take the same path. That is to say that 517 bidirectional DetNet flows are solely represented at the management 518 and control plane levels, without specific support or knowledge 519 within the DetNet data plane. Fate sharing and associated or co- 520 routed bidirectional flows can be managed at the control level. 522 Control and management mechanisms need to support bidirectional 523 flows, but the specification of such mechanisms are out of scope of 524 this document. An example control plane solution for MPLS can be 525 found in [RFC7551]. 527 4.9. Aggregation Considerations 529 The use of prefixes, wildcards, bitmasks, and port ranges allows a 530 DetNet node to aggregate DetNet flows. This aggregation can take 531 place within a single node, when that node maintains state about both 532 the aggregated and component flows. It can also take place between 533 nodes, where one node maintains state about only flow aggregates 534 while the other node maintains state on all or a portion of the 535 component flows. In either case, the management or control function 536 that provisions the aggregate flows must ensure that adequate 537 resources are allocated and configured to provide combined service 538 requirements of the component flows. As DetNet is concerned about 539 latency and jitter, more than just bandwidth needs to be considered. 541 5. DetNet IP Data Plane Procedures 543 This section provides DetNet IP data plane procedures. These 544 procedures have been divided into the following areas: flow 545 identification, forwarding and traffic treatment. Flow 546 identification includes those procedures related to matching IP and 547 higher layer protocol header information to DetNet flow (state) 548 information and service requirements. Flow identification is also 549 sometimes called Traffic classification, for example see [RFC5777]. 550 Forwarding includes those procedures related to next hop selection 551 and delivery. Traffic treatment includes those procedures related to 552 providing an identified flow with the required DetNet service. 554 DetNet IP data plane establishment and operational procedures also 555 have requirements on the control and management systems for DetNet 556 flows and these are covered in this section. Specifically this 557 section identifies a number of information elements that require 558 support via the management and control interfaces supported by a 559 DetNet node. The specific mechanism used for such support is out of 560 the scope of this document. A summary of the requirements for 561 management and control related information is included. Conformance 562 language is not used in the summary since applies to future 563 mechanisms such as those that may be provided in YANG models [YANG- 564 REF-TBD]. 566 5.1. DetNet IP Flow Identification Procedures 568 IP and higher layer protocol header information is used to identify 569 DetNet flows. All DetNet implementations that support this document 570 MUST identify individual DetNet flows based on the set of information 571 identified in this section. Note, that additional flow 572 identification requirements, e.g., to support other higher layer 573 protocols, may be defined in future. 575 The configuration and control information used to identify an 576 individual DetNet flow MUST be ordered by an implementation. 577 Implementations MUST support a fixed order when identifying flows, 578 and MUST identify a DetNet flow by the first set of matching flow 579 information. 581 Implementations of this document MUST support DetNet flow 582 identification when the implementation is acting as a DetNet end 583 systems, a relay node or as an edge node. 585 5.1.1. IP Header Information 587 Implementations of this document MUST support DetNet flow 588 identification based on IP header information. The IPv4 header is 589 defined in [RFC0791] and the IPv6 is defined in [RFC8200]. 591 5.1.1.1. Source Address Field 593 Implementations of this document MUST support DetNet flow 594 identification based on the Source Address field of an IP packet. 595 Implementations SHOULD support longest prefix matching for this 596 field, see [RFC1812] and [RFC7608]. Note that a prefix length of 597 zero (0) effectively means that the field is ignored. 599 5.1.1.2. Destination Address Field 601 Implementations of this document MUST support DetNet flow 602 identification based on the Destination Address field of an IP 603 packet. Implementations SHOULD support longest prefix matching for 604 this field, see [RFC1812] and [RFC7608]. Note that a prefix length 605 of zero (0) effectively means that the field is ignored. 607 Note: any IP address value is allowed, including an IP multicast 608 destination address. 610 5.1.1.3. IPv4 Protocol and IPv6 Next Header Fields 612 Implementations of this document MUST support DetNet flow 613 identification based on the IPv4 Protocol field when processing IPv4 614 packets, and the IPv6 Next Header Field when processing IPv6 packets. 615 An implementation MUST support flow identification based based the 616 next protocol values defined in Section 5.1.2. Other, non-zero 617 values, MUST be used for flow identification. Implementations SHOULD 618 allow for these fields to be ignored for a specific DetNet flow. 620 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields 622 These fields are used to support Differentiated Services [RFC2474] 623 and Explicit Congestion Notification [RFC3168]. Implementations of 624 this document MUST support DetNet flow identification based on the 625 IPv4 Type of Service field when processing IPv4 packets, and the IPv6 626 Traffic Class Field when processing IPv6 packets. Implementations 627 MUST support bitmask based matching, where bits set to one (1) in the 628 bitmask indicate which subset of the bits in the field are to be used 629 in determining a match. Note that all bits set to zero (0) value as 630 a bitmask effectively means that these fields are ignored. 632 5.1.1.5. IPv6 Flow Label Field 634 Implementations of this document SHOULD support identification of 635 DetNet flows based on the IPv6 Flow Label field. Implementations 636 that support matching based on this field MUST allow for this field 637 to be ignored for a specific DetNet flow. When this field is used to 638 identify a specific DetNet flow, implementations MAY exclude the IPv6 639 Next Header field and next header information as part of DetNet flow 640 identification. 642 5.1.2. Other Protocol Header Information 644 Implementations of this document MUST support DetNet flow 645 identification based on header information identified in this 646 section. Support for TCP, UDP and IPsec flows is defined. Future 647 documents are expected to define support for other protocols. 649 5.1.2.1. TCP and UDP 651 DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is 652 achieved based on the Source and Destination Port fields carried in 653 each protocol's header. These fields share a common format and 654 common DetNet flow identification procedures. 656 5.1.2.1.1. Source Port Field 658 Implementations of this document MUST support DetNet flow 659 identification based on the Source Port field of a TCP or UDP packet. 660 Implementations MUST support flow identification based on a 661 particular value carried in the field, i.e., an exact value. 662 Implementations SHOULD support range-based port matching. 663 Implementation MUST also allow for the field to be ignored for a 664 specific DetNet flow. 666 5.1.2.1.2. Destination Port Field 668 Implementations of this document MUST support DetNet flow 669 identification based on the Destination Port field of a TCP or UDP 670 packet. Implementations MUST support flow identification based on a 671 particular value carried in the field, i.e., an exact value. 672 Implementations SHOULD support range-based port matching. 673 Implementation MUST also allow for the field to be ignored for a 674 specific DetNet flow. 676 5.1.2.2. IPsec AH and ESP 678 IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security 679 Payload (ESP) [RFC4303] share a common format for the Security 680 Parameters Index (SPI) field. Implementations MUST support flow 681 identification based on a particular value carried in the field, 682 i.e., an exact value. Implementation SHOULD also allow for the field 683 to be ignored for a specific DetNet flow. 685 5.2. Forwarding Procedures 687 General requirements for IP nodes are defined in [RFC1122], [RFC1812] 688 and [RFC6434], and are not modified by this document. The typical 689 next-hop selection process is impacted by DetNet. Specifically, 690 implementations of this document SHALL use management and control 691 information to select the one or more outgoing interfaces and next 692 hops to be used for a packet belonging to a DetNet flow. 694 The use of multiple paths or links, e.g., ECMP, to support a single 695 DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet 696 flows within a DetNet domain. 698 The above implies that management and control functions will be 699 defined to support this requirement, e.g., see [YANG-REF-TBD]. 701 5.3. DetNet IP Traffic Treatment Procedures 703 Implementations if this document MUST ensure that a DetNet flow 704 receives the traffic treatment that is provisioned for it via 705 configuration or the controller plane, e.g., via [YANG-REF-TBD]. 706 General information on DetNet service can be found in 707 [I-D.ietf-detnet-flow-information-model]. Typical mechanisms used to 708 provide different treatment to different flows includes the 709 allocation of system resources (such as queues and buffers) and 710 provisioning or related parameters (such as shaping, and policing). 711 Support can also be provided via an underlying network technology 712 such as MPLS [I-D.ietf-detnet-ip-over-mpls]. and IEEE802.1 TSN 713 [I-D.ietf-ip-over-tsn]. Other than in the TSN case, the specific 714 mechanisms used by a DetNet node to ensure DetNet service delivery 715 requirements are met for supported DetNet flows is outside the scope 716 of this document. 718 6. Flow Identification Management and Control Information 720 The following summarizes the set of information that is needed to 721 identify an individual DetNet flow: 723 o IPv4 and IPv6 source address field. 725 o IPv4 and IPv6 source address prefix length, where a zero (0) value 726 effectively means that the address field is ignored. 728 o IPv4 and IPv6 destination address field. 730 o IPv4 and IPv6 destination address prefix length, where a zero (0) 731 effectively means that the address field is ignored. 733 o IPv4 protocol field. A limited set of values is allowed, and the 734 ability to ignore this field, e.g., via configuration of the value 735 zero (0), is desirable. 737 o IPv6 next header field. A limited set of values is allowed, and 738 the ability to ignore this field, e.g., via configuration of the 739 value zero (0), is desirable. 741 o IPv4 Type of Service and IPv6 Traffic Class Fields. 743 o IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a 744 zero (0) effectively means that theses fields are ignored. 746 o IPv6 flow label field. This field can be optionally used for 747 matching. When used, can be exclusive of matching against the 748 next header field. 750 o TCP and UDP Source Port. Exact and wildcard matching is required. 751 Port ranges can optionally be used. 753 o TCP and UDP Destination Port. Exact and wildcard matching is 754 required. Port ranges can optionally be used. 756 This information MUST be provisioned per DetNet flow via 757 configuration, e.g., via the controller or management plane. 759 Information identifying a DetNet flow is ordered and implementations 760 use the first match. This can, for example, be used to provide a 761 DetNet service for a specific UDP flow, with unique Source and 762 Destination Port field values, while providing a different service 763 for all other flows with that same UDP Destination Port value. 765 7. Security Considerations 767 The security considerations of DetNet in general are discussed in 768 [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. Other 769 security considerations will be added in a future version of this 770 draft. 772 8. IANA Considerations 774 TBD. 776 9. Contributors 778 RFC7322 limits the number of authors listed on the front page of a 779 draft to a maximum of 5, far fewer than the 20 individuals below who 780 made important contributions to this draft. The editor wishes to 781 thank and acknowledge each of the following authors for contributing 782 text to this draft. See also Section 10. 784 Loa Andersson 785 Huawei 786 Email: loa@pi.nu 788 Yuanlong Jiang 789 Huawei 790 Email: jiangyuanlong@huawei.com 792 Norman Finn 793 Huawei 794 3101 Rio Way 795 Spring Valley, CA 91977 796 USA 797 Email: norman.finn@mail01.huawei.com 799 Janos Farkas 800 Ericsson 801 Magyar Tudosok krt. 11 802 Budapest 1117 803 Hungary 804 Email: janos.farkas@ericsson.com 806 Carlos J. Bernardos 807 Universidad Carlos III de Madrid 808 Av. Universidad, 30 809 Leganes, Madrid 28911 810 Spain 811 Email: cjbc@it.uc3m.es 813 Tal Mizrahi 814 Marvell 815 6 Hamada st. 816 Yokneam 817 Israel 818 Email: talmi@marvell.com 820 Lou Berger 821 LabN Consulting, L.L.C. 822 Email: lberger@labn.net 824 Andrew G. Malis 825 Huawei Technologies 826 Email: agmalis@gmail.com 828 Don Fedyk 829 LabN Consulting, L.L.C. 830 Email: dfedyk@labn.net 832 10. Acknowledgements 834 The author(s) ACK and NACK. 836 The following people were part of the DetNet Data Plane Solution 837 Design Team: 839 Jouni Korhonen 841 Janos Farkas 843 Norman Finn 845 Balazs Varga 847 Loa Andersson 849 Tal Mizrahi 851 David Mozes 853 Yuanlong Jiang 855 Andrew Malis 857 Carlos J. Bernardos 859 The DetNet chairs serving during the DetNet Data Plane Solution 860 Design Team: 862 Lou Berger 864 Pat Thaler 866 Thanks for Stewart Bryant for his extensive review of the previous 867 versions of the document. 869 11. References 871 11.1. Normative references 873 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 874 DOI 10.17487/RFC0768, August 1980, 875 . 877 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 878 DOI 10.17487/RFC0791, September 1981, 879 . 881 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 882 RFC 793, DOI 10.17487/RFC0793, September 1981, 883 . 885 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 886 RFC 1812, DOI 10.17487/RFC1812, June 1995, 887 . 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels", BCP 14, RFC 2119, 891 DOI 10.17487/RFC2119, March 1997, 892 . 894 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 895 "Definition of the Differentiated Services Field (DS 896 Field) in the IPv4 and IPv6 Headers", RFC 2474, 897 DOI 10.17487/RFC2474, December 1998, 898 . 900 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 901 of Explicit Congestion Notification (ECN) to IP", 902 RFC 3168, DOI 10.17487/RFC3168, September 2001, 903 . 905 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 906 Switching (GMPLS) Signaling Resource ReserVation Protocol- 907 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 908 DOI 10.17487/RFC3473, January 2003, 909 . 911 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 912 DOI 10.17487/RFC4302, December 2005, 913 . 915 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 916 RFC 4303, DOI 10.17487/RFC4303, December 2005, 917 . 919 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 920 Length Recommendation for Forwarding", BCP 198, RFC 7608, 921 DOI 10.17487/RFC7608, July 2015, 922 . 924 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 925 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 926 May 2017, . 928 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 929 (IPv6) Specification", STD 86, RFC 8200, 930 DOI 10.17487/RFC8200, July 2017, 931 . 933 11.2. Informative references 935 [I-D.ietf-detnet-architecture] 936 Finn, N., Thubert, P., Varga, B., and J. Farkas, 937 "Deterministic Networking Architecture", draft-ietf- 938 detnet-architecture-12 (work in progress), March 2019. 940 [I-D.ietf-detnet-dp-sol-mpls] 941 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 942 Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in 943 progress), March 2019. 945 [I-D.ietf-detnet-flow-information-model] 946 Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet 947 Flow Information Model", draft-ietf-detnet-flow- 948 information-model-03 (work in progress), March 2019. 950 [I-D.ietf-detnet-framework] 951 Korhonen, J., Varga, B., "DetNet Data Plane Framework", 952 2019. 954 [I-D.ietf-detnet-ip-over-mpls] 955 Korhonen, J., Varga, B., "DetNet IP over DetNet MPLS Data 956 Plane", 2019. 958 [I-D.ietf-detnet-security] 959 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 960 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 961 Networking (DetNet) Security Considerations", draft-ietf- 962 detnet-security-04 (work in progress), March 2019. 964 [I-D.ietf-detnet-tsn-over-mpls] 965 Varga, B., "DetNet Data Plane: IEEE 802.1 Time Sensitive 966 Networking over MPLS", 2019. 968 [I-D.ietf-ip-over-tsn] 969 Korhonen, J., Varga, B., "DetNet Data Plane: IP over IEEE 970 802.1 Time Sensitive Networking (TSN)", 2019. 972 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 973 Communication Layers", STD 3, RFC 1122, 974 DOI 10.17487/RFC1122, October 1989, 975 . 977 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 978 Informal Management Model for Diffserv Routers", RFC 3290, 979 DOI 10.17487/RFC3290, May 2002, 980 . 982 [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and 983 W. Weiss, "Information Model for Describing Network Device 984 QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, 985 January 2004, . 987 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 988 Ed., and A. Lior, "Traffic Classification and Quality of 989 Service (QoS) Attributes for Diameter", RFC 5777, 990 DOI 10.17487/RFC5777, February 2010, 991 . 993 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 994 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 995 2011, . 997 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 998 Extensions for Associated Bidirectional Label Switched 999 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1000 . 1002 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 1003 (Diffserv) and Real-Time Communication", RFC 7657, 1004 DOI 10.17487/RFC7657, November 2015, 1005 . 1007 Authors' Addresses 1009 Balazs Varga (editor) 1010 Ericsson 1011 Magyar Tudosok krt. 11. 1012 Budapest 1117 1013 Hungary 1015 Email: balazs.a.varga@ericsson.com 1017 Janos Farkas 1018 Ericsson 1019 Magyar Tudosok krt. 11. 1020 Budapest 1117 1021 Hungary 1023 Email: janos.farkas@ericsson.com 1024 Lou Berger 1025 LabN Consulting, L.L.C. 1027 Email: lberger@labn.net 1029 Don Fedyk 1030 LabN Consulting, L.L.C. 1032 Email: dfedyk@labn.net 1034 Andrew G. Malis 1035 Huawei Technologies 1037 Email: agmalis@gmail.com 1039 Stewart Bryant 1040 Huawei Technologies 1042 Email: stewart.bryant@gmail.com 1044 Jouni Korhonen 1046 Email: jouni.nospam@gmail.com