From rsn-bounces@ietf.org Mon Jul 09 16:28:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zpx-0005zA-EY; Mon, 09 Jul 2007 16:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zpv-0005y7-9v; Mon, 09 Jul 2007 16:27:59 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7zpq-0005hT-Sx; Mon, 09 Jul 2007 16:27:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2007 16:27:54 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAIo2kkZAZnmf/2dsb2JhbACCLzM X-IronPort-AV: i="4.16,518,1175486400"; d="scan'208,217"; a="125605636:sNHT45757256" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l69KRsls008909; Mon, 9 Jul 2007 16:27:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l69KRr6a019341; Mon, 9 Jul 2007 20:27:54 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 16:27:52 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 16:27:52 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: rsn@ietf.org Message-Id: <0492560A-D76C-4D8D-82E8-E78A4AF2A39C@cisco.com> From: JP Vasseur Date: Mon, 9 Jul 2007 16:27:18 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Jul 2007 20:27:52.0744 (UTC) FILETIME=[A0235A80:01C7C267] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3944; t=1184012874; x=1184876874; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Update |Sender:=20 |To:=20rsn@ietf.org; bh=+QD+NH2/ON4jhQOZWFA7BWMXKdWIDtoYTRIsbUtb0Vw=; b=qS/FU/zlY0V3Qiy1PPeTIiuq85OcQwH1omBVfWCp6A1sWOkZfOdc7uMCtwhKc943KXRAh3mq Fc8pntD5mnShhzwEuBLFnjKAJLFkEHRs5NUgh4aMmq6iLBgLuAeQChZ6; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: manet@ietf.org, manemo@mobileip.jp Subject: [RSN] Update X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0602073563==" Errors-To: rsn-bounces@ietf.org --===============0602073563== Content-Type: multipart/alternative; boundary=Apple-Mail-9--452791207 --Apple-Mail-9--452791207 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, As agreed on the list some time ago, several new IDs have been posted: 1) The generic requirements ID: "Routing Requirements for Low Power And Lossy Networks" - draft- culler-rl2n-routing-reqs-01 http://www.ietf.org/internet-drafts/draft-culler-rl2n-routing- reqs-01.txt 2) Application-specific routing requirements for L2Ns * Home Automation "Home Automation Routing Requirement in Low Power and Lossy Networks" - draft-brandt-rl2n-home-routing-reqs-01 http://www.ietf.org/internet-drafts/draft-brandt-rl2n-home-routing- reqs-01.txt * Industrial: in the works * Healthcare: TBD 3) Survey on existing protocols. "Overview of Existing Wireless Mesh Routing Protocols for Low Power and Lossy Networks" - draft-levis-rl2n-overview-protocols-01 http://www.ietf.org/internet-drafts/draft-levis-rl2n-overview- protocols-01.txt => This is a **very** first draft that definitely requires more work but a good start. We should be having within a 3-4 weeks timeframe a more fleshed out version. Thanks. JP and David. --Apple-Mail-9--452791207 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

As agreed on the list some = time ago, several new IDs have been posted:

1) The generic requirements = ID:
= "Routing Requirements for Low Power And Lossy Networks" = -=A0draft-culler-rl2n-routing-reqs-01

2) Application-specific = routing requirements for L2Ns
* Home = Automation
"Home Automation Routing = Requirement in Low Power and Lossy Networks" = -=A0draft-brandt-rl2n-home-routing-reqs-01
* Industrial: in the = works
* Healthcare: = TBD

3) = Survey on existing protocols.
"Overview of Existing Wireless = Mesh Routing Protocols for Low Power and Lossy Networks" = -=A0draft-levis-rl2n-overview-protocols-01
=3D> This is a **very** first draft = that definitely requires more work but a good start. We should be having = within a 3-4 weeks timeframe
a more fleshed out = version.

Thanks.

JP and = David.
= --Apple-Mail-9--452791207-- --===============0602073563== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0602073563==-- From rsn-bounces@ietf.org Mon Jul 09 16:28:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zqA-000694-VC; Mon, 09 Jul 2007 16:28:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zq9-00068O-Jd for rsn@ietf.org; Mon, 09 Jul 2007 16:28:13 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7zq8-00015j-SZ for rsn@ietf.org; Mon, 09 Jul 2007 16:28:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2007 16:28:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGs3kkZAZnmf/2dsb2JhbACCYg X-IronPort-AV: i="4.16,518,1175486400"; d="scan'208,217"; a="64729271:sNHT60416708" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l69KS4ng008966 for ; Mon, 9 Jul 2007 16:28:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l69KRtsC022649 for ; Mon, 9 Jul 2007 20:28:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 16:28:01 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 16:28:00 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: rsn@ietf.org Message-Id: <2366F1CE-5DB4-4BF6-B34C-3D27458BCA54@cisco.com> References: From: JP Vasseur Date: Mon, 9 Jul 2007 16:27:26 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Jul 2007 20:28:00.0291 (UTC) FILETIME=[A4A2EF30:01C7C267] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=21088; t=1184012884; x=1184876884; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20I-D=20ACTION=3Adraft-culler-rl2n-routing-reqs-01.txt =20 |Sender:=20 |To:=20rsn@ietf.org; bh=CKGLcQ13SSnMjlg/4NqPlb1EfQHAA+l7L1U8y4zwCbg=; b=ZjbLr5WDq8MEp5ZVd5fXjk+leWl/3YqWArvz7du0RT26/DWE4BeeI1c+QBH1VELC1snD1yQX jVct5ov4aZzf1g3nkHNnwwTXMU6inHuTPK+wDXVCdHTOkH7+jY2K2CAR; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 Subject: [RSN] Fwd: I-D ACTION:draft-culler-rl2n-routing-reqs-01.txt X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0471534576==" Errors-To: rsn-bounces@ietf.org --===============0471534576== Content-Type: multipart/alternative; boundary=Apple-Mail-10--452783276 --Apple-Mail-10--452783276 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, We have updated the generic requirement document: 1) Editorial changes 2) RFC 2119 language 3) New sections: Terminology, "Route over versus Mesh-under", In the next revision, we'll cover the security (particularly important due to the MP2P traffic nature in some L2Ns such as Sensor Networks) and manageability aspects. Comments very welcome. Thanks. JP and David. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: July 8, 2007 6:15:02 PM EDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-culler-rl2n-routing-reqs-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Routing Requirements for Low Power And Lossy Networks > Author(s) : J. Vasseur, D. Cullerot > Filename : draft-culler-rl2n-routing-reqs-01.txt > Pages : 11 > Date : 2007-7-8 > > The need for high quality routing for Low power and Lossy Network > (L2N) such as sensor networks comprised of highly constrained > devices > (CPU, memory, ...) in sometimes unstable wireless environments is > critical now and will continue to increase. Interest in this class > of applications has grown dramatically in recent years and a > routing > solution addressing the specific environments of such networks is > highly required considering the numerous, incompatible open-source > and proprietary routing protocols as well as several industrial > forums. The aim of this document is to define the routing > requirements for Sensor Networks at the IP layer. Such routing > protocol(s) would need to address several unique aspects of this > class of embedded devices and would operate in networks comprising > links of various nature. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-culler-rl2n-routing- > reqs-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-culler-rl2n-routing-reqs-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-culler-rl2n-routing-reqs-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-7-8170127.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-10--452783276 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear all,

We have updated the generic = requirement document:

1) Editorial = changes
2) RFC 2119 language
3) New sections: = Terminology, "Route over versus Mesh-under",=A0

In the next revision, we'll = cover the security (particularly important due to the MP2P = traffic
nature in some L2Ns such as Sensor Networks) and = manageability aspects.

Comments very = welcome.

Thanks.

JP and = David.

Begin forwarded message:

Date: July 8, 2007 6:15:02 PM = EDT
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-culler-rl2n-routing-reqs-01.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts=A0
directories.


Title : Routing Requirements for Low = Power And Lossy Networks
= Author(s) = : J. Vasseur, D. Cullerot
= Filename = : draft-culler-rl2n-routing-reqs-01.txt
Pages : 11
Date : = 2007-7-8

The need for = high quality routing for Low power and Lossy Network
=A0=A0 = (L2N) such as sensor networks comprised of highly constrained = devices
=A0=A0 (CPU, memory, ...) in = sometimes unstable wireless environments is
=A0=A0 critical now and will = continue to increase.=A0 = Interest in this class
=A0=A0 of applications has grown = dramatically in recent years and a routing
=A0=A0 solution addressing the = specific environments of such networks is
=A0=A0 highly required = considering the numerous, incompatible open-source
=A0=A0 = and proprietary routing protocols as well as several = industrial
=A0=A0 forums.=A0 The aim of this document is = to define the routing
=A0=A0 requirements for Sensor = Networks at the IP layer.=A0 = Such routing
=A0=A0 protocol(s) would need to = address several unique aspects of this
=A0=A0 class of embedded devices = and would operate in networks comprising
=A0=A0 links of various = nature.

A URL for this Internet-Draft is:

To remove yourself from the I-D Announcement list, = send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-culler-rl2n-routing-reqs-01.txt".

A list of = Internet-Drafts directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-culler-rl2n-routing-reqs-01.txt".

NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

=

= --Apple-Mail-10--452783276-- --===============0471534576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0471534576==-- From rsn-bounces@ietf.org Mon Jul 09 17:51:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I818Y-0005Ng-Sl; Mon, 09 Jul 2007 17:51:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I818W-0005DV-41 for rsn@ietf.org; Mon, 09 Jul 2007 17:51:16 -0400 Received: from smtp1-g19.free.fr ([212.27.42.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I818V-0003B4-KV for rsn@ietf.org; Mon, 09 Jul 2007 17:51:16 -0400 Received: from [192.168.0.1] (mir01-2-82-245-104-81.fbx.proxad.net [82.245.104.81]) by smtp1-g19.free.fr (Postfix) with ESMTP id 887121AB2B6; Mon, 9 Jul 2007 23:50:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <9AA40622-DC1C-4120-9702-BD738EFA1E0B@cisco.com> References: <505C7499-1AF3-45E0-875B-B5B73C25F4FE@free.fr> <9AA40622-DC1C-4120-9702-BD738EFA1E0B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <48D31231-1BCD-422A-9710-CDDC9490C261@ens-lyon.fr> Content-Transfer-Encoding: quoted-printable From: Bernard Tourancheau Subject: Re: [RSN] L3 mesh requirements Date: Mon, 9 Jul 2007 23:50:39 +0200 To: JP Vasseur , rsn@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Le 21 juin 07 =E0 23:00, JP Vasseur a =E9crit : > Hi Bernard, > > On Jun 19, 2007, at 4:39 PM, Bernard Tourancheau wrote: > >> Hello all, >> A few comments, probably very naive, I did not read entirely the =20 >> archive. >> >> Other wireless networks do not have the strong energy constraint, =20 >> memory constraint, ... that sensors have. Thus lowpan deserves a =20 >> different perspective to reflect its physical reality. Routing =20 >> will be hierarchical because of the different capabilities of each =20= >> nodes. >> We may "classify them by their routing resources ?: >> >> Type | Capability = Fonctional Device >> ---------------------------------------------------------------------=20= >> --------------------------- >> leaf nodes, | send/recv = veryRFD? >> hop nodes, | send/recv/fwd+treatment? = RFD? >> bridge nodes. | send/recv/fwd/multi-cast/treatment = FFD? >> gateway nodes| send/recv/fwd/multi-cast/treatment + "always" up =20= >> veryFFD? >> >> We may associate L3 to only FFDs ? The L2 forwarding is not =20 >> mandatory, automatic and blind, somehow it defines a cluster, =20 >> representing the first stage of the hierarchy. >> > > At this stage, we've been working on the requirements. As pointed =20 > out in a previous email, it may not be a good > idea to take the superset of all the requirements of L2Ns (again =20 > let's try to use that terminology to refer to Low Power > and Lossy Networks, which includes Sensor Networks but is not =20 > restricted to it). > > Why ? > > Because they drastically differ ... thus this may lead to trying to =20= > design a routing protocols satisfying conflicting requirements > if we want to indeed design a network for light footprint nodes. =20 > Thus the proposed approach is to have (in addition to the > generic ID above), several applications specific requirements =20 > documents and define the protocol as a set of loadable > components. > > I know that two IDs are in the works: > (1) Home Automation > (2) Industrial application > > We would probably need to have another one for healthcare. Hi JP, I agree with your points. ID classes could be defined for severals needs: for weather forecast, =20= for aerospace, for automotive, for electrical/gaz/sewage/water grid, =20 for environement temperature, ... > > Back to your point, in a second step, we may decide to classify =20 > nodes by category although I personally prefer to use > nodes attributes to provide a better granularity, to be discussed =20 > with the group of course. Then the routing design will > follow. > > At this point, I think that it is crucial to carefully analyze the =20 > requirements ... although I know that we are all tempted to > jump into the protocol design discussion. > > Would you want to provide comments to http://www.ietf.org/internet-=20 > drafts/draft-culler-rsn-routing-reqs-00.txt? This is interesting and of course "the" very good start !!!. I would =20 add sections about broadcast and multicast that will be a requirement =20= for L2N, at least for weak-up, alarm, data collection, ... all the =20 event-based control of these devices, not speaking about neighbor =20 discovery, announcement, routing set-up, etc. I am also wandering about the possibility for a device to have =20 several addresses or a range of addresses, for instance one for each =20 sensing collector. > > As I said other related IDs will be soon follow. > >> About mobility or slow mobility: >> Are we sure this is a requirement for our targets ? As long a =20 >> connection exist no problem, its physical strength or the =20 >> forwarding path can vary due to slow mobility, energy level or =20 >> environment movements. When some connection is lost, let call it =20 >> broken link. A new connection in another forwarding cluster needs =20 >> dhcp style renegociation. > > See this is why we need application specific IDs. If it turns out =20 > that mobility is not a strong requirements it would be good to know > it before making the assumption that it is required, although in =20 > this particular case I think it is ;-) Ok, my point here was that for RFDs, mobility may not have the strong =20= IP meaning but just "disconnected" or less connected meanings. I am =20 not sure RFDs should spend energy dealing with complex mobility =20 protocols. Cheers, Bernard. > > Thanks. > > JP. > >> >> My 2motes, >> Bernard. >> >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Jul 09 22:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I85Fy-0006Sc-AK; Mon, 09 Jul 2007 22:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I85Fx-0006SX-Rj for rsn@ietf.org; Mon, 09 Jul 2007 22:15:13 -0400 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I85Ft-0004mo-En for rsn@ietf.org; Mon, 09 Jul 2007 22:15:13 -0400 Received: by nz-out-0506.google.com with SMTP id n1so841777nzf for ; Mon, 09 Jul 2007 19:15:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n3X2YTMP5Wx+iCIsoIl8VU6KoctZVqfUI2Lz5wUugBJsj5JrXrx9K7N/7vMnWBA4ha3qWGF/lgIu+3D3E4p1b6ZJSIdIkSxFDjzHnV/7HFwWl3zt+VAoGdV2waqpA7ufnRX/ln+3F9/zE/++ryHj1wtH7G1Pl3tHoAuL/5N7mQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XHTxgTdTEREDCW7phfiecUcCwRzz6PNMRtcw9wa0JvfBGUckhJp76PQu3JVj4+YEjd1mB+tqn29XIbxh/zrFNeH8UFBNa2hZ6oDe5J8dnOxgT/uoyLoTu6+fisMepP/uxHVaLJRU4eE7+8FoapCj1qMKRORs9Na4jQ0yjeVuK+s= Received: by 10.141.195.18 with SMTP id x18mr1122717rvp.1184033708583; Mon, 09 Jul 2007 19:15:08 -0700 (PDT) Received: by 10.141.98.2 with HTTP; Mon, 9 Jul 2007 19:15:08 -0700 (PDT) Message-ID: <2a3692de0707091915o43ca5f3axfd49b24fd41e78a2@mail.gmail.com> Date: Tue, 10 Jul 2007 11:15:08 +0900 From: "Dominik Kaspar" To: "JP Vasseur" Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rl2n-routing-reqs-01.txt In-Reply-To: <2366F1CE-5DB4-4BF6-B34C-3D27458BCA54@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2366F1CE-5DB4-4BF6-B34C-3D27458BCA54@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi JP, It's good to see the new section "Route Over versus Mesh-Under" in your draft. We have also just updated our "6lowpan Routing Requirements" draft, including more clarification about "mesh-under routing". Hopefully, that will lead to a better separation. As RSN/RL2N is currently collecting different scenarios of applications and deployment, we hope that 6lowpan's view on routing may also serve as valuable input for 6lowpan-specific requirements, which can be one of the application areas for RSN/RL2N. Our updated draft should soon be available at: http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-02.txt Cheers, Dominik On 7/10/07, JP Vasseur wrote: > Dear all, > > We have updated the generic requirement document: > > 1) Editorial changes > 2) RFC 2119 language > 3) New sections: Terminology, "Route over versus Mesh-under", > > In the next revision, we'll cover the security (particularly important due > to the MP2P traffic > nature in some L2Ns such as Sensor Networks) and manageability aspects. > > Comments very welcome. > > Thanks. > > JP and David. > > Begin forwarded message: > > From: Internet-Drafts@ietf.org > Date: July 8, 2007 6:15:02 PM EDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-culler-rl2n-routing-reqs-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Routing Requirements for Low Power And Lossy Networks > Author(s) : J. Vasseur, D. Cullerot > Filename : draft-culler-rl2n-routing-reqs-01.txt > Pages : 11 > Date : 2007-7-8 > > The need for high quality routing for Low power and Lossy Network > (L2N) such as sensor networks comprised of highly constrained devices > (CPU, memory, ...) in sometimes unstable wireless environments is > critical now and will continue to increase. Interest in this class > of applications has grown dramatically in recent years and a routing > solution addressing the specific environments of such networks is > highly required considering the numerous, incompatible open-source > and proprietary routing protocols as well as several industrial > forums. The aim of this document is to define the routing > requirements for Sensor Networks at the IP layer. Such routing > protocol(s) would need to address several unique aspects of this > class of embedded devices and would operate in networks comprising > links of various nature. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-culler-rl2n-routing-reqs-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-culler-rl2n-routing-reqs-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-culler-rl2n-routing-reqs-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-7-8170127.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jul 13 11:01:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MdL-0005hj-Id; Fri, 13 Jul 2007 11:00:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MdK-0005go-0H for RSN@ietf.org; Fri, 13 Jul 2007 11:00:38 -0400 Received: from ccaix.jsums.edu ([143.132.8.108]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Md4-0004tx-LD for RSN@ietf.org; Fri, 13 Jul 2007 11:00:37 -0400 Received: from webmail.jsums.edu ([143.132.8.100]) by ccaix.jsums.edu (8.13.1/8.13.1) with ESMTP id l6DExnZ8019037; Fri, 13 Jul 2007 09:59:49 -0500 Received: from 172.132.188.100 (SquirrelMail authenticated user nmeghanathan) by webmail.jsums.edu with HTTP; Fri, 13 Jul 2007 09:59:49 -0500 (CDT) Message-ID: <1442.172.132.188.100.1184338789.squirrel@webmail.jsums.edu> Date: Fri, 13 Jul 2007 09:59:49 -0500 (CDT) From: nmeghanathan@jsums.edu To: RSN@ietf.org User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: iaria.announce@gmail.com Subject: [RSN] CFP: ICNS 2008: The Fourth International Conference on Networking and Services X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Please apologize for any cross-postings --------------------------------------- Invitation: Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS, TUTORIALS, PANELS The Fourth International Conference on Networking and Services ICNS 2008 March 16-21, 2008 - Gosier, Guadeloupe Site: http://www.iaria.org/conferences2008/ICNS08.html Submit a paper: http://www.iaria.org/conferences2008/SubmitICNS08.html Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. Important deadlines: Submission deadline: October 5, 2007 Notification of acceptance: November 15, 2007 Registration/camera ready: December 5, 2007 ICNS 2008 Tracks (details in the CfP on site) * ENCOT: Emerging Network Communications and Technologies * COMAN: Network Control and Management * SERVI: Multi-technology service deployment and assurance * NGNUS: Next Generation Networks and Ubiquitous Services * MPQSI: Multi Provider QoS/SLA Internetworking * GRIDNS: Grid Networks and Services * EDNA: Emergency Services and Disaster Recovery of Networks and Applications * IPv6DFI: Deploying the Future Infrastructure * IPDy: Internet Packet Dynamics * GOBS: GRID over Optical Burst Switching Networks ====================== IARIA Publicity Board ====================== _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jul 13 16:28:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RkO-0002kr-Ca; Fri, 13 Jul 2007 16:28:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RkM-0002ZU-HN for rsn@ietf.org; Fri, 13 Jul 2007 16:28:14 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9RkI-0006Js-1A for rsn@ietf.org; Fri, 13 Jul 2007 16:28:14 -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 l6DKRrNJ011391; Fri, 13 Jul 2007 15:28:05 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <4697E041.1020807@saloits.com> Date: Fri, 13 Jul 2007 15:27:45 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: rsn@ietf.org, 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [RSN] "Link-Local Routing" versus "Network-Layer Routing" X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org The document "Routing Requirements for Low Power And Lossy Networks" (draft-culler-rl2n-routing-reqs-01) contains lots of good information and identifies a number of topics that require additional thought. This e-mail responds to Section 3, "'Route over' versus 'Mesh under,", which includes the following language: > Clearly routing techniques can be defined at the link layer (also > referred as to the "Mesh Under" approach). By contrast, the "Route > over" approach exclusively relies on IP routing over a network made > of a variety of nodes interconnected by links of various nature. The > aim of this document is to define the routing requirements L2Ns at > the IP layer. As such, it pertains to collections of IEEE 802.15.4 > devices, but is not limited to communication within a single IP link. > It pertains to IP level routing among multiple such PANs, routing > among IEEE 802.15.4 PANs and other links, and routing in other low > power (wireless) networks. In short, we are using a model that the 6lowpan Working Group is developing a link-layer routing protocol. Of course, being the IETF, we don't want to actually say that, which apparently motivated the creation of the opaque term "mesh under". I propose an alternative model of the 6lowpan routing activity that, I claim, fits the facts just as well as does the link-layer routing model. More importantly, this alternative model will be more useful is helping us think about and write about the type of routing being developed by the 6lowpan Working Group. The 6lowpan "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" draft specifies that the link-local portion of an IPv6 address is actually the 64-bit or 16-bit [link-layer] address used by 802.15.4. Stated differently, if I give you a 64-bit or a 16-bit address as used in the 6lowpan format document, you won't be able to tell me whether it is really an 802.15.4 link-layer address or an IPv6 link-local address (because, as specified in the format document, a particular address is used for both purposes). For that matter, the routing protocol won't be able to tell you whether the address is a link-layer or a [elided] network-layer address. In some sense, all I am suggesting is that we emphasize the network-layer use, rather than the link-layer origin, of these 64-bit and 16-bit 802.15.4/link-local addresses. Given this context, I propose that the type of routing that the 6lowpan Working Group is developing can be better described as [IP, network-layer] "link-local routing". That is, it is really network-layer routing, but its scope is restricted to a single IPv6 link. And, because the scope of this routing protocol is restricted to a single IPv6 link, the protocol transports only elided IPv6 addresses, namely only the link-local portion of the IPv6 addresses. I will try, in the next few days, to draft alternative language for Section 3 of the Culler draft that describes the 6lowpan routing work as creating a network-layer, link-local, routing protocol. -tjs _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sat Jul 14 08:56:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hAe-0003LB-U7; Sat, 14 Jul 2007 08:56:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hAd-0003Eq-2m for rsn@ietf.org; Sat, 14 Jul 2007 08:56:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9hAZ-0008Hr-FJ for rsn@ietf.org; Sat, 14 Jul 2007 08:56:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2007 08:56:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAINkmEZAZnme/2dsb2JhbACCLzM X-IronPort-AV: i="4.16,538,1175486400"; d="scan'208,217"; a="126051589:sNHT51745394" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6ECuIPp007686; Sat, 14 Jul 2007 08:56:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6ECuIWI000198; Sat, 14 Jul 2007 12:56:18 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 08:56:18 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 08:56:17 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <3BB9A12B-5DE5-4D1E-8DFC-2D650251E7C0@cisco.com> From: JP Vasseur Subject: Re: [RSN] Update Date: Sat, 14 Jul 2007 08:55:42 -0400 To: Anthony Schoofs X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Jul 2007 12:56:17.0921 (UTC) FILETIME=[5E6E3710:01C7C616] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11669; t=1184417778; x=1185281778; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20Update |Sender:=20 |To:=20Anthony=20Schoofs=20; bh=12LMFYvQhm619iEv7LWcAPPY5A+XGlH0rrr6SJnYD6c=; b=saxqb+L0/qqX/1FzIwvDpS8SHJDSDY9NkAZmcbaSByYvSpJiT1S6/DraqwTPd8qYY/++rwCx tgAZMv0DM88yFEoGTFvJ23hdV1JBSAH0wmYMUz7bUt7MMtE1sEHBUpKe; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0842661601==" Errors-To: rsn-bounces@ietf.org --===============0842661601== Content-Type: multipart/alternative; boundary=Apple-Mail-26--47887774 --Apple-Mail-26--47887774 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Anthony, On Jun 6, 2007, at 10:21 AM, Anthony Schoofs wrote: > > JP, I agree when you said in a previous email: > > > "the proposal is to design a IP routing solution > > specifically for sensor networks, that would of course be > independent > > to the L1/L2 protocol in use (it may be desirable to take into > account > > link layer attributes when calculating a route but the routing > process > > would not be tied up with the link layer). > > In addition, our routing scheme should know when the PAN > coordinator/Gateway location has changed to lower and balance the > network energy consumption. > Then new timezones can be assigned and data routed accordingly. Interesting, your feed-back on several on the new ID would be very welcome in light of the experience with your routing protocol. > > I am looking forward to seeing this new WG formed, Thanks, JP. > Best regards, > Anthony. > > > -- > Anthony Schoofs > Philips Research WY 7-038 > High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands > Email: anthony.schoofs@philips.com > > > > > > > > > Anthony Schoofs > 04-06-2007 12:06 > > To > JP Vasseur > cc > rsn@ietf.org > Subject > Re: [RSN] Update > Classification > > > > > > > We did some work to schedule a coordinate switching on and off of > sensor nodes in order to reduce at maximum the energy consumption > of the network. > We came up with a routing protocol that allows us to route data > throughout the network according to the ON/OFF state of the nodes. > > We would like to provide input for an ID on routing schemes that > have energy consumption as the first focus. > > Best regards, > Anthony. > > -- > Anthony Schoofs > Philips Research > High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands > Email: anthony.schoofs@philips.com > > > > > > > > JP Vasseur > 03-06-2007 14:02 > > > To > rsn@ietf.org > cc > Subject > [RSN] Update > Classification > > > > > > > > Dear all, > > Here is an update on where we stand: good progress ! > > 1) We've been having quite a bit of off-line and on-line discussions > and there is apparently a good level of interest in this work. > There are currently 5 IDs in the works: > * The generic routing requirements: draft-culler-rsn-routing-reqs > * Two application-specific routing requirements: > - Home Networking > - Industrial > * A problem statement > * An ID on routing metrics > > Of course, if you're interested to work on these IDs or other items, > feel free ! > > 2) New name > Although we called this initiative RSN: Routing for Sensor Networks, > it does apply more generally to constrained nodes (Low Power) > operating in Lossy Networks. Objects in general would typically be > part of those networks. So from now on, let's rename this work > R2LN: "Routing issues for Low Power, Lossy Networks", and use that > acronym in all IDs. > > 3) Next IETF > We asked for a presentation slot for the next IETF. Depending on the > feedback, the next step would then to request a BOF in Vancouver. > > Thanks. > > JP and David. > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > --Apple-Mail-26--47887774 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Anthony,


On Jun 6, = 2007, at 10:21 AM, Anthony Schoofs wrote:


JP, I agree when you said in a previous = email:

> "the proposal is to design a IP routing = solution
> specifically for sensor networks, that would of = course be independent
> to the L1/L2 protocol in use (it may be = desirable to take into account
> link layer attributes when = calculating a route but the routing process
> would not be tied = up with the link layer).

In addition, our routing scheme = should know when the PAN coordinator/Gateway location has changed to = lower and balance the network energy consumption.
Then new timezones can be assigned and = data routed accordingly.

Interesting, your feed-back = on several on the new ID would be very welcome in
light of the = experience with your routing protocol.

=
I am looking forward to seeing = this new WG formed,

Thanks,

JP.

Best regards, =
Anthony.


--
= Anthony Schoofs
Philips Research WY 7-038
High Tech Campus 37 , = 5656 AE Eindhoven, The Netherlands
Email: anthony.schoofs@philips.com







Anthony Schoofs

04-06-2007 12:06

=
To
= 		JP Vasseur <jvasseur@cisco.com> =
cc
rsn@ietf.org
Subject
Re: [RSN] Update
Classification
=




=

We did some work to = schedule a coordinate switching on and off of sensor nodes in order to = reduce at maximum the energy consumption of the network.
We came up = with a routing protocol that allows us to route data throughout =A0the = network according to the ON/OFF state of the nodes.

We = would like to provide input for an ID on routing schemes that have = energy consumption as the first focus.
=
Best = regards,
Anthony.

--
Anthony Schoofs
= Philips Research
High Tech Campus 37 , 5656 AE Eindhoven, The = Netherlands
Email: anthony.schoofs@philips.com


 =


=


JP Vasseur = <jvasseur@cisco.com> =

03-06-2007 = 14:02


=
To
= 		rsn@ietf.org =
cc
Subject
[RSN] Update =
Classification
=


=
=



=
Dear all,

Here is an update on = where we stand: good progress !

1) We've been having quite a = bit of off-line and on-line discussions =A0
and there is apparently = a good level of interest in this work.
There are currently 5 IDs in = the works:
* The generic routing requirements: = draft-culler-rsn-routing-reqs
* Two application-specific routing = requirements:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Home Networking
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0- Industrial
* A problem statement
* = An ID on routing metrics

Of course, if you're interested to = work on these IDs or other items, =A0
feel free !

2) New = name
Although we called this initiative RSN: Routing for Sensor = Networks, =A0
it does apply more generally to constrained nodes (Low = Power)
operating in Lossy Networks. Objects in general would = typically be =A0
part of those networks. So from now on, let's = rename this work
R2LN: "Routing issues for Low Power, Lossy = Networks", and use that =A0
acronym in all IDs.

3) Next = IETF
We asked for a presentation slot for the next IETF. Depending = on the =A0
feedback, the next step would then to request a BOF in = Vancouver.

Thanks.

JP and David.

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

= --Apple-Mail-26--47887774-- --===============0842661601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0842661601==-- From rsn-bounces@ietf.org Sat Jul 14 09:05:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hJE-0002oB-3O; Sat, 14 Jul 2007 09:05:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hJC-0002nA-8D for rsn@ietf.org; Sat, 14 Jul 2007 09:05:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9hJB-0000bd-Ir for rsn@ietf.org; Sat, 14 Jul 2007 09:05:14 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2007 09:04:57 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKtmmEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175486400"; d="scan'208"; a="126051860:sNHT32187610" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6ED4vni027360; Sat, 14 Jul 2007 09:04:57 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6ED4mWI002237; Sat, 14 Jul 2007 13:04:52 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 09:04:48 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 09:04:47 -0400 In-Reply-To: <48D31231-1BCD-422A-9710-CDDC9490C261@ens-lyon.fr> References: <505C7499-1AF3-45E0-875B-B5B73C25F4FE@free.fr> <9AA40622-DC1C-4120-9702-BD738EFA1E0B@cisco.com> <48D31231-1BCD-422A-9710-CDDC9490C261@ens-lyon.fr> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1F6D90B6-B140-49D5-B16C-08C3A061D5C6@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [RSN] L3 mesh requirements Date: Sat, 14 Jul 2007 09:04:11 -0400 To: Bernard Tourancheau X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Jul 2007 13:04:48.0028 (UTC) FILETIME=[8E7A5DC0:01C7C617] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5742; t=1184418297; x=1185282297; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20L3=20mesh=20requirements |Sender:=20 |To:=20Bernard=20Tourancheau=20; bh=5kCYg3h7UioYtW5cozI0sjmIKgoqUSleNPRlTir05nE=; b=USNiM8rbzvdqYe84ZvGTfWIv9PyVN5BDocJAPviLZf7SQ72CviJzaXmBEcSdI8FWOkYOGhmz nh/LQkGnjiFmhOcKStvxYbP1pvQCwGpmNzNrl607R8rUSgozeVWPLwH+; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Bernard, On Jul 9, 2007, at 5:50 PM, Bernard Tourancheau wrote: > > Le 21 juin 07 =E0 23:00, JP Vasseur a =E9crit : > >> Hi Bernard, >> >> On Jun 19, 2007, at 4:39 PM, Bernard Tourancheau wrote: >> >>> Hello all, >>> A few comments, probably very naive, I did not read entirely the =20 >>> archive. >>> >>> Other wireless networks do not have the strong energy constraint, =20= >>> memory constraint, ... that sensors have. Thus lowpan deserves a =20 >>> different perspective to reflect its physical reality. Routing =20 >>> will be hierarchical because of the different capabilities of =20 >>> each nodes. >>> We may "classify them by their routing resources ?: >>> >>> Type | Capability = Fonctional Device >>> --------------------------------------------------------------------=20= >>> ---------------------------- >>> leaf nodes, | send/recv = veryRFD? >>> hop nodes, | send/recv/fwd+treatment? = RFD? >>> bridge nodes. | send/recv/fwd/multi-cast/treatment = FFD? >>> gateway nodes| send/recv/fwd/multi-cast/treatment + "always" up =20= >>> veryFFD? >>> >>> We may associate L3 to only FFDs ? The L2 forwarding is not =20 >>> mandatory, automatic and blind, somehow it defines a cluster, =20 >>> representing the first stage of the hierarchy. >>> >> >> At this stage, we've been working on the requirements. As pointed =20 >> out in a previous email, it may not be a good >> idea to take the superset of all the requirements of L2Ns (again =20 >> let's try to use that terminology to refer to Low Power >> and Lossy Networks, which includes Sensor Networks but is not =20 >> restricted to it). >> >> Why ? >> >> Because they drastically differ ... thus this may lead to trying =20 >> to design a routing protocols satisfying conflicting requirements >> if we want to indeed design a network for light footprint nodes. =20 >> Thus the proposed approach is to have (in addition to the >> generic ID above), several applications specific requirements =20 >> documents and define the protocol as a set of loadable >> components. >> >> I know that two IDs are in the works: >> (1) Home Automation >> (2) Industrial application >> >> We would probably need to have another one for healthcare. > Hi JP, > I agree with your points. > ID classes could be defined for severals needs: for weather =20 > forecast, for aerospace, for automotive, for electrical/gaz/sewage/=20 > water grid, for environement temperature, ... Yes, for the time being we'll try to focus on a few ones since in =20 this area it is "easy" to get the work diluted but also to end up with a such a sparse =20 ranges of requirements that no single protocol could satisfy all of them. At the end, we may =20= very end up having a solution of "some" of these applications, which in my opinion would =20= be perfectly acceptable, considering that today there is NO IP solution for L2Ns. >> >> Back to your point, in a second step, we may decide to classify =20 >> nodes by category although I personally prefer to use >> nodes attributes to provide a better granularity, to be discussed =20 >> with the group of course. Then the routing design will >> follow. >> >> At this point, I think that it is crucial to carefully analyze the =20= >> requirements ... although I know that we are all tempted to >> jump into the protocol design discussion. >> >> Would you want to provide comments to http://www.ietf.org/internet-=20= >> drafts/draft-culler-rsn-routing-reqs-00.txt? > This is interesting and of course "the" very good start !!!. I =20 > would add sections about broadcast and multicast that will be a =20 > requirement for L2N, at least for weak-up, alarm, data =20 > collection, ... all the event-based control of these devices, not =20 > speaking about neighbor discovery, announcement, routing set-up, etc. > I am also wandering about the possibility for a device to have =20 > several addresses or a range of addresses, for instance one for =20 > each sensing collector. We briefly introduced the notion of "Groupcast" in the home =20 automation ID. Neighbor discovery, ... would typically be addresses by 6lowpan but the =20 routing protocol would of course have to support it. Feed-back from 6lowpan ? >> >> As I said other related IDs will be soon follow. >> >>> About mobility or slow mobility: >>> Are we sure this is a requirement for our targets ? As long a =20 >>> connection exist no problem, its physical strength or the =20 >>> forwarding path can vary due to slow mobility, energy level or =20 >>> environment movements. When some connection is lost, let call it =20 >>> broken link. A new connection in another forwarding cluster needs =20= >>> dhcp style renegociation. >> >> See this is why we need application specific IDs. If it turns out =20 >> that mobility is not a strong requirements it would be good to know >> it before making the assumption that it is required, although in =20 >> this particular case I think it is ;-) > Ok, my point here was that for RFDs, mobility may not have the =20 > strong IP meaning but just "disconnected" or less connected =20 > meanings. I am not sure RFDs should spend energy dealing with =20 > complex mobility protocols. Absolutely. The routing protocol would have to be flexible enough to =20 not activate some of the routing function on the most constrained node. Cheers. JP. > Cheers, > Bernard. >> >> Thanks. >> >> JP. >> >>> >>> My 2motes, >>> Bernard. >>> >>> >>> _______________________________________________ >>> RSN mailing list >>> RSN@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sat Jul 14 09:07:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hKz-0005zN-5D; Sat, 14 Jul 2007 09:07:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hKx-0005vd-En for rsn@ietf.org; Sat, 14 Jul 2007 09:07:03 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9hKx-0000ds-4M for rsn@ietf.org; Sat, 14 Jul 2007 09:07:03 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Jul 2007 06:07:02 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFNnmEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175497200"; d="scan'208"; a="182104980:sNHT30667662" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6ED72Lk022860; Sat, 14 Jul 2007 06:07:02 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6ED71A0023986; Sat, 14 Jul 2007 13:07:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 09:07:01 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 09:07:01 -0400 In-Reply-To: <78045EBC-86F2-412F-870D-A5375031A789@cs.stanford.edu> References: <20070522232511.DD58016B0002@secure.archedrock.com> <4655A261.2010304@gmail.com> <78045EBC-86F2-412F-870D-A5375031A789@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B706203-300A-4F52-8435-4B27187B5A7C@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Next step for RSN ? Date: Sat, 14 Jul 2007 09:06:24 -0400 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Jul 2007 13:07:01.0422 (UTC) FILETIME=[DDFCACE0:01C7C617] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2463; t=1184418422; x=1185282422; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20Next=20step=20for=20RSN=20? |Sender:=20; bh=wBaKgjg9u//qeCzb/HZjGbIXmY2NTp3ZzcS02T166Ac=; b=I9GFOWQdEJY3BQliHIT19GOCGiuJF7nH9jZ4P6JurGHMJVfDFQP9J+ox4rkkN42Bppv3QqeP KiRN/uJHonIsvUa1VoucOBS25ks3Q6BQrN/Z2Hfbm58Pu7/j8h4B/DxF; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear Alexanndru, http://www.ietf.org/internet-drafts/draft-culler-rl2n-routing- reqs-01.txt may help you understand the specifics of L2Ns. Thanks. JP. On May 24, 2007, at 7:17 PM, Philip Levis wrote: > On May 24, 2007, at 7:34 AM, Alexandru Petrescu wrote: > >> Hi JP, I've received this on the MANEMO list but I'm replying here. >> >> I have some comments, more like against forming the RSN work, but >> I'm ok with all other opinions too :-) >> >> One is that I generally don't really see why routing for sensor >> networks >> is different than other networks. Or maybe that it is generally too >> early for that. > > Routing for sensornets is different than other networks because > they operate under different constraints. The two major differences > are: > > 1) Nodes are energy-limited. > 2) One repercussion of 1) is that nodes are state-limited. > > You can take existing routing approaches, such as AODV, DYMO, GPSR, > etc. and apply them to sensor networks. Users have done so. > Practice has shown, however, that they don't work that well and > generally aren't a very good fit. Instead, working versions of > these protocols typically constrain the protocol. For example, the > AODV implementation for sensor nodes[1] supports routing to a > single destination. High densities, combined with slow radios (a > product of energy concerns), make flooding discovery such as AODV's > tricky to get right, especially without some kind of scoping. > Fundamentally, links behave differently during a flood than during > unicast flows due to the correlations in packet transmissions. > > David summarized many of the implications of 2) very well in a > message to the 6lowpan list. In the context of routing, having each > node store up to O(n) state is generally unfeasible. Capping the > routing state to some value R obviously has problems if you need R > +1 routes. Achieving scalable unicast communication within a state- > limited wireless network is a very active area of research. Right > now, the state of the art (S4, presented at NSDI in March, which > uses compact routing) requires O(sqrt(n)) state. Achieving this, > however, requires embedding a little bit more information in a > routing packet besides the destination address. > > Phil > > [1] tinyos-1.x/contrib/hsn/tos/lob/AODV.nc from http:// > sourceforge.net/cvs/?group_id=28656 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sat Jul 14 09:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hWe-0005Yh-5S; Sat, 14 Jul 2007 09:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hWc-0005Wo-K1; Sat, 14 Jul 2007 09:19:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9hWY-0000No-8x; Sat, 14 Jul 2007 09:19:06 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2007 09:19:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAF5qmEZAZnme/2dsb2JhbACtEg X-IronPort-AV: i="4.16,538,1175486400"; d="scan'208"; a="126052206:sNHT30297268" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6EDJ1T9011752; Sat, 14 Jul 2007 09:19:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6EDJ1WI005898; Sat, 14 Jul 2007 13:19:01 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 09:19:01 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 09:19:01 -0400 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> References: <20070522232511.DD58016B0002@secure.archedrock.com> <7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C11646C-2152-41FA-97CB-20873155E3D2@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Next step for RSN ? Date: Sat, 14 Jul 2007 09:18:25 -0400 To: "Pascal Thubert ((pthubert))" , manet@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Jul 2007 13:19:01.0273 (UTC) FILETIME=[8B0D3890:01C7C619] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3671; t=1184419142; x=1185283142; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20Next=20step=20for=20RSN=20? |Sender:=20 |To:=20=22Pascal=20Thubert=20((pthubert))=22=20, =20ma net@ietf.org; bh=VHBbE3vbNb1oX6KYxLHCdb5xG3YO7RqvYhQGt+TTzno=; b=fiyv81OmqB3N8fJQr7GRU/clTqzsWU0OHYQpFapO8+O9/y39erRcCb2VujOh2hPCwPyEDKWI PyqgXhM0nMiG3gSENgf/nZYrfEezzkwwOKkdwziBmWqWrqk8ngD95Pqy; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Pascal, On May 24, 2007, at 9:45 AM, Pascal Thubert ((pthubert)) wrote: > Hi JP: > > Please see inline: > > It looks fairly obvious that a network made of N "mesh-under" > routing protocols is very unlikely to satisfy an end to end path > constraint and would be fairly complex to manage and tune. We all > remember the issue of IP routing over ATM PVCs routed by PNNI. > Think of this with N "Mesh-under" routing protocols. That said, > this is not to say that we exclude the use of "mesh-under" > solutions, but we propose to define a IP-based routing protocol. > > Pascal => I agree there's a lot of value to federate over IP the > various approaches that are defined for mesh-under. Indeed. > > The second step would consist of making a survey on the existing > routing protocols and see whether (1) they could be used as such > (2) they should be adapted (for instance, see whether AODV or OLR > or RIP could be made energy efficient, could support some form of > constrained based routing, ...) or (3) we should design a new > generic new protocol. > > Pascal => One aspect of this could be to consider the features that > mesh and sensor networks have deployed and why, and then see if > there is a need to generalize the approach at layer 3. For > instance, offline routing is popular in WSNs while not the > prominent model in IP or MANET. > Good point indeed (see TSMP, ...). There is a bit of off-line at the IETF for MPLS but indeed not that much on IP. On the goal of the RSN WG (should it be formed) would precisely to evaluate the pros/cons of all approach and supporting a mix approach might be an option. Anyway, food for future thoughts. Back to the protocol survey, a very first draft is available and requires much more work. Folks from MANET would be very welcome to provide feed-back/comments/ suggestions/... > Pascal => Another specificity could be to work on a tighter > integration with the radio and a more specific abstraction for L3. > I know we have that barrier at IETF against L2 related activities. > Yet, if the radio model provides such things as beacons, then it > could be beneficial to define a routing protocol that can take > advantage of the beacons. At the moment, IP is carried in data > frames only. I agree that we need an L2 abstraction layer since RF links in particular are quite specifics and their characteristics must be known by the routing protocol when they influence the routing decision, as stated in draft-culler-rl2n-routing-reqs-01. By the way, you and I have the action plan to produce that ID ;-) Back to your example on beacon, I would personally prefer to maintain a clear separation between layer to keep the L2 agnostic nature of routing. Why not defining local inter-layer mechanism (out of the standardization scope) as we do with many other media ? > > Pascal => We'll also have to work out the relationship with MANEMO. > My understanding is that MANEMO is for bigger boxes (routers > really) and has strong mobility and global reachability > constraints. That makes it pretty different in the objectives. > OTOH, there seems to be value to keep sharing views and ideas > between the groups, should they form. You are 100% right. One option might be to concentrate all routing function in one place or to clearly differentiate the routing objective. We do need to avoid any overlap. We (RSN) should provide feed-back to MANET (I just assigned an action item to myself ;-)) and vice versa. Thanks. JP. > > Pascal _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sat Jul 14 15:01:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9msK-0001Au-Fh; Sat, 14 Jul 2007 15:01:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9msJ-0001Ao-Mt for rsn@ietf.org; Sat, 14 Jul 2007 15:01:51 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9ms3-0000J4-Rv for rsn@ietf.org; Sat, 14 Jul 2007 15:01:51 -0400 Received: from [127.0.0.1] (saloits.com [208.42.140.127]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l6EJ0jc3020408; Sat, 14 Jul 2007 14:00:56 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <46991D57.2000704@saloits.com> Date: Sat, 14 Jul 2007 14:00:39 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: rsn@ietf.org, 6lowpan <6lowpan@lists.ietf.org> References: <496204.11117.qm@web81903.mail.mud.yahoo.com> In-Reply-To: <496204.11117.qm@web81903.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Subject: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing" X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Gabriel, Thanks for the note. Some questions and comments follow. gabriel montenegro wrote: > There is an incorrect assumption in the message below: > > The 6lowpan "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" > draft specifies that the link-local portion of an IPv6 address is > actually the 64-bit or 16-bit [link-layer] address used by 802.15.4. Gabriel is, of course, absolutely correct. For various classes of IPv6 addresses (e.g., non-link-local addresses and multicast addresses) the 6lowpan format document simply cannot mandate that the link-local portion of the IPv6 address is actually an 802.15.4 address -- it doesn't make any technical sense. Perhaps, the interesting issue is whether the 6lowpan format document should specify that the link-local portion of IPv6 unicast addresses assigned to 6lowpan hosts _must_ be derived from either the 64-bit or 16-bit addresses used by 802.15.4. I can think of a few reasons why this might be undesirable: o It probably conflicts with the RFC 3041 privacy extensions o It may prohibit a host from having multiple IPv6 addresses (or, it might not, if the host requests multiple 16-bit addresses from the PAN controller) o It might prohibit a host from aliasing as another host o It might prohibit the specification of well-defined IPv6 addresses Are there other reasons why this might be a bad idea? On the other hand, it appears to me that requiring that IPv6 unicast addresses within a PAN be created by using either the 64-bit or the 16-bit 802.15.4 addresses has some tremendous advantages: o It probably eliminates the need for duplicate address detection functionality, thereby simplifying efforts to emulate IPv6 neighbor discovery functionality o It probably eliminates the need for address resolution functionality, thereby simplifying efforts to emulate IPv6 neighbor discovery functionality o It probably allows issues of link-local routing, neighbor reachability, and link-layer neighbor discovery to be addressed in a coordinated fashion. It appears that a coordinated solution is much more likely to be well-adapted to highly resource-constrained networks, compared to attacking each of these topics individually (or trying to emulate IPv6 neighbor discovery for as many functions as possible). Of course, I have a few other questions: o How important are RFC 3041 privacy extensions in 6lowpan networks? If this functionality is important, can some other technique be used to provide the same functionality (e.g., translate/scramble IPv6 addresses at the border of the 6lowpan network)? o Is there a requirement that conflicts with using 802.15.4 addresses to form the link-local part of IPv6 addresses assigned to 6lowpan hosts? o Are there cases where it is technically infeasible to use 802.15.4 addresses to form the link-local part of IPv6 addresses assigned to 6lowpan hosts? o Have I missed something fundamental, and this is all really a bad idea? > 6lowpan does not mandate such a relationship. It only says that if it > does in fact exist, then here is how to take advantage of it. ... > Notice that the above is merely an optimization, and one applied to the > IPv6 header compression scheme. Yes. I am asking whether it should be required, rather than optional, when it is possible. > As such, it is orthogonal and independent to the mesh delivery support. Yes. But, should it be? > We want that independence as > the IPv6 header compression works only for IPv6, whereas the lowpan > layer (including the mesh delivery) works independently of the protocol > being transported in this link. In other words, you could use the lowpan > layer for IPv4, appletalk, or any other protocol. I think it would be useful to discuss the use of IPv4 in 802.15.4, rather than assume a particular technical solution in advance of those discussions. For example, given the highly resource-constrained nature of these networks, it might make sense to use 802.15.4 addresses within a 4lowpan network as network addresses, and then translate them to [real] IPv4 addresses at the boundary of the network. This would enable a common routing protocol to be used for IPv4 and IPv6, and would avoid having to create an IPv4 ARP function. Does even Apple use AppleTalk anymore? From : "AppleTalk is a proprietary suite of protocols developed by Apple Inc for computer networking. It was included in the original Macintosh (1984) and is now deprecated by Apple in favor of TCP/IP networking." Or, maybe someone wants to run the OSI protocols over 802.15.4 networks... It seems like we should talk about this some more, before we potentially clutter up an 802.15.4 solution in order to potentially support dead protocols such as AppleTalk. > So your suggested wording below is not true in general, but it may > apply in a meaningful subset of possible cases. Or, I might be totally confused. But, it seems like the approach I propose could simplify, perhaps even dramatically, our task of creating effective solutions for low-power wireless networks. -tjs _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sat Jul 14 18:06:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9plG-0000Ky-O9; Sat, 14 Jul 2007 18:06:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9plF-0000Ks-EJ for rsn@ietf.org; Sat, 14 Jul 2007 18:06:45 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9plA-00065J-Sl for rsn@ietf.org; Sat, 14 Jul 2007 18:06:45 -0400 Received: from [127.0.0.1] (saloits.com [208.42.140.127]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l6EM6RJg021293 for ; Sat, 14 Jul 2007 17:06:38 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <469948DC.1060302@saloits.com> Date: Sat, 14 Jul 2007 17:06:20 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 Followup-To: 6lowpan,<6lowpan@lists.ietf.org> To: rsn@ietf.org References: <496204.11117.qm@web81903.mail.mud.yahoo.com> In-Reply-To: <496204.11117.qm@web81903.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing" X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org gabriel montenegro wrote: > Hi Tim, > > There is an incorrect assumption in the message below: > > The 6lowpan "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" > draft specifies that the link-local portion of an IPv6 address is > actually the 64-bit or 16-bit [link-layer] address used by 802.15.4. > > 6lowpan does not mandate such a relationship. It only says that if it > does in fact exist, then here is how to take advantage of it. The fact > that this is not being mandated > should be evident from the text in section 10.1: ... Having thought about this a bit more, a few additional comments follow about whether the 6lowpan format document should mandate that the IPv6 addresses of devices on a 6lowpan network _must_ be derived from 802.15.4 64-bit or 16-bit addresses. The 6lowpan format document includes the following language: 6. Stateless Address Autoconfiguration This section defines how to obtain an IPv6 interface identifier. The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may be based on the EUI-64 identifier [EUI64] assigned to the IEEE 802.15.4 device. ... All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short addresses (Section 3 and Section 12) are also possible. In these cases, a "pseudo 48-bit address" is formed as follows. ... A different MAC address set manually or by software MAY be used to derive the Interface Identifier. ... So, if I understand correctly, an IPv6 interface identifier created by an implementation of the 6lowpan format specification can be pretty much any arbitrary string of bits of the appropriate length. This appears to me to imply that either: The 6lowpan specifications should explicitly require every conforming 6lowpan implementation to implement duplicate address detection and address resolution functionality analogous to that specified in the IPv6 neighbor discovery protocols. This is because a 6lowpan implementation must (it would seem) be capable of operating in a 6lowpan network in which one or more devices are using arbitrary interface identifiers. This appears to me to conflict with the objective of creating a solution for 802.15.4 networks that requires a small memory footprint. I also suspect that, given that many 6lowpan devices will sleep most of the time, a general duplicate address detection mechanism is unlikely to work (unless, of course, the duplicate address detection mechanism wakes up every sleeping device and asks it if its address is a duplicate...). or, Implementations that conform to the 6lowpan specifications are not assured to interoperate. This is because a device that doesn't implement IPv6-like duplicate address detection and address resolution functionality can't be assured of interoperating with devices that create arbitrary interface identifiers. Note that non-interoperable conforming implementations appear to be acceptable to some standards communities, but I don't think this approach should be acceptable to the IETF. Alternatively, the 6lowpan format document could _require_ that IPv6 interface identifiers be derived from either 64-bit or 16-bit 802.15.4 addresses. This would enable us to avoid requiring every 6lowpan device to implement IPv6-like duplicate address detection or address resolution functionality (or accept that conforming implementations may not interoperate). Is it technically feasible to require that 6lowpan devices derive IPv6 interface identifiers from 802.15.4 64-bit or 16-bit addresses? Is there a requirement that 6lowpan devices be able to create arbitrary IPv6 interface identifiers? Or, was this feature simply included because it seemed like a good idea at the time? Should the 6lowpan format specification require that IPv6 interface identifiers be derived from 802.16.4 addresses? Or, have I simply missed the point somehow? -tjs _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun Jul 15 01:26:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9wcq-0006LV-6z; Sun, 15 Jul 2007 01:26:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9wcp-0006L9-0N for rsn@ietf.org; Sun, 15 Jul 2007 01:26:31 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9wck-0005FC-Hx for rsn@ietf.org; Sun, 15 Jul 2007 01:26:30 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id EA52C16B0001; Sat, 14 Jul 2007 22:26:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [192.168.1.124] (adsl-71-142-73-24.dsl.pltn13.pacbell.net [71.142.73.24]) by secure.archedrock.com (Postfix) with ESMTP id 0B3C716B0001; Sat, 14 Jul 2007 22:26:24 -0700 (PDT) Message-ID: <4699AFFB.8020204@archrock.com> Date: Sat, 14 Jul 2007 22:26:19 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Timothy J. Salo" Subject: Re: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing" References: <496204.11117.qm@web81903.mail.mud.yahoo.com> <469948DC.1060302@saloits.com> In-Reply-To: <469948DC.1060302@saloits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Timothy J. Salo wrote: > Is there a requirement that 6lowpan devices be able to create > arbitrary IPv6 interface identifiers? Or, was this feature > simply included because it seemed like a good idea at the time? I don't think there is any explicit requirement for nodes using arbitrary interface identifiers. Though I do think that when the format doc was drafted, it was meant to support IPv6 with a minimal set of constraining assumptions. One obvious example is support for the minimum IPv6 MTU. While its unlikely that we'll see LoWPAN nodes transmitting relatively large datagrams, the support for the full minimum IPv6 MTU was included as part of the LoWPAN format specification. Many would argue that this adds non-trivial complexity. > Should the 6lowpan format specification require that IPv6 interface > identifiers be derived from 802.16.4 addresses? I wouldn't go as far as to limit LoWPAN nodes to using only interface identifiers derived from link addresses. Rather, I would prefer an approach where DAD and link address resolution is not required for IPv6 addresses with interface identifiers that have universal scope (i.e. u/l bit set to one). DAD would still be required IPv6 addresses with local scope interface identifiers. The main advantage of this approach is that it would be possible for nodes using only global scope interface identifiers to avoid implementing any form of DAD and be completely agnostic to whatever LoWPAN DAD approach is defined. It would just need to route the packets between nodes participating in the DAD protocol. I would also go as far to say that interface identifiers derived from 802.15.4 short addresses also do not require DAD, as it is assumed that lower layers will enforce the uniqueness of the short address within the PAN. For nodes that do want to use arbitrary local scope interface identifiers (e.g. for privacy), then they would be burdened by the extra support required for DAD. This follows the "pay-as-you-go" spirit of the LoWPAN format, where only nodes that utilize more "advanced" functionality carry most of the extra costs. -- Jonathan Hui jhui@archrock.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun Jul 15 22:57:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAGmI-0003i2-TP; Sun, 15 Jul 2007 22:57:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAGmH-0003hw-7V for rsn@ietf.org; Sun, 15 Jul 2007 22:57:37 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAGm2-00005z-De for rsn@ietf.org; Sun, 15 Jul 2007 22:57:37 -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 l6G2uWVL030416; Sun, 15 Jul 2007 21:56:43 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <469ADE57.2070106@saloits.com> Date: Sun, 15 Jul 2007 21:56:23 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: rsn@ietf.org, 6lowpan@lists.ietf.org Subject: Re: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing" References: <496204.11117.qm@web81903.mail.mud.yahoo.com> <469948DC.1060302@saloits.com> <4699AFFB.8020204@archrock.com> In-Reply-To: <4699AFFB.8020204@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Jonathan Hui wrote: > > Timothy J. Salo wrote: >> Is there a requirement that 6lowpan devices be able to create >> arbitrary IPv6 interface identifiers? Or, was this feature >> simply included because it seemed like a good idea at the time? > > I don't think there is any explicit requirement for nodes using > arbitrary interface identifiers. Though I do think that when the format > doc was drafted, it was meant to support IPv6 with a minimal set of > constraining assumptions. One obvious example is support for the minimum > IPv6 MTU. While its unlikely that we'll see LoWPAN nodes transmitting > relatively large datagrams, the support for the full minimum IPv6 MTU > was included as part of the LoWPAN format specification. Many would > argue that this adds non-trivial complexity. Support for the minimum IPv6 MTU enables 6lowpan devices to interoperate with traditional IPv6 hosts. Ensuring interoperability between 6lowpan devices and non-6lowpan IPv6 hosts seems to be a pretty important objective. Arbitrary link-local interface identifiers, on the other hand, do not appear to provide any benefits that are nearly so fundamental. Perhaps they are useful in some circumstances (although I haven't heard what these circumstances might be) but they don't appear to be really important, much less facilitate interoperability. >> Should the 6lowpan format specification require that IPv6 interface >> identifiers be derived from 802.16.4 addresses? > > I wouldn't go as far as to limit LoWPAN nodes to using only interface > identifiers derived from link addresses. Rather, I would prefer an > approach where DAD and link address resolution is not required for IPv6 > addresses with interface identifiers that have universal scope (i.e. u/l > bit set to one). DAD would still be required IPv6 addresses with local > scope interface identifiers. The main advantage of this approach is that > it would be possible for nodes using only global scope interface > identifiers to avoid implementing any form of DAD and be completely > agnostic to whatever LoWPAN DAD approach is defined. It would just need > to route the packets between nodes participating in the DAD protocol. I > would also go as far to say that interface identifiers derived from > 802.15.4 short addresses also do not require DAD, as it is assumed that > lower layers will enforce the uniqueness of the short address within the > PAN. For nodes that do want to use arbitrary local scope interface > identifiers (e.g. for privacy), then they would be burdened by the extra > support required for DAD. This follows the "pay-as-you-go" spirit of the > LoWPAN format, where only nodes that utilize more "advanced" > functionality carry most of the extra costs. I believe that if the 6lowpan format document permits the use of interface identifiers that are _not_ derived from 64-bit or 16-bit 802.15.4 addresses, then _every_ 6lowpan device must implement a IPv6-like address resolution capability. This is because, even though a device may derive its own interface identifier from an 802.15.4 address, the device might be connected to a network in which other devices create arbitrary interface identifiers. That is, every 6lowpan device must be prepared to resolve arbitrary interface identifiers used by other 6lowpan devices. On the other hand, any 6lowpan node that wishes to communicate with a 6lowpan device that uses an arbitrary interface address must execute an IPv6-like address resolution function. This function will involve additional network traffic and probably additional stored state (to cache address resolution information to avoid unnecessary network traffic). Of course, a 6lowpan device won't know until it connects to a network whether it will need to use this IPv6-like address resolution capability, and so every 6lowpan device must implement this functionality just in case. (I assume that interface identifiers derived from 802.15.4 addresses can be resolved to 802.15.4 addresses without any additional network traffic or stored state. I also assume, but haven't verified, that 16-bit 802.15.4 addresses can be used directly, and don't need to be resolved to 64-bit 802.15.4 addresses.) It appears to me that restricting 6lowpan interface identifiers to those derived from 64-bit and 16-bit 802.15.4 addresses is a really big win. First, this restriction would eliminate the need for _every_ 6lowpan device to implement an IPv6-like address resolution function, thereby reducing the minimum memory footprint of all 6lowpan implementations. Second, this restriction would eliminate the possibility that any 6lowpan device would ever need to use an IPv6-like address resolution capability, thereby avoiding (what to my mind is) unnecessary additional network traffic and state storage. - - - - As Jonathan points out, the issue of duplicate address detection (DAD) is far less clear (well, at least to me). I understand that any 6lowpan device that creates only interface identifiers in which the Universal/Local (U/L) bit is set (to indicate that the identifier is globally unique) will not need to implement DAD functionality. This leaves 6lowpan devices that create interface identifiers in which the U/L bit is zero. These include arbitrary, not-globally-unique interface identifiers, as well as interface identifiers derived from 16-bit 802.15.4 addresses. However, as I note below, making DAD actually work for these devices could be non-trivial. It appears to me that restricting 6lowpan interface identifiers to those derived from 64-bit and 16-bit 802.15.4 addresses will eliminate the need for any 6lowpan device to implement a duplicate address detection capability. Interface identifiers derived from (globally unique) 64-bit 802.15.4 [MAC] addresses are assured to be globally unique. I assume that we can rely upon the 802.15.4 PAN controller to ensure that 16-bit 802.15.4 addresses are unique within the PAN. The part I don't understand is how DAD will work when: 1. A 6lowpan device might create an arbitrary interface identifier that is the same as a 16-bit 802.15.4 address (assuming that the PAN identifier is zero or unknown). Clearly the device creating an arbitrary interface identifier must execute a DAD procedure. But, what about another device that later joins the network and derives its interface identifier from a 16-bit 802.15.4 addresses? Does it need to execute a DAD procedure? Of course, that raises the small question of what the device could possible do, if it detects a collision. Perhaps, ask the PAN controller for another 16-bit 802.15.4 address? Or, maybe we should simmply assume that no implementor will ever use small integers as arbitrary interface identifiers... 2. An arbitrary interface identifier might conflict with the interface identifier of a device that is currently sleeping (which, in some networks might be most of the devices most of the time). Are we going to develop a DAD algorithm that assumes that most of the potentially conflicting devices might be sleeping most of the time? I think that the loss of functionality that results from restricting 6lowpan interface identifiers to 64-bit and 16-bit 802.15.4 addresses is minimal (and might even be null), but the benefits are substantial. I recommend we make this change to the 6lowpan format document. -tjs _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Jul 16 01:40:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAJJt-0004li-2s; Mon, 16 Jul 2007 01:40:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAJJq-0004f6-TF for rsn@ietf.org; Mon, 16 Jul 2007 01:40:26 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAJJq-0003Dq-G1 for rsn@ietf.org; Mon, 16 Jul 2007 01:40:26 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id EF20316B0001; Sun, 15 Jul 2007 22:39:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [192.168.1.124] (adsl-71-142-73-24.dsl.pltn13.pacbell.net [71.142.73.24]) by secure.archedrock.com (Postfix) with ESMTP id 09A6A16B0001; Sun, 15 Jul 2007 22:39:52 -0700 (PDT) Message-ID: <469B04A5.5070304@archrock.com> Date: Sun, 15 Jul 2007 22:39:49 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Timothy J. Salo" Subject: Re: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing" References: <496204.11117.qm@web81903.mail.mud.yahoo.com> <469948DC.1060302@saloits.com> <4699AFFB.8020204@archrock.com> <469ADE57.2070106@saloits.com> In-Reply-To: <469ADE57.2070106@saloits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Timothy J. Salo wrote: > Support for the minimum IPv6 MTU enables 6lowpan devices to interoperate > with traditional IPv6 hosts. Ensuring interoperability between 6lowpan > devices and non-6lowpan IPv6 hosts seems to be a pretty important > objective. True. Though I don't think any LoWPAN network will ever operate as a transit network for more capable networks. Thus, leaving interoperability in LoWPAN networks to imply that protocols and applications will actually process such large packets. I suspect very few, if any, will make use of the full minimum IPv6 MTU. The one exception is ICMP, but do we really expect LoWPAN nodes to generate ICMP errors to maximum sized packets? > Arbitrary link-local interface identifiers, on the other hand, do not > appear to provide any benefits that are nearly so fundamental. Perhaps > they are useful in some circumstances (although I haven't heard what > these circumstances might be) but they don't appear to be really > important, much less facilitate interoperability. There are a class of applications that may require support for privacy extensions. One of the major issues with RFID is privacy. Like RFID, current or future LoWPAN application may associate a LoWPAN node with an item or person, making tracking possible without the users knowledge or consent. It's not that I'm a privacy advocate, but privacy tends to be a concern that slows or inhibits technology adoption and shouldn't be treated lightly. If we do decide to adopt the approach you suggest, then we should either provide a solution that satisfies privacy advocates or understand that we will face adoption hurdles in those applications. > I think that the loss of functionality that results from restricting > 6lowpan interface identifiers to 64-bit and 16-bit 802.15.4 addresses > is minimal (and might even be null), but the benefits are substantial. > I recommend we make this change to the 6lowpan format document. I agree with you that tying LoWPAN interface identifiers to 802.15.4 addresses removes the need for both address resolution and DAD. If we are comfortable with dropping privacy extensions, then it will definitely lower the resource requirements of LoWPAN implementations. If privacy wasn't an issue, then I'm all for it. The key question is whether the lowered resource requirements outweigh the benefits of privacy extensions. While we could get concrete numbers for the former, the latter is a bit more difficult to quantify. Where on the tipping point do people think we lie? Are there other applications or use cases where arbitrary interface identifiers are desirable? FYI, there is some work within LoWPAN to minimize ND costs in LoWPAN networks. Though I haven't had a chance to look at it in detail yet. http://tools.ietf.org/wg/6lowpan/draft-chakrabarti-6lowpan-ipv6-nd-03.txt -- Jonathan Hui jhui@archrock.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Jul 17 01:25:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAfYm-00082E-1N; Tue, 17 Jul 2007 01:25:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAfYk-00081v-9t for rsn@ietf.org; Tue, 17 Jul 2007 01:25:18 -0400 Received: from darkness.externet.hu ([212.40.96.183] helo=mail-xgw2.externet.hu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAfYj-0004fY-JB for rsn@ietf.org; Tue, 17 Jul 2007 01:25:18 -0400 Received: (qmail 25965 invoked from network); 17 Jul 2007 05:25:03 -0000 Received: from pool-019a0.externet.hu (HELO pocok) (rolivida@externet.hu@88.209.195.160) by 0 with ESMTPA; 17 Jul 2007 05:25:03 -0000 From: "Rolland Vida" To: Date: Tue, 17 Jul 2007 07:25:02 +0200 Organization: bme MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfIMtNiPd8GRrEGTYS36Xsq1OPdtw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: pwsn@tmit.bme.hu Subject: [RSN] PWSN 2007 - submission deadline extended X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Message-Id: Please accept our apologies for multiple copies ======================================================================= CALL FOR PAPERS ======================================================================= PWSN 2007 2nd Int'l Workshop on Performance Control in Wireless Sensor Networks held in conjunction with WICON, the 3rd Annual International Wireless Internet Conference October 23, 2007, Austin, Texas, USA http://www.pwsn.org/ ======================================================================= IMPORTANT DATES ======================================================================= Full Papers due (EXTENDED): July 30, 2007 Notification of Acceptance: August 31, 2007 Camera-ready Manuscripts due: September 10, 2007 ======================================================================= SCOPE ======================================================================= The aim of PWSN 2007 is to bring together professionals from academia and industry to discuss performance issues in wireless sensor networks (WSNs). WSNs are today the subject of intense research, with many prototype installations being investigated. However, most of the currently deployed sensor networks have in common the fact that they are not considered time critical, i.e., no immediate action has to be undertaken as a response to the received data. In contrast, many envisioned future application areas of WSNs (such as plant automation and control, traffic management, medical applications, emergency solutions) require immediate and guaranteed actions. In such environments, data has to be transported reliably and in time through the sensor network towards the end user. To make the networking task more complex, in many applications the end user or the controlling intelligence is located remotely (e.g., remote monitoring, supervision and surveillance applications), and the WSN interworks with other networks (e.g., fixed infrastructure cellular, Internet). Due to the lack of appropriate models, components, and protocols it is currently very difficult to construct and operate a wireless sensor network with performance guarantees. Thus, the commercial success of WSNs in many application areas is unsure unless this particular problem is understood and solved. Areas of interest include, but are not limited to: * Models: Traffic models, channel models, mathematical models to balance performance parameters in the network. * MAC protocols: MAC protocols with deterministic behavior, MAC protocols to balance forwarding performance and energy consumption. * Routing and topology control: Methods to stabilize network topology, topology robustness. * Data transport: Control of data transport delay and reliability, methods to improve data forwarding performance. * Operating systems: Performance optimization and control of sensor network operating systems. * Middleware and frameworks: Middleware/frameworks providing performance guarantees for sensor network applications. * Security: The impact of security features on network performance. ======================================================================= PAPER SUBMISSION ======================================================================= Papers will be submitted by electronic submission through the COCUS system. The page limit is 8 pages in ACM double column format with fonts not smaller than 10 points. The workshop papers will be included in the ACM Digital Library, and take into consideration to be indexed by EI. Authors of accepted papers are expected to register and present the paper at the Workshop. Submitted papers can report on work in progress. ======================================================================= TECHNICAL PROGRAM COMMITTEE ======================================================================= . Nirupama Bulusu - Portland State University, USA . Levente Buttyan - Budapest University of Techn. and Econ., HU . Abdelmajid Khelil - Technical University of Darmstadt, DE . Hai Liu - University of Ottawa, CAN . Ren Ping Liu - CSIRO ICT Centre, AUS . Christos Panayiotou - University of Cyprus, CYP . Iain Phillips - Loughborough University, UK . Radha Poovendran - University of Washington, USA . Hartmut Ritter - Freie Universitaet Berlin, DE . Utz Roedig - Lancaster University, UK . Jens Schmitt - University of Kaiserslautern, DE . Cormac J. Sreenan - University College Cork, IR . John A. Stankovic - University of Virginia, USA . Rolland Vida - Budapest University of Techn. and Econ., HU . Attila Vidacs - Budapest University of Techn. and Econ., HU . Marco Zuniga - Xerox Research Center, USA ======================================================================= For all further details, please visit: http://pwsn.org/ ======================================================================= _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Jul 17 12:49:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqEi-0002Df-MW; Tue, 17 Jul 2007 12:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqEh-0002DO-PT for rsn@ietf.org; Tue, 17 Jul 2007 12:49:19 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAqEh-0006xo-8J for rsn@ietf.org; Tue, 17 Jul 2007 12:49:19 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 17 Jul 2007 09:49:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOWPnEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="8974290:sNHT16149690" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6HGnIiB024186; Tue, 17 Jul 2007 09:49:18 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HGmlAO024207; Tue, 17 Jul 2007 16:49:18 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:49:11 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:49:11 -0400 In-Reply-To: <2a3692de0707091915o43ca5f3axfd49b24fd41e78a2@mail.gmail.com> References: <2366F1CE-5DB4-4BF6-B34C-3D27458BCA54@cisco.com> <2a3692de0707091915o43ca5f3axfd49b24fd41e78a2@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rl2n-routing-reqs-01.txt Date: Tue, 17 Jul 2007 12:48:35 -0400 To: Dominik Kaspar X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Jul 2007 16:49:11.0243 (UTC) FILETIME=[666B31B0:01C7C892] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5026; t=1184690958; x=1185554958; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20Fwd=3A=20I-D=20ACTION=3Adraft-culler-rl2n-rou ting-reqs-01.txt |Sender:=20; bh=fQldi5iCbtRfTAfrp0tv82MpOEvzPay7VB+bRyMxV2M=; b=kcYb3eUTXUFZFa1Op/KbBjFJ4cWz+b/EvYJxNOQCP8AkaGHOoAqP+gFYOAGozWFEaPdN/eKC Xvj5hegVDa7/22ImjjsDhxa6WnZPbRG8KSQ9unBMdspDYKf4r4EvlyN+; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Dominik, On Jul 9, 2007, at 10:15 PM, Dominik Kaspar wrote: > Hi JP, > > It's good to see the new section "Route Over versus Mesh-Under" in > your draft. We have also just updated our "6lowpan Routing > Requirements" draft, including more clarification about "mesh-under > routing". Hopefully, that will lead to a better separation. Indeed, we need to clearly show the separation to avoid confusion. > > As RSN/RL2N is currently collecting different scenarios of > applications and deployment, we hope that 6lowpan's view on routing > may also serve as valuable input for 6lowpan-specific requirements, > which can be one of the application areas for RSN/RL2N. Absolutely. > > Our updated draft should soon be available at: > http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-02.txt > I'll be happy to send comments. Cheers. JP. > Cheers, > Dominik > > On 7/10/07, JP Vasseur wrote: >> Dear all, >> >> We have updated the generic requirement document: >> >> 1) Editorial changes >> 2) RFC 2119 language >> 3) New sections: Terminology, "Route over versus Mesh-under", >> >> In the next revision, we'll cover the security (particularly >> important due >> to the MP2P traffic >> nature in some L2Ns such as Sensor Networks) and manageability >> aspects. >> >> Comments very welcome. >> >> Thanks. >> >> JP and David. >> >> Begin forwarded message: >> >> From: Internet-Drafts@ietf.org >> Date: July 8, 2007 6:15:02 PM EDT >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-culler-rl2n-routing-reqs-01.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Routing Requirements for Low Power And Lossy Networks >> Author(s) : J. Vasseur, D. Cullerot >> Filename : draft-culler-rl2n-routing-reqs-01.txt >> Pages : 11 >> Date : 2007-7-8 >> >> The need for high quality routing for Low power and Lossy Network >> (L2N) such as sensor networks comprised of highly constrained >> devices >> (CPU, memory, ...) in sometimes unstable wireless environments is >> critical now and will continue to increase. Interest in this >> class >> of applications has grown dramatically in recent years and a >> routing >> solution addressing the specific environments of such networks is >> highly required considering the numerous, incompatible open-source >> and proprietary routing protocols as well as several industrial >> forums. The aim of this document is to define the routing >> requirements for Sensor Networks at the IP layer. Such routing >> protocol(s) would need to address several unique aspects of this >> class of embedded devices and would operate in networks comprising >> links of various nature. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-culler-rl2n-routing- >> reqs-01.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of >> the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-culler-rl2n-routing-reqs-01.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-culler-rl2n-routing-reqs-01.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2007-7-8170127.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> >> _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Jul 17 19:28:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAwT0-0004QP-6x; Tue, 17 Jul 2007 19:28:30 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IAwSx-0004Pw-Sw for rsn-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 19:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAwSu-0004MQ-6q for rsn@ietf.org; Tue, 17 Jul 2007 19:28:24 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAwSs-0002w0-FI for rsn@ietf.org; Tue, 17 Jul 2007 19:28:24 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2007 16:28:23 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOfsnEarR7PE/2dsb2JhbACCYg X-IronPort-AV: i="4.16,547,1175497200"; d="scan'208,217"; a="386353595:sNHT59517850" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6HNSLdp004121; Tue, 17 Jul 2007 16:28:21 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6HNSK6C000715; Tue, 17 Jul 2007 23:28:21 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 19:28:20 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 19:28:19 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: Dominik Kaspar Message-Id: <81EB2115-F598-4D0D-871D-12B51CE51B0B@cisco.com> From: JP Vasseur Date: Tue, 17 Jul 2007 19:27:43 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Jul 2007 23:28:19.0610 (UTC) FILETIME=[28C1FFA0:01C7C8CA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15911; t=1184714901; x=1185578901; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Comments=20on=20draft-dokaspar-6lowpan-routreq-02 |Sender:=20; bh=BqpXcroi8LqiypH4AalnPmu0XmmDMsYc2q+IZfpnN2w=; b=aGtqIYtct2Q5TMsKK/BU30FXS8JQ6OAuFVS2wXzyCzsd2gjYzuqOxVRfOxozt5q0Syw7vhew 6pgM7my8wYa9TTuAGCz4Aex1Pqrf5d26urEBT2u28pBKlXzXgWw2+qpA; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1263026645==" Errors-To: rsn-bounces@ietf.org --===============1263026645== Content-Type: multipart/alternative; boundary=Apple-Mail-75-249233839 --Apple-Mail-75-249233839 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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. --Apple-Mail-75-249233839 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear Coauthors,

Few Comments = on=A0draft-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 ...=A0

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

=A0 =A0These fundamental = features of LoWPANs can affect the design of
=A0= =A0 routing solutions, so that existing routing specifications should = be
=A0=A0 simplified and modified to the smallest extent = possible, in order to
=A0=A0 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

=A0 =A0In order to find = energy-optimal routing paths, LoWPAN mesh routing
=A0= =A0protocols should minimize power consumption by utilizing = a
=A0=A0 combination of the link quality indication = (LQI) provided by the MAC
=A0=A0 layer and other = measures, such as hop count.=A0 Route repair and = route
=A0=A0 error messages should be avoided for minimizing = the overall number of
=A0=A0 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

=A0 =A0Transparent IP = routing between LoWPAN domains and higher layer
=A0= =A0 networks must be provided bidirectionally.=A0 A LoWPAN mesh = routing
=A0=A0 protocol must allow = for gateways to forward packets out of the local
=A0= =A0 domain and it must be possible to query a LoWPAN device from = outside
=A0=A0 of the local = domain.=A0 Strategies must be considered to avoid = battery
=A0=A0 depletion of nodes = by too many queries from higher level networks.
=A0= =A0 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

=A0 =A0Because network = layer routing imposes too much overhead for LoWPANs
JP>= Which Routing protocol ?

=A0= =A0 and link layer techniques are out of scope of IETF, LoWPAN = mesh
=A0=A0 routing should be performed within the = adaptation layer defined in
=A0=A0 [3].=A0 Both = addressing modes provided by the IEEE 802.15.4 = standard,
=A0=A0 16-bit short = addresses and 64-bit extended addresses, must be
=A0= =A0 considered by LoWPAN mesh routing protocols.=A0 It is also assumed = that
=A0=A0 nodes participating in LoWPAN mesh routing are = assigned only a single
=A0=A0 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.
= --Apple-Mail-75-249233839-- --===============1263026645== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1263026645==-- From rsn-bounces@ietf.org Wed Jul 18 03:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4Cu-0001dD-DQ; Wed, 18 Jul 2007 03:44:24 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IB4Ct-0001cV-Ao for rsn-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 03:44:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4Cp-0001bw-QG for rsn@ietf.org; Wed, 18 Jul 2007 03:44:19 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IB4Co-0007hX-0v for rsn@ietf.org; Wed, 18 Jul 2007 03:44:19 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2007 09:44:17 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACZhnUaQ/uCLh2dsb2JhbACPQwEBCQon X-IronPort-AV: i="4.16,549,1175464800"; d="scan'208"; a="148327692:sNHT32556928" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6I7iHdj001076; Wed, 18 Jul 2007 09:44:17 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6I7i6kt017704; Wed, 18 Jul 2007 07:44:10 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:44:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-LayerRouting" Date: Wed, 18 Jul 2007 09:44:03 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC043D06B1@xmb-ams-337.emea.cisco.com> In-Reply-To: <469B04A5.5070304@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-LayerRouting" Thread-Index: AcfHa84jl6orPMlDQxmDIuOacyGDjgBnIUGA References: <496204.11117.qm@web81903.mail.mud.yahoo.com> <469948DC.1060302@saloits.com><4699AFFB.8020204@archrock.com> <469ADE57.2070106@saloits.com> <469B04A5.5070304@archrock.com> From: "Pascal Thubert \(pthubert\)" To: "Jonathan Hui" , "Timothy J. Salo" X-OriginalArrivalTime: 18 Jul 2007 07:44:06.0281 (UTC) FILETIME=[6B27C790:01C7C90F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4343; t=1184744657; x=1185608657; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[RSN]=20Re=3A=20[6lowpan]=20=22Link-Local=20Routing=2 2=20versus=20=22Network-LayerRouting=22 |Sender:=20; bh=Z7yTYowywu2EOngVujVdw9i5db55iqxAvSrHvt122Us=; b=od/Pt2CpFRMhkJWsIRegRP6mSLPWBqA8N5Kem8TYOl1j8+hSZiEu7NrhH8Xp4n476mWW9Zhn CFhvWXJciW6Dgb9qYrW5uOHarLcO1jRk+8GjCuLekmWe1cVODn3OenZm; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Jonathan >Timothy J. Salo wrote: >> Support for the minimum IPv6 MTU enables 6lowpan devices to interoperate >> with traditional IPv6 hosts. Ensuring interoperability between 6lowpan >> devices and non-6lowpan IPv6 hosts seems to be a pretty important >> objective. > >True. Though I don't think any LoWPAN network will ever operate as a >transit network for more capable networks. Thus, leaving >interoperability in LoWPAN networks to imply that protocols and >applications will actually process such large packets. I suspect very >few, if any, will make use of the full minimum IPv6 MTU. The one >exception is ICMP, but do we really expect LoWPAN nodes to generate ICMP >errors to maximum sized packets? [Pascal] Who knows? One might use a disseminated sensor network as access for some signaling, or limited upstream when no other medium is available. If we do not need that assumption, let's not make it... >> Arbitrary link-local interface identifiers, on the other hand, do not >> appear to provide any benefits that are nearly so fundamental. Perhaps >> they are useful in some circumstances (although I haven't heard what >> these circumstances might be) but they don't appear to be really >> important, much less facilitate interoperability. > >There are a class of applications that may require support for privacy >extensions. One of the major issues with RFID is privacy. Like RFID, >current or future LoWPAN application may associate a LoWPAN node with an >item or person, making tracking possible without the users knowledge or >consent. It's not that I'm a privacy advocate, but privacy tends to be a >concern that slows or inhibits technology adoption and shouldn't be >treated lightly. If we do decide to adopt the approach you suggest, then >we should either provide a solution that satisfies privacy advocates or >understand that we will face adoption hurdles in those applications. > [Pascal] Agreed. I understand that we decide which formats do not need DAD (those described in the draft) and decide that those are ever DADed, or are optimistically DADed. But that does not secure the address ownership like SeND does. I understand that a device could roll its 16-bit short address if it really wanted to for privacy reasons, correct?=20 If so, what I'd suggest is that when the u/l bit is set to local, we force the 16 bits at a given place, say the last bits of the address, and leave the rest up to the device. That way, DAD is not necessary and the specification is still open for the device to do what it likes with the rest of the address, such as a CGA that we would define over 48 bits instead of 64. >> I think that the loss of functionality that results from restricting >> 6lowpan interface identifiers to 64-bit and 16-bit 802.15.4 addresses >> is minimal (and might even be null), but the benefits are substantial. >> I recommend we make this change to the 6lowpan format document. > >I agree with you that tying LoWPAN interface identifiers to 802.15.4 >addresses removes the need for both address resolution and DAD. If we >are comfortable with dropping privacy extensions, then it will >definitely lower the resource requirements of LoWPAN implementations. >If privacy wasn't an issue, then I'm all for it. The key question is >whether the lowered resource requirements outweigh the benefits of >privacy extensions. While we could get concrete numbers for the former, >the latter is a bit more difficult to quantify. Where on the tipping >point do people think we lie? Are there other applications or use cases >where arbitrary interface identifiers are desirable? > >FYI, there is some work within LoWPAN to minimize ND costs in LoWPAN >networks. Though I haven't had a chance to look at it in detail yet. >http://tools.ietf.org/wg/6lowpan/draft-chakrabarti-6lowpan-ipv6-nd-03.t xt [Pascal] It seems fair to believe that the coordinators and FFDs will end up proxying ND and some routing for the RFDs, which this draft proposes. At the moment, the IPv6 routers do not talk 6LowPAN and there's a gateway that interconnects say, Ethernet and 802.15.4. Should there be a specific 6LowPAN ND support in the router? And can we define that functionality so that it can be proxyed/snooped in the gateway? Pascal _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Jul 18 04:03:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4V0-0003BA-KL; Wed, 18 Jul 2007 04:03:06 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IB4Ux-00032D-Pd for rsn-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 04:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4Ux-00030F-Cl for rsn@ietf.org; Wed, 18 Jul 2007 04:03:03 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB4Uv-0007Zq-Rr for rsn@ietf.org; Wed, 18 Jul 2007 04:03:02 -0400 Received: by py-out-1112.google.com with SMTP id f31so346239pyh for ; Wed, 18 Jul 2007 01:03:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CngjsvW/s9f03YmMOvHkB4v6Yqpq3ZjdzAePWnYeFEtJz2APE3AQ4mM/iUVdOJYdvdBXzu0YxQjVBQQ3P5E5Ui6SXbxqqkJXPNw37MjcCDgPj8LU1R4NiOf2br7PTTxJYwPcMaqJXwqnDo5FBeLmabpSU/Afm3kKEwT7CBo3PPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BW+aPM0RvSzSfa8rZ9OA/t/eNzKHcBfUkEgkeKxnFeZGc/4dB+PoDo+/Cdyykv8dU0xIzRpGqy9Rk2zjUcLCrktmHEan10Zd4Ps1Jp40n66ZrO11nvc8qPr3Q0f3jdv0Muw17OGj8Lo/RCRn70nNOuZ5nSMSFZdsZY3AO95d5Wc= Received: by 10.141.197.18 with SMTP id z18mr346969rvp.1184745780272; Wed, 18 Jul 2007 01:03:00 -0700 (PDT) Received: by 10.140.161.21 with HTTP; Wed, 18 Jul 2007 01:03:00 -0700 (PDT) Message-ID: <2a3692de0707180103t79e7d0e2p75b74a88bacbe0d7@mail.gmail.com> Date: Wed, 18 Jul 2007 17:03:00 +0900 From: "Dominik Kaspar" To: "JP Vasseur" In-Reply-To: <81EB2115-F598-4D0D-871D-12B51CE51B0B@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <81EB2115-F598-4D0D-871D-12B51CE51B0B@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [RSN] Re: Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org 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 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. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Jul 18 04:56:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5KQ-0003eP-Vg; Wed, 18 Jul 2007 04:56:14 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IB5KP-0003dX-JY for rsn-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 04:56:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5KP-0003d8-3U for rsn@ietf.org; Wed, 18 Jul 2007 04:56:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB5KO-0001Cl-Kc for rsn@ietf.org; Wed, 18 Jul 2007 04:56:13 -0400 Received: by ug-out-1314.google.com with SMTP id u2so678044uge for ; Wed, 18 Jul 2007 01:56:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=XWe6SWOAqnKlG/6E0ji+2tpvCfCE4YL20k+0jlzy7jfuy6Zah3EwDr7yW8IWkh+LG+LGsCtcIVuGEKbTYoAwO4NQy8oDiOKwyzAN1/Wx4vZlo246do+syIGn4u2K2NLhGjhcYXrOEdKx4QcXbJl/xOKoDHr0iURQVFM7LTEhX1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qqSG5ckZ4079NFsiXUYCqm/30qCVdht2JKffS9ADAL1pFaeXOJAZsnLSWxO8ip9zhZy1kW9kp/yu3DlBz1OsjP5Ayl51m2jiaq84byLW5EY66fFZt0lGqu0cWlVjvPTkHim3bsIrBo7q3fI74Wmpv/53/900gst78B6UzT3LTdo= Received: by 10.67.99.4 with SMTP id b4mr170731ugm.1184748972036; Wed, 18 Jul 2007 01:56:12 -0700 (PDT) Received: by 10.142.108.5 with HTTP; Wed, 18 Jul 2007 01:56:11 -0700 (PDT) Message-ID: <77f1dba80707180156j3c2abb19ye150c7f0a01ca801@mail.gmail.com> Date: Wed, 18 Jul 2007 17:56:11 +0900 From: "Eunsook \"Eunah\" Kim" To: 6lowpan <6lowpan@lists.ietf.org>, manet@ietf.org, rsn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [RSN] Soliciting comments on 'draft-oh-6lowpan-packetbb-dymoapp-00' X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear all, For our project experiments, we have tried to apply an existing ad-hoc routing solution to our sensor network testbed. We chose to simplify both DYMO and the corresponding PacketBB for application to 6LoWPAN. We carried out this experiment as one example of "How to apply exisiting protocols to 6LoWPAN", and we hope that our document will serve as an informative input for discussing routing issues in 6LoWPAN, by... - providing guidelines on how to simplify existing ad-hoc routing solutions, and - defining a PacketBB for 6LoWPAN. The draft is available at: http://www.ietf.org/internet-drafts/draft-oh-6lowpan-packetbb-dymoapp-01.txt Thanks, -eunsook PS: I've put this on the RSN and MANET lists too, as some folks there might be interested in seeing this. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Jul 18 09:53:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB9yB-00086A-5i; Wed, 18 Jul 2007 09:53:35 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IB9y9-00085d-Mm for rsn-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 09:53:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB9y9-00085U-45 for rsn@ietf.org; Wed, 18 Jul 2007 09:53:33 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IB9y5-0002dx-NO for rsn@ietf.org; Wed, 18 Jul 2007 09:53:33 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id B2C6C1DDC3B7; Wed, 18 Jul 2007 06:53:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE,MSGID_FROM_MTA_ID autolearn=no version=3.1.8 Received: from GoatRock (64-142-4-192.dsl.static.sonic.net [64.142.4.192]) by secure.archedrock.com (Postfix) with ESMTP id 587AA1DDC3B9; Wed, 18 Jul 2007 06:53:23 -0700 (PDT) From: "dculler" To: "'JP Vasseur'" , "'Dominik Kaspar'" Subject: RE: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 Date: Wed, 18 Jul 2007 06:53:19 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfIyjKGU/GBi0frRxSITDycth8L7QAMx6gQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <81EB2115-F598-4D0D-871D-12B51CE51B0B@cisco.com> Message-Id: <20070718135323.587AA1DDC3B9@secure.archedrock.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: e02509f7a15c0aaea12155beed3396f0 Cc: '6lowpan' <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dculler@archrock.com List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1317521378==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============1317521378== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7C908.551417D0" This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C7C908.551417D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:jvasseur@cisco.com] Sent: Tuesday, July 17, 2007 4:28 PM To: Dominik Kaspar Cc: 6lowpan; rsn@ietf.org 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. ------=_NextPart_000_0004_01C7C908.551417D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The argument for route-over is pretty=20 simple.
 
1. In the vast majority of wireless sensor = networks in=20 existance the dominant communication pattern is data collection (from = nodes in=20 the PAN to IP-based computers external to the PAN) and control = actions=20 (from controllers external to the PAN to devices within the PAN).  = There=20 are cases where data collection point and/or the controller is a = gateway=20 device on the PAN, but this physical collocation is rather=20 artificial.  If is far more typical that where a gateway is = deployed=20 it is used to bridge communication to other=20 networks.  
 
This is true not only for wireless = instrumentation, but=20 wired instrumentation as well.  See for example
 
BACNET: http://ww= w.bacnet.org/Tutorial/HMN-Overview/sld028.htm and=20 http://ww= w.bacnet.org/Tutorial/HMN-Overview/sld029.htm 
 
and
 
HART: http://www.hartcomm2.org/hart_protocol/tech_info/eval_network= s/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=20 address for the device within the PAN.  It is important for this = address to=20 be compressible, just as when both endpoints are within the PAN.  = No matter=20 how effective is the L2 mesh routing within the PAN, you still need to = deal with=20 IP routing off the PAN.  This is, of course, the purpose of IP=20 routing.  Whatever mesh-under is done, there will also be = route-over. =20 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=20 distinct networks that use the same media, ie. distinct Ethernet subnets = or=20 distinct WiFi subnets.  This will happen in 802.15.4 networks where = the=20 networks use the same physical link, but different PAN_IDs, different = channels=20 (or different sets of channels or different channel schedules), = different MAC=20 layers, etc.  Even different meshing protocols.  They will be = stiched=20 together by IP routing.
 
3. The Mesh-under protocol is currently=20 undefined.  6lowpan is sufficient to describe single hop=20 communication.  It also identifies the endpoints (original and = final) of=20 multihop mesh-routed communication, but it does not define how the = intervening=20 hops are determined or what information is exchanged to establish=20 routes.  Clearly it anticipates that such L2 protocols will be = developed and standardized.  However, if a single 802.15.4 = hop is=20 performed per IP hop, any L3 routing algorithm can be used to set up the = routing=20 tables and forwarding occurs according to the routing tables.  = (Worst come=20 to worst, you can hammer the tables in place by external means.) If mesh = routing=20 does become defined, IP routing can be applied per L2 mesh path.  = Thus, IP=20 routing applies whether or not mesh routing is defined.  All of the = IP=20 visibility and management tools apply to the IP hops.  None of them = apply=20 to the mesh hops within an IP hop.
 
4. Many IP routing protocols are defined and = a=20 diversity of protocols has become the norm.  One of the key = elements of IP=20 is that it separates routing from forwarding.  We tolerate the use = of=20 different routing protocols in different settings.  These=20 protocols set up the tables and forwarding works across them.  = We have=20 had multiple competing routing protocols apply to the same setting = (e.g., RIP vs=20 OSPF in the campus area) and their relative strengths have become clear = over=20 time. 
 
This has not been the case with link-level = "meshing";=20 so far it has been approached as a winner-take-all and unfortunately = this means=20 that everybody must agree on the protocol before they have much = experience=20 with the use of the protocol.  For example, in Zigbee we have seen = that=20 after several years of development, but no broad usage, Zigbee 1.0 = is=20 obsoleted in favor of Zigbee 2006, which is incompatible and also = incompatible=20 with Zigbee 2007, which is not yet fully defined.  We have seen = numerous=20 proprietary protocols, proprietary extensions to standard protocols, and = open=20 research protocols for meshing that are all incompatible.  In some = cases=20 they optimize for different aspects, in some cases they integrate = aspects of all=20 layers of the stack.  In any case, they don't play well together. = So, one=20 of the key virtues of route-over is that we have an established = framework and=20 long history of stiching together a variety of routing protocols to = establish=20 the tables such that forwarding works across them and where we can gain=20 experience over time.  Call it "rough consensus and running=20 code".
 
One might argue these aspects are = sociological, rather=20 than technical.  Well, the separation of topology formation, path=20 selection, and route table maintainance from forwarding is awfully=20 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=20 be developed for the PAN for mesh-under to mature.  It is an = interesting=20 question whether you need to be within the PAN to utilize the equivalent = of=20 traceroute.
 
5. History suggests that once IP routing is = available=20 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"=20 routing in switched ethernets and mesh wifi, but generally it is=20 transparent.  The link looks like the unswitched=20 counterpart.
 
So I think it is very clear that IP routing = will occur=20 over IEEE 802.15.4 links.  It is already there.  For = every single=20 hop 15.4 network it is done.  For deeper networks, there are many = ways to=20 set up the tables.   
 
So route-over is a fact.  The = question should=20 be "Do you need mesh-under in addition to route-over?" =20 Why?
 

From: JP Vasseur = [mailto:jvasseur@cisco.com]=20
Sent: Tuesday, July 17, 2007 4:28 PM
To: Dominik=20 Kaspar
Cc: 6lowpan; rsn@ietf.org
Subject: [RSN] = Comments=20 on draft-dokaspar-6lowpan-routreq-02

Dear = Coauthors,
Few Comments on=20 draft-dokaspar-6lowpan-routreq-02.
First of all, I think = that we=20 will need to have that debate on whether we indeed need both a = "Mesh-under"=20 and a "Route over" solutions. If the answer turns out to be "yes, we = need=20 both" I would volunteer to write the ID capturing the pros and cons = ...=20
In the meantime, here = are a few=20 comments:
1) I would suggest to = use a=20 consistent terminology for the "Mesh-under" routing. Not trying to = quibble on=20 the terminology here but this is quite important to avoid confusion = with the=20 RSN initiative. "Lowpan mesh routing" looks more like Route = over.
2) Section = 2
These=20 fundamental features of LoWPANs can affect the design = of
routing=20 solutions, so that existing routing specifications should = be
simplified=20 and modified to the smallest extent possible, in order = to
fit the=20 low-power requirements of LoWPANs.
We had that = discussion before ...=20 Yes, if one can find an existing protocol that meets
the requirement and = that can be=20 adapted, then great. But whether any of the current
protocols can be = adapted to meet=20 these requirements is not a given.
3) Section = 2
In order=20 to find energy-optimal routing paths, LoWPAN mesh = routing
protocols=20 should minimize power consumption by utilizing a
combination of the link quality indication (LQI) = provided by the=20 MAC
layer and=20 other measures, such as hop count. Route repair and = route
error=20 messages should be avoided for minimizing the overall number=20 of
control=20 messages and the required energy for sending them.
Two = comments:
* This is a = difference with=20 Route-over where we will define IP metric to reflect
the link = characteristics to be=20 used by the routing engine but we do want to
remain layer 2 = agnostic, thus the=20 need for a minimal abstraction layer.
* Should we avoid = "Route Repair"=20 ? mmm ... I'm not so sure since there are
applications that = require fast=20 rerouting to forward sensitive data. A cheap
alternative is to = compute=20 disjoint paths but this comes at the path quality
cost.
3) Section = 3
Transparent IP routing between LoWPAN domains and = higher=20 layer
networks=20 must be provided bidirectionally. A LoWPAN mesh = routing
protocol=20 must allow for gateways to forward packets out of the = local
domain and=20 it must be possible to query a LoWPAN device from = outside
of the=20 local domain. Strategies must be considered to avoid = battery
depletion=20 of nodes by too many queries from higher level = networks.
End-to-end=20 communication is not a design goal of LoWPAN.
This is one on my = main=20 motivations of a Route-over strategy.
4) Section = 3.2
Because=20 network layer routing imposes too much overhead for = LoWPANs
JP> Which=20 Routing protocol ?
and link=20 layer techniques are out of scope of IETF, LoWPAN = mesh
routing=20 should be performed within the adaptation layer defined = in
[3]. Both=20 addressing modes provided by the IEEE 802.15.4 = standard,
16-bit=20 short addresses and 64-bit extended addresses, must = be
considered=20 by LoWPAN mesh routing protocols. It is also assumed = that
nodes=20 participating in LoWPAN mesh routing are assigned only a=20 single
address/identifier and do not support multiple=20 interfaces.
Just a note here to = mention that=20 L2Ns will more than likely support multiple
interfaces thanks to = multiple non=20 overlapping frequencies.
Thanks.
JP.
------=_NextPart_000_0004_01C7C908.551417D0-- --===============1317521378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1317521378==-- From rsn-bounces@ietf.org Wed Jul 18 10:53:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAu9-0000Bs-Qv; Wed, 18 Jul 2007 10:53:29 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IBAu9-0000Bi-24 for rsn-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 10:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAu8-0000BV-OT for rsn@ietf.org; Wed, 18 Jul 2007 10:53:28 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBAu7-0003Ew-FC for rsn@ietf.org; Wed, 18 Jul 2007 10:53:28 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2007 16:53:27 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHfFnUaQ/uCLh2dsb2JhbACPQwEBCQon X-IronPort-AV: i="4.16,550,1175464800"; d="scan'208"; a="148387194:sNHT29369502" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6IErQpD018792; Wed, 18 Jul 2007 16:53:26 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6IErJkt023575; Wed, 18 Jul 2007 14:53:21 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 16:53:18 +0200 Received: from [64.103.30.15] ([64.103.30.15]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 16:53:18 +0200 Message-ID: <469E295A.9020209@cisco.com> Date: Wed, 18 Jul 2007 16:53:14 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: dculler@archrock.com Subject: Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 References: <20070718135323.587AA1DDC3B9@secure.archedrock.com> In-Reply-To: <20070718135323.587AA1DDC3B9@secure.archedrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 14:53:18.0569 (UTC) FILETIME=[60B71590:01C7C94B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=447; t=1184770406; x=1185634406; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[RSN]=20Comments=20on=20draft-dokaspar-6lowpan-routre q-02 |Sender:=20; bh=n4HYRvrrZFwovXGqwgqCPdF2O3dhJVK9s55uBKq4IN0=; b=UmmPomDDa0jRCn0rWA4P+MLEN72ELks2jSOL1+1fF2wDwsnQSrMI+M0uVGPtPC6F480eQ8u0 lfFGTJNTpzcuZc4egfkIR+jSviUa3Cm/0B/jOX05BpnkGj69xPUR17/A; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: '6lowpan' <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org 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 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Jul 18 12:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCJx-0006dN-3F; Wed, 18 Jul 2007 12:24:13 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IBCJu-0006cw-5z for rsn-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 12:24:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCJt-0006ch-RD for rsn@ietf.org; Wed, 18 Jul 2007 12:24:09 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBCJs-0005uw-Fy for rsn@ietf.org; Wed, 18 Jul 2007 12:24:09 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id DCB831DDC3BC; Wed, 18 Jul 2007 09:24:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.8 Received: from [192.168.7.194] (69-12-164-135.sfo.archedrock.com [69.12.164.135]) by secure.archedrock.com (Postfix) with ESMTP id E93A81DDC3A4; Wed, 18 Jul 2007 09:24:03 -0700 (PDT) Message-ID: <469E3E9C.5030605@archrock.com> Date: Wed, 18 Jul 2007 09:23:56 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-LayerRouting" References: <496204.11117.qm@web81903.mail.mud.yahoo.com> <469948DC.1060302@saloits.com><4699AFFB.8020204@archrock.com> <469ADE57.2070106@saloits.com> <469B04A5.5070304@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC043D06B1@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC043D06B1@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Pascal Thubert (pthubert) wrote: > [Pascal] Who knows? One might use a disseminated sensor network as > access for some signaling, or limited upstream when no other medium is > available. If we do not need that assumption, let's not make it... Looks like we both agree. My point throughout this thread was that sometimes we can't make certain assumptions even if they may have significant advantages. > [Pascal] Agreed. I understand that we decide which formats do not need > DAD (those described in the draft) and decide that those are ever DADed, > or are optimistically DADed. But that does not secure the address > ownership like SeND does. Agreed. Though some of the address security issues may be mitigated by link-layer security mechanisms. > I understand that a device could roll its 16-bit short address if it > really wanted to for privacy reasons, correct? Correct. But the availability of a short address depends on the configuration of the link-layer. According to the IEEE 802.15.4 spec, a PAN coordinator is not obligated to dole out 16-bit short addresses. I don't know how often we see this in practice, and maybe its okay if, in these cases, nodes refuse to communicate to preserve privacy. > If so, what I'd suggest is that when the u/l bit is set to local, we > force the 16 bits at a given place, say the last bits of the address, > and leave the rest up to the device. That way, DAD is not necessary and > the specification is still open for the device to do what it likes with > the rest of the address, such as a CGA that we would define over 48 bits > instead of 64. The current 6LoWPAN format draft suggests that interface identifiers derived from short addresses is done similar to RFC2464, by creating a 48-bit Ethernet-style address using the PAN ID and short address. So it doesn't support creating any form of CGA with a well-defined mapping to short addresses. But, maybe we should revisit this issue. In general, I am in agreement with Timothy Salo's proposal. Correct me if I'm wrong, but most, if not all, current 6LoWPAN implementations assume that the interface identifier and link address (16 and 64-bit) have a one-to-one mapping, including the Arch Rock implementation. It does reduce resource requirements in energy and code. I'm playing a bit of devil's advocate here to vet out that such an assumption don't cause unwanted constraints in the future. > [Pascal] It seems fair to believe that the coordinators and FFDs will > end up proxying ND and some routing for the RFDs, which this draft > proposes. At the moment, the IPv6 routers do not talk 6LowPAN and > there's a gateway that interconnects say, Ethernet and 802.15.4. Should > there be a specific 6LowPAN ND support in the router? And can we define > that functionality so that it can be proxyed/snooped in the gateway? I believe there should be 6LoWPAN support in routers. It is a better fit architecturally - it is where router-specific ND mechanisms are intended to be implemented. It can also open doors for 6LoWPAN specific extensions to ND at the router. -- Jonathan Hui jhui@archrock.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jul 19 05:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSFw-0002WM-F9; Thu, 19 Jul 2007 05:25:08 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IBSFv-0002OO-Al for rsn-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 05:25:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSFq-0001wD-H6 for rsn@ietf.org; Thu, 19 Jul 2007 05:25:02 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBSFo-0007qj-T0 for rsn@ietf.org; Thu, 19 Jul 2007 05:25:02 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jul 2007 11:25:00 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAbLnkaQ/uCLZmdsb2JhbACPSgsKJA X-IronPort-AV: i="4.16,555,1175464800"; d="scan'208"; a="148454454:sNHT189613540" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6J9OxId007864; Thu, 19 Jul 2007 11:24:59 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6J9OClT025840; Thu, 19 Jul 2007 09:24:55 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 11:24:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-LayerRouting" Date: Thu, 19 Jul 2007 11:24:25 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC043D0C0D@xmb-ams-337.emea.cisco.com> In-Reply-To: <469E3E9C.5030605@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-LayerRouting" Thread-Index: AcfJWB6mBw6qbOvFSiecjaCxel5A6wAiw4RQ References: <496204.11117.qm@web81903.mail.mud.yahoo.com> <469948DC.1060302@saloits.com><4699AFFB.8020204@archrock.com> <469ADE57.2070106@saloits.com> <469B04A5.5070304@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC043D06B1@xmb-ams-337.emea.cisco.com> <469E3E9C.5030605@archrock.com> From: "Pascal Thubert \(pthubert\)" To: "Jonathan Hui" X-OriginalArrivalTime: 19 Jul 2007 09:24:35.0513 (UTC) FILETIME=[9F455290:01C7C9E6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5231; t=1184837099; x=1185701099; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[RSN]=20Re=3A=20[6lowpan]=20=22Link-Local=20Routing=2 2=20versus=20=22Network-LayerRouting=22 |Sender:=20; bh=RMG3mdGZj8JtJbGYwgikkcyUeLix/OrrShpUfj9OPVk=; b=aXdj/myiXovr7tbwdD8ui76PXyoZMKnIlQDjKVcH5yd7YE7bbjM/KPG8KCBsizZfisHqQocJ AMHkaJlSy6v4B/TS4oNnCIuqbrFKff0zE7xiOyQLMqNJJAGNr8IjL4Dw; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Jonathan Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: Wednesday, July 18, 2007 6:24 PM >To: Pascal Thubert (pthubert) >Cc: Timothy J. Salo; 6lowpan@lists.ietf.org; rsn@ietf.org >Subject: Re: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-LayerRouting" > > >Pascal Thubert (pthubert) wrote: >> [Pascal] Who knows? One might use a disseminated sensor network as >> access for some signaling, or limited upstream when no other medium is >> available. If we do not need that assumption, let's not make it... > >Looks like we both agree. My point throughout this thread was that >sometimes we can't make certain assumptions even if they may have >significant advantages. > [Pascal] :) >> I understand that a device could roll its 16-bit short address if it >> really wanted to for privacy reasons, correct? > >Correct. But the availability of a short address depends on the >configuration of the link-layer. According to the IEEE 802.15.4 spec, a >PAN coordinator is not obligated to dole out 16-bit short addresses. I >don't know how often we see this in practice, and maybe its okay if, in >these cases, nodes refuse to communicate to preserve privacy. [Pascal] That's fine. If the burnin EUI64 address is used, we all agree that DAD can be skipped or made very very optimistic. > >> If so, what I'd suggest is that when the u/l bit is set to local, we >> force the 16 bits at a given place, say the last bits of the address, >> and leave the rest up to the device. That way, DAD is not necessary and >> the specification is still open for the device to do what it likes with >> the rest of the address, such as a CGA that we would define over 48 bits >> instead of 64. > >The current 6LoWPAN format draft suggests that interface identifiers >derived from short addresses is done similar to RFC2464, by creating a >48-bit Ethernet-style address using the PAN ID and short address. So it >doesn't support creating any form of CGA with a well-defined mapping to >short addresses. But, maybe we should revisit this issue. > [Pascal] Yes, that's specifically what I'm discussing right now. If we want to be open to some CGA or other privacy extension in the future and still avoid DAD, then there is a need to change the draft before it's too late. The proposal was that if we have a short address, we just lock its position in the IID, and leave the rest open. That ensures the uniqueness of the address and whatever game the nodes play in the future with the 46 bits left will be backward compatible. >In general, I am in agreement with Timothy Salo's proposal. Correct me >if I'm wrong, but most, if not all, current 6LoWPAN implementations >assume that the interface identifier and link address (16 and 64-bit) >have a one-to-one mapping, including the Arch Rock implementation. It >does reduce resource requirements in energy and code. I'm playing a bit >of devil's advocate here to vet out that such an assumption don't cause >unwanted constraints in the future. > [Pascal] You can not lock the draft because of early implementations, can you? Anyway, I'm don't see that I'm asking to change that? I'm just proposing to leave the rest of the IID open to the node's support of various upcoming features, as opposed to forcing the draft EUI48 format.=20 At the moment, the draft still assumes that a PAN maps to a link, so the PAN id in the IID is not necessary. If that assumption breaks later, we can always define the PAN ID in the address at that time and be backward compatible; IOW future nodes will be able to insert into a legacy network which obeys the current draft limitation (1 PAN per link) and will interact with legacy nodes that do not know better.=20 OTOH, if the legacy nodes expect the PAN ID in the EUI 48 and do something about it, they will never interwork with a newer device that needs the bits for something else, e.g. CGA. Seems to me that we share the objective is to prevent the nodes from making any unnecessary assumption. So we should agree on this, do I miss something? >> [Pascal] It seems fair to believe that the coordinators and FFDs will >> end up proxying ND and some routing for the RFDs, which this draft >> proposes. At the moment, the IPv6 routers do not talk 6LowPAN and >> there's a gateway that interconnects say, Ethernet and 802.15.4. Should >> there be a specific 6LowPAN ND support in the router? And can we define >> that functionality so that it can be proxyed/snooped in the gateway? > >I believe there should be 6LoWPAN support in routers. It is a better fit >architecturally - it is where router-specific ND mechanisms are intended >to be implemented. It can also open doors for 6LoWPAN specific >extensions to ND at the router. > [Pascal] Things like MLD can be snooped in a switch, and there has been some effort in the past for ND proxy. Depending on how things are done, such things could happen for 6LowPAN or not. We might make it a goal or a non goal. Your answer makes it a non goal. I'm fine with that, I just wanted to make it clear to the lists that there was an option there. Pascal _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jul 20 05:41:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBoyw-0000dj-Nc; Fri, 20 Jul 2007 05:41:06 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IBoyv-0000d2-2O for rsn-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 05:41:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBoyr-0000bR-3V for rsn@ietf.org; Fri, 20 Jul 2007 05:41:01 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBoyp-0002L1-Qr for rsn@ietf.org; Fri, 20 Jul 2007 05:41:01 -0400 Received: by py-out-1112.google.com with SMTP id f31so2710577pyh for ; Fri, 20 Jul 2007 02:40:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K8k+ug0dKzpGApjDjOssEIZXX+U57RzuJ4FDHEOHL09+TTODBdZq2WYnfUbPWR/MqdZkYxMwAy/RUGwR/TqhwmCrtGhD47h48t9vSwHvxgWn+kv39Hvv4TLpjtPBbowCtW9QAvVu6RrnHiWNQRzaz8jQZTK5VK8X5YZtRpGz/pw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b9dH6AgpAD2DSERnQoxJrAZIlb0oXDtNt/sNgDNLmhA6zRvpXzxKuVgG/S7IHVRqOH7+MPdFmTh/UHDFNOLwlxJjxXA0ECLuQ0gEm+FY1WYtgPyOuHkuNZm9ranksOFfn7+8ATYH1gY9Y1qmBiICUPJ4pMr/qzVn2YHYTiIDG2w= Received: by 10.140.170.12 with SMTP id s12mr84683rve.1184924458792; Fri, 20 Jul 2007 02:40:58 -0700 (PDT) Received: by 10.140.161.21 with HTTP; Fri, 20 Jul 2007 02:40:58 -0700 (PDT) Message-ID: <2a3692de0707200240p3776b78cj718c027b67cce3e0@mail.gmail.com> Date: Fri, 20 Jul 2007 18:40:58 +0900 From: "Dominik Kaspar" To: dculler@archrock.com Subject: Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 In-Reply-To: <20070718135323.587AA1DDC3B9@secure.archedrock.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <81EB2115-F598-4D0D-871D-12B51CE51B0B@cisco.com> <20070718135323.587AA1DDC3B9@secure.archedrock.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org 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 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:jvasseur@cisco.com] > Sent: Tuesday, July 17, 2007 4:28 PM > To: Dominik Kaspar > Cc: 6lowpan; rsn@ietf.org > 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 RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jul 20 12:51:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvh3-0003m5-U4; Fri, 20 Jul 2007 12:51:05 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IBvh2-0003ln-OR for rsn-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 12:51:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvh2-0003ld-CS for rsn@ietf.org; Fri, 20 Jul 2007 12:51:04 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBvh1-0007Av-Ls for rsn@ietf.org; Fri, 20 Jul 2007 12:51:04 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id BDF201DDC100; Fri, 20 Jul 2007 09:51:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.8 Received: from [192.168.7.194] (69-12-164-135.sfo.archedrock.com [69.12.164.135]) by secure.archedrock.com (Postfix) with ESMTP id 4C4CD1DDC3BE; Fri, 20 Jul 2007 09:50:28 -0700 (PDT) Message-ID: <46A0E7CD.4050906@archrock.com> Date: Fri, 20 Jul 2007 09:50:21 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dominik Kaspar Subject: Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 References: <81EB2115-F598-4D0D-871D-12B51CE51B0B@cisco.com> <20070718135323.587AA1DDC3B9@secure.archedrock.com> <2a3692de0707200240p3776b78cj718c027b67cce3e0@mail.gmail.com> In-Reply-To: <2a3692de0707200240p3776b78cj718c027b67cce3e0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dominik Kaspar wrote: > 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. [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. > 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. [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. > 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. [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 jhui@archrock.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jul 20 16:59:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBzZa-0005fE-8l; Fri, 20 Jul 2007 16:59:38 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IBzZZ-0005f6-Ah for rsn-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 16:59:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBzZY-0005er-QH for rsn@ietf.org; Fri, 20 Jul 2007 16:59:36 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBzZY-0001uz-8u for rsn@ietf.org; Fri, 20 Jul 2007 16:59:36 -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 l6KKxRtR030935; Fri, 20 Jul 2007 15:59:35 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <46A12227.7080701@saloits.com> Date: Fri, 20 Jul 2007 15:59:19 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [RSN] Link-Local versus Network Routing at IETF-69 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org The IETF-69 BOF status page says that the RSN BoF will not meet until the Vanvouver IETF, but that the problem space will be presented in the Routing Area Working Group meeting (17:40 Tuesday) or equivalent venue. Has a venue for the RSN non-BOF discussion been established yet? It doesn't seem to be on the current rtgwg agenda. This discussion, where ever it occurs, may be an excellent opportunity (although not the only one) to discuss whether separate link-local and network routing protocols are likely to be required for low-power wireless networks. My [current] view is that link-local and network routing protocols adapted to low-power wireless network have a lot more in common than they do differences. They seem to share a lot of hard problems (e.g., support for a class of nodes that is severely resource constrained, support for nodes that sleep most of the time, the lack of an efficient link-wide multicast/broadcast capability, etc.). In contrast, the scope of the routing protocol (link-local versus network-wide) seems like a comparatively minor variation, even if the link-local version ends up using link-layer addresses (of course, I continue to argue that in 6lowpan networks the mapping between link-layer addresses and network-addresses should be trivial, which would seem to moot this argument). At any rate, at this time I am strongly opposed any of the two, largely independent efforts to develop/adapt a routing protocol for low-power wireless networks (6lowpan and rsn) being described as standards-track. I believe that both of these efforts should be classified as "experimental" until either they are converged, or a strong case has been made that two, independent routing protocols are really required. -tjs _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jul 20 21:36:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC3ti-0005Zl-Qd; Fri, 20 Jul 2007 21:36:42 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IC3tg-0005Yy-UR for rsn-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 21:36:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC3tg-0005WY-G2 for rsn@ietf.org; Fri, 20 Jul 2007 21:36:40 -0400 Received: from mail.globalsuite.net ([69.46.103.200]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IC3tf-0006zM-7T for rsn@ietf.org; Fri, 20 Jul 2007 21:36:40 -0400 X-AuditID: c0a8013c-ad6c0bb000003048-19-46a16323b7cf Received: from [172.17.167.32] (unknown [207.236.7.194]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id D0FF64DC008; Fri, 20 Jul 2007 19:36:34 -0600 (MDT) In-Reply-To: <2a3692de0707180103t79e7d0e2p75b74a88bacbe0d7@mail.gmail.com> References: <81EB2115-F598-4D0D-871D-12B51CE51B0B@cisco.com> <2a3692de0707180103t79e7d0e2p75b74a88bacbe0d7@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3DF4E8A6-051D-4193-BD27-2AC997861188@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Fri, 20 Jul 2007 21:34:05 -0400 To: Dominik Kaspar X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [RSN] Re: Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Dominik, On Jul 18, 2007, at 4:03 AM, Dominik Kaspar wrote: > 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. > Fully agree. > 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. > 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. > 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. OK. > 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. > Well does not have to be in the ID then but thanks for the clarification. > 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". Stay tuned ... we should get the first draft soon, to which comments/ contribution will be very welcome. > > * 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. > 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. > 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, As pointed out before, this is of course not the only motivations. > 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. I see, not sure this should be mentioned in the requirement document. > > 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. JP. > > Thanks. > > > On 7/18/07, JP Vasseur 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. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jul 20 21:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC42n-0003f4-CM; Fri, 20 Jul 2007 21:46:05 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IC42l-0003an-SI for rsn-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 21:46:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC42k-0003Yr-KM for rsn@ietf.org; Fri, 20 Jul 2007 21:46:02 -0400 Received: from mail.globalsuite.net ([69.46.103.200]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IC42i-000776-22 for rsn@ietf.org; Fri, 20 Jul 2007 21:46:02 -0400 X-AuditID: c0a8013c-ab6bcbb000003048-df-46a165536a0c Received: from [172.17.167.32] (unknown [207.236.7.194]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 924544DC00A; Fri, 20 Jul 2007 19:45:51 -0600 (MDT) In-Reply-To: <20070718135323.587AA1DDC3B9@secure.archedrock.com> References: <20070718135323.587AA1DDC3B9@secure.archedrock.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: JP Vasseur Subject: Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 Date: Fri, 20 Jul 2007 21:45:13 -0400 To: X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8104b3fcabb4d2dfaed548848b9dc80f Cc: '6lowpan' <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1919742188==" Errors-To: rsn-bounces@ietf.org --===============1919742188== Content-Type: multipart/alternative; boundary=Apple-Mail-24-516683745 --Apple-Mail-24-516683745 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Adding a few comments ... On Jul 18, 2007, at 9:53 AM, 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. > 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. > > 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? > > 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. > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Tuesday, July 17, 2007 4:28 PM > To: Dominik Kaspar > Cc: 6lowpan; rsn@ietf.org > 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. --Apple-Mail-24-516683745 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Adding a few comments = ...=A0

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

The = argument for route-over is pretty simple.
=A0
=
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)=A0and control actions (from controllers external to the PAN = to devices within the PAN).=A0 There are cases where data collection = point and/or the controller is=A0a gateway device on the PAN, but = this=A0physical collocation is rather artificial.=A0 If is far more = typical that=A0where a gateway is deployed it is used to bridge = communication to other networks.=A0=A0
=A0
=
This is true not only for = wireless instrumentation, but wired instrumentation as well.=A0 See for = example
=A0
=
=A0
=
and
=
=A0
=
=A0
and Wireless HART
=A0
=
=A0
Routing onto or off the = PAN=A0utilizes a routable IP address for the device within the PAN.=A0 = It is important for this address to be compressible, just as when both = endpoints are within the PAN.=A0 No matter how effective is the L2 mesh = routing within the PAN, you still need to deal with IP routing off the = PAN.=A0 This is, of course, the purpose of IP routing.=A0 Whatever = mesh-under is done, there will also be route-over.=A0 The = mesh-under=A0path is, at least, one of the route-over hops.=A0 Possibly = more of the IP hops may occur over 802.15.4 links.
=
=A0
=
2. It is very common that = devices route between distinct networks that use the same media, ie. = distinct Ethernet subnets or distinct WiFi subnets.=A0 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.=A0 Even = different meshing protocols.=A0 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.

=A0
3. The Mesh-under protocol=A0is currently = undefined.=A0 6lowpan is sufficient to describe single hop = communication.=A0 It also identifies the endpoints (original and final) = of multihop mesh-routed communication, but it does not define how the = intervening hops=A0are determined or what information is exchanged to = establish routes.=A0=A0Clearly it anticipates that such L2 protocols = will be developed and standardized.=A0 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.=A0 (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.=A0 Thus, IP routing = applies whether or not mesh routing is defined.=A0 All of the IP = visibility and management tools apply to the IP hops.=A0 None of them = apply to the mesh hops within an IP hop.
=A0
=
4. Many IP routing = protocols are defined and a diversity of protocols has become the norm.=A0= One of the key elements of IP is that it separates routing from = forwarding.=A0 We tolerate the use of different routing protocols in = different settings.=A0 These protocols=A0set up the tables and = forwarding works across them.=A0 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.=A0 =
=A0
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=A0have much experience with the use of the protocol.=A0 For = example, in Zigbee we have seen that after several years of development, = but no broad usage,=A0Zigbee 1.0 is obsoleted in favor of Zigbee 2006, = which is incompatible and also incompatible with Zigbee 2007, which is = not yet fully defined.=A0 We have seen numerous proprietary protocols, = proprietary extensions to standard protocols, and open research = protocols for meshing that are all incompatible.=A0 In some cases they = optimize for different aspects, in some cases they integrate aspects of = all layers of the stack.=A0 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.=A0 Call it "rough consensus = and running code".
=A0
One might argue these aspects are = sociological, rather than technical.=A0 Well, the separation of topology = formation, path selection, and route table maintainance from forwarding = is awfully important.=A0 So are the vast set of tools to gain visibility = into IP routing.=A0 At the very least, source routing, exploration, etc. = will need to be developed for the PAN for mesh-under to mature.=A0 It is = an interesting question whether you need to be within the PAN to utilize = the equivalent of traceroute.
=A0
5. History suggests that once IP routing is = available for a particular kind of link, sub-IP routing tends to = dissappear.=A0 Remember x.25 and frame relay.=A0 Of course, we do some = form of "mesh" routing in switched ethernets and mesh wifi, but = generally it is transparent.=A0 The link looks like the unswitched = counterpart.
=A0
So I think it is very clear that IP routing = will occur over IEEE 802.15.4 links.=A0 It is already there.=A0 For = every=A0single hop 15.4 network it is done.=A0 For deeper networks, = there are many ways to set up the tables.=A0=A0=A0
=
=A0
=
So route-over is a fact.=A0 = The question=A0should be=A0"Do you need mesh-under in addition to = route-over?"=A0 Why?
=A0

=
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.
=
From: JP Vasseur [mailto:jvasseur@cisco.com] =
Sent: Tuesday, July 17, 2007 4:28 PM
To: Dominik = Kaspar
Cc: 6lowpan; rsn@ietf.org
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.

<= /BODY>= --Apple-Mail-24-516683745-- --===============1919742188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1919742188==-- From rsn-bounces@ietf.org Fri Jul 20 21:54:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC4BL-0001tU-49; Fri, 20 Jul 2007 21:54:55 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IC4BJ-0001ra-7Z for rsn-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 21:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC4BI-0001rM-FY for rsn@ietf.org; Fri, 20 Jul 2007 21:54:52 -0400 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IC4BH-0004h5-JH for rsn@ietf.org; Fri, 20 Jul 2007 21:54:52 -0400 X-AuditID: c0a8013c-ad6c0bb000003048-50-46a16768e6f6 Received: from [172.17.167.32] (unknown [207.236.7.194]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 2FE844DC00A; Fri, 20 Jul 2007 19:54:46 -0600 (MDT) In-Reply-To: <46A0E7CD.4050906@archrock.com> References: <81EB2115-F598-4D0D-871D-12B51CE51B0B@cisco.com> <20070718135323.587AA1DDC3B9@secure.archedrock.com> <2a3692de0707200240p3776b78cj718c027b67cce3e0@mail.gmail.com> <46A0E7CD.4050906@archrock.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8782D67F-A0CF-458D-B82D-990AFD50BF00@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 Date: Fri, 20 Jul 2007 21:54:10 -0400 To: Jonathan Hui , Dominik Kaspar X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi, On Jul 20, 2007, at 12:50 PM, Jonathan Hui wrote: > > Dominik Kaspar wrote: >> 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. > > [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. > >> 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. > > [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. > >> 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. 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 >> 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. I must be missing your point ... why ? >> Such a gateway is not an artificial, but a very >> realistic architectural element for efficient sensor network >> functionality. > > [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. > -- > Jonathan Hui > jhui@archrock.com > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jul 20 22:02:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC4Ia-00080C-P5; Fri, 20 Jul 2007 22:02:24 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IC4IZ-0007yC-1y for rsn-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 22:02:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC4IY-0007xz-O7 for rsn@ietf.org; Fri, 20 Jul 2007 22:02:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IC4IY-0004nK-5N for rsn@ietf.org; Fri, 20 Jul 2007 22:02:22 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2007 22:02:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAG4GoUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,565,1175486400"; d="scan'208"; a="65763539:sNHT27697144" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6L22Lkg007993; Fri, 20 Jul 2007 22:02:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6L227WI002695; Sat, 21 Jul 2007 02:02:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 22:02:07 -0400 Received: from [172.17.167.32] ([10.86.242.235]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 22:02:06 -0400 In-Reply-To: <46A12227.7080701@saloits.com> References: <46A12227.7080701@saloits.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17A055E7-1DC0-46C9-9B18-1873708276E1@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Link-Local versus Network Routing at IETF-69 Date: Fri, 20 Jul 2007 22:01:33 -0400 To: "Timothy J. Salo" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Jul 2007 02:02:06.0988 (UTC) FILETIME=[23F164C0:01C7CB3B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2302; t=1184983341; x=1185847341; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20Link-Local=20versus=20Network=20Routing=20at= 20IETF-69 |Sender:=20 |To:=20=22Timothy=20J.=20Salo=22=20; bh=Kzri5mq5G5rT97+WRyQqpIyZ4tX1yXcjdcGgWqp7bhg=; b=hiSza/Qy03eG8y3U+90vq8l6fFjodDn68WGVsKVWYKUkNOSujUifUlD8SNm9KyS8NKxVGBc5 46ySDd53jz3OaAucs5UHmAlMoiyT1TgtoMMvFf5yY2YQqQ0RJ8fC+2Su; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Tim, On Jul 20, 2007, at 4:59 PM, Timothy J. Salo wrote: > The IETF-69 BOF status page > says that the RSN BoF will not meet until the Vanvouver IETF, but > that the problem space will be presented in the Routing Area Working > Group meeting (17:40 Tuesday) or equivalent venue. > > Has a venue for the RSN non-BOF discussion been established yet? It > doesn't seem to be on the current rtgwg agenda. > > This discussion, where ever it occurs, may be an excellent opportunity > (although not the only one) to discuss whether separate link-local and > network routing protocols are likely to be required for low-power > wireless networks. > > My [current] view is that link-local and network routing protocols > adapted to low-power wireless network have a lot more in common than > they do differences. They seem to share a lot of hard problems (e.g., > support for a class of nodes that is severely resource constrained, > support for nodes that sleep most of the time, the lack of an > efficient > link-wide multicast/broadcast capability, etc.). In contrast, the > scope of the routing protocol (link-local versus network-wide) seems > like a comparatively minor variation, even if the link-local version > ends up using link-layer addresses (of course, I continue to argue > that in 6lowpan networks the mapping between link-layer addresses > and network-addresses should be trivial, which would seem to > moot this argument). > > At any rate, at this time I am strongly opposed any of the two, > largely > independent efforts to develop/adapt a routing protocol for low- > power wireless networks (6lowpan and rsn) being described as > standards-track. > I believe that both of these efforts should be classified as > "experimental" until either they are converged, or a strong case has > been made that two, independent routing protocols are really required. > > We are very far from being there ... Remember there is currently NO WG for RL2N so before considering a Std versus Experimental track, you need a hosting WG. Thanks. JP. > -tjs > > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Jul 25 12:03:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjKW-0006yD-P7; Wed, 25 Jul 2007 12:03:16 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IDjKV-0006y0-Be for rsn-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 12:03:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjKQ-0006tz-SD for rsn@ietf.org; Wed, 25 Jul 2007 12:03:10 -0400 Received: from ns1.nict.go.jp ([133.243.3.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDjKP-0002bP-01 for rsn@ietf.org; Wed, 25 Jul 2007 12:03:10 -0400 Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id l6PFxLpS002192; Thu, 26 Jul 2007 00:59:21 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id l6PFxLRM003790; Thu, 26 Jul 2007 00:59:21 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id l6PFxKc4003787; Thu, 26 Jul 2007 00:59:20 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id C36896EBB; Thu, 26 Jul 2007 00:59:20 +0900 (JST) Received: from kaflenote2 (ssh.nict.go.jp [133.243.3.49]) by mail2.nict.go.jp (Postfix) with ESMTP id 9D8316E39; Thu, 26 Jul 2007 00:59:19 +0900 (JST) From: "Ved Kafle" To: "'JP Vasseur'" Date: Thu, 26 Jul 2007 00:59:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <17A055E7-1DC0-46C9-9B18-1873708276E1@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfLOzJBMDVQhyjVQSykMcpHegH+7wDmMU4g Message-Id: <20070725155919.9D8316E39@mail2.nict.go.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: rsn@ietf.org Subject: [RSN] Routing in L2N presentation file X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi JP, Is it possible to get the presentation file you used in the routing area meeting? I could find it on the web. Ved Kafle _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jul 26 07:39:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1fy-00013v-K0; Thu, 26 Jul 2007 07:38:38 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IE1fw-00013I-M1 for rsn-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 07:38:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1fs-00012n-QE for rsn@ietf.org; Thu, 26 Jul 2007 07:38:32 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE1fs-0001U4-9D for rsn@ietf.org; Thu, 26 Jul 2007 07:38:32 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jul 2007 13:38:31 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANIjqEaQ/uCKh2dsb2JhbACPZwEBAQgKJw X-IronPort-AV: i="4.16,584,1175464800"; d="scan'208"; a="149063105:sNHT92000274" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6QBcUVp030800; Thu, 26 Jul 2007 13:38:30 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6QBc6kv003625; Thu, 26 Jul 2007 11:38:11 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 13:38:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jul 2007 13:38:00 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0446A5BA@xmb-ams-337.emea.cisco.com> In-Reply-To: <46A7A767.3050906@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Manemo] MANEMO is not just about Nested Nemo Thread-Index: AcfO89HZaQGI1Fb4QxmO+OAmsHM2YQAhEV0g References: <816DD9299957E547B5D758D7F977D6DC022501AE@tayexc14.americas.cpqcorp.net> <7892795E1A87F04CADFCCF41FADD00FC0441DEBC@xmb-ams-337.emea.cisco.com> <46A7A767.3050906@gmail.com> From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 26 Jul 2007 11:38:06.0965 (UTC) FILETIME=[6F5C2250:01C7CF79] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2138; t=1185449910; x=1186313910; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[Manemo]=20MANEMO=20is=20not=20just=20about=20Nested= 20Nemo |Sender:=20; bh=IqYz3be7gpS5r7ALMA6ZNa+sLSVGmpQXDCZOJl320Co=; b=ICSNIzmw/qBVJTIV7OAbP8fK8CNCZTz3YOerS/uovIOVn7+SYuWNVfi4cAG9zDGLufyBMogP VGAmxEKP4eNJlTFt0PwWZr3Bp/rekBmZC2dOneIpRDZbtqMo6Eyb545j; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org, manemo@mobileip.jp, "Bound, Jim" Subject: [RSN] RE: [Manemo] MANEMO is not just about Nested Nemo X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Alex: I'm adding RSN and 6LoWPAN. Seems we agree here :) >> At the moment, RSN takes its requirements from 6LoWPAN, but I'd >> suggest considering whether MANEMO can influence RSN and offload some >> of its routing part there. > >I agree that MANEMO shouldn't do much routing, like routing for sensors >or so. I agree if sensors we need then talking to RSN or 6LowPAN. [Pascal] RSN (or rather RL2N now) is not really specific to sensors but to highly constrained devices (battery, CPU, memory, bandwidth, wake time etc...). We would see MANEMO at the same level as 6LoWPAN, pushing some requirements into RSN. > >> It just seems better to do routing work in the routing area, and that >> would enable to focus MANEMO on more specific problems, like routing >> policies between topologies, nested NEMO RO solution, CIA properties >> definition and enforcement, using the fringe structure for >> multicasting, etc... > >I mainly agree. I think we want to stay in the Internet area and do as >much routing as Internet area has traditionally done, but no more. [Pascal] Yes. We have enough trouble focusing/chartering MANEMO and we should avoid an inter area conflict on what belongs where. The routing expertise is supposed to come from routing area. >> If we specify properly the needs for building the logical structure >> to reach the infrastructure, then we could see how RSN and MANET >> solutions as defined within the routing area perform best for our >> routing needs. We could also develop tree discovery within RSN, since >> very similar technology already happens at L2 within sensor networks. > >So do we see tree discovery out of MANEMO and into RSN rather? [Pascal] Yes. I think that the core engine should be in RSN, and then we can add options and best practices so that the generic TD applies well to forming a nested-NEMO for instance. I see 6LoWPAN adapting TD as well so that TD benefits from the ND and compression optimizations that they do there. Would you agree with that approach ?=20 Pascal_____________________________________________________________ _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun Jul 29 17:03:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFFvL-0000jr-Bn; Sun, 29 Jul 2007 17:03:35 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IFFvK-0000jk-Ca for rsn-confirm+ok@megatron.ietf.org; Sun, 29 Jul 2007 17:03:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFFvG-0000jY-Qe for RSN@ietf.org; Sun, 29 Jul 2007 17:03:30 -0400 Received: from ccaix.jsums.edu ([143.132.8.108]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFFvG-0005Ti-9G for RSN@ietf.org; Sun, 29 Jul 2007 17:03:30 -0400 Received: from webmail.jsums.edu ([143.132.8.100]) by ccaix.jsums.edu (8.13.1/8.13.1) with ESMTP id l6TL3Srq018112; Sun, 29 Jul 2007 16:03:28 -0500 Received: from 172.134.192.106 (SquirrelMail authenticated user nmeghanathan) by webmail.jsums.edu with HTTP; Sun, 29 Jul 2007 16:03:28 -0500 (CDT) Message-ID: <4645.172.134.192.106.1185743008.squirrel@webmail.jsums.edu> Date: Sun, 29 Jul 2007 16:03:28 -0500 (CDT) From: nmeghanathan@jsums.edu To: RSN@ietf.org User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: iaria.announce@gmail.com Subject: [RSN] [ICN 2008] Call for Papers - The Seventh International Conference on Networking, 2008 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Please apologize for any cross-postings. ====================== Invitation: Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS, TUTORIALS, PANELS ICN 2008, The Seventh International Conference on Networking April 13-18, 2008 - Cancun, Mexico Site: http://www.iaria.org/conferences2008/ICN08.html Submit a paper: http://www.iaria.org/conferences2008/SubmitICN08.html Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. Important deadlines: Submission deadline: November 5, 2007 Notification of acceptance: December 15, 2007 Registration/camera ready: January 20, 2008 ICN 2008 Topics (details in the CfP on site): 1. Communication theory 2. Communications switching and routing 3. Communications modeling 4. Communications security 5. Computer communications 6. Distributed communications 7. Signal processing in communications 8. Multimedia and multicast communications 9. Wireless communications (satellite, WLL, 4G, Ad Hoc, sensor networks) 10. Next generation networks [NGN] principles 11. Storage area networks [SAN] 12. Access and home networks 13. High-speed networks 14. Optical networks 15. Peer-to-peer and overlay networking 16. Mobile networking and systems 17. MPLS-VPN, IPSec-VPN networks 18. GRID networks 19. Broadband networks 20. Quality of service, service level agreement [QoS/SLA] 21. Reliability, availability, serviceability [RAS] 22. Traffic engineering, metering, monitoring 23. Voice over IP services 24. Performance evaluation, tools, simulation 25. Network, control and service architectures 26. Network signaling, pricing and billing 27. Network middleware 28. Telecommunication networks architectures 29. On-demand networks, utility computing architectures 30. Applications and case studies 31. NGN protocol design and evaluation 32. NGN Standard Activities [ITU, TMF, 3GPP, IETF, etc.] 33. NGN Device Instrumentation 34. Network Management, scheduling and policy 35. NGN policy-based control 36. Networks policy-based management 37. Management of autonomic networks and systems ====================== IARIA Publicity Board ====================== _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun Jul 29 17:10:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFG2Q-0004W8-AL; Sun, 29 Jul 2007 17:10:54 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IFG2O-0004Vk-Lz for rsn-confirm+ok@megatron.ietf.org; Sun, 29 Jul 2007 17:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFG2O-0004Vb-CO for RSN@ietf.org; Sun, 29 Jul 2007 17:10:52 -0400 Received: from ccaix.jsums.edu ([143.132.8.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFG2N-0005Zt-3e for RSN@ietf.org; Sun, 29 Jul 2007 17:10:52 -0400 Received: from webmail.jsums.edu ([143.132.8.100]) by ccaix.jsums.edu (8.13.1/8.13.1) with ESMTP id l6TLAngd018854; Sun, 29 Jul 2007 16:10:50 -0500 Received: from 172.134.192.106 (SquirrelMail authenticated user nmeghanathan) by webmail.jsums.edu with HTTP; Sun, 29 Jul 2007 16:10:50 -0500 (CDT) Message-ID: <4695.172.134.192.106.1185743450.squirrel@webmail.jsums.edu> Date: Sun, 29 Jul 2007 16:10:50 -0500 (CDT) From: nmeghanathan@jsums.edu To: RSN@ietf.org User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: iaria.announce@gmail.com Subject: [RSN] [ICONS 2008] Call for Papers - The Third International Conference on Systems, 2008 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Please apologize for any cross-postings. ====================== Invitation: Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS, TUTORIALS, PANELS ICONS 2008, The Third International Conference on Systems April 13-18, 2008 - Cancun, Mexico Site: http://www.iaria.org/conferences2008/ICONS08.html Submit a paper: http://www.iaria.org/conferences2008/SubmitICONS08.html Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. Important deadlines: Submission deadline: November 5, 2007 Notification of acceptance: December 15, 2007 Registration/camera ready: January 20, 2008 ICONS 2008 Topics (details in the CfP on site): * Systems' theory and practice * System engineering * Systems' instrumentation * Embedded systems and systems-on-the-chip * Target-oriented systems * Specialized systems * Validation systems * Security and protection systems * Mobile communications and learning * Advanced systems * Application-oriented systems * Safety in industrial systems * Micro and nano structures and systems * Embedded systems * Industrial applications ====================== IARIA Publicity Board ====================== _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn