From 6lowpan-bounces@ietf.org Mon Jul 03 11:53:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQk7-0006Im-Fa; Mon, 03 Jul 2006 11:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQk5-0006Ih-KS for 6lowpan@lists.ietf.org; Mon, 03 Jul 2006 11:53:45 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQk2-0007AO-Ao for 6lowpan@lists.ietf.org; Mon, 03 Jul 2006 11:53:43 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k63FrXOF003570 for <6lowpan@lists.ietf.org>; Mon, 3 Jul 2006 09:53:33 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Mon, 03 Jul 2006 09:53:49 -0600 Message-Id: <1151942029.22336.7.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [6lowpan] agenda for next week 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 Does anyone have input for the agenda for next week? Items: 1. Problem Statement document - As far as I can recall this document is complete. I remember that we put out a working group last call and had no negative replies. If this is the case, we need to move this document along. 2. Format document - Gabriel has submitted an update to this document. Are we ready for a working group last call on this? We cannot move forward unless we finalize this, as well as the preceeding, document. 3. Items for rechartering - Christian, do you have the list of items that we had proposed as the top items to work on for rechartering? 4. Mesh networking under IP - While we have discussed using the work from the Manet group for this, I'm concerned that there may be some divergent requirements for our two groups, specifically support for "Low Power Mesh Networks", i.e networks that are completely battery powered. I would like to discuss this next week. 5. Presentations for next weeks meeting. 6. How do we get this group moving?????? geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 03 12:41:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRU9-0005Fp-Ok; Mon, 03 Jul 2006 12:41:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRU8-0005B2-Gj for 6lowpan@lists.ietf.org; Mon, 03 Jul 2006 12:41:20 -0400 Received: from maily.danfoss.com ([193.162.34.7] helo=mailx.danfoss.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxRU7-0002zC-Vz for 6lowpan@lists.ietf.org; Mon, 03 Jul 2006 12:41:20 -0400 Received: from DKDN04MX62.dkdn04.danfoss.net ([10.6.2.62]) by mailx.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 18:41:18 +0200 Received: from dkdn01mx21.danfoss.net ([10.12.129.21]) by DKDN04MX62.dkdn04.danfoss.net with InterScan Message Security Suite; Mon, 03 Jul 2006 18:41:18 +0200 Received: from DKDN01MX34.danfoss.net ([10.12.128.14]) by dkdn01mx21.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 18:41:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: SV: [6lowpan] agenda for next week Date: Mon, 3 Jul 2006 18:41:17 +0200 Message-ID: <49A38D2FE2C53946A57916AD6A1F00D7139329@DKDN01MX34.danfoss.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] agenda for next week Thread-Index: AcaeuOi9ZYnzTptwTde63F8jl0ZCCgABZ9v2 References: <1151942029.22336.7.camel@dellx1> From: "Schumacher Christian Peter Pii" To: "Geoff Mulligan" , "6lowpan" <6lowpan@lists.ietf.org> X-OriginalArrivalTime: 03 Jul 2006 16:41:18.0425 (UTC) FILETIME=[8209A490:01C69EBF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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="===============0196931752==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0196931752== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69EBF.81A3660F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69EBF.81A3660F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Geoff. Here is the list of top recharter items, as written in the minutes from = last IETF meeting: PS: proposed standard Inf: Informational document * 6lowpan Bootstrapping (PS) and 6lowpan IPv6 ND optimizations = (PS) * Problem statement stateful header compression (Inf) * Recommendations for 6lowpan applications (Inf) o Transport, app, discovery/configuration/commissioning * 6lowpan mesh routing (n x PS) * 6lowpan security analysis (Inf) A way to get 6lowpan to move forward may be to use a net-conference tool = and schedule monthly calls. I suggest an off-line discussion next week = at the IETF at investigate what the viable options are. We have a system = within Danfoss for net-conferencing (Interwise) which may be useful, but = I'm happy to discuss the alternatives.=20 Regards Christian -----Oprindelig meddelelse----- Fra: Geoff Mulligan [mailto:geoff@mulligan.com] Sendt: ma 7/3/2006 5:53 Til: 6lowpan Emne: [6lowpan] agenda for next week =20 Does anyone have input for the agenda for next week? Items: 1. Problem Statement document - As far as I can recall this document is complete. I remember that we put out a working group last call and had no negative replies. If this is the case, we need to move this document along. 2. Format document - Gabriel has submitted an update to this document. Are we ready for a working group last call on this? We cannot move forward unless we finalize this, as well as the preceeding, document. 3. Items for rechartering - Christian, do you have the list of items that we had proposed as the top items to work on for rechartering? 4. Mesh networking under IP - While we have discussed using the work from the Manet group for this, I'm concerned that there may be some divergent requirements for our two groups, specifically support for "Low Power Mesh Networks", i.e networks that are completely battery powered. I would like to discuss this next week. 5. Presentations for next weeks meeting. 6. How do we get this group moving?????? geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01C69EBF.81A3660F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SV: [6lowpan] agenda for next week

Hi Geoff.

Here is the list of top recharter items, as written in the minutes from = last IETF meeting:

          PS: proposed = standard
          Inf: = Informational document

          * 6lowpan = Bootstrapping (PS) and 6lowpan IPv6 ND optimizations (PS)

          * Problem = statement stateful header compression (Inf)

          * Recommendations = for 6lowpan applications (Inf)

            &= nbsp; o Transport, app, discovery/configuration/commissioning

          * 6lowpan mesh = routing (n x PS)

          * 6lowpan = security analysis (Inf)


A way to get 6lowpan to move forward may be to use a net-conference tool = and schedule monthly calls. I suggest an off-line discussion next week = at the IETF at investigate what the viable options are. We have a system = within Danfoss for net-conferencing (Interwise) which may be useful, but = I'm happy to discuss the alternatives.

Regards
Christian

-----Oprindelig meddelelse-----
Fra: Geoff Mulligan [mailto:geoff@mulligan.com]
Sendt: ma 7/3/2006 5:53
Til: 6lowpan
Emne: [6lowpan] agenda for next week

Does anyone have input for the agenda for next week?

Items:
  1. Problem Statement document - As far as I can recall this = document
is complete. I remember that we put out a working group last call = and
had no negative replies.  If this is the case, we need to move = this
document along.

  2. Format document - Gabriel has submitted an update to this = document.
Are we ready for a working group last call on this?  We cannot = move
forward unless we finalize this, as well as the preceeding, = document.

  3. Items for rechartering - Christian, do you have the list of = items
that we had proposed as the top items to work on for rechartering?

  4. Mesh networking under IP - While we have discussed using the = work
from the Manet group for this, I'm concerned that there may be some
divergent requirements for our two groups, specifically support for = "Low
Power Mesh Networks", i.e networks that are completely battery = powered.
I would like to discuss this next week.

  5. Presentations for next weeks meeting.

  6. How do we get this group moving??????



        geoff




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

------_=_NextPart_001_01C69EBF.81A3660F-- --===============0196931752== 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 --===============0196931752==-- From 6lowpan-bounces@ietf.org Tue Jul 04 12:06:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnPY-0001YS-UF; Tue, 04 Jul 2006 12:06:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnPX-0001YN-HY for 6lowpan@ietf.org; Tue, 04 Jul 2006 12:06:03 -0400 Received: from mail2.iabg.de ([62.245.167.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxnPV-0008ML-Cg for 6lowpan@ietf.org; Tue, 04 Jul 2006 12:06:02 -0400 Received: from mail2.iabg.de (localhost [127.0.0.1]) by localhost.iabg.de (Mailserver2 IABG) with ESMTP id 3669E1125; Tue, 4 Jul 2006 18:05:54 +0200 (CEST) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail2.iabg.de (Mailserver2 IABG) with ESMTP id 2252BB79; Tue, 4 Jul 2006 18:05:54 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [6lowpan] 6lowpan-nd version 2 Date: Tue, 4 Jul 2006 18:05:56 +0200 Message-ID: In-Reply-To: <43b91d370606241630n52d25c58jb3fb784e364a416e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan-nd version 2 Thread-Index: AcaX5jE8tokziHbZRlSIeFu3mi0yTwHeIKkw From: "Mayer Karl" To: "Samita Chakrabarti" , <6lowpan@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Hi Samita, A few comments and questions about your new version. - page 4, chapter 3 point 2 you state Neighbor Solicitation but it = should be a Router Solicitation, right? - page 6, chapter 4: you state "The IPv6 router which sits in the = boundary of the LowPan is a PAN co-ordinator." Since only one PAN = co-ordinator is allowed per LowPan this implies that the LowPan is only = connected by one IPv6 router to the outside world. I think it is = beneficial and applicable to have more than one IPv6 router (gateway) = that connects the LowPan to external networks (e.g. for redundancy, = loadsharing, reaching differnet offlink networks, etc.). If you agree = you could reword the sentence and state: "One of the IPv6 router which = sits in the boundary of the LowPan is the PAN co-ordinator." A second = gateway (IPv6 router) may overtake the role of the PAN coordinator in = case that one is failing (alternate PAN coordinator) or the PAN = coordinator may redirect offlink traffic to a second gateway due to = being overloaded. - page 8, section 5.1: For your statement "[TBD: how can it also find = out about the other addresses? Guess based on the advertised = prefixes?]" I would recommend that for each address a node configures it = sends a Neighbor Solicitation to the PAN coordinator. This way, the PAN = coordinator would get a complete L2-L3 association table of on-link = nodes. This would also answer your last bullet point in section 9 and = removes the need for your section 6.1. - page 8, section 5.2: I would not introduce an additional signalling = protocol, e.g. among coordinators, to enhance RA processing but would = keep periodic RAS and go for your option 2 (use L2 unicast to send RAs). = The resulting overhead should be acceptable (setting an appropriate = interval is a network designer issue). An additional signalling protocol = has also an overhead and complexity, and requires additional processing = in coordinators, which are likely to be battery powered as well. Maybe we could think of a signalling protocol between PAN coordinator = and alternate PAN coordinators (e.g. IPv6 routers that provide external = connectivity) so that an alternate PAN coordinator can quickly = establishes itself as PAN coordinator in case the primary one fails. Best regards, Karl >-----Urspr=FCngliche Nachricht----- >Von: Samita Chakrabarti [mailto:samitac2@gmail.com]=20 >Gesendet: Sonntag, 25. Juni 2006 01:30 >An: 6lowpan@ietf.org >Betreff: [6lowpan] 6lowpan-nd version 2 > >Erik and I have updated=20 >draft-chakrabarti-6lowpan-ipv6-nd-02.txt and submitted for=20 >publication. The new update includes a section on generic=20 >application of this draft for non-multicast, non-broadcast=20 >network. At the last wg meeting, the request was made for such=20 >an update for the Wimax effort on IPv6. > >Two questions to the working group and the chairs: > > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG=20 >document ? > 2) Are we OK with publishing the draft as "IPv6 Neighbor=20 >Discovery Optimization > for IEEE 802.15.4 and other non-multicast networks" so=20 >that it contains > specifics on 6lowpan and a generic guideline for other=20 >relevant networks? > >Comments are welcome. > > >- Samita > >_______________________________________________ >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 Wed Jul 05 04:06:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy2PO-0002ea-E0; Wed, 05 Jul 2006 04:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy2PN-0002eV-F6 for 6lowpan@ietf.org; Wed, 05 Jul 2006 04:06:53 -0400 Received: from wx-out-0102.google.com ([66.249.82.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy2PN-0008UY-5Z for 6lowpan@ietf.org; Wed, 05 Jul 2006 04:06:53 -0400 Received: by wx-out-0102.google.com with SMTP id i26so900509wxd for <6lowpan@ietf.org>; Wed, 05 Jul 2006 01:06:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uLsqBq/Rl6e6yuygG7aBxPoiaSsByS+m0gp085uNHllqvFIwc1NSC0chUKITALQVoXr/UK05Ws8pmODriLv35yBVh78Set+bqlZdbzkyX/6+cCElSP71N/iaznXrWTzDGAKIXsBcN5OVsB8EpXi+HPTShe/XOqrhHOKnCk/ymQA= Received: by 10.70.53.3 with SMTP id b3mr8637285wxa; Wed, 05 Jul 2006 01:06:52 -0700 (PDT) Received: by 10.70.28.18 with HTTP; Wed, 5 Jul 2006 01:06:52 -0700 (PDT) Message-ID: Date: Wed, 5 Jul 2006 17:06:52 +0900 From: "JinHyeock Choi" To: "Behcet Sarikaya" Subject: Re: [6lowpan] 6lowpan-nd version 2 In-Reply-To: <20060627025420.49130.qmail@web60317.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370606261905k4409d643u27fdc0fc5a4d0d39@mail.gmail.com> <20060627025420.49130.qmail@web60317.mail.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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: , Errors-To: 6lowpan-bounces@ietf.org Dear Samita I went over the draft and gladly find many similarities with 'IPv6 over 802.16' work. For example, an Access Router in PAN (PAN coordinator) has the complete list of all the (link-local) addresses on the link' and WiMAX AR (ASN GW) is also an omniscient AR. It seems that we think along the similar line. Kindly find my in-line comments. Sec 3. > 2. When the host initializes its network it multicasts one or a few > Neighbor Solicitation messages to the all-router IPv6 multicast Typo. sub/ Neighbor/ Router. Sec 5.1. > The lowpan nodes MUST include a Sender Link-layer Address option in > the Router Solicitation, since this then allows the router to unicast > a Router Advertisement in response. The above is possible only after DAD is completed, which results in delay. How about including 'Tentative Option' instead? > Since every host sends a RS when it attaches to the PAN and there is > a single router for the PAN (the PAN co-ordinator), this router will > observe the arrival of all the IPv6 link local addresses This may not be so. Allow me an example. When a host attaches to a network, while performing DAD, it may receive an unsolicited (periodic) RA. Then the host would not send an RS. Also the host may generate a new (link-local) address while staying at the same link for the privacy reason. Then it would simply configure a new address without sending an RS. How about monitoring the incoming DAD NS to generate the list instead? That's the approach WiMAX takes right now. Sec 5.2. > Firstly, it might very well be possible to increase the default time > significantly as long as the hosts can use some other mechanism to > detect when the router (the PAN co-ordinator) disappears. We also try to increase the maximum of MaxRtrAdvInterval. Sec 7. > Should nodes in LowPan network use duplicate address > detection Avoiding duplicate address detection will save broadcast > signaling in the PAN-since 802.15.4 does not have multicast > capabilities. I have difficulty understanding the above. Kindly clarify. Sec 11 > It is assumed that the node knows the router's IPv6 address on the > link. Usually this is not possible for 802.16/ WiMAX. > The node sends a Router Solicitation message directly to the > router's link-local address. In WiMAX, the node sends an RS with all-router multicast destination address. However, WiMAX specific forwarding mechanism ensures that the RS is delivered to the AR in unicast. > This RS message MUST carry sender's > link-layer address (SLLA) option. If the RS is sent before completing DAD, it can't carry SLAA. In that case it may carry Tentative Option. > The > default periodic interval should be set by the link-layer technology > specific requirements. In WiMAX, it may not be efficient to send RA every 30 mins (current Max MaxRtrAdvInt) I learned that, in cellular environments, mobile stations remain idle for the majority of time. (Even it's not unthinkable to spend more than 90% of time in idling mode contemplating my own cellular phone usage.) So WiMAX developers are not happy at the prospect of having to page and awaken 90% of dormant nodes for every 30 mins. > This causes the router > to both forward the packet to the target and send a Redirect message > back to the sender. The redirect can include the L2 address for the > target, In WiMAX, the router would not send a Redirect message. Usually L2 address is not used for data forwarding inside a link. In WiMAX, an MS has only an AR, a default router, as its on-link neighbor. > The router > sends router redirects for the target on-link IP address to the > sender node A. The router redirect carries the target link-layer > address option. As I wrote the above, an MS has only its AR as its on-link neighbor in its Neighbor Cache. So I don't think it's necessary for AR to relay an address resolution query. I wish the above helps. Thanks for your kind consideration. Best Regards JinHyeock _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jul 07 18:44:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyz3L-0002OJ-2r; Fri, 07 Jul 2006 18:44:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyz3J-0002OE-MW for 6lowpan@ietf.org; Fri, 07 Jul 2006 18:44:01 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyz3I-0001wN-6q for 6lowpan@ietf.org; Fri, 07 Jul 2006 18:44:01 -0400 Received: by nf-out-0910.google.com with SMTP id c29so332751nfb for <6lowpan@ietf.org>; Fri, 07 Jul 2006 15:43:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A0FSYDC8zAwb2WxJNMgheRoG3SlK4lyfbSGPGEc6s42ib5FtehO48/K/twVzt84jMrOlF3HeKpCsePYk43iuXZW6pHTlvNRPY11d5R1BlZ82kX/q6TLj85COju7cA7tlxLDdxVYiFajXH8ZfzcW+KAdXSBH/LfSKYKP8JGz4KkQ= Received: by 10.78.179.12 with SMTP id b12mr908965huf; Fri, 07 Jul 2006 15:43:59 -0700 (PDT) Received: by 10.78.150.5 with HTTP; Fri, 7 Jul 2006 15:43:58 -0700 (PDT) Message-ID: <43b91d370607071543m441b8ff9p7684211d6087c163@mail.gmail.com> Date: Fri, 7 Jul 2006 15:43:59 -0700 From: "Samita Chakrabarti" To: "Mayer Karl" Subject: Re: [6lowpan] 6lowpan-nd version 2 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43b91d370606241630n52d25c58jb3fb784e364a416e@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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: , Errors-To: 6lowpan-bounces@ietf.org Hi Karl, Thanks for your input. My responses are in-line. On 7/4/06, Mayer Karl wrote: > Hi Samita, > A few comments and questions about your new version. > - page 4, chapter 3 point 2 you state Neighbor Solicitation but it should= be a Router Solicitation, right? Yes. Router Solicitation should be more expilicit term. > > - page 6, chapter 4: you state "The IPv6 router which sits in the boundar= y of the LowPan is a PAN co-ordinator." Since only one PAN co-ordinator is = allowed per LowPan this implies that the LowPan is only connected by one IP= v6 router to the outside world. I think it is beneficial and applicable to = have more than one IPv6 router (gateway) that connects the LowPan to extern= al networks (e.g. for redundancy, loadsharing, reaching differnet offlink n= etworks, etc.). If you agree you could reword the sentence and state: "One = of the IPv6 router which sits in the boundary of the LowPan is the PAN co-o= rdinator." A second gateway (IPv6 router) may overtake the role of the PAN = coordinator in case that one is failing (alternate PAN coordinator) or the = PAN coordinator may redirect offlink traffic to a second >gateway due to be= ing overloaded. At last IETF, we discussed on the signle point of failure issue of single IPv6 router per lowpan. SInce there is single PAN co-ordinator in a lowpan, we would have to figure= out how it switches the PAN-coordinator functionality as well. The IPv6 router function should be a function of PAN-coordinator switch at L2. Once we know about th= e PAN-co-ordinator switch and load-balancing we can fix the text or define an appropriate L3 behavior for that. > > - page 8, section 5.1: For your statement "[TBD: how can it also find out= about the other addresses? Guess based on the advertised prefixes?]" I wo= uld recommend that for each address a node configures it sends a Neighbor S= olicitation to the PAN coordinator. This way, the PAN coordinator would >get a complete L2-L3 association table of on-link nodes. Alternately, (if we want to avoid NS messages to the PAN co-ord) the PAN co= - ordinator can automatically associate global IPv6-addresses in the L2-L3 ta= ble based on the prefix advertisement. Usually NS to a router happens to its link-local address, are you saying each node to send NS to the router's global IPv6 address? > This would also answer your last bullet point in section 9 and removes th= e need for your section 6.1. 6.1 redirect messages for address resolution is useful because it distributes the load of future messages to the respective nodes. Also, since the router advertises off-link (L=3D0) in RA, the node sends data directly to the router; this saves cost = of NS. So, I think 6.1 redirect method might be useful for saving messages. > > - page 8, section 5.2: I would not introduce an additional signalling pro= tocol, e.g. among coordinators, to enhance RA processing but would keep per= iodic RAS and go for your option 2 (use L2 unicast to send RAs). The result= ing overhead should be acceptable (setting an appropriate interval is a net= work designer issue). An additional signalling protocol has also an overhea= d and complexity, and requires additional processing in coordinators, which= are likely to be battery powered as well. Ok. I understand that you suggest using L2 unicast to send RA to each node= . > Maybe we could think of a signalling protocol between PAN coordinator and= alternate PAN coordinators (e.g. IPv6 routers that provide external connec= tivity) so that an alternate PAN coordinator can quickly establishes itself= as PAN >coordinator in case the primary one fails. Do you have any idea to switch PAN co-ordinators at L2 layer? If so, we cou= ld link IPv6-router switch along with that. Regards, -Samita > >-----Urspr=FCngliche Nachricht----- > >Von: Samita Chakrabarti [mailto:samitac2@gmail.com] > >Gesendet: Sonntag, 25. Juni 2006 01:30 > >An: 6lowpan@ietf.org > >Betreff: [6lowpan] 6lowpan-nd version 2 > > > >Erik and I have updated > >draft-chakrabarti-6lowpan-ipv6-nd-02.txt and submitted for > >publication. The new update includes a section on generic > >application of this draft for non-multicast, non-broadcast > >network. At the last wg meeting, the request was made for such > >an update for the Wimax effort on IPv6. > > > >Two questions to the working group and the chairs: > > > > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG > >document ? > > 2) Are we OK with publishing the draft as "IPv6 Neighbor > >Discovery Optimization > > for IEEE 802.15.4 and other non-multicast networks" so > >that it contains > > specifics on 6lowpan and a generic guideline for other > >relevant networks? > > > >Comments are welcome. > > > > > >- Samita > > > >_______________________________________________ > >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 Fri Jul 07 19:59:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz0Eb-0001eQ-Bw; Fri, 07 Jul 2006 19:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz0Ea-0001d6-5u for 6lowpan@ietf.org; Fri, 07 Jul 2006 19:59:44 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz0EZ-0002og-Lm for 6lowpan@ietf.org; Fri, 07 Jul 2006 19:59:44 -0400 Received: by nf-out-0910.google.com with SMTP id l23so4312nfc for <6lowpan@ietf.org>; Fri, 07 Jul 2006 16:59:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VFYJg6t/jNUv8WskJDVRR1GzJWG//1ySG6nc3F8FBhtym4aQDlwguROLGyfFKWIe5UxybapeBI8fTp1313Hal2FZQt21szaebW8nwakSitn+1f8ZB91KbimFb2GNwdJUrxaS9Fo7kHjfb8uIkmsCjMp6V88WbLG45dctgJ463FY= Received: by 10.78.117.10 with SMTP id p10mr924089huc; Fri, 07 Jul 2006 16:59:42 -0700 (PDT) Received: by 10.78.150.5 with HTTP; Fri, 7 Jul 2006 16:59:42 -0700 (PDT) Message-ID: <43b91d370607071659n1fada033xfb521ca5a2132c46@mail.gmail.com> Date: Fri, 7 Jul 2006 16:59:42 -0700 From: "Samita Chakrabarti" To: "JinHyeock Choi" Subject: Re: [6lowpan] 6lowpan-nd version 2 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370606261905k4409d643u27fdc0fc5a4d0d39@mail.gmail.com> <20060627025420.49130.qmail@web60317.mail.yahoo.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 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: , Errors-To: 6lowpan-bounces@ietf.org HI JinHyeock, On 7/5/06, JinHyeock Choi wrote: > Dear Samita > > I went over the draft and gladly find many similarities with 'IPv6 > over 802.16' work. For example, an Access Router in PAN (PAN > coordinator) has the complete list of all the (link-local) addresses > on the link' and WiMAX AR (ASN GW) is also an omniscient AR. It seems > that we think along the similar line. Agree. > > Kindly find my in-line comments. Thanks for your comments. > > Sec 3. > > > 2. When the host initializes its network it multicasts one or a few > > Neighbor Solicitation messages to the all-router IPv6 multicast > > Typo. sub/ Neighbor/ Router. Ok. > > Sec 5.1. > > > The lowpan nodes MUST include a Sender Link-layer Address option in > > the Router Solicitation, since this then allows the router to unicast > > a Router Advertisement in response. > > The above is possible only after DAD is completed, which results in > delay. How about including 'Tentative Option' instead? > Are you talking about Optimized DAD? How much time should we be saving? Will it be worth the extra code ? This document is only concerned with the base ND changes. > > Since every host sends a RS when it attaches to the PAN and there is > > a single router for the PAN (the PAN co-ordinator), this router will > > observe the arrival of all the IPv6 link local addresses > > This may not be so. Allow me an example. When a host attaches to a > network, while performing DAD, it may receive an unsolicited > (periodic) RA. Then the host would not send an RS. Also the host may > generate a new (link-local) address while staying at the same link for > the privacy reason. Then it would simply configure a new address > without sending an RS. In case of LowPan-ND, we are requiring to send unicast RS to the IPv6-router. We have not decided whether DAD should be mandatory for these devices or not. Since this draft assumes each node has EUI-64 addresses, DAD may not be required in theory. But in practice, it may choose to do DAD through the Ipv6-router. However, it will not receive unsolicited RA while waiting on DAD, because in this ND-extension RA will happen (most likely) through unicast L2 messages. Since both the DAD and RA will be sent by the same Ipv6 router, I'd assume they will happen in sequence. But due to radio link issues, we cannot guarantee that one will reach the destination always in sequence. Perhaps, we need to re-word the above mentioned text to clarify "observe the arrival..." part of the sentence. > > How about monitoring the incoming DAD NS to generate the list instead? > That's the approach WiMAX takes right now. Will discuss that. As mentioned above that DAD may not be mandatory. > > Sec 5.2. > > > Firstly, it might very well be possible to increase the default time > > significantly as long as the hosts can use some other mechanism to > > detect when the router (the PAN co-ordinator) disappears. > > We also try to increase the maximum of MaxRtrAdvInterval. > What was the value? Which draft is it in? > Sec 7. > > > Should nodes in LowPan network use duplicate address > > detection Avoiding duplicate address detection will save broadcast > > signaling in the PAN-since 802.15.4 does not have multicast > > capabilities. > > I have difficulty understanding the above. Kindly clarify. Sorry, that sentence is problematic. We are missing a punctuation. It means that DAD means broadcast in 802.15.4 network and should we skip DAD for 802.15.4 network? > > Sec 11 > > > It is assumed that the node knows the router's IPv6 address on the > > link. > > Usually this is not possible for 802.16/ WiMAX. How does it know its router address then? Does it know router's link-layer address to send DAD? > > > The node sends a Router Solicitation message directly to the > > router's link-local address. > > In WiMAX, the node sends an RS with all-router multicast destination > address. However, WiMAX specific forwarding mechanism ensures that the > RS is delivered to the AR in unicast. Ok. The above line actually meant the same, but it did not specify the L3 address and the destination IP-address should be multicast address as specified in IPv6, but the link layer sends it to the L2-unicast address. So we are in sync. > > > This RS message MUST carry sender's > > link-layer address (SLLA) option. > > If the RS is sent before completing DAD, it can't carry SLAA. In that > case it may carry Tentative Option. > Can you please point me to the Tentative Option document? > > The > > default periodic interval should be set by the link-layer technology > > specific requirements. > > In WiMAX, it may not be efficient to send RA every 30 mins (current > Max MaxRtrAdvInt) I learned that, in cellular environments, mobile > stations remain idle for the majority of time. (Even it's not > unthinkable to spend more than 90% of time in idling mode > contemplating my own cellular phone usage.) So WiMAX developers are > not happy at the prospect of having to page and awaken 90% of dormant > nodes for every 30 mins. I think Wimax has some other mechanism for sending 'Fast-RA' during device attachment time and then it sends RS to followup. So it is perfectly alright not to have a periodic RA. In that case RA interval is infinity :-) > > > This causes the router > > to both forward the packet to the target and send a Redirect message > > back to the sender. The redirect can include the L2 address for the > > target, > > In WiMAX, the router would not send a Redirect message. Usually L2 > address is not used for data forwarding inside a link. In WiMAX, an MS > has only an AR, a default router, as its on-link neighbor. Please see section 10 of this draft for application on other technologies. RFC2461 actually recommends using off-link RA advertisements for the non-broadcast/non-multicast networks neighbor soliciation. This is not new in this draft. > > > The router > > sends router redirects for the target on-link IP address to the > > sender node A. The router redirect carries the target link-layer > > address option. > > As I wrote the above, an MS has only its AR as its on-link neighbor in > its Neighbor Cache. So I don't think it's necessary for AR to relay an > address resolution query. So, according to your description, each MS is off-link to the other. So any packet has to be forwarded to the AR first. It sounds like the AR needs to have a different IPv6 link and L2 link (for each MS), such that an IPv6-link consists of multiple MSes. So, if AR follows IPv6 neighbor discovery it should advertise RA with L=0 and all data packets are forwarded through it like a star topology in 6lowpan. Thanks for pointing out the differences in Wimax technology. As I mentioned before, this draft only provides guidelines for other technolgies so that mimimal change is required to adopt IPv6 ND on other non-broadcast/multicast networks. Regards, -Samita > > I wish the above helps. > > Thanks for your kind consideration. > > Best Regards > > JinHyeock > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Jul 09 20:56:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzk51-0005r7-7L; Sun, 09 Jul 2006 20:56:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzk50-0005qY-Kc for 6lowpan@lists.ietf.org; Sun, 09 Jul 2006 20:56:54 -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 1Fzk4k-00066r-36 for 6lowpan@lists.ietf.org; Sun, 09 Jul 2006 20:56:54 -0400 Received: from [127.0.0.1] (m2 [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k6A0uLKX014795; Mon, 10 Jul 2006 02:56:23 +0200 (CEST) In-Reply-To: <1151942029.22336.7.camel@dellx1> References: <1151942029.22336.7.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B128760-6B1A-497A-9A35-D6C892A0B3F0@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [6lowpan] agenda for next week Date: Sun, 9 Jul 2006 20:56:04 -0400 To: 6lowpan <6lowpan@lists.ietf.org> X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Carsten Bormann 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 While Geoff and I are still finalizing the details of agenda, I have one request: Would those that plan to present in Tuesday's meeting please: -- send copies of the slides to Geoff and me -- meet with us on Monday at 0800 over breakfast in 517D (or send mail otherwise) To save you a click, the agenda we have posted looks like this: 09:00 - Intro and agenda Bormann (10) 09:10 - Working group status Mulligan (10) 09:20 - Format Spec Montenegro (30) 09:50 - Low-power Mesh networking Mulligan (10+20) 10:20 - Charter discussion Chairs (20) 10:40 - New Work Thanks, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 10 00:25:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FznKk-0005PE-FV; Mon, 10 Jul 2006 00:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FznKj-0005LM-0H for 6lowpan@lists.ietf.org; Mon, 10 Jul 2006 00:25:21 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FznC6-0004Kd-Ra for 6lowpan@lists.ietf.org; Mon, 10 Jul 2006 00:16:30 -0400 Received: by ug-out-1314.google.com with SMTP id m3so1450188uge for <6lowpan@lists.ietf.org>; Sun, 09 Jul 2006 21:16:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=c5UVca/NgY0osgSJ/Po1Ll9gtbCcKuJZKFeXjXOPw1u2Tev+zea6dO977dp+NMPBqt3CSpxg76UJcy/3NuoprQANO1abGHfIabpnE7AOPR5fJD5gbvhouM3aj83cf7KdmuNHMos1VA+7ATg6fjtQ4DuOXfmZDpYBAtRDDHomECI= Received: by 10.67.19.13 with SMTP id w13mr4586565ugi; Sun, 09 Jul 2006 21:16:25 -0700 (PDT) Received: by 10.67.86.2 with HTTP; Sun, 9 Jul 2006 21:16:25 -0700 (PDT) Message-ID: Date: Mon, 10 Jul 2006 13:16:25 +0900 From: "Ki-Hyung Kim" To: "Carsten Bormann" , "Geoff Mulligan" Subject: Re: [6lowpan] agenda for next week In-Reply-To: <3B128760-6B1A-497A-9A35-D6C892A0B3F0@tzi.org> MIME-Version: 1.0 References: <1151942029.22336.7.camel@dellx1> <3B128760-6B1A-497A-9A35-D6C892A0B3F0@tzi.org> X-Spam-Score: 0.6 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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: , Content-Type: multipart/mixed; boundary="===============1907780426==" Errors-To: 6lowpan-bounces@ietf.org --===============1907780426== Content-Type: multipart/alternative; boundary="----=_Part_10694_21391307.1152504985173" ------=_Part_10694_21391307.1152504985173 Content-Type: text/plain; charset=EUC-KR; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgR2VvZmYgYW5kIENhcnN0ZW4sCkkgd2FudCB0byBwcmVzZW50IHRoZSBwcm9ncmVzcyBvZiBM T0FEIChlc3BlY2lhbGx5IHRoZSBwcmVsaW1pbmFyeQpwZXJmb3JtYW5jZSByZXN1bHRzICkuCgoK CjIwMDYvNy8xMCwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+Ogo+Cj4gV2hpbGUgR2Vv ZmYgYW5kIEkgYXJlIHN0aWxsIGZpbmFsaXppbmcgdGhlIGRldGFpbHMgb2YgYWdlbmRhLCBJIGhh dmUKPiBvbmUgcmVxdWVzdDoKPiBXb3VsZCB0aG9zZSB0aGF0IHBsYW4gdG8gcHJlc2VudCBpbiBU dWVzZGF5J3MgbWVldGluZyBwbGVhc2U6Cj4KPiAtLSBzZW5kIGNvcGllcyBvZiB0aGUgc2xpZGVz IHRvIEdlb2ZmIGFuZCBtZQo+IC0tIG1lZXQgd2l0aCB1cyBvbiBNb25kYXkgYXQgMDgwMCBvdmVy IGJyZWFrZmFzdCBpbiA1MTdEIChvciBzZW5kCj4gbWFpbCBvdGhlcndpc2UpCj4KPiBUbyBzYXZl IHlvdSBhIGNsaWNrLCB0aGUgYWdlbmRhIHdlIGhhdmUgcG9zdGVkIGxvb2tzIGxpa2UgdGhpczoK Pgo+IDA5OjAwIC0gSW50cm8gYW5kIGFnZW5kYSAgICAgICAgICAgICAgICAgICAgICAgIEJvcm1h bm4gKDEwKQo+IDA5OjEwIC0gV29ya2luZyBncm91cCBzdGF0dXMgICAgICAgICAgICAgICAgICAg IE11bGxpZ2FuICgxMCkKPiAwOToyMCAtIEZvcm1hdCBTcGVjICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBNb250ZW5lZ3JvICgzMCkKPiAwOTo1MCAtIExvdy1wb3dlciBNZXNoIG5ldHdvcmtp bmcgICAgICAgICAgICAgICBNdWxsaWdhbiAoMTArMjApCj4gMTA6MjAgLSBDaGFydGVyIGRpc2N1 c3Npb24gICAgICAgICAgICAgICAgICAgICAgQ2hhaXJzICgyMCkKPiAxMDo0MCAtIE5ldyBXb3Jr Cj4KPiBUaGFua3MsCj4KPiBDYXJzdGVuCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4gNmxvd3BhbiBtYWlsaW5nIGxpc3QKPiA2bG93cGFuQGll dGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3Bhbgo+ CgoKCi0tIApLaS1IeXVuZyBLaW0gKLHoseLH/Cwg0N3Rw/r7KQpBc3NvY2lhdGUgUHJvZmVzc29y CkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIGFuZCBDb21wdXRlciBFbmcuLCBBam91IFVuaXZlcnNp dHksIFN1d29uLCBLb3JlYQo0NDItNzQ5ClRlbDogKzgyLTMxLTIxOS0yNDMzLCBDZWw6ICs4Mi0x Ny03NjAtMjU1MSwgIEZheDogKzgyLTMxLTIxOS0yNDMzCmh0dHA6Ly93d3cuNmxvd3Bhbi5vcmcK ------=_Part_10694_21391307.1152504985173 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSBHZW9mZiBhbmQgQ2Fyc3Rlbiw8L2Rpdj4KPGRpdj5JIHdhbnQgdG8gcHJlc2VudCB0 aGUgcHJvZ3Jlc3Mgb2YgTE9BRCZuYnNwOyhlc3BlY2lhbGx5IHRoZSBwcmVsaW1pbmFyeSBwZXJm b3JtYW5jZSByZXN1bHRzICkuPC9kaXY+CjxkaXY+PGJyPjxicj4mbmJzcDs8L2Rpdj4KPGRpdj48 c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMDYvNy8xMCwgQ2Fyc3RlbiBCb3JtYW5uICZsdDs8 YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIj5jYWJvQHR6aS5vcmc8L2E+Jmd0Ozo8L3NwYW4+ CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4 OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQi PldoaWxlIEdlb2ZmIGFuZCBJIGFyZSBzdGlsbCBmaW5hbGl6aW5nIHRoZSBkZXRhaWxzIG9mIGFn ZW5kYSwgSSBoYXZlPGJyPm9uZSByZXF1ZXN0Ojxicj5Xb3VsZCB0aG9zZSB0aGF0IHBsYW4gdG8g cHJlc2VudCBpbiBUdWVzZGF5J3MgbWVldGluZyBwbGVhc2U6Cjxicj48YnI+LS0gc2VuZCBjb3Bp ZXMgb2YgdGhlIHNsaWRlcyB0byBHZW9mZiBhbmQgbWU8YnI+LS0gbWVldCB3aXRoIHVzIG9uIE1v bmRheSBhdCAwODAwIG92ZXIgYnJlYWtmYXN0IGluIDUxN0QgKG9yIHNlbmQ8YnI+bWFpbCBvdGhl cndpc2UpPGJyPjxicj5UbyBzYXZlIHlvdSBhIGNsaWNrLCB0aGUgYWdlbmRhIHdlIGhhdmUgcG9z dGVkIGxvb2tzIGxpa2UgdGhpczo8YnI+PGJyPjA5OjAwIC0gSW50cm8gYW5kIGFnZW5kYSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0Jvcm1hbm4gKDEwKQo8YnI+MDk6MTAgLSBXb3JraW5n IGdyb3VwIHN0YXR1cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO011bGxpZ2FuICgxMCk8YnI+MDk6MjAgLSBGb3JtYXQgU3BlYyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNb250 ZW5lZ3JvICgzMCk8YnI+MDk6NTAgLSBMb3ctcG93ZXIgTWVzaCBuZXR3b3JraW5nJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE11bGxpZ2FuICgxMCsyMCk8YnI+MTA6MjAgLSBDaGFydGVyIGRp c2N1c3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDaGFpcnMgKDIwKQo8YnI+MTA6NDAgLSBOZXcgV29y azxicj48YnI+VGhhbmtzLDxicj48YnI+Q2Fyc3Rlbjxicj48YnI+PGJyPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPjZsb3dwYW4gbWFpbGluZyBsaXN0 PGJyPjxhIGhyZWY9Im1haWx0bzo2bG93cGFuQGlldGYub3JnIj42bG93cGFuQGlldGYub3JnPC9h Pjxicj48YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93 cGFuIj4KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3BhbjwvYT48 YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5LaS1I eXVuZyBLaW0gKLHoseLH/Cwg0N3Rw/r7KTxicj5Bc3NvY2lhdGUgUHJvZmVzc29yPGJyPkRpdmlz aW9uIG9mIEluZm9ybWF0aW9uIGFuZCBDb21wdXRlciBFbmcuLCBBam91IFVuaXZlcnNpdHksIFN1 d29uLCBLb3JlYSA0NDItNzQ5Cjxicj5UZWw6ICs4Mi0zMS0yMTktMjQzMywgQ2VsOiArODItMTct NzYwLTI1NTEsJm5ic3A7Jm5ic3A7RmF4OiArODItMzEtMjE5LTI0MzMgPGEgaHJlZj0iaHR0cDov L3d3dy42bG93cGFuLm9yZyI+aHR0cDovL3d3dy42bG93cGFuLm9yZzwvYT4gCg== ------=_Part_10694_21391307.1152504985173-- --===============1907780426== 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 --===============1907780426==-- From 6lowpan-bounces@ietf.org Mon Jul 10 10:21:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwdn-0000KD-Ny; Mon, 10 Jul 2006 10:21:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwdm-0000K8-W0 for 6lowpan@ietf.org; Mon, 10 Jul 2006 10:21:38 -0400 Received: from wx-out-0102.google.com ([66.249.82.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzwdk-0001ev-LG for 6lowpan@ietf.org; Mon, 10 Jul 2006 10:21:38 -0400 Received: by wx-out-0102.google.com with SMTP id i26so1694752wxd for <6lowpan@ietf.org>; Mon, 10 Jul 2006 07:21:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qoZ2lRRx5FadvSNGnMzoOML34kW85v6HfNN0j59jgGx9pJq69U6SC9JOdGiVAIx35DVLrtYQmK6StAtbJFmay0IuL2MhnmnbK6kvk23Wpp4fZ3nvL9M3GP9MbL4BrSq2O5bhcqKwQdFHVZ0Bt4OxG57bKZiY21qkJ0xbS0DTwFE= Received: by 10.70.32.7 with SMTP id f7mr5478510wxf; Mon, 10 Jul 2006 07:21:35 -0700 (PDT) Received: by 10.70.28.18 with HTTP; Mon, 10 Jul 2006 07:21:35 -0700 (PDT) Message-ID: Date: Mon, 10 Jul 2006 15:21:35 +0100 From: "JinHyeock Choi" To: "Samita Chakrabarti" Subject: Re: [6lowpan] 6lowpan-nd version 2 In-Reply-To: <43b91d370607071659n1fada033xfb521ca5a2132c46@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370606261905k4409d643u27fdc0fc5a4d0d39@mail.gmail.com> <20060627025420.49130.qmail@web60317.mail.yahoo.com> <43b91d370607071659n1fada033xfb521ca5a2132c46@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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: , Errors-To: 6lowpan-bounces@ietf.org Dear Samita Thanks for your clarification. >> The above is possible only after DAD is completed, which results in >> delay. How about including 'Tentative Option' instead? >> > Are you talking about Optimized DAD? yes. > How much time should we be saving? 1 sec by default. > Will it be worth the extra code ? It depends. :-) > This document is only concerned with the base ND changes. I see. >> > Since every host sends a RS when it attaches to the PAN and there is >> > a single router for the PAN (the PAN co-ordinator), this router will >> > observe the arrival of all the IPv6 link local addresses >> >> This may not be so. Allow me an example. When a host attaches to a >> network, while performing DAD, it may receive an unsolicited >> (periodic) RA. Then the host would not send an RS. Also the host may >> generate a new (link-local) address while staying at the same link for >> the privacy reason. Then it would simply configure a new address >> without sending an RS. > > In case of LowPan-ND, we are requiring to send unicast RS to the IPv6-router. > We have not decided whether DAD should be mandatory for these devices or not. > Since this draft assumes each node has EUI-64 addresses, DAD may not be > required in theory. But in practice, it may choose to do DAD through > the Ipv6-router. > However, it will not receive unsolicited RA while waiting on DAD, because in > this ND-extension RA will happen (most likely) through unicast L2 messages. > Since both the DAD and RA will be sent by the same Ipv6 router, I'd assume > they will happen in sequence. But due to radio link issues, we cannot guarantee > that one will reach the destination always in sequence. Perhaps, we > need to re-word the above mentioned text to clarify "observe the > arrival..." part of the sentence. ok. >> How about monitoring the incoming DAD NS to generate the list instead? >> That's the approach WiMAX takes right now. > > Will discuss that. As mentioned above that DAD may not be mandatory. ok. >> > Firstly, it might very well be possible to increase the default time >> > significantly as long as the hosts can use some other mechanism to >> > detect when the router (the PAN co-ordinator) disappears. >> >> We also try to increase the maximum of MaxRtrAdvInterval. > > What was the value? Which draft is it in? > Sorry, that sentence is problematic. We are missing a punctuation. > > It means that DAD means broadcast in 802.15.4 network and should we > skip DAD for 802.15.4 network? ok. >> > This RS message MUST carry sender's >> > link-layer address (SLLA) option. >> >> If the RS is sent before completing DAD, it can't carry SLAA. In that >> case it may carry Tentative Option. > > Can you please point me to the Tentative Option document? http://www.ietf.org/internet-drafts/draft-ietf-dna-tentative-00.txt Take notice that the draft is planned to be merged into a single DNA draft. >> In WiMAX, the router would not send a Redirect message. Usually L2 >> address is not used for data forwarding inside a link. In WiMAX, an MS >> has only an AR, a default router, as its on-link neighbor. > > Please see section 10 of this draft for application on other technologies. > RFC2461 actually recommends using off-link RA advertisements for > the non-broadcast/non-multicast networks neighbor soliciation. This is > not new in this draft. I see. >> As I wrote the above, an MS has only its AR as its on-link neighbor in >> its Neighbor Cache. So I don't think it's necessary for AR to relay an >> address resolution query. > > So, according to your description, each MS is off-link to the other. > So any packet has to be forwarded to the AR first. It sounds like > the AR needs to have a different IPv6 link and L2 link (for each MS), > such that an IPv6-link consists of multiple MSes. > So, if AR follows IPv6 neighbor discovery it should advertise RA with L=0 > and all data packets are forwarded through it like a star topology in 6lowpan. yes. > Thanks for pointing out the differences in Wimax technology. As I mentioned > before, this draft only provides guidelines for other technolgies so that > mimimal change is required to adopt IPv6 ND on other non-broadcast/multicast > networks. I see. Thanks for your kind consideration. Best Regards JinHyeock _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 10 10:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwfs-0003nw-OZ; Mon, 10 Jul 2006 10:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwfr-0003mE-RU for 6lowpan@ietf.org; Mon, 10 Jul 2006 10:23:47 -0400 Received: from wx-out-0102.google.com ([66.249.82.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzwfq-0001jK-Lz for 6lowpan@ietf.org; Mon, 10 Jul 2006 10:23:47 -0400 Received: by wx-out-0102.google.com with SMTP id i26so1695041wxd for <6lowpan@ietf.org>; Mon, 10 Jul 2006 07:23:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gbjC0uUJEjgaEGGSveVNkhHaA0AyvxdGS8Mqr4jkl5font5QsVTdYJ8aoLMeG1CmVwU7CxkkFZPPYPbzTRRmKQLdsNKmT7mc4rb/BjINlPlJxkg7qkTAtocaQLczV0iMt119sqlnzlvBiP2A445WiQhE701k3U7UlAYoedHIRWc= Received: by 10.70.97.7 with SMTP id u7mr5724437wxb; Mon, 10 Jul 2006 07:23:46 -0700 (PDT) Received: by 10.70.28.18 with HTTP; Mon, 10 Jul 2006 07:23:45 -0700 (PDT) Message-ID: Date: Mon, 10 Jul 2006 15:23:45 +0100 From: "JinHyeock Choi" To: "Samita Chakrabarti" Subject: Re: [6lowpan] 6lowpan-nd version 2 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370606261905k4409d643u27fdc0fc5a4d0d39@mail.gmail.com> <20060627025420.49130.qmail@web60317.mail.yahoo.com> <43b91d370607071659n1fada033xfb521ca5a2132c46@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: 6lowpan-bounces@ietf.org >> > Firstly, it might very well be possible to increase the default time >> > significantly as long as the hosts can use some other mechanism to >> > detect when the router (the PAN co-ordinator) disappears. >> >> We also try to increase the maximum of MaxRtrAdvInterval. > > What was the value? Which draft is it in? roughly 6 hours. We try to reflect that in 2461bis. Best Regards JinHyeock _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 10 10:49:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzx4n-0004iK-Ci; Mon, 10 Jul 2006 10:49:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzx4m-0004iF-D0 for 6lowpan@ietf.org; Mon, 10 Jul 2006 10:49:32 -0400 Received: from mail2.iabg.de ([62.245.167.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzx4l-0002hC-QQ for 6lowpan@ietf.org; Mon, 10 Jul 2006 10:49:32 -0400 Received: from mail2.iabg.de (localhost [127.0.0.1]) by localhost.iabg.de (Mailserver2 IABG) with ESMTP id E9C731312; Mon, 10 Jul 2006 16:49:22 +0200 (CEST) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail2.iabg.de (Mailserver2 IABG) with ESMTP id D619A130C; Mon, 10 Jul 2006 16:49:22 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [6lowpan] 6lowpan-nd version 2 Date: Mon, 10 Jul 2006 16:49:17 +0200 Message-ID: In-Reply-To: <43b91d370607071543m441b8ff9p7684211d6087c163@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan-nd version 2 Thread-Index: AcaiF9p/79v4sf5qTYWS0Jr2phtJ/gB6hexg From: "Mayer Karl" To: "Samita Chakrabarti" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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: , Errors-To: 6lowpan-bounces@ietf.org Hi Samita, Thanks for your quick response. See comments inline... >> - page 6, chapter 4: you state "The IPv6 router which sits=20 >in the boundary of the LowPan is a PAN co-ordinator." Since=20 >only one PAN co-ordinator is allowed per LowPan this implies=20 >that the LowPan is only connected by one IPv6 router to the=20 >outside world. I think it is beneficial and applicable to have=20 >more than one IPv6 router (gateway) that connects the LowPan=20 >to external networks (e.g. for redundancy, loadsharing,=20 >reaching differnet offlink networks, etc.). If you agree you=20 >could reword the sentence and state: "One of the IPv6 router=20 >which sits in the boundary of the LowPan is the PAN=20 >co-ordinator." A second gateway (IPv6 router) may overtake the=20 >role of the PAN coordinator in case that one is failing=20 >(alternate PAN coordinator) or the PAN coordinator may=20 >redirect offlink traffic to a second >gateway due to being overloaded. > >At last IETF, we discussed on the signle point of failure=20 >issue of single > IPv6 router per lowpan. >SInce there is single PAN co-ordinator in a lowpan, we would=20 >have to figure out how it switches the PAN-coordinator=20 >functionality as well. The IPv6 router function should be a=20 >function of PAN-coordinator switch at L2. Once we know about=20 >the PAN-co-ordinator switch and load-balancing we can fix the=20 >text or define an appropriate L3 behavior for that. > >> >> - page 8, section 5.1: For your statement "[TBD: how can it=20 >also find=20 >>out about the other addresses? Guess based on the advertised=20 >prefixes?]" I would recommend that for each address a node=20 >configures it sends a Neighbor Solicitation to the PAN=20 >coordinator. This way, the PAN coordinator would get a=20 >complete L2-L3 association table of on-link nodes. > >Alternately, (if we want to avoid NS messages to the PAN=20 >co-ord) the PAN co- ordinator can automatically associate=20 >global IPv6-addresses in the L2-L3 table based on the prefix=20 >advertisement. Usually NS to a router happens to its=20 >link-local address, are you saying each node to send NS to the=20 >router's global IPv6 address? So you would conclude from the EUI-64 identifier of the link-local = address (received in the RS) also the non-link-local addresses, right? = This is only possible in case *all* IP addresses are constructed by = concatenating the respective prefix with the EUI-64 identifier. However, = draft-ietf-6lowpan-format-03 leaves flexibility in the constructing of = non-link-local IP addresses so I am not sure whether we can rely on this = (or at least we have to make this an requirement).=20 Therefore my proposal was to send for each configured IPv6 address an NS = message to the PAN coordinator with the respective IPv6 address as = source address and the Source Link Layer Address option. The destination = address could be any of the router's IPv6 addresses, the link-local = address as well. > >> This would also answer your last bullet point in section 9=20 >and removes the need for your section 6.1. > >6.1 redirect messages for address resolution is useful because=20 >it distributes the load of future messages to the respective nodes. > Also, since the router advertises off-link >(L=3D0) in RA, the node sends data directly to the router; this=20 >saves cost of NS. >So, I think 6.1 redirect method might be useful for saving messages. > Now I got your point.=20 >> >> - page 8, section 5.2: I would not introduce an additional=20 >signalling protocol, e.g. among coordinators, to enhance RA=20 >processing but would keep periodic RAS and go for your option=20 >2 (use L2 unicast to send RAs). The resulting overhead should=20 >be acceptable (setting an appropriate interval is a network=20 >designer issue). An additional signalling protocol has also an=20 >overhead and complexity, and requires additional processing in=20 >coordinators, which are likely to be battery powered as well. > >Ok. I understand that you suggest using L2 unicast to send RA=20 >to each node. > >> Maybe we could think of a signalling protocol between PAN=20 >coordinator=20 >>and alternate PAN coordinators (e.g. IPv6 routers that=20 >provide external connectivity) so that an alternate PAN=20 >coordinator can quickly establishes itself as PAN coordinator=20 >in case the primary one fails. > >Do you have any idea to switch PAN co-ordinators at L2 layer?=20 >If so, we could link IPv6-router switch along with that. Not much about this is written in the IEEE 802.15.4-2003 standard and I = have no access to the IEEE 802.15.4b-2003 standard (and I don't think = they solve this issue there). I assume 802.15.4 leaves it up to higher = layers (e.g. to the 6lowpan layer) to deal with PAN coordinator = selection. When sending an Association Request message, a node can = signal its wilingness to be an alternate PAN coordinator via a = respective flag. Similar to other failover mechanisms, a PAN coordinator = receiving such a message with the flag set could subsequently send = periodically an alive message just to his alternate PAN coordinators. In = case an alternate PAN coordinator does not receive an alive message = anymore it could perform an election process among all alternate PAN = coordinators and become the PAN coordinator. Clearly, there are open = issues and these are just first thoughts. Best regards, Karl > >Regards, >-Samita > > >> >-----Urspr=FCngliche Nachricht----- >> >Von: Samita Chakrabarti [mailto:samitac2@gmail.com] >> >Gesendet: Sonntag, 25. Juni 2006 01:30 >> >An: 6lowpan@ietf.org >> >Betreff: [6lowpan] 6lowpan-nd version 2 >> > >> >Erik and I have updated >> >draft-chakrabarti-6lowpan-ipv6-nd-02.txt and submitted for=20 >> >publication. The new update includes a section on generic=20 >application=20 >> >of this draft for non-multicast, non-broadcast network. At the last=20 >> >wg meeting, the request was made for such an update for the Wimax=20 >> >effort on IPv6. >> > >> >Two questions to the working group and the chairs: >> > >> > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG=20 >> >document ? >> > 2) Are we OK with publishing the draft as "IPv6 Neighbor=20 >Discovery=20 >> >Optimization >> > for IEEE 802.15.4 and other non-multicast networks"=20 >so that it=20 >> >contains >> > specifics on 6lowpan and a generic guideline for=20 >other relevant=20 >> >networks? >> > >> >Comments are welcome. >> > >> > >> >- Samita >> > >> >_______________________________________________ >> >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 Mon Jul 10 19:25:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G057s-0005jj-C6; Mon, 10 Jul 2006 19:25:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G057r-0005je-Id for 6lowpan@ietf.org; Mon, 10 Jul 2006 19:25:15 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G057q-0007cx-8l for 6lowpan@ietf.org; Mon, 10 Jul 2006 19:25:15 -0400 Received: by ug-out-1314.google.com with SMTP id m3so190966uge for <6lowpan@ietf.org>; Mon, 10 Jul 2006 16:25:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jrJ5/4jO7hGZ9Ky/n3E0iZDBoCoo0laj5P5qUecJ2Z2qG2gQvGKJiexnmM1AY12vZFnEfoHe319PqaUog1ONmGSD5hSKmyds/29TAZaYiiW5cTkap/wsr5nOiKwDlgvGzdBU19LNQ+RAF/Mz0wTIf+eoxPq5Ex8z9sO+VMguYZQ= Received: by 10.78.170.17 with SMTP id s17mr1915723hue; Mon, 10 Jul 2006 16:25:13 -0700 (PDT) Received: by 10.78.150.5 with HTTP; Mon, 10 Jul 2006 16:25:12 -0700 (PDT) Message-ID: <43b91d370607101625g55bc83fap7dd6ebcdbe5f03f1@mail.gmail.com> Date: Mon, 10 Jul 2006 16:25:12 -0700 From: "Samita Chakrabarti" To: "Julien Laganier" Subject: Re: [6lowpan] 6lowpan-nd version 2 In-Reply-To: <200606271558.22329.julien.laganier@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370606241630n52d25c58jb3fb784e364a416e@mail.gmail.com> <04fb01c69913$90578140$6dc6dba8@daniellaptop> <43b91d370606261905k4409d643u27fdc0fc5a4d0d39@mail.gmail.com> <200606271558.22329.julien.laganier@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: 6lowpan-bounces@ietf.org Hi Julien, Thanks for the pointer. Please see my comments below. On 6/27/06, Julien Laganier wrote: >> Thus the idea is that 16ng-ND draft can update its text based on > > the information in the general applicability section of the > > 6lowpan-ND draft. > > Until today I was unaware of existence of Relay-DAD in 6lowpan and > 16ng (silly me ;-) > > As I mentionned already on the 16ng mailing list today: > > > In a draft I co-author (available there until it shows up in ID rep: > ( we also define Relay-DAD to support SEND (otherwise we could just have > proxied ND.) > > Hence, I thought I should also ask to this mailing list opinions on > usefulness of a standalone document defining Relay-DAD? I don't know how much security work will be part of 6lowpan charter. This draft may be more applicable for the 16ng architecture at this point. Don't know whether 6lowpan will adopt a very simple security scheme ( i,e shared group key) and perform all operation on it or add more complicated scheme, due to its limitation on power and low processing capability. draft-daniel-6lowpan-security-analysis-01.txt is starting to define the 6lowpan threat model. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jul 10 20:01:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G05gp-00025l-VX; Mon, 10 Jul 2006 20:01:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G05gp-00025g-5P for 6lowpan@ietf.org; Mon, 10 Jul 2006 20:01:23 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G05gn-00085i-PJ for 6lowpan@ietf.org; Mon, 10 Jul 2006 20:01:23 -0400 Received: by ug-out-1314.google.com with SMTP id m3so199539uge for <6lowpan@ietf.org>; Mon, 10 Jul 2006 17:01:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RTRX0XEx2d1E2r8QLbL9ySch2wJMyWtaWSWyg4dHz5UZmcpvDIn8VTtUqy4ET7A+JHZPQae3p9bKepDuhSPvd1BuNlxjIeR/kdHcy6z4qjZB11ZfDnqiher/iicfxrQ17sjjrXnDhQLbDNuyf2s2ybXDsgYiZCUNJs0/NeFkTkA= Received: by 10.78.117.10 with SMTP id p10mr1927633huc; Mon, 10 Jul 2006 17:01:20 -0700 (PDT) Received: by 10.78.150.5 with HTTP; Mon, 10 Jul 2006 17:01:20 -0700 (PDT) Message-ID: <43b91d370607101701t81c6e34o51523ec37d7abb68@mail.gmail.com> Date: Mon, 10 Jul 2006 17:01:20 -0700 From: "Samita Chakrabarti" To: "Mayer Karl" Subject: Re: [6lowpan] 6lowpan-nd version 2 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43b91d370607071543m441b8ff9p7684211d6087c163@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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: , Errors-To: 6lowpan-bounces@ietf.org Hello Karl, On 7/10/06, Mayer Karl wrote: > > So you would conclude from the EUI-64 identifier of the link-local addres= s (received in the RS) also the non-link-local addresses, right? Yes. > This is only possible in case *all* IP addresses are constructed by conca= tenating the respective prefix with the EUI-64 identifier. However, draft-i= etf-6lowpan-format-03 leaves flexibility in the constructing of non-link-lo= cal IP addresses so I am not sure whether we can rely on this (or at least = we have to make this an requirement). I see your point. > Therefore my proposal was to send for each configured IPv6 address an NS = message to the PAN coordinator with the respective IPv6 address as source a= ddress and the Source Link Layer Address option. The destination address co= uld be any of the router's IPv6 addresses, the link-local address as well. > I got the idea. Will discuss with you further, before next revision of the draft. > >Do you have any idea to switch PAN co-ordinators at L2 layer? > >If so, we could link IPv6-router switch along with that. > > Not much about this is written in the IEEE 802.15.4-2003 standard and I h= ave no access to the IEEE 802.15.4b-2003 standard (and I don't think they s= olve this issue there). I assume 802.15.4 leaves it up to higher layers (e.= g. to the 6lowpan layer) to deal with PAN coordinator selection. When sendi= ng an Association Request message, a node can signal its wilingness to be a= n alternate PAN coordinator via a respective flag. Similar to other failove= r mechanisms, a PAN coordinator receiving such a message with the flag set = could subsequently send periodically an alive message just to his alternate= PAN coordinators. In case an alternate PAN coordinator does not receive an= alive message anymore it could perform an election process among all alter= nate PAN coordinators and become the PAN coordinator. Clearly, there are op= en issues and these are just first thoughts. OK. Thanks for explaining. Regards, -Samita > > > >> >-----Urspr=FCngliche Nachricht----- > >> >Von: Samita Chakrabarti [mailto:samitac2@gmail.com] > >> >Gesendet: Sonntag, 25. Juni 2006 01:30 > >> >An: 6lowpan@ietf.org > >> >Betreff: [6lowpan] 6lowpan-nd version 2 > >> > > >> >Erik and I have updated > >> >draft-chakrabarti-6lowpan-ipv6-nd-02.txt and submitted for > >> >publication. The new update includes a section on generic > >application > >> >of this draft for non-multicast, non-broadcast network. At the last > >> >wg meeting, the request was made for such an update for the Wimax > >> >effort on IPv6. > >> > > >> >Two questions to the working group and the chairs: > >> > > >> > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG > >> >document ? > >> > 2) Are we OK with publishing the draft as "IPv6 Neighbor > >Discovery > >> >Optimization > >> > for IEEE 802.15.4 and other non-multicast networks" > >so that it > >> >contains > >> > specifics on 6lowpan and a generic guideline for > >other relevant > >> >networks? > >> > > >> >Comments are welcome. > >> > > >> > > >> >- Samita > >> > > >> >_______________________________________________ > >> >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 Tue Jul 11 13:05:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Lg3-0006aD-P5; Tue, 11 Jul 2006 13:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Lg2-0006Yo-TP for 6lowpan@ietf.org; Tue, 11 Jul 2006 13:05:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0J8l-0000pL-Na for 6lowpan@ietf.org; Tue, 11 Jul 2006 10:23:07 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0J3w-0006a0-5j for 6lowpan@ietf.org; Tue, 11 Jul 2006 10:18:10 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 43896800089; Tue, 11 Jul 2006 17:18:02 +0300 (EEST) Date: Tue, 11 Jul 2006 17:18:02 +0300 (EEST) From: Wassim Haddad To: 6lowpan@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.6 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Wassim.Haddad@ericsson.com Subject: [6lowpan] ND Security Optimizations 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, Following the current discussion in the 6lopwan WG meeting, I'd like to mention the ongoing work on optimizing SEND (OptiSEND) protocol: draft-haddad-mipshop-optisend-01. Regards, Wassim H. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 12 10:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fuN-00012B-Em; Wed, 12 Jul 2006 10:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fuL-00011u-V2 for 6lowpan@ietf.org; Wed, 12 Jul 2006 10:41:45 -0400 Received: from nz-out-0102.google.com ([64.233.162.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fuJ-0008NW-MW for 6lowpan@ietf.org; Wed, 12 Jul 2006 10:41:45 -0400 Received: by nz-out-0102.google.com with SMTP id 16so138046nzp for <6lowpan@ietf.org>; Wed, 12 Jul 2006 07:41:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=edxPaSJBjqvyU60zU+7xqIU+NoCgvq0vYHbjAAgkElUPr9l13e/DYdX3804SbAo1MQPCUh0qMKv4bjiROVC6kxKG70UZ1d96y9nYJ++c8xb06JGwLajvffOBcpphVh9UeKhxxDGAZVx01cyn5pniH4Bf3X6T2Qc6f43klLeK2vg= Received: by 10.64.142.10 with SMTP id p10mr709889qbd; Wed, 12 Jul 2006 07:41:24 -0700 (PDT) Received: from ?132.219.12.241? ( [132.219.12.241]) by mx.gmail.com with ESMTP id e17sm462887qbe.2006.07.12.07.41.22; Wed, 12 Jul 2006 07:41:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: manet , 6lowpan <6lowpan@ietf.org> From: Ian Chakeres Date: Wed, 12 Jul 2006 10:41:06 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [6lowpan] Reminder: MANET July 13th 1pm Rm 515 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 Just a reminder that the MANET meeting will be tomorrow at 1pm. Please review the WG documents and be prepared to discuss them. http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-01.txt http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-05.txt http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-02.txt http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-02.txt Ian Chakeres The agenda and presentations will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jul 15 11:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mTo-0003p2-Be; Sat, 15 Jul 2006 11:54:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mTn-0003ol-1n for 6lowpan@lists.ietf.org; Sat, 15 Jul 2006 11:54:55 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1mTh-00088X-UH for 6lowpan@lists.ietf.org; Sat, 15 Jul 2006 11:54:53 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k6FFscDS029012 for <6lowpan@lists.ietf.org>; Sat, 15 Jul 2006 09:54:39 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: multipart/mixed; boundary="=-2i5rIiIe8wmn2JxmKfZg" Date: Sat, 15 Jul 2006 09:54:33 -0600 Message-Id: <1152978873.5044.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: cb256aa41b5300a7da304d7294799ef5 Cc: Subject: [6lowpan] modification to problem statement document 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 --=-2i5rIiIe8wmn2JxmKfZg Content-Type: text/plain Content-Transfer-Encoding: 7bit Here is the updated problem statement. The changes are to include the requirement to support mains and battery powered networks. Thanks Gabriel. geoff --=-2i5rIiIe8wmn2JxmKfZg Content-Disposition: attachment; filename=draft-ietf-6lowpan-problem-04.txt Content-Type: text/plain; name=draft-ietf-6lowpan-problem-04.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Network Working Group N. Kushalnagar Internet-Draft Intel Corp Expires: December 3, 2006 G. Montenegro Microsoft Corporation June 2006 6LoWPAN: Overview, Assumptions, Problem Statement and Goals draft-ietf-6lowpan-problem-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 3, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the assumptions, problem statement and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. Additional goals may be found necessary over time and may be added to this document. Kushalnagar & Montenegro Expires December 3, 2006 [Page 1] Internet-Draft 6lowpan Problems and Goals June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. IP Connectivity . . . . . . . . . . . . . . . . . . . . . 5 4.2. Topologies . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Limited Packet Size . . . . . . . . . . . . . . . . . . . 6 4.4. Limited configuration and management . . . . . . . . . . . 7 4.5. Service discovery . . . . . . . . . . . . . . . . . . . . 7 4.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Kushalnagar & Montenegro Expires December 3, 2006 [Page 2] Internet-Draft 6lowpan Problems and Goals June 2006 1. Introduction Low-power wireless personal area networks (LoWPANs) comprise devices that conform to the IEEE 802.15.4-2003 standard by the IEEE [ieee802.15.4]. IEEE 802.15.4 devices are characterized by short range, low bit rate, low power and low cost. This document gives an overview of LoWPANs and describes how they benefit from IP and IPv6 networking. It describes LoWPAN requirements with regards to the IP layer and above, and spells out the underlying assumptions of IP for LoWPANs. Finally, it describes problems associated with enabling IP communication between devices in a LoWPAN, and defines goals to address these in a prioritized manner. Admittedly, not all items on this list are necessarily appropriate tasks for the IETF. Nevertheless, they are documented here to give a general overview of the larger problem. This is useful both to structure work within the IETF as well as to understand better how to coordinate with external organizations. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Overview A LoWPAN is a simple low cost communication network that allows wireless connectivity in applications with limited power and relaxed throughput requirements. A LoWPAN typically includes devices that work together to connect the physical environment to real-world applications, e.g., wireless sensors. LoWPANs conform to the IEEE 802.15.4-2003 standard. [ieee802.15.4]. Some of the characteristics of LoWPANs are: 1. Small packet size. Given that the maximum physical layer packet is 127 bytes, the resulting maximum frame size at the media access control layer is 102 octets. Link-layer security imposes further overhead, which in the maximum case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 and AES-CCM-64, respectively) leaves 81 octets for data packets. 2. Support for both 16-bit short or IEEE 64-bit extended media access control addresses. Kushalnagar & Montenegro Expires December 3, 2006 [Page 3] Internet-Draft 6lowpan Problems and Goals June 2006 3. Low bandwidth. Data rates of 250 kbps, 40 kbps and 20 kbps for each of the currently defined physical layers (2.4 GHz, 915 MHz and 868 MHz, respectively). 4. Topologies include star and mesh operation. 5. Low power. Typically, some or all devices are battery operated. 6. Low cost. These devices are typically associated with sensors, switches, etc. This drives some of the other characteristics such as low processing, low memory, etc. Numerical values for "low" elided on purpose since costs tend to change over time. 7. Large number of devices expected to be deployed during the life- time of the technology. This number is expected to dwarf the number of deployed personal computers, for example. 8. Location of the devices is typically not predefined, as they tend to be deployed in an ad hoc fashion. Furthermore, sometimes the location of these devices may not be easily accessible. Additionally, these devices may move to new locations. 9. Devices within LoWPANs tend to be unreliable due to variety of reasons: uncertain radio connectivity, battery drain, device lockups, physical tampering, etc. 10. Devices within LoWPANs tend to be unavailable because they often are in sleep mode or in a power-down mode to conserve power. The following sections take into account these characteristics in describing the assumptions, problems statement and goals for LoWPANs, and, in particular, for 6LoWPANs (IPv6-based LoWPAN networks). 3. Assumptions Given the small packet size of LoWPANs, this document presumes applications typically send small amounts of data. However, the protocols themselves do not restrict bulk data transfers. LoWPANs as described in this document are based on IEEE 802.15.4- 2003. It is possible that the specification may undergo changes in the future and may change some of the requirements mentioned above. Some of these assumptions are based on the limited capabilities of devices within LoWPANs. As devices become more powerful, and consume Kushalnagar & Montenegro Expires December 3, 2006 [Page 4] Internet-Draft 6lowpan Problems and Goals June 2006 less power, some of the requirements mentioned above may be somewhat relaxed. While some LoWPAN devices are expected to be extremely limited (the so-called "Reduced Function Devices" or RFDs), more capable "Full Function Devices" (FFDs) will also be present, albeit in much smaller numbers. FFDs will typically have more resources and may be mains powered. Accordingly, FFDs will aid RFDs by providing functions such as network coordination, packet forwarding, interfacing with other types of networks, etc. The application of IP technology is assumed to provide the following benefits: 1. The pervasive nature of IP networks allows use of existing infrastructure. 2. IP-based technologies already exist, are well known and proven to be working. 3. An admittedly non-technical but important consideration is that intellectual property conditions for IP networking technology are either more favorable or at least better understood than proprietary and newer solutions. 4. Tools for diagnostics, management and commissioning of IP networks already exist. 5. IP-based devices can be connected readily to other IP-based networks, without the need for intermediate entities like translation gateways or proxies. 4. Problems Based on the characteristics defined in the overview section, the following sections elaborate on the main problems with IP for LoWPANs. 4.1. IP Connectivity The requirement for IP connectivity within a LoWPAN is driven by the following: 1. The many devices in a LoWPAN make network auto configuration and statelessness highly desirable. And for this, IPv6 has ready solutions. 2. The large number of devices poses the need for a large address space, well met by IPv6. 3. Given the limited packet size of LoWPANs, the IPv6 address format allows subsuming of IEEE 802.15.4 addresses if so desired. Kushalnagar & Montenegro Expires December 3, 2006 [Page 5] Internet-Draft 6lowpan Problems and Goals June 2006 4. Simple interconnectivity to other IP networks including the Internet. However, given the limited packet size, headers for IPv6 and layers above must be compressed whenever possible. 4.2. Topologies LoWPANs must support various topologies including mesh and star. Mesh topologies imply multi-hop routing, to a desired destination. In this case, intermediate devices act as packet forwarders at the link layer (akin to routers at the network layer). Typically these are "full function devices" that have more capabilities in terms of power, computation, etc. The requirements on the routing protocol are: 1. Given the minimal packet size of LoWPANs, the routing protocol must impose low (or no) overhead on data packets, hopefully independently of the number of hops. 2. The routing protocols should have low routing overhead (low chattiness) balanced with topology changes and power conservation. 3. The computation and memory requirements in the routing protocol should be minimal to satisfy the low cost and low power objectives. Thus, storage and maintenance of large routing tables is detrimental. 4. Support for network topologies in which either FFDs or RFDs may be battery or mains-powered. This implies the appropriate considerations for routing in the presence of sleeping nodes. As with mesh topologies, star topologies include provisioning a subset of devices with packet forwarding functionality. If, in addition to IEEE 802.15.4, these devices use other kinds of network interfaces such as ethernet or IEEE 802.11, the goal is to seamlessly integrate the networks built over those different technologies. This, of course, is a primary motivation to use IP to begin with. 4.3. Limited Packet Size Applications within LoWPANs are expected to originate small packets. Adding all layers for IP connectivity should still allow transmission in one frame without incurring excessive fragmentation and reassembly. Furthermore, protocols must be designed or chosen so that the individual "control/protocol packets" fit within a single 802.15.4 frame. Kushalnagar & Montenegro Expires December 3, 2006 [Page 6] Internet-Draft 6lowpan Problems and Goals June 2006 4.4. Limited configuration and management As alluded to above, devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work "out of the box", be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices. Network management should have little overhead yet be powerful enough to control dense deployment of devices. 4.5. Service discovery LoWPANs require simple service discovery network protocols to discover, control and maintain services provided by devices. In some cases, especially in dense deployments, abstraction of several nodes to provide a service may be beneficial. In order to enable such features, new protocols may have to be designed. 4.6. Security IEEE 802.15.4 mandates link-layer security based on AES, but it omits any details about topics like bootstrapping, key management and security at higher layers. Of course, a complete security solution for LoWPAN devices must consider application needs very carefully. Please refer to the security consideration section below for a more detailed discussion and in-depth security requirements. 5. Goals The goals mentioned below are general and not limited to IETF activities. As such, they may not only refer to work that can be done within the IETF (e.g., specification required to transmit IP, profile of best practices for transmitting IP packets, and associated upper level protocols, etc). They also point at work more relevant to other standards bodies (e.g., desirable changes to or profiles relevant to IEEE 802.15.4, W3C, etc). When the goals fall under the IETF's purview, they serve to point out what those efforts should strive to accomplish, regardless of whether they are pursued within one (or more) new (or existing) working groups. When the goals do not fall under the purview of the IETF, documenting them here serves as input to other organizations [liaison]. Note that a common underlying goal is to reduce packet overhead, bandwidth consumption, processing requirements and power consumption. Kushalnagar & Montenegro Expires December 3, 2006 [Page 7] Internet-Draft 6lowpan Problems and Goals June 2006 The following are the goals according to priority for LoWPANs: 1. Fragmentation and Reassembly layer: As mentioned in the overview, the protocol data units may be as small 81 bytes. This is obviously far below the minimum IPv6 packet size of 1280 octets, and in keeping with section 5 of the IPv6 specification [RFC2460], a fragmentation and reassembly adaptation layer must be provided at the layer below IP. 2. Header Compression: Given that in the worst case the maximum size available for transmitting IP packets over IEEE 802.15.4 frame is 81 octets, and that the IPv6 header is 40 octets long, (without optional headers), this leaves only 41 octets for upper-layer protocols, like UDP and TCP. UDP uses 8 octets in the header and TCP uses 20 octets. This leaves 33 octets for data over UDP and 21 octets for data over TCP. Additionally, as pointed above, there is also a need for a fragmentation and reassembly layer, which will use even more octets leaving very few octets for data. Thus if one were to use the protocols as is, it would lead to excessive fragmentation and reassembly even when data packets are just 10s of octets long. This points to the need for header compression. As there is much published and in-progress standardization work on header compression, the 6LoWPAN community needs to investigate using existing header compression techniques, and, if necessary, specify new ones. 3. Address Autoconfiguration: [I-D.ietf-ipv6-rfc2462bis] specifies methods for creating IPv6 stateless address auto configuration. Stateless auto configuration (as compared to stateful) is attractive for 6LoWPANs, because it reduces the configuration overhead on the hosts. There is a need for a method to generate an "interface identifier" from the EUI-64 [EUI64] assigned to the IEEE 802.15.4 device. 4. Mesh Routing Protocol: A routing protocol to support a multi-hop mesh network is necessary. There is much published work on adhoc multi hop routing for devices. Some examples include [RFC3561], [RFC3626], [RFC3684], all experimental. Also, these protocols are designed to use IP-based addresses that have large overheads. For example, the AODV [RFC3561] routing protocol uses 48 octets for a route request based on IPv6 addressing. Given the packet- size constraints, transmitting this packet without fragmentation and reassembly may be difficult. Thus, care should be taken when using existing routing protocols (or designing new ones) so that the routing packets fit within a single IEEE 802.15.4 frame. Kushalnagar & Montenegro Expires December 3, 2006 [Page 8] Internet-Draft 6lowpan Problems and Goals June 2006 5. Network Management: One of the points of transmitting IPv6 packets, is to reuse existing protocols as much as possible. Network management functionality is critical for LoWPANs. [RFC3411] specifies SNMPv3 protocol operations. SNMP functionality may be translated "as is" to LoWPANs. However, further investigation is required to determine if it is suitable, or if an appropriate adaption is in order. This adaptation could include limiting the data types and simplifying the Basic Encoding Rules so as to reduce the size and complexity of the ASN.1 parser, thereby reducing the memory and processing needs to better fit into the limited memory and power of LoWPAN devices. 6. Implementation Considerations: It may be the case that transmitting IP over IEEE 802.15.4 would become more beneficial if implemented in a "certain" way. Accordingly, implementation considerations are to be documented. 7. Application and higher layer Considerations: As header compression becomes more prevalent, overall performance will depend even more on efficiency of application protocols. Heavyweight protocols based on XML such as SOAP [SOAP], may not be suitable for LoWPANs. As such, more compact encodings (and perhaps protocols) may become necessary. The goal here is to specify or suggest modifications to existing protocols so that they are suitable for LoWPANs. Furthermore, application level interoperability specifications may also become necessary in the future and may thus be specified. 8. Security Considerations: Security threats at different layers must be clearly understood and documented. Bootstrapping of devices into a secure network could also be considered given the location, limited display, high density and ad hoc deployment of devices. 6. IANA Considerations This document contains no IANA considerations. 7. Security Considerations IPv6 over LoWPAN (6LoWPAN) applications often require confidentiality and integrity protection. This can be provided at the application, transport, network, and/or at the link layer (i.e., within the 6LoWPAN set of specifications). In all these cases, prevailing constraints will influence the choice of a particular protocol. Some of the more relevant constraints are small code size, low power Kushalnagar & Montenegro Expires December 3, 2006 [Page 9] Internet-Draft 6lowpan Problems and Goals June 2006 operation, low complexity, and small bandwidth requirements. Given these constraints, first, a threat model for 6LoWPAN devices needs to be developed in order to weigh any risks against the cost of their mitigations while making meaningful assumptions and simplifications. Some examples for threats that should be considered are man-in-the-middle attacks and denial of service attacks. A separate set of security considerations apply to bootstrapping a 6LoWPAN device into the network (e.g., for initial key establishment). This generally involves application level exchanges or out-of-band techniques for the initial key establishment, and may rely on application- specific trust models; thus, it is considered extraneous to 6LoWPAN and is not addressed in these specifications. In order to be able to select (or design) this next set of protocols, there needs to be a common model of the keying material created by the initial key establishment. Beyond initial key establishment, protocols for subsequent key management as well as to secure the data traffic do fall under the purview of 6LoWPAN. Here, the different alternatives (TLS, IKE/ IPsec, etc.) must be evaluated in light of the 6LoWPAN constraints. One argument for using link layer security is that most IEEE 802.15.4 devices already have support for AES link-layer security. AES is a block cipher operating on blocks of fixed length, i.e., 128 bits. To encrypt longer messages, several modes of operation may be used. The earliest modes described, such as ECB, CBC, OFB and CFB provide only confidentiality, and this does not ensure message integrity. Other modes have been designed which ensure both confidentiality and message integrity, such as CCM* mode. 6LoWPAN networks can operate in any of the previous modes, but it is desirable to utilize the most secure modes available for link-layer security (e.g., CCM*), and build upon it. For network layer security, two models are applicable: end-to-end security, e.g. using IPsec transport mode, or security that is limited to the wireless portion of the network, e.g. using a security gateway and IPsec tunnel mode. The disadvantage of the latter is the larger header size, which is significant at the 6LoWPAN frame MTUs. To simplify 6LoWPAN implementations, it is beneficial to identify the relevant security model, and to identify a preferred set of cipher suites that are appropriate given the constraints. 8. Acknowledgements Thanks to Geoff Mulligan, Soohong Daniel Park, Samita Chakrabarti and Kushalnagar & Montenegro Expires December 3, 2006 [Page 10] Internet-Draft 6lowpan Problems and Goals June 2006 Brijesh Kumar for their comments and help in shaping this document. 9. References 9.1. Normative References [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html. [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-07 (work in progress), May 2006. [I-D.ietf-ipv6-rfc2462bis] Thomson, S., "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08 (work in progress), May 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003. 9.2. Informative References [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004. Kushalnagar & Montenegro Expires December 3, 2006 [Page 11] Internet-Draft 6lowpan Problems and Goals June 2006 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [SOAP] "SOAP", W3C http://www.w3c.org/2000/xp/Group/. [liaison] "LIASONS", IETF http://www.ietf.org/liaisonActivities.html. Kushalnagar & Montenegro Expires December 3, 2006 [Page 12] Internet-Draft 6lowpan Problems and Goals June 2006 Authors' Addresses Nandakishore Kushalnagar Intel Corp Email: nandakishore.kushalnagar@intel.com Gabriel Montenegro Microsoft Corporation Email: gabriel_montenegro_2000@yahoo.com Kushalnagar & Montenegro Expires December 3, 2006 [Page 13] Internet-Draft 6lowpan Problems and Goals June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kushalnagar & Montenegro Expires December 3, 2006 [Page 14] --=-2i5rIiIe8wmn2JxmKfZg 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 --=-2i5rIiIe8wmn2JxmKfZg-- From 6lowpan-bounces@ietf.org Mon Jul 17 13:48:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2XCi-00022Z-V8; Mon, 17 Jul 2006 13:48:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2XCh-00022S-JR for 6lowpan@lists.ietf.org; Mon, 17 Jul 2006 13:48:23 -0400 Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2XCg-0003Ht-9g for 6lowpan@lists.ietf.org; Mon, 17 Jul 2006 13:48:23 -0400 Received: (qmail 81195 invoked by uid 60001); 17 Jul 2006 17:48:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=voOlszQMUkaPZyYyHVfUrC2YVkDm5bOKU8JmrhMMKYHbdWQpTHDHRRcndkxAssvdpY1b+avojXbB02jNy/E2z8pT+poneBnvL3rEP9ENQZP/E/7ZaRoYyVnMs1atDH8z3KS4zEbI9Q7+Oc5KPhCk3+S22J3apEH7I+ntg5Jog6E= ; Message-ID: <20060717174816.81193.qmail@web81903.mail.mud.yahoo.com> Received: from [64.213.152.82] by web81903.mail.mud.yahoo.com via HTTP; Mon, 17 Jul 2006 10:48:16 PDT Date: Mon, 17 Jul 2006 10:48:16 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] modification to problem statement document To: Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org> In-Reply-To: <1152978873.5044.2.camel@localhost> MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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="===============1326212601==" Errors-To: 6lowpan-bounces@ietf.org --===============1326212601== Content-Type: multipart/alternative; boundary="0-2125120650-1153158496=:79018" Content-Transfer-Encoding: 8bit --0-2125120650-1153158496=:79018 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Just to be clear. The version of the ID sent by Geoff in the previous message was a proposal as to how to accomodate the suggested changes. It has not yet been submitted to the I-D repository. I'll do that tomororrow Tuesday, just to have one more day for folks to look it over. The changes were: Section 3 added the word "may" in this sentence: "FFDs will typically have more resources and may be mains powered. " New bullet 4 in section 4.2: 4. Support for network topologies in which either FFDs or RFDs may be battery or mains-powered. This implies the appropriate considerations for routing in the presence of sleeping nodes. -gabriel Geoff Mulligan wrote: Here is the updated problem statement. The changes are to include the requirement to support mains and battery powered networks. Thanks Gabriel. geoff --0-2125120650-1153158496=:79018 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Just to be clear. The version of the ID sent by Geoff in the previous message was
a proposal as to how to accomodate the suggested changes. It has not yet been
submitted to the I-D repository. I'll do that tomororrow Tuesday, just to have one more
day for folks to look it over.
 
The changes were:
 
Section 3 added the word "may" in this sentence:
 
"FFDs will typically have more resources and may be mains
   powered. "
 
New bullet 4 in section 4.2:
 
   4.  Support for network topologies in which either FFDs or RFDs may
       be battery or mains-powered.  This implies the appropriate
       considerations for routing in the presence of sleeping nodes.
 
-gabriel

Geoff Mulligan <geoff@mulligan.com> wrote:
Here is the updated problem statement. The changes are to include the
requirement to support mains and battery powered networks.

Thanks Gabriel.

geoff
--0-2125120650-1153158496=:79018-- --===============1326212601== 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 --===============1326212601==-- From 6lowpan-bounces@ietf.org Wed Jul 19 00:26:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33dl-0003qP-Ez; Wed, 19 Jul 2006 00:26:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33dj-0003fj-Qt for 6lowpan@ietf.org; Wed, 19 Jul 2006 00:26:27 -0400 Received: from web81906.mail.mud.yahoo.com ([68.142.207.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G33di-00075n-H9 for 6lowpan@ietf.org; Wed, 19 Jul 2006 00:26:27 -0400 Received: (qmail 14771 invoked by uid 60001); 19 Jul 2006 04:26:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=It7XtKxwSZSj6wGeSYNUEkeKYSjWGQoAtoUpOXZg4uy2SY2rCGYhRmK6KHJmHPcXENxqVF/MQ3nKbHduXQTyxITTYCC2EJIteylK+3ci+lQRaREiWJqWzU/Xu3VJj8ulxJX9+XB1tItzffqPnuPrqP3YZ3PSp0Q0RZGbAViH56Q= ; Message-ID: <20060719042625.14769.qmail@web81906.mail.mud.yahoo.com> Received: from [64.213.152.82] by web81906.mail.mud.yahoo.com via HTTP; Tue, 18 Jul 2006 21:26:25 PDT Date: Tue, 18 Jul 2006 21:26:25 -0700 (PDT) From: gabriel montenegro To: 6lowpan@ietf.org, Geoff Mulligan , Carsten Bormann MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [6lowpan] problem statement document rev04 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============1546884720==" Errors-To: 6lowpan-bounces@ietf.org --===============1546884720== Content-Type: multipart/alternative; boundary="0-138618593-1153283185=:14765" --0-138618593-1153283185=:14765 Content-Type: text/plain; charset=us-ascii FYI: I've submitted to the internet-drafts repository. I think we'll be ready to advance to IESG as soon as it appears published. thanks, -gabriel --0-138618593-1153283185=:14765 Content-Type: text/html; charset=us-ascii
FYI: I've submitted to the internet-drafts repository. I think we'll be ready to advance to IESG as soon as it appears published.
 
thanks,
 
-gabriel
--0-138618593-1153283185=:14765-- --===============1546884720== 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 --===============1546884720==-- From 6lowpan-bounces@ietf.org Wed Jul 19 00:27:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33f7-0004rc-4D; Wed, 19 Jul 2006 00:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33f6-0004rX-3Z for 6lowpan@ietf.org; Wed, 19 Jul 2006 00:27:52 -0400 Received: from web81907.mail.mud.yahoo.com ([68.142.207.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G33f4-00079l-Qb for 6lowpan@ietf.org; Wed, 19 Jul 2006 00:27:52 -0400 Received: (qmail 23630 invoked by uid 60001); 19 Jul 2006 04:27:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=tD+bYhXfCfKE1dKSPaHSl+QSXP0ls5ESq5f2wSliB360w7g+IK+i0FU4/e8Bpja0X3aDgED/T8OydTDkH00S+hUg7cryQkwKSj2ZXQEM5ZIX+UxQPAC+RN9WN8UPWcg9xswDQ6TJXDUGxYoDNHbpL7rU+jhr7Vr2X0Te3A6XQao= ; Message-ID: <20060719042750.23628.qmail@web81907.mail.mud.yahoo.com> Received: from [64.213.152.82] by web81907.mail.mud.yahoo.com via HTTP; Tue, 18 Jul 2006 21:27:50 PDT Date: Tue, 18 Jul 2006 21:27:50 -0700 (PDT) From: gabriel montenegro To: 6lowpan@ietf.org, Geoff Mulligan , Carsten Bormann MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [6lowpan] format document X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============0508650775==" Errors-To: 6lowpan-bounces@ietf.org --===============0508650775== Content-Type: multipart/alternative; boundary="0-142861018-1153283270=:23573" --0-142861018-1153283270=:23573 Content-Type: text/plain; charset=us-ascii Esteemed Chairs, As we discussed during the meeting last week, this document is ready for WG last call. I hereby request that you issue the WG last call. thanks, -gabriel --0-142861018-1153283270=:23573 Content-Type: text/html; charset=us-ascii
Esteemed Chairs,
 
As we discussed during the meeting last week, this document is ready for WG last call.
I hereby request that you issue the WG last call.
 
thanks,
 
-gabriel
--0-142861018-1153283270=:23573-- --===============0508650775== 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 --===============0508650775==-- From 6lowpan-bounces@ietf.org Wed Jul 19 00:30:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33ha-0005MC-2g; Wed, 19 Jul 2006 00:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33hY-0005LT-OZ for 6lowpan@ietf.org; Wed, 19 Jul 2006 00:30:24 -0400 Received: from web81910.mail.mud.yahoo.com ([68.142.207.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G33hX-0007Mj-Es for 6lowpan@ietf.org; Wed, 19 Jul 2006 00:30:24 -0400 Received: (qmail 29723 invoked by uid 60001); 19 Jul 2006 04:30:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Z98xQQmlR6npwL/rBRIhGQqOrb+7w7uT0A1yjZLiKTX9dTwQojl/Dx3+KmUwnB14CUeegKF4Jur+roRuBWb0CqGN6DGfwBj2pj5fAEYvxzxck5NJznZJQCxCi6EczzqlBgCpO9wX2aJnG0Vsk+svM6+QZ1sqMDTZUaldhapGP/I= ; Message-ID: <20060719043022.29721.qmail@web81910.mail.mud.yahoo.com> Received: from [64.213.152.82] by web81910.mail.mud.yahoo.com via HTTP; Tue, 18 Jul 2006 21:30:22 PDT Date: Tue, 18 Jul 2006 21:30:22 -0700 (PDT) From: gabriel montenegro To: 6lowpan@ietf.org, Geoff Mulligan , Carsten Bormann MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [6lowpan] updating twiki X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============0032961720==" Errors-To: 6lowpan-bounces@ietf.org --===============0032961720== Content-Type: multipart/alternative; boundary="0-1182944822-1153283422=:27955" --0-1182944822-1153283422=:27955 Content-Type: text/plain; charset=us-ascii Esteemed Chairs, As per last week's meeting discussion, here are two items suggested with respect to the twiki 6lowpan page: 1. Add a link to the 6lowpan twiki page from the 6lowpan page at tools.ietf.org (similar to what the NETLMM folks did). 2. update the 6lowpan twiki page with the info on our past interim meeting. thanks, -gabriel --0-1182944822-1153283422=:27955 Content-Type: text/html; charset=us-ascii
Esteemed Chairs,
 
As per last week's meeting discussion, here are two items suggested with respect to the twiki 6lowpan page:
 
1. Add a link to the 6lowpan twiki page from the 6lowpan page at tools.ietf.org (similar to what the NETLMM folks did).
2. update the 6lowpan twiki page with the info on our past interim meeting.
 
thanks,
 
-gabriel
--0-1182944822-1153283422=:27955-- --===============0032961720== 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 --===============0032961720==-- From 6lowpan-bounces@ietf.org Wed Jul 19 15:50:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I3a-0002k2-Jh; Wed, 19 Jul 2006 15:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I3Y-0002jW-H1; Wed, 19 Jul 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3I3Y-0003CB-6g; Wed, 19 Jul 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6JJo1p0032216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3I3V-0006GY-TV; Wed, 19 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 19 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-problem-04.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low power WPAN Working Group of the IETF. Title : 6LoWPAN: Overview, Assumptions, Problem Statement and Goals Author(s) : N. Kushalnagar, G. Montenegro Filename : draft-ietf-6lowpan-problem-04.txt Pages : 14 Date : 2006-7-19 This document describes the assumptions, problem statement and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. Additional goals may be found necessary over time and may be added to this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.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-ietf-6lowpan-problem-04.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-ietf-6lowpan-problem-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-19144016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-problem-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-problem-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-19144016.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From 6lowpan-bounces@ietf.org Wed Jul 19 17:30:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JcF-0007Rk-Az; Wed, 19 Jul 2006 17:29:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JcE-0007Re-8c for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 17:29:58 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3JcB-0002xg-T5 for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 17:29:58 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k6JLTqjd020889 for <6lowpan@lists.ietf.org>; Wed, 19 Jul 2006 15:29:52 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Wed, 19 Jul 2006 15:29:49 -0600 Message-Id: <1153344589.4878.38.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [6lowpan] WG Last call on Problem Statement Document 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 Folks, This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions, Problem Statement and Goals". The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt The document is intended to be submitted by this Working Group to the IESG for publication as an Informational Document. Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. This Last Call will end on Wednesday 02 August 2006 at 2359 UTC. Thanks, Geoff & Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 19 17:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JfL-0007lj-IL; Wed, 19 Jul 2006 17:33:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JfK-0007le-NU for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 17:33:10 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3JfJ-00034c-9F for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 17:33:10 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k6JLX8U1020920 for <6lowpan@lists.ietf.org>; Wed, 19 Jul 2006 15:33:08 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Wed, 19 Jul 2006 15:33:05 -0600 Message-Id: <1153344785.4878.41.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [6lowpan] WG Last Call on Format Document 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 Folks, This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-format-03, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks draft-ietf-6lowpan-format-03". The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-03.txt The document is intended to be submitted by this Working Group to the IESG for publication as an Proposed Standard Document. Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. This Last Call will end on Wednesday 02 August 2006 at 2359 UTC. Thanks, Geoff & Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 19 18:01:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3K7A-0003Yr-AS; Wed, 19 Jul 2006 18:01:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3K79-0003Y6-KN for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 18:01:55 -0400 Received: from web81915.mail.mud.yahoo.com ([68.142.207.63]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3JuQ-0004W9-PU for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 17:48:49 -0400 Received: (qmail 69017 invoked by uid 60001); 19 Jul 2006 21:48:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=wvrHen9dSKjS/cy56q0Efc2ditlkhpSpB898x4h6S3J7N2PgL0J+B+wJSiwjem8rNeY+P4ZRqKChRlDtazJ+d4tFNgJvCoyxSFLplrgbHIkrr66prB51vyBfMoOor6Ub+2eYh11t3SyddHWJy3D+uAXjwa25TXHPbh69cj+2QrY= ; Message-ID: <20060719214846.69015.qmail@web81915.mail.mud.yahoo.com> Received: from [64.213.152.82] by web81915.mail.mud.yahoo.com via HTTP; Wed, 19 Jul 2006 14:48:46 PDT Date: Wed, 19 Jul 2006 14:48:46 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] WG Last call on Problem Statement Document To: Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org> In-Reply-To: <1153344589.4878.38.camel@localhost> MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============0100276747==" Errors-To: 6lowpan-bounces@ietf.org --===============0100276747== Content-Type: multipart/alternative; boundary="0-1999257766-1153345726=:68003" --0-1999257766-1153345726=:68003 Content-Type: text/plain; charset=us-ascii Hi Geoff, This document had already gone thruogh WG last call. The changes done were as a result of that. So wouldn't the draft now be ready to be sent to the IESG? tnx,. -gabriel ----- Original Message ---- From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Sent: Wednesday, July 19, 2006 2:29:49 PM Subject: [6lowpan] WG Last call on Problem Statement Document Folks, This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions, Problem Statement and Goals". The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt The document is intended to be submitted by this Working Group to the IESG for publication as an Informational Document. Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. This Last Call will end on Wednesday 02 August 2006 at 2359 UTC. Thanks, Geoff & Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-1999257766-1153345726=:68003 Content-Type: text/html; charset=us-ascii
Hi Geoff,
 
This document had already gone thruogh WG last call. The changes done were as a result of that.
So wouldn't the draft now be ready to be sent to the IESG?
 
tnx,.
 
-gabriel
 


 
----- Original Message ----
From: Geoff Mulligan <geoff@mulligan.com>
To: 6lowpan <6lowpan@lists.ietf.org>
Sent: Wednesday, July 19, 2006 2:29:49 PM
Subject: [6lowpan] WG Last call on Problem Statement Document

Folks,
  This note formally starts the WG Last Call for comments on
draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions,
Problem Statement and Goals".

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt

The document is intended to be submitted by this Working Group to the
IESG for publication as an Informational Document.

Please review the document carefully (one last time), and send your
comments to the 6lowpan list.  Please also indicate in your response
whether or not you think this document is ready to go to the IESG.

This Last Call will end on Wednesday 02 August 2006 at 2359 UTC.

    Thanks,
        Geoff & Carsten



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

--0-1999257766-1153345726=:68003-- --===============0100276747== 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 --===============0100276747==-- From 6lowpan-bounces@ietf.org Wed Jul 19 18:02:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3K7K-0003fM-Ue; Wed, 19 Jul 2006 18:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3K7K-0003dx-9N for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 18:02:06 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3K7I-0005WT-T8 for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 18:02:06 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k6JM24AL021094; Wed, 19 Jul 2006 16:02:04 -0600 (MDT) Subject: Re: [6lowpan] WG Last call on Problem Statement Document From: Geoff Mulligan To: gabriel montenegro In-Reply-To: <20060719214846.69015.qmail@web81915.mail.mud.yahoo.com> References: <20060719214846.69015.qmail@web81915.mail.mud.yahoo.com> Content-Type: text/plain Date: Wed, 19 Jul 2006 16:02:01 -0600 Message-Id: <1153346521.4878.49.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Gabriel, In our discussions and the limited feedback that we originally received from the working group, we felt that since it didn't make sense to send one document without the other to the IESG that we would err on the side of greater opportunity and call a WG last call on both documents. geoff On Wed, 2006-07-19 at 14:48 -0700, gabriel montenegro wrote: > Hi Geoff, > > This document had already gone thruogh WG last call. The changes done > were as a result of that. > So wouldn't the draft now be ready to be sent to the IESG? > > tnx,. > > -gabriel > > > > > ----- Original Message ---- > From: Geoff Mulligan > To: 6lowpan <6lowpan@lists.ietf.org> > Sent: Wednesday, July 19, 2006 2:29:49 PM > Subject: [6lowpan] WG Last call on Problem Statement Document > > Folks, > This note formally starts the WG Last Call for comments on > draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions, > Problem Statement and Goals". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > This Last Call will end on Wednesday 02 August 2006 at 2359 UTC. > > Thanks, > Geoff & Carsten > > > > _______________________________________________ > 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 Wed Jul 19 19:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3L6R-00026h-QB; Wed, 19 Jul 2006 19:05:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3L6P-00026Z-UX for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 19:05:13 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3L6N-0002Ua-Ee for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 19:05:13 -0400 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J2O001I2ASLXR@mailout2.samsung.com> for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 08:05:09 +0900 (KST) Received: from your655e9d6f61 ([124.235.139.2]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J2O00DXLASJ6E@mmp2.samsung.com> for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 08:05:09 +0900 (KST) Date: Wed, 19 Jul 2006 16:05:04 -0700 From: Soohong Daniel Park Subject: Re: [6lowpan] WG Last Call on Format Document To: Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org> Message-id: <00b601c6ab87$c6d377c0$028beb7c@your655e9d6f61> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1153344785.4878.41.camel@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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, As I pointed out in Montreal, Figure 8 and 9 must be clarified to have Non-Compressed fields which is not limited length. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC1 encoding | Non-Compressed fields follow... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: LOWPAN_HC1 (common compressed header encoding) CHANGE TO: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC1 encoding | Non-Compressed fields follow... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |HC_UDP encoding| Fields carried in-line follow... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: HC_UDP (UDP common compressed header encoding) CHANGE TO: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |HC_UDP encoding| Fields carried in-line follow... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Otherwise, I believe it is ready to the IESG. Good job. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Geoff Mulligan" To: "6lowpan" <6lowpan@lists.ietf.org> Sent: Wednesday, July 19, 2006 2:33 PM Subject: [6lowpan] WG Last Call on Format Document > Folks, > This note formally starts the WG Last Call for comments on > draft-ietf-6lowpan-format-03, "Transmission of IPv6 Packets over IEEE > 802.15.4 Networks draft-ietf-6lowpan-format-03". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-03.txt > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Proposed Standard Document. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > This Last Call will end on Wednesday 02 August 2006 at 2359 UTC. > > Thanks, > Geoff & Carsten > > > > _______________________________________________ > 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 Wed Jul 19 19:15:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LGi-0003PP-N5; Wed, 19 Jul 2006 19:15:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LGh-0003PK-4p for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 19:15:51 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3LGf-0003zb-Mx for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 19:15:51 -0400 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J2O00C9FBACKP@mailout2.samsung.com> for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 08:15:48 +0900 (KST) Received: from your655e9d6f61 ([124.235.139.2]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J2O00DUIBA96E@mmp2.samsung.com> for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 08:15:47 +0900 (KST) Date: Wed, 19 Jul 2006 16:07:18 -0700 From: Soohong Daniel Park Subject: Re: [6lowpan] WG Last call on Problem Statement Document To: Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org> Message-id: <00f001c6ab89$436b1bc0$028beb7c@your655e9d6f61> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1153344589.4878.38.camel@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Seems really odd. Is it a second WGLC ? Anyhow, I believe it is ready to the IESG, Good job. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Geoff Mulligan" To: "6lowpan" <6lowpan@lists.ietf.org> Sent: Wednesday, July 19, 2006 2:29 PM Subject: [6lowpan] WG Last call on Problem Statement Document > Folks, > This note formally starts the WG Last Call for comments on > draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions, > Problem Statement and Goals". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > This Last Call will end on Wednesday 02 August 2006 at 2359 UTC. > > Thanks, > Geoff & Carsten > > > > _______________________________________________ > 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 Wed Jul 19 19:25:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LQM-0004L5-1U; Wed, 19 Jul 2006 19:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LQK-0004Ks-I3 for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 19:25:48 -0400 Received: from web81913.mail.mud.yahoo.com ([68.142.207.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3LQJ-00053Q-EO for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 19:25:48 -0400 Received: (qmail 40880 invoked by uid 60001); 19 Jul 2006 23:25:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=C/4uGno1TGbDeAt/JI3dvr3sUCj1NmRO1nyqsiUhEkt08DPPkzRpPZFAJRfBy9T9kZn0fv4cj517CcGgEE74WWA9CSSRJUEimIb0esX2prQdp4PaOcX2RxNWOjJnY6nL5FuiZb7z/hpu17/3yX6UxtLWtkgDQ4iySmrWzCfBpx4= ; Message-ID: <20060719232547.40878.qmail@web81913.mail.mud.yahoo.com> Received: from [64.213.152.82] by web81913.mail.mud.yahoo.com via HTTP; Wed, 19 Jul 2006 16:25:47 PDT Date: Wed, 19 Jul 2006 16:25:47 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] WG Last Call on Format Document To: Soohong Daniel Park , Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org> In-Reply-To: <00b601c6ab87$c6d377c0$028beb7c@your655e9d6f61> MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============1194904711==" Errors-To: 6lowpan-bounces@ietf.org --===============1194904711== Content-Type: multipart/alternative; boundary="0-178507401-1153351547=:39115" --0-178507401-1153351547=:39115 Content-Type: text/plain; charset=us-ascii Yes. I actually did that change in the draft already as a result of your pointing this out. But this is so minor, and I expect that during WG LC we will get more comments, that I have not submitted the version with this minor fix. -gabriel ----- Original Message ---- From: Soohong Daniel Park To: Geoff Mulligan ; 6lowpan <6lowpan@lists.ietf.org> Sent: Wednesday, July 19, 2006 4:05:04 PM Subject: Re: [6lowpan] WG Last Call on Format Document Gabriel, As I pointed out in Montreal, Figure 8 and 9 must be clarified to have Non-Compressed fields which is not limited length. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC1 encoding | Non-Compressed fields follow... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: LOWPAN_HC1 (common compressed header encoding) CHANGE TO: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC1 encoding | Non-Compressed fields follow... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |HC_UDP encoding| Fields carried in-line follow... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: HC_UDP (UDP common compressed header encoding) CHANGE TO: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |HC_UDP encoding| Fields carried in-line follow... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Otherwise, I believe it is ready to the IESG. Good job. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Geoff Mulligan" To: "6lowpan" <6lowpan@lists.ietf.org> Sent: Wednesday, July 19, 2006 2:33 PM Subject: [6lowpan] WG Last Call on Format Document > Folks, > This note formally starts the WG Last Call for comments on > draft-ietf-6lowpan-format-03, "Transmission of IPv6 Packets over IEEE > 802.15.4 Networks draft-ietf-6lowpan-format-03". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-03.txt > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Proposed Standard Document. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > This Last Call will end on Wednesday 02 August 2006 at 2359 UTC. > > Thanks, > Geoff & Carsten > > > > _______________________________________________ > 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 --0-178507401-1153351547=:39115 Content-Type: text/html; charset=us-ascii
Yes. I actually did that change in the draft already as a result of your pointing this out.
But this is so minor, and I expect that during WG LC we will get more comments, that I
have not submitted the version with this minor fix.
 
-gabriel

----- Original Message ----
From: Soohong Daniel Park <soohong.park@samsung.com>
To: Geoff Mulligan <geoff@mulligan.com>; 6lowpan <6lowpan@lists.ietf.org>
Sent: Wednesday, July 19, 2006 4:05:04 PM
Subject: Re: [6lowpan] WG Last Call on Format Document

Gabriel,

As I pointed out in Montreal, Figure 8 and 9 must
be clarified to have Non-Compressed fields which
is not limited length.


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC1 encoding  |     Non-Compressed fields follow...           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: LOWPAN_HC1 (common compressed header encoding)

CHANGE TO:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC1 encoding  |     Non-Compressed fields follow...          
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|HC_UDP encoding|     Fields carried in-line follow...          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: HC_UDP (UDP common compressed header encoding)

CHANGE TO:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|HC_UDP encoding|     Fields carried in-line follow...          
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Otherwise, I believe it is ready to the IESG. Good job.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

----- Original Message -----
From: "Geoff Mulligan" <geoff@mulligan.com>
To: "6lowpan" <6lowpan@lists.ietf.org>
Sent: Wednesday, July 19, 2006 2:33 PM
Subject: [6lowpan] WG Last Call on Format Document


> Folks,
>  This note formally starts the WG Last Call for comments on
> draft-ietf-6lowpan-format-03, "Transmission of IPv6 Packets over IEEE
> 802.15.4 Networks draft-ietf-6lowpan-format-03".
>
> The document can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-03.txt
>
> The document is intended to be submitted by this Working Group to the
> IESG for publication as an Proposed Standard Document.
>
> Please review the document carefully (one last time), and send your
> comments to the 6lowpan list.  Please also indicate in your response
> whether or not you think this document is ready to go to the IESG.
>
> This Last Call will end on Wednesday 02 August 2006 at 2359 UTC.
>
>        Thanks,
>                Geoff & Carsten
>
>
>
> _______________________________________________
> 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

--0-178507401-1153351547=:39115-- --===============1194904711== 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 --===============1194904711==-- From 6lowpan-bounces@ietf.org Wed Jul 19 19:29:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LTm-0005DU-M5; Wed, 19 Jul 2006 19:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LTm-0005DP-4C for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 19:29:22 -0400 Received: from web81912.mail.mud.yahoo.com ([68.142.207.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3LTj-0005H2-KW for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 19:29:22 -0400 Received: (qmail 58297 invoked by uid 60001); 19 Jul 2006 23:28:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=heaDZ3JFyKb5lTmrxf0TuOkNUMTUSgHnulF7K99jFR02T7Cxg/aNKcDGGDW/7oeFuRznleGHQk224oq/F5zKJ7wkIoZVQOsIj9/jyQTyt4idiCksYpGYjr5AN59scaQnR4j1MjVHtn9hlJdPcrGZ5RC6jSq6Bf2Hgv6WIVFQE8w= ; Message-ID: <20060719232839.58295.qmail@web81912.mail.mud.yahoo.com> Received: from [64.213.152.82] by web81912.mail.mud.yahoo.com via HTTP; Wed, 19 Jul 2006 16:28:39 PDT Date: Wed, 19 Jul 2006 16:28:39 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] WG Last call on Problem Statement Document To: Geoff Mulligan In-Reply-To: <1153346521.4878.49.camel@localhost> MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============0887510756==" Errors-To: 6lowpan-bounces@ietf.org --===============0887510756== Content-Type: multipart/alternative; boundary="0-1443123832-1153351719=:54632" --0-1443123832-1153351719=:54632 Content-Type: text/plain; charset=us-ascii I guess that would argue for (1) *not* advancing the prob statement until the format document catches up (and then advancing both in lockstep), not necessarily for (2) issuing another WG LC on the prob statement. The latter seems superfluous. -gabriel ----- Original Message ---- From: Geoff Mulligan To: gabriel montenegro Cc: 6lowpan <6lowpan@lists.ietf.org> Sent: Wednesday, July 19, 2006 3:02:01 PM Subject: Re: [6lowpan] WG Last call on Problem Statement Document Gabriel, In our discussions and the limited feedback that we originally received from the working group, we felt that since it didn't make sense to send one document without the other to the IESG that we would err on the side of greater opportunity and call a WG last call on both documents. geoff On Wed, 2006-07-19 at 14:48 -0700, gabriel montenegro wrote: > Hi Geoff, > > This document had already gone thruogh WG last call. The changes done > were as a result of that. > So wouldn't the draft now be ready to be sent to the IESG? > > tnx,. > > -gabriel > > > > > ----- Original Message ---- > From: Geoff Mulligan > To: 6lowpan <6lowpan@lists.ietf.org> > Sent: Wednesday, July 19, 2006 2:29:49 PM > Subject: [6lowpan] WG Last call on Problem Statement Document > > Folks, > This note formally starts the WG Last Call for comments on > draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions, > Problem Statement and Goals". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > This Last Call will end on Wednesday 02 August 2006 at 2359 UTC. > > Thanks, > Geoff & Carsten > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > --0-1443123832-1153351719=:54632 Content-Type: text/html; charset=us-ascii
I guess that would argue for (1) *not* advancing the prob statement until the format document catches up
(and then advancing both in lockstep), not necessarily for (2) issuing another WG LC on the prob statement.
The latter seems superfluous.
 
-gabriel

----- Original Message ----
From: Geoff Mulligan <geoff@mulligan.com>
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Cc: 6lowpan <6lowpan@lists.ietf.org>
Sent: Wednesday, July 19, 2006 3:02:01 PM
Subject: Re: [6lowpan] WG Last call on Problem Statement Document

Gabriel,
  In our discussions and the limited feedback that we originally
received from the working group, we felt that since it didn't make sense
to send one document without the other to the IESG that we would err on
the side of greater opportunity and call a WG last call on both
documents.

    geoff

On Wed, 2006-07-19 at 14:48 -0700, gabriel montenegro wrote:
> Hi Geoff,
>  
> This document had already gone thruogh WG last call. The changes done
> were as a result of that.
> So wouldn't the draft now be ready to be sent to the IESG?
>  
> tnx,.
>  
> -gabriel
>  
>
>
>  
> ----- Original Message ----
> From: Geoff Mulligan <geoff@mulligan.com>
> To: 6lowpan <6lowpan@lists.ietf.org>
> Sent: Wednesday, July 19, 2006 2:29:49 PM
> Subject: [6lowpan] WG Last call on Problem Statement Document
>
> Folks,
>   This note formally starts the WG Last Call for comments on
> draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions,
> Problem Statement and Goals".
>
> The document can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt
>
> The document is intended to be submitted by this Working Group to the
> IESG for publication as an Informational Document.
>
> Please review the document carefully (one last time), and send your
> comments to the 6lowpan list.  Please also indicate in your response
> whether or not you think this document is ready to go to the IESG.
>
> This Last Call will end on Wednesday 02 August 2006 at 2359 UTC.
>
>     Thanks,
>         Geoff & Carsten
>
>
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>

--0-1443123832-1153351719=:54632-- --===============0887510756== 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 --===============0887510756==-- From 6lowpan-bounces@ietf.org Wed Jul 19 19:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Lus-0000Tv-GO; Wed, 19 Jul 2006 19:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Luq-0000SU-Sg for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 19:57:20 -0400 Received: from agp.stanford.edu ([171.67.73.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Lup-0001Bq-Ib for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 19:57:20 -0400 Received: from 66-7-230-34.static-ip.telepacific.net ([66.7.230.34] helo=[64.60.253.163]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1G3Lul-0001YY-BB; Wed, 19 Jul 2006 16:57:16 -0700 In-Reply-To: <1153344589.4878.38.camel@localhost> References: <1153344589.4878.38.camel@localhost> 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: Philip Levis Subject: Re: [6lowpan] WG Last call on Problem Statement Document Date: Wed, 19 Jul 2006 15:34:17 -0700 To: Geoff Mulligan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -8.2 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 On Jul 19, 2006, at 2:29 PM, Geoff Mulligan wrote: > Folks, > This note formally starts the WG Last Call for comments on > draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions, > Problem Statement and Goals". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. One consideration and one question about an implication. Both stem from the scarcity of storage (RAM or non-volatile) on many of these devices, due to power and cost considerations. Consideration: the draft acknowledges that LowPAN devices may be deployed in large numbers (possibly in high density) but require low- state/low-overhead protocols. It might be useful to make this statement a little stronger, and comment that protocols which require state for every "neighbor" (whatever that means) are not feasible. Rather, protocols which can scale to different degrees of accuracy (e.g., I can store 10% of the neighbors, vs. 50%) are preferred. Otherwise, you have a box with 10,000 nodes in it and the protocols collapse. Question: The requirement for fragmentation and assembly below IP, given the minimum packet size of 1280 octets, seems to preclude most devices that have, e.g., 2K of RAM and no other feasible storage medium. I don't mean to suggest that this limitation on scope or statement of requirements is a problem: you have to cut the line somewhere. Rather, would making this explicit be helpful? Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jul 19 23:10:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3OvV-0005x4-4f; Wed, 19 Jul 2006 23:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3OvU-0005v2-Cd for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 23:10:12 -0400 Received: from web60320.mail.yahoo.com ([209.73.178.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3OvT-0007Kj-VE for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 23:10:12 -0400 Received: (qmail 69438 invoked by uid 60001); 20 Jul 2006 03:10:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Cxjz3CqvgPJJ7hXRU7AM9KETqGZFPe4mPDnC7J2fYR/gEqXQWbkxNseQPhR+UepGFRu2WD8MuqCdlsVTONWoEgoReFG2jBAy0n0IssNP3EvQJ/1EkpucncAxNS6QPvTVNO3XOtQP9RJWgWA3m+RLsyn++9uc3LP90Z33/e0afW4= ; Message-ID: <20060720031006.69436.qmail@web60320.mail.yahoo.com> Received: from [67.166.240.5] by web60320.mail.yahoo.com via HTTP; Wed, 19 Jul 2006 20:10:06 PDT Date: Wed, 19 Jul 2006 20:10:06 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [6lowpan] WG Last call on Problem Statement Document To: Philip Levis , Geoff Mulligan In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya 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="===============1952466347==" Errors-To: 6lowpan-bounces@ietf.org --===============1952466347== Content-Type: multipart/alternative; boundary="0-1645459501-1153365006=:67298" --0-1645459501-1153365006=:67298 Content-Type: text/plain; charset=us-ascii I agree with Phil, I think we should have his consideration considered seriously. Regarding his question, in the format draft, 802.15.4 MAC layer is assumed and the frame sizes are from IEEE standard. This WG assumes that even the light sensors support 802.15.4 MAC (kind of like Telos motes). In that sense this WG is addressing futuristic sensor nodes on which IP stack can be implemented. How close that future be, we do not know. Regards, Behcet ----- Original Message ---- From: Philip Levis To: Geoff Mulligan Cc: 6lowpan <6lowpan@lists.ietf.org> Sent: Wednesday, July 19, 2006 5:34:17 PM Subject: Re: [6lowpan] WG Last call on Problem Statement Document On Jul 19, 2006, at 2:29 PM, Geoff Mulligan wrote: > Folks, > This note formally starts the WG Last Call for comments on > draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions, > Problem Statement and Goals". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. One consideration and one question about an implication. Both stem from the scarcity of storage (RAM or non-volatile) on many of these devices, due to power and cost considerations. Consideration: the draft acknowledges that LowPAN devices may be deployed in large numbers (possibly in high density) but require low- state/low-overhead protocols. It might be useful to make this statement a little stronger, and comment that protocols which require state for every "neighbor" (whatever that means) are not feasible. Rather, protocols which can scale to different degrees of accuracy (e.g., I can store 10% of the neighbors, vs. 50%) are preferred. Otherwise, you have a box with 10,000 nodes in it and the protocols collapse. Question: The requirement for fragmentation and assembly below IP, given the minimum packet size of 1280 octets, seems to preclude most devices that have, e.g., 2K of RAM and no other feasible storage medium. I don't mean to suggest that this limitation on scope or statement of requirements is a problem: you have to cut the line somewhere. Rather, would making this explicit be helpful? Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-1645459501-1153365006=:67298 Content-Type: text/html; charset=us-ascii
I agree with Phil, I think we should have his consideration considered seriously.
Regarding his question, in the format draft, 802.15.4 MAC layer is assumed and the frame sizes are from IEEE standard. This WG assumes that even the light sensors support 802.15.4 MAC (kind of like Telos motes). In that sense this WG is addressing futuristic sensor nodes on which IP stack can be implemented. How close that future be, we do not know.

Regards,

Behcet

----- Original Message ----
From: Philip Levis <pal@cs.stanford.edu>
To: Geoff Mulligan <geoff@mulligan.com>
Cc: 6lowpan <6lowpan@lists.ietf.org>
Sent: Wednesday, July 19, 2006 5:34:17 PM
Subject: Re: [6lowpan] WG Last call on Problem Statement Document

On Jul 19, 2006, at 2:29 PM, Geoff Mulligan wrote:

> Folks,
>   This note formally starts the WG Last Call for comments on
> draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions,
> Problem Statement and Goals".
>
> The document can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt
>
> The document is intended to be submitted by this Working Group to the
> IESG for publication as an Informational Document.
>
> Please review the document carefully (one last time), and send your
> comments to the 6lowpan list.  Please also indicate in your response
> whether or not you think this document is ready to go to the IESG.

One consideration and one question about an implication. Both stem  
from the scarcity of storage (RAM or non-volatile) on many of these  
devices, due to power and cost considerations.

Consideration: the draft acknowledges that LowPAN devices may be  
deployed in large numbers (possibly in high density) but require low-
state/low-overhead protocols. It might be useful to make this  
statement a little stronger, and comment that protocols which require  
state for every "neighbor" (whatever that means) are not feasible.  
Rather, protocols which can scale to different degrees of accuracy  
(e.g., I can store 10% of the neighbors, vs. 50%) are preferred.  
Otherwise, you have a box with 10,000 nodes in it and the protocols  
collapse.

Question: The requirement for fragmentation and assembly below IP,  
given the minimum packet size of 1280 octets, seems to preclude most  
devices that have, e.g., 2K of RAM and no other feasible storage  
medium. I don't mean to suggest that this limitation on scope or  
statement of requirements is a problem: you have to cut the line  
somewhere. Rather, would making this explicit be helpful?

Phil

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

--0-1645459501-1153365006=:67298-- --===============1952466347== 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 --===============1952466347==-- From 6lowpan-bounces@ietf.org Wed Jul 19 23:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3PV9-0005Ti-PW; Wed, 19 Jul 2006 23:47:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3PV8-0005Td-Vm for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 23:47:02 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3PV7-00021s-GB for 6lowpan@lists.ietf.org; Wed, 19 Jul 2006 23:47:02 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2O006S9O9HX2@szxga03-in.huawei.com> for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 11:56:05 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2O001EDO9H17@szxga03-in.huawei.com> for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 11:56:05 +0800 (CST) Received: from l47967 ([10.111.12.93]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2O00J7YNXFZB@szxml03-in.huawei.com> for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 11:48:54 +0800 (CST) Date: Thu, 20 Jul 2006 11:46:14 +0800 From: Hui Liu To: 6lowpan@lists.ietf.org Message-id: <016d01c6abaf$0cfe80b0$5d0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acarrwy7DjdDH17BT3CG6lEyMgRP8g== X-Spam-Score: 0.5 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: Subject: [6lowpan] unsubsribe 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 unsubsribe _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 20 12:15:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bB1-0003HI-Mc; Thu, 20 Jul 2006 12:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bAz-0003FC-SA for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 12:15:01 -0400 Received: from agp.stanford.edu ([171.67.73.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3bAy-0001oQ-Hy for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 12:15:01 -0400 Received: from dnab42230a.stanford.edu ([171.66.35.10]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1G3bAt-0000fY-1H; Thu, 20 Jul 2006 09:14:57 -0700 In-Reply-To: <20060720031006.69436.qmail@web60320.mail.yahoo.com> References: <20060720031006.69436.qmail@web60320.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28F1AB75-E294-4290-89FE-E7CE580F126C@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] WG Last call on Problem Statement Document Date: Thu, 20 Jul 2006 08:52:49 -0700 To: Behcet Sarikaya X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -108.2 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 On Jul 19, 2006, at 8:10 PM, Behcet Sarikaya wrote: > I agree with Phil, I think we should have his consideration > considered seriously. > Regarding his question, in the format draft, 802.15.4 MAC layer is > assumed and the frame sizes are from IEEE standard. This WG assumes > that even the light sensors support 802.15.4 MAC (kind of like > Telos motes). In that sense this WG is addressing futuristic sensor > nodes on which IP stack can be implemented. How close that future > be, we do not know. > You can totally write an IP stack -- even a TCP stack -- on sensor nodes today, admittedly the ones that have the biggest microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP stack might not have a lot of RAM for windowing and high performance, but that's rarely the goal. You can do it. I don't think the requirements the document implies are unrealistic or onerous. As I said, you have to cut the line somewhere. My comment was just that they *do* preclude smaller nodes whose storage cannot hold a complete IPv6 packet, and it might be useful to note as such, since the document is defining the problem statement, and therefore the problem scope. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 20 15:35:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3eIX-00070T-GZ; Thu, 20 Jul 2006 15:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3eIW-0006uw-2D for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 15:35:00 -0400 Received: from mga05.intel.com ([192.55.52.89] helo=fmsmga101.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3eIT-00078s-In for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 15:35:00 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 20 Jul 2006 12:34:56 -0700 Received: from azsmsx334.amr.corp.intel.com ([10.2.121.57]) by fmsmga001.fm.intel.com with ESMTP; 20 Jul 2006 12:34:56 -0700 X-IronPort-AV: i="4.07,163,1151910000"; d="txt'208?scan'208,208"; a="101297561:sNHT34609141" Received: from azsmsx331.amr.corp.intel.com ([10.2.161.41]) by azsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 12:34:55 -0700 Received: from mail pickup service by azsmsx331.amr.corp.intel.com with Microsoft SMTPSVC; Thu, 20 Jul 2006 12:34:54 -0700 Received: from orsmsx312.amr.corp.intel.com ([192.168.65.62]) by azsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 13:05:01 -0700 Received: from orsmsx334.amr.corp.intel.com ([10.22.226.45]) by orsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Jul 2006 13:04:59 -0700 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 13:04:59 -0700 Received: from orsmga101.jf.intel.com ([10.7.208.22]) by orsmga001.jf.intel.com with ESMTP; 19 Jul 2006 12:50:47 -0700 Received: from stiedprmman1.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by orsmga101.jf.intel.com with ESMTP; 19 Jul 2006 12:50:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,260,1149490800"; d="txt'208?scan'208,208"; a="92436436:sNHT38954832" Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I3b-0002kG-OT; Wed, 19 Jul 2006 15:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I3Y-0002jW-H1; Wed, 19 Jul 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3I3Y-0003CB-6g; Wed, 19 Jul 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6JJo1p0032216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3I3V-0006GY-TV; Wed, 19 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 19 Jul 2006 15:50:01 -0400 X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 19 Jul 2006 20:04:59.0806 (UTC) FILETIME=[9D2863E0:01C6AB6E] X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-problem-04.txt X-BeenThere: 6lowpan@ietf.org Reply-To: internet-drafts@ietf.org 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low power WPAN Working Group of the IETF. Title : 6LoWPAN: Overview, Assumptions, Problem Statement and Goals Author(s) : N. Kushalnagar, G. Montenegro Filename : draft-ietf-6lowpan-problem-04.txt Pages : 14 Date : 2006-7-19 This document describes the assumptions, problem statement and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. Additional goals may be found necessary over time and may be added to this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.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-ietf-6lowpan-problem-04.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-ietf-6lowpan-problem-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-19144016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-problem-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-problem-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-19144016.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart 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 --NextPart-- From 6lowpan-bounces@ietf.org Thu Jul 20 16:16:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ex2-0006eJ-QK; Thu, 20 Jul 2006 16:16:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ex2-0006dm-3h for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 16:16:52 -0400 Received: from web60312.mail.yahoo.com ([209.73.178.135]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3elY-0002uJ-OT for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 16:05:02 -0400 Received: (qmail 94521 invoked by uid 60001); 20 Jul 2006 20:05:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LlhaGHzjIgSDtIbRtBHsbXPg3v1XZjrdM6u8HUgL+GD5YajRa4RFoWOHgzRApsInFoYOH86eYbf/pXHEJUYih+/JzAZVNDcOxj7Jh30DwKrIK3+Y/oC+sGNQleXfwXL0qxIG8HyFyKkoL4PGa8f+SP5CrpMqGlEVZXPMd5w+NnI= ; Message-ID: <20060720200500.94519.qmail@web60312.mail.yahoo.com> Received: from [12.129.211.52] by web60312.mail.yahoo.com via HTTP; Thu, 20 Jul 2006 13:05:00 PDT Date: Thu, 20 Jul 2006 13:05:00 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [6lowpan] WG Last call on Problem Statement Document To: Philip Levis , Behcet Sarikaya In-Reply-To: <28F1AB75-E294-4290-89FE-E7CE580F126C@cs.stanford.edu> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya 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="===============1794161229==" Errors-To: 6lowpan-bounces@ietf.org --===============1794161229== Content-Type: multipart/alternative; boundary="0-1691164134-1153425900=:94130" --0-1691164134-1153425900=:94130 Content-Type: text/plain; charset=us-ascii OK, I think Phil is commenting on: This is obviously far below the minimum IPv6 packet size of 1280 octets, 1280 octets is not necessarily the minimum IPv6 packet size, but you can set 1280 as the MTU size which would mean the maximum packet size. This point is clear in the format draft, draft-ietf-6lowpan-format-03.txt but it should be clarified in the PS draft as well. Regards, Behcet ----- Original Message ---- From: Philip Levis To: Behcet Sarikaya Cc: Geoff Mulligan ; 6lowpan <6lowpan@lists.ietf.org> Sent: Thursday, July 20, 2006 10:52:49 AM Subject: Re: [6lowpan] WG Last call on Problem Statement Document On Jul 19, 2006, at 8:10 PM, Behcet Sarikaya wrote: > I agree with Phil, I think we should have his consideration > considered seriously. > Regarding his question, in the format draft, 802.15.4 MAC layer is > assumed and the frame sizes are from IEEE standard. This WG assumes > that even the light sensors support 802.15.4 MAC (kind of like > Telos motes). In that sense this WG is addressing futuristic sensor > nodes on which IP stack can be implemented. How close that future > be, we do not know. > You can totally write an IP stack -- even a TCP stack -- on sensor nodes today, admittedly the ones that have the biggest microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP stack might not have a lot of RAM for windowing and high performance, but that's rarely the goal. You can do it. I don't think the requirements the document implies are unrealistic or onerous. As I said, you have to cut the line somewhere. My comment was just that they *do* preclude smaller nodes whose storage cannot hold a complete IPv6 packet, and it might be useful to note as such, since the document is defining the problem statement, and therefore the problem scope. Phil --0-1691164134-1153425900=:94130 Content-Type: text/html; charset=us-ascii
OK, I think Phil is commenting on:
This is obviously far below the minimum IPv6 packet size of 1280 octets,

1280 octets is not necessarily the minimum IPv6 packet size, but you can set 1280 as the MTU size which would mean the maximum packet size.
This point is clear in the format draft, draft-ietf-6lowpan-format-03.txt but it should be clarified in the PS draft as well.

Regards,

Behcet

----- Original Message ----
From: Philip Levis <pal@cs.stanford.edu>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: Geoff Mulligan <geoff@mulligan.com>; 6lowpan <6lowpan@lists.ietf.org>
Sent: Thursday, July 20, 2006 10:52:49 AM
Subject: Re: [6lowpan] WG Last call on Problem Statement Document

On Jul 19, 2006, at 8:10 PM, Behcet Sarikaya wrote:

> I agree with Phil, I think we should have his consideration  
> considered seriously.
> Regarding his question, in the format draft, 802.15.4 MAC layer is  
> assumed and the frame sizes are from IEEE standard. This WG assumes  
> that even the light sensors support 802.15.4 MAC (kind of like  
> Telos motes). In that sense this WG is addressing futuristic sensor  
> nodes on which IP stack can be implemented. How close that future  
> be, we do not know.
>

You can totally write an IP stack -- even a TCP stack -- on sensor  
nodes today, admittedly the ones that have the biggest  
microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP  
stack might not have a lot of RAM for windowing and high performance,  
but that's rarely the goal.  You can do it.

I don't think the requirements the document implies are unrealistic  
or onerous. As I said, you have to cut the line somewhere. My comment  
was just that they *do* preclude smaller nodes whose storage cannot  
hold a complete IPv6 packet, and it might be useful to note as such,  
since the document is defining the problem statement, and therefore  
the problem scope.

Phil




--0-1691164134-1153425900=:94130-- --===============1794161229== 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 --===============1794161229==-- From 6lowpan-bounces@ietf.org Thu Jul 20 16:40:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fJa-0007vT-6R; Thu, 20 Jul 2006 16:40:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fIx-0006zc-8p for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 16:39:31 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3fC4-0006VD-2R for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 16:32:25 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k6KKW9EF026959; Thu, 20 Jul 2006 14:32:10 -0600 (MDT) Subject: Re: [6lowpan] WG Last call on Problem Statement Document From: Geoff Mulligan To: Philip Levis In-Reply-To: <28F1AB75-E294-4290-89FE-E7CE580F126C@cs.stanford.edu> References: <20060720031006.69436.qmail@web60320.mail.yahoo.com> <28F1AB75-E294-4290-89FE-E7CE580F126C@cs.stanford.edu> Content-Type: text/plain Date: Thu, 20 Jul 2006 14:32:12 -0600 Message-Id: <1153427533.4878.79.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 On Thu, 2006-07-20 at 08:52 -0700, Philip Levis wrote: > On Jul 19, 2006, at 8:10 PM, Behcet Sarikaya wrote: > > > I agree with Phil, I think we should have his consideration > > considered seriously. > > Regarding his question, in the format draft, 802.15.4 MAC layer is > > assumed and the frame sizes are from IEEE standard. This WG assumes > > that even the light sensors support 802.15.4 MAC (kind of like > > Telos motes). In that sense this WG is addressing futuristic sensor > > nodes on which IP stack can be implemented. How close that future > > be, we do not know. > > > > You can totally write an IP stack -- even a TCP stack -- on sensor > nodes today, admittedly the ones that have the biggest > microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP > stack might not have a lot of RAM for windowing and high performance, > but that's rarely the goal. You can do it. We have already built an 802.15.4MAC/AODVtiny/IPv6/UDP stack that will run on a 64K part and, with some optimization in the MAC, should run on a 32K part. For a non-routing node (read RFD) it should run on a 16K part! As Phil rightly points out, RAM is actually more of a constraint. > > I don't think the requirements the document implies are unrealistic > or onerous. As I said, you have to cut the line somewhere. My comment > was just that they *do* preclude smaller nodes whose storage cannot > hold a complete IPv6 packet, and it might be useful to note as such, > since the document is defining the problem statement, and therefore > the problem scope. There certainly could be a problem for very small parts (ie those with very limited RAM - 2k) where it could be nearly impossible for the device to store a complete 1280 byte IPv6 packet, but I think with some judicious use of memory it might be doable even on a 2k ram device so long as it isn't trying to maintain routing tables. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 20 17:44:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gJc-0005WK-2B; Thu, 20 Jul 2006 17:44:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gIM-0003uk-Qm for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 17:42:58 -0400 Received: from agp.stanford.edu ([171.67.73.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3g7m-0001kR-Ti for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 17:32:05 -0400 Received: from dnab42230a.stanford.edu ([171.66.35.10]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1G3g7k-0000aI-Mo; Thu, 20 Jul 2006 14:32:02 -0700 In-Reply-To: <1153427533.4878.79.camel@localhost> References: <20060720031006.69436.qmail@web60320.mail.yahoo.com> <28F1AB75-E294-4290-89FE-E7CE580F126C@cs.stanford.edu> <1153427533.4878.79.camel@localhost> 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: Philip Levis Subject: Re: [6lowpan] WG Last call on Problem Statement Document Date: Thu, 20 Jul 2006 14:31:57 -0700 To: Geoff Mulligan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -108.2 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 26b8f8cb9d50f38c95a96ded60a4c5d6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 On Jul 20, 2006, at 1:32 PM, Geoff Mulligan wrote: > On Thu, 2006-07-20 at 08:52 -0700, Philip Levis wrote: >> On Jul 19, 2006, at 8:10 PM, Behcet Sarikaya wrote: >> >>> I agree with Phil, I think we should have his consideration >>> considered seriously. >>> Regarding his question, in the format draft, 802.15.4 MAC layer is >>> assumed and the frame sizes are from IEEE standard. This WG assumes >>> that even the light sensors support 802.15.4 MAC (kind of like >>> Telos motes). In that sense this WG is addressing futuristic sensor >>> nodes on which IP stack can be implemented. How close that future >>> be, we do not know. >>> >> >> You can totally write an IP stack -- even a TCP stack -- on sensor >> nodes today, admittedly the ones that have the biggest >> microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP >> stack might not have a lot of RAM for windowing and high performance, >> but that's rarely the goal. You can do it. > > We have already built an 802.15.4MAC/AODVtiny/IPv6/UDP stack that will > run on a 64K part and, with some optimization in the MAC, should > run on > a 32K part. For a non-routing node (read RFD) it should run on a 16K > part! As Phil rightly points out, RAM is actually more of a > constraint. > 16K RAM or program memory? If RAM, it sounds like you're talking about an ARM or an MCU with an external memory attachment. The largest microcontroller (not microprocessor) I know of is the MSP430F1611, with 10K. Are there others? I'm sure you could easily do all of those things in much less than 16K of RAM. If you're talking about program memory, yeah, 32K sounds right, and 16K would be really squeaking it in. >> >> I don't think the requirements the document implies are unrealistic >> or onerous. As I said, you have to cut the line somewhere. My comment >> was just that they *do* preclude smaller nodes whose storage cannot >> hold a complete IPv6 packet, and it might be useful to note as such, >> since the document is defining the problem statement, and therefore >> the problem scope. > > There certainly could be a problem for very small parts (ie those with > very limited RAM - 2k) where it could be nearly impossible for the > device to store a complete 1280 byte IPv6 packet, but I think with > some > judicious use of memory it might be doable even on a 2k ram device so > long as it isn't trying to maintain routing tables. OK, we can quibble about where the line is (2K, 1K, 1.5K, 1529 bytes, etc), but I think the point remains: there will be devices that cannot receive complete IPv6 packets, and will therefore either be precluded from interoperability or require breaking the end-to-end argument by fragmenting and reassembly at the IP layer (not below, as the draft mentions). Anyways, I guess the question is whether the WG feels that mentioning this constraint is important enough to include in the document. Sounds like opinion is mixed. Given that it's such a minor point, I don't think it's a big deal if it's not included; I just think its presence would help define the problem space a little bit more precisely. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 20 18:06:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3geq-0003Wo-Pq; Thu, 20 Jul 2006 18:06:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3geo-0003V9-MA for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 18:06:10 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3gVY-0004R0-1r for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 17:56:37 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k6KLuTnW027462; Thu, 20 Jul 2006 15:56:29 -0600 (MDT) Subject: Re: [6lowpan] WG Last call on Problem Statement Document From: Geoff Mulligan To: Philip Levis In-Reply-To: References: <20060720031006.69436.qmail@web60320.mail.yahoo.com> <28F1AB75-E294-4290-89FE-E7CE580F126C@cs.stanford.edu> <1153427533.4878.79.camel@localhost> Content-Type: text/plain Date: Thu, 20 Jul 2006 15:56:34 -0600 Message-Id: <1153432594.4878.88.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 On Thu, 2006-07-20 at 14:31 -0700, Philip Levis wrote: > On Jul 20, 2006, at 1:32 PM, Geoff Mulligan wrote: > > > On Thu, 2006-07-20 at 08:52 -0700, Philip Levis wrote: > >> On Jul 19, 2006, at 8:10 PM, Behcet Sarikaya wrote: > >> > >>> I agree with Phil, I think we should have his consideration > >>> considered seriously. > >>> Regarding his question, in the format draft, 802.15.4 MAC layer is > >>> assumed and the frame sizes are from IEEE standard. This WG assumes > >>> that even the light sensors support 802.15.4 MAC (kind of like > >>> Telos motes). In that sense this WG is addressing futuristic sensor > >>> nodes on which IP stack can be implemented. How close that future > >>> be, we do not know. > >>> > >> > >> You can totally write an IP stack -- even a TCP stack -- on sensor > >> nodes today, admittedly the ones that have the biggest > >> microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP > >> stack might not have a lot of RAM for windowing and high performance, > >> but that's rarely the goal. You can do it. > > > > We have already built an 802.15.4MAC/AODVtiny/IPv6/UDP stack that will > > run on a 64K part and, with some optimization in the MAC, should > > run on > > a 32K part. For a non-routing node (read RFD) it should run on a 16K > > part! As Phil rightly points out, RAM is actually more of a > > constraint. > > > > 16K RAM or program memory? If RAM, it sounds like you're talking > about an ARM or an MCU with an external memory attachment. The > largest microcontroller (not microprocessor) I know of is the > MSP430F1611, with 10K. Are there others? I'm sure you could easily do > all of those things in much less than 16K of RAM. > > If you're talking about program memory, yeah, 32K sounds right, and > 16K would be really squeaking it in. We have the code currently running on a 64K flash part with 4K of ram. The biggest problem we are seeing with 16k flash parts is that they generally only have 2K (max) of ram. This is critically small for buffer space. > > > >> > >> I don't think the requirements the document implies are unrealistic > >> or onerous. As I said, you have to cut the line somewhere. My comment > >> was just that they *do* preclude smaller nodes whose storage cannot > >> hold a complete IPv6 packet, and it might be useful to note as such, > >> since the document is defining the problem statement, and therefore > >> the problem scope. > > > > There certainly could be a problem for very small parts (ie those with > > very limited RAM - 2k) where it could be nearly impossible for the > > device to store a complete 1280 byte IPv6 packet, but I think with > > some > > judicious use of memory it might be doable even on a 2k ram device so > > long as it isn't trying to maintain routing tables. > > OK, we can quibble about where the line is (2K, 1K, 1.5K, 1529 bytes, > etc), but I think the point remains: there will be devices that > cannot receive complete IPv6 packets, and will therefore either be > precluded from interoperability or require breaking the end-to-end > argument by fragmenting and reassembly at the IP layer (not below, as > the draft mentions). How does ip fragmentation "break" end-to-end? > > Anyways, I guess the question is whether the WG feels that mentioning > this constraint is important enough to include in the document. > Sounds like opinion is mixed. Given that it's such a minor point, I > don't think it's a big deal if it's not included; I just think its > presence would help define the problem space a little bit more > precisely. > > Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 20 18:23:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gvw-0007vo-Ad; Thu, 20 Jul 2006 18:23:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gvv-0007vj-85 for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 18:23:51 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3gvt-0006TR-RH for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 18:23:51 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k6KMNkA3027672; Thu, 20 Jul 2006 16:23:46 -0600 (MDT) Subject: Re: [6lowpan] WG Last call on Problem Statement Document From: Geoff Mulligan To: Behcet Sarikaya In-Reply-To: <20060720031006.69436.qmail@web60320.mail.yahoo.com> References: <20060720031006.69436.qmail@web60320.mail.yahoo.com> Content-Type: text/plain Date: Thu, 20 Jul 2006 16:23:51 -0600 Message-Id: <1153434231.4878.98.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Behcet, Just to be clear - the future is now. We have and others have implemented IPv6 on 802.15.4 - it works and is deployed. Our stack is not yet 6lowpan compliant in that our frame format is not the same as 6lowpan but this is a small tweak. geoff On Wed, 2006-07-19 at 20:10 -0700, Behcet Sarikaya wrote: > I agree with Phil, I think we should have his consideration considered > seriously. > Regarding his question, in the format draft, 802.15.4 MAC layer is > assumed and the frame sizes are from IEEE standard. This WG assumes > that even the light sensors support 802.15.4 MAC (kind of like Telos > motes). In that sense this WG is addressing futuristic sensor nodes on > which IP stack can be implemented. How close that future be, we do not > know. > > Regards, > > Behcet > > ----- Original Message ---- > From: Philip Levis > To: Geoff Mulligan > Cc: 6lowpan <6lowpan@lists.ietf.org> > Sent: Wednesday, July 19, 2006 5:34:17 PM > Subject: Re: [6lowpan] WG Last call on Problem Statement Document > > On Jul 19, 2006, at 2:29 PM, Geoff Mulligan wrote: > > > Folks, > > This note formally starts the WG Last Call for comments on > > draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions, > > Problem Statement and Goals". > > > > The document can be found at: > > > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt > > > > The document is intended to be submitted by this Working Group to > the > > IESG for publication as an Informational Document. > > > > Please review the document carefully (one last time), and send your > > comments to the 6lowpan list. Please also indicate in your response > > whether or not you think this document is ready to go to the IESG. > > One consideration and one question about an implication. Both stem > from the scarcity of storage (RAM or non-volatile) on many of these > devices, due to power and cost considerations. > > Consideration: the draft acknowledges that LowPAN devices may be > deployed in large numbers (possibly in high density) but require low- > state/low-overhead protocols. It might be useful to make this > statement a little stronger, and comment that protocols which > require > state for every "neighbor" (whatever that means) are not feasible. > Rather, protocols which can scale to different degrees of accuracy > (e.g., I can store 10% of the neighbors, vs. 50%) are preferred. > Otherwise, you have a box with 10,000 nodes in it and the protocols > collapse. > > Question: The requirement for fragmentation and assembly below IP, > given the minimum packet size of 1280 octets, seems to preclude most > devices that have, e.g., 2K of RAM and no other feasible storage > medium. I don't mean to suggest that this limitation on scope or > statement of requirements is a problem: you have to cut the line > somewhere. Rather, would making this explicit be helpful? > > Phil > > _______________________________________________ > 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 Thu Jul 20 18:31:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3h2y-0005Mr-Fd; Thu, 20 Jul 2006 18:31:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3h2y-0005Mm-3P for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 18:31:08 -0400 Received: from agp.stanford.edu ([171.67.73.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3h2w-00072Q-RW for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 18:31:08 -0400 Received: from dnab42230a.stanford.edu ([171.66.35.10]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1G3h2v-0002cf-G6; Thu, 20 Jul 2006 15:31:06 -0700 In-Reply-To: <1153432594.4878.88.camel@localhost> References: <20060720031006.69436.qmail@web60320.mail.yahoo.com> <28F1AB75-E294-4290-89FE-E7CE580F126C@cs.stanford.edu> <1153427533.4878.79.camel@localhost> <1153432594.4878.88.camel@localhost> 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: Philip Levis Subject: Re: [6lowpan] WG Last call on Problem Statement Document Date: Thu, 20 Jul 2006 15:31:05 -0700 To: Geoff Mulligan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -108.2 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 4c7a780eb20f40a19c8376fd8d8b00d5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 On Jul 20, 2006, at 2:56 PM, Geoff Mulligan wrote: > > How does ip fragmentation "break" end-to-end? I think I was unclear and miswrote; since you cannot receive the complete IP-level packet, you cannot receive the complete packet from the L4+ protocol. Therefore the L4+ protocol needs to break its packet up into finer parts. E.g., rather than break a single UDP packet into multiple IP fragments, you might actually have to break it up into multiple UDP packets. But since it's end-to-end fragmentation/assembly anyway, I guess this isn't a big deal. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jul 20 23:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3lKG-0001Lk-Gp; Thu, 20 Jul 2006 23:05:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3lKE-0001Le-CH for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 23:05:14 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3lKD-0004hB-2Q for 6lowpan@lists.ietf.org; Thu, 20 Jul 2006 23:05:14 -0400 Received: by nf-out-0910.google.com with SMTP id k26so841656nfc for <6lowpan@lists.ietf.org>; Thu, 20 Jul 2006 20:05:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fnB4/fcXnys8NbZS45Fsd6unO4obZ4xd4gu7pxfRIPhJVCBu4C3wZLRrbRtAWQ7Fhtw/dBr7ubCT9ud2NCfPml4bPZ3fD+xXm8Hn4WdZTMumVukBwZkLdDKaH/okvQ7ls+rXvCNHk93FiiGDBzMlAT5vETFy9C6CWp7PlE2gu7U= Received: by 10.78.166.7 with SMTP id o7mr74436hue; Thu, 20 Jul 2006 20:05:12 -0700 (PDT) Received: by 10.78.147.18 with HTTP; Thu, 20 Jul 2006 20:05:12 -0700 (PDT) Message-ID: <43b91d370607202005n76793ae8r6badccba4a1c6810@mail.gmail.com> Date: Thu, 20 Jul 2006 20:05:12 -0700 From: "Samita Chakrabarti" To: "Philip Levis" Subject: Re: [6lowpan] WG Last call on Problem Statement Document In-Reply-To: <28F1AB75-E294-4290-89FE-E7CE580F126C@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060720031006.69436.qmail@web60320.mail.yahoo.com> <28F1AB75-E294-4290-89FE-E7CE580F126C@cs.stanford.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 On 7/20/06, Philip Levis wrote: > You can totally write an IP stack -- even a TCP stack -- on sensor > nodes today, admittedly the ones that have the biggest > microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP > stack might not have a lot of RAM for windowing and high performance, > but that's rarely the goal. You can do it. > > I don't think the requirements the document implies are unrealistic > or onerous. As I said, you have to cut the line somewhere. My comment > was just that they *do* preclude smaller nodes whose storage cannot > hold a complete IPv6 packet, and it might be useful to note as such, > since the document is defining the problem statement, and therefore > the problem scope. > Your point is valid. Though IMHO, drawing a strict line on non-applicability on low RAM devices may not be wise. But I do agree that having a few lines of text about the issues on having low RAM or tiny micro-controllers would be useful to discuss. It will actually help the implementors make the right decision on optimization on their implementation, if possible, in case they decide to use 6lowpan stack on those low-capability HW devices. Regards, -Samita > > > > > _______________________________________________ > 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 Fri Jul 21 15:08:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40MD-0005rM-5Y; Fri, 21 Jul 2006 15:08:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40M7-0005kA-8b for 6lowpan@lists.ietf.org; Fri, 21 Jul 2006 15:08:11 -0400 Received: from agp.stanford.edu ([171.67.73.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G40Dn-00040R-TX for 6lowpan@lists.ietf.org; Fri, 21 Jul 2006 14:59:38 -0400 Received: from adsl-68-127-179-90.dsl.pltn13.pacbell.net ([68.127.179.90] helo=[192.168.1.114]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1G40Dl-0004lG-Tc; Fri, 21 Jul 2006 11:59:35 -0700 In-Reply-To: <43b91d370607202005n76793ae8r6badccba4a1c6810@mail.gmail.com> References: <20060720031006.69436.qmail@web60320.mail.yahoo.com> <28F1AB75-E294-4290-89FE-E7CE580F126C@cs.stanford.edu> <43b91d370607202005n76793ae8r6badccba4a1c6810@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: Philip Levis Subject: Re: [6lowpan] WG Last call on Problem Statement Document Date: Fri, 21 Jul 2006 11:59:34 -0700 To: Samita Chakrabarti X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -8.2 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 On Jul 20, 2006, at 8:05 PM, Samita Chakrabarti wrote: > On 7/20/06, Philip Levis wrote: >> You can totally write an IP stack -- even a TCP stack -- on sensor >> nodes today, admittedly the ones that have the biggest >> microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP >> stack might not have a lot of RAM for windowing and high performance, >> but that's rarely the goal. You can do it. >> >> I don't think the requirements the document implies are unrealistic >> or onerous. As I said, you have to cut the line somewhere. My comment >> was just that they *do* preclude smaller nodes whose storage cannot >> hold a complete IPv6 packet, and it might be useful to note as such, >> since the document is defining the problem statement, and therefore >> the problem scope. >> > > Your point is valid. Though IMHO, drawing a strict line on non- > applicability > on low RAM devices may not be wise. Of course; it would be counter-productive for the document to say "this means IPv6 cannot be implemented on hardware XYZ," as the future and some interesting techniques might show such a hard statement to be wrong. Rather, something such as "IPv6's requirement of sub-IP reassembly may pose challenges for low-end LowPAN devices that do not have enough RAM or storage for a 1280-octet packet." But anyways. Sounds like I've beaten this horse to death. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jul 25 21:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Y2x-00055P-Fo; Tue, 25 Jul 2006 21:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Y2v-00055H-Px for 6lowpan@lists.ietf.org; Tue, 25 Jul 2006 21:18:45 -0400 Received: from web81902.mail.mud.yahoo.com ([68.142.207.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5Y2v-0005m4-9M for 6lowpan@lists.ietf.org; Tue, 25 Jul 2006 21:18:45 -0400 Received: (qmail 31462 invoked by uid 60001); 26 Jul 2006 01:18:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Vhm0uHrbzocBBIoPGhq0KC+LkAFjdjS1ALEzjhjlZ2EZt0sTlSCBqWQOY2KUNGy2km+yTZ0EOf+DSxWBwVMLMgnzRaLqsgEt7vqUydB6txooJN2/NkVvhbBQiBeSbWTQ5vBinizqEuu1LDA8W41e2QhhIyjXx9ZnqijP+7gjO1Q= ; Message-ID: <20060726011844.31460.qmail@web81902.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81902.mail.mud.yahoo.com via HTTP; Tue, 25 Jul 2006 18:18:44 PDT Date: Tue, 25 Jul 2006 18:18:44 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] WG Last call on Problem Statement Document To: Philip Levis , Samita Chakrabarti In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============1675206117==" Errors-To: 6lowpan-bounces@ietf.org --===============1675206117== Content-Type: multipart/alternative; boundary="0-963879163-1153876724=:31445" --0-963879163-1153876724=:31445 Content-Type: text/plain; charset=us-ascii I think your text below makes sense, and see no problem adding it, unless there's heated objection. In general, though, this 1280 byte number is just thrown in to say that we comply with IPv6 requirements. Having enough buffer space for such large packets does not make it a good idea to throw them around a LoWPAN network. Nor does having insufficient buffer space mean that such a device won't be able to participate in a LoWPAN network, given that judicious applications better NOT use such large packets anyhow. I guess the upcoming document on application best practices (if we ever finish our current docs and recharter) can offer advice in this regard. -gabriel ----- Original Message ---- From: Philip Levis To: Samita Chakrabarti Cc: 6lowpan <6lowpan@lists.ietf.org> Sent: Friday, July 21, 2006 11:59:34 AM Subject: Re: [6lowpan] WG Last call on Problem Statement Document On Jul 20, 2006, at 8:05 PM, Samita Chakrabarti wrote: > On 7/20/06, Philip Levis wrote: >> You can totally write an IP stack -- even a TCP stack -- on sensor >> nodes today, admittedly the ones that have the biggest >> microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP >> stack might not have a lot of RAM for windowing and high performance, >> but that's rarely the goal. You can do it. >> >> I don't think the requirements the document implies are unrealistic >> or onerous. As I said, you have to cut the line somewhere. My comment >> was just that they *do* preclude smaller nodes whose storage cannot >> hold a complete IPv6 packet, and it might be useful to note as such, >> since the document is defining the problem statement, and therefore >> the problem scope. >> > > Your point is valid. Though IMHO, drawing a strict line on non- > applicability > on low RAM devices may not be wise. Of course; it would be counter-productive for the document to say "this means IPv6 cannot be implemented on hardware XYZ," as the future and some interesting techniques might show such a hard statement to be wrong. Rather, something such as "IPv6's requirement of sub-IP reassembly may pose challenges for low-end LowPAN devices that do not have enough RAM or storage for a 1280-octet packet." But anyways. Sounds like I've beaten this horse to death. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-963879163-1153876724=:31445 Content-Type: text/html; charset=us-ascii
I think your text below makes sense, and see no problem adding it, unless there's heated objection.
In general, though, this 1280 byte number is just thrown in to say that we comply with IPv6
requirements. Having enough buffer space for such large packets does not make it a good idea to
throw them around a LoWPAN network. Nor does having insufficient buffer space mean that such
a device won't be able to participate in a LoWPAN network, given that judicious applications
better NOT use such large packets anyhow.
 
I guess the upcoming document on application best practices (if we ever finish our current
docs and recharter) can offer advice in this regard.
 
-gabriel

----- Original Message ----
From: Philip Levis <pal@cs.stanford.edu>
To: Samita Chakrabarti <samitac2@gmail.com>
Cc: 6lowpan <6lowpan@lists.ietf.org>
Sent: Friday, July 21, 2006 11:59:34 AM
Subject: Re: [6lowpan] WG Last call on Problem Statement Document

On Jul 20, 2006, at 8:05 PM, Samita Chakrabarti wrote:

> On 7/20/06, Philip Levis <pal@cs.stanford.edu> wrote:
>> You can totally write an IP stack -- even a TCP stack -- on sensor
>> nodes today, admittedly the ones that have the biggest
>> microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP
>> stack might not have a lot of RAM for windowing and high performance,
>> but that's rarely the goal.  You can do it.
>>
>> I don't think the requirements the document implies are unrealistic
>> or onerous. As I said, you have to cut the line somewhere. My comment
>> was just that they *do* preclude smaller nodes whose storage cannot
>> hold a complete IPv6 packet, and it might be useful to note as such,
>> since the document is defining the problem statement, and therefore
>> the problem scope.
>>
>
> Your point is valid. Though IMHO, drawing a strict line on non-
> applicability
> on low RAM devices may not be wise.

Of course; it would be counter-productive for the document to say  
"this means IPv6 cannot be implemented on hardware XYZ," as the  
future and some interesting techniques might show such a hard  
statement to be wrong. Rather, something such as "IPv6's requirement  
of sub-IP reassembly may pose challenges for low-end LowPAN devices  
that do not have enough RAM or storage for a  1280-octet packet."

But anyways. Sounds like I've beaten this horse to death.

Phil

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

--0-963879163-1153876724=:31445-- --===============1675206117== 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 --===============1675206117==--