From 6lowpan-bounces@ietf.org Tue Sep 05 09:47:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKbGj-0008PB-4u; Tue, 05 Sep 2006 09:47:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKbGh-0008P0-DI for 6lowpan@lists.ietf.org; Tue, 05 Sep 2006 09:47:11 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKbGf-00061V-2X for 6lowpan@lists.ietf.org; Tue, 05 Sep 2006 09:47:11 -0400 Received: from dellx1.coslabs.com (dellx1.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k85DkvRN022219 for <6lowpan@lists.ietf.org>; Tue, 5 Sep 2006 07:46:57 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Tue, 05 Sep 2006 07:46:52 -0600 Message-Id: <1157464012.5164.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [6lowpan] Minutes from last WG meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Folks, The minutes from the last working group meeting have been posted to the wiki: http://www3.ietf.org/proceedings/06jul/minutes/6lowpan.txt Please review the minutes and let me know if there are any changes needed before we post these to the IETF WG site. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Sep 07 04:42:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLFT6-0006q5-LX; Thu, 07 Sep 2006 04:42:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLFT5-0006pz-3I for 6lowpan@ietf.org; Thu, 07 Sep 2006 04:42:39 -0400 Received: from web81908.mail.mud.yahoo.com ([68.142.207.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLFT4-0004ui-Ga for 6lowpan@ietf.org; Thu, 07 Sep 2006 04:42:39 -0400 Received: (qmail 60900 invoked by uid 60001); 7 Sep 2006 08:42:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iGr3YSDeviOsQ8BBLwhvdmQ6bEs7fP4uBnqBa5AGgmeDt0XJJLl9DNfSX/W7cWU1BkD6xzvXoFC9hBayoj8E7uFKLfh07cnQUP82pAV6C+fM1h8UPK1Sg36HaZK7YdikM90hibGOkq9F9f5HzewBEn4IO41amuXUWl4sRrflVgE= ; Message-ID: <20060907084238.60898.qmail@web81908.mail.mud.yahoo.com> Received: from [131.107.0.104] by web81908.mail.mud.yahoo.com via HTTP; Thu, 07 Sep 2006 01:42:38 PDT Date: Thu, 7 Sep 2006 01:42:38 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 To: gabriel montenegro , Mario Mao In-Reply-To: <20060808155624.6074.qmail@web81908.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1384359028==" Errors-To: 6lowpan-bounces@ietf.org --===============1384359028== Content-Type: multipart/alternative; boundary="0-1622548545-1157618557=:56892" --0-1622548545-1157618557=:56892 Content-Type: text/plain; charset=us-ascii Since there has been no feedback on this, I will go with option #4 below unless I hear otherwise within the next few days. We can always revisit this during IETF LC. But if we make no decision we will never get to IETF LC. -gabriel ----- Original Message ---- From: gabriel montenegro To: Mario Mao Cc: 6lowpan@ietf.org Sent: Tuesday, August 8, 2006 8:56:24 AM Subject: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 Good point, yes. The confusion is that upon reception it is not easy to determine which of the two following mesh header formats is being used because the fixed part of the header does not tell us: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|F| Hops Left | Originator Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...Final Destination Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Mesh Delivery Field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|F| Hops Left |Sequence Number| Originator Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...Final Destination Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Mesh Broadcast or Multicast Delivery Field We could put the indication in the fixed part of the header by : 1. adding a bit field to distinguish. Two alternatives: (a) We could add one bit and move everything after it over one bit. Not that our alignment was great to begin with, but this would make it uglier. (b) We could make this bit field larger than 1 bit, in which case we'd be able to distinguish between the two current formats and leave some bit patterns reserved in case we end up defining other mesh headers in the future. 2. adding a bit by stealing one from, say, hops_left. This means we'd have a max of 32 hops instead of the current 64. I still think this is enough. This would not alter whatever alignment we now have. 3. Grow the 'F' field by one more bit, and assign bit patterns for 64 bit address, 16-bit address and 16-bit bcast/mcast address (as per the current draft). This would leave one bit pattern reserved. 4. Move the distinguishing field, "Final Destination Address" into the fixed part of the header (right after hops_left). Sequence number and originator address would relocate after final destination address. This does not waste any bits, but is esthetically unpleasant. But we may not care about such things. Any others? Comments? Would the folks who are implementing this please express their opinions? -gabriel ----- Original Message ---- From: Mario Mao To: gabriel montenegro Cc: 6lowpan@ietf.org Sent: Saturday, August 5, 2006 2:52:52 AM Subject: Some comments about draft-ietf-6lowpan-format-04 Hi Gabriel, There is some comments about the last draft, thanks. In Section 11, the draft mentions that a special format of "Mesh Delivery" field should be used when Broadcast or Multicast. This kind of field is called as Mesh Broadcast or Multicast Delivery Field and a "Sequence Number" is added. For Source Node, it will be clear that which kind of format it should use. But for Destination Node or Relay Node, looks like there will be some confusion when they trying to explain this format. The cause of such confusion is the way inbound Node identifying such kind of field format. As the draft mentioned, the destination address is the identification of such kind of field. However, for the Final Destination Address is behind the Sequence Number, the inbound Node will be unaware of the existence of this field before it check the Final Destination Address. If inbound Node handle all Broadcast Delivery Field as the normal "Mesh Delivery" field, when it begins to check the Final Destination Address, there will be 8-bits shift of the right position. This scenario must lead to an mistake. There is also another way to identify the Broadcast Delivery Field. That is checking the destination MAC address in the IEEE 802.15.4 header (0xFFFF). But in practice, an IEEE 802.15.4 broadcast frame can't be delivered to every END DEVICE (RFD). This is because the END DEVICE disable its transceiver during CAP when there is no frame directly sent to it. To avoid such incorrect scenario, one flag may be needed in the fixed filed (in Adaptation Header). That make all node could recognize the special Broadcast Delivery Field in right way. Regards, Mario Mao MarioMao@Gmail.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-1622548545-1157618557=:56892 Content-Type: text/html; charset=us-ascii
Since there has been no feedback on this, I will go with option #4 below unless I hear otherwise within the next few
days. We can always revisit this during IETF LC. But if we make no decision we will never get to IETF LC.
 
-gabriel

----- Original Message ----
From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
To: Mario Mao <mariomao@gmail.com>
Cc: 6lowpan@ietf.org
Sent: Tuesday, August 8, 2006 8:56:24 AM
Subject: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04

Good point, yes. The confusion is that upon reception it is not easy to determine which of the two following mesh header formats is being used because
the fixed part of the header does not tell us:

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |O|F| Hops Left |            Originator Address...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ...Final Destination Address
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 10: Mesh Delivery
 Field

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |O|F| Hops Left |Sequence Number|     Originator Address...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ...Final Destination Address
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 11: Mesh Broadcast or Multicast Delivery Field
We could put the indication in the fixed part of the header by :

1. adding a bit field to distinguish. Two alternatives: (a) We could add one bit and move everything after it over one bit. Not that our alignment was
    great to begin with, but this would make it uglier. (b) We could make this bit field larger than 1 bit, in which case we'd be able
    to distinguish between the two current formats and leave some bit patterns reserved in case we end up defining other
    mesh headers in the future.
2. adding a bit by stealing one from, say, hops_left. This means we'd have a max of 32 hops instead of the current 64. I still think this
    is enough. This would not alter whatever alignment we now have.
3. Grow the 'F' field by one more bit, and assign bit patterns for 64 bit address, 16-bit address and 16-bit bcast/mcast address (as per
    the current draft).
    This would leave one bit pattern reserved.
4. Move the distinguishing field, "Final Destination Address" into the fixed part of the header (right after hops_left). Sequence number and originator
    address would relocate after final destination address. This does not waste any bits, but is esthetically unpleasant. But we may not care about such
    things.

Any others?

Comments? Would the folks who are implementing this please express their opinions?

-gabriel

----- Original Message ----
From: Mario Mao <mariomao@gmail.com>
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Cc: 6lowpan@ietf.org
Sent: Saturday, August 5, 2006 2:52:52 AM
Subject: Some comments about draft-ietf-6lowpan-format-04

Hi Gabriel,
 
There is some comments about the last draft, thanks.
 
In Section 11, the draft mentions that a special format of "Mesh Delivery" field should be used when Broadcast or Multicast. This kind of field is called as Mesh Broadcast or Multicast Delivery Field and a "Sequence Number" is added.
 
For Source Node, it will be clear that which kind of format it should use. But for Destination Node or Relay Node, looks like there will be some confusion when they trying to explain this format.
 
The cause of such confusion is the way inbound Node identifying such kind of field format. As the draft mentioned, the destination address is the identification of such kind of field. However, for the Final Destination Address is behind the Sequence Number, the inbound Node will be unaware of the existence of this field before it check the Final Destination Address. If inbound Node handle all Broadcast Delivery Field as the normal "Mesh Delivery" field, when it begins to check the Final Destination Address, there will be 8-bits shift of the right position. This scenario must lead to an mistake.
 
There is also another way to identify the Broadcast Delivery Field. That is checking the destination MAC address in the IEEE 802.15.4 header (0xFFFF). But in practice, an IEEE 802.15.4 broadcast frame can't be delivered to every END DEVICE (RFD). This is because the END DEVICE disable its transceiver during CAP when there is no frame directly sent to it.
 
To avoid such incorrect scenario, one flag may be needed in the fixed filed (in Adaptation Header). That make all node could recognize the special Broadcast Delivery Field in right way.
 
Regards,

Mario Mao
                                       

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

--0-1622548545-1157618557=:56892-- --===============1384359028== 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 --===============1384359028==-- From 6lowpan-bounces@ietf.org Thu Sep 07 08:25:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLIwp-0006gm-Nf; Thu, 07 Sep 2006 08:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLIwo-0006gh-Cn for 6lowpan@ietf.org; Thu, 07 Sep 2006 08:25:34 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLIwn-00021s-Aa for 6lowpan@ietf.org; Thu, 07 Sep 2006 08:25:34 -0400 Received: by py-out-1112.google.com with SMTP id e30so236284pya for <6lowpan@ietf.org>; Thu, 07 Sep 2006 05:25:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:to:cc:references:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole:from; b=Jz8lTjdVdLMvSUm6/mPPrb1imXVI0gRLf8idD0jXo2gDwE/ey3/9Tlhw5a401P7rGiB3MHyCMxb1aAYtdZetnUP+ruU4sg5YPQ1VngyNW93y1DIzYb0DNl6KmdCRoYKOcU1dh5+pV0qtvBsA2eiPwuCa/mQRmaCWc/BlDV5RGZY= Received: by 10.35.84.12 with SMTP id m12mr601015pyl; Thu, 07 Sep 2006 05:25:32 -0700 (PDT) Received: from Maoer ( [211.144.102.60]) by mx.gmail.com with ESMTP id m2sm643402nzf.2006.09.07.05.25.30; Thu, 07 Sep 2006 05:25:32 -0700 (PDT) Message-ID: <007001c6d279$90ade8b0$7fc0a8c0@netlab.cs.ecnu.edu.cn> To: "gabriel montenegro" References: <20060907084238.60898.qmail@web81908.mail.mud.yahoo.com> Subject: Re: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 Date: Thu, 7 Sep 2006 20:31:34 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1807 From: Mario Mao X-Spam-Score: 1.2 (+) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0718994183==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0718994183== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C6D2BC.9C890D70" This is a multi-part message in MIME format. ------=_NextPart_000_006D_01C6D2BC.9C890D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgR2FicmllbCwNCg0KU29ycnkgZm9yIHRoZSBkZWxheSwgaGVyZSBhcmUgc29tZSBjb21tZW50 cyBhYm91dCB0aGUgbmV3bHkgbW9kaWZpZWQgQnJvYWRjYXN0IGZpZWxkLCB0aGFua3MuDQoNCkFi b3V0IHRoZSBvcHRpb24gIzQsIEkgdGhpbmsgaXQgaXMgYSBnb29kIHdheSB0byBzb2x2ZSB0aGUg Y29uZnVzaW9uLiBJbiBhZGRpdGlvbiwgaGVyZSBpcyB0aGUgd2F5IHdlIHVzZWQsIGhvcGUgaXQg Y291bGQgZG8gc29tZSBoZWxwLCB0aGFua3MuDQoNCkkgcmVtZW1iZXIgSSBoYWQgc3VnZ2VzdGVk IGEgd2F5IG9mIGludHJvZHVjaW5nIGEgIk0iIGJpdCB3aGljaCBpbmRpY2F0ZXMgTWVzaCBCcm9h ZGNhc3Qgb3IgTXVsdGljYXN0IERlbGl2ZXJ5IEZpZWxkIGltbWVkaWF0ZWx5IGZvbGxvd2luZyB0 aGUgTG9XUEFOIGhlYWRlci4gVGhlICJNIiB3aWxsIHVzZSBvbmUgb2YgdGhlIDQgcnN2IGJpdHMg aW4gZml4ZWQgaGVhZGVyIGFuZCBub3QgYWZmZWN0IHRoZSBhbGlnbm1lbnQuDQoNCiAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDENCiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KIHwgTEZ8ICBwcm90X3R5cGUgICAgfE18QnwgcnN2ICAgfFBheWxvYWQg KE1lc2ggQi9NIEZpZWxkKS4uLg0KICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCldoZW4gZW5jb3VudGVyaW5nIGFkYXB0 YXRpb24gbGF5ZXIgZnJhZ21lbnQsIG5vIG1vcmUgYml0IGFyZSBmcmVlIGZvciB0aGUgc3BlY2lh bCBiaXQuIEhvd2V2ZXIsIHdlIGZpbmQgaXQncyBhIG5pZ2h0bWFyZSB0byBicm9hZGNhc3QgZnJh Z21lbnRzIGluIGFjdHVhbCA4MDIuMTUuNCBuZXR3b3JrLiBUaGUgd29ya2luZyBjaGFubmVsIHdv dWxkIGJlIGZ1bGwgb2YgYnJvYWRjYXN0IGZyYWdtZW50cyBldmVuIHVzaW5nIGtpbmRzIG9mIG9w dGltaXplZCBhbGdvcml0aG0gYW5kIHRoZSByZXN1bHQgaXMgaGlnaCBwb3NzaWJpbGl0eSBvZiBk aXNjYXJkaW5nIGFuZCByZS10cmFuc21pdHRpbmcsIGFuZCBoaWdoIGVuZXJneS1jb3N0IC4gU28s IHRvIGF2b2lkIHN1Y2ggc2l0dWF0aW9uLCB3ZSBkZWNpZGUgdG8gZGlzYWJsZSBicm9hZGNhc3Qg d2hlbiB0aGUgcGFja2V0IG5lZWQgdG8gYmUgZnJhZ21lbnRlZCBpbnRvIHNldmVyYWwgZnJhbWVz ICh1Z2x5IGJ1dCB1c2VmdWwgd2F5KS4gV2l0aCB0aGlzIHN0cmF0ZWd5LCBubyBtb2RpZmljYXRp b24gdG8gdGhlIGZyYWdtZW50IGVuY2Fwc3VsYXRpb24gaGVhZGVyIGZvcm1hdCBpcyBuZWVkZWQg dG9vLg0KDQpBdCBsYXN0LCBJIGZpbmQgc29tZSBwcm9ibGVtIHdoZW4gaW1wbGltZW50IElQdjYg aGVhZGVyIGNvbXByZXNzaW9uLiBQbGVhc2Ugbm90ZSBUcmFmZmljIENsYXNzIGFuZCBGbG93IExh YmVsIGJpdCBpbiBIQzEuIElmIHdlIGRvbid0IGNvbXByZXNzIHRoZSB0d28gZmllbGQsIDI4IGJp dHMgKHRoYXQgaXMgdGhyZWUgYW5kIGhhbGYgYnl0ZXMpIGFyZSBzZW50LiBIb3dldmVyLCBob3cg dG8gc2VuZCB0aGUgaGFsZiBieXRlPyBBcyBJIGtub3csIG1vc3QgaGFyZHdhcmUgY291bGQgb25s eSB0cmFuc21pdCBkYXRhIGluIHVuaXQgb2YgQllURS4gU2hvdWxkIHdlIG5lZWQgNCBiaXRzIHBl bmRpbmcgZGF0YT8gVGhlIHdvcmtkYXJvdW5kIHdlIHVzZWQgaXMgY29tYmluaW5nIHRoZSBUcmFm ZmljIENsYXNzIGFuZCBGbG93IExhYmVsIHdpdGggVmVyc2lvbiBmaWVsZC4gU28sIHRoZSBUcmFm ZmljIENsYXNzIGFuZCBGbG93IExhYmVsIGJpdCBiZWNvbWVzIFZlcnNpb24sIFRyYWZmaWMgQ2xh c3MgYW5kIEZsb3cgTGFiZWwgYml0LiBQbGVhc2Ugc2VlIGZvbGxvd2luZyBhcyBkZXRhaWwuDQoN ClZlcnNpb24sIFRyYWZmaWMgQ2xhc3MgYW5kIEZsb3cgTGFiZWwgKGJpdCA0KToNCjA6IG5vdCBj b21wcmVzc2VkLCBmdWxsIDQgYml0cyBmb3IgVmVyc2lvbiwgOCBiaXRzIGZvciBUcmFmZmljIENs YXNzIGFuZCAyMCBiaXRzIGZvciBGbG93IExhYmVsIGFyZSBzZW50DQoxOiBUcmFmZmljIENsYXNz IGFuZCBGbG93IExhYmVsIGFyZSB6ZXJvDQoNCkJlc3QgUmVnYXJkcywNCg0KTWFyaW8gTWFvDQog IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IGdhYnJpZWwgbW9udGVuZWdy byANCiAgVG86IGdhYnJpZWwgbW9udGVuZWdybyA7IE1hcmlvIE1hbyANCiAgQ2M6IDZsb3dwYW5A aWV0Zi5vcmcgDQogIFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDcsIDIwMDYgNDo0MiBQTQ0K ICBTdWJqZWN0OiBSZTogWzZsb3dwYW5dIFJlOiBTb21lIGNvbW1lbnRzIGFib3V0IGRyYWZ0LWll dGYtNmxvd3Bhbi1mb3JtYXQtMDQNCg0KDQogIFNpbmNlIHRoZXJlIGhhcyBiZWVuIG5vIGZlZWRi YWNrIG9uIHRoaXMsIEkgd2lsbCBnbyB3aXRoIG9wdGlvbiAjNCBiZWxvdyB1bmxlc3MgSSBoZWFy IG90aGVyd2lzZSB3aXRoaW4gdGhlIG5leHQgZmV3DQogIGRheXMuIFdlIGNhbiBhbHdheXMgcmV2 aXNpdCB0aGlzIGR1cmluZyBJRVRGIExDLiBCdXQgaWYgd2UgbWFrZSBubyBkZWNpc2lvbiB3ZSB3 aWxsIG5ldmVyIGdldCB0byBJRVRGIExDLg0KDQogIC1nYWJyaWVsDQoNCg0KICAtLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0NCiAgRnJvbTogZ2FicmllbCBtb250ZW5lZ3JvIDxnYWJyaWVsX21v bnRlbmVncm9fMjAwMEB5YWhvby5jb20+DQogIFRvOiBNYXJpbyBNYW8gPG1hcmlvbWFvQGdtYWls LmNvbT4NCiAgQ2M6IDZsb3dwYW5AaWV0Zi5vcmcNCiAgU2VudDogVHVlc2RheSwgQXVndXN0IDgs IDIwMDYgODo1NjoyNCBBTQ0KICBTdWJqZWN0OiBbNmxvd3Bhbl0gUmU6IFNvbWUgY29tbWVudHMg YWJvdXQgZHJhZnQtaWV0Zi02bG93cGFuLWZvcm1hdC0wNA0KDQoNCiAgR29vZCBwb2ludCwgeWVz LiBUaGUgY29uZnVzaW9uIGlzIHRoYXQgdXBvbiByZWNlcHRpb24gaXQgaXMgbm90IGVhc3kgdG8g ZGV0ZXJtaW5lIHdoaWNoIG9mIHRoZSB0d28gZm9sbG93aW5nIG1lc2ggaGVhZGVyIGZvcm1hdHMg aXMgYmVpbmcgdXNlZCBiZWNhdXNlDQogIHRoZSBmaXhlZCBwYXJ0IG9mIHRoZSBoZWFkZXIgZG9l cyBub3QgdGVsbCB1czoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAxICAgICAgICAg ICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KyAgICAgIHxPfEZ8IEhvcHMgTGVmdCB8ICAgICAgICAgICAgT3JpZ2luYXRvciBBZGRyZXNzLi4u ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsgICAgICAgICAuLi5GaW5hbCBEZXN0aW5hdGlvbiBBZGRyZXNzICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDEwOiBNZXNoIERlbGl2ZXJ5DQog RmllbGQNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAy ICAgICAgICAgICAgICAgICAgIDMgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAgICB8T3xG fCBIb3BzIExlZnQgfFNlcXVlbmNlIE51bWJlcnwgICAgIE9yaWdpbmF0b3IgQWRkcmVzcy4uLiAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rICAgICAgICAgLi4uRmluYWwgRGVzdGluYXRpb24gQWRkcmVzcyAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rICAgICAgICAgICBGaWd1cmUgMTE6IE1lc2ggQnJvYWRjYXN0IG9yIE11bHRpY2FzdCBE ZWxpdmVyeSBGaWVsZFdlIGNvdWxkIHB1dCB0aGUgaW5kaWNhdGlvbiBpbiB0aGUgZml4ZWQgcGFy dCBvZiB0aGUgaGVhZGVyIGJ5IDoNCg0KICAxLiBhZGRpbmcgYSBiaXQgZmllbGQgdG8gZGlzdGlu Z3Vpc2guIFR3byBhbHRlcm5hdGl2ZXM6IChhKSBXZSBjb3VsZCBhZGQgb25lIGJpdCBhbmQgbW92 ZSBldmVyeXRoaW5nIGFmdGVyIGl0IG92ZXIgb25lIGJpdC4gTm90IHRoYXQgb3VyIGFsaWdubWVu dCB3YXMNCiAgICAgIGdyZWF0IHRvIGJlZ2luIHdpdGgsIGJ1dCB0aGlzIHdvdWxkIG1ha2UgaXQg dWdsaWVyLiAoYikgV2UgY291bGQgbWFrZSB0aGlzIGJpdCBmaWVsZCBsYXJnZXIgdGhhbiAxIGJp dCwgaW4gd2hpY2ggY2FzZSB3ZSdkIGJlIGFibGUgDQogICAgICB0byBkaXN0aW5ndWlzaCBiZXR3 ZWVuIHRoZSB0d28gY3VycmVudCBmb3JtYXRzIGFuZCBsZWF2ZSBzb21lIGJpdCBwYXR0ZXJucyBy ZXNlcnZlZCBpbiBjYXNlIHdlIGVuZCB1cCBkZWZpbmluZyBvdGhlciAuDQogICAgICBtZXNoIGhl YWRlcnMgaW4gdGhlIGZ1dHVyZS4NCiAgMi4gYWRkaW5nIGEgYml0IGJ5IHN0ZWFsaW5nIG9uZSBm cm9tLCBzYXksIGhvcHNfbGVmdC4gVGhpcyBtZWFucyB3ZSdkIGhhdmUgYSBtYXggb2YgMzIgaG9w cyBpbnN0ZWFkIG9mIHRoZSBjdXJyZW50IDY0LiBJIHN0aWxsIHRoaW5rIHRoaXMNCiAgICAgIGlz IGVub3VnaC4gVGhpcyB3b3VsZCBub3QgYWx0ZXIgd2hhdGV2ZXIgYWxpZ25tZW50IHdlIG5vdyBo YXZlLg0KICAzLiBHcm93IHRoZSAnRicgZmllbGQgYnkgb25lIG1vcmUgYml0LCBhbmQgYXNzaWdu IGJpdCBwYXR0ZXJucyBmb3IgNjQgYml0IGFkZHJlc3MsIDE2LWJpdCBhZGRyZXNzIGFuZCAxNi1i aXQgYmNhc3QvbWNhc3QgYWRkcmVzcyAoYXMgcGVyDQogICAgICB0aGUgY3VycmVudCBkcmFmdCku IA0KICAgICAgVGhpcyB3b3VsZCBsZWF2ZSBvbmUgYml0IHBhdHRlcm4gcmVzZXJ2ZWQuDQogIDQu IE1vdmUgdGhlIGRpc3Rpbmd1aXNoaW5nIGZpZWxkLCAiRmluYWwgRGVzdGluYXRpb24gQWRkcmVz cyIgaW50byB0aGUgZml4ZWQgcGFydCBvZiB0aGUgaGVhZGVyIChyaWdodCBhZnRlciBob3BzX2xl ZnQpLiBTZXF1ZW5jZSBudW1iZXIgYW5kIG9yaWdpbmF0b3INCiAgICAgIGFkZHJlc3Mgd291bGQg cmVsb2NhdGUgYWZ0ZXIgZmluYWwgZGVzdGluYXRpb24gYWRkcmVzcy4gVGhpcyBkb2VzIG5vdCB3 YXN0ZSBhbnkgYml0cywgYnV0IGlzIGVzdGhldGljYWxseSB1bnBsZWFzYW50LiBCdXQgd2UgbWF5 IG5vdCBjYXJlIGFib3V0IHN1Y2gNCiAgICAgIHRoaW5ncy4NCg0KICBBbnkgb3RoZXJzPw0KDQog IENvbW1lbnRzPyBXb3VsZCB0aGUgZm9sa3Mgd2hvIGFyZSBpbXBsZW1lbnRpbmcgdGhpcyBwbGVh c2UgZXhwcmVzcyB0aGVpciBvcGluaW9ucz8NCg0KICAtZ2FicmllbA0KDQoNCiAgLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tDQogIEZyb206IE1hcmlvIE1hbyA8bWFyaW9tYW9AZ21haWwuY29t Pg0KICBUbzogZ2FicmllbCBtb250ZW5lZ3JvIDxnYWJyaWVsX21vbnRlbmVncm9fMjAwMEB5YWhv by5jb20+DQogIENjOiA2bG93cGFuQGlldGYub3JnDQogIFNlbnQ6IFNhdHVyZGF5LCBBdWd1c3Qg NSwgMjAwNiAyOjUyOjUyIEFNDQogIFN1YmplY3Q6IFNvbWUgY29tbWVudHMgYWJvdXQgZHJhZnQt aWV0Zi02bG93cGFuLWZvcm1hdC0wNA0KDQoNCiAgSGkgR2FicmllbCwNCg0KICBUaGVyZSBpcyBz b21lIGNvbW1lbnRzIGFib3V0IHRoZSBsYXN0IGRyYWZ0LCB0aGFua3MuDQoNCiAgSW4gU2VjdGlv biAxMSwgdGhlIGRyYWZ0IG1lbnRpb25zIHRoYXQgYSBzcGVjaWFsIGZvcm1hdCBvZiAiTWVzaCBE ZWxpdmVyeSIgZmllbGQgc2hvdWxkIGJlIHVzZWQgd2hlbiBCcm9hZGNhc3Qgb3IgTXVsdGljYXN0 LiBUaGlzIGtpbmQgb2YgZmllbGQgaXMgY2FsbGVkIGFzIE1lc2ggQnJvYWRjYXN0IG9yIE11bHRp Y2FzdCBEZWxpdmVyeSBGaWVsZCBhbmQgYSAiU2VxdWVuY2UgTnVtYmVyIiBpcyBhZGRlZC4NCg0K ICBGb3IgU291cmNlIE5vZGUsIGl0IHdpbGwgYmUgY2xlYXIgdGhhdCB3aGljaCBraW5kIG9mIGZv cm1hdCBpdCBzaG91bGQgdXNlLiBCdXQgZm9yIERlc3RpbmF0aW9uIE5vZGUgb3IgUmVsYXkgTm9k ZSwgbG9va3MgbGlrZSB0aGVyZSB3aWxsIGJlIHNvbWUgY29uZnVzaW9uIHdoZW4gdGhleSB0cnlp bmcgdG8gZXhwbGFpbiB0aGlzIGZvcm1hdC4NCg0KICBUaGUgY2F1c2Ugb2Ygc3VjaCBjb25mdXNp b24gaXMgdGhlIHdheSBpbmJvdW5kIE5vZGUgaWRlbnRpZnlpbmcgc3VjaCBraW5kIG9mIGZpZWxk IGZvcm1hdC4gQXMgdGhlIGRyYWZ0IG1lbnRpb25lZCwgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3Mg aXMgdGhlIGlkZW50aWZpY2F0aW9uIG9mIHN1Y2gga2luZCBvZiBmaWVsZC4gSG93ZXZlciwgZm9y IHRoZSBGaW5hbCBEZXN0aW5hdGlvbiBBZGRyZXNzIGlzIGJlaGluZCB0aGUgU2VxdWVuY2UgTnVt YmVyLCB0aGUgaW5ib3VuZCBOb2RlIHdpbGwgYmUgdW5hd2FyZSBvZiB0aGUgZXhpc3RlbmNlIG9m IHRoaXMgZmllbGQgYmVmb3JlIGl0IGNoZWNrIHRoZSBGaW5hbCBEZXN0aW5hdGlvbiBBZGRyZXNz LiBJZiBpbmJvdW5kIE5vZGUgaGFuZGxlIGFsbCBCcm9hZGNhc3QgRGVsaXZlcnkgRmllbGQgYXMg dGhlIG5vcm1hbCAiTWVzaCBEZWxpdmVyeSIgZmllbGQsIHdoZW4gaXQgYmVnaW5zIHRvIGNoZWNr IHRoZSBGaW5hbCBEZXN0aW5hdGlvbiBBZGRyZXNzLCB0aGVyZSB3aWxsIGJlIDgtYml0cyBzaGlm dCBvZiB0aGUgcmlnaHQgcG9zaXRpb24uIFRoaXMgc2NlbmFyaW8gbXVzdCBsZWFkIHRvIGFuIG1p c3Rha2UuDQoNCiAgVGhlcmUgaXMgYWxzbyBhbm90aGVyIHdheSB0byBpZGVudGlmeSB0aGUgQnJv YWRjYXN0IERlbGl2ZXJ5IEZpZWxkLiBUaGF0IGlzIGNoZWNraW5nIHRoZSBkZXN0aW5hdGlvbiBN QUMgYWRkcmVzcyBpbiB0aGUgSUVFRSA4MDIuMTUuNCBoZWFkZXIgKDB4RkZGRikuIEJ1dCBpbiBw cmFjdGljZSwgYW4gSUVFRSA4MDIuMTUuNCBicm9hZGNhc3QgZnJhbWUgY2FuJ3QgYmUgZGVsaXZl cmVkIHRvIGV2ZXJ5IEVORCBERVZJQ0UgKFJGRCkuIFRoaXMgaXMgYmVjYXVzZSB0aGUgRU5EIERF VklDRSBkaXNhYmxlIGl0cyB0cmFuc2NlaXZlciBkdXJpbmcgQ0FQIHdoZW4gdGhlcmUgaXMgbm8g ZnJhbWUgZGlyZWN0bHkgc2VudCB0byBpdC4NCg0KICBUbyBhdm9pZCBzdWNoIGluY29ycmVjdCBz Y2VuYXJpbywgb25lIGZsYWcgbWF5IGJlIG5lZWRlZCBpbiB0aGUgZml4ZWQgZmlsZWQgKGluIEFk YXB0YXRpb24gSGVhZGVyKS4gVGhhdCBtYWtlIGFsbCBub2RlIGNvdWxkIHJlY29nbml6ZSB0aGUg c3BlY2lhbCBCcm9hZGNhc3QgRGVsaXZlcnkgRmllbGQgaW4gcmlnaHQgd2F5Lg0KDQogIFJlZ2Fy ZHMsDQoNCg0KICBNYXJpbyBNYW8NCiAgTWFyaW9NYW9AR21haWwuY29tDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgNmxvd3BhbiBtYWlsaW5nIGxpc3QNCiAgNmxv d3BhbkBpZXRmLm9yZw0KICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82 bG93cGFuDQoNCg== ------=_NextPart_000_006D_01C6D2BC.9C890D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+ RElWIHsNCglNQVJHSU46IDBweA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xNTYxIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNm ZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhpIEdhYnJpZWwsPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlNvcnJ5IGZvciB0aGUgZGVsYXksIGhlcmUgYXJl IHNvbWUgY29tbWVudHMgYWJvdXQgDQp0aGUgbmV3bHkgbW9kaWZpZWQgQnJvYWRjYXN0IGZpZWxk LCB0aGFua3MuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFib3V0IHRoZSBv cHRpb24gIzQsIEkgdGhpbmsgaXQgaXMgYSBnb29kIHdheSB0byANCnNvbHZlIHRoZSBjb25mdXNp b24uIEluIGFkZGl0aW9uLCBoZXJlIGlzIHRoZSB3YXkgd2UgdXNlZCwgaG9wZSBpdCBjb3VsZCBk byBzb21lIA0KaGVscCwgdGhhbmtzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj5JIHJlbWVtYmVyIEkgaGFkIHN1Z2dlc3RlZCBhIHdheSZuYnNwO29mIA0KaW50cm9kdWNpbmcg YSAiTSIgYml0IHdoaWNoIGluZGljYXRlcyBNZXNoIEJyb2FkY2FzdCBvciBNdWx0aWNhc3QgRGVs aXZlcnkgRmllbGQgDQppbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhlIExvV1BBTiBoZWFkZXIuIFRo ZSAiTSIgd2lsbCB1c2Ugb25lIG9mIHRoZSA0IHJzdiBiaXRzIA0KaW4gZml4ZWQgaGVhZGVyIGFu ZCBub3QgYWZmZWN0IHRoZSBhbGlnbm1lbnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg DQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjImbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQozPEJSPiZuYnNwOyAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IA0KMTxCUj4mbmJzcDsrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKzxCUj4mbmJzcDt8IA0KTEZ8Jm5ic3A7IHByb3RfdHlwZSZu YnNwOyZuYnNwOyZuYnNwOyB8TXxCfCByc3YmbmJzcDsmbmJzcDsgfFBheWxvYWQgKE1lc2ggQi9N IA0KRmllbGQpLi4uPEJSPiZuYnNwOystKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9GT05UPjxCUj48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+V2hlbiBlbmNvdW50ZXJpbmcgYWRhcHRhdGlvbiBsYXllciBm cmFnbWVudCwgbm8gDQptb3JlIGJpdCBhcmUgZnJlZSBmb3IgdGhlIHNwZWNpYWwgYml0LiBIb3dl dmVyLCB3ZSBmaW5kIGl0J3MgYSZuYnNwO25pZ2h0bWFyZSB0byANCmJyb2FkY2FzdCBmcmFnbWVu dHMmbmJzcDtpbiBhY3R1YWwgODAyLjE1LjQgbmV0d29yay4gVGhlIHdvcmtpbmcgY2hhbm5lbCB3 b3VsZCANCmJlIGZ1bGwgb2YgYnJvYWRjYXN0IGZyYWdtZW50cyBldmVuIHVzaW5nIGtpbmRzIG9m IG9wdGltaXplZCBhbGdvcml0aG0gYW5kIHRoZSANCnJlc3VsdCZuYnNwO2lzIGhpZ2ggcG9zc2li aWxpdHkgb2YgZGlzY2FyZGluZyBhbmQgcmUtdHJhbnNtaXR0aW5nLCBhbmQgaGlnaCANCmVuZXJn eS1jb3N0IC4gU28sIHRvIGF2b2lkIHN1Y2ggc2l0dWF0aW9uLCB3ZSBkZWNpZGUgdG8gZGlzYWJs ZSBicm9hZGNhc3Qgd2hlbiANCnRoZSBwYWNrZXQgbmVlZCB0byBiZSBmcmFnbWVudGVkIGludG8g c2V2ZXJhbCBmcmFtZXMgKHVnbHkgYnV0IHVzZWZ1bCB3YXkpLiBXaXRoIA0KdGhpcyBzdHJhdGVn eSwgbm8gbW9kaWZpY2F0aW9uIHRvIHRoZSBmcmFnbWVudCBlbmNhcHN1bGF0aW9uIGhlYWRlciBm b3JtYXQgaXMgDQpuZWVkZWQgdG9vLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgZmFj ZT1BcmlhbD5BdCBsYXN0LCBJIGZpbmQmbmJzcDtzb21lIHByb2JsZW0gd2hlbiANCmltcGxpbWVu dCBJUHY2IGhlYWRlciBjb21wcmVzc2lvbi4gUGxlYXNlIG5vdGUgVHJhZmZpYyBDbGFzcyBhbmQg RmxvdyBMYWJlbCBiaXQgDQppbiBIQzEuIElmIHdlIGRvbid0IGNvbXByZXNzIHRoZSB0d28gZmll bGQsIDI4IGJpdHMgKHRoYXQgaXMmbmJzcDt0aHJlZSBhbmQgaGFsZiANCmJ5dGVzKSBhcmUgc2Vu dC4gSG93ZXZlciwgaG93IHRvIHNlbmQgdGhlIGhhbGYgYnl0ZT8gQXMgSSBrbm93LCBtb3N0IGhh cmR3YXJlIA0KY291bGQgb25seSZuYnNwO3RyYW5zbWl0IGRhdGEgaW4gdW5pdCBvZiBCWVRFLiBT aG91bGQgd2UgbmVlZCA0IGJpdHMgcGVuZGluZyANCmRhdGE/Jm5ic3A7VGhlIHdvcmtkYXJvdW5k IHdlIHVzZWQgaXMgY29tYmluaW5nIHRoZSBUcmFmZmljIENsYXNzIGFuZCBGbG93IExhYmVsIA0K d2l0aCBWZXJzaW9uIGZpZWxkLiBTbywgdGhlIFRyYWZmaWMgQ2xhc3MgYW5kIEZsb3cgTGFiZWwg Yml0IGJlY29tZXMgVmVyc2lvbiwgDQpUcmFmZmljIENsYXNzIGFuZCBGbG93IExhYmVsIGJpdC48 L0ZPTlQ+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gDQo8L0ZPTlQ+PEZPTlQgZmFjZT1B cmlhbD5QbGVhc2Ugc2VlIGZvbGxvd2luZyBhcyBkZXRhaWwuPC9GT05UPjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGxhbmc9RU4t VVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiAmIzIzNDM1OyYjMjAzMDc7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSI+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0OyBGT05U LUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogJiMyMzQzNTsmIzIwMzA3OzsgbXNvLWZvbnQta2Vybmlu ZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0KZmFjZT1BcmlhbD48Rk9O VCBzaXplPTI+VmVyc2lvbiwgVHJhZmZpYyBDbGFzcyBhbmQgRmxvdyBMYWJlbCAoYml0IDQpOjxC Uj4wOiBub3QgDQpjb21wcmVzc2VkLCBmdWxsIDQgYml0cyBmb3IgVmVyc2lvbiwgOCBiaXRzIGZv ciBUcmFmZmljIENsYXNzIGFuZCAyMCBiaXRzIGZvciANCkZsb3cgTGFiZWwgYXJlIHNlbnQ8L0ZP TlQ+PEJSPjxGT05UIHNpemU9Mj4xOiBUcmFmZmljIENsYXNzIGFuZCBGbG93IExhYmVsIGFyZSAN Cnplcm88L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+QmVzdCBSZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5N YXJpbyBNYW88L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJ TkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRF Ui1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0 ICYjMjM0MzU7JiMyMDMwNzs7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxB IHRpdGxlPWdhYnJpZWxfbW9udGVuZWdyb18yMDAwQHlhaG9vLmNvbSANCiAgaHJlZj0ibWFpbHRv OmdhYnJpZWxfbW9udGVuZWdyb18yMDAwQHlhaG9vLmNvbSI+Z2FicmllbCBtb250ZW5lZ3JvPC9B PiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRv OjwvQj4gPEEgDQogIHRpdGxlPWdhYnJpZWxfbW9udGVuZWdyb18yMDAwQHlhaG9vLmNvbSANCiAg aHJlZj0ibWFpbHRvOmdhYnJpZWxfbW9udGVuZWdyb18yMDAwQHlhaG9vLmNvbSI+Z2FicmllbCBt b250ZW5lZ3JvPC9BPiA7IDxBIA0KICB0aXRsZT1tYXJpb21hb0BnbWFpbC5jb20gaHJlZj0ibWFp bHRvOm1hcmlvbWFvQGdtYWlsLmNvbSI+TWFyaW8gTWFvPC9BPiA8L0RJVj4NCiAgPERJViBzdHls ZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9Nmxvd3Bh bkBpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOjZsb3dwYW5AaWV0Zi5vcmciPjZsb3dwYW5AaWV0 Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3 OyI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDcsIDIwMDYgNDo0MiANCiAgUE08 L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1Ympl Y3Q6PC9CPiBSZTogWzZsb3dwYW5dIFJlOiBTb21lIGNvbW1lbnRzIA0KICBhYm91dCBkcmFmdC1p ZXRmLTZsb3dwYW4tZm9ybWF0LTA0PC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLCBu ZXcgeW9yaywgdGltZXMsIHNlcmlmIj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJw dDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+ U2luY2UgDQogIHRoZXJlIGhhcyBiZWVuIG5vIGZlZWRiYWNrIG9uIHRoaXMsIEkgd2lsbCBnbyB3 aXRoIG9wdGlvbiAjNCBiZWxvdyB1bmxlc3MgSSANCiAgaGVhciBvdGhlcndpc2Ugd2l0aGluIHRo ZSBuZXh0IGZldzwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmIj5kYXlzLiAN CiAgV2UgY2FuIGFsd2F5cyByZXZpc2l0IHRoaXMgZHVyaW5nIElFVEYgTEMuIEJ1dCBpZiB3ZSBt YWtlIG5vIGRlY2lzaW9uIHdlIHdpbGwgDQogIG5ldmVyIGdldCB0byBJRVRGIExDLjwvRElWPg0K ICA8RElWIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3 IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmIj4mbmJzcDs8L0RJVj4NCiAgPERJViANCiAg c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3 IHlvcmssIHRpbWVzLCBzZXJpZiI+LWdhYnJpZWw8QlI+PEJSPjwvRElWPg0KICA8RElWIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLCBuZXcg eW9yaywgdGltZXMsIHNlcmlmIj4tLS0tLSANCiAgT3JpZ2luYWwgTWVzc2FnZSAtLS0tPEJSPkZy b206IGdhYnJpZWwgbW9udGVuZWdybyAmbHQ7PEEgDQogIGhyZWY9Im1haWx0bzpnYWJyaWVsX21v bnRlbmVncm9fMjAwMEB5YWhvby5jb20iPmdhYnJpZWxfbW9udGVuZWdyb18yMDAwQHlhaG9vLmNv bTwvQT4mZ3Q7PEJSPlRvOiANCiAgTWFyaW8gTWFvICZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOm1h cmlvbWFvQGdtYWlsLmNvbSI+bWFyaW9tYW9AZ21haWwuY29tPC9BPiZndDs8QlI+Q2M6IDxBIA0K ICBocmVmPSJtYWlsdG86Nmxvd3BhbkBpZXRmLm9yZyI+Nmxvd3BhbkBpZXRmLm9yZzwvQT48QlI+ U2VudDogVHVlc2RheSwgQXVndXN0IA0KICA4LCAyMDA2IDg6NTY6MjQgQU08QlI+U3ViamVjdDog WzZsb3dwYW5dIFJlOiBTb21lIGNvbW1lbnRzIGFib3V0IA0KICBkcmFmdC1pZXRmLTZsb3dwYW4t Zm9ybWF0LTA0PEJSPjxCUj4NCiAgPFNUWUxFIHR5cGU9dGV4dC9jc3M+PCEtLSBESVYge21hcmdp bjowcHg7fS0tPjwvU1RZTEU+DQoNCiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsg Rk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+DQog IDxESVYgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcg cm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWYiPkdvb2QgDQogIHBvaW50LCB5ZXMuIFRoZSBjb25m dXNpb24gaXMgdGhhdCB1cG9uIHJlY2VwdGlvbiBpdCBpcyBub3QgZWFzeSB0byBkZXRlcm1pbmUg DQogIHdoaWNoIG9mIHRoZSB0d28gZm9sbG93aW5nIG1lc2ggaGVhZGVyIGZvcm1hdHMgaXMgYmVp bmcgdXNlZCBiZWNhdXNlPEJSPnRoZSANCiAgZml4ZWQgcGFydCBvZiB0aGUgaGVhZGVyIGRvZXMg bm90IHRlbGwgdXM6PEJSPjxCUj48UFJFPiAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAg ICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzPEJSPiAgICAgICAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8QlI+ ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSs8QlI+ICAgICAgfE98RnwgSG9wcyBMZWZ0IHwgICAgICAgICAgICBPcmln aW5hdG9yIEFkZHJlc3MuLi48QlI+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8QlI+ICAgICAgICAgLi4uRmluYWwg RGVzdGluYXRpb24gQWRkcmVzczxCUj4gICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxCUj48QlI+PEJSPiAgICAgICAg ICAgICAgICAgICAgICBGaWd1cmUgMTA6IE1lc2ggRGVsaXZlcnkNCiBGaWVsZDwvUFJFPjxCUj48 UFJFPiAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAg ICAgICAgICAgICAgICAzPEJSPiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8QlI+ICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8QlI+ICAg ICAgfE98RnwgSG9wcyBMZWZ0IHxTZXF1ZW5jZSBOdW1iZXJ8ICAgICBPcmlnaW5hdG9yIEFkZHJl c3MuLi48QlI+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8QlI+ICAgICAgICAgLi4uRmluYWwgRGVzdGluYXRpb24g QWRkcmVzczxCUj4gICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKzxCUj48QlI+ICAgICAgICAgICBGaWd1cmUgMTE6IE1l c2ggQnJvYWRjYXN0IG9yIE11bHRpY2FzdCBEZWxpdmVyeSBGaWVsZDwvUFJFPldlIA0KICBjb3Vs ZCBwdXQgdGhlIGluZGljYXRpb24gaW4gdGhlIGZpeGVkIHBhcnQgb2YgdGhlIGhlYWRlciBieSA6 PEJSPjxCUj4xLiBhZGRpbmcgDQogIGEgYml0IGZpZWxkIHRvIGRpc3Rpbmd1aXNoLiBUd28gYWx0 ZXJuYXRpdmVzOiAoYSkgV2UgY291bGQgYWRkIG9uZSBiaXQgYW5kIA0KICBtb3ZlIGV2ZXJ5dGhp bmcgYWZ0ZXIgaXQgb3ZlciBvbmUgYml0LiBOb3QgdGhhdCBvdXIgYWxpZ25tZW50IA0KICB3YXM8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyZWF0IHRvIGJlZ2luIHdpdGgsIGJ1dCB0aGlzIHdvdWxk IG1ha2UgaXQgdWdsaWVyLiANCiAgKGIpIFdlIGNvdWxkIG1ha2UgdGhpcyBiaXQgZmllbGQgbGFy Z2VyIHRoYW4gMSBiaXQsIGluIHdoaWNoIGNhc2Ugd2UnZCBiZSBhYmxlIA0KICA8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlIHR3byBjdXJyZW50IGZvcm1h dHMgYW5kIA0KICBsZWF2ZSBzb21lIGJpdCBwYXR0ZXJucyByZXNlcnZlZCBpbiBjYXNlIHdlIGVu ZCB1cCBkZWZpbmluZyBvdGhlciANCiAgLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgbWVzaCBoZWFk ZXJzIGluIHRoZSBmdXR1cmUuPEJSPjIuIGFkZGluZyBhIGJpdCBieSANCiAgc3RlYWxpbmcgb25l IGZyb20sIHNheSwgaG9wc19sZWZ0LiBUaGlzIG1lYW5zIHdlJ2QgaGF2ZSBhIG1heCBvZiAzMiBo b3BzIA0KICBpbnN0ZWFkIG9mIHRoZSBjdXJyZW50IDY0LiBJIHN0aWxsIHRoaW5rIHRoaXM8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIGVub3VnaC4gDQogIFRoaXMgd291bGQgbm90IGFsdGVyIHdo YXRldmVyIGFsaWdubWVudCB3ZSBub3cgaGF2ZS48QlI+My4gR3JvdyB0aGUgJ0YnIGZpZWxkIA0K ICBieSBvbmUgbW9yZSBiaXQsIGFuZCBhc3NpZ24gYml0IHBhdHRlcm5zIGZvciA2NCBiaXQgYWRk cmVzcywgMTYtYml0IGFkZHJlc3MgDQogIGFuZCAxNi1iaXQgYmNhc3QvbWNhc3QgYWRkcmVzcyAo YXMgcGVyPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgY3VycmVudCANCiAgZHJhZnQpLiA8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgd291bGQgbGVhdmUgb25lIGJpdCBwYXR0ZXJuIA0KICBy ZXNlcnZlZC48QlI+NC4gTW92ZSB0aGUgZGlzdGluZ3Vpc2hpbmcgZmllbGQsICJGaW5hbCBEZXN0 aW5hdGlvbiBBZGRyZXNzIiANCiAgaW50byB0aGUgZml4ZWQgcGFydCBvZiB0aGUgaGVhZGVyIChy aWdodCBhZnRlciBob3BzX2xlZnQpLiBTZXF1ZW5jZSBudW1iZXIgYW5kIA0KICBvcmlnaW5hdG9y PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBhZGRyZXNzIHdvdWxkIHJlbG9jYXRlIGFmdGVyIGZpbmFs IA0KICBkZXN0aW5hdGlvbiBhZGRyZXNzLiBUaGlzIGRvZXMgbm90IHdhc3RlIGFueSBiaXRzLCBi dXQgaXMgZXN0aGV0aWNhbGx5IA0KICB1bnBsZWFzYW50LiBCdXQgd2UgbWF5IG5vdCBjYXJlIGFi b3V0IHN1Y2g8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICB0aGluZ3MuPEJSPjxCUj5Bbnkgb3Ro ZXJzPzxCUj48QlI+Q29tbWVudHM/IFdvdWxkIHRoZSBmb2xrcyB3aG8gYXJlIA0KICBpbXBsZW1l bnRpbmcgdGhpcyBwbGVhc2UgZXhwcmVzcyB0aGVpciBvcGluaW9ucz88QlI+PEJSPi1nYWJyaWVs PEJSPjxCUj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6 IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+LS0tLS0gDQogIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLTxCUj5Gcm9tOiBNYXJpbyBNYW8gJmx0O21hcmlvbWFvQGdtYWlsLmNvbSZn dDs8QlI+VG86IA0KICBnYWJyaWVsIG1vbnRlbmVncm8gJmx0O2dhYnJpZWxfbW9udGVuZWdyb18y MDAwQHlhaG9vLmNvbSZndDs8QlI+Q2M6IA0KICA2bG93cGFuQGlldGYub3JnPEJSPlNlbnQ6IFNh dHVyZGF5LCBBdWd1c3QgNSwgMjAwNiAyOjUyOjUyIEFNPEJSPlN1YmplY3Q6IFNvbWUgDQogIGNv bW1lbnRzIGFib3V0IGRyYWZ0LWlldGYtNmxvd3Bhbi1mb3JtYXQtMDQ8QlI+PEJSPg0KICA8U1RZ TEU+PC9TVFlMRT4NCg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhpIEdhYnJpZWws PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGVyZSBpcyBzb21lIGNv bW1lbnRzIGFib3V0IHRoZSBsYXN0IGRyYWZ0LCANCiAgdGhhbmtzLjwvRk9OVD48L0RJVj4NCiAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SW4gU2VjdGlvbiAxMSwgdGhlIGRyYWZ0IG1lbnRpb25z IHRoYXQgYSBzcGVjaWFsIA0KICBmb3JtYXQgb2YgIk1lc2ggRGVsaXZlcnkiIGZpZWxkIHNob3Vs ZCBiZSB1c2VkIHdoZW4gQnJvYWRjYXN0IG9yIE11bHRpY2FzdC4gDQogIFRoaXMga2luZCBvZiBm aWVsZCBpcyBjYWxsZWQgYXMmbmJzcDtNZXNoIEJyb2FkY2FzdCBvciBNdWx0aWNhc3QgRGVsaXZl cnkgDQogIEZpZWxkIGFuZCZuYnNwO2EgIlNlcXVlbmNlIE51bWJlciIgaXMgYWRkZWQuPC9GT05U PjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Gb3IgU291cmNlIE5vZGUsIGl0IHdp bGwgYmUgY2xlYXIgdGhhdCB3aGljaCBraW5kIA0KICBvZiBmb3JtYXQgaXQgc2hvdWxkIHVzZS4g QnV0IGZvciBEZXN0aW5hdGlvbiBOb2RlIG9yIFJlbGF5IE5vZGUsIGxvb2tzIGxpa2UgDQogIHRo ZXJlIHdpbGwgYmUgc29tZSBjb25mdXNpb24gd2hlbiB0aGV5IHRyeWluZyB0byBleHBsYWluIHRo aXMgDQogIGZvcm1hdC48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlRo ZSBjYXVzZSBvZiBzdWNoIGNvbmZ1c2lvbiBpcyB0aGUgd2F5IGluYm91bmQgDQogIE5vZGUmbmJz cDtpZGVudGlmeWluZyBzdWNoIGtpbmQgb2YgZmllbGQgZm9ybWF0LiBBcyB0aGUgZHJhZnQgbWVu dGlvbmVkLCB0aGUgDQogIGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgdGhlIGlkZW50aWZpY2F0aW9u IG9mIHN1Y2gga2luZCBvZiANCiAgZmllbGQuJm5ic3A7SG93ZXZlciwmbmJzcDtmb3IgdGhlIEZp bmFsIERlc3RpbmF0aW9uIEFkZHJlc3MgDQogIGlzJm5ic3A7YmVoaW5kJm5ic3A7dGhlIFNlcXVl bmNlIE51bWJlciwgdGhlIGluYm91bmQgTm9kZSB3aWxsIGJlIHVuYXdhcmUgb2YgDQogIHRoZSBl eGlzdGVuY2Ugb2YgdGhpcyBmaWVsZCBiZWZvcmUgaXQgY2hlY2sgdGhlIEZpbmFsIERlc3RpbmF0 aW9uIEFkZHJlc3MuIElmIA0KICBpbmJvdW5kIE5vZGUgaGFuZGxlIGFsbCBCcm9hZGNhc3QmbmJz cDtEZWxpdmVyeSBGaWVsZCBhcyB0aGUgbm9ybWFsICJNZXNoIA0KICBEZWxpdmVyeSIgZmllbGQs IHdoZW4gaXQgYmVnaW5zIHRvIGNoZWNrIHRoZSBGaW5hbCBEZXN0aW5hdGlvbiBBZGRyZXNzLCAN CiAgdGhlcmUmbmJzcDt3aWxsIGJlIDgtYml0cyBzaGlmdCBvZiB0aGUgcmlnaHQgcG9zaXRpb24u IFRoaXMgc2NlbmFyaW8gbXVzdCBsZWFkIA0KICB0byBhbiBtaXN0YWtlLjwvRk9OVD48L0RJVj4N CiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+VGhlcmUgaXMgYWxzbyBhbm90aGVyIHdheSB0byBp ZGVudGlmeSB0aGUgDQogIEJyb2FkY2FzdCBEZWxpdmVyeSBGaWVsZC4gVGhhdCBpcyBjaGVja2lu ZyB0aGUgZGVzdGluYXRpb24gTUFDIGFkZHJlc3MgaW4gdGhlIA0KICBJRUVFIDgwMi4xNS40Jm5i c3A7aGVhZGVyICgweEZGRkYpLiZuYnNwO0J1dCBpbiBwcmFjdGljZSwgYW4gSUVFRSA4MDIuMTUu NCANCiAgYnJvYWRjYXN0IGZyYW1lIGNhbid0IGJlIGRlbGl2ZXJlZCB0byBldmVyeSBFTkQgREVW SUNFIChSRkQpLiBUaGlzIGlzIGJlY2F1c2UgDQogIHRoZSZuYnNwO0VORCBERVZJQ0UmbmJzcDtk aXNhYmxlIGl0cyB0cmFuc2NlaXZlciZuYnNwO2R1cmluZyBDQVAgd2hlbiB0aGVyZSBpcyANCiAg bm8gZnJhbWUgZGlyZWN0bHkgc2VudCB0byBpdC48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPlRvIGF2b2lkIHN1Y2ggaW5jb3JyZWN0IHNjZW5hcmlvLCBvbmUgZmxhZyBt YXkgYmUgDQogIG5lZWRlZCBpbiB0aGUgZml4ZWQgZmlsZWQgKGluIEFkYXB0YXRpb24gSGVhZGVy KS4gVGhhdCBtYWtlIGFsbCBub2RlIGNvdWxkIA0KICByZWNvZ25pemUgdGhlIHNwZWNpYWwgQnJv YWRjYXN0IERlbGl2ZXJ5IEZpZWxkIGluIHJpZ2h0IHdheS48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPlJlZ2FyZHMsPC9GT05UPjwvRElWPg0KICA8RElWPjxCUj4NCiAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5NYXJpbyBNYW88L0ZPTlQ+PC9ESVY+DQogIDxE SVY+PFU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48QSBpZD1ib2R5TGlu a3MgDQogIGhyZWY9Im1haWx0bzpNYXJpb01hb0BHbWFpbC5jb20iIHRhcmdldD1fYmxhbmsgDQog IHJlbD1ub2ZvbGxvdz5NYXJpb01hb0BHbWFpbC5jb208L0E+PC9GT05UPjwvVT48L0RJVj4NCiAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvRElWPjwvRElW PjwvRElWPjxCUj48L0RJVj48L0RJVj4NCiAgPERJVj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxCUj42bG93cGFuIG1haWxpbmcgDQogIGxpc3Q8QlI+Nmxv d3BhbkBpZXRmLm9yZzxCUj48QSANCiAgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vNmxvd3BhbiIgDQogIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3BhbjwvQT48L0RJVj48L0RJVj4NCiAgPERJViANCiAg c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3 IHlvcmssIHRpbWVzLCBzZXJpZiI+PEJSPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+ PC9IVE1MPg0K ------=_NextPart_000_006D_01C6D2BC.9C890D70-- --===============0718994183== 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 --===============0718994183==-- From 6lowpan-bounces@ietf.org Thu Sep 07 15:46:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLPp4-00044U-Lg; Thu, 07 Sep 2006 15:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLPp3-000447-Dg for 6lowpan@ietf.org; Thu, 07 Sep 2006 15:46:01 -0400 Received: from mpls-relay-02.inet.qwest.net ([63.226.138.12]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLPp2-0006p6-T1 for 6lowpan@ietf.org; Thu, 07 Sep 2006 15:46:01 -0400 Received: (qmail 70325 invoked by uid 0); 7 Sep 2006 19:45:49 -0000 Received: from unknown (HELO scorp01.corp.cmdinfo.com) (65.120.79.2) by mpls-relay-02.inet.qwest.net with SMTP; 7 Sep 2006 19:45:49 -0000 Date: Thu, 7 Sep 2006 15:43:14 -0400 Message-ID: <7158315D3917854D9AD5B36BFF8CD3F13CC071@scorp01.corp.cmdinfo.com> From: "Dave Green" To: "Mario Mao" , "gabriel montenegro" Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <007001c6d279$90ade8b0$7fc0a8c0@netlab.cs.ecnu.edu.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 Thread-Index: AcbSeR183IY2SWoBRg+g/GyFHQF39AAO7a5g X-Spam-Score: 0.1 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Would anyone in this group be interested in working on an open-source = free (as in free beer) IPv6 6LowPAN stack for 802.15.4 if we make the = project available? The license would likely be creative commons. The = first target environment is a 32 bit ARM-7 controller. My company would = supply the reference stack for all to hack on and compile for their = architectures. We would do the ARM-7 port and hope others would port to = their architectures and post. This would create a license free = alternative to Zigbee so we can buy cheap sensor radios for our work.=20 If interested, please let me know. I believe we could have this set up = by year's end.=20 David Green |=A0VP of R&D=A0|=A0Command Information 13655 Dulles Technology Drive, Suite 100=A0|=A0 Herndon, VA=A020171 O: 703.561.5937=A0| M: 703.899.9663 |=A0green@commandinformation.com ________________________________________ From: Mario Mao [mailto:mariomao@gmail.com]=20 Sent: Thursday, September 07, 2006 8:32 AM To: gabriel montenegro Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Re: Some comments about = draft-ietf-6lowpan-format-04 Hi Gabriel, =A0 Sorry for the delay, here are some comments about the newly modified = Broadcast field, thanks. =A0 About the option #4, I think it is a good way to solve the confusion. In = addition, here is the way we used, hope it could do some help, thanks. =A0 I remember I had suggested a way=A0of introducing a "M" bit which = indicates Mesh Broadcast or Multicast Delivery Field immediately = following the LoWPAN header. The "M" will use one of the 4 rsv bits in = fixed header and not affect the alignment. =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3 =A0 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 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =A0| LF|=A0 prot_type=A0=A0=A0 |M|B| rsv=A0=A0 |Payload (Mesh B/M = Field)... =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When encountering adaptation layer fragment, no more bit are free for = the special bit. However, we find it's a=A0nightmare to broadcast = fragments=A0in actual 802.15.4 network. The working channel would be = full of broadcast fragments even using kinds of optimized algorithm and = the result=A0is high possibility of discarding and re-transmitting, and = high energy-cost . So, to avoid such situation, we decide to disable = broadcast when the packet need to be fragmented into several frames = (ugly but useful way). With this strategy, no modification to the = fragment encapsulation header format is needed too. =A0 At last, I find=A0some problem when impliment IPv6 header compression. = Please note Traffic Class and Flow Label bit in HC1. If we don't = compress the two field, 28 bits (that is=A0three and half bytes) are = sent. However, how to send the half byte? As I know, most hardware could = only=A0transmit data in unit of BYTE. Should we need 4 bits pending = data?=A0The workdaround we used is combining the Traffic Class and Flow = Label with Version field. So, the Traffic Class and Flow Label bit = becomes Version, Traffic Class and Flow Label bit. Please see following = as detail. =A0 Version, Traffic Class and Flow Label (bit 4): 0: not compressed, full 4 bits for Version, 8 bits for Traffic Class and = 20 bits for Flow Label are sent 1: Traffic Class and Flow Label are zero =A0 Best Regards, =A0 Mario Mao ----- Original Message -----=20 From: gabriel montenegro=20 To: gabriel montenegro ; Mario Mao=20 Cc: 6lowpan@ietf.org=20 Sent: Thursday, September 07, 2006 4:42 PM Subject: Re: [6lowpan] Re: Some comments about = draft-ietf-6lowpan-format-04 Since there has been no feedback on this, I will go with option #4 below = unless I hear otherwise within the next few days. We can always revisit this during IETF LC. But if we make no = decision we will never get to IETF LC. =A0 -gabriel ----- Original Message ---- From: gabriel montenegro To: Mario Mao Cc: 6lowpan@ietf.org Sent: Tuesday, August 8, 2006 8:56:24 AM Subject: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 Good point, yes. The confusion is that upon reception it is not easy to = determine which of the two following mesh header formats is being used = because the fixed part of the header does not tell us: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|F| Hops Left | Originator Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...Final Destination Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Mesh Delivery Field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|F| Hops Left |Sequence Number| Originator Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...Final Destination Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Mesh Broadcast or Multicast Delivery Field We could put the indication in the fixed part of the header by : 1. adding a bit field to distinguish. Two alternatives: (a) We could add = one bit and move everything after it over one bit. Not that our = alignment was =A0=A0=A0 great to begin with, but this would make it uglier. (b) We = could make this bit field larger than 1 bit, in which case we'd be able=20 =A0=A0=A0 to distinguish between the two current formats and leave some = bit patterns reserved in case we end up defining other . =A0=A0=A0 mesh headers in the future. 2. adding a bit by stealing one from, say, hops_left. This means we'd = have a max of 32 hops instead of the current 64. I still think this =A0=A0=A0 is enough. This would not alter whatever alignment we now = have. 3. Grow the 'F' field by one more bit, and assign bit patterns for 64 = bit address, 16-bit address and 16-bit bcast/mcast address (as per =A0=A0=A0 the current draft).=20 =A0=A0=A0 This would leave one bit pattern reserved. 4. Move the distinguishing field, "Final Destination Address" into the = fixed part of the header (right after hops_left). Sequence number and = originator =A0=A0=A0 address would relocate after final destination address. This = does not waste any bits, but is esthetically unpleasant. But we may not = care about such =A0=A0=A0 things. Any others? Comments? Would the folks who are implementing this please express their = opinions? -gabriel ----- Original Message ---- From: Mario Mao To: gabriel montenegro Cc: 6lowpan@ietf.org Sent: Saturday, August 5, 2006 2:52:52 AM Subject: Some comments about draft-ietf-6lowpan-format-04 Hi Gabriel, =A0 There is some comments about the last draft, thanks. =A0 In Section 11, the draft mentions that a special format of "Mesh = Delivery" field should be used when Broadcast or Multicast. This kind of = field is called as=A0Mesh Broadcast or Multicast Delivery Field and=A0a = "Sequence Number" is added. =A0 For Source Node, it will be clear that which kind of format it should = use. But for Destination Node or Relay Node, looks like there will be = some confusion when they trying to explain this format. =A0 The cause of such confusion is the way inbound Node=A0identifying such = kind of field format. As the draft mentioned, the destination address is = the identification of such kind of field.=A0However,=A0for the Final = Destination Address is=A0behind=A0the Sequence Number, the inbound Node = will be unaware of the existence of this field before it check the Final = Destination Address. If inbound Node handle all Broadcast=A0Delivery = Field as the normal "Mesh Delivery" field, when it begins to check the = Final Destination Address, there=A0will be 8-bits shift of the right = position. This scenario must lead to an mistake. =A0 There is also another way to identify the Broadcast Delivery Field. That = is checking the destination MAC address in the IEEE 802.15.4=A0header = (0xFFFF).=A0But in practice, an IEEE 802.15.4 broadcast frame can't be = delivered to every END DEVICE (RFD). This is because the=A0END = DEVICE=A0disable its transceiver=A0during CAP when there is no frame = directly sent to it. =A0 To avoid such incorrect scenario, one flag may be needed in the fixed = filed (in Adaptation Header). That make all node could recognize the = special Broadcast Delivery Field in right way. =A0 Regards, Mario Mao MarioMao@Gmail.com =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Sep 09 17:01:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM9wk-0006zZ-V8; Sat, 09 Sep 2006 17:01:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM9wj-0006zR-Lq for 6lowpan@ietf.org; Sat, 09 Sep 2006 17:01:01 -0400 Received: from dash.upc.es ([147.83.2.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM9wd-0000XQ-BF for 6lowpan@ietf.org; Sat, 09 Sep 2006 17:01:01 -0400 Received: from localhost (wmail-mat.upc.es [147.83.39.70]) by dash.upc.es (8.13.1/8.13.1) with ESMTP id k88CnlR9026711; Fri, 8 Sep 2006 14:49:48 +0200 Received: from 147.83.39.42 ( [147.83.39.42]) as user peres@mat.upc.es by wmail-mat.upc.es with HTTP; Fri, 8 Sep 2006 14:44:37 +0200 Message-ID: <1157719477.450165b5899cd@wmail-mat.upc.es> Date: Fri, 8 Sep 2006 14:44:37 +0200 From: Pere Salvatella To: 6lowpan <6lowpan@ietf.org> Subject: RE: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 References: <7158315D3917854D9AD5B36BFF8CD3F13CC071@scorp01.corp.cmdinfo.com> In-Reply-To: <7158315D3917854D9AD5B36BFF8CD3F13CC071@scorp01.corp.cmdinfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 147.83.39.42 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (dash.upc.es [147.83.2.50]); Fri, 08 Sep 2006 14:49:48 +0200 (CEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: Josep Paradells , Carles Gomez X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Dave, Here in Wireless Network Group (WNG) from UPC we are currently developing an open-source free IPv6 6LowPAN stack for 802.15.4. Our platform environment is TelosB mote from CrossBow, the code is written in NesC and it runs over TinyOS on its first version (tinyos-1.x). We would like to ask you: on which platform/OS is your reference stack running? In which programming language is it written? We can keep in contact, to explore collaboration opportunities. Best regards, Pere Salvatella Quoting Dave Green : > Would anyone in this group be interested in working on an open-source free > (as in free beer) IPv6 6LowPAN stack for 802.15.4 if we make the project > available? The license would likely be creative commons. The first target > environment is a 32 bit ARM-7 controller. My company would supply the > reference stack for all to hack on and compile for their architectures. We > would do the ARM-7 port and hope others would port to their architectures and > post. This would create a license free alternative to Zigbee so we can buy > cheap sensor radios for our work. > > If interested, please let me know. I believe we could have this set up by > year's end. > > David Green | VP of R&D | Command Information > 13655 Dulles Technology Drive, Suite 100 | Herndon, VA 20171 > O: 703.561.5937 | M: 703.899.9663 | green@commandinformation.com > > > > > ________________________________________ > From: Mario Mao [mailto:mariomao@gmail.com] > Sent: Thursday, September 07, 2006 8:32 AM > To: gabriel montenegro > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 > > Hi Gabriel, > > Sorry for the delay, here are some comments about the newly modified > Broadcast field, thanks. > > About the option #4, I think it is a good way to solve the confusion. In > addition, here is the way we used, hope it could do some help, thanks. > > I remember I had suggested a way of introducing a "M" bit which indicates > Mesh Broadcast or Multicast Delivery Field immediately following the LoWPAN > header. The "M" will use one of the 4 rsv bits in fixed header and not affect > the alignment. > > 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|B| rsv |Payload (Mesh B/M Field)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > When encountering adaptation layer fragment, no more bit are free for the > special bit. However, we find it's a nightmare to broadcast fragments in > actual 802.15.4 network. The working channel would be full of broadcast > fragments even using kinds of optimized algorithm and the result is high > possibility of discarding and re-transmitting, and high energy-cost . So, to > avoid such situation, we decide to disable broadcast when the packet need to > be fragmented into several frames (ugly but useful way). With this strategy, > no modification to the fragment encapsulation header format is needed too. > > At last, I find some problem when impliment IPv6 header compression. Please > note Traffic Class and Flow Label bit in HC1. If we don't compress the two > field, 28 bits (that is three and half bytes) are sent. However, how to send > the half byte? As I know, most hardware could only transmit data in unit of > BYTE. Should we need 4 bits pending data? The workdaround we used is > combining the Traffic Class and Flow Label with Version field. So, the > Traffic Class and Flow Label bit becomes Version, Traffic Class and Flow > Label bit. Please see following as detail. > > Version, Traffic Class and Flow Label (bit 4): > 0: not compressed, full 4 bits for Version, 8 bits for Traffic Class and 20 > bits for Flow Label are sent > 1: Traffic Class and Flow Label are zero > > Best Regards, > > Mario Mao > ----- Original Message ----- > From: gabriel montenegro > To: gabriel montenegro ; Mario Mao > Cc: 6lowpan@ietf.org > Sent: Thursday, September 07, 2006 4:42 PM > Subject: Re: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 > > Since there has been no feedback on this, I will go with option #4 below > unless I hear otherwise within the next few > days. We can always revisit this during IETF LC. But if we make no decision > we will never get to IETF LC. > > -gabriel > ----- Original Message ---- > From: gabriel montenegro > To: Mario Mao > Cc: 6lowpan@ietf.org > Sent: Tuesday, August 8, 2006 8:56:24 AM > Subject: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 > Good point, yes. The confusion is that upon reception it is not easy to > determine which of the two following mesh header formats is being used > because > the fixed part of the header does not tell us: > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |O|F| Hops Left | Originator Address... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ...Final Destination Address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 10: Mesh Delivery > Field > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |O|F| Hops Left |Sequence Number| Originator Address... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ...Final Destination Address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 11: Mesh Broadcast or Multicast Delivery Field > We could put the indication in the fixed part of the header by : > > 1. adding a bit field to distinguish. Two alternatives: (a) We could add one > bit and move everything after it over one bit. Not that our alignment was > great to begin with, but this would make it uglier. (b) We could make > this bit field larger than 1 bit, in which case we'd be able > to distinguish between the two current formats and leave some bit > patterns reserved in case we end up defining other . > mesh headers in the future. > 2. adding a bit by stealing one from, say, hops_left. This means we'd have a > max of 32 hops instead of the current 64. I still think this > is enough. This would not alter whatever alignment we now have. > 3. Grow the 'F' field by one more bit, and assign bit patterns for 64 bit > address, 16-bit address and 16-bit bcast/mcast address (as per > the current draft). > This would leave one bit pattern reserved. > 4. Move the distinguishing field, "Final Destination Address" into the fixed > part of the header (right after hops_left). Sequence number and originator > address would relocate after final destination address. This does not > waste any bits, but is esthetically unpleasant. But we may not care about > such > things. > > Any others? > > Comments? Would the folks who are implementing this please express their > opinions? > > -gabriel > ----- Original Message ---- > From: Mario Mao > To: gabriel montenegro > Cc: 6lowpan@ietf.org > Sent: Saturday, August 5, 2006 2:52:52 AM > Subject: Some comments about draft-ietf-6lowpan-format-04 > Hi Gabriel, > > There is some comments about the last draft, thanks. > > In Section 11, the draft mentions that a special format of "Mesh Delivery" > field should be used when Broadcast or Multicast. This kind of field is > called as Mesh Broadcast or Multicast Delivery Field and a "Sequence Number" > is added. > > For Source Node, it will be clear that which kind of format it should use. > But for Destination Node or Relay Node, looks like there will be some > confusion when they trying to explain this format. > > The cause of such confusion is the way inbound Node identifying such kind of > field format. As the draft mentioned, the destination address is the > identification of such kind of field. However, for the Final Destination > Address is behind the Sequence Number, the inbound Node will be unaware of > the existence of this field before it check the Final Destination Address. If > inbound Node handle all Broadcast Delivery Field as the normal "Mesh > Delivery" field, when it begins to check the Final Destination Address, > there will be 8-bits shift of the right position. This scenario must lead to > an mistake. > > There is also another way to identify the Broadcast Delivery Field. That is > checking the destination MAC address in the IEEE 802.15.4 header > (0xFFFF). But in practice, an IEEE 802.15.4 broadcast frame can't be > delivered to every END DEVICE (RFD). This is because the END DEVICE disable > its transceiver during CAP when there is no frame directly sent to it. > > To avoid such incorrect scenario, one flag may be needed in the fixed filed > (in Adaptation Header). That make all node could recognize the special > Broadcast Delivery Field in right way. > > Regards, > > Mario Mao > MarioMao@Gmail.com > > > _______________________________________________ > 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 > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan