< draft-pthubert-detnet-ipv6-hbh-05.txt   draft-pthubert-detnet-ipv6-hbh-06.txt >
DetNet P. Thubert, Ed. DetNet P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track 12 August 2021 Intended status: Standards Track F. Yang
Expires: 13 February 2022 Expires: 25 February 2022 Huawei Technologies
24 August 2021
IPv6 Options for DetNet IPv6 Options for DetNet
draft-pthubert-detnet-ipv6-hbh-05 draft-pthubert-detnet-ipv6-hbh-06
Abstract Abstract
RFC 8938, the Deterministic Networking Data Plane Framework relies on RFC 8938, the Deterministic Networking Data Plane Framework relies on
the 6-tuple to identify an IPv6 flow. But the full DetNet operations the 6-tuple to identify an IPv6 flow. But the full DetNet operations
require also the capabilities to signal meta-information such as a require also the capabilities to signal meta-information such as a
sequence within that flow, and to transport different types of sequence within that flow, and to transport different types of
packets along the same path with the same treatment, e.g., packets along the same path with the same treatment, e.g.,
Operations, Administration, and Maintenance packets and/or multiple Operations, Administration, and Maintenance packets and/or multiple
flows with fate and resource sharing. This document introduces new flows with fate and resource sharing. This document introduces new
skipping to change at page 1, line 38 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 February 2022. This Internet-Draft will expire on 25 February 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The DetNet Options . . . . . . . . . . . . . . . . . . . . . 6 4. The DetNet Options . . . . . . . . . . . . . . . . . . . . . 6
4.1. DetNet Redundancy Information Option . . . . . . . . . . 6 4.1. DetNet Redundancy Information Option . . . . . . . . . . 7
4.2. DetNet Path Options . . . . . . . . . . . . . . . . . . . 10 4.2. DetNet Path Options . . . . . . . . . . . . . . . . . . . 11
4.2.1. DetNet Strict Path Option . . . . . . . . . . . . . . 10 4.2.1. DetNet Strict Path Option . . . . . . . . . . . . . . 11
4.2.2. DetNet Loose Path Option . . . . . . . . . . . . . . 12 4.2.2. DetNet Loose Path Option . . . . . . . . . . . . . . 13
4.3. RPL Packet Information . . . . . . . . . . . . . . . . . 13 4.3. RPL Packet Information . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Encapsulation of DetNet Options . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.1. IPv6 Network . . . . . . . . . . . . . . . . . . . . . . 14
6.1. New Subregistry for the Redundancy Type . . . . . . . . . 13 5.2. Segment Routing over IPv6 Network . . . . . . . . . . . . 16
6.2. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. New Subregistry for the Redundancy Type . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Section 2 of the Deterministic Networking Problem Statement Section 2 of the Deterministic Networking Problem Statement
[DetNet-PBST] introduces the concept of Deterministic Networking [DetNet-PBST] introduces the concept of Deterministic Networking
(DetNet) to the IETF. DetNet extends the reach of lower layer (DetNet) to the IETF. DetNet extends the reach of lower layer
technologies such as Time-Sensitive Networking (TSN) [IEEE 802.1 TSN] technologies such as Time-Sensitive Networking (TSN) [IEEE 802.1 TSN]
and Timeslotted Channel Hopping (TSCH) [IEEE Std. 802.15.4] over IPv6 and Timeslotted Channel Hopping (TSCH) [IEEE Std. 802.15.4] over IPv6
and MPLS [RFC8938], to provide bounded latency and reliability and MPLS [RFC8938], to provide bounded latency and reliability
guarantees over an end-to-end layer-3 nailed-down path. guarantees over an end-to-end layer-3 nailed-down path.
The "Deterministic Networking Architecture" [DetNet-ARCH] details the The "Deterministic Networking Architecture" [DetNet-ARCH] details the
contribution of layer-3 protocols, and defines three planes: the contribution of layer-3 protocols, and defines three planes: the
Application (User) Plane, the Controller Plane, and the Network Application (User) Plane, the Controller Plane, and the Network
Plane. [DetNet-ARCH] places an emphasis on the centralized model Plane. [DetNet-ARCH] places an emphasis on the centralized model
whereby a controller instantiates a DetNet state in the routers that whereby a controller instantiates a DetNet state in the routers that
is located based on matching information in the packet. For IPv6 is located based on matching information in the packet.
flows, this document proposes a layer-3 signaling to index that
state, using an IPv6 Extension Header (EH). 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
proposes a layer-3 signaling that is independent of the upper layer
information, to locate the DetNet state and enable the same
forwarding nehavior for the data flows and the OAM packets.
The "6TiSCH Architecture" [6TiSCH-ARCH] leverages RPL, the "Routing The "6TiSCH Architecture" [6TiSCH-ARCH] leverages RPL, the "Routing
Protocol for Low Power and Lossy Networks" [RPL] and introduces Protocol for Low Power and Lossy Networks" [RPL] and introduces
concept of a Track as a highly redundant RPL Destination Oriented concept of a Track as a highly redundant RPL Destination Oriented
Directed Acyclic Graph (DODAG) rooted at the Track Ingress. Directed Acyclic Graph (DODAG) rooted at the Track Ingress. The
Track is indicative of a layer-3 forwarding behavior (e.g., next
hops)as opposed to indicative of the upper layer content, so it is
more in line with the DetNet needs than the 6-tuple.
A Track may for instance be installed using RPL route projection A Track may for instance be installed using RPL route projection
[RPL-PDAO]. In that case, the TrackId is an index from a namespace [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 associated to one IPv6 address of the Track Ingress node, and the
Track that an IPv6 packet follows is signaled by the combination of Track that an IPv6 packet follows is signaled by the combination of
the source address (of the Track Ingress node), and the TrackID 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) placed in a RPL Option [RFC6553] located in an IPv6 Hop-by-Hop (HbH)
Options Header [IPv6] in the IPv6 packet. Options Header [IPv6] in the IPv6 packet.
The "Reliable and Available Wireless (RAW) Architecture/Framework" The "Reliable and Available Wireless (RAW) Architecture/Framework"
skipping to change at page 3, line 42 skipping to change at page 4, line 24
changed to allow a packet with a RPL option to escape the RPL domain changed to allow a packet with a RPL option to escape the RPL domain
in the larger Internet [RFC9008]. in the larger Internet [RFC9008].
"IPv6 Hop-by-Hop Options Processing Procedures" [HbH-UPDT] further "IPv6 Hop-by-Hop Options Processing Procedures" [HbH-UPDT] further
specifies the procedures for how IPv6 Hop-by-Hop options are specifies the procedures for how IPv6 Hop-by-Hop options are
processed to make their processing even more practical and increase processed to make their processing even more practical and increase
their use in the Internet. In that context, it makes sense to their use in the Internet. In that context, it makes sense to
consider Hop-by-Hop Options to transport the information that is consider Hop-by-Hop Options to transport the information that is
relevant to DetNet. 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.
As opposed to the HbH EH, the Destination Option Header (DOH) is only As opposed to the HbH EH, the Destination Option Header (DOH) is only
read by the destination of the packet, which can be one at a time the read by the destination of the packet, which can be one at a time the
collection of nodes listed in a Routing Extension Header (RH) if the collection of nodes listed in a Routing Extension Header (RH) if the
DOH is placed before the RH. DOH is placed before the RH.
This document introduces new IPv6 Options, the DetNet Redundancy This document introduces new IPv6 Options, the DetNet Redundancy
Information Option and the DetNet Path Options, that signal the Information Option and the DetNet Path Options, that signal the
DetNet information to the intermediate DetNet nodes in an abstract DetNet information to the intermediate DetNet nodes in an abstract
form, that is pure layer-3 and agnostic of the transport layer. The form, that is pure layer-3 and agnostic of the transport layer. The
options are placed in either a HbH EH or in a DOH, which happens when options are placed in either a HbH EH or in a DOH, which happens when
skipping to change at page 4, line 28 skipping to change at page 4, line 47
This pure layer-3 technique alines DetNet with the IPv6 architecture This pure layer-3 technique alines DetNet with the IPv6 architecture
and opens to the progress / extensions done elsewhere for IPv6; e.g., and opens to the progress / extensions done elsewhere for IPv6; e.g.,
if the DetNet path leverages Segment routing (SRv6) [RFC8402] for if the DetNet path leverages Segment routing (SRv6) [RFC8402] for
some reason - there are plausible ones in RAW -, the Segment Routing some reason - there are plausible ones in RAW -, the Segment Routing
Header (SRH) [RFC8754] is inserted after the HbH and/or DOH by the PE Header (SRH) [RFC8754] is inserted after the HbH and/or DOH by the PE
and both are readily accessible for the on-path routers without the and both are readily accessible for the on-path routers without the
need of a deeper inspection of the packet (up to and beyond the need of a deeper inspection of the packet (up to and beyond the
transport header). transport header).
For instance, the DetNet Redundancy Information Option may be placed For instance, the DetNet Redundancy Information Option may be placed
in a DOH EH before an SRH that signals the exhaustive list of the in a DOH before an SRH that signals the exhaustive list of the DetNet
Detnet relays along the path of the packet, so every relay can relays along the path of the packet, so every relay can process the
process the redundancy information therein, while the DetNet Strict redundancy information therein, while the DetNet Strict Path Option
Path Option would be placed in an HbH EH to be read by every DeNet would be placed in an HbH EH to be read by every DetNet forwarding
fowarding node, and intercepted should it strays away from its path. node, and intercepted should it strays away from its path.
2. Terminology 2. Terminology
Timestamp semantics and timestamp formats used in this document are Timestamp semantics and timestamp formats used in this document are
defined in "Guidelines for Defining Packet Timestamps" [RFC8877]. defined in "Guidelines for Defining Packet Timestamps" [RFC8877].
The Deterministic Networking terms used in this document are defined The Deterministic Networking terms used in this document are defined
in the "Deterministic Networking Architecture" [DetNet-ARCH]. in the "Deterministic Networking Architecture" [DetNet-ARCH].
The terms Track and TrackID are defined in the "6TiSCH Architecture" The terms Track and TrackID are defined in the "6TiSCH Architecture"
skipping to change at page 10, line 34 skipping to change at page 11, line 34
flows. The DetNet Path Options when present contains information flows. The DetNet Path Options when present contains information
that MUST be used to select the DetNet state installed and if the that MUST be used to select the DetNet state installed and if the
DetNet state does not exist then the packet cannot be forwarded. DetNet state does not exist then the packet cannot be forwarded.
4.2.1. DetNet Strict Path Option 4.2.1. DetNet Strict Path Option
In complement to the RPL option, this specification defines a In complement to the RPL option, this specification defines a
protocol-independent Strict Path Identifier, which is also taken from protocol-independent Strict Path Identifier, which is also taken from
a namespace indicated by the IPv6 source address of the packet. 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 The DetNet Strict Path Option is to be used in a limited domain to
all routers along the path are expected to support the option. The indicate a routing state that must be present in all nodes to ensure
option is placed in an HbH EH to be seen by all routers on path. The that the packet is routed along a strictly predefined path, for
path indicated therein may also be used by the service sublayer, to instance pointing at a specific netxt hop with reserved resources for
signal the scope where the redundancy information is unique across a buffers and bandwidth. For that reason all the routers along the
number of packets large enough to ensure that a forwarding node never path are expected to support the option and own a state indexed by
has to handle different packets with the same redundancy information, the Strict Path ID indicated therein.
though the same value may be found for packets with a different path
information. The option is placed in an HbH EH to be seen by all routers on path.
The path indicated therein may also be used by the service sublayer,
to signal 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 typically contained under a single The typical DetNet path is typically contained under a single
administrative control or within a closed group of administrative administrative control or within a closed group of administrative
control; these include campus-wide networks and private WANs control; these include campus-wide networks and private WANs
[DetNet-ARCH]. The typical expectation is that all nodes along a [DetNet-ARCH]. The typical expectation is that all nodes along a
DetNet path are aware of the path and actively maintain a forwarding DetNet path are aware of the path and actively maintain a forwarding
state for it. The DetNet Strict Path Option (see Section 4.2.1) is state for it. The DetNet Strict Path Option (see Section 4.2.1) is
designed for that environment; if a packet escapes the local domain, designed for that environment; if a packet escapes the local domain,
a router that does not support the option will intercept it and a router that does not support the option will intercept it and
return an error to the source. return an error to the source.
In other environments such as RAW, it might be that the service-layer 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 protection concentrates on just segments of the end-to-end path. In
that case, the service-sublayer protection may require the signaling that case, the service-sublayer protection may require the signaling
skipping to change at page 11, line 27 skipping to change at page 12, line 34
but is missing the necessary state to forward along the indicated 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 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. the offset of the Strict Path ID in the DetNet Strict Path Option.
DetNet can also leverage the RPL Option that signals a Track in the 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 Packet Information (RPI) [RFC6553]. There are 2 versions of the
RPL option, defined respectively in [RPL] with the act bits [IPv6] RPL option, defined respectively in [RPL] with the act bits [IPv6]
set to dropped the packet when the option is unknown, that defined set to dropped the packet when the option is unknown, that defined
in[RFC9008] which let the option be ignored. in[RFC9008] which let the option be ignored.
0 1 2 3 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 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 | | Option Type | Opt Data Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DetNet Strict Path Option Format Figure 3: DetNet Strict Path Option Format
Redundancy Option fields: Redundancy Option fields:
Option Type: 8-bit identifier of the type of option. Value TBD by Option Type: 8-bit identifier of the type of option. Value TBD by
IANA; if the processing IPv6 node does not recognize the Option IANA; if the processing IPv6 node does not recognize the Option
Type it must discard the packet and send an ICMP Parameter Type it must discard the packet and send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address (act =10); Problem, Code 2, message to the packet's Source Address (act =10);
the Option Data of that option cannot change en route to the the Option Data of that option cannot change en route to the
skipping to change at page 12, line 17 skipping to change at page 13, line 21
The DetNet Loose Path Option transports a Loose Path identifier which The DetNet Loose Path Option transports a Loose Path identifier which
is taken from a namespace indicated by the Origin Autonomous System is taken from a namespace indicated by the Origin Autonomous System
(AS). When the DetNet path is contained within a single AS, the (AS). When the DetNet path is contained within a single AS, the
Origin Autonomous System field can be left to 0 indicating local AS. Origin Autonomous System field can be left to 0 indicating local AS.
The option may be placed either in an HbH or a DoH EH, but the The option may be placed either in an HbH or a DoH EH, but the
preferred method is a DOH that precedes an RH such as SRH. preferred method is a DOH that precedes an RH such as SRH.
The DetNet Loose Path Option is to be used to signal a path that may 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 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 of the hops may traverse routers in the wider internet that will not
leverage the option and are expected to ignore it. leverage the option and are expected to ignore it. For instance, the
path information may signal a specific topology in a multi-topology
network and is only important for nodes that participate to more than
one topology.
An intermediate router that supports the DetNet Loose Path Option but An intermediate router that supports the DetNet Loose Path Option but
is missing the necessary state to forward along the indicated path is missing the necessary state to forward along the indicated path
must ignore the DetNet Loose Path Option. must ignore the DetNet Loose Path Option, but it should raise a
management alert as this is an unexpected situation with a limited
chance that the packet may loop till TTL.
0 1 2 3 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 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 | | Option Type | Opt Data Len | Origin Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loose Path ID | | Loose Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DetNet Loose Path Option Format Figure 4: DetNet Loose Path Option Format
skipping to change at page 13, line 15 skipping to change at page 14, line 21
4.3. RPL Packet Information 4.3. RPL Packet Information
6TiSCH [6TiSCH-ARCH] and RAW [RAW-ARCH] signal a Track using a RPL 6TiSCH [6TiSCH-ARCH] and RAW [RAW-ARCH] signal a Track using a RPL
Option [RFC6553] with a RPLInstanceID used as TrackID. This Option [RFC6553] with a RPLInstanceID used as TrackID. This
specification reuses the RPL option as a method to signal a DetNet 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 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, 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 MUST be set to 0 by the originator, forwarded as-is, and ignored on
reception. reception.
5. Security Considerations 5. Encapsulation of DetNet Options
6. IANA Considerations In this section, encapsulations of three DetNet Options are specified
separately in the scenarios of pure IPv6 and SRv6.
6.1. New Subregistry for the Redundancy Type 5.1. IPv6 Network
The DetNet Strict Path Option are intended to be placed in an IPv6
HbH option header since they are used on every DetNet forwarding and
relay nodes along the path. The DetNet Loose Path Option and the
DetNet Redundancy Information Option may also carried in an IPv6 HbH
Option header the case where the set of routers that need the
information does not match the destinations along a source route
path; those options are intended to be ignored by unaware
intermediate routers.
In the specific case where path selection and PREOF are end-to-end
performed between DetNet edge nodes, Redundancy Information Option
can be alternatively placed in IPv6 Destination Option header. The
encapsulation options are shown in Figure 5 and Figure 6.
+-----------------------------------+
| DetNet App-Flow |
| (original IP) Packet |
+-----------------------------------+
| other EHs |
+-----------------------------------+ <--\
| IPv6 Hop-by-Hop Ex Hdr | |
| (DetNet RI Option) | DetNet Options
| (DetNet Strict/Loose Path Option) | |
+-----------------------------------+ <--/
| IPv6 Header |
+-----------------------------------+
| Data-Link |
+-----------------------------------+
| Physical |
+-----------------------------------+
Figure 5: DetNet IPv6 Option Encapsulation Alternative 1
+-----------------------------------+
| DetNet App-Flow |
| (original IP) Packet |
+-----------------------------------+
| other EHs such as RH |
+-----------------------------------+ <--\
| IPv6 Destination Ext Hdr | |
| (DetNet RI Option) | |
+-----------------------------------+ DetNet Options
| IPv6 Hop-by-Hop Ext Hdr | |
| (DetNet Strict/Loose Path Option) | |
+-----------------------------------+ <--/
| IPv6 Header |
+-----------------------------------+
| Data-Link |
+-----------------------------------+
| Physical |
+-----------------------------------+
Figure 6: DetNet IPv6 Option Encapsulation Alternative 2
5.2. Segment Routing over IPv6 Network
In SRv6, partial or all of DetNet forwarding and relay nodes may be
represented by SRv6 SIDs to determine a specific path for a DetNet
flow. In the former case, DetNet Strict Path Option would be placed
in an HbH EH to be read by every DetNet forwarding node, and
intercepted should it strays away from its path. In the latter case,
three DetNet Options can be placed either in an HbH EH or in a DOH EH
before an SRH, as two encapsulation options are being functionally
equivalent, as shown in Figure 7 .
+-----------------------------------+
| DetNet App-Flow |
| (original IP) Packet |
+-----------------------------------+
| Segment Routing Header |
+-----------------------------------+ <--\
| IPv6 Hop-by-Hop Ex Hdr | |
| (DetNet RI Option) | DetNet Options
| (DetNet Strict/Loose Path Option) | |
+-----------------------------------+ <--/
| IPv6 Header |
+-----------------------------------+
| Data-Link |
+-----------------------------------+
| Physical |
+-----------------------------------+
Figure 7: DetNet IPv6 Option Encapsulation in SRv6 Alternative 1
In the case where the SRv6 SRH signals the exhaustive list of the
Detnet relays along the path, it is recommended to place the DetNet
Redundancy Information Option in a DOH EH before the SRH, so that it
is processed by every relay node therein without burdening the
intermediate DetNet forwarding nodes, as illustrated in Figure 8 and
Figure 9.
If all the nodes that process the loose path information are also
listed in the SRH, then the DetNet Loose Path Option may also be
placed in the DOH, as shown in Figure 8
+-----------------------------------+
| DetNet App-Flow |
| (original IP) Packet |
+-----------------------------------+
| Segment Routing Header |
+-----------------------------------+ <--\
| IPv6 Destination Ex Hdr | |
| (DetNet RI Option) | DetNet Options
| (DetNet Loose Path Option) | |
+-----------------------------------+ <--/
| IPv6 Header |
+-----------------------------------+
| Data-Link |
+-----------------------------------+
| Physical |
+-----------------------------------+
Figure 8: DetNet IPv6 Option Encapsulation in SRv6 Alternative 2
Unless the SRH is a strict routing header indicating all the hops on
the path, the DetNet Strict Path Option must remain separate in a HbH
EH, to be observed by all routers on path, as shown in Figure 9
+-----------------------------------+
| DetNet App-Flow |
| (original IP) Packet |
+-----------------------------------+
| Segment Routing Header |
+-----------------------------------+ <--\
| IPv6 Destination Ex Hdr | |
| (DetNet RI Option) | |
+-----------------------------------+ DetNet Options
| IPv6 Hop-by-Hop Ex Hdr | |
| (DetNet Strict Path Option) | |
+-----------------------------------+ <--/
| IPv6 Header |
+-----------------------------------+
| Data-Link |
+-----------------------------------+
| Physical |
+-----------------------------------+
Figure 9: DetNet IPv6 Option Encapsulation in SRv6 Alternative 3
6. Security Considerations
7. IANA Considerations
7.1. New Subregistry for the Redundancy Type
This specification creates a new Subregistry for the "Redundancy Type This specification creates a new Subregistry for the "Redundancy Type
of the Redundancy Option" under the "Internet Protocol Version 6 of the Redundancy Option" under the "Internet Protocol Version 6
(IPv6) Parameters" registry [IPV6-PARMS]. (IPv6) Parameters" registry [IPV6-PARMS].
* Possible values are 8-bit unsigned integers (0..255). * Possible values are 8-bit unsigned integers (0..255).
* Registration procedure is "IETF Review" [RFC8126]. * Registration procedure is "IETF Review" [RFC8126].
* Initial allocation is as Suggested in Table 2: * Initial allocation is as Suggested in Table 2:
skipping to change at page 14, line 5 skipping to change at page 18, line 38
+-----------------+--------------------------------+-----------+ +-----------------+--------------------------------+-----------+
| 13 | PTP time stamp | THIS RFC | | 13 | PTP time stamp | THIS RFC |
+-----------------+--------------------------------+-----------+ +-----------------+--------------------------------+-----------+
| 14 | Short PTP time stamp | THIS RFC | | 14 | Short PTP time stamp | THIS RFC |
+-----------------+--------------------------------+-----------+ +-----------------+--------------------------------+-----------+
| 24 | TSN Redundancy Tag | THIS RFC | | 24 | TSN Redundancy Tag | THIS RFC |
+-----------------+--------------------------------+-----------+ +-----------------+--------------------------------+-----------+
Table 2: Redundancy Information Type values Table 2: Redundancy Information Type values
6.2. New Hop-by-Hop Options 7.2. New Hop-by-Hop Options
This specification updates the "Destination Options and Hop-by-Hop This specification updates the "Destination Options and Hop-by-Hop
Options" under the "Internet Protocol Version 6 (IPv6) Parameters" Options" under the "Internet Protocol Version 6 (IPv6) Parameters"
registry [IPV6-PARMS] with the (suggested) values below: registry [IPV6-PARMS] with the (suggested) values below:
+------+-----+-----+-------+--------------------+-----------+ +------+-----+-----+-------+--------------------+-----------+
| Hexa | act | chg | rest | Description | Reference | | Hexa | act | chg | rest | Description | Reference |
+------+-----+-----+-------+--------------------+-----------+ +------+-----+-----+-------+--------------------+-----------+
| 0x12 | 00 | 0 | 10010 | DetNet Redundancy | THIS RFC | | 0x12 | 00 | 0 | 10010 | DetNet Redundancy | THIS RFC |
| | | | | Information Option | | | | | | | Information Option | |
+------+-----+-----+-------+--------------------+-----------+ +------+-----+-----+-------+--------------------+-----------+
| 0x93 | 10 | 0 | 10011 | DetNet Strict Path | THIS RFC | | 0x93 | 10 | 0 | 10011 | DetNet Strict Path | THIS RFC |
| | | | | Option | | | | | | | Option | |
+------+-----+-----+-------+--------------------+-----------+ +------+-----+-----+-------+--------------------+-----------+
| 0x14 | 00 | 0 | 10100 | DetNet Loose Path | THIS RFC | | 0x14 | 00 | 0 | 10100 | DetNet Loose Path | THIS RFC |
| | | | | Option | | | | | | | Option | |
+------+-----+-----+-------+--------------------+-----------+ +------+-----+-----+-------+--------------------+-----------+
Table 3: DetNet Hop-by-Hop Options Table 3: DetNet Hop-by-Hop Options
7. Acknowledgments 8. Acknowledgments
TBD TBD
8. References 9. References
8.1. Normative References 9.1. Normative References
[RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL Power and Lossy Networks (RPL) Option for Carrying RPL
skipping to change at page 15, line 45 skipping to change at page 20, line 40
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021, RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>. <https://www.rfc-editor.org/info/rfc9030>.
[RAW-ARCH] Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable [RAW-ARCH] Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable
and Available Wireless Architecture/Framework", Work in and Available Wireless Architecture/Framework", Work in
Progress, Internet-Draft, draft-pthubert-raw-architecture- Progress, Internet-Draft, draft-pthubert-raw-architecture-
09, 7 July 2021, <https://datatracker.ietf.org/doc/html/ 09, 7 July 2021, <https://datatracker.ietf.org/doc/html/
draft-pthubert-raw-architecture-09>. draft-pthubert-raw-architecture-09>.
8.2. Informative References 9.2. Informative References
[RPL-PDAO] Thubert, P., Jadhav, R. A., and M. Gillmore, "Root [RPL-PDAO] Thubert, P., Jadhav, R. A., and M. Gillmore, "Root
initiated routing state in RPL", Work in Progress, initiated routing state in RPL", Work in Progress,
Internet-Draft, draft-ietf-roll-dao-projection-19, 27 July Internet-Draft, draft-ietf-roll-dao-projection-19, 27 July
2021, <https://datatracker.ietf.org/doc/html/draft-ietf- 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
roll-dao-projection-19>. roll-dao-projection-19>.
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
Xiao, "Overview and Principles of Internet Traffic Xiao, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002,
skipping to change at page 17, line 16 skipping to change at page 22, line 10
IEEE, "IEEE Standard for a Precision Clock Synchronization IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
IEEE Standard 1588, IEEE Standard 1588,
<https://ieeexplore.ieee.org/document/4579760/>. <https://ieeexplore.ieee.org/document/4579760/>.
[IPV6-PARMS] [IPV6-PARMS]
IANA, "Internet Protocol Version 6 (IPv6) Parameters", IANA, "Internet Protocol Version 6 (IPv6) Parameters",
<https://www.iana.org/assignments/ipv6-parameters/ <https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml>. ipv6-parameters.xhtml>.
Author's Address Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
France France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Fan Yang
Huawei Technologies
China
Email: shirley.yangfan@huawei.com
 End of changes. 24 change blocks. 
64 lines changed or deleted 228 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/