Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8480

6TiSCH Operation Sublayer (6top) Protocol (6P)

Pages: 50
Proposed Standard
Part 3 of 4 – Pages 31 to 42
First   Prev   Next

Top   ToC   RFC8480 - Page 31   prevText

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
Top   ToC   RFC8480 - Page 32
   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.
Top   ToC   RFC8480 - Page 33

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.
Top   ToC   RFC8480 - Page 34
   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.
Top   ToC   RFC8480 - Page 35
   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
Top   ToC   RFC8480 - Page 36
   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
Top   ToC   RFC8480 - Page 37
   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)
Top   ToC   RFC8480 - Page 38
            +----------+                           +----------+
            |  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)
Top   ToC   RFC8480 - Page 39
   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).
Top   ToC   RFC8480 - Page 40
   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.
Top   ToC   RFC8480 - Page 41

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].
Top   ToC   RFC8480 - Page 42
   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)

Next Section