Hi Christian, I understand your concern. In the current draft we maintain a Tx cell for each known neighbor, and this might end up draining resources. Maybe we should leave more flexibility on maintenance of autonomous cells? One could even choose to install autonomous cells only on-demand: when a packet is queued to a given neighbor, install cell towards that neighbor, then remove it after sending.
Best, Simon On Wed, Oct 24, 2018 at 2:29 PM Christian Hopfner < [email protected]> wrote: > Hi all, > > > > I have some question comments on latest draft of msf. > > > > 3. Autonomous Unicast Cells > > MSF nodes MUST initialize Slotframe 1 with a set of default cells for > > unicast communication with their neighbors. These cells are referred > > to as ’autonomous cells’, because they are maintained autonomously by > > each node. Each node has: > > > > 1. One cell to receive, at a [slotOffset,channelOffset] computed as > > a hash of the node’s EUI64 (detailed next). The cell options for > > this cell are RX=1. > > > > 2. For each neighbor in the IPv6 neighbor table, one cell to > > transmit, at a [slotOffset,channelOffset] computed as a hash of > > the neighbor’s EUI64 (detailed next). The cell options for this > > cell are TX=1, SHARED=1. > > > > CH I’m not sure if this 2nd item makes sense discussion it with the > background of low-power and bandwidth capacity. Assuming we have space for > 30 neighbor entries within my neighbor table this will lead to 32 cells > being allocated within my schedule. 30 neighbors, my autonomous RX cell and > shared minimal. This will reduce available bandwidth for the node > tremendously. And might increase power consumption in parallel if we do not > a have an intelligent scheduler which keeps the device in sleep even for > active TX cells if we know in advance that there is no packet in the queue > for the specific neighbor. > > > > What about considering only RPL neighbors for allocation TX, S cells to. > This will keep the amount of allocated cell at least at a minimum necessary > cells. If it comes to network transformation due to changing RPL parameters > the Parent Switch functionality of msf will take care of reallocating > installed cells. > > > 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 protected] | 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. > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
