Dear all, +1 to be able to reserve dynamically cells for the non best effort tracks. It would be more flexible.
Regards, Fabrice > Le 30 sept. 2015 à 10:46, Maria Rita PALATTELLA > <[email protected]> a écrit : > > Dear Pascal, all > > I agree it should be better to not limit OTF to the best effort track (IP > traffic). We may in the future look into more advanced features, and consider > other specific tracks. > > About the first point on the 6TiSCH Architecture, I have the feeling we > should describe better the link between 6TiSCH and DetNet (IMHO applicability > of DetNet work doesn’t sound clear). > > Finally, we could remove the text on non-chartered items (all the content can > be kept in a wiki, as per discussion in Prague), but I would add a short > sentence referring to the Interop events. If we are planning to keep in > organizing them, better to mention it. > > Thanks for your work. > > Regards, > Maria Rita > > > > From: 6tisch [mailto:[email protected]] On Behalf Of Pascal Thubert > (pthubert) > Sent: Monday, September 28, 2015 12:08 PM > 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 _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
