6TiSCH | Q. Wang, Ed. |
Internet-Draft | Univ. of Sci. and Tech. Beijing |
Intended status: Informational | X. Vilajosana |
Expires: January 5, 2015 | Universitat Oberta de Catalunya |
T. Watteyne | |
Linear Technology | |
R. Sudhaakar | |
Cisco Systems | |
P. Zand | |
University of Twente | |
July 4, 2014 |
Transporting CoAP Messages over IEEE802.15.4e Information Elements
draft-wang-6tisch-6top-coapie-00
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 RFC 2119 [RFC2119].
This document fits in the work done at the IETF 6TiSCH WG as follows:
The 6TiSCH architecture [I-D.ietf-6tisch-architecture] allows for both centralized and distributed monitoring and management of a 6TiSCH schedule. [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.
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 [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.
In addition, this document describe the frame formats and interaction between a node and its neighbor during softcell negotiation [I-D.wang-6tisch-6top-sublayer], through the addition of an Remote Procedure Call "RPC" element to the YANG model defined in [I-D.ietf-6tisch-6top-interface].
We call "6top-to-6top" communication the interaction between a node and its neighbor using the CoAP IE.
The authors decided to present the CoAP IE as a separate document to request discussion and suggestions for improvement from the Internet community.
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:
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.
This IE is not present in [IEEE802154e]; it is defined in this document.
Format of a CoAP IE.
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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
The fields in CoAP IE header are defined as follows.
The content of CoAP IE is a CoAP message compliant to [RFC7252]. The CoAP message MAY use the CoAP Block option (see Section 4.2) in order to fragment large CoAP messages.
Format of CoAP IE with CoAP message.
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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
The Token Length (TKL)is set to 2;
Per [RFC7252], the Uri-path field consists of the following sub-fields:
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.
This document proposes to replace the "6top Communication Protocol" defined in [I-D.wang-6tisch-6top-sublayer] by an extension to the YANG data model defined in [I-D.ietf-6tisch-6top-interface]. This allows neighbor nodes to negotiate the allocation of soft cells using the CoAP IE.
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; } } } }
In [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.
Format of CoAP IE content with fragmented message.
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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
Per [I-D.ietf-core-block], the option Delta is 23 for Block1 and 27 for Block2. Related sub-fields are defined as follows.
Per [IEEE802154], assuming the IE size constraint is 81 bytes, the related fields of the block option are defined as follows.
Management and MIB handling is handled by the protocol specification defined in [I-D.ietf-6tisch-coap].
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).
The example below illustrates the use of this negotiation interface. It assumes the RPC softcell-negotiation is at Uri-Path "6t/6/ng".
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 | |
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.
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 [IEEE802154e].
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.
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.
+-----------------------------------+ | 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 | +------------------------------------------+
Figure 4
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.
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.
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. |
[RFC7252] | Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. |
[I-D.ietf-core-block] | Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", Internet-Draft draft-ietf-core-block-14, October 2013. |
[I-D.ietf-6tisch-tsch] | Watteyne, T., Palattella, M. and L. Grieco, "Using IEEE802.15.4e TSCH in an LLN context: Overview, Problem Statement and Goals", Internet-Draft draft-ietf-6tisch-tsch-00, November 2013. |
[I-D.ietf-6tisch-architecture] | Thubert, P., Watteyne, T. and R. Assimiti, "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e", Internet-Draft draft-ietf-6tisch-architecture-02, June 2014. |
[I-D.ietf-6tisch-terminology] | Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Internet-Draft draft-ietf-6tisch-terminology-01, February 2014. |
[I-D.ietf-6tisch-minimal] | Vilajosana, X. and K. Pister, "Minimal 6TiSCH Configuration", Internet-Draft draft-ietf-6tisch-minimal-01, June 2014. |
[I-D.ietf-6tisch-6top-interface] | Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH Operation Sublayer (6top) Interface", Internet-Draft draft-ietf-6tisch-6top-interface-00, March 2014. |
[I-D.ietf-6tisch-coap] | Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Interaction using CoAP", Internet-Draft draft-ietf-6tisch-coap-00, May 2014. |
[I-D.wang-6tisch-6top-sublayer] | Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH Operation Sublayer (6top)", Internet-Draft draft-wang-6tisch-6top-sublayer-00, February 2014. |
[IEEE802154e] | IEEE standard for Information Technology, "IEEE std. 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2012. |
[IEEE802154] | IEEE standard for Information Technology, "IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks", June 2011. |
[OpenWSN] | Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., Weekly, K., Wang, Q., Glaser, S. and K. Pister, "OpenWSN: a Standards-Based Low-Power Wireless Development Environment", Transactions on Emerging Telecommunications Technologies , August 2012. |
[morell04label] | Morell, A., Vilajosana, X., Lopez-Vicario, J. and T. Watteyne, "Label Switching over IEEE802.15.4e Networks. Transactions on Emerging Telecommunications Technologies", June 2013. |