[6tisch] SeqNum definition in RFC8480 (6P)

[Yasuyuki Tanaka <[e-mail]>]

Hi,

I came across a question in RFC8480 (6P), which looks like an error to
me... Can anybody help? This is about the SeqNum field of the 6P header.

Section 3.2.2 defines SeqNum like this:

[https://tools.ietf.org/html/rfc8480#section-3.2.2]
>   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.

So, basically, a response and a confirmation have the same SeqNum
value as the corresponding request. This is very normal.

However, Section 3.4.6.2 says, if a node detect schedule inconsistency
with a received request, the node does a different thing. A response
in this case has a different SeqNum value from the corresponding
request. This is strange...

[https://tools.ietf.org/html/rfc8480#section-3.4.6.2]
>   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).

In Figure 31, Node A receives 6P Response (SeqNum=0, RC_ERR_SEQNUM) in
the last part of the message sequence. But, according to the
definition by Section 3.2.2, Node A doesn't consider the response to
be part of the transaction initiated by 6P Request (SeqNum=88),

[https://tools.ietf.org/html/rfc8480#section-3.4.6.2]
>           +----------+                           +----------+
>           |  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)

If this is an error, I'm going to file an errata entry. Otherwise, I'd
like to know why Node B in Figure 31 MUST set 0 to SeqNum for the 6P
Response having RC_ERR_SEQNUM. Node A becomes aware of schedule
inconsistency anyway, seeing RC_ERR_SEQNUM in the response.

By the way, the 5th paragraph in Section 3.4.6 supports Section
3.2.2. The response in an example of the paragraph has the same SeqNum
value as the response, which is 0. This is the same case as explained
with Figure 32.

[https://tools.ietf.org/html/rfc8480#section-3.4.6]
>   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.

Or, am I just confused...?

Best,
Yatch