From 6lowpan-bounces@ietf.org Mon Jul 09 16:29:31 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zrP-0007QC-7k; Mon, 09 Jul 2007 16:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zrO-0007OL-BL for 6lowpan@ietf.org; Mon, 09 Jul 2007 16:29:30 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7zrJ-0005li-NY for 6lowpan@ietf.org; Mon, 09 Jul 2007 16:29:30 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2007 13:29:25 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGs3kkarR7MV/2dsb2JhbACCYg X-IronPort-AV: i="4.16,518,1175497200"; d="scan'208,217"; a="179094703:sNHT171390978" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l69KTPrq032129 for <6lowpan@ietf.org>; Mon, 9 Jul 2007 13:29:25 -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 l69KTBXd012456 for <6lowpan@ietf.org>; Mon, 9 Jul 2007 20:29:24 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); Mon, 9 Jul 2007 16:29: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); Mon, 9 Jul 2007 16:29:19 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: 6lowpan@ietf.org Message-Id: References: <0492560A-D76C-4D8D-82E8-E78A4AF2A39C@cisco.com> From: JP Vasseur Date: Mon, 9 Jul 2007 16:28:45 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Jul 2007 20:29:19.0713 (UTC) FILETIME=[D3F9C510:01C7C267] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6309; t=1184012965; x=1184876965; c=relaxed/simple; s=sjdkim1004; 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=20Update |Sender:=20; bh=bMEYvVCMU92iRYFEfjqk39pFsXDvDVLt1RmQ79rqwh0=; b=AiGh/E7NIOlTh1i9/XFFbUop9yhioA6L2A7XdWczaf1NZV6ChNITH+H3WhW1XJzOeBWGYO5T wUuHASZ1miMv+1xFzKrw9PoYxVD1QsN9Af8+Kj9R2m2ayWzUWPD3eac+PupkqzwP1GymYmedYu XrZLC2RtwUctPGSF2XcPXVuZQ=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [6lowpan] Fwd: Update X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0163984738==" Errors-To: 6lowpan-bounces@ietf.org --===============0163984738== Content-Type: multipart/alternative; boundary=Apple-Mail-11--452704384 --Apple-Mail-11--452704384 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: JP Vasseur > Date: July 9, 2007 4:27:18 PM EDT > To: rsn@ietf.org > Cc: manemo@mobileip.jp, manet@ietf.org > Subject: Update > > 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-11--452704384 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = July 9, 2007 4:27:18 PM EDT
Subject: = Update

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-11--452704384-- --===============0163984738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0163984738==-- From 6lowpan-bounces@ietf.org Fri Jul 13 16:28:22 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RkT-00039P-En; Fri, 13 Jul 2007 16:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RkQ-0002vk-6o for 6lowpan@lists.ietf.org; Fri, 13 Jul 2007 16:28:18 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9RkM-0006Js-My for 6lowpan@lists.ietf.org; Fri, 13 Jul 2007 16:28:18 -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: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 13 21:01:52 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9W16-0001JP-W4; Fri, 13 Jul 2007 21:01:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9W14-00014O-P2 for 6lowpan@lists.ietf.org; Fri, 13 Jul 2007 21:01:46 -0400 Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9W0z-0007Mz-Vy for 6lowpan@lists.ietf.org; Fri, 13 Jul 2007 21:01:46 -0400 Received: (qmail 11768 invoked by uid 60001); 14 Jul 2007 01:01:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=T5xoFFVerKKwmRys0noYZfXBQfMvTykaiPX6VyF1aEpHyyo7SQg1C9UJ8C01fbauYFIqAeefvwKqFFRWb0eGiZTFOSLQj9H2KXN09Rs+WqxsSo286OJoiYWdVsL42VOj7n4Or+BjBLLqK8niuy3V6mWCsbK/ZbOBngvUEITHBZE=; X-YMail-OSG: J3ZeFrMVM1kkA0qNb34L7u5SJu62pm1Wf9bMkGCzKE_51iB5cRt8slGNabCLf2p3Nw-- Received: from [131.107.0.103] by web81903.mail.mud.yahoo.com via HTTP; Fri, 13 Jul 2007 18:01:41 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Fri, 13 Jul 2007 18:01:41 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing" To: "Timothy J. Salo" , rsn@ietf.org, 6lowpan <6lowpan@lists.ietf.org> MIME-Version: 1.0 Message-ID: <496204.11117.qm@web81903.mail.mud.yahoo.com> X-Spam-Score: 1.4 (+) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0011221096==" Errors-To: 6lowpan-bounces@ietf.org --===============0011221096== Content-Type: multipart/alternative; boundary="0-1916450526-1184374901=:11117" --0-1916450526-1184374901=:11117 Content-Type: text/plain; charset=ascii 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: the IPv6 interface identifiers (bottom 64 bits) for the source or destination addresses can be inferred from the layer two source and destination addresses (of course, this is only possible for interface identifiers derived from an underlying 802.15.4 MAC address); ... IC: Interface identifier elided (derivable from the corresponding link-layer address). If applied to the interface identifier of either the source or destination address when routing in a mesh (Section 11), the corresponding link-layer address is that found in the "Mesh Addressing" field (Section 5.2). Notice that the above is merely an optimization, and one applied to the IPv6 header compression scheme. As such, it is orthogonal and independent to the mesh delivery support. 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. So your suggested wording below is not true in general, but it may apply in a meaningful subset of possible cases. -gabriel ----- Original Message ---- From: Timothy J. Salo To: rsn@ietf.org; 6lowpan <6lowpan@lists.ietf.org> Sent: Friday, July 13, 2007 1:27:45 PM Subject: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing" 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-1916450526-1184374901=:11117 Content-Type: text/html; charset=ascii
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:

   the IPv6 interface identifiers (bottom 64
   bits) for the source or destination addresses can be inferred from
   the layer two source and destination addresses
 (of course, this is
   only possible for interface identifiers derived from an underlying
   802.15.4 MAC address);
...
      IC:  Interface identifier elided (derivable from the corresponding
         link-layer address).  If applied to the interface identifier of
         either the source or destination address when routing in a mesh
         (Section 11), the corresponding link-layer address is that
         found in the "Mesh Addressing" field (Section 5.2).

Notice that the above is merely an optimization, and one applied to the IPv6 header compression scheme.
As such, it is orthogonal and independent to the mesh delivery support. 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.

So your suggested wording below is not true in general,  but it may apply in a meaningful subset of possible cases.

-gabriel

----- Original Message ----
From: Timothy J. Salo <salo@saloits.com>
To: rsn@ietf.org; 6lowpan <6lowpan@lists.ietf.org>
Sent: Friday, July 13, 2007 1:27:45 PM
Subject: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing"

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


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--0-1916450526-1184374901=:11117-- --===============0011221096== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0011221096==-- From 6lowpan-bounces@ietf.org Sat Jul 14 09:05:15 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hJ6-0002mN-Ms; Sat, 14 Jul 2007 09:05:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hIz-0002lr-To for 6lowpan@lists.ietf.org; Sat, 14 Jul 2007 09:05:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9hIv-00005m-Dc for 6lowpan@lists.ietf.org; Sat, 14 Jul 2007 09:05:01 -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 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 Subject: [6lowpan] Re: [RSN] L3 mesh requirements X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jul 14 10:04:24 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9iER-0001pj-Qh; Sat, 14 Jul 2007 10:04:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9iEP-0001hj-LC for 6lowpan@lists.ietf.org; Sat, 14 Jul 2007 10:04:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9iEK-0001Pa-OF for 6lowpan@lists.ietf.org; Sat, 14 Jul 2007 10:04:21 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Jul 2007 07:04:16 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHN0mEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175497200"; d="scan'208"; a="182119273:sNHT39642777" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6EE4Fvj016237; Sat, 14 Jul 2007 07:04:15 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6EE4ESd002123; Sat, 14 Jul 2007 14:04:15 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 10:04:14 -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 10:04:13 -0400 In-Reply-To: <467FFF42.9010402@cisco.com> References: <1182290571.6218.29.camel@dellx1> <467FFF42.9010402@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <0A790B2E-E99C-4E7B-9D83-622C2D229CEA@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [6lowpan] Rechartering consensus... Date: Sat, 14 Jul 2007 10:03:38 -0400 To: Mark Townsley , Geoff Mulligan X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Jul 2007 14:04:13.0909 (UTC) FILETIME=[DBE8A050:01C7C61F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13142; t=1184421855; x=1185285855; 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[6lowpan]=20Rechartering=20consensus... |Sender:=20; bh=Lzs/Bh0+cD+ICT8/8V5sIP73EBkBUAjZupWliFlZTrs=; b=X9AEPKStyOgXeXw+PQmp3UfTEXsokV6qCfDTf6UsD+NxRKqotHCDCuXGtlbzCmcfxckyZ9uK R6jFvWws6mVDbOT6YWBhnKHbdLj0Q0HGVwB9BUNNqtVazRtp87r8XIUC; 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: db284e046c8702920c1c6125bc4d0b7a Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Geoff and Mark, Some overdue comments/feedback in line. On Jun 25, 2007, at 1:45 PM, Mark Townsley wrote: > Geoff Mulligan wrote: >> 6LoWPAN group, >> It would appear that we have consensus on the work items for the >> working group rechartering - the following 5 topics have been =20 >> relatively >> unchanged for months. >> >> As I have been working with folks that are implementing 6LoWPAN =20 >> and from >> some of the messages on the list I have realized that we should =20 >> probably >> be focused on those topics that are necessary to resolve for >> interoperability between implementations. Some of the 5 items =20 >> here are >> targeted to this and some of the topics mentioned on the list, =20 >> such as a >> standard/defined MIC could fall under one of the topics. >> >> - =936lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations=94 >> - =93Problem Statement for Stateful Header Compression in 6lowpans=94 >> - =93Recommendations for 6lowpan Applications=94 >> - =936lowpan Mesh Routing=94 >> - =936lowpan Security Analysis=94 Few comments here: 6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations: JP> Yes. =93Problem Statement for Stateful Header Compression in 6lowpans=94 JP> Yes. =93Recommendations for 6lowpan Applications=94 JP> Do you mean applicability statement ? In this case, in strong =20 support. This is one of the missing pieces particularly important to show that =20= PAN can be implemented on IP. Note that there are many other pieces that =20 must first be worked out (security, management, routing, ...) before we =20 will be able to produce applicability statement but would be good to have it in =20 the charter indeed. =936lowpan Mesh Routing=94 JP> One of these "hot" topic. And of course, the main question will =20 to be discuss whether Mesh-under routing is required if Route over is =20 available. In particular, open questions are "If we claim a need for a mesh =20 under routing, does that mean that we'll see a plethora of IDs showing how to adapt all protocols (e.g. MANET) used in a 802.15.4 environment ?" =936lowpan Security Analysis=94 JP: All for it. We are starting some work on RSN to address that =20 particular issue from a routing standpoint we clearly this is a key item of the WG. =20 Yes we still hear people promoting proprietary standards because they think that this =20 is provides a high degree of security. I would propose to add "Management": in most PANs we do expect a high =20= number of devices requiring self-management, so I think that this should be =20 listed at a WG item. And the final one is "Service discovery" >> >> I have attached a proposed new charter for the working group. >> >> geoff >> >> >> =20 >> ---------------------------------------------------------------------=20= >> --- >> >> Background/Introduction: >> >> Well-established fields such as control networks, and burgeoning ones >> such as "sensor" (or transducer) networks, are increasingly being >> based on wireless technologies. Most (but certainly not all) of these >> nodes are amongst the most constrained that have ever been networked >> wirelessly. Extreme low power (such that they will run potentially =20= >> for >> years on batteries) and extreme low cost (total device cost in single >> digit dollars, and riding Moore's law to continuously reduce that >> price point) are seen as essential enablers towards their deployment >> in networks with the following characteristics: >> * Significantly more devices than current networks >> > This statement seems a bit dubious to me. More devices than what =20 > "current" networks? And, what exactly is the limit of a "network" =20 > in this statement (the Internet is a network, for example, and I =20 > don't think you are building anything larger than the Internet =20 > itself). Indeed, and it depends on what we mean by "larger" but at least we =20 can safely refer to a potentially large number of devices per square foot with =20 densely connected devices. >> * Severely limited code and ram space (e.g., highly desirable to >> fit the required code--MAC, IP and anything else needed to >> execute the embedded application-- in, for example, 32K of flash >> memory, using 8-bit microprocessors) >> >> * Unobtrusive but very different user interface for configuration >> (e.g., using gestures or interactions involving the physical >> world) >> * Robustness and simplicity in routing or network fabric >> > This is a bit of a platitude, and why *or* here? >> A chief component of these devices is wireless communication >> technology. In particular, the IEEE 802.15.4 standard is very >> promising for the lower (physical and link) layers. As for higher >> layer functions, there is considerable interest from non-IETF groups >> in using IP technology. The working group is expected to coordinate >> and interact with such groups. Which groups ? Are you referring to official liaisons with non =20 official SDO ? >> >> The working group has completed a problem statement/requirements RFC >> and and adaptation layer (IPv6 over 802.15.4) RFC. The working group >> > Double "and" >> has as its main objective to complete those topics and areas =20 >> necessary >> for successful implmentation interoperability. >> > What do you mean by "complete those topics"? Continue to advance on =20= > the standards track? I guess that stands for "start working on several missing pieces" ? >> The required work includes items in the following (incomplete) list: >> * Addressing schemes and address management >> * Network management >> * Routing in dynamically adaptive topologies Of course we need to be more specific here: under-mesh ? >> * Security, including set-up and maintenance >> * Application programming interface We should then explain what this means since this is typically a topic what could meant very different things ... >> * Discovery (of devices, of services, etc) >> * Implementation considerations You mean implementation considerations. Looks to me that the number of topics is really large without sufficient description for each of them. >> >> Whereas at least some of the above items are within the purview of =20= >> the >> IETF, at this point it is not clear that all of them are. =20 >> Accordingly, >> the 6LoWPAN working group will address a reduced, more focused set of >> objectives. >> > I think the above list raises more questions than it answers. When =20 > I read it, I immediately ask "who is doing all this work? Should we =20= > liaise with someone on it? is it possible to have interoperable =20 > implementations without addressing all of these items? What else is =20= > left? etc." Rather than try and capture the entire landscape in an =20 > incomplete list, let's focus the charter on two things (1) What the =20= > 6lowpan group is going to do, and (2) any *important* things that =20 > this WG is *not* going to do. For the latter, any pointers to other =20= > WGs, SDOs, etc. would be welcome. AD's call but I do concur. >> Scope of 6lowpan: >> >> 1. Produce =936lowpan Bootstrapping and 6lowpan IPv6 ND =20 >> Optimizations=94 >> to define the required optimizations to make IPv6 ND applicable in >> 6lowpans, given the fact that IPv6 ND is too expensive for the =20 >> devices >> of 6lowpan and requires multicast. > Do we have consensus that ND is too expensive? If so, great, but I =20 > want to be sure. > I'm not so sure ... shouldn't we conduct some careful analysis first =20 and just indicate the WG item with no conclusion at this stage ? > Secondly, do we have consensus that ND is required? If 6lowpans =20 > have their own built-in address resolution due to the way addresses =20= > are managed, what aspects of ND are necessary? >> This document will define how to >> bootstrap a 6lowpan network and explore ND optimizations such as >> reusing the 802.15.4 network structure (use the coordinators), and >> obviate multicast by having devices talk to coordinators without >> creating a single point-of-failure, and changing the IPv6 ND =20 >> multicast >> semantics. This document will be a proposed standard. >> > This work item needs to be a little more crisp. Is this =20 > "Bootstrapping" or "ND" or both? If both, are we making the =20 > assumption that ND is the Bootstrapping method, but that it needs =20 > to be changed to work in a lowpan? Got the same questions. >> 2. Produce =93Problem Statement for Stateful Header Compression in >> 6lowpans=94 to document the problem of using stateful header =20 >> compression >> (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of >> stateless header compression given the assumption that stateful =20 >> header >> compression may be too complex. This document will determine if the >> assumption is correct and will be an informational document. >> > For the last sentence "The WG will determine if the assumption is =20 > correct at this time and record the findings in this informational =20 > document." >> 3. Produce =93Recommendations for 6lowpan Applications=94 to define = a >> set of recommendations of protocols to use for applications. The >> recommendations will cover protocols for transport, application =20 >> layer, >> discovery, configuration and commissioning. This document will be an >> informational document. >> > Can we be specific as to which protocols will be covered? This =20 > seems very open-ended. Do we want to really provide recommendations or applicability =20 statements ?? Also recommendations for configuration, commissioning and application =20= layers seem a bit out of the scope. >> 4. Produce =936lowpan Mesh Routing=94 to evaluate different mesh =20= >> routing >> protocols for use within 6lowpans. While most routing protocols are >> defined above the IP layer, 6lowpan requires a mesh routing protocol >> below the IP layer. =936lowpan Mesh Routing=94 may be several = proposed >> standard documents. >> > I think we need to be sure that the line between this and the "RSN" =20= > effort that is spinning up is clear. Also, nailing down which PS =20 > documents will be necessary would be a very nice thing to do. Indeed + first agree that a Mesh under solution is indeed required. I =20= know that this is likely to provide reactions but fair to ask at this point. >> 5. Produce =936lowpan Security Analysis=94 to define the threat =20 >> model of >> 6lowpans and to document suitability of existing key management >> schemes and to discuss bootstrapping/installation/commissioning/setup >> issues. This document will be an informational document. >> > And you will need a security area adviser appointed for this. When =20 > the time comes we will need to ask the secdir to appoint someone. > >> The working group will reuse existing specifications whenever >> reasonable and possible. >> > s/specifications/protocols and mechanisms >> The working group will also serve as a venue for ongoing discussions >> on other topics related to the more complete list outlined above. >> Additional related milestones may be added in the future via a >> rechartering operation. >> > Not sure this is good advice. You already have a big chunk of work =20 > to chew on. If discussion naturally ends up on this list for other =20 > work, that's fine, but I don't see why it needs to be listed in the =20= > charter as specifically allowed. >> Note: As may be obvious from its official name above, this particular >> working group will not work on IPv4 over IEEE 802.15.4 =20 >> specifications. >> Given the limitations of the target devices, dual-stack deployments >> are not practical. Because of its higher potential for header >> compression, its support for the huge number of devices expected and >> of cleanly built-in features such as address autoconfiguration, IPv6 >> is the exclusive focus of the working group. >> > I understand keeping IPv4 out of scope for within the lowpan, but I =20= > do think it is important to write a recommendation for the 6lowpan =20 > communicating on the Internet at large, in particular the IPv4 =20 > Internet. Thoughts on this? Oh yes ! Would be happy to help there. Still, I think that it would be nice to have at some point an open =20 discussion on why NOT IPv4, not pushing for anything here ... but having a "documented" =20 discussion would I think be helpful. Cheers. JP. > > Thanks, > > - Mark >> ---------------------------------------------------------------------=20= >> --- >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www1.ietf.org/mailman/listinfo/6lowpan >> > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jul 14 15:02:00 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9msP-0001CT-Nr; Sat, 14 Jul 2007 15:01:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9msO-0001CN-R9 for 6lowpan@lists.ietf.org; Sat, 14 Jul 2007 15:01:56 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9msK-00018x-6B for 6lowpan@lists.ietf.org; Sat, 14 Jul 2007 15:01:56 -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> Subject: Re: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing" 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: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jul 14 19:40:45 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9rEA-0006Ei-76; Sat, 14 Jul 2007 19:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9rE9-0006EZ-S2 for 6lowpan@lists.ietf.org; Sat, 14 Jul 2007 19:40:41 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9rE5-00080A-A3 for 6lowpan@lists.ietf.org; Sat, 14 Jul 2007 19:40:41 -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 l6ENeJUe021820 for <6lowpan@lists.ietf.org>; Sat, 14 Jul 2007 18:40:34 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <46995ED8.9050001@saloits.com> Date: Sat, 14 Jul 2007 18:40:08 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing" References: <496204.11117.qm@web81903.mail.mud.yahoo.com> <46991D57.2000704@saloits.com> In-Reply-To: <46991D57.2000704@saloits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Jul 15 01:26:39 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9wcp-0006LQ-VC; Sun, 15 Jul 2007 01:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9wcp-0006LA-0O for 6lowpan@lists.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-0005FE-Hq for 6lowpan@lists.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: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Jul 15 22:57:43 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAGmM-0003j9-Bd; Sun, 15 Jul 2007 22:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAGmL-0003j4-7X for 6lowpan@lists.ietf.org; Sun, 15 Jul 2007 22:57:41 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAGmH-0004Ep-F3 for 6lowpan@lists.ietf.org; Sun, 15 Jul 2007 22:57:41 -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: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 16 00:25:43 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAI9S-0003l5-Oe; Mon, 16 Jul 2007 00:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAI9S-0003kv-2b for 6lowpan@lists.ietf.org; Mon, 16 Jul 2007 00:25:38 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAI9O-0005m9-Hh for 6lowpan@lists.ietf.org; Mon, 16 Jul 2007 00:25:38 -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 l6G4PLVJ030833 for <6lowpan@lists.ietf.org>; Sun, 15 Jul 2007 23:25:31 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <469AF329.9000204@saloits.com> Date: Sun, 15 Jul 2007 23:25:13 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] Rechartering consensus... References: <1182290571.6218.29.camel@dellx1> In-Reply-To: <1182290571.6218.29.camel@dellx1> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by newbsd.saloits.com id l6G4PLVJ030833 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Geoff Mulligan wrote: > 2. Produce =E2=80=9CProblem Statement for Stateful Header Compression= in > 6lowpans=E2=80=9D to document the problem of using stateful header comp= ression > (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of > stateless header compression given the assumption that stateful header > compression may be too complex. This document will determine if the > assumption is correct and will be an informational document. The need for and value of this document escapes me, but maybe it's just me. The 6lowpan format document contains the following language: 10. Header Compression There is much published and in-progress standardization work on header compression. Nevertheless, header compression for IPv6 over IEEE 802.15.4 has differing constraints summarized as follows: Existing work assumes that there are many flows between any two devices. Here, we assume a very simple and low-context flavor of header compression. Whereas this works independently of flows (potentially several), it does not use any context specific to any flow. Thus, it cannot achieve as much compression as schemes that build separate context for each flow to be compressed. Given the very limited packet sizes, it is highly desirable to integrate layer 2 with layer 3 compression, something traditionally not done (although now changing due to the ROHC working group). It is expected that IEEE 802.15.4 devices will be deployed in multi-hop networks. However, header compression in a mesh departs from the usual point-to-point link scenario in which the compressor and decompressor are in direct and exclusive communication with each other. In an IEEE 802.15.4 network, it is highly desirable for a device to be able to send header compressed packets via any of its neighbors, with as little preliminary context-building as possible. While we might consider tightening up this language, I think it at least hints at all the reasons why 6lowpan networks need a static header compression scheme: o We really need to compress headers where ever possible, not just in those cases where existing IETF approaches work (e.g., on point-to-point links and with flows that are long enough to create enough state to do the compression). o 6lowpan devices can't affort to hold much state for any purpose, much less for dynamic header compression algorithms. o 6lowpan topologies are likely to be highly dynamic (e.g., most devices may sleep most of the time). Synchronizing the header compression state information after, for example, a device wakes up will probably be much more costly than using a stateless header compression scheme like that described in the 6lowpan document. How is the existing language in the 6lowpan format document fail to meet what ever objective is embodied in this work item? I suggest that we: o Include any necessary justification for a stateless header compression scheme in the 6lowpan format document, rather than clutter up the RFC process and repository with another RFC that doesn't really say very much. o Figure out whether and how the existing language in the 6lowpan format document is deficient, and enhance it (if necessary). (By the way, JPL developed some stateless header compressed Internet protocols, namely SCPS-NP (IP), SCPS-TP (TCP) and SCPS-SP (IPsec).) -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 16 01:40:05 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAJJQ-0004PE-Av; Mon, 16 Jul 2007 01:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAJJP-0004P4-2X for 6lowpan@lists.ietf.org; Mon, 16 Jul 2007 01:39:59 -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 1IAJJK-0007RD-Jn for 6lowpan@lists.ietf.org; Mon, 16 Jul 2007 01:39:59 -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: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 16 19:38:38 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAa9B-0001td-5d; Mon, 16 Jul 2007 19:38:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAa99-0001r4-DX for 6lowpan@ietf.org; Mon, 16 Jul 2007 19:38:31 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAa94-0006ME-S5 for 6lowpan@ietf.org; Mon, 16 Jul 2007 19:38:31 -0400 Received: by wx-out-0506.google.com with SMTP id h27so1229250wxd for <6lowpan@ietf.org>; Mon, 16 Jul 2007 16:38:26 -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; b=c38/AdGf50LpaTRpIvacMP23MFI+WdEtCtcLw7146r/ZBm7sQIw6w7+DCY3D59pFyi9p7PV71yG1muepVPuSUxUkEgppvZfjOx+FX7VecqN4/me7pMD/6EjIWeKSCk2d7tdm1+kVnBKljqI57A4V4UHbBvRDVIbe4GdLQ5ZSznE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=FRFukHBsegseMry6k/kI6xtxy+aLPYsQDrwVDzpeK5/C7o7vJTub6xZbP41fbiDJeTTNnlsngdMLjnb/bLC04NCTuA4CQrhmYG0jtPjVeBl5djuIP6jtskR/Rxykb47Tk+CGravmn/2Nep9cAQJUAfTQs6qH2W7nzfU3R6Xu9no= Received: by 10.70.41.6 with SMTP id o6mr8691708wxo.1184629106477; Mon, 16 Jul 2007 16:38:26 -0700 (PDT) Received: by 10.70.128.2 with HTTP; Mon, 16 Jul 2007 16:38:26 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 16:38:26 -0700 From: "David Culler" To: 6lowpan@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2017885299==" Errors-To: 6lowpan-bounces@ietf.org --===============2017885299== Content-Type: multipart/alternative; boundary="----=_Part_36183_9811365.1184629106440" ------=_Part_36183_9811365.1184629106440 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Folks, We'd like to draw your attention to I-D http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc1g-00.txt that was posted two weeks ago. It generalizes HC1 to provide the same level of header compression for a PAN-wide global prefix. HC1 only compresses addresses that use the link local prefix. A global prefix is always used in communication with endpoints external to the PAN. It may be used as well within the PAN. In the context of mesh-under, HC1g applies to originator / final. Thanks, David Culler and Jonathan Hui ------=_Part_36183_9811365.1184629106440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Folks,
  We'd like to draw your attention to I-D 

    http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc1g-00.txt

that was posted two weeks ago.  It generalizes HC1 to provide the same level of header compression for a PAN-wide global prefix.  HC1 only compresses addresses that use the link local prefix.  A global prefix is always used in communication with endpoints external to the PAN.  It may be used as well within the PAN.  In the context of mesh-under, HC1g applies to originator / final. 

Thanks,

     David Culler and Jonathan Hui
------=_Part_36183_9811365.1184629106440-- --===============2017885299== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============2017885299==-- From 6lowpan-bounces@ietf.org Mon Jul 16 19:41:47 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAaCJ-0005fi-GG; Mon, 16 Jul 2007 19:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAaCI-0005fc-Jr for 6lowpan@ietf.org; Mon, 16 Jul 2007 19:41:46 -0400 Received: from wx-out-0506.google.com ([66.249.82.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAaCE-0006ZW-At for 6lowpan@ietf.org; Mon, 16 Jul 2007 19:41:46 -0400 Received: by wx-out-0506.google.com with SMTP id h27so1229868wxd for <6lowpan@ietf.org>; Mon, 16 Jul 2007 16:41:42 -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; b=hoV6ZyaBPzyYNqoaD0XhbKx86L/RBE73nQ+ALxYawq8ew1t/JD6iLuU+isi7dF2uYaZc7jgcAghAfwxZ2ZQx7tniR3wBByEYmrucTWTp9K7174EQ3/ELlprYdw2sTXacrntw1a+x3m4o11qAXqy31gZUguZYm7XQsgOHGOXIRnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=j7+obGeSPdKd2/3cn4wrBBS+DXBgaPsBRrCq1KV53g8XljXUCVfxmkV3AEJYwTgXlFVazCDzQzsiA/lnlUy4vPKCURnLk3Q0uOxkmmwuYw6VGDCKabajD2G+nWGZzkMXbvxxWOzGnkhrm3HxFCmhIAbE4RDZGH4t7cW69i833/U= Received: by 10.70.18.11 with SMTP id 11mr8667701wxr.1184629302049; Mon, 16 Jul 2007 16:41:42 -0700 (PDT) Received: by 10.70.128.2 with HTTP; Mon, 16 Jul 2007 16:41:41 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 16:41:42 -0700 From: "David Culler" To: 6lowpan@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [6lowpan] Soliciting input on Interop draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1629659223==" Errors-To: 6lowpan-bounces@ietf.org --===============1629659223== Content-Type: multipart/alternative; boundary="----=_Part_36207_21489181.1184629302003" ------=_Part_36207_21489181.1184629302003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Folks, We'd like to get feedback on I- D http://www.ietf.org/internet-drafts/draft-hui-6lowpan-interop-00.txt submitted July 6. This provides thoughts on the first phases of interoperability testing. The scheme developed there would generalize to cover the rest of the 6LoWPAN. Thanks, Jonathan, Zack, and David ------=_Part_36207_21489181.1184629302003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Folks,
  We'd like to get feedback on I- D

                    http://www.ietf.org/internet-drafts/draft-hui-6lowpan-interop-00.txt

submitted July 6.  This provides thoughts on the first phases of interoperability testing.  The scheme developed there would generalize to cover the rest of the 6LoWPAN.

Thanks,

     Jonathan, Zack, and David
------=_Part_36207_21489181.1184629302003-- --===============1629659223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1629659223==-- From 6lowpan-bounces@ietf.org Mon Jul 16 23:00:45 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdIo-0002eb-Rz; Mon, 16 Jul 2007 23:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdIn-0002eS-SB for 6lowpan@ietf.org; Mon, 16 Jul 2007 23:00:41 -0400 Received: from web81911.mail.mud.yahoo.com ([68.142.207.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAdIj-0003bV-Aa for 6lowpan@ietf.org; Mon, 16 Jul 2007 23:00:41 -0400 Received: (qmail 7176 invoked by uid 60001); 17 Jul 2007 03:00:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=rmWXGDHzOe26u7fTu6O2CYPqMETV/MOX1iwITmxXAs+URmi36QBxabGMhlgreBs12RlyXRLW9cljpc4i188jPdLj+nFr4qJLizkVlLeooSYCnREberDEMrfaw66xXgro/UqW0LkelLWwLMdwReqp6N5YD97OtoWqatCyfDBddcM=; X-YMail-OSG: ryhHixkVM1kCrNhf56g8qZ3erLz5RNHAKf6c98bI.99RjPC9N1T2DWyDLF4CV0yiFcmLM1_Te2sW1kng4ruVonJ3qO3fqQaSX4Ttc6vVdF4Lupc- Received: from [64.1.210.240] by web81911.mail.mud.yahoo.com via HTTP; Mon, 16 Jul 2007 20:00:36 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Mon, 16 Jul 2007 20:00:36 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix To: David Culler , 6lowpan@ietf.org MIME-Version: 1.0 Message-ID: <820518.3244.qm@web81911.mail.mud.yahoo.com> X-Spam-Score: 1.4 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1729175918==" Errors-To: 6lowpan-bounces@ietf.org --===============1729175918== Content-Type: multipart/alternative; boundary="0-1846708184-1184641236=:3244" --0-1846708184-1184641236=:3244 Content-Type: text/plain; charset=ascii We actually discussed this a while back with Erik Nordmark in some detail. The issue is that an IPv6 link can have several prefixes, and they are not guaranteed to be advertised in any particular order by the router or routers on that link. So one could not use a bit pattern easily to refer to: * "the" global prefix (cuz there may be more than one) * "the first global prefix" (cuz node A's first might be node B's second) At the end we did not see a clear and easy way of doing so, so we limited the header compression scheme to only the link-local addresses (cuz the "prefix" in that case in unequivocally known). It also did not seem like overall, complicating the basic scheme with additional header compression for global prefixes was very meaningful as most traffic would probably be link-local anyways. In case it is not clear, an assumption above (as in all the format document) was that we wanted to have support for IPv6, not for some watered-down or somewhat tweaked (even if only slightly) version of IPv6. It was also pretty clear that without this we wouldn't have been able to have a working group. That was several years ago, so our assumptions may need to change, and it would be good to hear that based on folks' experience, of course. -gabriel ----- Original Message ---- From: David Culler To: 6lowpan@ietf.org Sent: Monday, July 16, 2007 4:38:26 PM Subject: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix Folks, We'd like to draw your attention to I-D http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc1g-00.txt that was posted two weeks ago. It generalizes HC1 to provide the same level of header compression for a PAN-wide global prefix. HC1 only compresses addresses that use the link local prefix. A global prefix is always used in communication with endpoints external to the PAN. It may be used as well within the PAN. In the context of mesh-under, HC1g applies to originator / final. Thanks, David Culler and Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-1846708184-1184641236=:3244 Content-Type: text/html; charset=ascii
We actually discussed this a while back with Erik Nordmark in some detail. The issue is that an IPv6 link
can have several prefixes, and they are not guaranteed to be advertised in any particular order by the router
or routers on that link. So one could not use a bit pattern easily to refer to:

    * "the" global prefix (cuz there may be more than one)
    * "the first global prefix" (cuz node A's first might be node B's second)

At the end we did not see a clear and easy way of doing so, so we limited the header compression scheme
to only the link-local addresses (cuz the "prefix" in that case in unequivocally known). It also did not seem
like overall, complicating the basic scheme with additional header compression for global prefixes was
very meaningful as most traffic would probably be link-local anyways.

In case it is not clear, an assumption above (as in all the format document) was that we wanted to have
support for IPv6, not for some watered-down or somewhat tweaked (even if only slightly) version of IPv6.
It was also pretty clear that without this we wouldn't have been able to have a working group.

That was several years ago, so our assumptions may need to change, and it would be good to hear
that based on folks' experience, of course.

-gabriel

----- Original Message ----
From: David Culler <david.culler@gmail.com>
To: 6lowpan@ietf.org
Sent: Monday, July 16, 2007 4:38:26 PM
Subject: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix

Folks,
  We'd like to draw your attention to I-D 

    http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc1g-00.txt

that was posted two weeks ago.  It generalizes HC1 to provide the same level of header compression for a PAN-wide global prefix.  HC1 only compresses addresses that use the link local prefix.  A global prefix is always used in communication with endpoints external to the PAN.  It may be used as well within the PAN.  In the context of mesh-under, HC1g applies to originator / final. 

Thanks,

     David Culler and Jonathan Hui
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--0-1846708184-1184641236=:3244-- --===============1729175918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1729175918==-- From 6lowpan-bounces@ietf.org Mon Jul 16 23:55:48 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAeA8-0007YK-Eu; Mon, 16 Jul 2007 23:55:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAeA7-0007YF-Hy for 6lowpan@ietf.org; Mon, 16 Jul 2007 23:55:47 -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 1IAeA3-0005I1-5n for 6lowpan@ietf.org; Mon, 16 Jul 2007 23:55:47 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id A972D1DDC394; Mon, 16 Jul 2007 20:55:42 -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.143] (adsl-71-142-73-24.dsl.pltn13.pacbell.net [71.142.73.24]) by secure.archedrock.com (Postfix) with ESMTP id 5BE8F1DDC390; Mon, 16 Jul 2007 20:55:41 -0700 (PDT) Message-ID: <469C3DAD.1050901@archrock.com> Date: Mon, 16 Jul 2007 20:55:25 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: gabriel montenegro Subject: Re: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix References: <820518.3244.qm@web81911.mail.mud.yahoo.com> In-Reply-To: <820518.3244.qm@web81911.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: 8b431ad66d60be2d47c7bfeb879db82c Cc: 6lowpan@ietf.org, David Culler X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org gabriel montenegro wrote: > We actually discussed this a while back with Erik Nordmark in some > detail. The issue is that an IPv6 link > can have several prefixes, and they are not guaranteed to be advertised > in any particular order by the router > or routers on that link. So one could not use a bit pattern easily to > refer to: > > * "the" global prefix (cuz there may be more than one) > * "the first global prefix" (cuz node A's first might be node B's > second) > Yes, the global compressible prefix must be clearly identified if nodes are assigned more than one prefix. Our thoughts are that this can be done using either stateless autoconfiguration mechanisms (i.e. IPv6 ND), by extending RAs and using a reserved bit to indicate its compressible status; through stateful autoconfiguration (i.e. DHCPv6) through IA Address options; or through some yet-to-be-defined 6LoWPAN configuration protocol. If there is a configuration error and more than one global prefix is marked as compressible, then the node must not compress the prefix. This is not stated in the current draft and probably should be. > At the end we did not see a clear and easy way of doing so, so we > limited the header compression scheme > to only the link-local addresses (cuz the "prefix" in that case in > unequivocally known). It also did not seem > like overall, complicating the basic scheme with additional header > compression for global prefixes was > very meaningful as most traffic would probably be link-local anyways. Link-local communication covers an important subset of applications. But we do see benefits in allowing nodes to communicate directly with other IP devices outside the LoWPAN network. By utilizing IP end-to-end, LoWPAN nodes can readily communicate with any other non-LoWPAN node, and it can do so without a stateful translation gateway in between. > In case it is not clear, an assumption above (as in all the format > document) was that we wanted to have > support for IPv6, not for some watered-down or somewhat tweaked (even if > only slightly) version of IPv6. > It was also pretty clear that without this we wouldn't have been able to > have a working group. We completely agree that we would like to support full IPv6. LOWPAN_HC1g supports just that, allowing nodes to communicate with any arbitrary prefix. -- Jonathan Hui jhui@archrock.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 17 00:23:21 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAeak-0002As-V8; Tue, 17 Jul 2007 00:23:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAeaj-00028b-Ui for 6lowpan@ietf.org; Tue, 17 Jul 2007 00:23:17 -0400 Received: from web81909.mail.mud.yahoo.com ([68.142.207.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAeaf-00068j-J2 for 6lowpan@ietf.org; Tue, 17 Jul 2007 00:23:17 -0400 Received: (qmail 46708 invoked by uid 60001); 17 Jul 2007 04:23:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=iG/y9rT8Dvd3PxQ4dMr4n0TRaCp5jG1cVb2Vp2lb5JIqWeDqbBb8xZozVPUqCCtdBQFiQN1nrVrtEvKIaFPqAXrlr1Ii2NKS0T8zCQPusHS0FzylTnObJBqcw/55QkRI3ARdT63bQQI/ClVh2Qg4qP3twz1juGwenvpIjq+wNw4=; X-YMail-OSG: br45OXUVM1mXCKMYk4DY_GyRf.xW_PUcAaZ96Ckrwl7n4dYPYBgjlb6Tg._lmMSAuRk3Zg-- Received: from [131.107.0.103] by web81909.mail.mud.yahoo.com via HTTP; Mon, 16 Jul 2007 21:23:13 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Mon, 16 Jul 2007 21:23:13 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix To: Jonathan Hui MIME-Version: 1.0 Message-ID: <78271.44694.qm@web81909.mail.mud.yahoo.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 6lowpan@ietf.org, David Culler X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1537835862==" Errors-To: 6lowpan-bounces@ietf.org --===============1537835862== Content-Type: multipart/alternative; boundary="0-1193596067-1184646193=:44694" --0-1193596067-1184646193=:44694 Content-Type: text/plain; charset=ascii thanks Jonathan, just a quick comment below... ----- Original Message ---- Link-local communication covers an important subset of applications. But we do see benefits in allowing nodes to communicate directly with other IP devices outside the LoWPAN network.... gab> That is not an issue, as nodes are perfectly capable to communicate directly with other IP devices outside the LoWPAN network. They can certainly use global prefixes, no issue there. The only question was whether such communication merited being optimized. It seemed to us (without any real data to support it, though) that the extra complexity was not worth the marginal benefit cuz most packets from puny devices would be local and only a small percentage would need to use the global prefix. If there is any data to justify the tradeoff of the additional complexity, it would be good to see it. --0-1193596067-1184646193=:44694 Content-Type: text/html; charset=ascii
thanks Jonathan,

just a quick comment below...

----- Original Message ----

Link-local communication covers an important subset of applications. But
we do see benefits in allowing nodes to communicate directly with other
IP devices outside the LoWPAN network....

gab> That is not an issue, as nodes are perfectly capable to communicate directly
with other IP devices outside the LoWPAN network. They can certainly use
global prefixes, no issue there. The only question was whether such communication
merited being optimized. It seemed to us (without any real data to support it, though)
that the extra complexity was not worth the marginal benefit cuz most packets from
puny devices would be local and only a small percentage would need to use the global prefix.
If there is any data to justify the tradeoff of the additional complexity, it would be good
to see it.

--0-1193596067-1184646193=:44694-- --===============1537835862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1537835862==-- From 6lowpan-bounces@ietf.org Tue Jul 17 02:30:12 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgZU-0001EM-9n; Tue, 17 Jul 2007 02:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgZS-0001ED-VU for 6lowpan@ietf.org; Tue, 17 Jul 2007 02:30:06 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAgZO-0001ZA-Fz for 6lowpan@ietf.org; Tue, 17 Jul 2007 02:30:06 -0400 Received: by wx-out-0506.google.com with SMTP id h27so1302995wxd for <6lowpan@ietf.org>; Mon, 16 Jul 2007 23:30:02 -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:references; b=McmdQdpi2UZ7mCslGbhsax8lMGeogO0bmvIzxee2yLz35iS+3e9AciXeYWt+enS9qM0QtYIaipO0NKDa6i0KrJhnaBAx7rVTMJk1rj448ObKigejWteltrbcpgfuBSF2g5NcmJmMqEE24m4UtqdxQyYBIC8ERKbUi5geFTQ+DIk= 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:references; b=twnfCIjdxajBVxJQEoLF/FP2GcoLV03siuP1yn6q9RfRTw4BgNzt3Q0EO55+Z9d/gVQSQbGFP89oJOGwZhcV4CCb7TEYH8SvvkjrOHqGQitaKCJbUbtngqucK43VFYy7NI4quUOffc7LYss246IUiK3pqrZyb2HfpeqwtVOuzv0= Received: by 10.70.28.9 with SMTP id b9mr233169wxb.1184653802225; Mon, 16 Jul 2007 23:30:02 -0700 (PDT) Received: by 10.70.128.2 with HTTP; Mon, 16 Jul 2007 23:30:02 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 23:30:02 -0700 From: "David Culler" To: "Jonathan Hui" Subject: Re: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix In-Reply-To: <469C3DAD.1050901@archrock.com> MIME-Version: 1.0 References: <820518.3244.qm@web81911.mail.mud.yahoo.com> <469C3DAD.1050901@archrock.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0003257776==" Errors-To: 6lowpan-bounces@ietf.org --===============0003257776== Content-Type: multipart/alternative; boundary="----=_Part_38836_11312360.1184653802181" ------=_Part_38836_11312360.1184653802181 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Gabriel, Thanks for weighing in. To expand a little on Jonathan's comments... The potential to have multiple global ipv6 would not seem to suggest that NONE of them should be compressible. hc1g allows ONE of them to be, but doesn't prevent the use of the others. Doesn't it seem a shame to lose the advantages of 6LoWPAN just because you assign IPv6 addresses to the nodes in addition to the default link local address. The philosophy of 6LoWPAN seems to be to provide a way to improve the common case while still supporting the general case correctly. We cannot compress all the UDP ports, just a selected region. I think that you would agree that two of the most important reasons for putting IPV6 on the 802.15.4 network in the first place is the ability to name a node with a globally meaningful IP address and the ability to route packets to and from nodes on the 802.15.4 network. HC1g preserves the the HC1 compression in these two cases. On 7/16/07, Jonathan Hui wrote: > > > gabriel montenegro wrote: > > We actually discussed this a while back with Erik Nordmark in some > > detail. The issue is that an IPv6 link > > can have several prefixes, and they are not guaranteed to be advertised > > in any particular order by the router > > or routers on that link. So one could not use a bit pattern easily to > > refer to: > > > > * "the" global prefix (cuz there may be more than one) > > * "the first global prefix" (cuz node A's first might be node B's > > second) > > > > Yes, the global compressible prefix must be clearly identified if nodes > are assigned more than one prefix. Our thoughts are that this can be > done using either stateless autoconfiguration mechanisms (i.e. IPv6 ND), > by extending RAs and using a reserved bit to indicate its compressible > status; through stateful autoconfiguration (i.e. DHCPv6) through IA > Address options; or through some yet-to-be-defined 6LoWPAN configuration > protocol. If there is a configuration error and more than one global > prefix is marked as compressible, then the node must not compress the > prefix. This is not stated in the current draft and probably should be. > > > At the end we did not see a clear and easy way of doing so, so we > > limited the header compression scheme > > to only the link-local addresses (cuz the "prefix" in that case in > > unequivocally known). It also did not seem > > like overall, complicating the basic scheme with additional header > > compression for global prefixes was > > very meaningful as most traffic would probably be link-local anyways. > > Link-local communication covers an important subset of applications. But > we do see benefits in allowing nodes to communicate directly with other > IP devices outside the LoWPAN network. By utilizing IP end-to-end, > LoWPAN nodes can readily communicate with any other non-LoWPAN node, and > it can do so without a stateful translation gateway in between. > > > In case it is not clear, an assumption above (as in all the format > > document) was that we wanted to have > > support for IPv6, not for some watered-down or somewhat tweaked (even if > > only slightly) version of IPv6. > > It was also pretty clear that without this we wouldn't have been able to > > have a working group. > > We completely agree that we would like to support full IPv6. LOWPAN_HC1g > supports just that, allowing nodes to communicate with any arbitrary > prefix. > > -- > Jonathan Hui > jhui@archrock.com > ------=_Part_38836_11312360.1184653802181 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Gabriel,
  Thanks for weighing in.  To expand a little on Jonathan's comments...  The potential to have multiple global ipv6 would not seem to suggest that NONE of them should be compressible.  hc1g allows ONE of them to be, but doesn't prevent the use of the others.  Doesn't it seem a shame to lose the advantages of 6LoWPAN just because you assign IPv6 addresses to the nodes in addition to the default link local address.  The philosophy of 6LoWPAN seems to be to provide a way to improve the common case while still supporting the general case correctly.  We cannot compress all the UDP ports, just a selected region.  I think that you would agree that two of the most important reasons for putting IPV6 on the 802.15.4 network in the first place is the ability to name a node with a globally meaningful IP address and the ability to route packets to and from nodes on the 802.15.4 network.  HC1g preserves the the HC1 compression in these two cases.

On 7/16/07, Jonathan Hui <jhui@archrock.com> wrote:

gabriel montenegro wrote:
> We actually discussed this a while back with Erik Nordmark in some
> detail. The issue is that an IPv6 link
> can have several prefixes, and they are not guaranteed to be advertised
> in any particular order by the router
> or routers on that link. So one could not use a bit pattern easily to
> refer to:
>
>     * "the" global prefix (cuz there may be more than one)
>     * "the first global prefix" (cuz node A's first might be node B's
> second)
>

Yes, the global compressible prefix must be clearly identified if nodes
are assigned more than one prefix. Our thoughts are that this can be
done using either stateless autoconfiguration mechanisms (i.e. IPv6 ND),
by extending RAs and using a reserved bit to indicate its compressible
status; through stateful autoconfiguration (i.e. DHCPv6) through IA
Address options; or through some yet-to-be-defined 6LoWPAN configuration
protocol. If there is a configuration error and more than one global
prefix is marked as compressible, then the node must not compress the
prefix. This is not stated in the current draft and probably should be.

> At the end we did not see a clear and easy way of doing so, so we
> limited the header compression scheme
> to only the link-local addresses (cuz the "prefix" in that case in
> unequivocally known). It also did not seem
> like overall, complicating the basic scheme with additional header
> compression for global prefixes was
> very meaningful as most traffic would probably be link-local anyways.

Link-local communication covers an important subset of applications. But
we do see benefits in allowing nodes to communicate directly with other
IP devices outside the LoWPAN network. By utilizing IP end-to-end,
LoWPAN nodes can readily communicate with any other non-LoWPAN node, and
it can do so without a stateful translation gateway in between.

> In case it is not clear, an assumption above (as in all the format
> document) was that we wanted to have
> support for IPv6, not for some watered-down or somewhat tweaked (even if
> only slightly) version of IPv6.
> It was also pretty clear that without this we wouldn't have been able to
> have a working group.

We completely agree that we would like to support full IPv6. LOWPAN_HC1g
supports just that, allowing nodes to communicate with any arbitrary prefix.

--
Jonathan Hui
jhui@archrock.com

------=_Part_38836_11312360.1184653802181-- --===============0003257776== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0003257776==-- From 6lowpan-bounces@ietf.org Tue Jul 17 03:00:29 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAh2q-0002V7-SR; Tue, 17 Jul 2007 03:00:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAh2p-0002SZ-7C for 6lowpan@ietf.org; Tue, 17 Jul 2007 03:00:27 -0400 Received: from web81906.mail.mud.yahoo.com ([68.142.207.185]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAh2o-00047s-Dn for 6lowpan@ietf.org; Tue, 17 Jul 2007 03:00:27 -0400 Received: (qmail 72582 invoked by uid 60001); 17 Jul 2007 07:00:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Ev8GdxnamNm+AAYQ/Yftl3bdZX3elBqV89cbZs93/iml1cRu5VHZ5vZoMYLjS9hS2gGKr2870F/D1V59V6dMEmUJipXGzCVMleKW5ZSe+a7++1SD6CHTRaOxNu8BFspEdRr7TYr2RHpTtHJtmysF7mxjfYa/MjCEdFtSiK1gz2Q=; X-YMail-OSG: pW4pyUsVM1l8_rRwpS3JfCyEPTZE7vfcLqjqAyMvcmgv0EyDRjTtMGYhi.u2wwYtug-- Received: from [64.1.210.240] by web81906.mail.mud.yahoo.com via HTTP; Tue, 17 Jul 2007 00:00:04 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Tue, 17 Jul 2007 00:00:04 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix To: David Culler , Jonathan Hui MIME-Version: 1.0 Message-ID: <998769.70363.qm@web81906.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1734410685==" Errors-To: 6lowpan-bounces@ietf.org --===============1734410685== Content-Type: multipart/alternative; boundary="0-1857693525-1184655604=:70363" --0-1857693525-1184655604=:70363 Content-Type: text/plain; charset=ascii Hi David, I hope it's clear from several msgs ago that I completely agree with the objective. What I'm not sure is how (if) you've achieved it. >From your draft: Compressed 64-bit Address: 64-bit prefix elided, 64-bit interface identifier carried in-line. The 64-bit prefix is derived from the 64-bit prefix assigned to the PAN.When we looked at it, it seemed like using routing advertisements to dole out prefix information did not allow for the above (no such thing as *the* link prefix). One can always define additional mechanisms to go with the new semantics, get those approved, published, etc. It seems to me like those are needed if the above snippet is to work. I'm just asking if you had data to determine that the extra effort needed to actually make this work is worth it, given the marginal benefit. We did not have any real deployment data, by the way. -gabriel ----- Original Message ---- From: David Culler To: Jonathan Hui Cc: gabriel montenegro ; 6lowpan@ietf.org Sent: Monday, July 16, 2007 11:30:02 PM Subject: Re: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix Gabriel, Thanks for weighing in. To expand a little on Jonathan's comments... The potential to have multiple global ipv6 would not seem to suggest that NONE of them should be compressible. hc1g allows ONE of them to be, but doesn't prevent the use of the others. Doesn't it seem a shame to lose the advantages of 6LoWPAN just because you assign IPv6 addresses to the nodes in addition to the default link local address. The philosophy of 6LoWPAN seems to be to provide a way to improve the common case while still supporting the general case correctly. We cannot compress all the UDP ports, just a selected region. I think that you would agree that two of the most important reasons for putting IPV6 on the 802.15.4 network in the first place is the ability to name a node with a globally meaningful IP address and the ability to route packets to and from nodes on the 802.15.4 network. HC1g preserves the the HC1 compression in these two cases. On 7/16/07, Jonathan Hui wrote: gabriel montenegro wrote: > We actually discussed this a while back with Erik Nordmark in some > detail. The issue is that an IPv6 link > can have several prefixes, and they are not guaranteed to be advertised > in any particular order by the router > or routers on that link. So one could not use a bit pattern easily to > refer to: > > * "the" global prefix (cuz there may be more than one) > * "the first global prefix" (cuz node A's first might be node B's > second) > Yes, the global compressible prefix must be clearly identified if nodes are assigned more than one prefix. Our thoughts are that this can be done using either stateless autoconfiguration mechanisms (i.e. IPv6 ND), by extending RAs and using a reserved bit to indicate its compressible status; through stateful autoconfiguration (i.e. DHCPv6) through IA Address options; or through some yet-to-be-defined 6LoWPAN configuration protocol. If there is a configuration error and more than one global prefix is marked as compressible, then the node must not compress the prefix. This is not stated in the current draft and probably should be. > At the end we did not see a clear and easy way of doing so, so we > limited the header compression scheme > to only the link-local addresses (cuz the "prefix" in that case in > unequivocally known). It also did not seem > like overall, complicating the basic scheme with additional header > compression for global prefixes was > very meaningful as most traffic would probably be link-local anyways. Link-local communication covers an important subset of applications. But we do see benefits in allowing nodes to communicate directly with other IP devices outside the LoWPAN network. By utilizing IP end-to-end, LoWPAN nodes can readily communicate with any other non-LoWPAN node, and it can do so without a stateful translation gateway in between. > In case it is not clear, an assumption above (as in all the format > document) was that we wanted to have > support for IPv6, not for some watered-down or somewhat tweaked (even if > only slightly) version of IPv6. > It was also pretty clear that without this we wouldn't have been able to > have a working group. We completely agree that we would like to support full IPv6. LOWPAN_HC1g supports just that, allowing nodes to communicate with any arbitrary prefix. -- Jonathan Hui jhui@archrock.com --0-1857693525-1184655604=:70363 Content-Type: text/html; charset=ascii
Hi David,

I hope it's clear from several msgs ago that I completely agree with the objective.
What I'm not sure is how (if) you've achieved it.

From your draft:
      Compressed 64-bit Address:  64-bit prefix elided, 64-bit interface
         identifier carried in-line.  The 64-bit prefix is derived from
         the 64-bit prefix assigned to the PAN.
When we looked at it, it seemed like using routing advertisements to dole out prefix information
did not allow for the above (no such thing as *the* link prefix). One can always define additional
mechanisms to go with the new semantics, get those approved, published, etc.  It seems to me like
those are needed if the above snippet is to work. I'm just asking if you had data to determine that
the extra effort needed to actually make this work is worth it, given the marginal benefit. We did not
have any real deployment data, by the way.

-gabriel

----- Original Message ----
From: David Culler <david.culler@gmail.com>
To: Jonathan Hui <jhui@archrock.com>
Cc: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>; 6lowpan@ietf.org
Sent: Monday, July 16, 2007 11:30:02 PM
Subject: Re: [6lowpan] Looking for feedback on HC1g - stateless header compression for routable prefix

Gabriel,
  Thanks for weighing in.  To expand a little on Jonathan's comments...  The potential to have multiple global ipv6 would not seem to suggest that NONE of them should be compressible.  hc1g allows ONE of them to be, but doesn't prevent the use of the others.  Doesn't it seem a shame to lose the advantages of 6LoWPAN just because you assign IPv6 addresses to the nodes in addition to the default link local address.  The philosophy of 6LoWPAN seems to be to provide a way to improve the common case while still supporting the general case correctly.  We cannot compress all the UDP ports, just a selected region.  I think that you would agree that two of the most important reasons for putting IPV6 on the 802.15.4 network in the first place is the ability to name a node with a globally meaningful IP address and the ability to route packets to and from nodes on the 802.15.4 network.  HC1g preserves the the HC1 compression in these two cases.

On 7/16/07, Jonathan Hui <jhui@archrock.com> wrote:

gabriel montenegro wrote:
> We actually discussed this a while back with Erik Nordmark in some
> detail. The issue is that an IPv6 link
> can have several prefixes, and they are not guaranteed to be advertised
> in any particular order by the router
> or routers on that link. So one could not use a bit pattern easily to
> refer to:
>
>     * "the" global prefix (cuz there may be more than one)
>     * "the first global prefix" (cuz node A's first might be node B's
> second)
>

Yes, the global compressible prefix must be clearly identified if nodes
are assigned more than one prefix. Our thoughts are that this can be
done using either stateless autoconfiguration mechanisms (i.e. IPv6 ND),
by extending RAs and using a reserved bit to indicate its compressible
status; through stateful autoconfiguration (i.e. DHCPv6) through IA
Address options; or through some yet-to-be-defined 6LoWPAN configuration
protocol. If there is a configuration error and more than one global
prefix is marked as compressible, then the node must not compress the
prefix. This is not stated in the current draft and probably should be.

> At the end we did not see a clear and easy way of doing so, so we
> limited the header compression scheme
> to only the link-local addresses (cuz the "prefix" in that case in
> unequivocally known). It also did not seem
> like overall, complicating the basic scheme with additional header
> compression for global prefixes was
> very meaningful as most traffic would probably be link-local anyways.

Link-local communication covers an important subset of applications. But
we do see benefits in allowing nodes to communicate directly with other
IP devices outside the LoWPAN network. By utilizing IP end-to-end,
LoWPAN nodes can readily communicate with any other non-LoWPAN node, and
it can do so without a stateful translation gateway in between.

> In case it is not clear, an assumption above (as in all the format
> document) was that we wanted to have
> support for IPv6, not for some watered-down or somewhat tweaked (even if
> only slightly) version of IPv6.
> It was also pretty clear that without this we wouldn't have been able to
> have a working group.

We completely agree that we would like to support full IPv6. LOWPAN_HC1g
supports just that, allowing nodes to communicate with any arbitrary prefix.

--
Jonathan Hui
jhui@archrock.com


--0-1857693525-1184655604=:70363-- --===============1734410685== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1734410685==-- From 6lowpan-bounces@ietf.org Tue Jul 17 12:49:23 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqEi-0002Du-Rr; 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-0002DT-R5 for 6lowpan@lists.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-0006xp-8H for 6lowpan@lists.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 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 Subject: [6lowpan] Re: [RSN] Fwd: I-D ACTION:draft-culler-rl2n-routing-reqs-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 >> >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 17 19:27:26 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAwRu-0000dq-TN; Tue, 17 Jul 2007 19:27:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAwRt-0000dj-9U for 6lowpan@ietf.org; Tue, 17 Jul 2007 19:27:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAwRr-0002u7-GM for 6lowpan@ietf.org; Tue, 17 Jul 2007 19:27:21 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 17 Jul 2007 16:27:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KACPtnEarR7PE/2dsb2JhbAAUghg2l3o X-IronPort-AV: i="4.16,547,1175497200"; d="scan'208,217"; a="183846284:sNHT59768163" 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 l6HNRINj002888; Tue, 17 Jul 2007 16:27:18 -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 l6HNR96E029755; Tue, 17 Jul 2007 23:27: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 19:27:10 -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:27:08 -0400 In-Reply-To: References: <46558EF0.2040309@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <6DE9C3D7-5366-4120-B823-D67900C1F668@cisco.com> From: JP Vasseur Subject: Re: [6lowpan] 6lowpan rechartering Date: Tue, 17 Jul 2007 19:26:33 -0400 To: Ki-Hyung Kim X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Jul 2007 23:27:08.0939 (UTC) FILETIME=[FEA275B0:01C7C8C9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=19154; t=1184714838; x=1185578838; 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[6lowpan]=206lowpan=20rechartering |Sender:=20; bh=Oij0dVKKXKTX7NpqRURA0YdmyN3cuE9hbkM4G6z5iP4=; b=DJ5mVy/wcy7aCBIdDWZUp22x4R+vRLVUHaZkI8TtILgmTLGnjsXzwjYb9dJiKQ5kbEs0hVFM l3JpuUvGzzN0hxfoWbilfxpUe8xl+ZXOpsqJYWeFi5WaBGN34OU6gyZs; 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: efb5d987e2484f3d9a304cc31a003441 Cc: 6lowpan@ietf.org, 6lowpan-chairs@tools.ietf.org, David Culler X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1846799789==" Errors-To: 6lowpan-bounces@ietf.org --===============1846799789== Content-Type: multipart/alternative; boundary=Apple-Mail-73-249163325 --Apple-Mail-73-249163325 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Hi, On May 24, 2007, at 12:00 PM, Ki-Hyung Kim wrote: > Hi, Mark, > This is Ki-Hyung Kim. It is a great news from you. > We have been waiting for this start of rechartering so long time. > > My comments are in-line. > > > On 5/24/07, Mark Townsley wrote: > > Folks, > > I'd like the group to continue its work on rechartering. RSN is =20 > starting > to work on the routing piece, and this group needs to formulate its > charter in concert with this for the remaining items. > > Starting with what we have from the last meeting, I'll offer the =20 > group my > thoughts on each as work items to start discussion. Please give your > feedback now, I'd like for the chairs to be able to get a proposed > charter together in time for Chicago. > > I copied text from > http://www3.ietf.org/proceedings/07mar/slides/6lowpan-0.pdf > > > Charter 1/5 > > > > Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND > > Optimizations" to define the required optimizations to make > > IPv6 ND applicable in 6lowpans, given the fact that IPv6 ND > > is too expensive for the devices of 6lowpan and requires > > multicast. This document will define how to bootstrap a > > 6lowpan network and explore ND optimizations such as > > reusing the 802.15.4 network structure (use the > > coordinators), and obviate multicast by having devices talk > > to coordinators without creating a single point-of-failure, and > > changing the IPv6 ND multicast semantics. This document > > will be a proposed standard. > > Bootstrapping and ND would seem to be related, but separate, work =20 > items > (but feel free to convince me otherwise). I think this work item needs > better scoping with respect to what "bootstrapping" really means. =20 > Also, > it would be nice to get away from 802.15.4-specific jargon ( e.g., you > shouldn't have to be intimately familiar with 802.15.4 to understand > what the work item is). > > Kim: Yes, I agree with you that bootstrapping and ND should be =20 > separate items, even though they are related. In order to get =20 > interoperable 6lowpan products, we should have a common =20 > bootstrapping protocol. A sensor node should inter-work with =20 > neighbors and 6lowpan routers when it boots or moves to the new =20 > 6lowpan region. > > > > > Charter 2/5 > > > > Produce "Problem Statement for Stateful Header > > Compression in 6lowpans" to document the problem of > > using stateful header compression (2507, ROHC) in > > 6lowpans. Currently 6lowpan only specifies the use of > > stateless header compression given the assumption that > > stateful header compression may be too complex. This > > document will determine if the assumption is correct and will > > be an informational document. > > I see no problem documenting this informationally, I would hope =20 > that it > wouldn't slow down PS work though. > > > > > Charter 3/5 > > > > Produce "Recommendations for 6lowpan > > Applications" to define a set of recommendations of > > protocols to use for applications. The recommendations > > will cover protocols for transport, application layer, > > discovery, configuration and commissioning. This > > document will be an informational document. > > This sounds more like an overall framework document. I wonder why > Routing isn't listed here. > > Kim: I think the title and the details of this item seem to be a =20 > little bit out of focus. My idea is to separate this item into the =20 > following two items. (Much of this idea was already discussed with =20 > Geoff and David Culler at the last IETF meeting) > Kim: First item is Recommendations for 6lowpan Applications which =20 > states and classifies typical 6lowpan applications and possible =20 > protocol requirements and adaptations for each of them. Yes, see my previous comment wrt to the new proposed charter and =20 applicability statements. > > Kim: Second item is 6lowpan Network Architecture which states the =20 > architecture of the IP over LoWPAN. It states routing protocols =20 > (Mesh under IP, Route over IP, or both of them, scalable routing, =20 > or other candidate routing protocols), commissioning, =20 > bootstrapping, ND, reliable and efficient delivery of packets (or =20 > fragments), configuration, discovery of networks and services), and =20= > mobility support. Absolutely: Geoff, David and I started such as ID. Should be posted =20 right after this IETF with welcome comments. > > > > > > Charter 4/5 > > > > Produce "6lowpan Mesh Routing" to evaluate different > > mesh routing protocols for use within 6lowpans. While most > > routing protocols are defined above the IP layer, 6lowpan > > requires a mesh routing protocol below the IP layer. "6lowpan > > Mesh Routing" may be several proposed standard > > documents. > > Something to discuss with RSN so that we have a clear understanding of > the goals of MAC vs. IP routing, whether we need to do both or not, =20= > how > much of the mechanism could be shared if we do need both, etc. I can't agree more ! See the email that I just sent out. > > Kim: I think we need routing protocols underneath IP, regardless of =20= > the efforts at RSN (I agree with JP and David that it is valuable =20 > to try to find possible routing protocols for sensor networks =20 > especially over IP). Good, although I'm still questioning why we need mesh-under routing. =20 But times will come when we should have that discussion. > This is because we will have lots of 6lowpan fragments of IP =20 > packets (of course depending on the applications and packet size). =20 > The fragments should anyway be routed underneath IP because the =20 > fragments can not be seen above IP. Not sure of what you mean by "routing fragment underneath IP" ?? > Mesh routing protocol is one of the candidates, and a scalable =20 > routing protocol could be an alternate choice especially when lots =20 > of 6lowpan nodes are to be deployed in a network, in that a routing =20= > protocol based on the routing table on sensor nodes might incur too =20= > much overhead to manage routing table updates. Well this has to be demonstrated. Thanks. JP. > > > > > > Charter 5/5 > > > > Produce "6lowpan Security Analysis" to define the threat > > model of 6lowpans and to document suitability of existing > > key management schemes and to discuss > > bootstrapping/installation/commissioning/setup issues. This > > document will be an informational document. > > Yes, and we will want to appoint a security adviser unless we already > have an expert in the group. > > These Charter items, with some cleanup and tightening, seem like a > reasonable start to me. I'd like to know what others in the group > believe, and if we have editors and energy lined up for the tasks. > > Kim: Overall, I hope we could start off the works on PS as well as =20 > the informational documents. > The routing protocol could be one of them. Indeed, the market is =20 > waiting for the 6lowpan products. > We spent two and half years for making one PS document. That is =20 > just start of the actual impact on the market. > We need to do some work at least routing protocols ASAP while =20 > starting off the sensor-op testing (sensor network version of =20 > interop). > > Thanks, > > - Mark > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > --=20 > Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8=B5=B7=E4=BA=A8) > Associate Professor > Division of Information and Computer Eng., Ajou University, Suwon, =20 > Korea 442-749 > Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 =20 > http://www.6lowpan.org > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan --Apple-Mail-73-249163325 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi,

On May 24, = 2007, at 12:00 PM, Ki-Hyung Kim wrote:

Hi, = Mark,
This is Ki-Hyung Kim.=C2=A0It is a great news from = you.
We have been waiting for this start of rechartering so = long time.
=C2=A0
My comments are in-line.
=

=C2=A0
On 5/24/07, Mark Townsley <townsley@cisco.com> = wrote:

Folks,

I'd like the group to continue its work on = rechartering. RSN is starting
to work on the routing piece, and this = group needs to formulate its
charter in concert with this for the = remaining items.

Starting with what we have from the last = meeting, I'll offer the group my
thoughts on each as work items to = start discussion. Please give your
feedback now, I'd like for the = chairs to be able to get a proposed
charter together in time for = Chicago.

I copied text from
http:= //www3.ietf.org/proceedings/07mar/slides/6lowpan-0.pdf

> = Charter 1/5
>
> Produce "6lowpan Bootstrapping and 6lowpan = IPv6 ND
> Optimizations" to define the required optimizations to = make
> IPv6 ND applicable in 6lowpans, given the fact that IPv6 = ND
> is too expensive for the devices of 6lowpan and requires =
> multicast. This document will define how to bootstrap a
> = 6lowpan network and explore ND optimizations such as
> reusing the = 802.15.4 network structure (use the
> coordinators), and obviate = multicast by having devices talk
> to coordinators without = creating a single point-of-failure, and
> changing the IPv6 ND = multicast semantics. This document
> will be a proposed = standard.

Bootstrapping and ND would seem to be related, but = separate, work items
(but feel free to convince me otherwise). I = think this work item needs
better scoping with respect to what = "bootstrapping" really means. Also,
it would be nice to get away from = 802.15.4-specific jargon ( e.g., you
shouldn't have to be intimately = familiar with 802.15.4 to understand
what the work item = is).
=C2=A0
Kim: Yes, I agree with you that = bootstrapping and ND should be separate items, even though they are = related. In order to=C2=A0get interoperable 6lowpan products, we should = have a common bootstrapping protocol. A sensor node should inter-work = with neighbors and 6lowpan routers when it boots or moves to the new = 6lowpan region.
=C2=A0

=C2=A0
=
> Charter = 2/5
>
> Produce "Problem Statement for Stateful = Header
> Compression in 6lowpans" to document the problem of =
> using stateful header compression (2507, ROHC) in
> = 6lowpans. Currently 6lowpan only specifies the use of
> stateless = header compression given the assumption that
> stateful header = compression may be too complex. This
> document will determine if = the assumption is correct and will
> be an informational = document.

I see no problem documenting this informationally, I = would hope that it
wouldn't slow down PS work though. =

>
> Charter 3/5
>
> Produce = "Recommendations for 6lowpan
> Applications" to define a set of = recommendations of
> protocols to use for applications. The = recommendations
> will cover protocols for transport, application = layer,
> discovery, configuration and commissioning. This
> = document will be an informational document.

This sounds more like = an overall framework document. I wonder why
Routing isn't listed = here.
=C2=A0
Kim: I think the title and the = details of this item seem to be a little bit out of focus. My idea is to = separate this item into the following two items. (Much of this idea was = already discussed with Geoff and David Culler at the last IETF meeting) =
Kim: First item is Recommendations for 6lowpan Applications = which states and classifies typical 6lowpan applications and possible = protocol requirements and adaptations for each of = them.

Yes, see my previous = comment wrt to the new proposed charter and applicability = statements.

=C2=A0
=
Kim: Second item is 6lowpan Network Architecture which states=C2=A0th= e architecture of the IP over LoWPAN. It states routing protocols (Mesh = under IP, Route over IP, or both of them, scalable routing, or other = candidate routing protocols), commissioning, bootstrapping, ND, reliable = and efficient delivery of packets (or fragments), configuration, = discovery of networks and services), and=C2=A0mobility = support.

Absolutely: Geoff, David = and I started such as ID. Should be posted right after this IETF with = welcome comments.

=
=C2=A0
=C2=A0
>
> Charter = 4/5
>
> Produce "6lowpan Mesh Routing" to evaluate = different
> mesh routing protocols for use within 6lowpans. While = most
> routing protocols are defined above the IP layer, 6lowpan =
> requires a mesh routing protocol below the IP layer. = "6lowpan
> Mesh Routing" may be several proposed standard
> = documents.

Something to discuss with RSN so that we have a clear = understanding of
the goals of MAC vs. IP routing, whether we need to = do both or not, how
much of the mechanism could be shared if we do = need both, etc.

I can't agree more ! See = the email that I just sent out.

=
=C2=A0
Kim: I think we need=C2=A0routing protocols = underneath IP, regardless of the efforts at RSN (I agree with JP and = David that it is valuable to=C2=A0try to find possible routing protocols = for sensor networks especially over IP).

Good, although I'm still = questioning why we need mesh-under routing. But times will come when we = should have that discussion.

=
This is because we will have lots of 6lowpan fragments of IP = packets (of course depending on the applications and packet size). The = fragments should anyway be routed underneath IP because the fragments = can not be seen above IP.

Not sure of what you mean = by "routing fragment underneath IP" ??

Mesh routing protocol=C2=A0is one of the candidates, = and a scalable routing protocol could be an alternate choice especially = when lots of 6lowpan nodes are to be deployed in a network, in that a = routing protocol based on the routing table on sensor nodes might incur = too much overhead to manage routing table = updates.

Well this has to be = demonstrated.

Thanks.

JP.



>
> Charter = 5/5
>
> Produce "6lowpan Security Analysis" to define the = threat
> model of 6lowpans and to document suitability of = existing
> key management schemes and to discuss
> = bootstrapping/installation/commissioning/setup issues. This
> = document will be an informational document.

Yes, and we will want = to appoint a security adviser unless we already
have an expert in the = group.

These Charter items, with some cleanup and tightening, = seem like a
reasonable start to me. I'd like to know what others in = the group
believe, and if we have editors and energy lined up for the = tasks.
=C2=A0
Kim: Overall, I hope we could start = off the works on PS as well as the informational documents.
=
The routing protocol could be one of them. Indeed, the market is = waiting for the 6lowpan products.
We spent two and half = years for making one PS document. That is just=C2=A0start of the actual = impact on the market.
We need to do some work at least = routing protocols ASAP while=C2=A0starting off the sensor-op testing = (sensor network version of interop).

Thanks,

- = Mark
>


_______________________________________________ =
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.= org/mailman/listinfo/6lowpan
=C2=A0


=
--
Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, = =EF=A4=8A=E8=B5=B7=E4=BA=A8)
Associate Professor
Division of = Information and Computer Eng., Ajou University, Suwon, Korea = 442-749
Tel: +82-31-219-2433, Cel: +82-17-760-2551,=C2=A0=C2=A0Fax: = +82-31-219-2433 = http://www.6lowpan.org
6lowpan mailing list
=

= --Apple-Mail-73-249163325-- --===============1846799789== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1846799789==-- From 6lowpan-bounces@ietf.org Tue Jul 17 19:28:25 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAwSv-0004Md-If; Tue, 17 Jul 2007 19:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAwSu-0004MP-6l for 6lowpan@lists.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-0002w1-FC for 6lowpan@lists.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: [6lowpan] Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1629644579==" Errors-To: 6lowpan-bounces@ietf.org --===============1629644579== 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-- --===============1629644579== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1629644579==-- From 6lowpan-bounces@ietf.org Tue Jul 17 19:44:25 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAwiO-0004dD-AH; Tue, 17 Jul 2007 19:44:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAwiN-0004cZ-10 for 6lowpan@lists.ietf.org; Tue, 17 Jul 2007 19:44:23 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAwiL-0003FL-Gu for 6lowpan@lists.ietf.org; Tue, 17 Jul 2007 19:44:23 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Jul 2007 19:44:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAB/xnEZAZnmf/2dsb2JhbACCYg X-IronPort-AV: i="4.16,547,1175486400"; d="scan'208,217"; a="65444485:sNHT59746112" 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 l6HNiKxO006344; Tue, 17 Jul 2007 19:44:20 -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 l6HNiIEZ001069; Tue, 17 Jul 2007 23:44:20 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); Tue, 17 Jul 2007 19:44:18 -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:44:16 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <77B7A8B3-D73C-4F5F-814D-4CEC5F5D37E4@cisco.com> From: JP Vasseur Date: Tue, 17 Jul 2007 19:43:42 -0400 To: Eunsook Eunah Kim , nicolas.chevrollier@tno.nl, dominik.ietf@gmail.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Jul 2007 23:44:16.0885 (UTC) FILETIME=[63569250:01C7C8CC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23577; t=1184715860; x=1185579860; 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=20I-D=20ACTION=3Adraft-ekim-6lowpan-scenarios-00.txt=20 |Sender:=20 |To:=20Eunsook=20Eunah=20Kim=20, =20nicolas.chevroll ier@tno.nl,=0A=20=20=20=20=20=20=20=20dominik.ietf@gmail.com; bh=hOH5g6qo+9mc7B/Pg+7qgCtEqbqZSPG25ntYdPoILxg=; b=aFFOp+eICGQ4pr6SUdV9+ztR1kj2w1ZNIRax5DdB9aZPm2nF9tY1U6s0pYnqDh8gK3LhLs3A ODIzUfkpCKPV0mw68J8YJu76eDpJpREqrMrTMP/s0ZkB3LvRzhxXuv5b; 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: ea36de7a5e28e9b4461c8d685f4e97f1 Cc: 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] Re: I-D ACTION:draft-ekim-6lowpan-scenarios-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0862777905==" Errors-To: 6lowpan-bounces@ietf.org --===============0862777905== Content-Type: multipart/alternative; boundary=Apple-Mail-79-250192590 --Apple-Mail-79-250192590 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, First of all, great idea to write such draft !! This is exactly along the lines of what I was proposing to add to the charter (Applicability statement) in a previous email recently sent to the list. Some Comments: * When describing the problem space I would suggest to explicitly mention that a LoWPAN is made of devices of various nature including Sensors but certainly there are non sensors devices (actuators, ...). * I would suggest to add two bullets in the "Design Space" section: Management (self healing properties) and Security. For each of the example that you provide, I would suggest to add a few dominant parameters: * Required Level of Security * Requirement for Multi-topology routing * Requirement for QoS support * Traffic pattern: P2MP/MP2P or P2P * Structural Monitoring: just mention that the number of nodes may in some cases be on the order on a few hundreds of nodes. I would not say that most of topologies are start topologies (there are many deployment cases where we have true mesh networks). Security level: high MTR: no Support of QoS: no Traffic Pattern: P2MP/MP2P * Agricultural: Security level: high MTR: no Support of QoS: no Traffic Pattern: P2MP/MP2P and P2P * Healthcare: I would suggest to list several applications here: (1) Healthcare at home (with scheduled monitoring and emergency), (2) Hospitals (and again there might be several applications with different level of criticality: at one end of the spectrum the ER (e.g. SMART project) and at the other end of spectrum for object tracking. Security level: high MTR: TBD Support of QoS: yes Traffic Pattern: P2MP/MP2P and P2P * Vehicular: might be good to differentiate car to fix infrastructure (your example) and car to car communication in this case. * I would suggest to add the Industrial (process control, ...) and Connected Home cases. About Section 4: there are of course many other benefits that could be listed but I would certainly suggest to add the fact that we'll see more and more device-to-device communication, in which case two nodes running different proprietary protocols would have to communicate via a protocol translation gateway with all known consequences. Thanks. JP. On Jun 11, 2007, at 3:50 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Design and Application Spaces for 6LoWPANs > Author(s) : E. Kim, et al. > Filename : draft-ekim-6lowpan-scenarios-00.txt > Pages : 16 > Date : 2007-6-11 > > This document investigates potential application scenarios and use > cases for low-power wireless personal area networks (LoWPANs). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ekim-6lowpan- > scenarios-00.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-ekim-6lowpan-scenarios-00.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-ekim-6lowpan-scenarios-00.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-6-11123644.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-79-250192590 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

First of all, great idea to = write such draft !! This is exactly along the lines of what I was = proposing to add to the charter (Applicability statement) in a previous = email recently sent to the list.

Some = Comments:

* When describing the problem = space I would suggest to explicitly mention that a LoWPAN is made of = devices of various nature including Sensors but certainly there are non = sensors devices (actuators, ...).=A0
* I would suggest to add two = bullets in the "Design Space" section: Management (self healing = properties) and Security.

For each of the example that = you provide, I would suggest to add a few dominant = parameters:
*=A0Required Level of Security
* Requirement for = Multi-topology routing
* Requirement for QoS support =
* Traffic pattern: P2MP/MP2P or = P2P

*=A0Structural Monitoring: = just mention that the number of nodes may in some cases be on the order = on a few hundreds of nodes. I would not say that most of topologies are = start topologies (there are many deployment cases where we have true = mesh networks).
Security level: high
MTR: no
Support of QoS: = no
Traffic Pattern: P2MP/MP2P

* = Agricultural:=A0
=A0 =A0 =A0=A0 =A0Security level: = high
MTR: no
Support of QoS: no
=A0 =A0 =A0=A0 =A0Traffic = Pattern: P2MP/MP2P and P2P

* Healthcare: I would suggest = to list several applications here: (1) Healthcare at home (with = scheduled monitoring and emergency), (2) Hospitals (and again there = might be several applications with different level of criticality: at = one end of the spectrum the ER (e.g. SMART project) and at the other end = of spectrum for object tracking.
=A0 =A0 =A0=A0 =A0Security = level: high
MTR: TBD
Support of QoS: yes
=A0 =A0 =A0=A0 =A0Traffic = Pattern: P2MP/MP2P and P2P

* Vehicular: might be good to = differentiate car to fix infrastructure (your example) and car to car = communication in this case.

* I would suggest to add the = Industrial (process control, ...) and Connected Home = cases.

About Section 4: there are of = course many other benefits that could be listed but I would certainly = suggest to add the fact that we'll see more and more device-to-device = communication, in which case two nodes running different proprietary = protocols would have to communicate via a protocol translation gateway = with all known consequences.

Thanks.

JP.

On Jun 11, 2007, at = 3:50 PM, Internet-Drafts@ietf.org = wrote:

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


= Title = = : Design and Application Spaces for 6LoWPANs
Author(s) : E. Kim, = et al.
Filename : = draft-ekim-6lowpan-scenarios-00.txt
= Pages = = : 16
Date : 2007-6-11

=A0=A0 This document investigates = potential application scenarios and use
=A0=A0 cases for low-power = wireless personal area networks (LoWPANs).


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-ekim-6lowpan-scenarios-00.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-ekim-6lowpan-scenarios-00.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-79-250192590-- --===============0862777905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0862777905==-- From 6lowpan-bounces@ietf.org Tue Jul 17 20:20:05 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAxGu-0006tQ-Dp; Tue, 17 Jul 2007 20:20:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAxGs-0006tF-Ff for 6lowpan@ietf.org; Tue, 17 Jul 2007 20:20:02 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAxGq-0004SV-VF for 6lowpan@ietf.org; Tue, 17 Jul 2007 20:20:02 -0400 Received: from [127.0.0.1] (x101-213-4.wireless.umn.edu [128.101.213.4]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l6I0JiZO054956 for <6lowpan@ietf.org>; Tue, 17 Jul 2007 19:19:56 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <469D5C99.1000501@saloits.com> Date: Tue, 17 Jul 2007 19:19:37 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: 6lowpan@ietf.org Subject: Re: [6lowpan] Soliciting input on Interop draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org David Culler wrote: > We'd like to get feedback on I- D > > http://www.ietf.org/internet-drafts/draft-hui-6lowpan-interop-00.txt > > > submitted July 6. This provides thoughts on the first phases of > interoperability testing. The scheme developed there would generalize > to cover the rest of the 6LoWPAN. Should the document, perhaps, refer to "interoperability test requirements", rather than "interoperability requirements"? Is the intent of this document to describe interoperability [test] requirements that cover all of the 6lowpan format document? (I strongly hope so.) More than the 6lowpan format document? I strongly prefer a smaller number of interoperability [test] requirement documents, rather than a larger number. Will there be a document that identifies, with more or less detail, test cases? Or, will this document serve this purpose? Or, do we expect that individual test cases can be trivially derived from this document? I believe that it would be very valuable to include a chart that lists all of the functionality specified in the 6lowpan format document. This chart should identify which interoperability [test] requirements are applicable to which format document functionality. This chart, while tedious to produce, will help those who review this document, those who conduct the tests, and those who review the test results to have confidence in the test coverage covered by the interoperability tests (test cases) specified in the document. (I believe that the tedium of creating this chart should be experienced by the authors of the document, rather than by the reviewers and readers of the document. Sorry about that guys. Well, sort of...) I believe that this document should: o Cover all of the functionality specified in the format document. o Include tests between a 6lowpan device and an IPv6 host; in fact perhaps _all_ tests should be conducted both between two 6lowpan devices and between a 6lowpan device and an IPv6 host. o Include tests between a 6lowpan device and an IPv4 host. -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 18 03:44:23 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4Cq-0001c4-Et; Wed, 18 Jul 2007 03:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4Co-0001bl-OU for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 03:44:18 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB4Cn-0006u9-RR for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 03:44:18 -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: -4.0 (----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 18 04:03:06 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4Uz-00039F-IN; Wed, 18 Jul 2007 04:03:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4Uw-00030C-Bv for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 04:03:03 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB4Uv-0007Zo-8l for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 04:03:02 -0400 Received: by nz-out-0506.google.com with SMTP id i28so94736nzi for <6lowpan@lists.ietf.org>; Wed, 18 Jul 2007 01:03:00 -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: [6lowpan] Re: Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 18 04:54:04 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5IJ-0000oJ-JJ; Wed, 18 Jul 2007 04:54:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5IH-0000nG-JL for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 04:54:02 -0400 Received: from hu-out-0506.google.com ([72.14.214.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB5IG-00018m-VM for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 04:54:01 -0400 Received: by hu-out-0506.google.com with SMTP id 32so152527huf for <6lowpan@lists.ietf.org>; Wed, 18 Jul 2007 01:54:00 -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=kIh1z9Ewi+UeyjmIUXQWs5tAyXeyzlKPi6sswvtjefu3AjLTfbyg4iUDk416+5oLVmI1hiMcFgKLeirkCWfJWMFwCNajnu4UJYltUwyUQuAbYusNHZy7DWnDXEGaXfX/YaU8otKcK9ZTIkLW+GMcr4TFgB4x84e2ayfASezXwmc= 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=muNT57mPjziA74ehbhsnAJNlTENQR2dINNjTX43FcQkvEhqgOsgW5SgkstDGFQ4XrR7WI9+Qa7hrSyRaKTCQtbzQsmnwMFnTKs23AWxPhsbyEQeCSCXz5yZhr/u9+XzHmrv4WRarmzzIAP0Yk60EXn3bFBdvgBCYOHWKY3t8nVY= Received: by 10.66.243.2 with SMTP id q2mr176842ugh.1184748838762; Wed, 18 Jul 2007 01:53:58 -0700 (PDT) Received: by 10.142.108.5 with HTTP; Wed, 18 Jul 2007 01:53:58 -0700 (PDT) Message-ID: <77f1dba80707180153l5710d7f0r9c7ce1193852b3dd@mail.gmail.com> Date: Wed, 18 Jul 2007 17:53:58 +0900 From: "Eunsook \"Eunah\" Kim" To: "JP Vasseur" In-Reply-To: <77B7A8B3-D73C-4F5F-814D-4CEC5F5D37E4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77B7A8B3-D73C-4F5F-814D-4CEC5F5D37E4@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: 6lowpan <6lowpan@lists.ietf.org>, dominik.ietf@gmail.com Subject: [6lowpan] Re: I-D ACTION:draft-ekim-6lowpan-scenarios-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi JP, Thanks for your support on this draft and your valuable comments. I will add your comments in the next version. Some answers are inline. :) Thanks, -eunsook On 7/18/07, JP Vasseur wrote: > Hi, > > First of all, great idea to write such draft !! This is exactly along the > lines of what I was proposing to add to the charter (Applicability > statement) in a previous email recently sent to the list. > > Some Comments: > > * When describing the problem space I would suggest to explicitly mention > that a LoWPAN is made of devices of various nature including Sensors but > certainly there are non sensors devices (actuators, ...). Good point. It will be added in the next version. > * I would suggest to add two bullets in the "Design Space" section: > Management (self healing properties) and Security. > Good suggestion. It would be good that you can contribute on this part if you have something already in your mind. :-) > For each of the example that you provide, I would suggest to add a few > dominant parameters: > * Required Level of Security > * Requirement for Multi-topology routing > * Requirement for QoS support > * Traffic pattern: P2MP/MP2P or P2P > > * Structural Monitoring: just mention that the number of nodes may in some > cases be on the order on a few hundreds of nodes. I would not say that most > of topologies are start topologies (there are many deployment cases where we > have true mesh networks). Yes, it won't be only with star topologies. We want to mention an example to have very simple star or two or three tiers of hierarchical star topologies (different from hierarchical tree which is one of mesh). > Security level: high > MTR: no > Support of QoS: no > Traffic Pattern: P2MP/MP2P > Thanks. I will add it. > * Agricultural: > Security level: high > MTR: no > Support of QoS: no > Traffic Pattern: P2MP/MP2P and P2P > OK. :) > * Healthcare: I would suggest to list several applications here: (1) > Healthcare at home (with scheduled monitoring and emergency), (2) Hospitals > (and again there might be several applications with different level of > criticality: at one end of the spectrum the ER (e.g. SMART project) and at > the other end of spectrum for object tracking. > Security level: high > MTR: TBD > Support of QoS: yes > Traffic Pattern: P2MP/MP2P and P2P > Thanks. We will add it to the next version. > * Vehicular: might be good to differentiate car to fix infrastructure (your > example) and car to car communication in this case. > Right. As this is an initial version, we add only car to fix infrastructure, but later car to car communication can be studied and added later. :) > * I would suggest to add the Industrial (process control, ...) and Connected > Home cases. > > About Section 4: there are of course many other benefits that could be > listed but I would certainly suggest to add the fact that we'll see more and > more device-to-device communication, in which case two nodes running > different proprietary protocols would have to communicate via a protocol > translation gateway with all known consequences. > right. :) > Thanks. > > JP. > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 18 04:56:14 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5KQ-0003dz-HX; Wed, 18 Jul 2007 04:56:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5KP-0003dV-I0 for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 04:56:13 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB5KP-0001Cu-7w for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 04:56:13 -0400 Received: by nz-out-0506.google.com with SMTP id i28so106477nzi for <6lowpan@lists.ietf.org>; Wed, 18 Jul 2007 01:56:13 -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: [6lowpan] Soliciting comments on 'draft-oh-6lowpan-packetbb-dymoapp-00' X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 18 10:53:32 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAu9-0000Bn-LR; 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-0000BW-OU for 6lowpan@lists.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-0003Ex-FC for 6lowpan@lists.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 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 Subject: [6lowpan] Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 18 12:24:13 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCJw-0006d8-Tj; Wed, 18 Jul 2007 12:24:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCJt-0006cq-Vs for 6lowpan@lists.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-0005ux-G0 for 6lowpan@lists.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: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 18 12:25:24 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCL6-0007Dz-Uo; Wed, 18 Jul 2007 12:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCL5-0007Do-Nw for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 12:25:23 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBCL4-0005wr-4x for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 12:25:23 -0400 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l6IGPCUg009116; Wed, 18 Jul 2007 10:25:12 -0600 (MDT) From: Geoff Mulligan To: Mark Townsley In-Reply-To: <469E295A.9020209@cisco.com> References: <20070718135323.587AA1DDC3B9@secure.archedrock.com> <469E295A.9020209@cisco.com> Content-Type: text/plain Date: Wed, 18 Jul 2007 10:25:14 -0600 Message-Id: <1184775914.28557.20.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: '6lowpan' <6lowpan@lists.ietf.org>, rsn@ietf.org, dculler@archrock.com Subject: [6lowpan] Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org It might look similar to 802.11s, but right now there is nothing defined for 802.15.4 like 802.11s. There is an 802.15.5 group working on this and it's solution may be just the "mesh under" soltion 6lowpan needs. I'm not at all sure about how TRILL would or could fit. geoff On Wed, 2007-07-18 at 16:53 +0200, Mark Townsley wrote: > 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 18 14:03:45 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDsH-0000zl-7i; Wed, 18 Jul 2007 14:03:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDsF-0000zc-PK for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 14:03:43 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBDsE-0000L9-Ax for 6lowpan@lists.ietf.org; Wed, 18 Jul 2007 14:03:43 -0400 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l6II3QOj009562; Wed, 18 Jul 2007 12:03:26 -0600 (MDT) From: Geoff Mulligan To: dculler@archrock.com In-Reply-To: <20070718135323.587AA1DDC3B9@secure.archedrock.com> References: <20070718135323.587AA1DDC3B9@secure.archedrock.com> Content-Type: text/plain Date: Wed, 18 Jul 2007 12:03:29 -0600 Message-Id: <1184781809.28557.35.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: '6lowpan' <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [6lowpan] RE: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Very interesting and provocative question you pose at the end of your message - "do we need mesh under?" I think and hope that this will generate some discussion on the list. I suspect that there are people on the list that will argue that mesh under is fact (it is deployed today) and that of course we need mesh under and will use standard layer 3 routing between 6lowpan subnets. Currently this is the thinking within SP100 for industrial wireless. 802.15.5 is certainly looking at and, I think, plans to standardize on a two different mesh under designs/protocols. Utilizing trill is an interesting thought. I don't yet know enough about trill to comment on it's applicability. Certainly the manet protocols might be applicable. What is critical to this discussion is that if 6lowpan does not select or generate a mesh under protocol (if one is necessary and used) then there will not be interoperability between multi-hoping nodes. If mesh-under is not used (but router over is used for multi-hopping) then all 6lowpan nodes can exchange packets and forward packets (but we need to understand the implications of one node per subnet). geoff On Wed, 2007-07-18 at 06:53 -0700, dculler wrote: > The argument for route-over is pretty simple. > > 1. In the vast majority of wireless sensor networks in existance the > dominant communication pattern is data collection (from nodes in the > PAN to IP-based computers external to the PAN) and control actions > (from controllers external to the PAN to devices within the PAN). > There are cases where data collection point and/or the controller is a > gateway device on the PAN, but this physical collocation is rather > artificial. If is far more typical that where a gateway is deployed > it is used to bridge communication to other networks. > > This is true not only for wireless instrumentation, but wired > instrumentation as well. See for example > > BACNET: http://www.bacnet.org/Tutorial/HMN-Overview/sld028.htm and > http://www.bacnet.org/Tutorial/HMN-Overview/sld029.htm > > and > > HART: > http://www.hartcomm2.org/hart_protocol/tech_info/eval_networks/compnet.html > > and Wireless HART > > http://www.hartcomm2.org/hart_protocol/wireless_hart/architecture.html > > Routing onto or off the PAN utilizes a routable IP address for the > device within the PAN. It is important for this address to be > compressible, just as when both endpoints are within the PAN. No > matter how effective is the L2 mesh routing within the PAN, you still > need to deal with IP routing off the PAN. This is, of course, the > purpose of IP routing. Whatever mesh-under is done, there will also > be route-over. The mesh-under path is, at least, one of the > route-over hops. Possibly more of the IP hops may occur over 802.15.4 > links. > > 2. It is very common that devices route between distinct networks that > use the same media, ie. distinct Ethernet subnets or distinct WiFi > subnets. This will happen in 802.15.4 networks where the networks use > the same physical link, but different PAN_IDs, different channels (or > different sets of channels or different channel schedules), different > MAC layers, etc. Even different meshing protocols. They will be > stiched together by IP routing. > > 3. The Mesh-under protocol is currently undefined. 6lowpan is > sufficient to describe single hop communication. It also identifies > the endpoints (original and final) of multihop mesh-routed > communication, but it does not define how the intervening hops are > determined or what information is exchanged to establish > routes. Clearly it anticipates that such L2 protocols will be > developed and standardized. However, if a single 802.15.4 hop is > performed per IP hop, any L3 routing algorithm can be used to set up > the routing tables and forwarding occurs according to the routing > tables. (Worst come to worst, you can hammer the tables in place by > external means.) If mesh routing does become defined, IP routing can > be applied per L2 mesh path. Thus, IP routing applies whether or not > mesh routing is defined. All of the IP visibility and management > tools apply to the IP hops. None of them apply to the mesh hops > within an IP hop. > > 4. Many IP routing protocols are defined and a diversity of protocols > has become the norm. One of the key elements of IP is that it > separates routing from forwarding. We tolerate the use of different > routing protocols in different settings. These protocols set up the > tables and forwarding works across them. We have had multiple > competing routing protocols apply to the same setting (e.g., RIP vs > OSPF in the campus area) and their relative strengths have become > clear over time. > > This has not been the case with link-level "meshing"; so far it has > been approached as a winner-take-all and unfortunately this means that > everybody must agree on the protocol before they have much experience > with the use of the protocol. For example, in Zigbee we have seen > that after several years of development, but no broad usage, Zigbee > 1.0 is obsoleted in favor of Zigbee 2006, which is incompatible and > also incompatible with Zigbee 2007, which is not yet fully defined. > We have seen numerous proprietary protocols, proprietary extensions to > standard protocols, and open research protocols for meshing that are > all incompatible. In some cases they optimize for different aspects, > in some cases they integrate aspects of all layers of the stack. In > any case, they don't play well together. So, one of the key virtues of > route-over is that we have an established framework and long history > of stiching together a variety of routing protocols to establish the > tables such that forwarding works across them and where we can gain > experience over time. Call it "rough consensus and running code". > > One might argue these aspects are sociological, rather than technical. > Well, the separation of topology formation, path selection, and route > table maintainance from forwarding is awfully important. So are the > vast set of tools to gain visibility into IP routing. At the very > least, source routing, exploration, etc. will need to be developed for > the PAN for mesh-under to mature. It is an interesting question > whether you need to be within the PAN to utilize the equivalent of > traceroute. > > 5. History suggests that once IP routing is available for a particular > kind of link, sub-IP routing tends to dissappear. Remember x.25 and > frame relay. Of course, we do some form of "mesh" routing in switched > ethernets and mesh wifi, but generally it is transparent. The link > looks like the unswitched counterpart. > > So I think it is very clear that IP routing will occur over IEEE > 802.15.4 links. It is already there. For every single hop 15.4 > network it is done. For deeper networks, there are many ways to set > up the tables. > > So route-over is a fact. The question should be "Do you need > mesh-under in addition to route-over?" Why? > > > > ______________________________________________________________ > From: JP Vasseur [mailto: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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 19 05:25:05 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSFr-00024O-Rt; Thu, 19 Jul 2007 05:25:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSFq-0001wM-HQ for 6lowpan@lists.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-0007qk-T4 for 6lowpan@lists.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: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 20 05:41:05 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBoys-0000ch-GW; Fri, 20 Jul 2007 05:41:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBoyr-0000cV-Ib for 6lowpan@lists.ietf.org; Fri, 20 Jul 2007 05:41:01 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBoyp-0002L2-Tp for 6lowpan@lists.ietf.org; Fri, 20 Jul 2007 05:41:01 -0400 Received: by nz-out-0506.google.com with SMTP id i28so718682nzi for <6lowpan@lists.ietf.org>; 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 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 Subject: [6lowpan] Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 20 12:51:08 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvh2-0003ll-No; Fri, 20 Jul 2007 12:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvh2-0003lY-7h for 6lowpan@lists.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 ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBvh1-0002yw-HN for 6lowpan@lists.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 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, dculler@archrock.com Subject: [6lowpan] Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 20 16:59:43 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBzZc-0005gW-Hb; Fri, 20 Jul 2007 16:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBzZa-0005fS-K9 for 6lowpan@lists.ietf.org; Fri, 20 Jul 2007 16:59:38 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBzZZ-00081w-3u for 6lowpan@lists.ietf.org; Fri, 20 Jul 2007 16:59:38 -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: [6lowpan] Link-Local versus Network Routing at IETF-69 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 20 17:30:14 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC03B-0004st-QN; Fri, 20 Jul 2007 17:30:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC039-0004sg-Pw for 6lowpan@lists.ietf.org; Fri, 20 Jul 2007 17:30:11 -0400 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IC039-00007m-33 for 6lowpan@lists.ietf.org; Fri, 20 Jul 2007 17:30:11 -0400 X-AuditID: c0a8013c-aaebbbb000003048-10-46a129617a94 Received: from [172.17.167.32] (unknown [207.236.7.194]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id C7B5D4DC002; Fri, 20 Jul 2007 15:30:08 -0600 (MDT) In-Reply-To: <77f1dba80707180153l5710d7f0r9c7ce1193852b3dd@mail.gmail.com> References: <77B7A8B3-D73C-4F5F-814D-4CEC5F5D37E4@cisco.com> <77f1dba80707180153l5710d7f0r9c7ce1193852b3dd@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 Date: Fri, 20 Jul 2007 17:12:11 -0400 To: Eunsook "Eunah" Kim X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: 6lowpan <6lowpan@lists.ietf.org>, dominik.ietf@gmail.com Subject: [6lowpan] Re: I-D ACTION:draft-ekim-6lowpan-scenarios-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi, On Jul 18, 2007, at 4:53 AM, Eunsook Eunah Kim wrote: > Hi JP, > > Thanks for your support on this draft and your valuable comments. > I will add your comments in the next version. > Some answers are inline. :) > > Thanks, > > -eunsook > > On 7/18/07, JP Vasseur wrote: >> Hi, >> >> First of all, great idea to write such draft !! This is exactly >> along the >> lines of what I was proposing to add to the charter (Applicability >> statement) in a previous email recently sent to the list. >> >> Some Comments: >> >> * When describing the problem space I would suggest to explicitly >> mention >> that a LoWPAN is made of devices of various nature including >> Sensors but >> certainly there are non sensors devices (actuators, ...). > > Good point. It will be added in the next version. > >> * I would suggest to add two bullets in the "Design Space" section: >> Management (self healing properties) and Security. >> > > Good suggestion. It would be good that you can contribute on this part > if you have something already in your mind. :-) > Surely, let's talk next week. >> For each of the example that you provide, I would suggest to add a >> few >> dominant parameters: >> * Required Level of Security >> * Requirement for Multi-topology routing >> * Requirement for QoS support >> * Traffic pattern: P2MP/MP2P or P2P >> >> * Structural Monitoring: just mention that the number of nodes may >> in some >> cases be on the order on a few hundreds of nodes. I would not say >> that most >> of topologies are start topologies (there are many deployment >> cases where we >> have true mesh networks). > > Yes, it won't be only with star topologies. We want to mention an > example to have very simple star or two or three tiers of hierarchical > star topologies (different from hierarchical tree which is one of > mesh). > >> Security level: high >> MTR: no >> Support of QoS: no >> Traffic Pattern: P2MP/MP2P >> > Thanks. I will add it. > >> * Agricultural: >> Security level: high >> MTR: no >> Support of QoS: no >> Traffic Pattern: P2MP/MP2P and P2P >> > OK. :) > >> * Healthcare: I would suggest to list several applications here: (1) >> Healthcare at home (with scheduled monitoring and emergency), (2) >> Hospitals >> (and again there might be several applications with different >> level of >> criticality: at one end of the spectrum the ER (e.g. SMART >> project) and at >> the other end of spectrum for object tracking. >> Security level: high >> MTR: TBD >> Support of QoS: yes >> Traffic Pattern: P2MP/MP2P and P2P >> > > Thanks. We will add it to the next version. > >> * Vehicular: might be good to differentiate car to fix >> infrastructure (your >> example) and car to car communication in this case. >> > Right. As this is an initial version, we add only car to fix > infrastructure, but later car to car communication can be studied and > added later. :) OK > >> * I would suggest to add the Industrial (process control, ...) and >> Connected >> Home cases. >> >> About Section 4: there are of course many other benefits that >> could be >> listed but I would certainly suggest to add the fact that we'll >> see more and >> more device-to-device communication, in which case two nodes running >> different proprietary protocols would have to communicate via a >> protocol >> translation gateway with all known consequences. >> > > right. :) > Great, cheers. JP. >> Thanks. >> >> JP. >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 20 21:36:45 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC3th-0005ZR-KV; Fri, 20 Jul 2007 21:36:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC3tg-0005WT-DC for 6lowpan@lists.ietf.org; Fri, 20 Jul 2007 21:36:40 -0400 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IC3tf-0004Nf-54 for 6lowpan@lists.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: [6lowpan] Re: Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 20 21:46:03 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC42l-0003a9-JE; Fri, 20 Jul 2007 21:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC42k-0003X9-1T for 6lowpan@lists.ietf.org; Fri, 20 Jul 2007 21:46:02 -0400 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IC42i-0004ZI-21 for 6lowpan@lists.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 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 Subject: [6lowpan] Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0804979771==" Errors-To: 6lowpan-bounces@ietf.org --===============0804979771== 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-- --===============0804979771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0804979771==-- From 6lowpan-bounces@ietf.org Fri Jul 20 21:54:54 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC4BJ-0001rf-U9; 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-0001rN-F0 for 6lowpan@lists.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-0004h6-JJ for 6lowpan@lists.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 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 Subject: [6lowpan] Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 20 22:02:23 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC4IZ-0007yI-IP; 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-0007y0-O7 for 6lowpan@lists.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-0004nL-5K for 6lowpan@lists.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 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 Subject: [6lowpan] Re: [RSN] Link-Local versus Network Routing at IETF-69 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Jul 22 17:09:25 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICig5-0008Uq-Rf; Sun, 22 Jul 2007 17:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICig4-0008Ul-L5 for 6lowpan@lists.ietf.org; Sun, 22 Jul 2007 17:09:20 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICig3-0004z7-6E for 6lowpan@lists.ietf.org; Sun, 22 Jul 2007 17:09:20 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EAD286279 for <6lowpan@lists.ietf.org>; Sun, 22 Jul 2007 23:09:18 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07711-09 for <6lowpan@lists.ietf.org>; Sun, 22 Jul 2007 23:09:14 +0200 (CEST) Received: from [10.70.11.175] (twoflower.eecsgradlab.iu-bremen.de [10.70.11.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTP id 417B08655B for <6lowpan@lists.ietf.org>; Sun, 22 Jul 2007 23:09:14 +0200 (CEST) Message-ID: <46A3C779.9000600@jacobs-university.de> Date: Sun, 22 Jul 2007 23:09:13 +0200 From: Matus Harvan User-Agent: Thunderbird 1.5.0.10 (X11/20070319) MIME-Version: 1.0 To: 6lowpan@lists.ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [6lowpan] ping6 our motes X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, two telosb motes with the 6lowpan implementation from Jacobs University now have routable, public IPv6 addresses, resolvable as 6lowpan-mote-14.eecs.jacobs-university.de 6lowpan-mote-18.eecs.jacobs-university.de The motes can be pinged and have a simple cli on UDP port 1234. Usage: ping6 6lowpan-mote-14.eecs.jacobs-university.de nc -6 -u 6lowpan-mote-14.eecs.jacobs-university.de 1234 The cli has built-in help. Matus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGo8d543LQWDWf0QIRAoKbAKClgJ5r1GqXQEk5Neb5uMETQxTiaQCffvu2 Q79YZdDn0B5ctG8cwx0jAyQ= =gMyZ -----END PGP SIGNATURE----- _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 24 13:43:40 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOQ2-0004lR-Ci; Tue, 24 Jul 2007 13:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOQ0-0004cl-QP for 6lowpan@ietf.org; Tue, 24 Jul 2007 13:43:32 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDOPy-0006vm-Qz for 6lowpan@ietf.org; Tue, 24 Jul 2007 13:43:32 -0400 Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id l6OHhSjH008441 for <6lowpan@ietf.org>; Tue, 24 Jul 2007 19:43:28 +0200 (CEST) Received: from [130.129.86.108] (unknown [130.129.86.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 387015D5D; Tue, 24 Jul 2007 19:43:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0AE789C6-4D1D-443E-BA70-BAFAF075D31D@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Tue, 24 Jul 2007 12:43:16 -0500 To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Carsten Bormann Subject: [6lowpan] Results of the Chicago meeting (IETF 69) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Lowpanners, I put a quick paragraph on the results of today's meeting at the 6lowpan wiki, http://6lowpan.tzi.org -- more information (and the official minutes) to follow. You may take the occasion to register a username on this Wiki as the work on the Architecture Document will commence there, and getting an account will allow you to contribute (those who already have an account don't need to do anything additional). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 26 07:38:37 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1fu-000133-Bu; Thu, 26 Jul 2007 07:38:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1ft-00012x-Ay for 6lowpan@lists.ietf.org; Thu, 26 Jul 2007 07:38:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE1fs-00030g-2M for 6lowpan@lists.ietf.org; Thu, 26 Jul 2007 07:38:33 -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: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org, manemo@mobileip.jp, "Bound, Jim" Subject: [6lowpan] RE: [Manemo] MANEMO is not just about Nested Nemo X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-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_____________________________________________________________ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 30 08:24:55 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUIw-00045E-3v; Mon, 30 Jul 2007 08:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUIu-00044g-SR for 6lowpan@ietf.org; Mon, 30 Jul 2007 08:24:52 -0400 Received: from mv-osn-hcb002.ocn.ad.jp ([60.37.51.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFUIt-0004eW-68 for 6lowpan@ietf.org; Mon, 30 Jul 2007 08:24:52 -0400 Received: from vcpure.ocn.ne.jp (mv-osn-hcb002 [60.37.51.7]) by mv-osn-hcb002.ocn.ad.jp (Postfix) with ESMTP id F0EB93401B for <6lowpan@ietf.org>; Mon, 30 Jul 2007 21:24:48 +0900 (JST) Received: from dell4500c (p6053-ipad103fukuokachu.fukuoka.ocn.ne.jp [60.38.234.53]) by vcpure.ocn.ne.jp (Postfix) with SMTP for <6lowpan@ietf.org>; Mon, 30 Jul 2007 21:24:48 +0900 (JST) Message-ID: <000a01c7d2a4$a08af800$0200a8c0@dell4500c> From: =?iso-2022-jp?B?GyRCJSohPCVKITwbKEI=?= To: <6lowpan@ietf.org> Date: Mon, 30 Jul 2007 21:24:50 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [6lowpan] (no subject) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0771367351==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0771367351== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7D2F0.0FE13570" This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7D2F0.0FE13570 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0007_01C7D2F0.0FE13570 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0007_01C7D2F0.0FE13570-- --===============0771367351== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0771367351==--