Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

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 <simon.duquennoy@ri.se>
Sent: jeudi 22 novembre 2018 09:50
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: 6tisch <6tisch@ietf.org>; 6tisch-ads@ietf.org; 6tisch-chairs@ietf.org
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) <pthubert@cisco.com<mailto:pthubert@cisco.com>> 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
6tisch@ietf.org<mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch