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
- Re: [RSN] Update Cuda Alberto
- [RSN] Update JP Vasseur
- Fwd: [RSN] Update JP Vasseur
- Re: [RSN] Update Timothy J. Salo
- Re: [RSN] Update Mark Townsley
- Re: [RSN] Update JP Vasseur
- Re: [RSN] Industrial Zach Shelby
- Re: [RSN] Update Anthony Schoofs
- RE: [RSN] Update dculler
- Re: [RSN] Update Traian MUNTEAN
- Re: [RSN] Update Timothy J. Salo
- RE: [RSN] Update Anders Brandt
- Re: [RSN] Update JP Vasseur
- Re: [RSN] Update Anthony Schoofs
- [RSN] The need for RSN Geoff Mulligan
- Re: [RSN] The need for RSN Dominik Kaspar
- Re: [RSN] Update Philip Levis
- [RSN] Update JP Vasseur
- Re: [RSN] Update JP Vasseur
- [RSN] Update JP Vasseur