draft-ietf-6tisch-coap-01.txt   draft-ietf-6tisch-coap-02.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: January 4, 2015 University of Twente Expires: June 7, 2015 University of Twente
July 3, 2014 December 4, 2014
6TiSCH Resource Management and Interaction using CoAP 6TiSCH Resource Management and Interaction using CoAP
draft-ietf-6tisch-coap-01 draft-ietf-6tisch-coap-02
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, the interaction with 6top, control and
6top, control and modify schedules, monitor parameters etc. Higher modify schedules, monitor parameters etc must be defined. 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. This draft
memo is to define the messaging between monitoring and management defines the messaging between monitoring and management entities and
entities and the 6top layer and a mapping to the 6top commands. The the 6top layer and a mapping to the 6top commands. The document also
document also presents a particular implementation of the generic presents a particular implementation of the generic data model
data model specified in [I-D.ietf-6tisch-6top-interface] based on specified in [I-D.ietf-6tisch-6top-interface] based on CoAP and CBOR.
CoAP and CBOR.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
Status of This Memo Status of This Memo
skipping to change at page 2, line 10 skipping to change at page 2, line 7
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 January 4, 2015. This Internet-Draft will expire on June 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope of the document . . . . . . . . . . . . . . . . . . . . 3 3. Scope of the document . . . . . . . . . . . . . . . . . . . . 3
4. Data Model definition for CoAP . . . . . . . . . . . . . . . 4 4. Data Model definition for CoAP . . . . . . . . . . . . . . . 4
4.1. Naming Convention for URI schemes . . . . . . . . . . . . 4 4.1. Naming Convention for URI schemes . . . . . . . . . . . . 4
4.2. Convention for accessing URIs . . . . . . . . . . . . . . 4 4.2. Convention for accessing URIs . . . . . . . . . . . . . . 5
4.3. 6TiSCH Resources . . . . . . . . . . . . . . . . . . . . 5 4.3. 6TiSCH Resources . . . . . . . . . . . . . . . . . . . . 5
4.3.1. Management Resources . . . . . . . . . . . . . . . . 5 4.3.1. Versioning . . . . . . . . . . . . . . . . . . . . . 6
4.3.2. Informational Resources . . . . . . . . . . . . . . . 7 4.3.2. Management Resources . . . . . . . . . . . . . . . . 6
4.3.3. Message Formats . . . . . . . . . . . . . . . . . . . 7 4.3.3. Informational Resources . . . . . . . . . . . . . . . 8
4.3.4. Extensible Resources . . . . . . . . . . . . . . . . 9 4.3.4. Message Formats . . . . . . . . . . . . . . . . . . . 9
4.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.5. Extensible Resources . . . . . . . . . . . . . . . . 11
4.4.1. Request-Response . . . . . . . . . . . . . . . . . . 10 4.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4.2. Publish-Subscribe . . . . . . . . . . . . . . . . . . 11 4.4.1. Request-Response . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4.2. Publish-Subscribe . . . . . . . . . . . . . . . . . . 13
5.1. Normative References . . . . . . . . . . . . . . . . . . 12 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Informative References . . . . . . . . . . . . . . . . . 12 5.1. Normative References . . . . . . . . . . . . . . . . . . 14
5.3. External Informative References . . . . . . . . . . . . . 14 5.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3. External Informative References . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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.ietf-6tisch-6top-interface] The 6TiSCH Operation Sublayer (6top) [I-D.ietf-6tisch-6top-interface]
skipping to change at page 3, line 35 skipping to change at page 3, line 35
| CoAP - Resource Management | | CoAP - Resource Management |
| and Interaction | | 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 Interoperation with any protocol that may be used by the network
with any protocol that may be used by the network layer. This layer is necessary to have a wide impact. This documents aims at
documents aims at defining the message exchanges and the formats of defining the message exchanges and the formats of the messages that
the messages that the network layer uses to interact with the 6top the network layer uses to interact with the 6top sub-layer. The
sub-layer. The messaging scheme defined in this document is aimed messaging scheme defined in this document is aimed for use between
for use between 6top nodes and higher layer management entities as 6top nodes and higher layer management entities as well as between
well as between 6top nodes. 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
This draft defines the communication mechanism between PCE and 6top This draft defines the communication mechanism between PCE and 6top
nodes using COAP. We use the generic YANG data model defined in nodes using COAP. The generic YANG data model defined in
[I-D.ietf-6tisch-6top-interface] to define the various CoAP messages [I-D.ietf-6tisch-6top-interface] is used to define the various CoAP
and payloads. The payload used CBOR for the encoding format. The messages and payloads. The payload used CBOR for the encoding
document also defines the URIs that used to identify the resources format. The document also defines the URIs that used to identify the
exposed by 6top. resources exposed by 6top.
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.
The CoAP Management Interface (CoMI) [I-D.vanderstok-core-comi] draft
specifies a common constrained device managment interface. The
conventions used in this draft follow the guidelines in the CoMI
draft . This draft expects CoMI to define the access methodologies,
discovery mechanisms, resource installation procedures required for
the management of constrained devices. This draft presents some
examples in Section 4.3.4 on how to use the CoMI specifications to
manage the 6top sublayer.
NOTE: CoMI specifications are not finalized at the time of this
writing. In case of any discrepancies, CoMI will supersede the
message formats in the examples presented in Section 4.3.4.
4. Data Model definition for CoAP 4. Data Model definition for CoAP
4.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. The basic URI naming conventions and terminology specified
specified in [RFC3986]. Specifically, the terms, 'scheme', in [RFC3986] is used. 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.
1. All URIs naming 6top resources MUST use the 'coap' scheme 1. All URIs naming 6top resources MUST use the 'coap' scheme
2. The authority MUST have the username '6top' and the IP address of 2. The authority MUST have the username '6top' and the IP address of
6top node 6top node
3. The root path MUST always start with '6t' 3. The root path MUST always start with '6top'
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.
4.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 [RFC7252]. We have no need for the PUT method as the of [RFC7252] and as specified in the CoMI draft
functionality of the POST method can be used for all situations that [I-D.vanderstok-core-comi]. There is no need for the PUT method as
need updating or modification of a resource. The CoAP methods are the functionality of the POST method can be used for all situations
mapped to 6top commands as shown in the figure below. that need updating or modification of a resource.
The CoAP methods are mapped to 6top commands as shown in the figure
below.
+-------------+--------------+-------------------------+ +-------------+--------------+-------------------------+
| CoAP method | 6top command | Description | | CoAP method | 6top command | Description |
+-------------+--------------+-------------------------+ +-------------+--------------+-------------------------+
| GET | READ | Retrieves 6top resources| | GET | READ | Retrieves 6top resources|
+-------------+--------------+-------------------------+ +-------------+--------------+-------------------------+
| POST | CREATE / | Creates/Updates a new | | POST | CREATE / | Creates/Updates a new |
| | UPDATE | entry | | | UPDATE | entry |
+-------------+--------------+-------------------------+ +-------------+--------------+-------------------------+
| DELETE | DELETE | Deletes an entry | | DELETE | DELETE | Deletes an entry |
skipping to change at page 5, line 27 skipping to change at page 5, line 39
Figure 2: Mapping between CoAP methods and 6top commands Figure 2: Mapping between CoAP methods and 6top commands
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.
The POST method is used in all situations where an argument needs to The POST method is used in all situations where an argument needs to
be passed to the 6top layer. The Content-Type option is set to be passed to the 6top layer. The Content-Type option is set to
'application/cbor'. The payload is encoded using CBOR format as 'application/cbor'. The payload is encoded using CBOR format as
described in [RFC7049]. described in [I-D.vanderstok-core-comi] and [RFC7049].
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.
4.3. 6TiSCH Resources 4.3. 6TiSCH Resources
The 6TiSCH resources presented in this draft offer a comprehensive
way to manage 6top nodes based on the requirement known to us as of
this writing. These resources are bound to evolve and will be
identified by appropriate version numbers that will be tied to
revisions of this draft.
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.
4.3.1. Management Resources 4.3.1. Versioning
The version number describes the set of resources that can be
accessed on a node that implements the recommendations in this draft.
Each revision of this draft will define a version number which will
uniquely identify the set of resources defined in that particular
revision of the draft. Specifically, a change to the major version
number indiactes that resources have been added, deleted, renamed or
their message formats have changed. In most cases, this MAY require
changes to the implementation. The minor version number indicates
changes to options supported by resources or other textual/language
changes to the draft. In most cases, this MAY NOT require any
changes to the implementation.
The 6TiSCH resource version information is available by executing a
GET method on the resource '/6top/version' of a 6top node.
4.3.2. 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/ | 6top/nbrList |
| List | DELETE/UPDATE | | | List | DELETE/UPDATE | |
+-------------+-----------------+---------------+ +-------------+-----------------+-----------------+
| slotframe | CREATE/READ/ | 6t/slotframe | | slotframe | CREATE/READ/ | 6top/slotFrame |
| List | DELETE/UPDATE | | | List | DELETE/UPDATE | |
+-------------+-----------------+---------------+ +-------------+-----------------+-----------------+
| Cell | CREATE/READ/ | 6t/Cell | | Cell | CREATE/READ/ | 6top/cellList |
| List | DELETE/UPDATE | | | List | DELETE/UPDATE | |
+-------------+-----------------+---------------+ +-------------+-----------------+-----------------+
| Time | CREATE/READ/ | 6t/TimeSource | | Time | CREATE/READ/ | 6top/timeSource |
| Source | DELETE/UPDATE | | | Source | DELETE/UPDATE | |
+-------------+-----------------+---------------+ +-------------+-----------------+-----------------+
| LabelSwitch | CREATE/READ/ | 6t/LblSwitch | | LabelSwitch | CREATE/READ/ | 6top/labelSwitch|
| List | DELETE/UPDATE | | | List | DELETE/UPDATE | |
+-------------+-----------------+---------------+ +-------------+-----------------+-----------------+
| Track | CREATE/READ/ | 6t/Track | | Track | CREATE/READ/ | 6top/tracklist |
| List | DELETE/UPDATE | | | List | DELETE/UPDATE | |
+-------------+-----------------+---------------+ +-------------+-----------------+-----------------+
| EB | CREATE/READ/ | 6t/EB | | EB | CREATE/READ/ | 6top/ebList |
| List | DELETE/UPDATE | | | List | DELETE/UPDATE | |
+-------------+-----------------+---------------+ +-------------+-----------------+-----------------+
| Chunk | CREATE/READ/ | 6t/Chunk | | Chunk | CREATE/READ/ | 6top/chunkList |
| List | DELETE/UPDATE | | | 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 List The following table provides an example about how Neighbor List
components (leafs in the YANG model) can be addressed. components (leafs in the YANG model) can be addressed.
+-------------+---------------------------+ +-------------+---------------------------+
| Field name | URI path | | Field name | URI path |
+-------------+---------------------------+ +-------------+---------------------------+
| Neighbor | 6t/Neighbor/TargetNodeAddr| | Target | |
| Neighbor | 6top/nbrList/tna |
| Addr | | | Addr | |
+-------------+---------------------------+ +-------------+---------------------------+
| ASN | 6t/Neighbor/ASN | | ASN | 6top/nbrList/asn |
+-------------+---------------------------+ +-------------+---------------------------+
| RSSI | 6t/Neighbor/RSSI | | RSSI | 6top/nbrList/rssi |
+-------------+---------------------------+ +-------------+---------------------------+
| LinkQuality | 6t/Neighbor/LinkQuality | | LinkQuality | 6top/nbrList/linkQ |
+-------------+---------------------------+ +-------------+---------------------------+
Figure 4: Neighbor Table Figure 4: Neighbor Table
4.3.2. Informational Resources 4.3.3. 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 | | Version | READ | 6top/version |
+-------------+-----------------+-----------------------+ +-------------+-----------------+-----------------------+
| Monitoring | READ/CONFIGURE | 6t/MonitoringStatus | | Queue | READ/CONFIGURE | 6top/queue |
+-------------+-----------------+-----------------------+
| Monitoring | READ/CONFIGURE | 6top/monitStatus |
| status | | | | status | | |
+-------------+-----------------+-----------------------+ +-------------+-----------------+-----------------------+
| Statistics | READ/CONFIGURE | 6t/StatisticsMetrics | | Statistics | READ/CONFIGURE | 6top/stats |
| metrics | | | | metrics | | |
+-------------+-----------------+-----------------------+ +-------------+-----------------+-----------------------+
Figure 5: List of Informational Resources Figure 5: List of Informational Resources
4.3.3. Message Formats 4.3.3.1. Version
The version resource is a read-only resource that provides
information on the methods, resources, message formats that is
supported by the node. The version resource does not directly map to
a 6top resource defined in [I-D.ietf-6tisch-6top-interface].
Upon receiving a GET on the '/6top/version' resource, the node MUST
respond with a version number that is described by a major and minor
number. It is expressed using 2 bytes - The first and second bytes
are 8-bit unsigned integers indicating the major and minor version
numbers respectively. The valid values for the major version are 1
through 255 (both inclusive) and for the minor version are 0 through
255 (both inclusive).
A 6top node implmenting the recommendations in this draft will
respond with the following 2 byte version number - '0x01 0x00',
indicating major version = 1 and minor version = 0.
The major and minor versions are separately accessible using the
resources '/6top/version/major' and '/6top/version/minor'
respectively. The response will be an 8-bit unsigned integer
containing the major or minor version number, respectively.
4.3.3.2. Resource Discovery
As new resources are defined (both native and custom), it is
essential for the PCE as well peers to discover the resources. The
CoMI draft presents methods by which standard CoAP resource discovery
mechanisms are extended to the management of constrained devices.
The methods described in Section 4.3 of [I-D.vanderstok-core-comi]
SHALL be used for discovering new resources available at a node.
4.3.4. 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 list is: example query on the neighbor list is:
+------------------------------------------+ +------------------------------------------+
Header | GET | Header | GET |
+------------------------------------------+ +------------------------------------------+
Uri-Path| /6t/Neighbor | Uri-Path| /6top/nbrList |
+------------------------------------------+ +------------------------------------------+
Options | Accept: application/cbor | Options | Accept: application/cbor |
| Uri-Query: ABNF(TargetNodeAddr==0x1234) | | Uri-Query: ABNF(TargetNodeAddr==0x1234) |
+------------------------------------------+ +------------------------------------------+
Figure 6: Example GET message Figure 6: Example GET message
Since this resources points to the entire neighbor list, the response Since this resources points to the entire neighbor list, the response
returns all the entries (the list of neighbors of that node) and all returns all the entries (the list of neighbors of that node) and all
fields in each entry (i.e. entry for a neighbor) of the list in CBOR fields in each entry (i.e. entry for a neighbor) of the list 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 entries in the list. The value of Uri-Query MUST be in only specific entries in the list. The value of Uri-Query MUST be in
the ABNF format as described in [RFC5234]. the ABNF format as described in [RFC5234].
Resources that point to collection within a list, such as Resources that point to collection within a list, such as
'/6t/Neighbor/TargetNodeAddr', returns only the values in the '/6top/nbrList/tna', returns only the values in the TargetNodeAddr
TargetNodeAddr column of the Neighbor list. The usage of the Uri- entry of the Neighbor list. The usage of the Uri-Query option has
Query option has the same effect of filtering on the result. 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 [RFC7252]. If the resource is found Not Found message as defined in [RFC7252]. If the resource is found
then the payload of the response MUST contain a CBOR representation then the payload of the response MUST contain a CBOR representation
of the data that is referenced by the URI. 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| /6top/nbrList |
+-------------------------------------+ +-------------------------------------+
Payload | CBOR( {TargetNodeAddr: 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 list, such as '/6t/Neighbor/TargetNodeAddr'. within a list, such as '/6top/nbrList/tna'.
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| /6top/nbrList |
+-------------------------------------+ +-------------------------------------+
Options | Uri-Query: ABNF(TargetNodeAddr | Options | Uri-Query: ABNF(TargetNodeAddr |
| == 0x1234) | | == 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 entry(s) within the list must be deleted. clearly specify which entry(s) within the list must be deleted.
Ideally, the CoAP client SHOULD make one call per entry that must be Ideally, the CoAP client SHOULD make one call per entry 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 '/6top/nbrList' 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 list 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 /6top/nbrList | Create.neighbor| Adds a | 2.01 Created|
| CBOR( | | neighbor | | | CBOR( | | neighbor | |
| {TargetNodeAddr: | (address,stats)| | | | {TargetNodeAddr: | (address,stats)| | |
| 1234}) | | | | | 1234}) | | | |
+--------------------+----------------+---------------+-------------+ +---------------------+----------------+---------------+-------------+
| GET /6t/Neighbor | Read.all. | Reads | 2.05 Content| | GET /6top/nbrList | Read.all. | Reads | 2.05 Content|
| | neighbor() | all | CBOR(Neigh- | | | neighbor() | all | CBOR(Neigh- |
| | | neighbors | bor List) | | | | neighbors | bor List) |
+--------------------+----------------+---------------+-------------+ +---------------------+----------------+---------------+-------------+
| GET /6t/Neighbor | Read.neighbor | Reads neighbor| 2.05 Content| | GET /6top/nbrList | Read.neighbor | Reads neighbor| 2.05 Content|
| Uri-Query - | (address) | information | CBOR(Neigh- | | Uri-Query - | (address) | information | CBOR(Neigh- |
| TargetNodeAddr: | | | bor List) | | TargetNodeAddr: | | | bor List) |
| 1234}) | | | | | 1234}) | | | |
+--------------------+----------------+---------------+-------------+ +---------------------+----------------+---------------+-------------+
| POST /6t/Neighbor | Update.neighbor| Updates an | 2.04 Changed| | POST /6top/nbrList | Update.neighbor| Updates an | 2.04 Changed|
| CBOR( | (address,stats)| entry | | | CBOR( | (address,stats)| entry | |
| {TargetNodeAddr: | | | | | {TargetNodeAddr: | | | |
| 1234}) | | | | | 1234}) | | | |
+--------------------+----------------+---------------+-------------+ +---------------------+----------------+---------------+-------------+
| DELETE /6t/Neighbor|Delete.neighbor | Removes | 2.02 Deleted| | DELETE /6top/nbrList|Delete.neighbor | Removes | 2.02 Deleted|
| Uri-Query - | (address) | the neighbor | | | Uri-Query - | (address) | the neighbor | |
| TargetNodeAddr | | | | | TargetNodeAddr | | | |
| == 1234}) | | | | | == 1234}) | | | |
+--------------------+----------------+---------------+-------------+ +---------------------+----------------+---------------+-------------+
Figure 9: CoAP methods and resulting invocation 6top commands Figure 9: CoAP methods and resulting invocation 6top commands
4.3.4. Extensible Resources 4.3.5. 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.
4.3.4.1. Defining new resources 4.3.5.1. Defining new resources
An extensible resource path MUST always start with '/6t/custom' and An extensible resource path MUST always start with '/6top/custom' and
follow the guideline for URI naming as described in 4.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 '/6top/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 | |
skipping to change at page 11, line 9 skipping to change at page 13, line 9
command, the 6top sublayer adds an entry to the neighbor list with command, the 6top sublayer adds an entry to the neighbor list with
appropriate values and returns a confirm message. The CoAP endpoint appropriate values and returns a confirm message. The CoAP endpoint
in turn send out an appropriate CoAP response to indicate success. in turn send out an appropriate CoAP response to indicate success.
If the addition of the neighbor failed, a failure message will be If the addition of the neighbor failed, a failure message will be
returned. 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 /6top/nbrList |----------------------->|
| payload: | Create.neighbor | Adds a | payload: | Create.neighbor | Adds a
| CBOR({TargertNodeAddr: | (address,stats) | neighbor | CBOR({TargertNodeAddr: | (address,stats) | neighbor
| 1234}) | | with address | 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 a target node 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 /6top/nbrList |----------------------->|
| Uri-Query - | Read.neighbor(address) |Reads neighbor | Uri-Query - | Read.neighbor(address) |Reads neighbor
| TargetNodeAddr | |information | TargetNodeAddr | |information
| == 0x1234 | | | == 0x1234 | |
| | | | | |
| | 6top Confirm | | | 6top Confirm |
| CoAP Response |<-----------------------| | CoAP Response |<-----------------------|
|<- - - - - - - - - - - -| Reads neighbor | |<- - - - - - - - - - - -| Reads neighbor |
| 2.05 Content | information | | 2.05 Content | information |
| | | | | |
skipping to change at page 12, line 9 skipping to change at page 14, line 9
4.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 /6top/monitStatus |----------------------->|
| | Read.Monitoring.Status |Reads | | Read.Monitoring.Status |Reads
| | |the current | | |the current
| | |Monitoring | | |Monitoring
| | |status | | |status
| | 6top Notification | | | 6top Notification |
| CoAP Notification |<-----------------------| | CoAP Notification |<-----------------------|
|<- - - - - - - - - - - - | Reads the current | |<- - - - - - - - - - - - | Reads the current |
| 2.05 Content | Monitoring status | | 2.05 Content | Monitoring status |
| | |The Status | | |The Status
| | |changes | | |changes
skipping to change at page 12, line 46 skipping to change at page 14, line 46
5.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.
5.2. Informative References 5.2. Informative References
[I-D.ietf-6tisch-6top-interface] [I-D.ietf-6tisch-6top-interface]
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Interface", draft-ietf-6tisch- Operation Sublayer (6top) Interface", draft-ietf-6tisch-
6top-interface-00 (work in progress), March 2014. 6top-interface-02 (work in progress), October 2014.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., Watteyne, T., and R. Assimiti, "An Thubert, P., Watteyne, T., and R. Assimiti, "An
Architecture for IPv6 over the TSCH mode of IEEE Architecture for IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-architecture-02 (work in 802.15.4e", draft-ietf-6tisch-architecture-04 (work in
progress), June 2014. progress), October 2014.
[I-D.ietf-6tisch-coap] [I-D.ietf-6tisch-coap]
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-00 (work Interaction using CoAP", draft-ietf-6tisch-coap-01 (work
in progress), May 2014. in progress), July 2014.
[I-D.ietf-6tisch-minimal] [I-D.ietf-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH Vilajosana, X. and K. Pister, "Minimal 6TiSCH
Configuration", draft-ietf-6tisch-minimal-01 (work in Configuration", draft-ietf-6tisch-minimal-04 (work in
progress), June 2014. progress), November 2014.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-01 (work in 802.15.4e", draft-ietf-6tisch-terminology-02 (work in
progress), February 2014. progress), July 2014.
[I-D.ietf-6tisch-tsch] [I-D.ietf-6tisch-tsch]
Watteyne, T., Palattella, M., and L. Grieco, "Using Watteyne, T., Palattella, M., and L. Grieco, "Using
IEEE802.15.4e TSCH in an LLN context: Overview, Problem IEEE802.15.4e TSCH in an IoT context: Overview, Problem
Statement and Goals", draft-ietf-6tisch-tsch-00 (work in Statement and Goals", draft-ietf-6tisch-tsch-03 (work in
progress), November 2013. progress), October 2014.
[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-14 (work in progress), June 2014. core-observe-15 (work in progress), October 2014.
[I-D.vanderstok-core-comi]
Stok, P., Greevenbosch, B., Bierman, A., Schoenwaelder,
J., and A. Sehgal, "CoAP Management Interface", draft-
vanderstok-core-comi-05 (work in progress), October 2014.
[I-D.wang-6tisch-6top-sublayer] [I-D.wang-6tisch-6top-sublayer]
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top)", draft-wang-6tisch-6top- Operation Sublayer (6top)", draft-wang-6tisch-6top-
sublayer-00 (work in progress), February 2014. sublayer-01 (work in progress), July 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.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, October 2013. Representation (CBOR)", RFC 7049, October 2013.
 End of changes. 49 change blocks. 
141 lines changed or deleted 222 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/