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. 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. 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. 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. 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". * 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. 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, 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. 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. 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
