From mailman-bounces@ietf.org Fri Oct 1 05:31:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09868 for ; Fri, 1 Oct 2004 05:31:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDJtm-0002dD-OF for ospf-wireless-design-archive@ietf.org; Fri, 01 Oct 2004 05:40:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJJ2-000263-Q3 for ospf-wireless-design-archive@ietf.org; Fri, 01 Oct 2004 05:02:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ospf-wireless-design-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:00:52 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for ospf-wireless-design-archive@ietf.org: List Password // URL ---- -------- ospf-wireless-design@lists.ietf.org uxefev https://www1.ietf.org/mailman/options/ospf-wireless-design/ospf-wireless-design-archive%40ietf.org From ospf-wireless-design-bounces@ietf.org Tue Oct 5 11:44:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08778; Tue, 5 Oct 2004 11:44:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CErdT-0006S1-Mh; Tue, 05 Oct 2004 11:53:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CErPo-0002CN-9i; Tue, 05 Oct 2004 11:39:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CErOG-0001pW-Id for ospf-wireless-design@megatron.ietf.org; Tue, 05 Oct 2004 11:38:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08376 for ; Tue, 5 Oct 2004 11:38:09 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CErXZ-0006Ep-Ev for ospf-wireless-design@ietf.org; Tue, 05 Oct 2004 11:47:49 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 05 Oct 2004 11:56:11 -0400 X-BrightmailFiltered: true Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i95Fbcr5000236; Tue, 5 Oct 2004 11:37:39 -0400 (EDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.11.2/CISCO.WS.1.2) id i95Fbc812605; Tue, 5 Oct 2004 11:37:38 -0400 (EDT) Date: Tue, 5 Oct 2004 11:37:38 -0400 From: "Madhavi W. Chandra" To: "Spagnolo, Phillip A" Subject: Re: [Ospf-wireless-design] DT Direction... Message-ID: <20041005153738.GB12588@cisco.com> References: <3BFEACE361F5BF429DD1DA593E3A7C0904C69429@xch-nw-28.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BFEACE361F5BF429DD1DA593E3A7C0904C69429@xch-nw-28.nw.nos.boeing.com> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Hi Phillip, Sorry for the late response. It's great that you are implementing our draft! I consulted with our software engineer Pratap who implemented this portion of our design. Please see inline...much of this is feedback from Pratap. On Fri, Sep 24, 2004 at 12:54:20PM -0700, Spagnolo, Phillip A wrote: > Here are few comments on differential hellos from implementing Cisco's > draft. > > I would call the differential hellos a moderately hard piece. From my > experience, it is harder than optimized flooding. But, I wouldn't rule > it out do to implementation, after it is completed it can work well. My Yes, there are new components or terms added to the Hello process. Thus, it may look complicated. According to Pratap, "I don't think it really is as complicated as it sounds." In any case, this is subjective. As you say, it can work well...thus, let's look at the objective issues below. > biggest question about differential hellos is adding a non-periodic > component to the hello process. Not sure what you mean here... It is up to the implementation when a change is sent. For example, a change can trigger a Hello or you can send all the changes once at the end of the Hello-interval. Note that this is not like a route change where we need to worry about how fast we notify neighbors. > A few of the changes necessary (not inclusive): > -state machine (Differential hellos require a somewhat complicated state > machine and processing of the TLVs. You cannot process the hello > message in order of the TLVs, you must keep all TLVs in memory before > determining what should be done with the packet.) Actually, there is no real change to neighbor state machine. However, there is a new state machine added for hello processing. The logic can be simplified to something like this: - Receive Incremental Hello if SCS is same, ignore if SCS is SCS+1, if incomplete-bit is set, send request and ignore the hello if incomplete-bit not set, Process each TLV else Send request - Receive Hello with response bit set, Process all the TLVs When you receive a Hello, you have the whole Hello in the buffer pool memory...which is all you need to process TLVs. After OSPF processes the Hello, it gets rid of that memory. You don't need to save the TLVs into seperate memory before processing them. > -sequence # (Increment for any state change) If you are sending all changes within the Hello-interval, then you need to only increment the SCS once for all changes before sending the Hello. > -Active neighbors (only send in initial hello after new neighbor) > -Drop neighbors (require keeping history of dropped neighbors for 4 > *dead interval, clear drop neighbor if renewed) For this part, you need to maintain a separate list and a timer...for persistant sending. Note that with the introduction of the incomplete-bit, persistent sending of TLVs is flexible. Meaning, any TLV can be sent persistently using this bit if that TLV is deemed 'more' important (to avoid request/reply)...or sent only once...in which case you wouldn't need the separate list and timer. > -Relays added (similar to neighbors) > -Relay deleted (similar to neighbors) The relay list is saved in memory. Upon calculation of the relay set, the deltas are sent in the Hello (either immediately...or at the expiration of Hello-interval)....and the new relay list is saved. The details of what information must be saved in the 'interim' depends on when the Hello is sent (immediately or after Hello-interval). > -Partial state (must make checks of how many items in hello changed from > previous state and set flag if partial info) The incomplete-bit was added to provide flexibility in persistently sending information...and accuracy. It allows the receiver to be sure in identifying if anything changed from previous Hello, *without* having to save the previous Hello. For example, let's say we have SCS 10 for a neighbor and we then receive a Hello with SCS 11. The logic now is simple. If the bit is set, it means that this is persistent information...and the original SCS 11 was lost...so the receiver can request. If this bit is NOT set, it means that this is the original SCS 11 packet...so process it and save SCS 11 for the neighbor. Now, let's say that a Hello with SCS 11 with the incomplete bit set is received. The receiver knows that this is just persistent info...and it already has the info...so no processing needed. So, there is no need to see how many things changed from previous Hello. Hope this helps! Regards, Madhavi > -Graceful restart (has to be changed due to partial info) > > Phil > > > -----Original Message----- > > From: Henderson, Thomas R > > Sent: Friday, September 24, 2004 8:39 AM > > To: Spagnolo, Phillip A > > Subject: FW: [Ospf-wireless-design] DT Direction... > > > > > > can you comment on how easy/hard it was to implement the > > differential hello piece, and if hard, what was hard about > > it? > > > > -----Original Message----- > > From: Abhay Roy [mailto:akr@cisco.com] > > Sent: Thursday, September 23, 2004 11:53 PM > > To: Acee Lindem > > Cc: ospf-wireless-design@ietf.org > > Subject: Re: [Ospf-wireless-design] DT Direction... > > > > > > Acee, > > > > Yes I agree that flooding is where the biggest gains can be made. > > So of course we need to start from there. But the "every little > > bit helps" logic is very valid too ;) And in fact it has been > > brought up by some of the customers we are talking to. > > > > I also pointed earlier that we are proposing to overload Hello > > with (possibly) a lot of new information. So an attempt to > > condense this information using a seq# (incremental) approach > > seems appealing in theory. I would like to suggest that we wait to > > see some simulation/measurement numbers before ruling it out. > > > > Regards, > > -Roy- > > > > On 09/22/04-0400 at 6:17pm, Acee Lindem writes: > > > > > I believe everybody agrees that flooding needs to be > > optimised but is > > > it really a a forgone conclusion that we need to optimise hellos > > > and database exchange? I know that there was one vote for optimising > > > hello since "every little bit helps". However, as OSPF WG > > co-chair and > > > steward of the protocol, I see one of my main roles as > > questioning whether or > > > not the existing mechanisms need to be changed. > > > Also, if flooding is dominant and database exchange is a > > factor, why wouldn't > > > we want to focus on reducing the amount of information? I > > don't have a > > > proposal for this but I've wondered why nobody has > > > gone down this path. > > > Thanks, > > > Acee > > > ----- Original Message ----- From: "Madhavi W. Chandra" > > > > > To: > > > Sent: Wednesday, September 01, 2004 12:22 PM > > > Subject: [Ospf-wireless-design] DT Direction... > > > > > > > > >> Hi All, > > >> > > >> I put together a brief outline as a suggested direction > > for our Design > > >> Team. For credibility and effectiveness of the DT, I > > think we need to > > >> have focused direction and timelines. Basically, we > > shouldn't try to > > >> solve everything under the sun for OSPF-MANET...and we > > shouldn't drag > > >> this on to the point that know one will care...including > > us the DT! :) > > >> > > >> Please see attached. I also put in there the generic requirements > > >> that we (Cisco) have gotten from customers that lead to our design > > >> proposals. (Due to NDAs, I cannot share specifics.) > > >> > > >>> From what I understand, the problem statement is more an > > agreement, > > >> and not a formal draft. So, we should be able to reach that in a > > >> couple of weeks. > > >> > > >> Thanks! > > >> -Madhavi > > >> > > > > > > > > > > > -------------------------------------------------------------- > > ------------------ > > > > > > > > >> _______________________________________________ > > >> Ospf-wireless-design mailing list > > >> Ospf-wireless-design@lists.ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > > >> > > > > > > _______________________________________________ > > > Ospf-wireless-design mailing list > > > Ospf-wireless-design@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > > > > > > > _______________________________________________ > > Ospf-wireless-design mailing list > > Ospf-wireless-design@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > > > > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Thu Oct 7 12:03:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29892; Thu, 7 Oct 2004 12:03:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFatW-00065F-UI; Thu, 07 Oct 2004 12:13:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaOI-0004Sf-RT; Thu, 07 Oct 2004 11:41:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaFV-0002Al-Ni for ospf-wireless-design@megatron.ietf.org; Thu, 07 Oct 2004 11:32:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27145 for ; Thu, 7 Oct 2004 11:32:06 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFaP4-0004Ar-Na for ospf-wireless-design@ietf.org; Thu, 07 Oct 2004 11:42:13 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA13097 for ; Thu, 7 Oct 2004 08:31:27 -0700 (PDT) Received: from xch-nw-23p.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i97FVQD23055 for ; Thu, 7 Oct 2004 08:31:26 -0700 (PDT) Received: from XCH-NW-28.nw.nos.boeing.com ([192.48.4.102]) by xch-nw-23p.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Oct 2004 08:30:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ospf-wireless-design] DT Direction... Date: Thu, 7 Oct 2004 08:30:49 -0700 Message-ID: <3BFEACE361F5BF429DD1DA593E3A7C0904C6942C@xch-nw-28.nw.nos.boeing.com> Thread-Topic: [Ospf-wireless-design] DT Direction... Thread-Index: AcSq8UFsfiR7S1W8SueWYvgsIcP1QwAA7GtQ From: "Spagnolo, Phillip A" To: X-OriginalArrivalTime: 07 Oct 2004 15:30:50.0069 (UTC) FILETIME=[9FD83850:01C4AC82] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable Hi Madhavi, Thanks for your response, and thanks for talking with Pratap. My e-mail was designed to give some insight into how hard/easy the differential hello piece was to implement. I agree that the difficulty in implementing differential hellos is subjective and I don't claim to be an expert implementer. However, the complexity of differential hellos is definitely greater than the current hello scheme. But once again, I don't propose that complexity in this case is a reason to discard differential hellos. Here is a response to your comments: My comment that a non-periodic component is added to the hello process comes in two parts. First, you are now sending additional "unicast hellos" in the form of requests. A unicast request cannot be used to say hello to everyone. Second, answers MAY be sent immediately per implementers choice. I didn't mean a change is made to the neighbor state machine. I meant the state machine for processing a differential hello has many case. I will expand on your state machine below. The basic concept is easy the details give you more cases. - Receive Hello if L-bit and I-bit are set process diff hello if new neighbor in neighbor list add new neighbor Process TLVs if R-bit set in SCS TLV send unicast answer if SCS is same if neigh state >=3D 2-way refresh neigh expiration timer if relay selector for neighbor refresh mpr expiration timer else if A-bit set in SCS TLV if self contained in drop neighbor TLV do nothing - return set neighbor SCS number equal to value in SCS TLV if (self contained in neighbor list) refresh neigh expiration timer if self in relay selector TLV add to mpr list else if neighbor in relay selector list remove mpr from selector list =20 else if neigh state >=3D 2way=20 if SCS is SCS+1, if incomplete-bit is set send unicast request - return else if hello neighbor list size > 0 increment neighbor scs //drop TLV processing if self in drop neighbor TLV move neighbor to state one-way else if self not in drop neighbor TLV=20 increment neighbor SCS //relay selector TLV processing if relay selector TLV not empty increment neighbor SCS if self dropped in mpr list remove mpr from selector list else if self added in mpr list add to mpr list else if neighbor already a selector refresh mpr expiration timer else if neighbor already a selector refresh mpr expiration timer //process other TLVs if neighbor scs not incremented send unicast request else Send unicast request >=20 > When you receive a Hello, you have the whole Hello in the buffer pool=20 > memory...which is all you need to process TLVs. > After OSPF processes the Hello, it gets rid of that memory. =20 > You don't need to save the TLVs into separate memory before=20 > processing them. >=20 > > -sequence # (Increment for any state change) >=20 > If you are sending all changes within the Hello-interval, then you=20 > need to only increment the SCS once for all changes before sending the > Hello. I agree, that is what I meant. Sorry for my unclear statement. > > -Active neighbors (only send in initial hello after new neighbor)=20 > > -Drop neighbors (require keeping history of dropped neighbors for 4=20 > > *dead interval, clear drop neighbor if renewed) >=20 > For this part, you need to maintain a separate list and a timer...for=20 > persistent sending. Note that with the introduction of the=20 > incomplete-bit, persistent sending of TLVs is flexible. Meaning, any=20 > TLV can be sent persistently using this bit if that TLV is deemed=20 > 'more' important (to avoid request/reply)...or sent only once...in=20 > which case you wouldn't need the separate list and timer. I again agree. So does that mean section 2.3.4.2 bullet 4 is a MAY send hello for RouterDeadInterval? >=20 > > -Relays added (similar to neighbors) > > -Relay deleted (similar to neighbors) >=20 > The relay list is saved in memory. Upon calculation of the relay set, > the deltas are sent in the Hello (either immediately...or at the=20 > expiration of Hello-interval)....and the new relay list is saved. The > details of what information must be saved in the 'interim' depends on=20 > when the Hello is sent (immediately or after Hello-interval). >=20 Does this mean you MAY send a hello every time you change a relay? I would again say this leads to aperiodic hellos. > > -Partial state (must make checks of how many items in hello changed=20 > > from previous state and set flag if partial info) >=20 > The incomplete-bit was added to provide flexibility in persistently=20 > sending information...and accuracy. It allows the receiver to be sure > in identifying if anything changed from previous Hello, *without*=20 > having to save the previous Hello. >=20 > For example, let's say we have SCS 10 for a neighbor and we then=20 > receive a Hello with SCS 11. The logic now is simple. > If the bit is set, it means that this is persistent=20 > information...and the original SCS 11 was lost...so the=20 > receiver can request. If this bit is NOT set, it means that=20 > this is the original SCS 11 packet...so process it and save=20 > SCS 11 for the neighbor. Now, let's say that a Hello with=20 > SCS 11 with the incomplete bit set is received. The receiver=20 > knows that this is just persistent info...and it already has=20 > the info...so no processing needed. So, there is no need to=20 > see how many things changed from previous Hello. >=20 I understand the goal of having the N-bit, and it seems useful for this case. I was simply saying that the sender must determine if the hello it sends contains partial or full state change. =20 Thanks, Phil _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Thu Oct 14 08:40:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09598; Thu, 14 Oct 2004 08:40:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI55S-00011l-1f; Thu, 14 Oct 2004 08:52:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI4pE-0002ko-B6; Thu, 14 Oct 2004 08:35:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlGN-0006oX-4g for ospf-wireless-design@megatron.ietf.org; Wed, 13 Oct 2004 11:42:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09140 for ; Wed, 13 Oct 2004 11:42:02 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlRH-0007fY-Df for ospf-wireless-design@ietf.org; Wed, 13 Oct 2004 11:53:23 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA16046 for ; Wed, 13 Oct 2004 10:41:24 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9DFfN303353 for ; Wed, 13 Oct 2004 10:41:23 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Oct 2004 08:41:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4B13B.136593E4" Date: Wed, 13 Oct 2004 08:41:15 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0452271F@xch-nw-27.nw.nos.boeing.com> X-MS-Has-Attach: yes Thread-Topic: new material to review and discuss Thread-Index: AcSxOxNkoFqfACi9SieBx/pjtk60kA== From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 13 Oct 2004 15:41:16.0603 (UTC) FILETIME=[13C438B0:01C4B13B] X-Spam-Score: 0.0 (/) X-Scan-Signature: fc33afc280b74ce7916a8c9e6ab57db8 X-Mailman-Approved-At: Thu, 14 Oct 2004 08:35:19 -0400 Subject: [Ospf-wireless-design] new material to review and discuss X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 72be645574b2b4b84446d27f730bf563 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B13B.136593E4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, I have attached a revised version of the wireless design team document. I am trying to use this to document agreements and discussion points raised in the drafts and the mailing lists. In particular, I have added a section 1.2 that lists the items that the group agrees upon. Can people please review this section and see whether there is any objection to removing the "pending" status to any of these topics? (I will interpret silence on the list as acquiescence). If we can move past those items, the next topic I would like to focus on is the flooding discussion-- in particular, the issue of MPR vs. CDS that has never been resolved adequately in my opinion. Please read Section 3.2 carefully, as it has been substantially rewritten, and let the list know of your agreements and disagreements to what is written there. Thanks, Tom ------_=_NextPart_001_01C4B13B.136593E4 Content-Type: text/plain; name="wospf-summary.txt" Content-Description: wospf-summary.txt Content-Disposition: attachment; filename="wospf-summary.txt" Content-Transfer-Encoding: base64 CgpPU1BGIFdvcmtpbmcgR3JvdXBzIERlc2lnbiBUZWFtICAgICAgICAgICAgICAgICAgICAgICBU LiBIZW5kZXJzb24gKGVkLikKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEJvZWluZyBQaGFudG9tIFdvcmtzCkV4cGlyZXM6IEFwcmlsIDEzLCAyMDA1 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAxMywgMjAwNAoKCgogICAg ICAgICAgICAgICAgICBkcmFmdC1tYW5ldC1vc3BmLWRlc2lnbi10ZWFtLTAwLXByZTIKClN0YXR1 cyBvZiB0aGlzIE1lbW8KCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5k IGlzIHN1YmplY3QgdG8gYWxsIHByb3Zpc2lvbnMKICAgb2Ygc2VjdGlvbiAzIG9mIFJGQyAzNjY3 LiAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoCiAgIGF1dGhvciByZXBy ZXNlbnRzIHRoYXQgYW55IGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2YK ICAgd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3Nl ZCwgYW5kIGFueSBvZgogICB3aGljaCBoZSBvciBzaGUgYmVjb21lIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGgKICAgUkZDIDM2NjguCgogICBJbnRlcm5ldC1EcmFm dHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBU YXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90 ZSB0aGF0CiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1l bnRzIGFzCiAgIEludGVybmV0LURyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQg ZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJl IHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFu eQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFz IHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29y ayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBj YW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFj dHMudHh0LgoKICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVz IGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoK ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBBcHJpbCAxMywgMjAwNS4KCkNv cHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIw MDQpLgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gYXR0ZW1wdCB0byBvcmdhbml6 ZSBhbmQgc3VtbWFyaXplIHRoZSBPU1BGIFdHCiAgIGRlc2lnbiB0ZWFtIGFjdGl2aXRpZXMsIGJ5 IGZpcnN0IHN0YXRpbmcgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZAogICBzY2hlZHVsZSBvZiBh Y3Rpdml0aWVzLCBhbmQgdGhlbiBzdW1tYXJpemluZyBwcm9wb3NlZCBtb2RpZmljYXRpb25zLgog ICBJdCBpcyBpbnRlbmRlZCB0byBiZSBhIGxpdmluZyBkb2N1bWVudCB0aGF0IGV2b2x2ZXMgdG8g Y2FwdHVyZSB0aGUKICAgZGVzaWduIHRlYW0gZGlzY3Vzc2lvbnMgYW5kIGRlY2lzaW9ucy4KCiAg IFRoaXMgZG9jdW1lbnQgc3VtbWFyaXplcyBwcm9wb3NhbHMgYW5kIGRpc2N1c3Npb24gY2FwdHVy ZWQgaW4gWzFdLAogICBbMl0sIFszXSwgWzRdLCBbNV0sIFs2XSwgWzddLCBbOF0sIHRoZSBkZXNp Z24gdGVhbSBlbWFpbCBwb3N0cywgYW5kCgoKCkhlbmRlcnNvbiAoZWQuKSAgICAgICAgICBFeHBp cmVzIEFwcmlsIDEzLCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURy YWZ0ICAgICAgU3VtbWFyeSBvZiBNQU5FVCBPU1BGIFByb3Bvc2FscyAgICAgICAgIE9jdG9iZXIg MjAwNAoKCiAgIG9sZGVyIE1BTkVUIGFuZCBPU1BGIG1haWxpbmcgbGlzdCBwb3N0cy4KClRhYmxl IG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgICAxLjEgICBQcm9ibGVtIFN0YXRlbWVu dCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgICAgMS4yICAg QWdyZWVtZW50cyBSZWFjaGVkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMwogICAyLiAgU2NoZWR1bGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgMy4gIFByb3Bvc2VkIE1vZGlmaWNhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMy4xICAgU2NvcGUgb2Yg TUFORVQgZXh0ZW5zaW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAg IDMuMiAgIFRvcG9sb2d5IGRpc3NlbWluYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDYKICAgICAgIDMuMi4xICAgRGlzY3Vzc2lvbiBvZiBSTlMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgICAzLjIuMiAgIERpc2N1c3Npb24gb2Yg cmVsaWFiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgIDMuMyAgIE5l aWdoYm9yIGRpc2NvdmVyeSBhbmQgc3luY2hyb25pemF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTIKICAgICAzLjQgICBPdGhlciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEzCiAgIDQuICBBY2tub3dsZWRnbWVudHMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICA1LiAgUmVmZXJlbmNlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgICAg IEF1dGhvcidzIEFkZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDE3CiAgICAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0 ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAxOAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CkhlbmRlcnNvbiAoZWQuKSAgICAgICAgICBFeHBpcmVzIEFwcmlsIDEzLCAyMDA1ICAgICAgICAg ICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgU3VtbWFyeSBvZiBNQU5FVCBP U1BGIFByb3Bvc2FscyAgICAgICAgIE9jdG9iZXIgMjAwNAoKCjEuICBJbnRyb2R1Y3Rpb24KCjEu MSAgUHJvYmxlbSBTdGF0ZW1lbnQKCiAgIChOb3RlOiB0aGlzIGlzIGFuIGluLXByb2dyZXNzIHZl cnNpb24sICBlZGl0ZWQgYmFzZWQgb24gbWFpbGluZyBsaXN0CiAgIGRpc2N1c3Npb25zIGJ1dCBz dGlsbCBzdWJqZWN0IHRvIGNoYW5nZSkKCiAgIFRoZSBjaGFydGVyIG9mIHRoZSBkZXNpZ24gdGVh bSB3aWxsIGJlIHRvIHNlbGVjdCB0aGUgaW5pdGlhbCBzZXQgb2YKICAgT1NQRnYzIGV4dGVuc2lv bnMgaW4gc3VwcG9ydCBvZiB3aXJlbGVzcyAob3IgTUFORVQpIG5ldHdvcmtzIGFuZAogICBkb2N1 bWVudCB0aGVzZSBpbiBvbmUgb3IgbW9yZSBJbnRlcm5ldCBEcmFmdHMuICBUaGUgZXh0ZW5zaW9u cyB3aWxsCiAgIGJlY29tZSBXRyBkb2N1bWVudHMgYW5kIHdpbGwgYmUgcmV2aWV3ZWQgYnkgdGhl IE9TUEYgYW5kIE1BTkVUIFdHcy4KICAgVGhlIGluaXRpYWwgZW52aXJvbm1lbnQgd2lsbCBiZSB2 aWV3ZWQgYXM6CgogICAgICAgIDEpIERlc2lnbiB0ZWFtIHdpbGwgZm9jdXMgb24gT1NQRnYzIGFu ZCBub3QgT1NQRnYyLgogICAgICAgIDIpIENvbXBhdGliaWxpdHkgd2l0aCBub24td2lyZWxlc3Mg T1NQRnYzIGltcGxlbWVudGF0aW9ucyBtdXN0IGJlCiAgICAgICAgICAgbWFpbnRhaW5lZC4KICAg ICAgICAzKSBPbmx5IEludHJhLWFyZWEgZW52aXJvbm1lbnRzIHdpbGwgYmUgY29uc2lkZXJlZCBp biB0aGUgaW5pdGlhbCBzZXQKICAgICAgICAgICBvZiBleHRlbnNpb25zLgogICAgICAgIDQpIE1B TkVUIHdpcmVsZXNzIGVudmlyb25tZW50cyB3aWxsIG5vdCBub3JtYWxseSBiZSBhIHRyYW5zaXQg Zm9yCiAgICAgICAgICAgd2lyZWxpbmUgbmV0d29ya3MgYnV0IHRoaXMgc2hvdWxkbid0IGJlIHBy ZWNsdWRlZC4KICAgICAgICA1KSBUaGUgc2NhbGluZyBnb2FsIGZvciB0aGUgbnVtYmVyIG9mIG5v ZGVzIG9uIHRoZSB3aXJlbGVzcyBjaGFubmVsCiAgICAgICAgICAgaXMgb24gdGhlIG9yZGVyIG9m IDUwIHRvIDEwMCBub2RlcywgYWx0aG91Z2ggYSBsYXJnZXIgbnVtYmVyIG9mCiAgICAgICAgICAg bm9kZXMgbWlnaHQgYWxzbyBiZSBzdXBwb3J0YWJsZS4KICAgICAgICA2KSBXaGVuIHBvc3NpYmxl LCBtZWNoYW5pc21zIGZyb20gZXhpc3RpbmcgTUFORVQgcHJvdG9jb2xzIHNob3VsZCBiZQogICAg ICAgICAgIGxldmVyYWdlZC4KICAgICAgICA3KSBUaGUgZGVzaWduIHRlYW0gd2lsbCB1c2UgUkZD IDM2NjggZ3VpZGFuY2UgZm9yIGRlYWxpbmcgd2l0aCBJUFIKICAgICAgICAgICBjbGFpbXMuCgog ICBUaGUgc2ltdWxhdGlvbi9wZXJmb3JtYW5jZSB3b3JrIGluIGFuZCBvZiBpdHNlbGYgaXMgbm90 IGEgZ29hbCBvZiB0aGUKICAgZGVzaWduIHRlYW0gZXhjZXB0IGluIHRoZSBjb250ZXh0IG9mIGV2 YWx1YXRpb24gb2YgT1NQRnYzIGV4dGVuc2lvbnMuCgoxLjIgIEFncmVlbWVudHMgUmVhY2hlZAoK ICAgMS4gIERlc2lnbiB0ZWFtIGZvY3VzZXMgb24gYWNrbm93bGVkZ2VkIChyZWxpYWJsZSkgZmxv b2RpbmcsIGxlYXZpbmcKICAgICAgIHBlcmlvZGljIGZsb29kaW5nIGFzIGEgZnV0dXJlIG9wdGlt aXphdGlvbi4KICAgMi4gIChwZW5kaW5nIGRlc2lnbiB0ZWFtIGNvbnNlbnN1cykgRGVzaWduIHRl YW0gYWRvcHRzIHByb2JsZW0KICAgICAgIHN0YXRlbWVudCBpbiBTZWN0aW9uIDEuMS4KICAgMy4g IChwZW5kaW5nIGRlc2lnbiB0ZWFtIGNvbnNlbnN1cykgRGVzaWduIHRlYW0gZm9jdXNlcyBvbiBk ZWZpbmluZyBhCiAgICAgICBNQU5FVCBpbnRlcmZhY2UgdHlwZSwgbm90IGEgTUFORVQgYXJlYSB0 eXBlLiAgKE5vdGU6ICBUaGlzCiAgICAgICBhc3N1bXB0aW9uIHdhcyBjaGFsbGVuZ2VkIGJ5IFRv bnkgUHJ6eWdpZW5kYSBiYWNrIGluIEphbnVhcnkpCiAgIDQuICAocGVuZGluZyBkZXNpZ24gdGVh bSBjb25zZW5zdXMpIERlc2lnbiB0ZWFtIGZvY3VzZXMgZmlyc3Qgb24KICAgICAgIGRlZmluaW5n IGFuIG9wdGltaXplZCBmbG9vZGluZyBtZWNoYW5pc20gZm9yIExTQSBkaXNzZW1pbmF0aW9uLgoK CgoKCgoKCgpIZW5kZXJzb24gKGVkLikgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxMywgMjAwNSAg ICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgIFN1bW1hcnkgb2Yg TUFORVQgT1NQRiBQcm9wb3NhbHMgICAgICAgICBPY3RvYmVyIDIwMDQKCgoyLiAgU2NoZWR1bGUK CiAgIFRoZSBmb2xsb3dpbmcgc2NoZWR1bGUgaGFzIGJlZW4gcHJvcG9zZWQgYnkgTWFkaGF2aSBD aGFuZHJhLCB3aXRoCiAgIHN1Z2dlc3RlZCBtb2RpZmljYXRpb25zICh0byB0aGUgbGlzdCBvZiBQ aGFzZSBJIGFzc3VtcHRpb25zKSBieSBUb20KICAgSGVuZGVyc29uLiAgQWNlZSBMaW5kZW0gZXhw cmVzc2VkIHRvIHRoZSBsaXN0IHRoYXQgaGUgaGFzIG5vdCB5ZXQKICAgYmVlbiBjb252aW5jZWQg YWJvdXQgdGhlIG5lZWQgdG8gb3B0aW1pemUgaGVsbG9zIGFuZCBkYXRhYmFzZQogICBleGNoYW5n ZXMuCgogICBQaGFzZSBJIG9mIE9TUEYtTUFORVQgRGVzaWduIFRlYW0KCiAgIEFzc3VtcHRpb25z IGZvciBQaGFzZSBJOgogICBvIHNpbmdsZSBmbGF0IGFyZWEKICAgbyBnb2FsIGlzIHRvIHJlZHVj ZSBvdmVyaGVhZAogICBvIE1BTkVUIHdpcmVsZXNzIGNoYW5uZWwgaXMgY29uc2lkZXJlZCB0byBi ZSBhIHNwZWNpYWwKICAgICBsaW5rIHR5cGUsIGluIHBhcmFsbGVsIHdpdGggZXhpc3RpbmcgZml2 ZSBPU1BGIGxpbmsgdHlwZXMKICAgbyByYWRpbyB0cmFuc21pc3Npb25zIGFyZSBicm9hZGNhc3Qg YW5kIG1heSBvciBtYXkgbm90CiAgIHJlYWNoIGFsbCBub2RlcyBvbiB0aGUgbGluawoKCiAgIFJl cXVpcmVtZW50cyBiYXNlZCBvbiBjdXN0b21lciBmZWVkYmFjazoKICAgLSBEZWZpbmUgV2lyZWxl c3MgaW50ZXJmYWNlCiAgIC0gT3B0aW1pemUgUmVsaWFibGUgRmxvb2RpbmcgbWVjaGFuaXNtCiAg IC0gUmVkdWNlIG92ZXJoZWFkCiAgICAgLSBIZWxsbyBwcm9jZXNzCiAgICAgLSBEYXRhYmFzZSBl eGNoYW5nZSBwcm9jZXNzCgogICBUaW1lbGluZToKICAgRm9yIGNyZWRpYmlsaXR5IG9mIERUIGFu ZCByZWFsaXN0aWMgYWRvcHRtZW50LCB3ZSBzaG91bGQgaGF2ZSBhCiAgIGZvY3VzZWQgcHJvYmxl bSBzdGF0ZW1lbnQgYW5kIG1pbGVzdG9uZSBkZWxpdmVyYWJsZXMuICBJIHdpbGwKICAgc3VnZ2Vz dCB0aGUgZm9sbG93aW5nOgoKICAgKiBQcm9ibGVtIHN0YXRlbWVudCBjb25zZW5zdXMgYnkgU2Vw dC4gMTUKICAgKiBEZXNpZ24gV2lyZWxlc3MgSW50ZXJmYWNlIHNjb3BlIGJ5IE9jdCAxNQogICAq IERlc2lnbiBvZiBGbG9vZGluZyBtZWNoYW5pc20gYnkgRGVjIDEKICAgKiBEZXNpZ24gdG8gT3B0 aW1pemUgSGVsbG8gcHJvY2VzcyBieSBKYW4gMTUKICAgKiBEZXNpZ24gdG8gT3B0aW1pemUgRGF0 YWJhc2UgRXhjaGFuZ2UgYnkgRmViIDE1CiAgICogRHJhZnQgc3VibWlzc2lvbiB0byBXRyBieSBN YXJjaCBJRVRGCgogICBQb3NzaWJpbGl0ZXMgZm9yIFBoYXNlIElJIG9mIERlc2lnbiBUZWFtOgog ICAtIENsdXN0ZXJpbmcgbWVjaGFuaXNtIGZvciBzY2FsYWJpbGl0eQogICAtIFVucmVsaWFibGUg Rmxvb2RpbmcgbWVjaGFuaXNtCiAgIC0gTXVsdGlwbGUgYXJlYXMKCgoKCgoKCgoKSGVuZGVyc29u IChlZC4pICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTMsIDIwMDUgICAgICAgICAgICAgICAgIFtQ YWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBTdW1tYXJ5IG9mIE1BTkVUIE9TUEYgUHJvcG9z YWxzICAgICAgICAgT2N0b2JlciAyMDA0CgoKMy4gIFByb3Bvc2VkIE1vZGlmaWNhdGlvbnMKCiAg IEZvciBpbml0aWFsIGNhdGVnb3JpemF0aW9uLCB3ZSBjYW4gZ3JvdXAgcHJvcG9zZWQgbW9kaWZp Y2F0aW9ucyBhdCBhCiAgIGhpZ2ggbGV2ZWwgYXMgZm9sbG93czoKICAgYS4gIFNjb3BlIG9mIE1B TkVUIGV4dGVuc2lvbnMKICAgYi4gIFRvcG9sb2d5IGRpc3NlbWluYXRpb24KICAgYy4gIE5laWdo Ym9yIGRpc2NvdmVyeSBhbmQgc3luY2hyb25pemF0aW9uCiAgIGQuICBPdGhlcgoKMy4xICBTY29w ZSBvZiBNQU5FVCBleHRlbnNpb25zCgogICBUbyBzdGFydCB3aXRoIGEgcmVxdWlyZW1lbnQgdGhh dCBzZWVtcyBub24tY29udGVudGlvdXMsIGFueQogICBNQU5FVC1zcGVjaWZpYyBpbmZvcm1hdGlv biBzaG91bGQgZWl0aGVyIGJlIGNvbmZpbmVkIHRvIHRoZSBNQU5FVCBvcgogICBlbHNlIGJlIGV4 cG9zZWQgdG8gdGhlIHJlc3Qgb2YgdGhlIE9TUEYgbmV0d29yayBpbiBzdWNoIGEgbWFubmVyIHRo YXQKICAgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyBwcmVzZXJ2ZWQuCgogICBBbGwgb2YgdGhl IHByb3Bvc2FscyB0aGF0IGhhdmUgYmVlbiBzdWJtaXR0ZWQgYXMgaW50ZXJuZXQgZHJhZnRzIGhh dmUKICAgc3VnZ2VzdGVkIHRoYXQgdGhlIE1BTkVUIGV4dGVuc2lvbnMgYmUgZGVzaWduZWQgYXMg YSBuZXcgaW50ZXJmYWNlCiAgIHR5cGUsIGFuYWxvZ291cyB0byBQb2ludC10by1NdWx0aXBvaW50 IGludGVyZmFjZSB0eXBlLiAgU2VwYXJhdGVseSwKICAgVG9ueSBQcnp5Z2llbmRhIGhhcyByYWlz ZWQgb24gdGhlIGRlc2lnbiB0ZWFtIG1haWxpbmcgbGlzdCB0aGUgaWRlYQogICB0aGF0IHRoZSBN QU5FVCBleHRlbnNpb25zIGJlIGRlZmluZWQgYXMgYSBuZXcgYXJlYSB0eXBlLCBhbmFsb2dvdXMg dG8KICAgbnNzYS1hcmVhLCBiZWNhdXNlIHdlIGFyZSB0YWxraW5nIGFib3V0IGNoYW5naW5nIHRo ZSBmbG9vZGluZyBjb2RlLAogICBhbmQgdGhhdCBhbGwgaW50ZXJmYWNlIHR5cGVzIHR5cGljYWxs eSBzaGFyZSB0aGUgc2FtZSBmbG9vZGluZyBjb2RlLgoKICAgT25lIGFkZGl0aW9uYWwgY29uc2lk ZXJhdGlvbiBvZiB3aGV0aGVyIHRvIGlzb2xhdGUgTUFORVQgbmV0d29ya3MKICAgd2l0aCBhbiBh cmVhIGJvdW5kYXJ5IGlzIHRoZSBiZW5lZml0IG9mIHN1bW1hcml6aW5nIHRoZSBNQU5FVAogICBw cmVmaXhlcyBzdWNoIHRoYXQgcmFwaWRseSBjaGFuZ2luZyBMU0FzIGFyZSBub3QgZmxvb2RlZCB0 aHJvdWdob3V0CiAgIHRoZSBhcmVhIGZsb29kaW5nIGRvbWFpbiBkdWUgdG8gYSB2b2xhdGlsZSBN QU5FVCBwb3J0aW9uIG9mIHRoYXQKICAgZG9tYWluLiAgRGVmaW5pbmcgdGhlIE1BTkVUIGV4dGVu c2lvbnMgYXMgYW4gYXJlYSB0eXBlIGNhbiBvYnZpYXRlCiAgIHRoZSBjb25jZXJuIGZvciB0aGlz IHByb2JsZW0sIGJ1dCByZXF1aXJlcyB0aGF0IHN1bW1hcml6YXRpb24gYmUKICAgaW1wbGVtZW50 ZWQgb24gdGhlIE1BTkVUIGJvcmRlciByb3V0ZXJzLiAgQnkgdXNpbmcgYW4gaW50ZXJmYWNlIHR5 cGUsCiAgIHRoZSBkZXNpZ24gaXMgbm90IGNvbnN0cmFpbmVkIHRvIHVzZSBhcmVhIHN1bW1hcml6 YXRpb24sIGJ1dCBtYXkKICAgc3RpbGwgb3B0aW9uYWxseSBkZWZpbmUgYXJlYSBib3VuZGFyaWVz IGlmIG5lZWRlZC4gIFNlY3Rpb24gMi44IG9mCiAgIFsyXSBtZW50aW9ucyB0aGF0IG5ldyBzdW1t YXJpemF0aW9uIHRlY2huaXF1ZXMgZm9yIE1BTkVUIG1heSBiZQogICBkZXNpcmFibGUgaW4gdGhl IGZ1dHVyZS4gIFdlcmUgdGhlIGV4dGVuc2lvbnMgdG8gYmUgYXJlYS1iYXNlZCwgd2UKICAgd291 bGQgaGF2ZSB0byBjb25zaWRlciB0aGUgcG9zc2libGUgY29uc3RyYWludHMgb2YgcmVxdWlyaW5n IGFyZWEKICAgY29uZmlndXJhdGlvbnMgYW5kIGNvbm5lY3Rpb25zIHRvIHRoZSBiYWNrYm9uZS4K CiAgIElmIHRoZSBNQU5FVCBleHRlbnNpb25zIGZvcm0gYSBuZXcgaW50ZXJmYWNlIHR5cGUsIHRo ZW4gdGhlcmUgYXJlIGEKICAgbnVtYmVyIG9mIG1lY2hhbmlzbXMgdGhhdCBoYXZlIGJlZW4gcHJv cG9zZWQgdG8gbGltaXQgdGhlIGZsb29kaW5nCiAgIHNjb3BlIG9mIE1BTkVULXNwZWNpZmljIGlu Zm9ybWF0aW9uLiAgSW4gWzNdLCB3aGljaCB3YXMgaW1wbGVtZW50ZWQKICAgZm9yIElQdjQsIG5l dyBtZXNzYWdlIHR5cGVzIChXaXJlbGVzcyBIZWxsbyBhbmQgTGluayBTdGF0ZSBGbG9vZAogICBw YWNrZXRzKSB3ZXJlIG9ubHkgZ2VuZXJhdGVkIG9yIGNvbnN1bWVkIG9uIHRoZSBNQU5FVCBpbnRl cmZhY2UuCiAgIExpbmsgU3RhdGUgRmxvb2QgcGFja2V0cyBpbiBmYWN0IGhhZCBhIGRpZmZlcmVu dCBmbG9vZGluZyBzY29wZQogICAoc3VibmV0d29yaykgdGhhbiB0eXBpY2FsbHkgZm91bmQgZm9y IE9TUEZ2MyAobGluaywgYXJlYSwgQVMpLAogICBhbHRob3VnaCB0aGUgZW1iZWRkZWQgUG9pbnQt dG8tTXVsdGlwb2ludCBMU0FzIGhhZCBhcmVhIHNjb3BlIGFzCiAgIHVzdWFsLiAgKGluIG90aGVy IHdvcmRzLCBpZiBuZWlnaGJvciByZWxhdGlvbnNoaXBzIGFyZSB0cmVhdGVkIGFzCiAgIHBvaW50 LXRvLXBvaW50IGxpbmtzLCB0aGVyZSBpcyBubyB3YXkgdG8gaW5kaWNhdGUgYSAic3VibmV0LXNj b3BlIgoKCgpIZW5kZXJzb24gKGVkLikgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxMywgMjAwNSAg ICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFN1bW1hcnkgb2Yg TUFORVQgT1NQRiBQcm9wb3NhbHMgICAgICAgICBPY3RvYmVyIDIwMDQKCgogICBmbG9vZGluZyB3 aXRoIHRoZSBwcmVzZW50bHkgZGVmaW5lZCBTMSBhbmQgUzIgYml0cyBpbiBPU1BGdjMgTFMgVHlw ZQogICBmaWVsZHMpLiAgSW4gWzRdLCBMaW5rIExvY2FsIFNpZ25hbGxpbmcgKExMUykgZXh0ZW5z aW9ucyBhcmUgdXNlZCB0bwogICBsaW1pdCB0aGUgc2NvcGUgb2YgTUFORVQtc3BlY2lmaWMgaW5m b3JtYXRpb24uCgogICBJbiBbNF0sIGl0IGlzIGFsc28gc3RhdGVkIHRoYXQgYW4gQVBJIG11c3Qg YmUgcHJvdmlkZWQgdG8gbGF5ZXItMyB0bwogICBkZXRlcm1pbmUgdGhlIGxheWVyLTIgYnJvYWRj YXN0IGNhcGFiaWxpdHkgKGVpdGhlciBNQU5FVCBicm9hZGNhc3QsCiAgIE1BTkVUIHBzZXVkby1i cm9hZGNhc3QsIGFuZCBNQU5FVCBub24tYnJvYWRjYXN0KSwgYW5kIHRoZSBvcGVyYXRpb24KICAg b2YgdGhlIGludGVyZmFjZSBpcyBzbGlnaHRseSBhZGFwdGVkIHRvIGZpdCB0aGVzZSBjYXRlZ29y aWVzLgoKICAgSW4gWzRdLCBTZWN0aW9uIDIuNC4xMCwgaXQgaXMgc3VnZ2VzdGVkIHRoYXQgdGhl IG9wdGltaXplZCBmbG9vZGluZwogICBtaWdodCBnZW5lcmFsaXplIGFuZCBiZSBvZiBiZW5lZml0 IHRvIGFsbCBpbnRlcmZhY2VzIGluIGEgZmxvb2RpbmcKICAgZG9tYWluLCBub3QganVzdCBNQU5F VCBpbnRlcmZhY2VzLiAgVGhlcmUgd2FzIGFsc28gYW4gaW50ZXJuZXQgZHJhZnQKICAgYnkgQ2hv dWRodXJ5IGFuZCBNYW5yYWwgaW4gMjAwMiB0aGF0IGNvbnNpZGVyZWQgdGhlIGJlbmVmaXQgb2Yg TVBScwogICBpbiB3aXJlZCBuZXR3b3JrcyB0byByZWR1Y2UgbGFyZ2UgTFNBIHN0b3JtcyBkdWUg dG8gZmliZXIgY3V0cy4KCjMuMiAgVG9wb2xvZ3kgZGlzc2VtaW5hdGlvbgoKICAgQSBmdW5kYW1l bnRhbCBvcGVyYXRpb24gb2YgT1NQRiwgZGlzc2VtaW5hdGlvbiBvZiBjaGFuZ2VkIExTQXMKICAg dGhyb3VnaG91dCB0aGUgZmxvb2RpbmcgZG9tYWluLCB3YXMgc2hvd24gaW4gWzddIHRvIGJlIHRo ZSBtYWpvcgogICBjb250cmlidXRvciB0byBvdmVyaGVhZCBpbiB0aGUgTUFORVQgc2NlbmFyaW9z IGNvbnNpZGVyZWQgdGhlcmVpbi4KICAgVGhpcyBvdmVyaGVhZCBoYXMgYWxzbyBiZWVuIG9ic2Vy dmVkIGluIHByYWN0aWNlIHdoZW4gdXNpbmcgT1NQRiBpbgogICB3aXJlbGVzcyBuZXR3b3JraW5n IGV4cGVyaW1lbnRzLiAgRm9sbG93aW5nIHRoZSBkaXNjdXNzaW9uIGluIFs1XSwKICAgb25lIHdh eSB0byBicmVhayBkb3duIHRoZSBwcm9ibGVtIG9mIHRvcG9sb2d5IGRpc3NlbWluYXRpb24gaXMg dG8KICAgYS4gIGRlZmluZSB0aGUgc2V0IG9mIHJlbGF5IG5vZGVzIHVzZWQgZm9yIGZsb29kaW5n IExTQXMKICAgYi4gIGRlZmluZSB0aGUgc2V0IG9mIExTQXMgdGhhdCBlYWNoIG5vZGUgaXMgcmVz cG9uc2libGUgZm9yCiAgICAgICByZWxheWluZywgYW5kCiAgIGMuICBkZWZpbmUgdGhlIG1lY2hh bmlzbSBmb3IgcmVsaWFiaWxpdHkgb2YgTFNBIGRpc3NlbWluYXRpb24uCgogICBSaWNoYXJkIE9n aWVyIGhhcyBwcmVzZW50ZWQgYSBuaWNlIGRpc2N1c3Npb24gb2YgdGhlc2UgYWx0ZXJuYXRpdmVz CiAgIGluIFs1XS4gIFRoZSBwcm9wb3NlZCBhbHRlcm5hdGl2ZXMgZm9yIHNlbGVjdGluZyB0aGUg c2V0IG9mIHJlbGF5CiAgIG5vZGVzIGFyZToKICAgMS4gIE1QUnMgc2VsZWN0ZWQgYnkgdGhlIG9y aWdpbmF0aW5nIG5vZGUKICAgMi4gIE1QUnMgdGhhdCBhcmUgc2VsZi1zZWxlY3RlZAogICAzLiAg Y29ubmVjdGVkIGRvbWluYXRpbmcgc2V0cyAoQ0RTKQogICA0LiAgbm9uLWxlYWYgbm9kZXMgb2Yg YSBtaW4taG9wIHNwYW5uaW5nIHRyZWUgcm9vdGVkIGF0IHRoZQogICAgICAgb3JpZ2luYXRvcgog ICBNUFJzIGFyZSBhbHNvIHNvbWV0aW1lcyByZWZlcnJlZCB0byBhcyBzb3VyY2UtZGVwZW5kZW50 IENEUywgd2hpbGUKICAgdGhlIHVzZSBvZiB0aGUgdGVybSBDRFMgdHlwaWNhbGx5IG1lYW5zIHNv dXJjZS1pbmRlcGVuZGVudCBDRFMuICBBcwogICBmb3IgZGVmaW5pbmcgdGhlIHNldCBvZiBMU0Fz IHRoYXQgdGhlc2UgcmVsYXkgbm9kZXMgYXJlIHJlc3BvbnNpYmxlCiAgIGZvciBmb3J3YXJkaW5n LCBvcHRpb25zIDEsIDIsIGFuZCA0IGFyZSBleGFtcGxlcyBvZiB3aGF0IGlzIGNhbGxlZAogICBv cmlnaW4tZGVwZW5kZW50IHJlbGF5IG5vZGUgc2V0cyAoUk5TKSwgd2hpbGUgMyBpcyBhbiBleGFt cGxlIG9mCiAgIG9yaWdpbi1pbmRlcGVuZGVudCBSTlMgKGFsbCBMU0FzIGFyZSBkaXN0cmlidXRl ZCBhbG9uZyB0aGUgc2FtZSBDRFMKICAgYmFja2JvbmUgcmVnYXJkbGVzcyBvZiB0aGUgTFNBIG9y aWdpbmF0b3IpLgoKICAgVGhlIEJvZWluZyAoWzNdKSBhbmQgQ2lzY28gcHJvcG9zYWxzIChbNF0p IGFyZSBleGFtcGxlcyBvZiB0aGUgZmlyc3QKICAgdHlwZSBvZiByZWxheSBub2RlIHNldCBzZWxl Y3Rpb24sIGFsdGhvdWdoIHRoZXkgZGlmZmVyIGluIHRoZQogICBwZXJpb2RpYyAodW5yZWxpYWJs ZSkgb3IgYWNrbm93bGVkZ2VkIChyZWxpYWJsZSkgbW9kZXMgb2YgTFNBCiAgIGZsb29kaW5nLiAg T2dpZXIgcmVmZXJlbmNlcyBzZWxmLXNlbGVjdGluZyBNUFIgdGVjaG5pcXVlcyBpbiBbNV07CgoK CkhlbmRlcnNvbiAoZWQuKSAgICAgICAgICBFeHBpcmVzIEFwcmlsIDEzLCAyMDA1ICAgICAgICAg ICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgU3VtbWFyeSBvZiBNQU5FVCBP U1BGIFByb3Bvc2FscyAgICAgICAgIE9jdG9iZXIgMjAwNAoKCiAgIGVzc2VudGlhbGx5LCBzdWNo IHRlY2huaXF1ZXMgaW5jdXIgZXh0cmEgcGVyLW5vZGUgcHJvY2Vzc2luZyBmb3IgdGhlCiAgIGF2 b2lkYW5jZSBvZiBoYXZpbmcgdG8gbm90aWZ5IG5laWdoYm9ycyB0aGF0IHRoZXkgYXJlIHNlbGVj dGVkIGFzIGFuCiAgIE1QUi4gIE9naWVyIGhhcyBvYnNlcnZlZCB0aGF0IENEU3MgKGFuZCBzZWxm LXNlbGVjdGVkIE1QUnMpIGFyZQogICBzb21ld2hhdCBhbmFsb2dvdXMgdG8gT1NQRiBkZXNpZ25h dGVkIHJvdXRlcnMuICBBIG51bWJlciBvZiBDRFMKICAgc2VsZWN0aW9uIGFsZ29yaXRobXMgaGF2 ZSBiZWVuIGV4cGxvcmVkIGZvciBNQU5FVHMsIGFuZCBPZ2llcgogICBvYnNlcnZlcyB0aGF0IHRo ZSBvcmlnaW5hbCB2ZXJzaW9uIG9mIFRCUlBGIHVzZWQgdGhlIGZvdXJ0aCB0eXBlIG9mCiAgIFJO UyBzZXQgc2VsZWN0aW9uLgoKMy4yLjEgIERpc2N1c3Npb24gb2YgUk5TCgogICBUaGVyZSBoYXZl IGJlZW4gbWFueSBwcm9wb3NhbHMgaW4gdGhlIGxpdGVyYXR1cmUgZm9yIG9wdGltaXppbmcgcmVs YXkKICAgbm9kZSBzZXQgc2VsZWN0aW9uIGluIGEgTUFORVQgZW52aXJvbm1lbnQuICBUaGUgcHJv cG9zYWxzIHRoYXQgd2UKICAgaGF2ZSBiZWVuIGNvbnNpZGVyaW5nIGluIHRoZSBkZXNpZ24gdGVh bSwgYW5kIHRoYXQgYXJlIGFwcHJvcHJpYXRlCiAgIGZvciByZWxpYWJsZSB0cmFuc21pc3Npb24g dGhyb3VnaG91dCB0aGUgZmxvb2RpbmcgZG9tYWluLCBhcmUgYmFzZWQKICAgb24ga25vd2xlZGdl IG9mIGEgbm9kZSdzIGxvY2FsIG5laWdoYm9yaG9vZCAodHlwaWNhbGx5IGRpc2NvdmVyZWQKICAg dGhyb3VnaCBIZWxsbyBtZXNzYWdlcykgdG8gZmluZCBhIHN1YnNldCBvZiBub2RlcyB0byByZWJy b2FkY2FzdCB0aGUKICAgbWVzc2FnZXMuICBUaGUgZGlzY3Vzc2lvbiBiZWxvdyBmb2N1c2VzIG9u IHRoZSBmb2xsb3dpbmcgcHJvcG9zYWxzOgogICAxLiAgT0xTUi1zdHlsZSBNUFJzCiAgIDIuICBz ZWxmLXNlbGVjdGVkIE1QUnMKICAgMy4gIENpc2NvJ3MgT3ZlcmxhcHBpbmcgUmVsYXlzCiAgIDQu ICBjb25uZWN0ZWQgZG9taW5hdGluZyBzZXRzIChDRFMpCgogICBBZGRpdGlvbmFsIGRpc2N1c3Np b24gb2YgdGhlIGlzc3VlcyBzdXJyb3VuZGluZyBSTlMgZGVzaWduIGlzIGZvdW5kCiAgIGluIFs1 XS4KCjMuMi4xLjEgIE9MU1Itc3R5bGUgTVBScwoKICAgQSBub2RlJ3MgbXVsdGlwb2ludCByZWxh eXMgKE1QUnMpIGZvcm0gYSBkb21pbmF0aW5nIHNldCBvZiBpdHMKICAgdHdvLWhvcCBuZWlnaGJv cmhvb2QuICBUaGUgc2V0IG9mIGFsbCBNUFJzIGluIHRoZSBuZXR3b3JrIChmb3IgYWxsCiAgIG5v ZGVzKSBmb3JtcyBhIGRvbWluYXRpbmcgc2V0IGZvciB0aGUgc2V0IG9mIGFsbCBub2Rlcy4gIE9M U1Itc3R5bGUKICAgTVBScyBhcmUgYSBzZXQgb2Ygbm9kZXMgdGhhdCBvYmV5IHRoZSBmb2xsb3dp bmcgcHJvcGVydGllczogIGkpIGVhY2gKICAgTVBSIGlzIHNlbGVjdGVkIGJ5IGFuIG9yaWdpbmF0 aW5nIG5vZGUgKGFuICJNUFIgc2VsZWN0b3IiKSBhbmQgc2VydmVzCiAgIGFzIGEgcmVsYXkgZm9y IHJlYnJvYWRjYXN0aW5nIGZsb29kZWQgcGFja2V0cyB0aGF0IGFyZSByZWNlaXZlZCBmcm9tCiAg IHRoZSBNUFIgc2VsZWN0b3IsIGlpKSBub2RlcyBjYW4gc2ltdWx0YW5lb3VzbHkgc2VydmUgYXMg YW4gTVBSIHdpdGgKICAgcmVzcGVjdCB0byBtb3JlIHRoYW4gb25lIG5laWdoYm9yaW5nIG5vZGUs IGlpaSkgTVBScyBhcmUgbm90aWZpZWQgb2YKICAgdGhlaXIgc2VsZWN0aW9uIGFzIGFuIE1QUiBi eSBhIG1lc3NhZ2UgZnJvbSB0aGUgTVBSIHNlbGVjdG9yLiAgQnkKICAgdHJhbnNpdGl2aXR5LCBh IHBhY2tldCBvcmlnaW5hdGVkIGJ5IGFuIE1QUiBzZWxlY3RvciBzaG91bGQgdGhlcmVmb3JlCiAg IHJlYWNoIGFsbCBvZiB0aGUgbm9kZXMgaW4gdGhlIG5ldHdvcmsgaWYgZWFjaCByZWNlaXZpbmcg bm9kZSBpdHNlbGYKICAgaGFzIE1QUnMgZm9yIGl0cyB0d28taG9wIGNvdmVyYWdlLgoKICAgSXQg c2hvdWxkIGJlIGNsZWFyIGZyb20gdGhlIGFib3ZlIHRoYXQgZWFjaCBub2RlLCB3aGVuIGl0IGRl Y2lkZXMKICAgd2hldGhlciB0byByZWJyb2FkY2FzdCBhIHJlY2VpdmVkIG1lc3NhZ2UsIG11c3Qg Y29uc2lkZXIgd2hpY2ggbm9kZQogICB3YXMgdGhlIHByZXZpb3VzIGhvcCAoYW5kIHdoZXRoZXIg aXQgaXMgYW4gTVBSIHNlbGVjdG9yIGZvciB0aGUKICAgbm9kZSkuICBDYXNlcyBtYXkgYXJpc2Ug aW4gd2hpY2ggYSBub2RlIGxvc2VzIGEgbWVzc2FnZSBmcm9tIG9uZSBvZgogICBpdHMgTVBSIHNl bGVjdG9ycyBidXQgc3RpbGwgcmVjZWl2ZXMgdGhlIG1lc3NhZ2UgZnJvbSBhbm90aGVyCiAgIChu b24tTVBSLXNlbGVjdG9yKSBuZWlnaGJvciBhbmQgZG9lcyBub3QgZm9yd2FyZCBpdCwgYmVjYXVz ZSB1cG9uCiAgIHJldHJhbnNtaXNzaW9uIGJ5IHRoZSBNUFIgc2VsZWN0b3IsIHRoZSByZWNlaXZp bmcgbm9kZSB0cmVhdHMgaXQgYXMgYQogICBkdXBsaWNhdGUgYmVjYXVzZSBpdCBpcyBhbHJlYWR5 IGluIGl0cyBkYXRhYmFzZS4gIE9uZSBzb2x1dGlvbiBmb3IKCgoKSGVuZGVyc29uIChlZC4pICAg ICAgICAgIEV4cGlyZXMgQXByaWwgMTMsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDddCgwK SW50ZXJuZXQtRHJhZnQgICAgICBTdW1tYXJ5IG9mIE1BTkVUIE9TUEYgUHJvcG9zYWxzICAgICAg ICAgT2N0b2JlciAyMDA0CgoKICAgdGhpcyBpcyB0byBrZWVwIHRyYWNrIG9mIGEgZmxhZyBmb3Ig ZWFjaCBtZXNzYWdlIGluIHRoZSBkYXRhYmFzZSB0aGF0CiAgIGluZGljYXRlcyB3aGV0aGVyIHRo ZSBtZXNzYWdlIHdhcyBldmVyIGxvY2FsbHkgcmVmbG9vZGVkLCBhcwogICBkZXNjcmliZWQgaW4g WzNdLgoKICAgVGhlIG9wdGltYWwgc2VsZWN0aW9uIG9mIE1QUnMgaXMgYW4gTlAtaGFyZCBwcm9i bGVtOyBob3dldmVyLAogICBoZXVyaXN0aWNzIGV4aXN0IHRvIG9idGFpbiBnb29kIGNvdmVyYWdl LiAgVGhlIE1QUiBzZWxlY3Rpb24KICAgYWxnb3JpdGhtIGluIE9MU1IgaXMgYSBncmVlZHkgYWxn b3JpdGhtIHRoYXQgc2VsZWN0cyBNUFJzIGJhc2VkIG9uCiAgIGRlZ3JlZSBvZiB0aGUgY2FuZGlk YXRlIG5vZGVzLiAgSXQgaXMgYW5hbHl6ZWQgaW4gKGFtb25nIG90aGVyCiAgIHBsYWNlcykgWzld LCBhbmQgaXMga25vd24gdG8gcHJvZHVjZSBNUFIgc2V0cyB0aGF0IGFyZSBubyBtb3JlIHRoYW4K ICAgbG9nIG0gb2YgdGhlIG9wdGltYWwgTVBSIHNldCwgYW5kIHJ1bnMgaW4gTyhtXjIpIHRpbWUu ICBSaWNoYXJkIE9naWVyCiAgIGhhcyBvYnNlcnZlZCBpbiBbMTBdIHRoYXQgdGhpcyBhbGdvcml0 aG0gbWF5IHJlc3VsdCBpbiBmZXdlciBNUFJzLAogICBidXQgY29uY2VudHJhdGVkIG9uIHRoZSBi b3VuZGFyeSBvZiB0aGUgcmVjZXB0aW9uIHJhbmdlIGFuZCBoZW5jZQogICBsZXNzIHN0YWJsZS4g IEFuIGFsdGVybmF0ZSB0ZWNobmlxdWUgYmFzZWQgb24gbWluaW11bSBub2RlIElEIG1heSBiZQog ICB1c2VkLCBhbmQgbWF5IGJlIGZhc3RlciBvciBzaW1wbGVyIHRvIGltcGxlbWVudCAoTyhtKSBy dW4gdGltZSkgYnV0CiAgIGlzIG5vdCBib3VuZGVkIHdpdGggcmVzcGVjdCB0byB0aGUgb3B0aW1h bCBNUFIgc2V0IHNpemUgWzldLgoKICAgRm9yIHJvYnVzdG5lc3MsIGl0IG1heSBub3QgYmUgZGVz aXJhYmxlIHRvIG9ubHkgaW5jbHVkZSB0aGUgbWluaW11bQogICBudW1iZXIgb2YgTVBScywgc2lu Y2Ugd2lyZWxlc3MgbWVzc2FnZXMgbWF5IGJlIGxvc3QuICBNUFIgc2VsZWN0aW9uCiAgIGNhbiBi ZSB0dW5lZCB0byBpbmNsdWRlIHJlZHVuZGFudCBjb3ZlcmFnZSBvZiB0aGUgdHdvLWhvcCBuZWln aGJvcgogICBzZXQgKGZvciBpbmNyZWFzZWQgcHJvYmFiaWxpdHkgb2Ygc3VjY2Vzc2Z1bCBtZXNz YWdlIGZsb29kaW5nKSwgdGFrZQogICBpbnRvIGFjY291bnQgYSBub2RlJ3MgIndpbGxpbmduZXNz IHRvIGZvcndhcmQiIChhbmFsb2dvdXMgdG8gT1NQRgogICByb3V0ZXIgcHJpb3JpdHkpLCBhbmQg aXMgYWRhcHRpdmUgdG8gbGluayBxdWFsaXRpZXMuICBBIGZvdXJ0aAogICBwcm9wZXJ0eSAoaXQg Y2FuIHJlZHVjZSB0aGUgYWR2ZXJ0aXNlZCBsaW5rIHNldCBzaXplKSBkb2VzIG5vdCBzZWVtCiAg IGFzIHJlbGV2YW50IHRvIHRoZSBPU1BGIGRpc2N1c3Npb24gc2luY2Ugd2UgYXJlIHRhbGtpbmcg YWJvdXQgZnVsbAogICB0b3BvbG9neSBvcGVyYXRpb24uCgogICBJdCBzaG91bGQgYWxzbyBiZSBj bGVhciB0aGF0IE9MU1Itc3R5bGUgTVBSIHNlbGVjdGlvbiByZXF1aXJlcyBhIG5ldwogICBtZXNz YWdlIHR5cGUgb3IgZXh0ZW5zaW9ucyB0byBleGlzdGluZyBtZXNzYWdlcyB0byBkaXN0cmlidXRl IHRoZSBNUFIKICAgc2VsZWN0aW9uIGluZm9ybWF0aW9uIHRvIG5laWdoYm9ycy4gIEVpdGhlciBt b2RpZmllZCBIZWxsbyBtZXNzYWdlCiAgIGZvcm1hdHMsIG9yIExpbmsgTG9jYWwgU2lnbmFsaW5n IGV4dGVuc2lvbnMgbWF5IGFjY29tcGxpc2ggdGhpcy4KCiAgIEFsdGVybmF0aXZlbHksIFJpY2hh cmQgT2dpZXIgaGFzIG9ic2VydmVkIHRoYXQsIGluIHRoZSBNUFIgZnJhbWV3b3JrLAogICBub2Rl cyBjb3VsZCBjb21wdXRlIHRoZWlyIG9yaWdpbmF0aW5nIG5vZGUgc2V0IChyZXBvcnRlZCBvcmln aW5hdG9yCiAgIHNldCwgb3IgUk9TKSBieSBjb21wdXRpbmcgbWluLWhvcCBwYXRocyBiYWNrIHRv IG9yaWdpbmF0b3JzLiAgU3VjaCBhCiAgIGNhcGFiaWxpdHkgb2Yga25vd2luZyB0aGUgUk9TIG1h eSBhaWQgaW4gb3B0aW1pemluZyBkYXRhYmFzZQogICBzeW5jaHJvbml6YXRpb24gdGVjaG5pcXVl cyAoZWFjaCBub2RlIHdvdWxkIGtub3cgd2hpY2ggc3Vic2V0IG9mIExTQXMKICAgdGhhdCBpdCBp cyByZXNwb25zaWJsZSBmb3IgbWFraW5nIHN1cmUgYXJlIHN5bmNocm9uaXplZCB3aXRoIHRoZQog ICBuZWlnaGJvcnMpIGFuZCBpcyBkaXNjdXNzZWQgZnVydGhlciBiZWxvdy4KCiAgIE1QUnMgaGF2 ZSB0aGUgcHJvcGVydHkgdGhhdCB0aGUgUk5TIGNvbnN0cnVjdGlvbiBpcyBkaXN0cmlidXRlZCBh bmQKICAgdGhlIGFsZ29yaXRobSB0aGF0IGVhY2ggbm9kZSB1c2VzIHRvIGRldGVybWluZSBzdWZm aWNpZW50IHR3by1ob3AKICAgbmVpZ2hib3IgY292ZXJhZ2UgZG9lc24ndCBuZWNlc3NhcmlseSBu ZWVkIHRvIGJlIHN0YW5kYXJkaXplZC4KICAgV2hldGhlciB0aGlzIGlzIGEgZ29vZCBvciBiYWQg cHJvcGVydHkgaGFzbid0IHByZXZpb3VzbHkgYmVlbgogICBkaXNjdXNzZWQsIHRvIHRoZSBhdXRo b3IncyBrbm93bGVkZ2UuICBPbmUgcG90ZW50aWFsIGJlbmVmaXQgbWF5IGJlCiAgIHRoYXQgaXQg d291bGQgYWxsb3cgZm9yIGdyYWR1YWwgZGVwbG95bWVudCBvZiBpbXByb3ZlZCBoZXVyaXN0aWNz CiAgIHdpdGhvdXQgYWZmZWN0aW5nIGludGVyb3BlcmFiaWxpdHkuCgogICBNUFJzIGhhdmUgdGhl IHByb3BlcnR5IHRoYXQgZmxvb2RpbmcgaXMgZG9uZSBhbG9uZyBtaW4taG9wIHBhdGhzLgoKCgpI ZW5kZXJzb24gKGVkLikgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxMywgMjAwNSAgICAgICAgICAg ICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFN1bW1hcnkgb2YgTUFORVQgT1NQ RiBQcm9wb3NhbHMgICAgICAgICBPY3RvYmVyIDIwMDQKCgogICBNUFJzIGFsc28gaGF2ZSB0aGUg cHJvcGVydHkgdGhhdCBmbG9vZGluZyB0cmFmZmljIG1pZ2h0IGJlIG1vcmUKICAgZGlzdHJpYnV0 ZWQgYW1vbmcgZGlmZmVyZW50IG5vZGVzIChsZXNzIGNvbmNlbnRyYXRlZCB0aGFuIHdoZW4gdXNp bmcKICAgYSBzcGVjaWZpYyBmbG9vZGluZyAiYmFja2JvbmUiKS4KCiAgIFVzaW5nIGFuIE9MU1It bGlrZSBNUFIgYWxnb3JpdGhtIGFwcGxpZWQgdG8gT1NQRiwgYWZ0ZXIgbmVpZ2hib3JzCiAgIHJl YWNoIHN0YXRlIDItd2F5LCBhIG5vZGUgbXVzdCBydW4gdGhlIE1QUiBzZWxlY3Rpb24gYWxnb3Jp dGhtIGFuZAogICB0aGVuIG5vdGlmeSB0aGUgbmVpZ2hib3IgdGhhdCBpdCBoYXMgYmVlbiBzZWxl Y3RlZC4gIFRoaXMgbWF5IGluY3VyIGEKICAgZGVsYXkgaW4gZmxvb2RpbmcgYW5kIGNvbnNlcXVl bnRseSBzb21lIGxvc3QgaW5pdGlhbCBtZXNzYWdlcy4KICAgQWx0ZXJuYXRpdmVseSwgaW5zdGVh ZCBvZiBhbiAib3B0LWluIiBwb2xpY3kgZm9yIHJlZmxvb2RpbmcsIGl0IG1heQogICBiZSBwb3Nz aWJsZSB0byBjb25zdHJ1Y3QgYW4gIm9wdC1vdXQiIG1lY2hhbmlzbSB0byBoYXZlIG5vZGVzIGRl ZmF1bHQKICAgdG8gYmVpbmcgTVBScyBhbmQgb25seSBkZS1zZWxlY3QgdGhlbXNlbHZlcyB3aGVu IHRoZXkgZG8gbm90IHNlZQogICB0aGVtc2VsdmVzIGluIGEgbmVpZ2hib3IncyBNUFIgc2VsZWN0 b3IgYW5ub3VuY2VtZW50LiAgVGhpcyBtYXkKICAgaW1wcm92ZSB0aGUgcGVyY2VudGFnZSBvZiBz dWNjZXNzZnVsbHkgZmxvb2RlZCBtZXNzYWdlcywgYXQgdGhlIGNvc3QKICAgb2YgaW5jcmVhc2Vk IG51bWJlciBvZiByZWR1bmRhbnQgdHJhbnNtaXNzaW9ucy4gIFRvIHRoZSBhdXRob3IncwogICBr bm93bGVkZ2UsIHRoaXMgYXNwZWN0IGhhcyBub3QgYmVlbiBkaXNjdXNzZWQgbXVjaCwgYW5kIHNl ZW1zIHRvIGJlCiAgIGluZGVwZW5kZW50IG9mIHRoZSBpc3N1ZSBvZiB3aGV0aGVyIHRvIHVzZSBN UFJzIHZzLiAgQ0RTLgoKMy4yLjEuMiAgU2VsZi1zZWxlY3RlZCBNUFJzCgogICBSZWdhcmRpbmcg d2hldGhlciBNUFJzIGFyZSBzZWxmLXNlbGVjdGVkIHZlcnN1cyBzZWxlY3RlZCBieSB0aGUKICAg b3JpZ2luYXRvcnMgdGhlbXNlbHZlcywgdGhlIHRyYWRlb2ZmIHNlZW1zIHRvIGJlIHNvbWUgaW5j cmVhc2UgaW4KICAgY29tcGxleGl0eSAoaS5lLiwgcHJvY2Vzc2luZyBzdGVwcykgdG8gc2VsZi1z ZWxlY3QgdGhlbSwgdmVyc3VzIGEKICAgbmVlZCB0byB1c2UgZXh0cmEgZmllbGRzIGluIEhlbGxv IG9yIG90aGVyIG1lc3NhZ2VzIHRvIG5vdGlmeSBhCiAgIG5laWdoYm9yIHRoYXQgaXQgaGFzIGJl ZW4gc2VsZWN0ZWQuICBIb3dldmVyLCBpdCBtYXkgcmVxdWlyZSB0aGF0CiAgIE9TUEYgSGVsbG9z IGJlIG1vZGlmaWVkIHRvIHByb3ZpZGUgdHdvLWhvcCBpbmZvcm1hdGlvbiBhbnl3YXkuICBGb3IK ICAgZXhhbXBsZSwgY29uc2lkZXIgaWYgZWFjaCBub2RlIHByb3ZpZGVkIGl0cyB0d28taG9wIG5l aWdoYm9yCiAgIGluZm9ybWF0aW9uIHRvIGFsbCBvZiBpdHMgb25lIGhvcCBuZWlnaGJvcnMuICBS YXRoZXIgdGhhbiB0aGUgbm9kZQogICBydW5uaW5nIHRoZSBNUFIgc2VsZWN0aW9uIGFsZ29yaXRo bSBhbmQgbm90aWZ5aW5nIHRoZSBzZWxlY3RlZCBvbmUKICAgaG9wIG5laWdoYm9yLCBlYWNoIG5l aWdoYm9yIGNvdWxkIHJ1biB0aGUgYWxnb3JpdGhtIG9uIHRoZSBub2RlJ3MKICAgYmVoYWxmLCBh bmQgZGVjaWRlIHdoZXRoZXIgaXQgd291bGQgaGF2ZSBiZWVuIHNlbGVjdGVkIGJ5IHRoZSBub2Rl LgogICBCdXQgdGhlIGN1cnJlbnQgT1NQRiBIZWxsbyBvbmx5IHByb3ZpZGVzIG9uZS1ob3AgbmVp Z2hib3IgaW5mb3JtYXRpb24KICAgZm9yIHRoZSBzZW5kaW5nIG5vZGUuCgogICBBIG1pbmltdW0t SUQgYWxnb3JpdGhtIGRlc2NyaWJlZCBpbiBbOV0gcmVxdWlyZXMgTyhtXjQpIGNvbXB1dGF0aW9u CiAgIHdoZW4gcnVuIGFzIGEgc2VsZi1zZWxlY3RpbmcgYWxnb3JpdGhtIHJhdGhlciB0aGFuIE8o bV4yKSBvciBPKG0pCiAgIHVzaW5nIHRoZSBNUFIgc2VsZWN0b3IgYXBwcm9hY2guICBIb3dldmVy LCBpdCBoYXMgYWxzbyBiZWVuIHBvaW50ZWQKICAgb3V0IGJ5IE9naWVyIHRoYXQsIGFuYWxvZ291 cyB0byBpbmNsdWRpbmcgdGhlIHNlbGVjdGVkIERSIGluIEhlbGxvCiAgIG1lc3NhZ2VzLCBpdCBt YXkgYmUgdXNlZnVsIHRvIGFubm91bmNlIHdoZXRoZXIgYSBub2RlIGhhcyBzZWxlY3RlZAogICBp dHNlbGYgYXMgYW4gTVBSIGZvciBvbmUgb2YgaXRzIG5laWdoYm9ycywgdG8gcmVkdWNlIHRoZSBm cmVxdWVuY3kgb2YKICAgTVBSIGNoYW5nZXMuCgozLjIuMS4zICBDaXNjbyBPdmVybGFwcGluZyBS ZWxheXMKCiAgIEFzIGRlc2NyaWJlZCBpbiBbNF0sIHRoZSBwcm9wb3NlZCAib3ZlcmxhcHBpbmcg cmVsYXlzIiBhbGdvcml0aG0gaXMKICAgYmFzZWQgb24gdGhlIE9MU1IgTVBSIGFsZ29yaXRobSwg d2l0aCB0aGUgZm9sbG93aW5nIG9wdGltaXphdGlvbi4KICAgTmVpZ2hib3JzIHRoYXQgYXJlIHNl bGVjdGVkIGFzIHdoYXQgT0xTUiB3b3VsZCBjYWxsIE1QUnMgYXJlIGNhbGxlZAogICAiYWN0aXZl IiBvdmVybGFwcGluZyByZWxheXMsIGFuZCBhbGwgb3RoZXIgbmVpZ2hib3JzIGFyZSAibm9uLWFj dGl2ZSIKICAgb3ZlcmxhcHBpbmcgcmVsYXlzLCB3aXRoIHJlc3BlY3QgdG8gYSBnaXZlbiB0d28t aG9wIG5laWdoYm9yIG9mIHRoZQoKCgpIZW5kZXJzb24gKGVkLikgICAgICAgICAgRXhwaXJlcyBB cHJpbCAxMywgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgIFN1bW1hcnkgb2YgTUFORVQgT1NQRiBQcm9wb3NhbHMgICAgICAgICBPY3RvYmVyIDIwMDQK CgogICBtZXNzYWdlIG9yaWdpbmF0b3IuICBUaGUgYWN0aXZlIHJlbGF5cyBiZWhhdmUgbGlrZSBP TFNSIE1QUnMsIGJ1dCB0aGUKICAgbm9uLWFjdGl2ZSByZWxheXMgb2YgbWVzc2FnZSBvcmlnaW5h dG9yIG1vbml0b3Igd2hldGhlciB0aGUgdHdvLWhvcAogICBuZWlnaGJvciBpbiBmYWN0IGFja25v d2xlZGdlZCB0aGUgdHJhbnNtaXNzaW9uLiAgSWYgbm8gYWNrIGlzCiAgIHJlY2VpdmVkLCB0aGVu IG9uZSBvZiB0aGUgbm9uLWFjdGl2ZSByZWxheXMgd2lsbCBhdHRlbXB0IHRvCiAgIHJldHJhbnNt aXQgdGhlIG1lc3NhZ2UsIGJhc2VkIG9uIHNvbWUgdGltZSBpbnRlcnZhbCBhbmQgaml0dGVyIHRv CiAgIGF2b2lkIGFsbCBub24tYWN0aXZlIHJlbGF5cyBmcm9tIGF0dGVtcHRpbmcgdG8gcmVjb3Zl ciB0aGUgbG9zcyBhdAogICB0aGUgc2FtZSB0aW1lLgoKICAgT3RoZXIgdGhhbiB0aGlzIHJlbGlh YmlsaXR5IG9wdGltaXphdGlvbiwgaXQgc2VlbXMgdGhhdCB0aGUgcHJvcG9zZWQKICAgQ2lzY28g YXBwcm9hY2ggaW5oZXJpdHMgdGhlIHByb3BlcnRpZXMgZGVzY3JpYmVkIGFib3ZlIHJlZ2FyZGlu ZwogICBPTFNSLXN0eWxlIE1QUnMuICBBcyBwcmVzZW50bHkgZGVmaW5lZCwgaXQgYWxzbyBpbmN1 cnMgYSBkZWxheSBpbgogICBub3RpZnlpbmcgYSBuZWlnaGJvciB0aGF0IGl0IGhhcyBiZWNvbWUg YWN0aXZlICh0aGUgc28tY2FsbGVkCiAgICJvcHQtaW4iIG1ldGhvZCBhYm92ZSksIGJ1dCB0aGlz IGlzIG1pdGlnYXRlZCBieSB0aGUgcHJvdGVjdGlvbgogICBvZmZlcmVkIGJ5IG5vbi1hY3RpdmUg bmVpZ2hib3JzLCBzbyBhbGwgdGhhdCBtaWdodCBoYXBwZW4gaXMgYSBzbGlnaHQKICAgaW5jcmVh c2UgaW4gZmxvb2RpbmcgZGVsYXkuCgozLjIuMS40ICBDRFMgYWxnb3JpdGhtcwoKICAgQXQgdGhl IGVuZCBvZiBTZWN0aW9uIDYgb2YgWzVdLCBSaWNoYXJkIE9naWVyIGFyZ3VlcyB0aGF0IENEUyBt YXkgYmUKICAgcHJlZmVyYWJsZSB0byBNUFIgZm9yIE9TUEYsIHNpbmNlIGl0IG1vcmUgbmF0dXJh bGx5IGZpdHMgd2l0aCB0aGUKICAgY29uY2VwdCBvZiBPU1BGIERSIHdpdGggZmV3ZXIgY2hhbmdl cyBuZWVkZWQgdG8gT1NQRiBwYWNrZXRzLCBhbmQKICAgYmVjYXVzZSBpdCBvZmZlcnMgb3Bwb3J0 dW5pdGllcyB0byBvcHRpbWl6ZSBkYXRhYmFzZSBzeW5jaHJvbml6YXRpb24KICAgdGVjaG5pcXVl cy4KCiAgIFNwZWNpZmljYWxseSwgc29tZSByZXNlYXJjaGVycyAoZS5nLiwgWzEwXSkgaGF2ZSBz aG93biBzaW11bGF0aW9uCiAgIHJlc3VsdHMgdGhhdCBzaG93IHNtYWxsZXIgc2l6ZSByZWxheSBu b2RlIHNldHMgd2hlbiB1c2luZyBDRFMsCiAgIGFsdGhvdWdoIGluIHRoZSBhdXRob3IncyBvcGlu aW9uLCB0aGlzIGV2aWRlbmNlIG1heSBiZQogICBzY2VuYXJpby1kZXBlbmRlbnQgYW5kIGRvZXMg bm90IHN0cm9uZ2x5IGZhdm9yIG9uZSBvciB0aGUgb3RoZXIuICBJdAogICBoYXMgYmVlbiBhcmd1 ZWQgdGhhdCBDRFMgYWxnb3JpdGhtcyBhcmUgcG90ZW50aWFsbHkgc2ltcGxlciBhcyB3ZWxsLAog ICBzaW5jZSB0aGUgZGVjaXNpb24gdG8gZm9yd2FyZCBpcyBub3QgYmFzZWQgb24gdGhlIG9yaWdp bmF0b3Igb2YgdGhlCiAgIHByZXZpb3VzIHRyYW5zbWlzc2lvbi4gIENEUyBtYXkgbm90IGZvcndh cmQgYWxvbmcgbWluLWhvcCBwYXRocyBmcm9tCiAgIHRoZSBtZXNzYWdlIG9yaWdpbmF0b3IsIGFs dGhvdWdoIHRoZSBkaWZmZXJlbmNlIGluIHBhdGggbGVuZ3RoIGlzCiAgIHByb2JhYmx5IG9ubHkg b25lIGhvcCwgaWYgYXQgYWxsLCBhbmQgbWV0aG9kcyBtYXkgZXhpc3QgdG8gYWxsb3cKICAgbWlu LWhvcCBmbG9vZGluZyAoZS5nLiwgWzEwXSkuCgogICBJZiBhIG5vZGUgaXMgc2VsZi1zZWxlY3Rp bmcgaXRzZWxmIGFzIGEgQ0RTLCBpdCBtb3N0IGxpa2VseSBkb2VzIHNvCiAgIHdpdGggYW4gYXNz dW1wdGlvbiB0aGF0IG5laWdoYm9ycyBhcmUgcnVubmluZyB0aGUgaWRlbnRpY2FsIG9yCiAgIHNp bWlsYXIgYWxnb3JpdGhtIChpbiBtdWNoIHRoZSBzYW1lIHdheSB0aGF0IHRoZSBkaXN0cmlidXRl ZAogICBjb21wdXRhdGlvbiBvZiBEaWprc3RyYSdzIGFsZ29yaXRobSByZXF1aXJlcyB0aGF0IGFs bCBub2RlcwogICBjb25zaXN0ZW50bHkgYXBwbHkgaXQpLiAgSW4gYSBNQU5FVCBlbnZpcm9ubWVu dCwgc29tZSBub2RlcyBtYXkgbm90CiAgIGJlIGFzIHdpbGxpbmcgdG8gc2VsZWN0IHRoZW1zZWx2 ZXMgYXMgQ0RTLCBkdWUgdG8gaXNzdWVzIHN1Y2ggYXMKICAgZW5lcmd5IHJlc2VydmUuICBSaWNo YXJkIE9naWVyIHN1Z2dlc3RlZCBpbiBbNV0gdGhhdCB0aGUgUm91dGVyCiAgIFByaW9yaXR5IGZp ZWxkIG1heSBiZSB1c2VkIHRvIGluZGljYXRlICJ3aWxsaW5nbmVzcyIgdG8gcmVsYXkgdHJhZmZp YwogICBhbmQgYmVjb21lIGEgQ0RTIG5vZGUsIGJ1dCB0aGVyZSBpcyBubyBzcGVjaWZpYyBkZXNj cmlwdGlvbiBvZiBob3cKICAgdGhpcyBtaWdodCB3b3JrLiAgTGlrZXdpc2UsIGl0IGlzIG5vdCBj bGVhciBob3cgc2Vuc2l0aXZlIGEgQ0RTCiAgIHNlbGYtc2VsZWN0aW9uIGFsZ29yaXRobSB3b3Vs ZCBiZSB0byBuZWlnaGJvcnMgdXNpbmcgY29uc2lzdGVudAogICBhbGdvcml0aG1zLCBhbmQgaGVu Y2UsIGhvdyBlYXN5IGl0IHdvdWxkIGJlIHRvIGV2b2x2ZSB0aGUgaGV1cmlzdGljcwogICBpbiBh biBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IHNjZW5hcmlvLgoKCgpIZW5kZXJzb24gKGVkLikgICAg ICAgICAgRXhwaXJlcyBBcHJpbCAxMywgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJ bnRlcm5ldC1EcmFmdCAgICAgIFN1bW1hcnkgb2YgTUFORVQgT1NQRiBQcm9wb3NhbHMgICAgICAg ICBPY3RvYmVyIDIwMDQKCgogICBSZWxhdGVkIHRvIHRoZSBpc3N1ZSBvZiBrbm93aW5nIHRoZSBS T1MgaXMgdGhlIGlzc3VlIG9mIG9wdGltaXplZAogICBkYXRhYmFzZSBzeW5jaHJvbml6YXRpb24u ICBBbm90aGVyIGJlbmVmaXQgb2YgQ0RTIG9yIE1QUnMgdGhhdCBrbm93CiAgIHRoZWlyIFJPUyBp cyB0aGF0IHRoZXNlICJzcGVjaWFsIG5vZGVzIiBjYW4gdGFrZSByZXNwb25zaWJpbGl0eSBmb3IK ICAgc3luY2hyb25pemF0aW9uLCBtdWNoIGFzIGFuIGV4aXN0aW5nIE9TUEYgRFIsIHJhdGhlciB0 aGFuIHJlcXVpcmluZwogICBwYWlyLXdpc2Ugc3luY2hyb25pemF0aW9uIGJldHdlZW4gbm9kZXMu CgogICBBbHRob3VnaCB0aGVyZSBhcmUgc2V2ZXJhbCBoZXVyaXN0aWNzIGZvciBDRFMgY29uc3Ry dWN0aW9uIHRoYXQgaGF2ZQogICBiZWVuIHByb3Bvc2VkLCBvbmUgaW50ZXJlc3Rpbmcgb25lIHBy ZXNlbnRlZCBieSBJTlJJQSAoaW4gWzldKSBjYW4gYmUKICAgdXNlZCB0byB0cmFuc2Zvcm0gdGhl IHNldCBvZiBNUFJzIGludG8gYSBDRFMsIGlmIHRoZSBub2RlcyBoYXZlIHNvbWUKICAgYWdyZWVk LXVwb24ga25vd2xlZGdlIG9mIHRoZSB0b3RhbC1vcmRlciBvZiB0aGUgbmV0d29yayAoc3VjaCBh cwogICBpbmNyZWFzaW5nIHJvdXRlciBJRCkuICBPZ2llciBoYXMgZG9uZSBzb21lIHNpbXVsYXRp b24gZXZhbHVhdGlvbiBvZgogICB0aGlzIGFsZ29yaXRobSBpbiBbMTBdIGFuZCBzaG93biBzaW11 bGF0aW9uIHJlc3VsdHMgdGhhdCBpdCBwZXJmb3JtcwogICB3b3JzZSB0aGFuIGFuIGFsZ29yaXRo bSBiYXNlZCBvbiB0d28taG9wIG5laWdoYm9yIGluZm9ybWF0aW9uLgoKMy4yLjEuNSAgU3VtbWFy eQoKICAgSW4gdGhlIHBhc3QsIHRoZXJlIGhhcyBiZWVuIHNpbXVsYXRpb24gZXZpZGVuY2UgcHJl c2VudGVkIHRoYXQKICAgZmF2b3JlZCBNUFJzIG92ZXIgQ0RTLCBhbmQgdmljZSB2ZXJzYSwgaW4g dGVybXMgb2YgYmFuZHdpZHRoCiAgIGVmZmljaWVuY3kuICBJbiB0aGUgYWJzZW5jZSBvZiBiZXR0 ZXIgZGF0YSwgaXQgaXMgdGhlIGF1dGhvcidzCiAgIG9waW5pb24gdGhhdCwgZnJvbSB0aGUgc3Rh bmRwb2ludCBvZiBiYW5kd2lkdGggZWZmaWNpZW5jeSwgTVBScwogICB2ZXJzdXMgQ0RTIHdpbGwg bm90IG1ha2UgYSB3aG9sZSBsb3Qgb2YgZGlmZmVyZW5jZSwgZXNwZWNpYWxseSB3aGVuCiAgIG1l dHJpY3MgbGlrZSByb2J1c3RuZXNzIGFyZSBjb25zaWRlcmVkIHRoYXQgbWlnaHQgZmF2b3Igc29t ZQogICByZWR1bmRhbmN5IGluIHRyYW5zbWlzc2lvbnMgYW55d2F5LiAgQm90aCB0ZWNobmlxdWVz IHNlZWsgdG8gbWluaW1pemUKICAgYXMgbXVjaCBhcyBwb3NzaWJsZSB0aGUgbnVtYmVyIG9mIHRy YW5zbWlzc2lvbnMgcmVxdWlyZWQgdG8KICAgZGlzc2VtaW5hdGUgdGhlIGluZm9ybWF0aW9uLCBh bmQgZGlmZmVyZW50IHNjZW5hcmlvcyB3aWxsIHlpZWxkCiAgIGRpZmZlcmVudCB3aW5uZXJzLCBi dXQgaW4gbW9zdCBjYXNlcywgdGhlIGRpZmZlcmVuY2VzIHNlZW0gdG8gYmUgYQogICBmZXcgcGVy Y2VudC4gIEluc3RlYWQsIHRoZSBkZXNpZ24gZGVjaXNpb24gc2hvdWxkIHByb2JhYmx5IGJlIGRy aXZlbgogICBieSB3aGljaCBtZWNoYW5pc20gZml0cyBiZXN0IChpcyBsZWFzdCBkaXNydXB0aXZl KSB0byB0aGUgZXhpc3RpbmcKICAgT1NQRiBpbXBsZW1lbnRhdGlvbi4KCiAgIFRoZXJlIGhhdmUg YmVlbiBhcmd1bWVudHMgcHV0IGZvcndhcmQsIHByaW5jaXBhbGx5IGJ5IFJpY2hhcmQgT2dpZXIs CiAgIHRoYXQgQ0RTLWJhc2VkIGZsb29kaW5nIGlzIGEgYmV0dGVyIGZpdCBmb3IgT1NQRiB0aGFu IGlzIE1QUi1iYXNlZCwKICAgYmVjYXVzZSBDRFMgc2VsZWN0aW9uIGFsZ29yaXRobXMgZG8gbm90 IG5lY2Vzc2FyaWx5IHJlcXVpcmUgY2hhbmdlcwogICB0byBPU1BGIG1lc3NhZ2UgZm9ybWF0cywg YmVjYXVzZSBDRFMgaXMgYW5hbG9nb3VzIHRvIERlc2lnbmF0ZWQKICAgUm91dGVyLCBiZWNhdXNl IHRoZXkgbWF5IGhhdmUgc2ltcGxlciBjb25zdHJ1Y3Rpb24gYWxnb3JpdGhtcyAoZm9yCiAgIHRo aXMgcG9pbnQsIHRoZSBhdXRob3IgaGFzIG5vdCBzZWVuIGFueSBwcm9vZiksIGFuZCBiZWNhdXNl IHRoZSBmYWN0CiAgIHRoYXQgYSBDRFMgZG9lcyBub3QgY2FyZSBhYm91dCB0aGUgb3JpZ2luYXRv ciBvZiBhIG1lc3NhZ2UsIHdoaWNoIG1heQogICBoZWxwIGlmIHRoZSBkYXRhYmFzZSBzeW5jaHJv bml6YXRpb24gcHJvY2VkdXJlcyBhcmUgZXZlciBvcHRpbWl6ZWQKICAgZm9yIGEgTUFORVQuICBU aGVyZWZvcmUsIGluIHRoZSBhdXRob3IncyBvcGluaW9uLCBkZXNwaXRlIG5vdCBoYXZpbmcKICAg YSBjb25jcmV0ZSBDRFMtYmFzZWQgcHJvcG9zYWwgb24gdGhlIHRhYmxlLCB0aGUgT1NQRiBNQU5F VCBkZXNpZ24KICAgdGVhbSBzaG91bGQgY29uc2lkZXIgdGhpcyBpc3N1ZSBtb3JlIGNhcmVmdWxs eS4KCjMuMi4yICBEaXNjdXNzaW9uIG9mIHJlbGlhYmlsaXR5CgogICBJdCBzZWVtcyB0byB0aGUg YXV0aG9yIHRoYXQgdGhlIGRlY2lzaW9uIHRvIGZvY3VzIG9uIHJlbGlhYmxlCiAgIG1lY2hhbmlz bXMgZmlyc3QgaXMgbm9uLWNvbnRlbnRpb3VzLiAgVGhlIGF1dGhvciBoYXMgc3VnZ2VzdGVkCiAg IHBhcnRpYWxpdHkgdG8gbWVjaGFuaXNtcyB0aGF0IGFsbG93IHRoZSBpbnRyb2R1Y3Rpb24gb2Yg YSBwZXJpb2RpYywKICAgbm9uLWFja2VkIExTQSBkaXNzZW1pbmF0aW9uIG1vZGUgaW4gdGhlIGZ1 dHVyZS4KCgoKSGVuZGVyc29uIChlZC4pICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTMsIDIwMDUg ICAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBTdW1tYXJ5IG9m IE1BTkVUIE9TUEYgUHJvcG9zYWxzICAgICAgICAgT2N0b2JlciAyMDA0CgoKICAgUmljaGFyZCBP Z2llciBoYXMgcHJvcG9zZWQgdGhhdCB1bnJlbGlhYmxlIChwZXJpb2RpYykgb3BlcmF0aW9uIG1h eQogICBiZSBhIGh5YnJpZCBvcHRpb24gb2YgYW4gb3ZlcmFsbCByZWxpYWJsZSBtZWNoYW5pc20u ICBBIEJvZWluZwogICBzaW11bGF0aW9uIHN0dWR5IGRlc2NyaWJlZCBpbiBbN10gc3VnZ2VzdGVk IHRoYXQgaXQgbWF5IGJlIGRpZmZpY3VsdAogICB0byBjb3JyZWN0bHkgZXN0aW1hdGUgdGhlIG5l ZWQgdG8gYmUgaW4gb25lIG1vZGUgb3IgYW5vdGhlci4gIFNpbmNlCiAgIHRoYXQgdGltZSwgUmlj aGFyZCBPZ2llciBoYXMgcmV2aXNlZCBoaXMgcHJvcG9zYWwgaW4gdGhpcyByZWdhcmQsIGFzCiAg IGRpc2N1c3NlZCBpbiBTZWN0aW9uIDUgb2YgWzVdLiAgUmljaGFyZCdzIGN1cnJlbnQgcHJvcG9z YWwgaXMgbm90CiAgIGJhc2VkIG9uIHJlY2VpdmVyIHN1cHByZXNzaW9uIG9mIEFDS3MgYnV0IGlu c3RlYWQgaXMgc2VuZGVyLWJhc2VkIGFuZAogICBzdWdnZXN0cyBzZXR0aW5nIGEgbmV3IG9wdGlv biBiaXQgaW4gdGhlIGhlYWRlciB0byBtYWtlIHRoZSBMU0EKICAgIm5vbi1hY2thYmxlIiB3aXRo aW4gdGhlIHdpcmVsZXNzIGRvbWFpbiB3aGVuZXZlciBuZXcgTFNBcyBhcmUgYmVpbmcKICAgZ2Vu ZXJhdGVkIGZhc3QgZW5vdWdoIChpLmUuLCBjbG9zZSB0byBNaW5MU0ludGVydmFsKSwgd2l0aCBo eXN0ZXJlc2lzCiAgIGFwcGxpZWQgdG8gYXZvaWQgZmxhcHBpbmcgYmV0d2VlbiBtb2Rlcy4KCiAg IEJha2VyIHN1Z2dlc3RlZCB0aGUgdXNlIG9mIG5leHQtaG9wIHJlZmxvb2RpbmcgYXMgYW4gaW1w bGljaXQgQUNLIGluCiAgIFsxXSwgYWx0aG91Z2ggT2dpZXIgcG9pbnRlZCBvdXQgdGhhdCB0aGlz IG9ubHkgYXBwbGllZCB0byBub2RlcyBpbgogICB0aGUgcmVsYXkgc2V0OyBub24tcmVsYXkgbm9k ZXMgc3RpbGwgaGF2ZSB0byBBQ0suCgogICBJbiBTZWN0aW9uIDYgb2YgWzVdLCBSaWNoYXJkIE9n aWVyIHN1Z2dlc3RzIGEgcmVsaWFibGUgZmxvb2RpbmcKICAgdGVjaG5pcXVlIGJhc2VkIG9uIG1v ZGlmaWNhdGlvbiBvZiBEYXRhYmFzZSBEZXNjcmlwdGlvbiAoREQpIHBhY2tldHMuCiAgIEl0IGNh bGxzIGZvciBzcGVjaWFsIG5vZGVzIChlaXRoZXIgQ0RTIG5vZGVzIG9yIE1QUiBub2RlcykgdG8K ICAgcGVyaW9kaWNhbGx5IGJyb2FkY2FzdCBoZWFkZXJzIG9mIGFsbCB0aGUgTFNBcyBmb3Igd2hp Y2ggaXQgaXMKICAgcmVzcG9uc2libGUgZm9yIGZvcndhcmRpbmcsIGFuZCBmb3IgYWxsIG90aGVy IG5vZGVzIHRvIGJyb2FkY2FzdCBhIERECiAgIHBhY2tldCB3aXRoIHRoZSBoZWFkZXIgb2YgaXRz IG93biByb3V0ZXIgTFNBLiAgVGhpcyBpcyBpbiBjb250cmFzdCB0bwogICB1bnJlbGlhYmxlIGZs b29kaW5nIG9mIHRoZSBMU0FzIHRoZW1zZWx2ZXMuICBOb2RlcyB0aGF0IGRldGVjdCBhCiAgIG1p c3NpbmcgTFNBIGNhbiBzdGlsbCB1c2UgdGhlIExTUiB0byByZXF1ZXN0IGl0LCBhZnRlciBzb21l IGJhY2tvZmYKICAgdGltZS4gIFRoaXMgaXMgYW5hbG9nb3VzIHRvIElTLUlTIENvbXBsZXRlIFNl cXVlbmNlIE51bWJlciAoQ1NOKQogICBwYWNrZXRzIFsxMV0uICBUaGUgdGVjaG5pcXVlIGlzIGlu IGNvbnRyYXN0IHRvIHRoZSBPTFNSLWxpa2UgYXBwcm9hY2gKICAgaW4gdGhlIEJvZWluZyBwcm9w b3NhbCwgd2hpY2ggcGVyaW9kaWNhbGx5IHJlZmxvb2RzIGFsbCBMU0FzLgogICBWYXJpYXRpb25z IG9mIHRoaXMgYXBwcm9hY2ggYXJlIHBvc3NpYmxlIGFuZCBkaXNjdXNzZWQgYnkgUmljaGFyZAog ICBPZ2llciwgc3VjaCBhcyByZXBlYXRpbmcgdGhlIG9yaWdpbmFsIExTQSB0cmFuc21pc3Npb24g bXVsdGlwbGUKICAgdGltZXMsIG9yIENEUyByZWR1bmRhbmN5LiAgSU5SSUEgYWxzbyBwcm9wb3Nl ZCBzdWNoIGEgbWVjaGFuaXNtIG9mCiAgIHBlcmlvZGljIGluZm9ybWF0aW9uYWwgZGF0YWJhc2Ug c2lnbmF0dXJlIGJyb2FkY2FzdHMgaW4gWzZdLgoKICAgTGFzdCwgaXQgc2hvdWxkIGJlIHBvaW50 ZWQgb3V0IChhcyBSaWNoYXJkIGhhcykgdGhhdCB0aGUgc2VsZWN0aW9uIG9mCiAgIFJOUyBzZXRz IGlzIG5vdCBjb21wbGV0ZWx5IGluZGVwZW5kZW50IG9mIHRoZSBkZWNpc2lvbiB3aGV0aGVyIExT QQogICBkaXNzZW1pbmF0aW9uIGlzIHJlbGlhYmxlIG9yIHBlcmlvZGljLiAgQSBwdXJlbHkgT0xT Ui1zdHlsZSBNUFIgUk5TCiAgIGlzIHN1c2NlcHRpYmxlIHRvIHNvbWUgbG9zdCBwYWNrZXRzIHdo ZW4gdXNlZCBpbiBhIHJlbGlhYmxlIG1vZGUsCiAgIHVubGVzcyBub24tcmVsYXkgbm9kZXMgYXJl IHVzZWQgYXMgYmFja3VwcywgYXMgaXMgcHJvcG9zZWQgZm9yIHRoZQogICBDaXNjbyBvdmVybGFw cGluZyByZWxheXMgdGVjaG5pcXVlLgoKMy4zICBOZWlnaGJvciBkaXNjb3ZlcnkgYW5kIHN5bmNo cm9uaXphdGlvbgoKICAgVGhpcyBzZWN0aW9uIGRpc2N1c3NlcyB0aGUgcHJvY2VzcyBvZiBuZWln aGJvciBkaXNjb3ZlcnksIGFkamFjZW5jeQogICBmb3JtaW5nLCBhbmQgZGF0YWJhc2Ugc3luY2hy b25pemF0aW9uLgoKICAgSW4gYSBNQU5FVCwgdGhlIG51bWJlciBvZiBuZWlnaGJvcnMgY2FuIGJl Y29tZSBsYXJnZSwgY2F1c2luZwogICBxdWFkcmF0aWMgc2NhbGluZyBwcm9ibGVtcy4gIEZyZWQg QmFrZXIgc3VnZ2VzdHMgaW4gWzFdIHRoYXQgdGhlCiAgIG51bWJlciBvZiBhZGphY2VuY2llcyBt aWdodCBiZSByZWR1Y2VkLiAgTW9yZSByZWNlbnRseSwgdGhlIHByb3Bvc2FsCiAgIGJ5IENpc2Nv IGFkdm9jYXRlcyB0aGUgdXNlIG9mIGRpZmZlcmVudGlhbCBvciBpbmNyZW1lbnRhbCBIZWxsb3MK CgoKSGVuZGVyc29uIChlZC4pICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTMsIDIwMDUgICAgICAg ICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBTdW1tYXJ5IG9mIE1BTkVU IE9TUEYgUHJvcG9zYWxzICAgICAgICAgT2N0b2JlciAyMDA0CgoKICAgKGFsc28gc3VnZ2VzdGVk IGJ5IHRoZSBNQU5FVCBUQlJQRiBwcm90b2NvbCkuICBTb21lIHNpbXVsYXRpb25zCiAgIGNvbmR1 Y3RlZCBieSBCb2VpbmcgYW5kIGRpc2N1c3NlZCBpbiBbN10gc3VnZ2VzdCB0aGF0IGRpZmZlcmVu dGlhbAogICBIZWxsb3MgY29udHJpYnV0ZSBzZWNvbmQtb3JkZXIgc2F2aW5ncyBpbiBiYW5kd2lk dGgsIGJ1dCB0aGUgYmVuZWZpdHMKICAgbWlnaHQgYWN0dWFsbHkgYmUgbGFyZ2VyIHRoYW4gdGhv c2UgZGVzY3JpYmVkIGJ5IEJvZWluZyB3aGVuIHRoZQogICBuZXR3b3JrIGlzIHZlcnkgZGVuc2Uu ICBPbmUgcG90ZW50aWFsIGJlbmVmaXQgb2YgZGlmZmVyZW50aWFsIEhlbGxvcwogICBpcyB0aGF0 IHRoZSBIZWxsbyB0cmFuc21pc3Npb25zIGNhbiBiZSBhcGVyaW9kaWMuCgogICBGb3IgdGhlIHNh bWUgcmVhc29uIHRoYXQgZGlmZmVyZW50aWFsIEhlbGxvcyBtaWdodCBiZSB1c2VmdWwsIHNvIHRv bwogICBtaWdodCBhIHJlZHVjdGlvbiBpbiB0aGUgbnVtYmVyIG9mIG5laWdoYm9ycyB3aXRoIHdo aWNoIGEgTUFORVQgbm9kZQogICBiZWNvbWVzIGFkamFjZW50LiAgT1NQRiBkb2VzIHRoaXMgYWxy ZWFkeSBmb3IgYnJvYWRjYXN0IGludGVyZmFjZXMuCiAgIEZyZWQgQmFrZXIgaW4gWzFdIHN1Z2dl c3RlZCB0aGF0IG5vZGVzIG1pZ2h0IHdhbnQgdG8gbGltaXQgdGhlIG51bWJlcgogICBvZiBuZWln aGJvcnMuICBSaWNoYXJkIE9naWVyIGluIFs1XSBhbHNvIHN1Z2dlc3RlZCB0aGF0IGlmIHRoZXJl IGFyZQogICBzcGVjaWFsIG5vZGVzIHN1Y2ggYXMgTXVsdGlwb2ludCBSZWxheXMgKE1QUnMpIGFu ZCBDb25uZWN0ZWQKICAgRG9taW5hdGluZyBTZXRzIChDRFMpIGluIHRoZSBuZXR3b3JrLCB0aGF0 IG5vbi1yZWxheSBub2RlcyBtaWdodCB3YW50CiAgIHRvIHN5bmNocm9uaXplIG9ubHkgd2l0aCB0 aGVzZSByZWxheSBub2RlcyAoT2dpZXIgcmVkZWZpbmVkIHRoZQogICBjb25jZXB0IG9mIGFkamFj ZW5jeSBpbiB0aGlzIGNvbnRleHQpLiAgV2hlbiB1c2luZyB1bnJlbGlhYmxlCiAgIGZsb29kaW5n IGFzIGluIFszXSwgbm8gZGF0YWJhc2Ugc3luY2hyb25pemF0aW9uIG9jY3Vyczsgbm9kZXMgZG8g bm90CiAgIHByb2dyZXNzIHBhc3Qgc3RhdGUgMi1XYXkgb24gYSBNQU5FVCBpbnRlcmZhY2UuCgog ICBUYWtpbmcgdGhlIHN5bmNocm9uaXphdGlvbiBwcm9jZXNzIGEgc3RlcCBmdXJ0aGVyLCBUaG9t YXMgQ2xhdXNlbiBhbmQKICAgSU5SSUEgc3VnZ2VzdGVkIGluIFs2XSB0aGF0IGEgbXVjaCBtb3Jl IGNvbXBhY3QgcmVwcmVzZW50YXRpb24gb2YKICAgT1NQRiBkYXRhYmFzZXMgdGhhbiBhbiBlbnVt ZXJhdGlvbiBvZiBMU0EgaGVhZGVycyBtaWdodCBiZSBwb3NzaWJsZQogICB1c2luZyBzaWduYXR1 cmVzIChoYXNoZXMpIG9mIHBhcnRzIG9mIHRoZSBPU1BGIGRhdGFiYXNlLiAgRm9yCiAgIGV4YW1w bGUsIG5vZGVzIGNvdWxkIGNvbXBhcmUgdG9wLWxldmVsIHNpZ25hdHVyZXMgb2YgdGhlaXIgZGF0 YWJhc2UsCiAgIGFuZCBvbmx5IGlmIHRoZXkgZGlmZmVyZWQgd291bGQgYWRkaXRpb25hbCBzaWdu YXR1cmVzIHN0YXJ0IHRvIGJlCiAgIGNvbXBhcmVkLCB1bnRpbCB0aGUgZGlzY3JlcGFuY3kgd2Fz IG5hcnJvd2VkIGRvd24uICBUaGUgZHJhZnQKICAgZGVzY3JpYmVzIGFuIGFsZ29yaXRobSBjYWxs ZWQgVHVuc3RhbGwgU3BsaXR0aW5nIHRvIGdlbmVyYXRlIHByZWZpeAogICBzaWduYXR1cmVzIG9m IGRpZmZlcmVudCBwYXJ0cyBvZiB0aGUgZGF0YWJhc2UsIHdoaWNoIGNhbiBiZSBmdXJ0aGVyCiAg IHNlZ3JlZ2F0ZWQgYnkgYWdlIG9mIHRoZSBMU0FzLgoKMy40ICBPdGhlcgoKICAgRm9yIG5vdywg dGhpcyBpcyBhIGNvbGxlY3Rpb24gb2YgbWlzY2VsbGFuZW91cyBzdWdnZXN0aW9ucyB0aGF0IGNh bgogICBiZSBjb25zaWRlcmVkIGZvciBwYXJ0IG9mIHRoZSBkZXNpZ24gKGVpdGhlciBpbml0aWFs IGRlc2lnbiBvciBuZXh0CiAgIHBoYXNlKS4KCiAgIFNlY3Rpb24gMi4zLjggb2YgWzRdIGRlc2Ny aWJlcyBjaGFuZ2VzIHRvIHN1cHBvcnQgT1NQRiBHcmFjZWZ1bAogICBSZXN0YXJ0LgoKICAgU2Vj dGlvbiA2LjQgb2YgUmljaGFyZCBPZ2llcidzIGRyYWZ0IHN1Z2dlc3RzIHRoZSB1c2Ugb2YgZGlm ZmVyZW50aWFsCiAgIExTQXMsIGFuZCBhIHNsaWdodCBtb2RpZmljYXRpb24gb2YgdGhlIExTIFJl cXVlc3QgcGFja2V0IHRvIGluZGljYXRlCiAgIHRoZSBzZXF1ZW5jZSBudW1iZXIgb2YgdGhlIGlu c3RhbmNlIG9mIHRoZSBMU0EgaW4gdGhlIG5vZGUncwogICBkYXRhYmFzZS4KCiAgIEZyZWQgQmFr ZXIgaW4gWzFdIHN1Z2dlc3RlZCB0aGF0LCBpbiBhIGRlbnNlIG5ldHdvcmssIE9TUEYgcm91dGVy cwogICBtYXkgd2FudCB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIGFkamFjZW5jaWVzLCBwZXJoYXBz IGJ5IGxpbWl0aW5nIHRoZQogICBuZWlnaGJvciByZWxhdGlvbnNoaXBzIHRvIHRob3NlIHJvdXRl cnMgd2l0aCB0aGUgbG93ZXN0IG1ldHJpY3Mgb3IKICAgaGlnaGVzdCB3aWxsaW5nbmVzcyB0byBj b25uZWN0LgoKCgpIZW5kZXJzb24gKGVkLikgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxMywgMjAw NSAgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgIFN1bW1hcnkg b2YgTUFORVQgT1NQRiBQcm9wb3NhbHMgICAgICAgICBPY3RvYmVyIDIwMDQKCgogICBCbyBCZXJy eSBvZiBDaXNjbyBoYXMgcHVibGlzaGVkIGEgcmVsYXRlZCBkcmFmdCBbOF0gdGhhdCBkZXNjcmli ZXMgYQogICBQUFBvRSBwcm90b2NvbCBiZXR3ZWVuIGEgcm91dGVyIGFuZCBhbiBleHRlcm5hbCBy YWRpbywgZm9yIHRoZQogICBwdXJwb3NlIG9mIHBlcmZvcm1pbmcgZmxvdyBjb250cm9sIGFuZCBj b252ZXlpbmcgbGluayBtZXRyaWNzIGZyb20KICAgdGhlIHJhZGlvIHRvIHRoZSByb3V0ZXIuCgog ICBUaGUgT1NQRiBNQU5FVCBwcm9ibGVtIHN0YXRlbWVudCBbMl0gZGlzY3Vzc2VzIHRoZSBwb3Rl bnRpYWwgZm9yCiAgIGxpbWl0ZWQgdHJhbnNtaXQgb3BlcmF0aW9uLCBhIHNwZWNpYWwgY2FzZSBv ZiB3aGljaCBpcyBkZW1hbmQgY2lyY3VpdAogICBvcGVyYXRpb24uICBUZWNobmlxdWVzIHRvIG1p bmltaXplIHRoZSBudW1iZXIgb2YgdW5uZWNlc3NhcnkKICAgdHJhbnNtaXNzaW9ucyBzdWNoIGFz IGRlc2NyaWJlZCBtYXkgYmUgYW4gYXJlYSBmb3IgZnVydGhlcgogICBleHBsb3JhdGlvbiwgYWx0 aG91Z2ggbm8gc3BlY2lmaWMgcHJvcG9zYWxzIGhhdmUgYmVlbiBzdWJtaXR0ZWQuCiAgIExpbWl0 ZWQgdHJhbnNtaXQgb3IgZGVtYW5kIGNpcmN1aXQgb3BlcmF0aW9uIChCYWtlcikKCiAgIFJlbGF0 ZWQgdG8gdGhpcywgdGhlIE1BTkVUIHByb2JsZW0gc3RhdGVtZW50IGFsc28gZGlzY3Vzc2VkIHRo ZQogICBwb3RlbnRpYWwgbmVlZCBmb3IgcG93ZXIgbWFuYWdlbWVudCBjb25zaWRlcmF0aW9uczsg c3BlY2lmaWNhbGx5LCB0aGUKICAgd2lsbGluZ25lc3Mgb2YgYSBub2RlIHRvIHJlbGF5IG1lc3Nh Z2VzIHdoZW4gaXRzIGJhdHRlcnkgaXMgbG93LgogICBNQU5FVCByb3V0aW5nIHByb3RvY29scyBz dWNoIGFzIE9MU1IgaGF2ZSBhZGRlZCBhIGZlYXR1cmUgY2FsbGVkCiAgICJ3aWxsaW5nbmVzcyIg dGhhdCBpbmZsdWVuY2VzIHRoZSBwcm9iYWJpbGl0eSB0aGF0IGEgbm9kZSB3aWxsIGJlCiAgIHNl bGVjdGVkIGFzIGEgcmVsYXkgbm9kZS4gIFRoZSBDaXNjbyBwcm9wb3NhbCBhbHNvIGluY2x1ZGVz IGEKICAgV2lsbGluZ25lc3MgVExWLgoKICAgQm90aCBGcmVkIEJha2VyJ3Mgb3JpZ2luYWwgZHJh ZnQgYW5kIHRoZSBNQU5FVCBwcm9ibGVtIHN0YXRlbWVudAogICAoWzFdLCBbMl0pIGRpc2N1c3Mg dGhlIGNvbmNlcHQgb2YgYXJlYSBtb2JpbGl0eSAoYSBtb2RlbCB0aGF0IHBlcm1pdHMKICAgYXJl YXMgdG8gZXhjaGFuZ2Ugc3VtbWFyeSBMU0FzIGF0IGFueSBib3VuZGFyeSkuICBTZWN0aW9uIDQu NC4xIG9mCiAgIFsxXSB3YWxrcyB0aHJvdWdoIGEgc3RyYXdtYW4gZGVzaWduIG9mIE9TUEYgbW9k aWZpY2F0aW9ucyB0byBhbGxvdwogICByb3V0ZXJzIHRvIHJvYW0gYmV0d2VlbiBhcmVhcy4KCiAg IFRoZSBNQU5FVCBjb21tdW5pdHkgaGFzIG9ic2VydmVkIHRoZSBiZW5lZml0IG9mIGppdHRlcmlu ZyBvcgogICBkZWNvcnJlbGF0aW5nIHJhZGlvIHRyYW5zbWlzc2lvbnMgb24gYSBicm9hZGNhc3Qg Y2hhbm5lbCwgYW5kIHRoaXMKICAgdG9waWMgaGFzIGJlZW4gYWxzbyBkaXNjdXNzZWQgaW4gWzFd LgoKICAgRnJlZCBCYWtlcidzIE1BTkVUIHJldmlldyBzdWdnZXN0ZWQgdGhlIHBvc3NpYmlsaXR5 IG9mIGNvbXBvc2l0ZSBsaW5rCiAgIG1ldHJpY3M7IGUuZy4sIG1ldHJpY3MgdGhhdCBhcmUgYSBm dW5jdGlvbiBvZiBwb2xpY3ksIGxpbmsgcXVhbGl0eSwKICAgYW5kIHRocm91Z2hwdXQuICBPc2Np bGxhdGlvbiBvZiBzdWNoIGR5bmFtaWMgbGluayBtZXRyaWNzIGlzIGEKICAgcHJvYmxlbWF0aWMg Y29uc2lkZXJhdGlvbiAoQVJQQU5FVCBmbGFwcGluZyBmcm9tIHRoZSAxOTgwcyksIGFuZAogICBo eXN0ZXJlc2lzIHdvdWxkIG5lZWQgdG8gYmUgYXBwbGllZCBhbHNvIHRvIGxpbWl0IHRoZSBnZW5l cmF0aW9uIG9mCiAgIG5ldyBMU0FzLiAgVGhlIHF1YWxpdHkgb2YgdGhlIGxpbmsgKG5laWdoYm9y IHJlbGF0aW9uc2hpcHMpIG5lZWRzIHRvCiAgIGJlIGF2YWlsYWJsZSBmcm9tIGFuIEFQSSwgc3Vj aCBhcyBkaXNjdXNzZWQgaW4gWzhdLiAgVGhlIENpc2NvCiAgIHByb3Bvc2FsIGZhdm9ycyB0aGUg Y2FwYWJpbGl0eSBvZiBzZXR0aW5nIG1ldHJpY3Mgb24gYSBwZXItbmVpZ2hib3IKICAgYmFzaXMu ICBJdCBpcyBub3QgY2xlYXIgaG93IG11Y2ggb2YgY29tcG9zaXRlIGxpbmsgbWV0cmljcyBhbmQK ICAgbGF5ZXItMi8zIEFQSXMgZm9yIGxpbmsgcXVhbGl0eSBuZWVkIHRvIGJlIHN0YW5kYXJkaXpl ZC4KCiAgIEZpbmFsbHksIEpvZSBNYWNrZXIncyBncm91cCBhdCBOUkwgaGFzIGxvb2tlZCBhdCB0 aGUgcG9zc2libGUKICAgY29tYmluYXRpb24gb2YgbXlvcGljIChlLmcuLCAiZmlzaGV5ZSIpIExT QSBkaXNzZW1pbmF0aW9uIHRlY2huaXF1ZXMKICAgaW4gYWRkaXRpb24gdG8gZWZmaWNpZW50IGRp c3RyaWJ1dGlvbiB0cmVlcywgYW5kIGhhcyBwcmVzZW50ZWQgc29tZQogICBldmlkZW5jZSB0aGF0 IHRoZXNlIGZsb29kaW5nIHRlY2huaXF1ZXMgbWlnaHQgcHJvdmlkZSBhZGRpdGlvbmFsCiAgIGJh bmR3aWR0aCBlZmZpY2llbmN5IGdhaW5zLiAgVHlwaWNhbGx5LCBlZmZpY2llbnQgcmVsYXkgbm9k ZSBzZXRzCiAgIHN1Y2ggYXMgTVBScyBpbXByb3ZlIHNjYWxhYmlsaXR5IGluIHRlcm1zIG9mIGRl bnNpdHksIHdoaWxlIG15b3BpYwogICBzdHJhdGVnaWVzIGltcHJvdmUgdGhlIHNjYWxhYmlsaXR5 IGluIHRlcm1zIG9mIGRpYW1ldGVyLiAgVGhpcyB3b3JrCgoKCkhlbmRlcnNvbiAoZWQuKSAgICAg ICAgICBFeHBpcmVzIEFwcmlsIDEzLCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDE0XQoMCklu dGVybmV0LURyYWZ0ICAgICAgU3VtbWFyeSBvZiBNQU5FVCBPU1BGIFByb3Bvc2FscyAgICAgICAg IE9jdG9iZXIgMjAwNAoKCiAgIHdhcyBkb25lIGluIHRoZSBjb250ZXh0IG9mIHVucmVsaWFibGUg Zmxvb2RpbmcsIGFuZCBpdCBpcyBub3QgY2xlYXIKICAgaG93IGl0IG1pZ2h0IHRyYW5zbGF0ZSB0 byByZWxpYWJsZSBmbG9vZGluZy4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCkhlbmRlcnNvbiAoZWQuKSAgICAgICAgICBFeHBpcmVzIEFwcmlsIDEzLCAy MDA1ICAgICAgICAgICAgICAgIFtQYWdlIDE1XQoMCkludGVybmV0LURyYWZ0ICAgICAgU3VtbWFy eSBvZiBNQU5FVCBPU1BGIFByb3Bvc2FscyAgICAgICAgIE9jdG9iZXIgMjAwNAoKCjQuICBBY2tu b3dsZWRnbWVudHMKCiAgIFRoZSBlZGl0b3Igd291bGQgbGlrZSB0byB0aGFuayBQaGlsIFNwYWdu b2xvIGFuZCBHYXJ5IFBlaSBmb3IKICAgc3VnZ2VzdGlvbnMgdG8gdGhpcyBkcmFmdC4KCjUgIFJl ZmVyZW5jZXMKCiAgIFsxXSAgIEJha2VyLCBGLiwgIkFuIG91dHNpZGVyJ3MgdmlldyBvZiBNQU5F VCIsCiAgICAgICAgIGRyYWZ0LWJha2VyLW1hbmV0LXJldmlldy0wMSAod29yayBpbiBwcm9ncmVz cyksIE1hcmNoIDIwMDIuCgogICBbMl0gICBCYWtlciwgRi4sICJQcm9ibGVtIFN0YXRlbWVudCBm b3IgT1NQRiBFeHRlbnNpb25zIGZvciBNb2JpbGUgQWQKICAgICAgICAgSG9jIFJvdXRpbmciLCBk cmFmdC1iYWtlci1tYW5ldC1vc3BmLXByb2JsZW0tc3RhdGVtZW50LTAwICh3b3JrCiAgICAgICAg IGluIHByb2dyZXNzKSwgT2N0b2JlciAyMDAzLgoKICAgWzNdICAgQWhyZW5ob2x6LCBKLiwgIk9T UEZ2MiBXaXJlbGVzcyBJbnRlcmZhY2UgVHlwZSIsCiAgICAgICAgIGRyYWZ0LXNwYWdub2xvLW1h bmV0LW9zcGYtd2lyZWxlc3MtaW50ZXJmYWNlLTAxICh3b3JrIGluCiAgICAgICAgIHByb2dyZXNz KSwgTWF5IDIwMDQuCgogICBbNF0gICBDaGFuZHJhLCBNLiwgIkV4dGVuc2lvbnMgdG8gT1NQRiB0 byBTdXBwb3J0IE1vYmlsZSBBZCBIb2MKICAgICAgICAgTmV0d29ya2luZyIsIGRyYWZ0LWNoYW5k cmEtb3NwZi1tYW5ldC1leHQtMDEgKHdvcmsgaW4KICAgICAgICAgcHJvZ3Jlc3MpLCBKdWx5IDIw MDQuCgogICBbNV0gICBPZ2llciwgUi4sICJBbHRlcm5hdGl2ZSBEZXNpZ25zIGZvciBPU1BGIEV4 dGVuc2lvbnMgZm9yIE1vYmlsZQogICAgICAgICBBZCBIb2MgTmV0d29ya3MiLCBkcmFmdC1vZ2ll ci1tYW5ldC1vc3BmLWV4dGVuc2lvbi0wMSAod29yayBpbgogICAgICAgICBwcm9ncmVzcyksIEp1 bHkgMjAwNC4KCiAgIFs2XSAgIENsYXVzZW4sIFQuLCAiREIgRXhjaGFuZ2UgZm9yIE9TUEZ2MiBX aXJlbGVzcyBJbnRlcmZhY2UgVHlwZSIsCiAgICAgICAgIGRyYWZ0LWNsYXVzZW4tbWFuZXQtb3Nw Zi1kYngtMDAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBGZWJydWFyeQogICAgICAgICAyMDA0LgoKICAg WzddICAgU3BhZ25vbG8sIFAuLCAiRGVzaWduIENvbnNpZGVyYXRpb25zIGZvciBhIFdpcmVsZXNz IE9TUEYKICAgICAgICAgSW50ZXJmYWNlIiwgZHJhZnQtc3BhZ25vbG8tbWFuZXQtb3NwZi1kZXNp Z24gKHdvcmsgaW4KICAgICAgICAgcHJvZ3Jlc3MpLCBBcHJpbCAyMDA0LgoKICAgWzhdICAgQmVy cnksIEIuIGFuZCBILiBIb2xnYXRlLCAiUFBQIE92ZXIgRXRoZXJlbnQgKFBQUG9FKSBFeHRlbnNp b25zCiAgICAgICAgIGZvciBDcmVkaXQgRmxvdyBhbmQgTGluayBNZXRyaWNzIiwgZHJhZnQtYmJl cnJ5LXBwcG9lLWNyZWRpdC0wMQogICAgICAgICAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDIw MDQuCgogICBbOV0gICBBZGppaCwgQy4sIEphY3F1ZXQsIFAuIGFuZCBMLiBWaWVubm90LCAiQ29t cHV0aW5nIGNvbm5lY3RlZAogICAgICAgICBkb21pbmF0ZWQgc2V0cyB3aXRoIG11bHRpcG9pbnQg cmVsYXlzIiwgVGVjaG5pY2FsIFJlcG9ydCA0NTk3LAogICAgICAgICBPY3RvYmVyIDIwMDIuCgog ICBbMTBdICBPZ2llciwgUi4sICJJRVRGIE1BTkVUIG1haWxpbmcgbGlzdDoKICAgICAgICAgaHR0 cDovL3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dvcmtpbmctZ3JvdXBzL21hbmV0L2N1cnJl bnQvbXNnMDQyMTYuaHRtbCIKICAgICAgICAgLCBNYXJjaCAyMDA0LgoKICAgWzExXSAgT3Jhbiwg RC4sICJPU0kgSVMtSVMgSW50cmEtZG9tYWluIFJvdXRpbmcgUHJvdG9jb2wiLCBSRkMgMTE0MiwK ICAgICAgICAgRmVicnVhcnkgMTk5MC4KCgoKSGVuZGVyc29uIChlZC4pICAgICAgICAgIEV4cGly ZXMgQXByaWwgMTMsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICBTdW1tYXJ5IG9mIE1BTkVUIE9TUEYgUHJvcG9zYWxzICAgICAgICAgT2N0b2JlciAy MDA0CgoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgVG9tIEhlbmRlcnNvbgogICBCb2VpbmcgUGhhbnRv bSBXb3JrcwogICBQLk8uIEJveCAzNzA3LCBNQyA3TC00OQogICBTZWF0dGxlLCBXQSAgOTgxMjQK ICAgVVNBCgogICBQaG9uZTogKzEgNDI1IDg2NSAzNjA5CiAgIEVNYWlsOiB0aG9tYXMuci5oZW5k ZXJzb25AYm9laW5nLmNvbQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CkhlbmRlcnNvbiAoZWQuKSAgICAgICAgICBFeHBpcmVzIEFwcmlsIDEzLCAyMDA1ICAgICAgICAg ICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURyYWZ0ICAgICAgU3VtbWFyeSBvZiBNQU5FVCBP U1BGIFByb3Bvc2FscyAgICAgICAgIE9jdG9iZXIgMjAwNAoKCkludGVsbGVjdHVhbCBQcm9wZXJ0 eSBTdGF0ZW1lbnQKCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUg dmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55CiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMg b3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bwogICBwZXJ0YWluIHRvIHRo ZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluCiAg IHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBz dWNoIHJpZ2h0cwogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBp dCByZXByZXNlbnQgdGhhdCBpdCBoYXMKICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRv IGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uCiAgIG9uIHRoZSBwcm9jZWR1 cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUKICAgZm91 bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1h ZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQogICBhc3N1cmFuY2VzIG9mIGxpY2Vu c2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuCiAgIGF0dGVtcHQg bWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVz ZSBvZgogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMg b2YgdGhpcwogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9u LWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuCgogICBU aGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRl bnRpb24gYW55CiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywg b3Igb3RoZXIgcHJvcHJpZXRhcnkKICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kg dGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50CiAgIHRoaXMgc3RhbmRhcmQuICBQbGVh c2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQKICAgaWV0Zi1pcHJAaWV0 Zi5vcmcuCgoKRGlzY2xhaW1lciBvZiBWYWxpZGl0eQoKICAgVGhpcyBkb2N1bWVudCBhbmQgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuCiAgICJBUyBJ UyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQ UkVTRU5UUwogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJ RVRZIEFORCBUSEUgSU5URVJORVQKICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBB TEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELAogICBJTkNMVURJTkcgQlVUIE5PVCBM SU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFCiAgIElORk9STUFUSU9O IEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVECiAgIFdB UlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ VVJQT1NFLgoKCkNvcHlyaWdodCBTdGF0ZW1lbnQKCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVy bmV0IFNvY2lldHkgKDIwMDQpLiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0CiAgIHRvIHRoZSBy aWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwgYW5k CiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0 aGVpciByaWdodHMuCgoKQWNrbm93bGVkZ21lbnQKCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRp dG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUKICAgSW50ZXJuZXQgU29j aWV0eS4KCgoKCkhlbmRlcnNvbiAoZWQuKSAgICAgICAgICBFeHBpcmVzIEFwcmlsIDEzLCAyMDA1 ICAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCg== ------_=_NextPart_001_01C4B13B.136593E4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design ------_=_NextPart_001_01C4B13B.136593E4-- From ospf-wireless-design-bounces@ietf.org Fri Oct 22 12:30:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18405; Fri, 22 Oct 2004 12:30:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2WE-0001g5-HS; Fri, 22 Oct 2004 12:43:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2EC-0002Cz-9H; Fri, 22 Oct 2004 12:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2A3-0001Dq-93 for ospf-wireless-design@megatron.ietf.org; Fri, 22 Oct 2004 12:21:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17754 for ; Fri, 22 Oct 2004 12:20:59 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2Mp-0001Y1-Mc for ospf-wireless-design@ietf.org; Fri, 22 Oct 2004 12:34:18 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BFE0B9E8AB0; Fri, 22 Oct 2004 09:20:54 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01499-01; Fri, 22 Oct 2004 09:20:54 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.74]) by prattle.redback.com (Postfix) with SMTP id A96B49E8AB2; Fri, 22 Oct 2004 09:20:53 -0700 (PDT) Message-ID: <0b0601c4b853$151ec170$0202a8c0@aceeinspiron> From: "Acee Lindem" To: "Henderson, Thomas R" , References: <6938661A6EDA8A4EA8D1419BCE46F24C0452271F@xch-nw-27.nw.nos.boeing.com> Subject: Re: [Ospf-wireless-design] new material to review and discuss Date: Fri, 22 Oct 2004 12:20:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Tom, Can we schedule a OSPF wireless design update for the Washington IETF? What I think would be good would be a presentation on the attached document with ample time for WG questions. Did anybody else have anything relevant to the OSPF wireless effort that they wanted to present in Washington? I've had a lot going on lately and realized today that time is running short. Thanks, Acee ----- Original Message ----- From: "Henderson, Thomas R" To: Sent: Wednesday, October 13, 2004 11:41 AM Subject: [Ospf-wireless-design] new material to review and discuss All, I have attached a revised version of the wireless design team document. I am trying to use this to document agreements and discussion points raised in the drafts and the mailing lists. In particular, I have added a section 1.2 that lists the items that the group agrees upon. Can people please review this section and see whether there is any objection to removing the "pending" status to any of these topics? (I will interpret silence on the list as acquiescence). If we can move past those items, the next topic I would like to focus on is the flooding discussion-- in particular, the issue of MPR vs. CDS that has never been resolved adequately in my opinion. Please read Section 3.2 carefully, as it has been substantially rewritten, and let the list know of your agreements and disagreements to what is written there. Thanks, Tom -------------------------------------------------------------------------------- > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 22 13:30:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23069; Fri, 22 Oct 2004 13:30:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3Sa-0002nJ-M3; Fri, 22 Oct 2004 13:44:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL39N-0004CD-R0; Fri, 22 Oct 2004 13:24:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL30B-0001kb-TM for ospf-wireless-design@megatron.ietf.org; Fri, 22 Oct 2004 13:14:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21512 for ; Fri, 22 Oct 2004 13:14:51 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3Cz-0002Tm-GK for ospf-wireless-design@ietf.org; Fri, 22 Oct 2004 13:28:11 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA05643; Fri, 22 Oct 2004 10:14:18 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9MHEID25927; Fri, 22 Oct 2004 10:14:18 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 10:14:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ospf-wireless-design] new material to review and discuss Date: Fri, 22 Oct 2004 10:14:12 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Ospf-wireless-design] new material to review and discuss Thread-Index: AcS4Ux2c8XBCRw72Ra+KImDW/tKOWgABpiZQ From: "Henderson, Thomas R" To: "Acee Lindem" , X-OriginalArrivalTime: 22 Oct 2004 17:14:12.0879 (UTC) FILETIME=[8D3429F0:01C4B85A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Yes, I could give a short update at the IETF meeting. Perhaps my document was a bit much for people to digest last week, but = in a nutshell, I would like to come to agreement on the following = points: - Design team adopts problem statement as modified by design team list = discussions - Design team focuses on defining a MANET interface type, not a MANET = area type. =20 - Design team focuses first on defining an optimized flooding mechanism = for LSA dissemination. - Design team focuses on acknowledged (reliable) flooding, leaving = periodic flooding as a future optimization. and having done so, I would like to consider as a next step the = tradeoffs between MPRs and CDS as the relay node set used for flooding = (which is described in much detail in Section 3.2 of the draft that I = sent around). Tom > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com]=20 > Sent: Friday, October 22, 2004 9:21 AM > To: Henderson, Thomas R; ospf-wireless-design@ietf.org > Cc: Rohit Dube > Subject: Re: [Ospf-wireless-design] new material to review and discuss >=20 >=20 > Tom,=20 >=20 > Can we schedule a OSPF wireless design update for the Washington=20 > IETF? What I think would be good would be a presentation on the > attached document with ample time for WG questions.=20 >=20 > Did anybody else have anything relevant to the OSPF wireless=20 > effort that > they wanted to present in Washington? I've had a lot going on lately > and realized today that time is running short.=20 >=20 > Thanks, > Acee >=20 _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 22 14:05:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25363; Fri, 22 Oct 2004 14:05:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL408-0003QS-B7; Fri, 22 Oct 2004 14:18:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3ge-0006Sl-AX; Fri, 22 Oct 2004 13:58:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3db-0005Tm-O6 for ospf-wireless-design@megatron.ietf.org; Fri, 22 Oct 2004 13:55:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24718 for ; Fri, 22 Oct 2004 13:55:37 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3qP-0003Es-Oy for ospf-wireless-design@ietf.org; Fri, 22 Oct 2004 14:08:55 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9DBF96817E0 for ; Fri, 22 Oct 2004 10:55:33 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03943-03 for ; Fri, 22 Oct 2004 10:55:33 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.99]) by prattle.redback.com (Postfix) with SMTP id 744786817DB for ; Fri, 22 Oct 2004 10:55:32 -0700 (PDT) Message-ID: <0b1b01c4b860$4d968da0$0202a8c0@aceeinspiron> From: "Acee Lindem" To: References: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> Subject: Re: [Ospf-wireless-design] new material to review and discuss Date: Fri, 22 Oct 2004 13:55:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Here is my take... > Yes, I could give a short update at the IETF meeting. > > Perhaps my document was a bit much for people to digest last week, but in a nutshell, I would like to come to agreement on the > following points: > > - Design team adopts problem statement as modified by design team list discussions Agreed. However, I think it is still extended work plan is still open for debate. Do we need to change/optimize additional OSPF mechanisms for wireless (e.g., database exchange). Possibly, there be a better other mechanisms or policies that would yield more bang-for-the-buck. > - Design team focuses on defining a MANET interface type, not a MANET area type. I think that since all the work done heretofore has been based on the MANET interface type we need to stick with it. I know there have been suggestions that the OSPF area might be a better boundary for flooding changes (I think I may have said this ;^). However, there are no proposals on the table. > - Design team focuses first on defining an optimized flooding mechanism for LSA dissemination. Agreed. > - Design team focuses on acknowledged (reliable) flooding, leaving periodic flooding as a future optimization. Agreed. > > and having done so, I would like to consider as a next step the tradeoffs between MPRs > and CDS as the relay node set used for flooding (which is described in much detail in Section 3.2 of the draft that I sent > around). Tom > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com] > Sent: Friday, October 22, 2004 9:21 AM > To: Henderson, Thomas R; ospf-wireless-design@ietf.org > Cc: Rohit Dube > Subject: Re: [Ospf-wireless-design] new material to review and discuss > > > Tom, > > Can we schedule a OSPF wireless design update for the Washington > IETF? What I think would be good would be a presentation on the > attached document with ample time for WG questions. > > Did anybody else have anything relevant to the OSPF wireless > effort that > they wanted to present in Washington? I've had a lot going on lately > and realized today that time is running short. > > Thanks, > Acee > _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 22 14:06:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25482; Fri, 22 Oct 2004 14:06:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL417-0003Rs-DF; Fri, 22 Oct 2004 14:19:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3nR-0000Ns-Pa; Fri, 22 Oct 2004 14:05:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3jS-0007DC-DG for ospf-wireless-design@megatron.ietf.org; Fri, 22 Oct 2004 14:01:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25147 for ; Fri, 22 Oct 2004 14:01:39 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3wG-0003Lh-Bm for ospf-wireless-design@ietf.org; Fri, 22 Oct 2004 14:14:57 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA05865; Fri, 22 Oct 2004 11:01:05 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9MI14s19164; Fri, 22 Oct 2004 11:01:04 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 11:01:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ospf-wireless-design] new material to review and discuss Date: Fri, 22 Oct 2004 11:01:02 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C045227BF@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Ospf-wireless-design] new material to review and discuss Thread-Index: AcS4XkRtlZRzd1EZQoudKdEskSc80QAAnXTA From: "Henderson, Thomas R" To: "Joe Macker" X-OriginalArrivalTime: 22 Oct 2004 18:01:03.0172 (UTC) FILETIME=[1844D840:01C4B861] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 > Sent: Friday, October 22, 2004 10:41 AM > To: Acee Lindem > Cc: Henderson, Thomas R; ospf-wireless-design@ietf.org > Subject: Re: [Ospf-wireless-design] new material to review and discuss >=20 >=20 > > If we can move past those items, the next topic I would like > > to focus on is the flooding discussion-- in particular, the > > issue of MPR vs. CDS that has never been resolved adequately > > in my opinion. Please read Section 3.2 carefully, as it has > > been substantially rewritten, and let the list know of your > > agreements and disagreements to what is written there. > >=20 >=20 > Tom: >=20 > Sorry I'm jumping ahead here, but in preparation for=20 > discussion of MPR=20 > vs.CDS, I'd like to clarify a few issues, especially the terminology. >=20 > MPR is a heuristic algorithm that forms a "source specific"=20 > CDS. So it=20 > is a CDS algorithm. So are we talking about "other" CDS=20 > algorithms like=20 > Wu and Li have proposed,etc. I just want to get the=20 > terminology straight=20 > so I know what we are talking about. For example, are we=20 > talking about=20 > a shared tree CDS algorithms, different election heuristics for=20 > forwarding sets, dynamic robustness issues, complexity tradeoffs... Yes, I mean source-independent vs. source dependent. Please see the writeup in the draft that I circulated. >=20 > There are existing empirical and analytical studies that we=20 > can look at=20 > and discuss. >=20 Please point us to such studies that you are aware of. I have the paper by Wu and Li and can share it with anyone who is interested. Tom _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 22 19:37:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13956; Fri, 22 Oct 2004 19:37:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9BT-0000kt-Pi; Fri, 22 Oct 2004 19:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8o7-0001TO-HI; Fri, 22 Oct 2004 19:26:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8fz-0003CI-NX for ospf-wireless-design@megatron.ietf.org; Fri, 22 Oct 2004 19:18:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12303 for ; Fri, 22 Oct 2004 19:18:25 -0400 (EDT) Received: from postfix3-1.free.fr ([213.228.0.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8su-0000Hb-Aq for ospf-wireless-design@ietf.org; Fri, 22 Oct 2004 19:31:48 -0400 Received: from imp3-q.free.fr (imp3-q.free.fr [212.27.42.3]) by postfix3-1.free.fr (Postfix) with ESMTP id D21A7173494; Sat, 23 Oct 2004 01:18:24 +0200 (CEST) Received: by imp3-q.free.fr (Postfix, from userid 33) id 7C3B72A25F; Sat, 23 Oct 2004 01:18:24 +0200 (MEST) Received: from ZH111047.ppp.dion.ne.jp (ZH111047.ppp.dion.ne.jp [222.3.111.47]) by imp3-q.free.fr (IMP) with HTTP for ; Sat, 23 Oct 2004 01:18:24 +0200 Message-ID: <1098487104.4179954065301@imp3-q.free.fr> Date: Sat, 23 Oct 2004 01:18:24 +0200 From: Thomas Heide Clausen To: "Henderson, Thomas R" Subject: RE: [Ospf-wireless-design] new material to review and discuss References: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 222.3.111.47 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.6 (++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Tom, Acee et. al., Quoting "Henderson, Thomas R" : > Yes, I could give a short update at the IETF meeting. > > Perhaps my document was a bit much for people to digest last week, but = in a > nutshell, I would like to come to agreement on the following points: > > - Design team adopts problem statement as modified by design team list > discussions > - Design team focuses on defining a MANET interface type, not a MANET a= rea > type. > - Design team focuses first on defining an optimized flooding mechanism= for > LSA dissemination. > - Design team focuses on acknowledged (reliable) flooding, leaving peri= odic > flooding as a future optimization. > I've been everywhere but in the office lately, so I apologize for not hav= ing had time to comment on your document. I've read it, though, and it's quite go= od! I would like to voice agreement with the above items, with exception for = the last: I believe that we definitely should include both reliable and perio= dic flooding as options-to-consider, also initially. Indeed, I do believe tha= t one of the realizations of the MANET working group is, that periodic floding = may be beneficial in manet-style networks (Richard, Joe back me up here). As suc= h, I believe that scoping this completely out of the discussion at this stage = would be ill adviced. I would advocate a sensible hybrid approach, if at all possible. > and having done so, I would like to consider as a next step the tradeof= fs > between MPRs and CDS as the relay node set used for flooding (which is > described in much detail in Section 3.2 of the draft that I sent around= ). Just one brief comment here: I disagree with the terminology chosen. MPRs= do form a CDS -- indeed the MPR algorithm is an instance of a CDS algorithm.= As such, it doesn't make much sense to chose between them. I'd suggest that = we, rather than "chose between them" consider which features we need -- and t= hen pick an algorithm that fits (notice, I did write "pick", not "develop" --= for a reason). I know what's meant by "MPR vs CDS" above, since I've been part of the pr= ocess and discussion -- but to the outsider, this might be a source of misunderstanding, so I'd reccomend that we do not present it as a "choise= " of either or.... Cheers, --thomas > > Tom > > > > -----Original Message----- > > From: Acee Lindem [mailto:acee@redback.com] > > Sent: Friday, October 22, 2004 9:21 AM > > To: Henderson, Thomas R; ospf-wireless-design@ietf.org > > Cc: Rohit Dube > > Subject: Re: [Ospf-wireless-design] new material to review and discus= s > > > > > > Tom, > > > > Can we schedule a OSPF wireless design update for the Washington > > IETF? What I think would be good would be a presentation on the > > attached document with ample time for WG questions. > > > > Did anybody else have anything relevant to the OSPF wireless > > effort that > > they wanted to present in Washington? I've had a lot going on lately > > and realized today that time is running short. > > > > Thanks, > > Acee > > > > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 22 19:47:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14525; Fri, 22 Oct 2004 19:47:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9LR-0000y5-AX; Fri, 22 Oct 2004 20:01:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL918-0008Ao-Hp; Fri, 22 Oct 2004 19:40:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8sg-0003rW-D2 for ospf-wireless-design@megatron.ietf.org; Fri, 22 Oct 2004 19:31:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13601 for ; Fri, 22 Oct 2004 19:31:32 -0400 (EDT) Received: from postfix3-2.free.fr ([213.228.0.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL95Z-0000e1-AW for ospf-wireless-design@ietf.org; Fri, 22 Oct 2004 19:44:55 -0400 Received: from imp3-q.free.fr (imp3-q.free.fr [212.27.42.3]) by postfix3-2.free.fr (Postfix) with ESMTP id 6A501C022; Sat, 23 Oct 2004 01:31:30 +0200 (CEST) Received: by imp3-q.free.fr (Postfix, from userid 33) id F232A2A285; Sat, 23 Oct 2004 01:31:29 +0200 (MEST) Received: from ZH111047.ppp.dion.ne.jp (ZH111047.ppp.dion.ne.jp [222.3.111.47]) by imp3-q.free.fr (IMP) with HTTP for ; Sat, 23 Oct 2004 01:31:29 +0200 Message-ID: <1098487889.41799851dca07@imp3-q.free.fr> Date: Sat, 23 Oct 2004 01:31:29 +0200 From: Thomas Heide Clausen To: "Henderson, Thomas R" Subject: RE: [Ospf-wireless-design] new material to review and discuss References: <6938661A6EDA8A4EA8D1419BCE46F24C045227BF@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C045227BF@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 222.3.111.47 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.6 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: Joe Macker , ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Ahh...Joe beat me to it ;) I didn't get Joe's mail to the list, so I only= saw Tom's reply. Sorry for being redundant. --thomas Quoting "Henderson, Thomas R" : > > > > -----Original Message----- > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > Sent: Friday, October 22, 2004 10:41 AM > > To: Acee Lindem > > Cc: Henderson, Thomas R; ospf-wireless-design@ietf.org > > Subject: Re: [Ospf-wireless-design] new material to review and discus= s > > > > > > > If we can move past those items, the next topic I would like > > > to focus on is the flooding discussion-- in particular, the > > > issue of MPR vs. CDS that has never been resolved adequately > > > in my opinion. Please read Section 3.2 carefully, as it has > > > been substantially rewritten, and let the list know of your > > > agreements and disagreements to what is written there. > > > > > > > Tom: > > > > Sorry I'm jumping ahead here, but in preparation for > > discussion of MPR > > vs.CDS, I'd like to clarify a few issues, especially the terminology. > > > > MPR is a heuristic algorithm that forms a "source specific" > > CDS. So it > > is a CDS algorithm. So are we talking about "other" CDS > > algorithms like > > Wu and Li have proposed,etc. I just want to get the > > terminology straight > > so I know what we are talking about. For example, are we > > talking about > > a shared tree CDS algorithms, different election heuristics for > > forwarding sets, dynamic robustness issues, complexity tradeoffs... > > Yes, I mean source-independent vs. source dependent. Please > see the writeup in the draft that I circulated. > > > > > There are existing empirical and analytical studies that we > > can look at > > and discuss. > > > Please point us to such studies that you are aware of. I have > the paper by Wu and Li and can share it with anyone who > is interested. > > Tom > > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 22 19:47:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14544; Fri, 22 Oct 2004 19:47:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9LQ-0000y2-Hd; Fri, 22 Oct 2004 20:01:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL916-0008A6-Dy; Fri, 22 Oct 2004 19:40:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8rB-0003Gw-1d for ospf-wireless-design@megatron.ietf.org; Fri, 22 Oct 2004 19:30:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13513 for ; Fri, 22 Oct 2004 19:29:59 -0400 (EDT) Received: from postfix3-1.free.fr ([213.228.0.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL945-0000cV-Ui for ospf-wireless-design@ietf.org; Fri, 22 Oct 2004 19:43:22 -0400 Received: from imp3-q.free.fr (imp3-q.free.fr [212.27.42.3]) by postfix3-1.free.fr (Postfix) with ESMTP id B4EF91734A2; Sat, 23 Oct 2004 01:29:59 +0200 (CEST) Received: by imp3-q.free.fr (Postfix, from userid 33) id A86EB2A285; Sat, 23 Oct 2004 01:29:59 +0200 (MEST) Received: from ZH111047.ppp.dion.ne.jp (ZH111047.ppp.dion.ne.jp [222.3.111.47]) by imp3-q.free.fr (IMP) with HTTP for ; Sat, 23 Oct 2004 01:29:59 +0200 Message-ID: <1098487799.417997f794a86@imp3-q.free.fr> Date: Sat, 23 Oct 2004 01:29:59 +0200 From: Thomas Heide Clausen To: Acee Lindem Subject: Re: [Ospf-wireless-design] new material to review and discuss References: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> <0b1b01c4b860$4d968da0$0202a8c0@aceeinspiron> In-Reply-To: <0b1b01c4b860$4d968da0$0202a8c0@aceeinspiron> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 222.3.111.47 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.6 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Quoting Acee Lindem : > Here is my take... > > > > Yes, I could give a short update at the IETF meeting. > > > > Perhaps my document was a bit much for people to digest last week, bu= t in a > nutshell, I would like to come to agreement on the > > following points: > > > > - Design team adopts problem statement as modified by design team lis= t > discussions > > Agreed. However, I think it is still extended work plan is still open f= or > debate. Do we > need to change/optimize additional OSPF mechanisms for wireless (e.g., > database exchange). > Possibly, there be a better other mechanisms or policies that would yie= ld > more > bang-for-the-buck. > I just have to ask: we know from our research that there are mechanisms w= hich would yield more "bang-for-the-buck" in the manet-type scenario. However = these would in many ways divert from the traditional OSPF-mechanisms (both in s= cope and form), and have not been proven by large-scale deployments etc. To wh= ich extend are we going to include such in the work of this design-team? My personal feeling is, that this could cause undesired research-creep: t= o my knowledge, there's no concensus on such, as well as no "real-world-experi= ence" (well, Richard and I have at some point had similar thoughts on e.g. data= base exchange, but that does not a coherent mechanism yield nor does it indica= te wider concensus). So it might be a process of maturing such mechanisms, a= nd convincing ourself that it's usefull. As a researcher, I'd think this wou= ld be interresting (of course) to venture down that path. It's a trade-off, but I wanted the teams input. --thomas > > - Design team focuses on defining a MANET interface type, not a MANET= area > type. > > I think that since all the work done heretofore has been based on the M= ANET > interface > type we need to stick with it. I know there have been suggestions that = the > OSPF area > might be a better boundary for flooding changes (I think I may have sai= d this > ;^). However, > there are no proposals on the table. > > > - Design team focuses first on defining an optimized flooding mechani= sm for > LSA dissemination. > > Agreed. > > > - Design team focuses on acknowledged (reliable) flooding, leaving pe= riodic > flooding as a future optimization. > > Agreed. > > > > and having done so, I would like to consider as a next step the trade= offs > between MPRs > > and CDS as the relay node set used for flooding (which is described = in > much detail in Section 3.2 of the draft that I sent > > around). > > Tom > > > > -----Original Message----- > > From: Acee Lindem [mailto:acee@redback.com] > > Sent: Friday, October 22, 2004 9:21 AM > > To: Henderson, Thomas R; ospf-wireless-design@ietf.org > > Cc: Rohit Dube > > Subject: Re: [Ospf-wireless-design] new material to review and discus= s > > > > > > Tom, > > > > Can we schedule a OSPF wireless design update for the Washington > > IETF? What I think would be good would be a presentation on the > > attached document with ample time for WG questions. > > > > Did anybody else have anything relevant to the OSPF wireless > > effort that > > they wanted to present in Washington? I've had a lot going on lately > > and realized today that time is running short. > > > > Thanks, > > Acee > > > > > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Mon Oct 25 13:50:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18034; Mon, 25 Oct 2004 13:50:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM9Cs-00041t-9F; Mon, 25 Oct 2004 14:04:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8qu-0001wp-FL; Mon, 25 Oct 2004 13:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8n1-0001fz-N6 for ospf-wireless-design@megatron.ietf.org; Mon, 25 Oct 2004 13:37:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17147 for ; Mon, 25 Oct 2004 13:37:50 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM90W-0003n8-EQ for ospf-wireless-design@ietf.org; Mon, 25 Oct 2004 13:51:48 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2004 13:36:45 -0400 X-BrightmailFiltered: true Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9PHag7K000994; Mon, 25 Oct 2004 13:36:42 -0400 (EDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.11.2/CISCO.WS.1.2) id i9PHafs20398; Mon, 25 Oct 2004 13:36:41 -0400 (EDT) Date: Mon, 25 Oct 2004 13:36:41 -0400 From: "Madhavi W. Chandra" To: Thomas Heide Clausen Subject: Re: [Ospf-wireless-design] new material to review and discuss Message-ID: <20041025173641.GC20381@cisco.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> <1098487104.4179954065301@imp3-q.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1098487104.4179954065301@imp3-q.free.fr> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Hi Thomas, On Sat, Oct 23, 2004 at 01:18:24AM +0200, Thomas Heide Clausen wrote: > Tom, Acee et. al., > > Quoting "Henderson, Thomas R" : > > > Yes, I could give a short update at the IETF meeting. > > > > Perhaps my document was a bit much for people to digest last week, but in a > > nutshell, I would like to come to agreement on the following points: > > > > - Design team adopts problem statement as modified by design team list > > discussions > > - Design team focuses on defining a MANET interface type, not a MANET area > > type. > > - Design team focuses first on defining an optimized flooding mechanism for > > LSA dissemination. > > - Design team focuses on acknowledged (reliable) flooding, leaving periodic > > flooding as a future optimization. > > > > I've been everywhere but in the office lately, so I apologize for not having had > time to comment on your document. I've read it, though, and it's quite good! > > I would like to voice agreement with the above items, with exception for the > last: I believe that we definitely should include both reliable and periodic > flooding as options-to-consider, also initially. Indeed, I do believe that one > of the realizations of the MANET working group is, that periodic floding may be > beneficial in manet-style networks (Richard, Joe back me up here). As such, I > believe that scoping this completely out of the discussion at this stage would > be ill adviced. I would advocate a sensible hybrid approach, if at all > possible. We are also very interested in looking into a hybrid scheme...however, as a 'Phase II' task for the DT. To meet the DT timeline, it seems that we had reached agreement as a DT last month to focus on reliable flooding for Phase I as indicated in Section 1.2. I propose that we follow this, and defer the hybrid scheme for our next set of tasks (Phase II). Regards, Madhavi > > and having done so, I would like to consider as a next step the tradeoffs > > between MPRs and CDS as the relay node set used for flooding (which is > > described in much detail in Section 3.2 of the draft that I sent around). > > Just one brief comment here: I disagree with the terminology chosen. MPRs do > form a CDS -- indeed the MPR algorithm is an instance of a CDS algorithm. As > such, it doesn't make much sense to chose between them. I'd suggest that we, > rather than "chose between them" consider which features we need -- and then > pick an algorithm that fits (notice, I did write "pick", not "develop" -- for a > reason). > > I know what's meant by "MPR vs CDS" above, since I've been part of the process > and discussion -- but to the outsider, this might be a source of > misunderstanding, so I'd reccomend that we do not present it as a "choise" of > either or.... > > Cheers, > > --thomas > > > > > Tom > > > > > > > -----Original Message----- > > > From: Acee Lindem [mailto:acee@redback.com] > > > Sent: Friday, October 22, 2004 9:21 AM > > > To: Henderson, Thomas R; ospf-wireless-design@ietf.org > > > Cc: Rohit Dube > > > Subject: Re: [Ospf-wireless-design] new material to review and discuss > > > > > > > > > Tom, > > > > > > Can we schedule a OSPF wireless design update for the Washington > > > IETF? What I think would be good would be a presentation on the > > > attached document with ample time for WG questions. > > > > > > Did anybody else have anything relevant to the OSPF wireless > > > effort that > > > they wanted to present in Washington? I've had a lot going on lately > > > and realized today that time is running short. > > > > > > Thanks, > > > Acee > > > > > > > _______________________________________________ > > Ospf-wireless-design mailing list > > Ospf-wireless-design@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > > > > > > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Mon Oct 25 13:52:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18267; Mon, 25 Oct 2004 13:52:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM9F7-00044t-QV; Mon, 25 Oct 2004 14:06:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8tQ-0002DV-IH; Mon, 25 Oct 2004 13:44:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8pc-0001nw-C7 for ospf-wireless-design@megatron.ietf.org; Mon, 25 Oct 2004 13:40:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17309 for ; Mon, 25 Oct 2004 13:40:31 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM934-0003pP-C8 for ospf-wireless-design@ietf.org; Mon, 25 Oct 2004 13:54:29 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2004 13:39:58 -0400 X-BrightmailFiltered: true Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9PHdsWT001929; Mon, 25 Oct 2004 13:39:55 -0400 (EDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.11.2/CISCO.WS.1.2) id i9PHdsC20403; Mon, 25 Oct 2004 13:39:54 -0400 (EDT) Date: Mon, 25 Oct 2004 13:39:54 -0400 From: "Madhavi W. Chandra" To: Thomas Heide Clausen Subject: Re: [Ospf-wireless-design] new material to review and discuss Message-ID: <20041025173954.GD20381@cisco.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> <0b1b01c4b860$4d968da0$0202a8c0@aceeinspiron> <1098487799.417997f794a86@imp3-q.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1098487799.417997f794a86@imp3-q.free.fr> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Hi Thomas, On Sat, Oct 23, 2004 at 01:29:59AM +0200, Thomas Heide Clausen wrote: > Quoting Acee Lindem : > > > Here is my take... > > > > > > > Yes, I could give a short update at the IETF meeting. > > > > > > Perhaps my document was a bit much for people to digest last week, but in a > > nutshell, I would like to come to agreement on the > > > following points: > > > > > > - Design team adopts problem statement as modified by design team list > > discussions > > > > Agreed. However, I think it is still extended work plan is still open for > > debate. Do we > > need to change/optimize additional OSPF mechanisms for wireless (e.g., > > database exchange). > > Possibly, there be a better other mechanisms or policies that would yield > > more > > bang-for-the-buck. > > > > I just have to ask: we know from our research that there are mechanisms which > would yield more "bang-for-the-buck" in the manet-type scenario. However these > would in many ways divert from the traditional OSPF-mechanisms (both in scope > and form), and have not been proven by large-scale deployments etc. To which > extend are we going to include such in the work of this design-team? > > My personal feeling is, that this could cause undesired research-creep: to my > knowledge, there's no concensus on such, as well as no "real-world-experience" > (well, Richard and I have at some point had similar thoughts on e.g. database > exchange, but that does not a coherent mechanism yield nor does it indicate > wider concensus). So it might be a process of maturing such mechanisms, and > convincing ourself that it's usefull. As a researcher, I'd think this would be > interresting (of course) to venture down that path. > > It's a trade-off, but I wanted the teams input. I completely agree with your take on it. We're also toying with some database exchange optimizations...but, as you said so well above, it might be a process of maturing such mechanisms. My vote it to chalk this up to a Phase II task for the DT....so it doesn't bog us down in Phase I. Regards, Madhavi > --thomas > > > > > - Design team focuses on defining a MANET interface type, not a MANET area > > type. > > > > I think that since all the work done heretofore has been based on the MANET > > interface > > type we need to stick with it. I know there have been suggestions that the > > OSPF area > > might be a better boundary for flooding changes (I think I may have said this > > ;^). However, > > there are no proposals on the table. > > > > > - Design team focuses first on defining an optimized flooding mechanism for > > LSA dissemination. > > > > Agreed. > > > > > - Design team focuses on acknowledged (reliable) flooding, leaving periodic > > flooding as a future optimization. > > > > Agreed. > > > > > > and having done so, I would like to consider as a next step the tradeoffs > > between MPRs > > > and CDS as the relay node set used for flooding (which is described in > > much detail in Section 3.2 of the draft that I sent > > > around). > > > > Tom > > > > > > > -----Original Message----- > > > From: Acee Lindem [mailto:acee@redback.com] > > > Sent: Friday, October 22, 2004 9:21 AM > > > To: Henderson, Thomas R; ospf-wireless-design@ietf.org > > > Cc: Rohit Dube > > > Subject: Re: [Ospf-wireless-design] new material to review and discuss > > > > > > > > > Tom, > > > > > > Can we schedule a OSPF wireless design update for the Washington > > > IETF? What I think would be good would be a presentation on the > > > attached document with ample time for WG questions. > > > > > > Did anybody else have anything relevant to the OSPF wireless > > > effort that > > > they wanted to present in Washington? I've had a lot going on lately > > > and realized today that time is running short. > > > > > > Thanks, > > > Acee > > > > > > > > > _______________________________________________ > > Ospf-wireless-design mailing list > > Ospf-wireless-design@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > > > > > > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Wed Oct 27 03:02:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10949; Wed, 27 Oct 2004 03:02:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMi3N-0006wO-RO; Wed, 27 Oct 2004 03:17:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMhoc-00011x-2g; Wed, 27 Oct 2004 03:01:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMhnm-0000qu-LB for ospf-wireless-design@megatron.ietf.org; Wed, 27 Oct 2004 03:00:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10784 for ; Wed, 27 Oct 2004 03:00:56 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMi1a-0006uf-PD for ospf-wireless-design@ietf.org; Wed, 27 Oct 2004 03:15:15 -0400 Received: from sdn-ap-004castocp0021.dialsprint.net ([63.187.32.21] helo=earthlink.net) by pop-a065c28.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CMhne-00058E-00; Wed, 27 Oct 2004 00:00:51 -0700 Message-ID: <417F479D.8030001@earthlink.net> Date: Wed, 27 Oct 2004 00:00:45 -0700 From: Richard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Ospf-wireless-design] new material to review and discuss References: <6938661A6EDA8A4EA8D1419BCE46F24C0452271F@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Content-Transfer-Encoding: 7bit Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Content-Transfer-Encoding: 7bit Thomas, Please see my comments below for Section 3.2 of your document draft-manet-ospf-design-team-00-pre2 Overall, it is very good. First I want to comment on your sentence: > MPRs are also sometimes referred to as source-dependent CDS, while > the use of the term CDS typically means source-independent CDS. I'm glad you clarified this. So the main issue is whether we want the relays to be source-dependent or source-independent. Actually, there are different ways of defining a CDS in terms of MPRs, depending on the forwarding rule. (E.g., does an MPR forward any packet that was received from an MPR selector, or only if the first neighbor that transmitted the packet is an MPR selector, or only if the min ID neighbor that transmitted the packet is an MPR selector, etc.) > 3.2.1.2 Self-selected MPRs > > Regarding whether MPRs are self-selected versus selected by the > originators themselves, the tradeoff seems to be some increase in > complexity (i.e., processing steps) to self-select them, versus a > need to use extra fields in Hello or other messages to notify a > neighbor that it has been selected. However, it may require that > OSPF Hellos be modified to provide two-hop information anyway. For > example, consider if each node provided its two-hop neighbor > information to all of its one hop neighbors. Rather than the node > running the MPR selection algorithm and notifying the selected one > hop neighbor, each neighbor could run the algorithm on the node's > behalf, and decide whether it would have been selected by the node. > But the current OSPF Hello only provides one-hop neighbor information > for the sending node. Actually, the OSPF Hello does not even provide one-hop neighbor information, since it does not say whether each neighbor is 2-way. As in Cisco's protocol and in TBRPF, each node can inform its neighbors of all of its 2-way neighbors in its self-originated LSA. In that way, each node learns about all of its neighbors' neighbors (2-hop neighbors). It would be unnecessarily bandwidth consuming for each node to report all of its 2-hop neighbors (which would result in each node knowing its 3-hop neighbors). > > > A minimum-ID algorithm described in [9] requires O(m^4) computation > when run as a self-selecting algorithm rather than O(m^2) or O(m) > using the MPR selector approach. However, it has also been pointed A min-ID self-selecting algorithm exists which requires only O(n^3) using the Floyd-Warshall algorithm to compute shortest paths from each neighbor to each other neighbor, where n is the number of neighbors. I don't think this is too large. Another such algorithm requires only O(n^2) computations by computing shortest paths from each neighbor to only the min-ID neighbor. > > out by Ogier that, analogous to including the selected DR in Hello > messages, it may be useful to announce whether a node has selected > itself as an MPR for one of its neighbors, to reduce the frequency of > MPR changes. > > 3.2.1.3 Cisco Overlapping Relays > > As described in [4], the proposed "overlapping relays" algorithm is > based on the OLSR MPR algorithm, with the following optimization. > Neighbors that are selected as what OLSR would call MPRs are called > "active" overlapping relays, and all other neighbors are "non-active" > overlapping relays, with respect to a given two-hop neighbor of the > > > > Henderson (ed.) Expires April 13, 2005 [Page 9] > > Internet-Draft Summary of MANET OSPF Proposals October 2004 > > > message originator. The active relays behave like OLSR MPRs, but the > non-active relays of message originator monitor whether the two-hop > neighbor in fact acknowledged the transmission. If no ack is > received, then one of the non-active relays will attempt to > retransmit the message, based on some time interval and jitter to > avoid all non-active relays from attempting to recover the loss at > the same time. > > Other than this reliability optimization, it seems that the proposed > Cisco approach inherits the properties described above regarding > OLSR-style MPRs. As presently defined, it also incurs a delay in > notifying a neighbor that it has become active (the so-called > "opt-in" method above), but this is mitigated by the protection > offered by non-active neighbors, so all that might happen is a slight > increase in flooding delay. > > 3.2.1.4 CDS algorithms > > At the end of Section 6 of [5], Richard Ogier argues that CDS may be > preferable to MPR for OSPF, since it more naturally fits with the > concept of OSPF DR with fewer changes needed to OSPF packets, and > because it offers opportunities to optimize database synchronization > techniques. > > Specifically, some researchers (e.g., [10]) have shown simulation > results that show smaller size relay node sets when using CDS, > although in the author's opinion, this evidence may be > scenario-dependent and does not strongly favor one or the other. It > has been argued that CDS algorithms are potentially simpler as well, > since the decision to forward is not based on the originator of the > previous transmission. CDS may not forward along min-hop paths from > the message originator, although the difference in path length is > probably only one hop, if at all, and methods may exist to allow > min-hop flooding (e.g., [10]). > > If a node is self-selecting itself as a CDS, it most likely does so > with an assumption that neighbors are running the identical or > similar algorithm (in much the same way that the distributed > computation of Dijkstra's algorithm requires that all nodes > consistently apply it). In a MANET environment, some nodes may not > be as willing to select themselves as CDS, due to issues such as > energy reserve. Richard Ogier suggested in [5] that the Router > Priority field may be used to indicate "willingness" to relay traffic > and become a CDS node, but there is no specific description of how > this might work. Likewise, it is not clear how sensitive a CDS > self-selection algorithm would be to neighbors using consistent > algorithms, and hence, how easy it would be to evolve the heuristics > in an incremental deployment scenario. OSPF requires all nodes to run the same shortest-path algorithm, so requiring all nodes to run the same CDS algorithm is consistent with OSPF's philosophy. > > > > > Henderson (ed.) Expires April 13, 2005 [Page 10] > > Internet-Draft Summary of MANET OSPF Proposals October 2004 > > > Related to the issue of knowing the ROS is the issue of optimized > database synchronization. Another benefit of CDS or MPRs that know > their ROS is that these "special nodes" can take responsibility for > synchronization, much as an existing OSPF DR, rather than requiring > pair-wise synchronization between nodes. > > Although there are several heuristics for CDS construction that have > been proposed, one interesting one presented by INRIA (in [9]) can be > used to transform the set of MPRs into a CDS, if the nodes have some > agreed-upon knowledge of the total-order of the network (such as > increasing router ID). Ogier has done some simulation evaluation of > this algorithm in [10] and shown simulation results that it performs > worse than an algorithm based on two-hop neighbor information. I also want to point out that MPR selection involves *more* than 2-hop neighbor information, since each node computes its MPRs based on 2-hop neighbor information and then informs its neighbors of its MPR selection (so the selection of an MPR may depend on information about nodes that are 3 hops from the MPR itself). The CDS algorithms that I am considering depend only on 2-hop neighbor information. Also, having to first compute MPRs and then inform neighbors of the selection results in slower response to topology changes. > > > 3.2.1.5 Summary > > In the past, there has been simulation evidence presented that > favored MPRs over CDS, and vice versa, in terms of bandwidth > efficiency. In the absence of better data, it is the author's > opinion that, from the standpoint of bandwidth efficiency, MPRs > versus CDS will not make a whole lot of difference, especially when > metrics like robustness are considered that might favor some > redundancy in transmissions anyway. Both techniques seek to minimize > as much as possible the number of transmissions required to > disseminate the information, and different scenarios will yield > different winners, but in most cases, the differences seem to be a > few percent. Instead, the design decision should probably be driven > by which mechanism fits best (is least disruptive) to the existing > OSPF implementation. > > There have been arguments put forward, principally by Richard Ogier, > that CDS-based flooding is a better fit for OSPF than is MPR-based, > because CDS selection algorithms do not necessarily require changes > to OSPF message formats, because CDS is analogous to Designated > Router, because they may have simpler construction algorithms (for > this point, the author has not seen any proof), and because the fact > that a CDS does not care about the originator of a message, which may > help if the database synchronization procedures are ever optimized > for a MANET. Therefore, in the author's opinion, despite not having > a concrete CDS-based proposal on the table, the OSPF MANET design > team should consider this issue more carefully. > > 3.2.2 Discussion of reliability > > It seems to the author that the decision to focus on reliable > mechanisms first is non-contentious. The author has suggested > partiality to mechanisms that allow the introduction of a periodic, > non-acked LSA dissemination mode in the future. > > > > Henderson (ed.) Expires April 13, 2005 [Page 11] > > Internet-Draft Summary of MANET OSPF Proposals October 2004 > > > Richard Ogier has proposed that unreliable (periodic) operation may > be a hybrid option of an overall reliable mechanism. A Boeing > simulation study described in [7] suggested that it may be difficult > to correctly estimate the need to be in one mode or another. Since > that time, Richard Ogier has revised his proposal in this regard, as > discussed in Section 5 of [5]. Richard's current proposal is not > based on receiver suppression of ACKs but instead is sender-based and > suggests setting a new option bit in the header to make the LSA > "non-ackable" within the wireless domain whenever new LSAs are being > generated fast enough (i.e., close to MinLSInterval), with hysteresis > applied to avoid flapping between modes. > > Baker suggested the use of next-hop reflooding as an implicit ACK in > [1], although Ogier pointed out that this only applied to nodes in > the relay set; non-relay nodes still have to ACK. > > In Section 6 of [5], Richard Ogier suggests a reliable flooding > technique based on modification of Database Description (DD) packets. > It calls for special nodes (either CDS nodes or MPR nodes) to > periodically broadcast headers of all the LSAs for which it is It should be clarified that these LSAs headers are contained within DD packets that are broadcast to all neighbors periodically (similar to the sequence numbers packets of IS-IS). > > responsible for forwarding, and for all other nodes to broadcast a DD > packet with the header of its own router LSA. This is in contrast to > unreliable flooding of the LSAs themselves. Nodes that detect a > missing LSA can still use the LSR to request it, after some backoff > time. This is analogous to IS-IS Complete Sequence Number (CSN) > packets [11]. The technique is in contrast to the OLSR-like approach > in the Boeing proposal, which periodically refloods all LSAs. > Variations of this approach are possible and discussed by Richard > Ogier, such as repeating the original LSA transmission multiple > times, or CDS redundancy. INRIA also proposed such a mechanism of > periodic informational database signature broadcasts in [6]. > > Last, it should be pointed out (as Richard has) that the selection of > RNS sets is not completely independent of the decision whether LSA > dissemination is reliable or periodic. A purely OLSR-style MPR RNS > is susceptible to some lost packets when used in a reliable mode, > unless non-relay nodes are used as backups, as is proposed for the > Cisco overlapping relays technique. > > 3.3 Neighbor discovery and synchronization > > This section discusses the process of neighbor discovery, adjacency > forming, and database synchronization. > > In a MANET, the number of neighbors can become large, causing > quadratic scaling problems. Fred Baker suggests in [1] that the > number of adjacencies might be reduced. More recently, the proposal > by Cisco advocates the use of differential or incremental Hellos > > > > Henderson (ed.) Expires April 13, 2005 [Page 12] > > Internet-Draft Summary of MANET OSPF Proposals October 2004 > > > (also suggested by the MANET TBRPF protocol). Some simulations > conducted by Boeing and discussed in [7] suggest that differential > Hellos contribute second-order savings in bandwidth, but the benefits > might actually be larger than those described by Boeing when the > network is very dense. One potential benefit of differential Hellos > is that the Hello transmissions can be aperiodic. > > For the same reason that differential Hellos might be useful, so too > might a reduction in the number of neighbors with which a MANET node > becomes adjacent. OSPF does this already for broadcast interfaces. > Fred Baker in [1] suggested that nodes might want to limit the number > of neighbors. Richard Ogier in [5] also suggested that if there are > special nodes such as Multipoint Relays (MPRs) and Connected > Dominating Sets (CDS) in the network, that non-relay nodes might want > to synchronize only with these relay nodes (Ogier redefined the > concept of adjacency in this context). When using unreliable > flooding as in [3], no database synchronization occurs; nodes do not > progress past state 2-Way on a MANET interface. It would be good to point out what happens if the periodic DD packet method is used for reliable flooding. In this case (similar to IS-IS), a new neighbor of a CDS node (or MPR) will receive the periodic DD packets and send a LS Request if the CDS node has a more recent LSA. This is similar to Clausen's proposal (both are inspired by IS-IS) but is simpler and closer to OSPF. Regards, Richard > > > Taking the synchronization process a step further, Thomas Clausen and > INRIA suggested in [6] that a much more compact representation of > OSPF databases than an enumeration of LSA headers might be possible > using signatures (hashes) of parts of the OSPF database. For > example, nodes could compare top-level signatures of their database, > and only if they differed would additional signatures start to be > compared, until the discrepancy was narrowed down. The draft > describes an algorithm called Tunstall Splitting to generate prefix > signatures of different parts of the database, which can be further > segregated by age of the LSAs. _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Wed Oct 27 12:51:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21697; Wed, 27 Oct 2004 12:51:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrFP-0001Xn-63; Wed, 27 Oct 2004 13:06:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMqvH-0006yu-Mi; Wed, 27 Oct 2004 12:45:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMqq9-0005uA-7E for ospf-wireless-design@megatron.ietf.org; Wed, 27 Oct 2004 12:40:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20972 for ; Wed, 27 Oct 2004 12:39:57 -0400 (EDT) Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMr41-0001Kb-N7 for ospf-wireless-design@ietf.org; Wed, 27 Oct 2004 12:54:23 -0400 Received: from sdn-ap-004castocp0066.dialsprint.net ([63.187.32.66] helo=earthlink.net) by pop-a065c05.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CMqq2-0005p4-00; Wed, 27 Oct 2004 09:39:55 -0700 Message-ID: <417FCF57.5090405@earthlink.net> Date: Wed, 27 Oct 2004 09:39:51 -0700 From: Richard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Thomas Heide Clausen Subject: Re: [Ospf-wireless-design] new material to review and discuss References: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> <0b1b01c4b860$4d968da0$0202a8c0@aceeinspiron> <1098487799.417997f794a86@imp3-q.free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Hi Thomas, Thomas Heide Clausen wrote: > >I just have to ask: we know from our research that there are mechanisms which >would yield more "bang-for-the-buck" in the manet-type scenario. However these >would in many ways divert from the traditional OSPF-mechanisms (both in scope >and form), and have not been proven by large-scale deployments etc. To which >extend are we going to include such in the work of this design-team? > >My personal feeling is, that this could cause undesired research-creep: to my >knowledge, there's no concensus on such, as well as no "real-world-experience" >(well, Richard and I have at some point had similar thoughts on e.g. database >exchange, but that does not a coherent mechanism yield nor does it indicate >wider concensus). So it might be a process of maturing such mechanisms, and >convincing ourself that it's usefull. As a researcher, I'd think this would be >interresting (of course) to venture down that path. > I think it depends on how novel the proposed mechanisms are. Some of the techniques we are proposing have been throroghly tested in other protocols such as IS-IS and therefore are more mature and less "researchy". For example, the periodic DD packet technique I am proposing is just an adaptation of the periodic sequence numbers packets of IS-IS. To achieve efficient, reliable flooding in MANETs, *some* novelty is needed, since this has not been done before. For example, Cisco's proposal (in which ACKs are multicast and non-MPR nodes can forward LSAs) is novel, and perhaps more "researchy" than simply adapting the IS-IS technique. It might be better to adapt the well-tested technique from IS-IS than to invent new mechanisms for efficient, reliable flooding. If adapting the IS-IS technique results in more efficient flooding in highly mobile networks, and if it also leads more quickly to a mature protocol, it would be a shame to ignore this approach. If we wait until Phase II before we consider this approach (which does not use ACKs), then we *might* find that the ACK-based flooding mechanism developed in Phase I is obsolete. Regards, Richard > > >It's a trade-off, but I wanted the teams input. > >--thomas > > >>>- Design team focuses on defining a MANET interface type, not a MANET area >>> >>type. >> >>I think that since all the work done heretofore has been based on the MANET >>interface >>type we need to stick with it. I know there have been suggestions that the >>OSPF area >>might be a better boundary for flooding changes (I think I may have said this >>;^). However, >>there are no proposals on the table. >> >>>- Design team focuses first on defining an optimized flooding mechanism for >>> >>LSA dissemination. >> >>Agreed. >> >>>- Design team focuses on acknowledged (reliable) flooding, leaving periodic >>> >>flooding as a future optimization. >> >>Agreed. >> >>>and having done so, I would like to consider as a next step the tradeoffs >>> >>between MPRs >> >>>and CDS as the relay node set used for flooding (which is described in >>> >>much detail in Section 3.2 of the draft that I sent >> >>>around). >>> >>Tom >> >> >>>-----Original Message----- >>>From: Acee Lindem [mailto:acee@redback.com] >>>Sent: Friday, October 22, 2004 9:21 AM >>>To: Henderson, Thomas R; ospf-wireless-design@ietf.org >>>Cc: Rohit Dube >>>Subject: Re: [Ospf-wireless-design] new material to review and discuss >>> >>> >>>Tom, >>> >>>Can we schedule a OSPF wireless design update for the Washington >>>IETF? What I think would be good would be a presentation on the >>>attached document with ample time for WG questions. >>> >>>Did anybody else have anything relevant to the OSPF wireless >>>effort that >>>they wanted to present in Washington? I've had a lot going on lately >>>and realized today that time is running short. >>> >>>Thanks, >>>Acee >>> >> >>_______________________________________________ >>Ospf-wireless-design mailing list >>Ospf-wireless-design@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/ospf-wireless-design >> > > > >_______________________________________________ >Ospf-wireless-design mailing list >Ospf-wireless-design@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Thu Oct 28 23:13:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01555; Thu, 28 Oct 2004 23:13:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNR8-0002MX-0l; Thu, 28 Oct 2004 23:28:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMj2-00010m-R2; Thu, 28 Oct 2004 22:42:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3Pp-0001Pd-V2 for ospf-wireless-design@megatron.ietf.org; Fri, 22 Oct 2004 13:41:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23640 for ; Fri, 22 Oct 2004 13:41:23 -0400 (EDT) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3cb-0002wq-Dz for ospf-wireless-design@ietf.org; Fri, 22 Oct 2004 13:54:41 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id i9MHelNl028560; Fri, 22 Oct 2004 13:40:47 -0400 (EDT) Received: from [127.0.0.1] ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.0.4.64) with SMTP id M2004102213404610480 ; Fri, 22 Oct 2004 13:40:46 -0400 Message-ID: <41794637.7000204@nrl.navy.mil> Date: Fri, 22 Oct 2004 13:41:11 -0400 From: Joe Macker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Acee Lindem Subject: Re: [Ospf-wireless-design] new material to review and discuss References: <6938661A6EDA8A4EA8D1419BCE46F24C0452271F@xch-nw-27.nw.nos.boeing.com> <0b0601c4b853$151ec170$0202a8c0@aceeinspiron> In-Reply-To: <0b0601c4b853$151ec170$0202a8c0@aceeinspiron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Oct 2004 22:42:47 -0400 Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit > If we can move past those items, the next topic I would like > to focus on is the flooding discussion-- in particular, the > issue of MPR vs. CDS that has never been resolved adequately > in my opinion. Please read Section 3.2 carefully, as it has > been substantially rewritten, and let the list know of your > agreements and disagreements to what is written there. > Tom: Sorry I'm jumping ahead here, but in preparation for discussion of MPR vs.CDS, I'd like to clarify a few issues, especially the terminology. MPR is a heuristic algorithm that forms a "source specific" CDS. So it is a CDS algorithm. So are we talking about "other" CDS algorithms like Wu and Li have proposed,etc. I just want to get the terminology straight so I know what we are talking about. For example, are we talking about a shared tree CDS algorithms, different election heuristics for forwarding sets, dynamic robustness issues, complexity tradeoffs... There are existing empirical and analytical studies that we can look at and discuss. -joe _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Thu Oct 28 23:13:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01602; Thu, 28 Oct 2004 23:13:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNRB-0002Mv-PR; Thu, 28 Oct 2004 23:28:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMj3-00011I-8d; Thu, 28 Oct 2004 22:42:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL74M-0006dQ-3n for ospf-wireless-design@megatron.ietf.org; Fri, 22 Oct 2004 17:35:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22035 for ; Fri, 22 Oct 2004 17:35:25 -0400 (EDT) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7HB-0002UW-Qe for ospf-wireless-design@ietf.org; Fri, 22 Oct 2004 17:48:47 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id i9MLYnNp007394; Fri, 22 Oct 2004 17:34:53 -0400 (EDT) Received: from [127.0.0.1] ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.0.4.64) with SMTP id M2004102217345212890 ; Fri, 22 Oct 2004 17:34:52 -0400 Message-ID: <41797D16.8060907@nrl.navy.mil> Date: Fri, 22 Oct 2004 17:35:18 -0400 From: Joe Macker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Ospf-wireless-design] new material to review and discuss References: <6938661A6EDA8A4EA8D1419BCE46F24C045227BF@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C045227BF@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Oct 2004 22:42:47 -0400 Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: > Yes, I mean source-independent vs. source dependent. Please > see the writeup in the draft that I circulated. > > Ok, I sent another message after I read it (sorry for the premature first message). >>There are existing empirical and analytical studies that we >>can look at >>and discuss. >> > > Please point us to such studies that you are aware of. I have > the paper by Wu and Li and can share it with anyone who > is interested. FYI (I am not necessarily of the above, just pointing out there is work there)...many of the more optimal techniques can suffer under dynamic/mobile operation (often more signaling/maintenance required,etc)..in addition to overhead we need to consider this. I have some analytical (random graphs) and empirical studies (with mobility) internally also on a few methods (not completely comprehensive but it may contribute). I'll bring some to the IETF. I think we should strive for a good approach that is not overly complex (perhaps not optimal). > > Tom > > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > > _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Thu Oct 28 23:13:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01621; Thu, 28 Oct 2004 23:13:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNRD-0002N0-FR; Thu, 28 Oct 2004 23:28:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMj3-00011X-HU; Thu, 28 Oct 2004 22:42:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6X9-0007js-8z for ospf-wireless-design@megatron.ietf.org; Mon, 25 Oct 2004 11:13:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03210 for ; Mon, 25 Oct 2004 11:13:16 -0400 (EDT) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM6kb-00007D-Jx for ospf-wireless-design@ietf.org; Mon, 25 Oct 2004 11:27:14 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id i9PFCiNl009283 for ; Mon, 25 Oct 2004 11:12:44 -0400 (EDT) Received: from [127.0.0.1] ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.0.4.64) with SMTP id M2004102511124407702 for ; Mon, 25 Oct 2004 11:12:44 -0400 Message-ID: <417D180D.1040605@nrl.navy.mil> Date: Mon, 25 Oct 2004 11:13:17 -0400 From: Joe Macker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ospf-wireless-design@ietf.org Subject: Re: [Ospf-wireless-design] new material to review and discuss References: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> <0b1b01c4b860$4d968da0$0202a8c0@aceeinspiron> In-Reply-To: <0b1b01c4b860$4d968da0$0202a8c0@aceeinspiron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Oct 2004 22:42:47 -0400 X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Are we planning to meet separately as a design team in DC as in San Diego? I thought that was a very productive forum last time.. Sorry about nasty message wrapping in my last few e-mails, just switched clients and didn't catch the default settings right away... -Joe _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 29 00:00:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01564; Thu, 28 Oct 2004 23:13:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNR9-0002Mh-84; Thu, 28 Oct 2004 23:28:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMj3-000111-1w; Thu, 28 Oct 2004 22:42:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5Nf-0002ZB-5B for ospf-wireless-design@megatron.ietf.org; Fri, 22 Oct 2004 15:47:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03830 for ; Fri, 22 Oct 2004 15:47:15 -0400 (EDT) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5aV-0005E0-3o for ospf-wireless-design@ietf.org; Fri, 22 Oct 2004 16:00:35 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id i9MJkXNp003913; Fri, 22 Oct 2004 15:46:41 -0400 (EDT) Received: from [127.0.0.1] ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.0.4.64) with SMTP id M2004102215463911766 ; Fri, 22 Oct 2004 15:46:39 -0400 Message-ID: <417963B9.40909@nrl.navy.mil> Date: Fri, 22 Oct 2004 15:47:05 -0400 From: Joe Macker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Ospf-wireless-design] new material to review and discuss References: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Oct 2004 22:42:47 -0400 Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: > Yes, I could give a short update at the IETF meeting. > > Perhaps my document was a bit much for people to digest last week, but in a nutshell, I would like to come to agreement on the following points: > > - Design team adopts problem statement as modified by design team list discussions > - Design team focuses on defining a MANET interface type, not a MANET area type. > - Design team focuses first on defining an optimized flooding mechanism for LSA dissemination. optimized flooding seems a little general given the next statement. I assume here we mean we will work on a mechanism for reduced forwarder sets (e.g., MPR, whatever)...below is the reliability aspect.? Is that the correct interpretation...? > - Design team focuses on acknowledged (reliable) flooding, leaving periodic flooding as a future optimization. > > and having done so, I would like to consider as a next step the tradeoffs between MPRs and CDS as the relay node set used for flooding (which is described in much detail in Section 3.2 of the draft that I sent around). > (you probably have see my last note by now)...its redundant so forget it...read this instead I reread the new 3.2 section, I see you defined MPR as source-dependent CDS and explained CDS better, but there's some implication MRP isn't CDS. Maybe this is all from Richard's tutorial. From a graph theory point of view I am still confused. I prefer the terms SI-CDS and SD-CDS used in literature. SD-CDS = source dependent CDS SI-CDS = source independent CDS But the section is well-written and provides a discussion dropoff point. Good work... One thing to note in section 3.2.1.4 Specifically, some researchers (e.g., [10]) have shown simulation results that show smaller size relay node sets when using CDS, although in the author's opinion, this evidence may be scenario-dependent and does not strongly favor one or the other. ------------------------- I agree with you Tom, as further evidence for further discussion... in fact "some researchers [Wu etal, and others] state the opposite of the above is true" That basically typical SD-CDS (MPR-like)algorithms produce smaller sets than SI-CDS algorithms... We analysed SD-MPR against a global knowledge clustering algorithm (SI-CDS) for up to 100 nodes in a random graph.. ther results showed about the same relay set size. The SI-CDS was much simpler.. Just one example I realize that.. Some numbers may also depend how people count the relay set in use.. In a SD-CDS algorithms not all relays are active in the forwarding for every packet (in SI they are), since this is source dependent (at least previous hop dependent)... "active relays" used for a given source are usually smaller in SD. In conclusion, I think it is scenario and algorithm dependent and also depends on how one counts the forwarding set used (active vs. total number). -------------------------------- > Tom > > > >>-----Original Message----- >>From: Acee Lindem [mailto:acee@redback.com] >>Sent: Friday, October 22, 2004 9:21 AM >>To: Henderson, Thomas R; ospf-wireless-design@ietf.org >>Cc: Rohit Dube >>Subject: Re: [Ospf-wireless-design] new material to review and discuss >> >> >>Tom, >> >>Can we schedule a OSPF wireless design update for the Washington >>IETF? What I think would be good would be a presentation on the >>attached document with ample time for WG questions. >> >>Did anybody else have anything relevant to the OSPF wireless >>effort that >>they wanted to present in Washington? I've had a lot going on lately >>and realized today that time is running short. >> >>Thanks, >>Acee >> > > > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > > _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 29 08:40:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24712; Fri, 29 Oct 2004 08:40:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWHU-0005wE-KZ; Fri, 29 Oct 2004 08:55:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVjY-00057c-Eb; Fri, 29 Oct 2004 08:19:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVa0-0000jF-12 for ospf-wireless-design@megatron.ietf.org; Fri, 29 Oct 2004 08:10:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22392 for ; Fri, 29 Oct 2004 08:10:02 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNVoH-0005Gu-0G for ospf-wireless-design@ietf.org; Fri, 29 Oct 2004 08:24:49 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7C1B865DA23; Fri, 29 Oct 2004 05:09:57 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10018-02; Fri, 29 Oct 2004 05:09:57 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.27]) by prattle.redback.com (Postfix) with SMTP id 7FEB265DA22; Fri, 29 Oct 2004 05:09:56 -0700 (PDT) Message-ID: <006301c4bdb0$30defb70$0202a8c0@aceeinspiron> From: "Acee Lindem" To: "Joe Macker" , References: <6938661A6EDA8A4EA8D1419BCE46F24C040608D5@xch-nw-27.nw.nos.boeing.com><0b1b01c4b860$4d968da0$0202a8c0@aceeinspiron> <417D180D.1040605@nrl.navy.mil> Subject: Re: [Ospf-wireless-design] new material to review and discuss Date: Fri, 29 Oct 2004 08:09:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Hi Joe, ----- Original Message ----- From: "Joe Macker" To: Sent: Monday, October 25, 2004 11:13 AM Subject: Re: [Ospf-wireless-design] new material to review and discuss > Are we planning to meet separately as a design team in DC as in San Diego? > I thought that was a very productive forum last time.. For me it would have to be Tuesday. I'm in a transitionary period and am only going to be at the IETF Monday and Tuesday. > > Sorry about nasty message wrapping in my last few e-mails, just switched clients and didn't catch the default settings right > away.. > -Joe > > > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 29 17:45:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16875; Fri, 29 Oct 2004 17:45:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNemx-0003N4-H3; Fri, 29 Oct 2004 18:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNe4P-0002ZT-2C; Fri, 29 Oct 2004 17:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdVs-0007dt-Sj for ospf-wireless-design@megatron.ietf.org; Fri, 29 Oct 2004 16:38:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07796 for ; Fri, 29 Oct 2004 16:38:18 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdkE-0000to-4D for ospf-wireless-design@ietf.org; Fri, 29 Oct 2004 16:53:10 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA16579; Fri, 29 Oct 2004 13:37:46 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9TKbki01164; Fri, 29 Oct 2004 13:37:46 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 13:37:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ospf-wireless-design] new material to review and discuss Date: Fri, 29 Oct 2004 13:37:34 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608F8@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Ospf-wireless-design] new material to review and discuss Thread-Index: AcS9tHFWUeOXRowfRxih/1c05BUMzAAQf3mQ From: "Henderson, Thomas R" To: "Acee Lindem" , "Joe Macker" , X-OriginalArrivalTime: 29 Oct 2004 20:37:35.0307 (UTC) FILETIME=[1F4F29B0:01C4BDF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Does anyone have a conflict meeting on Tuesday PM? I have conflicts on Tuesday AM. The routing related agenda on Tuesday PM seems to be: IP over Cable Data Network WG Routing Protocol Security Requirements WG (OPS) Global Routing Operations WG Protocol Independent Multicast WG For those who will be at the IETF meeting, please chime in if=20 you would like to schedule around any of the above. =20 Tom _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 29 22:16:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04861; Fri, 29 Oct 2004 22:16:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNj1Q-0008AR-2o; Fri, 29 Oct 2004 22:31:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNieC-0002Q1-QK; Fri, 29 Oct 2004 22:07:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNiQN-0004f8-LD for ospf-wireless-design@megatron.ietf.org; Fri, 29 Oct 2004 21:52:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03643 for ; Fri, 29 Oct 2004 21:52:57 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNiel-0007oV-U5 for ospf-wireless-design@ietf.org; Fri, 29 Oct 2004 22:07:52 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA13509; Fri, 29 Oct 2004 18:52:14 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9U1qEp01599; Fri, 29 Oct 2004 18:52:14 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 18:51:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ospf-wireless-design] new material to review and discuss Date: Fri, 29 Oct 2004 18:51:33 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060900@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Ospf-wireless-design] new material to review and discuss Thread-Index: AcS4jXAGPutVoxmEQc2XQbu5EUMDGAFlCh2Q From: "Henderson, Thomas R" To: "Thomas Heide Clausen" X-OriginalArrivalTime: 30 Oct 2004 01:51:34.0945 (UTC) FILETIME=[FC9BC910:01C4BE22] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Catching up on a few of these mails... > -----Original Message----- > From: Thomas Heide Clausen [mailto:T.Clausen@computer.org]=20 > Sent: Friday, October 22, 2004 4:18 PM > To: Henderson, Thomas R > Cc: Acee Lindem; ospf-wireless-design@ietf.org > Subject: RE: [Ospf-wireless-design] new material to review and discuss >=20 >>=20 > Just one brief comment here: I disagree with the terminology=20 > chosen. MPRs do > form a CDS -- indeed the MPR algorithm is an instance of a=20 > CDS algorithm. As > such, it doesn't make much sense to chose between them. I'd=20 > suggest that we, > rather than "chose between them" consider which features we=20 > need -- and then > pick an algorithm that fits (notice, I did write "pick", not=20 > "develop" -- for a > reason). >=20 If we pick from what is available, what is the pool from which we are picking? I think that one criteria is that we look for algorithms that operate in a distributed fashion (i.e., don't require a global knowledge of all nodes to pick the relay node set). In the source-dependent CDS realm, that includes MPRs (and=20 Cisco adaptation of that) and TBRPF-like approaches (others?) In the source-independent CDS realm, I'm aware of the following distributed approaches: - the approach by Wu and Li, improved upon by Lin - the approach described by Adjih (INRIA), which transforms a set of MPRs into a set of SI-CDS - the virtual dynamic backbone algorithm (Kozat et al.) Are there others? =20 Tom _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design From ospf-wireless-design-bounces@ietf.org Fri Oct 29 22:17:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04931; Fri, 29 Oct 2004 22:17:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNj2W-0008BR-KP; Fri, 29 Oct 2004 22:32:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNiel-0002qM-NF; Fri, 29 Oct 2004 22:07:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNiag-0000et-Cj for ospf-wireless-design@megatron.ietf.org; Fri, 29 Oct 2004 22:03:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04178 for ; Fri, 29 Oct 2004 22:03:36 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNip4-0007xy-Qs for ospf-wireless-design@ietf.org; Fri, 29 Oct 2004 22:18:31 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id TAA18409; Fri, 29 Oct 2004 19:03:06 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9U235p09056; Fri, 29 Oct 2004 19:03:05 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 19:03:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ospf-wireless-design] new material to review and discuss Date: Fri, 29 Oct 2004 19:03:03 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060901@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Ospf-wireless-design] new material to review and discuss Thread-Index: AcS78rRaAxWBZMpgTaqqo4vsHCH7VwCMHRzA From: "Henderson, Thomas R" To: "Richard" X-OriginalArrivalTime: 30 Oct 2004 02:03:05.0156 (UTC) FILETIME=[9801A040:01C4BE24] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: ospf-wireless-design@ietf.org X-BeenThere: ospf-wireless-design@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OSPF Wireless Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-wireless-design-bounces@ietf.org Errors-To: ospf-wireless-design-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable see responses inline > -----Original Message----- > From: Richard [mailto:rich.ogier@earthlink.net]=20 > Sent: Wednesday, October 27, 2004 12:01 AM > To: Henderson, Thomas R > Cc: ospf-wireless-design@ietf.org > Subject: Re: [Ospf-wireless-design] new material to review and discuss >=20 >=20 > Thomas, >=20 > Please see my comments below for Section 3.2 of your document > draft-manet-ospf-design-team-00-pre2 > Overall, it is very good. >=20 > First I want to comment on your sentence: >=20 > > MPRs are also sometimes referred to as source-dependent=20 > CDS, while > > the use of the term CDS typically means source-independent CDS. >=20 > I'm glad you clarified this. So the main issue is whether we want > the relays to be source-dependent or source-independent. Actually, > there are different ways of defining a CDS in terms of MPRs, > depending on the forwarding rule. (E.g., does an MPR forward any > packet that was received from an MPR selector, or only if the > first neighbor that transmitted the packet is an MPR selector, > or only if the min ID neighbor that transmitted the packet is > an MPR selector, etc.) =20 >=20 agreed, these are possible variations. >=20 > > 3.2.1.2 Self-selected MPRs > > > > Regarding whether MPRs are self-selected versus selected by the > > originators themselves, the tradeoff seems to be some increase in > > complexity (i.e., processing steps) to self-select them, versus a > > need to use extra fields in Hello or other messages to notify a > > neighbor that it has been selected. However, it may require that > > OSPF Hellos be modified to provide two-hop information=20 > anyway. For > > example, consider if each node provided its two-hop neighbor > > information to all of its one hop neighbors. Rather=20 > than the node > > running the MPR selection algorithm and notifying the=20 > selected one > > hop neighbor, each neighbor could run the algorithm on the node's > > behalf, and decide whether it would have been selected=20 > by the node. > > But the current OSPF Hello only provides one-hop=20 > neighbor information > > for the sending node. >=20 > Actually, the OSPF Hello does not even provide one-hop neighbor > information, since it does not say whether each neighbor is 2-way. > As in Cisco's protocol and in TBRPF, each node can inform its=20 > neighbors > of all of its 2-way neighbors in its self-originated LSA. > In that way, each node learns about all of its neighbors' neighbors > (2-hop neighbors). > It would be unnecessarily bandwidth consuming for each node to > report all of its 2-hop neighbors (which would result in each node > knowing its 3-hop neighbors). agreed.=20 >=20 > > > > > > A minimum-ID algorithm described in [9] requires O(m^4)=20 > computation > > when run as a self-selecting algorithm rather than O(m^2) or O(m) > > using the MPR selector approach. However, it has also=20 > been pointed >=20 > A min-ID self-selecting algorithm exists which requires only > O(n^3) using the Floyd-Warshall algorithm to compute shortest paths > from each neighbor to each other neighbor, where n is the number > of neighbors. I don't think this is too large. Another such algorithm > requires only O(n^2) computations by computing shortest paths=20 > from each > neighbor to only the min-ID neighbor. agreed. thanks for pointing that out. > > > > If a node is self-selecting itself as a CDS, it most=20 > likely does so > > with an assumption that neighbors are running the identical or > > similar algorithm (in much the same way that the distributed > > computation of Dijkstra's algorithm requires that all nodes > > consistently apply it). In a MANET environment, some=20 > nodes may not > > be as willing to select themselves as CDS, due to issues such as > > energy reserve. Richard Ogier suggested in [5] that the Router > > Priority field may be used to indicate "willingness" to=20 > relay traffic > > and become a CDS node, but there is no specific=20 > description of how > > this might work. Likewise, it is not clear how sensitive a CDS > > self-selection algorithm would be to neighbors using consistent > > algorithms, and hence, how easy it would be to evolve=20 > the heuristics > > in an incremental deployment scenario. >=20 > OSPF requires all nodes to run the same shortest-path algorithm, > so requiring all nodes to run the same CDS algorithm > is consistent with OSPF's philosophy. I agree that CDS is consistent with OSPF-- the question is whether the=20 possibility for evolving the heuristics in an incremental fashion is worth anything. > > > Although there are several heuristics for CDS=20 > construction that have > > been proposed, one interesting one presented by INRIA=20 > (in [9]) can be > > used to transform the set of MPRs into a CDS, if the=20 > nodes have some > > agreed-upon knowledge of the total-order of the network (such as > > increasing router ID). Ogier has done some simulation=20 > evaluation of > > this algorithm in [10] and shown simulation results that=20 > it performs > > worse than an algorithm based on two-hop neighbor information. >=20 > I also want to point out that MPR selection involves *more* than > 2-hop neighbor information, since each node computes its MPRs > based on 2-hop neighbor information and then informs its > neighbors of its MPR selection (so the selection of an MPR > may depend on information about nodes that are 3 hops from > the MPR itself). The CDS algorithms that I am considering > depend only on 2-hop neighbor information. > Also, having to first compute MPRs and then inform neighbors of the > selection results in slower response to topology changes. Yes, but the node doing the selection relies on two hop info, right? That is the main point, I think. But then there is the extra step of notifying. I think you are pointing out that the CDS algorithm relies on two hop info, but there is no "next step" of notifying a node as in MPRs. =20 > > > > In Section 6 of [5], Richard Ogier suggests a reliable flooding > > technique based on modification of Database Description=20 > (DD) packets. > > It calls for special nodes (either CDS nodes or MPR nodes) to > > periodically broadcast headers of all the LSAs for which it is >=20 > It should be clarified that these LSAs headers are contained within > DD packets that are broadcast to all neighbors periodically (similar > to the sequence numbers packets of IS-IS). OK. > > > > For the same reason that differential Hellos might be=20 > useful, so too > > might a reduction in the number of neighbors with which=20 > a MANET node > > becomes adjacent. OSPF does this already for broadcast=20 > interfaces. > > Fred Baker in [1] suggested that nodes might want to=20 > limit the number > > of neighbors. Richard Ogier in [5] also suggested that=20 > if there are > > special nodes such as Multipoint Relays (MPRs) and Connected > > Dominating Sets (CDS) in the network, that non-relay=20 > nodes might want > > to synchronize only with these relay nodes (Ogier redefined the > > concept of adjacency in this context). When using unreliable > > flooding as in [3], no database synchronization occurs;=20 > nodes do not > > progress past state 2-Way on a MANET interface. >=20 > It would be good to point out what happens if the periodic DD packet > method is used for reliable flooding. In this case (similar to IS-IS), > a new neighbor of a CDS node (or MPR) will receive the periodic > DD packets and send a LS Request if the CDS node has a more > recent LSA. This is similar to Clausen's proposal (both > are inspired by IS-IS) but is simpler and closer to OSPF. >=20 OK, thanks. When I take a next cut at that section, I will fold in those comments. Tom _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design