idnits 2.17.00 (12 Aug 2021) /tmp/idnits44229/draft-pthubert-detnet-ipv6-hbh-07.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 341: '...e representation MUST be large enough ...' RFC 2119 keyword, line 353: '...rigin node that builds the option MUST...' RFC 2119 keyword, line 375: '...n of the counter MUST be large enough ...' RFC 2119 keyword, line 397: '... Type it MUST skip over this opti...' RFC 2119 keyword, line 405: '...t fragments tags MUST be considered as...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (22 February 2022) is 81 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) ** Downref: Normative reference to an Informational RFC: RFC 8877 ** Downref: Normative reference to an Informational RFC: RFC 9030 (ref. '6TiSCH-ARCH') ** Downref: Normative reference to an Informational draft: draft-pthubert-raw-architecture (ref. 'RAW-ARCH') == Outdated reference: A later version (-25) exists of draft-ietf-roll-dao-projection-23 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track F. Yang 5 Expires: 26 August 2022 Huawei Technologies 6 22 February 2022 8 IPv6 Options for DetNet 9 draft-pthubert-detnet-ipv6-hbh-07 11 Abstract 13 RFC 8938, the Deterministic Networking Data Plane Framework relies on 14 the 6-tuple to identify an IPv6 flow. But the full DetNet operations 15 require also the capabilities to signal meta-information such as a 16 sequence within that flow, and to transport different types of 17 packets along the same path with the same treatment, e.g., 18 Operations, Administration, and Maintenance packets and/or multiple 19 flows with fate and resource sharing. This document introduces new 20 IPv6 options that signal that path and redundancy information to the 21 intermediate DetNet relay and forwarding nodes. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 26 August 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. The DetNet Options . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. DetNet Redundancy Information Option . . . . . . . . . . 8 61 4.2. DetNet Path Options . . . . . . . . . . . . . . . . . . . 12 62 4.2.1. DetNet Strict Path Option . . . . . . . . . . . . . . 12 63 4.2.2. DetNet Loose Path Option . . . . . . . . . . . . . . 14 64 4.3. RPL Packet Information . . . . . . . . . . . . . . . . . 15 65 5. Encapsulation of DetNet Options . . . . . . . . . . . . . . . 15 66 5.1. IPv6 Network . . . . . . . . . . . . . . . . . . . . . . 15 67 5.2. Segment Routing over IPv6 Network . . . . . . . . . . . . 17 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 70 7.1. New Subregistry for the Redundancy Type . . . . . . . . . 19 71 7.2. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . 19 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 75 9.2. Informative References . . . . . . . . . . . . . . . . . 21 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 78 1. Introduction 80 Section 2 of the Deterministic Networking Problem Statement 81 [DetNet-PBST] introduces the concept of Deterministic Networking 82 (DetNet) to the IETF. DetNet extends the reach of lower layer 83 technologies such as Time-Sensitive Networking (TSN) [IEEE 802.1 TSN] 84 and Timeslotted Channel Hopping (TSCH) [IEEE Std. 802.15.4] over IPv6 85 and MPLS [RFC8938], to provide bounded latency and reliability 86 guarantees over an end-to-end layer-3 nailed-down path. 88 The "Deterministic Networking Architecture" [DetNet-ARCH] details the 89 contribution of layer-3 protocols, and defines three planes: the 90 Application (User) Plane, the Controller Plane, and the Network 91 Plane. [DetNet-ARCH] places an emphasis on the centralized model 92 whereby a controller instantiates a DetNet state in the routers that 93 is located based on matching information in the packet. 95 The "Deterministic Networking Data Plane Framework" [RFC8938] relies 96 on the 6-tuple to identify an IPv6 flow. But the full DetNet 97 operations require also the capabilities to signal meta-information 98 such as a sequence within that flow, and to transport different types 99 of packets along the same path with the same treatment. For 100 instance, it is required that Operations, Administration, and 101 Maintenance (OAM) [RFC6291] packets and/or multiple flows share the 102 same fate and resource sharing over the same Track or the same 103 Traffic Engineered (TE) [RFC3272] DetNet path. This document 104 proposes a layer-3 signaling that is independent of the upper layer 105 information, to locate the DetNet state and enable the same 106 forwarding nehavior for the data flows and the OAM packets. 108 The "6TiSCH Architecture" [6TiSCH-ARCH] leverages RPL, the "Routing 109 Protocol for Low Power and Lossy Networks" [RPL] and introduces 110 concept of a Track as a highly redundant RPL Destination Oriented 111 Directed Acyclic Graph (DODAG) rooted at the Track Ingress. The 112 Track is indicative of a layer-3 forwarding behavior (e.g., next 113 hops)as opposed to indicative of the upper layer content, so it is 114 more in line with the DetNet needs than the 6-tuple. 116 A Track may for instance be installed using RPL route projection 117 [RPL-PDAO]. In that case, the TrackId is an index from a namespace 118 associated to one IPv6 address of the Track Ingress node, and the 119 Track that an IPv6 packet follows is signaled by the combination of 120 the source address (of the Track Ingress node), and the TrackID 121 placed in a RPL Option [RFC6553] located in an IPv6 Hop-by-Hop (HbH) 122 Options Header [IPv6] in the IPv6 packet. 124 The "Reliable and Available Wireless (RAW) Architecture/Framework" 125 [RAW-ARCH], extends the DetNet Network Plane to accomodate one or 126 multiple hops of homogeneous or heterogeneous wireless technologies, 127 e.g. a Wi-Fi6 Mesh or parallel radio access links combining Wi-Fi and 128 5G. The RAW Architecture reuses the concept of Track and introduces 129 a new dataplane component, the Path Selection Engine (PSE), to 130 dynamically select a subpath and maintain the required quality of 131 service within a Track in the face of the rapid evolution of the 132 medium properties. 134 With [IPv6], the behavior of a router upon an IPv6 packet with a HbH 135 Options Header has evolved, making the examination of the header by 136 routers along the path optional, as opposed to previously mandatory. 137 Additionally, the Option Type for any option in a HbH Options Header 138 encodes in the leftmost bits whether a router that inspects the 139 header should drop the packet or ignore the option when encountering 140 an unknown option. Combined, these capabilities enable a larger use 141 of the header beyond the boundaries of a limited domain, as 142 examplified by the change of behavior of the RPL data plane, that was 143 changed to allow a packet with a RPL option to escape the RPL domain 144 in the larger Internet [RFC9008]. 146 "IPv6 Hop-by-Hop Options Processing Procedures" [HbH-UPDT] further 147 specifies the procedures for how IPv6 Hop-by-Hop options are 148 processed to make their processing even more practical and increase 149 their use in the Internet. In that context, it makes sense to 150 consider Hop-by-Hop Options to transport the information that is 151 relevant to DetNet. 153 As opposed to the HbH EH, the Destination Option Header (DOH) is only 154 read by the destination of the packet, which can be one at a time the 155 collection of nodes listed in a Routing Extension Header (RH) if the 156 DOH is placed before the RH. 158 This document introduces new IPv6 Options, the DetNet Redundancy 159 Information Option and the DetNet Path Options, that signal the 160 DetNet information to the intermediate DetNet nodes in an abstract 161 form, that is pure layer-3 and agnostic of the transport layer. The 162 options are placed in either a HbH EH or in a DOH, which happens when 163 the next node that needs to process the option is the IPv6 164 destination in the IPv6 header. 166 This pure layer-3 technique alines DetNet with the IPv6 architecture 167 and opens to the progress / extensions done elsewhere for IPv6; e.g., 168 if the DetNet path leverages Segment routing (SRv6) [RFC8402] for 169 some reason - there are plausible ones in RAW -, the Segment Routing 170 Header (SRH) [RFC8754] is inserted after the HbH and/or DOH by the PE 171 and both are readily accessible for the on-path routers without the 172 need of a deeper inspection of the packet (up to and beyond the 173 transport header). 175 For instance, the DetNet Redundancy Information Option may be placed 176 in a DOH before an SRH that signals the exhaustive list of the DetNet 177 relays along the path of the packet, so every relay can process the 178 redundancy information therein, while the DetNet Strict Path Option 179 would be placed in an HbH EH to be read by every DetNet forwarding 180 node, and intercepted should it strays away from its path. 182 2. Terminology 184 Timestamp semantics and timestamp formats used in this document are 185 defined in "Guidelines for Defining Packet Timestamps" [RFC8877]. 187 The Deterministic Networking terms used in this document are defined 188 in the "Deterministic Networking Architecture" [DetNet-ARCH]. 190 The terms Track and TrackID are defined in the "6TiSCH Architecture" 191 [6TiSCH-ARCH]. 193 3. Applicability 195 The "Deterministic Networking (DetNet) Data Plane: IP" [RFC8939] 196 illustrates the need for DetNet Services at the IP network layer in 197 conformance to the DetNet architecture [DetNet-ARCH] and data plane 198 framework [RFC8938]). As the specification does not introduce a new 199 header for DetNet, it also lacks the capability to signal PREOF at 200 the network layer. Instead, the information of application flows 201 (the 6-tuple), on which the network layer has no control, is used 202 directly to makes network layer forwarding decisions. This confuses 203 the signaling of the application-layer "water" that being transported 204 and with the network-layer "pipe" that transports it and makes it 205 problematic to aggregate applications flows and OAM for a equal 206 treatment. It is thus desirable to introduce a new signaling to 207 enable PREOF and flow aggregation independently of the application 208 flow that is more appropriate for network layer operations. 210 [I-D.varga-detnet-ip-preof] provides a methods for signaling PREOF 211 over UDP that combines the MPLS PREOF signaling defined in "DetNet 212 Data Plane: MPLS" [RFC8964] and the mechanisms defined in "DetNet 213 Data Plane: MPLS over UDP/IP" [RFC9025]. This approach provides IP 214 version independence, allows to reuse MPLS structures and possibly to 215 bridge MPLS DetNet flows onto IP with minimal mapping effort. It is 216 thus specially valuable in environments where flows can be 217 transported in any combination of MPLS and IP. OTOH, the signaled 218 information inherits the limitations of MPLS in terms of stack 219 structure, and is available after the transport header, which can be 220 harder to reach for a hardware solution, in particular in the 221 presence of a variable header chain at the network layer. 223 This draft proposes a native IPv6 solution that transports enriched 224 DetNet PREOF information in IPv6 Extension Headers. This method 225 reduces the encapsulation overhead, can be combined with the use of 226 "IPv6 Segment Routing (SRv6) Header (SRH)" [RFC8754], and simplifies 227 the access to the PREOF data by placing it early in the network 228 header chain. The forwarding information (the path) is advertised 229 independently of the application flow information (observable as the 230 6-tuple). This enables any mix and match of flows and OAM data over 231 the same path with the same treatment. The method is thus suited for 232 environments that are IPv6-only, where flows can be aggregated over 233 larger pipes and disaggregated again, but it is harder to combine 234 with MPLS and requires that all nodes on path can parse at least the 235 IPv6 Extension Header that signal the path. 237 Transported in IPv6 Extension Headers, the DetNet options are easier 238 to reach for a hardware or otherwise constrained implementation. A 239 DetNet-aware end-system (see section 4.2 of [DetNet-ARCH]) may place 240 the options in the header chain when constructing the packet, in 241 which case there is no need of an encapsulation. 243 Alternatively, the source end system may signal the flow information 244 some other way, or it may lack the full DetNet awareness; in that 245 case the DetNet path endpoints are the provider Edge (PE) routers 246 (see Figure 1 reproducing figure 5 of [DetNet-ARCH]) and the Ingress 247 PE needs to encapsulate the packets to add the HbH options. 249 In Figure 1, the DetNet end systems may be f-aware and signal an IPv6 250 flow using the 6-tuple for the End-to-End service, but may not be 251 s-aware, and may not sequence the packets for Packet Replication, 252 Elimination, and Ordering Functions (PREOF), which operate at the 253 detNet Service Layer. In that case, the Ingress PE will encapsulate 254 the packets for this and possibly other flows to provide a common 255 DetNet Service with OAM and PREOF, across the DetNet-1 service 256 provider network, terminating the tunnel at the Egress PE router. 258 _ 259 / \ +----DetNet-UNI (U) / \ 260 /App\ | /App\ 261 /-----\ | /-----\ 262 | NIC | v ________ | NIC | 263 +--+--+ _____ / \ DetNet-UNI (U) --+ +--+--+ 264 | / \__/ \ | | 265 | / +----+ +----+ \_____ | | 266 | / | | | | \_______ | | 267 +------U PE +----+ P +----+ \ _ v | 268 | | | | | | | ___/ \ | 269 | +--+-+ +----+ | +----+ | / \_ | 270 \ | | | | | / \ | 271 \ | +----+ +--+-+ +--+PE |------ U-----+ 272 \ | | | | | | | | | \_ _/ 273 \ +---+ P +----+ P +--+ +----+ | \____/ 274 \___ | | | | / 275 \ +----+__ +----+ DetNet-1 DetNet-2 276 | \_____/ \___________/ | 277 | | 278 | | End-to-End Service | | | | 279 <-------------------------------------------------------------> 280 | | DetNet Service | | | | 281 | <------------------------------------------------> | 282 | | | | | | 284 Figure 1: Figure 5 of RFC 8655, Reproduced 286 4. The DetNet Options 288 This document defines new IPv6 options for DetNet to signal path and 289 a reliability information (e.g., sequencing) to the DetNet layers. 290 Those options are to be placed in the IPv6 HbH Options Header, which 291 is found right after the outer IPv6 header in the DetNet packet and 292 immediately reachable for the forwarding engine. The format of the 293 options follow the generic definition in section 4.2 of [IPv6]. For 294 each tyoe of option, the draft allows to express the information in 295 different fashions, depending on the use case, and possibly carrying 296 an information that plays the same role at another layer, in which 297 case the format of the information is opaque. 299 The reliability information may be inherited from another layer as 300 long as the value is guaranteed to be unique within a reasonable set 301 of sequential packet so all packets with the same value are 302 redundant. Timestamping can be used as an alternate sequencing 303 technique, that avoids maintaining per-path state at the path 304 ingress, which is feasible for nodes that maintain a very precise 305 sense of time (e.g., from GPS or PTP) for their DetNet operations. 307 As long as the time granularity is in the order of a few bytes 308 transmission, the system timestamp provides an absolute sense of 309 ordering over a very long period across all paths for which this node 310 is ingress, and thus within any of those. Alternatively, the draft 311 allows to combine a rough time stamp (e.g., from a system clock 312 synchronized by NTP) and a sequence counter that differntiates the 313 packets that are stamped within the timer resolution. 315 If a DetNet Path option (see Section 4.2), including the RPL Option, 316 is present in the same HbH Option Header as a DetNet Redundancy 317 Information option (see Section 4.1), then the redundancy information 318 applies to the signaled path across all flows that traverse that 319 path; else the redundancy information applies to the flow indicated 320 by the 6-tuple [RFC8938]. 322 4.1. DetNet Redundancy Information Option 324 The DetNet Redundancy Information Option helps discriminate copies of 325 a same packet vs. different packets, and is useful for service- 326 sublayer Packet Replication Elimination and Ordering Functions 327 (PREOF). The option may be placed either in an HbH or a DoH EH, 328 e.g., prior to a Segment Routing Header (SRH) [RFC8754] that lists 329 the DetNet relays. A sequence counter is probably the most typical 330 expression of the redundancy information, but it is not the only way 331 to identify a packet and/or enable reordering, e.g., a timestamp can 332 be seen as a large sequence counter with gaps. 334 It is also possible that a packet is divided in elements such as 335 network-coded fragments. In that case, the pieces are discriminated 336 with an opaque 8-bit fragment tag. The goal is to retain one copy of 337 each fragment but not reorder them. 339 A packet sequence can be expressed uniquely as a wrapping counter, 340 represented as an unsigned integer in the option. In that case, the 341 size of the representation MUST be large enough to cover at least 3 342 times the upper bound on out-of-order packet delivery in terms of 343 number of packets. The sequence counter may be copied from a field 344 in another protocol, and it is possible that the value 0 is reserved 345 when wrapping, to the option offers both possibilities, wrapping to 346 either 0 or to 1. 348 This specification also allows to use a time stamp for the packet 349 redundancy information, in conformance with the recommendations in 350 [RFC8877]. This can be accomplished by utilizing the Precision Time 351 Protocol (PTP) format defined in IEEE Std. 1588 [IEEE Std. 1588] or 352 Network Time Protocol (NTP) [RFC5905] formats. In that case, the 353 timestamp resolution at the origin node that builds the option MUST 354 be fine enough to ensure that two consecutive packets are never 355 stamped with the same value. There is no requirement for this 356 particular stamping function that the sense of time at the origin 357 node is synchronized with the rest of the DetNet network. 359 IEEEE TSN [IEEE 802.1 TSN] defined a redundancy tag (R-Tag) for the 360 IEEE Std. 802.1CB Frame Replication and Elimination for Reliability 361 (FRER). The R-Tag is a structured field and its content is subject 362 to evolve; but the expectation for this specification is that the 363 overall size remains 48 bits and that the 48-bit value is different 364 for a large number of contiguous frames. When transporting TSN 365 frames in a DetNet packet, it is possible to leverage the R-Tag as 366 Redundancy information, though it cannot be assumed that the R-Tag is 367 sequentially incremented; so it can be used for packet duplicate 368 elimination but it is not suitable not for packet re-ordering. 370 This specification also allows for an hybrid model with a coarse 371 grained packet sequence within a coarse grained time stamp. In that 372 case, both a time stamp option and a wrapping counter options are 373 found, and the counter is used to compare packets with the same time 374 stamp and ignored otherwise In that case, the size of the 375 representation of the counter MUST be large enough to cover at least 376 3 times the number of packets that may be sent with the same value of 377 time stamp. 379 0 1 2 3 380 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Option Type | Opt Data Len | R.I. Type | Fragment Tag | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 . . 386 . Redundancy Information (variable Size) . 387 . . 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Figure 2: Redundancy Information Option Format 393 Redundancy Information Option fields: 395 Option Type: 8-bit identifier of the type of option. Value TBD by 396 IANA; if the processing IPv6 node does not recognize the Option 397 Type it MUST skip over this option and continue processing the 398 header (act =00); the Option Data of that option cannot change en 399 route to the packet's final destination (chg=0). The 401 Opt Data Len: 8-bit length of the option data. 403 Fragment Tag: 8-bit field, set to 0 when the packet is sent in 404 entirety; packets with the same Redundancy Information and 405 different fragments tags MUST be considered as different by the 406 elimination function and are not subject to ordering based on the 407 Tag. 409 Redundancy Information Type: 8-bit identifier of the type of 410 Redundancy information. Value to be confirmed by IANA. 412 +=======+============+===============+===========================+ 413 | Seq. | Category | Common Name | Redundancy | 414 | Type | | | Information Format | 415 | Value | | | | 416 +=======+============+===============+===========================+ 417 | 1 | Wrapping | Basic | 32-bit unsigned | 418 | | Counter | Sequence | integer | 419 | | | Counter | | 420 +-------+============+---------------+---------------------------+ 421 | 2 | Wrapping | Zero-avoiding | 32-bit unsigned | 422 | | Counter | Sequence | integer, wraps to 1 | 423 | | | Counter | | 424 +-------+============+---------------+---------------------------+ 425 | 3 | Wrapping | RPL Sequence | 8-bit RPL sequence, | 426 | | Counter | Counter | see section 7. of | 427 | | | | [RPL] | 428 +-------+============+---------------+---------------------------+ 429 | 11 | Time Stamp | Fractional | NTP 64-bit Timestamp | 430 | | | NTP | Format, see section | 431 | | | | 4.2.1. of [RFC8877] | 432 +-------+============+---------------+---------------------------+ 433 | 12 | Time Stamp | Short NTP | NTP 32-bit Timestamp | 434 | | | | Format, see section | 435 | | | | 4.2.2. of [RFC8877] | 436 +-------+============+---------------+---------------------------+ 437 | 13 | Time Stamp | PTP | PTP 80-bit Timestamp | 438 | | | | Format, see [IEEE | 439 | | | | Std. 1588] | 440 +-------+============+---------------+---------------------------+ 441 | 14 | Time Stamp | Short PTP | PTP 64-bit Truncated | 442 | | | | Timestamp Format, | 443 | | | | see section 4.3. of | 444 | | | | [RFC8877] | 445 +-------+============+---------------+---------------------------+ 446 | 24 | Structured | TSN | 48-bit opaque | 447 | | Unique Tag | Redundancy | | 448 | | | Tag | | 449 +-------+============+---------------+---------------------------+ 451 Table 1: Redundancy Information Type values (suggested) 453 Redundancy Information: Variable size, as indicated in Table 1. 455 4.2. DetNet Path Options 457 The DetNet Architecture [DetNet-ARCH] assigns a DetNet flow "to 458 specific paths through a network", but is not specific on how the 459 path is then signaled in the packet. The DetNet Data Plane Framework 460 [RFC8938] relies on the 6-tuple to identify an IPv6 flow and 461 implicitely the path could be indexed by the flow identification. 462 But this requires to maintain one path per flow and makes it 463 difficult to assign other traffic such as OAM to the same path. 465 This draft provides aditional means to signal the path in which the 466 flow is placed separately from the flow indentification, and 467 independantly of the transport layer, so a path can be shared between 468 one or more flows and OAM packets across IP address families. All 469 the packets that are assigned to the same path are subject to the 470 same DetNet forwarding treatment. 472 the DetNet expectation is that a PCE sets up a state at the DetNet 473 forwarding sublayer to instruct each hop on how to process the DetNet 474 flows. The DetNet Path Options when present contains information 475 that MUST be used to select the DetNet state installed and if the 476 DetNet state does not exist then the packet cannot be forwarded. 478 4.2.1. DetNet Strict Path Option 480 In complement to the RPL option, this specification defines a 481 protocol-independent Strict Path Identifier, which is also taken from 482 a namespace indicated by the IPv6 source address of the packet. 484 The DetNet Strict Path Option is to be used in a limited domain to 485 indicate a routing state that must be present in all nodes to ensure 486 that the packet is routed along a strictly predefined path, for 487 instance pointing at a specific next hop with reserved resources for 488 buffers and bandwidth. For that reason all the routers along the 489 path are expected to support the option and own a state indexed by 490 the Strict Path ID indicated therein. 492 The option is placed in an HbH EH to be seen by all routers on path. 493 The path indicated therein may also be used by the service sublayer, 494 to signal the scope where the redundancy information is unique across 495 a number of packets large enough to ensure that a forwarding node 496 never has to handle different packets with the same redundancy 497 information, though the same value may be found for packets with a 498 different path information. 500 The typical DetNet path is typically contained under a single 501 administrative control or within a closed group of administrative 502 control; these include campus-wide networks and private WANs 504 [DetNet-ARCH]. The typical expectation is that all nodes along a 505 DetNet path are aware of the path and actively maintain a forwarding 506 state for it. The DetNet Strict Path Option (see Section 4.2.1) is 507 designed for that environment; if a packet escapes the local domain, 508 a router that does not support the option will intercept it and 509 return an error to the source. 511 In other environments such as RAW, it might be that the service-layer 512 protection concentrates on just segments of the end-to-end path. In 513 that case, the service-sublayer protection may require the signaling 514 of both redundancy and path information, though the path information 515 is potentially not used by some of the intermediate routers and may 516 not be used for forwarding at all. The path information may also 517 relate to segments that are installed along the path using a DetNet 518 forwarding state as opposed to, say, source routing. In either case 519 the DetNet Loose Path Option Section 4.2.2 can be used to signal the 520 path without incurring an ICMP Error from an intermediate node. 522 An intermediate router that supports the DetNet Strict Path Option 523 but is missing the necessary state to forward along the indicated 524 path must drop the packet and return an ICMP error.code 0 pointing at 525 the offset of the Strict Path ID in the DetNet Strict Path Option. 527 DetNet can also leverage the RPL Option that signals a Track in the 528 RPL Packet Information (RPI) [RFC6553]. There are 2 versions of the 529 RPL option, defined respectively in [RPL] with the act bits [IPv6] 530 set to dropped the packet when the option is unknown, that defined 531 in[RFC9008] which let the option be ignored. 533 0 1 2 3 534 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Option Type | Opt Data Len | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 3: DetNet Strict Path Option Format 541 Redundancy Option fields: 543 Option Type: 8-bit identifier of the type of option. Value TBD by 544 IANA; if the processing IPv6 node does not recognize the Option 545 Type it must discard the packet and send an ICMP Parameter 546 Problem, Code 2, message to the packet's Source Address (act =10); 547 the Option Data of that option cannot change en route to the 548 packet's final destination (chg=0). 550 Opt Data Len: 8-bit length of the option data, set to 2. 552 Strict Path ID: 16-bit identifier of the DetNet Path, taken from a 553 local namespace associated with the IPv6 source address of the 554 packet. 556 4.2.2. DetNet Loose Path Option 558 The DetNet Loose Path Option transports a Loose Path identifier which 559 is taken from a namespace indicated by the Origin Autonomous System 560 (AS). When the DetNet path is contained within a single AS, the 561 Origin Autonomous System field can be left to 0 indicating local AS. 562 The option may be placed either in an HbH or a DoH EH, but the 563 preferred method is a DOH that precedes an RH such as SRH. 565 The DetNet Loose Path Option is to be used to signal a path that may 566 be loose and may exceed the boundaries of a local domain; a portion 567 of the hops may traverse routers in the wider internet that will not 568 leverage the option and are expected to ignore it. For instance, the 569 path information may signal a specific topology in a multi-topology 570 network and is only important for nodes that participate to more than 571 one topology. 573 An intermediate router that supports the DetNet Loose Path Option but 574 is missing the necessary state to forward along the indicated path 575 must ignore the DetNet Loose Path Option, but it should raise a 576 management alert as this is an unexpected situation with a limited 577 chance that the packet may loop till TTL. 579 0 1 2 3 580 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Option Type | Opt Data Len | Origin Autonomous System | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Loose Path ID | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Figure 4: DetNet Loose Path Option Format 589 Redundancy Option fields: 591 Option Type: 8-bit identifier of the type of option. Value TBD by 592 IANA; if the processing IPv6 node does not recognize the Option 593 Type it MUST skip over this option and continue processing the 594 header (act =00); the Option Data of that option cannot change en 595 route to the packet's final destination (chg=0). 597 Opt Data Len: 8-bit length of the option data, set to 6. 599 Origin Autonomous System: 16-bit identifier of the Autonomous 600 Systems (AS) that originates the path. The value of 0 signals a 601 DetNet path that is constrained within the local AS or the local 602 administrative DetNet domain. 604 Loose Path ID: 32-bit identifier of the DetNet Path, taken from a 605 local namespace associated with the origin AS of the DetNet path. 607 4.3. RPL Packet Information 609 6TiSCH [6TiSCH-ARCH] and RAW [RAW-ARCH] signal a Track using a RPL 610 Option [RFC6553] with a RPLInstanceID used as TrackID. This 611 specification reuses the RPL option as a method to signal a DetNet 612 path. In that case, the Projected-Route 'P' flag [RPL-PDAO] MUST be 613 set to 1, and the O, R, F flags, as well as the Sender Rank field, 614 MUST be set to 0 by the originator, forwarded as-is, and ignored on 615 reception. 617 5. Encapsulation of DetNet Options 619 In this section, encapsulations of three DetNet Options are specified 620 separately in the scenarios of pure IPv6 and SRv6. 622 5.1. IPv6 Network 624 The DetNet Strict Path Option is intended to be placed in an IPv6 HbH 625 EH since it must be processed by every DetNet forwarding node along 626 the path. The DetNet Loose Path Option and the DetNet Redundancy 627 Information Option may also carried in an IPv6 HbH Option header the 628 case where the set of routers that need the information does not 629 match the destinations along a source route path; those options are 630 intended to be ignored by unaware intermediate routers. 632 In the specific case where path selection and PREOF are end-to-end 633 performed between DetNet edge nodes, Redundancy Information Option 634 can be alternatively placed in IPv6 Destination Option header. The 635 encapsulation options are shown in Figure 5 and Figure 6. 637 +-----------------------------------+ 638 | DetNet App-Flow | 639 | (original IP) Packet | 640 +-----------------------------------+ 641 | other EHs | 642 +-----------------------------------+ <--\ 643 | IPv6 Hop-by-Hop Ex Hdr | | 644 | (DetNet RI Option) | DetNet Options 645 | (DetNet Strict/Loose Path Option) | | 646 +-----------------------------------+ <--/ 647 | IPv6 Header | 648 +-----------------------------------+ 649 | Data-Link | 650 +-----------------------------------+ 651 | Physical | 652 +-----------------------------------+ 654 Figure 5: DetNet IPv6 Option Encapsulation Alternative 1 656 +-----------------------------------+ 657 | DetNet App-Flow | 658 | (original IP) Packet | 659 +-----------------------------------+ 660 | other EHs such as RH | 661 +-----------------------------------+ <--\ 662 | IPv6 Destination Ext Hdr | | 663 | (DetNet RI Option) | | 664 +-----------------------------------+ DetNet Options 665 | IPv6 Hop-by-Hop Ext Hdr | | 666 | (DetNet Strict/Loose Path Option) | | 667 +-----------------------------------+ <--/ 668 | IPv6 Header | 669 +-----------------------------------+ 670 | Data-Link | 671 +-----------------------------------+ 672 | Physical | 673 +-----------------------------------+ 675 Figure 6: DetNet IPv6 Option Encapsulation Alternative 2 677 5.2. Segment Routing over IPv6 Network 679 In SRv6, partial or all of DetNet forwarding and relay nodes may be 680 represented by SRv6 SIDs to determine a specific path for a DetNet 681 flow. In the former case, DetNet Strict Path Option would be placed 682 in an HbH EH to be read by every DetNet forwarding node, and 683 intercepted should it strays away from its path. In the latter case, 684 three DetNet Options can be placed either in an HbH EH or in a DOH EH 685 before an SRH, as two encapsulation options are being functionally 686 equivalent, as shown in Figure 7 . 688 +-----------------------------------+ 689 | DetNet App-Flow | 690 | (original IP) Packet | 691 +-----------------------------------+ 692 | Segment Routing Header | 693 +-----------------------------------+ <--\ 694 | IPv6 Hop-by-Hop Ex Hdr | | 695 | (DetNet RI Option) | DetNet Options 696 | (DetNet Strict/Loose Path Option) | | 697 +-----------------------------------+ <--/ 698 | IPv6 Header | 699 +-----------------------------------+ 700 | Data-Link | 701 +-----------------------------------+ 702 | Physical | 703 +-----------------------------------+ 705 Figure 7: DetNet IPv6 Option Encapsulation in SRv6 Alternative 1 707 In the case where the SRv6 SRH signals the exhaustive list of the 708 Detnet relays along the path, it is recommended to place the DetNet 709 Redundancy Information Option in a DOH EH before the SRH, so that it 710 is processed by every relay node therein without burdening the 711 intermediate DetNet forwarding nodes, as illustrated in Figure 8 and 712 Figure 9. 714 If all the nodes that process the loose path information are also 715 listed in the SRH, then the DetNet Loose Path Option may also be 716 placed in the DOH, as shown in Figure 8 717 +-----------------------------------+ 718 | DetNet App-Flow | 719 | (original IP) Packet | 720 +-----------------------------------+ 721 | Segment Routing Header | 722 +-----------------------------------+ <--\ 723 | IPv6 Destination Ex Hdr | | 724 | (DetNet RI Option) | DetNet Options 725 | (DetNet Loose Path Option) | | 726 +-----------------------------------+ <--/ 727 | IPv6 Header | 728 +-----------------------------------+ 729 | Data-Link | 730 +-----------------------------------+ 731 | Physical | 732 +-----------------------------------+ 734 Figure 8: DetNet IPv6 Option Encapsulation in SRv6 Alternative 2 736 Unless the SRH is a strict routing header indicating all the hops on 737 the path, the DetNet Strict Path Option must remain separate in a HbH 738 EH, to be observed by all routers on path, as shown in Figure 9 740 +-----------------------------------+ 741 | DetNet App-Flow | 742 | (original IP) Packet | 743 +-----------------------------------+ 744 | Segment Routing Header | 745 +-----------------------------------+ <--\ 746 | IPv6 Destination Ex Hdr | | 747 | (DetNet RI Option) | | 748 +-----------------------------------+ DetNet Options 749 | IPv6 Hop-by-Hop Ex Hdr | | 750 | (DetNet Strict Path Option) | | 751 +-----------------------------------+ <--/ 752 | IPv6 Header | 753 +-----------------------------------+ 754 | Data-Link | 755 +-----------------------------------+ 756 | Physical | 757 +-----------------------------------+ 759 Figure 9: DetNet IPv6 Option Encapsulation in SRv6 Alternative 3 761 6. Security Considerations 763 7. IANA Considerations 764 7.1. New Subregistry for the Redundancy Type 766 This specification creates a new Subregistry for the "Redundancy Type 767 of the Redundancy Option" under the "Internet Protocol Version 6 768 (IPv6) Parameters" registry [IPV6-PARMS]. 770 * Possible values are 8-bit unsigned integers (0..255). 772 * Registration procedure is "IETF Review" [RFC8126]. 774 * Initial allocation is as Suggested in Table 2: 776 +-----------------+--------------------------------+-----------+ 777 | Suggested Value | Meaning | Reference | 778 +-----------------+--------------------------------+-----------+ 779 | 1 | Basic Sequence Counter | THIS RFC | 780 +-----------------+--------------------------------+-----------+ 781 | 2 | Zero-avoiding Sequence Counter | THIS RFC | 782 +-----------------+--------------------------------+-----------+ 783 | 3 | RPL Sequence Counter | THIS RFC | 784 +-----------------+--------------------------------+-----------+ 785 | 11 | Fractional NTP time stamp | THIS RFC | 786 +-----------------+--------------------------------+-----------+ 787 | 12 | Short NTP time stamp | THIS RFC | 788 +-----------------+--------------------------------+-----------+ 789 | 13 | PTP time stamp | THIS RFC | 790 +-----------------+--------------------------------+-----------+ 791 | 14 | Short PTP time stamp | THIS RFC | 792 +-----------------+--------------------------------+-----------+ 793 | 24 | TSN Redundancy Tag | THIS RFC | 794 +-----------------+--------------------------------+-----------+ 796 Table 2: Redundancy Information Type values 798 7.2. New Hop-by-Hop Options 800 This specification updates the "Destination Options and Hop-by-Hop 801 Options" under the "Internet Protocol Version 6 (IPv6) Parameters" 802 registry [IPV6-PARMS] with the (suggested) values below: 804 +------+-----+-----+-------+--------------------+-----------+ 805 | Hexa | act | chg | rest | Description | Reference | 806 +------+-----+-----+-------+--------------------+-----------+ 807 | 0x12 | 00 | 0 | 10010 | DetNet Redundancy | THIS RFC | 808 | | | | | Information Option | | 809 +------+-----+-----+-------+--------------------+-----------+ 810 | 0x93 | 10 | 0 | 10011 | DetNet Strict Path | THIS RFC | 811 | | | | | Option | | 812 +------+-----+-----+-------+--------------------+-----------+ 813 | 0x14 | 00 | 0 | 10100 | DetNet Loose Path | THIS RFC | 814 | | | | | Option | | 815 +------+-----+-----+-------+--------------------+-----------+ 817 Table 3: DetNet Hop-by-Hop Options 819 8. Acknowledgments 821 TBD 823 9. References 825 9.1. Normative References 827 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 828 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 829 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 830 Low-Power and Lossy Networks", RFC 6550, 831 DOI 10.17487/RFC6550, March 2012, 832 . 834 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 835 Power and Lossy Networks (RPL) Option for Carrying RPL 836 Information in Data-Plane Datagrams", RFC 6553, 837 DOI 10.17487/RFC6553, March 2012, 838 . 840 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 841 (IPv6) Specification", STD 86, RFC 8200, 842 DOI 10.17487/RFC8200, July 2017, 843 . 845 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 846 Writing an IANA Considerations Section in RFCs", BCP 26, 847 RFC 8126, DOI 10.17487/RFC8126, June 2017, 848 . 850 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 851 Defining Packet Timestamps", RFC 8877, 852 DOI 10.17487/RFC8877, September 2020, 853 . 855 [HbH-UPDT] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options 856 Processing Procedures", Work in Progress, Internet-Draft, 857 draft-hinden-6man-hbh-processing-01, 2 June 2021, 858 . 861 [DetNet-ARCH] 862 Finn, N., Thubert, P., Varga, B., and J. Farkas, 863 "Deterministic Networking Architecture", RFC 8655, 864 DOI 10.17487/RFC8655, October 2019, 865 . 867 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 868 Option Type, Routing Header for Source Routes, and IPv6- 869 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 870 DOI 10.17487/RFC9008, April 2021, 871 . 873 [6TiSCH-ARCH] 874 Thubert, P., Ed., "An Architecture for IPv6 over the Time- 875 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 876 RFC 9030, DOI 10.17487/RFC9030, May 2021, 877 . 879 [RAW-ARCH] Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable 880 and Available Wireless Architecture/Framework", Work in 881 Progress, Internet-Draft, draft-pthubert-raw-architecture- 882 09, 7 July 2021, . 885 9.2. Informative References 887 [I-D.varga-detnet-ip-preof] 888 Varga, B., Farkas, J., and A. G. Malis, "Deterministic 889 Networking (DetNet): DetNet PREOF via MPLS over UDP/IP", 890 Work in Progress, Internet-Draft, draft-varga-detnet-ip- 891 preof-02, 1 February 2022, 892 . 895 [RPL-PDAO] Thubert, P. and R. A. Jadhav, "Root initiated routing 896 state in RPL", Work in Progress, Internet-Draft, draft- 897 ietf-roll-dao-projection-23, 13 January 2022, 898 . 901 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 902 Xiao, "Overview and Principles of Internet Traffic 903 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 904 . 906 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 907 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 908 Acronym in the IETF", BCP 161, RFC 6291, 909 DOI 10.17487/RFC6291, June 2011, 910 . 912 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 913 "Network Time Protocol Version 4: Protocol and Algorithms 914 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 915 . 917 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 918 Decraene, B., Litkowski, S., and R. Shakir, "Segment 919 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 920 July 2018, . 922 [DetNet-PBST] 923 Finn, N. and P. Thubert, "Deterministic Networking Problem 924 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 925 . 927 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 928 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 929 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 930 . 932 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 933 Bryant, "Deterministic Networking (DetNet) Data Plane 934 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 935 . 937 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 938 Bryant, "Deterministic Networking (DetNet) Data Plane: 939 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 940 . 942 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 943 S., and J. Korhonen, "Deterministic Networking (DetNet) 944 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 945 2021, . 947 [RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 948 Bryant, "Deterministic Networking (DetNet) Data Plane: 949 MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April 950 2021, . 952 [IEEE Std. 802.15.4] 953 IEEE standard for Information Technology, "IEEE Std. 954 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 955 and Physical Layer (PHY) Specifications for Low-Rate 956 Wireless Personal Area Networks". 958 [IEEE 802.1 TSN] 959 IEEE 802.1, "Time-Sensitive Networking (TSN) Task Group", 960 . 962 [IEEE Std. 1588] 963 IEEE, "IEEE Standard for a Precision Clock Synchronization 964 Protocol for Networked Measurement and Control Systems", 965 IEEE Standard 1588, 966 . 968 [IPV6-PARMS] 969 IANA, "Internet Protocol Version 6 (IPv6) Parameters", 970 . 973 Authors' Addresses 975 Pascal Thubert (editor) 976 Cisco Systems, Inc 977 France 978 Phone: +33 497 23 26 34 979 Email: pthubert@cisco.com 981 Fan Yang 982 Huawei Technologies 983 China 984 Email: shirley.yangfan@huawei.com