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

[Xavi Vilajosana Guillen <[e-mail]>]

Hi Yatch,

thanks for your observation. I think that the behaviour is correct as
described in the text. When node B power cycles loses the last seen seqNum.
Its stored value is then 0 and hence when it receives the request responds
with the error and with the stored last seen seqnum (0).

does it make sense?
regards
Xavi

Missatge de Yasuyuki Tanaka <[e-mail]> del dia dv., 19
d’abr. 2019 a les 18:05:

> 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
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
([phone]
[e-mail] <[e-mail]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
[image: Universitat Oberta de Catalunya]
­