Fantastic Michael!
I'm willing to give a hand after August if that's useful?
Pascal
> Le 10 juin 2015 à 18:20, Michael Richardson a écrit :
>
>
> Pascal Thubert (pthubert) wrote:
OTOH, there is one (or more?) RPL instance that is used for 6TiSCH
timing. I think all we need in 6top
Pascal Thubert (pthubert) wrote:
>> > OTOH, there is one (or more?) RPL instance that is used for 6TiSCH
>> > timing. I think all we need in 6top is an information of which RPL
>> > instance(s) is (are) used for timing and hten the admin can read the
>> > RPL info about that insta
I agree, we are using RPL now, but we may use other protocols tomorrow.
Better we leave it opened.
Maria Rita
From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Pascal Thubert
(pthubert)
Sent: Wednesday, June 10, 2015 10:16 PM
To: Qin Wang; Michael Richardson; 6tisch@ietf.org
Subject: R
Hi Michael,
According to my understanding, there are two levels of synchronization in
6TiSCH network, i.e. (1) all nodes work on same ASN, which is presented in EB;
(2) the node corrects its clock periodically by communication with its
timesource. The description in TimeSource is about (2).
make
Hi Michael
>
> > OTOH, there is one (or more?) RPL instance that is used for 6TiSCH
> > timing. I think all we need in 6top is an information of which RPL
> > instance(s) is (are) used for timing and hten the admin can read the
> > RPL info about that instance in the RPL data model
Same here.
Cheers,
Pascal
From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Qin Wang
Sent: mercredi 10 juin 2015 13:04
To: Michael Richardson; 6tisch@ietf.org
Subject: Re: [6tisch] 6top and neighbour list
Hi Michael,
Regarding to including DAG rank into 6top NeighborList, I think, be
That is exactly right, Qin.
Cheers,
Pascal
From: Qin Wang [mailto:qinwang6...@yahoo.com]
Sent: mercredi 10 juin 2015 12:19
To: Pascal Thubert (pthubert); Michael Richardson; 6tisch@ietf.org
Subject: Re: [6tisch] 6top and neighbour list
Hi Pascal,
What you say is that the RPL parents list shoul
Hi Michael,
Regarding to including DAG rank into 6top NeighborList, I think, besides RPL,
there may be other routing protocols working on top of 6top in the future.
Thus, it could be better to decouple 6top sublayer and upper layer protocol
like RPL.
What do you think?
What other people think?
Hi Pascal,
What you say is that the RPL parents list should be in RPL data model (YANG
model), and 6top data model only includes the parent used as time source.
Right? It really makes sense to me.
ThanksQin
On Thursday, June 11, 2015 12:45 AM, Pascal Thubert (pthubert)
wrote:
#y
Pascal Thubert (pthubert) wrote:
> A node has a list of RPL parents per RPL instance. But that’s a RPL
> problem and we probably need a RPL data model to be done at ROLL.
yes, so I'm considering whether the RPL data model can take this from the
6tisch model, because we badly need a stand
Hi Pascal.
If we move ahead with the solution discussed between myself and Alexander,
aliases won’t save much space and are not worth it.
The solution is based on the following principles:
· Data nodes are identified using a 20 bits registered module
identifier and a 10 bits assigned Y
Hello Qin:
A node has a list of RPL parents per RPL instance. But that’s a RPL problem and
we probably need a RPL data model to be done at ROLL.
OTOH, there is one (or more?) RPL instance that is used for 6TiSCH timing. I
think all we need in 6top is an information of which RPL instance(s) is (a
Dear all:
This looks like the problem of local namespaces, which is the reason why MPLS
switches labels.
The user may access a limited set of resources from a number of servers, and
servers are read by many users.
You cannot ensure that you have a single alias space that satisfies them all.
So
Qin Wang wrote:
> NeighborList contains the Link information, and the information about
> Parent is contained in TimeSource for saving space. Make sense?
I don't see how container TimeSource will give me a list of parents.
leaf NodeAddress {
type nodeaddresstype;
Qin, your file is the 2015-03-04 version, while Michel forwarded the
2015-01-01 revision.
I looked into the bitbucket for the ietf-6top.yang file, and not seeing
is split out, I'll send you a pull request via bitbucket.
I guess you live on windows, so I can't assume you have any useful tools,
but
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
Hi Pat,
Thanks! I see your concerns.
Let us hope we will have advanced IoT controllers, similar to WLAN controllers,
which manage and provide a deterministic and efficient 6tisch network!
Anand
On Tue, 9 Jun 2015, Pat Kinney wrote:
Anand;
You raise valid points and in a professionally inst
Thomas,
Yes. I would think a change to the 6top interface MIB should do. Michel's
idea of using BEACON IE for the joining nodes is very interesting to pursue.
Anand
On Tue, 9 Jun 2015, Thomas Watteyne wrote:
Anand,
Possibly useful, and I believe a small change to the 6top interface.
Thomas
Hi Michel,
Yes, I agree with you.
Thanks!
Anand
On Tue, 9 Jun 2015, Michel Veillette wrote:
Hi Anand
About "Does it make sense to use the BEACON IE approach when the node joins the
network and let an external centralized controller (NME), use the 6top MIB interface to
subsequently manage
19 matches
Mail list logo
