From 6lowpan-bounces@ietf.org Wed Oct 05 16:11:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFbg-0000dU-Vq; Wed, 05 Oct 2005 16:11:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENBdr-0005NW-FU for 6lowpan@megatron.ietf.org; Wed, 05 Oct 2005 11:57:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01686 for <6lowpan@ietf.org>; Wed, 5 Oct 2005 11:57:07 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENBmd-0007u5-2g for 6lowpan@ietf.org; Wed, 05 Oct 2005 12:06:23 -0400 Received: from jurassic.eng.sun.com ([129.146.108.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j95Fv2HT007089 for <6lowpan@ietf.org>; Wed, 5 Oct 2005 08:57:02 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j95Fv2lP254846 for <6lowpan@ietf.org>; Wed, 5 Oct 2005 08:57:02 -0700 (PDT) Message-Id: <200510051557.j95Fv2lP254846@jurassic.eng.sun.com> Date: Wed, 5 Oct 2005 08:54:56 -0700 (PDT) From: Samita Chakrabarti To: 6lowpan@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: aIYeDCaDoBTLZl9T6SQVWw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [6lowpan] 6lowpan meeting? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Does anyone know if 6lowpan wg is meeting at the upcoming IETF in November? The mailing list is very quiet. -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 06 08:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVCj-0005uV-EC; Thu, 06 Oct 2005 08:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVCf-0005uQ-US for 6lowpan@megatron.ietf.org; Thu, 06 Oct 2005 08:50:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00292 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 08:50:28 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENVLl-00069b-O0 for 6lowpan@ietf.org; Thu, 06 Oct 2005 08:59:53 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 541441; Thu, 06 Oct 2005 08:51:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200510051557.j95Fv2lP254846@jurassic.eng.sun.com> References: <200510051557.j95Fv2lP254846@jurassic.eng.sun.com> Date: Thu, 6 Oct 2005 08:50:26 -0400 To: Samita Chakrabarti , 6lowpan@ietf.org From: Margaret Wasserman Subject: Re: [6lowpan] 6lowpan meeting? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Samita, Yes, a meeting has been scheduled for Vancouver. Margaret At 8:54 AM -0700 10/5/05, Samita Chakrabarti wrote: >Does anyone know if 6lowpan wg is meeting >at the upcoming IETF in November? > >The mailing list is very quiet. > > >-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 Thu Oct 06 16:22:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcAr-0004ez-T8; Thu, 06 Oct 2005 16:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcAp-0004dw-Gt for 6lowpan@megatron.ietf.org; Thu, 06 Oct 2005 16:17:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05041 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 16:17:00 -0400 (EDT) Received: from fmr17.intel.com ([134.134.136.16] helo=orsfmr002.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENcJx-00036S-2f for 6lowpan@ietf.org; Thu, 06 Oct 2005 16:26:29 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j96KGqrS006138 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 20:16:52 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j96KGOSE030905 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 20:16:52 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005100613165116725 for <6lowpan@ietf.org>; Thu, 06 Oct 2005 13:16:51 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 13:16:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Oct 2005 13:15:44 -0700 Message-ID: <9D602ABCE51B0B488BF857A4787939B50601E642@orsmsx410> Thread-Topic: format document issues Thread-Index: AcXJixYD75E7wFvsQN+7BnYV00/PDQBGKUCg From: "Kushalnagar, Nandakishore" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 06 Oct 2005 20:16:51.0639 (UTC) FILETIME=[E34CFC70:01C5CAB2] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 X-Spam-Score: 0.6 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e Subject: [6lowpan] format document issues 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="===============0929768448==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0929768448== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CAB2.E313D9D3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CAB2.E313D9D3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I took a first stab in addressing some of the issues in the current specifications of the 6lowpan format document. Please send suggestions on the list. Issue from the previous meeting: Issue 1: Christian Huitema suggested looking at existing IANA registries for protocol types to avoid having to set up another one. Specifically, he suggested looking at IP protocol identifiers. Other people suggested looking at link-layer registries such as Ethertype and PPP protocol IDs. This item requires further work. [6lowpan at IETF 63 ]=20 When examining a specific registry, we should make sure that it actually is a good fit. The payloads for the 6lowpan encapsulation are somewhat 6lowpan specific. Raw IPv6 packets are just one type; we also will have a number of rather 6lowpan specific header compression schemes. In addition, routing and registration/management messages are quite likely to be entirely 6lowpan specific.=20 One other consideration would be whether the 6lowpan registrations would place an undue burden on the original registry. E.g., there are only 256 IP protocol numbers, which makes them a scarce resource.=20 One other way to manage the number space would be to make one or more existing registries part of the 6lowpan number space. E.g., there could be a selector that chooses between IP protocol numbers and PPP protocol numbers (assuming both actually make sense in this context).=20 IP protocol numbers are 8 bits. PPP protocol numbers are 14 bits (expressed in either 8 or 16 bits depending on the low order bit of the first byte).=20 NK:=20 I looked at IANA and could not find a protocol type that had the width of 11 bits and that served the purpose of what we needed. Please let me know if I am wrong here. As for adding ether type may be a good solution, the document does mention about adding a SNAP header. If we were to add the SNAP header we could potentially remove the protocol field in the adaptation layer. But as we discussed in the meeting, how difficult would it be to get a packet that has ethertype for 6lowpan specific packets such as route messages, etc. Another issue with adding 8 bytes of LLC/SNAP is that we will loose those bytes from the header. If there are no heart burns about this, then we could perhaps choose to add the LLC/SNAP header and remove protocol field from the header and instead use 6lowpan type field whose values are defined within this document to indicate types of 6lowpan messages. (routing, discovery, etc). This is of course assuming that 6lowpan could be made a type under the definition of SNAP protocol type. Any suggestions? Issue 2 =20 Technical work required on encapsulation/format specification:=20 Some discussion ensued about the M-bit and the compression of source addresses in a multi-hop environment. As this discussion could not be completed on-line, KiHyungKim will send an example scenario where this matters to the mailing list. [6lowpan at IETF 63 ]=20 =20 NK:=20 I think I understand what KiHyungKim was getting at here. Correct me if I am wrong, his argument was that the source address also changes on a link by link basis and just having a destination address and compressing out the IP source and destination address will not work. We need to also add another field that specifies a "multi hop" source address field when the M bit is present. =20 I would suggest the following change for the current format when M bit is 1: =20 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 2 3 4 5 6 7 8 9 0 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | LF|prot_type|M| Multihop source address | Multihop Destination Address| =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ =20 Where multihop source and destination addresses correspond to source and final destination address. =20 Regards, Nandu ------_=_NextPart_001_01C5CAB2.E313D9D3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

I took a first stab in addressing = some of the issues in the current specifications of the 6lowpan format document. = Please send suggestions on the list.

Issue from the previous = meeting:

Issue = 1:

Christian Huitema suggested = looking at existing IANA registries for protocol types to avoid having to set up = another one. Specifically, he suggested looking at IP protocol identifiers. = Other people suggested looking at link-layer registries such as Ethertype and = PPP protocol IDs. This item requires further work. [6lowpan at IETF = 63]

When examining a specific = registry, we should make sure that it actually is a good fit. The payloads for the = 6lowpan encapsulation are somewhat 6lowpan specific. Raw IPv6 packets are just = one type; we also will have a number of rather 6lowpan specific header = compression schemes. In addition, routing and registration/management messages are = quite likely to be entirely 6lowpan specific.

One other consideration would be = whether the 6lowpan registrations would place an undue burden on the original = registry. E.g., there are only 256 IP protocol numbers, which makes them a scarce resource.

One other way to manage the = number space would be to make one or more existing registries part of the 6lowpan = number space. E.g., there could be a selector that chooses between IP protocol = numbers and PPP protocol numbers (assuming both actually make sense in this = context).

IP protocol numbers are 8 bits. = PPP protocol numbers are 14 bits (expressed in either 8 or 16 bits depending = on the low order bit of the first byte).

NK:

I looked at IANA and could not find a = protocol type that had the width of 11 bits and that served the purpose of what = we needed. Please let me know if I am wrong = here.

As for adding ether type may be a good = solution, the document does mention about adding a SNAP header. If we were to add = the SNAP header we could potentially remove the protocol field in the = adaptation layer. But as we discussed in the meeting, how difficult would it be to = get a packet that has ethertype for 6lowpan specific packets such as route = messages, etc. Another issue with adding 8 bytes of LLC/SNAP is that we will loose = those bytes from the header.

If there are no heart burns about this, = then we could perhaps choose to add the LLC/SNAP header and remove protocol = field from the header and instead use 6lowpan type field whose values are defined = within this document to indicate types of 6lowpan messages. (routing, = discovery, etc). This is of course assuming that 6lowpan could be made a type under the definition of SNAP protocol type. Any = suggestions?

Issue = 2

 

=

Technical work required = on encapsulation/format specification:

Some discussion ensued about the M-bit and the compression of source = addresses in a multi-hop environment. As this discussion could not be completed = on-line, KiHyungKim will send an = example scenario where this matters to the mailing list. [6lowpan at IETF = 63]

 =

NK: =

I think I = understand what KiHyungKim was getting at here. Correct me if I am wrong, his argument = was that the source address also changes on a link by link basis and just having = a destination address and compressing out the IP source and destination = address will not work. We need to also add another field that specifies a = “multi hop” source address field when the M bit is = present.

 =

I would suggest = the following change for the current format when M bit is = 1:

 =

   = ;    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 2 3 4 5 = 6 7 8 9 0

   = ;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+

   = ;   | LF|prot_type|M|    Multihop source address | Multihop Destination Address|

   = ;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+

 =

Where multihop = source and destination addresses correspond to source and final destination = address.

 =

Regards,

Nandu<= /span>

------_=_NextPart_001_01C5CAB2.E313D9D3-- --===============0929768448== 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 --===============0929768448==-- From 6lowpan-bounces@ietf.org Thu Oct 06 16:28:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcLw-0005ef-OT; Thu, 06 Oct 2005 16:28:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcLv-0005e1-7M for 6lowpan@megatron.ietf.org; Thu, 06 Oct 2005 16:28:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10632 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 16:28:27 -0400 (EDT) Received: from fmr20.intel.com ([134.134.136.19] helo=orsfmr005.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENcUz-0005Tp-N5 for 6lowpan@ietf.org; Thu, 06 Oct 2005 16:37:55 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j96KSGB4016037 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 20:28:16 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j96KRVbm029612 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 20:28:16 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005100613281506068 for <6lowpan@ietf.org>; Thu, 06 Oct 2005 13:28:15 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 13:28:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Oct 2005 13:26:06 -0700 Message-ID: <9D602ABCE51B0B488BF857A4787939B50601E690@orsmsx410> Thread-Topic: goals draft issues Thread-Index: AcXKtC3MhnZ+gkpvRTGCUeQrxTOCVQ== From: "Kushalnagar, Nandakishore" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 06 Oct 2005 20:28:15.0540 (UTC) FILETIME=[7AEFFF40:01C5CAB4] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 X-Spam-Score: 0.2 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Subject: [6lowpan] goals draft issues 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="===============1835498182==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1835498182== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CAB4.7A947C94" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CAB4.7A947C94 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Last time we discussed about one issue that talked about filling the security consideration section within the document: =20 Issue: The security considerations are still "TBD". Gabriel Montenegro proposed mining the security considerations section of the format document for possible input. =20 NK: I am soliciting for some feedback here as to what this section is supposed to have?=20 Chairs/others? =20 Regards, Nandu ------_=_NextPart_001_01C5CAB4.7A947C94 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Last time we discussed = about one issue that talked about filling the security consideration section = within the document:

 

Issue:=

The security = considerations are still "TBD". Gabriel = Montenegro proposed mining the security considerations section of the format = document for possible input.

 

NK:

I am soliciting for some feedback here as to what = this section is supposed to have?

Chairs/others?

 

Regards,

Nandu

------_=_NextPart_001_01C5CAB4.7A947C94-- --===============1835498182== 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 --===============1835498182==-- From 6lowpan-bounces@ietf.org Thu Oct 06 16:31:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcOf-0007ud-3K; Thu, 06 Oct 2005 16:31:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcOd-0007sL-9R for 6lowpan@megatron.ietf.org; Thu, 06 Oct 2005 16:31:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12224 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 16:31:13 -0400 (EDT) Received: from fmr20.intel.com ([134.134.136.19] helo=orsfmr005.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENcXf-000662-Gg for 6lowpan@ietf.org; Thu, 06 Oct 2005 16:40:41 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j96KV2B4016569 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 20:31:02 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j96KSHUO006480 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 20:31:02 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005100613305919338 for <6lowpan@ietf.org>; Thu, 06 Oct 2005 13:30:59 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 13:30:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Oct 2005 13:30:36 -0700 Message-ID: <9D602ABCE51B0B488BF857A4787939B50601E6A4@orsmsx410> Thread-Topic: goals draft issues Thread-Index: AcXKtC3MhnZ+gkpvRTGCUeQrxTOCVQAAIIkg From: "Kushalnagar, Nandakishore" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 06 Oct 2005 20:30:59.0459 (UTC) FILETIME=[DCA40D30:01C5CAB4] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 X-Spam-Score: 0.2 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Subject: [6lowpan] RE: goals draft issues 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="===============0530339191==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0530339191== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CAB4.DC6D393E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CAB4.DC6D393E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not sure if the email got sent the first time, thus resending. Sorry. =20 All, =20 Last time we discussed about one issue that talked about filling the security consideration section within the document: =20 Issue: The security considerations are still "TBD". Gabriel Montenegro proposed mining the security considerations section of the format document for possible input. =20 NK: I am soliciting for some feedback here as to what this section is supposed to have?=20 Chairs/others? =20 Regards, Nandu ------_=_NextPart_001_01C5CAB4.DC6D393E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not sure if the email got sent the = first time, thus resending. Sorry.

 

=

All,

 

Last time we discussed = about one issue that talked about filling the security consideration section = within the document:

 

Issue:=

The security = considerations are still "TBD". Gabriel = Montenegro proposed mining the security considerations section of the format = document for possible input.

 

NK:

I am soliciting for some feedback here as to what = this section is supposed to have?

Chairs/others?

 

Regards,

Nandu

------_=_NextPart_001_01C5CAB4.DC6D393E-- --===============0530339191== 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 --===============0530339191==-- From 6lowpan-bounces@ietf.org Thu Oct 06 18:59:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENehm-0005gd-G7; Thu, 06 Oct 2005 18:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENehk-0005gS-Pl for 6lowpan@megatron.ietf.org; Thu, 06 Oct 2005 18:59:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25574 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 18:59:06 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENeqp-0005Qi-VA for 6lowpan@ietf.org; Thu, 06 Oct 2005 19:08:39 -0400 Received: from jurassic.eng.sun.com ([129.146.106.105]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j96Mx5vD016959; Thu, 6 Oct 2005 16:59:05 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j96Mx5rF216874; Thu, 6 Oct 2005 15:59:05 -0700 (PDT) Message-Id: <200510062259.j96Mx5rF216874@jurassic.eng.sun.com> Date: Thu, 6 Oct 2005 15:56:58 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [6lowpan] goals draft issues To: nandakishore.kushalnagar@intel.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +Wjgy6tz4CXkZ4eeNA9CBA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > From: "Kushalnagar, Nandakishore" > To: <6lowpan@ietf.org> Issue: The security considerations are still "TBD". Gabriel Montenegro proposed mining the security considerations section of the format document for possible input. NK: I am soliciting for some feedback here as to what this section is supposed to have? Chairs/others? -------------------------------- Hi Nandu, In the first meeting of LowPan wg (BOF?), folks brought up the security consideration issues. It was mentioned that 802.15.4 link-layer security should be enough. The following paper depicts some of the problem scenarios with 802.15.4 security: http://www.cs.berkeley.edu/~nks/papers/15.4-wise04.pdf I was told by a security expert that 802.15.4 security is not good enough. The above paper recomends a few modifications - does anyone know if IEEE 802.15.4 workgroup is looking into improving the link-layer security? I don't think IPsec security is a feasible solution on this kind of small devices where 6lowpan would eventually run. It'd be interesting to get people's viewpoint on this. Since we are routing at the link-layer, it would be better if we have tighter link-level security and then application level security using crypto. Perhaps the protocols running on top of LowPan can run some security protocols that are appropriate for this kind of network. Comments? -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 06 19:24:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENf6L-0004yx-7g; Thu, 06 Oct 2005 19:24:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENf6I-0004yp-NE for 6lowpan@megatron.ietf.org; Thu, 06 Oct 2005 19:24:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26556 for <6lowpan@ietf.org>; Thu, 6 Oct 2005 19:24:31 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENfFQ-0006KK-Nv for 6lowpan@ietf.org; Thu, 06 Oct 2005 19:34:04 -0400 Received: from jurassic.eng.sun.com ([129.146.68.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j96NOU2B021440; Thu, 6 Oct 2005 16:24:30 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j96NOT3x226490; Thu, 6 Oct 2005 16:24:29 -0700 (PDT) Message-Id: <200510062324.j96NOT3x226490@jurassic.eng.sun.com> Date: Thu, 6 Oct 2005 16:22:23 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [6lowpan] format document issues To: nandakishore.kushalnagar@intel.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: u34G1T91DM/7PVz7uZ2CLQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > From: "Kushalnagar, Nandakishore" > To: <6lowpan@ietf.org> ---------Issue from the previous meeting: Issue 1: Christian Huitema suggested looking at existing IANA registries for protocol types to avoid having to set up another one. Specifically, he suggested looking at IP protocol identifiers. Other people suggested looking at link-layer registries such as Ethertype and PPP protocol IDs. This item requires further work. [6lowpan at IETF 63 ] When examining a specific registry, we should make sure that it actually is a good fit. The payloads for the 6lowpan encapsulation are somewhat 6lowpan specific. Raw IPv6 packets are just one type; we also will have a number of rather 6lowpan specific header compression schemes. In addition, routing and registration/management messages are quite likely to be entirely 6lowpan specific. One other consideration would be whether the 6lowpan registrations would place an undue burden on the original registry. E.g., there are only 256 IP protocol numbers, which makes them a scarce resource. One other way to manage the number space would be to make one or more existing registries part of the 6lowpan number space. E.g., there could be a selector that chooses between IP protocol numbers and PPP protocol numbers (assuming both actually make sense in this context). IP protocol numbers are 8 bits. PPP protocol numbers are 14 bits (expressed in either 8 or 16 bits depending on the low order bit of the first byte). NK: I looked at IANA and could not find a protocol type that had the width of 11 bits and that served the purpose of what we needed. Please let me know if I am wrong here. As for adding ether type may be a good solution, the document does mention about adding a SNAP header. If we were to add the SNAP header we could potentially remove the protocol field in the adaptation layer. But as we discussed in the meeting, how difficult would it be to get a packet that has ethertype for 6lowpan specific packets such as route messages, etc. Another issue with adding 8 bytes of LLC/SNAP is that we will loose those bytes from the header. If there are no heart burns about this, then we could perhaps choose to add the LLC/SNAP header and remove protocol field from the header and instead use 6lowpan type field whose values are defined within this document to indicate types of 6lowpan messages. (routing, discovery, etc). This is of course assuming that 6lowpan could be made a type under the definition of SNAP protocol type. Any suggestions? ---------------------- SC: It'd be a mistake, IMHO to add LLC/SNAP (8 bytes) in 802.15.4 layer in order to use only a few bits for protocol number. Even for ethernet, LLC/SNAP only uses 2 bytes in a meaningful way and adds extra overhead of bytes (SSAP=DSSAP always same). Protocol type needs to be looked at every LL-hop - thus header compression at this level would not work. Also, the Lowpan protocol type different than the IP-protocol (L3) type, folks may want to run a lowpan specific protocol that does not run on the IP layer. Thus it may not be a good idea to hold space from IP-protocol space. I don't understand the process of protocol type assignment - but can we ask for a different space for LowPan protocol types ? Also, would like to see 11 bits to shrink to a lower number say 8bits or so. Issue 2 ---Technical work required on encapsulation/format specification: ----- NK: I think I understand what KiHyungKim was getting at here. Correct me if I am wrong, his argument was that the source address also changes on a link by link basis and just having a destination address and compressing out the IP source and destination address will not work. We need to also add another field that specifies a "multi hop" source address field when the M bit is present. --------------------------------- SC: I don't quite understand the issue of header compression here for IPv6 case. We are doing header compression in IPv6 header, not on 802.15.4 MAC layer address. Since M bit signifies that this packet is routed in LL2-multihop fashion, the final destination would be a MAC-address. I don't see any header compression of final destination when M bit set. Perhaps the draft is not clear about that in the area where it describes LowPan unfragmented header format with M bit. The draft needs to clarify the final destination address type. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Oct 08 03:23:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO92y-0007Ai-Vk; Sat, 08 Oct 2005 03:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO92u-000770-0s for 6lowpan@megatron.ietf.org; Sat, 08 Oct 2005 03:23:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06815 for <6lowpan@ietf.org>; Sat, 8 Oct 2005 03:23:02 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO9CK-00070w-4q for 6lowpan@ietf.org; Sat, 08 Oct 2005 03:32:49 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IO100LNW5TZ54@mailout3.samsung.com> for 6lowpan@ietf.org; Sat, 08 Oct 2005 16:22:47 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IO100K0M5TZX0@mmp2.samsung.com> for 6lowpan@ietf.org; Sat, 08 Oct 2005 16:22:47 +0900 (KST) Date: Sat, 08 Oct 2005 16:23:37 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] goals draft issues To: Samita Chakrabarti , nandakishore.kushalnagar@intel.com Message-id: <04ea01c5cbd9$33380be0$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200510062259.j96Mx5rF216874@jurassic.eng.sun.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > Since we are routing at the link-layer, it would be better if we > have tighter link-level security and then application level security > using crypto. Perhaps the protocols running on top of LowPan > can run some security protocols that are appropriate for this kind > of network. > > Comments? Current draft said; (in both problem statements and goals) 4.6 Security Although IEEE 802.15.4 provides AES link layer security, a complete end-to-end security is needed. 8. 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. So, I prefer not to address more specific something in Security Considerations. Just refering them into Security Considerations would be fine for me. If rechartering requires more details on security issue, it could be a separated document (at least *6lowpan security threat analysis*). Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Oct 08 04:27:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOA30-0002le-0O; Sat, 08 Oct 2005 04:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOA2w-0002lW-V3 for 6lowpan@megatron.ietf.org; Sat, 08 Oct 2005 04:27:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09029 for <6lowpan@ietf.org>; Sat, 8 Oct 2005 04:27:08 -0400 (EDT) Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOACP-0000Mn-1s for 6lowpan@ietf.org; Sat, 08 Oct 2005 04:36:57 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.12.10/8.12.10) with ESMTP id j988R1s6012828 for <6lowpan@ietf.org>; Sat, 8 Oct 2005 02:27:01 -0600 (MDT) From: Geoff Mulligan To: 6lowpan@ietf.org Content-Type: text/plain Date: Sat, 08 Oct 2005 02:27:05 -0600 Message-Id: <1128760026.2159.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [6lowpan] how many drafts 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Would anyone planning on presenting a draft at this next ietf please raise their hand. We have only gotten a single hour, though we requested two. We are trying to get scheduled for 2 hours. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 10 15:17:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP39d-0006B9-K8; Mon, 10 Oct 2005 15:17:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP39a-0006Ah-0P for 6lowpan@megatron.ietf.org; Mon, 10 Oct 2005 15:17:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14776 for <6lowpan@ietf.org>; Mon, 10 Oct 2005 15:17:38 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP3JR-0005kI-TG for 6lowpan@ietf.org; Mon, 10 Oct 2005 15:27:57 -0400 Received: from jurassic.eng.sun.com ([129.146.68.36]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9AJHOHT008412; Mon, 10 Oct 2005 12:17:24 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9AJHMXu151476; Mon, 10 Oct 2005 12:17:24 -0700 (PDT) Message-Id: <200510101917.j9AJHMXu151476@jurassic.eng.sun.com> Date: Mon, 10 Oct 2005 12:15:11 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [6lowpan] how many drafts To: geoff@mulligan.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 23XuXkgf9K35acxan9ZPwA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Geoff, > > Would anyone planning on presenting a draft at this next ietf please > raise their hand. We have only gotten a single hour, though we > requested two. We are trying to get scheduled for 2 hours. > > geoff A presentation on the lowpan-aodv(or merged Load) would be potential interest to many, I suppose. We had one slide/draft presentation, from different drafts last time, we do not have a new version of lowpan-nd draft this time. But, I wonder if the existing one would be allowed to present this time. I am a bit unsure about the charter of this workgroup. Are we going to extend the charter to incorporate discussion on routing, ND etc. to be done here ? Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 10 15:32:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP3OL-00017A-KB; Mon, 10 Oct 2005 15:32:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP3OG-00014F-Sa for 6lowpan@megatron.ietf.org; Mon, 10 Oct 2005 15:32:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16052 for <6lowpan@ietf.org>; Mon, 10 Oct 2005 15:32:51 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP3YB-0006AU-9S for 6lowpan@ietf.org; Mon, 10 Oct 2005 15:43:10 -0400 Received: from jurassic.eng.sun.com ([129.146.56.144]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9AJWm2B023581; Mon, 10 Oct 2005 12:32:48 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9AJWlkG158967; Mon, 10 Oct 2005 12:32:47 -0700 (PDT) Message-Id: <200510101932.j9AJWlkG158967@jurassic.eng.sun.com> Date: Mon, 10 Oct 2005 12:30:36 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [6lowpan] goals draft issues To: Samita.Chakrabarti@eng.sun.com, nandakishore.kushalnagar@intel.com, soohong.park@samsung.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GeQk7j4qxkkiPjCOId0Esg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > > > Since we are routing at the link-layer, it would be better if we > > have tighter link-level security and then application level security > > using crypto. Perhaps the protocols running on top of LowPan > > can run some security protocols that are appropriate for this kind > > of network. > > > > Comments? > > Current draft said; (in both problem statements and goals) > > 4.6 Security > > Although IEEE 802.15.4 provides AES link layer security, a complete > end-to-end security is needed. > > 8. 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. > > Ok. Thanks. I missed the text in Section 8. > > So, I prefer not to address more specific something in Security Considerations. Just refering them into Security Considerations would be fine for me. If rechartering requires more details on security issue, it could be a separated document (at least *6lowpan security threat analysis*). Makes sense to me. -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 10 21:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP9HM-0002Vo-3W; Mon, 10 Oct 2005 21:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP9HK-0002Vf-Hn for 6lowpan@megatron.ietf.org; Mon, 10 Oct 2005 21:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07570 for <6lowpan@ietf.org>; Mon, 10 Oct 2005 21:50:04 -0400 (EDT) Received: from web81906.mail.mud.yahoo.com ([68.142.207.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EP9RJ-0008G0-KQ for 6lowpan@ietf.org; Mon, 10 Oct 2005 22:00:27 -0400 Received: (qmail 20567 invoked by uid 60001); 11 Oct 2005 01:49:55 -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:Content-Transfer-Encoding; b=a2vi7T9T7HleBeHi7u6zpqfJXEyVzM7pR+WlCYu1crdivRg0By0paW8G808bbwiDl36TFlPwa+rHCAXvi9UaZfqnuB0+eKK2fkE1uG0D8N8R1YO1+yKsImgFxC/j64RUJBZsv7omFPduj5a9uMgZkRJB9CqKv8kKjM0H0sIyIgY= ; Message-ID: <20051011014955.20565.qmail@web81906.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81906.mail.mud.yahoo.com via HTTP; Mon, 10 Oct 2005 18:49:55 PDT Date: Mon, 10 Oct 2005 18:49:55 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] how many drafts To: Samita Chakrabarti , geoff@mulligan.com In-Reply-To: <200510101917.j9AJHMXu151476@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- Samita Chakrabarti wrote: > A presentation on the lowpan-aodv(or merged Load) would be potential > interest to many, I suppose. I'm suppose this will happen. Perhaps Prof. Kim of Ajou Univ. will provide the update. Along these lines, you were asking about DyMO. I had started something with Ian Chakeres but never submitted it as an I-D (though I did send a pointer previous to Paris). I'm pleased to say the Prof. Kim of Ajou Univ. and Daniel will be helping out with this, so perhaps we'll see something about this as well in Vancouver. You had asked about what was the future of AODVbis. This is a question to ask in MANET, I guess. Ian, do you know? -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 10 22:07:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP9Xp-0006Do-46; Mon, 10 Oct 2005 22:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP9Xo-0006Bx-60 for 6lowpan@megatron.ietf.org; Mon, 10 Oct 2005 22:07:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08266 for <6lowpan@ietf.org>; Mon, 10 Oct 2005 22:07:05 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP9hn-0000E0-IE for 6lowpan@ietf.org; Mon, 10 Oct 2005 22:17:29 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IO6008TTB7CKG@mailout3.samsung.com> for 6lowpan@ietf.org; Tue, 11 Oct 2005 11:06:48 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IO600304B7CRB@mmp2.samsung.com> for 6lowpan@ietf.org; Tue, 11 Oct 2005 11:06:48 +0900 (KST) Date: Tue, 11 Oct 2005 11:07:45 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] how many drafts To: Samita Chakrabarti , geoff@mulligan.com Message-id: <020a01c5ce08$91df06e0$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200510101917.j9AJHMXu151476@jurassic.eng.sun.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Samita, > A presentation on the lowpan-aodv(or merged Load) would be potential > interest to many, I suppose. LOAD would be very much enough for this interest. Yes, it will be shown at upcoming 6lowpan meeting if acceptable. Also one more on-demand adhoc protocol for 6lowpan will be proposed soon in terms of 6lowpan adhoc routing. > We had one slide/draft presentation, from different drafts last time, we > do not have a new version of lowpan-nd draft this time. But, I wonder > if the existing one would be allowed to present this time. > > I am a bit unsure about the charter of this workgroup. Are we going to > extend the charter to incorporate discussion on routing, ND etc. to be > done here ? I am asking for the same concern too. Geoff, we also have lots of issues regarding 6lowpan and it is almost certain to be implemented soon (hopefully our all implementation will be done by end of this month). We can input lots of valuable results from our real experience into 6lowpan, but, I am also not sure which items would be extended from rechartering of 6lowpan. Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 10 22:17:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP9hh-0008PD-7H; Mon, 10 Oct 2005 22:17:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP9hf-0008P8-Sj for 6lowpan@megatron.ietf.org; Mon, 10 Oct 2005 22:17:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08571 for <6lowpan@ietf.org>; Mon, 10 Oct 2005 22:17:15 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP9rd-0000Pm-G6 for 6lowpan@ietf.org; Mon, 10 Oct 2005 22:27:38 -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 <0IO6008JBBOD2M@mailout2.samsung.com> for 6lowpan@ietf.org; Tue, 11 Oct 2005 11:17:01 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IO60005CBODD8@mmp2.samsung.com> for 6lowpan@ietf.org; Tue, 11 Oct 2005 11:17:01 +0900 (KST) Date: Tue, 11 Oct 2005 11:17:57 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] goals draft issues To: Samita Chakrabarti , nandakishore.kushalnagar@intel.com Message-id: <024001c5ce09$ff2a31b0$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200510062259.j96Mx5rF216874@jurassic.eng.sun.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Samita again...:-) > In the first meeting of LowPan wg (BOF?), folks brought up the > security consideration issues. It was mentioned that 802.15.4 > link-layer security should be enough. The following paper > depicts some of the problem scenarios with 802.15.4 security: > > http://www.cs.berkeley.edu/~nks/papers/15.4-wise04.pdf > > I was told by a security expert that 802.15.4 security is not > good enough. The above paper recomends a few modifications - does > anyone know if IEEE 802.15.4 workgroup is looking into improving > the link-layer security? > > I don't think IPsec security is a feasible solution on this kind > of small devices where 6lowpan would eventually run. It'd be > interesting to get people's viewpoint on this. > > Since we are routing at the link-layer, it would be better if we > have tighter link-level security and then application level security > using crypto. Perhaps the protocols running on top of LowPan > can run some security protocols that are appropriate for this kind > of network. > > Comments? > > -Samita > Your comment seems very interesting for me to raise the awareness of 6lowpan security. Yes, 802.15.4 security is not good enough in my understanding. Also, IPSec is not appropriate to 6lowpan small device. So, I think *6lowpan security threat analysis* should be documended prior to moving specific solutions on. Obviously, 6lowpan requires security protocols. Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 11 15:04:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPQn-0005OZ-1c; Tue, 11 Oct 2005 15:04:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPQj-0005OK-4w for 6lowpan@megatron.ietf.org; Tue, 11 Oct 2005 15:04:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22624 for <6lowpan@ietf.org>; Tue, 11 Oct 2005 15:04:49 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPPan-0004ul-Tz for 6lowpan@ietf.org; Tue, 11 Oct 2005 15:15:21 -0400 Received: from jurassic.eng.sun.com ([129.146.226.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9BJ4e2B020780; Tue, 11 Oct 2005 12:04:40 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9BJ4d4A518576; Tue, 11 Oct 2005 12:04:40 -0700 (PDT) Message-Id: <200510111904.j9BJ4d4A518576@jurassic.eng.sun.com> Date: Tue, 11 Oct 2005 12:02:27 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [6lowpan] how many drafts To: gabriel_montenegro_2000@yahoo.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: j7qMN4z19nSdC2FqBgAvgw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Gabe, Thanks for your response. I have a few questions regarding the routing solutions on Lowpan: - Are we going to go ahead with lowpan-aodv draft? If so, I'd like to pass some modification requests that we have discovered during an exercize of its implementation. - Are we going to merge lowpan-aodv and LOAD draft? - If yes, then we need to review this draft seriously. It is RFC3561 based. IMHO, neigther AODV-bis nor RFC3561 are quite suitable for lowpan routing; It'd be much nicer if we come up with a lowpan routing protocol based on DYMO/AODV/AODVbis flavors. It is unlikely that lowpan tiny devices will route packets for the regular internet, hence the modified standard version protocol makes more sense for the lowpan world. I am not quite sure how it is useful to have lowpan-aodv, lowpan-dymo and lowpan-aodvbis etc. as opposed to one draft that covers lowpan concerns and is based on parts of AODV/AODVbis and DYMO features. That way we will not be tying lowpan's fate on success of the corresponding protocols through the IETF process. But I may be too optimistic. -Samita > --- Samita Chakrabarti wrote: > > A presentation on the lowpan-aodv(or merged Load) would be potential > > interest to many, I suppose. > > I'm suppose this will happen. Perhaps Prof. Kim of Ajou Univ. will provide the > update. > > Along these lines, you were asking about DyMO. I had started something with Ian > Chakeres but never submitted it as an I-D (though I did send a pointer previous > to Paris). I'm pleased to say the Prof. Kim of Ajou Univ. and Daniel will be > helping out with this, so perhaps we'll see something about this as well in > Vancouver. > > You had asked about what was the future of AODVbis. This is a question to ask > in MANET, I guess. > > Ian, do you know? > > -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 11 17:52:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPS36-0006ne-OB; Tue, 11 Oct 2005 17:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPS35-0006nO-IN for 6lowpan@megatron.ietf.org; Tue, 11 Oct 2005 17:52:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06204 for <6lowpan@ietf.org>; Tue, 11 Oct 2005 17:52:36 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPSDC-0002r1-Sm for 6lowpan@ietf.org; Tue, 11 Oct 2005 18:03:11 -0400 Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9BLqT2B025337; Tue, 11 Oct 2005 14:52:29 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9BLqSiZ589610; Tue, 11 Oct 2005 14:52:29 -0700 (PDT) Message-Id: <200510112152.j9BLqSiZ589610@jurassic.eng.sun.com> Date: Tue, 11 Oct 2005 14:50:16 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [6lowpan] format document issues To: nandakishore.kushalnagar@intel.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Mfb4+9FxQDwncnzasG3irg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > > Issue 2 > ---Technical work required on encapsulation/format specification: ----- > > NK: > > I think I understand what KiHyungKim was getting at here. Correct me if > I am wrong, his argument was that the source address also changes on a > link by link basis and just having a destination address and compressing > out the IP source and destination address will not work. We need to also > add another field that specifies a "multi hop" source address field when > the M bit is present. > > --------------------------------- > SC: > > I don't quite understand the issue of header compression here for IPv6 > case. We are doing header compression in IPv6 header, not on 802.15.4 > MAC layer address. Since M bit signifies that this packet is routed in > LL2-multihop fashion, the final destination would be a MAC-address. > I don't see any header compression of final destination when M bit set. > After going back to the old mails in the alias, I think I understood now what KiHyungKim was trying to point at. ------------email excerpt from KiHyungKim in Aug 10---------------- Again, the layer 2 source address is not the originator address, but the previous hop node. Additionally, the routing at the adaptation layer could not report to the originator of route errors during data transmission . For example, A is the originator and E is the destination as follows. A --> B --> C --> D --> E In case, the link between C and D is broken, A --> B --> C -X-> D --> E C could report the broken link to the originator by utilizing Route Error message (in LOAD) if the data packet DOES have the originator address at the adaptation layer. -------------------------------------------------------------------- So, the main concern is how to report the error back. He also mentioned LOAD as a routing protocol. I think we should not add originator source address in the LowPan header - we are already short in payload length. The use of 'final destination' is needed, but not the 'originator source MAC address'. For example, when AODV RREQ is received at each intermediate node, it can extract the originator MAC address from the AODV packet and build a reverse route towards the orginator node. In the above example, node C will keep a reverse-route table ( in order to go to A next hop is B). When link between C and D breaks, during multihop data transfer, C can propagate that error back to the originator node by using multihop in the reverse direction. Thus, when M bit is set, we assume that intermediate nodes between two end-nodes will also use multi-hop routing (and discovery if needed) to propagate the error back to the originator. The format document, may explain the above situation and recommend that the underlying multihop routing protocol should be such that it should optimize multihopping in the reverse direction as well - Thus we can save 8 valuable bytes from the lowpan header. The lowpan M bit and forwarding concept is perhaps quite similar to draft-perlman-rbridge-03.txt where the shim-header contains the egress rbridge's address for unicast routing. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 12 02:48:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaPm-000456-Vn; Wed, 12 Oct 2005 02:48:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaPh-00040i-VK for 6lowpan@megatron.ietf.org; Wed, 12 Oct 2005 02:48:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00458 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 02:48:31 -0400 (EDT) Received: from web81911.mail.mud.yahoo.com ([68.142.207.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPaZs-0007zj-5S for 6lowpan@ietf.org; Wed, 12 Oct 2005 02:59:07 -0400 Received: (qmail 89231 invoked by uid 60001); 12 Oct 2005 06:48:15 -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:Content-Transfer-Encoding; b=2pO1d7T0x9A3ftSUSZSA6gwlyeB8TyY34L+Ibd+hLUvshduunbS3ZmdpFFMHT+7sfn4+SSwHPEKlCziEco/O5mmdYHHNo2jRw+91+HFWCzW/3QXJpI8pvBsKkVVILUk9zUrOcqp9RCWQySCdGhuwSrcTp9fvgsSSABTv8SN9FBY= ; Message-ID: <20051012064815.89229.qmail@web81911.mail.mud.yahoo.com> Received: from [24.16.92.216] by web81911.mail.mud.yahoo.com via HTTP; Tue, 11 Oct 2005 23:48:15 PDT Date: Tue, 11 Oct 2005 23:48:15 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] goals draft issues To: Samita Chakrabarti , nandakishore.kushalnagar@intel.com In-Reply-To: <200510062259.j96Mx5rF216874@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org 802.15.4b is improving somewhat the link security. I *believe*, for example, that they have deprecated (or recommended against) CBC-CTR (one of the weaknesses identified in the paper) and recommend CCM* (also recommended by ZigBee according to their public tutorials at their open house events), supposedly a much improved mode. Not sure about other security related changes, but I'm sure there are plenty of 15.4b-savvy folks on this alias. Hopefully, they can respond. It might even be a good idea to have a quick update by one of those folks at the meeting. -gabriel ps - another thing 15.4b is doing is increasing the speed for the sub-1GHz PHYs to bring them up to 250 Kbps. --- Samita Chakrabarti wrote: > > > > From: "Kushalnagar, Nandakishore" > > To: <6lowpan@ietf.org> > > Issue: > > The security considerations are still "TBD". Gabriel Montenegro proposed > mining the security considerations section of the format document for > possible input. > > > > NK: > > I am soliciting for some feedback here as to what this section is > supposed to have? > > Chairs/others? > -------------------------------- > > Hi Nandu, > > In the first meeting of LowPan wg (BOF?), folks brought up the > security consideration issues. It was mentioned that 802.15.4 > link-layer security should be enough. The following paper > depicts some of the problem scenarios with 802.15.4 security: > > http://www.cs.berkeley.edu/~nks/papers/15.4-wise04.pdf > > I was told by a security expert that 802.15.4 security is not > good enough. The above paper recomends a few modifications - does > anyone know if IEEE 802.15.4 workgroup is looking into improving > the link-layer security? > > I don't think IPsec security is a feasible solution on this kind > of small devices where 6lowpan would eventually run. It'd be > interesting to get people's viewpoint on this. > > Since we are routing at the link-layer, it would be better if we > have tighter link-level security and then application level security > using crypto. Perhaps the protocols running on top of LowPan > can run some security protocols that are appropriate for this kind > of network. > > Comments? > > -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 Oct 12 02:55:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaWD-000667-11; Wed, 12 Oct 2005 02:55:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaWA-00065z-Nc for 6lowpan@megatron.ietf.org; Wed, 12 Oct 2005 02:55:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00807 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 02:55:12 -0400 (EDT) Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPagQ-0008C2-R8 for 6lowpan@ietf.org; Wed, 12 Oct 2005 03:05:51 -0400 Received: (qmail 24433 invoked by uid 60001); 12 Oct 2005 06:55:04 -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:Content-Transfer-Encoding; b=w9EnPr4r82vWd1yhn49bxU7fgADRDL/JGVlBpCACPIBMNmhjebHDCxDIiaTxNpl0REwPEeLVoCvby829K2mtrkicFQTfoB58RdMtqYfgXJk1sofXrgR78zvifgNoJjBlcpcP/2P2LXm8HyMkY5n+hdhvy+uVebnXM1yuGVewGPw= ; Message-ID: <20051012065504.24431.qmail@web81903.mail.mud.yahoo.com> Received: from [24.16.92.216] by web81903.mail.mud.yahoo.com via HTTP; Tue, 11 Oct 2005 23:55:04 PDT Date: Tue, 11 Oct 2005 23:55:04 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] format document issues To: Samita Chakrabarti , nandakishore.kushalnagar@intel.com In-Reply-To: <200510062324.j96NOT3x226490@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I've appended some comments to Samita's. ---------Issue from the previous meeting: Issue 1: Christian Huitema suggested looking at existing IANA registries for protocol types to avoid having to set up another one. Specifically, he suggested looking at IP protocol identifiers. Other people suggested looking at link-layer registries such as Ethertype and PPP protocol IDs. This item requires further work. [6lowpan at IETF 63 ] When examining a specific registry, we should make sure that it actually is a good fit. The payloads for the 6lowpan encapsulation are somewhat 6lowpan specific. Raw IPv6 packets are just one type; we also will have a number of rather 6lowpan specific header compression schemes. In addition, routing and registration/management messages are quite likely to be entirely 6lowpan specific. One other consideration would be whether the 6lowpan registrations would place an undue burden on the original registry. E.g., there are only 256 IP protocol numbers, which makes them a scarce resource. One other way to manage the number space would be to make one or more existing registries part of the 6lowpan number space. E.g., there could be a selector that chooses between IP protocol numbers and PPP protocol numbers (assuming both actually make sense in this context). IP protocol numbers are 8 bits. PPP protocol numbers are 14 bits (expressed in either 8 or 16 bits depending on the low order bit of the first byte). NK: I looked at IANA and could not find a protocol type that had the width of 11 bits and that served the purpose of what we needed. Please let me know if I am wrong here. As for adding ether type may be a good solution, the document does mention about adding a SNAP header. If we were to add the SNAP header we could potentially remove the protocol field in the adaptation layer. But as we discussed in the meeting, how difficult would it be to get a packet that has ethertype for 6lowpan specific packets such as route messages, etc. Another issue with adding 8 bytes of LLC/SNAP is that we will loose those bytes from the header. If there are no heart burns about this, then we could perhaps choose to add the LLC/SNAP header and remove protocol field from the header and instead use 6lowpan type field whose values are defined within this document to indicate types of 6lowpan messages. (routing, discovery, etc). This is of course assuming that 6lowpan could be made a type under the definition of SNAP protocol type. Any suggestions? ---------------------- SC: It'd be a mistake, IMHO to add LLC/SNAP (8 bytes) in 802.15.4 layer in order to use only a few bits for protocol number. Even for ethernet, LLC/SNAP only uses 2 bytes in a meaningful way and adds extra overhead of bytes (SSAP=DSSAP always same). Protocol type needs to be looked at every LL-hop - thus header compression at this level would not work. Also, the Lowpan protocol type different than the IP-protocol (L3) type, folks may want to run a lowpan specific protocol that does not run on the IP layer. Thus it may not be a good idea to hold space from IP-protocol space. I don't understand the process of protocol type assignment - but can we ask for a different space for LowPan protocol types ? Also, would like to see 11 bits to shrink to a lower number say 8bits or so. -------------------------- gab: I agree with Samita about LLC/SNAP encapsulation not being desirable. This is what I wrote in the draft (removed when the draft changed from an individual submission to an official WG document): (Available at http://www.watersprings.org/pub/id/draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt) NOTE: In traditional IEEE 802 applications, a further 8 octets are taken up by LLC/SNAP encapsulation [RFC1042], which would leave only 73 octets for upper layer protocols (e.g., IP). SNAP encapsulation is not used in this specification. Any heartburn about this? Must think about compatibility with other applications (what do these do?). To guarantee interoperability, we might want to add the SNAP header. It's just more fixed overhead, as instead of following with the ether_type for IPv6 (and overloading the version field as per the hack in RFCs 1144 and 2507), we would want to follow the SNAP header with a new identifier for the adaptation layer defined below. As can be seen from the above, I did look at existing protocol type fields like ethertype and PPP DLL. At that time, our protocol type was only 5 bits, which allowed for only 1 octect of overhead before the IPv6 packet. No existing protocol type was small enough. Besides, we need to have the flexibility of defining several more types, cuz, as alluded to above, we need to carry not just IPv6, but other variants of that header (for the different compression schemes) as well as other protocols (e.g., our adaptations of routing protocols like AODV and DyMO which populate the routing tables for later use by the mesh delivery mechanism). It might be tough to obtain ether_types for stuff that is specific to 6lowpan. Instead, we would probably end up obtaining only one ether_type for 6lowpan encapsulation. And then we could still have our own encapsulation overhead on top of that, so the minimum overhead would not be 8 octets, but 10, by the time we're done. As for why have our own name space: We're doing compression specific to 6lowpan as it integrates compression of L3 IPv6 header with L2 802.15.4 header, so is not a general scheme. Our new registry is for our private use within 6lowpan encapsulation headers. I don't see what the issue is with that, as literally hundreds of protocols already define their own private name spaces. Many protocols define more than one (e.g., MIPv6). This is so common that *all* RFCs are supposed to have an IANA considerations section. Perhaps the worry is that we'd end up duplicating several of the very long protocol registries already in existence. Well, the idea is that most apps would use IPv6, and for that there is an existing protocol space. Nothing new there. The comment about our laying to much of a burden on the limited IP protocol space of 256 total types, I don't see how this applies. We're not using the IP protocol space. We're asking IANA for our own name space, so we don't use anybody's name space. IP is a payload within lowpan, not the other way around. Incidentally, I see that the IANA considerations needs to be updated as it still reflects the old field lengths of 5 or 7 for protocol type Issue 2 ---Technical work required on encapsulation/format specification: ----- NK: I think I understand what KiHyungKim was getting at here. Correct me if I am wrong, his argument was that the source address also changes on a link by link basis and just having a destination address and compressing out the IP source and destination address will not work. We need to also add another field that specifies a "multi hop" source address field when the M bit is present. --------------------------------- SC: I don't quite understand the issue of header compression here for IPv6 case. We are doing header compression in IPv6 header, not on 802.15.4 MAC layer address. Since M bit signifies that this packet is routed in LL2-multihop fashion, the final destination would be a MAC-address. I don't see any header compression of final destination when M bit set. Perhaps the draft is not clear about that in the area where it describes LowPan unfragmented header format with M bit. The draft needs to clarify the final destination address type. --------------------------------- gab: Samita mentions that the draft is not clear as to the final destination address type in the final destination header. I do believe the draft is already clear in this respect: Under Figure 9 in Section 9: Address: This is the final destination's link-layer address. This document assumes that this field is 64 bits long, but a future revision may add support for short addresses (16 bits). It's also mentioned several times throughout that section. As for the main question of whether another field for the originator source address is needed, I think there is a misunderstanding: the link-layer source address does not change on a hop-by-hop basis. The handling rules are: If a node wishes to use a forwarder to deliver a packet, it puts the forwarder's link-layer address in the link-layer destination address field. It must also set the 'M' bit, and include a "Final Destination" field with the final destination's link-layer address. Similarly, if a node receives a frame with the 'M' bit set, it must look at the "Final Destination" field to determine the real destination. Upon consulting its routing table, it determines what the next hop towards that destination should be. The node then reduces the "Hops Left" field. If the result is zero, the node discards the packet. Otherwise, it puts the next hop's address in the link-layer destination address field, and transmits the packet. If upon examining the "Final Destination" field the node determines that it has direct reachability, it removes the "Final Destination" field, sets that final address as the link-layer destination address, and transmits the packet. There is no mention of the link-layer source address changing on a hop-by-hop basis, only the destination address does so. So at each intermediate node, as well as at the final destination, what is known is the link-layer source address. What is not known is the link-layer address of the preceding hop, so a node knows who originated the packet it just received, but it does not know which node finally delivered it to it. In AODV/LOAD this is the "reverse route address". But of course, routing protocols like AODV or LOAD don't use the M bit, they have originator and destination address fields within the RREQ. This usage of only one extra address field is something I saw in 802.11 (although they do have the capability of using two extra fields). Hopefully, this clarifies the handling rules. Perhaps it's a good idea to state clearly that the source address does not change hop-by-hop. The main question is: are there any issues with this? It saves one address field, but are there any issues? -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 12 03:07:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaiI-000175-Uv; Wed, 12 Oct 2005 03:07:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaiI-00016x-0t for 6lowpan@megatron.ietf.org; Wed, 12 Oct 2005 03:07:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01456 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 03:07:43 -0400 (EDT) Received: from web81909.mail.mud.yahoo.com ([68.142.207.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPasY-000063-HW for 6lowpan@ietf.org; Wed, 12 Oct 2005 03:18:22 -0400 Received: (qmail 81647 invoked by uid 60001); 12 Oct 2005 07:07:36 -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:Content-Transfer-Encoding; b=JjT6UBhtOInPxCGdTLcRVABwq4oh7XH9rMjix/dRUN7oLFDU78QqcgbbmvCTaz5CJMXDPxNZineyIKUtd+2dt/YP35yMPo6tAL0PNJNonfdZHAE4+UhD/7wNBx2jpO9A826uJ/w1R2FnyVbb7K3acFXo91lvNClvqNGSsrlEwQY= ; Message-ID: <20051012070736.81645.qmail@web81909.mail.mud.yahoo.com> Received: from [24.16.92.216] by web81909.mail.mud.yahoo.com via HTTP; Wed, 12 Oct 2005 00:07:36 PDT Date: Wed, 12 Oct 2005 00:07:36 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] how many drafts To: Samita Chakrabarti In-Reply-To: <200510111904.j9BJ4d4A518576@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- Samita Chakrabarti wrote: > > Hi Gabe, > > Thanks for your response. > > I have a few questions regarding the routing solutions on Lowpan: > > - Are we going to go ahead with lowpan-aodv draft? > If so, I'd like to pass some modification requests that we have > discovered during an exercize of its implementation. > > - Are we going to merge lowpan-aodv and LOAD draft? > - If yes, then we need to review this draft seriously. It is RFC3561 > based. As Daniel mentioned, LOAD is what we're working on going forward. > > IMHO, neigther AODV-bis nor RFC3561 are quite suitable for lowpan routing; > It'd be much nicer if we come up with a lowpan routing protocol based on > DYMO/AODV/AODVbis flavors. It is unlikely that lowpan tiny devices will > route packets for the regular internet, hence the modified standard version > protocol makes more sense for the lowpan world. I believe an adapted protocol is the idea, yes. I think inventing something new won't happen (at least not in this WG, it might in MANET or something else in the routing area). But I believe it should be ok for lowpan to adapt an existing protocol. Perhaps not all fields are needed. Perhaps not all features are needed. The current drafts already started the adaptation because I don't believe they include all the bells and whistles in aodv or dymo, right? I guess we're in agreement. > I am not quite sure how it is useful to have lowpan-aodv, lowpan-dymo and > lowpan-aodvbis etc. as opposed to one draft that covers lowpan concerns > and is based on parts of AODV/AODVbis and DYMO features. That way we will > not be tying lowpan's fate on success of the corresponding protocols > through the IETF process. But I may be too optimistic. Again, these protocols are already adaptations of any of the above, right? So I'm not sure they'll create hard dependencies. In other words, within the LOAD document, AODV should perhaps appear as an informational reference. It is not a normative reference because implementing AODV per the RFC is not a pre-requisite for this to work and be interoperable. Actually, implementing it won't help lowpan meshing, cuz AODV per the RFC uses UDP as transport, whereas LOAD (or any other mesh for lowpan protocol) uses the lowpan adaptation layer as transport. So one could argue that the AODV RFC (or AODV-bis draft) is not normative, so it wouldn't tie LOAD in the publication process. But we're *very* far from that problem so I wouldn't worry about it yet. -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 12 04:19:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPbkB-0003Aq-H4; Wed, 12 Oct 2005 04:13:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPbk9-0003Aj-GC for 6lowpan@megatron.ietf.org; Wed, 12 Oct 2005 04:13:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04610 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 04:13:42 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPbuO-0001yC-Sy for 6lowpan@ietf.org; Wed, 12 Oct 2005 04:24:22 -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 <0IO800E7CMUCGS@mailout2.samsung.com> for 6lowpan@ietf.org; Wed, 12 Oct 2005 17:13:24 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IO800GVPMUCPM@mmp2.samsung.com> for 6lowpan@ietf.org; Wed, 12 Oct 2005 17:13:24 +0900 (KST) Date: Wed, 12 Oct 2005 17:14:24 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] how many drafts To: itijibox-6lowpan@yahoo.com, Samita Chakrabarti Message-id: <04a901c5cf04$f4f8c4d0$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20051012070736.81645.qmail@web81909.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > Again, these protocols are already adaptations of any of the above, right? > So I'm not sure they'll create hard dependencies. In other words, within the > LOAD document, AODV should perhaps appear as an informational reference. > It is not a normative reference because implementing AODV per the RFC > is not a pre-requisite for this to work and be interoperable. Actually, > implementing it won't help lowpan meshing, cuz AODV per the RFC uses UDP > as transport, whereas LOAD (or any other mesh for lowpan protocol) uses > the lowpan adaptation layer as transport. So one could argue that the > AODV RFC (or AODV-bis draft) is not normative, so it wouldn't tie LOAD > in the publication process. But we're *very* far from that problem so > I wouldn't worry about it yet. Please make sure what implications are described in LOAD. 3. Overview This section describes the distinctive features of LOAD compared to AODV. LOAD is defined to be operating on top of the adaptation layer instead of the transport layer. Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 12 16:25:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnA6-0005Qx-Hg; Wed, 12 Oct 2005 16:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnA4-0005Q3-Dy for 6lowpan@megatron.ietf.org; Wed, 12 Oct 2005 16:25:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28015 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 16:25:11 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnKM-0002E1-2b for 6lowpan@ietf.org; Wed, 12 Oct 2005 16:35:58 -0400 Received: from jurassic.eng.sun.com ([129.146.58.37]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9CKP51L010553; Wed, 12 Oct 2005 14:25:05 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9CKP40h957185; Wed, 12 Oct 2005 13:25:04 -0700 (PDT) Message-Id: <200510122025.j9CKP40h957185@jurassic.eng.sun.com> Date: Wed, 12 Oct 2005 13:22:51 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [6lowpan] format document issues To: Samita.Chakrabarti@eng.sun.com, nandakishore.kushalnagar@intel.com, itijibox-6lowpan@yahoo.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wjv5BEe8qdMT+pJQi9gF6g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Gabe, Please see my comments below. > There is no mention of the link-layer source address changing on a hop-by-hop > basis, only the destination address does so. So at each intermediate node, as well > as at the final destination, what is known is the link-layer source address. > What is not known is the link-layer address of the preceding hop, so a node > knows who originated the packet it just received, but it does not know which > node finally delivered it to it. In AODV/LOAD this is the "reverse route address". > But of course, routing protocols like AODV or LOAD don't use the M bit, they have > originator and destination address fields within the RREQ. This usage of only one > extra address field is something I saw in 802.11 (although they do have the > capability of using two extra fields). > > Hopefully, this clarifies the handling rules. Perhaps it's a good idea to state clearly > that > the source address does not change hop-by-hop. The main question is: are there any > issues with this? It saves one address field, but are there any issues? Normally, in IP-routing, the ethernet (link-layer) source address is changed at each hop and the link-layer destination address is set according to the next-hop IP address. Thus, the link-layer chooses its source interface MAC address at each hop while the IP-packet contains the orginal source address. Since we are now doing something new here - i,e. route at the link-layer, we still need to somehow know where the packet came from, i.e. the last sender or forwarder's link-layer address. IEEE802.15.4 has ACK frames, during data transfer, it may require a ACK from the next hop - how does the nexthop know where data packet came from ? How does it inform any error to the immediate sender if it does not know its link-layer address? Moreover, the previous hop may depend on receiving ACK to determine if a forward link is broken. Thus the link-layer frame _should_ have the correct src and dst address. That's why I mentioned in my last mail about a solution that maps the 'reverse route' mentioned in RFC3561. RFC3561 mentions: The intermediate node also updates its route table entry for the node originating the RREQ by placing the next hop towards the destination in the precursor list for the reverse route entry -- i.e., the entry for the Originator IP Address field of the RREQ message data. In our case, the AODV packet in the data section will have the originator link-layer address, thus at each intermediate node, upon RREQ, it sets a reverse route as following ( addresses are link-layer addresses): DEST next hop SEq# Originator previous-node originator's seq# This way, we can use reverse route *towards* the originator link-layer address. It is the same way one does at the IP-layer. The only difference here is that we must know our last link-layer sender's address. BTW, reverse routes are better explained in RFC3561 than in aodvbis. Thus, the format document can save one address field (for originator source link-layer addr) by requiring the routing protocol to provide information on originator address so that the intermediate node can setup reverse route. Alternately, the intermediate node will have to do route-discovery for the originator - that is certainly not effecient. Hope this clarifies the point. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 12 19:24:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPpxG-0005U6-5C; Wed, 12 Oct 2005 19:24:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPpxE-0005Ty-UN for 6lowpan@megatron.ietf.org; Wed, 12 Oct 2005 19:24:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11519 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 19:24:08 -0400 (EDT) Received: from fmr18.intel.com ([134.134.136.17] helo=orsfmr003.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPq7b-0008OO-Mi for 6lowpan@ietf.org; Wed, 12 Oct 2005 19:34:58 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9CNO1OL007837 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 23:24:01 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9CNNHxR003021 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 23:24:01 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101216193212015 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 16:19:33 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 15:26:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [6lowpan] goals draft issues Date: Wed, 12 Oct 2005 15:17:08 -0700 Message-ID: <9D602ABCE51B0B488BF857A4787939B506124E15@orsmsx410> Thread-Topic: [6lowpan] goals draft issues Thread-Index: AcXO+O0iPvugHph/TzWZVWwJlRt0zQAdJ8iA From: "Kushalnagar, Nandakishore" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 12 Oct 2005 22:26:54.0289 (UTC) FILETIME=[0C856410:01C5CF7C] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Thanks to all who responded. Thanks Samita for the paper. So with this conversation, I think it makes sense that given the 802.15.4 spec, it is clear that some work needs to be done in making the link layer more secure (or tuning there of) but this may be beyond the scope of our current charter.=20 The more relevant problem that this WG need to address would be to mention a need for a comprehensive end to end security given that current security protocols were not designed for 6lowpan devices. I will add something along these lines in the draft. Regards, Nandu -----Original Message----- From: gabriel montenegro [mailto:itijibox-6lowpan@yahoo.com]=20 Sent: Tuesday, October 11, 2005 11:48 PM To: Samita Chakrabarti; Kushalnagar, Nandakishore Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] goals draft issues 802.15.4b is improving somewhat the link security. I *believe*, for example, that they have deprecated (or recommended against) CBC-CTR (one of the weaknesses identified in=20 the paper) and recommend CCM* (also recommended by ZigBee according to their public tutorials at their open house events), supposedly a much improved mode. Not sure about other security related changes, but I'm sure there are plenty of 15.4b-savvy folks on this alias. Hopefully, they can respond. It might even be a good idea to have a quick update by one of those folks at the meeting. -gabriel ps - another thing 15.4b is doing is increasing the speed for the sub-1GHz PHYs to bring them up to 250 Kbps. --- Samita Chakrabarti wrote: >=20 >=20 > > From: "Kushalnagar, Nandakishore" > > To: <6lowpan@ietf.org> >=20 > Issue: >=20 > The security considerations are still "TBD". Gabriel Montenegro proposed > mining the security considerations section of the format document for > possible input. >=20 > =20 >=20 > NK: >=20 > I am soliciting for some feedback here as to what this section is > supposed to have?=20 >=20 > Chairs/others? > -------------------------------- >=20 > Hi Nandu, >=20 > In the first meeting of LowPan wg (BOF?), folks brought up the > security consideration issues. It was mentioned that 802.15.4 > link-layer security should be enough. The following paper > depicts some of the problem scenarios with 802.15.4 security: >=20 > http://www.cs.berkeley.edu/~nks/papers/15.4-wise04.pdf >=20 > I was told by a security expert that 802.15.4 security is not > good enough. The above paper recomends a few modifications - does > anyone know if IEEE 802.15.4 workgroup is looking into improving > the link-layer security?=20 >=20 > I don't think IPsec security is a feasible solution on this kind > of small devices where 6lowpan would eventually run. It'd be=20 > interesting to get people's viewpoint on this. >=20 > Since we are routing at the link-layer, it would be better if we > have tighter link-level security and then application level security > using crypto. Perhaps the protocols running on top of LowPan > can run some security protocols that are appropriate for this kind > of network. >=20 > Comments? >=20 > -Samita >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan >=20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 12 21:02:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPrUH-0007NA-1V; Wed, 12 Oct 2005 21:02:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPrUC-0007N5-OA for 6lowpan@megatron.ietf.org; Wed, 12 Oct 2005 21:02:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14869 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 21:02:18 -0400 (EDT) Received: from web81906.mail.mud.yahoo.com ([68.142.207.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPreb-0001t6-Is for 6lowpan@ietf.org; Wed, 12 Oct 2005 21:13:07 -0400 Received: (qmail 17386 invoked by uid 60001); 13 Oct 2005 01:02:10 -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:Content-Transfer-Encoding; b=XtIaaYGZ2XkVN0Acd7QBovfWVY9Vc09OQb2IOt/2X6u0lQvTGMnUgOj+rLL7zDiao4ls7uXE60hw9ho1CM+pE5Qh2KC4wfVnBnR59Hq85SAZZL6pOq9M0lQ8Z1Nvs1+3ablAMFrhzKlMZb7sOC7Frxpf5vWcIqSKSyxK92be4ZY= ; Message-ID: <20051013010210.17384.qmail@web81906.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81906.mail.mud.yahoo.com via HTTP; Wed, 12 Oct 2005 18:02:10 PDT Date: Wed, 12 Oct 2005 18:02:10 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] format document issues To: Samita Chakrabarti , nandakishore.kushalnagar@intel.com, itijibox-6lowpan@yahoo.com In-Reply-To: <200510122025.j9CKP40h957185@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Samita, --- Samita Chakrabarti wrote: > Thus, the format document can save one address field (for originator source > link-layer addr) by requiring the routing protocol to provide information > on originator address so that the intermediate node can setup reverse route. > Alternately, the intermediate node will have to do route-discovery for the > originator - that is certainly not effecient. > Hope this clarifies the point. I *think* we're repeating each other. From my post: > But of course, routing protocols like AODV or LOAD don't use the M bit, > they have > originator and destination address fields within the RREQ. So we don't even have to require "the routing protocol to provide information on originator address so that the intermediate node can setup reverse route." The required info is already in the RREQ, right? -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 12 21:23:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EProu-0004Th-9u; Wed, 12 Oct 2005 21:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EProt-0004Tc-Dt for 6lowpan@megatron.ietf.org; Wed, 12 Oct 2005 21:23:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15685 for <6lowpan@ietf.org>; Wed, 12 Oct 2005 21:23:40 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPrzF-0002Le-Fy for 6lowpan@ietf.org; Wed, 12 Oct 2005 21:34:29 -0400 Received: from jurassic.eng.sun.com ([129.146.108.38]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9D1NbHT012367; Wed, 12 Oct 2005 18:23:37 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9D1Nb6C228919; Wed, 12 Oct 2005 18:23:37 -0700 (PDT) Message-Id: <200510130123.j9D1Nb6C228919@jurassic.eng.sun.com> Date: Wed, 12 Oct 2005 18:21:23 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [6lowpan] format document issues To: itijibox-6lowpan@yahoo.com, nandakishore.kushalnagar@intel.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iOdUDw+ytON+Z6S6UkrAxw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org >I *think* we're repeating each other. From my post: Sorry, if I am repeating myself. I agree with you on the following item. All I said, that there's no need to add extra field for originator address and we can change the source MAC address at each lowpan-hop as well. > > > But of course, routing protocols like AODV or LOAD don't use the M bit, > > they have > > originator and destination address fields within the RREQ. > > So we don't even have to require "the routing protocol to provide information > on originator address so that the intermediate node can setup reverse route." > The required info is already in the RREQ, right? Sure, the required info is within the RREQ. But that assumes we use AODV, LOAD, DYMO etc. which already use RREQ. Since Lowpan layer is not tying up with any particular routing protocol, hence someone in future can try to develop a new routing protocol that might be different than what we expect today at RREQ. Thus, clarifying that requirement will help the implementors today as to how to setup the reverse lowpan-route and lowpan-routing protocol developers in the future. That's all. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 13 08:24:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ28p-00073R-0S; Thu, 13 Oct 2005 08:24:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ28n-00071O-Bm for 6lowpan@megatron.ietf.org; Thu, 13 Oct 2005 08:24:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14256 for <6lowpan@ietf.org>; Thu, 13 Oct 2005 08:24:52 -0400 (EDT) Received: from pxy2nd.nifty.com ([202.248.175.14]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQ2JI-0001la-0p for 6lowpan@ietf.org; Thu, 13 Oct 2005 08:35:49 -0400 Received: (qmail 8363 invoked from network); Thu, 13 Oct 2005 21:24:27 +0900 Received: from unknown (HELO aps501) (172.22.60.114) by smb507.nifty.com with SMTP; Thu, 13 Oct 2005 21:24:27 +0900 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=pxy2nd-default; d=mbj.nifty.com; b=GCoTC/ofGg0E1MAEHLC2Hmp55XNcX57QnZJV283xL4/qxyp9W3RI+D+5SQSkg3Vp4bZHEUTynKSUP0FSpYzRjw== ; Message-ID: <4823110.1129206267292.y-ig@mbj.nifty.com> Date: Thu, 13 Oct 2005 21:24:27 +0900 (JST) From: Yuichi To: 6lowpan@ietf.org Subject: [6lowpan] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Priority: normal X-Mailer: @nifty Webmail 2.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I'm interested in mesh network of 6lowpan and have a question. draft-ietf-6lowpan-format-00 mentions (Section9 ): This implies that the "Final Destination" field will immediately follow an unfragmented packet as per Figure 1 (i.e., preceding the IPv6 Header), or immediately following the first fragment header as per Figure 2. Question: When a second link fragment arrives before the first fragment, how does a intermediate node determine the forwading node? Sincerely _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 13 09:03:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2kU-000856-N2; Thu, 13 Oct 2005 09:03:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2kS-00083r-VX for 6lowpan@megatron.ietf.org; Thu, 13 Oct 2005 09:03:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16053 for <6lowpan@ietf.org>; Thu, 13 Oct 2005 09:03:47 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ2ux-0002jD-8Y for 6lowpan@ietf.org; Thu, 13 Oct 2005 09:14:44 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IOA001NLUXZMQ@mailout1.samsung.com> for 6lowpan@ietf.org; Thu, 13 Oct 2005 22:03:36 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IOA00CV1UXZVF@mmp1.samsung.com> for 6lowpan@ietf.org; Thu, 13 Oct 2005 22:03:35 +0900 (KST) Date: Thu, 13 Oct 2005 22:04:38 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] To: Yuichi , 6lowpan@ietf.org Message-id: <061101c5cff6$aaf31910$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4823110.1129206267292.y-ig@mbj.nifty.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > I'm interested in mesh network of 6lowpan and have a question. > > draft-ietf-6lowpan-format-00 mentions (Section9 ): > This implies that the "Final Destination" field > will immediately follow an unfragmented packet as per Figure 1 (i.e., > preceding the IPv6 Header), or immediately following the first > fragment header as per Figure 2. > > Question: > When a second link fragment arrives before the first fragment, > how does a intermediate node determine the forwading node ? Once receiving the first fragment encapsulation header (in the fragmentation case), the node can forward its packets. It's almost certain to reduce packet size over 6lowpan link in my understanding. Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 13 11:41:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5Cg-0002mR-8g; Thu, 13 Oct 2005 11:41:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5Cc-0002lo-MW for 6lowpan@megatron.ietf.org; Thu, 13 Oct 2005 11:41:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24603 for <6lowpan@ietf.org>; Thu, 13 Oct 2005 11:41:02 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ5N4-0007Ao-M9 for 6lowpan@ietf.org; Thu, 13 Oct 2005 11:52:00 -0400 Received: by zproxy.gmail.com with SMTP id n1so421828nzf for <6lowpan@ietf.org>; Thu, 13 Oct 2005 08:40:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index:message-id; b=Kw3bEt1IYYTLC3oGv8pGEkfb5ek9KTYZtD6HUeOPrqYWG+iFiP740as7a68YJ7GHrDQaXSt4Ll+Da6iwG0kqvnFg3Alr0NSCjKXVwGlo9/9hNlQ7NnMlsV9Enc4WJ22Cjd/N9N07uEr9Q6WjenvAyqRgpYM6UTDZQm3i/H5PJL4= Received: by 10.36.104.20 with SMTP id b20mr2394146nzc; Thu, 13 Oct 2005 08:40:56 -0700 (PDT) Received: from ncman ( [202.30.31.245]) by mx.gmail.com with ESMTP id r1sm2384464nzd.2005.10.13.08.40.55; Thu, 13 Oct 2005 08:40:56 -0700 (PDT) From: "Ki-Hyung Kim" To: "'gabriel montenegro'" , , "'Samita Chakrabarti'" , Subject: RE: [6lowpan] format document issues Date: Fri, 14 Oct 2005 00:40:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20051013010210.17384.qmail@web81906.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXPke3+7b3qOUz3QnKN5qzC+VF0MAAdVSqw Message-ID: <434e8008.10c98bae.335c.16d2@mx.gmail.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Sorry for this late reply on this issue about the source address compression in multi-hop environment. After raising this issue in August, our research group has studied on the reporting of RERRs to the originators without a source address and a precursor list. The purpose of the research is to search a light weight RERR reporting scheme without putting a source address in the format and maintaining precursor lists on routing tables of every nodes. If I say the conclusion first, the source address is at least not required in the 6lowpan format for reporting RERRs to the originators. In AODV, every intermediate node on a routing path keeps a precursor list on each routing entry for a destination. The setting up of the precursor list is done when processing RREQ and RREP. Thus, data packets do not need to have the originator address in AODV. What about 6lowpan? If a routing scheme of 6lowpan maintains precursor lists for routing as AODV does, data packets at least do not need to have the originator address. This issue could be handled in the routing documents. Currently, we have submitted a paper to a conference about the RERR reporting schemes. In the paper, we have proposed and evaluated several RERR reporting schemes including 1) unicasting a RERR back in one-hop only, 2) broadcasting backward a RERR in one-hop only, 3) broadcasting backward based on the routing table information, 4) using precursor lists, and 5) using the originator address if it is assumed to be added to the 6lowpan format document. In the preliminary performance evaluation result, (1) has shown the best result, and then (4) comes next in terms of the communication throughput. Also (1) showed the minimal implementation complexity. The detailed description of the schemes and performance results shall be shown shortly. -- Ki-Hyung Kim Associate Professor Division of Information and Computer Eng., Ajou University Wonchun-Dong, Yeongtong-Gu, Suwon, Korea 442-749 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-1811 http://ilab.ajou.ac.kr/kkim86/index.htm > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of gabriel montenegro > Sent: Thursday, October 13, 2005 10:02 AM > To: Samita Chakrabarti; nandakishore.kushalnagar@intel.com; itijibox- > 6lowpan@yahoo.com > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] format document issues > > Samita, > > --- Samita Chakrabarti wrote: > > Thus, the format document can save one address field (for originator > source > > link-layer addr) by requiring the routing protocol to provide > information > > on originator address so that the intermediate node can setup reverse > route. > > Alternately, the intermediate node will have to do route-discovery for > the > > originator - that is certainly not effecient. > > Hope this clarifies the point. > > I *think* we're repeating each other. From my post: > > > But of course, routing protocols like AODV or LOAD don't use the M bit, > > they have > > originator and destination address fields within the RREQ. > > So we don't even have to require "the routing protocol to provide > information > on originator address so that the intermediate node can setup reverse > route." > The required info is already in the RREQ, right? > > -gabriel > > > _______________________________________________ > 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 Oct 13 12:52:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6JO-0000Ae-On; Thu, 13 Oct 2005 12:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6JM-0000AY-Pa for 6lowpan@megatron.ietf.org; Thu, 13 Oct 2005 12:52:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28382 for <6lowpan@ietf.org>; Thu, 13 Oct 2005 12:52:04 -0400 (EDT) Received: from web81911.mail.mud.yahoo.com ([68.142.207.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQ6Tt-0000e4-SP for 6lowpan@ietf.org; Thu, 13 Oct 2005 13:03:03 -0400 Received: (qmail 66274 invoked by uid 60001); 13 Oct 2005 16:51:58 -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:Content-Transfer-Encoding; b=NOAHfNlwrg9SUf4RgqY2uwTailpPa0BdQwd/dcMTOhdtJ8qhvcjqkXXb/8sTtRmMHB3XhG8dV01SfH+Ja3p6i1cAV/zjPScda23QsUYLGfDVkliH0gDD5SRXETLqQMly89JWJ18bI8ESVYp3leTX7rC7G1G0aEhZEemS6cw1H6E= ; Message-ID: <20051013165158.66272.qmail@web81911.mail.mud.yahoo.com> Received: from [24.16.92.216] by web81911.mail.mud.yahoo.com via HTTP; Thu, 13 Oct 2005 09:51:57 PDT Date: Thu, 13 Oct 2005 09:51:57 -0700 (PDT) From: gabriel montenegro Subject: RE: [6lowpan] format document issues To: Ki-Hyung Kim , "'Samita Chakrabarti'" , nandakishore.kushalnagar@intel.com In-Reply-To: <434e8008.10c98bae.335c.16d2@mx.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Prof Kim, This is great: results! Q1: Are these experimental or simulation results? Q2: Did you use the handling rules as per the draft, or did you modify the link-layer source address at every hop, as implied by your post a while back? -gabriel --- Ki-Hyung Kim wrote: > Sorry for this late reply on this issue about the source address compression > in multi-hop environment. > After raising this issue in August, our research group has studied on the > reporting of RERRs to the originators without a source address and a > precursor list. > The purpose of the research is to search a light weight RERR reporting > scheme without putting a source address in the format and maintaining > precursor lists on routing tables of every nodes. > > If I say the conclusion first, the source address is at least not required > in the 6lowpan format for reporting RERRs to the originators. > > In AODV, every intermediate node on a routing path keeps a precursor list on > each routing entry for a destination. The setting up of the precursor list > is done when processing RREQ and RREP. > Thus, data packets do not need to have the originator address in AODV. > > What about 6lowpan? > If a routing scheme of 6lowpan maintains precursor lists for routing as AODV > does, data packets at least do not need to have the originator address. > This issue could be handled in the routing documents. > > Currently, we have submitted a paper to a conference about the RERR > reporting schemes. > In the paper, we have proposed and evaluated several RERR reporting schemes > including 1) unicasting a RERR back in one-hop only, 2) broadcasting > backward a RERR in one-hop only, 3) broadcasting backward based on the > routing table information, 4) using precursor lists, and 5) using the > originator address if it is assumed to be added to the 6lowpan format > document. > > In the preliminary performance evaluation result, (1) has shown the best > result, and then (4) comes next in terms of the communication throughput. > Also (1) showed the minimal implementation complexity. > > The detailed description of the schemes and performance results shall be > shown shortly. > > -- > Ki-Hyung Kim > Associate Professor > Division of Information and Computer Eng., Ajou University > Wonchun-Dong, Yeongtong-Gu, Suwon, Korea 442-749 > Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-1811 > http://ilab.ajou.ac.kr/kkim86/index.htm > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > > Of gabriel montenegro > > Sent: Thursday, October 13, 2005 10:02 AM > > To: Samita Chakrabarti; nandakishore.kushalnagar@intel.com; itijibox- > > 6lowpan@yahoo.com > > Cc: 6lowpan@ietf.org > > Subject: Re: [6lowpan] format document issues > > > > Samita, > > > > --- Samita Chakrabarti wrote: > > > Thus, the format document can save one address field (for originator > > source > > > link-layer addr) by requiring the routing protocol to provide > > information > > > on originator address so that the intermediate node can setup reverse > > route. > > > Alternately, the intermediate node will have to do route-discovery for > > the > > > originator - that is certainly not effecient. > > > Hope this clarifies the point. > > > > I *think* we're repeating each other. From my post: > > > > > But of course, routing protocols like AODV or LOAD don't use the M bit, > > > they have > > > originator and destination address fields within the RREQ. > > > > So we don't even have to require "the routing protocol to provide > > information > > on originator address so that the intermediate node can setup reverse > > route." > > The required info is already in the RREQ, right? > > > > -gabriel > > > > > > _______________________________________________ > > 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 Oct 13 13:33:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6xE-0003zp-6G; Thu, 13 Oct 2005 13:33:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6xC-0003zh-1R for 6lowpan@megatron.ietf.org; Thu, 13 Oct 2005 13:33:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00567 for <6lowpan@ietf.org>; Thu, 13 Oct 2005 13:33:13 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ77k-0001lr-De for 6lowpan@ietf.org; Thu, 13 Oct 2005 13:44:12 -0400 Received: by zproxy.gmail.com with SMTP id n1so445453nzf for <6lowpan@ietf.org>; Thu, 13 Oct 2005 10:33:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index:message-id; b=WQH5w/D4HNLzOv+6BtztuF3SCIpXtJUUlI6OnGk8HmxI/Rug9/AgSGR+kJ+odaiGAmB+9Tpv5mbYPEpuUn0TNNJoH6ubFIPqS/zjIapgJjNEDKIJkm6Q7OY6FEVXMXwYr8z3xRpDdhZpIcTN/aVSW7ThEu6iShJymmWP0NMpA+I= Received: by 10.36.252.29 with SMTP id z29mr1186629nzh; Thu, 13 Oct 2005 10:33:16 -0700 (PDT) Received: from ncman ( [202.30.31.245]) by mx.gmail.com with ESMTP id j4sm5541210nzd.2005.10.13.10.33.14; Thu, 13 Oct 2005 10:33:15 -0700 (PDT) From: "Ki-Hyung Kim" To: "'gabriel montenegro'" , , "'Samita Chakrabarti'" , Subject: RE: [6lowpan] format document issues Date: Fri, 14 Oct 2005 02:33:07 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20051013165158.66272.qmail@web81911.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQFm3Nw8oBM9R2SDWLBvHBL8ZKkgABPRoA Message-ID: <434e9a5b.45905f74.77a3.329c@mx.gmail.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Please look at the replies below. > -----Original Message----- > From: gabriel montenegro [mailto:itijibox-6lowpan@yahoo.com] > Sent: Friday, October 14, 2005 1:52 AM > To: Ki-Hyung Kim; 'Samita Chakrabarti'; nandakishore.kushalnagar@intel.com > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] format document issues > > Prof Kim, > > This is great: results! > > Q1: Are these experimental or simulation results? That is simulation results. About the Q1: Currently, we are implementing the formatting document and LOAD on a sensor platform. After finishing the implementation, the experimental results will be available. > Q2: Did you use the handling rules as per the draft, or did you modify the > link-layer source address at every hop, as implied by your post a while back? I didn't change anything of the format document on the simulation. Also the link-layer source address is changed at every hop as everybody expected. > > -gabriel > > --- Ki-Hyung Kim wrote: > > > Sorry for this late reply on this issue about the source address > compression > > in multi-hop environment. > > After raising this issue in August, our research group has studied on > the > > reporting of RERRs to the originators without a source address and a > > precursor list. > > The purpose of the research is to search a light weight RERR reporting > > scheme without putting a source address in the format and maintaining > > precursor lists on routing tables of every nodes. > > > > If I say the conclusion first, the source address is at least not > required > > in the 6lowpan format for reporting RERRs to the originators. > > > > In AODV, every intermediate node on a routing path keeps a precursor > list on > > each routing entry for a destination. The setting up of the precursor > list > > is done when processing RREQ and RREP. > > Thus, data packets do not need to have the originator address in AODV. > > > > What about 6lowpan? > > If a routing scheme of 6lowpan maintains precursor lists for routing as > AODV > > does, data packets at least do not need to have the originator address. > > This issue could be handled in the routing documents. > > > > Currently, we have submitted a paper to a conference about the RERR > > reporting schemes. > > In the paper, we have proposed and evaluated several RERR reporting > schemes > > including 1) unicasting a RERR back in one-hop only, 2) broadcasting > > backward a RERR in one-hop only, 3) broadcasting backward based on the > > routing table information, 4) using precursor lists, and 5) using the > > originator address if it is assumed to be added to the 6lowpan format > > document. > > > > In the preliminary performance evaluation result, (1) has shown the best > > result, and then (4) comes next in terms of the communication throughput. > > Also (1) showed the minimal implementation complexity. > > > > The detailed description of the schemes and performance results shall be > > shown shortly. > > > > -- > > Ki-Hyung Kim > > Associate Professor > > Division of Information and Computer Eng., Ajou University > > Wonchun-Dong, Yeongtong-Gu, Suwon, Korea 442-749 > > Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-1811 > > http://ilab.ajou.ac.kr/kkim86/index.htm > > > > > -----Original Message----- > > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf > > > Of gabriel montenegro > > > Sent: Thursday, October 13, 2005 10:02 AM > > > To: Samita Chakrabarti; nandakishore.kushalnagar@intel.com; itijibox- > > > 6lowpan@yahoo.com > > > Cc: 6lowpan@ietf.org > > > Subject: Re: [6lowpan] format document issues > > > > > > Samita, > > > > > > --- Samita Chakrabarti wrote: > > > > Thus, the format document can save one address field (for > originator > > > source > > > > link-layer addr) by requiring the routing protocol to provide > > > information > > > > on originator address so that the intermediate node can setup > reverse > > > route. > > > > Alternately, the intermediate node will have to do route-discovery > for > > > the > > > > originator - that is certainly not effecient. > > > > Hope this clarifies the point. > > > > > > I *think* we're repeating each other. From my post: > > > > > > > But of course, routing protocols like AODV or LOAD don't use the M > bit, > > > > they have > > > > originator and destination address fields within the RREQ. > > > > > > So we don't even have to require "the routing protocol to provide > > > information > > > on originator address so that the intermediate node can setup reverse > > > route." > > > The required info is already in the RREQ, right? > > > > > > -gabriel > > > > > > > > > _______________________________________________ > > > 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 Oct 13 14:31:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7rK-0005u7-FE; Thu, 13 Oct 2005 14:31:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7rI-0005u0-3k for 6lowpan@megatron.ietf.org; Thu, 13 Oct 2005 14:31:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04153 for <6lowpan@ietf.org>; Thu, 13 Oct 2005 14:31:11 -0400 (EDT) Received: from web81906.mail.mud.yahoo.com ([68.142.207.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQ81n-0003SW-2C for 6lowpan@ietf.org; Thu, 13 Oct 2005 14:42:11 -0400 Received: (qmail 47971 invoked by uid 60001); 13 Oct 2005 18:31:02 -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:Content-Transfer-Encoding; b=NgWnO56w4/2t6NwdZk9OZwSYCb0/6sXQEeCILYANT1lBIBLzjmzwC0WjN94n9C5Hjz+QkVELIAn7rc67E7lW7+bnm2gSsQxGopt+1O8KbzP+IhKiSG6su/hY+nI4Q0z3q//I4fidsln9L9A/XPqXn87qSKofdLtQutvmoMoGUnQ= ; Message-ID: <20051013183102.47969.qmail@web81906.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81906.mail.mud.yahoo.com via HTTP; Thu, 13 Oct 2005 11:31:02 PDT Date: Thu, 13 Oct 2005 11:31:02 -0700 (PDT) From: gabriel montenegro Subject: RE: [6lowpan] format document issues To: Ki-Hyung Kim , "'Samita Chakrabarti'" , nandakishore.kushalnagar@intel.com In-Reply-To: <434e9a5b.45905f74.77a3.329c@mx.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.5 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org thanks, comment below... --- Ki-Hyung Kim wrote: > > Q2: Did you use the handling rules as per the draft, or did you modify the > > link-layer source address at every hop, as implied by your post a while > back? > I didn't change anything of the format document on the simulation. Also the > link-layer source address is changed at every hop as everybody expected. As I explained before, this departs from the handling rules in the format draft. According to those rules (I won't send them again), the source address does not change hop-by-hop. The assumption is that if an intermediate node wants to send an RERR to its previous hop, it would do a reverse forwarding decision. To be clear, if multiple paths were kept, presumably an intermediat node would have more than one reverse path to the originator of a message. In this case, it is not clear to which of the possible predecessors should the RERR be sent. Perhaps to all of them, which costs a bit more. You say that the "link-layer source address is changed at every hop as everybody expected". One conclusion is that given that this contradicts the current handling rules, then it is clear that they need to be clarified by explicitly mentioning that no such thing is done. Another possible conclusion of your "as everybody expected" is that between these choices: a) link-layer source address is changed at every hop b) link-layer source address is not changed at every hop the draft has obvioiusly made the wrong choice in going with "b". You have verified that having only one link-layer source address (the one in the 802.15.4 header) works under handling rule "a". Have you also evaluated under handling rule "b" in order to compare both? Or is "b" obviously wrong for some reason? -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 13 15:40:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8vz-0007si-Oy; Thu, 13 Oct 2005 15:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8vz-0007sc-2Y for 6lowpan@megatron.ietf.org; Thu, 13 Oct 2005 15:40:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07238 for <6lowpan@ietf.org>; Thu, 13 Oct 2005 15:40:05 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ96Q-00053e-VK for 6lowpan@ietf.org; Thu, 13 Oct 2005 15:51:07 -0400 Received: by zproxy.gmail.com with SMTP id l1so390229nzf for <6lowpan@ietf.org>; Thu, 13 Oct 2005 12:39:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index:message-id; b=p4FwNq3kaxxf2nFHzagdKGlk/S/Dl2eM8DjmHdPVcLeT8eassCKsmB3YC00+hF6fXZRkBtkj1ji0EWpC07RO5EyienxJ5KyHDebZ4MrR71S/C8R0zH2DzE7Xbs67OONRBMtei2r/5QOb76GOmYYqfFs63hY5f9Q5eSsmRGeqZ5Q= Received: by 10.37.20.48 with SMTP id x48mr2780114nzi; Thu, 13 Oct 2005 12:39:59 -0700 (PDT) Received: from ncman ( [202.30.31.245]) by mx.gmail.com with ESMTP id 40sm4136553nzf.2005.10.13.12.39.57; Thu, 13 Oct 2005 12:39:59 -0700 (PDT) From: "Ki-Hyung Kim" To: , "'Samita Chakrabarti'" , Subject: RE: [6lowpan] format document issues Date: Fri, 14 Oct 2005 04:39:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20051013183102.47969.qmail@web81906.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQJES0sQGORZwySIWaodV3VKWDLQACHysw Message-ID: <434eb80f.732f3206.1b80.57b8@mx.gmail.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Gabriel, Please see the comments below. > -----Original Message----- > From: gabriel montenegro [mailto:itijibox-6lowpan@yahoo.com] > Sent: Friday, October 14, 2005 3:31 AM > To: Ki-Hyung Kim; 'Samita Chakrabarti'; nandakishore.kushalnagar@intel.com > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] format document issues > > thanks, comment below... > > --- Ki-Hyung Kim wrote: > > > Q2: Did you use the handling rules as per the draft, or did you modify > the > > > link-layer source address at every hop, as implied by your post a > while > > back? > > I didn't change anything of the format document on the simulation. Also > the > > link-layer source address is changed at every hop as everybody expected. > > As I explained before, this departs from the handling rules in the format > draft. > According to those rules (I won't send them again), the source address > does not > change hop-by-hop. The assumption is that if an intermediate node wants to > send an > RERR to its previous hop, it would do a reverse forwarding decision. To be > clear, > if multiple paths were kept, presumably an intermediat node would have > more than one > reverse path to the originator of a message. In this case, it is not clear > to which of > the possible predecessors should the RERR be sent. Perhaps to all of them, > which costs > a bit more. > > You say that the "link-layer source address is changed at every hop as > everybody > expected". > > One conclusion is that given that this contradicts the current handling > rules, then it is > > clear that they need to be clarified by explicitly mentioning that no such > thing is done. > > Another possible conclusion of your "as everybody expected" is that > between these > choices: > > a) link-layer source address is changed at every hop > b) link-layer source address is not changed at every hop > > the draft has obvioiusly made the wrong choice in going with "b". You have > verified that > having only one link-layer source address (the one in the 802.15.4 header) > works under handling rule "a". Have you also evaluated under handling rule > "b" in order > to compare > both? Or is "b" obviously wrong for some reason? I have looked at your description about the handling rules of the format right before. (Sorry, I had no time to look at the mailing list in these days.) I believe that (a) is right because it is MAC address. I have also double checked it by the packet sniffer of IEEE802.15.4. That is, (b) is not correct. > > -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 13 15:59:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9F4-0004xn-RS; Thu, 13 Oct 2005 15:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9F0-0004xU-Uw for 6lowpan@megatron.ietf.org; Thu, 13 Oct 2005 15:59:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09581 for <6lowpan@ietf.org>; Thu, 13 Oct 2005 15:59:47 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ9Pa-0006D8-Id for 6lowpan@ietf.org; Thu, 13 Oct 2005 16:10:47 -0400 Received: by zproxy.gmail.com with SMTP id s1so519184nze for <6lowpan@ietf.org>; Thu, 13 Oct 2005 12:59:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index:message-id; b=f62n+hA3W2Z/LUS9cP0GvSbn9w2uTemx8W1Fjj3kirhsIXQGuaslrhcZm5sndHrNouRlCM06zEd2jgVtebBRsRPhD3zWtK5vuyF98vnUW1mjIpTBX3y+U6ytEkgtYgK1+4F8K/zWDhzjqbAgSKFyv7X4Ktl34j2czqbMQSi2b84= Received: by 10.36.252.72 with SMTP id z72mr2758189nzh; Thu, 13 Oct 2005 12:59:48 -0700 (PDT) Received: from ncman ( [202.30.31.245]) by mx.gmail.com with ESMTP id m2sm11417nzf.2005.10.13.12.59.46; Thu, 13 Oct 2005 12:59:48 -0700 (PDT) From: "Ki-Hyung Kim" To: "'Samita Chakrabarti'" , , Subject: RE: [6lowpan] format document issues Date: Fri, 14 Oct 2005 04:59:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200510122025.j9CKP40h957185@jurassic.eng.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXPa8Qynzwllj55SQ+hoHPuttQCEgAwiOZA Message-ID: <434ebcb4.56167394.4ea3.042b@mx.gmail.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Samita, Please see my comments below. > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Samita Chakrabarti > Sent: Thursday, October 13, 2005 5:23 AM > To: Samita.Chakrabarti@eng.sun.com; nandakishore.kushalnagar@intel.com; > itijibox-6lowpan@yahoo.com > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] format document issues > > Hi Gabe, > > Please see my comments below. > > > > There is no mention of the link-layer source address changing on a hop- > by-hop > > basis, only the destination address does so. So at each intermediate > node, as > well > > as at the final destination, what is known is the link-layer source > address. > > What is not known is the link-layer address of the preceding hop, so a > node > > knows who originated the packet it just received, but it does not know > which > > node finally delivered it to it. In AODV/LOAD this is the "reverse route > address". > > But of course, routing protocols like AODV or LOAD don't use the M bit, > they > have > > originator and destination address fields within the RREQ. This usage of > only > one > > extra address field is something I saw in 802.11 (although they do have > the > > capability of using two extra fields). > > > > Hopefully, this clarifies the handling rules. Perhaps it's a good idea > to > state clearly > > that > > the source address does not change hop-by-hop. The main question is: are > there > any > > issues with this? It saves one address field, but are there any issues? > > Normally, in IP-routing, the ethernet (link-layer) source address is > changed > at each hop and the link-layer destination address is set according to the > next-hop IP address. Thus, the link-layer chooses its source interface MAC > address at each hop while the IP-packet contains the orginal source > address. > > Since we are now doing something new here - i,e. route at the link-layer, > we still need to somehow know where the packet came from, i.e. the last > sender or forwarder's link-layer address. IEEE802.15.4 has ACK frames, > during > data transfer, it may require a ACK from the next hop - how does the > nexthop > know > where data packet came from ? How does it inform any error to the > immediate > sender if it does not know its link-layer address? > > Moreover, the previous hop may depend on receiving ACK to determine if a > forward > link is broken. Thus the link-layer frame _should_ have the correct src > and > dst address. That's why I mentioned in my last mail about a solution that > maps the 'reverse route' mentioned in RFC3561. > > RFC3561 mentions: > The intermediate node also updates its route table entry > for the node originating the RREQ by placing the next hop towards the > destination in the precursor list for the reverse route entry -- > i.e., the entry for the Originator IP Address field of the RREQ > message data. > > In our case, the AODV packet in the data section will have the originator > link-layer address, thus at each intermediate node, upon RREQ, it sets > a reverse route as following ( addresses are link-layer addresses): > > DEST next hop SEq# > > Originator previous-node originator's seq# > > > This way, we can use reverse route *towards* the originator link-layer > address. > It is the same way one does at the IP-layer. The only difference here is > that > we must know our last link-layer sender's address. > > BTW, reverse routes are better explained in RFC3561 than in aodvbis. > > Thus, the format document can save one address field (for originator > source > link-layer addr) by requiring the routing protocol to provide information > on originator address so that the intermediate node can setup reverse > route. > Alternately, the intermediate node will have to do route-discovery for > the > originator - that is certainly not effecient. > Hope this clarifies the point. > > Thanks, > -Samita I want to clarify about reporting RERR to the originator in AODV. AODV does not rely on the reverse route path for reporting RERR to the originator even though it could. Moreover, the reverse route path in the routing table could not be used for unicasting back a RERR in 6lowpan because a data packet does not contain the originator address. That is, even though a routing table contains a reverse route to the originator, the route could not be found by just looking at a data packet. Instead of the reverse route, AODV uses a precursor list attached on the routing entry for the unreachable destination. The list contains neighbor nodes in previous hop. Also, AODV could even utilize a reverse route path to the originator instead. The precursor list was set up when a node processing a RREQ and a RREP. If the list contains a neighbor, the upstream node just unicasts a RERR to the neighbor (that is, previous hop node). Otherwise, if the list has multiple neighbors, the node may broadcast a RERR or unicast a RERR one-by-one to each neighbor. The precursor list might be utilized in 6lowpan also for the RERR reporting, but have to pay some expense for maintaining it. That is one of the reasons why we are trying to find alternate lightweight solutions in 6lowpan. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 13 20:06:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQD5g-0000Nd-40; Thu, 13 Oct 2005 20:06:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQD5e-0000NT-Se for 6lowpan@megatron.ietf.org; Thu, 13 Oct 2005 20:06:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05353 for <6lowpan@ietf.org>; Thu, 13 Oct 2005 20:06:19 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQDGC-00007T-Kr for 6lowpan@ietf.org; Thu, 13 Oct 2005 20:17:23 -0400 Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9E06JHT027428; Thu, 13 Oct 2005 17:06:19 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9E06JmP717410; Thu, 13 Oct 2005 17:06:19 -0700 (PDT) Message-Id: <200510140006.j9E06JmP717410@jurassic.eng.sun.com> Date: Thu, 13 Oct 2005 17:04:05 -0700 (PDT) From: Samita Chakrabarti Subject: RE: [6lowpan] format document issues To: kkim86@gmail.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VzEwg2qkHMlwdWkL85Zpog== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hello Ki-Hyung, Thanks for the clarification. Please see my comments in-line. > > I want to clarify about reporting RERR to the originator in AODV. > > AODV does not rely on the reverse route path for reporting RERR to the > originator even though it could. It is true. RFC3561 talks about the 'precursor or neighbor list for previous hops'. I was looking at the following section: 6.11. Route Error (RERR) Messages, Route Expiry and Route Deletion A Route Error (RERR) message MAY be either broadcast (if there are many precursors), unicast (if there is only 1 precursor), or iteratively unicast to all precursors (if broadcast is inappropriate). The idea expressed in the previous mail for reverse route RERR is an idea that I am pursuing in my mind - that can be appropriate for Lowpan-aodv; I was thinking wrt to RREQ packets. > Moreover, the reverse route path in the routing table could not be used for > unicasting back a RERR in 6lowpan because a data packet does not contain the > originator address. > That is, even though a routing table contains a reverse route to the > originator, the route could not be found by just looking at a data packet. > You are right! It's definitely confusing our thoughts on this kind of cross-layer design. > Instead of the reverse route, AODV uses a precursor list attached on the > routing entry for the unreachable destination. The list contains neighbor > nodes in previous hop. Also, AODV could even utilize a reverse route path to > the originator instead. > > The precursor list was set up when a node processing a RREQ and a RREP. > If the list contains a neighbor, the upstream node just unicasts a RERR to > the neighbor (that is, previous hop node). Otherwise, if the list has > multiple neighbors, the node may broadcast a RERR or unicast a RERR > one-by-one to each neighbor. agree. > The precursor list might be utilized in 6lowpan also for the RERR reporting, > but have to pay some expense for maintaining it. > That is one of the reasons why we are trying to find alternate lightweight > solutions in 6lowpan. Still, the problem lies with the datapacket not carrying information on the source link-layer address. The question is whether we want to sacrifice 64bit for the link-layer source address for occasional error messages back? One question, I have in mind, whether we need to define a format for IEEE 64bit address for lowpan - AFAIK, IEEE802.15.4 does not specify an address format for the 64bit MAC address. Do we know if it could be a random number? If we have a specific format for the address, perhaps we can comeup with some clever header-compression and include both source and destination MAC address when M bit is set. Or just doing a multiple-unicast to the precusor list and so on. If the routing table maintains a precusor list, it will not be that costly for the lowpan layer-code to lookup that list. The third option is to include a bit in the lowpan layer along with 'M' bit to ask for RERR or not. If the bit is 0, the RERR is not generated for the datapackets. Anyway, I can see the problem you're trying to address. It is an interesting problem when one wants to send data directly over lowpan. Thanks. -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 13 20:34:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQDWf-0000yf-0z; Thu, 13 Oct 2005 20:34:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQDWd-0000yX-Km for 6lowpan@megatron.ietf.org; Thu, 13 Oct 2005 20:34:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06341 for <6lowpan@ietf.org>; Thu, 13 Oct 2005 20:34:14 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQDhC-0000mz-RZ for 6lowpan@ietf.org; Thu, 13 Oct 2005 20:45:18 -0400 Received: from jurassic.eng.sun.com ([129.146.58.166]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9E0YF1L026542; Thu, 13 Oct 2005 18:34:15 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9E0YEDe725452; Thu, 13 Oct 2005 17:34:14 -0700 (PDT) Message-Id: <200510140034.j9E0YEDe725452@jurassic.eng.sun.com> Date: Thu, 13 Oct 2005 17:32:00 -0700 (PDT) From: Samita Chakrabarti To: itijibox-6lowpan@yahoo.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zhDb0Vl9PWWBtP8IUPUWUQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 6lowpan@ietf.org Subject: [6lowpan] MultiHop Format document issues X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Gabe, I have some questions regarding the M bit in lowpan. The draft says in pg 5: The LoWPAN payload (e.g., an IPv6 packet) follows this encapsulation header. Alternatively, if the 'M' bit is on, before this actual payload, a "Final Destination" field will be present (Section 9). On pg 6 M: This bit is used to signal whether there is a "Final Destination" field as used for ad hoc or mesh routing. If set to 1, a "Final Destination" field precedes the IPv6 packet (Section 9). Q1: What is meant by 'used for adhoc or mesh routing' ? I assume that it means M bit is used for both control and data path for multihop routing - is it correct? If it's used for data routing in mesh-network, then I see why the draft wanted to keep original MAC source address field unchanged. But I beleive the MAC implementation sets its own MAC address anyway when it transmits a packet. ( I don't know of all implementations though). It seems if we can come up with a IEEE address format for lowpan, then it can be compressed easily over a LowPAN network to include both originator address and final address. ---------------------------------------- 9. Packet Delivery in a Link-Layer Mesh A device that wishes to send a packet may, in such cases, use other intermediate devices as forwarders towards the final destination. In order to achieve such packet delivery using unicast, it is necessary to include the final destination in addition to the hop-by-hop destination. This final destination may be expressed either as a layer 2 or as an IP (layer 3) address. In the latter case, there is no need to provide any additional header support in this document (i.e., at the sub-IP layer). The link-layer destination address points to the next hop destination address while the IP destination address points to the final destination (IP) address (that may be multiple hops away from the source). Thus, while forwarding data, the single-hop destination address changes hop-by-hop pointing to the "best" next hop, while the destination IP address remains unchanged. ---------------------------------------------- Does the above paragraph mean we could have M bit set and final destination address could be a 16 byte IPv6 address? I wonder why do we need IPv6 address in M bit case? Shouldn't the final IP destination be extracted from the IPv6 header in the payload? Not sure, what it means by 'any additional header support'. I wonder what is the need for supporting a L3 address in final destination field (when it talks about packet delivery in the link-layer)? Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 14 00:01:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGl3-00070G-E7; Fri, 14 Oct 2005 00:01:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGl0-000705-KK for 6lowpan@megatron.ietf.org; Fri, 14 Oct 2005 00:01:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14410 for <6lowpan@ietf.org>; Fri, 14 Oct 2005 00:01:18 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQGvZ-0005lE-PD for 6lowpan@ietf.org; Fri, 14 Oct 2005 00:12:22 -0400 Received: by zproxy.gmail.com with SMTP id l1so457782nzf for <6lowpan@ietf.org>; Thu, 13 Oct 2005 21:01:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:in-reply-to:x-mimeole:message-id; b=IrX/DQLnVIK7SQRqgK9gWbT1+JLNoi0KHLe+vlykE8VZuaulq4DzYPTQKcPmIja6YJhMasK/ejkrR2KafrWmdZElJrGju2Y6IIe7GtVRW62zSYv3lBTLZxn0/o9PvZjECMhEnhgoT6JIMav/4n0WAINlREF4N5jy4FvmnNq3bQo= Received: by 10.36.61.5 with SMTP id j5mr3164760nza; Thu, 13 Oct 2005 21:01:16 -0700 (PDT) Received: from ncman ( [202.30.31.245]) by mx.gmail.com with ESMTP id 38sm869402nzf.2005.10.13.21.01.14; Thu, 13 Oct 2005 21:01:15 -0700 (PDT) From: "Ki-Hyung Kim" To: "'Samita Chakrabarti'" , Subject: RE: [6lowpan] MultiHop Format document issues Date: Fri, 14 Oct 2005 13:01:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcXQVx+NbwCLg716TuaDPBdCwCWGGAAG4gQg In-Reply-To: <200510140034.j9E0YEDe725452@jurassic.eng.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <434f2d8b.6f550250.1482.22ab@mx.gmail.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Samita, Please see the comments in line. > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Samita Chakrabarti > Sent: Friday, October 14, 2005 9:32 AM > To: itijibox-6lowpan@yahoo.com > Cc: 6lowpan@ietf.org > Subject: [6lowpan] MultiHop Format document issues > > > Hi Gabe, > > I have some questions regarding the M bit in lowpan. > > The draft says in pg 5: > The LoWPAN payload (e.g., an > IPv6 packet) follows this encapsulation header. Alternatively, if > the 'M' bit is on, before this actual payload, a "Final Destination" > field will be present (Section 9). > > On pg 6 > M: This bit is used to signal whether there is a "Final Destination" > field as used for ad hoc or mesh routing. If set to 1, a "Final > Destination" field precedes the IPv6 packet (Section 9). > > Q1: What is meant by 'used for adhoc or mesh routing' ? I assume that > it > means M bit is used for both control and data path for multihop routing > - > is it correct? > > If it's used for data routing in mesh-network, then I see why the draft > wanted to keep original MAC source address field unchanged. But I > beleive > the MAC implementation sets its own MAC address anyway when it transmits > a packet. ( I don't know of all implementations though). > > It seems if we can come up with a IEEE address format for lowpan, then > it can be compressed easily over a LowPAN network to include both > originator address and final address. > > ---------------------------------------- > 9. Packet Delivery in a Link-Layer Mesh > > A device that wishes > to send a packet may, in such cases, use other intermediate devices > as forwarders towards the final destination. In order to achieve > such packet delivery using unicast, it is necessary to include the > final destination in addition to the hop-by-hop destination. This > final destination may be expressed either as a layer 2 or as an IP > (layer 3) address. > > In the latter case, there is no need to provide any additional header > support in this document (i.e., at the sub-IP layer). The link-layer > destination address points to the next hop destination address while > the IP destination address points to the final destination (IP) > address (that may be multiple hops away from the source). Thus, > while forwarding data, the single-hop destination address changes > hop-by-hop pointing to the "best" next hop, while the destination IP > address remains unchanged. > ---------------------------------------------- > Does the above paragraph mean we could have M bit set and final > destination > address could be a 16 byte IPv6 address? > I wonder why do we need IPv6 address > in M bit case? Shouldn't the final IP destination be extracted from the > IPv6 header in the payload? Not sure, what it means by 'any additional > header support'. The final IP destination can be extracted from the payload if it contains the IPv6 header). But, if the IP packet is fragmented in the payload, all the fragments except the first one do not contain the destination address. This means that the adaptation layer should provide its own final destination field without relying on the payload. I hope I got the right point of the question. > > I wonder what is the need for supporting a L3 address in final > destination > field (when it talks about packet delivery in the link-layer)? > > Thanks, > -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 Oct 14 04:19:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQKjN-0003j4-0D; Fri, 14 Oct 2005 04:15:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQKjI-0003hD-J8 for 6lowpan@megatron.ietf.org; Fri, 14 Oct 2005 04:15:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25099 for <6lowpan@ietf.org>; Fri, 14 Oct 2005 04:15:46 -0400 (EDT) Received: from web81906.mail.mud.yahoo.com ([68.142.207.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQKty-0003oS-Cp for 6lowpan@ietf.org; Fri, 14 Oct 2005 04:26:55 -0400 Received: (qmail 57741 invoked by uid 60001); 14 Oct 2005 08:15:40 -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:Content-Transfer-Encoding; b=N+RTdU1FOBSZwjri4Ky7kSa0+jP0PADCLFoLc6O9GM6BhjgAK6DlJXpIZ1Yx7RiZFxWCdO/RMpaLIlYJ7sxjjxKlXwHDs4UaLRIIq1dG3Xa0DzH2VvH3Gp3EAbXMNZnloAmBzPu47Vh69UPtncX3lN3cLPd/TEXITByfRAQNsgk= ; Message-ID: <20051014081540.57739.qmail@web81906.mail.mud.yahoo.com> Received: from [24.16.92.216] by web81906.mail.mud.yahoo.com via HTTP; Fri, 14 Oct 2005 01:15:40 PDT Date: Fri, 14 Oct 2005 01:15:40 -0700 (PDT) From: gabriel montenegro To: Samita Chakrabarti , itijibox-6lowpan@yahoo.com In-Reply-To: <200510140034.j9E0YEDe725452@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: [6lowpan] Re: MultiHop Format document issues X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Samita, --- Samita Chakrabarti wrote: > > Hi Gabe, > > I have some questions regarding the M bit in lowpan. > > The draft says in pg 5: > The LoWPAN payload (e.g., an > IPv6 packet) follows this encapsulation header. Alternatively, if > the 'M' bit is on, before this actual payload, a "Final Destination" > field will be present (Section 9). > > On pg 6 > M: This bit is used to signal whether there is a "Final Destination" > field as used for ad hoc or mesh routing. If set to 1, a "Final > Destination" field precedes the IPv6 packet (Section 9). > > Q1: What is meant by 'used for adhoc or mesh routing' ? I assume that it > means M bit is used for both control and data path for multihop routing - > is it correct? It's meant for data delivery. You would run your favorite mesh protocol (aodv, dymo, olsr, etc) without using the 'M' bit, cuz these go hop-by-hop. One could think of ways in which one could run them even with an 'M' bit on, but this is perhaps more for discussion f2f. Your routing protocol would use hop-by-hop to find routes (RREQ/RREP) and populate routing tables along the way. Once the routing tables are set up, then your data forwarding can take place. You would use the 'M' bit and section 9 for the data delivery. > > If it's used for data routing in mesh-network, then I see why the draft > wanted to keep original MAC source address field unchanged. But I beleive > the MAC implementation sets its own MAC address anyway when it transmits > a packet. ( I don't know of all implementations though). Yeah, this is a bit problematic (also with ACKs). > It seems if we can come up with a IEEE address format for lowpan, then > it can be compressed easily over a LowPAN network to include both > originator address and final address. I don't think we have the charter to define layer 2 addressing. Besides, I don't see the point, cuz if a PAN is using 16-bit (short) addresses as per 802.15.4, they would take much less space. Might as well use that. > > ---------------------------------------- > 9. Packet Delivery in a Link-Layer Mesh > > A device that wishes > to send a packet may, in such cases, use other intermediate devices > as forwarders towards the final destination. In order to achieve > such packet delivery using unicast, it is necessary to include the > final destination in addition to the hop-by-hop destination. This > final destination may be expressed either as a layer 2 or as an IP > (layer 3) address. > > In the latter case, there is no need to provide any additional header > support in this document (i.e., at the sub-IP layer). The link-layer > destination address points to the next hop destination address while > the IP destination address points to the final destination (IP) > address (that may be multiple hops away from the source). Thus, > while forwarding data, the single-hop destination address changes > hop-by-hop pointing to the "best" next hop, while the destination IP > address remains unchanged. > ---------------------------------------------- > Does the above paragraph mean we could have M bit set and final destination > address could be a 16 byte IPv6 address? Hmm... In the spec as it is now, it could be either a 64-bit address or a 16-bit (not byte) address. Only the 64-bit address is fully specified in the draft. I'll try to get 16-bit in by the deadline. > I wonder why do we need IPv6 address > in M bit case? Shouldn't the final IP destination be extracted from the > IPv6 header in the payload? Not sure, what it means by 'any additional > header support'. > > I wonder what is the need for supporting a L3 address in final destination > field (when it talks about packet delivery in the link-layer)? No need, and this is not what's done in the spec. I see that the above text is confusing. That part was meant to be a discussion of a possible alternative and an explanation of why we chose not to follow it. I've modified section 9 to make things a bit clearer and also to discuss the options we have (either the source address changes hop-by-hop or it doesn't change). It seems like both are sub-optimal. I'm currently edging to include both src and dst in the 'Final Destination Header'. If so, we'd presumably re-name to something like 'Original Endpoints Header' or 'Mesh Delivery Header' (any preferences? other suggestions?). Please read the updated section 9 on mesh delivery and comment. That section is available here: http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.htm#mesh http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.txt I include it below for your convenience. -gabriel --------------------------------------------------------- 9. Frame Delivery in a Link-Layer Mesh Even though 802.15.4 networks are expected to commonly use mesh routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] does not define such capability. In such cases, an ad hoc or mesh routing protocol populates the devices' routing tables. A device that wishes to send a frame may, in such cases, use other intermediate devices as forwarders towards the final destination. In order to achieve such frame delivery using unicast, it is necessary to include the final destination in addition to the hop-by-hop destination. 9.1. Alternatives for Delivery of Frames in a Mesh Before discussing the defined mechanism for delivery in a mesh, let's review some options on how to accomplish this. The final destination could be expressed either as a layer 2 or as an IP (layer 3) address. In the latter case, there would be no need to provide any additional header support in this document (i.e., at the sub-IP layer). The link-layer destination address would point to the next hop destination address while the IP destination address would point to the final destination (IP) address (that may be multiple hops away from the source). Thus, while forwarding data, the single-hop destination address would change at each hop (always pointing to the "best" next link-layer hop), while the destination IP address would remain unchanged. Notice that if an IP packet is fragmented, the individual fragments may arrive at any node out of order. If so, if the initial frament (which contains the IP header) is delayed for some reason, a node that receives a middle fragment would lack the final destination address. It would be forced to wait until this information arrives (in the IP header within the first fragment) before being able to forward the fragment any further. This imposes some additional buffering requirements on intermediate nodes. Additionally, the above scheme would need to be adapted depending on the layer 3 protocol, and would require this protocol to include its own addressing information. On the other hand, in order to create a mesh at the link-layer (layer 2), one would need to include the link-layer final destination address within the layer 2 frame. This would enable mesh delivery for any protocol or application layering itself on top of the adaptation layer defined above (Section 4). For IPv6 as supported in this document, another advantage of expressing the final destination as a layer 2 addresses is that the IPv6 destination address can be compressed as per the header compression specified in Section 8, thus saving 8 octets. Another advantage is that the the number of octets needed to maintain routing tables is reduced due to the smaller size of 802.15.4 addresses (either 64 bits or 16 bits) as compared to IPv6 addresses (128 bits). A disadvantage is that applications on top of IP do not address packets to link-layer destination addresses, but to IP (layer 3) destination addresses. Thus, given an IP address, there is a need to resolve the corresponding link-layer address. A mesh routing specification would need to clarify the Neighbor Discovery implications, although in some special cases, it may be possible to derive a device's address at layer 2 from its address at layer 3 (and viceversa). Such complete specification is outside the scope of this document. 9.2. Mechanism for Packet Delivery in a Mesh This section defines how to effect delivery of layer 2 frames in a mesh, given a target link-layer address. It does so via a layer 2 approach, as discussed in the previous section. Mesh delivery is enabled by setting the 'M' bit that immediately follows the 'prot_type' field. If the 'M' bit is set, there is a "Final Destination" field included in the frame immediately following the current header (e.g., possibly preceding any existing header compression fields). This implies that the "Final Destination" field will immediately follow an unfragmented packet as per Figure 1 (i.e., preceding the IPv6 Header), or immediately following the first fragment header as per Figure 2. If a node wishes to use a forwarder to deliver a packet, it puts the forwarder's link-layer address in the link-layer destination address field. It must also set the 'M' bit, and include a "Final Destination" field with the final destination's link-layer address. Similarly, if a node receives a frame with the 'M' bit set, it must look at the "Final Destination" field to determine the real destination. Upon consulting its routing table, it determines what the next hop towards that destination should be. The node then reduces the "Hops Left" field. If the result is zero, the node discards the packet. Otherwise, it puts the next hop's address in the link-layer destination address field, and transmits the packet. If upon examining the "Final Destination" field the node determines that it has direct reachability, it removes the "Final Destination" field, sets that final address as the link-layer destination address, and transmits the packet. Notice that whereas the destination link- layer address changes at every hop, no such change applies to the source link-layer address. The latter always points at the initial originator of the frame being forwarded. NOTE: The mesh delivery mechanism defined here only allows for a final destination link-layer address, but not for an original destination link-layer address. This saves space, but then one must decide how to use the only existing source link-layer address (that in the 802.15.4 header). There are pros and cons to not having the source link-layer address change at every hop, as per the current specification. This is a pure layer 2 mesh delivery solution, so even middle fragments can be forwarded as soon as they are received. Even though which node sent a given frame is not immediately obvious, this information can be inferred from the precursor list information in its routing table. If more than one precursor are possible, the node would not necessarily know which of those actually sent it the frame in question. In order to send back an RERR, for example, it might have to send it to all possible precursors. Given that such error conditions may be rare as compared to data forwarding events, this may not be a large cost to pay. However, the acknowledge mode of data delivery in 802.15.4 sends back an ACK whenever a frame is received. Typically, this operation is implemented in hardware very efficiently. With the current scheme, one would have to turn off this option on the chipset, and instead do it in a much less efficient manner in software. Data forwarding in this case incurs the cost of examining the routing table in order to infer the link- layer address of the device that is expecting the ACK. Unfortunately, a device that does not implement this specification would proceed as per the usual 802.15.4 procedures and send back an ACK to the address contained in the source link-layer address. Such an ACK would be erroneously addressed to the initial originator of the frame, and would most probably remain undelivered. Because of these considerations it may be inevitable to add the original link- layer source address as an explicit field in mesh delivery. The alternative, of course, is to have the source link-layer address change at every hop. In this case, the original link-layer address is lost. It may be possible to recover it if the IP source address is present and if there is a clearly defined way to derive the former from the latter (as per the header compression considerations in this document). This poses the issues that this ceases being a mesh delivery solution at layer 2, with the considerations raised in the previous section. Whereas a node must participate in a mesh routing protocol to be a forwarder, no such requirement exists for simply using mesh forwarding. Only "Full Function Devices" (FFDs) are expected to participate as routers in a mesh. "Reduced Function Devices" (RFDs) limit themselves to discovering FFDs and using them for all their forwarding, in a manner similar to how IP hosts typically use default routers to forward all their off-link traffic. For an RFD using mesh delivery, the forwarder is always the appropriate FFD. The "Final Destination" field is defined as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Hops Left | Link-layer Address of final destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Final Destination Field Field definitions are as follows: S: This bit field SHALL be zero. Future revisions will use this bit to signal the use of an 802.15.4 short 16 bit address instead of the default IEEE extended 64 bit address format. Hops Left: This 7 bit field SHALL be decremented by each forwarding node before sending this packet towards its next hop. The packet is discarded if Hops Left is decremented to 0. Address: This is the final destination's link-layer address. This document assumes that this field is 64 bits long, but a future revision may add support for short addresses (16 bits). _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 14 04:24:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQKrg-0006lN-62; Fri, 14 Oct 2005 04:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQKre-0006lE-HI for 6lowpan@megatron.ietf.org; Fri, 14 Oct 2005 04:24:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25520 for <6lowpan@ietf.org>; Fri, 14 Oct 2005 04:24:26 -0400 (EDT) Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQL2J-00044J-Vb for 6lowpan@ietf.org; Fri, 14 Oct 2005 04:35:33 -0400 Received: (qmail 13191 invoked by uid 60001); 14 Oct 2005 08:24:20 -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:Content-Transfer-Encoding; b=IDf1zgnr45G3vvlVFh9kUStxZrezsJDOd3GiQAWi+YsurtnjUZBFgIHJRl1HrlHR9hTEOextZxAF+lZThCdCFxnt9yZ631JTZQDJDND9X3KoPEWfcibFJrar/mDSTf86gQgPsRnd2+JpAzY8kQIQQ8caJIS5TuBEHIP9myeUqfA= ; Message-ID: <20051014082420.13189.qmail@web81903.mail.mud.yahoo.com> Received: from [24.16.92.216] by web81903.mail.mud.yahoo.com via HTTP; Fri, 14 Oct 2005 01:24:20 PDT Date: Fri, 14 Oct 2005 01:24:20 -0700 (PDT) From: gabriel montenegro Subject: RE: [6lowpan] format document issues To: Samita Chakrabarti , kkim86@gmail.com In-Reply-To: <200510140006.j9E06JmP717410@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- Samita Chakrabarti wrote: > One question, I have in mind, whether we need to define a format for > IEEE 64bit address for lowpan - AFAIK, IEEE802.15.4 does not specify an > address format for the 64bit MAC address. Do we know if it could be a Sure. By default the MAC address is an EUI-64, as mentioned here: http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.htm#mesh As with many 802 devices (ethernet, token ring, fddi...) you're not forced to set it to the manufacturer-set MAC address. So people quite commonly set it to other things like random, or layer 2 CGAs or structured, etc. ZigBee has a structured addressing scheme, and Geoff can tell you about issues with that. We've seen a similar proposal in this group as well. 802.15.4 also allows the 16-bit addresses, assigned by the controller during network entry of the device. > random number? If we have a specific format for the address, perhaps > we can comeup with some clever header-compression and include both > source and destination MAC address when M bit is set. Just using 16-bit addresses would go a long way. Not sure we should look any further. We could include both src and dst then. > Or just doing a multiple-unicast to the precusor list and so on. If the > routing table maintains a precusor list, it will not be that costly > for the lowpan layer-code to lookup that list. The third option is to > include a bit in the lowpan layer along with 'M' bit to ask for RERR > or not. If the bit is 0, the RERR is not generated for the datapackets. AODVjr, for example, does not use RERRs (or precursor lists, for that matter). -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 14 16:55:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWao-0005zs-FC; Fri, 14 Oct 2005 16:55:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWam-0005yP-5v for 6lowpan@megatron.ietf.org; Fri, 14 Oct 2005 16:55:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24156 for <6lowpan@ietf.org>; Fri, 14 Oct 2005 16:55:45 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWlT-0005xZ-GN for 6lowpan@ietf.org; Fri, 14 Oct 2005 17:06:59 -0400 Received: from jurassic.eng.sun.com ([129.146.58.166]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9EKtjvD027926; Fri, 14 Oct 2005 14:55:45 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9EKti8S430351; Fri, 14 Oct 2005 13:55:44 -0700 (PDT) Message-Id: <200510142055.j9EKti8S430351@jurassic.eng.sun.com> Date: Fri, 14 Oct 2005 13:53:29 -0700 (PDT) From: Samita Chakrabarti To: itijibox-6lowpan@yahoo.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: diG7ESMKz41LtlGV7R4RwQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: 6lowpan@ietf.org Subject: [6lowpan] Re: MultiHop Format document issues X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > > Q1: What is meant by 'used for adhoc or mesh routing' ? I assume that it > > means M bit is used for both control and data path for multihop routing - > > is it correct? > > It's meant for data delivery. You would run your favorite mesh protocol > (aodv, dymo, olsr, etc) without using the 'M' bit, cuz these go hop-by-hop. > One could think of ways in which one could run them even with an 'M' bit > on, but this is perhaps more for discussion f2f. For RREQ forward path M bit is not necessary, because all nodes use bcast. For RREP from destination to the original sender, it might be useful it seems.[ when AODV runs on link-layer] > > It seems if we can come up with a IEEE address format for lowpan, then > > it can be compressed easily over a LowPAN network to include both > > originator address and final address. > > I don't think we have the charter to define layer 2 addressing. Besides, > I don't see the point, cuz if a PAN is using 16-bit (short) addresses > as per 802.15.4, they would take much less space. Might as well use that. > > > Are we re-thinking of IPv6-address format ( the low 64bit part) as well ? fe80:0:0:::<16bit-addr>? > > ---------------------------------------- > > 9. Packet Delivery in a Link-Layer Mesh > > > > A device that wishes > > to send a packet may, in such cases, use other intermediate devices > > as forwarders towards the final destination. In order to achieve > > such packet delivery using unicast, it is necessary to include the > > final destination in addition to the hop-by-hop destination. This > > final destination may be expressed either as a layer 2 or as an IP > > (layer 3) address. > > > > In the latter case, there is no need to provide any additional header > > support in this document (i.e., at the sub-IP layer). The link-layer > > destination address points to the next hop destination address while > > the IP destination address points to the final destination (IP) > > address (that may be multiple hops away from the source). Thus, > > while forwarding data, the single-hop destination address changes > > hop-by-hop pointing to the "best" next hop, while the destination IP > > address remains unchanged. > > ---------------------------------------------- > > Does the above paragraph mean we could have M bit set and final destination > > address could be a 16 byte IPv6 address? > > Hmm... In the spec as it is now, it could be either a 64-bit address > or a 16-bit (not byte) address. Only the 64-bit address is fully specified > in the draft. I'll try to get 16-bit in by the deadline. > > > I wonder why do we need IPv6 address > > in M bit case? Shouldn't the final IP destination be extracted from the > > IPv6 header in the payload? Not sure, what it means by 'any additional > > header support'. > > > > I wonder what is the need for supporting a L3 address in final destination > > field (when it talks about packet delivery in the link-layer)? > > No need, and this is not what's done in the spec. I see that the above text is > confusing. That part was meant to be a discussion of a possible alternative and > an explanation of why we chose not to follow it. > > I've modified section 9 to make things a bit clearer and also to discuss the > options we have (either the source address changes hop-by-hop or it doesn't change). > It seems like both are sub-optimal. I'm currently edging to include both src and > dst in the 'Final Destination Header'. If so, we'd presumably re-name to something > like 'Original Endpoints Header' or 'Mesh Delivery Header' (any preferences? other > suggestions?). > Currently it says 'Final destination field' - I suppose, it's going to change to 'Final Destination header' or alike? If we add source link-layer address as well, then I'd really like to see a suggestion for header compression in case of 64bit addresses, even though IETF charter may not allow to specify IEEE address format. Do you think, it might be something that should be brought up at the IEEE meetings? If we use 16bit short addresses only, do we see any disadvantages in routing directly to the Internet other than limitation of address space? As for naming, I'd prefer 'Mesh Delivery header'. > Please read the updated section 9 on mesh delivery and comment. That section > is available here: > > http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.h tm#mesh > http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.t xt > > I include it below for your convenience. Thanks so much. Please the comments in-line. > 9. Frame Delivery in a Link-Layer Mesh > > Even though 802.15.4 networks are expected to commonly use mesh > routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] does not > define such capability. In such cases, an ad hoc or mesh routing > protocol populates the devices' routing tables. A device that wishes > to send a frame may, in such cases, use other intermediate devices as > forwarders towards the final destination. In order to achieve such > frame delivery using unicast, it is necessary to include the final > destination in addition to the hop-by-hop destination. > > 9.1. Alternatives for Delivery of Frames in a Mesh > > Before discussing the defined mechanism for delivery in a mesh, let's > review some options on how to accomplish this. The final destination > could be expressed either as a layer 2 or as an IP (layer 3) address. > In the latter case, there would be no need to provide any additional > header support in this document (i.e., at the sub-IP layer). The > link-layer destination address would point to the next hop > destination address while the IP destination address would point to > the final destination (IP) address (that may be multiple hops away > from the source). Thus, while forwarding data, the single-hop > destination address would change at each hop (always pointing to the > "best" next link-layer hop), while the destination IP address would > remain unchanged. Notice that if an IP packet is fragmented, the > individual fragments may arrive at any node out of order. If so, if > the initial frament (which contains the IP header) is delayed for > some reason, a node that receives a middle fragment would lack the > final destination address. It would be forced to wait until this > information arrives (in the IP header within the first fragment) > before being able to forward the fragment any further. This imposes > some additional buffering requirements on intermediate nodes. > Additionally, the above scheme would need to be adapted depending on > the layer 3 protocol, and would require this protocol to include its > own addressing information. > Perhaps a subheader for 'Using L3 Final Destination field' and 'Using L2 Final Destination Field' would look a litle clear. As for L3 final destination address, I understand : - The routing still happens in L3 layer; each node derives the next hop L2 address corresponding to the next-hop IP-address in the routing table given the final destination IPv6 address. - The Final destination field is useful when IPv6 pkt is fragmented over the link. If not fragmented, Final destination IP-address is not needed. - If the IPv6 packet is not fragmented, and we use L3 routing, we don't need to set M bit. Are the above assumptions correct? If yes, perhaps then a clarification on them in the above text is helpful. > On the other hand, in order to create a mesh at the link-layer (layer > 2), one would need to include the link-layer final destination > address within the layer 2 frame. This would enable mesh delivery > for any protocol or application layering itself on top of the > adaptation layer defined above (Section 4). For IPv6 as supported in > this document, another advantage of expressing the final destination > as a layer 2 addresses is that the IPv6 destination address can be > compressed as per the header compression specified in Section 8, thus > saving 8 octets. Another advantage is that the the number of octets > needed to maintain routing tables is reduced due to the smaller size > of 802.15.4 addresses (either 64 bits or 16 bits) as compared to IPv6 > addresses (128 bits). A disadvantage is that applications on top of > IP do not address packets to link-layer destination addresses, but to > IP (layer 3) destination addresses. Thus, given an IP address, there > is a need to resolve the corresponding link-layer address. A mesh > routing specification would need to clarify the Neighbor Discovery > implications, although in some special cases, it may be possible to > derive a device's address at layer 2 from its address at layer 3 (and > viceversa). Such complete specification is outside the scope of this > document. > > 9.2. Mechanism for Packet Delivery in a Mesh > > This section defines how to effect delivery of layer 2 frames in a > mesh, given a target link-layer address. It does so via a layer 2 > approach, as discussed in the previous section. > > Mesh delivery is enabled by setting the 'M' bit that immediately > follows the 'prot_type' field. If the 'M' bit is set, there is a > "Final Destination" field included in the frame immediately following > the current header (e.g., possibly preceding any existing header > compression fields). This implies that the "Final Destination" field > will immediately follow an unfragmented packet as per Figure 1 (i.e., > preceding the IPv6 Header), or immediately following the first > fragment header as per Figure 2. > > If a node wishes to use a forwarder to deliver a packet, it puts the > forwarder's link-layer address in the link-layer destination address > field. It must also set the 'M' bit, and include a "Final > Destination" field with the final destination's link-layer address. > Similarly, if a node receives a frame with the 'M' bit set, it must > look at the "Final Destination" field to determine the real > destination. Upon consulting its routing table, it determines what > the next hop towards that destination should be. The node then > reduces the "Hops Left" field. If the result is zero, the node > discards the packet. Otherwise, it puts the next hop's address in > the link-layer destination address field, and transmits the packet. > If upon examining the "Final Destination" field the node determines > that it has direct reachability, it removes the "Final Destination" > field, sets that final address as the link-layer destination address, > and transmits the packet. Notice that whereas the destination link- > layer address changes at every hop, no such change applies to the > source link-layer address. The latter always points at the initial > originator of the frame being forwarded. > I assume the following NOTE is for temporary discussion. The rest looks good. Thanks again. -Samita > NOTE: The mesh delivery mechanism defined here only allows for a > final destination link-layer address, but not for an original > destination link-layer address. This saves space, but then one must > decide how to use the only existing source link-layer address (that > in the 802.15.4 header). There are pros and cons to not having the > source link-layer address change at every hop, as per the current > specification. This is a pure layer 2 mesh delivery solution, so > even middle fragments can be forwarded as soon as they are received. > Even though which node sent a given frame is not immediately obvious, > this information can be inferred from the precursor list information > in its routing table. If more than one precursor are possible, the > node would not necessarily know which of those actually sent it the > frame in question. In order to send back an RERR, for example, it > might have to send it to all possible precursors. Given that such > error conditions may be rare as compared to data forwarding events, > this may not be a large cost to pay. However, the acknowledge mode > of data delivery in 802.15.4 sends back an ACK whenever a frame is > received. Typically, this operation is implemented in hardware very > efficiently. With the current scheme, one would have to turn off > this option on the chipset, and instead do it in a much less > efficient manner in software. Data forwarding in this case incurs > the cost of examining the routing table in order to infer the link- > layer address of the device that is expecting the ACK. > Unfortunately, a device that does not implement this specification > would proceed as per the usual 802.15.4 procedures and send back an > ACK to the address contained in the source link-layer address. Such > an ACK would be erroneously addressed to the initial originator of > the frame, and would most probably remain undelivered. Because of > these considerations it may be inevitable to add the original link- > layer source address as an explicit field in mesh delivery. The > alternative, of course, is to have the source link-layer address > change at every hop. In this case, the original link-layer address > is lost. It may be possible to recover it if the IP source address > is present and if there is a clearly defined way to derive the former > from the latter (as per the header compression considerations in this > document). This poses the issues that this ceases being a mesh > delivery solution at layer 2, with the considerations raised in the > previous section. > > Whereas a node must participate in a mesh routing protocol to be a > forwarder, no such requirement exists for simply using mesh > forwarding. Only "Full Function Devices" (FFDs) are expected to > participate as routers in a mesh. "Reduced Function Devices" (RFDs) > limit themselves to discovering FFDs and using them for all their > forwarding, in a manner similar to how IP hosts typically use default > routers to forward all their off-link traffic. For an RFD using mesh > delivery, the forwarder is always the appropriate FFD. > > The "Final Destination" field is defined as follows: > > 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |S| Hops Left | Link-layer Address of final destination | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 9: Final Destination Field > > Field definitions are as follows: > > S: This bit field SHALL be zero. Future revisions will use this bit > to signal the use of an 802.15.4 short 16 bit address instead of > the default IEEE extended 64 bit address format. > > Hops Left: This 7 bit field SHALL be decremented by each forwarding > node before sending this packet towards its next hop. The packet > is discarded if Hops Left is decremented to 0. > > Address: This is the final destination's link-layer address. This > document assumes that this field is 64 bits long, but a future > revision may add support for short addresses (16 bits). _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 14 19:42:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQZCG-0003My-Ip; Fri, 14 Oct 2005 19:42:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQZCE-0003Ml-R3 for 6lowpan@megatron.ietf.org; Fri, 14 Oct 2005 19:42:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05017 for <6lowpan@ietf.org>; Fri, 14 Oct 2005 19:42:37 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQZN0-0002Ze-8R for 6lowpan@ietf.org; Fri, 14 Oct 2005 19:53:53 -0400 Received: from jurassic.eng.sun.com ([129.146.108.38]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9ENgXh0024584; Fri, 14 Oct 2005 16:42:34 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9ENgXS0522984; Fri, 14 Oct 2005 16:42:33 -0700 (PDT) Message-Id: <200510142342.j9ENgXS0522984@jurassic.eng.sun.com> Date: Fri, 14 Oct 2005 16:40:18 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [6lowpan] how many drafts To: itijibox-6lowpan@yahoo.com, soohong.park@samsung.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: elQBBaVrnVNTfLO8UKa1Vg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > > > > I have a few questions regarding the routing solutions on Lowpan: > > > > - Are we going to go ahead with lowpan-aodv draft? > > If so, I'd like to pass some modification requests that we have > > discovered during an exercize of its implementation. > > > > - Are we going to merge lowpan-aodv and LOAD draft? > > - If yes, then we need to review this draft seriously. It is RFC3561 > > based. > > As Daniel mentioned, LOAD is what we're working on going forward. > Ok. > > IMHO, neigther AODV-bis nor RFC3561 are quite suitable for lowpan routing; > > It'd be much nicer if we come up with a lowpan routing protocol based on > > DYMO/AODV/AODVbis flavors. It is unlikely that lowpan tiny devices will > > route packets for the regular internet, hence the modified standard version > > protocol makes more sense for the lowpan world. > > I believe an adapted protocol is the idea, yes. I think inventing something > new won't happen (at least not in this WG, it might in MANET or something else > in the routing area). But I believe it should be ok for lowpan to adapt > an existing protocol. Perhaps not all fields are needed. Perhaps not all > features are needed. The current drafts already started the adaptation because > I don't believe they include all the bells and whistles in aodv or dymo, right? > I guess we're in agreement. > Agree. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 14 19:58:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQZRE-0008DX-MV; Fri, 14 Oct 2005 19:58:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQZRC-00089n-T1 for 6lowpan@megatron.ietf.org; Fri, 14 Oct 2005 19:58:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05583 for <6lowpan@ietf.org>; Fri, 14 Oct 2005 19:58:05 -0400 (EDT) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQZbw-0002rX-GE for 6lowpan@ietf.org; Fri, 14 Oct 2005 20:09:21 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOD00K73JWCLG00@dps.sfvic.sunlabs.com> for 6lowpan@ietf.org; Fri, 14 Oct 2005 16:57:48 -0700 (PDT) Received: from [129.146.73.85] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOD00KJ1JWC2300@mail.sunlabs.com> for 6lowpan@ietf.org; Fri, 14 Oct 2005 16:57:48 -0700 (PDT) Date: Fri, 14 Oct 2005 16:58:09 -0700 From: Vipul Gupta To: 6lowpan@ietf.org Message-id: <687116938ee5805116a344a7ae8688aa@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 2.8 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7BIT Subject: [6lowpan] Re: MultiHop Format document issues 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Gab, The updated section still mentions the possibility that the source address is not changed by the forwarder, " Notice that whereas the destination link-layer address changes at every hop, no such change applies to the source link-layer address. The latter always points at the initial originator of the frame being forwarded." I doubt that this is even possible for devices that implement LowPAN as a software layer sitting atop existing 802.15.4 radios like the CC2420, unless, before sending each packet, the device changes its MAC address. Besides the other issues you point out in the draft, having an intermediate node emit an 802.15.4 header with someone else's source address also breaks 802.1.5.4 layer security. Consider node A sending packets for node C via node B. A and B have a security association (algorithm, key etc) as do B and C. What security processing should B apply on the packet before it sends it to C if it also wishes to keep A as the src address? [If one assumes that A, B and C all use a common key, then there are problems with replay protection as mentioned in the Sastry/Wagner paper] So it seems to me that including the source explicitly (like the destination) is the best option. And that one should use short addresses to minimize the addressing overhead. vipul Begin forwarded message: > Please read the updated section 9 on mesh delivery and comment. That > section > is available here: > > http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan- > format-00a.htm#mesh > http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan- > format-00a.txt > > I include it below for your convenience. > > -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 17 05:03:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQuB-0004ZN-06; Mon, 17 Oct 2005 05:03:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQu8-0004Yd-AF for 6lowpan@megatron.ietf.org; Mon, 17 Oct 2005 05:03:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26988 for <6lowpan@ietf.org>; Mon, 17 Oct 2005 05:03:28 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERR5G-0006Ol-Rq for 6lowpan@ietf.org; Mon, 17 Oct 2005 05:15:17 -0400 Received: by zproxy.gmail.com with SMTP id n1so919538nzf for <6lowpan@ietf.org>; Mon, 17 Oct 2005 02:03:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:thread-index:x-mimeole:message-id; b=gDI3UfJcxTR5p6uFAGWctGq1DEkeF4BKsIpPS84aty7s9Aq/DhusPOjH7979ifoSDn14FhkaT4DBHtEgbfOV7OzBveEg8c0ooYP57bnzhP6fOd2lTusouXCS4A+z5bkwlw3uu5LlXsWkY0BAhbO2dc7+im7LGnUtQMKgDGflv9U= Received: by 10.36.82.20 with SMTP id f20mr2620862nzb; Mon, 17 Oct 2005 02:03:22 -0700 (PDT) Received: from ncman ( [202.30.31.245]) by mx.gmail.com with ESMTP id j4sm8141916nzd.2005.10.17.02.03.21; Mon, 17 Oct 2005 02:03:22 -0700 (PDT) From: "Ki-Hyung Kim" To: "'Geoff Mulligan'" Subject: RE: [6lowpan] how many drafts Date: Mon, 17 Oct 2005 18:03:07 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1128760026.2159.6.camel@localhost.localdomain> Thread-Index: AcXMfoRyAfoMndK1QR2VG9YJZC9IpgGeWbhQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <435368da.696b971c.77a3.63eb@mx.gmail.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org If allowable, I would like to ask a presentation slot of 20~30minutes in WG for the routing issue of 6lowpan. The title would be "LOAD vs. AODV, DYMO vs. DYMO-low" which presents mainly functional comparisons of the routing protocols and our preliminary evaluation results. __ Ki-Hyung Kim > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Geoff Mulligan > Sent: Saturday, October 08, 2005 5:27 PM > To: 6lowpan@ietf.org > Subject: [6lowpan] how many drafts > > > Would anyone planning on presenting a draft at this next ietf please > raise their hand. We have only gotten a single hour, though we > requested two. We are trying to get scheduled for 2 hours. > > geoff > > > > _______________________________________________ > 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 Oct 17 21:01:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERfqm-000243-9U; Mon, 17 Oct 2005 21:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERfqk-00023p-Na for 6lowpan@megatron.ietf.org; Mon, 17 Oct 2005 21:01:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20872 for <6lowpan@ietf.org>; Mon, 17 Oct 2005 21:00:59 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERg28-0002Pp-52 for 6lowpan@ietf.org; Mon, 17 Oct 2005 21:12:55 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IOJ00DU26RNS6@mailout1.samsung.com> for 6lowpan@ietf.org; Tue, 18 Oct 2005 09:59:47 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IOJ009IH6RNFU@mmp2.samsung.com> for 6lowpan@ietf.org; Tue, 18 Oct 2005 09:59:47 +0900 (KST) Date: Tue, 18 Oct 2005 10:00:59 +0900 From: Soohong Daniel Park To: 6lowpan@ietf.org Message-id: <02a501c5d37f$66eccef0$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <435368da.696b971c.77a3.63eb@mx.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7BIT Subject: [6lowpan] DYMO-low for 6lowpan 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Folks, Here is a new document for DMYO over 6lowpan networks. Please use the link below before official publication. http://daniel.vsix.net/ietf/6lowpan/draft-montenegro-6lowpan-dymo-low-routing-00.txt Geoff, as Kihyung pointed out, we'd like to show the outstanding issues while comaparing original adhoc protocols (AODV and DYMO) with 6lowpan adhoc protocols (LOAD and DYMO-low). Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 18 06:23:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERocr-0007dO-OE; Tue, 18 Oct 2005 06:23:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERocp-0007bq-Hl for 6lowpan@megatron.ietf.org; Tue, 18 Oct 2005 06:23:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19599 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 06:23:11 -0400 (EDT) Received: from web81902.mail.mud.yahoo.com ([68.142.207.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERooI-0000CF-Gz for 6lowpan@ietf.org; Tue, 18 Oct 2005 06:35:13 -0400 Received: (qmail 91605 invoked by uid 60001); 18 Oct 2005 10:23: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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vYurUdaxDB4oFUpsFJxdZMOmsAhaVv0Lsie6adaUJnVnAdQ0Nbhu5axcFYrzZM7YyeSJaZwh4vIr3C6SE+Q4IdE/RkzswzCEWrdJLnHRgfRODJUECVXlB/SlTl6z6vVNeEh4EorwhVwvaNA4QrM8H8BmKWHySziZnqVIdXILcWo= ; Message-ID: <20051018102306.91603.qmail@web81902.mail.mud.yahoo.com> Received: from [24.16.92.216] by web81902.mail.mud.yahoo.com via HTTP; Tue, 18 Oct 2005 03:23:06 PDT Date: Tue, 18 Oct 2005 03:23:06 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Re: MultiHop Format document issues To: Vipul Gupta , 6lowpan@ietf.org In-Reply-To: <687116938ee5805116a344a7ae8688aa@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 8bit Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Vipul, --- Vipul Gupta wrote: ... > So it seems to me that including the source explicitly > (like the destination) is the best option. And that one > should use short addresses to minimize the addressing > overhead. I am convinced of this as well. In the note I added, I say so, although it was not clear. I think for the upcoming rev we should add that original source field, yes. Any objections? -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 18 13:55:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERvg8-0001yl-IZ; Tue, 18 Oct 2005 13:55:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERvg4-0001w3-SP for 6lowpan@megatron.ietf.org; Tue, 18 Oct 2005 13:55:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19069 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 13:54:56 -0400 (EDT) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERvrW-0005bX-NC for 6lowpan@ietf.org; Tue, 18 Oct 2005 14:07:04 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOK00MTQHR7ZK00@dps.sfvic.sunlabs.com> for 6lowpan@ietf.org; Tue, 18 Oct 2005 10:54:43 -0700 (PDT) Received: from [129.146.73.85] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOK00MWZHR7YW10@mail.sunlabs.com> for 6lowpan@ietf.org; Tue, 18 Oct 2005 10:54:43 -0700 (PDT) Date: Tue, 18 Oct 2005 10:55:09 -0700 From: Vipul Gupta Subject: Re: [6lowpan] Re: MultiHop Format document issues In-reply-to: <20051018102306.91603.qmail@web81902.mail.mud.yahoo.com> To: itijibox-6lowpan@yahoo.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20051018102306.91603.qmail@web81902.mail.mud.yahoo.com> X-Spam-Score: 2.8 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Gab, The proposal to include the original source (in addition to the final destination) sounds good to me. A related issue on which I'd like to see some more discussion is the inclusion of the original link src and final link dst on a per IP datagram v/s per fragment basis. If we use short addresses (2 bytes), then including this information in each fragment introduces around 4 bytes of overhead but allows the fragments to move through the multihop network quickly. Otherwise, the full packet would need to be reassembled at each hop which seems quite burdensome and unnecessarily restrictive. The way I understand the current draft at: http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan- format-00a.htm the final destination info (which is needed to look up the next hop at each intermediate point in the path) is only carried in the first fragment. Is this correct or just a misunderstanding on my part? vipul On Oct 18, 2005, at 3:23 AM, gabriel montenegro wrote: > > Hi Vipul, > > --- Vipul Gupta wrote: > ... >> So it seems to me that including the source explicitly >> (like the destination) is the best option. And that one >> should use short addresses to minimize the addressing >> overhead. > > I am convinced of this as well. In the note I added, I say so, > although it > was not clear. > > I think for the upcoming rev we should add that original source field, > yes. > Any objections? > > -gabriel > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 18 14:41:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwPE-0000op-TD; Tue, 18 Oct 2005 14:41:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwPC-0000og-E3 for 6lowpan@megatron.ietf.org; Tue, 18 Oct 2005 14:41:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21450 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 14:41:37 -0400 (EDT) Received: from web81910.mail.mud.yahoo.com ([68.142.207.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERwal-0006vK-Iq for 6lowpan@ietf.org; Tue, 18 Oct 2005 14:53:45 -0400 Received: (qmail 31290 invoked by uid 60001); 18 Oct 2005 18:41:35 -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:Content-Transfer-Encoding; b=cFIl7cpvu++SUFeS9qHvBAeQSW3OTxQrcbVW60mJX9fKYYEvjFJ/KAA/tGldRvFA7UIo9KyHB6j0xoWSAj6vMA6Oe6hSAAwsL65kMstMj1vJOruGfJ9ZLTfLHyeJ8rwENOwH6lf1JkmEKIBH7KVCAQjrDSnIRIwtn0ZEqaaKvig= ; Message-ID: <20051018184135.31288.qmail@web81910.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81910.mail.mud.yahoo.com via HTTP; Tue, 18 Oct 2005 11:41:34 PDT Date: Tue, 18 Oct 2005 11:41:34 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Re: MultiHop Format document issues To: Vipul Gupta , itijibox-6lowpan@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- Vipul Gupta wrote: > The way I understand the current draft at: > http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan- > format-00a.htm > the final destination info (which is needed to look > up the next hop at each intermediate point in the path) is only > carried in the first fragment. Is this correct or just a > misunderstanding > on my part? The latter. If you look at the packet formats: http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.htm#anchor6 You'll notice that the 'M' bit (and the use of the final destination field) are persent in all three variations, so yes, even middle and final fragments have this capability of being delivered in a mesh. -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 18 16:19:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxtl-0002q5-6c; Tue, 18 Oct 2005 16:17:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxtj-0002pa-7O for 6lowpan@megatron.ietf.org; Tue, 18 Oct 2005 16:17:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02339 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 16:17:14 -0400 (EDT) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERy53-00036o-Ow for 6lowpan@ietf.org; Tue, 18 Oct 2005 16:29:09 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOK0001COC1RU00@dps.sfvic.sunlabs.com> for 6lowpan@ietf.org; Tue, 18 Oct 2005 13:16:49 -0700 (PDT) Received: from [129.146.73.85] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOK0007KOC1U500@mail.sunlabs.com> for 6lowpan@ietf.org; Tue, 18 Oct 2005 13:16:49 -0700 (PDT) Date: Tue, 18 Oct 2005 13:17:15 -0700 From: Vipul Gupta Subject: Re: [6lowpan] Re: MultiHop Format document issues In-reply-to: <20051018184135.31288.qmail@web81910.mail.mud.yahoo.com> To: itijibox-6lowpan@yahoo.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20051018184135.31288.qmail@web81910.mail.mud.yahoo.com> X-Spam-Score: 2.8 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Oct 18, 2005, at 11:41 AM, gabriel montenegro wrote: > --- Vipul Gupta wrote: >> The way I understand the current draft at: >> http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan- >> format-00a.htm >> the final destination info (which is needed to look >> up the next hop at each intermediate point in the path) is only >> carried in the first fragment. Is this correct or just a >> misunderstanding >> on my part? > > The latter. If you look at the packet formats: That's good to know. Perhaps the draft could be made clearer in this respect. In particular, I misunderstood this part in Section 9.2 "This implies that the "Final Destination" field will immediately follow an unfragmented packet as per Figure 1 (i.e., preceding the IPv6 Header), or immediately following the first fragment header as per Figure 2." as precluding the inclusion of the "Final Destination" in fragments other than the first. vipul _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 18 17:53:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzP1-000844-5c; Tue, 18 Oct 2005 17:53:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzOz-00083z-RS for 6lowpan@megatron.ietf.org; Tue, 18 Oct 2005 17:53:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02357 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 17:53:37 -0400 (EDT) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERzaW-0005od-TX for 6lowpan@ietf.org; Tue, 18 Oct 2005 18:05:46 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOK0005FST1RT00@dps.sfvic.sunlabs.com> for 6lowpan@ietf.org; Tue, 18 Oct 2005 14:53:25 -0700 (PDT) Received: from [129.146.73.85] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOK000ELST1U200@mail.sunlabs.com> for 6lowpan@ietf.org; Tue, 18 Oct 2005 14:53:25 -0700 (PDT) Date: Tue, 18 Oct 2005 14:53:51 -0700 From: Vipul Gupta To: 6lowpan@ietf.org Message-id: <366dd398990120394a3aa312f3b36e7d@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 2.8 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7BIT Subject: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I couldn't find an easy way to search the archive for prior discussions on this topic but the datagram tag size of 7 bits seems too low to me. The max data rate for 802.15.4 is 250kbps. Of this, lets assume that one only achieves about 128kbps or 16KBps. At this rate, an application could potentially be pumping out 128-byte packets (this is long enough to cause each packet to be fragmented) at the rate of 128 packets per second and cause the tag field to rollover every second. So to avoid any potential of confusion due to tag reuse, one would have to assume that packets do not stay in the multihop network for more than a second or so. This expectation seems unreasonable (especially for a reactive routing protocol where route discovery alone might take this long). thoughts/comments? vipul _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 18 19:59:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1Md-0007Xq-Sy; Tue, 18 Oct 2005 19:59:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1MX-0007Vc-Ep for 6lowpan@megatron.ietf.org; Tue, 18 Oct 2005 19:59:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07991 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 19:59:11 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES1Xp-0000Bp-Fa for 6lowpan@ietf.org; Tue, 18 Oct 2005 20:11:22 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IOK003DUYLX9P@mailout1.samsung.com> for 6lowpan@ietf.org; Wed, 19 Oct 2005 08:58:45 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IOK002GVYLXJ8@mmp1.samsung.com> for 6lowpan@ietf.org; Wed, 19 Oct 2005 08:58:45 +0900 (KST) Date: Wed, 19 Oct 2005 08:59:58 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] Re: MultiHop Format document issues To: itijibox-6lowpan@yahoo.com, Samita Chakrabarti Message-id: <00f001c5d440$0b7b90d0$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20051014081540.57739.qmail@web81906.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Gabrel, > 9.1. Alternatives for Delivery of Frames in a Mesh > > Before discussing the defined mechanism for delivery in a mesh, let's > review some options on how to accomplish this. The final destination > could be expressed either as a layer 2 or as an IP (layer 3) address. > In the latter case, there would be no need to provide any additional > header support in this document (i.e., at the sub-IP layer). The > link-layer destination address would point to the next hop > destination address while the IP destination address would point to > the final destination (IP) address (that may be multiple hops away > from the source). Thus, while forwarding data, the single-hop > destination address would change at each hop (always pointing to the > "best" next link-layer hop), while the destination IP address would > remain unchanged. Notice that if an IP packet is fragmented, the > individual fragments may arrive at any node out of order. If so, if > the initial frament (which contains the IP header) is delayed for > some reason, a node that receives a middle fragment would lack the > final destination address. It would be forced to wait until this > information arrives (in the IP header within the first fragment) > before being able to forward the fragment any further. This imposes > some additional buffering requirements on intermediate nodes. > Additionally, the above scheme would need to be adapted depending on > the layer 3 protocol, and would require this protocol to include its > own addressing information. Additional buffering and final destination field always-on seem a bit trafoff. If all fragment packet includes final destination field, packet size is a bit increased (24bits if S is set or 72bits). Intermediate nodes, however, don't need any additional buffering. Increasd packet size above seems not too much big in my understanding. So, I think we should clarify this concern in above sentence... Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 18 20:06:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1TD-0002oH-4d; Tue, 18 Oct 2005 20:06:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1TB-0002o3-5z for 6lowpan@megatron.ietf.org; Tue, 18 Oct 2005 20:06:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08177 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 20:06:04 -0400 (EDT) Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ES1em-0000J9-9W for 6lowpan@ietf.org; Tue, 18 Oct 2005 20:18:14 -0400 Received: (qmail 15043 invoked by uid 60001); 19 Oct 2005 00:06:01 -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:Content-Transfer-Encoding; b=wFGSYuIMFsWe6zYU143elBAEkjztnS0m3fF9zeGC6ZFV9viM1L25hrpU6xg4g2TJWyxBR3QbzoUAN66//+xQZaTHDEzvFD2f5yxCDWF71RjaMqUeAQL6c6KUPoFAtQcIzMO+ZAhW1hcMY7b0w8ZDQJ0o2Qi0v/Xu6W4ZXxjg6EA= ; Message-ID: <20051019000601.15041.qmail@web81903.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81903.mail.mud.yahoo.com via HTTP; Tue, 18 Oct 2005 17:06:01 PDT Date: Tue, 18 Oct 2005 17:06:01 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Re: MultiHop Format document issues To: Vipul Gupta , itijibox-6lowpan@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- Vipul Gupta wrote: > > On Oct 18, 2005, at 11:41 AM, gabriel montenegro wrote: > > --- Vipul Gupta wrote: > >> The way I understand the current draft at: > >> http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan- > >> format-00a.htm > >> the final destination info (which is needed to look > >> up the next hop at each intermediate point in the path) is only > >> carried in the first fragment. Is this correct or just a > >> misunderstanding > >> on my part? > > > > The latter. If you look at the packet formats: > > > That's good to know. > > Perhaps the draft could be made clearer in this respect. In particular, > I misunderstood this part in Section 9.2 > > "This implies that the "Final Destination" field will immediately > follow an unfragmented packet as per Figure 1 (i.e., preceding the IPv6 > Header), or immediately following the first fragment header as per > Figure 2." > > as precluding the inclusion of the "Final Destination" in fragments > other than the first. Ah, yes, confusing. I've changed that paragraph to this, which hopefully works better: Mesh delivery is enabled by setting the 'M' bit present in all variations of the LoWPAN encapsulation (Section 4). If the 'M' bit is set, there is a "Mesh Delivery" field included in the frame immediately following the LoWPAN header. More precisely, in all variations of the LoWPAN encapsulation (unfragmented and fragmented), the "Mesh Delivery" field immediately precedes the LoWPAN payload (e.g., a full-blown IPv6 header, a compressed IPv6 header as per Section 8, or any others defined elsewhere). -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 18 20:19:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1dZ-0008T6-B7; Tue, 18 Oct 2005 20:16:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1dX-0008T0-D2 for 6lowpan@megatron.ietf.org; Tue, 18 Oct 2005 20:16:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08774 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 20:16:46 -0400 (EDT) Received: from web81909.mail.mud.yahoo.com ([68.142.207.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ES1p9-0000ZS-4I for 6lowpan@ietf.org; Tue, 18 Oct 2005 20:28:55 -0400 Received: (qmail 2257 invoked by uid 60001); 19 Oct 2005 00:16: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:Content-Transfer-Encoding; b=Sauewtb2CxeN/cIThq+mMzihviXEakuZ883PqvjmbONIZVFJdayLo7PRX2f1foPD1xeVezt9YVNoieTZQGhhThnFWlvPSHcPQh7POP44hr9kedUbBDWZkiSIkadRiwasImQUmKWEQxzfZ3xgxsPfP5QYSM0ibFM2ZIqzRzau84M= ; Message-ID: <20051019001644.2255.qmail@web81909.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81909.mail.mud.yahoo.com via HTTP; Tue, 18 Oct 2005 17:16:44 PDT Date: Tue, 18 Oct 2005 17:16:44 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Re: MultiHop Format document issues To: Soohong Daniel Park , itijibox-6lowpan@yahoo.com, Samita Chakrabarti In-Reply-To: <00f001c5d440$0b7b90d0$6dc6dba8@natpt> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- Soohong Daniel Park wrote: > Gabrel, > > > 9.1. Alternatives for Delivery of Frames in a Mesh > > > > Before discussing the defined mechanism for delivery in a mesh, let's > > review some options on how to accomplish this. The final destination > > could be expressed either as a layer 2 or as an IP (layer 3) address. > > In the latter case, there would be no need to provide any additional > > header support in this document (i.e., at the sub-IP layer). The > > link-layer destination address would point to the next hop > > destination address while the IP destination address would point to > > the final destination (IP) address (that may be multiple hops away > > from the source). Thus, while forwarding data, the single-hop > > destination address would change at each hop (always pointing to the > > "best" next link-layer hop), while the destination IP address would > > remain unchanged. Notice that if an IP packet is fragmented, the > > individual fragments may arrive at any node out of order. If so, if > > the initial frament (which contains the IP header) is delayed for > > some reason, a node that receives a middle fragment would lack the > > final destination address. It would be forced to wait until this > > information arrives (in the IP header within the first fragment) > > before being able to forward the fragment any further. This imposes > > some additional buffering requirements on intermediate nodes. > > Additionally, the above scheme would need to be adapted depending on > > the layer 3 protocol, and would require this protocol to include its > > own addressing information. > > Additional buffering and final destination field always-on seem a bit trafoff. If all > fragment packet includes final destination field, packet size is a bit increased > (24bits if S is set or 72bits). Intermediate nodes, however, don't need any additional > buffering. Increasd packet size above seems not too much big in my understanding. Agree, this was meant as discussion of an alternative that was *not* chosen, and why it was rejected. > So, > I think we should clarify this concern in above sentence... Yes, I'm in the process of revising the mesh stuff. Samita had also mentioned the need to revamp this section. This section was meant as background discussion, which doesn't quite seem to fit within a normative section such as this one. I've moved it into an appendix. Here's the appendix as it stands right now: Appendix A. Alternatives for Delivery of Frames in a Mesh Before settling on the mechanism finally adopted for delivery in a mesh (Section 9), several alternatives were considered. In addition to the hop-by-hop source and destination link-layer addresses, delivering a packet in a LoWPAN mesh requires the end-to-end originator and destination addresses. These could be expressed either as layer 2 or as layer 3 (i.e., IP ) addresses. In the latter case, there would be no need to provide any additional header support in this document (i.e., within the LoWPAN header itself). The link- layer destination address would point to the next hop destination address while the IP header destination address would point to the final destination (IP) address (possibly multiple hops away from the source), and similarly for the source addresses. Thus, while forwarding data, the single-hop source and destination addresses would change at each hop (always pointing to the node doing the forwarding and the "best" next link-layer hop, respectively), while the source and destination IP addresses would remain unchanged. Notice that if an IP packet is fragmented, the individual fragments may arrive at any node out of order. If the initial frament (which contains the IP header) is delayed for some reason, a node that receives a subsequent fragment would lack the required information. It would be forced to wait until it receives the IP header (within the first fragment) before being able to forward the fragment any further. This imposes some additional buffering requirements on intermediate nodes. Additionally, such a specification would only work for one type of LoWPAN payload: IPv6. In general, it would have to be adapted for any other payload, and would require that payload to provide its own end-to-end addressing information. On the other hand, the approach finally followed (Section 9) creates a mesh at the LoWPAN layer (below layer 3). Accordingly, link-layer originator and final destination address are included within the LoWPAN header. This enables mesh delivery for any protocol or application layered on the LoWPAN adaptation layer (Section 4). For IPv6 as supported in this document, another advantage of expressing the originator and final destinations as layer 2 addresses is that the IPv6 addresses can be compressed as per the header compression specified in Section 8. Furthermore, the number of octets needed to maintain routing tables is reduced due to the smaller size of 802.15.4 addresses (either 64 bits or 16 bits) as compared to IPv6 addresses (128 bits). A disadvantage is that applications on top of IP do not address packets to link-layer destination addresses, but to IP (layer 3) destination addresses. Thus, given an IP address, there is a need to resolve the corresponding link-layer address. Accordingly, a mesh routing specification needs to clarify the Neighbor Discovery implications, although in some special cases, it may be possible to derive a device's address at layer 2 from its address at layer 3 (and viceversa). Such complete specification is outside the scope of this document. -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 18 21:17:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES2Zv-0001Fz-6P; Tue, 18 Oct 2005 21:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES2Zt-0001AU-EK for 6lowpan@megatron.ietf.org; Tue, 18 Oct 2005 21:17:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11195 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 21:17:03 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES2lR-0001pA-1X for 6lowpan@ietf.org; Tue, 18 Oct 2005 21:29:10 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IOL00HPW21QUD@mailout3.samsung.com> for 6lowpan@ietf.org; Wed, 19 Oct 2005 10:13:02 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IOL007LU21PBM@mmp2.samsung.com> for 6lowpan@ietf.org; Wed, 19 Oct 2005 10:13:02 +0900 (KST) Date: Wed, 19 Oct 2005 10:14:15 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) To: Vipul Gupta , 6lowpan@ietf.org Message-id: <018501c5d44a$6c0e1da0$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <366dd398990120394a3aa312f3b36e7d@sun.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > I couldn't find an easy way to search the archive > for prior discussions on this topic but the > datagram tag size of 7 bits seems too low to me. > > The max data rate for 802.15.4 is 250kbps. > Of this, lets assume that one only achieves about > 128kbps or 16KBps. At this rate, an application could > potentially be pumping out 128-byte packets (this > is long enough to cause each packet to be fragmented) > at the rate of 128 packets per second and cause the > tag field to rollover every second. So to avoid any > potential of confusion due to tag reuse, one would > have to assume that packets do not stay in the > multihop network for more than a second or so. This > expectation seems unreasonable (especially > for a reactive routing protocol where route discovery > alone might take this long). > > thoughts/comments? Interesting point, but I am really not sure how often the tag field reuse happen in 6lowpan scenarios. The major applicable connectivity amongst 6lowpan nodes are simple control. Anything else ? Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 18 21:34:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES2qV-0000o0-9z; Tue, 18 Oct 2005 21:34:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES2qT-0000nO-AH for 6lowpan@megatron.ietf.org; Tue, 18 Oct 2005 21:34:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11806 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 21:34:13 -0400 (EDT) Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ES324-0002BN-O5 for 6lowpan@ietf.org; Tue, 18 Oct 2005 21:46:23 -0400 Received: (qmail 38979 invoked by uid 60001); 19 Oct 2005 01:34:08 -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:Content-Transfer-Encoding; b=WpNG5K7XSAgfSn+bRfQHu/rtwIol1NfAcCLQH+x8mOCB9/3WsbN/CuO1Ngwprh+frflhcCuRZi0fU3D6hASa07EAr3dd546hwqKyIdTWfWp8qUSGTFm87s+lBufFOSwkMzJ8VoyC/v6C2eELtpiR0wYnZOSjPTuLwHOM3XBud+8= ; Message-ID: <20051019013408.38977.qmail@web81903.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81903.mail.mud.yahoo.com via HTTP; Tue, 18 Oct 2005 18:34:08 PDT Date: Tue, 18 Oct 2005 18:34:08 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) To: Vipul Gupta , 6lowpan@ietf.org In-Reply-To: <366dd398990120394a3aa312f3b36e7d@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 8bit Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- Vipul Gupta wrote: > I couldn't find an easy way to search the archive > for prior discussions on this topic but the > datagram tag size of 7 bits seems too low to me. Don't think there's been any discussion on this topic. > The max data rate for 802.15.4 is 250kbps. > Of this, lets assume that one only achieves about > 128kbps or 16KBps. At this rate, an application could this rate sounds reasonable as a maximum actual throughput (assuming ACKs being turned on). > potentially be pumping out 128-byte packets (this > is long enough to cause each packet to be fragmented) > at the rate of 128 packets per second and cause the > tag field to rollover every second. So to avoid any > potential of confusion due to tag reuse, one would > have to assume that packets do not stay in the > multihop network for more than a second or so. This > expectation seems unreasonable (especially > for a reactive routing protocol where route discovery > alone might take this long). does sound unreasonably short. one could also say that no matter how much we decide to grow the tag field, after a certain rate, the fragmentation and reassembly services of the adaptation layer do not apply anymore. apps that spew out more than a certain volume of traffic (TBD) would then have to provide fragmentation and reassembly at their layer. notice that they could continue using mesh delivery, they would just spew out "unfragmented" (at the lowpan layer) packets. The issue is, as always, one of tradeoff. should we specify a field that will be future proof and cover all possible cases? with 15.4a's defining two new PHYs (UWB and "chirp" spread spectrum), who knows what rates we might have. i've heard that anything from 50kbps up to 1Mbps or so is possible. could anyone who follows 15.4a confirm? let's say it's 1Mbps. this means that even if we grow the tag to 10 bits, we'd see a rollover about every second. we could, on the other hand, simply grow it to, say, 16 bits for a rollover every minute or so at 1Mbps (someone check the math). depending on the mesh, one minute may be cutting it short as well, given store and forwarding, transient network partitions, etc. heck, might as well grow it to 32 bits and be done with it. sure, that imposes quite an overhead over apps that cause fragments to occur. But, if so, they *deserve* it (one could see this as the "fragmentation tax"). This fragmentation and reassembly capability is supposed to be used sparingly (if at all), so any overhead to the fragmentation packets does not apply normal operation. just some thoughts. what do others think? -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 19 00:48:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES5sW-0007tm-Oh; Wed, 19 Oct 2005 00:48:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES5sU-0007tT-FO for 6lowpan@megatron.ietf.org; Wed, 19 Oct 2005 00:48:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20237 for <6lowpan@ietf.org>; Wed, 19 Oct 2005 00:48:29 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES646-0006YZ-B4 for 6lowpan@ietf.org; Wed, 19 Oct 2005 01:00:42 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9J4mQeT015505 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 22:48:26 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IOL009N8C0PWJ@edgemail1.Central.Sun.COM> for 6lowpan@ietf.org; Tue, 18 Oct 2005 22:48:26 -0600 (MDT) Received: from [192.168.10.4] ([71.131.82.117]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IOL000N0C0NJ8@mail.sun.net> for 6lowpan@ietf.org; Tue, 18 Oct 2005 22:48:24 -0600 (MDT) Date: Tue, 18 Oct 2005 21:48:19 -0700 From: Vipul Gupta Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) In-reply-to: <018501c5d44a$6c0e1da0$6dc6dba8@natpt> To: Soohong Daniel Park Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <366dd398990120394a3aa312f3b36e7d@sun.com> <018501c5d44a$6c0e1da0$6dc6dba8@natpt> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Oct 18, 2005, at 6:14 PM, Soohong Daniel Park wrote: >> I couldn't find an easy way to search the archive >> for prior discussions on this topic but the >> datagram tag size of 7 bits seems too low to me. >> >> The max data rate for 802.15.4 is 250kbps. >> Of this, lets assume that one only achieves about >> 128kbps or 16KBps. At this rate, an application could >> potentially be pumping out 128-byte packets (this >> is long enough to cause each packet to be fragmented) >> at the rate of 128 packets per second and cause the >> tag field to rollover every second. So to avoid any >> potential of confusion due to tag reuse, one would >> have to assume that packets do not stay in the >> multihop network for more than a second or so. This >> expectation seems unreasonable (especially >> for a reactive routing protocol where route discovery >> alone might take this long). >> >> thoughts/comments? > > Interesting point, but I am really not sure how often the tag field > reuse happen in 6lowpan scenarios. The major applicable connectivity > amongst 6lowpan nodes are simple control. Anything else ? You are certainly correct in the assumption that many applications are unlikely to involve high data rates (at least not all the time). However, there are several applications (e.g. structural monitoring etc.) where an application keeps collecting sensor readings until some application specific buffer is full and then turns on the radio and to send data back to a central collection site. In such "bursty traffic" scenarios, tag rollover could be an issue even though the "average" data rate is very low. vipul _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 19 00:57:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES61B-00041r-Mt; Wed, 19 Oct 2005 00:57:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES619-00041i-Jd for 6lowpan@megatron.ietf.org; Wed, 19 Oct 2005 00:57:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20689 for <6lowpan@ietf.org>; Wed, 19 Oct 2005 00:57:26 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES6Cp-0006nE-6g for 6lowpan@ietf.org; Wed, 19 Oct 2005 01:09:39 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9J4vYeT019898 for <6lowpan@ietf.org>; Tue, 18 Oct 2005 22:57:34 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IOL00AO1CFX1Q@edgemail1.Central.Sun.COM> for 6lowpan@ietf.org; Tue, 18 Oct 2005 22:57:34 -0600 (MDT) Received: from [192.168.10.4] ([71.131.82.117]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IOL000N4CFWJ8@mail.sun.net> for 6lowpan@ietf.org; Tue, 18 Oct 2005 22:57:33 -0600 (MDT) Date: Tue, 18 Oct 2005 21:57:28 -0700 From: Vipul Gupta Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) In-reply-to: <20051019013408.38977.qmail@web81903.mail.mud.yahoo.com> To: itijibox-6lowpan@yahoo.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20051019013408.38977.qmail@web81903.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Given that IPv4 has managed to do fine with a 16-bit identifier, I'd say this size represents a reasonable compromise. vipul On Oct 18, 2005, at 6:34 PM, gabriel montenegro wrote: > --- Vipul Gupta wrote: > >> I couldn't find an easy way to search the archive >> for prior discussions on this topic but the >> datagram tag size of 7 bits seems too low to me. > > Don't think there's been any discussion on this topic. > >> The max data rate for 802.15.4 is 250kbps. >> Of this, lets assume that one only achieves about >> 128kbps or 16KBps. At this rate, an application could > > this rate sounds reasonable as a maximum actual throughput > (assuming ACKs being turned on). > >> potentially be pumping out 128-byte packets (this >> is long enough to cause each packet to be fragmented) >> at the rate of 128 packets per second and cause the >> tag field to rollover every second. So to avoid any >> potential of confusion due to tag reuse, one would >> have to assume that packets do not stay in the >> multihop network for more than a second or so. This >> expectation seems unreasonable (especially >> for a reactive routing protocol where route discovery >> alone might take this long). > > does sound unreasonably short. one could also say that no > matter how much we decide to grow the tag field, after a certain > rate, the fragmentation and reassembly services of the > adaptation layer do not apply anymore. apps that > spew out more than a certain volume of traffic (TBD) would > then have to provide fragmentation and reassembly at their layer. > notice that they could continue using mesh delivery, they would > just spew out "unfragmented" (at the lowpan layer) packets. > > The issue is, as always, one of tradeoff. should we specify a field > that will be future proof and cover all possible cases? with 15.4a's > defining two new PHYs (UWB and "chirp" spread spectrum), who knows > what rates we might have. i've heard that anything from 50kbps up > to 1Mbps or so is possible. could anyone who follows 15.4a confirm? > let's say it's 1Mbps. this means that even if we grow the tag to 10 > bits, we'd see a rollover about every second. > > we could, on the other hand, simply grow it to, say, 16 bits for a > rollover > every minute or so at 1Mbps (someone check the math). depending on the > mesh, one > minute may be cutting it short as well, given store and forwarding, > transient > network partitions, etc. heck, might as well grow it to 32 bits and be > done with it. > > sure, that imposes quite an overhead over apps that cause fragments to > occur. > But, if so, they *deserve* it (one could see this as the > "fragmentation tax"). > This fragmentation and reassembly capability is supposed to > be used sparingly (if at all), so any overhead to the fragmentation > packets > does not apply normal operation. > > just some thoughts. what do others think? > > -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 19 15:33:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJh6-0003k2-EO; Wed, 19 Oct 2005 15:33:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJh4-0003jr-Ps for 6lowpan@megatron.ietf.org; Wed, 19 Oct 2005 15:33:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08555 for <6lowpan@ietf.org>; Wed, 19 Oct 2005 15:33:36 -0400 (EDT) Received: from web81910.mail.mud.yahoo.com ([68.142.207.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESJsq-00067s-2b for 6lowpan@ietf.org; Wed, 19 Oct 2005 15:45:58 -0400 Received: (qmail 4569 invoked by uid 60001); 19 Oct 2005 19:33:34 -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:Content-Transfer-Encoding; b=Aj1/IHUvHwuAitcT02u4dZ8dmhu4fQM/TOJvXE+nwcVzkmncQq9HaSnUC29jS7mSxqX38Zyd+fNbeYuYsY2dN8DwIrrHgzV5bLeU+Pmue+/iNWG+8QVuzsDvZXsUyaBXdi5hUP9mYSfz74XWKyfJJUlBZDlNGiNRQ9AjR+0JMFA= ; Message-ID: <20051019193334.4567.qmail@web81910.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81910.mail.mud.yahoo.com via HTTP; Wed, 19 Oct 2005 12:33:34 PDT Date: Wed, 19 Oct 2005 12:33:34 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) To: Vipul Gupta , itijibox-6lowpan@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- Vipul Gupta wrote: > Given that IPv4 has managed to do fine with a I wouldn't necessarily say that IPv4 is fine with only 16 bits. This is a known issue. See for example: http://www.watersprings.org/pub/id/draft-mathis-frag-harmful-00.txt And some updated discussion in the context of tunnels in: http://www.ietf.org/internet-drafts/draft-savola-mtufrag-network-tunneling-05.txt > 16-bit identifier, I'd say this size represents a > reasonable compromise. 16 bits would buy us over a minute at 1Mbps (dunno if this is a possible rate in the future, though). For comparison, RFC 1122 (3.3.2 Reassembly) requires that the IPv4 reassembly timeout be between 1 and 2 minutes. Not sure what is reasonable for us to drive for. Given that these puny devices have to put out all that traffic, do we understand the system implications of such a feat? How reasonable is it to expect the required buffer space, bus bandwidth (I2C, etc) on these platforms to sustain that level of offered traffic? Of course, one can always 15.4-enable a regular computer, in which case such sustained throughput is not an issue. However, I wouldn't know the difference between this scenario and a "denial of service" attack... Frankly, I don't loose much sleep over this, and would be fine even at less than 16 bits. For example, even if 1 Mbps were possible with 802.15.4a (my guess is that we won't have that) it would represent 512K max, by the same reason that 802.15.4's "250Kbps" becomes a max (perhaps unattained) of actual 128Kbps on the wire, If so, 15 bits is fine and would give us over a minute before rollover at 512K. If we just look at the packet formats, and extrapolate, here's an example of what one might end up with: Format 2: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| prot_type |M| datagram_size |datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Format 3: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| datagram_offset |M| datagram_size |datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What do folks think? We haven't discussed at all about alignment issues (perhaps a discussion to have with respect to IPv6 header alignment requirements, implications and what we wish to do about it), but the above keeps an octet alignment. Typical radio chips will read in min 1 octet most probably 2 octets at a time, I believe. Comments? -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 19 16:25:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKG9-00030j-1t; Wed, 19 Oct 2005 16:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKG6-0002zf-RZ for 6lowpan@megatron.ietf.org; Wed, 19 Oct 2005 16:09:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14549 for <6lowpan@ietf.org>; Wed, 19 Oct 2005 16:09:47 -0400 (EDT) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESKRk-0000Dl-F7 for 6lowpan@ietf.org; Wed, 19 Oct 2005 16:22:06 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOM0011JINRNW00@dps.sfvic.sunlabs.com> for 6lowpan@ietf.org; Wed, 19 Oct 2005 13:09:27 -0700 (PDT) Received: from [129.146.73.85] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOM001ANINQUJ00@mail.sunlabs.com> for 6lowpan@ietf.org; Wed, 19 Oct 2005 13:09:27 -0700 (PDT) Date: Wed, 19 Oct 2005 13:09:54 -0700 From: Vipul Gupta Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) In-reply-to: <20051019193334.4567.qmail@web81910.mail.mud.yahoo.com> To: 6lowpan@ietf.org Message-id: <2d70d83e0f8ae8f85bcec9a47399e0cb@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20051019193334.4567.qmail@web81910.mail.mud.yahoo.com> X-Spam-Score: 2.8 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org 15 bits should be ok for the data rates we are dealing with and still support reassembly timers in the order of 1min. However, if we need an extra bit, one could possibly take that from the prot_type and the datagram_offset fields (for the latter one could use a mechanism similar to what's used in IPv4 and IPv6 and specify the offset in 2 byte units -- IPv4 and IPv6 use 8-byte units). It might also make sense to reserve a portion of the prot_type space for private use among consenting parties. Has there been any discussion on including a version field in the LowPAN header for future extensions (it could be fairly short 2-4 bits)? vipul On Oct 19, 2005, at 12:33 PM, gabriel montenegro wrote: > If we just look at the packet formats, and extrapolate, here's an > example of what > one might end up with: > > Format 2: > 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LF| prot_type |M| datagram_size |datagram_tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | datagram_tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Format 3: > 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LF| datagram_offset |M| datagram_size |datagram_tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | datagram_tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > What do folks think? > > We haven't discussed at all about alignment issues (perhaps a > discussion > to have with respect to IPv6 header alignment requirements, > implications > and what we wish to do about it), but the above keeps > an octet alignment. Typical radio chips will read in min 1 octet most > probably 2 octets at a time, I believe. > > Comments? > > -gabriel > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 19 18:16:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMER-0006yJ-2w; Wed, 19 Oct 2005 18:16:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMEP-0006y9-Ms for 6lowpan@megatron.ietf.org; Wed, 19 Oct 2005 18:16:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08221 for <6lowpan@ietf.org>; Wed, 19 Oct 2005 18:16:12 -0400 (EDT) Received: from web81909.mail.mud.yahoo.com ([68.142.207.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESMQD-0001S3-38 for 6lowpan@ietf.org; Wed, 19 Oct 2005 18:28:34 -0400 Received: (qmail 23466 invoked by uid 60001); 19 Oct 2005 22:16:10 -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:Content-Transfer-Encoding; b=It/E1VPF9yXZCXFVxGkQg1BX72gHw3igSW13ANadK81AxPtDgHwjfiIo2HTu4KVNGB/p/lPyEyHtAlfS6nTIb+HZwHEQ89ejIuryzLojds9ctwsnS9CNsexKrFnFkk5gJdHMxcBZrUqeUQM1kuK6Wpj6RPQKA0yznVRaKFcL7eo= ; Message-ID: <20051019221610.23464.qmail@web81909.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81909.mail.mud.yahoo.com via HTTP; Wed, 19 Oct 2005 15:16:09 PDT Date: Wed, 19 Oct 2005 15:16:09 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) To: Vipul Gupta , 6lowpan@ietf.org In-Reply-To: <2d70d83e0f8ae8f85bcec9a47399e0cb@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 8bit Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- Vipul Gupta wrote: > 15 bits should be ok for the data rates we are dealing with > and still support reassembly timers in the order of 1min. > However, if we need an extra bit, one could possibly take > that from the prot_type and the datagram_offset fields > (for the latter one could use a mechanism similar to what's > used in IPv4 and IPv6 and specify the offset in 2 byte > units -- IPv4 and IPv6 use 8-byte units). > > It might also make sense to reserve a portion of the prot_type > space for private use among consenting parties. Has there > been any discussion on including a version field in the > LowPAN header for future extensions (it could be fairly > short 2-4 bits)? If one were to do both (add a fixed version field, say 2 bits, and add one bit to the datagram tag), we'd need 3 bits in header formats 2 and 3, where both the version and the enlarged datagram tag appear. In the header formats 1 and 2, these 3 bits could come from the protocol type (reducing to 8 from 11 bits, which is still enough, I think), and in header format 3 they'd come from the datagram tag (meaning we'd specify offsets in 8 octet units). Here's what formats might look like: Format 1: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF|Ver| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Format 2: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF|Ver| prot_type |M| datagram_size | datagram_tag... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |...datagram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Format 3: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF|Ver|datagram_offset|M| datagram_size | datagram_tag... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |...datagram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ protocol type and datagram offset now at 8bits datagram tag now at 16 bits Comments? -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 19 18:32:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMU8-0004xh-BM; Wed, 19 Oct 2005 18:32:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMU6-0004xc-KN for 6lowpan@megatron.ietf.org; Wed, 19 Oct 2005 18:32:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09341 for <6lowpan@ietf.org>; Wed, 19 Oct 2005 18:32:25 -0400 (EDT) Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESMft-00020L-KL for 6lowpan@ietf.org; Wed, 19 Oct 2005 18:44:48 -0400 Received: (qmail 48014 invoked by uid 60001); 19 Oct 2005 22:32:23 -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:Content-Transfer-Encoding; b=5/OTnoiRAMAmc3JVs84Senc5d1N8D84HP4XRucv/o3nj39Yw6hbNkf/Ewkkq9mOcF0LPO5uH/D0ZJ+GMFt3XRr2I8cMDejWeekfmUHc64cPMy8Wj3WgEyAUdcKrlkgnxHkW2aeUBULcvaMbovLpDvH1SEAfJKD1Hki2xAWWqPUM= ; Message-ID: <20051019223223.48012.qmail@web81903.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81903.mail.mud.yahoo.com via HTTP; Wed, 19 Oct 2005 15:32:23 PDT Date: Wed, 19 Oct 2005 15:32:23 -0700 (PDT) From: gabriel montenegro To: Vipul Gupta , 6lowpan@ietf.org In-Reply-To: <20051019221610.23464.qmail@web81909.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit Cc: Subject: [6lowpan] co-existence [was: Datagram tag size (draft-ietf-6lowpan-format-00a.txt)] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- gabriel montenegro wrote: > bla, bla, ... > ... > Format 1: > 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LF|Ver| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Actually, the Ver(sion) field would probably preced the LF field. Something that bothers me is the question of co-existence with, say, Zigbee, which also layers itself on top of 15.4 directly. In a LoWPAN network, when looking into the 15.4 payload, the first bits one would see would be the 'Ver' bits (presumably 0 for this first version). If a Zigbee network were to overlap (perhaps on purpose for dual-stack devices), I don't know what those first bits would be. So, while 'Ver' bits are fine in that they allow us to multiplex among the different versions of the lowpan encapsulation, it would be good to also be able to multiplex among the different types of 15.4 payloads (e.g., zigbee vs. lowpan). I don't include proprietary schemes, cuz they are so for a reason, and are definitely the majority now, and perhaps will remain so. Impossible to coordinate with all of them. But do folks see how one might be able to coordinate with zigbee? -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 19 21:30:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESPGg-0008NU-0X; Wed, 19 Oct 2005 21:30:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESPGb-0008NJ-Sr for 6lowpan@megatron.ietf.org; Wed, 19 Oct 2005 21:30:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01790 for <6lowpan@ietf.org>; Wed, 19 Oct 2005 21:30:39 -0400 (EDT) Received: from web81909.mail.mud.yahoo.com ([68.142.207.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESPSR-000318-St for 6lowpan@ietf.org; Wed, 19 Oct 2005 21:43:04 -0400 Received: (qmail 76218 invoked by uid 60001); 20 Oct 2005 01:30:37 -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:Content-Transfer-Encoding; b=TBtm+EkNqCIlFLIc1Km1DAVKN8XSM8dwVbnmSR0F/R+guDCynySUa91ZIS8vj4uztvyPlMSaGB1ds960RBMZumvtLdYbdu87twx7X0NU3Q0Mx4kzG/yOjXIr3F62YG1Ds4qapD8yb0+E0B2jWfUwwpvYJGDrJVr46TkZty/Dsp8= ; Message-ID: <20051020013037.76216.qmail@web81909.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81909.mail.mud.yahoo.com via HTTP; Wed, 19 Oct 2005 18:30:37 PDT Date: Wed, 19 Oct 2005 18:30:37 -0700 (PDT) From: gabriel montenegro To: Samita Chakrabarti , itijibox-6lowpan@yahoo.com In-Reply-To: <200510142055.j9EKti8S430351@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: [6lowpan] Re: MultiHop Format document issues X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Here's another preliminary version of the doc: http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00b.htm http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00b.txt Please look it over, specially as related to the changes: Appendix B. Changes Changes from version draft-ietf-6lowpan-format-00.txt to version draft-ietf-6lowpan-format-01.txt are as follows: TODO: Add support for 16-bit "short" addresses. TODO: Added 'Ver' field, and one more bit to datagram tag (from 15 to 16 bits). protocol_type and datagram offset both went from 11 to 8 bits (which is still enough for the format, and which implies counting offset in units of 8 octets for the latter). Changed both fragmentation formats, moved the datagram tag towards the end, and increased its length from 7 to 15 bits. Addition of the originator's link-layer source address to the "Mesh Delivery" header. Changed name of "Final Destination" header to "Mesh Delivery" header. Further clarification on mesh delivery. Sundry editorial changes. As for your message, please find some answers below... -gabriel --- Samita Chakrabarti wrote: > > > Q1: What is meant by 'used for adhoc or mesh routing' ? I assume that it > > > means M bit is used for both control and data path for multihop routing - > > > is it correct? > > > > It's meant for data delivery. You would run your favorite mesh protocol > > (aodv, dymo, olsr, etc) without using the 'M' bit, cuz these go hop-by-hop. > > One could think of ways in which one could run them even with an 'M' bit > > on, but this is perhaps more for discussion f2f. > > For RREQ forward path M bit is not necessary, because all nodes use bcast. > For RREP from destination to the original sender, it might be useful > it seems.[ when AODV runs on link-layer] ah, yes, ok. > > > It seems if we can come up with a IEEE address format for lowpan, then > > > it can be compressed easily over a LowPAN network to include both > > > originator address and final address. > > > > I don't think we have the charter to define layer 2 addressing. Besides, > > I don't see the point, cuz if a PAN is using 16-bit (short) addresses > > as per 802.15.4, they would take much less space. Might as well use that. > > > > > > > Are we re-thinking of IPv6-address format ( the low 64bit part) as well ? > fe80:0:0:::<16bit-addr>? ah, i see. you're talking about the interface identifier (IID) format based on the link-layer address. yes, that's one of the things that an ip-over-foo is expected to specify. we already did for the 64-bit format. for the 16-bit 15.4 link-layer format, your suggestion is the simplest, yes. we're already suggesting adding a to a /48 to obtain a prefix identifier so this would play into that as well. but for IIDs we can actually mandate the above format. going through the draft and adding support for short bit addresses is still on the TODO list, hopefully we can do it before the cut-off. > ... > Currently it says 'Final destination field' - I suppose, it's going to change > to 'Final Destination header' or alike? > If we add source link-layer address as well, then I'd really like to see > a suggestion for header compression in case of 64bit addresses, even though > IETF charter may not allow to specify IEEE address format. Do you think, it > might be something that should be brought up at the IEEE meetings? not sure what you mean here. > If we use 16bit short addresses only, do we see any disadvantages in > routing directly to the Internet other than limitation of address space? not sure why. any link-layer addresses are supposed to be used on your local link. so routing to the internet only plays in that you must find a router to send stuff off-link. this router would be on your local link, of course, so it would an address on that link just like anybody else (e.g., short 16-bit address if on a 15.4 link). perhaps i misunderstood the question. > As for naming, I'd prefer 'Mesh Delivery header'. ok. > > Please read the updated section 9 on mesh delivery and comment. That section > > is available here: > > > > > http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.h > tm#mesh > > > http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.t > xt > > > > I include it below for your convenience. > > Thanks so much. Please the comments in-line. > > > 9. Frame Delivery in a Link-Layer Mesh > > > > Even though 802.15.4 networks are expected to commonly use mesh > > routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] does not > > define such capability. In such cases, an ad hoc or mesh routing > > protocol populates the devices' routing tables. A device that wishes > > to send a frame may, in such cases, use other intermediate devices as > > forwarders towards the final destination. In order to achieve such > > frame delivery using unicast, it is necessary to include the final > > destination in addition to the hop-by-hop destination. > > > > 9.1. Alternatives for Delivery of Frames in a Mesh > > > > Before discussing the defined mechanism for delivery in a mesh, let's > > review some options on how to accomplish this. The final destination > > could be expressed either as a layer 2 or as an IP (layer 3) address. > > In the latter case, there would be no need to provide any additional > > header support in this document (i.e., at the sub-IP layer). The > > link-layer destination address would point to the next hop > > destination address while the IP destination address would point to > > the final destination (IP) address (that may be multiple hops away > > from the source). Thus, while forwarding data, the single-hop > > destination address would change at each hop (always pointing to the > > "best" next link-layer hop), while the destination IP address would > > remain unchanged. Notice that if an IP packet is fragmented, the > > individual fragments may arrive at any node out of order. If so, if > > the initial frament (which contains the IP header) is delayed for > > some reason, a node that receives a middle fragment would lack the > > final destination address. It would be forced to wait until this > > information arrives (in the IP header within the first fragment) > > before being able to forward the fragment any further. This imposes > > some additional buffering requirements on intermediate nodes. > > Additionally, the above scheme would need to be adapted depending on > > the layer 3 protocol, and would require this protocol to include its > > own addressing information. > > > > > Perhaps a subheader for 'Using L3 Final Destination field' and 'Using L2 Final > Destination Field' would look a litle clear. I just moved the above section into an appendix. > As for L3 final destination address, I understand : > > - The routing still happens in L3 layer; each node derives the next hop > L2 address corresponding to the next-hop IP-address in the routing table > given the final destination IPv6 address. > > - The Final destination field is useful when IPv6 pkt is fragmented over the > link. If not fragmented, Final destination IP-address is not needed. > > - If the IPv6 packet is not fragmented, and we use L3 routing, we don't > need to set M bit. > > Are the above assumptions correct? If yes, perhaps then a clarification > on them in the above text is helpful. This was one option we did not choose, so I've left the text pretty much unchanged (with some minor edits, perhaps it's clearer). We might want to remove this altogether before publicatino. -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 20 03:54:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVGE-000711-9k; Thu, 20 Oct 2005 03:54:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVGC-0006zM-GU for 6lowpan@megatron.ietf.org; Thu, 20 Oct 2005 03:54:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22809 for <6lowpan@ietf.org>; Thu, 20 Oct 2005 03:54:38 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESVS5-0006eB-Eu for 6lowpan@ietf.org; Thu, 20 Oct 2005 04:07:06 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ION003MMFAWQM@mailout1.samsung.com> for 6lowpan@ietf.org; Thu, 20 Oct 2005 16:54:32 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0ION00LUDFAWT7@mmp1.samsung.com> for 6lowpan@ietf.org; Thu, 20 Oct 2005 16:54:32 +0900 (KST) Date: Thu, 20 Oct 2005 16:55:49 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] comments on the load document To: Soohong Daniel Park , "Kushalnagar, Nandakishore" , 6lowpan@ietf.org Message-id: <018501c5d54b$af7a52a0$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Catching up with this comment... Nandu, sorry for loooong delay. Route Cost is one of important elements in LOAD and 6lowpan node decides more good link quality than before accordingly. Also it is applied to DYMO-low. Still...I am not sure why Cost Type would be embedded into header. Upon checking the Route Cost field of header, 6lowpan node will decide its own decision regardless of Cost Type. On the other hand, even if there are lots of bits available to use, I think *Reserved* MUST come after *specific bits - R/D/O...* for further extension regardless of a new fields such as Cost Type... Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: Kushalnagar, Nandakishore To: 6lowpan@ietf.org Sent: Thursday, August 04, 2005 8:49 AM Subject: [6lowpan] comments on the load document Daniel, I think it seems to be a pretty comprehensive document to tailor AODV for 6lowpan. I have 1 major comment and 1 suggestion. The accumulation routing metric tbd in this document is interesting as I see the reason you want to do this is to give a holistic picture of bidirectional routing. But just accumulation of the routing cost as is has these problems: 1. the route reply cost will always be worser than the request cost and hence the underlying operation would change for route comparison with forward and reverse metrics. (section 2. as far as I see this is an option that vendors MAY choose to implement and hence must be an option. I would like to propose an idea of having routing metric type: If we think of sensor networks, the path chosen depends on what kind of metric you choose. In 6lowpans, these metrics can be dynamic. For example imagine when all nodes are running on full power, the nodes may choose routing metric to be end to end delay, lqi, hop count, etc. When nodes start loosing battery, the nodes may want to choose a different metric based on remaining life time. Thus a routing metric type within the routing header is extremely important to lowpans more than other kinds of network. Here we can say how we plan to accomplish this within the LOAD scope as there are a lot of bits available to use. Here is my suggestion: The current format for route request is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|D|O|Reserved | RREQ ID | Route cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Originator Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Suggested format change for route request could be: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|D|O|B| Cost Type | RREQ ID | Route cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Originator Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B: Bidirectional cost when accumulation happens in a bidirectional manner Cost Type: This is a cost type that dictates the type of routing cost present in the header. The following are the current cost types known: 0: Hop count(All routing implementations must support this type) 1: End to end delay 2: lqi 3: Battery lifetime 4-127: TBD 128-255: Vendor dependent The current format for route response is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|D|O|Reserved | RREQ ID | Route cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link layer Originator Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Suggested format change is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|D|O|B| Cost Type | RREQ ID | Route cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link layer Originator Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B: Bidirectional cost when accumulation happens in a bidirectional manner Cost Type: This is a cost type that dictates the type of routing cost present in the header. The following are the current cost types known: 0: Hop count (All routing implementations must support this type) 1: End to end delay 2: lqi 3: Battery lifetime 4-127: TBD 128-255: Vendor dependent Current RERR message error codes Numeric value for describing error. 0x00 = No available route 0x01 = Low battery 0x02 - 0xff = reserved (TBD) Suggested changes in error codes: 0x00 = No available route 0x01 = routing cost not supported 0x02 - 0xff = reserved (TBD) Nandu _______________________________________________ 6lowpan mailing list 6lowpan@lists.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 Oct 20 19:13:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjbB-0001Op-Qb; Thu, 20 Oct 2005 19:13:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjb9-0001Nb-G2 for 6lowpan@megatron.ietf.org; Thu, 20 Oct 2005 19:13:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28259 for <6lowpan@ietf.org>; Thu, 20 Oct 2005 19:13:13 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESjn6-0007q8-TP for 6lowpan@ietf.org; Thu, 20 Oct 2005 19:25:48 -0400 Received: from jurassic.eng.sun.com ([129.146.224.130]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9KNDEeT028592; Thu, 20 Oct 2005 17:13:15 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id j9KNDEFZ286970; Thu, 20 Oct 2005 16:13:14 -0700 (PDT) Message-Id: <200510202313.j9KNDEFZ286970@jurassic.eng.sun.com> Date: Thu, 20 Oct 2005 16:10:54 -0700 (PDT) From: Samita Chakrabarti To: itijibox-6lowpan@yahoo.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /AkSMwFkfEeTF6xyUBOl1A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 6lowpan@ietf.org Subject: [6lowpan] Re: MultiHop Format document issues X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Gabe, Thanks for the update. See below. > Here's another preliminary version of the doc: > > http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00b.h tm > http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00b.t xt > > Please look it over, specially as related to the changes: > I'll do. But will not have time before the draft cut-off deadline. > > Are we re-thinking of IPv6-address format ( the low 64bit part) as well ? > > fe80:0:0:::<16bit-addr>? > > ah, i see. you're talking about the interface identifier (IID) format based on > the link-layer address. yes, that's one of the things that an ip-over-foo > is expected to specify. we already did for the 64-bit format. for the > 16-bit 15.4 link-layer format, your suggestion is the simplest, yes. > we're already suggesting adding a to a /48 to obtain a prefix identifier > so this would play into that as well. but for IIDs we can actually mandate > the above format. going through the draft and adding support for short bit > addresses is still on the TODO list, hopefully we can do it before the cut-off. > great! Thanks. > > Currently it says 'Final destination field' - I suppose, it's going to change > > to 'Final Destination header' or alike? > > If we add source link-layer address as well, then I'd really like to see > > a suggestion for header compression in case of 64bit addresses, even though > > IETF charter may not allow to specify IEEE address format. Do you think, it > > might be something that should be brought up at the IEEE meetings? > > not sure what you mean here. I was thinking of using some formating scheme in 64bit address format- especially in the higher 48bit part - a crude example: :<16bit-otherid><16bit hardware-id>. Having a formatting scheme may help compressing the 64bit address into a 32bit address - thus we can accomodate both originator and final destination address into the 64bit address space. -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 20 19:52:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESk6K-0008Ix-5v; Thu, 20 Oct 2005 19:45:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESk6I-0008I7-FT for 6lowpan@megatron.ietf.org; Thu, 20 Oct 2005 19:45:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09255 for <6lowpan@ietf.org>; Thu, 20 Oct 2005 19:45:22 -0400 (EDT) Received: from web81904.mail.mud.yahoo.com ([68.142.207.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESkCT-0005E8-IQ for 6lowpan@ietf.org; Thu, 20 Oct 2005 19:51:59 -0400 Received: (qmail 15843 invoked by uid 60001); 20 Oct 2005 23:39:21 -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:Content-Transfer-Encoding; b=wJj41EMBwXwUwobjLNNlIdbF5Ch3KVdcaimTwUzrSL7P9Z2Iv+MFnXZE4FTrvumFwvuTP4y+3xXmi3cXdUI16uX76rLMulPHaGasYP9njMCK4hMqMU1MDKM7cwwXVfiwUQshyHng5YB3yEa/+JjkRpW86qsPGAANR4u9wmVW/A0= ; Message-ID: <20051020233921.15841.qmail@web81904.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81904.mail.mud.yahoo.com via HTTP; Thu, 20 Oct 2005 16:39:21 PDT Date: Thu, 20 Oct 2005 16:39:21 -0700 (PDT) From: gabriel montenegro To: Samita Chakrabarti In-Reply-To: <200510202313.j9KNDEFZ286970@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: [6lowpan] Re: MultiHop Format document issues X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --- Samita Chakrabarti wrote: > I was thinking of using some formating scheme in 64bit address format- > especially in the higher 48bit part - a crude example: format>:<16bit-otherid><16bit hardware-id>. Having a formatting scheme > may help compressing the 64bit address into a 32bit address - thus > we can accomodate both originator and final destination address into the > 64bit address space. wouldn't want to go there: - this is IEEE's turf (the above would be an alternate format the the EUI-64 which already includes 24 bits for company_id) - ignoring the top bits (presumably company id) means we can have collisions if we only look at the bottom bits (these bottom bits are only required to be unique within a given company_id space - presumably, the IEEE went for EUI-64 instead of the typical EUI-48 precisely because with 15.4 devices one expects so many of them. cutting back on the number of bits we have to tell them apart (from 64 to 32 per address if I understand your proposal) defeats that purpose - there's an existing alternative: use short 16-bit addresses as specified by 15.4. -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 20 20:03:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESkNA-0003VM-FK; Thu, 20 Oct 2005 20:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESkN8-0003Sp-Tf for 6lowpan@megatron.ietf.org; Thu, 20 Oct 2005 20:02:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11056 for <6lowpan@ietf.org>; Thu, 20 Oct 2005 20:02:46 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESkUd-0007iq-NE for 6lowpan@ietf.org; Thu, 20 Oct 2005 20:10:45 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IOO00L1PNWG5V@mailout1.samsung.com> for 6lowpan@ietf.org; Fri, 21 Oct 2005 08:57:52 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IOO000JRNWGPE@mmp2.samsung.com> for 6lowpan@ietf.org; Fri, 21 Oct 2005 08:57:52 +0900 (KST) Date: Fri, 21 Oct 2005 08:59:10 +0900 From: Soohong Daniel Park To: 6lowpan@ietf.org Message-id: <022101c5d5d2$43ad0c70$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: multipart/mixed; boundary="Boundary_(ID_qkNGxELNdYYsY6Dkb4SLSQ)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [6lowpan] Fw: I-D ACTION:draft-montenegro-6lowpan-dymo-low-routing-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_qkNGxELNdYYsY6Dkb4SLSQ) Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT fyi.. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing > Author(s) : K. Kim, et al. > Filename : draft-montenegro-6lowpan-dymo-low-routing-00.txt > Pages : 20 > Date : 2005-10-20 > > This document specifies how to use the Dynamic MANET On-demand > Routing Protocol over IEEE802.15.4 networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-montenegro-6lowpan-dymo-low-routing-00.txt Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. --Boundary_(ID_qkNGxELNdYYsY6Dkb4SLSQ) Content-type: application/octet-stream; name=ATT00538.dat Content-disposition: attachment; filename=ATT00538.dat Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-20102255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-6lowpan-dymo-low-routing-00.txt --Boundary_(ID_qkNGxELNdYYsY6Dkb4SLSQ) Content-type: text/plain; name=draft-montenegro-6lowpan-dymo-low-routing-00.txt Content-disposition: attachment; filename=draft-montenegro-6lowpan-dymo-low-routing-00.txt Content-Transfer-Encoding: 7BIT Content-Type: text/plain Content-ID: <2005-10-20102255.I-D@ietf.org> --Boundary_(ID_qkNGxELNdYYsY6Dkb4SLSQ) 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 --Boundary_(ID_qkNGxELNdYYsY6Dkb4SLSQ)-- From 6lowpan-bounces@ietf.org Fri Oct 21 16:58:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3yK-0004NZ-EZ; Fri, 21 Oct 2005 16:58:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3yJ-0004N8-Cc for 6lowpan@megatron.ietf.org; Fri, 21 Oct 2005 16:58:39 -0400 Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05313 for <6lowpan@lists.ietf.org>; Fri, 21 Oct 2005 16:58:27 -0400 (EDT) Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.12.10/8.12.10) with ESMTP id j9LKw7s6015532 for <6lowpan@lists.ietf.org>; Fri, 21 Oct 2005 14:58:07 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain Date: Fri, 21 Oct 2005 14:58:19 -0600 Message-Id: <1129928299.11168.216.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [6lowpan] agenda for 6lowpan 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Folks, We now have 2 hours!!! yeah! on Monday 1 to 3. Please send me your agenda items. Right now I know that we need to cover the 2 drafts. I would like to present 20 minutes on the current zigbee work and compatibility/coexistence issues. What else do we want to cover? geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Oct 22 01:20:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETBoQ-0003pV-QQ; Sat, 22 Oct 2005 01:20:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETBoJ-0003pB-Aa for 6lowpan@megatron.ietf.org; Sat, 22 Oct 2005 01:20:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18685 for <6lowpan@ietf.org>; Sat, 22 Oct 2005 01:20:38 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETC0H-00088g-Ve for 6lowpan@ietf.org; Sat, 22 Oct 2005 01:33:32 -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 <0IOQ00ALGXHWNH@mailout2.samsung.com> for 6lowpan@ietf.org; Sat, 22 Oct 2005 14:20:21 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IOQ004AYXHWE0@mmp2.samsung.com> for 6lowpan@ietf.org; Sat, 22 Oct 2005 14:20:20 +0900 (KST) Date: Sat, 22 Oct 2005 14:21:40 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] agenda for 6lowpan To: Geoff Mulligan , 6lowpan <6lowpan@ietf.org> Message-id: <01cf01c5d6c8$7bea40c0$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1129928299.11168.216.camel@localhost.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org once again... Issue 1: On-Demand adhoc routing protocol for 6lowpan (LOAD vs. AODV / DYMO-low vs. DYMO) References: http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-load-adhoc-routing-01.txt http://www.ietf.org/internet-drafts/draft-montenegro-6lowpan-dymo-low-routing-00.txt Presentors: Kihyung Kim and Soohong Daniel Park Length: 20 mins. Issue 2: 6lowpan Evaluation results References: presentation materials (associated papers, graphs...) http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-load-adhoc-routing-01.txt http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-hilow-hierarchical-routing-00.txt http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-sslp-00.txt http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-interoperability-01.txt Presentors: Kihyung Kim and Soohong Daniel Park Length: 15 or 20 mins (depending on agenda items) Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Geoff Mulligan" To: "6lowpan" <6lowpan@ietf.org> Sent: Saturday, October 22, 2005 5:58 AM Subject: [6lowpan] agenda for 6lowpan > Folks, > We now have 2 hours!!! yeah! on Monday 1 to 3. > > Please send me your agenda items. > > Right now I know that we need to cover the 2 drafts. I would like to > present 20 minutes on the current zigbee work and > compatibility/coexistence issues. > > What else do we want to cover ? > > geoff > > > > _______________________________________________ > 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 Sun Oct 23 03:57:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETajD-0004tb-Ho; Sun, 23 Oct 2005 03:57:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETajB-0004tV-T3 for 6lowpan@megatron.ietf.org; Sun, 23 Oct 2005 03:57:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19707 for <6lowpan@ietf.org>; Sun, 23 Oct 2005 03:57:00 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETavd-0004bU-GX for 6lowpan@ietf.org; Sun, 23 Oct 2005 04:10:07 -0400 Received: from jurassic.eng.sun.com ([129.146.106.105]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9N7v13F029205; Sun, 23 Oct 2005 01:57:01 -0600 (MDT) Received: from eng.sun.com (vpn-129-150-24-51.SFBay.Sun.COM [129.150.24.51]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9N7v0P8993202; Sun, 23 Oct 2005 00:57:00 -0700 (PDT) Message-ID: <435B424C.3080909@eng.sun.com> Date: Sun, 23 Oct 2005 00:57:00 -0700 From: Samita Chakrabarti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: itijibox-6lowpan@yahoo.com Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) References: <20051019221610.23464.qmail@web81909.mail.mud.yahoo.com> In-Reply-To: <20051019221610.23464.qmail@web81909.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I am not quite clear on the need of version for lowpan layer ; how are other ipv6 over protocol foo defined in this respect? Also, datagram tag size increament to 16bits does not seem to be a clear need to me. I am not sure if there is a need for fragmentation tax. Today folks run IP datagram over 10Gb/s ethernet, but IP identification fileld size is not changing. We need to be very sure that the datagram tag rollover is an issue before increasing bit numbers in the lowpan header. BTW, currently protocol field is 11 bits - we should reduce that number to 8 bits. We may want to use 1 bit (8bit +1) in highest order bit, to indicate private or standard protocol-type if folks think that might be useful. IMHO, we need more discussion and input from folks before changing the tagsize to 16bits. My recommendation would be to start with the current size and change later if needed based on implementations input , ie, when we have more experience with IPv6 over lowpan. Thanks, -Samita gabriel montenegro wrote: >--- Vipul Gupta wrote: > > > >>15 bits should be ok for the data rates we are dealing with >>and still support reassembly timers in the order of 1min. >>However, if we need an extra bit, one could possibly take >>that from the prot_type and the datagram_offset fields >>(for the latter one could use a mechanism similar to what's >>used in IPv4 and IPv6 and specify the offset in 2 byte >>units -- IPv4 and IPv6 use 8-byte units). >> >>It might also make sense to reserve a portion of the prot_type >>space for private use among consenting parties. Has there >>been any discussion on including a version field in the >>LowPAN header for future extensions (it could be fairly >>short 2-4 bits)? >> >> > >If one were to do both (add a fixed version field, say 2 bits, and >add one bit to the datagram tag), we'd need 3 bits in header formats >2 and 3, where both the version and the enlarged datagram tag appear. > >In the header formats 1 and 2, these 3 bits could come from the protocol type >(reducing to 8 from 11 bits, which is still enough, I think), and in >header format 3 they'd come from the datagram tag (meaning we'd specify >offsets in 8 octet units). Here's what formats might look like: > >Format 1: > 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LF|Ver| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Format 2: > 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LF|Ver| prot_type |M| datagram_size | datagram_tag... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |...datagram_tag| Payload (or Mesh Delivery Hdr)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Format 3: > 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LF|Ver|datagram_offset|M| datagram_size | datagram_tag... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |...datagram_tag| Payload (or Mesh Delivery Hdr)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >protocol type and datagram offset now at 8bits >datagram tag now at 16 bits > >Comments? > >-gabriel > > > > > > > > > >_______________________________________________ >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 Sun Oct 23 16:40:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETme9-0007OL-EN; Sun, 23 Oct 2005 16:40:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETme5-0007MQ-Si for 6lowpan@megatron.ietf.org; Sun, 23 Oct 2005 16:40:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24088 for <6lowpan@ietf.org>; Sun, 23 Oct 2005 16:40:33 -0400 (EDT) Received: from web81909.mail.mud.yahoo.com ([68.142.207.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ETmqi-0006El-2W for 6lowpan@ietf.org; Sun, 23 Oct 2005 16:53:48 -0400 Received: (qmail 14776 invoked by uid 60001); 23 Oct 2005 20:40:34 -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:Content-Transfer-Encoding; b=bc4A8/cGdWlh6Xh7+NcRWecqmU/T2Cr8i2yZTPaCUoPQdPiv/TnnBMQvbW9S5Yt/VhYP8viYVBfFBnyv+1UJb4TjtvqsuhPFI/Pyv3Igl5fXMrpzibCGGG8K8GDDDm0w1fxM0+WAH/KdOieIAmi0gbCmTKbZjosUwDUH6iCfJ28= ; Message-ID: <20051023204034.14774.qmail@web81909.mail.mud.yahoo.com> Received: from [24.16.92.216] by web81909.mail.mud.yahoo.com via HTTP; Sun, 23 Oct 2005 13:40:33 PDT Date: Sun, 23 Oct 2005 13:40:33 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) To: Samita Chakrabarti In-Reply-To: <435B424C.3080909@eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Samita, --- Samita Chakrabarti wrote: > I am not quite clear on the need of version for lowpan layer ; how are other > ipv6 over protocol foo defined in this respect? Good question, you might want to look over those specs, but I don't recall ever seeing a version number. If a future rev of 15.4 (e.g., 15.4-on-steroids) ever makes it obvious that a new adaptation layer is needed, then instead of handling this via version numbers on the current spec, one could simply issue another document specifically for 'IP-over-15.4-on-steroids". Achieves the same thing without wasting bits on version numbers. > Also, datagram tag size increament to 16bits does not seem to be a > clear need to me. I am not sure if there is a need for fragmentation > tax. Today folks run IP datagram over 10Gb/s ethernet, but IP > identification > fileld size is not changing. Good point, I don't see a need for this to grow much either. > We need to be very sure that the datagram tag > rollover is an issue before increasing bit numbers in the lowpan header. This is the main issue, yes, let's not get too aggressive on over-engineering in advance. > BTW, currently protocol field is 11 bits - we should reduce that number > to 8 bits. Ok, let's do this. > We may want to use 1 bit (8bit +1) in highest order bit, to > indicate > private or standard protocol-type if folks think that might be useful. I don't think this is useful. Private or proprietary encapsulations are the majority (and will continue to be so according to some folks) and these precisely couldn't care less about interoperability with anybody cuz they have their own isolated network. This bit would remain unused. As for interoperability with zigbee, I'm thinking that the fact that most of these applications will (hopefully) use some link-layer (15.4) security, means that as long as you don't use the same keys for both lowpan and zigbee, you won't even get a chance of being confused. This multiplexing will be achieved by traffic separation due to different keying. So I'm thinking that there isn't much to do here either. > IMHO, we need more discussion and input from folks before changing > the tagsize to 16bits. My recommendation would be to start with the current > size and change later if needed based on implementations input , ie, when > we have more experience with IPv6 over lowpan. Looking at the previous proposed formats I sent on this thread, how about using the 2 bits from the "Ver" field and assigning them to the tag size (to grow it from 8 to 10 bits)? This is what I propose: prot_type: 8 bits datagram_size: 11 bits datagram_tag: 10 bits datagram_offset: 8 bits (offsets expressed in increments of 8 octets) Format 1 (unfragmented): 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Format 2 (first fragment): 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| prot_type |M| datagram_size | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Format 3 (middle or last fragment): 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF|datagram_offset|M| datagram_size | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is what I'll put into the draft before submission, unless I hear strong opposition, ok? -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Oct 23 20:27:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETqBA-0003Ag-MH; Sun, 23 Oct 2005 20:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETqB9-0003Ab-MB for 6lowpan@megatron.ietf.org; Sun, 23 Oct 2005 20:27:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03147 for <6lowpan@ietf.org>; Sun, 23 Oct 2005 20:26:54 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETqNm-0004JX-1U for 6lowpan@ietf.org; Sun, 23 Oct 2005 20:40:12 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9O0R43F020676 for <6lowpan@ietf.org>; Sun, 23 Oct 2005 18:27:04 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IOU000EU993E5@edgemail1.Central.Sun.COM> for 6lowpan@ietf.org; Sun, 23 Oct 2005 18:27:04 -0600 (MDT) Received: from [192.168.10.4] ([71.131.82.117]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IOU00A5R99110@mail.sun.net> for 6lowpan@ietf.org; Sun, 23 Oct 2005 18:27:02 -0600 (MDT) Date: Sun, 23 Oct 2005 17:26:57 -0700 From: Vipul Gupta Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) In-reply-to: <20051023204034.14774.qmail@web81909.mail.mud.yahoo.com> To: 6lowpan@ietf.org Message-id: <4cc207196fc03aa1c6e8c1ce16df24e1@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20051023204034.14774.qmail@web81909.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org If we assume that the LowPAN design this group comes up with will only need to be revised when a new lower layer is designed, then yes there is no need for version numbers. However, if there's even a small chance that, based on deployment experience, we may revise the LowPAN header format while still wanting to run it on top of the same lower layer then I don't see how the recipient would figure out how to interpret the received packet without a version number. From what I can tell, there is no place in the 802.15.4 header to describe the higher protocol type (ethernet, in contrast, does have such a field). Perhaps the following example will make things clearer. Because SSL includes a version number, the IETF was able to define TLS and now TLS 1.1 without requiring a new underlying protocol (all versions of SSL and TLS run atop TCP). It seems like a prudent tradeoff to me to spend 2 bits for the ability to later revise LowPAN (based on deployment experience) without requiring a new lower layer. As for the tag size, I think 7 bits is still too low (based on the previously posted analysis). If the general consensus is to bump it to 10 and wait for deployment experience before changing it to a higher value, that's fine (at current data rates, 10 bits would allow for a reassembly timeout of around 8 seconds which might be ok). In terms of saving bits, supporting short addresses provides the biggest bang for the buck -- instead of carrying two 8-byte addresses across each hop (for a multihop pkt), carrying two 2-byte addresses saves 96 bits. Compared to this, the extra few bits spent on the version or the tag are minuscule. vipul On Oct 23, 2005, at 1:40 PM, gabriel montenegro wrote: > Hi Samita, > > --- Samita Chakrabarti wrote: >> I am not quite clear on the need of version for lowpan layer ; how >> are other >> ipv6 over protocol foo defined in this respect? > > Good question, you might want to look over those specs, but I don't > recall > ever seeing a version number. If a future rev of 15.4 (e.g., > 15.4-on-steroids) ever makes it obvious that a new adaptation layer > is needed, then instead of handling this via version numbers on the > current spec, one could simply issue another document specifically > for 'IP-over-15.4-on-steroids". Achieves the same thing without wasting > bits on version numbers. > >> Also, datagram tag size increament to 16bits does not seem to be a >> clear need to me. I am not sure if there is a need for >> fragmentation >> tax. Today folks run IP datagram over 10Gb/s ethernet, but IP >> identification >> fileld size is not changing. > > Good point, I don't see a need for this to grow much either. > >> We need to be very sure that the datagram tag >> rollover is an issue before increasing bit numbers in the lowpan >> header. > > This is the main issue, yes, let's not get too aggressive on > over-engineering > in advance. > >> BTW, currently protocol field is 11 bits - we should reduce that >> number >> to 8 bits. > > Ok, let's do this. > >> We may want to use 1 bit (8bit +1) in highest order bit, to >> indicate >> private or standard protocol-type if folks think that might be >> useful. > > I don't think this is useful. Private or proprietary encapsulations > are the > majority (and will continue to be so according to some folks) and > these precisely > couldn't care less about interoperability with anybody cuz they have > their own > isolated network. This bit would remain unused. > > As for interoperability with zigbee, I'm thinking that the fact that > most of these > applications will (hopefully) use some link-layer (15.4) security, > means that as long > as you don't use the same keys for both lowpan and zigbee, you won't > even get a chance > of being confused. This multiplexing will be achieved by traffic > separation due to > different > keying. So I'm thinking that there isn't much to do here either. > >> IMHO, we need more discussion and input from folks before changing >> the tagsize to 16bits. My recommendation would be to start with the >> current >> size and change later if needed based on implementations input , ie, >> when >> we have more experience with IPv6 over lowpan. > > Looking at the previous proposed formats I sent on this thread, > how about using the 2 bits from the "Ver" field and assigning them to > the tag size (to grow it from 8 to 10 bits)? This is what I propose: > > prot_type: 8 bits > datagram_size: 11 bits > datagram_tag: 10 bits > datagram_offset: 8 bits (offsets expressed in increments of 8 octets) > > Format 1 (unfragmented): > 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LF| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Format 2 (first fragment): > 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LF| prot_type |M| datagram_size | datagram_tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload (or Mesh Delivery Hdr)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Format 3 (middle or last fragment): > 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LF|datagram_offset|M| datagram_size | datagram_tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload (or Mesh Delivery Hdr)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This is what I'll put into the draft before submission, unless I hear > strong opposition, ok? > > -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 24 03:34:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETwqy-00071Q-JE; Mon, 24 Oct 2005 03:34:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETwqw-00071G-KV for 6lowpan@megatron.ietf.org; Mon, 24 Oct 2005 03:34:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22163 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 03:34:26 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETx3Z-00009S-DY for 6lowpan@ietf.org; Mon, 24 Oct 2005 03:47:48 -0400 Received: from jurassic.eng.sun.com ([129.146.104.45]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9O7YX4u006700 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 00:34:33 -0700 (PDT) Received: from eng.sun.com (vpn-129-150-24-78.SFBay.Sun.COM [129.150.24.78]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9O7YWNX337128; Mon, 24 Oct 2005 00:34:33 -0700 (PDT) Message-ID: <435C8E85.9080400@eng.sun.com> Date: Mon, 24 Oct 2005 00:34:29 -0700 From: Samita Chakrabarti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vipul Gupta Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) References: <20051023204034.14774.qmail@web81909.mail.mud.yahoo.com> <4cc207196fc03aa1c6e8c1ce16df24e1@sun.com> In-Reply-To: <4cc207196fc03aa1c6e8c1ce16df24e1@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > > > In terms of saving bits, supporting short addresses > provides the biggest bang for the buck -- instead > of carrying two 8-byte addresses across each hop > (for a multihop pkt), carrying two 2-byte addresses > saves 96 bits. Compared to this, the extra few > bits spent on the version or the tag are minuscule. While supporting 16bit short addresses are a great idea for saving bits in case of multihopping, the draft will need to consider the 64bit addresses as well. There will be some devices that will use 64bit link-layer addresses and stlll want to do multihopping and fragmentation. I believe ZigBee devices also support 64bit addresses. -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 24 04:20:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxVH-0001ik-8k; Mon, 24 Oct 2005 04:16:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxVF-0001ie-9G for 6lowpan@megatron.ietf.org; Mon, 24 Oct 2005 04:16:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24218 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 04:16:07 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETxhu-0001f9-RT for 6lowpan@ietf.org; Mon, 24 Oct 2005 04:29:30 -0400 Received: from jurassic.eng.sun.com ([129.146.68.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9O8GE3F002047; Mon, 24 Oct 2005 02:16:14 -0600 (MDT) Received: from eng.sun.com (vpn-129-150-24-78.SFBay.Sun.COM [129.150.24.78]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9O8GDfq384868; Mon, 24 Oct 2005 01:16:14 -0700 (PDT) Message-ID: <435C984A.2010808@eng.sun.com> Date: Mon, 24 Oct 2005 01:16:10 -0700 From: Samita Chakrabarti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: itijibox-6lowpan@yahoo.com Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) References: <20051023204034.14774.qmail@web81909.mail.mud.yahoo.com> In-Reply-To: <20051023204034.14774.qmail@web81909.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > This is what I propose: > >prot_type: 8 bits >datagram_size: 11 bits >datagram_tag: 10 bits >datagram_offset: 8 bits (offsets expressed in increments of 8 octets) > > > Seems OK to me. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 24 04:25:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxdd-00038u-6w; Mon, 24 Oct 2005 04:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxdb-00037h-Fc for 6lowpan@megatron.ietf.org; Mon, 24 Oct 2005 04:24:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24522 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 04:24:45 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETxqG-0001vT-QN for 6lowpan@ietf.org; Mon, 24 Oct 2005 04:38:08 -0400 Received: from jurassic.eng.sun.com ([129.146.108.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9O8OsdK023035; Mon, 24 Oct 2005 01:24:54 -0700 (PDT) Received: from eng.sun.com (vpn-129-150-24-78.SFBay.Sun.COM [129.150.24.78]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9O8OrbC396875; Mon, 24 Oct 2005 01:24:53 -0700 (PDT) Message-ID: <435C9A52.20900@eng.sun.com> Date: Mon, 24 Oct 2005 01:24:50 -0700 From: Samita Chakrabarti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoff Mulligan Subject: Re: [6lowpan] agenda for 6lowpan References: <1129928299.11168.216.camel@localhost.localdomain> In-Reply-To: <1129928299.11168.216.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: 6lowpan <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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Geoff Mulligan wrote: >Folks, > We now have 2 hours!!! yeah! on Monday 1 to 3. > >Please send me your agenda items. > >Right now I know that we need to cover the 2 drafts. I would like to >present 20 minutes on the current zigbee work and >compatibility/coexistence issues. > >What else do we want to cover? > > geoff > > > draft-chakrabarti-lowpan-nd-00.txt by S. Chakrabarti, E. Nordmark If possible, like to get a 10-15 min slot. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 24 11:22:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU49i-00024l-Pw; Mon, 24 Oct 2005 11:22:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU49h-00024g-Kh for 6lowpan@megatron.ietf.org; Mon, 24 Oct 2005 11:22:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15175 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 11:22:20 -0400 (EDT) Received: from fmr19.intel.com ([134.134.136.18] helo=orsfmr004.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU4MQ-0007H1-HW for 6lowpan@ietf.org; Mon, 24 Oct 2005 11:35:46 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9OFMHG4010668 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 15:22:17 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9OFMHOC013581 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 15:22:17 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005102408221700545 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 08:22:17 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 08:21:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5D8AE.AB9BC998" Date: Mon, 24 Oct 2005 08:21:56 -0700 Message-ID: <9D602ABCE51B0B488BF857A4787939B50629FD03@orsmsx410> X-MS-Has-Attach: yes Thread-Topic: Revision of 6lowpan draft: draft-ietf-6lowpan-problem-01.txt Thread-Index: AcXYleGPecsVxKVbRe2f69GvwiWfiAAF37awAABGEoA= From: "Kushalnagar, Nandakishore" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 24 Oct 2005 15:21:56.0992 (UTC) FILETIME=[ABE7A000:01C5D8AE] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab Subject: [6lowpan] FW: Revision of 6lowpan draft: draft-ietf-6lowpan-problem-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D8AE.AB9BC998 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fyi..=20 I have made updates to the security section that was talked about in the mailing list Regards, Nandu -----Original Message----- From: Kushalnagar, Nandakishore=20 Sent: Monday, October 24, 2005 8:15 AM To: internet-drafts@ietf.org; Geoff Mulligan; Carsten Bormann Subject: Revision of 6lowpan draft: draft-ietf-6lowpan-problem-01.txt Please find the revised draft: draft-ietf-6lowpan-problem-01.txt Thanks, Nandu ------_=_NextPart_001_01C5D8AE.AB9BC998 Content-Type: text/plain; name="draft-ietf-6lowpan-problem-01.txt" Content-Description: draft-ietf-6lowpan-problem-01.txt Content-Disposition: attachment; filename="draft-ietf-6lowpan-problem-01.txt" Content-Transfer-Encoding: base64 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBOLiBLdXNoYWxuYWdhcgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEludGVsIENvcnAKRXhwaXJlczogQXByaWwgMjcsIDIw MDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBNb250ZW5lZ3JvCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY3Jvc29mdCBD b3Jwb3JhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE9jdG9iZXIgMjQsIDIwMDUKCgogICAgICA2TG9XUEFOOiBPdmVydmlldywgQXNz dW1wdGlvbnMsIFByb2JsZW0gU3RhdGVtZW50IGFuZCBHb2FscwogICAgICAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi02bG93cGFuLXByb2JsZW0tMDAudHh0CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgog ICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2Vu dHMgdGhhdCBhbnkKICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3 aGljaCBoZSBvciBzaGUgaXMgYXdhcmUKICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2Vk LCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91 cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt RHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFp ZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERp cmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRv dy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBBcHJpbCAyNywg MjAwNi4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNv Y2lldHkgKDIwMDUpLgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBh c3N1bXB0aW9ucywgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIGdvYWxzCiAgIGZvciB0cmFuc21pdHRp bmcgSVAgb3ZlciBJRUVFIDgwMi4xNS40IG5ldHdvcmtzLiAgVGhlIHNldCBvZiBnb2FscwogICBl bnVtZXJhdGVkIGluIHRoaXMgZG9jdW1lbnQgZm9ybSBhbiBpbml0aWFsIHNldCBvbmx5LiAgQWRk aXRpb25hbAogICBnb2FscyBtYXkgYmUgZm91bmQgbmVjZXNzYXJ5IG92ZXIgdGltZSBhbmQgbWF5 IGJlIGFkZGVkIHRvIHRoaXMKICAgZG9jdW1lbnQuCgoKCgoKS3VzaGFsbmFnYXIgJiBNb250ZW5l Z3JvICBFeHBpcmVzIEFwcmlsIDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICA2bG93cGFuIFByb2JsZW1zIGFuZCBHb2FscyAgICAgICAgICAg T2N0b2JlciAyMDA1CgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAgIDEu MS4gIFJlcXVpcmVtZW50cyBub3RhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDMKICAgMi4gIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgIDMuICBBc3N1bXB0aW9ucyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICA0LiAgUHJvYmxlbXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUK ICAgICA0LjEuICBJUCBDb25uZWN0aXZpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA1CiAgICAgNC4yLiAgVG9wb2xvZ2llcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDQuMy4gIExpbWl0ZWQgUGFja2V0 IFNpemUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgICA0LjQu ICBMaW1pdGVkIGNvbmZpZ3VyYXRpb24gYW5kIG1hbmFnZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA2CiAgICAgNC41LiAgU2VydmljZSBkaXNjb3ZlcnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgIDQuNi4gIFNlY3VyaXR5IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgNS4gIEdvYWxzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAg IDYuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgOQogICA3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgOC4gIEFja25vd2xlZGdlbWVudHMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgIDkuICBSZWZl cmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOQogICAgIDkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICA5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgIEF1dGhvcnMnIEFkZHJlc3Nl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICBJ bnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpLdXNoYWxuYWdhciAmIE1v bnRlbmVncm8gIEV4cGlyZXMgQXByaWwgMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMl0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgIDZsb3dwYW4gUHJvYmxlbXMgYW5kIEdvYWxzICAgICAg ICAgICBPY3RvYmVyIDIwMDUKCgoxLiAgSW50cm9kdWN0aW9uCgogICBMb3ctcG93ZXIgd2lyZWxl c3MgcGVyc29uYWwgYXJlYSBuZXR3b3JrcyAoTG9XUEFOcykgY29tcHJpc2UgZGV2aWNlcwogICB0 aGF0IGNvbmZvcm0gdG8gdGhlIElFRUUgODAyLjE1LjQtMjAwMyBzdGFuZGFyZCBieSB0aGUgSUVF RQogICBbaWVlZTgwMi4xNS40XS4gIFRoZSBJRUVFIDgwMi4xNS40IGRldmljZXMgYXJlIGNoYXJh Y3Rlcml6ZWQgYnkgc2hvcnQKICAgcmFuZ2UsIGxvdyBiaXQgcmF0ZSwgbG93IHBvd2VyIGFuZCBs b3cgY29zdC4KCiAgIFRoaXMgZG9jdW1lbnQgZ2l2ZXMgYW4gb3ZlcnZpZXcgb2YgTG9XUEFOcyBh bmQgZGVzY3JpYmVzIGhvdyB0aGV5CiAgIGJlbmVmaXQgZnJvbSBJUCBhbmQgSVB2NiBuZXR3b3Jr aW5nLiAgSXQgZGVzY3JpYmVzIHRoZSByZXF1aXJlbWVudHMKICAgb2YgTG9XUEFOcyB3aXRoIHJl Z2FyZHMgdG8gSVAgbGF5ZXIgYW5kIGFib3ZlLiAgSXQgc3BlbGxzIG91dCB0aGUKICAgdW5kZXJs eWluZyBhc3N1bXB0aW9ucyBvZiBJUCBmb3IgTG9XUEFOcy4gIEZpbmFsbHksIGl0IGRlc2NyaWJl cwogICBwcm9ibGVtcyBhc3NvY2lhdGVkIHdpdGggZW5hYmxpbmcgSVAgY29tbXVuaWNhdGlvbiBi ZXR3ZWVuIGRldmljZXMgaW4KICAgTG9XUEFOLCBhbmQgZGVmaW5lcyBnb2FscyB0byBhZGRyZXNz IHRoZXNlIGluIGEgcHJpb3JpdGl6ZWQgbWFubmVyLgogICBBZG1pdHRlZGx5LCBub3QgYWxsIGl0 ZW1zIG9uIHRoaXMgbGlzdCBhcmUgbmVjZXNzYXJpbHkgYXBwcm9wcmlhdGUKICAgdGFza3MgZm9y IHRoZSBJRVRGLiAgTmV2ZXJ0aGVsZXNzLCB0aGV5IGFyZSBkb2N1bWVudGVkIGhlcmUgdG8gZ2l2 ZSBhCiAgIGdlbmVyYWwgb3ZlcnZpZXcgb2YgdGhlIGxhcmdlciBwcm9ibGVtLiAgVGhpcyBpcyB1 c2VmdWwgYm90aCB0bwogICBzdHJ1Y3R1cmUgd29yayB3aXRoaW4gdGhlIElFVEYgYXMgd2VsbCBh cyB0byB1bmRlcnN0YW5kIGJldHRlciBob3cgdG8KICAgY29vcmRpbmF0ZSB3aXRoIGV4dGVybmFs IG9yZ2FuaXphdGlvbnMuCgoxLjEuICBSZXF1aXJlbWVudHMgbm90YXRpb24KCiAgIFRoZSBrZXkg d29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9U IiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAi T1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRl c2NyaWJlZCBpbiBbUkZDMjExOV0uCgoKMi4gIE92ZXJ2aWV3CgogICBBIExvV1BBTiBpcyBhIHNp bXBsZSBsb3cgY29zdCBjb21tdW5pY2F0aW9uIG5ldHdvcmsgdGhhdCBhbGxvd3MKICAgd2lyZWxl c3MgY29ubmVjdGl2aXR5IGluIGFwcGxpY2F0aW9ucyB3aXRoIGxpbWl0ZWQgcG93ZXIgYW5kIHJl bGF4ZWQKICAgdGhyb3VnaHB1dCByZXF1aXJlbWVudHMuICBBIExvV1BBTiB0eXBpY2FsbHkgaW5j bHVkZXMgZGV2aWNlcyB0aGF0CiAgIHdvcmsgdG9nZXRoZXIgdG8gY29ubmVjdCB0aGUgcGh5c2lj YWwgZW52aXJvbm1lbnQgdG8gcmVhbC13b3JsZAogICBhcHBsaWNhdGlvbnMsIGUuZy4sIHdpcmVs ZXNzIHNlbnNvcnMuICBMb1dQQU5zIGNvbmZvcm0gdG8gdGhlIElFRUUKICAgODAyLjE1LjQtMjAw MyBzdGFuZGFyZC4gW2llZWU4MDIuMTUuNF0uCgogICBTb21lIG9mIHRoZSBjaGFyYWN0ZXJpc3Rp Y3Mgb2YgTG9XUEFOcyBhcmU6CgogICAxLiAgU21hbGwgcGFja2V0IHNpemUuICBHaXZlbiB0aGF0 IHRoZSBtYXhpbXVtIHBoeXNpY2FsIGxheWVyIHBhY2tldAogICAgICAgaXMgMTI3IGJ5dGVzLCB0 aGUgcmVzdWx0aW5nIG1heGltdW0gZnJhbWUgc2l6ZSBhdCB0aGUgbWVkaWEKICAgICAgIGFjY2Vz cyBjb250cm9sIGxheWVyIGlzIDEwMiBvY3RldHMuICBMaW5rLWxheWVyIHNlY3VyaXR5IGltcG9z ZXMKICAgICAgIGZ1cnRoZXIgb3ZlcmhlYWQsIHdoaWNoIGluIHRoZSBtYXhpbXVtIGNhc2UgKDIx IG9jdGV0cyBvZgogICAgICAgb3ZlcmhlYWQgaW4gdGhlIEFFUy1DQ00tMTI4IGNhc2UsIHZlcnN1 cyA5IGFuZCAxMyBmb3IgQUVTLUNDTS0zMgogICAgICAgYW5kIEFFUy1DQ00tNjQsIHJlc3BlY3Rp dmVseSkgbGVhdmVzIDgxIG9jdGV0cyBmb3IgZGF0YSBwYWNrZXRzLgoKICAgMi4gIFN1cHBvcnQg Zm9yIGJvdGggMTYtYml0IHNob3J0IG9yIElFRUUgNjQtYml0IGV4dGVuZGVkIG1lZGlhCiAgICAg ICBhY2Nlc3MgY29udHJvbCBhZGRyZXNzZXMuCgoKCgoKS3VzaGFsbmFnYXIgJiBNb250ZW5lZ3Jv ICBFeHBpcmVzIEFwcmlsIDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICA2bG93cGFuIFByb2JsZW1zIGFuZCBHb2FscyAgICAgICAgICAgT2N0 b2JlciAyMDA1CgoKICAgMy4gIExvdyBiYW5kd2lkdGguICBEYXRhIHJhdGVzIG9mIDI1MCBrYnBz LCA0MCBrYnBzIGFuZCAyMCBrYnBzIGZvcgogICAgICAgZWFjaCBvZiB0aGUgY3VycmVudGx5IGRl ZmluZWQgcGh5c2ljYWwgbGF5ZXJzICgyLjQgR0h6LCA5MTUgTUh6CiAgICAgICBhbmQgODY4IE1I eiwgcmVzcGVjdGl2ZWx5KS4KCiAgIDQuICBUb3BvbG9naWVzIGluY2x1ZGUgc3RhciBhbmQgbWVz aCBvcGVyYXRpb24uCgogICA1LiAgTG93IHBvd2VyLCB0eXBpY2FsbHkgYmF0dGVyeSBvcGVyYXRl ZC4KCiAgIDYuICBSZWxhdGl2ZWx5IGxvdyBjb3N0LCB0eXBpY2FsbHkgYXNzb2NpYXRlZCB3aXRo IHNlbnNvcnMsIHN3aXRjaGVzLAogICAgICAgZXRjLiAgVGhlc2UgZHJpdmUgc29tZSBvZiB0aGUg b3RoZXIgY2hhcmFjdGVyaXN0aWNzIHN1Y2ggYXMgbG93CiAgICAgICBwcm9jZXNzaW5nLCBsb3cg bWVtb3J5LCBldGMuICBOdW1lcmljYWwgdmFsdWVzIGZvciAibG93IiBoYXZlIG5vdAogICAgICAg YmVlbiBleHBsaWNpdGx5IG1lbnRpb25lZCBoZXJlIGFzIGhpc3RvcmljYWxseSB0aGUgY29zdHMg dGVuZCB0bwogICAgICAgY2hhbmdlIG92ZXIgdGltZS4KCiAgIDcuICBMYXJnZSBudW1iZXIgb2Yg ZGV2aWNlcyBleHBlY3RlZCB0byBiZSBkZXBsb3llZCBkdXJpbmcgdGhlIGxpZmUtCiAgICAgICB0 aW1lIG9mIHRoZSB0ZWNobm9sb2d5LiAgVGhpcyBudW1iZXIgaXMgZXhwZWN0ZWQgdG8gZHdhcmYg dGhlCiAgICAgICBudW1iZXIgb2YgZGVwbG95ZWQgcGVyc29uYWwgY29tcHV0ZXJzLCBmb3IgZXhh bXBsZS4KCiAgIDguICBMb2NhdGlvbiBvZiB0aGUgZGV2aWNlcyBhcmUgdHlwaWNhbGx5IG5vdCBw cmVkZWZpbmVkLCB0aHVzIHRoZXNlCiAgICAgICBkZXZpY2VzIGFyZSBkZXBsb3llZCBpbiBhbiBh ZGhvYyBmYXNoaW9uLiAgRnVydGhlcm1vcmUsIHNvbWV0aW1lcwogICAgICAgdGhlIGxvY2F0aW9u IG9mIHRoZXNlIGRldmljZXMgbWF5IG5vdCBiZSBlYXNpbHkgYWNjZXNzaWJsZS4KCiAgIDkuICBE ZXZpY2VzIHdpdGhpbiBMb1dQQU5zIGhhdmUgYSBoaWdoZXIgcG9zc2liaWxpdHkgb2YgYmVpbmcK ICAgICAgIHVucmVsaWFibGUgZHVlIHRvIHZhcmlldHkgb2YgcmVhc29uczogdW5jZXJ0YWluIHJh ZGlvCiAgICAgICBjb25uZWN0aXZpdHksIGJhdHRlcnkgZHJhaW4sIGRldmljZSBsb2NrdXBzLCBw aHlzaWNhbCB0YW1wZXJpbmcsCiAgICAgICBldGMuCgogICBUaGUgZm9sbG93aW5nIHNlY3Rpb25z IHRha2UgaW50byBhY2NvdW50IHRoZXNlIGNoYXJhY3RlcmlzdGljcyBpbgogICBkZXNjcmliaW5n IHRoZSBhc3N1bXB0aW9ucywgcHJvYmxlbXMgc3RhdGVtZW50IGFuZCBnb2FscyBmb3IgTG9XUEFO cy4KCgozLiAgQXNzdW1wdGlvbnMKCiAgIEdpdmVuIHRoZSBzbWFsbCBwYWNrZXQgc2l6ZSBvZiBM b1dQQU5zLCB0aGlzIGRvY3VtZW50IHByZXN1bWVzCiAgIGFwcGxpY2F0aW9ucyB0eXBpY2FsbHkg c2VuZCBzbWFsbCBhbW91bnRzIG9mIGRhdGEuICBIb3dldmVyLCB0aGUKICAgcHJvdG9jb2xzIHRo ZW1zZWx2ZXMgZG8gbm90IHJlc3RyaWN0IGJ1bGsgZGF0YSB0cmFuc2ZlcnMuCgogICBMb1dQQU5z IGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBiYXNlZCBvbiBJRUVFIDgwMi4xNS40 LQogICAyMDAzLiAgSXQgaXMgcG9zc2libGUgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBtYXkgdW5k ZXJnbyBjaGFuZ2VzIGluCiAgIHRoZSBmdXR1cmUgYW5kIG1heSBjaGFuZ2Ugc29tZSBvZiB0aGUg cmVxdWlyZW1lbnRzIG1lbnRpb25lZCBhYm92ZS4KCiAgIFNvbWUgb2YgdGhlc2UgYXNzdW1wdGlv bnMgYXJlIGJhc2VkIG9uIHRoZSBsaW1pdGVkIGNhcGFiaWxpdGllcyBvZgogICBkZXZpY2VzIHdp dGhpbiBMb1dQQU5zLiAgQXMgZGV2aWNlcyBiZWNvbWUgbW9yZSBwb3dlcmZ1bCwgYW5kIGNvbnN1 bWUKICAgbGVzcyBwb3dlciwgc29tZSBvZiB0aGUgcmVxdWlyZW1lbnRzIG1lbnRpb25lZCBhYm92 ZSBtYXkgYmUgc29tZXdoYXQKICAgcmVsYXhlZC4KCiAgIE5ldmVydGhlbGVzcywgbm90IGFsbCBk ZXZpY2VzIGluIGEgTG9XUEFOIGFyZSBleHBlY3RlZCB0byBiZQogICBleHRyZW1lbHkgbGltaXRl ZC4gIFRoaXMgaXMgdHJ1ZSBvZiBzby1jYWxsZWQgIlJlZHVjZWQgRnVuY3Rpb24KCgoKS3VzaGFs bmFnYXIgJiBNb250ZW5lZ3JvICBFeHBpcmVzIEFwcmlsIDI3LCAyMDA2ICAgICAgICAgICAgICAg IFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICA2bG93cGFuIFByb2JsZW1zIGFuZCBH b2FscyAgICAgICAgICAgT2N0b2JlciAyMDA1CgoKICAgRGV2aWNlcyIgKFJGRHMpLCBidXQgbm90 IG5lY2Vzc2FyaWx5IG9mICJGdWxsIEZ1bmN0aW9uIERldmljZXMiCiAgIChGRkRzKS4gIFRoZXNl IHdpbGwgYWxzbyBiZSBwcmVzZW50IGFsYmVpdCBpbiBtdWNoIHNtYWxsZXIgbnVtYmVycywKICAg YW5kIHdpbGwgdHlwaWNhbGx5IGhhdmUgbW9yZSByZXNvdXJjZXMgYW5kIGJlIG1haW5zIHBvd2Vy ZWQuCiAgIEFjY29yZGluZ2x5LCBGRkRzIHdpbGwgYWlkIFJGRHMgYnkgcHJvdmlkaW5nIGZ1bmN0 aW9ucyBzdWNoIGFzCiAgIG5ldHdvcmsgY29vcmRpbmF0aW9uLCBwYWNrZXQgZm9yd2FyZGluZywg aW50ZXJmYWNpbmcgd2l0aCBvdGhlciB0eXBlcwogICBvZiBuZXR3b3JrcywgZXRjLgoKICAgSVAg dGVjaG5vbG9neSBpcyBhc3N1bWVkIHRvIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBiZW5lZml0czoK CiAgIDEuICBUaGUgcGVydmFzaXZlIG5hdHVyZSBvZiBJUCBuZXR3b3JrcyBhbGxvd3MgdXNlIG9m IGV4aXN0aW5nCiAgICAgICBpbmZyYXN0cnVjdHVyZS4KICAgMi4gIElQIGJhc2VkIHRlY2hub2xv Z2llcyBhbHJlYWR5IGV4aXN0LCBhcmUgd2VsbCBrbm93biBhbmQgcHJvdmVuIHRvCiAgICAgICBi ZSB3b3JraW5nLgogICAzLiAgQW4gYWRtaXR0ZWRseSBub24tdGVjaG5pY2FsIGJ1dCBpbXBvcnRh bnQgY29uc2lkZXJhdGlvbiBpcyB0aGF0CiAgICAgICBpbnRlbGxlY3R1YWwgcHJvcGVydHkgY29u ZGl0aW9ucyBmb3IgSVAgbmV0d29ya2luZyB0ZWNobm9sb2d5IGFyZQogICAgICAgZWl0aGVyIG1v cmUgZmF2b3JhYmxlIG9yIGF0IGxlYXN0IGJldHRlciB1bmRlcnN0b29kIHRoYW4KICAgICAgIHBy b3ByaWV0YXJ5IGFuZCBuZXdlciBzb2x1dGlvbnMuCgoKNC4gIFByb2JsZW1zCgogICBCYXNlZCBv biB0aGUgY2hhcmFjdGVyaXN0aWNzIGRlZmluZWQgaW4gdGhlIG92ZXJ2aWV3IHNlY3Rpb24sIHRo ZQogICBmb2xsb3dpbmcgc2VjdGlvbnMgZWxhYm9yYXRlIG9uIHRoZSBtYWluIHByb2JsZW1zIHdp dGggSVAgZm9yIExvV1BBTnMKICAgTm90ZSB0aGF0IGEgY29tbW9uIHVuZGVybHlpbmcgZ29hbCBp cyB0byByZWR1Y2UgcGFja2V0IG92ZXJoZWFkLAogICBiYW5kd2lkdGggY29uc3VtcHRpb24sIGFu ZCBwcm9jZXNzaW5nIHJlcXVpcmVtZW50cy4KCjQuMS4gIElQIENvbm5lY3Rpdml0eQoKICAgVGhl IHJlcXVpcmVtZW50IGZvciBJUCBjb25uZWN0aXZpdHkgd2l0aGluIGEgTG9XUEFOIGlzIGRyaXZl biBieSB0aGUKICAgZm9sbG93aW5nOgoKICAgMS4gIFRoZSBtYW55IGRldmljZXMgaW4gYSBMb1dQ QU4gbWFrZSBuZXR3b3JrIGF1dG9jb25maWd1cmF0aW9uIGFuZAogICAgICAgc3RhdGVsZXNzbmVz cyBoaWdobHkgZGVzaXJhYmxlLiAgQW5kIGZvciB0aGlzLCBJUHY2IGhhcyByZWFkeQogICAgICAg c29sdXRpb25zLgogICAyLiAgVGhlIGxhcmdlIG51bWJlciBvZiBkZXZpY2VzIHBvc2VzIHRoZSBu ZWVkIGZvciBhIGxhcmdlIGFkZHJlc3MKICAgICAgIHNwYWNlLCB3ZWxsIG1ldCBieSBJUHY2Lgog ICAzLiAgR2l2ZW4gdGhlIGxpbWl0ZWQgcGFja2V0IHNpemUgb2YgTG9XUEFOcywgdGhlIElQdjYg YWRkcmVzcyBmb3JtYXQKICAgICAgIGFsbG93cyBzdWJzdW1pbmcgb2YgSUVFRSA4MDIuMTUuNCBh ZGRyZXNzZXMgaWYgc28gZGVzaXJlZC4KCiAgIEhvd2V2ZXIsIGdpdmVuIHRoZSBsaW1pdGVkIHBh Y2tldCBzaXplLCBoZWFkZXJzIGZvciBJUHY2IGFuZCBhYm92ZQogICBsYXllcnMgbXVzdCBiZSBj b21wcmVzc2VkIHdoZW5ldmVyIHBvc3NpYmxlLgoKNC4yLiAgVG9wb2xvZ2llcwoKICAgTG9XUEFO cyBtdXN0IHN1cHBvcnQgdmFyaW91cyB0b3BvbG9naWVzIGluY2x1ZGluZyBtZXNoIGFuZCBzdGFy LgoKICAgTWVzaCB0b3BvbG9naWVzIGltcGx5IG11bHRpLWhvcCByb3V0aW5nLiB0byBhIGRlc2ly ZWQgZGVzdGluYXRpb24uCiAgIEluIHRoaXMgY2FzZSwgaW50ZXJtZWRpYXRlIGRldmljZXMgYWN0 IGFzIHBhY2tldCBmb3J3YXJkZXJzIGF0IHRoZQoKCgpLdXNoYWxuYWdhciAmIE1vbnRlbmVncm8g IEV4cGlyZXMgQXByaWwgMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgIDZsb3dwYW4gUHJvYmxlbXMgYW5kIEdvYWxzICAgICAgICAgICBPY3Rv YmVyIDIwMDUKCgogICBsaW5rIGxheWVyIChha2luIHRvIHJvdXRlcnMgYXQgdGhlIG5ldHdvcmsg bGF5ZXIpLiAgVHlwaWNhbGx5IHRoZXNlCiAgIGFyZSAiZnVsbCBmdW5jdGlvbiBkZXZpY2VzIiB0 aGF0IGhhdmUgbW9yZSBjYXBhYmlsaXRpZXMgaW4gdGVybXMgb2YKICAgcG93ZXIsIGNvbXB1dGF0 aW9uLCBldGMuICBUaGUgcmVxdWlyZW1lbnRzIHRoYXQgYXBwbHkgb24gdGhlIGNob3NlbgogICBy b3V0aW5nIHByb3RvY29sIGFyZToKCiAgIDEuICBHaXZlbiB0aGUgbWluaW1hbCBwYWNrZXQgc2l6 ZSBvZiBMb1dQQU5zLCB0aGUgcm91dGluZyBwcm90b2NvbAogICAgICAgbXVzdCBpbXBvc2UgbG93 IChvciBubykgb3ZlcmhlYWQgb24gZGF0YSBwYWNrZXRzLCBob3BlZnVsbHkKICAgICAgIGluZGVw ZW5kZW50bHkgb2YgdGhlIG51bWJlciBvZiBob3BzLgogICAyLiAgVGhlIHJvdXRpbmcgcHJvdG9j b2xzIHNob3VsZCBoYXZlIGxvdyByb3V0aW5nIG92ZXJoZWFkIChsZXNzCiAgICAgICBjaGF0dHkp IGJhbGFuY2VkIHdpdGggdG9wb2xvZ3kgY2hhbmdlcyBhbmQgcG93ZXIgY29uc2VydmF0aW9uLgog ICAzLiAgVGhlIGNvbXB1dGF0aW9uIGFuZCBtZW1vcnkgcmVxdWlyZW1lbnRzIGluIHRoZSByb3V0 aW5nIHByb3RvY29sCiAgICAgICBzaG91bGQgYmUgbWluaW1hbCB0byBzYXRpc2Z5IGxvdyBjb3N0 IGFuZCBsb3cgcG93ZXIKICAgICAgIGNoYXJhY3RlcmlzdGljcy4gIFRodXMgc3RvcmFnZSBhbmQg bWFpbnRhaW5pbmcgb2YgbGFyZ2Ugcm91dGluZwogICAgICAgdGFibGVzIG1heSBiZSBkZXRyaW1l bnRhbC4KCiAgIEFzIHdpdGggbWVzaCB0b3BvbG9naWVzLCBzdGFyIHRvcG9sb2dpZXMgaW5jbHVk ZSBwcm92aXNpb25pbmcgYQogICBzdWJzZXQgb2YgZGV2aWNlcyB3aXRoIHBhY2tldCBmb3J3YXJk aW5nIGZ1bmN0aW9uYWxpdHkuICBJZiwgaW4KICAgYWRkaXRpb24gdG8gSUVFRSA4MDIuMTUuNCwg dGhlc2UgZGV2aWNlcyB1c2Ugb3RoZXIga2luZHMgb2YgbmV0d29yawogICBpbnRlcmZhY2VzIHN1 Y2ggYXMgZXRoZXJuZXQsIElFRUUgODAyLjExLCBldGMuLCB0aGUgZ29hbCBpcyB0bwogICBzZWFt bGVzc2x5IGludGVncmF0ZSB0aGUgbmV0d29ya3MgYnVpbHQgb3ZlciB0aG9zZSBkaWZmZXJlbnQK ICAgdGVjaG5vbG9naWVzLiAgVGhpcywgb3IgY291cnNlLCBpcyBhIHByaW1hcnkgbW90aXZhdGlv biB0byB1c2UgSVAgdG8KICAgYmVnaW4gd2l0aC4KCjQuMy4gIExpbWl0ZWQgUGFja2V0IFNpemUK CiAgIEFwcGxpY2F0aW9ucyB3aXRoaW4gTG9XUEFOcyBhcmUgZXhwZWN0ZWQgdG8gb3JpZ2luYXRl IHNtYWxsIHBhY2tldHMuCiAgIEFkZGluZyBhbGwgbGF5ZXJzIGZvciBJUCBjb25uZWN0aXZpdHkg c2hvdWxkIHN0aWxsIGFsbG93IHRyYW5zbWlzc2lvbgogICBpbiBvbmUgZnJhbWUgd2l0aG91dCBp bmN1cnJpbmcgZXhjZXNzaXZlIGZyYWdtZW50YXRpb24gYW5kCiAgIHJlYXNzZW1ibHkuICBGdXJ0 aGVybW9yZSwgcHJvdG9jb2xzIG11c3QgYmUgZGVzaWduZWQgb3IgY2hvc2VuIHNvCiAgIHRoYXQg dGhlIGluZGl2aWR1YWwgImNvbnRyb2wvcHJvdG9jb2wgcGFja2V0cyIgZml0IHdpdGhpbiBhIHNp bmdsZQogICA4MDIuMTUuNCBmcmFtZS4KCjQuNC4gIExpbWl0ZWQgY29uZmlndXJhdGlvbiBhbmQg bWFuYWdlbWVudAoKICAgQXMgYWxsdWRlZCB0byBhYm92ZSwgZGV2aWNlcyB3aXRoaW4gTG9XUEFO cyBhcmUgZXhwZWN0ZWQgdG8gYmUKICAgZGVwbG95ZWQgaW4gZXhjZWVkaW5nbHkgbGFyZ2UgbnVt YmVycy4gIEFkZGl0aW9uYWxseSwgdGhleSBhcmUKICAgZXhwZWN0ZWQgdG8gaGF2ZSBsaW1pdGVk IGRpc3BsYXkgYW5kIGlucHV0IGNhcGFiaWxpdGllcy4KICAgRnVydGhlcm1vcmUsIHRoZSBsb2Nh dGlvbiBvZiBzb21lIG9mIHRoZXNlIGRldmljZXMgbWF5IGJlIGhhcmQgdG8KICAgYWNjZXNzLiAg QXMgc3VjaCwgcHJvdG9jb2xzIGRlc2lnbmVkIGZvciBMb1dQQU5zIHNob3VsZCBoYXZlIG1pbmlt YWwKICAgY29uZmlndXJhdGlvbiwgcHJlZmVyYWJseSB3b3JrICJvdXQgb2YgdGhlIGJveCIsIHBy b3ZpZGUgZWFzeQogICBib290c3RyYXBwaW5nLCBhbmQgc2hvdWxkIGJlIGFibGUgdG8gc2VsZiBo ZWFsIGdpdmVuIHRoZSBpbmhlcmVudAogICB1bnJlbGlhYmxlIGNoYXJhY3RlcmlzdGljIG9mIHRo ZXNlIGRldmljZXMuICBUaGUgbmV0d29yayBtYW5hZ2VtZW50CiAgIHNob3VsZCBoYXZlIGxlc3Mg b3ZlcmhlYWQgeWV0IGJlIHBvd2VyZnVsIHRvIGNvbnRyb2wgZGVuc2UgZGVwbG95bWVudAogICBv ZiBkZXZpY2VzLgoKNC41LiAgU2VydmljZSBkaXNjb3ZlcnkKCiAgIExvV1BBTnMgcmVxdWlyZSBz aW1wbGUgc2VydmljZSBkaXNjb3ZlcnkgbmV0d29yayBwcm90b2NvbHMgdG8KCgoKS3VzaGFsbmFn YXIgJiBNb250ZW5lZ3JvICBFeHBpcmVzIEFwcmlsIDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQ YWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICA2bG93cGFuIFByb2JsZW1zIGFuZCBHb2Fs cyAgICAgICAgICAgT2N0b2JlciAyMDA1CgoKICAgZGlzY292ZXIsIGNvbnRyb2wgYW5kIG1haW50 YWluIHNlcnZpY2VzIHByb3ZpZGVkIGJ5IGRldmljZXMuICBJbiBzb21lCiAgIGNhc2VzLCBlc3Bl Y2lhbGx5IGluIGRlbnNlIGRlcGxveW1lbnRzLCBhYnN0cmFjdGlvbiBvZiBzZXZlcmFsIG5vZGVz CiAgIHRvIHByb3ZpZGUgYSBzZXJ2aWNlIG1heSBiZSBiZW5lZmljaWFsLiAgSW4gb3JkZXIgdG8g ZW5hYmxlIHN1Y2gKICAgZmVhdHVyZXMsIG5ldyBwcm90b2NvbHMgbWF5IGhhdmUgdG8gYmUgZGVz aWduZWQuCgo0LjYuICBTZWN1cml0eQoKICAgQWx0aG91Z2ggSUVFRSA4MDIuMTUuNCBwcm92aWRl cyBBRVMgbGluayBsYXllciBzZWN1cml0eSwgYSBjb21wbGV0ZQogICBlbmQtdG8tZW5kIHNlY3Vy aXR5IGlzIG5lZWRlZC4KCgo1LiAgR29hbHMKCiAgIEdvYWxzIG1lbnRpb25lZCBoZXJlIG1heSBw b2ludCBhdCByZWxldmFudCB3b3JrIHRoYXQgY2FuIGJlIGRvbmUKICAgd2l0aGluIHRoZSBJRVRG IChlLmcuLCBzcGVjaWZpY2F0aW9uIHJlcXVpcmVkIHRvIHRyYW5zbWl0IElQLCBwcm9maWxlCiAg IG9mIGJlc3QgcHJhY3RpY2VzIGZvciB0cmFuc21pdHRpbmcgSVAgcGFja2V0cywgYW5kIGFzc29j aWF0ZWQgdXBwZXIKICAgbGV2ZWwgcHJvdG9jb2xzLCBldGMpLiAgSXQgbWF5IGFsc28gcG9pbnQg YXQgd29yayB0byBiZSBkb25lIGluIG90aGVyCiAgIHN0YW5kYXJkcyBib2RpZXMgdGhhdCBleGlz dCBvciBtYXkgZXhpc3QgaW4gdGhlIGZ1dHVyZSAoZS5nLiwKICAgZGVzaXJhYmxlIGNoYW5nZXMg b3IgcHJvZmlsZXMgcmVsZXZhbnQgdG8gSUVFRSA4MDIuMTUuNCwgVzNDLCBldGMpLgogICBXaGVu IHRoZSBnb2FscyBmYWxsIHVuZGVyIHRoZSBJRVRGJ3MgcHVydmlldywgdGhleSBzZXJ2ZSB0byBw b2ludCBvdXQKICAgd2hhdCB0aG9zZSBlZmZvcnRzIHNob3VsZCBzdHJpdmUgdG8gYWNjb21wbGlz aC4gIFJlZ2FyZGxlc3Mgb2YKICAgd2hldGhlciB0aGV5IGFyZSBwdXJzdWVkIHdpdGhpbiBvbmUg KG9yIG1vcmUpIG5ldyAob3IgZXhpc3RpbmcpCiAgIHdvcmtpbmcgZ3JvdXBzLiAgV2hlbiB0aGUg Z29hbHMgZG8gbm90IGZhbGwgdW5kZXIgdGhlIHB1cnZpZXcgb2YgdGhlCiAgIElFVEYsIGRvY3Vt ZW50aW5nIHRoZW0gaGVyZSBzZXJ2ZXMgYXMgaW5wdXQgdG8gdGhvc2Ugb3RoZXIKICAgb3JnYW5p emF0aW9ucyBbbGlhaXNvbl0uCgogICBUaGUgZm9sbG93aW5nIGFyZSB0aGUgZ29hbHMgYWNjb3Jk aW5nIHRvIHByaW9yaXR5IGZvciBMb1dQQU5zOgoKICAgMS4gIEFzIG1lbnRpb25lZCBpbiB0aGUg b3ZlcnZpZXcsIHRoZSBwcm90b2NvbCBkYXRhIHVuaXRzIG1heSBiZSBhcwogICAgICAgc21hbGwg ODEgYnl0ZXMuICBUaGlzIGlzIG9idmlvdXNseSBmYXIgYmVsb3cgdGhlIG1pbmltdW0gSVB2Ngog ICAgICAgcGFja2V0IHNpemUgb2YgMTI4MCBvY3RldHMsIGFuZCBpbiBrZWVwaW5nIHdpdGggc2Vj dGlvbiA1IG9mIHRoZQogICAgICAgSVB2NiBzcGVjaWZpY2F0aW9uIFtSRkMyNDYwXSwgYSBmcmFn bWVudGF0aW9uIGFuZCByZWFzc2VtYmx5CiAgICAgICBhZGFwdGF0aW9uIGxheWVyIG11c3QgYmUg cHJvdmlkZWQgYXQgdGhlIGxheWVyIGJlbG93IElQLgoKICAgMi4gIEdpdmVuIHRoYXQgaW4gdGhl IHdvcnN0IGNhc2UgdGhlIG1heGltdW0gc2l6ZSBhdmFpbGFibGUgZm9yCiAgICAgICB0cmFuc21p dHRpbmcgSVAgcGFja2V0cyBvdmVyIElFRUUgODAyLjE1LjQgZnJhbWUgaXMgODEgb2N0ZXRzLAog ICAgICAgYW5kIHRoYXQgdGhlIElQdjYgaGVhZGVyIGlzIDQwIG9jdGV0cyBsb25nLCAod2l0aG91 dCBvcHRpb25hbAogICAgICAgaGVhZGVycyksIHRoaXMgbGVhdmVzIG9ubHkgNDEgb2N0ZXRzIGZv ciB1cHBlci1sYXllciBwcm90b2NvbHMsCiAgICAgICBsaWtlIFVEUCBhbmQgVENQLiAgVURQIHVz ZXMgOCBvY3RldHMgaW4gdGhlIGhlYWRlciBhbmQgVENQIHVzZXMKICAgICAgIDIwIG9jdGV0cy4g IFRoaXMgbGVhdmVzIDMzIG9jdGV0cyBmb3IgZGF0YSBvdmVyIFVEUCBhbmQgMjEgb2N0ZXRzCiAg ICAgICBmb3IgZGF0YSBvdmVyIFRDUC4gIEFkZGl0aW9uYWxseSwgYXMgcG9pbnRlZCBhYm92ZSwg dGhlcmUgaXMgYWxzbwogICAgICAgYSBuZWVkIGZvciBhIGZyYWdtZW50YXRpb24gYW5kIHJlYXNz ZW1ibHkgbGF5ZXIsIHdoaWNoIHdpbGwgdXNlCiAgICAgICBldmVuIG1vcmUgb2N0ZXRzIGxlYXZp bmcgdmVyeSBmZXcgb2N0ZXRzIGZvciBkYXRhLiAgVGh1cyBpZiBvbmUKICAgICAgIHdlcmUgdG8g dXNlIHRoZSBwcm90b2NvbHMgYXMgaXMsIGl0IHdvdWxkIGxlYWQgdG8gZXhjZXNzaXZlCiAgICAg ICBmcmFnbWVudGF0aW9uIGFuZCByZWFzc2VtYmx5IGV2ZW4gd2hlbiBkYXRhIHBhY2tldHMgYXJl IGp1c3QgMTBzCiAgICAgICBvZiBvY3RldHMgbG9uZy4gIFRoaXMgcG9pbnRzIGF0IHRoZSBuZWVk IGZvciBoZWFkZXIgY29tcHJlc3Npb24KICAgICAgIEFzIHRoZXJlIGlzIG11Y2ggcHVibGlzaGVk IGFuZCBpbi1wcm9ncmVzcyBzdGFuZGFyZGl6YXRpb24gd29yawogICAgICAgb24gaGVhZGVyIGNv bXByZXNzaW9uLCB0aGlzIGdvYWwgbmVlZHMgdG8gaW52ZXN0aWdhdGUgdXNpbmcKCgoKS3VzaGFs bmFnYXIgJiBNb250ZW5lZ3JvICBFeHBpcmVzIEFwcmlsIDI3LCAyMDA2ICAgICAgICAgICAgICAg IFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICA2bG93cGFuIFByb2JsZW1zIGFuZCBH b2FscyAgICAgICAgICAgT2N0b2JlciAyMDA1CgoKICAgICAgIGV4aXN0aW5nIGhlYWRlciBjb21w cmVzc2lvbiB0ZWNobmlxdWVzIGFuZCBpZiBuZWNlc3Nhcnkgc3BlY2lmeQogICAgICAgbmV3IG9u ZXMuCgogICAzLiAgW0ktRC5pZXRmLWlwdjYtcmZjMjQ2MmJpc10gc3BlY2lmeSBtZXRob2RzIGZv ciBjcmVhdGluZyBJUHY2CiAgICAgICBzdGF0ZWxlc3MgYWRkcmVzcyBhdXRvY29uZmlndXJhdGlv bi4gIFN0YXRlbGVzcyBhdXRvCiAgICAgICBjb25maWd1cmF0aW9uIGhhcyBhbiBhZHZhbnRhZ2Ug b3ZlciBzdGF0ZWZ1bCBieSBoYXZpbmcgbGVzcwogICAgICAgY29uZmlndXJhdGlvbiBvdmVyaGVh ZCBvbiB0aGUgaG9zdHMgc3VpdGFibGUgZm9yIExvV1BBTnMuICBUaGUKICAgICAgIGdvYWwgc2hv dWxkIHNwZWNpZnkgYSBtZXRob2QgdG8gZ2VuZXJhdGUgYW4gImludGVyZmFjZQogICAgICAgaWRl bnRpZmllciIgZnJvbSB0aGUgRVVJLTY0IFtFVUk2NF0gYXNzaWduZWQgdG8gdGhlIElFRUUgODAy LjE1LjQKICAgICAgIGRldmljZS4KCiAgIDQuICBBIHJvdXRpbmcgcHJvdG9jb2wgdG8gc3VwcG9y dCBhIG11bHRpLWhvcCBtZXNoIG5ldHdvcmsgaXMKICAgICAgIG5lY2Vzc2FyeS4gIFRoZXJlIGlz IG11Y2ggcHVibGlzaGVkIHdvcmsgb24gYWRob2MgbXVsdGkgaG9wCiAgICAgICByb3V0aW5nIGZv ciBkZXZpY2VzLiAgU29tZSBleGFtcGxlcyBpbmNsdWRlIFtSRkMzNTYxXSwgW1JGQzM2MjZdLAog ICAgICAgW1JGQzM2ODRdLCBhbGwgZXhwZXJpbWVudGFsLiAgQWxzbywgdGhlc2UgcHJvdG9jb2xz IGFyZSBkZXNpZ25lZAogICAgICAgdG8gdXNlIElQIGJhc2VkIGFkZHJlc3NlcyB0aGF0IGhhdmUg bGFyZ2Ugb3ZlcmhlYWRzLiAgRm9yCiAgICAgICBleGFtcGxlLCB0aGUgQU9EViBbUkZDMzU2MV0g cm91dGluZyBwcm90b2NvbCB1c2VzIDQ4IG9jdGV0cyBmb3IgYQogICAgICAgcm91dGUgcmVxdWVz dCBiYXNlZCBvbiBJUHY2IGFkZHJlc3NpbmcuICBHaXZlbiB0aGUgcGFja2V0IHNpemUKICAgICAg IGNvbnN0cmFpbnRzLCB0cmFuc21pdHRpbmcgdGhpcyBwYWNrZXQgd2l0aG91dCBmcmFnbWVudGF0 aW9uIGFuZAogICAgICAgcmVhc3NlbWJseSBtYXkgYmUgZGlmZmljdWx0LiAgVGh1cyBjYXJlIHNo b3VsZCBiZSB0YWtlbiB3aGVuCiAgICAgICB1c2luZyBleGlzdGluZyBwcm90b2NvbHMgb3IgZGVz aWduaW5nIG5ldyBwcm90b2NvbHMgZm9yIHJvdXRpbmcKICAgICAgIHNvIHRoYXQgdGhlIHJvdXRp bmcgcGFja2V0cyBmaXQgd2l0aGluIGEgc2luZ2xlIElFRUUgODAyLjE1LjQKICAgICAgIGZyYW1l LgoKICAgNS4gIE9uZSBvZiB0aGUgcG9pbnRzIG9mIHRyYW5zbWl0dGluZyBJUHY2IHBhY2tldHMs IGlzIHRvIHJldXNlCiAgICAgICBleGlzdGluZyBwcm90b2NvbHMgYXMgbXVjaCBhcyBwb3NzaWJs ZS4gIE5ldHdvcmsgbWFuYWdlbWVudAogICAgICAgZnVuY3Rpb25hbGl0eSBpcyBjcml0aWNhbCBm b3IgTG9XUEFOcy4gIFtSRkMzNDExXSBzcGVjaWZpZXMKICAgICAgIFNOTVB2MyBwcm90b2NvbCBv cGVyYXRpb25zLiAgU05NUCBmdW5jdGlvbmFsaXR5IG1heSBiZSB0cmFuc2xhdGVkCiAgICAgICAi YXMgaXMiIHRvIExvV1BBTnMuICBIb3dldmVyLCBmdXJ0aGVyIGludmVzdGlnYXRpb24gaXMgcmVx dWlyZWQuCiAgICAgICBTTk1QdjMgbWF5IG5vdCBiZSB0aGUgYmVzdCBwcm90b2NvbCBmb3IgdGhp cyB0YXNrLiAgT3IgaXQgbWF5IGJlCiAgICAgICBvbmx5IGFmdGVyIGFkYXB0aW5nIGl0IGFwcHJv cHJpYXRlbHkuCgogICA2LiAgSXQgbWF5IGJlIHRoZSBjYXNlIHRoYXQgdHJhbnNtaXR0aW5nIElQ IG92ZXIgSUVFRSA4MDIuMTUuNCB3b3VsZAogICAgICAgYmVjb21lIG1vcmUgYmVuZWZpY2lhbCBp ZiBpbXBsZW1lbnRlZCBpbiBhICJjZXJ0YWluIiB3YXkuCiAgICAgICBBY2NvcmRpbmdseSwgaW1w bGVtZW50YXRpb24gY29uc2lkZXJhdGlvbnMgYXJlIHRvIGJlIGRvY3VtZW50ZWQuCgogICA3LiAg QXMgaGVhZGVyIGNvbXByZXNzaW9uIGJlY29tZXMgbW9yZSBwcmV2YWxlbnQsIG92ZXJhbGwgcGVy Zm9ybWFuY2UKICAgICAgIHdpbGwgZGVwZW5kIGV2ZW4gbW9yZSBvbiBlZmZpY2llbmN5IG9mIGFw cGxpY2F0aW9uIHByb3RvY29scy4KICAgICAgIEhlYXZ5d2VpZ2h0IHByb3RvY29scyBiYXNlZCBv biBYTUwgc3VjaCBhcyBTT0FQIFtTT0FQXSwgbWF5IG5vdAogICAgICAgYmUgc3VpdGFibGUgZm9y IExvV1BBTnMuICBBcyBzdWNoLCBtb3JlIGNvbXBhY3QgZW5jb2RpbmdzIChhbmQKICAgICAgIHBl cmhhcHMgcHJvdG9jb2xzKSBtYXkgYmVjb21lIG5lY2Vzc2FyeS4gIFRoZSBnb2FsIGhlcmUgaXMg dG8KICAgICAgIHNwZWNpZnkgb3Igc3VnZ2VzdCBtb2RpZmljYXRpb25zIHRvIGV4aXN0aW5nIHBy b3RvY29scyBzbyB0aGF0IGl0CiAgICAgICBpcyBzdWl0YWJsZSBmb3IgTG9XUEFOcy4gIEZ1cnRo ZXJtb3JlLCBhcHBsaWNhdGlvbiBsZXZlbAogICAgICAgaW50ZXJvcGVyYWJpbGl0eSBzcGVjaWZp Y2F0aW9ucyBtYXkgYWxzbyBiZWNvbWUgbmVjZXNzYXJ5IGluIHRoZQogICAgICAgZnV0dXJlIGFu ZCBtYXkgdGh1cyBiZSBzcGVjaWZpZWQuCgoKCgoKCkt1c2hhbG5hZ2FyICYgTW9udGVuZWdybyAg RXhwaXJlcyBBcHJpbCAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgNmxvd3BhbiBQcm9ibGVtcyBhbmQgR29hbHMgICAgICAgICAgIE9jdG9i ZXIgMjAwNQoKCiAgIDguICBTZWN1cml0eSB0aHJlYXRzIGF0IGRpZmZlcmVudCBsYXllcnMgbXVz dCBiZSBjbGVhcmx5IHVuZGVyc3Rvb2QKICAgICAgIGFuZCBkb2N1bWVudGVkLiAgQm9vdHN0cmFw cGluZyBvZiBkZXZpY2VzIGludG8gYSBzZWN1cmUgbmV0d29yawogICAgICAgY291bGQgYWxzbyBi ZSBjb25zaWRlcmVkIGdpdmVuIHRoZSBsb2NhdGlvbiwgbGltaXRlZCBkaXNwbGF5LAogICAgICAg aGlnaCBkZW5zaXR5IGFuZCBhZCBob2MgZGVwbG95bWVudCBvZiBkZXZpY2VzLgoKCjYuICBJQU5B IENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRvY3VtZW50IGNvbnRhaW5zIG5vIElBTkEgY29uc2lk ZXJhdGlvbnMuCgoKNy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBJRUVFIDgwMi4xNS40 IHByb3ZpZGVzIEFFUyBsaW5rIGxheWVyIHNlY3VyaXR5LiAgQXMgNkxvV1BBTiBpbXBvc2VzCiAg IHVuaXF1ZSBzZXQgb2YgY2hhbGxlbmdlcyB0aGF0IGFyZSBub3QgcHJldmVsYW50IGluIGNsYXNz aWNhbAogICBuZXR3b3Jrcywgc2VjdXJpdHkgdGhyZWF0cyBhY3Jvc3MgdmFyaW91cyBsYXllcnMg c2hvdWxkIGZpcnN0IGJlCiAgIHVuZGVyc3Rvb2QgYmVmb3JlIGNob29zaW5nIGFueSBzZWN1cml0 eSBwcm90b2NvbC4gIEZ1cnRoZXJtb3JlLCB0aGVzZQogICBkZXZpY2VzIG1heSBub3QgaGF2ZSBh bnkgZnJvbnQgZW5kIHRvIGRvIGNvbmZpZ3VyYXRpb24gYW5kCiAgIG1hbmFnZW1lbnQuICBBcyBz dWNoIHByb3RvY29scyBtdXN0IGJlIGNob3NlbiB0byBoYXZlIHZlcnkgbGl0dGxlCiAgIGNvbmZp Z3VyYXRpb24gYW5kIG1hbmFnZW1lbnQsIGJ1dCBzdGlsbCBub3QgY29tcHJhbWlzZSBvbiBlaXRo ZXIKICAgY29ubmVjdGl2aXR5IG5vciBzZWN1cml0eS4KCgo4LiAgQWNrbm93bGVkZ2VtZW50cwoK ICAgVGhhbmtzIHRvIDoKCiAgIEdlb2ZmIE11bGxpZ2FuCgogICBTb29ob25nIERhbmllbCBQYXJr CgogICBTYW1pdGEgQ2hha3JhYmFydGkKCiAgIEJyaWplc2ggS3VtYXIKCiAgIGZvciB0aGVpciBj b21tZW50cyBhbmQgaGVscCBzaGFwaW5nIHRoaXMgZG9jdW1lbnQuCgoKOS4gIFJlZmVyZW5jZXMK CjkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbRVVJNjRdICAgICJHVUlERUxJTkVTIEZP UiA2NC1CSVQgR0xPQkFMIElERU5USUZJRVIgKEVVSS02NCkKICAgICAgICAgICAgICBSRUdJU1RS QVRJT04gQVVUSE9SSVRZIiwgSUVFRSBodHRwOi8vc3RhbmRhcmRzLmllZWUub3JnLwogICAgICAg ICAgICAgIHJlZ2F1dGgvb3VpL3R1dG9yaWFscy9FVUk2NC5odG1sLgoKICAgW0ktRC5pZXRmLWlw djYtMjQ2MWJpc10KICAgICAgICAgICAgICBOYXJ0ZW4sIFQuLCAiTmVpZ2hib3IgRGlzY292ZXJ5 IGZvciBJUCB2ZXJzaW9uIDYgKElQdjYpIiwKCgoKS3VzaGFsbmFnYXIgJiBNb250ZW5lZ3JvICBF eHBpcmVzIEFwcmlsIDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICA2bG93cGFuIFByb2JsZW1zIGFuZCBHb2FscyAgICAgICAgICAgT2N0b2Jl ciAyMDA1CgoKICAgICAgICAgICAgICBkcmFmdC1pZXRmLWlwdjYtMjQ2MWJpcy0wNSAod29yayBp biBwcm9ncmVzcyksCiAgICAgICAgICAgICAgT2N0b2JlciAyMDA1LgoKICAgW0ktRC5pZXRmLWlw djYtcmZjMjQ2MmJpc10KICAgICAgICAgICAgICBUaG9tc29uLCBTLiwgIklQdjYgU3RhdGVsZXNz IEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24iLAogICAgICAgICAgICAgIGRyYWZ0LWlldGYtaXB2 Ni1yZmMyNDYyYmlzLTA4ICh3b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgICAgICBNYXkgMjAw NS4KCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNz IHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBS RkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkMyNDYwXSAgRGVlcmluZywgUy4gYW5kIFIuIEhp bmRlbiwgIkludGVybmV0IFByb3RvY29sLCBWZXJzaW9uIDYKICAgICAgICAgICAgICAoSVB2Nikg U3BlY2lmaWNhdGlvbiIsIFJGQyAyNDYwLCBEZWNlbWJlciAxOTk4LgoKICAgW2llZWU4MDIuMTUu NF0KICAgICAgICAgICAgICBJRUVFIENvbXB1dGVyIFNvY2lldHksICJJRUVFIFN0ZC4gODAyLjE1 LjQtMjAwMyIsCiAgICAgICAgICAgICAgT2N0b2JlciAyMDAzLgoKOS4yLiAgSW5mb3JtYXRpdmUg UmVmZXJlbmNlcwoKICAgW1JGQzM0MTFdICBIYXJyaW5ndG9uLCBELiwgUHJlc3VobiwgUi4sIGFu ZCBCLiBXaWpuZW4sICJBbgogICAgICAgICAgICAgIEFyY2hpdGVjdHVyZSBmb3IgRGVzY3JpYmlu ZyBTaW1wbGUgTmV0d29yayBNYW5hZ2VtZW50CiAgICAgICAgICAgICAgUHJvdG9jb2wgKFNOTVAp IE1hbmFnZW1lbnQgRnJhbWV3b3JrcyIsIFNURCA2MiwgUkZDIDM0MTEsCiAgICAgICAgICAgICAg RGVjZW1iZXIgMjAwMi4KCiAgIFtSRkMzNTYxXSAgUGVya2lucywgQy4sIEJlbGRpbmctUm95ZXIs IEUuLCBhbmQgUy4gRGFzLCAiQWQgaG9jIE9uLQogICAgICAgICAgICAgIERlbWFuZCBEaXN0YW5j ZSBWZWN0b3IgKEFPRFYpIFJvdXRpbmciLCBSRkMgMzU2MSwKICAgICAgICAgICAgICBKdWx5IDIw MDMuCgogICBbUkZDMzYyNl0gIENsYXVzZW4sIFQuIGFuZCBQLiBKYWNxdWV0LCAiT3B0aW1pemVk IExpbmsgU3RhdGUgUm91dGluZwogICAgICAgICAgICAgIFByb3RvY29sIChPTFNSKSIsIFJGQyAz NjI2LCBPY3RvYmVyIDIwMDMuCgogICBbUkZDMzY4NF0gIE9naWVyLCBSLiwgVGVtcGxpbiwgRi4s IGFuZCBNLiBMZXdpcywgIlRvcG9sb2d5CiAgICAgICAgICAgICAgRGlzc2VtaW5hdGlvbiBCYXNl ZCBvbiBSZXZlcnNlLVBhdGggRm9yd2FyZGluZyAoVEJSUEYpIiwKICAgICAgICAgICAgICBSRkMg MzY4NCwgRmVicnVhcnkgMjAwNC4KCiAgIFtSRkMzNzU2XSAgTmlrYW5kZXIsIFAuLCBLZW1wZiwg Si4sIGFuZCBFLiBOb3JkbWFyaywgIklQdjYgTmVpZ2hib3IKICAgICAgICAgICAgICBEaXNjb3Zl cnkgKE5EKSBUcnVzdCBNb2RlbHMgYW5kIFRocmVhdHMiLCBSRkMgMzc1NiwKICAgICAgICAgICAg ICBNYXkgMjAwNC4KCiAgIFtTT0FQXSAgICAgIlNPQVAiLCBXM0MgaHR0cDovL3d3dy53M2Mub3Jn LzIwMDAveHAvR3JvdXAvLgoKICAgW2xpYWlzb25dICAiTElBU09OUyIsCiAgICAgICAgICAgICAg SUVURiBodHRwOi8vd3d3LmlldGYub3JnL2xpYWlzb25BY3Rpdml0aWVzLmh0bWwuCgoKCgoKCgpL dXNoYWxuYWdhciAmIE1vbnRlbmVncm8gIEV4cGlyZXMgQXByaWwgMjcsIDIwMDYgICAgICAgICAg ICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIDZsb3dwYW4gUHJvYmxlbXMg YW5kIEdvYWxzICAgICAgICAgICBPY3RvYmVyIDIwMDUKCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAg IE5hbmRha2lzaG9yZSBLdXNoYWxuYWdhcgogICBJbnRlbCBDb3JwCgogICBFbWFpbDogbmFuZGFr aXNob3JlLmt1c2hhbG5hZ2FyQGludGVsLmNvbQoKCiAgIEdhYnJpZWwgTW9udGVuZWdybwogICBN aWNyb3NvZnQgQ29ycG9yYXRpb24KCiAgIEVtYWlsOiBnYWJyaWVsX21vbnRlbmVncm9fMjAwMEB5 YWhvby5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKS3VzaGFsbmFn YXIgJiBNb250ZW5lZ3JvICBFeHBpcmVzIEFwcmlsIDI3LCAyMDA2ICAgICAgICAgICAgICAgW1Bh Z2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICA2bG93cGFuIFByb2JsZW1zIGFuZCBHb2Fs cyAgICAgICAgICAgT2N0b2JlciAyMDA1CgoKSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVu dAoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBv ciBzY29wZSBvZiBhbnkKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciBy aWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVu dGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4KICAgdGhpcyBkb2N1 bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRz CiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2Vu dCB0aGF0IGl0IGhhcwogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkg YW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCBy ZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQogICBmb3VuZCBpbiBCQ1Ag NzggYW5kIEJDUCA3OS4KCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUg SUVURiBTZWNyZXRhcmlhdCBhbmQgYW55CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUg bWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBtYWRlIHRvIG9i dGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mCiAgIHN1 Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzCiAg IHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIg cmVwb3NpdG9yeSBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4KCiAgIFRoZSBJRVRGIGlu dml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkK ICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBw cm9wcmlldGFyeQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBi ZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNz IHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdAogICBpZXRmLWlwckBpZXRmLm9yZy4KCgpE aXNjbGFpbWVyIG9mIFZhbGlkaXR5CgogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4KICAgIkFTIElTIiBiYXNpcyBh bmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTCiAg IE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRI RSBJTlRFUk5FVAogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5U SUVTLCBFWFBSRVNTIE9SIElNUExJRUQsCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8g QU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUKICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJ TEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQKICAgV0FSUkFOVElFUyBP RiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCgoK Q29weXJpZ2h0IFN0YXRlbWVudAoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0 eSAoMjAwNSkuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QKICAgdG8gdGhlIHJpZ2h0cywgbGlj ZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQKICAgZXhjZXB0 IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0 cy4KCgpBY2tub3dsZWRnbWVudAoKICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rp b24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQogICBJbnRlcm5ldCBTb2NpZXR5LgoKCgoK S3VzaGFsbmFnYXIgJiBNb250ZW5lZ3JvICBFeHBpcmVzIEFwcmlsIDI3LCAyMDA2ICAgICAgICAg ICAgICAgW1BhZ2UgMTJdCgwKCg== ------_=_NextPart_001_01C5D8AE.AB9BC998 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_001_01C5D8AE.AB9BC998-- From 6lowpan-bounces@ietf.org Mon Oct 24 16:02:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8WR-0007Py-2u; Mon, 24 Oct 2005 16:02:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8WO-0007Jt-Sk for 6lowpan@megatron.ietf.org; Mon, 24 Oct 2005 16:02:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01229 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 16:02:01 -0400 (EDT) Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EU8jB-0000E3-Ri for 6lowpan@ietf.org; Mon, 24 Oct 2005 16:15:31 -0400 Received: (qmail 49284 invoked by uid 60001); 24 Oct 2005 20:02:05 -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:Content-Transfer-Encoding; b=Z9srT4PC4aiwXNTfuO7xtHpkCA3MgPIetxjaCW4eAR8vnQkaBZUUm/ymhKJtXX2cebJ+aVl0Luyg/9xPymmCeWdYo5iGE49mOEzp5E/W1wuEcyRB91c9kPBKT1pmt9CcYa+7HgP3SEENPOiF5Fd+7wafXRBfSG+hQGFJVzm8g64= ; Message-ID: <20051024200205.49282.qmail@web81903.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81903.mail.mud.yahoo.com via HTTP; Mon, 24 Oct 2005 13:02:05 PDT Date: Mon, 24 Oct 2005 13:02:05 -0700 (PDT) From: gabriel montenegro To: 6lowpan@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 8bit Subject: [6lowpan] revision of format draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Folks, Submitted a new version. Before the official announcement, please find it here: http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-01.htm http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-01.txt Final list of changes: Changes from version draft-ietf-6lowpan-format-00.txt to version draft-ietf-6lowpan-format-01.txt are as follows: Added a reassembly timeout of 15 sec. Added support for 16-bit "short" addresses. datagram tag now at 10 bits protocol_type and datagram offset both went from 11 to 8 bits (which is still enough for the format, and which implies counting offset in units of 8 octets for the latter). Addition of the originator's link-layer source address to the "Mesh Delivery" header. Changed name of "Final Destination" header to "Mesh Delivery" header. Further clarification on mesh delivery. Sundry editorial changes. This format still does not have a version field, so let's continue discussion on this subject. -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 24 18:44:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB3j-000327-Bz; Mon, 24 Oct 2005 18:44:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB3h-000322-TS for 6lowpan@megatron.ietf.org; Mon, 24 Oct 2005 18:44:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26354 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 18:44:36 -0400 (EDT) Received: from web81910.mail.mud.yahoo.com ([68.142.207.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUBGV-0002jJ-Ls for 6lowpan@ietf.org; Mon, 24 Oct 2005 18:58:06 -0400 Received: (qmail 50801 invoked by uid 60001); 24 Oct 2005 22:44:37 -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:Content-Transfer-Encoding; b=EsMczzSLO4tL8/CSe9MFQp7DAAVx83UrwpwgvMQ9oOywztU60qcabcnwm+D2NQwy1JtTNaIkKcVtLukhlUKbJg8yYRP1fi3J8SEP+ZMvqB2vkKszmIOSFqBlsJTIEzp5U5VNFlQjyCxuuBzNZp3105i03QU6pcaoVEivpbsQpPs= ; Message-ID: <20051024224437.50799.qmail@web81910.mail.mud.yahoo.com> Received: from [131.107.0.87] by web81910.mail.mud.yahoo.com via HTTP; Mon, 24 Oct 2005 15:44:37 PDT Date: Mon, 24 Oct 2005 15:44:37 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) To: Vipul Gupta , 6lowpan@ietf.org In-Reply-To: <4cc207196fc03aa1c6e8c1ce16df24e1@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 8bit Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Vipul, --- Vipul Gupta wrote: > If we assume that the LowPAN design this group comes up > with will only need to be revised when a new lower layer > is designed, then yes there is no need for version numbers. > > However, if there's even a small chance that, based on > deployment experience, we may revise the LowPAN > header format while still wanting to run it on top of the > same lower layer then I don't see how the recipient > would figure out how to interpret the received packet > without a version number. From what I can tell, there is Yes, there is that risk. I guess the more complex an encapsulation, the more justifiable it is to have a version field. > no place in the 802.15.4 header to describe the higher > protocol type Correct, 802.15.4-2003 does not. But as an 802 technology, you're supposed to use 802.2 LLC (section 5.3 in the 15.4 spec), which we've abandoned because of its overhead. Instead, we provide our own protocol field within the lowpan layer. > (ethernet, in contrast, does have such a > field). Well, the 802.3-2002 spec talks about a Type/Length field. When one uses the "ethernet II" frame format, this field is interpreted as "Type", so what you say is true. But when you use the other available formats (802.3, 802.2 LLC, SNAP/RFC1042) then this field is interpreted as "Length". In these cases, the ethernet frame does not have such a type field, and this is left to the higher layer encapsulation, e.g., 802.2 LLC or the LLC-derived SNAP encapsulation. Notice that none of the basic ethernet frame, LLC or SNAP have a version field. Our LoWPAN encapsulation is somewhat similar in function to the 802.2 LLC. It is a bit more complex. A much closer analogy is the encapsulation format defined in section 4.2 of the "IPv4 over IEEE 1394" (RFC 2734) spec (not suprisingly, as this was the model for our adaptation layer at the start). Again, this encapsulation does not have a version field either. So I wonder, if a version field was deemed superfluous for all the above encapsulation formats (which did not have the stringent constraints we do), why would it be justified in our case? Our complexity is similar to that of the encapsulation for IEEE 1394. One thing we do in addition to what they do is have a mesh header. Is this additional complexity enough to justify adding a version header? > Perhaps the following example will make things clearer. > Because SSL includes a version number, the IETF was > able to define TLS and now TLS 1.1 without requiring > a new underlying protocol (all versions of SSL and > TLS run atop TCP). Like I said, the more complex an encapsulation, the more chances you'll want a version field in there. For higher layer protocols like HTTP, TLS/SSL, SSH, etc, you definitely want one. No question there. But protocols at those layers are hardly applicable to what we're doing. When I look at what I believe is applicable (frame formats as discussed above), I have not seen version numbers. Perhaps we've just added enough complexity to just tilt the balance enough that we should use one. Not sure yet. I'd certainly like to hear from implementors and people deploying this stuff. I didn't add the version field before this submission cuz I think we need more discussion (and frankly, cuz I didn't have time). Let's discuss some more. > It seems like a prudent tradeoff to me to spend 2 bits > for the ability to later revise LowPAN (based on deployment > experience) without requiring a new lower layer. > > As for the tag size, I think 7 bits is still too low (based on > the previously posted analysis). If the general consensus That analysis is a theoretical one. I'm quite unconvinced that we'll ever hit this in practice given the type of applications that 15.4 is for (after all, the max frame size is remarkably puny). I think before over-engineering this is one point that requires input from folks actually deploying (hopefully comercially) 15.4 networks. > is to bump it to 10 and wait for deployment experience > before changing it to a higher value, that's fine (at current > data rates, 10 bits would allow for a reassembly timeout of > around 8 seconds which might be ok). >From RFC 2734 I note that the 1394 encapsulation uses a datagram tag length of 16 bits. Comparing with the lowest speed or 100Mbps in RFC 2734 (with an MTU of 512 octets), it seems like there's a factor of slightly under 2^8 as compared to 802.15.4's expected max throughput of 125Kbps at 128 octets MTU. If so, and given that 1394 is *MUCH* more probable to transfer long packets than 802.15.4, I'd say for us a datagram tag of 8 bits is at least equivalent (and in reality much safer, given expected usage) than their 16 bits. In keeping with this reasoning, and if we determined that a version field was useful, I'd suggest taking 2 bits from the tag (bumping it down to 8 bits as per the previous paragraph). > In terms of saving bits, supporting short addresses > provides the biggest bang for the buck -- instead > of carrying two 8-byte addresses across each hop > (for a multihop pkt), carrying two 2-byte addresses > saves 96 bits. Compared to this, the extra few > bits spent on the version or the tag are minuscule. Agree, small addresses are the best bang for the buck. The latest version of the draft supports these. But I don't think we can claim that by doing so we are being particularly good citizens. This is a savings enabled fundamentally by the 802.15.4 spec regardless of us. On the contrary, *not* supporting short addresses would have made us bad citizens. We only become good citizens by being careful about the stuff we are adding. That stuff is the fixed overhead in the encapsulation formats. The first version had very little overhead, and we've been growing it slowly. -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 24 19:51:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUC69-0003x7-HF; Mon, 24 Oct 2005 19:51:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUC68-0003wx-8d for 6lowpan@megatron.ietf.org; Mon, 24 Oct 2005 19:51:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06128 for <6lowpan@ietf.org>; Mon, 24 Oct 2005 19:51:10 -0400 (EDT) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUCIr-0006kh-MV for 6lowpan@ietf.org; Mon, 24 Oct 2005 20:04:41 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOW0057C28ZS900@dps.sfvic.sunlabs.com> for 6lowpan@ietf.org; Mon, 24 Oct 2005 16:50:59 -0700 (PDT) Received: from [129.146.73.85] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOW003PG28ZTF40@mail.sunlabs.com> for 6lowpan@ietf.org; Mon, 24 Oct 2005 16:50:59 -0700 (PDT) Date: Mon, 24 Oct 2005 16:51:35 -0700 From: Vipul Gupta Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) In-reply-to: <20051024224437.50799.qmail@web81910.mail.mud.yahoo.com> To: itijibox-6lowpan@yahoo.com Message-id: <03fabd39f242385f557057e94edec9f7@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20051024224437.50799.qmail@web81910.mail.mud.yahoo.com> X-Spam-Score: 2.8 (++) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7BIT 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Gab, I've been thinking some more about the fragmentation issue and have managed to convince myself that the tag size in the latest draft (of 1 byte) is adequate :-) My initial analysis assumed two things: 1. That the application would be pumping a lot of data over a short period of time 2. It would do so using a fairly small packet size that is still large enough to cause fragmentation (e.g. the analysis assumed 128 bytes). We do see 1 on our network already, for example, when over the air reprogramming is involved and we send 10s of KBs of code. However, in such situations, an application is also likely to use large packets -- closer to the 2KB max. (I couldn't think of any realistic situations where 1 and 2 both apply simultaneously). If we change 2 to assume large packets, the analysis changes quite a bit. Assuming 1-2KB packets, 8-bit sequence numbers will roll around only after an application has pumped out 256-512KB of data which, at 250kbits/s (or more realistically ~16KB/s), would take about 16-32 seconds -- reasonable enough for a reassembly timer. In reality, these values might be even higher because few sensors (the Sun SPOT being an exception) have enough memory to buffer 256-512KB of data. vipul On Oct 24, 2005, at 3:44 PM, gabriel montenegro wrote: > Vipul, > > --- Vipul Gupta wrote: >> If we assume that the LowPAN design this group comes up >> with will only need to be revised when a new lower layer >> is designed, then yes there is no need for version numbers. >> >> However, if there's even a small chance that, based on >> deployment experience, we may revise the LowPAN >> header format while still wanting to run it on top of the >> same lower layer then I don't see how the recipient >> would figure out how to interpret the received packet >> without a version number. From what I can tell, there is > > Yes, there is that risk. I guess the more complex an encapsulation, > the more justifiable it is to have a version field. > >> no place in the 802.15.4 header to describe the higher >> protocol type > > Correct, 802.15.4-2003 does not. But as an 802 technology, you're > supposed to use > 802.2 LLC (section 5.3 in the 15.4 spec), which we've abandoned > because of its overhead. > Instead, we provide our own protocol field within the lowpan layer. > >> (ethernet, in contrast, does have such a >> field). > > Well, the 802.3-2002 spec talks about a Type/Length field. > When one uses the "ethernet II" frame format, this field > is interpreted as "Type", so what you say is true. But when you > use the other available formats (802.3, 802.2 LLC, SNAP/RFC1042) > then this field is interpreted as "Length". In these cases, the > ethernet frame does not have such a type field, and this is > left to the higher layer encapsulation, e.g., 802.2 LLC or > the LLC-derived SNAP encapsulation. > > Notice that none of the basic ethernet frame, LLC or SNAP have a > version field. > > Our LoWPAN encapsulation is somewhat similar in function to > the 802.2 LLC. It is a bit more complex. A much closer analogy is the > encapsulation format defined in section 4.2 of the "IPv4 over IEEE > 1394" > (RFC 2734) spec (not suprisingly, as this was the model for our > adaptation > layer at the start). Again, this encapsulation does not have a version > field > either. > > So I wonder, if a version field was deemed superfluous for all the > above > encapsulation formats (which did not have the stringent constraints we > do), > why would it be justified in our case? Our complexity is similar to > that > of the encapsulation for IEEE 1394. One thing we do in addition to > what they > do is have a mesh header. Is this additional complexity enough to > justify adding > a version header? > >> Perhaps the following example will make things clearer. >> Because SSL includes a version number, the IETF was >> able to define TLS and now TLS 1.1 without requiring >> a new underlying protocol (all versions of SSL and >> TLS run atop TCP). > > Like I said, the more complex an encapsulation, the more chances you'll > want a version field in there. For higher layer protocols like HTTP, > TLS/SSL, SSH, etc, you definitely want one. No question there. But > protocols > at those layers are hardly applicable to what we're doing. When I look > at > what I believe is applicable (frame formats as discussed above), I > have not > seen version numbers. Perhaps we've just added enough complexity to > just > tilt the balance enough that we should use one. Not sure yet. I'd > certainly > like to hear from implementors and people deploying this stuff. I > didn't add > the version field before this submission cuz I think we need more > discussion > (and frankly, cuz I didn't have time). > > Let's discuss some more. > >> It seems like a prudent tradeoff to me to spend 2 bits >> for the ability to later revise LowPAN (based on deployment >> experience) without requiring a new lower layer. >> >> As for the tag size, I think 7 bits is still too low (based on >> the previously posted analysis). If the general consensus > > That analysis is a theoretical one. I'm quite unconvinced that we'll > ever hit this in practice given the type of applications that 15.4 is > for (after all, the max frame size is remarkably puny). I think before > over-engineering this is one point that requires input from folks > actually > deploying (hopefully comercially) 15.4 networks. > >> is to bump it to 10 and wait for deployment experience >> before changing it to a higher value, that's fine (at current >> data rates, 10 bits would allow for a reassembly timeout of >> around 8 seconds which might be ok). > > From RFC 2734 I note that the 1394 encapsulation uses a datagram tag > length of 16 bits. > Comparing with the lowest speed or 100Mbps in RFC 2734 (with an MTU of > 512 octets), it > seems like there's a factor of slightly under 2^8 as compared to > 802.15.4's > expected max throughput of 125Kbps at 128 octets MTU. If so, and given > that > 1394 is *MUCH* more probable to transfer long packets than 802.15.4, > I'd say for us a datagram tag of 8 bits is at least equivalent (and in > reality much safer, given expected usage) than their 16 bits. > > In keeping with this reasoning, and if we determined that a version > field was useful, > I'd suggest taking 2 bits from the tag (bumping it down to 8 bits as > per the previous > paragraph). > >> In terms of saving bits, supporting short addresses >> provides the biggest bang for the buck -- instead >> of carrying two 8-byte addresses across each hop >> (for a multihop pkt), carrying two 2-byte addresses >> saves 96 bits. Compared to this, the extra few >> bits spent on the version or the tag are minuscule. > > Agree, small addresses are the best bang for the buck. The latest > version of > the draft supports these. But I don't think we can claim that by doing > so we > are being particularly good citizens. This is a savings enabled > fundamentally by the 802.15.4 spec regardless of us. > > On the contrary, *not* supporting short addresses > would have made us bad citizens. We only become good citizens by being > careful about the > stuff we are adding. That stuff is the fixed overhead in the > encapsulation formats. > The first version had very little overhead, and we've been growing it > slowly. > > -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 25 02:36:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUIQ7-00039w-BT; Tue, 25 Oct 2005 02:36:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUIQ4-00036j-RZ for 6lowpan@megatron.ietf.org; Tue, 25 Oct 2005 02:36:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24500 for <6lowpan@ietf.org>; Tue, 25 Oct 2005 02:36:10 -0400 (EDT) Received: from web81901.mail.mud.yahoo.com ([68.142.207.180]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUIcw-00085H-T3 for 6lowpan@ietf.org; Tue, 25 Oct 2005 02:49:45 -0400 Received: (qmail 47249 invoked by uid 60001); 25 Oct 2005 06:36:13 -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:Content-Transfer-Encoding; b=Wk9uAtshgw5f/nwER0QqhDeRIkJtEB02srqYdmxgZI65/dX9RPrNc0Qa9nqefm+pS/cq4brj+PTb8zlWM0IUUjigP7z4uSdtJqdoG0ICWDpq+Gd/N65sAxccUa5oUeckzwl/4ZvY/AjdZ4Ch96y3FyG8tKuU+hbfc18jj6ncKbw= ; Message-ID: <20051025063613.47247.qmail@web81901.mail.mud.yahoo.com> Received: from [24.16.92.216] by web81901.mail.mud.yahoo.com via HTTP; Mon, 24 Oct 2005 23:36:13 PDT Date: Mon, 24 Oct 2005 23:36:13 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt) To: Vipul Gupta , itijibox-6lowpan@yahoo.com In-Reply-To: <03fabd39f242385f557057e94edec9f7@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Good points, thanks Vipul. Just to clarify, the latest draft (the one submitted) has a tag field of 10 bits, no 8. By the way, I added a retransmission timeout of 15 sec (took it out of a hat). Seems to be reasonable, in particular seeing your calculations below. But please check and comment. -gabriel --- Vipul Gupta wrote: > Hi Gab, > > I've been thinking some more about the fragmentation issue and > have managed to convince myself that the tag size in the latest draft > (of 1 byte) is adequate :-) My initial analysis assumed two things: > > 1. That the application would be pumping a lot of data > over a short period of time > > 2. It would do so using a fairly small packet size that is still > large enough to cause fragmentation (e.g. the analysis > assumed 128 bytes). > > We do see 1 on our network already, for example, when over the > air reprogramming is involved and we send 10s of KBs of code. > However, in such situations, an application is also likely to use > large packets -- closer to the 2KB max. (I couldn't think of any > realistic situations where 1 and 2 both apply simultaneously). > > If we change 2 to assume large packets, the analysis changes > quite a bit. Assuming 1-2KB packets, 8-bit sequence numbers > will roll around only after an application has pumped out > 256-512KB of data which, at 250kbits/s (or more realistically > ~16KB/s), would take about 16-32 seconds -- reasonable > enough for a reassembly timer. In reality, these values might be > even higher because few sensors (the Sun SPOT being an exception) > have enough memory to buffer 256-512KB of data. > > vipul > > On Oct 24, 2005, at 3:44 PM, gabriel montenegro wrote: > > > Vipul, > > > > --- Vipul Gupta wrote: > >> If we assume that the LowPAN design this group comes up > >> with will only need to be revised when a new lower layer > >> is designed, then yes there is no need for version numbers. > >> > >> However, if there's even a small chance that, based on > >> deployment experience, we may revise the LowPAN > >> header format while still wanting to run it on top of the > >> same lower layer then I don't see how the recipient > >> would figure out how to interpret the received packet > >> without a version number. From what I can tell, there is > > > > Yes, there is that risk. I guess the more complex an encapsulation, > > the more justifiable it is to have a version field. > > > >> no place in the 802.15.4 header to describe the higher > >> protocol type > > > > Correct, 802.15.4-2003 does not. But as an 802 technology, you're > > supposed to use > > 802.2 LLC (section 5.3 in the 15.4 spec), which we've abandoned > > because of its overhead. > > Instead, we provide our own protocol field within the lowpan layer. > > > >> (ethernet, in contrast, does have such a > >> field). > > > > Well, the 802.3-2002 spec talks about a Type/Length field. > > When one uses the "ethernet II" frame format, this field > > is interpreted as "Type", so what you say is true. But when you > > use the other available formats (802.3, 802.2 LLC, SNAP/RFC1042) > > then this field is interpreted as "Length". In these cases, the > > ethernet frame does not have such a type field, and this is > > left to the higher layer encapsulation, e.g., 802.2 LLC or > > the LLC-derived SNAP encapsulation. > > > > Notice that none of the basic ethernet frame, LLC or SNAP have a > > version field. > > > > Our LoWPAN encapsulation is somewhat similar in function to > > the 802.2 LLC. It is a bit more complex. A much closer analogy is the > > encapsulation format defined in section 4.2 of the "IPv4 over IEEE > > 1394" > > (RFC 2734) spec (not suprisingly, as this was the model for our > > adaptation > > layer at the start). Again, this encapsulation does not have a version > > field > > either. > > > > So I wonder, if a version field was deemed superfluous for all the > > above > > encapsulation formats (which did not have the stringent constraints we > > do), > > why would it be justified in our case? Our complexity is similar to > > that > > of the encapsulation for IEEE 1394. One thing we do in addition to > > what they > > do is have a mesh header. Is this additional complexity enough to > > justify adding > > a version header? > > > >> Perhaps the following example will make things clearer. > >> Because SSL includes a version number, the IETF was > >> able to define TLS and now TLS 1.1 without requiring > >> a new underlying protocol (all versions of SSL and > >> TLS run atop TCP). > > > > Like I said, the more complex an encapsulation, the more chances you'll > > want a version field in there. For higher layer protocols like HTTP, > > TLS/SSL, SSH, etc, you definitely want one. No question there. But > > protocols > > at those layers are hardly applicable to what we're doing. When I look > > at > > what I believe is applicable (frame formats as discussed above), I > > have not > > seen version numbers. Perhaps we've just added enough complexity to > > just > > tilt the balance enough that we should use one. Not sure yet. I'd > > certainly > > like to hear from implementors and people deploying this stuff. I > > didn't add > > the version field before this submission cuz I think we need more > > discussion > > (and frankly, cuz I didn't have time). > > > > Let's discuss some more. > > > >> It seems like a prudent tradeoff to me to spend 2 bits > >> for the ability to later revise LowPAN (based on deployment > >> experience) without requiring a new lower layer. > >> > >> As for the tag size, I think 7 bits is still too low (based on > >> the previously posted analysis). If the general consensus > > > > That analysis is a theoretical one. I'm quite unconvinced that we'll > > ever hit this in practice given the type of applications that 15.4 is > > for (after all, the max frame size is remarkably puny). I think before > > over-engineering this is one point that requires input from folks > > actually > > deploying (hopefully comercially) 15.4 networks. > > > >> is to bump it to 10 and wait for deployment experience > >> before changing it to a higher value, that's fine (at current > >> data rates, 10 bits would allow for a reassembly timeout of > >> around 8 seconds which might be ok). > > > > From RFC 2734 I note that the 1394 encapsulation uses a datagram tag > > length of 16 bits. > > Comparing with the lowest speed or 100Mbps in RFC 2734 (with an MTU of > > 512 octets), it > > seems like there's a factor of slightly under 2^8 as compared to > > 802.15.4's > > expected max throughput of 125Kbps at 128 octets MTU. If so, and given > > that > > 1394 is *MUCH* more probable to transfer long packets than 802.15.4, > > I'd say for us a datagram tag of 8 bits is at least equivalent (and in > > reality much safer, given expected usage) than their 16 bits. > > > > In keeping with this reasoning, and if we determined that a version > > field was useful, > > I'd suggest taking 2 bits from the tag (bumping it down to 8 bits as > > per the previous > > paragraph). > > > >> In terms of saving bits, supporting short addresses > >> provides the biggest bang for the buck -- instead > >> of carrying two 8-byte addresses across each hop > >> (for a multihop pkt), carrying two 2-byte addresses > >> saves 96 bits. Compared to this, the extra few > >> bits spent on the version or the tag are minuscule. > > > > Agree, small addresses are the best bang for the buck. The latest > > version of > > the draft supports these. But I don't think we can claim that by doing > > so we > > are being particularly good citizens. This is a savings enabled > > fundamentally by the 802.15.4 spec regardless of us. > > > > On the contrary, *not* supporting short addresses > > would have made us bad citizens. We only become good citizens by being > > careful about the > > stuff we are adding. That stuff is the fixed overhead in the > > encapsulation formats. > > The first version had very little overhead, and we've been growing it > > slowly. > > > > -gabriel > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 26 18:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu6L-0000dM-AJ; Wed, 26 Oct 2005 18:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu5s-0000So-VI for 6lowpan@megatron.ietf.org; Wed, 26 Oct 2005 18:50:05 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02292 for <6lowpan@lists.ietf.org>; Wed, 26 Oct 2005 18:49:47 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5r-0005eJ-A2; Wed, 26 Oct 2005 18:50:03 -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, 26 Oct 2005 18:50:03 -0400 Cc: 6lowpan@ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-problem-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org 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-01.txt Pages : 12 Date : 2005-10-26 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-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-6lowpan-problem-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-6lowpan-problem-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2005-10-26183806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-problem-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-problem-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26183806.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 Oct 26 23:15:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyEy-0006N0-BA; Wed, 26 Oct 2005 23:15:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyEw-0006M2-28 for 6lowpan@megatron.ietf.org; Wed, 26 Oct 2005 23:15:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18557 for <6lowpan@ietf.org>; Wed, 26 Oct 2005 23:15:25 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUySB-0004mu-NZ for 6lowpan@ietf.org; Wed, 26 Oct 2005 23:29:25 -0400 Received: from ep_mmp1 (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 <0IP000G3J11CUL@mailout2.samsung.com> for 6lowpan@ietf.org; Thu, 27 Oct 2005 12:15:12 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IP000FL111CVI@mmp1.samsung.com> for 6lowpan@ietf.org; Thu, 27 Oct 2005 12:15:12 +0900 (KST) Date: Thu, 27 Oct 2005 12:16:43 +0900 From: Soohong Daniel Park To: 6lowpan@ietf.org Message-id: <02fc01c5daa4$db7225f0$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7BIT Cc: Subject: [6lowpan] Comments on I-D ACTION:draft-ietf-6lowpan-problem-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Nandu, thanks your good job and here is my smalls nits though. Typo: In Abstract s/problem/problems In Security Considerations s/6LoWPAN/LoWPAN (Throughout the draft, LoWPAN terminology is in use except here, so LoWPAN would be fine) s/prevelant/prevalent s/compramise/compromise Comment: In Security Considerations, you are refering to AES for 802.15.4 secured mode amongst three security modes (unsecured, ACL and secured). To understand AES easily, please add a new reference into the References Section as follows; [AES] National Institute of Standards and Technology. FIPS Pub 197: Advanced Encryption Standard (AES). 26 November 2001. Discussion: >7. Security Considerations. > >IEEE 802.15.4 provides AES link layer security. As 6LoWPAN imposes >unique set of challenges that are not prevelant in classical >etworks, security threats across various layers should first be >understood before choosing any security protocol. >Furthermore, these >devices may not have any front end to do configuration and >management. As such protocols must be chosen to have very little >configuration and management, but still not compramise on either >connectivity nor security. It seems not clear for me. As you pointed out, the sentences above should be further study before addressing anything. So, I am suggesting not to add these text at this stage... Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 27 02:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV1aP-0007ky-7p; Thu, 27 Oct 2005 02:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV1aM-0007jj-TM for 6lowpan@megatron.ietf.org; Thu, 27 Oct 2005 02:50:03 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28113 for <6lowpan@lists.ietf.org>; Thu, 27 Oct 2005 02:49:47 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV1aM-00072B-Ao; Thu, 27 Oct 2005 02:50:02 -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: Thu, 27 Oct 2005 02:50:02 -0400 Cc: 6lowpan@ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org 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 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks Author(s) : G. Montenegro, N. Kushalnagar Filename : draft-ietf-6lowpan-format-01.txt Pages : 25 Date : 2005-10-26 This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-6lowpan-format-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-6lowpan-format-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2005-10-26193035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26193035.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--