idnits 2.17.1 draft-varga-detnet-ip-preof-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC9025]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2021) is 1046 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-varga-detnet-pof-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga 3 Internet-Draft J. Farkas 4 Intended status: Informational Ericsson 5 Expires: December 11, 2021 A. Malis 6 Malis Consulting 7 June 9, 2021 9 Deterministic Networking (DetNet): PREOF for DetNet IP 10 draft-varga-detnet-ip-preof-00 12 Abstract 14 This document describes how DetNet IP data plane can support the 15 Packet Replication, Elimination, and Ordering Functions (PREOF) based 16 on [RFC9025]. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 11, 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 55 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 56 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 57 3. Requirements for adding PREOF to DetNet IP . . . . . . . . . 4 58 4. Adding PREOF to DetNet IP . . . . . . . . . . . . . . . . . . 4 59 4.1. Solution Basics . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5 61 4.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 6 62 4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 6 63 4.5. PREOF Procedures . . . . . . . . . . . . . . . . . . . . 7 64 4.6. PREOF capable DetNet IP domain . . . . . . . . . . . . . 8 65 5. Control and Management Plane Parameters . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 8.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 The DetNet Working Group has defined packet replication (PRF), packet 76 elimination (PEF) and packet ordering (POF) functions to provide 77 service protection by the DetNet service sub-layer [RFC8655]. The 78 PREOF service protection method relies on copies of the same packet 79 sent over multiple maximally disjoint paths and uses sequencing 80 information to eliminate duplicates. A possible implementation of 81 the PRF and PEF functions is described in [IEEE8021CB] and the 82 related YANG data model is defined in [IEEEP8021CBcv]. A possible 83 implementation of POF function is described in 84 [I-D.varga-detnet-pof]. Figure 1 shows a DetNet flow on which PREOF 85 functions are applied during forwarding from the source to the 86 destination. 88 +------------+ 89 +---------------E1---+ | | 90 +---+ | | +---R3---+ | +---+ 91 |src|------R1 +---+ | E3----O----+dst| 92 +---+ | | E2-------+ +---+ 93 +----------R2 | 94 +-----------------+ 96 R: replication function (PRF) 97 E: elimination function (PEF) 98 O: ordering function (POF) 100 Figure 1: PREOF scenario in a DetNet network 102 In general, the use of PREOF functions require sequencing information 103 to be included in the packets of a DetNet compound flow. This may be 104 done by adding a sequence number or time stamp as part of DetNet 105 encapsulation. Sequencing information is typically added once, at or 106 close to the source. 108 The DetNet MPLS data plane [RFC8939] specifies how sequencing 109 information is encoded in the MPLS header. However, the DetNet IP 110 data plane described in [RFC8939] does not specify how sequencing 111 information can be encoded in the IP header. This document describes 112 a DetNet IP encapsulation that includes sequencing information based 113 on the DetNet MPLS over UDP/IP data plane [RFC9025], i.e., leveraging 114 the MPLS-over-UDP technology. 116 2. Terminology 118 2.1. Terms Used in This Document 120 This document uses the terminology established in the DetNet 121 architecture [RFC8655], and the reader is assumed to be familiar with 122 that document and its terminology. 124 2.2. Abbreviations 126 The following abbreviations are used in this document: 128 DetNet Deterministic Networking. 130 PEF Packet Elimination Function. 132 POF Packet Ordering Function. 134 PREOF Packet Replication, Elimination and Ordering Functions. 136 PRF Packet Replication Function. 138 2.3. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 3. Requirements for adding PREOF to DetNet IP 148 The requirements for adding PREOF to DetNet IP are: 150 o to reuse existing DetNet data plane solutions (e.g., [RFC8964], 151 [RFC9025]). 153 o to allow with minimal implementation effort the DetNet service 154 sub-layer for IP packet switched networks. 156 The described solution practically gains from MPLS header fields 157 without adding MPLS protocol stack complexity to the nodal 158 requirements. 160 4. Adding PREOF to DetNet IP 162 4.1. Solution Basics 164 The DetNet IP encapsulation supporting DetNet Service sub-layer is 165 based on the "UDP tunneling" concept. At the edge of a PREOF capable 166 DetNet IP domain the DetNet flow is encapsulated in an UDP packet 167 containing the sequence number used by PREOF functions within the 168 domain. This solution maintains the 6-tuple-based DetNet flow 169 identification in DetNet transit nodes, which operate at the DetNet 170 forwarding sub-layer between the DetNet service sub-layer nodes; 171 therefore, it is compatible with [RFC8939]. Figure 2 shows how the 172 PREOF capable DetNet IP data plane fits into the DetNet sub-layers. 174 DetNet IP 175 . 176 . 177 +------------+ 178 | Service | d-CW, Service-ID (S-label) 179 +------------+ 180 | Forwarding | UDP/IP Header 181 +------------+ 183 Figure 2: PREOF capable DetNet IP data plane 185 4.2. Encapsulation 187 The PREOF capable DetNet IP encapsulation builds on encapsulating 188 DetNet PW directly over UDP. That is, it combines DetNet MPLS 189 [RFC8964] with DetNet MPLS-in-UDP [RFC9025], without using any 190 F-Labels as shown in Figure 3. DetNet flows are identified at the 191 receiving DetNet service sub-layer processing node via the S-Label 192 and/or the UDP/IP header information. Sequencing information for 193 PREOF is provided by the DetNet Control Word (d-CW) as per [RFC8964]. 194 The S-label is used to identify both the DetNet flow and the DetNet 195 App-flow type. The UDP tunnel is used to direct the packet across 196 the DetNet domain to the next DetNet service sub-layer processing 197 node. 199 +---------------------------------+ 200 | | 201 | DetNet App-Flow | 202 | (original IP) Packet | 203 | | 204 +---------------------------------+ <--\ 205 | DetNet Control Word | | 206 +---------------------------------+ +--> PREOF capable 207 | Service-ID (S-Label) | | DetNet IP data 208 +---------------------------------+ | plane encapsulation 209 | UDP Header | | 210 +---------------------------------+ | 211 | IP Header | | 212 +---------------------------------+ <--/ 213 | Data-Link | 214 +---------------------------------+ 215 | Physical | 216 +---------------------------------+ 218 Figure 3: PREOF capable DetNet IP encapsulation 220 4.3. Packet Processing 222 IP ingress and egress nodes of the PREOF capable DetNet IP domain 223 MUST add and remove a DetNet service-specific d-CW and Service-ID 224 (i.e., S-Label). Relay nodes MAY change Service-ID values when 225 processing a DetNet flow, i.e., incoming and outgoing Service-IDs of 226 a DetNet flow can be different. Service-ID values MUST be 227 provisioned per DetNet service via configuration, i.e., via the 228 Controller Plane described in [RFC8938]. In some PREOF topologies, 229 the node performing replication sends the packets to multiple nodes 230 performing PEF or POF and the replication node may need to use 231 different Service-ID values for the different member flows for the 232 same DetNet service. 234 Note, that Service-IDs provide identification at the downstream 235 DetNet service sub-layer receiver, not the sender. 237 4.4. Flow Aggregation 239 Two methods can be used for flow aggregation: 241 o aggregation using same UDP tunnel, 243 o aggregating DetNet flows as a new DetNet flow. 245 In the first case, the different DetNet PWs use the same UDP tunnel, 246 so they are treated as a single (aggregated) flow on all transit 247 nodes. 249 For the second option, an additional Service-ID and d-CW tuple is 250 added to the encapsulation. The Aggregate-ID is a special case of a 251 Service-ID, whose properties are known only at the aggregation and 252 de-aggregation end points. It is a property of the Aggregate-ID that 253 it is followed by a d-CW followed by an Service-ID/d-CW tuple. 254 Figure 4 shows the encapsulation in case of aggregation. 256 +---------------------------------+ 257 | | 258 | DetNet App-Flow | 259 | Payload Packet | 260 | | 261 +---------------------------------+ <--\ 262 | DetNet Control Word | | 263 +---------------------------------+ +--> PREOF capable 264 | Service-ID (S-Label) | | DetNet IP data 265 +---------------------------------+ | plane encapsulation 266 | DetNet Control Word | | 267 +---------------------------------+ | 268 | Aggregate-ID (A-Label) | | 269 +---------------------------------+ | 270 | UDP Header | | 271 +---------------------------------+ | 272 | IP Header | | 273 +---------------------------------+ <--/ 274 | Data-Link | 275 +---------------------------------+ 276 | Physical | 277 +---------------------------------+ 279 Figure 4: Aggregating DetNet flows as a new DetNet flow 281 4.5. PREOF Procedures 283 A node operating on a received DetNet flow at the DetNet service sub- 284 layer uses the local context associated with a received Service-ID to 285 determine which local DetNet operation(s) are applied to received 286 packet. A Service-ID may be allocated to be unique and enabling 287 DetNet flow identification regardless of which input interface or UDP 288 tunnel the packet is received. It is important to note that Service- 289 ID values are driven by the receiver, not the sender. 291 The DetNet forwarding sub-layer is supported by the UDP tunnel and is 292 responsible for providing resource allocation and explicit routes. 294 To support outgoing PREOF capable DetNet IP encapsulation, an 295 implementation MUST support the provisioning of UDP and IP header 296 information. Note, when PRF is performed at the DetNet service sub- 297 layer, there are multiple member flows, and each member flow requires 298 the of their own Service-ID, UDP and IP header information. The 299 headers for each outgoing packet MUST be formatted according to the 300 configuration information, and the UDP Source Port value MUST be set 301 to uniquely identify the DetNet flow. The packet MUST then be 302 handled as a PREOF capable DetNet IP packet. 304 To support the receive processing, an implementation MUST also 305 support the provisioning of received Service-ID, UDP and IP header 306 information. The provisioned information MUST be used to identify 307 incoming app-flows based on the combination of Service-ID and/or 308 incoming encapsulation header information. 310 The challenge for POF initialization is that, for example, after a 311 reset, it is not known whether the first received packet is in-order 312 or out-of-order. The original initialization (see 313 [I-D.varga-detnet-pof]) considers the first packet as in-order, so 314 out-of-order packet(s) during "POFMaxTime"/"POFMaxTime_path_i" time - 315 after the first packet was received - may not be corrected. The 316 motivation behind such an initialization is POF implementation 317 simplicity. 319 4.6. PREOF capable DetNet IP domain 321 Figure 5 shows using PREOF in a PREOF capable DetNet IP network. 323 <---------- PREOF capable DetNet IP ---------------> 324 ______ 325 ____ / \__ 326 ____ / \__/ \____________ 327 +----+ __/ \____/ \ +----+ 328 |src |_____/ \___| dst| 329 +----+ \_______ DetNet network __________/ +----+ 330 \_______ _/ 331 \ __ __/ 332 \_______/ \___/ 334 +------------+ 335 +---------------E1---+ | | 336 +----+ | | +---R3---+ | +----+ 337 |src |------R1 +---+ | E3----O----+ dst| 338 +----+ | | E2-------+ +----+ 339 +----------R2 | 340 +-----------------+ 342 Figure 5: PREOF capable DetNet IP domain 344 5. Control and Management Plane Parameters 346 The information needed to identify individual and aggregated DetNet 347 flows is summarized as follows: 349 o Service-ID information to be mapped to UDP/IP flows. Note that, 350 for example, a single Service-ID can map to multiple sets of UDP/ 351 IP information when PREOF is used. 353 o IPv4 or IPv6 source address field. 355 o IPv4 or IPv6 source address prefix length, where a zero (0) value 356 effectively means that the address field is ignored. 358 o IPv4 or IPv6 destination address field. 360 o IPv4 or IPv6 destination address prefix length, where a zero (0) 361 effectively means that the address field is ignored. 363 o IPv4 protocol field set to "UDP". 365 o IPv6 next header field set to "UDP". 367 o For the IPv4 Type of Service and IPv6 Traffic Class Fields: 369 * Whether or not the DSCP field is used in flow identification as 370 the use of the DSCP field for flow identification is optional. 372 * If the DSCP field is used to identify a flow, then the flow 373 identification information (for that flow) includes a list of 374 DSCPs used by the given DetNet flow. 376 o UDP Source Port. Support for both exact and wildcard matching is 377 required. Port ranges can optionally be used. 379 o UDP Destination Port. Support for both exact and wildcard 380 matching is required. Port ranges can optionally be used. 382 o For end systems, an optional maximum IP packet size that should be 383 used for that outgoing DetNet IP flow. 385 This information MUST be provisioned per DetNet flow via 386 configuration, e.g., via the controller plane. 388 An implementation MUST support ordering of the set of information 389 used to identify an individual DetNet flow. This can, for example, 390 be used to provide a DetNet service for a specific UDP flow, with 391 unique Source and Destination Port field values, while providing a 392 different service for the aggregate of all other flows with that same 393 UDP Destination Port value. 395 The minimum set of information for the configuration of the DetNet 396 service sub-layer is summarized as follows: 398 o App-flow identification information. 400 o Sequence number length. 402 o PREOF + related Service-ID(s). 404 o Associated forwarding sub-layer information. 406 o Service aggregation information. 408 The minimum set of information for the configuration of the DetNet 409 forwarding sub-layer is summarized as follows: 411 o UDP tunnel specific information. 413 o Traffic parameters. 415 6. Security Considerations 417 There are no new DetNet related security considerations introduced by 418 this solution. 420 7. IANA Considerations 422 This document makes no IANA requests. 424 8. References 426 8.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, 430 DOI 10.17487/RFC2119, March 1997, 431 . 433 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 434 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 435 May 2017, . 437 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 438 "Deterministic Networking Architecture", RFC 8655, 439 DOI 10.17487/RFC8655, October 2019, 440 . 442 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 443 Bryant, "Deterministic Networking (DetNet) Data Plane 444 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 445 . 447 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 448 Bryant, "Deterministic Networking (DetNet) Data Plane: 449 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 450 . 452 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 453 S., and J. Korhonen, "Deterministic Networking (DetNet) 454 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 455 2021, . 457 [RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 458 Bryant, "Deterministic Networking (DetNet) Data Plane: 459 MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April 460 2021, . 462 8.2. Informative References 464 [I-D.varga-detnet-pof] 465 Varga, B., Farkas, J., Kehrer, S., and T. Heer, 466 "Deterministic Networking (DetNet): Packet Ordering 467 Function", draft-varga-detnet-pof-00 (work in progress), 468 April 2021. 470 [IEEE8021CB] 471 IEEE, "IEEE Standard for Local and metropolitan area 472 networks -- Frame Replication and Elimination for 473 Reliability", DOI 10.1109/IEEESTD.2017.8091139, October 474 2017, 475 . 477 [IEEEP8021CBcv] 478 Kehrer, S., "FRER YANG Data Model and Management 479 Information Base Module", IEEE P802.1CBcv 480 /D1.2 P802.1CBcv, March 2021, 481 . 484 Authors' Addresses 486 Balazs Varga 487 Ericsson 488 Magyar Tudosok krt. 11. 489 Budapest 1117 490 Hungary 492 Email: balazs.a.varga@ericsson.com 493 Janos Farkas 494 Ericsson 495 Magyar Tudosok krt. 11. 496 Budapest 1117 497 Hungary 499 Email: janos.farkas@ericsson.com 501 Andrew G. Malis 502 Malis Consulting 504 Email: agmalis@gmail.com