From stbryant@cisco.com Fri Mar 4 11:18:07 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C783A69EC for ; Fri, 4 Mar 2011 11:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.484 X-Spam-Level: X-Spam-Status: No, score=-110.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 nXmtjK5osiax for ; Fri, 4 Mar 2011 11:18:06 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E3DB83A6818 for ; Fri, 4 Mar 2011 11:18:06 -0800 (PST) Received: from ams-iport-2.cisco.com ([144.254.224.141]) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1PvaWv-0006ZS-C6 for draft-ietf-manet-smf@tools.ietf.org; Fri, 04 Mar 2011 11:19:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=82; q=dns/txt; s=iport; t=1299266353; x=1300475953; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=2avMwkGKfFqo9aupbMGhJVokTiTIEktQPlxdJxC9OOI=; b=DhXnRyMEG72ZtpkkyRzKqiyHQGC5CGrEbgOMi15LHdwdRjQuSNg0r3GV XTqRc7b4kLDJmHVjjM2X05JKvM05OeZA+Txxsxe6VRHj87+USAH7Wv/v9 eAGf4Uh760yHOjZeoudI7u5CWPy2aiZ3anFAPS6OrYgO0YryPbxT8GSU2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMHADrKcE2Q/khMgWdsb2JhbACYZo19FQEBFiIlo3+CaQ4BmGeFYQSMLw X-IronPort-AV: E=Sophos;i="4.62,265,1297036800"; d="scan'208";a="20723857" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 04 Mar 2011 19:19:05 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p24JJ58f028968 for ; Fri, 4 Mar 2011 19:19:05 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p24JJ5Ud005481; Fri, 4 Mar 2011 19:19:05 GMT Message-ID: <4D713B29.20706@cisco.com> Date: Fri, 04 Mar 2011 19:19:05 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: draft-ietf-manet-smf@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 144.254.224.141 X-SA-Exim-Rcpt-To: draft-ietf-manet-smf@tools.ietf.org X-SA-Exim-Mail-From: stbryant@cisco.com X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: macker@itd.nrl.navy.mil, manet@ietf.org Resent-Message-Id: <20110304191806.E3DB83A6818@core3.amsl.com> Resent-Date: Fri, 4 Mar 2011 11:18:06 -0800 (PST) Resent-From: stbryant@cisco.com Subject: [manet] Mail regarding draft-ietf-manet-smf X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 19:18:07 -0000 This is a regular ping to see how you are getting on with this draft? Stewart From tthhac@gmail.com Sun Mar 6 16:00:45 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E6E28C0DD for ; Sun, 6 Mar 2011 16:00:45 -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 IyWSApxw-KrF for ; Sun, 6 Mar 2011 16:00:42 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 35EB728C0CF for ; Sun, 6 Mar 2011 16:00:41 -0800 (PST) Received: by yic13 with SMTP id 13so1800481yic.31 for ; Sun, 06 Mar 2011 16:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=4zMG028sdTjtQKKKa8lPJZXs7ntX7wOyWjNRHc7AIqk=; b=g44NetbfkpfQA07N98Gu8kzMh3/3m5b/f+pO0ky/2CdOLuWFz/KhSaErNpi4NddQDD cvy9VRgaXAa4txFPYSsjaPqUqV8bCaqh4UNpMiFnkQz66rXo4uEfW0VfBKNMUP4w7b+s HlWEko5C42iO4by/IcSaUGIsIDnGPNMlKRfiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LQLqb2mvyP4JAqn3UMbeupxK8JaQp0Rduqw02tjcS1fX8wPuL4jjf/O3OOXJhwcbNU xqwVYpkqUtbRAZ3Mld4ilsDdwA9k4swDvq5ZyV4sC2m55XuLr5wfOIWwriGLCVxfMAza g8HxtI4HtQtCUJYWk7BaoZ6ycRzWdGzlkQ60Y= MIME-Version: 1.0 Received: by 10.90.48.5 with SMTP id v5mr2396551agv.62.1299456111356; Sun, 06 Mar 2011 16:01:51 -0800 (PST) Received: by 10.90.216.14 with HTTP; Sun, 6 Mar 2011 16:01:51 -0800 (PST) Date: Mon, 7 Mar 2011 07:01:51 +0700 Message-ID: From: To Thanh Hai To: manet@ietf.org, ns-users@isi.edu Content-Type: multipart/alternative; boundary=0016e65bc34eeb2c4b049dd933ba Subject: [manet] Mobility scenario generator for RRGM model X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 00:02:33 -0000 --0016e65bc34eeb2c4b049dd933ba Content-Type: text/plain; charset=ISO-8859-1 Dear Mobile Ad Hoc Networkers, I am studying about Reference region group mobility model. I am looking for the "mobility scenario generator" that generate the mobility scenario for this model. But I cannot see yet. I would like to see this generator. Regards, Hai To ------------------------------------------------------------ Hue-Aptech - Computer Education Center www.huesoft.com.vn Email: tthhac@gmail.com --0016e65bc34eeb2c4b049dd933ba Content-Type: text/html; charset=ISO-8859-1 Dear Mobile Ad Hoc Networkers,

I am studying about Reference region group mobility model. I am looking for the "mobility scenario generator" that generate the mobility scenario for this model. But I cannot see yet.

I would like to see this generator.

Regards,
Hai To

------------------------------------------------------------
Hue-Aptech - Computer Education Center
www.huesoft.com.vn
Email: tthhac@gmail.com
--0016e65bc34eeb2c4b049dd933ba-- From joseph.macker@nrl.navy.mil Thu Mar 10 15:14:47 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194DD3A69F1 for ; Thu, 10 Mar 2011 15:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 c4rDXYToOI3c for ; Thu, 10 Mar 2011 15:14:46 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 59B803A69B6 for ; Thu, 10 Mar 2011 15:14:46 -0800 (PST) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.74) (envelope-from ) id 1Pxp5O-00068G-Mm for draft-ietf-manet-smf@tools.ietf.org; Thu, 10 Mar 2011 15:16:03 -0800 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p2ANFnON021334; Thu, 10 Mar 2011 18:15:49 -0500 Received: from vpn217206.nrl.navy.mil ([132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011031018154803640 ; Thu, 10 Mar 2011 18:15:48 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Macker In-Reply-To: <4D713B29.20706@cisco.com> Date: Thu, 10 Mar 2011 18:15:55 -0500 Content-Transfer-Encoding: 7bit Message-Id: <71B49ED0-AFC1-4B76-B2C3-E7A86A85EC1B@nrl.navy.mil> References: <4D713B29.20706@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 132.250.83.3 X-SA-Exim-Rcpt-To: draft-ietf-manet-smf@tools.ietf.org X-SA-Exim-Mail-From: joseph.macker@nrl.navy.mil X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Mailman-Approved-At: Fri, 11 Mar 2011 15:04:24 -0800 Cc: draft-ietf-manet-smf@tools.ietf.org Subject: Re: [manet] Mail regarding draft-ietf-manet-smf X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 23:14:47 -0000 I have a plan to put out a new version by Monday's cutoff time. Its nice that I can update one of the normative references now with RFC 6130. -Joe On Mar 4, 2011, at 2:19 PM, Stewart Bryant wrote: > This is a regular ping to see how you are getting on with this draft? > > Stewart > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From jpmacker@gmail.com Sun Mar 13 23:42:03 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1AF3A6A60 for ; Sun, 13 Mar 2011 23:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 1YZscLenq3a8 for ; Sun, 13 Mar 2011 23:42:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 3DC413A67FF for ; Sun, 13 Mar 2011 23:42:02 -0700 (PDT) Received: by wwa36 with SMTP id 36so3665401wwa.13 for ; Sun, 13 Mar 2011 23:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=cPS+1qJbS6iCadO5lL5ttwYoRGuM9qoCNVBxwWv3Dxk=; b=vbIQ5nkIbKCOdnRntyohUA8BB4e4yQHlQ1AWtvj/2F4hwS3ohPh5XotkgLKLpxP3ax Ztv0UHqO37ORYkxz6XeHUS6gDIGjLXHGx+qlwaemAinb7Bj9cxh8kPBFVHpF0CkAHC/7 nPVLTbuwpXec3vpOt7MnZ7sF2PJCKIACfrcL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UA0vCcGXJbuecnT6RWE0n3IrVChSBxFn5A+be7mHMbvIMoeUDGRmj5dDvSZGTVDiq4 sYF0QwUyNA2asL04rgEwQFcNKhF/sQdLEyIOPi7ePTK+64d0iBhE5BXgymjg1e0b/UW5 z889IsoJwvv8BWkKADPr7WRigwsrLKi4Gi/PM= MIME-Version: 1.0 Received: by 10.216.62.144 with SMTP id y16mr6197579wec.101.1300085004806; Sun, 13 Mar 2011 23:43:24 -0700 (PDT) Received: by 10.216.163.210 with HTTP; Sun, 13 Mar 2011 23:43:24 -0700 (PDT) Date: Mon, 14 Mar 2011 02:43:24 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Updated Draft Prague Agenda X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 06:42:03 -0000 I just updated the draft agenda for Prague. Also I plan to upload the revised SMF ID tomorrow afternoon. -Joe From Ronald.intVelt@tno.nl Mon Mar 14 11:11:52 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95E03A6DEA for ; Mon, 14 Mar 2011 11:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 emAsn2pBx-Re for ; Mon, 14 Mar 2011 11:11:51 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 5986A3A6A31 for ; Mon, 14 Mar 2011 11:11:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.62,317,1297033200"; d="scan'208";a="11706693" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 14 Mar 2011 19:13:13 +0100 Received: from EXC-MBX01.tsn.tno.nl ([169.254.1.37]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0270.001; Mon, 14 Mar 2011 19:13:13 +0100 From: "Velt, R. (Ronald) in 't" To: Joseph Macker , "manet@ietf.org" Thread-Topic: [manet] Updated Draft Prague Agenda Thread-Index: AQHL4hMzpxyy1LFBQU2QeZ2Zos9ob5QtIbGw Date: Mon, 14 Mar 2011 18:13:12 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F300ADDDC23@EXC-MBX01.tsn.tno.nl> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Updated Draft Prague Agenda X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:11:53 -0000 Hi Joe,=20 >-----Original Message----- >From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=20 >On Behalf Of Joseph Macker >Sent: maandag 14 maart 2011 7:43 >To: manet@ietf.org >Subject: [manet] Updated Draft Prague Agenda > >I just updated the draft agenda for Prague. >Also I plan to upload the revised SMF ID tomorrow afternoon. While you're at it, you may want to fix the reference to "Mobile Ad hoc Net= working (MANET): Routing Protocol Performance Issues and Evaluation Conside= rations": that's RFC 2501, not RFC 2901 :-) Cheers, Ronald > >-Joe >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet > This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From jpmacker@gmail.com Mon Mar 14 11:28:57 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07083A6AAA for ; Mon, 14 Mar 2011 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 fC2Uboa5wOuk for ; Mon, 14 Mar 2011 11:28:54 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 97E443A6A4A for ; Mon, 14 Mar 2011 11:28:53 -0700 (PDT) Received: by wwa36 with SMTP id 36so4153130wwa.13 for ; Mon, 14 Mar 2011 11:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VSFfI8O5/Gil1D8+T0W4dCy1XAR217lyddlZzMr3pb0=; b=Z1CYFPU+8ez+vpcscpvTURRT8FvbRakME/9q8w1AhQ5eoWtBOldcwyutm4iB26gE30 I0ofbPXauFPTbULc3vqKbnPhsUMqFiCbjteMdXXwUvCl9wKOnpbDHf2qnLeGd0e7/s5a 67qmjKup0k3/B3DP6LU7mCaS9krv6P5KzSCUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q+NdewSzVH2e9+NeQ2cPiSwcUv31gVM4VM9/+Z1Eb9T51TH0L67llJ2a1FXg5LMdXd K4ETO5mZLc4Iy7W7HbRTTGls/wTCcl3JTzivK+73Ienzizl2hWx7G6IJUu1J4qo9LFKI o8/V/UB2kk1dwAwSA51WXcXckOZH1wZp0Ko6A= MIME-Version: 1.0 Received: by 10.216.62.144 with SMTP id y16mr6840050wec.101.1300127415988; Mon, 14 Mar 2011 11:30:15 -0700 (PDT) Received: by 10.216.163.210 with HTTP; Mon, 14 Mar 2011 11:30:15 -0700 (PDT) In-Reply-To: <72FB622921C13746AD6349E70A8D9F300ADDDC23@EXC-MBX01.tsn.tno.nl> References: <72FB622921C13746AD6349E70A8D9F300ADDDC23@EXC-MBX01.tsn.tno.nl> Date: Mon, 14 Mar 2011 14:30:15 -0400 Message-ID: From: Joseph Macker To: "Velt, R. (Ronald) in 't" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Updated Draft Prague Agenda X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:28:57 -0000 As a coauthor of that I should know better. How was your birthday. On Mon, Mar 14, 2011 at 2:13 PM, Velt, R. (Ronald) in 't wrote: > Hi Joe, > >>-----Original Message----- >>From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] >>On Behalf Of Joseph Macker >>Sent: maandag 14 maart 2011 7:43 >>To: manet@ietf.org >>Subject: [manet] Updated Draft Prague Agenda >> >>I just updated the draft agenda for Prague. >>Also I plan to upload the revised SMF ID tomorrow afternoon. > > While you're at it, you may want to fix the reference to "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations": that's RFC 2501, not RFC 2901 :-) > > Cheers, > Ronald > >> >>-Joe >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www.ietf.org/mailman/listinfo/manet >> > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer > > From joseph.macker@nrl.navy.mil Mon Mar 14 12:31:25 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668293A6B4C for ; Mon, 14 Mar 2011 12:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 VHzxkHt6nLRH for ; Mon, 14 Mar 2011 12:31:19 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 253123A6A3B for ; Mon, 14 Mar 2011 12:31:18 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p2EJWerV021008; Mon, 14 Mar 2011 15:32:41 -0400 Received: from vpn217206.nrl.navy.mil ([132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011031415323915937 ; Mon, 14 Mar 2011 15:32:39 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Macker In-Reply-To: <72FB622921C13746AD6349E70A8D9F300ADDDC23@EXC-MBX01.tsn.tno.nl> Date: Mon, 14 Mar 2011 15:32:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72FB622921C13746AD6349E70A8D9F300ADDDC23@EXC-MBX01.tsn.tno.nl> To: "Velt, R. (Ronald) in 't" X-Mailer: Apple Mail (2.1082) Cc: Joseph Macker , "manet@ietf.org" Subject: Re: [manet] Updated Draft Prague Agenda X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:31:25 -0000 Dup... yeah nice catch since I co-authored that I should know better. Its all done and coming soon. Just doing final nit check. -Joe On Mar 14, 2011, at 2:13 PM, Velt, R. (Ronald) in 't wrote: > Hi Joe,=20 >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=20 >> On Behalf Of Joseph Macker >> Sent: maandag 14 maart 2011 7:43 >> To: manet@ietf.org >> Subject: [manet] Updated Draft Prague Agenda >>=20 >> I just updated the draft agenda for Prague. >> Also I plan to upload the revised SMF ID tomorrow afternoon. >=20 > While you're at it, you may want to fix the reference to "Mobile Ad = hoc Networking (MANET): Routing Protocol Performance Issues and = Evaluation Considerations": that's RFC 2501, not RFC 2901 :-) >=20 > Cheers, > Ronald >=20 >>=20 >> -Joe >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From wwwrun@core3.amsl.com Mon Mar 14 13:50:34 2011 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8B09B3A6EBD; Mon, 14 Mar 2011 13:50:33 -0700 (PDT) From: IETF I-D Submission Tool To: macker@itd.nrl.navy.mil Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110314205034.8B09B3A6EBD@core3.amsl.com> Date: Mon, 14 Mar 2011 13:50:33 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] New Version Notification for draft-ietf-manet-smf-11 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:50:34 -0000 A new version of I-D, draft-ietf-manet-smf-11.txt has been successfully submitted by Joseph Macker and posted to the IETF repository. Filename: draft-ietf-manet-smf Revision: 11 Title: Simplified Multicast Forwarding Creation_date: 2011-03-14 WG ID: manet Number_of_pages: 51 Abstract: This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF defines techniques for multicast duplicate packet detection (DPD) to be applied in the forwarding process and includes maintenance and checking operations for both IPv4 and IPv6 protocol use. SMF also specifies mechanisms for applying reduced relay sets to achieve more efficient multicast data distribution within a mesh topology versus simple flooding. The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. The IETF Secretariat. From Internet-Drafts@ietf.org Mon Mar 14 14:00:05 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93D73A6EEE; Mon, 14 Mar 2011 14:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FJlPPjoFQXXj; Mon, 14 Mar 2011 14:00:04 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E9E3A6EF4; Mon, 14 Mar 2011 14:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314210002.8579.55519.idtracker@localhost> Date: Mon, 14 Mar 2011 14:00:02 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-smf-11.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:00:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Simplified Multicast Forwarding Author(s) : J. Macker, S. Team Filename : draft-ietf-manet-smf-11.txt Pages : 51 Date : 2011-03-14 This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF defines techniques for multicast duplicate packet detection (DPD) to be applied in the forwarding process and includes maintenance and checking operations for both IPv4 and IPv6 protocol use. SMF also specifies mechanisms for applying reduced relay sets to achieve more efficient multicast data distribution within a mesh topology versus simple flooding. The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-11.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 Content-Type: Message/External-body; name="draft-ietf-manet-smf-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14135033.I-D@ietf.org> --NextPart-- From jpmacker@gmail.com Mon Mar 14 12:42:24 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4A43A6AAA for ; Mon, 14 Mar 2011 12:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-2.200, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_93=0.6, MANGLED_SHOP=2.3, 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 rA6RHzzyu9gS for ; Mon, 14 Mar 2011 12:42:18 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4D64B3A6B50 for ; Mon, 14 Mar 2011 12:42:16 -0700 (PDT) Received: by wwa36 with SMTP id 36so4215108wwa.13 for ; Mon, 14 Mar 2011 12:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=OWDJWxdvIwo6PxFQqsqAlHyR9X+uth+ZYznTC5llrGw=; b=ohsSvshoFs9fad7hdogdLq9mPi+Dy3Yv+oxQwfiJgTbCZkz+KMhKsNgSMf0cNKXZv3 2K8pwU9Dl+1pzipApCU2ilGbMcpcy8/oFQbpgofW8Itj0YPznFNcN3eDQEYTIsD3Knch 3qxdsL1t1fzwCbAN1jld3D9ZNobzQD+eRN1QA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wm3g1bkxhPdZBTxHeAkMYuuPsy4pbGTOyakxGDVZzdtm/E7nBHX0hW7ljt5wmNRiNh kWJLdRe4M7gcbF7TrQirQv5nzQaKb3trv2NIyx71nG5fe6kHMrMbBf7U/omCrh/mUMf3 cYwLh3cb9ugTwiT+IKArAbyEfICyvp6G647Ok= MIME-Version: 1.0 Received: by 10.216.191.232 with SMTP id g82mr10931177wen.24.1300131820183; Mon, 14 Mar 2011 12:43:40 -0700 (PDT) Received: by 10.216.163.210 with HTTP; Mon, 14 Mar 2011 12:43:40 -0700 (PDT) Date: Mon, 14 Mar 2011 15:43:40 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org, Ulrich Herberg Content-Type: multipart/mixed; boundary=0016e6567fb64da0a8049e7687c0 X-Mailman-Approved-At: Tue, 15 Mar 2011 08:16:59 -0700 Subject: [manet] SMF update and comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:42:24 -0000 --0016e6567fb64da0a8049e7687c0 Content-Type: text/plain; charset=ISO-8859-1 SMF version 11 has been uploaded. Here is a thread related to Ulrich's older comments that have been addressed. UH> is comment and JM> is my response. Most of the comments were incorporated fixed. Technical content has not really changed but some vague content has been removed or clarified. Thanks Ulrich. -Joe --0016e6567fb64da0a8049e7687c0 Content-Type: text/plain; name="SMF_review-herberg_response_4.txt" Content-Disposition: attachment; filename="SMF_review-herberg_response_4.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gl9sutrs0 ICAKRGV0YWlsZWQgY29tbWVudHM6IChzdGFydGluZyB3aXRoICJVSD4gIiwgYWx3YXlzIGltbWVk aWF0ZWx5IGZvbGxvd2luZwp0aGUgY29uY2VybmVkIHNlbnRlbmNlIG9yIHBhcmFncmFwaCkKPT09 PT09PT09PT09CgoxLiAgUmVxdWlyZW1lbnRzIE5vdGF0aW9uCgogICBUaGUga2V5IHdvcmRzICJN VVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJT SE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFM IiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4gW1JGQzIxMTldLgpVSD4gPT09PT09PT09PT09PT09PQpVSD4gVGhlcmUgaXMgYW4gZXJyYXRh IHRvIFJGQzIxMTk6ICJOT1QgUkVDT01NRU5ERUQiIGhhcyBiZWVuIGFkZGVkLgpVSD4gPT09PT09 PT09PT09PT09PQoKSk0+IEZJWEVEIGluIDExCgoKMi4gIEludHJvZHVjdGlvbiBhbmQgU2NvcGUK CiAgIFVuaWNhc3Qgcm91dGluZyBwcm90b2NvbCBkZXNpZ25zIGZvciBNQU5FVCBhbmQgd2lyZWxl c3MgbWVzaCB1c2UgaGF2ZQogICBkZW1vbnN0cmF0ZWQgZWZmaWNpZW50IG1lY2hhbmlzbXMgdG8g Zmxvb2Qgcm91dGluZyBjb250cm9sIHBsYW5lCiAgIG1lc3NhZ2VzIHdpdGhpbiBhIHdpcmVsZXNz IHJvdXRpbmcgYXJlYS4gIApVSD4gPT09PT09PT09PT09PT09PQpVSD4gImhhdmUgZGVtb25zdHJh dGVkIiBtYXkgcmVxdWlyZSBhIGNpdGF0aW9uClVIPiA9PT09PT09PT09PT09PT09CgpKTT4gQWdy ZWVkLiBDaGFuZ2VkIGludHJvIHdyaXRldXAgdG8gZGlzY3VzcyBvbmx5IHRoYXQgcHJlc2VudCBh cHByb2FjaGVzIGltcGxlbWVudCBvcHRpbWl6ZWQgcmVsYXkgc2V0cyBmb3IgdGhlIGNvbnRyb2wg cGxhbmUuIEkgdGhpbmsgbm93IHRoZSBwcmVzZW50IGNpdGF0aW9ucyBhcmUgc3VmZmljaWVudC4K ICAgCiAgIEZvciBleGFtcGxlLCBhbGdvcml0aG1zCiAgIHNwZWNpZmllZCB3aXRoaW4gW1JGQzM2 MjZdIGFuZCBbUkZDMzY4NF0gcHJvdmlkZSBkaXN0cmlidXRlZCBtZXRob2RzCiAgIG9mIGR5bmFt aWNhbGx5IGVsZWN0aW5nIHJlZHVjZWQgcmVsYXkgc2V0cyB0aGF0IGF0dGVtcHQgdG8gb3B0aW1p emUKICAgZmxvb2Rpbmcgb2Ygcm91dGluZyBjb250cm9sIG1lc3NhZ2VzIHdoaWxlIG1haW50YWlu aW5nIGEgY29ubmVjdGVkCiAgIHNldC4gIEluIG9uZSBzZW5zZSwgU2ltcGxpZmllZCBNdWx0aWNh c3QgRm9yd2FyZGluZyAoU01GKSBleHRlbmRzIHRoZQogICBlZmZpY2llbnQgZmxvb2RpbmcgY29u Y2VwdCB0byB0aGUgZGF0YSBmb3J3YXJkaW5nIHBsYW5lLiAgVGhlcmVmb3JlLAogICBTTUYgcHJv dmlkZXMgYW4gYXBwcm9wcmlhdGUgbXVsdGljYXN0IGZvcndhcmRpbmcgY2FwYWJpbGl0eSBmb3Ig dXNlCiAgIGNhc2VzIHdoZXJlIGxvY2FsaXplZCwgZWZmaWNpZW50IGZsb29kaW5nIGlzIGRlZW1l ZCBlZmZlY3RpdmUuICBUaGUKICAgYmFzZWxpbmUgZGVzaWduIGlzIGludGVuZGVkIHRvIHByb3Zp ZGUgYSBiYXNpYywgYmVzdCBlZmZvcnQgbXVsdGljYXN0CiAgIGZvcndhcmRpbmcgY2FwYWJpbGl0 eSB0aGF0IGlzIGNvbnN0cmFpbmVkIHRvIG9wZXJhdGUgd2l0aGluIGEgTUFORVQKICAgb3Igd2ly ZWxlc3MgbWVzaCByb3V0aW5nIHJlZ2lvbi4gIFRoZSBtYWluIGRlc2lnbiBnb2FscyBvZiB0aGlz IFNNRgogICBzcGVjaWZpY2F0aW9uIGFyZSB0byBhZGFwdCBlZmZpY2llbnQgcmVsYXkgc2V0cyBp biBNQU5FVCB0eXBlCiAgIGVudmlyb25tZW50cyBbUkZDMjkwMV0gYW5kIHRvIGRlZmluZSB0aGUg bmVlZGVkIElQdjQgYW5kIElQdjYKICAgbXVsdGljYXN0IGR1cGxpY2F0ZSBwYWNrZXQgZGV0ZWN0 aW9uIChEUEQpIG1lY2hhbmlzbXMgdG8gc3VwcG9ydAogICBtdWx0aS1ob3AsIHBhY2tldCBmb3J3 YXJkaW5nLiAgRmlndXJlIDEgcHJvdmlkZXMgYW4gb3ZlcnZpZXcgb2YgdGhlCiAgIGxvZ2ljYWwg U01GIG5vZGUgYXJjaGl0ZWN0dXJlLCBjb25zaXN0aW5nIG9mICJOZWlnaGJvcmhvb2QKICAgRGlz Y292ZXJ5IiwgIlJlbGF5IFNldCBTZWxlY3Rpb24iIGFuZCAiRm9yd2FyZGluZyBQcm9jZXNzIgog ICBjb21wb25lbnRzLiAgVHlwaWNhbGx5LCByZWxheSBzZXQgc2VsZWN0aW9uIChvciBzZWxmLWVs ZWN0aW9uKSB3aWxsCiAgIG9jY3VyIGJhc2VkIG9uIGlucHV0IGZyb20gYSBuZWlnaGJvcmhvb2Qg ZGlzY292ZXJ5IHByb2Nlc3MsIGFuZCB0aGUKICAgZm9yd2FyZGluZyBwcm9jZXNzIHdpbGwgb2Z0 ZW4gYmUgZGV0ZXJtaW5lZCBieSBkeW5hbWljIHJlbGF5IHNldAogICBzZWxlY3Rpb24uICBOb3Rl IHRoZSBuZWlnaGJvcmhvb2QgZGlzY292ZXJ5IGFuZC9vciByZWxheSBzZXQKICAgc2VsZWN0aW9u IGluZm9ybWF0aW9uIE1BWSAKClVIPiA9PT09PT09PT09PT09PT09ClVIPiBUaGlzIGlzIGFuIGlu dHJvZHVjdGlvbiBzZWN0aW9uLiBJIGFtIG5vdCBzdXJlIGl0IGlzIGEgZ29vZCBwbGFjZSB0byBz dGFydCB0aGUgc3BlY2lmaWNhdGlvbiBpdHNlbGYgYnkgdXNpbmcgUkZDMjExOSB0ZXJtaW5vbG9n eS4gVGhhdCBhcHBsaWVzIHNldmVyYWwgdGltZXMgdGhyb3VnaG91dCB0aGUgaW50cm9kdWN0aW9u LgpVSD4gPT09PT09PT09PT09PT09PQoKSk0+IFRoZSBkaXNjdXNzaW9uIG9mIHRoZSBEZXNpZ24g T3ZlcnZpZXcgSSB0aGluayByZXF1aXJlcyBzb21lIG9mIHRoaXMsIGJ1dCBpdCB3YXMgbW92ZWQg b3V0c2lkZSB0aGUgSW50cm8vU2NvcGUgc2VjdGlvbi4KIAogICBiZSBvYnRhaW5lZCBmcm9tIGEg Y29leGlzdGVudCBwcm9jZXNzCiAgIChlLmcuLCBhIGxvd2VyIGxheWVyIG1lY2hhbmlzbSBvciBh IHVuaWNhc3Qgcm91dGluZyBwcm90b2NvbCB1c2luZwogICByZWxheSBzZXRzKS4gIEluIHNvbWUg Y2FzZXMsIHRoZSBmb3J3YXJkaW5nIGRlY2lzaW9uIGZvciBhIHBhY2tldCBjYW4KICAgYWxzbyBk ZXBlbmQgb24gcHJldmlvdXMgaG9wIG9yIGluY29taW5nIGludGVyZmFjZSBpbmZvcm1hdGlvbi4g IFRoZQogICBhc3Rlcmlza3MgKCopIGluIEZpZ3VyZSAxIG1hcmsgdGhlIHByaW1pdGl2ZXMgYW5k IHJlbGF0aW9uc2hpcHMKICAgbmVlZGVkIGJ5IHJlbGF5IHNldCBhbGdvcml0aG1zIHJlcXVpcmlu ZyBwcmV2aW91cy1ob3AgcGFja2V0CiAgIGZvcndhcmRpbmcga25vd2xlZGdlLgoKCgoKCgoKCgoK CgpNYWNrZXIsIGVkaXRvciAmIFNNRiBEZXNpZ24gVGVhbSAgRXhwaXJlcyBTZXB0ZW1iZXIgNywg MjAxMCAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgIFNN RiAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTAKCgogICAgICAgICAgICAgICAgX19f X19fX19fX19fX18gICAgICAgICAgICAgICAgX19fX19fX19fX19fXwogICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgfCBOZWlnaGJvcmhvb2QgfCAgICAgICAgICAgICAgfCAgUmVsYXkgU2V0ICB8CiAgICAgICAg ICAgICAgIHwgIERpc2NvdmVyeSAgIHwtLS0tLS0tLS0tLS0tPnwgIFNlbGVjdGlvbiAgfAogICAg ICAgICAgICAgICB8ICAgUHJvdG9jb2wgICB8ICAgbmVpZ2hib3IgICB8ICBBbGdvcml0aG0gIHwK ICAgICAgICAgICAgICAgfF9fX19fX19fX19fX19ffCAgICAgaW5mbyAgICAgfF9fX19fX19fX19f X198CiAgICAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LwogICAgICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgLwog ICAgICAgICAgICAgICAgbmVpZ2hib3JcICAgICAgICAgICAgICAgICAgICAgICAgICAvZm9yd2Fy ZGluZwogICAgICAgICAgICAgICAgICBpbmZvKiAgXCAgICAgIF9fX19fX19fX19fXyAgICAgIC8g IHN0YXR1cwogICAgICAgICAgICAgICAgICAgICAgICAgIFwgICAgfCAgICAgICAgICAgIHwgICAg LwogICAgICAgICAgICAgICAgICAgICAgICAgICBgLS0+fCBGb3J3YXJkaW5nIHw8LS0nCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBQcm9jZXNzICAgfAogICAgICAgICAgICAgfn5+ fn5+fn5+fn5+fn5+fn4+fF9fX19fX19fX19fX3x+fn5+fn5+fn5+fn5+fn5+fj4KICAgICAgICAg ICAgIGluY29taW5nIHBhY2tldCwgICAgICAgICAgICAgICAgIGZvcndhcmRlZCBwYWNrZXRzCiAg ICAgICAgICAgICBpbnRlcmZhY2UgaWQqLCBhbmQKICAgICAgICAgICAgIHByZXZpb3VzIGhvcCoK CiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogU01GIE5vZGUgQXJjaGl0ZWN0dXJlCgog ICBJbnRlcm9wZXJhYmxlIFNNRiBpbXBsZW1lbnRhdGlvbnMgTVVTVCB1c2UgYSBjb21tb24gRFBE IGFwcHJvYWNoIGFuZAogICBiZSBhYmxlIHRvIHByb2Nlc3MgdGhlIGhlYWRlciBvcHRpb25zIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudCBmb3IKICAgSVB2NiBvcGVyYXRpb24uICBXZSBkZWZpbmUg Q2xhc3NpY2FsIEZsb29kaW5nIChDRiksIGFzIHRoZSBzaW1wbGVzdAogICBjYXNlIG9mIFNNRiBt dWx0aWNhc3QgZm9yd2FyZGluZy4gIFdpdGggQ0YsIGVhY2ggU01GIHJvdXRlciBmb3J3YXJkcwog ICBlYWNoIHJlY2VpdmVkIGZvcndhcmRhYmxlIG11bHRpY2FzdCBwYWNrZXQgZXhhY3RseSBvbmNl LiAgClVIPiA9PT09PT09PT09PT09PT09ClVIPiBXaGVyZSBpcyAiZm9yd2FyZGFibGUiIGRlZmlu ZWQ/IFRocm91Z2hvdXQgdGhlIGRvY3VtZW50LCB0aGUgd29yZCAicGFja2V0IiBpcyB1c2VkLiBN YXliZSByZXBsYWNlIGl0IHdpdGggIklQIGRhdGFncmFtIj8KVUg+ID09PT09PT09PT09PT09PT0K CkpNPiBCcmllZmx5IGludHJvZHVjZWQgdGhlIGNvbmNlcHQgb2YgZm9yd2FyZGFibGUgaGVyZSBh bmQgcG9pbnRlZCB0byB0aGUgZmFjdCB0aGF0IG1vcmUgZGV0YWlscyBhcmUgZ2l2ZW4gbGF0ZXIg aW4gdGhlIGRvY3VtZW50LgpKTT4gUmUuIHBhY2tldCBJIHRoaW5rIGJlY2F1c2Ugd2UgZGlzY3Vz cyBmb3J3YXJkaW5nIG9mIElQIGRhdGFncmFtIGZyYWdtZW50cyBhIG1vcmUgZ2VuZXJpYyB0ZXJt IHdhcyBkZXNpcmVkLiAgSSBndWVzcyB0aGlzIGlzIGRlYmF0YWJsZS4gIEkgYW0gaGFwcHkgdG8g dXNlIElQIGRhdGFncmFtLCBidXQgc2hvdWxkIGFsc28gc2F5IElQIGRhdGFncmFtIGZyYWdtZW50 cy4gQWN0dWFsbHkgSSBsaWtlIHBhY2tldCBiZXR0ZXIgYmVjYXVzZSBvZiB0aGUgZnJhZ21lbnQg aXNzdWUuCiAgIAogICBJbiB0aGlzCiAgIGNhc2UsIHRoZSBuZWVkIGZvciBhbnkgcmVsYXkgc2V0 IHNlbGVjdGlvbiBvciBuZWlnaGJvcmhvb2QgdG9wb2xvZ3kKICAgaW5mb3JtYXRpb24gaXMgZWxp bWluYXRlZCBidXQgRFBEIGZ1bmN0aW9uYWxpdHkgaXMgc3RpbGwgcmVxdWlyZWQuCiAgIFdoaWxl IFNNRiBzdXBwb3J0cyBhIENGIG1vZGUgb2Ygb3BlcmF0aW9uIHRoZSB1c2Ugb2YgbW9yZSBlZmZp Y2llbnQKICAgcmVsYXkgc2V0IG1vZGVzIGlzIFJFQ09NTUVOREVEIHRvIHJlZHVjZSBjb250ZW50 aW9uIGFuZCBjb25nZXN0aW9uCiAgIGNhdXNlZCBieSB1bm5lY2Vzc2FyeSBwYWNrZXQgcmV0cmFu c21pc3Npb25zIFtOVFNDOTldLiAgQW4gZWZmaWNpZW50LAogICByZWR1Y2VkIHJlbGF5IHNldCBp cyByZWFsaXplZCBieSBzZWxlY3RpbmcgYW5kIG1haW50YWluaW5nIGEgX3N1YnNldF8KVUg+ID09 PT09PT09PT09PT09PT0KVUg+IHVuZGVyc2NvcmVzIGFyb3VuZCBzdWJzZXQgc2VlbSB1bm5lY2Vz c2FyeQpVSD4gPT09PT09PT09PT09PT09PQoKSk0+IHJlbW92ZWQKCiAgIG9mIGFsbCBwb3NzaWJs ZSBTTUYgcm91dGVycyBpbiBhIE1BTkVUIHJvdXRpbmcgcmVnaW9uLiAKVUg+ID09PT09PT09PT09 PT09PT0KVUg+IFRocm91Z2hvdXQgdGhlIGRvY3VtZW50LCBkaWZmZXJlbnQgdGVybXMgYXJlIHVz ZWQgZm9yIHByZXN1bWFibHkgdGhlIHNhbWUgaW50ZW50aW9uOiBNQU5FVCByb3V0aW5nIGRvbWFp biwgU01GIHJvdXRpbmcgYXJlYSwgTUFORVQgU01GIHJvdXRpbmcgZG9tYWluLCBTTUYgcm91dGlu ZyBkb21haW4sLi4uIE5vbmUgb2YgdGhlc2UgaXMgZGVmaW5lZC4KVUg+IEFsc28sIEkgd291bGQg cmVwbGFjZSAiU01GIHJvdXRlcnMiIGJ5ICJyb3V0ZXJzIHJ1bm5pbmcgdGhlIFNNRiBwcm90b2Nv bCIKVUg+ID09PT09PT09PT09PT09PT0KCkpNPiB3ZWxsIHRoZXJlIHdhcyBzb21lIGRlZmluaXRp b24gaW4gOS4yIG9uIHNpdGUgc2NvcGVkIGFyZWFzIGJ1dCB0aGUgdGVybWlub2xvZ3kgd2FzIGlu Y29uc2lzdGVudC4gSSBhbSBnb2luZyB3aXRoIFNNRiByb3V0aW5nIGRvbWFpbiBhbmQgcm91dGVy cyBydW5uaW5nIHRoZSBTTUYgcHJvdG9jb2wgZm9yIG5vdy4KICAgCiAgIEtub3duIHJlbGF5CiAg IHNldCBzZWxlY3Rpb24gYWxnb3JpdGhtcyBoYXZlIGFscmVhZHkgZGVtb25zdHJhdGVkIHRoZSBh YmlsaXR5IHRvCiAgIHByb3ZpZGUgYW5kIG1haW50YWluIGEgZHluYW1pYyBjb25uZWN0ZWQgc2V0 IGZvciBmb3J3YXJkaW5nIHVzZXIKICAgbXVsdGljYXN0IGRhdGEgW01EQzA0XS4gIEEgZmV3IHN1 Y2ggcmVsYXkgc2V0IHNlbGVjdGlvbiBhbGdvcml0aG1zCiAgIGFyZSBkZXNjcmliZWQgaW4gdGhl IEFwcGVuZGljZXMgb2YgdGhpcyBkb2N1bWVudCBhbmQgdGhlIGJhc2ljCiAgIGRlc2lnbnMgYm9y cm93IGRpcmVjdGx5IGZyb20gcHJldmlvdXNseSBkb2N1bWVudGVkIElFVEYgd29yay4gIFNNRgog ICByZWxheSBzZXQgY29uZmlndXJhdGlvbiBpcyBleHRlbnNpYmxlIGFuZCBhZGRpdGlvbmFsIHJl bGF5IHNldAogICBhbGdvcml0aG1zIGJleW9uZCB0aG9zZSBzcGVjaWZpZWQgaGVyZSBjYW4gYmUg YWNjb21tb2RhdGVkIGluIGZ1dHVyZQogICB3b3JrLgoKICAgRGV0ZXJtaW5pbmcgYW5kIG1haW50 YWluaW5nIGFuIG9wdGltaXplZCBzZXQgb2YgZm9yd2FyZGluZyBub2RlcwpVSD4gPT09PT09PT09 PT09PT09PQpVSD4gVGhyb3VnaG91dCB0aGUgZG9jdW1lbnQsIG5vZGUvcm91dGVyIGlzIGluY29u c2lzdGVudC4gQW4gYXBwbGljYWJpbGl0eSBzZWN0aW9uIHdvdWxkIGJlIG5pY2UuIERvZXMgU01G IHJ1biBvbiBob3N0cywgcm91dGVycywgYm90aD8gVGhlcmUsIG9uZSBjb3VsZCBtZW50aW9uIHRo YXQgaXQgaXMgbGltaXRlZCB0byBJUCAoYnV0IHN1cHBvcnRzIGJvdGggSVB2NCBhbmQgSVB2Niku ClVIPiA9PT09PT09PT09PT09PT09CgpKTT4gU01GIGlzIGEgZm9yd2FyZGluZyBwcm90b2NvbCBz byB5ZXMgaWYgYSBub2RlIGhhcyBtdWx0aWNhc3QgZm9yd2FyZGluZyBlbmFibGVkIGl0IGNhbiBy dW4gU01GLgoKICAgZ2VuZXJhbGx5IHJlcXVpcmVzIGR5bmFtaWMgbmVpZ2hib3Job29kIHRvcG9s b2d5IGluZm9ybWF0aW9uLgogICBOZWlnaGJvcmhvb2QgdG9wb2xvZ3kgZGlzY292ZXJ5IGZ1bmN0 aW9ucyBNQVkgYmUgZXh0ZXJuYWxseSBwcm92aWRlZAogICBieSBhIE1BTkVUIHVuaWNhc3Qgcm91 dGluZyBwcm90b2NvbCBvciBieSB1c2luZyB0aGUgTUFORVQKICAgTmVpZ2hib3JIb29kIERpc2Nv dmVyeSBQcm90b2NvbCAoTkhEUCkgW05IRFBdIHJ1bm5pbmcgaW4gY29uY3VycmVuY2UKICAgd2l0 aCBTTUYuICBBZGRpdGlvbmFsbHksIHRoaXMgc3BlY2lmaWNhdGlvbiBhbGxvd3MgYWx0ZXJuYXRp dmUKICAgcHJvY2Vzc2VzIHRoYXQgbWF5IGJlIGRlZW1lZCBtb3JlIGVmZmVjdGl2ZSAoZS5nLiwg bG93ZXIgbGF5ZXIKCgoKTWFja2VyLCBlZGl0b3IgJiBTTUYgRGVzaWduIFRlYW0gIEV4cGlyZXMg U2VwdGVtYmVyIDcsIDIwMTAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICAgICBTTUYgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEwCgoKICAgd2ly ZWxlc3MgaW50ZXJmYWNlKQpVSD4gPT09PT09PT09PT09PT09PQpVSD4gVGhlIHNlbnRlbmNlIGlz IHVuY2xlYXIuLi4gaXMgcmVhZHMgYXMgaWYgYSB3aXJlbGVzcyBpbnRlcmZhY2Ugd2FzIGEgcHJv Y2Vzcy4KVUg+ID09PT09PT09PT09PT09PT0KCkpNPiBPayBpdHMgY2hhbmdlZC4gVGFsa2VkIG1v cmUgYWJvdXQgYSBsb3dlciBsYXllciBpbnRlcmZhY2UgKHN1Y2ggYXMgYSByYWRpbyByb3V0ZXIg aW50ZXJmYWNlKQogICAKICAgdG8gcHJvdmlkZSB0aGUgbmVjZXNzYXJ5IG5laWdoYm9yaG9vZCBp bmZvcm1hdGlvbgogICB0byBzdXBwb3J0IHJlbGF5IHNldCBlbGVjdGlvbi4gIEZ1bmRhbWVudGFs bHksIGFuIFNNRiBpbXBsZW1lbnRhdGlvbgogICBTSE9VTEQgcHJvdmlkZSB0aGUgYWJpbGl0eSBm b3IgbXVsdGljYXN0IGZvcndhcmRpbmcgc3RhdGUgdG8gYmUKICAgZHluYW1pY2FsbHkgbWFuYWdl ZCBwZXIgb3BlcmF0aW5nIG5ldHdvcmsgaW50ZXJmYWNlLiAgU29tZSBvZiB0aGUKICAgcmVsYXkg c3RhdGUgbWFpbnRlbmFuY2Ugb3B0aW9ucyBhbmQgaW50ZXJhY3Rpb25zIGFyZSBvdXRsaW5lZCBs YXRlcgogICBpbiBTZWN0aW9uIDYuICBUaGlzIGRvY3VtZW50IHN0YXRlcyBzcGVjaWZpYyByZXF1 aXJlbWVudHMgZm9yCiAgIG5laWdoYm9yaG9vZCBkaXNjb3Zlcnkgd2l0aCByZXNwZWN0IHRvIHRo ZSBmb3J3YXJkaW5nIHByb2Nlc3MgYW5kIHRoZQogICByZWxheSBzZXQgc2VsZWN0aW9uIGFsZ29y aXRobXMgZGVzY3JpYmVkIGhlcmVpbi4gIEZvciBkZXRlcm1pbmluZwogICBkeW5hbWljIHJlbGF5 IHNldHMgaW4gdGhlIGFic2VuY2Ugb2YgYW4gZXhpc3RpbmcgTUFORVQgdW5pY2FzdAogICBwcm90 b2NvbCBvciBsb3dlciBsYXllciBpbnRlcmZhY2UKVUg+ID09PT09PT09PT09PT09PT0KVUg+IElu IHRoZSBhYnNlbmNlIG9mIGEgIiI/IElzIHRoYXQgYSBuZXR3b3JrIGludGVyZmFjZT8KVUg+ID09 PT09PT09PT09PT09PT0KCkpNID5jaGFuZ2VkIGluIDExLgogICAKICAgLCBTTUYgcmVsaWVzIG9u IHRoZSBNQU5FVCBOSERQCiAgIHNwZWNpZmljYXRpb24gdG8gYXNzaXN0IGluIElQIGxheWVyIDIt aG9wIG5laWdoYm9yaG9vZCBzdGF0ZQogICBkaXNjb3ZlcnkgYW5kIG1haW50ZW5hbmNlIGZvciBy ZWxheSBzZXQgZWxlY3Rpb24uICBBICJTTUZfUkVMQVlfQUxHIgogICBNZXNzYWdlIFRMViB0eXBl IChwZXIgW1JGQzU0NDRdKQpVSD4gPT09PT09PT09PT09PT09PQpVSD4gSXQgY291bGQgYmUgdXNl ZnVsIHRvIGJyaWVmbHkgZ2l2ZSBhbiBvdmVydmlldyBvZiBSRkM1NDQ0IGJlZm9yZTsgb3IgZGVm aW5lIHdoaWNoIHRlcm1zIG9mIFJGQzU0NDQgYXJlIHVzZWQgd2l0aGluIHRoaXMgc3BlYy4KVUg+ ID09PT09PT09PT09PT09PT0KICAgCiAgIAozLiAgU01GIEFwcGxpY2FiaWxpdHkKCiAgIFdpdGhp biBkeW5hbWljIHdpcmVsZXNzIHJvdXRpbmcgdG9wb2xvZ2llcywgbWFpbnRhaW5pbmcgdHJhZGl0 aW9uYWwKICAgZm9yd2FyZGluZyB0cmVlcyB0byBzdXBwb3J0IGEgbXVsdGljYXN0IHJvdXRpbmcg cHJvdG9jb2wgaXMgb2Z0ZW4gbm90CiAgIGFzIGVmZmVjdGl2ZSBhcyBpbiB3aXJlZCBuZXR3b3Jr cyBkdWUgdG8gdGhlIHJlZHVjZWQgcmVsaWFiaWxpdHkgYW5kCiAgIGluY3JlYXNlZCBkeW5hbWlj cyBvZiBtZXNoIHRvcG9sb2dpZXMgW01HTDA0XSBbR005OV0uICBBIGJhc2ljIHBhY2tldAogICBm b3J3YXJkaW5nIHNlcnZpY2UgcmVhY2hpbmcgYWxsIGNvbm5lY3RlZCBNQU5FVCBTTUYgcm91dGVy cwogICBwYXJ0aWNpcGF0aW5nIHdpdGhpbiBhIGxvY2FsaXplZCByb3V0aW5nIHJlZ2lvbgpVSD4g PT09PT09PT09PT09PT09PQpVSD4gV2hhdCBpcyBhICJsb2NhbGl6ZWQgcm91dGluZyByZWdpb24i PwpVSD4gPT09PT09PT09PT09PT09PQpKTT4gZml4ZWQKICAgCiAgIG1heSBwcm92aWRlIGEgdXNl ZnVsCiAgIGdyb3VwIGNvbW11bmljYXRpb24gcGFyYWRpZ20gZm9yIHZhcmlvdXMgY2xhc3NlcyBv ZiBhcHBsaWNhdGlvbnMuCiAgIEFwcGxpY2F0aW9ucyB0aGF0IGNvdWxkIHRha2UgYWR2YW50YWdl IG9mIGEgc2ltcGxlIG11bHRpY2FzdAogICBmb3J3YXJkaW5nIHNlcnZpY2Ugd2l0aGluIGEgTUFO RVQgcm91dGluZyByZWdpb24gaW5jbHVkZSBtdWx0aW1lZGlhCiAgIHN0cmVhbWluZywgaW50ZXJh Y3RpdmUgZ3JvdXAtYmFzZWQgbWVzc2FnaW5nIGFuZCBhcHBsaWNhdGlvbnMsIHBlZXItCiAgIHRv LXBlZXIgbWlkZGxld2FyZSBtdWx0aWNhc3RpbmcsIGFuZCBtdWx0aS1ob3AgbW9iaWxlIGRpc2Nv dmVyeSBvcgogICByZWdpc3RyYXRpb24gc2VydmljZXMuICBTTUYgaXMgYXBwcm9wcmlhdGUgZm9y IGRlcGxveW1lbnQgaW4gbGltaXRlZAogICBkeW5hbWljIHdpcmVsZXNzIHJvdXRpbmcgYXJlYXMg ClVIPiA9PT09PT09PT09PT09PT09ClVIPiBXaGF0IGlzIGEgImxpbWl0ZWQgZHluYW1pYyB3aXJl bGVzcyByb3V0aW5nIGFyZWEiPwpVSD4gPT09PT09PT09PT09PT09PQpKTT4gZnVydGhlciBkZWZp bmVkIHRocm91Z2hvdXQgeW91IGhhZCBhIGJpZyBjZW50cmFsIGNvbW1lbnQgYWJvdXQgdGhpcyB0 aGF0IEkgdHJhY2tlZCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudC4KICAgCiAgIHNvIHRoYXQgdGhl IGZsb29kaW5nIHByb2Nlc3MgY2FuIGJlCiAgIGNvbnRhaW5lZC4KCiAgIE5vdGUgYWdhaW4gdGhh dCBGaWd1cmUgMSBwcm92aWRlcyBhIG5vdGlvbmFsIGFyY2hpdGVjdHVyZSBmb3IgdHlwaWNhbAog ICBTTUYtY2FwYWJsZSBub2Rlcy4gIEhvd2V2ZXIsIApVSD4gPT09PT09PT09PT09PT09PQpVSD4g UmVtb3ZlICJob3dldmVyIj8KVUg+ID09PT09PT09PT09PT09PT0KSk0+IGRvbmUKICAgCiAgIGEg Z29hbCBpcyB0aGF0IHNpbXBsZSBlbmQtc3lzdGVtIChub24tCiAgIGZvcndhcmRpbmcpIHdpcmVs ZXNzIG5vZGVzIApVSD4gPT09PT09PT09PT09PT09PQpVSD4gQSAibm9kZSIgKHJvdXRlcj8gaG9z dD8pIGlzIG5vdCB3aXJlbGVzcy4gSXQgY2FuIGhhdmUgc2V2ZXJhbCB3aXJlZC93aXJlbGVzcyBp bnRlcmZhY2VzLgpVSD4gPT09PT09PT09PT09PT09PQpKTT4gaXRzIHJlYWxseSBhYm91dCBsZWFm IG5vZGVzIG9mIGFueSBzb3J0IHNvIEkgcmVtb3ZlZCB0aGUgd2lyZWxlc3Mgbm9kZSByZWYuIE5p Y2UgY2F0Y2guCiAgIAogICBtYXkgYWxzbyBwYXJ0aWNpcGF0ZSBpbiBtdWx0aWNhc3QgdHJhZmZp YwogICB0cmFuc21pc3Npb24gYW5kIHJlY2VwdGlvbiB3aXRoIHN0YW5kYXJkIElQIG5ldHdvcmsg bGF5ZXIgc2VtYW50aWNzCiAgIChlLmcuLCBzcGVjaWFsIG9yIHVubmVjZXNzYXJ5IGVuY2Fwc3Vs YXRpb24gb2YgSVAgcGFja2V0cyBzaG91bGQgYmUKICAgYXZvaWRlZCBpbiB0aGlzIGNhc2UpLiAg SXQgaXMgaW1wb3J0YW50IHRoYXQgU01GIGRlcGxveW1lbnRzIGluCiAgIGxvY2FsaXplZCBlZGdl IG5ldHdvcmsgc2V0dGluZ3MgYXJlIGFibGUgdG8gY29ubmVjdCBhbmQgaW50ZXJvcGVyYXRlCiAg IHdpdGggZXhpc3Rpbmcgc3RhbmRhcmQgbXVsdGljYXN0IHByb3RvY29scyBvcGVyYXRpbmcgd2l0 aGluIG1vcmUKICAgY29udmVudGlvbmFsIEludGVybmV0IGluZnJhc3RydWN0dXJlcy4gIEEgbXVs dGljYXN0IGJvcmRlciByb3V0ZXIgb3IKICAgcHJveHkgbWVjaGFuaXNtIE1VU1QgYmUgdXNlZCB3 aGVuIGRlcGxveWVkIGFsb25nc2lkZSBtb3JlIGZpeGVkLQogICBpbmZyYXN0cnVjdHVyZSBJUCBt dWx0aWNhc3Qgcm91dGluZyBzdWNoIFByb3RvY29sIEluZGVwZW5kZW50CiAgIE11bHRpY2FzdCAo UElNKSB2YXJpYW50cyBbUkZDMzk3M10gYW5kIFtSRkM0NjAxXS4gIFdpdGggcHJlc2VudAogICBl eHBlcmltZW50YWwgU01GIGltcGxlbWVudGF0aW9ucywgcHJveHkgbWV0aG9kcyBoYXZlIGRlbW9u c3RyYXRlZApVSD4gPT09PT09PT09PT09PT09PQpVSD4gImhhdmUgZGVtb25zdHJhdGVkIiAtLT4g Y2l0YXRpb24KVUg+ID09PT09PT09PT09PT09PT0KSk0+IGFkZGVkCiAgIAogICBnYXRld2F5IGZ1 bmN0aW9uYWxpdHkgYXQgTUFORVQgYm9yZGVyIHJvdXRlcnMgb3BlcmF0aW5nIHdpdGggZXhpc3Rp bmcKICAgZXh0ZXJuYWwgSVAgbXVsdGljYXN0IHJvdXRpbmcgcHJvdG9jb2xzLiAgU01GIG1heSBi ZSBleHRlbmRlZCBvcgogICBjb21iaW5lZCB3aXRoIG90aGVyIG1lY2hhbmlzbXMgdG8gcHJvdmlk ZSBpbmNyZWFzZWQgcmVsaWFiaWxpdHkgYW5kCiAgIGdyb3VwIHNwZWNpZmljIGZpbHRlcmluZywg YnV0IHRoZSBkZXRhaWxzIGZvciB0aGlzIGFyZSBub3QgZGlzY3Vzc2VkCiAgIGhlcmUuCgoKNC4g IFNNRiBQYWNrZXQgUHJvY2Vzc2luZyBhbmQgRm9yd2FyZGluZwoKICAgVGhlIFNNRiBQYWNrZXQg UHJvY2Vzc2luZyBhbmQgRm9yd2FyZGluZyBhY3Rpb25zIGFyZSBjb25kdWN0ZWQgd2l0aAogICB0 aGUgZm9sbG93aW5nIHBhY2tldCBoYW5kbGluZyBhY3Rpdml0aWVzOgoKICAgMS4gIFByb2Nlc3Np bmcgb2Ygb3V0Ym91bmQsIGxvY2FsbHktZ2VuZXJhdGVkIG11bHRpY2FzdCBwYWNrZXRzLgogICAy LiAgUmVjZXB0aW9uIGFuZCBwcm9jZXNzaW5nIG9mIGluYm91bmQgcGFja2V0cyBvbiBhIHNwZWNp ZmljIG5ldHdvcmsKICAgICAgIGludGVyZmFjZShzKS4KVUg+ID09PT09PT09PT09PT09PT0KVUg+ IHdyb25nIHBsdXJhbDogImEiIC4uLiAiaW50ZXJmYWNlcyIKVUg+ID09PT09PT09PT09PT09PT0K Sk0+IEZpeGVkCgogICBUaGUgcHVycG9zZSBvZiBpbnRlcmNlcHRpbmcgb3V0Ym91bmQsIGxvY2Fs bHktZ2VuZXJhdGVkIG11bHRpY2FzdAogICBwYWNrZXRzIGlzIHRvIGFwcGx5IGFueSBhZGRlZCBw YWNrZXQgbWFya2luZyBuZWVkZWQgdG8gc2F0aXNmeSB0aGUKCgoKTWFja2VyLCBlZGl0b3IgJiBT TUYgRGVzaWduIFRlYW0gIEV4cGlyZXMgU2VwdGVtYmVyIDcsIDIwMTAgICAgIFtQYWdlIDhdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICBTTUYgICAgICAgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDEwCgoKICAgRFBEIHJlcXVpcmVtZW50cyBzbyB0aGF0IHByb3BlciBmb3J3 YXJkaW5nIG1heSBiZSBjb25kdWN0ZWQuICBOb3RlCiAgIHRoYXQgZm9yIHNvbWUgc3lzdGVtIGNv bmZpZ3VyYXRpb25zIHRoZSBpbnRlcmNlcHRpb24gb2Ygb3V0Ym91bmQKICAgcGFja2V0cyBmb3Ig dGhpcyBwdXJwb3NlIGlzIG5vdCBuZWNlc3NhcnkuCgogICBJbmJvdW5kIG11bHRpY2FzdCBwYWNr ZXRzIGFyZSByZWNlaXZlZCBieSB0aGUgU01GIGltcGxlbWVudGF0aW9uIGFuZAogICBwcm9jZXNz ZWQgZm9yIHBvc3NpYmxlIGZvcndhcmRpbmcuICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHByZXNl bnRseQogICBzdXBwb3J0IGZvcndhcmRpbmcgb2YgZGlyZWN0ZWQgYnJvYWRjYXN0IGFkZHJlc3Nl cyBbUkZDMjY0NF0uICBTTUYKICAgaW1wbGVtZW50YXRpb25zIE1VU1QgYmUgY2FwYWJsZSBvZiBm b3J3YXJkaW5nICJnbG9iYWwgc2NvcGUiCiAgIG11bHRpY2FzdCBwYWNrZXRzIApVSD4gPT09PT09 PT09PT09PT09PQpVSD4gV2hhdCBpcyBhICJnbG9iYWwgc2NvcGUgbXVsdGljYXN0IHBhY2tldCI/ IE1heWJlIGFuICJJUCBkYXRhZ3JhbSB3aG9zZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGEgZ2xv YmFsIElQIGFkZHJlc3MgYXMgc3BlY2lmaWVkIGluIFJGQzIzNzM/IgpVSD4gPT09PT09PT09PT09 PT09PQpKTT4gYWRkZWQgYXBwcm9wcmlhdGUgcmVmcyBmb3IgSVB2NCBhbmQgSVB2Ni4gTmljZSBj YXRjaC4KCiAgIAogICB0byBzdXBwb3J0IGdlbmVyaWMgbXVsdGljYXN0IGFwcGxpY2F0aW9uIG5l ZWRzIG9yCiAgIHRvIGRpc3RyaWJ1dGUgZGVzaWduYXRlZCBtdWx0aWNhc3QgdHJhZmZpYyBpbmdy ZXNzaW5nIHRoZSBNQU5FVAogICByb3V0aW5nIHJlZ2lvbiB2aWEgYm9yZGVyIHJvdXRlcnMKVUg+ ID09PT09PT09PT09PT09PT0KVUg+IEFyZSAiTUFORVQgYm9yZGVyIHJvdXRlcnMiIGRlZmluZWQg c29tZXdoZXJlPwpVSD4gPT09PT09PT09PT09PT09PQogICAKSk0+ICBUaGF0IGlzIHNvbWV3aGF0 IGxlZnQgb3BlbiAgYXMgdGhlcmUgYXJlIG1hbnkgYm9yZGVyIHJvdXRlciBhcHByb2FjaGVzIGJ1 dCB3YXMgaW50ZW5kZWQgdG8gYmUgc3RhbmRhcmQgaW5mcmFzdHJ1Y3R1cmUgb3Igb3RoZXIgcm91 dGluZy4gIFRIZXJlIGhhdmUgaGFzIGJlZW4gY29kZSBhbmQgZGVtb25zdHJhdGlvbiBvZiBTTUYg YW5kIHN0YW5kYXJkIFBJTSB2YXJpYW50IGJvcmRlciBnYXRld2F5cy4gIEFzIEVYUCBpbnRlbnQg SSB3b3VsZG4ndCB3aGF0IHRvIG1ha2UgZ2F0ZXdheWluZyB0b28gc3BlY2lmaWMuIEFueSBzdWdn ZXN0aW9ucz8gSSBjb3VsZCBhZGQgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIGFzIGEgYm9yZGVy IGV4YW1wbGUgaWYgdGhhdCBoZWxwcy4gIE5vdCBzdXJlIGl0IGlzIGNyaXRpY2FsIGF0IHRoaXMg c3RhZ2UuCgogICAuICBUaGUgbXVsdGljYXN0IGFkZHJlc3NlcyB0byBiZQogICBmb3J3YXJkZWQg d2lsbCBiZSBtYWludGFpbmVkIGJ5IGFuIGEgcHJpb3JpIGxpc3Qgb3IgYSBkeW5hbWljCiAgIGZv cndhcmRpbmcgaW5mb3JtYXRpb24gYmFzZSAoRklCKSB0aGF0IE1BWSBpbnRlcmFjdCB3aXRoIGZ1 dHVyZSBNQU5FVAogICBkeW5hbWljIGdyb3VwIG1lbWJlcnNoaXAgZXh0ZW5zaW9ucyBvciBtYW5h Z2VtZW50IGZ1bmN0aW9ucy4gIFRoZXJlCiAgIHdpbGwgYWxzbyBiZSBhIHdlbGwta25vd24gbXVs dGljYXN0IGdyb3VwIGZvciBmbG9vZGluZyB0byBhbGwgU01GCiAgIGZvcndhcmRlcnMKVUg+ID09 PT09PT09PT09PT09PT0KVUg+IEhhcyAiU01GIGZvcndhcmRlciIgYmVlbiBkZWZpbmVkIHNvbWV3 aGVyZT8KVUg+ID09PT09PT09PT09PT09PT0KSk0+ICAgVGhpcyBzaG91bGQgYmUgY2hhbmdlZCB0 byBTTUYgbm9kZXMgaW4gYSByb3V0aW5nIGRvbWFpbiBhbmQgYmUgY29uc2lzdGVudCB3aXRoIG90 aGVyIGRlZmluaXRpb24gb2YgbGltaXRlZCBTTUYgcm91dGluZyBkb21haW4gaW4gQXBwbGljYWJp bGl0eSBzZWN0aW9uLgoKICAgLiAgVGhpcyBtdWx0aWNhc3QgZ3JvdXAgaXMgc3BlY2lmaWVkIHRv IGNvbnRhaW4gYWxsIE1BTkVUCiAgIFNNRiByb3V0ZXJzIG9mIGEgY29ubmVjdGVkIE1BTkVUIHJv dXRpbmcgcmVnaW9uClVIPiA9PT09PT09PT09PT09PT09ClVIPiBXaGVyZSBpcyAiY29ubmVjdGVk IE1BTkVUIHJvdXRpbmcgcmVnaW9uIiBkZWZpbmVkPwpVSD4gPT09PT09PT09PT09PT09PQoKICAg LCBzbyB0aGF0IHBhY2tldHMKICAgdHJhbnNtaXR0ZWQgdG8gdGhlIG11bHRpY2FzdCBhZGRyZXNz IGFzc29jaWF0ZWQgd2l0aCB0aGUgZ3JvdXAgd2lsbAogICBiZSBkZWxpdmVyZWQgdG8gYWxsIGNv bm5lY3RlZCBTTUYgcm91dGVycy4KVUg+ID09PT09PT09PT09PT09PT0KVUg+IFdoZXJlIGlzICJj b25uZWN0ZWQgU01GIHJvdXRlcnMiIGRlZmluZWQ/ClVIPiA9PT09PT09PT09PT09PT09CkpNPiBJ IHRoaW5rIHRoZSBhYm92ZSAzIGNvbW1lbnRzIGFyZSBhbGwgaW1wcm92ZWQgaW4gdGhlIHNhbWUg d2F5IGluIHRoZSBuZXcgdGV4dC4KICAgCiAgIEZvciBJUHY2LCB0aGUgbXVsdGljYXN0CiAgIGFk ZHJlc3MgaXMgc3BlY2lmaWVkIHRvIGJlICJzaXRlLWxvY2FsIi4gIFRoZSBuYW1lIG9mIHRoZSBt dWx0aWNhc3QKICAgZ3JvdXAgaXMgIlNMLU1BTkVULVJPVVRFUlMiLgpVSD4gPT09PT09PT09PT09 PT09PQpVSD4gSSB3b3VsZCBtb3ZlIHRoaXMgdG8gdGhlIGVuZCBvZiB0aGUgc3BlYy4gKElBTkEg Y29uc2lkZXJhdGlvbnMpClVIPiA9PT09PT09PT09PT09PT09CkpNPiAgT2ssIHRoaXMgd2FzIGlu IHRoZSBvdGhlciBJQU5BIE1BTkVUIElEIGFuZCBnb3QgbW92ZWQgb3V0LiBTbyB5ZWFoIGl0IGJl bG9uZ3MgaGVyZSBub3cuCgogICBNaW5pbWFsbHkgU01GIFNIQUxMClVIPiA9PT09PT09PT09PT09 PT09ClVIPiBUaGlzIGlzIHRoZSBvbmx5IHNlY3Rpb24gaW4gdGhpcyBzcGVjIHRoYXQgdXNlZCAi U0hBTEwiIGluc3RlYWQgb2YgIk1VU1QiLiBJIHdvdWxkIHN0aWNrIHdpdGggIk1VU1QiLgpVSD4g PT09PT09PT09PT09PT09PQogICAKICAgZm9yd2FyZCwgYXMKICAgaW5zdHJ1Y3RlZCBieSB0aGUg cmVsYXkgc2V0IHNlbGVjdGlvbiBhbGdvcml0aG0sIHVuaXF1ZSAobm9uLQogICBkdXBsaWNhdGUp IHBhY2tldHMgcmVjZWl2ZWQgZm9yIHRoaXMgd2VsbC1rbm93biBncm91cCBhZGRyZXNzIHdoZW4K ICAgdGhlIFRUTCBvciBob3AgY291bnQgdmFsdWUgClVIPiA9PT09PT09PT09PT09PT09ClVIPiBz L2hvcCBjb3VudC9ob3AgbGltaXQvClVIPiA9PT09PT09PT09PT09PT09CiAgIAogICBpbiB0aGUg SVAgaGVhZGVyIGlzIGdyZWF0ZXIgdGhhbiAxLiAgU01GCiAgIFNIQUxMIGZvcndhcmQgYWxsIGFk ZGl0aW9uYWwgZ2xvYmFsIHNjb3BlIGFkZHJlc3NlcyBzcGVjaWZpZWQgd2l0aGluCiAgIHRoZSBk eW5hbWljIEZJQiBvciBjb25maWd1cmVkIGxpc3QgYXMgd2VsbC4gIEluIGFsbCBjYXNlcywgdGhl CiAgIGZvbGxvd2luZyBydWxlcyBTSEFMTCBiZSBvYnNlcnZlZCBmb3IgU01GIG11bHRpY2FzdCBm b3J3YXJkaW5nOgoKICAgMS4gIE11bHRpY2FzdCBwYWNrZXRzIHdpdGggVFRMIDw9IDEgTVVTVCBO T1QgYmUgZm9yd2FyZGVkLgpVSD4gPT09PT09PT09PT09PT09PQpVSD4gVW5jbGVhciBkZWZpbml0 aW9uIG9mICJNdWx0aWNhc3QgcGFja2V0IjsgYmV0dGVyIHVzZSAiSVAgZGF0YWdyYW0gd2l0aCBt dWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyIgb3IgdGhlIGxpa2UuLi4gc2ltaWxhciBmb3Ig aXRlbSAyLgpVSD4gPT09PT09PT09PT09PT09PQoKSk0+IE11bHRpY2FzdCBkYXRhZ3JhbXMgYXJl IGRlZmluZWQgaW4gb3RoZXIgZG9jdW1lbnRzLiBIZXJlIEkgbWVhbiBhbnkgbXVsdGljYXN0IHBh Y2tldCB0aGF0IHBhc3NlcyB0aGUgZm9yd2FyZGVkIHJ1bGVzLiBUaGVzZSBjb3VsZCBiZSAoUyxH KSBvciAoKiwgRykgZGVmaW5lZCB2aWEgYSBzZXBhcmF0ZSBwcm9jZXNzLiAKCiAgIDIuICBMaW5r IGxvY2FsIG11bHRpY2FzdCBwYWNrZXRzIE1VU1QgTk9UIGJlIGZvcndhcmRlZC4KICAgMy4gIElu Y29taW5nIG11bHRpY2FzdCBwYWNrZXRzIHdpdGggYW4gSVAgc291cmNlIGFkZHJlc3MgbWF0Y2hp bmcgb25lCiAgICAgICBvZiB0aG9zZSBvZiB0aGUgbG9jYWwgU01GIHJvdXRlciBpbnRlcmZhY2Uo cykgTVVTVCBOT1QgYmUKICAgICAgIGZvcndhcmRlZC4KICAgNC4gIFJlY2VpdmVkIHBhY2tldCBm cmFtZXMgd2l0aCB0aGUgTUFDIHNvdXJjZSBhZGRyZXNzIG1hdGNoaW5nIHRoZQogICAgICAgbG9j YWwgU01GIHJvdXRlciBpbnRlcmZhY2UocykgTVVTVCBOT1QgYmUgZm9yd2FyZGVkLgoKVUg+ID09 PT09PT09PT09PT09PT0KVUg+IEhhcyBJUCBmcmFnbWVudGF0aW9uIGJlZW4gbWVudGlvbmVkIGJl Zm9yZT8gQXJlIHRoZXNlIElQIGZyYW1lcz8gVGhlbiB0aGV5IGRvbid0IGhhdmUgYSBNQUMgYWRk cmVzcyAob25seSB0aGUgTDIgZnJhbWUgc3Vycm91bmRpbmcgdGhlIElQIGZyYW1lIGhhcyBvbmUp LiBEbyBhbGwgTDIgZnJhbWVzIGhhdmUgTUFDIGFkZHJlc3NlcyAodGhlcmUgbWF5IGJlIHN0cmFu Z2Ugbm9uLUlFRUUtTklDcyB1c2VkIGluIGEgTUFORVQpLiBUaGUgY2FzZSBvZiBzZXZlcmFsIGlu dGVyZmFjZXMgaXMgdW5jbGVhciAoYmV0dGVyIGRldGFpbCBpdCBsaWtlICJSZWNlaXZlZCBmcmFt ZXMgd2l0aCB0aGUgTUFDIHNvdXJjZSBhZGRyZXNzIG1hdGNoaW5nIGFueSBNQUMgYWRkcmVzcyBv ZiBhbnkgb2YgdGhlIHJvdXRlcnMnIGludGVyZmFjZXMuLi4iIG9yIHRoZSBsaWtlLikKVUg+ID09 PT09PT09PT09PT09PT0KCiAgIDUuICBSZWNlaXZlZCBwYWNrZXRzIGZvciB3aGljaCBTTUYgY2Fu bm90IHJlYXNvbmFibHkgZW5zdXJlIHRlbXBvcmFsCiAgICAgICBEUEQgdW5pcXVlbmVzcyBNVVNU IE5PVCBiZSBmb3J3YXJkZWQuCgpVSD4gPT09PT09PT09PT09PT09PQpVSD4gSXMgdGhhdCBleHBs YWluZWQgYW55d2hlcmUgaW4gZGV0YWlsPyBXaGF0IGRhcyAicmVhc29uYWJseSIgbWVhbj8gV2hh dCBkb2VzICJ0ZW1wb3JhbCB1bmlxdWVuZXNzIiBtZWFuPyBEb2VzIHRoYXQgbWVhbiB0aGF0IHRo ZSBEUEQgZXhwbGFpbmVkIGxhdGVyIGluIHRoZSBzcGVjIGlzIHBlcmZvcm1lZCBhdCB0aGlzIG1v bWVudD8gKDUuKQpVSD4gPT09PT09PT09PT09PT09PQoKICAgNi4gIFdoZW4gcGFja2V0cyBhcmUg Zm9yd2FyZGVkLCBUVEwgb3IgaG9wIGxpbWl0IFNIQUxMIGJlIGRlY3JlbWVudGVkCiAgICAgICBi eSBvbmUuCgpVSD4gPT09PT09PT09PT09PT09PQpVSD4gSSBsaWtlIHRoaXMgb3JkZXJlZCBsaXN0 IG9mIGFjdGlvbnMuIEJ1dCBpdCBpcyBub3QgY29uc2VxdWVudGx5IHVzZWQgdGhyb3VnaG91dCB0 aGUgZG9jLiBJdCB3b3VsZCBiZSB2ZXJ5IG5pY2UgdGhyb3VnaG91dCB0aGUgd2hvbGUgZG9jdW1l bnQgdG8ga25vdyBpbiB3aGF0IG9yZGVyIHRvIGRvIHdoYXQgYWN0aW9uLgpJIHN1Z2dlc3Q6IHMv U0hBTEwvTVVTVC8KVUg+ID09PT09PT09PT09PT09PT0KCiAgIE5vdGUgdGhhdCBydWxlICMzIGlz IGltcG9ydGFudCBiZWNhdXNlIGluIHdpcmVsZXNzIG5ldHdvcmtzLAoKVUg+ID09PT09PT09PT09 PT09PT0KVUg+IFdoYXQgaXMgYSAid2lyZWxlc3MgbmV0d29yayI/IE1heWJlIHlvdSBtZWFuIHNv bWV0aGluZyBsaWtlICJhIG5ldHdvcmsgY29uc2lzdGluZyBvZiBtb2JpbGUgcm91dGVycyB3aXRo IGF0IGxlYXN0IG9uZSB3aXJlbGVzcyBpbnRlcmZhY2UgcGFydGljaXBhdGluZyBpbiB0aGUgc2Ft ZSByb3V0aW5nIGRvbWFpbi4uLi4iICh3ZWxsLCBoYXMgdG8gYmUgdGhvdWdodCBhYm91dC4uLikK VUg+ID09PT09PT09PT09PT09PT0KICAgCiAgIAogICB0aGUKICAgbG9jYWwgU01GIHJvdXRlciAK VUg+ID09PT09PT09PT09PT09PT0KVUg+IFdoYXQgaXMgdGhlICJsb2NhbCIgU01GIHJvdXRlcj8g VGhhdCBzaG91bGQgYmUgZGVmaW5lZCAoYXMgaXQgaXMgZG9uZSBpbiBPTFNSdjIsIGZvciBleGFt cGxlKQpVSD4gPT09PT09PT09PT09PT09PQogICAKICAgbWF5IHJlY2VpdmUgcmUtdHJhbnNtaXNz aW9ucyBvZiBpdHMgb3duIHBhY2tldHMgd2hlbgogICB0aGV5IGFyZSBmb3J3YXJkZWQgYnkgbmVp Z2hib3Jpbmcgbm9kZXMuICAKVUg+ID09PT09PT09PT09PT09PT0KVUg+IElzICJuZWlnaGJvcmlu ZyBub2RlcyIgZGVmaW5lZD8gSXMgdGhhdCBOSERQIHRlcm1pbm9sb2d5PwpVSD4gPT09PT09PT09 PT09PT09PQpKRD4gPT09PT09PT09PT09PQpKRD4gQWRqYWNlbnQgU01GIHJvdXRlcnM/ICBvciBi ZXR0ZXIgeWV0ICJuZWlnaGJvcmluZyBTTUYgbm9kZXMiCkpEPiA9PT09PT09PT09PT09CiAgIAog ICBUaGlzIHJ1bGUgYXZvaWRzCiAgIHVubmVjZXNzYXJ5IHJldHJhbnNtaXNzaW9uIG9mIGxvY2Fs bHktZ2VuZXJhdGVkIHBhY2tldHMgZXZlbiB3aGVuCiAgIG90aGVyIGZvcndhcmRpbmcgZGVjaXNp b24gcnVsZXMgd291bGQgYXBwbHkuCgogICBBbiBhZGRpdGlvbmFsIHByb2Nlc3NpbmcgcnVsZSBh bHNvIG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgYmFzZWQgdXBvbgogICBhIHBvdGVudGlhbCBzZWN1 cml0eSB0aHJlYXQuICAKVUg+ID09PT09PT09PT09PT09PT0KVUg+IEluIHRoZSBsaXN0IGFib3Zl LCB3aGVuIHdvdWxkIHRoaXMgcnVsZSBiZSBhcHBsaWVkPwpVSD4gPT09PT09PT09PT09PT09PQoK Sk0+IFRIaXMgaXMgYSBuZXcgcnVsZSBhbmQgd291bGQgYmUgY2hlY2tlZCBwcmlvciB0byA2Lgog ICAKICAgQXMgZGlzY3Vzc2VkIGZ1cnRoZXIgaW4gU2VjdGlvbiAxMCwKCi4uLgogICBPbmNlIHRo ZXNlIGNyaXRlcmlhIGhhdmUgYmVlbiBtZXQsIGFuIFNNRiBpbXBsZW1lbnRhdGlvbiBNVVNUIG1h a2UgYQogICBmb3J3YXJkaW5nIGRlY2lzaW9uIGRlcGVuZGVudCB1cG9uIHRoZSByZWxheSBzZXQg c2VsZWN0aW9uIGFsZ29yaXRobQogICBpbiB1c2UuICBJZiB0aGUgU01GIGltcGxlbWVudGF0aW9u IGlzIHVzaW5nIENsYXNzaWNhbCBGbG9vZGluZyAoQ0YpLAogICB0aGUgZm9yd2FyZGluZyBkZWNp c2lvbiBpcyBpbXBsaWNpdCBvbmNlIERQRCB1bmlxdWVuZXNzIGlzCiAgIGRldGVybWluZWQuICAK VUg+ID09PT09PT09PT09PT09PT0KVUg+IEhvdyBpcyBpdCBkZXRlcm1pbmVkPyAoc3BlY2lmaWNh dGlvbiBuZWVkZWQgaGVyZSkKVUg+ID09PT09PT09PT09PT09PT0KCkpNPiBUaGlzIGlzIGEgbG9j YWwgZGVjaXNpb24gYW5kIHRoZSBub2RlIHdpbGwga25vdyB3aGljaCBtb2RlIGJhc2VkIHVwb24g b3BlcmF0aW9uIGNvbmZpZ3VyYXRpb24uCiAgIAogICBPdGhlcndpc2UsIGEgZm9yd2FyZGluZyBk ZWNpc2lvbiBkZXBlbmRzIHVwb24gdGhlCiAgIGN1cnJlbnQgaW50ZXJmYWNlLXNwZWNpZmljIHJl bGF5IHNldCBzdGF0ZS4gIFRoZSBkZXNjcmlwdGlvbnMgb2YgdGhlCiAgIHJlbGF5IHNldCBzZWxl Y3Rpb24gYWxnb3JpdGhtcyBpbiB0aGUgQXBwZW5kaWNlcyAKVUg+ID09PT09PT09PT09PT09PT0K VUg+IFdoaWNoIHNlY3Rpb24gaW4gdGhlIEFwcGVuZGljZXM/ClVIPiA9PT09PT09PT09PT09PT09 CkpNPiBFYWNoIEFwcGVuZGl4IG5vdyBjb3ZlcnMgc2VwYXJhdGUgcmVsYXkgc2V0IGRpc2N1c3Np b25zLgoKICAgdG8gdGhpcyBkb2N1bWVudAogICBzcGVjaWZ5IHRoZSByZXNwZWN0aXZlIGhldXJp c3RpY3MgZm9yIG11bHRpY2FzdCBwYWNrZXQgZm9yd2FyZGluZyBhbmQKICAgc3BlY2lmaWMgRFBE IG9yIG90aGVyIHByb2Nlc3NpbmcgcmVxdWlyZWQgdG8gYWNoaWV2ZSBjb3JyZWN0IFNNRgogICBi ZWhhdmlvci4gIEZvciBleGFtcGxlLCBvbmUgY2xhc3Mgb2YgZm9yd2FyZGluZyBpcyBiYXNlZCB1 cG9uIHJlbGF5CiAgIHNldCBlbGVjdGlvbiBzdGF0dXMgYW5kIHRoZSBwYWNrZXQncyBwcmV2aW91 cyBob3AgZm9yd2FyZGVyCiAgCiAgICwgd2hpbGUKICAgb3RoZXIgY2xhc3NlcyBkZXNpZ25hdGUg dGhlIGxvY2FsIFNNRiByb3V0ZXIgYXMgYSBmb3J3YXJkZXIgZm9yIGFsbAogICBuZWlnaGJvcmlu ZyBub2Rlcy4KICAgClVIPiA9PT09PT09PT09PT09PT09ClVIPiBOb3Qgc3VyZSB0aGlzIHdob2xl IHNlY3Rpb24gYWJvdXQgdGhpcyBzZWN1cml0eSBhc3BlY3QgYmVsb25ncyBoZXJlIChpdCdzIG5v dCBjb3JlIHNwZWMpLiBNYXliZSBtb3ZlIGl0IHRvIHRoZSAiU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMiIHNlY3Rpb24gYXQgdGhlIGVuZD8gT3IgYW5vdGhlciBkcmFmdD8gSSBhbSBub3Qgc3VyZSBo ZXJlLi4uClVIPiA9PT09PT09PT09PT09PT09CkpNPiBZZXMsIGl0IGJlbG9uZ3MgaW4gdGhlIGRv Y3VtZW50LiBTaW5jZSB0aGUgcHJvY2Vzc2luZyBydWxlcyBhcmUgYmVpbmcgaW50cm9kdWNlZCBo ZXJlIGl0IHNlZW1lZCBpdCBuaWNlIHRpbWUgdG8gaW50cm9kdWNlIGlzc3Vlcy4gQ091bGQgbGVh dmUgaXQgdG8gbGF0ZXIgaW4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYnV0IGl0cyBhY3R1YWxs eSBhIHNwZWNpZmljIHByb2Nlc3NpbmcgcnVsZSBjb25zaWRlcmF0aW9uLiBSZW1lbWJlciB0aGlz IGlzIEVYUCBwcm9wb3NlZCB0cmFjayBhdCB0aGlzIHBvaW50LiBJIGRvbid0IHdhbnQgdG8gbGVh dmUgb3V0IGd1aWRhbmNlIHRoYXQgbWF5IGJlIHdvcnRoIGV4cGxvcmluZyBpbiB0aGUgZm9yd2Fy ZGluZyBydWxlcyBhcyBzb21lb25lIGlzIGJlZ2lubmluZyB0byBpbXBsZW1lbnQgY29kZS4KCjUu ICBTTUYgRHVwbGljYXRlIFBhY2tldCBEZXRlY3Rpb24KCiAgIER1cGxpY2F0ZSBwYWNrZXQgZGV0 ZWN0aW9uIChEUEQpIGlzIGEgY29tbW9uIHJlcXVpcmVtZW50IGluIE1BTkVUIApVSD4gPT09PT09 PT09PT09PT09PQpVSD4gImNvbW1vbiByZXF1aXJlbWVudCIgbWF5IHJlcXVpcmUgY2l0YXRpb25z ClVIPiA9PT09PT09PT09PT09PT09CkpNPiBTb2Z0ZW5lZCB0aGlzIGFuZCBjaGFuZ2VkIHRoZSB3 b3JkaW5nIGEgbGl0dGxlIHNpbmNlIGl0cyBjb21tb24gcHJhY3RpY2UuIFRoZSBwb2ludCBpcyBk dWUgdG8gZHluYW1pY3MgYW5kIHJldHJhbnNtaXNzaW9uIG91dCB0aGUgc2FtZSBwaHlzaWNhbCBp bnRlcmZhY2UgaW4gbWFueSBjYXNlcyBkdXAgZGV0ZWN0aW9uIGlzIG5lZWRlZC4gVGhpcyBpcyBh bHJlYWR5IHVzZWQgd2l0aGluIGNvbnRyb2wgcGxhbmUgTUFORVQgcHJvdG9jb2xzIGFzIHlvdXIg YXdhcmUuIE5vdGhpbmcgbmV3IGhlcmUuCiAgIAogICBvcgogICB3aXJlbGVzcyBtZXNoIHBhY2tl dCBmb3J3YXJkaW5nIGJlY2F1c2UgcGFja2V0cyBtYXkgYmUgdHJhbnNtaXR0ZWQKICAgb3V0IHRo ZSBzYW1lIHBoeXNpY2FsIGludGVyZmFjZSB1cG9uIHdoaWNoIHRoZXkgYXJyaXZlZCBhbmQgbm9k ZXMgbWF5CiAgIGFsc28gcmVjZWl2ZSBjb3BpZXMgb2YgcHJldmlvdXNseS10cmFuc21pdHRlZCBw YWNrZXRzIGZyb20gb3RoZXIKICAgZm9yd2FyZGluZyBuZWlnaGJvcnMuICBTTUYgaW1wbGVtZW50 YXRpb25zIE1VU1QgZGV0ZWN0IGFuZCBhdm9pZAogICBmb3J3YXJkaW5nIGR1cGxpY2F0ZSBtdWx0 aWNhc3QgcGFja2V0cyB1c2luZyB0ZW1wb3JhbCBwYWNrZXQKICAgaWRlbnRpZmljYXRpb24uICAK VUg+ID09PT09PT09PT09PT09PT0KVUg+IFdoZXJlIGlzICJ0ZW1wb3JhbCBwYWNrZXQgaWRlbnRp ZmljYXRpb24iIGRlZmluZWQ/ClVIPiA9PT09PT09PT09PT09PT09CkpNPiBJdCBpcyBkaXNjdXNz ZWQgaW4gdGhlIHBhcmFncmFwaHMgdGhhdCBpbW1lZGlhdGVseSBmb2xsb3cuIEknbGwgbWFrZSBp dCBtb3JlIGV4cGxpY2l0LgoKICAgSXQgaXMgUkVDT01NRU5ERUQgdGhpcyBiZSBpbXBsZW1lbnRl ZCBieSBrZWVwaW5nIGEKICAgaGlzdG9yeSBvZiByZWNlbnRseS1wcm9jZXNzZWQgbXVsdGljYXN0 IHBhY2tldHMgClVIPiA9PT09PT09PT09PT09PT09ClVIPiAibXVsdGljYXN0IHBhY2tldHMiIHNo b3VsZCBiZSBkZWZpbmVkClVIPiA9PT09PT09PT09PT09PT09CkpNPiBNdWx0aWNhc3QgcGFja2V0 cyBpcyB3aGF0IGlzIHVzZWQgaW4gUkZDIDQ2MDEsZXRjLiBPdXIgZm9yd2FyZGluZyBzZWN0aW9u IGRlZmluZSB3aGF0IGNsYXNzZXMgb2YgbXVsdGljYXN0IHBhY2tldHMgbWlnaHQgYmUgZm9yd2Fy ZGFibGUuIEFnYWluIHdlIGZvcndhcmQgZnJhZ21lbnRzIHNvIGRhdGFncmFtIGlzIG5vdCBnb29k IGVpdGhlci4KCiAgIAogICBmb3IgY29tcGFyaXNvbiB0bwogICBpbmNvbWluZyBwYWNrZXRzLiAg Rm9yIGJvdGggSVB2NCBhbmQgSVB2NiwgdGhpcyBkb2N1bWVudCBkZXNjcmliZXMKICAgdHdvIGJh c2ljIG11bHRpY2FzdCBkdXBsaWNhdGUgcGFja2V0IGRldGVjdGlvbiBtZWNoYW5pc21zOiBoZWFk ZXIKICAgY29udGVudCBpZGVudGlmaWNhdGlvbi1iYXNlZCAoSS1EUEQpIGFuZCBoYXNoLWJhc2Vk IChILURQRCkgZHVwbGljYXRlCiAgIGRldGVjdGlvbi4gIFRoZSB0d28gYXBwcm9hY2hlcyBhcmUg ZGVzY3JpYmVkIGZvciBleHBlcmltZW50YWwKCgoKTWFja2VyLCBlZGl0b3IgJiBTTUYgRGVzaWdu IFRlYW0gIEV4cGlyZXMgU2VwdGVtYmVyIDcsIDIwMTAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICAgICBTTUYgICAgICAgICAgICAgICAgICAgICAgICBNYXJj aCAyMDEwCgoKICAgcHVycG9zZXMuICBUcmFkZS1vZmZzIG9mIHRoZSB0d28gYXBwcm9hY2hlcyB0 byBEUEQgbWVyaXQgZGlmZmVyZW50CiAgIGNvbnNpZGVyYXRpb24gZGVwZW5kZW50IHVwb24gdGhl IHNwZWNpZmljIFNNRiBkZXBsb3ltZW50IHNjZW5hcmlvLgogICBCZWNhdXNlIG9mIHRoZSBwb3Rl bnRpYWwgYWRkaXRpb24gb2YgYSBob3AtYnktaG9wIG9wdGlvbiBoZWFkZXIgd2l0aAogICBJUHY2 LCBTTUYgZGVwbG95bWVudHMgTVVTVCBiZSBjb25maWd1cmVkIHRvIHVzZSBhIGNvbW1vbiBtZWNo YW5pc20KICAgYW5kIERQRCBhbGdvcml0aG0uICBUaGUgbWFpbiBkaWZmZXJlbmNlIGJldHdlZW4g SVB2NCBhbmQgSVB2NiBTTUYgRFBECiAgIHNwZWNpZmljYXRpb24gaXMgdGhlIGF2b2lkYW5jZSBv ZiBhbnkgYWRkaXRpb25hbCBoZWFkZXIgb3B0aW9ucyBpbgogICB0aGUgSVB2NCBjYXNlLgoKICAg Rm9yIGVhY2ggbmV0d29yayBpbnRlcmZhY2UsIFNNRiBpbXBsZW1lbnRhdGlvbnMgTVVTVCBtYWlu dGFpbiBEUEQKICAgcGFja2V0IHN0YXRlIGFzIG5lZWRlZCB0byBzdXBwb3J0IHRoZSBmb3J3YXJk aW5nIGhldXJpc3RpY3Mgb2YgdGhlCiAgIHJlbGF5IHNldCBhbGdvcml0aG0gdXNlZC4gIAoKVUg+ ID09PT09PT09PT09PT09PT0KVUg+IEkgd291bGQgcHJlZmVyIHRvIGhhdmUgYSBwcmVjaXNlIHNw ZWNpZmljYXRpb24gb2YgdGhlIGluZm9ybWF0aW9uZW4gYmFzZXMgdGhhdCBhcmUgcmVxdWlyZWQg KGFzIGl0IGlzIGRvbmUsIGZvciBleGFtcGxlLCBpbiBPTFNSdjIpClVIPiA9PT09PT09PT09PT09 PT09CkpNPiBCcmlhbiBBZGFtc29uIChrbm93biBpbXBsZW1lbnRvcikgYW5kIG15c2VsZiBmZWVs IGF0IHRoaXMgcG9pbnQgdGhhdCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgYW5kIG1heSBi ZSBkb25lIGRpZmZlcmVudCB3YXlzLiBXZSB3b3VsZCBwcmVmZXIgdG8gbGVhdmUgaW1wbGVtZW50 YXRpb24gZGV0YWlscyBvdXQgZm9yIG5vdy4KICAgCiAgIFRoZSBzcGVjaWZpYyByZXF1aXJlbWVu dHMgb2Ygc2V2ZXJhbCByZWxheQogICBzZXQgc2VsZWN0aW9uIGFsZ29yaXRobXMgYW5kIHRoZWly IGZvcndhcmRpbmcgcnVsZXMgYXJlIGRlc2NyaWJlZCBpbgogICB0aGUgQXBwZW5kaWNlcyBvZiB0 aGlzIGRvY3VtZW50LiAgSW4gZ2VuZXJhbCB0aGlzIGludm9sdmVzIGtlZXBpbmcKICAgdHJhY2sg b2YgcHJldmlvdXNseSBmb3J3YXJkZWQgcGFja2V0cyBzbyB0aGF0IGR1cGxpY2F0ZXMgYXJlIG5v dAogICBmb3J3YXJkZWQsIGJ1dCBzb21lIHJlbGF5IHRlY2huaXF1ZXMgbWF5IGhhdmUgYWRkaXRp b25hbAogICBjb25zaWRlcmF0aW9ucy4KCiAgIEZvciBJLURQRCwgcGFja2V0cyBhcmUgaWRlbnRp ZmllZCB1c2luZyBleHBsaWNpdCBpZGVudGlmaWVycyBmcm9tIHRoZQogICBJUCBoZWFkZXIuICAK ClVIPiA9PT09PT09PT09PT09PT09ClVIPiBJLURQRCBoYXMgbm90IGJlZW4gZGVmaW5lZCB1bnRp bCBub3cuIFRoaXMgaXMgYSBtYWpvciBwcm9ibGVtIG9mIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBo cy4gSSB3b3VsZCBwcmVmZXIgdG8gaGF2ZSBhbiBpbnRyb2R1Y3Rpb24gdG8gZGlmZmVyZW50IERQ RHMgdGhhdCBhcmUgZGVmaW5lZCBpbiB0aGUgc3BlYywgdGhlbiBhIHNwZWNpZmljYXRpb24gb2Yg ZWFjaCBpbiBkZXRhaWwuIFRoaXMgaXMgbWl4ZWQgdXAgaW4gdGhlIGZvbGxvd2luZyBwYWdlcy4K VUg+IFRoZSBzZW50ZW5jZSAiaWRlbnRpZmllZCB1c2luZyBbLi4uXSBpZGVudGlmaWVycyIgc291 bmRzIGxpa2UgYSB0YXV0b2xvZ3kKVUg+ID09PT09PT09PT09PT09PT0KSk0+IEludHJvZHVjdGlv biB0byBkaWZmZXJlbnQgRFBEcyB3YXMgdGhlcmUgYnV0IGFkZGVkIGFub3RoZXIgZXhwbGljaXQg ZXhwbGFuYXRpb24uIFNlZW1zIHJlZHVuZGFudCB0byBtZSBidXQgb2suCkpNPiBUYXV0b2xvZ3kg bm90ZWQgYW5kIGZpeGVkIHRoZXJlLgoKICAgCiAgIFRoZSBzcGVjaWZpYyBpZGVudGlmaWVyIHRv IHVzZSBkZXBlbmRzIHVwb24gdGhlIElQCiAgIHByb3RvY29sIHZlcnNpb24gYW5kIHRoZSB0eXBl IG9mIHBhY2tldC4gCgpVSD4gPT09PT09PT09PT09PT09PQpVSD4gV2hhdCAidHlwZSBvZiBwYWNr ZXQiPyBJUCBkYXRhZ3JhbSB0eXBlPyBXaGVyZSBpcyB0aGF0IGRlZmluZWQ/ClVIPiA9PT09PT09 PT09PT09PT09CkpNPiBPSyBnb29kIGNhdGNoLCBtYWRlIGl0IGV4cGxpY2l0IHRoYXQgaW5jbHVk ZXMgdGVzdGluZyBmb3IgZnJhZ21lbnRhdGlvbiBhbmQgSVBTRUMuCiAgIAogICBGb3IgZXhhbXBs ZSwgSVB2NCBbUkZDMDc5MV0KICAgcHJvdmlkZXMgYW4gIklkZW50aWZpY2F0aW9uIiBmaWVsZCB0 aGF0IG1heSBhc3Npc3QgYSBEUEQgbWVjaGFuaXNtLAogICBhbmQgcGFja2V0cyB0aGF0IGNvbnRh aW4gSVBTZWMgcHJvdG9jb2wgaGVhZGVycyBhbHNvIHByb3ZpZGUgc3VpdGFibGUKICAgcGFja2V0 IGlkZW50aWZpZXJzLiAgRnJhZ21lbnRlZCBwYWNrZXRzIGFsc28gcHJvdmlkZSBhZGRpdGlvbmFs CiAgIGlkZW50aWZpZXJzIHRoYXQgbmVlZCB0byBiZSBjb25zaWRlcmVkLiAgVGhlc2UgaWRlbnRp ZmllciBmaWVsZHMgYXJlCiAgIHVuaXF1ZSB3aXRoaW4gdGhlIGNvbnRleHQgb2Ygc291cmNlIGFk ZHJlc3MsIGRlc3RpbmF0aW9uIGFkZHJlc3MsCiAgIHByb3RvY29sIHR5cGUsIGFuZC9vciBvdGhl ciBoZWFkZXIgZmllbGRzIGRlcGVuZGluZyB1cG9uIHRoZSB0eXBlIG9mCiAgIGlkZW50aWZpZXIg dXNlZCBmb3IgRFBELiAgU2ltaWxhcmx5LCAKClVIPiA9PT09PT09PT09PT09PT09ClVIPiAiU2lt aWxhcmx5IiB0byB3aGF0PwpVSD4gPT09PT09PT09PT09PT09PQpKTT4gU2VudGVuY2VzIHdlcmUg c3dhcHBlZC4gVGhpcyBjYW1lIGJlZm9yZSB0aGUgc2VudGVuY2UgcmVnYXJkaW5nIEktRFBEIHN0 YXRlLgpKTT4gU2ltaWxhcmx5IGlzIG5vdCBxdWl0ZSByaWdodC4gQ2hhbmdlZCB0aGlzIHRvIGp1 c3Qgc3RhdGUgdGhlIHJlY29tbWVuZGF0aW9uIGZvciBILURQRAogICAKICAgZm9yIEgtRFBELCAK VUg+ID09PT09PT09PT09PT09PT0KVUg+IEgtRFBEIGhhcyBub3QgYmVlbiBpbnRyb2R1Y2VkIG5v ciBkZWZpbmVkIGJlZm9yZQpVSD4gPT09PT09PT09PT09PT09PQpKTT4gTm93IHRoZXJlIGlzIGEg c2hvcnQgZGVmaW5pdGlvbiBwcmVjZWRpbmcuCiAgIAogICBpdCBpcyBleHBlY3RlZCB0aGF0CiAg IHBhY2tldCBoYXNoIHZhbHVlcyB3aWxsIGJlIGtlcHQgd2l0aCByZXNwZWN0IHRvIGF0IGxlYXN0 IHRoZSBzb3VyY2UKICAgYWRkcmVzcyB0byBoZWxwIGVuc3VyZSBoYXNoIGNvbGxpc2lvbiBhdm9p ZGFuY2UuIApVSD4gPT09PT09PT09PT09PT09PQpVSD4gImF0IGxlYXN0Ij8gd2hhdCBlbHNlPwpV SD4gPT09PT09PT09PT09PT09PQpKTT4gZG9uZSBzZWUgZm9yd2FyZCBjb21tZW50CiAgIAogICBT TUYgaW1wbGVtZW50YXRpb25zCiAgIE1VU1QgbWFpbnRhaW4gRFBEIGhpc3RvcnkgcGVyIHRoZSBh cHBsaWNhYmxlIHBhY2tldCBmbG93IGNvbnRleHQKICAgKGUuZy4sIDxwcm90b2NvbDpzcmNBZGRy OmRzdEFkZHI+IApVSD4gPT09PT09PT09PT09PT09PQpVSD4gSGFzIHRoaXMgbm90YXRpb24gYmVl biBkZWZpbmVkIGJlZm9yZT8gPC4uLjouLi46Li4+ClVIPiA9PT09PT09PT09PT09PT09CgogICAK ICAgZm9yIERQRCBiYXNlZCB1cG9uIElQdjQgSUQpLiAgVGhlCiAgIGRldGFpbHMgZm9yIEktRFBE IGFuZCBILURQRCBmb3IgZGlmZmVyZW50IHR5cGVzIG9mIHBhY2tldHMgYXJlCiAgIGRlc2NyaWJl ZCBpbiB0aGUgc2VjdGlvbnMgYmVsb3cuICBJbiBlaXRoZXIgY2FzZSwgdGhpcyBoaXN0b3J5IFNI T1VMRAogICBiZSBrZXB0IGxvbmcgZW5vdWdoIHRvIHNwYW4gdGhlIG1heGltdW0gbmV0d29yayB0 cmF2ZXJzYWwgbGlmZXRpbWUsCiAgIE1BWF9QQUNLRVRfTElGRVRJTUUsIG9mIG11bHRpY2FzdCBw YWNrZXRzIGJlaW5nIGZvcndhcmRlZCB3aXRoaW4gYW4KICAgU01GIG9wZXJhdGluZyBhcmVhLiAK VUg+ID09PT09PT09PT09PT09PT0KVUg+IFdoYXQgaXMgYW4gIlNNRiBvcGVyYXRpbmcgYXJlYSI/ IERlZmluaXRpb24gbmVlZGVkClVIPiA9PT09PT09PT09PT09PT09CkpNPiBkb25lIHNlZSBmb3J3 YXJkIGNvbW1lbnQKICAgCiAgIFRoZSByZXF1aXJlZCBzaXplIG9mIHRoZSBEUEQgY2FjaGUgaXMg Z292ZXJuZWQKICAgYnkgdGhpcyB0aW1lb3V0IHZhbHVlIGFuZCBpcyBhbHNvIGEgZnVuY3Rpb24g b2YgdGhlIHBhY2tldCBmb3J3YXJkaW5nCiAgIHJhdGVzLiAgClVIPiA9PT09PT09PT09PT09PT09 ClVIPiBIb3cgaXMgdGhpcyAiZnVuY3Rpb24gb2YgdGhlIHBhY2tldCBmb3J3YXJkaW5nIHJhdGUi IGRlZmluZWQ/ClVIPiA9PT09PT09PT09PT09PT09CkpNPiBkb25lIHNlZSBmb3J3YXJkIGNvbW1l bnQKICAgCiAgIFRoZSBEUEQgbWVjaGFuaXNtIFNIT1VMRCBhdm9pZCBrZWVwaW5nIHVubmVjZXNz YXJ5IHN0YXRlIGZvcgogICBwYWNrZXQgZmxvd3Mgc3VjaCBhcyB0aG9zZSB0aGF0IGFyZSBsb2Nh bGx5LWdlbmVyYXRlZCBvciBsaW5rLWxvY2FsCiAgIGRlc3RpbmF0aW9ucyB0aGF0IHdvdWxkIG5v dCBiZSBjb25zaWRlcmVkIGZvciBmb3J3YXJkaW5nLgpVSD4gPT09PT09PT09PT09PT09PQpVSD4g VGhpcyB3aG9sZSBzZWN0aW9uIGlzIHRvbyBkZXRhaWxlZCBmb3IgYSBzcGVjaWZpY2F0aW9uIGFu ZCB0b28gdmFndWUgZm9yIGFuIGludHJvZHVjYXRpb24gdG8gSS1EUEQvSC1EUEQuIEEgZ29vZCBv dmVydmlldyBvZiBib3RoIHdvdWxkIGJlIGJldHRlciBpbnN0ZWFkLgpVSD4gPT09PT09PT09PT09 PT09PQpKTT4gVEhpcyB3YXMgeW91ciBpbXBvcnRhbnQgZ2VuZXJhbCBjb21tZW50IEkgbmVlZGVk IHRvIHJld3JpdGUgdGhpcyB3aG9sZSBpbnRybyBzZWN0aW9uIGFzIGl0IHdhcyByZWR1bmRhbnQg d2l0aCBmb2xsb3dpbmcgc2VjdGlvbnMgYW5kIGNhbWUgdG9vIGVhcmx5IHdpdGggdG9vIG11Y2gg ZGV0YWlsIGFuZCB0b28gdmFndWUgaW4gb3RoZXIgcGxhY2VzLiBEb25lLgoKNS4xLiAgSVB2NiBE dXBsaWNhdGUgUGFja2V0IERldGVjdGlvbgoKICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUg bWVjaGFuaXNtcyBhbmQgb3B0aW9ucyBmb3IgU01GIElQdjYgRFBELgogICBUaGUgY29yZSBJUHY2 IHBhY2tldCBoZWFkZXIgZG9lcyBub3QgcHJvdmlkZSBhbnkgZXhwbGljaXQKICAgaWRlbnRpZmlj YXRpb24gaGVhZGVyIGZpZWxkIHRoYXQgY2FuIGJlIGV4cGxvaXRlZCBmb3IgSS1EUEQuICBUaGUK ICAgZm9sbG93aW5nIGFyZWFzIGFyZSBkZXNjcmliZWQgdG8gc3VwcG9ydCBJUHY2IERQRDoKCgoK Ck1hY2tlciwgZWRpdG9yICYgU01GIERlc2lnbiBUZWFtICBFeHBpcmVzIFNlcHRlbWJlciA3LCAy MDEwICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgU01G ICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMAoKCiAgIDEuICBhIGhvcC1ieS1ob3Ag U01GLURQRCBvcHRpb24gaGVhZGVyICh3aXRoIHN1cHBvcnRpbmcgaWRlbnRpZmllciBvcgogICAg ICAgaGFzaCBhc3Npc3RhbmNlIHZhbHVlKSwKICAgMi4gIHRoZSB1c2Ugb2YgSVB2NiBmcmFnbWVu dCBoZWFkZXIgZmllbGRzIGZvciBJLURQRCB3aGVuIHRoZXkgZXhpc3QsCiAgIDMuICB0aGUgdXNl IG9mIElQU2VjIHNlcXVlbmNpbmcgZm9yIEktRFBEIHdoZW4gYSBub24tZnJhZ21lbnRlZCwKICAg ICAgIElQU2VjIGhlYWRlciBpcyBkZXRlY3RlZCwgYW5kCiAgIDQuICBhbiBILURQRCBhcHByb2Fj aCBhc3Npc3RlZCwgYXMgbmVlZGVkLCBieSB0aGUgU01GLURQRCBvcHRpb24KICAgICAgIGhlYWRl ci4KVUg+ID09PT09PT09PT09PT09PT0KVUg+IEl0IHNob3VsZCBiZSBtYWRlIGNsZWFyIHRoYXQg dGhlc2UgNCBwb2ludHMgYXJlIGV4cGxhaW5lZCBpbiB0aGUgZm9sbG93aW5nIHN1YnNlY3Rpb25z IGluIG1vcmUgZGV0YWlsLgpVSD4gVGhlIGxpc3QgbWl4ZXMgdXAgSS1EUEQgYW5kIEgtRFBELiBJ IHdvdWxkIHByZWZlciB0byBoYXZlIHRoYXQgbW9yZSBzZXBlcmF0ZWQuClVIPiA9PT09PT09PT09 PT09PT09CkpNPiBDbGVhcmVyIG5vdy4KICAgICAgIAoKICAgU01GIE1VU1QgcHJvdmlkZSBhIERQ RCBtYXJraW5nIG1vZHVsZSB0aGF0IGNhbiBpbnNlcnQgdGhlIGhvcC1ieS1ob3AKICAgSVB2NiBo ZWFkZXIgb3B0aW9uIGRlZmluZWQgaW4gdGhpcyBzZWN0aW9uLiAgCgpVSD4gPT09PT09PT09PT09 PT09PQpVSD4gQXQgd2hhdCBwb2ludCBvZiB0aW1lIGlzIHRoYXQgZG9uZT8gKHNlZSBwcmV2aW91 cyBvcmRlcmVkIGxpc3Qgb2YgYWN0aW9ucyB3aGVuIGEgbWVzc2FnZSBpcyBjb25zaWRlcmVkIGZv ciBmb3J3YXJkaW5nIGluIHNlY3Rpb24gNCkKVUg+ID09PT09PT09PT09PT09PT0KSk0+IE1heSBi ZSBjb25mdXNlZCBieSBob3AtYnktaG9wIG9wdGlvbi4gSXQgaXMgbm90IGFwcGxpZWQgaW4gbm9y bWFsIGZvcndhcmRpbmcgcHJvY2VzcyBzbyBub3QgdGhhdCBzYW1lIHByZXZpb3VzIHN0ZXBzLiBP bmx5IGF0IHNvdXJjZS9pbmdyZXNzIGdhdGV3YXkgYW5kIHRoaXMgaXMgY29uZmlndXJlZC4KICAg CiAgIFRoaXMgcHJvY2VzcyBNVVNUIGNvbWUKICAgYWZ0ZXIgYW55IHNvdXJjZS1iYXNlZCBmcmFn bWVudGF0aW9uIHRoYXQgbWF5IG9jY3VyIHdpdGggSVB2Ni4gIEFzCiAgIHdpdGggSVB2NCwgU01G IElQdjYgRFBEIGlzIHByZXNlbnRseSBzcGVjaWZpZWQgdG8gYWxsb3cgZWl0aGVyIGEKICAgcGFj a2V0IGhhc2ggb3IgaGVhZGVyIGlkZW50aWZpY2F0aW9uIG1ldGhvZCBmb3IgRFBELiAgQW4gU01G CiAgIGltcGxlbWVudGF0aW9uIE1VU1QgYmUgY29uZmlndXJlZCB0byBvcGVyYXRlIGVpdGhlciBp biBILURQRCBvciBJLURQRAogICBtb2RlIGFuZCBwZXJmb3JtIHRoZSBhcHByb3ByaWF0ZSByb3V0 aW5lcyBvdXRsaW5lZCBpbiB0aGUgZm9sbG93aW5nCiAgIHNlY3Rpb25zLgoKNS4xLjEuICBJUHY2 IFNNRi1EUEQgSGVhZGVyIE9wdGlvbgoKICAgQXMgcHJldmlvdXNseSBtZW50aW9uZWQKVUg+ID09 PT09PT09PT09PT09PT0KVUg+IHdoZXJlPyB3aGljaCBzZWN0aW9uPwpVSD4gPT09PT09PT09PT09 PT09PQpKTT4gUmVtb3ZlZAoKICAgCiAgICwgdGhlIGJhc2UgSVB2NiBwYWNrZXQgaGVhZGVyIGRv ZXMgbm90IGNvbnRhaW4KICAgYSB1bmlxdWUgaWRlbnRpZmllciBzdWl0YWJsZSBmb3IgRFBELiAg VGhpcyBzZWN0aW9uIGRlZmluZXMgYW4gSVB2NgogICBIb3AtYnktSG9wIE9wdGlvbiAKVUg+ID09 PT09PT09PT09PT09PT0KVUg+IGNpdGF0aW9uIG9mIElQdjYgSG9wLWJ5LUhvcCBPcHRpb24gc3Bl Yy4KVUg+ID09PT09PT09PT09PT09PT0KSk0+ZG9uZQoKICAgdG8gc2VydmUgdGhpcyBwdXJwb3Nl IGZvciBJUHY2IEktRFBELgogICBBZGRpdGlvbmFsbHksIHRoZSBoZWFkZXIgb3B0aW9uIHByb3Zp ZGVzIGEgbWVjaGFuaXNtIHRvIGd1YXJhbnRlZQogICBub24tY29sbGlzaW9uIG9mIGhhc2ggdmFs dWVzIGZvciBkaWZmZXJlbnQgcGFja2V0cyB3aGVuIEgtRFBEIGlzCiAgIHVzZWQuICBUaGUgdmFs dWUgb2YgdGhlIElQdjYgU01GIERQRCBIb3AtYnktSG9wIE9wdGlvbiBUeXBlIGlzIFRCRC4KVUg+ ID09PT09PT09PT09PT09PT0KVUg+IE1vdmUgdGhhdCB0byB0aGUgSUFOQSBDb25zaWRlcmF0aW9u cyBzZWN0aW9uIGF0IHRoZSBlbmQgb2YgdGhlIHNwZWMuClVIPiA9PT09PT09PT09PT09PT09CkpN PmRvbmUuCiAgIAoKICAgVGhlIGZpcnN0IGJpdCBvZiB0aGUgZGF0YSBmaWVsZCBvZiB0aGUgU01G LURQRCBvcHRpb24gaXMgdGhlICJILWJpdCIKICAgdGhhdCBkZXRlcm1pbmVzIHRoZSBmb3JtYXQg b2YgdGhlIE9wdGlvbiBEYXRhIGNvbnRlbnQuICBUd28gZGlmZmVyZW50CiAgIGZvcm1hdHMgYXJl IHN1cHBvcnRlZC4gIFdoZW4gdGhlICJILWJpdCIgaXMgY2xlYXJlZCAoemVybyB2YWx1ZSksIHRo ZQogICBTTUYtRFBEIGZvcm1hdCB0byBzdXBwb3J0IEktRFBEIG9wZXJhdGlvbiBpcyBzcGVjaWZp ZWQgYXMgc2hvd24gaW4KICAgRmlndXJlIDIgYW5kIGRlZmluZXMgdGhlIGV4dGVuc2lvbiBoZWFk ZXIgaW4gYWNjb3JkYW5jZSB3aXRoCiAgIFtSRkMyNDYwXS4KVUg+ID09PT09PT09PT09PT09PT0K VUg+IElzIHRoYXQgZmxleGlibGUgZW5vdWdoLCBqdXN0IHR3byBvcHRpb25zIGZvciBILURQRCBh bmQgSS1EUEQ/IE1heWJlIHRoZXJlIHdpbGwgYmUgYSBmdXR1cmUgeC1EUEQgd2hpY2ggY2Fubm90 IGJlIHVzZWQgdGhlbi4KVUg+ID09PT09PT09PT09PT09PT0KSk0+IFRpZFR5cCBwcm92aWRlcyBz b21lIGZsZXhpYmlsaXR5LCBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIG11Y2ggdmFyaWF0aW9uIHJl cXVpcmVzIGZvciB0aGUgSEFWLiBTbyB3aGlsZSBpdHMgbmFtZWQgZm9yIFRhZ2dlcklEIG5vdyB3 ZSBoYXZlIGEgcmVzZXJ2ZWQgb3B0aW9ucyBsZWZ0LgoKICAgCiAgICAgICAgMCAgICAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgICAgICAgICAgICAgICAgIC4uLiAgICAgICAg ICAgICAgfDB8MHwwfCBPcHRUeXBlIHwgT3B0LiBEYXRhIExlbiB8ClVIPiA9PT09PT09PT09PT09 PT09ClVIPiBJIHdvdWxkIG9ubHkgcHJpbnQgdGhlIGJ5dGVzIGNvbnRhaW5lZCBpbiB0aGUgaGVh ZGVyIG9wdGlvbi4uIGUuZy4sIHRoZSBmaXJzdCAxNiBiaXRzIGNvdWxkIGJlIG9taXR0ZWQKVUg+ ID09PT09PT09PT09PT09PT0KICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsK ICAgICAgIHwwfFRpZFR5cHxUaWRMZW58ICAgICAgICAgICAgIFRhZ2dlcklkIChvcHRpb25hbCkg Li4uICAgICAgICAgICB8CiAgICAgICArLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgSWRlbnRpZmllciAgLi4uCiAgICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwoKICAgICAgICAgICAgRmlndXJlIDI6IElQdjYgU01GLURQRCBIZWFkZXIgT3B0aW9uIGluIEkt RFBEIG1vZGUKVUg+ID09PT09PT09PT09PT09PT0KVUg+IFRoaXMgc2VjdGlvbiB0YWxrcyBhYm91 dCB0aGUgZ2VuZXJhbCBoZWFkZXIgb3B0aW9uIGZvciBib3RoIEktRFBEIGFuZCBILURQRC4gU28g SSB3b3VsZCBub3QgcHV0IGFuIGV4YW1wbGUgZm9yIEktRFBEIGhlcmUsIGJ1dCByYXRoZXIgaW4g dGhlIG5leHQgc3Vic2VjdGlvbi4gSGVyZSBzaG91bGQgYmUgYSBnZW5lcmFsIGhlYWRlciBvcHRp b24gd2l0aCB0aGUgSC1iaXQgY2xlYXJseSB2aXNpYmxlClVIPiA9PT09PT09PT09PT09PT09CkpN PiBZZXMsIG1hbnkgcmV2aXNpb25zIGFnbyB0aGVyZSB3YXMgYSBnZW5lcmljIGhlYWRlciBkaWFn cmFtIGFuZCBpdCBnb3QgcmVtb3ZlZCBiYXNlIHVwb24gc29tZSBjb21tZW50LiBJIGFtIGdvaW5n IHRvIHB1dCBpdCBiYWNrIGluLgoKICAgVGhlICJUaWRUeXBlIiBpcyBhIDMtYml0IGZpZWxkIGlu ZGljYXRpbmcgdGhlIHByZXNlbmNlIGFuZCB0eXBlIG9mCiAgIHRoZSBvcHRpb25hbCAiVGFnZ2Vy SWQiIGZpZWxkLiAgVGhlIG9wdGlvbmFsICJUYWdnZXJJZCIgaXMgdXNlZCB0bwogICBkaWZmZXJl bnRpYXRlIG11bHRpcGxlIGluZ3Jlc3NpbmcgYm9yZGVyIGdhdGV3YXlzIHRoYXQgbWF5IGNvbW1v bmx5CiAgIGFwcGx5IHRoZSBTTUYtRFBEIG9wdGlvbiBoZWFkZXIgdG8gcGFja2V0cyBmcm9tIGEg cGFydGljdWxhciBzb3VyY2UuCgrJLgogICBXaGVuIHRoZSAiSC1iaXQiIGluIHRoZSBTTUYtRFBE IG9wdGlvbiBkYXRhIGlzIHNldCwgdGhlIGRhdGEgY29udGVudAogICB2YWx1ZSBpcyBpbnRlcnBy ZXRlZCBhcyBhIEhhc2gtQXNzaXN0IFZhbHVlIChIQVYpIHVzZWQgdG8gZmFjaWxpdGF0ZQogICBI LURQRCBvcGVyYXRpb24uICBJbiB0aGlzIGNhc2UsIHNvdXJjZSBob3N0cyBvciBpbmdyZXNzaW5n IGdhdGV3YXlzCiAgIGFwcGx5IHRoZSBTTUYtRFBEIHdpdGggYSBIQVYgb25seSB3aGVuIHJlcXVp cmVkIHRvIGRpZmZlcmVudGlhdGUgdGhlCiAgIGhhc2ggdmFsdWUgb2YgYSBuZXcgcGFja2V0IHdp dGggcmVzcGVjdCB0byBvbGRlciBwYWNrZXRzIGluIHRoZQogICBjdXJyZW50IERQRCBoaXN0b3J5 IGNhY2hlLiAKVUg+ID09PT09PT09PT09PT09PT0KVUg+IERlZmluZSB3aGF0IGlzIGFuICJvbGQi IHBhY2tldCBhbmQgd2hhdCBpcyBhICJuZXciIHBhY2tldC4gSXMgdGhlIGhpc3RvcnkgY2FjaGUg ZGF0YSBzdHJ1Y3R1cmUgc29tZXdoZXJlIGRlZmluZWQ/ClVIPiA9PT09PT09PT09PT09PT09CkpN PiBuZWVkIHRvIGV4cGxhaW4gbG9jYWwgZGV0ZWN0aW9uIG9mIGhhc2ggY29sbGlzaW9uLGV0Yy4g YWRkZWQuIG9sZCwgbmV3IHdhcyB2YWd1ZS4KICAgCiAgIFRoaXMgaGVscHMgdG8gZ3VhcmFudGVl IHRoZSB1bmlxdWVuZXNzIG9mCiAgIGdlbmVyYXRlZCBoYXNoIHZhbHVlcyB3aGVuIEgtRFBEIGlz IHVzZWQuICBBZGRpdGlvbmFsbHksIHRoaXMgYWxzbwogICBhdm9pZHMgdGhlIGFkZGVkIG92ZXJo ZWFkIG9mIGFwcGx5aW5nIHRoZSBTTUYtRFBEIG9wdGlvbiBoZWFkZXIgdG8KICAgZXZlcnkgcGFj a2V0LiAgRm9yIG1hbnkgaGFzaCBhbGdvcml0aG1zLCBpdCBpcyBleHBlY3RlZCB0aGF0IG9ubHkK ICAgc3BhcnNlIHVzZSBvZiB0aGUgU01GLURQRCBvcHRpb24gbWF5IGJlIHJlcXVpcmVkLiAgVGhl IGZvcm1hdCBvZiB0aGUKICAgU01GLURQRCBoZWFkZXIgb3B0aW9uIGZvciBILURQRCBvcGVyYXRp b24gaXMgZ2l2ZW4gaW4gRmlndXJlIDMuCgoKCgoKCk1hY2tlciwgZWRpdG9yICYgU01GIERlc2ln biBUZWFtICBFeHBpcmVzIFNlcHRlbWJlciA3LCAyMDEwICAgIFtQYWdlIDEzXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgU01GICAgICAgICAgICAgICAgICAgICAgICAgTWFy Y2ggMjAxMAoKCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAg MiAgICAgICAgICAgICAgICAgICAzCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAg ICAgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICB8MHwwfDB8IE9wdFR5cGUgfCBPcHQuIERh dGEgTGVuIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfDB8ICAgIEhhc2ggQXNzaXN0IFZhbHVlIChI QVYpIC4uLgpVSD4gPT09PT09PT09PT09PT09PQpVSD4gU2hvdWxkIHRoZSBmaXJzdCBiaXQgaW4g dGhlIHNlY29uZCBsaW5lIChILWJpdCkgYmUgMSwgaW5zdGVhZCBvZiAwPwpVSD4gPT09PT09PT09 PT09PT09PQpKTT4gWWVzLCB3b3cgbWlzc2VkIHRoYXQuCiAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICAgICAg ICAgICBGaWd1cmUgMzogSVB2NiBTTUZfRFBEIEhlYWRlciBPcHRpb24gaW4gSC1EUEQgTW9kZQpV SD4gPT09PT09PT09PT09PT09PQpVSD4gVGhlIEktRCBtaXhlcyB1cCBTTUYtRFBELCBTTUZfRFBE LCBTTUYgRFBELiBTaG91bGQgYmUgY29uc2lzdGVudApVSD4gPT09PT09PT09PT09PT09PQpKTT4g RGVjaWRlZCBvbiBTTUYtRFBEIGFkZGVkIHRvIGRlZmluaXRpb24gdGFibGUgYWxzby4KCiAgIFRo ZSBTTUYtRFBEIG9wdGlvbiBzaG91bGQgYmUgYXBwbGllZCB3aXRoIGEgSEFWIHRvIHByb2R1Y2Ug YSB1bmlxdWUKICAgaGFzaCBkaWdlc3QgZm9yIHBhY2tldHMgd2l0aGluIHRoZSBjb250ZXh0IG9m IHRoZSBJUHY2IHBhY2tldCBoZWFkZXIKICAgPHNyY0FkZHI+LiAgVGhlIHNpemUgb2YgdGhlIEhB ViBmaWVsZCBpcyBpbXBsaWVkIGJ5IHRoZSAiT3B0LiBEYXRhCiAgIExlbiIuICBUaGUgYXBwcm9w cmlhdGUgc2l6ZSBvZiB0aGUgZmllbGQgZGVwZW5kcyB1cG9uIHRoZSBjb2xsaXNpb24KICAgcHJv cGVydGllcyBvZiB0aGUgc3BlY2lmaWMgaGFzaCBhbGdvcml0aG0gdXNlZC4gIE1vcmUgZGV0YWls cyBvbiBJUHY2CiAgIEgtRFBEIG9wZXJhdGlvbiBhcmUgcHJvdmlkZWQgaW4gU2VjdGlvbiA1LjEu My4KCjUuMS4yLiAgSVB2NiBJZGVudGlmaWNhdGlvbi1iYXNlZCBEUEQKCiAgIFRoZSBmb2xsb3dp bmcgdGFibGUgc3VtbWFyaXplcyB0aGUgSVB2NiBJLURQRCBwcm9jZXNzaW5nIGFwcHJvYWNoLgog ICBXaXRoaW4gdGhlIHRhYmxlICcqJyBpbmRpY2F0ZXMgYSBkb24ndCBjYXJlIGNvbmRpdGlvbi4K VUg+ID09PT09PT09PT09PT09PT0KVUg+IERlZmluZSB3aGF0IGEgImRvbid0IGNhcmUgY29uZGl0 aW9uIiBpcy4gTWF5YmUgdXNlIG1vcmUgc2NpZW50aWZpYyB0ZXJtcy4KVUg+ID09PT09PT09PT09 PT09PT0KSk0+IGNoYW5nZWQgdG8gaWdub3JlCgogICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCBJUHY2ICAg ICAgICB8IElQdjYgICAgICB8IElQdjYgICAgICB8IFNNRiBJUHY2IEktRFBEIE1vZGUgQWN0aW9u ICB8CiAgIHwgRnJhZ21lbnQgICAgfCBJUFNlYyAgICAgfCBJLURQRCAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICB8IEhlYWRlciAgICAgIHwgSGVhZGVyICAgIHwgSGVhZGVy ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwg UHJlc2VudCAgICAgfCAqICAgICAgICAgfCAqICAgICAgICAgfCBVc2UgRnJhZ21lbnQgSGVhZGVy IEktRFBEICAgfAogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwgQ2hl Y2sgYW5kIFByb2Nlc3MgZm9yICAgICAgIHwKICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgICB8IEZvcndhcmRpbmcgICAgICAgICAgICAgICAgICB8CiAgIHwgTm90IFByZXNl bnQgfCBQcmVzZW50ICAgfCAqICAgICAgICAgfCBVc2UgSVBTZWMgSGVhZGVyIEktRFBEICAgICAg fAogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwgQ2hlY2sgYW5kIFBy b2Nlc3MgZm9yICAgICAgIHwKICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAg ICB8IEZvcndhcmRpbmcgICAgICAgICAgICAgICAgICB8CiAgIHwgUHJlc2VudCAgICAgfCAqICAg ICAgICAgfCBQcmVzZW50ICAgfCBJbnZhbGlkLCBkbyBub3QgRm9yd2FyZCAgICAgfAogICB8IE5v dCBQcmVzZW50IHwgUHJlc2VudCAgIHwgUHJlc2VudCAgIHwgSW52YWxpZCwgZG8gbm90IEZvcndh cmQgICAgIHwKICAgfCBOb3QgUHJlc2VudCB8IE5vdCAgICAgICB8IE5vdCAgICAgICB8IEFkZCBJ LURQRCBIZWFkZXIsYW5kICAgICAgICB8CiAgIHwgICAgICAgICAgICAgfCBQcmVzZW50ICAgfCBQ cmVzZW50ICAgfCBQcm9jZXNzIGZvciBGb3J3YXJkaW5nICAgICAgfAogICB8IE5vdCBQcmVzZW50 IHwgTm90ICAgICAgIHwgUHJlc2VudCAgIHwgVXNlIEktRFBEIEhlYWRlciBDaGVjayBhbmQgIHwK ICAgfCAgICAgICAgICAgICB8IFByZXNlbnQgICB8ICAgICAgICAgICB8IFByb2Nlc3MgZm9yIEZv cndhcmRpbmcgICAgICB8CiAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpVSD4gPT09PT09PT09PT09PT09PQpVSD4g SXMgdGhlIHRhYmxlIGV4cGxhaW5lZCBhbnl3aGVyZT8gVGhlIGNvbHVtbiBoZWFkZXJzIHNob3Vs ZCBiZSBleHBsYWluZWQuIEkgd291bGQgYWRkIGEgaG9yaXpvbnRhbCBsaW5lIGFmdGVyIGVhY2gg cm93IHRvIG1ha2UgaXQgbW9yZSByZWFkYWJsZS4KVUg+ID09PT09PT09PT09PT09PT0KCiAgICAg ICAgICAgICAgICAgICBUYWJsZSAyOiBJUHY2IEktRFBEIFByb2Nlc3NpbmcgUnVsZXMKCiAgIElm IHRoZSBJUHY2IG11bHRpY2FzdCBwYWNrZXQgaXMgYW4gSVB2NiBmcmFnbWVudCwgU01GIE1VU1Qg dXNlIHRoZQogICBmcmFnbWVudCBleHRlbnNpb24gaGVhZGVyIGZpZWxkcyBmb3IgcGFja2V0IGlk ZW50aWZpY2F0aW9uLiAgVGhpcwogICBpZGVudGlmaWVyIGNhbiBiZSBjb25zaWRlcmVkIHVuaXF1 ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgPHNyY0FkZHI6CiAgIGRzdEFkZHI+IG9mIHRoZSBJUCBw YWNrZXQuICBJZiB0aGUgcGFja2V0IGlzIGFuIHVuZnJhZ21lbnRlZCBJUHY2CiAgIElQU2VjIHBh Y2tldCwgU01GIE1VU1QgdXNlIElQU2VjIGZpZWxkcyBmb3IgcGFja2V0IGlkZW50aWZpY2F0aW9u LgoKCgpNYWNrZXIsIGVkaXRvciAmIFNNRiBEZXNpZ24gVGVhbSAgRXhwaXJlcyBTZXB0ZW1iZXIg NywgMjAxMCAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg IFNNRiAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTAKCgogICBUaGUgSVBTZWMgaGVh ZGVyIDxzZXF1ZW5jZT4gZmllbGQgClVIPiA9PT09PT09PT09PT09PT09ClVIPiBjaXRlIHdoZXJl IHRoYXQgaXMgc3BlY2lmaWVkClVIPiA9PT09PT09PT09PT09PT09CkpNPiBkb25lCiAgIGNhbiBi ZSBjb25zaWRlcmVkIGEgdW5pcXVlCiAgIGlkZW50aWZpZXIgaW4gdGhlIGNvbnRleHQgb2YgdGhl IDxJUFNlY1R5cGU6c3JjQWRkcjpkc3RBZGRyOlNQST4KVUg+ID09PT09PT09PT09PT09PT0KVUg+ IFdoZXJlIGlzIFNQSSBkZWZpbmVkPyBDaXRlLgpVSD4gPT09PT09PT09PT09PT09PQpKTT4gZG9u ZQoKICAgd2hlcmUgdGhlICJJUFNlY1R5cGUiIGlzIGVpdGhlciBBSCBvciBFU1AuICBGb3IgdW5m cmFnbWVudGVkLCBub24tCiAgIElQU2VjLCBJUHY2IHBhY2tldHMsIHRoZSB1c2Ugb2YgdGhlIFNN RiBEUEQgaGVhZGVyIG9wdGlvbiBpcwogICBuZWNlc3NhcnkgdG8gc3VwcG9ydCBJLURQRCBvcGVy YXRpb24uICBUaGUgU01GIERQRCBoZWFkZXIgb3B0aW9uIGlzCiAgIGFwcGxpZWQgaW4gdGhlIGNv bnRleHQgb2YgdGhlIDxzcmNBZGRyPiBvZiB0aGUgSVAgcGFja2V0LiAgRW5kCiAgIHN5c3RlbXMg b3IgaW5ncmVzc2luZyBTTUYgZ2F0ZXdheXMgYXJlIHJlc3BvbnNpYmxlIGZvciBhcHBseWluZyB0 aGlzCiAgIG9wdGlvbiB0byBzdXBwb3J0IERQRC4gIFRoZSBmb2xsb3dpbmcgdGFibGUgc3VtbWFy aXplcyB0aGVzZSBwYWNrZXQKICAgaWRlbnRpZmljYXRpb24gdHlwZXM6CgogICArLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LSsKICAgfCBJUHY2ICAgICAgfCBQYWNrZXQgRFBEIElEIENvbnRleHQgICAgICAgICAgIHwgUGFj a2V0IERQRCBJRCAgICAgICB8CiAgIHwgUGFja2V0ICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfAogICB8IFR5cGUgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0rCiAgIHwgRnJhZ21lbnQgIHwgPHNyY0FkZHI6ZHN0QWRkcj4gICAgICAgICAgICAg ICB8IDxmcmFnbWVudE9mZnNldDppZD4gfAogICB8IElQU2VjICAgICB8IDxJUFNlY1R5cGU6c3Jj QWRkcjpkc3RBZGRyOlNQST4gfCA8c2VxdWVuY2U+ICAgICAgICAgIHwKICAgfCBQYWNrZXQgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8 CiAgIHwgUmVndWxhciAgIHwgPFt0YWdnZXJJZDpdc3JjQWRkcjpkc3RBZGRyPiAgICB8IDxTTUYt RFBEIG9wdGlvbiAgICAgfAogICB8IFBhY2tldCAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCBoZWFkZXIgaWQ+ICAgICAgICAgIHwKVUg+ID09PT09PT09PT09PT09PT0KVUg+ IEkgd29uZGVyIHdoZXRoZXIgZm9yIHJlZ3VsYXIgcGFja2V0cyBpbiBJUHY0LCB0aGUgd2hvbGUg bWVjaGFuaXNtIHdpbGwgd29yayBpZiB2ZXJ5IHNpbWlsYXIgcGFja2V0cyAoZS5nLiBiZWFjb25z KSBhcmUgc2VudCBpbiBhIHZlcnkgc2hvcnQgdGltZSBpbnRlcnZhbC4gQ291bGRuJ3Qgd2UgdXNl IGEgdGltZXN0YW1wIGhlYWRlciBvcHRpb24gb2YgSVB2NCBvciBzb21ldGhpbmc/IEkgZmVhciB0 aGF0IGp1c3QgdXNpbmcgdGhlIHRhZ2dlcklkLCBzcmMgYW5kIGRlc3QgaXMgbm90IGVub3VnaC4g QW5kIHRoaXMgaXMgcHJvYmFibHksIGF0IHRoZSB0aW1lIG9mIHdyaXRpbmcsIHRoZSBtb3N0IHBy ZWRvbWluYW50IHRyYWZmaWMgdHlwZS4KVUg+ID09PT09PT09PT09PT09PT0KSk0+IHRoYXQncyBh biBvcHRpb25hbCBpZGVhIGJ1dCB0aGVyZSBpcyBubyB0YWdnZXJJRCBmb3IgSVB2NC4gV2UgY291 bGQgY29weSB0aGUgaGVhZGVyIG9wdGlvbiBhcHByb2FjaCBmb3IgSVB2Ni4gTWFueSBoYXZlIGFu IGF2ZXJzaW9uIHRvIElQdjQgaGVhZGVyIG9wdGlvbnMuCiAgICstLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgICAg ICAgICAgICBUYWJsZSAzOiBJUHY2IEktRFBEIFBhY2tldCBJZGVudGlmaWNhdGlvbiBUeXBlcwoK ICAgIklQU2VjVHlwZSIgaXMgZWl0aGVyIEF1dGhlbnRpY2F0aW9uIEhlYWRlciAoQUgpIG9yIEVu Y2Fwc3VsYXRpbmcKICAgU2VjdXJpdHkgUGF5bG9hZCAoRVNQKS4KCiAgIFRoZSAidGFnZ2VySWQi IGlzIGFuIG9wdGlvbmFsIGZlYXR1cmUgb2YgdGhlIElQdjYgU01GLURQRCBoZWFkZXIKICAgb3B0 aW9uLgoKNS4xLjMuICBJUHY2IEhhc2gtYmFzZWQgRFBECgogICBBIGRlZmF1bHQgaGFzaC1iYXNl ZCBEUEQgYXBwcm9hY2ggKEgtRFBEKSBmb3IgdXNlIGJ5IFNNRiBpcyBzcGVjaWZpZWQKICAgYXMg Zm9sbG93cy4gIEFuIE1ENSBbUkZDMTMyMV0gaGFzaCBvZiB0aGUgbm9uLW11dGFibGUgaGVhZGVy IGZpZWxkcywKICAgb3B0aW9ucyBmaWVsZHMsIGFuZCBkYXRhIGNvbnRlbnQgb2YgdGhlIElQdjYg bXVsdGljYXN0IHBhY2tldCBpcyB1c2VkCiAgIHRvIHByb2R1Y2UgYSAxMjgtYml0IGRpZ2VzdC4g IApVSD4gPT09PT09PT09PT09PT09PQpVSD4gTWF5YmUgY29uc2lkZXIgdXNpbmcgYSBjb2RlLXBv aW50IGZvciBNRDUuIE1heWJlIGl0IG1ha2VzIHNlbnNlIHRvIGJlIG1vcmUgZmxleGlibGUgaGVy ZS4gTUQ1IGlzIGFscmVhZHkgY29uc2lkZXJlZCBkZXByZWNhdGVkIChJIGtub3csIGl0IG1heSBu b3QgYmUgcmVsZXZhbnQgaGVyZSBiZWNhdXNlIGl0IGlzIG5vdCB1c2VkIGZvciBjcnlwdG9ncmFw aGljYWwgaW50ZWdyaXR5IGNoZWNrcykuIENvdWxkbid0IG9uZSBhbHNvIHVzZSBvdGhlciBjaGVj a3N1bXMgKGUuZy4gdXNlIHRoZSBDUkMgY2hlY2tzdW0gZnJvbSB1cHBlciBsYXllcnMsIGlmIGF2 YWlsYWJsZT8pClVIPiA9PT09PT09PT09PT09PT09CkpNPiBBY3R1YWxseSB0aGF0IGlzIGFuIGlk ZWEgd2UgaGF2ZSBhbHJlYWR5IHJlbGVhc2VkIGluIHRoZSB3b3JraW5nIGNvZGUsIGJ1dCBJIGFt IHZlcnkgY2FyZWZ1bCB0byBNRDUgaXMgbm90IHVzZWQgZm9yIGNyeXB0b2dyYXBoaWMgcmVhc29u cyBhbmQgdG8gdGFsayBhYm91dCB0aGUgcG90ZW50aWFsIGFyZWFzIGZvciBmdXJ0aGVyIGV4cGxv cmF0aW9uIG9mIGxvdyBjb21wbGV4aXR5LCBnb29kIGNvbGxpc2lvbiBwcm9wZXJ0eSBoYXNoIGFs Z29yaXRobXMuIEluIG91ciBwcm90b3R5cGUgY29kZSB3ZSBoYXZlIG9wdGlvbnMgZm9yIENSQywg TUQ1LCBvdGhlciBhcHByb2FjaGVzLiBBcyB5b3Ugc2F5IGl0cyBub3QgbGltaXRpbmcgYnV0IGlz IGhlcmUgYXMgYSBkZWZhdWx0IHRlc3QgY2FzZS4KICAgCiAgIFRoZSBsb3dlciA2NCBiaXRzIApV SD4gPT09PT09PT09PT09PT09PQpVSD4gImxvd2VyIiBpbiB3aGF0IG9yZGVyPyBtb3N0LXNpZ25p ZmljYW50IGJpdCBmaXJzdD8KVUg+ID09PT09PT09PT09PT09PT0KSk0+IG9rIGxlZnRtb3N0IG9y IG1vc3Qtc2lnbmlmaWNhbnQgYml0IGZpcnN0LiBzaW1pbGFyIHRvIGludGVyZmFjZSBpZGVudGlm aWVycyBpbiBSRkMgMzA0MS4KICAgb2YgdGhpcyBkaWdlc3QKICAgKE1ENV82NCkKVUg+ID09PT09 PT09PT09PT09PT0KVUg+IElzIHRoYXQgYSBrbm93biB0ZXJtLCAiTUQ1XzY0Ij8gb3IgaXMgaXQg ZGVmaW5lZCBoZXJlPwpVSD4gPT09PT09PT09PT09PT09PQpKTT4gTm90IHRoYXQgaXRzIG5vdCBh IGJvcnJvd2VkIGRpZSwgYnV0IEkgdGhpbmsgSSBkaWQgdGhhdCBzdHJpbmcgc28gSSB3b3VsZG4n dCBnZXQgY2FycGFsIHR1bm5lbC4gYnV0IEkgYWN0dWFsbHkgbmV2ZXIgcmV1c2VkIGl0LiBEZWxl dGVkLgogICBpcyB1c2VkIGZvciBTTUYgcGFja2V0IGlkZW50aWZpY2F0aW9uLiAgVGhlIGFwcHJv YWNoIGZvcgogICBjYWxjdWxhdGluZyB0aGlzIGhhc2ggdmFsdWUgU0hPVUxEIGZvbGxvdyB0aGUg c2FtZSBndWlkZWxpbmVzCiAgIGRlc2NyaWJlZCBmb3IgY2FsY3VsYXRpbmcgdGhlIEludGVncml0 eSBDaGVjayBWYWx1ZSAoSUNWKSBkZXNjcmliZWQKICAgaW4gW1JGQzQzMDJdIHdpdGggcmVzcGVj dCB0byBub24tbXV0YWJsZSBmaWVsZHMuICBUaGlzIGFwcHJvYWNoCiAgIHNob3VsZCBoYXZlIGEg cmVhc29uYWJseSBsb3cgcHJvYmFiaWxpdHkgb2YgZGlnZXN0IGNvbGxpc2lvbiB3aGVuCiAgIHBh Y2tldCBoZWFkZXJzIGFuZCBjb250ZW50IGFyZSB2YXJ5aW5nLiAgTUQ1IGlzIGJlaW5nIGFwcGxp ZWQgaW4gU01GCiAgIG9ubHkgdG8gcHJvdmlkZSBhIGxvdyBwcm9iYWJpbGl0eSBvZiBjb2xsaXNp b24gYW5kIGlzIG5vdCBiZWluZyB1c2VkCiAgIGZvciBjcnlwdG9ncmFwaGljIG9yIGF1dGhlbnRp Y2F0aW9uIHB1cnBvc2VzLiAgQSBoaXN0b3J5IG9mIHRoZQogICBwYWNrZXQgaGFzaCB2YWx1ZXMg U0hPVUxEIGJlIG1haW50YWluZWQgd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZQogICBJUHY2IHBh Y2tldCBoZWFkZXIgPHNyY0FkZHI+ClVIPiA9PT09PT09PT09PT09PT09ClVIPiAicGFja2V0IGhl YWRlciIgKyBmaWVsZCArICI8c3JjQWRkcj4iClVIPiA9PT09PT09PT09PT09PT09CkpNPiBubyBJ IGRvbid0IGtub3cgd2hhdCB0aGlzIG1lYW5zLiBObyB0aGF0cyBub3Qgd2hhdHMgbWVhbnQgYnkg dGhlIGFib3ZlLgoKICAgLiAgVGhpcyBoaXN0b3J5IGlzIHVzZWQgYnkgZm9yd2FyZGluZyBTTUYK ICAgbm9kZXMgKG5vbi1pbmdyZXNzIHBvaW50cykgClVIPiA9PT09PT09PT09PT09PT09ClVIPiBo YXMgIm5vbi1pbmdyZXNzIHBvaW50IiBiZSBkZWZpbmVkIGJlZm9yZT8KVUg+ID09PT09PT09PT09 PT09PT0KSk0+IGNvbmZ1c2luZyByZW1vdmVkLgogICAKICAgdG8gYXZvaWQgZm9yd2FyZGluZyBk dXBsaWNhdGVzLiAgU01GCiAgIGluZ3Jlc3MgcG9pbnRzIChpLmUuLCBzb3VyY2UgaG9zdHMgb3Ig Z2F0ZXdheXMpIHVzZSB0aGlzIGhpc3RvcnkgdG8KCgoKTWFja2VyLCBlZGl0b3IgJiBTTUYgRGVz aWduIFRlYW0gIEV4cGlyZXMgU2VwdGVtYmVyIDcsIDIwMTAgICAgW1BhZ2UgMTVdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICBTTUYgICAgICAgICAgICAgICAgICAgICAgICBN YXJjaCAyMDEwCgoKICAgY29uZmlybSB0aGF0IG5ldyBwYWNrZXRzIGFyZSB1bmlxdWUgd2l0aCBy ZXNwZWN0IHRvIHRoZWlyIGhhc2ggdmFsdWUuCiAgIFRoZSBIYXNoLWFzc2lzdCBWYWx1ZSAoSEFW KSBmaWVsZCBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjEuMSBpcwogICBwcm92aWRlZCBhcyBhIGRp ZmZlcmVudGlhdGluZyBmaWVsZCB3aGVuIGEgZGlnZXN0IGNvbGxpc2lvbiB3b3VsZAogICBvdGhl cndpc2Ugb2NjdXIuICBOb3RlIHRoYXQgdGhlIEhBViBpcyBhbiBpbW11dGFibGUgb3B0aW9uIGZp ZWxkIGFuZAogICBTTUYgTVVTVCB1c2UgYW55IGluY2x1ZGVkIEgtRFBEIGhhc2ggYXNzaXN0IHZh bHVlIChIQVYpIG9wdGlvbiBoZWFkZXIKICAgKHNlZSBTZWN0aW9uIDUuMS4xKSBpbiBpdHMgaGFz aCBjYWxjdWxhdGlvbi4KCiAgIElmIGEgcGFja2V0IHJlc3VsdHMgaW4gYSBkaWdlc3QgY29sbGlz aW9uIChpLmUuLCBieSBjaGVja2luZyB0aGUKICAgSC1EUEQgZGlnZXN0IGhpc3RvcnkpIHdpdGhp biB0aGUgbGltaXRlZCBoaXN0b3J5IGtlcHQgClVIPiA9PT09PT09PT09PT09PT09ClVIPiB0aGUg ImxpbWl0ZWQgaGlzdG9yeSIgaXMgbm90IGRlZmluZWQgYmVmb3JlLiBJdCdzIHVuY2xlYXIgaG93 IGxvbmcgdG8ga2VlcCBlbnRyaWVzLiBJdCB3YXNuJ3QgZXZlbiBtZW50aW9uZWQgYmVmb3JlIHRo YXQgZW50cmllcyBhcmUgcHVyZ2VkIGFmdGVyIGEgcHJlZGVmaW5lZCB0aW1lLgpVSD4gPT09PT09 PT09PT09PT09PQpKTT4gdmFndWUsIGp1c3Qgc2FpZCBEUEQgY2FjaGUuCiAgIAogICBieSBTTUYK ICAgZm9yd2FyZGVycywgdGhlIHBhY2tldCBzaG91bGQgYmUgc2lsZW50bHkgZHJvcHBlZC4gIElm IGEgZGlnZXN0CiAgIGNvbGxpc2lvbiBpcyBkZXRlY3RlZCBhdCBhbiBTTUYgaW5ncmVzcyBwb2lu dCAoaS5lLiwgaW5jbHVkaW5nIFNNRi0KICAgYXdhcmUgc291cmNlcykKVUg+ID09PT09PT09PT09 PT09PT0KVUg+IFdoYXQgaXMgYW4gIlNNRi1hd2FyZSBzb3VyY2UiPyBIb3cgd291bGQgaXQga25v dz8KVUg+ID09PT09PT09PT09PT09PT0KSk0+IFJlbW92ZWQuCgogICAsIHRoZSBILURQRCBvcHRp b24gaGVhZGVyIGlzIGFwcGxpZWQgd2l0aCBhIEhBVi4gIFRoZQogICBwYWNrZXQgaXMgcmV0ZXN0 ZWQgZm9yIGNvbGxpc2lvbiBhbmQgdGhlIEhBViBpcyByZS1hcHBsaWVkIGFzIG5lZWRlZApVSD4g PT09PT09PT09PT09PT09PQpVSD4gV2hhdCBkb2VzICJyZS1hcHBsaWVkIGFzIG5lZWRlZCIgbWVh bj8KVUg+ID09PT09PT09PT09PT09PT0KSk0+IENsYXJpZmllZCBwcm9jZXNzaW5nL2NhbGN1bGF0 aW9uIHJlcXVpcmVtZW50cwogICAKICAgdG8gcHJvZHVjZSBhIG5vbi1jb2xsaWRpbmcgaGFzaCB2 YWx1ZS4gIFRoZSBtdWx0aWNhc3QgcGFja2V0IGlzIHRoZW4KICAgZm9yd2FyZGVkIHdpdGggdGhl IGFkZGVkIElQdjYgU01GLURQRCBoZWFkZXIgb3B0aW9uLgoKICAgVGhlIE1ENSBpbmRleGluZyBh bmQgSVB2NiBIQVYgYXBwcm9hY2hlcyBhcmUgc3BlY2lmaWVkIGF0IHByZXNlbnQgZm9yCiAgIGNv bnNpc3RlbmN5IGFuZCByb2J1c3RuZXNzIHRvIHN1aXQgZXhwZXJpbWVudGFsIHVzZXMuICBGdXR1 cmUKICAgYXBwcm9hY2hlcyBhbmQgZXhwZXJpbWVudGF0aW9uIG1heSBkaXNjb3ZlciBkZXNpZ25z IHRyYWRlb2ZmcyBpbiBoYXNoCiAgIHJvYnVzdG5lc3MgYW5kIGVmZmljaWVuY3kgd29ydGggY29u c2lkZXJpbmcuICBUaGlzIE1BWSBpbmNsdWRlCiAgIHJlZHVjaW5nIHRoZSBtYXhpbXVtIHBheWxv YWQgbGVuZ3RoIHRoYXQgaXMgcHJvY2Vzc2VkLCBkZXRlcm1pbmluZwogICBzaG9ydGVyIGluZGV4 ZXMsIG9yIGFwcGx5aW5nIG1vcmUgZWZmaWNpZW50IGhhc2hpbmcgYWxnb3JpdGhtcy4gIFVzZQog ICBvZiB0aGUgSEFWIGZ1bmN0aW9uYWxpdHkgbWF5IGFsbG93IGZvciBhcHBsaWNhdGlvbiBvZiAi bGlnaHRlci0KICAgd2VpZ2h0IiBoYXNoaW5nIHRlY2huaXF1ZXMgdGhhdCBtaWdodCBub3QgaGF2 ZSBiZWVuIGluaXRpYWxseQogICBjb25zaWRlcmVkIGR1ZSB0byBwb29yIGNvbGxpc2lvbiBwcm9w ZXJ0aWVzIG90aGVyd2lzZS4gIFN1Y2gKICAgdGVjaG5pcXVlcyBjb3VsZCByZWR1Y2UgcGFja2V0 IHByb2Nlc3Npbmcgb3ZlcmhlYWQgYW5kIG1lbW9yeQogICByZXF1aXJlbWVudHMuCgo1LjIuICBJ UHY0IER1cGxpY2F0ZSBQYWNrZXQgRGV0ZWN0aW9uCgogICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVz IHRoZSBtZWNoYW5pc21zIGFuZCBvcHRpb25zIGZvciBJUHY0IERQRC4gIFRoZQogICBJUHY0IHBh Y2tldCBoZWFkZXIgMTYtYml0ICJJZGVudGlmaWNhdGlvbiIgZmllbGQgTUFZIGJlIHVzZWQgZm9y IERQRAogICBhc3Npc3RhbmNlLCBidXQgcHJhY3RpY2FsIGxpbWl0YXRpb25zIG1heSByZXF1aXJl IGFsdGVybmF0aXZlCiAgIGFwcHJvYWNoZXMgaW4gc29tZSBzaXR1YXRpb25zLiAgVGhlIGZvbGxv d2luZyBhcmVhcyBhcmUgZGVzY3JpYmVkIHRvCiAgIHN1cHBvcnQgSVB2NCBEUEQ6OgogICAKICAg MS4gIHRoZSB1c2Ugb2YgSVB2NCBmcmFnbWVudCBoZWFkZXIgZmllbGRzIGZvciBJLURQRCB3aGVu IHRoZXkgZXhpc3QsCiAgIDIuICB0aGUgdXNlIG9mIElQU2VjIHNlcXVlbmNpbmcgZm9yIEktRFBE IHdoZW4gYSBub24tZnJhZ21lbnRlZCBJUHY0CiAgICAgICBJUFNlYyBwYWNrZXQgaXMgZGV0ZWN0 ZWQsIGFuZAogICAzLiAgYSBILURQRCBhcHByb2FjaC4KICAgQSBzcGVjaWZpYyBTTUYtRFBEIG1h cmtpbmcgb3B0aW9uIGlzIG5vdCBzcGVjaWZpZWQgZm9yIElQdjQgc2luY2UKICAgaGVhZGVyIG9w dGlvbnMgYXJlIG5vdCBhcyB0cmFjdGFibGUgZm9yIGVuZCBzeXN0ZW1zIGFzIGZvciBJUHY2Lgog ICBJUHY0IHBhY2tldHMgZnJvbSBhIHBhcnRpY3VsYXIgc291cmNlIGFyZSBhc3N1bWVkIHRvIGJl IG1hcmtlZCB3aXRoIGEKICAgdGVtcG9yYWxseSB1bmlxdWUgdmFsdWUgaW4gdGhlICJJZGVudGlm aWNhdGlvbiIgZmllbGQgb2YgdGhlIHBhY2tldAogICBoZWFkZXIgdGhhdCBjYW4gc2VydmUgZm9y IFNNRiBEUEQgcHVycG9zZXMuICBIb3dldmVyLCBpbiBwcmVzZW50CiAgIG9wZXJhdGluZyBzeXN0 ZW0gbmV0d29ya2luZyBrZXJuZWxzLCB0aGUgSVB2NCBoZWFkZXIgIklkZW50aWZpY2F0aW9uIgog ICB2YWx1ZSBpcyBub3QgYWx3YXlzIGdlbmVyYXRlZCBwcm9wZXJseSwgZXNwZWNpYWxseSB3aGVu IHRoZSAiZG9uJ3QKICAgZnJhZ21lbnQiIChERikgYml0IGlzIHNldC4gIFRoZSBJUHY0IEktRFBE IG1vZGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uCiAgIHJlcXVpcmVzIHRoYXQgSVB2NCAiSWRlbnRp ZmljYXRpb24iIGZpZWxkcyBhcmUgbWFuYWdlZCByZWFzb25hYmx5IGJ5CgoKCk1hY2tlciwgZWRp dG9yICYgU01GIERlc2lnbiBUZWFtICBFeHBpcmVzIFNlcHRlbWJlciA3LCAyMDEwICAgIFtQYWdl IDE2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgU01GICAgICAgICAgICAg ICAgICAgICAgICAgTWFyY2ggMjAxMAoKCiAgIHNvdXJjZSBob3N0cyBhbmQgdGhhdCB0ZW1wb3Jh bGx5IHVuaXF1ZSB2YWx1ZXMgYXJlIHNldCB3aXRoaW4gdGhlCiAgIGNvbnRleHQgb2YgdGhlIHBh Y2tldCBoZWFkZXIgPHByb3RvY29sOnNyY0FkZHI6ZHN0QWRkcj4gdHVwbGUuICBJZgogICB0aGlz IGlzIG5vdCBleHBlY3RlZCBkdXJpbmcgYW4gU01GIGRlcGxveW1lbnQsIHRoZW4gaXQgaXMgUkVD T01NRU5ERUQKICAgdGhhdCB0aGUgSC1EUEQgbWV0aG9kIGJlIHVzZWQgYXMgYSBtb3JlIHJlbGlh YmxlIGFwcHJvYWNoLgoKICAgU2luY2UgSVB2NCBTTUYgZG9lcyBub3Qgc3BlY2lmeSBhbiBvcHRp b25zIGhlYWRlciwgdGhlCiAgIGludGVyb3BlcmFiaWxpdHkgY29uc3RyYWludHMgYXJlIGxvb3Nl ciB0aGFuIHRoZSBJUHY2IHZlcnNpb24gYW5kCiAgIGZvcndhcmRlcnMgbWF5IGJlIG9wZXJhdGUg d2l0aCBtaXhlZCBILURQRCBhbmQgSS1EUEQgbW9kZXMgYXMgbG9uZyBhcwogICB0aGV5IGNvbnNp c3RlbnRseSBwZXJmb3JtIHRoZSBhcHByb3ByaWF0ZSBEUEQgcm91dGluZXMgb3V0bGluZWQgaW4K ICAgdGhlIGZvbGxvd2luZyBzZWN0aW9ucy4gIEhvd2V2ZXIsIGl0IGlzIFJFQ09NTUVOREVEIHRo YXQgYSBkZXBsb3ltZW50CiAgIGJlIGNvbmZpZ3VyZWQgd2l0aCBhIGNvbW1vbiBtb2RlIGZvciBv cGVyYXRpb25hbCBjb25zaXN0ZW5jeS4KCjUuMi4xLiAgSVB2NCBJZGVudGlmaWNhdGlvbi1iYXNl ZCBEUEQKCiAgIFRoZSBmb2xsb3dpbmcgdGFibGUgc3VtbWFyaXplcyB0aGUgSVB2NCBJLURQRCBw cm9jZXNzaW5nIGFwcHJvYWNoCiAgIG9uY2UgYSBwYWNrZXQgaGFzIHBhc3NlZCB0aGUgYmFzaWMg Zm9yd2FyZGFibGUgY3JpdGVyaWEgZGVzY3JpYmVkIGluCiAgIGVhcmxpZXIgU01GIHNlY3Rpb25z LgpVSD4gPT09PT09PT09PT09PT09PQpVSD4gQ2l0ZSBpbiB3aGljaCBzZWN0aW9ucwpVSD4gPT09 PT09PT09PT09PT09PQpKTT4gZG9uZQoKICAgV2l0aGluIHRoZSB0YWJsZSAnKicgaW5kaWNhdGVz IGEgZG9uJ3QgY2FyZQogICBjb25kaXRpb24uCgogICArLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCBkZiB8IG1m IHwgZnJhZ21lbnQgfCBJUFNlYyAgIHwgSVB2NCBJLURQRCBBY3Rpb24gICAgICAgICAgICAgICAg ICB8CiAgIHwgICAgfCAgICB8IG9mZnNldCAgIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICArLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCAxICB8IDEgIHwgKiAgICAg ICAgfCAqICAgICAgIHwgSW52YWxpZCwgRG8gTm90IEZvcndhcmQgICAgICAgICAgICB8CiAgIHwg MSAgfCAwICB8IG5vbnplcm8gIHwgKiAgICAgICB8IEludmFsaWQsIERvIE5vdCBGb3J3YXJkICAg ICAgICAgICAgfAogICB8ICogIHwgMCAgfCB6ZXJvICAgICB8IG5vdCAgICAgfCBUdXBsZSBJLURQ RCBDaGVjayBhbmQgUHJvY2VzcyBmb3IgIHwKICAgfCAgICB8ICAgIHwgICAgICAgICAgfCBQcmVz ZW50IHwgRm9yd2FyZGluZyAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgKiAgfCAwICB8 IHplcm8gICAgIHwgUHJlc2VudCB8IElQU2VjIGVuaGFuY2VkIFR1cGxlIEktRFBEIENoZWNrICAg fAogICB8ICAgIHwgICAgfCAgICAgICAgICB8ICAgICAgICAgfCBhbmQgUHJvY2VzcyBmb3IgRm9y d2FyZGluZyAgICAgICAgIHwKICAgfCAwICB8IDAgIHwgbm9uemVybyAgfCAqICAgICAgIHwgRXh0 ZW5kZWQgRnJhZ21lbnQgT2Zmc2V0IFR1cGxlICAgICB8CiAgIHwgICAgfCAgICB8ICAgICAgICAg IHwgICAgICAgICB8IEktRFBEIENoZWNrIGFuZCBQcm9jZXNzIGZvciAgICAgICAgfAogICB8ICAg IHwgICAgfCAgICAgICAgICB8ICAgICAgICAgfCBGb3J3YXJkaW5nICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgfCAwICB8IDEgIHwgemVybyBvciAgfCAqICAgICAgIHwgRXh0ZW5kZWQgRnJh Z21lbnQgT2Zmc2V0IFR1cGxlICAgICB8CiAgIHwgICAgfCAgICB8IG5vbnplcm8gIHwgICAgICAg ICB8IEktRFBEIENoZWNrIGFuZCBQcm9jZXNzIGZvciAgICAgICAgfAogICB8ICAgIHwgICAgfCAg ICAgICAgICB8ICAgICAgICAgfCBGb3J3YXJkaW5nICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rClVIPiA9PT09PT09PT09PT09PT09ClVIPiBUaGUgdGFibGUgaGVhZGVy cyBzaG91bGQgYmUgZXhwbGFpbmVkICh3aGF0IGlzICJkZiIsICJtZiIsIGZyYWdtZW50IG9mZnNl dC4pClVIPiA9PT09PT09PT09PT09PT09CkpNPiBvayBJIHBvaW50IG91dCB0aGUgSVB2NCBkYXRh Z3JhbSByZWZlcmVuY2VzLgoKICAgICAgICAgICAgICAgICAgIFRhYmxlIDQ6IElQdjQgSS1EUEQg UHJvY2Vzc2luZyBSdWxlcwoKICAgRm9yIHBlcmZvcm1hbmNlIHJlYXNvbnMsIElQdjQgbmV0d29y ayBmcmFnbWVudGF0aW9uIGFuZCByZWFzc2VtYmx5IG9mCiAgIG11bHRpY2FzdCBwYWNrZXRzIHdp dGhpbiB3aXJlbGVzcyBNQU5FVCBuZXR3b3JrcyBzaG91bGQgYmUgbWluaW1pemVkLAogICB5ZXQg U01GIHByb3ZpZGVzIHRoZSBmb3J3YXJkaW5nIG9mIGZyYWdtZW50cyB3aGVuIHRoZXkgb2NjdXIu ICBJZiB0aGUKICAgSVB2NCBtdWx0aWNhc3QgcGFja2V0IGlzIGEgZnJhZ21lbnQsIFNNRiBNVVNU IHVzZSB0aGUgZnJhZ21lbnRhdGlvbgogICBoZWFkZXIgZmllbGRzIGZvciBwYWNrZXQgaWRlbnRp ZmljYXRpb24uICBUaGlzIGlkZW50aWZpY2F0aW9uIGNhbiBiZQogICBjb25zaWRlcmVkIHRlbXBv cmFsbHkgdW5pcXVlIGluIHRoZSBjb250ZXh0IG9mIHRoZSA8cHJvdG9jb2w6c3JjQWRkcjoKICAg ZHN0QWRkcj4gb2YgdGhlIElQdjQgcGFja2V0LiAgSWYgdGhlIHBhY2tldCBpcyBhbiB1bmZyYWdt ZW50ZWQgSVB2NAogICBJUFNlYyBwYWNrZXQsIFNNRiBNVVNUIHVzZSBJUFNlYyBmaWVsZHMgZm9y IHBhY2tldCBpZGVudGlmaWNhdGlvbi4KICAgVGhlIElQU2VjIGhlYWRlciA8c2VxdWVuY2U+IGZp ZWxkIGNhbiBiZSBjb25zaWRlcmVkIGEgdW5pcXVlCgoKCk1hY2tlciwgZWRpdG9yICYgU01GIERl c2lnbiBUZWFtICBFeHBpcmVzIFNlcHRlbWJlciA3LCAyMDEwICAgIFtQYWdlIDE3XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgU01GICAgICAgICAgICAgICAgICAgICAgICAg TWFyY2ggMjAxMAoKCiAgIGlkZW50aWZpZXIgaW4gdGhlIGNvbnRleHQgb2YgdGhlIDxJUFNlY1R5 cGU6c3JjQWRkcjpkc3RBZGRyOlNQST4KICAgd2hlcmUgdGhlICJJUFNlY1R5cGUiIGlzIGVpdGhl ciBBSCBvciBFU1AuICAKVUg+ID09PT09PT09PT09PT09PT0KVUg+IERvZXMgb25lIHRha2UgQUgg b3IgRVNQIGlmIGJvdGggYXJlIGF2YWlsYWJsZT8KVUg+ID09PT09PT09PT09PT09PT0KSk0+IElm IHRoZXkgd2VyZSBjb21iaW5lZCBJIHdvdWxkIHN1Z2dlc3QgdXNpbmcgdGhlIG91dGVyIEFILgog ICAKICAgRmluYWxseSwgZm9yCiAgIHVuZnJhZ21lbnRlZCwgbm9uLUlQU2VjLCBJUHY0IHBhY2tl dHMsIHRoZSAiSWRlbnRpZmljYXRpb24iIGZpZWxkIGNhbgogICBiZSB1c2VkIGZvciBJLURQRCBw dXJwb3Nlcy4gIFRoZSAiSWRlbnRpZmljYXRpb24iIGZpZWxkIGNhbiBiZQogICBjb25zaWRlcmVk IHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgSVB2NCA8cHJvdG9jb2w6c2NyQWRkcjoKICAg ZHN0QWRkcj4gdHVwbGUuICBUaGUgZm9sbG93aW5nIHRhYmxlIHN1bW1hcml6ZXMgdGhlc2UgcGFj a2V0CiAgIGlkZW50aWZpY2F0aW9uIHR5cGVzOgoKICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgSVB2NCAg ICAgIHwgUGFja2V0IElkZW50aWZpY2F0aW9uIENvbnRleHQgICB8IFBhY2tldCBJZGVudGlmaWVy ICAgfAogICB8IFBhY2tldCAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgIHwKICAgfCBUeXBlICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8 IEZyYWdtZW50ICB8IDxwcm90b2NvbDpzcmNBZGRyOmRzdEFkZHI+ICAgICAgfCA8ZnJhZ21lbnRP ZmZzZXQ6aWQ+IHwKICAgfCBJUFNlYyAgICAgfCA8SVBTZWNUeXBlOnNyY0FkZHI6ZHN0QWRkcjpT UEk+IHwgPHNlcXVlbmNlPiAgICAgICAgICB8CiAgIHwgUGFja2V0ICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfAogICB8IFJlZ3VsYXIg ICB8IDxwcm90b2NvbDpzcmNBZGRyOmRzdEFkZHI+ICAgICAgfCA8aWQ+ICAgICAgICAgICAgICAg IHwKVUg+ID09PT09PT09PT09PT09PT0KVUg+IEhhcyA8aWQ+IGJlZW4gZGVmaW5lZCBiZWZvcmU/ ClVIPiA9PT09PT09PT09PT09PT09CkpNPiB0b28gbXVjaCBzaG9ydGhhbmQgYWRkZWQgdGhlIHJl ZiBhbmQgY2xhcmlmaWNhdGlvbgogICAKICAgfCBQYWNrZXQgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoK ICAgICAgICAgICAgICBUYWJsZSA1OiBJUHY0IEktRFBEIFBhY2tldCBJZGVudGlmaWNhdGlvbiBU eXBlcwoKICAgIklQU2VjVHlwZSIgaXMgZWl0aGVyIEF1dGhlbnRpY2F0aW9uIEhlYWRlciAoQUgp IG9yIEVuY2Fwc3VsYXRpbmcKICAgU2VjdXJpdHkgUGF5bG9hZCAoRVNQKS4KyS4KCjUuMy4gIElu dGVybmFsIEhhc2ggQ29tcHV0YXRpb24gQ29uc2lkZXJhdGlvbnMKVUg+ID09PT09PT09PT09PT09 PT0KVUg+IEkgYW0gbm90IHN1cmUgdGhpcyBiZWxvbmdzIGhlcmUgKHNlZSBwcmV2aW91cyBjb21t ZW50IG9uIHNlY3VyaXR5KS4gTWF5YmUgdG8gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgb3IgZXh0 cmEgZG9jdW1lbnQuLi4KVUg+ID09PT09PT09PT09PT09PT0KSk0+IE1vdmVkIHRvIHNlY3VyaXR5 IGFjdHVhbGx5IEkgdGhpbmsgaXQgd2FzIGFscmVhZHkgcmVkdW5kYW50bHkgdGhlcmUuCgogICBG b3J3YXJkaW5nIHByb3RvY29scyB0aGF0IHVzZSBEUEQgdGVjaG5pcXVlcywgc3VjaCBhcyBTTUYs IG1heSBiZQogICB2dWxuZXJhYmxlIHRvIGRlbmlhbC1vZi1zZXJ2aWNlIChEb1MpIGF0dGFja3Mg YmFzZWQgb24gc3Bvb2ZpbmcKICAgcGFja2V0cyB3aXRoIGFwcGFyZW50bHkgdmFsaWQgcGFja2V0 IGlkZW50aWZpZXIgZmllbGRzLiAgU3VjaCBhCiAgIGNvbnNpZGVyYXRpb24gaXMgcG9pbnRlZCBv dXQgaW4gU2VjdGlvbiAxMC4gIEluIHdpcmVsZXNzCiAgIGVudmlyb25tZW50cywgd2hlcmUgU01G IHdpbGwgbW9zdCBsaWtlbHkgYmUgdXNlZApVSD4gPT09PT09PT09PT09PT09PQpVSD4gSXQgaXMg YW4gYXNzdW1wdGlvbiwgd2hlcmUgU01GIHdpbGwgYmUgbW9zdCBsaWtlbHkgdXNlZC4KVUg+ID09 PT09PT09PT09PT09PT0KICAgCiAgICwgdGhlIG9wcG9ydHVuaXR5IGZvcgogICBzdWNoIGF0dGFj a3MgaXMgbW9yZSBwcmV2YWxlbnQgdGhhbiBpbiB3aXJlZCBuZXR3b3Jrcy4gIEluIHRoZSBjYXNl CiAgIG9mIElQdjQgcGFja2V0cywgZnJhZ21lbnRlZCBJUCBwYWNrZXRzIG9yIHBhY2tldHMgd2l0 aCBJUFNlYyBoZWFkZXJzCiAgIGFwcGxpZWQsIHRoZSBEUEQgImlkZW50aWZpZXIgcG9ydGlvbnMi IG9mIHBvdGVudGlhbCBmdXR1cmUgcGFja2V0cwogICB0aGF0IG1pZ2h0IGJlIGZvcndhcmRlZCBp cyBoaWdobHkgcHJlZGljdGFibGUgYW5kIGVhc2lseSBzdWJqZWN0IHRvCiAgIGRlbmlhbC1vZi1z ZXJ2aWNlIGF0dGFja3MgYWdhaW5zdCBmb3J3YXJkaW5nLiAgQSBSRUNPTU1FTkRFRAogICB0ZWNo bmlxdWUgdG8gY291bnRlciB0aGlzIGNvbmNlcm4gaXMgZm9yIFNNRiBpbXBsZW1lbnRhdGlvbnMg dG8KICAgZ2VuZXJhdGUgYW4gImludGVybmFsIiBoYXNoIHZhbHVlIHRoYXQgaXMgY29uY2F0ZW5h dGVkIHdpdGggdGhlCiAgIGV4cGxpY2l0IEktRFBEIHBhY2tldCBpZGVudGlmaWVyIHRvIGZvcm0g YSB1bmlxdWUgaWRlbnRpZmllciB0aGF0IGlzCiAgIGEgZnVuY3Rpb24gb2YgdGhlIHBhY2tldCBj b250ZW50IGFzIHdlbGwgYXMgdGhlIHZpc2libGUgaWRlbnRpZmllci4KICAgU01GIGltcGxlbWVu dGF0aW9ucyBjb3VsZCBzZWVkIHRoZWlyIGhhc2ggZ2VuZXJhdGlvbiB3aXRoIGEgcmFuZG9tCiAg IHZhbHVlIHRvIG1ha2UgaXQgdW5saWtlbHkgdGhhdCBhbiBleHRlcm5hbCBvYnNlcnZlciBjb3Vs ZCBndWVzcyBob3cKICAgdG8gc3Bvb2YgcGFja2V0cyB1c2VkIGluIGEgZGVuaWFsLW9mLXNlcnZp Y2UgYXR0YWNrIGFnYWluc3QKICAgZm9yd2FyZGluZy4gIFNpbmNlIHRoZSBoYXNoIGNvbXB1dGF0 aW9uIGFuZCBzdGF0ZSBpcyBrZXB0IGNvbXBsZXRlbHkKICAgaW50ZXJuYWwgdG8gU01GIG5vZGVz LCB0aGUgY3J5cHRvZ3JhcGhpYyBwcm9wZXJ0aWVzIG9mIHRoaXMgaGFzaGluZwogICB3b3VsZCBu b3QgbmVlZCB0byBiZSBleHRlbnNpdmUgYW5kIHRodXMgcG9zc2libHkgb2YgbG93IGNvbXBsZXhp dHkuCiAgIEV4cGVyaW1lbnRhbCBpbXBsZW1lbnRhdGlvbnMgbWF5IGRldGVybWluZSB0aGF0IGEg bGlnaHR3ZWlnaHQgaGFzaCBvZgogICBldmVuIG9ubHkgcG9ydGlvbnMgb2YgcGFja2V0cyBtYXkg c3VmZmljZSB0byBzZXJ2ZSB0aGlzIHB1cnBvc2UuClVIPiA9PT09PT09PT09PT09PT09ClVIPiBJ cyB0aGVyZSBhbnkgcHJvb2Ygb3IgYW5hbHlzaXMgaG93L3doZXRoZXIgdGhhdCB3b3Jrcz8KVUg+ ID09PT09PT09PT09PT09PT0KICAgCgogICBGb3IgSVB2NCBJLURQRCBiYXNlZCBvbiB0aGUgbGlt aXRlZCAxNi1iaXQgSVAgaGVhZGVyICJJZGVudGlmaWNhdGlvbiIKICAgZmllbGQsIGl0IGlzIHBv c3NpYmxlIHRoYXQgdXNlIG9mIHRoaXMgImludGVybmFsIGhhc2giIHRlY2huaXF1ZSBtYXkKICAg YWxzbyBlbmhhbmNlIEktRFBEIHBlcmZvcm1hbmNlIGluIGNhc2VzIHdoZXJlIHRoZSBJUHY0CiAg ICJJZGVudGlmaWNhdGlvbiIgZmllbGQgbWF5IGZyZXF1ZW50bHkgd3JhcCBkdWUgdG8gc291cmNl cyBzdXBwb3J0aW5nCiAgIGhpZ2ggZGF0YSByYXRlIGZsb3dzLgpVSD4gPT09PT09PT09PT09PT09 PQpVSD4gSXQgaXMgInBvc3NpYmxlIiB0aGF0IGl0IGltcHJvdmVzIHBlcmZvcm1hbmNlPyBUaGF0 IHNvdW5kcyBhIGJpdCB2YWd1ZS4KVUg+ID09PT09PT09PT09PT09PT0KSk0+IHRvbyB2YWd1ZSBh bmQgaW5hcHByb3ByaWF0ZSBoZXJlIEkgZGVsZXRlZCBpdC4KICAgCsnJCgo2LiAgUmVkdWNlZCBS ZWxheSBTZXQgRm9yd2FyZGluZyBhbmQgUmVsYXkgU2VsZWN0aW9uIENhcGFiaWxpdHkKCiAgIFNN RiBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IENGIGFzIGEgYmFzaWMgZm9yd2FyZGluZyBt ZWNoYW5pc20KICAgd2hlbiByZWR1Y2VkIHJlbGF5IHNldCBpbmZvcm1hdGlvbiBpcyBub3QgYXZh aWxhYmxlIG9yIG5vdCBzZWxlY3RlZAogICBmb3Igb3BlcmF0aW9uLiAgCgpVSD4gPT09PT09PT09 PT09PT09PQpVSD4gQ0YgbW9kZSBzaG91bGQgYmUgZGVmaW5lZCBpbiB0aGUgc3BlYyBpbiBhIHNl cGVyYXRlIHNlY3Rpb24uClVIPiA9PT09PT09PT09PT09PT09CkpNPiBEb25lLgoKICAgSW4gQ0Yg bW9kZSwgZWFjaCBub2RlIHRyYW5zbWl0cyBhIGxvY2FsbHkgZ2VuZXJhdGVkCiAgIG9yIG5ld2x5 IHJlY2VpdmVkIGZvcndhcmRhYmxlIHBhY2tldCBleGFjdGx5IG9uY2UuICBUaGUgRFBECiAgIHRl Y2huaXF1ZXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNSBhcmUgY3JpdGljYWwgdG8gcHJvcGVyIG9w ZXJhdGlvbgogICBhbmQgcHJldmVudCBkdXBsaWNhdGUgcGFja2V0IHJldHJhbnNtaXNzaW9ucyBi eSB0aGUgc2FtZSBmb3J3YXJkaW5nCiAgIG5vZGUuCgogICBBIGdvYWwgb2YgU01GIGlzIHRvIGFw cGx5IHJlZHVjZWQgcmVsYXkgc2V0cyBmb3IgbW9yZSBlZmZpY2llbnQKICAgbXVsdGljYXN0IGRp c3NlbWluYXRpb24gd2l0aGluIGR5bmFtaWMgdG9wb2xvZ2llcy4gIFRvIGFjY29tcGxpc2gKICAg dGhpcyBTTUYgTVVTVCBzdXBwb3J0IHRoZSBhYmlsaXR5IHRvIG1vZGlmeSBpdHMgbXVsdGljYXN0 IHBhY2tldAogICBmb3J3YXJkaW5nIHJ1bGVzIGJhc2VkIHVwb24gcmVsYXkgc2V0IHN0YXRlIHJl Y2VpdmVkIGR5bmFtaWNhbGx5CiAgIGR1cmluZyBvcGVyYXRpb24uICBJbiB0aGlzIHdheSwgU01G IGZvcndhcmRpbmcgb3BlcmF0ZXMgZWZmZWN0aXZlbHkKICAgYXMgbmVpZ2hib3IgYWRqYWNlbmNp ZXMgb3IgbXVsdGljYXN0IGZvcndhcmRpbmcgcG9saWNpZXMgd2l0aGluIHRoZQogICB0b3BvbG9n eSBjaGFuZ2UuCgogICBJbiBlYXJseSBTTUYgZXhwZXJpbWVudGFsIGRlcGxveW1lbnRzLApVSD4g PT09PT09PT09PT09PT09PQpVSD4gV2hpY2g/ClVIPiA9PT09PT09PT09PT09PT09CkpNPiBJIGhh dmUgYSBmZXcgcmVmZXJlbmNlcyB0byBwcm90b3R5cGVzIGFuZCBpbmZvcm1hdGl2ZSBwYXBlcnMs IGluY2x1ZGVzIE9MU1IgTVBSLCBFLUNEUyBhbmQgT1NQRnYzIE1EUiB1c2UgZ29pbmcgYmFjayB0 byAyMDA0LgpKTT4gSSdsbCBhZGQgYSByZWYgaGVyZS4KICAgCiAgIHRoZSByZWxheSBzZXQgaW5m b3JtYXRpb24gaGFzCiAgIGJlZW4gZGVyaXZlZCBmcm9tIGNvZXhpc3RlbnQgdW5pY2FzdCByb3V0 aW5nIGNvbnRyb2wgcGxhbmUgdHJhZmZpYwogICBmbG9vZGluZyBwcm9jZXNzZXMuICBGcm9tIHRo aXMgZXhwZXJpZW5jZSwgZXh0cmEgcHJ1bmluZwogICBjb25zaWRlcmF0aW9ucyB3ZXJlIHNvbWV0 aW1lcyByZXF1aXJlZCB3aGVuIHV0aWxpemluZyBhIHJlbGF5IHNldAogICBmcm9tIGEgc2VwYXJh dGUgcm91dGluZyBwcm90b2NvbCBwcm9jZXNzLiAgQXMgYW4gZXhhbXBsZSwgcmVsYXkgc2V0cwog ICBmb3JtZWQgZm9yIHRoZSB1bmljYXN0IGNvbnRyb2wgcGxhbmUgZmxvb2RpbmcgTUFZIGluY2x1 ZGUgYWRkaXRpb25hbAogICByZWR1bmRhbmN5IHRoYXQgbWF5IG5vdCBiZSBkZXNpcmVkIGZvciBt dWx0aWNhc3QgZm9yd2FyZGluZyB1c2UKICAgKGUuZy4sIGJpY29ubmVjdGVkIENEUyBtZXNoIGZv ciBjb250cm9sIHBsYW5lIHB1cnBvc2VzKS4KVUg+ID09PT09PT09PT09PT09PT0KVUg+ICJiaWNv bm5lY3RlZCBDRFMgbWVzaCBmb3IgY29udHJvbCBwbGFuZSBwdXJwb3NlcyIgLSBkZWZpbml0aW9u PyBDRFMgaGFzIG5vdCBiZWVuIHVzZWQgYmVmb3JlLgpVSD4gPT09PT09PT09PT09PT09PQpKTT4g ZXZlcnlvbmUgcHJldmlvdXNseSBhc2tlZCBtZSB0byB0YWtlIG91dCBhbGwgZGV0YWlscyBvbiB0 aGlzLCBDRFMgZXRjLiBEaWRuJ3Qgd2FudCB0dXRvcmlhbCBpbmZvIG5vdyBJIG5lZWQgaXQgYmFj ay4gZ2xhZCB5b3UgY2F1Z2h0IHRoaXMuIEknbGwganVzdCBtYWtlIGl0IG1vcmUgdmFndWUgYnV0 IHJlbW92aW5nIGl0LiBJIGNhbiByZWZlciBzb21lIHRvIE9TUEZ2My1NRFIgYW5kIFNNRiBhZGFw dGF0aW9uLgogICAKCiAgIEhlcmUgaXMgYSByZWNvbW1lbmRlZCBjcml0ZXJpYSBsaXN0IGZvciBT TUYgcmVsYXkgc2V0IHNlbGVjdGlvbgogICBhbGdvcml0aG0gY2FuZGlkYXRlczoKCiAgIDEuICBS b2J1c3RuZXNzIHRvIHRvcG9sb2dpY2FsIGR5bmFtaWNzIGFuZCBtb2JpbGl0eQogICAyLiAgTG9j YWxpemVkIGVsZWN0aW9uIG9yIGNvb3JkaW5hdGlvbiBvZiBhbnkgcmVsYXkgc2V0cwogICAzLiAg UmVhc29uYWJsZSBtaW5pbWl6YXRpb24gb2YgQ0RTIHJlbGF5IHNldCBzaXplIGdpdmVuIGFib3Zl CiAgICAgICBjb25zdHJhaW50cwogICA0LiAgSGV1cmlzdGljIHN1cHBvcnQgZm9yIHByZWZlcmVu Y2Ugb3IgZWxlY3Rpb24gbWV0cmljcyAoQmV0dGVyCiAgICAgICBlbmFibGVzIHNjZW5hcmlvLXNw ZWNpZmljIG1hbmFnZW1lbnQgb2YgcmVsYXkgc2V0KQpVSD4gPT09PT09PT09PT09PT09PQpVSD4g V2hhdCBkb2VzICJCZXR0ZXIgZW5hYmxlcyBzY2VuYXJpby1zcGVjaWZpYyBtYW5hZ2VtZW50IG9m IHJlbGF5IHNldCIgbWVhbj8KVUg+ID09PT09PT09PT09PT09PT0KSk0+IGJhZCBncmFtbWFyIHNv IEkgd2lsbCByZW1vdmUgaXQuCgogICBTb21lIHJlbGF5IHNldCBhbGdvcml0aG1zIG1lZXRpbmcg dGhlc2UgY3JpdGVyaWEgYXJlIGRlc2NyaWJlZCBpbiB0aGUKICAgQXBwZW5kaWNlcyBvZiB0aGlz IGRvY3VtZW50LiAgQWRkaXRpb25hbCByZWxheSBzZXQgc2VsZWN0aW9uCiAgIGFsZ29yaXRobXMg bWF5IGJlIHNwZWNpZmllZCBpbiBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9ucyBpbiB0aGUgZnV0dXJl LgogICBUaGUgQXBwZW5kaWNlcyAKVUg+ID09PT09PT09PT09PT09PT0KVUg+IFdoaWNoIGV4YWN0 IHNlY3Rpb24/ClVIPiA9PT09PT09PT09PT09PT09CkpNPiBmaXhlZAogICBpbiB0aGlzIGRvY3Vt ZW50IGNhbiBzZXJ2ZSBhcyBhIHRlbXBsYXRlIGZvciB0aGUKICAgY29udGVudCBvZiBzdWNoIHBv dGVudGlhbCBmdXR1cmUgc3BlY2lmaWNhdGlvbnMuCgogICBGaWd1cmUgNCBkZXBpY3RzIGEgc3Rh dGUgaW5mb3JtYXRpb24gZGlhZ3JhbSBvZiBwb3NzaWJsZSByZWxheSBzZXQKICAgY29udHJvbCBv cHRpb25zLgoKCgoKCgpNYWNrZXIsIGVkaXRvciAmIFNNRiBEZXNpZ24gVGVhbSAgRXhwaXJlcyBT ZXB0ZW1iZXIgNywgMjAxMCAgICBbUGFnZSAyMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgICAgIFNNRiAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTAKCgogICAgICAg ICAgICAgICAgICAgICAgIFBvc3NpYmxlIEwyIFRyaWdnZXIvSW5mb3JtYXRpb24KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgX19fX19fX19fX19fX18gICAgICAgICAgICAgIF9fX19fX3ZfX19f XyAgICAgICAgIF9fX19fX19fX19fX19fX19fXwogICB8ICAgIE1BTkVUICAgICB8ICAgICAgICAg ICAgfCAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICAgIHwKICAgfCBOZWlnaGJv cmhvb2QgfCAgICAgICAgICAgIHwgUmVsYXkgU2V0ICB8ICAgICAgIHwgT3RoZXIgSGV1cmlzdGlj cyB8CiAgIHwgIERpc2NvdmVyeSAgIHwtLS0tLS0tLS0tLT58IFNlbGVjdGlvbiAgfDwtLS0tLS18 IChQcmVmZXJlbmNlLGV0YykgfAogICB8ICAgUHJvdG9jb2wgICB8IG5laWdoYm9yICAgfCBBbGdv cml0aG0gIHwgICAgICAgfCAgICAgICAgICAgICAgICAgIHwKICAgfF9fX19fX19fX19fX19ffCAg IGluZm8gICAgIHxfX19fX19fX19fX198ICAgICAgIHxfX19fX19fX19fX19fX19fX198CiAgICAg ICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLwogICAgICAgICAgIFwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLwogICAgbmVpZ2hib3JcICAgICAgICAgICAgICAgICAgICAg ICAgICAvIER5bmFtaWMgUmVsYXkKICAgICAgaW5mbyogIFwgICAgICBfX19fX19fX19fX18gICAg ICAvICAgIFNldCBTdGF0dXMKICAgICAgICAgICAgICBcICAgIHwgICAgU01GICAgICB8ICAgIC8g KFN0YXRlLCB7bmVpZ2hib3IgaW5mb30pCiAgICAgICAgICAgICAgIGAtLT58IFJlbGF5IFNldCAg fDwtLScKICAgICAgICAgICAgICAgICAgIHwgICBTdGF0ZSAgICB8CiAgICAgICAgICAgICAgICAt LT58X19fX19fX19fX19ffAogICAgICAgICAgICAgICAvCiAgICAgICAgICAgICAgLwogICAgX19f X19fX19fX19fX18KICAgfCAgQ29leGlzdGVudCAgfAogICB8ICAgIE1BTkVUICAgICB8CiAgIHwg ICBVbmljYXN0ICAgIHwKICAgfCAgIFByb2Nlc3MgICAgfAogICB8X19fX19fX19fX19fX198CgoK ICAgICAgICAgICAgICAgICAgRmlndXJlIDQ6IFNNRiBSZWxheSBTZXQgQ29udHJvbCBPcHRpb25z CiAgICAgICAgICAgICAgICAgIApVSD4gPT09PT09PT09PT09PT09PQpVSD4gVGhpcyBwaWN0dXJl IGlzIG5ldmVyIGV4cGxhaW5lZC4KVUg+ID09PT09PT09PT09PT09PT0KSk0+IFRoZSBmb2xsb3dp bmcgcGFyYWdyYXBocyBhdHRlbXB0ZWQgdG8gZXhwbGFpbiB0aGUgcGljdHVyZSBhbmQgbW9kZXMg b2Ygb3BlcmF0aW9uIEkgd2lsbCB0cnkgdG8gY2xhcmlmeSBpbiB0aGlzIHJldiBieSBhZGRpbmcg YW4gaW50cm8gYW5kIG1vcmUgZGlzY3Vzc2lvbi4KCiAgIFRoZXJlIGFyZSBiYXNpY2FsbHkgdGhy ZWUgc3R5bGVzIG9mIFNNRiBvcGVyYXRpb24gd2l0aCByZWR1Y2VkIHJlbGF5CiAgIHNldHM6Cgog ICAxLiAgSW5kZXBlbmRlbnQgb3BlcmF0aW9uOiBJbiB0aGlzIGNhc2UsIFNNRiBwZXJmb3JtcyBp dHMgb3duIHJlbGF5CiAgICAgICBzZXQgc2VsZWN0aW9uIHVzaW5nIGluZm9ybWF0aW9uIGZyb20g YW4gYXNzb2NpYXRlZCBNQU5FVCBOSERQCiAgICAgICBwcm9jZXNzLiAgSW4gdGhpcyBjYXNlLCBO SERQIG1lc3NhZ2luZyBTSE9VTEQgYmUgYXBwZW5kZWQgd2l0aAogICAgICAgYWRkaXRpb25hbCBb UkZDNTQ0NF0gdHlwZS1sZW5ndGgtdmFsdWUgKFRMVikgY29udGVudCB0byBzdXBwb3J0CiAgICAg ICBTTUYtc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDcgYW5k IGZvciB0aGUKICAgICAgIGFwcGxpY2FibGUgcmVsYXkgc2V0IGFsZ29yaXRobSBkZXNjcmliZWQg aW4gdGhlIEFwcGVuZGljZXMgb2YKICAgICAgIHRoaXMgZG9jdW1lbnQgb3IgZnV0dXJlIHNwZWNp ZmljYXRpb25zLgoKICAgMi4gIE9wZXJhdGlvbiB3aXRoIENEUy1hd2FyZSB1bmljYXN0IHJvdXRp bmcgcHJvdG9jb2w6IEluIHRoaXMgY2FzZSwKICAgICAgIGEgY29leGlzdGVudCB1bmljYXN0IHJv dXRpbmcgcHJvdG9jb2wgcHJvdmlkZXMgZHluYW1pYyByZWxheSBzZXQKICAgICAgIHN0YXRlIGJh c2VkIHVwb24gaXRzIG93biBjb250cm9sIHBsYW5lIENEUyBvciBuZWlnaGJvcmhvb2QKICAgICAg IGRpc2NvdmVyeSBpbmZvcm1hdGlvbi4gIElmIGl0IGlzIGRlc2lyZWQgdGhhdCB0aGUgU01GIGRh dGEgcGxhbmUKICAgICAgIGZvcndhcmRpbmcgdXNlIGEgZGlmZmVyZW50IHJlbGF5IHNldCBzZWxl Y3Rpb24gYWxnb3JpdGhtIHRoYW4KICAgICAgIHVzZWQgZm9yIHRoZSByb3V0aW5nIHByb3RvY29s IGNvbnRyb2wgcGxhbmUsIHRoZW4gdGhlIHJvdXRpbmcKICAgICAgIHByb3RvY29sIE5IRFAgaW5z dGFuY2UgICAgICAgIChpZiBhcHBsaWNhYmxlKSBTSE9VTEQgYXBwZW5kIGl0cyBtZXNzYWdlcwog ICAgICAgd2l0aCB0aGUgYXBwcm9wcmlhdGUgU01GLXNwZWNpZmljIFRMViBjb250ZW50IChzZWUg U2VjdGlvbiA3IGFuZAogICAgICAgdGhlIHJlbGF5IHNldCBhbGdvcml0aG0gQXBwZW5kaWNlcyku CgoKCk1hY2tlciwgZWRpdG9yICYgU01GIERlc2lnbiBUZWFtICBFeHBpcmVzIFNlcHRlbWJlciA3 LCAyMDEwICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAg U01GICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMAoKCiAgIDMuICBDcm9zcy1sYXll ciBPcGVyYXRpb246IEluIHRoaXMgY2FzZSwgU01GIG9wZXJhdGVzIHVzaW5nCiAgICAgICBuZWln aGJvcmhvb2Qgc3RhdHVzIGFuZCB0cmlnZ2VycyBmcm9tIGEgY3Jvc3MtbGF5ZXIgaW5mb3JtYXRp b24KICAgICAgIGJhc2UgZm9yIGR5bmFtaWMgcmVsYXkgc2V0IHNlbGVjdGlvbiBhbmQgbWFpbnRl bmFuY2UgKGUuZy4sIGxvd2VyCiAgICAgICBsaW5rIGxheWVyKSAuCgogICAgICAgCgoKNy4gIFNN RiBOZWlnaGJvcmhvb2QgRGlzY292ZXJ5IFJlcXVpcmVtZW50cwoKICAgVGhpcyBzZWN0aW9uIGRl ZmluZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgdXNlIG9mIHRoZSBNQU5FVAogICBOZWlnaGJvcmhv b2QgRGlzY292ZXJ5IFByb3RvY29sIChOSERQKSBbTkhEUF0gdG8gc3VwcG9ydCBTTUYKICAgb3Bl cmF0aW9uLiAgTm90ZSB0aGF0IGJhc2ljIENGIGZvcndhcmRpbmcgcmVxdWlyZXMgbm8gbmVpZ2hi b3Job29kCiAgIHRvcG9sb2d5IGtub3dsZWRnZSBzaW5jZSBpbiB0aGlzIGNvbmZpZ3VyZWQgbW9k ZSBldmVyeSBTTUYgbm9kZQogICByZWxheXMgYWxsIHRyYWZmaWMuICBTdXBwb3J0aW5nIG1vcmUg cmVkdWNlZCBTTUYgcmVsYXkgc2V0IG9wZXJhdGlvbgogICByZXF1aXJlcyB0aGUgZGlzY292ZXJ5 IGFuZCBtYWludGVuYW5jZSBvZiBkeW5hbWljIG5laWdoYm9yaG9vZAogICB0b3BvbG9neSBpbmZv cm1hdGlvbi4gIFRoZSBNQU5FVCBOSERQIHByb3RvY29sIGNhbiBiZSBsZXZlcmFnZWQKICAgcHJv dmlkZSB0aGlzIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiwgaG93ZXZlciB0aGVyZSBhcmUgU01GLXNw ZWNpZmljCiAgIHJlcXVpcmVtZW50cyBmb3IgcmVsYXRlZCBOSERQIHVzZS4gIFRoaXMgaXMgdGhl IGNhc2UgZm9yIGJvdGgKICAgImluZGVwZW5kZW50IiBTTUYgb3BlcmF0aW9uIHdoZXJlIE5IRFAg aXMgYmVpbmcgdXNlZCBzcGVjaWZpY2FsbHkgdG8KICAgc3VwcG9ydCBTTUYgb3Igd2hlbiBvbmUg TkhEUCBpbnN0YW5jZSBpcyB1c2VkIGZvciBib3RoIGZvciBTTUYgYW5kIGEKICAgY29leGlzdGVu dCBNQU5FVCB1bmljYXN0IHJvdXRpbmcgcHJvdG9jb2wuCgogICBDb3JlIE5IRFAgbWVzc2FnZXMg CiAgIGFuZCB0aGUgcmVzdWx0YW50IG5laWdoYm9yaG9vZCBpbmZvcm1hdGlvbiBiYXNlCiAgIGFy ZSBkZXNjcmliZWQgc2VwYXJhdGVseSB3aXRoaW4gdGhlIE5IRFAgc3BlY2lmaWNhdGlvbi4gIFRv CiAgIHN1bW1hcml6ZSwgdGhlIE5IRFAgcHJvdG9jb2wgcHJvdmlkZXMgdGhlIGZvbGxvd2luZyBi YXNpYyBmdW5jdGlvbnM6CgogICAxLiAgMS1ob3AgbmVpZ2hib3IgbGluayBzZW5zaW5nIGFuZCBi aWRpcmVjdGlvbmFsaXR5IGNoZWNrcyBvZgogICAgICAgbmVpZ2hib3IgbGlua3MsCiAgIDIuICAy LWhvcCBuZWlnaGJvcmhvb2QgZGlzY292ZXJ5IGluY2x1ZGluZyBjb2xsZWN0aW9uIG9mIDItaG9w CiAgICAgICBuZWlnaGJvcnMgYW5kIGNvbm5lY3Rpdml0eSBpbmZvcm1hdGlvbiwKICAgMy4gIENv bGxlY3Rpb24gYW5kIG1haW50ZW5hbmNlIG9mIHRoZSBhYm92ZSBpbmZvcm1hdGlvbiBhY3Jvc3MK ICAgICAgIG11bHRpcGxlIGludGVyZmFjZXMsIGFuZAogICA0LiAgQSBtZXRob2QgZm9yIHNpZ25h bGluZyBTTUYgaW5mb3JtYXRpb24gdGhyb3VnaG91dCB0aGUgMi1ob3AKICAgICAgIG5laWdoYm9y aG9vZAoKICAgVGhlIEFwcGVuZGljZXMgClVIPiA9PT09PT09PT09PT09PT09ClVIPiBXaGljaCBw cmVjaXNlIHNlY3Rpb25zPwpVSD4gPT09PT09PT09PT09PT09PQpKTT4gYWRkZWQKCiAgIG9mIHRo aXMgZG9jdW1lbnQgZGVzY3JpYmUgYSBzZXQgb2YgQ0RTLWJhc2VkIHJlbGF5IHNldAogICBzZWxl Y3Rpb24gYWxnb3JpdGhtcyB0aGF0IGNhbiBiZSB1c2VkIHRvIGFjaGlldmUgZWZmaWNpZW50IFNN RgogICBvcGVyYXRpb24sIGV2ZW4gaW4gZHluYW1pYywgbW9iaWxlIG5ldHdvcmtzW01EREEwN10u CiAKICAgV2hlbiB1c2luZwogICB0aGVzZSBhbGdvcml0aG1zIGluIGNvbmp1bmN0aW9uIHdpdGgg TkhEUCwgYSBtZXRob2QgdmVyaWZ5aW5nCiAgIG5laWdoYm9yIFNNRiBvcGVyYXRpb24gaXMgcmVx dWlyZWQgaW4gb3JkZXIgdG8gaW5zdXJlIGNvcnJlY3QgcmVsYXkKICAgc2V0IHNlbGVjdGlvbi4g IFRoZSBjb3JlIE5IRFAgc3BlY2lmaWNhdGlvbiAKICAgYWxvbmcgd2l0aCBTTUYgb3BlcmF0aW9u CiAgIHZlcmlmaWNhdGlvbiBwcm92aWRlcyB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIHJlcXVp cmVkIGJ5IHRoZXNlCiAgIGFsZ29yaXRobXMgdG8gY29uZHVjdCByZWxheSBzZXQgc2VsZWN0aW9u LiAgVmVyaWZpY2F0aW9uIG9mIFNNRgogICBvcGVyYXRpb24gbWF5IGJlIGRvbmUgYWRtaW5pc3Ry YXRpdmVseSBvciB0aHJvdWdoIHRoZSB1c2Ugb2YgdGhlIFNNRgogICByZWxheSBhbGdvcml0aG1z IFRMVnMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LgpVSD4gPT09PT09PT09PT09PT09PQpVSD4g RGVmaW5lZCB3aGVyZT8gSW4gd2hpY2ggc2VjdGlvbj8KVUg+ID09PT09PT09PT09PT09PT0KSk0+ IGFkZGVkLgogICAKICAgVXNlIG9mIHRoZSBTTUYgcmVsYXkKICAgYWxnb3JpdGhtIFRMVnMgaXMg UkVDT01NRU5ERUQgd2hlbiB1c2luZyBOSERQIGZvciBTTUYgbmVpZ2hib3Job29kCiAgIGRpc2Nv dmVyeS4KCiAgIFRoZSBmb2xsb3dpbmcgc3ViLXNlY3Rpb25zIHNwZWNpZnkgc29tZSBTTUYtc3Bl Y2lmaWMgVExWIHR5cGVzCgrJLi4KCjcuMS4gIFNNRiBSZWxheSBBbGdvcml0aG0gVExWIFR5cGVz CgogICBUaGlzIHNlY3Rpb24gc3BlY2lmaWVzIFRMViB0eXBlcyB0byBiZSB1c2VkIHdpdGhpbiBO SERQIG1lc3NhZ2VzIAogICB0bwogICBpZGVudGlmeSB0aGUgQ0RTIHJlbGF5IHNldCBzZWxlY3Rp b24gYWxnb3JpdGhtKHMpIGluIHVzZS4gIFR3byBUTFYKICAgdHlwZXMgYXJlIGRlZmluZWQsIG9u ZSBtZXNzYWdlIFRMViB0eXBlIGFuZCBvbmUgYWRkcmVzcyBUTFYgdHlwZS4KVUg+ID09PT09PT09 PT09PT09PT0KVUg+IEkgd291bGQgbW92ZSB0aGF0IHRvIHRoZSBlbmQgb2YgdGhlIGRvY3VtZW50 IChJQU5BIENvbnNpZGVyYXRpb25zKQpVSD4gPT09PT09PT09PT09PT09PQpKRD4gPT09PT09PT09 PT09PQpKRD4gSSBhbSBva2F5IHdpdGggbW92aW5nIHRoZSBhc3NpZ25tZW50cyB0byBJQU5BIGJ1 dCBJIGZpbmQgaXQgdXNlZnVsIHRvIGRlc2NyaWJlIHRoZW0gaGVyZSBzbyB0aGF0IHRoZWlyIHVz ZSBpcyB1bmRlcnN0b29kLgpKRD4gPT09PT09PT09PT09PQpKTT4gSSBhZGRlZCBzb21lIG9mIHRo aXMgZGlzY3Vzc2lvbiB0byBJQU5BLCBidXQgbGVmdCBwdXJwb3NlIGludHJvIGhlcmUuLgoKNy4x LjEuICBTTUYgTWVzc2FnZSBUTFYgVHlwZQoKICAgVGhlIFNNRiBtZXNzYWdlIFRMViB0eXBlIGRl bm90ZWQgU01GX1RZUEUgaXMgdXNlZCB0byBpZGVudGlmeSB0aGUKICAgZXhpc3RlbmNlIG9mIGFu IFNNRiBpbnN0YW5jZSBvcGVyYXRpbmcgaW4gY29uanVuY3Rpb24gd2l0aCBOSERQLgogICBUaGlz IG1lc3NhZ2UgdHlwZSAKClVIPiA9PT09PT09PT09PT09PT09ClVIPiBZb3UgbWVhbiAiVExWIHR5 cGUiPwpVSD4gPT09PT09PT09PT09PT09PQpKTT4gcmlnaHQgZ290IGl0IGZpeGVkLgoKCiAgIG1h a2VzIHVzZSBvZiB0aGUgZXh0ZW5kZWQgdHlwZSBmaWVsZCBhcyBkZWZpbmVkIGJ5CiAgIFtSRkM1 NDQ0XSB0byBjb252ZXkgdGhlIENEUyByZWxheSBzZXQgc2VsZWN0aW9uIGFsZ29yaXRobSBjdXJy ZW50bHkKICAgaW4gdXNlIGJ5IHRoZSBTTUYgbWVzc2FnZSBvcmlnaW5hdG9yLiAgV2hlbiBOSERQ IGlzIHVzZWQgdG8gc3VwcG9ydAogICBTTUYgb3BlcmF0aW9uLCB0aGUgU01GX1RZUEUgVExWLCBj b250YWluaW5nIHRoZSBleHRlbmRlZCB0eXBlIGZpZWxkCiAgIHdpdGggdGhlIGFwcHJvcHJpYXRl IHZhbHVlLCBTSE9VTEQgYmUgaW5jbHVkZWQgaW4gTkhEUF9IRUxMTyAKVUg+ID09PT09PT09PT09 PT09PT0KVUg+IE5IRFBfSEVMTE8gbWVzc2FnZSBoYXMgbmV2ZXIgYmVlbiBkZWZpbmVkLiBJdCB3 b3VsZCBiZSAiSEVMTE8gbWVzc2FnZSBhcyBkZWZpbmVkIGluIFtOSERQXSIKVUg+ID09PT09PT09 PT09PT09PT0KSk0+IGRlZmluZWQgTkhEUF9IRUxMTyBhcyBhIEhFTExPIGZyb20gTkhEUCBhbmQg cmVmJ2QgNjEzMAoKICAgbWVzc2FnZXMKICAgZ2VuZXJhdGVkLiAgVGhpcyBhbGxvd3MgU01GIG5v ZGVzIHRvIGxlYXJuIHdoZW4gbmVpZ2hib3JzIGFyZQogICBjb25maWd1cmVkIHRvIHVzZSBOSERQ IGZvciBpbmZvcm1hdGlvbiBleGNoYW5nZSBpbmNsdWRpbmcgYWxnb3JpdGhtCiAgIHR5cGUgYW5k IHJlbGF0ZWQgYWxnb3JpdGhtIGluZm9ybWF0aW9uLiAgVGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUg dXNlZAogICB0byB0YWtlIGFjdGlvbiwgc3VjaCBhcyBpZ25vcmluZyBuZWlnaGJvciBpbmZvcm1h dGlvbiB1c2luZwogICBpbmNvbXBhdGlibGUgYWxnb3JpdGhtcy4gIEl0IGlzIHBvc3NpYmxlIHRo YXQgU01GIG5laWdoYm9ycyBNQVkgYmUKICAgY29uZmlndXJlZCBkaWZmZXJlbnRseSBhbmQgc3Rp bGwgb3BlcmF0ZSBjb29wZXJhdGl2ZWx5LCBidXQgdGhlc2UKICAgY2FzZXMgd2lsbCB2YXJ5IGRl cGVuZGVudCB1cG9uIHRoZSBhbGdvcml0aG0gdHlwZXMgZGVzaWduYXRlZC4KCiAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyB0aGUgZm9sbG93aW5nIE1lc3NhZ2UgVExWIHR5cGVUYWJsZSA2CiAgIGNv bmZvcm1pbmcgdG8gW1JGQzU0NDRdLiAgRXh0ZW5kZWQgdHlwZSBmaWVsZCB2YWx1ZXMgY29tbXVu aWNhdGUKICAgIlJlbGF5IEFsZ29yaXRobSBUeXBlIiB0byBvdGhlciAxLWhvcCBTTUYgbmVpZ2hi b3JzIGFuZCB2YWx1ZSBmaWVsZHMKICAgbWF5IGNvbnRhaW4gYWxnb3JpdGhtIHNwZWNpZmljIGlu Zm9ybWF0aW9uLgogICAgICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICB8ICAgICAgICAgICAgICAgfCBwYWNrZXRCQiBU TFYgc3ludGF4IHwgRmllbGQgVmFsdWVzICAgICAgIHwKICAgICAgICstLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgfCB0eXBl ICAgICAgICAgIHwgPHRsdi10eXBlPiAgICAgICAgICB8IFNNRl9UWVBFICAgICAgICAgICB8CiAg ICAgICB8IGV4dGVuZGVkIHR5cGUgfCA8dGx2LXR5cGUtZXh0PiAgICAgIHwgPHJlbGF5QWxnb3Jp dGhtaWQ+IHwKICAgICAgIHwgbGVuZ3RoICAgICAgICB8IDxsZW5ndGg+ICAgICAgICAgICAgfCB2 YXJpYWJsZSAgICAgICAgICAgfAogICAgICAgfCB2YWx1ZSAgICAgICAgIHwgPHZhbHVlPiAgICAg ICAgICAgICB8IHZhcmlhYmxlICAgICAgICAgICB8CiAgICAgICArLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAg ICAgICAgICAgVGFibGUgNjogU01GIFR5cGUgTWVzc2FnZSBUTFYKCiAgIEluIFRhYmxlIDYgPHJl bGF5QWxnb3JpdGhtSWQ+IGlzIGFuIDgtYml0IGZpZWxkIAogICBjb250YWluaW5nIGEgbnVtYmVy CiAgIDAtMjU1IHJlcHJlc2VudGluZyB0aGUgIlJlbGF5IEFsZ29yaXRobSBUeXBlIiBvZiB0aGUg b3JpZ2luYXRvcgogICBhZGRyZXNzIG9mIHRoZSBjb3JyZXNwb25kaW5nIE5IRFAgbWVzc2FnZS4K CgoKTWFja2VyLCBlZGl0b3IgJiBTTUYgRGVzaWduIFRlYW0gIEV4cGlyZXMgU2VwdGVtYmVyIDcs IDIwMTAgICAgW1BhZ2UgMjNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICBT TUYgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEwCgoKICAgUG9zc2libGUgdmFsdWVz IGZvciB0aGUgPHJlbGF5QWxnb3JpdGhtSWQ+IGFyZSBkZWZpbmVkIGluIFRhYmxlIDcuCiAgIFRo ZSB0YWJsZSBwcm92aWRlcyB2YWx1ZSBhc3NpZ25tZW50cywgZnV0dXJlIElBTkEgYXNzaWdubWVu dCBzcGFjZXMsCiAgIGFuZCBhbiBleHBlcmltZW50YWwgc3BhY2UuICBUaGUgZXhwZXJpbWVudGFs IHNwYWNlIHVzZSBNVVNUIE5PVAogICBhc3N1bWUgdW5pcXVlbmVzcyBhbmQgdGh1cyBzaG91bGQg bm90IGJlIHVzZWQgZm9yIGdlbmVyYWwKICAgaW50ZXJvcGVyYWJsZSBkZXBsb3ltZW50IHByaW9y IHRvIG9mZmljaWFsIElBTkEgYXNzaWdubWVudC4KCiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgIHwgRXh0ZW5k ZWQgVHlwZSBWYWx1ZSB8ICAgICAgICAgICAgICAgIEFsZ29yaXRobSAgICAgICAgICAgICAgIHwK ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAgICAwICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgQ0YgICAgICAgICAgICAgICAgICAgfAogICAgIHwgICAgICAgICAgMSAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgUy1NUFIgICAgICAgICAgICAgICAgIHwKICAgICB8ICAgICAgICAgIDIg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgIEUtQ0RTICAgICAgICAgICAgICAgICB8CiAgICAg fCAgICAgICAgICAzICAgICAgICAgIHwgICAgICAgICAgICAgICAgIE1QUi1DRFMgICAgICAgICAg ICAgICAgfAogICAgIHwgICAgICAgIDQtMTI3ICAgICAgICB8ICAgIEZ1dHVyZSBBc3NpZ25tZW50 IHdpdGggU1REIGFjdGlvbiAgIHwKICAgICB8ICAgICAgIDEyOC0yMzkgICAgICAgfCAgICAgICAg IE5vIFNURCBhY3Rpb24gcmVxdWlyZWQgICAgICAgICB8CiAgICAgfCAgICAgICAyNDAtMjU1ICAg ICAgIHwgICAgICAgICAgIEV4cGVyaW1lbnRhbCBTcGFjZSAgICAgICAgICAgfAogICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsKCiAgICAgICAgICAgICAgICAgVGFibGUgNzogU01GIFJlbGF5IEFsZ29yaXRobSBUeXBlIFZh bHVlcwoKICAgQWNjZXB0YWJsZSA8bGVuZ3RoPiBhbmQgPHZhbHVlPiBmaWVsZHMgb2YgYW4gU01G X1RZUEUgVExWIGFyZQogICBleHRlbmRlZCB0eXBlIGRlcGVuZGVudC4gIFRoZSBhcHByb3ByaWF0 ZSBhbGdvcml0aG0gdHlwZSwgYXMgY29udmV5ZWQKICAgaW4gdGhlIDx0bHYtdHlwZS1leHQ+IGZp ZWxkLCBkZWZpbmVzIHRoZSBtZWFuaW5nIGFuZCBmb3JtYXQgb2YgaXRzCiAgIFRMViA8dmFsdWU+ IGZpZWxkLiAgRm9yIGFsZ29yaXRobXMgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50IHNlZSB0aGUK ICAgYXBwcm9wcmlhdGUgYXBwZW5kaXggZm9yIHRoZSA8dmFsdWU+IGZpZWxkIGZvcm1hdC4KVUg+ ID09PT09PT09PT09PT09PT0KVUg+IENpdGUgcHJlY2lzZSBzZWN0aW9ucyBpbiB0aGUgYXBwZW5k aXguClVIPiA9PT09PT09PT09PT09PT09CiAgIAoKNy4xLjIuICBTTUYgQWRkcmVzcyBCbG9jayBU TFYgVHlwZQoKICAgQW4gYWRkcmVzcyBibG9jayBUTFYgdHlwZSwgZGVub3RlZCBTTUZfTkJSX1RZ UEUgKGkuZS4sIFNNRiBuZWlnaGJvcgogICByZWxheSBhbGdvcml0aG0pIApVSD4gPT09PT09PT09 PT09PT09PQpVSD4gKyAiYXMgc3BlY2lmaWVkIGluICIKVUg+ID09PT09PT09PT09PT09PT0KSk0+ IEpEIGFkZGVkCiAgIFRhYmxlIDgsIGlzIHNwZWNpZmllZCBzbyB0aGF0IENEUyByZWxheSBhbGdv cml0aG0KICAgb3BlcmF0aW9uIGFuZCBjb25maWd1cmF0aW9uIGNhbiBiZSBzaGFyZWQgYW1vbmcg Mi1ob3AgbmVpZ2hib3Job29kcy4KICAgU29tZSByZWxheSBhbGdvcml0aG1zIHJlcXVpcmUgdHdv IGhvcCBuZWlnaGJvciBjb25maWd1cmF0aW9uIGluIG9yZGVyCiAgIHRvIGNvcnJlY3RseSBzZWxl Y3QgcmVsYXkgc2V0cy4gIEl0IGlzIGFsc28gdXNlZnVsIHdoZW4gbWl4ZWQgcmVsYXkKICAgYWxn b3JpdGhtIG9wZXJhdGlvbiBpcyBwb3NzaWJsZS4KICAgVGhlIG1lc3NhZ2UgU01GX1RZUEUgVExW IGFuZCBhZGRyZXNzIGJsb2NrIFNNRl9OQlJfVFlQRSBUTFYgdHlwZXMKICAgc2hhcmUgYSBjb21t b24gZm9ybWF0LgoKCk1hY2tlciwgZWRpdG9yICYgU01GIERlc2lnbiBUZWFtICBFeHBpcmVzIFNl cHRlbWJlciA3LCAyMDEwICAgIFtQYWdlIDI0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgICAgU01GICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMAoKCiAgICAgICAr LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LSsKICAgICAgIHwgICAgICAgICAgICAgICB8IHBhY2tldEJCIFRMViBzeW50YXggfCBGaWVsZCBW YWx1ZXMgICAgICAgfAogICAgICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICB8IHR5cGUgICAgICAgICAgfCA8dGx2LXR5 cGU+ICAgICAgICAgIHwgU01GX05CUl9SRUxBWV9BTEcgIHwKICAgICAgIHwgZXh0ZW5kZWQgdHlw ZSB8IDx0bHYtdHlwZS1leHQ+ICAgICAgfCA8cmVsYXlBbGdvcml0aG1pZD4gfAogICAgICAgfCBs ZW5ndGggICAgICAgIHwgPGxlbmd0aD4gICAgICAgICAgICB8IHZhcmlhYmxlICAgICAgICAgICB8 CiAgICAgICB8IHZhbHVlICAgICAgICAgfCA8dmFsdWU+ICAgICAgICAgICAgIHwgdmFyaWFibGUg ICAgICAgICAgIHwKICAgICAgICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICAgICBUYWJsZSA4OiBTTUYg VHlwZSBBZGRyZXNzIEJsb2NrIFRMVgoKICAgPHJlbGF5QWxnb3JpdGhtSWQ+IGluIFRhYmxlIDcg CiAgIGlzIGFuIDgtYml0IGZpZWxkIGNvbnRhaW5pbmcgYSBudW1iZXIKICAgMC0yNTUgcmVwcmVz ZW50aW5nIHRoZSAiUmVsYXkgQWxnb3JpdGhtIFR5cGUiIHZhbHVlIHRoYXQgY29ycmVzcG9uZHMK ICAgdG8gYW55IGluZGljYXRlZCBhZGRyZXNzIAogICBpbiB0aGUgYWRkcmVzcyBibG9jay4gIE5v dGUgdGhhdCAiUmVsYXkKICAgQWxnb3JpdGhtIFR5cGUiIHZhbHVlcyBmb3IgMi1ob3AgbmVpZ2hi b3JzIGNhbiBiZSBjb252ZXllZCBpbiBhCiAgIHNpbmdsZSBUTFYgb3IgbXVsdGlwbGUgdmFsdWUg VExWcyBhcyBkZXNjcmliZWQgaW4gW1JGQzU0NDRdLiAgSXQgaXMKICAgZXhwZWN0ZWQgdGhhdCBT TUYgbm9kZXMgdXNpbmcgTkhEUCBjb25zdHJ1Y3QgYWRkcmVzcyBibG9ja3Mgd2l0aAogICBTTUZf TkJSX1RZUEUgVExWcyB0byBhZHZlcnRpc2UgIlJlbGF5IEFsZ29yaXRobSBUeXBlIiBhbmQgdG8K ICAgYWR2ZXJ0aXNlIG5laWdoYm9yIGFsZ29yaXRobSB2YWx1ZXMgcmVjZWl2ZWQgaW4gU01GX1RZ UEUgVExWcyBmcm9tCiAgIHRob3NlIG5laWdoYm9ycy4KCiAgIEFnYWluIHZhbHVlcyBmb3IgdGhl IDxyZWxheUFsZ29yaXRobUlkPiBhcmUgZGVmaW5lZCBpbiBUYWJsZSA3LgogICBWYWx1ZSBsZW5n dGggYW5kIHZhbHVlIGNvbnRlbnQgCiAgIG9mIGFuIFNNRl9OQlJfVFlQRSBUTFYgaXMgZGVmaW5l ZCBieQogICB0aGUgYXBwcm9wcmlhdGUgYWxnb3JpdGhtIHR5cGUgY29udGFpbmVkIGluIHRoZSBl eHRlbmRlZCB0eXBlIGZpZWxkLgogICBTZWUgYXBwcm9wcmlhdGUgdGhlIGFwcGVuZGl4IGZvciBk ZWZpbml0aW9ucyBvZiB2YWx1ZSBmaWVsZHMgZm9yCiAgIGFsZ29yaXRobXMgZGVmaW5lZCBieSB0 aGlzIGRvY3VtZW50LgoKCjguICBTTUYgQm9yZGVyIEdhdGV3YXkgQ29uc2lkZXJhdGlvbnMKCiAg IEl0IGlzIGV4cGVjdGVkIHRoYXQgU01GIHdpbGwgYmUgdXNlZCB0byBwcm92aWRlIHNpbXBsZSBm b3J3YXJkaW5nIG9mCiAgIG11bHRpY2FzdCB0cmFmZmljIHdpdGhpbiBhIE1BTkVUIG9yIG1lc2gg cm91dGluZyB0b3BvbG9neS4gIEEgYm9yZGVyCiAgIHJvdXRlciBhcHByb2FjaCAKVUg+ID09PT09 PT09PT09PT09PT0KVUg+IERlZmluaXRpb24gb2YgImJvcmRlciByb3V0ZXIgYXBwcm9hY2giPwpV SD4gPT09PT09PT09PT09PT09PQogICBzaG91bGQgYmUgdXNlZCB0byBhbGxvdyBpbnRlcmNvbm5l Y3Rpb24gb2YgU01GIGFyZWFzCiAgIHdpdGggbmV0d29ya3MgdXNpbmcgb3RoZXIgbXVsdGljYXN0 IHJvdXRpbmcgcHJvdG9jb2xzIChlLmcuLCBQSU0pLgogICBJdCBpcyBpbXBvcnRhbnQgdG8gbm90 ZSB0aGF0IHRoZXJlIGFyZSBtYW55IHNjZW5hcmlvLXNwZWNpZmljIGlzc3VlcwogICB0aGF0IHNo b3VsZCBiZSBhZGRyZXNzZWQgd2hlbiBkaXNjdXNzaW5nIGJvcmRlciByb3V0ZXJzLiAgQXQgdGhl CiAgIHByZXNlbnQgdGltZSwgZXhwZXJpbWVudGFsIGRlcGxveW1lbnRzIG9mIFNNRiBhbmQgUElN IGJvcmRlciByb3V0ZXIKICAgYXBwcm9hY2hlcyBoYXZlIGJlZW4gZGVtb25zdHJhdGVkLiAgU29t ZSBvZiB0aGUgZnVuY3Rpb25hbGl0eSBib3JkZXIKICAgcm91dGVycyBtYXkgbmVlZCB0byBhZGRy ZXNzIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmc6CgogICAxLiAgRGV0ZXJtaW5pbmcgd2hpY2ggbXVs dGljYXN0IGdyb3VwIHRyYWZmaWMgdHJhbnNpdHMgdGhlIGJvcmRlcgogICAgICAgcm91dGVyIHdo ZXRoZXIgZW50ZXJpbmcgb3IgZXhpdGluZyB0aGUgYXR0YWNoZWQgTUFORVQgcm91dGluZwogICAg ICAgcmVnaW9uKHMpLgogICAyLiAgRW5mb3JjZW1lbnQgb2YgVFRMIHRocmVzaG9sZCBvciBvdGhl ciBzY29waW5nIHBvbGljaWVzLgogICAzLiAgQW55IG1hcmtpbmcgb3IgbGFiZWxpbmcgdG8gZW5h YmxlIERQRCBvbiBpbmdyZXNzaW5nIHBhY2tldHMuCgoKCgoKTWFja2VyLCBlZGl0b3IgJiBTTUYg RGVzaWduIFRlYW0gIEV4cGlyZXMgU2VwdGVtYmVyIDcsIDIwMTAgICAgW1BhZ2UgMjVdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICBTTUYgICAgICAgICAgICAgICAgICAgICAg ICBNYXJjaCAyMDEwCgoKICAgNC4gIEludGVyZmFjZSB3aXRoIGV4dGVyaW9yIG11bHRpY2FzdCBy b3V0aW5nIHByb3RvY29scy4KICAgNS4gIFBvc3NpYmxlIG9wZXJhdGlvbiB3aXRoIG11bHRpcGxl IGJvcmRlciByb3V0ZXJzIChwcmVzZW50bHkgYmV5b25kCiAgICAgICBzY29wZSBvZiB0aGlzIGRv Y3VtZW50KS4KICAgNi4gIFByb3Zpc2lvbnMgZm9yIHBhcnRpY2lwYXRpbmcgbm9uLVNNRiBub2Rl cy4KVUg+ID09PT09PT09PT09PT09PT0KVUg+IFNob3VsZCBiZSBtYWRlIGNsZWFyIHRoYXQgdGhl c2UgNiBwb2ludHMgYXJlIGV4cGxhaW5lZCBpbiBzZWN0aW9ucyBsYXRlcgpVSD4gPT09PT09PT09 PT09PT09PQpKTT4gb2sKICAgCgogICBOb3RlIHRoZSBiZWhhdmlvciBvZiBTTUYgYm9yZGVyIHJv dXRlcnMgaXMgdGhlIHNhbWUgYXMgdGhhdCBvZiBub24tCiAgIGJvcmRlciBTTUYgbm9kZXMgd2hl biBmb3J3YXJkaW5nIHBhY2tldHMgb24gaW50ZXJmYWNlcyB3aXRoaW4gdGhlCiAgIE1BTkVUIHJv dXRpbmcgcmVnaW9uLiAgUGFja2V0cyB0aGF0IGFyZSBwYXNzZWQgb3V0Ym91bmQgdG8gaW50ZXJm YWNlcwogICBvcGVyYXRpbmcgZml4ZWQtaW5mcmFzdHJ1Y3R1cmUgbXVsdGljYXN0IHJvdXRpbmcg cHJvdG9jb2xzIFNIT1VMRCBiZQogICBldmFsdWF0ZWQgZm9yIGR1cGxpY2F0ZSBwYWNrZXQgc3Rh dHVzIHNpbmNlIHByZXNlbnQgc3RhbmRhcmQKICAgbXVsdGljYXN0IGZvcndhcmRpbmcgbWVjaGFu aXNtcyBkbyBub3QgdXN1YWxseSBwZXJmb3JtIHRoaXMgZnVuY3Rpb24uCgo4LjEuICBGb3J3YXJk ZWQgTXVsdGljYXN0IEdyb3VwcwoKICAgTWVjaGFuaXNtcyBmb3IgZHluYW1pY2FsbHkgZGV0ZXJt aW5pbmcgZ3JvdXBzIGZvciBmb3J3YXJkaW5nIGludG8gYQogICBNQU5FVCBTTUYgcm91dGluZyBy ZWdpb24gaXMgYW4gZXZvbHZpbmcgdGVjaG5vbG9neSBhcmVhLiAgSWRlYWxseSwKICAgb25seSBn cm91cHMgZm9yIHdoaWNoIHRoZXJlIGlzIGFjdGl2ZSBncm91cCBtZW1iZXJzaGlwIHNob3VsZCBi ZQogICBpbmplY3RlZCBpbnRvIHRoZSBTTUYgZG9tYWluLiAgVGhpcyBjYW4gYmUgYWNjb21wbGlz aGVkIGJ5IHByb3ZpZGluZwogICBhbiBJUHY0IEludGVybmV0IEdyb3VwIE1lbWJlcnNoaXAgUHJv dG9jb2wgKElHTVApIG9yIElQVjYgTXVsdGljYXN0CiAgIExpc3RlbmVyIERpc2NvdmVyeSAoTUxE KSBwcm94eSBwcm90b2NvbCBzbyB0aGF0IE1BTkVUIFNNRiBub2RlcyBjYW4KICAgaW5mb3JtIGF0 dGFjaGVkIGJvcmRlciByb3V0ZXJzIChhbmQgaGVuY2UgbXVsdGljYXN0IG5ldHdvcmtzKSBvZgog ICB0aGVpciBjdXJyZW50IGdyb3VwIG1lbWJlcnNoaXAgc3RhdHVzLiAgRm9yIHNwZWNpZmljIHN5 c3RlbXMgYW5kCiAgIHNlcnZpY2VzIGl0IG1heSBiZSBwb3NzaWJsZSB0byBzdGF0aWNhbGx5IGNv bmZpZ3VyZSBncm91cCBtZW1iZXJzaGlwCiAgIGpvaW5zIGluIGJvcmRlciByb3V0ZXJzLCBidXQg aXQgaXMgUkVDT01NRU5ERUQgdGhhdCBzb21lIGZvcm0gb2YKICAgSUdNUC9NTEQgcHJveHkgb3Ig b3RoZXIgZXhwbGljaXQsIGR5bmFtaWMgY29udHJvbCBvZiBtZW1iZXJzaGlwIGJlCiAgIHByb3Zp ZGVkLiAgU3BlY2lmaWNhdGlvbiBvZiBzdWNoIGFuIElHTVAvTUxEIHByb3h5IHByb3RvY29sIGlz IGJleW9uZAogICB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCiAgIE91dGJvdW5kIHRyYWZm aWMgaXMgbGVzcyBwcm9ibGVtYXRpYy4gIApVSD4gPT09PT09PT09PT09PT09PQpVSD4gTGVzcyBw cm9ibGVtYXRpYyB0aGFuIHdoYXQ/ClVIPiA9PT09PT09PT09PT09PT09CkpNPiB0aGFuIGluYm91 bmQgYnV0IEkgcmVtb3ZlZCB0aGUgb2JzZXJ2YXRpb25hbCBjb21tZW50LgogICAKICAgU01GIGJv cmRlciByb3V0ZXJzIGNhbiBwZXJmb3JtCiAgIGR1cGxpY2F0ZSBwYWNrZXQgZGV0ZWN0aW9uIGFu ZCBmb3J3YXJkIG5vbi1kdXBsaWNhdGUgdHJhZmZpYyB0aGF0CiAgIG1lZXRzIFRUTC9ob3AgbGlt aXQgYW5kIHNjb3BpbmcgY3JpdGVyaWEgdG8gb3RoZXIgaW50ZXJmYWNlcy4KVUg+ID09PT09PT09 PT09PT09PT0KVUg+IE90aGVyIGludGVyZmFjZXMgdGhhbiB3aGF0PwpVSD4gPT09PT09PT09PT09 PT09PQpKTT5uZXh0IGNvbW1lbnQKICAgCiAgIEFwcHJvcHJpYXRlIElQIG11bHRpY2FzdCByb3V0 aW5nIChQSU0sIGV0Yykgb24gdGhvc2UgaW50ZXJmYWNlcyAKVUg+ID09PT09PT09PT09PT09PT0K VUg+IFdoaWNoIGFyZSAidGhvc2UiIGludGVyZmFjZXM/ClVIPiA9PT09PT09PT09PT09PT09CkpN PiBleHBsYWluZWQgdGhlIGFib3ZlIGFzIGJvcmRlciBtdWx0aWNhc3Qgcm91dGVyIGludGVyZmFj ZXMgZXh0ZXJuYWwgdG8gU01GIHJvdXRpbmcgZG9tYWluIGRlbmllZCBlYXJsaWVyLgogICAKICAg Y2FuCiAgIHRoZW4gbWFrZSBmdXJ0aGVyIGZvcndhcmRpbmcgZGVjaXNpb25zIHdpdGggcmVzcGVj dCB0byB0aGUgZ2l2ZW4KICAgdHJhZmZpYyBkZXN0aW5hdGlvbiBhbmQgcG90ZW50aWFsbHkgaXRz IApVSD4gPT09PT09PT09PT09PT09PQpVSD4gIml0cyIuLi4gd2hvc2Ugc291cmNlIGFkZHJlc3M/ ClVIPiA9PT09PT09PT09PT09PT09CkpNPiB5ZWFoIHRvbyB2YWd1ZS4KCiAgIHNvdXJjZSBhZGRy ZXNzZXMuICBOb3RlIHRoYXQKICAgdGhlIHByZXNlbmNlIG9mIG11bHRpcGxlIGJvcmRlciByb3V0 ZXJzIGFzc29jaWF0ZWQgd2l0aCBhIE1BTkVUCiAgIHJvdXRpbmcgcmVnaW9uIHJhaXNlcyBhZGRp dGlvbmFsIGlzc3Vlcy4gIFRoaXMgaXMgZnVydGhlciBkaXNjdXNzZWQKICAgaW4gU2VjdGlvbiA4 LjQgYnV0IGZ1cnRoZXIgd29yayBpcyBleHBlY3RlZCB0byBiZSBuZWVkZWQgaGVyZS4KCjguMi4g IE11bHRpY2FzdCBHcm91cCBTY29waW5nCgogICBNdWx0aWNhc3Qgc2NvcGluZyBpcyB1c2VkIGJ5 IG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgdG8gY29udHJvbCB0aGUKICAgbmV0d29yayByb3V0aW5n IHJlZ2lvbnMgcmVhY2hhYmxlIGJ5IG11bHRpY2FzdCBwYWNrZXRzLiAgVGhpcyBpcwogICB1c3Vh bGx5IGRvbmUgYnkgY29uZmlndXJpbmcgZXh0ZXJuYWwgaW50ZXJmYWNlcyBvZiBib3JkZXIgcm91 dGVycyBpbgogICB0aGUgYm9yZGVyIG9mIGFuIHJvdXRpbmcgCiAgIHJlZ2lvbiB0byBub3QgZm9y d2FyZCBtdWx0aWNhc3QgcGFja2V0cwogICB3aGljaCBtdXN0IGJlIGtlcHQgd2l0aGluIHRoZSBy b3V0aW5nIHJlZ2lvbi4gIFRoaXMgaXMgY29tbW9ubHkgZG9uZQogICBiYXNlZCBvbiBUVEwgb2Yg bWVzc2FnZXMgb3IgdGhlIGJhc2lzIG9mIGdyb3VwIGFkZHJlc3Nlcy4gIFRoZXNlCiAgIHNjaGVt ZXMgYXJlIGtub3duIHJlc3BlY3RpdmVseSBhczoKCgoKCk1hY2tlciwgZWRpdG9yICYgU01GIERl c2lnbiBUZWFtICBFeHBpcmVzIFNlcHRlbWJlciA3LCAyMDEwICAgIFtQYWdlIDI2XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgU01GICAgICAgICAgICAgICAgICAgICAgICAg TWFyY2ggMjAxMAoKCiAgIDEuICBUVEwgc2NvcGluZy4KVUg+ID09PT09PT09PT09PT09PT0KVUg+ ICsgaG9wIGxpbWl0PwpVSD4gPT09PT09PT09PT09PT09PQpKTT4geWVwLgogICAKICAgMi4gIEFk bWluaXN0cmF0aXZlIHNjb3BpbmcuCgogICBGb3IgSVB2NCwgbmV0d29yayBhZG1pbmlzdHJhdG9y cyBjYW4gY29uZmlndXJlIGJvcmRlciByb3V0ZXJzIHdpdGgKICAgdGhlIGFwcHJvcHJpYXRlIFRU TCB0aHJlc2hvbGRzIG9yIGFkbWluaXN0cmF0aXZlbHkgc2NvcGVkIG11bHRpY2FzdAogICBncm91 cHMgZm9yIHRoZSByb3V0ZXIgaW50ZXJmYWNlcyBhcyB3aXRoIGFueSB0cmFkaXRpb25hbCBtdWx0 aWNhc3QKICAgcm91dGVyLiAgSG93ZXZlciwgZm9yIHRoZSBjYXNlIG9mIFRUTCBzY29waW5nIGl0 IFNIT1VMRCBiZSB0YWtlbiBpbnRvCiAgIGFjY291bnQgdGhhdCB0aGUgcGFja2V0IGNvdWxkIHRy YXZlcnNlIG11bHRpcGxlIGhvcHMgd2l0aGluIHRoZSBNQU5FVAogICBTTUYgcm91dGluZyByZWdp b24gYmVmb3JlIHJlYWNoaW5nIHRoZSBib3JkZXIgcm91dGVyLiAgVGh1cywgVFRMCiAgIHRocmVz aG9sZHMgU0hPVUxEIGJlIHNlbGVjdGVkIGNhcmVmdWxseS4KCiAgIEZvciBJUHY2LCBtdWx0aWNh c3QgYWRkcmVzcyBzcGFjZXMgaW5jbHVkZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUKICAgc2NvcGUg b2YgdGhlIGdyb3VwLiAgVGh1cywgYm9yZGVyIHJvdXRlcnMgb2YgYW4gU01GIHJvdXRpbmcgcmVn aW9uCiAgIGtub3cgaWYgdGhleSBtdXN0IGZvcndhcmQgYSBwYWNrZXQgYmFzZWQgb24gdGhlIElQ djYgbXVsdGljYXN0IGdyb3VwCiAgIGFkZHJlc3MuICBGb3IgdGhlIGNhc2Ugb2YgSVB2NiwgaXQg aXMgUkVDT01NRU5ERUQgdGhhdCBhIE1BTkVUIFNNRgogICByb3V0aW5nIHJlZ2lvbiBiZSBkZXNp Z25hdGVkIGEgc2l0ZS4gClVIPiA9PT09PT09PT09PT09PT09ClVIPiBUaGF0IGlzIGEgYml0IHZh Z3VlLiAiZGVzaWduYXRlZCBhIHNpdGUiIChub3RlIHRoYXQgdW5pY2FzdCBzaXRlLXNjb3BlIElQ djYgYWRkcmVzc2VzIGFyZSBkZXByZWNhdGVkKS4gSSB3b3VsZCBjaGFuZ2UgdGhhdCB0byAic2l0 ZS1zY29wZSBtdWx0aWNhc3QgYWRkcmVzc2VzIFNIT1VMRCBiZSB1c2VkIGFzIGRlc3RpbmF0aW9u IG9mIElQdjYgZGF0YWdyYW1zIi4KVUg+ID09PT09PT09PT09PT09PT0KSk0+IHllYWggbWFrZSBp dCBjbGVhciBpdHMgc2l0ZS1zY29wZWQgbXVsdGljYXN0LiBCVXQgdGhhdCBJIHRoaW5rIHNob3Vs ZCBiZSBvayBhbmQgd2hhdCBhbiBTTUYgZG9tYWluIHJlYWxseSBuZWVkcy4KICAgCiAgIFRodXMs IGFsbCBJUHY2IG11bHRpY2FzdAogICBwYWNrZXRzIGluIHRoZSByYW5nZSBGRjA1OjovMTYgU0hP VUxEIGJlIGtlcHQgd2l0aGluIHRoZSBNQU5FVCBTTUYKICAgcm91dGluZyByZWdpb24gYnkgYm9y ZGVyIHJvdXRlcnMuICBJUHY2IHBhY2tldHMgaW4gYW55IG90aGVyIHdpZGVyCiAgIHJhbmdlIHNj b3BlcyAoaS5lLiAgRkYwODo6LzE2LCBGRjBCOjovMTYgYW5kIEZGMEU6OjE2KSBNQVkgdHJhdmVy c2UKICAgYm9yZGVyIHJvdXRlcnMgdW5sZXNzIG90aGVyIHJlc3RyaWN0aW9ucyBkaWZmZXJlbnQg ZnJvbSB0aGUgc2NvcGUKICAgYXBwbGllcy4KCiAgIEdpdmVuIHRoYXQgc2NvcGluZyBvZiBtdWx0 aWNhc3QgcGFja2V0cyBpcyBwZXJmb3JtZWQgYXQgdGhlIGJvcmRlcgogICByb3V0ZXJzLCBhbmQg Z2l2ZW4gdGhhdCBleGlzdGluZyBzY29waW5nIG1lY2hhbmlzbXMgYXJlIG5vdCBkZXNpZ25lZAog ICB0byB3b3JrIHdpdGggbW9iaWxlIHJvdXRlcnMsIGl0IGlzIGFzc3VtZWQgdGhhdCBub24tYm9y ZGVyIFNNRgogICByb3V0ZXJzIHdpbGwgbm90IHN0b3AgZm9yd2FyZGluZyBtdWx0aWNhc3QgZGF0 YSBwYWNrZXRzIG9mIGFuCiAgIGFwcHJvcHJpYXRlIHNpdGUgc2NvcGluZy4gIFRoYXQgaXMsIGl0 IGlzIGFzc3VtZWQgdGhhdCBhbiBTTUYgcm91dGluZwogICByZWdpb24gaXMgYSBzaXRlIHNjb3Bl ZCBhcmVhLgoKOC4zLiAgSW50ZXJmYWNlIHdpdGggRXh0ZXJpb3IgTXVsdGljYXN0IFJvdXRpbmcg UHJvdG9jb2xzCgogICBUaGUgdHJhZGl0aW9uYWwgb3BlcmF0aW9uIG9mIG11bHRpY2FzdCByb3V0 aW5nIHByb3RvY29scyBpcyB0aWdodGx5CiAgIGludGVncmF0ZWQgd2l0aCB0aGUgZ3JvdXAgbWVt YmVyc2hpcCBmdW5jdGlvbi4gClVIPiA9PT09PT09PT09PT09PT09ClVIPiBBZGQgY2l0YXRpb24/ ClVIPiA9PT09PT09PT09PT09PT09CkpNPiBwcm9iYWJsZSBEZWVyaW5nIDkwIHdvdWxkIHdvcmsu CiAgIAogICBMZWFmIHJvdXRlcnMgClVIPiA9PT09PT09PT09PT09PT09ClVIPiBEZWZpbml0aW9u IG9mICJsZWFkIHJvdXRlciI/ClVIPiA9PT09PT09PT09PT09PT09CkpNPiBpdHMgbGVhZiByb3V0 ZXIuIEVhcmx5IERlZXJpbmcgRFZNUlAgb3IgUElNIGxhdGVyLgoKICAgYXJlCiAgIGNvbmZpZ3Vy ZWQgdG8gcGVyaW9kaWNhbGx5IGdhdGhlciBncm91cCBtZW1iZXJzaGlwIGluZm9ybWF0aW9uLCB3 aGlsZQogICBpbnRlcm1lZGlhdGUgcm91dGVycyBjb25zcGlyZSB0byBjcmVhdGUgbXVsdGljYXN0 IHRyZWVzIGNvbm5lY3RpbmcKICAgcm91dGVycyB3aXRoIGRpcmVjdGx5LWNvbm5lY3RlZCBtdWx0 aWNhc3Qgc291cmNlcyBhbmQgcm91dGVycyB3aXRoCiAgIGFjdGl2ZSBtdWx0aWNhc3QgcmVjZWl2 ZXJzLiAgSW4gdGhlIGNvbmNyZXRlIGNhc2Ugb2YgU01GLCBib3JkZXIKICAgcm91dGVycyBjYW4g YmUgY29uc2lkZXJlZCBsZWFmIHJvdXRlcnMuICBNZWNoYW5pc21zIGZvciBtdWx0aWNhc3QKICAg c291cmNlcyBhbmQgcmVjZWl2ZXJzIHRvIGludGVyb3BlcmF0ZSB3aXRoIGJvcmRlciByb3V0ZXJz IG92ZXIgdGhlCiAgIG11bHRpaG9wIE1BTkVUIFNNRiByb3V0aW5nIHJlZ2lvbiBhcyBpZiB0aGV5 IHdlcmUgZGlyZWN0bHkgY29ubmVjdGVkCiAgIHRvIHRoZSByb3V0ZXIgbmVlZCB0byBiZSBkZWZp bmVkLiAgClVIPiA9PT09PT09PT09PT09PT09ClVIPiBCdXQgYXJlbid0IHRoZXkgZGlyZWN0bHkg ImNvbm5lY3RlZCIgKHdoYXRldmVyIHRoYXQgbWVhbnMpIHdpdGggdGhlIGJvcmRlciByb3V0ZXJz PwpVSD4gPT09PT09PT09PT09PT09PQogICBUaGUgZm9sbG93aW5nIGlzc3VlcyBuZWVkIHRvIGJl CiAgIGFkZHJlc3NlZDoKCiAgIDEuICBBIG1lY2hhbmlzbSBieSB3aGljaCBib3JkZXIgcm91dGVy cyBnYXRoZXIgbWVtYmVyc2hpcCBpbmZvcm1hdGlvbgogICAyLiAgQSBtZWNoYW5pc20gYnkgd2hp Y2ggbXVsdGljYXN0IHNvdXJjZXMgYXJlIGtub3duIGJ5IHRoZSBib3JkZXIKICAgICAgIHJvdXRl cgoKCgoKCk1hY2tlciwgZWRpdG9yICYgU01GIERlc2lnbiBUZWFtICBFeHBpcmVzIFNlcHRlbWJl ciA3LCAyMDEwICAgIFtQYWdlIDI3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgU01GICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMAoKCiAgIDMuICBBIG1lY2hh bmlzbSBmb3IgZXhjaGFuZ2Ugb2YgZXh0ZXJpb3Igcm91dGluZyBwcm90b2NvbCBtZXNzYWdlcwog ICAgICAgYWNyb3NzIHRoZSBNQU5FVCByb3V0aW5nIHJlZ2lvbiBpZiB0aGUgTUFORVQgcm91dGlu ZyByZWdpb24gaXMgdG8KICAgICAgIHByb3ZpZGUgdHJhbnNpdCBjb25uZWN0aXZpdHkgZm9yIG11 bHRpY2FzdCB0cmFmZmljLgoKICAgSXQgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50IHRvIGFkZHJlc3MgaW1wbGVtZW50YXRpb24KICAgc29sdXRpb25zIHRvIHRoZXNlIGlzc3Vl cy4gIEFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDguMSwgSUdNUC9NTEQKICAgcHJveHkgbWVjaGFu aXNtcyBjYW4gYmUgZGVwbG95ZWQgdG8gYWRkcmVzcyBzb21lIG9mIHRoZXNlIGlzc3Vlcy4KICAg U2ltaWxhcmx5LCBleHRlcmlvciByb3V0aW5nIHByb3RvY29sIG1lc3NhZ2VzIGNvdWxkIGJlIHR1 bm5lbGVkIG9yCiAgIGNvbnZleWVkIGFjcm9zcyB0aGUgTUFORVQgcm91dGluZyByZWdpb24uICBC dXQsIGJlY2F1c2UgTUFORVQgcm91dGluZwogICByZWdpb25zIGFyZSBtdWx0aS1ob3AgYW5kIHBv dGVudGlhbGx5IHVucmVsaWFibGUKVUg+ID09PT09PT09PT09PT09PT0KVUg+IFBsZWFzZSBzcGVj aWZpeSB3aGF0IHRoYXQgbWVhbnMsICJNQU5FVCByZWdpb25zIGFyZSBtdWx0aS1ob3AgYW5kIHBv dGVudGlhbGx5IHVucmVsaWFibGUiClVIPiBMaW5rcyBiZXR3ZWVuIHJvdXRlcnMgbWF5IGJlIHVu cmVsaWFibGUsIG5vdCBNQU5FVCByZWdpb25zICh3aGljaCBpcyB1bmRlZmluZWQpIApVSD4gPT09 PT09PT09PT09PT09PQpKTT4gZ29uZS4KCiAgICwgYXMgb3Bwb3NlZCB0byB0aGUKICAgc2luZ2xl LWhvcCBMQU4gaW50ZXJjb25uZWN0aW9uIHRoYXQgbmVpZ2hib3JpbmcgSVAgTXVsdGljYXN0IHJv dXRlcnMKICAgbWlnaHQgdHlwaWNhbGx5IGVuam95LCBhZGRpdGlvbmFsIHByb3Zpc2lvbnMgbWF5 IGJlIHJlcXVpcmVkIHRvCiAgIGFjaGlldmUgc3VjY2Vzc2Z1bCBvcGVyYXRpb24uCgogICBUaGUg bmVlZCBmb3IgdGhlIGJvcmRlciByb3V0ZXIgdG8gcmVjZWl2ZSB0cmFmZmljIGZyb20gcmVjb2du aXplZAogICBtdWx0aWNhc3Qgc291cmNlcyB3aXRoaW4gdGhlIE1BTkVUIFNNRiByb3V0aW5nIHJl Z2lvbiBpcyBpbXBvcnRhbnQgdG8KICAgYWNoaWV2ZSBhIHNtb290aCBpbnRlcndvcmtpbmcgClVI PiA9PT09PT09PT09PT09PT09ClVIPiBXaGF0IGRvZXMgInNtb290aCBpbnRlcndvcmtpbmciIG1l YW4/ClVIPiA9PT09PT09PT09PT09PT09CkpNPiBjaGFuZ2VkCiAgIHdpdGggZXhpc3Rpbmcgcm91 dGluZyBwcm90b2NvbHMuICBGb3IKICAgaW5zdGFuY2UsIFBJTS1TIHJlcXVpcmVzIHJvdXRlcnMg d2l0aCBsb2NhbGx5IGF0dGFjaGVkIG11bHRpY2FzdAogICBzb3VyY2VzIHRvIHJlZ2lzdGVyIHRo ZW0gdG8gdGhlIFJlbmRlenZvdXMgUG9pbnQgKFJQKSBzbyB0aGF0IG5vZGVzCiAgIGNhbiBqb2lu IHRoZSBtdWx0aWNhc3QgdHJlZS4gIEluIGFkZGl0aW9uLCBpZiB0aG9zZSBzb3VyY2VzIGFyZSBu b3QKICAgYWR2ZXJ0aXNlZCB0byBvdGhlciBhdXRvbm9tb3VzIHN5c3RlbXMgKEFTKSB1c2luZyBN U0RQLApVSD4gPT09PT09PT09PT09PT09PQpVSD4gTVNEUCBoYXMgbm90IGJlZW4gY2l0ZWQuIE5v ciB3YXMgUElNLVMuClVIPiA9PT09PT09PT09PT09PT09CkpNPiBXRSBzaG91bGQgZG8gc28uCiAg IHJlY2VpdmVycyBpbgogICB0aG9zZSBleHRlcm5hbCBuZXR3b3JrcyBhcmUgbm90IGFibGUgdG8g am9pbiB0aGUgbXVsdGljYXN0IHRyZWUgZm9yCiAgIHRoYXQgc291cmNlLgoKOC40LiAgTXVsdGlw bGUgQm9yZGVyIFJvdXRlcnMKCiAgIEEgTUFORVQgbWlnaHQgYmUgZGVwbG95ZWQgd2l0aCBtdWx0 aXBsZSBwYXJ0aWNpcGF0aW5nIG5vZGVzIGhhdmluZwogICBjb25uZWN0aXZpdHkgdG8gZXh0ZXJu YWwgKHRvIHRoZSBNQU5FVCksIGZpeGVkLWluZnJhc3RydWN0dXJlCiAgIG5ldHdvcmtzLiAgQWxs b3dpbmcgbXVsdGlwbGUgbm9kZXMgdG8gZm9yd2FyZCBtdWx0aWNhc3QgdHJhZmZpYyB0by8KICAg ZnJvbSB0aGUgTUFORVQgcm91dGluZyByZWdpb24gY2FuIGJlIGJlbmVmaWNpYWwgc2luY2UgaXQg Y2FuIGluY3JlYXNlCiAgIHJlbGlhYmlsaXR5LCBhbmQgcHJvdmlkZSBiZXR0ZXIgc2VydmljZS4g IEZvciBleGFtcGxlLCBpZiB0aGUgTUFORVQKICAgcm91dGluZyByZWdpb24gd2VyZSB0byBmcmFn bWVudCB3aXRoIGRpZmZlcmVudCBNQU5FVCBub2RlcwogICBtYWludGFpbmluZyBjb25uZWN0aXZp dHkgdG8gZGlmZmVyZW50IGJvcmRlciByb3V0ZXJzLCBtdWx0aWNhc3QKICAgc2VydmljZSBjb3Vs ZCBzdGlsbCBjb250aW51ZSBzdWNjZXNzZnVsbHkuICBCdXQsIHRoZSBjYXNlIG9mIG11bHRpcGxl CiAgIGJvcmRlciByb3V0ZXJzIGNvbm5lY3RpbmcgYSBNQU5FVCByb3V0aW5nIHJlZ2lvbiB0byBl eHRlcm5hbCBuZXR3b3JrcwogICBwcmVzZW50cyBzZXZlcmFsIGNoYWxsZW5nZXMgZm9yIFNNRjoK CiAgIDEuICBEZXRlY3Rpb24vaGFzaCBjb2xsaXNpb24vc2VxdWVuY2luZyAKVUg+ID09PT09PT09 PT09PT09PT0KVUg+IEJldHRlciBtYWtlIGEgcmVhbCBzZW50ZW5jZSBvdXQgb2YgdGhlc2UgdHdv IC8KVUg+ID09PT09PT09PT09PT09PT0KSk0+IHJpZ2h0LgogICAKICAgb2YgZHVwbGljYXRlIHVu bWFya2VkIElQdjQgb3IKICAgICAgIElQdjYgKHdpdGhvdXQgSVBTZWMgZW5jYXBzdWxhdGlvbiBv ciBEUEQgb3B0aW9uKSBwYWNrZXRzIHBvc3NpYmx5CiAgICAgICBpbmplY3RlZCBieSBtdWx0aXBs ZSBib3JkZXIgcm91dGVycy4KICAgMi4gIFNvdXJjZS1iYXNlZCByZWxheSBhbGdvcml0aG1zIGhh bmRsaW5nIG9mIGR1cGxpY2F0ZSB0cmFmZmljCiAgICAgICBpbmplY3RlZCBieSBtdWx0aXBsZSBi b3JkZXIgcm91dGVycy4KICAgMy4gIERldGVybWluYXRpb24gb2Ygd2hpY2ggYm9yZGVyIHJvdXRl cihzKSB3aWxsIGZvcndhcmQgb3V0Ym91bmQKICAgICAgIG11bHRpY2FzdCB0cmFmZmljLgogICA0 LiAgQWRkaXRpb25hbCBjaGFsbGVuZ2VzIHdpdGggaW50ZXJmYWNlcyB0byBleHRlcmlvciBtdWx0 aWNhc3QKICAgICAgIHJvdXRpbmcgcHJvdG9jb2xzLgoKICAgT25lIG9mIHRoZSBtb3N0IG9idmlv dXMgaXNzdWVzIApVSD4gPT09PT09PT09PT09PT09PQpVSD4gTm90IHNjaWVudGlmaWMgbGFuZ3Vh Z2UKVUg+ID09PT09PT09PT09PT09PT0KSk0+IGZpeGVkLgogICAKICAgaXMgd2hlbiBtdWx0aXBs ZSBib3JkZXIgcm91dGVycyBhcmUKCgoKTWFja2VyLCBlZGl0b3IgJiBTTUYgRGVzaWduIFRlYW0g IEV4cGlyZXMgU2VwdGVtYmVyIDcsIDIwMTAgICAgW1BhZ2UgMjhdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICAgICBTTUYgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEw CgoKICAgcHJlc2VudCBhbmQgbWF5IGJlIGFsdGVybmF0aXZlbHkgKGR1ZSB0byByb3V0ZSBjaGFu Z2VzKSBvcgogICBzaW11bHRhbmVvdXNseSBpbmplY3RpbmcgY29tbW9uIHRyYWZmaWMgaW50byB0 aGUgTUFORVQgcm91dGluZyByZWdpb24KICAgdGhhdCBoYXMgbm90IGJlZW4gcHJldmlvdXNseSBt YXJrZWQgZm9yIFNNRiBEUEQuICBEaWZmZXJlbnQgYm9yZGVyCiAgIHJvdXRlcnMgd291bGQgbm90 IGJlIGFibGUgdG8gaW1wbGljaXRseSBzeW5jaHJvbml6ZSBzZXF1ZW5jaW5nIG9mCiAgIGluamVj dGVkIHRyYWZmaWMgc2luY2UgdGhleSBtYXkgbm90IHJlY2VpdmUgZXhhY3RseSB0aGUgc2FtZSBt ZXNzYWdlcwogICBkdWUgdG8gcGFja2V0IGxvc3Nlcy4gIEZvciBJUHY2IEktRFBEIG9wZXJhdGlv biwgdGhlIG9wdGlvbmFsCiAgICJUYWdnZXJJZCIgZmllbGQgZGVzY3JpYmVkIGZvciB0aGUgU01G LURQRCBoZWFkZXIgb3B0aW9uIGNhbiBiZSB1c2VkCiAgIHRvIG1pdGlnYXRlIHRoaXMgaXNzdWUu ICBXaGVuIG11bHRpcGxlIGJvcmRlciByb3V0ZXJzIGFyZSBpbmplY3RpbmcgYQogICBmbG93IGlu dG8gYSBNQU5FVCByb3V0aW5nIHJlZ2lvbiwgdGhlcmUgYXJlIHR3byBmb3J3YXJkaW5nIHBvbGlj aWVzCiAgIHRoYXQgU01GIEktRFBEIG5vZGVzIG1heSBpbXBsZW1lbnQ6ClVIPiA9PT09PT09PT09 PT09PT09ClVIPiAicm91dGVycyBydW5uaW5nIFNNRiBpbiBJLURQRCBtb2RlIiBpbnN0ZWFkIG9m ICJTTUYgSS1EUEQgbm9kZSIKVUg+ID09PT09PT09PT09PT09PT0KSk0+b2sKICAgCgogICAxLiAg UmVkdW5kYW50bHkgZm9yd2FyZCB0aGUgbXVsdGljYXN0IGZsb3dzIChpZGVudGlmaWVkIGJ5CiAg ICAgICA8c291cmNlQWRkcmVzczpkZXN0aW5hdGlvbkFkZHJlc3M+KSBmcm9tIGVhY2ggYm9yZGVy IHJvdXRlciwKICAgICAgIHBlcmZvcm1pbmcgRFBEIHByb2Nlc3Npbmcgb24gYSA8dGFnZ2VySUQ6 ZGVzdGluYXRpb25BZGRyZXNzPiBvcgogICAgICAgPHRhZ2dlcklEOnNvdXJjZUFkZHJlc3M6ZGVz dGluYXRpb25BZGRyZXNzPiBiYXNpcywgb3IKICAgMi4gIFVzZSBzb21lIGJhc2lzIHRvIHNlbGVj dCB0aGUgZmxvdyBvZiBvbmUgdGFnZ2VyIChib3JkZXIgcm91dGVyKQogICAgICAgb3ZlciB0aGUg b3RoZXJzIGFuZCBmb3J3YXJkIHBhY2tldHMgZm9yIGFwcGxpY2FibGUgZmxvd3MKICAgICAgIChp ZGVudGlmaWVkIGJ5IDxzb3VyY2VBZGRyZXNzOmRlc3RpbmF0aW9uQWRkcmVzcz4pIG9ubHkgZm9y IHRoYXQKICAgICAgICJUYWdnZXIgSUQiIHVudGlsIHRpbWVvdXQgb3Igc29tZSBvdGhlciBjcml0 ZXJpYSB0byBmYXZvciBhbm90aGVyCiAgICAgICB0YWdnZXIgb2NjdXJzLgogICBJdCBpcyBSRUNP TU1FTkRFRCB0aGF0IHRoZSBmaXJzdCBhcHByb2FjaCBiZSB1c2VkIGluIHRoZSBjYXNlIG9mCiAg IEktRFBEIG9wZXJhdGlvbiB1bmxlc3MgdGhlIFNNRiBzeXN0ZW0gClVIPiA9PT09PT09PT09PT09 PT09ClVIPiBEZWZpbml0aW9uIG9mICJTTUYgc3lzdGVtIj8KVUg+ID09PT09PT09PT09PT09PT0K Sk0+IG9uIHJldmlldyB0aGF0IHBhcnQgb2YgdGhlIHNlbnRlbmNlIHJlYWxseSBpc24ndCBuZWVk ZWQgaXRzIGdvbmUuCiAgIAogICBpcyBzcGVjaWZpY2FsbHkgZGVzaWduZWQgdG8KICAgaW1wbGVt ZW50IHRoZSBzZWNvbmQgb3B0aW9uLiAgQWRkaXRpb25hbCBzcGVjaWZpY2F0aW9uIG1heSBiZQog ICByZXF1aXJlZCB0byBkZXNjcmliZSBhbiBpbnRlcm9wZXJhYmxlIGZvcndhcmRpbmcgcG9saWN5 IGJhc2VkIG9uIHRoaXMKICAgc2Vjb25kIG9wdGlvbi4gIE5vdGUgdGhhdCB0aGUgaW1wbGVtZW50 YXRpb24gb2YgdGhlIHNlY29uZCBvcHRpb24KICAgcmVxdWlyZXMgdGhhdCBwZXItZmxvdyAoaS5l LiwgPHNvdXJjZUFkZHJlc3M6OmRlc3RpbmF0aW9uQWRkcmVzcz4pCiAgIHN0YXRlIGJlIG1haW50 YWluZWQgZm9yIHRoZSBzZWxlY3RlZCAiVGFnZ2VyIElEIi4KCiAgIFRoZSBkZXBsb3ltZW50IG9m IGEgSC1EUEQgb3BlcmF0aW9uYWwgbW9kZSBtYXkgYWxsZXZpYXRlIERQRAogICByZXNvbHV0aW9u IHdoZW4gaW5ncmVzc2luZyB0cmFmZmljIGNvbWVzIGZyb20gbXVsdGlwbGUgYm9yZGVyCiAgIHJv dXRlcnMuICBOb24tY29sbGlkaW5nIGhhc2ggaW5kZXhlcyAodGhvc2Ugbm90IHJlcXVpcmluZyB0 aGUgSC1EUEQKICAgb3B0aW9ucyBoZWFkZXIgaW4gSVB2Nikgc2hvdWxkIGJlIHJlc29sdmVkIGVm ZmVjdGl2ZWx5LgoKCkpNPiBJIGFtIGR1bXBpbmcgdGhpcyB3aG9sZSBzZWN0aW9ucy4gSXRzIGRp c2N1c3Npb24gb3JpZW50ZWQgb24gYSBzaWRlIHRvcGljLgphbmQgbm90IHRvbyByZWxldmFudCB0 byB0aGUgc3BlYy4gT3RoZXIgdXNlIGNhc2UgZG9jdW1lbnRzIGNvdWxkIGJlIHdyaXR0ZW4uCgo5 LiAgTm9uLVNNRiBNQU5FVCBOb2RlIEludGVyYWN0aW9uCgogICBUaGVyZSBtYXkgYmUgc2NlbmFy aW9zIGluIHdoaWNoIHNvbWUgbmVpZ2hib3Jpbmcgd2lyZWxlc3MgTUFORVQgbm9kZQogICBhcmUg bm90IHJ1bm5pbmcgU01GIGFuZC9vciBub3QgZm9yd2FyZGluZywgYnV0IGFyZSBpbnRlcmVzdGVk IGluCiAgIHJlY2VpdmluZyBtdWx0aWNhc3QgZGF0YS4gIEZvciBleGFtcGxlLCBhIE1BTkVUIHNl cnZpY2UKVUg+ID09PT09PT09PT09PT09PT0KVUg+IERlZmluaXRpb24gb2YgIk1BTkVUIHNlcnZp Y2UiPwpVSD4gPT09PT09PT09PT09PT09PQogICAKICAgbWlnaHQgYmUKICAgZGVwbG95ZWQgdGhh dCBpcyBhY2Nlc3NpYmxlIHRvIHdpcmVsZXNzIGVkZ2UgZGV2aWNlcyAKVUg+ID09PT09PT09PT09 PT09PT0KVUg+IERlZmluaXRpb24gb2YgIndpcmVsZXNzIGVkZ2UgZGV2aWNlcyI/ClVIPiA9PT09 PT09PT09PT09PT09CiAgIAogICB0aGF0IGRvIG5vdAogICBwYXJ0aWNpcGF0ZSBpbiBNQU5FVCBy b3V0aW5nLCBOSERQLCBhbmQvb3IgU01GIGZvcndhcmRpbmcgb3BlcmF0aW9uLgogICBUaGVzZSBk ZXZpY2VzIGluY2x1ZGU6CgogICAxLiAgRGV2aWNlcyB0aGF0IG9wcG9ydHVuaXN0aWNhbGx5IHJl Y2VpdmUgbXVsdGljYXN0IHRyYWZmaWMgZHVlIHRvCiAgICAgICBwcm94aW1pdHkgd2l0aCBTTUYg cmVsYXlzIChwb3NzaWJseSB3aXRoIGFzeW1tZXRyaWMgSVAKICAgICAgIGNvbm5lY3Rpdml0eSAK VUg+ID09PT09PT09PT09PT09PT0KVUg+IERlZmluaXRpb24gb2YgImFzeW1tZXRyaWMgSVAgY29u bmVjdGl2aXR5Ij8KVUg+ID09PT09PT09PT09PT09PT0KICAgICAgIAogICAgICAgZS5nLiwgc2Vu c29yIG5ldHdvcmsgZGV2aWNlKS4KCgoKCgpNYWNrZXIsIGVkaXRvciAmIFNNRiBEZXNpZ24gVGVh bSAgRXhwaXJlcyBTZXB0ZW1iZXIgNywgMjAxMCAgICBbUGFnZSAyOV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgICAgIFNNRiAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIw MTAKCgogICAyLiAgRGV2aWNlcyB0aGF0IHBhcnRpY2lwYXRlIGluIE5IRFAgKGRpcmVjdGx5IG9y IHZpYSByb3V0aW5nCiAgICAgICBwcm90b2NvbCBzaWduYWxpbmcpCiAgICAgICBidXQgZG8gbm90 IGZvcndhcmQgdHJhZmZpYy4KCiAgIE5vdGUgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIG9mIHRyYWZm aWMgZGVsaXZlcnkgd2l0aCBjYXRlZ29yeSAxIGFib3ZlLAogICBidXQgdGhlIGVsZWN0aW9uIGhl dXJpc3RpY3Mgc2hvd24gaW4gRmlndXJlIDQgTUFZIGJlIGFkanVzdGVkIHZpYQogICBtYW5hZ2Vt ZW50IHRvIGJldHRlciBzdXBwb3J0IHN1Y2ggZGV2aWNlcy4gIEhvd2V2ZXIsIGl0IGlzCiAgIFJF Q09NTUVOREVEIHRoYXQgbm9kZXMgcGFydGljaXBhdGUgaW4gTkhEUCB3aGVuIHBvc3NpYmxlLiAg CiAgIFN1Y2ggZGV2aWNlcyAKCiAgIG1heSBhbHNvIHRyYW5zbWl0IG11bHRpY2FzdCB0cmFmZmlj LCBidXQgaXQgaXMgaW1wb3J0YW50IHRvCiAgIG5vdGUgdGhhdCBTTUYgcm91dGluZyByZWdpb25z IHVzaW5nIHNvdXJjZS1zcGVjaWZpYyByZWxheSBzZXQKICAgYWxnb3JpdGhtcyBzdWNoIGFzIChT LU1QUikgbWF5IG5vdCBmb3J3YXJkIHN1Y2ggdHJhZmZpYy4gIFRoZXNlCiAgIGRldmljZXMgU0hP VUxEIGFsc28gbGlzdGVuIGZvciBhbnkgSUdNUC9NTEQgUXVlcmllcyB0aGF0IGFyZSBwcm92aWRl ZAogICBhbmQgdHJhbnNtaXQgSUdNUC9NTEQgUmVwb3J0cyAKVUg+ID09PT09PT09PT09PT09PT0K VUg+IERlZmluaXRpb24gb2YgIklHTVAgUXVlcmllcywgSUdNUCBSZXBvcnRzIj8KVUg+ID09PT09 PT09PT09PT09PT0KCiAgIGZvciBncm91cHMgdGhleSBoYXZlIGpvaW5lZCBwZXIgdXN1YWwKICAg SVAgTXVsdGljYXN0IG9wZXJhdGlvbi4gIFdoaWxlIGl0IGlzIG5vdCBpbiB0aGUgc2NvcGUgb2Yg dGhpcwogICBkb2N1bWVudCwgSUdNUC9NTEQgcHJveHkgbWVjaGFuaXNtcyBtYXkgYmUgaW4gcGxh Y2UgdG8gY29udmV5IGdyb3VwCiAgIG1lbWJlcnNoaXAgaW5mb3JtYXRpb24gdG8gYW55IGJvcmRl ciByb3V0ZXJzIG9yIGludGVybWVkaWF0ZSBzeXN0ZW1zCiAgIHByb3ZpZGluZyBJUCBNdWx0aWNh c3Qgcm91dGluZyBmdW5jdGlvbnMuCgoKMTAuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAg R3JhdHVpdG91cyB1c2Ugb2Ygb3B0aW9uIGhlYWRlcnMgY2FuIGNhdXNlIHByb2JsZW1zIGluIHJv dXRlcnMuCiAgIFJvdXRlcnMgb3V0c2lkZSBvZiBNQU5FVCByb3V0aW5nIHJlZ2lvbnMgClVIPiA9 PT09PT09PT09PT09PT09ClVIPiBEZWZpbml0aW9uIG9mICJyb3V0ZXJzIG91dHNpZGUgb2YgTUFO RVQgcm91dGluZyByZWdpb24iPwpVSD4gPT09PT09PT09PT09PT09PQoKCgogICBzaG91bGQgaWdu b3JlIFNNRi1zcGVjaWZpYwogICBoZWFkZXIgb3B0aW9ucyBpZiBlbmNvdW50ZXJlZC4gIFRoZSBo ZWFkZXIgb3B0aW9ucyB0eXBlcyBhcmUgZW5jb2RlZAogICBhcHByb3ByaWF0ZWx5IHRvIGFsbG93 IGZvciB0aGlzIGJlaGF2aW9yLgoKICAgU2V2ZXJhbCBTTUYgRG9TIHNjZW5hcmlvcyBoYXZlIGJl ZW4gZGVzY3JpYmVkIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50CiAgIGFuZCByZWNvbW1lbmRlZCBt aXRpZ2F0aW9uIHN0cmF0ZWdpZXMgaGF2ZSBiZWVuIHByZXNlbnRlZC4gIEhlcmUgd2UKICAgc3Vt bWFyaXplIGEgZmV3IG9mIHRoZXNlIGFyZWFzIGZvciByZWZlcmVuY2UuCgogICBTZXF1ZW5jZS1i YXNlZCBwYWNrZXQgaWRlbnRpZmllcnMgYXJlIHByZWRpY3RhYmxlIGFuZCB0aHVzIHByb3ZpZGUg YW4KICAgb3Bwb3J0dW5pdHkgZm9yIGEgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrIGFnYWluc3Qg Zm9yd2FyZGluZy4gIFRoZQogICB1c2Ugb2YgdGhlICJpbnRlcm5hbCBoYXNoaW5nIiBhcyBkZXNj cmliZWQgaW4gU2VjdGlvbiA1LjMgZm9yIHRoZQogICBJLURQRCBvcGVyYXRpb24gaGVscHMgdG8g bWl0aWdhdGUgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrcyBvbgogICBwcmVkaWN0YWJsZSBwYWNr ZXQgaWRlbnRpZmllcnMuICBJbiB0aGlzIGNhc2UsIHNwb29mZWQgcGFja2V0cyBNQVkgYmUKICAg Zm9yd2FyZGVkIGJ1dCB0aGUgYWRkaXRpb25hbCBpbnRlcm5hbCBoaXN0b3J5IGlkZW50aWZpZXIg d2lsbCBwcm90ZWN0CiAgIGFnYWluc3QgZmFsc2UgY29sbGlzaW9uIGV2ZW50cyB0aGF0IG1heSBy ZXN1bHQgZnJvbSBhIHByZWRpY3RpdmUKICAgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrIHN0cmF0 ZWd5LgoKICAgQW5vdGhlciBwb3RlbnRpYWwgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrIGFnYWlu c3QgU01GIGZvcndhcmRpbmcgaXMKICAgcG9zc2libGUgd2hlbiBhIG1hbGljaW91cyBub2RlIGhh cyBhIGZvcm0gb2YgIndvcm1ob2xlIiBhY2Nlc3MgKHZpYSBhCiAgIGRpcmVjdGlvbmFsIGFudGVu bmEsIGV0YykgClVIPiA9PT09PT09PT09PT09PT09ClVIPiBEZWZpbml0aW9uIG9mIHdob3JtaG9s ZT8gc291bmRzIGZvciBtZSBsaWtlIGEgIm5vcm1hbCIgbGluayB3aXRoIGxvd2VyIFJUVHMvZGVs YXlzLi4uClVIPiA9PT09PT09PT09PT09PT09CkpNPiByZXdyaXR0ZW4gYSBsaXR0bGUuCiAgIAog ICB0byBwcmV2aWV3IHBhY2tldHMgYmVmb3JlIGEgcGFydGljdWxhciBTTUYKICAgbm9kZSB3b3Vs ZCByZWNlaXZlIHRoZW0uICBUaGUgbWFsaWNpb3VzIG5vZGUgY291bGQgcmVkdWNlIHRoZSBUVEwg b3IKICAgSG9wIExpbWl0IG9mIHRoZSBwYWNrZXQgYW5kIHRyYW5zbWl0IGl0IHRvIHRoZSBTTUYg bm9kZSBjYXVzaW5nIGl0IHRvCiAgIGZvcndhcmQgdGhlIHBhY2tldCB3aXRoIGEgbGltaXRlZCBU VEwgKG9yIGV2ZW4gZHJvcCBpdCkgYW5kIG1ha2UgYQogICBEUEQgZW50cnkgdGhhdCB3b3VsZCBi bG9jayBmb3J3YXJkaW5nIG9mIHRoZSBzdWJzZXF1ZW50bHktYXJyaXZpbmcKICAgdmFsaWQgcGFj a2V0IHdpdGggYXBwcm9wcmlhdGUgVFRMIHZhbHVlLiAgVGhpcyB3b3VsZCBiZSBhIHJlbGF0aXZl bHkKICAgbG93LWNvc3QsIGhpZ2gtcGF5b2ZmIGF0dGFjayB0aGF0IHdvdWxkIGJlIGhhcmQgdG8g ZGV0ZWN0IGFuZCB0aHVzCiAgIGF0dHJhY3RpdmUgdG8gcG90ZW50aWFsIGF0dGFja2Vycy4gIEFu IGFwcHJvYWNoIG9mIGNhY2hpbmcgVFRMCgoKCk1hY2tlciwgZWRpdG9yICYgU01GIERlc2lnbiBU ZWFtICBFeHBpcmVzIFNlcHRlbWJlciA3LCAyMDEwICAgIFtQYWdlIDMwXQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICAgICAgU01GICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2gg MjAxMAoKCiAgIGluZm9ybWF0aW9uIHdpdGggRFBEIHN0YXRlIGFuZCB0YWtpbmcgYXBwcm9wcmlh dGUgZm9yd2FyZGluZyBhY3Rpb25zCiAgIGlzIGlkZW50aWZpZWQgaW4gU2VjdGlvbiA0IHRvIG1p dGlnYXRlIHRoaXMgZm9ybSBvZiBhdHRhY2suCgogICBUaGUgc3VwcG9ydCBvZiBmb3J3YXJkaW5n IElQU2VjIGRhdGFncmFtcyB3aXRob3V0IGZ1cnRoZXIKICAgbW9kaWZpY2F0aW9uIGZvciBib3Ro IElQdjQgYW5kIElQdjYgaXMgc3VwcG9ydGVkIGJ5IHRoaXMKICAgc3BlY2lmaWNhdGlvbi4KCiAg IEF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgdG8gaWRlbnRpZnkgdGhlIHNvdXJjZSBvZiBJUHY2 IG9wdGlvbgogICBoZWFkZXJzIHNob3VsZCBiZSBjb25zaWRlcmVkIHRvIHJlZHVjZSB2dWxuZXJh YmlsaXR5IHRvIGEgdmFyaWV0eSBvZgogICBhdHRhY2tzLgoKCjExLiAgSUFOQSBDb25zaWRlcmF0 aW9ucwoKICAgVGhpcyBkb2N1bWVudCByYWlzZXMgbXVsdGlwbGUgSUFOQSBDb25zaWRlcmF0aW9u cy4gIFRoZXNlIGluY2x1ZGUgdGhlCiAgIElQdjYgU01GX0RQRCBob3AtYnktaG9wIEhlYWRlciBF eHRlbnNpb24gZGVmaW5lZCBhbmQgbXVsdGlwbGUgVHlwZS0KICAgTGVuZ3RoLVZhbHVlIChUTFYp IGNvbnN0cnVjdHMgKHNlZSBbUkZDNTQ0NF0pIHVzZWQgdG8gZXh0ZW5kIE5IRFAKICAgb3BlcmF0 aW9uIGFzIG5lZWRlZCB0byBzdXBwb3J0IGRpZmZlcmVudCBmb3JtcyBvZiBTTUYgb3BlcmF0aW9u LgoKMTEuMS4gIElQdjYgU01GX0RQRCBIZWFkZXIgRXh0ZW5zaW9uCgogICBUaGlzIGRvY3VtZW50 IHJlcXVlc3RzIElBTkEgYXNzaWdubWVudCBvZiB0aGUgIlNNRl9EUEQiIGhvcC1ieS1ob3AKICAg b3B0aW9uIHR5cGUgZnJvbSB0aGUgSUFOQSAiSVB2NiBIb3AtYnktSG9wIE9wdGlvbnMgT3B0aW9u IFR5cGUiCiAgIHJlZ2lzdHJ5IChzZWUgU2VjdGlvbiA1LjUgb2YgW1JGQzI3ODBdKS4KCiAgIFRo ZSBmb3JtYXQgb2YgdGhpcyBuZXcgb3B0aW9uIHR5cGUgaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g NS4xLjEuICBBCiAgIHBvcnRpb24gb2YgdGhlIG9wdGlvbiBkYXRhIGNvbnRlbnQgaXMgdGhlICJ0 YWdnZXJJZFR5cGUiIHRoYXQKICAgcHJvdmlkZXMgYSBjb250ZXh0IGZvciB0aGUgInRhZ2dlcklk IiB0aGF0IGlzIG9wdGlvbmFsbHkgaW5jbHVkZWQgdG8KICAgaWRlbnRpZnkgdGhlIGludGVybWVk aWF0ZSBzeXN0ZW0gClVIPiA9PT09PT09PT09PT09PT09ClVIPiBEZWZpbml0aW9uIG9mICJpbnRl cm1lZGlhdGUgc3lzdGVtIj8gRGlmZmVyZW5jZSB0byAiaW50ZXJtZWRpYXRlIHJvdXRlciI/ClVI PiA9PT09PT09PT09PT09PT09CkpNPiBvawogICAKICAgdGhhdCBhZGRlZCB0aGUgU01GX0RQRCBv cHRpb24gdG8gdGhlCiAgIHBhY2tldC4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5hbWUtc3Bh Y2UgZm9yIElQdjYgU01GX0RQRCBUYWdnZXIKICAgSWRlbnRpZmllciBUeXBlczoKICAgICAgICAg ICAgICAgICAgICAgICAgaWV0ZjptYW5ldDpzbWY6dGFnZ2VySWRUeXBlcwoKCiAgIFtOSERQXSAg ICAgQ2xhdXNlbiwgVC4gYW5kIGV0IGFsLCAiTUFORVQgTmVpZ2hib3Job29kIERpc2NvdmVyeQog ICAgICAgICAgICAgIFByb3RvY29sIiwgZHJhZnQtaWV0Zi1tYW5ldC1uaGRwLTExLCBXb3JrIGlu IHByb2dyZXNzICwKVUg+ID09PT09PT09PT09PT09PT0KVUg+IFNldmVyYWwgdGltZXMgaW4gY2l0 YXRpb25zIHRoZXJlIGFyZSBhZGRpdGlvbmFsIGJsYW5rcyAoZS5nLiBoZXJlIGJlZm9yZSB0aGUg Y29tbWEpLiBOSERQIGlzIGluIHZlcnNpb24gMTQgbm93ClVIPiA9PT09PT09PT09PT09PT09CkpN PiBXZWxsIGl0cyBSRkM2MTMwIG5vdyBhbmQgcmVmbGVjdGVkIGluIHYxMQogICAgICAgICAgICAg IAogICAgICAgICAgICAgIE9jdG9iZXIgMjAwOS4KCgoKCk1hY2tlciwgZWRpdG9yICYgU01GIERl c2lnbiBUZWFtICBFeHBpcmVzIFNlcHRlbWJlciA3LCAyMDEwICAgIFtQYWdlIDMzXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgU01GICAgICAgICAgICAgICAgICAgICAgICAg TWFyY2ggMjAxMAoKCiAgIFtPTFNSdjJdICAgQ2xhdXNlbiwgVC4gYW5kIGV0IGFsLCAiT3B0aW1p emVkIExpbmsgU3RhdGUgUm91dGluZwogICAgICAgICAgICAgIFByb3RvY29sIHZlcnNpb24gMiIs IGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLTEwLCBXb3JrIGluCiAgICAgICAgICAgICAgcHJvZ3Jl c3MgLCBTZXB0ZW1iZXIgMjAwOS4KVUg+ID09PT09PT09PT09PT09PT0KVUg+IE9MU1J2Mi0xMS4g SXMgT0xTUiBhbmQgT0xTUnYyIHJlYWxseSBub3JtYXRpdmU/ClVIPiA9PT09PT09PT09PT09PT09 CkpNPiBXZWxsIGFzIGEgZ29vZCByZWYgZm9yIHRoZSBTLU1QUiByZWxheSBzZXQgZWxlY3Rpb24g eWVzLgoKICAgW1JGQzA3OTFdICBQb3N0ZWwsIEouLCAiSW50ZXJuZXQgUHJvdG9jb2wiLCBTVEQg NSwgUkZDIDc5MSwKICAgICAgICAgICAgICBTZXB0ZW1iZXIgMTk4MS4KCiAgIFtSRkMxMzIxXSAg Uml2ZXN0LCBSLiwgIlRoZSBNRDUgTWVzc2FnZS1EaWdlc3QgQWxnb3JpdGhtIiwgUkZDIDEzMjEs CiAgICAgICAgICAgICAgQXByaWwgMTk5Mi4KCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJL ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWly ZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkMyNDM0 XSAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcg YW4KICAgICAgICAgICAgICBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcyIsIEJD UCAyNiwgUkZDIDI0MzQsCiAgICAgICAgICAgICAgT2N0b2JlciAxOTk4LgoKICAgW1JGQzI0NjBd ICBEZWVyaW5nLCBTLiBhbmQgUi4gSGluZGVuLCAiSW50ZXJuZXQgUHJvdG9jb2wsIFZlcnNpb24g NgogICAgICAgICAgICAgIChJUHY2KSBTcGVjaWZpY2F0aW9uIiwgUkZDIDI0NjAsIERlY2VtYmVy IDE5OTguCgogICBbUkZDMjY0NF0gIFNlbmllLCBELiwgIkNoYW5naW5nIHRoZSBEZWZhdWx0IGZv ciBEaXJlY3RlZCBCcm9hZGNhc3RzCiAgICAgICAgICAgICAgaW4gUm91dGVycyIsIEJDUCAzNCwg UkZDIDI2NDQsIEF1Z3VzdCAxOTk5LgoKICAgW1JGQzI3ODBdICBCcmFkbmVyLCBTLiwgIklBTkEg QWxsb2NhdGlvbiBHdWlkZWxpbmVzIEZvciBWYWx1ZXMgSW4gdGhlCiAgICAgICAgICAgICAgSW50 ZXJuZXQgUHJvdG9jb2wgYW5kIFJlbGF0ZWQgSGVhZGVycyIsIE1hcmNoIDIwMDAuCgogICBbUkZD MzYyNl0gIENsYXVzZW4sIFQuIGFuZCBQLiBKYWNxdWV0LCAiT3B0aW1pemVkIExpbmsgU3RhdGUg Um91dGluZwogICAgICAgICAgICAgIFByb3RvY29sIiwgMjAwMy4KCiAgIFtSRkM0MzAyXSAgS2Vu dCwgUy4sICJJUCBBdXRoZW50aWNhdGlvbiBIZWFkZXIiLCBEZWNlbWJlciAyMDA1LgoKICAgW1JG QzU0NDRdICBDbGF1c2VuLCBULiBhbmQgZXQgYWwsIApVSD4gPT09PT09PT09PT09PT09PQpVSD4g YW5kIGV0IGFsIGlzIGRvdWJsZSBkb3VibGUuLi4KVUg+ID09PT09PT09PT09PT09PT0KSk0+IGF3 ZXNvbWUgYXdlc29tZSBmaW5kIDstKSBJIG1lYW50IHRvIHByb3Blcmx5IHVwZGF0ZSB0aGVzZSBS RkMgcmVmcyBmcm9tIGJpYnhtbC4KCiAgICJHZW5lcmFsaXplZCBNQU5FVCBQYWNrZXQvTWVzc2Fn ZQogICAgICAgICAgICAgIEZvcm1hdCIsIFJGQyA1NDQ0LCBGZWJydWFyeSAyMDA5LgoKMTMuMi4g IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtHTTk5XSAgICAgR2FyY2lhLUx1bmEtQWNldmVz LCBKSi4gYW5kIEUuIE1hZHJ1Z2EsICJUaGUgY29yZS1hc3Npc3RlZAogICAgICAgICAgICAgIG1l c2ggcHJvdG9jb2wiLCBTZWxlY3RlZCBBcmVhcyBpbiBDb21tdW5pY2F0aW9ucywgSUVFRQogICAg ICAgICAgICAgIEpvdXJuYWwgb24gIFZvbHVtZSAxNywgSXNzdWUgOCwgQXVndXN0IDE5OTkuCgog ICBbSkxNVjAyXSAgIEphY3F1ZXQsIFAuLCBMYW91aXRpLCBWLiwgTWluZXQsIFAuLCBhbmQgTC4g Vmllbm5vdCwKICAgICAgICAgICAgICAiUGVyZm9ybWFuY2Ugb2YgbXVsdGlwb2ludCByZWxheWlu ZyBpbiBhZCBob2MgbW9iaWxlCiAgICAgICAgICAgICAgcm91dGluZyBwcm90b2NvbHMiLCBOZXR3 b3JraW5nICwgMjAwMi4KCiAgIFtNREMwNF0gICAgTWFja2VyLCBKLiwgRGVhbiwgSi4sIGFuZCBX LiBDaGFvLCAiU2ltcGxpZmllZCBNdWx0aWNhc3QKICAgICAgICAgICAgICBGb3J3YXJkaW5nIGlu IE1vYmlsZSBBZCBob2MgTmV0d29ya3MiLCBJRUVFIE1JTENPTSAyMDA0CiAgICAgICAgICAgICAg UHJvY2VlZGluZ3MgLCAyMDA0LgoKCgoKTWFja2VyLCBlZGl0b3IgJiBTTUYgRGVzaWduIFRlYW0g IEV4cGlyZXMgU2VwdGVtYmVyIDcsIDIwMTAgICAgW1BhZ2UgMzRdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICAgICBTTUYgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEw CgoKICAgW01EREEwN10gICBNYWNrZXIsIEouLCBEb3duYXJkLCBJLiwgRGVhbiwgSi4sIGFuZCBS LiBBZGFtc29uLAogICAgICAgICAgICAgICJFdmFsdWF0aW9uIG9mIGRpc3RyaWJ1dGVkIGNvdmVy IHNldCBhbGdvcml0aG1zIGluIG1vYmlsZQogICAgICAgICAgICAgIGFkIGhvYyBuZXR3b3JrIGZv ciBzaW1wbGlmaWVkIG11bHRpY2FzdCBmb3J3YXJkaW5nIiwgQUNNCiAgICAgICAgICAgICAgU0lH TU9CSUxFIE1vYmlsZSBDb21wdXRpbmcgYW5kIENvbW11bmljYXRpb25zIFJldmlldwogICAgICAg ICAgICAgICBWb2x1bWUgMTEgLCAgSXNzdWUgMyAgKEp1bHkgMjAwNyksIEp1bHkgMjAwNy4KVUg+ ID09PT09PT09PT09PT09PT0KVUg+IFR3aWNlIEp1bHkgMjAwNwpVSD4gPT09PT09PT09PT09PT09 PQpKTT4gaGV5IHRoYXRzIHhtbDJyZmMgYmVpbmcgdG9vIHNtYXJ0LiB0aGUgeG1sIGJpYiByZWYg d2FzIGJhZC4gICAgICAgICAgICAgIAoKCiAgIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIFNN Rl9UWVBFOkUtQ0RTIG1lc3NhZ2UgVExWIApVSD4gPT09PT09PT09PT09PT09PQpVSD4gYXMgZGVm aW5lZCB3aGVyZT8KVUg+ID09PT09PT09PT09PT09PT0KICAgYmUgaW5jbHVkZWQgaW4KICAgTkhE UF9IRUxMTyBtZXNzYWdlcyB0aGF0IGFyZSBnZW5lcmF0ZWQgYnkgbm9kZXMgY29uZHVjdGluZyBF LUNEUyBTTUYKICAgb3BlcmF0aW9uLiAgSXQgaXMgYWxzbyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBT TUZfTkJSX1RZUEU6RS1DRFMKICAgYWRkcmVzcyBibG9jayBUTFYgYmUgdXNlZCB0byBhZHZlcnRp c2UgbmVpZ2hib3Igbm9kZXMgdGhhdCBhcmUgYWxzbwogICBjb25kdWN0aW5nIEUtQ0RTIFNNRiBv cGVyYXRpb24uCgpBLjEuICBFLUNEUyBSZWxheSBTZXQgU2VsZWN0aW9uIE92ZXJ2aWV3CgogICBU aGUgRS1DRFMgcmVsYXkgc2V0IHNlbGVjdGlvbiByZXF1aXJlcyAyLWhvcCBuZWlnaGJvcmhvb2Qg aW5mb3JtYXRpb24KICAgY29sbGVjdGVkIHRocm91Z2ggTkhEUCBvciBhbm90aGVyIHByb2Nlc3Mu ICBSZWxheSBub2RlcywgaW4gRS1DRFMgU01GCiAgIHNlbGVjdGlvbiwgYXJlICJzZWxmLWVsZWN0 ZWQiIHVzaW5nIGEgcm91dGVyIGlkZW50aWZpZXIgKFJvdXRlciBJRCkKICAgYW5kIGFuIG9wdGlv bmFsIG5vZGFsIG1ldHJpYywgcmVmZXJyZWQgdG8gaGVyZSBhcyAiUm91dGVyIFByaW9yaXR5Igog ICBmb3IgYWxsIDEtaG9wIGFuZCAyLWhvcCBuZWlnaGJvcnMuICBUbyBlbnN1cmUgcHJvcGVyIHJl bGF5IHNldCBzZWxmLQogICBlbGVjdGlvbiwgdGhlIFJvdXRlciBJRCBhbmQgUm91dGVyIFByaW9y aXR5IE1VU1QgYmUgY29uc2lzdGVudCBhbW9uZwogICBub2RlcyBwYXJ0aWNpcGF0aW5nIAogICBh bmQgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCBOSERQIGJlIHVzZWQgdG8gc2hhcmUKICAgdGhpcyBp bmZvcm1hdGlvbi4gCiAgIFRoZSBSb3V0ZXIgSUQgaXMgYSBsb2dpY2FsIGlkZW50aWZpY2F0aW9u IHRoYXQKICAgTVVTVCBiZSBjb25zaXN0ZW50IGFjcm9zcyBpbnRlcm9wZXJhdGluZyBTTUYgbmVp Z2hib3Job29kcyBhbmQgaXQgaXMKICAgUkVDT01NRU5ERUQgdG8gYmUgY2hvc2VuIGFzIHRoZSBs YXJnZXN0IGludGVyZmFjZSBhZGRyZXNzIGFkdmVydGlzZWQKICAgYnkgTkhEUC4gCiAgIFRoZSBF LUNEUyBzZWxmLWVsZWN0aW9uIHByb2Nlc3MgY2FuIGJlIHN1bW1hcml6ZWQgYXMKICAgZm9sbG93 czoKCiAgIDEuICBJZiBhbiBTTUYgbm9kZSBoYXMgYSBoaWdoZXIgb3JkaW5hbCAoUm91dGVyIFBy aW9yaXR5LCBSb3V0ZXIgSUQpCiAgICAgICB0aGFuIGFsbCBvZiBpdHMgc3ltbWV0cmljIG5laWdo Ym9ycywgaXQgZWxlY3RzIGl0c2VsZiB0byBhY3QgYXMgYQogICAgICAgZm9yd2FyZGVyIGZvciBh bGwgcmVjZWl2ZWQgbXVsdGljYXN0IHBhY2tldHMsCiAgIDIuICBFbHNlLCBpZiB0aGVyZSBkb2Vz IG5vdCBleGlzdCBhIHBhdGggZnJvbSBuZWlnaGJvciAiaiIgClVIPiA9PT09PT09PT09PT09PT09 ClVIPiAiaiIgaXMgbmV2ZXIgdXNlZC4gQ2FuIGJlIG9taXR0ZWQKVUg+ID09PT09PT09PT09PT09 PT0KSkQ+ID09PT09PT09PT09PT0KSkQ+IHMvZnJvbSBuZWlnaGJvciAiaiIgd2l0aC9mcm9tIHRo ZSBuZWlnaGJvciB3aXRoLwpKRD4gPT09PT09PT09PT09PQoKICAgd2l0aAogICAgICAgbGFyZ2Vz dCAoUm91dGVyIFByaW9yaXR5LCBSb3V0ZXIgSUQpIHRvIGFueSBvdGhlciBuZWlnaGJvciwgX3Zp YV8KICAgICAgIG5laWdoYm9ycyB3aXRoIGxhcmdlciB2YWx1ZXMgb2YgKFJvdXRlciBQcmlvcml0 eSwgUm91dGVyIElEKSwKICAgICAgIHRoZW4gaXQgZWxlY3RzIGl0c2VsZiB0byB0aGUgcmVsYXkg c2V0LgoKICAgVGhlIGJhc2ljIGZvcm0gb2YgRS1DRFMgZGVzY3JpYmVkIGFuZCBhcHBsaWVkIHdp dGhpbiB0aGlzCiAgIHNwZWNpZmljYXRpb24gZG9lcyBub3QgcHJvdmlkZSBmb3IgcmVkdW5kYW50 IHJlbGF5IHNldCBlbGVjdGlvbgogICAoZS5nLiwgYmktY29ubmVjdGVkKSBidXQgc3VjaCBjYXBh YmlsaXR5IGlzIHN1cHBvcnRlZCBieSB0aGUgYmFzaWMKICAgRS1DRFMgZGVzaWduLgoKyS4KCkEu My4gIEUtQ0RTIE5laWdoYm9yaG9vZCBEaXNjb3ZlcnkgUmVxdWlyZW1lbnRzCgogICBJdCBpcyBw b3NzaWJsZSB0byBwZXJmb3JtIEUtQ0RTIHJlbGF5IHNldCBzZWxlY3Rpb24gd2l0aG91dAogICBt b2RpZmljYXRpb24gb2YgTkhEUCwgYmFzaW5nIHRoZSBzZWxmLWVsZWN0aW9uIHByb2Nlc3MgZXhj bHVzaXZlbHkgb24KICAgdGhlIFJvdXRlciBJRHMgKGludGVyZmFjZSBhZGRyZXNzZXMpIAogICBv ZiBwYXJ0aWNpcGF0aW5nIFNNRiBub2Rlcy4KCiAgIEhvd2V2ZXIgc3RlcHMgTVVTVCBiZSB0YWtl biB0byBpbnN1cmUgdGhhdCBhbGwgTkhEUCBpbnN0YW5jZXMgCiAgIG5vdAogICB1c2luZyBTTUZf VFlQRTpFLUNEUyBmdWxsIHR5cGUgbWVzc2FnZSBUTFZzIGFyZSBpbiBmYWN0IHJ1bm5pbmcgU01G CiAgIEUtQ0RTLCBvdGhlcndpc2UgaW5jb3JyZWN0IGZvcndhcmRpbmcgbWF5IG9jY3VyLiAgRnVy dGhlcm1vcmUsIGl0IGhhcwogICBiZWVuIHNob3duIApVSD4gPT09PT09PT09PT09PT09PQpVSD4g Iml0IGhhcyBiZWVuIHNob3duIiB3aGVyZT8gQ2l0YXRpb24KVUg+ID09PT09PT09PT09PT09PT0K Sk0+IERlYW4ncyBpbnRlcm5hbCBleHBlcmltZW50cyBub3Qgc3VyZSBpdCB3YXMgcHVibGlzaGVk IHNvIHJlbW92ZWQuCgoKQi4zLiAgUy1NUFIgTmVpZ2hib3Job29kIERpc2NvdmVyeSBSZXF1aXJl bWVudHMKCiAgIE5vZGVzIG1heSBvcHRpb25hbGx5IHNpZ25hbCAiUm91dGVyIFByaW9yaXR5IiBv ciAiV0lMTElOR05FU1MiIAoKICAgdG8KICAgYmVjb21lIE1QUiBub2RlcyBmb3IgdGhlaXIgb25l IGhvcCBuZWlnaGJvcnMgYnkgdXNpbmcgdGhlIFNNRl9UWVBFOlMtCiAgIE1QUiBtZXNzYWdlIGJs b2NrIFRMViB2YWx1ZSBmaWVsZCBkZWZpbmVkIGFzIHN1Y2g6CgogICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAg fCBMZW5ndGgoYnl0ZXMpIHwgVmFsdWUgICB8IFJvdXRlciBQcmlvcml0eSB8CiAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAg ICAgICAgICB8IDAgICAgICAgICAgICAgfCBOL0EgICAgIHwgNjQgICAgICAgICAgICAgIHwKICAg ICAgICAgICAgICAgfCAxICAgICAgICAgICAgIHwgPHZhbHVlPiB8IDAtMTI3ICAgICAgICAgICB8 CiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tKwoKICAgICAgICAgICAgICAgICAgICBUYWJsZSAxMzogUy1NUFIgTWVzc2FnZSBUTFYgVmFs dWVzCgogICBXaGVyZSA8dmFsdWU+IGlzIGEgb25lIGJ5dGUgYml0IGZpZWxkIApVSD4gPT09PT09 PT09PT09PT09PQpVSD4gIm9uZSBvY3RldCBsb25nIGJpdCBmaWVsZCIKVUg+ID09PT09PT09PT09 PT09PT0KSk0+ZG9uZQoKICAgd2hpY2ggaXMgZGVmaW5lZCBhczoKCiAgIGJpdCAwOiBpcyByZXNl cnZlZCBhbmQgU0hPVUxEIGJlIHNldCB0byAwLgouLi4KCkIuNC4gIFMtTVBSIFNlbGVjdGlvbiBB bGdvcml0aG0KCiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgYSBiYXNpYyBhbGdvcml0aG0gZm9y IHRoZSBTLU1QUiBzZWxlY3Rpb24KICAgcHJvY2Vzcy4gIE5vdGUgdGhhdCB0aGUgc2VsZWN0aW9u IGlzIHdpdGggcmVzcGVjdCB0byBhIHNwZWNpZmljCiAgIGludGVyZmFjZSBvZiB0aGUgbm9kZSBw ZXJmb3JtaW5nIHNlbGVjdGlvbiBhbmQgb3RoZXIgbm9kZSBpbnRlcmZhY2VzCiAgIHJlZmVyZW5j ZWQgYXJlIHJlYWNoYWJsZSBmcm9tIHRoaXMgcmVmZXJlbmNlIG5vZGUgaW50ZXJmYWNlLiAgVGhp cyBpcwogICBjb25zaXN0ZW50IHdpdGggdGhlIFMtTVBSIGZvcndhcmRpbmcgcnVsZXMgZGVzY3Jp YmVkIGFib3ZlLiAgV2hlbgogICBtdWx0aXBsZSBpbnRlcmZhY2VzIHBlciBub2RlIGFyZSB1c2Vk LCBpdCBpcyBwb3NzaWJsZSB0byBlbmhhbmNlIHRoZQogICBvdmVyYWxsIHNlbGVjdGlvbiBwcm9j ZXNzIGFjcm9zcyBtdWx0aXBsZSBpbnRlcmZhY2VzIHN1Y2ggdGhhdCBjb21tb24KICAgbm9kZXMg YXJlIHNlbGVjdGVkIGFzIE1QUnMgZm9yIGVhY2ggaW50ZXJmYWNlIHRvIGF2b2lkIHVubmVjZXNz YXJ5CiAgIGluZWZmaWNpZW5jaWVzIGluIGZsb29kaW5nLiAgVGhpcyBpcyBkZXNjcmliZWQgZnVy dGhlciBpbiBbT0xTUnYyXS4KICAgVGhlIGZvbGxvd2luZyBzdGVwcyBkZXNjcmliZSBhIGJhc2lj IGFsZ29yaXRobSBmb3IgY29uZHVjdGluZyBTLU1QUgogICBzZWxlY3Rpb24gZm9yIGEgbm9kZSBp bnRlcmZhY2UgIm4wIjoKCiAgIDEuICBJbml0aWFsaXplIHRoZSBzZXQgIk1QUiIgdG8gZW1wdHku CiAgIDIuICBJbml0aWFsaXplIHRoZSBzZXQgIk4xIiB0byBpbmNsdWRlIGFsbCAxLWhvcCBuZWln aGJvcnMgb2YgIm4wIi4KICAgMy4gIEluaXRpYWxpemUgdGhlIHNldCAiTjIiIHRvIGluY2x1ZGUg YWxsIDItaG9wIG5laWdoYm9ycywgZXhjbHVkaW5nCiAgICAgICAibjAiIGFuZCBhbnkgbm9kZXMg aW4gIk4xIi4gIE5vZGVzIHdoaWNoIGFyZSBvbmx5IHJlYWNoYWJsZSB2aWEKICAgICAgICJOMSIg bm9kZXMgClVIPiA9PT09PT09PT09PT09PT09ClVIPiBhZGQgImFuZCIgYmV0d2VlbiBOMSBhbmQg bm9kZXM/ClVIPiA9PT09PT09PT09PT09PT09CkpEPiA9PT09PT09PT09PT09CkpEPiBOby4gIFdl IG1heSBuZWVkIHRvIHJlcHJvZHVjZSB0aGUgdHVwbGUgZm9ybWF0IEkgc3VnZ2VzdGVkIGZvciBF Q0RTIHRvIGJlIGNvbXBhcmFibGUuICBJdCBzZWVtcyB0aGUgb25seSB3YXkgdG8gY2xlYW5seSBn cm91cCBhZGRyZXNzZXMgYW5kIG5vZGVzLiAgVGhlIHR1cGxlIGZvcm1hdCB3aWxsIGNsZWFuIHRo aXMgdXAgYW5kIG1ha2UgdGhlIGJlbG93IG1vcmUgY2xlYXIuCkpEPiA9PT09PT09PT09PT09Cgog ICAgICAgCiAgICAgICB3aXRoIHJvdXRlciBwcmlvcml0eSB2YWx1ZXMgb2YgTkVWRVIgYXJlIGFs c28KICAgICAgIGV4Y2x1ZGVkLgogICA0LiAgRm9yIGVhY2ggaW50ZXJmYWNlICJ5IiBpbiAiTjEi LCBpbml0aWFsaXplIGEgc2V0ICJOMih5KSIgdG8KVUg+ID09PT09PT09PT09PT09PT0KVUg+IE4x IGNvbnRhaW5zICIxLWhvcCBuZWlnaGJvcnMiIChJIGFzc3VtZSBvcmlnaW5hdG9yIGFkZHJlc3Nl cyBvciBzby4uLiB1bmNsZWFyIGFzIGluIHN0ZXAgMikuIEJ1dCBub3QgaW50ZXJmYWNlLiBNYXli ZSBpdCBjb3VsZCBjb250YWluIGludGVyZmFjZSBhZGRyZXNzZXMsIGJ1dCBub3QgaW50ZXJmYWNl cwpVSD4gPT09PT09PT09PT09PT09PQpKRD4gPT09PT09PT09PT09PQpKRD4gV2VsbCBpdHMgZ29p bmcgdG8gYmUgdHVwbGVzIHdoaWNoIGluY2x1ZGUgdGhlICJTZW5kaW5nIEFkZHJlc3MgTGlzdCIg YXMgZGVmaW5lZCBpbiBOSERQIHNlY3Rpb24gMTIuMiBkZWZpbml0aW9ucyBzZWN0aW9uLiAgVGhp cyBkZWZpbml0aW9uIHNob3VsZCBiZSB1c2UgZWxzZXdoZXJlIHRvby4KSkQ+ID09PT09PT09PT09 PT0KCiAgICAgICBpbmNsdWRlIGFueSBpbnRlcmZhY2VzIGluICJOMiIgdGhhdCBhcmUgMS1ob3Ag bmVpZ2hib3JzIG9mICJ5Ii4KICAgNS4gIEZvciBlYWNoIGludGVyZmFjZSAieCIgaW4gIk4xIiB3 aXRoIGEgcm91dGVyIHByaW9yaXR5IHZhbHVlIG9mCiAgICAgICAiQUxXQVlTIiAob3IgdXNpbmcg Q0YgcmVsYXkgYWxnb3JpdGhtKSwgc2VsZWN0ICJ4IiBhcyBhIE1QUjoKICAgICAgIEEuICBBZGQg IngiIHRvIHRoZSBzZXQgIk1QUiIgYW5kIHJlbW92ZSAieCIgZnJvbSAiTjEiLgogICAgICAgQi4g IEZvciBlYWNoIGludGVyZmFjZSAieiIgaW4gIk4yKHgpIiwgcmVtb3ZlICJ6IiBmcm9tICJOMiIK ICAgICAgIEMuICBGb3IgZWFjaCBpbnRlcmZhY2UgInkiIGluICJOMSIsIHJlbW92ZSBhbnkgaW50 ZXJmYWNlcyBpbgogICAgICAgICAgICJOMih4KSIgZnJvbSAiTjIoeSkiCgoMCgo= --0016e6567fb64da0a8049e7687c0-- From joseph.macker@nrl.navy.mil Mon Mar 14 12:39:52 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DEE73A6B57 for ; Mon, 14 Mar 2011 12:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[AWL=-2.250, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_93=0.6, MANGLED_SHOP=2.3, 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 B50C7JvasFk4 for ; Mon, 14 Mar 2011 12:39:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ACFA63A6B1F for ; Mon, 14 Mar 2011 12:39:45 -0700 (PDT) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.74) (envelope-from ) id 1PzDdT-0001ou-7P for draft-ietf-manet-smf@tools.ietf.org; Mon, 14 Mar 2011 12:41:08 -0700 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p2EJeVoY021592; Mon, 14 Mar 2011 15:40:41 -0400 Received: from vpn217206.nrl.navy.mil ([132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011031415404115992 ; Mon, 14 Mar 2011 15:40:41 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/mixed; boundary=Apple-Mail-1--298106070 From: Joe Macker In-Reply-To: <71B49ED0-AFC1-4B76-B2C3-E7A86A85EC1B@nrl.navy.mil> Date: Mon, 14 Mar 2011 15:40:40 -0400 Message-Id: <58ED598E-4FDA-42F0-B277-160497763191@nrl.navy.mil> References: <4D713B29.20706@cisco.com> <71B49ED0-AFC1-4B76-B2C3-E7A86A85EC1B@nrl.navy.mil> To: Joe Macker X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 132.250.83.3 X-SA-Exim-Rcpt-To: draft-ietf-manet-smf@tools.ietf.org X-SA-Exim-Mail-From: joseph.macker@nrl.navy.mil X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Mailman-Approved-At: Tue, 15 Mar 2011 08:17:07 -0700 Cc: draft-ietf-manet-smf@tools.ietf.org Subject: Re: [manet] Mail regarding draft-ietf-manet-smf X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:39:52 -0000 --Apple-Mail-1--298106070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii version 11 has been submitted I am attaching the comment responses from = Ulrich's thread. I will recopy these to the manet list. --Apple-Mail-1--298106070 Content-Disposition: attachment; filename=SMF_review-herberg_response_4.txt Content-Type: text/plain; x-unix-mode=0644; name="SMF_review-herberg_response_4.txt" Content-Transfer-Encoding: quoted-printable =20 Detailed comments: (starting with "UH> ", always immediately following the concerned sentence or paragraph) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> There is an errata to RFC2119: "NOT RECOMMENDED" has been added. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> FIXED in 11 2. Introduction and Scope Unicast routing protocol designs for MANET and wireless mesh use have demonstrated efficient mechanisms to flood routing control plane messages within a wireless routing area. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "have demonstrated" may require a citation UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Agreed. Changed intro writeup to discuss only that present = approaches implement optimized relay sets for the control plane. I think = now the present citations are sufficient. =20 For example, algorithms specified within [RFC3626] and [RFC3684] provide distributed methods of dynamically electing reduced relay sets that attempt to optimize flooding of routing control messages while maintaining a connected set. In one sense, Simplified Multicast Forwarding (SMF) extends the efficient flooding concept to the data forwarding plane. Therefore, SMF provides an appropriate multicast forwarding capability for use cases where localized, efficient flooding is deemed effective. The baseline design is intended to provide a basic, best effort multicast forwarding capability that is constrained to operate within a MANET or wireless mesh routing region. The main design goals of this SMF specification are to adapt efficient relay sets in MANET type environments [RFC2901] and to define the needed IPv4 and IPv6 multicast duplicate packet detection (DPD) mechanisms to support multi-hop, packet forwarding. Figure 1 provides an overview of the logical SMF node architecture, consisting of "Neighborhood Discovery", "Relay Set Selection" and "Forwarding Process" components. Typically, relay set selection (or self-election) will occur based on input from a neighborhood discovery process, and the forwarding process will often be determined by dynamic relay set selection. Note the neighborhood discovery and/or relay set selection information MAY=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> This is an introduction section. I am not sure it is a good place to = start the specification itself by using RFC2119 terminology. That = applies several times throughout the introduction. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> The discussion of the Design Overview I think requires some of this, = but it was moved outside the Intro/Scope section. =20 be obtained from a coexistent process (e.g., a lower layer mechanism or a unicast routing protocol using relay sets). In some cases, the forwarding decision for a packet can also depend on previous hop or incoming interface information. The asterisks (*) in Figure 1 mark the primitives and relationships needed by relay set algorithms requiring previous-hop packet forwarding knowledge. Macker, editor & SMF Design Team Expires September 7, 2010 [Page 5] =0C Internet-Draft SMF March 2010 ______________ _____________ | | | | | Neighborhood | | Relay Set | | Discovery |------------->| Selection | | Protocol | neighbor | Algorithm | |______________| info |_____________| \ / \ / neighbor\ /forwarding info* \ ____________ / status \ | | / `-->| Forwarding |<--' | Process | ~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~> incoming packet, forwarded packets interface id*, and previous hop* Figure 1: SMF Node Architecture Interoperable SMF implementations MUST use a common DPD approach and be able to process the header options defined in this document for IPv6 operation. We define Classical Flooding (CF), as the simplest case of SMF multicast forwarding. With CF, each SMF router forwards each received forwardable multicast packet exactly once. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Where is "forwardable" defined? Throughout the document, the word = "packet" is used. Maybe replace it with "IP datagram"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Briefly introduced the concept of forwardable here and pointed to = the fact that more details are given later in the document. JM> Re. packet I think because we discuss forwarding of IP datagram = fragments a more generic term was desired. I guess this is debatable. = I am happy to use IP datagram, but should also say IP datagram = fragments. Actually I like packet better because of the fragment issue. =20 In this case, the need for any relay set selection or neighborhood topology information is eliminated but DPD functionality is still required. While SMF supports a CF mode of operation the use of more efficient relay set modes is RECOMMENDED to reduce contention and congestion caused by unnecessary packet retransmissions [NTSC99]. An efficient, reduced relay set is realized by selecting and maintaining a _subset_ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> underscores around subset seem unnecessary UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> removed of all possible SMF routers in a MANET routing region.=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Throughout the document, different terms are used for presumably the = same intention: MANET routing domain, SMF routing area, MANET SMF = routing domain, SMF routing domain,... None of these is defined. UH> Also, I would replace "SMF routers" by "routers running the SMF = protocol" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> well there was some definition in 9.2 on site scoped areas but the = terminology was inconsistent. I am going with SMF routing domain and = routers running the SMF protocol for now. =20 Known relay set selection algorithms have already demonstrated the ability to provide and maintain a dynamic connected set for forwarding user multicast data [MDC04]. A few such relay set selection algorithms are described in the Appendices of this document and the basic designs borrow directly from previously documented IETF work. SMF relay set configuration is extensible and additional relay set algorithms beyond those specified here can be accommodated in future work. Determining and maintaining an optimized set of forwarding nodes UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Throughout the document, node/router is inconsistent. An = applicability section would be nice. Does SMF run on hosts, routers, = both? There, one could mention that it is limited to IP (but supports = both IPv4 and IPv6). UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> SMF is a forwarding protocol so yes if a node has multicast = forwarding enabled it can run SMF. generally requires dynamic neighborhood topology information. Neighborhood topology discovery functions MAY be externally provided by a MANET unicast routing protocol or by using the MANET NeighborHood Discovery Protocol (NHDP) [NHDP] running in concurrence with SMF. Additionally, this specification allows alternative processes that may be deemed more effective (e.g., lower layer Macker, editor & SMF Design Team Expires September 7, 2010 [Page 6] =0C Internet-Draft SMF March 2010 wireless interface) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> The sentence is unclear... is reads as if a wireless interface was a = process. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Ok its changed. Talked more about a lower layer interface (such as a = radio router interface) =20 to provide the necessary neighborhood information to support relay set election. Fundamentally, an SMF implementation SHOULD provide the ability for multicast forwarding state to be dynamically managed per operating network interface. Some of the relay state maintenance options and interactions are outlined later in Section 6. This document states specific requirements for neighborhood discovery with respect to the forwarding process and the relay set selection algorithms described herein. For determining dynamic relay sets in the absence of an existing MANET unicast protocol or lower layer interface UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> In the absence of a ""? Is that a network interface? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM >changed in 11. =20 , SMF relies on the MANET NHDP specification to assist in IP layer 2-hop neighborhood state discovery and maintenance for relay set election. A "SMF_RELAY_ALG" Message TLV type (per [RFC5444]) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> It could be useful to briefly give an overview of RFC5444 before; or = define which terms of RFC5444 are used within this spec. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =20 3. SMF Applicability Within dynamic wireless routing topologies, maintaining traditional forwarding trees to support a multicast routing protocol is often not as effective as in wired networks due to the reduced reliability and increased dynamics of mesh topologies [MGL04] [GM99]. A basic packet forwarding service reaching all connected MANET SMF routers participating within a localized routing region UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What is a "localized routing region"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> fixed =20 may provide a useful group communication paradigm for various classes of applications. Applications that could take advantage of a simple multicast forwarding service within a MANET routing region include multimedia streaming, interactive group-based messaging and applications, peer- to-peer middleware multicasting, and multi-hop mobile discovery or registration services. SMF is appropriate for deployment in limited dynamic wireless routing areas=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What is a "limited dynamic wireless routing area"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> further defined throughout you had a big central comment about this = that I tracked throughout the document. =20 so that the flooding process can be contained. Note again that Figure 1 provides a notional architecture for typical SMF-capable nodes. However,=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Remove "however"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> done =20 a goal is that simple end-system (non- forwarding) wireless nodes=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> A "node" (router? host?) is not wireless. It can have several = wired/wireless interfaces. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> its really about leaf nodes of any sort so I removed the wireless = node ref. Nice catch. =20 may also participate in multicast traffic transmission and reception with standard IP network layer semantics (e.g., special or unnecessary encapsulation of IP packets should be avoided in this case). It is important that SMF deployments in localized edge network settings are able to connect and interoperate with existing standard multicast protocols operating within more conventional Internet infrastructures. A multicast border router or proxy mechanism MUST be used when deployed alongside more fixed- infrastructure IP multicast routing such Protocol Independent Multicast (PIM) variants [RFC3973] and [RFC4601]. With present experimental SMF implementations, proxy methods have demonstrated UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "have demonstrated" --> citation UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> added =20 gateway functionality at MANET border routers operating with existing external IP multicast routing protocols. SMF may be extended or combined with other mechanisms to provide increased reliability and group specific filtering, but the details for this are not discussed here. 4. SMF Packet Processing and Forwarding The SMF Packet Processing and Forwarding actions are conducted with the following packet handling activities: 1. Processing of outbound, locally-generated multicast packets. 2. Reception and processing of inbound packets on a specific network interface(s). UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> wrong plural: "a" ... "interfaces" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Fixed The purpose of intercepting outbound, locally-generated multicast packets is to apply any added packet marking needed to satisfy the Macker, editor & SMF Design Team Expires September 7, 2010 [Page 8] =0C Internet-Draft SMF March 2010 DPD requirements so that proper forwarding may be conducted. Note that for some system configurations the interception of outbound packets for this purpose is not necessary. Inbound multicast packets are received by the SMF implementation and processed for possible forwarding. This document does not presently support forwarding of directed broadcast addresses [RFC2644]. SMF implementations MUST be capable of forwarding "global scope" multicast packets=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What is a "global scope multicast packet"? Maybe an "IP datagram = whose destination address is a global IP address as specified in = RFC2373?" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> added appropriate refs for IPv4 and IPv6. Nice catch. =20 to support generic multicast application needs or to distribute designated multicast traffic ingressing the MANET routing region via border routers UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Are "MANET border routers" defined somewhere? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 JM> That is somewhat left open as there are many border router = approaches but was intended to be standard infrastructure or other = routing. THere have has been code and demonstration of SMF and standard = PIM variant border gateways. As EXP intent I wouldn't what to make = gatewaying too specific. Any suggestions? I could add an informative = reference as a border example if that helps. Not sure it is critical at = this stage. . The multicast addresses to be forwarded will be maintained by an a priori list or a dynamic forwarding information base (FIB) that MAY interact with future MANET dynamic group membership extensions or management functions. There will also be a well-known multicast group for flooding to all SMF forwarders UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Has "SMF forwarder" been defined somewhere? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> This should be changed to SMF nodes in a routing domain and be = consistent with other definition of limited SMF routing domain in = Applicability section. . This multicast group is specified to contain all MANET SMF routers of a connected MANET routing region UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Where is "connected MANET routing region" defined? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D , so that packets transmitted to the multicast address associated with the group will be delivered to all connected SMF routers. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Where is "connected SMF routers" defined? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> I think the above 3 comments are all improved in the same way in the = new text. =20 For IPv6, the multicast address is specified to be "site-local". The name of the multicast group is "SL-MANET-ROUTERS". UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I would move this to the end of the spec. (IANA considerations) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Ok, this was in the other IANA MANET ID and got moved out. So yeah = it belongs here now. Minimally SMF SHALL UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> This is the only section in this spec that used "SHALL" instead of = "MUST". I would stick with "MUST". UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 forward, as instructed by the relay set selection algorithm, unique (non- duplicate) packets received for this well-known group address when the TTL or hop count value=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/hop count/hop limit/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 in the IP header is greater than 1. SMF SHALL forward all additional global scope addresses specified within the dynamic FIB or configured list as well. In all cases, the following rules SHALL be observed for SMF multicast forwarding: 1. Multicast packets with TTL <=3D 1 MUST NOT be forwarded. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Unclear definition of "Multicast packet"; better use "IP datagram = with multicast destination address" or the like... similar for item 2. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Multicast datagrams are defined in other documents. Here I mean any = multicast packet that passes the forwarded rules. These could be (S,G) = or (*, G) defined via a separate process.=20 2. Link local multicast packets MUST NOT be forwarded. 3. Incoming multicast packets with an IP source address matching one of those of the local SMF router interface(s) MUST NOT be forwarded. 4. Received packet frames with the MAC source address matching the local SMF router interface(s) MUST NOT be forwarded. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Has IP fragmentation been mentioned before? Are these IP frames? = Then they don't have a MAC address (only the L2 frame surrounding the IP = frame has one). Do all L2 frames have MAC addresses (there may be = strange non-IEEE-NICs used in a MANET). The case of several interfaces = is unclear (better detail it like "Received frames with the MAC source = address matching any MAC address of any of the routers' interfaces..." = or the like.) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. Received packets for which SMF cannot reasonably ensure temporal DPD uniqueness MUST NOT be forwarded. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Is that explained anywhere in detail? What das "reasonably" mean? = What does "temporal uniqueness" mean? Does that mean that the DPD = explained later in the spec is performed at this moment? (5.) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 6. When packets are forwarded, TTL or hop limit SHALL be decremented by one. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I like this ordered list of actions. But it is not consequently used = throughout the doc. It would be very nice throughout the whole document = to know in what order to do what action. I suggest: s/SHALL/MUST/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Note that rule #3 is important because in wireless networks, UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What is a "wireless network"? Maybe you mean something like "a = network consisting of mobile routers with at least one wireless = interface participating in the same routing domain...." (well, has to be = thought about...) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =20 the local SMF router=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What is the "local" SMF router? That should be defined (as it is = done in OLSRv2, for example) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 may receive re-transmissions of its own packets when they are forwarded by neighboring nodes. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Is "neighboring nodes" defined? Is that NHDP terminology? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JD> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JD> Adjacent SMF routers? or better yet "neighboring SMF nodes" JD> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 This rule avoids unnecessary retransmission of locally-generated packets even when other forwarding decision rules would apply. An additional processing rule also needs to be considered based upon a potential security threat. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> In the list above, when would this rule be applied? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> THis is a new rule and would be checked prior to 6. =20 As discussed further in Section 10, ... Once these criteria have been met, an SMF implementation MUST make a forwarding decision dependent upon the relay set selection algorithm in use. If the SMF implementation is using Classical Flooding (CF), the forwarding decision is implicit once DPD uniqueness is determined. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> How is it determined? (specification needed here) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> This is a local decision and the node will know which mode based = upon operation configuration. =20 Otherwise, a forwarding decision depends upon the current interface-specific relay set state. The descriptions of the relay set selection algorithms in the Appendices=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Which section in the Appendices? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Each Appendix now covers separate relay set discussions. to this document specify the respective heuristics for multicast packet forwarding and specific DPD or other processing required to achieve correct SMF behavior. For example, one class of forwarding is based upon relay set election status and the packet's previous hop forwarder =20 , while other classes designate the local SMF router as a forwarder for all neighboring nodes. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Not sure this whole section about this security aspect belongs here = (it's not core spec). Maybe move it to the "Security Considerations" = section at the end? Or another draft? I am not sure here... UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Yes, it belongs in the document. Since the processing rules are = being introduced here it seemed it nice time to introduce issues. COuld = leave it to later in security considerations but its actually a specific = processing rule consideration. Remember this is EXP proposed track at = this point. I don't want to leave out guidance that may be worth = exploring in the forwarding rules as someone is beginning to implement = code. 5. SMF Duplicate Packet Detection Duplicate packet detection (DPD) is a common requirement in MANET=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "common requirement" may require citations UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Softened this and changed the wording a little since its common = practice. The point is due to dynamics and retransmission out the same = physical interface in many cases dup detection is needed. This is = already used within control plane MANET protocols as your aware. Nothing = new here. =20 or wireless mesh packet forwarding because packets may be transmitted out the same physical interface upon which they arrived and nodes may also receive copies of previously-transmitted packets from other forwarding neighbors. SMF implementations MUST detect and avoid forwarding duplicate multicast packets using temporal packet identification. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Where is "temporal packet identification" defined? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> It is discussed in the paragraphs that immediately follow. I'll make = it more explicit. It is RECOMMENDED this be implemented by keeping a history of recently-processed multicast packets=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "multicast packets" should be defined UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Multicast packets is what is used in RFC 4601,etc. Our forwarding = section define what classes of multicast packets might be forwardable. = Again we forward fragments so datagram is not good either. =20 for comparison to incoming packets. For both IPv4 and IPv6, this document describes two basic multicast duplicate packet detection mechanisms: header content identification-based (I-DPD) and hash-based (H-DPD) duplicate detection. The two approaches are described for experimental Macker, editor & SMF Design Team Expires September 7, 2010 [Page 10] =0C Internet-Draft SMF March 2010 purposes. Trade-offs of the two approaches to DPD merit different consideration dependent upon the specific SMF deployment scenario. Because of the potential addition of a hop-by-hop option header with IPv6, SMF deployments MUST be configured to use a common mechanism and DPD algorithm. The main difference between IPv4 and IPv6 SMF DPD specification is the avoidance of any additional header options in the IPv4 case. For each network interface, SMF implementations MUST maintain DPD packet state as needed to support the forwarding heuristics of the relay set algorithm used. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I would prefer to have a precise specification of the informationen = bases that are required (as it is done, for example, in OLSRv2) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Brian Adamson (known implementor) and myself feel at this point that = is an implementation detail and may be done different ways. We would = prefer to leave implementation details out for now. =20 The specific requirements of several relay set selection algorithms and their forwarding rules are described in the Appendices of this document. In general this involves keeping track of previously forwarded packets so that duplicates are not forwarded, but some relay techniques may have additional considerations. For I-DPD, packets are identified using explicit identifiers from the IP header. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I-DPD has not been defined until now. This is a major problem of the = following paragraphs. I would prefer to have an introduction to = different DPDs that are defined in the spec, then a specification of = each in detail. This is mixed up in the following pages. UH> The sentence "identified using [...] identifiers" sounds like a = tautology UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Introduction to different DPDs was there but added another explicit = explanation. Seems redundant to me but ok. JM> Tautology noted and fixed there. =20 The specific identifier to use depends upon the IP protocol version and the type of packet.=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What "type of packet"? IP datagram type? Where is that defined? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> OK good catch, made it explicit that includes testing for = fragmentation and IPSEC. =20 For example, IPv4 [RFC0791] provides an "Identification" field that may assist a DPD mechanism, and packets that contain IPSec protocol headers also provide suitable packet identifiers. Fragmented packets also provide additional identifiers that need to be considered. These identifier fields are unique within the context of source address, destination address, protocol type, and/or other header fields depending upon the type of identifier used for DPD. Similarly,=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "Similarly" to what? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Sentences were swapped. This came before the sentence regarding = I-DPD state. JM> Similarly is not quite right. Changed this to just state the = recommendation for H-DPD =20 for H-DPD,=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> H-DPD has not been introduced nor defined before UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Now there is a short definition preceding. =20 it is expected that packet hash values will be kept with respect to at least the source address to help ensure hash collision avoidance.=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "at least"? what else? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> done see forward comment =20 SMF implementations MUST maintain DPD history per the applicable packet flow context (e.g., =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Has this notation been defined before? <...:...:..> UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 for DPD based upon IPv4 ID). The details for I-DPD and H-DPD for different types of packets are described in the sections below. In either case, this history SHOULD be kept long enough to span the maximum network traversal lifetime, MAX_PACKET_LIFETIME, of multicast packets being forwarded within an SMF operating area.=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What is an "SMF operating area"? Definition needed UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> done see forward comment =20 The required size of the DPD cache is governed by this timeout value and is also a function of the packet forwarding rates. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> How is this "function of the packet forwarding rate" defined? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> done see forward comment =20 The DPD mechanism SHOULD avoid keeping unnecessary state for packet flows such as those that are locally-generated or link-local destinations that would not be considered for forwarding. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> This whole section is too detailed for a specification and too vague = for an introducation to I-DPD/H-DPD. A good overview of both would be = better instead. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> THis was your important general comment I needed to rewrite this = whole intro section as it was redundant with following sections and came = too early with too much detail and too vague in other places. Done. 5.1. IPv6 Duplicate Packet Detection This section describes the mechanisms and options for SMF IPv6 DPD. The core IPv6 packet header does not provide any explicit identification header field that can be exploited for I-DPD. The following areas are described to support IPv6 DPD: Macker, editor & SMF Design Team Expires September 7, 2010 [Page 11] =0C Internet-Draft SMF March 2010 1. a hop-by-hop SMF-DPD option header (with supporting identifier or hash assistance value), 2. the use of IPv6 fragment header fields for I-DPD when they exist, 3. the use of IPSec sequencing for I-DPD when a non-fragmented, IPSec header is detected, and 4. an H-DPD approach assisted, as needed, by the SMF-DPD option header. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> It should be made clear that these 4 points are explained in the = following subsections in more detail. UH> The list mixes up I-DPD and H-DPD. I would prefer to have that more = seperated. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Clearer now. =20 SMF MUST provide a DPD marking module that can insert the hop-by-hop IPv6 header option defined in this section. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> At what point of time is that done? (see previous ordered list of = actions when a message is considered for forwarding in section 4) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> May be confused by hop-by-hop option. It is not applied in normal = forwarding process so not that same previous steps. Only at = source/ingress gateway and this is configured. =20 This process MUST come after any source-based fragmentation that may occur with IPv6. As with IPv4, SMF IPv6 DPD is presently specified to allow either a packet hash or header identification method for DPD. An SMF implementation MUST be configured to operate either in H-DPD or I-DPD mode and perform the appropriate routines outlined in the following sections. 5.1.1. IPv6 SMF-DPD Header Option As previously mentioned UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> where? which section? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Removed =20 , the base IPv6 packet header does not contain a unique identifier suitable for DPD. This section defines an IPv6 Hop-by-Hop Option=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> citation of IPv6 Hop-by-Hop Option spec. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM>done to serve this purpose for IPv6 I-DPD. Additionally, the header option provides a mechanism to guarantee non-collision of hash values for different packets when H-DPD is used. The value of the IPv6 SMF DPD Hop-by-Hop Option Type is TBD. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Move that to the IANA Considerations section at the end of the spec. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM>done. =20 The first bit of the data field of the SMF-DPD option is the "H-bit" that determines the format of the Option Data content. Two different formats are supported. When the "H-bit" is cleared (zero value), the SMF-DPD format to support I-DPD operation is specified as shown in Figure 2 and defines the extension header in accordance with [RFC2460]. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Is that flexible enough, just two options for H-DPD and I-DPD? Maybe = there will be a future x-DPD which cannot be used then. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> TidTyp provides some flexibility, I don't think there is much = variation requires for the HAV. So while its named for TaggerID now we = have a reserved options left. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... |0|0|0| OptType | Opt. Data Len | UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I would only print the bytes contained in the header option.. e.g., = the first 16 bits could be omitted UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|TidTyp|TidLen| TaggerId (optional) ... | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IPv6 SMF-DPD Header Option in I-DPD mode UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> This section talks about the general header option for both I-DPD = and H-DPD. So I would not put an example for I-DPD here, but rather in = the next subsection. Here should be a general header option with the = H-bit clearly visible UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Yes, many revisions ago there was a generic header diagram and it = got removed base upon some comment. I am going to put it back in. The "TidType" is a 3-bit field indicating the presence and type of the optional "TaggerId" field. The optional "TaggerId" is used to differentiate multiple ingressing border gateways that may commonly apply the SMF-DPD option header to packets from a particular source. =C9. When the "H-bit" in the SMF-DPD option data is set, the data content value is interpreted as a Hash-Assist Value (HAV) used to facilitate H-DPD operation. In this case, source hosts or ingressing gateways apply the SMF-DPD with a HAV only when required to differentiate the hash value of a new packet with respect to older packets in the current DPD history cache.=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Define what is an "old" packet and what is a "new" packet. Is the = history cache data structure somewhere defined? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> need to explain local detection of hash collision,etc. added. old, = new was vague. =20 This helps to guarantee the uniqueness of generated hash values when H-DPD is used. Additionally, this also avoids the added overhead of applying the SMF-DPD option header to every packet. For many hash algorithms, it is expected that only sparse use of the SMF-DPD option may be required. The format of the SMF-DPD header option for H-DPD operation is given in Figure 3. Macker, editor & SMF Design Team Expires September 7, 2010 [Page 13] =0C Internet-Draft SMF March 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... |0|0|0| OptType | Opt. Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Hash Assist Value (HAV) ... UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Should the first bit in the second line (H-bit) be 1, instead of 0? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Yes, wow missed that. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPv6 SMF_DPD Header Option in H-DPD Mode UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> The I-D mixes up SMF-DPD, SMF_DPD, SMF DPD. Should be consistent UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Decided on SMF-DPD added to definition table also. The SMF-DPD option should be applied with a HAV to produce a unique hash digest for packets within the context of the IPv6 packet header . The size of the HAV field is implied by the "Opt. Data Len". The appropriate size of the field depends upon the collision properties of the specific hash algorithm used. More details on IPv6 H-DPD operation are provided in Section 5.1.3. 5.1.2. IPv6 Identification-based DPD The following table summarizes the IPv6 I-DPD processing approach. Within the table '*' indicates a don't care condition. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Define what a "don't care condition" is. Maybe use more scientific = terms. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> changed to ignore +-------------+-----------+-----------+-----------------------------+ | IPv6 | IPv6 | IPv6 | SMF IPv6 I-DPD Mode Action | | Fragment | IPSec | I-DPD | | | Header | Header | Header | | +-------------+-----------+-----------+-----------------------------+ | Present | * | * | Use Fragment Header I-DPD | | | | | Check and Process for | | | | | Forwarding | | Not Present | Present | * | Use IPSec Header I-DPD | | | | | Check and Process for | | | | | Forwarding | | Present | * | Present | Invalid, do not Forward | | Not Present | Present | Present | Invalid, do not Forward | | Not Present | Not | Not | Add I-DPD Header,and | | | Present | Present | Process for Forwarding | | Not Present | Not | Present | Use I-DPD Header Check and | | | Present | | Process for Forwarding | +-------------+-----------+-----------+-----------------------------+ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Is the table explained anywhere? The column headers should be = explained. I would add a horizontal line after each row to make it more = readable. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Table 2: IPv6 I-DPD Processing Rules If the IPv6 multicast packet is an IPv6 fragment, SMF MUST use the fragment extension header fields for packet identification. This identifier can be considered unique in the context of the of the IP packet. If the packet is an unfragmented IPv6 IPSec packet, SMF MUST use IPSec fields for packet identification. Macker, editor & SMF Design Team Expires September 7, 2010 [Page 14] =0C Internet-Draft SMF March 2010 The IPSec header field=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> cite where that is specified UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> done can be considered a unique identifier in the context of the UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Where is SPI defined? Cite. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> done where the "IPSecType" is either AH or ESP. For unfragmented, non- IPSec, IPv6 packets, the use of the SMF DPD header option is necessary to support I-DPD operation. The SMF DPD header option is applied in the context of the of the IP packet. End systems or ingressing SMF gateways are responsible for applying this option to support DPD. The following table summarizes these packet identification types: +-----------+---------------------------------+---------------------+ | IPv6 | Packet DPD ID Context | Packet DPD ID | | Packet | | | | Type | | | +-----------+---------------------------------+---------------------+ | Fragment | | | | IPSec | | | | Packet | | | | Regular | <[taggerId:]srcAddr:dstAddr> | | UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I wonder whether for regular packets in IPv4, the whole mechanism = will work if very similar packets (e.g. beacons) are sent in a very = short time interval. Couldn't we use a timestamp header option of IPv4 = or something? I fear that just using the taggerId, src and dest is not = enough. And this is probably, at the time of writing, the most = predominant traffic type. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> that's an optional idea but there is no taggerID for IPv4. We could = copy the header option approach for IPv6. Many have an aversion to IPv4 = header options. +-----------+---------------------------------+---------------------+ Table 3: IPv6 I-DPD Packet Identification Types "IPSecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP). The "taggerId" is an optional feature of the IPv6 SMF-DPD header option. 5.1.3. IPv6 Hash-based DPD A default hash-based DPD approach (H-DPD) for use by SMF is specified as follows. An MD5 [RFC1321] hash of the non-mutable header fields, options fields, and data content of the IPv6 multicast packet is used to produce a 128-bit digest. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Maybe consider using a code-point for MD5. Maybe it makes sense to = be more flexible here. MD5 is already considered deprecated (I know, it = may not be relevant here because it is not used for cryptographical = integrity checks). Couldn't one also use other checksums (e.g. use the = CRC checksum from upper layers, if available?) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Actually that is an idea we have already released in the working = code, but I am very careful to MD5 is not used for cryptographic reasons = and to talk about the potential areas for further exploration of low = complexity, good collision property hash algorithms. In our prototype = code we have options for CRC, MD5, other approaches. As you say its not = limiting but is here as a default test case. =20 The lower 64 bits=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "lower" in what order? most-significant bit first? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> ok leftmost or most-significant bit first. similar to interface = identifiers in RFC 3041. of this digest (MD5_64) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Is that a known term, "MD5_64"? or is it defined here? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Not that its not a borrowed die, but I think I did that string so I = wouldn't get carpal tunnel. but I actually never reused it. Deleted. is used for SMF packet identification. The approach for calculating this hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [RFC4302] with respect to non-mutable fields. This approach should have a reasonably low probability of digest collision when packet headers and content are varying. MD5 is being applied in SMF only to provide a low probability of collision and is not being used for cryptographic or authentication purposes. A history of the packet hash values SHOULD be maintained within the context of the IPv6 packet header UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "packet header" + field + "" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> no I don't know what this means. No thats not whats meant by the = above. . This history is used by forwarding SMF nodes (non-ingress points)=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> has "non-ingress point" be defined before? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> confusing removed. =20 to avoid forwarding duplicates. SMF ingress points (i.e., source hosts or gateways) use this history to Macker, editor & SMF Design Team Expires September 7, 2010 [Page 15] =0C Internet-Draft SMF March 2010 confirm that new packets are unique with respect to their hash value. The Hash-assist Value (HAV) field described in Section 5.1.1 is provided as a differentiating field when a digest collision would otherwise occur. Note that the HAV is an immutable option field and SMF MUST use any included H-DPD hash assist value (HAV) option header (see Section 5.1.1) in its hash calculation. If a packet results in a digest collision (i.e., by checking the H-DPD digest history) within the limited history kept=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> the "limited history" is not defined before. It's unclear how long = to keep entries. It wasn't even mentioned before that entries are purged = after a predefined time. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> vague, just said DPD cache. =20 by SMF forwarders, the packet should be silently dropped. If a digest collision is detected at an SMF ingress point (i.e., including SMF- aware sources) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What is an "SMF-aware source"? How would it know? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Removed. , the H-DPD option header is applied with a HAV. The packet is retested for collision and the HAV is re-applied as needed UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What does "re-applied as needed" mean? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Clarified processing/calculation requirements =20 to produce a non-colliding hash value. The multicast packet is then forwarded with the added IPv6 SMF-DPD header option. The MD5 indexing and IPv6 HAV approaches are specified at present for consistency and robustness to suit experimental uses. Future approaches and experimentation may discover designs tradeoffs in hash robustness and efficiency worth considering. This MAY include reducing the maximum payload length that is processed, determining shorter indexes, or applying more efficient hashing algorithms. Use of the HAV functionality may allow for application of "lighter- weight" hashing techniques that might not have been initially considered due to poor collision properties otherwise. Such techniques could reduce packet processing overhead and memory requirements. 5.2. IPv4 Duplicate Packet Detection This section describes the mechanisms and options for IPv4 DPD. The IPv4 packet header 16-bit "Identification" field MAY be used for DPD assistance, but practical limitations may require alternative approaches in some situations. The following areas are described to support IPv4 DPD:: =20 1. the use of IPv4 fragment header fields for I-DPD when they exist, 2. the use of IPSec sequencing for I-DPD when a non-fragmented IPv4 IPSec packet is detected, and 3. a H-DPD approach. A specific SMF-DPD marking option is not specified for IPv4 since header options are not as tractable for end systems as for IPv6. IPv4 packets from a particular source are assumed to be marked with a temporally unique value in the "Identification" field of the packet header that can serve for SMF DPD purposes. However, in present operating system networking kernels, the IPv4 header "Identification" value is not always generated properly, especially when the "don't fragment" (DF) bit is set. The IPv4 I-DPD mode of this specification requires that IPv4 "Identification" fields are managed reasonably by Macker, editor & SMF Design Team Expires September 7, 2010 [Page 16] =0C Internet-Draft SMF March 2010 source hosts and that temporally unique values are set within the context of the packet header tuple. If this is not expected during an SMF deployment, then it is RECOMMENDED that the H-DPD method be used as a more reliable approach. Since IPv4 SMF does not specify an options header, the interoperability constraints are looser than the IPv6 version and forwarders may be operate with mixed H-DPD and I-DPD modes as long as they consistently perform the appropriate DPD routines outlined in the following sections. However, it is RECOMMENDED that a deployment be configured with a common mode for operational consistency. 5.2.1. IPv4 Identification-based DPD The following table summarizes the IPv4 I-DPD processing approach once a packet has passed the basic forwardable criteria described in earlier SMF sections. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Cite in which sections UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> done Within the table '*' indicates a don't care condition. +----+----+----------+---------+------------------------------------+ | df | mf | fragment | IPSec | IPv4 I-DPD Action | | | | offset | | | +----+----+----------+---------+------------------------------------+ | 1 | 1 | * | * | Invalid, Do Not Forward | | 1 | 0 | nonzero | * | Invalid, Do Not Forward | | * | 0 | zero | not | Tuple I-DPD Check and Process for | | | | | Present | Forwarding | | * | 0 | zero | Present | IPSec enhanced Tuple I-DPD Check | | | | | | and Process for Forwarding | | 0 | 0 | nonzero | * | Extended Fragment Offset Tuple | | | | | | I-DPD Check and Process for | | | | | | Forwarding | | 0 | 1 | zero or | * | Extended Fragment Offset Tuple | | | | nonzero | | I-DPD Check and Process for | | | | | | Forwarding | +----+----+----------+---------+------------------------------------+ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> The table headers should be explained (what is "df", "mf", fragment = offset.) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> ok I point out the IPv4 datagram references. Table 4: IPv4 I-DPD Processing Rules For performance reasons, IPv4 network fragmentation and reassembly of multicast packets within wireless MANET networks should be minimized, yet SMF provides the forwarding of fragments when they occur. If the IPv4 multicast packet is a fragment, SMF MUST use the fragmentation header fields for packet identification. This identification can be considered temporally unique in the context of the of the IPv4 packet. If the packet is an unfragmented IPv4 IPSec packet, SMF MUST use IPSec fields for packet identification. The IPSec header field can be considered a unique Macker, editor & SMF Design Team Expires September 7, 2010 [Page 17] =0C Internet-Draft SMF March 2010 identifier in the context of the where the "IPSecType" is either AH or ESP. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Does one take AH or ESP if both are available? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> If they were combined I would suggest using the outer AH. =20 Finally, for unfragmented, non-IPSec, IPv4 packets, the "Identification" field can be used for I-DPD purposes. The "Identification" field can be considered unique in the context of the IPv4 tuple. The following table summarizes these packet identification types: +-----------+---------------------------------+---------------------+ | IPv4 | Packet Identification Context | Packet Identifier | | Packet | | | | Type | | | +-----------+---------------------------------+---------------------+ | Fragment | | | | IPSec | | | | Packet | | | | Regular | | | UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Has been defined before? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> too much shorthand added the ref and clarification =20 | Packet | | | +-----------+---------------------------------+---------------------+ Table 5: IPv4 I-DPD Packet Identification Types "IPSecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP). =C9. 5.3. Internal Hash Computation Considerations UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I am not sure this belongs here (see previous comment on security). = Maybe to Security Considerations or extra document... UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Moved to security actually I think it was already redundantly there. Forwarding protocols that use DPD techniques, such as SMF, may be vulnerable to denial-of-service (DoS) attacks based on spoofing packets with apparently valid packet identifier fields. Such a consideration is pointed out in Section 10. In wireless environments, where SMF will most likely be used UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> It is an assumption, where SMF will be most likely used. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 , the opportunity for such attacks is more prevalent than in wired networks. In the case of IPv4 packets, fragmented IP packets or packets with IPSec headers applied, the DPD "identifier portions" of potential future packets that might be forwarded is highly predictable and easily subject to denial-of-service attacks against forwarding. A RECOMMENDED technique to counter this concern is for SMF implementations to generate an "internal" hash value that is concatenated with the explicit I-DPD packet identifier to form a unique identifier that is a function of the packet content as well as the visible identifier. SMF implementations could seed their hash generation with a random value to make it unlikely that an external observer could guess how to spoof packets used in a denial-of-service attack against forwarding. Since the hash computation and state is kept completely internal to SMF nodes, the cryptographic properties of this hashing would not need to be extensive and thus possibly of low complexity. Experimental implementations may determine that a lightweight hash of even only portions of packets may suffice to serve this purpose. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Is there any proof or analysis how/whether that works? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 For IPv4 I-DPD based on the limited 16-bit IP header "Identification" field, it is possible that use of this "internal hash" technique may also enhance I-DPD performance in cases where the IPv4 "Identification" field may frequently wrap due to sources supporting high data rate flows. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> It is "possible" that it improves performance? That sounds a bit = vague. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> too vague and inappropriate here I deleted it. =20 =C9=C9 6. Reduced Relay Set Forwarding and Relay Selection Capability SMF implementations MUST support CF as a basic forwarding mechanism when reduced relay set information is not available or not selected for operation. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> CF mode should be defined in the spec in a seperate section. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Done. In CF mode, each node transmits a locally generated or newly received forwardable packet exactly once. The DPD techniques described in Section 5 are critical to proper operation and prevent duplicate packet retransmissions by the same forwarding node. A goal of SMF is to apply reduced relay sets for more efficient multicast dissemination within dynamic topologies. To accomplish this SMF MUST support the ability to modify its multicast packet forwarding rules based upon relay set state received dynamically during operation. In this way, SMF forwarding operates effectively as neighbor adjacencies or multicast forwarding policies within the topology change. In early SMF experimental deployments, UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Which? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> I have a few references to prototypes and informative papers, = includes OLSR MPR, E-CDS and OSPFv3 MDR use going back to 2004. JM> I'll add a ref here. =20 the relay set information has been derived from coexistent unicast routing control plane traffic flooding processes. =46rom this experience, extra pruning considerations were sometimes required when utilizing a relay set from a separate routing protocol process. As an example, relay sets formed for the unicast control plane flooding MAY include additional redundancy that may not be desired for multicast forwarding use (e.g., biconnected CDS mesh for control plane purposes). UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "biconnected CDS mesh for control plane purposes" - definition? CDS = has not been used before. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> everyone previously asked me to take out all details on this, CDS = etc. Didn't want tutorial info now I need it back. glad you caught this. = I'll just make it more vague but removing it. I can refer some to = OSPFv3-MDR and SMF adaptation. =20 Here is a recommended criteria list for SMF relay set selection algorithm candidates: 1. Robustness to topological dynamics and mobility 2. Localized election or coordination of any relay sets 3. Reasonable minimization of CDS relay set size given above constraints 4. Heuristic support for preference or election metrics (Better enables scenario-specific management of relay set) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What does "Better enables scenario-specific management of relay set" = mean? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> bad grammar so I will remove it. Some relay set algorithms meeting these criteria are described in the Appendices of this document. Additional relay set selection algorithms may be specified in separate specifications in the future. The Appendices=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Which exact section? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> fixed in this document can serve as a template for the content of such potential future specifications. Figure 4 depicts a state information diagram of possible relay set control options. Macker, editor & SMF Design Team Expires September 7, 2010 [Page 20] =0C Internet-Draft SMF March 2010 Possible L2 Trigger/Information | | ______________ ______v_____ __________________ | MANET | | | | | | Neighborhood | | Relay Set | | Other Heuristics | | Discovery |----------->| Selection |<------| (Preference,etc) | | Protocol | neighbor | Algorithm | | | |______________| info |____________| |__________________| \ / \ / neighbor\ / Dynamic Relay info* \ ____________ / Set Status \ | SMF | / (State, {neighbor info}) `-->| Relay Set |<--' | State | -->|____________| / / ______________ | Coexistent | | MANET | | Unicast | | Process | |______________| Figure 4: SMF Relay Set Control Options =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> This picture is never explained. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> The following paragraphs attempted to explain the picture and modes = of operation I will try to clarify in this rev by adding an intro and = more discussion. There are basically three styles of SMF operation with reduced relay sets: 1. Independent operation: In this case, SMF performs its own relay set selection using information from an associated MANET NHDP process. In this case, NHDP messaging SHOULD be appended with additional [RFC5444] type-length-value (TLV) content to support SMF-specific requirements as discussed in Section 7 and for the applicable relay set algorithm described in the Appendices of this document or future specifications. 2. Operation with CDS-aware unicast routing protocol: In this case, a coexistent unicast routing protocol provides dynamic relay set state based upon its own control plane CDS or neighborhood discovery information. If it is desired that the SMF data plane forwarding use a different relay set selection algorithm than used for the routing protocol control plane, then the routing protocol NHDP instance (if applicable) SHOULD append its = messages with the appropriate SMF-specific TLV content (see Section 7 and the relay set algorithm Appendices). Macker, editor & SMF Design Team Expires September 7, 2010 [Page 21] =0C Internet-Draft SMF March 2010 3. Cross-layer Operation: In this case, SMF operates using neighborhood status and triggers from a cross-layer information base for dynamic relay set selection and maintenance (e.g., lower link layer) . =20 7. SMF Neighborhood Discovery Requirements This section defines the requirements for use of the MANET Neighborhood Discovery Protocol (NHDP) [NHDP] to support SMF operation. Note that basic CF forwarding requires no neighborhood topology knowledge since in this configured mode every SMF node relays all traffic. Supporting more reduced SMF relay set operation requires the discovery and maintenance of dynamic neighborhood topology information. The MANET NHDP protocol can be leveraged provide this necessary information, however there are SMF-specific requirements for related NHDP use. This is the case for both "independent" SMF operation where NHDP is being used specifically to support SMF or when one NHDP instance is used for both for SMF and a coexistent MANET unicast routing protocol. Core NHDP messages=20 and the resultant neighborhood information base are described separately within the NHDP specification. To summarize, the NHDP protocol provides the following basic functions: 1. 1-hop neighbor link sensing and bidirectionality checks of neighbor links, 2. 2-hop neighborhood discovery including collection of 2-hop neighbors and connectivity information, 3. Collection and maintenance of the above information across multiple interfaces, and 4. A method for signaling SMF information throughout the 2-hop neighborhood The Appendices=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Which precise sections? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> added of this document describe a set of CDS-based relay set selection algorithms that can be used to achieve efficient SMF operation, even in dynamic, mobile networks[MDDA07]. =20 When using these algorithms in conjunction with NHDP, a method verifying neighbor SMF operation is required in order to insure correct relay set selection. The core NHDP specification=20 along with SMF operation verification provides the necessary information required by these algorithms to conduct relay set selection. Verification of SMF operation may be done administratively or through the use of the SMF relay algorithms TLVs defined in this document. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Defined where? In which section? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> added. =20 Use of the SMF relay algorithm TLVs is RECOMMENDED when using NHDP for SMF neighborhood discovery. The following sub-sections specify some SMF-specific TLV types =C9.. 7.1. SMF Relay Algorithm TLV Types This section specifies TLV types to be used within NHDP messages=20 to identify the CDS relay set selection algorithm(s) in use. Two TLV types are defined, one message TLV type and one address TLV type. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I would move that to the end of the document (IANA Considerations) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JD> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JD> I am okay with moving the assignments to IANA but I find it useful = to describe them here so that their use is understood. JD> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> I added some of this discussion to IANA, but left purpose intro = here.. 7.1.1. SMF Message TLV Type The SMF message TLV type denoted SMF_TYPE is used to identify the existence of an SMF instance operating in conjunction with NHDP. This message type=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> You mean "TLV type"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> right got it fixed. makes use of the extended type field as defined by [RFC5444] to convey the CDS relay set selection algorithm currently in use by the SMF message originator. When NHDP is used to support SMF operation, the SMF_TYPE TLV, containing the extended type field with the appropriate value, SHOULD be included in NHDP_HELLO=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> NHDP_HELLO message has never been defined. It would be "HELLO = message as defined in [NHDP]" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> defined NHDP_HELLO as a HELLO from NHDP and ref'd 6130 messages generated. This allows SMF nodes to learn when neighbors are configured to use NHDP for information exchange including algorithm type and related algorithm information. This information can be used to take action, such as ignoring neighbor information using incompatible algorithms. It is possible that SMF neighbors MAY be configured differently and still operate cooperatively, but these cases will vary dependent upon the algorithm types designated. This document defines the following Message TLV typeTable 6 conforming to [RFC5444]. Extended type field values communicate "Relay Algorithm Type" to other 1-hop SMF neighbors and value fields may contain algorithm specific information. +---------------+---------------------+--------------------+ | | packetBB TLV syntax | Field Values | +---------------+---------------------+--------------------+ | type | | SMF_TYPE | | extended type | | | | length | | variable | | value | | variable | +---------------+---------------------+--------------------+ Table 6: SMF Type Message TLV In Table 6 is an 8-bit field=20 containing a number 0-255 representing the "Relay Algorithm Type" of the originator address of the corresponding NHDP message. Macker, editor & SMF Design Team Expires September 7, 2010 [Page 23] =0C Internet-Draft SMF March 2010 Possible values for the are defined in Table 7. The table provides value assignments, future IANA assignment spaces, and an experimental space. The experimental space use MUST NOT assume uniqueness and thus should not be used for general interoperable deployment prior to official IANA assignment. +---------------------+----------------------------------------+ | Extended Type Value | Algorithm | +---------------------+----------------------------------------+ | 0 | CF | | 1 | S-MPR | | 2 | E-CDS | | 3 | MPR-CDS | | 4-127 | Future Assignment with STD action | | 128-239 | No STD action required | | 240-255 | Experimental Space | +---------------------+----------------------------------------+ Table 7: SMF Relay Algorithm Type Values Acceptable and fields of an SMF_TYPE TLV are extended type dependent. The appropriate algorithm type, as conveyed in the field, defines the meaning and format of its TLV field. For algorithms defined by this document see the appropriate appendix for the field format. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Cite precise sections in the appendix. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 7.1.2. SMF Address Block TLV Type An address block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor relay algorithm)=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> + "as specified in " UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> JD added Table 8, is specified so that CDS relay algorithm operation and configuration can be shared among 2-hop neighborhoods. Some relay algorithms require two hop neighbor configuration in order to correctly select relay sets. It is also useful when mixed relay algorithm operation is possible. The message SMF_TYPE TLV and address block SMF_NBR_TYPE TLV types share a common format. Macker, editor & SMF Design Team Expires September 7, 2010 [Page 24] =0C Internet-Draft SMF March 2010 +---------------+---------------------+--------------------+ | | packetBB TLV syntax | Field Values | +---------------+---------------------+--------------------+ | type | | SMF_NBR_RELAY_ALG | | extended type | | | | length | | variable | | value | | variable | +---------------+---------------------+--------------------+ Table 8: SMF Type Address Block TLV in Table 7=20 is an 8-bit field containing a number 0-255 representing the "Relay Algorithm Type" value that corresponds to any indicated address=20 in the address block. Note that "Relay Algorithm Type" values for 2-hop neighbors can be conveyed in a single TLV or multiple value TLVs as described in [RFC5444]. It is expected that SMF nodes using NHDP construct address blocks with SMF_NBR_TYPE TLVs to advertise "Relay Algorithm Type" and to advertise neighbor algorithm values received in SMF_TYPE TLVs from those neighbors. Again values for the are defined in Table 7. Value length and value content=20 of an SMF_NBR_TYPE TLV is defined by the appropriate algorithm type contained in the extended type field. See appropriate the appendix for definitions of value fields for algorithms defined by this document. 8. SMF Border Gateway Considerations It is expected that SMF will be used to provide simple forwarding of multicast traffic within a MANET or mesh routing topology. A border router approach=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Definition of "border router approach"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D should be used to allow interconnection of SMF areas with networks using other multicast routing protocols (e.g., PIM). It is important to note that there are many scenario-specific issues that should be addressed when discussing border routers. At the present time, experimental deployments of SMF and PIM border router approaches have been demonstrated. Some of the functionality border routers may need to address includes the following: 1. Determining which multicast group traffic transits the border router whether entering or exiting the attached MANET routing region(s). 2. Enforcement of TTL threshold or other scoping policies. 3. Any marking or labeling to enable DPD on ingressing packets. Macker, editor & SMF Design Team Expires September 7, 2010 [Page 25] =0C Internet-Draft SMF March 2010 4. Interface with exterior multicast routing protocols. 5. Possible operation with multiple border routers (presently beyond scope of this document). 6. Provisions for participating non-SMF nodes. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Should be made clear that these 6 points are explained in sections = later UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> ok =20 Note the behavior of SMF border routers is the same as that of non- border SMF nodes when forwarding packets on interfaces within the MANET routing region. Packets that are passed outbound to interfaces operating fixed-infrastructure multicast routing protocols SHOULD be evaluated for duplicate packet status since present standard multicast forwarding mechanisms do not usually perform this function. 8.1. Forwarded Multicast Groups Mechanisms for dynamically determining groups for forwarding into a MANET SMF routing region is an evolving technology area. Ideally, only groups for which there is active group membership should be injected into the SMF domain. This can be accomplished by providing an IPv4 Internet Group Membership Protocol (IGMP) or IPV6 Multicast Listener Discovery (MLD) proxy protocol so that MANET SMF nodes can inform attached border routers (and hence multicast networks) of their current group membership status. For specific systems and services it may be possible to statically configure group membership joins in border routers, but it is RECOMMENDED that some form of IGMP/MLD proxy or other explicit, dynamic control of membership be provided. Specification of such an IGMP/MLD proxy protocol is beyond the scope of this document. Outbound traffic is less problematic. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Less problematic than what? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> than inbound but I removed the observational comment. =20 SMF border routers can perform duplicate packet detection and forward non-duplicate traffic that meets TTL/hop limit and scoping criteria to other interfaces. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Other interfaces than what? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM>next comment =20 Appropriate IP multicast routing (PIM, etc) on those interfaces=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Which are "those" interfaces? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> explained the above as border multicast router interfaces external = to SMF routing domain denied earlier. =20 can then make further forwarding decisions with respect to the given traffic destination and potentially its=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "its"... whose source address? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> yeah too vague. source addresses. Note that the presence of multiple border routers associated with a MANET routing region raises additional issues. This is further discussed in Section 8.4 but further work is expected to be needed here. 8.2. Multicast Group Scoping Multicast scoping is used by network administrators to control the network routing regions reachable by multicast packets. This is usually done by configuring external interfaces of border routers in the border of an routing=20 region to not forward multicast packets which must be kept within the routing region. This is commonly done based on TTL of messages or the basis of group addresses. These schemes are known respectively as: Macker, editor & SMF Design Team Expires September 7, 2010 [Page 26] =0C Internet-Draft SMF March 2010 1. TTL scoping. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> + hop limit? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> yep. =20 2. Administrative scoping. For IPv4, network administrators can configure border routers with the appropriate TTL thresholds or administratively scoped multicast groups for the router interfaces as with any traditional multicast router. However, for the case of TTL scoping it SHOULD be taken into account that the packet could traverse multiple hops within the MANET SMF routing region before reaching the border router. Thus, TTL thresholds SHOULD be selected carefully. For IPv6, multicast address spaces include information about the scope of the group. Thus, border routers of an SMF routing region know if they must forward a packet based on the IPv6 multicast group address. For the case of IPv6, it is RECOMMENDED that a MANET SMF routing region be designated a site.=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> That is a bit vague. "designated a site" (note that unicast = site-scope IPv6 addresses are deprecated). I would change that to = "site-scope multicast addresses SHOULD be used as destination of IPv6 = datagrams". UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> yeah make it clear its site-scoped multicast. BUt that I think = should be ok and what an SMF domain really needs. =20 Thus, all IPv6 multicast packets in the range FF05::/16 SHOULD be kept within the MANET SMF routing region by border routers. IPv6 packets in any other wider range scopes (i.e. FF08::/16, FF0B::/16 and FF0E::16) MAY traverse border routers unless other restrictions different from the scope applies. Given that scoping of multicast packets is performed at the border routers, and given that existing scoping mechanisms are not designed to work with mobile routers, it is assumed that non-border SMF routers will not stop forwarding multicast data packets of an appropriate site scoping. That is, it is assumed that an SMF routing region is a site scoped area. 8.3. Interface with Exterior Multicast Routing Protocols The traditional operation of multicast routing protocols is tightly integrated with the group membership function.=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Add citation? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> probable Deering 90 would work. =20 Leaf routers=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Definition of "lead router"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> its leaf router. Early Deering DVMRP or PIM later. are configured to periodically gather group membership information, while intermediate routers conspire to create multicast trees connecting routers with directly-connected multicast sources and routers with active multicast receivers. In the concrete case of SMF, border routers can be considered leaf routers. Mechanisms for multicast sources and receivers to interoperate with border routers over the multihop MANET SMF routing region as if they were directly connected to the router need to be defined. =20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> But aren't they directly "connected" (whatever that means) with the = border routers? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following issues need to be addressed: 1. A mechanism by which border routers gather membership information 2. A mechanism by which multicast sources are known by the border router Macker, editor & SMF Design Team Expires September 7, 2010 [Page 27] =0C Internet-Draft SMF March 2010 3. A mechanism for exchange of exterior routing protocol messages across the MANET routing region if the MANET routing region is to provide transit connectivity for multicast traffic. It is beyond the scope of this document to address implementation solutions to these issues. As described in Section 8.1, IGMP/MLD proxy mechanisms can be deployed to address some of these issues. Similarly, exterior routing protocol messages could be tunneled or conveyed across the MANET routing region. But, because MANET routing regions are multi-hop and potentially unreliable UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Please specifiy what that means, "MANET regions are multi-hop and = potentially unreliable" UH> Links between routers may be unreliable, not MANET regions (which is = undefined)=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> gone. , as opposed to the single-hop LAN interconnection that neighboring IP Multicast routers might typically enjoy, additional provisions may be required to achieve successful operation. The need for the border router to receive traffic from recognized multicast sources within the MANET SMF routing region is important to achieve a smooth interworking=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> What does "smooth interworking" mean? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> changed with existing routing protocols. For instance, PIM-S requires routers with locally attached multicast sources to register them to the Rendezvous Point (RP) so that nodes can join the multicast tree. In addition, if those sources are not advertised to other autonomous systems (AS) using MSDP, UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> MSDP has not been cited. Nor was PIM-S. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> WE should do so. receivers in those external networks are not able to join the multicast tree for that source. 8.4. Multiple Border Routers A MANET might be deployed with multiple participating nodes having connectivity to external (to the MANET), fixed-infrastructure networks. Allowing multiple nodes to forward multicast traffic to/ from the MANET routing region can be beneficial since it can increase reliability, and provide better service. For example, if the MANET routing region were to fragment with different MANET nodes maintaining connectivity to different border routers, multicast service could still continue successfully. But, the case of multiple border routers connecting a MANET routing region to external networks presents several challenges for SMF: 1. Detection/hash collision/sequencing=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Better make a real sentence out of these two / UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> right. =20 of duplicate unmarked IPv4 or IPv6 (without IPSec encapsulation or DPD option) packets possibly injected by multiple border routers. 2. Source-based relay algorithms handling of duplicate traffic injected by multiple border routers. 3. Determination of which border router(s) will forward outbound multicast traffic. 4. Additional challenges with interfaces to exterior multicast routing protocols. One of the most obvious issues=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Not scientific language UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> fixed. =20 is when multiple border routers are Macker, editor & SMF Design Team Expires September 7, 2010 [Page 28] =0C Internet-Draft SMF March 2010 present and may be alternatively (due to route changes) or simultaneously injecting common traffic into the MANET routing region that has not been previously marked for SMF DPD. Different border routers would not be able to implicitly synchronize sequencing of injected traffic since they may not receive exactly the same messages due to packet losses. For IPv6 I-DPD operation, the optional "TaggerId" field described for the SMF-DPD header option can be used to mitigate this issue. When multiple border routers are injecting a flow into a MANET routing region, there are two forwarding policies that SMF I-DPD nodes may implement: UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "routers running SMF in I-DPD mode" instead of "SMF I-DPD node" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM>ok =20 1. Redundantly forward the multicast flows (identified by ) from each border router, performing DPD processing on a or basis, or 2. Use some basis to select the flow of one tagger (border router) over the others and forward packets for applicable flows (identified by ) only for that "Tagger ID" until timeout or some other criteria to favor another tagger occurs. It is RECOMMENDED that the first approach be used in the case of I-DPD operation unless the SMF system=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Definition of "SMF system"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> on review that part of the sentence really isn't needed its gone. =20 is specifically designed to implement the second option. Additional specification may be required to describe an interoperable forwarding policy based on this second option. Note that the implementation of the second option requires that per-flow (i.e., ) state be maintained for the selected "Tagger ID". The deployment of a H-DPD operational mode may alleviate DPD resolution when ingressing traffic comes from multiple border routers. Non-colliding hash indexes (those not requiring the H-DPD options header in IPv6) should be resolved effectively. JM> I am dumping this whole sections. Its discussion oriented on a side = topic. and not too relevant to the spec. Other use case documents could be = written. 9. Non-SMF MANET Node Interaction There may be scenarios in which some neighboring wireless MANET node are not running SMF and/or not forwarding, but are interested in receiving multicast data. For example, a MANET service UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Definition of "MANET service"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 might be deployed that is accessible to wireless edge devices=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Definition of "wireless edge devices"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 that do not participate in MANET routing, NHDP, and/or SMF forwarding operation. These devices include: 1. Devices that opportunistically receive multicast traffic due to proximity with SMF relays (possibly with asymmetric IP connectivity=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Definition of "asymmetric IP connectivity"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 e.g., sensor network device). Macker, editor & SMF Design Team Expires September 7, 2010 [Page 29] =0C Internet-Draft SMF March 2010 2. Devices that participate in NHDP (directly or via routing protocol signaling) but do not forward traffic. Note there is no guarantee of traffic delivery with category 1 above, but the election heuristics shown in Figure 4 MAY be adjusted via management to better support such devices. However, it is RECOMMENDED that nodes participate in NHDP when possible. =20 Such devices=20 may also transmit multicast traffic, but it is important to note that SMF routing regions using source-specific relay set algorithms such as (S-MPR) may not forward such traffic. These devices SHOULD also listen for any IGMP/MLD Queries that are provided and transmit IGMP/MLD Reports=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Definition of "IGMP Queries, IGMP Reports"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D for groups they have joined per usual IP Multicast operation. While it is not in the scope of this document, IGMP/MLD proxy mechanisms may be in place to convey group membership information to any border routers or intermediate systems providing IP Multicast routing functions. 10. Security Considerations Gratuitous use of option headers can cause problems in routers. Routers outside of MANET routing regions=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Definition of "routers outside of MANET routing region"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D should ignore SMF-specific header options if encountered. The header options types are encoded appropriately to allow for this behavior. Several SMF DoS scenarios have been described throughout the document and recommended mitigation strategies have been presented. Here we summarize a few of these areas for reference. Sequence-based packet identifiers are predictable and thus provide an opportunity for a denial-of-service attack against forwarding. The use of the "internal hashing" as described in Section 5.3 for the I-DPD operation helps to mitigate denial-of-service attacks on predictable packet identifiers. In this case, spoofed packets MAY be forwarded but the additional internal history identifier will protect against false collision events that may result from a predictive denial-of-service attack strategy. Another potential denial-of-service attack against SMF forwarding is possible when a malicious node has a form of "wormhole" access (via a directional antenna, etc)=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Definition of whormhole? sounds for me like a "normal" link with = lower RTTs/delays... UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> rewritten a little. =20 to preview packets before a particular SMF node would receive them. The malicious node could reduce the TTL or Hop Limit of the packet and transmit it to the SMF node causing it to forward the packet with a limited TTL (or even drop it) and make a DPD entry that would block forwarding of the subsequently-arriving valid packet with appropriate TTL value. This would be a relatively low-cost, high-payoff attack that would be hard to detect and thus attractive to potential attackers. An approach of caching TTL Macker, editor & SMF Design Team Expires September 7, 2010 [Page 30] =0C Internet-Draft SMF March 2010 information with DPD state and taking appropriate forwarding actions is identified in Section 4 to mitigate this form of attack. The support of forwarding IPSec datagrams without further modification for both IPv4 and IPv6 is supported by this specification. Authentication mechanisms to identify the source of IPv6 option headers should be considered to reduce vulnerability to a variety of attacks. 11. IANA Considerations This document raises multiple IANA Considerations. These include the IPv6 SMF_DPD hop-by-hop Header Extension defined and multiple Type- Length-Value (TLV) constructs (see [RFC5444]) used to extend NHDP operation as needed to support different forms of SMF operation. 11.1. IPv6 SMF_DPD Header Extension This document requests IANA assignment of the "SMF_DPD" hop-by-hop option type from the IANA "IPv6 Hop-by-Hop Options Option Type" registry (see Section 5.5 of [RFC2780]). The format of this new option type is described in Section 5.1.1. A portion of the option data content is the "taggerIdType" that provides a context for the "taggerId" that is optionally included to identify the intermediate system=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Definition of "intermediate system"? Difference to "intermediate = router"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> ok =20 that added the SMF_DPD option to the packet. This document defines a name-space for IPv6 SMF_DPD Tagger Identifier Types: ietf:manet:smf:taggerIdTypes [NHDP] Clausen, T. and et al, "MANET Neighborhood Discovery Protocol", draft-ietf-manet-nhdp-11, Work in progress , UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Several times in citations there are additional blanks (e.g. here = before the comma). NHDP is in version 14 now UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Well its RFC6130 now and reflected in v11 =20 October 2009. Macker, editor & SMF Design Team Expires September 7, 2010 [Page 33] =0C Internet-Draft SMF March 2010 [OLSRv2] Clausen, T. and et al, "Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsrv2-10, Work in progress , September 2009. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> OLSRv2-11. Is OLSR and OLSRv2 really normative? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Well as a good ref for the S-MPR relay set election yes. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999. [RFC2780] Bradner, S., "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", March 2000. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol", 2003. [RFC4302] Kent, S., "IP Authentication Header", December 2005. [RFC5444] Clausen, T. and et al,=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> and et al is double double... UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> awesome awesome find ;-) I meant to properly update these RFC refs = from bibxml. "Generalized MANET Packet/Message Format", RFC 5444, February 2009. 13.2. Informative References [GM99] Garcia-Luna-Aceves, JJ. and E. Madruga, "The core-assisted mesh protocol", Selected Areas in Communications, IEEE Journal on Volume 17, Issue 8, August 1999. [JLMV02] Jacquet, P., Laouiti, V., Minet, P., and L. Viennot, "Performance of multipoint relaying in ad hoc mobile routing protocols", Networking , 2002. [MDC04] Macker, J., Dean, J., and W. Chao, "Simplified Multicast Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004 Proceedings , 2004. Macker, editor & SMF Design Team Expires September 7, 2010 [Page 34] =0C Internet-Draft SMF March 2010 [MDDA07] Macker, J., Downard, I., Dean, J., and R. Adamson, "Evaluation of distributed cover set algorithms in mobile ad hoc network for simplified multicast forwarding", ACM SIGMOBILE Mobile Computing and Communications Review Volume 11 , Issue 3 (July 2007), July 2007. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Twice July 2007 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> hey thats xml2rfc being too smart. the xml bib ref was bad. = =20 It is RECOMMENDED that the SMF_TYPE:E-CDS message TLV=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> as defined where? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D be included in NHDP_HELLO messages that are generated by nodes conducting E-CDS SMF operation. It is also RECOMMENDED that the SMF_NBR_TYPE:E-CDS address block TLV be used to advertise neighbor nodes that are also conducting E-CDS SMF operation. A.1. E-CDS Relay Set Selection Overview The E-CDS relay set selection requires 2-hop neighborhood information collected through NHDP or another process. Relay nodes, in E-CDS SMF selection, are "self-elected" using a router identifier (Router ID) and an optional nodal metric, referred to here as "Router Priority" for all 1-hop and 2-hop neighbors. To ensure proper relay set self- election, the Router ID and Router Priority MUST be consistent among nodes participating=20 and it is RECOMMENDED that NHDP be used to share this information.=20 The Router ID is a logical identification that MUST be consistent across interoperating SMF neighborhoods and it is RECOMMENDED to be chosen as the largest interface address advertised by NHDP.=20 The E-CDS self-election process can be summarized as follows: 1. If an SMF node has a higher ordinal (Router Priority, Router ID) than all of its symmetric neighbors, it elects itself to act as a forwarder for all received multicast packets, 2. Else, if there does not exist a path from neighbor "j"=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "j" is never used. Can be omitted UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JD> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JD> s/from neighbor "j" with/from the neighbor with/ JD> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D with largest (Router Priority, Router ID) to any other neighbor, _via_ neighbors with larger values of (Router Priority, Router ID), then it elects itself to the relay set. The basic form of E-CDS described and applied within this specification does not provide for redundant relay set election (e.g., bi-connected) but such capability is supported by the basic E-CDS design. =C9. A.3. E-CDS Neighborhood Discovery Requirements It is possible to perform E-CDS relay set selection without modification of NHDP, basing the self-election process exclusively on the Router IDs (interface addresses)=20 of participating SMF nodes. However steps MUST be taken to insure that all NHDP instances=20 not using SMF_TYPE:E-CDS full type message TLVs are in fact running SMF E-CDS, otherwise incorrect forwarding may occur. Furthermore, it has been shown=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "it has been shown" where? Citation UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM> Dean's internal experiments not sure it was published so removed. B.3. S-MPR Neighborhood Discovery Requirements Nodes may optionally signal "Router Priority" or "WILLINGNESS"=20 to become MPR nodes for their one hop neighbors by using the SMF_TYPE:S- MPR message block TLV value field defined as such: +---------------+---------+-----------------+ | Length(bytes) | Value | Router Priority | +---------------+---------+-----------------+ | 0 | N/A | 64 | | 1 | | 0-127 | +---------------+---------+-----------------+ Table 13: S-MPR Message TLV Values Where is a one byte bit field=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "one octet long bit field" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JM>done which is defined as: bit 0: is reserved and SHOULD be set to 0. ... B.4. S-MPR Selection Algorithm This section describes a basic algorithm for the S-MPR selection process. Note that the selection is with respect to a specific interface of the node performing selection and other node interfaces referenced are reachable from this reference node interface. This is consistent with the S-MPR forwarding rules described above. When multiple interfaces per node are used, it is possible to enhance the overall selection process across multiple interfaces such that common nodes are selected as MPRs for each interface to avoid unnecessary inefficiencies in flooding. This is described further in [OLSRv2]. The following steps describe a basic algorithm for conducting S-MPR selection for a node interface "n0": 1. Initialize the set "MPR" to empty. 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". 3. Initialize the set "N2" to include all 2-hop neighbors, excluding "n0" and any nodes in "N1". Nodes which are only reachable via "N1" nodes=20 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> add "and" between N1 and nodes? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JD> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JD> No. We may need to reproduce the tuple format I suggested for ECDS = to be comparable. It seems the only way to cleanly group addresses and = nodes. The tuple format will clean this up and make the below more = clear. JD> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 with router priority values of NEVER are also excluded. 4. For each interface "y" in "N1", initialize a set "N2(y)" to UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> N1 contains "1-hop neighbors" (I assume originator addresses or = so... unclear as in step 2). But not interface. Maybe it could contain = interface addresses, but not interfaces UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JD> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JD> Well its going to be tuples which include the "Sending Address List" = as defined in NHDP section 12.2 definitions section. This definition = should be use elsewhere too. JD> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D include any interfaces in "N2" that are 1-hop neighbors of "y". 5. For each interface "x" in "N1" with a router priority value of "ALWAYS" (or using CF relay algorithm), select "x" as a MPR: A. Add "x" to the set "MPR" and remove "x" from "N1". B. For each interface "z" in "N2(x)", remove "z" from "N2" C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)" =0C --Apple-Mail-1--298106070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 10, 2011, at 6:15 PM, Joe Macker wrote: > I have a plan to put out a new version by Monday's cutoff time. > Its nice that I can update one of the normative references now with = RFC 6130. >=20 > -Joe > On Mar 4, 2011, at 2:19 PM, Stewart Bryant wrote: >=20 >> This is a regular ping to see how you are getting on with this draft? >>=20 >> Stewart >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail-1--298106070-- From ulrich@herberg.name Tue Mar 15 16:21:24 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9892B3A6EF2 for ; Tue, 15 Mar 2011 16:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 r+cPgOodpk+G for ; Tue, 15 Mar 2011 16:21:22 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 86A9C3A6D74 for ; Tue, 15 Mar 2011 16:21:22 -0700 (PDT) Received: by wwa36 with SMTP id 36so947662wwa.13 for ; Tue, 15 Mar 2011 16:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=cKiS2gANox/PngS0A/DVKXCMh6z5X0SdYwWyi29hj6Q=; b=uKEd6NqVrpvBFG+FsZkpBJUZ/qg+7IW2HzL1BAdOBLStCS+F5rCwQVaEpOBg1xn9up j3zMVFHhPvzZpWInPjxtj5XQ5JO/vnZkIBEh/6cpv5ahOrc/b4jmDGViUmNS8nB1qcNs suBEPKoiSuWmv+Lxw3D11lyFDt27DH1BINT/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=l1buAps5h6QQcuwKKX4M+PispmK+xcgo+4oTNJZ7xSY68+Oee/SdHfykRrVGfUydgV PZwjBCPeo/dj43Z7HB12I45Cg2lmYy/2s6MZlzee8TPWbMZge8vLxzCWZ6SPq/6Gm9YF Va4Jb+4Fwfp6bTPrYS455qLrxQyOqfBTxOEIk= Received: by 10.216.238.194 with SMTP id a44mr62817wer.51.1300231367321; Tue, 15 Mar 2011 16:22:47 -0700 (PDT) Received: from [192.168.1.15] (AMontsouris-753-1-2-157.w90-2.abo.wanadoo.fr [90.2.129.157]) by mx.google.com with ESMTPS id k76sm217716wej.19.2011.03.15.16.22.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2011 16:22:45 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3777A4F1-CDEE-4505-A018-A12716F0B9AB@herberg.name> X-Mailer: iPad Mail (8F190) From: Ulrich Herberg Date: Wed, 16 Mar 2011 00:22:58 +0100 To: Joseph Macker Cc: "manet@ietf.org" Subject: Re: [manet] SMF update and comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:21:24 -0000 Thanks Joe for the efforts!=20 On Mar 14, 2011, at 20:43, Joseph Macker wrote: > SMF version 11 has been uploaded. > Here is a thread related to Ulrich's older comments that have been address= ed. >=20 > UH> is comment and JM> is my response. Most of the comments were > incorporated fixed. > Technical content has not really changed but some vague content has > been removed or clarified. >=20 > Thanks Ulrich. >=20 >=20 > -Joe > From jpmacker@gmail.com Tue Mar 15 19:12:27 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68AE63A6BA1 for ; Tue, 15 Mar 2011 19:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 tagged_above=-999 required=5 tests=[AWL=0.590, 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 aMSiGjVeQmEc for ; Tue, 15 Mar 2011 19:12:16 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 68B073A6B5B for ; Tue, 15 Mar 2011 19:12:16 -0700 (PDT) Received: by wyb42 with SMTP id 42so1309087wyb.31 for ; Tue, 15 Mar 2011 19:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=81OVaEUPQ20pCp3RIHVjqacJO19sXQkC1KBdH+1tLoc=; b=hPDpkNzIGSM6g8iH6vZA/X0aoN33LxD2VbEaCTyGtaYIiF8KAbyfStcXXB4bNnv0jl eZx1SvfR0uyAvtyx/7bxmnwaTUxcph86o6bg6mMAmCteBwlMIe4elIBT4/ihfRDiZi/r 6q01kUaXkPtOOwkTidP0+LFaY4vJb7Azgy8TE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xap8weOwW9jsSZQCpG9jfJoOnIv7UhlXdglqTc0DWh4NDtCuux8bofAVqrQ4fV25iV Seze1n+oOK86GwQQ36TTlq8XdvkZhGuJ752dLg4sgdiYyngjY1eceFCTAnzB04O1eRTi IZzSekyP+UalN2HKo0mlWBuTCBBSifPqEc6zU= MIME-Version: 1.0 Received: by 10.216.62.144 with SMTP id y16mr163197wec.101.1300241621636; Tue, 15 Mar 2011 19:13:41 -0700 (PDT) Received: by 10.216.163.210 with HTTP; Tue, 15 Mar 2011 19:13:41 -0700 (PDT) In-Reply-To: <3777A4F1-CDEE-4505-A018-A12716F0B9AB@herberg.name> References: <3777A4F1-CDEE-4505-A018-A12716F0B9AB@herberg.name> Date: Tue, 15 Mar 2011 22:13:41 -0400 Message-ID: From: Joseph Macker To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] SMF update and comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 02:12:27 -0000 Thank you as well, I am sorry it took so long. My surgical problems in Nov/Dec10 were really unexpected. Although its good in a way to have waited since NHDP is normative.. -Joe On Tue, Mar 15, 2011 at 7:22 PM, Ulrich Herberg wrote: > Thanks Joe for the efforts! > > On Mar 14, 2011, at 20:43, Joseph Macker wrote: > >> SMF version 11 has been uploaded. >> Here is a thread related to Ulrich's older comments that have been addressed. >> >> UH> is comment and JM> is my response. Most of the comments were >> incorporated fixed. >> Technical content has not really changed but some vague content has >> been removed or clarified. >> >> Thanks Ulrich. >> >> >> -Joe >> > From rakesh.mishra.rbl@gmail.com Sun Mar 20 10:12:23 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042003A6BC5 for ; Sun, 20 Mar 2011 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, 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 IEL2TyalTU-n for ; Sun, 20 Mar 2011 10:12:21 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 63AF73A6BCD for ; Sun, 20 Mar 2011 10:12:21 -0700 (PDT) Received: by fxm15 with SMTP id 15so5315087fxm.31 for ; Sun, 20 Mar 2011 10:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=YBStNFuYuF+TQ3IdRUhdoFgv5UMIuL76Z96AX1mDnzo=; b=tynCpk9BWOX3LweuSK8O0rRjStcYD48V/bfgSqHE47THuYvBlvv32DhonN8aB2bNnD 8XhcHDTavG7nHqIIU5eIEH9mWCeThQ0qG2LN8sp6TyEhniZNWUyReZnC2oW6iE6FoGSF PZ1347xk2Xy+2Wf5xkjWTaieHvGCix4Wu9wBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=iXTxRZmqfdmtqQrrDyow8VQF09A8lKdDpUes3e0fwhGMPtgcvjO/q+v12Tlx7GcRmk EmTaNwD2uwyLgL2DcVn/0X1B2aykOfDD0cfSsO0Lmnydua769c6S6tPoVc5J4lUbyxAx 3r1vC704OterlS0K5iXTZ8Zxysfo2Fbm436rc= MIME-Version: 1.0 Received: by 10.223.6.11 with SMTP id 11mr3791750fax.101.1300641231209; Sun, 20 Mar 2011 10:13:51 -0700 (PDT) Received: by 10.223.116.139 with HTTP; Sun, 20 Mar 2011 10:13:51 -0700 (PDT) In-Reply-To: References: <8F1115C67A7272DD84754AA4BE13CA77@dlfse> Date: Sun, 20 Mar 2011 22:43:51 +0530 Message-ID: From: rakesh mishra To: manet@ietf.org Content-Type: multipart/alternative; boundary=00151747849e912abc049eed2231 Subject: [manet] Fwd: ***[Possible UCE]*** Congress on Computer Applications and Computational Science, Bali, 15-17 Nov 2011 [EI Compendex, ISTP, IEEE Xplore] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 17:12:23 -0000 --00151747849e912abc049eed2231 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: Nabendu Chaki Date: Thu, Mar 17, 2011 at 1:14 PM Subject: Fwd: ***[Possible UCE]*** Congress on Computer Applications and Computational Science, Bali, 15-17 Nov 2011 [EI Compendex,ISTP,IEEE Xplore] To: rakesh mishra , novarun deb < novarun.db@gmail.com> ---------- Forwarded message ---------- From: Jane Lew Date: Thu, Mar 17, 2011 at 10:10 AM Subject: ***[Possible UCE]*** Congress on Computer Applications and Computational Science, Bali, 15-17 Nov 2011 [EI Compendex,ISTP,IEEE Xplore] To: nabendu@ieee.org Dear Author, Please forward to those who may be interested. Thank you. The 2011 2nd International Congress on Computer Applications and Computational Science (CACS 2011) http://irast.net/conferences/CACS/2011 15-17 November 2011, Bali, Indonesia CACS 2010 aims to bring together researchers and scientists from academia, industry, and government laboratories to present new results and identify future research directions in computer applications and computational science. All papers published in the CACS 2011 proceedings will be included in the IEEE Xplore and indexed in both Ei Compendex and ISTP. CACS 2011 has appeared in the IEEE Conferences (Conference Record # 18959, IEEE Catalog Number: CFP1175N-CDR, ISBN: 978-1-61284-995-9). Topics of interest include, but are not limited to: =B7 Computer Architecture and VLSI =B7 Computer Control and Robotics =B7 Computers in Education and Learning Technologies =B7 Computer Networks and Data Communications =B7 Data Mining and Data Engineering =B7 Energy and Power Systems =B7 Intelligent Systems and Autonomous Agents =B7 Internet and Web Systems =B7 Scientific Computing and Modeling =B7 Signal, Image and Multimedia Processing =B7 Software Engineering Bali is a favorite vacation destination for many nationalities. Bali's natural attractions include miles of sandy beaches, picturesque rice terraces, towering active volcanoes over 3,000 meters high, fast flowing rivers, deep ravines, pristine crater lakes, sacred caves, and lush tropical forests full of exotic wildlife. The island's rich cultural heritage is visible everywhere - in over 20,000 temples and palaces, in many colorful festivals and ceremonies, in drama, music, and dance. Bali is also well-known for its night life. Come to Bali enjoying the beautiful environment and fun here! Paper Submission Deadline: 15 May 2011 Review Decision Notifications: 15 August 2011 Final Papers and Author Registration Deadline: 9 September 2011 To unsubscribe, reply with =93unsubscribe nabendu@ieee.org =94 in your email subject or the first line of the email body. With kind regards, Jane Lew -- Dr. Nabendu Chaki HoD Department of Computer Science & Engineering & Coordinator A K Choudhury School of Information Technology University of Calcutta, India www.cucse.org/nc.htm --=20 -------------------- Mob +919415758102 --00151747849e912abc049eed2231 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------<= br>From: Nabendu Chaki = <nchaki@gmail.com>
= Date: Thu, Mar 17, 2011 at 1:14 PM
Subject: Fwd: ***[Possible UCE]*** Congress on Computer Applications and Co= mputational Science, Bali, 15-17 Nov 2011 [EI Compendex,ISTP,IEEE Xplore]To: rakesh mishra <rake= sh.mishra.rbl@gmail.com>, novarun deb <novarun.db@gmail.com>


---------- Forwarded message ----------
From: Jane Lew <cacs@cacs2010.org>
Date: Thu, Mar 17, 2011 at 10:10 AM
Subject: ***[Possible UCE]*** Congress on Computer Applications and
Computational Science, Bali, 15-17 Nov 2011 [EI Compendex,ISTP,IEEE
Xplore]
To: nabendu@ieee.org


Dear Author,

Please forward to those who may be interested. Thank you.

The 2011 2nd International Congress on Computer Applications and
Computational Science

(CACS 2011)

http:/= /irast.net/conferences/CACS/2011

15-17 November 2011, Bali, Indonesia

CACS 2010 aims to bring together researchers and scientists from
academia, industry, and government laboratories to present new results
and identify future research directions in computer applications and
computational science.

All papers published in the CACS 2011 proceedings will be included in
the IEEE Xplore and indexed in both Ei Compendex and ISTP. CACS 2011
has appeared in the IEEE Conferences (Conference Record # 18959, IEEE
Catalog Number: CFP1175N-CDR, ISBN: 978-1-61284-995-9).

Topics of interest include, but are not limited to:

=B7 Computer Architecture and VLSI

=B7 Computer Control and Robotics

=B7 Computers in Education and Learning Technologies

=B7 Computer Networks and Data Communications

=B7 Data Mining and Data Engineering

=B7 Energy and Power Systems

=B7 Intelligent Systems and Autonomous Agents

=B7 Internet and Web Systems

=B7 Scientific Computing and Modeling

=B7 Signal, Image and Multimedia Processing

=B7 Software Engineering

Bali is a favorite vacation destination for many nationalities. Bali's<= br> natural attractions include miles of sandy beaches, picturesque rice
terraces, towering active volcanoes over 3,000 meters high, fast
flowing rivers, deep ravines, pristine crater lakes, sacred caves, and
lush tropical forests full of exotic wildlife. The island's rich
cultural heritage is visible everywhere - in over 20,000 temples and
palaces, in many colorful festivals and ceremonies, in drama, music,
and dance. Bali is also well-known for its night life. Come to Bali
enjoying the beautiful environment and fun here!

Paper Submission Deadline: 15 May 2011

Review Decision Notifications: 15 August 2011

Final Papers and Author Registration Deadline: 9 September 2011

To unsubscribe, reply with =93unsubscribe nabendu@ieee.org =94 in your
email subject or the first line of the email body.

With kind regards,

Jane Lew


--
Dr. Nabendu Chaki
HoD
Department of Computer Science & Engineering
&
Coordinator
A K Choudhury School of Information Technology
University of Calcutta, India
www.cucse.org/nc.= htm



--
--------------------
Mob +9194157= 58102
--00151747849e912abc049eed2231-- From jpmacker@gmail.com Mon Mar 21 08:10:17 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D536F28C15F for ; Mon, 21 Mar 2011 08:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=0.492, 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 2m9xplR++2lo for ; Mon, 21 Mar 2011 08:10:17 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E6B7A3A6877 for ; Mon, 21 Mar 2011 08:10:16 -0700 (PDT) Received: by wyb42 with SMTP id 42so6497690wyb.31 for ; Mon, 21 Mar 2011 08:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=FjSifSPzWlTWHdyy8jCLgLKXIl5g7I6b7Lc/+AGIpNA=; b=WH5On2ZPOsEewmnBxn0MzLqZ6t8vEQrhekVKpRXTs/vCIRCW6LjCx/LXnQLDYeFgWY AHxLTAx+ksiS/QTUKb9e0Ud/xLHTHdIB6KEjG4pnELRDjbhCdXUZK7QR4bSRgIFwRbIF i54Wh22/Ib/bZMU8DBk3tvq2A0m2OKT5aKsSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EW3Sv8q7LsmAQ0AytYLjZSdvM+O2GOmH2JBGiUYHIE795Rq3GD1+8G0XAvvktrKZTY HxRSaKjrcNyji9144l525d0hK8Umje+7A2mUnLh26vX266t6YaHTb6iz7sDH4sTvbuwN bjJ5vwvH8cBAKsarF17zu7XbA8DFVnch0Xsao= MIME-Version: 1.0 Received: by 10.216.168.67 with SMTP id j45mr5084257wel.101.1300720308743; Mon, 21 Mar 2011 08:11:48 -0700 (PDT) Received: by 10.216.163.210 with HTTP; Mon, 21 Mar 2011 08:11:48 -0700 (PDT) Date: Mon, 21 Mar 2011 11:11:48 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Reminder X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:10:17 -0000 Manet WG meeting is next Wed 0900 slot. Those who are presenting please provide me your materials when you can so I can upload to the materials website. -Joe From Internet-Drafts@ietf.org Tue Mar 29 13:15:02 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6A228B797; Tue, 29 Mar 2011 13:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 J3pTfsEZ3PV6; Tue, 29 Mar 2011 13:15:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B3E3A6A99; Tue, 29 Mar 2011 13:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110329201501.18048.86480.idtracker@localhost> Date: Tue, 29 Mar 2011 13:15:01 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-packetbb-sec-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 20:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : MANET Cryptographical Signature TLV Definition Author(s) : U. Herberg, T. Clausen Filename : draft-ietf-manet-packetbb-sec-03.txt Pages : 16 Date : 2011-03-29 This document describes general and flexible TLVs (type-length-value structure) for representing cryptographic signatures as well as timestamps, using the generalized MANET packet/message format [RFC5444]. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs, for affixing cryptographic signatures and timestamps to a packet, message and address, respectively. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-sec-03.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 Content-Type: Message/External-body; name="draft-ietf-manet-packetbb-sec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-29130607.I-D@ietf.org> --NextPart-- From teco@inf-net.nl Wed Mar 30 04:27:53 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F03528C13B; Wed, 30 Mar 2011 04:27:53 -0700 (PDT) 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 0IEi4HJtUuPZ; Wed, 30 Mar 2011 04:27:52 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5473928C0DB; Wed, 30 Mar 2011 04:27:52 -0700 (PDT) Received: by bwz13 with SMTP id 13so951499bwz.31 for ; Wed, 30 Mar 2011 04:29:30 -0700 (PDT) Received: by 10.204.172.129 with SMTP id l1mr910329bkz.99.1301484569232; Wed, 30 Mar 2011 04:29:29 -0700 (PDT) Received: from dhcp-14b8.meeting.ietf.org (dhcp-14b8.meeting.ietf.org [130.129.20.184]) by mx.google.com with ESMTPS id b6sm4028838bkb.22.2011.03.30.04.29.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 04:29:27 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Mar 2011 13:29:25 +0200 Message-Id: To: int-area@ietf.org, MANET IETF Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [manet] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:27:53 -0000 Sorry for x-posting. But there is a conflict in: http://tools.ietf.org/html/draft-ietf-manet-smf http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update SMF has a duplicate packet detection function based on the IPv4 ID field. So text in ietf-intarea-ipv4-id-update section 4 is not correct, in that there would be no deployments for such. That said, SMF deployment with IPv4 DPD on IP-ID would be limited. What to do? Teco From teco@inf-net.nl Wed Mar 30 05:00:25 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC9828C171; Wed, 30 Mar 2011 05:00:25 -0700 (PDT) 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 hjo-Z4yXT3Md; Wed, 30 Mar 2011 05:00:23 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 182F028C12F; Wed, 30 Mar 2011 05:00:19 -0700 (PDT) Received: by bwz13 with SMTP id 13so971845bwz.31 for ; Wed, 30 Mar 2011 05:01:58 -0700 (PDT) Received: by 10.204.57.135 with SMTP id c7mr926474bkh.88.1301486518220; Wed, 30 Mar 2011 05:01:58 -0700 (PDT) Received: from dhcp-14b8.meeting.ietf.org (dhcp-14b8.meeting.ietf.org [130.129.20.184]) by mx.google.com with ESMTPS id b6sm16727bkb.10.2011.03.30.05.01.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 05:01:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4D9317FB.6060109@isi.edu> Date: Wed, 30 Mar 2011 14:01:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9317FB.6060109@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Cc: MANET IETF , int-area@ietf.org Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:00:25 -0000 Hi Joe, The current text in intarea-ipv4-id-update is "no current deployments=20 are known". I read this as a statement in general. Then, it is not = correct. I am fine with discouragement of usage of systems that use IP_ID for = DPD, but such systems are around. Teco Op 30 mrt 2011, om 13:46 heeft Joe Touch het volgende geschreven: > Hi, Teco, >=20 > On 3/30/2011 4:29 AM, Teco Boot wrote: >> Sorry for x-posting. But there is a conflict in: >> http://tools.ietf.org/html/draft-ietf-manet-smf >> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update >>=20 >> SMF has a duplicate packet detection function based on the IPv4 >> ID field. So text in ietf-intarea-ipv4-id-update section 4 >> is not correct, in that there would be no deployments for such. >=20 > SMF is experimental. When we talk about deployments of duplicate = detection, we're focused on standards-based systems. >=20 > Note that ipv4-id-update is standards-track. >=20 >> That said, SMF deployment with IPv4 DPD on IP-ID would be limited. >>=20 >> What to do? >=20 > IMO, recommend H-DPD and change the discussion to explain why the ID = shouldn't be used for DPD (the text is basically already there - it = mentions the idea, but then explains that it's not likely to work = anyway). >=20 > Use of the IP ID for this purpose is problematic for a variety of = reasons, which is why ipv4-id-update deprecates use of that field for = that purpose. >=20 > Joe From charles.perkins@earthlink.net Wed Mar 30 05:19:50 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C38328C184; Wed, 30 Mar 2011 05:19:50 -0700 (PDT) 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 DYSbf2RdBMV7; Wed, 30 Mar 2011 05:19:49 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3FBAB28C15A; Wed, 30 Mar 2011 05:19:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gCJoDOmdDfRb6506J4gwb3D6cnbj78Xu/U3Hd/fXM2BeUrqAmsyFjtC2w1WKdYdi; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.70.103] by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Q4uOs-0002oS-4T; Wed, 30 Mar 2011 08:21:26 -0400 Message-ID: <4D932043.2040006@earthlink.net> Date: Wed, 30 Mar 2011 05:21:23 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: <4D9317FB.6060109@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86cdb8d8a971dc1542372634811264759c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.70.103 Cc: MANET IETF , int-area@ietf.org, Joe Touch Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:19:50 -0000 Hello Teco, Is it possible that the SMF usage is not vulnerable to the pitfalls noted in the intarea draft? Usually we don't picture NAT boxes in the MANET routing paths... Regards, Charlie P. On 3/30/2011 5:01 AM, Teco Boot wrote: > Hi Joe, > > The current text in intarea-ipv4-id-update is "no current deployments > are known". I read this as a statement in general. Then, it is not correct. > I am fine with discouragement of usage of systems that use IP_ID for DPD, > but such systems are around. > > Teco > > > Op 30 mrt 2011, om 13:46 heeft Joe Touch het volgende geschreven: > >> Hi, Teco, >> >> On 3/30/2011 4:29 AM, Teco Boot wrote: >>> Sorry for x-posting. But there is a conflict in: >>> http://tools.ietf.org/html/draft-ietf-manet-smf >>> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update >>> >>> SMF has a duplicate packet detection function based on the IPv4 >>> ID field. So text in ietf-intarea-ipv4-id-update section 4 >>> is not correct, in that there would be no deployments for such. >> >> SMF is experimental. When we talk about deployments of duplicate detection, we're focused on standards-based systems. >> >> Note that ipv4-id-update is standards-track. >> >>> That said, SMF deployment with IPv4 DPD on IP-ID would be limited. >>> >>> What to do? >> >> IMO, recommend H-DPD and change the discussion to explain why the ID shouldn't be used for DPD (the text is basically already there - it mentions the idea, but then explains that it's not likely to work anyway). >> >> Use of the IP ID for this purpose is problematic for a variety of reasons, which is why ipv4-id-update deprecates use of that field for that purpose. >> >> Joe > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From teco@inf-net.nl Wed Mar 30 05:26:18 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0EE228C121; Wed, 30 Mar 2011 05:26:17 -0700 (PDT) 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 9XGr-+zfFg6y; Wed, 30 Mar 2011 05:26:13 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2FFDA28C182; Wed, 30 Mar 2011 05:26:11 -0700 (PDT) Received: by bwz13 with SMTP id 13so989550bwz.31 for ; Wed, 30 Mar 2011 05:27:49 -0700 (PDT) Received: by 10.204.126.131 with SMTP id c3mr1027413bks.104.1301488069388; Wed, 30 Mar 2011 05:27:49 -0700 (PDT) Received: from dhcp-14b8.meeting.ietf.org (dhcp-14b8.meeting.ietf.org [130.129.20.184]) by mx.google.com with ESMTPS id l1sm32377bkl.13.2011.03.30.05.27.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 05:27:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4D931F02.7040303@isi.edu> Date: Wed, 30 Mar 2011 14:27:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <195C022D-54CD-4A68-ACEC-5E46F2B8489C@inf-net.nl> References: <4D9317FB.6060109@isi.edu> <4D931CD7.7060402@isi.edu> <4D931F02.7040303@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Cc: MANET IETF , int-area@ietf.org Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:26:18 -0000 OK, it is good to hear that we can continue to do experiments and learn=20= from that.=20 I am aware of (non-SMF) data transport over small bandwidth satcom links, using IP-ID DPD. It is experimental / prototype.=20 For SMF, I let authors respond. =20 I think it is acceptable to update such experiments to H-DPD. Teco Op 30 mrt 2011, om 14:16 heeft Joe Touch het volgende geschreven: > Clarification... >=20 > On 3/30/2011 5:06 AM, Joe Touch wrote: >>=20 >>=20 >> On 3/30/2011 5:01 AM, Teco Boot wrote: >>> Hi Joe, >>>=20 >>> The current text in intarea-ipv4-id-update is "no current = deployments >>> are known". I read this as a statement in general. Then, it is not >>> correct. >>=20 >> Experiments are not supposed to be deployed in the public Internet. = So > ^ widely ^ > without monitoring >> unless the doc markings are incorrect, SMF should really not be >> deployed. ;-) >=20 > Back to your original point, yes, we should note that this is = happening. How widely deployed is this, and what would the impact be of = updating the 'experiment' to use H-DPD for IPv4? >=20 > Joe From jdean@itd.nrl.navy.mil Wed Mar 30 05:26:23 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58EB428C17C; Wed, 30 Mar 2011 05:26:23 -0700 (PDT) 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 l8MNn4NWwnn4; Wed, 30 Mar 2011 05:26:15 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 151E928C164; Wed, 30 Mar 2011 05:26:14 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p2UCRkkV028192; Wed, 30 Mar 2011 08:27:53 -0400 Received: (from bebe [132.250.93.61]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011033008275315785 ; Wed, 30 Mar 2011 08:27:53 -0400 From: "Justin Dean" To: "'Teco Boot'" , , "'MANET IETF'" References: In-Reply-To: Date: Wed, 30 Mar 2011 08:23:11 -0400 Message-ID: <00a901cbeed5$3c738700$b55a9500$@nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvuzcwXVMMEXO09RWKnYlwHfKD3rQABO+hg Content-Language: en-us Subject: Re: [manet] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:26:24 -0000 "Deprecating the use of the IPv4 ID field for non-reassembly uses should have little - if any - impact." That statement wasn't true for very long was it... Well section 9 may provide a way out. "Network address translators (NATs) and address/port translators (NAPTs) rewrite IP fields, and tunnel ingresses (using IPv4 encapsulation) copy and modify some IPv4 fields, so all are considered sources, as do any devices that rewrite any portion of the source address, destination address, protocol, and ID tuple for non- atomic datagrams [RFC3022]. As a result, they are subject to all the requirements of any source, as has been noted." With the current draft incoming packets can have their id fields modified by the SMF gateway before being forwarded in the MANET. I would say this makes the gateway a source. Then we just need to fragment everything! I can see the reason for banning the behavior in high bandwidth wired links where duplicates only occur with routing loops and the id wraps so fast it is useless. But the way this is written it bans ALL use of the IPv4 ID field for duplicate detection. "The IPv4 ID field is no longer permitted for duplicate detection." Does this mean we can't even hash this field for duplicate detection?! > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Teco Boot > Sent: Wednesday, March 30, 2011 7:29 AM > To: int-area@ietf.org; MANET IETF > Subject: [manet] SMF and intarea-ipv4-id-update > > Sorry for x-posting. But there is a conflict in: > http://tools.ietf.org/html/draft-ietf-manet-smf > http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update > > SMF has a duplicate packet detection function based on the IPv4 > ID field. So text in ietf-intarea-ipv4-id-update section 4 > is not correct, in that there would be no deployments for such. > That said, SMF deployment with IPv4 DPD on IP-ID would be limited. > > What to do? > > Teco > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Wed Mar 30 05:33:10 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A769C3A6A1C; Wed, 30 Mar 2011 05:33:10 -0700 (PDT) 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 DYbU0Uk1cy96; Wed, 30 Mar 2011 05:33:07 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id BE9B33A67D4; Wed, 30 Mar 2011 05:33:05 -0700 (PDT) Received: by bwz13 with SMTP id 13so994530bwz.31 for ; Wed, 30 Mar 2011 05:34:44 -0700 (PDT) Received: by 10.204.154.88 with SMTP id n24mr1078506bkw.38.1301488483926; Wed, 30 Mar 2011 05:34:43 -0700 (PDT) Received: from dhcp-14b8.meeting.ietf.org (dhcp-14b8.meeting.ietf.org [130.129.20.184]) by mx.google.com with ESMTPS id z18sm38393bkf.8.2011.03.30.05.34.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 05:34:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4D932043.2040006@earthlink.net> Date: Wed, 30 Mar 2011 14:34:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9317FB.6060109@isi.edu> <4D932043.2040006@earthlink.net> To: Charles E. Perkins X-Mailer: Apple Mail (2.1082) Cc: MANET IETF , int-area@ietf.org, Joe Touch Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:33:11 -0000 There are other ideas around, that could be applicable in MANETs. You could check draft-briscoe-intarea-ipv4-id-reuse Teco Op 30 mrt 2011, om 14:21 heeft Charles E. Perkins het volgende = geschreven: >=20 > Hello Teco, >=20 > Is it possible that the SMF usage is not vulnerable to > the pitfalls noted in the intarea draft? Usually we > don't picture NAT boxes in the MANET routing paths... >=20 > Regards, > Charlie P. >=20 >=20 > On 3/30/2011 5:01 AM, Teco Boot wrote: >> Hi Joe, >>=20 >> The current text in intarea-ipv4-id-update is "no current deployments >> are known". I read this as a statement in general. Then, it is not = correct. >> I am fine with discouragement of usage of systems that use IP_ID for = DPD, >> but such systems are around. >>=20 >> Teco >>=20 >>=20 >> Op 30 mrt 2011, om 13:46 heeft Joe Touch het volgende geschreven: >>=20 >>> Hi, Teco, >>>=20 >>> On 3/30/2011 4:29 AM, Teco Boot wrote: >>>> Sorry for x-posting. But there is a conflict in: >>>> http://tools.ietf.org/html/draft-ietf-manet-smf >>>> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update >>>>=20 >>>> SMF has a duplicate packet detection function based on the IPv4 >>>> ID field. So text in ietf-intarea-ipv4-id-update section 4 >>>> is not correct, in that there would be no deployments for such. >>>=20 >>> SMF is experimental. When we talk about deployments of duplicate = detection, we're focused on standards-based systems. >>>=20 >>> Note that ipv4-id-update is standards-track. >>>=20 >>>> That said, SMF deployment with IPv4 DPD on IP-ID would be limited. >>>>=20 >>>> What to do? >>>=20 >>> IMO, recommend H-DPD and change the discussion to explain why the ID = shouldn't be used for DPD (the text is basically already there - it = mentions the idea, but then explains that it's not likely to work = anyway). >>>=20 >>> Use of the IP ID for this purpose is problematic for a variety of = reasons, which is why ipv4-id-update deprecates use of that field for = that purpose. >>>=20 >>> Joe >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From scott.brim@gmail.com Wed Mar 30 05:39:41 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246CC3A67CC; Wed, 30 Mar 2011 05:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 pElNcuCvVf22; Wed, 30 Mar 2011 05:39:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 596C63A67D4; Wed, 30 Mar 2011 05:39:40 -0700 (PDT) Received: by iye19 with SMTP id 19so1408695iye.31 for ; Wed, 30 Mar 2011 05:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=F50taX5qJCLXorhPwFX36dXN0S+Q/md10QrI1tSfKJI=; b=gBQ1oVNWTzOAPQYruNm0ekTUtijcDHkH9zreQf0EoRWp/xMiS5G3PcYztmECo8ds+t 69wRk2iIqIiB20ChQcQBIsdQs/dRPvPN9C0+Grf7EJ+RihbnJBbF36HHXgFnCVqhT14q ZzoYc0oMAO/a1Qo4Ytte3HmM+DAy8vpXHTdws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=AMjr+vEMgqWpfGXofo3o4WUh4I8G5UM3xpgg4YJ4wusnRZoXgzwNO5dTMShJNcagrj xqrhjbhVoGgXKmLjQSaUF16NSY2yCx8p04uKob1OWrwerZo/VaXZlw8gBmU7Esg2hpzl 6c6Qy7rU5wvtucy1aU6NY0QhMnZmJv7KduwN4= Received: by 10.42.133.72 with SMTP id g8mr1223494ict.80.1301488879121; Wed, 30 Mar 2011 05:41:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.225.133 with HTTP; Wed, 30 Mar 2011 05:40:59 -0700 (PDT) In-Reply-To: References: <4D9317FB.6060109@isi.edu> <4D932043.2040006@earthlink.net> From: Scott Brim Date: Wed, 30 Mar 2011 14:40:59 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: MANET IETF , int-area@ietf.org Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:39:41 -0000 On Wed, Mar 30, 2011 at 14:34, Teco Boot wrote: > There are other ideas around, that could be applicable in MANETs. > You could check draft-briscoe-intarea-ipv4-id-reuse Bob's draft assumes Joe's draft. It may collide with other undocumented uses of the "reserved" flag. I never make assumptions about what middleboxes might do when nobody is looking. From joseph.macker@nrl.navy.mil Wed Mar 30 07:08:35 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25CA3A6B5D; Wed, 30 Mar 2011 07:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.937 X-Spam-Level: X-Spam-Status: No, score=-5.937 tagged_above=-999 required=5 tests=[AWL=0.663, 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 28wXCqVro78t; Wed, 30 Mar 2011 07:08:34 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 0D1103A6A1D; Wed, 30 Mar 2011 07:08:33 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p2UE8uju003355; Wed, 30 Mar 2011 10:10:10 -0400 Received: from vpn217206.nrl.navy.mil ([132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011033010100816798 ; Wed, 30 Mar 2011 10:10:09 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Macker In-Reply-To: Date: Wed, 30 Mar 2011 16:10:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B71EC55-1D87-43CA-8C7A-B6552C23D600@nrl.navy.mil> References: To: Teco Boot X-Mailer: Apple Mail (2.1084) Cc: MANET IETF , int-area@ietf.org Subject: Re: [manet] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 14:08:35 -0000 Yes this is an optional duplicate detection scheme and is an example of = use in practice. Also As Teco mentioned this intended for limited use in edge network = multicast systems. On Mar 30, 2011, at 1:29 PM, Teco Boot wrote: > Sorry for x-posting. But there is a conflict in: > http://tools.ietf.org/html/draft-ietf-manet-smf > http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update >=20 > SMF has a duplicate packet detection function based on the IPv4=20 > ID field. So text in ietf-intarea-ipv4-id-update section 4 > is not correct, in that there would be no deployments for such. > That said, SMF deployment with IPv4 DPD on IP-ID would be limited. >=20 > What to do? >=20 > Teco >=20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From touch@isi.edu Wed Mar 30 04:45:07 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326A23A6947; Wed, 30 Mar 2011 04:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 7wFjQwOtQKaO; Wed, 30 Mar 2011 04:45:06 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 6DAC03A6767; Wed, 30 Mar 2011 04:45:06 -0700 (PDT) Received: from [130.129.21.87] (dhcp-1557.meeting.ietf.org [130.129.21.87]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p2UBk4tZ021068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 30 Mar 2011 04:46:18 -0700 (PDT) Message-ID: <4D9317FB.6060109@isi.edu> Date: Wed, 30 Mar 2011 04:46:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 30 Mar 2011 14:11:44 -0700 Cc: MANET IETF , int-area@ietf.org Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:45:07 -0000 Hi, Teco, On 3/30/2011 4:29 AM, Teco Boot wrote: > Sorry for x-posting. But there is a conflict in: > http://tools.ietf.org/html/draft-ietf-manet-smf > http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update > > SMF has a duplicate packet detection function based on the IPv4 > ID field. So text in ietf-intarea-ipv4-id-update section 4 > is not correct, in that there would be no deployments for such. SMF is experimental. When we talk about deployments of duplicate detection, we're focused on standards-based systems. Note that ipv4-id-update is standards-track. > That said, SMF deployment with IPv4 DPD on IP-ID would be limited. > > What to do? IMO, recommend H-DPD and change the discussion to explain why the ID shouldn't be used for DPD (the text is basically already there - it mentions the idea, but then explains that it's not likely to work anyway). Use of the IP ID for this purpose is problematic for a variety of reasons, which is why ipv4-id-update deprecates use of that field for that purpose. Joe From touch@isi.edu Wed Mar 30 05:06:22 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81F23A6B50; Wed, 30 Mar 2011 05:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.137 X-Spam-Level: X-Spam-Status: No, score=-104.137 tagged_above=-999 required=5 tests=[AWL=-1.538, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Qrguk+4UNVRm; Wed, 30 Mar 2011 05:06:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 02BBD3A6B32; Wed, 30 Mar 2011 05:06:21 -0700 (PDT) Received: from [130.129.21.87] (dhcp-1557.meeting.ietf.org [130.129.21.87]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p2UC6mtH013410 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 30 Mar 2011 05:07:01 -0700 (PDT) Message-ID: <4D931CD7.7060402@isi.edu> Date: Wed, 30 Mar 2011 05:06:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: <4D9317FB.6060109@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 30 Mar 2011 14:11:45 -0700 Cc: MANET IETF , int-area@ietf.org Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:06:22 -0000 On 3/30/2011 5:01 AM, Teco Boot wrote: > Hi Joe, > > The current text in intarea-ipv4-id-update is "no current deployments > are known". I read this as a statement in general. Then, it is not correct. Experiments are not supposed to be deployed in the public Internet. So unless the doc markings are incorrect, SMF should really not be deployed. ;-) Joe > I am fine with discouragement of usage of systems that use IP_ID for DPD, > but such systems are around. > > Teco > > > Op 30 mrt 2011, om 13:46 heeft Joe Touch het volgende geschreven: > >> Hi, Teco, >> >> On 3/30/2011 4:29 AM, Teco Boot wrote: >>> Sorry for x-posting. But there is a conflict in: >>> http://tools.ietf.org/html/draft-ietf-manet-smf >>> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update >>> >>> SMF has a duplicate packet detection function based on the IPv4 >>> ID field. So text in ietf-intarea-ipv4-id-update section 4 >>> is not correct, in that there would be no deployments for such. >> >> SMF is experimental. When we talk about deployments of duplicate detection, we're focused on standards-based systems. >> >> Note that ipv4-id-update is standards-track. >> >>> That said, SMF deployment with IPv4 DPD on IP-ID would be limited. >>> >>> What to do? >> >> IMO, recommend H-DPD and change the discussion to explain why the ID shouldn't be used for DPD (the text is basically already there - it mentions the idea, but then explains that it's not likely to work anyway). >> >> Use of the IP ID for this purpose is problematic for a variety of reasons, which is why ipv4-id-update deprecates use of that field for that purpose. >> >> Joe > From touch@isi.edu Wed Mar 30 05:15:08 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0CB28C154; Wed, 30 Mar 2011 05:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.028 X-Spam-Level: X-Spam-Status: No, score=-104.028 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 RP0E5Z2NGbIo; Wed, 30 Mar 2011 05:15:07 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 778E828C144; Wed, 30 Mar 2011 05:15:07 -0700 (PDT) Received: from [130.129.21.87] (dhcp-1557.meeting.ietf.org [130.129.21.87]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p2UCG2YU014944 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 30 Mar 2011 05:16:16 -0700 (PDT) Message-ID: <4D931F02.7040303@isi.edu> Date: Wed, 30 Mar 2011 05:16:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: <4D9317FB.6060109@isi.edu> <4D931CD7.7060402@isi.edu> In-Reply-To: <4D931CD7.7060402@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 30 Mar 2011 14:11:45 -0700 Cc: MANET IETF , int-area@ietf.org Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:15:08 -0000 Clarification... On 3/30/2011 5:06 AM, Joe Touch wrote: > > > On 3/30/2011 5:01 AM, Teco Boot wrote: >> Hi Joe, >> >> The current text in intarea-ipv4-id-update is "no current deployments >> are known". I read this as a statement in general. Then, it is not >> correct. > > Experiments are not supposed to be deployed in the public Internet. So ^ widely ^ without monitoring > unless the doc markings are incorrect, SMF should really not be > deployed. ;-) Back to your original point, yes, we should note that this is happening. How widely deployed is this, and what would the impact be of updating the 'experiment' to use H-DPD for IPv4? Joe From touch@isi.edu Wed Mar 30 05:26:36 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFED428C18F; Wed, 30 Mar 2011 05:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 p3YL5U87Inub; Wed, 30 Mar 2011 05:26:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4F7B028C160; Wed, 30 Mar 2011 05:26:30 -0700 (PDT) Received: from [130.129.21.87] (dhcp-1557.meeting.ietf.org [130.129.21.87]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p2UCRUKP017004 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 30 Mar 2011 05:27:45 -0700 (PDT) Message-ID: <4D9321B1.9080602@isi.edu> Date: Wed, 30 Mar 2011 05:27:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Charles E. Perkins" References: <4D9317FB.6060109@isi.edu> <4D932043.2040006@earthlink.net> In-Reply-To: <4D932043.2040006@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 30 Mar 2011 14:11:45 -0700 Cc: MANET IETF , int-area@ietf.org Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:26:36 -0000 The pitfalls include: - false positives (dropping unique packets) due to ID wrap before 2MSL - false positives due to ID being deliberately repeated (e.g., from cellphones using ID=0 all the time) - false positives due to colliding use by different sources behind a NAT that fails to rewrite the ID Note that only the last example is NAT related. The others are not. Joe On 3/30/2011 5:21 AM, Charles E. Perkins wrote: > > Hello Teco, > > Is it possible that the SMF usage is not vulnerable to > the pitfalls noted in the intarea draft? Usually we > don't picture NAT boxes in the MANET routing paths... > > Regards, > Charlie P. > > > On 3/30/2011 5:01 AM, Teco Boot wrote: >> Hi Joe, >> >> The current text in intarea-ipv4-id-update is "no current deployments >> are known". I read this as a statement in general. Then, it is not >> correct. >> I am fine with discouragement of usage of systems that use IP_ID for DPD, >> but such systems are around. >> >> Teco >> >> >> Op 30 mrt 2011, om 13:46 heeft Joe Touch het volgende geschreven: >> >>> Hi, Teco, >>> >>> On 3/30/2011 4:29 AM, Teco Boot wrote: >>>> Sorry for x-posting. But there is a conflict in: >>>> http://tools.ietf.org/html/draft-ietf-manet-smf >>>> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update >>>> >>>> SMF has a duplicate packet detection function based on the IPv4 >>>> ID field. So text in ietf-intarea-ipv4-id-update section 4 >>>> is not correct, in that there would be no deployments for such. >>> >>> SMF is experimental. When we talk about deployments of duplicate >>> detection, we're focused on standards-based systems. >>> >>> Note that ipv4-id-update is standards-track. >>> >>>> That said, SMF deployment with IPv4 DPD on IP-ID would be limited. >>>> >>>> What to do? >>> >>> IMO, recommend H-DPD and change the discussion to explain why the ID >>> shouldn't be used for DPD (the text is basically already there - it >>> mentions the idea, but then explains that it's not likely to work >>> anyway). >>> >>> Use of the IP ID for this purpose is problematic for a variety of >>> reasons, which is why ipv4-id-update deprecates use of that field for >>> that purpose. >>> >>> Joe >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> From touch@isi.edu Wed Mar 30 05:49:37 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F07053A6A1C; Wed, 30 Mar 2011 05:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.775 X-Spam-Level: X-Spam-Status: No, score=-103.775 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 z3QxTJYqorW2; Wed, 30 Mar 2011 05:49:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D4F9D3A67FC; Wed, 30 Mar 2011 05:49:35 -0700 (PDT) Received: from [130.129.21.87] (dhcp-1557.meeting.ietf.org [130.129.21.87]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p2UCof2B021128 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 30 Mar 2011 05:50:56 -0700 (PDT) Message-ID: <4D932721.9070804@isi.edu> Date: Wed, 30 Mar 2011 05:50:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Teco Boot References: <4D9317FB.6060109@isi.edu> <4D932043.2040006@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 30 Mar 2011 14:11:45 -0700 Cc: MANET IETF , int-area@ietf.org Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:49:37 -0000 FWIW, Briscoe's doc won't help here. It is intended to find other ways to use the ID field for atomic packets (as defined in ipv4-id-update), but those bits would be as flags, not as a whole space that could be used for a given purpose. Joe On 3/30/2011 5:34 AM, Teco Boot wrote: > There are other ideas around, that could be applicable in MANETs. > You could check draft-briscoe-intarea-ipv4-id-reuse > > Teco > > Op 30 mrt 2011, om 14:21 heeft Charles E. Perkins het volgende geschreven: > >> >> Hello Teco, >> >> Is it possible that the SMF usage is not vulnerable to >> the pitfalls noted in the intarea draft? Usually we >> don't picture NAT boxes in the MANET routing paths... >> >> Regards, >> Charlie P. >> >> >> On 3/30/2011 5:01 AM, Teco Boot wrote: >>> Hi Joe, >>> >>> The current text in intarea-ipv4-id-update is "no current deployments >>> are known". I read this as a statement in general. Then, it is not correct. >>> I am fine with discouragement of usage of systems that use IP_ID for DPD, >>> but such systems are around. >>> >>> Teco >>> >>> >>> Op 30 mrt 2011, om 13:46 heeft Joe Touch het volgende geschreven: >>> >>>> Hi, Teco, >>>> >>>> On 3/30/2011 4:29 AM, Teco Boot wrote: >>>>> Sorry for x-posting. But there is a conflict in: >>>>> http://tools.ietf.org/html/draft-ietf-manet-smf >>>>> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update >>>>> >>>>> SMF has a duplicate packet detection function based on the IPv4 >>>>> ID field. So text in ietf-intarea-ipv4-id-update section 4 >>>>> is not correct, in that there would be no deployments for such. >>>> >>>> SMF is experimental. When we talk about deployments of duplicate detection, we're focused on standards-based systems. >>>> >>>> Note that ipv4-id-update is standards-track. >>>> >>>>> That said, SMF deployment with IPv4 DPD on IP-ID would be limited. >>>>> >>>>> What to do? >>>> >>>> IMO, recommend H-DPD and change the discussion to explain why the ID shouldn't be used for DPD (the text is basically already there - it mentions the idea, but then explains that it's not likely to work anyway). >>>> >>>> Use of the IP ID for this purpose is problematic for a variety of reasons, which is why ipv4-id-update deprecates use of that field for that purpose. >>>> >>>> Joe >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> > From ulrich@herberg.name Wed Mar 30 08:11:57 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5457C3A6B6B for ; Wed, 30 Mar 2011 08:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_25=0.6, J_CHICKENPOX_63=0.6, MANGLED_SHOP=2.3, 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 y+gNIq2ZInF7 for ; Wed, 30 Mar 2011 08:11:49 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D5D4A3A6B6F for ; Wed, 30 Mar 2011 08:11:42 -0700 (PDT) Received: by vws12 with SMTP id 12so1258592vws.31 for ; Wed, 30 Mar 2011 08:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=tDfs8Tw1kbRwuKSdVXejUocRamEpXFRv5oN1gzIGU4I=; b=kqIhVD6/mCcWbYgRdOHJFARS9h8RyrAGlv/5sFo5IRQ6JdXrOSmC4ZwzAVxLN6p/NI sBejb+/gJ3W3pkpp493rSTV4Mx1vfBAYzbAEjwR/r+2PyLPE/G02t0KjIuOJGgxK/FIx RdD6e4hRyz+PWo3xPzEmJuK2e+85rpLpV9ZAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=BaHh/0CtbpFopKFmKuiFqLz3dAdYf6eNoKT9oh+9ew3N/A99cOvkHf22dZ1w7rl1EX d6SSUUXLhXvVe6Vbj9Ne4q4pdzHKAMu5dG6QtAzzaW9CtzsOkhoHLCrt9dUIzQexRRWE ivMpFCljR1QlZJ6lcvTGX+gPAEytVKyDNjeYg= MIME-Version: 1.0 Received: by 10.220.46.234 with SMTP id k42mr357076vcf.133.1301497999079; Wed, 30 Mar 2011 08:13:19 -0700 (PDT) Received: by 10.220.29.201 with HTTP; Wed, 30 Mar 2011 08:13:19 -0700 (PDT) Date: Wed, 30 Mar 2011 17:13:19 +0200 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 30 Mar 2011 14:11:43 -0700 Subject: [manet] SMF-11 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:11:57 -0000 Hi, as promised, my review of the last revision of SMF. As said in the meeting, the draft has improved a lot in terms of readability and consistency since -10. My remaining issues are a number of smaller fixes, nothing that really changes the spec. As in my previous review, my comments are enclosed by "UH> =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D". Network Working Group J. Macker, editor Internet-Draft NRL Intended status: Experimental SMF Design Team Expires: September 15, 2011 IETF MANET WG March 14, 2011 Simplified Multicast Forwarding draft-ietf-manet-smf-11 Abstract This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF defines techniques for multicast duplicate packet detection (DPD) to be applied in the forwarding process and includes maintenance and checking operations for both IPv4 and IPv6 protocol use. SMF also specifies mechanisms for applying reduced relay sets to achieve more efficient multicast data distribution within a mesh topology versus simple flooding. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> simple or classic flooding? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 15, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 1] =0C Internet-Draft SMF March 2011 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 Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 2] =0C Internet-Draft SMF March 2011 Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 4. SMF Applicability . . . . . . . . . . . . . . . . . . . . . . 8 5. SMF Packet Processing and Forwarding . . . . . . . . . . . . . 9 6. SMF Duplicate Packet Detection . . . . . . . . . . . . . . . . 11 6.1. IPv6 Duplicate Packet Detection . . . . . . . . . . . . . 12 6.1.1. IPv6 SMF-DPD Header Option . . . . . . . . . . . . . . 12 6.1.2. IPv6 Identification-based DPD . . . . . . . . . . . . 15 6.1.3. IPv6 Hash-based DPD . . . . . . . . . . . . . . . . . 17 6.2. IPv4 Duplicate Packet Detection . . . . . . . . . . . . . 18 6.2.1. IPv4 Identification-based DPD . . . . . . . . . . . . 18 6.2.2. IPv4 Hash-based DPD . . . . . . . . . . . . . . . . . 20 7. Relay Set Selection . . . . . . . . . . . . . . . . . . . . . 20 7.1. Non-Reduced Relay Set Forwarding . . . . . . . . . . . . . 20 7.2. Reduced Relay Set Forwarding . . . . . . . . . . . . . . . 21 8. SMF Neighborhood Discovery Requirements . . . . . . . . . . . 23 8.1. SMF Relay Algorithm TLV Types . . . . . . . . . . . . . . 24 8.1.1. SMF Message TLV Type . . . . . . . . . . . . . . . . . 24 8.1.2. SMF Address Block TLV Type . . . . . . . . . . . . . . 25 9. SMF Border Gateway Considerations . . . . . . . . . . . . . . 26 9.1. Forwarded Multicast Groups . . . . . . . . . . . . . . . . 27 9.2. Multicast Group Scoping . . . . . . . . . . . . . . . . . 28 9.3. Interface with Exterior Multicast Routing Protocols . . . 28 9.4. Multiple Border Routers . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 11.1. IPv6 SMF-DPD Header Extension . . . . . . . . . . . . . . 32 11.2. SMF Type-Length-Value . . . . . . . . . . . . . . . . . . 33 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . . 35 Appendix A. Essential Connecting Dominating Set (E-CDS) Algorithm . . . . . . . . . . . . . . . . . . . . . . 36 A.1. E-CDS Relay Set Selection Overview . . . . . . . . . . . . 37 A.2. E-CDS Forwarding Rules . . . . . . . . . . . . . . . . . . 38 A.3. E-CDS Neighborhood Discovery Requirements . . . . . . . . 38 A.4. E-CDS Selection Algorithm . . . . . . . . . . . . . . . . 41 Appendix B. Source-based Multipoint Relay (S-MPR) . . . . . . . . 43 B.1. S-MPR Relay Set Selection Overview . . . . . . . . . . . . 43 B.2. S-MPR Forwarding Rules . . . . . . . . . . . . . . . . . . 44 B.3. S-MPR Neighborhood Discovery Requirements . . . . . . . . 45 B.4. S-MPR Selection Algorithm . . . . . . . . . . . . . . . . 47 Appendix C. Multipoint Relay Connected Dominating Set Macker, editor & SMF Design Team Expires September 15, 2011 [Page 3] =0C Internet-Draft SMF March 2011 (MPR-CDS) Algorithm . . . . . . . . . . . . . . . . . 48 C.1. MPR-CDS Relay Set Selection Overview . . . . . . . . . . . 48 C.2. MPR-CDS Forwarding Rules . . . . . . . . . . . . . . . . . 49 C.3. MPR-CDS Neighborhood Discovery Requirements . . . . . . . 50 C.4. MPR-CDS Selection Algorithm . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Macker, editor & SMF Design Team Expires September 15, 2011 [Page 4] =0C Internet-Draft SMF March 2011 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction and Scope Unicast routing protocol designs for MANET and wireless mesh use UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> is it designs or designed? not sure... UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D often apply distributed algorithms to flood routing control plane messages within an interior wireless routing domain. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "interior"? Is that different than just "routing domain", as used later= ? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For example, algorithms specified within [RFC3626] and [RFC3684] provide distributed methods of dynamically electing reduced relay sets that attempt to efficiently flood routing control messages while maintaining a connected set under dynamic topological conditions. In one sense, Simplified Multicast Forwarding (SMF) extends the efficient flooding concept to the data forwarding plane. Therefore, SMF provides an appropriate multicast forwarding capability for use cases where localized, efficient flooding is considered an effective design approach. The baseline design is intended to provide a basic, best effort multicast forwarding capability that is constrained to operate within an interior MANET or wireless mesh routing domain. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> same comment as before, "interior [...] routing domain"?. The difference between "MANET [...] routing domain" and "wireless mesh routing domain" is not clear to me. Maybe just say "MANET routing domain"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An SMF routing domain is an instance of a SMF UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/a SMF/an SMF/ ? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D routing protocol with common policies that is under a single network administration authority. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I wonder whether that is always applicable. For example, I am not quite sure that the FunkFeuer network is under a "single network administration authority". Everybody is free to join, simply by running the protocol. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The main design goals of this SMF specification are to adapt efficient relay sets in MANET type environments [RFC2501] and to define the needed IPv4 and IPv6 multicast duplicate packet detection (DPD) mechanisms to support multi-hop, packet forwarding. 2.1. Terminology UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I suggest to change the title to "Terminology and Notations" and add some text explaining the kind of notations (e.g. ) for fields and variables, similar to RFC 5444 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following abbreviations are used throughout this document: Macker, editor & SMF Design Team Expires September 15, 2011 [Page 5] =0C Internet-Draft SMF March 2011 +--------------+---------------------------------+ | Abbreviation | Definition | +--------------+---------------------------------+ | MANET | Mobile Ad hoc Network | | SMF | Simplified Multicast Forwarding | | CF | Classical Flooding | | CDS | Connected Dominating Set | | MPR | Multi-Point Relay | | S-MPR | Source-based MPR | | MPR-CDS | MPR-based CDS | | E-CDS | Essential CDS | | NHDP | Neighborhood Discovery Protocol | | SMF-DPD | SMF-Duplicate Packet Detection | | I-DPD | Identification-based DPD | | H-DPD | Hash-based DPD | | HAV | Hash-assist Value | | FIB | Forwarding Information Base | | TLV | type-length-value encoding | | DoS | Denial of Service | +--------------+---------------------------------+ 3. Design Overview Figure 1 provides an overview of the logical SMF node UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> At many places in the draft, the word "node" is still used, instead of "router", as in other cases. I suggest to replace "node" with "router" throughout the doc. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D architecture, consisting of "Neighborhood Discovery", "Relay Set Selection" and "Forwarding Process" components. Typically, relay set selection (or self-election) occurs based on dynamic input from a neighborhood discovery process. SMF supports the case where neighborhood discovery and/or relay set selection information is obtained from a coexistent process (e.g., a lower layer mechanism or a unicast routing protocol using relay sets). In some algorithm designs, the forwarding decision for a packet can also depend on previous hop or incoming interface information. The asterisks (*) in Figure 1 mark the primitives and relationships needed by relay set algorithms requiring previous-hop packet forwarding knowledge. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 6] =0C Internet-Draft SMF March 2011 ______________ _____________ | | | | | Neighborhood | | Relay Set | | Discovery |------------->| Selection | | Protocol | neighbor | Algorithm | |______________| info |_____________| \ / \ / neighbor\ /forwarding info* \ ____________ / status \ | | / `-->| Forwarding |<--' | Process | ~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~> incoming packet, forwarded packets interface id*, and previous hop* Figure 1: SMF Node Architecture There are certain IP multicast packets, defined later in this specification UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> better: "defined in section XX of this specification" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D , that are "non-forwardable" and these multicast packets will be ignored by the SMF forwarding engine. The SMF forwarding engine MAY also work with policies and management interfaces to allow additional filtering control over which multicast packets are considered for potential SMF forwarding. This interface would allow more refined dynamic forwarding control once such techniques are matured for MANET operation. At present further discussion of dynamic control is left to future work. Interoperable SMF implementations MUST use a common DPD approach and be able to process the header options defined in this document for IPv6 operation. We define Classical Flooding (CF), UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I prefer to use passive instead of "we...", i.e. "CF is defined as ... = " UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D as the simplest case of SMF multicast forwarding. With CF, each SMF router forwards each received multicast packet exactly once. In this case, the need for any relay set selection or neighborhood topology information is eliminated at the expense of additional network overhead. In CF mode, the SMF-DPD functionality is still required. While SMF supports a CF mode of operation UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> add comma UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D the use of more efficient relay set modes is RECOMMENDED to reduce contention and congestion caused by unnecessary packet retransmissions [NTSC99]. An efficient, reduced relay set is realized by selecting and maintaining a subset of all possible routers in a MANET routing domain. Known distributed relay set selection algorithms have demonstrated the ability to provide and maintain a dynamic connected set for forwarding multicast IP packets [MDC04]. A few such relay set selection algorithms are described in the Appendices of this Macker, editor & SMF Design Team Expires September 15, 2011 [Page 7] =0C Internet-Draft SMF March 2011 document and the basic designs borrow directly from previously documented IETF work. SMF relay set configuration is extensible and additional relay set algorithms beyond those specified here can be accommodated in future work. Determining and maintaining an optimized set of forwarding nodes generally requires dynamic neighborhood topology information. Neighborhood topology discovery functions MAY be externally provided by a MANET unicast routing protocol or by using the MANET NeighborHood Discovery Protocol (NHDP) [RFC6130] running in concurrence with SMF. Additionally, this specification allows alternative lower layer interfaces (radio router interface) to provide the necessary neighborhood information to aid in supporting more effective relay set election. Fundamentally, an SMF implementation SHOULD provide the ability for multicast forwarding state to be dynamically managed per operating network interface. Some of the relay state maintenance options and interactions are outlined later UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> remove the word "later" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D in Section 7. This document states specific requirements for neighborhood discovery with respect to the forwarding process and the relay set selection algorithms described herein. For determining dynamic relay sets in the absence of other control interfaces, SMF relies on the MANET NHDP specification to assist in IP layer 2-hop neighborhood state discovery and maintenance for relay set election. "SMF_TYPE" and "SMF_NBR_TYPE" Message and Address Block, respectfully, UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "respectively"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TLV structures (per [RFC5444]) are defined for use with the NHDP protocol. It is RECOMMENDED that all nodes performing SMF operation in conjunction with NHDP, include these TLV types in any NHDP HELLO messages generated. This capability allows for nodes participating in SMF to be explicitly identified along with their respective dynamic relay set algorithm. 4. SMF Applicability Within dynamic wireless routing topologies, maintaining traditional forwarding trees to support a multicast routing protocol is often not as effective as in wired networks due to the reduced reliability and increased dynamics of mesh topologies [MGL04] [GM99]. A basic packet forwarding service reaching all connected routers running the SMF protocol within a localized routing domain UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "localized routing domain"? is that the same as "interior routing domain" or just "routing domain"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D may provide a useful group communication paradigm for various classes of applications. Applications that could take advantage of a simple multicast forwarding service include multimedia streaming, interactive group- based messaging and applications, peer-to-peer middleware multicasting, and multi-hop mobile discovery or registration services. SMF is likely only appropriate for deployment in limited dynamic wireless routing domains so that the flooding process can be contained. The limited SMF routing domains are further defined as Macker, editor & SMF Design Team Expires September 15, 2011 [Page 8] =0C Internet-Draft SMF March 2011 administratively scoped multicast forwarding domains in Section 9.2. Note again that Figure 1 provides a notional architecture for typical SMF-capable nodes. A goal is that simple leaf nodes UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> remove "simple"? I think that this is not quite clear what a "leaf" node (/router) is in the context of the draft. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D may also participate in multicast traffic transmission and reception with standard IP network layer semantics (e.g., special or unnecessary encapsulation of IP packets should be avoided in this case). It is important that SMF deployments in localized edge network settings UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> definition of "localized edge network settings"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D are able to connect and interoperate with existing standard multicast protocols operating within more conventional Internet infrastructures. A multicast border router or proxy mechanism MUST be used when deployed alongside more fixed-infrastructure IP multicast routing such Protocol Independent Multicast (PIM) variants [RFC3973] and [RFC4601]. Present experimental SMF implementations have demonstrated gateway functionality at MANET border routers operating with existing external IP multicast routing protocols [CDHM07],[DHS08],and UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> space missing before "and" and before "[DHS08]" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [DHG09]. SMF may be extended or combined with other mechanisms to provide increased reliability and group specific filtering, but the details for this are not discussed here. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/here/in this document/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. SMF Packet Processing and Forwarding The SMF Packet Processing and Forwarding actions are conducted with the following packet handling activities: 1. Processing of outbound, locally-generated multicast packets. 2. Reception and processing of inbound packets on specific network interfaces. The purpose of intercepting outbound, locally-generated multicast packets is to apply any added packet marking needed to satisfy the DPD requirements so that proper forwarding may be conducted. Note that for some system configurations the interception of outbound packets for this purpose is not necessary. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH? such as? why? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Inbound multicast packets are received by the SMF implementation and processed for possible forwarding. This document does not presently support forwarding of directed broadcast addresses [RFC2644]. SMF implementations MUST be capable of forwarding IP multicast packets with destination addresses that are not node-local and link-local for IPv6 as defined in [RFC4291] and that are not within the local network control block as defined by [RFC5771] This will help support generic multi-hop multicast application needs or to distribute designated multicast traffic ingressing the SMF routing domain via border routers. The multicast addresses to be forwarded should be maintained by an a priori list or a dynamic Macker, editor & SMF Design Team Expires September 15, 2011 [Page 9] =0C Internet-Draft SMF March 2011 forwarding information base (FIB) that MAY interact with future MANET dynamic group membership extensions or management functions. There will also be a well-known multicast group for SMF. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "will be"? should we write a document defining that and cite it here? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This multicast group is specified to contain all routers within an SMF routing domain, so that packets transmitted to the multicast address associated with the group will be delivered to all connected routers running SMF. Due the mobile nature of a MANET, routers running SMF may not be topologically connected at particular times. For IPv6, the multicast address is specified to be "site-local". The name of the multicast group is "SL-MANET-ROUTERS". Minimally SMF MUST forward, as instructed by the relay set selection algorithm, unique (non-duplicate) packets received for this well-known group address when the TTL or hop limit value in the IP header is greater than 1. SMF MUST forward all additional global scope addresses specified within the dynamic FIB or configured list as well. In all cases, the following rules MUST be observed for SMF multicast forwarding: 1. IP multicast packets with TTL <=3D 1 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "TTL / hop limit" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MUST NOT be forwarded. 2. Link local IP multicast packets MUST NOT be forwarded. 3. Incoming IP multicast packets with an IP source address matching one of those of the local SMF router interface(s) MUST NOT be forwarded. 4. Received frames with the MAC source address matching any MAC address of the routers interfaces MUST NOT be forwarded. 5. Received packets for which SMF cannot reasonably ensure temporal DPD uniqueness UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Maybe "temporal uniqueness" should be defined before. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MUST NOT be forwarded. 6. When packets are forwarded, TTL or hop limit MUST be decremented by one. Note that rule #3 is important because over some types of wireless interfaces, the originating SMF router may receive re-transmissions of its own packets when they are forwarded by adjacent routers. This rule avoids unnecessary retransmission of locally-generated packets even when other forwarding decision rules would apply. An additional processing rule also needs to be considered based upon a potential security threat. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Maybe it would be interesting to add a rule number 7 to the previous list, which says something like "any further filtering can be applied by extensions to this specification", similar to NHDP, which allows to easily "hook in" extensions, e.g. for security? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D As discussed further in Section 10, there may be concern in some SMF deployments that malicious nodes may conduct a denial-of-service attack by remotely "previewing" (e.g., via a directional receive antenna) packets that an SMF node would be forwarding and conduct a "pre-play" attack by transmitting the packet before the SMF node would otherwise receive it but with a reduced TTL (or Hop Limit UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/Hop Limit/hop limit/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ) field value. This form of attack could cause an SMF node to create a DPD entry that would block the proper forwarding of the valid packet (with correct TTL UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> / hop limit. Or maybe, at first usage of "TTL", add a comment that throughout the document, TTL is used both for TTL (in IPv4) and hop limit (IPv6) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ) through the SMF area. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/SMF area/SMF routing domain/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A RECOMMENDED approach to prevent this attack, when it is a concern, would be to cache temporal packet TTL values along with the per- packet DPD state (hash value(s) and/or identifier as described in Macker, editor & SMF Design Team Expires September 15, 2011 [Page 10] =0C Internet-Draft SMF March 2011 Section 6). Then, if a subsequent matching (with respect to DPD) packet arrives with a larger TTL value than the packet that was previously forwarded, SMF should forward the new packet and update the TTL value cached with corresponding DPD state to the new, larger TTL value. There may be temporal cases where SMF would unnecessarily forward some duplicate packets using this approach, but those cases are expected to be minimal and acceptable when compared with the potential threat of denied service. Once these criteria UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> which criteria? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D have been met, an SMF implementation MUST make a forwarding decision dependent upon the relay set selection algorithm in use. One of the requirements of SMF is that it be configured to run a particular relay set selection algorithm when launched. If the SMF implementation is using Classical Flooding (CF), the forwarding decision is implicit once DPD uniqueness is determined. Otherwise, a forwarding decision depends upon the current interface-specific relay set state. The descriptions of the relay set selection algorithms in the Appendices to this document specify the respective heuristics for multicast packet forwarding and specific DPD or other processing required to achieve correct SMF behavior in each case. For example, one class of forwarding is based upon relay set election status and the packet's previous hop, while other classes designate the local SMF router as a forwarder for all neighboring nodes. 6. SMF Duplicate Packet Detection Duplicate packet detection (DPD) is often a requirement in MANET or wireless mesh packet forwarding mechanisms because packets may be transmitted out the same physical interface upon which they arrived and nodes may also receive copies of previously-transmitted packets from other forwarding neighbors. SMF operation requires DPD and implementations MUST provide mechanisms to detect and reduce the likelihood of forwarding duplicate multicast packets using temporal packet identification. It is RECOMMENDED this be implemented by keeping a history of recently-processed multicast packets for comparison to incoming packets. A DPD packet cache history SHOULD be kept long enough to span the maximum network traversal lifetime, MAX_PACKET_LIFETIME, of multicast packets being forwarded within an SMF routing domain. The DPD mechanism SHOULD avoid keeping unnecessary state for packet flows such as those that are locally- generated or link-local destinations that would not be considered for forwarding as presented in Section 5. For both IPv4 and IPv6, this document describes two basic multicast duplicate packet detection mechanisms: header content identification-based (I-DPD) and hash- based (H-DPD) duplicate detection. I-DPD is a mechanism using specific packet headers, and option headers in the case of IPv6, in combination with flow state to estimate the temporal uniqueness of a Macker, editor & SMF Design Team Expires September 15, 2011 [Page 11] =0C Internet-Draft SMF March 2011 packet. H-DPD uses hashing of the particular packet fields and payloads to provide an estimation of temporal uniqueness. Trade-offs of the two approaches to DPD merit different consideration UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D s/consideration/considerations/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D dependent upon the specific SMF deployment scenario. Because of the potential addition of a hop-by-hop option header with IPv6, SMF deployments MUST be configured to use a common mechanism and DPD algorithm. The main difference between IPv4 and IPv6 SMF-DPD specification is the avoidance of any additional header options in the IPv4 case. For each network interface, SMF implementations MUST maintain DPD packet state as needed to support the forwarding heuristics of the relay set algorithm used. In general this involves keeping track of previously forwarded packets so that duplicates are not forwarded, but some relay techniques have additional considerations, such as discussed in Appendix B.2. Additional details of I-DPD and H-DPD processing and maintenance for different classes of packets are described in the following sections. 6.1. IPv6 Duplicate Packet Detection This section describes the mechanisms and options for SMF IPv6 DPD. The core IPv6 packet header does not provide any explicit identification header field that can be exploited for I-DPD. The following areas are described to support IPv6 DPD and each is covered in more detail in particular subsections: 1. the hop-by-hop SMF-DPD option header, 2. the use of IPv6 fragment header fields for I-DPD when they exist, 3. the use of IPsec sequencing for I-DPD when a non-fragmented, IPsec header is detected, and 4. an H-DPD approach assisted, as needed, by the SMF-DPD option header. SMF MUST provide a DPD marking module that can insert the hop-by-hop IPv6 header option defined in this section. This process MUST come after any source-based fragmentation that may occur with IPv6. As with IPv4, SMF IPv6 DPD is presently specified to allow either a packet hash or header identification method for DPD. An SMF implementation MUST be configured to operate either in H-DPD or I-DPD mode and perform the appropriate routines outlined in the following sections. 6.1.1. IPv6 SMF-DPD Header Option The base IPv6 packet header does not contain a unique identifier suitable for DPD. This section defines an IPv6 Hop-by-Hop Option Macker, editor & SMF Design Team Expires September 15, 2011 [Page 12] =0C Internet-Draft SMF March 2011 [RFC2460] to serve this purpose for IPv6 I-DPD. Additionally, the header option provides a mechanism to guarantee non-collision of hash values for different packets when H-DPD is used. If this is the only hop-by-hop option present, the optional "TaggerId" field UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> would be good to explain the use of the field here UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (see below) is not included, and the size of the DPD packet identifier (sequence number) or hash token is 24 bits or less, UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> why 24 bits or less? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D this will result in the addition of 8 bytes to the IPv6 packet header including the "Next Header", "Header Extension Length", SMF-DPD option fields, and padding. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... |0|0|0| OptType | Opt. Data Len | UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> why are these first 16 bits empty? maybe just remove them? same for all following figures UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H| DPD Identifier Option Fields or Hash Assist Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 2 - IPv6 SMF-DPD Hop-by-Hop Header Option "Option Type" =3D (Lower 5 bits pending IANA assignment, highest order MUST be 000). By having these three bits be zero, this specification requires that nodes not recognizing this option type should skip over this option and continue processing the header and that the option must not change en route [RFC2460]. "Opt. Data Len" =3D Length of option content (I.e., 1 + ( ? ( + 1): 0) + Length(DPD ID)). UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I don't like that notation :-) is not a "condition" (I know, I am fan of Java more than C, which would allow such "dirty" expressions ;-) UH> I'd prefer using English to describe this. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "H-bit" =3D a hash indicator bit value identifying DPD marking type. 0 =3D=3D sequence-based approach w/ optional taggerId UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/taggerId/TaggerId/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D and a tuple-based sequence number. 1 =3D=3D indicates a hash assist value (HAV) field follows to aid in avoiding hash-based DPD collisions. When the "H-bit" is cleared (zero value), the SMF-DPD format to support I-DPD operation is specified as shown in Figure 2 and defines the extension header in accordance with [RFC2460]. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 13] =0C Internet-Draft SMF March 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... |0|0|0| OptType | Opt. Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|TidTyp|TidLen| TaggerId (optional) ... | UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> it looks like TidType is 3.5 bits long. I know, it doesn't fit in there... not sure there is a better way UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IPv6 SMF-DPD Header Option in I-DPD mode The "TidType" is UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> maybe use the same style for these definitions as before, i.e. with: "field" =3D definition... UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D a 3-bit field indicating the presence and type of the optional "TaggerId" field. The optional "TaggerId" is used to differentiate multiple ingressing border gateways that may commonly apply the SMF-DPD option header to packets from a particular source. This is provided for experimental purposes. The following table lists the valid TaggerId types: +---------+-------+-------------------------------------------------+ | Name | Value | Purpose | +---------+-------+-------------------------------------------------+ | NULL | 0 | Indicates no "TaggerId" field is present. | | | | "TidLen" MUST also be set to ZERO. | | DEFAULT | 1 | A "TaggerId" of non-specific context is | | | | present. "TidLen + 1" defines the length of | | | | the TaggerId field in bytes. | | IPv4 | 2 | A "TaggerId" representing an IPv4 address is | | | | present. The "TidLen" MUST be set to 3. | | IPv6 | 3 | A "TaggerId" representing an IPv6 address is | | | | present. The "TidLen" MUST be set to 15. | | ExtId | 7 | RESERVED FOR FUTURE USE (possible extended ID) | +---------+-------+-------------------------------------------------+ Table 1: TaggerId Types This format allows a quick check of the "TidType" field to determine if a "TaggerId" field is present. If the UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> is there a difference between the notation "TidType" and ? See my comment to add a "notations" description to the terminology section. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D is NULL, then the length of the DPD packet field corresponds to the UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> remove "the" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ( - 1). If the is non-NULL, then the length of the "TaggerId" field is equal to ( - 1) and the remainder of the option data comprises the DPD packet field. When the "TaggerId" field is present, the field can be considered a unique packet identifier in the context of the =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> taggerId or TaggerId? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D :srcAddr: dstAddr> tuple. When the "TaggerId" field is not present, then it is assumed the source host UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> host? or router? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D applied the SMF-DPD option and the can be considered unique in the context of the IPv6 packet header tuple. IPv6 I-DPD operation details Macker, editor & SMF Design Team Expires September 15, 2011 [Page 14] =0C Internet-Draft SMF March 2011 are described in Section 6.1.2. When the "H-bit" in the SMF-DPD option data is set, the data content value is interpreted as a Hash-Assist Value (HAV) used to facilitate H-DPD operation. In this case, source hosts UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> host? router? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D or ingressing gateways apply the SMF-DPD with a HAV only when required to differentiate the hash value of a new packet with respect to hash values in the DPD cache. This situation can be detected locally on the node by running the hash algorithm and checking the DPD cache. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> change . to , UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D prior ingressing a previously unmarked packet or a locally sourced packet. This helps to guarantee the uniqueness of generated hash values when H-DPD is used. Additionally, this also avoids the added overhead of applying the SMF-DPD option header to every packet. For many hash algorithms, it is expected that only sparse use of the SMF-DPD option may be required. The format of the SMF-DPD header option for H-DPD operation is given in Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... |0|0|0| OptType | Opt. Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Hash Assist Value (HAV) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPv6 SMF_DPD Header Option in H-DPD Mode UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> There is an inconsistency throughout the document between SMF_DPD and SMF-DPD UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The SMF-DPD option should be applied with a HAV UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/a/an/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D to produce a unique hash digest for packets within the context of the IPv6 packet header . The size of the HAV field is implied by the "Opt. Data Len". The appropriate size of the field depends upon the collision properties of the specific hash algorithm used. More details on IPv6 H-DPD operation are provided in Section 6.1.3. 6.1.2. IPv6 Identification-based DPD The following table summarizes the IPv6 I-DPD processing and forwarding decision approach. Within the table '*' indicates an ignore field condition. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> describe what's an "ignore field condition" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Macker, editor & SMF Design Team Expires September 15, 2011 [Page 15] =0C Internet-Draft SMF March 2011 +-------------+-----------+-----------+-----------------------------+ | IPv6 | IPv6 | IPv6 | SMF IPv6 I-DPD Mode Action | | Fragment | IPsec | I-DPD | | | Header | Header | Header | | +-------------+-----------+-----------+-----------------------------+ | Present | * | * | Use Fragment Header I-DPD | | | | | Check and Process for | | | | | Forwarding | UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> adding horizontal lines between rows could make it easier to read UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Not Present | Present | * | Use IPsec Header I-DPD | | | | | Check and Process for | | | | | Forwarding | | Present | * | Present | Invalid, do not Forward | | Not Present | Present | Present | Invalid, do not Forward | | Not Present | Not | Not | Add I-DPD Header,and | | | Present | Present | Process for Forwarding | | Not Present | Not | Present | Use I-DPD Header Check and | | | Present | | Process for Forwarding | +-------------+-----------+-----------+-----------------------------+ Table 2: IPv6 I-DPD Processing Rules If the IPv6 multicast packet UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> which? "a packet received on a router, considered for forwarding..." or similar.. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> The following would be easier to read, if it was an ennummeration, e.g. 1. if the packet is an IPv6 fragement, then... 2. else, if it is an... UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D is an IPv6 fragment, SMF MUST use the fragment extension header fields for packet identification. This identifier can be considered unique in the context of the of the IP packet. If the packet is an unfragmented IPv6 IPsec packet, SMF MUST use IPsec fields for packet identification. The IPsec header field can be considered a unique identifier in the context of the UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> maybe write what the abbreviation SPI stands for and cite IPsec UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D where the "IPsecType" is either AH or ESP [RFC4302]. For unfragmented, non-IPsec, IPv6 packets, the use of the SMF-DPD header option is necessary to support I-DPD operation. The SMF-DPD header option is applied in the context of the of the IP packet. End systems UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> End systems sounds like hosts. Do you mean routers? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D or ingressing SMF gateways are responsible for applying this option to support DPD. The following table UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/The following table/Table 3/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D summarizes these packet identification types: +-----------+---------------------------------+---------------------+ | IPv6 | Packet DPD ID Context | Packet DPD ID | | Packet | | | | Type | | | +-----------+---------------------------------+---------------------+ | Fragment | | | | IPsec | | | | Packet | | | | Regular | <[taggerId:] UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> the notation <[taggerId:] is unclear. Also, it should be TaggerId UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D srcAddr:dstAddr> | | +-----------+---------------------------------+---------------------+ Macker, editor & SMF Design Team Expires September 15, 2011 [Page 16] =0C Internet-Draft SMF March 2011 Table 3: IPv6 I-DPD Packet Identification Types "IPsecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP). UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> That has been said only a few sentences before UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The "TaggerId" is an optional field of the IPv6 SMF-DPD header option. 6.1.3. IPv6 Hash-based DPD A default hash-based DPD approach (H-DPD) for use by SMF is specified as follows. An MD5 [RFC1321] hash UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> hm, why fix to MD5 (deprecated)? couldn't we use a registry and then list possible signature methods in the appendix? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D of the non-mutable header fields, options fields, and data content of the IPv6 multicast packet is used to produce a 128-bit digest. The least significant 64 bits of this digest is used for SMF packet identification. The approach for calculating this hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [RFC4302] with respect to non-mutable fields. This approach should have a reasonably low probability of digest collision when packet headers and content are varying. MD5 is being applied in SMF only to provide a low probability of collision and is not being used for cryptographic or authentication purposes. A history of the packet hash values SHOULD be maintained within the context of the IPv6 packet header . SMF ingress points (i.e., source hosts UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> hosts / routers? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D or gateways) use this history to confirm that new packets are unique with respect to their hash value. The Hash-assist Value (HAV) field described in Section 6.1.1 is provided as a differentiating field when a digest collision would otherwise occur. Note that the HAV is an immutable option field and SMF MUST process any included HAV values (see Section 6.1.1) in its hash calculation. If a packet results in a digest collision (i.e., by checking the H-DPD digest history) within the DPD cache kept by SMF forwarders, the packet should UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> should or SHOULD? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D be silently dropped. If a digest collision is detected at an SMF ingress point the H-DPD option header is constructed with a randomly generated HAV. A UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/a/an/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D HAV is recalculated as needed to produce a non-colliding hash value prior to forwarding. The multicast packet is then forwarded with the added IPv6 SMF-DPD header option. The MD5 indexing and IPv6 HAV approaches are specified at present for consistency and robustness to suit experimental uses. Future approaches and experimentation may discover designs UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/designs/design/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D tradeoffs in hash robustness and efficiency worth considering. Enhancements MAY include reducing the maximum payload length that is processed, determining shorter indexes, or applying more efficient hashing algorithms. Use of the HAV functionality may allow for application of "lighter-weight" hashing techniques that might not have been Macker, editor & SMF Design Team Expires September 15, 2011 [Page 17] =0C Internet-Draft SMF March 2011 initially considered due to poor collision properties otherwise. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I suggest use of registry in the appendix UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Such techniques could reduce packet processing overhead and memory requirements. 6.2. IPv4 Duplicate Packet Detection This section describes the mechanisms and options for IPv4 DPD. The IPv4 packet header [RFC0791] 16-bit "Identification" field MAY be used for DPD assistance, but practical limitations may require alternative approaches in some situations. The following areas are described to support IPv4 DPD: 1. the use of IPv4 fragment header fields for I-DPD when they exist, 2. the use of IPsec sequencing for I-DPD when a non-fragmented IPv4 IPsec packet is detected, and 3. a H-DPD approach. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/a/an/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A specific SMF-DPD marking option is not specified for IPv4 since header options are not as tractable for end systems UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> hosts / routers? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D as for IPv6. IPv4 packets from a particular source are assumed to be marked with a temporally unique value in the "Identification" field of the packet header that can serve for SMF-DPD purposes. However, in present operating system networking kernels, the IPv4 header "Identification" value is not always generated properly, especially when the "don't fragment" (DF) bit is set. The IPv4 I-DPD mode of this specification requires that IPv4 "Identification" fields are managed reasonably by source hosts UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> host? router? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D and that temporally unique values are set within the context of the packet header tuple. If this is not expected during an SMF deployment, then it is RECOMMENDED that the H-DPD method be used as a more reliable approach. Since IPv4 SMF does not specify an options header UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> option header or options header? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D , the interoperability constraints are looser than the IPv6 version and forwarders may be operate with mixed H-DPD and I-DPD modes as long as they consistently perform the appropriate DPD routines outlined in the following sections. However, it is RECOMMENDED that a deployment be configured with a common mode for operational consistency. 6.2.1. IPv4 Identification-based DPD The following table UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/The following table/Table 4/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D summarizes the IPv4 I-DPD processing approach once a packet has passed the basic forwardable criteria described in Section 5. Within the table '*' indicates an ignore field condition. DF, MF, Fragment offset correspond to related fields and flags defined in [RFC0791]. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 18] =0C Internet-Draft SMF March 2011 +------+------+----------+---------+--------------------------------+ | DF | MF | Fragment | IPsec | IPv4 I-DPD Action | | flag | flag | offset | | | +------+------+----------+---------+--------------------------------+ | 1 | 1 | * | * | Invalid, Do Not Forward | | 1 | 0 | nonzero | * | Invalid, Do Not Forward | | * | 0 | zero | not | Tuple I-DPD Check and Process | | | | | Present | for Forwarding | | * | 0 | zero | Present | IPsec enhanced Tuple I-DPD | | | | | | Check and Process for | | | | | | Forwarding | | 0 | 0 | nonzero | * | Extended Fragment Offset Tuple | | | | | | I-DPD Check and Process for | | | | | | Forwarding | | 0 | 1 | zero or | * | Extended Fragment Offset Tuple | | | | nonzero | | I-DPD Check and Process for | | | | | | Forwarding | +------+------+----------+---------+--------------------------------+ Table 4: IPv4 I-DPD Processing Rules For performance reasons, IPv4 network fragmentation and reassembly of multicast packets within wireless MANET networks should be minimized, yet SMF provides the forwarding of fragments when they occur. If the IPv4 multicast packet is a fragment, SMF MUST use the fragmentation header fields for packet identification. This identification can be considered temporally unique in the context of the of the IPv4 packet. If the packet is an unfragmented IPv4 IPsec packet, SMF MUST use IPsec fields for packet identification. The IPsec header field can be considered a unique identifier in the context of the where the "IPsecType" is either AH or ESP [RFC4302]. Finally, for unfragmented, non-IPsec, IPv4 packets, the "Identification" field can be used for I-DPD purposes. The "Identification" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> or "Identification" (see comment same pages before) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D field can be considered unique in the context of the IPv4 tuple. The following table UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/The following table/Table 5/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D summarizes these packet identification types: +-----------+---------------------------------+---------------------+ | IPv4 | Packet Identification Context | Packet Identifier | | Packet | | | | Type | | | +-----------+---------------------------------+---------------------+ | Fragment | | | | IPsec | | | | Packet | | | Macker, editor & SMF Design Team Expires September 15, 2011 [Page 19] =0C Internet-Draft SMF March 2011 | Regular | | | +-----------+---------------------------------+---------------------+ Table 5: IPv4 I-DPD Packet Identification Types "IPsecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP). The limited size (16 bits) of the IPv4 header "Identification" field [RFC0791] may result in more frequent value field wrapping, particularly if a common sequence space is used by a source for multiple destinations. If I-DPD operation is required, the use of the "internal hashing" technique described in Section 10 may mitigate this limitation of the IPv4 "Identification" field for SMF-DPD. In this case the "internal hash" value would be concatenated with the "Identification" value for I-DPD operation. 6.2.2. IPv4 Hash-based DPD To ensure consistent IPv4 H-DPD operation among SMF nodes, a default hashing approach is specified. This is similar to that specified UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH>+ " in section xx " UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D for IPv6, but the H-DPD header option with HAV is not considered. SMF MUST perform an MD5 [RFC1321] UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> same comment as before, maybe put a flexible hashing using a registry? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D hash of the immutable header fields, option fields and data content of the IPv4 multicast packet resulting in a 128-bit digest. The least significant 64 bits of this digest is UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/is/are/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D used for SMF packet identification. The approach for calculating the hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [RFC4302] with respect to non-mutable fields. A history of the packet hash values SHOULD be maintained in the context of . The context for IPv4 is more specific than that of IPv6 since the SMF-DPD HAV cannot be employed to mitigate hash collisions. The MD5 hash is specified at present for consistency and robustness. Future approaches and experimentation may discover design tradeoffs in hash robustness and efficiency worth considering for future revisions of SMF. This MAY include reducing the packet payload length that is processed, determining shorter indexes, or applying a more efficient hashing algorithm. 7. Relay Set Selection UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> Maybe add a sentence here before 7.1. It looks weird to have no text between two headers. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 7.1. Non-Reduced Relay Set Forwarding SMF implementations MUST support CF as a basic forwarding mechanism when reduced relay set information is not available or not selected Macker, editor & SMF Design Team Expires September 15, 2011 [Page 20] =0C Internet-Draft SMF March 2011 for operation. In CF mode, each node transmits a locally generated or newly received forwardable packet exactly once. The DPD techniques described in Section 6 are critical to proper operation and prevent duplicate packet retransmissions by the same forwarding node. 7.2. Reduced Relay Set Forwarding MANET reduced relay sets are often achieved by distributed algorithms that can dynamically calculate a topological connected dominating set (CDS). A goal of SMF is to apply reduced relay sets for more efficient multicast dissemination within dynamic topologies. To accomplish this SMF MUST UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH>maybe: s/SMF/an SMF implementation/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D support the ability to modify its multicast packet forwarding rules based upon relay set state received dynamically during operation. In this way, SMF forwarding operates effectively as neighbor adjacencies or multicast forwarding policies within the topology change. In early SMF experimental prototyping, the relay set information has been derived from coexistent unicast routing control plane traffic flooding processes [MDC04]. From this experience, extra pruning considerations were sometimes required when utilizing a relay set from a separate routing protocol process. As an example, relay sets formed for the unicast control plane flooding MAY include additional redundancy that may not be desired for multicast forwarding use (e.g., biconnected relay set). Here is a recommended criteria list for SMF relay set selection algorithm candidates: 1. Robustness to topological dynamics and mobility 2. Localized election or coordination of any relay sets 3. Reasonable minimization of CDS relay set size given above constraints 4. Heuristic support for preference or election metrics Some relay set algorithms meeting these criteria are described in the Appendices of this document. Additional relay set selection algorithms may be specified in separate specifications in the future. Each Appendix subsection in this document can serve as a template for specifying additional relay algorithms. Figure 4 depicts a UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/a/an/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D information flow diagram of possible relay set control options. The SMF Relay Set State UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH>Relay Set or relay set (as later in the paragraph)? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D represents the information base that is used by SMF in the forwarding decision process. The relay set control option diagram demonstrates that the SMF relay set Macker, editor & SMF Design Team Expires September 15, 2011 [Page 21] =0C Internet-Draft SMF March 2011 state may be determined by fundamentally three different methods: independent operation with NHDP [RFC5444] input providing dynamic network neighborhood adjacency information that is then used by a particular relay set selection, slave operation with an existing unicast MANET routing protocol that is capable of providing CDS election information that can be used by SMF, and cross layer operation that may involve lower layer neighbor or link information. Other heuristics to influence and control election can come from network management or other interfaces as shown on the right UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> + " of the figure" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . Of course CF mode, UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> move comma to right after "of course"? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D simplifies the control and does not require other input but relies solely on DPD. Possible L2 Trigger/Information | | ______________ ______v_____ __________________ | MANET | | | | | | Neighborhood | | Relay Set | | Other Heuristics | | Discovery |----------->| Selection |<------| (Preference,etc) | | Protocol | neighbor | Algorithm | | Net Management | |______________| info |____________| |__________________| \ / \ / neighbor\ / Dynamic Relay info* \ ____________ / Set Status \ | SMF | / (State, {neighbor info}) `-->| Relay Set |<--' | State | -->|____________| / / ______________ | Coexistent | | MANET | | Unicast | | Process | |______________| Figure 4: SMF Reduced Relay Set Information Flow More discussion is provided on the three styles of SMF operation with reduced relay sets as illustrated in Figure 4 : UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> remove blank after "4" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Independent operation: In this case, SMF operates independently from any unicast routing protocols. To support reduced relay sets SMF MUST perform its own relay set selection using information gathered from signaling. It is RECOMMENDED that an associated MANET NHDP process be use UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/use/used/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D for this signaling. NHDP Macker, editor & SMF Design Team Expires September 15, 2011 [Page 22] =0C Internet-Draft SMF March 2011 messaging SHOULD be appended with additional [RFC5444] type- length-value (TLV) content to support SMF-specific requirements as discussed in [RFC6130] and for the applicable relay set algorithm described in the Appendices of this document or future specifications. Unicast routing protocols may co-exist, even using the same NHDP process, but signaling that supports reduced relay set selection for SMF is independent of these protocols. 2. Operation with CDS-aware unicast routing protocol: In this case, a coexistent unicast routing protocol provides dynamic relay set state based upon its own control plane CDS or neighborhood discovery information. 3. Cross-layer Operation: In this case, SMF operates using neighborhood status and triggers from a cross-layer information base for dynamic relay set selection and maintenance (e.g., lower link layer). 8. SMF Neighborhood Discovery Requirements This section defines the requirements for use of the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] to support SMF operation. Note that basic CF forwarding requires no neighborhood topology knowledge since in this configured mode every SMF node relays all traffic. Supporting more reduced SMF relay set operation requires the discovery and maintenance of dynamic neighborhood topology information. The MANET NHDP protocol can be leveraged UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> + "to" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D provide this necessary information, however there are SMF-specific requirements for related NHDP use. This is the case for both "independent" SMF operation where NHDP is being used specifically to support SMF or when one NHDP instance is used for both for UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> "is used for both for" (I am not a native speaker, but it seems weird..= .) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SMF and a coexistent MANET unicast routing protocol. NHDP HELLO messages and the resultant neighborhood information base are described separately within the NHDP specification. To summarize, the NHDP protocol provides the following basic functions: 1. 1-hop neighbor link sensing and bidirectionality checks of neighbor links, 2. 2-hop neighborhood discovery including collection of 2-hop neighbors and connectivity information, 3. Collection and maintenance of the above information across multiple interfaces, and 4. A method for signaling SMF information throughout the 2-hop neighborhood through the use of TLV extensions. Appendices (A-C) of this document describe CDS-based relay set selection algorithms that can achieve efficient SMF operation, even in dynamic, mobile networks and each of the algorithms has been Macker, editor & SMF Design Team Expires September 15, 2011 [Page 23] =0C Internet-Draft SMF March 2011 initially experimented within a working SMF prototype [MDDA07]. When using these algorithms in conjunction with NHDP, a method verifying neighbor SMF operation is required in order to insure correct relay set selection. NHDP along with SMF operation verification provides the necessary information required by these algorithms to conduct relay set selection. Verification of SMF operation may be done administratively or through the use of the SMF relay algorithms TLVs defined in the following subsections. Use of the SMF relay algorithm TLVs is RECOMMENDED when using NHDP for SMF neighborhood discovery. The following sub-sections specify some SMF-specific TLV types supporting general SMF operation or supporting the algorithms described in the Appendices. The Appendices describing several relay set algorithms also specify any additional requirements for use with NHDP and reference the applicable TLV types as needed. 8.1. SMF Relay Algorithm TLV Types This section specifies TLV types to be used within NHDP messages to identify the CDS relay set selection algorithm(s) in use. Two TLV types are defined, one message TLV type and one address TLV type. 8.1.1. SMF Message TLV Type The message TLV type denoted SMF_TYPE is used to identify the existence of an SMF instance operating in conjunction with NHDP. This message TLV type makes use of the extended type field as defined by [RFC5444] to convey the CDS relay set selection algorithm currently in use by the SMF message originator. When NHDP is used to support SMF operation, the SMF_TYPE TLV, containing the extended type field with the appropriate value, SHOULD be included in NHDP_HELLO messages (HELLO messages as defined in [RFC6130]. This allows SMF nodes to learn when neighbors are configured to use NHDP for information exchange including algorithm type and related algorithm information. This information can be used to take action, such as ignoring neighbor information using incompatible algorithms. It is possible that SMF neighbors MAY be configured differently and still operate cooperatively, but these cases will vary dependent upon the algorithm types designated. This document defines the following Message TLV type as specified in Table 6 conforming to [RFC5444]. The TLV extended type field is used to contain the sender's "Relay Algorithm Type". The interpretation of the "value" content of these TLVs is defined per "Relay Algorithm Type" and may contain algorithm specific information. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 24] =0C Internet-Draft SMF March 2011 +---------------+----------------+--------------------+ | | TLV syntax | Field Values | UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/syntax/Syntax/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +---------------+----------------+--------------------+ | type | | SMF_TYPE | | extended type | | | | length | | variable | | value | | variable | +---------------+----------------+--------------------+ Table 6: SMF Type Message TLV In Table 6 is an 8-bit field containing a number 0-255 representing the "Relay Algorithm Type" of the originator address of the corresponding NHDP message. Possible values for the are defined in Table 7. The table provides value assignments, future IANA assignment spaces, and an experimental space. The experimental space use MUST NOT assume uniqueness and thus should not be used UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> should not or SHOULD NOT UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D for general interoperable deployment prior to official IANA assignment. +-------------+--------------------+--------------------------------+ | Type Value | Extended Type | Algorithm | | | Value | | +-------------+--------------------+--------------------------------+ | SMF_TYPE | 0 | CF | | SMF_TYPE | 1 | S-MPR | | SMF_TYPE | 2 | E-CDS | | SMF_TYPE | 3 | MPR-CDS | | SMF_TYPE | 4-127 | Future Assignment STD action | | SMF_TYPE | 128-239 | No STD action required | | SMF_TYPE | 240-255 | Experimental Space | +-------------+--------------------+--------------------------------+ Table 7: SMF Relay Algorithm Type Values Acceptable and fields of an SMF_TYPE TLV are dependent on the extended type value (i.e. relay algorithm type). The appropriate algorithm type, as conveyed in the field, defines the meaning and format of its TLV field. For the algorithms defined by this document, see the appropriate appendix for the field format. 8.1.2. SMF Address Block TLV Type An address block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor relay algorithm) is specified in Table 8. This TLV enables CDS relay algorithm operation and configuration to be shared among 2-hop Macker, editor & SMF Design Team Expires September 15, 2011 [Page 25] =0C Internet-Draft SMF March 2011 neighborhoods. Some relay algorithms require two hop neighbor configuration in order to correctly select relay sets. It is also useful when mixed relay algorithm operation is possible, some examples of mixed use is UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/is/are/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D outlined in the appendices. The message SMF_TYPE TLV UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I think in RFC5444 it is Message TLV and not message TLV. (similiar for address.. etc). UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D and address block SMF_NBR_TYPE TLV types share a common format. +---------------+----------------+--------------------+ | | TLV syntax | Field Values | +---------------+----------------+--------------------+ | type | | SMF_NBR_TYPE | | extended type | | | | length | | variable | | value | | variable | +---------------+----------------+--------------------+ Table 8: SMF Type Address Block TLV in Table 8 is an 8-bit unsigned integer field containing a number 0-255 representing the "Relay Algorithm Type" value that corresponds to any associated address in the address block. Note that "Relay Algorithm Type" values for 2-hop neighbors can be conveyed in a single TLV or multiple value TLVs as described in [RFC5444]. It is expected that SMF nodes using NHDP construct address blocks with SMF_NBR_TYPE TLVs to advertise "Relay Algorithm Type" and to advertise neighbor algorithm values received in SMF_TYPE TLVs from those neighbors. Again values for the are defined in Table 8. The interpretation of the "value" field of SMF_NBR_TYPE TLVs is defined per "Relay Algorithm Type" and may contain algorithm specific information. See the appropriate appendix for definitions of value fields for the algorithms defined by this document. 9. SMF Border Gateway Considerations It is expected that SMF will be used to provide simple forwarding of multicast traffic within a MANET or mesh routing topology. A border router gateway approach should be used to allow interconnection of SMF areas UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> SMF routing domain? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D with networks using other multicast routing protocols, such as PIM. It is important to note that there are many scenario- specific issues that should be addressed when discussing border multicast routers. At the present time, experimental deployments of SMF and PIM border router approaches have been demonstrated[DHS08]. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> missing blank before [DHS08] UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some of the functionality border routers may need to address includes Macker, editor & SMF Design Team Expires September 15, 2011 [Page 26] =0C Internet-Draft SMF March 2011 the following: 1. Determining which multicast group traffic transits the border router whether entering or exiting the attached SMF routing domain. 2. Enforcement of TTL threshold or other scoping policies. 3. Any marking or labeling to enable DPD on ingressing packets. 4. Interface with exterior multicast routing protocols. 5. Possible operation with multiple border routers (presently beyond scope of this document). 6. Provisions for participating non-SMF nodes. Each of these areas is discussed in more detail in the following subsections. Note the behavior of SMF border routers is the same as that of non-border SMF nodes when forwarding packets on interfaces within the SMF routing domain. Packets that are passed outbound to interfaces operating fixed-infrastructure multicast routing protocols SHOULD be evaluated for duplicate packet status since present standard multicast forwarding mechanisms do not usually perform this function. 9.1. Forwarded Multicast Groups Mechanisms for dynamically determining groups for forwarding into a MANET SMF routing domain is an evolving technology area. Ideally, only groups for which there is active group membership should be injected into the SMF domain. This can be accomplished by providing an IPv4 Internet Group Membership Protocol (IGMP) or IPv6 Multicast Listener Discovery (MLD) proxy protocol so that MANET SMF nodes can inform attached border routers (and hence multicast networks) of their current group membership status. For specific systems and services it may be possible to statically configure group membership joins in border routers, but it is RECOMMENDED that some form of IGMP/MLD proxy or other explicit, dynamic control of membership be provided. Specification of such an IGMP/MLD proxy protocol is beyond the scope of this document. For outbound traffic, SMF border routers can perform duplicate packet detection and forward non-duplicate traffic that meets TTL/hop limit and scoping criteria and forward packet to interfaces external to the SMF routing domain. Appropriate IP multicast routing (PIM, etc) on those interfaces can then make further forwarding decisions with respect to the multicast packet. Note that the presence of multiple border routers associated with a MANET routing domain raises additional issues. This is further discussed in Section 9.4 but further work is expected to be needed here. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 27] =0C Internet-Draft SMF March 2011 9.2. Multicast Group Scoping Multicast scoping is used by network administrators to control the network routing domains reachable by multicast packets. This is usually done by configuring external interfaces of border routers in the border of a routing domain to not forward multicast packets which must be kept within the routing region. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> routing domain? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is commonly done based on TTL of messages or the basis of group addresses. These schemes are known respectively as: 1. TTL scoping. 2. Administrative scoping. For IPv4, network administrators can configure border routers with the appropriate TTL thresholds or administratively scoped multicast groups for the router interfaces as with any traditional multicast router. However, for the case of TTL scoping it SHOULD be taken into account that the packet could traverse multiple hops within the MANET SMF routing domain before reaching the border router. Thus, TTL thresholds SHOULD be selected carefully. For IPv6, multicast address spaces include information about the scope of the group. Thus, border routers of an SMF routing domain know if they must forward a packet based on the IPv6 multicast group address. For the case of IPv6, it is RECOMMENDED that a MANET SMF routing domain be designated a site-scoped multicast domain. Thus, all IPv6 site-scoped multicast packets in the range FF05::/16 SHOULD be kept within the MANET SMF routing domain by border routers. IPv6 packets in any other wider range scopes (i.e. FF08::/16, FF0B::/16 and FF0E::16) MAY traverse border routers unless other restrictions different from the scope applies. Given that scoping of multicast packets is performed at the border routers, and given that existing scoping mechanisms are not designed to work with mobile routers, it is assumed that non-border routers running SMF will not stop forwarding multicast data packets of an appropriate site scoping. That is, it is assumed that an SMF routing domain is a site-scoped multicast area. 9.3. Interface with Exterior Multicast Routing Protocols The traditional operation of multicast routing protocols is tightly integrated with the group membership function. Leaf routers are configured to periodically gather group membership information, while intermediate routers conspire to create multicast trees connecting routers with directly-connected multicast sources and routers with active multicast receivers. In the concrete case of SMF, border routers can be considered leaf routers. Mechanisms for multicast Macker, editor & SMF Design Team Expires September 15, 2011 [Page 28] =0C Internet-Draft SMF March 2011 sources and receivers to interoperate with border routers over the multihop MANET SMF routing domain as if they were directly connected to the router need to be defined. The following issues need to be addressed: 1. A mechanism by which border routers gather membership information 2. A mechanism by which multicast sources are known by the border router 3. A mechanism for exchange of exterior routing protocol messages across the SMF routing domain if the SMF routing domain is to provide transit connectivity for multicast traffic. It is beyond the scope of this document to address implementation solutions to these issues. As described in Section 9.1, IGMP/MLD proxy mechanisms can be deployed to address some of these issues. Similarly, exterior routing protocol messages could be tunneled or conveyed across an SMF routing domain but doing this robustly in a distributed wireless environment likely requires additional considerations outside the scope of this document. The need for the border router to receive traffic from recognized multicast sources within the SMF routing domain is important to potentially achieve interoperability with existing routing protocols. For instance, PIM-S requires routers with locally attached multicast sources to register them to the Rendezvous Point (RP) so that nodes can join the multicast tree. In addition, if those sources are not advertised to other autonomous systems (AS) using Multicast Source Discovery Protocol (MSDP), receivers in those external networks are not able to join the multicast tree for that source. 9.4. Multiple Border Routers An SMF domain UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> routing domain? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D might be deployed with multiple participating nodes having connectivity to external, fixed-infrastructure networks. Allowing multiple nodes to forward multicast traffic to/from the SMF routing domain can be beneficial since it can increase reliability, and provide better service. For example, if the SMF routing domain were to fragment with different SMF nodes maintaining connectivity to different border routers, multicast service could still continue successfully. But, the case of multiple border routers connecting a SMF routing domain to external networks presents several challenges for SMF: 1. Handling duplicate unmarked IPv4 or IPv6 (without IPsec encapsulation or DPD option) packets possibly injected by multiple border routers. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 29] =0C Internet-Draft SMF March 2011 2. Source-based relay algorithms handling of duplicate traffic injected by multiple border routers. 3. Determination of which border router(s) will forward outbound multicast traffic. 4. Additional challenges with interfaces to exterior multicast routing protocols. When multiple border routers are present they may be alternatively (due to route changes) or simultaneously injecting common traffic into the MANET routing region that has not been previously marked for SMF-DPD. Different border routers would not be able to implicitly synchronize sequencing of injected traffic since they may not receive exactly the same messages due to packet losses. For IPv6 I-DPD operation, the optional "TaggerId" field described for the SMF-DPD header option can be used to mitigate this issue. When multiple border routers are injecting a flow into a MANET routing region, UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> routing region? Is there a difference between MANET routing domain and SMF routing domain? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D there are two forwarding policies that SMF nodes running I-DPD may implement: 1. Redundantly forward the multicast flows (identified by ) from each border router, performing DPD processing on a or basis, or 2. Use some basis to select the flow of one tagger (border router) over the others and forward packets for applicable flows (identified by ) only for the selected "Tagger ID" until timeout or some other criteria to favor another tagger occurs. It is RECOMMENDED that the first approach be used in the case of I-DPD operation. Additional specification may be required to describe an interoperable forwarding policy based on this second option. Note that the implementation of the second option requires that per-flow (i.e., ) state be maintained for the selected "Tagger ID". The deployment of H-DPD operation may alleviate DPD resolution when ingressing traffic comes from multiple border routers. Non-colliding hash indexes (those not requiring the H-DPD options header in IPv6) should be resolved effectively. 10. Security Considerations Gratuitous use of option headers can cause problems in routers. Other IP routers external to an SMF routing domains UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> s/domains/domain/ UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D that might receive forwarded multicast should UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> should or SHOULD? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ignore SMF-specific header options when encountered. The header options types are encoded appropriately to allow for this behavior. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 30] =0C Internet-Draft SMF March 2011 Here we briefly discuss several SMF denial-of-service (DoS) attack scenarios and we provide some initial recommended mitigation strategies. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> I'd prefer to not use "we". (instead, "several SMF DoS attack scenarios are discussed..." etc) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A potential denial-of-service attack against SMF forwarding is possible when a malicious node has a form of wormhole access to multiple part of a network topology. In the wireless ad hoc case, a directional antenna is one way to provide such a wormhole physically. If such a node can preview forwarded packets in one part of the network and forward modified versions to another part of the network it can perform the following attack. The malicious node could reduce the TTL or Hop Limit of the packet and transmit it to the SMF node causing it to forward the packet with a limited TTL (or even drop it) and make a DPD entry that could block or limit the subsequent forwarding of later-arriving valid packets with correct TTL values. This would be a relatively low-cost, high-payoff attack that would be hard to detect and thus attractive to potential attackers. An approach of caching TTL information with DPD state and taking appropriate forwarding actions is identified in Section 5 to mitigate this form of attack. Sequence-based packet identifiers are predictable and thus provide an opportunity for a DoS attack against forwarding. Forwarding protocols that use DPD techniques, such as SMF, may be vulnerable to DoS attacks based on spoofing packets with apparently valid packet identifier fields. In wireless environments, where SMF will most likely be used, the opportunity for such attacks may be more prevalent than in wired networks. In the case of IPv4 packets, fragmented IP packets or packets with IPsec headers applied, the DPD "identifier portions" of potential future packets that might be forwarded is highly predictable and easily subject to denial-of- service attacks against forwarding. A RECOMMENDED technique to counter this concern is for SMF implementations to generate an "internal" hash value that is concatenated with the explicit I-DPD packet identifier to form a unique identifier that is a function of the packet content as well as the visible identifier. SMF implementations could seed their hash generation with a random value to make it unlikely that an external observer could guess how to spoof packets used in a denial-of-service attack against forwarding. Since the hash computation and state is kept completely internal to SMF nodes, the cryptographic properties of this hashing would not need to be extensive and thus possibly of low complexity. Experimental implementations may determine that a lightweight hash of even only portions of packets may suffice to serve this purpose. While H-DPD is not as readily susceptible to this form of DoS attack, it is possible that a sophisticated adversary could use side information to construct spoofing packets to mislead forwarders using Macker, editor & SMF Design Team Expires September 15, 2011 [Page 31] =0C Internet-Draft SMF March 2011 a well-known hash algorithm. Thus, similarly, a separate "internal" hash value could be concatenated with the well-known hash value to alleviate this security concern. The support of forwarding IPsec packets without further modification for both IPv4 and IPv6 is supported by this specification. Authentication mechanisms to identify the source of IPv6 option headers should be considered to reduce vulnerability to a variety of attacks. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> maybe add something that the security considerations of the used neighbor discovery mechanism (NHDP) also applies UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 11. IANA Considerations This document raises multiple IANA Considerations. These include the IPv6 SMF_DPD hop-by-hop Header Extension defined and multiple Type- Length-Value (TLV) constructs UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> missing ( UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [RFC5444]) to be used with NHDP [RFC6130]operation UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> missing blank UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D as needed to support different forms of SMF operation. There is one message TLV type and one address TLV type needed to be assigned for SMF purposes as discussed in Section 8.1. The value of the IPv6 SMF-DPD Hop-by-Hop Option Type is TBD (to be assigned). The SL-MANET-ROUTERS multicast address will be registered for both IPv4 and IPv6 multicast address spaces. 11.1. IPv6 SMF-DPD Header Extension This document requests IANA assignment of the "SMF_DPD" hop-by-hop option type from the IANA "IPv6 Hop-by-Hop Options Option Type" registry (see Section 5.5 of [RFC2780]). The format of this new option type is described in Section 6.1.1. A portion of the option data content is the taggger identifier type "TidType" that provides a context for the "TaggerId" that is optionally included to identify the node that added the SMF_DPD option to the packet. This document defines a namespace for IPv6 SMF_DPD Tagger Identifier Type values: ietf:manet:smf:taggerIdTypes The values that can be assigned within the "ietf:manet:smf: taggerIdTypes" name-space are numeric indexes in the range [0, 7], boundaries included. All assignment requests are granted on an "IETF Consensus" basis as defined in [RFC5226]. This specification registers Tagger Identification Type values from Table 9 in the registry "ietf:manet:smf:taggerIdTypes": Macker, editor & SMF Design Team Expires September 15, 2011 [Page 32] =0C Internet-Draft SMF March 2011 +----------+-------+---------------+ | Mnemonic | Value | Reference | +----------+-------+---------------+ | NULL | 0 | This document | | DEFAULT | 1 | This document | | IPv4 | 2 | This document | | IPv6 | 3 | This document | | ExtId | 7 | This document | +----------+-------+---------------+ Table 9: TaggerId Types 11.2. SMF Type-Length-Value This document requests IANA assignment of one message "SMF_TYPE" TLV type and one address block "SMF_NBR_TYPE" TLV type from the [RFC6130] specific registry space. The common format of these new TLV types is described in Table 6 and Table 8. Furthermore this document defines a namespace for algorithm ID types using the extended type TLV value field defined by [RFC5444]. Both SMF_TYPE and SMF_NBR_TYPE TLVs use this namespace. ietf:manet:packetbb:nhdp:smf:relayAlgorithmID The values that can be assigned within the "ietf:manet:packetbb:nhdp: smf:relayAlgorithmID" name-space are numeric indexes in the range [0, 239], boundaries included. Assignment requests for the [0-127] are granted on an "IETF Consensus" basis as defined in [RFC5226]. Standards action is not required for assignment requests of the range [128-239]. Documents requesting relayAlgorithmId values SHOULD define value field uses contained by the SMF_TYPE: and SMF_NBR_TYPE: full type TLVs. This specification registers the following Relay Algorithm ID Type values shown in Table 10 in the registry "ietf:manet:packetbb:nhdp: smf:relayAlgorithmID UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> missing " UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +----------+-------+------------+ | Mnemonic | Value | Reference | +----------+-------+------------+ | CF | 0 | | | S-MPR | 1 | Appendix B | | E-CDS | 2 | Appendix A | | MPR-CDS | 3 | Appendix C | +----------+-------+------------+ Table 10: Relay Set Algorithm Type Values Macker, editor & SMF Design Team Expires September 15, 2011 [Page 33] =0C Internet-Draft SMF March 2011 12. Acknowledgments Many of the concepts and mechanisms used and adopted by SMF resulted from many years of discussion and related work within the MANET working group since the late 1990s. There are obviously many contributors to past discussions and related draft documents within the working group that have influenced the development of SMF concepts that deserve acknowledgment. In particular, the document is largely a direct product of the earlier SMF design team within the IETF MANET working group and borrows text and implementation ideas from the related individuals and activities. Some of the direct contributors who have been involved in design, content editing, prototype implementation, major commenting, and core discussions are listed below in alphabetical order. We appreciate all the input and feedback from the many community members and early implementation users we have heard from that are not on this list as well. Key contributors/authors in alphabetical order: Brian Adamson Teco Boot Ian Chakeres Thomas Clausen Justin Dean Brian Haberman Ulrich Herberg Charles Perkins Pedro Ruiz Fred Templin Maoyu Wang The RFC text was produced using Marshall Rose's xml2rfc tool and Bill Fenner's XMLmind add-ons. 13. References 13.1. Normative References [E-CDS] Ogier, R., "MANET Extension of OSPF Using CDS Flooding", Proceedings of the 62nd IETF , March 2005. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> is that required to be normative? Anyways, better cite the RFC than the IETF proceedings (RFC5614) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing Connected Dominating Sets with Multipoint Relays", Ad Hoc and Sensor Wireless Networks , January 2005. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> is that required to be normative? UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 34] =0C Internet-Draft SMF March 2011 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> if we use a code point instead, we would not need to cite MD5 (or not normatively) UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999. [RFC2780] Bradner, S., "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", March 2000. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> add RFC 2780 before "March 2000", like for the other citations UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol", 2003. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> month and RFC number missing before 2003 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4302] Kent, S., "IP Authentication Header", December 2005. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> RFC number missing before Dec. 2005 UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5444] Clausen, T. and et al, UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> and et al doesn't work :-) better cite all authors, like for the other citations UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Generalized MANET Packet/Message Format", RFC 5444, February 2009. [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignment", RFC 5771, March 2010. [RFC6130] Clausen, T. and et al, "MANET Neighborhood Discovery Protocol", RFC 6130, March 2011. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> The precise title is "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 13.2. Informative References [CDHM07] Chakeres, I., Danilov, C., and T. Henderson, "Connecting MANET Multicast", IEEE MILCOM 2007 Proceedings , 2007. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> remove blank after Proceedings. similiarly, there are some blanks too much in the following cites UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [DHG09] Danilov, C., Henderson, T., and T. Goff, "Experiment and field demonstration of a 802.11-based ground-UAV mobile ad-hoc network", Proceedings of the 28th IEEE conference on Military Communications , 2009. [DHS08] Danilov, C., Henderson, T., and T. Spagnolo, "MANET Multicast with Multiple Gateways", IEEE MILCOM 2008 Macker, editor & SMF Design Team Expires September 15, 2011 [Page 35] =0C Internet-Draft SMF March 2011 Proceedings , 2008. [GM99] Garcia-Luna-Aceves, JJ. and E. Madruga, "The core-assisted mesh protocol", Selected Areas in Communications, IEEE Journal on Volume 17, Issue 8, August 1999. [JLMV02] Jacquet, P., Laouiti, V., Minet, P., and L. Viennot, "Performance of multipoint relaying in ad hoc mobile routing protocols", Networking , 2002. [MDC04] Macker, J., Dean, J., and W. Chao, "Simplified Multicast Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004 Proceedings , 2004. [MDDA07] Macker, J., Downard, I., Dean, J., and R. Adamson, "Evaluation of distributed cover set algorithms in mobile ad hoc network for simplified multicast forwarding", ACM SIGMOBILE Mobile Computing and Communications Review Volume 11 , Issue 3, July 2007. [MGL04] Mohapatra, P., Gui, C., and J. Li, "Group Communications in Mobile Ad hoc Networks", IEEE Computer Vol. 37, No. 2, February 2004. [NTSC99] Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast Storm Problem in Mobile Ad hoc Networks", Proceedings Of ACM Mobicom 99 , 1999. [RFC2501] Macker, JP. and MS. Corson, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", 1999. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> month and RFC number UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding", 2003. UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UH> month and RFC number UH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. From touch@isi.edu Wed Mar 30 10:09:42 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D780828C12E; Wed, 30 Mar 2011 10:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-1.936, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 xRIAK7dDwOv3; Wed, 30 Mar 2011 10:09:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A2A5028C158; Wed, 30 Mar 2011 10:09:41 -0700 (PDT) Received: from [130.129.68.50] (dhcp-4432.meeting.ietf.org [130.129.68.50]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p2UHAXSV011560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Mar 2011 10:10:46 -0700 (PDT) References: <00a901cbeed5$3c738700$b55a9500$@nrl.navy.mil> In-Reply-To: <00a901cbeed5$3c738700$b55a9500$@nrl.navy.mil> Mime-Version: 1.0 (iPad Mail 8F190) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8F190) From: Joe Touch Date: Wed, 30 Mar 2011 19:10:55 +0200 To: Justin Dean X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 30 Mar 2011 14:11:45 -0700 Cc: MANET IETF , "" Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 17:09:43 -0000 On Mar 30, 2011, at 2:23 PM, "Justin Dean" wrote: > "Deprecating the use of the IPv4 ID field for non-reassembly uses > should have little - if any - impact." >=20 > That statement wasn't true for very long was it... Technically even if your devices rely on it it wouldn't be long before they s= tarted dropping valid packets, IMO. > Well section 9 may provide a way out. >=20 > "Network address translators (NATs) and address/port translators > (NAPTs) rewrite IP fields, and tunnel ingresses (using IPv4 > encapsulation) copy and modify some IPv4 fields, so all are > considered sources, as do any devices that rewrite any portion of the > source address, destination address, protocol, and ID tuple for non- > atomic datagrams [RFC3022]. As a result, they are subject to all the > requirements of any source, as has been noted." >=20 > With the current draft incoming packets can have their id fields modified b= y > the SMF gateway before being forwarded in the MANET. I would say this mak= es > the gateway a source. Then we just need to fragment everything! I can se= e > the reason for banning the behavior in high bandwidth wired links where > duplicates only occur with routing loops and the id wraps so fast it is > useless. But the way this is written it bans ALL use of the IPv4 ID field= > for duplicate detection. >=20 > "The IPv4 ID field is no longer permitted for duplicate detection."=20 >=20 > Does this mean we can't even hash this field for duplicate detection?! The field and the other parts of the header are not ensured unique for fragm= ents right now - many hosts break the rules. A packet as a whole isn't eithe= r.=20 It is much safer to expect the higher layers to drop such duplicates. You ca= n drop but you need more requirements - e.g., that the higher layer won't se= nd valid dups (TCP seqnos accomplish this), and you check/hash the whole pac= ket. The header *isn't* enough right now, unless you ensure rate limiting. Joe >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >> Of Teco Boot >> Sent: Wednesday, March 30, 2011 7:29 AM >> To: int-area@ietf.org; MANET IETF >> Subject: [manet] SMF and intarea-ipv4-id-update >>=20 >> Sorry for x-posting. But there is a conflict in: >> http://tools.ietf.org/html/draft-ietf-manet-smf >> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update >>=20 >> SMF has a duplicate packet detection function based on the IPv4 >> ID field. So text in ietf-intarea-ipv4-id-update section 4 >> is not correct, in that there would be no deployments for such. >> That said, SMF deployment with IPv4 DPD on IP-ID would be limited. >>=20 >> What to do? >>=20 >> Teco >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From aaron@lo-res.org Thu Mar 31 00:42:02 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46B73A6B19 for ; Thu, 31 Mar 2011 00:42:02 -0700 (PDT) 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 AAJ4pj1Oj-hU for ; Thu, 31 Mar 2011 00:42:02 -0700 (PDT) Received: from mute.lo-res.org (mail.lo-res.org [IPv6:2a02:60:1:1::3]) by core3.amsl.com (Postfix) with ESMTP id C82E03A6B16 for ; Thu, 31 Mar 2011 00:42:01 -0700 (PDT) Received: from dhcp-1680.meeting.ietf.org (dhcp-1680.meeting.ietf.org [130.129.22.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mute.lo-res.org (Postfix) with ESMTPSA id A22BB9BC4B2 for ; Thu, 31 Mar 2011 09:43:38 +0200 (CEST) From: "L. Aaron Kaplan" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 09:43:36 +0200 Message-Id: <9269D450-0300-47A1-BF8E-84C45D8AED54@lo-res.org> To: IETF MANET Mime-Version: 1.0 (Apple Message framework v1084) X-Pgp-Agent: GPGMail 1.3.2 X-Mailer: Apple Mail (2.1084) Subject: [manet] IETF80 manet WG dinner/drinks? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 07:42:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I would like to meet up with some folks of the MANET WG for = dinner/drinks=20 tonight. I suggest we meet at 19:30 in the main lobby hall. Just talked to Thomas Clausen (who is back) and he will be joining for=20= some drinks later since he already arranged for dinner. (just have to make sure he will find the place). Would you be interested? a. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2UMKkACgkQxEgyMttZ8Yw2kgCfQWdb8r4LjmPBOHr9SbqNdvsl awIAn0bvP9J3yrlBQ7CKI+yajNdNEtBX =3D/bqP -----END PGP SIGNATURE-----