Re: [6tisch] MSF / 6top - Error Handling for Bandwidth Allocation exceeding available capacity

[Yasuyuki Tanaka <[e-mail]>]

Hi Christian,

Indeed, there is no return code found in draft-ietf-6tisch-6top-protocol-12 for such a case. 

> Node C indicates a 6P ADD to node A which is answered with 6P_SUCCESS but with an empty cellist (2-step transaction). I guess next time node C can try 3-step transaction giving node A the opportunity to propose a cellist. 
> In case Node A has no cells to propose the response should contain RC_ERR_CELLLIST error correct?

Node A can respond with an empty cell list to the ADD request to indicate that it cannot give any candidate cell to add. The 6P draft implies this, although the text assumes only 2-step ADD transaction.

(https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-12#section-3.3.1)
>    CellList can be used).  In all cases, node B MUST send a 6P Response
>    with return code set to RC_SUCCESS, and which specifies the list of
>    cells that were scheduled following the CellOptions field.  That can
>    contain NumCells elements (succeed), 0 elements (fail), or between 0
>    and NumCells elements (partially succeed).

Then, you can do something on receiving an empty cell list in the response message for a 3-step ADD transaction.

> If there would be an error code signaling “out of bandwidth” the SF may trigger a parent switch towards a neighbor which can handle the required traffic.


Best,
Yatch

> On Sep 25, 2018, at 10:49, Christian Hopfner <[e-mail]> wrote:
> 
> Hello,
>  
> I have not found an answer to my question yet, reading through 6top and msf draft. Is there anything foreseen signaling that a node does not have any bandwidth capacity remaining (max active cells reached, with respect to given policy).
>  
> Let’s assume we have a network with 4 nodes where node R is parent of nodes A and B. Node C is child of A and requires more bandwidth. But A has no additional bandwidth available.
>  
> Node C indicates a 6P ADD to node A which is answered with 6P_SUCCESS but with an empty cellist (2-step transaction). I guess next time node C can try 3-step transaction giving node A the opportunity to propose a cellist. 
> In case Node A has no cells to propose the response should contain RC_ERR_CELLLIST error correct?
>  
> But at the end Node C may end up in a loop trying to get more bandwidth unless node B becomes its preferred parent isn’t it?
>  
> If there would be an error code signaling “out of bandwidth” the SF may trigger a parent switch towards a neighbor which can handle the required traffic.
>  
>  
> 
> Mit freundlichen Grüßen I Best regards 
> 
> Christian Hopfner
> 
> Developer | TPI F&E Plattform Informatik
> Endress+Hauser SE+Co. KG | Hauptstrasse 1 | 79689 Maulburg | Germany
> Phone: [phone]
> [e-mail] | www.pcm.endress.com 
> 
> 
> Endress+Hauser SE+Co. KG
> Registergericht: Amtsgericht Freiburg i.Br. HRA 670225
> Sitz der Gesellschaft: Maulburg
> Persönlich haftender Gesellschafter: Endress+Hauser Administration SE
> Sitz des persönlich haftenden Gesellschafters: Maulburg
> Registergericht: Amtsgericht Freiburg i.Br. HRB 717326
> Vorstand: Dr. Andreas Mayr
> Aufsichtsratsvorsitzender: Matthias Altendorf
> 
> Gemäss der Datenschutzgrundverordnung (EU-DSGVO) sind wir verpflichtet, Sie zu informieren,
> wenn wir personenbezogene Daten von Ihnen erheben.
> 
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.
> 
> Endress+Hauser SE+Co. KG
> Register Court: Local Court of Freiburg i.Br. HRA 670225
> Registered Office: Maulburg
> General Partner: Endress+Hauser Administration SE
> Registered Office of General Partner: Maulburg
> Register Court: Local Court of Freiburg i.Br. HRB 717326
> Chief Executive Officer: Dr. Andreas Mayr
> Chairman of the Board: Matthias Altendorf
> 
> According to the General Data Protection Regulation,
> we are obliged to inform you when collecting your personal data.
> We comply with this information duty with the following Data Protection Statement
> 
>  
> Disclaimer: 
> 
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged
> material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities
> other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer.
> This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
> 
>  
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch