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 From 6lowpan-bounces@ietf.org Sat Sep 16 18:15:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOiRM-0005O1-JI; Sat, 16 Sep 2006 18:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOiRL-0005Nq-31 for 6lowpan@ietf.org; Sat, 16 Sep 2006 18:15:11 -0400 Received: from dash.upc.es ([147.83.2.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOiRJ-0000ys-PB for 6lowpan@ietf.org; Sat, 16 Sep 2006 18:15:11 -0400 Received: from mat.upc.es (mat.upc.es [147.83.39.3]) by dash.upc.es (8.13.1/8.13.1) with ESMTP id k8GMF6gL025486; Sun, 17 Sep 2006 00:15:06 +0200 Received: from [147.83.113.31] (portgomis.upc.es [147.83.113.31]) by mat.upc.es (Postfix) with ESMTP id 287573399F; Sun, 17 Sep 2006 00:20:03 +0200 (MET DST) Message-ID: <450C77D9.6040603@mat.upc.es> Date: Sun, 17 Sep 2006 00:16:57 +0200 From: =?ISO-8859-1?Q?Carles_G=F3mez?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mario Mao , 6lowpan@ietf.org Subject: Re: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04 References: <20060907084238.60898.qmail@web81908.mail.mud.yahoo.com> <007001c6d279$90ade8b0$7fc0a8c0@netlab.cs.ecnu.edu.cn> In-Reply-To: <007001c6d279$90ade8b0$7fc0a8c0@netlab.cs.ecnu.edu.cn> 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]); Sun, 17 Sep 2006 00:15:07 +0200 (CEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0989257601==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0989257601== Content-Type: multipart/alternative; boundary="------------050900040403010008080209" This is a multi-part message in MIME format. --------------050900040403010008080209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, I would like to express the opinion our group has about this topic. To sum up, our preferences are, in decreasing order: - Option proposed by Mario Mao (i.e. using a reserved bit) - Option 4 (i.e. "final address moved up") - Others like options 2 and 3, which are assumable We would rather discourage option 1, since it would add complexity in handling bits instead of bytes. Best regards, Carles Gomez Wireless Networks Group Technical University of Catalonia Mario Mao wrote: > 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 > > --------------050900040403010008080209 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit      Dear all,
 
     I would like to express the opinion our group has about this topic. To
sum up, our preferences are, in decreasing order:
 
     - Option proposed by Mario Mao (i.e. using a reserved bit)
     - Option 4 (i.e. "final address moved up")
     - Others like options 2 and 3, which are assumable
 
    We would rather discourage option 1, since it would add complexity in handling bits instead of bytes.

     Best regards,
 
     Carles Gomez
     Wireless Networks Group
     Technical University of Catalonia

Mario Mao wrote:
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 -----
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 <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


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

--------------050900040403010008080209-- --===============0989257601== 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 --===============0989257601==-- From 6lowpan-bounces@ietf.org Thu Sep 21 01:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQGx3-0004Xh-9n; Thu, 21 Sep 2006 01:18:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQGx1-0004Xc-Ri for 6lowpan@ietf.org; Thu, 21 Sep 2006 01:18:19 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQGwx-0000D9-3I for 6lowpan@ietf.org; Thu, 21 Sep 2006 01:18:19 -0400 Received: by ug-out-1314.google.com with SMTP id 72so81189ugd for <6lowpan@ietf.org>; Wed, 20 Sep 2006 22:18:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ftgQCwCSS2IfCu+X94mUt7lmG/p0dyUBMDu8kAN0XEOAtMc9xgFFPP18uKpdB/IMHhZQ0jLb4BgZ6tO8/WVi2D+DPXidQsvOWgBt4N+XGuvfKUxSBNAn+5NAnLgk1Y3bvcoQKfe0WZM4Z7nL75CnogR3jSd7XSgPAmjmnj93ga4= Received: by 10.67.93.6 with SMTP id v6mr8863256ugl; Wed, 20 Sep 2006 22:18:13 -0700 (PDT) Received: by 10.67.91.9 with HTTP; Wed, 20 Sep 2006 22:18:13 -0700 (PDT) Message-ID: Date: Wed, 20 Sep 2006 22:18:13 -0700 From: "David Culler" To: 6lowpan@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [6lowpan] Mesh Delivery Field 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="===============1639817303==" Errors-To: 6lowpan-bounces@ietf.org --===============1639817303== Content-Type: multipart/alternative; boundary="----=_Part_178_25813958.1158815893841" ------=_Part_178_25813958.1158815893841 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear All, I would like to raise a concern about the Mesh Delivery Field definition in Section 11 of the format document. While the actual mesh routing protocol is appropriately outside the scope of the 6lowpan Format document, that format needs provide the raw structure upon which rough consensus and running code can be flourish. We know that low power wireless mesh routing is technically tricky and strongly influenced by target traffic load, power management profile, network design, and so on. Thus, it is reasonable to expect that the consensus building and technical refinement process will require on-going experience with protocol and implementation alternatives. The 6lowpan format document should support this process, although it should not dictate its conclusion. Based on past experience with IP layer 3 routing and with past internally routed links, we can establish a few primary goals for the expressiveness of the 6lowpan Mesh Delivery Field. (1) It should support the visibility into the routed 15.4 cloud necessary to develop, debug, diagnose, and manage the 15.4 cloud. (2) It should support the ability to define, develop and compare routing protocols and possibly support the presence of multiple protocols for widely differing usage cases. (3) It needs to be possible for nodes to communicate with other nodes in the cloud in order to discover and negotiate joining the cloud without joining the cloud a priori through some mechanism that is opaque to IP and above. (1) has historically been addressed through various forms of source routing. It should be possible to do the equivalent of traceroute through the 15.4 mesh and this should be accessible in some form through IP so higher layers can be built to perform the management. The current Mesh Delivery Field definition seems to prohibit any form of source routing. It assumes that the routing tables are all set up and correct so that the forwarder can "swizzle" the destination address field of the 15.4 header with a table entry. (The experience of IP over ATM and the thousands of pages of the Q83b signalling protocol required to set up all the tables in advance ought to give us a little pause here.) The idea of supporting table-driven routing and thereby separating the route formation from the forwarding engine is a good one, but there needs to be enough expressive power to support the protocols that will establish and manage those tables (rather than relying on an opaque out-of-band signaling mechanism) and there needs to be the ability to query and validate those tables without relying on out-of-band mechanisms. (2) has historically be addressed with protocol identifiers and options. As we went through the various RIP, OSPF, etc. we didn't need to go back and redefine the format documents. There was enough expressiveness for topology formation and routing to evolve. Not all networks need to support all protocols. That has been the network designers' determination. The underlying structure provided the primitives, allowing solutions (and consensus) to evolve. We want to avoid creating a "winner take all" structure where there is no room for evolution and development. It is possible that AODV, or TinyAODV, or DSR, or GPSR or possibly one of several other alternatives is the right solution. However, there is little evidence of one having clear superiority at this time, despite numerous high profile efforts. We should be defining the canvas upon which competing alternatives can be defined and vetted. (3) has historically been addressed by a limited ability to communicate on the link to a crudely defined set of nodes in order to bootstrap the discovery, join, address assignment, negotiation, etc. Most successful links under IP look either like a broadcast medium or a point-to-point link (a degenerative broadcast). This allows ARP, RARP, BOOTP, DHCP, etc. to gain higher level accessibility and addressibility through the link. Links that require complex signaling, discovery, joining and coordnation below the link layer, including ATM, Bluetooth (piconets and scatter nets), and IRDA have proved onerous for IP and have been relegated to far less general usage scenarios - such as the desktop USB replacement. Even though the radio is a broadcast medium, the challenge in a routed link is that the link is not by default a link-wide broadcast phy. There are two natural notions of "broadcast" in a lowpan. (i) The physical neighbors that happen to receive a transmission because they are close enough to pick up the signal and have their radios turned on to receive. (ii) The entire collection of nodes that can be reached by a multihop dissemination (flood). Both of these are extremely useful in bootstrapping higher levels, including routing, and should be addressed in the format document. Additionally, it is not neccessary to use the 802.15.4 beaconing mechanism to bring up IP over a 15.4 link. Providing some forms of broadcast using data frames makes the 802.15.4 format much more like 802.11 and other links that have proved very suitable for IP. Few, if any, of the public 15.4 routing layers developed by the TinyOS community utilize beacon packets. The recognition that the current Mesh Delivery field may be to restrictive is intimated by the need to define a second form of the header for multicast (and link local broadcast) that includes a sequence number. The mesh header field type is defined by whether the destination address is unicast or multicast. The document states that the use of such a sequence number is out of scope. However, the observation that that extra information may need to be included depending on how packets are routed further suggests that more careful format definition is needed to support future development of mesh routing. Have folks who have been developing mesh layers for lowpan6 felt that the existing Mesh Delivery Field is too restrictive? David E. Culler UC Berkeley culler@cs.berkeley.edu ------=_Part_178_25813958.1158815893841 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear All,

I would like to raise a concern about the Mesh Delivery Field
definition in Section 11 of the format document.  While the actual
mesh routing protocol is appropriately outside the scope of the
6lowpan Format document, that format needs provide the raw structure
upon which rough consensus and running code can be flourish.  We
know that low power wireless mesh routing is technically tricky and
strongly influenced by target traffic load, power management profile,
network design, and so on.  Thus, it is reasonable to expect that the
consensus building and technical refinement process will require
on-going experience with protocol and implementation alternatives.
The 6lowpan format document should support this process, although it
should not dictate its conclusion.

Based on past experience with IP layer 3 routing and with past
internally routed links, we can establish a few primary goals for the
expressiveness of the 6lowpan Mesh Delivery Field.
   (1) It should support the visibility into the routed 15.4 cloud
necessary to develop, debug, diagnose, and manage the 15.4 cloud.
   (2) It should support the ability to define, develop and compare
routing protocols and possibly support the presence of multiple
protocols for widely differing usage cases.
   (3) It needs to be possible for nodes to communicate with other nodes
in the cloud in order to discover and negotiate joining the cloud
without joining the cloud a priori through some mechanism that is
opaque to IP and above.

(1) has historically been addressed through various forms of source
routing.  It should be possible to do the equivalent of traceroute
through the 15.4 mesh and this should be accessible in some form through IP so
higher layers can be built to perform the management.  The current
Mesh Delivery Field definition seems to prohibit any form of source routing.
It assumes that the routing tables are all set up and correct so that
the forwarder can "swizzle" the destination address field of the 15.4
header with a table entry.  (The experience of IP over ATM and the
thousands of pages of the Q83b signalling protocol required to set up
all the tables in advance ought to give us a little pause here.)  The
idea of supporting table-driven routing and thereby separating the
route formation from the forwarding engine is a good one, but there
needs to be enough expressive power to support the protocols that will
establish and manage those tables (rather than relying on an opaque
out-of-band signaling mechanism) and there needs to be the ability to
query and validate those tables without relying on out-of-band
mechanisms.

(2) has historically be addressed with protocol identifiers and
options.  As we went through the various RIP, OSPF, etc. we didn't
need to go back and redefine the format documents.  There was enough
expressiveness for topology formation and routing to evolve.  Not all
networks need to support all protocols.  That has been the network
designers' determination.  The underlying structure provided the
primitives, allowing solutions (and consensus) to evolve.  We want to
avoid creating a "winner take all" structure where there is no room
for evolution and development.  It is possible that AODV, or TinyAODV,
or DSR, or GPSR or possibly one of several other alternatives is the right
solution.  However, there is little evidence of one having clear superiority at
this time, despite numerous high profile efforts.  We should be defining the
canvas upon which competing alternatives can be defined and vetted.

(3) has historically been addressed by a limited ability to
communicate on the link to a crudely defined set of nodes in order to
bootstrap the discovery, join, address assignment, negotiation, etc.
Most successful links under IP look either like a broadcast medium or
a point-to-point link (a degenerative broadcast).  This allows ARP,
RARP, BOOTP, DHCP, etc. to gain higher level accessibility and
addressibility through the link.  Links that require complex
signaling, discovery, joining and coordnation below the link layer,
including ATM, Bluetooth (piconets and scatter nets), and IRDA have
proved onerous for IP and have been relegated to far less general
usage scenarios - such as the desktop USB replacement.  Even though
the radio is a broadcast medium, the challenge in a routed link is
that the link is not by default a link-wide broadcast phy.  There
are two natural notions of "broadcast" in a lowpan.  (i) The physical
neighbors that happen to receive a transmission because they are close
enough to pick up the signal and have their radios turned on to
receive.  (ii) The entire collection of nodes that can be reached by a
multihop dissemination (flood).  Both of these are extremely useful in
bootstrapping higher levels, including routing, and should be
addressed in the format document.  Additionally, it is not
neccessary to use the 802.15.4 beaconing mechanism to bring up IP over
a 15.4 link.  Providing some forms of broadcast using data frames
makes the 802.15.4 format much more like 802.11 and other links that
have proved very suitable for IP.  Few, if any, of the public 15.4 routing layers developed
by the TinyOS community utilize beacon packets.

The recognition that the current Mesh Delivery field may be to restrictive
is intimated by the need to define a second form of the header for
multicast (and link local broadcast) that includes a sequence number.
The mesh header field type is defined by whether the destination
address is unicast or multicast. The document states that the use of
such a sequence number is out of scope. However, the observation that
that extra information may need to be included depending on how
packets are routed further suggests that more careful format
definition is needed to support future development of mesh routing.

Have folks who have been developing mesh layers for lowpan6 felt that
the existing Mesh Delivery Field is too restrictive?


David E. Culler
UC Berkeley
culler@cs.berkeley.edu



------=_Part_178_25813958.1158815893841-- --===============1639817303== 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 --===============1639817303==-- From 6lowpan-bounces@ietf.org Fri Sep 22 05:24:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQhGJ-0003pu-5a; Fri, 22 Sep 2006 05:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQhGH-0003pZ-Mz for 6lowpan@ietf.org; Fri, 22 Sep 2006 05:23:57 -0400 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQhGH-0005Qk-A3 for 6lowpan@ietf.org; Fri, 22 Sep 2006 05:23:57 -0400 Received: by wx-out-0506.google.com with SMTP id s8so917045wxc for <6lowpan@ietf.org>; Fri, 22 Sep 2006 02:23:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C8S0iLSUfvgkf4511mi98meLK4HaExDoKouIvt5f40vtO72GAgnJyPRaY6jDtjscnJaU3yJPZ1LWjg4julnc6wmGKNMlfjHw/k9fufikGQ9+t53qIZCR0Ht8OaKmTVzG/K6/twK3aL9vV+lOCSHxBZIs7tvQFf4q1XomrhQTXe0= Received: by 10.70.87.5 with SMTP id k5mr643878wxb; Fri, 22 Sep 2006 02:23:56 -0700 (PDT) Received: by 10.70.27.14 with HTTP; Fri, 22 Sep 2006 02:23:56 -0700 (PDT) Message-ID: Date: Fri, 22 Sep 2006 19:23:56 +1000 From: "Soohong Daniel Park" To: "David Culler" Subject: Re: [6lowpan] Mesh Delivery Field In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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 David, First off, your issue raising in this thread seems too late since our official WGLC was expired: "This Last Call will end on Wednesday 02 August 2006 at 2359 UTC." Anyway, my sense is not to take Mesh issue at this stage. As long as we are looking at the 6lowpan solution format, mesh is out of scope of that. In fact, as far as I am concern, mesh belongs to 15.4 technology based on MAC layer. Instead, as described in the rechartering, we will go through adhoc issue based on IP layer. That's why we are here in 6lowpan wg of ietf. But, some staffs described in your mail seem helpful from the 6lowpan perspective, especially IPv6 related stuffs. If allowed, please bring your concern to the next 6lowpan face-to-face meeting in San Diego. Then, we will have further details in there I believe... -- Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. On 9/21/06, David Culler wrote: > Dear All, > > I would like to raise a concern about the Mesh Delivery Field > definition in Section 11 of the format document. While the actual > mesh routing protocol is appropriately outside the scope of the > 6lowpan Format document, that format needs provide the raw structure > upon which rough consensus and running code can be flourish. We > know that low power wireless mesh routing is technically tricky and > strongly influenced by target traffic load, power management profile, > network design, and so on. Thus, it is reasonable to expect that the > consensus building and technical refinement process will require > on-going experience with protocol and implementation alternatives. > The 6lowpan format document should support this process, although it > should not dictate its conclusion. > > Based on past experience with IP layer 3 routing and with past > internally routed links, we can establish a few primary goals for the > expressiveness of the 6lowpan Mesh Delivery Field. > (1) It should support the visibility into the routed 15.4 cloud > necessary to develop, debug, diagnose, and manage the 15.4 cloud. > (2) It should support the ability to define, develop and compare > routing protocols and possibly support the presence of multiple > protocols for widely differing usage cases. > (3) It needs to be possible for nodes to communicate with other nodes > in the cloud in order to discover and negotiate joining the cloud > without joining the cloud a priori through some mechanism that is > opaque to IP and above. > > (1) has historically been addressed through various forms of source > routing. It should be possible to do the equivalent of traceroute > through the 15.4 mesh and this should be accessible in some form through IP > so > higher layers can be built to perform the management. The current > Mesh Delivery Field definition seems to prohibit any form of source routing. > It assumes that the routing tables are all set up and correct so that > the forwarder can "swizzle" the destination address field of the 15.4 > header with a table entry. (The experience of IP over ATM and the > thousands of pages of the Q83b signalling protocol required to set up > all the tables in advance ought to give us a little pause here.) The > idea of supporting table-driven routing and thereby separating the > route formation from the forwarding engine is a good one, but there > needs to be enough expressive power to support the protocols that will > establish and manage those tables (rather than relying on an opaque > out-of-band signaling mechanism) and there needs to be the ability to > query and validate those tables without relying on out-of-band > mechanisms. > > (2) has historically be addressed with protocol identifiers and > options. As we went through the various RIP, OSPF, etc. we didn't > need to go back and redefine the format documents. There was enough > expressiveness for topology formation and routing to evolve. Not all > networks need to support all protocols. That has been the network > designers' determination. The underlying structure provided the > primitives, allowing solutions (and consensus) to evolve. We want to > avoid creating a "winner take all" structure where there is no room > for evolution and development. It is possible that AODV, or TinyAODV, > or DSR, or GPSR or possibly one of several other alternatives is the right > solution. However, there is little evidence of one having clear superiority > at > this time, despite numerous high profile efforts. We should be defining the > canvas upon which competing alternatives can be defined and vetted. > > (3) has historically been addressed by a limited ability to > communicate on the link to a crudely defined set of nodes in order to > bootstrap the discovery, join, address assignment, negotiation, etc. > Most successful links under IP look either like a broadcast medium or > a point-to-point link (a degenerative broadcast). This allows ARP, > RARP, BOOTP, DHCP, etc. to gain higher level accessibility and > addressibility through the link. Links that require complex > signaling, discovery, joining and coordnation below the link layer, > including ATM, Bluetooth (piconets and scatter nets), and IRDA have > proved onerous for IP and have been relegated to far less general > usage scenarios - such as the desktop USB replacement. Even though > the radio is a broadcast medium, the challenge in a routed link is > that the link is not by default a link-wide broadcast phy. There > are two natural notions of "broadcast" in a lowpan. (i) The physical > neighbors that happen to receive a transmission because they are close > enough to pick up the signal and have their radios turned on to > receive. (ii) The entire collection of nodes that can be reached by a > multihop dissemination (flood). Both of these are extremely useful in > bootstrapping higher levels, including routing, and should be > addressed in the format document. Additionally, it is not > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over > a 15.4 link. Providing some forms of broadcast using data frames > makes the 802.15.4 format much more like 802.11 and other links that > have proved very suitable for IP. Few, if any, of the public 15.4 routing > layers developed > by the TinyOS community utilize beacon packets. > > The recognition that the current Mesh Delivery field may be to restrictive > is intimated by the need to define a second form of the header for > multicast (and link local broadcast) that includes a sequence number. > The mesh header field type is defined by whether the destination > address is unicast or multicast. The document states that the use of > such a sequence number is out of scope. However, the observation that > that extra information may need to be included depending on how > packets are routed further suggests that more careful format > definition is needed to support future development of mesh routing. > > Have folks who have been developing mesh layers for lowpan6 felt that > the existing Mesh Delivery Field is too restrictive? > > > David E. Culler > UC Berkeley > culler@cs.berkeley.edu > > > > > _______________________________________________ > 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 Sep 22 09:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlPl-00035b-NR; Fri, 22 Sep 2006 09:50:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlPk-000335-AD for 6lowpan@ietf.org; Fri, 22 Sep 2006 09:50:00 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlPe-0007dy-ON for 6lowpan@ietf.org; Fri, 22 Sep 2006 09:50:00 -0400 Received: from [61.85.6.26] ([61.85.6.26]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id k8MDnes5021829; Fri, 22 Sep 2006 07:49:40 -0600 (MDT) Subject: Re: [6lowpan] Mesh Delivery Field From: Geoff Mulligan To: Soohong Daniel Park In-Reply-To: References: Content-Type: text/plain Date: Fri, 22 Sep 2006 07:41:21 -0600 Message-Id: <1158932481.5028.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: 6lowpan@ietf.org, David Culler X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Daniel, While the WG last call did expire, I'm not sure if David is too late. I think that he raises some important concerns and I'm not sure that we really have consensus on the mesh delivery field. I would like to hear from the list on this. I think that Gabriel has put forth 4 alternatives. Carsten indicated that he thought he might have a different alternative and would post to the list either the alternative or his consideration of the 4 alternatives - Carsten, please send your thoughts. I feel that the issue David raises should be dealt with by the WG because I do not want to send the draft on to the IESG only to have these issues brought up in the IETF last call. These seem rather fundamental to me and we might look rather foolish not having resolved this in the working group! We need some significant discussion from the members of the WG. This WG has been, my self included, rather quiet and as a result we have moved at a snails pace getting anything done. I implore everyone to take time and read the thread on the mesh field and send your thoughts, pro, con or otherwise to this list. If everyone continues to be apathetic about this work, I hold little hope for this WG being rechartered to do any other work! geoff On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote: > David, > > First off, your issue raising in this thread seems too late since our > official WGLC was expired: "This Last Call will end on Wednesday 02 > August 2006 at 2359 UTC." > > Anyway, my sense is not to take Mesh issue at this stage. As long as > we are looking at the 6lowpan solution format, mesh is out of scope of > that. In fact, as far as I am concern, mesh belongs to 15.4 technology > based on MAC layer. Instead, as described in the rechartering, we will > go through adhoc issue based on IP layer. That's why we are here in > 6lowpan wg of ietf. > > But, some staffs described in your mail seem helpful from the 6lowpan > perspective, especially IPv6 related stuffs. If allowed, please bring > your concern to the next 6lowpan face-to-face meeting in San Diego. > Then, we will have further details in there I believe... > > -- > > > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. > > > > On 9/21/06, David Culler wrote: > > Dear All, > > > > I would like to raise a concern about the Mesh Delivery Field > > definition in Section 11 of the format document. While the actual > > mesh routing protocol is appropriately outside the scope of the > > 6lowpan Format document, that format needs provide the raw structure > > upon which rough consensus and running code can be flourish. We > > know that low power wireless mesh routing is technically tricky and > > strongly influenced by target traffic load, power management profile, > > network design, and so on. Thus, it is reasonable to expect that the > > consensus building and technical refinement process will require > > on-going experience with protocol and implementation alternatives. > > The 6lowpan format document should support this process, although it > > should not dictate its conclusion. > > > > Based on past experience with IP layer 3 routing and with past > > internally routed links, we can establish a few primary goals for the > > expressiveness of the 6lowpan Mesh Delivery Field. > > (1) It should support the visibility into the routed 15.4 cloud > > necessary to develop, debug, diagnose, and manage the 15.4 cloud. > > (2) It should support the ability to define, develop and compare > > routing protocols and possibly support the presence of multiple > > protocols for widely differing usage cases. > > (3) It needs to be possible for nodes to communicate with other nodes > > in the cloud in order to discover and negotiate joining the cloud > > without joining the cloud a priori through some mechanism that is > > opaque to IP and above. > > > > (1) has historically been addressed through various forms of source > > routing. It should be possible to do the equivalent of traceroute > > through the 15.4 mesh and this should be accessible in some form through IP > > so > > higher layers can be built to perform the management. The current > > Mesh Delivery Field definition seems to prohibit any form of source routing. > > It assumes that the routing tables are all set up and correct so that > > the forwarder can "swizzle" the destination address field of the 15.4 > > header with a table entry. (The experience of IP over ATM and the > > thousands of pages of the Q83b signalling protocol required to set up > > all the tables in advance ought to give us a little pause here.) The > > idea of supporting table-driven routing and thereby separating the > > route formation from the forwarding engine is a good one, but there > > needs to be enough expressive power to support the protocols that will > > establish and manage those tables (rather than relying on an opaque > > out-of-band signaling mechanism) and there needs to be the ability to > > query and validate those tables without relying on out-of-band > > mechanisms. > > > > (2) has historically be addressed with protocol identifiers and > > options. As we went through the various RIP, OSPF, etc. we didn't > > need to go back and redefine the format documents. There was enough > > expressiveness for topology formation and routing to evolve. Not all > > networks need to support all protocols. That has been the network > > designers' determination. The underlying structure provided the > > primitives, allowing solutions (and consensus) to evolve. We want to > > avoid creating a "winner take all" structure where there is no room > > for evolution and development. It is possible that AODV, or TinyAODV, > > or DSR, or GPSR or possibly one of several other alternatives is the right > > solution. However, there is little evidence of one having clear superiority > > at > > this time, despite numerous high profile efforts. We should be defining the > > canvas upon which competing alternatives can be defined and vetted. > > > > (3) has historically been addressed by a limited ability to > > communicate on the link to a crudely defined set of nodes in order to > > bootstrap the discovery, join, address assignment, negotiation, etc. > > Most successful links under IP look either like a broadcast medium or > > a point-to-point link (a degenerative broadcast). This allows ARP, > > RARP, BOOTP, DHCP, etc. to gain higher level accessibility and > > addressibility through the link. Links that require complex > > signaling, discovery, joining and coordnation below the link layer, > > including ATM, Bluetooth (piconets and scatter nets), and IRDA have > > proved onerous for IP and have been relegated to far less general > > usage scenarios - such as the desktop USB replacement. Even though > > the radio is a broadcast medium, the challenge in a routed link is > > that the link is not by default a link-wide broadcast phy. There > > are two natural notions of "broadcast" in a lowpan. (i) The physical > > neighbors that happen to receive a transmission because they are close > > enough to pick up the signal and have their radios turned on to > > receive. (ii) The entire collection of nodes that can be reached by a > > multihop dissemination (flood). Both of these are extremely useful in > > bootstrapping higher levels, including routing, and should be > > addressed in the format document. Additionally, it is not > > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over > > a 15.4 link. Providing some forms of broadcast using data frames > > makes the 802.15.4 format much more like 802.11 and other links that > > have proved very suitable for IP. Few, if any, of the public 15.4 routing > > layers developed > > by the TinyOS community utilize beacon packets. > > > > The recognition that the current Mesh Delivery field may be to restrictive > > is intimated by the need to define a second form of the header for > > multicast (and link local broadcast) that includes a sequence number. > > The mesh header field type is defined by whether the destination > > address is unicast or multicast. The document states that the use of > > such a sequence number is out of scope. However, the observation that > > that extra information may need to be included depending on how > > packets are routed further suggests that more careful format > > definition is needed to support future development of mesh routing. > > > > Have folks who have been developing mesh layers for lowpan6 felt that > > the existing Mesh Delivery Field is too restrictive? > > > > > > David E. Culler > > UC Berkeley > > culler@cs.berkeley.edu > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Sep 22 12:02:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQnTq-0005CA-RV; Fri, 22 Sep 2006 12:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQnTo-00053F-Hk for 6lowpan@ietf.org; Fri, 22 Sep 2006 12:02:20 -0400 Received: from web81909.mail.mud.yahoo.com ([68.142.207.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQnTn-00076W-9Q for 6lowpan@ietf.org; Fri, 22 Sep 2006 12:02:20 -0400 Received: (qmail 15339 invoked by uid 60001); 22 Sep 2006 16:02:18 -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=CgVtAuY7xqw66b8Yrry5iOhoQAdyNHDov4TISVlph1BMg+qPHOsnmGqE7ru/3Yh8HObaxUeNgHxTH4E8fhGjWNbzwc2U+Z/Py+LmigdqB1y8GcPiQTmzYbSbdmUiJXUAUzhUyWgdVK4VMrGq3YTnZ7x0/5U9u+tbCd+9zOlZ2Bk= ; Message-ID: <20060922160218.15337.qmail@web81909.mail.mud.yahoo.com> Received: from [24.16.14.130] by web81909.mail.mud.yahoo.com via HTTP; Fri, 22 Sep 2006 09:02:18 PDT Date: Fri, 22 Sep 2006 09:02:18 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Mesh Delivery Field To: Geoff Mulligan , Soohong Daniel Park In-Reply-To: <1158932481.5028.7.camel@localhost> MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: 6lowpan@ietf.org, David Culler 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="===============0184306867==" Errors-To: 6lowpan-bounces@ietf.org --===============0184306867== Content-Type: multipart/alternative; boundary="0-705944577-1158940938=:13686" --0-705944577-1158940938=:13686 Content-Type: text/plain; charset=us-ascii First of all, Thanks David for your thoughtful message. It's great to see you participate in this forum and I hope you'll stick around! >From the point of view of laying the technology foundation, everything in your message is quite relevant. >From the point of view of WG management, I'm trying to figure out if we need to act on all of it right now or if there are things we can address independently of the format draft under discussion. For example, you bring up the topic of traceroute type functionality. In IP, this is carried over ICMP, a separate management control plane. Since what we have in the format draft is a multiplexing layer, we can define a new protocol value to carry out the management protocol packets. The question is if the current format provides the required mechanism to go do work on such a separate protocol in another draft. Intuitively, it seems like this would work. Someone (your group, David?) could define such a protocol with functionality similar to ICMP for pings, traceroute, etc and provide the route gathering functionality, the echo response, etc in that separate draft. Conceivably, it would not necessarily use the mesh delivery header, as it would provide its own facility to record hop-by-hop route information within its own protocol fields. It could use loose source routing in which case some use of the mesh delivery header might be appropriate as well. Would such an approach work, David? This would actually play into one of the items slated for the next round of 6lowpan (if we ever recharter) to strengthen diagnosability or management of these networks. As for your point about us not knowing exactly what the header format must look like at this point in time, this is perhaps something we need to take into consideration right now. For example, this input would push us into reserving at least a couple of bits in the header for future expansion. A while back Vipul was arguing for a "version" field. Not sure if such a field is required or if the current reserved fields are enough. Mario Mao's proposal uses one of those reserved bits to solve the issue under discussion regarding the mesh delivery header variants for unicast vs mcast/bcast. There has been one group expressing support for this, so perhaps we already have the necessary mechanism in place in the header. David, you also mention the need to support different routing protocols side-by-side for comparison. This is one of the design goals of the format document. As I mentioned, the protocol field allows one to carry different protocols. We currently have proposals for a 6lowpan adaptations of AODV, a DyMO and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps BVR is next. The point is that the format document does provide the mechanism to define any such protocol, or is there a limitation you can see in the current document? If so, what needs to change? As for the claim that sub-IP benefits from simpler structures, my interpretation is that you're suggesting it is better not to use the mesh delivery header and let IP deal with the underlying individual collection of links. If so, one can ignore the mesh delivery header (not use it) and use the other parts of the format document to simply layer IP on top. This approach would then make use of other activities like AUTOCONF or MANET to create meshes if so desired. Personally, I see that *if* one wishes to do a mesh, not doing it in the sub-IP layer just pushes to problem upwards into the IP routing realm, and this just makes things even more complex than doing it under sub-IP. Complexity will be there no matter what, it's just a question of where one wants to address it. I do note that sub-IP complex structures are very popular and deployed in some cases (802.1d bridged networks). Perhaps likely to become even more so with 802.11s within a few years. I would not be interested in pursuing an AUTOCONF path, but think it should be possible to do so for those so inclined. Does this sound doable? Again, my immediate concern is that the format document not prevent this approach. -gabriel ----- Original Message ---- From: Geoff Mulligan To: Soohong Daniel Park Cc: 6lowpan@ietf.org; David Culler Sent: Friday, September 22, 2006 6:41:21 AM Subject: Re: [6lowpan] Mesh Delivery Field Daniel, While the WG last call did expire, I'm not sure if David is too late. I think that he raises some important concerns and I'm not sure that we really have consensus on the mesh delivery field. I would like to hear from the list on this. I think that Gabriel has put forth 4 alternatives. Carsten indicated that he thought he might have a different alternative and would post to the list either the alternative or his consideration of the 4 alternatives - Carsten, please send your thoughts. I feel that the issue David raises should be dealt with by the WG because I do not want to send the draft on to the IESG only to have these issues brought up in the IETF last call. These seem rather fundamental to me and we might look rather foolish not having resolved this in the working group! We need some significant discussion from the members of the WG. This WG has been, my self included, rather quiet and as a result we have moved at a snails pace getting anything done. I implore everyone to take time and read the thread on the mesh field and send your thoughts, pro, con or otherwise to this list. If everyone continues to be apathetic about this work, I hold little hope for this WG being rechartered to do any other work! geoff On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote: > David, > > First off, your issue raising in this thread seems too late since our > official WGLC was expired: "This Last Call will end on Wednesday 02 > August 2006 at 2359 UTC." > > Anyway, my sense is not to take Mesh issue at this stage. As long as > we are looking at the 6lowpan solution format, mesh is out of scope of > that. In fact, as far as I am concern, mesh belongs to 15.4 technology > based on MAC layer. Instead, as described in the rechartering, we will > go through adhoc issue based on IP layer. That's why we are here in > 6lowpan wg of ietf. > > But, some staffs described in your mail seem helpful from the 6lowpan > perspective, especially IPv6 related stuffs. If allowed, please bring > your concern to the next 6lowpan face-to-face meeting in San Diego. > Then, we will have further details in there I believe... > > -- > > > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. > > > > On 9/21/06, David Culler wrote: > > Dear All, > > > > I would like to raise a concern about the Mesh Delivery Field > > definition in Section 11 of the format document. While the actual > > mesh routing protocol is appropriately outside the scope of the > > 6lowpan Format document, that format needs provide the raw structure > > upon which rough consensus and running code can be flourish. We > > know that low power wireless mesh routing is technically tricky and > > strongly influenced by target traffic load, power management profile, > > network design, and so on. Thus, it is reasonable to expect that the > > consensus building and technical refinement process will require > > on-going experience with protocol and implementation alternatives. > > The 6lowpan format document should support this process, although it > > should not dictate its conclusion. > > > > Based on past experience with IP layer 3 routing and with past > > internally routed links, we can establish a few primary goals for the > > expressiveness of the 6lowpan Mesh Delivery Field. > > (1) It should support the visibility into the routed 15.4 cloud > > necessary to develop, debug, diagnose, and manage the 15.4 cloud. > > (2) It should support the ability to define, develop and compare > > routing protocols and possibly support the presence of multiple > > protocols for widely differing usage cases. > > (3) It needs to be possible for nodes to communicate with other nodes > > in the cloud in order to discover and negotiate joining the cloud > > without joining the cloud a priori through some mechanism that is > > opaque to IP and above. > > > > (1) has historically been addressed through various forms of source > > routing. It should be possible to do the equivalent of traceroute > > through the 15.4 mesh and this should be accessible in some form through IP > > so > > higher layers can be built to perform the management. The current > > Mesh Delivery Field definition seems to prohibit any form of source routing. > > It assumes that the routing tables are all set up and correct so that > > the forwarder can "swizzle" the destination address field of the 15.4 > > header with a table entry. (The experience of IP over ATM and the > > thousands of pages of the Q83b signalling protocol required to set up > > all the tables in advance ought to give us a little pause here.) The > > idea of supporting table-driven routing and thereby separating the > > route formation from the forwarding engine is a good one, but there > > needs to be enough expressive power to support the protocols that will > > establish and manage those tables (rather than relying on an opaque > > out-of-band signaling mechanism) and there needs to be the ability to > > query and validate those tables without relying on out-of-band > > mechanisms. > > > > (2) has historically be addressed with protocol identifiers and > > options. As we went through the various RIP, OSPF, etc. we didn't > > need to go back and redefine the format documents. There was enough > > expressiveness for topology formation and routing to evolve. Not all > > networks need to support all protocols. That has been the network > > designers' determination. The underlying structure provided the > > primitives, allowing solutions (and consensus) to evolve. We want to > > avoid creating a "winner take all" structure where there is no room > > for evolution and development. It is possible that AODV, or TinyAODV, > > or DSR, or GPSR or possibly one of several other alternatives is the right > > solution. However, there is little evidence of one having clear superiority > > at > > this time, despite numerous high profile efforts. We should be defining the > > canvas upon which competing alternatives can be defined and vetted. > > > > (3) has historically been addressed by a limited ability to > > communicate on the link to a crudely defined set of nodes in order to > > bootstrap the discovery, join, address assignment, negotiation, etc. > > Most successful links under IP look either like a broadcast medium or > > a point-to-point link (a degenerative broadcast). This allows ARP, > > RARP, BOOTP, DHCP, etc. to gain higher level accessibility and > > addressibility through the link. Links that require complex > > signaling, discovery, joining and coordnation below the link layer, > > including ATM, Bluetooth (piconets and scatter nets), and IRDA have > > proved onerous for IP and have been relegated to far less general > > usage scenarios - such as the desktop USB replacement. Even though > > the radio is a broadcast medium, the challenge in a routed link is > > that the link is not by default a link-wide broadcast phy. There > > are two natural notions of "broadcast" in a lowpan. (i) The physical > > neighbors that happen to receive a transmission because they are close > > enough to pick up the signal and have their radios turned on to > > receive. (ii) The entire collection of nodes that can be reached by a > > multihop dissemination (flood). Both of these are extremely useful in > > bootstrapping higher levels, including routing, and should be > > addressed in the format document. Additionally, it is not > > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over > > a 15.4 link. Providing some forms of broadcast using data frames > > makes the 802.15.4 format much more like 802.11 and other links that > > have proved very suitable for IP. Few, if any, of the public 15.4 routing > > layers developed > > by the TinyOS community utilize beacon packets. > > > > The recognition that the current Mesh Delivery field may be to restrictive > > is intimated by the need to define a second form of the header for > > multicast (and link local broadcast) that includes a sequence number. > > The mesh header field type is defined by whether the destination > > address is unicast or multicast. The document states that the use of > > such a sequence number is out of scope. However, the observation that > > that extra information may need to be included depending on how > > packets are routed further suggests that more careful format > > definition is needed to support future development of mesh routing. > > > > Have folks who have been developing mesh layers for lowpan6 felt that > > the existing Mesh Delivery Field is too restrictive? > > > > > > David E. Culler > > UC Berkeley > > culler@cs.berkeley.edu > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-705944577-1158940938=:13686 Content-Type: text/html; charset=us-ascii
First of all, Thanks David for your thoughtful message. It's great to see you participate in this forum and I hope
you'll stick around!
 
From the point of view of laying the technology foundation, everything in your message is quite relevant.
From the point of view of WG management, I'm trying to figure out if we need to act on all of it right now
or if there are things we can address independently of the format draft under discussion. For example,
you bring up the topic of traceroute type functionality. In IP, this is carried over ICMP, a separate
management control plane. Since what we have in the format draft is a multiplexing layer, we can
define a new protocol value to carry out the management protocol packets. The question is if the
current format provides the required mechanism to go do work on such a separate protocol
in another draft. Intuitively, it seems like this would work. Someone (your group, David?) could
define such a protocol with functionality similar to ICMP for pings, traceroute, etc and provide
the route gathering functionality, the echo response, etc in that separate draft. Conceivably, it
would not necessarily use the mesh delivery header, as it would provide its own facility to
record hop-by-hop route information within its own protocol fields. It could use loose source
routing in which case some use of the mesh delivery header might be appropriate as well.
Would such an approach work, David? This would actually play into one of the items slated for
the next round of 6lowpan (if we ever recharter) to strengthen diagnosability or management of
these networks.
 
As for your point about us not knowing exactly what the header format must look like at this point in
time, this is perhaps something we need to take into consideration right now. For example, this
input would push us into reserving at least a couple of bits in the header for future expansion. A while
back Vipul was arguing for a "version" field. Not sure if such a field is required or if the current reserved
fields are enough. Mario Mao's proposal uses one of those reserved bits to solve the issue under
discussion regarding the mesh delivery header variants for unicast vs mcast/bcast. There has been
one group expressing support for this, so perhaps we already have the necessary mechanism in place
in the header.
 
David, you also mention the need to support different routing protocols side-by-side for comparison.
This is one of the design goals of the format document. As I mentioned, the protocol field allows one
to carry different protocols. We currently have proposals for a 6lowpan adaptations of AODV, a DyMO
and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps BVR is next. The point is that
the format document does provide the mechanism to define any such protocol, or is there a limitation you
can see in the current document? If so, what needs to change?
 
As for the claim that sub-IP benefits from simpler structures, my interpretation is that you're suggesting it
is better not to use the mesh delivery header and let IP deal with the underlying individual collection of links.
If so, one can ignore the mesh delivery header (not use it) and use the other parts of the format document to
simply layer IP on top. This approach would then make use of other activities like AUTOCONF or MANET
to create meshes if so desired.  Personally, I see that *if* one wishes to do a mesh, not doing it in the sub-IP
layer just pushes to problem upwards into the IP routing realm, and this just makes things even more complex
than doing it under sub-IP. Complexity will be there no matter what, it's just a question of where one wants to
address it. I do note that sub-IP complex structures are very popular and deployed in some cases (802.1d bridged
networks). Perhaps likely to become even more so with 802.11s within a few years.
 
I would not be interested in pursuing an AUTOCONF path, but think it should
be possible to do so for those so inclined. Does this sound doable? Again, my immediate concern is that the
format document not prevent this approach.
 
-gabriel

----- Original Message ----
From: Geoff Mulligan <geoff@mulligan.com>
To: Soohong Daniel Park <soohongp@gmail.com>
Cc: 6lowpan@ietf.org; David Culler <david.culler@gmail.com>
Sent: Friday, September 22, 2006 6:41:21 AM
Subject: Re: [6lowpan] Mesh Delivery Field

Daniel,
  While the WG last call did expire, I'm not sure if David is too late.
I think that he raises some important concerns and I'm not sure that we
really have consensus on the mesh delivery field.

I would like to hear from the list on this.  I think that Gabriel has
put forth 4 alternatives.  Carsten indicated that he thought he might
have a different alternative and would post to the list either the
alternative or his consideration of the 4 alternatives - Carsten, please
send your thoughts.

I feel that the issue David raises should be dealt with by the WG
because I do not want to send the draft on to the IESG only to have
these issues brought up in the IETF last call.  These seem rather
fundamental to me and we might look rather foolish not having resolved
this in the working group!

We need some significant discussion from the members of the WG.  This WG
has been, my self included, rather quiet and as a result we have moved
at a snails pace getting anything done.  I implore everyone to take time
and read the thread on the mesh field and send your thoughts, pro, con
or otherwise to this list.  If everyone continues to be apathetic about
this work, I hold little hope for this WG being rechartered to do any
other work!

    geoff

On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote:
> David,
>
> First off, your issue raising in this thread seems too late since our
> official WGLC was expired: "This Last Call will end on Wednesday 02
> August 2006 at 2359 UTC."
>
> Anyway, my sense is not to take Mesh issue at this stage. As long as
> we are looking at the 6lowpan solution format, mesh is out of scope of
> that. In fact, as far as I am concern, mesh belongs to 15.4 technology
> based on MAC layer. Instead, as described in the rechartering, we will
> go through adhoc issue based on IP layer. That's why we are here in
> 6lowpan wg of ietf.
>
> But, some staffs described in your mail seem helpful from the 6lowpan
> perspective, especially IPv6 related stuffs. If allowed, please bring
> your concern to the next 6lowpan face-to-face meeting in San Diego.
> Then, we will have further details in there I believe...
>
> --
>
>
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.
>
>
>
> On 9/21/06, David Culler <david.culler@gmail.com> wrote:
> > Dear All,
> >
> > I would like to raise a concern about the Mesh Delivery Field
> > definition in Section 11 of the format document.  While the actual
> > mesh routing protocol is appropriately outside the scope of the
> > 6lowpan Format document, that format needs provide the raw structure
> > upon which rough consensus and running code can be flourish.  We
> > know that low power wireless mesh routing is technically tricky and
> > strongly influenced by target traffic load, power management profile,
> > network design, and so on.  Thus, it is reasonable to expect that the
> > consensus building and technical refinement process will require
> > on-going experience with protocol and implementation alternatives.
> > The 6lowpan format document should support this process, although it
> > should not dictate its conclusion.
> >
> > Based on past experience with IP layer 3 routing and with past
> > internally routed links, we can establish a few primary goals for the
> > expressiveness of the 6lowpan Mesh Delivery Field.
> >    (1) It should support the visibility into the routed 15.4 cloud
> > necessary to develop, debug, diagnose, and manage the 15.4 cloud.
> >    (2) It should support the ability to define, develop and compare
> > routing protocols and possibly support the presence of multiple
> > protocols for widely differing usage cases.
> >    (3) It needs to be possible for nodes to communicate with other nodes
> > in the cloud in order to discover and negotiate joining the cloud
> > without joining the cloud a priori through some mechanism that is
> > opaque to IP and above.
> >
> > (1) has historically been addressed through various forms of source
> > routing.  It should be possible to do the equivalent of traceroute
> > through the 15.4 mesh and this should be accessible in some form through IP
> > so
> > higher layers can be built to perform the management.  The current
> > Mesh Delivery Field definition seems to prohibit any form of source routing.
> > It assumes that the routing tables are all set up and correct so that
> > the forwarder can "swizzle" the destination address field of the 15.4
> > header with a table entry.  (The experience of IP over ATM and the
> > thousands of pages of the Q83b signalling protocol required to set up
> > all the tables in advance ought to give us a little pause here.)  The
> > idea of supporting table-driven routing and thereby separating the
> > route formation from the forwarding engine is a good one, but there
> > needs to be enough expressive power to support the protocols that will
> > establish and manage those tables (rather than relying on an opaque
> > out-of-band signaling mechanism) and there needs to be the ability to
> > query and validate those tables without relying on out-of-band
> > mechanisms.
> >
> > (2) has historically be addressed with protocol identifiers and
> > options.  As we went through the various RIP, OSPF, etc. we didn't
> > need to go back and redefine the format documents.  There was enough
> > expressiveness for topology formation and routing to evolve.  Not all
> > networks need to support all protocols.  That has been the network
> > designers' determination.  The underlying structure provided the
> > primitives, allowing solutions (and consensus) to evolve.  We want to
> > avoid creating a "winner take all" structure where there is no room
> > for evolution and development.  It is possible that AODV, or TinyAODV,
> > or DSR, or GPSR or possibly one of several other alternatives is the right
> > solution.  However, there is little evidence of one having clear superiority
> > at
> > this time, despite numerous high profile efforts.  We should be defining the
> > canvas upon which competing alternatives can be defined and vetted.
> >
> > (3) has historically been addressed by a limited ability to
> > communicate on the link to a crudely defined set of nodes in order to
> > bootstrap the discovery, join, address assignment, negotiation, etc.
> > Most successful links under IP look either like a broadcast medium or
> > a point-to-point link (a degenerative broadcast).  This allows ARP,
> > RARP, BOOTP, DHCP, etc. to gain higher level accessibility and
> > addressibility through the link.  Links that require complex
> > signaling, discovery, joining and coordnation below the link layer,
> > including ATM, Bluetooth (piconets and scatter nets), and IRDA have
> > proved onerous for IP and have been relegated to far less general
> > usage scenarios - such as the desktop USB replacement.  Even though
> > the radio is a broadcast medium, the challenge in a routed link is
> > that the link is not by default a link-wide broadcast phy.  There
> > are two natural notions of "broadcast" in a lowpan.  (i) The physical
> > neighbors that happen to receive a transmission because they are close
> > enough to pick up the signal and have their radios turned on to
> > receive.  (ii) The entire collection of nodes that can be reached by a
> > multihop dissemination (flood).  Both of these are extremely useful in
> > bootstrapping higher levels, including routing, and should be
> > addressed in the format document.  Additionally, it is not
> > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over
> > a 15.4 link.  Providing some forms of broadcast using data frames
> > makes the 802.15.4 format much more like 802.11 and other links that
> > have proved very suitable for IP.  Few, if any, of the public 15.4 routing
> > layers developed
> > by the TinyOS community utilize beacon packets.
> >
> > The recognition that the current Mesh Delivery field may be to restrictive
> > is intimated by the need to define a second form of the header for
> > multicast (and link local broadcast) that includes a sequence number.
> > The mesh header field type is defined by whether the destination
> > address is unicast or multicast. The document states that the use of
> > such a sequence number is out of scope. However, the observation that
> > that extra information may need to be included depending on how
> > packets are routed further suggests that more careful format
> > definition is needed to support future development of mesh routing.
> >
> > Have folks who have been developing mesh layers for lowpan6 felt that
> > the existing Mesh Delivery Field is too restrictive?
> >
> >
> > David E. Culler
> > UC Berkeley
> > culler@cs.berkeley.edu
> >
> >
> >
> >
> > _______________________________________________
> > 6lowpan mailing list
> > 6lowpan@ietf.org
> > https://www1.ietf.org/mailman/listinfo/6lowpan
> >
> >
> >
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan


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

--0-705944577-1158940938=:13686-- --===============0184306867== 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 --===============0184306867==-- From 6lowpan-bounces@ietf.org Tue Sep 26 19:58:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSMok-0003jl-Ij; Tue, 26 Sep 2006 19:58:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSMoj-0003jZ-F6 for 6lowpan@ietf.org; Tue, 26 Sep 2006 19:58:25 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSMoh-000852-VO for 6lowpan@ietf.org; Tue, 26 Sep 2006 19:58:25 -0400 Received: by ug-out-1314.google.com with SMTP id 72so575ugd for <6lowpan@ietf.org>; Tue, 26 Sep 2006 16:58:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=d9ksTOIfdl0Pz6cYj4WRTJAw8G0QXmhQ8JO4oWdAC7apHkLLo+LvGT90yE8Dxt0HcX0if2mKLxmQyknU10kF7Jy9Nlg/VwMKZ1OG0lgSBTsKDD8EUV5JW1GQh+AMyLjCMoPo1Wn0TtL49IyHXJ5aSWVUsAVSN+I/JCqxEbBixsQ= Received: by 10.67.101.8 with SMTP id d8mr79329ugm; Tue, 26 Sep 2006 16:58:20 -0700 (PDT) Received: by 10.67.86.2 with HTTP; Tue, 26 Sep 2006 16:58:20 -0700 (PDT) Message-ID: Date: Wed, 27 Sep 2006 08:58:20 +0900 From: "Ki-Hyung Kim" To: "gabriel montenegro" Subject: Re: [6lowpan] Mesh Delivery Field In-Reply-To: <20060922160218.15337.qmail@web81909.mail.mud.yahoo.com> MIME-Version: 1.0 References: <1158932481.5028.7.camel@localhost> <20060922160218.15337.qmail@web81909.mail.mud.yahoo.com> X-Spam-Score: 3.1 (+++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: David Culler , 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="===============1158652717==" Errors-To: 6lowpan-bounces@ietf.org --===============1158652717== Content-Type: multipart/alternative; boundary="----=_Part_25254_23701974.1159315100783" ------=_Part_25254_23701974.1159315100783 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Gabriel, I am sorry for this late reply. Basically, I agree that current format document is rather tightly scheduled and not well prepared for future enhancements or revisions, in terms of routing, diagnoses, management, etc. Based on the assumption that we are not yet in the stage of pursuing future rechartering items, it might not be the right time to consider all the cases at one time. Also, we should be in rush to finish the current format document ASAP for moving forward into next stage before next IETF meeting. Regarding the mesh delivery field, Mario Mao's approach should be fine, and other approaches (like option 2,3, and 4) might be OK. However, it seems like we are trying too much to make the format compact while not considering the future expansions. After all, my opinion is option 1. Let's have one byte for the multicast bit and the reserved fields for future. having additional one byte for this is not a big deal in terms of packet size and won't add much complexity for handling it. Examples of utilizing some reserved fields might be follows: 1. Based on the assumption that 6lowpan supports multiple routing protocols such as LOAD, DYMO-low, HiLow, DSR, or whatever, etc., the field might be used for indicating which specific routing protocol should be used for routing this particular packet. It might be argued whether the format document should support multiple protocols at a time. However, those kind of argue should be debated later while considering routing protocols without eliminating future possible necessity. 2. Routing protocols could be optimzed by having some option fields, while it might not be right time to specifically mention them. I remember that the issue of the mesh underneath or above IP has been raised several times in the WG. I think it might not be right time considering it again right now. If you have any other opinions, please let me know -- Ki-Hyung Kim Associate Professor Division of Information and Computer Eng., Ajou University, Suwon, Korea 442-749 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 http://www.6lowpan.org ------=_Part_25254_23701974.1159315100783 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Gabriel,
 
I am sorry for this late reply.
Basically, I agree that current format document is rather tightly scheduled and not well prepared for future enhancements or revisions, in terms of routing, diagnoses, management, etc. Based on the assumption that we are not yet in the stage of pursuing future rechartering items, it might not be the right time to consider all the cases at one time. Also, we should be in rush to finish the current format document ASAP for moving forward into next stage before next IETF meeting.
 
Regarding the mesh delivery field, Mario Mao's approach should be fine, and other approaches (like option 2,3, and 4) might be OK. However, it seems like we are trying too much to make the format compact while not considering the future expansions.
 
After all, my opinion is option 1. Let's have one byte for the multicast bit and the reserved fields for future.
having additional one byte for this is not a big deal in terms of packet size and won't add much complexity for handling it.
Examples of utilizing some reserved fields might be follows:
1. Based on the assumption that 6lowpan supports multiple routing protocols such as  LOAD, DYMO-low, HiLow, DSR, or whatever, etc., the field might be used for indicating which specific routing protocol should be used for routing this particular packet. It might be argued whether the format document should support multiple protocols at a time. However, those kind of argue should be debated later while considering routing protocols without eliminating future possible necessity.
2. Routing protocols could be optimzed by having some option fields, while it might not be right time to specifically mention them.
 
I remember that the issue of the mesh underneath or above IP has been raised several times in the WG. I think it might not be right time considering it again right now.
 
If you have any other opinions, please let me know



--
Ki-Hyung Kim 
Associate Professor
Division of Information and Computer Eng., Ajou University, Suwon, Korea 442-749
Tel: +82-31-219-2433, Cel: +82-17-760-2551,  Fax: +82-31-219-2433 http://www.6lowpan.org ------=_Part_25254_23701974.1159315100783-- --===============1158652717== 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 --===============1158652717==-- From 6lowpan-bounces@ietf.org Fri Sep 29 14:14:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMsQ-0005tJ-A3; Fri, 29 Sep 2006 14:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTKS6-0001oj-Ar for 6lowpan@ietf.org; Fri, 29 Sep 2006 11:39:02 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTKS1-0007JM-MT for 6lowpan@ietf.org; Fri, 29 Sep 2006 11:39:02 -0400 Received: by ug-out-1314.google.com with SMTP id 72so256272ugd for <6lowpan@ietf.org>; Fri, 29 Sep 2006 08:38:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=rz3ybK1oa2lEZp7VFY7R1YkOXK+/BkcudZUnjxasbWWr2HDS3Sc0WfMTeJwVz2WV9l2k6/DjO33H6T1s6tC0GgT73vrpeHRo6lnyOucagGyUgmH7SYYWQeRFB+c2eIV/nIFOJvp3OxcOAumwpU2XjenlZfZCnh38m/YaU5yxC7Y= Received: by 10.67.93.7 with SMTP id v7mr148913ugl; Fri, 29 Sep 2006 08:38:56 -0700 (PDT) Received: by 10.67.91.9 with HTTP; Fri, 29 Sep 2006 08:38:55 -0700 (PDT) Message-ID: Date: Fri, 29 Sep 2006 08:38:56 -0700 From: "David Culler" To: "Ki-Hyung Kim" Subject: Re: [6lowpan] Mesh Delivery Field In-Reply-To: MIME-Version: 1.0 References: <1158932481.5028.7.camel@localhost> <20060922160218.15337.qmail@web81909.mail.mud.yahoo.com> X-Spam-Score: 2.3 (++) X-Scan-Signature: cb256aa41b5300a7da304d7294799ef5 X-Mailman-Approved-At: Fri, 29 Sep 2006 14:14:14 -0400 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="===============0676030912==" Errors-To: 6lowpan-bounces@ietf.org --===============0676030912== Content-Type: multipart/alternative; boundary="----=_Part_12049_2288102.1159544336033" ------=_Part_12049_2288102.1159544336033 Content-Type: text/plain; charset=EUC-KR; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SXQgY2VydGFpbmx5IHdvdWxkIGJlIGEgc2hhbWUgdG8gZ2V0IGludG8gYSBwb3NpdGlvbiB3aGVy ZSB0aGUgZW5jb2RpbmcgaXMKc28gc28gY29uc3RyYWluZWQgdGhhdCB0aGVyZSB3YXMgbm90IGEg bWVhbnMgb2YgYWNjb21vZGF0aW5nIGFkZGl0aW9uYWwKY2FwYWJpbGl0aWVzIHRoYXQgYXJlIHJl dmVhbGVkIHRocm91Z2ggZGVlcGVyIGltcGxlbWVudGF0aW9uIGFuZCB1c2FnZQpleHBlcmllbmNl LiAgVGhlIElQIGNvbW11bml0eSBoYXMgaGlzdG9yaWNhbGx5IGJlZW4gdmVyeSBnb29kIGF0IHBs YW5uaW5nCmZvciBjaGFuZ2UuICBPcHRpb25zIGZpZWxkcyBhbmQgbGVhdmluZyBhIGxpdHRsZSBy b29tIGluIHRoZSBpbml0aWFsCmVuY29kaW5ncyBhcmUgZXNzZW50aWFsIHRvIHRoYXQuICBBcyBt dWNoIGFzIHdlIHRyeSwgd2Ugc2VsZG9tIGdldCBldmVyeQphc3BlY3Qgb2YgdGhlIHByb3RvY29s IGV4YWN0bHkgcmlnaHQgdGhlIGZpcnN0IHRpbWUuICBJdCBpcyB1bmRlcnN0YW5kYWJsZQp0aGF0 IHdpdGggc28gbXVjaCBmb2N1cyBiZWluZyBwbGFjZSBvbiBoZWFkZXIgY29tcHJlc3Npb24gdGhh dCBpdCBpcyBoYXJkIHRvCmxlYXZlIGFueSBzcGFjZSB1bmNsYWltZWQuICBIb3dldmVyLCB0aGF0 IGNvbnRpbmdlbmN5IHBsYW5uaW5nIGFuZApmbGV4aWJpbGl0eSBtYXkgYmUgbW9yZSBjcml0aWNh bCB0byBldmVudHVhbCBhZG9wdGlvbiB0aGFuIHNxdWVlemluZyBvdXQKZXZlcnkgdW5uZWNjZXNz YXJ5IGJpdC4gICBBcyB3ZSBsb29rIGF0IHRoZSBkZXNpcmVkICJydXNoIHRvIGZpbmlzaCIgaXQg aXMKaW1wb3J0YW50IHRvIHZlcmlmeSB0aGF0IHRoZSBwcm9wb3NlZCBmcmFtZXdvcmsgcGVybWl0 cyBlbm91Z2ggZXhwcmVzc2l2ZQpwb3dlciB0byBhZGRyZXNzIHRoZSBpc3N1ZXMgdGhhdCBoYXZl IG5vdCB5ZXQgYmVlbiBmdWxseSB2ZXR0ZWQuICBZb3UgY2Fubm90CmV4cGFuZCB0aGUgZm9ybWF0 LCBvbmx5IHdvcmsgd2l0aGluIGl0LgoKT24gOS8yNi8wNiwgS2ktSHl1bmcgS2ltIDxra2ltODZA Z21haWwuY29tPiB3cm90ZToKPgo+IEdhYnJpZWwsCj4KPiBJIGFtIHNvcnJ5IGZvciB0aGlzIGxh dGUgcmVwbHkuCj4gQmFzaWNhbGx5LCBJIGFncmVlIHRoYXQgY3VycmVudCBmb3JtYXQgZG9jdW1l bnQgaXMgcmF0aGVyCj4gdGlnaHRseSBzY2hlZHVsZWQgYW5kIG5vdCB3ZWxsIHByZXBhcmVkIGZv ciBmdXR1cmUgZW5oYW5jZW1lbnRzIG9yCj4gcmV2aXNpb25zLCBpbiB0ZXJtcyBvZiByb3V0aW5n LCBkaWFnbm9zZXMsIG1hbmFnZW1lbnQsIGV0Yy4gQmFzZWQgb24gdGhlCj4gYXNzdW1wdGlvbiB0 aGF0IHdlIGFyZSBub3QgeWV0IGluIHRoZSBzdGFnZSBvZiBwdXJzdWluZyBmdXR1cmUgcmVjaGFy dGVyaW5nCj4gaXRlbXMsIGl0IG1pZ2h0IG5vdCBiZSB0aGUgcmlnaHQgdGltZSB0byBjb25zaWRl ciBhbGwgdGhlIGNhc2VzIGF0IG9uZSB0aW1lLgo+IEFsc28sIHdlIHNob3VsZCBiZSBpbiBydXNo IHRvIGZpbmlzaCB0aGUgY3VycmVudCBmb3JtYXQgZG9jdW1lbnQgQVNBUCBmb3IKPiBtb3Zpbmcg Zm9yd2FyZCBpbnRvIG5leHQgc3RhZ2UgYmVmb3JlIG5leHQgSUVURiBtZWV0aW5nLgo+Cj4gUmVn YXJkaW5nIHRoZSBtZXNoIGRlbGl2ZXJ5IGZpZWxkLCBNYXJpbyBNYW8ncyBhcHByb2FjaCBzaG91 bGQgYmUgZmluZSwKPiBhbmQgb3RoZXIgYXBwcm9hY2hlcyAobGlrZSBvcHRpb24gMiwzLCBhbmQg NCkgbWlnaHQgYmUgT0suIEhvd2V2ZXIsIGl0IHNlZW1zCj4gbGlrZSB3ZSBhcmUgdHJ5aW5nIHRv byBtdWNoIHRvIG1ha2UgdGhlIGZvcm1hdCBjb21wYWN0IHdoaWxlIG5vdCBjb25zaWRlcmluZwo+ IHRoZSBmdXR1cmUgZXhwYW5zaW9ucy4KPgo+IEFmdGVyIGFsbCwgbXkgb3BpbmlvbiBpcyBvcHRp b24gMS4gTGV0J3MgaGF2ZSBvbmUgYnl0ZSBmb3IgdGhlIG11bHRpY2FzdAo+IGJpdCBhbmQgdGhl IHJlc2VydmVkIGZpZWxkcyBmb3IgZnV0dXJlLgo+IGhhdmluZyBhZGRpdGlvbmFsIG9uZSBieXRl IGZvciB0aGlzIGlzIG5vdCBhIGJpZyBkZWFsIGluIHRlcm1zIG9mIHBhY2tldAo+IHNpemUgYW5k IHdvbid0IGFkZCBtdWNoIGNvbXBsZXhpdHkgZm9yIGhhbmRsaW5nIGl0Lgo+IEV4YW1wbGVzIG9m IHV0aWxpemluZyBzb21lIHJlc2VydmVkIGZpZWxkcyBtaWdodCBiZSBmb2xsb3dzOgo+IDEuIEJh c2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgNmxvd3BhbiBzdXBwb3J0cyBtdWx0aXBsZSByb3V0 aW5nCj4gcHJvdG9jb2xzIHN1Y2ggYXMgIExPQUQsIERZTU8tbG93LCBIaUxvdywgRFNSLCBvciB3 aGF0ZXZlciwgZXRjLiwgdGhlIGZpZWxkCj4gbWlnaHQgYmUgdXNlZCBmb3IgaW5kaWNhdGluZyB3 aGljaCBzcGVjaWZpYyByb3V0aW5nIHByb3RvY29sIHNob3VsZCBiZSB1c2VkCj4gZm9yIHJvdXRp bmcgdGhpcyBwYXJ0aWN1bGFyIHBhY2tldC4gSXQgbWlnaHQgYmUgYXJndWVkIHdoZXRoZXIgdGhl IGZvcm1hdAo+IGRvY3VtZW50IHNob3VsZCBzdXBwb3J0IG11bHRpcGxlIHByb3RvY29scyBhdCBh IHRpbWUuIEhvd2V2ZXIsIHRob3NlIGtpbmQgb2YKPiBhcmd1ZSBzaG91bGQgYmUgZGViYXRlZCBs YXRlciB3aGlsZSBjb25zaWRlcmluZyByb3V0aW5nIHByb3RvY29scyB3aXRob3V0Cj4gZWxpbWlu YXRpbmcgZnV0dXJlIHBvc3NpYmxlIG5lY2Vzc2l0eS4KPiAyLiBSb3V0aW5nIHByb3RvY29scyBj b3VsZCBiZSBvcHRpbXplZCBieSBoYXZpbmcgc29tZSBvcHRpb24gZmllbGRzLCB3aGlsZQo+IGl0 IG1pZ2h0IG5vdCBiZSByaWdodCB0aW1lIHRvIHNwZWNpZmljYWxseSBtZW50aW9uIHRoZW0uCj4K PiBJIHJlbWVtYmVyIHRoYXQgdGhlIGlzc3VlIG9mIHRoZSBtZXNoIHVuZGVybmVhdGggb3IgYWJv dmUgSVAgaGFzIGJlZW4KPiByYWlzZWQgc2V2ZXJhbCB0aW1lcyBpbiB0aGUgV0cuIEkgdGhpbmsg aXQgbWlnaHQgbm90IGJlIHJpZ2h0IHRpbWUKPiBjb25zaWRlcmluZyBpdCBhZ2FpbiByaWdodCBu b3cuCj4KPiBJZiB5b3UgaGF2ZSBhbnkgb3RoZXIgb3BpbmlvbnMsIHBsZWFzZSBsZXQgbWUga25v dy4KPgo+Cj4gT24gOS8yMy8wNiwgZ2FicmllbCBtb250ZW5lZ3JvIDxnYWJyaWVsX21vbnRlbmVn cm9fMjAwMEB5YWhvby5jb20+IHdyb3RlOgo+ID4KPiA+ICBGaXJzdCBvZiBhbGwsIFRoYW5rcyBE YXZpZCBmb3IgeW91ciB0aG91Z2h0ZnVsIG1lc3NhZ2UuIEl0J3MgZ3JlYXQgdG8KPiA+IHNlZSB5 b3UgcGFydGljaXBhdGUgaW4gdGhpcyBmb3J1bSBhbmQgSSBob3BlCj4gPiB5b3UnbGwgc3RpY2sg YXJvdW5kIQo+ID4KPiA+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgbGF5aW5nIHRoZSB0ZWNo bm9sb2d5IGZvdW5kYXRpb24sIGV2ZXJ5dGhpbmcKPiA+IGluIHlvdXIgbWVzc2FnZSBpcyBxdWl0 ZSByZWxldmFudC4KPiA+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgV0cgbWFuYWdlbWVudCwg SSdtIHRyeWluZyB0byBmaWd1cmUgb3V0IGlmIHdlCj4gPiBuZWVkIHRvIGFjdCBvbiBhbGwgb2Yg aXQgcmlnaHQgbm93Cj4gPiBvciBpZiB0aGVyZSBhcmUgdGhpbmdzIHdlIGNhbiBhZGRyZXNzIGlu ZGVwZW5kZW50bHkgb2YgdGhlIGZvcm1hdCBkcmFmdAo+ID4gdW5kZXIgZGlzY3Vzc2lvbi4gRm9y IGV4YW1wbGUsCj4gPiB5b3UgYnJpbmcgdXAgdGhlIHRvcGljIG9mIHRyYWNlcm91dGUgdHlwZSBm dW5jdGlvbmFsaXR5LiBJbiBJUCwgdGhpcyBpcwo+ID4gY2FycmllZCBvdmVyIElDTVAsIGEgc2Vw YXJhdGUKPiA+IG1hbmFnZW1lbnQgY29udHJvbCBwbGFuZS4gU2luY2Ugd2hhdCB3ZSBoYXZlIGlu IHRoZSBmb3JtYXQgZHJhZnQgaXMgYQo+ID4gbXVsdGlwbGV4aW5nIGxheWVyLCB3ZSBjYW4KPiA+ IGRlZmluZSBhIG5ldyBwcm90b2NvbCB2YWx1ZSB0byBjYXJyeSBvdXQgdGhlIG1hbmFnZW1lbnQg cHJvdG9jb2wKPiA+IHBhY2tldHMuIFRoZSBxdWVzdGlvbiBpcyBpZiB0aGUKPiA+IGN1cnJlbnQg Zm9ybWF0IHByb3ZpZGVzIHRoZSByZXF1aXJlZCBtZWNoYW5pc20gdG8gZ28gZG8gd29yayBvbiBz dWNoIGEKPiA+IHNlcGFyYXRlIHByb3RvY29sCj4gPiBpbiBhbm90aGVyIGRyYWZ0LiBJbnR1aXRp dmVseSwgaXQgc2VlbXMgbGlrZSB0aGlzIHdvdWxkIHdvcmsuIFNvbWVvbmUKPiA+ICh5b3VyIGdy b3VwLCBEYXZpZD8pIGNvdWxkCj4gPiBkZWZpbmUgc3VjaCBhIHByb3RvY29sIHdpdGggZnVuY3Rp b25hbGl0eSBzaW1pbGFyIHRvIElDTVAgZm9yIHBpbmdzLAo+ID4gdHJhY2Vyb3V0ZSwgZXRjIGFu ZCBwcm92aWRlCj4gPiB0aGUgcm91dGUgZ2F0aGVyaW5nIGZ1bmN0aW9uYWxpdHksIHRoZSBlY2hv IHJlc3BvbnNlLCBldGMgaW4gdGhhdAo+ID4gc2VwYXJhdGUgZHJhZnQuIENvbmNlaXZhYmx5LCBp dAo+ID4gd291bGQgbm90IG5lY2Vzc2FyaWx5IHVzZSB0aGUgbWVzaCBkZWxpdmVyeSBoZWFkZXIs IGFzIGl0IHdvdWxkIHByb3ZpZGUKPiA+IGl0cyBvd24gZmFjaWxpdHkgdG8KPiA+IHJlY29yZCBo b3AtYnktaG9wIHJvdXRlIGluZm9ybWF0aW9uIHdpdGhpbiBpdHMgb3duIHByb3RvY29sIGZpZWxk cy4gSXQKPiA+IGNvdWxkIHVzZSBsb29zZSBzb3VyY2UKPiA+IHJvdXRpbmcgaW4gd2hpY2ggY2Fz ZSBzb21lIHVzZSBvZiB0aGUgbWVzaCBkZWxpdmVyeSBoZWFkZXIgbWlnaHQgYmUKPiA+IGFwcHJv cHJpYXRlIGFzIHdlbGwuCj4gPiBXb3VsZCBzdWNoIGFuIGFwcHJvYWNoIHdvcmssIERhdmlkPyBU aGlzIHdvdWxkIGFjdHVhbGx5IHBsYXkgaW50byBvbmUgb2YKPiA+IHRoZSBpdGVtcyBzbGF0ZWQg Zm9yCj4gPiB0aGUgbmV4dCByb3VuZCBvZiA2bG93cGFuIChpZiB3ZSBldmVyIHJlY2hhcnRlcikg dG8gc3RyZW5ndGhlbgo+ID4gZGlhZ25vc2FiaWxpdHkgb3IgbWFuYWdlbWVudCBvZgo+ID4gdGhl c2UgbmV0d29ya3MuCj4gPgo+ID4gQXMgZm9yIHlvdXIgcG9pbnQgYWJvdXQgdXMgbm90IGtub3dp bmcgZXhhY3RseSB3aGF0IHRoZSBoZWFkZXIgZm9ybWF0Cj4gPiBtdXN0IGxvb2sgbGlrZSBhdCB0 aGlzIHBvaW50IGluCj4gPiB0aW1lLCB0aGlzIGlzIHBlcmhhcHMgc29tZXRoaW5nIHdlIG5lZWQg dG8gdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24gcmlnaHQKPiA+IG5vdy4gRm9yIGV4YW1wbGUsIHRo aXMKPiA+IGlucHV0IHdvdWxkIHB1c2ggdXMgaW50byByZXNlcnZpbmcgYXQgbGVhc3QgYSBjb3Vw bGUgb2YgYml0cyBpbiB0aGUKPiA+IGhlYWRlciBmb3IgZnV0dXJlIGV4cGFuc2lvbi4gQSB3aGls ZQo+ID4gYmFjayBWaXB1bCB3YXMgYXJndWluZyBmb3IgYSAidmVyc2lvbiIgZmllbGQuIE5vdCBz dXJlIGlmIHN1Y2ggYSBmaWVsZAo+ID4gaXMgcmVxdWlyZWQgb3IgaWYgdGhlIGN1cnJlbnQgcmVz ZXJ2ZWQKPiA+IGZpZWxkcyBhcmUgZW5vdWdoLiBNYXJpbyBNYW8ncyBwcm9wb3NhbCB1c2VzIG9u ZSBvZiB0aG9zZSByZXNlcnZlZCBiaXRzCj4gPiB0byBzb2x2ZSB0aGUgaXNzdWUgdW5kZXIKPiA+ IGRpc2N1c3Npb24gcmVnYXJkaW5nIHRoZSBtZXNoIGRlbGl2ZXJ5IGhlYWRlciB2YXJpYW50cyBm b3IgdW5pY2FzdCB2cwo+ID4gbWNhc3QvYmNhc3QuIFRoZXJlIGhhcyBiZWVuCj4gPiBvbmUgZ3Jv dXAgZXhwcmVzc2luZyBzdXBwb3J0IGZvciB0aGlzLCBzbyBwZXJoYXBzIHdlIGFscmVhZHkgaGF2 ZSB0aGUKPiA+IG5lY2Vzc2FyeSBtZWNoYW5pc20gaW4gcGxhY2UKPiA+IGluIHRoZSBoZWFkZXIu Cj4gPgo+ID4gRGF2aWQsIHlvdSBhbHNvIG1lbnRpb24gdGhlIG5lZWQgdG8gc3VwcG9ydCBkaWZm ZXJlbnQgcm91dGluZyBwcm90b2NvbHMKPiA+IHNpZGUtYnktc2lkZSBmb3IgY29tcGFyaXNvbi4K PiA+IFRoaXMgaXMgb25lIG9mIHRoZSBkZXNpZ24gZ29hbHMgb2YgdGhlIGZvcm1hdCBkb2N1bWVu dC4gQXMgSSBtZW50aW9uZWQsCj4gPiB0aGUgcHJvdG9jb2wgZmllbGQgYWxsb3dzIG9uZQo+ID4g dG8gY2FycnkgZGlmZmVyZW50IHByb3RvY29scy4gV2UgY3VycmVudGx5IGhhdmUgcHJvcG9zYWxz IGZvciBhIDZsb3dwYW4KPiA+IGFkYXB0YXRpb25zIG9mIEFPRFYsIGEgRHlNTwo+ID4gYW5kIEhp TG93LiBJIGtub3cgTmFuZHUgd2FzIHRoaW5raW5nIG9mIGRvaW5nIG9uZSBmb3IgT0xTUi4gUGVy aGFwcyBCVlIKPiA+IGlzIG5leHQuIFRoZSBwb2ludCBpcyB0aGF0Cj4gPiB0aGUgZm9ybWF0IGRv Y3VtZW50IGRvZXMgcHJvdmlkZSB0aGUgbWVjaGFuaXNtIHRvIGRlZmluZSBhbnkgc3VjaAo+ID4g cHJvdG9jb2wsIG9yIGlzIHRoZXJlIGEgbGltaXRhdGlvbiB5b3UKPiA+IGNhbiBzZWUgaW4gdGhl IGN1cnJlbnQgZG9jdW1lbnQ/IElmIHNvLCB3aGF0IG5lZWRzIHRvIGNoYW5nZT8KPiA+Cj4gPiBB cyBmb3IgdGhlIGNsYWltIHRoYXQgc3ViLUlQIGJlbmVmaXRzIGZyb20gc2ltcGxlciBzdHJ1Y3R1 cmVzLCBteQo+ID4gaW50ZXJwcmV0YXRpb24gaXMgdGhhdCB5b3UncmUgc3VnZ2VzdGluZyBpdAo+ ID4gaXMgYmV0dGVyIG5vdCB0byB1c2UgdGhlIG1lc2ggZGVsaXZlcnkgaGVhZGVyIGFuZCBsZXQg SVAgZGVhbCB3aXRoIHRoZQo+ID4gdW5kZXJseWluZyBpbmRpdmlkdWFsIGNvbGxlY3Rpb24gb2Yg bGlua3MuCj4gPiBJZiBzbywgb25lIGNhbiBpZ25vcmUgdGhlIG1lc2ggZGVsaXZlcnkgaGVhZGVy IChub3QgdXNlIGl0KSBhbmQgdXNlIHRoZQo+ID4gb3RoZXIgcGFydHMgb2YgdGhlIGZvcm1hdCBk b2N1bWVudCB0bwo+ID4gc2ltcGx5IGxheWVyIElQIG9uIHRvcC4gVGhpcyBhcHByb2FjaCB3b3Vs ZCB0aGVuIG1ha2UgdXNlIG9mIG90aGVyCj4gPiBhY3Rpdml0aWVzIGxpa2UgQVVUT0NPTkYgb3Ig TUFORVQKPiA+IHRvIGNyZWF0ZSBtZXNoZXMgaWYgc28gZGVzaXJlZC4gIFBlcnNvbmFsbHksIEkg c2VlIHRoYXQgKmlmKiBvbmUgd2lzaGVzCj4gPiB0byBkbyBhIG1lc2gsIG5vdCBkb2luZyBpdCBp biB0aGUgc3ViLUlQCj4gPiBsYXllciBqdXN0IHB1c2hlcyB0byBwcm9ibGVtIHVwd2FyZHMgaW50 byB0aGUgSVAgcm91dGluZyByZWFsbSwgYW5kIHRoaXMKPiA+IGp1c3QgbWFrZXMgdGhpbmdzIGV2 ZW4gbW9yZSBjb21wbGV4Cj4gPiB0aGFuIGRvaW5nIGl0IHVuZGVyIHN1Yi1JUC4gQ29tcGxleGl0 eSB3aWxsIGJlIHRoZXJlIG5vIG1hdHRlciB3aGF0LAo+ID4gaXQncyBqdXN0IGEgcXVlc3Rpb24g b2Ygd2hlcmUgb25lIHdhbnRzIHRvCj4gPiBhZGRyZXNzIGl0LiBJIGRvIG5vdGUgdGhhdCBzdWIt SVAgY29tcGxleCBzdHJ1Y3R1cmVzIGFyZSB2ZXJ5IHBvcHVsYXIKPiA+IGFuZCBkZXBsb3llZCBp biBzb21lIGNhc2VzICg4MDIuMWQgYnJpZGdlZAo+ID4gbmV0d29ya3MpLiBQZXJoYXBzIGxpa2Vs eSB0byBiZWNvbWUgZXZlbiBtb3JlIHNvIHdpdGggODAyLjExcyB3aXRoaW4gYQo+ID4gZmV3IHll YXJzLgo+ID4KPiA+IEkgd291bGQgbm90IGJlIGludGVyZXN0ZWQgaW4gcHVyc3VpbmcgYW4gQVVU T0NPTkYgcGF0aCwgYnV0IHRoaW5rIGl0Cj4gPiBzaG91bGQKPiA+IGJlIHBvc3NpYmxlIHRvIGRv IHNvIGZvciB0aG9zZSBzbyBpbmNsaW5lZC4gRG9lcyB0aGlzIHNvdW5kIGRvYWJsZT8KPiA+IEFn YWluLCBteSBpbW1lZGlhdGUgY29uY2VybiBpcyB0aGF0IHRoZQo+ID4gZm9ybWF0IGRvY3VtZW50 IG5vdCBwcmV2ZW50IHRoaXMgYXBwcm9hY2guCj4gPgo+ID4gLWdhYnJpZWwKPiA+Cj4gPgo+ID4g IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLQo+ID4gRnJvbTogR2VvZmYgTXVsbGlnYW4gPCBn ZW9mZkBtdWxsaWdhbi5jb20+Cj4gPiBUbzogU29vaG9uZyBEYW5pZWwgUGFyayA8c29vaG9uZ3BA Z21haWwuY29tPgo+ID4gQ2M6IDZsb3dwYW5AaWV0Zi5vcmc7IERhdmlkIEN1bGxlciA8ZGF2aWQu Y3VsbGVyQGdtYWlsLmNvbT4KPiA+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDIyLCAyMDA2IDY6 NDE6MjEgQU0KPiA+IFN1YmplY3Q6IFJlOiBbNmxvd3Bhbl0gTWVzaCBEZWxpdmVyeSBGaWVsZAo+ ID4KPiA+IERhbmllbCwKPiA+ICAgV2hpbGUgdGhlIFdHIGxhc3QgY2FsbCBkaWQgZXhwaXJlLCBJ J20gbm90IHN1cmUgaWYgRGF2aWQgaXMgdG9vIGxhdGUuCj4gPiBJIHRoaW5rIHRoYXQgaGUgcmFp c2VzIHNvbWUgaW1wb3J0YW50IGNvbmNlcm5zIGFuZCBJJ20gbm90IHN1cmUgdGhhdCB3ZQo+ID4g cmVhbGx5IGhhdmUgY29uc2Vuc3VzIG9uIHRoZSBtZXNoIGRlbGl2ZXJ5IGZpZWxkLgo+ID4KPiA+ IEkgd291bGQgbGlrZSB0byBoZWFyIGZyb20gdGhlIGxpc3Qgb24gdGhpcy4gIEkgdGhpbmsgdGhh dCBHYWJyaWVsIGhhcwo+ID4gcHV0IGZvcnRoIDQgYWx0ZXJuYXRpdmVzLiAgQ2Fyc3RlbiBpbmRp Y2F0ZWQgdGhhdCBoZSB0aG91Z2h0IGhlIG1pZ2h0Cj4gPiBoYXZlIGEgZGlmZmVyZW50IGFsdGVy bmF0aXZlIGFuZCB3b3VsZCBwb3N0IHRvIHRoZSBsaXN0IGVpdGhlciB0aGUKPiA+IGFsdGVybmF0 aXZlIG9yIGhpcyBjb25zaWRlcmF0aW9uIG9mIHRoZSA0IGFsdGVybmF0aXZlcyAtIENhcnN0ZW4s IHBsZWFzZQo+ID4KPiA+IHNlbmQgeW91ciB0aG91Z2h0cy4KPiA+Cj4gPiBJIGZlZWwgdGhhdCB0 aGUgaXNzdWUgRGF2aWQgcmFpc2VzIHNob3VsZCBiZSBkZWFsdCB3aXRoIGJ5IHRoZSBXRwo+ID4g YmVjYXVzZSBJIGRvIG5vdCB3YW50IHRvIHNlbmQgdGhlIGRyYWZ0IG9uIHRvIHRoZSBJRVNHIG9u bHkgdG8gaGF2ZQo+ID4gdGhlc2UgaXNzdWVzIGJyb3VnaHQgdXAgaW4gdGhlIElFVEYgbGFzdCBj YWxsLiAgVGhlc2Ugc2VlbSByYXRoZXIKPiA+IGZ1bmRhbWVudGFsIHRvIG1lIGFuZCB3ZSBtaWdo dCBsb29rIHJhdGhlciBmb29saXNoIG5vdCBoYXZpbmcgcmVzb2x2ZWQKPiA+IHRoaXMgaW4gdGhl IHdvcmtpbmcgZ3JvdXAhCj4gPgo+ID4gV2UgbmVlZCBzb21lIHNpZ25pZmljYW50IGRpc2N1c3Np b24gZnJvbSB0aGUgbWVtYmVycyBvZiB0aGUgV0cuICBUaGlzIFdHCj4gPiBoYXMgYmVlbiwgbXkg c2VsZiBpbmNsdWRlZCwgcmF0aGVyIHF1aWV0IGFuZCBhcyBhIHJlc3VsdCB3ZSBoYXZlIG1vdmVk Cj4gPiBhdCBhIHNuYWlscyBwYWNlIGdldHRpbmcgYW55dGhpbmcgZG9uZS4gIEkgaW1wbG9yZSBl dmVyeW9uZSB0byB0YWtlIHRpbWUKPiA+IGFuZCByZWFkIHRoZSB0aHJlYWQgb24gdGhlIG1lc2gg ZmllbGQgYW5kIHNlbmQgeW91ciB0aG91Z2h0cywgcHJvLCBjb24KPiA+IG9yIG90aGVyd2lzZSB0 byB0aGlzIGxpc3QuICBJZiBldmVyeW9uZSBjb250aW51ZXMgdG8gYmUgYXBhdGhldGljIGFib3V0 Cj4gPiB0aGlzIHdvcmssIEkgaG9sZCBsaXR0bGUgaG9wZSBmb3IgdGhpcyBXRyBiZWluZyByZWNo YXJ0ZXJlZCB0byBkbyBhbnkKPiA+IG90aGVyIHdvcmshCj4gPgo+ID4gICAgIGdlb2ZmCj4gPgo+ ID4gT24gRnJpLCAyMDA2LTA5LTIyIGF0IDE5OjIzICsxMDAwLCBTb29ob25nIERhbmllbCBQYXJr IHdyb3RlOgo+ID4gPiBEYXZpZCwKPiA+ID4KPiA+ID4gRmlyc3Qgb2ZmLCB5b3VyIGlzc3VlIHJh aXNpbmcgaW4gdGhpcyB0aHJlYWQgc2VlbXMgdG9vIGxhdGUgc2luY2Ugb3VyCj4gPiA+IG9mZmlj aWFsIFdHTEMgd2FzIGV4cGlyZWQ6ICJUaGlzIExhc3QgQ2FsbCB3aWxsIGVuZCBvbiBXZWRuZXNk YXkgMDIKPiA+ID4gQXVndXN0IDIwMDYgYXQgMjM1OSBVVEMuIgo+ID4gPgo+ID4gPiBBbnl3YXks IG15IHNlbnNlIGlzIG5vdCB0byB0YWtlIE1lc2ggaXNzdWUgYXQgdGhpcyBzdGFnZS4gQXMgbG9u ZyBhcwo+ID4gPiB3ZSBhcmUgbG9va2luZyBhdCB0aGUgNmxvd3BhbiBzb2x1dGlvbiBmb3JtYXQs IG1lc2ggaXMgb3V0IG9mIHNjb3BlIG9mCj4gPgo+ID4gPiB0aGF0LiBJbiBmYWN0LCBhcyBmYXIg YXMgSSBhbSBjb25jZXJuLCBtZXNoIGJlbG9uZ3MgdG8gMTUuNCB0ZWNobm9sb2d5Cj4gPiA+IGJh c2VkIG9uIE1BQyBsYXllci4gSW5zdGVhZCwgYXMgZGVzY3JpYmVkIGluIHRoZSByZWNoYXJ0ZXJp bmcsIHdlIHdpbGwKPiA+ID4gZ28gdGhyb3VnaCBhZGhvYyBpc3N1ZSBiYXNlZCBvbiBJUCBsYXll ci4gVGhhdCdzIHdoeSB3ZSBhcmUgaGVyZSBpbgo+ID4gPiA2bG93cGFuIHdnIG9mIGlldGYuCj4g PiA+Cj4gPiA+IEJ1dCwgc29tZSBzdGFmZnMgZGVzY3JpYmVkIGluIHlvdXIgbWFpbCBzZWVtIGhl bHBmdWwgZnJvbSB0aGUgNmxvd3Bhbgo+ID4gPiBwZXJzcGVjdGl2ZSwgZXNwZWNpYWxseSBJUHY2 IHJlbGF0ZWQgc3R1ZmZzLiBJZiBhbGxvd2VkLCBwbGVhc2UgYnJpbmcKPiA+ID4geW91ciBjb25j ZXJuIHRvIHRoZSBuZXh0IDZsb3dwYW4gZmFjZS10by1mYWNlIG1lZXRpbmcgaW4gU2FuIERpZWdv Lgo+ID4gPiBUaGVuLCB3ZSB3aWxsIGhhdmUgZnVydGhlciBkZXRhaWxzIGluIHRoZXJlIEkgYmVs aWV2ZS4uLgo+ID4gPgo+ID4gPiAtLQo+ID4gPgo+ID4gPgo+ID4gPiBEYW5pZWwgKFNvb2hvbmcg RGFuaWVsIFBhcmspCj4gPiA+IE1vYmlsZSBDb252ZXJnZW5jZSBMYWJvcmF0b3J5LCBTQU1TVU5H IEVsZWN0cm9uaWNzLgo+ID4gPgo+ID4gPgo+ID4gPgo+ID4gPiBPbiA5LzIxLzA2LCBEYXZpZCBD dWxsZXIgPGRhdmlkLmN1bGxlckBnbWFpbC5jb20+IHdyb3RlOgo+ID4gPiA+IERlYXIgQWxsLAo+ ID4gPiA+Cj4gPiA+ID4gSSB3b3VsZCBsaWtlIHRvIHJhaXNlIGEgY29uY2VybiBhYm91dCB0aGUg TWVzaCBEZWxpdmVyeSBGaWVsZAo+ID4gPiA+IGRlZmluaXRpb24gaW4gU2VjdGlvbiAxMSBvZiB0 aGUgZm9ybWF0IGRvY3VtZW50LiAgV2hpbGUgdGhlIGFjdHVhbAo+ID4gPiA+IG1lc2ggcm91dGlu ZyBwcm90b2NvbCBpcyBhcHByb3ByaWF0ZWx5IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZQo+ID4g PiA+IDZsb3dwYW4gRm9ybWF0IGRvY3VtZW50LCB0aGF0IGZvcm1hdCBuZWVkcyBwcm92aWRlIHRo ZSByYXcgc3RydWN0dXJlCj4gPiA+ID4gdXBvbiB3aGljaCByb3VnaCBjb25zZW5zdXMgYW5kIHJ1 bm5pbmcgY29kZSBjYW4gYmUgZmxvdXJpc2guICBXZQo+ID4gPiA+IGtub3cgdGhhdCBsb3cgcG93 ZXIgd2lyZWxlc3MgbWVzaCByb3V0aW5nIGlzIHRlY2huaWNhbGx5IHRyaWNreSBhbmQKPiA+ID4g PiBzdHJvbmdseSBpbmZsdWVuY2VkIGJ5IHRhcmdldCB0cmFmZmljIGxvYWQsIHBvd2VyIG1hbmFn ZW1lbnQKPiA+IHByb2ZpbGUsCj4gPiA+ID4gbmV0d29yayBkZXNpZ24sIGFuZCBzbyBvbi4gIFRo dXMsIGl0IGlzIHJlYXNvbmFibGUgdG8gZXhwZWN0IHRoYXQKPiA+IHRoZQo+ID4gPiA+IGNvbnNl bnN1cyBidWlsZGluZyBhbmQgdGVjaG5pY2FsIHJlZmluZW1lbnQgcHJvY2VzcyB3aWxsIHJlcXVp cmUKPiA+ID4gPiBvbi1nb2luZyBleHBlcmllbmNlIHdpdGggcHJvdG9jb2wgYW5kIGltcGxlbWVu dGF0aW9uIGFsdGVybmF0aXZlcy4KPiA+ID4gPiBUaGUgNmxvd3BhbiBmb3JtYXQgZG9jdW1lbnQg c2hvdWxkIHN1cHBvcnQgdGhpcyBwcm9jZXNzLCBhbHRob3VnaCBpdAo+ID4gPiA+IHNob3VsZCBu b3QgZGljdGF0ZSBpdHMgY29uY2x1c2lvbi4KPiA+ID4gPgo+ID4gPiA+IEJhc2VkIG9uIHBhc3Qg ZXhwZXJpZW5jZSB3aXRoIElQIGxheWVyIDMgcm91dGluZyBhbmQgd2l0aCBwYXN0Cj4gPiA+ID4g aW50ZXJuYWxseSByb3V0ZWQgbGlua3MsIHdlIGNhbiBlc3RhYmxpc2ggYSBmZXcgcHJpbWFyeSBn b2FscyBmb3IKPiA+IHRoZQo+ID4gPiA+IGV4cHJlc3NpdmVuZXNzIG9mIHRoZSA2bG93cGFuIE1l c2ggRGVsaXZlcnkgRmllbGQuCj4gPiA+ID4gICAgKDEpIEl0IHNob3VsZCBzdXBwb3J0IHRoZSB2 aXNpYmlsaXR5IGludG8gdGhlIHJvdXRlZCAxNS40IGNsb3VkCj4gPiA+ID4gbmVjZXNzYXJ5IHRv IGRldmVsb3AsIGRlYnVnLCBkaWFnbm9zZSwgYW5kIG1hbmFnZSB0aGUgMTUuNCBjbG91ZC4KPiA+ ID4gPiAgICAoMikgSXQgc2hvdWxkIHN1cHBvcnQgdGhlIGFiaWxpdHkgdG8gZGVmaW5lLCBkZXZl bG9wIGFuZCBjb21wYXJlCj4gPiA+ID4gcm91dGluZyBwcm90b2NvbHMgYW5kIHBvc3NpYmx5IHN1 cHBvcnQgdGhlIHByZXNlbmNlIG9mIG11bHRpcGxlCj4gPiA+ID4gcHJvdG9jb2xzIGZvciB3aWRl bHkgZGlmZmVyaW5nIHVzYWdlIGNhc2VzLgo+ID4gPiA+ICAgICgzKSBJdCBuZWVkcyB0byBiZSBw b3NzaWJsZSBmb3Igbm9kZXMgdG8gY29tbXVuaWNhdGUgd2l0aCBvdGhlcgo+ID4gbm9kZXMKPiA+ ID4gPiBpbiB0aGUgY2xvdWQgaW4gb3JkZXIgdG8gZGlzY292ZXIgYW5kIG5lZ290aWF0ZSBqb2lu aW5nIHRoZSBjbG91ZAo+ID4gPiA+IHdpdGhvdXQgam9pbmluZyB0aGUgY2xvdWQgYSBwcmlvcmkg dGhyb3VnaCBzb21lIG1lY2hhbmlzbSB0aGF0IGlzCj4gPiA+ID4gb3BhcXVlIHRvIElQIGFuZCBh Ym92ZS4KPiA+ID4gPgo+ID4gPiA+ICgxKSBoYXMgaGlzdG9yaWNhbGx5IGJlZW4gYWRkcmVzc2Vk IHRocm91Z2ggdmFyaW91cyBmb3JtcyBvZiBzb3VyY2UKPiA+ID4gPiByb3V0aW5nLiAgSXQgc2hv dWxkIGJlIHBvc3NpYmxlIHRvIGRvIHRoZSBlcXVpdmFsZW50IG9mIHRyYWNlcm91dGUKPiA+ID4g PiB0aHJvdWdoIHRoZSAxNS40IG1lc2ggYW5kIHRoaXMgc2hvdWxkIGJlIGFjY2Vzc2libGUgaW4g c29tZSBmb3JtCj4gPiB0aHJvdWdoIElQCj4gPiA+ID4gc28KPiA+ID4gPiBoaWdoZXIgbGF5ZXJz IGNhbiBiZSBidWlsdCB0byBwZXJmb3JtIHRoZSBtYW5hZ2VtZW50LiAgVGhlIGN1cnJlbnQKPiA+ ID4gPiBNZXNoIERlbGl2ZXJ5IEZpZWxkIGRlZmluaXRpb24gc2VlbXMgdG8gcHJvaGliaXQgYW55 IGZvcm0gb2Ygc291cmNlCj4gPiByb3V0aW5nLgo+ID4gPiA+IEl0IGFzc3VtZXMgdGhhdCB0aGUg cm91dGluZyB0YWJsZXMgYXJlIGFsbCBzZXQgdXAgYW5kIGNvcnJlY3Qgc28KPiA+IHRoYXQKPiA+ ID4gPiB0aGUgZm9yd2FyZGVyIGNhbiAic3dpenpsZSIgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3Mg ZmllbGQgb2YgdGhlCj4gPiAxNS40Cj4gPiA+ID4gaGVhZGVyIHdpdGggYSB0YWJsZSBlbnRyeS4g IChUaGUgZXhwZXJpZW5jZSBvZiBJUCBvdmVyIEFUTSBhbmQgdGhlCj4gPiA+ID4gdGhvdXNhbmRz IG9mIHBhZ2VzIG9mIHRoZSBRODNiIHNpZ25hbGxpbmcgcHJvdG9jb2wgcmVxdWlyZWQgdG8gc2V0 Cj4gPiB1cAo+ID4gPiA+IGFsbCB0aGUgdGFibGVzIGluIGFkdmFuY2Ugb3VnaHQgdG8gZ2l2ZSB1 cyBhIGxpdHRsZSBwYXVzZQo+ID4gaGVyZS4pICBUaGUKPiA+ID4gPiBpZGVhIG9mIHN1cHBvcnRp bmcgdGFibGUtZHJpdmVuIHJvdXRpbmcgYW5kIHRoZXJlYnkgc2VwYXJhdGluZyB0aGUKPiA+ID4g PiByb3V0ZSBmb3JtYXRpb24gZnJvbSB0aGUgZm9yd2FyZGluZyBlbmdpbmUgaXMgYSBnb29kIG9u ZSwgYnV0IHRoZXJlCj4gPiA+ID4gbmVlZHMgdG8gYmUgZW5vdWdoIGV4cHJlc3NpdmUgcG93ZXIg dG8gc3VwcG9ydCB0aGUgcHJvdG9jb2xzIHRoYXQKPiA+IHdpbGwKPiA+ID4gPiBlc3RhYmxpc2gg YW5kIG1hbmFnZSB0aG9zZSB0YWJsZXMgKHJhdGhlciB0aGFuIHJlbHlpbmcgb24gYW4gb3BhcXVl Cj4gPiA+ID4gb3V0LW9mLWJhbmQgc2lnbmFsaW5nIG1lY2hhbmlzbSkgYW5kIHRoZXJlIG5lZWRz IHRvIGJlIHRoZSBhYmlsaXR5Cj4gPiB0bwo+ID4gPiA+IHF1ZXJ5IGFuZCB2YWxpZGF0ZSB0aG9z ZSB0YWJsZXMgd2l0aG91dCByZWx5aW5nIG9uIG91dC1vZi1iYW5kCj4gPiA+ID4gbWVjaGFuaXNt cy4KPiA+ID4gPgo+ID4gPiA+ICgyKSBoYXMgaGlzdG9yaWNhbGx5IGJlIGFkZHJlc3NlZCB3aXRo IHByb3RvY29sIGlkZW50aWZpZXJzIGFuZAo+ID4gPiA+IG9wdGlvbnMuICBBcyB3ZSB3ZW50IHRo cm91Z2ggdGhlIHZhcmlvdXMgUklQLCBPU1BGLCBldGMuIHdlIGRpZG4ndAo+ID4gPiA+IG5lZWQg dG8gZ28gYmFjayBhbmQgcmVkZWZpbmUgdGhlIGZvcm1hdCBkb2N1bWVudHMuICBUaGVyZSB3YXMg ZW5vdWdoCj4gPgo+ID4gPiA+IGV4cHJlc3NpdmVuZXNzIGZvciB0b3BvbG9neSBmb3JtYXRpb24g YW5kIHJvdXRpbmcgdG8gZXZvbHZlLiAgTm90Cj4gPiBhbGwKPiA+ID4gPiBuZXR3b3JrcyBuZWVk IHRvIHN1cHBvcnQgYWxsIHByb3RvY29scy4gIFRoYXQgaGFzIGJlZW4gdGhlIG5ldHdvcmsKPiA+ ID4gPiBkZXNpZ25lcnMnIGRldGVybWluYXRpb24uICBUaGUgdW5kZXJseWluZyBzdHJ1Y3R1cmUg cHJvdmlkZWQgdGhlCj4gPiA+ID4gcHJpbWl0aXZlcywgYWxsb3dpbmcgc29sdXRpb25zIChhbmQg Y29uc2Vuc3VzKSB0byBldm9sdmUuICBXZSB3YW50Cj4gPiB0bwo+ID4gPiA+IGF2b2lkIGNyZWF0 aW5nIGEgIndpbm5lciB0YWtlIGFsbCIgc3RydWN0dXJlIHdoZXJlIHRoZXJlIGlzIG5vIHJvb20K PiA+ID4gPiBmb3IgZXZvbHV0aW9uIGFuZCBkZXZlbG9wbWVudC4gIEl0IGlzIHBvc3NpYmxlIHRo YXQgQU9EViwgb3IKPiA+IFRpbnlBT0RWLAo+ID4gPiA+IG9yIERTUiwgb3IgR1BTUiBvciBwb3Nz aWJseSBvbmUgb2Ygc2V2ZXJhbCBvdGhlciBhbHRlcm5hdGl2ZXMgaXMgdGhlCj4gPiByaWdodAo+ ID4gPiA+IHNvbHV0aW9uLiAgSG93ZXZlciwgdGhlcmUgaXMgbGl0dGxlIGV2aWRlbmNlIG9mIG9u ZSBoYXZpbmcgY2xlYXIKPiA+IHN1cGVyaW9yaXR5Cj4gPiA+ID4gYXQKPiA+ID4gPiB0aGlzIHRp bWUsIGRlc3BpdGUgbnVtZXJvdXMgaGlnaCBwcm9maWxlIGVmZm9ydHMuICBXZSBzaG91bGQgYmUK PiA+IGRlZmluaW5nIHRoZQo+ID4gPiA+IGNhbnZhcyB1cG9uIHdoaWNoIGNvbXBldGluZyBhbHRl cm5hdGl2ZXMgY2FuIGJlIGRlZmluZWQgYW5kIHZldHRlZC4KPiA+ID4gPgo+ID4gPiA+ICgzKSBo YXMgaGlzdG9yaWNhbGx5IGJlZW4gYWRkcmVzc2VkIGJ5IGEgbGltaXRlZCBhYmlsaXR5IHRvCj4g PiA+ID4gY29tbXVuaWNhdGUgb24gdGhlIGxpbmsgdG8gYSBjcnVkZWx5IGRlZmluZWQgc2V0IG9m IG5vZGVzIGluIG9yZGVyCj4gPiB0bwo+ID4gPiA+IGJvb3RzdHJhcCB0aGUgZGlzY292ZXJ5LCBq b2luLCBhZGRyZXNzIGFzc2lnbm1lbnQsIG5lZ290aWF0aW9uLCBldGMuCj4gPiA+ID4gTW9zdCBz dWNjZXNzZnVsIGxpbmtzIHVuZGVyIElQIGxvb2sgZWl0aGVyIGxpa2UgYSBicm9hZGNhc3QgbWVk aXVtCj4gPiBvcgo+ID4gPiA+IGEgcG9pbnQtdG8tcG9pbnQgbGluayAoYSBkZWdlbmVyYXRpdmUg YnJvYWRjYXN0KS4gIFRoaXMgYWxsb3dzIEFSUCwKPiA+ID4gPiBSQVJQLCBCT09UUCwgREhDUCwg ZXRjLiB0byBnYWluIGhpZ2hlciBsZXZlbCBhY2Nlc3NpYmlsaXR5IGFuZAo+ID4gPiA+IGFkZHJl c3NpYmlsaXR5IHRocm91Z2ggdGhlIGxpbmsuICBMaW5rcyB0aGF0IHJlcXVpcmUgY29tcGxleAo+ ID4gPiA+IHNpZ25hbGluZywgZGlzY292ZXJ5LCBqb2luaW5nIGFuZCBjb29yZG5hdGlvbiBiZWxv dyB0aGUgbGluayBsYXllciwKPiA+ID4gPiBpbmNsdWRpbmcgQVRNLCBCbHVldG9vdGggKHBpY29u ZXRzIGFuZCBzY2F0dGVyIG5ldHMpLCBhbmQgSVJEQSBoYXZlCj4gPiA+ID4gcHJvdmVkIG9uZXJv dXMgZm9yIElQIGFuZCBoYXZlIGJlZW4gcmVsZWdhdGVkIHRvIGZhciBsZXNzIGdlbmVyYWwKPiA+ ID4gPiB1c2FnZSBzY2VuYXJpb3MgLSBzdWNoIGFzIHRoZSBkZXNrdG9wIFVTQiByZXBsYWNlbWVu dC4gIEV2ZW4gdGhvdWdoCj4gPiA+ID4gdGhlIHJhZGlvIGlzIGEgYnJvYWRjYXN0IG1lZGl1bSwg dGhlIGNoYWxsZW5nZSBpbiBhIHJvdXRlZCBsaW5rIGlzCj4gPiA+ID4gdGhhdCB0aGUgbGluayBp cyBub3QgYnkgZGVmYXVsdCBhIGxpbmstd2lkZSBicm9hZGNhc3QgcGh5LiAgVGhlcmUKPiA+ID4g PiBhcmUgdHdvIG5hdHVyYWwgbm90aW9ucyBvZiAiYnJvYWRjYXN0IiBpbiBhIGxvd3Bhbi4gIChp KSBUaGUKPiA+IHBoeXNpY2FsCj4gPiA+ID4gbmVpZ2hib3JzIHRoYXQgaGFwcGVuIHRvIHJlY2Vp dmUgYSB0cmFuc21pc3Npb24gYmVjYXVzZSB0aGV5IGFyZQo+ID4gY2xvc2UKPiA+ID4gPiBlbm91 Z2ggdG8gcGljayB1cCB0aGUgc2lnbmFsIGFuZCBoYXZlIHRoZWlyIHJhZGlvcyB0dXJuZWQgb24g dG8KPiA+ID4gPiByZWNlaXZlLiAgKGlpKSBUaGUgZW50aXJlIGNvbGxlY3Rpb24gb2Ygbm9kZXMg dGhhdCBjYW4gYmUgcmVhY2hlZCBieQo+ID4gYQo+ID4gPiA+IG11bHRpaG9wIGRpc3NlbWluYXRp b24gKGZsb29kKS4gIEJvdGggb2YgdGhlc2UgYXJlIGV4dHJlbWVseSB1c2VmdWwKPiA+IGluCj4g PiA+ID4gYm9vdHN0cmFwcGluZyBoaWdoZXIgbGV2ZWxzLCBpbmNsdWRpbmcgcm91dGluZywgYW5k IHNob3VsZCBiZQo+ID4gPiA+IGFkZHJlc3NlZCBpbiB0aGUgZm9ybWF0IGRvY3VtZW50LiAgQWRk aXRpb25hbGx5LCBpdCBpcyBub3QKPiA+ID4gPiBuZWNjZXNzYXJ5IHRvIHVzZSB0aGUgODAyLjE1 LjQgYmVhY29uaW5nIG1lY2hhbmlzbSB0byBicmluZyB1cCBJUAo+ID4gb3Zlcgo+ID4gPiA+IGEg MTUuNCBsaW5rLiAgUHJvdmlkaW5nIHNvbWUgZm9ybXMgb2YgYnJvYWRjYXN0IHVzaW5nIGRhdGEg ZnJhbWVzCj4gPiA+ID4gbWFrZXMgdGhlIDgwMi4xNS40IGZvcm1hdCBtdWNoIG1vcmUgbGlrZSA4 MDIuMTEgYW5kIG90aGVyIGxpbmtzIHRoYXQKPiA+ID4gPiBoYXZlIHByb3ZlZCB2ZXJ5IHN1aXRh YmxlIGZvciBJUC4gIEZldywgaWYgYW55LCBvZiB0aGUgcHVibGljIDE1LjRyb3V0aW5nCj4gPiA+ ID4gbGF5ZXJzIGRldmVsb3BlZAo+ID4gPiA+IGJ5IHRoZSBUaW55T1MgY29tbXVuaXR5IHV0aWxp emUgYmVhY29uIHBhY2tldHMuCj4gPiA+ID4KPiA+ID4gPiBUaGUgcmVjb2duaXRpb24gdGhhdCB0 aGUgY3VycmVudCBNZXNoIERlbGl2ZXJ5IGZpZWxkIG1heSBiZSB0bwo+ID4gcmVzdHJpY3RpdmUK PiA+ID4gPiBpcyBpbnRpbWF0ZWQgYnkgdGhlIG5lZWQgdG8gZGVmaW5lIGEgc2Vjb25kIGZvcm0g b2YgdGhlIGhlYWRlciBmb3IKPiA+ID4gPiBtdWx0aWNhc3QgKGFuZCBsaW5rIGxvY2FsIGJyb2Fk Y2FzdCkgdGhhdCBpbmNsdWRlcyBhIHNlcXVlbmNlCj4gPiBudW1iZXIuCj4gPiA+ID4gVGhlIG1l c2ggaGVhZGVyIGZpZWxkIHR5cGUgaXMgZGVmaW5lZCBieSB3aGV0aGVyIHRoZSBkZXN0aW5hdGlv bgo+ID4gPiA+IGFkZHJlc3MgaXMgdW5pY2FzdCBvciBtdWx0aWNhc3QuIFRoZSBkb2N1bWVudCBz dGF0ZXMgdGhhdCB0aGUgdXNlIG9mCj4gPiA+ID4gc3VjaCBhIHNlcXVlbmNlIG51bWJlciBpcyBv dXQgb2Ygc2NvcGUuIEhvd2V2ZXIsIHRoZSBvYnNlcnZhdGlvbgo+ID4gdGhhdAo+ID4gPiA+IHRo YXQgZXh0cmEgaW5mb3JtYXRpb24gbWF5IG5lZWQgdG8gYmUgaW5jbHVkZWQgZGVwZW5kaW5nIG9u IGhvdwo+ID4gPiA+IHBhY2tldHMgYXJlIHJvdXRlZCBmdXJ0aGVyIHN1Z2dlc3RzIHRoYXQgbW9y ZSBjYXJlZnVsIGZvcm1hdAo+ID4gPiA+IGRlZmluaXRpb24gaXMgbmVlZGVkIHRvIHN1cHBvcnQg ZnV0dXJlIGRldmVsb3BtZW50IG9mIG1lc2ggcm91dGluZy4KPiA+ID4gPgo+ID4gPiA+IEhhdmUg Zm9sa3Mgd2hvIGhhdmUgYmVlbiBkZXZlbG9waW5nIG1lc2ggbGF5ZXJzIGZvciBsb3dwYW42IGZl bHQKPiA+IHRoYXQKPiA+ID4gPiB0aGUgZXhpc3RpbmcgTWVzaCBEZWxpdmVyeSBGaWVsZCBpcyB0 b28gcmVzdHJpY3RpdmU/Cj4gPiA+ID4KPiA+ID4gPgo+ID4gPiA+IERhdmlkIEUuIEN1bGxlcgo+ ID4gPiA+IFVDIEJlcmtlbGV5Cj4gPiA+ID4gY3VsbGVyQGNzLmJlcmtlbGV5LmVkdQo+ID4gPiA+ Cj4gPiA+ID4KPiA+ID4gPgo+ID4gPiA+Cj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiA+ID4gPiA2bG93cGFuIG1haWxpbmcgbGlzdAo+ID4g PiA+IDZsb3dwYW5AaWV0Zi5vcmcKPiA+ID4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby82bG93cGFuCj4gPiA+ID4KPiA+ID4gPgo+ID4gPiA+Cj4gPiA+Cj4gPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiA+IDZsb3dw YW4gbWFpbGluZyBsaXN0Cj4gPiA+IDZsb3dwYW5AaWV0Zi5vcmcKPiA+ID4gaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3Bhbgo+ID4KPiA+Cj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gNmxvd3BhbiBtYWlsaW5n IGxpc3QKPiA+IDZsb3dwYW5AaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvLzZsb3dwYW4KPiA+Cj4gPgo+ID4KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiA2bG93cGFuIG1haWxpbmcgbGlzdAo+ID4g Nmxvd3BhbkBpZXRmLm9yZwo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vNmxvd3Bhbgo+ID4KPiA+Cj4gPgo+Cj4KPiAtLQo+IEtpLUh5dW5nIEtpbSAoseix4sf8LCDQ 3dHD+vspCj4gQXNzb2NpYXRlIFByb2Zlc3Nvcgo+IERpdmlzaW9uIG9mIEluZm9ybWF0aW9uIGFu ZCBDb21wdXRlciBFbmcuLCBBam91IFVuaXZlcnNpdHksIFN1d29uLCBLb3JlYQo+IDQ0Mi03NDkK PiBUZWw6ICs4Mi0zMS0yMTktMjQzMywgQ2VsOiArODItMTctNzYwLTI1NTEsICBGYXg6ICs4Mi0z MS0yMTktMjQzMwo+IGh0dHA6Ly93d3cuNmxvd3Bhbi5vcmcKCgoKCi0tIApEYXZpZCBFLiBDdWxs ZXIKQXJjaGVkIFJvY2sgQ29ycG9yYXRpb24KMjE2OCBTaGF0dHVjayBBdmUKQmVya2VsZXksIENB IDk0NzA0Cnd3dy5hcmNoZWRyb2NrLmNvbQo= ------=_Part_12049_2288102.1159544336033 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline SXQgY2VydGFpbmx5IHdvdWxkIGJlIGEgc2hhbWUgdG8gZ2V0IGludG8gYSBwb3NpdGlvbiB3aGVy ZSB0aGUgZW5jb2RpbmcgaXMgc28gc28gY29uc3RyYWluZWQgdGhhdCB0aGVyZSB3YXMgbm90IGEg bWVhbnMgb2YgYWNjb21vZGF0aW5nIGFkZGl0aW9uYWwgY2FwYWJpbGl0aWVzIHRoYXQgYXJlIHJl dmVhbGVkIHRocm91Z2ggZGVlcGVyIGltcGxlbWVudGF0aW9uIGFuZCB1c2FnZSBleHBlcmllbmNl LiZuYnNwOyBUaGUgSVAgY29tbXVuaXR5IGhhcyBoaXN0b3JpY2FsbHkgYmVlbiB2ZXJ5IGdvb2Qg YXQgcGxhbm5pbmcgZm9yIGNoYW5nZS4mbmJzcDsgT3B0aW9ucyBmaWVsZHMgYW5kIGxlYXZpbmcg YSBsaXR0bGUgcm9vbSBpbiB0aGUgaW5pdGlhbCBlbmNvZGluZ3MgYXJlIGVzc2VudGlhbCB0byB0 aGF0LiZuYnNwOyBBcyBtdWNoIGFzIHdlIHRyeSwgd2Ugc2VsZG9tIGdldCBldmVyeSBhc3BlY3Qg b2YgdGhlIHByb3RvY29sIGV4YWN0bHkgcmlnaHQgdGhlIGZpcnN0IHRpbWUuJm5ic3A7IEl0IGlz IHVuZGVyc3RhbmRhYmxlIHRoYXQgd2l0aCBzbyBtdWNoIGZvY3VzIGJlaW5nIHBsYWNlIG9uIGhl YWRlciBjb21wcmVzc2lvbiB0aGF0IGl0IGlzIGhhcmQgdG8gbGVhdmUgYW55IHNwYWNlIHVuY2xh aW1lZC4mbmJzcDsgSG93ZXZlciwgdGhhdCBjb250aW5nZW5jeSBwbGFubmluZyBhbmQgZmxleGli aWxpdHkgbWF5IGJlIG1vcmUgY3JpdGljYWwgdG8gZXZlbnR1YWwgYWRvcHRpb24gdGhhbiBzcXVl ZXppbmcgb3V0IGV2ZXJ5IHVubmVjY2Vzc2FyeSBiaXQuJm5ic3A7Jm5ic3A7IEFzIHdlIGxvb2sg YXQgdGhlIGRlc2lyZWQgJnF1b3Q7cnVzaCB0byBmaW5pc2gmcXVvdDsgaXQgaXMgaW1wb3J0YW50 IHRvIHZlcmlmeSB0aGF0IHRoZSBwcm9wb3NlZCBmcmFtZXdvcmsgcGVybWl0cyBlbm91Z2ggZXhw cmVzc2l2ZSBwb3dlciB0byBhZGRyZXNzIHRoZSBpc3N1ZXMgdGhhdCBoYXZlIG5vdCB5ZXQgYmVl biBmdWxseSB2ZXR0ZWQuJm5ic3A7IFlvdSBjYW5ub3QgZXhwYW5kIHRoZSBmb3JtYXQsIG9ubHkg d29yayB3aXRoaW4gaXQuCjxicj48YnI+PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9u IDkvMjYvMDYsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5LaS1IeXVuZyBLaW08L2I+ICZs dDs8YSBocmVmPSJtYWlsdG86a2tpbTg2QGdtYWlsLmNvbSI+a2tpbTg2QGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJi b3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0 IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KPGRpdj5HYWJyaWVsLDwvZGl2Pgo8ZGl2 PiZuYnNwOzwvZGl2Pgo8ZGl2PkkgYW0gc29ycnkgZm9yIHRoaXMgbGF0ZSByZXBseS48L2Rpdj4K PGRpdj5CYXNpY2FsbHksIEkgYWdyZWUgdGhhdCBjdXJyZW50IGZvcm1hdCBkb2N1bWVudCBpcyBy YXRoZXIgdGlnaHRseSZuYnNwO3NjaGVkdWxlZCBhbmQgbm90IHdlbGwgcHJlcGFyZWQgZm9yIGZ1 dHVyZSBlbmhhbmNlbWVudHMgb3IgcmV2aXNpb25zLCBpbiB0ZXJtcyBvZiByb3V0aW5nLCBkaWFn bm9zZXMsIG1hbmFnZW1lbnQsIGV0Yy4gQmFzZWQgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB3ZSBh cmUgbm90IHlldCBpbiB0aGUgc3RhZ2Ugb2YgcHVyc3VpbmcmbmJzcDtmdXR1cmUgcmVjaGFydGVy aW5nIGl0ZW1zLCBpdCBtaWdodCBub3QgYmUgdGhlIHJpZ2h0IHRpbWUgdG8gY29uc2lkZXIgYWxs IHRoZSBjYXNlcyBhdCBvbmUgdGltZS4gQWxzbywgd2Ugc2hvdWxkIGJlIGluIHJ1c2ggdG8gZmlu aXNoIHRoZSBjdXJyZW50IGZvcm1hdCBkb2N1bWVudCBBU0FQIGZvciBtb3ZpbmcgZm9yd2FyZCBp bnRvIG5leHQgc3RhZ2UgYmVmb3JlIG5leHQgSUVURiBtZWV0aW5nLgo8L2Rpdj4KPGRpdj4mbmJz cDs8L2Rpdj4KPGRpdj5SZWdhcmRpbmcgdGhlIG1lc2ggZGVsaXZlcnkgZmllbGQsIE1hcmlvIE1h bydzIGFwcHJvYWNoIHNob3VsZCBiZSBmaW5lLCBhbmQgb3RoZXIgYXBwcm9hY2hlcyAobGlrZSBv cHRpb24gMiwzLCBhbmQgNCkgbWlnaHQgYmUgT0suIEhvd2V2ZXIsIGl0IHNlZW1zIGxpa2Ugd2Ug YXJlJm5ic3A7dHJ5aW5nIHRvbyBtdWNoIHRvIG1ha2UgdGhlIGZvcm1hdCZuYnNwO2NvbXBhY3Qg d2hpbGUgbm90IGNvbnNpZGVyaW5nIHRoZSBmdXR1cmUgZXhwYW5zaW9ucy4gCjwvZGl2Pgo8ZGl2 PiZuYnNwOzwvZGl2Pgo8ZGl2PkFmdGVyIGFsbCwgbXkgb3BpbmlvbiBpcyBvcHRpb24gMS4gTGV0 J3MgaGF2ZSBvbmUgYnl0ZSBmb3IgdGhlIG11bHRpY2FzdCBiaXQgYW5kIHRoZSByZXNlcnZlZCBm aWVsZHMgZm9yIGZ1dHVyZS48L2Rpdj4KPGRpdj5oYXZpbmcgYWRkaXRpb25hbCBvbmUgYnl0ZSBm b3IgdGhpcyBpcyBub3QgYSBiaWcgZGVhbCZuYnNwO2luIHRlcm1zIG9mIHBhY2tldCBzaXplIGFu ZCB3b24ndCBhZGQgbXVjaCBjb21wbGV4aXR5IGZvciBoYW5kbGluZyBpdC48L2Rpdj4KPGRpdj5F eGFtcGxlcyBvZiZuYnNwO3V0aWxpemluZyZuYnNwO3NvbWUgcmVzZXJ2ZWQgZmllbGRzJm5ic3A7 bWlnaHQgYmUgZm9sbG93czo8L2Rpdj4KPGRpdj4xLiBCYXNlZCBvbiB0aGUgYXNzdW1wdGlvbiZu YnNwO3RoYXQmbmJzcDs2bG93cGFuIHN1cHBvcnRzIG11bHRpcGxlIHJvdXRpbmcgcHJvdG9jb2xz IHN1Y2ggYXMgJm5ic3A7TE9BRCwgRFlNTy1sb3csIEhpTG93LCBEU1IsIG9yIHdoYXRldmVyLCZu YnNwO2V0Yy4sIHRoZSBmaWVsZCBtaWdodCBiZSB1c2VkIGZvciBpbmRpY2F0aW5nIHdoaWNoIHNw ZWNpZmljIHJvdXRpbmcgcHJvdG9jb2wgc2hvdWxkIGJlIHVzZWQgZm9yIHJvdXRpbmcgdGhpcyBw YXJ0aWN1bGFyIHBhY2tldC4gSXQgbWlnaHQgYmUgYXJndWVkIHdoZXRoZXIgdGhlIGZvcm1hdCBk b2N1bWVudCBzaG91bGQgc3VwcG9ydCBtdWx0aXBsZSBwcm90b2NvbHMgYXQgYSB0aW1lLiBIb3dl dmVyLCB0aG9zZSBraW5kIG9mIGFyZ3VlIHNob3VsZCBiZSBkZWJhdGVkIGxhdGVyIHdoaWxlIGNv bnNpZGVyaW5nIHJvdXRpbmcgcHJvdG9jb2xzIHdpdGhvdXQgZWxpbWluYXRpbmcgZnV0dXJlIHBv c3NpYmxlIG5lY2Vzc2l0eS4KPC9kaXY+CjxkaXY+Mi4gUm91dGluZyBwcm90b2NvbHMgY291bGQg YmUgb3B0aW16ZWQgYnkgaGF2aW5nIHNvbWUgb3B0aW9uIGZpZWxkcywgd2hpbGUgaXQgbWlnaHQg bm90IGJlIHJpZ2h0IHRpbWUgdG8gc3BlY2lmaWNhbGx5IG1lbnRpb24gdGhlbS48L2Rpdj4KPGRp dj4mbmJzcDs8L2Rpdj4KPGRpdj5JIHJlbWVtYmVyIHRoYXQgdGhlIGlzc3VlIG9mJm5ic3A7dGhl IG1lc2ggdW5kZXJuZWF0aCBvciBhYm92ZSBJUCBoYXMgYmVlbiByYWlzZWQgc2V2ZXJhbCB0aW1l cyBpbiB0aGUgV0cuIEkgdGhpbmsgaXQgbWlnaHQgbm90IGJlIHJpZ2h0IHRpbWUgY29uc2lkZXJp bmcgaXQgYWdhaW4gcmlnaHQgbm93LjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PklmIHlv dSBoYXZlIGFueSBvdGhlciBvcGluaW9ucywgcGxlYXNlIGxldCBtZSBrbm93Ljxicj48YnI+Jm5i c3A7PC9kaXY+PGRpdj48c3BhbiBjbGFzcz0iZSIgaWQ9InFfMTBkZWFlODVjY2NkNTFhNF8xIj4K PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDkvMjMvMDYsIDxiIGNsYXNzPSJnbWFp bF9zZW5kZXJuYW1lIj5nYWJyaWVsIG1vbnRlbmVncm88L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86 Z2FicmllbF9tb250ZW5lZ3JvXzIwMDBAeWFob28uY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGlj az0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPgpnYWJyaWVs X21vbnRlbmVncm9fMjAwMEB5YWhvby5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+CjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdi KDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6 IDFleDsiPgo8ZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0 aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij4KPGRpdiBzdHlsZT0iZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNl cmlmOyI+Rmlyc3Qgb2YgYWxsLCBUaGFua3MgRGF2aWQgZm9yIHlvdXIgdGhvdWdodGZ1bCBtZXNz YWdlLiBJdCdzIGdyZWF0IHRvIHNlZSB5b3UgcGFydGljaXBhdGUgaW4gdGhpcyBmb3J1bSBhbmQg SSBob3BlPC9kaXY+CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRp bWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZjsiPnlvdSdsbCBzdGljayBhcm91bmQh PC9kaXY+CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5l dyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZjsiPiZuYnNwOzwvZGl2Pgo8ZGl2IHN0eWxlPSJm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGlt ZXMsc2VyaWY7Ij5Gcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGxheWluZyB0aGUgdGVjaG5vbG9n eSBmb3VuZGF0aW9uLCBldmVyeXRoaW5nIGluIHlvdXIgbWVzc2FnZSBpcyBxdWl0ZSByZWxldmFu dC48L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogdGltZXMg bmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmOyI+RnJvbSB0aGUgcG9pbnQgb2YgdmlldyBv ZiBXRyBtYW5hZ2VtZW50LCBJJ20gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaWYgd2UgbmVlZCB0byBh Y3Qgb24gYWxsIG9mIGl0IHJpZ2h0IG5vdzwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij5v ciBpZiB0aGVyZSBhcmUgdGhpbmdzIHdlIGNhbiBhZGRyZXNzIGluZGVwZW5kZW50bHkgb2YgdGhl IGZvcm1hdCBkcmFmdCB1bmRlciBkaXNjdXNzaW9uLiBGb3IgZXhhbXBsZSw8L2Rpdj4KPGRpdiBz dHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLG5ldyB5 b3JrLHRpbWVzLHNlcmlmOyI+eW91IGJyaW5nIHVwIHRoZSB0b3BpYyBvZiB0cmFjZXJvdXRlIHR5 cGUgZnVuY3Rpb25hbGl0eS4gSW4gSVAsIHRoaXMgaXMgY2FycmllZCBvdmVyIElDTVAsIGEgc2Vw YXJhdGUgPC9kaXY+CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRp bWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZjsiPm1hbmFnZW1lbnQgY29udHJvbCBw bGFuZS4gU2luY2Ugd2hhdCB3ZSBoYXZlIGluIHRoZSBmb3JtYXQgZHJhZnQgaXMgYSBtdWx0aXBs ZXhpbmcgbGF5ZXIsIHdlIGNhbiA8L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmOyI+ZGVmaW5l IGEgbmV3IHByb3RvY29sIHZhbHVlIHRvIGNhcnJ5IG91dCB0aGUgbWFuYWdlbWVudCBwcm90b2Nv bCBwYWNrZXRzLiBUaGUgcXVlc3Rpb24gaXMgaWYgdGhlPC9kaXY+CjxkaXYgc3R5bGU9ImZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxz ZXJpZjsiPmN1cnJlbnQgZm9ybWF0IHByb3ZpZGVzIHRoZSByZXF1aXJlZCBtZWNoYW5pc20gdG8g Z28gZG8gd29yayBvbiBzdWNoIGEgc2VwYXJhdGUgcHJvdG9jb2w8L2Rpdj4KPGRpdiBzdHlsZT0i Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRp bWVzLHNlcmlmOyI+aW4gYW5vdGhlciBkcmFmdC4gSW50dWl0aXZlbHksIGl0IHNlZW1zIGxpa2Ug dGhpcyB3b3VsZCB3b3JrLiBTb21lb25lICh5b3VyIGdyb3VwLCBEYXZpZD8pIGNvdWxkPC9kaXY+ CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21h bixuZXcgeW9yayx0aW1lcyxzZXJpZjsiPmRlZmluZSBzdWNoIGEgcHJvdG9jb2wgd2l0aCBmdW5j dGlvbmFsaXR5IHNpbWlsYXIgdG8gSUNNUCBmb3IgcGluZ3MsIHRyYWNlcm91dGUsIGV0YyBhbmQg cHJvdmlkZTwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0 aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij50aGUgcm91dGUgZ2F0aGVyaW5n IGZ1bmN0aW9uYWxpdHksIHRoZSBlY2hvIHJlc3BvbnNlLCBldGMgaW4gdGhhdCBzZXBhcmF0ZSBk cmFmdC4gQ29uY2VpdmFibHksIGl0PC9kaXY+CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZjsiPndvdWxk IG5vdCBuZWNlc3NhcmlseSB1c2UgdGhlIG1lc2ggZGVsaXZlcnkgaGVhZGVyLCBhcyBpdCB3b3Vs ZCBwcm92aWRlIGl0cyBvd24gZmFjaWxpdHkgdG88L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlm OyI+cmVjb3JkIGhvcC1ieS1ob3Agcm91dGUgaW5mb3JtYXRpb24gd2l0aGluIGl0cyBvd24gcHJv dG9jb2wgZmllbGRzLiBJdCBjb3VsZCB1c2UgbG9vc2Ugc291cmNlPC9kaXY+CjxkaXYgc3R5bGU9 ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0 aW1lcyxzZXJpZjsiPnJvdXRpbmcgaW4gd2hpY2ggY2FzZSBzb21lIHVzZSBvZiB0aGUgbWVzaCBk ZWxpdmVyeSBoZWFkZXIgbWlnaHQgYmUgYXBwcm9wcmlhdGUgYXMgd2VsbC48L2Rpdj4KPGRpdiBz dHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLG5ldyB5 b3JrLHRpbWVzLHNlcmlmOyI+V291bGQgc3VjaCBhbiBhcHByb2FjaCB3b3JrLCBEYXZpZD8gVGhp cyB3b3VsZCBhY3R1YWxseSBwbGF5IGludG8gb25lIG9mIHRoZSBpdGVtcyBzbGF0ZWQgZm9yPC9k aXY+CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5ldyBy b21hbixuZXcgeW9yayx0aW1lcyxzZXJpZjsiPnRoZSBuZXh0IHJvdW5kIG9mIDZsb3dwYW4gKGlm IHdlIGV2ZXIgcmVjaGFydGVyKSB0byBzdHJlbmd0aGVuIGRpYWdub3NhYmlsaXR5IG9yIG1hbmFn ZW1lbnQgb2Y8L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog dGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmOyI+dGhlc2UgbmV0d29ya3MuPC9k aXY+CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5ldyBy b21hbixuZXcgeW9yayx0aW1lcyxzZXJpZjsiPiZuYnNwOzwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMs c2VyaWY7Ij5BcyBmb3IgeW91ciBwb2ludCBhYm91dCB1cyBub3Qga25vd2luZyBleGFjdGx5IHdo YXQgdGhlIGhlYWRlciBmb3JtYXQgbXVzdCBsb29rIGxpa2UgYXQgdGhpcyBwb2ludCBpbjwvZGl2 Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9t YW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij50aW1lLCB0aGlzIGlzIHBlcmhhcHMgc29tZXRoaW5n IHdlIG5lZWQgdG8gdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24gcmlnaHQgbm93LiBGb3IgZXhhbXBs ZSwgdGhpczwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0 aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij5pbnB1dCB3b3VsZCBwdXNoIHVz IGludG8gcmVzZXJ2aW5nIGF0IGxlYXN0IGEgY291cGxlIG9mIGJpdHMgaW4gdGhlIGhlYWRlciZu YnNwO2ZvciBmdXR1cmUgZXhwYW5zaW9uLiBBIHdoaWxlPC9kaXY+CjxkaXYgc3R5bGU9ImZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxz ZXJpZjsiPmJhY2sgVmlwdWwgd2FzIGFyZ3VpbmcgZm9yIGEgJnF1b3Q7dmVyc2lvbiZxdW90OyBm aWVsZC4gTm90IHN1cmUgaWYgc3VjaCBhIGZpZWxkIGlzIHJlcXVpcmVkIG9yIGlmIHRoZSBjdXJy ZW50IHJlc2VydmVkPC9kaXY+CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZjsiPmZpZWxkcyBhcmUgZW5v dWdoLiBNYXJpbyBNYW8ncyBwcm9wb3NhbCB1c2VzIG9uZSBvZiB0aG9zZSByZXNlcnZlZCBiaXRz IHRvIHNvbHZlIHRoZSBpc3N1ZSB1bmRlcjwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij5k aXNjdXNzaW9uIHJlZ2FyZGluZyB0aGUgbWVzaCBkZWxpdmVyeSBoZWFkZXIgdmFyaWFudHMgZm9y IHVuaWNhc3QgdnMgbWNhc3QvYmNhc3QuIFRoZXJlIGhhcyBiZWVuIDwvZGl2Pgo8ZGl2IHN0eWxl PSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmss dGltZXMsc2VyaWY7Ij5vbmUgZ3JvdXAgZXhwcmVzc2luZyBzdXBwb3J0IGZvciB0aGlzLCBzbyBw ZXJoYXBzIHdlIGFscmVhZHkgaGF2ZSB0aGUgbmVjZXNzYXJ5IG1lY2hhbmlzbSBpbiBwbGFjZTwv ZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcg cm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij5pbiB0aGUgaGVhZGVyLjwvZGl2Pgo8ZGl2IHN0 eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlv cmssdGltZXMsc2VyaWY7Ij4mbmJzcDs8L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmOyI+RGF2 aWQsIHlvdSBhbHNvIG1lbnRpb24gdGhlIG5lZWQgdG8gc3VwcG9ydCBkaWZmZXJlbnQgcm91dGlu ZyBwcm90b2NvbHMgc2lkZS1ieS1zaWRlIGZvciBjb21wYXJpc29uLjwvZGl2Pgo8ZGl2IHN0eWxl PSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmss dGltZXMsc2VyaWY7Ij5UaGlzIGlzIG9uZSBvZiB0aGUgZGVzaWduIGdvYWxzIG9mIHRoZSBmb3Jt YXQgZG9jdW1lbnQuIEFzIEkgbWVudGlvbmVkLCB0aGUgcHJvdG9jb2wgZmllbGQgYWxsb3dzIG9u ZTwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBu ZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij50byBjYXJyeSBkaWZmZXJlbnQgcHJvdG9j b2xzLiBXZSBjdXJyZW50bHkgaGF2ZSBwcm9wb3NhbHMgZm9yIGEgNmxvd3BhbiBhZGFwdGF0aW9u cyBvZiZuYnNwO0FPRFYsIGEgRHlNTzwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij5hbmQg SGlMb3cuIEkga25vdyBOYW5kdSB3YXMgdGhpbmtpbmcgb2YgZG9pbmcgb25lIGZvciBPTFNSLiBQ ZXJoYXBzIEJWUiBpcyBuZXh0LiBUaGUgcG9pbnQgaXMgdGhhdDwvZGl2Pgo8ZGl2IHN0eWxlPSJm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGlt ZXMsc2VyaWY7Ij50aGUgZm9ybWF0IGRvY3VtZW50IGRvZXMgcHJvdmlkZSB0aGUgbWVjaGFuaXNt IHRvIGRlZmluZSBhbnkgc3VjaCBwcm90b2NvbCwgb3IgaXMgdGhlcmUgYSBsaW1pdGF0aW9uIHlv dTwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBu ZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij5jYW4gc2VlIGluIHRoZSBjdXJyZW50IGRv Y3VtZW50PyBJZiBzbywgd2hhdCBuZWVkcyB0byBjaGFuZ2U/PC9kaXY+CjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1l cyxzZXJpZjsiPiZuYnNwOzwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij5BcyBmb3IgdGhl IGNsYWltIHRoYXQgc3ViLUlQIGJlbmVmaXRzIGZyb20gc2ltcGxlciBzdHJ1Y3R1cmVzLCBteSBp bnRlcnByZXRhdGlvbiBpcyB0aGF0IHlvdSdyZSBzdWdnZXN0aW5nIGl0IDwvZGl2Pgo8ZGl2IHN0 eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlv cmssdGltZXMsc2VyaWY7Ij5pcyBiZXR0ZXIgbm90IHRvIHVzZSB0aGUgbWVzaCBkZWxpdmVyeSBo ZWFkZXIgYW5kIGxldCBJUCBkZWFsIHdpdGggdGhlIHVuZGVybHlpbmcgaW5kaXZpZHVhbCBjb2xs ZWN0aW9uIG9mIGxpbmtzLjwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij5JZiBzbywgb25l IGNhbiBpZ25vcmUgdGhlIG1lc2ggZGVsaXZlcnkgaGVhZGVyIChub3QgdXNlIGl0KSBhbmQgdXNl IHRoZSBvdGhlciBwYXJ0cyBvZiB0aGUgZm9ybWF0IGRvY3VtZW50IHRvPC9kaXY+CjxkaXYgc3R5 bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9y ayx0aW1lcyxzZXJpZjsiPnNpbXBseSBsYXllciBJUCBvbiB0b3AuIFRoaXMgYXBwcm9hY2ggd291 bGQgdGhlbiBtYWtlIHVzZSBvZiBvdGhlciBhY3Rpdml0aWVzIGxpa2UgQVVUT0NPTkYgb3IgTUFO RVQ8L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogdGltZXMg bmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmOyI+dG8gY3JlYXRlIG1lc2hlcyBpZiBzbyBk ZXNpcmVkLiZuYnNwOyBQZXJzb25hbGx5LCBJIHNlZSB0aGF0ICppZiogb25lIHdpc2hlcyB0byBk byBhIG1lc2gsIG5vdCBkb2luZyBpdCBpbiB0aGUgc3ViLUlQPC9kaXY+CjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1l cyxzZXJpZjsiPmxheWVyIGp1c3QgcHVzaGVzIHRvIHByb2JsZW0gdXB3YXJkcyBpbnRvIHRoZSBJ UCByb3V0aW5nIHJlYWxtLCBhbmQgdGhpcyBqdXN0IG1ha2VzIHRoaW5ncyBldmVuIG1vcmUgY29t cGxleDwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1l cyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij50aGFuIGRvaW5nIGl0IHVuZGVyIHN1 Yi1JUC4gQ29tcGxleGl0eSB3aWxsIGJlIHRoZXJlIG5vIG1hdHRlciB3aGF0LCBpdCdzIGp1c3Qg YSBxdWVzdGlvbiBvZiB3aGVyZSBvbmUgd2FudHMgdG88L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNl cmlmOyI+YWRkcmVzcyBpdC4gSSBkbyBub3RlIHRoYXQgc3ViLUlQIGNvbXBsZXggc3RydWN0dXJl cyBhcmUgdmVyeSBwb3B1bGFyIGFuZCBkZXBsb3llZCBpbiBzb21lIGNhc2VzICg4MDIuMWQgYnJp ZGdlZDwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1l cyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij5uZXR3b3JrcykuIFBlcmhhcHMgbGlr ZWx5IHRvIGJlY29tZSBldmVuIG1vcmUgc28gd2l0aCA4MDIuMTFzIHdpdGhpbiBhIGZldyB5ZWFy cy48L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogdGltZXMg bmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmOyI+Jm5ic3A7PC9kaXY+CjxkaXYgc3R5bGU9 ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0 aW1lcyxzZXJpZjsiPkkgd291bGQgbm90IGJlIGludGVyZXN0ZWQgaW4gcHVyc3VpbmcgYW4gQVVU T0NPTkYgcGF0aCwgYnV0IHRoaW5rIGl0IHNob3VsZDwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2Vy aWY7Ij5iZSBwb3NzaWJsZSB0byBkbyBzbyBmb3IgdGhvc2Ugc28gaW5jbGluZWQuIERvZXMgdGhp cyBzb3VuZCBkb2FibGU/IEFnYWluLCBteSBpbW1lZGlhdGUgY29uY2VybiBpcyB0aGF0IHRoZTwv ZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBuZXcg cm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij5mb3JtYXQgZG9jdW1lbnQgbm90IHByZXZlbnQg dGhpcyBhcHByb2FjaC4gPC9kaXY+PHNwYW4+CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZjsiPiZuYnNw OzwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiB0aW1lcyBu ZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij4tZ2FicmllbDxicj48YnI+Jm5ic3A7PC9k aXY+PC9zcGFuPgo8ZGl2PjxzcGFuPgo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7Ij4tLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS08YnI+RnJvbTogR2VvZmYgTXVsbGlnYW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpnZW9mZkBtdWxsaWdhbi5jb20iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4g dG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+CgpnZW9mZkBtdWxsaWdhbi5j b208L2E+Jmd0Ozxicj5UbzogU29vaG9uZyBEYW5pZWwgUGFyayAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNvb2hvbmdwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3Au anMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5zb29ob25ncEBnbWFpbC5jb208L2E+ Jmd0Ozxicj5DYzogPGEgaHJlZj0ibWFpbHRvOjZsb3dwYW5AaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSI+Cgo2bG93cGFuQGlldGYub3JnPC9hPjsgRGF2aWQgQ3VsbGVyICZsdDs8YSBocmVmPSJtYWls dG86ZGF2aWQuY3VsbGVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5kYXZpZC5jdWxsZXJAZ21h aWwuY29tPC9hPiZndDs8YnI+U2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMDYgNjo0MToy MSBBTQo8YnI+U3ViamVjdDogUmU6IFs2bG93cGFuXSBNZXNoIERlbGl2ZXJ5IEZpZWxkPGJyPjxi cj4KPGRpdj5EYW5pZWwsPGJyPiZuYnNwOyZuYnNwO1doaWxlIHRoZSBXRyBsYXN0IGNhbGwgZGlk IGV4cGlyZSwgSSdtIG5vdCBzdXJlIGlmIERhdmlkIGlzIHRvbyBsYXRlLjxicj5JIHRoaW5rIHRo YXQgaGUgcmFpc2VzIHNvbWUgaW1wb3J0YW50IGNvbmNlcm5zIGFuZCBJJ20gbm90IHN1cmUgdGhh dCB3ZTxicj5yZWFsbHkgaGF2ZSBjb25zZW5zdXMgb24gdGhlIG1lc2ggZGVsaXZlcnkgZmllbGQu PGJyPjxicj4KCkkgd291bGQgbGlrZSB0byBoZWFyIGZyb20gdGhlIGxpc3Qgb24gdGhpcy4mbmJz cDsmbmJzcDtJIHRoaW5rIHRoYXQgR2FicmllbCBoYXM8YnI+cHV0IGZvcnRoIDQgYWx0ZXJuYXRp dmVzLiZuYnNwOyZuYnNwO0NhcnN0ZW4gaW5kaWNhdGVkIHRoYXQgaGUgdGhvdWdodCBoZSBtaWdo dDxicj5oYXZlIGEgZGlmZmVyZW50IGFsdGVybmF0aXZlIGFuZCB3b3VsZCBwb3N0IHRvIHRoZSBs aXN0IGVpdGhlciB0aGU8YnI+YWx0ZXJuYXRpdmUgb3IgaGlzIGNvbnNpZGVyYXRpb24gb2YgdGhl IDQgYWx0ZXJuYXRpdmVzIC0gQ2Fyc3RlbiwgcGxlYXNlCjxicj5zZW5kIHlvdXIgdGhvdWdodHMu PGJyPjxicj5JIGZlZWwgdGhhdCB0aGUgaXNzdWUgRGF2aWQgcmFpc2VzIHNob3VsZCBiZSBkZWFs dCB3aXRoIGJ5IHRoZSBXRzxicj5iZWNhdXNlIEkgZG8gbm90IHdhbnQgdG8gc2VuZCB0aGUgZHJh ZnQgb24gdG8gdGhlIElFU0cgb25seSB0byBoYXZlPGJyPnRoZXNlIGlzc3VlcyBicm91Z2h0IHVw IGluIHRoZSBJRVRGIGxhc3QgY2FsbC4mbmJzcDsmbmJzcDtUaGVzZSBzZWVtIHJhdGhlcgo8YnI+ ZnVuZGFtZW50YWwgdG8gbWUgYW5kIHdlIG1pZ2h0IGxvb2sgcmF0aGVyIGZvb2xpc2ggbm90IGhh dmluZyByZXNvbHZlZDxicj50aGlzIGluIHRoZSB3b3JraW5nIGdyb3VwITxicj48YnI+V2UgbmVl ZCBzb21lIHNpZ25pZmljYW50IGRpc2N1c3Npb24gZnJvbSB0aGUgbWVtYmVycyBvZiB0aGUgV0cu Jm5ic3A7Jm5ic3A7VGhpcyBXRzxicj5oYXMgYmVlbiwgbXkgc2VsZiBpbmNsdWRlZCwgcmF0aGVy IHF1aWV0IGFuZCBhcyBhIHJlc3VsdCB3ZSBoYXZlIG1vdmVkCjxicj5hdCBhIHNuYWlscyBwYWNl IGdldHRpbmcgYW55dGhpbmcgZG9uZS4mbmJzcDsmbmJzcDtJIGltcGxvcmUgZXZlcnlvbmUgdG8g dGFrZSB0aW1lPGJyPmFuZCByZWFkIHRoZSB0aHJlYWQgb24gdGhlIG1lc2ggZmllbGQgYW5kIHNl bmQgeW91ciB0aG91Z2h0cywgcHJvLCBjb248YnI+b3Igb3RoZXJ3aXNlIHRvIHRoaXMgbGlzdC4m bmJzcDsmbmJzcDtJZiBldmVyeW9uZSBjb250aW51ZXMgdG8gYmUgYXBhdGhldGljIGFib3V0Cjxi cj50aGlzIHdvcmssIEkgaG9sZCBsaXR0bGUgaG9wZSBmb3IgdGhpcyBXRyBiZWluZyByZWNoYXJ0 ZXJlZCB0byBkbyBhbnk8YnI+b3RoZXIgd29yayE8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO2dlb2ZmPGJyPjxicj5PbiBGcmksIDIwMDYtMDktMjIgYXQgMTk6MjMgKzEwMDAsIFNvb2hv bmcgRGFuaWVsIFBhcmsgd3JvdGU6PGJyPiZndDsgRGF2aWQsPGJyPiZndDsgPGJyPiZndDsgRmly c3Qgb2ZmLCB5b3VyIGlzc3VlIHJhaXNpbmcgaW4gdGhpcyB0aHJlYWQgc2VlbXMgdG9vIGxhdGUg c2luY2Ugb3VyCjxicj4mZ3Q7IG9mZmljaWFsIFdHTEMgd2FzIGV4cGlyZWQ6ICZxdW90O1RoaXMg TGFzdCBDYWxsIHdpbGwgZW5kIG9uIFdlZG5lc2RheSAwMjxicj4mZ3Q7IEF1Z3VzdCAyMDA2IGF0 IDIzNTkgVVRDLiZxdW90Ozxicj4mZ3Q7IDxicj4mZ3Q7IEFueXdheSwgbXkgc2Vuc2UgaXMgbm90 IHRvIHRha2UgTWVzaCBpc3N1ZSBhdCB0aGlzIHN0YWdlLiBBcyBsb25nIGFzPGJyPiZndDsgd2Ug YXJlIGxvb2tpbmcgYXQgdGhlIDZsb3dwYW4gc29sdXRpb24gZm9ybWF0LCBtZXNoIGlzIG91dCBv ZiBzY29wZSBvZgo8YnI+Jmd0OyB0aGF0LiBJbiBmYWN0LCBhcyBmYXIgYXMgSSBhbSBjb25jZXJu LCBtZXNoIGJlbG9uZ3MgdG8gMTUuNCB0ZWNobm9sb2d5PGJyPiZndDsgYmFzZWQgb24gTUFDIGxh eWVyLiBJbnN0ZWFkLCBhcyBkZXNjcmliZWQgaW4gdGhlIHJlY2hhcnRlcmluZywgd2Ugd2lsbDxi cj4mZ3Q7IGdvIHRocm91Z2ggYWRob2MgaXNzdWUgYmFzZWQgb24gSVAgbGF5ZXIuIFRoYXQncyB3 aHkgd2UgYXJlIGhlcmUgaW4KPGJyPiZndDsgNmxvd3BhbiB3ZyBvZiBpZXRmLjxicj4mZ3Q7IDxi cj4mZ3Q7IEJ1dCwgc29tZSBzdGFmZnMgZGVzY3JpYmVkIGluIHlvdXIgbWFpbCBzZWVtIGhlbHBm dWwgZnJvbSB0aGUgNmxvd3Bhbjxicj4mZ3Q7IHBlcnNwZWN0aXZlLCBlc3BlY2lhbGx5IElQdjYg cmVsYXRlZCBzdHVmZnMuIElmIGFsbG93ZWQsIHBsZWFzZSBicmluZzxicj4mZ3Q7IHlvdXIgY29u Y2VybiB0byB0aGUgbmV4dCA2bG93cGFuIGZhY2UtdG8tZmFjZSBtZWV0aW5nIGluIFNhbiBEaWVn by4KPGJyPiZndDsgVGhlbiwgd2Ugd2lsbCBoYXZlIGZ1cnRoZXIgZGV0YWlscyBpbiB0aGVyZSBJ IGJlbGlldmUuLi48YnI+Jmd0OyA8YnI+Jmd0OyAtLSA8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0 OyBEYW5pZWwgKFNvb2hvbmcgRGFuaWVsIFBhcmspPGJyPiZndDsgTW9iaWxlIENvbnZlcmdlbmNl IExhYm9yYXRvcnksIFNBTVNVTkcgRWxlY3Ryb25pY3MuPGJyPiZndDsgPGJyPiZndDsgPGJyPgoK Jmd0OyA8YnI+Jmd0OyBPbiA5LzIxLzA2LCBEYXZpZCBDdWxsZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpkYXZpZC5jdWxsZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJu IHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmRhdmlkLmN1bGxlckBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+Jmd0OyAmZ3Q7IERlYXIgQWxsLDxicj4mZ3Q7ICZndDsK PGJyPiZndDsgJmd0OyBJIHdvdWxkIGxpa2UgdG8gcmFpc2UgYSBjb25jZXJuIGFib3V0IHRoZSBN ZXNoIERlbGl2ZXJ5IEZpZWxkPGJyPiZndDsgJmd0OyBkZWZpbml0aW9uIGluIFNlY3Rpb24gMTEg b2YgdGhlIGZvcm1hdCBkb2N1bWVudC4mbmJzcDsmbmJzcDtXaGlsZSB0aGUgYWN0dWFsPGJyPiZn dDsgJmd0OyBtZXNoIHJvdXRpbmcgcHJvdG9jb2wgaXMgYXBwcm9wcmlhdGVseSBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGUKPGJyPiZndDsgJmd0OyA2bG93cGFuIEZvcm1hdCBkb2N1bWVudCwgdGhh dCBmb3JtYXQgbmVlZHMgcHJvdmlkZSB0aGUgcmF3IHN0cnVjdHVyZTxicj4mZ3Q7ICZndDsgdXBv biB3aGljaCByb3VnaCBjb25zZW5zdXMgYW5kIHJ1bm5pbmcgY29kZSBjYW4gYmUgZmxvdXJpc2gu Jm5ic3A7Jm5ic3A7V2U8YnI+Jmd0OyAmZ3Q7IGtub3cgdGhhdCBsb3cgcG93ZXIgd2lyZWxlc3Mg bWVzaCByb3V0aW5nIGlzIHRlY2huaWNhbGx5IHRyaWNreSBhbmQKPGJyPiZndDsgJmd0OyBzdHJv bmdseSBpbmZsdWVuY2VkIGJ5IHRhcmdldCB0cmFmZmljIGxvYWQsIHBvd2VyIG1hbmFnZW1lbnQg cHJvZmlsZSw8YnI+Jmd0OyAmZ3Q7IG5ldHdvcmsgZGVzaWduLCBhbmQgc28gb24uJm5ic3A7Jm5i c3A7VGh1cywgaXQgaXMgcmVhc29uYWJsZSB0byBleHBlY3QgdGhhdCB0aGU8YnI+Jmd0OyAmZ3Q7 IGNvbnNlbnN1cyBidWlsZGluZyBhbmQgdGVjaG5pY2FsIHJlZmluZW1lbnQgcHJvY2VzcyB3aWxs IHJlcXVpcmUKPGJyPiZndDsgJmd0OyBvbi1nb2luZyBleHBlcmllbmNlIHdpdGggcHJvdG9jb2wg YW5kIGltcGxlbWVudGF0aW9uIGFsdGVybmF0aXZlcy48YnI+Jmd0OyAmZ3Q7IFRoZSA2bG93cGFu IGZvcm1hdCBkb2N1bWVudCBzaG91bGQgc3VwcG9ydCB0aGlzIHByb2Nlc3MsIGFsdGhvdWdoIGl0 PGJyPiZndDsgJmd0OyBzaG91bGQgbm90IGRpY3RhdGUgaXRzIGNvbmNsdXNpb24uPGJyPiZndDsg Jmd0Owo8YnI+Jmd0OyAmZ3Q7IEJhc2VkIG9uIHBhc3QgZXhwZXJpZW5jZSB3aXRoIElQIGxheWVy IDMgcm91dGluZyBhbmQgd2l0aCBwYXN0PGJyPiZndDsgJmd0OyBpbnRlcm5hbGx5IHJvdXRlZCBs aW5rcywgd2UgY2FuIGVzdGFibGlzaCBhIGZldyBwcmltYXJ5IGdvYWxzIGZvciB0aGU8YnI+Jmd0 OyAmZ3Q7IGV4cHJlc3NpdmVuZXNzIG9mIHRoZSA2bG93cGFuIE1lc2ggRGVsaXZlcnkgRmllbGQu Cjxicj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoMSkgSXQgc2hvdWxkIHN1cHBv cnQgdGhlIHZpc2liaWxpdHkgaW50byB0aGUgcm91dGVkIDE1LjQgY2xvdWQ8YnI+Jmd0OyAmZ3Q7 IG5lY2Vzc2FyeSB0byBkZXZlbG9wLCBkZWJ1ZywgZGlhZ25vc2UsIGFuZCBtYW5hZ2UgdGhlIDE1 LjQgY2xvdWQuPGJyPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOygyKSBJdCBzaG91 bGQgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byBkZWZpbmUsIGRldmVsb3AgYW5kIGNvbXBhcmUKPGJy PiZndDsgJmd0OyByb3V0aW5nIHByb3RvY29scyBhbmQgcG9zc2libHkgc3VwcG9ydCB0aGUgcHJl c2VuY2Ugb2YgbXVsdGlwbGU8YnI+Jmd0OyAmZ3Q7IHByb3RvY29scyBmb3Igd2lkZWx5IGRpZmZl cmluZyB1c2FnZSBjYXNlcy48YnI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KDMp IEl0IG5lZWRzIHRvIGJlIHBvc3NpYmxlIGZvciBub2RlcyB0byBjb21tdW5pY2F0ZSB3aXRoIG90 aGVyIG5vZGVzCjxicj4KJmd0OyAmZ3Q7IGluIHRoZSBjbG91ZCBpbiBvcmRlciB0byBkaXNjb3Zl ciBhbmQgbmVnb3RpYXRlIGpvaW5pbmcgdGhlIGNsb3VkPGJyPiZndDsgJmd0OyB3aXRob3V0IGpv aW5pbmcgdGhlIGNsb3VkIGEgcHJpb3JpIHRocm91Z2ggc29tZSBtZWNoYW5pc20gdGhhdCBpczxi cj4mZ3Q7ICZndDsgb3BhcXVlIHRvIElQIGFuZCBhYm92ZS48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsg Jmd0OyAoMSkgaGFzIGhpc3RvcmljYWxseSBiZWVuIGFkZHJlc3NlZCB0aHJvdWdoIHZhcmlvdXMg Zm9ybXMgb2Ygc291cmNlCjxicj4mZ3Q7ICZndDsgcm91dGluZy4mbmJzcDsmbmJzcDtJdCBzaG91 bGQgYmUgcG9zc2libGUgdG8gZG8gdGhlIGVxdWl2YWxlbnQgb2YgdHJhY2Vyb3V0ZTxicj4mZ3Q7 ICZndDsgdGhyb3VnaCB0aGUgMTUuNCBtZXNoIGFuZCB0aGlzIHNob3VsZCBiZSBhY2Nlc3NpYmxl IGluIHNvbWUgZm9ybSB0aHJvdWdoIElQPGJyPiZndDsgJmd0OyBzbzxicj4mZ3Q7ICZndDsgaGln aGVyIGxheWVycyBjYW4gYmUgYnVpbHQgdG8gcGVyZm9ybSB0aGUgbWFuYWdlbWVudC4mbmJzcDsm bmJzcDtUaGUgY3VycmVudAo8YnI+Jmd0OyAmZ3Q7IE1lc2ggRGVsaXZlcnkgRmllbGQgZGVmaW5p dGlvbiBzZWVtcyB0byBwcm9oaWJpdCBhbnkgZm9ybSBvZiBzb3VyY2Ugcm91dGluZy48YnI+Jmd0 OyAmZ3Q7IEl0IGFzc3VtZXMgdGhhdCB0aGUgcm91dGluZyB0YWJsZXMgYXJlIGFsbCBzZXQgdXAg YW5kIGNvcnJlY3Qgc28gdGhhdDxicj4mZ3Q7ICZndDsgdGhlIGZvcndhcmRlciBjYW4gJnF1b3Q7 c3dpenpsZSZxdW90OyB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyBmaWVsZCBvZiB0aGUgCjE1LjQ8 YnI+Jmd0OyAmZ3Q7IGhlYWRlciB3aXRoIGEgdGFibGUgZW50cnkuJm5ic3A7Jm5ic3A7KFRoZSBl eHBlcmllbmNlIG9mIElQIG92ZXIgQVRNIGFuZCB0aGU8YnI+Jmd0OyAmZ3Q7IHRob3VzYW5kcyBv ZiBwYWdlcyBvZiB0aGUgUTgzYiBzaWduYWxsaW5nIHByb3RvY29sIHJlcXVpcmVkIHRvIHNldCB1 cDxicj4mZ3Q7ICZndDsgYWxsIHRoZSB0YWJsZXMgaW4gYWR2YW5jZSBvdWdodCB0byBnaXZlIHVz IGEgbGl0dGxlIHBhdXNlIGhlcmUuKSZuYnNwOyZuYnNwO1RoZQo8YnI+Jmd0OyAmZ3Q7IGlkZWEg b2Ygc3VwcG9ydGluZyB0YWJsZS1kcml2ZW4gcm91dGluZyBhbmQgdGhlcmVieSBzZXBhcmF0aW5n IHRoZTxicj4mZ3Q7ICZndDsgcm91dGUgZm9ybWF0aW9uIGZyb20gdGhlIGZvcndhcmRpbmcgZW5n aW5lIGlzIGEgZ29vZCBvbmUsIGJ1dCB0aGVyZTxicj4mZ3Q7ICZndDsgbmVlZHMgdG8gYmUgZW5v dWdoIGV4cHJlc3NpdmUgcG93ZXIgdG8gc3VwcG9ydCB0aGUgcHJvdG9jb2xzIHRoYXQgd2lsbAo8 YnI+Jmd0OyAmZ3Q7IGVzdGFibGlzaCBhbmQgbWFuYWdlIHRob3NlIHRhYmxlcyAocmF0aGVyIHRo YW4gcmVseWluZyBvbiBhbiBvcGFxdWU8YnI+Jmd0OyAmZ3Q7IG91dC1vZi1iYW5kIHNpZ25hbGlu ZyBtZWNoYW5pc20pIGFuZCB0aGVyZSBuZWVkcyB0byBiZSB0aGUgYWJpbGl0eSB0bzxicj4mZ3Q7 ICZndDsgcXVlcnkgYW5kIHZhbGlkYXRlIHRob3NlIHRhYmxlcyB3aXRob3V0IHJlbHlpbmcgb24g b3V0LW9mLWJhbmQKPGJyPiZndDsgJmd0OyBtZWNoYW5pc21zLjxicj4mZ3Q7ICZndDs8YnI+Jmd0 OyAmZ3Q7ICgyKSBoYXMgaGlzdG9yaWNhbGx5IGJlIGFkZHJlc3NlZCB3aXRoIHByb3RvY29sIGlk ZW50aWZpZXJzIGFuZDxicj4mZ3Q7ICZndDsgb3B0aW9ucy4mbmJzcDsmbmJzcDtBcyB3ZSB3ZW50 IHRocm91Z2ggdGhlIHZhcmlvdXMgUklQLCBPU1BGLCBldGMuIHdlIGRpZG4ndDxicj4mZ3Q7ICZn dDsgbmVlZCB0byBnbyBiYWNrIGFuZCByZWRlZmluZSB0aGUgZm9ybWF0IGRvY3VtZW50cy4mbmJz cDsmbmJzcDtUaGVyZSB3YXMgZW5vdWdoCjxicj4mZ3Q7ICZndDsgZXhwcmVzc2l2ZW5lc3MgZm9y IHRvcG9sb2d5IGZvcm1hdGlvbiBhbmQgcm91dGluZyB0byBldm9sdmUuJm5ic3A7Jm5ic3A7Tm90 IGFsbDxicj4mZ3Q7ICZndDsgbmV0d29ya3MgbmVlZCB0byBzdXBwb3J0IGFsbCBwcm90b2NvbHMu Jm5ic3A7Jm5ic3A7VGhhdCBoYXMgYmVlbiB0aGUgbmV0d29yazxicj4mZ3Q7ICZndDsgZGVzaWdu ZXJzJyBkZXRlcm1pbmF0aW9uLiZuYnNwOyZuYnNwO1RoZSB1bmRlcmx5aW5nIHN0cnVjdHVyZSBw cm92aWRlZCB0aGUKPGJyPiZndDsgJmd0OyBwcmltaXRpdmVzLCBhbGxvd2luZyBzb2x1dGlvbnMg KGFuZCBjb25zZW5zdXMpIHRvIGV2b2x2ZS4mbmJzcDsmbmJzcDtXZSB3YW50IHRvPGJyPiZndDsg Jmd0OyBhdm9pZCBjcmVhdGluZyBhICZxdW90O3dpbm5lciB0YWtlIGFsbCZxdW90OyBzdHJ1Y3R1 cmUgd2hlcmUgdGhlcmUgaXMgbm8gcm9vbTxicj4mZ3Q7ICZndDsgZm9yIGV2b2x1dGlvbiBhbmQg ZGV2ZWxvcG1lbnQuJm5ic3A7Jm5ic3A7SXQgaXMgcG9zc2libGUgdGhhdCBBT0RWLCBvciBUaW55 QU9EViwKPGJyPiZndDsgJmd0OyBvciBEU1IsIG9yIEdQU1Igb3IgcG9zc2libHkgb25lIG9mIHNl dmVyYWwgb3RoZXIgYWx0ZXJuYXRpdmVzIGlzIHRoZSByaWdodDxicj4mZ3Q7ICZndDsgc29sdXRp b24uJm5ic3A7Jm5ic3A7SG93ZXZlciwgdGhlcmUgaXMgbGl0dGxlIGV2aWRlbmNlIG9mIG9uZSBo YXZpbmcgY2xlYXIgc3VwZXJpb3JpdHk8YnI+Jmd0OyAmZ3Q7IGF0PGJyPiZndDsgJmd0OyB0aGlz IHRpbWUsIGRlc3BpdGUgbnVtZXJvdXMgaGlnaCBwcm9maWxlIGVmZm9ydHMuJm5ic3A7Jm5ic3A7 V2Ugc2hvdWxkIGJlIGRlZmluaW5nIHRoZQo8YnI+Jmd0OyAmZ3Q7IGNhbnZhcyB1cG9uIHdoaWNo IGNvbXBldGluZyBhbHRlcm5hdGl2ZXMgY2FuIGJlIGRlZmluZWQgYW5kIHZldHRlZC48YnI+Jmd0 OyAmZ3Q7PGJyPiZndDsgJmd0OyAoMykgaGFzIGhpc3RvcmljYWxseSBiZWVuIGFkZHJlc3NlZCBi eSBhIGxpbWl0ZWQgYWJpbGl0eSB0bzxicj4mZ3Q7ICZndDsgY29tbXVuaWNhdGUgb24gdGhlIGxp bmsgdG8gYSBjcnVkZWx5IGRlZmluZWQgc2V0IG9mIG5vZGVzIGluIG9yZGVyIHRvCjxicj4mZ3Q7 ICZndDsgYm9vdHN0cmFwIHRoZSBkaXNjb3ZlcnksIGpvaW4sIGFkZHJlc3MgYXNzaWdubWVudCwg bmVnb3RpYXRpb24sIGV0Yy48YnI+Jmd0OyAmZ3Q7IE1vc3Qgc3VjY2Vzc2Z1bCBsaW5rcyB1bmRl ciBJUCBsb29rIGVpdGhlciBsaWtlIGEgYnJvYWRjYXN0IG1lZGl1bSBvcjxicj4mZ3Q7ICZndDsg YSBwb2ludC10by1wb2ludCBsaW5rIChhIGRlZ2VuZXJhdGl2ZSBicm9hZGNhc3QpLiZuYnNwOyZu YnNwO1RoaXMgYWxsb3dzIEFSUCwKPGJyPiZndDsgJmd0OyBSQVJQLCBCT09UUCwgREhDUCwgZXRj LiB0byBnYWluIGhpZ2hlciBsZXZlbCBhY2Nlc3NpYmlsaXR5IGFuZDxicj4mZ3Q7ICZndDsgYWRk cmVzc2liaWxpdHkgdGhyb3VnaCB0aGUgbGluay4mbmJzcDsmbmJzcDtMaW5rcyB0aGF0IHJlcXVp cmUgY29tcGxleDxicj4mZ3Q7ICZndDsgc2lnbmFsaW5nLCBkaXNjb3ZlcnksIGpvaW5pbmcgYW5k IGNvb3JkbmF0aW9uIGJlbG93IHRoZSBsaW5rIGxheWVyLAo8YnI+Jmd0OyAmZ3Q7IGluY2x1ZGlu ZyBBVE0sIEJsdWV0b290aCAocGljb25ldHMgYW5kIHNjYXR0ZXIgbmV0cyksIGFuZCBJUkRBIGhh dmU8YnI+Jmd0OyAmZ3Q7IHByb3ZlZCBvbmVyb3VzIGZvciBJUCBhbmQgaGF2ZSBiZWVuIHJlbGVn YXRlZCB0byBmYXIgbGVzcyBnZW5lcmFsPGJyPiZndDsgJmd0OyB1c2FnZSBzY2VuYXJpb3MgLSBz dWNoIGFzIHRoZSBkZXNrdG9wIFVTQiByZXBsYWNlbWVudC4mbmJzcDsmbmJzcDtFdmVuIHRob3Vn aAo8YnI+Jmd0OyAmZ3Q7IHRoZSByYWRpbyBpcyBhIGJyb2FkY2FzdCBtZWRpdW0sIHRoZSBjaGFs bGVuZ2UgaW4gYSByb3V0ZWQgbGluayBpczxicj4mZ3Q7ICZndDsgdGhhdCB0aGUgbGluayBpcyBu b3QgYnkgZGVmYXVsdCBhIGxpbmstd2lkZSBicm9hZGNhc3QgcGh5LiZuYnNwOyZuYnNwO1RoZXJl PGJyPiZndDsgJmd0OyBhcmUgdHdvIG5hdHVyYWwgbm90aW9ucyBvZiAmcXVvdDticm9hZGNhc3Qm cXVvdDsgaW4gYSBsb3dwYW4uJm5ic3A7Jm5ic3A7KGkpIFRoZSBwaHlzaWNhbAo8YnI+Jmd0OyAm Z3Q7IG5laWdoYm9ycyB0aGF0IGhhcHBlbiB0byByZWNlaXZlIGEgdHJhbnNtaXNzaW9uIGJlY2F1 c2UgdGhleSBhcmUgY2xvc2U8YnI+Jmd0OyAmZ3Q7IGVub3VnaCB0byBwaWNrIHVwIHRoZSBzaWdu YWwgYW5kIGhhdmUgdGhlaXIgcmFkaW9zIHR1cm5lZCBvbiB0bzxicj4mZ3Q7ICZndDsgcmVjZWl2 ZS4mbmJzcDsmbmJzcDsoaWkpIFRoZSBlbnRpcmUgY29sbGVjdGlvbiBvZiBub2RlcyB0aGF0IGNh biBiZSByZWFjaGVkIGJ5IGEKPGJyPiZndDsgJmd0OyBtdWx0aWhvcCBkaXNzZW1pbmF0aW9uIChm bG9vZCkuJm5ic3A7Jm5ic3A7Qm90aCBvZiB0aGVzZSBhcmUgZXh0cmVtZWx5IHVzZWZ1bCBpbjxi cj4mZ3Q7ICZndDsgYm9vdHN0cmFwcGluZyBoaWdoZXIgbGV2ZWxzLCBpbmNsdWRpbmcgcm91dGlu ZywgYW5kIHNob3VsZCBiZTxicj4mZ3Q7ICZndDsgYWRkcmVzc2VkIGluIHRoZSBmb3JtYXQgZG9j dW1lbnQuJm5ic3A7Jm5ic3A7QWRkaXRpb25hbGx5LCBpdCBpcyBub3QKPGJyPiZndDsgJmd0OyBu ZWNjZXNzYXJ5IHRvIHVzZSB0aGUgODAyLjE1LjQgYmVhY29uaW5nIG1lY2hhbmlzbSB0byBicmlu ZyB1cCBJUCBvdmVyPGJyPiZndDsgJmd0OyBhIDE1LjQgbGluay4mbmJzcDsmbmJzcDtQcm92aWRp bmcgc29tZSBmb3JtcyBvZiBicm9hZGNhc3QgdXNpbmcgZGF0YSBmcmFtZXM8YnI+Jmd0OyAmZ3Q7 IG1ha2VzIHRoZSA4MDIuMTUuNCBmb3JtYXQgbXVjaCBtb3JlIGxpa2UgODAyLjExCgogYW5kIG90 aGVyIGxpbmtzIHRoYXQ8YnI+Jmd0OyAmZ3Q7IGhhdmUgcHJvdmVkIHZlcnkgc3VpdGFibGUgZm9y IElQLiZuYnNwOyZuYnNwO0ZldywgaWYgYW55LCBvZiB0aGUgcHVibGljIDE1LjQgcm91dGluZzxi cj4mZ3Q7ICZndDsgbGF5ZXJzIGRldmVsb3BlZDxicj4mZ3Q7ICZndDsgYnkgdGhlIFRpbnlPUyBj b21tdW5pdHkgdXRpbGl6ZSBiZWFjb24gcGFja2V0cy48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0 OyBUaGUgcmVjb2duaXRpb24gdGhhdCB0aGUgY3VycmVudCBNZXNoIERlbGl2ZXJ5IGZpZWxkIG1h eSBiZSB0byByZXN0cmljdGl2ZQo8YnI+Jmd0OyAmZ3Q7IGlzIGludGltYXRlZCBieSB0aGUgbmVl ZCB0byBkZWZpbmUgYSBzZWNvbmQgZm9ybSBvZiB0aGUgaGVhZGVyIGZvcjxicj4mZ3Q7ICZndDsg bXVsdGljYXN0IChhbmQgbGluayBsb2NhbCBicm9hZGNhc3QpIHRoYXQgaW5jbHVkZXMgYSBzZXF1 ZW5jZSBudW1iZXIuPGJyPiZndDsgJmd0OyBUaGUgbWVzaCBoZWFkZXIgZmllbGQgdHlwZSBpcyBk ZWZpbmVkIGJ5IHdoZXRoZXIgdGhlIGRlc3RpbmF0aW9uCjxicj4mZ3Q7ICZndDsgYWRkcmVzcyBp cyB1bmljYXN0IG9yIG11bHRpY2FzdC4gVGhlIGRvY3VtZW50IHN0YXRlcyB0aGF0IHRoZSB1c2Ug b2Y8YnI+Jmd0OyAmZ3Q7IHN1Y2ggYSBzZXF1ZW5jZSBudW1iZXIgaXMgb3V0IG9mIHNjb3BlLiBI b3dldmVyLCB0aGUgb2JzZXJ2YXRpb24gdGhhdDxicj4mZ3Q7ICZndDsgdGhhdCBleHRyYSBpbmZv cm1hdGlvbiBtYXkgbmVlZCB0byBiZSBpbmNsdWRlZCBkZXBlbmRpbmcgb24gaG93Cjxicj4mZ3Q7 ICZndDsgcGFja2V0cyBhcmUgcm91dGVkIGZ1cnRoZXIgc3VnZ2VzdHMgdGhhdCBtb3JlIGNhcmVm dWwgZm9ybWF0PGJyPiZndDsgJmd0OyBkZWZpbml0aW9uIGlzIG5lZWRlZCB0byBzdXBwb3J0IGZ1 dHVyZSBkZXZlbG9wbWVudCBvZiBtZXNoIHJvdXRpbmcuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZn dDsgSGF2ZSBmb2xrcyB3aG8gaGF2ZSBiZWVuIGRldmVsb3BpbmcgbWVzaCBsYXllcnMgZm9yIGxv d3BhbjYgZmVsdCB0aGF0Cjxicj4mZ3Q7ICZndDsgdGhlIGV4aXN0aW5nIE1lc2ggRGVsaXZlcnkg RmllbGQgaXMgdG9vIHJlc3RyaWN0aXZlPzxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZn dDsgJmd0OyBEYXZpZCBFLiBDdWxsZXI8YnI+Jmd0OyAmZ3Q7IFVDIEJlcmtlbGV5PGJyPiZndDsg Jmd0OyA8YSBocmVmPSJtYWlsdG86Y3VsbGVyQGNzLmJlcmtlbGV5LmVkdSIgdGFyZ2V0PSJfYmxh bmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp Ij4KCmN1bGxlckBjcy5iZXJrZWxleS5lZHU8L2E+PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8 YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyAmZ3Q7IDZsb3dwYW4gbWFpbGlu ZyBsaXN0PGJyPiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86Nmxvd3BhbkBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2 ZW50LHRoaXMpIj4KCjZsb3dwYW5AaWV0Zi5vcmc8L2E+PGJyPiZndDsgJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuIiB0YXJnZXQ9Il9i bGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhp cykiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW48L2E+PGJy PiZndDsgJmd0Owo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7IDxicj4mZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgNmxv d3BhbiBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyA8YSBocmVmPSJtYWlsdG86Nmxvd3BhbkBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIj4KCjZsb3dwYW5AaWV0Zi5vcmc8L2E+PGJyPiZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3BhbiIgdGFyZ2V0PSJf YmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRo aXMpIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuPC9hPjxi cj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cjxicj42bG93cGFuIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86Nmxvd3BhbkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmso d2luZG93LGV2ZW50LHRoaXMpIj42bG93cGFuQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuIiB0YXJnZXQ9Il9ibGFu ayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcyki PgoKaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3BhbjwvYT48L2Rp dj48L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogdGltZXMg bmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmOyI+PGJyPiZuYnNwOzwvZGl2Pjwvc3Bhbj48 L2Rpdj48L2Rpdj48L2Rpdj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+Nmxvd3BhbiBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOjZs b3dwYW5AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9w ZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+Cgo2bG93cGFuQGlldGYub3JnPC9hPjxicj48 YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuIiB0 YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3cs ZXZlbnQsdGhpcykiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dw YW48L2E+PGJyPjxicj48YnI+PC9ibG9ja3F1b3RlPgoKPC9kaXY+PGJyPjxiciBjbGVhcj0iYWxs Ij48YnI+PC9zcGFuPjwvZGl2PjxzcGFuIGNsYXNzPSJzZyI+LS0gPGJyPktpLUh5dW5nIEtpbSAo seix4sf8LCDQ3dHD+vspPGJyPkFzc29jaWF0ZSBQcm9mZXNzb3I8YnI+RGl2aXNpb24gb2YgSW5m b3JtYXRpb24gYW5kIENvbXB1dGVyIEVuZy4sIEFqb3UgVW5pdmVyc2l0eSwgU3V3b24sIEtvcmVh IDQ0Mi03NDk8YnI+VGVsOiArODItMzEtMjE5LTI0MzMsIENlbDogKzgyLTE3LTc2MC0yNTUxLCZu YnNwOyZuYnNwO0ZheDogKzgyLTMxLTIxOS0yNDMzIAo8YSBocmVmPSJodHRwOi8vd3d3LjZsb3dw YW4ub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGlu ayh3aW5kb3csZXZlbnQsdGhpcykiPmh0dHA6Ly93d3cuNmxvd3Bhbi5vcmc8L2E+IAo8L3NwYW4+ PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5EYXZpZCBF LiBDdWxsZXI8YnI+QXJjaGVkIFJvY2sgQ29ycG9yYXRpb248YnI+MjE2OCBTaGF0dHVjayBBdmU8 YnI+QmVya2VsZXksIENBIDk0NzA0PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuYXJjaGVkcm9jay5j b20iPnd3dy5hcmNoZWRyb2NrLmNvbTwvYT4K ------=_Part_12049_2288102.1159544336033-- --===============0676030912== 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 --===============0676030912==-- From 6lowpan-bounces@ietf.org Fri Sep 29 17:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTPhx-0000Jb-5k; Fri, 29 Sep 2006 17:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTPhv-0000JW-F7 for 6lowpan@ietf.org; Fri, 29 Sep 2006 17:15:43 -0400 Received: from web81905.mail.mud.yahoo.com ([68.142.207.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GTPhu-00065l-0U for 6lowpan@ietf.org; Fri, 29 Sep 2006 17:15:43 -0400 Received: (qmail 65607 invoked by uid 60001); 29 Sep 2006 21:15:41 -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:MIME-Version:Content-Type; b=UepKdgWvC/ymR44G9hE09vsjLOErscx7ssSAL51ixwW28c7maoKji2nTEU8MQRZDdNoDP6RxlMlsMFKhmbN3+YVWzxaWnXeVcdBvoB+l1DKAhOyuTWNQJpGkaxvhtAxenSVpfCtHatCVSer/SRuPROretYC4GFIxpLky7Q0s3Z8= ; Message-ID: <20060929211541.65605.qmail@web81905.mail.mud.yahoo.com> Received: from [24.16.14.130] by web81905.mail.mud.yahoo.com via HTTP; Fri, 29 Sep 2006 14:15:41 PDT Date: Fri, 29 Sep 2006 14:15:41 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Mesh Delivery Field To: David Culler , Ki-Hyung Kim MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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="===============1047760726==" Errors-To: 6lowpan-bounces@ietf.org --===============1047760726== Content-Type: multipart/alternative; boundary="0-1342563366-1159564541=:64886" --0-1342563366-1159564541=:64886 Content-Type: text/plain; charset=us-ascii [Re-sending after eliding all the thread due to size limitations on the 6lowpan alias.] Ok, it seems like folks would like to have more flexibility in the header. I'm just having a hard time translating that to actual bits and bytes within the header formats, and how much flexibility is fine. The first packet format has 5 bits of reserved 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: LoWPAN unfragmented encapsulation header format One bit out of that reserved field is what Mario Mao suggests we use to distinguish between the two current flavors of mesh delivery header (unicast vs bcast/mcast). Is this sufficient flexibility? The issue is that there is no such flexibility in the two other header formats, but we can certainly add such a reserved field and make all 3 header formats the same up to the first 16 bits. Perhaps along these lines (notice the new "reserved" field and the corresponding 5 bit shift for datagram_size and datagram_tag) : 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|reserved | datagram_size |dgram_tag| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |dgram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: LoWPAN first fragment encapsulation header format 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|reserved | datagram_size |dgram_tag| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |dgram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: LoWPAN subsequent fragment(s) encapsulation header format Would this be enough? If not, how many bits should be allocated? Should there be a version field in addition (as suggested by Vipul a while back)? What changes in the format are suggested? Folks, please be specific as to the suggested changes by sending header formats with clearly proposed fields, etc. tnx, -gabriel --0-1342563366-1159564541=:64886 Content-Type: text/html; charset=us-ascii
[Re-sending after eliding all the thread due to size limitations on the 6lowpan alias.]
 
Ok, it seems like folks would like to have more flexibility in the header. I'm just having a hard time translating that
to actual bits and bytes within the header formats, and how much flexibility is fine.
 
The first packet format has 5 bits of reserved 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | LF|  prot_type    |M| rsv     |Payload (or Mesh Delivery Hdr)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 1: LoWPAN unfragmented encapsulation header format
One bit out of that reserved field is what Mario Mao suggests we use to distinguish between the two current flavors
of mesh delivery header (unicast vs bcast/mcast). Is this sufficient flexibility?
 
The issue is that there is no such flexibility in the two other header formats, but we can certainly add such a
reserved field and make all 3 header formats the same up to the first 16 bits. Perhaps along these lines
(notice the new "reserved" field and the corresponding 5 bit shift for datagram_size and datagram_tag) :
 
                           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|reserved |   datagram_size     |dgram_tag|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |dgram_tag| Payload (or Mesh Delivery Hdr)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
        Figure 2: LoWPAN first fragment encapsulation header format
 
                           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|reserved |   datagram_size     |dgram_tag|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |dgram_tag| Payload (or Mesh Delivery Hdr)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 3: LoWPAN subsequent fragment(s) encapsulation header format
 
 
Would this be enough? If not, how many bits should be allocated? Should there be a version field in addition
(as suggested by Vipul a while back)? What changes in the format are suggested? Folks, please be specific
as to the suggested changes by sending header formats with clearly proposed fields, etc.
 
tnx,
 
-gabriel
--0-1342563366-1159564541=:64886-- --===============1047760726== 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 --===============1047760726==-- From 6lowpan-bounces@ietf.org Sat Sep 30 03:07:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTYwP-0002VB-Eu; Sat, 30 Sep 2006 03:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTYwN-0002UU-SI for 6lowpan@ietf.org; Sat, 30 Sep 2006 03:07:15 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTYwN-0004qA-AB for 6lowpan@ietf.org; Sat, 30 Sep 2006 03:07:15 -0400 Received: by py-out-1112.google.com with SMTP id w49so507853pyg for <6lowpan@ietf.org>; Sat, 30 Sep 2006 00:07:15 -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=bBtD3wlliy4X1RFSq4NA8wJ5pXOqp+IZirbjZMfXd3IT2JZ0zX6sjSDaVIxyOArjKNP+0TWsdYjegDV36e3tUm81Nz61qZ27bvdifQDkJGJCm2ohwkrU04nPS1tOJVJzwdV/HYkHw5cQ4AX9ADD0xCKgTdz0lzf6Rn0J4Ut1cE8= Received: by 10.35.111.7 with SMTP id o7mr2185139pym; Sat, 30 Sep 2006 00:07:14 -0700 (PDT) Received: from Maoer ( [211.144.102.60]) by mx.gmail.com with ESMTP id 12sm1083388nzn.2006.09.30.00.07.11; Sat, 30 Sep 2006 00:07:14 -0700 (PDT) Message-ID: <006c01c6e45f$22adf650$7fc0a8c0@netlab.cs.ecnu.edu.cn> To: "gabriel montenegro" , "Ki-Hyung Kim" References: <20060930021650.49281.qmail@web81913.mail.mud.yahoo.com> Subject: Re: [6lowpan] Mesh Delivery Field Date: Sat, 30 Sep 2006 15:07: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.1 (+) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: 6lowpan@ietf.org, David Culler X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1343536155==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1343536155== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01C6E4A2.28849410" This is a multi-part message in MIME format. ------=_NextPart_000_0069_01C6E4A2.28849410 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2FicmllbCwNCg0KVGhhbmtzIGZvciB5b3UgZmVlZGJhY2suDQoNCkFzIEkgbWVudGlvbmVk IGJlZm9yZSwgdGhlIHdheSB0byBjb21iaW5pbmcgdGhlIFRyYWZmaWMgQ2xhc3MgYW5kIEZsb3cg TGFiZWwgd2l0aCBWZXJzaW9uIGZpZWxkIGp1c3QgaXMgYSB3b3JrYXJvdW5kIHdlIHVzZWQgdGVt cG9yYXJpbHkuIEFsc28sIHRoZSBzYW1lIG1ldGhvZCBpcyB1c2VkIHRvIHNvbHZlIHRoZSBVRFAg Y29tcHJlc3Npb24gYWxpZ25tZW50IHByb2JsZW0sIHRoYXQgaXMsIG9ubHkgY29tcHJlc3MgdGhl IHBvcnQgZmllbGQgd2hlbiBib3RoIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gcG9ydHMgY291bGQg YmUgY29tcHJlc3NlZC4NCg0KQ2xlYXJseSwgbXkgd29ya2Fyb3VuZCBpcyBzb21ld2hhdCB1Z2x5 IGFuZCBub3QgcmVhc29uYWJsZSwgYnV0IGl0IGRvIG1ha2UgdGhlIGltcGxlbWVudGF0aW9uIG1v cmUgZWFzaWx5LiBJbiBmYWN0LCB3ZSBkbyB3YWl0IGZvciBuZXcgZHJhZnQgdG8gY2xhcmlmeSB0 aGlzIGFsaWdubWVudCBwcm9ibGVtLiBGb3IgcGVyc29uYWwgb3BpbmlvbiwgaXQgaXMgYSBnb29k IGlkZWEgdG8gcGFkIGJpdHMgdGlsbCBhbGwgY29tcHJlc3Npb24gZmluaW5zaGVkLiBIb3dldmVy LCBJIHRoaW5rIHdlIHNob3VsZCBwYXkgY2F1dGlvbiB0byB0aGUgZmFjaWxpdHkgZm9yIGltcGxl bWVudGF0aW9uLiBJIGhvcGUgd2UgY2FuIGdldCBjb25jbHVzaW9uIGluIHRoZSBuZXh0IHZlcnNp b24sIHRoYW5rcy4NCg0KQmVzdCBSZWdhcmRzLA0KDQpNYXJpbyBNYW8NCiAgLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogZ2FicmllbCBtb250ZW5lZ3JvIA0KICBUbzogS2kt SHl1bmcgS2ltIA0KICBDYzogRGF2aWQgQ3VsbGVyIDsgR2VvZmYgTXVsbGlnYW4gOyBTb29ob25n IERhbmllbCBQYXJrIDsgNmxvd3BhbkBpZXRmLm9yZyA7IE1hcmlvIE1hbyANCiAgU2VudDogU2F0 dXJkYXksIFNlcHRlbWJlciAzMCwgMjAwNiAxMDoxNiBBTQ0KICBTdWJqZWN0OiBSZTogWzZsb3dw YW5dIE1lc2ggRGVsaXZlcnkgRmllbGQNCg0KDQogIEtpLUh5dW5nLA0KDQogIFlvdSBhc2tlZDog IlNvLCB3aGF0IGlzIGZpbmFsIGxvb2sgb2YgdGhlIG1lc2ggZGVsaXZlcnkgZmllbGQ/Ig0KDQog IEFzIHBlciBNYXJpbydzIHN1Z2dlc3Rpb24sIHdlJ2QgdXNlIG9uZSBvZiB0aGUgNSByZXNlcnZl ZCBiaXRzIHRvIHNpZ25hbCBpZiB0aGUNCiAgYmNhc3QvbWNhc3QgbWVzaCBkZWxpdmVyeSBmb3Jt YXQgaXMgYmVpbmcgdXNlZCwgYW5kIHdlJ2QgY2FsbCBpdCB0aGUgJ0InIGJpdC4NCiAgU28gbm8g Y2hhbmdlIHRvIHRoZSBtZXNoIGRlbGl2ZXJ5IGZpZWxkcyBpcyByZXF1aXJlZC4gU2luY2UgdGhl IHJlc2VydmVkIGJpdHMNCiAgYXJlIGNvbW1vbiB0byBhbGwgdGhyZWUgbG93cGFuIGhlYWRlciBm b3JtYXRzLCB0aGUgJ0InIGJpdCB3b3VsZCBhcHBseSB0byBhbGwNCiAgdGhyZWUuIA0KDQogIE1h cmlvIGFsc28gaGFkIGEgY29tbWVudCBvbiBob3cgdGhlIGhlYWRlciBjb21wcmVzc2lvbiBmb3Jj ZXMgYWxpZ25tZW50IHRvIG5vdA0KICBmYWxsIG9uIG9jdGV0IGJvdW5kYXJpZXM6DQogICAgQXQg bGFzdCwgSSBmaW5kIHNvbWUgcHJvYmxlbSB3aGVuIGltcGxpbWVudCBJUHY2IGhlYWRlciBjb21w cmVzc2lvbi4gUGxlYXNlIG5vdGUgVHJhZmZpYyBDbGFzcyBhbmQgRmxvdyBMYWJlbCBiaXQgaW4g SEMxLiBJZiB3ZSBkb24ndCBjb21wcmVzcyB0aGUgdHdvIGZpZWxkLCAyOCBiaXRzICh0aGF0IGlz IHRocmVlIGFuZCBoYWxmIGJ5dGVzKSBhcmUgc2VudC4gSG93ZXZlciwgaG93IHRvIHNlbmQgdGhl IGhhbGYgYnl0ZT8gQXMgSSBrbm93LCBtb3N0IGhhcmR3YXJlIGNvdWxkIG9ubHkgdHJhbnNtaXQg ZGF0YSBpbiB1bml0IG9mIEJZVEUuIFNob3VsZCB3ZSBuZWVkIDQgYml0cyBwZW5kaW5nIGRhdGE/ IFRoZSB3b3JrZGFyb3VuZCB3ZSB1c2VkIGlzIGNvbWJpbmluZyB0aGUgVHJhZmZpYyBDbGFzcyBh bmQgRmxvdyBMYWJlbCB3aXRoIFZlcnNpb24gZmllbGQuIFNvLCB0aGUgVHJhZmZpYyBDbGFzcyBh bmQgRmxvdyBMYWJlbCBiaXQgYmVjb21lcyBWZXJzaW9uLCBUcmFmZmljIENsYXNzIGFuZCBGbG93 IExhYmVsIGJpdC4gUGxlYXNlIHNlZSBmb2xsb3dpbmcgYXMgZGV0YWlsLg0KDQogICAgVmVyc2lv biwgVHJhZmZpYyBDbGFzcyBhbmQgRmxvdyBMYWJlbCAoYml0IDQpOg0KICAgIDA6IG5vdCBjb21w cmVzc2VkLCBmdWxsIDQgYml0cyBmb3IgVmVyc2lvbiwgOCBiaXRzIGZvciBUcmFmZmljIENsYXNz IGFuZCAyMCBiaXRzIGZvciBGbG93IExhYmVsIGFyZSBzZW50DQogICAgMTogVHJhZmZpYyBDbGFz cyBhbmQgRmxvdyBMYWJlbCBhcmUgemVybw0KICBXaGF0IGRvIHBlb3BsZSB0aGluayBvZiB0aGF0 PyBJJ2QgcmF0aGVyIG5vdCBkbyB0aGF0IGJlY2F1c2UNCg0KICAgICAxLiB3aHkgc2VuZCBhIHZl cnNpb24gZmllbGQgaWYgdGhlIHZlcnNpb24gaXMgYWxyZWFkeSBrbm93biAoaS5lLiwgSVB2Nik/ DQogICAgIDIuIHRoaXMgb25seSBmaXhlcyB0aGUgYWxpZ25tZW50IGFzIGZhciBhcyB0aGUgSVB2 NiBoZWFkZXIgaXMgY29uY2VybmVkLCBidXQNCiAgICAgICAgdGhlcmUgYXJlIG1vcmUgaGVhZGVy cyBwcm9iYWJseSBmb2xsb3dpbmcsIGFuZCB0aG9zZSBjb3VsZCBhbHNvIGhhdmUgDQogICAgICAg IGFsaWdubWVudCBpc3N1ZXMuDQoNCiAgRm9yIGV4YW1wbGUsIHdlIGFsc28gaGF2ZSBhbiBpc3N1 ZSB3aXRoIFVEUCBoZWFkZXIgY29tcHJlc3Npb24gKHRoZSBvbmx5DQogIGhlYWRlciBjb21wcmVz c2lvbiBzY2hlbWUgY3VycmVudGx5IGRlZmluZWQgaW4gYWRkaXRpb24gdG8gSVB2NiBoZWFkZXIp Og0KDQogICAgICAgIFVEUCBzb3VyY2UgcG9ydCAoYml0IDApOg0KICAgICAgICAgICAwOiBOb3Qg Y29tcHJlc3NlZCwgY2FycmllZCAiaW4tbGluZSIgKFNlY3Rpb24gMTAuMy4yKQ0KICAgICAgICAg ICAxOiBDb21wcmVzc2VkIHRvIDQgYml0cy4gIFRoZSBhY3R1YWwgMTYtYml0IHNvdXJjZSBwb3J0 IGlzDQogICAgICAgICAgICAgIG9idGFpbmVkIGJ5IGNhbGN1bGF0aW5nOiBQICsgc2hvcnRfcG9y dCB2YWx1ZS4gIFAgaXMgYQ0KICAgICAgICAgICAgICBwcmVkZXRlcm1pbmVkIHBvcnQgbnVtYmVy IHdpdGggdmFsdWUgVEJELiAgVGhlIHNob3J0X3BvcnQgaXMNCiAgICAgICAgICAgICAgZXhwcmVz c2VkIGFzIGEgNC1iaXQgdmFsdWUgd2hpY2ggaXMgY2FycmllZCAiaW4tbGluZSINCiAgICAgICAg ICAgICAgKFNlY3Rpb24gMTAuMy4yKQ0KDQogICAgICAgIFVEUCBkZXN0aW5hdGlvbiBwb3J0IChi aXQgMSk6DQogICAgICAgICAgIDA6IE5vdCBjb21wcmVzc2VkLCBjYXJyaWVkICJpbi1saW5lIiAo U2VjdGlvbiAxMC4zLjIpDQogICAgICAgICAgIDE6IENvbXByZXNzZWQgdG8gNCBiaXRzLiAgVGhl IGFjdHVhbCAxNi1iaXQgZGVzdGluYXRpb24gcG9ydCBpcw0KICAgICAgICAgICAgICBvYnRhaW5l ZCBieSBjYWxjdWxhdGluZzogUCArIHNob3J0X3BvcnQgdmFsdWUuICBQIGlzIGENCiAgICAgICAg ICAgICAgcHJlZGV0ZXJtaW5lZCBwb3J0IG51bWJlciB3aXRoIHZhbHVlIFRCRC4gIFRoZSBzaG9y dF9wb3J0IGlzDQogICAgICAgICAgICAgIGV4cHJlc3NlZCBhcyBhIDQtYml0IHZhbHVlIHdoaWNo IGlzIGNhcnJpZWQgImluLWxpbmUiDQogICAgICAgICAgICAgIChTZWN0aW9uIDEwLjMuMikNCg0K DQogIEJlY2F1c2Ugb2YgdGhlIGFib3ZlLCBpdCBzZWVtcyBxdWl0ZSBwb3NzaWJsZSB0aGF0IG9u ZSB3b3VsZCBlbmQgdXAgd2l0aCA0IGJpdHMNCiAgZm9yIGVpdGhlciB0aGUgVURQIHNvdXJjZSBv ciBkZXN0aW5hdGlvbi4gSW4gc3VjaCBhIGNhc2UsIHRoZSBtaXNhbGlnbm1lbnQgaW4gdGhlDQog IElQdjYgaGVhZGVyIGNvdWxkIGJlIG9mZnNldCBieSB0aGUgbWlzYWxpZ25tZW50IGluIHRoZSBV RFAgaGVhZGVyIGNvbXByZXNzaW9uLCANCiAgYW5kIHdlJ2QgZW5kIHVwIGFsaWduZWQgb24gYW4g b2N0ZXQgYm91bmRhcnkuIE9mIGNvdXJzZSwgaWYgb25lIHVzZXMgdGhlIGZ1bmt5DQogIDQtYml0 IHBvcnQgY29tcHJlc3Npb24gZm9yIGJvdGggc291cmNlIGFuZCBkZXN0aW5hdGlvbiB0aGVuIG9u ZSB3b3VsZG4ndCBvZmZzZXQNCiAgdGhlIHByZXZpb3VzIG1pc2FsaWdubWVudC4gTm8gd2F5IHRv IGtub3csIHNvIHBlcmhhcHMgb25lIHNob3VsZCB3YWl0IHVudGlsIHRoZQ0KICBlbnRpcmUgaGVh ZGVyIGlzIGxhaWQgb3V0IHRvIGZpZ3VyZSBvdXQgaWYgYW55IHBhZGRpbmcgd2l0aCB6ZXJvIGJp dHMgaXMgdG8NCiAgYmUgZG9uZS4NCg0KICBTbyBwZXJoYXBzIHdoYXQgd2UgY2FuIGRvIGlzIHRv IGFkZCB0ZXh0IHRvIHRoZSBlZmZlY3QgdGhhdCBvbmUgcGFja3MgdGhlIGVudGlyZQ0KICBoZWFk ZXIgYW5kIHRoZW4gcGFkcyBhcyBhcHByb3ByaWF0ZSB0byBhbGlnbiB0byBhbiBvY3RldCBib3Vu ZGFyeS4gRG9lcyB0aGlzIA0KICBzb3VuZCByZWFzb25hYmxlPw0KDQogIHRoYW5rcyBmb3IgYW55 IGNvbW1lbnRzLA0KDQogIC1nYWJyaWVs ------=_NextPart_000_0069_01C6E4A2.28849410 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxTVFlMRSB0eXBlPXRleHQvY3NzPkRJ ViB7DQoJTUFSR0lOOiAwcHgNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI4MDAuMTU2MSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZm ZmZmPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SGkgR2FicmllbCw8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+VGhhbmtzIGZvciB5b3UgZmVlZGJhY2su PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFzIEkgbWVudGlvbmVkIGJlZm9y ZSwgdGhlIHdheSB0byBjb21iaW5pbmcgdGhlIA0KVHJhZmZpYyBDbGFzcyBhbmQgRmxvdyBMYWJl bCB3aXRoIFZlcnNpb24gZmllbGQganVzdCBpcyBhIHdvcmthcm91bmQgd2UgdXNlZCANCnRlbXBv cmFyaWx5LiBBbHNvLCB0aGUmbmJzcDtzYW1lIG1ldGhvZCBpcyB1c2VkIHRvIHNvbHZlIHRoZSBV RFAgDQpjb21wcmVzc2lvbiZuYnNwO2FsaWdubWVudCZuYnNwO3Byb2JsZW0sIHRoYXQgaXMsIG9u bHkgY29tcHJlc3MgdGhlIHBvcnQgZmllbGQgDQp3aGVuIGJvdGgmbmJzcDtzb3VyY2UgYW5kIGRl c3RpbmF0aW9uIHBvcnRzIGNvdWxkIGJlIGNvbXByZXNzZWQuPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPkNsZWFybHksIG15IHdvcmthcm91bmQgaXMgc29tZXdoYXQgdWdseSBh bmQgbm90IA0KcmVhc29uYWJsZSwgYnV0IGl0IGRvIG1ha2UgdGhlIGltcGxlbWVudGF0aW9uIG1v cmUgZWFzaWx5LiBJbiBmYWN0LCB3ZSBkbyB3YWl0IA0KZm9yIG5ldyBkcmFmdCB0byBjbGFyaWZ5 IHRoaXMgYWxpZ25tZW50IHByb2JsZW0uIEZvciBwZXJzb25hbCBvcGluaW9uLCBpdCBpcyBhIA0K Z29vZCBpZGVhIHRvIHBhZCBiaXRzIHRpbGwgYWxsIGNvbXByZXNzaW9uIGZpbmluc2hlZC4gSG93 ZXZlciwgSSB0aGluayB3ZSBzaG91bGQgDQpwYXkgY2F1dGlvbiB0byB0aGUgZmFjaWxpdHkgZm9y IGltcGxlbWVudGF0aW9uLiBJIGhvcGUgd2UgY2FuIGdldCBjb25jbHVzaW9uIGluIA0KdGhlIG5l eHQgdmVyc2lvbiwgdGhhbmtzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5C ZXN0IFJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPk1hcmlvIE1h bzwvRk9OVD48L0RJVj48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElO Ry1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVS LUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCDlrovkvZMiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+ DQogIDxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCDlrovkvZM7IGZv bnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPWdhYnJpZWxfbW9udGVu ZWdyb18yMDAwQHlhaG9vLmNvbSANCiAgaHJlZj0ibWFpbHRvOmdhYnJpZWxfbW9udGVuZWdyb18y MDAwQHlhaG9vLmNvbSI+Z2FicmllbCBtb250ZW5lZ3JvPC9BPiA8L0RJVj4NCiAgPERJViBzdHls ZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+VG86PC9CPiA8QSB0aXRsZT1ra2ltODZAZ21haWwuY29t IA0KICBocmVmPSJtYWlsdG86a2tpbTg2QGdtYWlsLmNvbSI+S2ktSHl1bmcgS2ltPC9BPiA8L0RJ Vj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1k YXZpZC5jdWxsZXJAZ21haWwuY29tIA0KICBocmVmPSJtYWlsdG86ZGF2aWQuY3VsbGVyQGdtYWls LmNvbSI+RGF2aWQgQ3VsbGVyPC9BPiA7IDxBIA0KICB0aXRsZT1nZW9mZkBtdWxsaWdhbi5jb20g aHJlZj0ibWFpbHRvOmdlb2ZmQG11bGxpZ2FuLmNvbSI+R2VvZmYgTXVsbGlnYW48L0E+IDsgDQog IDxBIHRpdGxlPXNvb2hvbmdwQGdtYWlsLmNvbSBocmVmPSJtYWlsdG86c29vaG9uZ3BAZ21haWwu Y29tIj5Tb29ob25nIERhbmllbCANCiAgUGFyazwvQT4gOyA8QSB0aXRsZT02bG93cGFuQGlldGYu b3JnIA0KICBocmVmPSJtYWlsdG86Nmxvd3BhbkBpZXRmLm9yZyI+Nmxvd3BhbkBpZXRmLm9yZzwv QT4gOyA8QSANCiAgdGl0bGU9bWFyaW9tYW9AZ21haWwuY29tIGhyZWY9Im1haWx0bzptYXJpb21h b0BnbWFpbC5jb20iPk1hcmlvIE1hbzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCDlrovkvZMiPjxCPlNlbnQ6PC9CPiBTYXR1cmRheSwgU2VwdGVtYmVyIDMwLCAyMDA2IDEwOjE2 IA0KICBBTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TdWJqZWN0 OjwvQj4gUmU6IFs2bG93cGFuXSBNZXNoIERlbGl2ZXJ5IA0KICBGaWVsZDwvRElWPg0KICA8RElW PjxCUj48L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1J TFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmIj4NCiAgPERJViANCiAg c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1vbmFjbywgbW9u b3NwYWNlLCBzYW5zLXNlcmlmIj5LaS1IeXVuZyw8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZP TlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBz YW5zLXNlcmlmIj4mbmJzcDs8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJw dDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmIj5Z b3UgDQogIGFza2VkOiAiU28sIHdoYXQgaXMgZmluYWwgbG9vayBvZiB0aGUgbWVzaCBkZWxpdmVy eSBmaWVsZD8iPC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQt RkFNSUxZOiBjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fucy1zZXJpZiI+Jm5ic3A7PC9E SVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBjb3Vy aWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fucy1zZXJpZiI+QXMgDQogIHBlciBNYXJpbydzIHN1 Z2dlc3Rpb24sIHdlJ2QgdXNlIG9uZSBvZiB0aGUgNSByZXNlcnZlZCBiaXRzIHRvIHNpZ25hbCBp ZiANCiAgdGhlPC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQt RkFNSUxZOiBjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fucy1zZXJpZiI+YmNhc3QvbWNh c3QmbmJzcDttZXNoJm5ic3A7ZGVsaXZlcnkgDQogIGZvcm1hdCBpcyBiZWluZyB1c2VkLCBhbmQg d2UnZCBjYWxsIGl0IHRoZSAnQicgYml0LjwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBGT05ULUZBTUlMWTogY291cmllciwgbW9uYWNvLCBtb25vc3BhY2UsIHNhbnMt c2VyaWYiPlNvIA0KICBubyBjaGFuZ2UgdG8gdGhlIG1lc2ggZGVsaXZlcnkgZmllbGRzIGlzIHJl cXVpcmVkLiBTaW5jZSB0aGUgcmVzZXJ2ZWQgDQogIGJpdHM8L0RJVj4NCiAgPERJViANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3Nw YWNlLCBzYW5zLXNlcmlmIj5hcmUgDQogIGNvbW1vbiB0byBhbGwgdGhyZWUgbG93cGFuIGhlYWRl ciBmb3JtYXRzLCB0aGUgJ0InIGJpdCB3b3VsZCBhcHBseSB0byANCmFsbDwvRElWPg0KICA8RElW IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogY291cmllciwgbW9uYWNv LCBtb25vc3BhY2UsIHNhbnMtc2VyaWYiPnRocmVlLiANCiAgPEJSPjwvRElWPg0KICA8RElWIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogY291cmllciwgbW9uYWNvLCBt b25vc3BhY2UsIHNhbnMtc2VyaWYiPk1hcmlvIA0KICBhbHNvIGhhZCBhIGNvbW1lbnQgb24gaG93 IHRoZSBoZWFkZXIgY29tcHJlc3Npb24gZm9yY2VzIGFsaWdubWVudCB0byBub3Q8L0RJVj4NCiAg PERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1v bmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmIj5mYWxsIA0KICBvbiBvY3RldCBib3VuZGFyaWVz OjwvRElWPg0KICA8QkxPQ0tRVU9URSBkaXI9bHRyIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0 OyBNQVJHSU4tUklHSFQ6IDBweDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3Nw YWNlLCBzYW5zLXNlcmlmIj4NCiAgICA8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBmYWNlPUFyaWFs PkF0IGxhc3QsIEkgZmluZCZuYnNwO3NvbWUgcHJvYmxlbSB3aGVuIA0KICAgIGltcGxpbWVudCBJ UHY2IGhlYWRlciBjb21wcmVzc2lvbi4gUGxlYXNlIG5vdGUgVHJhZmZpYyBDbGFzcyBhbmQgRmxv dyBMYWJlbCANCiAgICBiaXQgaW4gSEMxLiBJZiB3ZSBkb24ndCBjb21wcmVzcyB0aGUgdHdvIGZp ZWxkLCAyOCBiaXRzICh0aGF0IGlzJm5ic3A7dGhyZWUgDQogICAgYW5kIGhhbGYgYnl0ZXMpIGFy ZSBzZW50LiBIb3dldmVyLCBob3cgdG8gc2VuZCB0aGUgaGFsZiBieXRlPyBBcyBJIGtub3csIA0K ICAgIG1vc3QgaGFyZHdhcmUgY291bGQgb25seSZuYnNwO3RyYW5zbWl0IGRhdGEgaW4gdW5pdCBv ZiBCWVRFLiBTaG91bGQgd2UgbmVlZCANCiAgICA0IGJpdHMgcGVuZGluZyBkYXRhPyZuYnNwO1Ro ZSB3b3JrZGFyb3VuZCB3ZSB1c2VkIGlzIGNvbWJpbmluZyB0aGUgVHJhZmZpYyANCiAgICBDbGFz cyBhbmQgRmxvdyBMYWJlbCB3aXRoIFZlcnNpb24gZmllbGQuIFNvLCB0aGUgVHJhZmZpYyBDbGFz cyBhbmQgRmxvdyANCiAgICBMYWJlbCBiaXQgYmVjb21lcyBWZXJzaW9uLCBUcmFmZmljIENsYXNz IGFuZCBGbG93IExhYmVsIGJpdC48L0ZPTlQ+PEZPTlQgDQogICAgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4gPC9GT05UPjxGT05UIGZhY2U9QXJpYWw+UGxlYXNlIHNlZSBmb2xsb3dpbmcgYXMgDQog ICAgZGV0YWlsLjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+PC9TUEFOPjwvRk9O VD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gbGFuZz1F Ti1VUyANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJyI+PEZPTlQgDQogICAgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+VmVyc2lvbiwg VHJhZmZpYyBDbGFzcyBhbmQgRmxvdyBMYWJlbCAoYml0IDQpOjxCUj4wOiANCiAgICBub3QgY29t cHJlc3NlZCwgZnVsbCA0IGJpdHMgZm9yIFZlcnNpb24sIDggYml0cyBmb3IgVHJhZmZpYyBDbGFz cyBhbmQgMjAgDQogICAgYml0cyBmb3IgRmxvdyBMYWJlbCBhcmUgc2VudDwvRk9OVD48QlI+PEZP TlQgc2l6ZT0yPjE6IFRyYWZmaWMgQ2xhc3MgYW5kIA0KICAgIEZsb3cgTGFiZWwgYXJlIHplcm88 L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPg0KICA8RElWIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogY291cmllciwgbW9uYWNvLCBt b25vc3BhY2UsIHNhbnMtc2VyaWYiPldoYXQgDQogIGRvIHBlb3BsZSB0aGluayBvZiB0aGF0PyBJ J2QgcmF0aGVyIG5vdCBkbyB0aGF0IGJlY2F1c2U8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZP TlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBz YW5zLXNlcmlmIj4mbmJzcDs8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJw dDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmIj4m bmJzcDsmbmJzcDsgDQogIDEuIHdoeSBzZW5kIGEgdmVyc2lvbiBmaWVsZCBpZiB0aGUgdmVyc2lv biBpcyBhbHJlYWR5IGtub3duIChpLmUuLCANCklQdjYpPzwvRElWPg0KICA8RElWIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogY291cmllciwgbW9uYWNvLCBtb25vc3Bh Y2UsIHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyANCiAgMi4gdGhpcyBvbmx5IGZpeGVzIHRoZSBh bGlnbm1lbnQgYXMgZmFyIGFzIHRoZSBJUHY2IGhlYWRlciBpcyBjb25jZXJuZWQsIA0KICBidXQ8 L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNv dXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt0aGVyZSANCiAgYXJlIG1vcmUgaGVhZGVycyBwcm9iYWJseSBmb2xs b3dpbmcsIGFuZCB0aG9zZSBjb3VsZCBhbHNvIGhhdmUgPC9ESVY+DQogIDxESVYgDQogIHN0eWxl PSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFj ZSwgc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YWxpZ25t ZW50IA0KICBpc3N1ZXMuPC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7 IEZPTlQtRkFNSUxZOiBjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fucy1zZXJpZiI+Jm5i c3A7PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZ OiBjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fucy1zZXJpZiI+Rm9yIA0KICBleGFtcGxl LCB3ZSBhbHNvIGhhdmUgYW4gaXNzdWUgd2l0aCBVRFAgaGVhZGVyIGNvbXByZXNzaW9uICh0aGUg b25seTwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlM WTogY291cmllciwgbW9uYWNvLCBtb25vc3BhY2UsIHNhbnMtc2VyaWYiPmhlYWRlciANCiAgY29t cHJlc3Npb24gc2NoZW1lIGN1cnJlbnRseSBkZWZpbmVkIGluIGFkZGl0aW9uIHRvIElQdjYgaGVh ZGVyKTo8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1J TFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmIj4mbmJzcDs8L0RJVj4N CiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIs IG1vbmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQogIFVEUCBzb3VyY2UgcG9ydCAoYml0IDApOjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDA6IE5vdCBjb21wcmVzc2VkLCBjYXJy aWVkICJpbi1saW5lIiAoPEEgDQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtNmxvd3Bhbi1mb3JtYXQtMDQjc2VjdGlvbi0xMC4zLjIiPlNlY3Rpb24gDQogIDEw LjMuMjwvQT4pPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAxOiBDb21wcmVzc2VkIA0KICB0byA0IGJpdHMuJm5ic3A7IFRoZSBhY3R1YWwgMTYtYml0 IHNvdXJjZSBwb3J0IA0KICBpczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIG9idGFpbmVkIGJ5IGNhbGN1bGF0 aW5nOiBQICsgc2hvcnRfcG9ydCB2YWx1ZS4mbmJzcDsgUCBpcyANCiAgYTxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIHByZWRldGVybWluZWQgcG9ydCBudW1iZXIgd2l0aCB2YWx1ZSBUQkQuJm5ic3A7IFRoZSBz aG9ydF9wb3J0IA0KICBpczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIGV4cHJlc3NlZCBhcyBhIDQtYml0IHZh bHVlIHdoaWNoIGlzIGNhcnJpZWQgDQogICJpbi1saW5lIjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICg8QSAN CiAgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bG93cGFuLWZv cm1hdC0wNCNzZWN0aW9uLTEwLjMuMiI+U2VjdGlvbiANCiAgMTAuMy4yPC9BPik8QlI+PEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVRFAgZGVzdGluYXRpb24gcG9ydCAoYml0IA0K ICAxKTo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDA6IE5vdCBjb21wcmVzc2VkLCANCiAgY2FycmllZCAiaW4tbGluZSIgKDxBIA0KICBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZsb3dwYW4tZm9ybWF0LTA0I3Nl Y3Rpb24tMTAuMy4yIj5TZWN0aW9uIA0KICAxMC4zLjI8L0E+KTxCUj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTogQ29tcHJlc3NlZCANCiAgdG8gNCBi aXRzLiZuYnNwOyBUaGUgYWN0dWFsIDE2LWJpdCBkZXN0aW5hdGlvbiBwb3J0IA0KICBpczxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogIG9idGFpbmVkIGJ5IGNhbGN1bGF0aW5nOiBQICsgc2hvcnRfcG9ydCB2YWx1 ZS4mbmJzcDsgUCBpcyANCiAgYTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHByZWRldGVybWluZWQgcG9ydCBu dW1iZXIgd2l0aCB2YWx1ZSBUQkQuJm5ic3A7IFRoZSBzaG9ydF9wb3J0IA0KICBpczxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQogIGV4cHJlc3NlZCBhcyBhIDQtYml0IHZhbHVlIHdoaWNoIGlzIGNhcnJpZWQgDQog ICJpbi1saW5lIjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICg8QSANCiAgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bG93cGFuLWZvcm1hdC0wNCNzZWN0aW9uLTEwLjMuMiI+ U2VjdGlvbiANCiAgMTAuMy4yPC9BPik8QlI+PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05U LVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fu cy1zZXJpZiI+PEJSPkJlY2F1c2UgDQogIG9mIHRoZSBhYm92ZSwgaXQgc2VlbXMgcXVpdGUgcG9z c2libGUgdGhhdCBvbmUgd291bGQgZW5kIHVwIHdpdGggNCBiaXRzPC9ESVY+DQogIDxESVYgDQog IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBjb3VyaWVyLCBtb25hY28sIG1v bm9zcGFjZSwgc2Fucy1zZXJpZiI+Zm9yIA0KICBlaXRoZXIgdGhlIFVEUCBzb3VyY2Ugb3IgZGVz dGluYXRpb24uIEluIHN1Y2ggYSBjYXNlLCB0aGUgbWlzYWxpZ25tZW50IGluIA0KICB0aGU8L0RJ Vj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJp ZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmIj5JUHY2IA0KICBoZWFkZXIgY291bGQg YmUgb2Zmc2V0IGJ5IHRoZSBtaXNhbGlnbm1lbnQgaW4gdGhlIFVEUCBoZWFkZXIgY29tcHJlc3Np b24sIA0KICA8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1G QU1JTFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmIj5hbmQgDQogIHdl J2QgZW5kIHVwIGFsaWduZWQgb24gYW4gb2N0ZXQgYm91bmRhcnkuIE9mIGNvdXJzZSwgaWYgb25l IHVzZXMgdGhlIA0KICBmdW5reTwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0OyBGT05ULUZBTUlMWTogY291cmllciwgbW9uYWNvLCBtb25vc3BhY2UsIHNhbnMtc2VyaWYi PjQtYml0IA0KICBwb3J0IGNvbXByZXNzaW9uIGZvciBib3RoIHNvdXJjZSBhbmQgZGVzdGluYXRp b24gdGhlbiBvbmUgd291bGRuJ3QgDQpvZmZzZXQ8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZP TlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBz YW5zLXNlcmlmIj50aGUgDQogIHByZXZpb3VzIG1pc2FsaWdubWVudC4gTm8gd2F5IHRvIGtub3cs IHNvIHBlcmhhcHMgb25lIHNob3VsZCB3YWl0IHVudGlsIA0KICB0aGU8L0RJVj4NCiAgPERJViAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1vbmFjbywg bW9ub3NwYWNlLCBzYW5zLXNlcmlmIj5lbnRpcmUgDQogIGhlYWRlciBpcyBsYWlkIG91dCB0byBm aWd1cmUgb3V0IGlmIGFueSBwYWRkaW5nIHdpdGggemVybyBiaXRzIGlzIHRvPC9ESVY+DQogIDxE SVYgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBjb3VyaWVyLCBtb25h Y28sIG1vbm9zcGFjZSwgc2Fucy1zZXJpZiI+YmUgDQogIGRvbmUuPC9ESVY+DQogIDxESVYgDQog IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBjb3VyaWVyLCBtb25hY28sIG1v bm9zcGFjZSwgc2Fucy1zZXJpZiI+Jm5ic3A7PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05U LVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fu cy1zZXJpZiI+U28gDQogIHBlcmhhcHMgd2hhdCB3ZSBjYW4gZG8gaXMgdG8gYWRkIHRleHQgdG8g dGhlIGVmZmVjdCB0aGF0IG9uZSBwYWNrcyB0aGUgDQogIGVudGlyZTwvRElWPg0KICA8RElWIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogY291cmllciwgbW9uYWNvLCBt b25vc3BhY2UsIHNhbnMtc2VyaWYiPmhlYWRlciANCiAgYW5kIHRoZW4gcGFkcyBhcyBhcHByb3By aWF0ZSB0byBhbGlnbiB0byBhbiBvY3RldCBib3VuZGFyeS4gRG9lcyB0aGlzIDwvRElWPg0KICA8 RElWIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogY291cmllciwgbW9u YWNvLCBtb25vc3BhY2UsIHNhbnMtc2VyaWYiPnNvdW5kIA0KICByZWFzb25hYmxlPzwvRElWPg0K ICA8RElWIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogY291cmllciwg bW9uYWNvLCBtb25vc3BhY2UsIHNhbnMtc2VyaWYiPiZuYnNwOzwvRElWPg0KICA8RElWIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogY291cmllciwgbW9uYWNvLCBtb25v c3BhY2UsIHNhbnMtc2VyaWYiPnRoYW5rcyANCiAgZm9yIGFueSBjb21tZW50cyw8L0RJVj4NCiAg PERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1v bmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmIj4mbmJzcDs8L0RJVj4NCiAgPERJViANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IGNvdXJpZXIsIG1vbmFjbywgbW9ub3Nw YWNlLCBzYW5zLXNlcmlmIj4tZ2FicmllbDwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+ PC9IVE1MPg0K ------=_NextPart_000_0069_01C6E4A2.28849410-- --===============1343536155== 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 --===============1343536155==-- From 6lowpan-bounces@ietf.org Sat Sep 30 12:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThrY-0003Vc-Ev; Sat, 30 Sep 2006 12:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTUPO-0000GT-9z for 6lowpan@ietf.org; Fri, 29 Sep 2006 22:16:54 -0400 Received: from web81913.mail.mud.yahoo.com ([68.142.207.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GTUPL-0004jN-9Y for 6lowpan@ietf.org; Fri, 29 Sep 2006 22:16:54 -0400 Received: (qmail 49283 invoked by uid 60001); 30 Sep 2006 02:16:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tfSoWHURXUeXkwra6jy5/MIswirSvGsnNWdqkoWpte1eAUoNURgka2oMtz1fM1yF0kV9zlOWTaOwwXfNL5tmkZqQS1j1yK7K1BLrRigaRj3JMagLCnzxhQ1vSobcZWkAPBpvQxJi/7BW+Fy7Ud/WDEM7pElE+mN+1l0X2N1dIbo= ; Message-ID: <20060930021650.49281.qmail@web81913.mail.mud.yahoo.com> Received: from [24.16.14.130] by web81913.mail.mud.yahoo.com via HTTP; Fri, 29 Sep 2006 19:16:50 PDT Date: Fri, 29 Sep 2006 19:16:50 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Mesh Delivery Field To: Ki-Hyung Kim In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: d78508dfaea0c5ea6bced5c3a2ed5574 X-Mailman-Approved-At: Sat, 30 Sep 2006 12:38:51 -0400 Cc: Mario Mao , 6lowpan@ietf.org, David Culler 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="===============0192960026==" Errors-To: 6lowpan-bounces@ietf.org --===============0192960026== Content-Type: multipart/alternative; boundary="0-1262425063-1159582610=:47488" --0-1262425063-1159582610=:47488 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ki-Hyung, =20 You asked: "So, what is final look of the mesh delivery field?" =20 As per Mario's suggestion, we'd use one of the 5 reserved bits to signal if= the bcast/mcast mesh delivery format is being used, and we'd call it the 'B' bi= t. So no change to the mesh delivery fields is required. Since the reserved bi= ts are common to all three lowpan header formats, the 'B' bit would apply to a= ll three.=20 Mario also had a comment on how the header compression forces alignment to = not fall on octet boundaries: 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 se= nd 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 co= mbining the Traffic Class and Flow Label with Version field. So, the Traffi= c Class and Flow Label bit becomes Version, Traffic Class and Flow Label bi= t. Please see following as detail. =20 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 What do people think of that? I'd rather not do that because =20 1. why send a version field if the version is already known (i.e., IPv6)= ? 2. this only fixes the alignment as far as the IFrom 6lowpan-bounces@ietf.org Sat Sep 30 12:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThrY-0003Vc-Ev; Sat, 30 Sep 2006 12:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTUPO-0000GT-9z for 6lowpan@ietf.org; Fri, 29 Sep 2006 22:16:54 -0400 Received: from web81913.mail.mud.yahoo.com ([68.142.207.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GTUPL-0004jN-9Y for 6lowpan@ietf.org; Fri, 29 Sep 2006 22:16:54 -0400 Received: (qmail 49283 invoked by uid 60001); 30 Sep 2006 02:16:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tfSoWHURXUeXkwra6jy5/MIswirSvGsnNWdqkoWpte1eAUoNURgka2oMtz1fM1yF0kV9zlOWTaOwwXfNL5tmkZqQS1j1yK7K1BLrRigaRj3JMagLCnzxhQ1vSobcZWkAPBpvQxJi/7BW+Fy7Ud/WDEM7pElE+mN+1l0X2N1dIbo= ; Message-ID: <20060930021650.49281.qmail@web81913.mail.mud.yahoo.com> Received: from [24.16.14.130] by web81913.mail.mud.yahoo.com via HTTP; Fri, 29 Sep 2006 19:16:50 PDT Date: Fri, 29 Sep 2006 19:16:50 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Mesh Delivery Field To: Ki-Hyung Kim In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: d78508dfaea0c5ea6bced5c3a2ed5574 X-Mailman-Approved-At: Sat, 30 Sep 2006 12:38:51 -0400 Cc: Mario Mao , 6lowpan@ietf.org, David Culler 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="===============0192960026==" Errors-To: 6lowpan-bounces@ietf.org --===============0192960026== Content-Type: multipart/alternative; boundary="0-1262425063-1159582610=:47488" --0-1262425063-1159582610=:47488 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ki-Hyung, =20 You asked: "So, what is final look of the mesh delivery field?" =20 As per Mario's suggestion, we'd use one of the 5 reserved bits to signal if= the bcast/mcast mesh delivery format is being used, and we'd call it the 'B' bi= t. So no change to the mesh delivery fields is required. Since the reserved bi= ts are common to all three lowpan header formats, the 'B' bit would apply to a= ll three.=20 Mario also had a comment on how the header compression forces alignment to = not fall on octet boundaries: 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 se= nd 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 co= mbining the Traffic Class and Flow Label with Version field. So, the Traffi= c Class and Flow Label bit becomes Version, Traffic Class and Flow Label bi= t. Please see following as detail. =20 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 What do people think of that? I'd rather not do that because =20 1. why send a version field if the version is already known (i.e., IPv6)= ? 2. this only fixes the alignment as far as the IPv6 header is concerned,= but there are more headers probably following, and those could also have= =20 alignment issues. =20 For example, we also have an issue with UDP header compression (the only header compression scheme currently defined in addition to IPv6 header): =20 UDP source port (bit 0): 0: Not compressed, carried "in-line" (Section 10.3.2) 1: Compressed to 4 bits. The actual 16-bit source port is obtained by calculating: P + short_port value. P is a predetermined port number with value TBD. The short_port is expressed as a 4-bit value which is carried "in-line" (Section 10.3.2) UDP destination port (bit 1): 0: Not compressed, carried "in-line" (Section 10.3.2) 1: Compressed to 4 bits. The actual 16-bit destination port is obtained by calculating: P + short_port value. P is a predetermined port number with value TBD. The short_port is expressed as a 4-bit value which is carried "in-line" (Section 10.3.2) Because of the above, it seems quite possible that one would end up with 4 = bits for either the UDP source or destination. In such a case, the misalignment = in the IPv6 header could be offset by the misalignment in the UDP header compressi= on,=20 and we'd end up aligned on an octet boundary. Of course, if one uses the fu= nky 4-bit port compression for both source and destination then one wouldn't of= fset the previous misalignment. No way to know, so perhaps one should wait until= the entire header is laid out to figure out if any padding with zero bits is to be done. =20 So perhaps what we can do is to add text to the effect that one packs the e= ntire header and then pads as appropriate to align to an octet boundary. Does thi= s=20 sound reasonable? =20 thanks for any comments, =20 -gabriel =20 ----- Original Message ---- From: Ki-Hyung Kim To: gabriel montenegro Cc: David Culler ; Geoff Mulligan ; Soohong Daniel Park ; 6lowpan@ietf.org Sent: Friday, September 29, 2006 5:16:11 PM Subject: Re: [6lowpan] Mesh Delivery Field I think the flexibility should be fine. So, what is final look of the mesh = delivery field? =20 On 9/30/06, gabriel montenegro wrote:= =20 Ok, it seems like folks would like to have more flexibility in the header. = I'm just having a hard time translating that to actual bits and bytes within the header formats, and how much flexibilit= y is fine.=20 =20 The first packet format has 5 bits of reserved 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Figure 1: LoWPAN unfragmented encapsulation header format =20 One bit out of that reserved field is what Mario Mao suggests we use to dis= tinguish between the two current flavors of mesh delivery header (unicast vs bcast/mcast). Is this sufficient flexib= ility? =20 The issue is that there is no such flexibility in the two other header form= ats, but we can certainly add such a=20 reserved field and make all 3 header formats the same up to the first 16 bi= ts. Perhaps along these lines (notice the new "reserved" field and the corresponding 5 bit shift for data= gram_size and datagram_tag) : =20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| prot_type |M|reserved | datagram_size |dgram_tag| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |dgram_tag| Payload (or Mesh Delivery HdPv6 header is concerned,= but there are more headers probably following, and those could also have= =20 alignment issues. =20 For example, we also have an issue with UDP header compression (the only header compression scheme currently defined in addition to IPv6 header): =20 UDP source port (bit 0): 0: Not compressed, carried "in-line" (Section 10.3.2) 1: Compressed to 4 bits. The actual 16-bit source port is obtained by calculating: P + short_port value. P is a predetermined port number with value TBD. The short_port is expressed as a 4-bit value which is carried "in-line" (Section 10.3.2) UDP destination port (bit 1): 0: Not compressed, carried "in-line" (Section 10.3.2) 1: Compressed to 4 bits. The actual 16-bit destination port is obtained by calculating: P + short_port value. P is a predetermined port number with value TBD. The short_port is expressed as a 4-bit value which is carried "in-line" (Section 10.3.2) Because of the above, it seems quite possible that one would end up with 4 = bits for either the UDP source or destination. In such a case, the misalignment = in the IPv6 header could be offset by the misalignment in the UDP header compressi= on,=20 and we'd end up aligned on an octet boundary. Of course, if one uses the fu= nky 4-bit port compression for both source and destination then one wouldn't of= fset the previous misalignment. No way to know, so perhaps one should wait until= the entire header is laid out to figure out if any padding with zero bits is to be done. =20 So perhaps what we can do is to add text to the effect that one packs the e= ntire header and then pads as appropriate to align to an octet boundary. Does thi= s=20 sound reasonable? =20 thanks for any comments, =20 -gabriel =20 ----- Original Message ---- From: Ki-Hyung Kim To: gabriel montenegro Cc: David Culler ; Geoff Mulligan ; Soohong Daniel Park ; 6lowpan@ietf.org Sent: Friday, September 29, 2006 5:16:11 PM Subject: Re: [6lowpan] Mesh Delivery Field I think the flexibility should be fine. So, what is final look of the mesh = delivery field? =20 On 9/30/06, gabriel montenegro wrote:= =20 Ok, it seems like folks would like to have more flexibility in the header. = I'm just having a hard time translating that to actual bits and bytes within the header formats, and how much flexibilit= y is fine.=20 =20 The first packet format has 5 bits of reserved 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Figure 1: LoWPAN unfragmented encapsulation header format =20 One bit out of that reserved field is what Mario Mao suggests we use to dis= tinguish between the two current flavors of mesh delivery header (unicast vs bcast/mcast). Is this sufficient flexib= ility? =20 The issue is that there is no such flexibility in the two other header form= ats, but we can certainly add such a=20 reserved field and make all 3 header formats the same up to the first 16 bi= ts. Perhaps along these lines (notice the new "reserved" field and the corresponding 5 bit shift for data= gram_size and datagram_tag) : =20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| prot_type |M|reserved | datagram_size |dgram_tag| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |dgram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 Figure 2: LoWPAN first fragment encapsulation header format=20 =20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF|datagram_offset|M|reserved | datagram_size |dgram_tag| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |dgram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: LoWPAN subsequent fragment(s) encapsulation header format =20 =20 =20 Would this be enough? If not, how many bits should be allocated? Should the= re be a version field in addition=20 (as suggested by Vipul a while back)? What changes in the format are sugges= ted? Folks, please be specific as to the suggested changes by sending header formats with clearly proposed= fields, etc. =20 tnx, =20 -gabriel =20 ----- Original Message ---- From: David Culler < david.culler@gmail.com> To: Ki-Hyung Kim Cc: gabriel montenegro < gabriel_montenegro_2000@yahoo.com>; Geoff Mulligan= ; Soohong Daniel Park < soohongp@gmail.com>; 6lowpan@i= etf.org Sent: Friday, September 29, 2006 8:38:56 AM Subject: Re: [6lowpan] Mesh Delivery Field It certainly would be a shame to get into a position where the encoding is = so so constrained that there was not a means of accomodating additional cap= abilities that are revealed through deeper implementation and usage experie= nce. The IP community has historically been very good at planning for chan= ge. Options fields and leaving a little room in the initial encodings are = essential to that. As much as we try, we seldom get every aspect of the pr= otocol exactly right the first time. It is understandable that with so muc= h focus being place on header compression that it is hard to leave any spac= e unclaimed. However, that contingency planning and flexibility may be mor= e critical to eventual adoption than squeezing out every unneccessary bit. = As we look at the desired "rush to finish" it is important to verify that= the proposed framework permits enough expressive power to address the issu= es that have not yet been fully vetted. You cannot expand the format, only= work within it.=20 On 9/26/06, Ki-Hyung Kim wrote:=20 Gabriel, =20 I am sorry for this late reply. Basically, I agree that current format document is rather tightly scheduled= and not well prepared for future enhancements or revisions, in terms of ro= uting, diagnoses, management, etc. Based on the assumption that we are not = yet in the stage of pursuing future rechartering items, it might not be the= right time to consider all the cases at one time. Also, we should be in ru= sh to finish the current format document ASAP for moving forward into next = stage before next IETF meeting.=20 =20 Regarding the mesh delivery field, Mario Mao's approach should be fine, and= other approaches (like option 2,3, and 4) might be OK. However, it seems l= ike we are trying too much to make the format compact while not considering= the future expansions.=20 =20 After all, my opinion is option 1. Let's have one byte for the multicast bi= t and the reserved fields for future. having additional one byte for this is not a big deal in terms of packet si= ze and won't add much complexity for handling it. Examples of utilizing some reserved fields might be follows: 1. Based on the assumption that 6lowpan supports multiple routing protocols= such as LOAD, DYMO-low, HiLow, DSR, or whatever, etc., the field might be= used for indicating which specific routing protocol should be used for rou= ting this particular packet. It might be argued whether the format document= should support multiple protocols at a time. However, those kind of argue = should be debated later while considering routing protocols without elimina= ting future r)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 Figure 2: LoWPAN first fragment encapsulation header format=20 =20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF|datagram_offset|M|reserved | datagram_size |dgram_tag| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |dgram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: LoWPAN subsequent fragment(s) encapsulation header format =20 =20 =20 Would this be enough? If not, how many bits should be allocated? Should the= re be a version field in addition=20 (as suggested by Vipul a while back)? What changes in the format are sugges= ted? Folks, please be specific as to the suggested changes by sending header formats with clearly proposed= fields, etc. =20 tnx, =20 -gabriel =20 ----- Original Message ---- From: David Culler < david.culler@gmail.com> To: Ki-Hyung Kim Cc: gabriel montenegro < gabriel_montenegro_2000@yahoo.com>; Geoff Mulligan= ; Soohong Daniel Park < soohongp@gmail.com>; 6lowpan@i= etf.org Sent: Friday, September 29, 2006 8:38:56 AM Subject: Re: [6lowpan] Mesh Delivery Field It certainly would be a shame to get into a position where the encoding is = so so constrained that there was not a means of accomodating additional cap= abilities that are revealed through deeper implementation and usage experie= nce. The IP community has historically been very good at planning for chan= ge. Options fields and leaving a little room in the initial encodings are = essential to that. As much as we try, we seldom get every aspect of the pr= otocol exactly right the first time. It is understandable that with so muc= h focus being place on header compression that it is hard to leave any spac= e unclaimed. However, that contingency planning and flexibility may be mor= e critical to eventual adoption than squeezing out every unneccessary bit. = As we look at the desired "rush to finish" it is important to verify that= the proposed framework permits enough expressive power to address the issu= es that have not yet been fully vetted. You cannot expand the format, only= work within it.=20 On 9/26/06, Ki-Hyung Kim wrote:=20 Gabriel, =20 I am sorry for this late reply. Basically, I agree that current format document is rather tightly scheduled= and not well prepared for future enhancements or revisions, in terms of ro= uting, diagnoses, management, etc. Based on the assumption that we are not = yet in the stage of pursuing future rechartering items, it might not be the= right time to consider all the cases at one time. Also, we should be in ru= sh to finish the current format document ASAP for moving forward into next = stage before next IETF meeting.=20 =20 Regarding the mesh delivery field, Mario Mao's approach should be fine, and= other approaches (like option 2,3, and 4) might be OK. However, it seems l= ike we are trying too much to make the format compact while not considering= the future expansions.=20 =20 After all, my opinion is option 1. Let's have one byte for the multicast bi= t and the reserved fields for future. having additional one byte for this is not a big deal in terms of packet si= ze and won't add much complexity for handling it. Examples of utilizing some reserved fields might be follows: 1. Based on the assumption that 6lowpan supports multiple routing protocols= such as LOAD, DYMO-low, HiLow, DSR, or whatever, etc., the field might be= used for indicating which specific routing protocol should be used for rou= ting this particular packet. It might be argued whether the format document= should support multiple protocols at a time. However, those kind of argue = should be debated later while considering routing protocols without elimina= ting future possible necessity.=20 2. Routing protocols could be optimzed by having some option fields, while = it might not be right time to specifically mention them. =20 I remember that the issue of the mesh underneath or above IP has been raise= d several times in the WG. I think it might not be right time considering i= t again right now. =20 If you have any other opinions, please let me know. =20 On 9/23/06, gabriel montenegro < gabriel_montenegro_2000@yahoo.com> wrote:= =20 First of all, Thanks David for your thoughtful message. It's great to see y= ou participate in this forum and I hope you'll stick around! =20 >From the point of view of laying the technology foundation, everything in y= our message is quite relevant. >From the point of view of WG management, I'm trying to figure out if we nee= d to act on all of it right now or if there are things we can address independently of the format draft und= er discussion. For example, you bring up the topic of traceroute type functionality. In IP, this is car= ried over ICMP, a separate=20 management control plane. Since what we have in the format draft is a multi= plexing layer, we can=20 define a new protocol value to carry out the management protocol packets. T= he question is if the current format provides the required mechanism to go do work on such a sepa= rate protocol in another draft. Intuitively, it seems like this would work. Someone (your= group, David?) could define such a protocol with functionality similar to ICMP for pings, tracer= oute, etc and provide the route gathering functionality, the echo response, etc in that separate = draft. Conceivably, it would not necessarily use the mesh delivery header, as it would provide its= own facility to record hop-by-hop route information within its own protocol fields. It coul= d use loose source routing in which case some use of the mesh delivery header might be appropr= iate as well. Would such an approach work, David? This would actually play into one of th= e items slated for the next round of 6lowpan (if we ever recharter) to strengthen diagnosabili= ty or management of these networks. =20 As for your point about us not knowing exactly what the header format must = look like at this point in time, this is perhaps something we need to take into consideration right no= w. For example, this input would push us into reserving at least a couple of bits in the header = for future expansion. A while back Vipul was arguing for a "version" field. Not sure if such a field is r= equired or if the current reserved fields are enough. Mario Mao's proposal uses one of those reserved bits to = solve the issue under discussion regarding the mesh delivery header variants for unicast vs mcast= /bcast. There has been=20 one group expressing support for this, so perhaps we already have the neces= sary mechanism in place in the header. =20 David, you also mention the need to support different routing protocols sid= e-by-side for comparison. This is one of the design goals of the format document. As I mentioned, the= protocol field allows one to carry different protocols. We currently have proposals for a 6lowpan ada= ptations of AODV, a DyMO and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps BVR is = next. The point is that the format document does provide the mechanism to define any such protocol,= or is there a limitation you can see in the current document? If so, what needs to change? =20 As for the claim that sub-IP benefits from simpler structures, my interpret= ation is that you're suggesting it=20 is better not to use the mesh delivery header and let IP deal with the unde= rlying individual collection of links. If so, one can ignore the mesh delivery header (not use it) and use the oth= er parts of the format document to simply layer IP on top. This approach would then make use of other activiti= es like AUTOCONF or MANET to create meshes if so desired. Personally, I see that *if* one wishes to = do a mesh, not doing it in the sub-IP layer just pushes to problem upwards into the IP routing realm, and this ju= possible necessity.=20 2. Routing protocols could be optimzed by having some option fields, while = it might not be right time to specifically mention them. =20 I remember that the issue of the mesh underneath or above IP has been raise= d several times in the WG. I think it might not be right time considering i= t again right now. =20 If you have any other opinions, please let me know. =20 On 9/23/06, gabriel montenegro < gabriel_montenegro_2000@yahoo.com> wrote:= =20 First of all, Thanks David for your thoughtful message. It's great to see y= ou participate in this forum and I hope you'll stick around! =20 >From the point of view of laying the technology foundation, everything in y= our message is quite relevant. >From the point of view of WG management, I'm trying to figure out if we nee= d to act on all of it right now or if there are things we can address independently of the format draft und= er discussion. For example, you bring up the topic of traceroute type functionality. In IP, this is car= ried over ICMP, a separate=20 management control plane. Since what we have in the format draft is a multi= plexing layer, we can=20 define a new protocol value to carry out the management protocol packets. T= he question is if the current format provides the required mechanism to go do work on such a sepa= rate protocol in another draft. Intuitively, it seems like this would work. Someone (your= group, David?) could define such a protocol with functionality similar to ICMP for pings, tracer= oute, etc and provide the route gathering functionality, the echo response, etc in that separate = draft. Conceivably, it would not necessarily use the mesh delivery header, as it would provide its= own facility to record hop-by-hop route information within its own protocol fields. It coul= d use loose source routing in which case some use of the mesh delivery header might be appropr= iate as well. Would such an approach work, David? This would actually play into one of th= e items slated for the next round of 6lowpan (if we ever recharter) to strengthen diagnosabili= ty or management of these networks. =20 As for your point about us not knowing exactly what the header format must = look like at this point in time, this is perhaps something we need to take into consideration right no= w. For example, this input would push us into reserving at least a couple of bits in the header = for future expansion. A while back Vipul was arguing for a "version" field. Not sure if such a field is r= equired or if the current reserved fields are enough. Mario Mao's proposal uses one of those reserved bits to = solve the issue under discussion regarding the mesh delivery header variants for unicast vs mcast= /bcast. There has been=20 one group expressing support for this, so perhaps we already have the neces= sary mechanism in place in the header. =20 David, you also mention the need to support different routing protocols sid= e-by-side for comparison. This is one of the design goals of the format document. As I mentioned, the= protocol field allows one to carry different protocols. We currently have proposals for a 6lowpan ada= ptations of AODV, a DyMO and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps BVR is = next. The point is that the format document does provide the mechanism to define any such protocol,= or is there a limitation you can see in the current document? If so, what needs to change? =20 As for the claim that sub-IP benefits from simpler structures, my interpret= ation is that you're suggesting it=20 is better not to use the mesh delivery header and let IP deal with the unde= rlying individual collection of links. If so, one can ignore the mesh delivery header (not use it) and use the oth= er parts of the format document to simply layer IP on top. This approach would then make use of other activiti= es like AUTOCONF or MANET to create meshes if so desired. Personally, I see that *if* one wishes to = do a mesh, not doing it in the sub-IP layer just pushes to problem upwards into the IP routing realm, and this ju= st makes things even more complex than doing it under sub-IP. Complexity will be there no matter what, it's j= ust a question of where one wants to address it. I do note that sub-IP complex structures are very popular and d= eployed in some cases (802.1d bridged networks). Perhaps likely to become even more so with 802.11s within a few = years. =20 I would not be interested in pursuing an AUTOCONF path, but think it should be possible to do so for those so inclined. Does this sound doable? Again, = my immediate concern is that the format document not prevent this approach.=20 =20 -gabriel =20 ----- Original Message ---- From: Geoff Mulligan < geoff@mulligan.com> To: Soohong Daniel Park Cc: 6lowpan@ietf.org; David Culler Sent: Friday, September 22, 2006 6:41:21 AM=20 Subject: Re: [6lowpan] Mesh Delivery Field Daniel, While the WG last call did expire, I'm not sure if David is too late. I think that he raises some important concerns and I'm not sure that we really have consensus on the mesh delivery field. I would like to hear from the list on this. I think that Gabriel has put forth 4 alternatives. Carsten indicated that he thought he might have a different alternative and would post to the list either the alternative or his consideration of the 4 alternatives - Carsten, please=20 send your thoughts. I feel that the issue David raises should be dealt with by the WG because I do not want to send the draft on to the IESG only to have these issues brought up in the IETF last call. These seem rather=20 fundamental to me and we might look rather foolish not having resolved this in the working group! We need some significant discussion from the members of the WG. This WG has been, my self included, rather quiet and as a result we have moved=20 at a snails pace getting anything done. I implore everyone to take time and read the thread on the mesh field and send your thoughts, pro, con or otherwise to this list. If everyone continues to be apathetic about=20 this work, I hold little hope for this WG being rechartered to do any other work! geoff On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote: > David, >=20 > First off, your issue raising in this thread seems too late since our=20 > official WGLC was expired: "This Last Call will end on Wednesday 02 > August 2006 at 2359 UTC." >=20 > Anyway, my sense is not to take Mesh issue at this stage. As long as > we are looking at the 6lowpan solution format, mesh is out of scope of=20 > that. In fact, as far as I am concern, mesh belongs to 15.4 technology > based on MAC layer. Instead, as described in the rechartering, we will > go through adhoc issue based on IP layer. That's why we are here in=20 > 6lowpan wg of ietf. >=20 > But, some staffs described in your mail seem helpful from the 6lowpan > perspective, especially IPv6 related stuffs. If allowed, please bring > your concern to the next 6lowpan face-to-face meeting in San Diego.=20 > Then, we will have further details in there I believe... >=20 > --=20 >=20 >=20 > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. >=20 >=20 >=20 > On 9/21/06, David Culler wrote: > > Dear All,=20 > >=20 > > I would like to raise a concern about the Mesh Delivery Field > > definition in Section 11 of the format document. While the actual > > mesh routing protocol is appropriately outside the scope of the=20 > > 6lowpan Format document, that format needs provide the raw structure > > upon which rough consensus and running code can be flourish. We > > know that low power wireless mesh routing is technically tricky and=20 > > strongly influenced by target traffic load, power management profile, > > network design, and so on. Thus, it is reasonable to expect that the > > consensus building and technical refinement process will require=20 > > on-going experience with protocol and implementation alternatives. > > The 6lowpan format document should support this process, although it > > should not dictate its conclusion. >st makes things even more complex than doing it under sub-IP. Complexity will be there no matter what, it's j= ust a question of where one wants to address it. I do note that sub-IP complex structures are very popular and d= eployed in some cases (802.1d bridged networks). Perhaps likely to become even more so with 802.11s within a few = years. =20 I would not be interested in pursuing an AUTOCONF path, but think it should be possible to do so for those so inclined. Does this sound doable? Again, = my immediate concern is that the format document not prevent this approach.=20 =20 -gabriel =20 ----- Original Message ---- From: Geoff Mulligan < geoff@mulligan.com> To: Soohong Daniel Park Cc: 6lowpan@ietf.org; David Culler Sent: Friday, September 22, 2006 6:41:21 AM=20 Subject: Re: [6lowpan] Mesh Delivery Field Daniel, While the WG last call did expire, I'm not sure if David is too late. I think that he raises some important concerns and I'm not sure that we really have consensus on the mesh delivery field. I would like to hear from the list on this. I think that Gabriel has put forth 4 alternatives. Carsten indicated that he thought he might have a different alternative and would post to the list either the alternative or his consideration of the 4 alternatives - Carsten, please=20 send your thoughts. I feel that the issue David raises should be dealt with by the WG because I do not want to send the draft on to the IESG only to have these issues brought up in the IETF last call. These seem rather=20 fundamental to me and we might look rather foolish not having resolved this in the working group! We need some significant discussion from the members of the WG. This WG has been, my self included, rather quiet and as a result we have moved=20 at a snails pace getting anything done. I implore everyone to take time and read the thread on the mesh field and send your thoughts, pro, con or otherwise to this list. If everyone continues to be apathetic about=20 this work, I hold little hope for this WG being rechartered to do any other work! geoff On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote: > David, >=20 > First off, your issue raising in this thread seems too late since our=20 > official WGLC was expired: "This Last Call will end on Wednesday 02 > August 2006 at 2359 UTC." >=20 > Anyway, my sense is not to take Mesh issue at this stage. As long as > we are looking at the 6lowpan solution format, mesh is out of scope of=20 > that. In fact, as far as I am concern, mesh belongs to 15.4 technology > based on MAC layer. Instead, as described in the rechartering, we will > go through adhoc issue based on IP layer. That's why we are here in=20 > 6lowpan wg of ietf. >=20 > But, some staffs described in your mail seem helpful from the 6lowpan > perspective, especially IPv6 related stuffs. If allowed, please bring > your concern to the next 6lowpan face-to-face meeting in San Diego.=20 > Then, we will have further details in there I believe... >=20 > --=20 >=20 >=20 > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. >=20 >=20 >=20 > On 9/21/06, David Culler wrote: > > Dear All,=20 > >=20 > > I would like to raise a concern about the Mesh Delivery Field > > definition in Section 11 of the format document. While the actual > > mesh routing protocol is appropriately outside the scope of the=20 > > 6lowpan Format document, that format needs provide the raw structure > > upon which rough consensus and running code can be flourish. We > > know that low power wireless mesh routing is technically tricky and=20 > > strongly influenced by target traffic load, power management profile, > > network design, and so on. Thus, it is reasonable to expect that the > > consensus building and technical refinement process will require=20 > > on-going experience with protocol and implementation alternatives. > > The 6lowpan format document should support this process, although it > > should not dictate its conclusion. > >=20 > > Based on past experience with IP layer 3 routing and with past > > internally routed links, we can establish a few primary goals for the > > expressiveness of the 6lowpan Mesh Delivery Field.=20 > > (1) It should support the visibility into the routed 15.4 cloud > > necessary to develop, debug, diagnose, and manage the 15.4 cloud. > > (2) It should support the ability to define, develop and compare=20 > > routing protocols and possibly support the presence of multiple > > protocols for widely differing usage cases. > > (3) It needs to be possible for nodes to communicate with other node= s=20 > > in the cloud in order to discover and negotiate joining the cloud > > without joining the cloud a priori through some mechanism that is > > opaque to IP and above. > > > > (1) has historically been addressed through various forms of source=20 > > routing. It should be possible to do the equivalent of traceroute > > through the 15.4 mesh and this should be accessible in some form throug= h IP > > so > > higher layers can be built to perform the management. The current=20 > > Mesh Delivery Field definition seems to prohibit any form of source rou= ting. > > It assumes that the routing tables are all set up and correct so that > > the forwarder can "swizzle" the destination address field of the 15.4 > > header with a table entry. (The experience of IP over ATM and the > > thousands of pages of the Q83b signalling protocol required to set up > > all the tables in advance ought to give us a little pause here.) The= =20 > > idea of supporting table-driven routing and thereby separating the > > route formation from the forwarding engine is a good one, but there > > needs to be enough expressive power to support the protocols that will= =20 > > establish and manage those tables (rather than relying on an opaque > > out-of-band signaling mechanism) and there needs to be the ability to > > query and validate those tables without relying on out-of-band=20 > > mechanisms. > > > > (2) has historically be addressed with protocol identifiers and > > options. As we went through the various RIP, OSPF, etc. we didn't > > need to go back and redefine the format documents. There was enough=20 > > expressiveness for topology formation and routing to evolve. Not all > > networks need to support all protocols. That has been the network > > designers' determination. The underlying structure provided the=20 > > primitives, allowing solutions (and consensus) to evolve. We want to > > avoid creating a "winner take all" structure where there is no room > > for evolution and development. It is possible that AODV, or TinyAODV,= =20 > > or DSR, or GPSR or possibly one of several other alternatives is the ri= ght > > solution. However, there is little evidence of one having clear superi= ority > > at > > this time, despite numerous high profile efforts. We should be definin= g the=20 > > canvas upon which competing alternatives can be defined and vetted. > > > > (3) has historically been addressed by a limited ability to > > communicate on the link to a crudely defined set of nodes in order to= =20 > > bootstrap the discovery, join, address assignment, negotiation, etc. > > Most successful links under IP look either like a broadcast medium or > > a point-to-point link (a degenerative broadcast). This allows ARP,=20 > > RARP, BOOTP, DHCP, etc. to gain higher level accessibility and > > addressibility through the link. Links that require complex > > signaling, discovery, joining and coordnation below the link layer,=20 > > including ATM, Bluetooth (piconets and scatter nets), and IRDA have > > proved onerous for IP and have been relegated to far less general > > usage scenarios - such as the desktop USB replacement. Even though=20 > > the radio is a broadcast medium, the challenge in a routed link is > > that the link is not by default a link-wide broadcast phy. There > > are two natural notions of "broadcast" in a lowpan. (i) The physical= =20 > > neighbors that happen to receive a transmission because they are close > > eno >=20 > > Based on past experience with IP layer 3 routing and with past > > internally routed links, we can establish a few primary goals for the > > expressiveness of the 6lowpan Mesh Delivery Field.=20 > > (1) It should support the visibility into the routed 15.4 cloud > > necessary to develop, debug, diagnose, and manage the 15.4 cloud. > > (2) It should support the ability to define, develop and compare=20 > > routing protocols and possibly support the presence of multiple > > protocols for widely differing usage cases. > > (3) It needs to be possible for nodes to communicate with other node= s=20 > > in the cloud in order to discover and negotiate joining the cloud > > without joining the cloud a priori through some mechanism that is > > opaque to IP and above. > > > > (1) has historically been addressed through various forms of source=20 > > routing. It should be possible to do the equivalent of traceroute > > through the 15.4 mesh and this should be accessible in some form throug= h IP > > so > > higher layers can be built to perform the management. The current=20 > > Mesh Delivery Field definition seems to prohibit any form of source rou= ting. > > It assumes that the routing tables are all set up and correct so that > > the forwarder can "swizzle" the destination address field of the 15.4 > > header with a table entry. (The experience of IP over ATM and the > > thousands of pages of the Q83b signalling protocol required to set up > > all the tables in advance ought to give us a little pause here.) The= =20 > > idea of supporting table-driven routing and thereby separating the > > route formation from the forwarding engine is a good one, but there > > needs to be enough expressive power to support the protocols that will= =20 > > establish and manage those tables (rather than relying on an opaque > > out-of-band signaling mechanism) and there needs to be the ability to > > query and validate those tables without relying on out-of-band=20 > > mechanisms. > > > > (2) has historically be addressed with protocol identifiers and > > options. As we went through the various RIP, OSPF, etc. we didn't > > need to go back and redefine the format documents. There was enough=20 > > expressiveness for topology formation and routing to evolve. Not all > > networks need to support all protocols. That has been the network > > designers' determination. The underlying structure provided the=20 > > primitives, allowing solutions (and consensus) to evolve. We want to > > avoid creating a "winner take all" structure where there is no room > > for evolution and development. It is possible that AODV, or TinyAODV,= =20 > > or DSR, or GPSR or possibly one of several other alternatives is the ri= ght > > solution. However, there is little evidence of one having clear superi= ority > > at > > this time, despite numerous high profile efforts. We should be definin= g the=20 > > canvas upon which competing alternatives can be defined and vetted. > > > > (3) has historically been addressed by a limited ability to > > communicate on the link to a crudely defined set of nodes in order to= =20 > > bootstrap the discovery, join, address assignment, negotiation, etc. > > Most successful links under IP look either like a broadcast medium or > > a point-to-point link (a degenerative broadcast). This allows ARP,=20 > > RARP, BOOTP, DHCP, etc. to gain higher level accessibility and > > addressibility through the link. Links that require complex > > signaling, discovery, joining and coordnation below the link layer,=20 > > including ATM, Bluetooth (piconets and scatter nets), and IRDA have > > proved onerous for IP and have been relegated to far less general > > usage scenarios - such as the desktop USB replacement. Even though=20 > > the radio is a broadcast medium, the challenge in a routed link is > > that the link is not by default a link-wide broadcast phy. There > > are two natural notions of "broadcast" in a lowpan. (i) The physical= =20 > > neighbors that happen to receive a transmission because they are close > > enough to pick up the signal and have their radios turned on to > > receive. (ii) The entire collection of nodes that can be reached by a= =20 > > multihop dissemination (flood). Both of these are extremely useful in > > bootstrapping higher levels, including routing, and should be > > addressed in the format document. Additionally, it is not=20 > > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over > > a 15.4 link. Providing some forms of broadcast using data frames > > makes the 802.15.4 format much more like 802.11 and other links that > > have proved very suitable for IP. Few, if any, of the public 15.4 rout= ing > > layers developed > > by the TinyOS community utilize beacon packets. > > > > The recognition that the current Mesh Delivery field may be to restrict= ive=20 > > is intimated by the need to define a second form of the header for > > multicast (and link local broadcast) that includes a sequence number. > > The mesh header field type is defined by whether the destination=20 > > address is unicast or multicast. The document states that the use of > > such a sequence number is out of scope. However, the observation that > > that extra information may need to be included depending on how=20 > > packets are routed further suggests that more careful format > > definition is needed to support future development of mesh routing. > > > > Have folks who have been developing mesh layers for lowpan6 felt that= =20 > > the existing Mesh Delivery Field is too restrictive? > > > > > > David E. Culler > > UC Berkeley > > culler@cs.berkeley.edu > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan=20 > >=20 > > > > >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan=20 _______________________________________________=20 6lowpan mailing list 6lowpan@ietf.org=20 https://www1.ietf.org/mailman/listinfo/6lowpan =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --=20 Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8=B5=B7=E4=BA=A8) Associate Professor Division of Information and Computer Eng., Ajou University, Suwon, Korea 44= 2-749 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 http://ww= w.6lowpan.org=20 --=20 David E. Culler Arched Rock Corporation 2168 Shattuck Ave Berkeley, CA 94704 www.archedrock.com =20 --=20 Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8=B5=B7=E4=BA=A8) Associate Professor Division of Information and Computer Eng., Ajou University, Suwon, Korea 44= 2-749=20 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 http://ww= w.6lowpan.org --0-1262425063-1159582610=:47488 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ki-Hyung,
 
You asked: "So, what is final look of the mesh delivery field?"
 
As per Mario's suggestion, we'd use one of the 5 reserved bits to = signal if the
bcast/mcast mesh delivery format is being used, and we'd= call it the 'B' bit.
So no change to the mesh delivery fielugh to pick up the signal and have their radios turned on to > > receive. (ii) The entire collection of nodes that can be reached by a= =20 > > multihop dissemination (flood). Both of these are extremely useful in > > bootstrapping higher levels, including routing, and should be > > addressed in the format document. Additionally, it is not=20 > > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over > > a 15.4 link. Providing some forms of broadcast using data frames > > makes the 802.15.4 format much more like 802.11 and other links that > > have proved very suitable for IP. Few, if any, of the public 15.4 rout= ing > > layers developed > > by the TinyOS community utilize beacon packets. > > > > The recognition that the current Mesh Delivery field may be to restrict= ive=20 > > is intimated by the need to define a second form of the header for > > multicast (and link local broadcast) that includes a sequence number. > > The mesh header field type is defined by whether the destination=20 > > address is unicast or multicast. The document states that the use of > > such a sequence number is out of scope. However, the observation that > > that extra information may need to be included depending on how=20 > > packets are routed further suggests that more careful format > > definition is needed to support future development of mesh routing. > > > > Have folks who have been developing mesh layers for lowpan6 felt that= =20 > > the existing Mesh Delivery Field is too restrictive? > > > > > > David E. Culler > > UC Berkeley > > culler@cs.berkeley.edu > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan=20 > >=20 > > > > >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan=20 _______________________________________________=20 6lowpan mailing list 6lowpan@ietf.org=20 https://www1.ietf.org/mailman/listinfo/6lowpan =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --=20 Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8=B5=B7=E4=BA=A8) Associate Professor Division of Information and Computer Eng., Ajou University, Suwon, Korea 44= 2-749 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 http://ww= w.6lowpan.org=20 --=20 David E. Culler Arched Rock Corporation 2168 Shattuck Ave Berkeley, CA 94704 www.archedrock.com =20 --=20 Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8=B5=B7=E4=BA=A8) Associate Professor Division of Information and Computer Eng., Ajou University, Suwon, Korea 44= 2-749=20 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 http://ww= w.6lowpan.org --0-1262425063-1159582610=:47488 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ki-Hyung,
 
You asked: "So, what is final look of the mesh delivery field?"
 
As per Mario's suggestion, we'd use one of the 5 reserved bits to = signal if the
bcast/mcast mesh delivery format is being used, and we'd= call it the 'B' bit.
So no change to the mesh delivery fields is required. Since the re= served bits
are common to all three lowpan header formats, the 'B' bit would a= pply to all
three.
Mario also had a comment on how the header compression forces alig= nment to not
fall on octet boundaries:
At last, I find some problem wh= en impliment IPv6 header compression. Please note Traffic Class and Flow La= bel bit in HC1. If we don't compress the two field, 28 bits (that is t= hree and half bytes) are sent. However, how to send the half byte? As I kno= w, most hardware could only transmit data in unit of BYTE. Should we n= eed 4 bits pending data? The workdaround we used is combining the Traf= fic 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.
&n= bsp;
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<= /FONT>
What do people think of that? I'd rather not do that because
 
   1. why send a version field if the version is already= known (i.e., IPv6)?
   2. this only fixes the alignment as far as the IPv6 h= eader is concerned, but
      there are more headers probabl= y following, and those could also have
      alignment issues.
 
For example, we also have an issue with UDP header compression (th= e only
header compression scheme currently defined in addition to IPv6 he= ader):
 
      UDP source port (bit 0):
 &= nbsp;       0: Not compressed, carried "in-li= ne" (Section 10.3.2)
      &nb= sp;  1: Compressed to 4 bits.  The actual 16-bit source port is            obtain= ed by calculating: P + shords is required. Since the re= served bits
are common to all three lowpan header formats, the 'B' bit would a= pply to all
three.
Mario also had a comment on how the header compression forces alig= nment to not
fall on octet boundaries:
At last, I find some problem wh= en impliment IPv6 header compression. Please note Traffic Class and Flow La= bel bit in HC1. If we don't compress the two field, 28 bits (that is t= hree and half bytes) are sent. However, how to send the half byte? As I kno= w, most hardware could only transmit data in unit of BYTE. Should we n= eed 4 bits pending data? The workdaround we used is combining the Traf= fic 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.
&n= bsp;
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<= /FONT>
What do people think of that? I'd rather not do that because
 
   1. why send a version field if the version is already= known (i.e., IPv6)?
   2. this only fixes the alignment as far as the IPv6 h= eader is concerned, but
      there are more headers probabl= y following, and those could also have
      alignment issues.
 
For example, we also have an issue with UDP header compression (th= e only
header compression scheme currently defined in addition to IPv6 he= ader):
 
      UDP source port (bit 0):
 &= nbsp;       0: Not compressed, carried "in-li= ne" (Section 10.3.2)
      &nb= sp;  1: Compressed to 4 bits.  The actual 16-bit source port is            obtain= ed by calculating: P + short_port value.  P is a
   =          predetermined port number = with value TBD.  The short_port is
     &n= bsp;      expressed as a 4-bit value which is carr= ied "in-line"
         &nbs= p;  (Section 10.3.2)

      UDP destina= tion port (bit 1):
         0: N= ot compressed, carried "in-line" (Section 10.3.2)
 &nbs= p;       1: Compressed to 4 bits.  The a= ctual 16-bit destination port is
      &nb= sp;     obtained by calculating: P + short_port value.&= nbsp; P is a
          = ;  predetermined port number with value TBD.  The short_port is            expres= sed as a 4-bit value which is carried "in-line"
    =         (Section 10.3.2)

Because of the above, it seems quite possible that one would e= nd up with 4 bits
for either the UDP source or destination. In such a case, the misa= lignment in the
IPv6 header could be offset by the misalignment in the UDP header = compression,
and we'd end up aligned on an octet boundary. Of course, if one us= es the funky
4-bit port compression for both source and destination then one wo= uldn't offset
the previous misalignment. No way to know, so perhaps one should w= ait until the
entire header is laid out to figure out if any padding with zero b= its is to
be done.
 
So perhaps what we can do is to add text to the effect that one pa= cks the entire
header and then pads as appropriate to align to an octet boundary.= Does this
sound reasonable?
 
thanks for any comments,
 
-gabriel
 
----- Original Message ----
From: Ki-Hyung Kim <kkim86@gmai= l.com>
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com&g= t;
Cc: David Cult_port value.  P is a
   =          predetermined port number = with value TBD.  The short_port is
     &n= bsp;      expressed as a 4-bit value which is carr= ied "in-line"
         &nbs= p;  (Section 10.3.2)

      UDP destina= tion port (bit 1):
         0: N= ot compressed, carried "in-line" (Section 10.3.2)
 &nbs= p;       1: Compressed to 4 bits.  The a= ctual 16-bit destination port is
      &nb= sp;     obtained by calculating: P + short_port value.&= nbsp; P is a
          = ;  predetermined port number with value TBD.  The short_port is            expres= sed as a 4-bit value which is carried "in-line"
    =         (Section 10.3.2)

Because of the above, it seems quite possible that one would e= nd up with 4 bits
for either the UDP source or destination. In such a case, the misa= lignment in the
IPv6 header could be offset by the misalignment in the UDP header = compression,
and we'd end up aligned on an octet boundary. Of course, if one us= es the funky
4-bit port compression for both source and destination then one wo= uldn't offset
the previous misalignment. No way to know, so perhaps one should w= ait until the
entire header is laid out to figure out if any padding with zero b= its is to
be done.
 
So perhaps what we can do is to add text to the effect that one pa= cks the entire
header and then pads as appropriate to align to an octet boundary.= Does this
sound reasonable?
 
thanks for any comments,
 
-gabriel
 
----- Original Message ----
From: Ki-Hyung Kim <kkim86@gmai= l.com>
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com&g= t;
Cc: David Culler <david.culler@gmail.com>; Geoff Mulligan <g= eoff@mulligan.com>; Soohong Daniel Park <soohongp@gmail.com>; 6low= pan@ietf.org
Sent: Friday, September 29, 2006 5:16:11 PM
Subject: Re:= [6lowpan] Mesh Delivery Field

I think the flexibility should be fine. So, what is final look of the = mesh delivery field?

 
On 9/30/06, gabr= iel montenegro <gabriel_montenegro_2000@yaho= o.com> wrote:=20
Ok, it seems like folks would like to have more flexibility in th= e header. I'm just having a hard time translating that
to actual bits and bytes within the header formats, and how much = flexibility is fine.
 
The first packet format has 5 bits of reserved field:
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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   &nb= sp; |Payload (or Mesh Delivery Hdr)...
      +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 1: LoWPAN = unfragmented encapsulation header format
 
One bit out of that reserved field is what Mario Mao suggest= s we use to distinguish between the two current flavors
of mesh delivery header (unicast vs bcast/mcast). Is this suffici= ent flexibility?
 
The issue is that there is no such flexibility in the two other h= eader formats, but we can certainly add such a=20
reserved field and make all 3 header formats the same up to the f= irst 16 bits. Perhaps along these lines
(notice the new "reserved" field and the corresponding 5&nbs= p;bit shift for datagram_size and datagram_tag) :
 
  = ;            &n= bsp;   &nbler <david.culler@gmail.com>; Geoff Mulligan <g= eoff@mulligan.com>; Soohong Daniel Park <soohongp@gmail.com>; 6low= pan@ietf.org
Sent: Friday, September 29, 2006 5:16:11 PM
Subject: Re:= [6lowpan] Mesh Delivery Field

I think the flexibility should be fine. So, what is final look of the = mesh delivery field?

 
On 9/30/06, gabr= iel montenegro <gabriel_montenegro_2000@yaho= o.com> wrote:=20
Ok, it seems like folks would like to have more flexibility in th= e header. I'm just having a hard time translating that
to actual bits and bytes within the header formats, and how much = flexibility is fine.
 
The first packet format has 5 bits of reserved field:
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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   &nb= sp; |Payload (or Mesh Delivery Hdr)...
      +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 1: LoWPAN = unfragmented encapsulation header format
 
One bit out of that reserved field is what Mario Mao suggest= s we use to distinguish between the two current flavors
of mesh delivery header (unicast vs bcast/mcast). Is this suffici= ent flexibility?
 
The issue is that there is no such flexibility in the two other h= eader formats, but we can certainly add such a=20
reserved field and make all 3 header formats the same up to the f= irst 16 bits. Perhaps along these lines
(notice the new "reserved" field and the corresponding 5&nbs= p;bit shift for datagram_size and datagram_tag) :
 
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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|reserved |   da= tagram_size     |dgram_tag|
    =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |dgram_tag| Payload (or Mesh Delivery H= dr)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
        Figure 2: LoWP= AN first fragment encapsulation header format
 
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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|reserved |   datagram_size &nb= sp;   |dgram_tag|
      +-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   =    |dgram_tag| Payload (or Mesh Delivery Hdr)...
    &= nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
    Figure 3: LoWPAN subsequent fragment(s) encapsulatio= n header format
 
 
 
Would this be enough? If not, how many bits should be allocated? = Should there be a version field in addition
(as suggested by Vipul a while back)? What changes in the format = are suggested? Folks, please be specific
as to the suggested changes by sending header formats with clearl= y proposed fields, etc.
 
tnx,
 
-gabriel

 
&nbs= p;      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|reserved |   da= tagram_size     |dgram_tag|
    =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |dgram_tag| Payload (or Mesh Delivery H= dr)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
        Figure 2: LoWP= AN first fragment encapsulation header format
 
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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|reserved |   datagram_size &nb= sp;   |dgram_tag|
      +-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   =    |dgram_tag| Payload (or Mesh Delivery Hdr)...
    &= nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
    Figure 3: LoWPAN subsequent fragment(s) encapsulatio= n header format
 
 
 
Would this be enough? If not, how many bits should be allocated? = Should there be a version field in addition
(as suggested by Vipul a while back)? What changes in the format = are suggested? Folks, please be specific
as to the suggested changes by sending header formats with clearl= y proposed fields, etc.
 
tnx,
 
-gabriel

 
----- Original Message ----
From: David Culler < david.culler@gmail.com>
To: Ki-Hyung Kim <kkim86@gma= il.com>
Cc: gabriel montenegro < gabri= el_montenegro_2000@yahoo.com>; Geoff Mulligan <geoff@mul= ligan.com>; Soohong Daniel Park < soohongp@gmail.com= >; 6lowpan@ietf.org
Sent: Friday, September 29, 2006 8:38:= 56 AM
Subject: Re: [6lowpan] Mesh Delivery Field

It certainly would be a shame to get into a position where the encoding is so= so constrained that there was not a means of accomodating additional capab= ilities that are revealed through deeper implementation and usage experienc= e.  The IP community has historically been very good at planning for c= hange.  Options fields and leaving a little room in the initial encodi= ngs are essential to that.  As much as we try, we seldom get every asp= ect of the protocol exactly right the first time.  It is understandabl= e that with so much focus being place on header compression that it is hard= to leave any space unclaimed.  However, that contingency planning and= flexibility may be more critical to eventual adoption than squeezing out e= very unneccessary bit.   As we look at the desired "rush to finis= h" it is important to verify that the proposed framework permits enough exp= ressive power to address the issues that have not yet been fully vetted.&nb= sp; You cannot expand the format, only work within it.

On 9/26/06, Ki-H= yung Kim <kkim86@gmail.com > wrote:=20
Gabriel,
 
I am sorry for this late reply.
Basically, I agree that current format document is rather tightly = ;scheduled and not well prepared for future enhancements or revisions, in t= erms of routing, diagnoses, management, etc. Based on the assumption that w= e are not yet in the stage of pursuing future rechartering items, it m= ight not be the right time to consider all the cases at one time. Also, we = should be in rush to finish the current format document ASAP for moving for= ward into next stage before next IETF meeting.
 
Regarding the mesh delivery field, Mario Mao's approach should be fine= , and other approaches (like option 2,3, and 4) might be OK. However, it se= ems like we are trying too much to make the format compact while = not considering the future expansions.
 
After all, my opinion is option 1. Let's have one byte for the multica= st bit and the reserved fields for future.
having additional one byte for this is not a big deal in terms of= packet size and won't add much complexity for handling it.
Examples of utilizing some reserved fields might be fol= lows:
1. Based on the assumption that 6lowpan supports multiple ro= uting protocols such as  LOAD, DYMO-low, HiLow, DSR, or whatever, = ;etc., the field might be used for indicating which specific routing protoc= ol should be used for routing this particular packet. It might be argued wh= ether the format document should support multiple protocols at a tit; FONT-FAMILY: times new roman, new york, time= s, serif">----- Original Message ----
From: David Culler < david.culler@gmail.com>
To: Ki-Hyung Kim <kkim86@gma= il.com>
Cc: gabriel montenegro < gabri= el_montenegro_2000@yahoo.com>; Geoff Mulligan <geoff@mul= ligan.com>; Soohong Daniel Park < soohongp@gmail.com= >; 6lowpan@ietf.org
Sent: Friday, September 29, 2006 8:38:= 56 AM
Subject: Re: [6lowpan] Mesh Delivery Field

It certainly would be a shame to get into a position where the encoding is so= so constrained that there was not a means of accomodating additional capab= ilities that are revealed through deeper implementation and usage experienc= e.  The IP community has historically been very good at planning for c= hange.  Options fields and leaving a little room in the initial encodi= ngs are essential to that.  As much as we try, we seldom get every asp= ect of the protocol exactly right the first time.  It is understandabl= e that with so much focus being place on header compression that it is hard= to leave any space unclaimed.  However, that contingency planning and= flexibility may be more critical to eventual adoption than squeezing out e= very unneccessary bit.   As we look at the desired "rush to finis= h" it is important to verify that the proposed framework permits enough exp= ressive power to address the issues that have not yet been fully vetted.&nb= sp; You cannot expand the format, only work within it.

On 9/26/06, Ki-H= yung Kim <kkim86@gmail.com > wrote:=20
Gabriel,
 
I am sorry for this late reply.
Basically, I agree that current format document is rather tightly = ;scheduled and not well prepared for future enhancements or revisions, in t= erms of routing, diagnoses, management, etc. Based on the assumption that w= e are not yet in the stage of pursuing future rechartering items, it m= ight not be the right time to consider all the cases at one time. Also, we = should be in rush to finish the current format document ASAP for moving for= ward into next stage before next IETF meeting.
 
Regarding the mesh delivery field, Mario Mao's approach should be fine= , and other approaches (like option 2,3, and 4) might be OK. However, it se= ems like we are trying too much to make the format compact while = not considering the future expansions.
 
After all, my opinion is option 1. Let's have one byte for the multica= st bit and the reserved fields for future.
having additional one byte for this is not a big deal in terms of= packet size and won't add much complexity for handling it.
Examples of utilizing some reserved fields might be fol= lows:
1. Based on the assumption that 6lowpan supports multiple ro= uting protocols such as  LOAD, DYMO-low, HiLow, DSR, or whatever, = ;etc., the field might be used for indicating which specific routing protoc= ol should be used for routing this particular packet. It might be argued wh= ether the format document should support multiple protocols at a time. Howe= ver, those kind of argue should be debated later while considering routing = protocols without eliminating future possible necessity.
2. Routing protocols could be optimzed by having some option fields, w= hile it might not be right time to specifically mention them.
 
I remember that the issue of the mesh underneath or above IP has = been raised several times in the WG. I think it might not be right time con= sidering it again right now.
 
If you have any other opinions, please let me know.

 
On 9/23/06, gabr= iel montenegro < gabriel_montenegro_2000@yah= oo.com> wrote:=20
First of all, Thanks David for your thoughtful message. It's great t= o see you participate in this forum and I hope
you'll stick around!
 
From the point of view of laying the technology foundation, everythi= ng in your message is quite relevant.
From the point of view of WG management, I'm trying to figure out if= we need to act on all of it right now
or if there are things we can address independently of the format dr= aft under discussion. For example,
you bring up the topic of traceroute type functionality. In IP, this= is carried over ICMP, a separate
management control plane. Since what we have in the format draft is = a multiplexing layer, we can
define a new protocol value to carry out the management protocol pac= kets. The question is if the
current format provides the required mechanism to go do work on such= a separate protocol
in another draft. Intuitively, it seems like this would work. Someon= e (your group, David?) could
define such a protocol with functionality similar to ICMP for pings,= traceroute, etc and provide
the route gathering functionality, the echo response, etc in that se= parate draft. Conceivably, it
would not necessarily use the mesh delivery header, as it would prov= ide its own facility to
record hop-by-hop route information within its own protocol fields. = It could use loose source
routing in which case some use of the mesh delivery header might be = appropriate as well.
Would such an approach work, Davidme. Howe= ver, those kind of argue should be debated later while considering routing = protocols without eliminating future possible necessity.
2. Routing protocols could be optimzed by having some option fields, w= hile it might not be right time to specifically mention them.
 
I remember that the issue of the mesh underneath or above IP has = been raised several times in the WG. I think it might not be right time con= sidering it again right now.
 
If you have any other opinions, please let me know.

 
On 9/23/06, gabr= iel montenegro < gabriel_montenegro_2000@yah= oo.com> wrote:=20
First of all, Thanks David for your thoughtful message. It's great t= o see you participate in this forum and I hope
you'll stick around!
 
From the point of view of laying the technology foundation, everythi= ng in your message is quite relevant.
From the point of view of WG management, I'm trying to figure out if= we need to act on all of it right now
or if there are things we can address independently of the format dr= aft under discussion. For example,
you bring up the topic of traceroute type functionality. In IP, this= is carried over ICMP, a separate
management control plane. Since what we have in the format draft is = a multiplexing layer, we can
define a new protocol value to carry out the management protocol pac= kets. The question is if the
current format provides the required mechanism to go do work on such= a separate protocol
in another draft. Intuitively, it seems like this would work. Someon= e (your group, David?) could
define such a protocol with functionality similar to ICMP for pings,= traceroute, etc and provide
the route gathering functionality, the echo response, etc in that se= parate draft. Conceivably, it
would not necessarily use the mesh delivery header, as it would prov= ide its own facility to
record hop-by-hop route information within its own protocol fields. = It could use loose source
routing in which case some use of the mesh delivery header might be = appropriate as well.
Would such an approach work, David? This would actually play into on= e of the items slated for
the next round of 6lowpan (if we ever recharter) to strengthen diagn= osability or management of
these networks.
 
As for your point about us not knowing exactly what the header forma= t must look like at this point in
time, this is perhaps something we need to take into consideration r= ight now. For example, this
input would push us into reserving at least a couple of bits in the = header for future expansion. A while
back Vipul was arguing for a "version" field. Not sure if such a fie= ld is required or if the current reserved
fields are enough. Mario Mao's proposal uses one of those reserved b= its to solve the issue under
discussion regarding the mesh delivery header variants for unicast v= s mcast/bcast. There has been
one group expressing support for this, so perhaps we already have th= e necessary mechanism in place
in the header.
 
David, you also mention the need to support different routing protoc= ols side-by-side for comparison.
This is one of the design goals of the format document. As I mention= ed, the protocol field allows one
to carry different protocols. We currently have proposals for a 6low= pan adaptations of AODV, a DyMO
and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps = BVR is next. The point is that
the format document does provide the mechanism to define any such pr= otocol, or is there a limitation you
can see in the current document? If so, what needs to change?
 
As for the claim that sub-IP benefits from simpler structures, my in= terpretation is that you're suggesting it
is better not to use the mesh delivery header and let IP deal with t= he underlying individual collection of links.
If so, one can ignore the mesh delivery header (not use it) and use = the other parts of the format document to
simply layer IP on top. This approach would then make use of other a= ctivities like AUTOCONF or MANET
the next round of 6lowpan (if we ever recharter) to strengthen diagn= osability or management of
these networks.
 
As for your point about us not knowing exactly what the header forma= t must look like at this point in
time, this is perhaps something we need to take into consideration r= ight now. For example, this
input would push us into reserving at least a couple of bits in the = header for future expansion. A while
back Vipul was arguing for a "version" field. Not sure if such a fie= ld is required or if the current reserved
fields are enough. Mario Mao's proposal uses one of those reserved b= its to solve the issue under
discussion regarding the mesh delivery header variants for unicast v= s mcast/bcast. There has been
one group expressing support for this, so perhaps we already have th= e necessary mechanism in place
in the header.
 
David, you also mention the need to support different routing protoc= ols side-by-side for comparison.
This is one of the design goals of the format document. As I mention= ed, the protocol field allows one
to carry different protocols. We currently have proposals for a 6low= pan adaptations of AODV, a DyMO
and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps = BVR is next. The point is that
the format document does provide the mechanism to define any such pr= otocol, or is there a limitation you
can see in the current document? If so, what needs to change?
 
As for the claim that sub-IP benefits from simpler structures, my in= terpretation is that you're suggesting it
is better not to use the mesh delivery header and let IP deal with t= he underlying individual collection of links.
If so, one can ignore the mesh delivery header (not use it) and use = the other parts of the format document to
simply layer IP on top. This approach would then make use of other a= ctivities like AUTOCONF or MANET
to create meshes if so desired.  Personally, I see that *if* on= e wishes to do a mesh, not doing it in the sub-IP
layer just pushes to problem upwards into the IP routing realm, and = this just makes things even more complex
than doing it under sub-IP. Complexity will be there no matter what,= it's just a question of where one wants to
address it. I do note that sub-IP complex structures are very popula= r and deployed in some cases (802.1d bridged
networks). Perhaps likely to become even more so with 802.11s within= a few years.
 
I would not be interested in pursuing an AUTOCONF path, but think it= should
be possible to do so for those so inclined. Does this sound doable? = Again, my immediate concern is that the
format document not prevent this approach.
 
-gabriel

 
----- Original Message ----
From: Geoff Mulligan < ge= off@mulligan.com>
To: Soohong Daniel Park <soohongp@g= mail.com>
Cc: 6lowpan@ietf.org; David Culler <david.culler@gmail.com>
Sent: Friday, September 22, 2006 = 6:41:21 AM
Subject: Re: [6lowpan] Mesh Delivery Field

Daniel,
  While the WG last call did expire, I'm not sure= if David is too late.
I think that he raises some important concerns an= d I'm not sure that we
really have consensus on the mesh delivery field.=

I would like to hear from the list on this.  I think that= Gabriel has
put forth 4 alternatives.  Carsten indicated that= he thought he might
have a different alternative and would post to the = list either the
alternative or his consideration of the 4 alternatives -= Carsten, please
send your thoughts.

I feel that the issue David= raises should be dealt with by the WG
because I do not want to send the= draft on to the IESG only to have
these issues brought up in the IETF l= ast call.  These seem rather
fundamental to me and we might l= ook rather foolish not having resolved
this in the working group!
We need some significant discussion from the members of the WG.  = ;This WG
has been, my self included, rather quiet and as a result we have mov= ed
at a snails pace getting anything done.  I implore everyon= e to take time
and read the thread on the mesh field and send your thoug= hts, pro, con
or otherwise to this list.  If everyone continue= s to be apathetic about
this work, I hold little hope for this WG being= rechartered to do any
other work!

    geoff<= BR>
On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote:
>= ; David,
> roman,new york,times,= serif">to create meshes if so desired.  Personally, I see that *if* on= e wishes to do a mesh, not doing it in the sub-IP
layer just pushes to problem upwards into the IP routing realm, and = this just makes things even more complex
than doing it under sub-IP. Complexity will be there no matter what,= it's just a question of where one wants to
address it. I do note that sub-IP complex structures are very popula= r and deployed in some cases (802.1d bridged
networks). Perhaps likely to become even more so with 802.11s within= a few years.
 
I would not be interested in pursuing an AUTOCONF path, but think it= should
be possible to do so for those so inclined. Does this sound doable? = Again, my immediate concern is that the
format document not prevent this approach.
 
-gabriel

 
----- Original Message ----
From: Geoff Mulligan < ge= off@mulligan.com>
To: Soohong Daniel Park <soohongp@g= mail.com>
Cc: 6lowpan@ietf.org; David Culler <david.culler@gmail.com>
Sent: Friday, September 22, 2006 = 6:41:21 AM
Subject: Re: [6lowpan] Mesh Delivery Field

Daniel,
  While the WG last call did expire, I'm not sure= if David is too late.
I think that he raises some important concerns an= d I'm not sure that we
really have consensus on the mesh delivery field.=

I would like to hear from the list on this.  I think that= Gabriel has
put forth 4 alternatives.  Carsten indicated that= he thought he might
have a different alternative and would post to the = list either the
alternative or his consideration of the 4 alternatives -= Carsten, please
send your thoughts.

I feel that the issue David= raises should be dealt with by the WG
because I do not want to send the= draft on to the IESG only to have
these issues brought up in the IETF l= ast call.  These seem rather
fundamental to me and we might l= ook rather foolish not having resolved
this in the working group!
We need some significant discussion from the members of the WG.  = ;This WG
has been, my self included, rather quiet and as a result we have mov= ed
at a snails pace getting anything done.  I implore everyon= e to take time
and read the thread on the mesh field and send your thoug= hts, pro, con
or otherwise to this list.  If everyone continue= s to be apathetic about
this work, I hold little hope for this WG being= rechartered to do any
other work!

    geoff<= BR>
On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote:
>= ; David,
>
> First off, your issue raising in this thread seem= s too late since our
> official WGLC was expired: "This Last Call wi= ll end on Wednesday 02
> August 2006 at 2359 UTC."
>
> A= nyway, my sense is not to take Mesh issue at this stage. As long as
>= we are looking at the 6lowpan solution format, mesh is out of scope of > that. In fact, as far as I am concern, mesh belongs to 15.4 technolog= y
> based on MAC layer. Instead, as described in the rechartering, we will
= > go through adhoc issue based on IP layer. That's why we are here in > 6lowpan wg of ietf.
>
> But, some staffs described in y= our mail seem helpful from the 6lowpan
> perspective, especially IPv6= related stuffs. If allowed, please bring
> your concern to the next = 6lowpan face-to-face meeting in San Diego.
> Then, we will have furt= her details in there I believe...
>
> --
>
> > Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, S= AMSUNG Electronics.
>
>
>
> On 9/21/06, David Cu= ller <david.culler@gmail.com> wrote:
> > De= ar All,
> >
> > I would like to raise a concern about t= he Mesh Delivery Field
> > definition in Section 11 of the format document.  While the actual
> > mesh routing protocol i= s appropriately outside the scope of the
> > 6lowpan Format docum= ent, that format needs provide the raw structure
> > upon which ro= ugh consensus and running code can be flourish.  We
> > = know that low power wireless mesh routing is technically tricky and
>= ; > strongly influenced by target traffic load, power management profile= ,
> > network design, and so on.  Thus, it is reasonable= to expect that the
> > consensus building and technical refinemen= t process will require
> > on-going experience with protocol and = implementation alternatives.
> > The 6lowpan format document shoul= d support this process, although it
> > should not dictate its con= clusion.
> >
> > Based on past experience with IP layer = 3 routing and with past
> > internally routed links, we can establ= ish a few primary goals for the
> > expressiveness of the 6lowpan Mesh Deli= very Field.
> >    (1) It should support the = visibility into the routed 15.4 cloud
> > necessary to develop, de= bug, diagnose, and manage the 15.4 cloud.
> >   &nb= sp;(2) It should support the ability to define, develop and compare
>= ; > routing protocols and possibly support the presence of multiple
&= gt; > protocols for widely differing usage cases.
> > &nbs= p;  (3) It needs to be possible for nodes to communicate with oth= er nodes
> > in the cloud in order to discover and negotiate join= ing the cloud
> > without joining the cloud a priori through some = mechanism that is
> > opaque to IP and above.
> >
>= > (1) has historically been addressed through various forms of source <= BR>> > routing.  It should be possible to do the equivalent= of traceroute
> > through the 15.4 mesh and this should be accessibl= e in some form through IP
> > so
> > higher layers can be= built to perform the management.  The current
> > Mesh= Delivery Field definition seems to prohibit any form of source routing.> > It assumes that the routing tables are all set up and correct so= that
> > the forwarder can "swizzle" the destination address fiel= d of the 15.4
> > header with a table entry.  (The exper= ience of IP over ATM and the
> > thousands of pages of the Q83b si= gnalling p
> First off, your issue raising in this thread seem= s too late since our
> official WGLC was expired: "This Last Call wi= ll end on Wednesday 02
> August 2006 at 2359 UTC."
>
> A= nyway, my sense is not to take Mesh issue at this stage. As long as
>= we are looking at the 6lowpan solution format, mesh is out of scope of > that. In fact, as far as I am concern, mesh belongs to 15.4 technolog= y
> based on MAC layer. Instead, as described in the rechartering, we will
= > go through adhoc issue based on IP layer. That's why we are here in > 6lowpan wg of ietf.
>
> But, some staffs described in y= our mail seem helpful from the 6lowpan
> perspective, especially IPv6= related stuffs. If allowed, please bring
> your concern to the next = 6lowpan face-to-face meeting in San Diego.
> Then, we will have furt= her details in there I believe...
>
> --
>
> > Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, S= AMSUNG Electronics.
>
>
>
> On 9/21/06, David Cu= ller <david.culler@gmail.com> wrote:
> > De= ar All,
> >
> > I would like to raise a concern about t= he Mesh Delivery Field
> > definition in Section 11 of the format document.  While the actual
> > mesh routing protocol i= s appropriately outside the scope of the
> > 6lowpan Format docum= ent, that format needs provide the raw structure
> > upon which ro= ugh consensus and running code can be flourish.  We
> > = know that low power wireless mesh routing is technically tricky and
>= ; > strongly influenced by target traffic load, power management profile= ,
> > network design, and so on.  Thus, it is reasonable= to expect that the
> > consensus building and technical refinemen= t process will require
> > on-going experience with protocol and = implementation alternatives.
> > The 6lowpan format document shoul= d support this process, although it
> > should not dictate its con= clusion.
> >
> > Based on past experience with IP layer = 3 routing and with past
> > internally routed links, we can establ= ish a few primary goals for the
> > expressiveness of the 6lowpan Mesh Deli= very Field.
> >    (1) It should support the = visibility into the routed 15.4 cloud
> > necessary to develop, de= bug, diagnose, and manage the 15.4 cloud.
> >   &nb= sp;(2) It should support the ability to define, develop and compare
>= ; > routing protocols and possibly support the presence of multiple
&= gt; > protocols for widely differing usage cases.
> > &nbs= p;  (3) It needs to be possible for nodes to communicate with oth= er nodes
> > in the cloud in order to discover and negotiate join= ing the cloud
> > without joining the cloud a priori through some = mechanism that is
> > opaque to IP and above.
> >
>= > (1) has historically been addressed through various forms of source <= BR>> > routing.  It should be possible to do the equivalent= of traceroute
> > through the 15.4 mesh and this should be accessibl= e in some form through IP
> > so
> > higher layers can be= built to perform the management.  The current
> > Mesh= Delivery Field definition seems to prohibit any form of source routing.> > It assumes that the routing tables are all set up and correct so= that
> > the forwarder can "swizzle" the destination address fiel= d of the 15.4
> > header with a table entry.  (The exper= ience of IP over ATM and the
> > thousands of pages of the Q83b si= gnalling protocol required to set up
> > all the tables in advance= ought to give us a little pause here.)  The
> > idea o= f supporting table-driven routing and thereby separating the
> > r= oute formation from the forwarding engine is a good one, but there
> = > needs to be enough expressive power to support the protocols that will=
> > establish and manage those tables (rather than relying on an opaque> > out-of-band signaling mechanism) and there needs to be the abil= ity to
> > query and validate those tables without relying on out-= of-band
> > mechanisms.
> >
> > (2) has histori= cally be addressed with protocol identifiers and
> > options. = ; As we went through the various RIP, OSPF, etc. we didn't
> >= ; need to go back and redefine the format documents.  There was e= nough
> > expressiveness for topology formation and routing to ev= olve.  Not all
> > networks need to support all protocol= s.  That has been the network
> > designers' determinati= on.  The underlying structure provided the
> > primitiv= es, allowing solutions (and consensus) to evolve.  We want to
= > > avoid creating a "winner take all" structure where there is no ro= om
> > for evolution and development.  It is possible that AODV, o= r TinyAODV,
> > or DSR, or GPSR or possibly one of several other = alternatives is the right
> > solution.  However, there = is little evidence of one having clear superiority
> > at
> = > this time, despite numerous high profile efforts.  We should= be defining the
> > canvas upon which competing alternatives can= be defined and vetted.
> >
> > (3) has historically been= addressed by a limited ability to
> > communicate on the link to = a crudely defined set of nodes in order to
> > bootstrap the disc= overy, join, address assignment, negotiation, etc.
> > Most succes= sful links under IP look either like a broadcast medium or
> > a p= oint-to-point link (a degenerative broadcast).  This allows ARP, =
> > RARP, BOOTP, DHCP, etc. to gain higher level accessibility an= d
> > addressibility through the link.  Links that require comple= x
> > signaling, discovery, joining and coordnation below the link= layer,
> > including ATM, Bluetooth (piconets and scatter nets),= and IRDA have
> > proved onerous for IP and have been relegated t= o far less general
> > usage scenarios - such as the desktop USB r= eplacement.  Even though
> > the radio is a broadcast m= edium, the challenge in a routed link is
> > that the link is not = by default a link-wide broadcast phy.  There
> > are two= natural notions of "broadcast" in a lowpan.  (i) The physical > > neighbors that happen to receive a transmission because they ar= e close
> > enough to pick up the signal and have their radios tur= ned on to
> > receive.  (ii) The entire collection of no= des that can be reached by a
> > multihop dissemination (flood).  Both of these are extremely useful in
> > boo= tstrapping higher levels, including routing, and should be
> > add= ressed in the format document.  Additionally, it is not
> = > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over=
> > a 15.4 link.  Providing some forms of broadcast usi= ng data frames
> > makes the 802.15.4 format much more like 802.11= and other links that
> > have proved very suitable for IP. &= nbsp;Few, if any, of the public 15.4 routing
> > layers developed<= BR>> > by the TinyOS community utilize beacon packets.
> >>rotocol required to set up
> > all the tables in advance= ought to give us a little pause here.)  The
> > idea o= f supporting table-driven routing and thereby separating the
> > r= oute formation from the forwarding engine is a good one, but there
> = > needs to be enough expressive power to support the protocols that will=
> > establish and manage those tables (rather than relying on an opaque> > out-of-band signaling mechanism) and there needs to be the abil= ity to
> > query and validate those tables without relying on out-= of-band
> > mechanisms.
> >
> > (2) has histori= cally be addressed with protocol identifiers and
> > options. = ; As we went through the various RIP, OSPF, etc. we didn't
> >= ; need to go back and redefine the format documents.  There was e= nough
> > expressiveness for topology formation and routing to ev= olve.  Not all
> > networks need to support all protocol= s.  That has been the network
> > designers' determinati= on.  The underlying structure provided the
> > primitiv= es, allowing solutions (and consensus) to evolve.  We want to
= > > avoid creating a "winner take all" structure where there is no ro= om
> > for evolution and development.  It is possible that AODV, o= r TinyAODV,
> > or DSR, or GPSR or possibly one of several other = alternatives is the right
> > solution.  However, there = is little evidence of one having clear superiority
> > at
> = > this time, despite numerous high profile efforts.  We should= be defining the
> > canvas upon which competing alternatives can= be defined and vetted.
> >
> > (3) has historically been= addressed by a limited ability to
> > communicate on the link to = a crudely defined set of nodes in order to
> > bootstrap the disc= overy, join, address assignment, negotiation, etc.
> > Most succes= sful links under IP look either like a broadcast medium or
> > a p= oint-to-point link (a degenerative broadcast).  This allows ARP, =
> > RARP, BOOTP, DHCP, etc. to gain higher level accessibility an= d
> > addressibility through the link.  Links that require comple= x
> > signaling, discovery, joining and coordnation below the link= layer,
> > including ATM, Bluetooth (piconets and scatter nets),= and IRDA have
> > proved onerous for IP and have been relegated t= o far less general
> > usage scenarios - such as the desktop USB r= eplacement.  Even though
> > the radio is a broadcast m= edium, the challenge in a routed link is
> > that the link is not = by default a link-wide broadcast phy.  There
> > are two= natural notions of "broadcast" in a lowpan.  (i) The physical > > neighbors that happen to receive a transmission because they ar= e close
> > enough to pick up the signal and have their radios tur= ned on to
> > receive.  (ii) The entire collection of no= des that can be reached by a
> > multihop dissemination (flood).  Both of these are extremely useful in
> > boo= tstrapping higher levels, including routing, and should be
> > add= ressed in the format document.  Additionally, it is not
> = > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over=
> > a 15.4 link.  Providing some forms of broadcast usi= ng data frames
> > makes the 802.15.4 format much more like 802.11= and other links that
> > have proved very suitable for IP. &= nbsp;Few, if any, of the public 15.4 routing
> > layers developed<= BR>> > by the TinyOS community utilize beacon packets.
> >> > The recognition that the current Mesh Delivery field may be to = restrictive
> > is intimated by the need to define a second form = of the header for
> > multicast (and link local broadcast) that in= cludes a sequence number.
> > The mesh header field type is define= d by whether the destination
> > address is unicast or multicast. The documen= t states that the use of
> > such a sequence number is out of scop= e. However, the observation that
> > that extra information may ne= ed to be included depending on how
> > packets are routed further= suggests that more careful format
> > definition is needed to sup= port future development of mesh routing.
> >
> > Have fol= ks who have been developing mesh layers for lowpan6 felt that
> >= the existing Mesh Delivery Field is too restrictive?
> >
> = >
> > David E. Culler
> > UC Berkeley
> > culler@cs.berkeley.edu
> >
> >
> &g= t;
> >
> > ______________________________________________= _
> > 6lowpan mailing list
> > 6lowpan@ietf.org
> > https://www1.ietf.org/mailman/listinfo/6lowpan > >
> >
> >
>
> ____________________= ___________________________
> 6lowpan mailing list
> 6lo= wpan@ietf.org
> https://www1.ietf.o= rg/mailman/listinfo/6lowpan


_______________________________= ________________
6lowpan mailing list
6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6low= pan

 

_______________________= ________________________
6lowpan mailing list
6lowpan@ietf.or= g
https://www1.ietf.org/mailman/listin= fo/6lowpan





--
Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8= =B5=B7=E4=BA=A8)
Associate Professor
Division of Information and Comp= uter Eng., Ajou University, Suwon, Korea 442-749
Tel: +82-31-219-2433, C= el: +82-17-760-2551,  Fax: +82-31-219-2433 http://www.6low= pan.org



--
David = E. Culler
Arched Rock Corporation
2168 Shattuck Ave
Berkeley, CA 94704
www.archedrock.com

 



--
Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8= =B5=B7=E4=BA=A8)
Associate Professor
Division of Information and Comp= uter Eng., Ajou University, Suwon, Korea 442-749
Tel: +82-31-219-2433, = Cel: +82-17-760-2551,  Fax: +82-31-219-2433 http://www.6; > The recognition that the current Mesh Delivery field may be to = restrictive
> > is intimated by the need to define a second form = of the header for
> > multicast (and link local broadcast) that in= cludes a sequence number.
> > The mesh header field type is define= d by whether the destination
> > address is unicast or multicast. The documen= t states that the use of
> > such a sequence number is out of scop= e. However, the observation that
> > that extra information may ne= ed to be included depending on how
> > packets are routed further= suggests that more careful format
> > definition is needed to sup= port future development of mesh routing.
> >
> > Have fol= ks who have been developing mesh layers for lowpan6 felt that
> >= the existing Mesh Delivery Field is too restrictive?
> >
> = >
> > David E. Culler
> > UC Berkeley
> > culler@cs.berkeley.edu
> >
> >
> &g= t;
> >
> > ______________________________________________= _
> > 6lowpan mailing list
> > 6lowpan@ietf.org
> > https://www1.ietf.org/mailman/listinfo/6lowpan > >
> >
> >
>
> ____________________= ___________________________
> 6lowpan mailing list
> 6lo= wpan@ietf.org
> https://www1.ietf.o= rg/mailman/listinfo/6lowpan


_______________________________= ________________
6lowpan mailing list
6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6low= pan

 

_______________________= ________________________
6lowpan mailing list
6lowpan@ietf.or= g
https://www1.ietf.org/mailman/listin= fo/6lowpan





--
Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8= =B5=B7=E4=BA=A8)
Associate Professor
Division of Information and Comp= uter Eng., Ajou University, Suwon, Korea 442-749
Tel: +82-31-219-2433, C= el: +82-17-760-2551,  Fax: +82-31-219-2433 http://www.6low= pan.org



--
David = E. Culler
Arched Rock Corporation
2168 Shattuck Ave
Berkeley, CA 94704
www.archedrock.com

 



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

--0-1262425063-1159582610=:47488-- --===============0192960026== 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 --===============0192960026==-- From 6lowpan-bounces@ietf.org Sat Sep 30 12:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThrX-0003VS-Sx; Sat, 30 Sep 2006 12:38:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTPay-00047R-43 for 6lowpan@ietf.org; Fri, 29 Sep 2006 17:08:32 -0400 Received: from web81915.mail.mud.yahoo.com ([68.142.207.63]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GTPav-00056q-C6 for 6lowpan@ietf.org; Fri, 29 Sep 2006 17:08:32 -0400 Received: (qmail 32997 invoked by uid 60001); 29 Sep 2006 21:08:29 -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=N07khbmMpCwTmfPF9OTrZBoD/WGgwbhhzMj5jI+PdCTtwowndNuMqrjGd7h7/hrRJXuDWhcWjrHMV0GhA9XtSamuLi3gBKVYyDcT4lCEvzt1YMHrVUiR5lngFeiB/MWfxy8jA3hXyPqO6/pR0ATKlEquLommWpJBebkMMyq+RGs= ; Message-ID: <20060929210828.32995.qmail@web81915.mail.mud.yahoo.com> Received: from [24.16.14.130] by web81915.mail.mud.yahoo.com via HTTP; Fri, 29 Sep 2006 14:08:28 PDT Date: Fri, 29 Sep 2006 14:08:28 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Mesh Delivery Field To: David Culler , Ki-Hyung Kim In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: ed7d9c7c8d25b2053aac33a860e1606d X-Mailman-Approved-At: Sat, 30 Sep 2006 12:38:50 -0400 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="===============0593245853==" Errors-To: 6lowpan-bounces@ietf.org --===============0593245853== Content-Type: multipart/alternative; boundary="0-1752865851-1159564108=:27872" --0-1752865851-1159564108=:27872 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok, it seems like folks would like to have more flexibility in the header. = I'm just having a hard time translating that to actual bits and bytes within the header formats, and how much flexibilit= y is fine.=20 =20 The first packet format has 5 bits of reserved 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: LoWPAN unfragmented encapsulation header format One bit out of that reserved field is what Mario Mao suggests we use to dis= tinguish between the two current flavors of mesh delivery header (unicast vs bcast/mcast). Is this sufficient flexib= ility? =20 The issue is that there is no such flexibility in the two other header form= ats, but we can certainly add such a=20 reselo= wpan.org

--0-1262425063-1159582610=:47488-- --===============0192960026== 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 --===============0192960026==-- From 6lowpan-bounces@ietf.org Sat Sep 30 12:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThrX-0003VS-Sx; Sat, 30 Sep 2006 12:38:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTPay-00047R-43 for 6lowpan@ietf.org; Fri, 29 Sep 2006 17:08:32 -0400 Received: from web81915.mail.mud.yahoo.com ([68.142.207.63]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GTPav-00056q-C6 for 6lowpan@ietf.org; Fri, 29 Sep 2006 17:08:32 -0400 Received: (qmail 32997 invoked by uid 60001); 29 Sep 2006 21:08:29 -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=N07khbmMpCwTmfPF9OTrZBoD/WGgwbhhzMj5jI+PdCTtwowndNuMqrjGd7h7/hrRJXuDWhcWjrHMV0GhA9XtSamuLi3gBKVYyDcT4lCEvzt1YMHrVUiR5lngFeiB/MWfxy8jA3hXyPqO6/pR0ATKlEquLommWpJBebkMMyq+RGs= ; Message-ID: <20060929210828.32995.qmail@web81915.mail.mud.yahoo.com> Received: from [24.16.14.130] by web81915.mail.mud.yahoo.com via HTTP; Fri, 29 Sep 2006 14:08:28 PDT Date: Fri, 29 Sep 2006 14:08:28 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Mesh Delivery Field To: David Culler , Ki-Hyung Kim In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: ed7d9c7c8d25b2053aac33a860e1606d X-Mailman-Approved-At: Sat, 30 Sep 2006 12:38:50 -0400 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="===============0593245853==" Errors-To: 6lowpan-bounces@ietf.org --===============0593245853== Content-Type: multipart/alternative; boundary="0-1752865851-1159564108=:27872" --0-1752865851-1159564108=:27872 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok, it seems like folks would like to have more flexibility in the header. = I'm just having a hard time translating that to actual bits and bytes within the header formats, and how much flexibilit= y is fine.=20 =20 The first packet format has 5 bits of reserved 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: LoWPAN unfragmented encapsulation header format One bit out of that reserved field is what Mario Mao suggests we use to dis= tinguish between the two current flavors of mesh delivery header (unicast vs bcast/mcast). Is this sufficient flexib= ility? =20 The issue is that there is no such flexibility in the two other header form= ats, but we can certainly add such a=20 reserved field and make all 3 header formats the same up to the first 16 bi= ts. Perhaps along these lines (notice the new "reserved" field and the corresponding 5 bit shift for data= gram_size and datagram_tag) : =20 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|reserved | datagram_size |dgram_tag| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |dgram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 2: LoWPAN first fragment encapsulation header format =20 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|reserved | datagram_size |dgram_tag| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |dgram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: LoWPAN subsequent fragment(s) encapsulation header format =20 =20 Would this be enough? If not, how many bits should be allocated? Should the= re be a version field in addition=20 (as suggested by Vipul a while back)? What changes in the format are sugges= ted? Folks, please be specific as to the suggested changes by sending header formats with clearly proposed= fields, etc. =20 tnx, =20 -gabriel ----- Original Message ---- From: David Culler To: Ki-Hyung Kim Cc: gabriel montenegro ; Geoff Mulligan = ; Soohong Daniel Park ; 6lowpan@iet= f.org Sent: Friday, September 29, 2006 8:38:56 AM Subject: Re: [6lowpan] Mesh Delivery Field It certainly would be a shame to get into a position where the encoding is = so so constrained that there was not a means of accomodating additional cap= abilities that are revealed through deeper implementation and usage experie= nce. The IP community has historically been very good at planning for chan= ge. Options fields and leaving a little room in the initial encodings are = essential to that. As much as we try, we seldom get every aspect of the pr= otocol exactly right the first time. It is understandable that with so muc= h focus being place on header compression that it is hard to leave any spac= e unclaimed. However, that contingency planning and flexibility may be mor= e critical to eventual adoption than squeezing out every unneccessary bit. = As we look at the desired "rush to finish" it is important to verify that= the proposed framework permits enough expressive power to address the issu= es that have not yet been fully vetted. You cannot expand the format, only= work within it.=20 On 9/26/06, Ki-Hyung Kim wrote:=20 Gabriel, =20 I am sorry for this late reply. Basically, I agree that current format document is rather tightly scheduled= and not well prepared for future enhancements or revisions, in terms of ro= uting, diagnoses, management, etc. Based on the assumption that we are not = yet in the stage of pursuing future rechartering items, it might not be the= right time to consider all the cases at one time. Also, we should be in ru= sh to finish the current format document ASAP for moving forward into next = stage before next IETF meeting.=20 =20 Regarding the mesh delivery field, Mario Mao's approach should be fine, and= other approaches (like option 2,3, and 4) might be OK. However, it seems l= ike we are trying too much to make the format compact while not considering= the future expansions.=20 =20 After all, my opinion is option 1. Let's have one byte for the multicast bi= t and the reserved fields for future. having additional one byte for this is not a big deal in terms of packrved field and make all 3 header formats the same up to the first 16 bi= ts. Perhaps along these lines (notice the new "reserved" field and the corresponding 5 bit shift for data= gram_size and datagram_tag) : =20 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|reserved | datagram_size |dgram_tag| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |dgram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 2: LoWPAN first fragment encapsulation header format =20 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|reserved | datagram_size |dgram_tag| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |dgram_tag| Payload (or Mesh Delivery Hdr)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: LoWPAN subsequent fragment(s) encapsulation header format =20 =20 Would this be enough? If not, how many bits should be allocated? Should the= re be a version field in addition=20 (as suggested by Vipul a while back)? What changes in the format are sugges= ted? Folks, please be specific as to the suggested changes by sending header formats with clearly proposed= fields, etc. =20 tnx, =20 -gabriel ----- Original Message ---- From: David Culler To: Ki-Hyung Kim Cc: gabriel montenegro ; Geoff Mulligan = ; Soohong Daniel Park ; 6lowpan@iet= f.org Sent: Friday, September 29, 2006 8:38:56 AM Subject: Re: [6lowpan] Mesh Delivery Field It certainly would be a shame to get into a position where the encoding is = so so constrained that there was not a means of accomodating additional cap= abilities that are revealed through deeper implementation and usage experie= nce. The IP community has historically been very good at planning for chan= ge. Options fields and leaving a little room in the initial encodings are = essential to that. As much as we try, we seldom get every aspect of the pr= otocol exactly right the first time. It is understandable that with so muc= h focus being place on header compression that it is hard to leave any spac= e unclaimed. However, that contingency planning and flexibility may be mor= e critical to eventual adoption than squeezing out every unneccessary bit. = As we look at the desired "rush to finish" it is important to verify that= the proposed framework permits enough expressive power to address the issu= es that have not yet been fully vetted. You cannot expand the format, only= work within it.=20 On 9/26/06, Ki-Hyung Kim wrote:=20 Gabriel, =20 I am sorry for this late reply. Basically, I agree that current format document is rather tightly scheduled= and not well prepared for future enhancements or revisions, in terms of ro= uting, diagnoses, management, etc. Based on the assumption that we are not = yet in the stage of pursuing future rechartering items, it might not be the= right time to consider all the cases at one time. Also, we should be in ru= sh to finish the current format document ASAP for moving forward into next = stage before next IETF meeting.=20 =20 Regarding the mesh delivery field, Mario Mao's approach should be fine, and= other approaches (like option 2,3, and 4) might be OK. However, it seems l= ike we are trying too much to make the format compact while not considering= the future expansions.=20 =20 After all, my opinion is option 1. Let's have one byte for the multicast bi= t and the reserved fields for future. having additional one byte for this is not a big deal in terms of packet si= ze and won't add much complexity for handling it. Examples of utilizing some reserved fields might be follows: 1. Based on the assumption that 6lowpan supports multiple routing protocols= such as LOAD, DYMO-low, HiLow, DSR, or whatever, etc., the field might be= used for indicating which specific routing protocol should be used for rou= ting this particular packet. It might be argued whether the format document= should support multiple protocols at a time. However, those kind of argue = should be debated later while considering routing protocols without elimina= ting future possible necessity.=20 2. Routing protocols could be optimzed by having some option fields, while = it might not be right time to specifically mention them. =20 I remember that the issue of the mesh underneath or above IP has been raise= d several times in the WG. I think it might not be right time considering i= t again right now. =20 If you have any other opinions, please let me know. =20 On 9/23/06, gabriel montenegro < gabriel_montenegro_2000@yahoo.com> wrote:= =20 First of all, Thanks David for your thoughtful message. It's great to see y= ou participate in this forum and I hope you'll stick around! =20 >From the point of view of laying the technology foundation, everything in y= our message is quite relevant. >From the point of view of WG management, I'm trying to figure out if we nee= d to act on all of it right now or if there are things we can address independently of the format draft und= er discussion. For example, you bring up the topic of traceroute type functionality. In IP, this is car= ried over ICMP, a separate=20 management control plane. Since what we have in the format draft is a multi= plexing layer, we can=20 define a new protocol value to carry out the management protocol packets. T= he question is if the current format provides the required mechanism to go do work on such a sepa= rate protocol in another draft. Intuitively, it seems like this would work. Someone (your= group, David?) could define such a protocol with functionality similar to ICMP for pings, tracer= oute, etc and provide the route gathering functionality, the echo response, etc in that separate = draft. Conceivably, it would not necessarily use the mesh delivery header, as it would provide its= own facility to record hop-by-hop route information within its own protocol fields. It coul= d use loose source routing in which case some use of the mesh delivery header might be appropr= iate as well. Would such an approach work, David? This would actually play into one of th= e items slated for the next round of 6lowpan (if we ever recharter) to strengthen diagnosabili= ty or management of these networks. =20 As for your point about us not knowing exactly what the header format must = look like at this point in time, this is perhaps something we need to take into consideration right no= w. For example, this input would push us into reserving at least a couple of bits in the header = for future expansion. A while back Vipul was arguing for a "version" field. Not sure if such a field is r= equired or if the current reserved fields are enough. Mario Mao's proposal uses one of those reserved bits to = solve the issue under discussion regarding the mesh delivery header variants for unicast vs mcast= /bcast. There has been=20 one group expressing support for this, so perhaps we already have the neces= sary mechanism in place in the header. =20 David, you also mention the need to support different routing protocols sid= e-by-side for comparison. This is one of the design goals of the format document. As I mentioned, the= protocol field allows one to carry different protocols. We currently have proposals for a 6lowpan ada= ptations of AODV, a DyMO and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps BVR is = next. The point is that the format document does provide the mechanism to define any such protocol,= or is there a limitation you can see in the current document? If so, what needs to change? =20 As for the claim that sub-IP benefits from simet si= ze and won't add much complexity for handling it. Examples of utilizing some reserved fields might be follows: 1. Based on the assumption that 6lowpan supports multiple routing protocols= such as LOAD, DYMO-low, HiLow, DSR, or whatever, etc., the field might be= used for indicating which specific routing protocol should be used for rou= ting this particular packet. It might be argued whether the format document= should support multiple protocols at a time. However, those kind of argue = should be debated later while considering routing protocols without elimina= ting future possible necessity.=20 2. Routing protocols could be optimzed by having some option fields, while = it might not be right time to specifically mention them. =20 I remember that the issue of the mesh underneath or above IP has been raise= d several times in the WG. I think it might not be right time considering i= t again right now. =20 If you have any other opinions, please let me know. =20 On 9/23/06, gabriel montenegro < gabriel_montenegro_2000@yahoo.com> wrote:= =20 First of all, Thanks David for your thoughtful message. It's great to see y= ou participate in this forum and I hope you'll stick around! =20 >From the point of view of laying the technology foundation, everything in y= our message is quite relevant. >From the point of view of WG management, I'm trying to figure out if we nee= d to act on all of it right now or if there are things we can address independently of the format draft und= er discussion. For example, you bring up the topic of traceroute type functionality. In IP, this is car= ried over ICMP, a separate=20 management control plane. Since what we have in the format draft is a multi= plexing layer, we can=20 define a new protocol value to carry out the management protocol packets. T= he question is if the current format provides the required mechanism to go do work on such a sepa= rate protocol in another draft. Intuitively, it seems like this would work. Someone (your= group, David?) could define such a protocol with functionality similar to ICMP for pings, tracer= oute, etc and provide the route gathering functionality, the echo response, etc in that separate = draft. Conceivably, it would not necessarily use the mesh delivery header, as it would provide its= own facility to record hop-by-hop route information within its own protocol fields. It coul= d use loose source routing in which case some use of the mesh delivery header might be appropr= iate as well. Would such an approach work, David? This would actually play into one of th= e items slated for the next round of 6lowpan (if we ever recharter) to strengthen diagnosabili= ty or management of these networks. =20 As for your point about us not knowing exactly what the header format must = look like at this point in time, this is perhaps something we need to take into consideration right no= w. For example, this input would push us into reserving at least a couple of bits in the header = for future expansion. A while back Vipul was arguing for a "version" field. Not sure if such a field is r= equired or if the current reserved fields are enough. Mario Mao's proposal uses one of those reserved bits to = solve the issue under discussion regarding the mesh delivery header variants for unicast vs mcast= /bcast. There has been=20 one group expressing support for this, so perhaps we already have the neces= sary mechanism in place in the header. =20 David, you also mention the need to support different routing protocols sid= e-by-side for comparison. This is one of the design goals of the format document. As I mentioned, the= protocol field allows one to carry different protocols. We currently have proposals for a 6lowpan ada= ptations of AODV, a DyMO and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps BVR is = next. The point is that the format document does provide the mechanism to define any such protocol,= or is there a limitation you can see in the current document? If so, what needs to change? =20 As for the claim that sub-IP benefits from simpler structures, my interpret= ation is that you're suggesting it=20 is better not to use the mesh delivery header and let IP deal with the unde= rlying individual collection of links. If so, one can ignore the mesh delivery header (not use it) and use the oth= er parts of the format document to simply layer IP on top. This approach would then make use of other activiti= es like AUTOCONF or MANET to create meshes if so desired. Personally, I see that *if* one wishes to = do a mesh, not doing it in the sub-IP layer just pushes to problem upwards into the IP routing realm, and this ju= st makes things even more complex than doing it under sub-IP. Complexity will be there no matter what, it's j= ust a question of where one wants to address it. I do note that sub-IP complex structures are very popular and d= eployed in some cases (802.1d bridged networks). Perhaps likely to become even more so with 802.11s within a few = years. =20 I would not be interested in pursuing an AUTOCONF path, but think it should be possible to do so for those so inclined. Does this sound doable? Again, = my immediate concern is that the format document not prevent this approach.=20 =20 -gabriel =20 ----- Original Message ---- From: Geoff Mulligan < geoff@mulligan.com> To: Soohong Daniel Park Cc: 6lowpan@ietf.org; David Culler Sent: Friday, September 22, 2006 6:41:21 AM=20 Subject: Re: [6lowpan] Mesh Delivery Field Daniel, While the WG last call did expire, I'm not sure if David is too late. I think that he raises some important concerns and I'm not sure that we really have consensus on the mesh delivery field. I would like to hear from the list on this. I think that Gabriel has put forth 4 alternatives. Carsten indicated that he thought he might have a different alternative and would post to the list either the alternative or his consideration of the 4 alternatives - Carsten, please=20 send your thoughts. I feel that the issue David raises should be dealt with by the WG because I do not want to send the draft on to the IESG only to have these issues brought up in the IETF last call. These seem rather=20 fundamental to me and we might look rather foolish not having resolved this in the working group! We need some significant discussion from the members of the WG. This WG has been, my self included, rather quiet and as a result we have moved=20 at a snails pace getting anything done. I implore everyone to take time and read the thread on the mesh field and send your thoughts, pro, con or otherwise to this list. If everyone continues to be apathetic about=20 this work, I hold little hope for this WG being rechartered to do any other work! geoff On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote: > David, >=20 > First off, your issue raising in this thread seems too late since our=20 > official WGLC was expired: "This Last Call will end on Wednesday 02 > August 2006 at 2359 UTC." >=20 > Anyway, my sense is not to take Mesh issue at this stage. As long as > we are looking at the 6lowpan solution format, mesh is out of scope of=20 > that. In fact, as far as I am concern, mesh belongs to 15.4 technology > based on MAC layer. Instead, as described in the rechartering, we will > go through adhoc issue based on IP layer. That's why we are here in=20 > 6lowpan wg of ietf. >=20 > But, some staffs described in your mail seem helpful from the 6lowpan > perspective, especially IPv6 related stuffs. If allowed, please bring > your concern to the next 6lowpan face-to-face meeting in San Diego.=20 > Then, we will have further details in there I believe... >=20 > --=20 >=20 >=20 > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. >=20 >=20 >=20 > On 9/21/06, David Culler wrote: > > Dear All, > >=20 > > I would like to raise a concern about the Mesh Delivery Field > > definition in Section 11 of the format document. While the actual > > mesh routing protocol is appropriately outside the scope of the=20 > > 6lowpan Format document, thapler structures, my interpret= ation is that you're suggesting it=20 is better not to use the mesh delivery header and let IP deal with the unde= rlying individual collection of links. If so, one can ignore the mesh delivery header (not use it) and use the oth= er parts of the format document to simply layer IP on top. This approach would then make use of other activiti= es like AUTOCONF or MANET to create meshes if so desired. Personally, I see that *if* one wishes to = do a mesh, not doing it in the sub-IP layer just pushes to problem upwards into the IP routing realm, and this ju= st makes things even more complex than doing it under sub-IP. Complexity will be there no matter what, it's j= ust a question of where one wants to address it. I do note that sub-IP complex structures are very popular and d= eployed in some cases (802.1d bridged networks). Perhaps likely to become even more so with 802.11s within a few = years. =20 I would not be interested in pursuing an AUTOCONF path, but think it should be possible to do so for those so inclined. Does this sound doable? Again, = my immediate concern is that the format document not prevent this approach.=20 =20 -gabriel =20 ----- Original Message ---- From: Geoff Mulligan < geoff@mulligan.com> To: Soohong Daniel Park Cc: 6lowpan@ietf.org; David Culler Sent: Friday, September 22, 2006 6:41:21 AM=20 Subject: Re: [6lowpan] Mesh Delivery Field Daniel, While the WG last call did expire, I'm not sure if David is too late. I think that he raises some important concerns and I'm not sure that we really have consensus on the mesh delivery field. I would like to hear from the list on this. I think that Gabriel has put forth 4 alternatives. Carsten indicated that he thought he might have a different alternative and would post to the list either the alternative or his consideration of the 4 alternatives - Carsten, please=20 send your thoughts. I feel that the issue David raises should be dealt with by the WG because I do not want to send the draft on to the IESG only to have these issues brought up in the IETF last call. These seem rather=20 fundamental to me and we might look rather foolish not having resolved this in the working group! We need some significant discussion from the members of the WG. This WG has been, my self included, rather quiet and as a result we have moved=20 at a snails pace getting anything done. I implore everyone to take time and read the thread on the mesh field and send your thoughts, pro, con or otherwise to this list. If everyone continues to be apathetic about=20 this work, I hold little hope for this WG being rechartered to do any other work! geoff On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote: > David, >=20 > First off, your issue raising in this thread seems too late since our=20 > official WGLC was expired: "This Last Call will end on Wednesday 02 > August 2006 at 2359 UTC." >=20 > Anyway, my sense is not to take Mesh issue at this stage. As long as > we are looking at the 6lowpan solution format, mesh is out of scope of=20 > that. In fact, as far as I am concern, mesh belongs to 15.4 technology > based on MAC layer. Instead, as described in the rechartering, we will > go through adhoc issue based on IP layer. That's why we are here in=20 > 6lowpan wg of ietf. >=20 > But, some staffs described in your mail seem helpful from the 6lowpan > perspective, especially IPv6 related stuffs. If allowed, please bring > your concern to the next 6lowpan face-to-face meeting in San Diego.=20 > Then, we will have further details in there I believe... >=20 > --=20 >=20 >=20 > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. >=20 >=20 >=20 > On 9/21/06, David Culler wrote: > > Dear All, > >=20 > > I would like to raise a concern about the Mesh Delivery Field > > definition in Section 11 of the format document. While the actual > > mesh routing protocol is appropriately outside the scope of the=20 > > 6lowpan Format document, that format needs provide the raw structure > > upon which rough consensus and running code can be flourish. We > > know that low power wireless mesh routing is technically tricky and=20 > > strongly influenced by target traffic load, power management profile, > > network design, and so on. Thus, it is reasonable to expect that the > > consensus building and technical refinement process will require=20 > > on-going experience with protocol and implementation alternatives. > > The 6lowpan format document should support this process, although it > > should not dictate its conclusion. > >=20 > > Based on past experience with IP layer 3 routing and with past > > internally routed links, we can establish a few primary goals for the > > expressiveness of the 6lowpan Mesh Delivery Field.=20 > > (1) It should support the visibility into the routed 15.4 cloud > > necessary to develop, debug, diagnose, and manage the 15.4 cloud. > > (2) It should support the ability to define, develop and compare=20 > > routing protocols and possibly support the presence of multiple > > protocols for widely differing usage cases. > > (3) It needs to be possible for nodes to communicate with other node= s=20 > > in the cloud in order to discover and negotiate joining the cloud > > without joining the cloud a priori through some mechanism that is > > opaque to IP and above. > > > > (1) has historically been addressed through various forms of source=20 > > routing. It should be possible to do the equivalent of traceroute > > through the 15.4 mesh and this should be accessible in some form throug= h IP > > so > > higher layers can be built to perform the management. The current=20 > > Mesh Delivery Field definition seems to prohibit any form of source rou= ting. > > It assumes that the routing tables are all set up and correct so that > > the forwarder can "swizzle" the destination address field of the 15.4 > > header with a table entry. (The experience of IP over ATM and the > > thousands of pages of the Q83b signalling protocol required to set up > > all the tables in advance ought to give us a little pause here.) The= =20 > > idea of supporting table-driven routing and thereby separating the > > route formation from the forwarding engine is a good one, but there > > needs to be enough expressive power to support the protocols that will= =20 > > establish and manage those tables (rather than relying on an opaque > > out-of-band signaling mechanism) and there needs to be the ability to > > query and validate those tables without relying on out-of-band=20 > > mechanisms. > > > > (2) has historically be addressed with protocol identifiers and > > options. As we went through the various RIP, OSPF, etc. we didn't > > need to go back and redefine the format documents. There was enough=20 > > expressiveness for topology formation and routing to evolve. Not all > > networks need to support all protocols. That has been the network > > designers' determination. The underlying structure provided the=20 > > primitives, allowing solutions (and consensus) to evolve. We want to > > avoid creating a "winner take all" structure where there is no room > > for evolution and development. It is possible that AODV, or TinyAODV,= =20 > > or DSR, or GPSR or possibly one of several other alternatives is the ri= ght > > solution. However, there is little evidence of one having clear superi= ority > > at > > this time, despite numerous high profile efforts. We should be definin= g the=20 > > canvas upon which competing alternatives can be defined and vetted. > > > > (3) has historically been addressed by a limited ability to > > communicate on the link to a crudely defined set of nodes in order to= =20 > > bootstrap the discovery, join, address assignment, negotiation, etc. > > Most successful links under IP look either like a broadcast medium or > > a point-to-point link (a degenerative broadcast). This allows ARP,=20 > > RARP, BOOTP, DHCP, etc. to gain higher level accessibility and > > addressibility through the link. Links that require complex > > st format needs provide the raw structure > > upon which rough consensus and running code can be flourish. We > > know that low power wireless mesh routing is technically tricky and=20 > > strongly influenced by target traffic load, power management profile, > > network design, and so on. Thus, it is reasonable to expect that the > > consensus building and technical refinement process will require=20 > > on-going experience with protocol and implementation alternatives. > > The 6lowpan format document should support this process, although it > > should not dictate its conclusion. > >=20 > > Based on past experience with IP layer 3 routing and with past > > internally routed links, we can establish a few primary goals for the > > expressiveness of the 6lowpan Mesh Delivery Field.=20 > > (1) It should support the visibility into the routed 15.4 cloud > > necessary to develop, debug, diagnose, and manage the 15.4 cloud. > > (2) It should support the ability to define, develop and compare=20 > > routing protocols and possibly support the presence of multiple > > protocols for widely differing usage cases. > > (3) It needs to be possible for nodes to communicate with other node= s=20 > > in the cloud in order to discover and negotiate joining the cloud > > without joining the cloud a priori through some mechanism that is > > opaque to IP and above. > > > > (1) has historically been addressed through various forms of source=20 > > routing. It should be possible to do the equivalent of traceroute > > through the 15.4 mesh and this should be accessible in some form throug= h IP > > so > > higher layers can be built to perform the management. The current=20 > > Mesh Delivery Field definition seems to prohibit any form of source rou= ting. > > It assumes that the routing tables are all set up and correct so that > > the forwarder can "swizzle" the destination address field of the 15.4 > > header with a table entry. (The experience of IP over ATM and the > > thousands of pages of the Q83b signalling protocol required to set up > > all the tables in advance ought to give us a little pause here.) The= =20 > > idea of supporting table-driven routing and thereby separating the > > route formation from the forwarding engine is a good one, but there > > needs to be enough expressive power to support the protocols that will= =20 > > establish and manage those tables (rather than relying on an opaque > > out-of-band signaling mechanism) and there needs to be the ability to > > query and validate those tables without relying on out-of-band=20 > > mechanisms. > > > > (2) has historically be addressed with protocol identifiers and > > options. As we went through the various RIP, OSPF, etc. we didn't > > need to go back and redefine the format documents. There was enough=20 > > expressiveness for topology formation and routing to evolve. Not all > > networks need to support all protocols. That has been the network > > designers' determination. The underlying structure provided the=20 > > primitives, allowing solutions (and consensus) to evolve. We want to > > avoid creating a "winner take all" structure where there is no room > > for evolution and development. It is possible that AODV, or TinyAODV,= =20 > > or DSR, or GPSR or possibly one of several other alternatives is the ri= ght > > solution. However, there is little evidence of one having clear superi= ority > > at > > this time, despite numerous high profile efforts. We should be definin= g the=20 > > canvas upon which competing alternatives can be defined and vetted. > > > > (3) has historically been addressed by a limited ability to > > communicate on the link to a crudely defined set of nodes in order to= =20 > > bootstrap the discovery, join, address assignment, negotiation, etc. > > Most successful links under IP look either like a broadcast medium or > > a point-to-point link (a degenerative broadcast). This allows ARP,=20 > > RARP, BOOTP, DHCP, etc. to gain higher level accessibility and > > addressibility through the link. Links that require complex > > signaling, discovery, joining and coordnation below the link layer,=20 > > including ATM, Bluetooth (piconets and scatter nets), and IRDA have > > proved onerous for IP and have been relegated to far less general > > usage scenarios - such as the desktop USB replacement. Even though=20 > > the radio is a broadcast medium, the challenge in a routed link is > > that the link is not by default a link-wide broadcast phy. There > > are two natural notions of "broadcast" in a lowpan. (i) The physical= =20 > > neighbors that happen to receive a transmission because they are close > > enough to pick up the signal and have their radios turned on to > > receive. (ii) The entire collection of nodes that can be reached by a= =20 > > multihop dissemination (flood). Both of these are extremely useful in > > bootstrapping higher levels, including routing, and should be > > addressed in the format document. Additionally, it is not=20 > > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over > > a 15.4 link. Providing some forms of broadcast using data frames > > makes the 802.15.4 format much more like 802.11 and other links that > > have proved very suitable for IP. Few, if any, of the public 15.4 rout= ing > > layers developed > > by the TinyOS community utilize beacon packets. > > > > The recognition that the current Mesh Delivery field may be to restrict= ive=20 > > is intimated by the need to define a second form of the header for > > multicast (and link local broadcast) that includes a sequence number. > > The mesh header field type is defined by whether the destination=20 > > address is unicast or multicast. The document states that the use of > > such a sequence number is out of scope. However, the observation that > > that extra information may need to be included depending on how=20 > > packets are routed further suggests that more careful format > > definition is needed to support future development of mesh routing. > > > > Have folks who have been developing mesh layers for lowpan6 felt that= =20 > > the existing Mesh Delivery Field is too restrictive? > > > > > > David E. Culler > > UC Berkeley > > culler@cs.berkeley.edu > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan > >=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 =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --=20 Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8=B5=B7=E4=BA=A8) Associate Professor Division of Information and Computer Eng., Ajou University, Suwon, Korea 44= 2-749 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 http://ww= w.6lowpan.org=20 --=20 David E. Culler Arched Rock Corporation 2168 Shattuck Ave Berkeley, CA 94704 www.archedrock.com --0-1752865851-1159564108=:27872 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ok, it seems like folks would like to have more fl= exibility in the header. I'm just having a hard time translating that
to actual bits and bytes within the header formats, and how much = flexibility is fine.
 
The first packet format has 5 bits of reserved field: > including ATM, Bluetooth (piconets and scatter nets), and IRDA have > > proved onerous for IP and have been relegated to far less general > > usage scenarios - such as the desktop USB replacement. Even though=20 > > the radio is a broadcast medium, the challenge in a routed link is > > that the link is not by default a link-wide broadcast phy. There > > are two natural notions of "broadcast" in a lowpan. (i) The physical= =20 > > neighbors that happen to receive a transmission because they are close > > enough to pick up the signal and have their radios turned on to > > receive. (ii) The entire collection of nodes that can be reached by a= =20 > > multihop dissemination (flood). Both of these are extremely useful in > > bootstrapping higher levels, including routing, and should be > > addressed in the format document. Additionally, it is not=20 > > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over > > a 15.4 link. Providing some forms of broadcast using data frames > > makes the 802.15.4 format much more like 802.11 and other links that > > have proved very suitable for IP. Few, if any, of the public 15.4 rout= ing > > layers developed > > by the TinyOS community utilize beacon packets. > > > > The recognition that the current Mesh Delivery field may be to restrict= ive=20 > > is intimated by the need to define a second form of the header for > > multicast (and link local broadcast) that includes a sequence number. > > The mesh header field type is defined by whether the destination=20 > > address is unicast or multicast. The document states that the use of > > such a sequence number is out of scope. However, the observation that > > that extra information may need to be included depending on how=20 > > packets are routed further suggests that more careful format > > definition is needed to support future development of mesh routing. > > > > Have folks who have been developing mesh layers for lowpan6 felt that= =20 > > the existing Mesh Delivery Field is too restrictive? > > > > > > David E. Culler > > UC Berkeley > > culler@cs.berkeley.edu > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan > >=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 =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --=20 Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8=B5=B7=E4=BA=A8) Associate Professor Division of Information and Computer Eng., Ajou University, Suwon, Korea 44= 2-749 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 http://ww= w.6lowpan.org=20 --=20 David E. Culler Arched Rock Corporation 2168 Shattuck Ave Berkeley, CA 94704 www.archedrock.com --0-1752865851-1159564108=:27872 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ok, it seems like folks would like to have more fl= exibility in the header. I'm just having a hard time translating that
to actual bits and bytes within the header formats, and how much = flexibility is fine.
 
The first packet format has 5 bits of reserved field:
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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
      +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    &= nbsp; | LF|  prot_type    |M| rsv   &nbs= p; |Payload (or Mesh Delivery Hdr)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

&= nbsp;        Figure 1: LoWPAN unfragment= ed encapsulation header format
One bit out of that reserved field is what Mario Mao suggest= s we use to distinguish between the two current flavors
of mesh delivery header (unicast vs bcast/mcast). Is this suffici= ent flexibility?
 
The issue is that there is no such flexibility in the two other h= eader formats, but we can certainly add such a=20
reserved field and make all 3 header formats the same up to the f= irst 16 bits. Perhaps along these lines
(notice the new "reserved" field and the corresponding 5&nbs= p;bit shift for datagram_size and datagram_tag) :
 
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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
      +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    &= nbsp; | LF|  prot_type    |M|reserved |   dat= agram_size     |dgram_tag|
    &= nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 = ;     |dgram_tag| Payload (or Mesh Delivery Hdr)...
=       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
        Figure 2: LoWPAN first fra= gment encapsulation header format
 
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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
      +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    &= nbsp; | LF|  prot_type    |M| rsv   &nbs= p; |Payload (or Mesh Delivery Hdr)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

&= nbsp;        Figure 1: LoWPAN unfragment= ed encapsulation header format
One bit out of that reserved field is what Mario Mao suggest= s we use to distinguish between the two current flavors
of mesh delivery header (unicast vs bcast/mcast). Is this suffici= ent flexibility?
 
The issue is that there is no such flexibility in the two other h= eader formats, but we can certainly add such a=20
reserved field and make all 3 header formats the same up to the f= irst 16 bits. Perhaps along these lines
(notice the new "reserved" field and the corresponding 5&nbs= p;bit shift for datagram_size and datagram_tag) :
 
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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
      +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    &= nbsp; | LF|  prot_type    |M|reserved |   dat= agram_size     |dgram_tag|
    &= nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 = ;     |dgram_tag| Payload (or Mesh Delivery Hdr)...
=       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
        Figure 2: LoWPAN first fra= gment encapsulation header format
 
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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
      +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    &= nbsp; | LF|datagram_offset|M|reserved |   datagram_size &nbs= p;   |dgram_tag|
      +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   &n= bsp;  |dgram_tag| Payload (or Mesh Delivery Hdr)...
    &= nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
    Figure 3: LoWPAN subsequent fragment(s) encapsulatio= n header format
 
 
Would this be enough? If not, how many bits should be allocated? = Should there be a version field in addition
(as suggested by Vipul a while back)? What changes in the format = are suggested? Folks, please be specific
as to the suggested changes by sending header formats with clearl= y proposed fields, etc.
 
tnx,
 
-gabriel

----- Original Message ----
From: David Culler <david.culle= r@gmail.com>
To: Ki-Hyung Kim <kkim86@gmail.com>
Cc: gabriel= montenegro <gabriel_montenegro_2000@yahoo.com>; Geoff Mulligan <g= eoff@mulligan.com>; Soohong Daniel Park <soohongp@gmail.com>; 6low= pan@ietf.org
Sent: Friday, September 29, 2006 8:38:56 AM
Subject: Re:= [6lowpan] Mesh Delivery Field

It certainly would be a shame to get = into a position where the encoding is so so constrained that there was not = a means of accomodating additional capabilities that are revealed through d= eeper implementation and usage experience.  The IP community has histo= rically been very good at planning for change.  Options fields and lea= ving a little room in the initial encodings are essential to that.  As= much as we try, we seldom get every aspect of the protocol exactly right t= he first time.  It is understandable that with so much focus being place on he= ader compression that it is hard to leave any space unclaimed.  Howeve= r, that contingency planning and flexibility may be more critical to eventu= al adoption than squeezing out every unneccessary bit.   As we lo= ok at the desired "rush to finish" it is important to verify that the propo= sed framework permits enough expressive power to address the issues that ha= ve not yet been fully vetted.  You cannot expand the format, only work= within it.

On 9/26/06,
  = ;            &n= bsp;            1&nb= sp;            =       2       &= nbsp;           3
&nbs= p;      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
      +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    &= nbsp; | LF|datagram_offset|M|reserved |   datagram_size &nbs= p;   |dgram_tag|
      +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   &n= bsp;  |dgram_tag| Payload (or Mesh Delivery Hdr)...
    &= nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
    Figure 3: LoWPAN subsequent fragment(s) encapsulatio= n header format
 
 
Would this be enough? If not, how many bits should be allocated? = Should there be a version field in addition
(as suggested by Vipul a while back)? What changes in the format = are suggested? Folks, please be specific
as to the suggested changes by sending header formats with clearl= y proposed fields, etc.
 
tnx,
 
-gabriel

----- Original Message ----
From: David Culler <david.culle= r@gmail.com>
To: Ki-Hyung Kim <kkim86@gmail.com>
Cc: gabriel= montenegro <gabriel_montenegro_2000@yahoo.com>; Geoff Mulligan <g= eoff@mulligan.com>; Soohong Daniel Park <soohongp@gmail.com>; 6low= pan@ietf.org
Sent: Friday, September 29, 2006 8:38:56 AM
Subject: Re:= [6lowpan] Mesh Delivery Field

It certainly would be a shame to get = into a position where the encoding is so so constrained that there was not = a means of accomodating additional capabilities that are revealed through d= eeper implementation and usage experience.  The IP community has histo= rically been very good at planning for change.  Options fields and lea= ving a little room in the initial encodings are essential to that.  As= much as we try, we seldom get every aspect of the protocol exactly right t= he first time.  It is understandable that with so much focus being place on he= ader compression that it is hard to leave any space unclaimed.  Howeve= r, that contingency planning and flexibility may be more critical to eventu= al adoption than squeezing out every unneccessary bit.   As we lo= ok at the desired "rush to finish" it is important to verify that the propo= sed framework permits enough expressive power to address the issues that ha= ve not yet been fully vetted.  You cannot expand the format, only work= within it.

On 9/26/06, Ki-H= yung Kim <kkim86@gmail.com> wrote:
Gabriel,
 
I am sorry for this late reply.
Basically, I agree that current format document is rather tightly = ;scheduled and not well prepared for future enhancements or revisions, in t= erms of routing, diagnoses, management, etc. Based on the assumption that w= e are not yet in the stage of pursuing future rechartering items, it m= ight not be the right time to consider all the cases at one time. Also, we = should be in rush to finish the current format document ASAP for moving for= ward into next stage before next IETF meeting.
 
Regarding the mesh delivery field, Mario Mao's approach should be fine= , and other approaches (like option 2,3, and 4) might be OK. However, it se= ems like we are trying too much to make the format compact while = not considering the future expansions.
 
After all, my opinion is option 1. Let's have one byte for the multica= st bit and the reserved fields for future.
having additional one byte for this is not a big deal in terms of= packet size and won't add much complexity for handling it.
Examples of utilizing some reserved fields might be fol= lows:
1. Based on the assumption that 6lowpan supports multiple ro= uting protocols such as  LOAD, DYMO-low, HiLow, DSR, or whatever, = ;etc., the field might be used for indicating which specific routing protoc= ol should be used for routing this particular packet. It might be argued wh= ether the format document should support multiple protocols at a time. Howe= ver, those kind of argue should be debated later while considering routing = protocols without eliminating future possible necessity.
2. Routing protocols could be optimzed by having some option fields, w= hile it might not be right time to specifically mention them.
 
I remember that the issue of the mesh underneath or above IP has = been raised several times in the WG. I think it might not be right time con= sidering it again right now.
 
If you have any other opinions, please let me know.

 
On 9/23/06, gabr= iel montenegro < gabriel_montenegro_2000@yah= oo.com> wrote:=20
First of all, Thanks David for your thoughtful message. It's great t= o see you participate in this forum and I hope
you'll stick around!
 
From the point of view of laying the technology foundation, everythi= ng in your message is quite relevant.
From the point of view of WG management, I'm trying to figure out if= we need to act on all of it right now
or if there are things we can address independently of the format dr= aft under discussion. For example,
Ki-H= yung Kim <kkim86@gmail.com> wrote:
Gabriel,
 
I am sorry for this late reply.
Basically, I agree that current format document is rather tightly = ;scheduled and not well prepared for future enhancements or revisions, in t= erms of routing, diagnoses, management, etc. Based on the assumption that w= e are not yet in the stage of pursuing future rechartering items, it m= ight not be the right time to consider all the cases at one time. Also, we = should be in rush to finish the current format document ASAP for moving for= ward into next stage before next IETF meeting.
 
Regarding the mesh delivery field, Mario Mao's approach should be fine= , and other approaches (like option 2,3, and 4) might be OK. However, it se= ems like we are trying too much to make the format compact while = not considering the future expansions.
 
After all, my opinion is option 1. Let's have one byte for the multica= st bit and the reserved fields for future.
having additional one byte for this is not a big deal in terms of= packet size and won't add much complexity for handling it.
Examples of utilizing some reserved fields might be fol= lows:
1. Based on the assumption that 6lowpan supports multiple ro= uting protocols such as  LOAD, DYMO-low, HiLow, DSR, or whatever, = ;etc., the field might be used for indicating which specific routing protoc= ol should be used for routing this particular packet. It might be argued wh= ether the format document should support multiple protocols at a time. Howe= ver, those kind of argue should be debated later while considering routing = protocols without eliminating future possible necessity.
2. Routing protocols could be optimzed by having some option fields, w= hile it might not be right time to specifically mention them.
 
I remember that the issue of the mesh underneath or above IP has = been raised several times in the WG. I think it might not be right time con= sidering it again right now.
 
If you have any other opinions, please let me know.

 
On 9/23/06, gabr= iel montenegro < gabriel_montenegro_2000@yah= oo.com> wrote:=20
First of all, Thanks David for your thoughtful message. It's great t= o see you participate in this forum and I hope
you'll stick around!
 
From the point of view of laying the technology foundation, everythi= ng in your message is quite relevant.
From the point of view of WG management, I'm trying to figure out if= we need to act on all of it right now
or if there are things we can address independently of the format dr= aft under discussion. For example,
you bring up the topic of traceroute type functionality. In IP, this= is carried over ICMP, a separate
management control plane. Since what we have in the format draft is = a multiplexing layer, we can
define a new protocol value to carry out the management protocol pac= kets. The question is if the
current format provides the required mechanism to go do work on such= a separate protocol
in another draft. Intuitively, it seems like this would work. Someon= e (your group, David?) could
define such a protocol with functionality similar to ICMP for pings,= traceroute, etc and provide
the route gathering functionality, the echo response, etc in that se= parate draft. Conceivably, it
would not necessarily use the mesh delivery header, as it would prov= ide its own facility to
record hop-by-hop route information within its own protocol fields. = It could use loose source
routing in which case some use of the mesh delivery header might be = appropriate as well.
Would such an approach work, David? This would actually play into on= e of the items slated for
the next round of 6lowpan (if we ever recharter) to strengthen diagn= osability or management of
these networks.
 
As for your point about us not knowing exactly what the header forma= t must look like at this point in
time, this is perhaps something we need to take into consideration r= ight now. For example, this
input would push us into reserving at least a couple of bits in the = header for future expansion. A while
back Vipul was arguing for a "version" field. Not sure if such a fie= ld is required or if the current reserved
fields are enough. Mario Mao's proposal uses one of those reserved b= its to solve the issue under
discussion regarding the mesh delivery header variants for unicast v= s mcast/bcast. There has been
one group expressing support for this, so perhaps we already have th= e necessary mechanism in place
in the header.
 
David, you also meONT-SIZE: 12pt; FONT-FAMILY: times new roman,new york,times,= serif">you bring up the topic of traceroute type functionality. In IP, this= is carried over ICMP, a separate
management control plane. Since what we have in the format draft is = a multiplexing layer, we can
define a new protocol value to carry out the management protocol pac= kets. The question is if the
current format provides the required mechanism to go do work on such= a separate protocol
in another draft. Intuitively, it seems like this would work. Someon= e (your group, David?) could
define such a protocol with functionality similar to ICMP for pings,= traceroute, etc and provide
the route gathering functionality, the echo response, etc in that se= parate draft. Conceivably, it
would not necessarily use the mesh delivery header, as it would prov= ide its own facility to
record hop-by-hop route information within its own protocol fields. = It could use loose source
routing in which case some use of the mesh delivery header might be = appropriate as well.
Would such an approach work, David? This would actually play into on= e of the items slated for
the next round of 6lowpan (if we ever recharter) to strengthen diagn= osability or management of
these networks.
 
As for your point about us not knowing exactly what the header forma= t must look like at this point in
time, this is perhaps something we need to take into consideration r= ight now. For example, this
input would push us into reserving at least a couple of bits in the = header for future expansion. A while
back Vipul was arguing for a "version" field. Not sure if such a fie= ld is required or if the current reserved
fields are enough. Mario Mao's proposal uses one of those reserved b= its to solve the issue under
discussion regarding the mesh delivery header variants for unicast v= s mcast/bcast. There has been
one group expressing support for this, so perhaps we already have th= e necessary mechanism in place
in the header.
 
David, you also mention the need to support different routing protoc= ols side-by-side for comparison.
This is one of the design goals of the format document. As I mention= ed, the protocol field allows one
to carry different protocols. We currently have proposals for a 6low= pan adaptations of AODV, a DyMO
and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps = BVR is next. The point is that
the format document does provide the mechanism to define any such pr= otocol, or is there a limitation you
can see in the current document? If so, what needs to change?
 
As for the claim that sub-IP benefits from simpler structures, my in= terpretation is that you're suggesting it
is better not to use the mesh delivery header and let IP deal with t= he underlying individual collection of links.
If so, one can ignore the mesh delivery header (not use it) and use = the other parts of the format document to
simply layer IP on top. This approach would then make use of other a= ctivities like AUTOCONF or MANET
to create meshes if so desired.  Personally, I see that *if* on= e wishes to do a mesh, not doing it in the sub-IP
layer just pushes to problem upwards into the IP routing realm, and = this just makes things even more complex
than doing it under sub-IP. Complexity will be there no matter what,= it's just a question of where one wants to
address it. I do note that sub-IP complex structures are very popula= r and deployed in some cases (802.1d bridged
networks). Perhaps likely to become even more so with 802.11s within= a few years.
 
I would not be interested in pursuing an AUTOCONF path, but think it= should
be possible to do so for those so inclined. Does this sound doable? = Again, my immediate concern is that the
format document not prevent this approach.
 
-gabriel

 
----- Original Message ----
From: Geoff Mulligan < ge= off@mulligan.com>
To: Soohong Daniel Park <
This is one of the design goals of the format document. As I mention= ed, the protocol field allows one
to carry different protocols. We currently have proposals for a 6low= pan adaptations of AODV, a DyMO
and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps = BVR is next. The point is that
the format document does provide the mechanism to define any such pr= otocol, or is there a limitation you
can see in the current document? If so, what needs to change?
 
As for the claim that sub-IP benefits from simpler structures, my in= terpretation is that you're suggesting it
is better not to use the mesh delivery header and let IP deal with t= he underlying individual collection of links.
If so, one can ignore the mesh delivery header (not use it) and use = the other parts of the format document to
simply layer IP on top. This approach would then make use of other a= ctivities like AUTOCONF or MANET
to create meshes if so desired.  Personally, I see that *if* on= e wishes to do a mesh, not doing it in the sub-IP
layer just pushes to problem upwards into the IP routing realm, and = this just makes things even more complex
than doing it under sub-IP. Complexity will be there no matter what,= it's just a question of where one wants to
address it. I do note that sub-IP complex structures are very popula= r and deployed in some cases (802.1d bridged
networks). Perhaps likely to become even more so with 802.11s within= a few years.
 
I would not be interested in pursuing an AUTOCONF path, but think it= should
be possible to do so for those so inclined. Does this sound doable? = Again, my immediate concern is that the
format document not prevent this approach.
 
-gabriel

 
----- Original Message ----
From: Geoff Mulligan < ge= off@mulligan.com>
To: Soohong Daniel Park <soohongp@g= mail.com>
Cc: 6lowpan@ietf.org; David Culler <david.culler@gmail.com>
Sent: Friday, September 22, 2006 = 6:41:21 AM
Subject: Re: [6lowpan] Mesh Delivery Field

Daniel,
  While the WG last call did expire, I'm not sure= if David is too late.
I think that he raises some important concerns an= d I'm not sure that we
really have consensus on the mesh delivery field.=

I would like to hear from the list on this.  I think that= Gabriel has
put forth 4 alternatives.  Carsten indicated that= he thought he might
have a different alternative and would post to the = list either the
alternative or his consideration of the 4 alternatives -= Carsten, please
send your thoughts.

I feel that the issue David= raises should be dealt with by the WG
because I do not want to send the= draft on to the IESG only to have
these issues brought up in the IETF l= ast call.  These seem rather
fundamental to me and we might l= ook rather foolish not having resolved
this in the working group!
We need some significant discussion from the members of the WG.  = ;This WG
has been, my self included, rather quiet and as a result we have mov= ed
at a snails pace getting anything done.  I implore everyon= e to take time
and read the thread on the mesh field and send your thoug= hts, pro, con
or otherwise to this list.  If everyone continue= s to be apathetic about
this work, I hold little hope for this WG being= rechartered to do any
other work!

    geoff<= BR>
On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote:
>= ; David,
>
> First off, your issue raising in this thread seem= s too late since our
> official WGLC was expired: "This Last Call wi= ll end on Wednesday 02
> August 2006 at 2359 UTC."
>
> A= nyway, my sense is not to take Mesh issue at this stage. As long as
>= we are looking at the 6lowpan solution format, mesh is out of scope of > that. In fact, as far as I am concern, mesh belongs to 15.4 technolog= y
> based on MAC layer. Instead, as described in the rechartering, we will
= > go through adhoc issue based on IP layer. That's why we are here in > 6lowpan wg of ietf.
>
> But, some staffs described in y= our mail seem helpful from the 6lowpan
> perspective, especially IPv6= related stuffs. If allowed, please bring
> your concern to the next = 6lowpan face-to-face meeting in San Diego.
> Then, we will have furt= her details in there I believe...
>
> --
>
> > Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, S= AMSUNG Electronics.
>
>
>
> On 9/21/06, David Cu= ller <david.culler@gmail.com> wrote:
> > De= ar All,
> >
> > I would like to raise a concern about th= e Mesh Delivery Field
> > definition in Section 11 of the format document.  While the actual
> > mesh routing protocol i= s appropriately outside the scope of the
> > 6lowpan Format docum= ent, that format needs provide the raw structure
> > upon which ro= ugh consensus and running code can be flourish.  We
> > = know that low power wireless mesh routing is technically tricky and
>= ; > strongly influenced by target traffic load, power management profile= ,
> > network design, and so on.  Thus, it is reasonable= to expect that the
> > consensus building and technical refinemen= t process will require
> > on-going expeget=3D_blank rel=3Dnofollow>soohongp@g= mail.com>
Cc: 6lowpan@ietf.org; David Culler <david.culler@gmail.com>
Sent: Friday, September 22, 2006 = 6:41:21 AM
Subject: Re: [6lowpan] Mesh Delivery Field

Daniel,
  While the WG last call did expire, I'm not sure= if David is too late.
I think that he raises some important concerns an= d I'm not sure that we
really have consensus on the mesh delivery field.=

I would like to hear from the list on this.  I think that= Gabriel has
put forth 4 alternatives.  Carsten indicated that= he thought he might
have a different alternative and would post to the = list either the
alternative or his consideration of the 4 alternatives -= Carsten, please
send your thoughts.

I feel that the issue David= raises should be dealt with by the WG
because I do not want to send the= draft on to the IESG only to have
these issues brought up in the IETF l= ast call.  These seem rather
fundamental to me and we might l= ook rather foolish not having resolved
this in the working group!
We need some significant discussion from the members of the WG.  = ;This WG
has been, my self included, rather quiet and as a result we have mov= ed
at a snails pace getting anything done.  I implore everyon= e to take time
and read the thread on the mesh field and send your thoug= hts, pro, con
or otherwise to this list.  If everyone continue= s to be apathetic about
this work, I hold little hope for this WG being= rechartered to do any
other work!

    geoff<= BR>
On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote:
>= ; David,
>
> First off, your issue raising in this thread seem= s too late since our
> official WGLC was expired: "This Last Call wi= ll end on Wednesday 02
> August 2006 at 2359 UTC."
>
> A= nyway, my sense is not to take Mesh issue at this stage. As long as
>= we are looking at the 6lowpan solution format, mesh is out of scope of > that. In fact, as far as I am concern, mesh belongs to 15.4 technolog= y
> based on MAC layer. Instead, as described in the rechartering, we will
= > go through adhoc issue based on IP layer. That's why we are here in > 6lowpan wg of ietf.
>
> But, some staffs described in y= our mail seem helpful from the 6lowpan
> perspective, especially IPv6= related stuffs. If allowed, please bring
> your concern to the next = 6lowpan face-to-face meeting in San Diego.
> Then, we will have furt= her details in there I believe...
>
> --
>
> > Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, S= AMSUNG Electronics.
>
>
>
> On 9/21/06, David Cu= ller <david.culler@gmail.com> wrote:
> > De= ar All,
> >
> > I would like to raise a concern about th= e Mesh Delivery Field
> > definition in Section 11 of the format document.  While the actual
> > mesh routing protocol i= s appropriately outside the scope of the
> > 6lowpan Format docum= ent, that format needs provide the raw structure
> > upon which ro= ugh consensus and running code can be flourish.  We
> > = know that low power wireless mesh routing is technically tricky and
>= ; > strongly influenced by target traffic load, power management profile= ,
> > network design, and so on.  Thus, it is reasonable= to expect that the
> > consensus building and technical refinemen= t process will require
> > on-going experience with protocol and = implementation alternatives.
> > The 6lowpan format document shoul= d support this process, although it
> > should not dictate its con= clusion.
> >
> > Based on past experience with IP layer = 3 routing and with past
> > internally routed links, we can establ= ish a few primary goals for the
> > expressiveness of the 6lowpan Mesh Deli= very Field.
> >    (1) It should support the = visibility into the routed 15.4 cloud
> > necessary to develop, de= bug, diagnose, and manage the 15.4 cloud.
> >   &nb= sp;(2) It should support the ability to define, develop and compare
>= ; > routing protocols and possibly support the presence of multiple
&= gt; > protocols for widely differing usage cases.
> > &nbs= p;  (3) It needs to be possible for nodes to communicate with oth= er nodes
> > in the cloud in order to discover and negotiate join= ing the cloud
> > without joining the cloud a priori through some = mechanism that is
> > opaque to IP and above.
> >
>= > (1) has historically been addressed through various forms of source <= BR>> > routing.  It should be possible to do the equivalent= of traceroute
> > through the 15.4 mesh and this should be accessibl= e in some form through IP
> > so
> > higher layers can be= built to perform the management.  The current
> > Mesh= Delivery Field definition seems to prohibit any form of source routing.> > It assumes that the routing tables are all set up and correct so= that
> > the forwarder can "swizzle" the destination address fiel= d of the 15.4
> > header with a table entry.  (The exper= ience of IP over ATM and the
> > thousands of pages of the Q83b si= gnalling protocol required to set up
> > all the tables in advance= ought to give us a little pause here.)  The
> > idea o= f supporting table-driven routing and thereby separating the
> > r= oute formation from the forwarding engine is a good one, but there
> = > needs to be enough expressive power to support the protocols that will=
> > establish and manage those tables (rather than relying on an opaque> > out-of-band signaling mechanism) and there needs to be the abil= ity to
> > query and validate those tables without relying on out-= of-band
> > mechanisms.
> >
> > (2) has histori= cally be addressed with protocol identifiers and
> > options. = ; As we went through the various RIP, OSPF, etc. we didn't
> >= ; need to go back and redefine the format documents.  There was e= nough
> > expressiveness for topology formation and routing to ev= olve.  Not all
> > networks need to support all protocol= s.  That has been the network
> > designers' determinati= on.  The underlying structure provided the
> > primitiv= es, allowing solutions (and consensus) to evolve.  We want to
= > > avoid creating a "winner take all" structure where there is no ro= om
> > for evolution and development.  It is possible that AODV, o= r TinyAODV,
> > or DSR, or GPSR or possibly one of several other = alternatives is the right
> > solution.  However, there = is little evidence of one having clear superiority
> > at
> = > this time, despite numerous high profile efforts.  We should= be defining the
> > canvas upon which competing alternatives can= be defined and vetted.
> >
> > (3) has historically been= addressed by a limited ability to
> > communicate on the link to = a crudely defined set of nodes in order to
> > bootstrap the disc= overy, join, address assignmenrience with protocol and = implementation alternatives.
> > The 6lowpan format document shoul= d support this process, although it
> > should not dictate its con= clusion.
> >
> > Based on past experience with IP layer = 3 routing and with past
> > internally routed links, we can establ= ish a few primary goals for the
> > expressiveness of the 6lowpan Mesh Deli= very Field.
> >    (1) It should support the = visibility into the routed 15.4 cloud
> > necessary to develop, de= bug, diagnose, and manage the 15.4 cloud.
> >   &nb= sp;(2) It should support the ability to define, develop and compare
>= ; > routing protocols and possibly support the presence of multiple
&= gt; > protocols for widely differing usage cases.
> > &nbs= p;  (3) It needs to be possible for nodes to communicate with oth= er nodes
> > in the cloud in order to discover and negotiate join= ing the cloud
> > without joining the cloud a priori through some = mechanism that is
> > opaque to IP and above.
> >
>= > (1) has historically been addressed through various forms of source <= BR>> > routing.  It should be possible to do the equivalent= of traceroute
> > through the 15.4 mesh and this should be accessibl= e in some form through IP
> > so
> > higher layers can be= built to perform the management.  The current
> > Mesh= Delivery Field definition seems to prohibit any form of source routing.> > It assumes that the routing tables are all set up and correct so= that
> > the forwarder can "swizzle" the destination address fiel= d of the 15.4
> > header with a table entry.  (The exper= ience of IP over ATM and the
> > thousands of pages of the Q83b si= gnalling protocol required to set up
> > all the tables in advance= ought to give us a little pause here.)  The
> > idea o= f supporting table-driven routing and thereby separating the
> > r= oute formation from the forwarding engine is a good one, but there
> = > needs to be enough expressive power to support the protocols that will=
> > establish and manage those tables (rather than relying on an opaque> > out-of-band signaling mechanism) and there needs to be the abil= ity to
> > query and validate those tables without relying on out-= of-band
> > mechanisms.
> >
> > (2) has histori= cally be addressed with protocol identifiers and
> > options. = ; As we went through the various RIP, OSPF, etc. we didn't
> >= ; need to go back and redefine the format documents.  There was e= nough
> > expressiveness for topology formation and routing to ev= olve.  Not all
> > networks need to support all protocol= s.  That has been the network
> > designers' determinati= on.  The underlying structure provided the
> > primitiv= es, allowing solutions (and consensus) to evolve.  We want to
= > > avoid creating a "winner take all" structure where there is no ro= om
> > for evolution and development.  It is possible that AODV, o= r TinyAODV,
> > or DSR, or GPSR or possibly one of several other = alternatives is the right
> > solution.  However, there = is little evidence of one having clear superiority
> > at
> = > this time, despite numerous high profile efforts.  We should= be defining the
> > canvas upon which competing alternatives can= be defined and vetted.
> >
> > (3) has historically been= addressed by a limited ability to
> > communicate on the link to = a crudely defined set of nodes in order to
> > bootstrap the disc= overy, join, address assignment, negotiation, etc.
> > Most succes= sful links under IP look either like a broadcast medium or
> > a p= oint-to-point link (a degenerative broadcast).  This allows ARP, =
> > RARP, BOOTP, DHCP, etc. to gain higher level accessibility an= d
> > addressibility through the link.  Links that require comple= x
> > signaling, discovery, joining and coordnation below the link= layer,
> > including ATM, Bluetooth (piconets and scatter nets),= and IRDA have
> > proved onerous for IP and have been relegated t= o far less general
> > usage scenarios - such as the desktop USB r= eplacement.  Even though
> > the radio is a broadcast m= edium, the challenge in a routed link is
> > that the link is not = by default a link-wide broadcast phy.  There
> > are two= natural notions of "broadcast" in a lowpan.  (i) The physical > > neighbors that happen to receive a transmission because they ar= e close
> > enough to pick up the signal and have their radios tur= ned on to
> > receive.  (ii) The entire collection of no= des that can be reached by a
> > multihop dissemination (flood).  Both of these are extremely useful in
> > boo= tstrapping higher levels, including routing, and should be
> > add= ressed in the format document.  Additionally, it is not
> = > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over=
> > a 15.4 link.  Providing some forms of broadcast usi= ng data frames
> > makes the 802.15.4 format much more like 802.11= and other links that
> > have proved very suitable for IP. &= nbsp;Few, if any, of the public 15.4 routing
> > layers developed<= BR>> > by the TinyOS community utilize beacon packets.
> >> > The recognition that the current Mesh Delivery field may be to = restrictive
> > is intimated by the need to define a second form = of the header for
> > multicast (and link local broadcast) that in= cludes a sequence number.
> > The mesh header field type is define= d by whether the destination
> > address is unicast or multicast. The documen= t states that the use of
> > such a sequence number is out of scop= e. However, the observation that
> > that extra information may ne= ed to be included depending on how
> > packets are routed further= suggests that more careful format
> > definition is needed to sup= port future development of mesh routing.
> >
> > Have fol= ks who have been developing mesh layers for lowpan6 felt that
> >= the existing Mesh Delivery Field is too restrictive?
> >
> = >
> > David E. Culler
> > UC Berkeley
> > culler@cs.berkeley.edu
> >
> >
> &g= t;
> >
> > ______________________________________________= _
> > 6lowpan mailing list
> > 6lowpan@ietf.org
> > https://www1.ietf.org/mailman/listinfo/6lowpan
= > >
> >
> >
>
> _____________________= __________________________
> 6lowpan mailing list
> 6low= pan@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/6lowpan


_________________________________= ______________
6lowpan mailing list
> > Most succes= sful links under IP look either like a broadcast medium or
> > a p= oint-to-point link (a degenerative broadcast).  This allows ARP, =
> > RARP, BOOTP, DHCP, etc. to gain higher level accessibility an= d
> > addressibility through the link.  Links that require comple= x
> > signaling, discovery, joining and coordnation below the link= layer,
> > including ATM, Bluetooth (piconets and scatter nets),= and IRDA have
> > proved onerous for IP and have been relegated t= o far less general
> > usage scenarios - such as the desktop USB r= eplacement.  Even though
> > the radio is a broadcast m= edium, the challenge in a routed link is
> > that the link is not = by default a link-wide broadcast phy.  There
> > are two= natural notions of "broadcast" in a lowpan.  (i) The physical > > neighbors that happen to receive a transmission because they ar= e close
> > enough to pick up the signal and have their radios tur= ned on to
> > receive.  (ii) The entire collection of no= des that can be reached by a
> > multihop dissemination (flood).  Both of these are extremely useful in
> > boo= tstrapping higher levels, including routing, and should be
> > add= ressed in the format document.  Additionally, it is not
> = > neccessary to use the 802.15.4 beaconing mechanism to bring up IP over=
> > a 15.4 link.  Providing some forms of broadcast usi= ng data frames
> > makes the 802.15.4 format much more like 802.11= and other links that
> > have proved very suitable for IP. &= nbsp;Few, if any, of the public 15.4 routing
> > layers developed<= BR>> > by the TinyOS community utilize beacon packets.
> >> > The recognition that the current Mesh Delivery field may be to = restrictive
> > is intimated by the need to define a second form = of the header for
> > multicast (and link local broadcast) that in= cludes a sequence number.
> > The mesh header field type is define= d by whether the destination
> > address is unicast or multicast. The documen= t states that the use of
> > such a sequence number is out of scop= e. However, the observation that
> > that extra information may ne= ed to be included depending on how
> > packets are routed further= suggests that more careful format
> > definition is needed to sup= port future development of mesh routing.
> >
> > Have fol= ks who have been developing mesh layers for lowpan6 felt that
> >= the existing Mesh Delivery Field is too restrictive?
> >
> = >
> > David E. Culler
> > UC Berkeley
> > culler@cs.berkeley.edu
> >
> >
> &g= t;
> >
> > ______________________________________________= _
> > 6lowpan mailing list
> > 6lowpan@ietf.org
> > https://www1.ietf.org/mailman/listinfo/6lowpan
= > >
> >
> >
>
> _____________________= __________________________
> 6lowpan mailing list
> 6low= pan@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/6lowpan


_________________________________= ______________
6lowpan mailing list
6lowpan@ietf.org
<= A id=3DbodyLinks href=3D"https://www1.ietf.org/mailman/listinfo/6lowpan" ta= rget=3D_blank rel=3Dnofollow>https://www1.ietf.org/mailman/listinfo/6lowpan=

 

_______________________= ________________________
6lowpan mailing list
6lowpan@ietf.or= g
https://www1.ietf.org/mailman/listin= fo/6lowpan





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



-= -
David E. Culler
Arched Rock Corporation
2168 Shattuck Ave
Be= rkeley, CA 94704
www.archedrock.com

--0-1752865851-1159564108=:27872-- --===============0593245853== 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 --===============0593245853==-- etf.org" target=3D_blank rel=3Dnofollow>6lowpan@ietf.org
<= A id=3DbodyLinks href=3D"https://www1.ietf.org/mailman/listinfo/6lowpan" ta= rget=3D_blank rel=3Dnofollow>https://www1.ietf.org/mailman/listinfo/6lowpan=

 

_______________________= ________________________
6lowpan mailing list
6lowpan@ietf.or= g
https://www1.ietf.org/mailman/listin= fo/6lowpan





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



-= -
David E. Culler
Arched Rock Corporation
2168 Shattuck Ave
Be= rkeley, CA 94704
www.archedrock.com

--0-1752865851-1159564108=:27872-- --===============0593245853== 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 --===============0593245853==-- From 6lowpan-bounces@ietf.org Sat Sep 30 12:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThrY-0003VX-7j; Sat, 30 Sep 2006 12:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTSbw-0003nQ-0y for 6lowpan@ietf.org; Fri, 29 Sep 2006 20:21:44 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTSWb-00086j-MN for 6lowpan@ietf.org; Fri, 29 Sep 2006 20:16:16 -0400 Received: by ug-out-1314.google.com with SMTP id 72so289888ugd for <6lowpan@ietf.org>; Fri, 29 Sep 2006 17:16:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=BvtLuuoD83vGRwrO1ZOTbAfoQ7bGIxNFPvuBi+AHvXTGu29I7Iak0uydpd0vuxv2nKWQtxfcf2lpEqaOFJd9RkER1Bbk8KHYQ7rejwbMHjaEyds1q1cvgcmkK4Y7K9heGqmQt7WhWRGv2fva8h/64kzxTgZ+5E0fuf3yuJkQ6xc= Received: by 10.67.101.10 with SMTP id d10mr2981918ugm; Fri, 29 Sep 2006 17:16:12 -0700 (PDT) Received: by 10.67.86.2 with HTTP; Fri, 29 Sep 2006 17:16:11 -0700 (PDT) Message-ID: Date: Sat, 30 Sep 2006 09:16:11 +0900 From: "Ki-Hyung Kim" To: "gabriel montenegro" Subject: Re: [6lowpan] Mesh Delivery Field In-Reply-To: <20060929210828.32995.qmail@web81915.mail.mud.yahoo.com> MIME-Version: 1.0 References: <20060929210828.32995.qmail@web81915.mail.mud.yahoo.com> X-Spam-Score: 2.9 (++) X-Scan-Signature: 23776db464f2bef49f6ef0d6857b4195 X-Mailman-Approved-At: Sat, 30 Sep 2006 12:38:50 -0400 Cc: 6lowpan@ietf.org, David Culler X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1385195424==" Errors-To: 6lowpan-bounces@ietf.org --===============1385195424== Content-Type: multipart/alternative; boundary="----=_Part_22624_17963809.1159575371905" ------=_Part_22624_17963809.1159575371905 Content-Type: text/plain; charset=EUC-KR; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayB0aGUgZmxleGliaWxpdHkgc2hvdWxkIGJlIGZpbmUuIFNvLCB3aGF0IGlzIGZpbmFs IGxvb2sgb2YgdGhlIG1lc2gKZGVsaXZlcnkgZmllbGQ/CgoKT24gOS8zMC8wNiwgZ2FicmllbCBt b250ZW5lZ3JvIDxnYWJyaWVsX21vbnRlbmVncm9fMjAwMEB5YWhvby5jb20+IHdyb3RlOgo+Cj4g IE9rLCBpdCBzZWVtcyBsaWtlIGZvbGtzIHdvdWxkIGxpa2UgdG8gaGF2ZSBtb3JlIGZsZXhpYmls aXR5IGluIHRoZQo+IGhlYWRlci4gSSdtIGp1c3QgaGF2aW5nIGEgaGFyZCB0aW1lIHRyYW5zbGF0 aW5nIHRoYXQKPiB0byBhY3R1YWwgYml0cyBhbmQgYnl0ZXMgd2l0aGluIHRoZSBoZWFkZXIgZm9y bWF0cywgYW5kIGhvdyBtdWNoCj4gZmxleGliaWxpdHkgaXMgZmluZS4KPgo+IFRoZSBmaXJzdCBw YWNrZXQgZm9ybWF0IGhhcyA1IGJpdHMgb2YgcmVzZXJ2ZWQgZmllbGQ6Cj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMK PiAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxCj4gICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKPiAgICAgICB8IExGfCAgcHJvdF90eXBl ICAgIHxNfCByc3YgICAgIHxQYXlsb2FkIChvciBNZXNoIERlbGl2ZXJ5IEhkcikuLi4KPiAgICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwo+Cj4gICAgICAgICAgRmlndXJlIDE6IExvV1BBTiB1bmZyYWdtZW50ZWQgZW5j YXBzdWxhdGlvbiBoZWFkZXIgZm9ybWF0Cj4KPiBPbmUgYml0IG91dCBvZiB0aGF0IHJlc2VydmVk IGZpZWxkIGlzIHdoYXQgTWFyaW8gTWFvIHN1Z2dlc3RzIHdlIHVzZSB0bwo+IGRpc3Rpbmd1aXNo IGJldHdlZW4gdGhlIHR3byBjdXJyZW50IGZsYXZvcnMKPiBvZiBtZXNoIGRlbGl2ZXJ5IGhlYWRl ciAodW5pY2FzdCB2cyBiY2FzdC9tY2FzdCkuIElzIHRoaXMgc3VmZmljaWVudAo+IGZsZXhpYmls aXR5Pwo+Cj4gVGhlIGlzc3VlIGlzIHRoYXQgdGhlcmUgaXMgbm8gc3VjaCBmbGV4aWJpbGl0eSBp biB0aGUgdHdvIG90aGVyIGhlYWRlcgo+IGZvcm1hdHMsIGJ1dCB3ZSBjYW4gY2VydGFpbmx5IGFk ZCBzdWNoIGEgcmVzZXJ2ZWQgZmllbGQgYW5kIG1ha2UgYWxsIDMKPiBoZWFkZXIgZm9ybWF0cyB0 aGUgc2FtZSB1cCB0byB0aGUgZmlyc3QgMTYgYml0cy4gUGVyaGFwcyBhbG9uZyB0aGVzZSBsaW5l cwo+IChub3RpY2UgdGhlIG5ldyAicmVzZXJ2ZWQiIGZpZWxkIGFuZCB0aGUgY29ycmVzcG9uZGlu ZyA1IGJpdCBzaGlmdCBmb3IKPiBkYXRhZ3JhbV9zaXplIGFuZCBkYXRhZ3JhbV90YWcpIDoKPgo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAg ICAgICAgICAgICAzCj4gICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQo+ICAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCj4gICAgICAgfCBM RnwgIHByb3RfdHlwZSAgICB8TXxyZXNlcnZlZCB8ICAgZGF0YWdyYW1fc2l6ZSAgICAgfGRncmFt X3RhZ3wKPiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwo+ICAgICAgIHxkZ3JhbV90YWd8IFBheWxvYWQgKG9yIE1l c2ggRGVsaXZlcnkgSGRyKS4uLgo+ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCj4KPgo+ICAgICAgICAgRmlndXJl IDI6IExvV1BBTiBmaXJzdCBmcmFnbWVudCBlbmNhcHN1bGF0aW9uIGhlYWRlciBmb3JtYXQKPgo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAg ICAgICAgICAgICAzCj4gICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQo+ICAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCj4gICAgICAgfCBM RnxkYXRhZ3JhbV9vZmZzZXR8TXxyZXNlcnZlZCB8ICAgZGF0YWdyYW1fc2l6ZSAgICAgfGRncmFt X3RhZ3wKPiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwo+ICAgICAgIHxkZ3JhbV90YWd8IFBheWxvYWQgKG9yIE1l c2ggRGVsaXZlcnkgSGRyKS4uLgo+ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCj4KPiAgICAgRmlndXJlIDM6IExv V1BBTiBzdWJzZXF1ZW50IGZyYWdtZW50KHMpIGVuY2Fwc3VsYXRpb24gaGVhZGVyIGZvcm1hdAo+ Cj4KPgo+IFdvdWxkIHRoaXMgYmUgZW5vdWdoPyBJZiBub3QsIGhvdyBtYW55IGJpdHMgc2hvdWxk IGJlIGFsbG9jYXRlZD8gU2hvdWxkCj4gdGhlcmUgYmUgYSB2ZXJzaW9uIGZpZWxkIGluIGFkZGl0 aW9uCj4gKGFzIHN1Z2dlc3RlZCBieSBWaXB1bCBhIHdoaWxlIGJhY2spPyBXaGF0IGNoYW5nZXMg aW4gdGhlIGZvcm1hdCBhcmUKPiBzdWdnZXN0ZWQ/IEZvbGtzLCBwbGVhc2UgYmUgc3BlY2lmaWMK PiBhcyB0byB0aGUgc3VnZ2VzdGVkIGNoYW5nZXMgYnkgc2VuZGluZyBoZWFkZXIgZm9ybWF0cyB3 aXRoIGNsZWFybHkKPiBwcm9wb3NlZCBmaWVsZHMsIGV0Yy4KPgo+IHRueCwKPgo+IC1nYWJyaWVs Cj4KPgo+ICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0KPiBGcm9tOiBEYXZpZCBDdWxsZXIg PGRhdmlkLmN1bGxlckBnbWFpbC5jb20+Cj4gVG86IEtpLUh5dW5nIEtpbSA8a2tpbTg2QGdtYWls LmNvbT4KPiBDYzogZ2FicmllbCBtb250ZW5lZ3JvIDxnYWJyaWVsX21vbnRlbmVncm9fMjAwMEB5 YWhvby5jb20+OyBHZW9mZiBNdWxsaWdhbgo+IDxnZW9mZkBtdWxsaWdhbi5jb20+OyBTb29ob25n IERhbmllbCBQYXJrIDxzb29ob25ncEBnbWFpbC5jb20+Owo+IDZsb3dwYW5AaWV0Zi5vcmcKPiBT ZW50OiBGcmlkYXksIFNlcHRlbWJlciAyOSwgMjAwNiA4OjM4OjU2IEFNCj4gU3ViamVjdDogUmU6 IFs2bG93cGFuXSBNZXNoIERlbGl2ZXJ5IEZpZWxkCj4KPiBJdCBjZXJ0YWlubHkgd291bGQgYmUg YSBzaGFtZSB0byBnZXQgaW50byBhIHBvc2l0aW9uIHdoZXJlIHRoZSBlbmNvZGluZyBpcwo+IHNv IHNvIGNvbnN0cmFpbmVkIHRoYXQgdGhlcmUgd2FzIG5vdCBhIG1lYW5zIG9mIGFjY29tb2RhdGlu ZyBhZGRpdGlvbmFsCj4gY2FwYWJpbGl0aWVzIHRoYXQgYXJlIHJldmVhbGVkIHRocm91Z2ggZGVl cGVyIGltcGxlbWVudGF0aW9uIGFuZCB1c2FnZQo+IGV4cGVyaWVuY2UuICBUaGUgSVAgY29tbXVu aXR5IGhhcyBoaXN0b3JpY2FsbHkgYmVlbiB2ZXJ5IGdvb2QgYXQgcGxhbm5pbmcKPiBmb3IgY2hh bmdlLiAgT3B0aW9ucyBmaWVsZHMgYW5kIGxlYXZpbmcgYSBsaXR0bGUgcm9vbSBpbiB0aGUgaW5p dGlhbAo+IGVuY29kaW5ncyBhcmUgZXNzZW50aWFsIHRvIHRoYXQuICBBcyBtdWNoIGFzIHdlIHRy eSwgd2Ugc2VsZG9tIGdldCBldmVyeQo+IGFzcGVjdCBvZiB0aGUgcHJvdG9jb2wgZXhhY3RseSBy aWdodCB0aGUgZmlyc3QgdGltZS4gIEl0IGlzIHVuZGVyc3RhbmRhYmxlCj4gdGhhdCB3aXRoIHNv IG11Y2ggZm9jdXMgYmVpbmcgcGxhY2Ugb24gaGVhZGVyIGNvbXByZXNzaW9uIHRoYXQgaXQgaXMg aGFyZCB0bwo+IGxlYXZlIGFueSBzcGFjZSB1bmNsYWltZWQuICBIb3dldmVyLCB0aGF0IGNvbnRp bmdlbmN5IHBsYW5uaW5nIGFuZAo+IGZsZXhpYmlsaXR5IG1heSBiZSBtb3JlIGNyaXRpY2FsIHRv IGV2ZW50dWFsIGFkb3B0aW9uIHRoYW4gc3F1ZWV6aW5nIG91dAo+IGV2ZXJ5IHVubmVjY2Vzc2Fy eSBiaXQuICAgQXMgd2UgbG9vayBhdCB0aGUgZGVzaXJlZCAicnVzaCB0byBmaW5pc2giIGl0IGlz Cj4gaW1wb3J0YW50IHRvIHZlcmlmeSB0aGF0IHRoZSBwcm9wb3NlZCBmcmFtZXdvcmsgcGVybWl0 cyBlbm91Z2ggZXhwcmVzc2l2ZQo+IHBvd2VyIHRvIGFkZHJlc3MgdGhlIGlzc3VlcyB0aGF0IGhh dmUgbm90IHlldCBiZWVuIGZ1bGx5IHZldHRlZC4gIFlvdSBjYW5ub3QKPiBleHBhbmQgdGhlIGZv cm1hdCwgb25seSB3b3JrIHdpdGhpbiBpdC4KPgo+IE9uIDkvMjYvMDYsIEtpLUh5dW5nIEtpbSA8 a2tpbTg2QGdtYWlsLmNvbT4gd3JvdGU6Cj4gPgo+ID4gR2FicmllbCwKPiA+Cj4gPiBJIGFtIHNv cnJ5IGZvciB0aGlzIGxhdGUgcmVwbHkuCj4gPiBCYXNpY2FsbHksIEkgYWdyZWUgdGhhdCBjdXJy ZW50IGZvcm1hdCBkb2N1bWVudCBpcyByYXRoZXIKPiA+IHRpZ2h0bHkgc2NoZWR1bGVkIGFuZCBu b3Qgd2VsbCBwcmVwYXJlZCBmb3IgZnV0dXJlIGVuaGFuY2VtZW50cyBvcgo+ID4gcmV2aXNpb25z LCBpbiB0ZXJtcyBvZiByb3V0aW5nLCBkaWFnbm9zZXMsIG1hbmFnZW1lbnQsIGV0Yy4gQmFzZWQg b24gdGhlCj4gPiBhc3N1bXB0aW9uIHRoYXQgd2UgYXJlIG5vdCB5ZXQgaW4gdGhlIHN0YWdlIG9m IHB1cnN1aW5nIGZ1dHVyZSByZWNoYXJ0ZXJpbmcKPiA+IGl0ZW1zLCBpdCBtaWdodCBub3QgYmUg dGhlIHJpZ2h0IHRpbWUgdG8gY29uc2lkZXIgYWxsIHRoZSBjYXNlcyBhdCBvbmUgdGltZS4KPiA+ IEFsc28sIHdlIHNob3VsZCBiZSBpbiBydXNoIHRvIGZpbmlzaCB0aGUgY3VycmVudCBmb3JtYXQg ZG9jdW1lbnQgQVNBUCBmb3IKPiA+IG1vdmluZyBmb3J3YXJkIGludG8gbmV4dCBzdGFnZSBiZWZv cmUgbmV4dCBJRVRGIG1lZXRpbmcuCj4gPgo+ID4gUmVnYXJkaW5nIHRoZSBtZXNoIGRlbGl2ZXJ5 IGZpZWxkLCBNYXJpbyBNYW8ncyBhcHByb2FjaCBzaG91bGQgYmUgZmluZSwKPiA+IGFuZCBvdGhl ciBhcHByb2FjaGVzIChsaWtlIG9wdGlvbiAyLDMsIGFuZCA0KSBtaWdodCBiZSBPSy4gSG93ZXZl ciwgaXQgc2VlbXMKPiA+IGxpa2Ugd2UgYXJlIHRyeWluZyB0b28gbXVjaCB0byBtYWtlIHRoZSBm b3JtYXQgY29tcGFjdCB3aGlsZSBub3QgY29uc2lkZXJpbmcKPiA+IHRoZSBmdXR1cmUgZXhwYW5z aW9ucy4KPiA+Cj4gPiBBZnRlciBhbGwsIG15IG9waW5pb24gaXMgb3B0aW9uIDEuIExldCdzIGhh dmUgb25lIGJ5dGUgZm9yIHRoZSBtdWx0aWNhc3QKPiA+IGJpdCBhbmQgdGhlIHJlc2VydmVkIGZp ZWxkcyBmb3IgZnV0dXJlLgo+ID4gaGF2aW5nIGFkZGl0aW9uYWwgb25lIGJ5dGUgZm9yIHRoaXMg aXMgbm90IGEgYmlnIGRlYWwgaW4gdGVybXMgb2YgcGFja2V0Cj4gPiBzaXplIGFuZCB3b24ndCBh ZGQgbXVjaCBjb21wbGV4aXR5IGZvciBoYW5kbGluZyBpdC4KPiA+IEV4YW1wbGVzIG9mIHV0aWxp emluZyBzb21lIHJlc2VydmVkIGZpZWxkcyBtaWdodCBiZSBmb2xsb3dzOgo+ID4gMS4gQmFzZWQg b24gdGhlIGFzc3VtcHRpb24gdGhhdCA2bG93cGFuIHN1cHBvcnRzIG11bHRpcGxlIHJvdXRpbmcK PiA+IHByb3RvY29scyBzdWNoIGFzICBMT0FELCBEWU1PLWxvdywgSGlMb3csIERTUiwgb3Igd2hh dGV2ZXIsIGV0Yy4sIHRoZSBmaWVsZAo+ID4gbWlnaHQgYmUgdXNlZCBmb3IgaW5kaWNhdGluZyB3 aGljaCBzcGVjaWZpYyByb3V0aW5nIHByb3RvY29sIHNob3VsZCBiZSB1c2VkCj4gPiBmb3Igcm91 dGluZyB0aGlzIHBhcnRpY3VsYXIgcGFja2V0LiBJdCBtaWdodCBiZSBhcmd1ZWQgd2hldGhlciB0 aGUgZm9ybWF0Cj4gPiBkb2N1bWVudCBzaG91bGQgc3VwcG9ydCBtdWx0aXBsZSBwcm90b2NvbHMg YXQgYSB0aW1lLiBIb3dldmVyLCB0aG9zZSBraW5kIG9mCj4gPiBhcmd1ZSBzaG91bGQgYmUgZGVi YXRlZCBsYXRlciB3aGlsZSBjb25zaWRlcmluZyByb3V0aW5nIHByb3RvY29scyB3aXRob3V0Cj4g PiBlbGltaW5hdGluZyBmdXR1cmUgcG9zc2libGUgbmVjZXNzaXR5Lgo+ID4gMi4gUm91dGluZyBw cm90b2NvbHMgY291bGQgYmUgb3B0aW16ZWQgYnkgaGF2aW5nIHNvbWUgb3B0aW9uIGZpZWxkcywK PiA+IHdoaWxlIGl0IG1pZ2h0IG5vdCBiZSByaWdodCB0aW1lIHRvIHNwZWNpZmljYWxseSBtZW50 aW9uIHRoZW0uCj4gPgo+ID4gSSByZW1lbWJlciB0aGF0IHRoZSBpc3N1ZSBvZiB0aGUgbWVzaCB1 bmRlcm5lYXRoIG9yIGFib3ZlIElQIGhhcyBiZWVuCj4gPiByYWlzZWQgc2V2ZXJhbCB0aW1lcyBp biB0aGUgV0cuIEkgdGhpbmsgaXQgbWlnaHQgbm90IGJlIHJpZ2h0IHRpbWUKPiA+IGNvbnNpZGVy aW5nIGl0IGFnYWluIHJpZ2h0IG5vdy4KPiA+Cj4gPiBJZiB5b3UgaGF2ZSBhbnkgb3RoZXIgb3Bp bmlvbnMsIHBsZWFzZSBsZXQgbWUga25vdy4KPiA+Cj4gPgo+ID4gIE9uIDkvMjMvMDYsIGdhYnJp ZWwgbW9udGVuZWdybyA8IGdhYnJpZWxfbW9udGVuZWdyb18yMDAwQHlhaG9vLmNvbT4KPiA+IHdy b3RlOgo+ID4gPgo+ID4gPiAgRmlyc3Qgb2YgYWxsLCBUaGFua3MgRGF2aWQgZm9yIHlvdXIgdGhv dWdodGZ1bCBtZXNzYWdlLiBJdCdzIGdyZWF0IHRvCj4gPiA+IHNlZSB5b3UgcGFydGljaXBhdGUg aW4gdGhpcyBmb3J1bSBhbmQgSSBob3BlCj4gPiA+IHlvdSdsbCBzdGljayBhcm91bmQhCj4gPiA+ Cj4gPiA+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgbGF5aW5nIHRoZSB0ZWNobm9sb2d5IGZv dW5kYXRpb24sIGV2ZXJ5dGhpbmcKPiA+ID4gaW4geW91ciBtZXNzYWdlIGlzIHF1aXRlIHJlbGV2 YW50Lgo+ID4gPiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIFdHIG1hbmFnZW1lbnQsIEknbSB0 cnlpbmcgdG8gZmlndXJlIG91dCBpZgo+ID4gPiB3ZSBuZWVkIHRvIGFjdCBvbiBhbGwgb2YgaXQg cmlnaHQgbm93Cj4gPiA+IG9yIGlmIHRoZXJlIGFyZSB0aGluZ3Mgd2UgY2FuIGFkZHJlc3MgaW5k ZXBlbmRlbnRseSBvZiB0aGUgZm9ybWF0Cj4gPiA+IGRyYWZ0IHVuZGVyIGRpc2N1c3Npb24uIEZv ciBleGFtcGxlLAo+ID4gPiB5b3UgYnJpbmcgdXAgdGhlIHRvcGljIG9mIHRyYWNlcm91dGUgdHlw ZSBmdW5jdGlvbmFsaXR5LiBJbiBJUCwgdGhpcwo+ID4gPiBpcyBjYXJyaWVkIG92ZXIgSUNNUCwg YSBzZXBhcmF0ZQo+ID4gPiBtYW5hZ2VtZW50IGNvbnRyb2wgcGxhbmUuIFNpbmNlIHdoYXQgd2Ug aGF2ZSBpbiB0aGUgZm9ybWF0IGRyYWZ0IGlzIGEKPiA+ID4gbXVsdGlwbGV4aW5nIGxheWVyLCB3 ZSBjYW4KPiA+ID4gZGVmaW5lIGEgbmV3IHByb3RvY29sIHZhbHVlIHRvIGNhcnJ5IG91dCB0aGUg bWFuYWdlbWVudCBwcm90b2NvbAo+ID4gPiBwYWNrZXRzLiBUaGUgcXVlc3Rpb24gaXMgaWYgdGhl Cj4gPiA+IGN1cnJlbnQgZm9ybWF0IHByb3ZpZGVzIHRoZSByZXF1aXJlZCBtZWNoYW5pc20gdG8g Z28gZG8gd29yayBvbiBzdWNoIGEKPiA+ID4gc2VwYXJhdGUgcHJvdG9jb2wKPiA+ID4gaW4gYW5v dGhlciBkcmFmdC4gSW50dWl0aXZlbHksIGl0IHNlZW1zIGxpa2UgdGhpcyB3b3VsZCB3b3JrLiBT b21lb25lCj4gPiA+ICh5b3VyIGdyb3VwLCBEYXZpZD8pIGNvdWxkCj4gPiA+IGRlZmluZSBzdWNo IGEgcHJvdG9jb2wgd2l0aCBmdW5jdGlvbmFsaXR5IHNpbWlsYXIgdG8gSUNNUCBmb3IgcGluZ3Ms Cj4gPiA+IHRyYWNlcm91dGUsIGV0YyBhbmQgcHJvdmlkZQo+ID4gPiB0aGUgcm91dGUgZ2F0aGVy aW5nIGZ1bmN0aW9uYWxpdHksIHRoZSBlY2hvIHJlc3BvbnNlLCBldGMgaW4gdGhhdAo+ID4gPiBz ZXBhcmF0ZSBkcmFmdC4gQ29uY2VpdmFibHksIGl0Cj4gPiA+IHdvdWxkIG5vdCBuZWNlc3Nhcmls eSB1c2UgdGhlIG1lc2ggZGVsaXZlcnkgaGVhZGVyLCBhcyBpdCB3b3VsZAo+ID4gPiBwcm92aWRl IGl0cyBvd24gZmFjaWxpdHkgdG8KPiA+ID4gcmVjb3JkIGhvcC1ieS1ob3Agcm91dGUgaW5mb3Jt YXRpb24gd2l0aGluIGl0cyBvd24gcHJvdG9jb2wgZmllbGRzLiBJdAo+ID4gPiBjb3VsZCB1c2Ug bG9vc2Ugc291cmNlCj4gPiA+IHJvdXRpbmcgaW4gd2hpY2ggY2FzZSBzb21lIHVzZSBvZiB0aGUg bWVzaCBkZWxpdmVyeSBoZWFkZXIgbWlnaHQgYmUKPiA+ID4gYXBwcm9wcmlhdGUgYXMgd2VsbC4K PiA+ID4gV291bGQgc3VjaCBhbiBhcHByb2FjaCB3b3JrLCBEYXZpZD8gVGhpcyB3b3VsZCBhY3R1 YWxseSBwbGF5IGludG8gb25lCj4gPiA+IG9mIHRoZSBpdGVtcyBzbGF0ZWQgZm9yCj4gPiA+IHRo ZSBuZXh0IHJvdW5kIG9mIDZsb3dwYW4gKGlmIHdlIGV2ZXIgcmVjaGFydGVyKSB0byBzdHJlbmd0 aGVuCj4gPiA+IGRpYWdub3NhYmlsaXR5IG9yIG1hbmFnZW1lbnQgb2YKPiA+ID4gdGhlc2UgbmV0 d29ya3MuCj4gPiA+Cj4gPiA+IEFzIGZvciB5b3VyIHBvaW50IGFib3V0IHVzIG5vdCBrbm93aW5n IGV4YWN0bHkgd2hhdCB0aGUgaGVhZGVyIGZvcm1hdAo+ID4gPiBtdXN0IGxvb2sgbGlrZSBhdCB0 aGlzIHBvaW50IGluCj4gPiA+IHRpbWUsIHRoaXMgaXMgcGVyaGFwcyBzb21ldGhpbmcgd2UgbmVl ZCB0byB0YWtlIGludG8gY29uc2lkZXJhdGlvbgo+ID4gPiByaWdodCBub3cuIEZvciBleGFtcGxl LCB0aGlzCj4gPiA+IGlucHV0IHdvdWxkIHB1c2ggdXMgaW50byByZXNlcnZpbmcgYXQgbGVhc3Qg YSBjb3VwbGUgb2YgYml0cyBpbiB0aGUKPiA+ID4gaGVhZGVyIGZvciBmdXR1cmUgZXhwYW5zaW9u LiBBIHdoaWxlCj4gPiA+IGJhY2sgVmlwdWwgd2FzIGFyZ3VpbmcgZm9yIGEgInZlcnNpb24iIGZp ZWxkLiBOb3Qgc3VyZSBpZiBzdWNoIGEgZmllbGQKPiA+ID4gaXMgcmVxdWlyZWQgb3IgaWYgdGhl IGN1cnJlbnQgcmVzZXJ2ZWQKPiA+ID4gZmllbGRzIGFyZSBlbm91Z2guIE1hcmlvIE1hbydzIHBy b3Bvc2FsIHVzZXMgb25lIG9mIHRob3NlIHJlc2VydmVkCj4gPiA+IGJpdHMgdG8gc29sdmUgdGhl IGlzc3VlIHVuZGVyCj4gPiA+IGRpc2N1c3Npb24gcmVnYXJkaW5nIHRoZSBtZXNoIGRlbGl2ZXJ5 IGhlYWRlciB2YXJpYW50cyBmb3IgdW5pY2FzdCB2cwo+ID4gPiBtY2FzdC9iY2FzdC4gVGhlcmUg aGFzIGJlZW4KPiA+ID4gb25lIGdyb3VwIGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgdGhpcywgc28g cGVyaGFwcyB3ZSBhbHJlYWR5IGhhdmUgdGhlCj4gPiA+IG5lY2Vzc2FyeSBtZWNoYW5pc20gaW4g cGxhY2UKPiA+ID4gaW4gdGhlIGhlYWRlci4KPiA+ID4KPiA+ID4gRGF2aWQsIHlvdSBhbHNvIG1l bnRpb24gdGhlIG5lZWQgdG8gc3VwcG9ydCBkaWZmZXJlbnQgcm91dGluZwo+ID4gPiBwcm90b2Nv bHMgc2lkZS1ieS1zaWRlIGZvciBjb21wYXJpc29uLgo+ID4gPiBUaGlzIGlzIG9uZSBvZiB0aGUg ZGVzaWduIGdvYWxzIG9mIHRoZSBmb3JtYXQgZG9jdW1lbnQuIEFzIEkKPiA+ID4gbWVudGlvbmVk LCB0aGUgcHJvdG9jb2wgZmllbGQgYWxsb3dzIG9uZQo+ID4gPiB0byBjYXJyeSBkaWZmZXJlbnQg cHJvdG9jb2xzLiBXZSBjdXJyZW50bHkgaGF2ZSBwcm9wb3NhbHMgZm9yIGEKPiA+ID4gNmxvd3Bh biBhZGFwdGF0aW9ucyBvZiBBT0RWLCBhIER5TU8KPiA+ID4gYW5kIEhpTG93LiBJIGtub3cgTmFu ZHUgd2FzIHRoaW5raW5nIG9mIGRvaW5nIG9uZSBmb3IgT0xTUi4gUGVyaGFwcwo+ID4gPiBCVlIg aXMgbmV4dC4gVGhlIHBvaW50IGlzIHRoYXQKPiA+ID4gdGhlIGZvcm1hdCBkb2N1bWVudCBkb2Vz IHByb3ZpZGUgdGhlIG1lY2hhbmlzbSB0byBkZWZpbmUgYW55IHN1Y2gKPiA+ID4gcHJvdG9jb2ws IG9yIGlzIHRoZXJlIGEgbGltaXRhdGlvbiB5b3UKPiA+ID4gY2FuIHNlZSBpbiB0aGUgY3VycmVu dCBkb2N1bWVudD8gSWYgc28sIHdoYXQgbmVlZHMgdG8gY2hhbmdlPwo+ID4gPgo+ID4gPiBBcyBm b3IgdGhlIGNsYWltIHRoYXQgc3ViLUlQIGJlbmVmaXRzIGZyb20gc2ltcGxlciBzdHJ1Y3R1cmVz LCBteQo+ID4gPiBpbnRlcnByZXRhdGlvbiBpcyB0aGF0IHlvdSdyZSBzdWdnZXN0aW5nIGl0Cj4g PiA+IGlzIGJldHRlciBub3QgdG8gdXNlIHRoZSBtZXNoIGRlbGl2ZXJ5IGhlYWRlciBhbmQgbGV0 IElQIGRlYWwgd2l0aCB0aGUKPiA+ID4gdW5kZXJseWluZyBpbmRpdmlkdWFsIGNvbGxlY3Rpb24g b2YgbGlua3MuCj4gPiA+IElmIHNvLCBvbmUgY2FuIGlnbm9yZSB0aGUgbWVzaCBkZWxpdmVyeSBo ZWFkZXIgKG5vdCB1c2UgaXQpIGFuZCB1c2UKPiA+ID4gdGhlIG90aGVyIHBhcnRzIG9mIHRoZSBm b3JtYXQgZG9jdW1lbnQgdG8KPiA+ID4gc2ltcGx5IGxheWVyIElQIG9uIHRvcC4gVGhpcyBhcHBy b2FjaCB3b3VsZCB0aGVuIG1ha2UgdXNlIG9mIG90aGVyCj4gPiA+IGFjdGl2aXRpZXMgbGlrZSBB VVRPQ09ORiBvciBNQU5FVAo+ID4gPiB0byBjcmVhdGUgbWVzaGVzIGlmIHNvIGRlc2lyZWQuICBQ ZXJzb25hbGx5LCBJIHNlZSB0aGF0ICppZiogb25lCj4gPiA+IHdpc2hlcyB0byBkbyBhIG1lc2gs IG5vdCBkb2luZyBpdCBpbiB0aGUgc3ViLUlQCj4gPiA+IGxheWVyIGp1c3QgcHVzaGVzIHRvIHBy b2JsZW0gdXB3YXJkcyBpbnRvIHRoZSBJUCByb3V0aW5nIHJlYWxtLCBhbmQKPiA+ID4gdGhpcyBq dXN0IG1ha2VzIHRoaW5ncyBldmVuIG1vcmUgY29tcGxleAo+ID4gPiB0aGFuIGRvaW5nIGl0IHVu ZGVyIHN1Yi1JUC4gQ29tcGxleGl0eSB3aWxsIGJlIHRoZXJlIG5vIG1hdHRlciB3aGF0LAo+ID4g PiBpdCdzIGp1c3QgYSBxdWVzdGlvbiBvZiB3aGVyZSBvbmUgd2FudHMgdG8KPiA+ID4gYWRkcmVz cyBpdC4gSSBkbyBub3RlIHRoYXQgc3ViLUlQIGNvbXBsZXggc3RydWN0dXJlcyBhcmUgdmVyeSBw b3B1bGFyCj4gPiA+IGFuZCBkZXBsb3llZCBpbiBzb21lIGNhc2VzICg4MDIuMWQgYnJpZGdlZAo+ ID4gPiBuZXR3b3JrcykuIFBlcmhhcHMgbGlrZWx5IHRvIGJlY29tZSBldmVuIG1vcmUgc28gd2l0 aCA4MDIuMTFzIHdpdGhpbiBhCj4gPiA+IGZldyB5ZWFycy4KPiA+ID4KPiA+ID4gSSB3b3VsZCBu b3QgYmUgaW50ZXJlc3RlZCBpbiBwdXJzdWluZyBhbiBBVVRPQ09ORiBwYXRoLCBidXQgdGhpbmsg aXQKPiA+ID4gc2hvdWxkCj4gPiA+IGJlIHBvc3NpYmxlIHRvIGRvIHNvIGZvciB0aG9zZSBzbyBp bmNsaW5lZC4gRG9lcyB0aGlzIHNvdW5kIGRvYWJsZT8KPiA+ID4gQWdhaW4sIG15IGltbWVkaWF0 ZSBjb25jZXJuIGlzIHRoYXQgdGhlCj4gPiA+IGZvcm1hdCBkb2N1bWVudCBub3QgcHJldmVudCB0 aGlzIGFwcHJvYWNoLgo+ID4gPgo+ID4gPiAtZ2FicmllbAo+ID4gPgo+ID4gPgo+ID4gPiAgLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tCj4gPiA+IEZyb206IEdlb2ZmIE11bGxpZ2FuIDwgZ2Vv ZmZAbXVsbGlnYW4uY29tPgo+ID4gPiBUbzogU29vaG9uZyBEYW5pZWwgUGFyayA8c29vaG9uZ3BA Z21haWwuY29tPgo+ID4gPiBDYzogNmxvd3BhbkBpZXRmLm9yZzsgRGF2aWQgQ3VsbGVyIDxkYXZp ZC5jdWxsZXJAZ21haWwuY29tPgo+ID4gPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAyMiwgMjAw NiA2OjQxOjIxIEFNCj4gPiA+IFN1YmplY3Q6IFJlOiBbNmxvd3Bhbl0gTWVzaCBEZWxpdmVyeSBG aWVsZAo+ID4gPgo+ID4gPiBEYW5pZWwsCj4gPiA+ICAgV2hpbGUgdGhlIFdHIGxhc3QgY2FsbCBk aWQgZXhwaXJlLCBJJ20gbm90IHN1cmUgaWYgRGF2aWQgaXMgdG9vCj4gPiA+IGxhdGUuCj4gPiA+ IEkgdGhpbmsgdGhhdCBoZSByYWlzZXMgc29tZSBpbXBvcnRhbnQgY29uY2VybnMgYW5kIEknbSBu b3Qgc3VyZSB0aGF0Cj4gPiA+IHdlCj4gPiA+IHJlYWxseSBoYXZlIGNvbnNlbnN1cyBvbiB0aGUg bWVzaCBkZWxpdmVyeSBmaWVsZC4KPiA+ID4KPiA+ID4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgZnJv bSB0aGUgbGlzdCBvbiB0aGlzLiAgSSB0aGluayB0aGF0IEdhYnJpZWwgaGFzCj4gPiA+IHB1dCBm b3J0aCA0IGFsdGVybmF0aXZlcy4gIENhcnN0ZW4gaW5kaWNhdGVkIHRoYXQgaGUgdGhvdWdodCBo ZSBtaWdodAo+ID4gPiBoYXZlIGEgZGlmZmVyZW50IGFsdGVybmF0aXZlIGFuZCB3b3VsZCBwb3N0 IHRvIHRoZSBsaXN0IGVpdGhlciB0aGUKPiA+ID4gYWx0ZXJuYXRpdmUgb3IgaGlzIGNvbnNpZGVy YXRpb24gb2YgdGhlIDQgYWx0ZXJuYXRpdmVzIC0gQ2Fyc3RlbiwKPiA+ID4gcGxlYXNlCj4gPiA+ IHNlbmQgeW91ciB0aG91Z2h0cy4KPiA+ID4KPiA+ID4gSSBmZWVsIHRoYXQgdGhlIGlzc3VlIERh dmlkIHJhaXNlcyBzaG91bGQgYmUgZGVhbHQgd2l0aCBieSB0aGUgV0cKPiA+ID4gYmVjYXVzZSBJ IGRvIG5vdCB3YW50IHRvIHNlbmQgdGhlIGRyYWZ0IG9uIHRvIHRoZSBJRVNHIG9ubHkgdG8gaGF2 ZQo+ID4gPiB0aGVzZSBpc3N1ZXMgYnJvdWdodCB1cCBpbiB0aGUgSUVURiBsYXN0IGNhbGwuICBU aGVzZSBzZWVtIHJhdGhlcgo+ID4gPiBmdW5kYW1lbnRhbCB0byBtZSBhbmQgd2UgbWlnaHQgbG9v ayByYXRoZXIgZm9vbGlzaCBub3QgaGF2aW5nIHJlc29sdmVkCj4gPiA+IHRoaXMgaW4gdGhlIHdv cmtpbmcgZ3JvdXAhCj4gPiA+Cj4gPiA+IFdlIG5lZWQgc29tZSBzaWduaWZpY2FudCBkaXNjdXNz aW9uIGZyb20gdGhlIG1lbWJlcnMgb2YgdGhlIFdHLiAgVGhpcwo+ID4gPiBXRwo+ID4gPiBoYXMg YmVlbiwgbXkgc2VsZiBpbmNsdWRlZCwgcmF0aGVyIHF1aWV0IGFuZCBhcyBhIHJlc3VsdCB3ZSBo YXZlIG1vdmVkCj4gPiA+Cj4gPiA+IGF0IGEgc25haWxzIHBhY2UgZ2V0dGluZyBhbnl0aGluZyBk b25lLiAgSSBpbXBsb3JlIGV2ZXJ5b25lIHRvIHRha2UKPiA+ID4gdGltZQo+ID4gPiBhbmQgcmVh ZCB0aGUgdGhyZWFkIG9uIHRoZSBtZXNoIGZpZWxkIGFuZCBzZW5kIHlvdXIgdGhvdWdodHMsIHBy bywgY29uCj4gPiA+IG9yIG90aGVyd2lzZSB0byB0aGlzIGxpc3QuICBJZiBldmVyeW9uZSBjb250 aW51ZXMgdG8gYmUgYXBhdGhldGljCj4gPiA+IGFib3V0Cj4gPiA+IHRoaXMgd29yaywgSSBob2xk IGxpdHRsZSBob3BlIGZvciB0aGlzIFdHIGJlaW5nIHJlY2hhcnRlcmVkIHRvIGRvIGFueQo+ID4g PiBvdGhlciB3b3JrIQo+ID4gPgo+ID4gPiAgICAgZ2VvZmYKPiA+ID4KPiA+ID4gT24gRnJpLCAy MDA2LTA5LTIyIGF0IDE5OjIzICsxMDAwLCBTb29ob25nIERhbmllbCBQYXJrIHdyb3RlOgo+ID4g PiA+IERhdmlkLAo+ID4gPiA+Cj4gPiA+ID4gRmlyc3Qgb2ZmLCB5b3VyIGlzc3VlIHJhaXNpbmcg aW4gdGhpcyB0aHJlYWQgc2VlbXMgdG9vIGxhdGUgc2luY2UKPiA+ID4gb3VyCj4gPiA+ID4gb2Zm aWNpYWwgV0dMQyB3YXMgZXhwaXJlZDogIlRoaXMgTGFzdCBDYWxsIHdpbGwgZW5kIG9uIFdlZG5l c2RheSAwMgo+ID4gPiA+IEF1Z3VzdCAyMDA2IGF0IDIzNTkgVVRDLiIKPiA+ID4gPgo+ID4gPiA+ IEFueXdheSwgbXkgc2Vuc2UgaXMgbm90IHRvIHRha2UgTWVzaCBpc3N1ZSBhdCB0aGlzIHN0YWdl LiBBcyBsb25nIGFzCj4gPiA+ID4gd2UgYXJlIGxvb2tpbmcgYXQgdGhlIDZsb3dwYW4gc29sdXRp b24gZm9ybWF0LCBtZXNoIGlzIG91dCBvZiBzY29wZQo+ID4gPiBvZgo+ID4gPiA+IHRoYXQuIElu IGZhY3QsIGFzIGZhciBhcyBJIGFtIGNvbmNlcm4sIG1lc2ggYmVsb25ncyB0byAxNS40dGVjaG5v bG9neQo+ID4gPiA+IGJhc2VkIG9uIE1BQyBsYXllci4gSW5zdGVhZCwgYXMgZGVzY3JpYmVkIGlu IHRoZSByZWNoYXJ0ZXJpbmcsIHdlCj4gPiA+IHdpbGwKPiA+ID4gPiBnbyB0aHJvdWdoIGFkaG9j IGlzc3VlIGJhc2VkIG9uIElQIGxheWVyLiBUaGF0J3Mgd2h5IHdlIGFyZSBoZXJlIGluCj4gPiA+ ID4gNmxvd3BhbiB3ZyBvZiBpZXRmLgo+ID4gPiA+Cj4gPiA+ID4gQnV0LCBzb21lIHN0YWZmcyBk ZXNjcmliZWQgaW4geW91ciBtYWlsIHNlZW0gaGVscGZ1bCBmcm9tIHRoZQo+ID4gPiA2bG93cGFu Cj4gPiA+ID4gcGVyc3BlY3RpdmUsIGVzcGVjaWFsbHkgSVB2NiByZWxhdGVkIHN0dWZmcy4gSWYg YWxsb3dlZCwgcGxlYXNlCj4gPiA+IGJyaW5nCj4gPiA+ID4geW91ciBjb25jZXJuIHRvIHRoZSBu ZXh0IDZsb3dwYW4gZmFjZS10by1mYWNlIG1lZXRpbmcgaW4gU2FuIERpZWdvLgo+ID4gPiA+IFRo ZW4sIHdlIHdpbGwgaGF2ZSBmdXJ0aGVyIGRldGFpbHMgaW4gdGhlcmUgSSBiZWxpZXZlLi4uCj4g PiA+ID4KPiA+ID4gPiAtLQo+ID4gPiA+Cj4gPiA+ID4KPiA+ID4gPiBEYW5pZWwgKFNvb2hvbmcg RGFuaWVsIFBhcmspCj4gPiA+ID4gTW9iaWxlIENvbnZlcmdlbmNlIExhYm9yYXRvcnksIFNBTVNV TkcgRWxlY3Ryb25pY3MuCj4gPiA+ID4KPiA+ID4gPgo+ID4gPiA+Cj4gPiA+ID4gT24gOS8yMS8w NiwgRGF2aWQgQ3VsbGVyIDxkYXZpZC5jdWxsZXJAZ21haWwuY29tPiB3cm90ZToKPiA+ID4gPiA+ IERlYXIgQWxsLAo+ID4gPiA+ID4KPiA+ID4gPiA+IEkgd291bGQgbGlrZSB0byByYWlzZSBhIGNv bmNlcm4gYWJvdXQgdGhlIE1lc2ggRGVsaXZlcnkgRmllbGQKPiA+ID4gPiA+IGRlZmluaXRpb24g aW4gU2VjdGlvbiAxMSBvZiB0aGUgZm9ybWF0IGRvY3VtZW50LiAgV2hpbGUgdGhlIGFjdHVhbAo+ ID4gPiA+ID4gbWVzaCByb3V0aW5nIHByb3RvY29sIGlzIGFwcHJvcHJpYXRlbHkgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgdGhlCj4gPiA+ID4gPiA2bG93cGFuIEZvcm1hdCBkb2N1bWVudCwgdGhhdCBm b3JtYXQgbmVlZHMgcHJvdmlkZSB0aGUgcmF3Cj4gPiA+IHN0cnVjdHVyZQo+ID4gPiA+ID4gdXBv biB3aGljaCByb3VnaCBjb25zZW5zdXMgYW5kIHJ1bm5pbmcgY29kZSBjYW4gYmUgZmxvdXJpc2gu ICBXZQo+ID4gPiA+ID4ga25vdyB0aGF0IGxvdyBwb3dlciB3aXJlbGVzcyBtZXNoIHJvdXRpbmcg aXMgdGVjaG5pY2FsbHkgdHJpY2t5Cj4gPiA+IGFuZAo+ID4gPiA+ID4gc3Ryb25nbHkgaW5mbHVl bmNlZCBieSB0YXJnZXQgdHJhZmZpYyBsb2FkLCBwb3dlciBtYW5hZ2VtZW50Cj4gPiA+IHByb2Zp bGUsCj4gPiA+ID4gPiBuZXR3b3JrIGRlc2lnbiwgYW5kIHNvIG9uLiAgVGh1cywgaXQgaXMgcmVh c29uYWJsZSB0byBleHBlY3QgdGhhdAo+ID4gPiB0aGUKPiA+ID4gPiA+IGNvbnNlbnN1cyBidWls ZGluZyBhbmQgdGVjaG5pY2FsIHJlZmluZW1lbnQgcHJvY2VzcyB3aWxsIHJlcXVpcmUKPiA+ID4g PiA+IG9uLWdvaW5nIGV4cGVyaWVuY2Ugd2l0aCBwcm90b2NvbCBhbmQgaW1wbGVtZW50YXRpb24g YWx0ZXJuYXRpdmVzLgo+ID4gPiA+ID4gVGhlIDZsb3dwYW4gZm9ybWF0IGRvY3VtZW50IHNob3Vs ZCBzdXBwb3J0IHRoaXMgcHJvY2VzcywgYWx0aG91Z2gKPiA+ID4gaXQKPiA+ID4gPiA+IHNob3Vs ZCBub3QgZGljdGF0ZSBpdHMgY29uY2x1c2lvbi4KPiA+ID4gPiA+Cj4gPiA+ID4gPiBCYXNlZCBv biBwYXN0IGV4cGVyaWVuY2Ugd2l0aCBJUCBsYXllciAzIHJvdXRpbmcgYW5kIHdpdGggcGFzdAo+ ID4gPiA+ID4gaW50ZXJuYWxseSByb3V0ZWQgbGlua3MsIHdlIGNhbiBlc3RhYmxpc2ggYSBmZXcg cHJpbWFyeSBnb2FscyBmb3IKPiA+ID4gdGhlCj4gPiA+ID4gPiBleHByZXNzaXZlbmVzcyBvZiB0 aGUgNmxvd3BhbiBNZXNoIERlbGl2ZXJ5IEZpZWxkLgo+ID4gPiA+ID4gICAgKDEpIEl0IHNob3Vs ZCBzdXBwb3J0IHRoZSB2aXNpYmlsaXR5IGludG8gdGhlIHJvdXRlZCAxNS40IGNsb3VkCj4gPiA+ ID4gPiBuZWNlc3NhcnkgdG8gZGV2ZWxvcCwgZGVidWcsIGRpYWdub3NlLCBhbmQgbWFuYWdlIHRo ZSAxNS40IGNsb3VkLgo+ID4gPiA+ID4gICAgKDIpIEl0IHNob3VsZCBzdXBwb3J0IHRoZSBhYmls aXR5IHRvIGRlZmluZSwgZGV2ZWxvcCBhbmQKPiA+ID4gY29tcGFyZQo+ID4gPiA+ID4gcm91dGlu ZyBwcm90b2NvbHMgYW5kIHBvc3NpYmx5IHN1cHBvcnQgdGhlIHByZXNlbmNlIG9mIG11bHRpcGxl Cj4gPiA+ID4gPiBwcm90b2NvbHMgZm9yIHdpZGVseSBkaWZmZXJpbmcgdXNhZ2UgY2FzZXMuCj4g PiA+ID4gPiAgICAoMykgSXQgbmVlZHMgdG8gYmUgcG9zc2libGUgZm9yIG5vZGVzIHRvIGNvbW11 bmljYXRlIHdpdGggb3RoZXIKPiA+ID4gbm9kZXMKPiA+ID4gPiA+IGluIHRoZSBjbG91ZCBpbiBv cmRlciB0byBkaXNjb3ZlciBhbmQgbmVnb3RpYXRlIGpvaW5pbmcgdGhlIGNsb3VkCj4gPiA+ID4g PiB3aXRob3V0IGpvaW5pbmcgdGhlIGNsb3VkIGEgcHJpb3JpIHRocm91Z2ggc29tZSBtZWNoYW5p c20gdGhhdCBpcwo+ID4gPiA+ID4gb3BhcXVlIHRvIElQIGFuZCBhYm92ZS4KPiA+ID4gPiA+Cj4g PiA+ID4gPiAoMSkgaGFzIGhpc3RvcmljYWxseSBiZWVuIGFkZHJlc3NlZCB0aHJvdWdoIHZhcmlv dXMgZm9ybXMgb2YKPiA+ID4gc291cmNlCj4gPiA+ID4gPiByb3V0aW5nLiAgSXQgc2hvdWxkIGJl IHBvc3NpYmxlIHRvIGRvIHRoZSBlcXVpdmFsZW50IG9mIHRyYWNlcm91dGUKPiA+ID4gPiA+IHRo cm91Z2ggdGhlIDE1LjQgbWVzaCBhbmQgdGhpcyBzaG91bGQgYmUgYWNjZXNzaWJsZSBpbiBzb21l IGZvcm0KPiA+ID4gdGhyb3VnaCBJUAo+ID4gPiA+ID4gc28KPiA+ID4gPiA+IGhpZ2hlciBsYXll cnMgY2FuIGJlIGJ1aWx0IHRvIHBlcmZvcm0gdGhlIG1hbmFnZW1lbnQuICBUaGUgY3VycmVudAo+ ID4gPgo+ID4gPiA+ID4gTWVzaCBEZWxpdmVyeSBGaWVsZCBkZWZpbml0aW9uIHNlZW1zIHRvIHBy b2hpYml0IGFueSBmb3JtIG9mCj4gPiA+IHNvdXJjZSByb3V0aW5nLgo+ID4gPiA+ID4gSXQgYXNz dW1lcyB0aGF0IHRoZSByb3V0aW5nIHRhYmxlcyBhcmUgYWxsIHNldCB1cCBhbmQgY29ycmVjdCBz bwo+ID4gPiB0aGF0Cj4gPiA+ID4gPiB0aGUgZm9yd2FyZGVyIGNhbiAic3dpenpsZSIgdGhlIGRl c3RpbmF0aW9uIGFkZHJlc3MgZmllbGQgb2YgdGhlCj4gPiA+IDE1LjQKPiA+ID4gPiA+IGhlYWRl ciB3aXRoIGEgdGFibGUgZW50cnkuICAoVGhlIGV4cGVyaWVuY2Ugb2YgSVAgb3ZlciBBVE0gYW5k IHRoZQo+ID4gPiA+ID4gdGhvdXNhbmRzIG9mIHBhZ2VzIG9mIHRoZSBRODNiIHNpZ25hbGxpbmcg cHJvdG9jb2wgcmVxdWlyZWQgdG8gc2V0Cj4gPiA+IHVwCj4gPiA+ID4gPiBhbGwgdGhlIHRhYmxl cyBpbiBhZHZhbmNlIG91Z2h0IHRvIGdpdmUgdXMgYSBsaXR0bGUgcGF1c2UKPiA+ID4gaGVyZS4p ICBUaGUKPiA+ID4gPiA+IGlkZWEgb2Ygc3VwcG9ydGluZyB0YWJsZS1kcml2ZW4gcm91dGluZyBh bmQgdGhlcmVieSBzZXBhcmF0aW5nIHRoZQo+ID4gPiA+ID4gcm91dGUgZm9ybWF0aW9uIGZyb20g dGhlIGZvcndhcmRpbmcgZW5naW5lIGlzIGEgZ29vZCBvbmUsIGJ1dAo+ID4gPiB0aGVyZQo+ID4g PiA+ID4gbmVlZHMgdG8gYmUgZW5vdWdoIGV4cHJlc3NpdmUgcG93ZXIgdG8gc3VwcG9ydCB0aGUg cHJvdG9jb2xzIHRoYXQKPiA+ID4gd2lsbAo+ID4gPiA+ID4gZXN0YWJsaXNoIGFuZCBtYW5hZ2Ug dGhvc2UgdGFibGVzIChyYXRoZXIgdGhhbiByZWx5aW5nIG9uIGFuCj4gPiA+IG9wYXF1ZQo+ID4g PiA+ID4gb3V0LW9mLWJhbmQgc2lnbmFsaW5nIG1lY2hhbmlzbSkgYW5kIHRoZXJlIG5lZWRzIHRv IGJlIHRoZSBhYmlsaXR5Cj4gPiA+IHRvCj4gPiA+ID4gPiBxdWVyeSBhbmQgdmFsaWRhdGUgdGhv c2UgdGFibGVzIHdpdGhvdXQgcmVseWluZyBvbiBvdXQtb2YtYmFuZAo+ID4gPiA+ID4gbWVjaGFu aXNtcy4KPiA+ID4gPiA+Cj4gPiA+ID4gPiAoMikgaGFzIGhpc3RvcmljYWxseSBiZSBhZGRyZXNz ZWQgd2l0aCBwcm90b2NvbCBpZGVudGlmaWVycyBhbmQKPiA+ID4gPiA+IG9wdGlvbnMuICBBcyB3 ZSB3ZW50IHRocm91Z2ggdGhlIHZhcmlvdXMgUklQLCBPU1BGLCBldGMuIHdlIGRpZG4ndAo+ID4g PiA+ID4gbmVlZCB0byBnbyBiYWNrIGFuZCByZWRlZmluZSB0aGUgZm9ybWF0IGRvY3VtZW50cy4g IFRoZXJlIHdhcwo+ID4gPiBlbm91Z2gKPiA+ID4gPiA+IGV4cHJlc3NpdmVuZXNzIGZvciB0b3Bv bG9neSBmb3JtYXRpb24gYW5kIHJvdXRpbmcgdG8gZXZvbHZlLiAgTm90Cj4gPiA+IGFsbAo+ID4g PiA+ID4gbmV0d29ya3MgbmVlZCB0byBzdXBwb3J0IGFsbCBwcm90b2NvbHMuICBUaGF0IGhhcyBi ZWVuIHRoZSBuZXR3b3JrCj4gPiA+ID4gPiBkZXNpZ25lcnMnIGRldGVybWluYXRpb24uICBUaGUg dW5kZXJseWluZyBzdHJ1Y3R1cmUgcHJvdmlkZWQgdGhlCj4gPiA+ID4gPiBwcmltaXRpdmVzLCBh bGxvd2luZyBzb2x1dGlvbnMgKGFuZCBjb25zZW5zdXMpIHRvIGV2b2x2ZS4gIFdlIHdhbnQKPiA+ ID4gdG8KPiA+ID4gPiA+IGF2b2lkIGNyZWF0aW5nIGEgIndpbm5lciB0YWtlIGFsbCIgc3RydWN0 dXJlIHdoZXJlIHRoZXJlIGlzIG5vCj4gPiA+IHJvb20KPiA+ID4gPiA+IGZvciBldm9sdXRpb24g YW5kIGRldmVsb3BtZW50LiAgSXQgaXMgcG9zc2libGUgdGhhdCBBT0RWLCBvcgo+ID4gPiBUaW55 QU9EViwKPiA+ID4gPiA+IG9yIERTUiwgb3IgR1BTUiBvciBwb3NzaWJseSBvbmUgb2Ygc2V2ZXJh bCBvdGhlciBhbHRlcm5hdGl2ZXMgaXMKPiA+ID4gdGhlIHJpZ2h0Cj4gPiA+ID4gPiBzb2x1dGlv bi4gIEhvd2V2ZXIsIHRoZXJlIGlzIGxpdHRsZSBldmlkZW5jZSBvZiBvbmUgaGF2aW5nIGNsZWFy Cj4gPiA+IHN1cGVyaW9yaXR5Cj4gPiA+ID4gPiBhdAo+ID4gPiA+ID4gdGhpcyB0aW1lLCBkZXNw aXRlIG51bWVyb3VzIGhpZ2ggcHJvZmlsZSBlZmZvcnRzLiAgV2Ugc2hvdWxkIGJlCj4gPiA+IGRl ZmluaW5nIHRoZQo+ID4gPiA+ID4gY2FudmFzIHVwb24gd2hpY2ggY29tcGV0aW5nIGFsdGVybmF0 aXZlcyBjYW4gYmUgZGVmaW5lZCBhbmQKPiA+ID4gdmV0dGVkLgo+ID4gPiA+ID4KPiA+ID4gPiA+ ICgzKSBoYXMgaGlzdG9yaWNhbGx5IGJlZW4gYWRkcmVzc2VkIGJ5IGEgbGltaXRlZCBhYmlsaXR5 IHRvCj4gPiA+ID4gPiBjb21tdW5pY2F0ZSBvbiB0aGUgbGluayB0byBhIGNydWRlbHkgZGVmaW5l ZCBzZXQgb2Ygbm9kZXMgaW4gb3JkZXIKPiA+ID4gdG8KPiA+ID4gPiA+IGJvb3RzdHJhcCB0aGUg ZGlzY292ZXJ5LCBqb2luLCBhZGRyZXNzIGFzc2lnbm1lbnQsIG5lZ290aWF0aW9uLAo+ID4gPiBl dGMuCj4gPiA+ID4gPiBNb3N0IHN1Y2Nlc3NmdWwgbGlua3MgdW5kZXIgSVAgbG9vayBlaXRoZXIg bGlrZSBhIGJyb2FkY2FzdCBtZWRpdW0KPiA+ID4gb3IKPiA+ID4gPiA+IGEgcG9pbnQtdG8tcG9p bnQgbGluayAoYSBkZWdlbmVyYXRpdmUgYnJvYWRjYXN0KS4gIFRoaXMgYWxsb3dzCj4gPiA+IEFS UCwKPiA+ID4gPiA+IFJBUlAsIEJPT1RQLCBESENQLCBldGMuIHRvIGdhaW4gaGlnaGVyIGxldmVs IGFjY2Vzc2liaWxpdHkgYW5kCj4gPiA+ID4gPiBhZGRyZXNzaWJpbGl0eSB0aHJvdWdoIHRoZSBs aW5rLiAgTGlua3MgdGhhdCByZXF1aXJlIGNvbXBsZXgKPiA+ID4gPiA+IHNpZ25hbGluZywgZGlz Y292ZXJ5LCBqb2luaW5nIGFuZCBjb29yZG5hdGlvbiBiZWxvdyB0aGUgbGluawo+ID4gPiBsYXll ciwKPiA+ID4gPiA+IGluY2x1ZGluZyBBVE0sIEJsdWV0b290aCAocGljb25ldHMgYW5kIHNjYXR0 ZXIgbmV0cyksIGFuZCBJUkRBCj4gPiA+IGhhdmUKPiA+ID4gPiA+IHByb3ZlZCBvbmVyb3VzIGZv ciBJUCBhbmQgaGF2ZSBiZWVuIHJlbGVnYXRlZCB0byBmYXIgbGVzcyBnZW5lcmFsCj4gPiA+ID4g PiB1c2FnZSBzY2VuYXJpb3MgLSBzdWNoIGFzIHRoZSBkZXNrdG9wIFVTQiByZXBsYWNlbWVudC4g IEV2ZW4KPiA+ID4gdGhvdWdoCj4gPiA+ID4gPiB0aGUgcmFkaW8gaXMgYSBicm9hZGNhc3QgbWVk aXVtLCB0aGUgY2hhbGxlbmdlIGluIGEgcm91dGVkIGxpbmsgaXMKPiA+ID4gPiA+IHRoYXQgdGhl IGxpbmsgaXMgbm90IGJ5IGRlZmF1bHQgYSBsaW5rLXdpZGUgYnJvYWRjYXN0IHBoeS4gIFRoZXJl Cj4gPiA+ID4gPiBhcmUgdHdvIG5hdHVyYWwgbm90aW9ucyBvZiAiYnJvYWRjYXN0IiBpbiBhIGxv d3Bhbi4gIChpKSBUaGUKPiA+ID4gcGh5c2ljYWwKPiA+ID4gPiA+IG5laWdoYm9ycyB0aGF0IGhh cHBlbiB0byByZWNlaXZlIGEgdHJhbnNtaXNzaW9uIGJlY2F1c2UgdGhleSBhcmUKPiA+ID4gY2xv c2UKPiA+ID4gPiA+IGVub3VnaCB0byBwaWNrIHVwIHRoZSBzaWduYWwgYW5kIGhhdmUgdGhlaXIg cmFkaW9zIHR1cm5lZCBvbiB0bwo+ID4gPiA+ID4gcmVjZWl2ZS4gIChpaSkgVGhlIGVudGlyZSBj b2xsZWN0aW9uIG9mIG5vZGVzIHRoYXQgY2FuIGJlIHJlYWNoZWQKPiA+ID4gYnkgYQo+ID4gPiA+ ID4gbXVsdGlob3AgZGlzc2VtaW5hdGlvbiAoZmxvb2QpLiAgQm90aCBvZiB0aGVzZSBhcmUgZXh0 cmVtZWx5Cj4gPiA+IHVzZWZ1bCBpbgo+ID4gPiA+ID4gYm9vdHN0cmFwcGluZyBoaWdoZXIgbGV2 ZWxzLCBpbmNsdWRpbmcgcm91dGluZywgYW5kIHNob3VsZCBiZQo+ID4gPiA+ID4gYWRkcmVzc2Vk IGluIHRoZSBmb3JtYXQgZG9jdW1lbnQuICBBZGRpdGlvbmFsbHksIGl0IGlzIG5vdAo+ID4gPiA+ ID4gbmVjY2Vzc2FyeSB0byB1c2UgdGhlIDgwMi4xNS40IGJlYWNvbmluZyBtZWNoYW5pc20gdG8g YnJpbmcgdXAgSVAKPiA+ID4gb3Zlcgo+ID4gPiA+ID4gYSAxNS40IGxpbmsuICBQcm92aWRpbmcg c29tZSBmb3JtcyBvZiBicm9hZGNhc3QgdXNpbmcgZGF0YSBmcmFtZXMKPiA+ID4gPiA+IG1ha2Vz IHRoZSA4MDIuMTUuNCBmb3JtYXQgbXVjaCBtb3JlIGxpa2UgODAyLjExIGFuZCBvdGhlciBsaW5r cwo+ID4gPiB0aGF0Cj4gPiA+ID4gPiBoYXZlIHByb3ZlZCB2ZXJ5IHN1aXRhYmxlIGZvciBJUC4g IEZldywgaWYgYW55LCBvZiB0aGUgcHVibGljIDE1LjRyb3V0aW5nCj4gPiA+ID4gPiBsYXllcnMg ZGV2ZWxvcGVkCj4gPiA+ID4gPiBieSB0aGUgVGlueU9TIGNvbW11bml0eSB1dGlsaXplIGJlYWNv biBwYWNrZXRzLgo+ID4gPiA+ID4KPiA+ID4gPiA+IFRoZSByZWNvZ25pdGlvbiB0aGF0IHRoZSBj dXJyZW50IE1lc2ggRGVsaXZlcnkgZmllbGQgbWF5IGJlIHRvCj4gPiA+IHJlc3RyaWN0aXZlCj4g PiA+ID4gPiBpcyBpbnRpbWF0ZWQgYnkgdGhlIG5lZWQgdG8gZGVmaW5lIGEgc2Vjb25kIGZvcm0g b2YgdGhlIGhlYWRlciBmb3IKPiA+ID4gPiA+IG11bHRpY2FzdCAoYW5kIGxpbmsgbG9jYWwgYnJv YWRjYXN0KSB0aGF0IGluY2x1ZGVzIGEgc2VxdWVuY2UKPiA+ID4gbnVtYmVyLgo+ID4gPiA+ID4g VGhlIG1lc2ggaGVhZGVyIGZpZWxkIHR5cGUgaXMgZGVmaW5lZCBieSB3aGV0aGVyIHRoZSBkZXN0 aW5hdGlvbgo+ID4gPiA+ID4gYWRkcmVzcyBpcyB1bmljYXN0IG9yIG11bHRpY2FzdC4gVGhlIGRv Y3VtZW50IHN0YXRlcyB0aGF0IHRoZSB1c2UKPiA+ID4gb2YKPiA+ID4gPiA+IHN1Y2ggYSBzZXF1 ZW5jZSBudW1iZXIgaXMgb3V0IG9mIHNjb3BlLiBIb3dldmVyLCB0aGUgb2JzZXJ2YXRpb24KPiA+ ID4gdGhhdAo+ID4gPiA+ID4gdGhhdCBleHRyYSBpbmZvcm1hdGlvbiBtYXkgbmVlZCB0byBiZSBp bmNsdWRlZCBkZXBlbmRpbmcgb24gaG93Cj4gPiA+ID4gPiBwYWNrZXRzIGFyZSByb3V0ZWQgZnVy dGhlciBzdWdnZXN0cyB0aGF0IG1vcmUgY2FyZWZ1bCBmb3JtYXQKPiA+ID4gPiA+IGRlZmluaXRp b24gaXMgbmVlZGVkIHRvIHN1cHBvcnQgZnV0dXJlIGRldmVsb3BtZW50IG9mIG1lc2gKPiA+ID4g cm91dGluZy4KPiA+ID4gPiA+Cj4gPiA+ID4gPiBIYXZlIGZvbGtzIHdobyBoYXZlIGJlZW4gZGV2 ZWxvcGluZyBtZXNoIGxheWVycyBmb3IgbG93cGFuNiBmZWx0Cj4gPiA+IHRoYXQKPiA+ID4gPiA+ IHRoZSBleGlzdGluZyBNZXNoIERlbGl2ZXJ5IEZpZWxkIGlzIHRvbyByZXN0cmljdGl2ZT8KPiA+ ID4gPiA+Cj4gPiA+ID4gPgo+ID4gPiA+ID4gRGF2aWQgRS4gQ3VsbGVyCj4gPiA+ID4gPiBVQyBC ZXJrZWxleQo+ID4gPiA+ID4gY3VsbGVyQGNzLmJlcmtlbGV5LmVkdQo+ID4gPiA+ID4KPiA+ID4g PiA+Cj4gPiA+ID4gPgo+ID4gPiA+ID4KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4gPiA+ID4gPiA2bG93cGFuIG1haWxpbmcgbGlzdAo+ ID4gPiA+ID4gNmxvd3BhbkBpZXRmLm9yZwo+ID4gPiA+ID4gaHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vNmxvd3Bhbgo+ID4gPiA+ID4KPiA+ID4gPiA+Cj4gPiA+ID4gPgo+ ID4gPiA+Cj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiA+ID4gPiA2bG93cGFuIG1haWxpbmcgbGlzdAo+ID4gPiA+IDZsb3dwYW5AaWV0Zi5v cmcKPiA+ID4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFu Cj4gPiA+Cj4gPiA+Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj4gPiA+IDZsb3dwYW4gbWFpbGluZyBsaXN0Cj4gPiA+IDZsb3dwYW5AaWV0Zi5v cmcKPiA+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3Bhbgo+ ID4gPgo+ID4gPgo+ID4gPgo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+ID4gPiA2bG93cGFuIG1haWxpbmcgbGlzdAo+ID4gPiA2bG93cGFuQGll dGYub3JnCj4gPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dw YW4KPiA+ID4KPiA+ID4KPiA+ID4KPiA+Cj4gPgo+ID4gLS0KPiA+IEtpLUh5dW5nIEtpbSAoseix 4sf8LCDQ3dHD+vspCj4gPiBBc3NvY2lhdGUgUHJvZmVzc29yCj4gPiBEaXZpc2lvbiBvZiBJbmZv cm1hdGlvbiBhbmQgQ29tcHV0ZXIgRW5nLiwgQWpvdSBVbml2ZXJzaXR5LCBTdXdvbiwgS29yZWEK PiA+IDQ0Mi03NDkKPiA+IFRlbDogKzgyLTMxLTIxOS0yNDMzLCBDZWw6ICs4Mi0xNy03NjAtMjU1 MSwgIEZheDogKzgyLTMxLTIxOS0yNDMzCj4gPiBodHRwOi8vd3d3LjZsb3dwYW4ub3JnCj4KPgo+ Cj4KPiAtLQo+IERhdmlkIEUuIEN1bGxlcgo+IEFyY2hlZCBSb2NrIENvcnBvcmF0aW9uCj4gMjE2 OCBTaGF0dHVjayBBdmUKPiBCZXJrZWxleSwgQ0EgOTQ3MDQKPiB3d3cuYXJjaGVkcm9jay5jb20K Pgo+Cj4KCgoKLS0gCktpLUh5dW5nIEtpbSAoseix4sf8LCDQ3dHD+vspCkFzc29jaWF0ZSBQcm9m ZXNzb3IKRGl2aXNpb24gb2YgSW5mb3JtYXRpb24gYW5kIENvbXB1dGVyIEVuZy4sIEFqb3UgVW5p dmVyc2l0eSwgU3V3b24sIEtvcmVhCjQ0Mi03NDkKVGVsOiArODItMzEtMjE5LTI0MzMsIENlbDog KzgyLTE3LTc2MC0yNTUxLCAgRmF4OiArODItMzEtMjE5LTI0MzMKaHR0cDovL3d3dy42bG93cGFu Lm9yZwo= ------=_Part_22624_17963809.1159575371905 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5JIHRoaW5rIHRoZSBmbGV4aWJpbGl0eSBzaG91bGQgYmUgZmluZS4gU28sIHdoYXQgaXMg ZmluYWwgbG9vayBvZiB0aGUgbWVzaCBkZWxpdmVyeSBmaWVsZD88YnI+PGJyPiZuYnNwOzwvZGl2 Pgo8ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gOS8zMC8wNiwgPGIgY2xhc3M9Imdt YWlsX3NlbmRlcm5hbWUiPmdhYnJpZWwgbW9udGVuZWdybzwvYj4gJmx0OzxhIGhyZWY9Im1haWx0 bzpnYWJyaWVsX21vbnRlbmVncm9fMjAwMEB5YWhvby5jb20iPmdhYnJpZWxfbW9udGVuZWdyb18y MDAwQHlhaG9vLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj4KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHgg MC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+CjxkaXY+CjxkaXYgc3R5bGU9IkZP TlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRp bWVzLCBzZXJpZiI+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRp bWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+T2ssIGl0IHNlZW1zIGxpa2Ug Zm9sa3Mgd291bGQgbGlrZSB0byBoYXZlIG1vcmUgZmxleGliaWxpdHkgaW4gdGhlIGhlYWRlci4g SSdtIGp1c3QgaGF2aW5nIGEgaGFyZCB0aW1lIHRyYW5zbGF0aW5nIHRoYXQ8L2Rpdj4KPGRpdiBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLCBuZXcg eW9yaywgdGltZXMsIHNlcmlmIj50byBhY3R1YWwgYml0cyBhbmQgYnl0ZXMgd2l0aGluIHRoZSBo ZWFkZXIgZm9ybWF0cywgYW5kIGhvdyBtdWNoIGZsZXhpYmlsaXR5IGlzIGZpbmUuIDwvZGl2Pgo8 ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4s IG5ldyB5b3JrLCB0aW1lcywgc2VyaWYiPiZuYnNwOzwvZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJ WkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywg c2VyaWYiPlRoZSBmaXJzdCBwYWNrZXQgZm9ybWF0IGhhcyA1IGJpdHMgb2YgcmVzZXJ2ZWQgZmll bGQ6PC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVz IG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+PGZvbnQgZmFjZT0iY291cmllciwg bW9uYWNvLCBtb25vc3BhY2UsIHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMzxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx Cjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTEZ8Jm5ic3A7IHByb3RfdHlwZSZuYnNwOyZuYnNwOyZu YnNwOyB8TXwgcnN2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxQYXlsb2FkIChvciBNZXNoIERl bGl2ZXJ5IEhkcikuLi48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r Cjxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEZpZ3VyZSAxOiBMb1dQQU4gdW5mcmFnbWVudGVkIGVuY2Fwc3VsYXRpb24gaGVhZGVyIGZvcm1h dDwvZm9udD48YnI+Jm5ic3A7PC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9O VC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+T25lIGJp dCBvdXQgb2YgdGhhdCByZXNlcnZlZCBmaWVsZCZuYnNwO2lzIHdoYXQgTWFyaW8gTWFvIHN1Z2dl c3RzIHdlIHVzZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZSB0d28gY3VycmVudCBmbGF2b3Jz PC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5l dyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+b2YgbWVzaCBkZWxpdmVyeSBoZWFkZXIg KHVuaWNhc3QgdnMgYmNhc3QvbWNhc3QpLiBJcyB0aGlzIHN1ZmZpY2llbnQgZmxleGliaWxpdHk/ PC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5l dyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+Jm5ic3A7PC9kaXY+CjxkaXYgc3R5bGU9 IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmss IHRpbWVzLCBzZXJpZiI+VGhlIGlzc3VlIGlzIHRoYXQgdGhlcmUgaXMgbm8gc3VjaCBmbGV4aWJp bGl0eSBpbiB0aGUgdHdvIG90aGVyIGhlYWRlciBmb3JtYXRzLCBidXQgd2UgY2FuIGNlcnRhaW5s eSBhZGQgc3VjaCBhIAo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0 aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywgc2VyaWYiPnJlc2VydmVkIGZpZWxkIGFu ZCBtYWtlIGFsbCAzIGhlYWRlciBmb3JtYXRzIHRoZSBzYW1lIHVwIHRvIHRoZSBmaXJzdCAxNiBi aXRzLiBQZXJoYXBzIGFsb25nIHRoZXNlIGxpbmVzPC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0la RTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBz ZXJpZiI+KG5vdGljZSB0aGUgbmV3ICZxdW90O3Jlc2VydmVkJnF1b3Q7IGZpZWxkJm5ic3A7YW5k IHRoZSBjb3JyZXNwb25kaW5nIDUmbmJzcDtiaXQmbmJzcDtzaGlmdCBmb3IgZGF0YWdyYW1fc2l6 ZSBhbmQgZGF0YWdyYW1fdGFnKSZuYnNwOzo8L2Rpdj48L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMs IHNlcmlmIj4mbmJzcDs8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZB TUlMWTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmIj48Zm9udCBmYWNl PSJjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAzPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEKPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxi cj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBMRnwmbmJzcDsgcHJvdF90eXBlJm5i c3A7Jm5ic3A7Jm5ic3A7IHxNfHJlc2VydmVkIHwmbmJzcDsmbmJzcDsgZGF0YWdyYW1fc2l6ZSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8ZGdyYW1fdGFnfDxicj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 ZGdyYW1fdGFnfCBQYXlsb2FkIChvciBNZXNoIERlbGl2ZXJ5IEhkcikuLi48YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9mb250PjwvZGl2Pgo8ZGl2IHN0eWxlPSJG T05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0 aW1lcywgc2VyaWYiPjxmb250IGZhY2U9ImNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5z LXNlcmlmIj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMg bmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmIj4mbmJzcDs8YnI+Jm5ic3A7PC9kaXY+ PC9mb250Pjxmb250IGZhY2U9ImNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDI6IExv V1BBTiBmaXJzdCBmcmFnbWVudCBlbmNhcHN1bGF0aW9uIGhlYWRlciBmb3JtYXQKPC9mb250Pjwv ZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcg cm9tYW4sIG5ldyB5b3JrLCB0aW1lcywgc2VyaWYiPjxmb250IGZhY2U9IkNvdXJpZXIiPjwvZm9u dD4mbmJzcDs8L2Rpdj48L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZB TUlMWTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmIj48Zm9udCBmYWNl PSJjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAzPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEKPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxi cj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBMRnxkYXRhZ3JhbV9vZmZzZXR8TXxy ZXNlcnZlZCB8Jm5ic3A7Jm5ic3A7IGRhdGFncmFtX3NpemUmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfGRncmFtX3RhZ3w8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r Cjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfGRncmFtX3RhZ3wgUGF5bG9hZCAo b3IgTWVzaCBEZWxpdmVyeSBIZHIpLi4uPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3VyZSAzOiBMb1dQQU4gc3Vi c2VxdWVudCBmcmFnbWVudChzKSBlbmNhcHN1bGF0aW9uIGhlYWRlciBmb3JtYXQ8L2ZvbnQ+PGJy PiZuYnNwOwo8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTog dGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmIj4mbmJzcDs8L2Rpdj4KPGRp diBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLCBu ZXcgeW9yaywgdGltZXMsIHNlcmlmIj4mbmJzcDs8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNl cmlmIj5Xb3VsZCB0aGlzIGJlIGVub3VnaD8gSWYgbm90LCBob3cgbWFueSBiaXRzIHNob3VsZCBi ZSBhbGxvY2F0ZWQ/IFNob3VsZCB0aGVyZSBiZSBhIHZlcnNpb24gZmllbGQgaW4gYWRkaXRpb24g PC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5l dyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+KGFzIHN1Z2dlc3RlZCBieSBWaXB1bCBh IHdoaWxlIGJhY2spPyBXaGF0IGNoYW5nZXMgaW4gdGhlIGZvcm1hdCBhcmUgc3VnZ2VzdGVkPyBG b2xrcywgcGxlYXNlIGJlIHNwZWNpZmljPC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJw dDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+ YXMgdG8gdGhlIHN1Z2dlc3RlZCBjaGFuZ2VzIGJ5IHNlbmRpbmcgaGVhZGVyIGZvcm1hdHMgd2l0 aCBjbGVhcmx5IHByb3Bvc2VkIGZpZWxkcywgZXRjLjwvZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJ WkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywg c2VyaWYiPiZuYnNwOzwvZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFN SUxZOiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywgc2VyaWYiPnRueCw8L2Rpdj48 c3BhbiBjbGFzcz0ic2ciPgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZ OiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywgc2VyaWYiPiZuYnNwOzwvZGl2Pgo8 ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4s IG5ldyB5b3JrLCB0aW1lcywgc2VyaWYiPi1nYWJyaWVsPGJyPjxicj4mbmJzcDs8L2Rpdj48L3Nw YW4+CjxkaXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzEwZGZiNjgyOTYzYjdiYWJfMiI+CjxkaXYg c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3 IHlvcmssIHRpbWVzLCBzZXJpZiI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tPGJyPkZyb206 IERhdmlkIEN1bGxlciAmbHQ7PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3 aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpkYXZpZC5jdWxsZXJAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+CmRhdmlkLmN1bGxlckBnbWFpbC5jb208L2E+Jmd0Ozxicj5UbzogS2kt SHl1bmcgS2ltICZsdDs8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRv dyxldmVudCx0aGlzKSIgaHJlZj0ibWFpbHRvOmtraW04NkBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5ra2ltODZAZ21haWwuY29tPC9hPiZndDs8YnI+Q2M6IGdhYnJpZWwgbW9udGVuZWdybyAm bHQ7PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhp cykiIGhyZWY9Im1haWx0bzpnYWJyaWVsX21vbnRlbmVncm9fMjAwMEB5YWhvby5jb20iIHRhcmdl dD0iX2JsYW5rIj4KZ2FicmllbF9tb250ZW5lZ3JvXzIwMDBAeWFob28uY29tPC9hPiZndDs7IEdl b2ZmIE11bGxpZ2FuICZsdDs8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdp bmRvdyxldmVudCx0aGlzKSIgaHJlZj0ibWFpbHRvOmdlb2ZmQG11bGxpZ2FuLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmdlb2ZmQG11bGxpZ2FuLmNvbTwvYT4mZ3Q7OyBTb29ob25nIERhbmllbCBQYXJr ICZsdDsKPGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQs dGhpcykiIGhyZWY9Im1haWx0bzpzb29ob25ncEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5z b29ob25ncEBnbWFpbC5jb208L2E+Jmd0OzsgPGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVu RXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzo2bG93cGFuQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+CjZsb3dwYW5AaWV0Zi5vcmc8L2E+PGJyPlNlbnQ6IEZyaWRheSwg U2VwdGVtYmVyIDI5LCAyMDA2IDg6Mzg6NTYgQU08YnI+U3ViamVjdDogUmU6IFs2bG93cGFuXSBN ZXNoIERlbGl2ZXJ5IEZpZWxkPGJyPjxicj5JdCBjZXJ0YWlubHkgd291bGQgYmUgYSBzaGFtZSB0 byBnZXQgaW50byBhIHBvc2l0aW9uIHdoZXJlIHRoZSBlbmNvZGluZyBpcyBzbyBzbyBjb25zdHJh aW5lZCB0aGF0IHRoZXJlIHdhcyBub3QgYSBtZWFucyBvZiBhY2NvbW9kYXRpbmcgYWRkaXRpb25h bCBjYXBhYmlsaXRpZXMgdGhhdCBhcmUgcmV2ZWFsZWQgdGhyb3VnaCBkZWVwZXIgaW1wbGVtZW50 YXRpb24gYW5kIHVzYWdlIGV4cGVyaWVuY2UuJm5ic3A7IFRoZSBJUCBjb21tdW5pdHkgaGFzIGhp c3RvcmljYWxseSBiZWVuIHZlcnkgZ29vZCBhdCBwbGFubmluZyBmb3IgY2hhbmdlLiZuYnNwOyBP cHRpb25zIGZpZWxkcyBhbmQgbGVhdmluZyBhIGxpdHRsZSByb29tIGluIHRoZSBpbml0aWFsIGVu Y29kaW5ncyBhcmUgZXNzZW50aWFsIHRvIHRoYXQuJm5ic3A7IEFzIG11Y2ggYXMgd2UgdHJ5LCB3 ZSBzZWxkb20gZ2V0IGV2ZXJ5IGFzcGVjdCBvZiB0aGUgcHJvdG9jb2wgZXhhY3RseSByaWdodCB0 aGUgZmlyc3QgdGltZS4mbmJzcDsgSXQgaXMgdW5kZXJzdGFuZGFibGUgdGhhdCB3aXRoIHNvIG11 Y2ggZm9jdXMgYmVpbmcgcGxhY2Ugb24gaGVhZGVyIGNvbXByZXNzaW9uIHRoYXQgaXQgaXMgaGFy ZCB0byBsZWF2ZSBhbnkgc3BhY2UgdW5jbGFpbWVkLiZuYnNwOyBIb3dldmVyLCB0aGF0IGNvbnRp bmdlbmN5IHBsYW5uaW5nIGFuZCBmbGV4aWJpbGl0eSBtYXkgYmUgbW9yZSBjcml0aWNhbCB0byBl dmVudHVhbCBhZG9wdGlvbiB0aGFuIHNxdWVlemluZyBvdXQgZXZlcnkgdW5uZWNjZXNzYXJ5IGJp dC4mbmJzcDsmbmJzcDsgQXMgd2UgbG9vayBhdCB0aGUgZGVzaXJlZCAmcXVvdDtydXNoIHRvIGZp bmlzaCZxdW90OyBpdCBpcyBpbXBvcnRhbnQgdG8gdmVyaWZ5IHRoYXQgdGhlIHByb3Bvc2VkIGZy YW1ld29yayBwZXJtaXRzIGVub3VnaCBleHByZXNzaXZlIHBvd2VyIHRvIGFkZHJlc3MgdGhlIGlz c3VlcyB0aGF0IGhhdmUgbm90IHlldCBiZWVuIGZ1bGx5IHZldHRlZC4mbmJzcDsgWW91IGNhbm5v dCBleHBhbmQgdGhlIGZvcm1hdCwgb25seSB3b3JrIHdpdGhpbiBpdC4gCjxicj48YnI+CjxkaXY+ PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA5LzI2LzA2LCA8YiBjbGFzcz0iZ21haWxfc2Vu ZGVybmFtZSI+S2ktSHl1bmcgS2ltPC9iPiAmbHQ7PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5P cGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpra2ltODZAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub2ZvbGxvdyI+a2tpbTg2QGdtYWlsLmNvbQo8L2E+ Jmd0OyB3cm90ZTo8L3NwYW4+IAo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHQgMHB0IDBwdCAwLjhleDsgQk9SREVSLUxF RlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkIj4KPGRpdj5HYWJyaWVsLDwvZGl2Pgo8ZGl2 PiZuYnNwOzwvZGl2Pgo8ZGl2PkkgYW0gc29ycnkgZm9yIHRoaXMgbGF0ZSByZXBseS48L2Rpdj4K PGRpdj5CYXNpY2FsbHksIEkgYWdyZWUgdGhhdCBjdXJyZW50IGZvcm1hdCBkb2N1bWVudCBpcyBy YXRoZXIgdGlnaHRseSZuYnNwO3NjaGVkdWxlZCBhbmQgbm90IHdlbGwgcHJlcGFyZWQgZm9yIGZ1 dHVyZSBlbmhhbmNlbWVudHMgb3IgcmV2aXNpb25zLCBpbiB0ZXJtcyBvZiByb3V0aW5nLCBkaWFn bm9zZXMsIG1hbmFnZW1lbnQsIGV0Yy4gQmFzZWQgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB3ZSBh cmUgbm90IHlldCBpbiB0aGUgc3RhZ2Ugb2YgcHVyc3VpbmcmbmJzcDtmdXR1cmUgcmVjaGFydGVy aW5nIGl0ZW1zLCBpdCBtaWdodCBub3QgYmUgdGhlIHJpZ2h0IHRpbWUgdG8gY29uc2lkZXIgYWxs IHRoZSBjYXNlcyBhdCBvbmUgdGltZS4gQWxzbywgd2Ugc2hvdWxkIGJlIGluIHJ1c2ggdG8gZmlu aXNoIHRoZSBjdXJyZW50IGZvcm1hdCBkb2N1bWVudCBBU0FQIGZvciBtb3ZpbmcgZm9yd2FyZCBp bnRvIG5leHQgc3RhZ2UgYmVmb3JlIG5leHQgSUVURiBtZWV0aW5nLiAKPC9kaXY+CjxkaXY+Jm5i c3A7PC9kaXY+CjxkaXY+UmVnYXJkaW5nIHRoZSBtZXNoIGRlbGl2ZXJ5IGZpZWxkLCBNYXJpbyBN YW8ncyBhcHByb2FjaCBzaG91bGQgYmUgZmluZSwgYW5kIG90aGVyIGFwcHJvYWNoZXMgKGxpa2Ug b3B0aW9uIDIsMywgYW5kIDQpIG1pZ2h0IGJlIE9LLiBIb3dldmVyLCBpdCBzZWVtcyBsaWtlIHdl IGFyZSZuYnNwO3RyeWluZyB0b28gbXVjaCB0byBtYWtlIHRoZSBmb3JtYXQmbmJzcDtjb21wYWN0 IHdoaWxlIG5vdCBjb25zaWRlcmluZyB0aGUgZnV0dXJlIGV4cGFuc2lvbnMuIAo8L2Rpdj4KPGRp dj4mbmJzcDs8L2Rpdj4KPGRpdj5BZnRlciBhbGwsIG15IG9waW5pb24gaXMgb3B0aW9uIDEuIExl dCdzIGhhdmUgb25lIGJ5dGUgZm9yIHRoZSBtdWx0aWNhc3QgYml0IGFuZCB0aGUgcmVzZXJ2ZWQg ZmllbGRzIGZvciBmdXR1cmUuPC9kaXY+CjxkaXY+aGF2aW5nIGFkZGl0aW9uYWwgb25lIGJ5dGUg Zm9yIHRoaXMgaXMgbm90IGEgYmlnIGRlYWwmbmJzcDtpbiB0ZXJtcyBvZiBwYWNrZXQgc2l6ZSBh bmQgd29uJ3QgYWRkIG11Y2ggY29tcGxleGl0eSBmb3IgaGFuZGxpbmcgaXQuPC9kaXY+CjxkaXY+ RXhhbXBsZXMgb2YmbmJzcDt1dGlsaXppbmcmbmJzcDtzb21lIHJlc2VydmVkIGZpZWxkcyZuYnNw O21pZ2h0IGJlIGZvbGxvd3M6PC9kaXY+CjxkaXY+MS4gQmFzZWQgb24gdGhlIGFzc3VtcHRpb24m bmJzcDt0aGF0Jm5ic3A7Nmxvd3BhbiBzdXBwb3J0cyBtdWx0aXBsZSByb3V0aW5nIHByb3RvY29s cyBzdWNoIGFzICZuYnNwO0xPQUQsIERZTU8tbG93LCBIaUxvdywgRFNSLCBvciB3aGF0ZXZlciwm bmJzcDtldGMuLCB0aGUgZmllbGQgbWlnaHQgYmUgdXNlZCBmb3IgaW5kaWNhdGluZyB3aGljaCBz cGVjaWZpYyByb3V0aW5nIHByb3RvY29sIHNob3VsZCBiZSB1c2VkIGZvciByb3V0aW5nIHRoaXMg cGFydGljdWxhciBwYWNrZXQuIEl0IG1pZ2h0IGJlIGFyZ3VlZCB3aGV0aGVyIHRoZSBmb3JtYXQg ZG9jdW1lbnQgc2hvdWxkIHN1cHBvcnQgbXVsdGlwbGUgcHJvdG9jb2xzIGF0IGEgdGltZS4gSG93 ZXZlciwgdGhvc2Uga2luZCBvZiBhcmd1ZSBzaG91bGQgYmUgZGViYXRlZCBsYXRlciB3aGlsZSBj b25zaWRlcmluZyByb3V0aW5nIHByb3RvY29scyB3aXRob3V0IGVsaW1pbmF0aW5nIGZ1dHVyZSBw b3NzaWJsZSBuZWNlc3NpdHkuIAo8L2Rpdj4KPGRpdj4yLiBSb3V0aW5nIHByb3RvY29scyBjb3Vs ZCBiZSBvcHRpbXplZCBieSBoYXZpbmcgc29tZSBvcHRpb24gZmllbGRzLCB3aGlsZSBpdCBtaWdo dCBub3QgYmUgcmlnaHQgdGltZSB0byBzcGVjaWZpY2FsbHkgbWVudGlvbiB0aGVtLjwvZGl2Pgo8 ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PkkgcmVtZW1iZXIgdGhhdCB0aGUgaXNzdWUgb2YmbmJzcDt0 aGUgbWVzaCB1bmRlcm5lYXRoIG9yIGFib3ZlIElQIGhhcyBiZWVuIHJhaXNlZCBzZXZlcmFsIHRp bWVzIGluIHRoZSBXRy4gSSB0aGluayBpdCBtaWdodCBub3QgYmUgcmlnaHQgdGltZSBjb25zaWRl cmluZyBpdCBhZ2FpbiByaWdodCBub3cuPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+SWYg eW91IGhhdmUgYW55IG90aGVyIG9waW5pb25zLCBwbGVhc2UgbGV0IG1lIGtub3cuPGJyPjxicj4m bmJzcDs8L2Rpdj4KPGRpdj48c3Bhbj4KPGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9u IDkvMjMvMDYsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5nYWJyaWVsIG1vbnRlbmVncm88 L2I+ICZsdDs8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSIgaHJlZj0ibWFpbHRvOmdhYnJpZWxfbW9udGVuZWdyb18yMDAwQHlhaG9vLmNvbSIg dGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9mb2xsb3ciPgogZ2FicmllbF9tb250ZW5lZ3JvXzIwMDBA eWFob28uY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPiAKPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44 ZXg7IEJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZCI+CjxkaXY+CjxkaXYg c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcg eW9yayx0aW1lcyxzZXJpZiI+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1J TFk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+Rmlyc3Qgb2YgYWxsLCBU aGFua3MgRGF2aWQgZm9yIHlvdXIgdGhvdWdodGZ1bCBtZXNzYWdlLiBJdCdzIGdyZWF0IHRvIHNl ZSB5b3UgcGFydGljaXBhdGUgaW4gdGhpcyBmb3J1bSBhbmQgSSBob3BlPC9kaXY+CjxkaXYgc3R5 bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9y ayx0aW1lcyxzZXJpZiI+eW91J2xsIHN0aWNrIGFyb3VuZCE8L2Rpdj4KPGRpdiBzdHlsZT0iRk9O VC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVz LHNlcmlmIj4mbmJzcDs8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZB TUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj5Gcm9tIHRoZSBwb2lu dCBvZiB2aWV3IG9mIGxheWluZyB0aGUgdGVjaG5vbG9neSBmb3VuZGF0aW9uLCBldmVyeXRoaW5n IGluIHlvdXIgbWVzc2FnZSBpcyBxdWl0ZSByZWxldmFudC48L2Rpdj4KPGRpdiBzdHlsZT0iRk9O VC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVz LHNlcmlmIj5Gcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIFdHIG1hbmFnZW1lbnQsIEknbSB0cnlp bmcgdG8gZmlndXJlIG91dCBpZiB3ZSBuZWVkIHRvIGFjdCBvbiBhbGwgb2YgaXQgcmlnaHQgbm93 PC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5l dyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+b3IgaWYgdGhlcmUgYXJlIHRoaW5ncyB3ZSBj YW4gYWRkcmVzcyBpbmRlcGVuZGVudGx5IG9mIHRoZSBmb3JtYXQgZHJhZnQgdW5kZXIgZGlzY3Vz c2lvbi4gRm9yIGV4YW1wbGUsPC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9O VC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+eW91IGJyaW5n IHVwIHRoZSB0b3BpYyBvZiB0cmFjZXJvdXRlIHR5cGUgZnVuY3Rpb25hbGl0eS4gSW4gSVAsIHRo aXMgaXMgY2FycmllZCBvdmVyIElDTVAsIGEgc2VwYXJhdGUgPC9kaXY+CjxkaXYgc3R5bGU9IkZP TlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1l cyxzZXJpZiI+bWFuYWdlbWVudCBjb250cm9sIHBsYW5lLiBTaW5jZSB3aGF0IHdlIGhhdmUgaW4g dGhlIGZvcm1hdCBkcmFmdCBpcyBhIG11bHRpcGxleGluZyBsYXllciwgd2UgY2FuIDwvZGl2Pgo8 ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4s bmV3IHlvcmssdGltZXMsc2VyaWYiPmRlZmluZSBhIG5ldyBwcm90b2NvbCB2YWx1ZSB0byBjYXJy eSBvdXQgdGhlIG1hbmFnZW1lbnQgcHJvdG9jb2wgcGFja2V0cy4gVGhlIHF1ZXN0aW9uIGlzIGlm IHRoZTwvZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1l cyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWYiPmN1cnJlbnQgZm9ybWF0IHByb3ZpZGVz IHRoZSByZXF1aXJlZCBtZWNoYW5pc20gdG8gZ28gZG8gd29yayBvbiBzdWNoIGEgc2VwYXJhdGUg cHJvdG9jb2w8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTog dGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj5pbiBhbm90aGVyIGRyYWZ0LiBJ bnR1aXRpdmVseSwgaXQgc2VlbXMgbGlrZSB0aGlzIHdvdWxkIHdvcmsuIFNvbWVvbmUgKHlvdXIg Z3JvdXAsIERhdmlkPykgY291bGQ8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBG T05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj5kZWZpbmUg c3VjaCBhIHByb3RvY29sIHdpdGggZnVuY3Rpb25hbGl0eSBzaW1pbGFyIHRvIElDTVAgZm9yIHBp bmdzLCB0cmFjZXJvdXRlLCBldGMgYW5kIHByb3ZpZGU8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNl cmlmIj50aGUgcm91dGUgZ2F0aGVyaW5nIGZ1bmN0aW9uYWxpdHksIHRoZSBlY2hvIHJlc3BvbnNl LCBldGMgaW4gdGhhdCBzZXBhcmF0ZSBkcmFmdC4gQ29uY2VpdmFibHksIGl0PC9kaXY+CjxkaXYg c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcg eW9yayx0aW1lcyxzZXJpZiI+d291bGQgbm90IG5lY2Vzc2FyaWx5IHVzZSB0aGUgbWVzaCBkZWxp dmVyeSBoZWFkZXIsIGFzIGl0IHdvdWxkIHByb3ZpZGUgaXRzIG93biBmYWNpbGl0eSB0bzwvZGl2 Pgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9t YW4sbmV3IHlvcmssdGltZXMsc2VyaWYiPnJlY29yZCBob3AtYnktaG9wIHJvdXRlIGluZm9ybWF0 aW9uIHdpdGhpbiBpdHMgb3duIHByb3RvY29sIGZpZWxkcy4gSXQgY291bGQgdXNlIGxvb3NlIHNv dXJjZTwvZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1l cyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWYiPnJvdXRpbmcgaW4gd2hpY2ggY2FzZSBz b21lIHVzZSBvZiB0aGUgbWVzaCBkZWxpdmVyeSBoZWFkZXIgbWlnaHQgYmUgYXBwcm9wcmlhdGUg YXMgd2VsbC48L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTog dGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj5Xb3VsZCBzdWNoIGFuIGFwcHJv YWNoIHdvcmssIERhdmlkPyBUaGlzIHdvdWxkIGFjdHVhbGx5IHBsYXkgaW50byBvbmUgb2YgdGhl IGl0ZW1zIHNsYXRlZCBmb3I8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj50aGUgbmV4dCBy b3VuZCBvZiA2bG93cGFuIChpZiB3ZSBldmVyIHJlY2hhcnRlcikgdG8gc3RyZW5ndGhlbiBkaWFn bm9zYWJpbGl0eSBvciBtYW5hZ2VtZW50IG9mPC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTog MTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+ dGhlc2UgbmV0d29ya3MuPC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1G QU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+Jm5ic3A7PC9kaXY+ CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21h bixuZXcgeW9yayx0aW1lcyxzZXJpZiI+QXMgZm9yIHlvdXIgcG9pbnQgYWJvdXQgdXMgbm90IGtu b3dpbmcgZXhhY3RseSB3aGF0IHRoZSBoZWFkZXIgZm9ybWF0IG11c3QgbG9vayBsaWtlIGF0IHRo aXMgcG9pbnQgaW48L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlM WTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj50aW1lLCB0aGlzIGlzIHBl cmhhcHMgc29tZXRoaW5nIHdlIG5lZWQgdG8gdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24gcmlnaHQg bm93LiBGb3IgZXhhbXBsZSwgdGhpczwvZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7 IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWYiPmlucHV0 IHdvdWxkIHB1c2ggdXMgaW50byByZXNlcnZpbmcgYXQgbGVhc3QgYSBjb3VwbGUgb2YgYml0cyBp biB0aGUgaGVhZGVyJm5ic3A7Zm9yIGZ1dHVyZSBleHBhbnNpb24uIEEgd2hpbGU8L2Rpdj4KPGRp diBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5l dyB5b3JrLHRpbWVzLHNlcmlmIj5iYWNrIFZpcHVsIHdhcyBhcmd1aW5nIGZvciBhICZxdW90O3Zl cnNpb24mcXVvdDsgZmllbGQuIE5vdCBzdXJlIGlmIHN1Y2ggYSBmaWVsZCBpcyByZXF1aXJlZCBv ciBpZiB0aGUgY3VycmVudCByZXNlcnZlZDwvZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEy cHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWYiPmZp ZWxkcyBhcmUgZW5vdWdoLiBNYXJpbyBNYW8ncyBwcm9wb3NhbCB1c2VzIG9uZSBvZiB0aG9zZSBy ZXNlcnZlZCBiaXRzIHRvIHNvbHZlIHRoZSBpc3N1ZSB1bmRlcjwvZGl2Pgo8ZGl2IHN0eWxlPSJG T05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGlt ZXMsc2VyaWYiPmRpc2N1c3Npb24gcmVnYXJkaW5nIHRoZSBtZXNoIGRlbGl2ZXJ5IGhlYWRlciB2 YXJpYW50cyBmb3IgdW5pY2FzdCB2cyBtY2FzdC9iY2FzdC4gVGhlcmUgaGFzIGJlZW4gPC9kaXY+ CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21h bixuZXcgeW9yayx0aW1lcyxzZXJpZiI+b25lIGdyb3VwIGV4cHJlc3Npbmcgc3VwcG9ydCBmb3Ig dGhpcywgc28gcGVyaGFwcyB3ZSBhbHJlYWR5IGhhdmUgdGhlIG5lY2Vzc2FyeSBtZWNoYW5pc20g aW4gcGxhY2U8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTog dGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj5pbiB0aGUgaGVhZGVyLjwvZGl2 Pgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9t YW4sbmV3IHlvcmssdGltZXMsc2VyaWYiPiZuYnNwOzwvZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJ WkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2Vy aWYiPkRhdmlkLCB5b3UgYWxzbyBtZW50aW9uIHRoZSBuZWVkIHRvIHN1cHBvcnQgZGlmZmVyZW50 IHJvdXRpbmcgcHJvdG9jb2xzIHNpZGUtYnktc2lkZSBmb3IgY29tcGFyaXNvbi48L2Rpdj4KPGRp diBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5l dyB5b3JrLHRpbWVzLHNlcmlmIj5UaGlzIGlzIG9uZSBvZiB0aGUgZGVzaWduIGdvYWxzIG9mIHRo ZSBmb3JtYXQgZG9jdW1lbnQuIEFzIEkgbWVudGlvbmVkLCB0aGUgcHJvdG9jb2wgZmllbGQgYWxs b3dzIG9uZTwvZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0 aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWYiPnRvIGNhcnJ5IGRpZmZlcmVudCBw cm90b2NvbHMuIFdlIGN1cnJlbnRseSBoYXZlIHByb3Bvc2FscyBmb3IgYSA2bG93cGFuIGFkYXB0 YXRpb25zIG9mJm5ic3A7QU9EViwgYSBEeU1PPC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTog MTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+ YW5kIEhpTG93LiBJIGtub3cgTmFuZHUgd2FzIHRoaW5raW5nIG9mIGRvaW5nIG9uZSBmb3IgT0xT Ui4gUGVyaGFwcyBCVlIgaXMgbmV4dC4gVGhlIHBvaW50IGlzIHRoYXQ8L2Rpdj4KPGRpdiBzdHls ZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3Jr LHRpbWVzLHNlcmlmIj50aGUgZm9ybWF0IGRvY3VtZW50IGRvZXMgcHJvdmlkZSB0aGUgbWVjaGFu aXNtIHRvIGRlZmluZSBhbnkgc3VjaCBwcm90b2NvbCwgb3IgaXMgdGhlcmUgYSBsaW1pdGF0aW9u IHlvdTwvZGl2Pgo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1l cyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWYiPmNhbiBzZWUgaW4gdGhlIGN1cnJlbnQg ZG9jdW1lbnQ/IElmIHNvLCB3aGF0IG5lZWRzIHRvIGNoYW5nZT88L2Rpdj4KPGRpdiBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRp bWVzLHNlcmlmIj4mbmJzcDs8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj5BcyBmb3IgdGhl IGNsYWltIHRoYXQgc3ViLUlQIGJlbmVmaXRzIGZyb20gc2ltcGxlciBzdHJ1Y3R1cmVzLCBteSBp bnRlcnByZXRhdGlvbiBpcyB0aGF0IHlvdSdyZSBzdWdnZXN0aW5nIGl0IDwvZGl2Pgo8ZGl2IHN0 eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlv cmssdGltZXMsc2VyaWYiPmlzIGJldHRlciBub3QgdG8gdXNlIHRoZSBtZXNoIGRlbGl2ZXJ5IGhl YWRlciBhbmQgbGV0IElQIGRlYWwgd2l0aCB0aGUgdW5kZXJseWluZyBpbmRpdmlkdWFsIGNvbGxl Y3Rpb24gb2YgbGlua3MuPC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1G QU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+SWYgc28sIG9uZSBj YW4gaWdub3JlIHRoZSBtZXNoIGRlbGl2ZXJ5IGhlYWRlciAobm90IHVzZSBpdCkgYW5kIHVzZSB0 aGUgb3RoZXIgcGFydHMgb2YgdGhlIGZvcm1hdCBkb2N1bWVudCB0bzwvZGl2Pgo8ZGl2IHN0eWxl PSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmss dGltZXMsc2VyaWYiPnNpbXBseSBsYXllciBJUCBvbiB0b3AuIFRoaXMgYXBwcm9hY2ggd291bGQg dGhlbiBtYWtlIHVzZSBvZiBvdGhlciBhY3Rpdml0aWVzIGxpa2UgQVVUT0NPTkYgb3IgTUFORVQ8 L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3 IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj50byBjcmVhdGUgbWVzaGVzIGlmIHNvIGRlc2ly ZWQuJm5ic3A7IFBlcnNvbmFsbHksIEkgc2VlIHRoYXQgKmlmKiBvbmUgd2lzaGVzIHRvIGRvIGEg bWVzaCwgbm90IGRvaW5nIGl0IGluIHRoZSBzdWItSVA8L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNl cmlmIj5sYXllciBqdXN0IHB1c2hlcyB0byBwcm9ibGVtIHVwd2FyZHMgaW50byB0aGUgSVAgcm91 dGluZyByZWFsbSwgYW5kIHRoaXMganVzdCBtYWtlcyB0aGluZ3MgZXZlbiBtb3JlIGNvbXBsZXg8 L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3 IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj50aGFuIGRvaW5nIGl0IHVuZGVyIHN1Yi1JUC4g Q29tcGxleGl0eSB3aWxsIGJlIHRoZXJlIG5vIG1hdHRlciB3aGF0LCBpdCdzIGp1c3QgYSBxdWVz dGlvbiBvZiB3aGVyZSBvbmUgd2FudHMgdG88L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj5h ZGRyZXNzIGl0LiBJIGRvIG5vdGUgdGhhdCBzdWItSVAgY29tcGxleCBzdHJ1Y3R1cmVzIGFyZSB2 ZXJ5IHBvcHVsYXIgYW5kIGRlcGxveWVkIGluIHNvbWUgY2FzZXMgKDgwMi4xZCBicmlkZ2VkPC9k aXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyBy b21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+bmV0d29ya3MpLiBQZXJoYXBzIGxpa2VseSB0byBi ZWNvbWUgZXZlbiBtb3JlIHNvIHdpdGggODAyLjExcyB3aXRoaW4gYSBmZXcgeWVhcnMuPC9kaXY+ CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21h bixuZXcgeW9yayx0aW1lcyxzZXJpZiI+Jm5ic3A7PC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0la RTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJp ZiI+SSB3b3VsZCBub3QgYmUgaW50ZXJlc3RlZCBpbiBwdXJzdWluZyBhbiBBVVRPQ09ORiBwYXRo LCBidXQgdGhpbmsgaXQgc2hvdWxkPC9kaXY+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsg Rk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+YmUgcG9z c2libGUgdG8gZG8gc28gZm9yIHRob3NlIHNvIGluY2xpbmVkLiBEb2VzIHRoaXMgc291bmQgZG9h YmxlPyBBZ2FpbiwgbXkgaW1tZWRpYXRlIGNvbmNlcm4gaXMgdGhhdCB0aGU8L2Rpdj4KPGRpdiBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5 b3JrLHRpbWVzLHNlcmlmIj5mb3JtYXQgZG9jdW1lbnQgbm90IHByZXZlbnQgdGhpcyBhcHByb2Fj aC4gPC9kaXY+PHNwYW4+CjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6 IHRpbWVzIG5ldyByb21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+Jm5ic3A7PC9kaXY+CjxkaXYg c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbixuZXcg eW9yayx0aW1lcyxzZXJpZiI+LWdhYnJpZWw8YnI+PGJyPiZuYnNwOzwvZGl2Pjwvc3Bhbj4KPGRp dj48c3Bhbj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMg bmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS08YnI+RnJvbTogR2VvZmYgTXVsbGlnYW4gJmx0OzxhIG9uY2xpY2s9InJldHVybiB0b3AuanMu T3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86Z2VvZmZAbXVsbGln YW4uY29tIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub2ZvbGxvdyI+CiBnZW9mZkBtdWxsaWdhbi5j b208L2E+Jmd0Ozxicj5UbzogU29vaG9uZyBEYW5pZWwgUGFyayAmbHQ7PGEgb25jbGljaz0icmV0 dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpz b29ob25ncEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vZm9sbG93Ij5zb29ob25n cEBnbWFpbC5jb208L2E+Jmd0Ozxicj5DYzogPGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVu RXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzo2bG93cGFuQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub2ZvbGxvdyI+CjZsb3dwYW5AaWV0Zi5vcmc8L2E+OyBE YXZpZCBDdWxsZXIgJmx0OzxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86ZGF2aWQuY3VsbGVyQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiIHJlbD0ibm9mb2xsb3ciPmRhdmlkLmN1bGxlckBnbWFpbC5jb208L2E+Jmd0 Ozxicj5TZW50OiBGcmlkYXksIFNlcHRlbWJlciAyMiwgMjAwNiA2OjQxOjIxIEFNIAo8YnI+U3Vi amVjdDogUmU6IFs2bG93cGFuXSBNZXNoIERlbGl2ZXJ5IEZpZWxkPGJyPjxicj4KPGRpdj5EYW5p ZWwsPGJyPiZuYnNwOyZuYnNwO1doaWxlIHRoZSBXRyBsYXN0IGNhbGwgZGlkIGV4cGlyZSwgSSdt IG5vdCBzdXJlIGlmIERhdmlkIGlzIHRvbyBsYXRlLjxicj5JIHRoaW5rIHRoYXQgaGUgcmFpc2Vz IHNvbWUgaW1wb3J0YW50IGNvbmNlcm5zIGFuZCBJJ20gbm90IHN1cmUgdGhhdCB3ZTxicj5yZWFs bHkgaGF2ZSBjb25zZW5zdXMgb24gdGhlIG1lc2ggZGVsaXZlcnkgZmllbGQuPGJyPjxicj4KSSB3 b3VsZCBsaWtlIHRvIGhlYXIgZnJvbSB0aGUgbGlzdCBvbiB0aGlzLiZuYnNwOyZuYnNwO0kgdGhp bmsgdGhhdCBHYWJyaWVsIGhhczxicj5wdXQgZm9ydGggNCBhbHRlcm5hdGl2ZXMuJm5ic3A7Jm5i c3A7Q2Fyc3RlbiBpbmRpY2F0ZWQgdGhhdCBoZSB0aG91Z2h0IGhlIG1pZ2h0PGJyPmhhdmUgYSBk aWZmZXJlbnQgYWx0ZXJuYXRpdmUgYW5kIHdvdWxkIHBvc3QgdG8gdGhlIGxpc3QgZWl0aGVyIHRo ZTxicj5hbHRlcm5hdGl2ZSBvciBoaXMgY29uc2lkZXJhdGlvbiBvZiB0aGUgNCBhbHRlcm5hdGl2 ZXMgLSBDYXJzdGVuLCBwbGVhc2UgCjxicj5zZW5kIHlvdXIgdGhvdWdodHMuPGJyPjxicj5JIGZl ZWwgdGhhdCB0aGUgaXNzdWUgRGF2aWQgcmFpc2VzIHNob3VsZCBiZSBkZWFsdCB3aXRoIGJ5IHRo ZSBXRzxicj5iZWNhdXNlIEkgZG8gbm90IHdhbnQgdG8gc2VuZCB0aGUgZHJhZnQgb24gdG8gdGhl IElFU0cgb25seSB0byBoYXZlPGJyPnRoZXNlIGlzc3VlcyBicm91Z2h0IHVwIGluIHRoZSBJRVRG IGxhc3QgY2FsbC4mbmJzcDsmbmJzcDtUaGVzZSBzZWVtIHJhdGhlciAKPGJyPmZ1bmRhbWVudGFs IHRvIG1lIGFuZCB3ZSBtaWdodCBsb29rIHJhdGhlciBmb29saXNoIG5vdCBoYXZpbmcgcmVzb2x2 ZWQ8YnI+dGhpcyBpbiB0aGUgd29ya2luZyBncm91cCE8YnI+PGJyPldlIG5lZWQgc29tZSBzaWdu aWZpY2FudCBkaXNjdXNzaW9uIGZyb20gdGhlIG1lbWJlcnMgb2YgdGhlIFdHLiZuYnNwOyZuYnNw O1RoaXMgV0c8YnI+aGFzIGJlZW4sIG15IHNlbGYgaW5jbHVkZWQsIHJhdGhlciBxdWlldCBhbmQg YXMgYSByZXN1bHQgd2UgaGF2ZSBtb3ZlZCAKPGJyPmF0IGEgc25haWxzIHBhY2UgZ2V0dGluZyBh bnl0aGluZyBkb25lLiZuYnNwOyZuYnNwO0kgaW1wbG9yZSBldmVyeW9uZSB0byB0YWtlIHRpbWU8 YnI+YW5kIHJlYWQgdGhlIHRocmVhZCBvbiB0aGUgbWVzaCBmaWVsZCBhbmQgc2VuZCB5b3VyIHRo b3VnaHRzLCBwcm8sIGNvbjxicj5vciBvdGhlcndpc2UgdG8gdGhpcyBsaXN0LiZuYnNwOyZuYnNw O0lmIGV2ZXJ5b25lIGNvbnRpbnVlcyB0byBiZSBhcGF0aGV0aWMgYWJvdXQgCjxicj50aGlzIHdv cmssIEkgaG9sZCBsaXR0bGUgaG9wZSBmb3IgdGhpcyBXRyBiZWluZyByZWNoYXJ0ZXJlZCB0byBk byBhbnk8YnI+b3RoZXIgd29yayE8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2dlb2Zm PGJyPjxicj5PbiBGcmksIDIwMDYtMDktMjIgYXQgMTk6MjMgKzEwMDAsIFNvb2hvbmcgRGFuaWVs IFBhcmsgd3JvdGU6PGJyPiZndDsgRGF2aWQsPGJyPiZndDsgPGJyPiZndDsgRmlyc3Qgb2ZmLCB5 b3VyIGlzc3VlIHJhaXNpbmcgaW4gdGhpcyB0aHJlYWQgc2VlbXMgdG9vIGxhdGUgc2luY2Ugb3Vy IAo8YnI+Jmd0OyBvZmZpY2lhbCBXR0xDIHdhcyBleHBpcmVkOiAmcXVvdDtUaGlzIExhc3QgQ2Fs bCB3aWxsIGVuZCBvbiBXZWRuZXNkYXkgMDI8YnI+Jmd0OyBBdWd1c3QgMjAwNiBhdCAyMzU5IFVU Qy4mcXVvdDs8YnI+Jmd0OyA8YnI+Jmd0OyBBbnl3YXksIG15IHNlbnNlIGlzIG5vdCB0byB0YWtl IE1lc2ggaXNzdWUgYXQgdGhpcyBzdGFnZS4gQXMgbG9uZyBhczxicj4mZ3Q7IHdlIGFyZSBsb29r aW5nIGF0IHRoZSA2bG93cGFuIHNvbHV0aW9uIGZvcm1hdCwgbWVzaCBpcyBvdXQgb2Ygc2NvcGUg b2YgCjxicj4mZ3Q7IHRoYXQuIEluIGZhY3QsIGFzIGZhciBhcyBJIGFtIGNvbmNlcm4sIG1lc2gg YmVsb25ncyB0byAxNS40IHRlY2hub2xvZ3k8YnI+Jmd0OyBiYXNlZCBvbiBNQUMgbGF5ZXIuIElu c3RlYWQsIGFzIGRlc2NyaWJlZCBpbiB0aGUgcmVjaGFydGVyaW5nLCB3ZSB3aWxsPGJyPiZndDsg Z28gdGhyb3VnaCBhZGhvYyBpc3N1ZSBiYXNlZCBvbiBJUCBsYXllci4gVGhhdCdzIHdoeSB3ZSBh cmUgaGVyZSBpbiAKPGJyPiZndDsgNmxvd3BhbiB3ZyBvZiBpZXRmLjxicj4mZ3Q7IDxicj4mZ3Q7 IEJ1dCwgc29tZSBzdGFmZnMgZGVzY3JpYmVkIGluIHlvdXIgbWFpbCBzZWVtIGhlbHBmdWwgZnJv bSB0aGUgNmxvd3Bhbjxicj4mZ3Q7IHBlcnNwZWN0aXZlLCBlc3BlY2lhbGx5IElQdjYgcmVsYXRl ZCBzdHVmZnMuIElmIGFsbG93ZWQsIHBsZWFzZSBicmluZzxicj4mZ3Q7IHlvdXIgY29uY2VybiB0 byB0aGUgbmV4dCA2bG93cGFuIGZhY2UtdG8tZmFjZSBtZWV0aW5nIGluIFNhbiBEaWVnby4gCjxi cj4mZ3Q7IFRoZW4sIHdlIHdpbGwgaGF2ZSBmdXJ0aGVyIGRldGFpbHMgaW4gdGhlcmUgSSBiZWxp ZXZlLi4uPGJyPiZndDsgPGJyPiZndDsgLS0gPGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgRGFu aWVsIChTb29ob25nIERhbmllbCBQYXJrKTxicj4mZ3Q7IE1vYmlsZSBDb252ZXJnZW5jZSBMYWJv cmF0b3J5LCBTQU1TVU5HIEVsZWN0cm9uaWNzLjxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4KJmd0OyA8 YnI+Jmd0OyBPbiA5LzIxLzA2LCBEYXZpZCBDdWxsZXIgJmx0OzxhIG9uY2xpY2s9InJldHVybiB0 b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86ZGF2aWQu Y3VsbGVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9mb2xsb3ciPmRhdmlkLmN1 bGxlckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+Jmd0OyAmZ3Q7IERlYXIgQWxsLAo8YnI+ Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgSSB3b3VsZCBsaWtlIHRvIHJhaXNlIGEgY29uY2VybiBh Ym91dCB0aGUgTWVzaCBEZWxpdmVyeSBGaWVsZDxicj4mZ3Q7ICZndDsgZGVmaW5pdGlvbiBpbiBT ZWN0aW9uIDExIG9mIHRoZSBmb3JtYXQgZG9jdW1lbnQuJm5ic3A7Jm5ic3A7V2hpbGUgdGhlIGFj dHVhbDxicj4mZ3Q7ICZndDsgbWVzaCByb3V0aW5nIHByb3RvY29sIGlzIGFwcHJvcHJpYXRlbHkg b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIAo8YnI+Jmd0OyAmZ3Q7IDZsb3dwYW4gRm9ybWF0IGRv Y3VtZW50LCB0aGF0IGZvcm1hdCBuZWVkcyBwcm92aWRlIHRoZSByYXcgc3RydWN0dXJlPGJyPiZn dDsgJmd0OyB1cG9uIHdoaWNoIHJvdWdoIGNvbnNlbnN1cyBhbmQgcnVubmluZyBjb2RlIGNhbiBi ZSBmbG91cmlzaC4mbmJzcDsmbmJzcDtXZTxicj4mZ3Q7ICZndDsga25vdyB0aGF0IGxvdyBwb3dl ciB3aXJlbGVzcyBtZXNoIHJvdXRpbmcgaXMgdGVjaG5pY2FsbHkgdHJpY2t5IGFuZCAKPGJyPiZn dDsgJmd0OyBzdHJvbmdseSBpbmZsdWVuY2VkIGJ5IHRhcmdldCB0cmFmZmljIGxvYWQsIHBvd2Vy IG1hbmFnZW1lbnQgcHJvZmlsZSw8YnI+Jmd0OyAmZ3Q7IG5ldHdvcmsgZGVzaWduLCBhbmQgc28g b24uJm5ic3A7Jm5ic3A7VGh1cywgaXQgaXMgcmVhc29uYWJsZSB0byBleHBlY3QgdGhhdCB0aGU8 YnI+Jmd0OyAmZ3Q7IGNvbnNlbnN1cyBidWlsZGluZyBhbmQgdGVjaG5pY2FsIHJlZmluZW1lbnQg cHJvY2VzcyB3aWxsIHJlcXVpcmUgCjxicj4mZ3Q7ICZndDsgb24tZ29pbmcgZXhwZXJpZW5jZSB3 aXRoIHByb3RvY29sIGFuZCBpbXBsZW1lbnRhdGlvbiBhbHRlcm5hdGl2ZXMuPGJyPiZndDsgJmd0 OyBUaGUgNmxvd3BhbiBmb3JtYXQgZG9jdW1lbnQgc2hvdWxkIHN1cHBvcnQgdGhpcyBwcm9jZXNz LCBhbHRob3VnaCBpdDxicj4mZ3Q7ICZndDsgc2hvdWxkIG5vdCBkaWN0YXRlIGl0cyBjb25jbHVz aW9uLjxicj4mZ3Q7ICZndDsgCjxicj4mZ3Q7ICZndDsgQmFzZWQgb24gcGFzdCBleHBlcmllbmNl IHdpdGggSVAgbGF5ZXIgMyByb3V0aW5nIGFuZCB3aXRoIHBhc3Q8YnI+Jmd0OyAmZ3Q7IGludGVy bmFsbHkgcm91dGVkIGxpbmtzLCB3ZSBjYW4gZXN0YWJsaXNoIGEgZmV3IHByaW1hcnkgZ29hbHMg Zm9yIHRoZTxicj4mZ3Q7ICZndDsgZXhwcmVzc2l2ZW5lc3Mgb2YgdGhlIDZsb3dwYW4gTWVzaCBE ZWxpdmVyeSBGaWVsZC4gCjxicj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoMSkg SXQgc2hvdWxkIHN1cHBvcnQgdGhlIHZpc2liaWxpdHkgaW50byB0aGUgcm91dGVkIDE1LjQgY2xv dWQ8YnI+Jmd0OyAmZ3Q7IG5lY2Vzc2FyeSB0byBkZXZlbG9wLCBkZWJ1ZywgZGlhZ25vc2UsIGFu ZCBtYW5hZ2UgdGhlIDE1LjQgY2xvdWQuPGJyPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOygyKSBJdCBzaG91bGQgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byBkZWZpbmUsIGRldmVsb3Ag YW5kIGNvbXBhcmUgCjxicj4mZ3Q7ICZndDsgcm91dGluZyBwcm90b2NvbHMgYW5kIHBvc3NpYmx5 IHN1cHBvcnQgdGhlIHByZXNlbmNlIG9mIG11bHRpcGxlPGJyPiZndDsgJmd0OyBwcm90b2NvbHMg Zm9yIHdpZGVseSBkaWZmZXJpbmcgdXNhZ2UgY2FzZXMuPGJyPiZndDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOygzKSBJdCBuZWVkcyB0byBiZSBwb3NzaWJsZSBmb3Igbm9kZXMgdG8gY29t bXVuaWNhdGUgd2l0aCBvdGhlciBub2RlcyAKPGJyPiZndDsgJmd0OyBpbiB0aGUgY2xvdWQgaW4g b3JkZXIgdG8gZGlzY292ZXIgYW5kIG5lZ290aWF0ZSBqb2luaW5nIHRoZSBjbG91ZDxicj4mZ3Q7 ICZndDsgd2l0aG91dCBqb2luaW5nIHRoZSBjbG91ZCBhIHByaW9yaSB0aHJvdWdoIHNvbWUgbWVj aGFuaXNtIHRoYXQgaXM8YnI+Jmd0OyAmZ3Q7IG9wYXF1ZSB0byBJUCBhbmQgYWJvdmUuPGJyPiZn dDsgJmd0Ozxicj4mZ3Q7ICZndDsgKDEpIGhhcyBoaXN0b3JpY2FsbHkgYmVlbiBhZGRyZXNzZWQg dGhyb3VnaCB2YXJpb3VzIGZvcm1zIG9mIHNvdXJjZSAKPGJyPiZndDsgJmd0OyByb3V0aW5nLiZu YnNwOyZuYnNwO0l0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBkbyB0aGUgZXF1aXZhbGVudCBvZiB0 cmFjZXJvdXRlPGJyPiZndDsgJmd0OyB0aHJvdWdoIHRoZSAxNS40IG1lc2ggYW5kIHRoaXMgc2hv dWxkIGJlIGFjY2Vzc2libGUgaW4gc29tZSBmb3JtIHRocm91Z2ggSVA8YnI+Jmd0OyAmZ3Q7IHNv PGJyPiZndDsgJmd0OyBoaWdoZXIgbGF5ZXJzIGNhbiBiZSBidWlsdCB0byBwZXJmb3JtIHRoZSBt YW5hZ2VtZW50LiZuYnNwOyZuYnNwO1RoZSBjdXJyZW50IAo8YnI+Jmd0OyAmZ3Q7IE1lc2ggRGVs aXZlcnkgRmllbGQgZGVmaW5pdGlvbiBzZWVtcyB0byBwcm9oaWJpdCBhbnkgZm9ybSBvZiBzb3Vy Y2Ugcm91dGluZy48YnI+Jmd0OyAmZ3Q7IEl0IGFzc3VtZXMgdGhhdCB0aGUgcm91dGluZyB0YWJs ZXMgYXJlIGFsbCBzZXQgdXAgYW5kIGNvcnJlY3Qgc28gdGhhdDxicj4mZ3Q7ICZndDsgdGhlIGZv cndhcmRlciBjYW4gJnF1b3Q7c3dpenpsZSZxdW90OyB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyBm aWVsZCBvZiB0aGUgCjE1LjQ8YnI+Jmd0OyAmZ3Q7IGhlYWRlciB3aXRoIGEgdGFibGUgZW50cnku Jm5ic3A7Jm5ic3A7KFRoZSBleHBlcmllbmNlIG9mIElQIG92ZXIgQVRNIGFuZCB0aGU8YnI+Jmd0 OyAmZ3Q7IHRob3VzYW5kcyBvZiBwYWdlcyBvZiB0aGUgUTgzYiBzaWduYWxsaW5nIHByb3RvY29s IHJlcXVpcmVkIHRvIHNldCB1cDxicj4mZ3Q7ICZndDsgYWxsIHRoZSB0YWJsZXMgaW4gYWR2YW5j ZSBvdWdodCB0byBnaXZlIHVzIGEgbGl0dGxlIHBhdXNlIGhlcmUuKSZuYnNwOyZuYnNwO1RoZSAK PGJyPiZndDsgJmd0OyBpZGVhIG9mIHN1cHBvcnRpbmcgdGFibGUtZHJpdmVuIHJvdXRpbmcgYW5k IHRoZXJlYnkgc2VwYXJhdGluZyB0aGU8YnI+Jmd0OyAmZ3Q7IHJvdXRlIGZvcm1hdGlvbiBmcm9t IHRoZSBmb3J3YXJkaW5nIGVuZ2luZSBpcyBhIGdvb2Qgb25lLCBidXQgdGhlcmU8YnI+Jmd0OyAm Z3Q7IG5lZWRzIHRvIGJlIGVub3VnaCBleHByZXNzaXZlIHBvd2VyIHRvIHN1cHBvcnQgdGhlIHBy b3RvY29scyB0aGF0IHdpbGwgCjxicj4mZ3Q7ICZndDsgZXN0YWJsaXNoIGFuZCBtYW5hZ2UgdGhv c2UgdGFibGVzIChyYXRoZXIgdGhhbiByZWx5aW5nIG9uIGFuIG9wYXF1ZTxicj4mZ3Q7ICZndDsg b3V0LW9mLWJhbmQgc2lnbmFsaW5nIG1lY2hhbmlzbSkgYW5kIHRoZXJlIG5lZWRzIHRvIGJlIHRo ZSBhYmlsaXR5IHRvPGJyPiZndDsgJmd0OyBxdWVyeSBhbmQgdmFsaWRhdGUgdGhvc2UgdGFibGVz IHdpdGhvdXQgcmVseWluZyBvbiBvdXQtb2YtYmFuZCAKPGJyPiZndDsgJmd0OyBtZWNoYW5pc21z Ljxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICgyKSBoYXMgaGlzdG9yaWNhbGx5IGJlIGFkZHJl c3NlZCB3aXRoIHByb3RvY29sIGlkZW50aWZpZXJzIGFuZDxicj4mZ3Q7ICZndDsgb3B0aW9ucy4m bmJzcDsmbmJzcDtBcyB3ZSB3ZW50IHRocm91Z2ggdGhlIHZhcmlvdXMgUklQLCBPU1BGLCBldGMu IHdlIGRpZG4ndDxicj4mZ3Q7ICZndDsgbmVlZCB0byBnbyBiYWNrIGFuZCByZWRlZmluZSB0aGUg Zm9ybWF0IGRvY3VtZW50cy4mbmJzcDsmbmJzcDtUaGVyZSB3YXMgZW5vdWdoIAo8YnI+Jmd0OyAm Z3Q7IGV4cHJlc3NpdmVuZXNzIGZvciB0b3BvbG9neSBmb3JtYXRpb24gYW5kIHJvdXRpbmcgdG8g ZXZvbHZlLiZuYnNwOyZuYnNwO05vdCBhbGw8YnI+Jmd0OyAmZ3Q7IG5ldHdvcmtzIG5lZWQgdG8g c3VwcG9ydCBhbGwgcHJvdG9jb2xzLiZuYnNwOyZuYnNwO1RoYXQgaGFzIGJlZW4gdGhlIG5ldHdv cms8YnI+Jmd0OyAmZ3Q7IGRlc2lnbmVycycgZGV0ZXJtaW5hdGlvbi4mbmJzcDsmbmJzcDtUaGUg dW5kZXJseWluZyBzdHJ1Y3R1cmUgcHJvdmlkZWQgdGhlIAo8YnI+Jmd0OyAmZ3Q7IHByaW1pdGl2 ZXMsIGFsbG93aW5nIHNvbHV0aW9ucyAoYW5kIGNvbnNlbnN1cykgdG8gZXZvbHZlLiZuYnNwOyZu YnNwO1dlIHdhbnQgdG88YnI+Jmd0OyAmZ3Q7IGF2b2lkIGNyZWF0aW5nIGEgJnF1b3Q7d2lubmVy IHRha2UgYWxsJnF1b3Q7IHN0cnVjdHVyZSB3aGVyZSB0aGVyZSBpcyBubyByb29tPGJyPiZndDsg Jmd0OyBmb3IgZXZvbHV0aW9uIGFuZCBkZXZlbG9wbWVudC4mbmJzcDsmbmJzcDtJdCBpcyBwb3Nz aWJsZSB0aGF0IEFPRFYsIG9yIFRpbnlBT0RWLCAKPGJyPiZndDsgJmd0OyBvciBEU1IsIG9yIEdQ U1Igb3IgcG9zc2libHkgb25lIG9mIHNldmVyYWwgb3RoZXIgYWx0ZXJuYXRpdmVzIGlzIHRoZSBy aWdodDxicj4mZ3Q7ICZndDsgc29sdXRpb24uJm5ic3A7Jm5ic3A7SG93ZXZlciwgdGhlcmUgaXMg bGl0dGxlIGV2aWRlbmNlIG9mIG9uZSBoYXZpbmcgY2xlYXIgc3VwZXJpb3JpdHk8YnI+Jmd0OyAm Z3Q7IGF0PGJyPiZndDsgJmd0OyB0aGlzIHRpbWUsIGRlc3BpdGUgbnVtZXJvdXMgaGlnaCBwcm9m aWxlIGVmZm9ydHMuJm5ic3A7Jm5ic3A7V2Ugc2hvdWxkIGJlIGRlZmluaW5nIHRoZSAKPGJyPiZn dDsgJmd0OyBjYW52YXMgdXBvbiB3aGljaCBjb21wZXRpbmcgYWx0ZXJuYXRpdmVzIGNhbiBiZSBk ZWZpbmVkIGFuZCB2ZXR0ZWQuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgKDMpIGhhcyBoaXN0 b3JpY2FsbHkgYmVlbiBhZGRyZXNzZWQgYnkgYSBsaW1pdGVkIGFiaWxpdHkgdG88YnI+Jmd0OyAm Z3Q7IGNvbW11bmljYXRlIG9uIHRoZSBsaW5rIHRvIGEgY3J1ZGVseSBkZWZpbmVkIHNldCBvZiBu b2RlcyBpbiBvcmRlciB0byAKPGJyPiZndDsgJmd0OyBib290c3RyYXAgdGhlIGRpc2NvdmVyeSwg am9pbiwgYWRkcmVzcyBhc3NpZ25tZW50LCBuZWdvdGlhdGlvbiwgZXRjLjxicj4mZ3Q7ICZndDsg TW9zdCBzdWNjZXNzZnVsIGxpbmtzIHVuZGVyIElQIGxvb2sgZWl0aGVyIGxpa2UgYSBicm9hZGNh c3QgbWVkaXVtIG9yPGJyPiZndDsgJmd0OyBhIHBvaW50LXRvLXBvaW50IGxpbmsgKGEgZGVnZW5l cmF0aXZlIGJyb2FkY2FzdCkuJm5ic3A7Jm5ic3A7VGhpcyBhbGxvd3MgQVJQLCAKPGJyPiZndDsg Jmd0OyBSQVJQLCBCT09UUCwgREhDUCwgZXRjLiB0byBnYWluIGhpZ2hlciBsZXZlbCBhY2Nlc3Np YmlsaXR5IGFuZDxicj4mZ3Q7ICZndDsgYWRkcmVzc2liaWxpdHkgdGhyb3VnaCB0aGUgbGluay4m bmJzcDsmbmJzcDtMaW5rcyB0aGF0IHJlcXVpcmUgY29tcGxleDxicj4mZ3Q7ICZndDsgc2lnbmFs aW5nLCBkaXNjb3ZlcnksIGpvaW5pbmcgYW5kIGNvb3JkbmF0aW9uIGJlbG93IHRoZSBsaW5rIGxh eWVyLCAKPGJyPiZndDsgJmd0OyBpbmNsdWRpbmcgQVRNLCBCbHVldG9vdGggKHBpY29uZXRzIGFu ZCBzY2F0dGVyIG5ldHMpLCBhbmQgSVJEQSBoYXZlPGJyPiZndDsgJmd0OyBwcm92ZWQgb25lcm91 cyBmb3IgSVAgYW5kIGhhdmUgYmVlbiByZWxlZ2F0ZWQgdG8gZmFyIGxlc3MgZ2VuZXJhbDxicj4m Z3Q7ICZndDsgdXNhZ2Ugc2NlbmFyaW9zIC0gc3VjaCBhcyB0aGUgZGVza3RvcCBVU0IgcmVwbGFj ZW1lbnQuJm5ic3A7Jm5ic3A7RXZlbiB0aG91Z2ggCjxicj4mZ3Q7ICZndDsgdGhlIHJhZGlvIGlz IGEgYnJvYWRjYXN0IG1lZGl1bSwgdGhlIGNoYWxsZW5nZSBpbiBhIHJvdXRlZCBsaW5rIGlzPGJy PiZndDsgJmd0OyB0aGF0IHRoZSBsaW5rIGlzIG5vdCBieSBkZWZhdWx0IGEgbGluay13aWRlIGJy b2FkY2FzdCBwaHkuJm5ic3A7Jm5ic3A7VGhlcmU8YnI+Jmd0OyAmZ3Q7IGFyZSB0d28gbmF0dXJh bCBub3Rpb25zIG9mICZxdW90O2Jyb2FkY2FzdCZxdW90OyBpbiBhIGxvd3Bhbi4mbmJzcDsmbmJz cDsoaSkgVGhlIHBoeXNpY2FsIAo8YnI+Jmd0OyAmZ3Q7IG5laWdoYm9ycyB0aGF0IGhhcHBlbiB0 byByZWNlaXZlIGEgdHJhbnNtaXNzaW9uIGJlY2F1c2UgdGhleSBhcmUgY2xvc2U8YnI+Jmd0OyAm Z3Q7IGVub3VnaCB0byBwaWNrIHVwIHRoZSBzaWduYWwgYW5kIGhhdmUgdGhlaXIgcmFkaW9zIHR1 cm5lZCBvbiB0bzxicj4mZ3Q7ICZndDsgcmVjZWl2ZS4mbmJzcDsmbmJzcDsoaWkpIFRoZSBlbnRp cmUgY29sbGVjdGlvbiBvZiBub2RlcyB0aGF0IGNhbiBiZSByZWFjaGVkIGJ5IGEgCjxicj4mZ3Q7 ICZndDsgbXVsdGlob3AgZGlzc2VtaW5hdGlvbiAoZmxvb2QpLiZuYnNwOyZuYnNwO0JvdGggb2Yg dGhlc2UgYXJlIGV4dHJlbWVseSB1c2VmdWwgaW48YnI+Jmd0OyAmZ3Q7IGJvb3RzdHJhcHBpbmcg aGlnaGVyIGxldmVscywgaW5jbHVkaW5nIHJvdXRpbmcsIGFuZCBzaG91bGQgYmU8YnI+Jmd0OyAm Z3Q7IGFkZHJlc3NlZCBpbiB0aGUgZm9ybWF0IGRvY3VtZW50LiZuYnNwOyZuYnNwO0FkZGl0aW9u YWxseSwgaXQgaXMgbm90IAo8YnI+Jmd0OyAmZ3Q7IG5lY2Nlc3NhcnkgdG8gdXNlIHRoZSA4MDIu MTUuNCBiZWFjb25pbmcgbWVjaGFuaXNtIHRvIGJyaW5nIHVwIElQIG92ZXI8YnI+Jmd0OyAmZ3Q7 IGEgMTUuNCBsaW5rLiZuYnNwOyZuYnNwO1Byb3ZpZGluZyBzb21lIGZvcm1zIG9mIGJyb2FkY2Fz dCB1c2luZyBkYXRhIGZyYW1lczxicj4mZ3Q7ICZndDsgbWFrZXMgdGhlIDgwMi4xNS40IGZvcm1h dCBtdWNoIG1vcmUgbGlrZSA4MDIuMTEKIGFuZCBvdGhlciBsaW5rcyB0aGF0PGJyPiZndDsgJmd0 OyBoYXZlIHByb3ZlZCB2ZXJ5IHN1aXRhYmxlIGZvciBJUC4mbmJzcDsmbmJzcDtGZXcsIGlmIGFu eSwgb2YgdGhlIHB1YmxpYyAxNS40IHJvdXRpbmc8YnI+Jmd0OyAmZ3Q7IGxheWVycyBkZXZlbG9w ZWQ8YnI+Jmd0OyAmZ3Q7IGJ5IHRoZSBUaW55T1MgY29tbXVuaXR5IHV0aWxpemUgYmVhY29uIHBh Y2tldHMuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgVGhlIHJlY29nbml0aW9uIHRoYXQgdGhl IGN1cnJlbnQgTWVzaCBEZWxpdmVyeSBmaWVsZCBtYXkgYmUgdG8gcmVzdHJpY3RpdmUgCjxicj4m Z3Q7ICZndDsgaXMgaW50aW1hdGVkIGJ5IHRoZSBuZWVkIHRvIGRlZmluZSBhIHNlY29uZCBmb3Jt IG9mIHRoZSBoZWFkZXIgZm9yPGJyPiZndDsgJmd0OyBtdWx0aWNhc3QgKGFuZCBsaW5rIGxvY2Fs IGJyb2FkY2FzdCkgdGhhdCBpbmNsdWRlcyBhIHNlcXVlbmNlIG51bWJlci48YnI+Jmd0OyAmZ3Q7 IFRoZSBtZXNoIGhlYWRlciBmaWVsZCB0eXBlIGlzIGRlZmluZWQgYnkgd2hldGhlciB0aGUgZGVz dGluYXRpb24gCjxicj4mZ3Q7ICZndDsgYWRkcmVzcyBpcyB1bmljYXN0IG9yIG11bHRpY2FzdC4g VGhlIGRvY3VtZW50IHN0YXRlcyB0aGF0IHRoZSB1c2Ugb2Y8YnI+Jmd0OyAmZ3Q7IHN1Y2ggYSBz ZXF1ZW5jZSBudW1iZXIgaXMgb3V0IG9mIHNjb3BlLiBIb3dldmVyLCB0aGUgb2JzZXJ2YXRpb24g dGhhdDxicj4mZ3Q7ICZndDsgdGhhdCBleHRyYSBpbmZvcm1hdGlvbiBtYXkgbmVlZCB0byBiZSBp bmNsdWRlZCBkZXBlbmRpbmcgb24gaG93IAo8YnI+Jmd0OyAmZ3Q7IHBhY2tldHMgYXJlIHJvdXRl ZCBmdXJ0aGVyIHN1Z2dlc3RzIHRoYXQgbW9yZSBjYXJlZnVsIGZvcm1hdDxicj4mZ3Q7ICZndDsg ZGVmaW5pdGlvbiBpcyBuZWVkZWQgdG8gc3VwcG9ydCBmdXR1cmUgZGV2ZWxvcG1lbnQgb2YgbWVz aCByb3V0aW5nLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IEhhdmUgZm9sa3Mgd2hvIGhhdmUg YmVlbiBkZXZlbG9waW5nIG1lc2ggbGF5ZXJzIGZvciBsb3dwYW42IGZlbHQgdGhhdCAKPGJyPiZn dDsgJmd0OyB0aGUgZXhpc3RpbmcgTWVzaCBEZWxpdmVyeSBGaWVsZCBpcyB0b28gcmVzdHJpY3Rp dmU/PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IERhdmlkIEUuIEN1bGxl cjxicj4mZ3Q7ICZndDsgVUMgQmVya2VsZXk8YnI+Jmd0OyAmZ3Q7IDxhIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86Y3Vs bGVyQGNzLmJlcmtlbGV5LmVkdSIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9mb2xsb3ciPgpjdWxs ZXJAY3MuYmVya2VsZXkuZWR1PC9hPjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsg Jmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJmd0OyA2bG93cGFuIG1haWxpbmcgbGlzdDxi cj4mZ3Q7ICZndDsgPGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3cs ZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzo2bG93cGFuQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayIgcmVsPSJub2ZvbGxvdyI+CjZsb3dwYW5AaWV0Zi5vcmc8L2E+PGJyPiZndDsgJmd0OyA8YSBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJl Zj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3BhbiIgdGFyZ2V0 PSJfYmxhbmsiIHJlbD0ibm9mb2xsb3ciPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvLzZsb3dwYW4KPC9hPjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZn dDs8YnI+Jmd0OyA8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4mZ3Q7IDZsb3dwYW4gbWFpbGluZyBsaXN0PGJyPiZndDsgPGEgb25jbGlj az0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1h aWx0bzo2bG93cGFuQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub2ZvbGxvdyI+CjZs b3dwYW5AaWV0Zi5vcmc8L2E+PGJyPiZndDsgPGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVu RXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4iIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vZm9sbG93Ij5o dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuPC9hPgo8YnI+PGJy Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyA8YnI+ Nmxvd3BhbiBtYWlsaW5nIGxpc3Q8YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0 TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzo2bG93cGFuQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayIgcmVsPSJub2ZvbGxvdyI+Nmxvd3BhbkBpZXRmLm9yZwo8L2E+PGJyPjxh IG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBo cmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuIiB0YXJn ZXQ9Il9ibGFuayIgcmVsPSJub2ZvbGxvdyI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vNmxvd3BhbjwvYT48L2Rpdj48L2Rpdj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmIj48 YnI+Jm5ic3A7PC9kaXY+PC9zcGFuPjwvZGl2PjwvZGl2PjwvZGl2Pjxicj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj42bG93cGFuIG1haWxpbmcgbGlz dDxicj48YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0 aGlzKSIgaHJlZj0ibWFpbHRvOjZsb3dwYW5AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiByZWw9 Im5vZm9sbG93Ij4KNmxvd3BhbkBpZXRmLm9yZzwvYT48YnI+PGEgb25jbGljaz0icmV0dXJuIHRv cC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Imh0dHBzOi8vd3d3MS5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4iIHRhcmdldD0iX2JsYW5rIiByZWw9Im5v Zm9sbG93Ij5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuPC9h Pjxicj4KPGJyPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+ PC9zcGFuPjwvZGl2PjxzcGFuPi0tIDxicj5LaS1IeXVuZyBLaW0gKLHoseLH/Cwg0N3Rw/r7KTxi cj5Bc3NvY2lhdGUgUHJvZmVzc29yPGJyPkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIGFuZCBDb21w dXRlciBFbmcuLCBBam91IFVuaXZlcnNpdHksIFN1d29uLCBLb3JlYSA0NDItNzQ5PGJyPlRlbDog KzgyLTMxLTIxOS0yNDMzLCBDZWw6ICs4Mi0xNy03NjAtMjU1MSwmbmJzcDsmbmJzcDtGYXg6ICs4 Mi0zMS0yMTktMjQzMyAKPGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5k b3csZXZlbnQsdGhpcykiIGhyZWY9Imh0dHA6Ly93d3cuNmxvd3Bhbi5vcmcvIiB0YXJnZXQ9Il9i bGFuayIgcmVsPSJub2ZvbGxvdyI+aHR0cDovL3d3dy42bG93cGFuLm9yZzwvYT4gPC9zcGFuPjwv YmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+RGF2aWQgRS4g Q3VsbGVyPGJyPgpBcmNoZWQgUm9jayBDb3Jwb3JhdGlvbjxicj4yMTY4IFNoYXR0dWNrIEF2ZTxi cj5CZXJrZWxleSwgQ0EgOTQ3MDQ8YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0 TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Imh0dHA6Ly93d3cuYXJjaGVkcm9jay5jb20v IiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub2ZvbGxvdyI+d3d3LmFyY2hlZHJvY2suY29tPC9hPjwv ZGl2PgoKPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGltZXMgbmV3 IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmIj48YnI+Jm5ic3A7PC9kaXY+PC9zcGFuPjwv ZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8 YnI+S2ktSHl1bmcgS2ltICix6LHix/wsINDd0cP6+yk8YnI+QXNzb2NpYXRlIFByb2Zlc3Nvcjxi cj5EaXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBhbmQgQ29tcHV0ZXIgRW5nLiwgQWpvdSBVbml2ZXJz aXR5LCBTdXdvbiwgS29yZWEgNDQyLTc0OQo8YnI+VGVsOiArODItMzEtMjE5LTI0MzMsIENlbDog KzgyLTE3LTc2MC0yNTUxLCZuYnNwOyZuYnNwO0ZheDogKzgyLTMxLTIxOS0yNDMzIDxhIGhyZWY9 Imh0dHA6Ly93d3cuNmxvd3Bhbi5vcmciPmh0dHA6Ly93d3cuNmxvd3Bhbi5vcmc8L2E+IAo= ------=_Part_22624_17963809.1159575371905-- --===============1385195424== 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 --===============1385195424==--