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. 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.
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. 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. 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. 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.
--
Jonathan Hui
[EMAIL PROTECTED]
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
