Hello Qing Please see below:
Pascal > Le 28 sept. 2015 à 17:41, Wang, Chonggang <[email protected]> a > écrit : > > Hi Pascal and All, > > > > Sorry that I missed the interim on Friday 9/25. As for the re-chartering, the > drafted bullets look like a nice continuation of existing 6TiSCH work. I had > a few questions/comments below. > > > > 1. 6TiSCH architecture: the latest version seems to have content related to > existing charter and re-chartering. Wonder if a short version of existing > 6TiSCH architecture will be published first as the output of existing > charter. If that's the case, wonder which part of existing 6TiSCH > architecture will be shortened or removed. > We tried but Ralph's review was considered a push back and we followed his advice to ship the complete architecture when 6TiSCH completes. > > 2. 6TiSCH Architecture: "...including the operation of the network in the > presence of multiple LBRs...". Wonder which kind of "operations" will be > considered and whether they are unique to 6TiSCH. > They are not but so far only 6TiSCH documented its architecture. That is actually complete as part of the first charter. > 3. 6TiSCH Architecture: "...The existing document will be augmented to cover > dynamic scheduling and applicability of DetNet work". Wonder what's the > definition of "dynamic scheduling" here. Also, for "applicability of DetNet > work", wonder if dynamic scheduling work will be proposed within 6TiSCH and > will be applied to future DetNet WG. > the dynamic scheduling is when the nodes define their schedule whereas DetNet is when the PCE does it. This is by opposition to minimal that used a static schedule. > > > 4. Information Model: "A data model mapping for an existing protocol (such as > Concise Binary Object Representation (CBOR) over the Constrained Application > Protocol (CoAP)) will be provided". I suggested removing "such as Concise > Binary Object Representation (CBOR) over the Constrained Application Protocol > (CoAP)" since it's mentioned at the end of Pascal's email that CoAP draft > will not be continued; also ICMP protocol or other protocols could be good > options too. > > Well noted. Fine with me. > > 5. On-the-Fly: "Produce an “On-the-fly" specification to enable a distributed > dynamic scheduling of time slots for IP traffic". Agree to remove "for IP > traffic". > +1 : ) > > > 6. Security: "Produce a specification for a secure 6TiSCH network > bootstrap...". First, 6LO seems to have a work on constrained device > bootstrap. In addition, security for 6TiSCH networks in layer 2/3 has > multiple aspects and bootstrap is one of them. For re-chartering, should we > also consider other security aspects such as secure centralized or dynamic > scheduling, secure forwarding or routing, etc. > > This is because the group has been very active on that particular aspect for more than a year, and has a clear leadership on the Matter. We may have 6TiSCH specific constraints and our links into 802.15.4 may help us consider interactions with say 802.15.9... For other aspects of security, the work is much needed but there is no indication that it should take place here. > > 7. Centralized vs Distributed Scheduling: I feel 6TiSCH has a variety of use > cases. Some use cases have small networks with a small number of devices > (centralized could work) and others with a larger scale (more devices and > distributed scheduling may be better). In addition, for different > applications, both centralized and distributed scheduling have pros and cons. > From 6TiSCH perspective, either scheme or both could be standardized. > > +1 We start with distributed to leave room for DetNet to sort the generic problems > > Sorry for the long email. > > > Thank YOU Qing, great comments! Pascal > Thanks, > > Chonggang > > > > Chonggang Wang > Member Technical Staff > InterDigital Communications, Inc. > 781 Third Ave > King of Prussia, PA 19406 > T: +1 610.878.5731 > [email protected] > www.InterDigital.com<http://www.interdigital.com> > > [cid:[email protected]] > > This e-mail is intended only for the use of the individual or entity to which > it is addressed, and may contain information that is privileged, confidential > and/or otherwise protected from disclosure to anyone other than its intended > recipient. Unintended transmission shall not constitute waiver of any > privilege or confidentiality obligation. If you received this communication > in error, please do not review, copy or distribute it, notify me immediately > by email, and delete the original message and any attachments. Unless > expressly stated in this e-mail, nothing in this message or any attachment > should be construed as a digital or electronic signature. > > > ________________________________ > From: 6tisch [[email protected]] on behalf of Pascal Thubert (pthubert) > [[email protected]] > Sent: Monday, September 28, 2015 6:08 AM > To: [email protected] > Subject: [6tisch] Rechartering Discussion > > Dear all: > > This is the continuation if the discussion we had at the interim on Friday > 9/25 > (see published minutes @ > https://www.ietf.org/proceedings/interim/2015/09/25/6tisch/minutes/minutes-interim-2015-6tisch-13 > and > slides @ > https://www.ietf.org/proceedings/interim/2015/09/25/6tisch/slides/slides-interim-2015-6tisch-13-0.pdf > ). > > The highlighted / colored text below is an inline copy of the slides in the > above pdf so you may use that source as well. > > To the point; the current charter has the following: > > “ > > The group will: > > 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH > networks. This document will highlight the different architectural > blocks and signaling flows, including the operation of the network in > the presence of multiple LBRs. Initially, the document will focus on > distributed routing operation over a static TSCH schedule. > > 2. Produce an Information Model containing the management requirements > of a 6TiSCH node. This includes describing how an entity can manage the > TSCH schedule on a 6TiSCH node, and query timeslot information from that > node. A data model mapping for an existing protocol (such as Concise > Binary Object Representation (CBOR) over the Constrained Application > Protocol (CoAP)) will be provided. > > 3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH > network using the Routing Protocol for LLNs (RPL) and a static TSCH > schedule. It is expected that RPL and the Objective Function 0 (OF0) > will be reused as-is. > > The work will include a best practice configuration for RPL and OF0 > operation over the static schedule. Based on that experience the group > may produce a requirements draft for OF0 extensions, to be studied in ROLL. > > “ > > The tasks in red were never started and apparently did not raise interest in > the group. > The tasks in green are mostly complete. > In particular, the minimal draft was officially submitted to the IESG for > review. > Now we need to make room for new work in security and dynamic scheduling. > So at the interim we proposed to update the charter as follows: > > > The group will: > > 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH > networks. This document will highlight the different architectural > blocks and signaling flows, including the operation of the network in > the presence of multiple LBRs. The existing document will be > augmented to cover dynamic scheduling and applicability of DetNet work. > > 2. Produce an Information Model containing the management requirements > of a 6TiSCH node. This includes describing how an entity can manage the > TSCH schedule on a 6TiSCH node, and query timeslot information from that > node. A data model mapping for an existing protocol (such as Concise > Binary Object Representation (CBOR) over the Constrained Application > Protocol (CoAP)) will be provided. MAC-layer interactions to negotiate > Time Slots between peers will be proposed, to be eventually continued > at IEEE. > > 3. Produce an “On-the-fly" specification to enable a distributed dynamic > scheduling of time slots for IP traffic, with the capability for IoT routers > to appropriate chunks of the matrix without starving, or interfering with, > other 6TiSCH nodes. > > 4. Produce a specification for a secure 6TiSCH network bootstrap, adapted > to the constraints of 6TiSCH nodes and leveraging existing art when > possible. > > > The text in blue are proposed additions that made consensus at the call. > > The questions left were about items in red and yellow, and we are > specifically asking for advice on those, > though advice on the rest of the proposal is welcome as well. > > A suggestion was made to discontinue the work on the coap draft. Reason > advanced was that the CoMI work would make the draft mostly void. > Any comment on that? > > Another suggestion would be to remove the text in Yellow that limits the OTF > work to IP bundles (aka track0 or best effort). > Again, comments are welcome. > > > Finally, there the text about non chatrtered items. > > The Working Group may maintain a number of running, often-respun > documents, that evolve as the technology is refined for work items that > do not affect the milestone work items: > - implementers guide: this document will collect clarifying information > based on input from implementers, in particular as it becomes available > from interoperability events. This guide will contain information about > test harnesses used for interoperability testing. > - coexistence guide: this document will provide information on how > 6TiSCH can be operated in an environment shared with other protocols > that use the same or a similar TSCH MAC, and/or operate on the same > frequency band. > - Text on Interop test ? > The WG will welcome requirements for dynamic timeslot operation, for > example for centralized schedule computation. > > > A question was whether to keep them, another was whether to mention documents > on interop tests, > since the appeared to be very useful in Prague. > > What do you guys think? > > Take care; > > Pascal, on behalf of the chairs > > > > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
