Hi Pascal,
Yes, I do see a bunch of cases where BrB and "white-board" may make a
lot of sense. But, we're drifting a bit from the genesis of this
discussion. The proposed statement from Tim was to place a moratorium on
the use of multicast in proposed solutions. My suggestion is that this
statement is over constraining. One such example where multicast may be
useful is in route-over networks. Link-local multicast only has a scope
of a single radio transmission hop and is often done by either
implementing or emulating broadcast at L2, which most energy-management
protocols for 802.15.4 support.
--
Jonathan Hui
Pascal Thubert (pthubert) wrote:
Hi Jonathan and Geoff:
This makes sense to me. Now;
The BrB draft is 2 fold; part of it is routing from to the backbone and the Internet; and part of it is white board concept applied to 6LoWPAN. We could separate the features in 2 drafts, but it seems simpler to specify that the implementation of the proxy part towards the backbone be required only when there is a backbone in the first place.
It also seems that the white board is a good approach regardless of whether we
have a backbone or not, considering the very nature of the LoWPAN. We can do a
very refined multicast support and try to approach the energy cost and latency
that we get with the white board model; but it seems to me that the nearest to
that grail we could get, the more states we'd add in nodes all around, and
still we'd never get as good as white board. I've no handy proof of this
assertion, but I'd be surprised and quite interested to be proven wrong.
Also, it makes sense that the behavior of the motes be the same whether there's
a backbone or not; if we recognize the need for the backbone router for a
number of supported situations, and if we agree that the white board approach
enables the registration for the proxy function transparently, then isn't it
the fair approach overall?
In all of the architectures and deployments I've seen, there is always a
special box, called a sink, a router, a manager or a gateway, that plays a
central role for the LoWPAN. The case when that special box does not exist
seems really remote, so we can quite safely assume that the special box exists
and is a good candidate for the white board.
Does that make sense?
Pascal
-----Original Message-----
From: Jonathan Hui [mailto:[EMAIL PROTECTED]
Sent: vendredi 7 décembre 2007 23:20
To: Pascal Thubert (pthubert)
Cc: Timothy J. Salo; 6lowpan
Subject: Re: [6lowpan] ND optimization for sensor nodes (power
saving/ Idle/Sleep mode)
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-rout
er
-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
