| Internet-Draft | DetNet HbH Options | June 2021 |
| Thubert | Expires 13 December 2021 | [Page] |
RFC 8938, the Deterministic Networking Data Plane Framework relies on the 6-tuple to identify an IPv6 flow. But the full DetNet operations require also the capabilities to signal meta-information such as a sequence within that flow, and to transport different types of packets along the same path with the same treatment, e.g., Operations, Administration, and Maintenance packets and/or multiple flows with fate and resource sharing. This document introduces new IPv6 Hop-by-Hop options that signal that path and redundancy information to the intermediate DetNet relays.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 December 2021.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Section 2 of the Deterministic Networking Problem Statement [DetNet-PBST] introduces the concept of Deterministic Networking (DetNet) to the IETF. DetNet extends the reach of lower layer technologies such as Time-Sensitive Networking (TSN) [IEEE 802.1 TSN] and Timeslotted Channel Hopping (TSCH) [IEEE Std. 802.15.4] over IPv6 and MPLS [RFC8938].¶
The "Deterministic Networking Architecture" [DetNet-ARCH] details the contribution of layer-3 protocols, and defines three planes: the Application (User) Plane, the Controller Plane, and the Network Plane. [DetNet-ARCH] places an emphasis on the centralized model whereby a controller instantiates per-flow state in the routers to perform adequate forwading operations so as to provide end-to-end reliability and bounded latency guarantees.¶
The "6TiSCH Architecture" [6TiSCH-ARCH] leverages RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] and introduces concept of a Track as a highly redundant RPL Destination Oriented Directed Acyclic Graph (DODAG) rooted at the Track Ingress node, that can be installed using so-called projected routes [RPL-PDAO]. In that case, the TrackId is an index from a namespace associated to one IPv6 address of the Track Ingress node, and the Track that an IPv6 packet follows is signaled by the combination of the source address (of the Track Ingress node), and the TrackID placed in a RPL Option [RFC6553] located in an IPv6 Hop-by-Hop (HbH) Options Header [IPv6] in the IPv6 packet.¶
The "Reliable and Available Wireless (RAW) Architecture/Framework" [RAW-ARCH], extends the DetNet Network Plane to accomodate one or multiple hops of homogeneous or heterogeneous wireless technologies, e.g. a Wi-Fi6 Mesh or parallel radio access links combining Wi-Fi and 5G. The RAW Architecture reuses the concept of Track and introduces a new dataplane component, the Path Selection Engine (PSE), to dynamically select a subpath and maintain the required quality of service within a Track in the face of the rapid evolution of the medium properties.¶
With [IPv6], the behavior of a router upon an IPv6 packet with a HbH Options Header has evolved, making the examination of the header by routers along the path optional, as opposed to previously mandatory. Additionally, the Option Type for any option in a HbH Options Header encodes in the leftmost bits whether a router that inspects the header should drop the packet or ignore the option when encountering an unknown option. Combined, these capabilities enable a larger use of the header beyond the boundaries of a limited domain, as examplified by the change of behavior of the RPL data plane, that was changed to allow a packet with a RPL option to escape the RPL domain in the larger Internet [RFC9008].¶
"IPv6 Hop-by-Hop Options Processing Procedures" [HbH-UPDT] further specifies the procedures for how IPv6 Hop-by-Hop options are processed to make their processing even more practical and increase their use in the Internet. In that context, it makes sense to consider Hop-by-Hop Options to transport the information that is relevant to DetNet.¶
The "Deterministic Networking Data Plane Framework" [RFC8938] relies on the 6-tuple to identify an IPv6 flow. But the full DetNet operations require also the capabilities to signal meta-information such as a sequence within that flow, and to transport different types of packets along the same path with the same treatment. For instance, it is required that Operations, Administration, and Maintenance (OAM) [RFC6291] packets and/or multiple flows share the same fate and resource sharing over the same Track or the same Traffic Engineered (TE) [RFC3272] DetNet path.¶
This document introduces new IPv6 Hop-by-Hop options that signal DetNet path and redundancy information to the intermediate relays in an abstract form that is independent of the transport layer. Transported in IPv6 HbH Options, the DetNet information is available early in the header chain of the packet and can be added by a service instance as part of the encapsulation by the Ingress of the DetNet path. It can then be accessed by the intermediate DetNet routers without the need of a deep packet inspection (e.g., beyond UDP).¶
Timestamp semantics and timestamp formats used in this document are defined in "Guidelines for Defining Packet Timestamps" [RFC8877].¶
The Deterministic Networking terms used in this document are defined in the "Deterministic Networking Architecture" [DetNet-ARCH].¶
The terms Track and TrackID are defined in the "6TiSCH Architecture" [6TiSCH-ARCH].¶
This document defines new IPv6 options for DetNet to signal path and a sequence to the DetNet layers. Those options are to be placed in an IPv6 HbH Options Header. The format of the options follow the generic definition in section 4.2 of [IPv6].¶
If a DetNet Path option (see Section 3.2), including the RPL Option, is present in the same HbH Option Header as a DetNet Redundancy Information option (see Section 3.1), then the redundancy information applies to the signaled path across all flows that traverse that path; else the redundancy information applies to the flow indicated by the 6-tuple [RFC8938].¶
The DetNet Redundancy Information Option helps discriminate copies of a same packet vs. different packets, and is useful for service-sublayer Packet Replication Elimination and Ordering Functions (PREOF). The typical expression redundancy information is a sequence counter, but it is not the only way to identify a packet. It is also possible that a packet is divided in elements such as network-coded fragments. In that case, the pieces are discriminated with an opaque 8-bit fragment tag.¶
A packet sequence can be expressed uniquely as a wrapping counter, represented as an unsigned integer in the option. In that case, the size of the representation MUST be large enough to cover at least 3 times the upper bound on out-of-order packet delivery in terms of number of packets. The sequence counter may be copied from a field in another protocol, and it is possible that the value 0 is reserved when wrapping, to the option offers both possibilities, wrapping to either 0 or to 1.¶
This specification also allows to use a time stamp for the packet redundancy information, in conformance with the recommendations in [RFC8877]. This can be accomplished by utilizing the Precision Time Protocol (PTP) format defined in IEEE Std. 1588 [IEEE Std. 1588] or Network Time Protocol (NTP) [RFC5905] formats. In that case, the timestamp resolution at the origin node that builds the option MUST be fine enough to ensure that two consecutive packets are never stamped with the same value. There is no requirement for this particular stamping function that the sense of time at the origin node is synchronized with the rest of the DetNet network.¶
IEEEE TSN [IEEE 802.1 TSN] defined a redundancy tag (R-Tag) for the IEEE Std. 802.1CB Frame Replication and Elimination for Reliability (FRER). The R-Tag is a structured field and its content is subject to evolve; but the expectation for this specification is that the overall size remains 48 bits and that the 48-bit value is different for a large number of contiguous frames. When transporting TSN frames in a DetNet packet, it is possible to leverage the R-Tag as Redundancy information, though it cannot be assumed that the R-Tag is sequentially incremented; so it can be used for packet duplicate elimination but it is not suitable not for packet re-ordering.¶
This specification also allows for an hybrid model with a coarse grained packet sequence within a coarse grained time stamp. In that case, both a time stamp option and a wrapping counter options are found, and the counter is used to compare packets with the same time stamp and ignored otherwise In that case, the size of the representation of the counter MUST be large enough to cover at least 3 times the number of packets that may be sent with the same value of time stamp.¶
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | R.I. Type | Fragment Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Redundancy Information (variable Size) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redundancy Information Option fields:¶
8-bit length of the option data.¶
8-bit field, set to 0 when the packet is sent in entirety; packets with the same Redundancy Information and different fragments tags MUST be considered as different by the elimination function and are not subject to ordering based on the Tag.¶
8-bit identifier of the type of Redundancy information. Value to be confirmed by IANA.¶
| Seq. Type Value | Category | Common Name | Redundancy Information Format |
|---|---|---|---|
| 1 | Wrapping Counter | Basic Sequence Counter | 32-bit unsigned integer |
| 2 | Wrapping Counter | Zero-avoiding Sequence Counter | 32-bit unsigned integer, wraps to 1 |
| 3 | Wrapping Counter | RPL Sequence Counter | 8-bit RPL sequence, see section 7. of [RPL] |
| 11 | Time Stamp | Fractional NTP | NTP 64-bit Timestamp Format, see section 4.2.1. of [RFC8877] |
| 12 | Time Stamp | Short NTP | NTP 32-bit Timestamp Format, see section 4.2.2. of [RFC8877] |
| 13 | Time Stamp | PTP | PTP 80-bit Timestamp Format, see [IEEE Std. 1588] |
| 14 | Time Stamp | Short PTP | PTP 64-bit Truncated Timestamp Format, see section 4.3. of [RFC8877] |
| 24 | Structured Unique Tag | TSN Redundancy Tag | 48-bit opaque |
The DetNet Path Options carry path information that is independent from the flows transported. When present, it is the information that MUST be used to select the DetNet state at the DetNet forwarding sublayer.¶
The path indicated therein is used by the service sublayer, as it is the scope where the redundancy information is unique across a number of packets large enough to ensure that a forwarding node never has to handle different packets with the same redundancy information, though the same value may be found for packets with a different path information.¶
The typical DetNet path is is contained under a single administrative control or within a closed group of administrative control; these include campus-wide networks and private WANs [DetNet-ARCH]. The typical expectation is that all nodes along a DetNet path are aware of the path and actively maintain a forwarding state for it. The DetNet Strict Path Option (see Section 3.2.1) is designed for that environment; if a packet escapes the local domain, a router that does not support the option will intercept it and return an error to the source.¶
In other environments such as RAW, it might be that the service-layer protection concentrates on just segments of the end-to-end path. In that case, the service-sublayer protection may require the signaling of both redundancy and path information, though the path information is potentially not used by some intermediate routers. The path information may also relate to segments are installed along the path using a DetNet forwarding state as opposed to, say, SRv6. In either case the DetNet Loose Path Option Section 3.2.2 can be used to signal the path without incurring an ICMP Error from an intermediate node.¶
DetNet can also leverage the RPL Option that signals a Track in the RPL Packet Information (RPI) [RFC6553]. There are 2 versions of the RPL option, defined respectively in [RPL] with the act bits [IPv6] set to dropped the packet when the option is unknown, that defined in[RFC9008] which let the option be ignored.¶
In complement to the RPL option, this specification defines a protocol-independent Strict Path Identifier, which is also taken from a namespace indicated by the IPv6 source address of the packet.¶
The DetNet Strict Path Option is to be used in a limited domain and all routers along the path are expected to support the option.¶
An intermediate router that supports the DetNet Strict Path Option but is missing the necessary state to forward along the indicated path must drop the packet and return an ICMP error.code 0 pointing at the offset of the Strict Path ID in the DetNet Strict Path Option.¶
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | Strict Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redundancy Option fields:¶
8-bit length of the option data, set to 2.¶
16-bit identifier of the DetNet Path, taken from a local namespace associated with the IPv6 source address of the packet.¶
The DetNet Loose Path Option transports a Loose Path identifier which is taken from a namespace indicated by the Origin Autonomous System (AS). When the DetNet path is contained within a single AS, the Origin Autonomous System field can be left to 0 indicating local AS.¶
The DetNet Loose Path Option is to be used to signal a path that may be loose and may exceed the boundaries of a local domain; a portion of the hops may traverse routers in the wider internet that will not leverage the option and are expected to ignore it.¶
An intermediate router that supports the DetNet Loose Path Option but is missing the necessary state to forward along the indicated path must ignore the DetNet Loose Path Option.¶
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | Origin Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loose Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redundancy Option fields:¶
8-bit length of the option data, set to 6.¶
16-bit identifier of the Autonomous Systems (AS) that originates the path.¶
32-bit identifier of the DetNet Path, taken from a local namespace associated with the origin AS of the DetNet path. The value of 0 signals a DetNet path that is constrained within the local AS or the local administrative DetNet domain.¶
6TiSCH [6TiSCH-ARCH] and RAW [RAW-ARCH] signal a Track using a RPL Option [RFC6553] with a RPLInstanceID used as TrackID. This specification reuses the RPL option as a method to signal a DetNet path. In that case, the Projected-Route 'P' flag [RPL-PDAO] MUST be set to 1, and the O, R, F flags, as well as the Sender Rank field, MUST be set to 0 by the originator, forwarded as-is, and ignored on reception.¶
This specification creates a new Subregistry for the "Redundancy Type of the Redundancy Option" under the "Internet Protocol Version 6 (IPv6) Parameters" registry [IPV6-PARMS].¶
| Suggested Value | Meaning | Reference |
| 1 | Basic Sequence Counter | THIS RFC |
| 2 | Zero-avoiding Sequence Counter | THIS RFC |
| 3 | RPL Sequence Counter | THIS RFC |
| 11 | Fractional NTP time stamp | THIS RFC |
| 12 | Short NTP time stamp | THIS RFC |
| 13 | PTP time stamp | THIS RFC |
| 14 | Short PTP time stamp | THIS RFC |
| 24 | TSN Redundancy Tag | THIS RFC |
This specification updates the "Destination Options and Hop-by-Hop Options" under the "Internet Protocol Version 6 (IPv6) Parameters" registry [IPV6-PARMS] with the (suggested) values below:¶
| Hexa | act | chg | rest | Description | Reference |
| 0x12 | 00 | 0 | 10010 | DetNet Redundancy Information Option | THIS RFC |
| 0x93 | 10 | 0 | 10011 | DetNet Strict Path Option | THIS RFC |
| 0x14 | 00 | 0 | 10100 | DetNet Loose Path Option | THIS RFC |
TBD¶