Re: [6tisch] SeqNum definition in RFC8480 (6P)
Thanks, Diego! I think, if SeqNum=0 has the special meaning, 6P would need to pass a received SeqNum to a corresponding SF... But, my understandings is that, SeqNum is maintained only by 6P and not revealed to SFs... An alternative way to tell a power-cycle event to the peer would have been defining a separate return code from RC_ERR_SEQNUM. > On Apr 24, 2019, at 12:47, Prof. Diego Dujovne > wrote: > > As far as I can remember, it is important to know that the peer has forgotten > all the states and has lost his schedule, so all the allocated cells with > that neighbour are currently not valid anymore and should be wiped from the > local schedule. Actually, a node having such a peer should remove outdated cells somehow without having an explicit signaling. This is not a job of 6P, though. The SF should take care of it. A peer may move away from the node without sending a CLEAR request. Even if the peer sends a CLEAR request before moving somewhere, the CLEAR request may be lost in the air. RPL may do something for this case. If a node has some dedicated TX cells to its parent, and the parent reboots, RPL on the node could notice there is something wrong with the parent since measured link quality to the parent is getting worse. Then, parent switch will be performed. Or, a SF like MSF would try to relocate badly performed cells. Then, it receives RC_ERR_SEQNUM from the parent and take actions to resolve the schedule inconsistency in the same manner as for other scheduling consistency cases. The node can see whether the peer loses all the states nor not by having a following COUNT transaction if the SF really wants to know. If the SF always issues a CLEAR request to a peer which sent RC_ERR_SEQNUM, the SF doesn't care about the power-cycle event. Another possibility is that the RELOCATE transaction ends by 6P Timeout. Again, some actions will be taken by the SF. Best, Yatch ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] SeqNum definition in RFC8480 (6P)
Yacht, Let me chime in a little bit. Responses below. Regards, Diego El mié., 24 de abr. de 2019 06:24, Yasuyuki Tanaka escribió: > Hi Xavi, > > > What is the issue you see with this? > > At least, there is an inconsistency in RFC8480. Here is another example: > > https://tools.ietf.org/html/rfc8480#section-3.2.2 > > rfc8480> 6P Request, 6P Response, and 6P Confirmation messages for a > given > rfc8480> transaction MUST share the same Version, SFID, and SeqNum > values. > > Such an inconsistency could bring confusion and/or an interoperability > issue. > > According to you, a response having SeqNum=0 AND RC_ERR_SEQNUM has a > special > meaning which is "I've lost all the states completely (due to > power-cycle)", > although this is another case we will receive such a response as shown in > Figure 32... Honestly, I'm not sure how valuable it is to know the peer has > performed power-cycle, by the way. > As far as I can remember, it is important to know that the peer has forgotten all the states and has lost his schedule, so all the allocated cells with that neighbour are currently not valid anymore and should be wiped from the local schedule. > So, if setting 0 to SeqNum of a response is a right thing, I would add some > text to the SeqNum definition in Section 3.2.2, to tell there is an > exception. > > Best, > Yatch > ___ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] SeqNum definition in RFC8480 (6P)
Hi Xavi, > What is the issue you see with this? At least, there is an inconsistency in RFC8480. Here is another example: https://tools.ietf.org/html/rfc8480#section-3.2.2 rfc8480> 6P Request, 6P Response, and 6P Confirmation messages for a given rfc8480> transaction MUST share the same Version, SFID, and SeqNum values. Such an inconsistency could bring confusion and/or an interoperability issue. According to you, a response having SeqNum=0 AND RC_ERR_SEQNUM has a special meaning which is "I've lost all the states completely (due to power-cycle)", although this is another case we will receive such a response as shown in Figure 32... Honestly, I'm not sure how valuable it is to know the peer has performed power-cycle, by the way. So, if setting 0 to SeqNum of a response is a right thing, I would add some text to the SeqNum definition in Section 3.2.2, to tell there is an exception. Best, Yatch ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] SeqNum definition in RFC8480 (6P)
Hi Yatch, thanks for your response. see inline my comments. Missatge de Yasuyuki Tanaka del dia dt., 23 d’abr. 2019 a les 10:49: > Hi Xavi, > > Thank you for your reply. > > On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote: > > 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? > > I don't think so... Why doesn't Node B just use SeqNum received from Node > A for its response? > > Node A in Figure 31 would drop the response with SeqNum=0 at 6P layer > because it is not considered as part of the transaction started by the > request with SeqNum=88. > well SeqNum=0 is only possible after a reset or when the node boots. SeqNum will always be different than 0 except for that occasions. So 6P can be aware situation happening in the middle of a transaction. We took that decision as we consider that Node B may have completely lost the state, which is critical. Probably the option you mention would have been also possible but we took that direction. What is the issue you see with this? > Again, the definition of SeqNum is: > > >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. > > Best, > Yatch > regards X -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajos...@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
Re: [6tisch] SeqNum definition in RFC8480 (6P)
Hi Xavi, Thank you for your reply. On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote: 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? I don't think so... Why doesn't Node B just use SeqNum received from Node A for its response? Node A in Figure 31 would drop the response with SeqNum=0 at 6P layer because it is not considered as part of the transaction started by the request with SeqNum=88. Again, the definition of SeqNum is: 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. Best, Yatch ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] SeqNum definition in RFC8480 (6P)
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 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/mailm
