draft-ietf-6tisch-tsch-05.txt		draft-ietf-6tisch-tsch-06.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: July 12, 2015 University of Luxembourg		Expires: September 10, 2015 University of Luxembourg
	LA. Grieco		LA. Grieco
	Politecnico di Bari		Politecnico di Bari
	January 8, 2015		March 9, 2015
	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-05		draft-ietf-6tisch-tsch-06
	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 July 12, 2015.		This Internet-Draft will expire on September 10, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4
	3. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4		3. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 6
	4. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 6		3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 6
	4.1. Network Formation . . . . . . . . . . . . . . . . . . . . 7		3.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7
	4.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7		3.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 7
	4.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 7		3.4. Routing and Timing Parents . . . . . . . . . . . . . . . 7
	4.4. Routing and Timing Parents . . . . . . . . . . . . . . . 8		3.5. Resource Management . . . . . . . . . . . . . . . . . . . 8
	4.5. Resource Management . . . . . . . . . . . . . . . . . . . 8		3.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8
	4.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8		3.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8
	4.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8		3.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 9
	4.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 9		3.9. Secure Communication . . . . . . . . . . . . . . . . . . 9
	4.9. Secure Communication . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 10
	8.3. External Informative References . . . . . . . . . . . . . 12
	Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 13		Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 13
	A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 13		A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 13
	A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 14		A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 14
	A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 14		A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 14
	A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 14		A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 14
	A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 15		A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 15
	A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 15		A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 15
	A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 16		A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 16
	A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 16		A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 16
	A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 17		A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 17
	A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 17		A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 17
	A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 18		A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 18
	A.12. Information Elements . . . . . . . . . . . . . . . . . . 18		A.12. Information Elements . . . . . . . . . . . . . . . . . . 18
	A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 18		A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 18
	Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 19		Appendix B. TSCH Features . . . . . . . . . . . . . . . . . . . 19
	B.1. Collision Free Communication . . . . . . . . . . . . . . 19		B.1. Collision Free Communication . . . . . . . . . . . . . . 19
	B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 19		B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 19
	B.3. Cost of (continuous) Synchronization . . . . . . . . . . 19		B.3. Cost of (continuous) Synchronization . . . . . . . . . . 19
	B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 20		B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 20
	B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 20		B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	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.
	This document describes the main issues arising from the adoption of		This document describes the main issues arising from the adoption of
	the IEEE802.15.4e TSCH in the LLN context, following the terminology		the IEEE802.15.4e TSCH in the LLN context, following the terminology
	defined in [I-D.ietf-6tisch-terminology].		defined in [I-D.ietf-6tisch-terminology]. Appendix A further gives
			an overview of the key features of the IEEE802.15.4e Timeslotted
			Channel Hopping (TSCH) amendment. Appendix B details features of
			IEEE802.15.4e TSCH which might be interesting for the work of the
			6TiSCH WG.
	TSCH was designed to allow IEEE802.15.4 devices to support a wide		TSCH was designed to allow IEEE802.15.4 devices to support a wide
	range of applications including, but not limited to, industrial ones		range of applications including, but not limited to, industrial ones
	[IEEE802154e]. At its core is a medium access technique which uses		[IEEE802154e]. At its core is a medium access technique which uses
	time synchronization to achieve ultra low-power operation and channel		time synchronization to achieve low power operation and channel
	hopping to enable high reliability. Synchronization accuracy impacts		hopping to enable high reliability. Synchronization accuracy impacts
	power consumption, and can vary from micro-seconds to milli-seconds		power consumption, and can vary from micro-seconds to milli-seconds
	depending on the solution. This is very different from the "legacy"		depending on the solution. This is very different from the "legacy"
	IEEE802.15.4 MAC protocol, and is therefore better described as a		IEEE802.15.4 MAC protocol, and is therefore better described as a
	"redesign". TSCH does not amend the physical layer; i.e., it can		"redesign". TSCH does not amend the physical layer; i.e., it can
	operate on any IEEE802.15.4-compliant hardware.		operate on any IEEE802.15.4-compliant hardware.
	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
	skipping to change at page 3, line 50		skipping to change at page 4, line 5
	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,		IEEE802.15.4e has been designed for low-power constrained devices,
	often called "motes". Several terms are used in the IETF to refer to		often called "motes". Several terms are used in the IETF to refer to
	those devices, including "LLN nodes" [RFC7102] and "constrained		those devices, including "LLN nodes" [RFC7102] and "constrained
	nodes" [RFC7228]. In this document, we use the generic (and shorter)		nodes" [RFC7228]. In this document, we use the generic (and shorter)
	term "node", used as a synonym for "LLN node", "constrained node" or		term "node", used as a synonym for "LLN node", "constrained node" or
	"mote".		"mote".
	Bringing industrial-like performance into the LLN stack developed by		Enabling the LLN protocol stack to operate in industrial environments
	Internet of Things (IoT) related IETF working groups such as 6Lo,		opens up new application domains for these networks. Sensors
	ROLL and CoRE opens up new application domains for these networks.		deployed in smart cities [RFC5548] will be able to be installed for
			years without needing battery replacement. "Umbrella" networks will
	Sensors deployed in smart cities [RFC5548] will be able to be		interconnect smart elements from different entities in smart
	installed for years without needing battery replacement. "Umbrella"		buildings [RFC5867]. Peel-and-stick switches will obsolete the need
	networks will interconnect smart elements from different entities in		for costly conduits for lighting solutions in smart homes [RFC5826].
	smart buildings [RFC5867]. Peel-and-stick switches will obsolete the
	need for costly conduits for lighting solutions in smart homes
	[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
	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
	Link Control (LLC) layer between the IP abstraction of a link and the		functional entity which is in charge of scheduling TSCH timeslots for
	TSCH MAC, which is in charge of scheduling a timeslot for a given		frames to be sent on. In this document, we refer to this entity as
	packet coming down the stack from the upper layer.		the "Logical Link Control" (LLC), bearing in mind that realizations
			of this entity can be of different types, including a distributed
			protocol or a centralized server in charge of scheduling.
	While [IEEE802154e] defines the mechanisms for a TSCH node 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
	and strong customizations, simplifying the merging of TSCH with a		and strong customizations, simplifying the merging of TSCH with a
	protocol stack based on IPv6, 6LoWPAN, and RPL.		protocol stack based on IPv6, 6LoWPAN, and RPL.
	2. Requirements Language		2. TSCH in the LLN Context
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	3. TSCH in the LLN Context
	To map the services required by the IP layer to the services provided		To map the services required by the IP layer to the services provided
	by the link layer, an adaptation layer is used		by the link layer, an adaptation layer is used
	[palattella12standardized]. The 6LoWPAN working group started		[palattella12standardized]. The 6LoWPAN working group started
	working in 2007 on specifications for transmitting IPv6 packets over		working in 2007 on specifications for transmitting IPv6 packets over
	IEEE802.15.4 networks [RFC4919]. Low-power WPANs are characterized		IEEE802.15.4 networks [RFC4919]. Low-power Wireless Personal Area
	by small packet sizes, support for addresses with different lengths,		Networks (WPANs) typically feature small frame sizes, support for
	low bandwidth, star and mesh topologies, battery powered devices, low		addresses with different lengths, low bandwidth, star and mesh
	cost, large number of devices, unknown node positions, high		topologies, battery powered devices, low cost, large number of
	unreliability, and periods during which communication interfaces are		devices, unknown node positions, high unreliability, and periods
	turned off to save energy. Given these features, it is clear that		during which communication interfaces are turned off to save energy.
	the adoption of IPv6 on top of a Low-Power WPAN is not		Given these features, it is clear that the adoption of IPv6 on top of
	straightforward, but poses strong requirements for the optimization		a Low-Power WPAN is not straightforward, but poses strong
	of this adaptation layer.		requirements for the optimization of this adaptation layer.
	For instance, due to the IPv6 default minimum MTU size (1280 bytes),		For instance, due to the IPv6 default minimum MTU size (1280 bytes),
	an un-fragmented IPv6 packet is too large to fit in an IEEE802.15.4		an un-fragmented IPv6 packet is too large to fit in an IEEE802.15.4
	frame. Moreover, the overhead due to the 40-byte long IPv6 header		frame. Moreover, the overhead due to the 40-byte long IPv6 header
	wastes the scarce bandwidth available at the PHY layer [RFC4944].		wastes the scarce bandwidth available at the PHY layer [RFC4944].
	For these reasons, the 6LoWPAN working group has defined an effective		For these reasons, the 6LoWPAN working group has defined an effective
	adaptation layer [RFC6282]. Further issues encompass the auto-		adaptation layer [RFC6282]. Further issues encompass the auto-
	configuration of IPv6 addresses [RFC2460][RFC4862], the compliance		configuration of IPv6 addresses [RFC2460][RFC4862], the compliance
	with the recommendation on supporting link-layer subnet broadcast in		with the recommendation on supporting link-layer subnet broadcast in
	shared networks [RFC3819], the reduction of routing and management		shared networks [RFC3819], the reduction of routing and management
	overhead [RFC6606], the adoption of lightweight application protocols		overhead [RFC6606], the adoption of lightweight application protocols
	(or novel data encoding techniques), and the support for security		(or novel data encoding techniques), and the support for security
	mechanisms (confidentiality and integrity protection, device		mechanisms (confidentiality and integrity protection, device
	bootstrapping, key establishment, and management).		bootstrapping, key establishment, and management).
	These features can run on top of TSCH. There are, however, important		These features can run on top of TSCH. There are, however, important
	issues to solve, as highlighted in Section 4.		issues to solve, as highlighted in Section 3.
	Routing issues are challenging for 6LoWPAN, given the low-power and		Routing issues are challenging for 6LoWPAN, given the low-power and
	lossy radio links, the battery-powered nodes, the multi-hop mesh		lossy radio links, the battery-powered nodes, the multi-hop mesh
	topologies, and the frequent topology changes due to mobility.		topologies, and the frequent topology changes due to mobility.
	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
	skipping to change at page 6, line 19		skipping to change at page 6, line 15
	(P2MP) data streams are used for actuation purposes, where messages		(P2MP) data streams are used for actuation purposes, where messages
	are sent from DODAG roots to destination nodes. Point-to-Point (P2P)		are sent from DODAG roots to destination nodes. Point-to-Point (P2P)
	traffic allows communication between two devices belonging to the		traffic allows communication between two devices belonging to the
	same LLN, such as a sensor and an actuator. A packet flows from the		same LLN, such as a sensor and an actuator. A packet flows from the
	source to the common ancestor of those two communicating devices,		source to the common ancestor of those two communicating devices,
	then downward towards the destination. RPL therefore has to discover		then downward towards the destination. RPL therefore has to discover
	both upward routes (i.e. from nodes to DODAG roots) in order to		both upward routes (i.e. from nodes to DODAG roots) in order to
	enable MP2P and P2P flows, and downward routes (i.e. from DODAG roots		enable MP2P and P2P flows, and downward routes (i.e. from DODAG roots
	to nodes) to support P2MP and P2P traffic.		to nodes) to support P2MP and P2P traffic.
	Section 4 highlights the challenges that need to be addressed to use		Section 3 highlights the challenges that need to be addressed to use
	RPL on top of TSCH.		RPL on top of TSCH.
	Several open-source initiatives have emerged around TSCH. The		Open-source initiatives have emerged around TSCH, with the OpenWSN
	OpenWSN project [OpenWSN][OpenWSNETT] is an open-source		project [OpenWSN][OpenWSNETT] being the first open-source
	implementation of a standards-based protocol stack, which aims at		implementation of a standards-based protocol stack. This
	evaluating the applicability of TSCH to different applications. This
	implementation was used as the foundation for an IP for Smart Objects		implementation was used as the foundation for an IP for Smart Objects
	Alliance (IPSO) [IPSO] interoperability event in 2011. In the		Alliance (IPSO) [IPSO] interoperability event in 2011. In the
	absence of a standardized scheduling mechanism for TSCH, a "slotted		absence of a standardized scheduling mechanism for TSCH, a "slotted
	Aloha" schedule was used.		Aloha" schedule was used.
	4. Problems and Goals		3. Problems and Goals
	As highlighted in Appendix A, TSCH differs from traditional low-power		As highlighted in Appendix A, TSCH differs from other low-power MAC
	MAC protocols because of its scheduled nature. TSCH defines the		protocols because of its scheduled nature. TSCH defines the
	mechanisms to execute a communication schedule, yet it is the entity		mechanisms to execute a communication schedule, yet it is the entity
	that sets up that schedule which controls the topology of the		that sets up that schedule which controls the topology of the
	network. This scheduling entity also controls the resources		network. This scheduling entity also controls the resources
	allocated to each link in that topology.		allocated to each link in that topology.
	How this entity should operate is out of scope of TSCH. The		How this entity should operate is out of scope of TSCH. The
	remainder of this section highlights the problems this entity needs		remainder of this section highlights the problems this entity needs
	to address. For simplicity, we refer to this entity by the generic		to address. For simplicity, we refer to this entity by the generic
	name "LLC". Note that the 6top sublayer, currently being defined in		name "LLC". Note that the 6top sublayer, currently being defined in
	[I-D.wang-6tisch-6top-sublayer], can be seen as an embodiment of this		[I-D.wang-6tisch-6top-sublayer], can be seen as an embodiment of this
	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		3.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 nodes join, and how already joined nodes 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.		[IEEE802154e] advertising the presence of the network.
	2. For a new node, 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 node, 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		3.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 nodes to stay synchronized. The LLC needs to:		health, allowing for nodes to stay synchronized. The LLC needs to:
	1. Manage each node's time source neighbor.		1. Manage each node's time source neighbor.
	2. Define a mechanism for a node 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		3.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:
	1. Define a mechanism to gather topological information, node and		1. Define a mechanism to gather topological information, node and
	link state, which it can then feed to RPL.		link state, which it 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 (a cell in a TSCH schedule is an atomic
			"unit" of resource, see Section 3.5).
	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		3.4. Routing and Timing Parents
	At all times, a TSCH node 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		3.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 nodes 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 Path Computation Element (PCE), etc.) to take control
			of the schedule.
	4.6. Dataflow Control		3.6. Dataflow Control
	TSCH defines mechanisms for a node 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. Allow for the implementation and configuration of policy to queue
			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
	times, without receiving an acknowledgment. This covers both		times, without receiving an acknowledgment. This covers both
	dedicated and shared cells.		dedicated and shared cells.
	4.7. Deterministic Behavior		3.7. Deterministic Behavior
	As highlighted in [RFC5673], in some applications, data is generated		As highlighted in [RFC5673], in some applications, data is generated
	periodically and has a well understood data bandwidth requirement,		periodically and has a well understood data bandwidth requirement,
	which is deterministic and predictable. The LLC needs to:		which is deterministic and predictable. The LLC needs to:
	1. Ensure timely delivery of such data.		1. Ensure that the data is delivered to its final destination before
			a deadline possibly determined by the application.
	2. Provide a mechanism for such deterministic flows to coexist with		2. Provide a mechanism for such deterministic flows to coexist with
	bursty or infrequent traffic flows of different priorities.		bursty or infrequent traffic flows of different priorities.
	4.8. Scheduling Mechanisms		3.8. Scheduling Mechanisms
	Several scheduling mechanisms can be envisioned, and possibly coexist		Several scheduling mechanisms can be envisioned, and possibly coexist
	in the same network. For example,		in the same network. For example,
	[I-D.phinney-roll-rpl-industrial-applicability] describes how the		[I-D.phinney-roll-rpl-industrial-applicability] describes how the
	allocation of bandwidth can be optimized by an external Path		allocation of bandwidth can be optimized by an external Path
	Computation Element (PCE). Another centralized (PCE-based) traffic-		Computation Element (PCE) [RFC4655]. Another centralized (PCE-based)
	aware scheduling algorithm is defined in [TASA-PIMRC].		traffic-aware scheduling algorithm is defined in [TASA-PIMRC].
	Alternatively, two neighbor nodes can adapt the number of cells		Alternatively, two neighbor nodes can adapt the number of cells
	autonomously by monitoring the amount of traffic, and negotiating the		autonomously by monitoring the amount of traffic, and negotiating the
	allocation to extra cell when needed. An example of decentralized		allocation to extra cell when needed. An example of decentralized
	algorithm is provided in [tinka10decentralized]. This mechanism can		algorithm (i.e. no PCE is needed) is provided in
	be used to establish multi-hop paths in a fashion similar to RSVP.		[tinka10decentralized]. This mechanism can be used to establish
	The LLC needs to:		multi-hop paths in a fashion similar to RSVP [RFC2205]. The LLC
			needs to:
	1. Provide a mechanism for two 6TiSCH devices to negotiate the		1. Provide a mechanism for two devices to negotiate the allocation
	allocation and deallocation of cells between them.		and deallocation of cells between them.
	2. Provide a mechanism for device to monitor and manage the 6TiSCH		2. Provide a mechanism for device to monitor and manage the
	capabilities of a node several hops away.		capabilities of a node several hops away.
	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		3.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 node 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 nodes.		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 nodes and the LLC.		data between nodes and the LLC.
	5. IANA Considerations		4. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	6. Security Considerations		5. 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 not define any new mechanisms or protocols.
	It does describe the need for the 6TiSCH WG to define a secure		It does describe the need for the 6TiSCH WG to define a secure
	solution. In particular, Section 4.1 describes security in the join		solution. In particular, Section 3.1 describes security in the join
	process. Section 4.9 discusses data frame protection.		process. Section 3.9 discusses data frame protection.
	7. Acknowledgments		6. Acknowledgments
	Special thanks to Dominique Barthel, Patricia Brett, Guillaume		Special thanks to Dominique Barthel, Patricia Brett, Guillaume
	Gaillard, Pat Kinney, Ines Robles, Timothy J. Salo, Jonathan Simon,		Gaillard, Pat Kinney, Ines Robles, Timothy J. Salo, Jonathan Simon,
	Rene Struik, Xavi Vilajosana for reviewing the document and providing		Rene Struik, Xavi Vilajosana for reviewing the document and providing
	valuable feedback. Thanks to the IoT6 European Project (STREP) of		valuable feedback. Thanks to the IoT6 European Project (STREP) of
	the 7th Framework Program (Grant 288445).		the 7th Framework Program (Grant 288445).
	8. References		7. References
	8.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[IEEE802154e]
	Requirement Levels", BCP 14, RFC 2119, March 1997.		IEEE standard for Information Technology, "IEEE std.
			802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
			Networks (LR-WPANs) Amendment 1: MAC sublayer", April
			2012.
	8.2. Informative References		[IEEE802154]
			IEEE standard for Information Technology, "IEEE std.
			802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
			and Physical Layer (PHY) Specifications for Low-Rate
			Wireless Personal Area Networks", June 2011.
			7.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		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228, May 2014.		Constrained-Node Networks", RFC 7228, May 2014.
	[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and		[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
	Lossy Networks", RFC 7102, January 2014.		Lossy Networks", RFC 7102, January 2014.
	skipping to change at page 11, line 29		skipping to change at page 11, line 42
	Networks", RFC 4944, September 2007.		Networks", RFC 4944, September 2007.
	[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6		[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
	over Low-Power Wireless Personal Area Networks (6LoWPANs):		over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals", RFC		Overview, Assumptions, Problem Statement, and Goals", RFC
	4919, August 2007.		4919, August 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.
			[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
			Element (PCE)-Based Architecture", RFC 4655, August 2006.
	[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.
			[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
			Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
			Functional Specification", RFC 2205, September 1997.
	[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-03 (work in
	progress), July 2014.		progress), January 2015.
	[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.
	[I-D.phinney-roll-rpl-industrial-applicability]		[I-D.phinney-roll-rpl-industrial-applicability]
	Phinney, T., Thubert, P., and R. Assimiti, "RPL		Phinney, T., Thubert, P., and R. Assimiti, "RPL
	applicability in industrial networks", draft-phinney-roll-		applicability in industrial networks", draft-phinney-roll-
	rpl-industrial-applicability-02 (work in progress),		rpl-industrial-applicability-02 (work in progress),
	February 2013.		February 2013.
	8.3. External Informative References
	[IEEE802154e]
	IEEE standard for Information Technology, "IEEE std.
	802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
	Networks (LR-WPANs) Amendment 1: MAC sublayer", April
	2012.
	[IEEE802154]
	IEEE standard for Information Technology, "IEEE std.
	802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
	and Physical Layer (PHY) Specifications for Low-Rate
	Wireless Personal Area Networks", June 2011.
	[OpenWSN] "Berkeley's OpenWSN Project Homepage",		[OpenWSN] "Berkeley's OpenWSN Project Homepage",
	<http://www.openwsn.org/>.		<http://www.openwsn.org/>.
	[OpenWSNETT]		[OpenWSNETT]
	Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,		Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
	Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:		Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
	a Standards-Based Low-Power Wireless Development		a Standards-Based Low-Power Wireless Development
	Environment", Transactions on Emerging Telecommunications		Environment", Transactions on Emerging Telecommunications
	Technologies , August 2012.		Technologies , August 2012.
	[IPSO] "IP for Smart Objects Alliance Homepage",		[IPSO] "IP for Smart Objects Alliance Homepage",
	<http://www.ipso-alliance.org/>.		<http://www.ipso-alliance.org/>.
	[CurrentCalculator]		[CurrentCalculator]
	Linear Technology, "Application Note: Using the Current		Linear Technology, "Application Note: Using the Current
	Calculator to Estimate Mote Power", August 2012,		Calculator to Estimate Mote Power", August 2012,
	<http://cds.linear.com/docs/en/application-note/		<http://www.linear.com/docs/42452>.
	Application_Note_-
	_Using_the_Current_Calculator_to_Estimate_Mote_Power.pdf>.
	[doherty07channel]		[doherty07channel]
	Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific		Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific
	Wireless Sensor Network Path Data", IEEE International		Wireless Sensor Network Path Data", IEEE International
	Conference on Computer Communications and Networks (ICCCN)		Conference on Computer Communications and Networks (ICCCN)
	2008, 2007.		2008, 2007.
	[tinka10decentralized]		[tinka10decentralized]
	Tinka, A., Watteyne, T., and K. Pister, "A Decentralized		Tinka, A., Watteyne, T., and K. Pister, "A Decentralized
	Scheduling Algorithm for Time Synchronized Channel		Scheduling Algorithm for Time Synchronized Channel
	Hopping", Ad Hoc Networks 2010, 2010, <		Hopping", Ad Hoc Networks 2010, 2010.
	http://robotics.eecs.berkeley.edu/~pister/
	publications/2008/TSMP%20DSN08.pdf>.
	[watteyne09reliability]		[watteyne09reliability]
	Watteyne, T., Mehta, A., and K. Pister, "Reliability		Watteyne, T., Mehta, A., and K. Pister, "Reliability
	Through Frequency Diversity: Why Channel Hopping Makes		Through Frequency Diversity: Why Channel Hopping Makes
	Sense", International Conference on Performance Evaluation		Sense", International Conference on Performance Evaluation
	of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-		of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-
	WASUN) 2009, Oct. 2009, <http://www.ietf.org/mail-		WASUN) 2009, Oct. 2009.
	archive/web/roll/current/pdfa_EzmuDIv3.pdf>.
	[TASA-PIMRC]		[TASA-PIMRC]
	Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,		Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,
	and G. Boggia, "Traffic Aware Scheduling Algorithm for		and G. Boggia, "Traffic Aware Scheduling Algorithm for
	Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, Sept.		Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, Sept.
	2012, < http://www.cttc.es/resources/		2012.
	doc/120531-submitted-tasa-25511.pdf>.
	[palattella12standardized]		[palattella12standardized]
	Palattella, MR., Accettura, N., Vilajosana, X., Watteyne,		Palattella, MR., Accettura, N., Vilajosana, X., Watteyne,
	T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized		T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized
	Protocol Stack For The Internet Of (Important) Things",		Protocol Stack For The Internet Of (Important) Things",
	IEEE Communications Surveys and Tutorials 2012, Dec. 2012,		IEEE Communications Surveys and Tutorials 2012, Dec. 2012.
	< http://www.cttc.es/resources/doc/121025-
	completestackforiot-clean-4818610916636121981.pdf>.
	Appendix A. TSCH Protocol Highlights		Appendix A. TSCH Protocol Highlights
	This appendix gives an overview of the key features of the		This appendix gives an overview of the key features of the
	IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes		IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes
	no attempt at repeating the standard, but rather focuses on the		no attempt at repeating the standard, but rather focuses on the
	following:		following:
	o Concepts which are sufficiently different from traditional		o Concepts which are sufficiently different from other IEEE802.15.4
	IEEE802.15.4 networking that they may need to be defined and		networking that they may need to be defined and presented
	presented precisely.		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 nodes 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 node A to node B, and for node 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.
	skipping to change at page 19, line 8		skipping to change at page 19, line 8
	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.
	Appendix B. TSCH Gotchas		Appendix B. TSCH Features
	This section lists features of TSCH which we believe are important		This section details features of IEEE802.15.4e TSCH which might be
	and beneficial to the work of 6TiSCH.		interesting for the work of the 6TiSCH WG. It does not define any
			requirements.
	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 nodes 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.
End of changes. 56 change blocks.
	133 lines changed or deleted		127 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/