RFC 8480
6TiSCH Operation Sublayer (6top) Protocol (6P)
Pages: 50
Proposed Standard
Proposed Standard
Part 3 of 4 – Pages 31 to 42
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
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.
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.
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 SeqNum3.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.
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
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
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)
+----------+ +----------+ | 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)
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).
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.
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].
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.
(next page on part 4)