idnits 2.17.1 draft-pthubert-detnet-ipv6-hbh-03.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 188: '...e representation MUST be large enough ...' RFC 2119 keyword, line 200: '...rigin node that builds the option MUST...' RFC 2119 keyword, line 222: '...n of the counter MUST be large enough ...' RFC 2119 keyword, line 244: '... Type it MUST skip over this opti...' RFC 2119 keyword, line 252: '...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 (11 June 2021) is 1049 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 == Outdated reference: A later version (-01) exists of draft-hinden-6man-hbh-processing-00 ** Downref: Normative reference to an Informational RFC: RFC 9030 (ref. '6TiSCH-ARCH') == Outdated reference: A later version (-09) exists of draft-pthubert-raw-architecture-05 ** 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-16 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 4 errors (**), 0 flaws (~~), 4 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 11 June 2021 5 Expires: 13 December 2021 7 IPv6 Hop-by-Hop Options for DetNet 8 draft-pthubert-detnet-ipv6-hbh-03 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 Hop-by-Hop options that signal that path and redundancy 20 information to the intermediate DetNet relays. 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 December 2021. 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. The DetNet Options . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. DetNet Redundancy Information Option . . . . . . . . . . 4 59 3.2. DetNet Path Options . . . . . . . . . . . . . . . . . . . 8 60 3.2.1. DetNet Strict Path Option . . . . . . . . . . . . . . 8 61 3.2.2. DetNet Loose Path Option . . . . . . . . . . . . . . 9 62 3.3. RPL Packet Information . . . . . . . . . . . . . . . . . 10 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. New Subregistry for the Redundancy Type . . . . . . . . . 10 66 5.2. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . 11 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 70 7.2. Informative References . . . . . . . . . . . . . . . . . 13 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 Section 2 of the Deterministic Networking Problem Statement 76 [DetNet-PBST] introduces the concept of Deterministic Networking 77 (DetNet) to the IETF. DetNet extends the reach of lower layer 78 technologies such as Time-Sensitive Networking (TSN) [IEEE 802.1 TSN] 79 and Timeslotted Channel Hopping (TSCH) [IEEE Std. 802.15.4] over IPv6 80 and MPLS [RFC8938]. 82 The "Deterministic Networking Architecture" [DetNet-ARCH] details the 83 contribution of layer-3 protocols, and defines three planes: the 84 Application (User) Plane, the Controller Plane, and the Network 85 Plane. [DetNet-ARCH] places an emphasis on the centralized model 86 whereby a controller instantiates per-flow state in the routers to 87 perform adequate forwading operations so as to provide end-to-end 88 reliability and bounded latency guarantees. 90 The "6TiSCH Architecture" [6TiSCH-ARCH] leverages RPL, the "Routing 91 Protocol for Low Power and Lossy Networks" [RPL] and introduces 92 concept of a Track as a highly redundant RPL Destination Oriented 93 Directed Acyclic Graph (DODAG) rooted at the Track Ingress node, that 94 can be installed using so-called projected routes [RPL-PDAO]. In 95 that case, the TrackId is an index from a namespace associated to one 96 IPv6 address of the Track Ingress node, and the Track that an IPv6 97 packet follows is signaled by the combination of the source address 98 (of the Track Ingress node), and the TrackID placed in a RPL Option 99 [RFC6553] located in an IPv6 Hop-by-Hop (HbH) Options Header [IPv6] 100 in the IPv6 packet. 102 The "Reliable and Available Wireless (RAW) Architecture/Framework" 103 [RAW-ARCH], extends the DetNet Network Plane to accomodate one or 104 multiple hops of homogeneous or heterogeneous wireless technologies, 105 e.g. a Wi-Fi6 Mesh or parallel radio access links combining Wi-Fi and 106 5G. The RAW Architecture reuses the concept of Track and introduces 107 a new dataplane component, the Path Selection Engine (PSE), to 108 dynamically select a subpath and maintain the required quality of 109 service within a Track in the face of the rapid evolution of the 110 medium properties. 112 With [IPv6], the behavior of a router upon an IPv6 packet with a HbH 113 Options Header has evolved, making the examination of the header by 114 routers along the path optional, as opposed to previously mandatory. 115 Additionally, the Option Type for any option in a HbH Options Header 116 encodes in the leftmost bits whether a router that inspects the 117 header should drop the packet or ignore the option when encountering 118 an unknown option. Combined, these capabilities enable a larger use 119 of the header beyond the boundaries of a limited domain, as 120 examplified by the change of behavior of the RPL data plane, that was 121 changed to allow a packet with a RPL option to escape the RPL domain 122 in the larger Internet [RFC9008]. 124 "IPv6 Hop-by-Hop Options Processing Procedures" [HbH-UPDT] further 125 specifies the procedures for how IPv6 Hop-by-Hop options are 126 processed to make their processing even more practical and increase 127 their use in the Internet. In that context, it makes sense to 128 consider Hop-by-Hop Options to transport the information that is 129 relevant to DetNet. 131 The "Deterministic Networking Data Plane Framework" [RFC8938] relies 132 on the 6-tuple to identify an IPv6 flow. But the full DetNet 133 operations require also the capabilities to signal meta-information 134 such as a sequence within that flow, and to transport different types 135 of packets along the same path with the same treatment. For 136 instance, it is required that Operations, Administration, and 137 Maintenance (OAM) [RFC6291] packets and/or multiple flows share the 138 same fate and resource sharing over the same Track or the same 139 Traffic Engineered (TE) [RFC3272] DetNet path. 141 This document introduces new IPv6 Hop-by-Hop options that signal 142 DetNet path and redundancy information to the intermediate relays in 143 an abstract form that is independent of the transport layer. 144 Transported in IPv6 HbH Options, the DetNet information is available 145 early in the header chain of the packet and can be added by a service 146 instance as part of the encapsulation by the Ingress of the DetNet 147 path. It can then be accessed by the intermediate DetNet routers 148 without the need of a deep packet inspection (e.g., beyond UDP). 150 2. Terminology 152 Timestamp semantics and timestamp formats used in this document are 153 defined in "Guidelines for Defining Packet Timestamps" [RFC8877]. 155 The Deterministic Networking terms used in this document are defined 156 in the "Deterministic Networking Architecture" [DetNet-ARCH]. 158 The terms Track and TrackID are defined in the "6TiSCH Architecture" 159 [6TiSCH-ARCH]. 161 3. The DetNet Options 163 This document defines new IPv6 options for DetNet to signal path and 164 a sequence to the DetNet layers. Those options are to be placed in 165 an IPv6 HbH Options Header. The format of the options follow the 166 generic definition in section 4.2 of [IPv6]. 168 If a DetNet Path option (see Section 3.2), including the RPL Option, 169 is present in the same HbH Option Header as a DetNet Redundancy 170 Information option (see Section 3.1), then the redundancy information 171 applies to the signaled path across all flows that traverse that 172 path; else the redundancy information applies to the flow indicated 173 by the 6-tuple [RFC8938]. 175 3.1. DetNet Redundancy Information Option 177 The DetNet Redundancy Information Option helps discriminate copies of 178 a same packet vs. different packets, and is useful for service- 179 sublayer Packet Replication Elimination and Ordering Functions 180 (PREOF). The typical expression redundancy information is a sequence 181 counter, but it is not the only way to identify a packet. It is also 182 possible that a packet is divided in elements such as network-coded 183 fragments. In that case, the pieces are discriminated with an opaque 184 8-bit fragment tag. 186 A packet sequence can be expressed uniquely as a wrapping counter, 187 represented as an unsigned integer in the option. In that case, the 188 size of the representation MUST be large enough to cover at least 3 189 times the upper bound on out-of-order packet delivery in terms of 190 number of packets. The sequence counter may be copied from a field 191 in another protocol, and it is possible that the value 0 is reserved 192 when wrapping, to the option offers both possibilities, wrapping to 193 either 0 or to 1. 195 This specification also allows to use a time stamp for the packet 196 redundancy information, in conformance with the recommendations in 197 [RFC8877]. This can be accomplished by utilizing the Precision Time 198 Protocol (PTP) format defined in IEEE Std. 1588 [IEEE Std. 1588] or 199 Network Time Protocol (NTP) [RFC5905] formats. In that case, the 200 timestamp resolution at the origin node that builds the option MUST 201 be fine enough to ensure that two consecutive packets are never 202 stamped with the same value. There is no requirement for this 203 particular stamping function that the sense of time at the origin 204 node is synchronized with the rest of the DetNet network. 206 IEEEE TSN [IEEE 802.1 TSN] defined a redundancy tag (R-Tag) for the 207 IEEE Std. 802.1CB Frame Replication and Elimination for Reliability 208 (FRER). The R-Tag is a structured field and its content is subject 209 to evolve; but the expectation for this specification is that the 210 overall size remains 48 bits and that the 48-bit value is different 211 for a large number of contiguous frames. When transporting TSN 212 frames in a DetNet packet, it is possible to leverage the R-Tag as 213 Redundancy information, though it cannot be assumed that the R-Tag is 214 sequentially incremented; so it can be used for packet duplicate 215 elimination but it is not suitable not for packet re-ordering. 217 This specification also allows for an hybrid model with a coarse 218 grained packet sequence within a coarse grained time stamp. In that 219 case, both a time stamp option and a wrapping counter options are 220 found, and the counter is used to compare packets with the same time 221 stamp and ignored otherwise In that case, the size of the 222 representation of the counter MUST be large enough to cover at least 223 3 times the number of packets that may be sent with the same value of 224 time stamp. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Option Type | Opt Data Len | R.I. Type | Fragment Tag | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 . . 233 . Redundancy Information (variable Size) . 234 . . 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 1: Redundancy Information Option Format 240 Redundancy Information Option fields: 242 Option Type: 8-bit identifier of the type of option. Value TBD by 243 IANA; if the processing IPv6 node does not recognize the Option 244 Type it MUST skip over this option and continue processing the 245 header (act =00); the Option Data of that option cannot change en 246 route to the packet's final destination (chg=0). The 248 Opt Data Len: 8-bit length of the option data. 250 Fragment Tag: 8-bit field, set to 0 when the packet is sent in 251 entirety; packets with the same Redundancy Information and 252 different fragments tags MUST be considered as different by the 253 elimination function and are not subject to ordering based on the 254 Tag. 256 Redundancy Information Type: 8-bit identifier of the type of 257 Redundancy information. Value to be confirmed by IANA. 259 +=======+============+===============+===========================+ 260 | Seq. | Category | Common Name | Redundancy | 261 | Type | | | Information Format | 262 | Value | | | | 263 +=======+============+===============+===========================+ 264 | 1 | Wrapping | Basic | 32-bit unsigned | 265 | | Counter | Sequence | integer | 266 | | | Counter | | 267 +-------+============+---------------+---------------------------+ 268 | 2 | Wrapping | Zero-avoiding | 32-bit unsigned | 269 | | Counter | Sequence | integer, wraps to 1 | 270 | | | Counter | | 271 +-------+============+---------------+---------------------------+ 272 | 3 | Wrapping | RPL Sequence | 8-bit RPL sequence, | 273 | | Counter | Counter | see section 7. of | 274 | | | | [RPL] | 275 +-------+============+---------------+---------------------------+ 276 | 11 | Time Stamp | Fractional | NTP 64-bit Timestamp | 277 | | | NTP | Format, see section | 278 | | | | 4.2.1. of [RFC8877] | 279 +-------+============+---------------+---------------------------+ 280 | 12 | Time Stamp | Short NTP | NTP 32-bit Timestamp | 281 | | | | Format, see section | 282 | | | | 4.2.2. of [RFC8877] | 283 +-------+============+---------------+---------------------------+ 284 | 13 | Time Stamp | PTP | PTP 80-bit Timestamp | 285 | | | | Format, see [IEEE | 286 | | | | Std. 1588] | 287 +-------+============+---------------+---------------------------+ 288 | 14 | Time Stamp | Short PTP | PTP 64-bit Truncated | 289 | | | | Timestamp Format, | 290 | | | | see section 4.3. of | 291 | | | | [RFC8877] | 292 +-------+============+---------------+---------------------------+ 293 | 24 | Structured | TSN | 48-bit opaque | 294 | | Unique Tag | Redundancy | | 295 | | | Tag | | 296 +-------+============+---------------+---------------------------+ 298 Table 1: Redundancy Information Type values (suggested) 300 Redundancy Information: Variable size, as indicated in Table 1. 302 3.2. DetNet Path Options 304 The DetNet Path Options carry path information that is independent 305 from the flows transported. When present, it is the information that 306 MUST be used to select the DetNet state at the DetNet forwarding 307 sublayer. 309 The path indicated therein is used by the service sublayer, as it is 310 the scope where the redundancy information is unique across a number 311 of packets large enough to ensure that a forwarding node never has to 312 handle different packets with the same redundancy information, though 313 the same value may be found for packets with a different path 314 information. 316 The typical DetNet path is is contained under a single administrative 317 control or within a closed group of administrative control; these 318 include campus-wide networks and private WANs [DetNet-ARCH]. The 319 typical expectation is that all nodes along a DetNet path are aware 320 of the path and actively maintain a forwarding state for it. The 321 DetNet Strict Path Option (see Section 3.2.1) is designed for that 322 environment; if a packet escapes the local domain, a router that does 323 not support the option will intercept it and return an error to the 324 source. 326 In other environments such as RAW, it might be that the service-layer 327 protection concentrates on just segments of the end-to-end path. In 328 that case, the service-sublayer protection may require the signaling 329 of both redundancy and path information, though the path information 330 is potentially not used by some intermediate routers. The path 331 information may also relate to segments are installed along the path 332 using a DetNet forwarding state as opposed to, say, SRv6. In either 333 case the DetNet Loose Path Option Section 3.2.2 can be used to signal 334 the path without incurring an ICMP Error from an intermediate node. 336 DetNet can also leverage the RPL Option that signals a Track in the 337 RPL Packet Information (RPI) [RFC6553]. There are 2 versions of the 338 RPL option, defined respectively in [RPL] with the act bits [IPv6] 339 set to dropped the packet when the option is unknown, that defined 340 in[RFC9008] which let the option be ignored. 342 3.2.1. DetNet Strict Path Option 344 In complement to the RPL option, this specification defines a 345 protocol-independent Strict Path Identifier, which is also taken from 346 a namespace indicated by the IPv6 source address of the packet. 348 The DetNet Strict Path Option is to be used in a limited domain and 349 all routers along the path are expected to support the option. 351 An intermediate router that supports the DetNet Strict Path Option 352 but is missing the necessary state to forward along the indicated 353 path must drop the packet and return an ICMP error.code 0 pointing at 354 the offset of the Strict Path ID in the DetNet Strict Path Option. 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Option Type | Opt Data Len | Strict Path ID | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 2: DetNet Strict Path Option Format 364 Redundancy Option fields: 366 Option Type: 8-bit identifier of the type of option. Value TBD by 367 IANA; if the processing IPv6 node does not recognize the Option 368 Type it must discard the packet and send an ICMP Parameter 369 Problem, Code 2, message to the packet's Source Address (act =10); 370 the Option Data of that option cannot change en route to the 371 packet's final destination (chg=0). 373 Opt Data Len: 8-bit length of the option data, set to 2. 375 Strict Path ID: 16-bit identifier of the DetNet Path, taken from a 376 local namespace associated with the IPv6 source address of the 377 packet. 379 3.2.2. DetNet Loose Path Option 381 The DetNet Loose Path Option transports a Loose Path identifier which 382 is taken from a namespace indicated by the Origin Autonomous System 383 (AS). When the DetNet path is contained within a single AS, the 384 Origin Autonomous System field can be left to 0 indicating local AS. 386 The DetNet Loose Path Option is to be used to signal a path that may 387 be loose and may exceed the boundaries of a local domain; a portion 388 of the hops may traverse routers in the wider internet that will not 389 leverage the option and are expected to ignore it. 391 An intermediate router that supports the DetNet Loose Path Option but 392 is missing the necessary state to forward along the indicated path 393 must ignore the DetNet Loose Path Option. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Option Type | Opt Data Len | Origin Autonomous System | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Loose Path ID | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 3: DetNet Loose Path Option Format 405 Redundancy Option fields: 407 Option Type: 8-bit identifier of the type of option. Value TBD by 408 IANA; if the processing IPv6 node does not recognize the Option 409 Type it MUST skip over this option and continue processing the 410 header (act =00); the Option Data of that option cannot change en 411 route to the packet's final destination (chg=0). 413 Opt Data Len: 8-bit length of the option data, set to 6. 415 Origin Autonomous System: 16-bit identifier of the Autonomous 416 Systems (AS) that originates the path. 418 Loose Path ID: 32-bit identifier of the DetNet Path, taken from a 419 local namespace associated with the origin AS of the DetNet path. 420 The value of 0 signals a DetNet path that is constrained within 421 the local AS or the local administrative DetNet domain. 423 3.3. RPL Packet Information 425 6TiSCH [6TiSCH-ARCH] and RAW [RAW-ARCH] signal a Track using a RPL 426 Option [RFC6553] with a RPLInstanceID used as TrackID. This 427 specification reuses the RPL option as a method to signal a DetNet 428 path. In that case, the Projected-Route 'P' flag [RPL-PDAO] MUST be 429 set to 1, and the O, R, F flags, as well as the Sender Rank field, 430 MUST be set to 0 by the originator, forwarded as-is, and ignored on 431 reception. 433 4. Security Considerations 435 5. IANA Considerations 437 5.1. New Subregistry for the Redundancy Type 439 This specification creates a new Subregistry for the "Redundancy Type 440 of the Redundancy Option" under the "Internet Protocol Version 6 441 (IPv6) Parameters" registry [IPV6-PARMS]. 443 * Possible values are 8-bit unsigned integers (0..255). 445 * Registration procedure is "IETF Review" [RFC8126]. 447 * Initial allocation is as Suggested in Table 2: 449 +-----------------+--------------------------------+-----------+ 450 | Suggested Value | Meaning | Reference | 451 +-----------------+--------------------------------+-----------+ 452 | 1 | Basic Sequence Counter | THIS RFC | 453 +-----------------+--------------------------------+-----------+ 454 | 2 | Zero-avoiding Sequence Counter | THIS RFC | 455 +-----------------+--------------------------------+-----------+ 456 | 3 | RPL Sequence Counter | THIS RFC | 457 +-----------------+--------------------------------+-----------+ 458 | 11 | Fractional NTP time stamp | THIS RFC | 459 +-----------------+--------------------------------+-----------+ 460 | 12 | Short NTP time stamp | THIS RFC | 461 +-----------------+--------------------------------+-----------+ 462 | 13 | PTP time stamp | THIS RFC | 463 +-----------------+--------------------------------+-----------+ 464 | 14 | Short PTP time stamp | THIS RFC | 465 +-----------------+--------------------------------+-----------+ 466 | 24 | TSN Redundancy Tag | THIS RFC | 467 +-----------------+--------------------------------+-----------+ 469 Table 2: Redundancy Information Type values 471 5.2. New Hop-by-Hop Options 473 This specification updates the "Destination Options and Hop-by-Hop 474 Options" under the "Internet Protocol Version 6 (IPv6) Parameters" 475 registry [IPV6-PARMS] with the (suggested) values below: 477 +------+-----+-----+-------+--------------------+-----------+ 478 | Hexa | act | chg | rest | Description | Reference | 479 +------+-----+-----+-------+--------------------+-----------+ 480 | 0x12 | 00 | 0 | 10010 | DetNet Redundancy | THIS RFC | 481 | | | | | Information Option | | 482 +------+-----+-----+-------+--------------------+-----------+ 483 | 0x93 | 10 | 0 | 10011 | DetNet Strict Path | THIS RFC | 484 | | | | | Option | | 485 +------+-----+-----+-------+--------------------+-----------+ 486 | 0x14 | 00 | 0 | 10100 | DetNet Loose Path | THIS RFC | 487 | | | | | Option | | 488 +------+-----+-----+-------+--------------------+-----------+ 490 Table 3: DetNet Hop-by-Hop Options 492 6. Acknowledgments 494 TBD 496 7. References 498 7.1. Normative References 500 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 501 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 502 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 503 Low-Power and Lossy Networks", RFC 6550, 504 DOI 10.17487/RFC6550, March 2012, 505 . 507 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 508 Power and Lossy Networks (RPL) Option for Carrying RPL 509 Information in Data-Plane Datagrams", RFC 6553, 510 DOI 10.17487/RFC6553, March 2012, 511 . 513 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 514 (IPv6) Specification", STD 86, RFC 8200, 515 DOI 10.17487/RFC8200, July 2017, 516 . 518 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 519 Writing an IANA Considerations Section in RFCs", BCP 26, 520 RFC 8126, DOI 10.17487/RFC8126, June 2017, 521 . 523 [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 524 Defining Packet Timestamps", RFC 8877, 525 DOI 10.17487/RFC8877, September 2020, 526 . 528 [HbH-UPDT] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options 529 Processing Procedures", Work in Progress, Internet-Draft, 530 draft-hinden-6man-hbh-processing-00, 3 December 2020, 531 . 534 [DetNet-ARCH] 535 Finn, N., Thubert, P., Varga, B., and J. Farkas, 536 "Deterministic Networking Architecture", RFC 8655, 537 DOI 10.17487/RFC8655, October 2019, 538 . 540 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 541 Option Type, Routing Header for Source Routes, and IPv6- 542 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 543 DOI 10.17487/RFC9008, April 2021, 544 . 546 [6TiSCH-ARCH] 547 Thubert, P., Ed., "An Architecture for IPv6 over the Time- 548 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 549 RFC 9030, DOI 10.17487/RFC9030, May 2021, 550 . 552 [RAW-ARCH] Thubert, P., Papadopoulos, G. Z., and R. Buddenberg, 553 "Reliable and Available Wireless Architecture/Framework", 554 Work in Progress, Internet-Draft, draft-pthubert-raw- 555 architecture-05, 15 November 2020, 556 . 559 7.2. Informative References 561 [RPL-PDAO] Thubert, P., Jadhav, R. A., and M. Gillmore, "Root 562 initiated routing state in RPL", Work in Progress, 563 Internet-Draft, draft-ietf-roll-dao-projection-16, 15 564 January 2021, . 567 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 568 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 569 Acronym in the IETF", BCP 161, RFC 6291, 570 DOI 10.17487/RFC6291, June 2011, 571 . 573 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 574 "Network Time Protocol Version 4: Protocol and Algorithms 575 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 576 . 578 [DetNet-PBST] 579 Finn, N. and P. Thubert, "Deterministic Networking Problem 580 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 581 . 583 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 584 Xiao, "Overview and Principles of Internet Traffic 585 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 586 . 588 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 589 Bryant, "Deterministic Networking (DetNet) Data Plane 590 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 591 . 593 [IEEE Std. 802.15.4] 594 IEEE standard for Information Technology, "IEEE Std. 595 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 596 and Physical Layer (PHY) Specifications for Low-Rate 597 Wireless Personal Area Networks". 599 [IEEE 802.1 TSN] 600 IEEE 802.1, "Time-Sensitive Networking (TSN) Task Group", 601 . 603 [IEEE Std. 1588] 604 IEEE, "IEEE Standard for a Precision Clock Synchronization 605 Protocol for Networked Measurement and Control Systems", 606 IEEE Standard 1588, 607 . 609 [IPV6-PARMS] 610 IANA, "Internet Protocol Version 6 (IPv6) Parameters", 611 . 614 Author's Address 616 Pascal Thubert (editor) 617 Cisco Systems, Inc 618 France 620 Phone: +33 497 23 26 34 621 Email: pthubert@cisco.com