idnits 2.17.1 draft-ietf-detnet-ip-01.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 (July 1, 2019) is 1758 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 244, 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-00 == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-03 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-ip-over-mpls-00 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-00 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-04 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-tsn-vpn-over-mpls-00 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-yang-02 -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga, Ed. 3 Internet-Draft J. Farkas 4 Intended status: Standards Track Ericsson 5 Expires: January 2, 2020 L. Berger 6 D. Fedyk 7 LabN Consulting, L.L.C. 8 A. Malis 9 S. Bryant 10 Futurewei Technologies 11 J. Korhonen 12 July 1, 2019 14 DetNet Data Plane: IP 15 draft-ietf-detnet-ip-01 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 January 2, 2020. 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.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 9 66 4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 9 67 4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10 68 4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 10 69 4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 11 70 5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 11 71 5.1. DetNet IP Flow Identification Procedures . . . . . . . . 12 72 5.1.1. IP Header Information . . . . . . . . . . . . . . . . 12 73 5.1.2. Other Protocol Header Information . . . . . . . . . . 13 74 5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 14 75 5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 15 76 6. Management and Control Information Summary . . . . . . . . . 15 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 10.1. Normative references . . . . . . . . . . . . . . . . . . 17 82 10.2. Informative references . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 extremely low 89 packet loss rates and assured maximum end-to-end delivery latency. 90 General background and concepts of DetNet can be found in the DetNet 91 Architecture [I-D.ietf-detnet-architecture]. 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 decomposed into two sub-layers: functions into two sub- 103 layers: a service sub-layer and a forwarding sub-layer. The service 104 sub-layer is used to provide DetNet service protection and 105 reordering. The forwarding sub-layer is used to provides congestion 106 protection (low loss, assured latency, and limited out-of-order 107 delivery). Since no DetNet specific headers are added to support 108 DetNet IP flows, only the forwarding sub-layer functions are 109 supported using the DetNet IP defined by this document. Service 110 protection can be provided on a per sub-net basis using technologies 111 such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified 112 in the IEEE 802.1 TSN task group(referred to in this document simply 113 as IEEE802.1 TSN). 115 This document provides an overview of the DetNet IP data plane in 116 Section 3, considerations that apply to providing DetNet services via 117 the DetNet IP data plane in Section 4. Section 5 provides the 118 procedures for hosts and routers that support IP-based DetNet 119 services. Section 6 summarizes the set of information that is needed 120 to identify an individual DetNet flow. 122 2. Terminology 124 2.1. Terms Used In This Document 126 This document uses the terminology and concepts established in the 127 DetNet architecture [I-D.ietf-detnet-architecture], and the reader is 128 assumed to be familiar with that document and its terminology. 130 2.2. Abbreviations 132 The following abbreviations used in this document: 134 CoS Class of Service. 136 DetNet Deterministic Networking. 138 DN DetNet. 140 DiffServ Differentiated Services 142 DSCP Differentiated Services Code Point 144 L2 Layer-2. 146 L3 Layer-3. 148 LSP Label-switched path. 150 MPLS Multiprotocol Label Switching. 152 PREOF Packet Replication, Ordering and Elimination Function. 154 QoS Quality of Service. 156 TSN Time-Sensitive Networking, TSN is a Task Group of the 157 IEEE 802.1 Working Group. 159 2.3. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 3. DetNet IP Data Plane Overview 169 This document describes how IP is used by DetNet nodes, i.e., hosts 170 and routers, identify DetNet flows and provide a DetNet service using 171 an IP data plane. From a data plane perspective, an end-to-end IP 172 model is followed. As mentioned above, existing IP and higher layer 173 protocol header information is used to support flow identification 174 and DetNet service delivery. Common data plane procedures and 175 control information for all DetNet data planes can be found in the 176 [I-D.ietf-detnet-data-plane-framework]. 178 The DetNet IP data plane uses "6-tuple" based flow identification, 179 where 6-tuple refers to information carried in IP and higher layer 180 protocol headers. The 6-tuple referred to in this document is the 181 same as that defined in [RFC3290]. Specifically 6-tuple is 182 (destination address, source address, IP protocol, source port, 183 destination port, and differentiated services (DiffServ) code point 184 (DSCP). General background on the use of IP headers, and 5-tuples, 185 to identify flows and support Quality of Service (QoS) can be found 186 in [RFC3670]. [RFC7657] also provides useful background on the 187 delivery of DiffServ and "tuple" based flow identification. 188 Referring to a 6-tuple allows DetNet nodes to forward packets with 189 the 6-tuple as is or remap the DSCP where required by the DetNet 190 service. 192 DetNet flow aggregation may be enabled via the use of wildcards, 193 masks, prefixes and ranges. IP tunnels may also be used to support 194 flow aggregation. In these cases, it is expected that DetNet aware 195 intermediate nodes will provide DetNet service assurance on the 196 aggregate through resource allocation and congestion control 197 mechanisms. 199 DetNet IP Relay Relay DetNet IP 200 End System Node Node End System 202 +----------+ +----------+ 203 | Appl. |<------------ End to End Service ----------->| Appl. | 204 +----------+ ............ ........... +----------+ 205 | Service |<-: Service :-- DetNet flow --: Service :->| Service | 206 +----------+ +----------+ +----------+ +----------+ 207 |Forwarding| |Forwarding| |Forwarding| |Forwarding| 208 +--------.-+ +-.------.-+ +-.---.----+ +-------.--+ 209 : Link : \ ,-----. / \ ,-----. / 210 +......+ +----[ Sub ]----+ +-[ Sub ]-+ 211 [Network] [Network] 212 `-----' `-----' 214 |<--------------------- DetNet IP --------------------->| 216 Figure 1: A Simple DetNet (DN) Enabled IP Network 218 Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled 219 end systems originate IP encapsulated traffic that is identified as 220 DetNet flows, relay nodes understand the forwarding requirements of 221 the DetNet flow and ensure that node, interface and sub-network 222 resources are allocated to ensure DetNet service requirements. The 223 dotted line around the Service component of the Relay Nodes indicates 224 that the transit routers are DetNet service aware but do not perform 225 any DetNet service sub-layer function, e.g., PREOF. IEEE 802.1 TSN 226 is an example sub-network type which can provide support for DetNet 227 flows and service. 229 Note: The sub-network can represent a TSN, MPLS or IP network 230 segment. 232 IP Edge Edge IP 233 End System Node Node End System 235 +----------+ +.........+ +.........+ +----------+ 236 | Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. | 237 +----------+ +.........+ +.........+ +----------+ 238 | IP |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->| IP | 239 +----------+ +---+ +---+ +---+ +---+ +----------+ 240 |Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding| 241 +--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ 242 : Link : \ ,-----. / / ,-----. \ 243 +.......+ +----[ Sub ]----+ +--[ Sub ]--+ 244 [Network] [Network] 245 `-----' `-----' 247 |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->| 249 Figure 2: Non-DetNet aware IP end systems with DetNet IP Domain 251 Figure 2 illustrates a variant of Figure 1 where the end systems are 252 not DetNet aware. In this case, edge nodes sit at the boundary of 253 the DetNet domain and provide DetNet service proxies for the end 254 applications by initiating and terminating DetNet service for the 255 application's IP flows. The existing header information or an 256 approach such as described in Section 4.4 can be used to support 257 DetNet flow identification. 259 Note, that Figure 1 and Figure 2 can be combined, so IP DetNet End 260 Systems can communicate over DetNet IP network with IP End System. 262 Non-DetNet and DetNet IP packets are identical on the wire. From 263 data plane perspective, the only difference is that there is flow- 264 associated DetNet information on each DetNet node that defines the 265 flow related characteristics and required forwarding behavior. As 266 shown above, edge nodes provide a Service Proxy function that 267 "associates" one or more IP flows with the appropriate DetNet flow- 268 specific information and ensures that the receives the proper traffic 269 treatment within the domain. 271 Note: The operation of IEEE802.1 TSN end systems over DetNet enabled 272 IP networks is not described in this document. TSN over MPLS is 273 discribed in [I-D.ietf-detnet-tsn-vpn-over-mpls]. 275 4. DetNet IP Data Plane Considerations 277 This section provides informative considerations related to providing 278 DetNet service to flows which are identified based on their header 279 information. 281 4.1. End-System Specific Considerations 283 Data-flows requiring DetNet service are generated and terminated on 284 end systems. This document deals only with IP end systems. The 285 protocols used by an IP end system are specific to an application and 286 end systems peer with end systems using the same application 287 encapsulation format. This said, DetNet's use of 6-tuple IP flow 288 identification means that DetNet must be aware of not only the format 289 of the IP header, but also of the next protocol carried within an IP 290 packet. 292 When IP end systems are DetNet aware, no application-level or 293 service-level proxy functions are needed inside the DetNet domain. 294 For DetNet unaware IP end systems service-level proxy functions are 295 needed inside the DetNet domain. 297 End systems need to ensure that DetNet service requirements are met 298 when processing packets associated with a DetNet flow. When 299 forwarding packets, this means that packets are appropriately shaped 300 on transmission and received appropriate traffic treatment on the 301 connected sub-network, see Section 4.3.2 and Section 4.2 for more 302 details. When receiving packets, this means that there are 303 appropriate local node resources, e.g., buffers, to receive and 304 process a DetNet flow packets. 306 4.2. DetNet Domain-Specific Considerations 308 As a general rule, DetNet IP domains need to be able to forward any 309 DetNet flow identified by the IP 6-tuple. Doing otherwise would 310 limit end system encapsulation format. From a practical standpoint 311 this means that all nodes along the end-to-end path of DetNet flows 312 need to agree on what fields are used for flow identification, and 313 the transport protocols (e.g., TCP/UDP/IPsec) which can be used to 314 identify 6-tuple protocol ports. 316 From a connection type perspective two scenarios are identified: 318 1. DN attached: end system is directly connected to an edge node or 319 end system is behind a sub-network. (See ES1 and ES2 in figure 320 below) 322 2. DN integrated: end system is part of the DetNet domain. (See ES3 323 in figure below) 325 L3 (IP) end systems may use any of these connection types. A DetNet 326 domain allows communication between any end-systems using the same 327 encapsulation format, independent of their connection type and DetNet 328 capability. DN attached end systems have no knowledge about the 329 DetNet domain and its encapsulation format. See Figure 3 for L3 end 330 system connection examples. 332 ____+----+ 333 +----+ _____ / | ES3| 334 | ES1|____ / \__/ +----+___ 335 +----+ \ / \ 336 + | 337 ____ \ _/ 338 +----+ __/ \ +__ DetNet IP domain / 339 | ES2|____/ L2/L3 |___/ \ __ __/ 340 +----+ \_______/ \_______/ \___/ 342 Figure 3: Connection types of L3 end systems 344 Within a DetNet domain, the DetNet enabled IP Routers are 345 interconnected by links and sub-networks to support end-to-end 346 delivery of DetNet flows. From a DetNet architecture perspective, 347 these routers are DetNet relays, as they must be DetNet service 348 aware. Such routers identify DetNet flows based on the IP 6-tuple, 349 and ensure that the DetNet service required traffic treatment is 350 provided both on the node and on any attached sub-network. 352 This solution provides DetNet functions end to end, but does so on a 353 per link and sub-network basis. Congestion protection and latency 354 control and the resource allocation (queuing, policing, shaping) are 355 supported using the underlying link / sub net specific mechanisms. 356 However, service protections (packet replication and packet 357 elimination functions) are not provided at the DetNet layer end to 358 end. Instead service protection can be provided on a per underlying 359 L2 link and sub-network basis. 361 The DetNet Service Flow is mapped to the link / sub-network specific 362 resources using an underlying system specific means. This implies 363 each DetNet aware node on path looks into the forwarded DetNet 364 Service Flow packet and utilize e.g., a 6-tuple to find out the 365 required mapping within a node. 367 As noted earlier, the Service Protection is done within each link / 368 sub-network independently using the domain specific mechanisms (due 369 the lack of a unified end to end sequencing information that would be 370 available for intermediate nodes). Therefore, service protection (if 371 enabled) cannot be provided end-to-end, only within sub-networks. 372 This is shown for a three sub-network scenario in Figure 4, where 373 each sub-network can provide service protection between its borders. 375 "R" and "E" denotes replication and elimination points within the 376 sub-network. 378 <-------------------- DenNet IP ------------------------> 379 ______ 380 ____ / \__ 381 ____ / \__/ \___ ______ 382 +----+ __/ +====+ +==+ \ +----+ 383 |src |__/ SubN1 ) | | \ SubN3 \____| dst| 384 +----+ \_______/ \ Sub-Network2 | \______/ +----+ 385 \_ _/ 386 \ __ __/ 387 \_______/ \___/ 389 +---+ +---------E--------+ +-----+ 390 +----+ | | | | | | | +----+ 391 |src |----R E--------R +---+ E------R E------+ dst| 392 +----+ | | | | | | | +----+ 393 +---+ +-----R------------+ +-----+ 395 Figure 4: Replication and elimination in sub-networks for DetNet IP 396 networks 398 If end to end service protection is desired, it can be implemented, 399 for example, by the DetNet end systems using Layer-4 (L4) transport 400 protocols or application protocols. However, these protocols are out 401 of scope of this document. 403 4.3. Forwarding Sub-Layer Considerations 405 4.3.1. Class of Service 407 Class of Service (CoS) for DetNet flows carried in IPv6 is provided 408 using the standard differentiated services code point (DSCP) field 409 [RFC2474] and related mechanisms. The 2-bit explicit congestion 410 notification (ECN) [RFC3168] field MAY also be used. 412 One additional consideration for DetNet nodes which support CoS 413 services is that they MUST ensure that the CoS service classes do not 414 impact the congestion protection and latency control mechanisms used 415 to provide DetNet QoS. This requirement is similar to requirement 416 for MPLS LSRs to that CoS LSPs do not impact the resources allocated 417 to TE LSPs via [RFC3473]. 419 4.3.2. Quality of Service 421 Quality of Service (QoS) for DetNet service flows carried in IP MUST 422 be provided locally by the DetNet-aware hosts and routers supporting 423 DetNet flows. Such support leverages the underlying network layer 424 such as 802.1 TSN. The traffic control mechanisms used to deliver 425 QoS for IP encapsulated DetNet flows are expected to be defined in a 426 future document. From an encapsulation perspective, the combination 427 of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP code, 428 uniquely identifies a DetNet service flow. 430 Packets that are marked with a DetNet Class of Service value, but 431 that have not been the subject of a completed reservation, can 432 disrupt the QoS offered to properly reserved DetNet flows by using 433 resources allocated to the reserved flows. Therefore, the network 434 nodes of a DetNet network must: 436 o Defend the DetNet QoS by discarding or remarking (to a non-DetNet 437 CoS) packets received that are not the subject of a completed 438 reservation. 440 o Not use a DetNet reserved resource, e.g. a queue or shaper 441 reserved for DetNet flows, for any packet that does not carry a 442 DetNet Class of Service marker. 444 4.4. DetNet Flow Aggregation 446 As described in [I-D.ietf-detnet-data-plane-framework], the ability 447 to aggregate individual flows, and their associated resource control, 448 into a larger aggregate is an important technique for improving 449 scaling by reducing the state per hop. DetNet IP data plane 450 aggregation can take place within a single node, when that node 451 maintains state about both the aggregated and individual flows. It 452 can also take place between nodes, where one node maintains state 453 about only flow aggregates while the other node maintains state on 454 all or a portion of the component flows. In either case, the 455 management or control function that provisions the aggregate flows 456 must ensure that adequate resources are allocated and configured to 457 provide combined service requirements of the individual flows. As 458 DetNet is concerned about latency and jitter, more than just 459 bandwidth needs to be considered. 461 From a single node perspective, the aggregation of IP flows impacts 462 DetNet IP data plane flow identification and resource allocation. As 463 discussed above, IP flow identification uses the IP "6-tuple" for 464 flow identification. DetNet IP flows can be aggregated using any of 465 the 6-tuple fields defined in Section 5.1. The use of prefixes, 466 wildcards, bitmasks, and value ranges allows a DetNet node to 467 identify aggregate DetNet flows. From a resource allocation 468 perspective, DetNet nodes must provide service to a aggregate and not 469 on a component flow basis. 471 It is the responsibility of the DetNet controller plane to properly 472 provision the use of these aggregation mechanisms. This includes 473 ensuring that aggregated flows have compatible e.g., the same or very 474 similar QoS and/or CoS characteristics, see Section 4.3.2. It also 475 includes ensuring that per component-flow service requirements are 476 satisfied by the aggregate, see Section 5.3. 478 4.5. Bidirectional Traffic 480 While the DetNet IP data plane must support bidirectional DetNet 481 flows, there are no special bidirectional features with respect to 482 the data plane other than the need for the two directions of a co- 483 routed bidirectional flow to take the same path. That is to say that 484 bidirectional DetNet flows are solely represented at the management 485 and control plane levels, without specific support or knowledge 486 within the DetNet data plane. Fate sharing and associated or co- 487 routed bidirectional flows can be managed at the control level. 489 Control and management mechanisms need to support bidirectional 490 flows, but the specification of such mechanisms are out of scope of 491 this document. An example control plane solution for MPLS can be 492 found in [RFC7551]. 494 5. DetNet IP Data Plane Procedures 496 This section provides DetNet IP data plane procedures. These 497 procedures have been divided into the following areas: flow 498 identification, forwarding and traffic treatment. Flow 499 identification includes those procedures related to matching IP and 500 higher layer protocol header information to DetNet flow (state) 501 information and service requirements. Flow identification is also 502 sometimes called Traffic classification, for example see [RFC5777]. 503 Forwarding includes those procedures related to next hop selection 504 and delivery. Traffic treatment includes those procedures related to 505 providing an identified flow with the required DetNet service. 507 DetNet IP data plane establishment and operational procedures also 508 have requirements on the control and management systems for DetNet 509 flows and these are referred in this section. Specifically this 510 section identifies a number of information elements that require 511 support via the management and control interfaces supported by a 512 DetNet node. The specific mechanism used for such support is out of 513 the scope of this document. A summary of the requirements for 514 management and control related information is included. Conformance 515 language is not used in the summary since applies to future 516 mechanisms such as those that may be provided in YANG models 517 [I-D.ietf-detnet-yang]. 519 5.1. DetNet IP Flow Identification Procedures 521 IP and higher layer protocol header information is used to identify 522 DetNet flows. All DetNet implementations that support this document 523 MUST identify individual DetNet flows based on the set of information 524 identified in this section. Note, that additional flow 525 identification requirements, e.g., to support other higher layer 526 protocols, may be defined in future. 528 The configuration and control information used to identify an 529 individual DetNet flow MUST be ordered by an implementation. 530 Implementations MUST support a fixed order when identifying flows, 531 and MUST identify a DetNet flow by the first set of matching flow 532 information. 534 Implementations of this document MUST support DetNet flow 535 identification when the implementation is acting as a DetNet end 536 systems, a relay node or as an edge node. 538 5.1.1. IP Header Information 540 Implementations of this document MUST support DetNet flow 541 identification based on IP header information. The IPv4 header is 542 defined in [RFC0791] and the IPv6 is defined in [RFC8200]. 544 5.1.1.1. Source Address Field 546 Implementations of this document MUST support DetNet flow 547 identification based on the Source Address field of an IP packet. 548 Implementations SHOULD support longest prefix matching for this 549 field, see [RFC1812] and [RFC7608]. Note that a prefix length of 550 zero (0) effectively means that the field is ignored. 552 5.1.1.2. Destination Address Field 554 Implementations of this document MUST support DetNet flow 555 identification based on the Destination Address field of an IP 556 packet. Implementations SHOULD support longest prefix matching for 557 this field, see [RFC1812] and [RFC7608]. Note that a prefix length 558 of zero (0) effectively means that the field is ignored. 560 Note: any IP address value is allowed, including an IP multicast 561 destination address. 563 5.1.1.3. IPv4 Protocol and IPv6 Next Header Fields 565 Implementations of this document MUST support DetNet flow 566 identification based on the IPv4 Protocol field when processing IPv4 567 packets, and the IPv6 Next Header Field when processing IPv6 packets. 568 An implementation MUST support flow identification based based the 569 next protocol values defined in Section 5.1.2. Other, non-zero 570 values, MUST be used for flow identification. Implementations SHOULD 571 allow for these fields to be ignored for a specific DetNet flow. 573 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields 575 These fields are used to support Differentiated Services [RFC2474] 576 and Explicit Congestion Notification [RFC3168]. Implementations of 577 this document MUST support DetNet flow identification based on the 578 IPv4 Type of Service field when processing IPv4 packets, and the IPv6 579 Traffic Class Field when processing IPv6 packets. Implementations 580 MUST support bitmask based matching, where bits set to one (1) in the 581 bitmask indicate which subset of the bits in the field are to be used 582 in determining a match. Note that all bits set to zero (0) value as 583 a bitmask effectively means that these fields are ignored. 585 5.1.1.5. IPv6 Flow Label Field 587 Implementations of this document SHOULD support identification of 588 DetNet flows based on the IPv6 Flow Label field. Implementations 589 that support matching based on this field MUST allow for this field 590 to be ignored for a specific DetNet flow. When this field is used to 591 identify a specific DetNet flow, implementations MAY exclude the IPv6 592 Next Header field and next header information as part of DetNet flow 593 identification. 595 5.1.2. Other Protocol Header Information 597 Implementations of this document MUST support DetNet flow 598 identification based on header information identified in this 599 section. Support for TCP, UDP and IPsec flows is defined. Future 600 documents are expected to define support for other protocols. 602 5.1.2.1. TCP and UDP 604 DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is 605 achieved based on the Source and Destination Port fields carried in 606 each protocol's header. These fields share a common format and 607 common DetNet flow identification procedures. 609 5.1.2.1.1. Source Port Field 611 Implementations of this document MUST support DetNet flow 612 identification based on the Source Port field of a TCP or UDP packet. 613 Implementations MUST support flow identification based on a 614 particular value carried in the field, i.e., an exact value. 615 Implementations SHOULD support range-based port matching. 616 Implementation MUST also allow for the field to be ignored for a 617 specific DetNet flow. 619 5.1.2.1.2. Destination Port Field 621 Implementations of this document MUST support DetNet flow 622 identification based on the Destination Port field of a TCP or UDP 623 packet. Implementations MUST support flow identification based on a 624 particular value carried in the field, i.e., an exact value. 625 Implementations SHOULD support range-based port matching. 626 Implementation MUST also allow for the field to be ignored for a 627 specific DetNet flow. 629 5.1.2.2. IPsec AH and ESP 631 IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security 632 Payload (ESP) [RFC4303] share a common format for the Security 633 Parameters Index (SPI) field. Implementations MUST support flow 634 identification based on a particular value carried in the field, 635 i.e., an exact value. Implementation SHOULD also allow for the field 636 to be ignored for a specific DetNet flow. 638 5.2. Forwarding Procedures 640 General requirements for IP nodes are defined in [RFC1122], [RFC1812] 641 and [RFC6434], and are not modified by this document. The typical 642 next-hop selection process is impacted by DetNet. Specifically, 643 implementations of this document SHALL use management and control 644 information to select the one or more outgoing interfaces and next 645 hops to be used for a packet belonging to a DetNet flow. 647 The use of multiple paths or links, e.g., ECMP, to support a single 648 DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet 649 flows within a DetNet domain. 651 The above implies that management and control functions will be 652 defined to support this requirement, e.g., see 653 [I-D.ietf-detnet-yang]. 655 5.3. DetNet IP Traffic Treatment Procedures 657 Implementations if this document MUST ensure that a DetNet flow 658 receives the traffic treatment that is provisioned for it via 659 configuration or the controller plane, e.g., via 660 [I-D.ietf-detnet-yang]. General information on DetNet service can be 661 found in [I-D.ietf-detnet-flow-information-model]. Typical 662 mechanisms used to provide different treatment to different flows 663 includes the allocation of system resources (such as queues and 664 buffers) and provisioning or related parameters (such as shaping, and 665 policing). Support can also be provided via an underlying network 666 technology such as MPLS [I-D.ietf-detnet-ip-over-mpls]. and 667 IEEE802.1 TSN [I-D.ietf-detnet-ip-over-tsn]. Other than in the TSN 668 case, the specific mechanisms used by a DetNet node to ensure DetNet 669 service delivery requirements are met for supported DetNet flows is 670 outside the scope of this document. 672 6. Management and Control Information Summary 674 The following summarizes the set of information that is needed to 675 identify individual and aggregated DetNet flows: 677 o IPv4 and IPv6 source address field. 679 o IPv4 and IPv6 source address prefix length, where a zero (0) value 680 effectively means that the address field is ignored. 682 o IPv4 and IPv6 destination address field. 684 o IPv4 and IPv6 destination address prefix length, where a zero (0) 685 effectively means that the address field is ignored. 687 o IPv4 protocol field. A limited set of values is allowed, and the 688 ability to ignore this field, e.g., via configuration of the value 689 zero (0), is desirable. 691 o IPv6 next header field. A limited set of values is allowed, and 692 the ability to ignore this field, e.g., via configuration of the 693 value zero (0), is desirable. 695 o IPv4 Type of Service and IPv6 Traffic Class Fields. 697 o IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a 698 zero (0) effectively means that theses fields are ignored. 700 o IPv6 flow label field. This field can be optionally used for 701 matching. When used, can be exclusive of matching against the 702 next header field. 704 o TCP and UDP Source Port. Exact and wildcard matching is required. 705 Port ranges can optionally be used. 707 o TCP and UDP Destination Port. Exact and wildcard matching is 708 required. Port ranges can optionally be used. 710 o IPsec Header SPI field. Exact matching is required. 712 This information MUST be provisioned per DetNet flow via 713 configuration, e.g., via the controller or management plane. 715 Information identifying a DetNet flow is ordered and implementations 716 use the first match. This can, for example, be used to provide a 717 DetNet service for a specific UDP flow, with unique Source and 718 Destination Port field values, while providing a different service 719 for the aggregate of all other flows with that same UDP Destination 720 Port value. 722 It is the responsibility of the DetNet controller plane to properly 723 provision both flow identification information and the flow specific 724 resources needed to provided the traffic treatment needed to meet 725 each flow's service requirements. This applies for aggregated and 726 individual flows. 728 7. Security Considerations 730 Security considerations for DetNet are described in detail in 731 [I-D.ietf-detnet-security]. General security considerations are 732 described in [I-D.ietf-detnet-architecture]. This section considers 733 exclusively security considerations which are specific to the DetNet 734 IP data plane. 736 Security aspects which are unique to DetNet are those whose aim is to 737 provide the specific quality of service aspects of DetNet, which are 738 primarily to deliver data flows with extremely low packet loss rates 739 and bounded end-to-end delivery latency. 741 The primary considerations for the data plane is to maintain 742 integrity of data and delivery of the associated DetNet service 743 traversing the DetNet network. Application flows can be protected 744 through whatever means is provided by the underlying technology. For 745 example, encryption may be used, such as that provided by IPSec 746 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 747 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 749 From a data plane perspective this document does not add or modify 750 any header information. 752 At the management and control level DetNet flows are identified on a 753 per-flow basis, which may provide controller plane attackers with 754 additional information about the data flows (when compared to 755 controller planes that do not include per-flow identification). This 756 is an inherent property of DetNet which has security implications 757 that should be considered when determining if DetNet is a suitable 758 technology for any given use case. 760 To provide uninterrupted availability of the DetNet service, 761 provisions can be made against DOS attacks and delay attacks. To 762 protect against DOS attacks, excess traffic due to malicious or 763 malfunctioning devices can be prevented or mitigated, for example 764 through the use of existing mechanism such as policing and shaping 765 applied at the input of a DetNet domain. To prevent DetNet packets 766 from being delayed by an entity external to a DetNet domain, DetNet 767 technology definition can allow for the mitigation of Man-In-The- 768 Middle attacks, for example through use of authentication and 769 authorization of devices within the DetNet domain. 771 8. IANA Considerations 773 This document does not require an action from IANA. 775 9. Acknowledgements 777 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 778 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 779 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 780 Bernardos for their various contributions to this work. 782 10. References 784 10.1. Normative references 786 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 787 DOI 10.17487/RFC0768, August 1980, 788 . 790 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 791 DOI 10.17487/RFC0791, September 1981, 792 . 794 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 795 RFC 793, DOI 10.17487/RFC0793, September 1981, 796 . 798 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 799 RFC 1812, DOI 10.17487/RFC1812, June 1995, 800 . 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, 804 DOI 10.17487/RFC2119, March 1997, 805 . 807 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 808 "Definition of the Differentiated Services Field (DS 809 Field) in the IPv4 and IPv6 Headers", RFC 2474, 810 DOI 10.17487/RFC2474, December 1998, 811 . 813 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 814 of Explicit Congestion Notification (ECN) to IP", 815 RFC 3168, DOI 10.17487/RFC3168, September 2001, 816 . 818 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 819 Switching (GMPLS) Signaling Resource ReserVation Protocol- 820 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 821 DOI 10.17487/RFC3473, January 2003, 822 . 824 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 825 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 826 December 2005, . 828 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 829 DOI 10.17487/RFC4302, December 2005, 830 . 832 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 833 RFC 4303, DOI 10.17487/RFC4303, December 2005, 834 . 836 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 837 Length Recommendation for Forwarding", BCP 198, RFC 7608, 838 DOI 10.17487/RFC7608, July 2015, 839 . 841 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 842 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 843 May 2017, . 845 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 846 (IPv6) Specification", STD 86, RFC 8200, 847 DOI 10.17487/RFC8200, July 2017, 848 . 850 10.2. Informative references 852 [I-D.ietf-detnet-architecture] 853 Finn, N., Thubert, P., Varga, B., and J. Farkas, 854 "Deterministic Networking Architecture", draft-ietf- 855 detnet-architecture-13 (work in progress), May 2019. 857 [I-D.ietf-detnet-data-plane-framework] 858 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 859 Bryant, S., and J. Korhonen, "DetNet Data Plane 860 Framework", draft-ietf-detnet-data-plane-framework-00 861 (work in progress), May 2019. 863 [I-D.ietf-detnet-dp-sol-mpls] 864 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 865 Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in 866 progress), March 2019. 868 [I-D.ietf-detnet-flow-information-model] 869 Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet 870 Flow Information Model", draft-ietf-detnet-flow- 871 information-model-03 (work in progress), March 2019. 873 [I-D.ietf-detnet-ip-over-mpls] 874 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 875 and J. Korhonen, "DetNet Data Plane: IP over MPLS", draft- 876 ietf-detnet-ip-over-mpls-00 (work in progress), May 2019. 878 [I-D.ietf-detnet-ip-over-tsn] 879 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 880 Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time 881 Sensitive Networking (TSN)", draft-ietf-detnet-ip-over- 882 tsn-00 (work in progress), May 2019. 884 [I-D.ietf-detnet-security] 885 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 886 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 887 Networking (DetNet) Security Considerations", draft-ietf- 888 detnet-security-04 (work in progress), March 2019. 890 [I-D.ietf-detnet-tsn-vpn-over-mpls] 891 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 892 Korhonen, "DetNet Data Plane: IEEE 802.1 Time Sensitive 893 Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- 894 mpls-00 (work in progress), May 2019. 896 [I-D.ietf-detnet-yang] 897 Geng, X., Chen, M., Li, Z., and R. Rahman, "Deterministic 898 Networking (DetNet) Configuration YANG Model", draft-ietf- 899 detnet-yang-02 (work in progress), March 2019. 901 [IEEE802.1AE-2018] 902 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 903 Security (MACsec)", 2018, 904 . 906 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 907 Communication Layers", STD 3, RFC 1122, 908 DOI 10.17487/RFC1122, October 1989, 909 . 911 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 912 Informal Management Model for Diffserv Routers", RFC 3290, 913 DOI 10.17487/RFC3290, May 2002, 914 . 916 [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and 917 W. Weiss, "Information Model for Describing Network Device 918 QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, 919 January 2004, . 921 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 922 Ed., and A. Lior, "Traffic Classification and Quality of 923 Service (QoS) Attributes for Diameter", RFC 5777, 924 DOI 10.17487/RFC5777, February 2010, 925 . 927 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 928 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 929 2011, . 931 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 932 Extensions for Associated Bidirectional Label Switched 933 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 934 . 936 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 937 (Diffserv) and Real-Time Communication", RFC 7657, 938 DOI 10.17487/RFC7657, November 2015, 939 . 941 Authors' Addresses 943 Balazs Varga (editor) 944 Ericsson 945 Magyar Tudosok krt. 11. 946 Budapest 1117 947 Hungary 949 Email: balazs.a.varga@ericsson.com 951 Janos Farkas 952 Ericsson 953 Magyar Tudosok krt. 11. 954 Budapest 1117 955 Hungary 957 Email: janos.farkas@ericsson.com 959 Lou Berger 960 LabN Consulting, L.L.C. 962 Email: lberger@labn.net 964 Don Fedyk 965 LabN Consulting, L.L.C. 967 Email: dfedyk@labn.net 969 Andrew G. Malis 970 Futurewei Technologies 972 Email: agmalis@gmail.com 974 Stewart Bryant 975 Futurewei Technologies 977 Email: stewart.bryant@gmail.com 978 Jouni Korhonen 980 Email: jouni.nospam@gmail.com