< draft-pthubert-detnet-ipv6-hbh-02.txt		draft-pthubert-detnet-ipv6-hbh-03.txt >
	DetNet P. Thubert, Ed.		DetNet P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track 9 June 2021		Intended status: Standards Track 11 June 2021
	Expires: 11 December 2021		Expires: 13 December 2021
	IPv6 Hop-by-Hop Options for DetNet		IPv6 Hop-by-Hop Options for DetNet
	draft-pthubert-detnet-ipv6-hbh-02		draft-pthubert-detnet-ipv6-hbh-03
	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
	Hop-by-Hop header options that can signal that information to the		IPv6 Hop-by-Hop options that signal that path and redundancy
	intermediate relays.		information to the intermediate DetNet relays.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 11 December 2021.		This Internet-Draft will expire on 13 December 2021.
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. The DetNet Options . . . . . . . . . . . . . . . . . . . . . 4		3. The DetNet Options . . . . . . . . . . . . . . . . . . . . . 4
	3.1. DetNet Sequencing Option . . . . . . . . . . . . . . . . 4		3.1. DetNet Redundancy Information Option . . . . . . . . . . 4
	3.2. RPL Packet Information . . . . . . . . . . . . . . . . . 6		3.2. DetNet Path Options . . . . . . . . . . . . . . . . . . . 8
	3.3. DetNet Local Path Option . . . . . . . . . . . . . . . . 7		3.2.1. DetNet Strict Path Option . . . . . . . . . . . . . . 8
	3.4. DetNet Global Path Option . . . . . . . . . . . . . . . . 7		3.2.2. DetNet Loose Path Option . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		3.3. RPL Packet Information . . . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5.1. New Subregistry for the Sequencing Type . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5.2. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . 9		5.1. New Subregistry for the Redundancy Type . . . . . . . . . 10
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		5.2. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 13
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Section 2 of the Deterministic Networking Problem Statement		Section 2 of the Deterministic Networking Problem Statement
	[DetNet-PS] 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].		and MPLS [RFC8938].
	The "Deterministic Networking Architecture" [DetNet-ARCHI] details		The "Deterministic Networking Architecture" [DetNet-ARCH] details the
	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-ARCHI] places an emphasis on the centralized model		Plane. [DetNet-ARCH] places an emphasis on the centralized model
	whereby a controller instantiates per-flow state in the routers to		whereby a controller instantiates per-flow state in the routers to
	perform adequate forwading operations so as to provide end-to-end		perform adequate forwading operations so as to provide end-to-end
	reliability and bounded latency guarantees.		reliability and bounded latency guarantees.
	The "6TiSCH Architecture" [6TiSCH-ARCHI] leverages RPL, the "Routing		The "6TiSCH Architecture" [6TiSCH-ARCH] leverages RPL, the "Routing
	Protocol for Low Power and Lossy Networks" [RFC6550] 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 node, that		Directed Acyclic Graph (DODAG) rooted at the Track Ingress node, that
	can be installed using so-called projected routes [RPL-PDAO]. In		can be installed using so-called projected routes [RPL-PDAO]. In
	that case, the TrackId is an index from a namespace associated to one		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		IPv6 address of the Track Ingress node, and the Track that an IPv6
	packet follows is signaled by the combination of the source address		packet follows is signaled by the combination of the source address
	(of the Track Ingress node), and the TrackID placed in a RPL Option		(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]		[RFC6553] located in an IPv6 Hop-by-Hop (HbH) Options Header [IPv6]
	in the IPv6 packet.		in the IPv6 packet.
	The "Reliable and Available Wireless (RAW) Architecture/Framework"		The "Reliable and Available Wireless (RAW) Architecture/Framework"
	[RAW-ARCHI], extends the DetNet Network Plane to accomodate one or		[RAW-ARCH], extends the DetNet Network Plane to accomodate one or
	multiple hops of homogeneous or heterogeneous wireless technologies,		multiple hops of homogeneous or heterogeneous wireless technologies,
	e.g. a Wi-Fi6 Mesh or parallel radio access links combining Wi-Fi and		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		5G. The RAW Architecture reuses the concept of Track and introduces
	a new dataplane component, the Path Selection Engine (PSE), to		a new dataplane component, the Path Selection Engine (PSE), to
	dynamically select a subpath and maintain the required quality of		dynamically select a subpath and maintain the required quality of
	service within a Track in the face of the rapid evolution of the		service within a Track in the face of the rapid evolution of the
	medium properties.		medium properties.
	With [IPv6], the behavior of a router upon an IPv6 packet with a HbH		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		Options Header has evolved, making the examination of the header by
	routers along the path optional, as opposed to previously mandatory.		routers along the path optional, as opposed to previously mandatory.
	Additionally, the Option Type for any option in a HbH Options Header		Additionally, the Option Type for any option in a HbH Options Header
	encodes in the leftmost bits whether a router that inspects the		encodes in the leftmost bits whether a router that inspects the
	header should drop the packet or ignore the option when encountering		header should drop the packet or ignore the option when encountering
	an unknown option. Combined, these capabilities enable a larger use		an unknown option. Combined, these capabilities enable a larger use
	of the header beyond the boundaries of a limited domain, as		of the header beyond the boundaries of a limited domain, as
	examplified by the change of behavior of the RPL data plane, that was		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		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-PROCESS] 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		The "Deterministic Networking Data Plane Framework" [RFC8938] relies
	on the 6-tuple to identify an IPv6 flow. But the full DetNet		on the 6-tuple to identify an IPv6 flow. But the full DetNet
	operations require also the capabilities to signal meta-information		operations require also the capabilities to signal meta-information
	such as a sequence within that flow, and to transport different types		such as a sequence within that flow, and to transport different types
	of packets along the same path with the same treatment. For		of packets along the same path with the same treatment. For
	instance, it is required that Operations, Administration, and		instance, it is required that Operations, Administration, and
	Maintenance (OAM) [RFC6291] packets and/or multiple flows share the		Maintenance (OAM) [RFC6291] packets and/or multiple flows share the
	same fate and resource sharing over the same Track or the same		same fate and resource sharing over the same Track or the same
	Traffic Engineered (TE) [RFC3272] DetNet path.		Traffic Engineered (TE) [RFC3272] DetNet path.
	This document introduces new Hop-by-Hop options that can signal		This document introduces new IPv6 Hop-by-Hop options that signal
	DetNet path and sequencing information to the intermediate relays in		DetNet path and redundancy information to the intermediate relays in
	an abstract form that is independent of the transport layer.		an abstract form that is independent of the transport layer.
	Transported in IPv6 HbH Options, the DetNet information is available		Transported in IPv6 HbH Options, the DetNet information is available
	early in the header chain of the packet and presented and added as		early in the header chain of the packet and can be added by a service
	part of a service instance encapsulation by the Ingress of the DetNet		instance as part of the encapsulation by the Ingress of the DetNet
	path and accessed by the intermediate DetNet relay nodes.		path. It can then be accessed by the intermediate DetNet routers
			without the need of a deep packet inspection (e.g., beyond UDP).
	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-ARCHI].		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"
	[6TiSCH-ARCHI].		[6TiSCH-ARCH].
	3. The DetNet Options		3. The DetNet Options
	This document defines a number of IPv6 options to be placed in a HbH		This document defines new IPv6 options for DetNet to signal path and
	Options Header; the format of these options follow the generic		a sequence to the DetNet layers. Those options are to be placed in
	definition in section 4.2 of [IPv6].		an IPv6 HbH Options Header. The format of the options follow the
			generic definition in section 4.2 of [IPv6].
	3.1. DetNet Sequencing Option		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].
	A typical packet sequence can be expressed uniquely as a wrapping		3.1. DetNet Redundancy Information Option
	counter, represented as an unsigned integer in the option. In that
	case, the size of the representation MUST be large enough to cover at		The DetNet Redundancy Information Option helps discriminate copies of
	least 3 times the upper bound on out-of-order packet delivery in		a same packet vs. different packets, and is useful for service-
	terms of number of packets.		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		This specification also allows to use a time stamp for the packet
	sequencing following the recommendations in [RFC8877]. This can be		redundancy information, in conformance with the recommendations in
	accomplished by utilizing the Precision Time Protocol (PTP) format		[RFC8877]. This can be accomplished by utilizing the Precision Time
	defined in IEEE Std. 1588 [IEEE Std. 1588] or Network Time Protocol		Protocol (PTP) format defined in IEEE Std. 1588 [IEEE Std. 1588] or
	(NTP) [RFC5905] formats. In that case, the timestamp resolution at		Network Time Protocol (NTP) [RFC5905] formats. In that case, the
	the origin node that builds the option MUST be fine enough to ensure		timestamp resolution at the origin node that builds the option MUST
	that two consecutive packets are never stamped with the same value.		be fine enough to ensure that two consecutive packets are never
	There is no requirement for this particular stamping function that		stamped with the same value. There is no requirement for this
	the sense of time at the origin node is synchronized with the rest of		particular stamping function that the sense of time at the origin
	the DetNet network.		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		This specification also allows for an hybrid model with a coarse
	grained packet sequence within a coarse grained time stamp. In that		grained packet sequence within a coarse grained time stamp. In that
	case, both a time stamp option and a wrapping counter options are		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		found, and the counter is used to compare packets with the same time
	stamp and ignored otherwise In that case, the size of the		stamp and ignored otherwise In that case, the size of the
	representation of the counter MUST be large enough to cover at least		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		3 times the number of packets that may be sent with the same value of
	time stamp.		time stamp.
	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 | Seq. Type | Reserved |		| Option Type | Opt Data Len | R.I. Type | Fragment Tag |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Sequencing Information (variable Size) .		. Redundancy Information (variable Size) .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Sequencing Option Format		Figure 1: Redundancy Information Option Format
	Sequencing Option fields:		Redundancy Information 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.		IANA; if the processing IPv6 node does not recognize the Option
			Type it MUST skip over this option and continue processing the
			header (act =00); the Option Data of that option cannot change en
			route to the packet's final destination (chg=0). The
	Opt Data Len: 8-bit length of the option data.		Opt Data Len: 8-bit length of the option data.
	Reserved: 8-bit field, set to 0 and ignored on reception.		Fragment Tag: 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.
	Sequence Type: 8-bit identifier of the type of sequencing		Redundancy Information Type: 8-bit identifier of the type of
	information. Value to be confirmed by IANA.		Redundancy information. Value to be confirmed by IANA.
	+=======+==========+===============+===========================+		+=======+============+===============+===========================+
	| Seq. | Category | Common Name | Sequencing Information |		| Seq. | Category | Common Name | Redundancy |
	| Type | | | Format |		| Type | | | Information Format |
	| Value | | | |		| Value | | | |
	+=======+==========+===============+===========================+		+=======+============+===============+===========================+
	| 1 | Wrapping | Basic | 32-bit unsigned integer |		| 1 | Wrapping | Basic | 32-bit unsigned |
	| | Counter | Sequence | |		| | Counter | Sequence | integer |
	| | | Counter | |		| | | Counter | |
	+-------+==========+---------------+---------------------------+		+-------+============+---------------+---------------------------+
	| 2 | Wrapping | Zero-avoiding | 32-bit unsigned integer, |		| 2 | Wrapping | Zero-avoiding | 32-bit unsigned |
	| | Counter | Sequence | wraps to 1 |		| | Counter | Sequence | integer, wraps to 1 |
	| | | Counter | |		| | | Counter | |
	+-------+==========+---------------+---------------------------+		+-------+============+---------------+---------------------------+
	| 3 | Wrapping | RPL Sequence | 8-bit RPL sequence, see |		| 3 | Wrapping | RPL Sequence | 8-bit RPL sequence, |
	| | Counter | Counter | section 7. of [RFC6550] |		| | Counter | Counter | see section 7. of |
	+-------+==========+---------------+---------------------------+		| | | | [RPL] |
	| 11 | Time | Fractional | NTP 64-bit Timestamp |		+-------+============+---------------+---------------------------+
	| | Stamp | NTP | Format, see section |		| 11 | Time Stamp | Fractional | NTP 64-bit Timestamp |
	| | | | 4.2.1. of [RFC8877] |		| | | NTP | Format, see section |
	+-------+==========+---------------+---------------------------+		| | | | 4.2.1. of [RFC8877] |
	| 12 | Time | Short NTP | NTP 32-bit Timestamp |		+-------+============+---------------+---------------------------+
	| | Stamp | | Format, see section |		| 12 | Time Stamp | Short NTP | NTP 32-bit Timestamp |
	| | | | 4.2.2. of [RFC8877] |		| | | | Format, see section |
	+-------+==========+---------------+---------------------------+		| | | | 4.2.2. of [RFC8877] |
	| 13 | Time | PTP | PTP 80-bit Timestamp |		+-------+============+---------------+---------------------------+
	| | Stamp | | Format, see [IEEE Std. |		| 13 | Time Stamp | PTP | PTP 80-bit Timestamp |
	| | | | 1588] |		| | | | Format, see [IEEE |
	+-------+==========+---------------+---------------------------+		| | | | Std. 1588] |
	| 14 | Time | Short PTP | PTP 64-bit Truncated |		+-------+============+---------------+---------------------------+
	| | Stamp | | Timestamp Format, see |		| 14 | Time Stamp | Short PTP | PTP 64-bit Truncated |
	| | | | section 4.3. of [RFC8877] |		| | | | Timestamp Format, |
	+-------+==========+---------------+---------------------------+		| | | | see section 4.3. of |
			| | | | [RFC8877] |
			+-------+============+---------------+---------------------------+
			| 24 | Structured | TSN | 48-bit opaque |
			| | Unique Tag | Redundancy | |
			| | | Tag | |
			+-------+============+---------------+---------------------------+
	Table 1: Sequence Type values (suggested)		Table 1: Redundancy Information Type values (suggested)
	Sequencing Information: Variable size, as indicated in Table 1.		Redundancy Information: Variable size, as indicated in Table 1.
	3.2. RPL Packet Information		3.2. DetNet Path Options
	6TiSCH [6TiSCH-ARCHI] and RAW [RAW-ARCHI] signal a Track using a RPL		The DetNet Path Options carry path information that is independent
	Option [RFC6553] with a RPLInstanceID used as TrackID. This		from the flows transported. When present, it is the information that
	specification reuses the RPL option as a method to signal a DetNet		MUST be used to select the DetNet state at the DetNet forwarding
	path. In that case, the Projected-Route 'P' flag [RPL-PDAO] MUST be		sublayer.
	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.
	3.3. DetNet Local Path Option		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.
			3.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 Local 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.
	0 1 2 3		The DetNet Strict Path Option is to be used in a limited domain and
	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		all routers along the path are expected to support the option.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option Type | Opt Data Len | Local Path ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: DetNet Local Path Option Format		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.
	Sequencing Option fields:		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 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 2: DetNet Strict Path Option Format
			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.		IANA; if the processing IPv6 node does not recognize the Option
			Type it must discard the packet and send an ICMP Parameter
			Problem, Code 2, message to the packet's Source Address (act =10);
			the Option Data of that option cannot change en route to the
			packet's final destination (chg=0).
	Opt Data Len: 8-bit length of the option data, set to 2.		Opt Data Len: 8-bit length of the option data, set to 2.
	Local Path ID: 16-bit identifier of the DetNet Path, taken from a		Strict Path ID: 16-bit identifier of the DetNet Path, taken from a
	local namespace associated with the IPv6 source address of the		local namespace associated with the IPv6 source address of the
	packet.		packet.
	3.4. DetNet Global Path Option		3.2.2. DetNet Loose Path Option
	The DetNet Global Path Option transports a global path identifier		The DetNet Loose Path Option transports a Loose Path identifier which
	which is taken from a namespace indicated by the Origin Autonomous		is taken from a namespace indicated by the Origin Autonomous System
	System (AS). When the DetNet path is contained within a single AS,		(AS). When the DetNet path is contained within a single AS, the
	the Origin Autonomous System field can be left to 0 indicating local		Origin Autonomous System field can be left to 0 indicating local AS.
	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
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Global Path ID |		| Loose Path ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: DetNet Glocal Path Option Format		Figure 3: DetNet Loose Path Option Format
	Sequencing 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.		IANA; if the processing IPv6 node does not recognize the Option
			Type it MUST skip over this option and continue processing the
			header (act =00); the Option Data of that option cannot change en
			route to the packet's final destination (chg=0).
	Opt Data Len: 8-bit length of the option data, set to 6.		Opt Data Len: 8-bit length of the option data, set to 6.
	Origin Autonomous System: 16-bit identifier of the Autonomous		Origin Autonomous System: 16-bit identifier of the Autonomous
	Systems (AS) that originates the path.		Systems (AS) that originates the path.
	Global Path ID: 32-bit identifier of the DetNet Path, taken from a		Loose Path ID: 32-bit identifier of the DetNet Path, taken from a
	local namespace associated with the origin AS of the DetNet path.		local namespace associated with the origin AS of the DetNet path.
	The value of 0 signals a DetNet path that is constrained within		The value of 0 signals a DetNet path that is constrained within
	the local AS or the local administrative DetNet domain.		the local AS or the local administrative DetNet domain.
			3.3. RPL Packet Information
			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.
	4. Security Considerations		4. Security Considerations
	5. IANA Considerations		5. IANA Considerations
	5.1. New Subregistry for the Sequencing Type		5.1. New Subregistry for the Redundancy Type
	This specification creates a new Subregistry for the "Sequencing Type		This specification creates a new Subregistry for the "Redundancy Type
	of the Sequencing Option" under the "Internet Protocol Version 6		of the Redundancy Option" under the "Internet Protocol Version 6
	(IPv6) Parameters" registry.		(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:
	+-----------------+--------------------------------+-----------+		+-----------------+--------------------------------+-----------+
	| Suggested Value | Meaning | Reference |		| Suggested Value | Meaning | Reference |
	+-----------------+--------------------------------+-----------+		+-----------------+--------------------------------+-----------+
	skipping to change at page 8, line 48 ¶		skipping to change at page 11, line 28 ¶
	| 3 | RPL Sequence Counter | THIS RFC |		| 3 | RPL Sequence Counter | THIS RFC |
	+-----------------+--------------------------------+-----------+		+-----------------+--------------------------------+-----------+
	| 11 | Fractional NTP time stamp | THIS RFC |		| 11 | Fractional NTP time stamp | THIS RFC |
	+-----------------+--------------------------------+-----------+		+-----------------+--------------------------------+-----------+
	| 12 | Short NTP time stamp | THIS RFC |		| 12 | Short NTP time stamp | THIS RFC |
	+-----------------+--------------------------------+-----------+		+-----------------+--------------------------------+-----------+
	| 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 |
			+-----------------+--------------------------------+-----------+
	Table 2: Sequence Type values		Table 2: Redundancy Information Type values
	5.2. New Hop-by-Hop Options		5.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 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 Sequencing Option | THIS RFC |		| 0x12 | 00 | 0 | 10010 | DetNet Redundancy | THIS RFC |
	+------+-----+-----+-------+---------------------------+-----------+		| | | | | Information Option | |
	| 0x13 | 00 | 0 | 10011 | DetNet Local Path Option | THIS RFC |		+------+-----+-----+-------+--------------------+-----------+
	+------+-----+-----+-------+---------------------------+-----------+		| 0x93 | 10 | 0 | 10011 | DetNet Strict Path | THIS RFC |
	| 0x14 | 00 | 0 | 10100 | DetNet Global Path Option | THIS RFC |		| | | | | Option | |
	+------+-----+-----+-------+---------------------------+-----------+		+------+-----+-----+-------+--------------------+-----------+
			| 0x14 | 00 | 0 | 10100 | DetNet Loose Path | THIS RFC |
			| | | | | Option | |
			+------+-----+-----+-------+--------------------+-----------+
	Table 3: DetNet Hop-by-Hop Options		Table 3: DetNet Hop-by-Hop Options
	6. Acknowledgments		6. Acknowledgments
	TBD		TBD
	7. References		7. References
	7.1. Normative References		7.1. Normative References
			[RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
			Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
			JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
			Low-Power and Lossy Networks", RFC 6550,
			DOI 10.17487/RFC6550, March 2012,
			<https://www.rfc-editor.org/info/rfc6550>.
			[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
			Power and Lossy Networks (RPL) Option for Carrying RPL
			Information in Data-Plane Datagrams", RFC 6553,
			DOI 10.17487/RFC6553, March 2012,
			<https://www.rfc-editor.org/info/rfc6553>.
	[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for		[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
	Defining Packet Timestamps", RFC 8877,		Defining Packet Timestamps", RFC 8877,
	DOI 10.17487/RFC8877, September 2020,		DOI 10.17487/RFC8877, September 2020,
	<https://www.rfc-editor.org/info/rfc8877>.		<https://www.rfc-editor.org/info/rfc8877>.
	[HbH-PROCESS]		[HbH-UPDT] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
	Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
	Processing Procedures", Work in Progress, Internet-Draft,		Processing Procedures", Work in Progress, Internet-Draft,
	draft-hinden-6man-hbh-processing-00, 3 December 2020,		draft-hinden-6man-hbh-processing-00, 3 December 2020,
	<https://tools.ietf.org/html/draft-hinden-6man-hbh-		<https://tools.ietf.org/html/draft-hinden-6man-hbh-
	processing-00>.		processing-00>.
	[DetNet-ARCHI]		[DetNet-ARCH]
	Finn, N., Thubert, P., Varga, B., and J. Farkas,		Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", RFC 8655,		"Deterministic Networking Architecture", RFC 8655,
	DOI 10.17487/RFC8655, October 2019,		DOI 10.17487/RFC8655, October 2019,
	<https://www.rfc-editor.org/info/rfc8655>.		<https://www.rfc-editor.org/info/rfc8655>.
	[6TiSCH-ARCHI]		[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
			Option Type, Routing Header for Source Routes, and IPv6-
			in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
			DOI 10.17487/RFC9008, April 2021,
			<https://www.rfc-editor.org/info/rfc9008>.
			[6TiSCH-ARCH]
	Thubert, P., Ed., "An Architecture for IPv6 over the Time-		Thubert, P., Ed., "An Architecture for IPv6 over the Time-
	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-ARCHI]		[RAW-ARCH] Thubert, P., Papadopoulos, G. Z., and R. Buddenberg,
	Thubert, P., Papadopoulos, G. Z., and R. Buddenberg,
	"Reliable and Available Wireless Architecture/Framework",		"Reliable and Available Wireless Architecture/Framework",
	Work in Progress, Internet-Draft, draft-pthubert-raw-		Work in Progress, Internet-Draft, draft-pthubert-raw-
	architecture-05, 15 November 2020,		architecture-05, 15 November 2020,
	<https://tools.ietf.org/html/draft-pthubert-raw-		<https://tools.ietf.org/html/draft-pthubert-raw-
	architecture-05>.		architecture-05>.
	7.2. Informative References		7.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,
	skipping to change at page 10, line 44 ¶		skipping to change at page 13, line 43 ¶
	D., and S. Mansfield, "Guidelines for the Use of the "OAM"		D., and S. Mansfield, "Guidelines for the Use of the "OAM"
	Acronym in the IETF", BCP 161, RFC 6291,		Acronym in the IETF", BCP 161, RFC 6291,
	DOI 10.17487/RFC6291, June 2011,		DOI 10.17487/RFC6291, June 2011,
	<https://www.rfc-editor.org/info/rfc6291>.		<https://www.rfc-editor.org/info/rfc6291>.
	[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,		[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
	"Network Time Protocol Version 4: Protocol and Algorithms		"Network Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,		Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
	<https://www.rfc-editor.org/info/rfc5905>.		<https://www.rfc-editor.org/info/rfc5905>.
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[DetNet-PBST]
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550,
	DOI 10.17487/RFC6550, March 2012,
	<https://www.rfc-editor.org/info/rfc6550>.
	[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
	Power and Lossy Networks (RPL) Option for Carrying RPL
	Information in Data-Plane Datagrams", RFC 6553,
	DOI 10.17487/RFC6553, March 2012,
	<https://www.rfc-editor.org/info/rfc6553>.
	[DetNet-PS]
	Finn, N. and P. Thubert, "Deterministic Networking Problem		Finn, N. and P. Thubert, "Deterministic Networking Problem
	Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,		Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,
	<https://www.rfc-editor.org/info/rfc8557>.		<https://www.rfc-editor.org/info/rfc8557>.
	[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
	Option Type, Routing Header for Source Routes, and IPv6-
	in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
	DOI 10.17487/RFC9008, April 2021,
	<https://www.rfc-editor.org/info/rfc9008>.
	[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,
	<https://www.rfc-editor.org/info/rfc3272>.		<https://www.rfc-editor.org/info/rfc3272>.
	[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.		[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
	Bryant, "Deterministic Networking (DetNet) Data Plane		Bryant, "Deterministic Networking (DetNet) Data Plane
	Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,		Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
	<https://www.rfc-editor.org/info/rfc8938>.		<https://www.rfc-editor.org/info/rfc8938>.
	skipping to change at page 11, line 48 ¶		skipping to change at page 14, line 26 ¶
	[IEEE 802.1 TSN]		[IEEE 802.1 TSN]
	IEEE 802.1, "Time-Sensitive Networking (TSN) Task Group",		IEEE 802.1, "Time-Sensitive Networking (TSN) Task Group",
	<http://www.ieee802.org/1/pages/tsn.html>.		<http://www.ieee802.org/1/pages/tsn.html>.
	[IEEE Std. 1588]		[IEEE Std. 1588]
	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]
			IANA, "Internet Protocol Version 6 (IPv6) Parameters",
			<https://www.iana.org/assignments/ipv6-parameters/
			ipv6-parameters.xhtml>.
	Author's Address		Author's Address
	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
End of changes. 62 change blocks.
	166 lines changed or deleted		284 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/