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

From: Christian Hopfner <[email-masked]>
Date: Tue, 25 Sep 2018 08:49:32 +0000

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: +49 7622 28 1883
[email-masked] | 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<https://www.de.endress.com/de/cookies-endress+hauser-website> 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<https://www.de.endress.com/en/endress-hauser-website-cookies/en-data-protection-notice-de>

________________________________

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.

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Tue, 25 Sep 2018 11:23:44 +0200

Hi Christian,

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

> 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 <[email-masked]> wrote:
> 
> Hello,
>  
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.
> 
> Endress+Hauser SE+Co. KG
> We comply with this information duty with the following Data Protection Statement
> 
>  
> Disclaimer: 
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch