summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8480.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8480.txt')
-rw-r--r--doc/rfc/rfc8480.txt2803
1 files changed, 2803 insertions, 0 deletions
diff --git a/doc/rfc/rfc8480.txt b/doc/rfc/rfc8480.txt
new file mode 100644
index 0000000..681f9f1
--- /dev/null
+++ b/doc/rfc/rfc8480.txt
@@ -0,0 +1,2803 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) Q. Wang, Ed.
+Request for Comments: 8480 Univ. of Sci. and Tech. Beijing
+Category: Standards Track X. Vilajosana
+ISSN: 2070-1721 Universitat Oberta de Catalunya
+ T. Watteyne
+ Analog Devices
+ November 2018
+
+
+ 6TiSCH Operation Sublayer (6top) Protocol (6P)
+
+Abstract
+
+ This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e"
+ (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables
+ distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes
+ to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one
+ another. 6P is part of the 6TiSCH Operation Sublayer (6top), the
+ layer just above the IEEE Std 802.15.4 TSCH Medium Access Control
+ layer. 6top is composed of one or more Scheduling Functions (SFs)
+ and the 6top Protocol defined in this document. A 6top SF decides
+ when to add/delete cells, and it triggers 6P Transactions. The
+ definition of SFs is out of scope for this document; however, this
+ document provides the requirements for an SF.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8480.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 1]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+Copyright Notice
+
+ Copyright (c) 2018 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
+ (https://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
+ 1.1. Requirements Language ......................................5
+ 2. 6TiSCH Operation Sublayer (6top) ................................5
+ 2.1. Hard/Soft Cells ............................................6
+ 2.2. Using 6P with the Minimal 6TiSCH Configuration .............6
+ 3. 6top Protocol (6P) ..............................................7
+ 3.1. 6P Transactions ............................................7
+ 3.1.1. 2-Step 6P Transaction ...............................8
+ 3.1.2. 3-Step 6P Transaction ..............................10
+ 3.2. Message Format ............................................12
+ 3.2.1. 6top Information Element (IE) ......................12
+ 3.2.2. Generic 6P Message Format ..........................12
+ 3.2.3. 6P CellOptions .....................................13
+ 3.2.4. 6P CellList ........................................16
+ 3.3. 6P Commands and Operations ................................17
+ 3.3.1. Adding Cells .......................................17
+ 3.3.2. Deleting Cells .....................................19
+ 3.3.3. Relocating Cells ...................................21
+ 3.3.4. Counting Cells .....................................27
+ 3.3.5. Listing Cells ......................................28
+ 3.3.6. Clearing the Schedule ..............................30
+ 3.3.7. Generic Signaling between SFs ......................31
+ 3.4. Protocol Functional Details ...............................31
+ 3.4.1. Version Checking ...................................31
+ 3.4.2. SFID Checking ......................................32
+ 3.4.3. Concurrent 6P Transactions .........................32
+ 3.4.4. 6P Timeout .........................................33
+ 3.4.5. Aborting a 6P Transaction ..........................33
+ 3.4.6. SeqNum Management ..................................33
+ 3.4.7. Handling Error Responses ...........................40
+ 3.5. Security ..................................................40
+
+
+
+Wang, et al. Standards Track [Page 2]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ 4. Requirements for 6top Scheduling Function (SF) Specifications ..41
+ 4.1. SF Identifier (SFID) ......................................41
+ 4.2. Requirements for an SF Specification ......................41
+ 5. Security Considerations ........................................42
+ 6. IANA Considerations ............................................43
+ 6.1. IETF IE Subtype 6P ........................................43
+ 6.2. 6TiSCH Parameters Subregistries ...........................43
+ 6.2.1. 6P Version Numbers .................................43
+ 6.2.2. 6P Message Types ...................................44
+ 6.2.3. 6P Command Identifiers .............................44
+ 6.2.4. 6P Return Codes ....................................45
+ 6.2.5. 6P Scheduling Function Identifiers .................46
+ 6.2.6. 6P CellOptions Bitmap ..............................47
+ 7. References .....................................................48
+ 7.1. Normative References ......................................48
+ 7.2. Informative References ....................................48
+ Appendix A. Recommended Structure of an SF Specification ..........49
+ Authors' Addresses ................................................50
+
+1. Introduction
+
+ All communication in an "IPv6 over the TSCH mode of IEEE 802.15.4e"
+ (6TiSCH) network is orchestrated by a schedule [RFC7554]. The
+ schedule is composed of cells, each identified by a
+ [slotOffset,channelOffset] (Section 3.2.4). This specification
+ defines the 6TiSCH Operation Sublayer (6top) Protocol (6P), which is
+ terminated by 6top. 6P allows a node to communicate with a neighbor
+ node to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on
+ one another. This results in distributed schedule management in a
+ 6TiSCH network. 6top is composed of one or more Scheduling Functions
+ (SFs) and the 6top Protocol defined in this document. The definition
+ of SFs is out of scope for this document; however, this document
+ provides the requirements for an SF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 3]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ The example network depicted in Figure 1 is used to describe the
+ interaction between nodes. We consider the canonical case where
+ node "A" issues 6P Requests (also referred to as "commands" in this
+ document) to node "B". We use this example throughout this document:
+ node A always represents the node that issues a 6P Request, and
+ node B represents the node that receives this request.
+
+ (R)
+ / \
+ / \
+ (B)-----(C)
+ | |
+ | |
+ (A) (D)
+
+ Figure 1: A Simple 6TiSCH Network
+
+ We consider that node A monitors the communication cells it has in
+ its schedule to node B:
+
+ o If node A determines that the number of link-layer frames it is
+ sending to node B per unit of time exceeds the capacity offered by
+ the TSCH cells it has scheduled to node B, it triggers a 6P
+ Transaction with node B to add one or more cells to the TSCH
+ schedule of both nodes.
+
+ o If the traffic is lower than the capacity offered by the TSCH
+ cells it has scheduled to node B, node A triggers a 6P Transaction
+ with node B to delete one or more cells in the TSCH schedule of
+ both nodes.
+
+ o Node A MAY also monitor statistics to determine whether collisions
+ are happening on a particular cell to node B. If this feature is
+ enabled, node A communicates with node B to "relocate" this
+ particular cell to a different [slotOffset,channelOffset] location
+ in the TSCH schedule.
+
+ This results in distributed schedule management in a 6TiSCH network.
+
+ The 6top SF defines when to add/delete a cell to/on a neighbor.
+ Different applications require different SFs; this topic is out of
+ scope for 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. At least one SF MUST be running. The
+ SFID field contained in all 6P messages allows a node to invoke the
+ appropriate SF on a per-6P Transaction basis.
+
+
+
+
+
+Wang, et al. Standards Track [Page 4]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Section 2 describes 6top. Section 3 defines 6P. Section 4 provides
+ guidelines on how to define an SF.
+
+1.1. 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
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. 6TiSCH Operation Sublayer (6top)
+
+ As depicted in Figure 2, 6top is the layer just above the IEEE Std
+ 802.15.4 TSCH Medium Access Control (MAC) layer [IEEE802154]. We use
+ "802.15.4" as a short version of "IEEE Std 802.15.4" in this
+ document.
+
+ .
+ | . |
+ | higher layers |
+ +------------------------------------------+
+ | 6top |
+ +------------------------------------------+
+ | IEEE Std 802.15.4 TSCH |
+ | . |
+ .
+
+ Figure 2: 6top in the Protocol Stack
+
+ The roles of 6top are to:
+
+ o Terminate 6P, which allows neighbor nodes to communicate to
+ add/delete cells to/on one another.
+
+ o Run one or multiple 6top SFs, which define the rules that decide
+ when to add/delete cells.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 5]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+2.1. Hard/Soft Cells
+
+ Each cell in the schedule is either "hard" or "soft":
+
+ o A soft cell can be read, added, deleted, or updated by 6top.
+
+ o 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 schedule [RFC8180].
+
+2.2. Using 6P with the Minimal 6TiSCH Configuration
+
+ 6P MAY be used alongside the minimal 6TiSCH configuration [RFC8180].
+ In this case, it is RECOMMENDED to use two slotframes, as depicted in
+ Figure 3:
+
+ o Slotframe 0 is used for traffic defined in the minimal 6TiSCH
+ configuration. In Figure 3, Slotframe 0 is five slots long, but
+ it can be shorter or longer.
+
+ o 6P allocates cells from Slotframe 1. In Figure 3, Slotframe 1 is
+ 10 slots long, but it can be shorter or longer.
+
+ | 0 1 2 3 4 | 0 1 2 3 4 |
+ +------------------------+------------------------+
+ Slotframe 0 | | | | | | | | | | |
+ 5 slots long | EB | | | | | EB | | | | |
+ (Minimal 6TiSCH) | | | | | | | | | | |
+ +-------------------------------------------------+
+
+ | 0 1 2 3 4 5 6 7 8 9 |
+ +-------------------------------------------------+
+ Slotframe 1 | | | | | | | | | | |
+ 10 slots long | |A->B| | | | | | |B->A| |
+ (6P) | | | | | | | | | | |
+ +-------------------------------------------------+
+
+ Figure 3: 2-Slotframe Structure when Using 6P alongside the
+ Minimal 6TiSCH Configuration
+
+ The minimal 6TiSCH configuration cell SHOULD be allocated from a
+ slotframe of higher priority than the slotframe used by 6P for
+ dynamic cell allocation. This way, dynamically allocated cells
+ cannot "mask" the cells used by the minimal 6TiSCH configuration.
+ 6top MAY support additional slotframes; how to use additional
+ slotframes is out of scope for this document.
+
+
+
+Wang, et al. Standards Track [Page 6]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3. 6top Protocol (6P)
+
+ 6P enables two neighbor nodes to add/delete/relocate cells in their
+ TSCH schedule. Conceptually, two neighbor nodes "negotiate" the
+ location of the cells to add, delete, or relocate in their TSCH
+ schedule.
+
+3.1. 6P Transactions
+
+ We call "6P Transaction" a complete negotiation between two neighbor
+ nodes. A particular 6P Transaction is executed between two nodes as
+ a result of an action triggered by one SF. For a 6P Transaction to
+ succeed, both nodes must use the same SF to handle the particular
+ transaction. A 6P Transaction starts when a node wishes to
+ add/delete/relocate one or more cells with one of its neighbors. A
+ 6P Transaction ends when (1) the cell(s) has been added/deleted/
+ relocated in the schedule of both nodes or (2) the 6P Transaction has
+ failed.
+
+ 6P messages exchanged between nodes A and B during a 6P Transaction
+ SHOULD be exchanged on non-shared unicast cells ("dedicated" cells)
+ between nodes A and B. If no dedicated cells are scheduled between
+ nodes A and B, shared cells MAY be used.
+
+ Keeping consistency between the schedules of the two neighbor nodes
+ is important. A loss of consistency can cause loss of connectivity.
+ One example is when node A has a transmit cell to node B but node B
+ does not have the corresponding reception cell. To verify
+ consistency, neighbor nodes maintain a sequence number (SeqNum).
+ Neighbor nodes exchange the SeqNum as part of each 6P Transaction to
+ detect a possible inconsistency. This mechanism is explained in
+ Section 3.4.6.2.
+
+ An implementation MUST include a mechanism to associate each
+ scheduled cell with the SF that scheduled it. This mechanism is
+ implementation specific and is out of scope for this document.
+
+ A 6P Transaction can consist of two or three steps. A 2-step
+ transaction is used when node A selects the cells to be allocated. A
+ 3-step transaction is used when node B selects the cells to be
+ allocated. An SF MUST specify whether to use 2-step transactions,
+ 3-step transactions, or both.
+
+ We illustrate 2-step and 3-step transactions using the topology in
+ Figure 1.
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 7]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.1.1. 2-Step 6P Transaction
+
+ Figure 4 shows an example 2-step 6P Transaction. In a 2-step
+ transaction, node A selects the candidate cells. Several elements
+ are left out so that the diagram is easier to understand.
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ | |
+ | 6P ADD Request |
+ | Type = REQUEST |
+ | Code = ADD |
+ | SeqNum = 123 |
+ cells | NumCells = 2 |
+ locked | CellList = [(1,2),(2,2),(3,5)] |
+ +-- |-------------------------------------->|
+ | | L2 ACK |
+ | 6P Timeout |<- - - - - - - - - - - - - - - - - - - |
+ | | | |
+ | | | 6P Response |
+ | | | Type = RESPONSE |
+ | | | Code = RC_SUCCESS |
+ | | | SeqNum = 123 | cells
+ | | | CellList = [(2,2),(3,5)] | locked
+ +-> X |<--------------------------------------| --+
+ | L2 ACK | |
+ | - - - - - - - - - - - - - - - - - - ->| <-+
+ | |
+
+ Figure 4: An Example 2-Step 6P Transaction
+
+ In this example, the 2-step transaction occurs as follows:
+
+ 1. The SF running on node A determines that two extra cells need to
+ be scheduled to node B.
+
+ 2. The SF running on node A selects candidate cells for node B to
+ choose from. Node A MUST select at least as many candidate cells
+ as the number of cells to add. Here, node A selects three
+ candidate cells. Node A locks those candidate cells in its
+ schedule until it receives a 6P Response.
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 8]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ 3. Node A sends a 6P ADD Request to node B, indicating that it
+ wishes to add two cells (the "NumCells" value) and specifying the
+ list of three candidate cells (the "CellList" value). Each cell
+ in the CellList is a [slotOffset,channelOffset] tuple. This 6P
+ ADD Request is link-layer acknowledged by node B (labeled "L2
+ ACK" in Figure 4).
+
+ 4. After having successfully sent the 6P ADD Request (i.e.,
+ receiving the link-layer acknowledgment), node A starts a 6P
+ Timeout to abort the 6P Transaction in the event that no response
+ is received from node B.
+
+ 5. The SF running on node B selects two out of the three cells from
+ the CellList of the 6P ADD Request. Node B locks those cells in
+ its schedule until the transmission is successful (i.e., node B
+ receives a link-layer ACK from node A). Node B sends back a 6P
+ Response to node A, indicating the cells it has selected. The
+ response is link-layer acknowledged by node A.
+
+ 6. Upon completion of this 6P Transaction, two cells from node A to
+ node B have been added to the TSCH schedule of both nodes A
+ and B.
+
+ 7. An inconsistency in the schedule can happen if the 6P Timeout
+ expires when the 6P Response is in the air, if the last
+ link-layer ACK for the 6P Response is lost, or if one of the
+ nodes is power-cycled during the transaction. 6P provides an
+ inconsistency detection mechanism to cope with such situations;
+ see Section 3.4.6.2 for details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 9]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.1.2. 3-Step 6P Transaction
+
+ Figure 5 shows an example 3-step 6P Transaction. In a 3-step
+ transaction, node B selects the candidate cells. Several elements
+ are left out so that the diagram is easier to understand.
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ | |
+ | 6P ADD Request |
+ | Type = REQUEST |
+ | Code = ADD |
+ | SeqNum = 178 |
+ | NumCells = 2 |
+ | CellList = [] |
+ |-------------------------------------->|
+ | L2 ACK |
+ 6P Timeout |<- - - - - - - - - - - - - - - - - - - |
+ | | |
+ | | 6P Response |
+ | | Type = RESPONSE |
+ | | Code = RC_SUCCESS |
+ | | SeqNum = 178 | cells
+ | | CellList = [(1,2),(2,2),(3,5)] | locked
+ X |<--------------------------------------| --+
+ | L2 ACK | |
+ | - - - - - - - - - - - - - - - - - - ->| 6P Timeout |
+ | | | |
+ | 6P Confirmation | | |
+ | Type = CONFIRMATION | | |
+ | Code = RC_SUCCESS | | |
+ cells | SeqNum = 178 | | |
+ locked | CellList = [(2,2),(3,5)] | | |
+ +-- |-------------------------------------->| X <--+
+ | | L2 ACK |
+ +-> |<- - - - - - - - - - - - - - - - - - - |
+ | |
+
+ Figure 5: An Example 3-Step 6P Transaction
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 10]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ In this example, the 3-step transaction occurs as follows:
+
+ 1. The SF running on node A determines that two extra cells need to
+ be scheduled to node B. The SF uses a 3-step transaction, so it
+ does not select candidate cells.
+
+ 2. Node A sends a 6P ADD Request to node B, indicating that it
+ wishes to add two cells (the "NumCells" value), with an empty
+ "CellList". This 6P ADD Request is link-layer acknowledged by
+ node B.
+
+ 3. After having successfully sent the 6P ADD Request, node A starts
+ a 6P Timeout to abort the transaction in the event that no 6P
+ Response is received from node B.
+
+ 4. The SF running on node B selects three candidate cells and locks
+ them. Node B sends back a 6P Response to node A, indicating the
+ three cells it has selected. The response is link-layer
+ acknowledged by node A.
+
+ 5. After having successfully sent the 6P Response, node B starts a
+ 6P Timeout to abort the transaction in the event that no 6P
+ Confirmation is received from node A.
+
+ 6. The SF running on node A selects two cells from the CellList
+ field in the 6P Response and locks them. Node A sends back a 6P
+ Confirmation to node B, indicating the cells it selected. The
+ confirmation is link-layer acknowledged by node B.
+
+ 7. Upon completion of the 6P Transaction, two cells from node A to
+ node B have been added to the TSCH schedule of both nodes A
+ and B.
+
+ 8. An inconsistency in the schedule can happen if the 6P Timeout
+ expires when the 6P Confirmation is in the air, if the last
+ link-layer ACK for the 6P Confirmation is lost, or if one of the
+ nodes is power-cycled during the transaction. 6P provides an
+ inconsistency detection mechanism to cope with such situations;
+ see Section 3.4.6.2 for details.
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 11]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.2. Message Format
+
+3.2.1. 6top Information Element (IE)
+
+ 6P messages travel over a single hop. 6P messages are carried as
+ payload of an 802.15.4 Payload Information Element (IE) [IEEE802154].
+ The messages are encapsulated within the Payload IE header. The
+ Group ID is set to the IETF IE value defined in [RFC8137]. The
+ content is encapsulated by a subtype ID, as defined in [RFC8137].
+
+ Since 6P messages are carried in IEs, IEEE bit/byte ordering applies.
+ Bits within each field in the "6top IE" subtype are numbered from 0
+ (leftmost and least significant) to k-1 (rightmost and most
+ significant), where the length of the field is k bits. Fields that
+ are longer than a single octet are copied to the packet in the order
+ from the octet containing the lowest-numbered bits to the octet
+ containing the highest-numbered bits (little endian).
+
+ This document defines the 6top IE, a subtype of the IETF IE defined
+ in [RFC8137], with subtype SUBID_6TOP. The subtype content of the
+ 6top IE is defined in Section 3.2.2. The length of the 6top IE
+ content is variable.
+
+3.2.2. Generic 6P Message Format
+
+ All 6P messages follow the generic format shown in Figure 6.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Other Fields...
+ +-+-+-+-+-+-+-+-+-
+
+ Figure 6: Generic 6P Message Format
+
+ 6P Version (Version): The version of 6P. Only version 0 is defined
+ in this document. Future specifications may define subsequent
+ versions of 6P.
+
+ Type (T): The type of message. The message types are defined in
+ Section 6.2.2.
+
+ Reserved (R): Reserved bits. These two bits SHOULD be set to zero
+ when sending the message and MUST be ignored upon reception.
+
+
+
+
+
+Wang, et al. Standards Track [Page 12]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Code: The Code field contains a 6P command identifier when the 6P
+ message has a Type value of REQUEST. Section 6.2.3 lists the
+ 6P command identifiers. The Code field contains a 6P return
+ code when the 6P message has a Type value of RESPONSE or
+ CONFIRMATION. Section 6.2.4 lists the 6P return codes. The
+ same return codes are used in both 6P Response and 6P
+ Confirmation messages.
+
+ 6top Scheduling Function Identifier (SFID): The identifier of the SF
+ to use to handle this message. The SFID is defined in
+ Section 4.1.
+
+ SeqNum: The sequence number associated with the 6P Transaction.
+ Used to match the 6P Request, 6P Response, and 6P Confirmation
+ of the same 6P Transaction. The value of SeqNum MUST be
+ different for each new 6P Request issued to the same neighbor
+ and using the same SF. The SeqNum is also used to ensure
+ consistency between the schedules of the two neighbors.
+ Section 3.4.6 details how the SeqNum is managed.
+
+ Other Fields: The list of other fields and how they are used are
+ detailed in Section 3.3.
+
+ 6P Request, 6P Response, and 6P Confirmation messages for a given
+ transaction MUST share the same Version, SFID, and SeqNum values.
+
+ Future versions of the 6P message SHOULD maintain the format of the
+ 6P Version, Type, and Code fields for backward compatibility.
+
+3.2.3. 6P CellOptions
+
+ An 8-bit 6P CellOptions bitmap is present in the following 6P
+ Requests: ADD, DELETE, COUNT, LIST, and RELOCATE. The format and
+ meaning of this field MAY be redefined by the SF; the routine that
+ parses this field is therefore associated with a specific SF.
+
+ o In the 6P ADD Request, the 6P CellOptions bitmap is used to
+ specify what type of cell to add.
+
+ o In the 6P DELETE Request, the 6P CellOptions bitmap is used to
+ specify what type of cell to delete.
+
+ o In the 6P RELOCATE Request, the 6P CellOptions bitmap is used to
+ specify what type of cell to relocate.
+
+ o In the 6P COUNT and LIST Requests, the 6P CellOptions bitmap is
+ used as a selector of a particular type of cells.
+
+
+
+
+Wang, et al. Standards Track [Page 13]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ The content of the 6P CellOptions bitmap applies to all elements in
+ the CellList field. The possible values of the 6P CellOptions are as
+ follows:
+
+ o TX = 1 (resp. 0) refers to macTxType = TRUE (resp. FALSE) in the
+ macLinkTable of 802.15.4 [IEEE802154].
+
+ o RX = 1 (resp. 0) refers to macRxType = TRUE (resp. FALSE) in the
+ macLinkTable of 802.15.4.
+
+ o S = 1 (resp. 0) refers to macSharedType = TRUE (resp. FALSE) in
+ the macLinkTable of 802.15.4.
+
+ Section 6.2.6 provides the format of the 6P CellOptions bitmap; this
+ format applies unless redefined by the SF. Figure 7 shows the
+ meaning of the 6P CellOptions bitmap for the 6P ADD, DELETE, and
+ RELOCATE Requests (unless redefined by the SF). Figure 8 shows the
+ meaning of the 6P CellOptions bitmap for the 6P COUNT and LIST
+ Requests (unless redefined by the SF).
+
+ Note: Here, we assume that node A issues the 6P command to node B.
+ +-------------+-----------------------------------------------------+
+ | CellOptions | The type of cells B adds/deletes/relocates to its |
+ | Value | schedule when receiving a 6P ADD/DELETE/RELOCATE |
+ | | Request from A |
+ +-------------+-----------------------------------------------------+
+ |TX=0,RX=0,S=0| Invalid combination. RC_ERR is returned |
+ +-------------+-----------------------------------------------------+
+ |TX=1,RX=0,S=0| Add/delete/relocate RX cells at B (TX cells at A) |
+ +-------------+-----------------------------------------------------+
+ |TX=0,RX=1,S=0| Add/delete/relocate TX cells at B (RX cells at A) |
+ +-------------+-----------------------------------------------------+
+ |TX=1,RX=1,S=0| Add/delete/relocate TX|RX cells at B (and at A) |
+ +-------------+-----------------------------------------------------+
+ |TX=0,RX=0,S=1| Invalid combination. RC_ERR is returned |
+ +-------------+-----------------------------------------------------+
+ |TX=1,RX=0,S=1| Add/delete/relocate RX|SHARED cells at B |
+ | | (TX|SHARED cells at A) |
+ +-------------+-----------------------------------------------------+
+ |TX=0,RX=1,S=1| Add/delete/relocate TX|SHARED cells at B |
+ | | (RX|SHARED cells at A) |
+ +-------------+-----------------------------------------------------+
+ |TX=1,RX=1,S=1| Add/delete/relocate TX|RX|SHARED cells at B |
+ | | (and at A) |
+ +-------------+-----------------------------------------------------+
+
+ Figure 7: Meaning of the 6P CellOptions Bitmap for the
+ 6P ADD, DELETE, and RELOCATE Requests
+
+
+
+Wang, et al. Standards Track [Page 14]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Note: Here, we assume that node A issues the 6P command to node B.
+ +-------------+-----------------------------------------------------+
+ | CellOptions | The type of cells B selects from its schedule when |
+ | Value | receiving a 6P COUNT or LIST Request from A, |
+ | | from all the cells B has scheduled with A |
+ +-------------+-----------------------------------------------------+
+ |TX=0,RX=0,S=0| All cells |
+ +-------------+-----------------------------------------------------+
+ |TX=1,RX=0,S=0| All cells marked as RX only |
+ +-------------+-----------------------------------------------------+
+ |TX=0,RX=1,S=0| All cells marked as TX only |
+ +-------------+-----------------------------------------------------+
+ |TX=1,RX=1,S=0| All cells marked as TX and RX only |
+ +-------------+-----------------------------------------------------+
+ |TX=0,RX=0,S=1| All cells marked as SHARED (regardless of TX, RX) |
+ +-------------+-----------------------------------------------------+
+ |TX=1,RX=0,S=1| All cells marked as RX and SHARED only |
+ +-------------+-----------------------------------------------------+
+ |TX=0,RX=1,S=1| All cells marked as TX and SHARED only |
+ +-------------+-----------------------------------------------------+
+ |TX=1,RX=1,S=1| All cells marked as TX, RX, and SHARED |
+ +-------------+-----------------------------------------------------+
+
+ Figure 8: Meaning of the 6P CellOptions Bitmap for the
+ 6P COUNT and LIST Requests
+
+ The CellOptions constitute an opaque set of bits, sent unmodified to
+ the SF. The SF MAY redefine the format and meaning of the
+ CellOptions field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 15]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.2.4. 6P CellList
+
+ A CellList field MAY be present in a 6P ADD Request, a 6P DELETE
+ Request, a 6P RELOCATE Request, a 6P Response, or a 6P Confirmation.
+ It is composed of a concatenation of zero or more 6P Cells as defined
+ in Figure 9. The content of the CellOptions field specifies the
+ options associated with all cells in the CellList. This necessarily
+ means that the same options are associated with all cells in the
+ CellList.
+
+ A 6P Cell is a 4-byte field; its default format is:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 9: 6P Cell Format
+
+ slotOffset: The slot offset of the cell.
+
+ channelOffset: The channel offset of the cell.
+
+ The CellList is an opaque set of bytes, sent unmodified to the SF.
+ The length of the CellList field is implicit and is determined by the
+ IE Length field of the Payload IE header as defined in 802.15.4. The
+ SF MAY redefine the format of the CellList field; the routine that
+ parses this field is therefore associated with a specific SF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 16]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.3. 6P Commands and Operations
+
+3.3.1. Adding Cells
+
+ Cells are added by using the 6P ADD command. The Type field (T) is
+ set to REQUEST. The Code field is set to ADD. Figure 10 defines the
+ format of a 6P ADD Request.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Metadata | CellOptions | NumCells |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CellList ...
+ +-+-+-+-+-+-+-+-+-
+
+ Figure 10: 6P ADD Request Format
+
+ Metadata: Used as extra signaling to the SF. The contents of the
+ Metadata field are an opaque set of bytes passed unmodified to
+ the SF. The meaning of this field depends on the SF and is out
+ of scope for this document. For example, Metadata can specify
+ in which slotframe to add the cells.
+
+ CellOptions: Indicates the options to associate with the cells to be
+ added. If more than one cell is added (NumCells > 1), the same
+ options are associated with each one. This necessarily means
+ that if node A needs to add multiple cells with different
+ options it needs to initiate multiple 6P ADD Transactions.
+
+ NumCells: The number of additional cells node A wants to schedule to
+ node B.
+
+ CellList: A list of zero or multiple candidate cells. Its length is
+ implicit and is determined by the Length field of the Payload
+ IE header.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 17]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Figure 11 defines the format of a 6P ADD Response and Confirmation.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CellList ...
+ +-+-+-+-+-+-+-+-+-
+
+ Figure 11: 6P ADD Response and Confirmation Format
+
+ CellList: A list of zero or more 6P Cells.
+
+ Consider the topology in Figure 1; in this case, the SF on node A
+ decides to add NumCells cells to node B.
+
+ Node A's SF selects NumCandidate cells from its schedule. These are
+ cells that are candidates to be scheduled with node B. The
+ CellOptions field specifies the type of these cells. NumCandidate
+ MUST be greater than or equal to NumCells. How many cells node A
+ selects (NumCandidate) and how that selection is done are specified
+ in the SF and are out of scope for this document. Node A sends a 6P
+ ADD Request to node B that contains the CellOptions, the value of
+ NumCells, and a selection of NumCandidate cells in the CellList. If
+ the NumCandidate cells do not fit in a single packet, this operation
+ MUST be split into multiple independent 6P ADD Requests, each for a
+ subset of the number of cells that eventually need to be added. In
+ the case of a 3-step transaction, the SF is responsible for ensuring
+ that the returned Candidate CellList fits into the 6P Response.
+
+ Upon receiving the request, node B checks to see whether the
+ CellOptions are set to a valid value as noted by Figure 7. If this
+ is not the case, a Response with code RC_ERR is returned. If the
+ number of cells in the received CellList in node B is smaller than
+ NumCells, node B MUST return a 6P Response with the RC_ERR_CELLLIST
+ code. Otherwise, node B's SF verifies which of the cells in the
+ CellList it can install in node B's schedule, following the specified
+ CellOptions field. How that selection is done is specified in the SF
+ and is out of scope for this document. The verification can succeed
+ (NumCells cells from the CellList can be used), fail (none of the
+ cells from the CellList can be used), or partially succeed (fewer
+ than NumCells cells from the CellList can be used). In all cases,
+ node B MUST send a 6P Response that includes a return code set to
+ RC_SUCCESS and that specifies the list of cells that were scheduled
+ following the CellOptions field. That list can contain NumCells
+ elements (succeed), 0 elements (fail), or between 0 and NumCells
+ elements (partially succeed).
+
+
+
+Wang, et al. Standards Track [Page 18]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Upon receiving the response, node A adds the cells specified in the
+ CellList according to the CellOptions field.
+
+3.3.2. Deleting Cells
+
+ Cells are deleted by using the 6P DELETE command. The Type field (T)
+ is set to REQUEST. The Code field is set to DELETE. Figure 12
+ defines the format of a 6P DELETE Request.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Metadata | CellOptions | NumCells |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CellList ...
+ +-+-+-+-+-+-+-+-+-
+
+ Figure 12: 6P DELETE Request Format
+
+ Metadata: Same usage as for the 6P ADD command; see Section 3.3.1.
+ Its format is the same as that in the 6P ADD command, but its
+ content could be different.
+
+ CellOptions: Indicates the options that need to be associated with
+ the cells to delete. Only cells matching the CellOptions can
+ be deleted.
+
+ NumCells: The number of cells from the specified CellList the sender
+ wants to delete from the schedule of both sender and receiver.
+
+ CellList: A list of zero or more 6P Cells. Its length is determined
+ by the Length field of the Payload IE header.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 19]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Figure 13 defines the format of a 6P DELETE Response and
+ Confirmation.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CellList ...
+ +-+-+-+-+-+-+-+-+-
+
+ Figure 13: 6P DELETE Response and Confirmation Format
+
+ CellList: A list of zero or more 6P 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 already be scheduled between the
+ two nodes and MUST match the CellOptions field. If node A puts
+ cells in its CellList that are not already scheduled between the
+ two nodes and match the CellOptions field, node B MUST reply with
+ a RC_ERR_CELLLIST return code.
+
+ o The CellList in a 6P Request (2-step transaction) or 6P Response
+ (3-step transaction) MUST be empty, contain exactly NumCells
+ cells, or contain more than NumCells cells. The case where the
+ CellList is not empty but contains fewer than NumCells cells is
+ not supported; the RC_ERR_CELLLIST code MUST be returned when the
+ CellList contains fewer than NumCells cells. If the CellList is
+ empty, the SF on the receiving node MUST choose NumCells cells
+ scheduled to the sender matching the CellOptions field and delete
+ them. If the CellList contains more than NumCells cells, the SF
+ on the receiving node chooses exactly NumCells cells from the
+ CellList to delete.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 20]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.3.3. Relocating Cells
+
+ Cell relocation consists of moving a cell to a different
+ [slotOffset,channelOffset] location in the schedule. The Type field
+ (T) is set to REQUEST. The Code field is set to RELOCATE. Figure 14
+ defines the format of a 6P RELOCATE Request.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Metadata | CellOptions | NumCells |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Relocation CellList ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Candidate CellList ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Figure 14: 6P RELOCATE Request Format
+
+ Metadata: Same usage as for the 6P ADD command; see Section 3.3.1.
+
+ CellOptions: Indicates the options that need to be associated with
+ cells to be relocated.
+
+ NumCells: The number of cells to relocate. MUST be greater than or
+ equal to 1.
+
+ Relocation CellList: The list of NumCells 6P Cells to relocate.
+
+ Candidate CellList: A list of NumCandidate candidate cells for
+ node B to pick from. NumCandidate MUST be 0, equal to
+ NumCells, or greater than NumCells. Its length is determined
+ by the Length field of the Payload IE header.
+
+ In a 2-step 6P RELOCATE Transaction, node A specifies both (1) the
+ cells it needs to relocate and (2) the list of candidate cells to
+ relocate to. The Relocation CellList MUST contain exactly NumCells
+ entries. The Candidate CellList MUST contain at least NumCells
+ entries (NumCandidate >= NumCells).
+
+ In a 3-step 6P RELOCATE Transaction, node A specifies only the cells
+ it needs to relocate -- not the list of candidate cells to relocate
+ to. The Candidate CellList MUST therefore be empty.
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 21]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Figure 15 defines the format of a 6P RELOCATE Response and
+ Confirmation.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CellList ...
+ +-+-+-+-+-+-+-+-+-
+
+ Figure 15: 6P RELOCATE Response and Confirmation Format
+
+ CellList: A list of zero or more 6P Cells.
+
+ Node A's SF wants to relocate NumCells cells. Node A creates a 6P
+ RELOCATE Request and indicates the cells it wants to relocate in the
+ Relocation CellList. It also selects NumCandidate cells from its
+ schedule as candidate cells to relocate the cells to, and it puts
+ them in the Candidate CellList. The CellOptions field specifies the
+ type of the cell(s) to relocate. NumCandidate MUST be greater than
+ or equal to NumCells. How many cells it selects (NumCandidate) and
+ how that selection is done are specified in the SF and are out of
+ scope for this document. Node A sends the 6P RELOCATE Request to
+ node B.
+
+ Upon receiving the request, node B checks to see if the length of the
+ Candidate CellList is greater than or equal to NumCells. Node B's SF
+ verifies that all the cells in the Relocation CellList are scheduled
+ with node A and are associated with the options specified in the
+ CellOptions field. If either check fails, node B MUST send a 6P
+ Response to node A with return code RC_ERR_CELLLIST. If both checks
+ pass, node B's SF verifies which of the cells in the Candidate
+ CellList it can install in its schedule. How that selection is done
+ is specified in the SF and is out of scope for this document. That
+ verification for the Candidate CellList can succeed (NumCells cells
+ from the Candidate CellList can be used), fail (none of the cells
+ from the Candidate CellList can be used), or partially succeed (fewer
+ than NumCells cells from the Candidate CellList can be used). In all
+ cases, node B MUST send a 6P Response that includes a return code set
+ to RC_SUCCESS and that specifies the list of cells that will be
+ rescheduled following the CellOptions field. That list can contain
+ NumCells elements (succeed), 0 elements (fail), or between 0 and
+ NumCells elements (partially succeed). If N < NumCells cells appear
+ in the CellList, this means that the first N cells in the Relocation
+ CellList have been relocated and the remainder have not.
+
+
+
+
+
+Wang, et al. Standards Track [Page 22]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Upon receiving the response with code RC_SUCCESS, node A relocates
+ the cells specified in the Relocation CellList of its RELOCATE
+ Request to the new locations specified in the CellList of the 6P
+ Response, in the same order. If the received return code is
+ RC_ERR_CELLLIST, the transaction is aborted and no cell is relocated.
+ In the case of a 2-step transaction, node B relocates the selected
+ cells upon receiving the link-layer ACK for the 6P Response. In the
+ case of a 3-step transaction, node B relocates the selected cells
+ upon receiving the 6P Confirmation.
+
+ The SF SHOULD NOT relocate all cells between two nodes at the same
+ time, as this might result in the schedules of both nodes diverging
+ significantly.
+
+ Figure 16 shows an example of a successful 2-step 6P RELOCATE
+ Transaction.
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ | |
+ | 6P RELOCATE Request |
+ | Type = REQUEST |
+ | Code = RELOCATE |
+ | SeqNum = 11 |
+ | NumCells = 2 |
+ | R.CellList = [(1,2),(2,2)] |
+ | C.CellList = [(3,3),(4,3),(5,3)] |
+ |-------------------------------------->| B prepares
+ | L2 ACK | to relocate
+ |<- - - - - - - - - - - - - - - - - - - | (1,2)->(5,3)
+ | | and
+ | | (2,2)->(3,3)
+ | 6P Response |
+ | Code = RC_SUCCESS |
+ | SeqNum = 11 |
+ | CellList = [(5,3),(3,3)] |
+ A relocates |<--------------------------------------|
+ (1,2)->(5,3) | L2 ACK |
+ and | - - - - - - - - - - - - - - - - - - ->| B relocates
+ (2,2)->(3,3) | | (1,2)->(5,3)
+ | | and
+ | | (2,2)->(3,3)
+
+ Figure 16: Example of a Successful 2-Step 6P RELOCATE Transaction
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 23]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Figure 17 shows an example of a partially successful 2-step 6P
+ RELOCATE Transaction.
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ | |
+ | 6P RELOCATE Request |
+ | Type = REQUEST |
+ | Code = RELOCATE |
+ | SeqNum = 199 |
+ | NumCells = 2 |
+ | R.CellList = [(1,2),(2,2)] |
+ | C.CellList = [(3,3),(4,3),(5,3)] | B prepares
+ |-------------------------------------->| to relocate
+ | L2 ACK | (1,2)->(4,3)
+ |<- - - - - - - - - - - - - - - - - - - | but cannot
+ | | relocate (2,2)
+ | 6P Response |
+ | Type = RESPONSE |
+ | Code = RC_SUCCESS |
+ | SeqNum = 199 |
+ | CellList = [(4,3)] |
+ A relocates |<--------------------------------------|
+ (1,2)->(4,3) | L2 ACK |
+ | - - - - - - - - - - - - - - - - - - ->| B relocates
+ | | (1,2)->(4,3)
+ | |
+ | |
+
+ Figure 17: Example of a Partially Successful 2-Step 6P
+ RELOCATE Transaction
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 24]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Figure 18 shows an example of a failed 2-step 6P RELOCATE
+ Transaction.
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ | |
+ | 6P RELOCATE Request |
+ | Type = REQUEST |
+ | Code = RELOCATE |
+ | SeqNum = 53 |
+ | NumCells = 2 |
+ | R.CellList = [(1,2),(2,2)] |
+ | C.CellList = [(3,3),(4,3),(5,3)] |
+ |-------------------------------------->| B cannot
+ | L2 ACK | relocate
+ |<- - - - - - - - - - - - - - - - - - - | (1,2)
+ | | or (2,2)
+ | 6P Response |
+ | Type = RESPONSE |
+ | Code = RC_SUCCESS |
+ | SeqNum = 53 |
+ | CellList = [] |
+ |<--------------------------------------| B does not
+ | L2 ACK | relocate
+ A does not | - - - - - - - - - - - - - - - - - - ->|
+ relocate | |
+ | |
+
+ Figure 18: Failed 2-Step 6P RELOCATE Transaction Example
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 25]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Figure 19 shows an example of a successful 3-step 6P RELOCATE
+ Transaction.
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ | |
+ | 6P RELOCATE Request |
+ | Type = REQUEST |
+ | Code = RELOCATE |
+ | SeqNum = 11 |
+ | NumCells = 2 |
+ | R.CellList = [(1,2),(2,2)] |
+ | C.CellList = [] |
+ |-------------------------------------->|
+ | L2 ACK |
+ |<- - - - - - - - - - - - - - - - - - - | B identifies
+ | | candidate
+ | | cells
+ | 6P Response | (3,3),
+ | Code = RC_SUCCESS | (4,3), and
+ | SeqNum = 11 | (5,3)
+ | CellList = [(3,3),(4,3),(5,3)] |
+ A prepares |<--------------------------------------|
+ to relocate | L2 ACK |
+ (1,2)->(5,3) | - - - - - - - - - - - - - - - - - - ->|
+ and | |
+ (2,2)->(3,3) | 6P Confirmation |
+ | Code = RC_SUCCESS |
+ | SeqNum = 11 |
+ | CellList = [(5,3),(3,3)] |
+ |-------------------------------------->| B relocates
+ | L2 ACK | (1,2)->(5,3)
+ A relocates |<- - - - - - - - - - - - - - - - - - - | and
+ (1,2)->(5,3) | | (2,2)->(3,3)
+ and | |
+ (2,2)->(3,3) | |
+ | |
+
+ Figure 19: Example of a Successful 3-Step 6P RELOCATE Transaction
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 26]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.3.4. Counting Cells
+
+ To retrieve the number of scheduled cells node A has with B, node A
+ issues a 6P COUNT command. The Type field (T) is set to REQUEST.
+ The Code field is set to COUNT. Figure 20 defines the format of a 6P
+ COUNT Request.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Metadata | CellOptions |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 20: 6P COUNT Request Format
+
+ Metadata: Same usage as for the 6P ADD command; see Section 3.3.1.
+ Its format is the same as that in the 6P ADD command, but its
+ content could be different.
+
+ CellOptions: Specifies which type of cell to be counted.
+
+ Figure 21 defines the format of a 6P COUNT Response.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NumCells |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 21: 6P COUNT Response Format
+
+ NumCells: The number of cells that correspond to the fields of the
+ request.
+
+ Node A issues a COUNT command to node B, specifying some cell
+ options. Upon receiving the 6P COUNT Request, node B goes through
+ its schedule and counts the number of cells scheduled with node A in
+ its own schedule that match the cell options in the CellOptions field
+ of the request. Section 3.2.3 details the use of the CellOptions
+ field.
+
+ Node B issues a 6P Response to node A with return code RC_SUCCESS and
+ with NumCells containing the number of cells that match the request.
+
+
+
+
+Wang, et al. Standards Track [Page 27]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.3.5. Listing Cells
+
+ To retrieve a list of scheduled cells node A has with node B, node A
+ issues a 6P LIST command. The Type field (T) is set to REQUEST. The
+ Code field is set to LIST. Figure 22 defines the format of a 6P LIST
+ Request.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Metadata | CellOptions | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Offset | MaxNumCells |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 22: 6P LIST Request Format
+
+ Metadata: Same usage as for the 6P ADD command; see Section 3.3.1.
+ Its format is the same as that in the 6P ADD command, but its
+ content could be different.
+
+ CellOptions: Specifies which type of cell to be listed.
+
+ Reserved: Reserved bits. These bits SHOULD be set to zero when
+ sending the message and MUST be ignored upon reception.
+
+ Offset: The offset of the first scheduled cell that is requested.
+ The mechanism assumes that cells are ordered according to a
+ rule defined in the SF. The rule MUST always order the cells
+ in the same way.
+
+ MaxNumCells: The maximum number of cells to be listed. Node B MAY
+ return fewer than MaxNumCells cells -- for example, if
+ MaxNumCells cells do not fit in the frame.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 28]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Figure 23 defines the format of a 6P LIST Response.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CellList ...
+ +-+-+-+-+-+-+-+-+-
+
+ Figure 23: 6P LIST Response Format
+
+ CellList: A list of zero or more 6P Cells.
+
+ When receiving a LIST command, node B returns the cells scheduled
+ with A in its schedule that match the CellOptions field as specified
+ in Section 3.2.3.
+
+ When node B receives a LIST Request, the returned CellList in the 6P
+ Response contains between 0 and MaxNumCells cells, starting from the
+ specified offset. Node B SHOULD include as many cells as will fit in
+ the frame. If the response contains the last cell, node B MUST set
+ the Code field in the response to RC_EOL ("End of List", as per
+ Figure 38 in Section 6.2.4), indicating to node A that there are no
+ more cells that match the request. Node B MUST return at least one
+ cell, unless the specified offset is beyond the end of B's cell list
+ in its schedule. If node B has fewer than Offset cells that match
+ the request, node B returns an empty CellList and a Code field set
+ to RC_EOL.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 29]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.3.6. Clearing the Schedule
+
+ To clear the schedule between nodes A and B (for example, after a
+ schedule inconsistency is detected), node A issues a CLEAR command.
+ The Type field (T) is set to REQUEST. The Code field is set to
+ CLEAR. Figure 24 defines the format of a 6P CLEAR Request.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Metadata |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 24: 6P CLEAR Request Format
+
+ Metadata: Same usage as for the 6P ADD command; see Section 3.3.1.
+ Its format is the same as that in the 6P ADD command, but its
+ content could be different.
+
+ Figure 25 defines the format of a 6P CLEAR Response.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 25: 6P CLEAR Response Format
+
+ When a 6P CLEAR command is issued from node A to node B, both nodes A
+ and B MUST remove all the cells scheduled between them. That is,
+ node A MUST remove all the cells scheduled with node B, and node B
+ MUST remove all the cells scheduled with node A. In a 6P CLEAR
+ command, the SeqNum MUST NOT be checked. In particular, even if the
+ request contains a SeqNum value that would normally cause node B to
+ detect a schedule inconsistency, the transaction MUST NOT be aborted.
+ Upon 6P CLEAR completion, the value of SeqNum MUST be reset to 0.
+
+ The return code sent in response to a 6P CLEAR command SHOULD be
+ RC_SUCCESS unless the operation cannot be executed. When the CLEAR
+ operation cannot be executed, the return code MUST be set to
+ RC_RESET.
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 30]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.3.7. Generic Signaling between SFs
+
+ The 6P SIGNAL message allows the SF implementations on two neighbor
+ nodes to exchange generic commands. The payload in a received SIGNAL
+ message is an opaque set of bytes passed unmodified to the SF. The
+ length of the payload is determined by the Length field of the
+ Payload IE header. How the generic SIGNAL command is used is
+ specified by the SF and is outside the scope of this document. The
+ Type field (T) is set to REQUEST. The Code field is set to SIGNAL.
+ Figure 26 defines the format of a 6P SIGNAL Request.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Metadata | payload ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 26: 6P SIGNAL Request Format
+
+ Metadata: Same usage as for the 6P ADD command; see Section 3.3.1.
+ Its format is the same as that in the 6P ADD command, but its
+ content could be different.
+
+ Figure 27 defines the format of a 6P SIGNAL Response.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| T | R | Code | SFID | SeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | payload ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 27: 6P SIGNAL Response Format
+
+3.4. Protocol Functional Details
+
+3.4.1. Version Checking
+
+ All messages contain a Version field. If multiple protocol versions
+ of 6P have been defined (in future specifications for Version values
+ different from 0), a node MAY implement multiple protocol versions at
+ the same time. When a node receives a 6P message with a version
+ number it does not implement, the node MUST reply with a 6P Response
+ with a return code field set to RC_ERR_VERSION. The format of this
+ 6P Response message MUST be compliant with version 0 and MUST be
+
+
+
+Wang, et al. Standards Track [Page 31]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ supported by all future versions of the protocol. This ensures that
+ when node B sends a 6P Response to node A indicating that it does not
+ implement the 6P version in the 6P Request, node A can successfully
+ parse that response.
+
+ When a node supports a version number received in a 6P Request
+ message, the Version field in the 6P Response MUST be the same as the
+ Version field in the corresponding 6P Request. Similarly, in a
+ 3-step transaction, the Version field in the 6P Confirmation MUST
+ match that of the 6P Request and 6P Response of the same transaction.
+
+3.4.2. SFID Checking
+
+ All messages contain an SFID field. 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 with a return code of
+ RC_ERR_SFID. The SFID field in the 6P Response MUST be the same as
+ the SFID field in the corresponding 6P Request. In a 3-step
+ transaction, the SFID field in the 6P Confirmation MUST match that of
+ the 6P Request and the 6P Response of the same transaction.
+
+3.4.3. Concurrent 6P Transactions
+
+ Only a single 6P Transaction at a time in a given direction can take
+ place between two neighbors. That is, a node MUST NOT issue a new 6P
+ Request to a given neighbor before the previous 6P Transaction it
+ initiated has finished (or possibly 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 RC_RESET (as per Figure 38 in
+ Section 6.2.4) and discard this ongoing second transaction. A node
+ receiving a RC_RESET code MUST abort the second transaction and treat
+ it as though it never happened (i.e., reverting changes to the
+ schedule or SeqNum done by this transaction).
+
+ Nodes A and B MAY support having two transactions going on at the
+ same time, one in each direction. Similarly, a node MAY support
+ concurrent 6P Transactions with different neighbors. In this case,
+ the cells involved in an ongoing 6P Transaction MUST be "locked"
+ until the transaction finishes. For example, in Figure 1, node C can
+ have a different ongoing 6P Transaction with nodes B and R. If a
+ node does not have enough resources to handle concurrent 6P
+ Transactions from different neighbors, it MUST reply with a 6P
+ Response with return code RC_ERR_BUSY (as per Figure 38 in
+ Section 6.2.4). If the requested cells are locked, it MUST reply to
+ that request with a 6P Response with return code RC_ERR_LOCKED (as
+ per Figure 38). The node receiving RC_ERR_BUSY or RC_ERR_LOCKED MAY
+ implement a retry mechanism as defined by the SF.
+
+
+
+Wang, et al. Standards Track [Page 32]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+3.4.4. 6P Timeout
+
+ A timeout occurs when the node that successfully sent a 6P Request
+ does not receive the corresponding 6P Response within an amount of
+ time specified by the SF. In a 3-step transaction, a timeout also
+ occurs when a node sending the 6P Response does not receive a 6P
+ Confirmation. When a timeout occurs, the transaction MUST be
+ canceled at the node where the timeout occurs. The value of the 6P
+ Timeout should be greater than the longest possible time it takes to
+ receive the 6P Response or Confirmation. The value of the 6P Timeout
+ hence depends on the number of cells scheduled between the neighbor
+ nodes, the maximum number of link-layer retransmissions, etc. The SF
+ MUST determine the value of the timeout. The value of the timeout is
+ out of scope for this document.
+
+3.4.5. Aborting a 6P Transaction
+
+ If the receiver of a 6P 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 RC_RESET. Upon receiving this 6P Response,
+ the initiator of the 6P Transaction MUST consider the 6P Transaction
+ as having failed.
+
+ Similarly, in the case of a 3-step transaction, when the receiver of
+ a 6P Response fails during the 6P Transaction and is unable to
+ complete it, it MUST reply to that 6P Response with a 6P Confirmation
+ with return code RC_RESET. Upon receiving this 6P Confirmation, the
+ sender of the 6P Response MUST consider the 6P Transaction as having
+ failed.
+
+3.4.6. SeqNum Management
+
+ The SeqNum is the field in the 6top IE header used to match Request,
+ Response, and Confirmation messages for a given transaction. The
+ SeqNum is used to detect and handle duplicate commands
+ (Section 3.4.6.1) and inconsistent schedules (Section 3.4.6.2). Each
+ node remembers the last used SeqNum for each neighbor. That is, a
+ node stores as many SeqNum values as it has neighbors. In the case
+ of supporting multiple SFs at a time, a SeqNum value is maintained
+ per SF and per neighbor. In the remainder of this section, we
+ describe the use of SeqNum between two neighbors; the same happens
+ for each other neighbor, independently.
+
+ When a node resets, or after a CLEAR Transaction, it MUST reset
+ SeqNum to 0. The 6P Response and 6P Confirmation for a transaction
+ MUST use the same SeqNum value as that in the request. After every
+ transaction, the SeqNum MUST be incremented by exactly 1.
+
+
+
+
+Wang, et al. Standards Track [Page 33]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Specifically, if node A receives the link-layer acknowledgment for
+ its 6P Request, it will increment the SeqNum by exactly 1 after the
+ 6P Transaction ends. This ensures that, for the next 6P Transaction
+ where it sends a 6P Request, the 6P Request will have a different
+ SeqNum.
+
+ Similarly, node B increments the SeqNum by exactly 1 after having
+ received the link-layer acknowledgment for the 6P Response (2-step 6P
+ Transaction) or after having sent the link-layer acknowledgment for
+ the 6P Confirmation (3-step 6P Transaction).
+
+ When node B receives a 6P Request from node A with SeqNum equal to 0,
+ it checks the stored SeqNum for A. If A is a new neighbor, the
+ stored SeqNum in B will be 0. The transaction can continue. If the
+ stored SeqNum for A in B is different than 0, a potential
+ inconsistency is detected. In this case, B MUST return RC_ERR_SEQNUM
+ with SeqNum=0. The SF of node A MAY decide what to do next, as
+ described in Section 3.4.6.2.
+
+ The SeqNum MUST be implemented as a lollipop counter: it rolls over
+ from 0xFF to 0x01 (not to 0x00). This is used to detect a neighbor
+ reset. Figure 28 lists the possible values of the SeqNum.
+
+ +-----------+------------------------------+
+ | Value | Meaning |
+ +-----------+------------------------------+
+ | 0x00 | Clear, or after device reset |
+ | 0x01-0xFF | Lollipop counter values |
+ +-----------+------------------------------+
+
+ Figure 28: Possible Values of the SeqNum
+
+3.4.6.1. Detecting and Handling Duplicate 6P Messages
+
+ All 6P commands are link-layer acknowledged. A duplicate message
+ means that a node receives a second 6P Request, Response, or
+ Confirmation. This happens when the link-layer acknowledgment is not
+ received and a link-layer retransmission happens. Duplicate messages
+ are normal and unavoidable.
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 34]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Figure 29 shows an example 2-step transaction in which node A
+ receives a duplicate 6P Response.
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ | |
+ | 6P Request (SeqNum=456) |
+ |-------------------------------------->|
+ | L2 ACK |
+ |<- - - - - - - - - - - - - - - - - - - |
+ | |
+ | 6P Response (SeqNum=456) |
+ |<--------------------------------------|
+ | L2 ACK |
+ | - - - - - - - - - - -X | no ACK:
+ | | link-layer
+ | 6P Response (SeqNum=456) | retransmit
+ duplicate |<--------------------------------------|
+ 6P Response | L2 ACK |
+ received | - - - - - - - - - - - - - - - - - - ->|
+ | |
+
+ Figure 29: Example Duplicate 6P Message
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 35]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Figure 30 shows an example 3-step transaction in which node A
+ receives an out-of-order duplicate 6P Response after having sent a 6P
+ Confirmation.
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ | |
+ | 6P Request (SeqNum=123) |
+ |-------------------------------------->|
+ | L2 ACK |
+ |<- - - - - - - - - - - - - - - - - - - |
+ | |
+ | 6P Response (SeqNum=123) |
+ |<--------------------------------------|
+ | L2 ACK |
+ | - - - - - - - - - - -X | no ACK:
+ | | link-layer
+ | 6P Confirmation (SeqNum=123) | retransmit
+ |-------------------------------------->| |
+ | L2 ACK | |
+ |<- - - - - - - - - - - - - - - - - - - | frame
+ | | queued
+ | 6P Response (SeqNum=123) | |
+ duplicate |<--------------------------------------| <--+
+ out-of-order | L2 ACK |
+ 6P Response | - - - - - - - - - - - - - - - - - - ->|
+ received | |
+
+ Figure 30: Example Out-of-Order Duplicate 6P Message
+
+ A node detects a duplicate 6P message when it has the same SeqNum and
+ type as the last frame received from the same neighbor. When
+ receiving a duplicate 6P message, a node MUST send a link-layer
+ acknowledgment but MUST silently ignore the 6P message at 6top.
+
+3.4.6.2. Detecting and Handling a Schedule Inconsistency
+
+ A schedule inconsistency happens when the schedules of nodes A and B
+ are inconsistent -- for example, when node A has a transmit cell to
+ node B, but node B does not have the corresponding receive cell and
+ therefore isn't listening to node A on that cell. A schedule
+ inconsistency results in loss of connectivity.
+
+ The SeqNum field, which is present in each 6P message, is used to
+ detect an inconsistency. The SeqNum field increments by 1 in each
+ message, as detailed in Section 3.4.6. A node computes the expected
+
+
+
+
+Wang, et al. Standards Track [Page 36]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ SeqNum field for the next 6P Transaction. If a node receives a 6P
+ Request with a SeqNum value that is not the expected value, it has
+ detected an inconsistency.
+
+ There are two cases in which a schedule inconsistency happens.
+
+ The first case is when a node loses state -- for example, when it is
+ power-cycled (turned off, then on). In that case, its SeqNum value
+ is reset to 0. Since the SeqNum is a lollipop counter, its neighbor
+ detects an inconsistency in the next 6P Transaction. This is
+ illustrated in Figures 31 and 32.
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ SeqNum=87 | | SeqNum=87
+ | |
+ | 6P Request (SeqNum=87) |
+ |-------------------------------------->|
+ | L2 ACK |
+ |<- - - - - - - - - - - - - - - - - - - |
+ | |
+ | 6P Response (SeqNum=87) |
+ |<--------------------------------------|
+ | L2 ACK |
+ | - - - - - - - - - - - - - - - - - - ->|
+ | ==== power-cycle
+ | |
+ SeqNum=88 | | SeqNum=0
+ | |
+ | 6P Request (SeqNum=88) |
+ |-------------------------------------->| Inconsistency
+ | L2 ACK | detected
+ |<- - - - - - - - - - - - - - - - - - - |
+ | |
+ | 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
+ |<--------------------------------------|
+ | L2 ACK |
+ | - - - - - - - - - - - - - - - - - - ->|
+
+ Figure 31: Example of Inconsistency Because Node B Resets
+ (Detected by Node B)
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 37]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ SeqNum=97 | | SeqNum=97
+ | |
+ | 6P Request (SeqNum=97) |
+ |-------------------------------------->|
+ | L2 ACK |
+ |<- - - - - - - - - - - - - - - - - - - |
+ | |
+ | 6P Response (SeqNum=97) |
+ |<--------------------------------------|
+ | L2 ACK |
+ | - - - - - - - - - - - - - - - - - - ->|
+ | ==== power-cycle
+ | |
+ SeqNum=98 | | SeqNum=0
+ | |
+ | 6P Request (SeqNum=0) |
+ Inconsistency |<--------------------------------------|
+ detected | L2 ACK |
+ |- - - - - - - - - - - - - - - - - - - >|
+ | |
+ | 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
+ |-------------------------------------->|
+ | L2 ACK |
+ |<- - - - - - - - - - - - - - - - - - - |
+
+ Figure 32: Example of Inconsistency Because Node B Resets
+ (Detected by Node A)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 38]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ The second case is when the maximum number of link-layer
+ retransmissions is reached on the 6P Response of a 2-step transaction
+ (or, equivalently, on a 6P Confirmation of a 3-step transaction).
+ This is illustrated in Figure 33.
+
+ +----------+ +----------+
+ | Node A | | Node B |
+ +----+-----+ +-----+----+
+ SeqNum=87 | | SeqNum=87
+ | |
+ | 6P Request (SeqNum=87) |
+ |-------------------------------------->|
+ | L2 ACK |
+ |<- - - - - - - - - - - - - - - - - - - |
+ | |
+ | 6P Response (SeqNum=87) |
+ |<--------------------------------------|
+ | L2 ACK |
+ | - - - - - - - - X |
+ SeqNum=88 | | no ACK:
+ | 6P Response (SeqNum=87) | retrans. 1
+ (duplicate) |<--------------------------------------|
+ | L2 ACK |
+ | - - - - - - - - X |
+ | | no ACK:
+ | 6P Response (SeqNum=87) | retrans. 2
+ (duplicate) |<--------------------------------------|
+ | L2 ACK |
+ | - - - - - - - - X |
+ | | max. retrans.:
+ | | inconsistency
+ | | detected
+
+ Figure 33: Example Inconsistency Because of Maximum Link-Layer
+ Retransmissions (where Maximum = 2)
+
+ In both cases, node B detects the inconsistency.
+
+ If the inconsistency is detected during a 6P Transaction (Figure 31),
+ the node that has detected it MUST send back a 6P Response or 6P
+ Confirmation with an error code of RC_ERR_SEQNUM. In this 6P
+ Response or 6P Confirmation, the SeqNum field MUST be set to the
+ value of the sender of the message (0 in the example in Figure 31).
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 39]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ The SF of the node that has detected the inconsistency MUST define
+ how to handle the inconsistency. Three possible ways to do this are
+ as follows:
+
+ o Issue a 6P CLEAR Request to clear the schedule, and then rebuild.
+
+ o Issue a 6P LIST Request to retrieve the schedule.
+
+ o Internally "roll back" the schedule.
+
+ How to handle an inconsistency is out of scope for this document.
+ The SF defines how to handle an inconsistency.
+
+3.4.7. Handling Error Responses
+
+ A return code marked as Yes in the "Is Error?" column in Figure 38
+ (Section 6.2.4) indicates an error. When a node receives a 6P
+ Response or 6P Confirmation with an error, it MUST consider the 6P
+ Transaction as having failed. In particular, if this was a response
+ to a 6P ADD, DELETE, or RELOCATE Request, the node MUST NOT add,
+ delete, or relocate any of the cells involved in this 6P Transaction.
+ Similarly, a node sending a 6P Response or a 6P Confirmation with an
+ error code MUST NOT add, delete, or relocate any cells as part of
+ that 6P Transaction. If a node receives an unrecognized return code,
+ the 6P Transaction MUST be considered as having failed. In
+ particular, in a 3-step 6P Transaction, when receiving a 6P Response
+ with a return code that it does not recognize, the requester (node A)
+ MUST send a 6P Confirmation to the responder (node B) with return
+ code RC_ERR and consider the transaction failed. Upon reception of a
+ 6P Confirmation with return code RC_ERR, the responder MUST consider
+ the transaction failed as well. Defining what to do after an error
+ has occurred is out of scope for this document. The SF defines what
+ to do after an error has occurred.
+
+3.5. Security
+
+ 6P messages MUST be secured through link-layer security. This is
+ possible because 6P messages are carried as Payload IEs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 40]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+4. Requirements for 6top Scheduling Function (SF) Specifications
+
+4.1. SF Identifier (SFID)
+
+ Each SF has a 1-byte identifier. Section 6.2.5 defines the rules for
+ applying for an SFID.
+
+4.2. Requirements for an SF Specification
+
+ The specification for an SF
+
+ o MUST specify an identifier for that SF.
+
+ o MUST specify the rule for a node to decide when to add/delete one
+ or more cells to/on a neighbor.
+
+ o MUST specify the rule for a transaction source to select cells to
+ add to the CellList field in the 6P ADD Request.
+
+ o MUST specify the rule for a transaction destination to select
+ cells from the CellList to add to its schedule.
+
+ o MUST specify a value for the 6P Timeout or a rule/equation to
+ calculate it.
+
+ o MUST specify the rule for ordering cells.
+
+ o MUST specify a meaning for the Metadata field in the 6P ADD
+ Request.
+
+ o MUST specify the SF behavior of a node when it boots.
+
+ o MUST specify how to handle a schedule inconsistency.
+
+ o MUST specify what to do after an error has occurred (the node
+ either sent a 6P Response with an error code or received one).
+
+ o MUST specify the list of statistics to gather. Example statistics
+ include the number of transmitted frames to each neighbor. If the
+ SF does not require that statistics be gathered, the SF
+ specification MUST explicitly say so.
+
+ o SHOULD clearly state the application domain the SF is created for.
+
+ o SHOULD contain examples that highlight normal and error scenarios.
+
+ o SHOULD contain a list of current implementations, at least during
+ the Internet-Draft (I-D) state of the document, per [RFC7942].
+
+
+
+Wang, et al. Standards Track [Page 41]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ o SHOULD contain a performance evaluation of the scheme, possibly
+ through references to external documents.
+
+ o SHOULD define the format of the SIGNAL command payload and
+ its use.
+
+ o MAY redefine the format of the CellList field.
+
+ o MAY redefine the format of the CellOptions field.
+
+ o MAY redefine the meaning of the CellOptions field.
+
+5. Security Considerations
+
+ 6P messages are carried inside 802.15.4 Payload Information Elements
+ (IEs). Those Payload IEs are encrypted and authenticated at the link
+ layer through CCM* [CCM-Star] ("CCM" stands for "Cipher block
+ Chaining -- Message authentication code"). 6P benefits from the same
+ level of security as any other Payload IE. 6P does not define its
+ own security mechanisms. In particular, although a key management
+ solution is out of scope for this document, 6P will benefit from the
+ key management solution used in the network. This is relevant, as
+ security attacks such as forgery and misattribution attacks become
+ more damaging when a single key is shared amongst a group of more
+ than two participants.
+
+ 6P does not provide protection against DoS attacks. Example attacks
+ include not sending confirmation messages in 3-step transactions and
+ sending incorrectly formatted requests. These cases SHOULD be
+ handled by an appropriate policy, such as rate-limiting or
+ time-limited blacklisting of the attacker after several attempts.
+ The effect on the overall network is mostly localized to the two
+ nodes in question, as communication happens in dedicated cells.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 42]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+6. IANA Considerations
+
+6.1. IETF IE Subtype 6P
+
+ This document adds the following number to the "IEEE Std 802.15.4
+ IETF IE Subtype IDs" registry defined by [RFC8137]:
+
+ +--------+------------+-----------+
+ | Value | Subtype ID | Reference |
+ +--------+------------+-----------+
+ | 1 | SUBID_6TOP | RFC 8480 |
+ +---------------------+-----------+
+
+ Figure 34: IETF IE Subtype SUBID_6TOP
+
+6.2. 6TiSCH Parameters Subregistries
+
+ This section defines subregistries within the "IPv6 Over the TSCH
+ Mode of IEEE 802.15.4e (6TiSCH)" parameters registry, hereafter
+ referred to as the "6TiSCH parameters" registry. Each subregistry is
+ described in a subsection.
+
+6.2.1. 6P Version Numbers
+
+ The name of the subregistry is "6P Version Numbers".
+
+ The following note is included in this registry: "In the 6top
+ Protocol (6P) [RFC8480], there is a field to identify the version of
+ the protocol. This field is 4 bits in size."
+
+ Each entry in the subregistry must include the version in the
+ range 0-15 and a reference to the 6P version's documentation.
+
+ The initial entry in this subregistry is as follows:
+
+ +---------+-----------+
+ | Version | Reference |
+ +---------+-----------+
+ | 0 | RFC 8480 |
+ +---------+-----------+
+
+ Figure 35: 6P Version Number Entry
+
+ All other version numbers are Unassigned.
+
+ The IANA policy for future additions to this subregistry is "IETF
+ Review" or "IESG Approval" as described in [RFC8126].
+
+
+
+
+Wang, et al. Standards Track [Page 43]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+6.2.2. 6P Message Types
+
+ The name of the subregistry is "6P Message Types".
+
+ The following note is included in this registry: "In version 0 of the
+ 6top Protocol (6P) [RFC8480], there is a field to identify the type
+ of message. This field is 2 bits in size."
+
+ Each entry in the subregistry must include the message type in the
+ range b00-b11, the corresponding name, and a reference to the 6P
+ message type's documentation.
+
+ Initial entries in this subregistry are as follows:
+
+ +------+--------------+-----------+
+ | Type | Name | Reference |
+ +------+--------------+-----------+
+ | b00 | REQUEST | RFC 8480 |
+ | b01 | RESPONSE | RFC 8480 |
+ | b10 | CONFIRMATION | RFC 8480 |
+ +------+--------------+-----------+
+
+ Figure 36: 6P Message Types
+
+ All other message types are Unassigned.
+
+ The IANA policy for future additions to this subregistry is "IETF
+ Review" or "IESG Approval" as described in [RFC8126].
+
+6.2.3. 6P Command Identifiers
+
+ The name of the subregistry is "6P Command Identifiers".
+
+ The following note is included in this registry: "In version 0 of the
+ 6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in
+ size. In a 6P Request, the value of this Code field is used to
+ identify the command."
+
+ Each entry in the subregistry must include an identifier in the
+ range 0-255, the corresponding name, and a reference to the 6P
+ command identifier's documentation.
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 44]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Initial entries in this subregistry are as follows:
+
+ +------------+------------+-----------+
+ | Identifier | Name | Reference |
+ +------------+------------+-----------+
+ | 0 | Reserved | RFC 8480 |
+ | 1 | ADD | RFC 8480 |
+ | 2 | DELETE | RFC 8480 |
+ | 3 | RELOCATE | RFC 8480 |
+ | 4 | COUNT | RFC 8480 |
+ | 5 | LIST | RFC 8480 |
+ | 6 | SIGNAL | RFC 8480 |
+ | 7 | CLEAR | RFC 8480 |
+ | 8-254 | Unassigned | |
+ | 255 | Reserved | RFC 8480 |
+ +------------+------------+-----------+
+
+ Figure 37: 6P Command Identifiers
+
+ The IANA policy for future additions to this subregistry is "IETF
+ Review" or "IESG Approval" as described in [RFC8126].
+
+6.2.4. 6P Return Codes
+
+ The name of the subregistry is "6P Return Codes".
+
+ The following note is included in this registry: "In version 0 of the
+ 6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in
+ size. In a 6P Response or 6P Confirmation, the value of this Code
+ field is used to identify the return code."
+
+ Each entry in the subregistry must include a return code in the
+ range 0-255, the corresponding name, the corresponding description,
+ and a reference to the 6P return code's documentation. If the return
+ code corresponds to a Response error, the "Is Error?" entry must
+ indicate "Yes". Otherwise, "No" must be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 45]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ Initial entries in this subregistry are as follows:
+
+ +------+-----------------+---------------------------+-----------+
+ | Code | Name | Description | Is Error? |
+ +------+-----------------+---------------------------+-----------+
+ | 0 | RC_SUCCESS | operation succeeded | No |
+ | 1 | RC_EOL | end of list | No |
+ | 2 | RC_ERR | generic error | Yes |
+ | 3 | RC_RESET | critical error, reset | Yes |
+ | 4 | RC_ERR_VERSION | unsupported 6P version | Yes |
+ | 5 | RC_ERR_SFID | unsupported SFID | Yes |
+ | 6 | RC_ERR_SEQNUM | schedule inconsistency | Yes |
+ | 7 | RC_ERR_CELLLIST | cellList error | Yes |
+ | 8 | RC_ERR_BUSY | busy | Yes |
+ | 9 | RC_ERR_LOCKED | cells are locked | Yes |
+ +------+-----------------+---------------------------+-----------+
+
+ Figure 38: 6P Return Codes
+
+ All other message types are Unassigned.
+
+ The IANA policy for future additions to this subregistry is "IETF
+ Review" or "IESG Approval" as described in [RFC8126].
+
+6.2.5. 6P Scheduling Function Identifiers
+
+ The name of the subregistry is "6P Scheduling Function Identifiers".
+
+ The following note is included in this registry: "In version 0 of the
+ 6top Protocol (6P) [RFC8480], there is a field to identify the
+ Scheduling Function to handle the message. This field is 8 bits
+ in size."
+
+ Each entry in the subregistry must include an SFID in the
+ range 0-255, the corresponding name, and a reference to the 6P
+ Scheduling Function's documentation.
+
+ There are currently no entries in this subregistry.
+
+ +------+---------------------------------+--------------------------+
+ | SFID | Name | Reference |
+ +------+---------------------------------+--------------------------+
+ | 0-255| Unassigned | |
+ +------+---------------------------------+--------------------------+
+
+ Figure 39: SF Identifier (SFID) Entry
+
+ All message types are Unassigned.
+
+
+
+Wang, et al. Standards Track [Page 46]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+ The IANA policy for future additions to this subregistry depends on
+ the value of the SFID, as shown in Figure 40. These specifications
+ must follow the guidelines of Section 4.
+
+ +-----------+------------------------------+
+ | Range | Registration Procedures |
+ +-----------+------------------------------+
+ | 0-127 | IETF Review or IESG Approval |
+ | 128-255 | Expert Review |
+ +-----------+------------------------------+
+
+ Figure 40: SF Identifier (SFID): Registration Procedure
+
+6.2.6. 6P CellOptions Bitmap
+
+ The name of the subregistry is "6P CellOptions Bitmap".
+
+ The following note is included in this registry: "In version 0 of the
+ 6top Protocol (6P) [RFC8480], there is an optional CellOptions field
+ that is 8 bits in size."
+
+ Each entry in the subregistry must include a bit position in the
+ range 0-7, the corresponding name, and a reference to the bit's
+ documentation.
+
+ Initial entries in this subregistry are as follows:
+
+ +-----+---------------+-----------+
+ | bit | Name | Reference |
+ +-----+---------------+-----------+
+ | 0 | TX (Transmit) | RFC 8480 |
+ | 1 | RX (Receive) | RFC 8480 |
+ | 2 | SHARED | RFC 8480 |
+ | 3-7 | Reserved | |
+ +-----+---------------+-----------+
+
+ Figure 41: 6P CellOptions Bitmap
+
+ All other message types are Unassigned.
+
+ The IANA policy for future additions to this subregistry is "IETF
+ Review" or "IESG Approval" as described in [RFC8126].
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 47]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+7. References
+
+7.1. Normative References
+
+ [IEEE802154]
+ IEEE, "IEEE Standard for Low-Rate Wireless Networks",
+ IEEE 802.15.4, DOI 10.1109/IEEESTD.2016.7460875.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information
+ Element for the IETF", RFC 8137, DOI 10.17487/RFC8137,
+ May 2017, <https://www.rfc-editor.org/info/rfc8137>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+ RFC 2119 Key Words", BCP 14, RFC 8174,
+ DOI 10.17487/RFC8174, May 2017,
+ <https://www.rfc-editor.org/info/rfc8174>.
+
+7.2. Informative References
+
+ [CCM-Star] Struik, R., "Formal Specification of the CCM* Mode of
+ Operation", IEEE P802.15-4/0537r2, September 2005.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc7554>.
+
+ [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
+ Code: The Implementation Status Section", BCP 205,
+ RFC 7942, DOI 10.17487/RFC7942, July 2016,
+ <https://www.rfc-editor.org/info/rfc7942>.
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+ [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
+ IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
+ Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
+ May 2017, <https://www.rfc-editor.org/info/rfc8180>.
+
+
+
+
+Wang, et al. Standards Track [Page 48]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+Appendix A. Recommended Structure of an SF Specification
+
+ The following section structure for an SF document is RECOMMENDED:
+
+ o Introduction
+
+ o RFC 2119 Requirements Language (if applicable)
+
+ o Scheduling Function Identifier
+
+ o Rules for Adding/Deleting Cells
+
+ o Rules for CellList
+
+ o 6P Timeout Value
+
+ o Rule for Ordering Cells
+
+ o Meaning of the Metadata Field
+
+ o Node Behavior at Boot
+
+ o Schedule Inconsistency Handling
+
+ o 6P Error Handling
+
+ o Examples
+
+ o Implementation Status
+
+ o Security Considerations
+
+ o IANA Considerations
+
+ o Normative References (if applicable)
+
+ o Informative References (if applicable)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 49]
+
+RFC 8480 6top Protocol (6P) November 2018
+
+
+Authors' Addresses
+
+ Qin Wang (editor)
+ Univ. of Sci. and Tech. Beijing
+ 30 Xueyuan Road
+ Beijing, Hebei 100083
+ China
+
+ Email: wangqin@ies.ustb.edu.cn
+
+
+ Xavier Vilajosana
+ Universitat Oberta de Catalunya
+ 156 Rambla Poblenou
+ Barcelona, Catalonia 08018
+ Spain
+
+ Email: xvilajosana@uoc.edu
+
+
+ Thomas Watteyne
+ Analog Devices
+ 32990 Alvarado-Niles Road, Suite 910
+ Union City, CA 94587
+ United States of America
+
+ Email: thomas.watteyne@analog.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wang, et al. Standards Track [Page 50]
+