Hi Thomas,
Yes, you understood correctly. There are two related part in RFC8480 mentioned this case: Upon receiving the request, node B checks to see if the length of the Candidate CellList is greater than or equal to NumCells. Node B's SF verifies that all the cells in the Relocation CellList are scheduled with node A and are associated with the options specified in the CellOptions field. If either check fails, node B MUST send a 6P Response to node A with return code RC_ERR_CELLLIST. If both checks pass, node B's SF verifies which of the cells in the Candidate CellList it can install in its schedule. How that selection is done is specified in the SF and is out of scope for this document. That verification for the Candidate CellList can succeed (NumCells cells from the Candidate CellList can be used), fail (none of the cells from the Candidate CellList can be used), or partially succeed (fewer than NumCells cells from the Candidate CellList can be used). In all cases, node B MUST send a 6P Response that includes a return code set to RC_SUCCESS and that specifies the list of cells that will be rescheduled following the CellOptions field. That list can contain NumCells elements (succeed), 0 elements (fail), or between 0 and NumCells elements (partially succeed). If N < NumCells cells appear in the CellList, this means that the first N cells in the Relocation CellList have been relocated and the remainder have not. Here it clarified the return code for this case MUST be RC_SUCCESS. I would say it may implies that the case should be the option 1 I mentioned above. Another part in concurrent 6P transaction section, it says: 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 <https://tools.ietf.org/html/rfc8480#section-6.2.4>). I says enough resources to handle concurrent 6P Transactions, but the option 2 I mentioned doesn't need to be concurrent 6P transaction. Also the RC_BUSY doesn't sound the right return code name for this case. So does the RC_BUSY is the return code for option 2 I mentioned? Tengfei On Wed, Aug 14, 2019 at 4:45 PM Thomas Watteyne <[email protected]> wrote: > Tengfei, > > Trying to understand you point about " handle Sixtop ADD Response with > return code SUCCESS but 0 cells in cellList" > > If the response code is SUCCESS, IMO that means option 1. if option 2 is > happening (I assume you mean "there is no memory for allocating more > cells"), I would expect another return code, no? > > THomas > > > > ________________________________________ > > Thomas Watteyne, PhD > Sr Research Scientist & Innovator, Inria > Sr Networking Design Eng, Analog Devices > Founder & Advisor, Wattson Elements/Falco > Founder & co-lead, UC Berkeley OpenWSN > Co-chair, IETF 6TiSCH > > www.thomaswatteyne.com > ________________________________________ > > ------------------------------ > > *De: *"tengfei chang" <[email protected]> > *À: *"6tisch" <[email protected]> > *Envoyé: *Lundi 12 Août 2019 08:52:37 > *Objet: *[6tisch] draft-ietf-6tisch-msf-06 is published > > Dear all, > The draft-ietf-6tisch-msf-06 is just published, it mainly resolved what > we discussed during the IETF meeting. > > - add rules for celllist > - update the downstream cell adaptation strategy > > > Right now, there is one issue remained to be resolved and I am not sure > what is the right solution. So I need suggestions and feedback from you: > > - handle Sixtop ADD Response with return code SUCCESS but 0 cells in > cellList > > There are two possible reason for this situation > 1. the proposed celllist doesn't meet the requirement from neighbor side > 2. there is schedule memory for adding more cells. > > For the 1st reason, the node may try to send another 6P request later. > For the 2nd reason, the node may switch to another parent but it's layer > violated. > > Any solutions for this case? > > Tengfei > > -- > Chang Tengfei, > Postdoctoral Research Engineer, Inria > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- Chang Tengfei, Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
