Dear Coauthors,
Few Comments on draft-dokaspar-6lowpan-routreq-02.
First of all, I think that we will need to have that debate on
whether we indeed need both a "Mesh-under" and a "Route over"
solutions. If the answer turns out to be "yes, we need both" I would
volunteer to write the ID capturing the pros and cons ...
In the meantime, here are a few comments:
1) I would suggest to use a consistent terminology for the "Mesh-
under" routing. Not trying to quibble on the terminology here but
this is quite important to avoid confusion with the RSN initiative.
"Lowpan mesh routing" looks more like Route over.
2) Section 2
These fundamental features of LoWPANs can affect the design of
routing solutions, so that existing routing specifications should be
simplified and modified to the smallest extent possible, in order to
fit the low-power requirements of LoWPANs.
We had that discussion before ... Yes, if one can find an existing
protocol that meets
the requirement and that can be adapted, then great. But whether any
of the current
protocols can be adapted to meet these requirements is not a given.
3) Section 2
In order to find energy-optimal routing paths, LoWPAN mesh routing
protocols should minimize power consumption by utilizing a
combination of the link quality indication (LQI) provided by the MAC
layer and other measures, such as hop count. Route repair and route
error messages should be avoided for minimizing the overall
number of
control messages and the required energy for sending them.
Two comments:
* This is a difference with Route-over where we will define IP metric
to reflect
the link characteristics to be used by the routing engine but we do
want to
remain layer 2 agnostic, thus the need for a minimal abstraction layer.
* Should we avoid "Route Repair" ? mmm ... I'm not so sure since
there are
applications that require fast rerouting to forward sensitive data. A
cheap
alternative is to compute disjoint paths but this comes at the path
quality
cost.
3) Section 3
Transparent IP routing between LoWPAN domains and higher layer
networks must be provided bidirectionally. A LoWPAN mesh routing
protocol must allow for gateways to forward packets out of the local
domain and it must be possible to query a LoWPAN device from outside
of the local domain. Strategies must be considered to avoid battery
depletion of nodes by too many queries from higher level networks.
End-to-end communication is not a design goal of LoWPAN.
This is one on my main motivations of a Route-over strategy.
4) Section 3.2
Because network layer routing imposes too much overhead for LoWPANs
JP> Which Routing protocol ?
and link layer techniques are out of scope of IETF, LoWPAN mesh
routing should be performed within the adaptation layer defined in
[3]. Both addressing modes provided by the IEEE 802.15.4 standard,
16-bit short addresses and 64-bit extended addresses, must be
considered by LoWPAN mesh routing protocols. It is also assumed
that
nodes participating in LoWPAN mesh routing are assigned only a
single
address/identifier and do not support multiple interfaces.
Just a note here to mention that L2Ns will more than likely support
multiple
interfaces thanks to multiple non overlapping frequencies.
Thanks.
JP.
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
