idnits 2.17.1 draft-ietf-detnet-mpls-over-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: ---------------------------------------------------------------------------- == 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], [RFC8939]), 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 (21 March 2022) is 765 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-02 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: 22 September 2022 A. Malis 6 Malis Consulting 7 21 March 2022 9 Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP 10 draft-ietf-detnet-mpls-over-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) built 16 on the existing MPLS PREOF solution [RFC8939] and the mechanisms 17 defined in [RFC9025]. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 22 September 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised 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 * to reuse existing DetNet data plane solutions (e.g., [RFC8964], 151 [RFC9025]). 153 * to allow the DetNet service sub-layer for IP packet switched 154 networks with minimal implementation effort. 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. The solution creates a set of 166 underlay UDP/IP tunnels between an overlay set of DetNet relay nodes. 168 At the edge of a PREOF capable DetNet IP domain the DetNet flow is 169 encapsulated in an UDP packet containing the sequence number used by 170 PREOF functions within the domain. This solution maintains the 6- 171 tuple-based DetNet flow identification in DetNet transit nodes, which 172 operate at the DetNet forwarding sub-layer between the DetNet service 173 sub-layer nodes; therefore, it is compatible with [RFC8939]. 174 Figure 2 shows how the PREOF capable DetNet IP data plane fits into 175 the DetNet sub-layers. 177 DetNet IP 178 . 179 . 180 +------------+ 181 | Service | d-CW, Service-ID (S-label) 182 +------------+ 183 | Forwarding | UDP/IP Header 184 +------------+ 186 Figure 2: PREOF capable DetNet IP data plane 188 4.2. Encapsulation 190 The PREOF capable DetNet IP encapsulation builds on encapsulating 191 DetNet PW directly over UDP. That is, it combines DetNet MPLS 192 [RFC8964] with DetNet MPLS-in-UDP [RFC9025], without using any 193 F-Labels as shown in Figure 3. DetNet flows are identified at the 194 receiving DetNet service sub-layer processing node via the S-Label 195 and/or the UDP/IP header information. Sequencing information for 196 PREOF is provided by the DetNet Control Word (d-CW) as per [RFC8964]. 197 The S-label is used to identify both the DetNet flow and the DetNet 198 App-flow type. The UDP tunnel is used to direct the packet across 199 the DetNet domain to the next DetNet service sub-layer processing 200 node. 202 +---------------------------------+ 203 | | 204 | DetNet App-Flow | 205 | (original IP) Packet | 206 | | 207 +---------------------------------+ <--\ 208 | DetNet Control Word | | 209 +---------------------------------+ +--> PREOF capable 210 | Service-ID (S-Label) | | DetNet IP data 211 +---------------------------------+ | plane encapsulation 212 | UDP Header | | 213 +---------------------------------+ | 214 | IP Header | | 215 +---------------------------------+ <--/ 216 | Data-Link | 217 +---------------------------------+ 218 | Physical | 219 +---------------------------------+ 221 Figure 3: PREOF capable DetNet IP encapsulation 223 4.3. Packet Processing 225 IP ingress and egress nodes of the PREOF capable DetNet IP domain 226 MUST add and remove a DetNet service-specific d-CW and Service-ID 227 (i.e., S-Label). Relay nodes MAY change Service-ID values when 228 processing a DetNet flow, i.e., incoming and outgoing Service-IDs of 229 a DetNet flow can be different. Service-ID values MUST be 230 provisioned per DetNet service via configuration, i.e., via the 231 Controller Plane described in [RFC8938]. In some PREOF topologies, 232 the node performing replication sends the packets to multiple nodes 233 performing e.g., PEF or POF and the replication node may need to use 234 different Service-ID values for the different member flows for the 235 same DetNet service. 237 Note, that Service-IDs provide identification at the downstream 238 DetNet service sub-layer receiver, not the sender. 240 4.4. Flow Aggregation 242 Two methods can be used for flow aggregation: 244 * aggregation using same UDP tunnel, 246 * aggregating DetNet flows as a new DetNet flow. 248 In the first case, the different DetNet PWs use the same UDP tunnel, 249 so they are treated as a single (aggregated) flow on all transit 250 nodes. 252 For the second option, an additional Service-ID and d-CW tuple is 253 added to the encapsulation. The Aggregate-ID is a special case of a 254 Service-ID, whose properties are known only at the aggregation and 255 de-aggregation end points. It is a property of the Aggregate-ID that 256 it is followed by a d-CW followed by an Service-ID/d-CW tuple. 257 Figure 4 shows the encapsulation in case of aggregation. 259 +---------------------------------+ 260 | | 261 | DetNet App-Flow | 262 | Payload Packet | 263 | | 264 +---------------------------------+ <--\ 265 | DetNet Control Word | | 266 +---------------------------------+ +--> PREOF capable 267 | Service-ID (S-Label) | | DetNet IP data 268 +---------------------------------+ | plane encapsulation 269 | DetNet Control Word | | 270 +---------------------------------+ | 271 | Aggregate-ID (A-Label) | | 272 +---------------------------------+ | 273 | UDP Header | | 274 +---------------------------------+ | 275 | IP Header | | 276 +---------------------------------+ <--/ 277 | Data-Link | 278 +---------------------------------+ 279 | Physical | 280 +---------------------------------+ 282 Figure 4: Aggregating DetNet flows as a new DetNet flow 284 4.5. PREOF Procedures 286 A node operating on a received DetNet flow at the DetNet service sub- 287 layer uses the local context associated with a received Service-ID to 288 determine which local DetNet operation(s) are applied to received 289 packet. A Service-ID may be allocated to be unique and enabling 290 DetNet flow identification regardless of which input interface or UDP 291 tunnel the packet is received. It is important to note that Service- 292 ID values are driven by the receiver, not the sender. 294 The DetNet forwarding sub-layer is supported by the UDP tunnel and is 295 responsible for providing resource allocation and explicit routes. 297 To support outgoing PREOF capable DetNet IP encapsulation, an 298 implementation MUST support the provisioning of UDP and IP header 299 information. Note, when PRF is performed at the DetNet service sub- 300 layer, there are multiple member flows, and each member flow requires 301 their own Service-ID, UDP and IP header information. The headers for 302 each outgoing packet MUST be formatted according to the configuration 303 information, and the UDP Source Port value MUST be set to uniquely 304 identify the DetNet flow. The packet MUST then be handled as a PREOF 305 capable DetNet IP packet. 307 To support the receive processing, an implementation MUST also 308 support the provisioning of received Service-ID, UDP and IP header 309 information. The provisioned information MUST be used to identify 310 incoming app-flows based on the combination of Service-ID and/or 311 incoming encapsulation header information. 313 4.6. PREOF capable DetNet IP domain 315 Figure 5 shows using PREOF in a PREOF capable DetNet IP network. 317 <---------- PREOF capable DetNet IP ---------------> 318 ______ 319 ____ / \__ 320 ____ / \__/ \____________ 321 +----+ __/ \____/ \ +----+ 322 |src |_____/ \___| dst| 323 +----+ \_______ DetNet network __________/ +----+ 324 \_______ _/ 325 \ __ __/ 326 \_______/ \___/ 328 +------------+ 329 +---------------E1---+ | | 330 +----+ | | +---R3---+ | +----+ 331 |src |------R1 +---+ | E3----O----+ dst| 332 +----+ | | E2-------+ +----+ 333 +----------R2 | 334 +-----------------+ 336 Figure 5: PREOF capable DetNet IP domain 338 5. Control and Management Plane Parameters 340 The information needed to identify individual and aggregated DetNet 341 flows is summarized as follows: 343 * Service-ID information to be mapped to UDP/IP flows. Note that, 344 for example, a single Service-ID can map to multiple sets of UDP/ 345 IP information when PREOF is used. 347 * IPv4 or IPv6 source address field. 349 * IPv4 or IPv6 source address prefix length, where a zero (0) value 350 effectively means that the address field is ignored. 352 * IPv4 or IPv6 destination address field. 354 * IPv4 or IPv6 destination address prefix length, where a zero (0) 355 effectively means that the address field is ignored. 357 * IPv4 protocol field set to "UDP". 359 * IPv6 next header field set to "UDP". 361 * For the IPv4 Type of Service and IPv6 Traffic Class Fields: 363 - Whether or not the DSCP field is used in flow identification as 364 the use of the DSCP field for flow identification is optional. 366 - If the DSCP field is used to identify a flow, then the flow 367 identification information (for that flow) includes a list of 368 DSCPs used by the given DetNet flow. 370 * UDP Source Port. Support for both exact and wildcard matching is 371 required. Port ranges can optionally be used. 373 * UDP Destination Port. Support for both exact and wildcard 374 matching is required. Port ranges can optionally be used. 376 * For end systems, an optional maximum IP packet size that should be 377 used for that outgoing DetNet IP flow. 379 This information MUST be provisioned per DetNet flow via 380 configuration, e.g., via the controller plane. 382 An implementation MUST support ordering of the set of information 383 used to identify an individual DetNet flow. This can, for example, 384 be used to provide a DetNet service for a specific UDP flow, with 385 unique Source and Destination Port field values, while providing a 386 different service for the aggregate of all other flows with that same 387 UDP Destination Port value. 389 The minimum set of information for the configuration of the DetNet 390 service sub-layer is summarized as follows: 392 * App-flow identification information. 394 * Sequence number length. 396 * PREOF + related Service-ID(s). 398 * Associated forwarding sub-layer information. 400 * Service aggregation information. 402 The minimum set of information for the configuration of the DetNet 403 forwarding sub-layer is summarized as follows: 405 * UDP tunnel specific information. 407 * Traffic parameters. 409 6. Security Considerations 411 There are no new DetNet related security considerations introduced by 412 this solution. 414 7. IANA Considerations 416 This document makes no IANA requests. 418 8. References 420 8.1. Normative References 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", BCP 14, RFC 2119, 424 DOI 10.17487/RFC2119, March 1997, 425 . 427 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 428 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 429 May 2017, . 431 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 432 "Deterministic Networking Architecture", RFC 8655, 433 DOI 10.17487/RFC8655, October 2019, 434 . 436 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 437 Bryant, "Deterministic Networking (DetNet) Data Plane 438 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 439 . 441 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 442 Bryant, "Deterministic Networking (DetNet) Data Plane: 443 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 444 . 446 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 447 S., and J. Korhonen, "Deterministic Networking (DetNet) 448 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 449 2021, . 451 [RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 452 Bryant, "Deterministic Networking (DetNet) Data Plane: 453 MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April 454 2021, . 456 8.2. Informative References 458 [I-D.varga-detnet-pof] 459 Varga, B., Farkas, J., Kehrer, S., and T. Heer, 460 "Deterministic Networking (DetNet): Packet Ordering 461 Function", Work in Progress, Internet-Draft, draft-varga- 462 detnet-pof-02, 22 October 2021, 463 . 466 [IEEE8021CB] 467 IEEE, "IEEE Standard for Local and metropolitan area 468 networks -- Frame Replication and Elimination for 469 Reliability", DOI 10.1109/IEEESTD.2017.8091139, October 470 2017, 471 . 473 [IEEEP8021CBcv] 474 Kehrer, S., "FRER YANG Data Model and Management 475 Information Base Module", IEEE P802.1CBcv 476 /D1.2 P802.1CBcv, March 2021, 477 . 480 Authors' Addresses 482 Balázs Varga 483 Ericsson 484 Budapest 485 Magyar Tudosok krt. 11. 486 1117 487 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 497 Andrew G. Malis 498 Malis Consulting 499 Email: agmalis@gmail.com