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 <yasuyuki.tan...@inria.fr> 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 > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajos...@uoc.edu <usu...@uoc.edu> 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]
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
