One document matched: draft-wang-6tisch-6top-coapie-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<rfc category="info" ipr="trust200902" docName="draft-wang-6tisch-6top-coapie-00">
<front>
<title abbrev="6tisch-6top-coapie">
Transporting CoAP Messages over IEEE802.15.4e Information Elements
</title>
<author initials="Q" surname="Wang" fullname="Qin Wang" role="editor">
<organization>Univ. of Sci. and Tech. Beijing </organization>
<address>
<postal>
<street>30 Xueyuan Road</street>
<city>Beijing</city>
<region>Hebei</region>
<code>100083</code>
<country>China</country>
</postal>
<phone>+86 (10) 6233 4781</phone>
<email>wangqin@ies.ustb.edu.cn</email>
</address>
</author>
<author initials="X" surname="Vilajosana" fullname="Xavier Vilajosana" >
<organization>Universitat Oberta de Catalunya</organization>
<address>
<postal>
<street>156 Rambla Poblenou</street>
<city>Barcelona</city>
<region>Catalonia</region>
<code>08018</code>
<country>Spain</country>
</postal>
<phone>+34 (646) 633 681</phone>
<email>xvilajosana@uoc.edu</email>
</address>
</author>
<author initials="T" surname="Watteyne" fullname="Thomas Watteyne" >
<organization>Linear Technology</organization>
<address>
<postal>
<street>30695 Huntwood Avenue</street>
<city>Hayward</city>
<region>CA</region>
<code>94544</code>
<country>USA</country>
</postal>
<phone>+1 (510) 400-2978</phone>
<email>twatteyne@linear.com</email>
</address>
</author>
<author initials="R" surname="Sudhaakar" fullname="Raghuram S Sudhaakar">
<organization abbrev="Cisco Systems">Cisco Systems, Inc</organization>
<address>
<postal>
<street>Building 24</street>
<street>510 McCarthy Blvd</street>
<city>San Jose</city>
<code>95135</code>
<country>USA</country>
</postal>
<phone>+1 408 853 0844</phone>
<email>rsudhaak@cisco.com</email>
</address>
</author>
<author initials="P" surname="Zand" fullname="Pouria Zand">
<organization>
University of Twente
</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>Zilverling Building</street>
<city>Enschede</city>
<code>7522 NB</code>
<country>The Netherlands</country>
</postal>
<phone>+31 619040718</phone>
<email>p.zand@utwente.nl</email>
</address>
</author>
<date/>
<area>Internet Area</area>
<workgroup>6TiSCH</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>
This document describes the format of "CoAP IE", an IEEE802.15.4e Information Element which allows CoAP messages to be transported as part of the IEEE802.15.4e header. This enables 6top-to-6top communication between neighbor nodes in a 6TiSCH network.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Requirements Notation">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Context within 6TiSCH">
<t>
This document fits in the work done at the IETF 6TiSCH WG as follows:
<list style="symbols">
<t>
<xref target="I-D.wang-6tisch-6top-sublayer"/> defines the operation of the 6top sublayer, which monitors and manages the communication schedule used in the <xref target="IEEE802154e"/> TSCH network.
</t>
<t>
<xref target="I-D.ietf-6tisch-6top-interface"/> defines the interface of the 6top sublayer using the YANG data modeling language <xref target="RFC6020"/>.
</t>
<t>
<xref target="I-D.ietf-6tisch-coap"/> translates this YANG model in CoAP resources and interactions, allowing an Internet host (possibly but not necessarily constrained) to monitor and manage the 6top sublayer of a 6TiSCH device.
</t>
<t>
This document defines a method for transporting those CoAP messages as part of the IEEE802.15.4e header. It does so by defining a new IEEE802.15.4e Information Element called "CoAP IE". This allows a 6TiSCH node to monitor and manage the 6top sublayer and enables pairwise communication for signaling and control between neighbor nodes.
</t>
</list>
</t>
</section>
<section title="Motivation">
<t>
The 6TiSCH architecture <xref target="I-D.ietf-6tisch-architecture"/> allows for both centralized and distributed monitoring and management of a 6TiSCH schedule. <xref target="I-D.ietf-6tisch-coap"/> defines the mechanisms necessary for the centralized case. The present document defines a mechanism enabling the communication of nodes in a 1 hop neighborhood, enabling a distributed approach.
</t>
<t>
In particular, it allows a node to monitor and manage its neighbor node's MIB. Through the CoAP IE defined in this document, a node sends link-layer frames to its neighbor which contain, as part of the link-layer header, the CoAP messages defined in <xref target="I-D.ietf-6tisch-coap"/>. This allows a node to interact with the 6top interface of its neighbor, in a way equivalent to an Internet host interacting with a 6TiSCH device over CoAP.
</t>
<t>
In addition, this document describe the frame formats and interaction between a node and its neighbor during softcell negotiation <xref target="I-D.wang-6tisch-6top-sublayer"/>, through the addition of an Remote Procedure Call "RPC" element to the YANG model defined in <xref target="I-D.ietf-6tisch-6top-interface"/>.
</t>
<t>
We call "6top-to-6top" communication the interaction between a node and its neighbor using the CoAP IE.
</t>
</section>
<section title="Status of this Document">
<t>
The authors decided to present the CoAP IE as a separate document to request discussion and suggestions for improvement from the Internet community.
</t>
<t>
If the document gets support, and after suggestions for improvement have been integrated, the author propose to merge it in existing 6TiSCH I-Ds as follows:
<list style="symbols">
<t>
<xref target="sec:rpc_definition"/> would go into <xref target="I-D.ietf-6tisch-6top-interface"/>;
</t>
<t>
<xref target="sec:coap_support"/> would go into <xref target="I-D.ietf-6tisch-coap"/>;
</t>
<t>
<xref target="sec:coapie"/> and <xref target="sec:impl_considerations"/> would go into <xref target="I-D.wang-6tisch-6top-sublayer"/>.
</t>
</list>
</t>
</section>
</section>
<section title="CoAP IE Format" anchor="sec:coapie">
<t>
The CoAP IE is a container for transporting CoAP messages as part of the IEEE802.15.4e header, as an Information Element. It is used by both the management interface and the softcell negotiation interface for 6top-to-6top communication.
</t>
<t>
This IE is not present in <xref target="IEEE802154e"/>; it is defined in this document.
</t>
<figure anchor="CoAPIE">
<preamble>
Format of a CoAP IE.
</preamble>
<artwork><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
// //
| Fragmented CoAP message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
The fields in CoAP IE header are defined as follows.
</t>
<t>
<list style="symbols">
<t>Length = 1</t>
<t>SubID = 0x44</t>
<t>T = 0 (short type)</t>
</list>
</t>
<t>
The content of CoAP IE is a CoAP message compliant to <xref target="RFC7252"/>. The CoAP message MAY use the CoAP Block option (see <xref target="coapblock"/>) in order to fragment large CoAP messages.
</t>
<figure anchor="CoAPIEcontent">
<preamble>
Format of CoAP IE with CoAP message.
</preamble>
<artwork><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CoAP IE header |Ver| T | TKL | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | Token (0-8B, assume 2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uri-path option |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11111111 | |
+-+-+-+-+-+-+-+-+ |
// //
| CoAP message payload (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
The Token Length (TKL)is set to 2;
</t>
<t>
Per <xref target="RFC7252"/>, the Uri-path field consists of the following sub-fields:
<list style="symbols">
<t>Option Delta: 4bits, set to 11</t>
<t>Option Length: 4bits, set to 3</t>
<t>Option value: 3 bytes</t>
</list>
</t>
<t>
The first byte of the option value is set to "6" (for 6top), "4" (for IEEE802.15.4), or "e" (for extension). The second and third bytes refer to the resource name in the corresponding group.
</t>
</section>
<section title="Softcell Negotiation Interface RPC Definition" anchor="sec:rpc_definition">
<t>
This document proposes to replace the "6top Communication Protocol" defined in <xref target="I-D.wang-6tisch-6top-sublayer"/> by an extension to the YANG data model defined in <xref target="I-D.ietf-6tisch-6top-interface"/>. This allows neighbor nodes to negotiate the allocation of soft cells using the CoAP IE.
</t>
<figure>
<artwork><![CDATA[
rpc softcell-negotiation {
input {
leaf Opcode {
type enumeration {
enum RESERVATION;
enum REMOVE;
}
}
leaf RequiredBW {
type uint8;
}
leaf SlotframeID {
type uint8;
}
leaf TrackID {
type uint16;
description
"TrackID points to a tuple(TrackOwnerAddr,
InstanceID)";
}
leaf NumofCandidate {
type uint8;
}
List CandidateList {
key "SlotOffset ChannelOffset";
leaf SlotOffset{
type uint16;
}
leaf ChannelOffset{
type uint16;
}
}
}
output {
leaf NumOfCells {
type uint8;
}
List ResultedCells {
key "SlotOffset ChannelOffset";
leaf SlotOffset{
type uint16;
}
leaf ChannelOffset{
type uint16;
}
}
}
}
]]></artwork>
</figure>
</section>
<section title="CoAP support" anchor="sec:coap_support">
<section title="URI setting">
<t>
<list hangIndent="6" style="hanging">
<t>
Uri-Host option = target node address;
</t>
<t>
Uri-Path option = 6t/6/[6top resource name], or 6t/4/[15.4 resource name], or 6t/e/[extension resource name], where [6top resource name] refers to the data resources or RPC defined by 6top, [15.4 resource name] refers to the data resources defined by IEEE802.15.4, and [extension resource name] refers to the data resources defined by an extensions of 6top, e.g. OTF. [6top resource name] , [154 resource name] and [extension resource name] are RECOMMENDED to be at most 2 bytes long.
</t>
</list>
</t>
</section>
<section title="CoAP Block option" anchor="coapblock">
<t>
In <xref target="I-D.ietf-core-block"/>, two block options (Block1 and Block2) are defined to support block-wise transfers. The format of a fragmented message in a CoAP IE is defined as follows.
</t>
<figure anchor="CoAPIEContentfragment">
<preamble>
Format of CoAP IE content with fragmented message.
</preamble>
<artwork><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CoAP IE header |Ver| T | TKL | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uri-path option |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|option |option | option delta | NUM |M| SZX |
| delta |length | extended | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11111111 | |
+++++++++++++++++ |
// //
| fragmented payload (64B) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
Per <xref target="I-D.ietf-core-block"/>, the option Delta is 23 for Block1 and 27 for Block2. Related sub-fields are defined as follows.
<list style="symbols">
<t>
Option delta: 4bits, set to 13, indicates an 8-bit unsigned integer follows the initial byte and the Option Delta minus 13.
</t>
<t>
Option length: 4bits, set to 2.
</t>
<t>
Option delta extended: 8bits, 23-13=10 and 27-13=14 for Block1 and Block2, respectively.
</t>
</list>
</t>
<t>
Per <xref target="IEEE802154"/>, assuming the IE size constraint is 81 bytes, the related fields of the block option are defined as follows.
<list style="symbols">
<t>
The size of the block (SZX): 3 bits, representing block size 16B/32B/64B/128B/256B/512B/1024B. Considering the IE size constrained by <xref target="IEEE802154"/>, 16B/32B/64B block size will be used. Invalid block size values will cause the packet to be dropped quietly.
</t>
<t>
Whether more blocks are following (M): 1 bit;
</t>
<t>
The relative number of the block (NUM): 12 bits, within a sequence of blocks with the given size. NUM is 4bits or 12bits, or 20bits
</t>
</list>
</t>
</section>
<section title="Management Interface Protocol">
<t>
Management and MIB handling is handled by the protocol specification defined in <xref target="I-D.ietf-6tisch-coap"/>.
</t>
</section>
<section title="Negotiation interface protocol">
<t>
The negotiation protocol is used by neighbor nodes to agree at what slotOffset/channelOffset to add/remove sotfcells. It uses a Uri-Path option to identify the target resource (i.e the negotiation interface of the neighbor).
</t>
<t>
The example below illustrates the use of this negotiation interface. It assumes the RPC softcell-negotiation is at Uri-Path "6t/6/ng".
</t>
<figure>
<artwork><![CDATA[
nodeA nodeB
| |
+------>| IEEE802.15.4e type: DATA
| POST | CoAP Header: POST (T=CON)
| | Uri-Path: "6t/6/ng"
| | Payload: CBOR(
| | Opcode=RESERVATION,
| | RequiredBW,
| | SlotframeID,
| | TrackID,
| | NumOfCandidate,
| | CandidateList
| | )
| |
|<------+ IEEE802.15.4e type: ACK
| |
|<------+ IEEE802.15.4e type: DATA
| 2.04 | CoAP Header: 2.04 Changed (T=CON, Code=2.04)
| | Payload: CBOR(
| | NumOfCells,
| | ResultedCells
| | )
| |
+-------> IEEE802.15.4e type: ACK
| |
]]></artwork>
</figure>
<t>
Node A send a CoAP POST request, using a confirmable message. Node B sends back a IEEE802.15.4e ACK to confirm reception. This layer 2 ACK does not give any indication about the correct handling of the command, or even about whether this command is well formatted and understood. Node B parses the CoAP IE, and if correct, calls the appropriate 6top command to allocate softcells. When the allocation is done, node B sends back a CoAP Response with the appropriate return code to node A as a IEEE802.15.4e data packet. The CoAP ACK MUST be piggybacked on the Response.
</t>
</section>
<section title="Acknowledgement">
<t>
For both non-fragmented CoAP message and fragmented CoAP message, an Acknowledgement message of CoAP is used. The Acknowledgement message of CoAP is inserted into a CoAP IE, which is carried in the Data Frame or Enhanced Acknowledgement frame of <xref target="IEEE802154e"/>.
</t>
</section>
<section title="Observe">
<t>
The Observe mechanism is a option for 6top-to-6top communication. The Token in the CoAP message is used to bind Observe message and its Response messages.
</t>
</section>
</section>
<section title="Implementation Considerations" anchor="sec:impl_considerations">
<t>
Similar to the formatting and the parser modules used by CoAP (Layer 5), a CoAP formatting and parser modules are present in the 6top sublayer.
</t>
<figure anchor="CoAP_parser">
<artwork><![CDATA[
+-----------------------------------+
| PCEP | CoAP | | 6LoWPAN | |
| PCC | DTLS | PANA | ND |RPL |
+------------------------------------------+
| TCP | UDP | ICMP | RSVP |
+------------------------------------------+
| IPv6 |
+------------------------------------------+
| 6LoWPAN HC |
+------------------------------------------+
| +--------------+ +----------------+ |
| | CoAP Parser | | CoAP Formatting| |
| +--------------+ +----------------+ |
| +--------------+ +----------------+ |
| | IE Parser | | IE Formatting | |
| +--------------+ +----------------+ |
+------------------------------------------+
| IEEE802.15.4e TSCH |
+------------------------------------------+
| IEEE802.15.4 |
+------------------------------------------+
]]></artwork>
</figure>
<t>
When the IE parser identifies a CoAP IE in the data packet, it passes the IE content (i.e. the fragmented CoAP message) to the CoAP Parser. The CoAP Parser then assembles those fragmented CoAP messages, and takes the appropriate action based on the CoAP Code, Uri-Path, and payload.
</t>
<t>
When a CoAP message is formatted, it MAY be fragmented, then passed to the IE Formatting module. The IE Formatting module puts those (possibly fragmented) CoAP message(s) into a CoAP IE and pases them to the IEEE802.15.4e TSCH layer as separate packets.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
</references>
<references title="Informative References">
<!-- RFC 6TiSCH-->
<!-- RFC others -->
<?rfc include='reference.RFC.6020'?>
<?rfc include='reference.RFC.7252'?>
<?rfc include='reference.I-D.ietf-core-block'?>
<!-- I-D 6TiSCH -->
<?rfc include='reference.I-D.ietf-6tisch-tsch'?>
<?rfc include='reference.I-D.ietf-6tisch-architecture'?>
<?rfc include='reference.I-D.ietf-6tisch-terminology'?>
<?rfc include='reference.I-D.ietf-6tisch-minimal'?>
<?rfc include='reference.I-D.ietf-6tisch-6top-interface'?>
<?rfc include='reference.I-D.ietf-6tisch-coap'?>
<?rfc include='reference.I-D.wang-6tisch-6top-sublayer'?>
<!-- I-D others -->
</references>
<references title="External Informative References">
<reference anchor="IEEE802154e">
<front>
<title>IEEE std. 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer</title>
<author>
<organization>IEEE standard for Information Technology</organization>
</author>
<date month="April" year="2012"/>
</front>
</reference>
<reference anchor="IEEE802154">
<front>
<title>IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks</title>
<author>
<organization>IEEE standard for Information Technology</organization>
</author>
<date month="June" year="2011"/>
</front>
</reference>
<reference anchor="OpenWSN">
<front>
<title>OpenWSN: a Standards-Based Low-Power Wireless Development Environment</title>
<author initials="T." surname="Watteyne" fullname="Thomas Watteyne" />
<author initials="X." surname="Vilajosana" fullname="Xavier Vilajosana" />
<author initials="B." surname="Kerkez" fullname="Branko Kerkez" />
<author initials="F." surname="Chraim" fullname="Fabien Chraim" />
<author initials="K." surname="Weekly" fullname="Kevin Weekly" />
<author initials="Q." surname="Wang" fullname="Qin Wang" />
<author initials="S." surname="Glaser" fullname="Steven Glaser" />
<author initials="K." surname="Pister" fullname="Kris Pister" />
<date month="August" year="2012" />
</front>
<seriesInfo name="Transactions on Emerging Telecommunications Technologies" value="" />
</reference>
<reference anchor="morell04label">
<front>
<title>Label Switching over IEEE802.15.4e Networks. Transactions on Emerging Telecommunications Technologies</title>
<author initials="A" surname="Morell" fullname="Antoni Morell"/>
<author initials="X" surname="Vilajosana" fullname="Xavier Vilajosana"/>
<author initials="J" surname="Lopez-Vicario" fullname="Jose Lopez Vicario"/>
<author initials="T" surname="Watteyne" fullname="Thomas Watteyne"/>
<date month="June" year="2013"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 07:27:59 |