< draft-thubert-6tsch-architecture-00.txt		draft-thubert-6tsch-architecture-01.txt >
	6TSCH P. Thubert, Ed.		6TSCH P. Thubert, Ed.
	Internet-Draft cisco		Internet-Draft cisco
	Intended status: Standards Track RA. Assimiti		Intended status: Standards Track RA. Assimiti
	Expires: September 12, 2013 Nivis		Expires: October 19, 2013 Nivis
	T. Watteyne		T. Watteyne
	Linear Technology / Dust Networks		Linear Technology / Dust Networks
	March 11, 2013		April 19, 2013
	An Architecture for IPv6 over Time Synchronized Channel Hopping		An Architecture for IPv6 over Time Slotted Channel Hopping
	draft-thubert-6tsch-architecture-00		draft-thubert-6tsch-architecture-01
	Abstract		Abstract
	This document presents an architecture for an IPv6 multilink subnet		This document presents an architecture for an IPv6 multilink subnet
	that is composed of a high speed powered backbone and a number of		that is composed of a high speed powered backbone and a number of
	IEEE802.15.4e TSCH wireless networks attached and synchronized by		IEEE802.15.4e TSCH wireless networks attached and synchronized by
	Backbone Routers. Route Computation may be achieved in a centralized		Backbone Routers. Route Computation may be achieved in a centralized
	fashion by a Path Computation Element, in a distributed fashion using		fashion by a Path Computation Element, in a distributed fashion using
	the Routing Protocol for Low Power and Lossy Networks, or in a mixed		the Routing Protocol for Low Power and Lossy Networks, or in a mixed
	mode. The Backbone Routers perform proxy Neighbor discovery		mode. The Backbone Routers perform proxy Neighbor discovery
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	they can share a same subnet and appear to be connected to the same		they can share a same subnet and appear to be connected to the same
	backbone as classical devices.		backbone as classical devices.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC		"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 [RFC2119].		2119 [RFC2119].
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 September 12, 2013.		This Internet-Draft will expire on October 19, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 (http://trustee.ietf.org/
	(http://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . 3		3. Applications and Goals . . . . . . . . . . . . . . . . . . . . 3
	4. Centralized vs. Distributed Routing . . . . . . . . . . . . . 6		4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 4
	5. Functional Flows . . . . . . . . . . . . . . . . . . . . . . 6		5. Centralized vs. Distributed Routing . . . . . . . . . . . . . 7
	6. Network Synchronization . . . . . . . . . . . . . . . . . . . 6		6. Functional Flows . . . . . . . . . . . . . . . . . . . . . . . 7
	7. TSCH and 6TUS . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Network Synchronization . . . . . . . . . . . . . . . . . . . 7
	7.1. 6tus . . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. TSCH and 6TUS . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.2. Slotframes and Priorities . . . . . . . . . . . . . . . . 7		8.1. 6tus . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.3. Centralized Flow Reservation . . . . . . . . . . . . . . 7		8.2. Slotframes and Priorities . . . . . . . . . . . . . . . . 8
	7.4. Distributed Flow Reservation . . . . . . . . . . . . . . 7		8.3. Centralized Flow Reservation . . . . . . . . . . . . . . . 8
	7.5. Packet Marking and Handling . . . . . . . . . . . . . . . 8		8.4. Distributed Flow Reservation . . . . . . . . . . . . . . . 8
	8. Management . . . . . . . . . . . . . . . . . . . . . . . . . 9		8.5. Packet Marking and Handling . . . . . . . . . . . . . . . 9
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		9. Management . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 9		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	12.1. Normative References . . . . . . . . . . . . . . . . . . 9		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	12.2. Informative References . . . . . . . . . . . . . . . . . 10		13.1. Normative References . . . . . . . . . . . . . . . . . . 9
	12.3. External Informative References . . . . . . . . . . . . 11		13.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		13.3. External Informative References . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	A new breed of Time Sensitive Networks is being developped to enable		The emergence of radio technology enabled a large variety of new
	traffic that is highly sensitive to jitter and quite sensitive to		types of devices to be interconnected, at a very low marginal cost
	latency. Such traffic is not limited to voice and video, but also		compared to wire, at any range from Near Field to interplanetary
	includes command and control operations such as found in industrial		distances, and in circumstances where wiring could be less than
	automation or in-vehicule sensors and actuators.		practical, for instance rotating devices.
	At IEEE802.1, the "Audio/Video Task Group", was rename TSN for Time		At the same time, a new breed of Time Sensitive Networks is being
	Sensitive Networking. The IEEE802.15.4 Medium Access Control (MAC)		developped to enable traffic that is highly sensitive to jitter and
	has evolved with IEEE802.15.4e which provides in particular the Time		quite sensitive to latency. Such traffic is not limited to voice and
	Synchronized Channel Hopping (TSCH) mode for industrial-type		video, but also includes command and control operations such as found
	applications. Both provide Deterministic capabities to the point		in industrial automation or in-vehicule sensors and actuators.
	that a packet that pertains to a certain flow will cross the network
	from node to node following a very precise schedule, like a train		At IEEE802.1, the "Audio/Video Task Group", was renamed TSN for Time
	leaves intermediate stations at precise times along its path. The		Sensitive Networking to address Deterministic Ethernet. The
	time slotted aspect reduce collisions, and saves energy. The channel		IEEE802.15.4 Medium Access Control MAC) has evolved with
	hopping aspect is a simple and efficient technique to get around		IEEE802.15.4e that provides in particular the Time Slotted Channel
	statistical interference by WIFI emitters.		Hopping (TSCH) mode for industrial-type applications.
			Though at a different time scale, both standards provide
			Deterministic capabilities to the point that a packet that pertains
			to a certain flow will cross the network from node to node following
			a very precise schedule, like a train leaves intermediate stations at
			precise times along its path. The time slotted aspect reduces
			collisions, and saves energy, and enables to more closely engineer
			the network for deterministic properties. The channel hopping aspect
			is a simple and efficient technique to get around statistical
			interference by WIFI emitters.
	This document presents an architecture for an IPv6 multilink subnet		This document presents an architecture for an IPv6 multilink subnet
	that is composed of a high speed powered backbone and a number of		that is composed of a high speed powered backbone and a number of
	IEEE802.15.4e TSCH wireless networks attached and synchronized by		IEEE802.15.4e TSCH wireless networks attached and synchronized by
	backbone routers. Route Computation may be achieved in a centralized		backbone routers. Route Computation may be achieved in a centralized
	fashion by a Path Computation Element (PCE), in a distributed fashion		fashion by a Path Computation Entity (PCE), in a distributed fashion
	using the Routing Protocol for Low Power and Lossy Networks (RPL), or		using the Routing Protocol for Low Power and Lossy Networks (RPL), or
	in a mixed mode. The Backbone Routers perform proxy Ipv6 Neighbor		in a mixed mode. The Backbone Routers perform proxy Ipv6 Neighbor
	Discovery (ND) operations over the backbone on behalf of the wireless		Discovery (ND) operations over the backbone on behalf of the wireless
	device, so they can share a same IPv6 subnet and appear to be		device, so they can share a same IPv6 subnet and appear to be
	connected to the same backbone as classical devices.		connected to the same backbone as classical devices.
	2. Terminology		2. Terminology
	The draft uses terminology defined in		The draft uses terminology defined in [I-D.palattella-6tsch-
	[I-D.palattella-6tsch-terminology],		terminology], [I-D.chakrabarti-nordmark-6man-efficient-nd], [RFC5191]
	[I-D.chakrabarti-nordmark-6man-efficient-nd], [RFC5191] and		and [RFC4080].
	[RFC4080].
	It conforms to the terms and models described for IPv6 in [RFC5889]		It conforms to the terms and models described for IPv6 in [RFC5889]
	and uses the vocabulary and the concepts defined in [RFC4291] for		and uses the vocabulary and the concepts defined in [RFC4291] for
	IPv6.		IPv6.
	3. Overview and Scope		3. Applications and Goals
			The architecture derives from existing industrial standards for
			Process Control by its focus on Deterministic Networking, in
			particular with the use of the IEEE802.15.4e TSCH MAC and the
			centralized path computation entity. This approach leverages the
			TSCH MAC benefits for high reliability against interferences, low-
			power consumption on deterministic traffic, and its Traffic
			Engineering capabilities. Deterministic Networking applies in
			particular to open and close control loops, as well as supervisory
			control flows, and management.
			Additional industrial use cases are addressed with the addition of a
			more autonomic and distributed routing based on RPL. These use cases
			include plant setup and decommissioning, as well as monitoring of
			lots of lesser importance measurements such as corrosion and events.
			RPL also enables mobile use cases such as mobile workers and cranes.
			A Backbone Router is included in order to scale the factory plant
			subnet to address large deployments, with proxy ND and time
			synchronization over a high speed backbone.
			The architecture also applies to building automation that leverage
			RPL's storing mode to address multipath over a large number of hops,
			in-vehicule command and control that can be as demanding as
			industrial applications, commercial automation and asset tracking
			with mobile scenarios, home automation and domotics which become more
			reliable and thus provide a better user experience, and resource
			management (energy, water, etc...).
			4. Overview and Scope
	The scope of the present work is a subnet that, in its basic		The scope of the present work is a subnet that, in its basic
	configuration, is made of a IEEE802.15.4e Time Synchronized Channel		configuration, is made of a IEEE802.15.4e Time Slotted Channel
	Hopping (TSCH) [I-D.watteyne-6tsch-tsch-lln-context] MAC Route-Over		Hopping (TSCH) [I-D.watteyne-6tsch-tsch-lln-context] MAC Route-Over
	Low Power Lossy Network (LLN).		Low Power Lossy Network (LLN).
	+-----+		+-----+
	| | LLN Border		| | LLN Border
	| | router		| | router
	+-----+		+-----+
	o o o		o o o
	o o o o		o o o o
	o o LLN o o o		o o LLN o o o
	o o o o		o o o o
	o		o
	Figure 1: Basic Configuration
	The LLN devices communicate over IPv6 [RFC2460] using the 6LoWPAN		The LLN devices communicate over IPv6 [RFC2460] using the 6LoWPAN
	Header Compression (6LoWPAN HC) [RFC6282]. Neighbor Devices are		Header Compression (6LoWPAN HC) [RFC6282]. Neighbor Devices are
	discovered with 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775] and		discovered with 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775] and
	the Routing Protocol for Low Power and Lossy Networks (RPL) [RFC6550]		the Routing Protocol for Low Power and Lossy Networks (RPL)
	enables routing within the LLN. RPL forms Destination Oriented		[RFC6550] enables routing within the LLN. RPL forms Destination
	Directed Acyclic Graphs (DODAGs) within instances of the protocol,		Oriented Directed Acyclic Graphs (DODAGs) within instances of the
	each instance being associated with an Objective Function (OF) to		protocol, each instance being associated with an Objective Function
	form a routing topology. A particular LLN device, usually powered,		(OF) to form a routing topology. A particular LLN device, usually
	acts as RPL root, 6LoWPAN HC terminator, and LLN Border Router (LBR)		powered, acts as RPL root, 6LoWPAN HC terminator, and LLN Border
	to the outside.		Router (LBR) to the outside.
	An extended configuration of the subnet comprises multiple LLNs. The		An extended configuration of the subnet comprises multiple LLNs. The
	LLNs are interconnected and synchronized over a backbone, that can be		LLNs are interconnected and synchronized over a backbone, that can be
	wired or wireless. The backbone can be a classical IPv6 network,		wired or wireless. The backbone can be a classical IPv6 network,
	with Neighbor Discovery operating as defined in [RFC4861] and		with Neighbor Discovery operating as defined in [RFC4861] and
	[RFC4862]. The backbone can also support Efficiency aware IPv6		[RFC4862]. The backbone can also support Efficiency aware IPv6
	Neighbor Discovery Optimizations		Neighbor Discovery Optimizations [I-D.chakrabarti-nordmark-6man-
	[I-D.chakrabarti-nordmark-6man-efficient-nd] in mixed mode as		efficient-nd] in mixed mode as described in [I-D.thubert-6lowpan-
	described in [I-D.thubert-6lowpan-backbone-router].		backbone-router].
	Security is often handled at layer 2 and Layer 4. Authentication		Security is often handled at layer 2 and Layer 4. Authentication
	during the join process is handled with the Protocol for Carrying		during the join process is handled with the Protocol for Carrying
	Authentication for Network Access (PANA) [RFC5191].		Authentication for Network Access (PANA) [RFC5191].
	The LLN devices are time-synchronized at MAC level. The MAC		The LLN devices are time-synchronized at MAC level. The MAC
	coordinator that serves as time source through Enhanced Beacons (EB)		coordinator that serves as time source through Enhanced Beacons (EB)
	is loosely coupled with the RPL parent; this way, the time		is loosely coupled with the RPL parent; this way, the time
	synchronization starts at the RPL root and follows the RPL DODAGs		synchronization starts at the RPL root and follows the RPL DODAGs
	with no timing loop.		with no timing loop.
	In the extended configuration, the functionality of the LBR is		In the extended configuration, the functionality of the LBR is
	enhanced to that of Backbone Router (BBR). A BBR is an LBR, but also		enhanced to that of Backbone Router (BBR). A BBR is an LBR, but also
	an Energy Aware Default Router (NEAR) as defined in		an Energy Aware Default Router (NEAR) as defined in [I-D.chakrabarti-
	[I-D.chakrabarti-nordmark-6man-efficient-nd]. The BBR performs ND		nordmark-6man-efficient-nd]. The BBR performs ND proxy operations
	proxy operations between the registered devices and the classical ND		between the registered devices and the classical ND devices that are
	devices that are located over the backbone. 6TSCH BBRs synchronize		located over the backbone. 6TSCH BBRs synchronize with one another
	with one another over the backbone, so as to ensure that the multiple		over the backbone, so as to ensure that the multiple LLNs that form
	LLNs that form the IPv6 subnet stay tightly synchronized. If the		the IPv6 subnet stay tightly synchronized. If the Backbone is
	Backbone is Deterministic (such as defined by the Time Sensitive		Deterministic (such as defined by the Time Sensitive Networking WG at
	Networking WG at IEEE), then the Backbone Router ensures that the		IEEE), then the Backbone Router ensures that the end-to-end
	end-to-end deterministic behavior is maintained between the LLN and		deterministic behavior is maintained between the LLN and the
	the backbone.		backbone.
	---+------------------------		---+------------------------
	| External Network		| External Network
	|		|
	+-----+ +-----+		+-----+ +-----+
	| | Router | | PCE		| | Router | | PCE
	| | | |		| | | |
	+-----+ +-----+		+-----+ +-----+
	| |		| |
	| Subnet Backbone |		| Subnet Backbone |
	skipping to change at page 5, line 25 ¶		skipping to change at page 6, line 25 ¶
	| | |		| | |
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	| | Backbone | | Backbone | | Backbone		| | Backbone | | Backbone | | Backbone
	o | | router | | router | | router		o | | router | | router | | router
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	o o o o o		o o o o o
	o o o o o o o o o o o		o o o o o o o o o o o
	o o o LLN o o o o		o o o LLN o o o o
	o o o o o o o o o o o o		o o o o o o o o o o o o
	Figure 2: Extended Configuration		The main architectural blocks are arranged as follows:
	The main architactural blocks are arranged as follows:
	+-----+-----+-----+-----+-----+--------+		+-----+-----+-----+-----+-------+-----+
	|PANA | RPL |RSVP | PCE | IP |		|PCEP | CoAP |PANA |6LoWPAN| RPL |
	| | |/NSIS| /CNM|/ FORWARDING |		| PCC |DTLS | | | ND | |
	+-----+-----+-----+-----+--------+-----+-------+		+-----+-----+-----+-----+-------+-----+-----+
	| 6LoWPAN | 6LoWPAN ND |		| TCP | UDP | ICMP |RSVP |
	| HC +-------------+		+-----+-----+-----+-----+-------+-----+-----+
	| |		| IPv6 |
	+----------------------------------------------+		+-------------------------------------------+
	| 6TUS |		| 6LoWPAN HC |
	+----------------------------------------------+		+-------------------------------------------+
	| 802.15.4e TSCH |		| 6TUS |
	+----------------------------------------------+		+-------------------------------------------+
			| 802.15.4e TSCH |
			+-------------------------------------------+
	Figure 3: 6TSCH stack		RPL is the routing protocol of choice for LLNs. (TBD RPL) whether
			there is a need to define a 6TSCH OF.
	RPL is the routing protocol of choice. TBD whether there is a need		(tbd NME) COMAN is working on network Management for LLN. They are
	to define a 6TSCH OF.		considering the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M)
			Objet system. This standard includes DTLS, CoAP (core plus the Block
			and Observe patterns), SenML and CoAP Resource Directory.
	PCE => group needs to work with PCE WG to define flows to PCE, and		(tbd PCC) need to work with PCE WG to define flows to PCE, and define
	define how to accomodate PCE routes and reservation.		how to accomodate PCE routes and reservation. Will probably look a
			lot like GMPLS
	BBR => group needs to work woth 6MAN to define ND proxy. Also need		(tbd Backbone Router) need to work woth 6MAN to define ND proxy.
	BBR sync, time sync between deterministic ethernet and 6TSCH net.		Also need BBR sync sync between deterministic ethernet and 6TSCH
			LLNs.
	IEEE802.1TSN => external, maintain liaison.		IEEE802.1TSN: external, maintain consistency.
	IEEE802.15.4 => external, maintain liaison.		IEEE802.15.4: external, (tbd need updates?).
	ISA100.20 Common Network Management (CNM) => external, maintain		ISA100.20 Common Network Management: external, maintain consistency.
	liaison.
	IoT6 => external, maintain liaison.		IoT6 European Project: external, maintain consistency.
	4. Centralized vs. Distributed Routing		5. Centralized vs. Distributed Routing
	5. Functional Flows		6. Functional Flows
	6. Network Synchronization		7. Network Synchronization
	The mechanism(s) used for time synchronization is something that we		The mechanism(s) used for time synchronization is something that we
	might have to reconcile with RPL discovery and maintenance traffic.		might have to reconcile with RPL discovery and maintenance traffic.
	Time synchronization in TSCH is based on three mechanisms:		Time synchronization in TSCH is based on three mechanisms:
	Enhanced Beacons		Enhanced Beacons
	Enhanced ACKs		Enhanced ACKs
	Frame based synchronization		Frame based synchronization
	If a node communicates intermittently (sleepy, battery operated) it		If a node communicates intermittently (sleepy, battery operated) it
	can also proactively ping its time source and receive time stamps.		can also proactively ping its time source and receive time stamps.
	In order to maximize battery life and network throughput, it is		In order to maximize battery life and network throughput, it is
	advisable that RPL ICMP discovery and maintenance traffic (governed		advisable that RPL ICMP discovery and maintenance traffic (governed
	by the trickle timer) be somehow coordinated with the transmission of		by the trickle timer) be somehow coordinated with the transmission of
	time synch packets (especially with enhanced beacons). This could be		time synch packets (especially with enhanced beacons). This could be
	a function of the shim layer or it could be deferred to the device		a function of the shim layer or it could be deferred to the device
	management entity. Any suggestions, ideas on this topic?		management entity. Any suggestions, ideas on this topic?
	7. TSCH and 6TUS		8. TSCH and 6TUS
	7.1. 6tus		8.1. 6tus
	6tus is an adaptation layer which is the next higher layer to TSCH		6tus is an adaptation layer which is the next higher layer to TSCH
	and which offers a set of commands defining a data and management		and which offers a set of commands defining a data and management
	interface. 6tus is defines in [I-D.draft-wang-6tsch-6tus]		interface. 6tus is defined in [I-D.wang-6tsch-6tus]
	The management interface of 6tus enables an upper layer to schedule		The management interface of 6tus enables an upper layer to schedule
	cells and slotframes in the TSCH schedule.		cells and slotframes in the TSCH schedule.
	If the scheduling entity explicitly specifies the slotOffset/		If the scheduling entity explicitly specifies the slotOffset/
	channelOffset of the cells to be added/deleted, those cells are		channelOffset of the cells to be added/deleted, those cells are
	marked as "hard". 6tus can not move hard cells in the TSCH schedule.		marked as "hard". 6tus can not move hard cells in the TSCH schedule.
	Hard cells are typically used by an central PCE.		Hard cells are typically used by an central PCE.
	6tus contains a monitoring process which monitors the performance of		6tus contains a monitoring process which monitors the performance of
	cells, and can move a cell in the TSCH schedule when it performs bad.		cells, and can move a cell in the TSCH schedule when it performs bad.
	This is only applicable to cells which are marked as "soft". To		This is only applicable to cells which are marked as "soft". To
	reserve a soft cell, the higher layer does not indicate the		reserve a soft cell, the higher layer does not indicate the
	slotOffset/channelOffset of the cell to add, but rather the resulting		slotOffset/channelOffset of the cell to add, but rather the resulting
	bandwidth and QoS requirements. When the monitoring process triggers		bandwidth and QoS requirements. When the monitoring process triggers
	an cell reallocation, the two neighbor motes communication over this		an cell reallocation, the two neighbor motes communication over this
	cells negociate the new position in the TSCH schedule of this cell.		cells negociate the new position in the TSCH schedule of this cell.
	7.2. Slotframes and Priorities		8.2. Slotframes and Priorities
	6tus uses priority queues to manage concurrent data flows of		6tus uses priority queues to manage concurrent data flows of
	different prioroties. When a packet is received from an higher layer		different prioroties. When a packet is received from an higher layer
	for transmission, the I-MUX module of 6tus inserts that packet in the		for transmission, the I-MUX module of 6tus inserts that packet in the
	outgoing queue which matches the packet best (DSCP can therefore be		outgoing queue which matches the packet best (DSCP can therefore be
	used). At each schedule transmit slot, the MUX module looks for the		used). At each schedule transmit slot, the MUX module looks for the
	frame in all the outgoing queues that best matches the cells. If a		frame in all the outgoing queues that best matches the cells. If a
	frame is found, it is given to TSCH for transmission.		frame is found, it is given to TSCH for transmission.
	7.3. Centralized Flow Reservation		8.3. Centralized Flow Reservation
	In a centralized setting, a PCE computes the TSCH schedule, and		In a centralized setting, a PCE computes the TSCH schedule, and
	communicates with the different nodes in the network to configure		communicates with the different nodes in the network to configure
	their TSCH schedule. Since it has full knowledge of the network's		their TSCH schedule. Since it has full knowledge of the network's
	topology, the PCE can compute a collision-free schedule, which result		topology, the PCE can compute a collision-free schedule, which result
	in a high degree of communication determinism.		in a high degree of communication determinism.
	The protocol for the PCE to communicate with the motes is not yet		The protocol for the PCE to communicate with the motes is not yet
	defined. This protocol typically reserves hard cells on the		defined. This protocol typically reserves hard cells on the
	transmitter side of a dedicated cell, and the negociation protocol of		transmitter side of a dedicated cell, and the negociation protocol of
	6tus takes care of reserving the same cell on the receiver node.		6tus takes care of reserving the same cell on the receiver node.
	7.4. Distributed Flow Reservation		8.4. Distributed Flow Reservation
	In a distributed setting, no central PCE in present in the network.		In a distributed setting, no central PCE in present in the network.
	Nodes use 6tus to reserve soft cells with their neighbors. Since no		Nodes use 6tus to reserve soft cells with their neighbors. Since no
	node has full knowledge of the network's topology and the traffic		node has full knowledge of the network's topology and the traffic
	requirements, scheduling collisions are possible, for example because		requirements, scheduling collisions are possible, for example because
	of a hidden terminal problem.		of a hidden terminal problem.
	A schedule collision can be detected if two motes have multiple		A schedule collision can be detected if two motes have multiple
	dedicated cells schedule to one another. The statistics process of		dedicated cells schedule to one another. The statistics process of
	6tus can be configure to continuously compute the packet delivery		6tus can be configure to continuously compute the packet delivery
	skipping to change at page 8, line 19 ¶		skipping to change at page 9, line 5 ¶
	a soft cell to perform bad when that statistics for that cell is		a soft cell to perform bad when that statistics for that cell is
	significantly worse than for the other cell to the same neighbor.		significantly worse than for the other cell to the same neighbor.
	When this happens, the monitoring process of 6tus moves the cell to		When this happens, the monitoring process of 6tus moves the cell to
	another location in the 6TSCH schedule, through a re-negociation		another location in the 6TSCH schedule, through a re-negociation
	procedure with the neighbor.		procedure with the neighbor.
	The entity that builds and maintains the schedule in a distributed		The entity that builds and maintains the schedule in a distributed
	fashion is not yet defined.		fashion is not yet defined.
	7.5. Packet Marking and Handling		8.5. Packet Marking and Handling
	---+----------------		---+----------------
	Sender Receiver		Sender Receiver
	+-----------+ +----+ +----+ +----+ +-----------+		+-----------+ +----+ +----+ +----+ +-----------+
	|Application|---->| R1 |---->| R2 |----->|BBR |----->|Application|		|Application|---->| R1 |---->| R2 |----->|BBR |----->|Application|
	| +--+ | |+--+| |+--+| |+--+| | +--+ |		| +--+ | |+--+| |+--+| |+--+| | +--+ |
	| |NE|====|=====||NE||=====||NE||======||NE||======|===|NE| |		| |NE|====|=====||NE||=====||NE||======||NE||======|===|NE| |
	| +--+ | |+--+| |+--+| |+--+| | +--+ |		| +--+ | |+--+| |+--+| |+--+| | +--+ |
	| |^ | | |^ | | |^ | | |^ | | |^ |		| |^ | | |^ | | |^ | | |^ | | |^ |
	| v| | | v| | | v| | | v| | | v| |		| v| | | v| | | v| | | v| | | v| |
	skipping to change at page 8, line 45 ¶		skipping to change at page 9, line 31 ¶
	+--+		+--+
	|NE| = NSIS ==== = Signaling ---> = Data flow messages		|NE| = NSIS ==== = Signaling ---> = Data flow messages
	+--+ Entity Messages (unidirectional)		+--+ Entity Messages (unidirectional)
	+--+		+--+
	|6T| 6TUS layer		|6T| 6TUS layer
	|us| (and IEEE802.15.4e TSCH MAC below)		|us| (and IEEE802.15.4e TSCH MAC below)
	+--+		+--+
	Figure 4: NSIS flow
	reservation Deterministic flow allocation (hard reservation of time		reservation Deterministic flow allocation (hard reservation of time
	slots) eg centralized RSVP? metrics? Hop-by-hop interaction with		slots) eg centralized RSVP? metrics? Hop-by-hop interaction with
	6TUS. Lazy reservation (use shared slots to transport extra burst		6TUS. Lazy reservation (use shared slots to transport extra burst
	and then dynamically (de)allocate) Classical QoS (dynamic based on		and then dynamically (de)allocate) Classical QoS (dynamic based on
	observation)		observation)
	8. Management		9. Management
	9. IANA Considerations		10. IANA Considerations
	This specification does not require IANA action.		This specification does not require IANA action.
	10. Security Considerations		11. Security Considerations
	This specification is not found to introduce new security threat.		This specification is not found to introduce new security threat.
	11. Acknowledgements		12. Acknowledgements
	12. References		13. References
	12.1. Normative References		13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version		[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version
	6 (IPv6) Specification", RFC 2460, December 1998.		6 (IPv6) Specification", RFC 2460, December 1998.
	[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den		[RFC4080] Hancock, R., Karagiannis, G., Loughney, J. and S. Van den
	Bosch, "Next Steps in Signaling (NSIS): Framework", RFC		Bosch, "Next Steps in Signaling (NSIS): Framework", RFC
	4080, June 2005.		4080, June 2005.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.		[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
	Yegin, "Protocol for Carrying Authentication for Network		Yegin, "Protocol for Carrying Authentication for Network
	Access (PANA)", RFC 5191, May 2008.		Access (PANA)", RFC 5191, May 2008.
	[RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad		[RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
	Hoc Networks", RFC 5889, September 2010.		Hoc Networks", RFC 5889, September 2010.
	[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS		[RFC5974] Manner, J., Karagiannis, G. and A. McDonald, "NSIS
	Signaling Layer Protocol (NSLP) for Quality-of-Service		Signaling Layer Protocol (NSLP) for Quality-of-Service
	Signaling", RFC 5974, October 2010.		Signaling", RFC 5974, October 2010.
	[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6		[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
	Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	September 2011.		September 2011.
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
	Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.		Levis, P., Pister, K., Struik, R., Vasseur, JP. and R.
	Alexander, "RPL: IPv6 Routing Protocol for Low-Power and		Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
	Lossy Networks", RFC 6550, March 2012.		Lossy Networks", RFC 6550, March 2012.
	[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,		[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann,
	"Neighbor Discovery Optimization for IPv6 over Low-Power		"Neighbor Discovery Optimization for IPv6 over Low-Power
	Wireless Personal Area Networks (6LoWPANs)", RFC 6775,		Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
	November 2012.		November 2012.
	12.2. Informative References		13.2. Informative References
	[I-D.chakrabarti-nordmark-6man-efficient-nd]		[I-D.chakrabarti-nordmark-6man-efficient-nd]
	Chakrabarti, S., Nordmark, E., and M. Wasserman,		Chakrabarti, S., Nordmark, E. and M. Wasserman,
	"Efficiency aware IPv6 Neighbor Discovery Optimizations",		"Efficiency aware IPv6 Neighbor Discovery Optimizations",
	draft-chakrabarti-nordmark-6man-efficient-nd-01 (work in		Internet-Draft draft-chakrabarti-nordmark-6man-efficient-
	progress), November 2012.		nd-01, November 2012.
	[I-D.draft-wang-6tsch-6tus]
	Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6tus
	Adaptation Layer Specification. draft-wang-6tsch-6tus-00
	(work in progress) ", March 2013.
	[I-D.palattella-6tsch-terminology]		[I-D.palattella-6tsch-terminology]
	Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q.		Palattella, M., Thubert, P., Watteyne, T. and Q. Wang,
	Wang, "Terminology in IPv6 over Time Slotted Channel		"Terminology in IPv6 over Time Slotted Channel Hopping",
	Hopping. draft-palattella-6tsch-terminology-00 (work in		Internet-Draft draft-palattella-6tsch-terminology-00,
	progress) ", March 2013.		March 2013.
	[I-D.svshah-tsvwg-lln-diffserv-recommendations]		[I-D.svshah-tsvwg-lln-diffserv-recommendations]
	Shah, S. and P. Thubert, "Differentiated Service Class		Shah, S. and P. Thubert, "Differentiated Service Class
	Recommendations for LLN Traffic", draft-svshah-tsvwg-lln-		Recommendations for LLN Traffic", Internet-Draft draft-
	diffserv-recommendations-00 (work in progress), February		svshah-tsvwg-lln-diffserv-recommendations-00, February
	2013.		2013.
	[I-D.thubert-6lowpan-backbone-router]		[I-D.thubert-6lowpan-backbone-router]
	Thubert, P., "6LoWPAN Backbone Router", draft-thubert-		Thubert, P., "6LoWPAN Backbone Router", Internet-Draft
	6lowpan-backbone-router-03 (work in progress), February		draft-thubert-6lowpan-backbone-router-03, February 2013.
	2013.
			[I-D.wang-6tsch-6tus]
			Wang, Q., Vilajosana, X. and T. Watteyne, "6tus Adaptation
			Layer Specification", Internet-Draft draft-wang-6tsch-
			6tus-00, March 2013.
	[I-D.watteyne-6tsch-tsch-lln-context]		[I-D.watteyne-6tsch-tsch-lln-context]
	Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context:		Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context:
	Overview, Problem Statement and Goals", draft-watteyne-		Overview, Problem Statement and Goals", Internet-Draft
	6tsch-tsch-lln-context-01 (work in progress), February		draft-watteyne-6tsch-tsch-lln-context-01, February 2013.
	2013.
	12.3. External Informative References		[I-D.watteyne-6tsch-tsch-lln-context]
			Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context:
			Overview, Problem Statement and Goals", Internet-Draft
			draft-watteyne-6tsch-tsch-lln-context-01, February 2013.
			[I-D.watteyne-6tsch-tsch-lln-context]
			Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context:
			Overview, Problem Statement and Goals", Internet-Draft
			draft-watteyne-6tsch-tsch-lln-context-01, February 2013.
			13.3. External Informative References
	[HART] www.hartcomm.org, "Highway Addressable Remote Transducer,		[HART] www.hartcomm.org, "Highway Addressable Remote Transducer,
	a group of specifications for industrial process and		a group of specifications for industrial process and
	control devices administered by the HART Foundation", .		control devices administered by the HART Foundation", .
	[IEEE802.1TSNTG]		[IEEE802.1TSNTG]
	IEEE Standards Association, "IEEE 802.1 Time-Sensitive		IEEE Standards Association, "IEEE 802.1 Time-Sensitive
	Networks Task Group", March 2013, <		Networks Task Group", March 2013, <http://www.ieee802.org/
	http://www.ieee802.org/1/pages/avbridges.html>.		1/pages/avbridges.html>.
	[ISA100.11a]		[ISA100.11a]
	ISA, "ISA100, Wireless Systems for Automation", May 2008,		ISA, "ISA100, Wireless Systems for Automation", May 2008,
	< http://www.isa.org/Community/		<http://www.isa.org/Community/
	SP100WirelessSystemsforAutomation>.		SP100WirelessSystemsforAutomation>.
	Authors' Addresses		Authors' Addresses
			Pascal Thubert, editor
	Pascal Thubert (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
	Village d'Entreprises Green Side		Building D
	400, Avenue de Roumanille		45 Allee des Ormes - BP1200
	Batiment T3		MOUGINS - Sophia Antipolis, 06254
	Biot - Sophia Antipolis 06410
	FRANCE		FRANCE
	Phone: +33 497 23 26 34		Phone: +33 497 23 26 34
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
	Robert Assimiti		Robert Assimiti
	Nivis		Nivis
	1000 Circle 75 Parkway SE, Ste 300		1000 Circle 75 Parkway SE, Ste 300
	Atlanta, GA 30339		Atlanta, GA 30339
	USA		USA
	Phone: +1 678 202 6859		Phone: +1 678 202 6859
	Email: robert.assimiti@nivis.com		Email: robert.assimiti@nivis.com
	Thomas Watteyne		Thomas Watteyne
	Linear Technology / Dust Networks		Linear Technology / Dust Networks
	30695 Huntwood Avenue		30695 Huntwood Avenue
	Hayward, CA 94544		Hayward, CA 94544
	USA		USA
	Phone: +1 (510) 400-2978		Phone: +1 (510) 400-2978
	Email: twatteyne@linear.com		Email: twatteyne@linear.com
End of changes. 70 change blocks.
	170 lines changed or deleted		215 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/