6TiSCH Operation Sublayer (6top)
draft-wang-6tisch-6top-sublayer-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Qin Wang , Xavier Vilajosana | ||
| Last updated | 2015-10-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-6tisch-6top-sublayer-02
6TiSCH Q. Wang, Ed.
Internet-Draft Univ. of Sci. and Tech. Beijing
Intended status: Informational X. Vilajosana
Expires: April 11, 2016 Universitat Oberta de Catalunya
October 9, 2015
6TiSCH Operation Sublayer (6top)
draft-wang-6tisch-6top-sublayer-02
Abstract
This document defines the 6TiSCH Operation Sublayer (6top), which
offers mechanisms for distributed scheduling in 6TiSCH networks. The
6top sublayer is the next higher layer of the IEEE802.15.4e TSCH
medium access control layer. The 6top Protocol (6P) defined in this
document allows neighbor nodes to add/delete TSCH cells to one
another. To be able to match different application requirements, the
algorithm of when to add/delete cells, called the 6top Objective
Function (6OF), is left out of scope, and will be specified in one of
more companion documents.
Requirements Language
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].
Status of This Memo
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 April 11, 2016.
Wang & Vilajosana Expires April 11, 2016 [Page 1]
Internet-Draft 6tisch-6top-sublayer October 2015
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 6TiSCH Operation Sublayer (6top) . . . . . . . . . . . . . . 4
2.1. Hard/Soft Cells . . . . . . . . . . . . . . . . . . . . . 4
2.2. 6top and minimal . . . . . . . . . . . . . . . . . . . . 4
3. 6top Protocol (6P) . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. 6top Information Element . . . . . . . . . . . . . . 6
3.1.2. General Message Format . . . . . . . . . . . . . . . 6
3.1.3. 6P OpCode . . . . . . . . . . . . . . . . . . . . . . 6
3.1.4. 6P Cell Format . . . . . . . . . . . . . . . . . . . 7
3.1.5. 6P ADD Request Format . . . . . . . . . . . . . . . . 7
3.1.6. 6P DELETE Request Format . . . . . . . . . . . . . . 8
3.1.7. 6P Response Format . . . . . . . . . . . . . . . . . 8
3.2. Protocol Behavior . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Version Checking . . . . . . . . . . . . . . . . . . 8
3.2.2. 6OFID Checking . . . . . . . . . . . . . . . . . . . 9
3.2.3. Concurrent Atomic Transactions . . . . . . . . . . . 9
3.2.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.5. Adding cells . . . . . . . . . . . . . . . . . . . . 9
3.2.6. Deleting cells . . . . . . . . . . . . . . . . . . . 10
3.2.7. Handling error responses . . . . . . . . . . . . . . 10
3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Guidelines for 6top Objective Functions (6OF) . . . . . . . . 11
4.1. 6OF Identifier (6OFID) . . . . . . . . . . . . . . . . . 11
4.2. Requirements for a 6OF . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. [TEMPORARY] IEEE Liaison Considerations . . . . . . 13
Wang & Vilajosana Expires April 11, 2016 [Page 2]
Internet-Draft 6tisch-6top-sublayer October 2015
Appendix B. [TEMPORARY] Terms for the Terminology Draft . . . . 13
Appendix C. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
All communication in a 6TiSCH network is orchestrated by a schedule.
This specification defines the mechanisms offered by the 6TiSCH
Operation Sublayer (6top) sublayer. These mechanisms allow a node to
communicate with its neighbor node(s) to agree on a TSCH schedule in
a distributed manner.
(A)
/ \
/ \
(B)-----(C)
| |
| |
(D) (E)
Figure 1: A simple 6TiSCH network.
For example, node C in Figure 1 monitors the communication cells to
node A it has in its schedule.
o If node C determines the number of frames it is sending to A per
unit of time is larger than the capacity offered by the TSCH cells
it has scheduled to A, it communicates with node A to add one or
more cells.
o If node C determines collisions are happening on a particular cell
to node A, it communicates with node A to add a new cell and
delete the cell which suffered from collisions. This results,
conceptually, in "relocating" the cell which suffered from
collisions to a different slotOffset/channelOffset location in the
TSCH schedule.
o If the traffic is lower than the capacity, node C communicates
with node A to delete one or more cells to A.
This results in a distributed schedule management solution.
The mechanisms needed to enable this interaction are defined by the
6TiSCH Operation Sublayer (6top) sublayer, described in Section 2.
The 6top Protocol (6P), specified in Section 3, defines the
communication between neighbor nodes in this context. The 6top
sublayer includes a 6top Objective Function (6OF) which defines
policy of when to add/delete a cell to a neighbor. Different
applications require different 6OFs, so the 6OF is left out of scope
of this document. One of more 6OFs will be defined in one of more
Wang & Vilajosana Expires April 11, 2016 [Page 3]
Internet-Draft 6tisch-6top-sublayer October 2015
companion documents. Section 4 provides some guidelines on how to
design a 6OF.
2. 6TiSCH Operation Sublayer (6top)
As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) sits
directly above the IEEE802.15.4e TSCH medium access control layer
[IEEE802154e].
.
| . |
| next higher layer |
+------------------------------------------+
| 6top |
+------------------------------------------+
| IEEE802.15.4e TSCH |
| . |
.
Figure 2: The 6top sublayer in the protocol stack.
The roles of the 6top sublayer are:
o Implement and terminate the 6top Protocol (6P), which allows
neighbor nodes to communicate to add/delete cells to one another.
o Run a 6top Objective Function (6OF) which defines the algorithm to
decide when to add/delete cells.
o Offer a way for a neighbor node to discover which 6OF is being
used.
2.1. Hard/Soft Cells
6top qualifies each cell in the schedule as either "hard" or "soft":
o Soft Cell: can be read, added, deleted or updated by 6top.
o Hard Cell: is read-only by 6top.
In the context of this specification, all cells are soft. Hard cells
can be used for example when "hard-coding" a cell (e.g. the 6TiSCH
Configuration [I-D.ietf-6tisch-minimal]).
2.2. 6top and minimal
6top MAY be used alongside the Minimal 6TiSCH Configuration
[I-D.ietf-6tisch-minimal]. In this case, it is RECOMMENDED to use 2
slotframes, as depicted in Figure 3:
Wang & Vilajosana Expires April 11, 2016 [Page 4]
Internet-Draft 6tisch-6top-sublayer October 2015
o Slotframe 0 (SF0) is used for traffic defined in the Minimal
6TiSCH Configuration. In Figure 3, this slotframe is 5 slots
long, but it can be of any length.
o Slotframe 1 (SF1) is used by 6top to allocate cells from. In
Figure 3, this slotframe is 10 slots long, but it can be of any
length.
.
SF0 SHOULD be of higher priority than SF1. 6top MAY support further
slotframes; how to use more slotframes is out of the scope for this
document.
| 0 1 2 3 4 | 0 1 2 3 4 |
+------------------------+------------------------+
SF0 | EB | | | | | EB | | | | |
| | | | | | | | | | |
---------------------------------------------------
SF1 | |A->B| | | | | | |B->A| |
| | | | | | | | | | |
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 |
Figure 3: 2-slotframe structure when using 6top alongside the Minimal
6TiSCH Configuration.
3. 6top Protocol (6P)
The 6top Protocol (6P) allows two neighbor nodes to pass information
to add/delete cells to their TSCH schedule. This information is
carried as IEEE802.15.4 Information Elements (IE) [IEEE802154e] and
travels only a single hop.
Conceptually, two neighbor nodes "negotiate" the location of the
cells to add/delete. We reuse the topology in Figure 1 to illustrate
how the protocol works.
When node A wants to add (resp. delete) 2 cells to/from node B:
1. Node A sends a message to node B indicating it wants to add
(resp. delete) 2 cells to/from node B to its schedule, and
listing 2 or more candidate cells.
2. Node B responds with a message indicating that the operation
succeeded, and specifying which cells from the candidate list it
added (resp. deleted). This allows node A to add (resp. delte)
the same cells to/from its schedule.
Wang & Vilajosana Expires April 11, 2016 [Page 5]
Internet-Draft 6tisch-6top-sublayer October 2015
We call "6top Atomic Transaction" the action of two neighbor nodes
exchanging a 6P Request Message and the corresponding 6P Reply
message.
3.1. Message Format
3.1.1. 6top Information Element
The messages exchanges as part of the 6P protocol are carried in a
6top Information Element. The 6top Information Element is Payload IE
with Group ID IANA_6TOP_IE_GROUP_ID. The length of the 6top
Information Element is Variable. The content of the 6top Information
Element is specified in Section 3.1.
3.1.2. General Message Format
All 6P messages have the following format:
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |OpCode | 6OFID | Other Fields
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver (6P Version): The version of the 6P protocol. Only version
IANA_6P_VERSION is defined in this document. Future
specification might define further version of the 6P protocol.
OpCode (6P OpCode): Operation to carry out, or the response code.
The list of OpCode values is defined only for version
IANA_6P_VERSION in this document.
6OFID (6top Objective Function Identifier): The identifier of the
6OF to use to handle this message. The 6OFID is defined in
Section 4.1.
Other Fields: The list of other fields depends on the value of the
OpCode, as detailed below.
3.1.3. 6P OpCode
Figure 4 lists the possible OpCode values.
Wang & Vilajosana Expires April 11, 2016 [Page 6]
Internet-Draft 6tisch-6top-sublayer October 2015
Value OpCode RC Description
+-------------------+--------------+---+----------------------------+
| IANA_ADD | ADD | N | add one or more cells |
+-------------------+-----------------------------------------------+
| IANA_DELETE | DELETE | N | delete one or more cells |
+-------------------+-----------------------------------------------+
| IANA_RC_SUCCESS | RC_SUCCESS | Y | operation succeeded |
+-------------------+-----------------------------------------------+
| IANA_RC_ERR_VER | RC_ERR_VER | Y | unsupported 6P version |
+-------------------+-----------------------------------------------+
| IANA_RC_ERR_6OFID | RC_ERR_6OFID | Y | unsupported 6OFID |
+-------------------+-----------------------------------------------+
| IANA_RC_ERR_BUSY | RC_ERR_BUSY | Y | the node is busy |
+-------------------+-----------------------------------------------+
| IANA_RC_ERR | RC_ERR | Y | operation failed |
+-------------------+-----------------------------------------------+
| TODO-0xf | reserved |
+-------------------+-----------------------------------------------+
Figure 4: 6P OpCodes. (RC is return code)
3.1.4. 6P Cell Format
The 6P Cell is an element which is present in several messages. It
is a 4-byte field formatted as:
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| slotOffset | channelOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
slotOffset: The slot offset of the cell.
channelOffset: The channel offset of the cell.
3.1.5. 6P ADD Request Format
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |OpCode | 6OFID | NumCells | Container |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-
Ver: Set to IANA_6P_VERSION.
OpCode: Set to IANA_ADD for a 6P ADD Request.
Wang & Vilajosana Expires April 11, 2016 [Page 7]
Internet-Draft 6tisch-6top-sublayer October 2015
6OFID: Identifier of the 6OF to be used by the receiver to handle
the message.
NumCells: The number of additional TX cells the sender wants to
schedule to the receiver.
Container: An indication of where in the schedule to take the cells
from (which slotframe, which chunk, etc.). This value is an
indication to the 6OF. The meaning of this field depends on
the 6OF, and is hence out of scope of this document.
CellList: A list of 0, 1 of multiple 6P Cells. The format of a 6P
Cell is defined in Section 3.1.4
3.1.6. 6P DELETE Request Format
The 6P DELETE Request has the exact same format as the 6P ADD
Request, except for the OpCode which is set to IANA_DELETE.
3.1.7. 6P Response Format
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |OpCode | 6OFID | CellList ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver: Set to IANA_6P_VERSION.
6OFID: Identifier of the 6OF to be used by the receiver to handle
the message.
OpCode: One of the "return code" OpCodes listed in Section 3.1.3.
CellList: A list of 0, 1 of multiple 6P Cells. The format of a 6P
Cell is defined in Section 3.1.4.
3.2. Protocol Behavior
For illustration, we assume we use the topology in Figure 1, and that
node A negotiates to add/delete cells to node B.
3.2.1. Version Checking
All messages contain a Version field. If multiple Versions of the 6P
protocol have been defined (in future specifications for Version
values different than IANA_6P_VERSION), a node MAY implement multiple
protocol versions at the same time. When receiving a 6P message with
a Version number it does not implement, a node MUST reply with a 6P
Response and a return code of IANA_RC_ERR_VER. The Version field in
the 6P Response MUST be the same as the Version field in the
corresponding 6P Request.
Wang & Vilajosana Expires April 11, 2016 [Page 8]
Internet-Draft 6tisch-6top-sublayer October 2015
3.2.2. 6OFID Checking
All messages contain a 6OFID field. If multiple 6OFs has been
defined, a node MAY support multiple 6OFs at the same time. When
receiving a 6P message with an unsupported 6OFID, a node MUST reply
with a 6P Response and a return code of IANA_RC_ERR_6OFID. The
Version field in the 6P Response MUST be the same as the Version
field in the corresponding 6P Request.
3.2.3. Concurrent Atomic Transactions
Only a single 6P Atomic Transaction between two neighbors, in a given
direction, can take place at the same time. That is, a node MUST NOT
issue a new 6P Request to a given neighbor before having received the
6P Response for a previous request to that neighbor. The only
exception to this rule is when the previous Atomic Transaction has
timed out. If a node receives a 6P Request from a given neighbor
before having sent the 6P Response to the previous 6P Request from
that neighbor, it MUST send back a 6P Response with a return code of
IANA_RC_ERR.
A node MAY support concurrent Atomic Transactions from different
neighbors. In this case, in Figure 1, node C can have a different
ongoing Atomic Transaction with nodes B and E. In case a node does
not have enough resources to handle concurrent Atomic Transactions
from different neighbors, when it receives a 6P Request from a
neighbor while already handling a different request from a different
neighbor, it MUST reply to that second request with a 6P Response
with return code IANA_RC_ERR_BUSY.
3.2.4. Timeout
A timeout happens when the node sending the 6P Request has not
received the 6P Response. The value of the timeout is coupled with
how the cells between the nodes are scheduled. The 6OF determines
the value of the timeout. The value of the timeout is out of scope
of this document.
3.2.5. Adding cells
We assume the topology in Figure 1 where the 6OF on node C decides to
add NumCell cells to node A.
Node C's 6OF selects NumCandidate>=NumCell cells from its schedule as
candidate transmit cells to node A. NumCandidate MUST be larger or
equal to NumCell. How many cells it selects (NumCandidate) and how
that selection is done is specified in the 6OF and out of scope of
this document. Node C sends a 6P ADD Request to node A which
Wang & Vilajosana Expires April 11, 2016 [Page 9]
Internet-Draft 6tisch-6top-sublayer October 2015
contains the value of NumCells and the NumCandidate cells in the
CellList.
Upon receiving the request, node A's 6OF verifies which of the cells
in the CellList it can add as receive cells from node C in its own
schedule. How that selection is done is specified in the 6OF and out
of scope of this document. That verification can succeed (NumCell
cells from the CellList can be used), fail (none of the cells from
the CellList can be used) or partially succeed (less than NumCell
cells from the CellList can be used). In all cases, node A MUST send
a 6P Response with return code set to IANA_RC_SUCCESS, and which
specifies the list of cells that were scheduled as receive cells from
C. That can contain 0 elements (when the verification failed),
NumCell elements (succeeded) or between 0 and NumCell elements
(partially succeeded).
Upon receiving the response, node C adds the cells specified in the
CellList as transmit cells to node A.
3.2.6. Deleting cells
The behavior for deleting cells is equivalent to that of adding cells
except that:
o The nodes delete the cells they agree upon rather than adding
them.
o All cells in the CellList MUST be already scheduled between the
two nodes.
o If the CellList in the 6P Request is empty, the 6OF on the
receiving node is free to delete any cell from the sender.
o The CellList MUST either be equal, contain exactly NumCell cells,
or more than NumCell cells. The case where the CellList is not
empty but contains less than NumCell cells is not supported.
3.2.7. Handling error responses
A return code with a name starts with "RC_ERR" in Figure 4 indicates
an error. When a node receives a 6P Response with such an error, it
MUST consider the Atomic Transaction has failed. In particular, if
this was a response to a 6P ADD/DELETE Request, the node MUST NOT
add/delete any of the cells involved in this Atomic Transaction.
Similarly, a node sending a 6P Response with an "RC_ERR" return code
MUST NOT add/delete any cells as part of that Atomic Transaction.
The 6OF defines what to do after an error has occurred. Defining
what to do after an error has occurred is out of scope of this
document.
Wang & Vilajosana Expires April 11, 2016 [Page 10]
Internet-Draft 6tisch-6top-sublayer October 2015
3.3. Security
6P messages are secured through link-layer security. When link-layer
security is enabled, the 6P messages MUST be secured. This is
possible because 6P messages are carried as Payload IE.
4. Guidelines for 6top Objective Functions (6OF)
4.1. 6OF Identifier (6OFID)
Each 6OF has an identifier. The identifier is encoded as a 1-byte
field. The identifier space is divided in the following ranges.
Range Meaning
+-----------+-------------+
| 0x00 | reserved |
+-----------+--------------
| 0x01-0x7f | managed |
+-----------+--------------
| 0x80-0xfe | unmanaged |
+-----------+-------------+
| 0xff | reserved |
+-----------+-------------+
Figure 5: 6OFID range.
6OF identifiers in the managed space MUST be managed by IANA.
4.2. Requirements for a 6OF
The specification for a 6OF
o MUST specify an identifier for that 6OF.
o MUST specify a set of rules for a node to decide when to add one
or more cells to a neighbor.
o MUST specify a set of rules for a node to decide when to delete
one or more cells to a neighbor.
o MUST specify a value for the timeout, or a rule to calculate it.
o MUST specify a meaning for the "Container" field in the 6P ADD
Request.
o MUST specify the rule for selecting the cells (including their
number) to add to the CellList field in the 6P ADD Request.
o MUST specify the rule for verifying which cells from the CellList
it can add to it schedule.
o MUST specify what to do after an error has occurred (either the
node sent a 6P Response with an error code, or received one).
o SHOULD clearly state the application domain the 6OF is created
for.
Wang & Vilajosana Expires April 11, 2016 [Page 11]
Internet-Draft 6tisch-6top-sublayer October 2015
o SHOULD contain examples which highlight normal and error
scenarios.
o SHOULD contain a performance evaluation of the scheme, possibly
through references to external documents.
5. Security Considerations
TODO: analyze risks
6P messages are carried inside IEEE802.15.4 Payload Information
Elements (IEs). Those Payload IEs are encrypted and authenticated at
the link layer through CCM*. 6P benefits from the same level of
security as any other Payload IE. The 6P protocol does not define
its own security mechanisms. A key management solution is out of
scope for this document. The 6P protocol will benefit for the key
management solution used in the network.
6. IANA Consideration
o TODO: IANA_6TOP_IE_GROUP_ID
o TODO: IANA_6P_VERSION
o TODO: IANA_ADD
o TODO: IANA_DELETE
o TODO: IANA_RC_SUCCESS
o TODO: IANA_RC_ERR_VER
o TODO: IANA_RC_ERR_BUSY
o TODO: IANA_RC_ERR
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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.
Wang & Vilajosana Expires April 11, 2016 [Page 12]
Internet-Draft 6tisch-6top-sublayer October 2015
7.2. Informative References
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<http://www.rfc-editor.org/info/rfc7554>.
[I-D.ietf-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH
Configuration", draft-ietf-6tisch-minimal-12 (work in
progress), September 2015.
[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", draft-ietf-6tisch-terminology-05 (work in
progress), July 2015.
[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.
Appendix A. [TEMPORARY] IEEE Liaison Considerations
The 6P messages are carried into a single IEEE802.15.4 Payload
Information Element. We need a mechanism to discriminate 6P messages
from other IEs. In the text, we assume a Payload IE Group ID
(IANA_6TOP_IE_GROUP_ID) assigned. Another option would be for the
IEEE to assign a Payload IE Group ID to the IETF, and for 6TiSCH to
coordinate the creation of a IANA entry for subIEs.
Appendix B. [TEMPORARY] Terms for the Terminology Draft
Terms introduced by this document, and which needs to be added to
[I-D.ietf-6tisch-terminology]:
6top: The "6TiSCH Operation Sublayer", which the next highest
layer of the IEEE802.15.4e TSCH medium access control
layer. It implements and terminates the "6top Protocol"
(6P), and contains a "6top Objective Function" (6OF). It
is defined in LINK_draft-wang-6tisch-6top-sublayer.
6OF: The "6top Objective Function", the policy inside the
"6TiSCH Operation Sublayer" (6top) which decides when to
add/remove cells. It is defined in LINK_draft-wang-
6tisch-6top-sublayer.
Wang & Vilajosana Expires April 11, 2016 [Page 13]
Internet-Draft 6tisch-6top-sublayer October 2015
6OFID: The "6top Objective Function Identifier", a 4-bit field
identifying a 6OF. It is defined in LINK_draft-wang-
6tisch-6top-sublayer.
6P: The "6top Protocol", which allows neighbor nodes to
communicate to add/delete cells to one another in their
TSCH schedule. It is defined in LINK_draft-wang-6tisch-
6top-sublayer.
6top Atomic Transaction: Part of the "6top Protocol" (6P), the
action of two neighbors exchanging a 6P request message
and the corresponding 6P response message. It is defined
in LINK_draft-wang-6tisch-6top-sublayer.
Appendix C. [TEMPORARY] Changelog
o -02
* introduces the 6P protocol and the notion of 6top Atomic
Transaction.
* introduces the concept of 6OF and its 6OFID.
Authors' Addresses
Qin Wang (editor)
Univ. of Sci. and Tech. Beijing
30 Xueyuan Road
Beijing, Hebei 100083
China
Phone: +86 (10) 6233 4781
Email: wangqin@ies.ustb.edu.cn
Xavier Vilajosana
Universitat Oberta de Catalunya
156 Rambla Poblenou
Barcelona, Catalonia 08018
Spain
Phone: +34 (646) 633 681
Email: xvilajosana@uoc.edu
Wang & Vilajosana Expires April 11, 2016 [Page 14]