< draft-sudhaakar-6tisch-coap-00.txt		draft-sudhaakar-6tisch-coap-01.txt >
	6TiSCH R. Sudhaakar, Ed.		6TiSCH R. Sudhaakar, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track P. Zand		Intended status: Standards Track P. Zand
	Expires: April 24, 2014 University of Twente		Expires: September 30, 2014 University of Twente
	October 21, 2013		March 29, 2014
	6TiSCH Data Model for CoAP		6TiSCH Resource Management and Interaction using CoAP
	draft-sudhaakar-6tisch-coap-00		draft-sudhaakar-6tisch-coap-01
	Abstract		Abstract
	The [IEEE802154e] standardizes the TSCH mode of operation and defines		The [IEEE802154e] standardizes the TSCH mode of operation and defines
	the mechanisms for layer 2 communication between conforming devices.		the mechanisms for layer 2 communication between conforming devices.
	6top defines a set of commands to monitor and manage the TSCH		6top defines a set of commands to monitor and manage the TSCH
	schedule. To realize the full functionality of sensor networks and		schedule. To realize the full functionality of sensor networks and
	allow their adoption and use in real applications we need additional		allow their adoption and use in real applications we need additional
	mechanisms. Specifically, we need to define how to interact with		mechanisms. Specifically, we need to define how to interact with
	6top, control and modify schedules, monitor parameters etc. Higher		6top, control and modify schedules, monitor parameters etc. Higher
	layers monitoring and management entities are then able to use these		layers monitoring and management entities are then able to use these
	capabilities to create feedback loops. Although, there have been		capabilities to create feedback loops. Although, there have been
	many custom implementations of such feedback loops between the		many custom implementations of such feedback loops between the
	routing, transport and MAC layers in sensor network deployments,		routing, transport and MAC layers in sensor network deployments,
	there has been a lack of standards based approaches. The goal of the		there has been a lack of standards based approaches. The goal of the
	memo is to define a generic data model between monitoring and		memo is to define the messaging between monitoring and management
	management entities and the 6top layer and define a mapping to the		entities and the 6top layer and a mapping to the 6top commands. The
	6top commands. The document also presents a particular		document also presents a particular implementation of the generic
	implementation of the model based on CoAP and CBOR.		data model specified in [I-D.wang-6tisch-6top-interface] based on
			CoAP and CBOR.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 24, 2014.		This Internet-Draft will expire on September 30, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	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. Requirements notation . . . . . . . . . . . . . . . . . . . . 2		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Scope of the document . . . . . . . . . . . . . . . . . . . . 3		3. Scope of the document . . . . . . . . . . . . . . . . . . . . 3
	4. Generic Data Model . . . . . . . . . . . . . . . . . . . . . 4		4. Data Model definition for CoAP . . . . . . . . . . . . . . . 4
	5. Data Model definition for CoAP . . . . . . . . . . . . . . . 4		4.1. Naming Convention for URI schemes . . . . . . . . . . . . 4
	5.1. Naming Convention for URI schemes . . . . . . . . . . . . 4		4.2. Convention for accessing URIs . . . . . . . . . . . . . . 4
	5.2. Convention for accessing URIs . . . . . . . . . . . . . . 4		4.3. 6TiSCH Resources . . . . . . . . . . . . . . . . . . . . 5
	5.3. 6TiSCH Resources . . . . . . . . . . . . . . . . . . . . 5		4.3.1. Management Resources . . . . . . . . . . . . . . . . 5
	5.3.1. Management Resources . . . . . . . . . . . . . . . . 5		4.3.2. Informational Resources . . . . . . . . . . . . . . . 7
	5.3.2. Informational Resources . . . . . . . . . . . . . . . 7		4.3.3. Message Formats . . . . . . . . . . . . . . . . . . . 7
	5.3.3. Message Formats . . . . . . . . . . . . . . . . . . . 7		4.3.4. Extensible Resources . . . . . . . . . . . . . . . . 9
	5.3.4. Extensible Resources . . . . . . . . . . . . . . . . 10		4.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.4.1. Request-Response . . . . . . . . . . . . . . . . . . 10
	5.4.1. Request-Response . . . . . . . . . . . . . . . . . . 10		4.4.2. Publish-Subscribe . . . . . . . . . . . . . . . . . . 11
	5.4.2. Publish-Subscribe . . . . . . . . . . . . . . . . . . 12		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.1. Normative References . . . . . . . . . . . . . . . . . . 12
	6.1. Normative References . . . . . . . . . . . . . . . . . . 12		5.2. Informative References . . . . . . . . . . . . . . . . . 12
	6.2. Informative References . . . . . . . . . . . . . . . . . 12		5.3. External Informative References . . . . . . . . . . . . . 13
	6.3. External Informative References . . . . . . . . . . . . . 13
	Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Requirements notation		1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	The 6TiSCH Operation Sublayer (6top) [I-D.wang-6tsch-6top] describes		The 6TiSCH Operation Sublayer (6top) [I-D.wang-6tisch-6top-interface]
	the main commands provided to higher layers that allow them to build		describes the main commands provided to higher layers that allow them
	TSCH schedules, make routing decisions, perform TSCH configuration		to build TSCH schedules, make routing decisions, perform TSCH
	and control procedures and supports centralized and decentralized		configuration and control procedures and supports centralized and
	scheduling policies among other functionalities. However, there is		decentralized scheduling policies among other functionalities.
	still a need for specifying the methods, including message exchanges		However, there is still a need for specifying the methods, including
	and message formats that higher layers use to invoke these command		message exchanges and message formats that higher layers use to
	described by 6top.		invoke these command described by 6top.
	+------------------------------------+		+------------------------------------+
	| Higher Layers |		| Higher Layers |
	+------------------------------------+		+------------------------------------+
	| Information and Data Model |		| CoAP - Resource Management |
	| for interacting with 6top |		| and Interaction |
	+------------------------------------+		+------------------------------------+
	| 6top |		| 6top |
	+------------------------------------+		+------------------------------------+
	| 802.15.4e TSCH |		| 802.15.4e TSCH |
	+------------------------------------+		+------------------------------------+
	Figure 1: Logical positioning of layers		Figure 1: Logical positioning of layers
	In order to have an wide impact we need to be able to interoperate		In order to have an wide impact we need to be able to interoperate
	with any protocol that may be used by the network layer. This		with any protocol that may be used by the network layer. This
	documents aims at defining the message exchanges and the formats of		documents aims at defining the message exchanges and the formats of
	the messages that the network layer uses to interact with the 6top		the messages that the network layer uses to interact with the 6top
	sub-layer. We use the YANG data modelling language to specify a data		sub-layer. The messaging scheme defined in this document is aimed
	format reusable across different protocols/elements including RPL,		for use between 6top nodes and higher layer management entities as
	RSVP, PCE, etc.		well as between 6top nodes.
	This document also specifies an implementation of this generic		This document also specifies an implementation of this generic
	message exchange and data model using CoAP as the transport		message exchange and data model using CoAP as the transport
	mechanism.		mechanism.
	3. Scope of the document		3. Scope of the document
	We first define a generic data model that is applicable to extensions		This draft defines the communication mechanism between PCE adn 6top
	on other transport protocols. The generic data model uses YANG to		nodes using COAP. We use the generic YANG data model defined in
	describe the message and formats that are used by the higher layers		[I-D.wang-6tisch-6top-interface] to define the various CoAP messages
	to interact with 6top.		and payloads. The payload used CBOR for the encoding format. The
			document also defines the URIs that used to identify the resources
	It is followed by the implementation details of the data model for		exposed by 6top.
	the specific scenario where the higher layer may use CoAP to interact
	with the 6top nodes. The document defines the URIs that are used to
	identify resources exposed by 6top. The messages that are required
	to be sent to the 6top sublayer are defined using the CBOR format.
	This document also defines how users can install custom resources		This document also defines how users can install custom resources
	that allow them to extend the basic resource exposed by 6top.		that allow them to extend the basic resource exposed by 6top.
	4. Generic Data Model		4. Data Model definition for CoAP
	[TODO]
	5. Data Model definition for CoAP
	5.1. Naming Convention for URI schemes		4.1. Naming Convention for URI schemes
	Universal Resource Identifiers (URIs) help us uniquely identify the		Universal Resource Identifiers (URIs) help us uniquely identify the
	various commands and parameters that 6top exposes to the higher		various commands and parameters that 6top exposes to the higher
	layers. We use the basic URI naming conventions and terminology		layers. We use the basic URI naming conventions and terminology
	specified in [RFC3986]. Specifically, the terms, 'scheme',		specified in [RFC3986]. Specifically, the terms, 'scheme',
	'authority', 'path', 'query' are used as defined in the [RFC3986].		'authority', 'path', 'query' are used as defined in the [RFC3986].
	The following provides the guidelines that are followed in this draft		The following provides the guidelines that are followed in this draft
	to name the URIs that identify the resources exposed by 6top.		to name the URIs that identify the resources exposed by 6top.
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 34 ¶
	4. Each component of the path SHOULD be of minimum possible length		4. Each component of the path SHOULD be of minimum possible length
	while being self descriptive.		while being self descriptive.
	5. Typographical conventions as described in A SHOULD be followed		5. Typographical conventions as described in A SHOULD be followed
	These guidelines MUST be followed by users who install extensible		These guidelines MUST be followed by users who install extensible
	resources. It SHOULD be followed for future extensions of the data		resources. It SHOULD be followed for future extensions of the data
	model in order to provide consistency.		model in order to provide consistency.
	5.2. Convention for accessing URIs		4.2. Convention for accessing URIs
	We use the GET, POST and DELETE methods described by CoAP. These		We use the GET, POST and DELETE methods described by CoAP. These
	methods MUST be used in accordance with their definition in Sec. 5.8		methods MUST be used in accordance with their definition in Sec. 5.8
	of [I-D.ietf-core-coap]. We have no need for the PUT method as the		of [I-D.ietf-core-coap]. We have no need for the PUT method as the
	functionality of the POST method can be used for all situations that		functionality of the POST method can be used for all situations that
	need updating or modification of a resource. The CoAP methods are		need updating or modification of a resource. The CoAP methods are
	mapped to 6top commands as shown in the figure below.		mapped to 6top commands as shown in the figure below.
	+-------------+--------------+-------------------------+		+-------------+--------------+-------------------------+
	| CoAP method | 6top command | Description |		| CoAP method | 6top command | Description |
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 36 ¶
	'application/cbor'. The payload is encoded using CBOR format as		'application/cbor'. The payload is encoded using CBOR format as
	described in [I-D.bormann-cbor].		described in [I-D.bormann-cbor].
	The DELETE method is used to invoke the 6top DELETE command on a		The DELETE method is used to invoke the 6top DELETE command on a
	particular resource.		particular resource.
	The GET method may use queries to allow higher layer entities to		The GET method may use queries to allow higher layer entities to
	perform conditional GETs or filter the results of a GET on resource		perform conditional GETs or filter the results of a GET on resource
	that is a collection.		that is a collection.
	5.3. 6TiSCH Resources		4.3. 6TiSCH Resources
	Management resources are classified as resources to which a higher		Management resources are classified as resources to which a higher
	layer entity may create, update or delete. They are typically used		layer entity may create, update or delete. They are typically used
	to create schedules, identify time sources that TSCH needs. They are		to create schedules, identify time sources that TSCH needs. They are
	the means to close the control loop between TSCH and higher layers.		the means to close the control loop between TSCH and higher layers.
	Informational resources are classified as resources to which a higher		Informational resources are classified as resources to which a higher
	layer entity typically has only READ access. They are typically used		layer entity typically has only READ access. They are typically used
	to monitor operational parameters of TSCH and the values used as		to monitor operational parameters of TSCH and the values used as
	input to routing algorithms and other mechanisms.		input to routing algorithms and other mechanisms.
	5.3.1. Management Resources		4.3.1. Management Resources
	All the attributes in the management resources have the Read/Write		All the attributes in the management resources have the Read/Write
	accessibility. The following table lists the 6top management		accessibility. The following table lists the 6top management
	resources and the related URI paths.		resources and the related URI paths.
	+-------------+-----------------+---------------+		+-------------+-----------------+---------------+
	| Name | Accessibility | URI path |		| Name | Accessibility | URI path |
	| | 6top Commands | |		| | 6top Commands | |
	+-------------+-----------------+---------------+		+-------------+-----------------+---------------+
	| Neighbor | CREATE/READ/ | 6t/Neighbor |		| Neighbor | CREATE/READ/ | 6t/Neighbor |
	| Table | DELETE/UPDATE | |		| List | DELETE/UPDATE | |
	+-------------+-----------------+---------------+		+-------------+-----------------+---------------+
	| slotframe | CREATE/READ/ | 6t/slotframe |		| slotframe | CREATE/READ/ | 6t/slotframe |
	| Table | DELETE/UPDATE | |		| List | DELETE/UPDATE | |
	+-------------+-----------------+---------------+		+-------------+-----------------+---------------+
	| Cell | CREATE/READ/ | 6t/Cell |		| Cell | CREATE/READ/ | 6t/Cell |
	| Table | DELETE/UPDATE | |		| List | DELETE/UPDATE | |
	+-------------+-----------------+---------------+		+-------------+-----------------+---------------+
	| Time | CREATE/READ/ | 6t/TimeSource |		| Time | CREATE/READ/ | 6t/TimeSource |
	| Source | DELETE/UPDATE | |		| Source | DELETE/UPDATE | |
	+-------------+-----------------+---------------+		+-------------+-----------------+---------------+
	| Bundle | CREATE/READ/ | 6t/Bundle |		| LabelSwitch | CREATE/READ/ | 6t/LblSwitch |
	| Table | DELETE/UPDATE | |		| List | DELETE/UPDATE | |
	+-------------+-----------------+---------------+		+-------------+-----------------+---------------+
	| Track | CREATE/READ/ | 6t/Track |		| Track | CREATE/READ/ | 6t/Track |
	| Table | DELETE/UPDATE | |		| List | DELETE/UPDATE | |
	+-------------+-----------------+---------------+		+-------------+-----------------+---------------+
	| EB | CREATE/READ/ | 6t/EB |		| EB | CREATE/READ/ | 6t/EB |
	| Table | DELETE/UPDATE | |		| List | DELETE/UPDATE | |
			+-------------+-----------------+---------------+
			| Chunk | CREATE/READ/ | 6t/Chunk |
			| List | DELETE/UPDATE | |
	+-------------+-----------------+---------------+		+-------------+-----------------+---------------+
	Figure 3: List of Management Resources		Figure 3: List of Management Resources
	In the following table, we provide an example about how Neighbor		In the following table, we provide an example about how Neighbor List
	table attributes can be addressed.		components (leafs in the YANG model) can be addressed.
	+-------------+---------------------------+		+-------------+---------------------------+
	| Field name | URI path |		| Field name | URI path |
	+-------------+---------------------------+		+-------------+---------------------------+
	| Neighbor | 6t/Neighbor/ShortAddr |		| Neighbor | 6t/Neighbor/TargetNodeAddr|
	| Short Addr | |		| Addr | |
	+-------------+---------------------------+
	| numTx | 6t/Neighbor/numTx |
	+-------------+---------------------------+
	| numTxAck | 6t/Neighbor/numTxAck |
	+-------------+---------------------------+
	| numRx | 6t/Neighbor/numRx |
	+-------------+---------------------------+
	| Neighbor | 6t/Neighbor/LongAddr |
	| Long Addr | |
	+-------------+---------------------------+		+-------------+---------------------------+
	| ASN | 6t/Neighbor/ASN |		| ASN | 6t/Neighbor/ASN |
	+-------------+---------------------------+		+-------------+---------------------------+
	| RPL rank | 6t/Neighbor/RPLrank |
	+-------------+---------------------------+
	| Time Source | 6t/Neighbor/TSFlag |
	| Flag | |
	+-------------+---------------------------+
	| RSSI | 6t/Neighbor/RSSI |		| RSSI | 6t/Neighbor/RSSI |
	+-------------+---------------------------+		+-------------+---------------------------+
	| LQI | 6t/Neighbor/LQI |		| LinkQuality | 6t/Neighbor/LinkQuality |
	+-------------+---------------------------+		+-------------+---------------------------+
	Figure 4: Neighbor Table		Figure 4: Neighbor Table
	5.3.2. Informational Resources		4.3.2. Informational Resources
	All the attributes in the Informational resources have the Read		All the attributes in the Informational resources have the Read
	accessibility. The following table lists the 6top informational		accessibility. The following table lists the 6top informational
	resources and the related URI paths.		resources and the related URI paths.
	+-------------+-----------------+-----------------------+		+-------------+-----------------+-----------------------+
	| Name | Accessibility | URI path |		| Name | Accessibility | URI path |
	| | 6top Commands | |		| | 6top Commands | |
	+-------------+-----------------+-----------------------+		+-------------+-----------------+-----------------------+
	| Queue | READ/CONFIGURE | 6t/Queue |		| Queue | READ/CONFIGURE | 6t/Queue |
	+-------------+-----------------+-----------------------+		+-------------+-----------------+-----------------------+
	| Queue | READ/CONFIGURE | 6t/QueueStats |
	| stats | | |
	+-------------+-----------------+-----------------------+
	| Monitoring | READ/CONFIGURE | 6t/MonitoringStatus |		| Monitoring | READ/CONFIGURE | 6t/MonitoringStatus |
	| status | | |		| status | | |
	+-------------+-----------------+-----------------------+		+-------------+-----------------+-----------------------+
	| Statistics | READ/CONFIGURE | 6t/StatisticsMetrics |		| Statistics | READ/CONFIGURE | 6t/StatisticsMetrics |
	| metrics | | |		| metrics | | |
	+-------------+-----------------+-----------------------+		+-------------+-----------------+-----------------------+
	Figure 5: List of Informational Resources		Figure 5: List of Informational Resources
	5.3.3. Message Formats		4.3.3. Message Formats
	GET messages do not contain any payload. However, they can contain a		GET messages do not contain any payload. However, they can contain a
	query option to filter on the resource that is being retrieved. An		query option to filter on the resource that is being retrieved. An
	example query on the neighbor table is:		example query on the neighbor table is:
	+-------------------------------------+		+------------------------------------------+
	Header | GET |		Header | GET |
	+-------------------------------------+		+------------------------------------------+
	Uri-Path| /6t/Neighbor |		Uri-Path| /6t/Neighbor |
	+-------------------------------------+		+------------------------------------------+
	Options | Accept: application/cbor |		Options | Accept: application/cbor |
	| Uri-Query: ABNF(ShortAddr==0x1234) |		| Uri-Query: ABNF(TargetNodeAddr==0x1234) |
	+-------------------------------------+		+------------------------------------------+
	Figure 6: Example GET message		Figure 6: Example GET message
	Since this resources points to the entire neighbor table the response		Since this resources points to the entire neighbor table the response
	returns all the rows (the list of neighbors of that node) and all		returns all the rows (the list of neighbors of that node) and all
	fields in each row (i.e. entry for a neighbor) of the table in CBOR		fields in each row (i.e. entry for a neighbor) of the table in CBOR
	format. A request with a Uri-Query option may be used to retrieve		format. A request with a Uri-Query option may be used to retrieve
	only specific rows in the table. The value of Uri-Query MUST be in		only specific rows in the table. The value of Uri-Query MUST be in
	the ABNF formatas described in [RFC5234].		the ABNF format as described in [RFC5234].
	Resources that point to collection within a table, such as '/6t/		Resources that point to collection within a table, such as '/6t/
	Neighbor/ShortAddr', returns only the values in the ShortAddr column		Neighbor/TargetNodeAddr', returns only the values in the
	of the Neighbor table. The usage of the Uri-Query option has the		TargetNodeAddr column of the Neighbor table. The usage of the Uri-
	same effect of filtering on the result.		Query option has the same effect of filtering on the result.
	The endpoint MUST appropriately respond with a 2.05 Content or 4.04		The endpoint MUST appropriately respond with a 2.05 Content or 4.04
	Not Found message as defined in [I-D.ietf-core-coap]. If the		Not Found message as defined in [I-D.ietf-core-coap]. If the
	resource is found then the payload of the response MUST contain a		resource is found then the payload of the response MUST contain a
	CBOR representation of the data that is referenced by the URI.		CBOR representation of the data that is referenced by the URI.
	To create or update a Neighbor, the CoAP client MUST send a POST		To create or update a Neighbor, the CoAP client MUST send a POST
	message as shown in Figure 7. The payload MUST describe the argument		message as shown in Figure 7. The payload MUST describe the argument
	that is passed to 6top in CBOR format.		that is passed to 6top in CBOR format.
	+-------------------------------------+		+-------------------------------------+
	Header | POST |		Header | POST |
	+-------------------------------------+		+-------------------------------------+
	Uri-Path| /6t/Neighbor |		Uri-Path| /6t/Neighbor |
	+-------------------------------------+		+-------------------------------------+
	Payload | CBOR( {ShortAddr: 0x1234} ) |		Payload | CBOR( {TargetNodeAddr: 0x1234} ) |
	+-------------------------------------+		+-------------------------------------+
	Figure 7: Example POST message		Figure 7: Example POST message
	The POST method may not be used on resources that are collection		The POST method may not be used on resources that are collection
	within a table, such as '/6t/Neighbor/ShortAddr'.		within a table, such as '/6t/Neighbor/TargetNodeAddr'.
	To delete a Neighbor, the CoAP client MUST send a DELETE message as		To delete a Neighbor, the CoAP client MUST send a DELETE message as
	shown in Figure 8.		shown in Figure 8.
	+-------------------------------------+		+-------------------------------------+
	Header | DELETE |		Header | DELETE |
	+-------------------------------------+		+-------------------------------------+
	Uri-Path| /6t/Neighbor |		Uri-Path| /6t/Neighbor |
	+-------------------------------------+		+-------------------------------------+
	Options | Uri-Query: ABNF(ShortAddr==0x1234) |		Options | Uri-Query: ABNF(TargetNodeAddr |
	| |		| == 0x1234) |
	+-------------------------------------+		+-------------------------------------+
	Figure 8: Example DELETE message		Figure 8: Example DELETE message
	A DELETE message SHOULD always contain a Uri-Query option in order to		A DELETE message SHOULD always contain a Uri-Query option in order to
	clearly specify which row(s) within the table must be deleted.		clearly specify which row(s) within the table must be deleted.
	Ideally, the CoAP client SHOULD make one call per row that must be		Ideally, the CoAP client SHOULD make one call per row that must be
	deleted. An implementation may decide whether or not a DELETE method		deleted. An implementation may decide whether or not a DELETE method
	on '/6t/Neighbor' may be allowed.		on '/6t/Neighbor' may be allowed.
	The endpoint MUST appropriately respond with a 2.02 (Deleted)		The endpoint MUST appropriately respond with a 2.02 (Deleted)
	message.		message.
	A sample of mapping between CoAP methods and 6top commands for		A sample of mapping between CoAP methods and 6top commands for
	manipulating the neighbor table is shown in the figure below.		manipulating the neighbor list is shown in the figure below.
	+--------------------+----------------+---------------+-------------+		+--------------------+----------------+---------------+-------------+
	| CoAP method | 6top command |6top behaviour |CoAP Response|		| CoAP method | 6top command |6top behaviour |CoAP Response|
	+--------------------+----------------+---------------+-------------+		+--------------------+----------------+---------------+-------------+
	| POST /6t/Neighbor | Create.neighbor| Adds a | 2.01 Created|		| POST /6t/Neighbor | Create.neighbor| Adds a | 2.01 Created|
	| CBOR( | | neighbor | |		| CBOR( | | neighbor | |
	| {ShortAddr: 1234}) | (address,stats)| | |		| {TargetNodeAddr: | (address,stats)| | |
			| 1234}) | | | |
	+--------------------+----------------+---------------+-------------+		+--------------------+----------------+---------------+-------------+
	| GET /6t/Neighbor | Read.all. | Reads | 2.05 Content|		| GET /6t/Neighbor | Read.all. | Reads | 2.05 Content|
	| | neighbor() | all | CBOR(Neigh- |		| | neighbor() | all | CBOR(Neigh- |
	| | | neighbors | bor Table) |		| | | neighbors | bor Table) |
	+--------------------+----------------+---------------+-------------+		+--------------------+----------------+---------------+-------------+
	| GET /6t/Neighbor | Read.neighbor | Reads neighbor| 2.05 Content|		| GET /6t/Neighbor | Read.neighbor | Reads neighbor| 2.05 Content|
	| Uri-Query - | (address) | information | CBOR(Neigh- |		| Uri-Query - | (address) | information | CBOR(Neigh- |
	| ShortAddr == 0x1234| | | bor Table) |		| TargetNodeAddr: | | | bor Table) |
			| 1234}) | | | |
	+--------------------+----------------+---------------+-------------+		+--------------------+----------------+---------------+-------------+
	| POST /6t/Neighbor | Update.neighbor| Updates an | 2.04 Changed|		| POST /6t/Neighbor | Update.neighbor| Updates an | 2.04 Changed|
	| CBOR( | (address,stats)| entry | |		| CBOR( | (address,stats)| entry | |
	| {ShortAddr: 1234}) | | | |		| {TargetNodeAddr: | | | |
			| 1234}) | | | |
	+--------------------+----------------+---------------+-------------+		+--------------------+----------------+---------------+-------------+
	| DELETE /6t/Neighbor|Delete.neighbor | Removes | 2.02 Deleted|		| DELETE /6t/Neighbor|Delete.neighbor | Removes | 2.02 Deleted|
	| Uri-Query - | (address) | the neighbor | |		| Uri-Query - | (address) | the neighbor | |
	| ShortAddr == 0x1234| | | |		| TargetNodeAddr | | | |
			| == 1234}) | | | |
	+--------------------+----------------+---------------+-------------+		+--------------------+----------------+---------------+-------------+
	Figure 9: CoAP methods and resulting invocation 6top commands		Figure 9: CoAP methods and resulting invocation 6top commands
	5.3.4. Extensible Resources		4.3.4. Extensible Resources
	Extensible resources are to be used when a higher layer entity wants		Extensible resources are to be used when a higher layer entity wants
	to be notified of an event. An event may be defined as the result of		to be notified of an event. An event may be defined as the result of
	a mathematical operation on a 6top resource. For example, the CoAP		a mathematical operation on a 6top resource. For example, the CoAP
	client might want to monitor when the DAG rank of a particular node		client might want to monitor when the DAG rank of a particular node
	crosses a threshold. Once the extensible resource is installed the		crosses a threshold. Once the extensible resource is installed the
	CoAP client uses the observe mechanism defined in		CoAP client uses the observe mechanism defined in
	[I-D.ietf-core-observe] to monitor the resource.		[I-D.ietf-core-observe] to monitor the resource.
	5.3.4.1. Defining new resources		4.3.4.1. Defining new resources
	An extensible resource path MUST always start with '/6t/custom' and		An extensible resource path MUST always start with '/6t/custom' and
	follow the guideline for URI naming as described in 5.1. The event		follow the guideline for URI naming as described in 4.1. The event
	associated with the extensible resource must be defined using the		associated with the extensible resource must be defined using the
	ABNF notation described in [RFC5234].		ABNF notation described in [RFC5234].
	An extensible resource may be created by performing POST operation to		An extensible resource may be created by performing POST operation to
	the resource '/6t/custom' with the following payload encoded using		the resource '/6t/custom' with the following payload encoded using
	CBOR.		CBOR.
	+---------------+------------+		+---------------+------------+
	| Field Name | Type |		| Field Name | Type |
	+---------------+------------+		+---------------+------------+
	| Resource | String |		| Resource | String |
	| Name | |		| Name | |
	+---------------+------------+		+---------------+------------+
	| Event | String |		| Event | String |
	| Definition | |		| Definition | |
	+---------------+------------+		+---------------+------------+
	Figure 10: Payload format for creating an Extensible Resource		Figure 10: Payload format for creating an Extensible Resource
	5.3.4.2. Resource Profiles		4.4. Example
	[TODO]
	5.3.4.3. Resource and Profile Discovery
	[TODO]
	5.4. Example
	This section gives a number of short examples of how to use the data		This section gives a number of short examples of how to use the data
	model and CoAP mapping defined in this document.		model and CoAP mapping defined in this document.
	5.4.1. Request-Response		4.4.1. Request-Response
	Figure 11 shows how a CoAP client adds an entry in the neighbor table		Figure 11 shows how a CoAP client adds an entry in the neighbor table
	of node A. This new neighbor has short address 0x1234. The client		of node A. This new neighbor has a target node address 0x1234. The
	sends out a POST request containing the CBOR encoding of '{ShortAddr:		client sends out a POST request containing the CBOR encoding of
	1234}'. This message is received and processed by the CoAP endpoint		'{TargetNodeAddr: 1234}'. This message is received and processed by
	of Node A and in turn, the 6top command, Create.neighbor is invoked		the CoAP endpoint of Node A and in turn, the 6top command,
	with the appropriate parameters. In this case, the address is the		Create.neighbor is invoked with the appropriate parameters. In this
	'ShortAddr' parameter passed in the payload of the POST message and		case, the address is the 'TargetNodeAddr' parameter passed in the
	the stats argument has the default value. In the response to the		payload of the POST message and the stats argument has the default
	invocation of the Create.neighbor command, the 6top sublayer adds an		value. In the response to the invocation of the Create.neighbor
	entry to the neighbor table with appropriate values and returns a		command, the 6top sublayer adds an entry to the neighbor table with
	confirm message. The CoAP endpoint in turn send out an appropriate		appropriate values and returns a confirm message. The CoAP endpoint
	CoAP response to indicate success. In situation where the addition		in turn send out an appropriate CoAP response to indicate success.
	of the neighbor failed, a failure message will be returned.		In situation where the addition of the neighbor failed, a failure
			message will be returned.
	CoAP Client Node A Node A		CoAP Client Node A Node A
	(CoAP-endpoint) (6top sublayer)		(CoAP-endpoint) (6top sublayer)
	| CoAP Request | |		| CoAP Request | |
	|- - - - - - - - - - - ->| 6top Request |		|- - - - - - - - - - - ->| 6top Request |
	| POST /6t/Neighbor |----------------------->|		| POST /6t/Neighbor |----------------------->|
	| payload: | Create.neighbor | Adds a		| payload: | Create.neighbor | Adds a
	| CBOR({ShortAddr: 1234})| (address,stats) | neighbor		| CBOR({TargertNodeAddr: | (address,stats) | neighbor
	| | | ShortAddr:		| 1234}) | | with address
	| | | 1234		| | | 1234
	| | 6top Confirm |		| | 6top Confirm |
	| CoAP Response |<-----------------------|		| CoAP Response |<-----------------------|
	|<- - - - - - - - - - - -| |		|<- - - - - - - - - - - -| |
	| | |		| | |
	| | |		| | |
	Figure 11: Example of adding a neighbor		Figure 11: Example of adding a neighbor
	In Figure 12, a CoAP client reads a neighbor entry from node A. This		In Figure 12, a CoAP client reads a neighbor entry from node A. This
	neighbor has short address 0x1234.		neighbor has a target node address 0x1234.
	CoAP Client Node A Node A		CoAP Client Node A Node A
	(CoAP-endpoint) (6top sublayer)		(CoAP-endpoint) (6top sublayer)
	| CoAP Request | |		| CoAP Request | |
	|- - - - - - - - - - - ->| 6top Request |		|- - - - - - - - - - - ->| 6top Request |
	| GET /6t/Neighbor |----------------------->|		| GET /6t/Neighbor |----------------------->|
	| Uri-Query - | Read.neighbor(address) |Reads neighbor		| Uri-Query - | Read.neighbor(address) |Reads neighbor
	| ShortAddr == 0x1234 | |information		| TargetNodeAddr | |information
	| | |		| == 0x1234 | |
	| | |		| | |
	| | 6top Confirm |		| | 6top Confirm |
	| CoAP Response |<-----------------------|		| CoAP Response |<-----------------------|
	|<- - - - - - - - - - - -| Reads neighbor |		|<- - - - - - - - - - - -| Reads neighbor |
	| 2.05 Content | information |		| 2.05 Content | information |
	| | |		| | |
	Figure 12: Example of reading a neighbor		Figure 12: Example of reading a neighbor
	5.4.2. Publish-Subscribe		4.4.2. Publish-Subscribe
	In Figure 13, a CoAP client subscribes to Monitoring Status of node		In Figure 13, a CoAP client subscribes to Monitoring Status of node
	A. The Monitoring status of Node A is constantly monitored by the		A. The Monitoring status of Node A is constantly monitored by the
	CoAP client.		CoAP client.
	CoAP Client Node A Node A		CoAP Client Node A Node A
	(CoAP-endpoint) (6top sublayer)		(CoAP-endpoint) (6top sublayer)
	| CoAP Register | |		| CoAP Register | |
	|- - - - - - - - - - - - >| 6top Request |		|- - - - - - - - - - - - >| 6top Request |
	| GET /6t/MonitoringStatus|----------------------->|		| GET /6t/MonitoringStatus|----------------------->|
	skipping to change at page 12, line 41 ¶		skipping to change at page 12, line 34 ¶
	| | |The Status		| | |The Status
	| | |changes		| | |changes
	| | 6top Notification |		| | 6top Notification |
	| CoAP Notification |<-----------------------|		| CoAP Notification |<-----------------------|
	|<- - - - - - - - - - - - | Notifies upon the |		|<- - - - - - - - - - - - | Notifies upon the |
	| 2.05 Content | status change |		| 2.05 Content | status change |
	| | |		| | |
	Figure 13: Example of Subscribing to Monitoring Status		Figure 13: Example of Subscribing to Monitoring Status
	6. References		5. References
	6.1. Normative References		5.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.
	6.2. Informative References		5.2. Informative References
	[I-D.bormann-cbor]		[I-D.bormann-cbor]
	Bormann, C. and P. Hoffman, "Concise Binary Object		Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", draft-bormann-cbor-09 (work in		Representation (CBOR)", draft-bormann-cbor-09 (work in
	progress), September 2013.		progress), September 2013.
	[I-D.ietf-core-coap]		[I-D.ietf-core-coap]
	Shelby, Z., Hartke, K., and C. Bormann, "Constrained		Shelby, Z., Hartke, K., and C. Bormann, "Constrained
	Application Protocol (CoAP)", draft-ietf-core-coap-18		Application Protocol (CoAP)", draft-ietf-core-coap-18
	(work in progress), June 2013.		(work in progress), June 2013.
	[I-D.ietf-core-observe]		[I-D.ietf-core-observe]
	Hartke, K., "Observing Resources in CoAP", draft-ietf-		Hartke, K., "Observing Resources in CoAP", draft-ietf-
	core-observe-11 (work in progress), October 2013.		core-observe-11 (work in progress), October 2013.
	[I-D.wang-6tsch-6top]		[I-D.wang-6tisch-6top-interface]
	Wang, Q., Vilajosana, X., and T. Watteyne, "6TSCH		Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
	Operation Sublayer (6top)", draft-wang-6tsch-6top-00 (work		Operation Sublayer (6top) Interface", draft-wang-6tisch-
	in progress), July 2013.		6top-interface-02 (work in progress), February 2014.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66, RFC		Resource Identifier (URI): Generic Syntax", STD 66, RFC
	3986, January 2005.		3986, January 2005.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	6.3. External Informative References		5.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) Amendment 1: MAC sublayer ", April		Networks (LR-WPANs) Amendment 1: MAC sublayer", April
	2012.		2012.
	Appendix A.		Appendix A.
	Guidelines for constructing URI path names:		Guidelines for constructing URI path names:
	1. The first letter of each element of the path SHOULD be		1. The first letter of each element of the path SHOULD be
	capitalized		capitalized
	2. If an element has multiple words, each the first letter of each		2. If an element has multiple words, each the first letter of each
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 4 ¶
	Raghuram S Sudhaakar (editor)		Raghuram S Sudhaakar (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
	Building 24		Building 24
	510 McCarthy Blvd		510 McCarthy Blvd
	San Jose 95135		San Jose 95135
	USA		USA
	Phone: +1 408 853 0844		Phone: +1 408 853 0844
	Email: rsudhaak@cisco.com		Email: rsudhaak@cisco.com
	Pouria Zand		Pouria Zand
	University of Twente		University of Twente
	Graaf Florisstraat		Department of Computer Science
	1-F18		Zilverling Building
	Deventer 7415 LK		Enschede 7522 NB
	Netherlands		The Netherlands
	Phone: +31 619040718		Phone: +31 619040718
	Email: p.zand@utwente.nl		Email: p.zand@utwente.nl
End of changes. 59 change blocks.
	156 lines changed or deleted		134 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/