Since I'm working with Pascal on the Backbone Router (BbR)
draft/concept, I agree and like the idea that if the lowpan is connected
to the internet there will be something like a BbR and it would be a
natural place to have the "white board".
I don't necessarily agree that multicast for sleepy nodes is really any
more complex than it is for non-sleepy nodes when the underlying network
doesn't support multicast.
My other concern about relying on the BbR for ND type service is if the
network is installed without an Internet connection (or BbR).
geoff
On Fri, 2007-12-07 at 11:17 +0100, Pascal Thubert (pthubert) wrote:
> Hi
>
> I tend to agree with Tim here; multicast is a complex issue in the low
> power / sleepy space. It's even unclear which WG should be responsible
> to define it.
>
> Back to basics, there are basically 2 extreme models to locate somebody;
> cry out loud or white board. ND on Ethernet uses the first model based
> on multicast. Mobile IP uses the second. When you look up a mobile node
> on the Home Link, the Home Agent is the reference that responds the ND
> requests on behalf of the mobile nodes.
>
> So my question is: Should we take as granted that ND on the LoWPAN
> requires multicast? Maybe the white board model based on unicast is
> enough, in which case we get rid of a very difficult dependency.
> Considering that there is a need for a router that understands 6LowPAN
> to connect the LoWPAN to the Internet, that router is the natural
> location for a white board.
>
> So the concept of backbone router is this: cry out loud on the high
> speed backbone that federates LoWPANs, and white board on the LoWPAN,
> and ND proxying to federate the whole thing. The backbone router
> implements ND proxying in a fashion that is compatible with mobile IP so
> one day, sensors with a global address can move away and stay virtually
> there.
>
> In the meantime, a link local address is enough to connect to any node
> in the network federated by backbone routers, and a mote can move from a
> backbone router to another within the federated network without
> renumbering.
>
> The story begins in
> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router
> -00.txt :)
>
> Pascal
>
>
> >-----Original Message-----
> >From: Timothy J. Salo [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, December 06, 2007 11:11 PM
> >To: 6lowpan
> >Subject: Re: [6lowpan] ND optimization for sensor nodes (power
> >saving/ Idle/Sleep mode)
> >
> >Samita Chakrabarti wrote:
> >> ... That way, periodic RA will not wake up all the nodes in the
> >> 6lowpan. ...
> >
> >To the best of my knowledge, 802.15.4 implementations
> >power-down the radio when the system sleeps. As such, a
> >broadcast packet does not wake a sleeping 802.15.4 node.
> >Rather, the packet is simply never received by the sleeping node.
> >
> >If my understanding about this behavior is incorrect, someone
> >please correct me. I have been meaning to check and see what
> >the spec says about this, but haven't yet...
> >
> >Given that the response to broadcast packets differs in 802.16
> >networks (where an idle node wakes to process the packet) and
> >802.15.4 networks (where a sleeping node is never even aware
> >of the packet), different solutions are probably required.
> >
> >To reiterate what I have said before, I believe that we must
> >explicitly specify the behavior we expect of multicast in
> >6lowpan networks that contain sleeping nodes. In particular,
> >does multicast mean "received by the potentially very small
> >percentage of the nodes that aren't currently sleeping" or
> >might it mean "received by every node after they wake up
> >[whenever day that might be]"? After we specify the behavior
> >of multicast, then we can then try to figure out whether we
> >can actually implement that behavior in a useful way.
> >
> >In the interim, I suggest a moratorium on simply assuming that
> >multicast is a potential solution to any of the challenges we
> >face (e.g., duplicate address detection, router announcements,
> >neighbor discovery, ...)
> >
> >-tjs
> >
> >
> >
> >_______________________________________________
> >6lowpan mailing list
> >[email protected]
> >https://www1.ietf.org/mailman/listinfo/6lowpan
> >
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
