Hi,
On Jul 20, 2007, at 12:50 PM, Jonathan Hui wrote:
Dominik Kaspar wrote:
1.) The ability to fully exploit 6lowpan's adaptation layer (header
compression for energy saving):
Link-level meshing has so far been approached as a winner-take-all,
but the dispatch value in 6lowpan's format allows for coexistence of
different mesh-under algorithms. Therefore, depending of the type of
sensor network, a differently optimized routing protocol could be
used, be it a reactive, proactive, data-aware, or a geographical one.
[jhui] IP has always supported multiple routing protocols, using
different Next Header values, UDP ports, etc. What's also
interesting is that mesh-under doesn't necessarily mean better
header compression. While LOWPAN_HC1 currently only supports
compression of link-local prefixes, 6LoWPAN doesn't preclude the
use of other methods to compress IP headers.
2.) To make use of link-layer feedback for route optimization:
The main characteristics of low-power networks is their
battery-operation and that the nodes "die" after battery
depletion. It
is therefore the main goal and number one priority to reduce energy
consumption in any way possible, and bringing the routing "under" the
IP-layer is one method of doing so. Examples include the possible
avoidance of DAD and simplified neighbor discovery using addresses
that are directly derived from globally unique MAC addresses.
[jhui] I don't see how using IDDs derived from universal-scope
tokens necessitates mesh-under. IIDs are independent from the
prefix, allowing the prefix to have link-local or global scope.
Route-over vs. mesh-under doesn't dictate whether we can avoid DAD
or address resolution. In fact, the mesh-under case may require
address resolution over multiple link hops. BTW, this is not a new
problem, and there is some work in the AUTOCONF WG to simplify ND
by using carefully constructed IPv6 addresses. This also ties into
a recent thread on this list.
[jhui] Utilizing link characteristics doesn't necessitate the use
of mesh-under, but in the route-over case it does mean you need to
standardize on a metric that is meaningful across links. In my
view, the latter would be an extremely useful goal.
Yes this is this ID Pascal and I are working on. Soon on this list
for comments ...
There's been some work in the NEMO WG to incorporate more link
information (i.e. energy, bandwidth, etc.) to make better informed
routing decisions.
Right.
3.) End-to-end communication is not expected for sensor networks:
Sensor networks are "edge networks" and should not be used as transit
networks and routing onto or off the PAN needs to consider energy
consumption. Packets should not be "blindly" routed in and out of a
PAN. Basically, in many sensor application scenarios there shouldn't
be anything going "directly into the PAN". Therefore, end-to-end
communication clearly is not a 'high priority' design principle for
sensor network nodes.
Well it really depends on what you mean by "Network". Sensor Networks
(and again I personally prefer to use the term "L2N" since some low
power devices are not sensor but actuators or just "things")
could be made of a number of nodes interconnected by a variety of links
with peer to peer communication. There are many such examples (e.g.
a remote control with home automation).
Packets that travel "to the PAN" are most likely
queries of some sort. A gateway/collection point/controller is a very
efficient way to handle such queries and to reply with cached data,
instead of burdening the entire PAN with routing overhead on each
single (maybe redundant) query. Therefore, mesh-under routing can be
applied in the most efficient way to periodically report new sensor
data to the gateway.
I must be missing your point ... why ?
Such a gateway is not an artificial, but a very
realistic architectural element for efficient sensor network
functionality.
[jhui] Again, I don't see why this is an argument for mesh-under.
Same comment
You make a good point that a "gateway/collection point/controller"
may be useful to reduce the load on LoWPAN networks. In more
traditional networks, we call these proxy caches and Akamai
wouldn't exist if it wasn't a good idea. Why should we require
proxy caches to operate on the same link? What if the application
utilizes multiple PANs (geographically spread apart or not), do we
really need one proxy cache per link? And of course, packets
shouldn't be "blindly" routed, but that's why we have firewalls. As
I see it, this is not a question of mesh-under vs. route over, both
can route traffic through proxies and firewalls, its a question of
how the routes are set up.
[jhui] IMO, a mesh-under proposal may be a quick way of getting
some form of routing in LoWPAN networks as it limits the scope of
what to consider when designing it. What is unclear to me is
whether a mesh-under proposal will be preferred over a well-
designed route-over proposal, which necessarily has a broader scope.
Thanks.
JP.
--
Jonathan Hui
[EMAIL PROTECTED]
_______________________________________________
RSN mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/rsn
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
