draft-ietf-6tisch-tsch-02.txt		draft-ietf-6tisch-tsch-03.txt
	6TiSCH T. Watteyne, Ed.		6TiSCH T. Watteyne, Ed.
	Internet-Draft Linear Technology		Internet-Draft Linear Technology
	Intended status: Informational MR. Palattella		Intended status: Informational MR. Palattella
	Expires: April 20, 2015 University of Luxembourg		Expires: April 30, 2015 University of Luxembourg
	LA. Grieco		LA. Grieco
	Politecnico di Bari		Politecnico di Bari
	October 17, 2014		October 27, 2014
	Using IEEE802.15.4e TSCH in an IoT context:		Using IEEE802.15.4e TSCH in an IoT context:
	Overview, Problem Statement and Goals		Overview, Problem Statement and Goals
	draft-ietf-6tisch-tsch-02		draft-ietf-6tisch-tsch-03
	Abstract		Abstract
	This document describes the environment, problem statement, and goals		This document describes the environment, problem statement, and goals
	for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs.		for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs.
	The set of goals enumerated in this document form an initial set		The set of goals enumerated in this document form an initial set
	only.		only.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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 April 20, 2015.		This Internet-Draft will expire on April 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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/license-info) in effect on the date of		(http://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
	skipping to change at page 2, line 14		skipping to change at page 2, line 14
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4		3. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4
	4. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 6		4. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Network Formation . . . . . . . . . . . . . . . . . . . . 6		4.1. Network Formation . . . . . . . . . . . . . . . . . . . . 7
	4.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7		4.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7
	4.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 7		4.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 7
	4.4. Routing and Timing Parents . . . . . . . . . . . . . . . 7		4.4. Routing and Timing Parents . . . . . . . . . . . . . . . 8
	4.5. Resource Management . . . . . . . . . . . . . . . . . . . 8		4.5. Resource Management . . . . . . . . . . . . . . . . . . . 8
	4.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8		4.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8
	4.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8		4.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8
	4.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 8		4.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 9
	4.9. Secure Communication . . . . . . . . . . . . . . . . . . 9		4.9. Secure Communication . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 10
	8.3. External Informative References . . . . . . . . . . . . . 13		8.3. External Informative References . . . . . . . . . . . . . 13
	Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 15		Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 16
	A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 15		A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 16
	A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 16		A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 16
	A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 16		A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 16
	A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 16		A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 17
	A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 17		A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 17
	A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 17		A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 18
	A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 18		A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 18
	A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 18		A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 19
	A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 19		A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 19
	A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 19		A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 20
	A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 20		A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 20
	A.12. Information Elements . . . . . . . . . . . . . . . . . . 20		A.12. Information Elements . . . . . . . . . . . . . . . . . . 21
	A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 20		A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 21
	Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 21		Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 21
	B.1. Collision Free Communication . . . . . . . . . . . . . . 21		B.1. Collision Free Communication . . . . . . . . . . . . . . 21
	B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 21		B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 21
	B.3. Cost of (continuous) Synchronization . . . . . . . . . . 21		B.3. Cost of (continuous) Synchronization . . . . . . . . . . 22
	B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 21		B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 22
	B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 22		B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	IEEE802.15.4e [IEEE802154e] was published in 2012 as an amendment to		IEEE802.15.4e [IEEE802154e] was published in 2012 as an amendment to
	the Medium Access Control (MAC) protocol defined by the		the Medium Access Control (MAC) protocol defined by the
	IEEE802.15.4-2011 [IEEE802154] standard. IEEE802.15.4e will be		IEEE802.15.4-2011 [IEEE802154] standard. IEEE802.15.4e will be
	rolled into the next revision of IEEE802.15.4, scheduled to be		rolled into the next revision of IEEE802.15.4, scheduled to be
	published in 2015. The Timeslotted Channel Hopping (TSCH) mode of		published in 2015. The Timeslotted Channel Hopping (TSCH) mode of
	IEEE802.15.4e is the object of this document.		IEEE802.15.4e is the object of this document.
	skipping to change at page 3, line 39		skipping to change at page 3, line 39
	IEEE802.15.4e is the latest generation of ultra-lower power and		IEEE802.15.4e is the latest generation of ultra-lower power and
	reliable networking solutions for LLNs. [RFC5673] discusses		reliable networking solutions for LLNs. [RFC5673] discusses
	industrial applications, and highlights the harsh operating		industrial applications, and highlights the harsh operating
	conditions as well as the stringent reliability, availability, and		conditions as well as the stringent reliability, availability, and
	security requirements for an LLN to operate in an industrial		security requirements for an LLN to operate in an industrial
	environment. In these environments, vast deployment environments		environment. In these environments, vast deployment environments
	with large (metallic) equipment cause multi-path fading and		with large (metallic) equipment cause multi-path fading and
	interference to thwart any attempt of a single-channel solution to be		interference to thwart any attempt of a single-channel solution to be
	reliable; the channel agility of TSCH is the key to its ultra high		reliable; the channel agility of TSCH is the key to its ultra high
	reliability. Commercial networking solutions are available today in		reliability. Commercial networking solutions are available today in
	which motes consume 10's of micro-amps on average [CurrentCalculator]		which nodes consume 10's of micro-amps on average [CurrentCalculator]
	with end-to-end packet delivery ratios over 99.999%		with end-to-end packet delivery ratios over 99.999%
	[doherty07channel].		[doherty07channel].
			IEEE802.15.4e has been designed for low-power constrained devices,
			often called "motes". Several terms are used in the IETF to refer to
			those devices, including "LLN nodes" [RFC7102] and "constrained
			nodes" [RFC7228]. In this document, we use the generic (and shorter)
			term "node", used as a synonym for "LLN node", "constrained node" or
			"mote".
	Bringing industrial-like performance into the LLN stack developed by		Bringing industrial-like performance into the LLN stack developed by
	Internet of Things (IoT) related IETF working groups such as 6Lo,		Internet of Things (IoT) related IETF working groups such as 6Lo,
	ROLL and CoRE opens up new application domains for these networks.		ROLL and CoRE opens up new application domains for these networks.
	Sensors deployed in smart cities [RFC5548] will be able to be		Sensors deployed in smart cities [RFC5548] will be able to be
	installed for years without needing battery replacement. "Umbrella"		installed for years without needing battery replacement. "Umbrella"
	networks will interconnect smart elements from different entities in		networks will interconnect smart elements from different entities in
	smart buildings [RFC5867]. Peel-and-stick switches will obsolete the		smart buildings [RFC5867]. Peel-and-stick switches will obsolete the
	need for costly conduits for lighting solutions in smart homes		need for costly conduits for lighting solutions in smart homes
	[RFC5826].		[RFC5826].
	IEEE802.15.4e TSCH focuses on the MAC layer only. This clean		IEEE802.15.4e TSCH focuses on the MAC layer only. This clean
	layering allows for TSCH to fit under an IPv6 enabled protocol stack		layering allows for TSCH to fit under an IPv6 enabled protocol stack
	for LLNs, running 6LoWPAN [RFC6282], IPv6 Routing Protocol for Low		for LLNs, running 6LoWPAN [RFC6282], IPv6 Routing Protocol for Low
	skipping to change at page 4, line 14		skipping to change at page 4, line 21
	IEEE802.15.4e TSCH focuses on the MAC layer only. This clean		IEEE802.15.4e TSCH focuses on the MAC layer only. This clean
	layering allows for TSCH to fit under an IPv6 enabled protocol stack		layering allows for TSCH to fit under an IPv6 enabled protocol stack
	for LLNs, running 6LoWPAN [RFC6282], IPv6 Routing Protocol for Low		for LLNs, running 6LoWPAN [RFC6282], IPv6 Routing Protocol for Low
	power and Lossy Networks (RPL) [RFC6550] and the Constrained		power and Lossy Networks (RPL) [RFC6550] and the Constrained
	Application Protocol (CoAP) [RFC7252]. What is missing is a Logical		Application Protocol (CoAP) [RFC7252]. What is missing is a Logical
	Link Control (LLC) layer between the IP abstraction of a link and the		Link Control (LLC) layer between the IP abstraction of a link and the
	TSCH MAC, which is in charge of scheduling a timeslot for a given		TSCH MAC, which is in charge of scheduling a timeslot for a given
	packet coming down the stack from the upper layer.		packet coming down the stack from the upper layer.
	While [IEEE802154e] defines the mechanisms for a TSCH mote to		While [IEEE802154e] defines the mechanisms for a TSCH node to
	communicate, it does not define the policies to build and maintain		communicate, it does not define the policies to build and maintain
	the communication schedule, match that schedule to the multi-hop		the communication schedule, match that schedule to the multi-hop
	paths maintained by RPL, adapt the resources allocated between		paths maintained by RPL, adapt the resources allocated between
	neighbor nodes to the data traffic flows, enforce a differentiated		neighbor nodes to the data traffic flows, enforce a differentiated
	treatment for data generated at the application layer and signaling		treatment for data generated at the application layer and signaling
	messages needed by 6LoWPAN and RPL to discover neighbors, react to		messages needed by 6LoWPAN and RPL to discover neighbors, react to
	topology changes, self-configure IP addresses, or manage keying		topology changes, self-configure IP addresses, or manage keying
	material.		material.
	In other words, IEEE802.15.4e TSCH is designed to allow optimizations		In other words, IEEE802.15.4e TSCH is designed to allow optimizations
	skipping to change at page 5, line 31		skipping to change at page 5, line 38
	Successful solutions take into account the specific application		Successful solutions take into account the specific application
	requirements, along with IPv6 behavior and 6LoWPAN mechanisms		requirements, along with IPv6 behavior and 6LoWPAN mechanisms
	[palattella12standardized]. The ROLL working group has defined RPL		[palattella12standardized]. The ROLL working group has defined RPL
	in [RFC6550]. RPL can support a wide variety of link layers,		in [RFC6550]. RPL can support a wide variety of link layers,
	including ones that are constrained, potentially lossy, or typically		including ones that are constrained, potentially lossy, or typically
	utilized in conjunction with host or router devices with very limited		utilized in conjunction with host or router devices with very limited
	resources, as in building/home automation [RFC5867][RFC5826],		resources, as in building/home automation [RFC5867][RFC5826],
	industrial environments [RFC5673], and urban applications [RFC5548].		industrial environments [RFC5673], and urban applications [RFC5548].
	RPL is able to quickly build up network routes, distribute routing		RPL is able to quickly build up network routes, distribute routing
	knowledge among nodes, and adapt to a changing topology. In a		knowledge among nodes, and adapt to a changing topology. In a
	typical setting, motes are connected through multi-hop paths to a		typical setting, nodes are connected through multi-hop paths to a
	small set of root devices, which are usually responsible for data		small set of root devices, which are usually responsible for data
	collection and coordination. For each of them, a Destination		collection and coordination. For each of them, a Destination
	Oriented Directed Acyclic Graph (DODAG) is created by accounting for		Oriented Directed Acyclic Graph (DODAG) is created by accounting for
	link costs, node attributes/status information, and an Objective		link costs, node attributes/status information, and an Objective
	Function, which maps the optimization requirements of the target		Function, which maps the optimization requirements of the target
	scenario.		scenario.
	The topology is set up based on a Rank metric, which encodes the		The topology is set up based on a Rank metric, which encodes the
	distance of each node with respect to its reference root, as		distance of each node with respect to its reference root, as
	specified by the Objective Function. Regardless of the way it is		specified by the Objective Function. Regardless of the way it is
	skipping to change at page 6, line 48		skipping to change at page 7, line 8
	generic "LLC".		generic "LLC".
	Some of the issues the LLC needs to target might overlap with the		Some of the issues the LLC needs to target might overlap with the
	scope of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this		scope of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this
	case, it is entailed that the LLC will profit from the services		case, it is entailed that the LLC will profit from the services
	provided by other protocols to pursue these objectives.		provided by other protocols to pursue these objectives.
	4.1. Network Formation		4.1. Network Formation
	The LLC needs to control the way the network is formed, including how		The LLC needs to control the way the network is formed, including how
	new motes join, and how already joined motes advertise the presence		new nodes join, and how already joined nodes advertise the presence
	of the network. The LLC needs to:		of the network. The LLC needs to:
	1. Define the Information Elements included in the Enhanced Beacons		1. Define the Information Elements included in the Enhanced Beacons
	advertising the presence of the network.		advertising the presence of the network.
	2. For a new mote, define rules to process and filter received		2. For a new node, define rules to process and filter received
	Enhanced Beacons.		Enhanced Beacons.
	3. Define the joining procedure. This might include a mechanism to		3. Define the joining procedure. This might include a mechanism to
	assign a unique 16-bit address to a mote, and the management of		assign a unique 16-bit address to a node, and the management of
	initial keying material.		initial keying material.
	4. Define a mechanism to secure the joining process and the		4. Define a mechanism to secure the joining process and the
	subsequent optional process of scheduling more communication		subsequent optional process of scheduling more communication
	cells.		cells.
	4.2. Network Maintenance		4.2. Network Maintenance
	Once a network is formed, the LLC needs to maintain the network's		Once a network is formed, the LLC needs to maintain the network's
	health, allowing for motes to stay synchronized. The LLC needs to:		health, allowing for nodes to stay synchronized. The LLC needs to:
	1. Manage each mote's time source neighbor.		1. Manage each node's time source neighbor.
	2. Define a mechanism for a mote to update the join priority it		2. Define a mechanism for a node to update the join priority it
	announces in its Enhanced Beacon.		announces in its Enhanced Beacon.
	3. Schedule transmissions of Enhanced Beacons to advertise the		3. Schedule transmissions of Enhanced Beacons to advertise the
	presence of the network.		presence of the network.
	4.3. Multi-Hop Topology		4.3. Multi-Hop Topology
	RPL, given a weighted connectivity graph, determines multi-hop		RPL, given a weighted connectivity graph, determines multi-hop
	routes. The LLC needs to:		routes. The LLC needs to:
	skipping to change at page 7, line 48		skipping to change at page 8, line 7
	can then feed to RPL.		can then feed to RPL.
	2. Ensure that the TSCH schedule contains cells along the multi-hop		2. Ensure that the TSCH schedule contains cells along the multi-hop
	routes identified by RPL.		routes identified by RPL.
	3. Where applicable, maintain independent sets of cells to transport		3. Where applicable, maintain independent sets of cells to transport
	independent flows of data.		independent flows of data.
	4.4. Routing and Timing Parents		4.4. Routing and Timing Parents
	At all times, a TSCH mote needs to have a time source neighbor it can		At all times, a TSCH node needs to have a time source neighbor it can
	synchronize to. The LLC therefore needs to assign a time source		synchronize to. The LLC therefore needs to assign a time source
	neighbor to allow for correct operation of the TSCH network. A time		neighbor to allow for correct operation of the TSCH network. A time
	source neighbors could, or not, be taken from the RPL routing parent		source neighbors could, or not, be taken from the RPL routing parent
	set.		set.
	4.5. Resource Management		4.5. Resource Management
	A cell in a TSCH schedule is an atomic "unit" of resource. The		A cell in a TSCH schedule is an atomic "unit" of resource. The
	number of cells to assign between neighbor motes needs to be		number of cells to assign between neighbor nodes needs to be
	appropriate for the size of the traffic flow. The LLC needs to:		appropriate for the size of the traffic flow. The LLC needs to:
	1. Define a mechanism for neighbor nodes to exchange information		1. Define a mechanism for neighbor nodes to exchange information
	about their schedule and, if applicable, negotiate the addition/		about their schedule and, if applicable, negotiate the addition/
	deletion of cells.		deletion of cells.
	2. Allow for an entity (e.g., a set of devices, a distributed		2. Allow for an entity (e.g., a set of devices, a distributed
	protocol, a PCE, etc.) to take control of the schedule.		protocol, a PCE, etc.) to take control of the schedule.
	4.6. Dataflow Control		4.6. Dataflow Control
	TSCH defines mechanisms for a mote to signal it cannot accept an		TSCH defines mechanisms for a node to signal it cannot accept an
	incoming packet. It does not, however, define the policy which		incoming packet. It does not, however, define the policy which
	determines when to stop accepting packets. The LLC needs to:		determines when to stop accepting packets. The LLC needs to:
	1. Define a queuing policy for incoming and outgoing packets.		1. Define a queuing policy for incoming and outgoing packets.
	2. Manage the buffer space, and indicate to TSCH when to stop		2. Manage the buffer space, and indicate to TSCH when to stop
	accepting incoming packets.		accepting incoming packets.
	3. Handle transmissions that have failed. A transmission is		3. Handle transmissions that have failed. A transmission is
	declared failed when TSCH has retransmitted the packet multiple		declared failed when TSCH has retransmitted the packet multiple
	skipping to change at page 9, line 24		skipping to change at page 9, line 33
	3. Define an mechanism for these different scheduling mechanisms to		3. Define an mechanism for these different scheduling mechanisms to
	coexist in the same network.		coexist in the same network.
	4.9. Secure Communication		4.9. Secure Communication
	Given some keying material, TSCH defines mechanisms to encrypt and		Given some keying material, TSCH defines mechanisms to encrypt and
	authenticate MAC frames. It does not define how this keying material		authenticate MAC frames. It does not define how this keying material
	is generated. The LLC needs to:		is generated. The LLC needs to:
	1. Define the keying material and authentication mechanism needed by		1. Define the keying material and authentication mechanism needed by
	a new mote to join an existing network.		a new node to join an existing network.
	2. Define a mechanism to allow for the secure transfer of		2. Define a mechanism to allow for the secure transfer of
	application data between neighbor motes.		application data between neighbor nodes.
	3. Define a mechanism to allow for the secure transfer of signaling		3. Define a mechanism to allow for the secure transfer of signaling
	data between motes and the LLC.		data between nodes and the LLC.
	5. IANA Considerations		5. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	6. Security Considerations		6. Security Considerations
	This memo is an informational overview of existing standards, and		This memo is an informational overview of existing standards, and
	does define any new mechanisms or protocols.		does define any new mechanisms or protocols.
	skipping to change at page 10, line 17		skipping to change at page 10, line 23
	8.1. Normative References		8.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.
	8.2. Informative References		8.2. Informative References
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252, June 2014.		Application Protocol (CoAP)", RFC 7252, June 2014.
			[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
			Constrained-Node Networks", RFC 7228, May 2014.
			[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
			Lossy Networks", RFC 7102, January 2014.
	[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem		[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
	Statement and Requirements for IPv6 over Low-Power		Statement and Requirements for IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Routing", RFC		Wireless Personal Area Network (6LoWPAN) Routing", RFC
	6606, May 2012.		6606, May 2012.
	[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and		[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
	Application Spaces for IPv6 over Low-Power Wireless		Application Spaces for IPv6 over Low-Power Wireless
	Personal Area Networks (6LoWPANs)", RFC 6568, April 2012.		Personal Area Networks (6LoWPANs)", RFC 6568, April 2012.
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
	skipping to change at page 11, line 27		skipping to change at page 11, line 39
	[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,		[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
	Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.		Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
	Wood, "Advice for Internet Subnetwork Designers", BCP 89,		Wood, "Advice for Internet Subnetwork Designers", BCP 89,
	RFC 3819, July 2004.		RFC 3819, July 2004.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[I-D.ietf-6tisch-tsch]		[I-D.ietf-6tisch-tsch]
	Watteyne, T., Palattella, M., and L. Grieco, "Using		Watteyne, T., Palattella, M., and L. Grieco, "Using
	IEEE802.15.4e TSCH in an LLN context: Overview, Problem		IEEE802.15.4e TSCH in an IoT context: Overview, Problem
	Statement and Goals", draft-ietf-6tisch-tsch-01 (work in		Statement and Goals", draft-ietf-6tisch-tsch-02 (work in
	progress), July 2014.		progress), October 2014.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., Watteyne, T., and R. Assimiti, "An		Thubert, P., Watteyne, T., and R. Assimiti, "An
	Architecture for IPv6 over the TSCH mode of IEEE		Architecture for IPv6 over the TSCH mode of IEEE
	802.15.4e", draft-ietf-6tisch-architecture-03 (work in		802.15.4e", draft-ietf-6tisch-architecture-03 (work in
	progress), July 2014.		progress), July 2014.
	[I-D.ietf-6tisch-terminology]		[I-D.ietf-6tisch-terminology]
	Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,		Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
	"Terminology in IPv6 over the TSCH mode of IEEE		"Terminology in IPv6 over the TSCH mode of IEEE
	802.15.4e", draft-ietf-6tisch-terminology-02 (work in		802.15.4e", draft-ietf-6tisch-terminology-02 (work in
	progress), July 2014.		progress), July 2014.
	[I-D.ietf-6tisch-minimal]		[I-D.ietf-6tisch-minimal]
	Vilajosana, X. and K. Pister, "Minimal 6TiSCH		Vilajosana, X. and K. Pister, "Minimal 6TiSCH
	Configuration", draft-ietf-6tisch-minimal-02 (work in		Configuration", draft-ietf-6tisch-minimal-03 (work in
	progress), July 2014.		progress), October 2014.
	[I-D.ietf-6tisch-6top-interface]		[I-D.ietf-6tisch-6top-interface]
	Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH		Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
	Operation Sublayer (6top) Interface", draft-ietf-6tisch-		Operation Sublayer (6top) Interface", draft-ietf-6tisch-
	6top-interface-01 (work in progress), July 2014.		6top-interface-01 (work in progress), July 2014.
	[I-D.wang-6tisch-6top-sublayer]		[I-D.wang-6tisch-6top-sublayer]
	Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH		Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
	Operation Sublayer (6top)", draft-wang-6tisch-6top-		Operation Sublayer (6top)", draft-wang-6tisch-6top-
	sublayer-01 (work in progress), July 2014.		sublayer-01 (work in progress), July 2014.
	skipping to change at page 15, line 49		skipping to change at page 16, line 21
	o Concepts which are sufficiently different from traditional		o Concepts which are sufficiently different from traditional
	IEEE802.15.4 networking that they may need to be defined and		IEEE802.15.4 networking that they may need to be defined and
	presented precisely.		presented precisely.
	o Techniques and ideas which are part of IEEE802.15.4e and which		o Techniques and ideas which are part of IEEE802.15.4e and which
	might be useful for the work of the 6TiSCH WG.		might be useful for the work of the 6TiSCH WG.
	A.1. Timeslots		A.1. Timeslots
	All motes in a TSCH network are synchronized. Time is sliced up into		All nodes in a TSCH network are synchronized. Time is sliced up into
	timeslots. A timeslot is long enough for a MAC frame of maximum size		timeslots. A timeslot is long enough for a MAC frame of maximum size
	to be sent from mote A to mote B, and for mote B to reply with an		to be sent from node A to node B, and for node B to reply with an
	acknowledgment (ACK) frame indicating successful reception.		acknowledgment (ACK) frame indicating successful reception.
	The duration of a timeslot is not defined by the standard. With		The duration of a timeslot is not defined by the standard. With
	IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band,		IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band,
	a maximum-length frame of 127 bytes takes about 4ms to transmit; a		a maximum-length frame of 127 bytes takes about 4ms to transmit; a
	shorter ACK takes about 1ms. With a 10ms slot (a typical duration),		shorter ACK takes about 1ms. With a 10ms slot (a typical duration),
	this leaves 5ms to radio turnaround, packet processing and security		this leaves 5ms to radio turnaround, packet processing and security
	operations.		operations.
	A.2. Slotframes		A.2. Slotframes
	Timeslots are grouped into one of more slotframes. A slotframe		Timeslots are grouped into one of more slotframes. A slotframe
	continuously repeats over time. TSCH does not impose a slotframe		continuously repeats over time. TSCH does not impose a slotframe
	size. Depending on the application needs, these can range from 10s		size. Depending on the application needs, these can range from 10s
	to 1000s of timeslots. The shorter the slotframe, the more often a		to 1000s of timeslots. The shorter the slotframe, the more often a
	timeslot repeats, resulting in more available bandwidth, but also in		timeslot repeats, resulting in more available bandwidth, but also in
	a higher power consumption.		a higher power consumption.
	A.3. Node TSCH Schedule		A.3. Node TSCH Schedule
	A TSCH schedule instructs each mote what to do in each timeslot:		A TSCH schedule instructs each node what to do in each timeslot:
	transmit, receive or sleep. The schedule indicates, for each		transmit, receive or sleep. The schedule indicates, for each
	scheduled (transmit or receive) cell, a channelOffset and the address		scheduled (transmit or receive) cell, a channelOffset and the address
	of the neighbor to communicate with.		of the neighbor to communicate with.
	Once a mote obtains its schedule, it executes it:		Once a node obtains its schedule, it executes it:
	o For each transmit cell, the mote checks whether there is a packet		o For each transmit cell, the node checks whether there is a packet
	in the outgoing buffer which matches the neighbor written in the		in the outgoing buffer which matches the neighbor written in the
	schedule information for that timeslot. If there is none, the		schedule information for that timeslot. If there is none, the
	mote keeps its radio off for the duration of the timeslot. If		node keeps its radio off for the duration of the timeslot. If
	there is one, the mote can ask for the neighbor to acknowledge it,		there is one, the node can ask for the neighbor to acknowledge it,
	in which case it has to listen for the acknowledgment after		in which case it has to listen for the acknowledgment after
	transmitting.		transmitting.
	o For each receive cell, the mote listens for possible incoming		o For each receive cell, the node listens for possible incoming
	packets. If none is received after some listening period, it		packets. If none is received after some listening period, it
	shuts down its radio. If a packet is received, addressed to the		shuts down its radio. If a packet is received, addressed to the
	mote, and passes security checks, the mote can send back an		node, and passes security checks, the node can send back an
	acknowledgment.		acknowledgment.
	How the schedule is built, updated and maintained, and by which		How the schedule is built, updated and maintained, and by which
	entity, is outside of the scope of the IEEE802.15.4e standard.		entity, is outside of the scope of the IEEE802.15.4e standard.
	A.4. Cells and Bundles		A.4. Cells and Bundles
	Assuming the schedule is well built, if mote A is scheduled to		Assuming the schedule is well built, if node A is scheduled to
	transmit to mote B at slotOffset 5 and channelOffset 11, mote B will		transmit to node B at slotOffset 5 and channelOffset 11, node B will
	be scheduled to receive from mote A at the same slotOffset and		be scheduled to receive from node A at the same slotOffset and
	channelOffset.		channelOffset.
	A single element of the schedule characterized by a slotOffset and		A single element of the schedule characterized by a slotOffset and
	channelOffset, and reserved for mote A to transmit to mote B (or for		channelOffset, and reserved for node A to transmit to node B (or for
	mote B to receive from mote A) within a given slotframe, is called a		node B to receive from node A) within a given slotframe, is called a
	"scheduled cell".		"scheduled cell".
	If there is a lot of data flowing from mote A to mote B, the schedule		If there is a lot of data flowing from node A to node B, the schedule
	might contain multiple cells from A to B, at different times.		might contain multiple cells from A to B, at different times.
	Multiple cells scheduled to the same neighbor can be equivalent, i.e.		Multiple cells scheduled to the same neighbor can be equivalent, i.e.
	the MAC layer sends the packet on whichever of these cells shows up		the MAC layer sends the packet on whichever of these cells shows up
	first after the packet was put in the MAC queue. The union of all		first after the packet was put in the MAC queue. The union of all
	cells between two neighbors, A and B, is called a "bundle". Since		cells between two neighbors, A and B, is called a "bundle". Since
	the slotframe repeats over time (and the length of the slotframe is		the slotframe repeats over time (and the length of the slotframe is
	typically constant), each cell gives a "quantum" of bandwidth to a		typically constant), each cell gives a "quantum" of bandwidth to a
	given neighbor. Modifying the number of equivalent cells in a bundle		given neighbor. Modifying the number of equivalent cells in a bundle
	modifies the amount of resources allocated between two neighbors.		modifies the amount of resources allocated between two neighbors.
	A.5. Dedicated vs. Shared Cells		A.5. Dedicated vs. Shared Cells
	By default, each scheduled transmit cell within the TSCH schedule is		By default, each scheduled transmit cell within the TSCH schedule is
	dedicated, i.e., reserved only for mote A to transmit to mote B.		dedicated, i.e., reserved only for node A to transmit to node B.
	IEEE802.15.4e allows also to mark a cell as shared. In a shared		IEEE802.15.4e allows also to mark a cell as shared. In a shared
	cell, multiple motes can transmit at the same time, on the same		cell, multiple nodes can transmit at the same time, on the same
	frequency. To avoid contention, TSCH defines a back-off algorithm		frequency. To avoid contention, TSCH defines a back-off algorithm
	for shared cells.		for shared cells.
	A scheduled cell can be marked as both transmitting and receiving.		A scheduled cell can be marked as both transmitting and receiving.
	In this case, a mote transmits if it has an appropriate packet in its		In this case, a node transmits if it has an appropriate packet in its
	output buffer, or listens otherwise. Marking a cell as		output buffer, or listens otherwise. Marking a cell as
	[transmit,receive,shared] results in slotted-Aloha behavior.		[transmit,receive,shared] results in slotted-Aloha behavior.
	A.6. Absolute Slot Number		A.6. Absolute Slot Number
	TSCH defines a timeslot counter called Absolute Slot Number (ASN).		TSCH defines a timeslot counter called Absolute Slot Number (ASN).
	When a new network is created, the ASN is initialized to 0; from then		When a new network is created, the ASN is initialized to 0; from then
	on, it increments by 1 at each timeslot. In detail:		on, it increments by 1 at each timeslot. In detail:
	ASN = (k*S+t)		ASN = (k*S+t)
	where k is the slotframe cycle (i.e., the number of slotframe		where k is the slotframe cycle (i.e., the number of slotframe
	repetitions since the network was started), S the slotframe size and		repetitions since the network was started), S the slotframe size and
	t the slotOffset. A mote learns the current ASN when it joins the		t the slotOffset. A node learns the current ASN when it joins the
	network. Since motes are synchronized, they all know the current		network. Since nodes are synchronized, they all know the current
	value of the ASN, at any time. The ASN is encoded as a 5-byte		value of the ASN, at any time. The ASN is encoded as a 5-byte
	number: this allows it to increment for hundreds of years (the exact		number: this allows it to increment for hundreds of years (the exact
	value depends on the duration of a timeslot) without wrapping over.		value depends on the duration of a timeslot) without wrapping over.
	The ASN is used to calculate the frequency to communicate on, and can		The ASN is used to calculate the frequency to communicate on, and can
	be used for security-related operations.		be used for security-related operations.
	A.7. Channel Hopping		A.7. Channel Hopping
	For each scheduled cell, the schedule specifies a slotOffset and a		For each scheduled cell, the schedule specifies a slotOffset and a
	channelOffset. In a well-built schedule, when mote A has a transmit		channelOffset. In a well-built schedule, when node A has a transmit
	cell to mote B on channelOffset 5, mote B has a receive cell from		cell to node B on channelOffset 5, node B has a receive cell from
	mote A on the same channelOffset. The channelOffset is translated by		node A on the same channelOffset. The channelOffset is translated by
	both nodes into a frequency using the following function:		both nodes into a frequency using the following function:
	frequency = F {(ASN + channelOffset) mod nFreq}		frequency = F {(ASN + channelOffset) mod nFreq}
	The function F consists of a look-up table containing the set of		The function F consists of a look-up table containing the set of
	available channels. The value nFreq (the number of available		available channels. The value nFreq (the number of available
	frequencies) is the size of this look-up table. There are as many		frequencies) is the size of this look-up table. There are as many
	channelOffset values as there are frequencies available (e.g. 16 when		channelOffset values as there are frequencies available (e.g. 16 when
	using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are		using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are
	used). Since both motes have the same channelOffset written in their		used). Since both nodes have the same channelOffset written in their
	schedule for that scheduled cell, and the same ASN counter, they		schedule for that scheduled cell, and the same ASN counter, they
	compute the same frequency. At the next iteration (cycle) of the		compute the same frequency. At the next iteration (cycle) of the
	slotframe, however, while the channelOffset is the same, the ASN has		slotframe, however, while the channelOffset is the same, the ASN has
	changed, resulting in the computation of a different frequency.		changed, resulting in the computation of a different frequency.
	This results in "channel hopping": even with a static schedule, pairs		This results in "channel hopping": even with a static schedule, pairs
	of neighbors "hop" between the different frequencies when		of neighbors "hop" between the different frequencies when
	communicating. A way of ensuring communication happens on all		communicating. A way of ensuring communication happens on all
	available frequencies is to set the number of timeslots in a		available frequencies is to set the number of timeslots in a
	slotframe to a prime number. Channel hopping is a technique known to		slotframe to a prime number. Channel hopping is a technique known to
	efficiently combat multi-path fading and external interference.		efficiently combat multi-path fading and external interference.
	A.8. Time Synchronization		A.8. Time Synchronization
	Because of the slotted nature of communication in a TSCH network,		Because of the slotted nature of communication in a TSCH network,
	motes have to maintain tight synchronization. All motes are assumed		nodes have to maintain tight synchronization. All nodes are assumed
	to be equipped with clocks to keep track of time. Yet, because		to be equipped with clocks to keep track of time. Yet, because
	clocks in different motes drift with respect to one another, neighbor		clocks in different nodes drift with respect to one another, neighbor
	motes need to periodically re-synchronize.		nodes need to periodically re-synchronize.
	Each mote needs to periodically synchronize its network clock to		Each node needs to periodically synchronize its network clock to
	another mote, and it also provides its network time to its neighbors.		another node, and it also provides its network time to its neighbors.
	It is up to the entity that manages the schedule to assign an		It is up to the entity that manages the schedule to assign an
	adequate time source neighbor to each mote, i.e., to indicate in the		adequate time source neighbor to each node, i.e., to indicate in the
	schedule which of neighbor is its "time source neighbor". While		schedule which of neighbor is its "time source neighbor". While
	setting the time source neighbor, it is important to avoid		setting the time source neighbor, it is important to avoid
	synchronization loops, which could result in the formation of		synchronization loops, which could result in the formation of
	independent clusters of synchronized motes.		independent clusters of synchronized nodes.
	TSCH adds timing information in all packets that are exchanged (both		TSCH adds timing information in all packets that are exchanged (both
	data and ACK frames). This means that neighbor motes can		data and ACK frames). This means that neighbor nodes can
	resynchronize to one another whenever they exchange data. In detail,		resynchronize to one another whenever they exchange data. In detail,
	two methods are defined in IEEE802.15.4e-2012 for allowing a device		two methods are defined in IEEE802.15.4e-2012 for allowing a device
	to synchronize in a TSCH network: (i) Acknowledgment-Based and (ii)		to synchronize in a TSCH network: (i) Acknowledgment-Based and (ii)
	Frame-Based synchronization. In both cases, the receiver calculates		Frame-Based synchronization. In both cases, the receiver calculates
	the difference in time between the expected time of frame arrival and		the difference in time between the expected time of frame arrival and
	its actual arrival. In Acknowledgment-Based synchronization, the		its actual arrival. In Acknowledgment-Based synchronization, the
	receiver provides such information to the sender mote in its		receiver provides such information to the sender node in its
	acknowledgment. In this case, it is the sender mote that		acknowledgment. In this case, it is the sender node that
	synchronizes to the clock of the receiver. In Frame-Based		synchronizes to the clock of the receiver. In Frame-Based
	synchronization, the receiver uses the computed delta for adjusting		synchronization, the receiver uses the computed delta for adjusting
	its own clock. In this case, it is the receiver mote that		its own clock. In this case, it is the receiver node that
	synchronizes to the clock of the sender.		synchronizes to the clock of the sender.
	Different synchronization policies are possible. Motes can keep		Different synchronization policies are possible. Nodes can keep
	synchronization exclusively by exchanging EBs. Motes can also keep		synchronization exclusively by exchanging EBs. Nodes can also keep
	synchronized by periodically sending valid frames to a time source		synchronized by periodically sending valid frames to a time source
	neighbor and use the acknowledgment to resynchronize. Both method		neighbor and use the acknowledgment to resynchronize. Both method
	(or a combination thereof) are valid synchronization policies; which		(or a combination thereof) are valid synchronization policies; which
	one to use depends on network requirements.		one to use depends on network requirements.
	A.9. Power Consumption		A.9. Power Consumption
	There are only a handful of activities a mote can perform during a		There are only a handful of activities a node can perform during a
	timeslot: transmit, receive, or sleep. Each of these operations has		timeslot: transmit, receive, or sleep. Each of these operations has
	some energy cost associated to them, the exact value depends on the		some energy cost associated to them, the exact value depends on the
	the hardware used. Given the schedule of a mote, it is		the hardware used. Given the schedule of a node, it is
	straightforward to calculate the expected average power consumption		straightforward to calculate the expected average power consumption
	of that mote.		of that node.
	A.10. Network TSCH Schedule		A.10. Network TSCH Schedule
	The schedule entirely defines the synchronization and communication		The schedule entirely defines the synchronization and communication
	between motes. By adding/removing cells between neighbors, one can		between nodes. By adding/removing cells between neighbors, one can
	adapt a schedule to the needs of the application. Intuitive examples		adapt a schedule to the needs of the application. Intuitive examples
	are:		are:
	o Make the schedule "sparse" for applications where motes need to		o Make the schedule "sparse" for applications where nodes need to
	consume as little energy as possible, at the price of reduced		consume as little energy as possible, at the price of reduced
	bandwidth.		bandwidth.
	o Make the schedule "dense" for applications where motes generate a		o Make the schedule "dense" for applications where nodes generate a
	lot of data, at the price of increased power consumption.		lot of data, at the price of increased power consumption.
	o Add more cells along a multi-hop route over which many packets		o Add more cells along a multi-hop route over which many packets
	flow.		flow.
	A.11. Join Process		A.11. Join Process
	Motes already part of the network can periodically send Enhanced		Nodes already part of the network can periodically send Enhanced
	Beacon (EB) frames to announce the presence of the network. These		Beacon (EB) frames to announce the presence of the network. These
	contain information about the size of the timeslot used in the		contain information about the size of the timeslot used in the
	network, the current ASN, information about the slotframes and		network, the current ASN, information about the slotframes and
	timeslots the beaconing mote is listening on, and a 1-byte join		timeslots the beaconing node is listening on, and a 1-byte join
	priority. Even if a node is configured to send all EB frames on the		priority. The join priority field gives information to make a better
	same channel offset, because of the channel hopping nature of TSCH		decision of which node to join. Even if a node is configured to send
	described in Appendix A.7, this channel offset translates into a		all EB frames on the same channel offset, because of the channel
	different frequency at different slotframe cycles. As a result, EB		hopping nature of TSCH described in Appendix A.7, this channel offset
	frames are sent on all frequencies.		translates into a different frequency at different slotframe cycles.
			As a result, EB frames are sent on all frequencies.
	A mote wishing to join the network listens for EBs. Since EBs are		A node wishing to join the network listens for EBs. Since EBs are
	sent on all frequencies, the joining node can listen on any frequency		sent on all frequencies, the joining node can listen on any frequency
	until it hears an EB. What frequency it listens on, and whether it		until it hears an EB. What frequency it listens on is
	slowly changes frequency during this joining period is		implementation-specific. Once it has received one or more EBs, the
	implementation-specific. Using the ASN and the other timing		new node enables the TSCH mode and uses the ASN and the other timing
	information of the EB, the new mote synchronizes to the network.		information from the EB to synchronize to the network. Using the
	Using the slotframe and cell information from the EB, it knows how to		slotframe and cell information from the EB, it knows how to contact
	contact other nodes in the network.		other nodes in the network.
	The IEEE802.15.4e TSCH standard does not define the steps beyond this		The IEEE802.15.4e TSCH standard does not define the steps beyond this
	network "bootstrap".		network "bootstrap".
	A.12. Information Elements		A.12. Information Elements
	TSCH introduces the concept of Information Elements (IEs). An		TSCH introduces the concept of Information Elements (IEs). An
	information element is a list of Type-Length-Value containers placed		information element is a list of Type-Length-Value containers placed
	at the end of the MAC header. A small number of types are defined		at the end of the MAC header. A small number of types are defined
	for TSCH (e.g., the ASN in the EB is contained in an IE), and an		for TSCH (e.g., the ASN in the EB is contained in an IE), and an
	unmanaged range is available for extensions.		unmanaged range is available for extensions.
	A data bit in the MAC header indicates whether the frame contains		A data bit in the MAC header indicates whether the frame contains
	IEs. IEs are grouped into Header IEs, consumed by the MAC layer and		IEs. IEs are grouped into Header IEs, consumed by the MAC layer and
	therefore typically invisible to the next higher layer, and Payload		therefore typically invisible to the next higher layer, and Payload
	IEs, which are passed untouched to the next higher layer, possibly		IEs, which are passed untouched to the next higher layer, possibly
	followed by regular payload. Payload IEs can therefore be used for		followed by regular payload. Payload IEs can therefore be used for
	the next higher layers of two neighbor motes to exchange information.		the next higher layers of two neighbor nodes to exchange information.
	A.13. Extensibility		A.13. Extensibility
	The TSCH standard is designed to be extensible. It introduces the		The TSCH standard is designed to be extensible. It introduces the
	mechanisms as "building block" (e.g., cells, bundles, slotframes,		mechanisms as "building block" (e.g., cells, bundles, slotframes,
	etc.), but leaves entire freedom to the upper layer to assemble		etc.), but leaves entire freedom to the upper layer to assemble
	those. The MAC protocol can be extended by defining new Header IEs.		those. The MAC protocol can be extended by defining new Header IEs.
	An intermediate layer can be defined to manage the MAC layer by		An intermediate layer can be defined to manage the MAC layer by
	defining new Payload IEs.		defining new Payload IEs.
	skipping to change at page 21, line 16		skipping to change at page 21, line 40
	This section lists features of TSCH which we believe are important		This section lists features of TSCH which we believe are important
	and beneficial to the work of 6TiSCH.		and beneficial to the work of 6TiSCH.
	B.1. Collision Free Communication		B.1. Collision Free Communication
	TSCH allows one to design a schedule which yields collision-free		TSCH allows one to design a schedule which yields collision-free
	communication. This is done by building the schedule with dedicated		communication. This is done by building the schedule with dedicated
	cells in such a way that at most one node communicates with a		cells in such a way that at most one node communicates with a
	specific neighbor in each slotOffset/channelOffset cell. Multiple		specific neighbor in each slotOffset/channelOffset cell. Multiple
	pairs of neighbor motes can exchange data at the same time, but on		pairs of neighbor nodes can exchange data at the same time, but on
	different frequencies.		different frequencies.
	B.2. Multi-Channel vs. Channel Hopping		B.2. Multi-Channel vs. Channel Hopping
	A TSCH schedule looks like a matrix of width "slotframe size", S, and		A TSCH schedule looks like a matrix of width "slotframe size", S, and
	of height "number of frequencies", nFreq. For a scheduling		of height "number of frequencies", nFreq. For a scheduling
	algorithm, these can be considered atomic "units" to schedule. In		algorithm, these can be considered atomic "units" to schedule. In
	particular, because of the channel hopping nature of TSCH, the		particular, because of the channel hopping nature of TSCH, the
	scheduling algorithm should not worry about the actual frequency		scheduling algorithm should not worry about the actual frequency
	communication happens on, since it changes at each slotframe		communication happens on, since it changes at each slotframe
	iteration.		iteration.
	B.3. Cost of (continuous) Synchronization		B.3. Cost of (continuous) Synchronization
	When there is traffic in the network, motes which are communicating		When there is traffic in the network, nodes which are communicating
	implicitly re-synchronize using the data frames they exchange. In		implicitly re-synchronize using the data frames they exchange. In
	the absence of data traffic, motes are required to synchronize to		the absence of data traffic, nodes are required to synchronize to
	their time source neighbor(s) periodically not to drift in time. If		their time source neighbor(s) periodically not to drift in time. If
	they have not been communicating for some time (typically 30s), motes		they have not been communicating for some time (typically 30s), nodes
	can exchange an dummy data frame to re-synchronize. The frequency at		can exchange an dummy data frame to re-synchronize. The frequency at
	which such messages need to be transmitted depends on the stability		which such messages need to be transmitted depends on the stability
	of the clock source, and on how "early" each mote starts listening		of the clock source, and on how "early" each node starts listening
	for data (the "guard time"). Theoretically, with a 10ppm clock and a		for data (the "guard time"). Theoretically, with a 10ppm clock and a
	1ms guard time, this period can be 100s. Assuming this exchange		1ms guard time, this period can be 100s. Assuming this exchange
	causes the mote's radio to be on for 5ms, this yields a radio duty		causes the node's radio to be on for 5ms, this yields a radio duty
	cycle needed to keep synchronized of 5ms/100s=0.005%. While TSCH does		cycle needed to keep synchronized of 5ms/100s=0.005%. While TSCH does
	requires motes to resynchronize periodically, the cost of doing so is		requires nodes to resynchronize periodically, the cost of doing so is
	very low.		very low.
	B.4. Topology Stability		B.4. Topology Stability
	The channel hopping nature of TSCH causes links to be very "stable".		The channel hopping nature of TSCH causes links to be very "stable".
	Wireless phenomena such as multi-path fading and external		Wireless phenomena such as multi-path fading and external
	interference impact a wireless link between two motes differently on		interference impact a wireless link between two nodes differently on
	each frequency. If a transmission from mote A to mote B fails,		each frequency. If a transmission from node A to node B fails,
	retransmitting on a different frequency has a higher likelihood of		retransmitting on a different frequency has a higher likelihood of
	succeeding that retransmitting on the same frequency. As a result,		succeeding that retransmitting on the same frequency. As a result,
	even when some frequencies are "behaving bad", channel hopping		even when some frequencies are "behaving bad", channel hopping
	"smoothens" the contribution of each frequency, resulting in more		"smoothens" the contribution of each frequency, resulting in more
	stable links, and therefore a more stable topology.		stable links, and therefore a more stable topology.
	B.5. Multiple Concurrent Slotframes		B.5. Multiple Concurrent Slotframes
	The TSCH standard allows for multiple slotframes to coexist in a		The TSCH standard allows for multiple slotframes to coexist in a
	mote's schedule. It is possible that, at some timeslot, a mote has		node's schedule. It is possible that, at some timeslot, a node has
	multiple activities scheduled (e.g. transmit to mote B on slotframe		multiple activities scheduled (e.g. transmit to node B on slotframe
	2, receive from mote C on slotframe 1). To handle this situation,		2, receive from node C on slotframe 1). To handle this situation,
	the TSCH standard defines the following precedence rules:		the TSCH standard defines the following precedence rules:
	1. Transmissions take precedence over receptions;		1. Transmissions take precedence over receptions;
	2. Lower slotframe identifiers take precedence over higher slotframe		2. Lower slotframe identifiers take precedence over higher slotframe
	identifiers.		identifiers.
	In the example above, the mote would transmit to mote B on slotframe		In the example above, the node would transmit to node B on slotframe
	2.		2.
	Authors' Addresses		Authors' Addresses
	Thomas Watteyne (editor)		Thomas Watteyne (editor)
	Linear Technology		Linear Technology
	30695 Huntwood Avenue		30695 Huntwood Avenue
	Hayward, CA 94544		Hayward, CA 94544
	USA		USA
End of changes. 83 change blocks.
	110 lines changed or deleted		125 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/