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

[Kris Pister <[e-mail]>]

Geoff -
 what  would you call the 802.11s approach?  Is that mesh under or 
router over, or something in between?
 
David -
 >> 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)

I'm curious what data you have to support this assertion.  While I do 
believe that this may happen at some point in the future, I don't think 
that it's true today except in academic deployments.  Data collection 
yes, but not to IP-based computers.  When I look for commercial 
deployments in production, I see Eaton (Home Heartbeat) and Control 4 in 
home automation, and Emerson (Smart Wireless) in industrial.  Very few 
if any of these systems are hooked up to IP-based computers.

 >> History suggests that once IP routing is available for a particular
 >> kind of link, sub-IP routing tends to dissappear.

I don't know this history as well as you do, but I'm willing to bet that 
IP routing only gets successfully adopted on top of link technologies 
that actually work.

My concern with this group is that it seems to be based on the premise 
that the only reason why WSN isn't taking off quickly is that we haven't 
had IP addresses for our motes yet.  Do we really believe that Zigbee 
has had zero traction because it's not IP?  Do we really believe that 
there are no real TinyOS products because it's not IP?  Because that's 
not what customers and end users tell me.  They say that those 
technologies simply don't satisfy their requirements (typically 
reliability and power).
I'm looking forward to a world with IP-based motes and wsn routing.  But 
I don't think that it's going to happen unless we acknowledge that our 
success depends on more than just defining the right header compression 
and routing protocols.  We are intimately tied to L2 protocols in this 
space, and everyone to date who has ignored that has failed.

ksjp
Prof. EECS, UC Berkeley
Founder & CTO, Dust Networks

Geoff Mulligan wrote:
> 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.
>>  
>> 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: JP Vasseur [mailto:[e-mail]] 
>>         Sent: Tuesday, July 17, 2007 4:28 PM
>>         To: Dominik Kaspar
>>         Cc: 6lowpan; [e-mail]
>>         Subject: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02
>>         
>>         
>>         
>>         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.
>> _______________________________________________
>> RSN mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/rsn
>>     
>
>
>
> _______________________________________________
> RSN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rsn
>   

_______________________________________________
6lowpan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/6lowpan