idnits 2.17.1 draft-pthubert-detnet-ipv6-hbh-05.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 290: '...e representation MUST be large enough ...' RFC 2119 keyword, line 302: '...rigin node that builds the option MUST...' RFC 2119 keyword, line 324: '...n of the counter MUST be large enough ...' RFC 2119 keyword, line 346: '... Type it MUST skip over this opti...' RFC 2119 keyword, line 354: '...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 (12 August 2021) is 988 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 (-34) exists of draft-ietf-roll-dao-projection-19 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 12 August 2021 5 Expires: 13 February 2022 7 IPv6 Options for DetNet 8 draft-pthubert-detnet-ipv6-hbh-05 10 Abstract 12 RFC 8938, the Deterministic Networking Data Plane Framework relies on 13 the 6-tuple to identify an IPv6 flow. But the full DetNet operations 14 require also the capabilities to signal meta-information such as a 15 sequence within that flow, and to transport different types of 16 packets along the same path with the same treatment, e.g., 17 Operations, Administration, and Maintenance packets and/or multiple 18 flows with fate and resource sharing. This document introduces new 19 IPv6 options that signal that path and redundancy information to the 20 intermediate DetNet relay and forwarding nodes. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 13 February 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. The DetNet Options . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. DetNet Redundancy Information Option . . . . . . . . . . 6 60 4.2. DetNet Path Options . . . . . . . . . . . . . . . . . . . 10 61 4.2.1. DetNet Strict Path Option . . . . . . . . . . . . . . 10 62 4.2.2. DetNet Loose Path Option . . . . . . . . . . . . . . 12 63 4.3. RPL Packet Information . . . . . . . . . . . . . . . . . 13 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. New Subregistry for the Redundancy Type . . . . . . . . . 13 67 6.2. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . 14 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 8.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 Section 2 of the Deterministic Networking Problem Statement 77 [DetNet-PBST] introduces the concept of Deterministic Networking 78 (DetNet) to the IETF. DetNet extends the reach of lower layer 79 technologies such as Time-Sensitive Networking (TSN) [IEEE 802.1 TSN] 80 and Timeslotted Channel Hopping (TSCH) [IEEE Std. 802.15.4] over IPv6 81 and MPLS [RFC8938], to provide bounded latency and reliability 82 guarantees over an end-to-end layer-3 nailed-down path. 84 The "Deterministic Networking Architecture" [DetNet-ARCH] details the 85 contribution of layer-3 protocols, and defines three planes: the 86 Application (User) Plane, the Controller Plane, and the Network 87 Plane. [DetNet-ARCH] places an emphasis on the centralized model 88 whereby a controller instantiates a DetNet state in the routers that 89 is located based on matching information in the packet. For IPv6 90 flows, this document proposes a layer-3 signaling to index that 91 state, using an IPv6 Extension Header (EH). 93 The "6TiSCH Architecture" [6TiSCH-ARCH] leverages RPL, the "Routing 94 Protocol for Low Power and Lossy Networks" [RPL] and introduces 95 concept of a Track as a highly redundant RPL Destination Oriented 96 Directed Acyclic Graph (DODAG) rooted at the Track Ingress. 98 A Track may for instance be installed using RPL route projection 99 [RPL-PDAO]. In that case, the TrackId is an index from a namespace 100 associated to one IPv6 address of the Track Ingress node, and the 101 Track that an IPv6 packet follows is signaled by the combination of 102 the source address (of the Track Ingress node), and the TrackID 103 placed in a RPL Option [RFC6553] located in an IPv6 Hop-by-Hop (HbH) 104 Options Header [IPv6] in the IPv6 packet. 106 The "Reliable and Available Wireless (RAW) Architecture/Framework" 107 [RAW-ARCH], extends the DetNet Network Plane to accomodate one or 108 multiple hops of homogeneous or heterogeneous wireless technologies, 109 e.g. a Wi-Fi6 Mesh or parallel radio access links combining Wi-Fi and 110 5G. The RAW Architecture reuses the concept of Track and introduces 111 a new dataplane component, the Path Selection Engine (PSE), to 112 dynamically select a subpath and maintain the required quality of 113 service within a Track in the face of the rapid evolution of the 114 medium properties. 116 With [IPv6], the behavior of a router upon an IPv6 packet with a HbH 117 Options Header has evolved, making the examination of the header by 118 routers along the path optional, as opposed to previously mandatory. 119 Additionally, the Option Type for any option in a HbH Options Header 120 encodes in the leftmost bits whether a router that inspects the 121 header should drop the packet or ignore the option when encountering 122 an unknown option. Combined, these capabilities enable a larger use 123 of the header beyond the boundaries of a limited domain, as 124 examplified by the change of behavior of the RPL data plane, that was 125 changed to allow a packet with a RPL option to escape the RPL domain 126 in the larger Internet [RFC9008]. 128 "IPv6 Hop-by-Hop Options Processing Procedures" [HbH-UPDT] further 129 specifies the procedures for how IPv6 Hop-by-Hop options are 130 processed to make their processing even more practical and increase 131 their use in the Internet. In that context, it makes sense to 132 consider Hop-by-Hop Options to transport the information that is 133 relevant to DetNet. 135 The "Deterministic Networking Data Plane Framework" [RFC8938] relies 136 on the 6-tuple to identify an IPv6 flow. But the full DetNet 137 operations require also the capabilities to signal meta-information 138 such as a sequence within that flow, and to transport different types 139 of packets along the same path with the same treatment. For 140 instance, it is required that Operations, Administration, and 141 Maintenance (OAM) [RFC6291] packets and/or multiple flows share the 142 same fate and resource sharing over the same Track or the same 143 Traffic Engineered (TE) [RFC3272] DetNet path. 145 As opposed to the HbH EH, the Destination Option Header (DOH) is only 146 read by the destination of the packet, which can be one at a time the 147 collection of nodes listed in a Routing Extension Header (RH) if the 148 DOH is placed before the RH. 150 This document introduces new IPv6 Options, the DetNet Redundancy 151 Information Option and the DetNet Path Options, that signal the 152 DetNet information to the intermediate DetNet nodes in an abstract 153 form, that is pure layer-3 and agnostic of the transport layer. The 154 options are placed in either a HbH EH or in a DOH, which happens when 155 the next node that needs to process the option is the IPv6 156 destination in the IPv6 header. 158 This pure layer-3 technique alines DetNet with the IPv6 architecture 159 and opens to the progress / extensions done elsewhere for IPv6; e.g., 160 if the DetNet path leverages Segment routing (SRv6) [RFC8402] for 161 some reason - there are plausible ones in RAW -, the Segment Routing 162 Header (SRH) [RFC8754] is inserted after the HbH and/or DOH by the PE 163 and both are readily accessible for the on-path routers without the 164 need of a deeper inspection of the packet (up to and beyond the 165 transport header). 167 For instance, the DetNet Redundancy Information Option may be placed 168 in a DOH EH before an SRH that signals the exhaustive list of the 169 Detnet relays along the path of the packet, so every relay can 170 process the redundancy information therein, while the DetNet Strict 171 Path Option would be placed in an HbH EH to be read by every DeNet 172 fowarding node, and intercepted should it strays away from its path. 174 2. Terminology 176 Timestamp semantics and timestamp formats used in this document are 177 defined in "Guidelines for Defining Packet Timestamps" [RFC8877]. 179 The Deterministic Networking terms used in this document are defined 180 in the "Deterministic Networking Architecture" [DetNet-ARCH]. 182 The terms Track and TrackID are defined in the "6TiSCH Architecture" 183 [6TiSCH-ARCH]. 185 3. Applicability 187 Transported in IPv6 HbH Options, the DetNet options are available 188 early in the header chain of the packet. A DetNet-aware end system 189 (see section 4.2 of [DetNet-ARCH]) may place the options in the 190 header chain when constructing the packet, in which case there is no 191 need of an encapsulation. 193 Alternatively, the source end system may signal the flow information 194 some other way, or it may lack the full DetNet awareness; in that 195 case the DetNet path endpoints are the provider Edge (PE) routers 196 (see Figure 1 reproducing figure 5 of [DetNet-ARCH]) and the Ingress 197 PE needs to encapsulate the packets to add the HbH options. 199 In Figure 1, the DetNet end systems may be f-aware and signal an IPv6 200 flow using the 6-tuple for the End-to-End service, but may not be 201 s-aware, and may not sequence the packets for Packet Replication, 202 Elimination, and Ordering Functions (PREOF), which operate at the 203 detNet Service Layer. In that case, the Ingress PE will encapsulate 204 the packets for this and possibly other flows to provide a common 205 DetNet Service with OAM and PREOF, across the DetNet-1 service 206 provider network, terminating the tunnel at the Egress PE router. 208 _ 209 / \ +----DetNet-UNI (U) / \ 210 /App\ | /App\ 211 /-----\ | /-----\ 212 | NIC | v ________ | NIC | 213 +--+--+ _____ / \ DetNet-UNI (U) --+ +--+--+ 214 | / \__/ \ | | 215 | / +----+ +----+ \_____ | | 216 | / | | | | \_______ | | 217 +------U PE +----+ P +----+ \ _ v | 218 | | | | | | | ___/ \ | 219 | +--+-+ +----+ | +----+ | / \_ | 220 \ | | | | | / \ | 221 \ | +----+ +--+-+ +--+PE |------ U-----+ 222 \ | | | | | | | | | \_ _/ 223 \ +---+ P +----+ P +--+ +----+ | \____/ 224 \___ | | | | / 225 \ +----+__ +----+ DetNet-1 DetNet-2 226 | \_____/ \___________/ | 227 | | 228 | | End-to-End Service | | | | 229 <-------------------------------------------------------------> 230 | | DetNet Service | | | | 231 | <------------------------------------------------> | 232 | | | | | | 234 Figure 1: Figure 5 of RFC 8655, Reproduced 236 4. The DetNet Options 238 This document defines new IPv6 options for DetNet to signal path and 239 a reliability information (e.g., sequencing) to the DetNet layers. 240 Those options are to be placed in the IPv6 HbH Options Header, which 241 is found right after the outer IPv6 header in the DetNet packet and 242 immediately reachable for the forwarding engine. The format of the 243 options follow the generic definition in section 4.2 of [IPv6]. For 244 each tyoe of option, the draft allows to express the information in 245 different fashions, depending on the use case, and possibly carrying 246 an information that plays the same role at another layer, in which 247 case the format of the information is opaque. 249 The reliability information may be inherited from another layer as 250 long as the value is guaranteed to be unique within a reasonable set 251 of sequential packet so all packets with the same value are 252 redundant. Timestamping can be used as an alternate sequencing 253 technique, that avoids maintaining per-path state at the path 254 ingress, which is feasible for nodes that maintain a very precise 255 sense of time (e.g., from GPS or PTP) for their DetNet operations. 256 As long as the time granularity is in the order of a few bytes 257 transmission, the system timestamp provides an absolute sense of 258 ordering over a very long period across all paths for which this node 259 is ingress, and thus within any of those. Alternatively, the draft 260 allows to combine a rough time stamp (e.g., from a system clock 261 synchronized by NTP) and a sequence counter that differntiates the 262 packets that are stamped within the timer resolution. 264 If a DetNet Path option (see Section 4.2), including the RPL Option, 265 is present in the same HbH Option Header as a DetNet Redundancy 266 Information option (see Section 4.1), then the redundancy information 267 applies to the signaled path across all flows that traverse that 268 path; else the redundancy information applies to the flow indicated 269 by the 6-tuple [RFC8938]. 271 4.1. DetNet Redundancy Information Option 273 The DetNet Redundancy Information Option helps discriminate copies of 274 a same packet vs. different packets, and is useful for service- 275 sublayer Packet Replication Elimination and Ordering Functions 276 (PREOF). The option may be placed either in an HbH or a DoH EH, 277 e.g., prior to a Segment Routing Header (SRH) [RFC8754] that lists 278 the DetNet relays. A sequence counter is probably the most typical 279 expression of the redundancy information, but it is not the only way 280 to identify a packet and/or enable reordering, e.g., a timestamp can 281 be seen as a large sequence counter with gaps. 283 It is also possible that a packet is divided in elements such as 284 network-coded fragments. In that case, the pieces are discriminated 285 with an opaque 8-bit fragment tag. The goal is to retain one copy of 286 each fragment but not reorder them. 288 A packet sequence can be expressed uniquely as a wrapping counter, 289 represented as an unsigned integer in the option. In that case, the 290 size of the representation MUST be large enough to cover at least 3 291 times the upper bound on out-of-order packet delivery in terms of 292 number of packets. The sequence counter may be copied from a field 293 in another protocol, and it is possible that the value 0 is reserved 294 when wrapping, to the option offers both possibilities, wrapping to 295 either 0 or to 1. 297 This specification also allows to use a time stamp for the packet 298 redundancy information, in conformance with the recommendations in 299 [RFC8877]. This can be accomplished by utilizing the Precision Time 300 Protocol (PTP) format defined in IEEE Std. 1588 [IEEE Std. 1588] or 301 Network Time Protocol (NTP) [RFC5905] formats. In that case, the 302 timestamp resolution at the origin node that builds the option MUST 303 be fine enough to ensure that two consecutive packets are never 304 stamped with the same value. There is no requirement for this 305 particular stamping function that the sense of time at the origin 306 node is synchronized with the rest of the DetNet network. 308 IEEEE TSN [IEEE 802.1 TSN] defined a redundancy tag (R-Tag) for the 309 IEEE Std. 802.1CB Frame Replication and Elimination for Reliability 310 (FRER). The R-Tag is a structured field and its content is subject 311 to evolve; but the expectation for this specification is that the 312 overall size remains 48 bits and that the 48-bit value is different 313 for a large number of contiguous frames. When transporting TSN 314 frames in a DetNet packet, it is possible to leverage the R-Tag as 315 Redundancy information, though it cannot be assumed that the R-Tag is 316 sequentially incremented; so it can be used for packet duplicate 317 elimination but it is not suitable not for packet re-ordering. 319 This specification also allows for an hybrid model with a coarse 320 grained packet sequence within a coarse grained time stamp. In that 321 case, both a time stamp option and a wrapping counter options are 322 found, and the counter is used to compare packets with the same time 323 stamp and ignored otherwise In that case, the size of the 324 representation of the counter MUST be large enough to cover at least 325 3 times the number of packets that may be sent with the same value of 326 time stamp. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Option Type | Opt Data Len | R.I. Type | Fragment Tag | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | | 334 . . 335 . Redundancy Information (variable Size) . 336 . . 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 2: Redundancy Information Option Format 342 Redundancy Information Option fields: 344 Option Type: 8-bit identifier of the type of option. Value TBD by 345 IANA; if the processing IPv6 node does not recognize the Option 346 Type it MUST skip over this option and continue processing the 347 header (act =00); the Option Data of that option cannot change en 348 route to the packet's final destination (chg=0). The 350 Opt Data Len: 8-bit length of the option data. 352 Fragment Tag: 8-bit field, set to 0 when the packet is sent in 353 entirety; packets with the same Redundancy Information and 354 different fragments tags MUST be considered as different by the 355 elimination function and are not subject to ordering based on the 356 Tag. 358 Redundancy Information Type: 8-bit identifier of the type of 359 Redundancy information. Value to be confirmed by IANA. 361 +=======+============+===============+===========================+ 362 | Seq. | Category | Common Name | Redundancy | 363 | Type | | | Information Format | 364 | Value | | | | 365 +=======+============+===============+===========================+ 366 | 1 | Wrapping | Basic | 32-bit unsigned | 367 | | Counter | Sequence | integer | 368 | | | Counter | | 369 +-------+============+---------------+---------------------------+ 370 | 2 | Wrapping | Zero-avoiding | 32-bit unsigned | 371 | | Counter | Sequence | integer, wraps to 1 | 372 | | | Counter | | 373 +-------+============+---------------+---------------------------+ 374 | 3 | Wrapping | RPL Sequence | 8-bit RPL sequence, | 375 | | Counter | Counter | see section 7. of | 376 | | | | [RPL] | 377 +-------+============+---------------+---------------------------+ 378 | 11 | Time Stamp | Fractional | NTP 64-bit Timestamp | 379 | | | NTP | Format, see section | 380 | | | | 4.2.1. of [RFC8877] | 381 +-------+============+---------------+---------------------------+ 382 | 12 | Time Stamp | Short NTP | NTP 32-bit Timestamp | 383 | | | | Format, see section | 384 | | | | 4.2.2. of [RFC8877] | 385 +-------+============+---------------+---------------------------+ 386 | 13 | Time Stamp | PTP | PTP 80-bit Timestamp | 387 | | | | Format, see [IEEE | 388 | | | | Std. 1588] | 389 +-------+============+---------------+---------------------------+ 390 | 14 | Time Stamp | Short PTP | PTP 64-bit Truncated | 391 | | | | Timestamp Format, | 392 | | | | see section 4.3. of | 393 | | | | [RFC8877] | 394 +-------+============+---------------+---------------------------+ 395 | 24 | Structured | TSN | 48-bit opaque | 396 | | Unique Tag | Redundancy | | 397 | | | Tag | | 398 +-------+============+---------------+---------------------------+ 400 Table 1: Redundancy Information Type values (suggested) 402 Redundancy Information: Variable size, as indicated in Table 1. 404 4.2. DetNet Path Options 406 The DetNet Architecture [DetNet-ARCH] assigns a DetNet flow "to 407 specific paths through a network", but is not specific on how the 408 path is then signaled in the packet. The DetNet Data Plane Framework 409 [RFC8938] relies on the 6-tuple to identify an IPv6 flow and 410 implicitely the path could be indexed by the flow identification. 411 But this requires to maintain one path per flow and makes it 412 difficult to assign other traffic such as OAM to the same path. 414 This draft provides aditional means to signal the path in which the 415 flow is placed separately from the flow indentification, and 416 independantly of the transport layer, so a path can be shared between 417 one or more flows and OAM packets across IP address families. All 418 the packets that are assigned to the same path are subject to the 419 same DetNet forwarding treatment. 421 the DetNet expectation is that a PCE sets up a state at the DetNet 422 forwarding sublayer to instruct each hop on how to process the DetNet 423 flows. The DetNet Path Options when present contains information 424 that MUST be used to select the DetNet state installed and if the 425 DetNet state does not exist then the packet cannot be forwarded. 427 4.2.1. DetNet Strict Path Option 429 In complement to the RPL option, this specification defines a 430 protocol-independent Strict Path Identifier, which is also taken from 431 a namespace indicated by the IPv6 source address of the packet. 433 The DetNet Strict Path Option is to be used in a limited domain and 434 all routers along the path are expected to support the option. The 435 option is placed in an HbH EH to be seen by all routers on path. The 436 path indicated therein may also be used by the service sublayer, to 437 signal the scope where the redundancy information is unique across a 438 number of packets large enough to ensure that a forwarding node never 439 has to handle different packets with the same redundancy information, 440 though the same value may be found for packets with a different path 441 information. 443 The typical DetNet path is typically contained under a single 444 administrative control or within a closed group of administrative 445 control; these include campus-wide networks and private WANs 446 [DetNet-ARCH]. The typical expectation is that all nodes along a 447 DetNet path are aware of the path and actively maintain a forwarding 448 state for it. The DetNet Strict Path Option (see Section 4.2.1) is 449 designed for that environment; if a packet escapes the local domain, 450 a router that does not support the option will intercept it and 451 return an error to the source. 453 In other environments such as RAW, it might be that the service-layer 454 protection concentrates on just segments of the end-to-end path. In 455 that case, the service-sublayer protection may require the signaling 456 of both redundancy and path information, though the path information 457 is potentially not used by some of the intermediate routers and may 458 not be used for forwarding at all. The path information may also 459 relate to segments that are installed along the path using a DetNet 460 forwarding state as opposed to, say, source routing. In either case 461 the DetNet Loose Path Option Section 4.2.2 can be used to signal the 462 path without incurring an ICMP Error from an intermediate node. 464 An intermediate router that supports the DetNet Strict Path Option 465 but is missing the necessary state to forward along the indicated 466 path must drop the packet and return an ICMP error.code 0 pointing at 467 the offset of the Strict Path ID in the DetNet Strict Path Option. 469 DetNet can also leverage the RPL Option that signals a Track in the 470 RPL Packet Information (RPI) [RFC6553]. There are 2 versions of the 471 RPL option, defined respectively in [RPL] with the act bits [IPv6] 472 set to dropped the packet when the option is unknown, that defined 473 in[RFC9008] which let the option be ignored. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Option Type | Opt Data Len | Strict Path ID | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Figure 3: DetNet Strict Path Option Format 483 Redundancy Option fields: 485 Option Type: 8-bit identifier of the type of option. Value TBD by 486 IANA; if the processing IPv6 node does not recognize the Option 487 Type it must discard the packet and send an ICMP Parameter 488 Problem, Code 2, message to the packet's Source Address (act =10); 489 the Option Data of that option cannot change en route to the 490 packet's final destination (chg=0). 492 Opt Data Len: 8-bit length of the option data, set to 2. 494 Strict Path ID: 16-bit identifier of the DetNet Path, taken from a 495 local namespace associated with the IPv6 source address of the 496 packet. 498 4.2.2. DetNet Loose Path Option 500 The DetNet Loose Path Option transports a Loose Path identifier which 501 is taken from a namespace indicated by the Origin Autonomous System 502 (AS). When the DetNet path is contained within a single AS, the 503 Origin Autonomous System field can be left to 0 indicating local AS. 504 The option may be placed either in an HbH or a DoH EH, but the 505 preferred method is a DOH that precedes an RH such as SRH. 507 The DetNet Loose Path Option is to be used to signal a path that may 508 be loose and may exceed the boundaries of a local domain; a portion 509 of the hops may traverse routers in the wider internet that will not 510 leverage the option and are expected to ignore it. 512 An intermediate router that supports the DetNet Loose Path Option but 513 is missing the necessary state to forward along the indicated path 514 must ignore the DetNet Loose Path Option. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Option Type | Opt Data Len | Origin Autonomous System | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Loose Path ID | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 4: DetNet Loose Path Option Format 526 Redundancy Option fields: 528 Option Type: 8-bit identifier of the type of option. Value TBD by 529 IANA; if the processing IPv6 node does not recognize the Option 530 Type it MUST skip over this option and continue processing the 531 header (act =00); the Option Data of that option cannot change en 532 route to the packet's final destination (chg=0). 534 Opt Data Len: 8-bit length of the option data, set to 6. 536 Origin Autonomous System: 16-bit identifier of the Autonomous 537 Systems (AS) that originates the path. The value of 0 signals a 538 DetNet path that is constrained within the local AS or the local 539 administrative DetNet domain. 541 Loose Path ID: 32-bit identifier of the DetNet Path, taken from a 542 local namespace associated with the origin AS of the DetNet path. 544 4.3. RPL Packet Information 546 6TiSCH [6TiSCH-ARCH] and RAW [RAW-ARCH] signal a Track using a RPL 547 Option [RFC6553] with a RPLInstanceID used as TrackID. This 548 specification reuses the RPL option as a method to signal a DetNet 549 path. In that case, the Projected-Route 'P' flag [RPL-PDAO] MUST be 550 set to 1, and the O, R, F flags, as well as the Sender Rank field, 551 MUST be set to 0 by the originator, forwarded as-is, and ignored on 552 reception. 554 5. Security Considerations 556 6. IANA Considerations 558 6.1. New Subregistry for the Redundancy Type 560 This specification creates a new Subregistry for the "Redundancy Type 561 of the Redundancy Option" under the "Internet Protocol Version 6 562 (IPv6) Parameters" registry [IPV6-PARMS]. 564 * Possible values are 8-bit unsigned integers (0..255). 566 * Registration procedure is "IETF Review" [RFC8126]. 568 * Initial allocation is as Suggested in Table 2: 570 +-----------------+--------------------------------+-----------+ 571 | Suggested Value | Meaning | Reference | 572 +-----------------+--------------------------------+-----------+ 573 | 1 | Basic Sequence Counter | THIS RFC | 574 +-----------------+--------------------------------+-----------+ 575 | 2 | Zero-avoiding Sequence Counter | THIS RFC | 576 +-----------------+--------------------------------+-----------+ 577 | 3 | RPL Sequence Counter | THIS RFC | 578 +-----------------+--------------------------------+-----------+ 579 | 11 | Fractional NTP time stamp | THIS RFC | 580 +-----------------+--------------------------------+-----------+ 581 | 12 | Short NTP time stamp | THIS RFC | 582 +-----------------+--------------------------------+-----------+ 583 | 13 | PTP time stamp | THIS RFC | 584 +-----------------+--------------------------------+-----------+ 585 | 14 | Short PTP time stamp | THIS RFC | 586 +-----------------+--------------------------------+-----------+ 587 | 24 | TSN Redundancy Tag | THIS RFC | 588 +-----------------+--------------------------------+-----------+ 590 Table 2: Redundancy Information Type values 592 6.2. New Hop-by-Hop Options 594 This specification updates the "Destination Options and Hop-by-Hop 595 Options" under the "Internet Protocol Version 6 (IPv6) Parameters" 596 registry [IPV6-PARMS] with the (suggested) values below: 598 +------+-----+-----+-------+--------------------+-----------+ 599 | Hexa | act | chg | rest | Description | Reference | 600 +------+-----+-----+-------+--------------------+-----------+ 601 | 0x12 | 00 | 0 | 10010 | DetNet Redundancy | THIS RFC | 602 | | | | | Information Option | | 603 +------+-----+-----+-------+--------------------+-----------+ 604 | 0x93 | 10 | 0 | 10011 | DetNet Strict Path | THIS RFC | 605 | | | | | Option | | 606 +------+-----+-----+-------+--------------------+-----------+ 607 | 0x14 | 00 | 0 | 10100 | DetNet Loose Path | THIS RFC | 608 | | | | | Option | | 609 +------+-----+-----+-------+--------------------+-----------+ 611 Table 3: DetNet Hop-by-Hop Options 613 7. Acknowledgments 615 TBD 617 8. References 619 8.1. Normative References 621 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 622 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 623 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 624 Low-Power and Lossy Networks", RFC 6550, 625 DOI 10.17487/RFC6550, March 2012, 626 . 628 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 629 Power and Lossy Networks (RPL) Option for Carrying RPL 630 Information in Data-Plane Datagrams", RFC 6553, 631 DOI 10.17487/RFC6553, March 2012, 632 . 634 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 635 (IPv6) Specification", STD 86, RFC 8200, 636 DOI 10.17487/RFC8200, July 2017, 637 . 639 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 640 Writing an IANA Considerations Section in RFCs", BCP 26, 641 RFC 8126, DOI 10.17487/RFC8126, June 2017, 642 . 644 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 645 Defining Packet Timestamps", RFC 8877, 646 DOI 10.17487/RFC8877, September 2020, 647 . 649 [HbH-UPDT] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options 650 Processing Procedures", Work in Progress, Internet-Draft, 651 draft-hinden-6man-hbh-processing-01, 2 June 2021, 652 . 655 [DetNet-ARCH] 656 Finn, N., Thubert, P., Varga, B., and J. Farkas, 657 "Deterministic Networking Architecture", RFC 8655, 658 DOI 10.17487/RFC8655, October 2019, 659 . 661 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 662 Option Type, Routing Header for Source Routes, and IPv6- 663 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 664 DOI 10.17487/RFC9008, April 2021, 665 . 667 [6TiSCH-ARCH] 668 Thubert, P., Ed., "An Architecture for IPv6 over the Time- 669 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 670 RFC 9030, DOI 10.17487/RFC9030, May 2021, 671 . 673 [RAW-ARCH] Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable 674 and Available Wireless Architecture/Framework", Work in 675 Progress, Internet-Draft, draft-pthubert-raw-architecture- 676 09, 7 July 2021, . 679 8.2. Informative References 681 [RPL-PDAO] Thubert, P., Jadhav, R. A., and M. Gillmore, "Root 682 initiated routing state in RPL", Work in Progress, 683 Internet-Draft, draft-ietf-roll-dao-projection-19, 27 July 684 2021, . 687 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 688 Xiao, "Overview and Principles of Internet Traffic 689 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 690 . 692 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 693 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 694 Acronym in the IETF", BCP 161, RFC 6291, 695 DOI 10.17487/RFC6291, June 2011, 696 . 698 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 699 "Network Time Protocol Version 4: Protocol and Algorithms 700 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 701 . 703 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 704 Decraene, B., Litkowski, S., and R. Shakir, "Segment 705 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 706 July 2018, . 708 [DetNet-PBST] 709 Finn, N. and P. Thubert, "Deterministic Networking Problem 710 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 711 . 713 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 714 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 715 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 716 . 718 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 719 Bryant, "Deterministic Networking (DetNet) Data Plane 720 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 721 . 723 [IEEE Std. 802.15.4] 724 IEEE standard for Information Technology, "IEEE Std. 725 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 726 and Physical Layer (PHY) Specifications for Low-Rate 727 Wireless Personal Area Networks". 729 [IEEE 802.1 TSN] 730 IEEE 802.1, "Time-Sensitive Networking (TSN) Task Group", 731 . 733 [IEEE Std. 1588] 734 IEEE, "IEEE Standard for a Precision Clock Synchronization 735 Protocol for Networked Measurement and Control Systems", 736 IEEE Standard 1588, 737 . 739 [IPV6-PARMS] 740 IANA, "Internet Protocol Version 6 (IPv6) Parameters", 741 . 744 Author's Address 746 Pascal Thubert (editor) 747 Cisco Systems, Inc 748 France 750 Phone: +33 497 23 26 34 751 Email: pthubert@cisco.com