< draft-thubert-raw-technologies-01.txt		draft-thubert-raw-technologies-02.txt >
	RAW P. Thubert, Ed.		RAW P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Informational D. Cavalcanti		Intended status: Informational D. Cavalcanti
	Expires: December 8, 2019 Intel		Expires: December 21, 2019 Intel
	X. Vilajosana		X. Vilajosana
	Universitat Oberta de Catalunya		Universitat Oberta de Catalunya
	June 6, 2019		June 19, 2019
	Reliable and Available Wireless Technologies		Reliable and Available Wireless Technologies
	draft-thubert-raw-technologies-01		draft-thubert-raw-technologies-02
	Abstract		Abstract
	This document presents a series of recent technologies that are		This document presents a series of recent technologies that are
	capable of time synchronization and scheduling of transmission,		capable of time synchronization and scheduling of transmission,
	making them suitable to carry time-sensitive flows with requirements		making them suitable to carry time-sensitive flows with requirements
	of both reliable delivery in bounded time, and availability at all		of both reliable delivery in bounded time, and availability at all
	times, regardless of packet transmission or individual equipement		times, regardless of packet transmission or individual equipement
	failures.		failures.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 December 8, 2019.		This Internet-Draft will expire on December 21, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 4		3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 4		3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 4
	3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 4		3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 5
	4. IEEE 802 standards . . . . . . . . . . . . . . . . . . . . . 5		4. IEEE 802 standards . . . . . . . . . . . . . . . . . . . . . 6
	4.1. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1.1. Provenance and Documents . . . . . . . . . . . . . . 5		4.1.1. Provenance and Documents . . . . . . . . . . . . . . 6
	4.1.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . 7		4.1.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . 8
			4.1.2.1. General Characteristics . . . . . . . . . . . . . 8
			4.1.2.1.1. Multi-User OFDMA and Trigger-based Scheduled
			Access . . . . . . . . . . . . . . . . . . . 8
			4.1.2.1.2. Improved PHY Robustness . . . . . . . . . . . 8
			4.1.2.1.3. Support for 6GHz band . . . . . . . . . . . . 9
			4.1.2.2. Applicability to deterministic flows . . . . . . 9
			4.1.2.2.1. 802.11 Managed network operation and
			admission control . . . . . . . . . . . . . . 9
			4.1.2.2.2. Scheduling for bounded latency and diversity 10
	4.1.3. 802.11be Extreme High Throughput (EHT) . . . . . . . 10		4.1.3. 802.11be Extreme High Throughput (EHT) . . . . . . . 10
	4.1.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . 11		4.1.3.1. General Characteristics . . . . . . . . . . . . . 10
	4.2. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 12		4.1.3.2. Applicability to deterministic flows . . . . . . 11
	4.2.1. Provenance and Documents . . . . . . . . . . . . . . 12		4.1.3.2.1. Enhanced scheduled operation for bounded
	4.2.2. TimeSlotted Channel Hopping . . . . . . . . . . . . . 14		latency . . . . . . . . . . . . . . . . . . . 11
	5. 3GPP standards . . . . . . . . . . . . . . . . . . . . . . . 16		4.1.3.2.2. Multi-AP coordination . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		4.1.3.2.3. Multi-band operation . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		4.1.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . 12
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		4.1.4.1. General Characteristics . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.1.4.2. Applicability to deterministic flows . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 17		4.2. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 17		4.2.1. Provenance and Documents . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		4.2.2. TimeSlotted Channel Hopping . . . . . . . . . . . . . 15
			4.2.2.1. General Characteristics . . . . . . . . . . . . . 15
			4.2.2.2. Applicability to Deterministic Flows . . . . . . 16
			4.2.2.2.1. Centralized Path Computation . . . . . . . . 16
			4.2.2.2.2. 6TiSCH Tracks . . . . . . . . . . . . . . . . 22
			5. 3GPP standards . . . . . . . . . . . . . . . . . . . . . . . 29
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
			8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
			9.1. Normative References . . . . . . . . . . . . . . . . . . 29
			9.2. Informative References . . . . . . . . . . . . . . . . . 30
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	When used in math or philosophy, the term "deterministic" generally		When used in math or philosophy, the term "deterministic" generally
	refers to a perfection where all aspect are understood and		refers to a perfection where all aspect are understood and
	predictable. A perfectly Deterministic Network would ensure that		predictable. A perfectly Deterministic Network would ensure that
	every packet reach its destination following a predetermined path		every packet reach its destination following a predetermined path
	along a predefined schedule to be delivered at the exact due time.		along a predefined schedule to be delivered at the exact due time.
	In a real and imperfect world, a Deterministic Network must highly		In a real and imperfect world, a Deterministic Network must highly
	predictable, which is a combination of reliability and availability.		predictable, which is a combination of reliability and availability.
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 47 ¶
	the transmission losses that are experienced when a radio is used as		the transmission losses that are experienced when a radio is used as
	pure P2P.		pure P2P.
	2. Terminology		2. Terminology
	This specification uses several terms that are uncommon on protocols		This specification uses several terms that are uncommon on protocols
	that ensure bets effort transmissions for stochastics flows, such as		that ensure bets effort transmissions for stochastics flows, such as
	found in the traditional Internet and other statistically multiplexed		found in the traditional Internet and other statistically multiplexed
	packet networks.		packet networks.
	Reliable: That consistently performs as expected, the expectation		ARQ: Automatic Repeat Request, enabling an acknowledged transmission
	for a network being to always deliver a packet in due time.		and retries. ARQ is a typical model at Layer-2 on a wireless
			medium. It is typically avoided end-to-end on deterministic
			flows because it introduces excessive indetermination in
			latency, but a limited number of retries within a bounded time
			may be used over a wireless link and yet respect end-to-end
			constraints.
	Available: That is exempt of unscheduled outage, the expectation for		Available: That is exempt of unscheduled outage, the expectation for
	a network being that the flow is maintained in the face of any		a network being that the flow is maintained in the face of any
	single breakage.		single breakage.
			FEC: Forward error correction, sending redundant coded data to help
			the receiver recover transmission errors without the delays
			incurred with ARQ.
			HARQ: Hybrid ARQ, a combination of FEC and ARQ.
			PCE: Path Computation Element.
	PAREO (functions): the wireless extension of DetNet PREOF. PAREO		PAREO (functions): the wireless extension of DetNet PREOF. PAREO
	functions include scheduled ARQ at selected hops, and expect		functions include scheduled ARQ at selected hops, and expect
	the use of new operations like overhearing where available.		the use of new operations like overhearing where available.
			Reliable: That consistently performs as expected, the expectation
			for a network being to always deliver a packet in due time.
	Track: A DODAG oriented to a destination, and that enables Packet		Track: A DODAG oriented to a destination, and that enables Packet
	ARQ, Replication, Elimination, and Ordering Functions.		ARQ, Replication, Elimination, and Ordering Functions.
	ARQ: Automatic Repeat Request, enabling an acknowledged
	transmission, which is the typical model at Layer-2 on a
	wireless medium.
	HARQ: Forward error correction, sending redundant coded data to help
	the receiver recover transmission errors.
	HARQ: Hybrid ARQ, a combination of FEC and ARQ.
	3. On Scheduling		3. On Scheduling
	The operations of a Deterministic Network often rely on precisely		The operations of a Deterministic Network often rely on precisely
	applying a tight schedule, in order to avoid collision loss and		applying a tight schedule, in order to avoid collision loss and
	guarantee the worst-case time of delivery. To achieve this, there		guarantee the worst-case time of delivery. To achieve this, there
	must be a shared sense of time throughout the network. The sense of		must be a shared sense of time throughout the network. The sense of
	time is usually provided by the lower layer and is not in scope for		time is usually provided by the lower layer and is not in scope for
	RAW.		RAW.
	3.1. Benefits of Scheduling on Wires		3.1. Benefits of Scheduling on Wires
	skipping to change at page 12, line 41 ¶		skipping to change at page 13, line 20 ¶
	802.11ay, and it is one of the mechanisms that can be used to provide		802.11ay, and it is one of the mechanisms that can be used to provide
	bounded latency to time-sensitive data flows. An analysis of the		bounded latency to time-sensitive data flows. An analysis of the
	theoretical latency bounds that can be achieved with 802.11ad service		theoretical latency bounds that can be achieved with 802.11ad service
	periods is provided in [Cavalcanti_2019].		periods is provided in [Cavalcanti_2019].
	4.2. IEEE 802.15.4		4.2. IEEE 802.15.4
	4.2.1. Provenance and Documents		4.2.1. Provenance and Documents
	The IEEE802.15.4 Task Group has been driving the development of low-		The IEEE802.15.4 Task Group has been driving the development of low-
	power low-cost radio technology. The Timeslotted Channel Hopping		power low-cost radio technology. The IEEE802.15.4 physical layer has
	mode, added to the 2015 revision of the IEEE802.15.4 standard		been designed to support demanding low-power scenarios targeting the
	[IEEE802154], is targeted at the embedded and industrial world, where		use of unlicensed bands, both the 2.4 GHz and sub GHz Industrial,
	reliability, energy consumption and cost drive the application space.		Scientific and Medical (ISM) bands. This has imposed requirements in
			terms of frame size, data rate and bandwidth to achieve reduced
			collision probability, reduced packet error rate, and acceptable
			range with limited transmission power. The PHY layer supports frames
			of up to 127 bytes. The Medium Access Control (MAC) sublayer
			overhead is in the order of 10-20 bytes, leaving about 100 bytes to
			the upper layers. IEEE802.15.4 uses spread spectrum modulation such
			as the Direct Sequence Spread Spectrum (DSSS).
	The IEEE802.15.4 physical layer has been designed to support		The Timeslotted Channel Hopping (TSCH) mode was added to the 2015
	demanding low-power scenarios targeting the use of unlicensed bands,		revision of the IEEE802.15.4 standard [IEEE802154]. TSCH is targeted
	both the 2.4 GHz and sub GHz Industrial, Scientific and Medical (ISM)		at the embedded and industrial world, where reliability, energy
	bands. This has imposed requirements in terms of frame size, data		consumption and cost drive the application space.
	rate and bandwidth to achieve reduced collision probability, reduced
	packet error rate, and acceptable range with limited transmission
	power. The PHY layer supports frames of up to 127 bytes. The Medium
	Access Control (MAC) sublayer overhead is in the order of 10-20
	bytes, leaving about 100 bytes to the upper layers. IEEE802.15.4
	uses spread spectrum modulation such as the Direct Sequence Spread
	Spectrum (DSSS).
	IPv6 over TSCH is enabled by the work done at the 6TiSCH WG. 6TiSCH		At the IETF, the 6TiSCH Working Group (WG) [TiSCH] deals with best
	has enabled best effort distributed scheduling to exploit the		effort operation of IPv6 [RFC8200] over TSCH. 6TiSCH has enabled
	deterministic access capabilities provided by TSCH. The group		distributed scheduling to exploit the deterministic access
	designed the essential mechanisms to enable the management plane		capabilities provided by TSCH. The group designed the essential
	operation while ensuring IPv6 is supported. Yet the charter did not		mechanisms to enable the management plane operation while ensuring
	focus to providing a solution to establish end to end tracks while		IPv6 is supported. Yet the charter did not focus to providing a
	meeting quality of service requirements. 6TiSCH, through the RFC8480		solution to establish end to end Tracks while meeting quality of
	[RFC8480] defines the 6P protocol which provides a pairwise		service requirements. 6TiSCH, through the RFC8480 [RFC8480] defines
	negotiation mechanism to the control plane operation. The protocol		the 6P protocol which provides a pairwise negotiation mechanism to
	supports agreement on a schedule between neighbors, enabling		the control plane operation. The protocol supports agreement on a
	distributed scheduling. 6P goes hand-in-hand with a Scheduling		schedule between neighbors, enabling distributed scheduling. 6P goes
	Function (SF), the policy that decides how to maintain cells and		hand-in-hand with a Scheduling Function (SF), the policy that decides
	trigger 6P transactions. The Minimal Scheduling Function (MSF)		how to maintain cells and trigger 6P transactions. The Minimal
	[I-D.ietf-6tisch-msf] is the default SF defined by the 6TiSCH WG;		Scheduling Function (MSF) [I-D.ietf-6tisch-msf] is the default SF
	other standardized SFs can be defined in the future. MSF extends the		defined by the 6TiSCH WG; other standardized SFs can be defined in
	minimal schedule configuration, and is used to add child-parent links		the future. MSF extends the minimal schedule configuration, and is
	according to the traffic load.		used to add child-parent links according to the traffic load.
	Time sensitive networking on low power constrained wireless networks		Time sensitive networking on low power constrained wireless networks
	have been addressed by ISA100.11a and WirelessHART. TODO		have been partially addressed by ISA100.11a [ISA100.11a] and
			WirelessHART [WirelessHART]. Both technologies involve a central
			controller that computes redundant paths for industrial process
			control traffic over a TSCH mesh. Moreover, ISA100.11a introduces
			IPv6 capabilities with a Link-Local Address for the join process and
			a global unicast addres for later exchanges, but the IPv6 traffic
			typically ends at a local application gateway and the full power of
			IPv6 for end-to-end communication is not enabled. Compared to that
			state of the art, work at the IETF and in particular at RAW could
			provide additional techniques such as optimized P2P routing, PAREO
			functions, and end-to-end secured IPv6/CoAP connectivity.
	The 6TiSCH architecture [I-D.ietf-6tisch-architecture] already		The 6TiSCH architecture [I-D.ietf-6tisch-architecture] identifies
	identified different models to schedule resources along tracks		different models to schedule resources along so-called Tracks (see
	exploiting the TSCH schedule structure however these models have not		Section 4.2.2.2.2) exploiting the TSCH schedule structure however the
	been standardized. A Track, in the 6TiSCH architecture is considered		focus at 6TiSCH is on best effort traffic and the group was never
	a directed path from a source 6TiSCH node to one or more		chartered to produce standard work related to Tracks.
	destination(s) 6TiSCH node(s) through the 6TiSCH network. A Track in
	6TiSCH is the implementation of the deterministic path in the Detnet
	architecture [I-D.ietf-detnet-architecture] . Along a Track, 6TiSCH
	nodes reserve the resources to enable the efficient transmission of
	packets while aiming to optimize certain properties such as
	reliability and ensure small jitter or bounded latency. The track
	structure enables Layer-2 forwarding schemes, reducing the overhead
	of taking routing decisions at the Layer-3. Serial Tracks can be
	understood as the concatenation of cells or bundles along a routing
	path from a node towards a destination. The serial track concept is
	analogous to the circuit concept where resources are chained through
	the multi-hop topology. For example, A bundle of Tx Cells in a
	particular node is paired to a bundle of Rx Cells in the next hop
	node following a routing path. More complex approaches are described
	in and complemented by extensions to the RPL routing protocol in
	[I-D.ietf-roll-nsa-extension]. Reliability measures are for example
	achieved by exploiting concepts such as Replication and Elimination.
	In them, packets at origin are replicated and transmitted along
	disjoint tracks. This redundancy measure exploiting track forwarding
	increases energy consumption of the network nodes but improves
	significantly the reliability of the network.
	Useful References include:		Useful References include:
	1. IEEE Std 802.15.4: "IEEE Std. 802.15.4, Part. 15.4: Wireless		1. IEEE Std 802.15.4: "IEEE Std. 802.15.4, Part. 15.4: Wireless
	Medium Access Control (MAC) and Physical Layer (PHY)		Medium Access Control (MAC) and Physical Layer (PHY)
	Specifications for Low-Rate Wireless Personal Area Networks"		Specifications for Low-Rate Wireless Personal Area Networks"
	[IEEE802154]. The latest version at the time of this writing is		[IEEE802154]. The latest version at the time of this writing is
	dated year 2015.		dated year 2015.
	2. Morell, A. , Vilajosana, X. , Vicario, J. L. and Watteyne, T.		2. Morell, A. , Vilajosana, X. , Vicario, J. L. and Watteyne, T.
	skipping to change at page 14, line 40 ¶		skipping to change at page 15, line 11 ¶
	J. Pister, "6TiSCH: Industrial Performance for IPv6 Internet-		J. Pister, "6TiSCH: Industrial Performance for IPv6 Internet-
	of-Things Networks," in Proceedings of the IEEE, vol. 107, no.		of-Things Networks," in Proceedings of the IEEE, vol. 107, no.
	6, pp. 1153-1165, June 2019. [vilajosana19].		6, pp. 1153-1165, June 2019. [vilajosana19].
	4.2.2. TimeSlotted Channel Hopping		4.2.2. TimeSlotted Channel Hopping
	4.2.2.1. General Characteristics		4.2.2.1. General Characteristics
	As a core technique in IEEE802.15.4, TSCH splits time in multiple		As a core technique in IEEE802.15.4, TSCH splits time in multiple
	time slots that repeat over time. The structure is referred as a		time slots that repeat over time. The structure is referred as a
	Slotframe. For each timeslot, a set of available frequencies can be		Slotframe (see Section 4.2.2.2.1.4). For each timeslot, a set of
	used, resulting in a matrix-like schedule (see Fig. Figure 1).		available frequencies can be used, resulting in a matrix-like
			schedule (see Fig. Figure 1).
	timeslot offset		timeslot offset
	| 0 1 2 3 4 | 0 1 2 3 4 | Nodes		| 0 1 2 3 4 | 0 1 2 3 4 | Nodes
	+------------------------+------------------------+ +-----+		+------------------------+------------------------+ +-----+
	| | | | | | | | | | | | C |		| | | | | | | | | | | | C |
	CH-1 | EB | | |C->B| | EB | | |C->B| | | |		CH-1 | EB | | |C->B| | EB | | |C->B| | | |
	| | | | | | | | | | | +-----+		| | | | | | | | | | | +-----+
	+-------------------------------------------------+ |		+-------------------------------------------------+ |
	| | | | | | | | | | | |		| | | | | | | | | | | |
	CH-2 | | |B->C| |B->A| | |B->C| |B->A| +-----+		CH-2 | | |B->C| |B->A| | |B->C| |B->A| +-----+
	skipping to change at page 16, line 20 ¶		skipping to change at page 16, line 29 ¶
	modulations to trade-off performance to reliability. TSCH networks		modulations to trade-off performance to reliability. TSCH networks
	are organized in mesh topologies and connected to a backbone.		are organized in mesh topologies and connected to a backbone.
	Latency in the mesh network is mainly influenced by propagation		Latency in the mesh network is mainly influenced by propagation
	aspects such as interference. ARQ methods and redundancy techniques		aspects such as interference. ARQ methods and redundancy techniques
	such as replication and elimination should be studied to provide the		such as replication and elimination should be studied to provide the
	needed performance to address deterministic scenarios.		needed performance to address deterministic scenarios.
	4.2.2.2. Applicability to Deterministic Flows		4.2.2.2. Applicability to Deterministic Flows
	Nodes in a TSCH network are tightly synchronized. This enables to		Nodes in a TSCH network are tightly synchronized. This enables to
	build the slotted structure an ensure efficient utilization of		build the slotted structure and ensure efficient utilization of
	resources thranks to proper scheduling policies. Scheduling is a key		resources thanks to proper scheduling policies. Scheduling is a key
	to orchestrate the resources that different nodes in a track or path		to orchestrate the resources that different nodes in a Track or a
	are using. Slotframes can be split in resource blocks reserving the		path are using. Slotframes can be split in resource blocks reserving
	needed capacity to certain needs. Periodic and bursty traffic can be		the needed capacity to certain flows. Periodic and bursty traffic
	handled independently in the schedule, using active and reactive		can be handled independently in the schedule, using active and
	policies and taking advantage of certain cell overprovision. Along a		reactive policies and taking advantage of overprovisionned cells to
	track, resource blocks can be chained so nodes in previous hops		measu reth excursion. Along a Track, resource blocks can be chained
	transmit their data before those that come later. This provides a		so nodes in previous hops transmit their data before the next packet
	tight control to latency along a track. Redundancy is achieved in a		comes. This provides a tight control to latency along a Track.
	best effort manner by overprovision, giving time to the management		Collision loss is avoided for best effort traffic by
	plane of the network to request more resources if needed. -time		overprovisionning resources, giving time to the management plane of
	synchronization - scheduling capabilities, discuss such things as		the network to dedicate more resources if needed.
	Resource Units, time slots or resource blocks. Can we reserve
	periodic resources vs. ask each time, what precision can we get in		4.2.2.2.1. Centralized Path Computation
	latency control. - diversity scenarios, what's available, - gap
	analysis, e.g. discuss multihop, or what's missing how to do PAREO		In a controlled environment, a 6TiSCH device usually does not place a
	features.		request for bandwidth between itself and another device in the
			network. Rather, an Operation Control System (OCS) invoked through
			an Human/Machine Interface (HMI) iprovides the Traffic Specification,
			in particular in terms of latency and reliability, and the end nodes,
			to a PCE. With this, the PCE computes a Track between the end nodes
			and provisions every hop in the Track with per-flow state that
			describes the per-hop operation for a given packet, the corresponding
			timeSlots, and the flow identification to recognize which packet is
			placed in which Track, sort out duplicates, etc...
			For a static configuration that serves a certain purpose for a long
			period of time, it is expected that a node will be provisioned in one
			shot with a full schedule, which incorporates the aggregation of its
			behavior for multiple Tracks. The 6TiSCH Architecture expects that
			the programing of the schedule is done over COAP as discussed in
			"6TiSCH Resource Management and Interaction using CoAP"
			[I-D.ietf-6tisch-coap].
			But an Hybrid mode may be required as well whereby a single Track is
			added, modified, or removed, for instance if it appears that a Track
			does not perform as expected for, say, PDR. For that case, the
			expectation is that a protocol that flows along a Track (to be), in a
			fashion similar to classical Traffic Engineering (TE) [CCAMP], may be
			used to update the state in the devices. 6TiSCH provides means for a
			device to negotiate a timeSlot with a neighbor, but in general that
			flow was not designed and no protocol was selected and it is expected
			that DetNet will determine the appropriate end-to-end protocols to be
			used in that case.
			Stream Management Entity
			Operational System and HMI
			-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
			PCE PCE PCE PCE
			-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
			--- 6TiSCH------6TiSCH------6TiSCH------6TiSCH--
			6TiSCH / Device Device Device Device \
			Device- - 6TiSCH
			\ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device
			----Device------Device------Device------Device--
			Figure 2
			4.2.2.2.1.1. Packet Marking and Handling
			Section "Packet Marking and Handling" of
			[I-D.ietf-6tisch-architecture] describes the packet tagging and
			marking that is expected in 6TiSCH networks.
			4.2.2.2.1.1.1. Tagging Packets for Flow Identification
			For packets that are routed by a PCE along a Track, the tuple formed
			by the IPv6 source address and a local RPLInstanceID is tagged in the
			packets to identify uniquely the Track and associated transmit bundle
			of timeSlots.
			It results that the tagging that is used for a DetNet flow outside
			the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the
			packet enters and then leaves the 6TiSCH network.
			Note: The method and format used for encoding the RPLInstanceID at
			6lo is generalized to all 6TiSCH topological Instances, which
			includes Tracks.
			4.2.2.2.1.1.2. Replication, Retries and Elimination
			6TiSCH expects elimination and replication of packets along a complex
			Track, but has no position about how the sequence numbers would be
			tagged in the packet.
			As it goes, 6TiSCH expects that timeSlots corresponding to copies of
			a same packet along a Track are correlated by configuration, and does
			not need to process the sequence numbers.
			The semantics of the configuration MUST enable correlated timeSlots
			to be grouped for transmit (and respectively receive) with a 'OR'
			relations, and then a 'AND' relation MUST be configurable between
			groups. The semantics is that if the transmit (and respectively
			receive) operation succeeded in one timeSlot in a 'OR' group, then
			all the other timeSLots in the group are ignored. Now, if there are
			at least two groups, the 'AND' relation between the groups indicates
			that one operation must succeed in each of the groups.
			On the transmit side, timeSlots provisioned for retries along a same
			branch of a Track are placed a same 'OR' group. The 'OR' relation
			indicates that if a transmission is acknowledged, then further
			transmissions SHOULD NOT be attempted for timeSlots in that group.
			There are as many 'OR' groups as there are branches of the Track
			departing from this node. Different 'OR' groups are programmed for
			the purpose of replication, each group corresponding to one branch of
			the Track. The 'AND' relation between the groups indicates that
			transmission over any of branches MUST be attempted regardless of
			whether a transmission succeeded in another branch. It is also
			possible to place cells to different next-hop routers in a same 'OR'
			group. This allows to route along multi-path Tracks, trying one
			next-hop and then another only if sending to the first fails.
			On the receive side, all timeSlots are programmed in a same 'OR'
			group. Retries of a same copy as well as converging branches for
			elimination are converged, meaning that the first successful
			reception is enough and that all the other timeSlots can be ignored.
			4.2.2.2.1.1.3. Differentiated Services Per-Hop-Behavior
			Additionally, an IP packet that is sent along a Track uses the
			Differentiated Services Per-Hop-Behavior Group called Deterministic
			Forwarding, as described in
			[I-D.svshah-tsvwg-deterministic-forwarding].
			4.2.2.2.1.2. Topology and capabilities
			6TiSCH nodes are usually IoT devices, characterized by very limited
			amount of memory, just enough buffers to store one or a few IPv6
			packets, and limited bandwidth between peers. It results that a node
			will maintain only a small number of peering information, and will
			not be able to store many packets waiting to be forwarded. Peers can
			be identified through MAC or IPv6 addresses.
			Neighbors can be discovered over the radio using mechanism such as
			beacons, but, though the neighbor information is available in the
			6TiSCH interface data model, 6TiSCH does not describe a protocol to
			pro-actively push the neighborhood information to a PCE. This
			protocol should be described and should operate over CoAP. The
			protocol should be able to carry multiple metrics, in particular the
			same metrics as used for RPL operations [RFC6551]
			The energy that the device consumes in sleep, transmit and receive
			modes can be evaluated and reported. So can the amount of energy
			that is stored in the device and the power that it can be scavenged
			from the environment. The PCE SHOULD be able to compute Tracks that
			will implement policies on how the energy is consumed, for instance
			balance between nodes, ensure that the spent energy does not exceeded
			the scavenged energy over a period of time, etc...
			4.2.2.2.1.3. Schedule Management by a PCE
			6TiSCH supports a mixed model of centralized routes and distributed
			routes. Centralized routes can for example be computed by a entity
			such as a Path Computation element (PCE) [PCE]. Distributed routes
			are computed by RPL [RFC6550].
			Both methods may inject routes in the Routing Tables of the 6TiSCH
			routers. In either case, each route is associated with a 6TiSCH
			topology that can be a RPL Instance topology or a Track. The 6TiSCH
			topology is indexed by a Instance ID, in a format that reuses the
			RPLInstanceID as defined in RPL.
			Both RPL and PCE rely on shared sources such as policies to define
			Global and Local RPLInstanceIDs that can be used by either method.
			It is possible for centralized and distributed routing to share a
			same topology. Generally they will operate in different slotFrames,
			and centralized routes will be used for scheduled traffic and will
			have precedence over distributed routes in case of conflict between
			the slotFrames.
			4.2.2.2.1.4. SlotFrames and Priorities
			A slotFrame is the base object that a PCE needs to manipulate to
			program a schedule into an LLN node. Elaboration on that concept can
			be fond in section "SlotFrames and Priorities" of
			[I-D.ietf-6tisch-architecture]
			IEEE802.15.4 TSCH avoids contention on the medium by formatting time
			and frequencies in cells of transmission of equal duration. In order
			to describe that formatting of time and frequencies, the 6TiSCH
			architecture defines a global concept that is called a Channel
			Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of
			cells with an height equal to the number of available channels
			(indexed by ChannelOffsets) and a width (in timeSlots) that is the
			period of the network scheduling operation (indexed by slotOffsets)
			for that CDU matrix. The size of a cell is a timeSlot duration, and
			values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to
			accommodate for the transmission of a frame and an ack, including the
			security validation on the receive side which may take up to a few
			milliseconds on some device architecture.
			The frequency used by a cell in the matrix rotates in a pseudo-random
			fashion, from an initial position at an epoch time, as the matrix
			iterates over and over.
			A CDU matrix is computed by the PCE, but unallocated timeSlots may be
			used opportunistically by the nodes for classical best effort IP
			traffic. The PCE has precedence in the allocation in case of a
			conflict.
			In a given network, there might be multiple CDU matrices that operate
			with different width, so they have different durations and represent
			different periodic operations. It is recommended that all CDU
			matrices in a 6TiSCH domain operate with the same cell duration and
			are aligned, so as to reduce the chances of interferences from
			slotted-aloha operations. The PCE MUST compute the CDU matrices and
			shared that knowledge with all the nodes. The matrices are used in
			particular to define slotFrames.
			A slotFrame is a MAC-level abstraction that is common to all nodes
			and contains a series of timeSlots of equal length and precedence.
			It is characterized by a slotFrame_ID, and a slotFrame_size. A
			slotFrame aligns to a CDU matrix for its parameters, such as number
			and duration of timeSlots.
			Multiple slotFrames can coexist in a node schedule, i.e., a node can
			have multiple activities scheduled in different slotFrames, based on
			the precedence of the 6TiSCH topologies. The slotFrames may be
			aligned to different CDU matrices and thus have different width.
			There is typically one slotFrame for scheduled traffic that has the
			highest precedence and one or more slotFrame(s) for RPL traffic. The
			timeSlots in the slotFrame are indexed by the SlotOffset; the first
			cell is at SlotOffset 0.
			The 6TiSCH architecture introduces the concept of chunks
			([I-D.ietf-6tisch-architecture]) to operate such spectrum
			distribution for a whole group of cells at a time. The CDU matrix is
			formatted into a set of chunks, each of them identified uniquely by a
			chunk-ID. The PCE MUST compute the partitioning of CDU matrices into
			chunks and shared that knowledge with all the nodes in a 6TiSCH
			network.
			+-----+-----+-----+-----+-----+-----+-----+ +-----+
			chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|
			+-----+-----+-----+-----+-----+-----+-----+ +-----+
			chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|
			+-----+-----+-----+-----+-----+-----+-----+ +-----+
			...
			+-----+-----+-----+-----+-----+-----+-----+ +-----+
			chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|
			+-----+-----+-----+-----+-----+-----+-----+ +-----+
			0 1 2 3 4 5 6 M
			Figure 3: CDU matrix Partitioning in Chunks
			The appropriation of a chunk can be requested explicitly by the PCE
			to any node. After a successful appropriation, the PCE owns the
			cells in that chunk, and may use them as hard cells to set up Tracks.
			Then again, 6TiSCH did not propose a method for chunk definition and
			a protocol for appropriation. This is to be done at PAW.
			4.2.2.2.2. 6TiSCH Tracks
			A Track at 6TiSCH is the application to wireless of the concept of a
			path in the Detnet architecture [I-D.ietf-detnet-architecture]. A
			Track can follow a simple sequence of relay nodes or can be
			structured as a more complex destination oriented directed acyclic
			graph (DODAG) to a unicast destination. Along a Track, 6TiSCH nodes
			reserve the resources to enable the efficient transmission of packets
			while aiming to optimize certain properties such as reliability and
			ensure small jitter or bounded latency. The Track structure enables
			Layer-2 forwarding schemes, reducing the overhead of taking routing
			decisions at the Layer-3.
			Serial Tracks can be understood as the concatenation of cells or
			bundles along a routing path from a node towards a destination. The
			serial Track concept is analogous to the circuit concept where
			resources are chained through the multi-hop topology. For example, A
			bundle of Tx Cells in a particular node is paired to a bundle of Rx
			Cells in the next hop node following a routing path.
			whereas scheduling ensures reliable delivery in bounded time along
			any Track, high availability requires the application of PAREO
			functions along a more complex DODAG Track structure. A DODAG has
			forking and joining nodes where the concepts such as Replication and
			Elimination can be exploited. Spatial redundancy increases the
			oveall energy consumption in the network but improves significantly
			the availability of the network as well as the packet delivery ratio.
			A Track may also branch off and rejoin, for the purpose of the so-
			called Packet Replication and Elimination (PRE), over non congruent
			branches. PRE may be used to complement layer-2 Automatic Repeat
			reQuest (ARQ) and and receiver-end Ordering to form the PAREO
			functions. PAREO functions enable to meet industrial expectations in
			Packet Delivery Ratio (PDR) within bounded delivery time over a Track
			that includes wireless links, even when the Track extends beyond the
			6TiSCH network.
			+-----+
			| IoT |
			| G/W |
			+-----+
			^ <---- Elimination
			| |
			Track branch | |
			+-------+ +--------+ Subnet Backbone
			| |
			+--|--+ +--|--+
			| | | Backbone | | | Backbone
			o | | | router | | | router
			+--/--+ +--|--+
			o / o o---o----/ o
			o o---o--/ o o o o o
			o \ / o o LLN o
			o v <---- Replication
			o
			Figure 4: End-to-End deterministic Track
			In the example above, a Track is laid out from a field device in a
			6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN
			backbone.
			The Replication function in the field device sends a copy of each
			packet over two different branches, and a PCE schedules each hop of
			both branches so that the two copies arrive in due time at the
			gateway. In case of a loss on one branch, hopefully the other copy
			of the packet still makes it in due time. If two copies make it to
			the IoT gateway, the Elimination function in the gateway ignores the
			extra packet and presents only one copy to upper layers.
			At each 6TiSCH hop along the Track, the PCE may schedule more than
			one timeSlot for a packet, so as to support Layer-2 retries (ARQ).
			It is also possible that the field device only uses the second branch
			if sending over the first branch fails.
			In current deployments, a TSCH Track does not necessarily support PRE
			but is systematically multi-path. This means that a Track is
			scheduled so as to ensure that each hop has at least two forwarding
			solutions, and the forwarding decision is to try the preferred one
			and use the other in case of Layer-2 transmission failure as detected
			by ARQ.
			Methods to implement complex Tracks are described in
			[I-D.papadopoulos-paw-pre-reqs] and complemented by extensions to the
			RPL routing protocol in [I-D.ietf-roll-nsa-extension] for best effort
			traffic, but a centralized routing technique such as promoted in
			DetNet is still missing.
			4.2.2.2.2.1. Track Scheduling Protocol
			Section "Schedule Management Mechanisms" of the 6TiSCH architecture
			describes 4 paradigms to manage the TSCH schedule of the LLN nodes:
			Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring
			and scheduling management, and Hop-by-hop scheduling. The Track
			operation for DetNet corresponds to a remote monitoring and
			scheduling management by a PCE.
			Early work at 6TiSCH on a data model and a protocol to program the
			schedule in the 6TiSCH device was never concluded as the group
			focussed on best effort traffic. This work would be revived by PAW:
			The 6top interface document [RFC8480] (to be reopened at PAW) was
			intended to specify the generic data model that can be used to
			monitor and manage resources of the 6top sublayer. Abstract
			methods were suggested for use by a management entity in the
			device. The data model also enables remote control operations on
			the 6top sublayer.
			[I-D.ietf-6tisch-coap] (to be reopened at RAW) was intended to
			define a mapping of the 6top set of commands, which is described
			in RFC 8480, to CoAP resources. This allows an entity to interact
			with the 6top layer of a node that is multiple hops away in a
			RESTful fashion.
			[I-D.ietf-6tisch-coap] also defined a basic set CoAP resources and
			associated RESTful access methods (GET/PUT/POST/DELETE). The
			payload (body) of the CoAP messages is encoded using the CBOR
			format. The PCE commands are expected to be issued directly as
			CoAP requests or to be mapped back and forth into CoAP by a
			gateway function at the edge of the 6TiSCH network. For instance,
			it is possible that a mapping entity on the backbone transforms a
			non-CoAP protocol such as PCEP into the RESTful interfaces that
			the 6TiSCH devices support.
			4.2.2.2.2.2. Track Forwarding
			By forwarding, this specification means the per-packet operation that
			allows to deliver a packet to a next hop or an upper layer in this
			node. Forwarding is based on pre-existing state that was installed
			as a result of the routing computation of a Track by a PCE. The
			6TiSCH architecture supports three different forwarding model, G-MPLS
			Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6
			Forwarding (6F) which is the classical IP operation. The DetNet case
			relates to the Track Forwarding operation under the control of a PCE.
			A Track is a unidirectional path between a source and a destination.
			In a Track cell, the normal operation of IEEE802.15.4 Automatic
			Repeat-reQuest (ARQ) usually happens, though the acknowledgment may
			be omitted in some cases, for instance if there is no scheduled cell
			for a retry.
			Track Forwarding is the simplest and fastest. A bundle of cells set
			to receive (RX-cells) is uniquely paired to a bundle of cells that
			are set to transmit (TX-cells), representing a layer-2 forwarding
			state that can be used regardless of the network layer protocol.
			This model can effectively be seen as a Generalized Multi-protocol
			Label Switching (G-MPLS) operation in that the information used to
			switch a frame is not an explicit label, but rather related to other
			properties of the way the packet was received, a particular cell in
			the case of 6TiSCH. As a result, as long as the TSCH MAC (and
			Layer-2 security) accepts a frame, that frame can be switched
			regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN
			fragment, or a frame from an alternate protocol such as WirelessHART
			or ISA100.11a.
			A data frame that is forwarded along a Track normally has a
			destination MAC address that is set to broadcast - or a multicast
			address depending on MAC support. This way, the MAC layer in the
			intermediate nodes accepts the incoming frame and 6top switches it
			without incurring a change in the MAC header. In the case of
			IEEE802.15.4, this means effectively broadcast, so that along the
			Track the short address for the destination of the frame is set to
			0xFFFF.
			A Track is thus formed end-to-end as a succession of paired bundles,
			a receive bundle from the previous hop and a transmit bundle to the
			next hop along the Track, and a cell in such a bundle belongs to at
			most one Track. For a given iteration of the device schedule, the
			effective channel of the cell is obtained by adding a pseudo-random
			number to the channelOffset of the cell, which results in a rotation
			of the frequency that used for transmission. The bundles may be
			computed so as to accommodate both variable rates and
			retransmissions, so they might not be fully used at a given iteration
			of the schedule. The 6TiSCH architecture provides additional means
			to avoid waste of cells as well as overflows in the transmit bundle,
			as follows:
			In one hand, a TX-cell that is not needed for the current iteration
			may be reused opportunistically on a per-hop basis for routed
			packets. When all of the frame that were received for a given Track
			are effectively transmitted, any available TX-cell for that Track can
			be reused for upper layer traffic for which the next-hop router
			matches the next hop along the Track. In that case, the cell that is
			being used is effectively a TX-cell from the Track, but the short
			address for the destination is that of the next-hop router. It
			results that a frame that is received in a RX-cell of a Track with a
			destination MAC address set to this node as opposed to broadcast must
			be extracted from the Track and delivered to the upper layer (a frame
			with an unrecognized MAC address is dropped at the lower MAC layer
			and thus is not received at the 6top sublayer).
			On the other hand, it might happen that there are not enough TX-cells
			in the transmit bundle to accommodate the Track traffic, for instance
			if more retransmissions are needed than provisioned. In that case,
			the frame can be placed for transmission in the bundle that is used
			for layer-3 traffic towards the next hop along the Track as long as
			it can be routed by the upper layer, that is, typically, if the frame
			transports an IPv6 packet. The MAC address should be set to the
			next-hop MAC address to avoid confusion. It results that a frame
			that is received over a layer-3 bundle may be in fact associated to a
			Track. In a classical IP link such as an Ethernet, off-Track traffic
			is typically in excess over reservation to be routed along the non-
			reserved path based on its QoS setting. But with 6TiSCH, since the
			use of the layer-3 bundle may be due to transmission failures, it
			makes sense for the receiver to recognize a frame that should be re-
			Tracked, and to place it back on the appropriate bundle if possible.
			A frame should be re-Tracked if the Per-Hop-Behavior group indicated
			in the Differentiated Services Field in the IPv6 header is set to
			Deterministic Forwarding, as discussed in Section 4.2.2.2.1.1. A
			frame is re-Tracked by scheduling it for transmission over the
			transmit bundle associated to the Track, with the destination MAC
			address set to broadcast.
			There are 2 modes for a Track, transport mode and tunnel mode.
			4.2.2.2.2.2.1. Transport Mode
			In transport mode, the Protocol Data Unit (PDU) is associated with
			flow-dependant meta-data that refers uniquely to the Track, so the
			6top sublayer can place the frame in the appropriate cell without
			ambiguity. In the case of IPv6 traffic, this flow identification is
			transported in the Flow Label of the IPv6 header. Associated with
			the source IPv6 address, the Flow Label forms a globally unique
			identifier for that particular Track that is validated at egress
			before restoring the destination MAC address (DMAC) and punting to
			the upper layer.
			| ^
			+--------------+ | |
			| IPv6 | | |
			+--------------+ | |
			| 6LoWPAN HC | | |
			+--------------+ ingress egress
			| 6top | sets +----+ +----+ restores
			+--------------+ dmac to | | | | dmac to
			| TSCH MAC | brdcst | | | | self
			+--------------+ | | | | | |
			| LLN PHY | +-------+ +--...-----+ +-------+
			+--------------+
			Track Forwarding, Transport Mode
			4.2.2.2.2.2.2. Tunnel Mode
			In tunnel mode, the frames originate from an arbitrary protocol over
			a compatible MAC that may or may not be synchronized with the 6TiSCH
			network. An example of this would be a router with a dual radio that
			is capable of receiving and sending WirelessHART or ISA100.11a frames
			with the second radio, by presenting itself as an Access Point or a
			Backbone Router, respectively.
			In that mode, some entity (e.g. PCE) can coordinate with a
			WirelessHART Network Manager or an ISA100.11a System Manager to
			specify the flows that are to be transported transparently over the
			Track.
			+--------------+
			| IPv6 |
			+--------------+
			| 6LoWPAN HC |
			+--------------+ set restore
			| 6top | +dmac+ +dmac+
			+--------------+ to|brdcst to|nexthop
			| TSCH MAC | | | | |
			+--------------+ | | | |
			| LLN PHY | +-------+ +--...-----+ +-------+
			+--------------+ | ingress egress |
			| |
			+--------------+ | |
			| LLN PHY | | |
			+--------------+ | |
			| TSCH MAC | | |
			+--------------+ | dmac = | dmac =
			|ISA100/WiHART | | nexthop v nexthop
			+--------------+
			Figure 5: Track Forwarding, Tunnel Mode
			In that case, the flow information that identifies the Track at the
			ingress 6TiSCH router is derived from the RX-cell. The dmac is set
			to this node but the flow information indicates that the frame must
			be tunneled over a particular Track so the frame is not passed to the
			upper layer. Instead, the dmac is forced to broadcast and the frame
			is passed to the 6top sublayer for switching.
			At the egress 6TiSCH router, the reverse operation occurs. Based on
			metadata associated to the Track, the frame is passed to the
			appropriate link layer with the destination MAC restored.
			4.2.2.2.2.2.3. Tunnel Metadata
			Metadata coming with the Track configuration is expected to provide
			the destination MAC address of the egress endpoint as well as the
			tunnel mode and specific data depending on the mode, for instance a
			service access point for frame delivery at egress. If the tunnel
			egress point does not have a MAC address that matches the
			configuration, the Track installation fails.
			In transport mode, if the final layer-3 destination is the tunnel
			termination, then it is possible that the IPv6 address of the
			destination is compressed at the 6LoWPAN sublayer based on the MAC
			address. It is thus mandatory at the ingress point to validate that
			the MAC address that was used at the 6LoWPAN sublayer for compression
			matches that of the tunnel egress point. For that reason, the node
			that injects a packet on a Track checks that the destination is
			effectively that of the tunnel egress point before it overwrites it
			to broadcast. The 6top sublayer at the tunnel egress point reverts
			that operation to the MAC address obtained from the tunnel metadata.
			4.2.2.2.2.2.4. OAM
			An Overview of Operations, Administration, and Maintenance (OAM)
			Tools [RFC7276] provides an overwiew of the existing tooling for OAM
			[RFC6291]. Tracks are complex paths and new tooling is necessary to
			manage them, with respect to load control, timing, and the Packet
			Replication and Elimination Functions (PREF).
			An example of such tooling can be found in the context of BIER
			[RFC8279] and more specifically BIER Traffic Engineering
			[I-D.ietf-bier-te-arch] (BIER-TE):
			[I-D.thubert-bier-replication-elimination] leverages BIER-TE to
			control the process of PREF, and to provide traceability of these
			operations, in the deterministic dataplane, along a complex Track.
			For the 6TiSCH type of constrained environment,
			[I-D.thubert-6lo-bier-dispatch] enables an efficient encoding of the
			BIER bitmap within the 6LoRH framework.
	5. 3GPP standards		5. 3GPP standards
	6. IANA Considerations		6. IANA Considerations
	This specification does not require IANA action.		This specification does not require IANA action.
	7. Security Considerations		7. Security Considerations
	Most RAW technologies integrate some authentication or encryption		Most RAW technologies integrate some authentication or encryption
	skipping to change at page 17, line 16 ¶		skipping to change at page 29, line 49 ¶
	Many thanks to the participants of the RAW WG where a lot of the work		Many thanks to the participants of the RAW WG where a lot of the work
	discussed here happened.		discussed here happened.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-21 (work
	in progress), March 2019.		in progress), June 2019.
	[I-D.ietf-detnet-architecture]		[I-D.ietf-detnet-architecture]
	Finn, N., Thubert, P., Varga, B., and J. Farkas,		Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", draft-ietf-		"Deterministic Networking Architecture", draft-ietf-
	detnet-architecture-13 (work in progress), May 2019.		detnet-architecture-13 (work in progress), May 2019.
	[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.		[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
	Phinney, "Industrial Routing Requirements in Low-Power and		Phinney, "Industrial Routing Requirements in Low-Power and
	Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October		Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
	2009, <https://www.rfc-editor.org/info/rfc5673>.		2009, <https://www.rfc-editor.org/info/rfc5673>.
	skipping to change at page 17, line 47 ¶		skipping to change at page 30, line 33 ¶
	<https://www.rfc-editor.org/info/rfc8480>.		<https://www.rfc-editor.org/info/rfc8480>.
	9.2. Informative References		9.2. Informative References
	[Cavalcanti_2019]		[Cavalcanti_2019]
	Dave Cavalcanti et al., "Extending Time Distribution and		Dave Cavalcanti et al., "Extending Time Distribution and
	Timeliness Capabilities over the Air to Enable Future		Timeliness Capabilities over the Air to Enable Future
	Wireless Industrial Automation Systems, the Proceedings of		Wireless Industrial Automation Systems, the Proceedings of
	IEEE", June 2019.		IEEE", June 2019.
			[CCAMP] IETF, "Common Control and Measurement Plane",
			<https://dataTracker.ietf.org/doc/charter-ietf-ccamp/>.
	[dearmas16]		[dearmas16]
	Jesica de Armas et al., "Determinism through path		Jesica de Armas et al., "Determinism through path
	diversity: Why packet replication makes sense", September		diversity: Why packet replication makes sense", September
	2016.		2016.
	[Ghasempour_2017]		[Ghasempour_2017]
	Yasaman Ghasempour et al., "802.11ay: Next-Generation 60		Yasaman Ghasempour et al., "802.11ay: Next-Generation 60
	GHz Communications for 100 Gb/s Wi-Fi", December 2017.		GHz Communications for 100 Gb/s Wi-Fi", December 2017.
			[I-D.ietf-6tisch-coap]
			Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
			Interaction using CoAP", draft-ietf-6tisch-coap-03 (work
			in progress), March 2015.
	[I-D.ietf-6tisch-msf]		[I-D.ietf-6tisch-msf]
	Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and		Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and
	D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)",		D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)",
	draft-ietf-6tisch-msf-03 (work in progress), April 2019.		draft-ietf-6tisch-msf-03 (work in progress), April 2019.
			[I-D.ietf-bier-te-arch]
			Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic
			Engineering for Bit Index Explicit Replication (BIER-TE)",
			draft-ietf-bier-te-arch-02 (work in progress), May 2019.
	[I-D.ietf-roll-nsa-extension]		[I-D.ietf-roll-nsa-extension]
	Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P.		Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P.
	Thubert, "RPL DAG Metric Container Node State and		Thubert, "RPL DAG Metric Container Node State and
	Attribute object type extension", draft-ietf-roll-nsa-		Attribute object type extension", draft-ietf-roll-nsa-
	extension-01 (work in progress), March 2019.		extension-01 (work in progress), March 2019.
			[I-D.papadopoulos-paw-pre-reqs]
			Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P.
			Thubert, "Exploiting Packet Replication and Elimination in
			Complex Tracks in LLNs", draft-papadopoulos-paw-pre-
			reqs-01 (work in progress), March 2019.
			[I-D.svshah-tsvwg-deterministic-forwarding]
			Shah, S. and P. Thubert, "Deterministic Forwarding PHB",
			draft-svshah-tsvwg-deterministic-forwarding-04 (work in
			progress), August 2015.
			[I-D.thubert-6lo-bier-dispatch]
			Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A
			6loRH for BitStrings", draft-thubert-6lo-bier-dispatch-06
			(work in progress), January 2019.
			[I-D.thubert-bier-replication-elimination]
			Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER-
			TE extensions for Packet Replication and Elimination
			Function (PREF) and OAM", draft-thubert-bier-replication-
			elimination-03 (work in progress), March 2018.
	[IEEE80211]		[IEEE80211]
	"IEEE Standard 802.11 - IEEE Standard for Information		"IEEE Standard 802.11 - IEEE Standard for Information
	Technology - Telecommunications and information exchange		Technology - Telecommunications and information exchange
	between systems Local and metropolitan area networks -		between systems Local and metropolitan area networks -
	Specific requirements - Part 11: Wireless LAN Medium		Specific requirements - Part 11: Wireless LAN Medium
	Access Control (MAC) and Physical Layer (PHY)		Access Control (MAC) and Physical Layer (PHY)
	Specifications.".		Specifications.".
	[IEEE80211ad]		[IEEE80211ad]
	"802.11ad: Enhancements for very high throughput in the 60		"802.11ad: Enhancements for very high throughput in the 60
	skipping to change at page 19, line 22 ¶		skipping to change at page 32, line 46 ¶
	Performance Improvements".		Performance Improvements".
	[IEEE_doc_11-18-2009-06]		[IEEE_doc_11-18-2009-06]
	"802.11 Real-Time Applications (RTA) Topic Interest Group		"802.11 Real-Time Applications (RTA) Topic Interest Group
	(TIG) Report", November 2018.		(TIG) Report", November 2018.
	[IEEE_doc_11-19-0373-00]		[IEEE_doc_11-19-0373-00]
	Kevin Stanton et Al., "Time-Sensitive Applications Support		Kevin Stanton et Al., "Time-Sensitive Applications Support
	in EHT", March 2019.		in EHT", March 2019.
			[ISA100.11a]
			ISA/IEC, "ISA100.11a, Wireless Systems for Automation,
			also IEC 62734", 2011, < http://www.isa100wci.org/en-
			US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch-
			WEB-ETSI.aspx>.
	[morell13]		[morell13]
	Antoni Morell et al., "Label switching over IEEE802.15.4e		Antoni Morell et al., "Label switching over IEEE802.15.4e
	networks", April 2013.		networks", April 2013.
	[Nitsche_2015]		[Nitsche_2015]
	Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz		Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz
	communication for multi-Gigabit-per-second Wi-Fi",		communication for multi-Gigabit-per-second Wi-Fi",
	December 2014.		December 2014.
			[PCE] IETF, "Path Computation Element",
			<https://dataTracker.ietf.org/doc/charter-ietf-pce/>.
			[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
			D., and S. Mansfield, "Guidelines for the Use of the "OAM"
			Acronym in the IETF", BCP 161, RFC 6291,
			DOI 10.17487/RFC6291, June 2011,
			<https://www.rfc-editor.org/info/rfc6291>.
			[RFC6550] 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>.
			[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
			and D. Barthel, "Routing Metrics Used for Path Calculation
			in Low-Power and Lossy Networks", RFC 6551,
			DOI 10.17487/RFC6551, March 2012,
			<https://www.rfc-editor.org/info/rfc6551>.
			[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
			Weingarten, "An Overview of Operations, Administration,
			and Maintenance (OAM) Tools", RFC 7276,
			DOI 10.17487/RFC7276, June 2014,
			<https://www.rfc-editor.org/info/rfc7276>.
			[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
			Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
			Explicit Replication (BIER)", RFC 8279,
			DOI 10.17487/RFC8279, November 2017,
			<https://www.rfc-editor.org/info/rfc8279>.
			[TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4",
			<https://dataTracker.ietf.org/doc/charter-ietf-6tisch/>.
	[vilajosana19]		[vilajosana19]
	Xavier Vilajosana et al., "6TiSCH: Industrial Performance		Xavier Vilajosana et al., "6TiSCH: Industrial Performance
	for IPv6 Internet-of-Things Networks", June 2019.		for IPv6 Internet-of-Things Networks", June 2019.
			[WirelessHART]
			www.hartcomm.org, "Industrial Communication Networks -
			Wireless Communication Network and Communication Profiles
			- WirelessHART - IEC 62591", 2010.
	Authors' Addresses		Authors' Addresses
	Pascal Thubert (editor)		Pascal Thubert (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
	Building D		Building D
	45 Allee des Ormes - BP1200		45 Allee des Ormes - BP1200
	MOUGINS - Sophia Antipolis 06254		MOUGINS - Sophia Antipolis 06254
	FRANCE		FRANCE
	Phone: +33 497 23 26 34		Phone: +33 497 23 26 34
End of changes. 26 change blocks.
	114 lines changed or deleted		779 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/