< draft-vilajosana-6tsch-basic-00.txt		draft-vilajosana-6tsch-basic-01.txt >
	6TSCH X. Vilajosana, Ed.		6TSCH X. Vilajosana, Ed.
	Internet-Draft Universitat Oberta de Catalunya		Internet-Draft Universitat Oberta de Catalunya
	Intended status: Informational June 20, 2013		Intended status: Informational K. Pister
	Expires: December 22, 2013		Expires: January 15, 2014 University of California Berkeley
			July 14, 2013
	Minimal 6TSCH Configuration		Minimal 6TSCH Configuration
	draft-vilajosana-6tsch-basic-00		draft-vilajosana-6tsch-basic-01
	Abstract		Abstract
	This document describes the minimal set of rules to operate a		This document describes the minimal set of rules to operate a
	[IEEE802154e] Timeslotted Channel Hopping (TSCH) network. These		[IEEE802154e] Timeslotted Channel Hopping (TSCH) network. These
	rules can be used during early interoperability testing and		rules can be used during early interoperability testing and
	development, when the centralized and distributed solutions developed		development, when the centralized and distributed solutions developed
	by the 6TSCH group are not fully implemented yet, or otherwise not		by the 6TSCH group are not fully implemented yet, or otherwise not
	available.		available.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 36 ¶
	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 December 22, 2013.		This Internet-Draft will expire on January 15, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Basic Schedule . . . . . . . . . . . . . . . . . . . . . . . 2
	2.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Cells and cells Options . . . . . . . . . . . . . . . . . 4		2.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 5		2.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 5
	2.4. Time Slot timming . . . . . . . . . . . . . . . . . . . . 5		2.4. Time Slot timming . . . . . . . . . . . . . . . . . . . . 5
	3. Enhanced Beacons Configuration and Content . . . . . . . . . 6		3. Enhanced Beacons Configuration and Content . . . . . . . . . 6
	3.1. Sync IE . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Sync IE . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7		3.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7
	3.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 7		3.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Frame and Link IE . . . . . . . . . . . . . . . . . . . . 7		3.2. Frame and Link IE . . . . . . . . . . . . . . . . . . . . 7
	3.2.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7		3.2.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7
	3.2.2. IE Content . . . . . . . . . . . . . . . . . . . . . 7		3.2.2. IE Content . . . . . . . . . . . . . . . . . . . . . 8
	4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8		4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. ACK/NACK Time Correction IE . . . . . . . . . . . . . . . 8		4.1. ACK/NACK Time Correction IE . . . . . . . . . . . . . . . 8
	4.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 8		4.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 8
	4.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 8		4.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 8
	5. Neighbor information . . . . . . . . . . . . . . . . . . . . 9		5. Neighbor information . . . . . . . . . . . . . . . . . . . . 9
	5.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 9		5.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Time Parent Selection . . . . . . . . . . . . . . . . . . 10		5.2. Time Parent Selection . . . . . . . . . . . . . . . . . . 10
	6. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 10		6. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 11
	7.3. External Informative References . . . . . . . . . . . . . 11		7.3. External Informative References . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The nodes in a [IEEE802154e] TSCH network follow a communication		The nodes in a [IEEE802154e] TSCH network follow a communication
	schedule. The entity responsible for building and maintaining that		schedule. The entity (centralized or decentralized) responsible for
	schedule has very precise control over the trade-off between the		building and maintaining that schedule has very precise control over
	network's latency, bandwidth, reliability and power consumption.		the trade-off between the network's latency, bandwidth, reliability
	During early interoperability testing and development, however,		and power consumption. During early interoperability testing and
	simplicity is often more important than efficiency. The goal of this		development, however, simplicity is often more important than
	document is to defines the simplest set of rules for building a		efficiency. The goal of this document is to define the simplest set
			of rules for building a [IEEE802154e] TSCH-compliant network, at the
	[IEEE802154e] TSCH-compliant network, at the necessary price of		necessary price of lesser efficiency.
	lesser efficiency.
	2. Schedule
			2. Basic Schedule
	In order to form a network, a minimum schedule configuration is		In order to form a network, a minimum schedule configuration is
	required so nodes can advertise the presence of the network, and		required so nodes can advertise the presence of the network, and
	exchange data.		allow other nodes to join.
	2.1. Slotframe		2.1. Slotframe
	The slotframe, as defined by		The Slotframe, as defined in [I-D.palattella-6tsch-terminology], is
	[I-D.draft-palattella-6tsch-terminology], is an abstraction of the		an abstraction of the MAC layer that defines a collection of time
	MAC layer that defines a collection of time slots of equal length and		slots of equal length and priority, and which repeats over time. In
	priority, and which repeats over time. In order to set up a minimal		order to set up a basic TSCH network, nodes need to be synchronized
	TSCH network, nodes need to use the same slotframe configuration so		with the same slotframe configuration so they can exchange Enhanced
	they can exchange Enhanced Beacons (EBs) and data packets. This		Beacons (EBs) and data packets. This document recommends the
	document recommends the following slotframe configuration.		following slotframe configuration.
	Basic configuration configuration		Basic configuration
	+---------------------------------+----------------------+		+------------------------------------+----------------------+
	| Property | Value |		| Property | Value |
	+---------------------------------+----------------------+		+------------------------------------+----------------------+
	| Number of time slots | 101 |		| Number of time slots per Slotframe | 101 |
	+---------------------------------+----------------------+		+------------------------------------+----------------------+
	| Number of available channels | 16 |		| Number of available channels | 16 |
	+---------------------------------+----------------------+		+------------------------------------+----------------------+
	| Number of EBs slots | 1 (slotOffset 0) |		| Number of EBs cells | 1 (slotOffset 0) |
	+---------------------------------+----------------------+		+------------------------------------+----------------------+
	| Number of active cells | 5 (slotOffsets |		| Number of scheduled cells | 5 (slotOffsets |
	| | 1,2,3,4,5) |		| | 1,2,3,4,5) |
	+---------------------------------+----------------------+		+------------------------------------+----------------------+
	| Number of inactive slots | 95 (from slotOffset |		| Number of unscheduled cells | 95 (from slotOffset |
	| | 6 to 100) |		| | 6 to 100) |
	+---------------------------------+----------------------+		+------------------------------------+----------------------+
	| Number of MAC retransmissions | 3 |		| Number of MAC retransmissions (max)| 3 |
	+---------------------------------+----------------------+		+------------------------------------+----------------------+
	| Time Slot duration | 15ms |		| Time Slot duration | 15ms |
	+---------------------------------+----------------------+		+------------------------------------+----------------------+
	This schedule is hard-coded in each node. The slotframe is composed		The suggested basic schedule is hard-coded in each node. The
	of 101 time slots, the first slot in the slotframe is used to send		slotframe is composed of 101 time slots. The first slot in the
	Enhanced Beacons to announce the presence of the network. These EBs		slotframe is used to send Enhanced Beacons announcing the presence of
	are not acknowledged. Five cells are scheduled for exchangeing data		the network. These EBs are not acknowledged. Five cells are
	packets, as described in Section 2.2. These cells are scheduled at		scheduled for exchanging data packets, as described in Section 2.2.
	slotOffset 1 to 5, and channeOffset 0. Per the IEEE802.15.4e TSCH		These cells are scheduled at slotOffset 1 to 5, and channeOffset 0.
	standard, data packets sent on these cells to a unicast MAC address		Per the IEEE802.15.4e TSCH standard, data packets sent on these cells
	are acknowledged by the receiver. The 95 remaining cells are		to a unicast MAC address are acknowledged by the receiver. The 95
	inactive, i.e. the radio of the nodes remains off.		remaining cells are unscheduled, i.e., the radio of the nodes remains
			off.
	Basic schedule overview		Basic schedule overview
	+-----+-----+-----+-----+-----+-----+-----+ +-----+		+-----+-----+-----+-----+-----+-----+-----+ +-----+
	chan.Off. 0 | EB |TxRxS|TxRxS|TxRxS|TxRxS|TxRxS| OFF | ... | OFF |		chan.Off. 0 | EB |TxRxS|TxRxS|TxRxS|TxRxS|TxRxS| OFF | ... | OFF |
	+-----+-----+-----+-----+-----+-----+-----+ +-----+		+-----+-----+-----+-----+-----+-----+-----+ +-----+
	chan.Off. 1 | | | | | | | | ... | |		chan.Off. 1 | | | | | | | | ... | |
	+-----+-----+-----+-----+-----+-----+-----+ +-----+		+-----+-----+-----+-----+-----+-----+-----+ +-----+
	...		...
	+-----+-----+-----+-----+-----+-----+-----+ +-----+		+-----+-----+-----+-----+-----+-----+-----+ +-----+
	chan.Off. 15 | | | | | | | | ... | |		chan.Off. 15 | | | | | | | | ... | |
	+-----+-----+-----+-----+-----+-----+-----+ +-----+		+-----+-----+-----+-----+-----+-----+-----+ +-----+
	0 1 2 3 4 5 6 100		0 1 2 3 4 5 6 100
	2.2. Cells and cells Options		2.2. Cell Options
	Per the [IEEE802154e] TSCH standard, each active cell is assigned a		Per the [IEEE802154e] TSCH standard, each scheduled cell has a bitmap
	bitmap of cell options.		of cell options assigned. All scheduled cells in the basic schedule
			are configured as Hard cells
			[I-D.watteyne-6tsch-tsch-lln-context][I-D.draft-wang-6tsch-6top]
			since reallocation is not considered in that simple approach.
	The EB cell is assigned the following bitmap of cell options:		The EB cell is assigned the following bitmap of cell options:
	b0 = Transmit = 1 (set)		b0 = Transmit = 1 (set)
	b1 = Receive = 0 (clear)		b1 = Receive = 0 (clear)
	b2 = Shared = 0 (clear)		b2 = Shared = 0 (clear)
	b3 = Timekeeping = 0 (clear)		b3 = Timekeeping = 0 (clear)
	b4 = Hard = 1 (set)		b4 = Hard = 1 (set)
	b5-b7 = Reserved (clear)		b5-b7 = Reserved (clear)
	The data cells are assigned the bitmap of cell options below. This		The data cells are assigned the bitmap of cell options below that
	results in "Slotted Aloha" behavior. Because both the "Transmit" and		results in "Slotted Aloha" behavior. Because both the "Transmit" and
	"Receive" bits are set, the either transmits, or listens when it has		"Receive" bits are set, a node either transmits, if there is a packet
	nothing to transmit. Because the "shared" bit it set, it uses the		in its queue, or listens if it has nothing to transmit. Because the
	backoff mechanism defined in [IEEE802154e] TSCH to resolve		"shared" bit is set,in presence of collisions it uses the backoff
	collisions.		mechanism defined in [IEEE802154e].
	b0 = Transmit = 1 (set)		b0 = Transmit = 1 (set)
	b1 = Receive = 1 (set)		b1 = Receive = 1 (set)
	b2 = Shared = 1 (set)
			b2 = Shared = 1 (set)
	b3 = Timekeeping = 0 (clear)		b3 = Timekeeping = 0 (clear)
	b4 = Hard = 1 (set)		b4 = Hard = 1 (set)
	b5-b7 = Reserved (clear)		b5-b7 = Reserved (clear)
	All remaining cells are inactive, and so the nodes' radios remain		All remaining cells are unscheduled. Thus the nodes can keep their
	off. In a memory efficient implementation, active cells could be		radio off. In a memory efficient implementation, scheduled cells
	represented by a circular linked list. Inactive cells should not		could be represented by a circular linked list. Unscheduled cells
	occupy any memory.		should not occupy any memory.
	2.3. Retransmissions		2.3. Retransmissions
	The maximum number of MAC-layer retransmissions is set to 3. For		The maximum number of MAC-layer retransmissions is set to 3. For
	packets which require an acknowledgement, if none is received after a		packets which require an acknowledgement, if none is received after a
	total of 4 attempts, the transmissions is considered failed at the		total of 4 attempts, the transmissions is considered failed at the
	MAC layer, and the upper layer needs to be notified. Packets sent to		MAC layer, and the upper layer needs to be notified. Packets sent to
	the broadcast MAC address (including EBs) are not acknowledged and		the broadcast MAC address (including EBs) are not acknowledged and
	therefore not retransmitted.		therefore not retransmitted.
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 29 ¶
	Slot Slot		Slot Slot
	[IEEE802154e] does not define the different durations of a time slot.		[IEEE802154e] does not define the different durations of a time slot.
	It does allow those durations to be sent in the EBs (through a		It does allow those durations to be sent in the EBs (through a
	TimeSlot IE), but for simplicity, this document recommends to hard-		TimeSlot IE), but for simplicity, this document recommends to hard-
	code the different durations to the values listed below.		code the different durations to the values listed below.
	Timeslot durations		Timeslot durations
	+---------------------------------+------------------+		+---------------------------------+------------------+
	| IEEE802.15.4e TSCH duration | Value |		| IEEE802.15.4e TSCH parmeter | Value |
	+---------------------------------+------------------+		+---------------------------------+------------------+
	| TsTxOffset | 4000us |		| TsTxOffset | 4000us |
	+---------------------------------+------------------+		+---------------------------------+------------------+
	| TsLongGT | 1300us |		| TsLongGT | 2600us |
	+---------------------------------+------------------+		+---------------------------------+------------------+
	| TsTxAckDelay | 4606us |		| TsTxAckDelay | 4606us |
	+---------------------------------+------------------+		+---------------------------------+------------------+
	| TsShortGT | 500us |		| TsShortGT | 1000us |
	+---------------------------------+------------------+		+---------------------------------+------------------+
	| Time Slot duration | 15000us |		| Time Slot duration | 15000us |
	+---------------------------------+------------------+		+---------------------------------+------------------+
	3. Enhanced Beacons Configuration and Content		3. Enhanced Beacons Configuration and Content
	[IEEE802154e] does not define when EBs are sent. The choice of the		[IEEE802154e] does not define how often or which EBs are sent. The
	duration between two EBs needs to take into account whether EBs are		choice of the duration between two EBs needs to take into account
	used as the only mechanism to synchronize devices, or whether a Keep-		whether EBs are used as the only mechanism to synchronize devices, or
	Alive (KA) mechanism is used in parallel. For a simplest TSCH		whether a Keep-Alive (KA) mechanism is used in parallel. For a
	configuration, it is recommended to sent EBs at least once every 10s.		simplest TSCH configuration, it is recommended to sent EBs at least
			once every 10s. For additional reference see
			[I-D.watteyne-6tsch-tsch-lln-context] where different synchronization
			approaches are summarized.
	EBs must be sent with the Beacon IEEE802.15.4 frame type and this		EBs must be sent with the Beacon IEEE802.15.4 frame type and this
	document recommends that they carry the following Information		document recommends that they carry the following Information
	Elements (IEs):		Elements (IEs):
	3.1. Sync IE		3.1. Sync IE
	Contains synchronization information such as ASN and join priority.		Contains synchronization information such as ASN and join priority.
	3.1.1. IE Header		3.1.1. IE Header
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 6 ¶
	3.2.1. IE Header		3.2.1. IE Header
	Length (b0-b7) = variable		Length (b0-b7) = variable
	Sub-ID (b8-b14) = 0x1b		Sub-ID (b8-b14) = 0x1b
	Type (b15) = 0x00 (short)		Type (b15) = 0x00 (short)
	3.2.2. IE Content		3.2.2. IE Content
	# Slotframes (b16-b23) = 0x01		# Slotframes (b16-b23) = 0x01
	Slotframe ID (b24-b31) = 0x01		Slotframe ID (b24-b31) = 0x01
	Size Slotframe (b32-b47) = 0x65		Size Slotframe (b32-b47) = 0x65
	# Links (b48-b55) = 0x06		# Links (b48-b55) = 0x06
	For each link in the basic schedule:		For each link in the basic schedule:
	Channel Offset (2B) = 0x00		Channel Offset (2B) = 0x00
	Slot Number (2B) = from (0x00 to 0x05)		Slot Number (2B) = from (0x00 to 0x05)
	LinkOption (1B) = as described in Section 2.2		LinkOption (1B) = as described in Section 2.2
	4. Acknowledgement		4. Acknowledgement
	MAC-layer acknowledgement frames are built according to		MAC-layer acknowledgement frames are built according to
	[IEEE802154e]. Data frames and command frames sent to a unicast MAC		[IEEE802154e]. Data frames and command frames sent to a unicast MAC
	destination address request an acknowledged. The acknowledgement		destination address request an acknowledgement. The acknowledgement
	frame is of type ACK (0x10). Each acknowledgement contains the		frame is of type ACK (0x10). Each acknowledgement contains the
	following IE:		following IE:
	4.1. ACK/NACK Time Correction IE		4.1. ACK/NACK Time Correction IE
	The ACK/NACK time correction IE is used to carry the measured		The ACK/NACK time correction IE is used to carry the measured
	desynchronization between the sender and the receiver.		desynchronization between the sender and the receiver.
	4.1.1. IE Header		4.1.1. IE Header
	skipping to change at page 9, line 19 ¶		skipping to change at page 9, line 19 ¶
	+-----------------------------------+------------------+		+-----------------------------------+------------------+
	| ACK with negative time correction | 0x0800 - 0x0fff |		| ACK with negative time correction | 0x0800 - 0x0fff |
	+-----------------------------------+------------------+		+-----------------------------------+------------------+
	| NACK with positive time correction| 0x8000 - 0x87ff |		| NACK with positive time correction| 0x8000 - 0x87ff |
	+-----------------------------------+------------------+		+-----------------------------------+------------------+
	| NACK with negative time correction| 0x8800 - 0x8fff |		| NACK with negative time correction| 0x8800 - 0x8fff |
	+-----------------------------------+------------------+		+-----------------------------------+------------------+
	5. Neighbor information		5. Neighbor information
	[IEEE802154e] does not define when information is be kept at each		[IEEE802154e] does not define how and when each node in the network
	node about each neighbor. This document recommends to keep the		keeps information about its neighbors. This document recommends to
	following information in the neighbor table:		keep the following information in the neighbor table:
	5.1. Neighbor Table		5.1. Neighbor Table
	The exact format of the neighbor table is implementation-specific,		The exact format of the neighbor table is implementation-specific,
	but it should at least contain the following information, for each		but it should at least contain the following information, for each
	neighbor:		neighbor:
	Neighbor statistics:		Neighbor statistics:
	number of transmitted packets to that neighbor		number of transmitted packets to that neighbor
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 43 ¶
	number of transmitted packets that have been acknowledged by		number of transmitted packets that have been acknowledged by
	that neighbor		that neighbor
	number of received packets from that neighbor		number of received packets from that neighbor
	number of received packets that have been acknowledged for that		number of received packets that have been acknowledged for that
	neighbor		neighbor
	Neighbor address.		Neighbor address.
	ASN when that neighbor was last heard. This can be used to		ASN when that neighbor was heard for the last time. This can be
	trigger a keep-alive.		used to trigger a keep-alive message.
	RPL rank of that neighbor.		RPL rank of that neighbor.
	A flag which indicates whether this neighbor is a time source		A flag which indicates whether this neighbor is a time source
	neighbor.		neighbor.
	Connectivity statistics (RSSI, LQI, etc), which can be used to		Connectivity statistics (RSSI, LQI, etc), which can be used to
	help determine the quality of the link.		determine the quality of the link.
	In addition of that information, each node has to be able to compute		In addition of that information, each node has to be able to compute
	some RPL objective function (OF) taking into account the neighbor and		some RPL objective function (OF) taking into account the neighbor and
	connectivity statistics. An example RPL objective function is the		connectivity statistics. An example RPL objective function is the
	ETX.		ETX.
	5.2. Time Parent Selection		5.2. Time Parent Selection
	Each node selects a time parent amongst its known neighbors. When a		Each node selects a time parent amongst its known neighbors. When a
	node joins a network, it has no routing information yet. Its		node joins a network, it has no routing information yet. Its
	(possibly temporary) time parent is the node it can hear "best", for		(possibly temporary) time parent is the node it can hear "best", for
	example based on RSSI measurements of the EBs it received. After		example based on RSSI measurements of the EBs it received. After
	having acquired a RPL rank, the RPL routing parents should also be		having acquired a RPL rank, the RPL routing parents should also be
	IEEE802.15.4e time source neighbors.		IEEE802.15.4e time source neighbors.
	Optionally, a node can choose to use an counter to avoid frequent		Optionally, a node can choose to use an counter to avoid frequent
	changes in time source neighbor selection. Based on some thresholds		changes in time source neighbor selection. Based on some thresholds
	(on RSSI for example), if the quality of the link with time parent		(on RSSI for example), if the quality of the link with time parent
	changes over or below the thresholds for a certain number of times		changes over or below the thresholds for a certain number of times
	(e.g. 3), the instability counter is incremented and another time		(e.g., 3), the instability counter is incremented and another time
	parent is selected.		parent is selected.
	6. Queues and Priorities		6. Queues and Priorities
	[IEEE802154e] does not define the use of queues to handle upper layer		[IEEE802154e] does not define the use of queues to handle upper layer
	data (either application or control data from upper layers). This		data (either application or control data from upper layers). This
	document recommends to use a single queue with the following rules:		document recommends to use a single queue with the following rules:
	When the node is not synchronized to the network, higher layers		When the node is not synchronized to the network, higher layers
	are not able to insert packets into the queue.		are not able to insert packets into the queue.
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 5 ¶
	One entry in the queue is reserved at all times for a IEEE802.15.4		One entry in the queue is reserved at all times for a IEEE802.15.4
	frames of types Beacon or Command frames.		frames of types Beacon or Command frames.
	7. References		7. References
	7.1. Normative References		7.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.
	7.2. Informative References
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
	Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.		Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
	Alexander, "RPL: IPv6 Routing Protocol for Low-Power and		Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
	Lossy Networks", RFC 6550, March 2012.		Lossy Networks", RFC 6550, March 2012.
			7.2. Informative References
			[I-D.watteyne-6tsch-tsch-lln-context]
			Watteyne, T., Palattella, M., and L. Grieco, "Using
			IEEE802.15.4e TSCH in an LLN context: Overview, Problem
			Statement and Goals", draft-watteyne-6tsch-tsch-lln-
			context-02 (work in progress), May 2013.
			[I-D.thubert-6tsch-architecture]
			Thubert, P., Assimiti, R., and T. Watteyne, "An
			Architecture for IPv6 over Time Slotted Channel Hopping",
			draft-thubert-6tsch-architecture-01 (work in progress),
			April 2013.
			[I-D.palattella-6tsch-terminology]
			Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
			"Terminology in IPv6 over Time Slotted Channel Hopping",
			draft-palattella-6tsch-terminology-00 (work in progress),
			March 2013.
			[I-D.draft-wang-6tsch-6top]
			Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TSCH
			Operation Sublayer (6top). draft-wang-6tsch-6top-00 (work
			in progress) ", July 2013.
			[I-D.ohba-6tsch-security]
			Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and
			A. Yegin, "Security Framework and Key Management Protocol
			Requirements for 6TSCH", draft-ohba-6tsch-security-01
			(work in progress), July 2013.
	[I-D.ietf-roll-terminology]		[I-D.ietf-roll-terminology]
	Vasseur, J., "Terminology in Low power And Lossy		Vasseur, J., "Terminology in Low power And Lossy
	Networks", draft-ietf-roll-terminology-12 (work in		Networks", draft-ietf-roll-terminology-12 (work in
	progress), March 2013.		progress), March 2013.
	[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.
	[I-D.watteyne-6tsch-tsch-lln-context]
	Watteyne, T., Palattella, M., and L. Grieco, "Using
	IEEE802.15.4e TSCH in an LLN context: Overview, Problem
	Statement and Goals", draft-watteyne-6tsch-tsch-lln-
	context-02 (work in progress), May 2013.
	[I-D.draft-palattella-6tsch-terminology]
	Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q.
	Wang, "Terminology in IPv6 over Time Slotted Channel
	Hopping. draft-palattella-6tsch-terminology-00 (work in
	progress) ", March 2013.
	[I-D.draft-thubert-6tsch-architecture]
	Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An
	Architecture for IPv6 over Time Synchronized Channel
	Hopping. draft-thubert-6tsch-architecture-00 (work in
	progress) ", March 2013.
	[I-D.draft-wang-6tsch-6tus]
	Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6tus Sub-
	Layer Specification. draft-wang-6tsch-6tus-01 (work in
	progress) ", May 2013.
	7.3. External Informative References		7.3. External Informative References
	[IEEE802154e]		[IEEE802154e]
	IEEE standard for Information Technology, "IEEE std.		IEEE standard for Information Technology, "IEEE std.
	802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area		802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
	Networks (LR-WPANs) Amendament 1: MAC sublayer", April		Networks (LR-WPANs) Amendament 1: MAC sublayer", April
	2012.		2012.
	[IEEE802154]		[IEEE802154]
	IEEE standard for Information Technology, "IEEE std.		IEEE standard for Information Technology, "IEEE std.
	802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)		802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
	and Physical Layer (PHY) Specifications for Low-Rate		and Physical Layer (PHY) Specifications for Low-Rate
	Wireless Personal Area Networks", June 2011.		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/>.
	Author's Address		Authors' Addresses
	Xavier Vilajosana (editor)		Xavier Vilajosana (editor)
	Universitat Oberta de Catalunya		Universitat Oberta de Catalunya
	156 Rambla Poblenou		156 Rambla Poblenou
	Barcelona, Catalonia 08018		Barcelona, Catalonia 08018
	Spain		Spain
	Phone: +34 (646) 633 681		Phone: +34 (646) 633 681
	Email: xvilajosana@uoc.edu		Email: xvilajosana@uoc.edu
			Kris Pister
			University of California Berkeley
			490 Cory Hall
			Berkeley, California 94720
			USA
			Email: pister@eecs.berkeley.edu
End of changes. 36 change blocks.
	112 lines changed or deleted		126 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/