Hi Dominik,
On Jul 18, 2007, at 4:03 AM, Dominik Kaspar wrote:
Dear JP,
Thanks for your valuable comments on our draft.
Answers are ==> inline.
Best regards,
Dominik
----------------------------------------
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 ...
==> So far, in my view, mesh-under routing is a fast solution in a
single interface of IEEE 802.15.4. I see RSN (R2LN) as a broader
solution for sensor networks which is not limited to IEEE 802.15.4.
Fully agree.
So, IMO, both are needed, but, surely it would be good to make a
productive discussion on it, and your contribution would be valuable
in case we decide to keep working on mesh-under.
Ah but here is my point: since we do RL2N, that covers all cases, why
would we also need a mesh under routing solution ? In fact the issue is
not just to duplicate efforts here but more that we will unavoidably
end up
with network with both deployed, which will lead to consistency issues,
this is why I was referring to IP over ATM where running OSPF or ISIS
over ATM VCs that were routed using PNNI led to a myriad of issues.
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.
==> Agreed. I will read through and clarify the terminology.
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.
==> Yes, as we have discussed before, I well understand your concern.
OK.
It's for mentioning that it should be checked first if we can re-use
existing IETF solutions (although, not as it is, but with some
simplification). Surely, if we cannot find the applicable solutions,
we need to design a new one.
Well does not have to be in the ID then but thanks for the
clarification.
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.
==> Agreed. The development of routing metrics would be a significant
difference between "mesh-under" and "route-over".
Stay tuned ... we should get the first draft soon, to which comments/
contribution
will be very welcome.
* 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.
==> Right, it sounds a bit ambiguous. We wanted to say 'should be
minimized', as to avoid flooding from intermediate nodes for routing
repair. Thanks. We will rewrite the paragraph to make it clear.
Thanks ... Providing Route Repair will undoubtedly add a bit of
complexity
(I've never seen a "fast" recovery that comes for free) but this
might be
perfectly reasonable in light of the benefit.
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.
==> Yes. Currently, our view of R2LN's importance is interoperability
of sensor networks,
As pointed out before, this is of course not the only motivations.
and mesh-under for IEEE 802.15.4 is for within a
single interfaced network.
4) Section 3.2
Because network layer routing imposes too much overhead for LoWPANs
JP> Which Routing protocol ?
==> It's about the current situation. When we had some experiments
with current ad-hoc routing solutions, they have quite a numerous and
large routing packets, which use a lot of energy in sensor node.
That's what we meant.
I see, not sure this should be mentioned in the requirement document.
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.
==> Good. We will add it.
Thanks.
JP.
Thanks.
On 7/18/07, JP Vasseur <[EMAIL PROTECTED]> wrote:
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
