Hi Pascal,
Thank you very much for the clarification and for the valuable inputs!
Looking forward to have a discussion on the topic.
Anand
On Tuesday 29 September 2015 05:14 PM, Pascal Thubert (pthubert) wrote:
Hello Anand:
The intent of the for IP traffic is really whatever traffic is routed
by the motes, as opposed to switched at L2.5 along tracks.
And I agree with you for the rest. We have to define tracks, which can
probably be more complex than a simple sequence of hops if we want to
enable replication and elimination (PRP like).
I wrote some text in
https://www.ietf.org/id/draft-thubert-6tisch-4detnet-01.txt and would
really appreciate your review in this matter.
And yes, I think it is important to be able to carve PRP path that go
to the same collection point on the backbone via different BBRs… I
know of some techniques, some with IPR on them (and this includes PRP
actually) that we could discuss in the context of that draft.
Take care;
Pascal
*From:*S.V.R.Anand [mailto:[email protected]]
*Sent:* mardi 29 septembre 2015 12:17
*To:* Pascal Thubert (pthubert) <[email protected]>; [email protected]
*Subject:* Re: [6tisch] Rechartering Discussion
Hi Pascal,
The updated items that have been considered for the charter are very
appropriate.
With respect to the the usage of yellow coloured "for IP traffic" in
the item 3. I get a feeling
that the intent is to provide enough bandwidth for performing
essential but relatively not-very-critical control/management plane
operations without hurting the determinism expected from the data
plane whatsoever. Is my interpretation right ?
One of the schemes Detnet proposes is seamless redundancy replication
and elimination. Are we aiming for its realization under 6tisch ?
If we do so, I suppose it brings in its own set of challenges with
respect to track and cell management. This is due to the extent of
replication, when and where it comes into play inside the network,
the presence of multiple BBRs. Would be very happy to receive your
thoughts on this aspect.
Anand
On Monday 28 September 2015 03:38 PM, Pascal Thubert (pthubert) wrote:
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
--
This message has been scanned for viruses and
dangerous content by *MailScanner*
<http://www.mailscanner.info/>*, and is
believed to be clean. *
*_______________________________________________*
*6tisch mailing list*
*[email protected] <mailto:[email protected]>*
*https://www.ietf.org/mailman/listinfo/6tisch*
--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
