Hi Pascal,
The backbone solution proposed in your draft targets a particular
configuration and we should definitely consider it. Though I strongly
believe that we are going to see different 6LoWPAN/802.15.4 network
configurations. There may be some that do not connect to the Internet
and do not require or cannot afford a router. There may be others that
choose a route-over approach vs. mesh-under. I just want to reiterate my
wish that we don't force the WG into a solution space that only covers a
particular 6LoWPAN/802.15.4 configuration. Instead, we should consider a
few representative configurations as Tim suggested. While it'd be great
to see a single solution satisfy all of them, we should be open to
having different ones if needed.
--
Jonathan Hui
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
