> > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > > registrations do when strict ordering is not guaranteed (MIP being an > > example). Say that due to some config, a node registers a lifetime of > > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > > rapid sequence, but does not get an answer yet. Then it finally gets 2 > > AROs back, lifetime X and 0. What's the final state in the router? > > If the host changes its mind, then it would make sense for it to first listen to > the ack/nak of its previous instructions before issuing a new registration. > > I don't see this as a difficult restriction, because I think that it will be rare that > a host can't decide whether it will register or unregister.
[Pascal] Decoupling from L2 capability should serve us well also, shouldn't it? In mesh under: - you do not have end to end ack - you will have multipath - you will have out of order packets ND needs a TID. Pascal > Erik > > > I'd like to hear what others think. > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > > > >> -----Original Message----- > >> From: Dijk, Esko [mailto:[email protected]] > >> Sent: Monday, April 18, 2011 10:19 AM > >> To: Erik Nordmark; Pascal Thubert (pthubert) > >> Cc: [email protected] > >> Subject: RE: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" > >> flag > > in > >> ARO] > >> > >> Hello Erik, > >> > >> taking the definition you quoted: > >> 'host' refers to an LLN device that can generate but does not > > forward > >> RPL traffic > >> > >> the question may arise what is "RPL traffic"? It is not defined in > >> the > > RPL draft > >> it seems. Pascal clarified to me it is traffic associated to a RPL > > instance, not > >> necessarily RPL protocol messages. This means that a host could > > generate > >> RPL traffic without being aware of the existence of RPL at all. So, > > _not_ all > >> hosts have to speak RPL? > >> The RPL draft does not explicitly state if "hosts" in a RPL network > > always > >> speak RPL, never speak RPL, or can be mixed RPL/non-RPL speakers. > >> > >> Taking the definition of 'node' in the RPL draft: > >> 'node' refers to any RPL device, either a host or a router > >> > >> rules out (?) the option that all "hosts" are non-RPL speakers, since > > there > >> may be a "RPL device" (i.e. RPL-speaking device, I assume) that is > > also a host. > >> > >> I communicated these perceived unclarities to Pascal and the RFC > > editor 2 > >> weeks ago. Once this is clear I think the present discussion can > > continue. > >> And then there is the related discussion of ND support for sleepy > > devices, > >> the original topic of Anders ;) > >> > >> best regards, > >> > >> Esko > >> > >> > >> > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Erik Nordmark > >> Sent: Friday 15 April 2011 18:39 > >> To: Pascal Thubert (pthubert) > >> Cc: [email protected] > >> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" > >> flag > > in > >> ARO] > >> > >> On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > >> > >>> RPL can do what all classical IGPs can do WRT hosts. That is as long > >>> as the host address belongs to the router's prefix and stays > > attached > >>> to that router. > >> > >> I just realized that we might be talking about a different definition > > of "host". > >> What I mean by "host" is a node which does not participate in a > > routing > >> protocol, and does not forward packets (except packets explicitly > > addressed > >> to itself using e.g., a routing header). > >> > >> However, RPL has a different definition: > >> 'host' refers to an LLN device that can generate but does not > > forward > >> RPL traffic > >> > >> Basically per the RPL definition there is no such thing as a node > > which does > >> not participate in the RPL protocol. > >> IMHO what is in RPL should have been defined as a non-forwarding > >> node, > > so > >> that we can have a sane discussion without getting entangled in > > terminology > >> issues. > >> > >> Which definition of "host" are you using above? > >> > >> Per the RPL definition there is no need for 6lowpan-nd, since all > > nodes will > >> speak RPL. This is rather confusing, don't you think? > >> > >> Erik > >> > >>> When the topology becomes multilink subnet and mobility is required > >>> then it is a new problem entirely, and NO, 4861 is not a suitable > >>> interaction with the router to allow the router to redistribute a > > host route. > >>> Because the neighbor cache that 4861 builds is not a of the same > >>> nature as the binding table that 6LoWPAN ND builds. Another thing > > that > >>> 6LoWPAN ND fails to express correctly. I proposed text to explain > > that > >>> (attached) but it was not considered, contributing to the illusion > >>> that a cache is a table. > >>> > >>> The reality is also that those networks will need to scale to large > >>> subnets in plants, building, etc... (see the requirement drafts in > >>> ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > >>> requires a coordination between LBRs but does not say how it > > happens. > >>> This problem was discussed in 6LoWPAN; the answer was in ND-01to07; > >>> and it requires a TID, for the same reason as RPL. Removing the > >>> backbone operation and the TID from the draft is ostrich policy. > >>> > >>> RPL already adapted to the new reality of large multilink subnet > > with > >>> inner mobility. Placing the blame on RPL is another illusionist > > trick. > >>> And this is not RPL last call. > >>> > >>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all > > other > >>> registrations do when strict ordering is not guaranteed (MIP being > > an > >>> example). Say that due to some config, a node registers a lifetime > > of > >>> X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > >>> rapid sequence, but does not get an answer yet. Then it finally gets > > 2 > >>> AROs back, lifetime X and 0. What's the final state in the router? > >>> > >>> It seems we can never agree on any of this. I'd like to hear what > >>> others think. > >>> > >>> Pascal > >>> http://www.xtranormal.com/watch/7011357/ > >>> > >>> > >>>> -----Original Message----- > >>>> From: [email protected] [mailto:[email protected]] > On > >>>> Behalf Of Erik Nordmark > >>>> Sent: Friday, April 15, 2011 1:30 AM > >>>> To: 6lo>> '6lowpan' > >>>> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO > >>>> > >>>> > >>>> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote: > >>>>> Hi Erik: > >>>>> > >>>>> The RPL (DAO) sequence number allows the node to increment > rapidly > >>>>> in case of rapid changes and then lazily when the situation is > >>>>> stable and DAO are scarce. The increase is strictly monotonous > > which > >>> > >>>>> is critical to us. > >>>>> > >>>>> A time stamp imposes a synchronization between the routers. We do > >>>>> not have such mechanism in RPL. A time unit (a granularity) must > > be > >>>>> agreed upon. Within that unit, movements go undetected so the time > >>>>> unit must be thin grained to cover rapid changes. Yet, depending > > on > >>>>> the medium, the time unit, and the size of the network, it is not > >>>>> necessarily easy/possible to guarantee a strictly monotonous value > >>>>> with a thin grained time unit. And we have limited space (2 > > octets) > >>>>> and have to deal with wrap around, which divides the space by at > >>> least 3. > >>>>> > >>>>> So RPL went for a sequence number. > >>>> > >>>> But the unstated assumption that RPL made is that all > > host-to-router > >>>> protocols have to now be RPL aware. That doesn't sound like good > >>> design. > >>>> A host isn't aware of whether the routers speak IS-IS or OSPF, so > > why > >>>> do the hosts need to be aware of RPL by passing some TID around? > >>>> > >>>>> I think ND has the same need as MIP for a TID == Sequence # . We > >>>>> know of MIP; We know of RPL. We know of the backbone router > >>>>> operation. We know we'll need the TID and we know exactly why. I > >>>>> think we should have it in the 6LowPAN ND spec right away to avoid > >>>>> interop issues when we add RPL and BR operations. > >>>> > >>>> I don't see a need in 6lowpan-nd for a TID; the protocol works fine > >>> without it. > >>>> I think RPL needs to be improved to deal with reality. Isn't there > > a > >>>> desire for RPL to handle 4861 hosts? Those would never know about a > >>> TID. > >>>> > >>>> Erik > >>>> > >>>> _______________________________________________ > >>>> 6lowpan mailing list > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/6lowpan > >>> _______________________________________________ > >>> 6lowpan mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/6lowpan > >>> > >> > >> _______________________________________________ > >> 6lowpan mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/6lowpan > >> > >> The information contained in this message may be confidential and > > legally > >> protected under applicable law. The message is intended solely for > >> the addressee(s). If you are not the intended recipient, you are > >> hereby > > notified > >> that any use, forwarding, dissemination, or reproduction of this > > message is > >> strictly prohibited and may be unlawful. If you are not the intended > > recipient, > >> please contact the sender by return e-mail and destroy all copies of > > the > >> original message. > > > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
