Univ. of Sci. and Tech. Beijing

30 Xueyuan Road Beijing Hebei 100083 China +86 (10) 6233 4781 wangqin@ies.ustb.edu.cn

Universitat Oberta de Catalunya

156 Rambla Poblenou Barcelona Catalonia 08018 Spain +34 (646) 633 681 xvilajosana@uoc.edu

Internet Area 6TiSCH Draft This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes in a 6TiSCH network to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer of the IEEE802.15.4 TSCH medium access control layer. The 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P transactions. Several SFs can be defined, each identified by a different 6top Scheduling Function Identifier (SFID). This document lists the requirements for an SF, but leaves the definition of the SF out of scope. Different SFs are expected to be defined in future companion specifications. 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.

This document is an Internet Draft, so work-in-progress by nature. It contains the following work-in-progress elements: "TODO" statements are elements which have not yet been written by the authors for some reason (lack of time, ongoing discussions with no clear consensus yet, etc). The statement does indicate that the text will be written. "TEMPORARY" Appendices are there to capture current ongoing discussions or the changelog of the document. These appendices will be removed in the final text. "IANA_" identifiers are placeholders for numbers assigned by IANA. These placeholders are to be replaced by the actual values they represent after their assignment by IANA. This section will be removed in the final text.

All communication in a 6TiSCH network is orchestrated by a schedule . This specification defines the 6top Protocol (6P), part of the 6TiSCH Operation Sublayer (6top) sublayer. 6P allow a node to communicate with a neighbor to add/delete a TSCH cell to one another. 6P hence enables distributed scheduling in a 6TiSCH network.

For example, node C in monitors the communication cells to node A it has in its schedule. 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 triggers a 6P transaction with node A to add one or more cells to A in the TSCH schedule. If the traffic is lower than the capacity, node C triggers a 6P transaction with node A to delete one or more cells to A in the TSCH schedule. Node C might also monitor statistics to determine whether collisions are happening on a particular cell to node A. If this feature is enabled, node C communicates with node A to add a new cell and delete the cell which suffered from collisions. This conceptually results in "relocating" the cell which suffered from collisions to a different slotOffset/channelOffset location in the TSCH schedule. The mechanism to handle cell relocation is out of the scope of this document and might be defined in a future document. This results in distributed schedule management in a 6TiSCH network. The 6top Scheduling Function (SF) defines when to add/delete a cell to a neighbor. The SF functions as a (required) add-on to 6P. Different applications require different SFs, so the SF is left out of scope of this document. Different SFs are expected to be defined in future companion specifications. A node MAY implement multiple SFs and run them at the same time. The SFID field contained in all 6P messages allows a node to switch between SFs on a per-transaction basis. describes the 6TiSCH Operation Sublayer (6top). defines the 6top Protocol (6P). provides guidelines on how to design an SF.

As depicted in , the 6TiSCH Operation Sublayer (6top) is the next higher layer to the IEEE802.15.4 TSCH medium access control layer .

The roles of the 6top sublayer are: Implement and terminate the 6top Protocol (6P), which allows neighbor nodes to communicate to add/delete cells to one another. Run one or more 6top Scheduling Function (SF), which define the algorithm to decide when to add/delete cells.

6top qualifies each cell in the schedule as either "hard" or "soft": a Soft Cell can be read, added, deleted or updated by 6top. a Hard Cell is read-only for 6top. In the context of this specification, all the cells used by 6top are Soft Cells. Hard cells can be used for example when "hard-coding" a scheduling. This is done, for example, in the Minimal 6TiSCH Configuration .

6top MAY be used alongside the Minimal 6TiSCH Configuration . In this case, it is RECOMMENDED to use 2 slotframes, as depicted in : Slotframe 0 is used for traffic defined in the Minimal 6TiSCH Configuration. In , this slotframe is 5 slots long, but it can be of any length. Slotframe 1 is used by 6top to allocate cells from. In , this slotframe is 10 slots long, but it can be of any length. Slotframe 0 SHOULD be of higher priority than Slotframe 1. 6top MAY support further slotframes; how to use more slotframes is out of the scope for this document.

B| | | | | | |B->A| | low priority | | | | | | | | | | | +-------------------------------------------------+ ]]>

The 6top Protocol (6P) allows two neighbor nodes to communicate to add/delete cells to their TSCH schedule. Conceptually, two neighbor nodes "negotiate" the location of the cell(s) to add/delete.

We call "6top Transaction" a complete negotiation between two neighbor nodes. A transaction starts when a node wishes to add/delete one or more cells to one of its neighbors; it ends when the cell(s) have been added removed from the schedule of both neighbor, or when the transaction has failed. A transaction can consist of 2 or 3 steps. It is the SF which determines whether to use 2-step or 3-step transactions. An SF MAY use both 2-step and 3-step transactions. We reuse the topology in to illustrate 2-step and 3-step transactions.

6P supports both 2- and 3-step transactions; the SF determinisms which to use. Without loss of generality, this section illustrates 2-step transaction through an example. is a sequence diagram to help understand the core principle of 6P (several elements are left out to simplify understanding). We assume the SF running on node A determines 2 extra cells need to be scheduled to node B. In this example, node A proposes the cells to use.

| | | | 6P Response | | Return Code = IANA_6TOP_RC_SUCCESS | | CellList = [(2,2),(3,5)] | |<--------------------------------------| | | ]]>

In this example, the 2-step transaction occurs as follows: The SF running on node A selects 3 candidate cells. Node A sends a 6P ADD Request to node B, indicating it wishes to add 2 cells (the "NumCells" value), and specifying the list of 3 candidate (the "CellList" value). Each cell in the CellList is a (slotOffset,channelOffset) tuple. The SF running on node B selects 2 of the 3 cells in the CellList of the 6P ADD Request. Node B sends back a 6P Response to node A, indicating the cells it selected. The result of this 6P transaction is that 2 cells from A to B have been added to the TSCH schedule of both nodes A and B.

6P supports both 2- and 3-step transactions; the SF determinisms which to use. Without loss of generality, this section illustrates 3-step transaction through an example. is a sequence diagram to help understand the core principle of 6P (several elements are left out to simplify understanding). We assume the SF running on node A determines 2 extra cells need to be scheduled to node B. In this example, node B proposes the cells to use.

| | | | 6P Response | | Return Code = IANA_6TOP_RC_SUCCESS | | CellList = [(1,2),(2,2),(3,5)] | |<--------------------------------------| | | | 6P Confirmation | | Return Code = IANA_6TOP_RC_SUCCESS | | CellList = [(2,2),(3,5)] | |-------------------------------------->| | | ]]>

In this example, the 3-step transaction occurs as follows: The SF running on node A determines 2 extra cells need to be scheduled to node B, but does not select candidate cells. Node A sends a 6P ADD Request to node B, indicating it wishes to add 2 cells (the "NumCells" value), with en empty "CellList". The SF running on node B selects 3 candidate cells. Node B sends back a 6P Response to node A, indicating the 3 cells it selected. The SF running on node A selects 2 cells. Node A sends back a 6P Confirmation to node B, indicating the cells it selected. The result of this 6P transaction is that 2 cells from A to B have been added to the TSCH schedule of both nodes A and B.

6P messages are carried as payload of IEEE802.15.4 Information Elements (IE) . 6p messages travel over a single hop.

The 6top IE is an IETF IE with GroupID IANA_IETF_IE_GROUP_ID. The Sub-ID used by the 6top IE is IANA_6TOP_SUBIE_ID. The length of the 6top IE content is variable. The content of the 6top IE is specified in . The Payload Termination IE is defined by the IEEE802.15.4 standard . TODO: IETF IE specified in for now, but to be specified in a separate draft in the future.

In all 6P messages, the 6top IE content has the following format:

The version of the 6P protocol. Only version IANA_6TOP_6P_VERSION is defined in this document. Future specifications MIGHT define further version of the 6P protocol. Command to carry out or response code. The list of command identifiers and return codes is defined only for version IANA_6TOP_6P_VERSION in this document. The identifier of the SF to use to handle this message. The SFID is defined in . An identifier of the packet, used to match request and response. The value of SeqNum MUST increment by exactly one at each new 6P request issued to the same neighbor. The list of other fields depends on the value of the code field, as detailed below.

lists the 6P command identifiers.

lists the 6P Return Codes and their meaning.

The 6P Cell is an element which is present in several messages. It is a 4-byte field, its RECOMMENDED format is:

The slot offset of the cell. The channel offset of the cell. The CellList is an opaque set of bytes, sent unmodified to the SF. The SF MAY redefine the format of the CellList field.

Set to IANA_6TOP_6P_VERSION. Set to IANA_6TOP_CMD_ADD for a 6P ADD Request. Identifier of the SF to be used by the receiver to handle the message. Packet identifier to match 6P Request and 6P Response. The number of additional TX cells the sender wants to schedule to the receiver. Metadata used as extra signaling to the SF. One example use can be to specify which slotframe to schedule the cells to. The contents of the Metadata field is an opaque set of bytes, and passed unmodified to the SF. The meaning of this field depends on the SF, and is hence out of scope of this document. A list of 0, 1 or multiple 6P Cells. The RECOMMENDED format of each 6P Cell is defined in . The CellList is an opaque set of bytes, sent unmodified to the SF. The SF MAY redefine the format of the CellList field.

The 6P DELETE Request has the exact same format as the 6P ADD Request, except for the code which is set to IANA_6TOP_CMD_DELETE.

Set to IANA_6TOP_6P_VERSION. Set to IANA_6TOP_CMD_COUNT for a 6P COUNT Request. Identifier of the SF to be used by the receiver to handle the message. Packet identifier to match request and response. Metadata used as extra signaling to the SF. One example use can be to specify which slotframe to schedule the cells to. The contents of the Metadata field is an opaque set of bytes, and passed unmodified to the SF. The meaning of this field depends on the SF, and is hence out of scope of this document.

The 6P LIST Request has the exact same format as the 6P COUNT Request, except for the code which is set to IANA_6TOP_CMD_LIST.

The 6P CLEAR Request has the exact same format as the 6P COUNT Request, except for the code which is set to IANA_6TOP_CMD_CLEAR.

Set to IANA_6TOP_6P_VERSION. Identifier of the SF to be used by the receiver to handle the message. The response MUST contain the same SFID value as the value in the SFID field of the 6P Request is responds to. One of the 6P Return Codes listed in . Packet identifier to match request and response. The response MUST contain the same SeqNum value as the value in the SeqNum field of the 6P Request is responds to. The fields depends on what command the request is for: A list of 0, 1 or multiple 6P Cells. The format of a 6P Cell is defined in . The number of cells scheduled from the requesting node to the receiver node by the 6P protocol, encoded as a 2-octet unsigned integer. No other fields are present in the response.

A 6P Confirmation is only used in a 3-step transaction, as the third step. A 6P Confirmation Message has the exact same format as a 6P Response Message. It is only the fact that it appears as the third step in a 3-step transaction that distinguishes it from a 6P Response. In particular, the same Return Codes are used in both 6P Response and 6P Confirmation messages.

For illustration, we assume we use the topology in , and that node A negotiates to add/delete cells to node B.

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_6TOP_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_6TOP_RC_VER_ERR. The Version field in the 6P Response MUST be the same as the Version field in the corresponding 6P Request.

All messages contain a SFID field. If multiple SFs has been defined, a node MAY support multiple SFs at the same time. When receiving a 6P message with an unsupported SFID, a node MUST reply with a 6P Response and a return code of IANA_6TOP_RC_SFID_ERR. The Version field in the 6P Response MUST be the same as the Version field in the corresponding 6P Request.

Only a single 6P 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 6P 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_6TOP_RC_ERR. A node MAY support concurrent 6P Transactions from different neighbors. In this case the cells involved in the ongoing 6P transaction MUST be locked until the transaction finishes. For example, in , node C can have a different ongoing 6P Transaction with nodes B and E. In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors or if the cells requested are locked, it MUST reply to that second request with a 6P Response with return code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement a retry mechanism, as decided by the Scheduling Function.

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 SF determines the value of the timeout. The value of the timeout is out of scope of this document.

When a node receives a 6P Response with SeqNum value different from the SeqNum value in the 6P Request, it MUST drop the packet and consider the 6P Transaction as having failed.

We assume the topology in where the SF on node C decides to add NumCell cells to node A. Node C's SF 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 SF and out of scope of this document. Node C sends a 6P ADD Request to node A which contains the value of NumCells and the NumCandidate cells in the CellList. Upon receiving the request, node A's SF 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 SF 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_6TOP_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.

In case the receiver of a 6top request fails during a 6P Transaction and is unable to complete it, it SHOULD reply to that request with a 6P Response with return code IANA_6TOP_RC_RESET. Upon receiving this 6top reply, the initiator of the 6P Transaction MUST consider the 6P Transaction as failed.

The behavior for deleting cells is equivalent to that of adding cells except that: The nodes delete the cells they agree upon rather than adding them. All cells in the CellList MUST be already scheduled between the two nodes. If the CellList in the 6P Request is empty, the SF on the receiving node is free to delete any cell from the sender. 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.

A return code with a name starting with "RC_ERR" in indicates an error. When a node receives a 6P Response with such an error, it MUST consider the 6P Transaction 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 6P Transaction. Similarly, a node sending a 6P Response with an "RC_ERR" return code MUST NOT add/delete any cells as part of that 6P Transaction. The SF 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.

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.

Each SF has an identifier. The identifier is encoded as a 1-byte field. The identifier space is divided in the following ranges.

SF identifiers in the managed space MUST be managed by IANA.

The specification for an SF MUST specify an identifier for that SF. MUST specify the rule for a node to decide when to add/delete one or more cells to a neighbor. MUST specify the rule for a Transaction source to select cells to add to the CellList field in the 6P ADD Request. MUST specify the rule for a Transaction destination to select cells from CellList to add to its schedule. MUST specify a value for the 6P Timeout, or a rule/equation to calculate it. MUST specify a meaning for the "Metadata" field in the 6P ADD Request. MUST specify the behavior of a node when it boots. MUST specify what to do after an error has occurred (either the node sent a 6P Response with an error code, or received one). MUST specify the list of statistics to gather. An example statistic if the number of transmitted frames to each neighbor. In case the SF requires no statistics to be gathered, the specific of the SF MUST explicitly state so. SHOULD clearly state the application domain the SF is created for. SHOULD contain examples which highlight normal and error scenarios. SHOULD contain a list of current implementations, at least during the I-D state of the document, per . SHOULD contain a performance evaluation of the scheme, possibly through references to external documents. MAY redefine the format of the CellList field.

The following section structure for a SF document is RECOMMENDED: Introduction Scheduling Function Identifier Rules for Adding/Deleting Cells Rules for CellList 6P Timeout Value Meaning of the Metadata Field Node Behavior at Boot 6P Error Handling Examples Implementation Status Security Considerations IANA Considerations

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 6P was one of two protocols addressed during the ETSI 6TiSCH #2 plugtests organized on 2-4 February 2016 in Paris, France. 14 entities participated in this event, verifying the compliance and interoperability of their implementation of 6P. This event happened under NDA, so neither the name of the entities nor the test results are public. This event is, however, a clear indication of the maturity of 6P, and the interest it generates. More information about the event at http://www.etsi.org/news-events/events/1022-6TiSCH-2-plugtests. 6P is implemented in the OpenWSN project under a BSD open-source license. The authors of this document are collaborating with the OpenWSN community to gather feedback about the status and performance of the protocols described in this document. Results from that discussion will appear in this section in future revision of this specification. More information about this implementation at http://www.openwsn.org/. A Wireshark dissector for 6P is implemented under a BSD open-source license. It is not yet merged into the main Wireshark build, but can be downloaded at https://github.com/openwsn-berkeley/dissectors/.

TODO: explicit 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.

TODO: write out this section as soon as the discussion with the IEEE about a possible IETF IE ID has concluded. TODO: IANA_IETF_IE_GROUP_ID TODO: IANA_6TOP_SUBIE_ID TODO: IANA_6TOP_6P_VERSION TODO: IANA_6TOP_CMD_ADD TODO: IANA_6TOP_CMD_DELETE TODO: IANA_6TOP_CMD_LIST TODO: IANA_6TOP_CMD_COUNT TODO: IANA_6TOP_CMD_CLEAR TODO: IANA_6TOP_RC_SUCCESS TODO: IANA_6TOP_RC_VER_ERR TODO: IANA_6TOP_RC_SFID_ERR TODO: IANA_6TOP_RC_BUSY TODO: IANA_6TOP_RC_RESET TODO: IANA_6TOP_RC_ERR

IEEE standard for Information Technology

This section contains a proposal for the specification of an IETF IE. If this proposal is supported by the 6TiSCH WG, the authors of this draft recommend for the specification of the IETF IE to be its own draft, possibly developed in the 6TiSCH WG. The reason for having it a separated document is that the scope of the IETF IE is wider that the 6P protocol defined in this document. The proposal is to use an IETF IE, a IEEE802.15.4 Payload Information Element with the Group ID set to IANA_IETF_IE_GROUP_ID. The value of IANA_IETF_IE_GROUP_ID is defined by the IEEE, communicated to the IETF, and noted by IANA. The format of the IETF IE is exactly the same as the format of an MLME Information Element, as specified in , Section 5.2.4.5. The difference is that the space of Sub-IDs is managed by the IETF/IANA. The Sub-ID used by 6top commands is IANA_6TOP_SUBIE_ID with value 0x00. Other options are being discussed between the IETF 6TiSCH WG and the IEEE 6TiSCH IG, and listed in https://www.ietf.org/mail-archive/web/6tisch/current/msg04469.html. These options concern the way 6P Messages are transported as IEEE802.15.4 IEs, and do not impact the format of those messages.

If the specification described in this document is supported by the 6TiSCH WG, the authors of this document ask the 6TiSCH WG chairs to liaise with the IEEE to request a Payload Information Element Group ID to be assigned to the IETF (Group ID IANA_IETF_IE_GROUP_ID described in ).

Terms introduced by this document, and which needs to be added to : The "6TiSCH Operation Sublayer" (6top) is the next highest layer of the IEEE802.15.4 TSCH medium access control layer. It implements and terminates the "6top Protocol" (6P), and contains one or more "6top Scheduling Function" (SF). It is defined in TODO_LINK_draft-wang-6tisch-6top-protocol. The "6top Scheduling Function" (SF) is the policy inside the "6TiSCH Operation Sublayer" (6top) which decides when to add/delete cells. It is defined in TODO_LINK_draft-wang-6tisch-6top-protocol. The "6top Scheduling Function Identifier" (SFID) is a 1-byte field identifying a SF. It is defined in TODO_LINK_draft-wang-6tisch-6top-protocol. The "6top Protocol" (6P) allows neighbor nodes to communicate to add/delete cells to one another in their TSCH schedule. It is defined in TODO_LINK_draft-wang-6tisch-6top-protocol. Part of the "6top Protocol" (6P), we call "6top Transaction" a complete negotiation between two neighbor nodes. A transaction starts when a node wishes to add/delete one or more cells to one of its neighbors; it ends when the cell(s) have been added removed from the schedule of both neighbor, or when the transaction has failed. It is defined in TODO_LINK_draft-wang-6tisch-6top-protocol.

draft-ietf-6tisch-6top-protocol-01 Clarifying locking of resources in concurrent transactions Clarifying return of RC_BUSY in case of concurrent transactions without enough resources draft-ietf-6tisch-6top-protocol-00 Informational to Std track draft-wang-6tisch-6top-protocol-00 Editorial overhaul: fixing typos, increasing readability, clarifying figures. https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/47 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/54 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/55 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/49 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/53 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/44 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/48 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/43 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/52 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/45 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/51 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/50 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/46 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/41 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/42 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/39 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/40 draft-wang-6tisch-6top-sublayer-05 Specifies format of IE Adds token in messages to match request and response draft-wang-6tisch-6top-sublayer-04 Renames IANA_6TOP_IE_GROUP_ID to IANA_IETF_IE_GROUP_ID. Renames IANA_CMD and IANA_RC to IANA_6TOP_CMD and IANA_6TOP_RC. Proposes IANA_6TOP_SUBIE_ID with value 0x00 for the 6top sub-IE. draft-wang-6tisch-6top-sublayer-03 https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/32/missing-command-list https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/31/missing-command-count https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/30/missing-command-clear https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/37/6top-atomic-transaction-6p-transaction https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/35/separate-opcode-from-rc https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/36/add-length-field-in-ie https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/27/differentiate-rc_err_busy-and https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/29/missing-rc-rc_reset https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/28/the-sf-must-specify-the-behavior-of-a-mote https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/26/remove-including-their-number https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/34/6of-sf https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/33/add-a-figure-showing-the-negociation draft-wang-6tisch-6top-sublayer-02 introduces the 6P protocol and the notion of 6top Transaction. introduces the concept of 6OF and its 6OFID.