Re: [RSN] Update

"Timothy J. Salo" <salo@saloits.com> Tue, 05 June 2007 03:03 UTC

Return-path: <rsn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPKY-0003Nc-PW; Mon, 04 Jun 2007 23:03:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPKY-0003NO-2Y; Mon, 04 Jun 2007 23:03:34 -0400
Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvPKW-000484-GR; Mon, 04 Jun 2007 23:03:34 -0400
Received: from [127.0.0.1] (mpls.saloits.com [216.243.132.62]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l553347s091193; Mon, 4 Jun 2007 22:03:24 -0500 (CDT) (envelope-from salo@saloits.com)
Message-ID: <4664D24E.2000803@saloits.com>
Date: Mon, 04 Jun 2007 22:02:38 -0500
From: "Timothy J. Salo" <salo@saloits.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: rsn@ietf.org, 6lowpan@ietf.org
Subject: Re: [RSN] Update
References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> <46632986.3000401@saloits.com> <46632FB9.6080705@cisco.com>
In-Reply-To: <46632FB9.6080705@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc:
X-BeenThere: rsn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing Sensor Networks <rsn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rsn>
List-Post: <mailto:rsn@ietf.org>
List-Help: <mailto:rsn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe>
Errors-To: rsn-bounces@ietf.org

Mark Townsley wrote:
>> And finally, to do the job well, this group must look at more
>> than just routing issues (e.g., neighbor discovery and management
>> in low-power wireless networks).  We might consider:
>>
> This part should be part of the 6lowpan recharter. The idea amongst the 
> ADs has been to split off the routing portion of the work on low-power 
> networks to the routing area, and continue forward with work on ND, 
> bootstrapping, etc. within the int-area.

I strongly recommend that serious consideration be given to creating a
single working group that is responsible for both the routing and the
non-routing aspects of low-power wireless networks.  While it is
important to apply the IETF's routing expertise to these issues,
I believe that, in this arena, there is also a need for close
coordination between the routing solutions and the non-routing
solutions.

o  I believe that the IETF's low-power wireless network activity
    (both the routing and the non-routing portions) will
    benefit from (perhaps even require) outside experts and expertise.
    (i.e., people who don't traditionally attend IETF working group
    meetings).  I also believe that it will be much easier for these
    people to attend working group meetings if there is a single
    working group, rather than two.  Yes, we could have two working
    groups and promise that they will always meet on the same day.
    But, given the complexities of scheduling working group meetings,
    it seems much easier and much more reliable to simply have a
    single working group.  Groups I would like to see attend include:

    - Wireless Sensor Network (WSN) Research Commmunity - The WSN
      research community has considerable domain expertise that would
      benefit the IETF.  Furthermore, this community is developing
      routing protocols adapted to the unique needs of WSNs that are
      radically different than anything the IETF is thinking about
      (e.g., protocols that propagate _only_ a default route, and
      enable nodes to route packets to _only_ to an exit router or to
      immediately adjacent nodes; and protocols that enable at least
      some nodes to sleep most of the time).

    - Home Automation and Industrial Automation Vendors - These groups
      have strong ideas about their requirements and have developed
      some initial solutions.

    - Standards Bodies and Industry Consortiums - It is possible that
      some of these groups (e.g., ZigBee Alliance, IEEE etc.) might
      choose to send some representatives.

o I believe that low-power wireless networks are, in many respects,
   radically different than the networks with which the IETF has
   experience.  As a result, both those working on the routing and
   the non-routing aspects of this problem will need to collectively
   develop a detailed understanding of the of the unique characteristics
   of these environments.  Some of these unique characteristics have
   strong implications for the routing solutions (e.g., some nodes may
   sleep much of the time; some nodes may be severely energy-constrained,
   while other nodes may be mains-powered; nodes may have [at least in
   academic discussions] thousands of neighbors]).  It would be useful
   for the routing and non-routing participants to develop this domain
   expertise jointly, rather than have after-the-fact discussions of the
   form: But, you didn't tell us about _that_ requirement...

o Finally, I believe that there must be much closer collaboration
   between the routing and the non-routing solutions than is common
   in the IETF.  For example, some proposed WSN routing protocols
   assume that clocks are reasonably well synchronized (no, they
   don't run NTP).  Some system-level design issues should be
   decided in close coordination with the routing protocol design,
   such as:

   - Should some nodes, such as power-rich or gateway nodes, act as
     proxies (for some functions) for power constrained node?

   - Should a link/subnet use both MAC addresses and network-addresses,
     or should only a single set of addresses be used for both purposes?

   - Should full IP (particularly IPv6) addresses _ever_ be transmitted
     over a low-power wireless link (except to request translation to
     a short, link-local address)?

Having said all that, I do think that it is important for a single
(or maybe "joint") low-power wireless networking working group to
be associated with both the Internet Area and the Routing Area.
Perhaps, it is possible for this working group to be associated
with, and have oversight from, both Areas.

Thoughts on whether this new working group should result from a
rechartering of the 6lowpan working group, or whether a fresh
start would be beneficial, is the topic of some future
pontification^H^H^H^H^H^H e-mail.

More unsolicited opinions from,

-tjs


_______________________________________________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/mailman/listinfo/rsn