From pthubert@cisco.com Mon Feb 1 01:19:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B96728C0ED for <6lowpan@core3.amsl.com>; Mon, 1 Feb 2010 01:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.406 X-Spam-Level: X-Spam-Status: No, score=-9.406 tagged_above=-999 required=5 tests=[AWL=1.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcHtlr8cJo1c for <6lowpan@core3.amsl.com>; Mon, 1 Feb 2010 01:19:31 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6F26828C0E7 for <6lowpan@ietf.org>; Mon, 1 Feb 2010 01:19:31 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAcsZkutJV2Z/2dsb2JhbADBMYoYCYwtglKBcwQ X-IronPort-AV: E=Sophos;i="4.49,382,1262563200"; d="scan'208";a="294441108" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 01 Feb 2010 09:20:04 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o119JmM9016595; Mon, 1 Feb 2010 09:20:03 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 10:20:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Feb 2010 10:19:59 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0123594D@XMB-AMS-107.cisco.com> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429E0F@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing the extension header Thread-Index: AcqerSDlvUPU4wZPTzWnxxHqYGTliAAnP9kQAPTY58A= References: <4B5F2677.90905@jennic.com> <6D9687E95918C04A8B30A7D6DA805A3E01429E0F@zensys17.zensys.local> From: "Pascal Thubert (pthubert)" To: "Anders Brandt" , , <6lowpan@ietf.org> X-OriginalArrivalTime: 01 Feb 2010 09:20:03.0147 (UTC) FILETIME=[BC4591B0:01CAA31F] Subject: Re: [6lowpan] Compressing the extension header X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 01 Feb 2010 09:19:32 -0000 Hi Daniel: I do agree to.=20 Mesh headers do not belong to L3 but routing headers do, so it makes a lot more sense to discuss the compression of routing headers (RH) than mesh headers in 6LoWPAN.=20 I'm convinced that ROLL will work on compressing DAOs more. JP has already proposed a BNF to pack information. The record route piece in the DAO must also be compressed in a fashion that does not depend on 6LoWPAN but that 6LoWPAN HC could certainly take advantage of.=20 It makes sense to me to do the RPL compression work first to make sure we are compatible in the end... What do you think? Cheers, Pascal -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Anders Brandt Sent: mercredi 27 janvier 2010 13:26 To: daniel.gavelle@jennic.com; 6lowpan@ietf.org Subject: Re: [6lowpan] Compressing the extension header Daniel, I agree. This sounds like an obvious extension to the IPHC draft. It is a fair requirement that all intermediate nodes are in the same (local) subnet and may thus be compressed to short addresses. For sure the Internet or any backbone (?) will not use source routing anyway. Cheers, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Daniel Gavelle Sent: Tuesday, January 26, 2010 18:29 To: 6lowpan@ietf.org Subject: [6lowpan] Compressing the extension header When ROLL sends a packet from the DAG root to a node over a 6LowPAN network, there are two choices:- (1) Source routing is used, where the DAG root (edge router) is the only node that knows the route state. The root node would then use the "Routing Header" specified in RFC 2460 to specify the route. (2) Each routing node has a full routing table that knows the route to all its descendants (grand children, great grand children etc) as well as its immediate children and parent. Option (1) has several advantages, including reduced memory requirements for normal router nodes and avoiding the need to poison routes as the DAG changes. However, using source routing requires the full IPv6 address of each segment to be carried in the extension header. This will reduce the effectiveness of the very good work that has been done in draft-ietf-6lowpan-hc-06 to reduce the size of the IPv6 header. Adding context based compression of the addresses in a routing header would result in a much smaller header. All the addresses will have at least the same /64 prefix and if short addresses were used, only 16 bits would need to be stored for each address. Daniel. -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Mon Feb 1 14:16:52 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9983A6878 for <6lowpan@core3.amsl.com>; Mon, 1 Feb 2010 14:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3pmXB0xEziN for <6lowpan@core3.amsl.com>; Mon, 1 Feb 2010 14:16:51 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2E80E3A6838 for <6lowpan@ietf.org>; Mon, 1 Feb 2010 14:16:50 -0800 (PST) Received: from [192.168.1.3] (line-5011.dyn.kponet.fi [85.29.65.229]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o11MHKOP031920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Tue, 2 Feb 2010 00:17:21 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Feb 2010 00:17:22 +0200 References: <20100201215940.0D4FF3A68B6@core3.amsl.com> To: 6lowpan <6lowpan@ietf.org> Message-Id: Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 01 Feb 2010 22:16:53 -0000 Hi everyone, Thanks to an active discussion among the ND authors, and a bunch of = helpful reviews (thanks Richard, Anders and Colin), I finally managed to = post 6lowpan-nd-08, in its new slim form (think biggest loser). After = Hiroshima we reached good WG consensus to split the ND work into the = basic mechanism (which is now this document) and a separate Extended = LoWPAN draft (to be started), furthermore we agreed to deal with the DAD = issue. This document hopefully moves us very close to that goal. This = also includes the new RS feature suggested by Anders. http://www.ietf.org/id/draft-ietf-6lowpan-nd-08.txt As always with major changes (this needed lots of hacking and major = editing), there are surely tons of bugs and loose-ends left. Help to = find those appreciated. Changes from -07 to -08: o Removed Extended LoWPAN and Whiteboard related sections. o Included reference to the autoconf addressing model. o Added Optimistic Flag to 6AO. o Added guidelines on routers performing DAD. o Removed the NR/NC Advertising Interval. o Added assumption of uniform IID formation and DAD throughout a LoWPAN. The major open issue we have is how to develop the DAD text in Section = 5.3 in such a way that it works for most people, yet produces reliable = and safe LoWPANs, and is yet acceptable to the IPv6 crowd and especially = the IESG ;-) We are trying to find a balance to keep the WG happy, yet = having a chance to actually become an RFC....=20 It would also be nice to reduce the complexity of NR/NC and especially = 6AO message processing. Writing the spec, I am at least not totally = happy with the amount of explaining needed.... Is there a sleeker way to = deal with the addresses? Zach Begin forwarded message: > From: IETF I-D Submission Tool > Date: February 1, 2010 23:59:40 GMT+02:00 > To: zach@sensinode.com > Cc: = pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,cabo@tzi.org,E= rik.Nordmark@Sun.COM > Subject: New Version Notification for draft-ietf-6lowpan-nd-08=20 >=20 >=20 > A new version of I-D, draft-ietf-6lowpan-nd-08.txt has been = successfuly submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-ietf-6lowpan-nd > Revision: 08 > Title: 6LoWPAN Neighbor Discovery > Creation_date: 2010-02-01 > WG ID: 6lowpan > Number_of_pages: 46 >=20 > Abstract: > This document specifies a new Neighbor Discovery mechanism suitable > for LoWPANs. The 6LoWPAN format allows IPv6 to be used over energy > and bandwidth constrained wireless networks often making use of > multihop topologies. However, the use of classic IPv6 Neighbor > Discovery with 6LoWPAN has several problems. Classic Neighbor > Discovery was not designed for non-transitive wireless links, and the > traditional IPv6 link concept and heavy use of multicast makes it > unpractical. This document specifies a simple Neighbor Discovery > mechanism both sufficient yet minimal for LoWPAN operation. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From coflynn@newae.com Mon Feb 1 15:04:33 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B440728C1C6 for <6lowpan@core3.amsl.com>; Mon, 1 Feb 2010 15:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFGrJksakmmi for <6lowpan@core3.amsl.com>; Mon, 1 Feb 2010 15:04:32 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 4A09928C13E for <6lowpan@ietf.org>; Mon, 1 Feb 2010 15:04:32 -0800 (PST) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Na3yj-0005lt-A9 for 6lowpan@ietf.org; Wed, 27 Jan 2010 04:14:25 -0500 From: "Colin O'Flynn" To: <6lowpan@ietf.org> Date: Wed, 27 Jan 2010 09:16:55 -0000 Message-ID: <000901ca9f31$7b37f880$71a7e980$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CA9F31.7B37F880" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqfMXgbk73VBUi1Tii9T0A1m16QGg== Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: [6lowpan] New I-D: Initial Configuration of Resource-ConstrainedDevices (aka: Bootstrapping / Commissioning) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 01 Feb 2010 23:04:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01CA9F31.7B37F880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Cross-posted to both 6lowpan and 6lowapp, as of interest to both. However please try and keep discussion on 6lowapp mailing list to avoid further cross-posting / splintering of discussion. This I-D is a first-pass at identifying some of the problems and proposing some solutions. It overlaps some existing protocols a little, but I expect this I-D to undergo some pretty radical changes. It's a huge problem with a lot of different aspects, and not all of those are yet captured in this document. Regards, -Colin O'Flynn **************************************************************************** *** A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Initial Configuration of Resource-Constrained Devices Author(s) : C. O'Flynn Filename : draft-oflynn-6lowapp-bootstrapping-00.txt Pages : 27 Date : 2010-01-27 he Internet of Things is marching it's way towards completition. Nodes can use standards from the 6LoWPAN and ROLL WG to achieve IP connectivity. IEEE Standards ensure connectivity at lower layers for resource-constrained devices. Yet a central problem remains at a more basic layer without a suitable answer: how to initially configure the network. Without configuration the network never advances beyond a large box of nodes. Current solutions tend to be specific to a certain vendor, node type, or application. This document outlines exactly what problems are faced in solving this problem. General problems faced in any low-power wireless network are outlined first; followed by how these apply to bootstrapping. A selection of currently proposed techniques is presented. From these a more generic approach is presented, which can solve the problem for a wide range of situations. An emphasis is on performing this bootstrapping in a secure manner. This document does not cover operationg of the network securely. This document does provide the basis for allowing the network to operate securely however, by providing standard methods for key exchanges and authentication. A URL for this Internet-Draft is: http://www.ietf.org/id/draft-oflynn-6lowapp-bootstrapping-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_000A_01CA9F31.7B37F880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

Cross-posted to both 6lowpan and 6lowapp, as of interest to both. = However please try and keep discussion on 6lowapp mailing list to avoid further cross-posting / splintering of discussion.

This I-D is a first-pass at identifying some of the problems and = proposing some solutions. It overlaps some existing protocols a little, but I expect = this I-D to undergo some pretty radical changes. It's a huge problem with a lot = of different aspects, and not all of those are yet captured in this = document.

Regards,
 
  -Colin O'Flynn

*************************************************************************= ******

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

        Title           : = Initial Configuration of Resource-Constrained Devices
        Author(s)       : C. O'Flynn
        Filename        : draft-oflynn-6lowapp-bootstrapping-00.txt
        Pages           : = 27
        Date            : 2010-01-27

he Internet of Things is marching it's way towards completition.
Nodes can use standards from the 6LoWPAN and ROLL WG to achieve IP
connectivity.  IEEE Standards ensure connectivity at lower layers = for
resource-constrained devices.  Yet a central problem remains at = a
more basic layer without a suitable answer: how to initially
configure the network.  Without configuration the network never
advances beyond a large box of nodes.  Current solutions tend to = be
specific to a certain vendor, node type, or application.

This document outlines exactly what problems are faced in solving
this problem.  General problems faced in any low-power wireless
network are outlined first; followed by how these apply to
bootstrapping.  A selection of currently proposed techniques is
presented.  From these a more generic approach is presented, = which
can solve the problem for a wide range of situations.

An emphasis is on performing this bootstrapping in a secure manner.
This document does not cover operationg of the network securely.
This document does provide the basis for allowing the network to
operate securely however, by providing standard methods for key
exchanges and authentication.

A URL for this Internet-Draft is:
http://www.ietf.org/id/draft-oflynn-6lowapp-bootstrappi= ng-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-oflynn-6lowapp= -bootstrapping-00.txt>

------=_NextPart_000_000A_01CA9F31.7B37F880-- From daniel.gavelle@jennic.com Tue Feb 2 00:53:01 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C063A6AEB for <6lowpan@core3.amsl.com>; Tue, 2 Feb 2010 00:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJwHJRmXkFCN for <6lowpan@core3.amsl.com>; Tue, 2 Feb 2010 00:53:00 -0800 (PST) Received: from mail.jennic.com (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id 67BDC3A6AEA for <6lowpan@ietf.org>; Tue, 2 Feb 2010 00:52:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 408E89BE4FD; Tue, 2 Feb 2010 08:53:35 +0000 (GMT) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErIOE1QJdvps; Tue, 2 Feb 2010 08:53:35 +0000 (GMT) Received: from [10.99.98.20] (dgave.jennic.com [10.99.98.20]) by mail.jennic.com (Postfix) with ESMTP id 16BCC9BE4FC; Tue, 2 Feb 2010 08:53:35 +0000 (GMT) Message-ID: <4B67E80F.7010808@jennic.com> Date: Tue, 02 Feb 2010 08:53:35 +0000 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4B5F2677.90905@jennic.com> <6D9687E95918C04A8B30A7D6DA805A3E01429E0F@zensys17.zensys.local> <6A2A459175DABE4BB11DE2026AA50A5D0123594D@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0123594D@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Compressing the extension header X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 08:53:01 -0000 If source routing is used, the route will be stored in every header, not just the ROLL ICMP messages. Therefore this compression will need to go in the 6LowPAN HC rather than ROLL. Compression of source route addresses in the extension header would be beneficial when any source routing were used, not just ROLL. Compressing the addresses in ROLL DAO messages would also be useful. In most LowPAN's, the first 64 bits of the sub-net is likely to be the same for every node in the network. Even more bits will be common if 16 bit addresses are used. Context based compression would be a very good way to compress these addresses. Using the same address compression algorithm in ROLL and 6LowPAN-HC would reduce code size and ease implementation on what is likely to be a common class of nodes that run both ROLL and 6LowPAN-HC. Daniel. Pascal Thubert (pthubert) wrote: > Hi Daniel: > > I do agree to. > Mesh headers do not belong to L3 but routing headers do, so it makes a > lot more sense to discuss the compression of routing headers (RH) than > mesh headers in 6LoWPAN. > I'm convinced that ROLL will work on compressing DAOs more. JP has > already proposed a BNF to pack information. The record route piece in > the DAO must also be compressed in a fashion that does not depend on > 6LoWPAN but that 6LoWPAN HC could certainly take advantage of. > It makes sense to me to do the RPL compression work first to make sure > we are compatible in the end... > What do you think? > > Cheers, > > Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Anders Brandt > Sent: mercredi 27 janvier 2010 13:26 > To: daniel.gavelle@jennic.com; 6lowpan@ietf.org > Subject: Re: [6lowpan] Compressing the extension header > > Daniel, > > I agree. > > This sounds like an obvious extension to the IPHC draft. > > It is a fair requirement that all intermediate nodes are > in the same (local) subnet and may thus be compressed to short > addresses. > For sure the Internet or any backbone (?) will not use source routing > anyway. > > Cheers, > Anders > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Daniel Gavelle > Sent: Tuesday, January 26, 2010 18:29 > To: 6lowpan@ietf.org > Subject: [6lowpan] Compressing the extension header > > When ROLL sends a packet from the DAG root to a node over a 6LowPAN > network, there are two choices:- > > (1) Source routing is used, where the DAG root (edge router) is the only > node that knows the route state. The root node would then use the > "Routing Header" specified in RFC 2460 to specify the route. > > (2) Each routing node has a full routing table that knows the route to > all its descendants (grand children, great grand children etc) as well > as its immediate children and parent. > > Option (1) has several advantages, including reduced memory requirements > for normal router nodes and avoiding the need to poison routes as the > DAG changes. > > However, using source routing requires the full IPv6 address of each > segment to be carried in the extension header. This will reduce the > effectiveness of the very good work that has been done in > draft-ietf-6lowpan-hc-06 to reduce the size of the IPv6 header. > > Adding context based compression of the addresses in a routing header > would result in a much smaller header. All the addresses will have at > least the same /64 prefix and if short addresses were used, only 16 bits > would need to be stored for each address. > > Daniel. > > > > > > -- > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 > Registered In England http://www.jennic.com > __________________________________________________ > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From robert.cragie@gridmerge.com Tue Feb 9 14:53:11 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6F428C16C for <6lowpan@core3.amsl.com>; Tue, 9 Feb 2010 14:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7eKO6E6V4yw for <6lowpan@core3.amsl.com>; Tue, 9 Feb 2010 14:53:10 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id D460E28C168 for <6lowpan@ietf.org>; Tue, 9 Feb 2010 14:53:08 -0800 (PST) Received: from [12.190.142.90] (helo=[192.168.170.174]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1Neyy2-0005ut-2x; Tue, 09 Feb 2010 22:54:14 +0000 Message-ID: <4B71E782.2040902@gridmerge.com> Date: Tue, 09 Feb 2010 22:53:54 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <20100201215940.0D4FF3A68B6@core3.amsl.com> <4B701131.7080703@gridmerge.com> In-Reply-To: <4B701131.7080703@gridmerge.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060303020407020401040907" X-Mailman-Approved-At: Fri, 12 Feb 2010 23:35:15 -0800 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:53:11 -0000 This is a cryptographically signed message in MIME format. --------------ms060303020407020401040907 Content-Type: multipart/mixed; boundary="------------060203090205000409070206" This is a multi-part message in MIME format. --------------060203090205000409070206 Content-Type: multipart/alternative; boundary="------------040803030100040905000609" --------------040803030100040905000609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Zach, I have been through the document and made some corrections (in yellow) and some comments (in cyan) - see attachment. The main things I found were: * Inconsistent terminology. Bar the actual definitions, the terms, 'host', 'node', 'router' and 'Edge Router' should be used throughout, not a 'LoWPAN' variant of them. * Some hangovers re. whiteboard and Extended LoWPAN * DAD not covered - as mentioned below * Propagation of RS/RA not covered * Hints at relaying NR/NC but not covered * Assumption that IID will use EUI-64 whereas it could be formed from alternate link-layer address. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Robert Cragie wrote: > Hi Zach, > > I have been through the document and made some corrections (in yellow) > and some comments (in cyan) - see attachment. > > The main things I found were: > > * Inconsistent terminology. Bar the actual definitions, the terms, > 'host', 'node', 'router' and 'Edge Router' should be used > throughout, not a 'LoWPAN' variant of them. > * Some hangovers re. whiteboard and Extended LoWPAN > * DAD not covered - as mentioned below > * Propagation of RS/RA not covered > * Hints at relaying NS/NC but not covered > * Assumption that IID will use EUI-64 whereas it could be formed > from alternate link-layer address. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > > Zach Shelby wrote: >> Hi everyone, >> >> Thanks to an active discussion among the ND authors, and a bunch of helpful reviews (thanks Richard, Anders and Colin), I finally managed to post 6lowpan-nd-08, in its new slim form (think biggest loser). After Hiroshima we reached good WG consensus to split the ND work into the basic mechanism (which is now this document) and a separate Extended LoWPAN draft (to be started), furthermore we agreed to deal with the DAD issue. This document hopefully moves us very close to that goal. This also includes the new RS feature suggested by Anders. >> >> http://www.ietf.org/id/draft-ietf-6lowpan-nd-08.txt >> >> As always with major changes (this needed lots of hacking and major editing), there are surely tons of bugs and loose-ends left. Help to find those appreciated. >> >> Changes from -07 to -08: >> >> o Removed Extended LoWPAN and Whiteboard related sections. >> >> o Included reference to the autoconf addressing model. >> >> o Added Optimistic Flag to 6AO. >> >> o Added guidelines on routers performing DAD. >> >> o Removed the NR/NC Advertising Interval. >> >> o Added assumption of uniform IID formation and DAD throughout a >> LoWPAN. >> >> The major open issue we have is how to develop the DAD text in Section 5.3 in such a way that it works for most people, yet produces reliable and safe LoWPANs, and is yet acceptable to the IPv6 crowd and especially the IESG ;-) We are trying to find a balance to keep the WG happy, yet having a chance to actually become an RFC.... >> >> It would also be nice to reduce the complexity of NR/NC and especially 6AO message processing. Writing the spec, I am at least not totally happy with the amount of explaining needed.... Is there a sleeker way to deal with the addresses? >> >> Zach >> >> Begin forwarded message: >> >> >>> From: IETF I-D Submission Tool >>> Date: February 1, 2010 23:59:40 GMT+02:00 >>> To: zach@sensinode.com >>> Cc: pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,cabo@tzi.org,Erik.Nordmark@Sun.COM >>> Subject: New Version Notification for draft-ietf-6lowpan-nd-08 >>> >>> >>> A new version of I-D, draft-ietf-6lowpan-nd-08.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository. >>> >>> Filename: draft-ietf-6lowpan-nd >>> Revision: 08 >>> Title: 6LoWPAN Neighbor Discovery >>> Creation_date: 2010-02-01 >>> WG ID: 6lowpan >>> Number_of_pages: 46 >>> >>> Abstract: >>> This document specifies a new Neighbor Discovery mechanism suitable >>> for LoWPANs. The 6LoWPAN format allows IPv6 to be used over energy >>> and bandwidth constrained wireless networks often making use of >>> multihop topologies. However, the use of classic IPv6 Neighbor >>> Discovery with 6LoWPAN has several problems. Classic Neighbor >>> Discovery was not designed for non-transitive wireless links, and the >>> traditional IPv6 link concept and heavy use of multicast makes it >>> unpractical. This document specifies a simple Neighbor Discovery >>> mechanism both sufficient yet minimal for LoWPAN operation. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> >> >> > > ------------------------------------------------------------------------ > > > [Docs <../html/>] [txt > ] [pdf > ] [WG <../wg/6lowpan>] [Email > ] > [Diff1 ] > [Diff2 ] [Nits > ] > > Versions: (draft-hui-6lowpan-nd <./draft-hui-6lowpan-nd>) 00 > <./draft-ietf-6lowpan-nd-00> 01 <./draft-ietf-6lowpan-nd-01> 02 > <./draft-ietf-6lowpan-nd-02> 03 <./draft-ietf-6lowpan-nd-03> > 04 <./draft-ietf-6lowpan-nd-04> 05 <./draft-ietf-6lowpan-nd-05> 06 > <./draft-ietf-6lowpan-nd-06> 07 <./draft-ietf-6lowpan-nd-07> 08 > <./draft-ietf-6lowpan-nd-08> > > > 6lowpan Working Group Z. Shelby, Ed. > Internet-Draft Sensinode > Updates: 4944 <./rfc4944> (if approved) P. Thubert > Intended status: Standards Track Cisco > Expires: August 5, 2010 J. Hui > Arch Rock > S. Chakrabarti > IP Infusion > C. Bormann > Universitaet Bremen TZI > E. Nordmark > Sun > February 1, 2010 > > > 6LoWPAN Neighbor Discovery > draft-ietf-6lowpan-nd-08 <./draft-ietf-6lowpan-nd-08> > > Abstract > > This document specifies a new Neighbor Discovery mechanism suitable > for LoWPANs. The 6LoWPAN format allows IPv6 to be used over energy > and bandwidth constrained wireless networks often making use of > multihop topologies. However, the use of classic IPv6 Neighbor > Discovery with 6LoWPAN has several problems. Classic Neighbor > Discovery was not designed for non-transitive wireless links, and the > traditional IPv6 link concept and heavy use of multicast makes it > unpractical. This document specifies a simple Neighbor Discovery > mechanism both sufficient yet minimal for LoWPAN operation. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 <./bcp78> and BCP 79 <./bcp79>. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > > > > Shelby, et al. Expires August 5, 2010 [Page 1] > > <#page-2> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on August 5, 2010. > > Copyright Notice > > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 <./bcp78> and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4 <#section-4>.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 2] > > <#page-3> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > Table of Contents > > 1 <#section-1>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 <#page-4> > 1.1 <#section-1.1>. Goals, Assumptions, and Guesses . . . . . . . . . . . . . 5 <#page-5> > 1.2 <#section-1.2>. Why not classic IPv6 ND? . . . . . . . . . . . . . . . . . 5 <#page-5> > 2 <#section-2>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 <#page-6> > 2.1 <#section-2.1>. 6LoWPAN Terminology . . . . . . . . . . . . . . . . . . . 7 <#page-7> > 2.2 <#section-2.2>. ND Terminology . . . . . . . . . . . . . . . . . . . . . . 9 <#page-9> > 3 <#section-3>. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 <#page-10> > 3.1 <#section-3.1>. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 11 <#page-11> > 3.2 <#section-3.2>. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 12 <#page-12> > 3.3 <#section-3.3>. Operation . . . . . . . . . . . . . . . . . . . . . . . . 13 <#page-13> > 4 <#section-4>. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 <#page-13> > 4.1 <#section-4.1>. Node Registration/Confirmation Message . . . . . . . . . . 14 <#page-14> > 4.2 <#section-4.2>. Router Solicitation Message . . . . . . . . . . . . . . . 16 <#page-16> > 4.3 <#section-4.3>. Router Advertisement Message . . . . . . . . . . . . . . . 17 <#page-17> > 4.4 <#section-4.4>. Message Options . . . . . . . . . . . . . . . . . . . . . 18 <#page-18> > 4.4.1 <#section-4.4.1>. 6LoWPAN Address Option . . . . . . . . . . . . . . . . 18 <#page-18> > 4.4.2 <#section-4.4.2>. 6LoWPAN Information Option . . . . . . . . . . . . . . 19 <#page-19> > 4.4.3 <#section-4.4.3>. 6LoWPAN Summary Option . . . . . . . . . . . . . . . . 21 <#page-21> > 4.4.4 <#section-4.4.4>. Owner Interface Identifier Option . . . . . . . . . . 22 <#page-22> > 5 <#section-5>. Protocol Specification . . . . . . . . . . . . . . . . . . . . 23 <#page-23> > 5.1 <#section-5.1>. Interface initialization . . . . . . . . . . . . . . . . . 23 <#page-23> > 5.2 <#section-5.2>. Node Registration . . . . . . . . . . . . . . . . . . . . 24 <#page-24> > 5.2.1 <#section-5.2.1>. Processing a Node Registration Message . . . . . . . . 25 <#page-25> > 5.2.2 <#section-5.2.2>. Processing a Node Confirmation Message . . . . . . . . 25 <#page-25> > 5.3 <#section-5.3>. Duplicate Address Detection . . . . . . . . . . . . . . . 26 <#page-26> > 5.4 <#section-5.4>. Next-hop Determination . . . . . . . . . . . . . . . . . . 27 <#page-27> > 5.5 <#section-5.5>. Address Resolution . . . . . . . . . . . . . . . . . . . . 27 <#page-27> > 5.6 <#section-5.6>. Unreachability Detection . . . . . . . . . . . . . . . . . 28 <#page-28> > 5.7 <#section-5.7>. Context Dissemination . . . . . . . . . . . . . . . . . . 28 <#page-28> > 6 <#section-6>. Node Specification . . . . . . . . . . . . . . . . . . 29 <#page-29> > 6.1 <#section-6.1>. Conceptual structures . . . . . . . . . . . . . . . . . . 29 <#page-29> > 6.2 <#section-6.2>. Conceptual variables . . . . . . . . . . . . . . . . . . . 30 <#page-30> > 7 <#section-7>. Router Specification . . . . . . . . . . . . . . . . . 30 <#page-30> > 7.1 <#section-7.1>. Router Configuration Variables . . . . . . . . . . . . . . 30 <#page-30> > 7.2 <#section-7.2>. Becoming an Advertising Interface . . . . . . . . . . . . 30 <#page-30> > 7.3 <#section-7.3>. Router Advertisement Message Content . . . . . . . . . . . 31 <#page-31> > 7.4 <#section-7.4>. Sending Unsolicited Router Advertisements . . . . . . . . 32 <#page-32> > 7.5 <#section-7.5>. Ceasing To Be an Advertising Interface . . . . . . . . . . 32 <#page-32> > 7.6 <#section-7.6>. Processing Router Solicitations . . . . . . . . . . . . . 32 <#page-32> > 7.7 <#section-7.7>. Binding Table . . . . . . . . . . . . . . . . . . . . . . 32 <#page-32> > 8 <#section-8>. Ad-hoc LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . 32 <#page-32> > 9 <#section-9>. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 33 <#page-33> > 10 <#section-10>. Use of 6LoWPAN-ND under RFC4861 <./rfc4861>-only stacks . . . . . . . . . 34 <#page-34> > 11 <#section-11>. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 34 <#page-34> > 11.1 <#section-11.1>. NR/NC message exchange . . . . . . . . . . . . . . . . . . 34 <#page-34> > 11.2 <#section-11.2>. Router advertisement . . . . . . . . . . . . . . . . . . . 36 <#page-36> > > > > Shelby, et al. Expires August 5, 2010 [Page 3] > > <#page-4> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 12 <#section-12>. Security Considerations . . . . . . . . . . . . . . . . . . . 37 <#page-37> > 13 <#section-13>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 <#page-38> > 14 <#section-14>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 <#page-38> > 15 <#section-15>. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 38 <#page-38> > 16 <#section-16>. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 <#page-42> > 16.1 <#section-16.1>. Normative References . . . . . . . . . . . . . . . . . . . 42 <#page-42> > 16.2 <#section-16.2>. Informative References . . . . . . . . . . . . . . . . . . 43 <#page-43> > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 <#page-44> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 4] > > <#page-5> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 1. Introduction > > The IPv6 over IEEE 802.15.4 [RFC4944 <./rfc4944>] document has specified how to > carry IPv6 packets over IEEE 802.15.4 and similar networks (6LoWPANs > or LoWPANs for short) with the help of an adaptation header which > comes before the IP header. A link in such a 6LoWPAN is > characterized as lossy, low-power, low bit-rate, short range, with > many nodes saving energy with long deep sleep periods. Multicast as > used in classic IPv6 Neighbor Discovery [RFC4861 <./rfc4861>] is not desirable in > such a wireless low-power, lossy network. > > Moreover, LoWPAN links are asymmetric and non-transient in nature; > they are not always considered to be in a fixed network nor are they > bounded by our traditional definition of a wired-link. A LoWPAN is > potentially composed of a large amount of overlapping radio ranges, > eventually federated by a backbone or a backhaul link. Although a > given radio range has broadcast capabilities, the aggregation of > these is a complex Non-Broadcast MultiAccess (NBMA, [RFC2491 <./rfc2491>]) > structure with (generally) no LoWPAN-wide multicast capabilities. > link-local scope is in reality defined by reachability and radio > strength. Thus we can consider a LoWPAN to be made up of links with > undetermined connectivity properties as defined in > [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>], along with the corresponding > assumptions defined therein. The classic IPv6 Neighbor Discovery > [RFC4861 <./rfc4861>] control messages, the use of multicast and their default > frequency also attribute to unnecessary waste of energy in LoWPANs. > > This specification introduces a new mechanism called Node > Registration, used to optimize the interface between hosts and > routers in a LoWPAN. That registration mechanism provides a service > somewhat similar to the Multicast Address Resolution Server (MARS) > [RFC2022 <./rfc2022>] for a limited purpose, and in a much simpler and less > generic fashion. The use of Router Advertisements to disseminate > prefix and header compression context throughout the LoWPAN is also > specified. The solution supports the use of both link-layer- or > LoWPAN-level mesh (Mesh Under) and IP routing (Route Over) solutions > for multihop forwarding. This specification is both sufficient and > required for LoWPAN operation. The 6LoWPAN-ND mechanism could also > coexist with [RFC4861 <./rfc4861>], [RFC3122 <./rfc3122>] or other future ND mechanisms > (although the motivation or detailed specification of such > coexistence is out of scope for the present document). > > The document defines two new ICMPv6 messages: Node Registration and > Node Confirmation. > > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 5] > > <#page-6> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 1.1. Goals, Assumptions, and Guesses > > This document has the following main goals and assumptions, as well > as two guesses that may or may not be true in a specific LoWPAN but > still have shaped the optimizations. > > Goals: > > o Optimize ND with a mechanism that is minimal yet sufficient for > LoWPAN operation in both mesh-under and route-over configurations. > > o Minimize signalling by avoiding the use of multicast flooding and > reducing the frequency of link scope multicast messages inside the > LoWPANs. > > o Disseminate context information throughout the LoWPAN used by > [I-D.ietf-6lowpan-hc <#ref-I-D.ietf-6lowpan-hc>]. > > o Minimize the complexity of nodes. > > o Optimize the interfaces between nodes and their default routers. > > Assumptions: > > o A subnet includes all the nodes sharing the same IPv6 > prefix. > > o A single LoWPAN is configured in a homogeneous way, i.e., IIDs are > formed by nodes in a uniform matter and DAD is performed by > routers in a uniform way. > > o Link layer technology is e.g. IEEE 802.15.4 as in [RFC4944 <./rfc4944>], or > any other link-layer exhibiting non-transitivity or a similar > topology. > > 1.2. Why not classic IPv6 ND? > > IPv6 Neighbor Discovery [RFC4861 <./rfc4861>] provides several important > functions such as Router Discovery, Address Resolution, Duplicate > Address Detection, Redirect, Prefix and Parameter Discovery. > > Following power-on and initialization of the network in IPv6 Ethernet > networks, a node joins the solicited-node multicast address on the > interface and then performs duplicate address detection (DAD) for the > acquired link-local address by sending a solicited-node multicast > message to the link. After that it sends multicast messages to the > all-router address to solicit router advertisements. Once the host > receives a valid router advertisement with the "A" flag, it > > > > Shelby, et al. Expires August 5, 2010 [Page 6] > > <#page-7> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > autoconfigures the IPv6 address with the advertised prefix in the > router advertisement (RA). Besides this, the IPv6 routers usually > send router advertisements periodically on the network. RAs are sent > to the all-node multicast address. Nodes send Neighbor Solicitation/ > Neighbor Advertisement messages to resolve the IPv6 address of the > destination on the link. These NS/NA messages are also often > multicast messages and it is assumed that the node is on the same > link and relies on the fact that the destination node is always > powered and generally reliable. > > A LoWPAN network typically uses two types of L2 addresses -- for > example 16-bit short addresses and 64-bit unique addresses as defined > in [RFC4944 <./rfc4944>]. Moreover, the available L2 payload size on the order > of less than 100 bytes where we often might need to use header > compression and use a minimum payload. The network is lossy and low- > powered, and it does not provide multicast capability at the link- > layer, thus simulating multicast behavior by both using broadcast or > sending a number of unicast messages, both expensive for the low- > powered network and the low-processing capable nodes. Often these > low-powered nodes conserve energy by using sleep schedules; waking > them up to receive IPv6 signaling messages such as multicast messages > for NS or periodic RAs is not practical. Also they are not capable > of processing address-resolution for their neighbors effectively. > Due to the radio strength of its neighboring router or its own > strength, a node may often move from one router to another without > physically moving from one place to another. Considering the above > characteristics in a LoWPAN, and the IPv6 Neighbor Discovery > [RFC4861 <./rfc4861>] base protocol requirements, it was concluded that classic > Neighbor Discovery is not suitable as it is and a 6LoWPAN-specific ND > definition would be useful and efficient for the wide deployment of > IPv6 over low-powered wireless networks of embedded devices. > > > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119 <./rfc2119>]. > > This specification requires readers to be familiar with all the terms > and concepts that are discussed in "IPv6 Stateless Address > Autoconfiguration" [RFC4862 <./rfc4862>], "IPv6 over Low-Power Wireless Personal > Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, > and Goals" [RFC4919 <./rfc4919>], "Transmission of IPv6 Packets over IEEE > 802.15.4 Networks" [RFC4944 <./rfc4944>] and "IP Addressing Model in Ad Hoc > Networks" [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>]. > > Readers would benefit from reading "Optimistic Duplicate Address > > > > Shelby, et al. Expires August 5, 2010 [Page 7] > > <#page-8> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > Detection" [RFC4429 <./rfc4429>] ("oDAD") prior to this specification. > > This specification makes extensive use of the same terminology > defined in [RFC4861 <./rfc4861>] unless otherwise redefined below. > > 2.1. 6LoWPAN Terminology > > This section defines additional general terms related to the 6LoWPAN > architecture used in this specification: > > IP Routing > > The forwarding of datagrams at the IP layer between arbitrary > source-destination pairs, during which the IPv6 hop limit is > decremented. In the LoWPAN context, IP routing is performed by > routers on a single interface within the same subnet. > Exact match search is performed on the destination address of the > IP packet to find the next-hop to the destination. Referred to as > routing in this document. > > Link > > The link is a communication facility or medium over which nodes > can communicate at the link-layer, i.e., the layer directly below > IP ([RFC4861 <./rfc4861>]). 6LoWPAN assumes the use of low-power and lossy > wireless links such as IEEE 802.15.4, which is a special type of > link as described in [RFC4861 <./rfc4861>] exhibiting severe asymmetric > reachability with both asymmetric (A can reach B, but B can't > reach A) and non-transitive (A can reach B, and B can reach C, but > A can't reach C) qualities. The use of link-layer mesh technology > (see Mesh Under) emulates transitivity across the link but still > has problems with asymmetricity. Multicast on a link-layer mesh, > if available, is often implemented as an expensive broadcast > flood. Due to their nature, these are considered links with > undetermined connectivity properties as defined in > [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>]. > > Link-local > > Standard IPv6 link-local scope is defined in [RFC4291 <./rfc4291>] and > [RFC4861 <./rfc4861>]. Link-local scope is achieved by setting the hop limit > to 1, using a link-local prefix (FE80::) or link-local multicast > scope (FFx2::). If a link is non-transitive then link-local scope > may include only a subset of nodes on the link (the set of nodes > within symmetric radio range of a node). Nodes in the link-local > scope of a node are its neighbors, and this link-local scope may > differ from the perspective of each node. Therefore, link-local > addresses are of limited value as discussed in > > > > Shelby, et al. Expires August 5, 2010 [Page 8] > > <#page-9> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>]. > > LoWPAN Host > > A node that only sources or sinks IPv6 datagrams. Referred to as > a host in this document. > > LoWPAN Node > > A node that composes a LoWPAN, referring to both hosts and > routers. Simply called a node in this document. > > LoWPAN Router > > A LoWPAN node that forwards datagrams between arbitrary source- > destination pairs using a single 6LoWPAN interface performing IP > routing on that interface. Referred to as a router in this document. > > LoWPAN Mesh node > > A LoWPAN node that forwards data between arbitrary source- > destination pairs using link addresses (and thus only exists in > Mesh Under LoWPANs). > > Mesh Under > > A term referring to a configuration where the link-local scope is > defined by the boundaries of the LoWPAN (or a sizable part of it, > if Mesh Under is combined with Route Over) and includes all the > 6LoWPAN interfaces within it. There are forwarding and multihop > routing functions at L2 to achieve transitivity on the link. In > this configuration the link may still exhibit lossy, asymmetric, > NBMA (non-availability of mesh-wide multicast) behavior. > > Route Over > > A term referring to a configuration where the LoWPAN is made up of > several partially overlapping links and link-local scope reaches > only a subset of the nodes. IP routing is performed by > routers to provide connectivity across the LoWPAN. A > LoWPAN with this configuration may consist of both routers and > hosts. Route Over and Mesh Under are not mutually exclusive, and > IP routing may be used between links that perform Mesh Under. > > Subnet > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 9] > > <#page-10> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > A subnet is the collection of interfaces having the same IPv6 > subnet prefix on a link, as defined in [RFC4291 <./rfc4291>]. A LoWPAN is > made up of the interfaces of nodes and Edge Routers sharing > the same subnet prefix. This Route Over configuration exhibits a > multi-hop subnet feature with regard to hop limit as discussed in > [RFC4903 <./rfc4903>], and thus 6LoWPAN applications should be careful when > making assumptions about the hop limit as it may be decremented in > a LoWPAN. > > 2.2. ND Terminology > > This section defines Neighbor Discovery specific terminology used in > this specification: > > Simple LoWPAN > > A Simple LoWPAN consists of a single Edge Router and the set of > nodes on the same LoWPAN Subnet, shown in Figure 1. > > Ad-hoc LoWPAN > > An isolated LoWPAN, not connected to any other IP networks. Ad- > Hoc LoWPANs make use of Unique on-link IPv6 Unicast Addresses > (ULAs) [RFC4193 <./rfc4193>]. > > Backbone Link > > This is an IPv6 link that interconnects two or more Edge Routers > in an Extended LoWPAN topology. It is expected to be deployed as > a high speed backbone in order to federate a potentially large set > of LoWPANs. > > LoWPAN Edge Router > > An IPv6 router that interconnects the LoWPAN to another IP > network. Referred to as an Edge Router in this document. > > Registration > > The process during which a LoWPAN node sends a Node Registration > message to a router creating a binding for the node. > > > > > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 10] > > <#page-11> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > Infrastructure Cloud > | > | > | > +-----+ > | | Edge > | | Router > +-----+ > o o > o o o > o o o o o o: Node > o o o o > o o o > > Simple LoWPAN > > > Figure 1: A simple LoWPAN topology > > > 3. Protocol Overview > > 6LoWPAN Neighbor Discovery (6LoWPAN-ND) optimizes IPv6 ND with a > mechanism which is on its own minimal yet sufficient for LoWPAN IPv6 > operation. 6LoWPAN-ND defines a node registration mechanism > optimizing the node-router interface. This mechanism requires no > flooding and reduces link-local multicast frequency. 6LoWPAN-ND > supports non-transitive links, the use of both mesh-under and route- > over techniques and makes no assumptions about synchronization > between hosts using the same router. This specification is REQUIRED > for LoWPAN operation, but MAY also coexist with [RFC4861 <./rfc4861>], [RFC3122 <./rfc3122>] > or other future ND mechanisms. Any use of [RFC4944 <./rfc4944>] without this > specification is NOT RECOMMENDED. > > The following features are defined by 6LoWPAN-ND (see Section > Section 5 <#section-5> for details): > > Node Registration: Method in which nodes in the LoWPAN register with > routers, creating state about nodes attached to that router > (binding table). > > Next-hop Determination: The specification defines a simple next-hop > determination rule. > > Address Resolution: The Node Registration mechanism provides > sufficient a priori state in nodes and routers to resolve an IPv6 > address to its associated link-layer address on the node-router > interface. Host-host resolution is out of scope of this > > > > Shelby, et al. Expires August 5, 2010 [Page 11] > > <#page-12> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > specification. > > Unreachability Detection: Unreachability between a node and router > is determined based on link-layer acknowledgements to node > registration and unicast data messages. Host-host unreachability > detection is out of scope. Destination unreachability detection > is performed using ICMPv6 destination unreachable messages. > > Context Dissemination: The dissemination of LoWPAN context as used > by [I-D.ietf-6lowpan-hc <#ref-I-D.ietf-6lowpan-hc>] is defined as an ICMPv6 option, along > with an associated summary option to reduce message size when many > contexts are advertised. > > This specification makes use of RS/RA message exchanges similar to > classic ND, which in 6LoWPAN-ND may also carry additional options for > context dissemination (6LoWPAN Information Option, 6IO) and reducing > RA message size (6LoWPAN Summary Option, 6SO). In addition > 6LoWPAN-ND defines two new ICMP packet types: > > Node Registration (NR): Sent by a node to a router to register a > binding. > > Node Confirmation (NC): The response sent by a router back to the > registering node. > > 3.1. Topology > > 6LoWPAN-ND makes little assumption about synchronization between > nodes in a LoWPAN except between a node and the routers it has > registered with. 6LoWPAN-ND is designed to work also with Ad-hoc > topologies. The case of Ad-hoc LoWPAN operation is described in > Section 8 <#section-8>. > > 6LoWPAN-ND is compatible with the use of link-layer mesh or [RFC4944 <./rfc4944>] > mesh techniques, which alleviate the otherwise non-transitive nature > of wireless links. If used throughout the LoWPAN, this so-called > Mesh Under topology thus makes the entire link appear to the IP layer > as having a link-local scope covering all the 6LoWPAN interfaces in > the LoWPAN. This kind of LoWPAN is made up of hosts and Edge > Routers. This link still exhibits lossy, low-rate, asymmetric > behavior along with sleep cycles. The non-transitive nature of the > link can also be overcome using IP routing within the LoWPAN, also > called a Route Over topology. Routers are used in the LoWPAN > to provide routing between all nodes in the LoWPAN. Router > operations are specified in Section 7 <#section-7>. Link-local scope includes the > neighbors of each node within symmetric wireless range. Mesh Under > and Route Over techniques are not mutually exclusive, and it may be > possible to combine IP routing and mesh link-layers within a LoWPAN. > > > > Shelby, et al. Expires August 5, 2010 [Page 12] > > <#page-13> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 3.2. Bootstrapping > > 1. A node (host or router) first forms an Interface Identifier (IID) > from its EUI-64 or other appropriate MAC address, and goes on to form > a link-local unicast address as in [RFC4944 <./rfc4944>]. When a node > wants to join a LoWPAN, it does so by listening for Router > Advertisements, or by broadcasting a Router Solicitation (RS) and > receiving RA responses from on-link routers (see Figure 2). If a > valid prefix is advertised in the RA, the host may also autoconfigure > a global address. At this point the node has also chosen one or more > default routers based on RAs. > > 2. Next the node will attempt to perform initial Node Registration. > Registration is always performed with a link-local router by sending > a unicast Node Registration (NR) message to it. This message > exchange is illustrated in Figure 3. The NR includes the addresses > the node wants to register, and it is possible to request the router > to assign an address. > > 3. After processing the addresses and performing DAD if necessary, > the router replies with a Node Confirmation (NC). This confirmation > includes the set of addresses now confirmed by this router. The Host > is now capable of using the LoWPAN. > > > Node Router > | | > | ---------- Router Solicitation --------> | > | | > | <-------- Router Advertisement --------- | > | | > > > Figure 2: Basic RS/RA exchange between a node and any on-link router > (or Edge Router) > > > > Node Router > | | > | ---------- Node Registration --------> | > | | > | <--------- Node Confirmation --------- | > | | > > > Figure 3: Basic ND registration exchange > > > > > Shelby, et al. Expires August 5, 2010 [Page 13] > > <#page-14> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 3.3. Operation > > The node may now send packets to any IPv6 address inside or outside > the LoWPAN. Next-hop determination assumes destinations are off-link > (and thus forwarded to a default router) except for link-local scope > addresses which are always on-link. The information needed for > resolving the link-layer address of default routers or registered > nodes is known a priori as a result of node registration. > > The router binding table is soft, and thus must be renewed > periodically as indicated by the lifetime of the binding. This is > achieved by periodically sending a new NR message. If a host moves, > or the network topology changes, and the current routers are no > longer available, the host then starts the registration process with > another router. If the host is still in the same LoWPAN (same subnet > prefix), its IPv6 addresses remain the same. If the host moves to a > different LoWPAN (thus with a different subnet prefix), the > bootstrapping process is initiated again. See Section 6 <#section-6> for details > on node operation. > > Routers periodically send RAs to their neighbors. The Edge > Router initiates the first RAs, and information from these RAs is > included in the RAs of each further router, causing the information > to be disseminated throughout the LoWPAN. RA periods should be > optimized to reduce signalling. See Section 7 <#section-7> for detailed router > operation. > > > 4. Message Formats > > This section defines the message and option formats used in this > document. The new messages are all ICMPv6 messages. In addition, > new options for ICMPv6 messages are defined. > > The following new ICMPv6 message types are defined: > > o Node Registration (NR) > > o Node Confirmation (NC) > > In addition, the following new ICMPv6 options are defined: > > o 6LoWPAN Address Option (6AO) > > o 6LoWPAN Information Option (6IO) > > o 6LoWPAN Summary Option (6SO) > > > > > Shelby, et al. Expires August 5, 2010 [Page 14] > > <#page-15> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > o Owner Interface Identifier Option (OIIO) > > The following [RFC4861 <./rfc4861>] messages are used as specified in this > section: > > o Router Solicitation (RS) > > o Router Advertisement (RA) > > 4.1. Node Registration/Confirmation Message > > The Node Registration (NR) and Node Confirmation (NC) messages are > used by a node to register with a router. Any option that is not > recognized MUST be skipped silently. The Node Registration message > is sent by the node to the link-local unicast IPv6 address of > a on-link router. > > When registering for the first time, the node still has > optimistic addresses therefore the source address > of the Node Registration must be the IPv6 unspecified address to > comply with oDAD. In subsequent registrations, the IPv6 source > address is then the link-local IPv6 address of the sender. A > registration is periodically refreshed by sending a new NR message > more frequently than the Binding Lifetime indicated by the node > during registration. > > Address Options are included in the NR message for each IPv6 address > to be registered, and included in the corresponding NC to indicate > success. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type |Status | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TID |P|R| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Binding Lifetime | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Owner Nonce | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Owner Interface Identifier + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Registration option(s)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 4: Node Registration/Confirmation message format > > > > Shelby, et al. Expires August 5, 2010 [Page 15] > > <#page-16> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > IP Fields: > > Source Address: The IPv6 address of the source. This address > MUST be the IPv6 unspecified address for initial registration. > > Destination Address: The link-local unicast IPv6 address of a on- > link router when sent by a node. > > Hop Limit: 255 > > ICMP Fields: > > Type: TBD1 for Node Registration, TBD2 for Node Confirmation. > > Status: 4-bit unsigned integer. Sent only in NC messages, > ignored in NR messages. Values 0-7 are reserved for success > codes: > > 0 is unqualified success. > > Values 8-15 are reserved for error codes: > > 8 is send to indicate that the router is saturated and an > alternative router should be used. > > Code: 4-bit unsigned integer. > > 0 indicates this NR is a request sent directly from the > originating host, or this NC is a corresponding response. > > 1 indicates that the NR message has been relayed by a > router, or that the NC is to be relayed by the router > indicated as the destination. (For future use) > > 2 indicates this NC is a request <#> for the node to re- > register. > > 4-15 are reserved for future use. > > Checksum: The ICMP checksum. > > TID: 8-bit unsigned integer. A unique Transaction ID assigned by > the host and used to match replies. A lollipop mechanism is > used to increment the TID upon each new registration. The TID > is not incremented upon a on-link refresh. In a Node > Confirmation, the TID is that of the corresponding NR. TID is set > to 0 upon booting, and is incremented with each NR message. > After reaching 0xFF, the value loops to 16 (0x10) and is > > > > Shelby, et al. Expires August 5, 2010 [Page 16] > > <#page-17> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > incremented from there. Thus the values between 0-15 MUST only > used after a boot or reboot. > > P: 1-bit Primary flag. Not yet used by this specification, always > set to 1. > > R: 1-bit Router flag. Used to indicate the role of node sending > the NR message. Set to 0 by hosts and to 1 by routers. > > Binding Lifetime: 16-bit unsigned integer. The amount of time in > 10 second intervals remaining before the binding of this owner > interface identifier, and all associated address options and > configuration options, MUST be considered expired. A value of > zero indicates that the Binding Cache entries for the > registered owner interface identifier MUST be deleted. A value > of 0xFFFF indicates an idefinite lifetime. (The 16-bit field > covers up to slightly more than a week of Binding Lifetime.) > > Reserved: This field is unused. It MUST be initialized to zero > by the sender and MUST be ignored by the receiver. > > Owner Interface Identifier (OII): A globally unique identifier > for the requesting host's interface. Typically the EUI-64 > derived IID. > > Owner Nonce: A 32-bit Nonce generated randomly by the node upon > booting, and generated again each time the node re-boots. This > Nonce may be used to detect duplicate OIIs. > > Possible Options: > > 6LoWPAN Address Option(s): An Address Option is included for each > address the host wants to bind for this interface. > > 6LoWPAN Information Option: This option includes information > about the prefixes of the LoWPAN along with other context > information. Although normally carried in RA messages, a 6IO > option MAY also be carried in NC messages. > > Future versions of this protocol may define new option types. > Receivers MUST silently ignore any options they do not recognize > and continue processing the message. > > 4.2. Router Solicitation Message > > The RS message format for 6LoWPAN is identical to the classic > [RFC4861 <./rfc4861>] RS message. The following clarifications are made > regarding the use of RS in LoWPANs. > > > > Shelby, et al. Expires August 5, 2010 [Page 17] > > <#page-18> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > If a node has only optimistic addresses not yet confirmed by a > Router, then the IPv6 source address in the RS MUST be the IPv6 > unspecified address. The Source Link-Layer Address Option MUST NOT > be included in the RS at any time. Instead the Owner Interface > Identifier specified in this document MUST be included in the RS. > > The Code field of the Router Solicitation message is used to > indicate whether a node wants to receive the full set of 6IOs in the > RA response, or just the 6SO. An RS with Code = 0 is used to request > just the 6LoWPAN Summary Option, and Code = 1 is used to request the > full set of 6IOs. > > 4.3. Router Advertisement Message > > The RA message format for 6LoWPAN is identical to the classic > [RFC4861 <./rfc4861>] RA message. The use of flags is however defined in the > 6LoWPAN context, and additional new options are identified. RA > messages are sent either to link-local all-nodes multicast, or to a > link-local unicast address as a response to an RS. > > Updated Flag Definitions: > > Prf: 2-bit signed integer. Default Router Preference as defined > in [RFC4191 <./rfc4191>]. Indicates whether to prefer this router over > other default routers. Routers with no Edge Router available > MUST set Prf to (11) for low preference, routers with Edge Router > availability <#> MUST set Prf to (00) for normal preference, and > Edge Routers MUST set Prf to (01) for high preference. > > Options: > > 6LoWPAN Information Option: This option includes information > about the prefixes of the LoWPAN along with other context > information. > > 6LoWPAN Summary Option: This option provides a sequence number > associated with the current prefix options. It allows the > prefix options themselves to be sent only when a change has > occured, or when requested with an RS Code = 1. > > Prefix Information Option: If needed for backward compatibility, > an RA may also be sent using the classic [RFC4861 <./rfc4861>] Prefix > Information Option which all LoWPAN nodes MUST be able to > parse. If possible, routers in the LoWPAN SHOULD make use of > 6IO and 6SO options instead of PIO. > > The MTU and SLLAO options defined in [RFC4861 <./rfc4861>] are not used by > this specification. > > > > Shelby, et al. Expires August 5, 2010 [Page 18] > > <#page-19> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > Future versions of this protocol may define new option types. > Receivers MUST silently ignore any options they do not recognize > and continue processing the message. > > 4.4. Message Options > > This section defines the new 6LoWPAN-ND message options. > > 4.4.1. 6LoWPAN Address Option > > The 6LoWPAN Address Option (6AO) is used to indicate the address > which a node wants to register, and to indicate the success or > failure of that binding in an NC. Multiple Address Options can be > included in a message. In order to be as compact as possible, fields > are used to indicate the compression of the IPv6 address. The 6AO > also allows for duplicate addresses (e.g. anycasts), the request of a > generated address for claim and defend use, or for an address to be > removed. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Status | S | P | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |D|A|R|O| Reserved | IPv6 Address ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 5: 6LoWPAN Address Option format > > Type: TBD3 > > Length: 8-bit unsigned integer. The length of the option (including > the type and length fields) in units of 8 octets. > > Status: 8-bit unsigned integer. 0 means unqualified success. Any > value below 128 is a positive status that means that the binding > for this address was created or is being created optimistically. > Only used in a confirmation. > > D: 1-bit Duplicate flag. When set, indicates that duplicates are > allowed for this address (to support anycast) in a request. > > A: 1-bit Address Generation flag. Set to indicate that the host is > requesting a generated address for claim and defend addressing. > In a request when A is set the IPv6 address length is 0. Set to > indicate that an address has been assigned in a confirmation. P > and S are set to indicate the type of address requested and > > > > Shelby, et al. Expires August 5, 2010 [Page 19] > > <#page-20> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > assigned when A is set. Otherwise must be 0. > > R: 1-bit Removal flag. When set, indicates that this particular > address binding MUST be removed from a whiteboard (in a request) > or MUST not be used any longer (in a confirmation) <#>. > > O: 1-bit Optimistic flag. When set, indicates that this particular > address is optimistic and has not yet been checked for duplicates. > > P: 5-bit unsigned integer. Identifies prefix compression or type, if > any. > > 0-15: Prefix compressed; upon decompression, the prefix given by > the compression context with the same numerical CID as the P > field given is inserted. > > 16: Prefix is carried inline. > > 17: Prefix compressed; upon decompression, the link-local prefix > (fe80::) is inserted. > > 18-31: Reserved. > > S: 3-bit unsigned integer. Identifies suffix compression or type, if > any. > > 0: Suffix carried inline. > > 1: Suffix compressed and assumes the same value as the Owner > Interface Identifier field in the NR/NC message header. > > 2: Suffix compressed for an IID formed from an IEEE 802.15.4 16- > bit short addresses. Only the 16-bit short-address is carried > in-line. The IID is formed from this address as specified in > [RFC4944 <./rfc4944>]. > > 3-7: Reserved. > > IPv6 Address: The IPv6 address to be registered with the router, or > confirmed by the router. Parts of the address may be elided as per > the P and S fields. > > 4.4.2. 6LoWPAN Information Option > > This option carries prefix information for LoWPANs, and is similar in > use to the Prefix Information Option of [RFC4861 <./rfc4861>]. However this > option allows for the dissemination of multiple contexts identified > by a Context Identifier (CID) for use in 6LoWPAN address compression. > > > > Shelby, et al. Expires August 5, 2010 [Page 20] > > <#page-21> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Info Length |L|A|C|V| CID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Valid Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . Prefix or Address Information . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 6: 6LoWPAN Information Option format > > Type: TBD4 > > Length: 8-bit unsigned integer. The length of the option (including > the type and length fields) in units of 8 octets. May be 1, 2 or > 3 depending on the length of the Information field. > > Info Length: 8-bit unsigned integer. The number of leading bits in > the Information field that are valid. The value ranges from 0 to > 128. The info length field provides necessary information for on- > link determination (when combined with the L flag in the prefix > information option). It also assists with address > autoconfiguration as specified in [RFC4862 <./rfc4862>], for which there may > be more restrictions on the info length. > > L: 1-bit on-link flag, similar to the L flag in [RFC4861 <./rfc4861>]. This flag > MUST be unset for Route Over LoWPANs and Extended LoWPANs, and MAY > be set for Mesh Under Simple LoWPANs <#>. > > A: 1-bit autonomous address-configuration flag. When set indicates > that this prefix can be used for stateless address configuration > as specified in [RFC4861 <./rfc4861>]. > > C: 1-bit context flag. This flag indicates that this information > option also serves as a context on the LoWPAN, which is identified > by the CID field. > > V: 1-bit context validity flag. This flag indicates if the context > is valid, and is used only in combination with the C flag. A > context that is not valid MUST not be used for compression, but > MAY be used in decompression in case another compressor still > considers the context as valid. > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 21] > > <#page-22> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > CID: 4-bit Context Identifier for this prefix information. CID is > used by context based header compression specified in > [I-D.ietf-6lowpan-hc <#ref-I-D.ietf-6lowpan-hc>]. The list of CIDs for a LoWPAN is > configured on Edge Routers, who distribute the prefix list to all > nodes in the LoWPAN. > > Valid Lifetime: 32-bit unsigned integer. The length of time in > seconds (relative to the time the packet is sent) that the prefix > is valid for the purpose of on-link determination. A value of all > one bits (0xffffffff) represents infinity. > > Information: The IPv6 prefix or context information indicated. This > may be a partial prefix, a partial context or even an entire IPv6 > address for use as a context for compression. > > 4.4.3. 6LoWPAN Summary Option > > This option identifies the set of prefix information options by a > sequence number. This allows for the full set of prefix information > options to be sent only periodically in unsolicited RAs. If a host > detects a difference in the sequence number of this option, then the > prefix information has likely changed, and is then requested with an > RS. An RA sent in response to a unicast RS always includes the full > set of prefix information. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V| Reserved | ER Metric | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: 6LoWPAN Summary Option > > Type: TBD5 > > Length: 1 > > Sequence Number: 16-bit signed integer. Indicates the freshness of > the information advertised by the RA. > > ER Metric: 16-bit unsigned integer. The ER Metric gives an > indication of the cost (in routing metric terms) of reaching nodes > outside the LoWPAN via an Edge Router through this router. The metric > SHOULD be derived in a well-defined way from the routing protocol > used in the LoWPAN (possibly by structuring the 16 bits available > e.g. into a major and a minor metric), and has a mid-range default > > > > Shelby, et al. Expires August 5, 2010 [Page 22] > > <#page-23> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > value of 0x8000. Edge Routers most likely set this field to 0. A > host SHOULD take this metric into account when choosing default > routers by making a scalar comparison, preferring routers with > numerically lower ER Metric values. > > V: 1-bit flag. Indicates if the sequence number is valid and the > router is advertising information obtained from another router. > > Reserved: This field is unused. It MUST be initialized to zero by > the sender and MUST be ignored by the receiver. > > 4.4.4. Owner Interface Identifier Option > > This option is used together with Router Solicitation messages when a > node has only optimistic addresses before initial registration. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | TID | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Owner Nonce | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Owner Interface Identifier + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 8: Owner Interface Identifier Option > > Type: TBD6 > > Length: 2 > > TID: 8-bit unsigned integer. This field is set to the last TID > value used for sending an NR message. > > Reserved: This field is unused. It MUST be initialized to zero by > the sender and MUST be ignored by the receiver. > > Owner Nonce: A 32-bit Owner Nonce generated randomly by the node > upon booting, and generated again each time the node re-boots. > This Owner Nonce is used to detect duplicate OIIs. > > Owner Interface Identifier: A globally unique identifier for the > host's interface. This is typically the EUI-64 derived IID of the > interface. > > > > > Shelby, et al. Expires August 5, 2010 [Page 23] > > <#page-24> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 5. Protocol Specification > > This section specifies the functions defined by this specification, > along with pointers to needed procedures from other specifications. > These basic procedures are sufficient and required for LoWPAN > operation. > > 5.1. Interface initialization > > A LoWPAN node forms a 64-bit Interface Identifier (IID) as specified > in Section 6 of [RFC4944] <./rfc4944#section-6>. This may be based on the EUI-64 > identifier, an assigned 16-bit short address, or any other > appropriate MAC address. All nodes MUST configure at least one > address, a link-local address, by concatenating its IID with the > prefix FE80::/64 as specified in Section 7 of [RFC4944] <./rfc4944#section-7>. As a > result, knowledge of the IID of another node is enough to > derive its link-local address and reach it on the same link. If > derived from an EUI-64 or an equivalent the link-local address is > presumably unique on the LoWPAN, which enables the use of Optimistic > Duplicate Address Detection (oDAD) [RFC4429 <./rfc4429>]. The address SHOULD be > created as optimistic before it has been confirmed by Node > Registration (Section Section 5.2 <#section-5.2>). This document assumes that > addresses are formed in a uniform manner in a LoWPAN. Appropriate > steps SHOULD be taken to ensure that only correctly configured > devices participate in the LoWPAN, e.g. using L2 security mechanisms. > > A node MUST join the all-nodes multicast address, which is used for > receiving RAs from routers. A router MUST also join the all-routers > multicast address. A node MAY join other multicast addresses such as > the solicited-node multicast address if its link-layer includes > multicast support, but that is not required by this specification. > > Nodes MAY learn the address of routers using traditional means such > as L2 configuration or Router Advertisement messages as in [RFC4861 <./rfc4861>]. > When sending a Router Solicitation it MUST not have the SLLAO Option, > but instead MUST include the OII Option. If the sender of the RS has > only optimistic addresses, it MUST not use them as the IPv6 source > address for the RS, but instead uses the IPv6 unspecified address. > This procedure is to comply with the use of optimistic addresses as > per oDAD [RFC4429 <./rfc4429>]. > > The node SHOULD also form a global unicast address for routing inside > the LoWPAN and reachability from outside the LoWPAN. If a valid > prefix is available from an RA ('A' flag is set), then a global > unicast address MAY be derived following the general description in > Section 5.5 of [RFC4862] <./rfc4862#section-5.5>. This address is marked optimistic until > confirmed by the Node Registration process. If the LoWPAN is > operating in ad-hoc mode, then the prefix is a Unique on-link IPv6 > > > > Shelby, et al. Expires August 5, 2010 [Page 24] > > <#page-25> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > Address (ULA) prefix [RFC4193 <./rfc4193>] as specified in Section 8 <#section-8> (use of a > ULA prefix requires no changes to node operation). A node MAY > alternatively acquire a global unicast address using other suitable > means, e.g. DHCPv6, L2 assignment or manual configuration. > > 5.2. Node Registration > > The node registration process is very similar to that of a MIPv6 > mobile node, though the messages used are new Node Registration/Confirmation ICMP > messages. A node address is optimistic as long as the binding is > not confirmed by a router. The node sends a unicast Node > Registration to an on-link router to perform the binding. While a > node's addresses are still optimistic (first registration in a > LoWPAN), the IPv6 unspecified address must be used as the source. > Registration SHOULD be preferred with on-link Edge Routers rather > than routers if available. The Preference Flag of the RA is > used to differentiate between Edge Routers (Prf=01) and routers > (Prf=00). Routers with Prf=11 SHOULD NOT be used for > registration. Furthermore the ER Metric in the 6LoWPAN Summary > Option SHOULD be used to rank routers. > > A unique Owner Interface Identifier (OII) is included in the Node > Registration so the binding can be identified throughout the LoWPAN. > The OII SHOULD be formed from the EUI-64 of the interface <#> in the same > way as the node's link-local address IID as defined in [RFC4944 <./rfc4944>]. A > randomly generated 32-bit Owner Nonce is formed each time a node > boots or reboots. This is included in the NR and may be used to > detect duplicate OIIs. While cryptographic randomness [RFC4086 <./rfc4086>] is > not strictly required, the randomness SHOULD be derived using a > mechanism of similar quality. > > The NR message includes an Address Option for each address to be > registered. Thus the message is structured as follows: > > ICMPv6 (Node Registration (Address Option[0], Address Option[1], > Address Option[n])) > > This registration method includes a way of requesting a unique > address by setting the 'A' flag in an Address Option during > registration. This is useful for receiving a unique short link-layer > address. How a router assigns such an address is out of scope for > this document. > > A unique Transaction ID (TID) is included by the host in the NR > message and used to match replies. A lollipop mechanism is used. > TID is set to 0 upon booting, and is incremented with each Request NR > message. The TID MUST NOT be incremented when sending a Refresh NR > message. After reaching 0xFF, the value loops to 16 (0x10) and is > > > > Shelby, et al. Expires August 5, 2010 [Page 25] > > <#page-26> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > incremented from there. Thus the values between 0-15 MUST only used > after a boot or reboot while not yet registered. A node that has not > heard a valid Node Confirmation for 16 Node Registration messages in > a row restarts with a on-link next TID of zero (the node MAY, but > need not, generate a new Owner Nonce). > > The acknowledgment to a Node Registration is a unicast Node > Confirmation message that contains the status of the bindings. The > source of the packet is the link-local address of the on-link router. > The destination address is the link-local address of the node. An > Address Option for each confirmed or assigned address is included. > Upon successful completion in the Node Confirmation message, the > node sets the address from optimistic to preferred. See > Section 11 <#section-11> for message examples. > > Node bindings have timeouts associated with them, therefore nodes > must periodically send a new Node Registration message to renew the > binding. The period between Request NR messages SHOULD be less than > BindingLifetime. If a node no longer receives Node Confirmation > messages from any router in the current subnet, the registration > process starts over. > > 5.2.1. Processing a Node Registration Message > > When a router receives a Node Registration message from a node, it > first checks for correctness of the message fields and options. In > the case of an existing node, the message is used to refresh the > corresponding entries in the router's binding table. > > In the case of a new node, then a binding table entry is made for > each 6AO in the message. The router SHOULD perform Duplicate Address > Detection on each optimistic address (O flag set), see Section 5.3 <#section-5.3> > for further information on the DAD procedure. If a 6AO option with > an A flag is received, then the router should acquire a suitable > address for the node. How this is done is out of scope. Depending > on the link-layer and network it may be possible to generate a random > address (DAD MUST be performed in this case), acquire an address from > a link-layer coordinator, or perform DHCPv6 in a managed network to > name a few. > > After processing all 6AO options, a unicast Node Confirmation message > is sent back to the node with an appropriate NC Status code and > success codes for each 6AO option in the same order as received. > > 5.2.2. Processing a Node Confirmation Message > > When a node receives a Node Confirmation message from a router, it > first checks for correctness of the message fields and options. > > > > Shelby, et al. Expires August 5, 2010 [Page 26] > > <#page-27> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > If a NC is received with a success status (0-7), then the node goes > on to process 6LoWPAN Address Options. If a successful NC is > received with a code of 2, this indicates that the node should re- > register with that router. > > 6LoWPAN Address Options are processed one at a time. A success > status (0-127) indicates that the address was successfully bound with > the router. If the address is marked optimistic, it is now updated > to preferred. A failure code (128-) indicates that the binding > failed. See Section 4.4.1 <#section-4.4.1> for an explanation of 6AO codes. A > binding failure may indicate that a duplicate address (and thus a > duplicate IID) already exists. In this case the node SHOULD attempt > to form a new IID and restart the registration process. If this is > not possible, the node MUST not participate in the LoWPAN. > > If a NC is received with an error status (8 or greater), then the > registration has failed. See Section 4.1 <#section-4.1> for an explanation of NR/NC > codes. If no successful Node Confirmation is received within the > timeout (RegistrationTimeout) and number of retries > (RegistrationRetries), then registration should be performed with > another router in the default router list. > > 5.3. Duplicate Address Detection <#> > > It is important for proper network operation that duplicate addresses > are not used in a LoWPAN as described in "IPv6 Stateless Address > Autoconfiguration" [RFC4862 <./rfc4862>]. Furthermore, as LoWPANs are made up of > links with undetermined connectivity, it is important that address > uniqueness is ensured thoughout the routing domain as discussed in > [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>]. Hosts may be very > simple, and thus are not expected to have the capability of > performing a duplicate address detection (DAD) algorithm themselves. > Therefore the handling of DAD is considered a function of routers. > This document does not perform DAD as defined in [RFC4862 <./rfc4862>], > but instead makes use of alternative techniques appropriate for > LoWPANs. It is assumed that all routers in a LoWPAN are configured > to perform DAD in a uniform way. If there is only a single router in > the LoWPAN, as occurs in mesh-under or star topologies, then a router > automatically detects duplicates by checking its own binding table > during registration, thus no additional mechanism is needed. > > If a router receives a Node Registration 6AO with the Optimistic Flag > (O) set, it SHOULD perform DAD on this address. If the router > generates or assigns an address for a node in response to a 6AO with > the A flag set, it SHOULD perform DAD on that address. DAD MAY be > disabled if the address has been generated or assigned in such a way > that there is high confidence of no duplicates (WARNING IN LARGE > PRINT). Examples include the use of an EUI-64 to form an IID or > > > > Shelby, et al. Expires August 5, 2010 [Page 27] > > <#page-28> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > DHCPv6 performed through a single server uniformly by all nodes in > the LoWPAN (as per the homogeneous LoWPAN assumption). > > A router can be configured to perform DAD using one of the following > techniques, the details of which are out of the scope of this > document: > > Extended LoWPAN <#>: The Extended LoWPAN technique defined in (draft > tbd) provides DAD during its ER registration. > > Routing protocol: If supported, a routing protocol mechanism could > be used to check for the existance of an address in the LoWPAN, > assuming that it is covered by a single routing domain. > > 5.4. Next-hop Determination > > The IP address of the next-hop for a destination is determined as > follows. Destinations to the link-local prefix (FE80::) are always > sent on the link to that destination. All other prefixes are assumed > to be off-link as recommended in > [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>]. They are therefore sent to the > IP address of a router chosen from the Default Router List. > > Multicast addresses are considered to be on-link and are resolved as > specified in [RFC4944 <./rfc4944>] or relative future documents <#>. A node > is not required to maintain a minimum of one buffer per neighbor as > specified in [RFC4861 <./rfc4861>], as address lookup is not performed as part of > next-hop determination. Anycast addresses are always considered to > be off-link. > > 5.5. Address Resolution > > The node registration mechanism provides sufficient a priori state in > nodes and routers to resolve an IPv6 address to its associated link- > layer address on the node-router interface. As prefixes are always > assumed to be off-link, resolution between hosts is not needed. > > Information about link-layer addresses is stored by nodes about > routers in its default router list, and by routers about nodes in its > binding table. This information is stored during the node > registration process. In order to achieve LoWPAN compression, most > global addresses are also formed using a link-layer address. A node > can minimize memory usage by making use of an educated guess and > storing link-layer address information only if it differs from the > link-layer address corresponding to the IID of the IPv6 address > (i.e., differs in more than the on-link/global bit being inverted). > > > > > > Shelby, et al. Expires August 5, 2010 [Page 28] > > <#page-29> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 5.6. Unreachability Detection > > Unreachability between a node and router is determined based on NR/NC > and RS/RA exchanges and other unicast L3 data messages. Host-host > unreachability detection is out of scope. > > In order to detect unreachable destinations, nodes SHOULD support > type 1 ICMPv6 destination unreachable messages [RFC4443 <./rfc4443>]. LoWPAN > Routers or Edge Routers make use of ICMPv6 destination unreachable to > indicate that delivery to that destination is not possible. > > 5.7. Context Dissemination > > Network configuration parameters carried in Router Advertisements > originate at Edge Routers and must disseminate to all routers and > hosts within the LoWPAN <#>. RAs include either 6LoWPAN Information > Options (one for each context) and a 6LoWPAN Summary Option, or just > a 6LoWPAN Summary Option. > > For the dissemination of context information using the 6IO, a strict > lifecycle SHOULD be used in order to ensure the context information > stays synchronized throughout the LoWPAN. New context information > SHOULD be introduced into the LoWPAN with C=1 and V=0, to ensure it > is known by all nodes that may have to decompress based on this > context information. Only when it is reasonable to assume that this > information was successfully disseminated SHOULD an option with C=1 > and V=1 be sent, enabling the actual use of the context information > for compression. > > Conversely, to avoid that nodes send packets making use of previous > values of contexts, resulting in ambiguity when receiving a packet > that uses a recently changed context, old values of a context SHOULD > be taken out of use for a while before new values are assigned to > this specific context. That is, in preparation for a change of > context information, its dissemination SHOULD continue for at least > MIN_CONTEXT_CHANGE_DELAY with C=1 and V=0. Only when it is > reasonable to assume that the fact that the context is now invalid > was successfully disseminated, should the context ID be taken out of > dissemination or reused with a different Information field. In the > latter case, dissemination of the new value again SHOULD start with > C=1 and V=0, as above. > > The 6LoWPAN Summary Option is used to support information > dissemination from one or more Edge Routers to all other nodes in the > LoWPAN. The option includes a "V" flag which indicates that the > information contained in the Router Advertisement is valid. The > option also includes a sequence number to ensure that all nodes > converge on the same settings. The sequence number is incremented by > > > > Shelby, et al. Expires August 5, 2010 [Page 29] > > <#page-30> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > the originating Edge Router each time the set of prefix information > changes. > > As the number of prefixes or addresses included for context > compression in an RA may be large (up to 16), it is beneficial to > avoid the need to always include all options in every RA. Therefore > routers SHOULD only include the 6LoWPAN Summary Option in unsolicited > RAs, unless a set of prefix information with a new sequence number is > being disseminated. In the case of a new sequence number, the router > SHOULD include all 6LoWPAN Information Options in the RA. A node may > use an RS with Code set to 1 in order to get the whole prefix > information set in case it misses the RA sent when the sequence > number changes. An RS with Code set to 0 is responded to with an RA > with the 6SO. > > > 6. Node Specification > > This section specifies the conceptual data structures and variables > of a LoWPAN Node. > > 6.1. Conceptual structures > > Nodes make use of the following conceptual data structures: > > Prefix List - The list of prefixes which are advertised in Router > Advertisements, along with an associated invalidation timer. Each > entry is associated with the sequence number last advertised in > the 6LoWPAN Summary Option. Unlike in [RFC4861 <./rfc4861>], these prefixes > are always assumed to be off-link. > > Context List - The list of contexts and their associated CID which > are advertised in Router Advertisements, along with an associated > invalidation timer. Each entry is associated with the sequence > number last advertised in the 6LoWPAN Summary Option. This list > may be realized together with the Prefix List. > > Default Router List - As in [RFC4861 <./rfc4861>]. For networks where address > resolution needs to be performed, this list also contains link- > layer information about each router. > > These conceptual data structures may be realized in many ways. As > nodes have very limited memory the number of cache entries > should be limited, duplicate entries between caches referenced, and > full IPv6 addresses represented in a compressed format where > possible. > > > > > > Shelby, et al. Expires August 5, 2010 [Page 30] > > <#page-31> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 6.2. Conceptual variables > > The following variables are kept for each interface on a node, and > default values are overridden by information in Router > Advertisements: > > CurHopLimit The default hop limit to be used when sending IP > packets. > > CurTID The current Transaction ID (TID) value for use in > NR messages. > > BindingLifetime The binding lifetime sent in Node Registration > messages. > > RegistrationTimeout The time to wait for a Node Confirmation after > sending a Node Registration. SHOULD be at least > MIN_NR_TIMEOUT. > > RegistrationRetries <#> The number of times to try to send a Node > Registration, which SHOULD be less than > MAX_NR_RETRIES. > > > 7. Router Specification > > Routers are used in a route-over configuration where the > network is composed of overlapping link-local scopes. Edge > Routers implement router functionality. As a result, we > extend classic ND as specified in [RFC4861 <./rfc4861>] to operate over such non- > transitive LoWPAN links. This section describes ND for > router operations in a LoWPAN. Note that this section does not entirely apply to > pure Mesh Under LoWPANs where the are no routers, although > they do have Edge Routers. > > 7.1. Router Configuration Variables > > A router MUST allow the configuration of conceptual variables as > defined in Section 6.2.1 of [RFC4861] <./rfc4861#section-6.2.1>. AdvReachableTime and > AdvRetransTimer are not used. > > 7.2. Becoming an Advertising Interface > > An interface may become an advertising interface as specified in > Section 6.2.2 of [RFC4861] <./rfc4861#section-6.2.2>. > > A router's interface MAY become an advertising interface > before all of its router variables have been initialized. The router > > > > Shelby, et al. Expires August 5, 2010 [Page 31] > > <#page-32> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > MUST learn these variables (e.g. AdvCurHopLimit, prefix and context > information, etc.) from neighboring routers. While the variables are > not initialized, the router MAY send Router Advertisement with the > "Solicit" flag set to solicit Router Advertisements from neighboring > routers. However, the router MUST set the Router Lifetime field to > zero while one or more of its variables are uninitialized. > > 7.3. Router Advertisement Message Content > > A router sends periodic as well as solicited Router Advertisements > out its advertising interface. Outgoing Router Advertisements are > filled with the following values consistent with the message format > given in this document. > > - In the Router Lifetime field: if the router has a default route, > the interface's configured AdvDefaultLifetime. If the router does > not have a default route, zero. > > - In the M and O flags: the current value of AdvManagedFlag and > AdvOtherConfigFlag, respectively. > > - In the Preference flag: this flag is set to 00 to indicate that > the sender is a router <#>. > > - In the Cur Hop Limit field: the current value of CurHopLimit. > > - In the Reachable Time field: not used, set to zero. > > - In the Retrans Timer field: not used, set to zero. > > - In the options: > > - 6LoWPAN Summary Option: to indicate if the information > contained in the Router Advertisement is valid and, if so, the > freshness of the information contained in the Router > Advertisement message. The option fields are set as follows: > > - In the "valid" flag: the current value of > AdvInformationValid. > > - In the Sequence Number field: the current value of > AdvInformationSequence. > > - The ER Metric field is used by a routing algorithm to > indicate the cost of reaching an Edge Router through this > router. > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 32] > > <#page-33> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > - 6LoWPAN Information options: one 6LoWPAN Information option > for each prefix listed in AdvPrefixList with the option fields > set from the information in the AdvPrefxList entry as follows: > > - In the "on-link" flag: the entry's AdvOnLinkFlag. > > - In the "Autonomous address configuration" flag: the > entry's AdvAutonomousFlag. > > - In the Valid Lifetime field: the entry's AdvValidLifetime. > > 7.4. Sending Unsolicited Router Advertisements > > As specified in Section 6.2.4 of [RFC4861] <./rfc4861#section-6.2.4>. > > 7.5. Ceasing To Be an Advertising Interface > > As specified in Section 6.2.5 of [RFC4861] <./rfc4861#section-6.2.5>. > > 7.6. Processing Router Solicitations > > As specified in Section 6.2.6 of [RFC4861] <./rfc4861#section-6.2.6>. > > 7.7. Binding Table > > Routers maintain an set of information about nodes that are currently > registered through it called the binding table. > > The binding table contains an entry with information such as the > registered node's OII, link-local IPv6 address and the binding > lifetime from the last NR. If address resolution is required, the > table will also include corresponding link-layer address information. > > > 8. Ad-hoc LoWPAN > > LoWPAN networks by nature may often work in an ad-hoc fashion, > without an infrastructure or connectivity to the global Internet. > 6LoWPAN-ND may still be applied in such networks. > > A specific router in the Ad-hoc LoWPAN is nominated as Edge Router > and <#> configured to implement basic Edge Router functionality > (initiating RA dissemination) and generates a prefix based on Unique > on-link IPv6 Unicast Addresses (ULAs) as defined in [RFC4193 <./rfc4193>]. A > ULA is made up of the prefix fc00::/7, a global ID and a subnet ID. > The global ID is randomly generated, and the subnet ID is not used. > The Edge Router is responsible for the generation of the ULA prefix > to be advertised to the LoWPAN and used by all nodes. ULA generation > may use the algorithm suggested Section > > > > Shelby, et al. Expires August 5, 2010 [Page 33] > > <#page-34> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 3.2.2 of [RFC4193 <./rfc4193>] or something appropriate to the Edge Router's > capabilities. There SHOULD be only one Edge Router in an Ad-hoc > LoWPAN (just as in a Simple LoWPAN) to keep prefix consistency. > > In the case that an Edge Router on a Simple LoWPAN does not have a > prefix available from its IPv6 address, it SHOULD advertise a ULA > prefix in a similar manner. > > > 9. Protocol Constants > > This section defines the protocol constants used in this document > based on a subset of [RFC4861 <./rfc4861>] constants. (*) indicates constants > modified from [RFC4861 <./rfc4861>] and (+) indicates new constants. > > Additional protocol constants are defined in Section Section 4 <#section-4>. > > Edge Router Constants: > > MIN_CONTEXT_CHANGE_DELAY+ 60 seconds > > Router Constants: > > MAX_INITIAL_RTR_ADVERT_INTERVAL* 60 seconds > > MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions > > MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions > > MIN_DELAY_BETWEEN_RAS* 10 seconds > > MAX_RA_DELAY_TIME* 2 seconds > > Host Constants: > > MAX_RTR_SOLICITATION_DELAY* 2 second > > RTR_SOLICITATION_INTERVAL* 10 seconds > > MAX_RTR_SOLICITATIONS 3 transmissions > > Node Constants: > > MAX_NR_RETRIES+ 3 transmissions > > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 34] > > <#page-35> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > MIN_NR_TIMEOUT+ 5 seconds > > > 10. Use of 6LoWPAN-ND under RFC4861 <./rfc4861>-only stacks > > Some IPv6 stacks (e.g. on PCs) and tools (e.g. radvd) hard-wire the > mechanisms of RFC4861 <./rfc4861> for all links. This section explains the > adaptation needed in order to use a 6LoWPAN interface under such an > RFC4861 <./rfc4861>-only implementation. > > There are several ways to implement 6LoWPAN-ND in combination with an > IPv6 stack: > > o 6LoWPAN-ND is integrated with the IPv6 stack and its tools. This > is common for LoWPAN nodes. > > o 6LoWPAN-ND is implemented as part of the interface, configuration > is used to turn off RFC4861 <./rfc4861> mechanisms in the IPv6 stack. For > example, Proxy-ND interfaces can be used in Linux to disable most > built-in ND mechanisms. This model is common for Edge Routers > running on a standard operating system. > > o 6LoWPAN-ND is implemented as part of the interface, and it > performs adaptation for RFC4861 <./rfc4861> mechanisms running on the IPv6 > stack. The binding table is used to answer RFC4861 <./rfc4861> messages, and > appropriate options added to RA messages. > > Classic RS/RA messages can be used with a LoWPAN, thus allowing e.g. > for an unmodified radvd (with appropriate configuration) to be run on > an Edge Router as long as context dissemination is not needed. It is > however recommended that 6IO and 6SO options be used if possible, > which is easily achieved by patching existing RA tools or performing > adaptation. > > > 11. Message Examples > > This section provides basic examples of messages and options from > this document. > > 11.1. NR/NC message exchange > > When a host wants to register to a router, a simple NR/NC request > message exchange occurs. In this example, a host wants to register > its address generated with Stateless Address Autoconfiguration (SAA) <#>, > and in addition requests a generated short address. > > First the Host sends an NR message to the link-local address of the > > > > Shelby, et al. Expires August 5, 2010 [Page 35] > > <#page-36> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > router. In this example the host includes a 600 second binding > lifetime and its modified EUI-64 as the Owner Interface Identifier. > The message has two Address Options. The host has just booted, > therefore the TID starts with 0. This example assumes that the > LoWPAN prefix has been assigned CID 0. > > IPv6 Source: Unspecified address > IPv6 Destination: Router's link-local address > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD | 0 | 0 | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TID = 0 |1|0| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Binding Lifetime = 60 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Owner Nonce | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Owner Interface Identifier = + > | Modified EUI-64 of the interface | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 9: Basic NR request. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD | Length = 1 | Status = 0 | S=1 | P=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0|0|1| Reserved | Padding = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 10: NR Address Option 1, for the SAA address. > > > > > > > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 36] > > <#page-37> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD | Length = 1 | Status = 0 | S=2 | P=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|1|0|0| Reserved | Padding = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 11: NR Address Option 2, for the requested address. > > > IPv6 Source: Router's link-local address > IPv6 Destination: Host's link-local address > > The base NC message is identical to the base NR message above. > > > Figure 12: Corresponding NC message <#>. > > > > Address Option 1 is identical to Address Option 1 in the NR. > > > Figure 13: NC Address Option 1, for the SAA address. <#> > > > Address Option 2 now includes the generated address. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD | Length = 1 | Status = 0 | S=2 | P=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|1|0|0| Reserved | Generated 16-bit address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 14: NC Address Option 2, for the requested address. > > 11.2. Router advertisement > > Routers and Edge Routers in LoWPAN networks periodically send RA > messages. The following example is of an RA message sent by a > router. If the message is sent by an Edge Router, the only difference > is that the Preference flag is set to 10. > > > > > Shelby, et al. Expires August 5, 2010 [Page 37] > > <#page-38> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > In the example the Preference flag is 01 (router), and a 1200s Router > Lifetime is advertised. A 6LoWPAN Prefix Information Option is > included. > > > IPv6 Source: Router's link-local address > IPv6 Destination: All-nodes multicast address > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 134 | Code = 0 | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Cur Hop Limit |0|0|0|0 0|Rsrvd| Router Lifetime = 1200 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reachable Time = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Retrans Timer = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 15: RA message example. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD | Length = 2 | PL = 64 |0|1|1|1| CID=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Valid Lifetime = 3000 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . Prefix = 2001:DB8::/64 . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 16: 6LoWPAN Information Option example. > > > 12. Security Considerations > > The security considerations of IPv6 Neighbor Discovery [RFC4861 <./rfc4861>] > apply. Additional considerations can be found in [RFC3756 <./rfc3756>]. > > This specification expects that the link layer is sufficiently > protected, either by means of physical or IP security for the > backbone link or MAC sublayer cryptography. In other words, model 1 > from [RFC3756 <./rfc3756>] applies. In particular, it is expected that the > > > > Shelby, et al. Expires August 5, 2010 [Page 38] > > <#page-39> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > LoWPAN MAC provides secure unicast to/from Routers and secure > broadcast from the Routers in a way that prevents tampering with or > replaying the RA messages. However, any future 6LoWPAN security > protocol that applies to Neighbor Discovery for 6LoWPAN protocol, is > out of scope of this document. > > The use of EUI-64 for forming the Interface ID <#> in the link on-link > address prevents the usage of Secure ND ([RFC3971 <./rfc3971>] and [RFC3972 <./rfc3972>]) and > address privacy techniques. Considering the envisioned deployments > and the MAC layer security applied, this is not considered an issue > at this time. > > > 13. IANA Considerations > > This document requires two new ICMPv6 message types: > > o Node Registration (TBD1) > > o Node Confirmation (TBD2) > > The document also requires four new ND option types under the > subregistry "IPv6 Neighbor Discovery Option Formats": > > o 6LoWPAN Address Option (TBD3) > > o 6LoWPAN Information Option (TBD4) > > o 6LoWPAN Summary Option (TBD5) > > o Owner Interface Identifier Option (TBD6) > > [TO BE REMOVED: This registration should take place at the following > location: http://www.iana.org/assignments/icmpv6-parameters] > > > 14. Acknowledgments > > The authors thank Richard Kelsey, Geoff Mulligan, Julien Abeille, > Alexandru Petrescu, Peter Siklosi, Pieter De Mil, Fred Baker, Anthony > Schoofs, Phil Roberts and Joakim Eriksson for useful discussions and > comments that have helped shaped and improve this document. > > > 15. Changelog > > Changes from -07 to -08: > > > > > Shelby, et al. Expires August 5, 2010 [Page 39] > > <#page-40> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > o Removed Extended LoWPAN and Whiteboard related sections. > > o Included reference to the autoconf addressing model. > > o Added Optimistic Flag to 6AO. > > o Added guidelines on routers performing DAD. > > o Removed the NR/NC Advertising Interval. > > o Added assumption of uniform IID formation and DAD throughout a > LoWPAN. > > Changes from -06 to -07: > > o Updated addressing and address resolution (#60). > > o Changed the Address Option to 6LoWPAN Address Option, fixed S > values (#61). > > o Added support for classic RFC4861 <./rfc4861> RA Prefix Information messages > to be processed (#62). > > o Added a section on using 6LoWPAN-ND under a hard-wired RFC4861 <./rfc4861> > stack (#63). > > o Updated the NR/NC message with a new Router flag, combined the > Code and Status fields into one byte, and added the capability to > carry 6IOs (#64). > > o Made co-existence with other ND mechanisms clear (#59). > > o Added a new Protocol Specification section with all mechanisms > specified there (#59). > > o Removed dependencies and conflicts with RFC4861 <./rfc4861> wherever > possible (#59). > > o Some editorial cleanup. > > Changes from -05 to -06: > > o Fixed the Prf codes (#52). > > o Corrected the OIIO TID field to 8-bits. Changed the Nonce/OII > order in both the OIIO and the NR/NC. (#53) > > > > > > Shelby, et al. Expires August 5, 2010 [Page 40] > > <#page-41> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > o Corrected an error in Table 1 (#54). > > o Fixed asymmetric and a misplaced transient in the 6LoWPAN > terminology section. > > o Added Updates RFC4861 <./rfc4861> to header > > Changes from -04 to -05: > > o Meaning of the RA's M-bit changed to original [RFC4861 <./rfc4861>] meaning > (#46). > > o Terms "on-link" and "off-link" used in place of "on-link" and > "off-link". > > o Next-hop determination text simplified (#49). > > o Neighbor cache and destination cache removed. > > o IID to link-layer address requirement relaxed. > > o NR/NC changes to enable on-link refresh with routers (#48). > > o Modified 6LoWPAN Information Option (#47). > > o Added a Protocol Constants section (#24) > > o Added the NR processing table (#51) > > o Considered the use of SeND on backbone NS/NA messages (#50) > > Changes from -03 to -04: > > o Moved Ad-hoc LoWPAN operation to Section 7 <#section-7> and made ULA prefix > generation a features useful also in Simple and Extended LoWPANs. > (#41) > > o Added a 32-bit Owner Nonce to the NR/NC messages and the > Whiteboard, removed the TID history. (#39) > > o Improved the duplicate OII detection algorithm using the Owner > Nonce. (#39) > > o Clarified the use of Source and Target link-layer options in > NR/NC. (#43) > > o Included text on the use of alternative methods to acquire > addresses. (#38) > > > > Shelby, et al. Expires August 5, 2010 [Page 41] > > <#page-42> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > o Removed S=2 from Address Option (not needed). (#36) > > o Added a section on router dissemination consistency. (#44) > > o Small improvements and extensive editing. (#42, #37, #35) > > Changes from -02 to -03: > > o Updated terminology, with RFC4861 <./rfc4861> non-transitive link model. > > o 6LoWPAN and ND terminology separated. > > o Protocol overview explains RFC4861 <./rfc4861> diff in detail. > > o RR/RC is now Node Registration/Confirmation (NR/NC). > > o Added NR failure codes. > > o ER Metric now included in 6LoWPAN Summary Option for use in > default router determination by hosts. > > o Examples of host data structures, and the Whiteboard given. > > o Whiteboard is supported by all Edge Routers for option > simplicity. > > o Edge Router Specification chapter re-structured, clarifying > optional Extended LoWPAN operation. > > o NS/NA now completely optional for nodes. No address resolution > or NS/NA NUD required. > > o link-local operation now compatible with oDAD (was broken). > > o Exception to hop limit = 255 for NR/NC messages. > > o Security considerations improved. > > o ICMPv6 destination unreachable supported. > > Changes from -01 to -02: > > o Fixed 16 != 0xff bug (ticket closed). > > o Specified use of ULAs in ad-hoc LoWPAN section 9 <#section-9> (ticket > closed). > > > > > > Shelby, et al. Expires August 5, 2010 [Page 42] > > <#page-43> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > o Terminology cleanup based on Alex's comments. > > o General editing improvements. > > Changes from -00 to -01: > > o Specified the duplicate owner interface identifier procedures. > A TID lollipop algorithm was sufficient (nonce unnecessary). > > o Defined fault tolerance using secondary bindings. > > o Defined ad-hoc network operation. > > o Removed the E flag from RA and the X flag from RR/RC. > > o Completed message examples. > > o Lots of improvements in text quality and consistency were made. > > > 16. References > > 16.1. Normative References > > [I-D.ietf-autoconf-adhoc-addr-model] > Baccelli, E. and M. Townsley, "IP Addressing Model in Ad > Hoc Networks", draft-ietf-autoconf-adhoc-addr-model-02 <./draft-ietf-autoconf-adhoc-addr-model-02> > (work in progress), January 2010. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14 <./bcp14>, RFC 2119 <./rfc2119>, March 1997. > > [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 > over Non-Broadcast Multiple Access (NBMA) networks", > RFC 2491 <./rfc2491>, January 1999. > > [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and > More-Specific Routes", RFC 4191 <./rfc4191>, November 2005. > > [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast > Addresses", RFC 4193 <./rfc4193>, October 2005. > > [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing > Architecture", RFC 4291 <./rfc4291>, February 2006. > > [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) > for IPv6", RFC 4429 <./rfc4429>, April 2006. > > > > > Shelby, et al. Expires August 5, 2010 [Page 43] > > <#page-44> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control > Message Protocol (ICMPv6) for the Internet Protocol > Version 6 (IPv6) Specification", RFC 4443 <./rfc4443>, March 2006. > > [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, > "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861 <./rfc4861>, > September 2007. > > [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless > Address Autoconfiguration", RFC 4862 <./rfc4862>, September 2007. > > [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, > "Transmission of IPv6 Packets over IEEE 802.15.4 > Networks", RFC 4944 <./rfc4944>, September 2007. > > 16.2. Informative References > > [I-D.ietf-6lowpan-hc] > Hui, J. and P. Thubert, "Compression Format for IPv6 > Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-06 <./draft-ietf-6lowpan-hc-06> > (work in progress), October 2009. > > [RFC2022] Armitage, G., "Support for Multicast over UNI 3.0/3.1 > based ATM Networks", RFC 2022 <./rfc2022>, November 1996. > > [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for > Inverse Discovery Specification", RFC 3122 <./rfc3122>, June 2001. > > [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor > Discovery (ND) Trust Models and Threats", RFC 3756 <./rfc3756>, > May 2004. > > [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure > Neighbor Discovery (SEND)", RFC 3971 <./rfc3971>, March 2005. > > [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", > RFC 3972 <./rfc3972>, March 2005. > > [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness > Requirements for Security", BCP 106 <./bcp106>, RFC 4086 <./rfc4086>, June 2005. > > [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903 <./rfc4903>, > June 2007. > > [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 > over Low-Power Wireless Personal Area Networks (6LoWPANs): > Overview, Assumptions, Problem Statement, and Goals", > RFC 4919 <./rfc4919>, August 2007. > > > > Shelby, et al. Expires August 5, 2010 [Page 44] > > <#page-45> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > Authors' Addresses > > Zach Shelby (editor) > Sensinode > Hallituskatu 13-17D > Oulu 90100 > FINLAND > > Phone: +358407796297 > Email: zach@sensinode.com > > > Pascal Thubert > Cisco Systems > Village d'Entreprises Green Side > 400, Avenue de Roumanille > Batiment T3 > Biot - Sophia Antipolis 06410 > FRANCE > > Phone: +33 4 97 23 26 34 > Email: pthubert@cisco.com > > > Jonathan W. Hui > Arch Rock Corporation > 501 2nd St. Ste. 410 > San Francisco, California 94107 > USA > > Phone: +415 692 0828 > Email: jhui@archrock.com > > > Samita Chakrabarti > IP Infusion > 1188 Arquest Street > Sunnyvale, California > USA > > Phone: > Email: samitac@ipinfusion.com > > > > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 45] > > <#page-46> > Internet-Draft 6LoWPAN Neighbor Discovery February 2010 > > > Carsten Bormann > Universitaet Bremen TZI > Postfach 330440 > Bremen D-28359 > Germany > > Phone: +49-421-218-63921 > Fax: +49-421-218-7000 > Email: cabo@tzi.org > > > Erik Nordmark > Sun Microsystems > 17 Network Circle > Menlo Park, California 94025 > USA > > Phone: > Email: Erik.Nordmark@Sun.COM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shelby, et al. Expires August 5, 2010 [Page 46] > > > > > > Html markup produced by rfcmarkup 1.86, available from > http://tools.ietf.org/tools/rfcmarkup/ --------------040803030100040905000609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Zach,

I have been through the document and made some corrections (in yellow) and some comments (in cyan) - see attachment.

The main things I found were:
  • Inconsistent terminology. Bar the actual definitions, the terms, 'host', 'node', 'router' and 'Edge Router' should be used throughout, not a 'LoWPAN' variant of them.
  • Some hangovers re. whiteboard and Extended LoWPAN
  • DAD not covered - as mentioned below
  • Propagation of RS/RA not covered
  • Hints at relaying NR/NC but not covered
  • Assumption that IID will use EUI-64 whereas it could be formed from alternate link-layer address.
Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com



Robert Cragie wrote:
Hi Zach,

I have been through the document and made some corrections (in yellow) and some comments (in cyan) - see attachment.

The main things I found were:
  • Inconsistent terminology. Bar the actual definitions, the terms, 'host', 'node', 'router' and 'Edge Router' should be used throughout, not a 'LoWPAN' variant of them.
  • Some hangovers re. whiteboard and Extended LoWPAN
  • DAD not covered - as mentioned below
  • Propagation of RS/RA not covered
  • Hints at relaying NS/NC but not covered
  • Assumption that IID will use EUI-64 whereas it could be formed from alternate link-layer address.
Robert 

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com



Zach Shelby wrote: 
Hi everyone,

Thanks to an active discussion among the ND authors, and a bunch of helpful reviews (thanks Richard, Anders and Colin), I finally managed to post 6lowpan-nd-08, in its new slim form (think biggest loser). After Hiroshima we reached good WG consensus to split the ND work into the basic mechanism (which is now this document) and a separate Extended LoWPAN draft (to be started), furthermore we agreed to deal with the DAD issue. This document hopefully moves us very close to that goal. This also includes the new RS feature suggested by Anders.

http://www.ietf.org/id/draft-ietf-6lowpan-nd-08.txt

As always with major changes (this needed lots of hacking and major editing), there are surely tons of bugs and loose-ends left. Help to find those appreciated.

   Changes from -07 to -08:

      o Removed Extended LoWPAN and Whiteboard related sections.

      o Included reference to the autoconf addressing model.

      o Added Optimistic Flag to 6AO.

      o Added guidelines on routers performing DAD.

      o Removed the NR/NC Advertising Interval.

      o Added assumption of uniform IID formation and DAD throughout a
      LoWPAN.

The major open issue we have is how to develop the DAD text in Section 5.3 in such a way that it works for most people, yet produces reliable and safe LoWPANs, and is yet acceptable to the IPv6 crowd and especially the IESG ;-) We are trying to find a balance to keep the WG happy, yet having a chance to actually become an RFC.... 

It would also be nice to reduce the complexity of NR/NC and especially 6AO message processing. Writing the spec, I am at least not totally happy with the amount of explaining needed.... Is there a sleeker way to deal with the addresses?

Zach

Begin forwarded message:

  
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Date: February 1, 2010 23:59:40 GMT+02:00
To: zach@sensinode.com
Cc: pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,cabo@tzi.org,Erik.Nordmark@Sun.COM
Subject: New Version Notification for draft-ietf-6lowpan-nd-08 


A new version of I-D, draft-ietf-6lowpan-nd-08.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository.

Filename:	 draft-ietf-6lowpan-nd
Revision:	 08
Title:		 6LoWPAN Neighbor Discovery
Creation_date:	 2010-02-01
WG ID:		 6lowpan
Number_of_pages: 46

Abstract:
This document specifies a new Neighbor Discovery mechanism suitable
for LoWPANs.  The 6LoWPAN format allows IPv6 to be used over energy
and bandwidth constrained wireless networks often making use of
multihop topologies.  However, the use of classic IPv6 Neighbor
Discovery with 6LoWPAN has several problems.  Classic Neighbor
Discovery was not designed for non-transitive wireless links, and the
traditional IPv6 link concept and heavy use of multicast makes it
unpractical.  This document specifies a simple Neighbor Discovery
mechanism both sufficient yet minimal for LoWPAN operation.



The IETF Secretariat.


draft-ietf-6lowpan-nd-08 - 6LoWPAN Neighbor Discovery
[Docs] [txt] [pdf] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-hui-6lowpan-nd) 00 01 02 03
04 05 06 07 08 

 
6lowpan Working Group                                     Z. Shelby, Ed.
Internet-Draft                                                 Sensinode
Updates: 4944 (if approved)                                   P. Thubert
Intended status: Standards Track                                   Cisco
Expires: August 5, 2010                                           J. Hui
                                                               Arch Rock
                                                          S. Chakrabarti
                                                             IP Infusion
                                                              C. Bormann
                                                 Universitaet Bremen TZI
                                                             E. Nordmark
                                                                     Sun
                                                        February 1, 2010
 
 
                       6LoWPAN Neighbor Discovery
                        draft-ietf-6lowpan-nd-08 
 
Abstract
 
   This document specifies a new Neighbor Discovery mechanism suitable
   for LoWPANs.  The 6LoWPAN format allows IPv6 to be used over energy
   and bandwidth constrained wireless networks often making use of
   multihop topologies.  However, the use of classic IPv6 Neighbor
   Discovery with 6LoWPAN has several problems.  Classic Neighbor
   Discovery was not designed for non-transitive wireless links, and the
   traditional IPv6 link concept and heavy use of multicast makes it
   unpractical.  This document specifies a simple Neighbor Discovery
   mechanism both sufficient yet minimal for LoWPAN operation.
 
Status of this Memo
 
   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.
 
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
 
   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
 
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
 
 
 
 
Shelby, et al.           Expires August 5, 2010                 [Page 1] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
 
   This Internet-Draft will expire on August 5, 2010.
 
Copyright Notice
 
   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.
 
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                 [Page 2] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
Table of Contents
 
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4 
     1.1.  Goals, Assumptions, and Guesses  . . . . . . . . . . . . .  5 
     1.2.  Why not classic IPv6 ND? . . . . . . . . . . . . . . . . .  5 
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6 
     2.1.  6LoWPAN Terminology  . . . . . . . . . . . . . . . . . . .  7 
     2.2.  ND Terminology . . . . . . . . . . . . . . . . . . . . . .  9 
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . . 10 
     3.1.  Topology . . . . . . . . . . . . . . . . . . . . . . . . . 11 
     3.2.  Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . 12 
     3.3.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . 13 
   4.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 13 
     4.1.  Node Registration/Confirmation Message . . . . . . . . . . 14 
     4.2.  Router Solicitation Message  . . . . . . . . . . . . . . . 16 
     4.3.  Router Advertisement Message . . . . . . . . . . . . . . . 17 
     4.4.  Message Options  . . . . . . . . . . . . . . . . . . . . . 18 
       4.4.1.  6LoWPAN Address Option . . . . . . . . . . . . . . . . 18 
       4.4.2.  6LoWPAN Information Option . . . . . . . . . . . . . . 19 
       4.4.3.  6LoWPAN Summary Option . . . . . . . . . . . . . . . . 21 
       4.4.4.  Owner Interface Identifier Option  . . . . . . . . . . 22 
   5.  Protocol Specification . . . . . . . . . . . . . . . . . . . . 23 
     5.1.  Interface initialization . . . . . . . . . . . . . . . . . 23 
     5.2.  Node Registration  . . . . . . . . . . . . . . . . . . . . 24 
       5.2.1.  Processing a Node Registration Message . . . . . . . . 25 
       5.2.2.  Processing a Node Confirmation Message . . . . . . . . 25 
     5.3.  Duplicate Address Detection  . . . . . . . . . . . . . . . 26 
     5.4.  Next-hop Determination . . . . . . . . . . . . . . . . . . 27 
     5.5.  Address Resolution . . . . . . . . . . . . . . . . . . . . 27 
     5.6.  Unreachability Detection . . . . . . . . . . . . . . . . . 28 
     5.7.  Context Dissemination  . . . . . . . . . . . . . . . . . . 28 
   6.  Node Specification  . . . . . . . . . . . . . . . . . . 29 
     6.1.  Conceptual structures  . . . . . . . . . . . . . . . . . . 29 
     6.2.  Conceptual variables . . . . . . . . . . . . . . . . . . . 30 
   7.  Router Specification  . . . . . . . . . . . . . . . . . 30 
     7.1.  Router Configuration Variables . . . . . . . . . . . . . . 30 
     7.2.  Becoming an Advertising Interface  . . . . . . . . . . . . 30 
     7.3.  Router Advertisement Message Content . . . . . . . . . . . 31 
     7.4.  Sending Unsolicited Router Advertisements  . . . . . . . . 32 
     7.5.  Ceasing To Be an Advertising Interface . . . . . . . . . . 32 
     7.6.  Processing Router Solicitations  . . . . . . . . . . . . . 32 
     7.7.  Binding Table  . . . . . . . . . . . . . . . . . . . . . . 32 
   8.  Ad-hoc LoWPAN  . . . . . . . . . . . . . . . . . . . . . . . . 32 
   9.  Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 33 
   10. Use of 6LoWPAN-ND under RFC4861-only stacks  . . . . . . . . . 34 
   11. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 34 
     11.1. NR/NC message exchange . . . . . . . . . . . . . . . . . . 34 
     11.2. Router advertisement . . . . . . . . . . . . . . . . . . . 36 
 
 
 
Shelby, et al.           Expires August 5, 2010                 [Page 3] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 37 
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38 
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 38 
   15. Changelog  . . . . . . . . . . . . . . . . . . . . . . . . . . 38 
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 42 
     16.2. Informative References . . . . . . . . . . . . . . . . . . 43 
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                 [Page 4] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
1.  Introduction 
 
   The IPv6 over IEEE 802.15.4 [RFC4944] document has specified how to
   carry IPv6 packets over IEEE 802.15.4 and similar networks (6LoWPANs
   or LoWPANs for short) with the help of an adaptation header which
   comes before the IP header.  A link in such a 6LoWPAN is
   characterized as lossy, low-power, low bit-rate, short range, with
   many nodes saving energy with long deep sleep periods.  Multicast as
   used in classic IPv6 Neighbor Discovery [RFC4861] is not desirable in
   such a wireless low-power, lossy network.
 
   Moreover, LoWPAN links are asymmetric and non-transient in nature;
   they are not always considered to be in a fixed network nor are they
   bounded by our traditional definition of a wired-link.  A LoWPAN is
   potentially composed of a large amount of overlapping radio ranges,
   eventually federated by a backbone or a backhaul link.  Although a
   given radio range has broadcast capabilities, the aggregation of
   these is a complex Non-Broadcast MultiAccess (NBMA, [RFC2491])
   structure with (generally) no LoWPAN-wide multicast capabilities.
   link-local scope is in reality defined by reachability and radio
   strength.  Thus we can consider a LoWPAN to be made up of links with
   undetermined connectivity properties as defined in
   [I-D.ietf-autoconf-adhoc-addr-model], along with the corresponding
   assumptions defined therein.  The classic IPv6 Neighbor Discovery
   [RFC4861] control messages, the use of multicast and their default
   frequency also attribute to unnecessary waste of energy in LoWPANs.
 
   This specification introduces a new mechanism called Node
   Registration, used to optimize the interface between hosts and
   routers in a LoWPAN.  That registration mechanism provides a service
   somewhat similar to the Multicast Address Resolution Server (MARS)
   [RFC2022] for a limited purpose, and in a much simpler and less
   generic fashion.  The use of Router Advertisements to disseminate
   prefix and header compression context throughout the LoWPAN is also
   specified.  The solution supports the use of both link-layer- or
   LoWPAN-level mesh (Mesh Under) and IP routing (Route Over) solutions
   for multihop forwarding.  This specification is both sufficient and
   required for LoWPAN operation.  The 6LoWPAN-ND mechanism could also
   coexist with [RFC4861], [RFC3122] or other future ND mechanisms
   (although the motivation or detailed specification of such
   coexistence is out of scope for the present document).
 
   The document defines two new ICMPv6 messages: Node Registration and
   Node Confirmation.
 
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                 [Page 5] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
1.1.  Goals, Assumptions, and Guesses 
 
   This document has the following main goals and assumptions, as well
   as two guesses that may or may not be true in a specific LoWPAN but
   still have shaped the optimizations.
 
   Goals:
 
   o  Optimize ND with a mechanism that is minimal yet sufficient for
      LoWPAN operation in both mesh-under and route-over configurations.
 
   o  Minimize signalling by avoiding the use of multicast flooding and
      reducing the frequency of link scope multicast messages inside the
      LoWPANs.
 
   o  Disseminate context information throughout the LoWPAN used by
      [I-D.ietf-6lowpan-hc].
 
   o  Minimize the complexity of nodes.
 
   o  Optimize the interfaces between nodes and their default routers.
 
   Assumptions:
 
   o  A subnet includes all the nodes sharing the same IPv6
      prefix.
 
   o  A single LoWPAN is configured in a homogeneous way, i.e., IIDs are
      formed by nodes in a uniform matter and DAD is performed by
      routers in a uniform way.
 
   o  Link layer technology is e.g.  IEEE 802.15.4 as in [RFC4944], or
      any other link-layer exhibiting non-transitivity or a similar
      topology.
 
1.2.  Why not classic IPv6 ND? 
 
   IPv6 Neighbor Discovery [RFC4861] provides several important
   functions such as Router Discovery, Address Resolution, Duplicate
   Address Detection, Redirect, Prefix and Parameter Discovery.
 
   Following power-on and initialization of the network in IPv6 Ethernet
   networks, a node joins the solicited-node multicast address on the
   interface and then performs duplicate address detection (DAD) for the
   acquired link-local address by sending a solicited-node multicast
   message to the link.  After that it sends multicast messages to the
   all-router address to solicit router advertisements.  Once the host
   receives a valid router advertisement with the "A" flag, it
 
 
 
Shelby, et al.           Expires August 5, 2010                 [Page 6] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   autoconfigures the IPv6 address with the advertised prefix in the
   router advertisement (RA).  Besides this, the IPv6 routers usually
   send router advertisements periodically on the network.  RAs are sent
   to the all-node multicast address.  Nodes send Neighbor Solicitation/
   Neighbor Advertisement messages to resolve the IPv6 address of the
   destination on the link.  These NS/NA messages are also often
   multicast messages and it is assumed that the node is on the same
   link and relies on the fact that the destination node is always
   powered and generally reliable.
 
   A LoWPAN network typically uses two types of L2 addresses -- for
   example 16-bit short addresses and 64-bit unique addresses as defined
   in [RFC4944].  Moreover, the available L2 payload size on the order
   of less than 100 bytes where we often might need to use header
   compression and use a minimum payload.  The network is lossy and low-
   powered, and it does not provide multicast capability at the link-
   layer, thus simulating multicast behavior by both using broadcast or
   sending a number of unicast messages, both expensive for the low-
   powered network and the low-processing capable nodes.  Often these
   low-powered nodes conserve energy by using sleep schedules; waking
   them up to receive IPv6 signaling messages such as multicast messages
   for NS or periodic RAs is not practical.  Also they are not capable
   of processing address-resolution for their neighbors effectively.
   Due to the radio strength of its neighboring router or its own
   strength, a node may often move from one router to another without
   physically moving from one place to another.  Considering the above
   characteristics in a LoWPAN, and the IPv6 Neighbor Discovery
   [RFC4861] base protocol requirements, it was concluded that classic
   Neighbor Discovery is not suitable as it is and a 6LoWPAN-specific ND
   definition would be useful and efficient for the wide deployment of
   IPv6 over low-powered wireless networks of embedded devices.
 
 
2.  Terminology 
 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].
 
   This specification requires readers to be familiar with all the terms
   and concepts that are discussed in "IPv6 Stateless Address
   Autoconfiguration" [RFC4862], "IPv6 over Low-Power Wireless Personal
   Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement,
   and Goals" [RFC4919], "Transmission of IPv6 Packets over IEEE
   802.15.4 Networks" [RFC4944] and "IP Addressing Model in Ad Hoc
   Networks" [I-D.ietf-autoconf-adhoc-addr-model].
 
   Readers would benefit from reading "Optimistic Duplicate Address
 
 
 
Shelby, et al.           Expires August 5, 2010                 [Page 7] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   Detection" [RFC4429] ("oDAD") prior to this specification.
 
   This specification makes extensive use of the same terminology
   defined in [RFC4861] unless otherwise redefined below.
 
2.1.  6LoWPAN Terminology 
 
   This section defines additional general terms related to the 6LoWPAN
   architecture used in this specification:
 
   IP Routing
 
      The forwarding of datagrams at the IP layer between arbitrary
      source-destination pairs, during which the IPv6 hop limit is
      decremented.  In the LoWPAN context, IP routing is performed by
      routers on a single interface within the same subnet.
      Exact match search is performed on the destination address of the
      IP packet to find the next-hop to the destination.  Referred to as
      routing in this document.
 
   Link
 
      The link is a communication facility or medium over which nodes
      can communicate at the link-layer, i.e., the layer directly below
      IP ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy
      wireless links such as IEEE 802.15.4, which is a special type of
      link as described in [RFC4861] exhibiting severe asymmetric
      reachability with both asymmetric (A can reach B, but B can't
      reach A) and non-transitive (A can reach B, and B can reach C, but
      A can't reach C) qualities.  The use of link-layer mesh technology
      (see Mesh Under) emulates transitivity across the link but still
      has problems with asymmetricity.  Multicast on a link-layer mesh,
      if available, is often implemented as an expensive broadcast
      flood.  Due to their nature, these are considered links with
      undetermined connectivity properties as defined in
      [I-D.ietf-autoconf-adhoc-addr-model].
 
   Link-local
 
      Standard IPv6 link-local scope is defined in [RFC4291] and
      [RFC4861].  Link-local scope is achieved by setting the hop limit
      to 1, using a link-local prefix (FE80::) or link-local multicast
      scope (FFx2::).  If a link is non-transitive then link-local scope
      may include only a subset of nodes on the link (the set of nodes
      within symmetric radio range of a node).  Nodes in the link-local
      scope of a node are its neighbors, and this link-local scope may
      differ from the perspective of each node.  Therefore, link-local
      addresses are of limited value as discussed in
 
 
 
Shelby, et al.           Expires August 5, 2010                 [Page 8] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
      [I-D.ietf-autoconf-adhoc-addr-model].
 
   LoWPAN Host
 
      A node that only sources or sinks IPv6 datagrams.  Referred to as
      a host in this document.
 
   LoWPAN Node
 
      A node that composes a LoWPAN, referring to both hosts and
      routers.  Simply called a node in this document.
 
   LoWPAN Router
 
      A LoWPAN node that forwards datagrams between arbitrary source-
      destination pairs using a single 6LoWPAN interface performing IP
      routing on that interface.  Referred to as a router in this document.
 
   LoWPAN Mesh node
 
      A LoWPAN node that forwards data between arbitrary source-
      destination pairs using link addresses (and thus only exists in
      Mesh Under LoWPANs).
 
   Mesh Under
 
      A term referring to a configuration where the link-local scope is
      defined by the boundaries of the LoWPAN (or a sizable part of it,
      if Mesh Under is combined with Route Over) and includes all the
      6LoWPAN interfaces within it.  There are forwarding and multihop
      routing functions at L2 to achieve transitivity on the link.  In
      this configuration the link may still exhibit lossy, asymmetric,
      NBMA (non-availability of mesh-wide multicast) behavior.
 
   Route Over
 
      A term referring to a configuration where the LoWPAN is made up of
      several partially overlapping links and link-local scope reaches
      only a subset of the nodes.  IP routing is performed by
      routers to provide connectivity across the LoWPAN.  A
      LoWPAN with this configuration may consist of both routers and
      hosts.  Route Over and Mesh Under are not mutually exclusive, and
      IP routing may be used between links that perform Mesh Under.
 
   Subnet
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                 [Page 9] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
      A subnet is the collection of interfaces having the same IPv6
      subnet prefix on a link, as defined in [RFC4291].  A LoWPAN is
      made up of the interfaces of nodes and Edge Routers sharing
      the same subnet prefix.  This Route Over configuration exhibits a
      multi-hop subnet feature with regard to hop limit as discussed in
      [RFC4903], and thus 6LoWPAN applications should be careful when
      making assumptions about the hop limit as it may be decremented in
      a LoWPAN.
 
2.2.  ND Terminology 
 
   This section defines Neighbor Discovery specific terminology used in
   this specification:
 
   Simple LoWPAN
 
      A Simple LoWPAN consists of a single Edge Router and the set of
      nodes on the same LoWPAN Subnet, shown in Figure 1.
 
   Ad-hoc LoWPAN
 
      An isolated LoWPAN, not connected to any other IP networks.  Ad-
      Hoc LoWPANs make use of Unique on-link IPv6 Unicast Addresses
      (ULAs) [RFC4193].
 
   Backbone Link
 
      This is an IPv6 link that interconnects two or more Edge Routers
      in an Extended LoWPAN topology.  It is expected to be deployed as
      a high speed backbone in order to federate a potentially large set
      of LoWPANs.
 
   LoWPAN Edge Router
 
      An IPv6 router that interconnects the LoWPAN to another IP
      network.  Referred to as an Edge Router in this document.
 
   Registration
 
      The process during which a LoWPAN node sends a Node Registration
      message to a router creating a binding for the node.
 
 
 
 
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 10] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
          Infrastructure Cloud
                   |
                   |
                   |
                +-----+
                |     | Edge
                |     | Router
                +-----+
                  o  o
               o   o    o
             o  o   o  o o        o: Node
              o   o  o  o
                o   o o
 
             Simple LoWPAN
 
 
                    Figure 1: A simple LoWPAN topology
 
 
3.  Protocol Overview 
 
   6LoWPAN Neighbor Discovery (6LoWPAN-ND) optimizes IPv6 ND with a
   mechanism which is on its own minimal yet sufficient for LoWPAN IPv6
   operation. 6LoWPAN-ND defines a node registration mechanism
   optimizing the node-router interface.  This mechanism requires no
   flooding and reduces link-local multicast frequency. 6LoWPAN-ND
   supports non-transitive links, the use of both mesh-under and route-
   over techniques and makes no assumptions about synchronization
   between hosts using the same router.  This specification is REQUIRED
   for LoWPAN operation, but MAY also coexist with [RFC4861], [RFC3122]
   or other future ND mechanisms.  Any use of [RFC4944] without this
   specification is NOT RECOMMENDED.
 
   The following features are defined by 6LoWPAN-ND (see Section
   Section 5 for details):
 
   Node Registration:  Method in which nodes in the LoWPAN register with
      routers, creating state about nodes attached to that router
      (binding table).
 
   Next-hop Determination:  The specification defines a simple next-hop
      determination rule.
 
   Address Resolution:  The Node Registration mechanism provides
      sufficient a priori state in nodes and routers to resolve an IPv6
      address to its associated link-layer address on the node-router
      interface.  Host-host resolution is out of scope of this
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 11] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
      specification.
 
   Unreachability Detection:  Unreachability between a node and router
      is determined based on link-layer acknowledgements to node
      registration and unicast data messages.  Host-host unreachability
      detection is out of scope.  Destination unreachability detection
      is performed using ICMPv6 destination unreachable messages.
 
   Context Dissemination:  The dissemination of LoWPAN context as used
      by [I-D.ietf-6lowpan-hc] is defined as an ICMPv6 option, along
      with an associated summary option to reduce message size when many
      contexts are advertised.
 
   This specification makes use of RS/RA message exchanges similar to
   classic ND, which in 6LoWPAN-ND may also carry additional options for
   context dissemination (6LoWPAN Information Option, 6IO) and reducing
   RA message size (6LoWPAN Summary Option, 6SO).  In addition
   6LoWPAN-ND defines two new ICMP packet types:
 
   Node Registration (NR):  Sent by a node to a router to register a
      binding.
 
   Node Confirmation (NC):  The response sent by a router back to the
      registering node.
 
3.1.  Topology 
 
   6LoWPAN-ND makes little assumption about synchronization between
   nodes in a LoWPAN except between a node and the routers it has
   registered with. 6LoWPAN-ND is designed to work also with Ad-hoc
   topologies.  The case of Ad-hoc LoWPAN operation is described in
   Section 8.
 
   6LoWPAN-ND is compatible with the use of link-layer mesh or [RFC4944]
   mesh techniques, which alleviate the otherwise non-transitive nature
   of wireless links.  If used throughout the LoWPAN, this so-called
   Mesh Under topology thus makes the entire link appear to the IP layer
   as having a link-local scope covering all the 6LoWPAN interfaces in
   the LoWPAN.  This kind of LoWPAN is made up of hosts and Edge
   Routers.  This link still exhibits lossy, low-rate, asymmetric
   behavior along with sleep cycles.  The non-transitive nature of the
   link can also be overcome using IP routing within the LoWPAN, also
   called a Route Over topology.  Routers are used in the LoWPAN
   to provide routing between all nodes in the LoWPAN.  Router
   operations are specified in Section 7. Link-local scope includes the
   neighbors of each node within symmetric wireless range.  Mesh Under
   and Route Over techniques are not mutually exclusive, and it may be
   possible to combine IP routing and mesh link-layers within a LoWPAN.
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 12] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
3.2.  Bootstrapping 
 
   1.  A node (host or router) first forms an Interface Identifier (IID)
   from its EUI-64 or other appropriate MAC address, and goes on to form
   a link-local unicast address as in [RFC4944].  When a node
   wants to join a LoWPAN, it does so by listening for Router
   Advertisements, or by broadcasting a Router Solicitation (RS) and
   receiving RA responses from on-link routers (see Figure 2).  If a
   valid prefix is advertised in the RA, the host may also autoconfigure
   a global address.  At this point the node has also chosen one or more
   default routers based on RAs.
 
   2.  Next the node will attempt to perform initial Node Registration.
   Registration is always performed with a link-local router by sending
   a unicast Node Registration (NR) message to it.  This message
   exchange is illustrated in Figure 3.  The NR includes the addresses
   the node wants to register, and it is possible to request the router
   to assign an address.
 
   3.  After processing the addresses and performing DAD if necessary,
   the router replies with a Node Confirmation (NC).  This confirmation
   includes the set of addresses now confirmed by this router.  The Host
   is now capable of using the LoWPAN.
 
 
   Node                                                     Router
    |                                                          |
    |       ---------- Router Solicitation -------->           |
    |                                                          |
    |       <-------- Router Advertisement ---------           |
    |                                                          |
 
 
   Figure 2: Basic RS/RA exchange between a node and any on-link router
                      (or Edge Router)
 
 
 
   Node                                                      Router
    |                                                          |
    |       ---------- Node Registration -------->             |
    |                                                          |
    |       <--------- Node Confirmation ---------             |
    |                                                          |
 
 
                 Figure 3: Basic ND registration exchange
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 13] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
3.3.  Operation 
 
   The node may now send packets to any IPv6 address inside or outside
   the LoWPAN.  Next-hop determination assumes destinations are off-link
   (and thus forwarded to a default router) except for link-local scope
   addresses which are always on-link.  The information needed for
   resolving the link-layer address of default routers or registered
   nodes is known a priori as a result of node registration.
 
   The router binding table is soft, and thus must be renewed
   periodically as indicated by the lifetime of the binding.  This is
   achieved by periodically sending a new NR message.  If a host moves,
   or the network topology changes, and the current routers are no
   longer available, the host then starts the registration process with
   another router.  If the host is still in the same LoWPAN (same subnet
   prefix), its IPv6 addresses remain the same.  If the host moves to a
   different LoWPAN (thus with a different subnet prefix), the
   bootstrapping process is initiated again.  See Section 6 for details
   on node operation.
 
   Routers periodically send RAs to their neighbors.  The Edge
   Router initiates the first RAs, and information from these RAs is
   included in the RAs of each further router, causing the information
   to be disseminated throughout the LoWPAN.  RA periods should be
   optimized to reduce signalling.  See Section 7 for detailed router
   operation.
 
 
4.  Message Formats 
 
   This section defines the message and option formats used in this
   document.  The new messages are all ICMPv6 messages.  In addition,
   new options for ICMPv6 messages are defined.
 
   The following new ICMPv6 message types are defined:
 
   o  Node Registration (NR)
 
   o  Node Confirmation (NC)
 
   In addition, the following new ICMPv6 options are defined:
 
   o  6LoWPAN Address Option (6AO)
 
   o  6LoWPAN Information Option (6IO)
 
   o  6LoWPAN Summary Option (6SO)
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 14] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   o  Owner Interface Identifier Option (OIIO)
 
   The following [RFC4861] messages are used as specified in this
   section:
 
   o  Router Solicitation (RS)
 
   o  Router Advertisement (RA)
 
4.1.  Node Registration/Confirmation Message 
 
   The Node Registration (NR) and Node Confirmation (NC) messages are
   used by a node to register with a router.  Any option that is not
   recognized MUST be skipped silently.  The Node Registration message
   is sent by the node to the link-local unicast IPv6 address of
   a on-link router.
 
   When registering for the first time, the node still has
   optimistic addresses therefore the source address
   of the Node Registration must be the IPv6 unspecified address to
   comply with oDAD.  In subsequent registrations, the IPv6 source
   address is then the link-local IPv6 address of the sender.  A
   registration is periodically refreshed by sending a new NR message
   more frequently than the Binding Lifetime indicated by the node
   during registration.
 
   Address Options are included in the NR message for each IPv6 address
   to be registered, and included in the corresponding NC to indicate
   success.
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |Status | Code  |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TID      |P|R|                Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Binding Lifetime       |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Owner Nonce                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  Owner Interface Identifier                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Registration option(s)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+
 
          Figure 4: Node Registration/Confirmation message format
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 15] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   IP Fields:
 
      Source Address:  The IPv6 address of the source.  This address
         MUST be the IPv6 unspecified address for initial registration.
 
      Destination Address:  The link-local unicast IPv6 address of a on-
         link router when sent by a node.
 
      Hop Limit:  255
 
   ICMP Fields:
 
      Type:  TBD1 for Node Registration, TBD2 for Node Confirmation.
 
      Status:  4-bit unsigned integer.  Sent only in NC messages,
         ignored in NR messages.  Values 0-7 are reserved for success
         codes:
 
            0 is unqualified success.
 
         Values 8-15 are reserved for error codes:
 
            8 is send to indicate that the router is saturated and an
            alternative router should be used.
 
      Code:  4-bit unsigned integer.
 
            0 indicates this NR is a request sent directly from the
            originating host, or this NC is a corresponding response.
 
            1 indicates that the NR message has been relayed by a
            router, or that the NC is to be relayed by the router
            indicated as the destination.  (For future use)
 
            2 indicates this NC is a request for the node to re-
            register.
 
            4-15 are reserved for future use.
 
      Checksum:  The ICMP checksum.
 
      TID:  8-bit unsigned integer.  A unique Transaction ID assigned by
         the host and used to match replies.  A lollipop mechanism is
         used to increment the TID upon each new registration.  The TID
         is not incremented upon a on-link refresh.  In a Node
         Confirmation, the TID is that of the corresponding NR.  TID is set
         to 0 upon booting, and is incremented with each NR message.
         After reaching 0xFF, the value loops to 16 (0x10) and is
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 16] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
         incremented from there.  Thus the values between 0-15 MUST only
         used after a boot or reboot.
 
      P: 1-bit Primary flag.  Not yet used by this specification, always
         set to 1.
 
      R: 1-bit Router flag.  Used to indicate the role of node sending
         the NR message.  Set to 0 by hosts and to 1 by routers.
 
      Binding Lifetime:  16-bit unsigned integer.  The amount of time in
         10 second intervals remaining before the binding of this owner
         interface identifier, and all associated address options and
         configuration options, MUST be considered expired.  A value of
         zero indicates that the Binding Cache entries for the
         registered owner interface identifier MUST be deleted.  A value
         of 0xFFFF indicates an idefinite lifetime.  (The 16-bit field
         covers up to slightly more than a week of Binding Lifetime.)
 
      Reserved:  This field is unused.  It MUST be initialized to zero
         by the sender and MUST be ignored by the receiver.
 
      Owner Interface Identifier (OII):  A globally unique identifier
         for the requesting host's interface.  Typically the EUI-64
         derived IID.
 
      Owner Nonce:  A 32-bit Nonce generated randomly by the node upon
         booting, and generated again each time the node re-boots.  This
         Nonce may be used to detect duplicate OIIs.
 
   Possible Options:
 
      6LoWPAN Address Option(s):  An Address Option is included for each
         address the host wants to bind for this interface.
 
      6LoWPAN Information Option:  This option includes information
         about the prefixes of the LoWPAN along with other context
         information.  Although normally carried in RA messages, a 6IO
         option MAY also be carried in NC messages.
 
      Future versions of this protocol may define new option types.
      Receivers MUST silently ignore any options they do not recognize
      and continue processing the message.
 
4.2.  Router Solicitation Message 
 
   The RS message format for 6LoWPAN is identical to the classic
   [RFC4861] RS message.  The following clarifications are made
   regarding the use of RS in LoWPANs.
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 17] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   If a node has only optimistic addresses not yet confirmed by a
   Router, then the IPv6 source address in the RS MUST be the IPv6
   unspecified address.  The Source Link-Layer Address Option MUST NOT
   be included in the RS at any time.  Instead the Owner Interface
   Identifier specified in this document MUST be included in the RS.
 
   The Code field of the Router Solicitation message is used to
   indicate whether a node wants to receive the full set of 6IOs in the
   RA response, or just the 6SO.  An RS with Code = 0 is used to request
   just the 6LoWPAN Summary Option, and Code = 1 is used to request the
   full set of 6IOs.
 
4.3.  Router Advertisement Message 
 
   The RA message format for 6LoWPAN is identical to the classic
   [RFC4861] RA message.  The use of flags is however defined in the
   6LoWPAN context, and additional new options are identified.  RA
   messages are sent either to link-local all-nodes multicast, or to a
   link-local unicast address as a response to an RS.
 
   Updated Flag Definitions:
 
      Prf:  2-bit signed integer.  Default Router Preference as defined
         in [RFC4191].  Indicates whether to prefer this router over
         other default routers.  Routers with no Edge Router available
         MUST set Prf to (11) for low preference, routers with Edge Router
         availability MUST set Prf to (00) for normal preference, and
         Edge Routers MUST set Prf to (01) for high preference.
 
   Options:
 
      6LoWPAN Information Option:  This option includes information
         about the prefixes of the LoWPAN along with other context
         information.
 
      6LoWPAN Summary Option:  This option provides a sequence number
         associated with the current prefix options.  It allows the
         prefix options themselves to be sent only when a change has
         occured, or when requested with an RS Code = 1.
 
      Prefix Information Option:  If needed for backward compatibility,
         an RA may also be sent using the classic [RFC4861] Prefix
         Information Option which all LoWPAN nodes MUST be able to
         parse.  If possible, routers in the LoWPAN SHOULD make use of
         6IO and 6SO options instead of PIO.
 
      The MTU and SLLAO options defined in [RFC4861] are not used by
      this specification.
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 18] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
      Future versions of this protocol may define new option types.
      Receivers MUST silently ignore any options they do not recognize
      and continue processing the message.
 
4.4.  Message Options 
 
   This section defines the new 6LoWPAN-ND message options.
 
4.4.1.  6LoWPAN Address Option 
 
   The 6LoWPAN Address Option (6AO) is used to indicate the address
   which a node wants to register, and to indicate the success or
   failure of that binding in an NC.  Multiple Address Options can be
   included in a message.  In order to be as compact as possible, fields
   are used to indicate the compression of the IPv6 address.  The 6AO
   also allows for duplicate addresses (e.g. anycasts), the request of a
   generated address for claim and defend use, or for an address to be
   removed.
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Status     |  S  |    P    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |D|A|R|O|      Reserved         |         IPv6 Address        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
                  Figure 5: 6LoWPAN Address Option format
 
   Type:  TBD3
 
   Length:  8-bit unsigned integer.  The length of the option (including
      the type and length fields) in units of 8 octets.
 
   Status:  8-bit unsigned integer. 0 means unqualified success.  Any
      value below 128 is a positive status that means that the binding
      for this address was created or is being created optimistically.
      Only used in a confirmation.
 
   D: 1-bit Duplicate flag.  When set, indicates that duplicates are
      allowed for this address (to support anycast) in a request.
 
   A: 1-bit Address Generation flag.  Set to indicate that the host is
      requesting a generated address for claim and defend addressing.
      In a request when A is set the IPv6 address length is 0.  Set to
      indicate that an address has been assigned in a confirmation.  P
      and S are set to indicate the type of address requested and
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 19] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
      assigned when A is set.  Otherwise must be 0.
 
   R: 1-bit Removal flag.  When set, indicates that this particular
      address binding MUST be removed from a whiteboard (in a request)
      or MUST not be used any longer (in a confirmation).
 
   O: 1-bit Optimistic flag.  When set, indicates that this particular
      address is optimistic and has not yet been checked for duplicates.
 
   P: 5-bit unsigned integer.  Identifies prefix compression or type, if
      any.
 
      0-15:  Prefix compressed; upon decompression, the prefix given by
         the compression context with the same numerical CID as the P
         field given is inserted.
 
      16:  Prefix is carried inline.
 
      17:  Prefix compressed; upon decompression, the link-local prefix
         (fe80::) is inserted.
 
      18-31:  Reserved.
 
   S: 3-bit unsigned integer.  Identifies suffix compression or type, if
      any.
 
      0: Suffix carried inline.
 
      1: Suffix compressed and assumes the same value as the Owner
         Interface Identifier field in the NR/NC message header.
 
      2: Suffix compressed for an IID formed from an IEEE 802.15.4 16-
         bit short addresses.  Only the 16-bit short-address is carried
         in-line.  The IID is formed from this address as specified in
         [RFC4944].
 
      3-7:  Reserved.
 
   IPv6 Address:  The IPv6 address to be registered with the router, or
      confirmed by the router.  Parts of the address may be elided as per
      the P and S fields.
 
4.4.2.  6LoWPAN Information Option 
 
   This option carries prefix information for LoWPANs, and is similar in
   use to the Prefix Information Option of [RFC4861].  However this
   option allows for the dissemination of multiple contexts identified
   by a Context Identifier (CID) for use in 6LoWPAN address compression.
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 20] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |  Info Length  |L|A|C|V|  CID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Valid Lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                 Prefix or Address Information                 .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                Figure 6: 6LoWPAN Information Option format
 
   Type:  TBD4
 
   Length:  8-bit unsigned integer.  The length of the option (including
      the type and length fields) in units of 8 octets.  May be 1, 2 or
      3 depending on the length of the Information field.
 
   Info Length:  8-bit unsigned integer.  The number of leading bits in
      the Information field that are valid.  The value ranges from 0 to
      128.  The info length field provides necessary information for on-
      link determination (when combined with the L flag in the prefix
      information option).  It also assists with address
      autoconfiguration as specified in [RFC4862], for which there may
      be more restrictions on the info length.
 
   L: 1-bit on-link flag, similar to the L flag in [RFC4861].  This flag
      MUST be unset for Route Over LoWPANs and Extended LoWPANs, and MAY
      be set for Mesh Under Simple LoWPANs.
 
   A: 1-bit autonomous address-configuration flag.  When set indicates
      that this prefix can be used for stateless address configuration
      as specified in [RFC4861].
 
   C: 1-bit context flag.  This flag indicates that this information
      option also serves as a context on the LoWPAN, which is identified
      by the CID field.
 
   V: 1-bit context validity flag.  This flag indicates if the context
      is valid, and is used only in combination with the C flag.  A
      context that is not valid MUST not be used for compression, but
      MAY be used in decompression in case another compressor still
      considers the context as valid.
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 21] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   CID:  4-bit Context Identifier for this prefix information.  CID is
      used by context based header compression specified in
      [I-D.ietf-6lowpan-hc].  The list of CIDs for a LoWPAN is
      configured on Edge Routers, who distribute the prefix list to all
      nodes in the LoWPAN.
 
   Valid Lifetime:  32-bit unsigned integer.  The length of time in
      seconds (relative to the time the packet is sent) that the prefix
      is valid for the purpose of on-link determination.  A value of all
      one bits (0xffffffff) represents infinity.
 
   Information:  The IPv6 prefix or context information indicated.  This
      may be a partial prefix, a partial context or even an entire IPv6
      address for use as a context for compression.
 
4.4.3.  6LoWPAN Summary Option 
 
   This option identifies the set of prefix information options by a
   sequence number.  This allows for the full set of prefix information
   options to be sent only periodically in unsolicited RAs.  If a host
   detects a difference in the sequence number of this option, then the
   prefix information has likely changed, and is then requested with an
   RS.  An RA sent in response to a unicast RS always includes the full
   set of prefix information.
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |       Sequence Number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V|          Reserved           |           ER Metric           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                     Figure 7: 6LoWPAN Summary Option
 
   Type:  TBD5
 
   Length:  1
 
   Sequence Number:  16-bit signed integer.  Indicates the freshness of
      the information advertised by the RA.
 
   ER Metric:  16-bit unsigned integer.  The ER Metric gives an
      indication of the cost (in routing metric terms) of reaching nodes
      outside the LoWPAN via an Edge Router through this router.  The metric
      SHOULD be derived in a well-defined way from the routing protocol
      used in the LoWPAN (possibly by structuring the 16 bits available
      e.g. into a major and a minor metric), and has a mid-range default
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 22] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
      value of 0x8000.  Edge Routers most likely set this field to 0.  A
      host SHOULD take this metric into account when choosing default
      routers by making a scalar comparison, preferring routers with
      numerically lower ER Metric values.
 
   V: 1-bit flag.  Indicates if the sequence number is valid and the
      router is advertising information obtained from another router.
 
   Reserved:  This field is unused.  It MUST be initialized to zero by
      the sender and MUST be ignored by the receiver.
 
4.4.4.  Owner Interface Identifier Option 
 
   This option is used together with Router Solicitation messages when a
   node has only optimistic addresses before initial registration.
 
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Length    |      TID      |    Reserved   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Owner Nonce                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                  Owner Interface Identifier                   +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                Figure 8: Owner Interface Identifier Option
 
   Type:  TBD6
 
   Length:  2
 
   TID:  8-bit unsigned integer.  This field is set to the last TID
      value used for sending an NR message.
 
   Reserved:  This field is unused.  It MUST be initialized to zero by
      the sender and MUST be ignored by the receiver.
 
   Owner Nonce:  A 32-bit Owner Nonce generated randomly by the node
      upon booting, and generated again each time the node re-boots.
      This Owner Nonce is used to detect duplicate OIIs.
 
   Owner Interface Identifier:  A globally unique identifier for the
      host's interface.  This is typically the EUI-64 derived IID of the
      interface.
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 23] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
5.  Protocol Specification 
 
   This section specifies the functions defined by this specification,
   along with pointers to needed procedures from other specifications.
   These basic procedures are sufficient and required for LoWPAN
   operation.
 
5.1.  Interface initialization 
 
   A LoWPAN node forms a 64-bit Interface Identifier (IID) as specified
   in Section 6 of [RFC4944].  This may be based on the EUI-64
   identifier, an assigned 16-bit short address, or any other
   appropriate MAC address.  All nodes MUST configure at least one
   address, a link-local address, by concatenating its IID with the
   prefix FE80::/64 as specified in Section 7 of [RFC4944].  As a
   result, knowledge of the IID of another node is enough to
   derive its link-local address and reach it on the same link.  If
   derived from an EUI-64 or an equivalent the link-local address is
   presumably unique on the LoWPAN, which enables the use of Optimistic
   Duplicate Address Detection (oDAD) [RFC4429].  The address SHOULD be
   created as optimistic before it has been confirmed by Node
   Registration (Section Section 5.2).  This document assumes that
   addresses are formed in a uniform manner in a LoWPAN.  Appropriate
   steps SHOULD be taken to ensure that only correctly configured
   devices participate in the LoWPAN, e.g. using L2 security mechanisms.
 
   A node MUST join the all-nodes multicast address, which is used for
   receiving RAs from routers.  A router MUST also join the all-routers
   multicast address.  A node MAY join other multicast addresses such as
   the solicited-node multicast address if its link-layer includes
   multicast support, but that is not required by this specification.
 
   Nodes MAY learn the address of routers using traditional means such
   as L2 configuration or Router Advertisement messages as in [RFC4861].
   When sending a Router Solicitation it MUST not have the SLLAO Option,
   but instead MUST include the OII Option.  If the sender of the RS has
   only optimistic addresses, it MUST not use them as the IPv6 source
   address for the RS, but instead uses the IPv6 unspecified address.
   This procedure is to comply with the use of optimistic addresses as
   per oDAD [RFC4429].
 
   The node SHOULD also form a global unicast address for routing inside
   the LoWPAN and reachability from outside the LoWPAN.  If a valid
   prefix is available from an RA ('A' flag is set), then a global
   unicast address MAY be derived following the general description in
   Section 5.5 of [RFC4862].  This address is marked optimistic until
   confirmed by the Node Registration process.  If the LoWPAN is
   operating in ad-hoc mode, then the prefix is a Unique on-link IPv6
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 24] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   Address (ULA) prefix [RFC4193] as specified in Section 8 (use of a
   ULA prefix requires no changes to node operation).  A node MAY
   alternatively acquire a global unicast address using other suitable
   means, e.g.  DHCPv6, L2 assignment or manual configuration.
 
5.2.  Node Registration 
 
   The node registration process is very similar to that of a MIPv6
   mobile node, though the messages used are new Node Registration/Confirmation ICMP
   messages.  A node address is optimistic as long as the binding is
   not confirmed by a router.  The node sends a unicast Node
   Registration to an on-link router to perform the binding.  While a
   node's addresses are still optimistic (first registration in a
   LoWPAN), the IPv6 unspecified address must be used as the source.
   Registration SHOULD be preferred with on-link Edge Routers rather
   than routers if available.  The Preference Flag of the RA is
   used to differentiate between Edge Routers (Prf=01) and routers
   (Prf=00).  Routers with Prf=11 SHOULD NOT be used for
   registration.  Furthermore the ER Metric in the 6LoWPAN Summary
   Option SHOULD be used to rank routers.
 
   A unique Owner Interface Identifier (OII) is included in the Node
   Registration so the binding can be identified throughout the LoWPAN.
   The OII SHOULD be formed from the EUI-64 of the interface in the same
   way as the node's link-local address IID as defined in [RFC4944].  A
   randomly generated 32-bit Owner Nonce is formed each time a node
   boots or reboots.  This is included in the NR and may be used to
   detect duplicate OIIs.  While cryptographic randomness [RFC4086] is
   not strictly required, the randomness SHOULD be derived using a
   mechanism of similar quality.
 
   The NR message includes an Address Option for each address to be
   registered.  Thus the message is structured as follows:
 
   ICMPv6 (Node Registration (Address Option[0], Address Option[1],
   Address Option[n]))
 
   This registration method includes a way of requesting a unique
   address by setting the 'A' flag in an Address Option during
   registration.  This is useful for receiving a unique short link-layer
   address.  How a router assigns such an address is out of scope for
   this document.
 
   A unique Transaction ID (TID) is included by the host in the NR
   message and used to match replies.  A lollipop mechanism is used.
   TID is set to 0 upon booting, and is incremented with each Request NR
   message.  The TID MUST NOT be incremented when sending a Refresh NR
   message.  After reaching 0xFF, the value loops to 16 (0x10) and is
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 25] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   incremented from there.  Thus the values between 0-15 MUST only used
   after a boot or reboot while not yet registered.  A node that has not
   heard a valid Node Confirmation for 16 Node Registration messages in
   a row restarts with a on-link next TID of zero (the node MAY, but
   need not, generate a new Owner Nonce).
 
   The acknowledgment to a Node Registration is a unicast Node
   Confirmation message that contains the status of the bindings.  The
   source of the packet is the link-local address of the on-link router.
   The destination address is the link-local address of the node.  An
   Address Option for each confirmed or assigned address is included.
   Upon successful completion in the Node Confirmation message, the
   node sets the address from optimistic to preferred.  See
   Section 11 for message examples.
 
   Node bindings have timeouts associated with them, therefore nodes
   must periodically send a new Node Registration message to renew the
   binding.  The period between Request NR messages SHOULD be less than
   BindingLifetime.  If a node no longer receives Node Confirmation
   messages from any router in the current subnet, the registration
   process starts over.
 
5.2.1.  Processing a Node Registration Message 
 
   When a router receives a Node Registration message from a node, it
   first checks for correctness of the message fields and options.  In
   the case of an existing node, the message is used to refresh the
   corresponding entries in the router's binding table.
 
   In the case of a new node, then a binding table entry is made for
   each 6AO in the message.  The router SHOULD perform Duplicate Address
   Detection on each optimistic address (O flag set), see Section 5.3 
   for further information on the DAD procedure.  If a 6AO option with
   an A flag is received, then the router should acquire a suitable
   address for the node.  How this is done is out of scope.  Depending
   on the link-layer and network it may be possible to generate a random
   address (DAD MUST be performed in this case), acquire an address from
   a link-layer coordinator, or perform DHCPv6 in a managed network to
   name a few.
 
   After processing all 6AO options, a unicast Node Confirmation message
   is sent back to the node with an appropriate NC Status code and
   success codes for each 6AO option in the same order as received.
 
5.2.2.  Processing a Node Confirmation Message 
 
   When a node receives a Node Confirmation message from a router, it
   first checks for correctness of the message fields and options.
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 26] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   If a NC is received with a success status (0-7), then the node goes
   on to process 6LoWPAN Address Options.  If a successful NC is
   received with a code of 2, this indicates that the node should re-
   register with that router.
 
   6LoWPAN Address Options are processed one at a time.  A success
   status (0-127) indicates that the address was successfully bound with
   the router.  If the address is marked optimistic, it is now updated
   to preferred.  A failure code (128-) indicates that the binding
   failed.  See Section 4.4.1 for an explanation of 6AO codes.  A
   binding failure may indicate that a duplicate address (and thus a
   duplicate IID) already exists.  In this case the node SHOULD attempt
   to form a new IID and restart the registration process.  If this is
   not possible, the node MUST not participate in the LoWPAN.
 
   If a NC is received with an error status (8 or greater), then the
   registration has failed.  See Section 4.1 for an explanation of NR/NC
   codes.  If no successful Node Confirmation is received within the
   timeout (RegistrationTimeout) and number of retries
   (RegistrationRetries), then registration should be performed with
   another router in the default router list.
 
5.3.  Duplicate Address Detection 
 
   It is important for proper network operation that duplicate addresses
   are not used in a LoWPAN as described in "IPv6 Stateless Address
   Autoconfiguration" [RFC4862].  Furthermore, as LoWPANs are made up of
   links with undetermined connectivity, it is important that address
   uniqueness is ensured thoughout the routing domain as discussed in
   [I-D.ietf-autoconf-adhoc-addr-model].  Hosts may be very
   simple, and thus are not expected to have the capability of
   performing a duplicate address detection (DAD) algorithm themselves.
   Therefore the handling of DAD is considered a function of routers.
   This document does not perform DAD as defined in [RFC4862],
   but instead makes use of alternative techniques appropriate for
   LoWPANs.  It is assumed that all routers in a LoWPAN are configured
   to perform DAD in a uniform way.  If there is only a single router in
   the LoWPAN, as occurs in mesh-under or star topologies, then a router
   automatically detects duplicates by checking its own binding table
   during registration, thus no additional mechanism is needed.
 
   If a router receives a Node Registration 6AO with the Optimistic Flag
   (O) set, it SHOULD perform DAD on this address.  If the router
   generates or assigns an address for a node in response to a 6AO with
   the A flag set, it SHOULD perform DAD on that address.  DAD MAY be
   disabled if the address has been generated or assigned in such a way
   that there is high confidence of no duplicates (WARNING IN LARGE
   PRINT).  Examples include the use of an EUI-64 to form an IID or
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 27] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   DHCPv6 performed through a single server uniformly by all nodes in
   the LoWPAN (as per the homogeneous LoWPAN assumption).
 
   A router can be configured to perform DAD using one of the following
   techniques, the details of which are out of the scope of this
   document:
 
   Extended LoWPAN:  The Extended LoWPAN technique defined in (draft
      tbd) provides DAD during its ER registration.
 
   Routing protocol:  If supported, a routing protocol mechanism could
      be used to check for the existance of an address in the LoWPAN,
      assuming that it is covered by a single routing domain.
 
5.4.  Next-hop Determination 
 
   The IP address of the next-hop for a destination is determined as
   follows.  Destinations to the link-local prefix (FE80::) are always
   sent on the link to that destination.  All other prefixes are assumed
   to be off-link as recommended in
   [I-D.ietf-autoconf-adhoc-addr-model].  They are therefore sent to the
   IP address of a router chosen from the Default Router List.
 
   Multicast addresses are considered to be on-link and are resolved as
   specified in [RFC4944] or relative future documents.  A node
   is not required to maintain a minimum of one buffer per neighbor as
   specified in [RFC4861], as address lookup is not performed as part of
   next-hop determination.  Anycast addresses are always considered to
   be off-link.
 
5.5.  Address Resolution 
 
   The node registration mechanism provides sufficient a priori state in
   nodes and routers to resolve an IPv6 address to its associated link-
   layer address on the node-router interface.  As prefixes are always
   assumed to be off-link, resolution between hosts is not needed.
 
   Information about link-layer addresses is stored by nodes about
   routers in its default router list, and by routers about nodes in its
   binding table.  This information is stored during the node
   registration process.  In order to achieve LoWPAN compression, most
   global addresses are also formed using a link-layer address.  A node
   can minimize memory usage by making use of an educated guess and
   storing link-layer address information only if it differs from the
   link-layer address corresponding to the IID of the IPv6 address
   (i.e., differs in more than the on-link/global bit being inverted).
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 28] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
5.6.  Unreachability Detection 
 
   Unreachability between a node and router is determined based on NR/NC
   and RS/RA exchanges and other unicast L3 data messages.  Host-host
   unreachability detection is out of scope.
 
   In order to detect unreachable destinations, nodes SHOULD support
   type 1 ICMPv6 destination unreachable messages [RFC4443].  LoWPAN
   Routers or Edge Routers make use of ICMPv6 destination unreachable to
   indicate that delivery to that destination is not possible.
 
5.7.  Context Dissemination 
 
   Network configuration parameters carried in Router Advertisements
   originate at Edge Routers and must disseminate to all routers and
   hosts within the LoWPAN.  RAs include either 6LoWPAN Information
   Options (one for each context) and a 6LoWPAN Summary Option, or just
   a 6LoWPAN Summary Option.
 
   For the dissemination of context information using the 6IO, a strict
   lifecycle SHOULD be used in order to ensure the context information
   stays synchronized throughout the LoWPAN.  New context information
   SHOULD be introduced into the LoWPAN with C=1 and V=0, to ensure it
   is known by all nodes that may have to decompress based on this
   context information.  Only when it is reasonable to assume that this
   information was successfully disseminated SHOULD an option with C=1
   and V=1 be sent, enabling the actual use of the context information
   for compression.
 
   Conversely, to avoid that nodes send packets making use of previous
   values of contexts, resulting in ambiguity when receiving a packet
   that uses a recently changed context, old values of a context SHOULD
   be taken out of use for a while before new values are assigned to
   this specific context.  That is, in preparation for a change of
   context information, its dissemination SHOULD continue for at least
   MIN_CONTEXT_CHANGE_DELAY with C=1 and V=0.  Only when it is
   reasonable to assume that the fact that the context is now invalid
   was successfully disseminated, should the context ID be taken out of
   dissemination or reused with a different Information field.  In the
   latter case, dissemination of the new value again SHOULD start with
   C=1 and V=0, as above.
 
   The 6LoWPAN Summary Option is used to support information
   dissemination from one or more Edge Routers to all other nodes in the
   LoWPAN.  The option includes a "V" flag which indicates that the
   information contained in the Router Advertisement is valid.  The
   option also includes a sequence number to ensure that all nodes
   converge on the same settings.  The sequence number is incremented by
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 29] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   the originating Edge Router each time the set of prefix information
   changes.
 
   As the number of prefixes or addresses included for context
   compression in an RA may be large (up to 16), it is beneficial to
   avoid the need to always include all options in every RA.  Therefore
   routers SHOULD only include the 6LoWPAN Summary Option in unsolicited
   RAs, unless a set of prefix information with a new sequence number is
   being disseminated.  In the case of a new sequence number, the router
   SHOULD include all 6LoWPAN Information Options in the RA.  A node may
   use an RS with Code set to 1 in order to get the whole prefix
   information set in case it misses the RA sent when the sequence
   number changes.  An RS with Code set to 0 is responded to with an RA
   with the 6SO.
 
 
6.  Node Specification 
 
   This section specifies the conceptual data structures and variables
   of a LoWPAN Node.
 
6.1.  Conceptual structures 
 
   Nodes make use of the following conceptual data structures:
 
   Prefix List  - The list of prefixes which are advertised in Router
      Advertisements, along with an associated invalidation timer.  Each
      entry is associated with the sequence number last advertised in
      the 6LoWPAN Summary Option.  Unlike in [RFC4861], these prefixes
      are always assumed to be off-link.
 
   Context List  - The list of contexts and their associated CID which
      are advertised in Router Advertisements, along with an associated
      invalidation timer.  Each entry is associated with the sequence
      number last advertised in the 6LoWPAN Summary Option.  This list
      may be realized together with the Prefix List.
 
   Default Router List  - As in [RFC4861].  For networks where address
      resolution needs to be performed, this list also contains link-
      layer information about each router.
 
   These conceptual data structures may be realized in many ways.  As
   nodes have very limited memory the number of cache entries
   should be limited, duplicate entries between caches referenced, and
   full IPv6 addresses represented in a compressed format where
   possible.
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 30] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
6.2.  Conceptual variables 
 
   The following variables are kept for each interface on a node, and
   default values are overridden by information in Router
   Advertisements:
 
   CurHopLimit         The default hop limit to be used when sending IP
                       packets.
 
   CurTID              The current Transaction ID (TID) value for use in
                       NR messages.
 
   BindingLifetime     The binding lifetime sent in Node Registration
                       messages.
 
   RegistrationTimeout The time to wait for a Node Confirmation after
                       sending a Node Registration.  SHOULD be at least
                       MIN_NR_TIMEOUT.
 
   RegistrationRetries The number of times to try to send a Node
                       Registration, which SHOULD be less than
                       MAX_NR_RETRIES.
 
 
7.  Router Specification 
 
   Routers are used in a route-over configuration where the
   network is composed of overlapping link-local scopes.  Edge
   Routers implement router functionality.  As a result, we
   extend classic ND as specified in [RFC4861] to operate over such non-
   transitive LoWPAN links.  This section describes ND for 
   router operations in a LoWPAN.  Note that this section does not entirely apply to
   pure Mesh Under LoWPANs where the are no routers, although
   they do have Edge Routers.
 
7.1.  Router Configuration Variables 
 
   A router MUST allow the configuration of conceptual variables as
   defined in Section 6.2.1 of [RFC4861].  AdvReachableTime and
   AdvRetransTimer are not used.
 
7.2.  Becoming an Advertising Interface 
 
   An interface may become an advertising interface as specified in
   Section 6.2.2 of [RFC4861].
 
   A router's interface MAY become an advertising interface
   before all of its router variables have been initialized.  The router
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 31] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   MUST learn these variables (e.g.  AdvCurHopLimit, prefix and context
   information, etc.) from neighboring routers.  While the variables are
   not initialized, the router MAY send Router Advertisement with the
   "Solicit" flag set to solicit Router Advertisements from neighboring
   routers.  However, the router MUST set the Router Lifetime field to
   zero while one or more of its variables are uninitialized.
 
7.3.  Router Advertisement Message Content 
 
   A router sends periodic as well as solicited Router Advertisements
   out its advertising interface.  Outgoing Router Advertisements are
   filled with the following values consistent with the message format
   given in this document.
 
      - In the Router Lifetime field: if the router has a default route,
      the interface's configured AdvDefaultLifetime.  If the router does
      not have a default route, zero.
 
      - In the M and O flags: the current value of AdvManagedFlag and
      AdvOtherConfigFlag, respectively.
 
      - In the Preference flag: this flag is set to 00 to indicate that
      the sender is a router.
 
      - In the Cur Hop Limit field: the current value of CurHopLimit.
 
      - In the Reachable Time field: not used, set to zero.
 
      - In the Retrans Timer field: not used, set to zero.
 
      - In the options:
 
         - 6LoWPAN Summary Option: to indicate if the information
         contained in the Router Advertisement is valid and, if so, the
         freshness of the information contained in the Router
         Advertisement message.  The option fields are set as follows:
 
            - In the "valid" flag: the current value of
            AdvInformationValid.
 
            - In the Sequence Number field: the current value of
            AdvInformationSequence.
 
            - The ER Metric field is used by a routing algorithm to
            indicate the cost of reaching an Edge Router through this
            router.
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 32] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
         - 6LoWPAN Information options: one 6LoWPAN Information option
         for each prefix listed in AdvPrefixList with the option fields
         set from the information in the AdvPrefxList entry as follows:
 
            - In the "on-link" flag: the entry's AdvOnLinkFlag.
 
            - In the "Autonomous address configuration" flag: the
            entry's AdvAutonomousFlag.
 
            - In the Valid Lifetime field: the entry's AdvValidLifetime.
 
7.4.  Sending Unsolicited Router Advertisements 
 
   As specified in Section 6.2.4 of [RFC4861].
 
7.5.  Ceasing To Be an Advertising Interface 
 
   As specified in Section 6.2.5 of [RFC4861].
 
7.6.  Processing Router Solicitations 
 
   As specified in Section 6.2.6 of [RFC4861].
 
7.7.  Binding Table 
 
   Routers maintain an set of information about nodes that are currently
   registered through it called the binding table.
 
   The binding table contains an entry with information such as the
   registered node's OII, link-local IPv6 address and the binding
   lifetime from the last NR.  If address resolution is required, the
   table will also include corresponding link-layer address information.
 
 
8.  Ad-hoc LoWPAN 
 
   LoWPAN networks by nature may often work in an ad-hoc fashion,
   without an infrastructure or connectivity to the global Internet.
   6LoWPAN-ND may still be applied in such networks.
 
   A specific router in the Ad-hoc LoWPAN is nominated as Edge Router
   and configured to implement basic Edge Router functionality
   (initiating RA dissemination) and generates a prefix based on Unique
   on-link IPv6 Unicast Addresses (ULAs) as defined in [RFC4193].  A
   ULA is made up of the prefix fc00::/7, a global ID and a subnet ID.
   The global ID is randomly generated, and the subnet ID is not used.
   The Edge Router is responsible for the generation of the ULA prefix 
   to be advertised to the LoWPAN and used by all nodes.  ULA generation
   may use the algorithm suggested Section
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 33] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   3.2.2 of [RFC4193] or something appropriate to the Edge Router's
   capabilities.  There SHOULD be only one Edge Router in an Ad-hoc
   LoWPAN (just as in a Simple LoWPAN) to keep prefix consistency.
 
   In the case that an Edge Router on a Simple LoWPAN does not have a
   prefix available from its IPv6 address, it SHOULD advertise a ULA
   prefix in a similar manner.
 
 
9.  Protocol Constants 
 
   This section defines the protocol constants used in this document
   based on a subset of [RFC4861] constants. (*) indicates constants
   modified from [RFC4861] and (+) indicates new constants.
 
   Additional protocol constants are defined in Section Section 4.
 
   Edge Router Constants:
 
   MIN_CONTEXT_CHANGE_DELAY+               60 seconds
 
   Router Constants:
 
   MAX_INITIAL_RTR_ADVERT_INTERVAL*        60 seconds
 
   MAX_INITIAL_RTR_ADVERTISEMENTS          3 transmissions
 
   MAX_FINAL_RTR_ADVERTISEMENTS            3 transmissions
 
   MIN_DELAY_BETWEEN_RAS*                  10 seconds
 
   MAX_RA_DELAY_TIME*                      2 seconds
 
   Host Constants:
 
   MAX_RTR_SOLICITATION_DELAY*             2 second
 
   RTR_SOLICITATION_INTERVAL*              10 seconds
 
   MAX_RTR_SOLICITATIONS                   3 transmissions
 
   Node Constants:
 
   MAX_NR_RETRIES+                         3 transmissions
 
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 34] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   MIN_NR_TIMEOUT+                         5 seconds
 
 
10.  Use of 6LoWPAN-ND under RFC4861-only stacks 
 
   Some IPv6 stacks (e.g. on PCs) and tools (e.g. radvd) hard-wire the
   mechanisms of RFC4861 for all links.  This section explains the
   adaptation needed in order to use a 6LoWPAN interface under such an
   RFC4861-only implementation.
 
   There are several ways to implement 6LoWPAN-ND in combination with an
   IPv6 stack:
 
   o  6LoWPAN-ND is integrated with the IPv6 stack and its tools.  This
      is common for LoWPAN nodes.
 
   o  6LoWPAN-ND is implemented as part of the interface, configuration
      is used to turn off RFC4861 mechanisms in the IPv6 stack.  For
      example, Proxy-ND interfaces can be used in Linux to disable most
      built-in ND mechanisms.  This model is common for Edge Routers
      running on a standard operating system.
 
   o  6LoWPAN-ND is implemented as part of the interface, and it
      performs adaptation for RFC4861 mechanisms running on the IPv6
      stack.  The binding table is used to answer RFC4861 messages, and
      appropriate options added to RA messages.
 
   Classic RS/RA messages can be used with a LoWPAN, thus allowing e.g.
   for an unmodified radvd (with appropriate configuration) to be run on
   an Edge Router as long as context dissemination is not needed.  It is
   however recommended that 6IO and 6SO options be used if possible,
   which is easily achieved by patching existing RA tools or performing
   adaptation.
 
 
11.  Message Examples 
 
   This section provides basic examples of messages and options from
   this document.
 
11.1.  NR/NC message exchange 
 
   When a host wants to register to a router, a simple NR/NC request
   message exchange occurs.  In this example, a host wants to register
   its address generated with Stateless Address Autoconfiguration (SAA),
   and in addition requests a generated short address.
 
   First the Host sends an NR message to the link-local address of the
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 35] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   router.  In this example the host includes a 600 second binding
   lifetime and its modified EUI-64 as the Owner Interface Identifier.
   The message has two Address Options.  The host has just booted,
   therefore the TID starts with 0.  This example assumes that the
   LoWPAN prefix has been assigned CID 0.
 
   IPv6 Source: Unspecified address
   IPv6 Destination: Router's link-local address
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = TBD   |   0   |   0   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TID = 0     |1|0|                 Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Binding Lifetime = 60      |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Owner Nonce                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  Owner Interface Identifier =                 +
   |                Modified EUI-64 of the interface               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
                        Figure 9: Basic NR request.
 
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = TBD   |   Length = 1  |  Status = 0   | S=1 |  P=0    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|1|      Reserved         |         Padding  = 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
           Figure 10: NR Address Option 1, for the SAA address.
 
 
 
 
 
 
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 36] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = TBD   |   Length = 1  |  Status = 0   | S=2 |  P=0    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1|0|0|      Reserved         |         Padding = 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
        Figure 11: NR Address Option 2, for the requested address.
 
 
   IPv6 Source: Router's link-local address
   IPv6 Destination: Host's link-local address
 
   The base NC message is identical to the base NR message above.
 
 
                   Figure 12: Corresponding NC message.
 
 
 
   Address Option 1 is identical to Address Option 1 in the NR.
 
 
           Figure 13: NC Address Option 1, for the SAA address.
 
 
   Address Option 2 now includes the generated address.
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = TBD   |   Length = 1  |  Status = 0   | S=2 |  P=0    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1|0|0|      Reserved         |   Generated 16-bit address    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
        Figure 14: NC Address Option 2, for the requested address.
 
11.2.  Router advertisement 
 
   Routers and Edge Routers in LoWPAN networks periodically send RA
   messages.  The following example is of an RA message sent by a
   router.  If the message is sent by an Edge Router, the only difference
   is that the Preference flag is set to 10.
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 37] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   In the example the Preference flag is 01 (router), and a 1200s Router
   Lifetime is advertised.  A 6LoWPAN Prefix Information Option is
   included.
 
 
     IPv6 Source: Router's link-local address
     IPv6 Destination: All-nodes multicast address
 
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 134   |   Code = 0    |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cur Hop Limit |0|0|0|0 0|Rsrvd|    Router Lifetime = 1200     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Reachable Time = 0                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Retrans Timer = 0                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
                      Figure 15: RA message example.
 
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = TBD   |  Length = 2   |     PL = 64   |0|1|1|1| CID=0 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Valid Lifetime = 3000                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                    Prefix = 2001:DB8::/64                     .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
              Figure 16: 6LoWPAN Information Option example.
 
 
12.  Security Considerations 
 
   The security considerations of IPv6 Neighbor Discovery [RFC4861]
   apply.  Additional considerations can be found in [RFC3756].
 
   This specification expects that the link layer is sufficiently
   protected, either by means of physical or IP security for the
   backbone link or MAC sublayer cryptography.  In other words, model 1
   from [RFC3756] applies.  In particular, it is expected that the
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 38] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   LoWPAN MAC provides secure unicast to/from Routers and secure
   broadcast from the Routers in a way that prevents tampering with or
   replaying the RA messages.  However, any future 6LoWPAN security
   protocol that applies to Neighbor Discovery for 6LoWPAN protocol, is
   out of scope of this document.
 
   The use of EUI-64 for forming the Interface ID in the link on-link
   address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and
   address privacy techniques.  Considering the envisioned deployments
   and the MAC layer security applied, this is not considered an issue
   at this time.
 
 
13.  IANA Considerations 
 
   This document requires two new ICMPv6 message types:
 
   o  Node Registration (TBD1)
 
   o  Node Confirmation (TBD2)
 
   The document also requires four new ND option types under the
   subregistry "IPv6 Neighbor Discovery Option Formats":
 
   o  6LoWPAN Address Option (TBD3)
 
   o  6LoWPAN Information Option (TBD4)
 
   o  6LoWPAN Summary Option (TBD5)
 
   o  Owner Interface Identifier Option (TBD6)
 
   [TO BE REMOVED: This registration should take place at the following
   location: http://www.iana.org/assignments/icmpv6-parameters]
 
 
14.  Acknowledgments 
 
   The authors thank Richard Kelsey, Geoff Mulligan, Julien Abeille,
   Alexandru Petrescu, Peter Siklosi, Pieter De Mil, Fred Baker, Anthony
   Schoofs, Phil Roberts and Joakim Eriksson for useful discussions and
   comments that have helped shaped and improve this document.
 
 
15.  Changelog 
 
   Changes from -07 to -08:
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 39] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
      o Removed Extended LoWPAN and Whiteboard related sections.
 
      o Included reference to the autoconf addressing model.
 
      o Added Optimistic Flag to 6AO.
 
      o Added guidelines on routers performing DAD.
 
      o Removed the NR/NC Advertising Interval.
 
      o Added assumption of uniform IID formation and DAD throughout a
      LoWPAN.
 
   Changes from -06 to -07:
 
      o Updated addressing and address resolution (#60).
 
      o Changed the Address Option to 6LoWPAN Address Option, fixed S
      values (#61).
 
      o Added support for classic RFC4861 RA Prefix Information messages
      to be processed (#62).
 
      o Added a section on using 6LoWPAN-ND under a hard-wired RFC4861 
      stack (#63).
 
      o Updated the NR/NC message with a new Router flag, combined the
      Code and Status fields into one byte, and added the capability to
      carry 6IOs (#64).
 
      o Made co-existence with other ND mechanisms clear (#59).
 
      o Added a new Protocol Specification section with all mechanisms
      specified there (#59).
 
      o Removed dependencies and conflicts with RFC4861 wherever
      possible (#59).
 
      o Some editorial cleanup.
 
   Changes from -05 to -06:
 
      o Fixed the Prf codes (#52).
 
      o Corrected the OIIO TID field to 8-bits.  Changed the Nonce/OII
      order in both the OIIO and the NR/NC. (#53)
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 40] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
      o Corrected an error in Table 1 (#54).
 
      o Fixed asymmetric and a misplaced transient in the 6LoWPAN
      terminology section.
 
      o Added Updates RFC4861 to header
 
   Changes from -04 to -05:
 
      o Meaning of the RA's M-bit changed to original [RFC4861] meaning
      (#46).
 
      o Terms "on-link" and "off-link" used in place of "on-link" and
      "off-link".
 
      o Next-hop determination text simplified (#49).
 
      o Neighbor cache and destination cache removed.
 
      o IID to link-layer address requirement relaxed.
 
      o NR/NC changes to enable on-link refresh with routers (#48).
 
      o Modified 6LoWPAN Information Option (#47).
 
      o Added a Protocol Constants section (#24)
 
      o Added the NR processing table (#51)
 
      o Considered the use of SeND on backbone NS/NA messages (#50)
 
   Changes from -03 to -04:
 
      o Moved Ad-hoc LoWPAN operation to Section 7 and made ULA prefix
      generation a features useful also in Simple and Extended LoWPANs.
      (#41)
 
      o Added a 32-bit Owner Nonce to the NR/NC messages and the
      Whiteboard, removed the TID history. (#39)
 
      o Improved the duplicate OII detection algorithm using the Owner
      Nonce. (#39)
 
      o Clarified the use of Source and Target link-layer options in
      NR/NC. (#43)
 
      o Included text on the use of alternative methods to acquire
      addresses. (#38)
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 41] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
      o Removed S=2 from Address Option (not needed). (#36)
 
      o Added a section on router dissemination consistency. (#44)
 
      o Small improvements and extensive editing. (#42, #37, #35)
 
   Changes from -02 to -03:
 
      o Updated terminology, with RFC4861 non-transitive link model.
 
      o 6LoWPAN and ND terminology separated.
 
      o Protocol overview explains RFC4861 diff in detail.
 
      o RR/RC is now Node Registration/Confirmation (NR/NC).
 
      o Added NR failure codes.
 
      o ER Metric now included in 6LoWPAN Summary Option for use in
      default router determination by hosts.
 
      o Examples of host data structures, and the Whiteboard given.
 
      o Whiteboard is supported by all Edge Routers for option
      simplicity.
 
      o Edge Router Specification chapter re-structured, clarifying
      optional Extended LoWPAN operation.
 
      o NS/NA now completely optional for nodes.  No address resolution
      or NS/NA NUD required.
 
      o link-local operation now compatible with oDAD (was broken).
 
      o Exception to hop limit = 255 for NR/NC messages.
 
      o Security considerations improved.
 
      o ICMPv6 destination unreachable supported.
 
   Changes from -01 to -02:
 
      o Fixed 16 != 0xff bug (ticket closed).
 
      o Specified use of ULAs in ad-hoc LoWPAN section 9 (ticket
      closed).
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 42] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
      o Terminology cleanup based on Alex's comments.
 
      o General editing improvements.
 
   Changes from -00 to -01:
 
      o Specified the duplicate owner interface identifier procedures.
      A TID lollipop algorithm was sufficient (nonce unnecessary).
 
      o Defined fault tolerance using secondary bindings.
 
      o Defined ad-hoc network operation.
 
      o Removed the E flag from RA and the X flag from RR/RC.
 
      o Completed message examples.
 
      o Lots of improvements in text quality and consistency were made.
 
 
16.  References 
 
16.1.  Normative References 
 
   [I-D.ietf-autoconf-adhoc-addr-model]
              Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
              Hoc Networks", draft-ietf-autoconf-adhoc-addr-model-02 
              (work in progress), January 2010.
 
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 
   [RFC2491]  Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
              over Non-Broadcast Multiple Access (NBMA) networks",
              RFC 2491, January 1999.
 
   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.
 
   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.
 
   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.
 
   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, April 2006.
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 43] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.
 
   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.
 
   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.
 
   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.
 
16.2.  Informative References 
 
   [I-D.ietf-6lowpan-hc]
              Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-06 
              (work in progress), October 2009.
 
   [RFC2022]  Armitage, G., "Support for Multicast over UNI 3.0/3.1
              based ATM Networks", RFC 2022, November 1996.
 
   [RFC3122]  Conta, A., "Extensions to IPv6 Neighbor Discovery for
              Inverse Discovery Specification", RFC 3122, June 2001.
 
   [RFC3756]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
              Discovery (ND) Trust Models and Threats", RFC 3756,
              May 2004.
 
   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.
 
   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.
 
   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.
 
   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
              June 2007.
 
   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, August 2007.
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 44] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
Authors' Addresses
 
   Zach Shelby (editor)
   Sensinode
   Hallituskatu 13-17D
   Oulu  90100
   FINLAND
 
   Phone: +358407796297
   Email: zach@sensinode.com
 
 
   Pascal Thubert
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   FRANCE
 
   Phone: +33 4 97 23 26 34
   Email: pthubert@cisco.com
 
 
   Jonathan W. Hui
   Arch Rock Corporation
   501 2nd St. Ste. 410
   San Francisco, California  94107
   USA
 
   Phone: +415 692 0828
   Email: jhui@archrock.com
 
 
   Samita Chakrabarti
   IP Infusion
   1188 Arquest Street
   Sunnyvale, California
   USA
 
   Phone:
   Email: samitac@ipinfusion.com
 
 
 
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 45] 
  
 
Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
 
 
   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany
 
   Phone: +49-421-218-63921
   Fax:   +49-421-218-7000
   Email: cabo@tzi.org
 
 
   Erik Nordmark
   Sun Microsystems
   17 Network Circle
   Menlo Park, California  94025
   USA
 
   Phone:
   Email: Erik.Nordmark@Sun.COM
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Shelby, et al.           Expires August 5, 2010                [Page 46]

Html markup produced by rfcmarkup 1.86, available from http://tools.ietf.org/tools/rfcmarkup/
--------------040803030100040905000609-- --------------060203090205000409070206 Content-Type: text/html; charset=UTF-8; name="draft-ietf-6lowpan-nd-08-rcc-mod.html" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-6lowpan-nd-08-rcc-mod.html" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv bmFsLy9FTiINCiAgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRy YW5zaXRpb25hbC5kdGQiPiANCjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5 L3hodG1sIiB4bWw6bGFuZz0iZW4iIGxhbmc9ImVuIj4gDQo8aGVhZCBwcm9maWxlPSJodHRw Oi8vZHVibGluY29yZS5vcmcvZG9jdW1lbnRzLzIwMDgvMDgvMDQvZGMtaHRtbC8iPiANCiAg ICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsg Y2hhcnNldD11dGYtOCIgLz4gDQogICAgPG1ldGEgbmFtZT0icm9ib3RzIiBjb250ZW50PSJp bmRleCxmb2xsb3ciIC8+IA0KICAgIDxtZXRhIG5hbWU9ImNyZWF0b3IiIGNvbnRlbnQ9InJm Y21hcmt1cCB2ZXJzaW9uIDEuODYiIC8+IA0KICAgIDxsaW5rIHJlbD0ic2NoZW1hLkRDIiBo cmVmPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIgLz4gDQo8bWV0YSBuYW1l PSJEQy5SZWxhdGlvbi5SZXBsYWNlcyIgY29udGVudD0iZHJhZnQtaHVpLTZsb3dwYW4tbmQi IC8+IA0KPG1ldGEgbmFtZT0iREMuSWRlbnRpZmllciIgY29udGVudD0idXJuOmlldGY6aWQ6 aWV0Zi02bG93cGFuLW5kIiAvPiANCjxtZXRhIG5hbWU9IkRDLkRhdGUuSXNzdWVkIiBjb250 ZW50PSIyMDEwLTAyLTAxIiAvPiANCjxtZXRhIG5hbWU9IkRDLkNyZWF0b3IiIGNvbnRlbnQ9 Ik5vcmRtYXJrLCBFcmlrIiAvPiANCjxtZXRhIG5hbWU9IkRDLkNyZWF0b3IiIGNvbnRlbnQ9 IkJvcm1hbm4sIENhcnN0ZW4iIC8+IA0KPG1ldGEgbmFtZT0iREMuQ3JlYXRvciIgY29udGVu dD0iU2hlbGJ5LCBaYWNoIiAvPiANCjxtZXRhIG5hbWU9IkRDLkNyZWF0b3IiIGNvbnRlbnQ9 IkNoYWtyYWJhcnRpLCBTYW1pdGEiIC8+IA0KPG1ldGEgbmFtZT0iREMuQ3JlYXRvciIgY29u dGVudD0iVGh1YmVydCwgUGFzY2FsIiAvPiANCjxtZXRhIG5hbWU9IkRDLkNyZWF0b3IiIGNv bnRlbnQ9Ikh1aSwgSm9uYXRoYW4gVy4iIC8+IA0KPG1ldGEgbmFtZT0iREMuRGVzY3JpcHRp b24uQWJzdHJhY3QiIGNvbnRlbnQ9IlRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbmV3IE5l aWdoYm9yIERpc2NvdmVyeSBtZWNoYW5pc20gc3VpdGFibGVcbmZvciBMb1dQQU5zLiBUaGUg NkxvV1BBTiBmb3JtYXQgYWxsb3dzIElQdjYgdG8gYmUgdXNlZCBvdmVyIGVuZXJneSBhbmRc bmJhbmR3aWR0aCBjb25zdHJhaW5lZCB3aXJlbGVzcyBuZXR3b3JrcyBvZnRlbiBtYWtpbmcg dXNlIG9mIG11bHRpaG9wXG50b3BvbG9naWVzLiBIb3dldmVyLCB0aGUgdXNlIG9mIGNsYXNz aWMgSVB2NiBOZWlnaGJvciBEaXNjb3Zlcnkgd2l0aFxuNkxvV1BBTiBoYXMgc2V2ZXJhbCBw cm9ibGVtcy4gQ2xhc3NpYyBOZWlnaGJvciBEaXNjb3Zlcnkgd2FzIG5vdFxuZGVzaWduZWQg Zm9yIG5vbi10cmFuc2l0aXZlIHdpcmVsZXNzIGxpbmtzLCBhbmQgdGhlIHRyYWRpdGlvbmFs IElQdjZcbmxpbmsgY29uY2VwdCBhbmQgaGVhdnkgdXNlIG9mIG11bHRpY2FzdCBtYWtlcyBp dCB1bnByYWN0aWNhbC4gVGhpc1xuZG9jdW1lbnQgc3BlY2lmaWVzIGEgc2ltcGxlIE5laWdo Ym9yIERpc2NvdmVyeSBtZWNoYW5pc20gYm90aFxuc3VmZmljaWVudCB5ZXQgbWluaW1hbCBm b3IgTG9XUEFOIG9wZXJhdGlvbi4iIC8+IA0KPG1ldGEgbmFtZT0iREMuVGl0bGUiIGNvbnRl bnQ9IjZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5IiAvPiANCiANCiAgICA8bGluayByZWw9 Imljb24iIGhyZWY9Ii9pbWFnZXMvaWQucG5nIiB0eXBlPSJpbWFnZS9wbmciIC8+IA0KICAg IDxsaW5rIHJlbD0ic2hvcnRjdXQgaWNvbiIgaHJlZj0iL2ltYWdlcy9pZC5wbmciIHR5cGU9 ImltYWdlL3BuZyIgLz4gDQogICAgPHRpdGxlPmRyYWZ0LWlldGYtNmxvd3Bhbi1uZC0wOCAt IDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5PC90aXRsZT4gDQogICAgDQogICAgDQogICAg PHN0eWxlIHR5cGU9InRleHQvY3NzIj4gDQoJYm9keSB7DQoJICAgIG1hcmdpbjogMHB4IDhw eDsNCiAgICAgICAgICAgIGZvbnQtc2l6ZTogMWVtOw0KCX0NCiAgICAgICAgaDEsIGgyLCBo MywgaDQsIGg1LCBoNiwgLmgxLCAuaDIsIC5oMywgLmg0LCAuaDUsIC5oNiB7DQoJICAgIGZv bnQtd2VpZ2h0OiBib2xkOw0KICAgICAgICAgICAgbGluZS1oZWlnaHQ6IDBwdDsNCiAgICAg ICAgICAgIGRpc3BsYXk6IGlubGluZTsNCiAgICAgICAgICAgIHdoaXRlLXNwYWNlOiBwcmU7 DQogICAgICAgICAgICBmb250LWZhbWlseTogbW9ub3NwYWNlOw0KICAgICAgICAgICAgZm9u dC1zaXplOiAxZW07DQoJICAgIGZvbnQtd2VpZ2h0OiBib2xkOw0KICAgICAgICB9DQogICAg ICAgIHByZSB7DQogICAgICAgICAgICBmb250LXNpemU6IDFlbTsNCiAgICAgICAgICAgIG1h cmdpbi10b3A6IDBweDsNCiAgICAgICAgICAgIG1hcmdpbi1ib3R0b206IDBweDsNCiAgICAg ICAgfQ0KCS5wcmUgew0KCSAgICB3aGl0ZS1zcGFjZTogcHJlOw0KCSAgICBmb250LWZhbWls eTogbW9ub3NwYWNlOw0KCX0NCgkuaGVhZGVyew0KCSAgICBmb250LXdlaWdodDogYm9sZDsN Cgl9DQogICAgICAgIC5uZXdwYWdlIHsNCiAgICAgICAgICAgIHBhZ2UtYnJlYWstYmVmb3Jl OiBhbHdheXM7DQogICAgICAgIH0NCiAgICAgICAgLmludmlzaWJsZSB7DQogICAgICAgICAg ICB0ZXh0LWRlY29yYXRpb246IG5vbmU7DQogICAgICAgICAgICBjb2xvcjogd2hpdGU7DQog ICAgICAgIH0NCiAgICAgICAgQG1lZGlhIHByaW50IHsNCiAgICAgICAgICAgIGJvZHkgew0K ICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTAuNXB0Ow0KICAgICAgICAgICAgfQ0KICAg ICAgICAgICAgaDEsIGgyLCBoMywgaDQsIGg1LCBoNiB7DQogICAgICAgICAgICAgICAgZm9u dC1zaXplOiAxMC41cHQ7DQogICAgICAgICAgICB9DQogICAgICAgIA0KICAgICAgICAgICAg YTpsaW5rLCBhOnZpc2l0ZWQgew0KICAgICAgICAgICAgICAgIGNvbG9yOiBpbmhlcml0Ow0K ICAgICAgICAgICAgICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsNCiAgICAgICAgICAgIH0N CiAgICAgICAgICAgIC5ub3ByaW50IHsNCiAgICAgICAgICAgICAgICBkaXNwbGF5OiBub25l Ow0KICAgICAgICAgICAgfQ0KICAgICAgICB9DQoJQG1lZGlhIHNjcmVlbiB7DQoJICAgIC5n cmV5LCAuZ3JleSBhOmxpbmssIC5ncmV5IGE6dmlzaXRlZCB7DQoJCWNvbG9yOiAjNzc3Ow0K CSAgICB9DQogICAgICAgICAgICAuZG9jaW5mbyB7DQogICAgICAgICAgICAgICAgYmFja2dy b3VuZC1jb2xvcjogI0VFRTsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIC50b3Agew0K ICAgICAgICAgICAgICAgIGJvcmRlci10b3A6IDdweCBzb2xpZCAjRUVFOw0KICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgLmJnd2hpdGUgIHsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7 IH0NCiAgICAgICAgICAgIC5iZ3JlZCAgICB7IGJhY2tncm91bmQtY29sb3I6ICNGNDQ7IH0N CiAgICAgICAgICAgIC5iZ2dyZXkgICB7IGJhY2tncm91bmQtY29sb3I6ICM2NjY7IH0NCiAg ICAgICAgICAgIC5iZ2Jyb3duICB7IGJhY2tncm91bmQtY29sb3I6ICM4NDA7IH0gICAgICAg ICAgICANCiAgICAgICAgICAgIC5iZ29yYW5nZSB7IGJhY2tncm91bmQtY29sb3I6ICNGQTA7 IH0NCiAgICAgICAgICAgIC5iZ3llbGxvdyB7IGJhY2tncm91bmQtY29sb3I6ICNFRTA7IH0N CiAgICAgICAgICAgIC5iZ21hZ2VudGF7IGJhY2tncm91bmQtY29sb3I6ICNGNEY7IH0NCiAg ICAgICAgICAgIC5iZ2JsdWUgICB7IGJhY2tncm91bmQtY29sb3I6ICM2NkY7IH0NCiAgICAg ICAgICAgIC5iZ2N5YW4gICB7IGJhY2tncm91bmQtY29sb3I6ICM0REQ7IH0NCiAgICAgICAg ICAgIC5iZ2dyZWVuICB7IGJhY2tncm91bmQtY29sb3I6ICM0RjQ7IH0NCiANCiAgICAgICAg ICAgIC5sZWdlbmQgICB7IGZvbnQtc2l6ZTogOTAlOyB9DQogICAgICAgICAgICAuY3BsYXRl ICAgeyBmb250LXNpemU6IDcwJTsgYm9yZGVyOiBzb2xpZCBncmV5IDFweDsgfQ0KCX0NCiAg ICAuaGlsaXRlIHsNCiAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogI0ZGRkYwMDsNCiAgICB9 DQogICAgYS5jb21tZW50ew0KICAgICAgYmFja2dyb3VuZC1jb2xvcjogIzRERDsNCgkgIHRl eHQtZGVjb3JhdGlvbjpub25lDQogICAgfQ0KICAgIDwvc3R5bGU+IA0KICAgIDwhLS1baWYg SUVdPg0KICAgIDxzdHlsZT4NCiAgICBib2R5IHsNCiAgICAgICBmb250LXNpemU6IDEzcHg7 DQogICAgICAgbWFyZ2luOiAxMHB4IDEwcHg7DQogICAgfQ0KICAgIDwvc3R5bGU+DQogICAg PCFbZW5kaWZdLS0+IA0KIA0KICAgIDxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij48 IS0tDQogICAgZnVuY3Rpb24gYWRkSGVhZGVyVGFncygpIHsNCgl2YXIgc3BhbnMgPSBkb2N1 bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic3BhbiIpOw0KCWZvciAodmFyIGk9MDsgaSA8 IHNwYW5zLmxlbmd0aDsgaSsrKSB7DQoJICAgIHZhciBlbGVtID0gc3BhbnNbaV07DQoJICAg IGlmIChlbGVtKSB7DQoJCXZhciBsZXZlbCA9IGVsZW0uZ2V0QXR0cmlidXRlKCJjbGFzcyIp Ow0KICAgICAgICAgICAgICAgIGlmIChsZXZlbCA9PSAiaDEiIHx8IGxldmVsID09ICJoMiIg fHwgbGV2ZWwgPT0gImgzIiB8fCBsZXZlbCA9PSAiaDQiIHx8IGxldmVsID09ICJoNSIgfHwg bGV2ZWwgPT0gImg2Iikgew0KICAgICAgICAgICAgICAgICAgICBlbGVtLmlubmVySFRNTCA9 ICI8IitsZXZlbCsiPiIrZWxlbS5pbm5lckhUTUwrIjwvIitsZXZlbCsiPiI7CQkNCiAgICAg ICAgICAgICAgICB9DQoJICAgIH0NCgl9DQogICAgfQ0KICAgIHZhciBsZWdlbmRfaHRtbCA9 ICJDb2xvdXIgbGVnZW5kOjxiciAvPiAgICAgIDx0YWJsZT4gICAgICAgICA8dHI+PHRkPlVu a25vd246PC90ZD4gICAgICAgICAgPHRkPjxzcGFuIGNsYXNzPSdjcGxhdGUgYmd3aGl0ZSc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvdGQ+PC90cj4gICAgICAgICA8dHI+ PHRkPkRyYWZ0OjwvdGQ+ICAgICAgICAgICAgPHRkPjxzcGFuIGNsYXNzPSdjcGxhdGUgYmdy ZWQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3RkPjwvdHI+ICAgICAgICAg PHRyPjx0ZD5JbmZvcm1hdGlvbmFsOjwvdGQ+ICAgIDx0ZD48c3BhbiBjbGFzcz0nY3BsYXRl IGJnb3JhbmdlJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC90ZD48L3RyPiAg ICAgICAgIDx0cj48dGQ+RXhwZXJpbWVudGFsOjwvdGQ+ICAgICA8dGQ+PHNwYW4gY2xhc3M9 J2NwbGF0ZSBiZ3llbGxvdyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvdGQ+ PC90cj4gICAgICAgICA8dHI+PHRkPkJlc3QgQ29tbW9uIFByYWN0aWNlOjwvdGQ+PHRkPjxz cGFuIGNsYXNzPSdjcGxhdGUgYmdtYWdlbnRhJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 L3NwYW4+PC90ZD48L3RyPiAgICAgICAgIDx0cj48dGQ+UHJvcG9zZWQgU3RhbmRhcmQ6PC90 ZD48dGQ+PHNwYW4gY2xhc3M9J2NwbGF0ZSBiZ2JsdWUnPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzwvc3Bhbj48L3RkPjwvdHI+ICAgICAgICAgPHRyPjx0ZD5EcmFmdCBTdGFuZGFyZDo8 L3RkPiAgIDx0ZD48c3BhbiBjbGFzcz0nY3BsYXRlIGJnY3lhbic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9zcGFuPjwvdGQ+PC90cj4gICAgICAgICA8dHI+PHRkPlN0YW5kYXJkOjwv dGQ+ICAgICAgICAgPHRkPjxzcGFuIGNsYXNzPSdjcGxhdGUgYmdncmVlbic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvdGQ+PC90cj4gICAgICAgICA8dHI+PHRkPkhpc3Rv cmljOjwvdGQ+ICAgICAgICAgPHRkPjxzcGFuIGNsYXNzPSdjcGxhdGUgYmdncmV5Jz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC90ZD48L3RyPiAgICAgICAgIDx0cj48dGQ+ T2Jzb2xldGU6PC90ZD4gICAgICAgICA8dGQ+PHNwYW4gY2xhc3M9J2NwbGF0ZSBiZ2Jyb3du Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC90ZD48L3RyPiAgICAgPC90YWJs ZT4iOw0KICAgIGZ1bmN0aW9uIHNob3dFbGVtKGlkKSB7DQogICAgICAgIHZhciBlbGVtID0g ZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoaWQpOw0KICAgICAgICBlbGVtLmlubmVySFRNTCA9 IGV2YWwoaWQrIl9odG1sIik7DQogICAgICAgIGVsZW0uc3R5bGUudmlzaWJpbGl0eT0ndmlz aWJsZSc7DQogICAgfQ0KICAgIGZ1bmN0aW9uIGhpZGVFbGVtKGlkKSB7DQogICAgICAgIHZh ciBlbGVtID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoaWQpOw0KICAgICAgICBlbGVtLnN0 eWxlLnZpc2liaWxpdHk9J2hpZGRlbic7ICAgICAgICANCiAgICAgICAgZWxlbS5pbm5lckhU TUwgPSAiIjsNCiAgICB9DQogICAgLy8gLS0+DQogICAgPC9zY3JpcHQ+IA0KPC9oZWFkPiAN Cjxib2R5IG9ubG9hZD0iYWRkSGVhZGVyVGFncygpIj4gDQogICA8ZGl2IHN0eWxlPSJoZWln aHQ6IDEzcHg7Ij4gDQogICAgICA8ZGl2IG9ubW91c2VvdmVyPSJ0aGlzLnN0eWxlLmN1cnNv cj0ncG9pbnRlcic7Ig0KICAgICAgICAgb25jbGljaz0ic2hvd0VsZW0oJ2xlZ2VuZCcpOyIN CiAgICAgICAgIG9ubW91c2VvdXQ9ImhpZGVFbGVtKCdsZWdlbmQnKSINCgkgc3R5bGU9Imhl aWdodDogNnB4OyBwb3NpdGlvbjogYWJzb2x1dGU7Ig0KICAgICAgICAgY2xhc3M9InByZSBu b3ByaW50IGRvY2luZm8gYmdyZWQiDQogICAgICAgICB0aXRsZT0iQ2xpY2sgZm9yIGNvbG91 ciBsZWdlbmQuIiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+IA0KICAgICAgPGRpdiBpZD0i bGVnZW5kIg0KICAgICAgICAgICBjbGFzcz0iZG9jaW5mbyBub3ByaW50IHByZSBsZWdlbmQi DQogICAgICAgICAgIHN0eWxlPSJwb3NpdGlvbjphYnNvbHV0ZTsgdG9wOiA0cHg7IGxlZnQ6 IDRleDsgdmlzaWJpbGl0eTpoaWRkZW47IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyBwYWRk aW5nOiA0cHggOXB4IDVweCA3cHg7IGJvcmRlcjogc29saWQgIzM0NSAxcHg7ICINCiAgICAg ICAgICAgb25tb3VzZW92ZXI9InNob3dFbGVtKCdsZWdlbmQnKTsiDQogICAgICAgICAgIG9u bW91c2VvdXQ9ImhpZGVFbGVtKCdsZWdlbmQnKTsiPiANCiAgICAgIDwvZGl2PiANCiAgIDwv ZGl2PiANCjxzcGFuIGNsYXNzPSJwcmUgbm9wcmludCBkb2NpbmZvIHRvcCI+WzxhIGhyZWY9 Ii4uL2h0bWwvIiB0aXRsZT0iRG9jdW1lbnQgc2VhcmNoIGFuZCByZXRyaWV2YWwgcGFnZSI+ RG9jczwvYT5dIFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0 Zi02bG93cGFuLW5kLTA4LnR4dCIgdGl0bGU9IlBsYWludGV4dCB2ZXJzaW9uIG9mIHRoaXMg ZG9jdW1lbnQiPnR4dDwvYT5dIFs8YSBocmVmPSIvcGRmL2RyYWZ0LWlldGYtNmxvd3Bhbi1u ZC0wOC50eHQiIHRpdGxlPSJQREYgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50Ij5wZGY8L2E+ XSBbPGEgaHJlZj0iLi4vd2cvNmxvd3BhbiIgdGl0bGU9IlRoZSB3b3JraW5nIGdyb3VwIGhh bmRsaW5nIHRoaXMgZG9jdW1lbnQiPldHPC9hPl0gWzxhIGhyZWY9Im1haWx0bzpkcmFmdC1p ZXRmLTZsb3dwYW4tbmRAdG9vbHMuaWV0Zi5vcmc/c3ViamVjdD1kcmFmdC1pZXRmLTZsb3dw YW4tbmQlMjAiIHRpdGxlPSJTZW5kIGVtYWlsIHRvIHRoZSBkb2N1bWVudCBhdXRob3JzIj5F bWFpbDwvYT5dIFs8YSBocmVmPSIvcmZjZGlmZj9kaWZmdHlwZT0tLWh3ZGlmZiZhbXA7dXJs Mj1kcmFmdC1pZXRmLTZsb3dwYW4tbmQtMDgudHh0IiB0aXRsZT0iSW5saW5lIGRpZmYgKHdk aWZmKSI+RGlmZjE8L2E+XSBbPGEgaHJlZj0iL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLTZs b3dwYW4tbmQtMDgudHh0IiB0aXRsZT0iU2lkZS1ieS1zaWRlIGRpZmYiPkRpZmYyPC9hPl0g WzxhIGhyZWY9Ii9pZG5pdHM/dXJsPWh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1p ZXRmLTZsb3dwYW4tbmQtMDgudHh0IiB0aXRsZT0iUnVuIGFuIGlkbml0cyBjaGVjayBvZiB0 aGlzIGRvY3VtZW50Ij5OaXRzPC9hPl0gICAgICAgICAgICAgICAgICA8L3NwYW4+PGJyIC8+ IA0KPHNwYW4gY2xhc3M9InByZSBub3ByaW50IGRvY2luZm8iPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvc3Bhbj48YnIgLz4gDQo8c3BhbiBjbGFzcz0icHJlIG5vcHJpbnQgZG9jaW5mbyI+VmVy c2lvbnM6ICg8YSBocmVmPSIuL2RyYWZ0LWh1aS02bG93cGFuLW5kIiB0aXRsZT0iUHJlY3Vy c29yIj5kcmFmdC1odWktNmxvd3Bhbi1uZDwvYT4pICA8YSBocmVmPSIuL2RyYWZ0LWlldGYt Nmxvd3Bhbi1uZC0wMCI+MDA8L2E+IDxhIGhyZWY9Ii4vZHJhZnQtaWV0Zi02bG93cGFuLW5k LTAxIj4wMTwvYT4gPGEgaHJlZj0iLi9kcmFmdC1pZXRmLTZsb3dwYW4tbmQtMDIiPjAyPC9h PiA8YSBocmVmPSIuL2RyYWZ0LWlldGYtNmxvd3Bhbi1uZC0wMyI+MDM8L2E+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgPGEgaHJlZj0iLi9kcmFmdC1pZXRmLTZs b3dwYW4tbmQtMDQiPjA0PC9hPiA8YSBocmVmPSIuL2RyYWZ0LWlldGYtNmxvd3Bhbi1uZC0w NSI+MDU8L2E+IDxhIGhyZWY9Ii4vZHJhZnQtaWV0Zi02bG93cGFuLW5kLTA2Ij4wNjwvYT4g PGEgaHJlZj0iLi9kcmFmdC1pZXRmLTZsb3dwYW4tbmQtMDciPjA3PC9hPiA8YSBocmVmPSIu L2RyYWZ0LWlldGYtNmxvd3Bhbi1uZC0wOCI+MDg8L2E+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjxiciAvPiANCjxzcGFuIGNsYXNz PSJwcmUgbm9wcmludCBkb2NpbmZvIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PGJyIC8+ IA0KPHByZT4gDQo2bG93cGFuIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgWi4gU2hlbGJ5LCBFZC4NCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlbnNpbm9kZQ0KVXBk YXRlczogPGEgaHJlZj0iLi9yZmM0OTQ0Ij40OTQ0PC9hPiAoaWYgYXBwcm92ZWQpICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQLiBUaHViZXJ0DQpJbnRlbmRlZCBzdGF0 dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Q2lzY28NCkV4cGlyZXM6IEF1Z3VzdCA1LCAyMDEwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEouIEh1aQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXJjaCBSb2NrDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4g Q2hha3JhYmFydGkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBJUCBJbmZ1c2lvbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDLiBCb3JtYW5uDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVW5pdmVy c2l0YWV0IEJyZW1lbiBUWkkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBFLiBOb3JkbWFyaw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg U3VuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEZlYnJ1YXJ5IDEsIDIwMTANCiANCiANCiAgICAgICAgICAgICAgICAgICAgICAg NkxvV1BBTiBOZWlnaGJvciBEaXNjb3ZlcnkNCiAgICAgICAgICAgICAgICAgICAgICAgIDxh IGhyZWY9Ii4vZHJhZnQtaWV0Zi02bG93cGFuLW5kLTA4Ij5kcmFmdC1pZXRmLTZsb3dwYW4t bmQtMDg8L2E+IA0KIA0KQWJzdHJhY3QNCiANCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IGEgbmV3IE5laWdoYm9yIERpc2NvdmVyeSBtZWNoYW5pc20gc3VpdGFibGUNCiAgIGZvciBM b1dQQU5zLiAgVGhlIDZMb1dQQU4gZm9ybWF0IGFsbG93cyBJUHY2IHRvIGJlIHVzZWQgb3Zl ciBlbmVyZ3kNCiAgIGFuZCBiYW5kd2lkdGggY29uc3RyYWluZWQgd2lyZWxlc3MgbmV0d29y a3Mgb2Z0ZW4gbWFraW5nIHVzZSBvZg0KICAgbXVsdGlob3AgdG9wb2xvZ2llcy4gIEhvd2V2 ZXIsIHRoZSB1c2Ugb2YgY2xhc3NpYyBJUHY2IE5laWdoYm9yDQogICBEaXNjb3Zlcnkgd2l0 aCA2TG9XUEFOIGhhcyBzZXZlcmFsIHByb2JsZW1zLiAgQ2xhc3NpYyBOZWlnaGJvcg0KICAg RGlzY292ZXJ5IHdhcyBub3QgZGVzaWduZWQgZm9yIG5vbi10cmFuc2l0aXZlIHdpcmVsZXNz IGxpbmtzLCBhbmQgdGhlDQogICB0cmFkaXRpb25hbCBJUHY2IGxpbmsgY29uY2VwdCBhbmQg aGVhdnkgdXNlIG9mIG11bHRpY2FzdCBtYWtlcyBpdA0KICAgdW5wcmFjdGljYWwuICBUaGlz IGRvY3VtZW50IHNwZWNpZmllcyBhIHNpbXBsZSBOZWlnaGJvciBEaXNjb3ZlcnkNCiAgIG1l Y2hhbmlzbSBib3RoIHN1ZmZpY2llbnQgeWV0IG1pbmltYWwgZm9yIExvV1BBTiBvcGVyYXRp b24uDQogDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQogDQogICBUaGlzIEludGVybmV0LURyYWZ0 IGlzIHN1Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUNCiAg IHByb3Zpc2lvbnMgb2YgPGEgaHJlZj0iLi9iY3A3OCI+QkNQIDc4PC9hPiBhbmQgPGEgaHJl Zj0iLi9iY3A3OSI+QkNQIDc5PC9hPi4NCiANCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZv cmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0 aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCiANCiAgIEludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0K ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQogDQogICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIDxh IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCI+aHR0 cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0PC9hPi4NCiANCiANCiAN CiANCjxzcGFuIGNsYXNzPSJncmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJl cyBBdWd1c3QgNSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMV08L3NwYW4+IA0KPC9w cmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+PGEgbmFtZT0icGFnZS0yIiBpZD0icGFnZS0yIiBo cmVmPSIjcGFnZS0yIiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJn cmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5 ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAgPHNwYW4gY2xhc3M9 ImgxIj5UaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2Fu IGJlIGFjY2Vzc2VkIGF0PC9zcGFuPiANCiAgIDxzcGFuIGNsYXNzPSJoMSI+aHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC48L3NwYW4+IA0KIA0KICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiBBdWd1c3QgNSwgMjAxMC4NCiANCkNvcHlyaWdodCBOb3Rp Y2UNCiANCiAgIENvcHlyaWdodCAoYykgMjAxMCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29u cyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuDQogDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gPGEgaHJlZj0i Li9iY3A3OCI+QkNQIDc4PC9hPiBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KICAgUHJv dmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAgKDxhIGhyZWY9Imh0dHA6 Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbyI+aHR0cDovL3RydXN0ZWUuaWV0Zi5v cmcvbGljZW5zZS1pbmZvPC9hPikgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBwdWJs aWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVu dHMNCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVz dHJpY3Rpb25zIHdpdGggcmVzcGVjdA0KICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29t cG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUg U2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiA8YSBocmVmPSIj c2VjdGlvbi00Ij5TZWN0aW9uIDQ8L2E+LmUgb2YNCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92 aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcw0KICAgZGVzY3Jp YmVkIGluIHRoZSBCU0QgTGljZW5zZS4NCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN CiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN CiANCiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMl08L3Nw YW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+PGEgbmFtZT0icGFnZS0zIiBpZD0i cGFnZS0zIiBocmVmPSIjcGFnZS0zIiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxzcGFu IGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hib3Ig RGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KVGFibGUg b2YgQ29udGVudHMNCiANCiAgIDxhIGhyZWY9IiNzZWN0aW9uLTEiPjE8L2E+LiAgSW50cm9k dWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDxhIGhyZWY9IiNwYWdlLTQiPjQ8L2E+IA0KICAgICA8YSBocmVmPSIjc2VjdGlvbi0x LjEiPjEuMTwvYT4uICBHb2FscywgQXNzdW1wdGlvbnMsIGFuZCBHdWVzc2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA8YSBocmVmPSIjcGFnZS01Ij41PC9hPiANCiAgICAgPGEg aHJlZj0iI3NlY3Rpb24tMS4yIj4xLjI8L2E+LiAgV2h5IG5vdCBjbGFzc2ljIElQdjYgTkQ/ IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPGEgaHJlZj0iI3BhZ2UtNSI+ NTwvYT4gDQogICA8YSBocmVmPSIjc2VjdGlvbi0yIj4yPC9hPi4gIFRlcm1pbm9sb2d5ICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8YSBo cmVmPSIjcGFnZS02Ij42PC9hPiANCiAgICAgPGEgaHJlZj0iI3NlY3Rpb24tMi4xIj4yLjE8 L2E+LiAgNkxvV1BBTiBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgPGEgaHJlZj0iI3BhZ2UtNyI+NzwvYT4gDQogICAgIDxhIGhyZWY9IiNz ZWN0aW9uLTIuMiI+Mi4yPC9hPi4gIE5EIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxhIGhyZWY9IiNwYWdlLTkiPjk8L2E+IA0K ICAgPGEgaHJlZj0iI3NlY3Rpb24tMyI+MzwvYT4uICBQcm90b2NvbCBPdmVydmlldyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBocmVmPSIjcGFn ZS0xMCI+MTA8L2E+IA0KICAgICA8YSBocmVmPSIjc2VjdGlvbi0zLjEiPjMuMTwvYT4uICBU b3BvbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDxhIGhyZWY9IiNwYWdlLTExIj4xMTwvYT4gDQogICAgIDxhIGhyZWY9IiNzZWN0aW9u LTMuMiI+My4yPC9hPi4gIEJvb3RzdHJhcHBpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEgaHJlZj0iI3BhZ2UtMTIiPjEyPC9hPiANCiAgICAg PGEgaHJlZj0iI3NlY3Rpb24tMy4zIj4zLjM8L2E+LiAgT3BlcmF0aW9uICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBocmVmPSIjcGFnZS0x MyI+MTM8L2E+IA0KICAgPGEgaHJlZj0iI3NlY3Rpb24tNCI+NDwvYT4uICBNZXNzYWdlIEZv cm1hdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8 YSBocmVmPSIjcGFnZS0xMyI+MTM8L2E+IA0KICAgICA8YSBocmVmPSIjc2VjdGlvbi00LjEi PjQuMTwvYT4uICBOb2RlIFJlZ2lzdHJhdGlvbi9Db25maXJtYXRpb24gTWVzc2FnZSAuIC4g LiAuIC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTE0Ij4xNDwvYT4gDQogICAgIDxhIGhy ZWY9IiNzZWN0aW9uLTQuMiI+NC4yPC9hPi4gIFJvdXRlciBTb2xpY2l0YXRpb24gTWVzc2Fn ZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEgaHJlZj0iI3BhZ2UtMTYiPjE2 PC9hPiANCiAgICAgPGEgaHJlZj0iI3NlY3Rpb24tNC4zIj40LjM8L2E+LiAgUm91dGVyIEFk dmVydGlzZW1lbnQgTWVzc2FnZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBo cmVmPSIjcGFnZS0xNyI+MTc8L2E+IA0KICAgICA8YSBocmVmPSIjc2VjdGlvbi00LjQiPjQu NDwvYT4uICBNZXNzYWdlIE9wdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTE4Ij4xODwvYT4gDQogICAgICAgPGEgaHJl Zj0iI3NlY3Rpb24tNC40LjEiPjQuNC4xPC9hPi4gIDZMb1dQQU4gQWRkcmVzcyBPcHRpb24g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBocmVmPSIjcGFnZS0xOCI+MTg8 L2E+IA0KICAgICAgIDxhIGhyZWY9IiNzZWN0aW9uLTQuNC4yIj40LjQuMjwvYT4uICA2TG9X UEFOIEluZm9ybWF0aW9uIE9wdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEg aHJlZj0iI3BhZ2UtMTkiPjE5PC9hPiANCiAgICAgICA8YSBocmVmPSIjc2VjdGlvbi00LjQu MyI+NC40LjM8L2E+LiAgNkxvV1BBTiBTdW1tYXJ5IE9wdGlvbiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTIxIj4yMTwvYT4gDQogICAgICAgPGEg aHJlZj0iI3NlY3Rpb24tNC40LjQiPjQuNC40PC9hPi4gIE93bmVyIEludGVyZmFjZSBJZGVu dGlmaWVyIE9wdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBocmVmPSIjcGFnZS0yMiI+ MjI8L2E+IA0KICAgPGEgaHJlZj0iI3NlY3Rpb24tNSI+NTwvYT4uICBQcm90b2NvbCBTcGVj aWZpY2F0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBo cmVmPSIjcGFnZS0yMyI+MjM8L2E+IA0KICAgICA8YSBocmVmPSIjc2VjdGlvbi01LjEiPjUu MTwvYT4uICBJbnRlcmZhY2UgaW5pdGlhbGl6YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTIzIj4yMzwvYT4gDQogICAgIDxhIGhyZWY9 IiNzZWN0aW9uLTUuMiI+NS4yPC9hPi4gIE5vZGUgUmVnaXN0cmF0aW9uICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEgaHJlZj0iI3BhZ2UtMjQiPjI0PC9h PiANCiAgICAgICA8YSBocmVmPSIjc2VjdGlvbi01LjIuMSI+NS4yLjE8L2E+LiAgUHJvY2Vz c2luZyBhIE5vZGUgUmVnaXN0cmF0aW9uIE1lc3NhZ2UgLiAuIC4gLiAuIC4gLiAuIDxhIGhy ZWY9IiNwYWdlLTI1Ij4yNTwvYT4gDQogICAgICAgPGEgaHJlZj0iI3NlY3Rpb24tNS4yLjIi PjUuMi4yPC9hPi4gIFByb2Nlc3NpbmcgYSBOb2RlIENvbmZpcm1hdGlvbiBNZXNzYWdlIC4g LiAuIC4gLiAuIC4gLiA8YSBocmVmPSIjcGFnZS0yNSI+MjU8L2E+IA0KICAgICA8YSBocmVm PSIjc2VjdGlvbi01LjMiPjUuMzwvYT4uICBEdXBsaWNhdGUgQWRkcmVzcyBEZXRlY3Rpb24g IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTI2Ij4yNjwv YT4gDQogICAgIDxhIGhyZWY9IiNzZWN0aW9uLTUuNCI+NS40PC9hPi4gIE5leHQtaG9wIERl dGVybWluYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEgaHJl Zj0iI3BhZ2UtMjciPjI3PC9hPiANCiAgICAgPGEgaHJlZj0iI3NlY3Rpb24tNS41Ij41LjU8 L2E+LiAgQWRkcmVzcyBSZXNvbHV0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA8YSBocmVmPSIjcGFnZS0yNyI+Mjc8L2E+IA0KICAgICA8YSBocmVmPSIj c2VjdGlvbi01LjYiPjUuNjwvYT4uICBVbnJlYWNoYWJpbGl0eSBEZXRlY3Rpb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTI4Ij4yODwvYT4g DQogICAgIDxhIGhyZWY9IiNzZWN0aW9uLTUuNyI+NS43PC9hPi4gIENvbnRleHQgRGlzc2Vt aW5hdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEgaHJlZj0i I3BhZ2UtMjgiPjI4PC9hPiANCiAgIDxhIGhyZWY9IiNzZWN0aW9uLTYiPjY8L2E+LiAgPHNw YW4gY2xhc3M9aGlsaXRlPk5vZGU8L3NwYW4+IFNwZWNpZmljYXRpb24gIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTI5Ij4yOTwvYT4gDQog ICAgIDxhIGhyZWY9IiNzZWN0aW9uLTYuMSI+Ni4xPC9hPi4gIENvbmNlcHR1YWwgc3RydWN0 dXJlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEgaHJlZj0iI3Bh Z2UtMjkiPjI5PC9hPiANCiAgICAgPGEgaHJlZj0iI3NlY3Rpb24tNi4yIj42LjI8L2E+LiAg Q29uY2VwdHVhbCB2YXJpYWJsZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA8YSBocmVmPSIjcGFnZS0zMCI+MzA8L2E+IA0KICAgPGEgaHJlZj0iI3NlY3Rpb24t NyI+NzwvYT4uICA8c3BhbiBjbGFzcz1oaWxpdGU+Um91dGVyPC9zcGFuPiBTcGVjaWZpY2F0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEgaHJlZj0iI3BhZ2Ut MzAiPjMwPC9hPiANCiAgICAgPGEgaHJlZj0iI3NlY3Rpb24tNy4xIj43LjE8L2E+LiAgUm91 dGVyIENvbmZpZ3VyYXRpb24gVmFyaWFibGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA8YSBocmVmPSIjcGFnZS0zMCI+MzA8L2E+IA0KICAgICA8YSBocmVmPSIjc2VjdGlvbi03 LjIiPjcuMjwvYT4uICBCZWNvbWluZyBhbiBBZHZlcnRpc2luZyBJbnRlcmZhY2UgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTMwIj4zMDwvYT4gDQogICAgIDxh IGhyZWY9IiNzZWN0aW9uLTcuMyI+Ny4zPC9hPi4gIFJvdXRlciBBZHZlcnRpc2VtZW50IE1l c3NhZ2UgQ29udGVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEgaHJlZj0iI3BhZ2UtMzEi PjMxPC9hPiANCiAgICAgPGEgaHJlZj0iI3NlY3Rpb24tNy40Ij43LjQ8L2E+LiAgU2VuZGlu ZyBVbnNvbGljaXRlZCBSb3V0ZXIgQWR2ZXJ0aXNlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiA8 YSBocmVmPSIjcGFnZS0zMiI+MzI8L2E+IA0KICAgICA8YSBocmVmPSIjc2VjdGlvbi03LjUi PjcuNTwvYT4uICBDZWFzaW5nIFRvIEJlIGFuIEFkdmVydGlzaW5nIEludGVyZmFjZSAuIC4g LiAuIC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTMyIj4zMjwvYT4gDQogICAgIDxhIGhy ZWY9IiNzZWN0aW9uLTcuNiI+Ny42PC9hPi4gIFByb2Nlc3NpbmcgUm91dGVyIFNvbGljaXRh dGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEgaHJlZj0iI3BhZ2UtMzIiPjMy PC9hPiANCiAgICAgPGEgaHJlZj0iI3NlY3Rpb24tNy43Ij43Ljc8L2E+LiAgQmluZGluZyBU YWJsZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBo cmVmPSIjcGFnZS0zMiI+MzI8L2E+IA0KICAgPGEgaHJlZj0iI3NlY3Rpb24tOCI+ODwvYT4u ICBBZC1ob2MgTG9XUEFOICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA8YSBocmVmPSIjcGFnZS0zMiI+MzI8L2E+IA0KICAgPGEgaHJlZj0iI3Nl Y3Rpb24tOSI+OTwvYT4uICBQcm90b2NvbCBDb25zdGFudHMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBocmVmPSIjcGFnZS0zMyI+MzM8L2E+IA0K ICAgPGEgaHJlZj0iI3NlY3Rpb24tMTAiPjEwPC9hPi4gVXNlIG9mIDZMb1dQQU4tTkQgdW5k ZXIgPGEgaHJlZj0iLi9yZmM0ODYxIj5SRkM0ODYxPC9hPi1vbmx5IHN0YWNrcyAgLiAuIC4g LiAuIC4gLiAuIC4gPGEgaHJlZj0iI3BhZ2UtMzQiPjM0PC9hPiANCiAgIDxhIGhyZWY9IiNz ZWN0aW9uLTExIj4xMTwvYT4uIE1lc3NhZ2UgRXhhbXBsZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTM0Ij4zNDwvYT4g DQogICAgIDxhIGhyZWY9IiNzZWN0aW9uLTExLjEiPjExLjE8L2E+LiBOUi9OQyBtZXNzYWdl IGV4Y2hhbmdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxhIGhyZWY9 IiNwYWdlLTM0Ij4zNDwvYT4gDQogICAgIDxhIGhyZWY9IiNzZWN0aW9uLTExLjIiPjExLjI8 L2E+LiBSb3V0ZXIgYWR2ZXJ0aXNlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTM2Ij4zNjwvYT4gDQogDQogDQogDQo8c3BhbiBj bGFzcz0iZ3JleSI+U2hlbGJ5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUs IDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDNdPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xh c3M9J25ld3BhZ2UnPjxhIG5hbWU9InBhZ2UtNCIgaWQ9InBhZ2UtNCIgaHJlZj0iI3BhZ2Ut NCIgY2xhc3M9ImludmlzaWJsZSI+IDwvYT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJu ZXQtRHJhZnQgICAgICAgICA2TG9XUEFOIE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBG ZWJydWFyeSAyMDEwPC9zcGFuPiANCiANCiANCiAgIDxhIGhyZWY9IiNzZWN0aW9uLTEyIj4x MjwvYT4uIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTM3Ij4zNzwvYT4gDQogICA8YSBocmVm PSIjc2VjdGlvbi0xMyI+MTM8L2E+LiBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBocmVmPSIjcGFnZS0zOCI+Mzg8 L2E+IA0KICAgPGEgaHJlZj0iI3NlY3Rpb24tMTQiPjE0PC9hPi4gQWNrbm93bGVkZ21lbnRz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPGEgaHJl Zj0iI3BhZ2UtMzgiPjM4PC9hPiANCiAgIDxhIGhyZWY9IiNzZWN0aW9uLTE1Ij4xNTwvYT4u IENoYW5nZWxvZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDxhIGhyZWY9IiNwYWdlLTM4Ij4zODwvYT4gDQogICA8YSBocmVmPSIjc2Vj dGlvbi0xNiI+MTY8L2E+LiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBocmVmPSIjcGFnZS00MiI+NDI8L2E+IA0K ICAgICA8YSBocmVmPSIjc2VjdGlvbi0xNi4xIj4xNi4xPC9hPi4gTm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8YSBocmVmPSIj cGFnZS00MiI+NDI8L2E+IA0KICAgICA8YSBocmVmPSIjc2VjdGlvbi0xNi4yIj4xNi4yPC9h Pi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA8YSBocmVmPSIjcGFnZS00MyI+NDM8L2E+IA0KICAgQXV0aG9ycycgQWRkcmVz c2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxh IGhyZWY9IiNwYWdlLTQ0Ij40NDwvYT4gDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQo8c3BhbiBj bGFzcz0iZ3JleSI+U2hlbGJ5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUs IDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDRdPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xh c3M9J25ld3BhZ2UnPjxhIG5hbWU9InBhZ2UtNSIgaWQ9InBhZ2UtNSIgaHJlZj0iI3BhZ2Ut NSIgY2xhc3M9ImludmlzaWJsZSI+IDwvYT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJu ZXQtRHJhZnQgICAgICAgICA2TG9XUEFOIE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBG ZWJydWFyeSAyMDEwPC9zcGFuPiANCiANCiANCjxzcGFuIGNsYXNzPSJoMiI+PGEgbmFtZT0i c2VjdGlvbi0xIj4xPC9hPi4gIEludHJvZHVjdGlvbjwvc3Bhbj4gDQogDQogICBUaGUgSVB2 NiBvdmVyIElFRUUgODAyLjE1LjQgWzxhIGhyZWY9Ii4vcmZjNDk0NCIgdGl0bGU9JyJUcmFu c21pc3Npb24gb2YgSVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTUuNCBOZXR3b3JrcyIn PlJGQzQ5NDQ8L2E+XSBkb2N1bWVudCBoYXMgc3BlY2lmaWVkIGhvdyB0bw0KICAgY2Fycnkg SVB2NiBwYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTUuNCBhbmQgc2ltaWxhciBuZXR3b3JrcyAo NkxvV1BBTnMNCiAgIG9yIExvV1BBTnMgZm9yIHNob3J0KSB3aXRoIHRoZSBoZWxwIG9mIGFu IGFkYXB0YXRpb24gaGVhZGVyIHdoaWNoDQogICBjb21lcyBiZWZvcmUgdGhlIElQIGhlYWRl ci4gIEEgbGluayBpbiBzdWNoIGEgNkxvV1BBTiBpcw0KICAgY2hhcmFjdGVyaXplZCBhcyBs b3NzeSwgbG93LXBvd2VyLCBsb3cgYml0LXJhdGUsIHNob3J0IHJhbmdlLCB3aXRoDQogICBt YW55IG5vZGVzIHNhdmluZyBlbmVyZ3kgd2l0aCBsb25nIGRlZXAgc2xlZXAgcGVyaW9kcy4g IE11bHRpY2FzdCBhcw0KICAgdXNlZCBpbiBjbGFzc2ljIElQdjYgTmVpZ2hib3IgRGlzY292 ZXJ5IFs8YSBocmVmPSIuL3JmYzQ4NjEiIHRpdGxlPSciTmVpZ2hib3IgRGlzY292ZXJ5IGZv ciBJUCB2ZXJzaW9uIDYgKElQdjYpIic+UkZDNDg2MTwvYT5dIGlzIG5vdCBkZXNpcmFibGUg aW4NCiAgIHN1Y2ggYSB3aXJlbGVzcyBsb3ctcG93ZXIsIGxvc3N5IG5ldHdvcmsuDQogDQog ICBNb3Jlb3ZlciwgTG9XUEFOIGxpbmtzIGFyZSBhc3ltbWV0cmljIGFuZCBub24tdHJhbnNp ZW50IGluIG5hdHVyZTsNCiAgIHRoZXkgYXJlIG5vdCBhbHdheXMgY29uc2lkZXJlZCB0byBi ZSBpbiBhIGZpeGVkIG5ldHdvcmsgbm9yIGFyZSB0aGV5DQogICBib3VuZGVkIGJ5IG91ciB0 cmFkaXRpb25hbCBkZWZpbml0aW9uIG9mIGEgd2lyZWQtbGluay4gIEEgTG9XUEFOIGlzDQog ICBwb3RlbnRpYWxseSBjb21wb3NlZCBvZiBhIGxhcmdlIGFtb3VudCBvZiBvdmVybGFwcGlu ZyByYWRpbyByYW5nZXMsDQogICBldmVudHVhbGx5IGZlZGVyYXRlZCBieSBhIGJhY2tib25l IG9yIGEgYmFja2hhdWwgbGluay4gIEFsdGhvdWdoIGENCiAgIGdpdmVuIHJhZGlvIHJhbmdl IGhhcyBicm9hZGNhc3QgY2FwYWJpbGl0aWVzLCB0aGUgYWdncmVnYXRpb24gb2YNCiAgIHRo ZXNlIGlzIGEgY29tcGxleCBOb24tQnJvYWRjYXN0IE11bHRpQWNjZXNzIChOQk1BLCBbPGEg aHJlZj0iLi9yZmMyNDkxIiB0aXRsZT0nIklQdjYgb3ZlciBOb24tQnJvYWRjYXN0IE11bHRp cGxlIEFjY2VzcyAoTkJNQSkgbmV0d29ya3MiJz5SRkMyNDkxPC9hPl0pDQogICBzdHJ1Y3R1 cmUgd2l0aCAoZ2VuZXJhbGx5KSBubyBMb1dQQU4td2lkZSBtdWx0aWNhc3QgY2FwYWJpbGl0 aWVzLg0KICAgbGluay1sb2NhbCBzY29wZSBpcyBpbiByZWFsaXR5IGRlZmluZWQgYnkgcmVh Y2hhYmlsaXR5IGFuZCByYWRpbw0KICAgc3RyZW5ndGguICBUaHVzIHdlIGNhbiBjb25zaWRl ciBhIExvV1BBTiB0byBiZSBtYWRlIHVwIG9mIGxpbmtzIHdpdGgNCiAgIHVuZGV0ZXJtaW5l ZCBjb25uZWN0aXZpdHkgcHJvcGVydGllcyBhcyBkZWZpbmVkIGluDQogICBbPGEgaHJlZj0i I3JlZi1JLUQuaWV0Zi1hdXRvY29uZi1hZGhvYy1hZGRyLW1vZGVsIiB0aXRsZT0nIklQIEFk ZHJlc3NpbmcgTW9kZWwgaW4gQWQgSG9jIE5ldHdvcmtzIic+SS1ELmlldGYtYXV0b2NvbmYt YWRob2MtYWRkci1tb2RlbDwvYT5dLCBhbG9uZyB3aXRoIHRoZSBjb3JyZXNwb25kaW5nDQog ICBhc3N1bXB0aW9ucyBkZWZpbmVkIHRoZXJlaW4uICBUaGUgY2xhc3NpYyBJUHY2IE5laWdo Ym9yIERpc2NvdmVyeQ0KICAgWzxhIGhyZWY9Ii4vcmZjNDg2MSIgdGl0bGU9JyJOZWlnaGJv ciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiJz5SRkM0ODYxPC9hPl0gY29u dHJvbCBtZXNzYWdlcywgdGhlIHVzZSBvZiBtdWx0aWNhc3QgYW5kIHRoZWlyIGRlZmF1bHQN CiAgIGZyZXF1ZW5jeSBhbHNvIGF0dHJpYnV0ZSB0byB1bm5lY2Vzc2FyeSB3YXN0ZSBvZiBl bmVyZ3kgaW4gTG9XUEFOcy4NCiANCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBpbnRyb2R1Y2Vz IGEgbmV3IG1lY2hhbmlzbSBjYWxsZWQgTm9kZQ0KICAgUmVnaXN0cmF0aW9uLCB1c2VkIHRv IG9wdGltaXplIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBob3N0cyBhbmQNCiAgIHJvdXRlcnMg aW4gYSBMb1dQQU4uICBUaGF0IHJlZ2lzdHJhdGlvbiBtZWNoYW5pc20gcHJvdmlkZXMgYSBz ZXJ2aWNlDQogICBzb21ld2hhdCBzaW1pbGFyIHRvIHRoZSBNdWx0aWNhc3QgQWRkcmVzcyBS ZXNvbHV0aW9uIFNlcnZlciAoTUFSUykNCiAgIFs8YSBocmVmPSIuL3JmYzIwMjIiIHRpdGxl PSciU3VwcG9ydCBmb3IgTXVsdGljYXN0IG92ZXIgVU5JIDMuMC8zLjEgYmFzZWQgQVRNIE5l dHdvcmtzIic+UkZDMjAyMjwvYT5dIGZvciBhIGxpbWl0ZWQgcHVycG9zZSwgYW5kIGluIGEg bXVjaCBzaW1wbGVyIGFuZCBsZXNzDQogICBnZW5lcmljIGZhc2hpb24uICBUaGUgdXNlIG9m IFJvdXRlciBBZHZlcnRpc2VtZW50cyB0byBkaXNzZW1pbmF0ZQ0KICAgcHJlZml4IGFuZCBo ZWFkZXIgY29tcHJlc3Npb24gY29udGV4dCB0aHJvdWdob3V0IHRoZSBMb1dQQU4gaXMgYWxz bw0KICAgc3BlY2lmaWVkLiAgVGhlIHNvbHV0aW9uIHN1cHBvcnRzIHRoZSB1c2Ugb2YgYm90 aCBsaW5rLWxheWVyLSBvcg0KICAgTG9XUEFOLWxldmVsIG1lc2ggKE1lc2ggVW5kZXIpIGFu ZCBJUCByb3V0aW5nIChSb3V0ZSBPdmVyKSBzb2x1dGlvbnMNCiAgIGZvciBtdWx0aWhvcCBm b3J3YXJkaW5nLiAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIGJvdGggc3VmZmljaWVudCBhbmQN CiAgIHJlcXVpcmVkIGZvciBMb1dQQU4gb3BlcmF0aW9uLiAgVGhlIDZMb1dQQU4tTkQgbWVj aGFuaXNtIGNvdWxkIGFsc28NCiAgIGNvZXhpc3Qgd2l0aCBbPGEgaHJlZj0iLi9yZmM0ODYx IiB0aXRsZT0nIk5laWdoYm9yIERpc2NvdmVyeSBmb3IgSVAgdmVyc2lvbiA2IChJUHY2KSIn PlJGQzQ4NjE8L2E+XSwgWzxhIGhyZWY9Ii4vcmZjMzEyMiIgdGl0bGU9JyJFeHRlbnNpb25z IHRvIElQdjYgTmVpZ2hib3IgRGlzY292ZXJ5IGZvciBJbnZlcnNlIERpc2NvdmVyeSBTcGVj aWZpY2F0aW9uIic+UkZDMzEyMjwvYT5dIG9yIG90aGVyIGZ1dHVyZSBORCBtZWNoYW5pc21z DQogICAoYWx0aG91Z2ggdGhlIG1vdGl2YXRpb24gb3IgZGV0YWlsZWQgc3BlY2lmaWNhdGlv biBvZiBzdWNoDQogICBjb2V4aXN0ZW5jZSBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBwcmVz ZW50IGRvY3VtZW50KS4NCiANCiAgIFRoZSBkb2N1bWVudCBkZWZpbmVzIHR3byBuZXcgSUNN UHY2IG1lc3NhZ2VzOiBOb2RlIFJlZ2lzdHJhdGlvbiBhbmQNCiAgIE5vZGUgQ29uZmlybWF0 aW9uLg0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KPHNwYW4gY2xhc3M9ImdyZXkiPlNoZWxieSwg ZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA1LCAyMDEwICAgICAgICAgICAgICAg ICBbUGFnZSA1XTwvc3Bhbj4gDQo8L3ByZT48cHJlIGNsYXNzPSduZXdwYWdlJz48YSBuYW1l PSJwYWdlLTYiIGlkPSJwYWdlLTYiIGhyZWY9IiNwYWdlLTYiIGNsYXNzPSJpbnZpc2libGUi PiA8L2E+IA0KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAgICAgICAgNkxv V1BBTiBOZWlnaGJvciBEaXNjb3ZlcnkgICAgICAgICAgRmVicnVhcnkgMjAxMDwvc3Bhbj4g DQogDQogDQo8c3BhbiBjbGFzcz0iaDMiPjxhIG5hbWU9InNlY3Rpb24tMS4xIj4xLjE8L2E+ LiAgR29hbHMsIEFzc3VtcHRpb25zLCBhbmQgR3Vlc3Nlczwvc3Bhbj4gDQogDQogICBUaGlz IGRvY3VtZW50IGhhcyB0aGUgZm9sbG93aW5nIG1haW4gZ29hbHMgYW5kIGFzc3VtcHRpb25z LCBhcyB3ZWxsDQogICBhcyB0d28gZ3Vlc3NlcyB0aGF0IG1heSBvciBtYXkgbm90IGJlIHRy dWUgaW4gYSBzcGVjaWZpYyBMb1dQQU4gYnV0DQogICBzdGlsbCBoYXZlIHNoYXBlZCB0aGUg b3B0aW1pemF0aW9ucy4NCiANCiAgIEdvYWxzOg0KIA0KICAgbyAgT3B0aW1pemUgTkQgd2l0 aCBhIG1lY2hhbmlzbSB0aGF0IGlzIG1pbmltYWwgeWV0IHN1ZmZpY2llbnQgZm9yDQogICAg ICBMb1dQQU4gb3BlcmF0aW9uIGluIGJvdGggbWVzaC11bmRlciBhbmQgcm91dGUtb3ZlciBj b25maWd1cmF0aW9ucy4NCiANCiAgIG8gIE1pbmltaXplIHNpZ25hbGxpbmcgYnkgYXZvaWRp bmcgdGhlIHVzZSBvZiBtdWx0aWNhc3QgZmxvb2RpbmcgYW5kDQogICAgICByZWR1Y2luZyB0 aGUgZnJlcXVlbmN5IG9mIGxpbmsgc2NvcGUgbXVsdGljYXN0IG1lc3NhZ2VzIGluc2lkZSB0 aGUNCiAgICAgIExvV1BBTnMuDQogDQogICBvICBEaXNzZW1pbmF0ZSBjb250ZXh0IGluZm9y bWF0aW9uIHRocm91Z2hvdXQgdGhlIExvV1BBTiB1c2VkIGJ5DQogICAgICBbPGEgaHJlZj0i I3JlZi1JLUQuaWV0Zi02bG93cGFuLWhjIiB0aXRsZT0nIkNvbXByZXNzaW9uIEZvcm1hdCBm b3IgSVB2NiBEYXRhZ3JhbXMgaW4gNkxvV1BBTiBOZXR3b3JrcyInPkktRC5pZXRmLTZsb3dw YW4taGM8L2E+XS4NCiANCiAgIG8gIE1pbmltaXplIHRoZSBjb21wbGV4aXR5IG9mIDxzcGFu IGNsYXNzPWhpbGl0ZT5ub2RlPC9zcGFuPnMuDQogDQogICBvICBPcHRpbWl6ZSB0aGUgaW50 ZXJmYWNlcyBiZXR3ZWVuIG5vZGVzIGFuZCB0aGVpciBkZWZhdWx0IHJvdXRlcnMuDQogDQog ICBBc3N1bXB0aW9uczoNCiANCiAgIG8gIEEgc3VibmV0IGluY2x1ZGVzIGFsbCB0aGUgPHNw YW4gY2xhc3M9aGlsaXRlPm5vZGU8L3NwYW4+cyBzaGFyaW5nIHRoZSBzYW1lIElQdjYNCiAg ICAgIHByZWZpeC4NCiANCiAgIG8gIEEgc2luZ2xlIExvV1BBTiBpcyBjb25maWd1cmVkIGlu IGEgaG9tb2dlbmVvdXMgd2F5LCBpLmUuLCBJSURzIGFyZQ0KICAgICAgZm9ybWVkIGJ5IG5v ZGVzIGluIGEgdW5pZm9ybSBtYXR0ZXIgYW5kIERBRCBpcyBwZXJmb3JtZWQgYnkNCiAgICAg IHJvdXRlcnMgaW4gYSB1bmlmb3JtIHdheS4NCiANCiAgIG8gIExpbmsgbGF5ZXIgdGVjaG5v bG9neSBpcyBlLmcuICBJRUVFIDgwMi4xNS40IGFzIGluIFs8YSBocmVmPSIuL3JmYzQ5NDQi IHRpdGxlPSciVHJhbnNtaXNzaW9uIG9mIElQdjYgUGFja2V0cyBvdmVyIElFRUUgODAyLjE1 LjQgTmV0d29ya3MiJz5SRkM0OTQ0PC9hPl0sIG9yDQogICAgICBhbnkgb3RoZXIgbGluay1s YXllciBleGhpYml0aW5nIG5vbi10cmFuc2l0aXZpdHkgb3IgYSBzaW1pbGFyDQogICAgICB0 b3BvbG9neS4NCiANCjxzcGFuIGNsYXNzPSJoMyI+PGEgbmFtZT0ic2VjdGlvbi0xLjIiPjEu MjwvYT4uICBXaHkgbm90IGNsYXNzaWMgSVB2NiBORD88L3NwYW4+IA0KIA0KICAgSVB2NiBO ZWlnaGJvciBEaXNjb3ZlcnkgWzxhIGhyZWY9Ii4vcmZjNDg2MSIgdGl0bGU9JyJOZWlnaGJv ciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiJz5SRkM0ODYxPC9hPl0gcHJv dmlkZXMgc2V2ZXJhbCBpbXBvcnRhbnQNCiAgIGZ1bmN0aW9ucyBzdWNoIGFzIFJvdXRlciBE aXNjb3ZlcnksIEFkZHJlc3MgUmVzb2x1dGlvbiwgRHVwbGljYXRlDQogICBBZGRyZXNzIERl dGVjdGlvbiwgUmVkaXJlY3QsIFByZWZpeCBhbmQgUGFyYW1ldGVyIERpc2NvdmVyeS4NCiAN CiAgIEZvbGxvd2luZyBwb3dlci1vbiBhbmQgaW5pdGlhbGl6YXRpb24gb2YgdGhlIG5ldHdv cmsgaW4gSVB2NiBFdGhlcm5ldA0KICAgbmV0d29ya3MsIGEgbm9kZSBqb2lucyB0aGUgc29s aWNpdGVkLW5vZGUgbXVsdGljYXN0IGFkZHJlc3Mgb24gdGhlDQogICBpbnRlcmZhY2UgYW5k IHRoZW4gcGVyZm9ybXMgZHVwbGljYXRlIGFkZHJlc3MgZGV0ZWN0aW9uIChEQUQpIGZvciB0 aGUNCiAgIGFjcXVpcmVkIGxpbmstbG9jYWwgYWRkcmVzcyBieSBzZW5kaW5nIGEgc29saWNp dGVkLW5vZGUgbXVsdGljYXN0DQogICBtZXNzYWdlIHRvIHRoZSBsaW5rLiAgQWZ0ZXIgdGhh dCBpdCBzZW5kcyBtdWx0aWNhc3QgbWVzc2FnZXMgdG8gdGhlDQogICBhbGwtcm91dGVyIGFk ZHJlc3MgdG8gc29saWNpdCByb3V0ZXIgYWR2ZXJ0aXNlbWVudHMuICBPbmNlIHRoZSBob3N0 DQogICByZWNlaXZlcyBhIHZhbGlkIHJvdXRlciBhZHZlcnRpc2VtZW50IHdpdGggdGhlICJB IiBmbGFnLCBpdA0KIA0KIA0KIA0KPHNwYW4gY2xhc3M9ImdyZXkiPlNoZWxieSwgZXQgYWwu ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA1LCAyMDEwICAgICAgICAgICAgICAgICBbUGFn ZSA2XTwvc3Bhbj4gDQo8L3ByZT48cHJlIGNsYXNzPSduZXdwYWdlJz48YSBuYW1lPSJwYWdl LTciIGlkPSJwYWdlLTciIGhyZWY9IiNwYWdlLTciIGNsYXNzPSJpbnZpc2libGUiPiA8L2E+ IA0KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAgICAgICAgNkxvV1BBTiBO ZWlnaGJvciBEaXNjb3ZlcnkgICAgICAgICAgRmVicnVhcnkgMjAxMDwvc3Bhbj4gDQogDQog DQogICBhdXRvY29uZmlndXJlcyB0aGUgSVB2NiBhZGRyZXNzIHdpdGggdGhlIGFkdmVydGlz ZWQgcHJlZml4IGluIHRoZQ0KICAgcm91dGVyIGFkdmVydGlzZW1lbnQgKFJBKS4gIEJlc2lk ZXMgdGhpcywgdGhlIElQdjYgcm91dGVycyB1c3VhbGx5DQogICBzZW5kIHJvdXRlciBhZHZl cnRpc2VtZW50cyBwZXJpb2RpY2FsbHkgb24gdGhlIG5ldHdvcmsuICBSQXMgYXJlIHNlbnQN CiAgIHRvIHRoZSBhbGwtbm9kZSBtdWx0aWNhc3QgYWRkcmVzcy4gIE5vZGVzIHNlbmQgTmVp Z2hib3IgU29saWNpdGF0aW9uLw0KICAgTmVpZ2hib3IgQWR2ZXJ0aXNlbWVudCBtZXNzYWdl cyB0byByZXNvbHZlIHRoZSBJUHY2IGFkZHJlc3Mgb2YgdGhlDQogICBkZXN0aW5hdGlvbiBv biB0aGUgbGluay4gIFRoZXNlIE5TL05BIG1lc3NhZ2VzIGFyZSBhbHNvIG9mdGVuDQogICBt dWx0aWNhc3QgbWVzc2FnZXMgYW5kIGl0IGlzIGFzc3VtZWQgdGhhdCB0aGUgbm9kZSBpcyBv biB0aGUgc2FtZQ0KICAgbGluayBhbmQgcmVsaWVzIG9uIHRoZSBmYWN0IHRoYXQgdGhlIGRl c3RpbmF0aW9uIG5vZGUgaXMgYWx3YXlzDQogICBwb3dlcmVkIGFuZCBnZW5lcmFsbHkgcmVs aWFibGUuDQogDQogICBBIExvV1BBTiBuZXR3b3JrIHR5cGljYWxseSB1c2VzIHR3byB0eXBl cyBvZiBMMiBhZGRyZXNzZXMgLS0gZm9yDQogICBleGFtcGxlIDE2LWJpdCBzaG9ydCBhZGRy ZXNzZXMgYW5kIDY0LWJpdCB1bmlxdWUgYWRkcmVzc2VzIGFzIGRlZmluZWQNCiAgIGluIFs8 YSBocmVmPSIuL3JmYzQ5NDQiIHRpdGxlPSciVHJhbnNtaXNzaW9uIG9mIElQdjYgUGFja2V0 cyBvdmVyIElFRUUgODAyLjE1LjQgTmV0d29ya3MiJz5SRkM0OTQ0PC9hPl0uICBNb3Jlb3Zl ciwgdGhlIGF2YWlsYWJsZSBMMiBwYXlsb2FkIHNpemUgb24gdGhlIG9yZGVyDQogICBvZiBs ZXNzIHRoYW4gMTAwIGJ5dGVzIHdoZXJlIHdlIG9mdGVuIG1pZ2h0IG5lZWQgdG8gdXNlIGhl YWRlcg0KICAgY29tcHJlc3Npb24gYW5kIHVzZSBhIG1pbmltdW0gcGF5bG9hZC4gIFRoZSBu ZXR3b3JrIGlzIGxvc3N5IGFuZCBsb3ctDQogICBwb3dlcmVkLCBhbmQgaXQgZG9lcyBub3Qg cHJvdmlkZSBtdWx0aWNhc3QgY2FwYWJpbGl0eSBhdCB0aGUgbGluay0NCiAgIGxheWVyLCB0 aHVzIHNpbXVsYXRpbmcgbXVsdGljYXN0IGJlaGF2aW9yIGJ5IGJvdGggdXNpbmcgYnJvYWRj YXN0IG9yDQogICBzZW5kaW5nIGEgbnVtYmVyIG9mIHVuaWNhc3QgbWVzc2FnZXMsIGJvdGgg ZXhwZW5zaXZlIGZvciB0aGUgbG93LQ0KICAgcG93ZXJlZCBuZXR3b3JrIGFuZCB0aGUgbG93 LXByb2Nlc3NpbmcgY2FwYWJsZSBub2Rlcy4gIE9mdGVuIHRoZXNlDQogICBsb3ctcG93ZXJl ZCBub2RlcyBjb25zZXJ2ZSBlbmVyZ3kgYnkgdXNpbmcgc2xlZXAgc2NoZWR1bGVzOyB3YWtp bmcNCiAgIHRoZW0gdXAgdG8gcmVjZWl2ZSBJUHY2IHNpZ25hbGluZyBtZXNzYWdlcyBzdWNo IGFzIG11bHRpY2FzdCBtZXNzYWdlcw0KICAgZm9yIE5TIG9yIHBlcmlvZGljIFJBcyBpcyBu b3QgcHJhY3RpY2FsLiAgQWxzbyB0aGV5IGFyZSBub3QgY2FwYWJsZQ0KICAgb2YgcHJvY2Vz c2luZyBhZGRyZXNzLXJlc29sdXRpb24gZm9yIHRoZWlyIG5laWdoYm9ycyBlZmZlY3RpdmVs eS4NCiAgIER1ZSB0byB0aGUgcmFkaW8gc3RyZW5ndGggb2YgaXRzIG5laWdoYm9yaW5nIHJv dXRlciBvciBpdHMgb3duDQogICBzdHJlbmd0aCwgYSBub2RlIG1heSBvZnRlbiBtb3ZlIGZy b20gb25lIHJvdXRlciB0byBhbm90aGVyIHdpdGhvdXQNCiAgIHBoeXNpY2FsbHkgbW92aW5n IGZyb20gb25lIHBsYWNlIHRvIGFub3RoZXIuICBDb25zaWRlcmluZyB0aGUgYWJvdmUNCiAg IGNoYXJhY3RlcmlzdGljcyBpbiBhIExvV1BBTiwgYW5kIHRoZSBJUHY2IE5laWdoYm9yIERp c2NvdmVyeQ0KICAgWzxhIGhyZWY9Ii4vcmZjNDg2MSIgdGl0bGU9JyJOZWlnaGJvciBEaXNj b3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiJz5SRkM0ODYxPC9hPl0gYmFzZSBwcm90 b2NvbCByZXF1aXJlbWVudHMsIGl0IHdhcyBjb25jbHVkZWQgdGhhdCBjbGFzc2ljDQogICBO ZWlnaGJvciBEaXNjb3ZlcnkgaXMgbm90IHN1aXRhYmxlIGFzIGl0IGlzIGFuZCBhIDZMb1dQ QU4tc3BlY2lmaWMgTkQNCiAgIGRlZmluaXRpb24gd291bGQgYmUgdXNlZnVsIGFuZCBlZmZp Y2llbnQgZm9yIHRoZSB3aWRlIGRlcGxveW1lbnQgb2YNCiAgIElQdjYgb3ZlciBsb3ctcG93 ZXJlZCB3aXJlbGVzcyBuZXR3b3JrcyBvZiBlbWJlZGRlZCBkZXZpY2VzLg0KIA0KIA0KPHNw YW4gY2xhc3M9ImgyIj48YSBuYW1lPSJzZWN0aW9uLTIiPjI8L2E+LiAgVGVybWlub2xvZ3k8 L3NwYW4+IA0KIA0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFV SVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9U IiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRv Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gWzxhIGhyZWY9 Ii4vcmZjMjExOSIgdGl0bGU9JyJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGlj YXRlIFJlcXVpcmVtZW50IExldmVscyInPlJGQzIxMTk8L2E+XS4NCiANCiAgIFRoaXMgc3Bl Y2lmaWNhdGlvbiByZXF1aXJlcyByZWFkZXJzIHRvIGJlIGZhbWlsaWFyIHdpdGggYWxsIHRo ZSB0ZXJtcw0KICAgYW5kIGNvbmNlcHRzIHRoYXQgYXJlIGRpc2N1c3NlZCBpbiAiSVB2NiBT dGF0ZWxlc3MgQWRkcmVzcw0KICAgQXV0b2NvbmZpZ3VyYXRpb24iIFs8YSBocmVmPSIuL3Jm YzQ4NjIiIHRpdGxlPSciSVB2NiBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlv biInPlJGQzQ4NjI8L2E+XSwgIklQdjYgb3ZlciBMb3ctUG93ZXIgV2lyZWxlc3MgUGVyc29u YWwNCiAgIEFyZWEgTmV0d29ya3MgKDZMb1dQQU5zKTogT3ZlcnZpZXcsIEFzc3VtcHRpb25z LCBQcm9ibGVtIFN0YXRlbWVudCwNCiAgIGFuZCBHb2FscyIgWzxhIGhyZWY9Ii4vcmZjNDkx OSIgdGl0bGU9JyJJUHY2IG92ZXIgTG93LVBvd2VyIFdpcmVsZXNzIFBlcnNvbmFsIEFyZWEg TmV0d29ya3MgKDZMb1dQQU5zKTogT3ZlcnZpZXcsIEFzc3VtcHRpb25zLCBQcm9ibGVtIFN0 YXRlbWVudCwgYW5kIEdvYWxzIic+UkZDNDkxOTwvYT5dLCAiVHJhbnNtaXNzaW9uIG9mIElQ djYgUGFja2V0cyBvdmVyIElFRUUNCiAgIDgwMi4xNS40IE5ldHdvcmtzIiBbPGEgaHJlZj0i Li9yZmM0OTQ0IiB0aXRsZT0nIlRyYW5zbWlzc2lvbiBvZiBJUHY2IFBhY2tldHMgb3ZlciBJ RUVFIDgwMi4xNS40IE5ldHdvcmtzIic+UkZDNDk0NDwvYT5dIGFuZCAiSVAgQWRkcmVzc2lu ZyBNb2RlbCBpbiBBZCBIb2MNCiAgIE5ldHdvcmtzIiBbPGEgaHJlZj0iI3JlZi1JLUQuaWV0 Zi1hdXRvY29uZi1hZGhvYy1hZGRyLW1vZGVsIiB0aXRsZT0nIklQIEFkZHJlc3NpbmcgTW9k ZWwgaW4gQWQgSG9jIE5ldHdvcmtzIic+SS1ELmlldGYtYXV0b2NvbmYtYWRob2MtYWRkci1t b2RlbDwvYT5dLg0KIA0KICAgUmVhZGVycyB3b3VsZCBiZW5lZml0IGZyb20gcmVhZGluZyAi T3B0aW1pc3RpYyBEdXBsaWNhdGUgQWRkcmVzcw0KIA0KIA0KIA0KPHNwYW4gY2xhc3M9Imdy ZXkiPlNoZWxieSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA1LCAyMDEwICAg ICAgICAgICAgICAgICBbUGFnZSA3XTwvc3Bhbj4gDQo8L3ByZT48cHJlIGNsYXNzPSduZXdw YWdlJz48YSBuYW1lPSJwYWdlLTgiIGlkPSJwYWdlLTgiIGhyZWY9IiNwYWdlLTgiIGNsYXNz PSJpbnZpc2libGUiPiA8L2E+IA0KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0 ICAgICAgICAgNkxvV1BBTiBOZWlnaGJvciBEaXNjb3ZlcnkgICAgICAgICAgRmVicnVhcnkg MjAxMDwvc3Bhbj4gDQogDQogDQogICBEZXRlY3Rpb24iIFs8YSBocmVmPSIuL3JmYzQ0Mjki IHRpdGxlPSciT3B0aW1pc3RpYyBEdXBsaWNhdGUgQWRkcmVzcyBEZXRlY3Rpb24gKERBRCkg Zm9yIElQdjYiJz5SRkM0NDI5PC9hPl0gKCJvREFEIikgcHJpb3IgdG8gdGhpcyBzcGVjaWZp Y2F0aW9uLg0KIA0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIG1ha2VzIGV4dGVuc2l2ZSB1c2Ug b2YgdGhlIHNhbWUgdGVybWlub2xvZ3kNCiAgIGRlZmluZWQgaW4gWzxhIGhyZWY9Ii4vcmZj NDg2MSIgdGl0bGU9JyJOZWlnaGJvciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2 NikiJz5SRkM0ODYxPC9hPl0gdW5sZXNzIG90aGVyd2lzZSByZWRlZmluZWQgYmVsb3cuDQog DQo8c3BhbiBjbGFzcz0iaDMiPjxhIG5hbWU9InNlY3Rpb24tMi4xIj4yLjE8L2E+LiAgNkxv V1BBTiBUZXJtaW5vbG9neTwvc3Bhbj4gDQogDQogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyBh ZGRpdGlvbmFsIGdlbmVyYWwgdGVybXMgcmVsYXRlZCB0byB0aGUgNkxvV1BBTg0KICAgYXJj aGl0ZWN0dXJlIHVzZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uOg0KIA0KICAgSVAgUm91dGlu Zw0KIA0KICAgICAgVGhlIGZvcndhcmRpbmcgb2YgZGF0YWdyYW1zIGF0IHRoZSBJUCBsYXll ciBiZXR3ZWVuIGFyYml0cmFyeQ0KICAgICAgc291cmNlLWRlc3RpbmF0aW9uIHBhaXJzLCBk dXJpbmcgd2hpY2ggdGhlIElQdjYgaG9wIGxpbWl0IGlzDQogICAgICBkZWNyZW1lbnRlZC4g IEluIHRoZSBMb1dQQU4gY29udGV4dCwgSVAgcm91dGluZyBpcyBwZXJmb3JtZWQgYnkNCiAg ICAgIDxzcGFuIGNsYXNzPWhpbGl0ZT5yb3V0ZXI8L3NwYW4+cyBvbiBhIHNpbmdsZSBpbnRl cmZhY2Ugd2l0aGluIHRoZSBzYW1lIHN1Ym5ldC4NCiAgICAgIEV4YWN0IG1hdGNoIHNlYXJj aCBpcyBwZXJmb3JtZWQgb24gdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlDQogICAg ICBJUCBwYWNrZXQgdG8gZmluZCB0aGUgbmV4dC1ob3AgdG8gdGhlIGRlc3RpbmF0aW9uLiAg UmVmZXJyZWQgdG8gYXMNCiAgICAgIHJvdXRpbmcgaW4gdGhpcyBkb2N1bWVudC4NCiANCiAg IExpbmsNCiANCiAgICAgIFRoZSBsaW5rIGlzIGEgY29tbXVuaWNhdGlvbiBmYWNpbGl0eSBv ciBtZWRpdW0gb3ZlciB3aGljaCBub2Rlcw0KICAgICAgY2FuIGNvbW11bmljYXRlIGF0IHRo ZSBsaW5rLWxheWVyLCBpLmUuLCB0aGUgbGF5ZXIgZGlyZWN0bHkgYmVsb3cNCiAgICAgIElQ IChbPGEgaHJlZj0iLi9yZmM0ODYxIiB0aXRsZT0nIk5laWdoYm9yIERpc2NvdmVyeSBmb3Ig SVAgdmVyc2lvbiA2IChJUHY2KSInPlJGQzQ4NjE8L2E+XSkuIDZMb1dQQU4gYXNzdW1lcyB0 aGUgdXNlIG9mIGxvdy1wb3dlciBhbmQgbG9zc3kNCiAgICAgIHdpcmVsZXNzIGxpbmtzIHN1 Y2ggYXMgSUVFRSA4MDIuMTUuNCwgd2hpY2ggaXMgYSBzcGVjaWFsIHR5cGUgb2YNCiAgICAg IGxpbmsgYXMgZGVzY3JpYmVkIGluIFs8YSBocmVmPSIuL3JmYzQ4NjEiIHRpdGxlPSciTmVp Z2hib3IgRGlzY292ZXJ5IGZvciBJUCB2ZXJzaW9uIDYgKElQdjYpIic+UkZDNDg2MTwvYT5d IGV4aGliaXRpbmcgc2V2ZXJlIGFzeW1tZXRyaWMNCiAgICAgIHJlYWNoYWJpbGl0eSB3aXRo IGJvdGggYXN5bW1ldHJpYyAoQSBjYW4gcmVhY2ggQiwgYnV0IEIgY2FuJ3QNCiAgICAgIHJl YWNoIEEpIGFuZCBub24tdHJhbnNpdGl2ZSAoQSBjYW4gcmVhY2ggQiwgYW5kIEIgY2FuIHJl YWNoIEMsIGJ1dA0KICAgICAgQSBjYW4ndCByZWFjaCBDKSBxdWFsaXRpZXMuICBUaGUgdXNl IG9mIGxpbmstbGF5ZXIgbWVzaCB0ZWNobm9sb2d5DQogICAgICAoc2VlIE1lc2ggVW5kZXIp IGVtdWxhdGVzIHRyYW5zaXRpdml0eSBhY3Jvc3MgdGhlIGxpbmsgYnV0IHN0aWxsDQogICAg ICBoYXMgcHJvYmxlbXMgd2l0aCBhc3ltbWV0cmljaXR5LiAgTXVsdGljYXN0IG9uIGEgbGlu ay1sYXllciBtZXNoLA0KICAgICAgaWYgYXZhaWxhYmxlLCBpcyBvZnRlbiBpbXBsZW1lbnRl ZCBhcyBhbiBleHBlbnNpdmUgYnJvYWRjYXN0DQogICAgICBmbG9vZC4gIER1ZSB0byB0aGVp ciBuYXR1cmUsIHRoZXNlIGFyZSBjb25zaWRlcmVkIGxpbmtzIHdpdGgNCiAgICAgIHVuZGV0 ZXJtaW5lZCBjb25uZWN0aXZpdHkgcHJvcGVydGllcyBhcyBkZWZpbmVkIGluDQogICAgICBb PGEgaHJlZj0iI3JlZi1JLUQuaWV0Zi1hdXRvY29uZi1hZGhvYy1hZGRyLW1vZGVsIiB0aXRs ZT0nIklQIEFkZHJlc3NpbmcgTW9kZWwgaW4gQWQgSG9jIE5ldHdvcmtzIic+SS1ELmlldGYt YXV0b2NvbmYtYWRob2MtYWRkci1tb2RlbDwvYT5dLg0KIA0KICAgTGluay1sb2NhbA0KIA0K ICAgICAgU3RhbmRhcmQgSVB2NiBsaW5rLWxvY2FsIHNjb3BlIGlzIGRlZmluZWQgaW4gWzxh IGhyZWY9Ii4vcmZjNDI5MSIgdGl0bGU9JyJJUCBWZXJzaW9uIDYgQWRkcmVzc2luZyBBcmNo aXRlY3R1cmUiJz5SRkM0MjkxPC9hPl0gYW5kDQogICAgICBbPGEgaHJlZj0iLi9yZmM0ODYx IiB0aXRsZT0nIk5laWdoYm9yIERpc2NvdmVyeSBmb3IgSVAgdmVyc2lvbiA2IChJUHY2KSIn PlJGQzQ4NjE8L2E+XS4gIExpbmstbG9jYWwgc2NvcGUgaXMgYWNoaWV2ZWQgYnkgc2V0dGlu ZyB0aGUgaG9wIGxpbWl0DQogICAgICB0byAxLCB1c2luZyBhIGxpbmstbG9jYWwgcHJlZml4 IChGRTgwOjopIG9yIGxpbmstbG9jYWwgbXVsdGljYXN0DQogICAgICBzY29wZSAoRkZ4Mjo6 KS4gIElmIGEgbGluayBpcyBub24tdHJhbnNpdGl2ZSB0aGVuIGxpbmstbG9jYWwgc2NvcGUN CiAgICAgIG1heSBpbmNsdWRlIG9ubHkgYSBzdWJzZXQgb2Ygbm9kZXMgb24gdGhlIGxpbmsg KHRoZSBzZXQgb2Ygbm9kZXMNCiAgICAgIHdpdGhpbiBzeW1tZXRyaWMgcmFkaW8gcmFuZ2Ug b2YgYSBub2RlKS4gIE5vZGVzIGluIHRoZSBsaW5rLWxvY2FsDQogICAgICBzY29wZSBvZiBh IG5vZGUgYXJlIGl0cyBuZWlnaGJvcnMsIGFuZCB0aGlzIGxpbmstbG9jYWwgc2NvcGUgbWF5 DQogICAgICBkaWZmZXIgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgZWFjaCBub2RlLiAgVGhl cmVmb3JlLCBsaW5rLWxvY2FsDQogICAgICBhZGRyZXNzZXMgYXJlIG9mIGxpbWl0ZWQgdmFs dWUgYXMgZGlzY3Vzc2VkIGluDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5 LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAg ICAgIFtQYWdlIDhdPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5h bWU9InBhZ2UtOSIgaWQ9InBhZ2UtOSIgaHJlZj0iI3BhZ2UtOSIgY2xhc3M9ImludmlzaWJs ZSI+IDwvYT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2 TG9XUEFOIE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFu PiANCiANCiANCiAgICAgIFs8YSBocmVmPSIjcmVmLUktRC5pZXRmLWF1dG9jb25mLWFkaG9j LWFkZHItbW9kZWwiIHRpdGxlPSciSVAgQWRkcmVzc2luZyBNb2RlbCBpbiBBZCBIb2MgTmV0 d29ya3MiJz5JLUQuaWV0Zi1hdXRvY29uZi1hZGhvYy1hZGRyLW1vZGVsPC9hPl0uDQogDQog ICBMb1dQQU4gSG9zdA0KIA0KICAgICAgQSBub2RlIHRoYXQgb25seSBzb3VyY2VzIG9yIHNp bmtzIElQdjYgZGF0YWdyYW1zLiAgUmVmZXJyZWQgdG8gYXMNCiAgICAgIGEgaG9zdCBpbiB0 aGlzIGRvY3VtZW50Lg0KIA0KICAgTG9XUEFOIE5vZGUNCiANCiAgICAgIEEgbm9kZSB0aGF0 IGNvbXBvc2VzIGEgTG9XUEFOLCByZWZlcnJpbmcgdG8gYm90aCBob3N0cyBhbmQNCiAgICAg IHJvdXRlcnMuICBTaW1wbHkgY2FsbGVkIGEgbm9kZSBpbiB0aGlzIGRvY3VtZW50Lg0KIA0K ICAgTG9XUEFOIFJvdXRlcg0KIA0KICAgICAgQSBMb1dQQU4gbm9kZSB0aGF0IGZvcndhcmRz IGRhdGFncmFtcyBiZXR3ZWVuIGFyYml0cmFyeSBzb3VyY2UtDQogICAgICBkZXN0aW5hdGlv biBwYWlycyB1c2luZyBhIHNpbmdsZSA2TG9XUEFOIGludGVyZmFjZSBwZXJmb3JtaW5nIElQ DQogICAgICByb3V0aW5nIG9uIHRoYXQgaW50ZXJmYWNlLiAgPHNwYW4gY2xhc3M9aGlsaXRl PlJlZmVycmVkIHRvIGFzIGEgcm91dGVyIGluIHRoaXMgZG9jdW1lbnQuPC9zcGFuPg0KIA0K ICAgTG9XUEFOIE1lc2ggbm9kZQ0KIA0KICAgICAgQSBMb1dQQU4gbm9kZSB0aGF0IGZvcndh cmRzIGRhdGEgYmV0d2VlbiBhcmJpdHJhcnkgc291cmNlLQ0KICAgICAgZGVzdGluYXRpb24g cGFpcnMgdXNpbmcgbGluayBhZGRyZXNzZXMgKGFuZCB0aHVzIG9ubHkgZXhpc3RzIGluDQog ICAgICBNZXNoIFVuZGVyIExvV1BBTnMpLg0KIA0KICAgTWVzaCBVbmRlcg0KIA0KICAgICAg QSB0ZXJtIHJlZmVycmluZyB0byBhIGNvbmZpZ3VyYXRpb24gd2hlcmUgdGhlIGxpbmstbG9j YWwgc2NvcGUgaXMNCiAgICAgIGRlZmluZWQgYnkgdGhlIGJvdW5kYXJpZXMgb2YgdGhlIExv V1BBTiAob3IgYSBzaXphYmxlIHBhcnQgb2YgaXQsDQogICAgICBpZiBNZXNoIFVuZGVyIGlz IGNvbWJpbmVkIHdpdGggUm91dGUgT3ZlcikgYW5kIGluY2x1ZGVzIGFsbCB0aGUNCiAgICAg IDZMb1dQQU4gaW50ZXJmYWNlcyB3aXRoaW4gaXQuICBUaGVyZSBhcmUgZm9yd2FyZGluZyBh bmQgbXVsdGlob3ANCiAgICAgIHJvdXRpbmcgZnVuY3Rpb25zIGF0IEwyIHRvIGFjaGlldmUg dHJhbnNpdGl2aXR5IG9uIHRoZSBsaW5rLiAgSW4NCiAgICAgIHRoaXMgY29uZmlndXJhdGlv biB0aGUgbGluayBtYXkgc3RpbGwgZXhoaWJpdCBsb3NzeSwgYXN5bW1ldHJpYywNCiAgICAg IE5CTUEgKG5vbi1hdmFpbGFiaWxpdHkgb2YgbWVzaC13aWRlIG11bHRpY2FzdCkgYmVoYXZp b3IuDQogDQogICBSb3V0ZSBPdmVyDQogDQogICAgICBBIHRlcm0gcmVmZXJyaW5nIHRvIGEg Y29uZmlndXJhdGlvbiB3aGVyZSB0aGUgTG9XUEFOIGlzIG1hZGUgdXAgb2YNCiAgICAgIHNl dmVyYWwgcGFydGlhbGx5IG92ZXJsYXBwaW5nIGxpbmtzIGFuZCBsaW5rLWxvY2FsIHNjb3Bl IHJlYWNoZXMNCiAgICAgIG9ubHkgYSBzdWJzZXQgb2YgdGhlIDxzcGFuIGNsYXNzPWhpbGl0 ZT5ub2Rlczwvc3Bhbj4uICBJUCByb3V0aW5nIGlzIHBlcmZvcm1lZCBieQ0KICAgICAgPHNw YW4gY2xhc3M9aGlsaXRlPnJvdXRlcnM8L3NwYW4+IHRvIHByb3ZpZGUgY29ubmVjdGl2aXR5 IGFjcm9zcyB0aGUgTG9XUEFOLiAgQQ0KICAgICAgTG9XUEFOIHdpdGggdGhpcyBjb25maWd1 cmF0aW9uIG1heSBjb25zaXN0IG9mIGJvdGggcm91dGVycyBhbmQNCiAgICAgIGhvc3RzLiAg Um91dGUgT3ZlciBhbmQgTWVzaCBVbmRlciBhcmUgbm90IG11dHVhbGx5IGV4Y2x1c2l2ZSwg YW5kDQogICAgICBJUCByb3V0aW5nIG1heSBiZSB1c2VkIGJldHdlZW4gbGlua3MgdGhhdCBw ZXJmb3JtIE1lc2ggVW5kZXIuDQogDQogICBTdWJuZXQNCiANCiANCiANCiANCiANCiANCjxz cGFuIGNsYXNzPSJncmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgNSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgOV08L3NwYW4+IA0KPC9wcmU+PHBy ZSBjbGFzcz0nbmV3cGFnZSc+PGEgbmFtZT0icGFnZS0xMCIgaWQ9InBhZ2UtMTAiIGhyZWY9 IiNwYWdlLTEwIiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5 Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAg ICAgICAgIEZlYnJ1YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAgICAgQSBzdWJuZXQgaXMg dGhlIGNvbGxlY3Rpb24gb2YgaW50ZXJmYWNlcyBoYXZpbmcgdGhlIHNhbWUgSVB2Ng0KICAg ICAgc3VibmV0IHByZWZpeCBvbiBhIGxpbmssIGFzIGRlZmluZWQgaW4gWzxhIGhyZWY9Ii4v cmZjNDI5MSIgdGl0bGU9JyJJUCBWZXJzaW9uIDYgQWRkcmVzc2luZyBBcmNoaXRlY3R1cmUi Jz5SRkM0MjkxPC9hPl0uICBBIExvV1BBTiBpcw0KICAgICAgbWFkZSB1cCBvZiB0aGUgaW50 ZXJmYWNlcyBvZiA8c3BhbiBjbGFzcz1oaWxpdGU+bm9kZXM8L3NwYW4+IGFuZCBFZGdlIFJv dXRlcnMgc2hhcmluZw0KICAgICAgdGhlIHNhbWUgc3VibmV0IHByZWZpeC4gIFRoaXMgUm91 dGUgT3ZlciBjb25maWd1cmF0aW9uIGV4aGliaXRzIGENCiAgICAgIG11bHRpLWhvcCBzdWJu ZXQgZmVhdHVyZSB3aXRoIHJlZ2FyZCB0byBob3AgbGltaXQgYXMgZGlzY3Vzc2VkIGluDQog ICAgICBbPGEgaHJlZj0iLi9yZmM0OTAzIiB0aXRsZT0nIk11bHRpLUxpbmsgU3VibmV0IElz c3VlcyInPlJGQzQ5MDM8L2E+XSwgYW5kIHRodXMgNkxvV1BBTiBhcHBsaWNhdGlvbnMgc2hv dWxkIGJlIGNhcmVmdWwgd2hlbg0KICAgICAgbWFraW5nIGFzc3VtcHRpb25zIGFib3V0IHRo ZSBob3AgbGltaXQgYXMgaXQgbWF5IGJlIGRlY3JlbWVudGVkIGluDQogICAgICBhIExvV1BB Ti4NCiANCjxzcGFuIGNsYXNzPSJoMyI+PGEgbmFtZT0ic2VjdGlvbi0yLjIiPjIuMjwvYT4u ICBORCBUZXJtaW5vbG9neTwvc3Bhbj4gDQogDQogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyBO ZWlnaGJvciBEaXNjb3Zlcnkgc3BlY2lmaWMgdGVybWlub2xvZ3kgdXNlZCBpbg0KICAgdGhp cyBzcGVjaWZpY2F0aW9uOg0KIA0KICAgU2ltcGxlIExvV1BBTg0KIA0KICAgICAgQSBTaW1w bGUgTG9XUEFOIGNvbnNpc3RzIG9mIGEgc2luZ2xlIEVkZ2UgUm91dGVyIGFuZCB0aGUgc2V0 IG9mDQogICAgICA8c3BhbiBjbGFzcz1oaWxpdGU+bm9kZXM8L3NwYW4+IG9uIHRoZSBzYW1l IExvV1BBTiBTdWJuZXQsIHNob3duIGluIEZpZ3VyZSAxLg0KIA0KICAgQWQtaG9jIExvV1BB Tg0KIA0KICAgICAgQW4gaXNvbGF0ZWQgTG9XUEFOLCBub3QgY29ubmVjdGVkIHRvIGFueSBv dGhlciBJUCBuZXR3b3Jrcy4gIEFkLQ0KICAgICAgSG9jIExvV1BBTnMgbWFrZSB1c2Ugb2Yg VW5pcXVlIG9uLWxpbmsgSVB2NiBVbmljYXN0IEFkZHJlc3Nlcw0KICAgICAgKFVMQXMpIFs8 YSBocmVmPSIuL3JmYzQxOTMiIHRpdGxlPSciVW5pcXVlIExvY2FsIElQdjYgVW5pY2FzdCBB ZGRyZXNzZXMiJz5SRkM0MTkzPC9hPl0uDQogDQogICBCYWNrYm9uZSBMaW5rDQogDQogICAg ICBUaGlzIGlzIGFuIElQdjYgbGluayB0aGF0IGludGVyY29ubmVjdHMgdHdvIG9yIG1vcmUg PHNwYW4gY2xhc3M9aGlsaXRlPkU8L3NwYW4+ZGdlIDxzcGFuIGNsYXNzPWhpbGl0ZT5SPC9z cGFuPm91dGVycw0KICAgICAgaW4gYW4gRXh0ZW5kZWQgTG9XUEFOIHRvcG9sb2d5LiAgSXQg aXMgZXhwZWN0ZWQgdG8gYmUgZGVwbG95ZWQgYXMNCiAgICAgIGEgaGlnaCBzcGVlZCBiYWNr Ym9uZSBpbiBvcmRlciB0byBmZWRlcmF0ZSBhIHBvdGVudGlhbGx5IGxhcmdlIHNldA0KICAg ICAgb2YgTG9XUEFOcy4NCiANCiAgIExvV1BBTiBFZGdlIFJvdXRlcg0KIA0KICAgICAgQW4g SVB2NiByb3V0ZXIgdGhhdCBpbnRlcmNvbm5lY3RzIHRoZSBMb1dQQU4gdG8gYW5vdGhlciBJ UA0KICAgICAgbmV0d29yay4gIFJlZmVycmVkIHRvIGFzIGFuIEVkZ2UgUm91dGVyIGluIHRo aXMgZG9jdW1lbnQuDQogDQogICBSZWdpc3RyYXRpb24NCiANCiAgICAgIFRoZSBwcm9jZXNz IGR1cmluZyB3aGljaCBhIExvV1BBTiBub2RlIHNlbmRzIGEgTm9kZSBSZWdpc3RyYXRpb24N CiAgICAgIG1lc3NhZ2UgdG8gYSA8c3BhbiBjbGFzcz1oaWxpdGU+cjwvc3Bhbj5vdXRlciBj cmVhdGluZyBhIGJpbmRpbmcgZm9yIHRoZSA8c3BhbiBjbGFzcz1oaWxpdGU+bm9kZTwvc3Bh bj4uDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+ U2hlbGJ5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAg ICAgICAgICAgW1BhZ2UgMTBdPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2Un PjxhIG5hbWU9InBhZ2UtMTEiIGlkPSJwYWdlLTExIiBocmVmPSIjcGFnZS0xMSIgY2xhc3M9 ImludmlzaWJsZSI+IDwvYT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQg ICAgICAgICA2TG9XUEFOIE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAy MDEwPC9zcGFuPiANCiANCiANCiAgICAgICAgICBJbmZyYXN0cnVjdHVyZSBDbG91ZA0KICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICstLS0tLSsNCiAgICAgICAgICAgICAgICB8ICAg ICB8IEVkZ2UNCiAgICAgICAgICAgICAgICB8ICAgICB8IDxzcGFuIGNsYXNzPWhpbGl0ZT5S PC9zcGFuPm91dGVyDQogICAgICAgICAgICAgICAgKy0tLS0tKw0KICAgICAgICAgICAgICAg ICAgbyAgbw0KICAgICAgICAgICAgICAgbyAgIG8gICAgbw0KICAgICAgICAgICAgIG8gIG8g ICBvICBvIG8gICAgICAgIG86IDxzcGFuIGNsYXNzPWhpbGl0ZT5Ob2RlPC9zcGFuPg0KICAg ICAgICAgICAgICBvICAgbyAgbyAgbw0KICAgICAgICAgICAgICAgIG8gICBvIG8NCiANCiAg ICAgICAgICAgICBTaW1wbGUgTG9XUEFODQogDQogDQogICAgICAgICAgICAgICAgICAgIEZp Z3VyZSAxOiBBIHNpbXBsZSBMb1dQQU4gdG9wb2xvZ3kNCiANCiANCjxzcGFuIGNsYXNzPSJo MiI+PGEgbmFtZT0ic2VjdGlvbi0zIj4zPC9hPi4gIFByb3RvY29sIE92ZXJ2aWV3PC9zcGFu PiANCiANCiAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICg2TG9XUEFOLU5EKSBvcHRp bWl6ZXMgSVB2NiBORCB3aXRoIGENCiAgIG1lY2hhbmlzbSB3aGljaCBpcyBvbiBpdHMgb3du IG1pbmltYWwgeWV0IHN1ZmZpY2llbnQgZm9yIExvV1BBTiBJUHY2DQogICBvcGVyYXRpb24u IDZMb1dQQU4tTkQgZGVmaW5lcyBhIG5vZGUgcmVnaXN0cmF0aW9uIG1lY2hhbmlzbQ0KICAg b3B0aW1pemluZyB0aGUgbm9kZS1yb3V0ZXIgaW50ZXJmYWNlLiAgVGhpcyBtZWNoYW5pc20g cmVxdWlyZXMgbm8NCiAgIGZsb29kaW5nIGFuZCByZWR1Y2VzIGxpbmstbG9jYWwgbXVsdGlj YXN0IGZyZXF1ZW5jeS4gNkxvV1BBTi1ORA0KICAgc3VwcG9ydHMgbm9uLXRyYW5zaXRpdmUg bGlua3MsIHRoZSB1c2Ugb2YgYm90aCBtZXNoLXVuZGVyIGFuZCByb3V0ZS0NCiAgIG92ZXIg dGVjaG5pcXVlcyBhbmQgbWFrZXMgbm8gYXNzdW1wdGlvbnMgYWJvdXQgc3luY2hyb25pemF0 aW9uDQogICBiZXR3ZWVuIGhvc3RzIHVzaW5nIHRoZSBzYW1lIHJvdXRlci4gIFRoaXMgc3Bl Y2lmaWNhdGlvbiBpcyBSRVFVSVJFRA0KICAgZm9yIExvV1BBTiBvcGVyYXRpb24sIGJ1dCBN QVkgYWxzbyBjb2V4aXN0IHdpdGggWzxhIGhyZWY9Ii4vcmZjNDg2MSIgdGl0bGU9JyJOZWln aGJvciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiJz5SRkM0ODYxPC9hPl0s IFs8YSBocmVmPSIuL3JmYzMxMjIiIHRpdGxlPSciRXh0ZW5zaW9ucyB0byBJUHY2IE5laWdo Ym9yIERpc2NvdmVyeSBmb3IgSW52ZXJzZSBEaXNjb3ZlcnkgU3BlY2lmaWNhdGlvbiInPlJG QzMxMjI8L2E+XQ0KICAgb3Igb3RoZXIgZnV0dXJlIE5EIG1lY2hhbmlzbXMuICBBbnkgdXNl IG9mIFs8YSBocmVmPSIuL3JmYzQ5NDQiIHRpdGxlPSciVHJhbnNtaXNzaW9uIG9mIElQdjYg UGFja2V0cyBvdmVyIElFRUUgODAyLjE1LjQgTmV0d29ya3MiJz5SRkM0OTQ0PC9hPl0gd2l0 aG91dCB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGlzIE5PVCBSRUNPTU1FTkRFRC4NCiANCiAg IFRoZSBmb2xsb3dpbmcgZmVhdHVyZXMgYXJlIGRlZmluZWQgYnkgNkxvV1BBTi1ORCAoc2Vl IFNlY3Rpb24NCiAgIDxhIGhyZWY9IiNzZWN0aW9uLTUiPlNlY3Rpb24gNTwvYT4gZm9yIGRl dGFpbHMpOg0KIA0KICAgTm9kZSBSZWdpc3RyYXRpb246ICBNZXRob2QgaW4gd2hpY2ggbm9k ZXMgaW4gdGhlIExvV1BBTiByZWdpc3RlciB3aXRoDQogICAgICA8c3BhbiBjbGFzcz1oaWxp dGU+cjwvc3Bhbj5vdXRlcnMsIGNyZWF0aW5nIHN0YXRlIGFib3V0IG5vZGVzIGF0dGFjaGVk IHRvIHRoYXQgcm91dGVyDQogICAgICAoYmluZGluZyB0YWJsZSkuDQogDQogICBOZXh0LWhv cCBEZXRlcm1pbmF0aW9uOiAgVGhlIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIHNpbXBsZSBu ZXh0LWhvcA0KICAgICAgZGV0ZXJtaW5hdGlvbiBydWxlLg0KIA0KICAgQWRkcmVzcyBSZXNv bHV0aW9uOiAgVGhlIE5vZGUgUmVnaXN0cmF0aW9uIG1lY2hhbmlzbSBwcm92aWRlcw0KICAg ICAgc3VmZmljaWVudCBhIHByaW9yaSBzdGF0ZSBpbiBub2RlcyBhbmQgcm91dGVycyB0byBy ZXNvbHZlIGFuIElQdjYNCiAgICAgIGFkZHJlc3MgdG8gaXRzIGFzc29jaWF0ZWQgbGluay1s YXllciBhZGRyZXNzIG9uIHRoZSBub2RlLXJvdXRlcg0KICAgICAgaW50ZXJmYWNlLiAgSG9z dC1ob3N0IHJlc29sdXRpb24gaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMNCiANCiANCiANCjxz cGFuIGNsYXNzPSJncmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAxMV08L3NwYW4+IA0KPC9wcmU+PHBy ZSBjbGFzcz0nbmV3cGFnZSc+PGEgbmFtZT0icGFnZS0xMiIgaWQ9InBhZ2UtMTIiIGhyZWY9 IiNwYWdlLTEyIiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5 Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAg ICAgICAgIEZlYnJ1YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAgICAgc3BlY2lmaWNhdGlv bi4NCiANCiAgIFVucmVhY2hhYmlsaXR5IERldGVjdGlvbjogIFVucmVhY2hhYmlsaXR5IGJl dHdlZW4gYSBub2RlIGFuZCByb3V0ZXINCiAgICAgIGlzIGRldGVybWluZWQgYmFzZWQgb24g bGluay1sYXllciBhY2tub3dsZWRnZW1lbnRzIHRvIG5vZGUNCiAgICAgIHJlZ2lzdHJhdGlv biBhbmQgdW5pY2FzdCBkYXRhIG1lc3NhZ2VzLiAgSG9zdC1ob3N0IHVucmVhY2hhYmlsaXR5 DQogICAgICBkZXRlY3Rpb24gaXMgb3V0IG9mIHNjb3BlLiAgRGVzdGluYXRpb24gdW5yZWFj aGFiaWxpdHkgZGV0ZWN0aW9uDQogICAgICBpcyBwZXJmb3JtZWQgdXNpbmcgSUNNUHY2IGRl c3RpbmF0aW9uIHVucmVhY2hhYmxlIG1lc3NhZ2VzLg0KIA0KICAgQ29udGV4dCBEaXNzZW1p bmF0aW9uOiAgVGhlIGRpc3NlbWluYXRpb24gb2YgTG9XUEFOIGNvbnRleHQgYXMgdXNlZA0K ICAgICAgYnkgWzxhIGhyZWY9IiNyZWYtSS1ELmlldGYtNmxvd3Bhbi1oYyIgdGl0bGU9JyJD b21wcmVzc2lvbiBGb3JtYXQgZm9yIElQdjYgRGF0YWdyYW1zIGluIDZMb1dQQU4gTmV0d29y a3MiJz5JLUQuaWV0Zi02bG93cGFuLWhjPC9hPl0gaXMgZGVmaW5lZCBhcyBhbiBJQ01QdjYg b3B0aW9uLCBhbG9uZw0KICAgICAgd2l0aCBhbiBhc3NvY2lhdGVkIHN1bW1hcnkgb3B0aW9u IHRvIHJlZHVjZSBtZXNzYWdlIHNpemUgd2hlbiBtYW55DQogICAgICBjb250ZXh0cyBhcmUg YWR2ZXJ0aXNlZC4NCiANCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBtYWtlcyB1c2Ugb2YgUlMv UkEgbWVzc2FnZSBleGNoYW5nZXMgc2ltaWxhciB0bw0KICAgY2xhc3NpYyBORCwgd2hpY2gg aW4gNkxvV1BBTi1ORCBtYXkgYWxzbyBjYXJyeSBhZGRpdGlvbmFsIG9wdGlvbnMgZm9yDQog ICBjb250ZXh0IGRpc3NlbWluYXRpb24gKDZMb1dQQU4gSW5mb3JtYXRpb24gT3B0aW9uLCA2 SU8pIGFuZCByZWR1Y2luZw0KICAgUkEgbWVzc2FnZSBzaXplICg2TG9XUEFOIFN1bW1hcnkg T3B0aW9uLCA2U08pLiAgSW4gYWRkaXRpb24NCiAgIDZMb1dQQU4tTkQgZGVmaW5lcyB0d28g bmV3IElDTVAgcGFja2V0IHR5cGVzOg0KIA0KICAgTm9kZSBSZWdpc3RyYXRpb24gKE5SKTog IFNlbnQgYnkgYSBub2RlIHRvIGEgPHNwYW4gY2xhc3M9aGlsaXRlPnI8L3NwYW4+b3V0ZXIg dG8gcmVnaXN0ZXIgYQ0KICAgICAgYmluZGluZy4NCiANCiAgIE5vZGUgQ29uZmlybWF0aW9u IChOQyk6ICBUaGUgcmVzcG9uc2Ugc2VudCBieSBhIDxzcGFuIGNsYXNzPWhpbGl0ZT5yPC9z cGFuPm91dGVyIGJhY2sgdG8gdGhlDQogICAgICByZWdpc3RlcmluZyBub2RlLg0KIA0KPHNw YW4gY2xhc3M9ImgzIj48YSBuYW1lPSJzZWN0aW9uLTMuMSI+My4xPC9hPi4gIFRvcG9sb2d5 PC9zcGFuPiANCiANCiAgIDZMb1dQQU4tTkQgbWFrZXMgbGl0dGxlIGFzc3VtcHRpb24gYWJv dXQgc3luY2hyb25pemF0aW9uIGJldHdlZW4NCiAgIG5vZGVzIGluIGEgTG9XUEFOIGV4Y2Vw dCBiZXR3ZWVuIGEgbm9kZSBhbmQgdGhlIHJvdXRlcnMgaXQgaGFzDQogICByZWdpc3RlcmVk IHdpdGguIDZMb1dQQU4tTkQgaXMgZGVzaWduZWQgdG8gd29yayBhbHNvIHdpdGggQWQtaG9j DQogICB0b3BvbG9naWVzLiAgVGhlIGNhc2Ugb2YgQWQtaG9jIExvV1BBTiBvcGVyYXRpb24g aXMgZGVzY3JpYmVkIGluDQogICA8YSBocmVmPSIjc2VjdGlvbi04Ij5TZWN0aW9uIDg8L2E+ Lg0KIA0KICAgNkxvV1BBTi1ORCBpcyBjb21wYXRpYmxlIHdpdGggdGhlIHVzZSBvZiBsaW5r LWxheWVyIG1lc2ggb3IgWzxhIGhyZWY9Ii4vcmZjNDk0NCIgdGl0bGU9JyJUcmFuc21pc3Np b24gb2YgSVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTUuNCBOZXR3b3JrcyInPlJGQzQ5 NDQ8L2E+XQ0KICAgbWVzaCB0ZWNobmlxdWVzLCB3aGljaCBhbGxldmlhdGUgdGhlIG90aGVy d2lzZSBub24tdHJhbnNpdGl2ZSBuYXR1cmUNCiAgIG9mIHdpcmVsZXNzIGxpbmtzLiAgSWYg dXNlZCB0aHJvdWdob3V0IHRoZSBMb1dQQU4sIHRoaXMgc28tY2FsbGVkDQogICBNZXNoIFVu ZGVyIHRvcG9sb2d5IHRodXMgbWFrZXMgdGhlIGVudGlyZSBsaW5rIGFwcGVhciB0byB0aGUg SVAgbGF5ZXINCiAgIGFzIGhhdmluZyBhIGxpbmstbG9jYWwgc2NvcGUgY292ZXJpbmcgYWxs IHRoZSA2TG9XUEFOIGludGVyZmFjZXMgaW4NCiAgIHRoZSBMb1dQQU4uICBUaGlzIGtpbmQg b2YgTG9XUEFOIGlzIG1hZGUgdXAgb2YgaG9zdHMgYW5kIEVkZ2UNCiAgIFJvdXRlcnMuICBU aGlzIGxpbmsgc3RpbGwgZXhoaWJpdHMgbG9zc3ksIGxvdy1yYXRlLCBhc3ltbWV0cmljDQog ICBiZWhhdmlvciBhbG9uZyB3aXRoIHNsZWVwIGN5Y2xlcy4gIFRoZSBub24tdHJhbnNpdGl2 ZSBuYXR1cmUgb2YgdGhlDQogICBsaW5rIGNhbiBhbHNvIGJlIG92ZXJjb21lIHVzaW5nIElQ IHJvdXRpbmcgd2l0aGluIHRoZSBMb1dQQU4sIGFsc28NCiAgIGNhbGxlZCBhIFJvdXRlIE92 ZXIgdG9wb2xvZ3kuICA8c3BhbiBjbGFzcz1oaWxpdGU+Um91dGVyczwvc3Bhbj4gYXJlIHVz ZWQgaW4gdGhlIExvV1BBTg0KICAgdG8gcHJvdmlkZSByb3V0aW5nIGJldHdlZW4gYWxsIG5v ZGVzIGluIHRoZSBMb1dQQU4uICA8c3BhbiBjbGFzcz1oaWxpdGU+Um91dGVyPC9zcGFuPg0K ICAgb3BlcmF0aW9ucyBhcmUgc3BlY2lmaWVkIGluIDxhIGhyZWY9IiNzZWN0aW9uLTciPlNl Y3Rpb24gNzwvYT4uIDxzcGFuIGNsYXNzPWhpbGl0ZT5MPC9zcGFuPmluay1sb2NhbCBzY29w ZSBpbmNsdWRlcyB0aGUNCiAgIG5laWdoYm9ycyBvZiBlYWNoIG5vZGUgd2l0aGluIHN5bW1l dHJpYyB3aXJlbGVzcyByYW5nZS4gIE1lc2ggVW5kZXINCiAgIGFuZCBSb3V0ZSBPdmVyIHRl Y2huaXF1ZXMgYXJlIG5vdCBtdXR1YWxseSBleGNsdXNpdmUsIGFuZCBpdCBtYXkgYmUNCiAg IHBvc3NpYmxlIHRvIGNvbWJpbmUgSVAgcm91dGluZyBhbmQgbWVzaCBsaW5rLWxheWVycyB3 aXRoaW4gYSBMb1dQQU4uDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5LCBl dCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAgICAg W1BhZ2UgMTJdPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5hbWU9 InBhZ2UtMTMiIGlkPSJwYWdlLTEzIiBocmVmPSIjcGFnZS0xMyIgY2xhc3M9ImludmlzaWJs ZSI+IDwvYT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2 TG9XUEFOIE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFu PiANCiANCiANCjxzcGFuIGNsYXNzPSJoMyI+PGEgbmFtZT0ic2VjdGlvbi0zLjIiPjMuMjwv YT4uICBCb290c3RyYXBwaW5nPC9zcGFuPiANCiANCiAgIDEuICBBIG5vZGUgKGhvc3Qgb3Ig cm91dGVyKSBmaXJzdCBmb3JtcyBhbiBJbnRlcmZhY2UgSWRlbnRpZmllciAoSUlEKQ0KICAg ZnJvbSBpdHMgRVVJLTY0IG9yIG90aGVyIGFwcHJvcHJpYXRlIE1BQyBhZGRyZXNzLCBhbmQg Z29lcyBvbiB0byBmb3JtDQogICBhIGxpbmstbG9jYWwgdW5pY2FzdCBhZGRyZXNzIGFzIGlu IFs8YSBocmVmPSIuL3JmYzQ5NDQiIHRpdGxlPSciVHJhbnNtaXNzaW9uIG9mIElQdjYgUGFj a2V0cyBvdmVyIElFRUUgODAyLjE1LjQgTmV0d29ya3MiJz5SRkM0OTQ0PC9hPl0uICBXaGVu IGEgPHNwYW4gY2xhc3M9aGlsaXRlPm5vZGU8L3NwYW4+DQogICB3YW50cyB0byBqb2luIGEg TG9XUEFOLCBpdCBkb2VzIHNvIGJ5IGxpc3RlbmluZyBmb3IgUm91dGVyDQogICBBZHZlcnRp c2VtZW50cywgb3IgYnkgYnJvYWRjYXN0aW5nIGEgUm91dGVyIFNvbGljaXRhdGlvbiAoUlMp IGFuZA0KICAgcmVjZWl2aW5nIFJBIHJlc3BvbnNlcyBmcm9tIG9uLWxpbmsgcm91dGVycyAo c2VlIEZpZ3VyZSAyKS4gIElmIGENCiAgIHZhbGlkIHByZWZpeCBpcyBhZHZlcnRpc2VkIGlu IHRoZSBSQSwgdGhlIGhvc3QgbWF5IGFsc28gYXV0b2NvbmZpZ3VyZQ0KICAgYSBnbG9iYWwg YWRkcmVzcy4gIEF0IHRoaXMgcG9pbnQgdGhlIG5vZGUgaGFzIGFsc28gY2hvc2VuIG9uZSBv ciBtb3JlDQogICBkZWZhdWx0IHJvdXRlcnMgYmFzZWQgb24gUkFzLg0KIA0KICAgMi4gIE5l eHQgdGhlIG5vZGUgd2lsbCBhdHRlbXB0IHRvIHBlcmZvcm0gaW5pdGlhbCBOb2RlIFJlZ2lz dHJhdGlvbi4NCiAgIFJlZ2lzdHJhdGlvbiBpcyBhbHdheXMgcGVyZm9ybWVkIHdpdGggYSBs aW5rLWxvY2FsIDxzcGFuIGNsYXNzPWhpbGl0ZT5yPC9zcGFuPm91dGVyIGJ5IHNlbmRpbmcN CiAgIGEgdW5pY2FzdCBOb2RlIFJlZ2lzdHJhdGlvbiAoTlIpIG1lc3NhZ2UgdG8gaXQuICBU aGlzIG1lc3NhZ2UNCiAgIGV4Y2hhbmdlIGlzIGlsbHVzdHJhdGVkIGluIEZpZ3VyZSAzLiAg VGhlIE5SIGluY2x1ZGVzIHRoZSBhZGRyZXNzZXMNCiAgIHRoZSBub2RlIHdhbnRzIHRvIHJl Z2lzdGVyLCBhbmQgaXQgaXMgcG9zc2libGUgdG8gcmVxdWVzdCB0aGUgcm91dGVyDQogICB0 byBhc3NpZ24gYW4gYWRkcmVzcy4NCiANCiAgIDMuICBBZnRlciBwcm9jZXNzaW5nIHRoZSBh ZGRyZXNzZXMgYW5kIHBlcmZvcm1pbmcgREFEIGlmIG5lY2Vzc2FyeSwNCiAgIHRoZSA8c3Bh biBjbGFzcz1oaWxpdGU+cjwvc3Bhbj5vdXRlciByZXBsaWVzIHdpdGggYSBOb2RlIENvbmZp cm1hdGlvbiAoTkMpLiAgVGhpcyBjb25maXJtYXRpb24NCiAgIGluY2x1ZGVzIHRoZSBzZXQg b2YgYWRkcmVzc2VzIG5vdyBjb25maXJtZWQgYnkgdGhpcyByb3V0ZXIuICBUaGUgSG9zdA0K ICAgaXMgbm93IGNhcGFibGUgb2YgdXNpbmcgdGhlIExvV1BBTi4NCiANCiANCiAgIE5vZGUg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJv dXRlcg0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgIHwgICAgICAgLS0tLS0tLS0tLSBSb3V0ZXIgU29saWNp dGF0aW9uIC0tLS0tLS0tJmd0OyAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAg ICAgJmx0Oy0tLS0tLS0tIFJvdXRlciBBZHZlcnRpc2VtZW50IC0tLS0tLS0tLSAgICAgICAg ICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KIA0KIA0KICAgRmlndXJlIDI6IEJhc2ljIFJTL1JBIGV4Y2hh bmdlIGJldHdlZW4gYSBub2RlIGFuZCBhbnkgb24tbGluayByb3V0ZXINCiAgICAgICAgICAg ICAgICAgICAgICA8c3BhbiBjbGFzcz1oaWxpdGU+KG9yIEVkZ2UgUm91dGVyKTwvc3Bhbj4N CiANCiANCiANCiAgIE5vZGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBSb3V0ZXINCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgIC0tLS0t LS0tLS0gTm9kZSBSZWdpc3RyYXRpb24gLS0tLS0tLS0mZ3Q7ICAgICAgICAgICAgIHwNCiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICB8ICAgICAgICZsdDstLS0tLS0tLS0gTm9kZSBDb25maXJtYXRpb24g LS0tLS0tLS0tICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiANCiANCiAgICAgICAgICAg ICAgICAgRmlndXJlIDM6IEJhc2ljIE5EIHJlZ2lzdHJhdGlvbiBleGNoYW5nZQ0KIA0KIA0K IA0KIA0KPHNwYW4gY2xhc3M9ImdyZXkiPlNoZWxieSwgZXQgYWwuICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCA1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDEzXTwvc3Bhbj4gDQo8 L3ByZT48cHJlIGNsYXNzPSduZXdwYWdlJz48YSBuYW1lPSJwYWdlLTE0IiBpZD0icGFnZS0x NCIgaHJlZj0iI3BhZ2UtMTQiIGNsYXNzPSJpbnZpc2libGUiPiA8L2E+IA0KPHNwYW4gY2xh c3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAgICAgICAgNkxvV1BBTiBOZWlnaGJvciBEaXNj b3ZlcnkgICAgICAgICAgRmVicnVhcnkgMjAxMDwvc3Bhbj4gDQogDQogDQo8c3BhbiBjbGFz cz0iaDMiPjxhIG5hbWU9InNlY3Rpb24tMy4zIj4zLjM8L2E+LiAgT3BlcmF0aW9uPC9zcGFu PiANCiANCiAgIFRoZSBub2RlIG1heSBub3cgc2VuZCBwYWNrZXRzIHRvIGFueSBJUHY2IGFk ZHJlc3MgaW5zaWRlIG9yIG91dHNpZGUNCiAgIHRoZSBMb1dQQU4uICBOZXh0LWhvcCBkZXRl cm1pbmF0aW9uIGFzc3VtZXMgZGVzdGluYXRpb25zIGFyZSBvZmYtbGluaw0KICAgKGFuZCB0 aHVzIGZvcndhcmRlZCB0byBhIGRlZmF1bHQgcm91dGVyKSBleGNlcHQgZm9yIGxpbmstbG9j YWwgc2NvcGUNCiAgIGFkZHJlc3NlcyB3aGljaCBhcmUgYWx3YXlzIG9uLWxpbmsuICBUaGUg aW5mb3JtYXRpb24gbmVlZGVkIGZvcg0KICAgcmVzb2x2aW5nIHRoZSBsaW5rLWxheWVyIGFk ZHJlc3Mgb2YgZGVmYXVsdCByb3V0ZXJzIG9yIHJlZ2lzdGVyZWQNCiAgIG5vZGVzIGlzIGtu b3duIGEgcHJpb3JpIGFzIGEgcmVzdWx0IG9mIG5vZGUgcmVnaXN0cmF0aW9uLg0KIA0KICAg VGhlIDxzcGFuIGNsYXNzPWhpbGl0ZT5yb3V0ZXI8L3NwYW4+IGJpbmRpbmcgdGFibGUgaXMg c29mdCwgYW5kIHRodXMgbXVzdCBiZSByZW5ld2VkDQogICBwZXJpb2RpY2FsbHkgYXMgaW5k aWNhdGVkIGJ5IHRoZSBsaWZldGltZSBvZiB0aGUgYmluZGluZy4gIFRoaXMgaXMNCiAgIGFj aGlldmVkIGJ5IHBlcmlvZGljYWxseSBzZW5kaW5nIGEgbmV3IE5SIG1lc3NhZ2UuICBJZiBh IGhvc3QgbW92ZXMsDQogICBvciB0aGUgbmV0d29yayB0b3BvbG9neSBjaGFuZ2VzLCBhbmQg dGhlIGN1cnJlbnQgcm91dGVycyBhcmUgbm8NCiAgIGxvbmdlciBhdmFpbGFibGUsIHRoZSBo b3N0IHRoZW4gc3RhcnRzIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyB3aXRoDQogICBhbm90 aGVyIHJvdXRlci4gIElmIHRoZSBob3N0IGlzIHN0aWxsIGluIHRoZSBzYW1lIExvV1BBTiAo c2FtZSBzdWJuZXQNCiAgIHByZWZpeCksIGl0cyBJUHY2IGFkZHJlc3NlcyByZW1haW4gdGhl IHNhbWUuICBJZiB0aGUgaG9zdCBtb3ZlcyB0byBhDQogICBkaWZmZXJlbnQgTG9XUEFOICh0 aHVzIHdpdGggYSBkaWZmZXJlbnQgc3VibmV0IHByZWZpeCksIHRoZQ0KICAgYm9vdHN0cmFw cGluZyBwcm9jZXNzIGlzIGluaXRpYXRlZCBhZ2Fpbi4gIFNlZSA8YSBocmVmPSIjc2VjdGlv bi02Ij5TZWN0aW9uIDY8L2E+IGZvciBkZXRhaWxzDQogICBvbiBub2RlIG9wZXJhdGlvbi4N CiANCiAgIDxzcGFuIGNsYXNzPWhpbGl0ZT5Sb3V0ZXI8L3NwYW4+cyBwZXJpb2RpY2FsbHkg c2VuZCBSQXMgdG8gdGhlaXIgbmVpZ2hib3JzLiAgVGhlIEVkZ2UNCiAgIFJvdXRlciBpbml0 aWF0ZXMgdGhlIGZpcnN0IFJBcywgYW5kIGluZm9ybWF0aW9uIGZyb20gdGhlc2UgUkFzIGlz DQogICBpbmNsdWRlZCBpbiB0aGUgUkFzIG9mIGVhY2ggZnVydGhlciByb3V0ZXIsIGNhdXNp bmcgdGhlIGluZm9ybWF0aW9uDQogICB0byBiZSBkaXNzZW1pbmF0ZWQgdGhyb3VnaG91dCB0 aGUgTG9XUEFOLiAgUkEgcGVyaW9kcyBzaG91bGQgYmUNCiAgIG9wdGltaXplZCB0byByZWR1 Y2Ugc2lnbmFsbGluZy4gIFNlZSA8YSBocmVmPSIjc2VjdGlvbi03Ij5TZWN0aW9uIDc8L2E+ IGZvciBkZXRhaWxlZCByb3V0ZXINCiAgIG9wZXJhdGlvbi4NCiANCiANCjxzcGFuIGNsYXNz PSJoMiI+PGEgbmFtZT0ic2VjdGlvbi00Ij40PC9hPi4gIE1lc3NhZ2UgRm9ybWF0czwvc3Bh bj4gDQogDQogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyB0aGUgbWVzc2FnZSBhbmQgb3B0aW9u IGZvcm1hdHMgdXNlZCBpbiB0aGlzDQogICBkb2N1bWVudC4gIFRoZSBuZXcgbWVzc2FnZXMg YXJlIGFsbCBJQ01QdjYgbWVzc2FnZXMuICBJbiBhZGRpdGlvbiwNCiAgIG5ldyBvcHRpb25z IGZvciBJQ01QdjYgbWVzc2FnZXMgYXJlIGRlZmluZWQuDQogDQogICBUaGUgZm9sbG93aW5n IG5ldyBJQ01QdjYgbWVzc2FnZSB0eXBlcyBhcmUgZGVmaW5lZDoNCiANCiAgIG8gIE5vZGUg UmVnaXN0cmF0aW9uIChOUikNCiANCiAgIG8gIE5vZGUgQ29uZmlybWF0aW9uIChOQykNCiAN CiAgIEluIGFkZGl0aW9uLCB0aGUgZm9sbG93aW5nIG5ldyBJQ01QdjYgb3B0aW9ucyBhcmUg ZGVmaW5lZDoNCiANCiAgIG8gIDZMb1dQQU4gQWRkcmVzcyBPcHRpb24gKDZBTykNCiANCiAg IG8gIDZMb1dQQU4gSW5mb3JtYXRpb24gT3B0aW9uICg2SU8pDQogDQogICBvICA2TG9XUEFO IFN1bW1hcnkgT3B0aW9uICg2U08pDQogDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+ U2hlbGJ5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAg ICAgICAgICAgW1BhZ2UgMTRdPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2Un PjxhIG5hbWU9InBhZ2UtMTUiIGlkPSJwYWdlLTE1IiBocmVmPSIjcGFnZS0xNSIgY2xhc3M9 ImludmlzaWJsZSI+IDwvYT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQg ICAgICAgICA2TG9XUEFOIE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAy MDEwPC9zcGFuPiANCiANCiANCiAgIG8gIE93bmVyIEludGVyZmFjZSBJZGVudGlmaWVyIE9w dGlvbiAoT0lJTykNCiANCiAgIFRoZSBmb2xsb3dpbmcgWzxhIGhyZWY9Ii4vcmZjNDg2MSIg dGl0bGU9JyJOZWlnaGJvciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiJz5S RkM0ODYxPC9hPl0gbWVzc2FnZXMgYXJlIHVzZWQgYXMgc3BlY2lmaWVkIGluIHRoaXMNCiAg IHNlY3Rpb246DQogDQogICBvICBSb3V0ZXIgU29saWNpdGF0aW9uIChSUykNCiANCiAgIG8g IFJvdXRlciBBZHZlcnRpc2VtZW50IChSQSkNCiANCjxzcGFuIGNsYXNzPSJoMyI+PGEgbmFt ZT0ic2VjdGlvbi00LjEiPjQuMTwvYT4uICBOb2RlIFJlZ2lzdHJhdGlvbi9Db25maXJtYXRp b24gTWVzc2FnZTwvc3Bhbj4gDQogDQogICBUaGUgTm9kZSBSZWdpc3RyYXRpb24gKE5SKSBh bmQgTm9kZSBDb25maXJtYXRpb24gKE5DKSBtZXNzYWdlcyBhcmUNCiAgIHVzZWQgYnkgYSBu b2RlIHRvIHJlZ2lzdGVyIHdpdGggYSA8c3BhbiBjbGFzcz1oaWxpdGU+cjwvc3Bhbj5vdXRl ci4gIEFueSBvcHRpb24gdGhhdCBpcyBub3QNCiAgIHJlY29nbml6ZWQgTVVTVCBiZSBza2lw cGVkIHNpbGVudGx5LiAgVGhlIE5vZGUgUmVnaXN0cmF0aW9uIG1lc3NhZ2UNCiAgIGlzIHNl bnQgYnkgdGhlIDxzcGFuIGNsYXNzPWhpbGl0ZT5ub2RlPC9zcGFuPiB0byB0aGUgbGluay1s b2NhbCB1bmljYXN0IElQdjYgYWRkcmVzcyBvZg0KICAgYSBvbi1saW5rIDxzcGFuIGNsYXNz PWhpbGl0ZT5yPC9zcGFuPm91dGVyLg0KIA0KICAgV2hlbiByZWdpc3RlcmluZyA8c3BhbiBj bGFzcz1oaWxpdGU+Zm9yIHRoZSBmaXJzdCB0aW1lLCB0aGUgbm9kZSBzdGlsbCBoYXMNCiAg IG9wdGltaXN0aWMgYWRkcmVzc2VzIHRoZXJlZm9yZSB0aGU8L3NwYW4+IHNvdXJjZSBhZGRy ZXNzDQogICBvZiB0aGUgTm9kZSBSZWdpc3RyYXRpb24gbXVzdCBiZSB0aGUgSVB2NiB1bnNw ZWNpZmllZCBhZGRyZXNzIHRvDQogICBjb21wbHkgd2l0aCBvREFELiAgSW4gc3Vic2VxdWVu dCByZWdpc3RyYXRpb25zLCB0aGUgSVB2NiBzb3VyY2UNCiAgIGFkZHJlc3MgaXMgdGhlbiB0 aGUgbGluay1sb2NhbCBJUHY2IGFkZHJlc3Mgb2YgdGhlIHNlbmRlci4gIEENCiAgIHJlZ2lz dHJhdGlvbiBpcyBwZXJpb2RpY2FsbHkgcmVmcmVzaGVkIGJ5IHNlbmRpbmcgYSBuZXcgTlIg bWVzc2FnZQ0KICAgbW9yZSBmcmVxdWVudGx5IHRoYW4gdGhlIEJpbmRpbmcgTGlmZXRpbWUg aW5kaWNhdGVkIGJ5IHRoZSBub2RlDQogICBkdXJpbmcgPHNwYW4gY2xhc3M9aGlsaXRlPnJl Z2lzdHJhdGlvbjwvc3Bhbj4uDQogDQogICBBZGRyZXNzIE9wdGlvbnMgYXJlIGluY2x1ZGVk IGluIHRoZSBOUiBtZXNzYWdlIGZvciBlYWNoIElQdjYgYWRkcmVzcw0KICAgdG8gYmUgcmVn aXN0ZXJlZCwgYW5kIGluY2x1ZGVkIGluIHRoZSBjb3JyZXNwb25kaW5nIE5DIHRvIGluZGlj YXRlDQogICBzdWNjZXNzLg0KIA0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQogICB8ICAgICBUeXBlICAgICAgfFN0YXR1cyB8IENvZGUgIHwgICAgICAg ICAgIENoZWNrc3VtICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICBU SUQgICAgICB8UHxSfCAgICAgICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgICAgICAg ICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgQmluZGluZyBMaWZldGltZSAgICAg ICB8ICAgICAgICAgICAgUmVzZXJ2ZWQgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICB8ICAgICAgICAgICAgICAgICAgICAgICAgIE93bmVyIE5vbmNlICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArICAg ICAgICAgICAgICAgICAgT3duZXIgSW50ZXJmYWNlIElkZW50aWZpZXIgICAgICAgICAgICAg ICAgICAgKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgUmVnaXN0 cmF0aW9uIG9wdGlvbihzKS4uLg0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog DQogICAgICAgICAgRmlndXJlIDQ6IE5vZGUgUmVnaXN0cmF0aW9uL0NvbmZpcm1hdGlvbiBt ZXNzYWdlIGZvcm1hdA0KIA0KIA0KIA0KPHNwYW4gY2xhc3M9ImdyZXkiPlNoZWxieSwgZXQg YWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA1LCAyMDEwICAgICAgICAgICAgICAgIFtQ YWdlIDE1XTwvc3Bhbj4gDQo8L3ByZT48cHJlIGNsYXNzPSduZXdwYWdlJz48YSBuYW1lPSJw YWdlLTE2IiBpZD0icGFnZS0xNiIgaHJlZj0iI3BhZ2UtMTYiIGNsYXNzPSJpbnZpc2libGUi PiA8L2E+IA0KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAgICAgICAgNkxv V1BBTiBOZWlnaGJvciBEaXNjb3ZlcnkgICAgICAgICAgRmVicnVhcnkgMjAxMDwvc3Bhbj4g DQogDQogDQogICBJUCBGaWVsZHM6DQogDQogICAgICBTb3VyY2UgQWRkcmVzczogIFRoZSBJ UHY2IGFkZHJlc3Mgb2YgdGhlIHNvdXJjZS4gIFRoaXMgYWRkcmVzcw0KICAgICAgICAgTVVT VCBiZSB0aGUgSVB2NiB1bnNwZWNpZmllZCBhZGRyZXNzIGZvciBpbml0aWFsIHJlZ2lzdHJh dGlvbi4NCiANCiAgICAgIERlc3RpbmF0aW9uIEFkZHJlc3M6ICBUaGUgbGluay1sb2NhbCB1 bmljYXN0IElQdjYgYWRkcmVzcyBvZiBhIG9uLQ0KICAgICAgICAgbGluayByb3V0ZXIgd2hl biBzZW50IGJ5IGEgbm9kZS4NCiANCiAgICAgIEhvcCBMaW1pdDogIDI1NQ0KIA0KICAgSUNN UCBGaWVsZHM6DQogDQogICAgICBUeXBlOiAgVEJEMSBmb3IgTm9kZSBSZWdpc3RyYXRpb24s IFRCRDIgZm9yIE5vZGUgQ29uZmlybWF0aW9uLg0KIA0KICAgICAgU3RhdHVzOiAgNC1iaXQg dW5zaWduZWQgaW50ZWdlci4gIFNlbnQgb25seSBpbiBOQyBtZXNzYWdlcywNCiAgICAgICAg IGlnbm9yZWQgaW4gTlIgbWVzc2FnZXMuICBWYWx1ZXMgMC03IGFyZSByZXNlcnZlZCBmb3Ig c3VjY2Vzcw0KICAgICAgICAgY29kZXM6DQogDQogICAgICAgICAgICAwIGlzIHVucXVhbGlm aWVkIHN1Y2Nlc3MuDQogDQogICAgICAgICBWYWx1ZXMgOC0xNSBhcmUgcmVzZXJ2ZWQgZm9y IGVycm9yIGNvZGVzOg0KIA0KICAgICAgICAgICAgOCBpcyBzZW5kIHRvIGluZGljYXRlIHRo YXQgdGhlIHJvdXRlciBpcyBzYXR1cmF0ZWQgYW5kIGFuDQogICAgICAgICAgICBhbHRlcm5h dGl2ZSByb3V0ZXIgc2hvdWxkIGJlIHVzZWQuDQogDQogICAgICBDb2RlOiAgNC1iaXQgdW5z aWduZWQgaW50ZWdlci4NCiANCiAgICAgICAgICAgIDAgaW5kaWNhdGVzIHRoaXMgTlIgaXMg YSByZXF1ZXN0IHNlbnQgZGlyZWN0bHkgZnJvbSB0aGUNCiAgICAgICAgICAgIG9yaWdpbmF0 aW5nIGhvc3QsIG9yIHRoaXMgTkMgaXMgYSBjb3JyZXNwb25kaW5nIHJlc3BvbnNlLg0KIA0K ICAgICAgICAgICAgMSBpbmRpY2F0ZXMgdGhhdCB0aGUgTlIgbWVzc2FnZSBoYXMgYmVlbiBy ZWxheWVkIGJ5IGENCiAgICAgICAgICAgIHJvdXRlciwgb3IgdGhhdCB0aGUgTkMgaXMgdG8g YmUgcmVsYXllZCBieSB0aGUgcm91dGVyDQogICAgICAgICAgICBpbmRpY2F0ZWQgYXMgdGhl IGRlc3RpbmF0aW9uLiAgKEZvciBmdXR1cmUgdXNlKQ0KIA0KICAgICAgICAgICAgMiBpbmRp Y2F0ZXMgdGhpcyBOQyBpcyBhIDxhIGNsYXNzPWNvbW1lbnQgaHJlZj0iIyIgdGl0bGU9IiZx dW90O3Vuc29saWNpdGVkIHJlcXVlc3QmcXVvdDs/Ij5yZXF1ZXN0PC9hPiBmb3IgdGhlIG5v ZGUgdG8gcmUtDQogICAgICAgICAgICByZWdpc3Rlci4NCiANCiAgICAgICAgICAgIDQtMTUg YXJlIHJlc2VydmVkIGZvciBmdXR1cmUgdXNlLg0KIA0KICAgICAgQ2hlY2tzdW06ICBUaGUg SUNNUCBjaGVja3N1bS4NCiANCiAgICAgIFRJRDogIDgtYml0IHVuc2lnbmVkIGludGVnZXIu ICBBIHVuaXF1ZSBUcmFuc2FjdGlvbiBJRCBhc3NpZ25lZCBieQ0KICAgICAgICAgdGhlIGhv c3QgYW5kIHVzZWQgdG8gbWF0Y2ggcmVwbGllcy4gIEEgbG9sbGlwb3AgbWVjaGFuaXNtIGlz DQogICAgICAgICB1c2VkIHRvIGluY3JlbWVudCB0aGUgVElEIHVwb24gZWFjaCBuZXcgcmVn aXN0cmF0aW9uLiAgVGhlIFRJRA0KICAgICAgICAgaXMgbm90IGluY3JlbWVudGVkIHVwb24g YSBvbi1saW5rIHJlZnJlc2guICBJbiBhIE5vZGUNCiAgICAgICAgIENvbmZpcm1hdGlvbjxz cGFuIGNsYXNzPWhpbGl0ZT4sIHRoZTwvc3Bhbj4gVElEIGlzIHRoYXQgb2YgdGhlIGNvcnJl c3BvbmRpbmcgTlIuICBUSUQgaXMgc2V0DQogICAgICAgICB0byAwIHVwb24gYm9vdGluZywg YW5kIGlzIGluY3JlbWVudGVkIHdpdGggZWFjaCBOUiBtZXNzYWdlLg0KICAgICAgICAgQWZ0 ZXIgcmVhY2hpbmcgMHhGRiwgdGhlIHZhbHVlIGxvb3BzIHRvIDE2ICgweDEwKSBhbmQgaXMN CiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAxNl08L3NwYW4+ IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+PGEgbmFtZT0icGFnZS0xNyIgaWQ9InBh Z2UtMTciIGhyZWY9IiNwYWdlLTE3IiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxzcGFu IGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hib3Ig RGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAgICAg ICAgaW5jcmVtZW50ZWQgZnJvbSB0aGVyZS4gIFRodXMgdGhlIHZhbHVlcyBiZXR3ZWVuIDAt MTUgTVVTVCBvbmx5DQogICAgICAgICB1c2VkIGFmdGVyIGEgYm9vdCBvciByZWJvb3QuDQog DQogICAgICBQOiAxLWJpdCBQcmltYXJ5IGZsYWcuICBOb3QgeWV0IHVzZWQgYnkgdGhpcyBz cGVjaWZpY2F0aW9uLCBhbHdheXMNCiAgICAgICAgIHNldCB0byAxLg0KIA0KICAgICAgUjog MS1iaXQgUm91dGVyIGZsYWcuICBVc2VkIHRvIGluZGljYXRlIHRoZSByb2xlIG9mIG5vZGUg c2VuZGluZw0KICAgICAgICAgdGhlIE5SIG1lc3NhZ2UuICBTZXQgdG8gMCBieSBob3N0cyBh bmQgdG8gMSBieSByb3V0ZXJzLg0KIA0KICAgICAgQmluZGluZyBMaWZldGltZTogIDE2LWJp dCB1bnNpZ25lZCBpbnRlZ2VyLiAgVGhlIGFtb3VudCBvZiB0aW1lIGluDQogICAgICAgICAx MCBzZWNvbmQgaW50ZXJ2YWxzIHJlbWFpbmluZyBiZWZvcmUgdGhlIGJpbmRpbmcgb2YgdGhp cyBvd25lcg0KICAgICAgICAgaW50ZXJmYWNlIGlkZW50aWZpZXIsIGFuZCBhbGwgYXNzb2Np YXRlZCBhZGRyZXNzIG9wdGlvbnMgYW5kDQogICAgICAgICBjb25maWd1cmF0aW9uIG9wdGlv bnMsIE1VU1QgYmUgY29uc2lkZXJlZCBleHBpcmVkLiAgQSB2YWx1ZSBvZg0KICAgICAgICAg emVybyBpbmRpY2F0ZXMgdGhhdCB0aGUgQmluZGluZyBDYWNoZSBlbnRyaWVzIGZvciB0aGUN CiAgICAgICAgIHJlZ2lzdGVyZWQgb3duZXIgaW50ZXJmYWNlIGlkZW50aWZpZXIgTVVTVCBi ZSBkZWxldGVkLiAgQSB2YWx1ZQ0KICAgICAgICAgb2YgMHhGRkZGIGluZGljYXRlcyBhbiBp ZGVmaW5pdGUgbGlmZXRpbWUuICAoVGhlIDE2LWJpdCBmaWVsZA0KICAgICAgICAgY292ZXJz IHVwIHRvIHNsaWdodGx5IG1vcmUgdGhhbiBhIHdlZWsgb2YgQmluZGluZyBMaWZldGltZS4p DQogDQogICAgICBSZXNlcnZlZDogIFRoaXMgZmllbGQgaXMgdW51c2VkLiAgSXQgTVVTVCBi ZSBpbml0aWFsaXplZCB0byB6ZXJvDQogICAgICAgICBieSB0aGUgc2VuZGVyIGFuZCBNVVNU IGJlIGlnbm9yZWQgYnkgdGhlIHJlY2VpdmVyLg0KIA0KICAgICAgT3duZXIgSW50ZXJmYWNl IElkZW50aWZpZXIgKE9JSSk6ICBBIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVyDQogICAg ICAgICBmb3IgdGhlIHJlcXVlc3RpbmcgaG9zdCdzIGludGVyZmFjZS4gIFR5cGljYWxseSB0 aGUgRVVJLTY0DQogICAgICAgICBkZXJpdmVkIElJRC4NCiANCiAgICAgIE93bmVyIE5vbmNl OiAgQSAzMi1iaXQgTm9uY2UgZ2VuZXJhdGVkIHJhbmRvbWx5IGJ5IHRoZSBub2RlIHVwb24N CiAgICAgICAgIGJvb3RpbmcsIGFuZCBnZW5lcmF0ZWQgYWdhaW4gZWFjaCB0aW1lIHRoZSBu b2RlIHJlLWJvb3RzLiAgVGhpcw0KICAgICAgICAgTm9uY2UgbWF5IGJlIHVzZWQgdG8gZGV0 ZWN0IGR1cGxpY2F0ZSBPSUlzLg0KIA0KICAgUG9zc2libGUgT3B0aW9uczoNCiANCiAgICAg IDZMb1dQQU4gQWRkcmVzcyBPcHRpb24ocyk6ICBBbiBBZGRyZXNzIE9wdGlvbiBpcyBpbmNs dWRlZCBmb3IgZWFjaA0KICAgICAgICAgYWRkcmVzcyB0aGUgaG9zdCB3YW50cyB0byBiaW5k IGZvciB0aGlzIGludGVyZmFjZS4NCiANCiAgICAgIDZMb1dQQU4gSW5mb3JtYXRpb24gT3B0 aW9uOiAgVGhpcyBvcHRpb24gaW5jbHVkZXMgaW5mb3JtYXRpb24NCiAgICAgICAgIGFib3V0 IHRoZSBwcmVmaXhlcyBvZiB0aGUgTG9XUEFOIGFsb25nIHdpdGggb3RoZXIgY29udGV4dA0K ICAgICAgICAgaW5mb3JtYXRpb24uICBBbHRob3VnaCBub3JtYWxseSBjYXJyaWVkIGluIFJB IG1lc3NhZ2VzLCBhIDZJTw0KICAgICAgICAgb3B0aW9uIE1BWSBhbHNvIGJlIGNhcnJpZWQg aW4gTkMgbWVzc2FnZXMuDQogDQogICAgICBGdXR1cmUgdmVyc2lvbnMgb2YgdGhpcyBwcm90 b2NvbCBtYXkgZGVmaW5lIG5ldyBvcHRpb24gdHlwZXMuDQogICAgICBSZWNlaXZlcnMgTVVT VCBzaWxlbnRseSBpZ25vcmUgYW55IG9wdGlvbnMgdGhleSBkbyBub3QgcmVjb2duaXplDQog ICAgICBhbmQgY29udGludWUgcHJvY2Vzc2luZyB0aGUgbWVzc2FnZS4NCiANCjxzcGFuIGNs YXNzPSJoMyI+PGEgbmFtZT0ic2VjdGlvbi00LjIiPjQuMjwvYT4uICBSb3V0ZXIgU29saWNp dGF0aW9uIE1lc3NhZ2U8L3NwYW4+IA0KIA0KICAgVGhlIFJTIG1lc3NhZ2UgZm9ybWF0IGZv ciA2TG9XUEFOIGlzIGlkZW50aWNhbCB0byB0aGUgY2xhc3NpYw0KICAgWzxhIGhyZWY9Ii4v cmZjNDg2MSIgdGl0bGU9JyJOZWlnaGJvciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAo SVB2NikiJz5SRkM0ODYxPC9hPl0gUlMgbWVzc2FnZS4gIFRoZSBmb2xsb3dpbmcgY2xhcmlm aWNhdGlvbnMgYXJlIG1hZGUNCiAgIHJlZ2FyZGluZyB0aGUgdXNlIG9mIFJTIGluIExvV1BB TnMuDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5LCBldCBhbC4gICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMTddPC9z cGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5hbWU9InBhZ2UtMTgiIGlk PSJwYWdlLTE4IiBocmVmPSIjcGFnZS0xOCIgY2xhc3M9ImludmlzaWJsZSI+IDwvYT4gDQo8 c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2TG9XUEFOIE5laWdo Ym9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFuPiANCiANCiANCiAg IElmIGEgbm9kZSBoYXMgb25seSBvcHRpbWlzdGljIGFkZHJlc3NlcyBub3QgeWV0IGNvbmZp cm1lZCBieSBhDQogICBSb3V0ZXIsIHRoZW4gdGhlIElQdjYgc291cmNlIGFkZHJlc3MgaW4g dGhlIFJTIE1VU1QgYmUgdGhlIElQdjYNCiAgIHVuc3BlY2lmaWVkIGFkZHJlc3MuICBUaGUg U291cmNlIExpbmstTGF5ZXIgQWRkcmVzcyBPcHRpb24gTVVTVCBOT1QNCiAgIGJlIGluY2x1 ZGVkIGluIHRoZSBSUyBhdCBhbnkgdGltZS4gIEluc3RlYWQgdGhlIE93bmVyIEludGVyZmFj ZQ0KICAgSWRlbnRpZmllciBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBNVVNUIGJlIGlu Y2x1ZGVkIGluIHRoZSBSUy4NCiANCiAgIFRoZSBDb2RlIGZpZWxkIG9mIHRoZSBSb3V0ZXIg U29saWNpdGF0aW9uIG1lc3NhZ2UgaXMgdXNlZCB0bw0KICAgPHNwYW4gY2xhc3M9aGlsaXRl PmluZGljYXRlPC9zcGFuPiB3aGV0aGVyIGEgbm9kZSB3YW50cyB0byByZWNlaXZlIHRoZSBm dWxsIHNldCBvZiA2SU9zIGluIHRoZQ0KICAgUkEgcmVzcG9uc2UsIG9yIGp1c3QgdGhlIDZT Ty4gIEFuIFJTIHdpdGggQ29kZSA9IDAgaXMgdXNlZCB0byByZXF1ZXN0DQogICBqdXN0IHRo ZSA2TG9XUEFOIFN1bW1hcnkgT3B0aW9uLCBhbmQgQ29kZSA9IDEgaXMgdXNlZCB0byByZXF1 ZXN0IHRoZQ0KICAgZnVsbCBzZXQgb2YgNklPcy4NCiANCjxzcGFuIGNsYXNzPSJoMyI+PGEg bmFtZT0ic2VjdGlvbi00LjMiPjQuMzwvYT4uICBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBNZXNz YWdlPC9zcGFuPiANCiANCiAgIFRoZSBSQSBtZXNzYWdlIGZvcm1hdCBmb3IgNkxvV1BBTiBp cyBpZGVudGljYWwgdG8gdGhlIGNsYXNzaWMNCiAgIFs8YSBocmVmPSIuL3JmYzQ4NjEiIHRp dGxlPSciTmVpZ2hib3IgRGlzY292ZXJ5IGZvciBJUCB2ZXJzaW9uIDYgKElQdjYpIic+UkZD NDg2MTwvYT5dIFJBIG1lc3NhZ2UuICBUaGUgdXNlIG9mIGZsYWdzIGlzIGhvd2V2ZXIgZGVm aW5lZCBpbiB0aGUNCiAgIDZMb1dQQU4gY29udGV4dCwgYW5kIGFkZGl0aW9uYWwgbmV3IG9w dGlvbnMgYXJlIGlkZW50aWZpZWQuICBSQQ0KICAgbWVzc2FnZXMgYXJlIHNlbnQgZWl0aGVy IHRvIGxpbmstbG9jYWwgYWxsLW5vZGVzIG11bHRpY2FzdCwgb3IgdG8gYQ0KICAgbGluay1s b2NhbCB1bmljYXN0IGFkZHJlc3MgYXMgYSByZXNwb25zZSB0byBhbiBSUy4NCiANCiAgIFVw ZGF0ZWQgRmxhZyBEZWZpbml0aW9uczoNCiANCiAgICAgIFByZjogIDItYml0IHNpZ25lZCBp bnRlZ2VyLiAgRGVmYXVsdCBSb3V0ZXIgUHJlZmVyZW5jZSBhcyBkZWZpbmVkDQogICAgICAg ICBpbiBbPGEgaHJlZj0iLi9yZmM0MTkxIiB0aXRsZT0nIkRlZmF1bHQgUm91dGVyIFByZWZl cmVuY2VzIGFuZCBNb3JlLVNwZWNpZmljIFJvdXRlcyInPlJGQzQxOTE8L2E+XS4gIEluZGlj YXRlcyB3aGV0aGVyIHRvIHByZWZlciB0aGlzIHJvdXRlciBvdmVyDQogICAgICAgICBvdGhl ciBkZWZhdWx0IHJvdXRlcnMuICA8c3BhbiBjbGFzcz1oaWxpdGU+Um91dGVyPC9zcGFuPnMg d2l0aCBubyA8c3BhbiBjbGFzcz1oaWxpdGU+RWRnZSBSb3V0ZXI8L3NwYW4+IGF2YWlsYWJs ZQ0KICAgICAgICAgTVVTVCBzZXQgUHJmIHRvICgxMSkgZm9yIGxvdyBwcmVmZXJlbmNlLCA8 c3BhbiBjbGFzcz1oaWxpdGU+cm91dGVyPC9zcGFuPnMgd2l0aCA8c3BhbiBjbGFzcz1oaWxp dGU+RWRnZSBSb3V0ZXI8L3NwYW4+DQogICAgICAgICA8YSBjbGFzcz1jb21tZW50IGhyZWY9 IiMiIHRpdGxlPSJXaGF0IGlzIEVkZ2UgUm91dGVyIGF2YWlsYWJpbGl0eT8gTm90IGRlZmlu ZWQgYW55d2hlcmUiPmF2YWlsYWJpbGl0eTwvYT4gTVVTVCBzZXQgUHJmIHRvICgwMCkgZm9y IG5vcm1hbCBwcmVmZXJlbmNlLCBhbmQNCiAgICAgICAgIDxzcGFuIGNsYXNzPWhpbGl0ZT5F ZGdlIFJvdXRlcjwvc3Bhbj5zIE1VU1Qgc2V0IFByZiB0byAoMDEpIGZvciBoaWdoIHByZWZl cmVuY2UuDQogDQogICBPcHRpb25zOg0KIA0KICAgICAgNkxvV1BBTiBJbmZvcm1hdGlvbiBP cHRpb246ICBUaGlzIG9wdGlvbiBpbmNsdWRlcyBpbmZvcm1hdGlvbg0KICAgICAgICAgYWJv dXQgdGhlIHByZWZpeGVzIG9mIHRoZSBMb1dQQU4gYWxvbmcgd2l0aCBvdGhlciBjb250ZXh0 DQogICAgICAgICBpbmZvcm1hdGlvbi4NCiANCiAgICAgIDZMb1dQQU4gU3VtbWFyeSBPcHRp b246ICBUaGlzIG9wdGlvbiBwcm92aWRlcyBhIHNlcXVlbmNlIG51bWJlcg0KICAgICAgICAg YXNzb2NpYXRlZCB3aXRoIHRoZSBjdXJyZW50IHByZWZpeCBvcHRpb25zLiAgSXQgYWxsb3dz IHRoZQ0KICAgICAgICAgcHJlZml4IG9wdGlvbnMgdGhlbXNlbHZlcyB0byBiZSBzZW50IG9u bHkgd2hlbiBhIGNoYW5nZSBoYXMNCiAgICAgICAgIG9jY3VyZWQsIG9yIHdoZW4gcmVxdWVz dGVkIHdpdGggYW4gUlMgQ29kZSA9IDEuDQogDQogICAgICBQcmVmaXggSW5mb3JtYXRpb24g T3B0aW9uOiAgSWYgbmVlZGVkIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LA0KICAgICAg ICAgYW4gUkEgbWF5IGFsc28gYmUgc2VudCB1c2luZyB0aGUgY2xhc3NpYyBbPGEgaHJlZj0i Li9yZmM0ODYxIiB0aXRsZT0nIk5laWdoYm9yIERpc2NvdmVyeSBmb3IgSVAgdmVyc2lvbiA2 IChJUHY2KSInPlJGQzQ4NjE8L2E+XSBQcmVmaXgNCiAgICAgICAgIEluZm9ybWF0aW9uIE9w dGlvbiB3aGljaCBhbGwgTG9XUEFOIG5vZGVzIE1VU1QgYmUgYWJsZSB0bw0KICAgICAgICAg cGFyc2UuICBJZiBwb3NzaWJsZSwgcm91dGVycyBpbiB0aGUgTG9XUEFOIFNIT1VMRCBtYWtl IHVzZSBvZg0KICAgICAgICAgNklPIGFuZCA2U08gb3B0aW9ucyBpbnN0ZWFkIG9mIFBJTy4N CiANCiAgICAgIFRoZSBNVFUgYW5kIFNMTEFPIG9wdGlvbnMgZGVmaW5lZCBpbiBbPGEgaHJl Zj0iLi9yZmM0ODYxIiB0aXRsZT0nIk5laWdoYm9yIERpc2NvdmVyeSBmb3IgSVAgdmVyc2lv biA2IChJUHY2KSInPlJGQzQ4NjE8L2E+XSBhcmUgbm90IHVzZWQgYnkNCiAgICAgIHRoaXMg c3BlY2lmaWNhdGlvbi4NCiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5Ij5TaGVsYnksIGV0 IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAgICAgICAgICBb UGFnZSAxOF08L3NwYW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+PGEgbmFtZT0i cGFnZS0xOSIgaWQ9InBhZ2UtMTkiIGhyZWY9IiNwYWdlLTE5IiBjbGFzcz0iaW52aXNpYmxl Ij4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgIDZM b1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTA8L3NwYW4+ IA0KIA0KIA0KICAgICAgRnV0dXJlIHZlcnNpb25zIG9mIHRoaXMgcHJvdG9jb2wgbWF5IGRl ZmluZSBuZXcgb3B0aW9uIHR5cGVzLg0KICAgICAgUmVjZWl2ZXJzIE1VU1Qgc2lsZW50bHkg aWdub3JlIGFueSBvcHRpb25zIHRoZXkgZG8gbm90IHJlY29nbml6ZQ0KICAgICAgYW5kIGNv bnRpbnVlIHByb2Nlc3NpbmcgdGhlIG1lc3NhZ2UuDQogDQo8c3BhbiBjbGFzcz0iaDMiPjxh IG5hbWU9InNlY3Rpb24tNC40Ij40LjQ8L2E+LiAgTWVzc2FnZSBPcHRpb25zPC9zcGFuPiAN CiANCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBuZXcgNkxvV1BBTi1ORCBtZXNzYWdl IG9wdGlvbnMuDQogDQo8c3BhbiBjbGFzcz0iaDQiPjxhIG5hbWU9InNlY3Rpb24tNC40LjEi PjQuNC4xPC9hPi4gIDZMb1dQQU4gQWRkcmVzcyBPcHRpb248L3NwYW4+IA0KIA0KICAgVGhl IDZMb1dQQU4gQWRkcmVzcyBPcHRpb24gKDZBTykgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGUg YWRkcmVzcw0KICAgd2hpY2ggYSBub2RlIHdhbnRzIHRvIHJlZ2lzdGVyLCBhbmQgdG8gaW5k aWNhdGUgdGhlIHN1Y2Nlc3Mgb3INCiAgIGZhaWx1cmUgb2YgdGhhdCBiaW5kaW5nIGluIGFu IE5DLiAgTXVsdGlwbGUgQWRkcmVzcyBPcHRpb25zIGNhbiBiZQ0KICAgaW5jbHVkZWQgaW4g YSBtZXNzYWdlLiAgSW4gb3JkZXIgdG8gYmUgYXMgY29tcGFjdCBhcyBwb3NzaWJsZSwgZmll bGRzDQogICBhcmUgdXNlZCB0byBpbmRpY2F0ZSB0aGUgY29tcHJlc3Npb24gb2YgdGhlIElQ djYgYWRkcmVzcy4gIFRoZSA2QU8NCiAgIGFsc28gYWxsb3dzIGZvciBkdXBsaWNhdGUgYWRk cmVzc2VzIChlLmcuIGFueWNhc3RzKSwgdGhlIHJlcXVlc3Qgb2YgYQ0KICAgZ2VuZXJhdGVk IGFkZHJlc3MgZm9yIGNsYWltIGFuZCBkZWZlbmQgdXNlLCBvciBmb3IgYW4gYWRkcmVzcyB0 byBiZQ0KICAgcmVtb3ZlZC4NCiANCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAg ICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgfCAgICAgVHlwZSAgICAgIHwgICAgTGVuZ3RoICAgICB8ICAgIFN0 YXR1cyAgICAgfCAgUyAgfCAgICBQICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8RHxBfFJ8 T3wgICAgICBSZXNlcnZlZCAgICAgICAgIHwgICAgICAgICBJUHY2IEFkZHJlc3MgICAgICAg IC4uLg0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiANCiANCiAgICAgICAgICAgICAgICAgIEZpZ3VyZSA1 OiA2TG9XUEFOIEFkZHJlc3MgT3B0aW9uIGZvcm1hdA0KIA0KICAgVHlwZTogIFRCRDMNCiAN CiAgIExlbmd0aDogIDgtYml0IHVuc2lnbmVkIGludGVnZXIuICBUaGUgbGVuZ3RoIG9mIHRo ZSBvcHRpb24gKGluY2x1ZGluZw0KICAgICAgdGhlIHR5cGUgYW5kIGxlbmd0aCBmaWVsZHMp IGluIHVuaXRzIG9mIDggb2N0ZXRzLg0KIA0KICAgU3RhdHVzOiAgOC1iaXQgdW5zaWduZWQg aW50ZWdlci4gMCBtZWFucyB1bnF1YWxpZmllZCBzdWNjZXNzLiAgQW55DQogICAgICB2YWx1 ZSBiZWxvdyAxMjggaXMgYSBwb3NpdGl2ZSBzdGF0dXMgdGhhdCBtZWFucyB0aGF0IHRoZSBi aW5kaW5nDQogICAgICBmb3IgdGhpcyBhZGRyZXNzIHdhcyBjcmVhdGVkIG9yIGlzIGJlaW5n IGNyZWF0ZWQgb3B0aW1pc3RpY2FsbHkuDQogICAgICBPbmx5IHVzZWQgaW4gYSBjb25maXJt YXRpb24uDQogDQogICBEOiAxLWJpdCBEdXBsaWNhdGUgZmxhZy4gIFdoZW4gc2V0LCBpbmRp Y2F0ZXMgdGhhdCBkdXBsaWNhdGVzIGFyZQ0KICAgICAgYWxsb3dlZCBmb3IgdGhpcyBhZGRy ZXNzICh0byBzdXBwb3J0IGFueWNhc3QpIGluIGEgcmVxdWVzdC4NCiANCiAgIEE6IDEtYml0 IEFkZHJlc3MgR2VuZXJhdGlvbiBmbGFnLiAgU2V0IHRvIGluZGljYXRlIHRoYXQgdGhlIGhv c3QgaXMNCiAgICAgIHJlcXVlc3RpbmcgYSBnZW5lcmF0ZWQgYWRkcmVzcyBmb3IgY2xhaW0g YW5kIGRlZmVuZCBhZGRyZXNzaW5nLg0KICAgICAgSW4gYSByZXF1ZXN0IHdoZW4gQSBpcyBz ZXQgdGhlIElQdjYgYWRkcmVzcyBsZW5ndGggaXMgMC4gIFNldCB0bw0KICAgICAgaW5kaWNh dGUgdGhhdCBhbiBhZGRyZXNzIGhhcyBiZWVuIGFzc2lnbmVkIGluIGEgY29uZmlybWF0aW9u LiAgUA0KICAgICAgYW5kIFMgYXJlIHNldCB0byBpbmRpY2F0ZSB0aGUgdHlwZSBvZiBhZGRy ZXNzIHJlcXVlc3RlZCBhbmQNCiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5Ij5TaGVsYnks IGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAgICAgICAg ICBbUGFnZSAxOV08L3NwYW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+PGEgbmFt ZT0icGFnZS0yMCIgaWQ9InBhZ2UtMjAiIGhyZWY9IiNwYWdlLTIwIiBjbGFzcz0iaW52aXNp YmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAg IDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTA8L3Nw YW4+IA0KIA0KIA0KICAgICAgYXNzaWduZWQgd2hlbiBBIGlzIHNldC4gIE90aGVyd2lzZSBt dXN0IGJlIDAuDQogDQogICBSOiAxLWJpdCBSZW1vdmFsIGZsYWcuICA8YSBjbGFzcz1jb21t ZW50IGhyZWY9IiMiIHRpdGxlPSJJcyB0aGlzIHJlbGV2YW50IGFueW1vcmUgbm93IHRoZSBj b25jZXB0IG9mIHdoaXRlYm9hcmRzIGhhcyBnb25lPyI+V2hlbiBzZXQsIGluZGljYXRlcyB0 aGF0IHRoaXMgcGFydGljdWxhcg0KICAgICAgYWRkcmVzcyBiaW5kaW5nIE1VU1QgYmUgcmVt b3ZlZCBmcm9tIGEgd2hpdGVib2FyZCAoaW4gYSByZXF1ZXN0KQ0KICAgICAgb3IgTVVTVCBu b3QgYmUgdXNlZCBhbnkgbG9uZ2VyIChpbiBhIGNvbmZpcm1hdGlvbik8L2E+Lg0KIA0KICAg TzogMS1iaXQgT3B0aW1pc3RpYyBmbGFnLiAgV2hlbiBzZXQsIGluZGljYXRlcyB0aGF0IHRo aXMgcGFydGljdWxhcg0KICAgICAgYWRkcmVzcyBpcyBvcHRpbWlzdGljIGFuZCBoYXMgbm90 IHlldCBiZWVuIGNoZWNrZWQgZm9yIGR1cGxpY2F0ZXMuDQogDQogICBQOiA1LWJpdCB1bnNp Z25lZCBpbnRlZ2VyLiAgSWRlbnRpZmllcyBwcmVmaXggY29tcHJlc3Npb24gb3IgdHlwZSwg aWYNCiAgICAgIGFueS4NCiANCiAgICAgIDAtMTU6ICBQcmVmaXggY29tcHJlc3NlZDsgdXBv biBkZWNvbXByZXNzaW9uLCB0aGUgcHJlZml4IGdpdmVuIGJ5DQogICAgICAgICB0aGUgY29t cHJlc3Npb24gY29udGV4dCB3aXRoIHRoZSBzYW1lIG51bWVyaWNhbCBDSUQgYXMgdGhlIFAN CiAgICAgICAgIGZpZWxkIGdpdmVuIGlzIGluc2VydGVkLg0KIA0KICAgICAgMTY6ICBQcmVm aXggaXMgY2FycmllZCBpbmxpbmUuDQogDQogICAgICAxNzogIFByZWZpeCBjb21wcmVzc2Vk OyB1cG9uIGRlY29tcHJlc3Npb24sIHRoZSBsaW5rLWxvY2FsIHByZWZpeA0KICAgICAgICAg KGZlODA6OikgaXMgaW5zZXJ0ZWQuDQogDQogICAgICAxOC0zMTogIFJlc2VydmVkLg0KIA0K ICAgUzogMy1iaXQgdW5zaWduZWQgaW50ZWdlci4gIElkZW50aWZpZXMgc3VmZml4IGNvbXBy ZXNzaW9uIG9yIHR5cGUsIGlmDQogICAgICBhbnkuDQogDQogICAgICAwOiBTdWZmaXggY2Fy cmllZCBpbmxpbmUuDQogDQogICAgICAxOiBTdWZmaXggY29tcHJlc3NlZCBhbmQgYXNzdW1l cyB0aGUgc2FtZSB2YWx1ZSBhcyB0aGUgT3duZXINCiAgICAgICAgIEludGVyZmFjZSBJZGVu dGlmaWVyIGZpZWxkIGluIHRoZSBOUi9OQyBtZXNzYWdlIGhlYWRlci4NCiANCiAgICAgIDI6 IFN1ZmZpeCBjb21wcmVzc2VkIGZvciBhbiBJSUQgZm9ybWVkIGZyb20gYW4gSUVFRSA4MDIu MTUuNCAxNi0NCiAgICAgICAgIGJpdCBzaG9ydCBhZGRyZXNzZXMuICBPbmx5IHRoZSAxNi1i aXQgc2hvcnQtYWRkcmVzcyBpcyBjYXJyaWVkDQogICAgICAgICBpbi1saW5lLiAgVGhlIElJ RCBpcyBmb3JtZWQgZnJvbSB0aGlzIGFkZHJlc3MgYXMgc3BlY2lmaWVkIGluDQogICAgICAg ICBbPGEgaHJlZj0iLi9yZmM0OTQ0IiB0aXRsZT0nIlRyYW5zbWlzc2lvbiBvZiBJUHY2IFBh Y2tldHMgb3ZlciBJRUVFIDgwMi4xNS40IE5ldHdvcmtzIic+UkZDNDk0NDwvYT5dLg0KIA0K ICAgICAgMy03OiAgUmVzZXJ2ZWQuDQogDQogICBJUHY2IEFkZHJlc3M6ICBUaGUgSVB2NiBh ZGRyZXNzIHRvIGJlIHJlZ2lzdGVyZWQgd2l0aCB0aGUgPHNwYW4gY2xhc3M9aGlsaXRlPnJv dXRlcjwvc3Bhbj4sIG9yDQogICAgICBjb25maXJtZWQgYnkgdGhlIDxzcGFuIGNsYXNzPWhp bGl0ZT5yb3V0ZXI8L3NwYW4+LiAgUGFydHMgb2YgdGhlIGFkZHJlc3MgbWF5IGJlIGVsaWRl ZCBhcyBwZXINCiAgICAgIHRoZSBQIGFuZCBTIGZpZWxkcy4NCiANCjxzcGFuIGNsYXNzPSJo NCI+PGEgbmFtZT0ic2VjdGlvbi00LjQuMiI+NC40LjI8L2E+LiAgNkxvV1BBTiBJbmZvcm1h dGlvbiBPcHRpb248L3NwYW4+IA0KIA0KICAgVGhpcyBvcHRpb24gY2FycmllcyBwcmVmaXgg aW5mb3JtYXRpb24gZm9yIExvV1BBTnMsIGFuZCBpcyBzaW1pbGFyIGluDQogICB1c2UgdG8g dGhlIFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb24gb2YgWzxhIGhyZWY9Ii4vcmZjNDg2MSIg dGl0bGU9JyJOZWlnaGJvciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiJz5S RkM0ODYxPC9hPl0uICBIb3dldmVyIHRoaXMNCiAgIG9wdGlvbiBhbGxvd3MgZm9yIHRoZSBk aXNzZW1pbmF0aW9uIG9mIG11bHRpcGxlIGNvbnRleHRzIGlkZW50aWZpZWQNCiAgIGJ5IGEg Q29udGV4dCBJZGVudGlmaWVyIChDSUQpIGZvciB1c2UgaW4gNkxvV1BBTiBhZGRyZXNzIGNv bXByZXNzaW9uLg0KIA0KIA0KIA0KPHNwYW4gY2xhc3M9ImdyZXkiPlNoZWxieSwgZXQgYWwu ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdl IDIwXTwvc3Bhbj4gDQo8L3ByZT48cHJlIGNsYXNzPSduZXdwYWdlJz48YSBuYW1lPSJwYWdl LTIxIiBpZD0icGFnZS0yMSIgaHJlZj0iI3BhZ2UtMjEiIGNsYXNzPSJpbnZpc2libGUiPiA8 L2E+IA0KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAgICAgICAgNkxvV1BB TiBOZWlnaGJvciBEaXNjb3ZlcnkgICAgICAgICAgRmVicnVhcnkgMjAxMDwvc3Bhbj4gDQog DQogDQogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwg ICAgIFR5cGUgICAgICB8ICAgICBMZW5ndGggICAgfCAgSW5mbyBMZW5ndGggIHxMfEF8Q3xW fCAgQ0lEICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAg IFZhbGlkIExpZmV0aW1lICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLg0KICAgLiAgICAgICAgICAgICAgICAgUHJlZml4IG9yIEFk ZHJlc3MgSW5mb3JtYXRpb24gICAgICAgICAgICAgICAgIC4NCiAgIC4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KIA0KICAgICAgICAgICAgICAgIEZpZ3VyZSA2OiA2TG9XUEFOIElu Zm9ybWF0aW9uIE9wdGlvbiBmb3JtYXQNCiANCiAgIFR5cGU6ICBUQkQ0DQogDQogICBMZW5n dGg6ICA4LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgVGhlIGxlbmd0aCBvZiB0aGUgb3B0aW9u IChpbmNsdWRpbmcNCiAgICAgIHRoZSB0eXBlIGFuZCBsZW5ndGggZmllbGRzKSBpbiB1bml0 cyBvZiA4IG9jdGV0cy4gIE1heSBiZSAxLCAyIG9yDQogICAgICAzIGRlcGVuZGluZyBvbiB0 aGUgbGVuZ3RoIG9mIHRoZSBJbmZvcm1hdGlvbiBmaWVsZC4NCiANCiAgIEluZm8gTGVuZ3Ro OiAgOC1iaXQgdW5zaWduZWQgaW50ZWdlci4gIFRoZSBudW1iZXIgb2YgbGVhZGluZyBiaXRz IGluDQogICAgICB0aGUgSW5mb3JtYXRpb24gZmllbGQgdGhhdCBhcmUgdmFsaWQuICBUaGUg dmFsdWUgcmFuZ2VzIGZyb20gMCB0bw0KICAgICAgMTI4LiAgVGhlIGluZm8gbGVuZ3RoIGZp ZWxkIHByb3ZpZGVzIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiBmb3Igb24tDQogICAgICBsaW5r IGRldGVybWluYXRpb24gKHdoZW4gY29tYmluZWQgd2l0aCB0aGUgTCBmbGFnIGluIHRoZSBw cmVmaXgNCiAgICAgIGluZm9ybWF0aW9uIG9wdGlvbikuICBJdCBhbHNvIGFzc2lzdHMgd2l0 aCBhZGRyZXNzDQogICAgICBhdXRvY29uZmlndXJhdGlvbiBhcyBzcGVjaWZpZWQgaW4gWzxh IGhyZWY9Ii4vcmZjNDg2MiIgdGl0bGU9JyJJUHY2IFN0YXRlbGVzcyBBZGRyZXNzIEF1dG9j b25maWd1cmF0aW9uIic+UkZDNDg2MjwvYT5dLCBmb3Igd2hpY2ggdGhlcmUgbWF5DQogICAg ICBiZSBtb3JlIHJlc3RyaWN0aW9ucyBvbiB0aGUgaW5mbyBsZW5ndGguDQogDQogICBMOiAx LWJpdCBvbi1saW5rIGZsYWcsIHNpbWlsYXIgdG8gdGhlIEwgZmxhZyBpbiBbPGEgaHJlZj0i Li9yZmM0ODYxIiB0aXRsZT0nIk5laWdoYm9yIERpc2NvdmVyeSBmb3IgSVAgdmVyc2lvbiA2 IChJUHY2KSInPlJGQzQ4NjE8L2E+XS4gIFRoaXMgZmxhZw0KICAgICAgTVVTVCBiZSB1bnNl dCBmb3IgUm91dGUgT3ZlciBMb1dQQU5zIDxhIGNsYXNzPWNvbW1lbnQgaHJlZj0iIyIgdGl0 bGU9IklzIHRoZSBjb250ZXh0IG9mIEV4dGVuZGVkIExvV1BBTnMgYW5kIFNpbXBsZSBMb1dQ QU5zIHN0aWxsIHJlbGV2YW50PyI+YW5kIEV4dGVuZGVkIExvV1BBTnMsIGFuZCBNQVkNCiAg ICAgIGJlIHNldCBmb3IgTWVzaCBVbmRlciBTaW1wbGUgTG9XUEFOczwvYT4uDQogDQogICBB OiAxLWJpdCBhdXRvbm9tb3VzIGFkZHJlc3MtY29uZmlndXJhdGlvbiBmbGFnLiAgV2hlbiBz ZXQgaW5kaWNhdGVzDQogICAgICB0aGF0IHRoaXMgcHJlZml4IGNhbiBiZSB1c2VkIGZvciBz dGF0ZWxlc3MgYWRkcmVzcyBjb25maWd1cmF0aW9uDQogICAgICBhcyBzcGVjaWZpZWQgaW4g WzxhIGhyZWY9Ii4vcmZjNDg2MSIgdGl0bGU9JyJOZWlnaGJvciBEaXNjb3ZlcnkgZm9yIElQ IHZlcnNpb24gNiAoSVB2NikiJz5SRkM0ODYxPC9hPl0uDQogDQogICBDOiAxLWJpdCBjb250 ZXh0IGZsYWcuICBUaGlzIGZsYWcgaW5kaWNhdGVzIHRoYXQgdGhpcyBpbmZvcm1hdGlvbg0K ICAgICAgb3B0aW9uIGFsc28gc2VydmVzIGFzIGEgY29udGV4dCBvbiB0aGUgTG9XUEFOLCB3 aGljaCBpcyBpZGVudGlmaWVkDQogICAgICBieSB0aGUgQ0lEIGZpZWxkLg0KIA0KICAgVjog MS1iaXQgY29udGV4dCB2YWxpZGl0eSBmbGFnLiAgVGhpcyBmbGFnIGluZGljYXRlcyBpZiB0 aGUgY29udGV4dA0KICAgICAgaXMgdmFsaWQsIGFuZCBpcyB1c2VkIG9ubHkgaW4gY29tYmlu YXRpb24gd2l0aCB0aGUgQyBmbGFnLiAgQQ0KICAgICAgY29udGV4dCB0aGF0IGlzIG5vdCB2 YWxpZCBNVVNUIG5vdCBiZSB1c2VkIGZvciBjb21wcmVzc2lvbiwgYnV0DQogICAgICBNQVkg YmUgdXNlZCBpbiBkZWNvbXByZXNzaW9uIGluIGNhc2UgYW5vdGhlciBjb21wcmVzc29yIHN0 aWxsDQogICAgICBjb25zaWRlcnMgdGhlIGNvbnRleHQgYXMgdmFsaWQuDQogDQogDQogDQog DQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5LCBldCBhbC4gICAgICAgICAgIEV4 cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMjFdPC9zcGFuPiAN CjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5hbWU9InBhZ2UtMjIiIGlkPSJwYWdl LTIyIiBocmVmPSIjcGFnZS0yMiIgY2xhc3M9ImludmlzaWJsZSI+IDwvYT4gDQo8c3BhbiBj bGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2TG9XUEFOIE5laWdoYm9yIERp c2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFuPiANCiANCiANCiAgIENJRDog IDQtYml0IENvbnRleHQgSWRlbnRpZmllciBmb3IgdGhpcyBwcmVmaXggaW5mb3JtYXRpb24u ICBDSUQgaXMNCiAgICAgIHVzZWQgYnkgY29udGV4dCBiYXNlZCBoZWFkZXIgY29tcHJlc3Np b24gc3BlY2lmaWVkIGluDQogICAgICBbPGEgaHJlZj0iI3JlZi1JLUQuaWV0Zi02bG93cGFu LWhjIiB0aXRsZT0nIkNvbXByZXNzaW9uIEZvcm1hdCBmb3IgSVB2NiBEYXRhZ3JhbXMgaW4g NkxvV1BBTiBOZXR3b3JrcyInPkktRC5pZXRmLTZsb3dwYW4taGM8L2E+XS4gIFRoZSBsaXN0 IG9mIENJRHMgZm9yIGEgTG9XUEFOIGlzDQogICAgICBjb25maWd1cmVkIG9uIEVkZ2UgUm91 dGVycywgd2hvIGRpc3RyaWJ1dGUgdGhlIHByZWZpeCBsaXN0IHRvIGFsbA0KICAgICAgbm9k ZXMgaW4gdGhlIExvV1BBTi4NCiANCiAgIFZhbGlkIExpZmV0aW1lOiAgMzItYml0IHVuc2ln bmVkIGludGVnZXIuICBUaGUgbGVuZ3RoIG9mIHRpbWUgaW4NCiAgICAgIHNlY29uZHMgKHJl bGF0aXZlIHRvIHRoZSB0aW1lIHRoZSBwYWNrZXQgaXMgc2VudCkgdGhhdCB0aGUgcHJlZml4 DQogICAgICBpcyB2YWxpZCBmb3IgdGhlIHB1cnBvc2Ugb2Ygb24tbGluayBkZXRlcm1pbmF0 aW9uLiAgQSB2YWx1ZSBvZiBhbGwNCiAgICAgIG9uZSBiaXRzICgweGZmZmZmZmZmKSByZXBy ZXNlbnRzIGluZmluaXR5Lg0KIA0KICAgSW5mb3JtYXRpb246ICBUaGUgSVB2NiBwcmVmaXgg b3IgY29udGV4dCBpbmZvcm1hdGlvbiBpbmRpY2F0ZWQuICBUaGlzDQogICAgICBtYXkgYmUg YSBwYXJ0aWFsIHByZWZpeCwgYSBwYXJ0aWFsIGNvbnRleHQgb3IgZXZlbiBhbiBlbnRpcmUg SVB2Ng0KICAgICAgYWRkcmVzcyBmb3IgdXNlIGFzIGEgY29udGV4dCBmb3IgY29tcHJlc3Np b24uDQogDQo8c3BhbiBjbGFzcz0iaDQiPjxhIG5hbWU9InNlY3Rpb24tNC40LjMiPjQuNC4z PC9hPi4gIDZMb1dQQU4gU3VtbWFyeSBPcHRpb248L3NwYW4+IA0KIA0KICAgVGhpcyBvcHRp b24gaWRlbnRpZmllcyB0aGUgc2V0IG9mIHByZWZpeCBpbmZvcm1hdGlvbiBvcHRpb25zIGJ5 IGENCiAgIHNlcXVlbmNlIG51bWJlci4gIFRoaXMgYWxsb3dzIGZvciB0aGUgZnVsbCBzZXQg b2YgcHJlZml4IGluZm9ybWF0aW9uDQogICBvcHRpb25zIHRvIGJlIHNlbnQgb25seSBwZXJp b2RpY2FsbHkgaW4gdW5zb2xpY2l0ZWQgUkFzLiAgSWYgYSBob3N0DQogICBkZXRlY3RzIGEg ZGlmZmVyZW5jZSBpbiB0aGUgc2VxdWVuY2UgbnVtYmVyIG9mIHRoaXMgb3B0aW9uLCB0aGVu IHRoZQ0KICAgcHJlZml4IGluZm9ybWF0aW9uIGhhcyBsaWtlbHkgY2hhbmdlZCwgYW5kIGlz IHRoZW4gcmVxdWVzdGVkIHdpdGggYW4NCiAgIFJTLiAgQW4gUkEgc2VudCBpbiByZXNwb25z ZSB0byBhIHVuaWNhc3QgUlMgYWx3YXlzIGluY2x1ZGVzIHRoZSBmdWxsDQogICBzZXQgb2Yg cHJlZml4IGluZm9ybWF0aW9uLg0KIA0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAg ICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogICB8ICAgICBUeXBlICAgICAgfCAgICAgTGVuZ3RoICAgIHwgICAg ICAgU2VxdWVuY2UgTnVtYmVyICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHxWfCAg ICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgfCAgICAgICAgICAgRVIgTWV0cmljICAgICAg ICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KIA0KICAgICAgICAgICAgICAgICAgICAgRmlndXJl IDc6IDZMb1dQQU4gU3VtbWFyeSBPcHRpb24NCiANCiAgIFR5cGU6ICBUQkQ1DQogDQogICBM ZW5ndGg6ICAxDQogDQogICBTZXF1ZW5jZSBOdW1iZXI6ICAxNi1iaXQgc2lnbmVkIGludGVn ZXIuICBJbmRpY2F0ZXMgdGhlIGZyZXNobmVzcyBvZg0KICAgICAgdGhlIGluZm9ybWF0aW9u IGFkdmVydGlzZWQgYnkgdGhlIFJBLg0KIA0KICAgRVIgTWV0cmljOiAgMTYtYml0IHVuc2ln bmVkIGludGVnZXIuICBUaGUgRVIgTWV0cmljIGdpdmVzIGFuDQogICAgICBpbmRpY2F0aW9u IG9mIHRoZSBjb3N0IChpbiByb3V0aW5nIG1ldHJpYyB0ZXJtcykgb2YgcmVhY2hpbmcgbm9k ZXMNCiAgICAgIG91dHNpZGUgdGhlIExvV1BBTiB2aWEgYW4gPHNwYW4gY2xhc3M9aGlsaXRl PkVkZ2UgUm91dGVyPC9zcGFuPiB0aHJvdWdoIHRoaXMgcm91dGVyLiAgVGhlIG1ldHJpYw0K ICAgICAgU0hPVUxEIGJlIGRlcml2ZWQgaW4gYSB3ZWxsLWRlZmluZWQgd2F5IGZyb20gdGhl IHJvdXRpbmcgcHJvdG9jb2wNCiAgICAgIHVzZWQgaW4gdGhlIExvV1BBTiAocG9zc2libHkg Ynkgc3RydWN0dXJpbmcgdGhlIDE2IGJpdHMgYXZhaWxhYmxlDQogICAgICBlLmcuIGludG8g YSBtYWpvciBhbmQgYSBtaW5vciBtZXRyaWMpLCBhbmQgaGFzIGEgbWlkLXJhbmdlIGRlZmF1 bHQNCiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAyMl08L3Nw YW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+PGEgbmFtZT0icGFnZS0yMyIgaWQ9 InBhZ2UtMjMiIGhyZWY9IiNwYWdlLTIzIiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxz cGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hi b3IgRGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAg ICAgdmFsdWUgb2YgMHg4MDAwLiAgRWRnZSBSb3V0ZXJzIG1vc3QgbGlrZWx5IHNldCB0aGlz IGZpZWxkIHRvIDAuICBBDQogICAgICBob3N0IFNIT1VMRCB0YWtlIHRoaXMgbWV0cmljIGlu dG8gYWNjb3VudCB3aGVuIGNob29zaW5nIGRlZmF1bHQNCiAgICAgIHJvdXRlcnMgYnkgbWFr aW5nIGEgc2NhbGFyIGNvbXBhcmlzb24sIHByZWZlcnJpbmcgcm91dGVycyB3aXRoDQogICAg ICBudW1lcmljYWxseSBsb3dlciBFUiBNZXRyaWMgdmFsdWVzLg0KIA0KICAgVjogMS1iaXQg ZmxhZy4gIEluZGljYXRlcyBpZiB0aGUgc2VxdWVuY2UgbnVtYmVyIGlzIHZhbGlkIGFuZCB0 aGUNCiAgICAgIHJvdXRlciBpcyBhZHZlcnRpc2luZyBpbmZvcm1hdGlvbiBvYnRhaW5lZCBm cm9tIGFub3RoZXIgcm91dGVyLg0KIA0KICAgUmVzZXJ2ZWQ6ICBUaGlzIGZpZWxkIGlzIHVu dXNlZC4gIEl0IE1VU1QgYmUgaW5pdGlhbGl6ZWQgdG8gemVybyBieQ0KICAgICAgdGhlIHNl bmRlciBhbmQgTVVTVCBiZSBpZ25vcmVkIGJ5IHRoZSByZWNlaXZlci4NCiANCjxzcGFuIGNs YXNzPSJoNCI+PGEgbmFtZT0ic2VjdGlvbi00LjQuNCI+NC40LjQ8L2E+LiAgT3duZXIgSW50 ZXJmYWNlIElkZW50aWZpZXIgT3B0aW9uPC9zcGFuPiANCiANCiAgIFRoaXMgb3B0aW9uIGlz IHVzZWQgdG9nZXRoZXIgd2l0aCBSb3V0ZXIgU29saWNpdGF0aW9uIG1lc3NhZ2VzIHdoZW4g YQ0KICAgbm9kZSBoYXMgb25seSBvcHRpbWlzdGljIGFkZHJlc3NlcyBiZWZvcmUgaW5pdGlh bCByZWdpc3RyYXRpb24uDQogDQogICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICB8ICAgICBUeXBlICAgICAgfCAgICAgTGVuZ3RoICAgIHwgICAg ICBUSUQgICAgICB8ICAgIFJlc2VydmVkICAgfA0KICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICBPd25lciBOb25jZSAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgKyAgICAg ICAgICAgICAgICAgIE93bmVyIEludGVyZmFjZSBJZGVudGlmaWVyICAgICAgICAgICAgICAg ICAgICsNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogDQogICAgICAgICAg ICAgICAgRmlndXJlIDg6IE93bmVyIEludGVyZmFjZSBJZGVudGlmaWVyIE9wdGlvbg0KIA0K ICAgVHlwZTogIFRCRDYNCiANCiAgIExlbmd0aDogIDINCiANCiAgIFRJRDogIDgtYml0IHVu c2lnbmVkIGludGVnZXIuICBUaGlzIGZpZWxkIGlzIHNldCB0byB0aGUgbGFzdCBUSUQNCiAg ICAgIHZhbHVlIHVzZWQgZm9yIHNlbmRpbmcgYW4gTlIgbWVzc2FnZS4NCiANCiAgIFJlc2Vy dmVkOiAgVGhpcyBmaWVsZCBpcyB1bnVzZWQuICBJdCBNVVNUIGJlIGluaXRpYWxpemVkIHRv IHplcm8gYnkNCiAgICAgIHRoZSBzZW5kZXIgYW5kIE1VU1QgYmUgaWdub3JlZCBieSB0aGUg cmVjZWl2ZXIuDQogDQogICBPd25lciBOb25jZTogIEEgMzItYml0IE93bmVyIE5vbmNlIGdl bmVyYXRlZCByYW5kb21seSBieSB0aGUgbm9kZQ0KICAgICAgdXBvbiBib290aW5nLCBhbmQg Z2VuZXJhdGVkIGFnYWluIGVhY2ggdGltZSB0aGUgbm9kZSByZS1ib290cy4NCiAgICAgIFRo aXMgT3duZXIgTm9uY2UgaXMgdXNlZCB0byBkZXRlY3QgZHVwbGljYXRlIE9JSXMuDQogDQog ICBPd25lciBJbnRlcmZhY2UgSWRlbnRpZmllcjogIEEgZ2xvYmFsbHkgdW5pcXVlIGlkZW50 aWZpZXIgZm9yIHRoZQ0KICAgICAgaG9zdCdzIGludGVyZmFjZS4gIFRoaXMgaXMgdHlwaWNh bGx5IHRoZSBFVUktNjQgZGVyaXZlZCBJSUQgb2YgdGhlDQogICAgICBpbnRlcmZhY2UuDQog DQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5LCBldCBhbC4gICAgICAgICAg IEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMjNdPC9zcGFu PiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5hbWU9InBhZ2UtMjQiIGlkPSJw YWdlLTI0IiBocmVmPSIjcGFnZS0yNCIgY2xhc3M9ImludmlzaWJsZSI+IDwvYT4gDQo8c3Bh biBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2TG9XUEFOIE5laWdoYm9y IERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFuPiANCiANCiANCjxzcGFu IGNsYXNzPSJoMiI+PGEgbmFtZT0ic2VjdGlvbi01Ij41PC9hPi4gIFByb3RvY29sIFNwZWNp ZmljYXRpb248L3NwYW4+IA0KIA0KICAgVGhpcyBzZWN0aW9uIHNwZWNpZmllcyB0aGUgZnVu Y3Rpb25zIGRlZmluZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLA0KICAgYWxvbmcgd2l0aCBw b2ludGVycyB0byBuZWVkZWQgcHJvY2VkdXJlcyBmcm9tIG90aGVyIHNwZWNpZmljYXRpb25z Lg0KICAgVGhlc2UgYmFzaWMgcHJvY2VkdXJlcyBhcmUgc3VmZmljaWVudCBhbmQgcmVxdWly ZWQgZm9yIExvV1BBTg0KICAgb3BlcmF0aW9uLg0KIA0KPHNwYW4gY2xhc3M9ImgzIj48YSBu YW1lPSJzZWN0aW9uLTUuMSI+NS4xPC9hPi4gIEludGVyZmFjZSBpbml0aWFsaXphdGlvbjwv c3Bhbj4gDQogDQogICBBIExvV1BBTiBub2RlIGZvcm1zIGEgNjQtYml0IEludGVyZmFjZSBJ ZGVudGlmaWVyIChJSUQpIGFzIHNwZWNpZmllZA0KICAgaW4gPGEgaHJlZj0iLi9yZmM0OTQ0 I3NlY3Rpb24tNiI+U2VjdGlvbiZuYnNwOzYgb2YgW1JGQzQ5NDRdPC9hPi4gIFRoaXMgbWF5 IGJlIGJhc2VkIG9uIHRoZSBFVUktNjQNCiAgIGlkZW50aWZpZXIsIGFuIGFzc2lnbmVkIDE2 LWJpdCBzaG9ydCBhZGRyZXNzLCBvciBhbnkgb3RoZXINCiAgIGFwcHJvcHJpYXRlIE1BQyBh ZGRyZXNzLiAgQWxsIG5vZGVzIE1VU1QgY29uZmlndXJlIGF0IGxlYXN0IG9uZQ0KICAgYWRk cmVzcywgYSBsaW5rLWxvY2FsIGFkZHJlc3MsIGJ5IGNvbmNhdGVuYXRpbmcgaXRzIElJRCB3 aXRoIHRoZQ0KICAgcHJlZml4IEZFODA6Oi82NCBhcyBzcGVjaWZpZWQgaW4gPGEgaHJlZj0i Li9yZmM0OTQ0I3NlY3Rpb24tNyI+U2VjdGlvbiZuYnNwOzcgb2YgW1JGQzQ5NDRdPC9hPi4g IEFzIGENCiAgIHJlc3VsdCwga25vd2xlZGdlIG9mIHRoZSBJSUQgb2YgYW5vdGhlciA8c3Bh biBjbGFzcz1oaWxpdGU+bm9kZTwvc3Bhbj4gaXMgZW5vdWdoIHRvDQogICBkZXJpdmUgaXRz IGxpbmstbG9jYWwgYWRkcmVzcyBhbmQgcmVhY2ggaXQgb24gdGhlIHNhbWUgbGluay4gIElm DQogICBkZXJpdmVkIGZyb20gYW4gRVVJLTY0IG9yIGFuIGVxdWl2YWxlbnQgdGhlIGxpbmst bG9jYWwgYWRkcmVzcyBpcw0KICAgcHJlc3VtYWJseSB1bmlxdWUgb24gdGhlIExvV1BBTiwg d2hpY2ggZW5hYmxlcyB0aGUgdXNlIG9mIE9wdGltaXN0aWMNCiAgIER1cGxpY2F0ZSBBZGRy ZXNzIERldGVjdGlvbiAob0RBRCkgWzxhIGhyZWY9Ii4vcmZjNDQyOSIgdGl0bGU9JyJPcHRp bWlzdGljIER1cGxpY2F0ZSBBZGRyZXNzIERldGVjdGlvbiAoREFEKSBmb3IgSVB2NiInPlJG QzQ0Mjk8L2E+XS4gIFRoZSBhZGRyZXNzIFNIT1VMRCBiZQ0KICAgY3JlYXRlZCBhcyBvcHRp bWlzdGljIGJlZm9yZSBpdCBoYXMgYmVlbiBjb25maXJtZWQgYnkgTm9kZQ0KICAgUmVnaXN0 cmF0aW9uIChTZWN0aW9uIDxhIGhyZWY9IiNzZWN0aW9uLTUuMiI+U2VjdGlvbiA1LjI8L2E+ KS4gIFRoaXMgZG9jdW1lbnQgYXNzdW1lcyB0aGF0DQogICBhZGRyZXNzZXMgYXJlIGZvcm1l ZCBpbiBhIHVuaWZvcm0gbWFubmVyIGluIGEgTG9XUEFOLiAgQXBwcm9wcmlhdGUNCiAgIHN0 ZXBzIFNIT1VMRCBiZSB0YWtlbiB0byBlbnN1cmUgdGhhdCBvbmx5IGNvcnJlY3RseSBjb25m aWd1cmVkDQogICBkZXZpY2VzIHBhcnRpY2lwYXRlIGluIHRoZSBMb1dQQU4sIGUuZy4gdXNp bmcgTDIgc2VjdXJpdHkgbWVjaGFuaXNtcy4NCiANCiAgIEEgbm9kZSBNVVNUIGpvaW4gdGhl IGFsbC1ub2RlcyBtdWx0aWNhc3QgYWRkcmVzcywgd2hpY2ggaXMgdXNlZCBmb3INCiAgIHJl Y2VpdmluZyBSQXMgZnJvbSByb3V0ZXJzLiAgQSByb3V0ZXIgTVVTVCBhbHNvIGpvaW4gdGhl IGFsbC1yb3V0ZXJzDQogICBtdWx0aWNhc3QgYWRkcmVzcy4gIEEgbm9kZSBNQVkgam9pbiBv dGhlciBtdWx0aWNhc3QgYWRkcmVzc2VzIHN1Y2ggYXMNCiAgIHRoZSBzb2xpY2l0ZWQtbm9k ZSBtdWx0aWNhc3QgYWRkcmVzcyBpZiBpdHMgbGluay1sYXllciBpbmNsdWRlcw0KICAgbXVs dGljYXN0IHN1cHBvcnQsIGJ1dCB0aGF0IGlzIG5vdCByZXF1aXJlZCBieSB0aGlzIHNwZWNp ZmljYXRpb24uDQogDQogICBOb2RlcyBNQVkgbGVhcm4gdGhlIGFkZHJlc3Mgb2Ygcm91dGVy cyB1c2luZyB0cmFkaXRpb25hbCBtZWFucyBzdWNoDQogICBhcyBMMiBjb25maWd1cmF0aW9u IG9yIFJvdXRlciBBZHZlcnRpc2VtZW50IG1lc3NhZ2VzIGFzIGluIFs8YSBocmVmPSIuL3Jm YzQ4NjEiIHRpdGxlPSciTmVpZ2hib3IgRGlzY292ZXJ5IGZvciBJUCB2ZXJzaW9uIDYgKElQ djYpIic+UkZDNDg2MTwvYT5dLg0KICAgV2hlbiBzZW5kaW5nIGEgUm91dGVyIFNvbGljaXRh dGlvbiBpdCBNVVNUIG5vdCBoYXZlIHRoZSBTTExBTyBPcHRpb24sDQogICBidXQgaW5zdGVh ZCBNVVNUIGluY2x1ZGUgdGhlIE9JSSBPcHRpb24uICBJZiB0aGUgc2VuZGVyIG9mIHRoZSBS UyBoYXMNCiAgIG9ubHkgb3B0aW1pc3RpYyBhZGRyZXNzZXMsIGl0IE1VU1Qgbm90IHVzZSB0 aGVtIGFzIHRoZSBJUHY2IHNvdXJjZQ0KICAgYWRkcmVzcyBmb3IgdGhlIFJTLCBidXQgaW5z dGVhZCB1c2VzIHRoZSBJUHY2IHVuc3BlY2lmaWVkIGFkZHJlc3MuDQogICBUaGlzIHByb2Nl ZHVyZSBpcyB0byBjb21wbHkgd2l0aCB0aGUgdXNlIG9mIG9wdGltaXN0aWMgYWRkcmVzc2Vz IGFzDQogICBwZXIgb0RBRCBbPGEgaHJlZj0iLi9yZmM0NDI5IiB0aXRsZT0nIk9wdGltaXN0 aWMgRHVwbGljYXRlIEFkZHJlc3MgRGV0ZWN0aW9uIChEQUQpIGZvciBJUHY2Iic+UkZDNDQy OTwvYT5dLg0KIA0KICAgVGhlIG5vZGUgU0hPVUxEIGFsc28gZm9ybSBhIGdsb2JhbCB1bmlj YXN0IGFkZHJlc3MgZm9yIHJvdXRpbmcgaW5zaWRlDQogICB0aGUgTG9XUEFOIGFuZCByZWFj aGFiaWxpdHkgZnJvbSBvdXRzaWRlIHRoZSBMb1dQQU4uICBJZiBhIHZhbGlkDQogICBwcmVm aXggaXMgYXZhaWxhYmxlIGZyb20gYW4gUkEgKCdBJyBmbGFnIGlzIHNldCksIHRoZW4gYSBn bG9iYWwNCiAgIHVuaWNhc3QgYWRkcmVzcyBNQVkgYmUgZGVyaXZlZCBmb2xsb3dpbmcgdGhl IGdlbmVyYWwgZGVzY3JpcHRpb24gaW4NCiAgIDxhIGhyZWY9Ii4vcmZjNDg2MiNzZWN0aW9u LTUuNSI+U2VjdGlvbiZuYnNwOzUuNSBvZiBbUkZDNDg2Ml08L2E+LiAgVGhpcyBhZGRyZXNz IGlzIG1hcmtlZCBvcHRpbWlzdGljIHVudGlsDQogICBjb25maXJtZWQgYnkgdGhlIE5vZGUg UmVnaXN0cmF0aW9uIHByb2Nlc3MuICBJZiB0aGUgTG9XUEFOIGlzDQogICBvcGVyYXRpbmcg aW4gYWQtaG9jIG1vZGUsIHRoZW4gdGhlIHByZWZpeCBpcyBhIFVuaXF1ZSBvbi1saW5rIElQ djYNCiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAyNF08L3Nw YW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+PGEgbmFtZT0icGFnZS0yNSIgaWQ9 InBhZ2UtMjUiIGhyZWY9IiNwYWdlLTI1IiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxz cGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hi b3IgRGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAg QWRkcmVzcyAoVUxBKSBwcmVmaXggWzxhIGhyZWY9Ii4vcmZjNDE5MyIgdGl0bGU9JyJVbmlx dWUgTG9jYWwgSVB2NiBVbmljYXN0IEFkZHJlc3NlcyInPlJGQzQxOTM8L2E+XSBhcyBzcGVj aWZpZWQgaW4gPGEgaHJlZj0iI3NlY3Rpb24tOCI+U2VjdGlvbiA4PC9hPiAodXNlIG9mIGEN CiAgIFVMQSBwcmVmaXggcmVxdWlyZXMgbm8gY2hhbmdlcyB0byBub2RlIG9wZXJhdGlvbiku ICBBIG5vZGUgTUFZDQogICBhbHRlcm5hdGl2ZWx5IGFjcXVpcmUgYSBnbG9iYWwgdW5pY2Fz dCBhZGRyZXNzIHVzaW5nIG90aGVyIHN1aXRhYmxlDQogICBtZWFucywgZS5nLiAgREhDUHY2 LCBMMiBhc3NpZ25tZW50IG9yIG1hbnVhbCBjb25maWd1cmF0aW9uLg0KIA0KPHNwYW4gY2xh c3M9ImgzIj48YSBuYW1lPSJzZWN0aW9uLTUuMiI+NS4yPC9hPi4gIE5vZGUgUmVnaXN0cmF0 aW9uPC9zcGFuPiANCiANCiAgIFRoZSBub2RlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGlzIHZl cnkgc2ltaWxhciB0byB0aGF0IG9mIGEgTUlQdjYNCiAgIG1vYmlsZSBub2RlLCB0aG91Z2gg dGhlIG1lc3NhZ2VzIHVzZWQgYXJlIG5ldyA8c3BhbiBjbGFzcz1oaWxpdGU+Tm9kZSBSZWdp c3RyYXRpb24vQ29uZmlybWF0aW9uPC9zcGFuPiBJQ01QDQogICBtZXNzYWdlcy4gIEEgPHNw YW4gY2xhc3M9aGlsaXRlPm5vZGU8L3NwYW4+IGFkZHJlc3MgPHNwYW4gY2xhc3M9aGlsaXRl PmlzPC9zcGFuPiBvcHRpbWlzdGljIGFzIGxvbmcgYXMgdGhlIGJpbmRpbmcgaXMNCiAgIG5v dCBjb25maXJtZWQgPHNwYW4gY2xhc3M9aGlsaXRlPmJ5PC9zcGFuPiBhIHJvdXRlci4gIFRo ZSA8c3BhbiBjbGFzcz1oaWxpdGU+bm9kZTwvc3Bhbj4gc2VuZHMgYSB1bmljYXN0IE5vZGUN CiAgIFJlZ2lzdHJhdGlvbiB0byBhbiBvbi1saW5rIDxzcGFuIGNsYXNzPWhpbGl0ZT5yPC9z cGFuPm91dGVyIHRvIHBlcmZvcm0gdGhlIGJpbmRpbmcuICBXaGlsZSBhDQogICA8c3BhbiBj bGFzcz1oaWxpdGU+bm9kZSdzPC9zcGFuPiBhZGRyZXNzZXMgYXJlIHN0aWxsIG9wdGltaXN0 aWMgKGZpcnN0IHJlZ2lzdHJhdGlvbiBpbiBhDQogICBMb1dQQU4pLCB0aGUgSVB2NiB1bnNw ZWNpZmllZCBhZGRyZXNzIG11c3QgYmUgdXNlZCBhcyB0aGUgc291cmNlLg0KICAgUmVnaXN0 cmF0aW9uIFNIT1VMRCBiZSBwcmVmZXJyZWQgd2l0aCBvbi1saW5rIEVkZ2UgUm91dGVycyBy YXRoZXINCiAgIHRoYW4gPHNwYW4gY2xhc3M9aGlsaXRlPnJvdXRlcjwvc3Bhbj5zIGlmIGF2 YWlsYWJsZS4gIFRoZSBQcmVmZXJlbmNlIEZsYWcgb2YgdGhlIFJBIGlzDQogICB1c2VkIHRv IGRpZmZlcmVudGlhdGUgYmV0d2VlbiA8c3BhbiBjbGFzcz1oaWxpdGU+RWRnZSBSb3V0ZXI8 L3NwYW4+cyAoUHJmPTAxKSBhbmQgPHNwYW4gY2xhc3M9aGlsaXRlPnJvdXRlcjwvc3Bhbj5z DQogICAoUHJmPTAwKS4gIDxzcGFuIGNsYXNzPWhpbGl0ZT5Sb3V0ZXI8L3NwYW4+cyB3aXRo IFByZj0xMSBTSE9VTEQgTk9UIGJlIHVzZWQgZm9yDQogICByZWdpc3RyYXRpb24uICBGdXJ0 aGVybW9yZSB0aGUgRVIgTWV0cmljIGluIHRoZSA2TG9XUEFOIFN1bW1hcnkNCiAgIE9wdGlv biBTSE9VTEQgYmUgdXNlZCB0byByYW5rIHJvdXRlcnMuDQogDQogICBBIHVuaXF1ZSBPd25l ciBJbnRlcmZhY2UgSWRlbnRpZmllciAoT0lJKSBpcyBpbmNsdWRlZCBpbiB0aGUgTm9kZQ0K ICAgUmVnaXN0cmF0aW9uIHNvIHRoZSBiaW5kaW5nIGNhbiBiZSBpZGVudGlmaWVkIHRocm91 Z2hvdXQgdGhlIExvV1BBTi4NCiAgIDxhIGNsYXNzPWNvbW1lbnQgaHJlZj0iIyIgdGl0bGU9 IkNhbiBpdCBiZSBmb3JtZWQgZnJvbSB0aGUgMTYtYml0IHNob3J0IGFkZHJlc3M/IFRoaXMg aXMgaW1wbGllZCBlbHNld2hlcmUgYW5kIGluIFJGQzQ5NDQiPlRoZSBPSUkgU0hPVUxEIGJl IGZvcm1lZCBmcm9tIHRoZSBFVUktNjQgb2YgdGhlIGludGVyZmFjZTwvYT4gaW4gdGhlIHNh bWUNCiAgIHdheSBhcyB0aGUgbm9kZSdzIGxpbmstbG9jYWwgYWRkcmVzcyBJSUQgYXMgZGVm aW5lZCBpbiBbPGEgaHJlZj0iLi9yZmM0OTQ0IiB0aXRsZT0nIlRyYW5zbWlzc2lvbiBvZiBJ UHY2IFBhY2tldHMgb3ZlciBJRUVFIDgwMi4xNS40IE5ldHdvcmtzIic+UkZDNDk0NDwvYT5d LiAgQQ0KICAgcmFuZG9tbHkgZ2VuZXJhdGVkIDMyLWJpdCBPd25lciBOb25jZSBpcyBmb3Jt ZWQgZWFjaCB0aW1lIGEgbm9kZQ0KICAgYm9vdHMgb3IgcmVib290cy4gIFRoaXMgaXMgaW5j bHVkZWQgaW4gdGhlIE5SIGFuZCBtYXkgYmUgdXNlZCB0bw0KICAgZGV0ZWN0IGR1cGxpY2F0 ZSBPSUlzLiAgV2hpbGUgY3J5cHRvZ3JhcGhpYyByYW5kb21uZXNzIFs8YSBocmVmPSIuL3Jm YzQwODYiIHRpdGxlPSciUmFuZG9tbmVzcyBSZXF1aXJlbWVudHMgZm9yIFNlY3VyaXR5Iic+ UkZDNDA4NjwvYT5dIGlzDQogICBub3Qgc3RyaWN0bHkgcmVxdWlyZWQsIHRoZSByYW5kb21u ZXNzIFNIT1VMRCBiZSBkZXJpdmVkIHVzaW5nIGENCiAgIG1lY2hhbmlzbSBvZiBzaW1pbGFy IHF1YWxpdHkuDQogDQogICBUaGUgTlIgbWVzc2FnZSBpbmNsdWRlcyBhbiBBZGRyZXNzIE9w dGlvbiBmb3IgZWFjaCBhZGRyZXNzIHRvIGJlDQogICByZWdpc3RlcmVkLiAgVGh1cyB0aGUg bWVzc2FnZSBpcyBzdHJ1Y3R1cmVkIGFzIGZvbGxvd3M6DQogDQogICBJQ01QdjYgKE5vZGUg UmVnaXN0cmF0aW9uIChBZGRyZXNzIE9wdGlvblswXSwgQWRkcmVzcyBPcHRpb25bMV0sDQog ICBBZGRyZXNzIE9wdGlvbltuXSkpDQogDQogICBUaGlzIHJlZ2lzdHJhdGlvbiBtZXRob2Qg aW5jbHVkZXMgYSB3YXkgb2YgcmVxdWVzdGluZyBhIHVuaXF1ZQ0KICAgYWRkcmVzcyBieSBz ZXR0aW5nIHRoZSAnQScgZmxhZyBpbiBhbiBBZGRyZXNzIE9wdGlvbiBkdXJpbmcNCiAgIHJl Z2lzdHJhdGlvbi4gIFRoaXMgaXMgdXNlZnVsIGZvciByZWNlaXZpbmcgYSB1bmlxdWUgc2hv cnQgbGluay1sYXllcg0KICAgYWRkcmVzcy4gIEhvdyBhIHJvdXRlciBhc3NpZ25zIHN1Y2gg YW4gYWRkcmVzcyBpcyBvdXQgb2Ygc2NvcGUgZm9yDQogICB0aGlzIGRvY3VtZW50Lg0KIA0K ICAgQSB1bmlxdWUgVHJhbnNhY3Rpb24gSUQgKFRJRCkgaXMgaW5jbHVkZWQgYnkgdGhlIGhv c3QgaW4gdGhlIE5SDQogICBtZXNzYWdlIGFuZCB1c2VkIHRvIG1hdGNoIHJlcGxpZXMuICBB IGxvbGxpcG9wIG1lY2hhbmlzbSBpcyB1c2VkLg0KICAgVElEIGlzIHNldCB0byAwIHVwb24g Ym9vdGluZywgYW5kIGlzIGluY3JlbWVudGVkIHdpdGggZWFjaCBSZXF1ZXN0IE5SDQogICBt ZXNzYWdlLiAgVGhlIFRJRCBNVVNUIE5PVCBiZSBpbmNyZW1lbnRlZCB3aGVuIHNlbmRpbmcg YSBSZWZyZXNoIE5SDQogICBtZXNzYWdlLiAgQWZ0ZXIgcmVhY2hpbmcgMHhGRiwgdGhlIHZh bHVlIGxvb3BzIHRvIDE2ICgweDEwKSBhbmQgaXMNCiANCiANCiANCjxzcGFuIGNsYXNzPSJn cmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAg ICAgICAgICAgICAgICBbUGFnZSAyNV08L3NwYW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3 cGFnZSc+PGEgbmFtZT0icGFnZS0yNiIgaWQ9InBhZ2UtMjYiIGhyZWY9IiNwYWdlLTI2IiBj bGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1E cmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1 YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAgaW5jcmVtZW50ZWQgZnJvbSB0aGVyZS4gIFRo dXMgdGhlIHZhbHVlcyBiZXR3ZWVuIDAtMTUgTVVTVCBvbmx5IHVzZWQNCiAgIGFmdGVyIGEg Ym9vdCBvciByZWJvb3Qgd2hpbGUgbm90IHlldCByZWdpc3RlcmVkLiAgQSBub2RlIHRoYXQg aGFzIG5vdA0KICAgaGVhcmQgYSB2YWxpZCBOb2RlIENvbmZpcm1hdGlvbiBmb3IgMTYgTm9k ZSBSZWdpc3RyYXRpb24gbWVzc2FnZXMgaW4NCiAgIGEgcm93IHJlc3RhcnRzIHdpdGggYSBv bi1saW5rIG5leHQgVElEIG9mIHplcm8gKHRoZSBub2RlIE1BWSwgYnV0DQogICBuZWVkIG5v dCwgZ2VuZXJhdGUgYSBuZXcgT3duZXIgTm9uY2UpLg0KIA0KICAgVGhlIGFja25vd2xlZGdt ZW50IHRvIGEgTm9kZSBSZWdpc3RyYXRpb24gaXMgYSB1bmljYXN0IE5vZGUNCiAgIENvbmZp cm1hdGlvbiBtZXNzYWdlIHRoYXQgY29udGFpbnMgdGhlIHN0YXR1cyBvZiB0aGUgYmluZGlu Z3MuICBUaGUNCiAgIHNvdXJjZSBvZiB0aGUgcGFja2V0IGlzIHRoZSBsaW5rLWxvY2FsIGFk ZHJlc3Mgb2YgdGhlIG9uLWxpbmsgcm91dGVyLg0KICAgVGhlIGRlc3RpbmF0aW9uIGFkZHJl c3MgaXMgdGhlIGxpbmstbG9jYWwgYWRkcmVzcyBvZiB0aGUgbm9kZS4gIEFuDQogICBBZGRy ZXNzIE9wdGlvbiBmb3IgZWFjaCBjb25maXJtZWQgb3IgYXNzaWduZWQgYWRkcmVzcyBpcyBp bmNsdWRlZC4NCiAgIFVwb24gc3VjY2Vzc2Z1bCBjb21wbGV0aW9uIGluIHRoZSBOb2RlIENv bmZpcm1hdGlvbiBtZXNzYWdlLCB0aGUNCiAgIDxzcGFuIGNsYXNzPWhpbGl0ZT5ub2RlPC9z cGFuPiBzZXRzIHRoZSBhZGRyZXNzIGZyb20gb3B0aW1pc3RpYyB0byBwcmVmZXJyZWQuICBT ZWUNCiAgIDxhIGhyZWY9IiNzZWN0aW9uLTExIj5TZWN0aW9uIDExPC9hPiBmb3IgbWVzc2Fn ZSBleGFtcGxlcy4NCiANCiAgIE5vZGUgYmluZGluZ3MgaGF2ZSB0aW1lb3V0cyBhc3NvY2lh dGVkIHdpdGggdGhlbSwgdGhlcmVmb3JlIG5vZGVzDQogICBtdXN0IHBlcmlvZGljYWxseSBz ZW5kIGEgbmV3IE5vZGUgUmVnaXN0cmF0aW9uIG1lc3NhZ2UgdG8gcmVuZXcgdGhlDQogICBi aW5kaW5nLiAgVGhlIHBlcmlvZCBiZXR3ZWVuIFJlcXVlc3QgTlIgbWVzc2FnZXMgU0hPVUxE IGJlIGxlc3MgdGhhbg0KICAgQmluZGluZ0xpZmV0aW1lLiAgSWYgYSBub2RlIG5vIGxvbmdl ciByZWNlaXZlcyBOb2RlIENvbmZpcm1hdGlvbg0KICAgbWVzc2FnZXMgZnJvbSBhbnkgcm91 dGVyIGluIHRoZSBjdXJyZW50IHN1Ym5ldCwgdGhlIHJlZ2lzdHJhdGlvbg0KICAgcHJvY2Vz cyBzdGFydHMgb3Zlci4NCiANCjxzcGFuIGNsYXNzPSJoNCI+PGEgbmFtZT0ic2VjdGlvbi01 LjIuMSI+NS4yLjE8L2E+LiAgUHJvY2Vzc2luZyBhIE5vZGUgUmVnaXN0cmF0aW9uIE1lc3Nh Z2U8L3NwYW4+IA0KIA0KICAgV2hlbiBhIHJvdXRlciByZWNlaXZlcyBhIE5vZGUgUmVnaXN0 cmF0aW9uIG1lc3NhZ2UgZnJvbSBhIG5vZGUsIGl0DQogICBmaXJzdCBjaGVja3MgZm9yIGNv cnJlY3RuZXNzIG9mIHRoZSBtZXNzYWdlIGZpZWxkcyBhbmQgb3B0aW9ucy4gIEluDQogICB0 aGUgY2FzZSBvZiBhbiBleGlzdGluZyBub2RlLCB0aGUgbWVzc2FnZSBpcyB1c2VkIHRvIHJl ZnJlc2ggdGhlDQogICBjb3JyZXNwb25kaW5nIGVudHJpZXMgaW4gdGhlIHJvdXRlcidzIGJp bmRpbmcgdGFibGUuDQogDQogICBJbiB0aGUgY2FzZSBvZiBhIG5ldyBub2RlLCB0aGVuIGEg YmluZGluZyB0YWJsZSBlbnRyeSBpcyBtYWRlIGZvcg0KICAgZWFjaCA2QU8gaW4gdGhlIG1l c3NhZ2UuICBUaGUgcm91dGVyIFNIT1VMRCBwZXJmb3JtIER1cGxpY2F0ZSBBZGRyZXNzDQog ICBEZXRlY3Rpb24gb24gZWFjaCBvcHRpbWlzdGljIGFkZHJlc3MgKE8gZmxhZyBzZXQpLCBz ZWUgPGEgaHJlZj0iI3NlY3Rpb24tNS4zIj5TZWN0aW9uIDUuMzwvYT4gDQogICBmb3IgZnVy dGhlciBpbmZvcm1hdGlvbiBvbiB0aGUgREFEIHByb2NlZHVyZS4gIElmIGEgNkFPIG9wdGlv biB3aXRoDQogICBhbiBBIGZsYWcgaXMgcmVjZWl2ZWQsIHRoZW4gdGhlIHJvdXRlciBzaG91 bGQgPHNwYW4gY2xhc3M9aGlsaXRlPmFjcXVpcmU8L3NwYW4+IGEgc3VpdGFibGUNCiAgIGFk ZHJlc3MgZm9yIHRoZSBub2RlLiAgSG93IHRoaXMgaXMgZG9uZSBpcyBvdXQgb2Ygc2NvcGUu ICBEZXBlbmRpbmcNCiAgIG9uIHRoZSBsaW5rLWxheWVyIGFuZCBuZXR3b3JrIGl0IG1heSBi ZSBwb3NzaWJsZSB0byBnZW5lcmF0ZSBhIHJhbmRvbQ0KICAgYWRkcmVzcyAoREFEIE1VU1Qg YmUgcGVyZm9ybWVkIGluIHRoaXMgY2FzZSksIDxzcGFuIGNsYXNzPWhpbGl0ZT5hY3F1aXJl PC9zcGFuPiBhbiBhZGRyZXNzIGZyb20NCiAgIGEgbGluay1sYXllciBjb29yZGluYXRvciwg b3IgcGVyZm9ybSBESENQdjYgaW4gYSBtYW5hZ2VkIG5ldHdvcmsgdG8NCiAgIG5hbWUgYSBm ZXcuDQogDQogICBBZnRlciBwcm9jZXNzaW5nIGFsbCA2QU8gb3B0aW9ucywgYSB1bmljYXN0 IE5vZGUgQ29uZmlybWF0aW9uIG1lc3NhZ2UNCiAgIGlzIHNlbnQgYmFjayB0byB0aGUgbm9k ZSB3aXRoIGFuIGFwcHJvcHJpYXRlIE5DIFN0YXR1cyBjb2RlIGFuZA0KICAgc3VjY2VzcyBj b2RlcyBmb3IgZWFjaCA2QU8gb3B0aW9uIGluIHRoZSBzYW1lIG9yZGVyIGFzIHJlY2VpdmVk Lg0KIA0KPHNwYW4gY2xhc3M9Img0Ij48YSBuYW1lPSJzZWN0aW9uLTUuMi4yIj41LjIuMjwv YT4uICBQcm9jZXNzaW5nIGEgTm9kZSBDb25maXJtYXRpb24gTWVzc2FnZTwvc3Bhbj4gDQog DQogICA8c3BhbiBjbGFzcz1oaWxpdGU+V2hlbiBhIG5vZGUgcmVjZWl2ZXMgYSBOb2RlIENv bmZpcm1hdGlvbiBtZXNzYWdlIGZyb20gYSByb3V0ZXI8L3NwYW4+LCBpdA0KICAgZmlyc3Qg Y2hlY2tzIGZvciBjb3JyZWN0bmVzcyBvZiB0aGUgbWVzc2FnZSBmaWVsZHMgYW5kIG9wdGlv bnMuDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5LCBldCBhbC4gICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMjZdPC9z cGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5hbWU9InBhZ2UtMjciIGlk PSJwYWdlLTI3IiBocmVmPSIjcGFnZS0yNyIgY2xhc3M9ImludmlzaWJsZSI+IDwvYT4gDQo8 c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2TG9XUEFOIE5laWdo Ym9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFuPiANCiANCiANCiAg IElmIGEgTkMgaXMgPHNwYW4gY2xhc3M9aGlsaXRlPnJlY2VpdmVkPC9zcGFuPiB3aXRoIGEg c3VjY2VzcyBzdGF0dXMgKDAtNyksIHRoZW4gdGhlIG5vZGUgZ29lcw0KICAgb24gdG8gcHJv Y2VzcyA2TG9XUEFOIEFkZHJlc3MgT3B0aW9ucy4gIElmIGEgc3VjY2Vzc2Z1bCBOQyBpcw0K ICAgcmVjZWl2ZWQgd2l0aCBhIGNvZGUgb2YgMiwgdGhpcyBpbmRpY2F0ZXMgdGhhdCB0aGUg bm9kZSBzaG91bGQgcmUtDQogICByZWdpc3RlciB3aXRoIHRoYXQgcm91dGVyLg0KIA0KICAg NkxvV1BBTiBBZGRyZXNzIE9wdGlvbnMgYXJlIHByb2Nlc3NlZCBvbmUgYXQgYSB0aW1lLiAg QSBzdWNjZXNzDQogICBzdGF0dXMgKDAtMTI3KSBpbmRpY2F0ZXMgdGhhdCB0aGUgYWRkcmVz cyB3YXMgc3VjY2Vzc2Z1bGx5IGJvdW5kIHdpdGgNCiAgIHRoZSByb3V0ZXIuICBJZiB0aGUg YWRkcmVzcyBpcyBtYXJrZWQgb3B0aW1pc3RpYywgaXQgaXMgbm93IHVwZGF0ZWQNCiAgIHRv IHByZWZlcnJlZC4gIEEgZmFpbHVyZSBjb2RlICgxMjgtKSBpbmRpY2F0ZXMgdGhhdCB0aGUg YmluZGluZw0KICAgZmFpbGVkLiAgU2VlIDxhIGhyZWY9IiNzZWN0aW9uLTQuNC4xIj5TZWN0 aW9uIDQuNC4xPC9hPiBmb3IgYW4gZXhwbGFuYXRpb24gb2YgNkFPIGNvZGVzLiAgQQ0KICAg YmluZGluZyBmYWlsdXJlIG1heSBpbmRpY2F0ZSB0aGF0IGEgZHVwbGljYXRlIGFkZHJlc3Mg KGFuZCB0aHVzIGENCiAgIGR1cGxpY2F0ZSBJSUQpIGFscmVhZHkgZXhpc3RzLiAgSW4gdGhp cyBjYXNlIHRoZSBub2RlIFNIT1VMRCBhdHRlbXB0DQogICB0byBmb3JtIGEgbmV3IElJRCBh bmQgcmVzdGFydCB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MuICBJZiB0aGlzIGlzDQogICBu b3QgcG9zc2libGUsIHRoZSBub2RlIE1VU1Qgbm90IHBhcnRpY2lwYXRlIGluIHRoZSBMb1dQ QU4uDQogDQogICBJZiBhIE5DIGlzIHJlY2VpdmVkIHdpdGggYW4gZXJyb3Igc3RhdHVzICg4 IG9yIGdyZWF0ZXIpLCB0aGVuIHRoZQ0KICAgcmVnaXN0cmF0aW9uIGhhcyBmYWlsZWQuICBT ZWUgPGEgaHJlZj0iI3NlY3Rpb24tNC4xIj5TZWN0aW9uIDQuMTwvYT4gZm9yIGFuIGV4cGxh bmF0aW9uIG9mIE5SL05DDQogICBjb2Rlcy4gIElmIG5vIHN1Y2Nlc3NmdWwgTm9kZSBDb25m aXJtYXRpb24gaXMgcmVjZWl2ZWQgd2l0aGluIHRoZQ0KICAgdGltZW91dCAoUmVnaXN0cmF0 aW9uVGltZW91dCkgYW5kIG51bWJlciBvZiByZXRyaWVzDQogICAoUmVnaXN0cmF0aW9uUmV0 cmllcyksIHRoZW4gcmVnaXN0cmF0aW9uIHNob3VsZCBiZSBwZXJmb3JtZWQgd2l0aA0KICAg YW5vdGhlciByb3V0ZXIgaW4gdGhlIGRlZmF1bHQgcm91dGVyIGxpc3QuDQogDQo8c3BhbiBj bGFzcz0iaDMiPjxhIG5hbWU9InNlY3Rpb24tNS4zIj41LjM8L2E+LiAgPGEgY2xhc3M9Y29t bWVudCBocmVmPSIjIiB0aXRsZT0iVGhpcyBzZWN0aW9uIGlzIHdvcmsgaW4gcHJvZ3Jlc3Mu Li4iPkR1cGxpY2F0ZSBBZGRyZXNzIERldGVjdGlvbjwvYT48L3NwYW4+IA0KIA0KICAgSXQg aXMgaW1wb3J0YW50IGZvciBwcm9wZXIgbmV0d29yayBvcGVyYXRpb24gdGhhdCBkdXBsaWNh dGUgYWRkcmVzc2VzDQogICBhcmUgbm90IHVzZWQgaW4gYSBMb1dQQU4gYXMgZGVzY3JpYmVk IGluICJJUHY2IFN0YXRlbGVzcyBBZGRyZXNzDQogICBBdXRvY29uZmlndXJhdGlvbiIgWzxh IGhyZWY9Ii4vcmZjNDg2MiIgdGl0bGU9JyJJUHY2IFN0YXRlbGVzcyBBZGRyZXNzIEF1dG9j b25maWd1cmF0aW9uIic+UkZDNDg2MjwvYT5dLiAgRnVydGhlcm1vcmUsIGFzIExvV1BBTnMg YXJlIG1hZGUgdXAgb2YNCiAgIGxpbmtzIHdpdGggdW5kZXRlcm1pbmVkIGNvbm5lY3Rpdml0 eSwgaXQgaXMgaW1wb3J0YW50IHRoYXQgYWRkcmVzcw0KICAgdW5pcXVlbmVzcyBpcyBlbnN1 cmVkIHRob3VnaG91dCB0aGUgcm91dGluZyBkb21haW4gYXMgZGlzY3Vzc2VkIGluDQogICBb PGEgaHJlZj0iI3JlZi1JLUQuaWV0Zi1hdXRvY29uZi1hZGhvYy1hZGRyLW1vZGVsIiB0aXRs ZT0nIklQIEFkZHJlc3NpbmcgTW9kZWwgaW4gQWQgSG9jIE5ldHdvcmtzIic+SS1ELmlldGYt YXV0b2NvbmYtYWRob2MtYWRkci1tb2RlbDwvYT5dLiAgPHNwYW4gY2xhc3M9aGlsaXRlPkhv c3Q8L3NwYW4+cyBtYXkgYmUgdmVyeQ0KICAgc2ltcGxlLCBhbmQgdGh1cyBhcmUgbm90IGV4 cGVjdGVkIHRvIGhhdmUgdGhlIGNhcGFiaWxpdHkgb2YNCiAgIHBlcmZvcm1pbmcgYSBkdXBs aWNhdGUgYWRkcmVzcyBkZXRlY3Rpb24gKERBRCkgYWxnb3JpdGhtIHRoZW1zZWx2ZXMuDQog ICBUaGVyZWZvcmUgdGhlIGhhbmRsaW5nIG9mIERBRCBpcyBjb25zaWRlcmVkIGEgZnVuY3Rp b24gb2YgPHNwYW4gY2xhc3M9aGlsaXRlPnJvdXRlcjwvc3Bhbj5zLg0KICAgVGhpcyBkb2N1 bWVudCBkb2VzIG5vdCBwZXJmb3JtIERBRCBhcyBkZWZpbmVkIGluIFs8YSBocmVmPSIuL3Jm YzQ4NjIiIHRpdGxlPSciSVB2NiBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlv biInPlJGQzQ4NjI8L2E+XSwNCiAgIGJ1dCBpbnN0ZWFkIG1ha2VzIHVzZSBvZiBhbHRlcm5h dGl2ZSB0ZWNobmlxdWVzIGFwcHJvcHJpYXRlIGZvcg0KICAgTG9XUEFOcy4gIEl0IGlzIGFz c3VtZWQgdGhhdCBhbGwgcm91dGVycyBpbiBhIExvV1BBTiBhcmUgY29uZmlndXJlZA0KICAg dG8gcGVyZm9ybSBEQUQgaW4gYSB1bmlmb3JtIHdheS4gIElmIHRoZXJlIGlzIG9ubHkgYSBz aW5nbGUgcm91dGVyIGluDQogICB0aGUgTG9XUEFOLCBhcyBvY2N1cnMgaW4gbWVzaC11bmRl ciBvciBzdGFyIHRvcG9sb2dpZXMsIHRoZW4gYSByb3V0ZXINCiAgIGF1dG9tYXRpY2FsbHkg ZGV0ZWN0cyBkdXBsaWNhdGVzIGJ5IGNoZWNraW5nIGl0cyBvd24gYmluZGluZyB0YWJsZQ0K ICAgZHVyaW5nIHJlZ2lzdHJhdGlvbiwgdGh1cyBubyBhZGRpdGlvbmFsIG1lY2hhbmlzbSBp cyBuZWVkZWQuDQogDQogICBJZiBhIHJvdXRlciByZWNlaXZlcyBhIE5vZGUgUmVnaXN0cmF0 aW9uIDZBTyB3aXRoIHRoZSBPcHRpbWlzdGljIEZsYWcNCiAgIChPKSBzZXQsIGl0IFNIT1VM RCBwZXJmb3JtIERBRCBvbiB0aGlzIGFkZHJlc3MuICBJZiB0aGUgcm91dGVyDQogICBnZW5l cmF0ZXMgb3IgYXNzaWducyBhbiBhZGRyZXNzIGZvciBhIG5vZGUgaW4gcmVzcG9uc2UgdG8g YSA2QU8gd2l0aA0KICAgdGhlIEEgZmxhZyBzZXQsIGl0IFNIT1VMRCBwZXJmb3JtIERBRCBv biB0aGF0IGFkZHJlc3MuICBEQUQgTUFZIGJlDQogICBkaXNhYmxlZCBpZiB0aGUgYWRkcmVz cyBoYXMgYmVlbiBnZW5lcmF0ZWQgb3IgYXNzaWduZWQgaW4gc3VjaCBhIHdheQ0KICAgdGhh dCB0aGVyZSBpcyBoaWdoIGNvbmZpZGVuY2Ugb2Ygbm8gZHVwbGljYXRlcyAoV0FSTklORyBJ TiBMQVJHRQ0KICAgUFJJTlQpLiAgRXhhbXBsZXMgaW5jbHVkZSB0aGUgdXNlIG9mIGFuIEVV SS02NCB0byBmb3JtIGFuIElJRCBvcg0KIA0KIA0KIA0KPHNwYW4gY2xhc3M9ImdyZXkiPlNo ZWxieSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA1LCAyMDEwICAgICAgICAg ICAgICAgIFtQYWdlIDI3XTwvc3Bhbj4gDQo8L3ByZT48cHJlIGNsYXNzPSduZXdwYWdlJz48 YSBuYW1lPSJwYWdlLTI4IiBpZD0icGFnZS0yOCIgaHJlZj0iI3BhZ2UtMjgiIGNsYXNzPSJp bnZpc2libGUiPiA8L2E+IA0KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAg ICAgICAgNkxvV1BBTiBOZWlnaGJvciBEaXNjb3ZlcnkgICAgICAgICAgRmVicnVhcnkgMjAx MDwvc3Bhbj4gDQogDQogDQogICBESENQdjYgcGVyZm9ybWVkIHRocm91Z2ggYSBzaW5nbGUg c2VydmVyIHVuaWZvcm1seSBieSBhbGwgbm9kZXMgaW4NCiAgIHRoZSBMb1dQQU4gKGFzIHBl ciB0aGUgaG9tb2dlbmVvdXMgTG9XUEFOIGFzc3VtcHRpb24pLg0KIA0KICAgQSByb3V0ZXIg Y2FuIGJlIGNvbmZpZ3VyZWQgdG8gcGVyZm9ybSBEQUQgdXNpbmcgb25lIG9mIHRoZSBmb2xs b3dpbmcNCiAgIHRlY2huaXF1ZXMsIHRoZSBkZXRhaWxzIG9mIHdoaWNoIGFyZSBvdXQgb2Yg dGhlIHNjb3BlIG9mIHRoaXMNCiAgIGRvY3VtZW50Og0KIA0KICAgPGEgY2xhc3M9Y29tbWVu dCBocmVmPSIjIiB0aXRsZT0iTWF5YmUgdGhlIHRlcm0gbmVlZHMgdG8gYmUgaW5jbHVkZWQg aW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gaW4gdGhpcyBkb2N1bWVudCBhbmQgdGhlbiBy ZWZlcmVuY2VkIG91dC4gQXQgdGhlIG1vbWVudCwgaXQgaXMgdXNlZCB3aXRob3V0IHF1YWxp ZmljYXRpb24iPkV4dGVuZGVkIExvV1BBTjwvYT46ICBUaGUgRXh0ZW5kZWQgTG9XUEFOIHRl Y2huaXF1ZSBkZWZpbmVkIGluIChkcmFmdA0KICAgICAgdGJkKSBwcm92aWRlcyBEQUQgZHVy aW5nIGl0cyBFUiByZWdpc3RyYXRpb24uDQogDQogICBSb3V0aW5nIHByb3RvY29sOiAgSWYg c3VwcG9ydGVkLCBhIHJvdXRpbmcgcHJvdG9jb2wgbWVjaGFuaXNtIGNvdWxkDQogICAgICBi ZSB1c2VkIHRvIGNoZWNrIGZvciB0aGUgZXhpc3RhbmNlIG9mIGFuIGFkZHJlc3MgaW4gdGhl IExvV1BBTiwNCiAgICAgIGFzc3VtaW5nIHRoYXQgaXQgaXMgY292ZXJlZCBieSBhIHNpbmds ZSByb3V0aW5nIGRvbWFpbi4NCiANCjxzcGFuIGNsYXNzPSJoMyI+PGEgbmFtZT0ic2VjdGlv bi01LjQiPjUuNDwvYT4uICBOZXh0LWhvcCBEZXRlcm1pbmF0aW9uPC9zcGFuPiANCiANCiAg IFRoZSBJUCBhZGRyZXNzIG9mIHRoZSBuZXh0LWhvcCBmb3IgYSBkZXN0aW5hdGlvbiBpcyBk ZXRlcm1pbmVkIGFzDQogICBmb2xsb3dzLiAgRGVzdGluYXRpb25zIHRvIHRoZSBsaW5rLWxv Y2FsIHByZWZpeCAoRkU4MDo6KSBhcmUgYWx3YXlzDQogICBzZW50IG9uIHRoZSBsaW5rIHRv IHRoYXQgZGVzdGluYXRpb24uICBBbGwgb3RoZXIgcHJlZml4ZXMgYXJlIGFzc3VtZWQNCiAg IHRvIGJlIG9mZi1saW5rIGFzIHJlY29tbWVuZGVkIGluDQogICBbPGEgaHJlZj0iI3JlZi1J LUQuaWV0Zi1hdXRvY29uZi1hZGhvYy1hZGRyLW1vZGVsIiB0aXRsZT0nIklQIEFkZHJlc3Np bmcgTW9kZWwgaW4gQWQgSG9jIE5ldHdvcmtzIic+SS1ELmlldGYtYXV0b2NvbmYtYWRob2Mt YWRkci1tb2RlbDwvYT5dLiAgVGhleSBhcmUgdGhlcmVmb3JlIHNlbnQgdG8gdGhlDQogICBJ UCBhZGRyZXNzIG9mIGEgcm91dGVyIGNob3NlbiBmcm9tIHRoZSBEZWZhdWx0IFJvdXRlciBM aXN0Lg0KIA0KICAgTXVsdGljYXN0IGFkZHJlc3NlcyBhcmUgY29uc2lkZXJlZCB0byBiZSBv bi1saW5rIGFuZCBhcmUgcmVzb2x2ZWQgYXMNCiAgIHNwZWNpZmllZCBpbiBbPGEgaHJlZj0i Li9yZmM0OTQ0IiB0aXRsZT0nIlRyYW5zbWlzc2lvbiBvZiBJUHY2IFBhY2tldHMgb3ZlciBJ RUVFIDgwMi4xNS40IE5ldHdvcmtzIic+UkZDNDk0NDwvYT5dIG9yIDxhIGNsYXNzPWNvbW1l bnQgaHJlZj0iIyIgdGl0bGU9IlRoaXMgaXMgYSBiaXQgdmFndWUuIj5yZWxhdGl2ZSBmdXR1 cmUgZG9jdW1lbnRzPC9hPi4gIEEgPHNwYW4gY2xhc3M9aGlsaXRlPm5vZGU8L3NwYW4+DQog ICBpcyBub3QgcmVxdWlyZWQgdG8gbWFpbnRhaW4gYSBtaW5pbXVtIG9mIG9uZSBidWZmZXIg cGVyIG5laWdoYm9yIGFzDQogICBzcGVjaWZpZWQgaW4gWzxhIGhyZWY9Ii4vcmZjNDg2MSIg dGl0bGU9JyJOZWlnaGJvciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiJz5S RkM0ODYxPC9hPl0sIGFzIGFkZHJlc3MgbG9va3VwIGlzIG5vdCBwZXJmb3JtZWQgYXMgcGFy dCBvZg0KICAgbmV4dC1ob3AgZGV0ZXJtaW5hdGlvbi4gIEFueWNhc3QgYWRkcmVzc2VzIGFy ZSBhbHdheXMgY29uc2lkZXJlZCB0bw0KICAgYmUgb2ZmLWxpbmsuDQogDQo8c3BhbiBjbGFz cz0iaDMiPjxhIG5hbWU9InNlY3Rpb24tNS41Ij41LjU8L2E+LiAgQWRkcmVzcyBSZXNvbHV0 aW9uPC9zcGFuPiANCiANCiAgIFRoZSBub2RlIHJlZ2lzdHJhdGlvbiBtZWNoYW5pc20gcHJv dmlkZXMgc3VmZmljaWVudCBhIHByaW9yaSBzdGF0ZSBpbg0KICAgbm9kZXMgYW5kIHJvdXRl cnMgdG8gcmVzb2x2ZSBhbiBJUHY2IGFkZHJlc3MgdG8gaXRzIGFzc29jaWF0ZWQgbGluay0N CiAgIGxheWVyIGFkZHJlc3Mgb24gdGhlIG5vZGUtcm91dGVyIGludGVyZmFjZS4gIEFzIHBy ZWZpeGVzIGFyZSBhbHdheXMNCiAgIGFzc3VtZWQgdG8gYmUgb2ZmLWxpbmssIHJlc29sdXRp b24gYmV0d2VlbiBob3N0cyBpcyBub3QgbmVlZGVkLg0KIA0KICAgSW5mb3JtYXRpb24gYWJv dXQgbGluay1sYXllciBhZGRyZXNzZXMgaXMgc3RvcmVkIGJ5IG5vZGVzIGFib3V0DQogICBy b3V0ZXJzIGluIGl0cyBkZWZhdWx0IHJvdXRlciBsaXN0LCBhbmQgYnkgcm91dGVycyBhYm91 dCBub2RlcyBpbiBpdHMNCiAgIGJpbmRpbmcgdGFibGUuICBUaGlzIGluZm9ybWF0aW9uIGlz IHN0b3JlZCBkdXJpbmcgdGhlIG5vZGUNCiAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiAgSW4g b3JkZXIgdG8gYWNoaWV2ZSBMb1dQQU4gY29tcHJlc3Npb24sIG1vc3QNCiAgIGdsb2JhbCBh ZGRyZXNzZXMgYXJlIGFsc28gZm9ybWVkIHVzaW5nIGEgbGluay1sYXllciBhZGRyZXNzLiAg QSBub2RlDQogICBjYW4gbWluaW1pemUgbWVtb3J5IHVzYWdlIGJ5IG1ha2luZyB1c2Ugb2Yg YW4gZWR1Y2F0ZWQgZ3Vlc3MgYW5kDQogICBzdG9yaW5nIGxpbmstbGF5ZXIgYWRkcmVzcyBp bmZvcm1hdGlvbiBvbmx5IGlmIGl0IGRpZmZlcnMgZnJvbSB0aGUNCiAgIGxpbmstbGF5ZXIg YWRkcmVzcyBjb3JyZXNwb25kaW5nIHRvIHRoZSBJSUQgb2YgdGhlIElQdjYgYWRkcmVzcw0K ICAgKGkuZS4sIGRpZmZlcnMgaW4gbW9yZSB0aGFuIHRoZSBvbi1saW5rL2dsb2JhbCBiaXQg YmVpbmcgaW52ZXJ0ZWQpLg0KIA0KIA0KIA0KIA0KIA0KPHNwYW4gY2xhc3M9ImdyZXkiPlNo ZWxieSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA1LCAyMDEwICAgICAgICAg ICAgICAgIFtQYWdlIDI4XTwvc3Bhbj4gDQo8L3ByZT48cHJlIGNsYXNzPSduZXdwYWdlJz48 YSBuYW1lPSJwYWdlLTI5IiBpZD0icGFnZS0yOSIgaHJlZj0iI3BhZ2UtMjkiIGNsYXNzPSJp bnZpc2libGUiPiA8L2E+IA0KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAg ICAgICAgNkxvV1BBTiBOZWlnaGJvciBEaXNjb3ZlcnkgICAgICAgICAgRmVicnVhcnkgMjAx MDwvc3Bhbj4gDQogDQogDQo8c3BhbiBjbGFzcz0iaDMiPjxhIG5hbWU9InNlY3Rpb24tNS42 Ij41LjY8L2E+LiAgVW5yZWFjaGFiaWxpdHkgRGV0ZWN0aW9uPC9zcGFuPiANCiANCiAgIFVu cmVhY2hhYmlsaXR5IGJldHdlZW4gYSBub2RlIGFuZCByb3V0ZXIgaXMgZGV0ZXJtaW5lZCBi YXNlZCBvbiBOUi9OQw0KICAgYW5kIFJTL1JBIGV4Y2hhbmdlcyBhbmQgb3RoZXIgdW5pY2Fz dCBMMyBkYXRhIG1lc3NhZ2VzLiAgSG9zdC1ob3N0DQogICB1bnJlYWNoYWJpbGl0eSBkZXRl Y3Rpb24gaXMgb3V0IG9mIHNjb3BlLg0KIA0KICAgSW4gb3JkZXIgdG8gZGV0ZWN0IHVucmVh Y2hhYmxlIGRlc3RpbmF0aW9ucywgbm9kZXMgU0hPVUxEIHN1cHBvcnQNCiAgIHR5cGUgMSBJ Q01QdjYgZGVzdGluYXRpb24gdW5yZWFjaGFibGUgbWVzc2FnZXMgWzxhIGhyZWY9Ii4vcmZj NDQ0MyIgdGl0bGU9JyJJbnRlcm5ldCBDb250cm9sIE1lc3NhZ2UgUHJvdG9jb2wgKElDTVB2 NikgZm9yIHRoZSBJbnRlcm5ldCBQcm90b2NvbCBWZXJzaW9uIDYgKElQdjYpIFNwZWNpZmlj YXRpb24iJz5SRkM0NDQzPC9hPl0uICBMb1dQQU4NCiAgIFJvdXRlcnMgb3IgRWRnZSBSb3V0 ZXJzIG1ha2UgdXNlIG9mIElDTVB2NiBkZXN0aW5hdGlvbiB1bnJlYWNoYWJsZSB0bw0KICAg aW5kaWNhdGUgdGhhdCBkZWxpdmVyeSB0byB0aGF0IGRlc3RpbmF0aW9uIGlzIG5vdCBwb3Nz aWJsZS4NCiANCjxzcGFuIGNsYXNzPSJoMyI+PGEgbmFtZT0ic2VjdGlvbi01LjciPjUuNzwv YT4uICBDb250ZXh0IERpc3NlbWluYXRpb248L3NwYW4+IA0KIA0KICAgTmV0d29yayBjb25m aWd1cmF0aW9uIHBhcmFtZXRlcnMgY2FycmllZCBpbiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudHMN CiAgIG9yaWdpbmF0ZSBhdCA8c3BhbiBjbGFzcz1oaWxpdGU+RWRnZSBSb3V0ZXI8L3NwYW4+ cyBhbmQgPGEgY2xhc3M9Y29tbWVudCBocmVmPSIjIiB0aXRsZT0iSG93PyBObyBtZWNoYW5p c20gaXMgZGVzY3JpYmVkIj5tdXN0IGRpc3NlbWluYXRlIHRvIGFsbCByb3V0ZXJzIGFuZA0K ICAgaG9zdHMgd2l0aGluIHRoZSBMb1dQQU48L2E+LiAgUkFzIGluY2x1ZGUgZWl0aGVyIDZM b1dQQU4gSW5mb3JtYXRpb24NCiAgIE9wdGlvbnMgKG9uZSBmb3IgZWFjaCBjb250ZXh0KSBh bmQgYSA2TG9XUEFOIFN1bW1hcnkgT3B0aW9uLCBvciBqdXN0DQogICBhIDZMb1dQQU4gU3Vt bWFyeSBPcHRpb24uDQogDQogICBGb3IgdGhlIGRpc3NlbWluYXRpb24gb2YgY29udGV4dCBp bmZvcm1hdGlvbiB1c2luZyB0aGUgNklPLCBhIHN0cmljdA0KICAgbGlmZWN5Y2xlIFNIT1VM RCBiZSB1c2VkIGluIG9yZGVyIHRvIGVuc3VyZSB0aGUgY29udGV4dCBpbmZvcm1hdGlvbg0K ICAgc3RheXMgc3luY2hyb25pemVkIHRocm91Z2hvdXQgdGhlIExvV1BBTi4gIE5ldyBjb250 ZXh0IGluZm9ybWF0aW9uDQogICBTSE9VTEQgYmUgaW50cm9kdWNlZCBpbnRvIHRoZSBMb1dQ QU4gd2l0aCBDPTEgYW5kIFY9MCwgdG8gZW5zdXJlIGl0DQogICBpcyBrbm93biBieSBhbGwg bm9kZXMgdGhhdCBtYXkgaGF2ZSB0byBkZWNvbXByZXNzIGJhc2VkIG9uIHRoaXMNCiAgIGNv bnRleHQgaW5mb3JtYXRpb24uICBPbmx5IHdoZW4gaXQgaXMgcmVhc29uYWJsZSB0byBhc3N1 bWUgdGhhdCB0aGlzDQogICBpbmZvcm1hdGlvbiB3YXMgc3VjY2Vzc2Z1bGx5IGRpc3NlbWlu YXRlZCBTSE9VTEQgYW4gb3B0aW9uIHdpdGggQz0xDQogICBhbmQgVj0xIGJlIHNlbnQsIGVu YWJsaW5nIHRoZSBhY3R1YWwgdXNlIG9mIHRoZSBjb250ZXh0IGluZm9ybWF0aW9uDQogICBm b3IgY29tcHJlc3Npb24uDQogDQogICBDb252ZXJzZWx5LCB0byBhdm9pZCB0aGF0IG5vZGVz IHNlbmQgcGFja2V0cyBtYWtpbmcgdXNlIG9mIHByZXZpb3VzDQogICB2YWx1ZXMgb2YgY29u dGV4dHMsIHJlc3VsdGluZyBpbiBhbWJpZ3VpdHkgd2hlbiByZWNlaXZpbmcgYSBwYWNrZXQN CiAgIHRoYXQgdXNlcyBhIHJlY2VudGx5IGNoYW5nZWQgY29udGV4dCwgb2xkIHZhbHVlcyBv ZiBhIGNvbnRleHQgU0hPVUxEDQogICBiZSB0YWtlbiBvdXQgb2YgdXNlIGZvciBhIHdoaWxl IGJlZm9yZSBuZXcgdmFsdWVzIGFyZSBhc3NpZ25lZCB0bw0KICAgdGhpcyBzcGVjaWZpYyBj b250ZXh0LiAgVGhhdCBpcywgaW4gcHJlcGFyYXRpb24gZm9yIGEgY2hhbmdlIG9mDQogICBj b250ZXh0IGluZm9ybWF0aW9uLCBpdHMgZGlzc2VtaW5hdGlvbiBTSE9VTEQgY29udGludWUg Zm9yIGF0IGxlYXN0DQogICBNSU5fQ09OVEVYVF9DSEFOR0VfREVMQVkgd2l0aCBDPTEgYW5k IFY9MC4gIE9ubHkgd2hlbiBpdCBpcw0KICAgcmVhc29uYWJsZSB0byBhc3N1bWUgdGhhdCB0 aGUgZmFjdCB0aGF0IHRoZSBjb250ZXh0IGlzIG5vdyBpbnZhbGlkDQogICB3YXMgc3VjY2Vz c2Z1bGx5IGRpc3NlbWluYXRlZCwgc2hvdWxkIHRoZSBjb250ZXh0IElEIGJlIHRha2VuIG91 dCBvZg0KICAgZGlzc2VtaW5hdGlvbiBvciByZXVzZWQgd2l0aCBhIGRpZmZlcmVudCBJbmZv cm1hdGlvbiBmaWVsZC4gIEluIHRoZQ0KICAgbGF0dGVyIGNhc2UsIGRpc3NlbWluYXRpb24g b2YgdGhlIG5ldyB2YWx1ZSBhZ2FpbiBTSE9VTEQgc3RhcnQgd2l0aA0KICAgQz0xIGFuZCBW PTAsIGFzIGFib3ZlLg0KIA0KICAgVGhlIDZMb1dQQU4gU3VtbWFyeSBPcHRpb24gaXMgdXNl ZCB0byBzdXBwb3J0IGluZm9ybWF0aW9uDQogICBkaXNzZW1pbmF0aW9uIGZyb20gb25lIG9y IG1vcmUgPHNwYW4gY2xhc3M9aGlsaXRlPkVkZ2UgUm91dGVyPC9zcGFuPnMgdG8gYWxsIG90 aGVyIG5vZGVzIGluIHRoZQ0KICAgTG9XUEFOLiAgVGhlIG9wdGlvbiBpbmNsdWRlcyBhICJW IiBmbGFnIHdoaWNoIGluZGljYXRlcyB0aGF0IHRoZQ0KICAgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoZSBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBpcyB2YWxpZC4gIFRoZQ0KICAgb3B0 aW9uIGFsc28gaW5jbHVkZXMgYSBzZXF1ZW5jZSBudW1iZXIgdG8gZW5zdXJlIHRoYXQgYWxs IG5vZGVzDQogICBjb252ZXJnZSBvbiB0aGUgc2FtZSBzZXR0aW5ncy4gIFRoZSBzZXF1ZW5j ZSBudW1iZXIgaXMgaW5jcmVtZW50ZWQgYnkNCiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5 Ij5TaGVsYnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAg ICAgICAgICAgICBbUGFnZSAyOV08L3NwYW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFn ZSc+PGEgbmFtZT0icGFnZS0zMCIgaWQ9InBhZ2UtMzAiIGhyZWY9IiNwYWdlLTMwIiBjbGFz cz0iaW52aXNpYmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFm dCAgICAgICAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5 IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAgdGhlIG9yaWdpbmF0aW5nIEVkZ2UgUm91dGVyIGVh Y2ggdGltZSB0aGUgc2V0IG9mIHByZWZpeCBpbmZvcm1hdGlvbg0KICAgY2hhbmdlcy4NCiAN CiAgIEFzIHRoZSBudW1iZXIgb2YgcHJlZml4ZXMgb3IgYWRkcmVzc2VzIGluY2x1ZGVkIGZv ciBjb250ZXh0DQogICBjb21wcmVzc2lvbiBpbiBhbiBSQSBtYXkgYmUgbGFyZ2UgKHVwIHRv IDE2KSwgaXQgaXMgYmVuZWZpY2lhbCB0bw0KICAgYXZvaWQgdGhlIG5lZWQgdG8gYWx3YXlz IGluY2x1ZGUgYWxsIG9wdGlvbnMgaW4gZXZlcnkgUkEuICBUaGVyZWZvcmUNCiAgIHJvdXRl cnMgU0hPVUxEIG9ubHkgaW5jbHVkZSB0aGUgNkxvV1BBTiBTdW1tYXJ5IE9wdGlvbiBpbiB1 bnNvbGljaXRlZA0KICAgUkFzLCB1bmxlc3MgYSBzZXQgb2YgcHJlZml4IGluZm9ybWF0aW9u IHdpdGggYSBuZXcgc2VxdWVuY2UgbnVtYmVyIGlzDQogICBiZWluZyBkaXNzZW1pbmF0ZWQu ICBJbiB0aGUgY2FzZSBvZiBhIG5ldyBzZXF1ZW5jZSBudW1iZXIsIHRoZSByb3V0ZXINCiAg IFNIT1VMRCBpbmNsdWRlIGFsbCA2TG9XUEFOIEluZm9ybWF0aW9uIE9wdGlvbnMgaW4gdGhl IFJBLiAgQSBub2RlIG1heQ0KICAgdXNlIGFuIFJTIHdpdGggQ29kZSBzZXQgdG8gMSBpbiBv cmRlciB0byBnZXQgdGhlIHdob2xlIHByZWZpeA0KICAgaW5mb3JtYXRpb24gc2V0IGluIGNh c2UgaXQgbWlzc2VzIHRoZSBSQSBzZW50IHdoZW4gdGhlIHNlcXVlbmNlDQogICBudW1iZXIg Y2hhbmdlcy4gIEFuIFJTIHdpdGggQ29kZSBzZXQgdG8gMCBpcyByZXNwb25kZWQgdG8gd2l0 aCBhbiBSQQ0KICAgd2l0aCB0aGUgNlNPLg0KIA0KIA0KPHNwYW4gY2xhc3M9ImgyIj48YSBu YW1lPSJzZWN0aW9uLTYiPjY8L2E+LiAgPHNwYW4gY2xhc3M9aGlsaXRlPk5vZGU8L3NwYW4+ IFNwZWNpZmljYXRpb248L3NwYW4+IA0KIA0KICAgVGhpcyBzZWN0aW9uIHNwZWNpZmllcyB0 aGUgY29uY2VwdHVhbCBkYXRhIHN0cnVjdHVyZXMgYW5kIHZhcmlhYmxlcw0KICAgb2YgYSBM b1dQQU4gTm9kZS4NCiANCjxzcGFuIGNsYXNzPSJoMyI+PGEgbmFtZT0ic2VjdGlvbi02LjEi PjYuMTwvYT4uICBDb25jZXB0dWFsIHN0cnVjdHVyZXM8L3NwYW4+IA0KIA0KICAgPHNwYW4g Y2xhc3M9aGlsaXRlPk5vZGU8L3NwYW4+cyBtYWtlIHVzZSBvZiB0aGUgZm9sbG93aW5nIGNv bmNlcHR1YWwgZGF0YSBzdHJ1Y3R1cmVzOg0KIA0KICAgUHJlZml4IExpc3QgIC0gVGhlIGxp c3Qgb2YgcHJlZml4ZXMgd2hpY2ggYXJlIGFkdmVydGlzZWQgaW4gUm91dGVyDQogICAgICBB ZHZlcnRpc2VtZW50cywgYWxvbmcgd2l0aCBhbiBhc3NvY2lhdGVkIGludmFsaWRhdGlvbiB0 aW1lci4gIEVhY2gNCiAgICAgIGVudHJ5IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2VxdWVu Y2UgbnVtYmVyIGxhc3QgYWR2ZXJ0aXNlZCBpbg0KICAgICAgdGhlIDZMb1dQQU4gU3VtbWFy eSBPcHRpb24uICBVbmxpa2UgaW4gWzxhIGhyZWY9Ii4vcmZjNDg2MSIgdGl0bGU9JyJOZWln aGJvciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiJz5SRkM0ODYxPC9hPl0s IHRoZXNlIHByZWZpeGVzDQogICAgICBhcmUgYWx3YXlzIGFzc3VtZWQgdG8gYmUgb2ZmLWxp bmsuDQogDQogICBDb250ZXh0IExpc3QgIC0gVGhlIGxpc3Qgb2YgY29udGV4dDxzcGFuIGNs YXNzPWhpbGl0ZT5zPC9zcGFuPiBhbmQgdGhlaXIgYXNzb2NpYXRlZCBDSUQgd2hpY2gNCiAg ICAgIGFyZSBhZHZlcnRpc2VkIGluIFJvdXRlciBBZHZlcnRpc2VtZW50cywgYWxvbmcgd2l0 aCBhbiBhc3NvY2lhdGVkDQogICAgICBpbnZhbGlkYXRpb24gdGltZXIuICBFYWNoIGVudHJ5 IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2VxdWVuY2UNCiAgICAgIG51bWJlciBsYXN0IGFk dmVydGlzZWQgaW4gdGhlIDZMb1dQQU4gU3VtbWFyeSBPcHRpb24uICBUaGlzIGxpc3QNCiAg ICAgIG1heSBiZSByZWFsaXplZCB0b2dldGhlciB3aXRoIHRoZSBQcmVmaXggTGlzdC4NCiAN CiAgIERlZmF1bHQgUm91dGVyIExpc3QgIC0gQXMgaW4gWzxhIGhyZWY9Ii4vcmZjNDg2MSIg dGl0bGU9JyJOZWlnaGJvciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiJz5S RkM0ODYxPC9hPl0uICBGb3IgbmV0d29ya3Mgd2hlcmUgYWRkcmVzcw0KICAgICAgcmVzb2x1 dGlvbiBuZWVkcyB0byBiZSBwZXJmb3JtZWQsIHRoaXMgbGlzdCBhbHNvIGNvbnRhaW5zIGxp bmstDQogICAgICBsYXllciBpbmZvcm1hdGlvbiBhYm91dCBlYWNoIHJvdXRlci4NCiANCiAg IFRoZXNlIGNvbmNlcHR1YWwgZGF0YSBzdHJ1Y3R1cmVzIG1heSBiZSByZWFsaXplZCBpbiBt YW55IHdheXMuICBBcw0KICAgPHNwYW4gY2xhc3M9aGlsaXRlPm5vZGU8L3NwYW4+cyBoYXZl IHZlcnkgbGltaXRlZCBtZW1vcnkgdGhlIG51bWJlciBvZiBjYWNoZSBlbnRyaWVzDQogICBz aG91bGQgYmUgbGltaXRlZCwgZHVwbGljYXRlIGVudHJpZXMgYmV0d2VlbiBjYWNoZXMgcmVm ZXJlbmNlZCwgYW5kDQogICBmdWxsIElQdjYgYWRkcmVzc2VzIHJlcHJlc2VudGVkIGluIGEg Y29tcHJlc3NlZCBmb3JtYXQgd2hlcmUNCiAgIHBvc3NpYmxlLg0KIA0KIA0KIA0KIA0KIA0K PHNwYW4gY2xhc3M9ImdyZXkiPlNoZWxieSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCA1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDMwXTwvc3Bhbj4gDQo8L3ByZT48 cHJlIGNsYXNzPSduZXdwYWdlJz48YSBuYW1lPSJwYWdlLTMxIiBpZD0icGFnZS0zMSIgaHJl Zj0iI3BhZ2UtMzEiIGNsYXNzPSJpbnZpc2libGUiPiA8L2E+IA0KPHNwYW4gY2xhc3M9Imdy ZXkiPkludGVybmV0LURyYWZ0ICAgICAgICAgNkxvV1BBTiBOZWlnaGJvciBEaXNjb3Zlcnkg ICAgICAgICAgRmVicnVhcnkgMjAxMDwvc3Bhbj4gDQogDQogDQo8c3BhbiBjbGFzcz0iaDMi PjxhIG5hbWU9InNlY3Rpb24tNi4yIj42LjI8L2E+LiAgQ29uY2VwdHVhbCB2YXJpYWJsZXM8 L3NwYW4+IA0KIA0KICAgVGhlIGZvbGxvd2luZyB2YXJpYWJsZXMgYXJlIGtlcHQgZm9yIGVh Y2ggaW50ZXJmYWNlIG9uIGEgbm9kZSwgYW5kDQogICBkZWZhdWx0IHZhbHVlcyBhcmUgb3Zl cnJpZGRlbiBieSBpbmZvcm1hdGlvbiBpbiBSb3V0ZXINCiAgIEFkdmVydGlzZW1lbnRzOg0K IA0KICAgQ3VySG9wTGltaXQgICAgICAgICBUaGUgZGVmYXVsdCBob3AgbGltaXQgdG8gYmUg dXNlZCB3aGVuIHNlbmRpbmcgSVANCiAgICAgICAgICAgICAgICAgICAgICAgcGFja2V0cy4N CiANCiAgIEN1clRJRCAgICAgICAgICAgICAgVGhlIGN1cnJlbnQgVHJhbnNhY3Rpb24gSUQg KFRJRCkgdmFsdWUgZm9yIHVzZSBpbg0KICAgICAgICAgICAgICAgICAgICAgICBOUiBtZXNz YWdlcy4NCiANCiAgIEJpbmRpbmdMaWZldGltZSAgICAgVGhlIGJpbmRpbmcgbGlmZXRpbWUg c2VudCBpbiBOb2RlIFJlZ2lzdHJhdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICBtZXNz YWdlcy4NCiANCiAgIFJlZ2lzdHJhdGlvblRpbWVvdXQgVGhlIHRpbWUgdG8gd2FpdCBmb3Ig YSBOb2RlIENvbmZpcm1hdGlvbiBhZnRlcg0KICAgICAgICAgICAgICAgICAgICAgICBzZW5k aW5nIGEgTm9kZSBSZWdpc3RyYXRpb24uICBTSE9VTEQgYmUgYXQgbGVhc3QNCiAgICAgICAg ICAgICAgICAgICAgICAgTUlOX05SX1RJTUVPVVQuDQogDQogICA8YSBjbGFzcz1jb21tZW50 IGhyZWY9IiMiIHRpdGxlPSJIb3cgZG9lcyB0aGlzIHdvcmsgaW4gY29uanVuY3Rpb24gd2l0 aCB0aGUgVElEPyBJcyB0aGUgVElEIGtlcHQgdGhlIHNhbWUgZm9yIGVhY2ggcmV0cnk/Ij5S ZWdpc3RyYXRpb25SZXRyaWVzPC9hPiBUaGUgbnVtYmVyIG9mIHRpbWVzIHRvIHRyeSB0byBz ZW5kIGEgTm9kZQ0KICAgICAgICAgICAgICAgICAgICAgICBSZWdpc3RyYXRpb24sIHdoaWNo IFNIT1VMRCBiZSBsZXNzIHRoYW4NCiAgICAgICAgICAgICAgICAgICAgICAgTUFYX05SX1JF VFJJRVMuDQogDQogDQo8c3BhbiBjbGFzcz0iaDIiPjxhIG5hbWU9InNlY3Rpb24tNyI+Nzwv YT4uICA8c3BhbiBjbGFzcz1oaWxpdGU+Um91dGVyPC9zcGFuPiBTcGVjaWZpY2F0aW9uPC9z cGFuPiANCiANCiAgIDxzcGFuIGNsYXNzPWhpbGl0ZT5Sb3V0ZXI8L3NwYW4+cyBhcmUgdXNl ZCBpbiBhIHJvdXRlPHNwYW4gY2xhc3M9aGlsaXRlPi08L3NwYW4+b3ZlciBjb25maWd1cmF0 aW9uIHdoZXJlIHRoZQ0KICAgbmV0d29yayBpcyBjb21wb3NlZCBvZiBvdmVybGFwcGluZyBs aW5rLWxvY2FsIHNjb3Blcy4gIDxzcGFuIGNsYXNzPWhpbGl0ZT5FZGdlDQogICBSb3V0ZXJz PC9zcGFuPiBpbXBsZW1lbnQgPHNwYW4gY2xhc3M9aGlsaXRlPnJvdXRlcjwvc3Bhbj4gZnVu Y3Rpb25hbGl0eS4gIEFzIGEgcmVzdWx0LCB3ZQ0KICAgZXh0ZW5kIGNsYXNzaWMgTkQgYXMg c3BlY2lmaWVkIGluIFs8YSBocmVmPSIuL3JmYzQ4NjEiIHRpdGxlPSciTmVpZ2hib3IgRGlz Y292ZXJ5IGZvciBJUCB2ZXJzaW9uIDYgKElQdjYpIic+UkZDNDg2MTwvYT5dIHRvIG9wZXJh dGUgb3ZlciBzdWNoIG5vbi0NCiAgIHRyYW5zaXRpdmUgTG9XUEFOIGxpbmtzLiAgVGhpcyBz ZWN0aW9uIGRlc2NyaWJlcyBORCBmb3IgPHNwYW4gY2xhc3M9aGlsaXRlPg0KICAgcm91dGVy IG9wZXJhdGlvbnMgaW4gYSBMb1dQQU48L3NwYW4+LiAgTm90ZSB0aGF0IHRoaXMgc2VjdGlv biBkb2VzIG5vdCBlbnRpcmVseSBhcHBseSB0bw0KICAgcHVyZSBNZXNoIFVuZGVyIExvV1BB TnMgd2hlcmUgdGhlIGFyZSBubyA8c3BhbiBjbGFzcz1oaWxpdGU+cm91dGVyPC9zcGFuPnMs IGFsdGhvdWdoDQogICB0aGV5IGRvIGhhdmUgPHNwYW4gY2xhc3M9aGlsaXRlPkVkZ2UgUm91 dGVyPC9zcGFuPnMuDQogDQo8c3BhbiBjbGFzcz0iaDMiPjxhIG5hbWU9InNlY3Rpb24tNy4x Ij43LjE8L2E+LiAgUm91dGVyIENvbmZpZ3VyYXRpb24gVmFyaWFibGVzPC9zcGFuPiANCiAN CiAgIEEgcm91dGVyIE1VU1QgYWxsb3cgdGhlIGNvbmZpZ3VyYXRpb24gb2YgY29uY2VwdHVh bCB2YXJpYWJsZXMgYXMNCiAgIGRlZmluZWQgaW4gPGEgaHJlZj0iLi9yZmM0ODYxI3NlY3Rp b24tNi4yLjEiPlNlY3Rpb24mbmJzcDs2LjIuMSBvZiBbUkZDNDg2MV08L2E+LiAgQWR2UmVh Y2hhYmxlVGltZSBhbmQNCiAgIEFkdlJldHJhbnNUaW1lciBhcmUgbm90IHVzZWQuDQogDQo8 c3BhbiBjbGFzcz0iaDMiPjxhIG5hbWU9InNlY3Rpb24tNy4yIj43LjI8L2E+LiAgQmVjb21p bmcgYW4gQWR2ZXJ0aXNpbmcgSW50ZXJmYWNlPC9zcGFuPiANCiANCiAgIEFuIGludGVyZmFj ZSBtYXkgYmVjb21lIGFuIGFkdmVydGlzaW5nIGludGVyZmFjZSBhcyBzcGVjaWZpZWQgaW4N CiAgIDxhIGhyZWY9Ii4vcmZjNDg2MSNzZWN0aW9uLTYuMi4yIj5TZWN0aW9uJm5ic3A7Ni4y LjIgb2YgW1JGQzQ4NjFdPC9hPi4NCiANCiAgIEEgPHNwYW4gY2xhc3M9aGlsaXRlPnJvdXRl cjwvc3Bhbj4ncyBpbnRlcmZhY2UgTUFZIGJlY29tZSBhbiBhZHZlcnRpc2luZyBpbnRlcmZh Y2UNCiAgIGJlZm9yZSBhbGwgb2YgaXRzIHJvdXRlciB2YXJpYWJsZXMgaGF2ZSBiZWVuIGlu aXRpYWxpemVkLiAgVGhlIHJvdXRlcg0KIA0KIA0KIA0KPHNwYW4gY2xhc3M9ImdyZXkiPlNo ZWxieSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA1LCAyMDEwICAgICAgICAg ICAgICAgIFtQYWdlIDMxXTwvc3Bhbj4gDQo8L3ByZT48cHJlIGNsYXNzPSduZXdwYWdlJz48 YSBuYW1lPSJwYWdlLTMyIiBpZD0icGFnZS0zMiIgaHJlZj0iI3BhZ2UtMzIiIGNsYXNzPSJp bnZpc2libGUiPiA8L2E+IA0KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAg ICAgICAgNkxvV1BBTiBOZWlnaGJvciBEaXNjb3ZlcnkgICAgICAgICAgRmVicnVhcnkgMjAx MDwvc3Bhbj4gDQogDQogDQogICBNVVNUIGxlYXJuIHRoZXNlIHZhcmlhYmxlcyAoZS5nLiAg QWR2Q3VySG9wTGltaXQsIHByZWZpeCBhbmQgY29udGV4dA0KICAgaW5mb3JtYXRpb24sIGV0 Yy4pIGZyb20gbmVpZ2hib3Jpbmcgcm91dGVycy4gIFdoaWxlIHRoZSB2YXJpYWJsZXMgYXJl DQogICBub3QgaW5pdGlhbGl6ZWQsIHRoZSByb3V0ZXIgTUFZIHNlbmQgUm91dGVyIEFkdmVy dGlzZW1lbnQgd2l0aCB0aGUNCiAgICJTb2xpY2l0IiBmbGFnIHNldCB0byBzb2xpY2l0IFJv dXRlciBBZHZlcnRpc2VtZW50cyBmcm9tIG5laWdoYm9yaW5nDQogICByb3V0ZXJzLiAgSG93 ZXZlciwgdGhlIHJvdXRlciBNVVNUIHNldCB0aGUgUm91dGVyIExpZmV0aW1lIGZpZWxkIHRv DQogICB6ZXJvIHdoaWxlIG9uZSBvciBtb3JlIG9mIGl0cyB2YXJpYWJsZXMgYXJlIHVuaW5p dGlhbGl6ZWQuDQogDQo8c3BhbiBjbGFzcz0iaDMiPjxhIG5hbWU9InNlY3Rpb24tNy4zIj43 LjM8L2E+LiAgUm91dGVyIEFkdmVydGlzZW1lbnQgTWVzc2FnZSBDb250ZW50PC9zcGFuPiAN CiANCiAgIEEgcm91dGVyIHNlbmRzIHBlcmlvZGljIGFzIHdlbGwgYXMgc29saWNpdGVkIFJv dXRlciBBZHZlcnRpc2VtZW50cw0KICAgb3V0IGl0cyBhZHZlcnRpc2luZyBpbnRlcmZhY2Uu ICBPdXRnb2luZyBSb3V0ZXIgQWR2ZXJ0aXNlbWVudHMgYXJlDQogICBmaWxsZWQgd2l0aCB0 aGUgZm9sbG93aW5nIHZhbHVlcyBjb25zaXN0ZW50IHdpdGggdGhlIG1lc3NhZ2UgZm9ybWF0 DQogICBnaXZlbiBpbiB0aGlzIGRvY3VtZW50Lg0KIA0KICAgICAgLSBJbiB0aGUgUm91dGVy IExpZmV0aW1lIGZpZWxkOiBpZiB0aGUgcm91dGVyIGhhcyBhIGRlZmF1bHQgcm91dGUsDQog ICAgICB0aGUgaW50ZXJmYWNlJ3MgY29uZmlndXJlZCBBZHZEZWZhdWx0TGlmZXRpbWUuICBJ ZiB0aGUgcm91dGVyIGRvZXMNCiAgICAgIG5vdCBoYXZlIGEgZGVmYXVsdCByb3V0ZSwgemVy by4NCiANCiAgICAgIC0gSW4gdGhlIE0gYW5kIE8gZmxhZ3M6IHRoZSBjdXJyZW50IHZhbHVl IG9mIEFkdk1hbmFnZWRGbGFnIGFuZA0KICAgICAgQWR2T3RoZXJDb25maWdGbGFnLCByZXNw ZWN0aXZlbHkuDQogDQogICAgICAtIDxhIGNsYXNzPWNvbW1lbnQgaHJlZj0iIyIgdGl0bGU9 IlRoZXJlIGFyZSBvdGhlciB2YWx1ZXMgb2YgUHJmIHdoaWNoIGNhbiBiZSBhcHBsaWVkIHRv IGEgcm91dGVyIj5JbiB0aGUgUHJlZmVyZW5jZSBmbGFnOiB0aGlzIGZsYWcgaXMgc2V0IHRv IDAwIHRvIGluZGljYXRlIHRoYXQNCiAgICAgIHRoZSBzZW5kZXIgaXMgYSA8c3BhbiBjbGFz cz1oaWxpdGU+cm91dGVyPC9zcGFuPjwvYT4uDQogDQogICAgICAtIEluIHRoZSBDdXIgSG9w IExpbWl0IGZpZWxkOiB0aGUgY3VycmVudCB2YWx1ZSBvZiBDdXJIb3BMaW1pdC4NCiANCiAg ICAgIC0gSW4gdGhlIFJlYWNoYWJsZSBUaW1lIGZpZWxkOiBub3QgdXNlZCwgc2V0IHRvIHpl cm8uDQogDQogICAgICAtIEluIHRoZSBSZXRyYW5zIFRpbWVyIGZpZWxkOiBub3QgdXNlZCwg c2V0IHRvIHplcm8uDQogDQogICAgICAtIEluIHRoZSBvcHRpb25zOg0KIA0KICAgICAgICAg LSA2TG9XUEFOIFN1bW1hcnkgT3B0aW9uOiB0byBpbmRpY2F0ZSBpZiB0aGUgaW5mb3JtYXRp b24NCiAgICAgICAgIGNvbnRhaW5lZCBpbiB0aGUgUm91dGVyIEFkdmVydGlzZW1lbnQgaXMg dmFsaWQgYW5kLCBpZiBzbywgdGhlDQogICAgICAgICBmcmVzaG5lc3Mgb2YgdGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGUgUm91dGVyDQogICAgICAgICBBZHZlcnRpc2VtZW50 IG1lc3NhZ2UuICBUaGUgb3B0aW9uIGZpZWxkcyBhcmUgc2V0IGFzIGZvbGxvd3M6DQogDQog ICAgICAgICAgICAtIEluIHRoZSAidmFsaWQiIGZsYWc6IHRoZSBjdXJyZW50IHZhbHVlIG9m DQogICAgICAgICAgICBBZHZJbmZvcm1hdGlvblZhbGlkLg0KIA0KICAgICAgICAgICAgLSBJ biB0aGUgU2VxdWVuY2UgTnVtYmVyIGZpZWxkOiB0aGUgY3VycmVudCB2YWx1ZSBvZg0KICAg ICAgICAgICAgQWR2SW5mb3JtYXRpb25TZXF1ZW5jZS4NCiANCiAgICAgICAgICAgIC0gVGhl IEVSIE1ldHJpYyBmaWVsZCBpcyB1c2VkIGJ5IGEgcm91dGluZyBhbGdvcml0aG0gdG8NCiAg ICAgICAgICAgIGluZGljYXRlIHRoZSBjb3N0IG9mIHJlYWNoaW5nIGFuIDxzcGFuIGNsYXNz PWhpbGl0ZT5FZGdlIFJvdXRlcjwvc3Bhbj4gdGhyb3VnaCB0aGlzDQogICAgICAgICAgICBy b3V0ZXIuDQogDQogDQogDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5LCBl dCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAgICAg W1BhZ2UgMzJdPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5hbWU9 InBhZ2UtMzMiIGlkPSJwYWdlLTMzIiBocmVmPSIjcGFnZS0zMyIgY2xhc3M9ImludmlzaWJs ZSI+IDwvYT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2 TG9XUEFOIE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFu PiANCiANCiANCiAgICAgICAgIC0gNkxvV1BBTiBJbmZvcm1hdGlvbiBvcHRpb25zOiBvbmUg NkxvV1BBTiBJbmZvcm1hdGlvbiBvcHRpb24NCiAgICAgICAgIGZvciBlYWNoIHByZWZpeCBs aXN0ZWQgaW4gQWR2UHJlZml4TGlzdCB3aXRoIHRoZSBvcHRpb24gZmllbGRzDQogICAgICAg ICBzZXQgZnJvbSB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIEFkdlByZWZ4TGlzdCBlbnRyeSBh cyBmb2xsb3dzOg0KIA0KICAgICAgICAgICAgLSBJbiB0aGUgIm9uLWxpbmsiIGZsYWc6IHRo ZSBlbnRyeSdzIEFkdk9uTGlua0ZsYWcuDQogDQogICAgICAgICAgICAtIEluIHRoZSAiQXV0 b25vbW91cyBhZGRyZXNzIGNvbmZpZ3VyYXRpb24iIGZsYWc6IHRoZQ0KICAgICAgICAgICAg ZW50cnkncyBBZHZBdXRvbm9tb3VzRmxhZy4NCiANCiAgICAgICAgICAgIC0gSW4gdGhlIFZh bGlkIExpZmV0aW1lIGZpZWxkOiB0aGUgZW50cnkncyBBZHZWYWxpZExpZmV0aW1lLg0KIA0K PHNwYW4gY2xhc3M9ImgzIj48YSBuYW1lPSJzZWN0aW9uLTcuNCI+Ny40PC9hPi4gIFNlbmRp bmcgVW5zb2xpY2l0ZWQgUm91dGVyIEFkdmVydGlzZW1lbnRzPC9zcGFuPiANCiANCiAgIEFz IHNwZWNpZmllZCBpbiA8YSBocmVmPSIuL3JmYzQ4NjEjc2VjdGlvbi02LjIuNCI+U2VjdGlv biZuYnNwOzYuMi40IG9mIFtSRkM0ODYxXTwvYT4uDQogDQo8c3BhbiBjbGFzcz0iaDMiPjxh IG5hbWU9InNlY3Rpb24tNy41Ij43LjU8L2E+LiAgQ2Vhc2luZyBUbyBCZSBhbiBBZHZlcnRp c2luZyBJbnRlcmZhY2U8L3NwYW4+IA0KIA0KICAgQXMgc3BlY2lmaWVkIGluIDxhIGhyZWY9 Ii4vcmZjNDg2MSNzZWN0aW9uLTYuMi41Ij5TZWN0aW9uJm5ic3A7Ni4yLjUgb2YgW1JGQzQ4 NjFdPC9hPi4NCiANCjxzcGFuIGNsYXNzPSJoMyI+PGEgbmFtZT0ic2VjdGlvbi03LjYiPjcu NjwvYT4uICBQcm9jZXNzaW5nIFJvdXRlciBTb2xpY2l0YXRpb25zPC9zcGFuPiANCiANCiAg IEFzIHNwZWNpZmllZCBpbiA8YSBocmVmPSIuL3JmYzQ4NjEjc2VjdGlvbi02LjIuNiI+U2Vj dGlvbiZuYnNwOzYuMi42IG9mIFtSRkM0ODYxXTwvYT4uDQogDQo8c3BhbiBjbGFzcz0iaDMi PjxhIG5hbWU9InNlY3Rpb24tNy43Ij43Ljc8L2E+LiAgQmluZGluZyBUYWJsZTwvc3Bhbj4g DQogDQogICBSb3V0ZXJzIG1haW50YWluIGFuIHNldCBvZiBpbmZvcm1hdGlvbiBhYm91dCBu b2RlcyB0aGF0IGFyZSBjdXJyZW50bHkNCiAgIHJlZ2lzdGVyZWQgdGhyb3VnaCBpdCBjYWxs ZWQgdGhlIGJpbmRpbmcgdGFibGUuDQogDQogICBUaGUgYmluZGluZyB0YWJsZSBjb250YWlu cyBhbiBlbnRyeSB3aXRoIGluZm9ybWF0aW9uIHN1Y2ggYXMgdGhlDQogICByZWdpc3RlcmVk IG5vZGUncyBPSUksIGxpbmstbG9jYWwgSVB2NiBhZGRyZXNzIGFuZCB0aGUgYmluZGluZw0K ICAgbGlmZXRpbWUgZnJvbSB0aGUgbGFzdCBOUi4gIElmIGFkZHJlc3MgcmVzb2x1dGlvbiBp cyByZXF1aXJlZCwgdGhlDQogICB0YWJsZSB3aWxsIGFsc28gaW5jbHVkZSBjb3JyZXNwb25k aW5nIGxpbmstbGF5ZXIgYWRkcmVzcyBpbmZvcm1hdGlvbi4NCiANCiANCjxzcGFuIGNsYXNz PSJoMiI+PGEgbmFtZT0ic2VjdGlvbi04Ij44PC9hPi4gIEFkLWhvYyBMb1dQQU48L3NwYW4+ IA0KIA0KICAgTG9XUEFOIG5ldHdvcmtzIGJ5IG5hdHVyZSBtYXkgb2Z0ZW4gd29yayBpbiBh biBhZC1ob2MgZmFzaGlvbiwNCiAgIHdpdGhvdXQgYW4gaW5mcmFzdHJ1Y3R1cmUgb3IgY29u bmVjdGl2aXR5IHRvIHRoZSBnbG9iYWwgSW50ZXJuZXQuDQogICA2TG9XUEFOLU5EIG1heSBz dGlsbCBiZSBhcHBsaWVkIGluIHN1Y2ggbmV0d29ya3MuDQogDQogICA8YSBjbGFzcz1jb21t ZW50IGhyZWY9IiMiIHRpdGxlPSJDbGFyaWZpZWQiPkEgPHNwYW4gY2xhc3M9aGlsaXRlPnNw ZWNpZmljIHJvdXRlcjwvc3Bhbj4gaW4gdGhlIEFkLWhvYyBMb1dQQU4gaXMgPHNwYW4gY2xh c3M9aGlsaXRlPm5vbWluYXRlZCBhcyBFZGdlIFJvdXRlcg0KICAgYW5kPC9zcGFuPjwvYT4g Y29uZmlndXJlZCB0byBpbXBsZW1lbnQgYmFzaWMgRWRnZSBSb3V0ZXIgZnVuY3Rpb25hbGl0 eQ0KICAgKGluaXRpYXRpbmcgUkEgZGlzc2VtaW5hdGlvbikgYW5kIGdlbmVyYXRlcyBhIHBy ZWZpeCBiYXNlZCBvbiBVbmlxdWUNCiAgIG9uLWxpbmsgSVB2NiBVbmljYXN0IEFkZHJlc3Nl cyAoVUxBcykgYXMgZGVmaW5lZCBpbiBbPGEgaHJlZj0iLi9yZmM0MTkzIiB0aXRsZT0nIlVu aXF1ZSBMb2NhbCBJUHY2IFVuaWNhc3QgQWRkcmVzc2VzIic+UkZDNDE5MzwvYT5dLiAgQQ0K ICAgVUxBIGlzIG1hZGUgdXAgb2YgdGhlIHByZWZpeCBmYzAwOjovNywgYSBnbG9iYWwgSUQg YW5kIGEgc3VibmV0IElELg0KICAgVGhlIGdsb2JhbCBJRCBpcyByYW5kb21seSBnZW5lcmF0 ZWQsIGFuZCB0aGUgc3VibmV0IElEIGlzIG5vdCB1c2VkLg0KICAgVGhlIEVkZ2UgUm91dGVy IGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgZ2VuZXJhdGlvbiBvZiB0aGUgVUxBIHByZWZpeCAN CiAgIHRvIGJlIGFkdmVydGlzZWQgdG8gdGhlIExvV1BBTiBhbmQgdXNlZCBieSBhbGwgbm9k ZXMuICBVTEEgZ2VuZXJhdGlvbg0KICAgbWF5IHVzZSB0aGUgYWxnb3JpdGhtIHN1Z2dlc3Rl ZCBTZWN0aW9uDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5LCBldCBhbC4g ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2Ug MzNdPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5hbWU9InBhZ2Ut MzQiIGlkPSJwYWdlLTM0IiBocmVmPSIjcGFnZS0zNCIgY2xhc3M9ImludmlzaWJsZSI+IDwv YT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2TG9XUEFO IE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFuPiANCiAN CiANCiAgIDMuMi4yIG9mIFs8YSBocmVmPSIuL3JmYzQxOTMiIHRpdGxlPSciVW5pcXVlIExv Y2FsIElQdjYgVW5pY2FzdCBBZGRyZXNzZXMiJz5SRkM0MTkzPC9hPl0gb3Igc29tZXRoaW5n IGFwcHJvcHJpYXRlIHRvIHRoZSBFZGdlIFJvdXRlcidzDQogICBjYXBhYmlsaXRpZXMuICBU aGVyZSBTSE9VTEQgYmUgb25seSBvbmUgRWRnZSBSb3V0ZXIgaW4gYW4gQWQtaG9jDQogICBM b1dQQU4gKGp1c3QgYXMgaW4gYSBTaW1wbGUgTG9XUEFOKSB0byBrZWVwIHByZWZpeCBjb25z aXN0ZW5jeS4NCiANCiAgIEluIHRoZSBjYXNlIHRoYXQgYW4gRWRnZSBSb3V0ZXIgb24gYSBT aW1wbGUgTG9XUEFOIGRvZXMgbm90IGhhdmUgYQ0KICAgcHJlZml4IGF2YWlsYWJsZSBmcm9t IGl0cyBJUHY2IGFkZHJlc3MsIGl0IFNIT1VMRCBhZHZlcnRpc2UgYSBVTEENCiAgIHByZWZp eCBpbiBhIHNpbWlsYXIgbWFubmVyLg0KIA0KIA0KPHNwYW4gY2xhc3M9ImgyIj48YSBuYW1l PSJzZWN0aW9uLTkiPjk8L2E+LiAgUHJvdG9jb2wgQ29uc3RhbnRzPC9zcGFuPiANCiANCiAg IFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBwcm90b2NvbCBjb25zdGFudHMgdXNlZCBpbiB0 aGlzIGRvY3VtZW50DQogICBiYXNlZCBvbiBhIHN1YnNldCBvZiBbPGEgaHJlZj0iLi9yZmM0 ODYxIiB0aXRsZT0nIk5laWdoYm9yIERpc2NvdmVyeSBmb3IgSVAgdmVyc2lvbiA2IChJUHY2 KSInPlJGQzQ4NjE8L2E+XSBjb25zdGFudHMuICgqKSBpbmRpY2F0ZXMgY29uc3RhbnRzDQog ICBtb2RpZmllZCBmcm9tIFs8YSBocmVmPSIuL3JmYzQ4NjEiIHRpdGxlPSciTmVpZ2hib3Ig RGlzY292ZXJ5IGZvciBJUCB2ZXJzaW9uIDYgKElQdjYpIic+UkZDNDg2MTwvYT5dIGFuZCAo KykgaW5kaWNhdGVzIG5ldyBjb25zdGFudHMuDQogDQogICBBZGRpdGlvbmFsIHByb3RvY29s IGNvbnN0YW50cyBhcmUgZGVmaW5lZCBpbiBTZWN0aW9uIDxhIGhyZWY9IiNzZWN0aW9uLTQi PlNlY3Rpb24gNDwvYT4uDQogDQogICBFZGdlIFJvdXRlciBDb25zdGFudHM6DQogDQogICBN SU5fQ09OVEVYVF9DSEFOR0VfREVMQVkrICAgICAgICAgICAgICAgNjAgc2Vjb25kcw0KIA0K ICAgUm91dGVyIENvbnN0YW50czoNCiANCiAgIE1BWF9JTklUSUFMX1JUUl9BRFZFUlRfSU5U RVJWQUwqICAgICAgICA2MCBzZWNvbmRzDQogDQogICBNQVhfSU5JVElBTF9SVFJfQURWRVJU SVNFTUVOVFMgICAgICAgICAgMyB0cmFuc21pc3Npb25zDQogDQogICBNQVhfRklOQUxfUlRS X0FEVkVSVElTRU1FTlRTICAgICAgICAgICAgMyB0cmFuc21pc3Npb25zDQogDQogICBNSU5f REVMQVlfQkVUV0VFTl9SQVMqICAgICAgICAgICAgICAgICAgMTAgc2Vjb25kcw0KIA0KICAg TUFYX1JBX0RFTEFZX1RJTUUqICAgICAgICAgICAgICAgICAgICAgIDIgc2Vjb25kcw0KIA0K ICAgSG9zdCBDb25zdGFudHM6DQogDQogICBNQVhfUlRSX1NPTElDSVRBVElPTl9ERUxBWSog ICAgICAgICAgICAgMiBzZWNvbmQNCiANCiAgIFJUUl9TT0xJQ0lUQVRJT05fSU5URVJWQUwq ICAgICAgICAgICAgICAxMCBzZWNvbmRzDQogDQogICBNQVhfUlRSX1NPTElDSVRBVElPTlMg ICAgICAgICAgICAgICAgICAgMyB0cmFuc21pc3Npb25zDQogDQogICBOb2RlIENvbnN0YW50 czoNCiANCiAgIE1BWF9OUl9SRVRSSUVTKyAgICAgICAgICAgICAgICAgICAgICAgICAzIHRy YW5zbWlzc2lvbnMNCiANCiANCiANCiANCiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5Ij5T aGVsYnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAg ICAgICAgICBbUGFnZSAzNF08L3NwYW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+ PGEgbmFtZT0icGFnZS0zNSIgaWQ9InBhZ2UtMzUiIGhyZWY9IiNwYWdlLTM1IiBjbGFzcz0i aW52aXNpYmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAg ICAgICAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5IDIw MTA8L3NwYW4+IA0KIA0KIA0KICAgTUlOX05SX1RJTUVPVVQrICAgICAgICAgICAgICAgICAg ICAgICAgIDUgc2Vjb25kcw0KIA0KIA0KPHNwYW4gY2xhc3M9ImgyIj48YSBuYW1lPSJzZWN0 aW9uLTEwIj4xMDwvYT4uICBVc2Ugb2YgNkxvV1BBTi1ORCB1bmRlciA8YSBocmVmPSIuL3Jm YzQ4NjEiPlJGQzQ4NjE8L2E+LW9ubHkgc3RhY2tzPC9zcGFuPiANCiANCiAgIFNvbWUgSVB2 NiBzdGFja3MgKGUuZy4gb24gUENzKSBhbmQgdG9vbHMgKGUuZy4gcmFkdmQpIGhhcmQtd2ly ZSB0aGUNCiAgIG1lY2hhbmlzbXMgb2YgPGEgaHJlZj0iLi9yZmM0ODYxIj5SRkM0ODYxPC9h PiBmb3IgYWxsIGxpbmtzLiAgVGhpcyBzZWN0aW9uIGV4cGxhaW5zIHRoZQ0KICAgYWRhcHRh dGlvbiBuZWVkZWQgaW4gb3JkZXIgdG8gdXNlIGEgNkxvV1BBTiBpbnRlcmZhY2UgdW5kZXIg c3VjaCBhbg0KICAgPGEgaHJlZj0iLi9yZmM0ODYxIj5SRkM0ODYxPC9hPi1vbmx5IGltcGxl bWVudGF0aW9uLg0KIA0KICAgVGhlcmUgYXJlIHNldmVyYWwgd2F5cyB0byBpbXBsZW1lbnQg NkxvV1BBTi1ORCBpbiBjb21iaW5hdGlvbiB3aXRoIGFuDQogICBJUHY2IHN0YWNrOg0KIA0K ICAgbyAgNkxvV1BBTi1ORCBpcyBpbnRlZ3JhdGVkIHdpdGggdGhlIElQdjYgc3RhY2sgYW5k IGl0cyB0b29scy4gIFRoaXMNCiAgICAgIGlzIGNvbW1vbiBmb3IgTG9XUEFOIG5vZGVzLg0K IA0KICAgbyAgNkxvV1BBTi1ORCBpcyBpbXBsZW1lbnRlZCBhcyBwYXJ0IG9mIHRoZSBpbnRl cmZhY2UsIGNvbmZpZ3VyYXRpb24NCiAgICAgIGlzIHVzZWQgdG8gdHVybiBvZmYgPGEgaHJl Zj0iLi9yZmM0ODYxIj5SRkM0ODYxPC9hPiBtZWNoYW5pc21zIGluIHRoZSBJUHY2IHN0YWNr LiAgRm9yDQogICAgICBleGFtcGxlLCBQcm94eS1ORCBpbnRlcmZhY2VzIGNhbiBiZSB1c2Vk IGluIExpbnV4IHRvIGRpc2FibGUgbW9zdA0KICAgICAgYnVpbHQtaW4gTkQgbWVjaGFuaXNt cy4gIFRoaXMgbW9kZWwgaXMgY29tbW9uIGZvciBFZGdlIFJvdXRlcnMNCiAgICAgIHJ1bm5p bmcgb24gYSBzdGFuZGFyZCBvcGVyYXRpbmcgc3lzdGVtLg0KIA0KICAgbyAgNkxvV1BBTi1O RCBpcyBpbXBsZW1lbnRlZCBhcyBwYXJ0IG9mIHRoZSBpbnRlcmZhY2UsIGFuZCBpdA0KICAg ICAgcGVyZm9ybXMgYWRhcHRhdGlvbiBmb3IgPGEgaHJlZj0iLi9yZmM0ODYxIj5SRkM0ODYx PC9hPiBtZWNoYW5pc21zIHJ1bm5pbmcgb24gdGhlIElQdjYNCiAgICAgIHN0YWNrLiAgVGhl IGJpbmRpbmcgdGFibGUgaXMgdXNlZCB0byBhbnN3ZXIgPGEgaHJlZj0iLi9yZmM0ODYxIj5S RkM0ODYxPC9hPiBtZXNzYWdlcywgYW5kDQogICAgICBhcHByb3ByaWF0ZSBvcHRpb25zIGFk ZGVkIHRvIFJBIG1lc3NhZ2VzLg0KIA0KICAgQ2xhc3NpYyBSUy9SQSBtZXNzYWdlcyBjYW4g YmUgdXNlZCB3aXRoIGEgTG9XUEFOLCB0aHVzIGFsbG93aW5nIGUuZy4NCiAgIGZvciBhbiB1 bm1vZGlmaWVkIHJhZHZkICh3aXRoIGFwcHJvcHJpYXRlIGNvbmZpZ3VyYXRpb24pIHRvIGJl IHJ1biBvbg0KICAgYW4gRWRnZSBSb3V0ZXIgYXMgbG9uZyBhcyBjb250ZXh0IGRpc3NlbWlu YXRpb24gaXMgbm90IG5lZWRlZC4gIEl0IGlzDQogICBob3dldmVyIHJlY29tbWVuZGVkIHRo YXQgNklPIGFuZCA2U08gb3B0aW9ucyBiZSB1c2VkIGlmIHBvc3NpYmxlLA0KICAgd2hpY2gg aXMgZWFzaWx5IGFjaGlldmVkIGJ5IHBhdGNoaW5nIGV4aXN0aW5nIFJBIHRvb2xzIG9yIHBl cmZvcm1pbmcNCiAgIGFkYXB0YXRpb24uDQogDQogDQo8c3BhbiBjbGFzcz0iaDIiPjxhIG5h bWU9InNlY3Rpb24tMTEiPjExPC9hPi4gIE1lc3NhZ2UgRXhhbXBsZXM8L3NwYW4+IA0KIA0K ICAgVGhpcyBzZWN0aW9uIHByb3ZpZGVzIGJhc2ljIGV4YW1wbGVzIG9mIG1lc3NhZ2VzIGFu ZCBvcHRpb25zIGZyb20NCiAgIHRoaXMgZG9jdW1lbnQuDQogDQo8c3BhbiBjbGFzcz0iaDMi PjxhIG5hbWU9InNlY3Rpb24tMTEuMSI+MTEuMTwvYT4uICBOUi9OQyBtZXNzYWdlIGV4Y2hh bmdlPC9zcGFuPiANCiANCiAgIFdoZW4gYSBob3N0IDxzcGFuIGNsYXNzPWhpbGl0ZT53YW50 czwvc3Bhbj4gdG8gcmVnaXN0ZXIgdG8gYSByb3V0ZXIsIGEgc2ltcGxlIE5SL05DIHJlcXVl c3QNCiAgIG1lc3NhZ2UgZXhjaGFuZ2Ugb2NjdXJzLiAgSW4gdGhpcyBleGFtcGxlPHNwYW4g Y2xhc3M9aGlsaXRlPiw8L3NwYW4+IGEgaG9zdCB3YW50cyB0byByZWdpc3Rlcg0KICAgaXRz IGFkZHJlc3MgZ2VuZXJhdGVkIHdpdGggU3RhdGVsZXNzIEFkZHJlc3MgQXV0b2NvbmZpZ3Vy YXRpb24gPGEgY2xhc3M9Y29tbWVudCBocmVmPSIjIiB0aXRsZT0iSXMgdGhpcyB0aGUgb2Zm aWNpYWwgYWJicmV2aWF0aW9uPyBTZWVtcyB0byBjb25mbGljdCB3aXRoIFNMTEFPIj4oU0FB KTwvYT4sDQogICBhbmQgaW4gYWRkaXRpb24gcmVxdWVzdHMgYSBnZW5lcmF0ZWQgc2hvcnQg YWRkcmVzcy4NCiANCiAgIEZpcnN0IHRoZSBIb3N0IHNlbmRzIGFuIE5SIG1lc3NhZ2UgdG8g dGhlIGxpbmstbG9jYWwgYWRkcmVzcyBvZiB0aGUNCiANCiANCiANCjxzcGFuIGNsYXNzPSJn cmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAg ICAgICAgICAgICAgICBbUGFnZSAzNV08L3NwYW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3 cGFnZSc+PGEgbmFtZT0icGFnZS0zNiIgaWQ9InBhZ2UtMzYiIGhyZWY9IiNwYWdlLTM2IiBj bGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1E cmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1 YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAgcm91dGVyLiAgSW4gdGhpcyBleGFtcGxlIHRo ZSBob3N0IGluY2x1ZGVzIGEgNjAwIHNlY29uZCBiaW5kaW5nDQogICBsaWZldGltZSBhbmQg aXRzIG1vZGlmaWVkIEVVSS02NCBhcyB0aGUgT3duZXIgSW50ZXJmYWNlIElkZW50aWZpZXIu DQogICBUaGUgbWVzc2FnZSBoYXMgdHdvIEFkZHJlc3MgT3B0aW9ucy4gIFRoZSBob3N0IGhh cyBqdXN0IGJvb3RlZCwNCiAgIHRoZXJlZm9yZSB0aGUgVElEIHN0YXJ0cyB3aXRoIDAuICBU aGlzIGV4YW1wbGUgYXNzdW1lcyB0aGF0IHRoZQ0KICAgTG9XUEFOIHByZWZpeCBoYXMgYmVl biBhc3NpZ25lZCBDSUQgMC4NCiANCiAgIElQdjYgU291cmNlOiBVbnNwZWNpZmllZCBhZGRy ZXNzDQogICBJUHY2IERlc3RpbmF0aW9uOiBSb3V0ZXIncyBsaW5rLWxvY2FsIGFkZHJlc3MN CiANCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAg ICAgICAgICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAg VHlwZSA9IFRCRCAgIHwgICAwICAgfCAgIDAgICB8ICAgICAgICAgICBDaGVja3N1bSAgICAg ICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgVElEID0gMCAgICAgfDF8MHwgICAg ICAgICAgICAgICAgIFJlc2VydmVkICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgIHwgICAgQmluZGluZyBMaWZldGltZSA9IDYwICAgICAgfCAgICAgICAgICAgIFJl c2VydmVkICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICBPd25lciBOb25jZSAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKyAgICAgICAgICAgICAgICAgIE93 bmVyIEludGVyZmFjZSBJZGVudGlmaWVyID0gICAgICAgICAgICAgICAgICsNCiAgIHwgICAg ICAgICAgICAgICAgTW9kaWZpZWQgRVVJLTY0IG9mIHRoZSBpbnRlcmZhY2UgICAgICAgICAg ICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KIA0KIA0KICAgICAgICAgICAgICAgICAgICAgICAg RmlndXJlIDk6IEJhc2ljIE5SIHJlcXVlc3QuDQogDQogDQogICAgMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgIFR5cGUgPSBUQkQgICB8ICAgTGVuZ3Ro ID0gMSAgfCAgU3RhdHVzID0gMCAgIHwgUz0xIHwgIFA9MCAgICB8DQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgfDB8MHwwfDF8ICAgICAgUmVzZXJ2ZWQgICAgICAgICB8ICAgICAgICAgUGFkZGlu ZyAgPSAwICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogDQogDQogICAgICAgICAgIEZp Z3VyZSAxMDogTlIgQWRkcmVzcyBPcHRpb24gMSwgZm9yIHRoZSBTQUEgYWRkcmVzcy4NCiAN CiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5Ij5T aGVsYnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAg ICAgICAgICBbUGFnZSAzNl08L3NwYW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+ PGEgbmFtZT0icGFnZS0zNyIgaWQ9InBhZ2UtMzciIGhyZWY9IiNwYWdlLTM3IiBjbGFzcz0i aW52aXNpYmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAg ICAgICAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5IDIw MTA8L3NwYW4+IA0KIA0KIA0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICB8ICBUeXBlID0gVEJEICAgfCAgIExlbmd0aCA9IDEgIHwgIFN0YXR1cyA9 IDAgICB8IFM9MiB8ICBQPTAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwwfDF8MHwwfCAg ICAgIFJlc2VydmVkICAgICAgICAgfCAgICAgICAgIFBhZGRpbmcgPSAwICAgICAgICAgICB8 DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KIA0KIA0KICAgICAgICBGaWd1cmUgMTE6IE5SIEFkZHJlc3Mg T3B0aW9uIDIsIGZvciB0aGUgcmVxdWVzdGVkIGFkZHJlc3MuDQogDQogDQogICBJUHY2IFNv dXJjZTogUm91dGVyJ3MgbGluay1sb2NhbCBhZGRyZXNzDQogICBJUHY2IERlc3RpbmF0aW9u OiBIb3N0J3MgbGluay1sb2NhbCBhZGRyZXNzDQogDQogICBUaGUgYmFzZSBOQyBtZXNzYWdl IGlzIGlkZW50aWNhbCB0byB0aGUgYmFzZSBOUiBtZXNzYWdlIGFib3ZlLg0KIA0KIA0KICAg ICAgICAgICAgICAgICAgIDxhIGNsYXNzPWNvbW1lbnQgaHJlZj0iIyIgdGl0bGU9IklzIHRo ZXJlIGFueSBuZWVkIGZvciBGaWd1cmUgMTIgdGV4dD8iPkZpZ3VyZSAxMjogQ29ycmVzcG9u ZGluZyBOQyBtZXNzYWdlPC9hPi4NCiANCiANCiANCiAgIEFkZHJlc3MgT3B0aW9uIDEgaXMg aWRlbnRpY2FsIHRvIEFkZHJlc3MgT3B0aW9uIDEgaW4gdGhlIE5SLg0KIA0KIA0KICAgICAg ICAgICA8YSBjbGFzcz1jb21tZW50IGhyZWY9IiMiIHRpdGxlPSJJcyB0aGVyZSBhbnkgbmVl ZCBmb3IgRmlndXJlIDEzIHRleHQ/Ij5GaWd1cmUgMTM6IE5DIEFkZHJlc3MgT3B0aW9uIDEs IGZvciB0aGUgU0FBIGFkZHJlc3MuPC9hPg0KIA0KIA0KICAgQWRkcmVzcyBPcHRpb24gMiBu b3cgaW5jbHVkZXMgdGhlIGdlbmVyYXRlZCBhZGRyZXNzLg0KIA0KICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICBUeXBlID0gVEJEICAgfCAgIExl bmd0aCA9IDEgIHwgIFN0YXR1cyA9IDAgICB8IFM9MiB8ICBQPTAgICAgfA0KICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgIHwwfDF8MHwwfCAgICAgIFJlc2VydmVkICAgICAgICAgfCAgIEdlbmVyYXRl ZCAxNi1iaXQgYWRkcmVzcyAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KIA0KIA0KICAgICAgICBG aWd1cmUgMTQ6IE5DIEFkZHJlc3MgT3B0aW9uIDIsIGZvciB0aGUgcmVxdWVzdGVkIGFkZHJl c3MuDQogDQo8c3BhbiBjbGFzcz0iaDMiPjxhIG5hbWU9InNlY3Rpb24tMTEuMiI+MTEuMjwv YT4uICBSb3V0ZXIgYWR2ZXJ0aXNlbWVudDwvc3Bhbj4gDQogDQogICBSb3V0ZXJzIGFuZCBF ZGdlIFJvdXRlcnMgaW4gTG9XUEFOIG5ldHdvcmtzIHBlcmlvZGljYWxseSBzZW5kIFJBDQog ICBtZXNzYWdlcy4gIDxzcGFuIGNsYXNzPWhpbGl0ZT5UaGU8L3NwYW4+IGZvbGxvd2luZyBl eGFtcGxlIGlzIG9mIGFuIFJBIG1lc3NhZ2Ugc2VudCBieSBhDQogICByb3V0ZXIuICA8c3Bh biBjbGFzcz1oaWxpdGU+SWYgdGhlIG1lc3NhZ2UgaXMgc2VudCBieSBhbiBFZGdlIFJvdXRl ciwgdGhlIG9ubHkgZGlmZmVyZW5jZQ0KICAgaXMgdGhhdCB0aGUgUHJlZmVyZW5jZSBmbGFn IGlzIHNldCB0byAxMDwvc3Bhbj4uDQogDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+ U2hlbGJ5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAg ICAgICAgICAgW1BhZ2UgMzddPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2Un PjxhIG5hbWU9InBhZ2UtMzgiIGlkPSJwYWdlLTM4IiBocmVmPSIjcGFnZS0zOCIgY2xhc3M9 ImludmlzaWJsZSI+IDwvYT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQg ICAgICAgICA2TG9XUEFOIE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAy MDEwPC9zcGFuPiANCiANCiANCiAgIEluIHRoZSBleGFtcGxlIHRoZSBQcmVmZXJlbmNlIGZs YWcgaXMgMDEgKHJvdXRlciksIGFuZCBhIDEyMDBzIFJvdXRlcg0KICAgTGlmZXRpbWUgaXMg YWR2ZXJ0aXNlZC4gIEEgNkxvV1BBTiBQcmVmaXggSW5mb3JtYXRpb24gT3B0aW9uIGlzDQog ICBpbmNsdWRlZC4NCiANCiANCiAgICAgSVB2NiBTb3VyY2U6IFJvdXRlcidzIGxpbmstbG9j YWwgYWRkcmVzcw0KICAgICBJUHY2IERlc3RpbmF0aW9uOiBBbGwtbm9kZXMgbXVsdGljYXN0 IGFkZHJlc3MNCiANCiAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg ICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8ICBUeXBlID0gMTM0ICAgfCAgIENvZGUgPSAwICAgIHwgICAgICAg ICAgQ2hlY2tzdW0gICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8IEN1 ciBIb3AgTGltaXQgfDB8MHwwfDAgMHxSc3J2ZHwgICAgUm91dGVyIExpZmV0aW1lID0gMTIw MCAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICBSZWFjaGFibGUgVGltZSA9IDAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICBSZXRyYW5zIFRpbWVyID0g MCAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KIA0KIA0KICAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxNTogUkEgbWVzc2FnZSBleGFtcGxlLg0KIA0K IA0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAg ICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICBU eXBlID0gVEJEICAgfCAgTGVuZ3RoID0gMiAgIHwgICAgIFBMID0gNjQgICB8MHwxfDF8MXwg Q0lEPTAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICBWYWxp ZCBMaWZldGltZSA9IDMwMDAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC4NCiAgIC4gICAgICAgICAgICAgICAgICAgIFByZWZpeCA9IDIw MDE6REI4OjovNjQgICAgICAgICAgICAgICAgICAgICAuDQogICAuICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiANCiAgICAgICAgICAgICAgRmlndXJlIDE2OiA2TG9XUEFOIEluZm9y bWF0aW9uIE9wdGlvbiBleGFtcGxlLg0KIA0KIA0KPHNwYW4gY2xhc3M9ImgyIj48YSBuYW1l PSJzZWN0aW9uLTEyIj4xMjwvYT4uICBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvc3Bhbj4g DQogDQogICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgb2YgSVB2NiBOZWlnaGJvciBE aXNjb3ZlcnkgWzxhIGhyZWY9Ii4vcmZjNDg2MSIgdGl0bGU9JyJOZWlnaGJvciBEaXNjb3Zl cnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiJz5SRkM0ODYxPC9hPl0NCiAgIGFwcGx5LiAg QWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBjYW4gYmUgZm91bmQgaW4gWzxhIGhyZWY9Ii4v cmZjMzc1NiIgdGl0bGU9JyJJUHY2IE5laWdoYm9yIERpc2NvdmVyeSAoTkQpIFRydXN0IE1v ZGVscyBhbmQgVGhyZWF0cyInPlJGQzM3NTY8L2E+XS4NCiANCiAgIFRoaXMgc3BlY2lmaWNh dGlvbiBleHBlY3RzIHRoYXQgdGhlIGxpbmsgbGF5ZXIgaXMgc3VmZmljaWVudGx5DQogICBw cm90ZWN0ZWQsIGVpdGhlciBieSBtZWFucyBvZiBwaHlzaWNhbCBvciBJUCBzZWN1cml0eSBm b3IgdGhlDQogICBiYWNrYm9uZSBsaW5rIG9yIE1BQyBzdWJsYXllciBjcnlwdG9ncmFwaHku ICBJbiBvdGhlciB3b3JkcywgbW9kZWwgMQ0KICAgZnJvbSBbPGEgaHJlZj0iLi9yZmMzNzU2 IiB0aXRsZT0nIklQdjYgTmVpZ2hib3IgRGlzY292ZXJ5IChORCkgVHJ1c3QgTW9kZWxzIGFu ZCBUaHJlYXRzIic+UkZDMzc1NjwvYT5dIGFwcGxpZXMuICBJbiBwYXJ0aWN1bGFyLCBpdCBp cyBleHBlY3RlZCB0aGF0IHRoZQ0KIA0KIA0KIA0KPHNwYW4gY2xhc3M9ImdyZXkiPlNoZWxi eSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA1LCAyMDEwICAgICAgICAgICAg ICAgIFtQYWdlIDM4XTwvc3Bhbj4gDQo8L3ByZT48cHJlIGNsYXNzPSduZXdwYWdlJz48YSBu YW1lPSJwYWdlLTM5IiBpZD0icGFnZS0zOSIgaHJlZj0iI3BhZ2UtMzkiIGNsYXNzPSJpbnZp c2libGUiPiA8L2E+IA0KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAgICAg ICAgNkxvV1BBTiBOZWlnaGJvciBEaXNjb3ZlcnkgICAgICAgICAgRmVicnVhcnkgMjAxMDwv c3Bhbj4gDQogDQogDQogICBMb1dQQU4gTUFDIHByb3ZpZGVzIHNlY3VyZSB1bmljYXN0IHRv L2Zyb20gUm91dGVycyBhbmQgc2VjdXJlDQogICBicm9hZGNhc3QgZnJvbSB0aGUgUm91dGVy cyBpbiBhIHdheSB0aGF0IHByZXZlbnRzIHRhbXBlcmluZyB3aXRoIG9yDQogICByZXBsYXlp bmcgdGhlIFJBIG1lc3NhZ2VzLiAgSG93ZXZlciwgYW55IGZ1dHVyZSA2TG9XUEFOIHNlY3Vy aXR5DQogICBwcm90b2NvbCB0aGF0IGFwcGxpZXMgdG8gTmVpZ2hib3IgRGlzY292ZXJ5IGZv ciA2TG9XUEFOIHByb3RvY29sLCBpcw0KICAgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1l bnQuDQogDQogICA8YSBjbGFzcz1jb21tZW50IGhyZWY9IiMiIHRpdGxlPSJJdCBpcyBub3Qg Y2xlYXIgaW4gdGhpcyBkb2N1bWVudCB0aGF0IEVVSS02NCBpcyBhbHdheXMgdXNlZCB0byBm b3JtIHRoZSBJSUQuIFRoZXJlIGlzIGEgbWVjaGFuaXNtIHRvIHVzZSB0aGUgMTYtYml0IGFk ZHJlc3MgYW5kIHBvc3NpYmx5IFBBTi1JRCBhcyB3ZWxsLiBUaGlzIHdvdWxkIGdvIHNvbWUg d2F5IHRvIHByb3RlY3QgdGhlIHByaXZhY3kgaXNzdWUuIj5UaGUgdXNlIG9mIEVVSS02NCBm b3IgZm9ybWluZyB0aGUgSW50ZXJmYWNlIElEPC9hPiBpbiB0aGUgbGluayBvbi1saW5rDQog ICBhZGRyZXNzIHByZXZlbnRzIHRoZSB1c2FnZSBvZiBTZWN1cmUgTkQgKFs8YSBocmVmPSIu L3JmYzM5NzEiIHRpdGxlPSciU0VjdXJlIE5laWdoYm9yIERpc2NvdmVyeSAoU0VORCkiJz5S RkMzOTcxPC9hPl0gYW5kIFs8YSBocmVmPSIuL3JmYzM5NzIiIHRpdGxlPSciQ3J5cHRvZ3Jh cGhpY2FsbHkgR2VuZXJhdGVkIEFkZHJlc3NlcyAoQ0dBKSInPlJGQzM5NzI8L2E+XSkgYW5k DQogICBhZGRyZXNzIHByaXZhY3kgdGVjaG5pcXVlcy4gIENvbnNpZGVyaW5nIHRoZSBlbnZp c2lvbmVkIGRlcGxveW1lbnRzDQogICBhbmQgdGhlIE1BQyBsYXllciBzZWN1cml0eSBhcHBs aWVkLCB0aGlzIGlzIG5vdCBjb25zaWRlcmVkIGFuIGlzc3VlDQogICBhdCB0aGlzIHRpbWUu DQogDQogDQo8c3BhbiBjbGFzcz0iaDIiPjxhIG5hbWU9InNlY3Rpb24tMTMiPjEzPC9hPi4g IElBTkEgQ29uc2lkZXJhdGlvbnM8L3NwYW4+IA0KIA0KICAgVGhpcyBkb2N1bWVudCByZXF1 aXJlcyB0d28gbmV3IElDTVB2NiBtZXNzYWdlIHR5cGVzOg0KIA0KICAgbyAgTm9kZSBSZWdp c3RyYXRpb24gKFRCRDEpDQogDQogICBvICBOb2RlIENvbmZpcm1hdGlvbiAoVEJEMikNCiAN CiAgIFRoZSBkb2N1bWVudCBhbHNvIHJlcXVpcmVzIGZvdXIgbmV3IE5EIG9wdGlvbiB0eXBl cyB1bmRlciB0aGUNCiAgIHN1YnJlZ2lzdHJ5ICJJUHY2IE5laWdoYm9yIERpc2NvdmVyeSBP cHRpb24gRm9ybWF0cyI6DQogDQogICBvICA2TG9XUEFOIEFkZHJlc3MgT3B0aW9uIChUQkQz KQ0KIA0KICAgbyAgNkxvV1BBTiBJbmZvcm1hdGlvbiBPcHRpb24gKFRCRDQpDQogDQogICBv ICA2TG9XUEFOIFN1bW1hcnkgT3B0aW9uIChUQkQ1KQ0KIA0KICAgbyAgT3duZXIgSW50ZXJm YWNlIElkZW50aWZpZXIgT3B0aW9uIChUQkQ2KQ0KIA0KICAgW1RPIEJFIFJFTU9WRUQ6IFRo aXMgcmVnaXN0cmF0aW9uIHNob3VsZCB0YWtlIHBsYWNlIGF0IHRoZSBmb2xsb3dpbmcNCiAg IGxvY2F0aW9uOiA8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEiPmh0dHA6Ly93d3cuaWFuYTwv YT4ub3JnL2Fzc2lnbm1lbnRzL2ljbXB2Ni1wYXJhbWV0ZXJzXQ0KIA0KIA0KPHNwYW4gY2xh c3M9ImgyIj48YSBuYW1lPSJzZWN0aW9uLTE0Ij4xNDwvYT4uICBBY2tub3dsZWRnbWVudHM8 L3NwYW4+IA0KIA0KICAgVGhlIGF1dGhvcnMgdGhhbmsgUmljaGFyZCBLZWxzZXksIEdlb2Zm IE11bGxpZ2FuLCBKdWxpZW4gQWJlaWxsZSwNCiAgIEFsZXhhbmRydSBQZXRyZXNjdSwgUGV0 ZXIgU2lrbG9zaSwgUGlldGVyIERlIE1pbCwgRnJlZCBCYWtlciwgQW50aG9ueQ0KICAgU2No b29mcywgUGhpbCBSb2JlcnRzIGFuZCBKb2FraW0gRXJpa3Nzb24gZm9yIHVzZWZ1bCBkaXNj dXNzaW9ucyBhbmQNCiAgIGNvbW1lbnRzIHRoYXQgaGF2ZSBoZWxwZWQgc2hhcGVkIGFuZCBp bXByb3ZlIHRoaXMgZG9jdW1lbnQuDQogDQogDQo8c3BhbiBjbGFzcz0iaDIiPjxhIG5hbWU9 InNlY3Rpb24tMTUiPjE1PC9hPi4gIENoYW5nZWxvZzwvc3Bhbj4gDQogDQogICBDaGFuZ2Vz IGZyb20gLTA3IHRvIC0wODoNCiANCiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5Ij5TaGVs YnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAgICAg ICAgICBbUGFnZSAzOV08L3NwYW4+IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+PGEg bmFtZT0icGFnZS00MCIgaWQ9InBhZ2UtNDAiIGhyZWY9IiNwYWdlLTQwIiBjbGFzcz0iaW52 aXNpYmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAg ICAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTA8 L3NwYW4+IA0KIA0KIA0KICAgICAgbyBSZW1vdmVkIEV4dGVuZGVkIExvV1BBTiBhbmQgV2hp dGVib2FyZCByZWxhdGVkIHNlY3Rpb25zLg0KIA0KICAgICAgbyBJbmNsdWRlZCByZWZlcmVu Y2UgdG8gdGhlIGF1dG9jb25mIGFkZHJlc3NpbmcgbW9kZWwuDQogDQogICAgICBvIEFkZGVk IE9wdGltaXN0aWMgRmxhZyB0byA2QU8uDQogDQogICAgICBvIEFkZGVkIGd1aWRlbGluZXMg b24gcm91dGVycyBwZXJmb3JtaW5nIERBRC4NCiANCiAgICAgIG8gUmVtb3ZlZCB0aGUgTlIv TkMgQWR2ZXJ0aXNpbmcgSW50ZXJ2YWwuDQogDQogICAgICBvIEFkZGVkIGFzc3VtcHRpb24g b2YgdW5pZm9ybSBJSUQgZm9ybWF0aW9uIGFuZCBEQUQgdGhyb3VnaG91dCBhDQogICAgICBM b1dQQU4uDQogDQogICBDaGFuZ2VzIGZyb20gLTA2IHRvIC0wNzoNCiANCiAgICAgIG8gVXBk YXRlZCBhZGRyZXNzaW5nIGFuZCBhZGRyZXNzIHJlc29sdXRpb24gKCM2MCkuDQogDQogICAg ICBvIENoYW5nZWQgdGhlIEFkZHJlc3MgT3B0aW9uIHRvIDZMb1dQQU4gQWRkcmVzcyBPcHRp b24sIGZpeGVkIFMNCiAgICAgIHZhbHVlcyAoIzYxKS4NCiANCiAgICAgIG8gQWRkZWQgc3Vw cG9ydCBmb3IgY2xhc3NpYyA8YSBocmVmPSIuL3JmYzQ4NjEiPlJGQzQ4NjE8L2E+IFJBIFBy ZWZpeCBJbmZvcm1hdGlvbiBtZXNzYWdlcw0KICAgICAgdG8gYmUgcHJvY2Vzc2VkICgjNjIp Lg0KIA0KICAgICAgbyBBZGRlZCBhIHNlY3Rpb24gb24gdXNpbmcgNkxvV1BBTi1ORCB1bmRl ciBhIGhhcmQtd2lyZWQgPGEgaHJlZj0iLi9yZmM0ODYxIj5SRkM0ODYxPC9hPiANCiAgICAg IHN0YWNrICgjNjMpLg0KIA0KICAgICAgbyBVcGRhdGVkIHRoZSBOUi9OQyBtZXNzYWdlIHdp dGggYSBuZXcgUm91dGVyIGZsYWcsIGNvbWJpbmVkIHRoZQ0KICAgICAgQ29kZSBhbmQgU3Rh dHVzIGZpZWxkcyBpbnRvIG9uZSBieXRlLCBhbmQgYWRkZWQgdGhlIGNhcGFiaWxpdHkgdG8N CiAgICAgIGNhcnJ5IDZJT3MgKCM2NCkuDQogDQogICAgICBvIE1hZGUgY28tZXhpc3RlbmNl IHdpdGggb3RoZXIgTkQgbWVjaGFuaXNtcyBjbGVhciAoIzU5KS4NCiANCiAgICAgIG8gQWRk ZWQgYSBuZXcgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiBzZWN0aW9uIHdpdGggYWxsIG1lY2hh bmlzbXMNCiAgICAgIHNwZWNpZmllZCB0aGVyZSAoIzU5KS4NCiANCiAgICAgIG8gUmVtb3Zl ZCBkZXBlbmRlbmNpZXMgYW5kIGNvbmZsaWN0cyB3aXRoIDxhIGhyZWY9Ii4vcmZjNDg2MSI+ UkZDNDg2MTwvYT4gd2hlcmV2ZXINCiAgICAgIHBvc3NpYmxlICgjNTkpLg0KIA0KICAgICAg byBTb21lIGVkaXRvcmlhbCBjbGVhbnVwLg0KIA0KICAgQ2hhbmdlcyBmcm9tIC0wNSB0byAt MDY6DQogDQogICAgICBvIEZpeGVkIHRoZSBQcmYgY29kZXMgKCM1MikuDQogDQogICAgICBv IENvcnJlY3RlZCB0aGUgT0lJTyBUSUQgZmllbGQgdG8gOC1iaXRzLiAgQ2hhbmdlZCB0aGUg Tm9uY2UvT0lJDQogICAgICBvcmRlciBpbiBib3RoIHRoZSBPSUlPIGFuZCB0aGUgTlIvTkMu ICgjNTMpDQogDQogDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5LCBldCBh bC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAgICAgW1Bh Z2UgNDBdPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5hbWU9InBh Z2UtNDEiIGlkPSJwYWdlLTQxIiBocmVmPSIjcGFnZS00MSIgY2xhc3M9ImludmlzaWJsZSI+ IDwvYT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2TG9X UEFOIE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFuPiAN CiANCiANCiAgICAgIG8gQ29ycmVjdGVkIGFuIGVycm9yIGluIFRhYmxlIDEgKCM1NCkuDQog DQogICAgICBvIEZpeGVkIGFzeW1tZXRyaWMgYW5kIGEgbWlzcGxhY2VkIHRyYW5zaWVudCBp biB0aGUgNkxvV1BBTg0KICAgICAgdGVybWlub2xvZ3kgc2VjdGlvbi4NCiANCiAgICAgIG8g QWRkZWQgVXBkYXRlcyA8YSBocmVmPSIuL3JmYzQ4NjEiPlJGQzQ4NjE8L2E+IHRvIGhlYWRl cg0KIA0KICAgQ2hhbmdlcyBmcm9tIC0wNCB0byAtMDU6DQogDQogICAgICBvIE1lYW5pbmcg b2YgdGhlIFJBJ3MgTS1iaXQgY2hhbmdlZCB0byBvcmlnaW5hbCBbPGEgaHJlZj0iLi9yZmM0 ODYxIiB0aXRsZT0nIk5laWdoYm9yIERpc2NvdmVyeSBmb3IgSVAgdmVyc2lvbiA2IChJUHY2 KSInPlJGQzQ4NjE8L2E+XSBtZWFuaW5nDQogICAgICAoIzQ2KS4NCiANCiAgICAgIG8gVGVy bXMgIm9uLWxpbmsiIGFuZCAib2ZmLWxpbmsiIHVzZWQgaW4gcGxhY2Ugb2YgIm9uLWxpbmsi IGFuZA0KICAgICAgIm9mZi1saW5rIi4NCiANCiAgICAgIG8gTmV4dC1ob3AgZGV0ZXJtaW5h dGlvbiB0ZXh0IHNpbXBsaWZpZWQgKCM0OSkuDQogDQogICAgICBvIE5laWdoYm9yIGNhY2hl IGFuZCBkZXN0aW5hdGlvbiBjYWNoZSByZW1vdmVkLg0KIA0KICAgICAgbyBJSUQgdG8gbGlu ay1sYXllciBhZGRyZXNzIHJlcXVpcmVtZW50IHJlbGF4ZWQuDQogDQogICAgICBvIE5SL05D IGNoYW5nZXMgdG8gZW5hYmxlIG9uLWxpbmsgcmVmcmVzaCB3aXRoIHJvdXRlcnMgKCM0OCku DQogDQogICAgICBvIE1vZGlmaWVkIDZMb1dQQU4gSW5mb3JtYXRpb24gT3B0aW9uICgjNDcp Lg0KIA0KICAgICAgbyBBZGRlZCBhIFByb3RvY29sIENvbnN0YW50cyBzZWN0aW9uICgjMjQp DQogDQogICAgICBvIEFkZGVkIHRoZSBOUiBwcm9jZXNzaW5nIHRhYmxlICgjNTEpDQogDQog ICAgICBvIENvbnNpZGVyZWQgdGhlIHVzZSBvZiBTZU5EIG9uIGJhY2tib25lIE5TL05BIG1l c3NhZ2VzICgjNTApDQogDQogICBDaGFuZ2VzIGZyb20gLTAzIHRvIC0wNDoNCiANCiAgICAg IG8gTW92ZWQgQWQtaG9jIExvV1BBTiBvcGVyYXRpb24gdG8gPGEgaHJlZj0iI3NlY3Rpb24t NyI+U2VjdGlvbiA3PC9hPiBhbmQgbWFkZSBVTEEgcHJlZml4DQogICAgICBnZW5lcmF0aW9u IGEgZmVhdHVyZXMgdXNlZnVsIGFsc28gaW4gU2ltcGxlIGFuZCBFeHRlbmRlZCBMb1dQQU5z Lg0KICAgICAgKCM0MSkNCiANCiAgICAgIG8gQWRkZWQgYSAzMi1iaXQgT3duZXIgTm9uY2Ug dG8gdGhlIE5SL05DIG1lc3NhZ2VzIGFuZCB0aGUNCiAgICAgIFdoaXRlYm9hcmQsIHJlbW92 ZWQgdGhlIFRJRCBoaXN0b3J5LiAoIzM5KQ0KIA0KICAgICAgbyBJbXByb3ZlZCB0aGUgZHVw bGljYXRlIE9JSSBkZXRlY3Rpb24gYWxnb3JpdGhtIHVzaW5nIHRoZSBPd25lcg0KICAgICAg Tm9uY2UuICgjMzkpDQogDQogICAgICBvIENsYXJpZmllZCB0aGUgdXNlIG9mIFNvdXJjZSBh bmQgVGFyZ2V0IGxpbmstbGF5ZXIgb3B0aW9ucyBpbg0KICAgICAgTlIvTkMuICgjNDMpDQog DQogICAgICBvIEluY2x1ZGVkIHRleHQgb24gdGhlIHVzZSBvZiBhbHRlcm5hdGl2ZSBtZXRo b2RzIHRvIGFjcXVpcmUNCiAgICAgIGFkZHJlc3Nlcy4gKCMzOCkNCiANCiANCiANCjxzcGFu IGNsYXNzPSJncmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg NSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSA0MV08L3NwYW4+IA0KPC9wcmU+PHByZSBj bGFzcz0nbmV3cGFnZSc+PGEgbmFtZT0icGFnZS00MiIgaWQ9InBhZ2UtNDIiIGhyZWY9IiNw YWdlLTQyIiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxzcGFuIGNsYXNzPSJncmV5Ij5J bnRlcm5ldC1EcmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hib3IgRGlzY292ZXJ5ICAgICAg ICAgIEZlYnJ1YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAgICAgbyBSZW1vdmVkIFM9MiBm cm9tIEFkZHJlc3MgT3B0aW9uIChub3QgbmVlZGVkKS4gKCMzNikNCiANCiAgICAgIG8gQWRk ZWQgYSBzZWN0aW9uIG9uIHJvdXRlciBkaXNzZW1pbmF0aW9uIGNvbnNpc3RlbmN5LiAoIzQ0 KQ0KIA0KICAgICAgbyBTbWFsbCBpbXByb3ZlbWVudHMgYW5kIGV4dGVuc2l2ZSBlZGl0aW5n LiAoIzQyLCAjMzcsICMzNSkNCiANCiAgIENoYW5nZXMgZnJvbSAtMDIgdG8gLTAzOg0KIA0K ICAgICAgbyBVcGRhdGVkIHRlcm1pbm9sb2d5LCB3aXRoIDxhIGhyZWY9Ii4vcmZjNDg2MSI+ UkZDNDg2MTwvYT4gbm9uLXRyYW5zaXRpdmUgbGluayBtb2RlbC4NCiANCiAgICAgIG8gNkxv V1BBTiBhbmQgTkQgdGVybWlub2xvZ3kgc2VwYXJhdGVkLg0KIA0KICAgICAgbyBQcm90b2Nv bCBvdmVydmlldyBleHBsYWlucyA8YSBocmVmPSIuL3JmYzQ4NjEiPlJGQzQ4NjE8L2E+IGRp ZmYgaW4gZGV0YWlsLg0KIA0KICAgICAgbyBSUi9SQyBpcyBub3cgTm9kZSBSZWdpc3RyYXRp b24vQ29uZmlybWF0aW9uIChOUi9OQykuDQogDQogICAgICBvIEFkZGVkIE5SIGZhaWx1cmUg Y29kZXMuDQogDQogICAgICBvIEVSIE1ldHJpYyBub3cgaW5jbHVkZWQgaW4gNkxvV1BBTiBT dW1tYXJ5IE9wdGlvbiBmb3IgdXNlIGluDQogICAgICBkZWZhdWx0IHJvdXRlciBkZXRlcm1p bmF0aW9uIGJ5IGhvc3RzLg0KIA0KICAgICAgbyBFeGFtcGxlcyBvZiBob3N0IGRhdGEgc3Ry dWN0dXJlcywgYW5kIHRoZSBXaGl0ZWJvYXJkIGdpdmVuLg0KIA0KICAgICAgbyBXaGl0ZWJv YXJkIGlzIHN1cHBvcnRlZCBieSBhbGwgRWRnZSBSb3V0ZXJzIGZvciBvcHRpb24NCiAgICAg IHNpbXBsaWNpdHkuDQogDQogICAgICBvIEVkZ2UgUm91dGVyIFNwZWNpZmljYXRpb24gY2hh cHRlciByZS1zdHJ1Y3R1cmVkLCBjbGFyaWZ5aW5nDQogICAgICBvcHRpb25hbCBFeHRlbmRl ZCBMb1dQQU4gb3BlcmF0aW9uLg0KIA0KICAgICAgbyBOUy9OQSBub3cgY29tcGxldGVseSBv cHRpb25hbCBmb3Igbm9kZXMuICBObyBhZGRyZXNzIHJlc29sdXRpb24NCiAgICAgIG9yIE5T L05BIE5VRCByZXF1aXJlZC4NCiANCiAgICAgIG8gbGluay1sb2NhbCBvcGVyYXRpb24gbm93 IGNvbXBhdGlibGUgd2l0aCBvREFEICh3YXMgYnJva2VuKS4NCiANCiAgICAgIG8gRXhjZXB0 aW9uIHRvIGhvcCBsaW1pdCA9IDI1NSBmb3IgTlIvTkMgbWVzc2FnZXMuDQogDQogICAgICBv IFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGltcHJvdmVkLg0KIA0KICAgICAgbyBJQ01QdjYg ZGVzdGluYXRpb24gdW5yZWFjaGFibGUgc3VwcG9ydGVkLg0KIA0KICAgQ2hhbmdlcyBmcm9t IC0wMSB0byAtMDI6DQogDQogICAgICBvIEZpeGVkIDE2ICE9IDB4ZmYgYnVnICh0aWNrZXQg Y2xvc2VkKS4NCiANCiAgICAgIG8gU3BlY2lmaWVkIHVzZSBvZiBVTEFzIGluIGFkLWhvYyBM b1dQQU4gPGEgaHJlZj0iI3NlY3Rpb24tOSI+c2VjdGlvbiA5PC9hPiAodGlja2V0DQogICAg ICBjbG9zZWQpLg0KIA0KIA0KIA0KIA0KIA0KPHNwYW4gY2xhc3M9ImdyZXkiPlNoZWxieSwg ZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA1LCAyMDEwICAgICAgICAgICAgICAg IFtQYWdlIDQyXTwvc3Bhbj4gDQo8L3ByZT48cHJlIGNsYXNzPSduZXdwYWdlJz48YSBuYW1l PSJwYWdlLTQzIiBpZD0icGFnZS00MyIgaHJlZj0iI3BhZ2UtNDMiIGNsYXNzPSJpbnZpc2li bGUiPiA8L2E+IA0KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAgICAgICAg NkxvV1BBTiBOZWlnaGJvciBEaXNjb3ZlcnkgICAgICAgICAgRmVicnVhcnkgMjAxMDwvc3Bh bj4gDQogDQogDQogICAgICBvIFRlcm1pbm9sb2d5IGNsZWFudXAgYmFzZWQgb24gQWxleCdz IGNvbW1lbnRzLg0KIA0KICAgICAgbyBHZW5lcmFsIGVkaXRpbmcgaW1wcm92ZW1lbnRzLg0K IA0KICAgQ2hhbmdlcyBmcm9tIC0wMCB0byAtMDE6DQogDQogICAgICBvIFNwZWNpZmllZCB0 aGUgZHVwbGljYXRlIG93bmVyIGludGVyZmFjZSBpZGVudGlmaWVyIHByb2NlZHVyZXMuDQog ICAgICBBIFRJRCBsb2xsaXBvcCBhbGdvcml0aG0gd2FzIHN1ZmZpY2llbnQgKG5vbmNlIHVu bmVjZXNzYXJ5KS4NCiANCiAgICAgIG8gRGVmaW5lZCBmYXVsdCB0b2xlcmFuY2UgdXNpbmcg c2Vjb25kYXJ5IGJpbmRpbmdzLg0KIA0KICAgICAgbyBEZWZpbmVkIGFkLWhvYyBuZXR3b3Jr IG9wZXJhdGlvbi4NCiANCiAgICAgIG8gUmVtb3ZlZCB0aGUgRSBmbGFnIGZyb20gUkEgYW5k IHRoZSBYIGZsYWcgZnJvbSBSUi9SQy4NCiANCiAgICAgIG8gQ29tcGxldGVkIG1lc3NhZ2Ug ZXhhbXBsZXMuDQogDQogICAgICBvIExvdHMgb2YgaW1wcm92ZW1lbnRzIGluIHRleHQgcXVh bGl0eSBhbmQgY29uc2lzdGVuY3kgd2VyZSBtYWRlLg0KIA0KIA0KPHNwYW4gY2xhc3M9Imgy Ij48YSBuYW1lPSJzZWN0aW9uLTE2Ij4xNjwvYT4uICBSZWZlcmVuY2VzPC9zcGFuPiANCiAN CjxzcGFuIGNsYXNzPSJoMyI+PGEgbmFtZT0ic2VjdGlvbi0xNi4xIj4xNi4xPC9hPi4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzPC9zcGFuPiANCiANCiAgIFs8YSBuYW1lPSJyZWYtSS1ELmll dGYtYXV0b2NvbmYtYWRob2MtYWRkci1tb2RlbCIgaWQ9InJlZi1JLUQuaWV0Zi1hdXRvY29u Zi1hZGhvYy1hZGRyLW1vZGVsIj5JLUQuaWV0Zi1hdXRvY29uZi1hZGhvYy1hZGRyLW1vZGVs PC9hPl0NCiAgICAgICAgICAgICAgQmFjY2VsbGksIEUuIGFuZCBNLiBUb3duc2xleSwgIklQ IEFkZHJlc3NpbmcgTW9kZWwgaW4gQWQNCiAgICAgICAgICAgICAgSG9jIE5ldHdvcmtzIiwg PGEgaHJlZj0iLi9kcmFmdC1pZXRmLWF1dG9jb25mLWFkaG9jLWFkZHItbW9kZWwtMDIiPmRy YWZ0LWlldGYtYXV0b2NvbmYtYWRob2MtYWRkci1tb2RlbC0wMjwvYT4gDQogICAgICAgICAg ICAgICh3b3JrIGluIHByb2dyZXNzKSwgSmFudWFyeSAyMDEwLg0KIA0KICAgWzxhIG5hbWU9 InJlZi1SRkMyMTE5IiBpZD0icmVmLVJGQzIxMTkiPlJGQzIxMTk8L2E+XSAgQnJhZG5lciwg Uy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIDxhIGhyZWY9Ii4vYmNwMTQiPkJDUCAxNDwvYT4s IDxhIGhyZWY9Ii4vcmZjMjExOSI+UkZDIDIxMTk8L2E+LCBNYXJjaCAxOTk3Lg0KIA0KICAg WzxhIG5hbWU9InJlZi1SRkMyNDkxIiBpZD0icmVmLVJGQzI0OTEiPlJGQzI0OTE8L2E+XSAg QXJtaXRhZ2UsIEcuLCBTY2h1bHRlciwgUC4sIEpvcmssIE0uLCBhbmQgRy4gSGFydGVyLCAi SVB2Ng0KICAgICAgICAgICAgICBvdmVyIE5vbi1Ccm9hZGNhc3QgTXVsdGlwbGUgQWNjZXNz IChOQk1BKSBuZXR3b3JrcyIsDQogICAgICAgICAgICAgIDxhIGhyZWY9Ii4vcmZjMjQ5MSI+ UkZDIDI0OTE8L2E+LCBKYW51YXJ5IDE5OTkuDQogDQogICBbPGEgbmFtZT0icmVmLVJGQzQx OTEiIGlkPSJyZWYtUkZDNDE5MSI+UkZDNDE5MTwvYT5dICBEcmF2ZXMsIFIuIGFuZCBELiBU aGFsZXIsICJEZWZhdWx0IFJvdXRlciBQcmVmZXJlbmNlcyBhbmQNCiAgICAgICAgICAgICAg TW9yZS1TcGVjaWZpYyBSb3V0ZXMiLCA8YSBocmVmPSIuL3JmYzQxOTEiPlJGQyA0MTkxPC9h PiwgTm92ZW1iZXIgMjAwNS4NCiANCiAgIFs8YSBuYW1lPSJyZWYtUkZDNDE5MyIgaWQ9InJl Zi1SRkM0MTkzIj5SRkM0MTkzPC9hPl0gIEhpbmRlbiwgUi4gYW5kIEIuIEhhYmVybWFuLCAi VW5pcXVlIExvY2FsIElQdjYgVW5pY2FzdA0KICAgICAgICAgICAgICBBZGRyZXNzZXMiLCA8 YSBocmVmPSIuL3JmYzQxOTMiPlJGQyA0MTkzPC9hPiwgT2N0b2JlciAyMDA1Lg0KIA0KICAg WzxhIG5hbWU9InJlZi1SRkM0MjkxIiBpZD0icmVmLVJGQzQyOTEiPlJGQzQyOTE8L2E+XSAg SGluZGVuLCBSLiBhbmQgUy4gRGVlcmluZywgIklQIFZlcnNpb24gNiBBZGRyZXNzaW5nDQog ICAgICAgICAgICAgIEFyY2hpdGVjdHVyZSIsIDxhIGhyZWY9Ii4vcmZjNDI5MSI+UkZDIDQy OTE8L2E+LCBGZWJydWFyeSAyMDA2Lg0KIA0KICAgWzxhIG5hbWU9InJlZi1SRkM0NDI5IiBp ZD0icmVmLVJGQzQ0MjkiPlJGQzQ0Mjk8L2E+XSAgTW9vcmUsIE4uLCAiT3B0aW1pc3RpYyBE dXBsaWNhdGUgQWRkcmVzcyBEZXRlY3Rpb24gKERBRCkNCiAgICAgICAgICAgICAgZm9yIElQ djYiLCA8YSBocmVmPSIuL3JmYzQ0MjkiPlJGQyA0NDI5PC9hPiwgQXByaWwgMjAwNi4NCiAN CiANCiANCiANCjxzcGFuIGNsYXNzPSJncmV5Ij5TaGVsYnksIGV0IGFsLiAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSA0M108L3NwYW4+ IA0KPC9wcmU+PHByZSBjbGFzcz0nbmV3cGFnZSc+PGEgbmFtZT0icGFnZS00NCIgaWQ9InBh Z2UtNDQiIGhyZWY9IiNwYWdlLTQ0IiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPiANCjxzcGFu IGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgIDZMb1dQQU4gTmVpZ2hib3Ig RGlzY292ZXJ5ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTA8L3NwYW4+IA0KIA0KIA0KICAgWzxh IG5hbWU9InJlZi1SRkM0NDQzIiBpZD0icmVmLVJGQzQ0NDMiPlJGQzQ0NDM8L2E+XSAgQ29u dGEsIEEuLCBEZWVyaW5nLCBTLiwgYW5kIE0uIEd1cHRhLCAiSW50ZXJuZXQgQ29udHJvbA0K ICAgICAgICAgICAgICBNZXNzYWdlIFByb3RvY29sIChJQ01QdjYpIGZvciB0aGUgSW50ZXJu ZXQgUHJvdG9jb2wNCiAgICAgICAgICAgICAgVmVyc2lvbiA2IChJUHY2KSBTcGVjaWZpY2F0 aW9uIiwgPGEgaHJlZj0iLi9yZmM0NDQzIj5SRkMgNDQ0MzwvYT4sIE1hcmNoIDIwMDYuDQog DQogICBbPGEgbmFtZT0icmVmLVJGQzQ4NjEiIGlkPSJyZWYtUkZDNDg2MSI+UkZDNDg2MTwv YT5dICBOYXJ0ZW4sIFQuLCBOb3JkbWFyaywgRS4sIFNpbXBzb24sIFcuLCBhbmQgSC4gU29s aW1hbiwNCiAgICAgICAgICAgICAgIk5laWdoYm9yIERpc2NvdmVyeSBmb3IgSVAgdmVyc2lv biA2IChJUHY2KSIsIDxhIGhyZWY9Ii4vcmZjNDg2MSI+UkZDIDQ4NjE8L2E+LA0KICAgICAg ICAgICAgICBTZXB0ZW1iZXIgMjAwNy4NCiANCiAgIFs8YSBuYW1lPSJyZWYtUkZDNDg2MiIg aWQ9InJlZi1SRkM0ODYyIj5SRkM0ODYyPC9hPl0gIFRob21zb24sIFMuLCBOYXJ0ZW4sIFQu LCBhbmQgVC4gSmlubWVpLCAiSVB2NiBTdGF0ZWxlc3MNCiAgICAgICAgICAgICAgQWRkcmVz cyBBdXRvY29uZmlndXJhdGlvbiIsIDxhIGhyZWY9Ii4vcmZjNDg2MiI+UkZDIDQ4NjI8L2E+ LCBTZXB0ZW1iZXIgMjAwNy4NCiANCiAgIFs8YSBuYW1lPSJyZWYtUkZDNDk0NCIgaWQ9InJl Zi1SRkM0OTQ0Ij5SRkM0OTQ0PC9hPl0gIE1vbnRlbmVncm8sIEcuLCBLdXNoYWxuYWdhciwg Ti4sIEh1aSwgSi4sIGFuZCBELiBDdWxsZXIsDQogICAgICAgICAgICAgICJUcmFuc21pc3Np b24gb2YgSVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTUuNA0KICAgICAgICAgICAgICBO ZXR3b3JrcyIsIDxhIGhyZWY9Ii4vcmZjNDk0NCI+UkZDIDQ5NDQ8L2E+LCBTZXB0ZW1iZXIg MjAwNy4NCiANCjxzcGFuIGNsYXNzPSJoMyI+PGEgbmFtZT0ic2VjdGlvbi0xNi4yIj4xNi4y PC9hPi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXM8L3NwYW4+IA0KIA0KICAgWzxhIG5hbWU9 InJlZi1JLUQuaWV0Zi02bG93cGFuLWhjIiBpZD0icmVmLUktRC5pZXRmLTZsb3dwYW4taGMi PkktRC5pZXRmLTZsb3dwYW4taGM8L2E+XQ0KICAgICAgICAgICAgICBIdWksIEouIGFuZCBQ LiBUaHViZXJ0LCAiQ29tcHJlc3Npb24gRm9ybWF0IGZvciBJUHY2DQogICAgICAgICAgICAg IERhdGFncmFtcyBpbiA2TG9XUEFOIE5ldHdvcmtzIiwgPGEgaHJlZj0iLi9kcmFmdC1pZXRm LTZsb3dwYW4taGMtMDYiPmRyYWZ0LWlldGYtNmxvd3Bhbi1oYy0wNjwvYT4gDQogICAgICAg ICAgICAgICh3b3JrIGluIHByb2dyZXNzKSwgT2N0b2JlciAyMDA5Lg0KIA0KICAgWzxhIG5h bWU9InJlZi1SRkMyMDIyIiBpZD0icmVmLVJGQzIwMjIiPlJGQzIwMjI8L2E+XSAgQXJtaXRh Z2UsIEcuLCAiU3VwcG9ydCBmb3IgTXVsdGljYXN0IG92ZXIgVU5JIDMuMC8zLjENCiAgICAg ICAgICAgICAgYmFzZWQgQVRNIE5ldHdvcmtzIiwgPGEgaHJlZj0iLi9yZmMyMDIyIj5SRkMg MjAyMjwvYT4sIE5vdmVtYmVyIDE5OTYuDQogDQogICBbPGEgbmFtZT0icmVmLVJGQzMxMjIi IGlkPSJyZWYtUkZDMzEyMiI+UkZDMzEyMjwvYT5dICBDb250YSwgQS4sICJFeHRlbnNpb25z IHRvIElQdjYgTmVpZ2hib3IgRGlzY292ZXJ5IGZvcg0KICAgICAgICAgICAgICBJbnZlcnNl IERpc2NvdmVyeSBTcGVjaWZpY2F0aW9uIiwgPGEgaHJlZj0iLi9yZmMzMTIyIj5SRkMgMzEy MjwvYT4sIEp1bmUgMjAwMS4NCiANCiAgIFs8YSBuYW1lPSJyZWYtUkZDMzc1NiIgaWQ9InJl Zi1SRkMzNzU2Ij5SRkMzNzU2PC9hPl0gIE5pa2FuZGVyLCBQLiwgS2VtcGYsIEouLCBhbmQg RS4gTm9yZG1hcmssICJJUHY2IE5laWdoYm9yDQogICAgICAgICAgICAgIERpc2NvdmVyeSAo TkQpIFRydXN0IE1vZGVscyBhbmQgVGhyZWF0cyIsIDxhIGhyZWY9Ii4vcmZjMzc1NiI+UkZD IDM3NTY8L2E+LA0KICAgICAgICAgICAgICBNYXkgMjAwNC4NCiANCiAgIFs8YSBuYW1lPSJy ZWYtUkZDMzk3MSIgaWQ9InJlZi1SRkMzOTcxIj5SRkMzOTcxPC9hPl0gIEFya2tvLCBKLiwg S2VtcGYsIEouLCBaaWxsLCBCLiwgYW5kIFAuIE5pa2FuZGVyLCAiU0VjdXJlDQogICAgICAg ICAgICAgIE5laWdoYm9yIERpc2NvdmVyeSAoU0VORCkiLCA8YSBocmVmPSIuL3JmYzM5NzEi PlJGQyAzOTcxPC9hPiwgTWFyY2ggMjAwNS4NCiANCiAgIFs8YSBuYW1lPSJyZWYtUkZDMzk3 MiIgaWQ9InJlZi1SRkMzOTcyIj5SRkMzOTcyPC9hPl0gIEF1cmEsIFQuLCAiQ3J5cHRvZ3Jh cGhpY2FsbHkgR2VuZXJhdGVkIEFkZHJlc3NlcyAoQ0dBKSIsDQogICAgICAgICAgICAgIDxh IGhyZWY9Ii4vcmZjMzk3MiI+UkZDIDM5NzI8L2E+LCBNYXJjaCAyMDA1Lg0KIA0KICAgWzxh IG5hbWU9InJlZi1SRkM0MDg2IiBpZD0icmVmLVJGQzQwODYiPlJGQzQwODY8L2E+XSAgRWFz dGxha2UsIEQuLCBTY2hpbGxlciwgSi4sIGFuZCBTLiBDcm9ja2VyLCAiUmFuZG9tbmVzcw0K ICAgICAgICAgICAgICBSZXF1aXJlbWVudHMgZm9yIFNlY3VyaXR5IiwgPGEgaHJlZj0iLi9i Y3AxMDYiPkJDUCAxMDY8L2E+LCA8YSBocmVmPSIuL3JmYzQwODYiPlJGQyA0MDg2PC9hPiwg SnVuZSAyMDA1Lg0KIA0KICAgWzxhIG5hbWU9InJlZi1SRkM0OTAzIiBpZD0icmVmLVJGQzQ5 MDMiPlJGQzQ5MDM8L2E+XSAgVGhhbGVyLCBELiwgIk11bHRpLUxpbmsgU3VibmV0IElzc3Vl cyIsIDxhIGhyZWY9Ii4vcmZjNDkwMyI+UkZDIDQ5MDM8L2E+LA0KICAgICAgICAgICAgICBK dW5lIDIwMDcuDQogDQogICBbPGEgbmFtZT0icmVmLVJGQzQ5MTkiIGlkPSJyZWYtUkZDNDkx OSI+UkZDNDkxOTwvYT5dICBLdXNoYWxuYWdhciwgTi4sIE1vbnRlbmVncm8sIEcuLCBhbmQg Qy4gU2NodW1hY2hlciwgIklQdjYNCiAgICAgICAgICAgICAgb3ZlciBMb3ctUG93ZXIgV2ly ZWxlc3MgUGVyc29uYWwgQXJlYSBOZXR3b3JrcyAoNkxvV1BBTnMpOg0KICAgICAgICAgICAg ICBPdmVydmlldywgQXNzdW1wdGlvbnMsIFByb2JsZW0gU3RhdGVtZW50LCBhbmQgR29hbHMi LA0KICAgICAgICAgICAgICA8YSBocmVmPSIuL3JmYzQ5MTkiPlJGQyA0OTE5PC9hPiwgQXVn dXN0IDIwMDcuDQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5LCBldCBhbC4g ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2Ug NDRdPC9zcGFuPiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5hbWU9InBhZ2Ut NDUiIGlkPSJwYWdlLTQ1IiBocmVmPSIjcGFnZS00NSIgY2xhc3M9ImludmlzaWJsZSI+IDwv YT4gDQo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2TG9XUEFO IE5laWdoYm9yIERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFuPiANCiAN CiANCkF1dGhvcnMnIEFkZHJlc3Nlcw0KIA0KICAgWmFjaCBTaGVsYnkgKGVkaXRvcikNCiAg IFNlbnNpbm9kZQ0KICAgSGFsbGl0dXNrYXR1IDEzLTE3RA0KICAgT3VsdSAgOTAxMDANCiAg IEZJTkxBTkQNCiANCiAgIFBob25lOiArMzU4NDA3Nzk2Mjk3DQogICBFbWFpbDogemFjaEBz ZW5zaW5vZGUuY29tDQogDQogDQogICBQYXNjYWwgVGh1YmVydA0KICAgQ2lzY28gU3lzdGVt cw0KICAgVmlsbGFnZSBkJ0VudHJlcHJpc2VzIEdyZWVuIFNpZGUNCiAgIDQwMCwgQXZlbnVl IGRlIFJvdW1hbmlsbGUNCiAgIEJhdGltZW50IFQzDQogICBCaW90IC0gU29waGlhIEFudGlw b2xpcyAgMDY0MTANCiAgIEZSQU5DRQ0KIA0KICAgUGhvbmU6ICszMyA0IDk3IDIzIDI2IDM0 DQogICBFbWFpbDogcHRodWJlcnRAY2lzY28uY29tDQogDQogDQogICBKb25hdGhhbiBXLiBI dWkNCiAgIEFyY2ggUm9jayBDb3Jwb3JhdGlvbg0KICAgNTAxIDJuZCBTdC4gU3RlLiA0MTAN CiAgIFNhbiBGcmFuY2lzY28sIENhbGlmb3JuaWEgIDk0MTA3DQogICBVU0ENCiANCiAgIFBo b25lOiArNDE1IDY5MiAwODI4DQogICBFbWFpbDogamh1aUBhcmNocm9jay5jb20NCiANCiAN CiAgIFNhbWl0YSBDaGFrcmFiYXJ0aQ0KICAgSVAgSW5mdXNpb24NCiAgIDExODggQXJxdWVz dCBTdHJlZXQNCiAgIFN1bm55dmFsZSwgQ2FsaWZvcm5pYQ0KICAgVVNBDQogDQogICBQaG9u ZToNCiAgIEVtYWlsOiBzYW1pdGFjQGlwaW5mdXNpb24uY29tDQogDQogDQogDQogDQogDQog DQogDQogDQogDQo8c3BhbiBjbGFzcz0iZ3JleSI+U2hlbGJ5LCBldCBhbC4gICAgICAgICAg IEV4cGlyZXMgQXVndXN0IDUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNDVdPC9zcGFu PiANCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPjxhIG5hbWU9InBhZ2UtNDYiIGlkPSJw YWdlLTQ2IiBocmVmPSIjcGFnZS00NiIgY2xhc3M9ImludmlzaWJsZSI+IDwvYT4gDQo8c3Bh biBjbGFzcz0iZ3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICA2TG9XUEFOIE5laWdoYm9y IERpc2NvdmVyeSAgICAgICAgICBGZWJydWFyeSAyMDEwPC9zcGFuPiANCiANCiANCiAgIENh cnN0ZW4gQm9ybWFubg0KICAgVW5pdmVyc2l0YWV0IEJyZW1lbiBUWkkNCiAgIFBvc3RmYWNo IDMzMDQ0MA0KICAgQnJlbWVuICBELTI4MzU5DQogICBHZXJtYW55DQogDQogICBQaG9uZTog KzQ5LTQyMS0yMTgtNjM5MjENCiAgIEZheDogICArNDktNDIxLTIxOC03MDAwDQogICBFbWFp bDogY2Fib0B0emkub3JnDQogDQogDQogICBFcmlrIE5vcmRtYXJrDQogICBTdW4gTWljcm9z eXN0ZW1zDQogICAxNyBOZXR3b3JrIENpcmNsZQ0KICAgTWVubG8gUGFyaywgQ2FsaWZvcm5p YSAgOTQwMjUNCiAgIFVTQQ0KIA0KICAgUGhvbmU6DQogICBFbWFpbDogRXJpay5Ob3JkbWFy a0BTdW4uQ09NDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQpT aGVsYnksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNSwgMjAxMCAgICAgICAg ICAgICAgICBbUGFnZSA0Nl0NCjwvcHJlPjxwcmUgY2xhc3M9J25ld3BhZ2UnPiANCiANCjwv cHJlPjxiciAvPiANCjxzcGFuIGNsYXNzPSJub3ByaW50Ij48c21hbGw+PHNtYWxsPkh0bWwg bWFya3VwIHByb2R1Y2VkIGJ5IHJmY21hcmt1cCAxLjg2LCBhdmFpbGFibGUgZnJvbQ0KPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL3JmY21hcmt1cC8iPmh0dHA6Ly90 b29scy5pZXRmLm9yZy90b29scy9yZmNtYXJrdXAvPC9hPiANCjwvc21hbGw+PC9zbWFsbD48 L3NwYW4+IA0KPC9ib2R5PjwvaHRtbD4g --------------060203090205000409070206-- --------------ms060303020407020401040907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAy MDkyMjUzNTRaMCMGCSqGSIb3DQEJBDEWBBSezm86hx6WsYqKl6FdlgoL7TgXnDBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAIkpPi2JUnPuTW9bU3lQHvNZn4M0gePkLqFaEW2GDzoKo1DvF5xVSH4TsyOhkEhyZsaF jwpUjmH4M5HuwQV7TM7Y0+Eoq55H9NTw5MSSwrs4PsQjndHyQe3/Owg1cJHDwjs6Ht89y40E /JngoBpM/ObjEFkAyVMxxv0lqWWB35ZerxJGP9WTjU/vdbR22L+lBEqfBRSN/Y7zFzroqYDS xospg8b6zTZIouyM8VTsPZcuY74kxlksPiyhpaFCbyfAFkIPxk8zBeFTxPrmQdhwg3pifHHv n/iiXYi7TIl3e8ScHdsEOR6esyaWnyzZ0VWgTtEx3mNAgjwAFHZIcjkcMYsAAAAAAAA= --------------ms060303020407020401040907-- From geoff@proto6.com Fri Feb 12 23:55:16 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74033A7933 for <6lowpan@core3.amsl.com>; Fri, 12 Feb 2010 23:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjiVjhjdPEd2 for <6lowpan@core3.amsl.com>; Fri, 12 Feb 2010 23:55:15 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id E38593A770F for <6lowpan@ietf.org>; Fri, 12 Feb 2010 23:55:15 -0800 (PST) Received: from server1.coslabs.com (unknown [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 85EBC1835B for <6lowpan@ietf.org>; Sat, 13 Feb 2010 00:56:42 -0700 (MST) Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o1D7uboi007680 for <6lowpan@ietf.org>; Sat, 13 Feb 2010 00:56:37 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain Date: Sat, 13 Feb 2010 00:56:31 -0700 Message-Id: <1266047791.3643.48.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 13 Feb 2010 07:55:16 -0000 Folks, I realized that I have made a huge slip-up. The HC draft has languished for the past few months. At the meeting in Hiroshima we said that we would last call this draft, but I failed to send out the actual last call. So... This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks". The document can be found at: http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt The document is intended to be submitted by this Working Group to the IESG for publication as a Standards Track document. Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. Because of my gaffe this Last Call will end Wednesday February 24 2010 at 2359 UTC. Thanks, Geoff From erik.nordmark@sun.com Sun Feb 14 08:18:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6771D3A783D for <6lowpan@core3.amsl.com>; Sun, 14 Feb 2010 08:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.55 X-Spam-Level: X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvazQOq1Fjez for <6lowpan@core3.amsl.com>; Sun, 14 Feb 2010 08:18:35 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 3A3F83A6BFC for <6lowpan@ietf.org>; Sun, 14 Feb 2010 08:18:35 -0800 (PST) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1EGK125026433 for <6lowpan@ietf.org>; Sun, 14 Feb 2010 16:20:01 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o1EGK1Di135482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Feb 2010 08:20:01 -0800 (PST) Message-ID: <4B773287.5000403@sun.com> Date: Sat, 13 Feb 2010 15:15:19 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20091207 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org> <04F5D591-1248-42FF-94E8-73978F0F4C5D@archrock.com> <6D9687E95918C04A8B30A7D6DA805A3E01429E0B@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01429E11@zensys17.zensys.local> <8D8B69C8-8015-4C3D-9D9A-68327D4266BA@sensinode.com> In-Reply-To: <8D8B69C8-8015-4C3D-9D9A-68327D4266BA@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] 6LoWPAN-ND - Use of node registration should be optional X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 14 Feb 2010 16:18:36 -0000 On 01/27/10 06:19 AM, Zach Shelby wrote: > The -08 version no longer differentiates Edge Routers and Routers > when it comes to registration. Instead, the NR/NC exchange is only > made link-locally between a node and the router its default router. > That router may be an Edge Router. There is no longer the concept of > an Extended LoWPAN or Whiteboard in this draft, and NR messages are > not relayed. > > Yes, this Node Registration must be performed for a node to use a > router. This is important because that message exchange builds up the > necessary information on both sides for address resolution, > unreachability detection and for a node to check that its address is > unique. I agree that a registration is required for hosts so that the routing protocol on the routers know which hosts are attached. But I don't see any logic in -08 which ensures that an IPv6 address based on the short addresses is unique across the lowpan. The NR/NC is local. Thus with this approach it isn't possible to support short addresses. Perhaps we need a separate mechanism to allocate and/or ensure uniqueness of short addresses? While there isn't a need for any ER as used in earlier versions, we do need some notion of the prefix originating router(s). By this I mean that one or more routers will originate the prefix or prefixes used in the lowpan. In the case of a lowpan attached to a wire it seems natural that the router(s) that attach to the wire would do this. That is the same location as what we previously called edge routers. Erik From zach@sensinode.com Mon Feb 15 02:12:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD793A731D for <6lowpan@core3.amsl.com>; Mon, 15 Feb 2010 02:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysm9WR8Q7WR4 for <6lowpan@core3.amsl.com>; Mon, 15 Feb 2010 02:12:42 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 76CD73A7530 for <6lowpan@ietf.org>; Mon, 15 Feb 2010 02:12:41 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1FAE6ue016679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Feb 2010 12:14:07 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4B773287.5000403@sun.com> Date: Mon, 15 Feb 2010 12:14:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <474997F6-8585-4300-A87F-D23F1AC9B142@sensinode.com> References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org> <04F5D591-1248-42FF-94E8-73978F0F4C5D@archrock.com> <6D9687E95918C04A8B30A7D6DA805A3E01429E0B@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01429E11@zensys17.zensys.local> <8D8B69C8-8015-4C3D-9D9A-68327D4266BA@sensinode.com> <4B773287.5000403@sun.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1077) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6LoWPAN-ND - Use of node registration should be optional X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 15 Feb 2010 10:12:44 -0000 Hi Erik, On Feb 14, 2010, at 1:15 , Erik Nordmark wrote: > On 01/27/10 06:19 AM, Zach Shelby wrote: >=20 >> The -08 version no longer differentiates Edge Routers and Routers >> when it comes to registration. Instead, the NR/NC exchange is only >> made link-locally between a node and the router its default router. >> That router may be an Edge Router. There is no longer the concept of >> an Extended LoWPAN or Whiteboard in this draft, and NR messages are >> not relayed. >>=20 >> Yes, this Node Registration must be performed for a node to use a >> router. This is important because that message exchange builds up the >> necessary information on both sides for address resolution, >> unreachability detection and for a node to check that its address is >> unique. >=20 > I agree that a registration is required for hosts so that the routing = protocol on the routers know which hosts are attached. The registration is also needed to bootstrap new routers to a LoWPAN. = After that we can consider their bindings refreshed with e.g. routing = signaling. =20 >=20 > But I don't see any logic in -08 which ensures that an IPv6 address = based on the short addresses is unique across the lowpan. The NR/NC is = local. Thus with this approach it isn't possible to support short = addresses. >=20 > Perhaps we need a separate mechanism to allocate and/or ensure = uniqueness of short addresses? Correct, this is the aim of the split in a way. The draft currently says = that address allocation and/or duplicate address detection are to be = performed by the router after receiving the NR message when appropriate. = But those mechanisms are not defined in this draft. Address allocation could be performed using DHCPv6. Another alternative = will be the Extended LoWPAN draft (to be written), which would extend = the registration to an Edge Router.=20 The thing I found hard writing the text, was how to define the = situations when duplicate detection SHOULD or MUST be performed... so = plenty of comments needed on Section 5.3... >=20 > While there isn't a need for any ER as used in earlier versions, we do = need some notion of the prefix originating router(s). By this I mean = that one or more routers will originate the prefix or prefixes used in = the lowpan. In the case of a lowpan attached to a wire it seems natural = that the router(s) that attach to the wire would do this. That is the = same location as what we previously called edge routers. Right, I think we should actually keep the ER term for the purpose of = prefix origination in this draft. So the ER concept now is just a router = attached to the wire, from which prefixes originate. How does that = sound? Thanks, Zach =20 >=20 > Erik >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From zach@sensinode.com Mon Feb 15 02:27:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5AB3A7B39 for <6lowpan@core3.amsl.com>; Mon, 15 Feb 2010 02:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYcOzloyEfHX for <6lowpan@core3.amsl.com>; Mon, 15 Feb 2010 02:27:34 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id CE2D03A7B37 for <6lowpan@ietf.org>; Mon, 15 Feb 2010 02:27:33 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1FASvgB018109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Feb 2010 12:28:57 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <4B71E782.2040902@gridmerge.com> Date: Mon, 15 Feb 2010 12:28:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100201215940.0D4FF3A68B6@core3.amsl.com> <4B701131.7080703@gridmerge.com> <4B71E782.2040902@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1077) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 15 Feb 2010 10:27:36 -0000 Robert, Thanks for all the comments, very helpful. I am not sure I could see all = of them though with the HTML embedded in your mail. Could you send me = that again directly as an attachment? Thanks. See some comments below = based on what I could see: On Feb 10, 2010, at 0:53 , Robert Cragie wrote: > Hi Zach, >=20 > I have been through the document and made some corrections (in yellow) = and some comments (in cyan) - see attachment. >=20 > The main things I found were: > =95 Inconsistent terminology. Bar the actual definitions, the = terms, 'host', 'node', 'router' and 'Edge Router' should be used = throughout, not a 'LoWPAN' variant of them. Yep, will fix. > =95 Some hangovers re. whiteboard and Extended LoWPAN Thanks for catching those. > =95 DAD not covered - as mentioned below Correct, how you do DAD is basically out of scope right now in the = draft. The hard part is actually the text defining *when* you SHOULD or = MUST perform DAD... Let's get back to this when I see your full = comments.=20 > =95 Propagation of RS/RA not covered Hmmm.. It is covered in Section 5.7 with regard to Context. Maybe a new = section in Chapter 7 could be added to deal with this more explicitly?=20= > =95 Hints at relaying NR/NC but not covered Right. This would be used by a separate Extended LoWPAN draft. This = draft just needs to define the relay code and fields in NR/NC. Maybe a = mention of why that code is there could help? > =95 Assumption that IID will use EUI-64 whereas it could be = formed from alternate link-layer address. =46rom Section 5.1: " A LoWPAN node forms a 64-bit Interface Identifier (IID) as specified = in=20 Section 6 of [RFC4944]. This may be based on the EUI-64 identifier, an = assigned 16-bit short address, or any other appropriate MAC address." Isn't this OK?=20 Cheers, Zach > Robert > Robert Cragie (Pacific Gas & Electric) >=20 > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com >=20 >=20 >=20 > Robert Cragie wrote: >> Hi Zach, >>=20 >> I have been through the document and made some corrections (in = yellow) and some comments (in cyan) - see attachment. >>=20 >> The main things I found were: >> =95 Inconsistent terminology. Bar the actual definitions, the = terms, 'host', 'node', 'router' and 'Edge Router' should be used = throughout, not a 'LoWPAN' variant of them. >> =95 Some hangovers re. whiteboard and Extended LoWPAN >> =95 DAD not covered - as mentioned below >> =95 Propagation of RS/RA not covered >> =95 Hints at relaying NS/NC but not covered >> =95 Assumption that IID will use EUI-64 whereas it could be = formed from alternate link-layer address. >> Robert=20 >> Robert Cragie (Pacific Gas & Electric) >>=20 >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 (0) 1924 910888 >> http://www.gridmerge.com >>=20 >>=20 >>=20 >> Zach Shelby wrote: >>> Hi everyone, >>>=20 >>> Thanks to an active discussion among the ND authors, and a bunch of = helpful reviews (thanks Richard, Anders and Colin), I finally managed to = post 6lowpan-nd-08, in its new slim form (think biggest loser). After = Hiroshima we reached good WG consensus to split the ND work into the = basic mechanism (which is now this document) and a separate Extended = LoWPAN draft (to be started), furthermore we agreed to deal with the DAD = issue. This document hopefully moves us very close to that goal. This = also includes the new RS feature suggested by Anders. >>>=20 >>>=20 >>> http://www.ietf.org/id/draft-ietf-6lowpan-nd-08.txt >>>=20 >>>=20 >>> As always with major changes (this needed lots of hacking and major = editing), there are surely tons of bugs and loose-ends left. Help to = find those appreciated. >>>=20 >>> Changes from -07 to -08: >>>=20 >>> o Removed Extended LoWPAN and Whiteboard related sections. >>>=20 >>> o Included reference to the autoconf addressing model. >>>=20 >>> o Added Optimistic Flag to 6AO. >>>=20 >>> o Added guidelines on routers performing DAD. >>>=20 >>> o Removed the NR/NC Advertising Interval. >>>=20 >>> o Added assumption of uniform IID formation and DAD throughout = a >>> LoWPAN. >>>=20 >>> The major open issue we have is how to develop the DAD text in = Section 5.3 in such a way that it works for most people, yet produces = reliable and safe LoWPANs, and is yet acceptable to the IPv6 crowd and = especially the IESG ;-) We are trying to find a balance to keep the WG = happy, yet having a chance to actually become an RFC....=20 >>>=20 >>> It would also be nice to reduce the complexity of NR/NC and = especially 6AO message processing. Writing the spec, I am at least not = totally happy with the amount of explaining needed.... Is there a = sleeker way to deal with the addresses? >>>=20 >>> Zach >>>=20 >>> Begin forwarded message: >>>=20 >>> =20 >>>=20 >>>> From: IETF I-D Submission Tool >>>>=20 >>>> Date: February 1, 2010 23:59:40 GMT+02:00 >>>> To:=20 >>>> zach@sensinode.com >>>>=20 >>>> Cc:=20 >>>> = pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,cabo@tzi.org,E= rik.Nordmark@Sun.COM >>>>=20 >>>> Subject: New Version Notification for draft-ietf-6lowpan-nd-08=20 >>>>=20 >>>>=20 >>>> A new version of I-D, draft-ietf-6lowpan-nd-08.txt has been = successfuly submitted by Zach Shelby and posted to the IETF repository. >>>>=20 >>>> Filename: draft-ietf-6lowpan-nd >>>> Revision: 08 >>>> Title: 6LoWPAN Neighbor Discovery >>>> Creation_date: 2010-02-01 >>>> WG ID: 6lowpan >>>> Number_of_pages: 46 >>>>=20 >>>> Abstract: >>>> This document specifies a new Neighbor Discovery mechanism suitable >>>> for LoWPANs. The 6LoWPAN format allows IPv6 to be used over energy >>>> and bandwidth constrained wireless networks often making use of >>>> multihop topologies. However, the use of classic IPv6 Neighbor >>>> Discovery with 6LoWPAN has several problems. Classic Neighbor >>>> Discovery was not designed for non-transitive wireless links, and = the >>>> traditional IPv6 link concept and heavy use of multicast makes it >>>> unpractical. This document specifies a simple Neighbor Discovery >>>> mechanism both sufficient yet minimal for LoWPAN operation. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat. >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>=20 >>> =20 >>>=20 --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From j.schoenwaelder@jacobs-university.de Mon Feb 15 02:29:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3795C3A7B3E for <6lowpan@core3.amsl.com>; Mon, 15 Feb 2010 02:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgL16vfqmgtu for <6lowpan@core3.amsl.com>; Mon, 15 Feb 2010 02:29:48 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7A9B13A7B3A for <6lowpan@ietf.org>; Mon, 15 Feb 2010 02:29:48 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD110C001A for <6lowpan@ietf.org>; Mon, 15 Feb 2010 11:31:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id REa6CogrFygf; Mon, 15 Feb 2010 11:31:16 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 134F1C0019; Mon, 15 Feb 2010 11:31:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6B072106C71E; Mon, 15 Feb 2010 11:31:02 +0100 (CET) Date: Mon, 15 Feb 2010 11:31:02 +0100 From: Juergen Schoenwaelder To: 6lowpan <6lowpan@ietf.org> Message-ID: <20100215103102.GB48352@elstar.local> Mail-Followup-To: 6lowpan <6lowpan@ietf.org> References: <1266047791.3643.48.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1266047791.3643.48.camel@dellx1> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [6lowpan] WGLC for 6lowpan HC draft - comments by js X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 10:29:50 -0000 On Sat, Feb 13, 2010 at 08:56:31AM +0100, Geoff Mulligan wrote: > This note formally starts the WG Last Call for comments on > draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in > 6LoWPAN Networks". > > The document can be found at: > http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt > > The document is intended to be submitted by this Working Group to the > IESG for publication as a Standards Track document. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. I believe the document is essentially ready to go to the IESG. All I found were a few nits: 1) p4: s/is is/is/ 2) p6: s/the the/the/ (occurs twice) 3) p16: I thing the text describing port compression can be somewhat simplified or less confusing by avoiding the "and elided". Here is proposed new text: 01: All 16 bits for Source Port are carried in-line. First 8 bits of Destination Port is 0xF0 and the remaining 8 bits of Destination Port are carried in-line. 10: First 8 bits of Source Port are 0xF0 and the remaining 8 bits of Source Port are carried in-line. All 16 bits for Destination Port are carried in-line. 11: First 12 bits of both Source Port and Destination Port are 0xF0B and the remaining 4 bits for each are carried in-line. 4) I was asking myself whether more needs to be said in the security considerations but could not really come up with additional text. However, operationally, I expect it to be challenging to debug problems when contexts are used since knowledge about the meaning of the contexts is crucial to assign meaning to a conversation. Since the document says how information is maintained in shared contexts is out of scope, I guess there is not much to be done for this document, but hopefully some other documents will be written to make this less of a magic. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From robert.cragie@gridmerge.com Mon Feb 15 09:21:35 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FB028C1C6 for <6lowpan@core3.amsl.com>; Mon, 15 Feb 2010 09:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=3.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuR164Y3m3-p for <6lowpan@core3.amsl.com>; Mon, 15 Feb 2010 09:21:33 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 0595D3A79E7 for <6lowpan@ietf.org>; Mon, 15 Feb 2010 09:21:32 -0800 (PST) Received: from client-86-26-66-142.bmly.adsl.virginmedia.com ([86.26.66.142] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1Nh4ez-000736-IJ; Mon, 15 Feb 2010 17:23:02 +0000 Message-ID: <4B7982F4.6030006@gridmerge.com> Date: Mon, 15 Feb 2010 17:23:00 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Zach Shelby References: <20100201215940.0D4FF3A68B6@core3.amsl.com> <4B701131.7080703@gridmerge.com> <4B71E782.2040902@gridmerge.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060505070603030109050605" Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 17:21:35 -0000 This is a cryptographically signed message in MIME format. --------------ms060505070603030109050605 Content-Type: multipart/alternative; boundary="------------040204050804020904090003" This is a multi-part message in MIME format. --------------040204050804020904090003 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Zach, Comments inline, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Zach Shelby wrote: > Robert, > > Thanks for all the comments, very helpful. I am not sure I could see al= l of them though with the HTML embedded in your mail. Could you send me t= hat again directly as an attachment? Thanks. See some comments below base= d on what I could see: > > On Feb 10, 2010, at 0:53 , Robert Cragie wrote: > > =20 >> Hi Zach, >> >> I have been through the document and made some corrections (in yellow)= and some comments (in cyan) - see attachment. >> >> The main things I found were: >> =95 Inconsistent terminology. Bar the actual definitions, the terms, = 'host', 'node', 'router' and 'Edge Router' should be used throughout, not= a 'LoWPAN' variant of them. >> =20 > > Yep, will fix. > > =20 >> =95 Some hangovers re. whiteboard and Extended LoWPAN >> =20 > > Thanks for catching those. > > =20 >> =95 DAD not covered - as mentioned below >> =20 > > Correct, how you do DAD is basically out of scope right now in the draf= t. The hard part is actually the text defining *when* you SHOULD or MUST = perform DAD... Let's get back to this when I see your full comments.=20 > > =20 >> =95 Propagation of RS/RA not covered >> =20 > > Hmmm.. It is covered in Section 5.7 with regard to Context. Maybe a new= section in Chapter 7 could be added to deal with this more explicitly?=20 > =20 With regard to RS, this can only apply on on-link routers as it is=20 indistinguishable from the RFC4861 RS. Therefore there is no guarantee=20 that an on-link router will have valid information disseminated to it. I = guess the V flag indicates this to some extent but there does seem to be = some implicit assumption that the correct LoWPAN information will=20 percolate to the edges somehow. With regard to RA, It is implicitly covered to some extent by the=20 content of 6IO and 6SO and how that is disseminated from the Edge Router = out into the LoWPAN but the synchronisation mechanism doesn't seem very=20 clear. There is no explicit section on processing RAs that contain=20 6IO/6SO. Maybe it's not strictly necessary but I think there may be some = gaps from a specification point of view. > =20 >> =95 Hints at relaying NR/NC but not covered >> =20 > > Right. This would be used by a separate Extended LoWPAN draft. This dra= ft just needs to define the relay code and fields in NR/NC. Maybe a menti= on of why that code is there could help? > =20 Is this just in extended LoWPANs? In 07 draft, NC would be relayed=20 to the Edge Router and fundamentally made sense in conjunction with the=20 Whiteboard for DAD. Now it only goes to an on-link router, so I guess I=20 don't quite see the point of it anymore unless some specific DAD=20 mechanism is described. > =20 >> =95 Assumption that IID will use EUI-64 whereas it could be formed fr= om alternate link-layer address. >> =20 > > From Section 5.1: > > " A LoWPAN node forms a 64-bit Interface Identifier (IID) as specified= in=20 > Section 6 of [RFC4944]. This may be based on the EUI-64 identifier, an = assigned 16-bit short address, or any other appropriate MAC address." > > Isn't this OK?=20 > =20 There are references throughout which suggest the IID is only=20 formed from the EUI-64. This gives subsequent addresses formed from it=20 different properties wrt. optimism of uniqueness than an IID using=20 16-bit short addresses, say, it its formation. --------------040204050804020904090003 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Zach,

Comments inline, bracketed by <RCC></RCC>

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com



Zach Shelby wrote: 
Robert,

Thanks for all the comments, very helpful. I am not sure I could see all =
of them though with the HTML embedded in your mail. Could you send me tha=
t again directly as an attachment? Thanks. See some comments below based =
on what I could see:

On Feb 10, 2010, at 0:53 , Robert Cragie wrote:

  
Hi Zach,

I have been through the document and made some corrections (in yellow) an=
d some comments (in cyan) - see attachment.

The main things I found were:
	=95 Inconsistent terminology. Bar the actual definitions, the terms, 'ho=
st', 'node', 'router' and 'Edge Router' should be used throughout, not a =
'LoWPAN' variant of them.
    

Yep, will fix.

  
	=95 Some hangovers re. whiteboard and Extended LoWPAN=

    

Thanks for catching those.

  
	=95 DAD not covered - as mentioned below
    

Correct, how you do DAD is basically out of scope right now in the draft.=
 The hard part is actually the text defining *when* you SHOULD or MUST pe=
rform DAD... Let's get back to this when I see your full comments.=20

  
	=95 Propagation of RS/RA not covered
    

Hmmm.. It is covered in Section 5.7 with regard to Context. Maybe a new s=
ection in Chapter 7 could be added to deal with this more explicitly?=20
<RCC>
With regard to RS, this can only apply on on-link routers as it is indistinguishable from the RFC4861 RS. Therefore there is no guarantee that an on-link router will have valid information disseminated to it. I guess the V flag indicates this to some extent but there does seem to be some implicit assumption that the correct LoWPAN information will percolate to the edges somehow.

With regard to RA, It is implicitly covered to some extent by the content of 6IO and 6SO and how that is disseminated from the Edge Router out into the LoWPAN but the synchronisation mechanism doesn't seem very clear. There is no explicit section on processing RAs that contain 6IO/6SO. Maybe it's not strictly necessary but I think there may be some gaps from a specification point of view.
</RCC>
  
	=95 Hints at relaying NR/NC but not covered
    

Right. This would be used by a separate Extended LoWPAN draft. This draft=
 just needs to define the relay code and fields in NR/NC. Maybe a mention=
 of why that code is there could help?
<RCC>Is this just in extended LoWPANs? In 07 draft, NC would be relayed to the Edge Router and fundamentally made sense in conjunction with the Whiteboard for DAD. Now it only goes to an on-link router, so I guess I don't quite see the point of it anymore unless some specific DAD mechanism is described.</RCC>
  
	=95 Assumption that IID will use EUI-64 whereas it co=
uld be formed from alternate link-layer address.
    

=46rom Section 5.1:

"  A LoWPAN node forms a 64-bit Interface Identifier (IID) as specified i=
n=20
Section 6 of [RFC4944]. This may be based on the EUI-64 identifier, an as=
signed 16-bit short address, or any other appropriate MAC address."

Isn't this OK?=20
<RCC>There are references throughout which suggest the IID is only formed from the EUI-64. This gives subsequent addresses formed from it different properties wrt. optimism of uniqueness than an IID using 16-bit=A0 short addresses, say, it its formation.</RCC>
--------------040204050804020904090003-- --------------ms060505070603030109050605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAy MTUxNzIzMDBaMCMGCSqGSIb3DQEJBDEWBBRKGYbOAu9N8ilp07U66/LReLHvszBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAKwKnSvgThDGsaR3zq8pV6q9UfcKzO/V5E0TYYija023TBd5IfhyPQTs0TYyv0nEAmgr L8OfNcEbyEpF9LrKISuhdKF9uYPVGFC7tiAflBzyC3fSi0ac0ernfdH7HcQCOIEhccRpLTgY C2olushX1ew/I/4LjncwTpL4XkPdLBUU0fHRreSNfdr7WcDHHRMpu/ZUjF4myvBM7pjOfTdn 9MIVthYDJPpffhN43W4aPliSE/z8f5uP9ixG2d2apPP0MXq8fkQvF4QW4qhXZFFxTzuIejQs AQx6LOk/7npwBTC9cF/U7h8ZUdhCqyvpYT35wD3N9mWsbhsz2FcKiDLHAV8AAAAAAAA= --------------ms060505070603030109050605-- From richard.kelsey@ember.com Tue Feb 16 12:03:23 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D5F28C183 for <6lowpan@core3.amsl.com>; Tue, 16 Feb 2010 12:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE0aLqIzob-5 for <6lowpan@core3.amsl.com>; Tue, 16 Feb 2010 12:03:23 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D270028C17F for <6lowpan@ietf.org>; Tue, 16 Feb 2010 12:03:22 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 15:07:24 -0500 Date: Tue, 16 Feb 2010 14:52:35 -0500 Message-Id: <87tythufek.fsf@kelsey-ws.hq.ember.com> To: 6lowpan@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 16 Feb 2010 20:07:24.0303 (UTC) FILETIME=[A799E1F0:01CAAF43] Subject: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 16 Feb 2010 20:03:23 -0000 There is a forward-compatibility problem lurking in the fragmentation specified by RFC 4944. In the RFC, fragment headers include sizes and offsets that are relative to the uncompressed datagram, and not the compressed version that is actually being communicated. If a node receives a fragmented datagram which includes a compressed next header that the node does not know how to uncompress, the node may not be able to determine if it has received all of the fragments. It knows neither the length of the compressed datagram or the total number of fragments. Further, the RFC states: Similarly, when a node first receives a fragment with a given datagram_tag, it starts a reassembly timer. When this time expires, if the entire packet has not been reassembled, the existing fragments MUST be discarded and the reassembly state MUST be flushed. This requirement assumes that the receiver is able to determine when it has received a complete datagram. My main concern is the possibility of compressing TCP headers at some time in the future. Pre-existing devices would not necessarily be able to forward packets with compressed TCP headers. This could be fixed in several ways, such as using the compressed sizes and offsets instead of the uncompressed ones, or including the number of fragments in the first fragment header. -Richard Kelsey From osk@exegin.com Tue Feb 16 13:03:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C8228C1DF for <6lowpan@core3.amsl.com>; Tue, 16 Feb 2010 13:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYbWbH5tyMzg for <6lowpan@core3.amsl.com>; Tue, 16 Feb 2010 13:03:31 -0800 (PST) Received: from mail-pz0-f190.google.com (mail-pz0-f190.google.com [209.85.222.190]) by core3.amsl.com (Postfix) with ESMTP id ED58B28C1DE for <6lowpan@ietf.org>; Tue, 16 Feb 2010 13:03:30 -0800 (PST) Received: by pzk28 with SMTP id 28so8054346pzk.31 for <6lowpan@ietf.org>; Tue, 16 Feb 2010 13:05:04 -0800 (PST) Received: by 10.143.27.21 with SMTP id e21mr4675368wfj.4.1266354304281; Tue, 16 Feb 2010 13:05:04 -0800 (PST) Received: from ?172.16.1.66? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 22sm7381297pzk.13.2010.02.16.13.05.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Feb 2010 13:05:03 -0800 (PST) Message-ID: <4B7B0875.8060609@exegin.com> Date: Tue, 16 Feb 2010 13:04:53 -0800 From: Owen Kirby Organization: Exegin Technologies Limited User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87tythufek.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 16 Feb 2010 21:03:32 -0000 Richard, We've been grappling with this problem internally over the last week or so, and I'd like to add our take on some of the problems in combining RFC4944 fragmentation with the draft header compression. I think the RFC4944 fragmentation was optimized specifically for HC1 compression under the assumption that the compressed headers never extend beyond the first fragment of the packet. If we assume that all subsequent fragments are uncompressed then you can quite easily tell when you have received all of the fragments, and the last fragment will have (dgram_offset + fragment size == dgram_size). The only oddity is that you have to decompress the first fragment before you can reassemble the datagram. However, I suspect that this assumption is no longer true in the case of the draft header compression. Especially now that IPv6 extension headers can be compressed (what do we do if ROLL adds ~160 bytes of routing headers to a packet?). It becomes substantially more complicated to determine how to defragment packets since we need to know the uncompressed length of each header in order to know when reassembly is done and to detect missing fragments, but we can't decompress the headers until we have all of the compressed headers. We get stuck in a catch-22: can't defragment until after decompression, but can't decompress until after defragmentation. |First Fragment (F1) |Second Fragment (F2) |Third Fragment (F3) +---------------------+ +-------------------+ +--------+--------------+ | Compressed Headers | |Compressed Headers | | C Hdrs | Payload | +---------------------+ +-------------------+ +--------+--------------+ : \ : \ : : \ : \ : |Uncompressed Datagram \: \: +-------------------------:-----------------------:--------+--------------+ | Uncompressed Headers | Payload | +-------------------------:-----------------------:--------+--------------+ | | | | |<--- L1 --->|<--- L2 --->|<--- L3 --->| | | |<-------------------------- datagram_size ----------------------->| The only way to reassemble these three packets is to perform decompression and reassembly at the same time, since the lengths and offsets of fragments F1, F2, and F3 do not add up to the datagram size, and leave gaps in the packet that hopefully get filled after decompression. It also becomes necessary to store the state of your decompressor across multiple packets, which can get very ugly if header fields get split across fragments. Either one of your recommended solutions would work, but if you want to include the total number of fragments I would recommend that each packet should also be identified by a sequence number. A simple, but less efficient solution, could also be to simply state that any headers which extend past the first fragment after compression should not be compressed. Also, as the author of the 6LoWPAN dissectors for Wireshark, I'm pulling my hair out trying to find a way to implement this without throwing away all of Wireshark's reassembly support and starting from scratch, or implementing some sort of wild speculative guessing. Thanks, Owen Kirby Richard Kelsey wrote: > There is a forward-compatibility problem lurking in the > fragmentation specified by RFC 4944. In the RFC, fragment > headers include sizes and offsets that are relative to the > uncompressed datagram, and not the compressed version that > is actually being communicated. If a node receives a > fragmented datagram which includes a compressed next header > that the node does not know how to uncompress, the node may > not be able to determine if it has received all of the > fragments. It knows neither the length of the compressed > datagram or the total number of fragments. > > Further, the RFC states: > > Similarly, when a node first receives a fragment with a > given datagram_tag, it starts a reassembly timer. When > this time expires, if the entire packet has not been > reassembled, the existing fragments MUST be discarded and > the reassembly state MUST be flushed. > > This requirement assumes that the receiver is able to > determine when it has received a complete datagram. > > My main concern is the possibility of compressing TCP > headers at some time in the future. Pre-existing devices > would not necessarily be able to forward packets with > compressed TCP headers. > > This could be fixed in several ways, such as using the > compressed sizes and offsets instead of the uncompressed > ones, or including the number of fragments in the first > fragment header. > -Richard Kelsey > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Wed Feb 17 09:31:46 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C391628C104 for <6lowpan@core3.amsl.com>; Wed, 17 Feb 2010 09:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y-rcxtyDYqJ for <6lowpan@core3.amsl.com>; Wed, 17 Feb 2010 09:31:45 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 9507228C0DF for <6lowpan@ietf.org>; Wed, 17 Feb 2010 09:31:43 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1HHXLqF000831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <6lowpan@ietf.org>; Wed, 17 Feb 2010 18:33:21 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1HHXKPx022509 for <6lowpan@ietf.org>; Wed, 17 Feb 2010 18:33:21 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1HHXK1C018915 for <6lowpan@ietf.org>; Wed, 17 Feb 2010 18:33:20 +0100 Message-ID: <4B7C2860.9010306@gmail.com> Date: Wed, 17 Feb 2010 18:33:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <20100201215940.0D4FF3A68B6@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] Licensing scheme for draft-ietf-6lowpan-nd-08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 17 Feb 2010 17:31:46 -0000 A side note on this draft. First - please don't overeact, I know, I should discuss this on tlp-interest - ok, I will. I wanted to publicly let the group know that I don't agree with the conditions in the preamble (boilerplate) of this draft. In the past I may have commented technically on this draft. Right now I must say I don't agree with its licensing. That's all, thanks for ignoring this message. I just want it to be here if any use for later. Yours, Alex (I am trying to do the same about all drafts I've been commented on recently because I just discovered the new IETF Trust licensing scheme in the boilerplate.) Le 01/02/2010 23:17, Zach Shelby a écrit : > Hi everyone, > > Thanks to an active discussion among the ND authors, and a bunch of > helpful reviews (thanks Richard, Anders and Colin), I finally managed > to post 6lowpan-nd-08, in its new slim form (think biggest loser). > After Hiroshima we reached good WG consensus to split the ND work > into the basic mechanism (which is now this document) and a separate > Extended LoWPAN draft (to be started), furthermore we agreed to deal > with the DAD issue. This document hopefully moves us very close to > that goal. This also includes the new RS feature suggested by > Anders. > > http://www.ietf.org/id/draft-ietf-6lowpan-nd-08.txt > > As always with major changes (this needed lots of hacking and major > editing), there are surely tons of bugs and loose-ends left. Help to > find those appreciated. > > Changes from -07 to -08: > > o Removed Extended LoWPAN and Whiteboard related sections. > > o Included reference to the autoconf addressing model. > > o Added Optimistic Flag to 6AO. > > o Added guidelines on routers performing DAD. > > o Removed the NR/NC Advertising Interval. > > o Added assumption of uniform IID formation and DAD throughout a > LoWPAN. > > The major open issue we have is how to develop the DAD text in > Section 5.3 in such a way that it works for most people, yet produces > reliable and safe LoWPANs, and is yet acceptable to the IPv6 crowd > and especially the IESG ;-) We are trying to find a balance to keep > the WG happy, yet having a chance to actually become an RFC.... > > It would also be nice to reduce the complexity of NR/NC and > especially 6AO message processing. Writing the spec, I am at least > not totally happy with the amount of explaining needed.... Is there a > sleeker way to deal with the addresses? > > Zach > > Begin forwarded message: > >> From: IETF I-D Submission Tool Date: >> February 1, 2010 23:59:40 GMT+02:00 To: zach@sensinode.com Cc: >> pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,cabo@tzi.org,Erik.Nordmark@Sun.COM >> >> >> >> Subject: New Version Notification for draft-ietf-6lowpan-nd-08 >> >> >> A new version of I-D, draft-ietf-6lowpan-nd-08.txt has been >> successfuly submitted by Zach Shelby and posted to the IETF >> repository. >> >> Filename: draft-ietf-6lowpan-nd Revision: 08 Title: 6LoWPAN >> Neighbor Discovery Creation_date: 2010-02-01 WG ID: 6lowpan >> Number_of_pages: 46 >> >> Abstract: This document specifies a new Neighbor Discovery >> mechanism suitable for LoWPANs. The 6LoWPAN format allows IPv6 to >> be used over energy and bandwidth constrained wireless networks >> often making use of multihop topologies. However, the use of >> classic IPv6 Neighbor Discovery with 6LoWPAN has several problems. >> Classic Neighbor Discovery was not designed for non-transitive >> wireless links, and the traditional IPv6 link concept and heavy use >> of multicast makes it unpractical. This document specifies a >> simple Neighbor Discovery mechanism both sufficient yet minimal for >> LoWPAN operation. >> >> >> >> The IETF Secretariat. >> >> > From richard.kelsey@ember.com Wed Feb 17 10:17:07 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825FB28C175 for <6lowpan@core3.amsl.com>; Wed, 17 Feb 2010 10:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf+tXLTtxmMz for <6lowpan@core3.amsl.com>; Wed, 17 Feb 2010 10:17:06 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 17B913A7D7B for <6lowpan@ietf.org>; Wed, 17 Feb 2010 10:17:02 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Feb 2010 13:21:08 -0500 Date: Wed, 17 Feb 2010 13:06:07 -0500 Message-Id: <87mxz7visw.fsf@kelsey-ws.hq.ember.com> To: Owen Kirby In-reply-to: <4B7B0875.8060609@exegin.com> (message from Owen Kirby on Tue, 16 Feb 2010 13:04:53 -0800) From: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> X-OriginalArrivalTime: 17 Feb 2010 18:21:08.0734 (UTC) FILETIME=[F9E101E0:01CAAFFD] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 17 Feb 2010 18:17:07 -0000 > Date: Tue, 16 Feb 2010 13:04:53 -0800 > From: Owen Kirby > > However, I suspect that this assumption is no longer true > in the case of the draft header compression. Especially > now that IPv6 extension headers can be compressed (what do > we do if ROLL adds ~160 bytes of routing headers to a > packet?). Owen, A long source route could quite possibly push the transport header into the second fragment. > [...] We get stuck in a catch-22: can't > defragment until after decompression, but can't decompress > until after defragmentation. > > [...] It also becomes necessary to store the state of your > decompressor across multiple packets, which can get very ugly if header > fields get split across fragments. > > Either one of your recommended solutions would work, but if you want to > include the total number of fragments I would recommend that each packet > should also be identified by a sequence number. A simple, but less > efficient solution, could also be to simply state that any headers which > extend past the first fragment after compression should not be compressed. This could be tricky because the size of the compressed IP header and the MAC addressing and security overhead can change hop-by-hop. What was in the first fragment on the first hop may not be in the first fragment on a subsequent hop, which causes a problem if the forwarding node does not know how to uncompress the entire packet. I think that the best solution would be to switch to using the compressed size and offsets in the fragment headers. This would allow (un)compression and (de)fragmentation to be done independently. > Also, as the author of the 6LoWPAN dissectors for Wireshark, I'm pulling > my hair out trying to find a way to implement this without throwing away > all of Wireshark's reassembly support and starting from scratch, or > implementing some sort of wild speculative guessing. Would using the compressed size and offsets in the fragment headers solve this? -Richard Kelsey ---------------- This message and the information it contains are the proprietary and confidential property of Ember Corporation and may be privileged. If you are not the intended recipient, please do not read, copy, disclose or distribute its contents to any party, and notify the sender immediately. From osk@exegin.com Wed Feb 17 11:35:11 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44473A6818 for <6lowpan@core3.amsl.com>; Wed, 17 Feb 2010 11:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbaqFDvwCneX for <6lowpan@core3.amsl.com>; Wed, 17 Feb 2010 11:35:11 -0800 (PST) Received: from mail-px0-f188.google.com (mail-px0-f188.google.com [209.85.216.188]) by core3.amsl.com (Postfix) with ESMTP id 05E593A6A10 for <6lowpan@ietf.org>; Wed, 17 Feb 2010 11:35:10 -0800 (PST) Received: by pxi26 with SMTP id 26so7090236pxi.17 for <6lowpan@ietf.org>; Wed, 17 Feb 2010 11:36:47 -0800 (PST) Received: by 10.140.58.5 with SMTP id g5mr5568310rva.254.1266435407191; Wed, 17 Feb 2010 11:36:47 -0800 (PST) Received: from ?172.16.1.66? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 23sm3386595pzk.4.2010.02.17.11.36.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Feb 2010 11:36:46 -0800 (PST) Message-ID: <4B7C454C.2090403@exegin.com> Date: Wed, 17 Feb 2010 11:36:44 -0800 From: Owen Kirby Organization: Exegin Technologies Limited User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87mxz7visw.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 17 Feb 2010 19:35:11 -0000 Richard, Richard Kelsey wrote: >> Date: Tue, 16 Feb 2010 13:04:53 -0800 >> From: Owen Kirby >> >> Either one of your recommended solutions would work, but if you want to >> include the total number of fragments I would recommend that each packet >> should also be identified by a sequence number. A simple, but less >> efficient solution, could also be to simply state that any headers which >> extend past the first fragment after compression should not be compressed. >> > This could be tricky because the size of the compressed IP > header and the MAC addressing and security overhead can > change hop-by-hop. What was in the first fragment on the > first hop may not be in the first fragment on a subsequent > hop, which causes a problem if the forwarding node does > not know how to uncompress the entire packet. > Perhaps I could use a little clarification on how reassembly and forwarding would work in a 6LoWPAN mesh. Please correct me if I've gotten anything wrong here. In a route-over network, the IPv6 packet would need to be reassembled and decompressed at every hop to decrement TTL and check the routing headers. In this case, the forwarding node has control over all of the fields and can change a compressed field into an uncompressed field (and vice-versa) for the next hop in the route. As I suggested, this is not the most efficient solution, but it works and requires the least amount of change from what's in the RFC. In the mesh-under case, the fragments get routed across the network using the mesh routing header in RFC4944, and reassembly only happens at the packet's final destination, the contents of the fragments can't be modified in-flight anyways, so I don't see how this would cause a problem, and changes in the MTU are something that the source would need to allow for anyways. FWIW, all of the 6LoWPAN implementations I know of work on the assumption that compressed headers are always contained within the first fragment only. > I think that the best solution would be to switch to using > the compressed size and offsets in the fragment headers. > This would allow (un)compression and (de)fragmentation to > be done independently. > I absolutely agree. >> Also, as the author of the 6LoWPAN dissectors for Wireshark, I'm pulling >> my hair out trying to find a way to implement this without throwing away >> all of Wireshark's reassembly support and starting from scratch, or >> implementing some sort of wild speculative guessing. >> > Would using the compressed size and offsets in the fragment > headers solve this? > Yes, this change would be very easy to implement. Thanks, Owen Kirby From adam@sics.se Wed Feb 17 12:38:24 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F753A7F18; Wed, 17 Feb 2010 12:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjn+GheK3YLF; Wed, 17 Feb 2010 12:38:23 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 84C703A7F14; Wed, 17 Feb 2010 12:38:23 -0800 (PST) Received: from [10.1.1.143] (unknown [10.1.1.143]) by letter.sics.se (Postfix) with ESMTPS id C801440103; Wed, 17 Feb 2010 21:40:01 +0100 (CET) Message-ID: <4B7C534B.1050404@sics.se> Date: Wed, 17 Feb 2010 21:36:27 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ROLL WG , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] ACM HotEmNets: deadline extended, paper submission open X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 17 Feb 2010 20:38:24 -0000 The paper submission deadline for HotEmNets 2010 has been extended due to several requests: New deadline: 1 March 2010 Paper submission is now open: https://www.easychair.org/login.cgi?conf=hotemnets2010 HotEMNETS 2010 - 6th Workshop on Hot Topics in Embedded Networked Sensors http://www.hotemnets2010.org/ The Sixth Workshop on Hot Topics in Embedded Networked Sensors (HotEmNets 2010) brings together wireless sensor network researchers from academic and industrial backgrounds to present groundbreaking results that will shed light on present and future research challenges. The workshop emphasizes results from experiments or deployments that quantify the challenges in the wireless sensor systems of today as well as early results from new ideas that introduce promising approaches that will define the challenges in the wireless sensor systems of tomorrow. We especially welcome papers reporting on results that refute common assumptions, deployment experiences, novel and original approaches, and, more generally, papers that will help inform and guide research. Attendance to HotEmNets 2010 will be by invitation only, but everyone is encouraged to submit papers. Authors of accepted papers, TPC and SC members as well as other distinguished members of the community will be invited to enable a focused and productive discussion. Topics of interest include, but are not limited to: * Validation/refutation of prior results * Applications beyond data collection * Application experiences: measurements, lessons learned * Future applications: requirements and challenges * Integration of sensor networks and IP networks * Hardware platforms, tradeoffs, and trends * Data and network storage * Delay-tolerant networking * Management, debugging, and troubleshooting * Network and software reliability * Network and system architectures * Software bug detection and tools * Energy sources, scavenging, and low-power operation * Human-Computer interfaces for sensor nets Important Dates DEADLINE EXTENDED: March 1, 2010 Notification: April 15, 2010 Camera Ready: May 10, 2010 Conference: June 28-29, 2010 Workshop Venue Killarney, Ireland General Chair: Dirk Pesch, Cork Institute of Technology Program Co-Chairs: Adam Dunkels, SICS Akos Ledeczi, Vanderbilt University Publications Chair: Antonio Ruzzelli, University College Dublin TPC: Philippe Bonnet, IT University of Copenhagen, Denmark Niru Bulusu, Portland State University, USA Prabal Dutta, University of Michigan, USA Mary Ann Ingram, Georgia Tech, USA Utz Rödig, Lancaster University, UK Kay Römer, University of Lübeck, Germany Janos Sallai, Vanderbilt University, USA Andreas Terzis, Johns Hopkins University, USA Roberto Verdone, University of Bologna, Italy Kamin Whitehouse, University of Virginia, USA Feng Zhao, Microsoft Research, China Steering Committee: Sanjay Jha (chair), UNSW Cormac Sreenan, Uni. College Cork John Heidemann, USC/ISI Andrew Campbell, Dartmouth College Nirupama Bulusu, PSU -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From richard.kelsey@ember.com Wed Feb 17 12:45:13 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7AB28C236 for <6lowpan@core3.amsl.com>; Wed, 17 Feb 2010 12:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oj9T4cfzvRk for <6lowpan@core3.amsl.com>; Wed, 17 Feb 2010 12:45:13 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D6DCC28C0EF for <6lowpan@ietf.org>; Wed, 17 Feb 2010 12:45:12 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Feb 2010 15:49:19 -0500 Date: Wed, 17 Feb 2010 15:34:16 -0500 Message-Id: <87k4ubvbxz.fsf@kelsey-ws.hq.ember.com> To: Owen Kirby In-reply-to: <4B7C454C.2090403@exegin.com> (message from Owen Kirby on Wed, 17 Feb 2010 11:36:44 -0800) From: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> <4B7C454C.2090403@exegin.com> X-OriginalArrivalTime: 17 Feb 2010 20:49:19.0265 (UTC) FILETIME=[AD0C6110:01CAB012] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 17 Feb 2010 20:45:14 -0000 Owen, > Date: Wed, 17 Feb 2010 11:36:44 -0800 > From: Owen Kirby > > In a route-over network, the IPv6 packet would need to be reassembled > and decompressed at every hop to decrement TTL and check the routing > headers. In theory, only the IPv6 header and any routing headers need to be uncompressed at each hop. The transport header should not need to be uncompressed until the destination is reached. > In this case, the forwarding node has control over all of the > fields and can change a compressed field into an uncompressed field (and > vice-versa) for the next hop in the route. As I suggested, this is not > the most efficient solution, but it works and requires the least amount > of change from what's in the RFC. Isn't that how RFC 4944 works today? What needs to be changed? It works as long as the relaying node is able to completely uncompress the packet. Should anyone want to add a new transport header compression later on, such as for TCP, existing devices would not be able to relay packets that used the new compression. This is the forward-compatibility problem that was the subject of my original message. The use of the uncompressed length and offsets in the fragment headers adds a lot of implementation complexity, but I do think that it works, as long as relaying nodes understand all of the compressions being used. In other words, while changing the fragmentation to make it simpler to implement would be nice, forward compatibility is the reason that I think we must do so. > In the mesh-under case, the fragments get routed across the network > using the mesh routing header in RFC4944, and reassembly only happens at > the packet's final destination, the contents of the fragments can't be > modified in-flight anyways, so I don't see how this would cause a > problem, and changes in the MTU are something that the source would need > to allow for anyways. Mesh-under networks do not necessarily use the mesh routing header in RFC4944. I suspect that similar problems could come up in a mesh-under network, depending on the details of how forwarding is accomplished. > FWIW, all of the 6LoWPAN implementations I know of work on the > assumption that compressed headers are always contained within the first > fragment only. As you pointed out earlier, that probably isn't a safe assumption when using the HC draft. In particular, source routes could easily push some or all of a compressed header into the second fragment. -Richard Kelsey From daniel.gavelle@jennic.com Thu Feb 18 04:32:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7603A7CD1 for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 04:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZo-HBSkYRQU for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 04:32:35 -0800 (PST) Received: from mail.jennic.com (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id 4F5DC3A77C5 for <6lowpan@ietf.org>; Thu, 18 Feb 2010 04:32:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 72D7CD6BB3; Thu, 18 Feb 2010 12:34:15 +0000 (GMT) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUfR7M-mFChS; Thu, 18 Feb 2010 12:34:15 +0000 (GMT) Received: from [10.99.98.20] (dgave.jennic.com [10.99.98.20]) by mail.jennic.com (Postfix) with ESMTP id 51415D6BB1; Thu, 18 Feb 2010 12:34:15 +0000 (GMT) Message-ID: <4B7D33C7.2070306@jennic.com> Date: Thu, 18 Feb 2010 12:34:15 +0000 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87mxz7visw.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org, Wayne Ellis Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 12:32:36 -0000 The main problems with the existing RFC4944 / HC-06 draft when the compressed data can extend over more than one header are:- (1) Detecting the subsequent fragments are compressed. (2) That it is not possible to detect the final fragment by (dgram_offset + fragment size == dgram_size). These problems can solved by creating new dispatch codes. We currently have 11 000 for first fragment FRAG1 and 11 100 for subsequent fragments FRAGN. A new code can be created for a subsequent fragment that contains compressed header information, e.g. 11 101 FRAGC. The problem of detecting the final fragment does not occur for implementations that use a bit map manager. A new final fragment code of 11 110 FRAGF can be added to assist implementations that detect the final fragment by (dgram_offset + fragment size == dgram_size). Changing the datagram_size and datagram_offset to refer to the compressed rather than the uncompressed sizes causes the following problems:- (a) It would force major changes on existing implementations. It would also completely break any compatibility with existing fragmentation code which has already been developed by contributors on this list. (b) It will make determination of whether a packet is complete more difficult for implementations which use a bitmap based on uncompressed offsets. (c) Storing the entire packet before decode / forwarding should be an implementation choice rather than something that is enforced because of the way the standard is written. Copying from one buffer to another is wasteful and not a luxury that an embedded engineer can count on, PC implementations aren't going to feel the pain in the same way. It is important that 6LP can be implemented in real-time with a minimum of buffer copies - all that is needed is a buffer capable of storing 2 (or more) fragments to get the system working when header creep is detected. When forwarding packets, a router node may need to deal with several packets at once and may not have space to fully buffer each IP datagram. (d) In the most common case, there is only fragmentation in the first header and then many fragments of uncompressed UDP payload. The existing method of specifying the uncompressed offset allows this UDP payload to be stored in the correct location as the incoming data arrives. (e) Forwarding unknown headers through router nodes in a route over implementation can be solved whether the length and offset are stored compressed or uncompressed. There are different advantages in this case with either method so we shouldn't let this cloud the issue. (f) Not knowing the full uncompressed datagram size until the entire packet has been decoded also has implications for ICMP error handling, e.g. MTU exceeded. Daniel. __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ Richard Kelsey wrote: >> Date: Tue, 16 Feb 2010 13:04:53 -0800 >> From: Owen Kirby >> >> However, I suspect that this assumption is no longer true >> in the case of the draft header compression. Especially >> now that IPv6 extension headers can be compressed (what do >> we do if ROLL adds ~160 bytes of routing headers to a >> packet?). > > Owen, > > A long source route could quite possibly push the transport > header into the second fragment. > >> [...] We get stuck in a catch-22: can't >> defragment until after decompression, but can't decompress >> until after defragmentation. >> >> [...] It also becomes necessary to store the state of your >> decompressor across multiple packets, which can get very ugly if header >> fields get split across fragments. >> >> Either one of your recommended solutions would work, but if you want to >> include the total number of fragments I would recommend that each packet >> should also be identified by a sequence number. A simple, but less >> efficient solution, could also be to simply state that any headers which >> extend past the first fragment after compression should not be compressed. > > This could be tricky because the size of the compressed IP > header and the MAC addressing and security overhead can > change hop-by-hop. What was in the first fragment on the > first hop may not be in the first fragment on a subsequent > hop, which causes a problem if the forwarding node does > not know how to uncompress the entire packet. > > I think that the best solution would be to switch to using > the compressed size and offsets in the fragment headers. > This would allow (un)compression and (de)fragmentation to > be done independently. > >> Also, as the author of the 6LoWPAN dissectors for Wireshark, I'm pulling >> my hair out trying to find a way to implement this without throwing away >> all of Wireshark's reassembly support and starting from scratch, or >> implementing some sort of wild speculative guessing. > > Would using the compressed size and offsets in the fragment > headers solve this? > -Richard Kelsey > > ---------------- > This message and the information it contains are the proprietary > and confidential property of Ember Corporation and may be privileged. > If you are not the intended recipient, please do not read, copy, > disclose or distribute its contents to any party, and notify the > sender immediately. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- From jhui@archrock.com Thu Feb 18 08:22:39 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B5C28C108 for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 08:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYSGUDRdZcr4 for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 08:22:38 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 55C723A7EEB for <6lowpan@ietf.org>; Thu, 18 Feb 2010 08:22:38 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 949D9AF996; Thu, 18 Feb 2010 08:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObmfBTBRq65s; Thu, 18 Feb 2010 08:24:17 -0800 (PST) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 411E0AF842; Thu, 18 Feb 2010 08:24:17 -0800 (PST) Message-Id: From: Jonathan Hui To: daniel.gavelle@jennic.com In-Reply-To: <4B7D33C7.2070306@jennic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Feb 2010 08:24:16 -0800 References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> <4B7D33C7.2070306@jennic.com> X-Mailer: Apple Mail (2.936) Cc: Wayne Ellis , 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 18 Feb 2010 16:22:39 -0000 I think that changing offset and length to indicate the *compressed* values is the best way forward. It is architecturally clean because it preserves the layering - the only information needed to generate fragments is the data and length. RFC 4944's use of uncompressed values requires the fragmentation layer to be aware of the specific header compression in use and creates dependencies, which is the primary cause of the issues described by Richard and Owen. The primary downsides that I see are the following: - Using compressed values does mean that a memmove() operation is likely when expanding the payload, but a memmove() on ~1K bytes does not represent a bottleneck relative to the 15.4 radios in use today. - The receiver no longer knows how much buffer to allocate in order to store the fully expanded payload (if that is what the implementation wants to do). Fortunately, the forwarding nodes are only concerned with L3 headers and the size difference is currently limited to the IPv6 header itself. Of course, the size difference on the final destination could be arbitrary depending on what other upper-layer compression is in use. We could include a expanded size field in each fragment, but I'm not sure the overhead outweighs the benefits. - Breaks existing implementations - I don't think we should be terribly concerned with this - most of the implementation work going on in the world is happening right now, standards at all layers of the stack are still being defined. I would suggest placing the appropriate text for whatever we decide on into the 6lowpan-hc draft. The draft already updates RFC 4944 and the change is relevant to how 6lowpan-hc is defined. I see this as the quickest way forward even though we would have to reset the WGLC on it. Another issue that comes up with Richard's forward compatibility concerns is handling of ICMPv6 errors - specifically, when a forwarder needs to generate an error, what should it include in the ICMPv6 payload? Though I think this should be left for a different thread. -- Jonathan Hui On Feb 18, 2010, at 4:34 AM, Daniel Gavelle wrote: > The main problems with the existing RFC4944 / HC-06 draft when the > compressed data can extend over more than one header are:- > > (1) Detecting the subsequent fragments are compressed. > > (2) That it is not possible to detect the final fragment by > (dgram_offset + fragment size == dgram_size). > > These problems can solved by creating new dispatch codes. > > We currently have 11 000 for first fragment FRAG1 and 11 100 for > subsequent fragments FRAGN. A new code can be created for a > subsequent fragment that contains compressed header information, > e.g. 11 101 FRAGC. > > The problem of detecting the final fragment does not occur for > implementations that use a bit map manager. A new final fragment > code of 11 110 FRAGF can be added to assist implementations that > detect the final fragment by (dgram_offset + fragment size == > dgram_size). > > Changing the datagram_size and datagram_offset to refer to the > compressed rather than the uncompressed sizes causes the following > problems:- > > (a) It would force major changes on existing implementations. It > would also completely break any compatibility with existing > fragmentation code which has already been developed by contributors > on this list. > > (b) It will make determination of whether a packet is complete more > difficult for implementations which use a bitmap based on > uncompressed offsets. > > (c) Storing the entire packet before decode / forwarding should be > an implementation choice rather than something that is enforced > because of the way the standard is written. Copying from one buffer > to another is wasteful and not a luxury that an embedded engineer > can count on, PC implementations aren't going to feel the pain in > the same way. It is important that 6LP can be implemented in real- > time with a minimum of buffer copies - all that is needed is a > buffer capable of storing 2 (or more) fragments to get the system > working when header creep is detected. When forwarding packets, a > router node may need to deal with several packets at once and may > not have space to fully buffer each IP datagram. > > (d) In the most common case, there is only fragmentation in the > first header and then many fragments of uncompressed UDP payload. > The existing method of specifying the uncompressed offset allows > this UDP payload to be stored in the correct location as the > incoming data arrives. > > (e) Forwarding unknown headers through router nodes in a route over > implementation can be solved whether the length and offset are > stored compressed or uncompressed. There are different advantages in > this case with either method so we shouldn't let this cloud the issue. > > (f) Not knowing the full uncompressed datagram size until the entire > packet has been decoded also has implications for ICMP error > handling, e.g. MTU exceeded. > > Daniel. > > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK > Comp Reg No: 3191371 Registered In England > http://www.jennic.com > __________________________________________________ > > > Richard Kelsey wrote: >>> Date: Tue, 16 Feb 2010 13:04:53 -0800 >>> From: Owen Kirby >>> >>> However, I suspect that this assumption is no longer true >>> in the case of the draft header compression. Especially >>> now that IPv6 extension headers can be compressed (what do >>> we do if ROLL adds ~160 bytes of routing headers to a >>> packet?). >> Owen, >> A long source route could quite possibly push the transport >> header into the second fragment. >>> [...] We get stuck in a catch-22: can't >>> defragment until after decompression, but can't decompress >>> until after defragmentation. >>> >>> [...] It also becomes necessary to store the state of your >>> decompressor across multiple packets, which can get very ugly if >>> header fields get split across fragments. >>> >>> Either one of your recommended solutions would work, but if you >>> want to include the total number of fragments I would recommend >>> that each packet should also be identified by a sequence number. >>> A simple, but less efficient solution, could also be to simply >>> state that any headers which extend past the first fragment after >>> compression should not be compressed. >> This could be tricky because the size of the compressed IP >> header and the MAC addressing and security overhead can >> change hop-by-hop. What was in the first fragment on the >> first hop may not be in the first fragment on a subsequent >> hop, which causes a problem if the forwarding node does >> not know how to uncompress the entire packet. >> I think that the best solution would be to switch to using >> the compressed size and offsets in the fragment headers. >> This would allow (un)compression and (de)fragmentation to >> be done independently. >>> Also, as the author of the 6LoWPAN dissectors for Wireshark, I'm >>> pulling my hair out trying to find a way to implement this without >>> throwing away all of Wireshark's reassembly support and starting >>> from scratch, or implementing some sort of wild speculative >>> guessing. >> Would using the compressed size and offsets in the fragment >> headers solve this? >> -Richard Kelsey >> ---------------- >> This message and the information it contains are the proprietary >> and confidential property of Ember Corporation and may be privileged. >> If you are not the intended recipient, please do not read, copy, >> disclose or distribute its contents to any party, and notify the >> sender immediately. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > -- > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Thu Feb 18 08:33:25 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE5D28C108 for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 08:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.804 X-Spam-Level: X-Spam-Status: No, score=-9.804 tagged_above=-999 required=5 tests=[AWL=0.795, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkhiifhTLj0P for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 08:33:23 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4EB5D3A7AEC for <6lowpan@ietf.org>; Thu, 18 Feb 2010 08:33:23 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAJH6fEuQ/uCWe2dsb2JhbACbBxUBARYkBh2lcopbCY0XgmSCAwQ X-IronPort-AV: E=Sophos;i="4.49,498,1262563200"; d="scan'208";a="57289877" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Feb 2010 16:35:05 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1IGZ4hw027714; Thu, 18 Feb 2010 16:35:05 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 17:35:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Feb 2010 17:34:55 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0149A84E@XMB-AMS-107.cisco.com> In-Reply-To: <4B7D33C7.2070306@jennic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] RFC 4944 fragmentation and future extensions Thread-Index: AcqwlrXc6LjnSOU4SiGkRShRmqkxTQAF4VMw References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com><87mxz7visw.fsf@kelsey-ws.hq.ember.com> <4B7D33C7.2070306@jennic.com> From: "Pascal Thubert (pthubert)" To: , "Richard Kelsey" X-OriginalArrivalTime: 18 Feb 2010 16:35:05.0023 (UTC) FILETIME=[533984F0:01CAB0B8] Cc: Wayne Ellis , 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 18 Feb 2010 16:33:25 -0000 Hi Daniel, Richard and Owen: There are a number of reasons why the fragmentation in RFC 4944 is broken. Richard has just identified a new one. The traditional problem of loss of fragment is another that might actually hurt a lot sooner. It is time that we rework the fragment in the light of this experience and without the need to be backward compatible but rather forward compatible. We did that for HC already. http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recover y already has the sequence that Owen has been asking for, for the purpose of recovering fragments.=20 It also has an all zeroes ack bitmap that enables the receiver to let the sender know that the packet is dropped so stop sending fragments for it; this can be used if the receiver fails to parse a compressed header. It is compatible with a route over model where fragments are forwarded without full recomposition ( see http://www.mail-archive.com/6lowpan@ietf.org/msg01828.html ). So my suggestion would be to work on that draft to make it achieve what you're looking for. What do you think? Pascal -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Daniel Gavelle Sent: Thursday, February 18, 2010 1:34 PM To: Richard Kelsey Cc: 6lowpan@ietf.org; Wayne Ellis Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions The main problems with the existing RFC4944 / HC-06 draft when the compressed data can extend over more than one header are:- (1) Detecting the subsequent fragments are compressed. (2) That it is not possible to detect the final fragment by (dgram_offset + fragment size =3D=3D dgram_size). These problems can solved by creating new dispatch codes. We currently have 11 000 for first fragment FRAG1 and 11 100 for subsequent fragments FRAGN. A new code can be created for a subsequent fragment that contains compressed header information, e.g. 11 101 FRAGC. The problem of detecting the final fragment does not occur for implementations that use a bit map manager. A new final fragment code of 11 110 FRAGF can be added to assist implementations that detect the final fragment by (dgram_offset + fragment size =3D=3D dgram_size). Changing the datagram_size and datagram_offset to refer to the compressed rather than the uncompressed sizes causes the following problems:- (a) It would force major changes on existing implementations. It would also completely break any compatibility with existing fragmentation code which has already been developed by contributors on this list. (b) It will make determination of whether a packet is complete more difficult for implementations which use a bitmap based on uncompressed offsets. (c) Storing the entire packet before decode / forwarding should be an implementation choice rather than something that is enforced because of the way the standard is written. Copying from one buffer to another is wasteful and not a luxury that an embedded engineer can count on, PC implementations aren't going to feel the pain in the same way. It is important that 6LP can be implemented in real-time with a minimum of buffer copies - all that is needed is a buffer capable of storing 2 (or more) fragments to get the system working when header creep is detected. When forwarding packets, a router node may need to deal with several packets at once and may not have space to fully buffer each IP datagram. (d) In the most common case, there is only fragmentation in the first header and then many fragments of uncompressed UDP payload. The existing method of specifying the uncompressed offset allows this UDP payload to be stored in the correct location as the incoming data arrives. (e) Forwarding unknown headers through router nodes in a route over implementation can be solved whether the length and offset are stored compressed or uncompressed. There are different advantages in this case with either method so we shouldn't let this cloud the issue. (f) Not knowing the full uncompressed datagram size until the entire packet has been decoded also has implications for ICMP error handling, e.g. MTU exceeded. Daniel. __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ Richard Kelsey wrote: >> Date: Tue, 16 Feb 2010 13:04:53 -0800 >> From: Owen Kirby >> >> However, I suspect that this assumption is no longer true in the case >> of the draft header compression. Especially now that IPv6 extension=20 >> headers can be compressed (what do we do if ROLL adds ~160 bytes of=20 >> routing headers to a packet?). >=20 > Owen, >=20 > A long source route could quite possibly push the transport header=20 > into the second fragment. >=20 >> [...] We get stuck in a catch-22: can't defragment until after=20 >> decompression, but can't decompress until after defragmentation. >> >> [...] It also becomes necessary to store the state of your=20 >> decompressor across multiple packets, which can get very ugly if=20 >> header fields get split across fragments. >> >> Either one of your recommended solutions would work, but if you want=20 >> to include the total number of fragments I would recommend that each=20 >> packet should also be identified by a sequence number. A simple, but >> less efficient solution, could also be to simply state that any=20 >> headers which extend past the first fragment after compression should not be compressed. >=20 > This could be tricky because the size of the compressed IP header and=20 > the MAC addressing and security overhead can change hop-by-hop. What=20 > was in the first fragment on the first hop may not be in the first=20 > fragment on a subsequent hop, which causes a problem if the forwarding > node does not know how to uncompress the entire packet. >=20 > I think that the best solution would be to switch to using the=20 > compressed size and offsets in the fragment headers. > This would allow (un)compression and (de)fragmentation to be done=20 > independently. >=20 >> Also, as the author of the 6LoWPAN dissectors for Wireshark, I'm=20 >> pulling my hair out trying to find a way to implement this without=20 >> throwing away all of Wireshark's reassembly support and starting from >> scratch, or implementing some sort of wild speculative guessing. >=20 > Would using the compressed size and offsets in the fragment headers=20 > solve this? > -Richard Kelsey >=20 > ---------------- > This message and the information it contains are the proprietary and=20 > confidential property of Ember Corporation and may be privileged. > If you are not the intended recipient, please do not read, copy,=20 > disclose or distribute its contents to any party, and notify the=20 > sender immediately. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 -- _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From dat@exegin.com Thu Feb 18 13:05:39 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6755728C19F for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 13:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ07z9a2lR3U for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 13:05:38 -0800 (PST) Received: from mail-pz0-f190.google.com (mail-pz0-f190.google.com [209.85.222.190]) by core3.amsl.com (Postfix) with ESMTP id 9B11528C18D for <6lowpan@ietf.org>; Thu, 18 Feb 2010 13:05:38 -0800 (PST) Received: by pzk28 with SMTP id 28so11087167pzk.31 for <6lowpan@ietf.org>; Thu, 18 Feb 2010 13:07:19 -0800 (PST) Received: by 10.142.55.13 with SMTP id d13mr6815889wfa.50.1266527239548; Thu, 18 Feb 2010 13:07:19 -0800 (PST) Received: from ?172.16.1.52? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 21sm11659605pzk.15.2010.02.18.13.07.17 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 13:07:18 -0800 (PST) Message-ID: <4B7DAC04.5070109@exegin.com> Date: Thu, 18 Feb 2010 13:07:16 -0800 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Owen Kirby References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> <4B7C454C.2090403@exegin.com> In-Reply-To: <4B7C454C.2090403@exegin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 18 Feb 2010 21:05:39 -0000 Richard and Owen, > >> I think that the best solution would be to switch to using >> the compressed size and offsets in the fragment headers. >> This would allow (un)compression and (de)fragmentation to >> be done independently. >> > I absolutely agree. > I agree. I think it should be simplified further by making datagram_offset 11bits long. Having datagram_offset as 8bits (forcing fragment length to a multiple of 8) may save 1 byte, but it also means that up to 7 bytes at the end of a fragment can be left unused (save 1 byte to, potentially, lose 7). So how about a new fragmentation header where both datagram_size and datagram_offset are 11bits and the datagram_tag is reduced to 13bits (how big does the tag need to be anyway). A new dispatch pattern would indicate a new fragmentation header where _offset and _size are relative to the compressed datagram. Something like the following: 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 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1| datagram_size | datagram_tag | datagram_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From an implementation point of view, bits 0 to 28 can be used as a pseudo tag in identifying fragments that belong to one datagram. It could be stored in 4 bytes with the last three bits of the last byte masked out, but that's just an idea for trying to be a little more efficient. Regards Dario From jhui@archrock.com Thu Feb 18 13:47:03 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7BE28C0ED for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 13:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLK8X+cCI4Gz for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 13:47:02 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id E37013A7B99 for <6lowpan@ietf.org>; Thu, 18 Feb 2010 13:47:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id EEB6EAF94A; Thu, 18 Feb 2010 13:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPP2tbuQTvyK; Thu, 18 Feb 2010 13:48:43 -0800 (PST) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id EEAAFAF99F; Thu, 18 Feb 2010 13:48:42 -0800 (PST) Message-Id: From: Jonathan Hui To: Dario Tedeschi In-Reply-To: <4B7DAC04.5070109@exegin.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Feb 2010 13:48:41 -0800 References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> <4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 18 Feb 2010 21:47:03 -0000 Hi Dario, I support the effort to make the offset field be in units of single octets, rather than 8 octets. Though we need to be careful about shrinking the tag field. Earlier drafts of RFC 4944 originally made the tag field 10 bits, but some comments from IESG review raised concerns about whether that was enough. After some discussion on the list, the decision was made to expand the field to 16 bits (though only 14 bits was necessary at the time) [1]. The key point is that 802.15.4 may operate on different PHYs with higher bit rates so we should be prepared for those. In my ideal world, we would reallocate a single fragment header type for simplicity. I'm not concerned about backwards compatibility given that we are changing the entire HC format. And little has been done in the way of multi-vendor interoperability with the existing formats. In that case, we include the tag, size, and offset fields in every fragment while keeping the tag 16 bits and others 11 bits. The header type would remain at two bits with '11'. Eliding the offset field in the first fragment doesn't give much added benefit. To me, the above is the most straight-forward approach - maintaining most of the existing format structure, while at the same time simplifying it and avoids revisiting the same IESG concerns we've had in the past. An alternate approach is to pick up on existing work to redesign the fragmentation layer to support more efficient fragment recovery and out-of-order delivery, but that would require a bigger change. I'd echo Pascal's request to get additional thoughts there. [1] http://www.ietf.org/mail-archive/web/6lowpan/current/msg00588.html -- Jonathan Hui On Feb 18, 2010, at 1:07 PM, Dario Tedeschi wrote: > Richard and Owen, > >> >>> I think that the best solution would be to switch to using >>> the compressed size and offsets in the fragment headers. >>> This would allow (un)compression and (de)fragmentation to >>> be done independently. >>> >> I absolutely agree. >> > I agree. > > I think it should be simplified further by making datagram_offset > 11bits long. Having datagram_offset as 8bits (forcing fragment > length to a multiple of 8) may save 1 byte, but it also means that > up to 7 bytes at the end of a fragment can be left unused (save 1 > byte to, potentially, lose 7). So how about a new fragmentation > header where both datagram_size and datagram_offset are 11bits and > the datagram_tag is reduced to 13bits (how big does the tag need to > be anyway). A new dispatch pattern would indicate a new > fragmentation header where _offset and _size are relative to the > compressed datagram. Something like the following: > > 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 2 3 > 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+-+-+-+-+ > |1 1 1 1 1| datagram_size | datagram_tag | > datagram_offset | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+-+-+-+-+ > > > From an implementation point of view, bits 0 to 28 can be used as a > pseudo tag in identifying fragments that belong to one datagram. It > could be stored in 4 bytes with the last three bits of the last byte > masked out, but that's just an idea for trying to be a little more > efficient. > > Regards > Dario > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From dat@exegin.com Thu Feb 18 17:09:20 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D873A7E08 for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 17:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYPd-gT7MTSY for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 17:09:18 -0800 (PST) Received: from mail-pz0-f190.google.com (mail-pz0-f190.google.com [209.85.222.190]) by core3.amsl.com (Postfix) with ESMTP id AE4DD28C194 for <6lowpan@ietf.org>; Thu, 18 Feb 2010 17:08:45 -0800 (PST) Received: by pzk28 with SMTP id 28so11325663pzk.31 for <6lowpan@ietf.org>; Thu, 18 Feb 2010 17:10:27 -0800 (PST) Received: by 10.141.23.20 with SMTP id a20mr6824937rvj.193.1266541827022; Thu, 18 Feb 2010 17:10:27 -0800 (PST) Received: from ?172.16.1.52? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 22sm10569728pzk.1.2010.02.18.17.10.25 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 17:10:26 -0800 (PST) Message-ID: <4B7DE500.1060607@exegin.com> Date: Thu, 18 Feb 2010 17:10:24 -0800 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Hui References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> <4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 01:09:20 -0000 Hi Jonathan

Jonathan Hui wrote:

Hi Dario,

I support the effort to make the offset field be in units of single octets, rather than 8 octets.  Though we need to be careful about shrinking the tag field.  Earlier drafts of RFC 4944 originally made the tag field 10 bits, but some comments from IESG review raised concerns about whether that was enough.  After some discussion on the list, the decision was made to expand the field to 16 bits (though only 14 bits was necessary at the time) [1].  The key point is that 802.15.4 may operate on different PHYs with higher bit rates so we should be prepared for those.
What kind of future bit rates are expected? Isn't it also possible that even a 16bit tag might not be enough in the future, if bit rates increase enough. My point here, is that I think the tag size is somewhat subjective depending on who you talk to and how much of the future one tries to predict.

Here's a rough calculation of the time it would take for the tag value in one node to rollover based on worst case packet sizes (i.e. smallest) and a 1Mb/s bit rate:
1st Packet Size = 128 bytes (PHY + MAC + Frag Hdr + HC + data + FCS)
2nd Packet Size = 18 bytes (PHY + MAC{short addrs} + Frag Hdr + 1 + FCS)
Total bytes sent for one datagram = 128 + 18 = 146
Total bits sent = 146 x 8 = 1168
Bit Rate = 1Mb/s
Time to send one datagram = 1168 / 1Mb/s =~ 1.168ms
**** Assuming datagrams are continuously sent from one source without delays (unlikely, but lets ignore any delays for now).
Time for 16bit tag field to rollover = 65536 * 1.168ms = 77s
Time for 13bit tag field to rollover = 8192 * 1.168ms = 10s

So is a 9 second rollover at 1Mb/s not sufficient as a worst case? I think it would be OK. Also, if we see bit-rates for PHYs increase we may also see an increase in allowable packet sizes (one can only hope :-).

However, if it means re-opening a heated debate or causing IESG problems, perhaps its best to stay with a 16bit tag and avoid wasting valuable time.

In my ideal world, we would reallocate a single fragment header type for simplicity.
I agree. An offset of 0 would indicate the first fragment, anyway (assuming one fragment header type for all fragments and the offset included).

  I'm not concerned about backwards compatibility given that we are changing the entire HC format.  And little has been done in the way of multi-vendor interoperability with the existing formats.  In that case, we include the tag, size, and offset fields in every fragment while keeping the tag 16 bits and others 11 bits.  The header type would remain at two bits with '11'.
Sounds plausible, except that I have two reservations:
  1. Having a dispatch pattern of '11xxxxxx' would overlay FRAG1, FRAGN and LOWPAN_NHC encoding in "draft...-hc-06". FRAG1 and FRAGN are of greater concern, because there would be no way of filtering out old fragment headers. I think in this case we'd want to remain backward compatible.
  2. The _size and _offset fields would no longer be octet aligned (assuming the same field order).

Eliding the offset field in the first fragment doesn't give much added benefit.
I agree.


To me, the above is the most straight-forward approach - maintaining most of the existing format structure, while at the same time simplifying it and avoids revisiting the same IESG concerns we've had in the past.

An alternate approach is to pick up on existing work to redesign the fragmentation layer to support more efficient fragment recovery and out-of-order delivery, but that would require a bigger change.  I'd echo Pascal's request to get additional thoughts there.

[1] http://www.ietf.org/mail-archive/web/6lowpan/current/msg00588.html

--
Jonathan Hui

On Feb 18, 2010, at 1:07 PM, Dario Tedeschi wrote:

Richard and Owen,


I think that the best solution would be to switch to using
the compressed size and offsets in the fragment headers.
This would allow (un)compression and (de)fragmentation to
be done independently.

I absolutely agree.

I agree.

I think it should be simplified further by making datagram_offset 11bits long. Having datagram_offset as 8bits (forcing fragment length to a multiple of 8) may save 1 byte, but it also means that up to 7 bytes at the end of a fragment can be left unused (save 1 byte to, potentially, lose 7). So how about a new fragmentation header where both datagram_size and datagram_offset are 11bits and the datagram_tag is reduced to 13bits (how big does the tag need to be anyway). A new dispatch pattern would indicate a new fragmentation header where _offset and _size are relative to the compressed datagram. Something like the following:

                     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 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1|    datagram_size    |      datagram_tag       |   datagram_offset   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


>From an implementation point of view, bits 0 to 28 can be used as a pseudo tag in identifying fragments that belong to one datagram. It could be stored in 4 bytes with the last three bits of the last byte masked out, but that's just an idea for trying to be a little more efficient.

Regards
Dario


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


From jhui@archrock.com Thu Feb 18 19:11:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 159A83A7A03 for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 19:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id purH1yBaS5P7 for <6lowpan@core3.amsl.com>; Thu, 18 Feb 2010 19:11:48 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id C38D13A78E1 for <6lowpan@ietf.org>; Thu, 18 Feb 2010 19:11:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8B411AF9BC; Thu, 18 Feb 2010 19:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ydrQV6KKMJ6; Thu, 18 Feb 2010 19:13:29 -0800 (PST) Received: from [10.0.1.5] (adsl-71-142-67-144.dsl.pltn13.pacbell.net [71.142.67.144]) by mail.sf.archrock.com (Postfix) with ESMTP id A3CB1AF846; Thu, 18 Feb 2010 19:13:28 -0800 (PST) Message-Id: <54359E42-F1B2-41B8-AD61-066B4DBA98B0@archrock.com> From: Jonathan Hui To: Dario Tedeschi In-Reply-To: <4B7DE500.1060607@exegin.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Feb 2010 19:13:27 -0800 References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> <4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <4B7DE500.1060607@exegin.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 03:11:50 -0000 Hi Dario, On Feb 18, 2010, at 5:10 PM, Dario Tedeschi wrote: >> I support the effort to make the offset field be in units of single =20= >> octets, rather than 8 octets. Though we need to be careful about =20 >> shrinking the tag field. Earlier drafts of RFC 4944 originally =20 >> made the tag field 10 bits, but some comments from IESG review =20 >> raised concerns about whether that was enough. After some =20 >> discussion on the list, the decision was made to expand the field =20 >> to 16 bits (though only 14 bits was necessary at the time) [1]. =20 >> The key point is that 802.15.4 may operate on different PHYs with =20 >> higher bit rates so we should be prepared for those. > What kind of future bit rates are expected? Isn't it also possible =20 > that even a 16bit tag might not be enough in the future, if bit =20 > rates increase enough. My point here, is that I think the tag size =20 > is somewhat subjective depending on who you talk to and how much of =20= > the future one tries to predict. When this WG chose to expand the tag field, we considered 2 Mbps 15.4a =20= PHY - see the archived thread that I linked. > Here's a rough calculation of the time it would take for the tag =20 > value in one node to rollover based on worst case packet sizes (i.e. =20= > smallest) and a 1Mb/s bit rate: > 1st Packet Size =3D 128 bytes (PHY + MAC + Frag Hdr + HC + data + FCS) > 2nd Packet Size =3D 18 bytes (PHY + MAC{short addrs} + Frag Hdr + 1 + =20= > FCS) > Total bytes sent for one datagram =3D 128 + 18 =3D 146 > Total bits sent =3D 146 x 8 =3D 1168 > Bit Rate =3D 1Mb/s > Time to send one datagram =3D 1168 / 1Mb/s =3D~ 1.168ms > **** Assuming datagrams are continuously sent from one source =20 > without delays (unlikely, but lets ignore any delays for now). > Time for 16bit tag field to rollover =3D 65536 * 1.168ms =3D 77s > Time for 13bit tag field to rollover =3D 8192 * 1.168ms =3D 10s > > So is a 9 second rollover at 1Mb/s not sufficient as a worst case? I =20= > think it would be OK. Also, if we see bit-rates for PHYs increase we =20= > may also see an increase in allowable packet sizes (one can only =20 > hope :-). This WG assumed a minimum roll-over period of 60 seconds - following =20 the parameters chosen by IPv6 reassembly - again, see the archived =20 thread. I could also see some scenarios where 9 seconds may not be =20 enough for some low-power protocols and/or mesh-under networks. > However, if it means re-opening a heated debate or causing IESG =20 > problems, perhaps its best to stay with a 16bit tag and avoid =20 > wasting valuable time. This is what I'm trying to avoid. >> In my ideal world, we would reallocate a single fragment header =20 >> type for simplicity. > I agree. An offset of 0 would indicate the first fragment, anyway =20 > (assuming one fragment header type for all fragments and the offset =20= > included). Right. >> I'm not concerned about backwards compatibility given that we are =20= >> changing the entire HC format. And little has been done in the way =20= >> of multi-vendor interoperability with the existing formats. In =20 >> that case, we include the tag, size, and offset fields in every =20 >> fragment while keeping the tag 16 bits and others 11 bits. The =20 >> header type would remain at two bits with '11'. > Sounds plausible, except that I have two reservations: > =95 Having a dispatch pattern of '11xxxxxx' would overlay FRAG1, = =20 > FRAGN and LOWPAN_NHC encoding in "draft...-hc-06". FRAG1 and FRAGN =20 > are of greater concern, because there would be no way of filtering =20 > out old fragment headers. I think in this case we'd want to remain =20 > backward compatible. I'm still not convinced on the *need* for backwards compatibility. =20 Another option is to take over the NALP value and require any non-IPv6 =20= protocol operating within a 6LoWPAN network to allocate a dispatch =20 value and respect the dispatch encoding. Are there people using the =20 NALP value and would they strongly oppose losing another 6 bits to =20 respect the dispatch encoding in order to fit in simplified fragment =20 header? > =95 The _size and _offset fields would no longer be octet = aligned =20 > (assuming the same field order). It's easy to fix some of that by reordering the fields to: offset | =20 size | tag. Again, this path is following the philosophy of simplifying the =20 existing fragmentation mechanism. I'm still looking for feedback on =20 whether people would like to see additional fragmentation mechanisms =20 at the risk of opening the flood gates. -- Jonathan Hui From pthubert@cisco.com Fri Feb 19 01:17:46 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99ABB28C1FB for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 01:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.883 X-Spam-Level: X-Spam-Status: No, score=-9.883 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZlnbkwSmaiE for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 01:17:44 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C54D928C1F5 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 01:17:44 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAF3mfUutJV2c/2dsb2JhbACBQplGdKRzmACEZwQ X-IronPort-AV: E=Sophos;i="4.49,502,1262563200"; d="scan'208,217";a="485377891" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-6.cisco.com with ESMTP; 19 Feb 2010 09:19:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o1J9JE7P020763; Fri, 19 Feb 2010 09:19:29 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 10:19:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB144.9CA99E81" Date: Fri, 19 Feb 2010 10:19:15 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0149A9E2@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] RFC 4944 fragmentation and future extensions Thread-Index: Acqw5C+5t+9U9xxbSVG5ymDzsvT+VAAWsnXA References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 19 Feb 2010 09:19:18.0294 (UTC) FILETIME=[9CF90B60:01CAB144] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 09:17:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAB144.9CA99E81 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan: =20 I agree we need to maintain the datagram tag to at least 16 bits. Another (key for me) reason is its potential use as a label for label switching fragments in a route over model. =20 Please find below the exercise of picking your proposal of 11 for fragments applied to the frag recovery draft. I agree with Dario that we should reserve 11X00 to avoid confusion, at least for a while. That could give us: =20 Forward fragment: ----------------- 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 F A 1| datagram_size | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sequence | datagram_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Where F would be (reserved for) Forward ECN and A ACK requested =20 Reply/ACK: ---------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 B 1 0 0|siz| datagram_tag | Ack Bitmap ...=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Where B would be (reserved for) Backward ECN, R set if error, and size used to encode the ack bitmap size (1 to 4 bytes). =20 The cool thing is that we do not need the complex bitmap encoding that was introduced recently to we could ack up to 32 fragments.=20 =20 =20 =20 Reply/NACK: ----------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 B 1 0 1|rsv| datagram_tag | error code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 =20 What do you think? =20 Pascal =20 =20 -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: Thursday, February 18, 2010 10:49 PM To: Dario Tedeschi Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions =20 =20 Hi Dario, =20 I support the effort to make the offset field be in units of single octets, rather than 8 octets. Though we need to be careful about shrinking the tag field. Earlier drafts of RFC 4944 originally made the tag field 10 bits, but some comments from IESG review raised concerns about whether that was enough. After some discussion on the list, the decision was made to expand the field to 16 bits (though only 14 bits was necessary at the time) [1]. The key point is that 802.15.4 may operate on different PHYs with higher bit rates so we should be prepared for those. =20 In my ideal world, we would reallocate a single fragment header type for simplicity. I'm not concerned about backwards compatibility given that we are changing the entire HC format. And little has been done in the way of multi-vendor interoperability with the existing formats. In that case, we include the tag, size, and offset fields in every fragment while keeping the tag 16 bits and others 11 bits. The header type would remain at two bits with '11'. Eliding the offset field in the first fragment doesn't give much added benefit. =20 To me, the above is the most straight-forward approach - maintaining most of the existing format structure, while at the same time simplifying it and avoids revisiting the same IESG concerns we've had in the past. =20 An alternate approach is to pick up on existing work to redesign the fragmentation layer to support more efficient fragment recovery and out-of-order delivery, but that would require a bigger change. I'd echo Pascal's request to get additional thoughts there. =20 [1] http://www.ietf.org/mail-archive/web/6lowpan/current/msg00588.html =20 =20 -- Jonathan Hui =20 On Feb 18, 2010, at 1:07 PM, Dario Tedeschi wrote: =20 > Richard and Owen, >=20 >>=20 >>> I think that the best solution would be to switch to using the=20 >>> compressed size and offsets in the fragment headers. >>> This would allow (un)compression and (de)fragmentation to be done=20 >>> independently. >>>=20 >> I absolutely agree. >>=20 > I agree. >=20 > I think it should be simplified further by making datagram_offset=20 > 11bits long. Having datagram_offset as 8bits (forcing fragment length=20 > to a multiple of 8) may save 1 byte, but it also means that up to 7=20 > bytes at the end of a fragment can be left unused (save 1 byte to,=20 > potentially, lose 7). So how about a new fragmentation header where=20 > both datagram_size and datagram_offset are 11bits and the datagram_tag > is reduced to 13bits (how big does the tag need to be anyway). A new=20 > dispatch pattern would indicate a new fragmentation header where=20 > _offset and _size are relative to the compressed datagram. Something=20 > like the following: >=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 2 3 > 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+-+-+-+-+ > |1 1 1 1 1| datagram_size | datagram_tag | =20 > datagram_offset | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+-+-+-+-+ >=20 >=20 > From an implementation point of view, bits 0 to 28 can be used as a=20 > pseudo tag in identifying fragments that belong to one datagram. It=20 > could be stored in 4 bytes with the last three bits of the last byte=20 > masked out, but that's just an idea for trying to be a little more=20 > efficient. >=20 > Regards > Dario >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org =20 > https://www.ietf.org/mailman/listinfo/6lowpan =20 =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org =20 https://www.ietf.org/mailman/listinfo/6lowpan =20 ------_=_NextPart_001_01CAB144.9CA99E81 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jonathan:

 

I agree we need to maintain the = datagram tag to at least 16 bits. Another (key for me)  reason is = its potential use as a label for label switching fragments in a route = over model.

 

Please find below the exercise of picking your proposal of = 11 for fragments applied to the frag recovery draft. I agree with Dario = that we should reserve 11X00 to avoid confusion, at least for a while. = That could give us:

 

Forward = fragment:

-----------------

         =             &= nbsp;      1     &= nbsp;           &n= bsp; = 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

       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       = |1 1 F A 1|   datagram_size     = |         = datagram_tag          = |

       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       = |Sequence |   datagram_offset =   |

       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Where F would be = (reserved for) Forward ECN and A ACK requested

 

Reply/ACK:

----------

=             &= nbsp;           &n= bsp;  1         &n= bsp;         = 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

       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       = |1 1 B 1 0 0|siz|         = datagram_tag          | Ack = Bitmap ...

       +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Where B would be = (reserved for) Backward ECN, R set if error, and size used to encode the = ack bitmap size (1 to 4 bytes).

 

The cool thing is that = we do not need the complex bitmap encoding that was introduced recently = to we could ack up to 32 fragments.

 

 

 

Reply/NACK:

-----------

         =             &= nbsp;      1     &= nbsp;           &n= bsp; = 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

       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       = |1 1 B 1 0 1|rsv|         = datagram_tag          | =  error code   |

       +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

 

What do you think?

 

Pascal

 

 

-----Original Message-----
From: = 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of = Jonathan Hui
Sent: Thursday, February 18, 2010 10:49 PM
To: Dario = Tedeschi
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] RFC 4944 = fragmentation and future extensions

 

 

Hi = Dario,

 

I support the effort to make the offset field be in units = of single octets, rather than 8 octets.  Though we need to be = careful about shrinking the tag field.  Earlier drafts of RFC 4944 = originally made the tag field 10 bits, but some comments from IESG = review raised concerns about whether that was enough.  After some = discussion on the list, the decision was made to expand the field to 16 = bits (though only 14 bits was necessary at the time) [1].  The key = point is that

802.15.4 may operate on different PHYs with higher bit = rates so we should be prepared for those.

 

In my ideal world, we would = reallocate a single fragment header type for simplicity.  I'm not = concerned about backwards compatibility given that we are changing the = entire HC format.  And little has been done in the way of = multi-vendor interoperability with the existing formats.  In that = case, we include the tag, size, and offset fields in every fragment = while keeping the tag 16 bits and others 11 bits.  The header type = would remain at two bits with '11'.  Eliding the offset field in = the first fragment doesn't give much added = benefit.

 

To me, the above is the most straight-forward approach - = maintaining most of the existing format structure, while at the same = time simplifying it and avoids revisiting the same IESG concerns we've = had in the past.

 

An alternate approach is to pick up on existing work to = redesign the fragmentation layer to support more efficient fragment = recovery and out-of-order delivery, but that would require a bigger = change.  I'd echo Pascal's request to get additional thoughts = there.

 

[1] http://www.ietf.org/mail-= archive/web/6lowpan/current/msg00588.html

 

--

Jonathan Hui

 

On Feb 18, 2010, at 1:07 PM, = Dario Tedeschi wrote:

 

> Richard and Owen,

> 

>> 

>>> I think that the = best solution would be to switch to using the

>>> compressed size and = offsets in the fragment headers.

>>> This would allow = (un)compression and (de)fragmentation to be done =

>>> independently.

>>> 

>> I absolutely = agree.

>> 

> I = agree.

> 

> I think it should be = simplified further by making datagram_offset

> 11bits long. Having = datagram_offset as 8bits (forcing fragment length =

> to = a multiple of 8) may save 1 byte, but it also means that up to 7 =

> = bytes at the end of a fragment can be left unused (save 1 byte to, =

> = potentially, lose 7). So how about a new fragmentation header where =

> = both datagram_size and datagram_offset are 11bits and the datagram_tag =

> is = reduced to 13bits (how big does the tag need to be anyway). A new =

> = dispatch pattern would indicate a new fragmentation header where =

> = _offset and _size are relative to the compressed datagram. Something =

> = like the following:

> 

>         &n= bsp;          = 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 2 3

> 4 5 6 7 8 = 9

> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=

> = +-+-+-+-+-+-+

> |1 1 1 1 1|    = datagram_size    |      = datagram_tag       |    =

> = datagram_offset   |

> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=

> = +-+-+-+-+-+-+

> 

> 

> From an implementation = point of view, bits 0 to 28 can be used as a

> pseudo tag in identifying = fragments that belong to one datagram. It

> could be stored in 4 bytes = with the last three bits of the last byte

> masked out, but that's just = an idea for trying to be a little more

> = efficient.

> 

> = Regards

> Dario

> 

> 

> = _______________________________________________

> 6lowpan mailing = list

> 6lowpan@ietf.org

> = https://www.ietf.org/mail= man/listinfo/6lowpan

 

_______________________________________________

6lowpan mailing = list

6lowpan@ietf.org

https://www.ietf.org/mail= man/listinfo/6lowpan

------_=_NextPart_001_01CAB144.9CA99E81-- From richard.kelsey@ember.com Fri Feb 19 06:05:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED0D28C280 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 06:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR6LD7yPhwsK for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 06:05:17 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B2BF228C1F7 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 06:05:17 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 09:09:32 -0500 Date: Fri, 19 Feb 2010 08:54:07 -0500 Message-Id: <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: (message from Jonathan Hui on Thu, 18 Feb 2010 13:48:41 -0800) From: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> <4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> X-OriginalArrivalTime: 19 Feb 2010 14:09:32.0389 (UTC) FILETIME=[28951150:01CAB16D] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 14:05:18 -0000 If we are going to mess with the fragment headers, and not just change the length and offsets from uncompressed to compressed, then my preferences would be: - Remove the alignment requirement for offsets. - Allow for some kind of ack, whether or not a packet is fragmented. 802.15.4 acks have their problems, so as long as we are adding an ack we should make it a general one. - Maintain backward compatibility. While I am not sure that backwards compatibility matters a great deal for this, being compatible is simpler. If nothing else, it makes life a lot easier for Wireshark and other tools. I really do not see the need to make the fragment header a byte shorter at the cost of using up a large block of dispatch bytes. We can't be sure we are getting fragmentation right this time, either. A proposal: Fragment: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment (TBD)| datagram_tag |A|R| datagram_ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ size | datagram_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A = ack requested R = reserved Datagram_size and datagram_offset are with respect to the compressed datagram. datagram_offset is zero for the first fragment. Ack request for an unfragmented packet: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ack Req (TBD) | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ack: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ack (TBD) |M| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [mask] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M = mask present An ack with no mask acks the entire datagram, fragmented or not. -Richard Kelsey From pthubert@cisco.com Fri Feb 19 06:16:33 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7936E28C1ED for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 06:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=-3.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSblaedIIdLo for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 06:16:32 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 34B6828C1D3 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 06:16:32 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQAACssfkuQ/uCWe2dsb2JhbACbBxUBARYkBh2lCZd8hGcE X-IronPort-AV: E=Sophos;i="4.49,503,1262563200"; d="scan'208";a="3603525" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 19 Feb 2010 13:46:32 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JEIHsx018540; Fri, 19 Feb 2010 14:18:17 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 15:18:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Feb 2010 15:18:10 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> In-Reply-To: <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] RFC 4944 fragmentation and future extensions Thread-Index: AcqxbNNhMcJ8IH+vTxO9F6WwwYaqjAAAVzbg References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , "Jonathan Hui" X-OriginalArrivalTime: 19 Feb 2010 14:18:17.0748 (UTC) FILETIME=[61B87D40:01CAB16E] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 14:16:33 -0000 Hi Richard: I'm confused by 2 things. 1) why do you desire to suppress alignment?=20 2) The ack is in the fragment header, so how'd you ack a non fragmented packet? Cheers, Pascal -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Richard Kelsey Sent: Friday, February 19, 2010 2:54 PM To: Jonathan Hui Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions If we are going to mess with the fragment headers, and not just change the length and offsets from uncompressed to compressed, then my preferences would be: - Remove the alignment requirement for offsets. - Allow for some kind of ack, whether or not a packet is fragmented. 802.15.4 acks have their problems, so as long as we are adding an ack we should make it a general one. - Maintain backward compatibility. While I am not sure that backwards compatibility matters a great deal for this, being compatible is simpler. If nothing else, it makes life a lot easier for Wireshark and other tools. I really do not see the need to make the fragment header a byte shorter at the cost of using up a large block of dispatch bytes. We can't be sure we are getting fragmentation right this time, either. A proposal: Fragment: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment (TBD)| datagram_tag |A|R| datagram_ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ size | datagram_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A =3D ack requested R =3D reserved Datagram_size and datagram_offset are with respect to the compressed datagram. datagram_offset is zero for the first fragment. Ack request for an unfragmented packet: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ack Req (TBD) | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ack: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ack (TBD) |M| datagram_tag | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [mask] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M =3D mask present =20 An ack with no mask acks the entire datagram, fragmented or not. -Richard Kelsey _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From richard.kelsey@ember.com Fri Feb 19 06:32:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03ABA28C217 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 06:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t43HdArw5yt for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 06:32:07 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 1B70828C13B for <6lowpan@ietf.org>; Fri, 19 Feb 2010 06:32:07 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 09:36:22 -0500 Date: Fri, 19 Feb 2010 09:20:57 -0500 Message-Id: <87eikhux12.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 19 Feb 2010 14:36:22.0171 (UTC) FILETIME=[E8164EB0:01CAB170] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 14:32:08 -0000 > Date: Fri, 19 Feb 2010 15:18:10 +0100 > From: "Pascal Thubert (pthubert)" > > I'm confused by 2 things. > > 1) why do you desire to suppress alignment? Because requiring the fragment offset be aligned on an eight-byte boundary adds complexity and wastes payload. To be clearer, I meant the alignment of the fragment boundaries, not the alignment of the offset field within the fragment header. I would prefer to keep the fields themselves aligned on byte boundaries, but it is difficult to to so with two eleven-bit fields. They could easily be put on four-bit (nibble) boundaries, if that is a help. > 2) The ack is in the fragment header, so how'd you ack a > non fragmented packet? What do you mean by "the ack is in the fragment header"? The ack is its own dispatch type, distinct from the fragment dispatch. -Richard From pthubert@cisco.com Fri Feb 19 07:05:12 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78FD828C240 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 07:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itiG3nIV28gm for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 07:05:07 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3FA773A7F7E for <6lowpan@ietf.org>; Fri, 19 Feb 2010 07:05:06 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFACo4fktAZnwN/2dsb2JhbACBQplFdKV7l3WEZwQ X-IronPort-AV: E=Sophos;i="4.49,503,1262563200"; d="scan'208,217";a="87483813" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2010 15:06:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1JF6hS3021775; Fri, 19 Feb 2010 15:06:49 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 16:06:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB175.23D4B306" Date: Fri, 19 Feb 2010 16:06:37 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> In-Reply-To: <87eikhux12.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] RFC 4944 fragmentation and future extensions Thread-Index: AcqxcMXat5GSwxwjRYuUnY8kiSmHUgAAzWCw References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 19 Feb 2010 15:06:41.0535 (UTC) FILETIME=[248338F0:01CAB175] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 15:05:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAB175.23D4B306 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard: >>=20 >> 1) why do you desire to suppress alignment?=20 =20 > Because requiring the fragment offset be aligned on an eight-byte boundary adds complexity and wastes payload. =20 How, that much we agree upon. But on your example you had the datagram_size over a DWORD barrier and I think that can be an issue. =20 >> 2) The ack is in the fragment header, so how'd you ack a non=20 >> fragmented packet? =20 >What do you mean by "the ack is in the fragment header"? >The ack is its own dispatch type, distinct from the fragment dispatch. =20 I see. So you'd use a new dispatch to make any packet ackable. Looks good to me. Do you have details on problems that this solves? As I had before, we need the capability to inform of congestion and error. In particular propagate a NACK to a source. =20 Cheers, =20 -Richard ------_=_NextPart_001_01CAB175.23D4B306 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard:

>> =

>> 1) why do you desire to suppress alignment? =

 

> Because requiring the fragment offset be aligned on an = eight-byte boundary adds complexity and wastes = payload.

 

How, that = much we agree upon. But on your example you had the datagram_size over a = DWORD barrier and I think that can be an issue.

 

>> 2) The ack is in the = fragment header, so how'd you ack a non

>> fragmented = packet?

 

>What do you mean by "the ack is in the fragment = header"?

>The ack is its own dispatch type, distinct from the = fragment dispatch.

 

I see.  So you’d use = a new dispatch to make any packet ackable. Looks good to me. Do you have = details on problems that this solves?

As I had before, we need the = capability to inform of congestion and error. In particular propagate a = NACK to a source.

 

Cheers,

 

    = -Richard

------_=_NextPart_001_01CAB175.23D4B306-- From richard.kelsey@ember.com Fri Feb 19 07:49:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9153A8173 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 07:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yfh4ttQRzA5 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 07:49:44 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id EF6443A6BF8 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 07:49:43 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 10:53:59 -0500 Date: Fri, 19 Feb 2010 10:38:33 -0500 Message-Id: <87aav5utfq.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 19 Feb 2010 15:53:59.0046 (UTC) FILETIME=[BFCD0A60:01CAB17B] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 15:49:44 -0000 > Date: Fri, 19 Feb 2010 16:06:37 +0100 > From: "Pascal Thubert (pthubert)" > > But on your example you had the datagram_size over a DWORD barrier > and I think that can be an issue. The alternative would be to put the length and offset first, and the tag second: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment (TBD)|A| datagram_size |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A = ack requested R = reserved Personally, I would prefer the tag first and not worry about the DWORD barrier, but it isn't something I feel strongly about. > > The ack is its own dispatch type, distinct from the fragment dispatch. > > I see. So you'd use a new dispatch to make any packet ackable. Looks > good to me. Do you have details on problems that this solves? The 802.15.4 ack is basically a phy ack. It tells you that the bits were received, but that is all. It doesn't tell you that the incoming message passed any security checks or if the receiver has space to buffer it. The 802.15.4 ack has no security and no source address. A 6LoWPAN ack could be secured and would indicate that the routing layer actually received the packet. > As I had before, we need the capability to inform of congestion and > error. Doing this would raise a lot of questions that I was trying to avoid. Handling congestion can get quite complicated, and seems only marginally related to the handling of any particular message. -Richard From jhui@archrock.com Fri Feb 19 07:53:37 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F263A8179 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 07:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW+xIl9Ed54l for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 07:53:36 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id AF0203A8177 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 07:53:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id E3A9FAF9A4; Fri, 19 Feb 2010 07:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlPgwAFmz5Lw; Fri, 19 Feb 2010 07:55:18 -0800 (PST) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id E6C73AF843; Fri, 19 Feb 2010 07:55:17 -0800 (PST) Message-Id: From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Feb 2010 07:55:17 -0800 References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 15:53:37 -0000 Hi Pascal and Richard, Since we are going down this path, I'd like to agree on what the =20 6lowpan ack/frag mechanism should provide before we get into the =20 details of bits/bytes. Let me throw out my preferences: - Ability to ACK/NACK and 6lowpan packet, whether or not it is =20 fragmented. The NACK is really useful to explicitly indicate that the =20= receiver does not currently have the buffer space to store the 6lowpan =20= packet. - Ability to carry arbitrary payloads in the ACK/NACK. There have =20 been many times in the past where being able to piggyback information =20= on the ACK/NACK can be helpful. We would probably initially define a =20= SNACK option, but I'd really like to keep it general enough so that we =20= aren't stuck with whatever we define immediately. - Carry a 6lowpan packet sequence number/tag separate from the MAC =20 header to assist in identifying 6lowpan fragments/packets as well as =20 suppressing dups. - Maintain backwards compatibility with the existing RFC 4944 fragment =20= header. Thoughts on the above? -- Jonathan Hui On Feb 19, 2010, at 7:06 AM, Pascal Thubert (pthubert) wrote: > Hi Richard: > >> > >> 1) why do you desire to suppress alignment? > > > Because requiring the fragment offset be aligned on an eight-byte =20= > boundary adds complexity and wastes payload. > > How, that much we agree upon. But on your example you had the =20 > datagram_size over a DWORD barrier and I think that can be an issue. > > >> 2) The ack is in the fragment header, so how'd you ack a non > >> fragmented packet? > > >What do you mean by "the ack is in the fragment header"? > >The ack is its own dispatch type, distinct from the fragment =20 > dispatch. > > I see. So you=92d use a new dispatch to make any packet ackable. =20 > Looks good to me. Do you have details on problems that this solves? > As I had before, we need the capability to inform of congestion and =20= > error. In particular propagate a NACK to a source. > > Cheers, > > -Richard From jhui@archrock.com Fri Feb 19 08:24:17 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AB128C295 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 08:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prnxeiz8aT10 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 08:24:17 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 4EBEF28C262 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 08:24:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9AB47AF947; Fri, 19 Feb 2010 08:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2C9d7uEa2Fm; Fri, 19 Feb 2010 08:26:00 -0800 (PST) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id B92DEAF845; Fri, 19 Feb 2010 08:25:59 -0800 (PST) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87aav5utfq.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Feb 2010 08:25:58 -0800 References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> <87aav5utfq.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 16:24:18 -0000 On Feb 19, 2010, at 7:38 AM, Richard Kelsey wrote: > The 802.15.4 ack is basically a phy ack. It tells you that > the bits were received, but that is all. It doesn't tell > you that the incoming message passed any security checks or > if the receiver has space to buffer it. The 802.15.4 ack > has no security and no source address. As FYI, the 802.15.4e TG is actively working on resolving these issues with the existing 802.15.4-2006 ACK. Regardless, however, I still see benefits in a 6lowpan-layer ACK. -- Jonathan Hui From pthubert@cisco.com Fri Feb 19 08:54:48 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F5A28C27B for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 08:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.741 X-Spam-Level: X-Spam-Status: No, score=-9.741 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU7yFUdHQwhK for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 08:54:47 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9D44028C22F for <6lowpan@ietf.org>; Fri, 19 Feb 2010 08:54:47 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOdRfktAZnwN/2dsb2JhbACbB3SlWpd9hGcE X-IronPort-AV: E=Sophos;i="4.49,504,1262563200"; d="scan'208";a="87508955" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2010 16:56:34 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1JGuWn7004626; Fri, 19 Feb 2010 16:56:34 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 17:56:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Feb 2010 17:56:27 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0149ACAA@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] RFC 4944 fragmentation and future extensions Thread-Index: AcqxfBGF0/uFoZkNTzqPIwG9/vFdqwACFWfw References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 19 Feb 2010 16:56:32.0937 (UTC) FILETIME=[7D4B5990:01CAB184] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 16:54:48 -0000 Hi Jonathan: I'm with you so far. Richard? Pascal -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com]=20 Sent: Friday, February 19, 2010 4:55 PM To: Pascal Thubert (pthubert) Cc: Richard Kelsey; 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions Hi Pascal and Richard, Since we are going down this path, I'd like to agree on what the 6lowpan ack/frag mechanism should provide before we get into the details of bits/bytes. Let me throw out my preferences: - Ability to ACK/NACK and 6lowpan packet, whether or not it is fragmented. The NACK is really useful to explicitly indicate that the receiver does not currently have the buffer space to store the 6lowpan packet. - Ability to carry arbitrary payloads in the ACK/NACK. There have been many times in the past where being able to piggyback information on the ACK/NACK can be helpful. We would probably initially define a SNACK option, but I'd really like to keep it general enough so that we aren't stuck with whatever we define immediately. - Carry a 6lowpan packet sequence number/tag separate from the MAC header to assist in identifying 6lowpan fragments/packets as well as suppressing dups. - Maintain backwards compatibility with the existing RFC 4944 fragment header. Thoughts on the above? -- Jonathan Hui On Feb 19, 2010, at 7:06 AM, Pascal Thubert (pthubert) wrote: > Hi Richard: > >> > >> 1) why do you desire to suppress alignment? > > > Because requiring the fragment offset be aligned on an eight-byte > boundary adds complexity and wastes payload. > > How, that much we agree upon. But on your example you had the =20 > datagram_size over a DWORD barrier and I think that can be an issue. > > >> 2) The ack is in the fragment header, so how'd you ack a non > >> fragmented packet? > > >What do you mean by "the ack is in the fragment header"? > >The ack is its own dispatch type, distinct from the fragment =20 > dispatch. > > I see. So you'd use a new dispatch to make any packet ackable. =20 > Looks good to me. Do you have details on problems that this solves? > As I had before, we need the capability to inform of congestion and =20 > error. In particular propagate a NACK to a source. > > Cheers, > > -Richard From cabo@tzi.org Fri Feb 19 08:59:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C9F3A7B1F for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 08:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRVm+GAyaygG for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 08:59:49 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 6FE9A3A769C for <6lowpan@ietf.org>; Fri, 19 Feb 2010 08:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o1JH1RJx001713 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 18:01:27 +0100 (CET) Received: from [134.102.2.180] (unknown [134.102.2.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 88D6AEFAD; Fri, 19 Feb 2010 18:01:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Fri, 19 Feb 2010 18:01:26 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> To: 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1077) Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 16:59:50 -0000 On Feb 19, 2010, at 16:55, Jonathan Hui wrote: > Since we are going down this path, Are we? My advice would be to read RFC 3819 before designing another L2 protocol. Gruesse, Carsten From jhui@archrock.com Fri Feb 19 09:07:17 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E566028C20E for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 09:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsPA3LMd4YXM for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 09:07:17 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 3C75628C17D for <6lowpan@ietf.org>; Fri, 19 Feb 2010 09:07:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 62DC7AF947; Fri, 19 Feb 2010 09:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FUC9JEZGl00; Fri, 19 Feb 2010 09:08:59 -0800 (PST) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 8869EAF81F; Fri, 19 Feb 2010 09:08:59 -0800 (PST) Message-Id: <50E8ACF9-62E2-4CD0-AAF3-9444E8881D5F@archrock.com> From: Jonathan Hui To: Carsten Bormann In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Feb 2010 09:08:58 -0800 References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 17:07:18 -0000 Hi Carsten, On Feb 19, 2010, at 9:01 AM, Carsten Bormann wrote: > Are we? > > My advice would be to read RFC 3819 before designing another L2 > protocol. The issues with 802.15.4-2006 ACKs are widely known (security, inability to nack, etc.). Waiting for the 802.15.4e TG to fix these issues (and then waiting for silicon vendors to implement those changes) is going to be a long process (if you've been following the discussions, it's already a big can of worms). Properly supporting security has already opened a big can of worms w.r.t. timing constraints, timeline to implement in hardware, etc. Defining an optional 6lowpan-layer ACK would solve many of these problems. -- Jonathan Hui From dat@exegin.com Fri Feb 19 10:36:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128D13A7FAC for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 10:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJXF-hwXFw0H for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 10:36:31 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id CBD2B3A6D3F for <6lowpan@ietf.org>; Fri, 19 Feb 2010 10:36:30 -0800 (PST) Received: by bwz3 with SMTP id 3so345082bwz.29 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 10:38:13 -0800 (PST) Received: by 10.204.34.212 with SMTP id m20mr1686070bkd.79.1266604692902; Fri, 19 Feb 2010 10:38:12 -0800 (PST) Received: from ?172.16.1.52? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 14sm176549bwz.6.2010.02.19.10.38.10 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Feb 2010 10:38:12 -0800 (PST) Message-ID: <4B7EDA91.1000809@exegin.com> Date: Fri, 19 Feb 2010 10:38:09 -0800 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Hui References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> <4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <4B7DE500.1060607@exegin.com> <54359E42-F1B2-41B8-AD61-066B4DBA98B0@archrock.com> In-Reply-To: <54359E42-F1B2-41B8-AD61-066B4DBA98B0@archrock.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 18:36:32 -0000 Hi Jonathan Jonathan Hui wrote: > > Hi Dario, > > On Feb 18, 2010, at 5:10 PM, Dario Tedeschi wrote: >> What kind of future bit rates are expected? Isn't it also possible >> that even a 16bit tag might not be enough in the future, if bit rates >> increase enough. My point here, is that I think the tag size is >> somewhat subjective depending on who you talk to and how much of the >> future one tries to predict. > > When this WG chose to expand the tag field, we considered 2 Mbps 15.4a > PHY - see the archived thread that I linked. > >> Here's a rough calculation of the time it would take for the tag >> value in one node to rollover ... --- removed for brevity --- ... >> >> So is a 9 second rollover at 1Mb/s not sufficient as a worst case? I >> think it would be OK. Also, if we see bit-rates for PHYs increase we >> may also see an increase in allowable packet sizes (one can only hope >> :-). > > This WG assumed a minimum roll-over period of 60 seconds - following > the parameters chosen by IPv6 reassembly - again, see the archived > thread. I could also see some scenarios where 9 seconds may not be > enough for some low-power protocols and/or mesh-under networks. > >> However, if it means re-opening a heated debate or causing IESG >> problems, perhaps its best to stay with a 16bit tag and avoid wasting >> valuable time. > > This is what I'm trying to avoid. OK, fair enough. 16bits it is. > >>> I'm not concerned about backwards compatibility given that we are >>> changing the entire HC format. And little has been done in the way >>> of multi-vendor interoperability with the existing formats. In that >>> case, we include the tag, size, and offset fields in every fragment >>> while keeping the tag 16 bits and others 11 bits. The header type >>> would remain at two bits with '11'. >> Sounds plausible, except that I have two reservations: >> • Having a dispatch pattern of '11xxxxxx' would overlay FRAG1, >> FRAGN and LOWPAN_NHC encoding in "draft...-hc-06". FRAG1 and FRAGN >> are of greater concern, because there would be no way of filtering >> out old fragment headers. I think in this case we'd want to remain >> backward compatible. > > I'm still not convinced on the *need* for backwards compatibility. > Another option is to take over the NALP value and require any non-IPv6 > protocol operating within a 6LoWPAN network to allocate a dispatch > value and respect the dispatch encoding. Are there people using the > NALP value and would they strongly oppose losing another 6 bits to > respect the dispatch encoding in order to fit in simplified fragment > header? > Certainly a possibility, if we are willing to drop NALP. >> • The _size and _offset fields would no longer be octet aligned >> (assuming the same field order). > It's easy to fix some of that by reordering the fields to: offset | > size | tag. OK, that would only align "size" and "tag". Ideally I'd rather see all fields aligned, but given that aligning two 11bit fields is awkward, I'd rather see offset aligned since that's the one field that's used more often. How about: tag | size | offset (still assuming a philosophy of simplifying fragmentation)? -- Dario From richard.kelsey@ember.com Fri Feb 19 10:39:55 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DBF3A7FB1 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 10:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkKUeSGw97Fj for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 10:39:54 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 088673A7D50 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 10:39:53 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 13:44:09 -0500 Date: Fri, 19 Feb 2010 13:28:42 -0500 Message-Id: <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: (message from Carsten Bormann on Fri, 19 Feb 2010 18:01:26 +0100) From: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 19 Feb 2010 18:44:09.0453 (UTC) FILETIME=[85AD81D0:01CAB193] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 18:39:55 -0000 > From: Carsten Bormann > Date: Fri, 19 Feb 2010 18:01:26 +0100 > > On Feb 19, 2010, at 16:55, Jonathan Hui wrote: > > > Since we are going down this path, > > Are we? I think we have to do something, because the RFC 4944 fragmentation does not work well if the compressed headers extend beyond the first fragment, or if a new transport compression is introduced. The HC draft makes this more important because it includes encodings for IPv6 extension headers. Whether this is fixed via a minimal update or a complete redesign is another question. I think it is worth spending a little time on what a redesign might look like, even if we end up leaving the fragmentation much as it is now. -Richard Kelsey From richard.kelsey@ember.com Fri Feb 19 10:47:27 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6A53A7FE1 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 10:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4773JGR6mh2T for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 10:47:26 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 9B0843A7FE6 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 10:47:26 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 13:51:42 -0500 Date: Fri, 19 Feb 2010 13:36:14 -0500 Message-Id: <87635tul7l.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: (message from Jonathan Hui on Fri, 19 Feb 2010 07:55:17 -0800) From: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 19 Feb 2010 18:51:42.0374 (UTC) FILETIME=[93A3C460:01CAB194] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 18:47:27 -0000 > From: Jonathan Hui > Date: Fri, 19 Feb 2010 07:55:17 -0800 > > Since we are going down this path, I'd like to agree on what the > 6lowpan ack/frag mechanism should provide before we get into the > details of bits/bytes. Let me throw out my preferences: > > - Ability to ACK/NACK and 6lowpan packet, whether or not it is > fragmented. The NACK is really useful to explicitly indicate that the > receiver does not currently have the buffer space to store the 6lowpan > packet. > > - Ability to carry arbitrary payloads in the ACK/NACK. There have > been many times in the past where being able to piggyback information > on the ACK/NACK can be helpful. We would probably initially define a > SNACK option, but I'd really like to keep it general enough so that we > aren't stuck with whatever we define immediately. > > - Carry a 6lowpan packet sequence number/tag separate from the MAC > header to assist in identifying 6lowpan fragments/packets as well as > suppressing dups. > > - Maintain backwards compatibility with the existing RFC 4944 fragment > header. Jonathan, That seems like a good list of goals, as long as nothing too complicated results. For arbitrary payloads, would it be enough to allow the ACK/NACK to be followed by additional LoWPAN frames? The piggybacked data could then be defined completely separately. -Richard Kelsey From dat@exegin.com Fri Feb 19 11:39:48 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9933A7D92 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 11:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiq8fbtqHCET for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 11:39:47 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 21E453A7D7E for <6lowpan@ietf.org>; Fri, 19 Feb 2010 11:39:46 -0800 (PST) Received: by bwz3 with SMTP id 3so388696bwz.29 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 11:41:29 -0800 (PST) Received: by 10.204.34.208 with SMTP id m16mr2470161bkd.180.1266608489409; Fri, 19 Feb 2010 11:41:29 -0800 (PST) Received: from ?172.16.1.52? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 14sm196033bwz.10.2010.02.19.11.41.27 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Feb 2010 11:41:28 -0800 (PST) Message-ID: <4B7EE965.3030602@exegin.com> Date: Fri, 19 Feb 2010 11:41:25 -0800 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 19:39:48 -0000 Hi Carsten and Richard Richard Kelsey wrote: >> From: Carsten Bormann >> Date: Fri, 19 Feb 2010 18:01:26 +0100 >> >> On Feb 19, 2010, at 16:55, Jonathan Hui wrote: >> >> >>> Since we are going down this path, >>> >> Are we? >> > > I think we have to do something, because the RFC 4944 > fragmentation does not work well if the compressed headers > extend beyond the first fragment, or if a new transport > compression is introduced. The HC draft makes this more > important because it includes encodings for IPv6 extension > headers. > > Whether this is fixed via a minimal update or a complete > redesign is another question. I think an updated, simplified fragmentation header to support the HC draft would be the quickest way forward. Let's fix the main problem that started this thread: Namely, that compressed headers spanning multiple RFC4944 fragments presents huge complexities in re-assembly. Sure, having a 6LoWPAN ACK may solve some issues, but how many use-cases does it cover and is it worth all the extra work at this point. Couldn't ACKing be added as an optional protocol some time in the future, for those that need it? Regards Dario From Pete.Stpierre@Sun.COM Fri Feb 19 11:51:23 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB45D3A7D86 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 11:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-MGVY8OHohh for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 11:51:23 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id B4B963A7D7D for <6lowpan@ietf.org>; Fri, 19 Feb 2010 11:51:22 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1JJr9gA026608 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 11:53:10 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY300G00TUBHF00@fe-sfbay-09.sun.com> for 6lowpan@ietf.org; Fri, 19 Feb 2010 11:53:09 -0800 (PST) Received: from dhcp-069-152.sfbay.sunlabs.com (dyn53.sunlabs.com [204.153.12.53]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY3001C8TWLDB80@fe-sfbay-09.sun.com>; Fri, 19 Feb 2010 11:53:09 -0800 (PST) Date: Fri, 19 Feb 2010 11:53:09 -0800 From: "Pete St. Pierre" In-reply-to: <4B7EE965.3030602@exegin.com> Sender: Pete.Stpierre@Sun.COM To: Dario Tedeschi Message-id: <4947014B-FE5C-4E4F-8B10-E8F87BAB89D1@Sun.COM> X-Mailer: Apple Mail (2.1077) References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com> <4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> <4B7EE965.3030602@exegin.com> Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 19:51:23 -0000 > I think an updated, simplified fragmentation header to support the HC draft would be the quickest way forward. Let's fix the main problem that started this thread: Namely, that compressed headers spanning multiple RFC4944 fragments presents huge complexities in re-assembly. I couldn't agree more! I don't think we want to see 4944 completely re-whacked at this point. Let's fix the problem at hand. > > Sure, having a 6LoWPAN ACK may solve some issues, but how many use-cases does it cover and is it worth all the extra work at this point. Couldn't ACKing be added as an optional protocol some time in the future, for those that need it? Agreed. We're getting more and more 4944 compliant implementations and should be careful before we fragment our developers (pun intended). IIRC, this was discussed in Stockholm and while there was some interest in continuing the work, there was definitely no consensus to re-do the entire header and deprecate 4944. My $,02 (FWIW), ...Pete From dat@exegin.com Fri Feb 19 15:41:02 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2EB28C1DD for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 15:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvV6EvgTMFba for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 15:41:01 -0800 (PST) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 5B23D3A7DCE for <6lowpan@ietf.org>; Fri, 19 Feb 2010 15:41:01 -0800 (PST) Received: by ywh3 with SMTP id 3so715016ywh.31 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 15:42:46 -0800 (PST) Received: by 10.101.78.4 with SMTP id f4mr6059464anl.50.1266622965840; Fri, 19 Feb 2010 15:42:45 -0800 (PST) Received: from ?172.16.1.52? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 15sm495342gxk.2.2010.02.19.15.42.44 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Feb 2010 15:42:45 -0800 (PST) Message-ID: <4B7F21F2.9000406@exegin.com> Date: Fri, 19 Feb 2010 15:42:42 -0800 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Geoff Mulligan References: <1266047791.3643.48.camel@dellx1> In-Reply-To: <1266047791.3643.48.camel@dellx1> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 23:41:02 -0000 Hi Geoff

 I have a few questions regarding Extended Header Compression:
  1. How does one compress the "type-specific data" field in a IPv6 Routing Header? It's a variable-length field with no predefined format given in RFC 2460. To compress this field effectively, a 6LoWPAN encoder would need to know the formats of all the currently used Routing Types.
  2. Is the reserved field in the Fragment Header elided or sent inline as 0?
  3. If Ext Header [B] follows compressed header [A] and the options in [B] turn out to be longer than 255 bytes during compression, how would you adjust [A] without having to do a memmove to make space for the inline next-header field. What I understand is that, if header [B] itself can't be compressed, the next-header field in header [A] must be placed in the inline portion for header A and before other inline fields in [A]. This problem also requires one to keep a pointer back to where the inline next-header field should be inserted. One other solution would be to look ahead at the length of [B] before compressing [A], but I think this can get messy.
Regard
Dario

Geoff Mulligan wrote: 
Folks,
  I realized that I have made a huge slip-up.  The HC draft has languished for the past few months.
At the meeting in Hiroshima we said that we would last call this draft, but I failed to send out the
actual last call. So...

  This note formally starts the WG Last Call for comments on
draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks".

The document can be found at:
http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt

The document is intended to be submitted by this Working Group to the
IESG for publication as a Standards Track document.

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

Because of my gaffe this Last Call will end Wednesday February 24 2010
at 2359 UTC.

        Thanks,
                Geoff


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

From jhui@archrock.com Fri Feb 19 15:53:45 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4163A7B89 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 15:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgL1XFHCIogi for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 15:53:44 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id E52D13A75BD for <6lowpan@ietf.org>; Fri, 19 Feb 2010 15:53:44 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 838DDAF8EB; Fri, 19 Feb 2010 15:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yak7zHroWFQQ; Fri, 19 Feb 2010 15:55:29 -0800 (PST) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id D189AAF845; Fri, 19 Feb 2010 15:55:28 -0800 (PST) Message-Id: From: Jonathan Hui To: Dario Tedeschi In-Reply-To: <4B7F21F2.9000406@exegin.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Feb 2010 15:55:27 -0800 References: <1266047791.3643.48.camel@dellx1> <4B7F21F2.9000406@exegin.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 19 Feb 2010 23:53:45 -0000 Hi Dario, On Feb 19, 2010, at 3:42 PM, Dario Tedeschi wrote: > I have a few questions regarding Extended Header Compression: > =95 How does one compress the "type-specific data" field in a = IPv6 =20 > Routing Header? It's a variable-length field with no predefined =20 > format given in RFC 2460. To compress this field effectively, a =20 > 6LoWPAN encoder would need to know the formats of all the currently =20= > used Routing Types. You don't compress. If you want compact routing information, then =20 create a new routing header type that utilizes compact information =20 (e.g. not full IPv6 addresses). It is likely that RPL will go this way. > =95 Is the reserved field in the Fragment Header elided or sent =20= > inline as 0? Sent inline as is. See this important text from hc-06: "For the most part, the IPv6 Extension Header is carried verbatim =20= in the bytes immediately following the LOWPAN_NHC octet, with two important exceptions: Length Field and Next Header Field." > =95 If Ext Header [B] follows compressed header [A] and the = options =20 > in [B] turn out to be longer than 255 bytes during compression, how =20= > would you adjust [A] without having to do a memmove to make space =20 > for the inline next-header field. What I understand is that, if =20 > header [B] itself can't be compressed, the next-header field in =20 > header [A] must be placed in the inline portion for header A and =20 > before other inline fields in [A]. This problem also requires one to =20= > keep a pointer back to where the inline next-header field should be =20= > inserted. One other solution would be to look ahead at the length of =20= > [B] before compressing [A], but I think this can get messy. If you can't compress B, using NHC encoding for A doesn't buy you =20 anything (actually hurts). My approach is to first see if it makes =20 sense to use NHC encoding at all by traversing the headers, then do =20 the transformation if needed. The important point here is that NHC support for IPv6 Extension =20 Headers isn't really intended to compress the IPv6 Extension Headers =20 themselves all that much (the only real exception is the ability to =20 elide padding in options headers. The real intended use is to allow =20 NHC encoding of transport-layer headers (e.g. UDP, TCP, etc.) as we =20 discussed in Stockholm. -- Jonathan Hui From cabo@tzi.org Fri Feb 19 23:17:41 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76E63A81C3 for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 23:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdrNDS5ZBi5M for <6lowpan@core3.amsl.com>; Fri, 19 Feb 2010 23:17:40 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 47C573A6825 for <6lowpan@ietf.org>; Fri, 19 Feb 2010 23:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o1K7JJWX013136 for <6lowpan@ietf.org>; Sat, 20 Feb 2010 08:19:19 +0100 (CET) Received: from [192.168.217.101] (p5489D7A1.dip.t-dialin.net [84.137.215.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 2B391E04F; Sat, 20 Feb 2010 08:19:19 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4B7EE965.3030602@exegin.com> Date: Sat, 20 Feb 2010 08:19:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <70063E19-09DC-4F4B-84AC-5A9A4279EC36@tzi.org> References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> <4B7EE965.3030602@exegin.com> To: 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1077) Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 20 Feb 2010 07:17:41 -0000 On Feb 19, 2010, at 20:41, Dario Tedeschi wrote: > compressed headers spanning multiple RFC4944 fragments presents huge = complexities in re-assembly My first reaction would be "don't do that, then!". (http://catb.org/jargon/html/D/Don-t-do-that-then-.html) I don't think that 4944 specifies anything that lets you have the = compressed header extend beyond the first frame. I'm not sure we explicitly discussed this, but certainly I didn't see a = need. If we now do, I'd like to first learn more about this use case. Gruesse, Carsten From jhui@archrock.com Sat Feb 20 00:41:13 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A591E3A80EF for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 00:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMsoQEW6NkUd for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 00:41:12 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id BE4513A80F1 for <6lowpan@ietf.org>; Sat, 20 Feb 2010 00:41:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id D03F9AF996; Sat, 20 Feb 2010 00:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vmb2pPhvZMFS; Sat, 20 Feb 2010 00:42:59 -0800 (PST) Received: from [10.0.1.5] (adsl-71-142-67-144.dsl.pltn13.pacbell.net [71.142.67.144]) by mail.sf.archrock.com (Postfix) with ESMTP id E28D4AF92C; Sat, 20 Feb 2010 00:42:58 -0800 (PST) Message-Id: <26426FD5-EAD2-4A26-8F94-1B130346F0D2@archrock.com> From: Jonathan Hui To: Carsten Bormann In-Reply-To: <70063E19-09DC-4F4B-84AC-5A9A4279EC36@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 20 Feb 2010 00:42:57 -0800 References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> <4B7EE965.3030602@exegin.com> <70063E19-09DC-4F4B-84AC-5A9A4279EC36@tzi.org> X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 20 Feb 2010 08:41:13 -0000 On Feb 19, 2010, at 11:19 PM, Carsten Bormann wrote: > On Feb 19, 2010, at 20:41, Dario Tedeschi wrote: > >> compressed headers spanning multiple RFC4944 fragments presents >> huge complexities in re-assembly > > My first reaction would be "don't do that, then!". > (http://catb.org/jargon/html/D/Don-t-do-that-then-.html) > > I don't think that 4944 specifies anything that lets you have the > compressed header extend beyond the first frame. > I'm not sure we explicitly discussed this, but certainly I didn't > see a need. > > If we now do, I'd like to first learn more about this use case. I'm not convinced of this use case either and I'm fine with limiting use of IPHC/NHC to the first fragment. Richard's future-compatibility case that he spawned this thread with is more important to consider. -- Jonathan Hui From richard.kelsey@ember.com Sat Feb 20 06:25:40 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726463A7B29 for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 06:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoNYUBXxdkaE for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 06:25:39 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 29EE43A7B18 for <6lowpan@ietf.org>; Sat, 20 Feb 2010 06:25:39 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 20 Feb 2010 09:29:58 -0500 Date: Sat, 20 Feb 2010 09:14:21 -0500 Message-Id: <87r5og9epu.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: <70063E19-09DC-4F4B-84AC-5A9A4279EC36@tzi.org> (message from Carsten Bormann on Sat, 20 Feb 2010 08:19:17 +0100) From: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> <4B7EE965.3030602@exegin.com> <70063E19-09DC-4F4B-84AC-5A9A4279EC36@tzi.org> X-OriginalArrivalTime: 20 Feb 2010 14:29:58.0562 (UTC) FILETIME=[2DD9F820:01CAB239] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 20 Feb 2010 14:25:40 -0000 > From: Carsten Bormann > Date: Sat, 20 Feb 2010 08:19:17 +0100 > > On Feb 19, 2010, at 20:41, Dario Tedeschi wrote: > > > compressed headers spanning multiple RFC4944 fragments > > presents huge complexities in re-assembly > > My first reaction would be "don't do that, then!". > (http://catb.org/jargon/html/D/Don-t-do-that-then-.html) Even if I don't do it, how can I be sure that no one else will? In the absence of any indication one way or the other in 4944, it would be dangerous to assume that no incoming packet will have a compressed header in the second fragment. > I don't think that 4944 specifies anything that lets you have the > compressed header extend beyond the first frame. 4944 doesn't say anything one way or the other, as far as I can tell. I can't see it happening with the 4944 compression, which may be why 4944 is silent on the issue. With the HC draft allowing compressed UDP headers to follow routing headers it is much more of a possibility. > I'm not sure we explicitly discussed this, but certainly I didn't see > a need. My one concern would be source routes, which are eminently suitable for compression and even when compressed could conceivably extend into the second fragment. It would be a shame to be able to compress short source routes but not long ones. -Richard Kelsey From richard.kelsey@ember.com Sat Feb 20 07:00:11 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279A93A7CD2 for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 07:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPUvSPMLNmsi for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 07:00:10 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 2ECB43A6FF9 for <6lowpan@ietf.org>; Sat, 20 Feb 2010 07:00:10 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 20 Feb 2010 10:04:30 -0500 Date: Sat, 20 Feb 2010 09:48:52 -0500 Message-Id: <87pr409d4b.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <26426FD5-EAD2-4A26-8F94-1B130346F0D2@archrock.com> (message from Jonathan Hui on Sat, 20 Feb 2010 00:42:57 -0800) From: Richard Kelsey References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> <4B7EE965.3030602@exegin.com> <70063E19-09DC-4F4B-84AC-5A9A4279EC36@tzi.org> <26426FD5-EAD2-4A26-8F94-1B130346F0D2@archrock.com> X-OriginalArrivalTime: 20 Feb 2010 15:04:30.0031 (UTC) FILETIME=[008B0DF0:01CAB23E] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 20 Feb 2010 15:00:11 -0000 > From: Jonathan Hui > Date: Sat, 20 Feb 2010 00:42:57 -0800 > > On Feb 19, 2010, at 11:19 PM, Carsten Bormann wrote: > > > I don't think that 4944 specifies anything that lets you have the > > compressed header extend beyond the first frame. > > I'm not sure we explicitly discussed this, but certainly I didn't > > see a need. > > > > If we now do, I'd like to first learn more about this use case. > > I'm not convinced of this use case either and I'm fine with limiting > use of IPHC/NHC to the first fragment. > > Richard's future-compatibility case that he spawned this thread with > is more important to consider. The two issues are related. If it were possible to guarantee that no compressed header would ever extend into the second fragment, then future compatibility would not be a problem. A relaying node could treat any unknown compressed header as if it and all subsequent headers were uncompressed. As long as compression only occured in the first fragment the second fragment's offset would be correct. Similarly, if all relayed messages could be completely uncompressed, we could mandate that compressed headers must never extend into the second fragment. A relaying node would stop compressing when it reached the end of the first outgoing fragment. The rub is that we can't enforce the requirement in precisely the case where it matters, which is when a relaying node gets a header that it doesn't know how to uncompress. The boundary between the first two fragments can move a lot from one hop to another, especially with anything like RPL's piecewise source routes in use. If a relay gets an unknown compressed header and has to add, say, an eight-hop source route, what can it do? How can it know that it hasn't pushed part of the compressed header into the second fragment? The use of the compressed offsets in the fragment headers introduces a number of complicated layering issues. It makes fragmentation and compression interdependent. It makes relaying nodes process transport headers. It interacts with the use of routing headers. What benefits does it bring that make it worth all of the headaches? -Richard Kelsey From cabo@tzi.org Sat Feb 20 08:13:10 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17033A7698 for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 08:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7btlUXeWO52 for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 08:13:08 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D353D28C180 for <6lowpan@ietf.org>; Sat, 20 Feb 2010 08:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o1KGEf64005672; Sat, 20 Feb 2010 17:14:41 +0100 (CET) Received: from [10.0.1.198] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 3D880E0E6; Sat, 20 Feb 2010 17:14:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <87r5og9epu.fsf@kelsey-ws.hq.ember.com> Date: Sat, 20 Feb 2010 17:14:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5B4B5CB5-0C81-4211-8D74-989DE6FE72E6@tzi.org> References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> <4B7EE965.3030602@exegin.com> <70063E19-09DC-4F4B-84AC-5A9A4279EC36@tzi.org> <87r5og9epu.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1077) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 20 Feb 2010 16:13:10 -0000 On Feb 20, 2010, at 15:14, Richard Kelsey wrote: >> From: Carsten Bormann >> Date: Sat, 20 Feb 2010 08:19:17 +0100 >>=20 >> On Feb 19, 2010, at 20:41, Dario Tedeschi wrote: >>=20 >>> compressed headers spanning multiple RFC4944 fragments >>> presents huge complexities in re-assembly >>=20 >> My first reaction would be "don't do that, then!". >> (http://catb.org/jargon/html/D/Don-t-do-that-then-.html) >=20 > Even if I don't do it, how can I be sure that no one else > will? =20 By dropping their packets. (Seriously.) > In the absence of any indication one way or the > other in 4944, I'm reading this text/figure in section 5 as pretty strong support: A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires fragmentation: +-----------+-------------+--------------+------------+---------+ | Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload | +-----------+-------------+--------------+------------+---------+ Apart from that, 4944 simply does not say you *can* do it. It would have to, because it would have to define the semantics of = "datagram_offset" for this specific case; the current text in 4944 = clearly assumes that additional fragments only carry payload. The new HC of course can simply make it more explicit you can't continue = compressed headers into the additional fragments; that would be one WGLC = comment that could come out of this discussion. > My one concern would be source routes, which are eminently > suitable for compression and even when compressed could > conceivably extend into the second fragment. It would be a > shame to be able to compress short source routes but not > long ones. It may be worthwhile to compress source routes as part of the HC = payload, not in HC itself. But then again, I find it weird to spend work to accommodate = fragmentation of routing headers (more precisely: to make that case. of = splitting into multi-frame packets just for routing, more efficient -- = you can always choose to not compress!). Fragmenting for routing goes against a lot of things that 6lowpan stands = for. Gruesse, Carsten From jhui@archrock.com Sat Feb 20 10:24:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED10B28C0FD for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 10:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQpn0Mw-B9z2 for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 10:24:44 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 263123A821E for <6lowpan@ietf.org>; Sat, 20 Feb 2010 10:24:44 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5B518AF913; Sat, 20 Feb 2010 10:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj3evN3RCXzm; Sat, 20 Feb 2010 10:26:30 -0800 (PST) Received: from [10.0.1.5] (adsl-71-142-67-144.dsl.pltn13.pacbell.net [71.142.67.144]) by mail.sf.archrock.com (Postfix) with ESMTP id 83EC2AF99F; Sat, 20 Feb 2010 10:26:30 -0800 (PST) Message-Id: <0B6BB048-397D-452D-BF8C-D5239198927C@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87pr409d4b.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 20 Feb 2010 10:26:29 -0800 References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> <4B7EE965.3030602@exegin.com> <70063E19-09DC-4F4B-84AC-5A9A4279EC36@tzi.org> <26426FD5-EAD2-4A26-8F94-1B130346F0D2@archrock.com> <87pr409d4b.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 20 Feb 2010 18:24:45 -0000 On Feb 20, 2010, at 6:48 AM, Richard Kelsey wrote: >> From: Jonathan Hui >> Date: Sat, 20 Feb 2010 00:42:57 -0800 >> >> On Feb 19, 2010, at 11:19 PM, Carsten Bormann wrote: >> >>> I don't think that 4944 specifies anything that lets you have the >>> compressed header extend beyond the first frame. >>> I'm not sure we explicitly discussed this, but certainly I didn't >>> see a need. >>> >>> If we now do, I'd like to first learn more about this use case. >> >> I'm not convinced of this use case either and I'm fine with limiting >> use of IPHC/NHC to the first fragment. >> >> Richard's future-compatibility case that he spawned this thread with >> is more important to consider. > > The two issues are related. > [... Richard's explanation of how the issues are related ...] Yes, I agree they are related. But I find it more useful to think of it as a forward-compatibility issue. Note that RFC 4944 did not allow any kind of forward compatibility. If you need to insert a routing header, the encoding of Section 10 of RFC 4944 would require expansion of any compressed UDP/ICMPv6/TCP headers. Because 6lowpan-hc decouples the encoding for each individual header, we now have the chance to start considering forward compatibility for higher-layer headers. If we were to continue the limitations implicitly defined by RFC 4944, then there would be no fundamental flaws in the fragmentation mechanism to talk about. > The use of the compressed offsets in the fragment headers > introduces a number of complicated layering issues. It > makes fragmentation and compression interdependent. It > makes relaying nodes process transport headers. It > interacts with the use of routing headers. What benefits > does it bring that make it worth all of the headaches? I think you meant to say "The use of *uncompressed* offsets". I completely agree and I noted the same layering/dependency issues in an earlier mail. Viewing the fragmentation payload as opaque would eliminate these dependencies. Carsten suggested that we could treat higher-layer compression as payload of 6lowpan-hc (rather than as a part of), but that would eliminate any benefit from using uncompressed offsets. Regardless of what we decide to do with the fragmentation header, I would really like to see a clean separation between fragmentation and header compression. Note that saying "compressed offsets/lengths" is a bit of a misnomer. It's better to say that offsets and lengths simply reflect the actual payload being fragmented (which may or may not use header compression). -- Jonathan Hui From pthubert@cisco.com Mon Feb 22 05:32:33 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75C328C1CE for <6lowpan@core3.amsl.com>; Mon, 22 Feb 2010 05:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.802 X-Spam-Level: X-Spam-Status: No, score=-5.802 tagged_above=-999 required=5 tests=[AWL=-3.203, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSFRgl-orvua for <6lowpan@core3.amsl.com>; Mon, 22 Feb 2010 05:32:33 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id B142F28C1CA for <6lowpan@ietf.org>; Mon, 22 Feb 2010 05:32:32 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAB8WgkuQ/uCWe2dsb2JhbACbCxUBAQsLJAYcolCXWoRrBA X-IronPort-AV: E=Sophos;i="4.49,518,1262563200"; d="scan'208";a="3664356" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 22 Feb 2010 13:02:31 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1MDYUPQ023311; Mon, 22 Feb 2010 13:34:30 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 14:34:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Feb 2010 14:34:29 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0149B19E@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6lowpan fragmentation and future extensions [was RE: [6lowpan] RFC 4944 fragmentation and future extensions] Thread-Index: Acqzsf84x18ChgGkRwSkjUF9fcukKw== From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Richard Kelsey" X-OriginalArrivalTime: 22 Feb 2010 13:34:30.0339 (UTC) FILETIME=[C2E6F130:01CAB3C3] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: [6lowpan] 6lowpan fragmentation and future extensions [was RE: RFC 4944 fragmentation and future extensions] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 22 Feb 2010 13:32:33 -0000 Hi Jonathan > Regardless of what we decide to do with the fragmentation header, I would really like to see a clean separation between fragmentation and header compression. Note that saying "compressed offsets/lengths" is a bit of a misnomer. It's better to say that offsets and lengths simply reflect the actual payload being fragmented (which may or may not use header compression). I took off the reference to 4944 in the title because as you indicate, we are talking about the benefits and consequences of the new HC, as opposed to maintaining 4944. From Carsten's words and Pete's suggestion, it would appear that we can leave RFC4944 as it stands, whether it is widely used as is or gets slowly deprecated by the new HC. For the subject at hand, that is how to handle fragments in the new HC / RPL world, I do agree with you, and with the model that you mentioned before, that is that the 6LoWPAN compression should be a sublayer above the fragment sublayer as opposed to be weirdly intertwined.=20 Pascal From cabo@tzi.org Mon Feb 22 05:47:49 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390AF28C2E2 for <6lowpan@core3.amsl.com>; Mon, 22 Feb 2010 05:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu8bYzX65eou for <6lowpan@core3.amsl.com>; Mon, 22 Feb 2010 05:47:48 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id C780428C2F1 for <6lowpan@ietf.org>; Mon, 22 Feb 2010 05:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o1MDnY2B019783; Mon, 22 Feb 2010 14:49:34 +0100 (CET) Received: from [134.102.2.131] (unknown [134.102.2.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id BC4A8E676; Mon, 22 Feb 2010 14:49:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0149B19E@XMB-AMS-107.cisco.com> Date: Mon, 22 Feb 2010 14:49:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5050FC3B-7446-473F-9F8F-8F17A5501B5F@tzi.org> References: <6A2A459175DABE4BB11DE2026AA50A5D0149B19E@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1077) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan fragmentation and future extensions [was RE: RFC 4944 fragmentation and future extensions] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 22 Feb 2010 13:47:49 -0000 On Feb 22, 2010, at 14:34, Pascal Thubert (pthubert) wrote: > I do agree with you, and with the model that you mentioned > before, that is that the 6LoWPAN compression should be a sublayer = above > the fragment sublayer as opposed to be weirdly intertwined.=20 I think a previous message nicely listed the advantages and = disadvantages of the usual layering vs. the weird one (compress a single = fragment) we adopted in 4944. But in any case, 4944 fragmentation also = works with HC-new, so any new layering would only apply to a new = fragmentation format, if we invent one. Gruesse, Carsten From dat@exegin.com Mon Feb 22 11:12:42 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BFE43A7DC1 for <6lowpan@core3.amsl.com>; Mon, 22 Feb 2010 11:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emp03zRAIiYm for <6lowpan@core3.amsl.com>; Mon, 22 Feb 2010 11:12:39 -0800 (PST) Received: from mail-px0-f188.google.com (mail-px0-f188.google.com [209.85.216.188]) by core3.amsl.com (Postfix) with ESMTP id A041F3A7C42 for <6lowpan@ietf.org>; Mon, 22 Feb 2010 11:12:36 -0800 (PST) Received: by pxi26 with SMTP id 26so4612493pxi.17 for <6lowpan@ietf.org>; Mon, 22 Feb 2010 11:14:31 -0800 (PST) Received: by 10.141.89.21 with SMTP id r21mr5603714rvl.33.1266866071268; Mon, 22 Feb 2010 11:14:31 -0800 (PST) Received: from ?172.16.1.52? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 21sm206624pzk.4.2010.02.22.11.14.29 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 11:14:30 -0800 (PST) Message-ID: <4B82D791.7050608@exegin.com> Date: Mon, 22 Feb 2010 11:14:25 -0800 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Hui References: <1266047791.3643.48.camel@dellx1> <4B7F21F2.9000406@exegin.com> In-Reply-To: Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 22 Feb 2010 19:12:42 -0000 Thanks Jonathan

A few comments below...

Jonathan Hui wrote:

    • Is the reserved field in the Fragment Header elided or sent inline as 0?

Sent inline as is.  See this important text from hc-06:

    "For the most part, the IPv6 Extension Header is carried verbatim in
     the bytes immediately following the LOWPAN_NHC octet, with two
     important exceptions: Length Field and Next Header Field."

Would it not be a little clearer to the reader, if the NHC section in hc-06 stated that reserved fields must be sent inline.

    • If Ext Header [B] follows compressed header [A] and the options in [B] turn out to be longer than 255 bytes during compression, how would you adjust [A] without having to do a memmove to make space for the inline next-header field. What I understand is that, if header [B] itself can't be compressed, the next-header field in header [A] must be placed in the inline portion for header A and before other inline fields in [A]. This problem also requires one to keep a pointer back to where the inline next-header field should be inserted. One other solution would be to look ahead at the length of [B] before compressing [A], but I think this can get messy.

If you can't compress B, using NHC encoding for A doesn't buy you anything (actually hurts).
What if A was an IP header? If you can't compress B using NHC, having A compressed can still buy you a lot. So for the current NHC in the draft there are two  implementations I see:
  1. Before encoding the next-header field in the IP header, look ahead at B to see if its options exceed 255 bytes.
  2. Or, compress A then attempt to encode B, and if B's options exceed 255 bytes, insert the next-header field in compressed A's inline area (requires a memmove).

--
Regards
Dario Tedeschi
From jhui@archrock.com Mon Feb 22 11:27:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96CAC28C13F for <6lowpan@core3.amsl.com>; Mon, 22 Feb 2010 11:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcZ5D0Y30Gbi for <6lowpan@core3.amsl.com>; Mon, 22 Feb 2010 11:27:17 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id C8E7828C133 for <6lowpan@ietf.org>; Mon, 22 Feb 2010 11:27:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 857FDAF932; Mon, 22 Feb 2010 11:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGmad+zTAe7G; Mon, 22 Feb 2010 11:29:12 -0800 (PST) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id C39CCAF843; Mon, 22 Feb 2010 11:29:12 -0800 (PST) Message-Id: From: Jonathan Hui To: Dario Tedeschi In-Reply-To: <4B82D791.7050608@exegin.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 22 Feb 2010 11:29:11 -0800 References: <1266047791.3643.48.camel@dellx1> <4B7F21F2.9000406@exegin.com> <4B82D791.7050608@exegin.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 22 Feb 2010 19:27:18 -0000 Hi Dario, On Feb 22, 2010, at 11:14 AM, Dario Tedeschi wrote: > Jonathan Hui wrote: >> >> >>> =95 Is the reserved field in the Fragment Header elided or sent =20= >>> inline as 0? >> >> Sent inline as is. See this important text from hc-06: >> >> "For the most part, the IPv6 Extension Header is carried =20 >> verbatim in >> the bytes immediately following the LOWPAN_NHC octet, with two >> important exceptions: Length Field and Next Header Field." >> > Would it not be a little clearer to the reader, if the NHC section =20 > in hc-06 stated that reserved fields must be sent inline. I prefer exclusion text since the common case for IPv6 extension =20 headers is to carry everything inline. So I can certainly clarify the =20= text to more explicitly indicate the common case and add in some text =20= that talks directly to reserved fields that make it extra explicit =20 that the common case really is to carry everything inline. >>> =95 If Ext Header [B] follows compressed header [A] and the =20 >>> options in [B] turn out to be longer than 255 bytes during =20 >>> compression, how would you adjust [A] without having to do a =20 >>> memmove to make space for the inline next-header field. What I =20 >>> understand is that, if header [B] itself can't be compressed, the =20= >>> next-header field in header [A] must be placed in the inline =20 >>> portion for header A and before other inline fields in [A]. This =20 >>> problem also requires one to keep a pointer back to where the =20 >>> inline next-header field should be inserted. One other solution =20 >>> would be to look ahead at the length of [B] before compressing =20 >>> [A], but I think this can get messy. >> >> If you can't compress B, using NHC encoding for A doesn't buy you =20 >> anything (actually hurts). > What if A was an IP header? Then you wouldn't be using NHC to compress A, but IPHC instead. My =20 point is that NHC for IPv6 Extension Headers doesn't buy you much =20 unless you want to elide at most 7 octets of tail padding in a Hop-by-=20= Hop Options header or a transport-layer header that you'd like to also =20= encode using NHC. If a header turns out to be longer than 255 bytes, =20= any savings will be relatively small compared to the size of the =20 datagram. > If you can't compress B using NHC, having A compressed can still buy =20= > you a lot. So for the current NHC in the draft there are two =20 > implementations I see: > =95 Before encoding the next-header field in the IP header, look = =20 > ahead at B to see if its options exceed 255 bytes. > =95 Or, compress A then attempt to encode B, and if B's options =20= > exceed 255 bytes, insert the next-header field in compressed A's =20 > inline area (requires a memmove). Either would be logically correct and the choice should be left up to =20= the implementor. -- Jonathan Hui From dat@exegin.com Mon Feb 22 12:44:54 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F0528C167 for <6lowpan@core3.amsl.com>; Mon, 22 Feb 2010 12:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR9NZBfowSK2 for <6lowpan@core3.amsl.com>; Mon, 22 Feb 2010 12:44:53 -0800 (PST) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id 0735528C138 for <6lowpan@ietf.org>; Mon, 22 Feb 2010 12:44:53 -0800 (PST) Received: by pzk33 with SMTP id 33so298705pzk.5 for <6lowpan@ietf.org>; Mon, 22 Feb 2010 12:46:50 -0800 (PST) Received: by 10.142.195.14 with SMTP id s14mr1875488wff.186.1266871610342; Mon, 22 Feb 2010 12:46:50 -0800 (PST) Received: from ?172.16.1.52? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 22sm284542pzk.13.2010.02.22.12.46.48 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 12:46:49 -0800 (PST) Message-ID: <4B82ED33.2080104@exegin.com> Date: Mon, 22 Feb 2010 12:46:43 -0800 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Hui References: <1266047791.3643.48.camel@dellx1> <4B7F21F2.9000406@exegin.com> <4B82D791.7050608@exegin.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 22 Feb 2010 20:44:54 -0000 Hi Jonathan Jonathan Hui wrote: > > Hi Dario, > > On Feb 22, 2010, at 11:14 AM, Dario Tedeschi wrote: > >> Jonathan Hui wrote: >>> >>> >>>> • Is the reserved field in the Fragment Header elided or sent >>>> inline as 0? >>> >>> Sent inline as is. See this important text from hc-06: >>> >>> "For the most part, the IPv6 Extension Header is carried >>> verbatim in >>> the bytes immediately following the LOWPAN_NHC octet, with two >>> important exceptions: Length Field and Next Header Field." >>> >> Would it not be a little clearer to the reader, if the NHC section in >> hc-06 stated that reserved fields must be sent inline. > > I prefer exclusion text since the common case for IPv6 extension > headers is to carry everything inline. So I can certainly clarify the > text to more explicitly indicate the common case and add in some text > that talks directly to reserved fields that make it extra explicit > that the common case really is to carry everything inline. Yes, I think that would be good. > >>>> • If Ext Header [B] follows compressed header [A] and the >>>> options in [B] turn out to be longer than 255 bytes during >>>> compression, how would you adjust [A] without having to do a >>>> memmove to make space for the inline next-header field. What I >>>> understand is that, if header [B] itself can't be compressed, the >>>> next-header field in header [A] must be placed in the inline >>>> portion for header A and before other inline fields in [A]. This >>>> problem also requires one to keep a pointer back to where the >>>> inline next-header field should be inserted. One other solution >>>> would be to look ahead at the length of [B] before compressing [A], >>>> but I think this can get messy. >>> >>> If you can't compress B, using NHC encoding for A doesn't buy you >>> anything (actually hurts). >> What if A was an IP header? > > Then you wouldn't be using NHC to compress A, but IPHC instead. My > point is that NHC for IPv6 Extension Headers doesn't buy you much > unless you want to elide at most 7 octets of tail padding in a > Hop-by-Hop Options header or a transport-layer header that you'd like > to also encode using NHC. If a header turns out to be longer than 255 > bytes, any savings will be relatively small compared to the size of > the datagram. > >> If you can't compress B using NHC, having A compressed can still buy >> you a lot. So for the current NHC in the draft there are two >> implementations I see: >> • Before encoding the next-header field in the IP header, look >> ahead at B to see if its options exceed 255 bytes. >> • Or, compress A then attempt to encode B, and if B's options >> exceed 255 bytes, insert the next-header field in compressed A's >> inline area (requires a memmove). > > Either would be logically correct and the choice should be left up to > the implementor. > I understand that; I was just wondering if there was some other way of handling Ext Headers without having a 255 byte limit. I'm sure it's been thoroughly investigated. Thanks for the clarification. -- Dario Tedeschi From yoav@yitran.com Tue Feb 23 13:43:49 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052533A830F for <6lowpan@core3.amsl.com>; Tue, 23 Feb 2010 13:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.925 X-Spam-Level: X-Spam-Status: No, score=-4.925 tagged_above=-999 required=5 tests=[AWL=-1.363, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqFFU+qXfsSs for <6lowpan@core3.amsl.com>; Tue, 23 Feb 2010 13:43:48 -0800 (PST) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id BD8013A7228 for <6lowpan@ietf.org>; Tue, 23 Feb 2010 13:43:47 -0800 (PST) Received: from source ([74.125.82.53]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKS4RMj97pIxanFxcXpdvoCW/yUo7SX2AA@postini.com; Tue, 23 Feb 2010 13:45:52 PST Received: by wwi18 with SMTP id 18so68892wwi.40 for <6lowpan@ietf.org>; Tue, 23 Feb 2010 13:45:51 -0800 (PST) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq00ZMkPiHmWr6aSi2K8I9BwBURrQ== Date: Tue, 23 Feb 2010 23:45:54 +0200 Received: by 10.216.89.135 with SMTP id c7mr3025202wef.62.1266961550963; Tue, 23 Feb 2010 13:45:50 -0800 (PST) Message-ID: <8cea7492288c995f6625b347e3a96a2f@mail.gmail.com> To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=0016e6dab54d3074aa04804b79ec Subject: [6lowpan] newbie question about association to the intended PAN X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 23 Feb 2010 21:43:49 -0000 --0016e6dab54d3074aa04804b79ec Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I have a newbie question. Is it the responsibility of 6LoWPAN rfc to define how to associate a node (in 802.15.4 terms) to the network that the end user intended (as there are potentially multiple routers from multiple PANs responding to the RS reques= t broadcast)? I couldn=92t find anything about this in the 6LoWPAN rfcs. Thanks in advance, Yoav --0016e6dab54d3074aa04804b79ec Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

I have a newbie question.

=A0

Is it the responsibility of 6LoWPAN rfc to define ho= w to associate a node (in 802.15.4 terms) to the network that the end user intended (as th= ere are potentially multiple routers from multiple PANs responding to the RS request broadcast)?

=A0

I couldn=92t find anything about this in the 6LoWPAN= rfcs.

=A0

Thanks in advance,

Yoav

=A0

=A0

=A0

=A0

--0016e6dab54d3074aa04804b79ec-- From mdurvy@cisco.com Wed Feb 24 04:51:28 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725913A84AE for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 04:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr+zLkXtlr1G for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 04:51:27 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 68D233A7F1E for <6lowpan@ietf.org>; Wed, 24 Feb 2010 04:51:27 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPuvhEtAZnwN/2dsb2JhbACbEnOlGZhIhHIE X-IronPort-AV: E=Sophos;i="4.49,531,1262563200"; d="p7s'?scan'208";a="88490221" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 Feb 2010 12:53:31 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1OCrVev019072; Wed, 24 Feb 2010 12:53:31 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 13:53:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Feb 2010 13:53:30 +0100 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_1733_01CAB558.BF140430" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE01711CBB@XMB-AMS-103.cisco.com> In-Reply-To: <1266047791.3643.48.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WGLC for 6lowpan HC draft Thread-Index: AcqsghUrV7UbP7OmSV6WzLMhzyt1HQIzat8g References: <1266047791.3643.48.camel@dellx1> From: "Mathilde Durvy (mdurvy)" To: "Geoff Mulligan" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 24 Feb 2010 12:53:30.0750 (UTC) FILETIME=[5DB2F1E0:01CAB550] Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 24 Feb 2010 12:51:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1733_01CAB558.BF140430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I believe the document is ready to go to the IESG. Best, Mathilde=20 -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Geoff Mulligan Sent: samedi, 13. f=E9vrier 2010 08:57 To: 6lowpan Subject: [6lowpan] WGLC for 6lowpan HC draft This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in = 6LoWPAN Networks". The document can be found at: http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt The document is intended to be submitted by this Working Group to the = IESG for publication as a Standards Track document. Please review the document carefully (one last time), and send your = comments to the 6lowpan list. Please also indicate in your response whether or = not you think this document is ready to go to the IESG. ------=_NextPart_000_1733_01CAB558.BF140430 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5 1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/ BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG 49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDIyNDEyNTMzMFowIwYJKoZI hvcNAQkEMRYEFJQ8PSj/6x/+rKqtwzTvHwEVhzzCMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGALYzB l6G9cEGr70VHQnNF7wUHPXMIeQfaCBt1kqtEmEl8ot7f34uxg+NAiIRb2fNlJ88Vll1SK1YBZHw1 d8K59JjylbEDRHgZCIwLUSFjgoHUD/olo0g1bkL4fEzdTg6tdQzdCtgg0FxW5Cxa3j1JW9QHIybJ InPcQpCxk1g6E6kAAAAAAAA= ------=_NextPart_000_1733_01CAB558.BF140430-- From jreddy@ti.com Wed Feb 24 10:59:57 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DC928C285 for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 10:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSVeEQ9RY5Sc for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 10:59:57 -0800 (PST) Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by core3.amsl.com (Postfix) with ESMTP id D91A228C25D for <6lowpan@ietf.org>; Wed, 24 Feb 2010 10:59:56 -0800 (PST) Received: from dlep36.itg.ti.com ([157.170.170.91]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id o1OJ24GX008024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Wed, 24 Feb 2010 13:02:04 -0600 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep36.itg.ti.com (8.13.8/8.13.8) with ESMTP id o1OJ208J024886 for <6lowpan@ietf.org>; Wed, 24 Feb 2010 13:02:00 -0600 (CST) Received: from dlee73.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o1OJ208W003091 for <6lowpan@ietf.org>; Wed, 24 Feb 2010 13:02:00 -0600 (CST) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee73.ent.ti.com ([157.170.170.88]) with mapi; Wed, 24 Feb 2010 13:02:00 -0600 From: "Reddy, Joseph" To: "6lowpan@ietf.org" <6lowpan@ietf.org> Date: Wed, 24 Feb 2010 13:01:57 -0600 Thread-Topic: [6lowpan] WGLC for 6lowpan HC draft Thread-Index: Acqs517HelMLDaJOTcujpgTSdbU2oQIm6Huw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 24 Feb 2010 18:59:57 -0000 =20 Hi Geoff, I do not support forwarding this doc to IESG yet. I would like the followin= g issues addressed=20 ** Investigate possible TCP header compression scheme ** Explain strategy for compressing RPL headers ( I understand this could b= e done in the ROLL group, but I have not seen a definite statement either w= ay ) ** Resolve the "forward compatability" issue ( ideally, while maintaining b= ackwards-comptability ) -Regards, Joseph ---------------------------------------------------------------------- Message: 1 Date: Sat, 13 Feb 2010 00:56:31 -0700 From: Geoff Mulligan Subject: [6lowpan] WGLC for 6lowpan HC draft To: 6lowpan <6lowpan@ietf.org> Message-ID: <1266047791.3643.48.camel@dellx1> Content-Type: text/plain Folks, I realized that I have made a huge slip-up. The HC draft has languished = for the past few months. At the meeting in Hiroshima we said that we would last call this draft, but= I failed to send out the actual last call. So... This note formally starts the WG Last Call for comments on draft-ietf-6lo= wpan-hc-06, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks". The document can be found at: http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt The document is intended to be submitted by this Working Group to the IESG = for publication as a Standards Track document. Please review the document carefully (one last time), and send your comment= s to the 6lowpan list. Please also indicate in your response whether or no= t you think this document is ready to go to the IESG. Because of my gaffe this Last Call will end Wednesday February 24 2010 at 2= 359 UTC. Thanks, Geoff ************************************** From osk@exegin.com Wed Feb 24 11:13:06 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DDA53A8563 for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 11:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSY7oN2rRsv6 for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 11:13:04 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id DA2E03A848E for <6lowpan@ietf.org>; Wed, 24 Feb 2010 11:13:04 -0800 (PST) Received: by pwi3 with SMTP id 3so5267915pwi.31 for <6lowpan@ietf.org>; Wed, 24 Feb 2010 11:15:09 -0800 (PST) Received: by 10.114.6.17 with SMTP id 17mr132390waf.96.1267038909619; Wed, 24 Feb 2010 11:15:09 -0800 (PST) Received: from ?172.16.1.66? (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 20sm1099469pzk.15.2010.02.24.11.15.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Feb 2010 11:15:08 -0800 (PST) Message-ID: <4B857ABA.90406@exegin.com> Date: Wed, 24 Feb 2010 11:15:06 -0800 From: Owen Kirby Organization: Exegin Technologies Limited User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Geoff Mulligan References: <1266047791.3643.48.camel@dellx1> In-Reply-To: <1266047791.3643.48.camel@dellx1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 24 Feb 2010 19:13:06 -0000 Geoff, I do not support draft-ietf-6lowpan-hc-06 for IESG submission until there is a resolution for: A) The forward compatibility issues raised by Richard Kelsey, and B) The use of fragmentation when compressed headers extend beyond the first fragment, or an explicit statement that compressed headers must fit within the first fragment. Thanks, Owen Kirby Geoff Mulligan wrote: > Folks, > I realized that I have made a huge slip-up. The HC draft has languished for the past few months. > At the meeting in Hiroshima we said that we would last call this draft, but I failed to send out the > actual last call. So... > > This note formally starts the WG Last Call for comments on > draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks". > > The document can be found at: > http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt > > The document is intended to be submitted by this Working Group to the > IESG for publication as a Standards Track document. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > Because of my gaffe this Last Call will end Wednesday February 24 2010 > at 2359 UTC. > > Thanks, > Geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From rstruik@certicom.com Wed Feb 24 12:59:05 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6BD28C159 for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 12:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQLixhhRy6eT for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 12:59:04 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 879243A8594 for <6lowpan@ietf.org>; Wed, 24 Feb 2010 12:59:03 -0800 (PST) X-AuditID: 0a666446-b7bb9ae000000a25-71-4b8593967140 Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 87.55.02597.693958B4; Wed, 24 Feb 2010 16:01:10 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 16:01:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Feb 2010 16:00:41 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC404272347@XCH57YKF.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WGLC for 6lowpan HC draft Thread-Index: Acqs517HelMLDaJOTcujpgTSdbU2oQIm6HuwAAQp9eA= References: From: "Rene Struik" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 24 Feb 2010 21:01:10.0447 (UTC) FILETIME=[7DD663F0:01CAB594] X-Brightmail-Tracker: AAAAAA== Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 24 Feb 2010 20:59:05 -0000 Hi Geoff: When studying details of the RoLL protocol, a similar question as the one raised by Joseph Reddy came to mind: how are we going to ensure that all packets are not going to be as bulky as they seem right now (from rpl-6, it seems one may use tens of bytes in various packets, seemingly without any technical need). As I understood from the RPL Security conf call as of Tue Feb 23, 2010, 12-1pm EST, compression of IPv6 packets is not in RoLL's charter and would be 6lowpan's responsibility. So, at this time, I would like this issue to be adequately addressed (if not 6lowpan, who is going to do this), prior to moving this forward to IESG. Best regards, Rene -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Reddy, Joseph Sent: Wednesday, February 24, 2010 2:02 PM To: 6lowpan@ietf.org Subject: Re: [6lowpan] WGLC for 6lowpan HC draft =20 Hi Geoff, I do not support forwarding this doc to IESG yet. I would like the following issues addressed=20 ** Investigate possible TCP header compression scheme ** Explain strategy for compressing RPL headers ( I understand this could be done in the ROLL group, but I have not seen a definite statement either way ) ** Resolve the "forward compatability" issue ( ideally, while maintaining backwards-comptability ) -Regards, Joseph ---------------------------------------------------------------------- Message: 1 Date: Sat, 13 Feb 2010 00:56:31 -0700 From: Geoff Mulligan Subject: [6lowpan] WGLC for 6lowpan HC draft To: 6lowpan <6lowpan@ietf.org> Message-ID: <1266047791.3643.48.camel@dellx1> Content-Type: text/plain Folks, I realized that I have made a huge slip-up. The HC draft has languished for the past few months. At the meeting in Hiroshima we said that we would last call this draft, but I failed to send out the actual last call. So... This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks". The document can be found at: http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt The document is intended to be submitted by this Working Group to the IESG for publication as a Standards Track document. Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. Because of my gaffe this Last Call will end Wednesday February 24 2010 at 2359 UTC. Thanks, Geoff ************************************** _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From robert.cragie@gridmerge.com Wed Feb 24 22:53:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A873A7B35 for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 22:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zwuf1ozDXbk for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 22:53:17 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id D9DB23A7B06 for <6lowpan@ietf.org>; Wed, 24 Feb 2010 22:53:16 -0800 (PST) Received: from client-82-26-112-155.midd.adsl.virginmedia.com ([82.26.112.155] helo=[192.168.1.64]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NkXd5-0000Qy-Nl; Thu, 25 Feb 2010 06:55:24 +0000 Message-ID: <4B861ED4.3070200@gridmerge.com> Date: Thu, 25 Feb 2010 06:55:16 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Reddy, Joseph" References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060508050001030601010400" Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 06:53:18 -0000 This is a cryptographically signed message in MIME format. --------------ms060508050001030601010400 Content-Type: multipart/alternative; boundary="------------050500070900030903040500" This is a multi-part message in MIME format. --------------050500070900030903040500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Geoff, I concur with Joseph's statements and thus do not support forwarding the draft to IESG yet. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Reddy, Joseph wrote: > > Hi Geoff, > > I do not support forwarding this doc to IESG yet. I would like the following issues addressed > > ** Investigate possible TCP header compression scheme > > ** Explain strategy for compressing RPL headers ( I understand this could be done in the ROLL group, but I have not seen a definite statement either way ) > > ** Resolve the "forward compatability" issue ( ideally, while maintaining backwards-comptability ) > > > -Regards, Joseph > > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 13 Feb 2010 00:56:31 -0700 > From: Geoff Mulligan > Subject: [6lowpan] WGLC for 6lowpan HC draft > To: 6lowpan <6lowpan@ietf.org> > Message-ID: <1266047791.3643.48.camel@dellx1> > Content-Type: text/plain > > Folks, > I realized that I have made a huge slip-up. The HC draft has languished for the past few months. > At the meeting in Hiroshima we said that we would last call this draft, but I failed to send out the actual last call. So... > > This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks". > > The document can be found at: > http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt > > The document is intended to be submitted by this Working Group to the IESG for publication as a Standards Track document. > > Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. > > Because of my gaffe this Last Call will end Wednesday February 24 2010 at 2359 UTC. > > Thanks, > Geoff > > > > > > ************************************** > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > --------------050500070900030903040500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Geoff,

I concur with Joseph's statements and thus do not support forwarding the draft to IESG yet.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com



Reddy, Joseph wrote: 
 
Hi Geoff,

I do not support forwarding this doc to IESG yet. I would like the following issues addressed 

** Investigate possible TCP header compression scheme

** Explain strategy for compressing RPL headers ( I understand this could be done in the ROLL group, but I have not seen a definite statement either way )

** Resolve the "forward compatability" issue ( ideally, while maintaining backwards-comptability )


-Regards, Joseph



----------------------------------------------------------------------

Message: 1
Date: Sat, 13 Feb 2010 00:56:31 -0700
From: Geoff Mulligan <geoff@proto6.com>
Subject: [6lowpan] WGLC for 6lowpan HC draft
To: 6lowpan <6lowpan@ietf.org>
Message-ID: <1266047791.3643.48.camel@dellx1>
Content-Type: text/plain

Folks,
  I realized that I have made a huge slip-up.  The HC draft has languished for the past few months.
At the meeting in Hiroshima we said that we would last call this draft, but I failed to send out the actual last call. So...

  This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks".

The document can be found at:
http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt

The document is intended to be submitted by this Working Group to the IESG for publication as a Standards Track document.

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

Because of my gaffe this Last Call will end Wednesday February 24 2010 at 2359 UTC.

        Thanks,
                Geoff





**************************************
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--------------050500070900030903040500-- --------------ms060508050001030601010400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAy MjUwNjU1MTZaMCMGCSqGSIb3DQEJBDEWBBQxuoIFBSJadr08Oxbm6xgF7lJkeTBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAGE5K3y53d3hRh6t3XaVaWjfpcx9IeAVxU0GSRC2PYl5ZXLOgJhyMtMletbOcLZc6Z80 xWt1m9LF9eb363CUwUVN2rygkCx6uuw3Aw5gsg9jFpzoEUA55LLnWbUfyvAF7RUneuZgke4n jxmGoa0MMAbP0pXo/TGavOIJ2AQ2V5WMXbnVi++Vi3lfJ4YozNbC0q9l3CKgiBXE7YrHb0l5 b/pieZmVYlurK0N/sK2PZQJCYJg8gzDEPtqyBTP5vA3Zar13fZB/ozddnvZIW0l+h3Zg3U8D oMG9Ar27UP57YB98c/aHJdCxSpFVnKOSXNsQ1/lZAlhoMHhlnGgb3ssi+MkAAAAAAAA= --------------ms060508050001030601010400-- From jhui@archrock.com Wed Feb 24 23:19:27 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6FA3A851D for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 23:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uezlHoYOeaYl for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 23:19:25 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 27EDC3A8517 for <6lowpan@ietf.org>; Wed, 24 Feb 2010 23:19:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B59CBAF918; Wed, 24 Feb 2010 23:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyU+LclSFoia; Wed, 24 Feb 2010 23:21:30 -0800 (PST) Received: from [10.0.1.5] (adsl-71-142-67-144.dsl.pltn13.pacbell.net [71.142.67.144]) by mail.sf.archrock.com (Postfix) with ESMTP id 32775AF914; Wed, 24 Feb 2010 23:21:30 -0800 (PST) Message-Id: <260AAC3E-D813-4F0C-889D-1FA2AB2C11BA@archrock.com> From: Jonathan Hui To: robert.cragie@gridmerge.com In-Reply-To: <4B861ED4.3070200@gridmerge.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Feb 2010 23:21:28 -0800 References: <4B861ED4.3070200@gridmerge.com> X-Mailer: Apple Mail (2.936) Cc: "6lowpan@ietf.org" <6lowpan@ietf.org>, "Reddy, Joseph" Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 25 Feb 2010 07:19:27 -0000 It would be helpful to know what people's expectations are relative to what this specific draft should include relative to an acceptable timeline of getting a document out. Few comments: - The WG currently does not have a proposal for TCP header compression, let alone one that we have built some consensus around. - The RPL protocol mechanisms and headers are still in flux. It is difficult to propose a concrete way of compressing them without knowing what they will look like. For example, within ROLL, we will be proposing ways to "pack" lists of addresses such that common prefixes are only carried once within the datagram. - The general 6lowpan-hc format is generic enough to be used on top of other fragmentation mechanisms and/or frame sizes. Do we really want to limit its capabilities to a particular fragmentation and frame size? There always seems to be a tension between splitting functionality across different drafts vs. delaying the current draft to "sneak" in new functionality. I'm all for sneaking in fixes to RFC 4944 (i.e. simple changes to fragmentation) or additional functionality for expediency if we can realize that expedience. But waiting until we design a TCP header compression mechanism that we can build consensus around probably isn't the best approach, in my opinion, and should be left to a separate draft. So what do others think? (I will start a new thread specifically on fragmentation + forward- compatibility so that we drive towards closure on that specific issue). -- Jonathan Hui On Feb 24, 2010, at 10:55 PM, Robert Cragie wrote: > Hi Geoff, > > I concur with Joseph's statements and thus do not support forwarding > the draft to IESG yet. > > Robert > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > > Reddy, Joseph wrote: >> >> >> Hi Geoff, >> >> I do not support forwarding this doc to IESG yet. I would like the >> following issues addressed >> >> ** Investigate possible TCP header compression scheme >> >> ** Explain strategy for compressing RPL headers ( I understand this >> could be done in the ROLL group, but I have not seen a definite >> statement either way ) >> >> ** Resolve the "forward compatability" issue ( ideally, while >> maintaining backwards-comptability ) >> >> >> -Regards, Joseph >> >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sat, 13 Feb 2010 00:56:31 -0700 >> From: Geoff Mulligan >> Subject: [6lowpan] WGLC for 6lowpan HC draft >> To: 6lowpan <6lowpan@ietf.org> >> Message-ID: <1266047791.3643.48.camel@dellx1> >> Content-Type: text/plain >> >> Folks, >> I realized that I have made a huge slip-up. The HC draft has >> languished for the past few months. >> At the meeting in Hiroshima we said that we would last call this >> draft, but I failed to send out the actual last call. So... >> >> This note formally starts the WG Last Call for comments on draft- >> ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in >> 6LoWPAN Networks". >> >> The document can be found at: >> http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt >> >> The document is intended to be submitted by this Working Group to >> the IESG for publication as a Standards Track document. >> >> Please review the document carefully (one last time), and send your >> comments to the 6lowpan list. Please also indicate in your >> response whether or not you think this document is ready to go to >> the IESG. >> >> Because of my gaffe this Last Call will end Wednesday February 24 >> 2010 at 2359 UTC. >> >> Thanks, >> Geoff >> >> >> >> >> >> ************************************** >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Wed Feb 24 23:42:22 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4444628C155 for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 23:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdgp7dTVoM4O for <6lowpan@core3.amsl.com>; Wed, 24 Feb 2010 23:42:21 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 100E43A8411 for <6lowpan@ietf.org>; Wed, 24 Feb 2010 23:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o1P7iKR7013513; Thu, 25 Feb 2010 08:44:20 +0100 (CET) Received: from [192.168.217.101] (p5489CF27.dip.t-dialin.net [84.137.207.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 7FFFBE299; Thu, 25 Feb 2010 08:44:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 25 Feb 2010 08:44:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62FB7C9C-A479-4FB9-BAF1-1DFC7030B5EB@tzi.org> References: To: "Reddy, Joseph" X-Mailer: Apple Mail (2.1077) Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 25 Feb 2010 07:42:22 -0000 > ** Investigate possible TCP header compression scheme >=20 > ** Explain strategy for compressing RPL headers ( I understand this = could be done in the ROLL group, but I have not seen a definite = statement either way ) Joseph, I appreciate your comments. I do have to point out that the work item on header compression this WG = was chartered with has a defined scope: > 2. Produce "6LoWPAN Improved Header Compression" to describe > mechanisms to allow enhancements to the 6LoWPAN headers. Specifically > this document will describe compression of addresses that are not > link-local. Additionally this document may include other enhancements > or optimizations of the HC1 or HC2 6LoWPAN headers. The one feature that was explicitly called out was compressing global = addresses, and I haven't heard any complaints on the way HC-06 addresses = that item. There are also "other enhancements or optimizations" in HC-06, in the = rather subordinate sense this was meant here. Having been part of the five-year effort that produced RFC4996, I'm = pretty sure TCP header compression would be on a different timeline, and = on a different scale altogether. =20 It is way beyond what we had in mind when we discussed and agreed the = above charter item. (Yes, a less complex and less efficient form of header compression than = RFC4996 can be found, but this is still likely to be a couple years of = effort.) I also believe that RPL might very well address its header space = problems in its own protocol -- in any case, with RPL still being in = flux, covering RPL would also be a different timeline. We have to deliver on our commitments before we start new work. We are already late meeting our milestone: > Aug 2008 Submit Improved Header Compression document to = IESG for consideration as a proposed standard Now re: > ** Resolve the "forward compatability" issue ( ideally, while = maintaining backwards-comptability ) I think this comment is the key to resolving the above issues -- can we = discuss now how we would embrace, e.g., TCP header compression (or RPL = compression if header size issues are not addressed by RPL), later? Gruesse, Carsten From coflynn@newae.com Thu Feb 25 01:33:26 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220CB28C2EC for <6lowpan@core3.amsl.com>; Thu, 25 Feb 2010 01:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc9cSENvdVIm for <6lowpan@core3.amsl.com>; Thu, 25 Feb 2010 01:33:24 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id B6B8A28C2F1 for <6lowpan@ietf.org>; Thu, 25 Feb 2010 01:33:24 -0800 (PST) Received: from 94-193-240-194.zone7.bethere.co.uk ([94.193.240.194] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nka79-00016o-S0; Thu, 25 Feb 2010 04:34:36 -0500 From: "Colin O'Flynn" To: "'Jonathan Hui'" References: <4B861ED4.3070200@gridmerge.com> <260AAC3E-D813-4F0C-889D-1FA2AB2C11BA@archrock.com> In-Reply-To: <260AAC3E-D813-4F0C-889D-1FA2AB2C11BA@archrock.com> Date: Thu, 25 Feb 2010 09:35:20 -0000 Message-ID: <001b01cab5fd$db076a10$91163e30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq16wnPyzFt/uxWSMS9Kayw9nsriAADnzOA Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 25 Feb 2010 09:33:26 -0000 Hi Jonathan, I support your comments completely here. Adding TCP compression in another draft would give us lots of time to design & test it, as the TCP compression will be more complex than UDP. I think almost any node will need to support UDP as a matter of normal operation. But not all nodes will support TCP, many may just use UDP. Hence it makes sense for that reason to keep TCP out of the HC. In addition I would like to see the issue of MUSTs worked out. The current I-D doesn't explicitly specify what features / addressing modes you must support. Having this document moving towards RFC status would be a great boost to implementers & 6LoWPAN. Then you can simply say you support "RFC4944 + RFCDEADBEEF", and other people know what frame format you are using. Right now it's "well I support -hc-01" and someone else supports -05, and someone else supports -06 but not all functions. Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: February 25, 2010 7:21 AM To: robert.cragie@gridmerge.com Cc: 6lowpan@ietf.org; Reddy, Joseph Subject: Re: [6lowpan] WGLC for 6lowpan HC draft It would be helpful to know what people's expectations are relative to what this specific draft should include relative to an acceptable timeline of getting a document out. Few comments: - The WG currently does not have a proposal for TCP header compression, let alone one that we have built some consensus around. - The RPL protocol mechanisms and headers are still in flux. It is difficult to propose a concrete way of compressing them without knowing what they will look like. For example, within ROLL, we will be proposing ways to "pack" lists of addresses such that common prefixes are only carried once within the datagram. - The general 6lowpan-hc format is generic enough to be used on top of other fragmentation mechanisms and/or frame sizes. Do we really want to limit its capabilities to a particular fragmentation and frame size? There always seems to be a tension between splitting functionality across different drafts vs. delaying the current draft to "sneak" in new functionality. I'm all for sneaking in fixes to RFC 4944 (i.e. simple changes to fragmentation) or additional functionality for expediency if we can realize that expedience. But waiting until we design a TCP header compression mechanism that we can build consensus around probably isn't the best approach, in my opinion, and should be left to a separate draft. So what do others think? (I will start a new thread specifically on fragmentation + forward- compatibility so that we drive towards closure on that specific issue). -- Jonathan Hui On Feb 24, 2010, at 10:55 PM, Robert Cragie wrote: > Hi Geoff, > > I concur with Joseph's statements and thus do not support forwarding > the draft to IESG yet. > > Robert > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > > Reddy, Joseph wrote: >> >> >> Hi Geoff, >> >> I do not support forwarding this doc to IESG yet. I would like the >> following issues addressed >> >> ** Investigate possible TCP header compression scheme >> >> ** Explain strategy for compressing RPL headers ( I understand this >> could be done in the ROLL group, but I have not seen a definite >> statement either way ) >> >> ** Resolve the "forward compatability" issue ( ideally, while >> maintaining backwards-comptability ) >> >> >> -Regards, Joseph >> >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sat, 13 Feb 2010 00:56:31 -0700 >> From: Geoff Mulligan >> Subject: [6lowpan] WGLC for 6lowpan HC draft >> To: 6lowpan <6lowpan@ietf.org> >> Message-ID: <1266047791.3643.48.camel@dellx1> >> Content-Type: text/plain >> >> Folks, >> I realized that I have made a huge slip-up. The HC draft has >> languished for the past few months. >> At the meeting in Hiroshima we said that we would last call this >> draft, but I failed to send out the actual last call. So... >> >> This note formally starts the WG Last Call for comments on draft- >> ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in >> 6LoWPAN Networks". >> >> The document can be found at: >> http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt >> >> The document is intended to be submitted by this Working Group to >> the IESG for publication as a Standards Track document. >> >> Please review the document carefully (one last time), and send your >> comments to the 6lowpan list. Please also indicate in your >> response whether or not you think this document is ready to go to >> the IESG. >> >> Because of my gaffe this Last Call will end Wednesday February 24 >> 2010 at 2359 UTC. >> >> Thanks, >> Geoff >> >> >> >> >> >> ************************************** >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From daniel.gavelle@jennic.com Thu Feb 25 06:16:01 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F6A28C32D for <6lowpan@core3.amsl.com>; Thu, 25 Feb 2010 06:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH6N+x88xzYh for <6lowpan@core3.amsl.com>; Thu, 25 Feb 2010 06:15:59 -0800 (PST) Received: from mail.jennic.com (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id 5E61828C15E for <6lowpan@ietf.org>; Thu, 25 Feb 2010 06:15:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id A8D10D6BB3 for <6lowpan@ietf.org>; Thu, 25 Feb 2010 14:18:07 +0000 (GMT) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbrzSg7SXCgF for <6lowpan@ietf.org>; Thu, 25 Feb 2010 14:18:07 +0000 (GMT) Received: from [10.99.98.20] (dgave.jennic.com [10.99.98.20]) by mail.jennic.com (Postfix) with ESMTP id 53C48D6BB1 for <6lowpan@ietf.org>; Thu, 25 Feb 2010 14:18:07 +0000 (GMT) Message-ID: <4B86869F.9010103@jennic.com> Date: Thu, 25 Feb 2010 14:18:07 +0000 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "6lowpan@ietf.org" <6lowpan@ietf.org> References: <4B861ED4.3070200@gridmerge.com> <260AAC3E-D813-4F0C-889D-1FA2AB2C11BA@archrock.com> In-Reply-To: <260AAC3E-D813-4F0C-889D-1FA2AB2C11BA@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 14:16:01 -0000 On the subject of forward and backward compatibility, I think the dispatch codes for fragmentation (FRAG1, FRAGN) should be changed to values that are currently reserved if we move to sending the datagram_size and datagram_offset as compressed and uncompressed values. This will mean that during the transition period, it will be much easier to sort out interoperability problems where some nodes use compressed values and some nodes are running older code using uncompressed values. I don't think the new nodes should support both compressed and uncompressed offsets / sizes but should simply reject fragments that don't have the dispatch codes they are expecting. The existing dispatch codes would not be lost forever as they could be strongly deprecated and then recycled in a future RFC. Daniel. Jonathan Hui wrote: > > It would be helpful to know what people's expectations are relative to > what this specific draft should include relative to an acceptable > timeline of getting a document out. Few comments: > > - The WG currently does not have a proposal for TCP header compression, > let alone one that we have built some consensus around. > - The RPL protocol mechanisms and headers are still in flux. It is > difficult to propose a concrete way of compressing them without knowing > what they will look like. For example, within ROLL, we will be > proposing ways to "pack" lists of addresses such that common prefixes > are only carried once within the datagram. > - The general 6lowpan-hc format is generic enough to be used on top of > other fragmentation mechanisms and/or frame sizes. Do we really want to > limit its capabilities to a particular fragmentation and frame size? > > There always seems to be a tension between splitting functionality > across different drafts vs. delaying the current draft to "sneak" in new > functionality. I'm all for sneaking in fixes to RFC 4944 (i.e. simple > changes to fragmentation) or additional functionality for expediency if > we can realize that expedience. But waiting until we design a TCP > header compression mechanism that we can build consensus around probably > isn't the best approach, in my opinion, and should be left to a separate > draft. > > So what do others think? > > (I will start a new thread specifically on fragmentation + > forward-compatibility so that we drive towards closure on that specific > issue). > > -- > Jonathan Hui > > On Feb 24, 2010, at 10:55 PM, Robert Cragie wrote: > >> Hi Geoff, >> >> I concur with Joseph's statements and thus do not support forwarding >> the draft to IESG yet. >> >> Robert >> Robert Cragie (Pacific Gas & Electric) >> >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 (0) 1924 910888 >> http://www.gridmerge.com >> >> >> >> Reddy, Joseph wrote: >>> >>> >>> Hi Geoff, >>> >>> I do not support forwarding this doc to IESG yet. I would like the >>> following issues addressed >>> >>> ** Investigate possible TCP header compression scheme >>> >>> ** Explain strategy for compressing RPL headers ( I understand this >>> could be done in the ROLL group, but I have not seen a definite >>> statement either way ) >>> >>> ** Resolve the "forward compatability" issue ( ideally, while >>> maintaining backwards-comptability ) >>> >>> >>> -Regards, Joseph >>> >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Sat, 13 Feb 2010 00:56:31 -0700 >>> From: Geoff Mulligan >>> Subject: [6lowpan] WGLC for 6lowpan HC draft >>> To: 6lowpan <6lowpan@ietf.org> >>> Message-ID: <1266047791.3643.48.camel@dellx1> >>> Content-Type: text/plain >>> >>> Folks, >>> I realized that I have made a huge slip-up. The HC draft has >>> languished for the past few months. >>> At the meeting in Hiroshima we said that we would last call this >>> draft, but I failed to send out the actual last call. So... >>> >>> This note formally starts the WG Last Call for comments on >>> draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in >>> 6LoWPAN Networks". >>> >>> The document can be found at: >>> http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt >>> >>> The document is intended to be submitted by this Working Group to the >>> IESG for publication as a Standards Track document. >>> >>> Please review the document carefully (one last time), and send your >>> comments to the 6lowpan list. Please also indicate in your response >>> whether or not you think this document is ready to go to the IESG. >>> >>> Because of my gaffe this Last Call will end Wednesday February 24 >>> 2010 at 2359 UTC. >>> >>> Thanks, >>> Geoff >>> >>> >>> >>> >>> >>> ************************************** >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From pthubert@cisco.com Thu Feb 25 09:22:17 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9D663A84F2 for <6lowpan@core3.amsl.com>; Thu, 25 Feb 2010 09:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.559 X-Spam-Level: X-Spam-Status: No, score=-9.559 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxV77geA1EmE for <6lowpan@core3.amsl.com>; Thu, 25 Feb 2010 09:22:16 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3B30E3A83F6 for <6lowpan@ietf.org>; Thu, 25 Feb 2010 09:22:16 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP5AhktAZnwN/2dsb2JhbACbF3OkK4pwCY1lgmmCDAQ X-IronPort-AV: E=Sophos;i="4.49,540,1262563200"; d="scan'208";a="214226085" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2010 17:24:27 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1PHOQMC015020; Thu, 25 Feb 2010 17:24:26 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Feb 2010 18:24:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Feb 2010 18:23:25 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0151C0EE@XMB-AMS-107.cisco.com> In-Reply-To: <4B86869F.9010103@jennic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WGLC for 6lowpan HC draft Thread-Index: Acq2JXKT6Hl9GtE3Rt+urri2BPy8YQAGF2Ww References: <4B861ED4.3070200@gridmerge.com><260AAC3E-D813-4F0C-889D-1FA2AB2C11BA@archrock.com> <4B86869F.9010103@jennic.com> From: "Pascal Thubert (pthubert)" To: , <6lowpan@ietf.org> X-OriginalArrivalTime: 25 Feb 2010 17:24:25.0996 (UTC) FILETIME=[60FE64C0:01CAB63F] Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 25 Feb 2010 17:22:17 -0000 Hi Daniel: I agree that we need to rework fragments for sure, but I'd think that: - there's more to do than just swap from uncompressed offsets to compressed - this is not the right draft to discuss fragmentations My suggestion is that we add some lines that explain the problem and suggest to limit the compressed piece to the first fragment if the RFC4944 fragmentation is used, and move forward with this draft. And then let's work (separately) on fragments. Lots to do there: - recovery - ECN - forwarding in route over mode ... And then we can work on compressing TCP, RPL, routing headers, etc..., all things in due time with due priority, as determined by our (re)charter.=20 Pascal -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Daniel Gavelle Sent: Thursday, February 25, 2010 3:18 PM To: 6lowpan@ietf.org Subject: Re: [6lowpan] WGLC for 6lowpan HC draft On the subject of forward and backward compatibility, I think the dispatch codes for fragmentation (FRAG1, FRAGN) should be changed to values that are currently reserved if we move to sending the datagram_size and datagram_offset as compressed and uncompressed values. This will mean that during the transition period, it will be much easier to sort out interoperability problems where some nodes use compressed values and some nodes are running older code using uncompressed values. I don't think the new nodes should support both compressed and uncompressed offsets / sizes but should simply reject fragments that don't have the dispatch codes they are expecting. The existing dispatch codes would not be lost forever as they could be strongly deprecated and then recycled in a future RFC. Daniel. Jonathan Hui wrote: >=20 > It would be helpful to know what people's expectations are relative to > what this specific draft should include relative to an acceptable=20 > timeline of getting a document out. Few comments: >=20 > - The WG currently does not have a proposal for TCP header=20 > compression, let alone one that we have built some consensus around. > - The RPL protocol mechanisms and headers are still in flux. It is=20 > difficult to propose a concrete way of compressing them without=20 > knowing what they will look like. For example, within ROLL, we will=20 > be proposing ways to "pack" lists of addresses such that common=20 > prefixes are only carried once within the datagram. > - The general 6lowpan-hc format is generic enough to be used on top of > other fragmentation mechanisms and/or frame sizes. Do we really want=20 > to limit its capabilities to a particular fragmentation and frame size? >=20 > There always seems to be a tension between splitting functionality=20 > across different drafts vs. delaying the current draft to "sneak" in=20 > new functionality. I'm all for sneaking in fixes to RFC 4944 (i.e.=20 > simple changes to fragmentation) or additional functionality for=20 > expediency if we can realize that expedience. But waiting until we=20 > design a TCP header compression mechanism that we can build consensus=20 > around probably isn't the best approach, in my opinion, and should be=20 > left to a separate draft. >=20 > So what do others think? >=20 > (I will start a new thread specifically on fragmentation +=20 > forward-compatibility so that we drive towards closure on that=20 > specific issue). >=20 > -- > Jonathan Hui >=20 > On Feb 24, 2010, at 10:55 PM, Robert Cragie wrote: >=20 >> Hi Geoff, >> >> I concur with Joseph's statements and thus do not support forwarding=20 >> the draft to IESG yet. >> >> Robert >> Robert Cragie (Pacific Gas & Electric) >> >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 (0) 1924 910888 >> http://www.gridmerge.com >> >> >> >> Reddy, Joseph wrote: >>> >>> >>> Hi Geoff, >>> >>> I do not support forwarding this doc to IESG yet. I would like the=20 >>> following issues addressed >>> >>> ** Investigate possible TCP header compression scheme >>> >>> ** Explain strategy for compressing RPL headers ( I understand this=20 >>> could be done in the ROLL group, but I have not seen a definite=20 >>> statement either way ) >>> >>> ** Resolve the "forward compatability" issue ( ideally, while=20 >>> maintaining backwards-comptability ) >>> >>> >>> -Regards, Joseph >>> >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> >>> Message: 1 >>> Date: Sat, 13 Feb 2010 00:56:31 -0700 >>> From: Geoff Mulligan >>> Subject: [6lowpan] WGLC for 6lowpan HC draft >>> To: 6lowpan <6lowpan@ietf.org> >>> Message-ID: <1266047791.3643.48.camel@dellx1> >>> Content-Type: text/plain >>> >>> Folks, >>> I realized that I have made a huge slip-up. The HC draft has=20 >>> languished for the past few months. >>> At the meeting in Hiroshima we said that we would last call this=20 >>> draft, but I failed to send out the actual last call. So... >>> >>> This note formally starts the WG Last Call for comments on=20 >>> draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in=20 >>> 6LoWPAN Networks". >>> >>> The document can be found at: >>> http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt >>> >>> The document is intended to be submitted by this Working Group to=20 >>> the IESG for publication as a Standards Track document. >>> >>> Please review the document carefully (one last time), and send your=20 >>> comments to the 6lowpan list. Please also indicate in your response >>> whether or not you think this document is ready to go to the IESG. >>> >>> Because of my gaffe this Last Call will end Wednesday February 24 >>> 2010 at 2359 UTC. >>> >>> Thanks, >>> Geoff >>> >>> >>> >>> >>> >>> ************************************** >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From daniel.gavelle@jennic.com Thu Feb 25 10:14:12 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37743A8702 for <6lowpan@core3.amsl.com>; Thu, 25 Feb 2010 10:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BoU9szVdPNa for <6lowpan@core3.amsl.com>; Thu, 25 Feb 2010 10:14:11 -0800 (PST) Received: from mail.jennic.com (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id B20AB3A8705 for <6lowpan@ietf.org>; Thu, 25 Feb 2010 10:14:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id D84A3D6BB3; Thu, 25 Feb 2010 18:16:17 +0000 (GMT) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGCYpgmt1pwO; Thu, 25 Feb 2010 18:16:17 +0000 (GMT) Received: from [10.99.98.20] (dgave.jennic.com [10.99.98.20]) by mail.jennic.com (Postfix) with ESMTP id ACF38D6BB1; Thu, 25 Feb 2010 18:16:17 +0000 (GMT) Message-ID: <4B86BE71.6000805@jennic.com> Date: Thu, 25 Feb 2010 18:16:17 +0000 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4B861ED4.3070200@gridmerge.com><260AAC3E-D813-4F0C-889D-1FA2AB2C11BA@archrock.com> <4B86869F.9010103@jennic.com> <6A2A459175DABE4BB11DE2026AA50A5D0151C0EE@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0151C0EE@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 18:14:13 -0000 Pascal, I am happy with HC-06 passing the last call and going to IESG unchanged, with the offset and length uncompressed. As you say, the fragmentation issues can be addressed by a separate draft. However, if the weight of opinion is that the change to compressed offsets should be made in the HC-06 draft then I think we should also change the dispatch headers to identify the change. Daniel. Pascal Thubert (pthubert) wrote: > Hi Daniel: > > I agree that we need to rework fragments for sure, but I'd think that: > > - there's more to do than just swap from uncompressed offsets to > compressed > - this is not the right draft to discuss fragmentations > > My suggestion is that we add some lines that explain the problem and > suggest to limit the compressed piece to the first fragment if the > RFC4944 fragmentation is used, and move forward with this draft. > > And then let's work (separately) on fragments. Lots to do there: > - recovery > - ECN > - forwarding in route over mode > ... > > And then we can work on compressing TCP, RPL, routing headers, etc..., > all things in due time with due priority, as determined by our > (re)charter. > > Pascal > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Daniel Gavelle > Sent: Thursday, February 25, 2010 3:18 PM > To: 6lowpan@ietf.org > Subject: Re: [6lowpan] WGLC for 6lowpan HC draft > > On the subject of forward and backward compatibility, I think the > dispatch codes for fragmentation (FRAG1, FRAGN) should be changed to > values that are currently reserved if we move to sending the > datagram_size and datagram_offset as compressed and uncompressed values. > > This will mean that during the transition period, it will be much > easier to sort out interoperability problems where some nodes use > compressed values and some nodes are running older code using > uncompressed values. > > I don't think the new nodes should support both compressed and > uncompressed offsets / sizes but should simply reject fragments that > don't have the dispatch codes they are expecting. > > The existing dispatch codes would not be lost forever as they could be > strongly deprecated and then recycled in a future RFC. > > Daniel. > > > > Jonathan Hui wrote: >> It would be helpful to know what people's expectations are relative to > >> what this specific draft should include relative to an acceptable >> timeline of getting a document out. Few comments: >> >> - The WG currently does not have a proposal for TCP header >> compression, let alone one that we have built some consensus around. >> - The RPL protocol mechanisms and headers are still in flux. It is >> difficult to propose a concrete way of compressing them without >> knowing what they will look like. For example, within ROLL, we will >> be proposing ways to "pack" lists of addresses such that common >> prefixes are only carried once within the datagram. >> - The general 6lowpan-hc format is generic enough to be used on top of > >> other fragmentation mechanisms and/or frame sizes. Do we really want >> to limit its capabilities to a particular fragmentation and frame > size? >> There always seems to be a tension between splitting functionality >> across different drafts vs. delaying the current draft to "sneak" in >> new functionality. I'm all for sneaking in fixes to RFC 4944 (i.e. >> simple changes to fragmentation) or additional functionality for >> expediency if we can realize that expedience. But waiting until we >> design a TCP header compression mechanism that we can build consensus >> around probably isn't the best approach, in my opinion, and should be >> left to a separate draft. >> >> So what do others think? >> >> (I will start a new thread specifically on fragmentation + >> forward-compatibility so that we drive towards closure on that >> specific issue). >> >> -- >> Jonathan Hui >> >> On Feb 24, 2010, at 10:55 PM, Robert Cragie wrote: >> >>> Hi Geoff, >>> >>> I concur with Joseph's statements and thus do not support forwarding >>> the draft to IESG yet. >>> >>> Robert >>> Robert Cragie (Pacific Gas & Electric) >>> >>> Gridmerge Ltd. >>> 89 Greenfield Crescent, >>> Wakefield, WF4 4WA, UK >>> +44 (0) 1924 910888 >>> http://www.gridmerge.com >>> >>> >>> >>> Reddy, Joseph wrote: >>>> >>>> Hi Geoff, >>>> >>>> I do not support forwarding this doc to IESG yet. I would like the >>>> following issues addressed >>>> >>>> ** Investigate possible TCP header compression scheme >>>> >>>> ** Explain strategy for compressing RPL headers ( I understand this >>>> could be done in the ROLL group, but I have not seen a definite >>>> statement either way ) >>>> >>>> ** Resolve the "forward compatability" issue ( ideally, while >>>> maintaining backwards-comptability ) >>>> >>>> >>>> -Regards, Joseph >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> -- >>>> >>>> Message: 1 >>>> Date: Sat, 13 Feb 2010 00:56:31 -0700 >>>> From: Geoff Mulligan >>>> Subject: [6lowpan] WGLC for 6lowpan HC draft >>>> To: 6lowpan <6lowpan@ietf.org> >>>> Message-ID: <1266047791.3643.48.camel@dellx1> >>>> Content-Type: text/plain >>>> >>>> Folks, >>>> I realized that I have made a huge slip-up. The HC draft has >>>> languished for the past few months. >>>> At the meeting in Hiroshima we said that we would last call this >>>> draft, but I failed to send out the actual last call. So... >>>> >>>> This note formally starts the WG Last Call for comments on >>>> draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in >>>> 6LoWPAN Networks". >>>> >>>> The document can be found at: >>>> http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt >>>> >>>> The document is intended to be submitted by this Working Group to >>>> the IESG for publication as a Standards Track document. >>>> >>>> Please review the document carefully (one last time), and send your >>>> comments to the 6lowpan list. Please also indicate in your response > >>>> whether or not you think this document is ready to go to the IESG. >>>> >>>> Because of my gaffe this Last Call will end Wednesday February 24 >>>> 2010 at 2359 UTC. >>>> >>>> Thanks, >>>> Geoff >>>> >>>> >>>> >>>> >>>> >>>> ************************************** >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > -- > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 > Registered In England http://www.jennic.com > __________________________________________________ > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From paul.chilton@jennic.com Fri Feb 26 01:49:21 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4E728C139 for <6lowpan@core3.amsl.com>; Fri, 26 Feb 2010 01:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSjfD7hzFjvN for <6lowpan@core3.amsl.com>; Fri, 26 Feb 2010 01:49:20 -0800 (PST) Received: from mail.jennic.com (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id F423928C13C for <6lowpan@ietf.org>; Fri, 26 Feb 2010 01:49:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 15437D6BB3; Fri, 26 Feb 2010 09:51:31 +0000 (GMT) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybPAndGKfD2w; Fri, 26 Feb 2010 09:51:30 +0000 (GMT) Received: from [192.168.0.3] (camwell.force9.co.uk [80.229.251.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id B9FBCD6BB1; Fri, 26 Feb 2010 09:51:30 +0000 (GMT) Message-ID: <4B8799A2.1080408@jennic.com> Date: Fri, 26 Feb 2010 09:51:30 +0000 From: Paul Chilton User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Geoff Mulligan Content-Type: multipart/alternative; boundary="------------050401000308050801030300" Cc: IETF 6LoWPAN <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paul.chilton@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 09:49:21 -0000 This is a multi-part message in MIME format. --------------050401000308050801030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Geoff I support the draft moving forward to the IESG The issues that have been brought up to do with further compression modes for TCP and RPL should be dealt with as separate internet drafts which can be used as additions to this one. Similarly the issues do with forward compatibility and fragmentation should be dealt with in a draft to update fragmentation in 4944. This will allow us to at least get this part of the stack functionality nailed down Paul --------------050401000308050801030300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Geoff
I support the draft moving forward to the IESG
The issues that have been brought up to do with further compression modes for TCP and RPL should be dealt with as separate internet drafts which can be used as additions to this one.  Similarly the issues do with forward compatibility and fragmentation should be dealt with in a draft to update fragmentation in 4944. 
This will allow us to at least get this part of the stack functionality nailed down
Paul
--------------050401000308050801030300-- From abr@sdesigns.dk Fri Feb 26 02:30:02 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9C528C0E1 for <6lowpan@core3.amsl.com>; Fri, 26 Feb 2010 02:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi92RTX1SPZz for <6lowpan@core3.amsl.com>; Fri, 26 Feb 2010 02:30:01 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 0C9943A86D8 for <6lowpan@ietf.org>; Fri, 26 Feb 2010 02:29:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Feb 2010 11:32:14 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429F0E@zensys17.zensys.local> In-Reply-To: <4B86869F.9010103@jennic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WGLC for 6lowpan HC draft Thread-Index: Acq2JWQ/88Dvw6q2SvC7KBnZ7XQpKgAp8n7g References: <4B861ED4.3070200@gridmerge.com><260AAC3E-D813-4F0C-889D-1FA2AB2C11BA@archrock.com> <4B86869F.9010103@jennic.com> From: "Anders Brandt" To: , <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 26 Feb 2010 10:30:02 -0000 Hi I support the proposal of a simple correction to fragmentation: * new dispatch codes for generic datagrams - fragments may carry compressed or uncompressed; it does not matter. * reject fragments of old type in the transition period * strongly deprecate old dispatch code by 2011 Cheers, Anders > -----Original Message----- > From: 6lowpan-bounces@ietf.org=20 > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Daniel Gavelle > Sent: Thursday, February 25, 2010 15:18 > To: 6lowpan@ietf.org > Subject: Re: [6lowpan] WGLC for 6lowpan HC draft >=20 > On the subject of forward and backward compatibility, I think=20 > the dispatch codes for fragmentation (FRAG1, FRAGN) should be=20 > changed to values that are currently reserved if we move to=20 > sending the datagram_size and datagram_offset as compressed=20 > and uncompressed values.=20 > This will mean that during the transition period, it will=20 > be much easier to sort out interoperability problems where=20 > some nodes use compressed values and some nodes are running=20 > older code using uncompressed values. >=20 > I don't think the new nodes should support both compressed=20 > and uncompressed offsets / sizes but should simply reject=20 > fragments that don't have the dispatch codes they are expecting. >=20 > The existing dispatch codes would not be lost forever as they=20 > could be strongly deprecated and then recycled in a future RFC. >=20 > Daniel. >=20 >=20 >=20 > Jonathan Hui wrote: > >=20 > > It would be helpful to know what people's expectations are=20 > relative to=20 > > what this specific draft should include relative to an acceptable=20 > > timeline of getting a document out. Few comments: > >=20 > > - The WG currently does not have a proposal for TCP header=20 > > compression, let alone one that we have built some consensus around. > > - The RPL protocol mechanisms and headers are still in flux. It is=20 > > difficult to propose a concrete way of compressing them without=20 > > knowing what they will look like. For example, within=20 > ROLL, we will=20 > > be proposing ways to "pack" lists of addresses such that common=20 > > prefixes are only carried once within the datagram. > > - The general 6lowpan-hc format is generic enough to be=20 > used on top of=20 > > other fragmentation mechanisms and/or frame sizes. Do we=20 > really want=20 > > to limit its capabilities to a particular fragmentation and=20 > frame size? > >=20 > > There always seems to be a tension between splitting functionality=20 > > across different drafts vs. delaying the current draft to=20 > "sneak" in=20 > > new functionality. I'm all for sneaking in fixes to RFC=20 > 4944 (i.e.=20 > > simple changes to fragmentation) or additional functionality for=20 > > expediency if we can realize that expedience. But waiting until we=20 > > design a TCP header compression mechanism that we can build=20 > consensus=20 > > around probably isn't the best approach, in my opinion, and=20 > should be=20 > > left to a separate draft. > >=20 > > So what do others think? > >=20 > > (I will start a new thread specifically on fragmentation +=20 > > forward-compatibility so that we drive towards closure on that=20 > > specific issue). > >=20 > > -- > > Jonathan Hui > >=20 > > On Feb 24, 2010, at 10:55 PM, Robert Cragie wrote: > >=20 > >> Hi Geoff, > >> > >> I concur with Joseph's statements and thus do not support=20 > forwarding=20 > >> the draft to IESG yet. > >> > >> Robert > >> Robert Cragie (Pacific Gas & Electric) > >> > >> Gridmerge Ltd. > >> 89 Greenfield Crescent, > >> Wakefield, WF4 4WA, UK > >> +44 (0) 1924 910888 > >> http://www.gridmerge.com > >> > >> > >> > >> Reddy, Joseph wrote: > >>> > >>> > >>> Hi Geoff, > >>> > >>> I do not support forwarding this doc to IESG yet. I would=20 > like the=20 > >>> following issues addressed > >>> > >>> ** Investigate possible TCP header compression scheme > >>> > >>> ** Explain strategy for compressing RPL headers ( I=20 > understand this=20 > >>> could be done in the ROLL group, but I have not seen a definite=20 > >>> statement either way ) > >>> > >>> ** Resolve the "forward compatability" issue ( ideally, while=20 > >>> maintaining backwards-comptability ) > >>> > >>> > >>> -Regards, Joseph > >>> > >>> > >>> > >>>=20 > -------------------------------------------------------------------- > >>> -- > >>> > >>> Message: 1 > >>> Date: Sat, 13 Feb 2010 00:56:31 -0700 > >>> From: Geoff Mulligan > >>> Subject: [6lowpan] WGLC for 6lowpan HC draft > >>> To: 6lowpan <6lowpan@ietf.org> > >>> Message-ID: <1266047791.3643.48.camel@dellx1> > >>> Content-Type: text/plain > >>> > >>> Folks, > >>> I realized that I have made a huge slip-up. The HC draft has=20 > >>> languished for the past few months. > >>> At the meeting in Hiroshima we said that we would last call this=20 > >>> draft, but I failed to send out the actual last call. So... > >>> > >>> This note formally starts the WG Last Call for comments on=20 > >>> draft-ietf-6lowpan-hc-06, "Compression Format for IPv6=20 > Datagrams in=20 > >>> 6LoWPAN Networks". > >>> > >>> The document can be found at: > >>> http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt > >>> > >>> The document is intended to be submitted by this Working Group to=20 > >>> the IESG for publication as a Standards Track document. > >>> > >>> Please review the document carefully (one last time), and=20 > send your=20 > >>> comments to the 6lowpan list. Please also indicate in=20 > your response=20 > >>> whether or not you think this document is ready to go to the IESG. > >>> > >>> Because of my gaffe this Last Call will end Wednesday February 24=20 > >>> 2010 at 2359 UTC. > >>> > >>> Thanks, > >>> Geoff > >>> > >>> > >>> > >>> > >>> > >>> ************************************** > >>> _______________________________________________ > >>> 6lowpan mailing list > >>> 6lowpan@ietf.org > >>> https://www.ietf.org/mailman/listinfo/6lowpan > >>> > >>> > >> _______________________________________________ > >> 6lowpan mailing list > >> 6lowpan@ietf.org > >> https://www.ietf.org/mailman/listinfo/6lowpan > >=20 > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > >=20 >=20 > -- > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg=20 > No: 3191371 Registered In England http://www.jennic.com=20 > __________________________________________________ > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 From pthubert@cisco.com Fri Feb 26 03:43:07 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A399428C0F6 for <6lowpan@core3.amsl.com>; Fri, 26 Feb 2010 03:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.611 X-Spam-Level: X-Spam-Status: No, score=-9.611 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-++SAqfqN0E for <6lowpan@core3.amsl.com>; Fri, 26 Feb 2010 03:43:06 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A51753A82A8 for <6lowpan@ietf.org>; Fri, 26 Feb 2010 03:43:06 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB9Dh0utJV2c/2dsb2JhbACbEHOjG5g4hHkE X-IronPort-AV: E=Sophos;i="4.49,546,1262563200"; d="scan'208";a="488817264" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2010 11:45:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o1QBjFCo015869; Fri, 26 Feb 2010 11:45:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Feb 2010 12:44:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Feb 2010 12:44:33 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0151C39D@XMB-AMS-107.cisco.com> In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC404272347@XCH57YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WGLC for 6lowpan HC draft Thread-Index: Acqs517HelMLDaJOTcujpgTSdbU2oQIm6HuwAAQp9eAAUMdNEA== References: <7E1DF37F1F42AB4E877E492C308E6AC404272347@XCH57YKF.rim.net> From: "Pascal Thubert (pthubert)" To: "Rene Struik" , <6lowpan@ietf.org> X-OriginalArrivalTime: 26 Feb 2010 11:44:38.0709 (UTC) FILETIME=[13A30650:01CAB6D9] Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 26 Feb 2010 11:43:07 -0000 Hello Ren=E9: As a RPL editor I'd point out that RPL operates on any LLN, not only = links running 6LoWPAN. So RPL cannot waste humongous space in the = packets and then rely of 6LoWPAN to fix it. RPL will have to do its own exercise and get as lean as possible; I = admit there's a lot left to be done, in particular in source route and = DAO, and that WILL be done. Whether 6LoWPAN can do more for its own = context is left to be seen, and we can start a new draft for that = purpose if such need is determined. The real question is for me whether the HC draft as it stands enables = future additions such as may be needed for RPL, or if it would stand on = the way. For all I see, HC leaves the door open for additions in = particular new headers such as the one RPL is considering for loop = detection, so I do not see this draft as compromising RPL. As you figure, there will always be additions that can be made, new = types and header coming up, new transports to integrate. This draft is = not intended to cover everything that will ever be compressed in 6LoWPAN = and I hope/trust that additions will follow. Till then, there are = implementations and deployments waiting for this draft to become RFC, = and we need to move forward. I do support moving this work forward to = IESG, see what they think. Cheers, Pascal -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Rene Struik Sent: Wednesday, February 24, 2010 10:01 PM To: 6lowpan@ietf.org Subject: Re: [6lowpan] WGLC for 6lowpan HC draft Hi Geoff: When studying details of the RoLL protocol, a similar question as the = one raised by Joseph Reddy came to mind: how are we going to ensure that = all packets are not going to be as bulky as they seem right now (from = rpl-6, it seems one may use tens of bytes in various packets, seemingly = without any technical need). As I understood from the RPL Security conf = call as of Tue Feb 23, 2010, 12-1pm EST, compression of IPv6 packets is = not in RoLL's charter and would be 6lowpan's responsibility. So, at this = time, I would like this issue to be adequately addressed (if not = 6lowpan, who is going to do this), prior to moving this forward to IESG. Best regards, Rene -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Reddy, Joseph Sent: Wednesday, February 24, 2010 2:02 PM To: 6lowpan@ietf.org Subject: Re: [6lowpan] WGLC for 6lowpan HC draft =20 Hi Geoff, I do not support forwarding this doc to IESG yet. I would like the = following issues addressed=20 ** Investigate possible TCP header compression scheme ** Explain strategy for compressing RPL headers ( I understand this = could be done in the ROLL group, but I have not seen a definite = statement either way ) ** Resolve the "forward compatability" issue ( ideally, while = maintaining backwards-comptability ) -Regards, Joseph ---------------------------------------------------------------------- Message: 1 Date: Sat, 13 Feb 2010 00:56:31 -0700 From: Geoff Mulligan Subject: [6lowpan] WGLC for 6lowpan HC draft To: 6lowpan <6lowpan@ietf.org> Message-ID: <1266047791.3643.48.camel@dellx1> Content-Type: text/plain Folks, I realized that I have made a huge slip-up. The HC draft has = languished for the past few months. At the meeting in Hiroshima we said that we would last call this draft, = but I failed to send out the actual last call. So... This note formally starts the WG Last Call for comments on = draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in = 6LoWPAN Networks". The document can be found at: http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt The document is intended to be submitted by this Working Group to the = IESG for publication as a Standards Track document. Please review the document carefully (one last time), and send your = comments to the 6lowpan list. Please also indicate in your response = whether or not you think this document is ready to go to the IESG. Because of my gaffe this Last Call will end Wednesday February 24 2010 = at 2359 UTC. Thanks, Geoff ************************************** _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From adam@sics.se Fri Feb 26 07:48:03 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1983C3A8695; Fri, 26 Feb 2010 07:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNYdt1K0zhOv; Fri, 26 Feb 2010 07:48:02 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 621283A840C; Fri, 26 Feb 2010 07:48:01 -0800 (PST) Received: from [10.1.1.153] (unknown [10.1.1.153]) by letter.sics.se (Postfix) with ESMTPS id 27F8740356; Fri, 26 Feb 2010 16:50:15 +0100 (CET) Message-ID: <4B87EDB5.6070906@sics.se> Date: Fri, 26 Feb 2010 16:50:13 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ROLL WG , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] ACM HotEmNets 2010 - only a few days left! X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 26 Feb 2010 15:48:03 -0000 There are only a few days left to submit papers to ACM HotEmNets! Paper deadline is Monday, March 1 2010. Papers are 5 pages, double-column format. All submissions will be peer reviewed by the program committee. Accepted papers will be published in the ACM digital library. Paper submission is now open: https://www.easychair.org/login.cgi?conf=hotemnets2010 HotEMNETS 2010 - 6th Workshop on Hot Topics in Embedded Networked Sensors http://www.hotemnets2010.org/ The Sixth Workshop on Hot Topics in Embedded Networked Sensors (HotEmNets 2010) brings together wireless sensor network researchers from academic and industrial backgrounds to present groundbreaking results that will shed light on present and future research challenges. The workshop emphasizes results from experiments or deployments that quantify the challenges in the wireless sensor systems of today as well as early results from new ideas that introduce promising approaches that will define the challenges in the wireless sensor systems of tomorrow. We especially welcome papers reporting on results that refute common assumptions, deployment experiences, novel and original approaches, and, more generally, papers that will help inform and guide research. Topics of interest include, but are not limited to: * Validation/refutation of prior results * Applications beyond data collection * Application experiences: measurements, lessons learned * Future applications: requirements and challenges * Integration of sensor networks and IP networks * Hardware platforms, tradeoffs, and trends * Data and network storage * Delay-tolerant networking * Management, debugging, and troubleshooting * Network and software reliability * Network and system architectures * Software bug detection and tools * Energy sources, scavenging, and low-power operation * Human-Computer interfaces for sensor nets Important Dates DEADLINE EXTENDED: March 1, 2010 Notification: April 15, 2010 Camera Ready: May 10, 2010 Conference: June 28-29, 2010 Workshop Venue Killarney, Ireland General Chair: Dirk Pesch, Cork Institute of Technology Program Co-Chairs: Adam Dunkels, SICS Akos Ledeczi, Vanderbilt University Publications Chair: Antonio Ruzzelli, University College Dublin TPC: Philippe Bonnet, IT University of Copenhagen, Denmark Niru Bulusu, Portland State University, USA Prabal Dutta, University of Michigan, USA Mary Ann Ingram, Georgia Tech, USA Utz Rödig, Lancaster University, UK Kay Römer, University of Lübeck, Germany Janos Sallai, Vanderbilt University, USA Andreas Terzis, Johns Hopkins University, USA Roberto Verdone, University of Bologna, Italy Kamin Whitehouse, University of Virginia, USA Feng Zhao, Microsoft Research, China Steering Committee: Sanjay Jha (chair), UNSW Cormac Sreenan, Uni. College Cork John Heidemann, USC/ISI Andrew Campbell, Dartmouth College Nirupama Bulusu, PSU -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org