Subject: [6lowpan] Comments on draft-dokaspar-6lowpan-routreq-02

From: JP Vasseur <[email-masked]>
Date: Tue, 17 Jul 2007 19:27:43 -0400

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-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "Dominik Kaspar" <[email-masked]>
Date: Wed, 18 Jul 2007 17:03:00 +0900

Dear JP,

Thanks for your valuable comments on our draft.
Answers are ==> inline.

Best regards,
Dominik

----------------------------------------

Dear Coauthors,

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.

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

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
   error messages should be avoided for minimizing the overall number of

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

==> 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

==> 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-masked]> wrote:
> 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 ...
>
> 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
>
> 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
>    error messages should be avoided for minimizing the overall number of
> * 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
> * 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
>
>    considered by LoWPAN mesh routing protocols.  It is also assumed that
>    nodes participating in LoWPAN mesh routing are assigned only a single
> Just a note here to mention that L2Ns will more than likely support multiple

---

From: Mark Townsley <[email-masked]>
Date: Wed, 18 Jul 2007 16:53:14 +0200

dculler wrote:
> 5. History suggests that once IP routing is available for a particular 
> kind of link, sub-IP routing tends to dissappear.  Remember x.25 and 
> frame relay.  Of course, we do some form of "mesh" routing in switched 
> ethernets and mesh wifi, but generally it is transparent.  The link 
> looks like the unswitched counterpart.
Why would a 6lowpan "route under" solution not look similar to 802.11s 
or TRILL?

- Mark

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 18 Jul 2007 10:25:14 -0600

It might look similar to 802.11s, but right now there is nothing defined
for 802.15.4 like 802.11s.  There is an 802.15.5 group working on this
and it's solution may be just the "mesh under" soltion 6lowpan needs.

I'm not at all sure about how TRILL would or could fit.

	geoff

On Wed, 2007-07-18 at 16:53 +0200, Mark Townsley wrote:
> RSN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rsn

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 18 Jul 2007 12:03:29 -0600

Very interesting and provocative question you pose at the end of your
message - "do we need mesh under?" I think and hope that this will
generate some discussion on the list. 

I suspect that there are people on the list that will argue that mesh
under is fact (it is deployed today) and that of course we need mesh
under and will use standard layer 3 routing between 6lowpan subnets.
Currently this is the thinking within SP100 for industrial wireless.

802.15.5 is certainly looking at and, I think, plans to standardize on a
two different mesh under designs/protocols.

Utilizing trill is an interesting thought.  I don't yet know enough
about trill to comment on it's applicability.

Certainly the manet protocols might be applicable.

What is critical to this discussion is that if 6lowpan does not select
or generate a mesh under protocol (if one is necessary and used) then
there will not be interoperability between multi-hoping nodes.  If
mesh-under is not used (but router over is used for multi-hopping) then
all 6lowpan nodes can exchange packets and forward packets (but we need
to understand the implications of one node per subnet).

	geoff

On Wed, 2007-07-18 at 06:53 -0700, dculler wrote:
> The argument for route-over is pretty simple.
>  
> 1. In the vast majority of wireless sensor networks in existance the
> dominant communication pattern is data collection (from nodes in the
> PAN to IP-based computers external to the PAN) and control actions
> (from controllers external to the PAN to devices within the PAN).
> There are cases where data collection point and/or the controller is a
> gateway device on the PAN, but this physical collocation is rather
> artificial.  If is far more typical that where a gateway is deployed
> it is used to bridge communication to other networks.  
>  
> This is true not only for wireless instrumentation, but wired
> instrumentation as well.  See for example
>  
> BACNET: http://www.bacnet.org/Tutorial/HMN-Overview/sld028.htm and
> http://www.bacnet.org/Tutorial/HMN-Overview/sld029.htm 
>  
> and
>  
> HART:
> http://www.hartcomm2.org/hart_protocol/tech_info/eval_networks/compnet.html
>  
> and Wireless HART
>  
> http://www.hartcomm2.org/hart_protocol/wireless_hart/architecture.html
>  
> Routing onto or off the PAN utilizes a routable IP address for the
> device within the PAN.  It is important for this address to be
> compressible, just as when both endpoints are within the PAN.  No
> matter how effective is the L2 mesh routing within the PAN, you still
> need to deal with IP routing off the PAN.  This is, of course, the
> purpose of IP routing.  Whatever mesh-under is done, there will also
> be route-over.  The mesh-under path is, at least, one of the
> route-over hops.  Possibly more of the IP hops may occur over 802.15.4
> links.
>  
> 2. It is very common that devices route between distinct networks that
> use the same media, ie. distinct Ethernet subnets or distinct WiFi
> subnets.  This will happen in 802.15.4 networks where the networks use
> the same physical link, but different PAN_IDs, different channels (or
> different sets of channels or different channel schedules), different
> MAC layers, etc.  Even different meshing protocols.  They will be
> stiched together by IP routing.
>  
> 3. The Mesh-under protocol is currently undefined.  6lowpan is
> sufficient to describe single hop communication.  It also identifies
> the endpoints (original and final) of multihop mesh-routed
> communication, but it does not define how the intervening hops are
> determined or what information is exchanged to establish
> routes.  Clearly it anticipates that such L2 protocols will be
> developed and standardized.  However, if a single 802.15.4 hop is
> performed per IP hop, any L3 routing algorithm can be used to set up
> the routing tables and forwarding occurs according to the routing
> tables.  (Worst come to worst, you can hammer the tables in place by
> external means.) If mesh routing does become defined, IP routing can
> be applied per L2 mesh path.  Thus, IP routing applies whether or not
> mesh routing is defined.  All of the IP visibility and management
> tools apply to the IP hops.  None of them apply to the mesh hops
> within an IP hop.
>  
> 4. Many IP routing protocols are defined and a diversity of protocols
> has become the norm.  One of the key elements of IP is that it
> separates routing from forwarding.  We tolerate the use of different
> routing protocols in different settings.  These protocols set up the
> tables and forwarding works across them.  We have had multiple
> competing routing protocols apply to the same setting (e.g., RIP vs
> OSPF in the campus area) and their relative strengths have become
> clear over time.  
>  
> This has not been the case with link-level "meshing"; so far it has
> been approached as a winner-take-all and unfortunately this means that
> everybody must agree on the protocol before they have much experience
> with the use of the protocol.  For example, in Zigbee we have seen
> that after several years of development, but no broad usage, Zigbee
> 1.0 is obsoleted in favor of Zigbee 2006, which is incompatible and
> also incompatible with Zigbee 2007, which is not yet fully defined.
> We have seen numerous proprietary protocols, proprietary extensions to
> standard protocols, and open research protocols for meshing that are
> all incompatible.  In some cases they optimize for different aspects,
> in some cases they integrate aspects of all layers of the stack.  In
> any case, they don't play well together. So, one of the key virtues of
> route-over is that we have an established framework and long history
> of stiching together a variety of routing protocols to establish the
> tables such that forwarding works across them and where we can gain
> experience over time.  Call it "rough consensus and running code".
>  
> One might argue these aspects are sociological, rather than technical.
> Well, the separation of topology formation, path selection, and route
> table maintainance from forwarding is awfully important.  So are the
> vast set of tools to gain visibility into IP routing.  At the very
> least, source routing, exploration, etc. will need to be developed for
> the PAN for mesh-under to mature.  It is an interesting question
> whether you need to be within the PAN to utilize the equivalent of
> traceroute.
>  
> So I think it is very clear that IP routing will occur over IEEE
> 802.15.4 links.  It is already there.  For every single hop 15.4
> network it is done.  For deeper networks, there are many ways to set
> up the tables.   
>  
> So route-over is a fact.  The question should be "Do you need
> mesh-under in addition to route-over?"  Why?
>  
> 
>         
>         ______________________________________________________________
>         From: JP Vasseur [mailto:[email-masked]] 
>         Sent: Tuesday, July 17, 2007 4:28 PM
>         To: Dominik Kaspar
>         Cc: 6lowpan; [email-masked]
>         Subject: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02
>         
>         
>         
>         Dear Coauthors, 
>         
>         
>         solutions. If the answer turns out to be "yes, we need both" I
>         would volunteer to write the ID capturing the pros and
>         cons ... 
>         
>         
>         "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
>         
>         
>         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

---

From: "Dominik Kaspar" <[email-masked]>
Date: Fri, 20 Jul 2007 18:40:58 +0900

Hello Geoff,

> [Geoff]:
> So route-over is a fact.  The question should be "Do you need mesh-under in
> addition to route-over?"  Why?

This is indeed an interesting question.
Here are some of my thoughts on the argument for "mesh-under" routing:

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.

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.

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.

4.) Continuing the 6lowpan work:

The 6lowpan WG has decided to specialize and build on top of IEEE
802.15.4 networks. It is therefore straightforward to utilize this
existing framework for building an energy-optimized "mesh-under"
routing solution that exploits link-layer feedback.

Best regards,
Dominik

On 7/18/07, dculler <[email-masked]> wrote:
> dominant communication pattern is data collection (from nodes in the PAN to
> IP-based computers external to the PAN) and control actions (from
> controllers external to the PAN to devices within the PAN).  There are cases
> where data collection point and/or the controller is a gateway device on the
> PAN, but this physical collocation is rather artificial.  If is far more
> typical that where a gateway is deployed it is used to bridge communication
> to other networks.
>
> BACNET:
> http://www.bacnet.org/Tutorial/HMN-Overview/sld028.htm and
> Routing onto or off the PAN utilizes a routable IP address for the device
> within the PAN.  It is important for this address to be compressible, just
> as when both endpoints are within the PAN.  No matter how effective is the
> L2 mesh routing within the PAN, you still need to deal with IP routing off
> the PAN.  This is, of course, the purpose of IP routing.  Whatever
> mesh-under is done, there will also be route-over.  The mesh-under path is,
> at least, one of the route-over hops.  Possibly more of the IP hops may
> occur over 802.15.4 links.
>
> 2. It is very common that devices route between distinct networks that use
> the same media, ie. distinct Ethernet subnets or distinct WiFi subnets.
> This will happen in 802.15.4 networks where the networks use the same
> physical link, but different PAN_IDs, different channels (or different sets
> of channels or different channel schedules), different MAC layers, etc.
> Even different meshing protocols.  They will be stiched together by IP
> routing.
>
> 3. The Mesh-under protocol is currently undefined.  6lowpan is sufficient to
> describe single hop communication.  It also identifies the endpoints
> (original and final) of multihop mesh-routed communication, but it does not
> define how the intervening hops are determined or what information is
> exchanged to establish routes.  Clearly it anticipates that such L2
> protocols will be developed and standardized.  However, if a single 802.15.4
> hop is performed per IP hop, any L3 routing algorithm can be used to set up
> the routing tables and forwarding occurs according to the routing tables.
> (Worst come to worst, you can hammer the tables in place by external means.)
> If mesh routing does become defined, IP routing can be applied per L2 mesh
> path.  Thus, IP routing applies whether or not mesh routing is defined.  All
> of the IP visibility and management tools apply to the IP hops.  None of
> them apply to the mesh hops within an IP hop.
>
> 4. Many IP routing protocols are defined and a diversity of protocols has
> become the norm.  One of the key elements of IP is that it separates routing
> from forwarding.  We tolerate the use of different routing protocols in
> different settings.  These protocols set up the tables and forwarding works
> across them.  We have had multiple competing routing protocols apply to the
> same setting (e.g., RIP vs OSPF in the campus area) and their relative
> strengths have become clear over time.
>
> This has not been the case with link-level "meshing"; so far it has been
> approached as a winner-take-all and unfortunately this means that everybody
> must agree on the protocol before they have much experience with the use of
> the protocol.  For example, in Zigbee we have seen that after several years
> of development, but no broad usage, Zigbee 1.0 is obsoleted in favor of
> Zigbee 2006, which is incompatible and also incompatible with Zigbee 2007,
> which is not yet fully defined.  We have seen numerous proprietary
> protocols, proprietary extensions to standard protocols, and open research
> protocols for meshing that are all incompatible.  In some cases they
> optimize for different aspects, in some cases they integrate aspects of all
> layers of the stack.  In any case, they don't play well together. So, one of
> the key virtues of route-over is that we have an established framework and
> long history of stiching together a variety of routing protocols to
> establish the tables such that forwarding works across them and where we can
> gain experience over time.  Call it "rough consensus and running code".
>
> Well, the separation of topology formation, path selection, and route table
> maintainance from forwarding is awfully important.  So are the vast set of
> tools to gain visibility into IP routing.  At the very least, source
> routing, exploration, etc. will need to be developed for the PAN for
> mesh-under to mature.  It is an interesting question whether you need to be
> within the PAN to utilize the equivalent of traceroute.
>
> 5. History suggests that once IP routing is available for a particular kind
> of link, sub-IP routing tends to dissappear.  Remember x.25 and frame relay.
>  Of course, we do some form of "mesh" routing in switched ethernets and mesh
> wifi, but generally it is transparent.  The link looks like the unswitched
> counterpart.
>
> So I think it is very clear that IP routing will occur over IEEE 802.15.4
> links.  It is already there.  For every single hop 15.4 network it is done.
> For deeper networks, there are many ways to set up the tables.
>
> So route-over is a fact.  The question should be "Do you need mesh-under in
> addition to route-over?"  Why?
>
>
> ________________________________

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 20 Jul 2007 09:50:21 -0700

> 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.

> 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.

> realistic architectural element for efficient sensor network

[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-masked]

---

From: JP Vasseur <[email-masked]>
Date: Fri, 20 Jul 2007 21:34:05 -0400

Hi Dominik,

> Thanks for your valuable comments on our draft.

Fully agree.

> 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.

> ==> Yes, as we have discussed before, I well understand your concern.

OK.

> we need to design a new one.

Well does not have to be in the ID then but thanks for the  
clarification.

> difference between "mesh-under" and "route-over".

Stay tuned ... we should get the first draft soon, to which comments/ 
contribution
will be very welcome.

> 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.

> 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

I see, not sure this should be mentioned in the requirement document.

Thanks.

JP.

>> whether we
>> under"
>> protocol

---

From: JP Vasseur <[email-masked]>
Date: Fri, 20 Jul 2007 21:45:13 -0400

Adding a few comments ...

On Jul 18, 2007, at 9:53 AM, dculler wrote:

> 1. In the vast majority of wireless sensor networks in existance  
> the dominant communication pattern is data collection (from nodes  
> in the PAN to IP-based computers external to the PAN) and control  
> actions (from controllers external to the PAN to devices within the  
> PAN).  There are cases where data collection point and/or the  
> controller is a gateway device on the PAN, but this physical  
> collocation is rather artificial.  If is far more typical that  
> where a gateway is deployed it is used to bridge communication to  
> other networks.
>
> HART: http://www.hartcomm2.org/hart_protocol/tech_info/ 
> eval_networks/compnet.html
>
> and Wireless HART
>
> matter how effective is the L2 mesh routing within the PAN, you  
> still need to deal with IP routing off the PAN.  This is, of  
> course, the purpose of IP routing.  Whatever mesh-under is done,  
> there will also be route-over.  The mesh-under path is, at least,  
> one of the route-over hops.  Possibly more of the IP hops may occur  
> over 802.15.4 links.
>
> 2. It is very common that devices route between distinct networks  
> that use the same media, ie. distinct Ethernet subnets or distinct  
> WiFi subnets.  This will happen in 802.15.4 networks where the  
> networks use the same physical link, but different PAN_IDs,  
> different channels (or different sets of channels or different  
> channel schedules), different MAC layers, etc.  Even different  
> meshing protocols.  They will be stiched together by IP routing.
>

In which case, multi-hop routing where hops are interconnected by PAN  
where mesh-under routing take place
lead to Inconsistent Routing. It is then very difficult to optimize  
the path with regards to a specific metric since there
is no to way to have a consistent end to end view.

> sufficient to describe single hop communication.  It also  
> identifies the endpoints (original and final) of multihop mesh- 
> routed communication, but it does not define how the intervening  
> hops are determined or what information is exchanged to establish  
> performed per IP hop, any L3 routing algorithm can be used to set  
> up the routing tables and forwarding occurs according to the  
> routing tables.  (Worst come to worst, you can hammer the tables in  
> place by external means.) If mesh routing does become defined, IP  
> routing can be applied per L2 mesh path.  Thus, IP routing applies  
> whether or not mesh routing is defined.  All of the IP visibility  
> and management tools apply to the IP hops.  None of them apply to  
> the mesh hops within an IP hop.
>
> 4. Many IP routing protocols are defined and a diversity of  
> protocols has become the norm.  One of the key elements of IP is  
> that it separates routing from forwarding.  We tolerate the use of  
> different routing protocols in different settings.  These protocols  
> set up the tables and forwarding works across them.  We have had  
> multiple competing routing protocols apply to the same setting  
> (e.g., RIP vs OSPF in the campus area) and their relative strengths  
> have become clear over time.
>
> been approached as a winner-take-all and unfortunately this means  
> that everybody must agree on the protocol before they have much  
> experience with the use of the protocol.  For example, in Zigbee we  
> have seen that after several years of development, but no broad  
> usage, Zigbee 1.0 is obsoleted in favor of Zigbee 2006, which is  
> incompatible and also incompatible with Zigbee 2007, which is not  
> yet fully defined.  We have seen numerous proprietary protocols,  
> proprietary extensions to standard protocols, and open research  
> protocols for meshing that are all incompatible.  In some cases  
> they optimize for different aspects, in some cases they integrate  
> aspects of all layers of the stack.  In any case, they don't play  
> well together. So, one of the key virtues of route-over is that we  
> have an established framework and long history of stiching together  
> a variety of routing protocols to establish the tables such that  
> forwarding works across them and where we can gain experience over  
> time.  Call it "rough consensus and running code".
>
> One might argue these aspects are sociological, rather than  
> technical.  Well, the separation of topology formation, path  
> selection, and route table maintainance from forwarding is awfully  
> important.  So are the vast set of tools to gain visibility into IP  
> routing.  At the very least, source routing, exploration, etc. will  
> need to be developed for the PAN for mesh-under to mature.  It is  
> an interesting question whether you need to be within the PAN to  
> utilize the equivalent of traceroute.
>
> 5. History suggests that once IP routing is available for a  
> particular kind of link, sub-IP routing tends to dissappear.   
> Remember x.25 and frame relay.  Of course, we do some form of  
> "mesh" routing in switched ethernets and mesh wifi, but generally  
> it is transparent.  The link looks like the unswitched counterpart.
>
> network it is done.  For deeper networks, there are many ways to  
> set up the tables.
>
> So route-over is a fact.  The question should be "Do you need mesh- 
> under in addition to route-over?"  Why?
>
>

Indeed, since we do need RL2N why would we need mesh-under (sorry I  
keep repeating myself here). I would
argue that having both would even be an issue, as pointed out above,  
not mentioning the operational complexity.

Cheers.

JP.
> would volunteer to write the ID capturing the pros and cons ...
>
> the requirement and that can be adapted, then great. But whether  
> any of the current

---

From: JP Vasseur <[email-masked]>
Date: Fri, 20 Jul 2007 21:54:10 -0400

Hi,

On Jul 20, 2007, at 12:50 PM, Jonathan Hui wrote:

> 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.
>
> [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.

>> 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
>> data to the gateway.

I must be missing your point ... why ?

>> Such a gateway is not an artificial, but a very
> [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.