idnits 2.17.00 (12 Aug 2021) /tmp/idnits54670/draft-pthubert-detnet-ipv6-hbh-06.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 299: '...e representation MUST be large enough ...' RFC 2119 keyword, line 311: '...rigin node that builds the option MUST...' RFC 2119 keyword, line 333: '...n of the counter MUST be large enough ...' RFC 2119 keyword, line 355: '... Type it MUST skip over this opti...' RFC 2119 keyword, line 363: '...t fragments tags MUST be considered as...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 August 2021) is 270 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-19 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 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: 25 February 2022 Huawei Technologies 6 24 August 2021 8 IPv6 Options for DetNet 9 draft-pthubert-detnet-ipv6-hbh-06 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 25 February 2022. 40 Copyright Notice 42 Copyright (c) 2021 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 Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. The DetNet Options . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. DetNet Redundancy Information Option . . . . . . . . . . 7 61 4.2. DetNet Path Options . . . . . . . . . . . . . . . . . . . 11 62 4.2.1. DetNet Strict Path Option . . . . . . . . . . . . . . 11 63 4.2.2. DetNet Loose Path Option . . . . . . . . . . . . . . 13 64 4.3. RPL Packet Information . . . . . . . . . . . . . . . . . 14 65 5. Encapsulation of DetNet Options . . . . . . . . . . . . . . . 14 66 5.1. IPv6 Network . . . . . . . . . . . . . . . . . . . . . . 14 67 5.2. Segment Routing over IPv6 Network . . . . . . . . . . . . 16 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 7.1. New Subregistry for the Redundancy Type . . . . . . . . . 18 71 7.2. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . 18 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 75 9.2. Informative References . . . . . . . . . . . . . . . . . 20 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 Transported in IPv6 HbH Options, the DetNet options are available 196 early in the header chain of the packet. A DetNet-aware end system 197 (see section 4.2 of [DetNet-ARCH]) may place the options in the 198 header chain when constructing the packet, in which case there is no 199 need of an encapsulation. 201 Alternatively, the source end system may signal the flow information 202 some other way, or it may lack the full DetNet awareness; in that 203 case the DetNet path endpoints are the provider Edge (PE) routers 204 (see Figure 1 reproducing figure 5 of [DetNet-ARCH]) and the Ingress 205 PE needs to encapsulate the packets to add the HbH options. 207 In Figure 1, the DetNet end systems may be f-aware and signal an IPv6 208 flow using the 6-tuple for the End-to-End service, but may not be 209 s-aware, and may not sequence the packets for Packet Replication, 210 Elimination, and Ordering Functions (PREOF), which operate at the 211 detNet Service Layer. In that case, the Ingress PE will encapsulate 212 the packets for this and possibly other flows to provide a common 213 DetNet Service with OAM and PREOF, across the DetNet-1 service 214 provider network, terminating the tunnel at the Egress PE router. 216 _ 217 / \ +----DetNet-UNI (U) / \ 218 /App\ | /App\ 219 /-----\ | /-----\ 220 | NIC | v ________ | NIC | 221 +--+--+ _____ / \ DetNet-UNI (U) --+ +--+--+ 222 | / \__/ \ | | 223 | / +----+ +----+ \_____ | | 224 | / | | | | \_______ | | 225 +------U PE +----+ P +----+ \ _ v | 226 | | | | | | | ___/ \ | 227 | +--+-+ +----+ | +----+ | / \_ | 228 \ | | | | | / \ | 229 \ | +----+ +--+-+ +--+PE |------ U-----+ 230 \ | | | | | | | | | \_ _/ 231 \ +---+ P +----+ P +--+ +----+ | \____/ 232 \___ | | | | / 233 \ +----+__ +----+ DetNet-1 DetNet-2 234 | \_____/ \___________/ | 235 | | 236 | | End-to-End Service | | | | 237 <-------------------------------------------------------------> 238 | | DetNet Service | | | | 239 | <------------------------------------------------> | 240 | | | | | | 242 Figure 1: Figure 5 of RFC 8655, Reproduced 244 4. The DetNet Options 246 This document defines new IPv6 options for DetNet to signal path and 247 a reliability information (e.g., sequencing) to the DetNet layers. 248 Those options are to be placed in the IPv6 HbH Options Header, which 249 is found right after the outer IPv6 header in the DetNet packet and 250 immediately reachable for the forwarding engine. The format of the 251 options follow the generic definition in section 4.2 of [IPv6]. For 252 each tyoe of option, the draft allows to express the information in 253 different fashions, depending on the use case, and possibly carrying 254 an information that plays the same role at another layer, in which 255 case the format of the information is opaque. 257 The reliability information may be inherited from another layer as 258 long as the value is guaranteed to be unique within a reasonable set 259 of sequential packet so all packets with the same value are 260 redundant. Timestamping can be used as an alternate sequencing 261 technique, that avoids maintaining per-path state at the path 262 ingress, which is feasible for nodes that maintain a very precise 263 sense of time (e.g., from GPS or PTP) for their DetNet operations. 265 As long as the time granularity is in the order of a few bytes 266 transmission, the system timestamp provides an absolute sense of 267 ordering over a very long period across all paths for which this node 268 is ingress, and thus within any of those. Alternatively, the draft 269 allows to combine a rough time stamp (e.g., from a system clock 270 synchronized by NTP) and a sequence counter that differntiates the 271 packets that are stamped within the timer resolution. 273 If a DetNet Path option (see Section 4.2), including the RPL Option, 274 is present in the same HbH Option Header as a DetNet Redundancy 275 Information option (see Section 4.1), then the redundancy information 276 applies to the signaled path across all flows that traverse that 277 path; else the redundancy information applies to the flow indicated 278 by the 6-tuple [RFC8938]. 280 4.1. DetNet Redundancy Information Option 282 The DetNet Redundancy Information Option helps discriminate copies of 283 a same packet vs. different packets, and is useful for service- 284 sublayer Packet Replication Elimination and Ordering Functions 285 (PREOF). The option may be placed either in an HbH or a DoH EH, 286 e.g., prior to a Segment Routing Header (SRH) [RFC8754] that lists 287 the DetNet relays. A sequence counter is probably the most typical 288 expression of the redundancy information, but it is not the only way 289 to identify a packet and/or enable reordering, e.g., a timestamp can 290 be seen as a large sequence counter with gaps. 292 It is also possible that a packet is divided in elements such as 293 network-coded fragments. In that case, the pieces are discriminated 294 with an opaque 8-bit fragment tag. The goal is to retain one copy of 295 each fragment but not reorder them. 297 A packet sequence can be expressed uniquely as a wrapping counter, 298 represented as an unsigned integer in the option. In that case, the 299 size of the representation MUST be large enough to cover at least 3 300 times the upper bound on out-of-order packet delivery in terms of 301 number of packets. The sequence counter may be copied from a field 302 in another protocol, and it is possible that the value 0 is reserved 303 when wrapping, to the option offers both possibilities, wrapping to 304 either 0 or to 1. 306 This specification also allows to use a time stamp for the packet 307 redundancy information, in conformance with the recommendations in 308 [RFC8877]. This can be accomplished by utilizing the Precision Time 309 Protocol (PTP) format defined in IEEE Std. 1588 [IEEE Std. 1588] or 310 Network Time Protocol (NTP) [RFC5905] formats. In that case, the 311 timestamp resolution at the origin node that builds the option MUST 312 be fine enough to ensure that two consecutive packets are never 313 stamped with the same value. There is no requirement for this 314 particular stamping function that the sense of time at the origin 315 node is synchronized with the rest of the DetNet network. 317 IEEEE TSN [IEEE 802.1 TSN] defined a redundancy tag (R-Tag) for the 318 IEEE Std. 802.1CB Frame Replication and Elimination for Reliability 319 (FRER). The R-Tag is a structured field and its content is subject 320 to evolve; but the expectation for this specification is that the 321 overall size remains 48 bits and that the 48-bit value is different 322 for a large number of contiguous frames. When transporting TSN 323 frames in a DetNet packet, it is possible to leverage the R-Tag as 324 Redundancy information, though it cannot be assumed that the R-Tag is 325 sequentially incremented; so it can be used for packet duplicate 326 elimination but it is not suitable not for packet re-ordering. 328 This specification also allows for an hybrid model with a coarse 329 grained packet sequence within a coarse grained time stamp. In that 330 case, both a time stamp option and a wrapping counter options are 331 found, and the counter is used to compare packets with the same time 332 stamp and ignored otherwise In that case, the size of the 333 representation of the counter MUST be large enough to cover at least 334 3 times the number of packets that may be sent with the same value of 335 time stamp. 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Option Type | Opt Data Len | R.I. Type | Fragment Tag | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 . . 344 . Redundancy Information (variable Size) . 345 . . 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 2: Redundancy Information Option Format 351 Redundancy Information Option fields: 353 Option Type: 8-bit identifier of the type of option. Value TBD by 354 IANA; if the processing IPv6 node does not recognize the Option 355 Type it MUST skip over this option and continue processing the 356 header (act =00); the Option Data of that option cannot change en 357 route to the packet's final destination (chg=0). The 359 Opt Data Len: 8-bit length of the option data. 361 Fragment Tag: 8-bit field, set to 0 when the packet is sent in 362 entirety; packets with the same Redundancy Information and 363 different fragments tags MUST be considered as different by the 364 elimination function and are not subject to ordering based on the 365 Tag. 367 Redundancy Information Type: 8-bit identifier of the type of 368 Redundancy information. Value to be confirmed by IANA. 370 +=======+============+===============+===========================+ 371 | Seq. | Category | Common Name | Redundancy | 372 | Type | | | Information Format | 373 | Value | | | | 374 +=======+============+===============+===========================+ 375 | 1 | Wrapping | Basic | 32-bit unsigned | 376 | | Counter | Sequence | integer | 377 | | | Counter | | 378 +-------+============+---------------+---------------------------+ 379 | 2 | Wrapping | Zero-avoiding | 32-bit unsigned | 380 | | Counter | Sequence | integer, wraps to 1 | 381 | | | Counter | | 382 +-------+============+---------------+---------------------------+ 383 | 3 | Wrapping | RPL Sequence | 8-bit RPL sequence, | 384 | | Counter | Counter | see section 7. of | 385 | | | | [RPL] | 386 +-------+============+---------------+---------------------------+ 387 | 11 | Time Stamp | Fractional | NTP 64-bit Timestamp | 388 | | | NTP | Format, see section | 389 | | | | 4.2.1. of [RFC8877] | 390 +-------+============+---------------+---------------------------+ 391 | 12 | Time Stamp | Short NTP | NTP 32-bit Timestamp | 392 | | | | Format, see section | 393 | | | | 4.2.2. of [RFC8877] | 394 +-------+============+---------------+---------------------------+ 395 | 13 | Time Stamp | PTP | PTP 80-bit Timestamp | 396 | | | | Format, see [IEEE | 397 | | | | Std. 1588] | 398 +-------+============+---------------+---------------------------+ 399 | 14 | Time Stamp | Short PTP | PTP 64-bit Truncated | 400 | | | | Timestamp Format, | 401 | | | | see section 4.3. of | 402 | | | | [RFC8877] | 403 +-------+============+---------------+---------------------------+ 404 | 24 | Structured | TSN | 48-bit opaque | 405 | | Unique Tag | Redundancy | | 406 | | | Tag | | 407 +-------+============+---------------+---------------------------+ 409 Table 1: Redundancy Information Type values (suggested) 411 Redundancy Information: Variable size, as indicated in Table 1. 413 4.2. DetNet Path Options 415 The DetNet Architecture [DetNet-ARCH] assigns a DetNet flow "to 416 specific paths through a network", but is not specific on how the 417 path is then signaled in the packet. The DetNet Data Plane Framework 418 [RFC8938] relies on the 6-tuple to identify an IPv6 flow and 419 implicitely the path could be indexed by the flow identification. 420 But this requires to maintain one path per flow and makes it 421 difficult to assign other traffic such as OAM to the same path. 423 This draft provides aditional means to signal the path in which the 424 flow is placed separately from the flow indentification, and 425 independantly of the transport layer, so a path can be shared between 426 one or more flows and OAM packets across IP address families. All 427 the packets that are assigned to the same path are subject to the 428 same DetNet forwarding treatment. 430 the DetNet expectation is that a PCE sets up a state at the DetNet 431 forwarding sublayer to instruct each hop on how to process the DetNet 432 flows. The DetNet Path Options when present contains information 433 that MUST be used to select the DetNet state installed and if the 434 DetNet state does not exist then the packet cannot be forwarded. 436 4.2.1. DetNet Strict Path Option 438 In complement to the RPL option, this specification defines a 439 protocol-independent Strict Path Identifier, which is also taken from 440 a namespace indicated by the IPv6 source address of the packet. 442 The DetNet Strict Path Option is to be used in a limited domain to 443 indicate a routing state that must be present in all nodes to ensure 444 that the packet is routed along a strictly predefined path, for 445 instance pointing at a specific netxt hop with reserved resources for 446 buffers and bandwidth. For that reason all the routers along the 447 path are expected to support the option and own a state indexed by 448 the Strict Path ID indicated therein. 450 The option is placed in an HbH EH to be seen by all routers on path. 451 The path indicated therein may also be used by the service sublayer, 452 to signal the scope where the redundancy information is unique across 453 a number of packets large enough to ensure that a forwarding node 454 never has to handle different packets with the same redundancy 455 information, though the same value may be found for packets with a 456 different path information. 458 The typical DetNet path is typically contained under a single 459 administrative control or within a closed group of administrative 460 control; these include campus-wide networks and private WANs 462 [DetNet-ARCH]. The typical expectation is that all nodes along a 463 DetNet path are aware of the path and actively maintain a forwarding 464 state for it. The DetNet Strict Path Option (see Section 4.2.1) is 465 designed for that environment; if a packet escapes the local domain, 466 a router that does not support the option will intercept it and 467 return an error to the source. 469 In other environments such as RAW, it might be that the service-layer 470 protection concentrates on just segments of the end-to-end path. In 471 that case, the service-sublayer protection may require the signaling 472 of both redundancy and path information, though the path information 473 is potentially not used by some of the intermediate routers and may 474 not be used for forwarding at all. The path information may also 475 relate to segments that are installed along the path using a DetNet 476 forwarding state as opposed to, say, source routing. In either case 477 the DetNet Loose Path Option Section 4.2.2 can be used to signal the 478 path without incurring an ICMP Error from an intermediate node. 480 An intermediate router that supports the DetNet Strict Path Option 481 but is missing the necessary state to forward along the indicated 482 path must drop the packet and return an ICMP error.code 0 pointing at 483 the offset of the Strict Path ID in the DetNet Strict Path Option. 485 DetNet can also leverage the RPL Option that signals a Track in the 486 RPL Packet Information (RPI) [RFC6553]. There are 2 versions of the 487 RPL option, defined respectively in [RPL] with the act bits [IPv6] 488 set to dropped the packet when the option is unknown, that defined 489 in[RFC9008] which let the option be ignored. 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Option Type | Opt Data Len | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 3: DetNet Strict Path Option Format 499 Redundancy Option fields: 501 Option Type: 8-bit identifier of the type of option. Value TBD by 502 IANA; if the processing IPv6 node does not recognize the Option 503 Type it must discard the packet and send an ICMP Parameter 504 Problem, Code 2, message to the packet's Source Address (act =10); 505 the Option Data of that option cannot change en route to the 506 packet's final destination (chg=0). 508 Opt Data Len: 8-bit length of the option data, set to 2. 510 Strict Path ID: 16-bit identifier of the DetNet Path, taken from a 511 local namespace associated with the IPv6 source address of the 512 packet. 514 4.2.2. DetNet Loose Path Option 516 The DetNet Loose Path Option transports a Loose Path identifier which 517 is taken from a namespace indicated by the Origin Autonomous System 518 (AS). When the DetNet path is contained within a single AS, the 519 Origin Autonomous System field can be left to 0 indicating local AS. 520 The option may be placed either in an HbH or a DoH EH, but the 521 preferred method is a DOH that precedes an RH such as SRH. 523 The DetNet Loose Path Option is to be used to signal a path that may 524 be loose and may exceed the boundaries of a local domain; a portion 525 of the hops may traverse routers in the wider internet that will not 526 leverage the option and are expected to ignore it. For instance, the 527 path information may signal a specific topology in a multi-topology 528 network and is only important for nodes that participate to more than 529 one topology. 531 An intermediate router that supports the DetNet Loose Path Option but 532 is missing the necessary state to forward along the indicated path 533 must ignore the DetNet Loose Path Option, but it should raise a 534 management alert as this is an unexpected situation with a limited 535 chance that the packet may loop till TTL. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Option Type | Opt Data Len | Origin Autonomous System | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Loose Path ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Figure 4: DetNet Loose Path Option Format 547 Redundancy Option fields: 549 Option Type: 8-bit identifier of the type of option. Value TBD by 550 IANA; if the processing IPv6 node does not recognize the Option 551 Type it MUST skip over this option and continue processing the 552 header (act =00); the Option Data of that option cannot change en 553 route to the packet's final destination (chg=0). 555 Opt Data Len: 8-bit length of the option data, set to 6. 557 Origin Autonomous System: 16-bit identifier of the Autonomous 558 Systems (AS) that originates the path. The value of 0 signals a 559 DetNet path that is constrained within the local AS or the local 560 administrative DetNet domain. 562 Loose Path ID: 32-bit identifier of the DetNet Path, taken from a 563 local namespace associated with the origin AS of the DetNet path. 565 4.3. RPL Packet Information 567 6TiSCH [6TiSCH-ARCH] and RAW [RAW-ARCH] signal a Track using a RPL 568 Option [RFC6553] with a RPLInstanceID used as TrackID. This 569 specification reuses the RPL option as a method to signal a DetNet 570 path. In that case, the Projected-Route 'P' flag [RPL-PDAO] MUST be 571 set to 1, and the O, R, F flags, as well as the Sender Rank field, 572 MUST be set to 0 by the originator, forwarded as-is, and ignored on 573 reception. 575 5. Encapsulation of DetNet Options 577 In this section, encapsulations of three DetNet Options are specified 578 separately in the scenarios of pure IPv6 and SRv6. 580 5.1. IPv6 Network 582 The DetNet Strict Path Option are intended to be placed in an IPv6 583 HbH option header since they are used on every DetNet forwarding and 584 relay nodes along the path. The DetNet Loose Path Option and the 585 DetNet Redundancy Information Option may also carried in an IPv6 HbH 586 Option header the case where the set of routers that need the 587 information does not match the destinations along a source route 588 path; those options are intended to be ignored by unaware 589 intermediate routers. 591 In the specific case where path selection and PREOF are end-to-end 592 performed between DetNet edge nodes, Redundancy Information Option 593 can be alternatively placed in IPv6 Destination Option header. The 594 encapsulation options are shown in Figure 5 and Figure 6. 596 +-----------------------------------+ 597 | DetNet App-Flow | 598 | (original IP) Packet | 599 +-----------------------------------+ 600 | other EHs | 601 +-----------------------------------+ <--\ 602 | IPv6 Hop-by-Hop Ex Hdr | | 603 | (DetNet RI Option) | DetNet Options 604 | (DetNet Strict/Loose Path Option) | | 605 +-----------------------------------+ <--/ 606 | IPv6 Header | 607 +-----------------------------------+ 608 | Data-Link | 609 +-----------------------------------+ 610 | Physical | 611 +-----------------------------------+ 613 Figure 5: DetNet IPv6 Option Encapsulation Alternative 1 615 +-----------------------------------+ 616 | DetNet App-Flow | 617 | (original IP) Packet | 618 +-----------------------------------+ 619 | other EHs such as RH | 620 +-----------------------------------+ <--\ 621 | IPv6 Destination Ext Hdr | | 622 | (DetNet RI Option) | | 623 +-----------------------------------+ DetNet Options 624 | IPv6 Hop-by-Hop Ext Hdr | | 625 | (DetNet Strict/Loose Path Option) | | 626 +-----------------------------------+ <--/ 627 | IPv6 Header | 628 +-----------------------------------+ 629 | Data-Link | 630 +-----------------------------------+ 631 | Physical | 632 +-----------------------------------+ 634 Figure 6: DetNet IPv6 Option Encapsulation Alternative 2 636 5.2. Segment Routing over IPv6 Network 638 In SRv6, partial or all of DetNet forwarding and relay nodes may be 639 represented by SRv6 SIDs to determine a specific path for a DetNet 640 flow. In the former case, DetNet Strict Path Option would be placed 641 in an HbH EH to be read by every DetNet forwarding node, and 642 intercepted should it strays away from its path. In the latter case, 643 three DetNet Options can be placed either in an HbH EH or in a DOH EH 644 before an SRH, as two encapsulation options are being functionally 645 equivalent, as shown in Figure 7 . 647 +-----------------------------------+ 648 | DetNet App-Flow | 649 | (original IP) Packet | 650 +-----------------------------------+ 651 | Segment Routing Header | 652 +-----------------------------------+ <--\ 653 | IPv6 Hop-by-Hop Ex Hdr | | 654 | (DetNet RI Option) | DetNet Options 655 | (DetNet Strict/Loose Path Option) | | 656 +-----------------------------------+ <--/ 657 | IPv6 Header | 658 +-----------------------------------+ 659 | Data-Link | 660 +-----------------------------------+ 661 | Physical | 662 +-----------------------------------+ 664 Figure 7: DetNet IPv6 Option Encapsulation in SRv6 Alternative 1 666 In the case where the SRv6 SRH signals the exhaustive list of the 667 Detnet relays along the path, it is recommended to place the DetNet 668 Redundancy Information Option in a DOH EH before the SRH, so that it 669 is processed by every relay node therein without burdening the 670 intermediate DetNet forwarding nodes, as illustrated in Figure 8 and 671 Figure 9. 673 If all the nodes that process the loose path information are also 674 listed in the SRH, then the DetNet Loose Path Option may also be 675 placed in the DOH, as shown in Figure 8 676 +-----------------------------------+ 677 | DetNet App-Flow | 678 | (original IP) Packet | 679 +-----------------------------------+ 680 | Segment Routing Header | 681 +-----------------------------------+ <--\ 682 | IPv6 Destination Ex Hdr | | 683 | (DetNet RI Option) | DetNet Options 684 | (DetNet Loose Path Option) | | 685 +-----------------------------------+ <--/ 686 | IPv6 Header | 687 +-----------------------------------+ 688 | Data-Link | 689 +-----------------------------------+ 690 | Physical | 691 +-----------------------------------+ 693 Figure 8: DetNet IPv6 Option Encapsulation in SRv6 Alternative 2 695 Unless the SRH is a strict routing header indicating all the hops on 696 the path, the DetNet Strict Path Option must remain separate in a HbH 697 EH, to be observed by all routers on path, as shown in Figure 9 699 +-----------------------------------+ 700 | DetNet App-Flow | 701 | (original IP) Packet | 702 +-----------------------------------+ 703 | Segment Routing Header | 704 +-----------------------------------+ <--\ 705 | IPv6 Destination Ex Hdr | | 706 | (DetNet RI Option) | | 707 +-----------------------------------+ DetNet Options 708 | IPv6 Hop-by-Hop Ex Hdr | | 709 | (DetNet Strict Path Option) | | 710 +-----------------------------------+ <--/ 711 | IPv6 Header | 712 +-----------------------------------+ 713 | Data-Link | 714 +-----------------------------------+ 715 | Physical | 716 +-----------------------------------+ 718 Figure 9: DetNet IPv6 Option Encapsulation in SRv6 Alternative 3 720 6. Security Considerations 722 7. IANA Considerations 723 7.1. New Subregistry for the Redundancy Type 725 This specification creates a new Subregistry for the "Redundancy Type 726 of the Redundancy Option" under the "Internet Protocol Version 6 727 (IPv6) Parameters" registry [IPV6-PARMS]. 729 * Possible values are 8-bit unsigned integers (0..255). 731 * Registration procedure is "IETF Review" [RFC8126]. 733 * Initial allocation is as Suggested in Table 2: 735 +-----------------+--------------------------------+-----------+ 736 | Suggested Value | Meaning | Reference | 737 +-----------------+--------------------------------+-----------+ 738 | 1 | Basic Sequence Counter | THIS RFC | 739 +-----------------+--------------------------------+-----------+ 740 | 2 | Zero-avoiding Sequence Counter | THIS RFC | 741 +-----------------+--------------------------------+-----------+ 742 | 3 | RPL Sequence Counter | THIS RFC | 743 +-----------------+--------------------------------+-----------+ 744 | 11 | Fractional NTP time stamp | THIS RFC | 745 +-----------------+--------------------------------+-----------+ 746 | 12 | Short NTP time stamp | THIS RFC | 747 +-----------------+--------------------------------+-----------+ 748 | 13 | PTP time stamp | THIS RFC | 749 +-----------------+--------------------------------+-----------+ 750 | 14 | Short PTP time stamp | THIS RFC | 751 +-----------------+--------------------------------+-----------+ 752 | 24 | TSN Redundancy Tag | THIS RFC | 753 +-----------------+--------------------------------+-----------+ 755 Table 2: Redundancy Information Type values 757 7.2. New Hop-by-Hop Options 759 This specification updates the "Destination Options and Hop-by-Hop 760 Options" under the "Internet Protocol Version 6 (IPv6) Parameters" 761 registry [IPV6-PARMS] with the (suggested) values below: 763 +------+-----+-----+-------+--------------------+-----------+ 764 | Hexa | act | chg | rest | Description | Reference | 765 +------+-----+-----+-------+--------------------+-----------+ 766 | 0x12 | 00 | 0 | 10010 | DetNet Redundancy | THIS RFC | 767 | | | | | Information Option | | 768 +------+-----+-----+-------+--------------------+-----------+ 769 | 0x93 | 10 | 0 | 10011 | DetNet Strict Path | THIS RFC | 770 | | | | | Option | | 771 +------+-----+-----+-------+--------------------+-----------+ 772 | 0x14 | 00 | 0 | 10100 | DetNet Loose Path | THIS RFC | 773 | | | | | Option | | 774 +------+-----+-----+-------+--------------------+-----------+ 776 Table 3: DetNet Hop-by-Hop Options 778 8. Acknowledgments 780 TBD 782 9. References 784 9.1. Normative References 786 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 787 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 788 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 789 Low-Power and Lossy Networks", RFC 6550, 790 DOI 10.17487/RFC6550, March 2012, 791 . 793 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 794 Power and Lossy Networks (RPL) Option for Carrying RPL 795 Information in Data-Plane Datagrams", RFC 6553, 796 DOI 10.17487/RFC6553, March 2012, 797 . 799 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 800 (IPv6) Specification", STD 86, RFC 8200, 801 DOI 10.17487/RFC8200, July 2017, 802 . 804 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 805 Writing an IANA Considerations Section in RFCs", BCP 26, 806 RFC 8126, DOI 10.17487/RFC8126, June 2017, 807 . 809 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 810 Defining Packet Timestamps", RFC 8877, 811 DOI 10.17487/RFC8877, September 2020, 812 . 814 [HbH-UPDT] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options 815 Processing Procedures", Work in Progress, Internet-Draft, 816 draft-hinden-6man-hbh-processing-01, 2 June 2021, 817 . 820 [DetNet-ARCH] 821 Finn, N., Thubert, P., Varga, B., and J. Farkas, 822 "Deterministic Networking Architecture", RFC 8655, 823 DOI 10.17487/RFC8655, October 2019, 824 . 826 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 827 Option Type, Routing Header for Source Routes, and IPv6- 828 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 829 DOI 10.17487/RFC9008, April 2021, 830 . 832 [6TiSCH-ARCH] 833 Thubert, P., Ed., "An Architecture for IPv6 over the Time- 834 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 835 RFC 9030, DOI 10.17487/RFC9030, May 2021, 836 . 838 [RAW-ARCH] Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable 839 and Available Wireless Architecture/Framework", Work in 840 Progress, Internet-Draft, draft-pthubert-raw-architecture- 841 09, 7 July 2021, . 844 9.2. Informative References 846 [RPL-PDAO] Thubert, P., Jadhav, R. A., and M. Gillmore, "Root 847 initiated routing state in RPL", Work in Progress, 848 Internet-Draft, draft-ietf-roll-dao-projection-19, 27 July 849 2021, . 852 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 853 Xiao, "Overview and Principles of Internet Traffic 854 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 855 . 857 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 858 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 859 Acronym in the IETF", BCP 161, RFC 6291, 860 DOI 10.17487/RFC6291, June 2011, 861 . 863 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 864 "Network Time Protocol Version 4: Protocol and Algorithms 865 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 866 . 868 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 869 Decraene, B., Litkowski, S., and R. Shakir, "Segment 870 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 871 July 2018, . 873 [DetNet-PBST] 874 Finn, N. and P. Thubert, "Deterministic Networking Problem 875 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 876 . 878 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 879 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 880 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 881 . 883 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 884 Bryant, "Deterministic Networking (DetNet) Data Plane 885 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 886 . 888 [IEEE Std. 802.15.4] 889 IEEE standard for Information Technology, "IEEE Std. 890 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 891 and Physical Layer (PHY) Specifications for Low-Rate 892 Wireless Personal Area Networks". 894 [IEEE 802.1 TSN] 895 IEEE 802.1, "Time-Sensitive Networking (TSN) Task Group", 896 . 898 [IEEE Std. 1588] 899 IEEE, "IEEE Standard for a Precision Clock Synchronization 900 Protocol for Networked Measurement and Control Systems", 901 IEEE Standard 1588, 902 . 904 [IPV6-PARMS] 905 IANA, "Internet Protocol Version 6 (IPv6) Parameters", 906 . 909 Authors' Addresses 911 Pascal Thubert (editor) 912 Cisco Systems, Inc 913 France 915 Phone: +33 497 23 26 34 916 Email: pthubert@cisco.com 918 Fan Yang 919 Huawei Technologies 920 China 922 Email: shirley.yangfan@huawei.com