Hi, This is an open issue, what return code to return when there is no available cell.
Christian raised it before: https://mailarchive.ietf.org/arch/msg/6tisch/Awiip2xOfwZTPyg1jQIeIOyqSgk As per RFC8480: - RC_SUCCESS with an empty list will be returned - RC_ERR_BUSY is defined to be returned when there is not enough resource to handle a new *transaction* - RC_ERR defined is be returned for a request having an invalid CellOptions value, or for a response having an unknown return code (in the 3-step case) > I woud send back either an RC_ERR_BUSY or RC_ERR, definitely NOT RC_SUCCESSS Between the two, RC_ERR_BUSY would be better since RC_ERR is basically telling that the responder doesn't understand your 6P message. But, RC_ERR_BUSY is not good either. It is a return code suggesting "retry it later", not "give up this neighbor." If possible, I would define a dedicated return code for this case, like RC_ERR_NO_AVAILABLE_CELL or RC_ERR_NO_CELL, though. One solution within RFC8480 is to perform a 3-step ADD transaction on receiving an empty cell with RC_SUCCESS to an (2-step) ADD request. If the responder doesn't have enough cells, it will return an empty cell list as the candidate cell list in its response. Best, Yatch > On Aug 14, 2019, at 19:03, Thomas Watteyne <[email protected]> wrote: > > I woud send back either an RC_ERR_BUSY or RC_ERR, definitely NOT RC_SUCCESSS > > ________________________________________ > > 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]> > À: "Thomas Watteyne" <[email protected]> > Cc: "6tisch" <[email protected]> > Envoyé: Mercredi 14 Août 2019 08:46:25 > Objet: Re: [6tisch] draft-ietf-6tisch-msf-06 is published > 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). > > 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 _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
