idnits 2.17.1 draft-varga-detnet-ip-preof-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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (23 October 2021) is 914 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-01 Summary: 1 error (**), 0 flaws (~~), 3 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: 26 April 2022 A. Malis 6 Malis Consulting 7 23 October 2021 9 Deterministic Networking (DetNet): PREOF for DetNet IP 10 draft-varga-detnet-ip-preof-01 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 technology used in [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 26 April 2022. 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 (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 54 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 55 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 3. Requirements for adding PREOF to DetNet IP . . . . . . . . . 4 57 4. Adding PREOF to DetNet IP . . . . . . . . . . . . . . . . . . 4 58 4.1. Solution Basics . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5 60 4.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 6 61 4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 6 62 4.5. PREOF Procedures . . . . . . . . . . . . . . . . . . . . 7 63 4.6. PREOF capable DetNet IP domain . . . . . . . . . . . . . 8 64 5. Control and Management Plane Parameters . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 The DetNet Working Group has defined packet replication (PRF), packet 75 elimination (PEF) and packet ordering (POF) functions to provide 76 service protection by the DetNet service sub-layer [RFC8655]. The 77 PREOF service protection method relies on copies of the same packet 78 sent over multiple maximally disjoint paths and uses sequencing 79 information to eliminate duplicates. A possible implementation of 80 the PRF and PEF functions is described in [IEEE8021CB] and the 81 related YANG data model is defined in [IEEEP8021CBcv]. A possible 82 implementation of POF function is described in 83 [I-D.varga-detnet-pof]. Figure 1 shows a DetNet flow on which PREOF 84 functions are applied during forwarding from the source to the 85 destination. 87 +------------+ 88 +---------------E1---+ | | 89 +---+ | | +---R3---+ | +---+ 90 |src|------R1 +---+ | E3----O----+dst| 91 +---+ | | E2-------+ +---+ 92 +----------R2 | 93 +-----------------+ 95 R: replication function (PRF) 96 E: elimination function (PEF) 97 O: ordering function (POF) 99 Figure 1: PREOF scenario in a DetNet network 101 In general, the use of PREOF functions require sequencing information 102 to be included in the packets of a DetNet compound flow. This may be 103 done by adding a sequence number or time stamp as part of DetNet 104 encapsulation. Sequencing information is typically added once, at or 105 close to the source. 107 The DetNet MPLS data plane [RFC8939] specifies how sequencing 108 information is encoded in the MPLS header. However, the DetNet IP 109 data plane described in [RFC8939] does not specify how sequencing 110 information can be encoded in the IP header. This document describes 111 a DetNet IP encapsulation that includes sequencing information based 112 on the DetNet MPLS over UDP/IP data plane [RFC9025], i.e., leveraging 113 the MPLS-over-UDP technology. 115 2. Terminology 117 2.1. Terms Used in This Document 119 This document uses the terminology established in the DetNet 120 architecture [RFC8655], and the reader is assumed to be familiar with 121 that document and its terminology. 123 2.2. Abbreviations 125 The following abbreviations are used in this document: 127 DetNet Deterministic Networking. 129 PEF Packet Elimination Function. 131 POF Packet Ordering Function. 133 PREOF Packet Replication, Elimination and Ordering Functions. 135 PRF Packet Replication Function. 137 2.3. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 3. Requirements for adding PREOF to DetNet IP 147 The requirements for adding PREOF to DetNet IP are: 149 * to reuse existing DetNet data plane solutions (e.g., [RFC8964], 150 [RFC9025]). 152 * to allow the DetNet service sub-layer for IP packet switched 153 networks with minimal implementation effort. 155 The described solution practically gains from MPLS header fields 156 without adding MPLS protocol stack complexity to the nodal 157 requirements. 159 4. Adding PREOF to DetNet IP 161 4.1. Solution Basics 163 The DetNet IP encapsulation supporting DetNet Service sub-layer is 164 based on the "UDP tunneling" concept. The solution creates a set of 165 underlay UDP/IP tunnels between an overlay set of DetNet relay nodes. 167 At the edge of a PREOF capable DetNet IP domain the DetNet flow is 168 encapsulated in an UDP packet containing the sequence number used by 169 PREOF functions within the domain. This solution maintains the 6- 170 tuple-based DetNet flow identification in DetNet transit nodes, which 171 operate at the DetNet forwarding sub-layer between the DetNet service 172 sub-layer nodes; therefore, it is compatible with [RFC8939]. 173 Figure 2 shows how the PREOF capable DetNet IP data plane fits into 174 the DetNet sub-layers. 176 DetNet IP 177 . 178 . 179 +------------+ 180 | Service | d-CW, Service-ID (S-label) 181 +------------+ 182 | Forwarding | UDP/IP Header 183 +------------+ 185 Figure 2: PREOF capable DetNet IP data plane 187 4.2. Encapsulation 189 The PREOF capable DetNet IP encapsulation builds on encapsulating 190 DetNet PW directly over UDP. That is, it combines DetNet MPLS 191 [RFC8964] with DetNet MPLS-in-UDP [RFC9025], without using any 192 F-Labels as shown in Figure 3. DetNet flows are identified at the 193 receiving DetNet service sub-layer processing node via the S-Label 194 and/or the UDP/IP header information. Sequencing information for 195 PREOF is provided by the DetNet Control Word (d-CW) as per [RFC8964]. 196 The S-label is used to identify both the DetNet flow and the DetNet 197 App-flow type. The UDP tunnel is used to direct the packet across 198 the DetNet domain to the next DetNet service sub-layer processing 199 node. 201 +---------------------------------+ 202 | | 203 | DetNet App-Flow | 204 | (original IP) Packet | 205 | | 206 +---------------------------------+ <--\ 207 | DetNet Control Word | | 208 +---------------------------------+ +--> PREOF capable 209 | Service-ID (S-Label) | | DetNet IP data 210 +---------------------------------+ | plane encapsulation 211 | UDP Header | | 212 +---------------------------------+ | 213 | IP Header | | 214 +---------------------------------+ <--/ 215 | Data-Link | 216 +---------------------------------+ 217 | Physical | 218 +---------------------------------+ 220 Figure 3: PREOF capable DetNet IP encapsulation 222 4.3. Packet Processing 224 IP ingress and egress nodes of the PREOF capable DetNet IP domain 225 MUST add and remove a DetNet service-specific d-CW and Service-ID 226 (i.e., S-Label). Relay nodes MAY change Service-ID values when 227 processing a DetNet flow, i.e., incoming and outgoing Service-IDs of 228 a DetNet flow can be different. Service-ID values MUST be 229 provisioned per DetNet service via configuration, i.e., via the 230 Controller Plane described in [RFC8938]. In some PREOF topologies, 231 the node performing replication sends the packets to multiple nodes 232 performing e.g., PEF or POF and the replication node may need to use 233 different Service-ID values for the different member flows for the 234 same DetNet service. 236 Note, that Service-IDs provide identification at the downstream 237 DetNet service sub-layer receiver, not the sender. 239 4.4. Flow Aggregation 241 Two methods can be used for flow aggregation: 243 * aggregation using same UDP tunnel, 245 * aggregating DetNet flows as a new DetNet flow. 247 In the first case, the different DetNet PWs use the same UDP tunnel, 248 so they are treated as a single (aggregated) flow on all transit 249 nodes. 251 For the second option, an additional Service-ID and d-CW tuple is 252 added to the encapsulation. The Aggregate-ID is a special case of a 253 Service-ID, whose properties are known only at the aggregation and 254 de-aggregation end points. It is a property of the Aggregate-ID that 255 it is followed by a d-CW followed by an Service-ID/d-CW tuple. 256 Figure 4 shows the encapsulation in case of aggregation. 258 +---------------------------------+ 259 | | 260 | DetNet App-Flow | 261 | Payload Packet | 262 | | 263 +---------------------------------+ <--\ 264 | DetNet Control Word | | 265 +---------------------------------+ +--> PREOF capable 266 | Service-ID (S-Label) | | DetNet IP data 267 +---------------------------------+ | plane encapsulation 268 | DetNet Control Word | | 269 +---------------------------------+ | 270 | Aggregate-ID (A-Label) | | 271 +---------------------------------+ | 272 | UDP Header | | 273 +---------------------------------+ | 274 | IP Header | | 275 +---------------------------------+ <--/ 276 | Data-Link | 277 +---------------------------------+ 278 | Physical | 279 +---------------------------------+ 281 Figure 4: Aggregating DetNet flows as a new DetNet flow 283 4.5. PREOF Procedures 285 A node operating on a received DetNet flow at the DetNet service sub- 286 layer uses the local context associated with a received Service-ID to 287 determine which local DetNet operation(s) are applied to received 288 packet. A Service-ID may be allocated to be unique and enabling 289 DetNet flow identification regardless of which input interface or UDP 290 tunnel the packet is received. It is important to note that Service- 291 ID values are driven by the receiver, not the sender. 293 The DetNet forwarding sub-layer is supported by the UDP tunnel and is 294 responsible for providing resource allocation and explicit routes. 296 To support outgoing PREOF capable DetNet IP encapsulation, an 297 implementation MUST support the provisioning of UDP and IP header 298 information. Note, when PRF is performed at the DetNet service sub- 299 layer, there are multiple member flows, and each member flow requires 300 their own Service-ID, UDP and IP header information. The headers for 301 each outgoing packet MUST be formatted according to the configuration 302 information, and the UDP Source Port value MUST be set to uniquely 303 identify the DetNet flow. The packet MUST then be handled as a PREOF 304 capable DetNet IP packet. 306 To support the receive processing, an implementation MUST also 307 support the provisioning of received Service-ID, UDP and IP header 308 information. The provisioned information MUST be used to identify 309 incoming app-flows based on the combination of Service-ID and/or 310 incoming encapsulation header information. 312 4.6. PREOF capable DetNet IP domain 314 Figure 5 shows using PREOF in a PREOF capable DetNet IP network. 316 <---------- PREOF capable DetNet IP ---------------> 317 ______ 318 ____ / \__ 319 ____ / \__/ \____________ 320 +----+ __/ \____/ \ +----+ 321 |src |_____/ \___| dst| 322 +----+ \_______ DetNet network __________/ +----+ 323 \_______ _/ 324 \ __ __/ 325 \_______/ \___/ 327 +------------+ 328 +---------------E1---+ | | 329 +----+ | | +---R3---+ | +----+ 330 |src |------R1 +---+ | E3----O----+ dst| 331 +----+ | | E2-------+ +----+ 332 +----------R2 | 333 +-----------------+ 335 Figure 5: PREOF capable DetNet IP domain 337 5. Control and Management Plane Parameters 339 The information needed to identify individual and aggregated DetNet 340 flows is summarized as follows: 342 * Service-ID information to be mapped to UDP/IP flows. Note that, 343 for example, a single Service-ID can map to multiple sets of UDP/ 344 IP information when PREOF is used. 346 * IPv4 or IPv6 source address field. 348 * IPv4 or IPv6 source address prefix length, where a zero (0) value 349 effectively means that the address field is ignored. 351 * IPv4 or IPv6 destination address field. 353 * IPv4 or IPv6 destination address prefix length, where a zero (0) 354 effectively means that the address field is ignored. 356 * IPv4 protocol field set to "UDP". 358 * IPv6 next header field set to "UDP". 360 * For the IPv4 Type of Service and IPv6 Traffic Class Fields: 362 - Whether or not the DSCP field is used in flow identification as 363 the use of the DSCP field for flow identification is optional. 365 - If the DSCP field is used to identify a flow, then the flow 366 identification information (for that flow) includes a list of 367 DSCPs used by the given DetNet flow. 369 * UDP Source Port. Support for both exact and wildcard matching is 370 required. Port ranges can optionally be used. 372 * UDP Destination Port. Support for both exact and wildcard 373 matching is required. Port ranges can optionally be used. 375 * For end systems, an optional maximum IP packet size that should be 376 used for that outgoing DetNet IP flow. 378 This information MUST be provisioned per DetNet flow via 379 configuration, e.g., via the controller plane. 381 An implementation MUST support ordering of the set of information 382 used to identify an individual DetNet flow. This can, for example, 383 be used to provide a DetNet service for a specific UDP flow, with 384 unique Source and Destination Port field values, while providing a 385 different service for the aggregate of all other flows with that same 386 UDP Destination Port value. 388 The minimum set of information for the configuration of the DetNet 389 service sub-layer is summarized as follows: 391 * App-flow identification information. 393 * Sequence number length. 395 * PREOF + related Service-ID(s). 397 * Associated forwarding sub-layer information. 399 * Service aggregation information. 401 The minimum set of information for the configuration of the DetNet 402 forwarding sub-layer is summarized as follows: 404 * UDP tunnel specific information. 406 * Traffic parameters. 408 6. Security Considerations 410 There are no new DetNet related security considerations introduced by 411 this solution. 413 7. IANA Considerations 415 This document makes no IANA requests. 417 8. References 419 8.1. Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, 423 DOI 10.17487/RFC2119, March 1997, 424 . 426 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 427 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 428 May 2017, . 430 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 431 "Deterministic Networking Architecture", RFC 8655, 432 DOI 10.17487/RFC8655, October 2019, 433 . 435 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 436 Bryant, "Deterministic Networking (DetNet) Data Plane 437 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 438 . 440 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 441 Bryant, "Deterministic Networking (DetNet) Data Plane: 442 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 443 . 445 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 446 S., and J. Korhonen, "Deterministic Networking (DetNet) 447 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 448 2021, . 450 [RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 451 Bryant, "Deterministic Networking (DetNet) Data Plane: 452 MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April 453 2021, . 455 8.2. Informative References 457 [I-D.varga-detnet-pof] 458 Varga, B., Farkas, J., Kehrer, S., and T. Heer, 459 "Deterministic Networking (DetNet): Packet Ordering 460 Function", Work in Progress, Internet-Draft, draft-varga- 461 detnet-pof-01, 21 May 2021, 462 . 465 [IEEE8021CB] 466 IEEE, "IEEE Standard for Local and metropolitan area 467 networks -- Frame Replication and Elimination for 468 Reliability", DOI 10.1109/IEEESTD.2017.8091139, October 469 2017, 470 . 472 [IEEEP8021CBcv] 473 Kehrer, S., "FRER YANG Data Model and Management 474 Information Base Module", IEEE P802.1CBcv 475 /D1.2 P802.1CBcv, March 2021, 476 . 479 Authors' Addresses 481 Balázs Varga 482 Ericsson 483 Budapest 484 Magyar Tudosok krt. 11. 485 1117 486 Hungary 488 Email: balazs.a.varga@ericsson.com 490 János Farkas 491 Ericsson 492 Budapest 493 Magyar Tudosok krt. 11. 494 1117 495 Hungary 496 Email: janos.farkas@ericsson.com 498 Andrew G. Malis 499 Malis Consulting 501 Email: agmalis@gmail.com