Hello Simon
I added the following on your behalf
<xref target="I-D.ietf-6tisch-msf">MSF</xref> is one of the possible
scheduling functions. MSF uses the rendez-vous slot from
<xref target="RFC8180"/> for network discovery, neighbor discovery,
and any other broadcast.
For basic unicast communication with any neighbor, each node uses a
receive cell at a well-known slotOffset/channelOffset, derived from
a hash of their own MAC address.
Nodes can reach any neighbor by installing a transmit (shared) cell
with slotOffset/channelOffset derived from the neighbor's MAC
address.
For child-parent links, MSF continuously monitors the load to/from
parents and children. It then uses 6P to install/remove unicast cells
whenever the current schedule appears to be under-/over- provisioned.
Please note this makes you contributor. I also added your name in the
contributor section if you do not mind.
Take care,
Pascal
From: Simon Duquennoy <[email protected]>
Sent: jeudi 22 novembre 2018 09:50
To: Pascal Thubert (pthubert) <[email protected]>
Cc: 6tisch <[email protected]>; [email protected]; [email protected]
Subject: Re: [6tisch] WGLC for
https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt
Hi Pascal, WG,
I drafted a summary of MSF for potential inclusion in 4.4.2.
The proposal is to:
(1) Remove MSF mention in "An optional Scheduling Function (SF) such as MSF
[I-D.ietf-6tisch-msf] is used to"
-> "An optional Scheduling Function (SF) is used to"
(2) Add the following paragraph at the end of the section:
========
As an example SF, we briefly introduce MSF [I-D.ietf-6tisch-msf].
MSF uses the rendez-vous slot from [RFC8180] for network discovery, neighbor
discovery, and any other broadcast.
For basic unicast communication with any neighbor, each node has a receive
cells at a well-known slotOffset/channelOffset, derived from a hash of their
own MAC address.
Nodes can reach any neighbor by installing a transmit (shared) cell with
slotOffset/channelOffset derived from the neighbor's MAC address.
For child-parent links, MSF continuously monitors the load to/from parents and
children.
It then uses 6P to install/remove unicast cells whenever the current schedule
appears to be under-/over- provisioned.
========
Thank you,
Simon
On Sun, Nov 11, 2018 at 3:23 AM Pascal Thubert (pthubert)
<[email protected]<mailto:[email protected]>> wrote:
Dear WG :
We are now starting the working group last call for the 6TiSCH Architecture
based on https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt. This
document is the merge of the previous architecture and terminology documents.
Authors of our WIP WG docs
draft-ietf-6tisch-dtsecurity-zerotouch-join-03<https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/>,
draft-ietf-6tisch-enrollment-enhanced-beacon-00<https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/>,
draft-ietf-6tisch-minimal-security-08<https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/>
and
draft-ietf-6tisch-msf-01<https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/>
are requested to pay particular attention on how their work is reflected in
the Architecture, and are strongly encouraged to propose new text to improve
the correctness of that representation.
The architecture is a foundational product of the WG, providing the view on the
whole stack that we designed, implemented and interop tested over the 5 years
of activity of the group; it is in some form a testimony of the WG.
With this in mind, please pay a very special attention when reviewing it.
The WGLC ends on Friday November 30th, 2018.
Many thanks in advance;
The chairs.
_______________________________________________
6tisch mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
