From exim@www1.ietf.org Tue Jul 1 03:25:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01453 for ; Tue, 1 Jul 2003 03:25:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h617P5P15192 for nsis-archive@odin.ietf.org; Tue, 1 Jul 2003 03:25:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XFVd-0003wX-Su; Tue, 01 Jul 2003 03:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XFVP-0003w4-Um for nsis@optimus.ietf.org; Tue, 01 Jul 2003 03:24:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01426 for ; Tue, 1 Jul 2003 03:24:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XFVG-0000V4-00 for nsis@ietf.org; Tue, 01 Jul 2003 03:24:38 -0400 Received: from mail5.telekom.de ([62.225.183.202] helo=mail1.telekom.de) by ietf-mx with esmtp (Exim 4.12) id 19XFV4-0000Ud-00 for nsis@ietf.org; Tue, 01 Jul 2003 03:24:26 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 1 Jul 2003 09:22:52 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Jul 2003 09:22:51 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB50D@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: mshore@cisco.com, hgs+nsis@cs.columbia.edu Cc: nsis@ietf.org Date: Tue, 1 Jul 2003 09:22:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [NSIS] [NSIS]: identifiers with global scope Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Melinda, Henning thanks for your clarifications. I fully agree with Melinda that the issue of "identifiers with global scope" needs some more discussion. Melinda mentions that there's "some agreement that [global IDs are] needed". And "there hasn't been sufficient discussion of namespace collision avoidance and there hasn't been discussion of how to avoid a proliferation of identifiers, the latter of which is a potential problem." What is lacking seems to be a concept how to make "identifiers with global scope" operational. There may be more "next steps of NSIS", but to me that is one which is important (I also like these identifiers). Should we solve the problem right now and go on? Or just define some "parameter" space and look for details later? In the latter case I'd prefer to have a "plan B", to be able to continue work if global IDs don't work. Practical solutions to the global ID scheme? A 32 bit number, globally unique. Should there be a fixed "per operator" code (AS number, country code, IP address/prefix, other) and a variable one? Only a variable one? How's the latter organised (I've got no expertise and the sole statement that 32 bit coding space is sufficient to avoid collisions doesn't help to much, even if I believe it). Or did I miss something and the 32 bit number is valid only in combination with an address or the like? Regards, Rudiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 1 07:07:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06175 for ; Tue, 1 Jul 2003 07:07:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61B76X22296 for nsis-archive@odin.ietf.org; Tue, 1 Jul 2003 07:07:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XIyT-0005k4-EW; Tue, 01 Jul 2003 07:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XIxW-0005fg-V5 for nsis@optimus.ietf.org; Tue, 01 Jul 2003 07:06:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06127 for ; Tue, 1 Jul 2003 07:05:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XIxQ-00028g-00 for nsis@ietf.org; Tue, 01 Jul 2003 07:05:56 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19XIxG-00028J-00 for nsis@ietf.org; Tue, 01 Jul 2003 07:05:46 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h61B4dIn021866; Tue, 1 Jul 2003 04:04:39 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJA43473; Tue, 1 Jul 2003 04:04:37 -0700 (PDT) Message-Id: <200307011104.AJA43473@mira-sjc5-c.cisco.com> To: "Geib, Ruediger" cc: hgs+nsis@cs.columbia.edu, nsis@ietf.org From: Melinda Shore In-Reply-To: Message from Ruediger.Geib@t-systems.com of "Tue, 01 Jul 2003 09:22:50 +0200." <9F8582E37B2EE5498E76392AEDDCD3FE03DBB50D@G8PQD.blf01.telekom.de> Date: Tue, 01 Jul 2003 07:04:37 -0400 Subject: [NSIS] Re: [NSIS]: identifiers with global scope Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > Practical solutions to the global ID scheme? A 32 bit > number, globally unique. Should there be a fixed "per > operator" code (AS number, country code, IP > address/prefix, other) and a variable one? Only a variable > one? How's the latter organised (I've got no expertise and > the sole statement that 32 bit coding space is sufficient > to avoid collisions doesn't help to much, even if I > believe it). Or did I miss something and the 32 bit number > is valid only in combination with an address or the like? A 32-bit number on its own is unfortunately insufficient to provide reasonable protection against collisions on its own. I think there are things we can do with high-resolution timestamps or cryptographically, but we're going to need more bits (potentially a lot more bits). This is not an uncommon problem and I expect there's been some useful work done already; a literature search is probably a good next step. I should add that I am not comfortable with a scheme that relies on a central registry. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 1 07:22:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06891 for ; Tue, 1 Jul 2003 07:22:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61BM3B26443 for nsis-archive@odin.ietf.org; Tue, 1 Jul 2003 07:22:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJD1-0006sP-Dg; Tue, 01 Jul 2003 07:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJCd-0006pf-RE for nsis@optimus.ietf.org; Tue, 01 Jul 2003 07:21:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06649; Tue, 1 Jul 2003 07:21:36 -0400 (EDT) Message-Id: <200307011121.HAA06649@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 01 Jul 2003 07:21:36 -0400 Subject: [NSIS] I-D ACTION:draft-mcdonald-nsis-qos-nslp-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Quality of Service NSLP for NSIS Author(s) : A. McDonald et al. Filename : draft-mcdonald-nsis-qos-nslp-00.txt Pages : 39 Date : 2003-6-30 This draft describes a protocol to be used for signaling QoS reservations in the Internet. It is compatible with the framework and requirements for such signaling protocols developed within NSIS; in conjunction with the NSIS Transport solution, it provides functionality comparable to RSVP: it is independent of the details of QoS specification, and adds support for a greater variety of reservation models, but is simplified by the elimination of support for multicast flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-qos-nslp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcdonald-nsis-qos-nslp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mcdonald-nsis-qos-nslp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30151108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-nsis-qos-nslp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-nsis-qos-nslp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151108.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 1 10:48:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03259 for ; Tue, 1 Jul 2003 10:48:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61Em1r06740 for nsis-archive@odin.ietf.org; Tue, 1 Jul 2003 10:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XMQL-0001kY-G3; Tue, 01 Jul 2003 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XMQI-0001k8-FY for nsis@optimus.ietf.org; Tue, 01 Jul 2003 10:47:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03225 for ; Tue, 1 Jul 2003 10:47:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XMQG-0005Go-00 for nsis@ietf.org; Tue, 01 Jul 2003 10:47:56 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19XMQ5-0005GK-00 for nsis@ietf.org; Tue, 01 Jul 2003 10:47:45 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h61El0s19181; Tue, 1 Jul 2003 09:47:01 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h61Ekwr01965; Tue, 1 Jul 2003 09:46:58 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HHCP26-0000XG-00; Tue, 01 Jul 2003 10:46:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16129.40668.946230.750994@gargle.gargle.HOWL> Date: Tue, 1 Jul 2003 09:46:52 -0500 From: Pete McCann To: Cc: , Subject: RE: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta13) "cauliflower" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, John, I don't think it's too soon to start considering this sort of interaction, especially because, as Hannes has indicated, there may be some impact on the NSIS protocol itself. Also, our hope is that we can make use of an IETF-specified Diameter application for the appropriate interfaces in the next release of 3GPP and 3GPP2 specifications, which means the sooner we can get started the better. We certainly intend to continue the discussion with Hannes and others on both the NSIS and AAA lists, as appropriate - hopefully the bandwidth we use will be tolerated by those not directly interested in the topic. -Pete john.loughney@nokia.com writes: > Hi Pete, > > Question for you - NSIS will obviously need some AAA interaction, > not just for QoS, but for middle box traversal (note, new NSIS > charter has been announced). > > It might be interesting to discuss this work in both AAA & NSIS, > but my feeling is that the AAA WG already has a lot to do. Perhaps > you could work with Hannes to incorporate aspects of the drafts > together. > > thanks, > John > > > -----Original Message----- > > From: ext Pete McCann [mailto:mccap@lucent.com] > > Sent: 26 June, 2003 23:20 > > To: nsis@ietf.org; aaa-wg@merit.edu > > Subject: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt > > > > > > > > Hi, > > > > We hope everyone who is interested in QoS/AAA has a chance to read the > > draft we have just submitted. > > > > Our work is definitely related to the 2 drafts-tschofenig that have > > been posted on the NSIS group (apologies for not acknowledging this > > explicitly in the draft, but we found them only recently and are still > > reading them). However, our work focuses more on the requirements for > > a AAA protocol rather than requirements for NSIS. Also, we are trying > > to set forth in our draft what we think is the proper relationship > > between NSIS/RSVP, AAA, and call control protocols like SIP. > > > > Please read/comment! > > > > -Pete > > > > Internet-Drafts@ietf.org writes: > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > > > > Title : Requirements for a QoS AAA Protocol > > > Author(s) : F. Alfano et al. > > > Filename : draft-alfano-aaa-qosreq-00.txt > > > Pages : 16 > > > Date : 2003-6-24 > > > > > > This document describes requirements for a protocol that would > > > perform Authentication, Authorization, and Accounting for > > Quality-of- > > > Service reservations. This protocol would be used by > > elements along > > > the path of a given application flow to authenticate a reservation > > > request, ensure that the reservation is authorized, and to account > > > for resources used during the life of the application flow. A QoS > > > AAA protocol should also support dynamic authorization of QoS as a > > > function of application and account state. While we assume the > > > existence of some QoS reservation protocol to allow endpoints to > > > request QoS from network elements, complete requirements > > for such a > > > protocol are outside the scope of this document and a QoS AAA > > > protocol could be used to support more than one kind of > > reservation > > > protocol. A QoS AAA protocol could be used between any > > bearer-level > > > network element that lies along the path of an application > > flow and > > > an application server that lies anywhere in the network, > > allowing for > > > a wide variety of flexible service deployment models. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-00.txt > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 1 11:08:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03867 for ; Tue, 1 Jul 2003 11:08:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61F82b09385 for nsis-archive@odin.ietf.org; Tue, 1 Jul 2003 11:08:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XMjh-0002RC-Fi; Tue, 01 Jul 2003 11:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XMjC-0002Ke-2f for nsis@optimus.ietf.org; Tue, 01 Jul 2003 11:07:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03844 for ; Tue, 1 Jul 2003 11:07:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XMj9-0005Rf-00 for nsis@ietf.org; Tue, 01 Jul 2003 11:07:27 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19XMit-0005Ra-00 for nsis@ietf.org; Tue, 01 Jul 2003 11:07:11 -0400 Received: from cs.columbia.edu (dyn-wireless-246-119.dyn.columbia.edu [160.39.246.119]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h61F6mf9015673 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jul 2003 11:06:49 -0400 (EDT) Message-ID: <3F01A37D.7030507@cs.columbia.edu> Date: Tue, 01 Jul 2003 11:06:37 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: "Geib, Ruediger" , hgs+nsis@cs.columbia.edu, nsis@ietf.org Subject: Re: [NSIS] Re: [NSIS]: identifiers with global scope References: <200307011104.AJA43473@mira-sjc5-c.cisco.com> In-Reply-To: <200307011104.AJA43473@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've talked about that in depth at the interim meeting. This is a well-known problem, also known as the "birthday problem". I picked a 128 bit random number as a reasonable compromise where the collision probability is way below the '5 nines' reliability threshold. For example, I computed the collision probability (using bc, the extended-precision library on Unix) for the case of d=2^127 and n=10,000, i.e., 10,000 simultaneous sessions in a node, using my suggested identifier length of 128 bits. The collision probability is approximated according to Eq. (5) in http://mathworld.wolfram.com/BirthdayProblem.html as .0000000000000000000000000000002938436127 Thus, this probability is far smaller than, say, the probability of winning the Powerball lottery (which is approximately .00000000125). For 32 bits, the collision probability increases to .011 (roughly, 1%), which is clearly too large. 64 bits yields .0000000000027102343806669673910162993043, which is also way below any other likely error contribution. I think I've gone through the other plausible alternatives for defining identifiers in an earlier message, and they all have fatal flaws in practical networks. (Plausible does not include a central mechanism for doling out numbers....) There is one other reasonable approach that combines a random, locally-unique identifier with a host IP address. This works as long as the host is not on an RFC-1918-addressed device. If we assume that the number of such devices is much smaller than the number of nodes overall, one could pick a combination of a short random identifier with the IP address. This seems dicier to me since there may well be two very large 1918-style networks that have a lot of flows between them. Henning Melinda Shore wrote: >>Practical solutions to the global ID scheme? A 32 bit >>number, globally unique. Should there be a fixed "per >>operator" code (AS number, country code, IP >>address/prefix, other) and a variable one? Only a variable >>one? How's the latter organised (I've got no expertise and >>the sole statement that 32 bit coding space is sufficient >>to avoid collisions doesn't help to much, even if I >>believe it). Or did I miss something and the 32 bit number >>is valid only in combination with an address or the like? > > > A 32-bit number on its own is unfortunately insufficient to > provide reasonable protection against collisions on its own. > I think there are things we can do with high-resolution > timestamps or cryptographically, but we're going to need > more bits (potentially a lot more bits). This is not an > uncommon problem and I expect there's been some useful work > done already; a literature search is probably a good next > step. > > I should add that I am not comfortable with a scheme that > relies on a central registry. > > Melinda > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 1 13:47:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08101 for ; Tue, 1 Jul 2003 13:47:53 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIN9K21654 for nsis-archive@odin.ietf.org; Fri, 27 Jun 2003 14:23:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vxrb-00058e-Ji; Fri, 27 Jun 2003 14:22:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuNU-0002NW-Nh for nsis@optimus.ietf.org; Fri, 27 Jun 2003 10:39:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28081 for ; Fri, 27 Jun 2003 10:01:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VtnS-0002pT-00 for nsis@ietf.org; Fri, 27 Jun 2003 10:01:50 -0400 Received: from mail5.telekom.de ([62.225.183.202] helo=mail1.telekom.de) by ietf-mx with esmtp (Exim 4.12) id 19VtnH-0002pD-00 for nsis@ietf.org; Fri, 27 Jun 2003 10:01:39 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 27 Jun 2003 10:07:40 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jun 2003 10:07:39 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB4FE@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: hgs+nsis@cs.columbia.edu Cc: nsis@ietf.org Subject: [NSIS] clarifications on schulzrinne-nsis-ntlp Date: Fri, 27 Jun 2003 10:07:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Henning, I've read your draft and would like to provide a brief feedback: I like the idea of using whatever transport is already there. I also = appreciate that space and ideas on security issues are provided. I don't understand how GIMPS works if a re-route occurs between = querying node and an already discovered next-hop peer. If you've = provided text I'd appreciate if you explain things more explicit. The state table seems to include information on the previous hop and on = "the existing transport and security assosiaction to the next-hop = peer". That's mentioned several times in the text. It may be added in = the paragraph "each node maintains a forwarding state table that = includes...". It's clear to me that several individual state table = entries may refer to the same previous/next peer entries. Two editorials: Section 2 mentions a "GTSP". Section 6 doesn't contain a "message SDU" (or message content), which = should at least be optional. I don't intend to start a detailed discussion. I'm rather asking for a = couple of clarifications by the author.=20 Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 1 23:22:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26031 for ; Tue, 1 Jul 2003 23:22:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XYC9-0003Q4-Sg for nsis-archive@odin.ietf.org; Tue, 01 Jul 2003 23:22:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h623M9Mh013131 for nsis-archive@odin.ietf.org; Tue, 1 Jul 2003 23:22:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XYC1-0003PI-86; Tue, 01 Jul 2003 23:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQR0-0001mJ-7S for nsis@optimus.ietf.org; Tue, 01 Jul 2003 15:04:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11547; Tue, 1 Jul 2003 15:04:40 -0400 (EDT) Message-Id: <200307011904.PAA11547@ietf.org> To: IETF-Announce: ; Cc: "RFC Editor" , "Internet Architecture Board" , nsis@ietf.org Date: Tue, 01 Jul 2003 15:04:39 -0400 From: Michael Lee Subject: [NSIS] Document Action: Requirements of a QoS Solution for Mobile IP to an Informatinal RFC Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'Requirements of a QoS Solution for Mobile IP' as an Informatinal RFC. This document is the product of the Next Steps in Signaling Working Group. The IESG contact persons are A. Mankin and J. Peterson _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 2 04:50:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28790 for ; Wed, 2 Jul 2003 04:50:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XdJS-0006sh-5X for nsis-archive@odin.ietf.org; Wed, 02 Jul 2003 04:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h628o24k026436 for nsis-archive@odin.ietf.org; Wed, 2 Jul 2003 04:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XdJQ-0006rp-SM; Wed, 02 Jul 2003 04:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XdIo-0006rH-Ji for nsis@optimus.ietf.org; Wed, 02 Jul 2003 04:49:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28753 for ; Wed, 2 Jul 2003 04:49:19 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XdIl-0007VN-00 for nsis@ietf.org; Wed, 02 Jul 2003 04:49:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19XdIk-0007VK-00 for nsis@ietf.org; Wed, 02 Jul 2003 04:49:18 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h628nJ929496 for ; Wed, 2 Jul 2003 11:49:19 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 2 Jul 2003 11:49:21 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Jul 2003 11:49:18 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Jul 2003 11:49:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt Date: Wed, 2 Jul 2003 11:49:11 +0300 Message-ID: Thread-Topic: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt Thread-Index: AcM/36bh3JKkzNRTS8G9TrLyruilmAAlvflw To: Cc: , X-OriginalArrivalTime: 02 Jul 2003 08:49:17.0437 (UTC) FILETIME=[D24212D0:01C34076] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Pete, > I don't think it's too soon to start considering this sort of > interaction, especially because, as Hannes has indicated, there may be > some impact on the NSIS protocol itself. Also, our hope is that we > can make use of an IETF-specified Diameter application for the > appropriate interfaces in the next release of 3GPP and 3GPP2 > specifications, which means the sooner we can get started the better. >=20 > We certainly intend to continue the discussion with Hannes and others > on both the NSIS and AAA lists, as appropriate - hopefully the > bandwidth we use will be tolerated by those not directly interested in > the topic. I think if we breakdown the problem into near term and longer term, the Diameter based solution is a good approach for the near term & may help generate useful material for the longer-term impact on NSIS. I don't see a problem discussing this on NSIS. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 2 16:18:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11680 for ; Wed, 2 Jul 2003 16:18:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo3N-0001U4-4v for nsis-archive@odin.ietf.org; Wed, 02 Jul 2003 16:18:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KI9O8005705 for nsis-archive@odin.ietf.org; Wed, 2 Jul 2003 16:18:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo3F-0001Q2-So; Wed, 02 Jul 2003 16:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo2a-0001HX-Cp for nsis@optimus.ietf.org; Wed, 02 Jul 2003 16:17:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11527 for ; Wed, 2 Jul 2003 16:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xo2W-0006x3-00 for nsis@ietf.org; Wed, 02 Jul 2003 16:17:16 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Xo2V-0006w3-00 for nsis@ietf.org; Wed, 02 Jul 2003 16:17:15 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h62KGUs05653; Wed, 2 Jul 2003 15:16:30 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h62KGSJ05058; Wed, 2 Jul 2003 15:16:28 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HHEYZB-0000R8-00; Wed, 02 Jul 2003 16:16:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16131.15765.566662.52588@gargle.gargle.HOWL> Date: Wed, 2 Jul 2003 15:16:21 -0500 From: Pete McCann To: Tschofenig Hannes Cc: "'john.loughney@nokia.com'" , nsis@ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFF52@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F03BBFF52@mchp905a.mch.sbs.de> X-Mailer: VM 7.14 under 21.5 (beta13) "cauliflower" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tschofenig Hannes writes: > hi pete, > > as promised i have read your draft and provided some comments inline. please > take a look at: > > http://www.tschofenig.priv.at/comments/draft-alfano-aaa-qosreq-00-hannes.txt > > it is good that you join the discussion. > > ciao > hannes Hi, Hannes, Thanks for your detailed comments - unfortunately it is more difficult for me to post files to the web on short notice, so I will try to respond to each of your points in this e-mail, deleting most of the draft text. See below... # please see my comments inline. # general comment: # # it is good that someone finally joins the aaa/qos discussion. i # always had the impression that there are a number of things that # need to be discussed. It's good to find your work in progress here in NSIS: hopefully we can work together to produce something useful. # Section 1 discusses a number of issues which are not applicable for # AAA and QoS reservations (my opinion). The Introduction tries to motivate the scope of the work; perhaps it wouldn't be appropriate for the final requirements document, at least not in its current form. (but see below) # For the purpose of authorization it is not relevant which protocols # (nsis, rsvp, etc.) carry the qos request to the network. Yes, I agree - section 1 is just an introduction, and is an attempt to motivate the work in the context of several different reservation protocols. Note that our draft is a set of requirements for a AAA protocol, not a set of requirements for NSIS. # it would be good to have the documents more generic, link layer and # 3gpp (or similar) independent. Understood; the 3G examples are given simply as motivation. In particular, we think that some of the current architectures for authorizing QoS may be harmful, as they may tend to limit the deployability of new services by linking the signaling plane to the bearer plane in a certain inflexible way. The body of the document should be generic. # the term bearer is not used in nsis. We use this to refer to anything that is on the path of the application flow or to the resources used to support the application flow. Can you suggest the proper NSIS term? I guess we are showing our bellhead colors here... there will be no need to manage them with a reservation protocol. Also, if the transport or application layers can provide self- correcting congestion control, it may be possible to operate the network even with high utilization and still meet the QoS requirements of the various applications. # this is a motiviation for not using qos at all. Yes, it's one scenario where you don't necessarily need to signal for resources, and is designed to set up a contrast with the remainder of the paragraph... However, when bandwidth is expensive and must be carefully managed, such as in wide-area cellular networks, and/or when applications and transport protocols lack the capability or cannot be trusted to perform congestion control, explicit reservation techniques are required. Note that a reservation protocol might be used regardless of the mechanisms used to enforce QoS, e.g., IntSrv or DiffSrv. ... Despite the advantages of closer coupling between application and bearer, the use of private, local interfaces between SIP servers and the bearer path leads to several disadvantages: * Use of SIP servers other than the ones provided by the operator becomes more difficult. * Deployment of some new applications requires close coordination with the network operator. * It becomes impossible to handle mobility at the network layer when a change in the bearer element point of attachment to the Internet requires a change in the associated SIP server. * Use of protocols other than SIP to establish sessions becomes impossible. # I would like to understand the motivation for the tight # coupling between an application and a QoS signaling protocol. See the previous paragraphs in the draft; however, what is not covered there explicitly is the desire on the part of operators to participate in more than just transport of IP packets. They do this by preventing bearer application flows until some SIP server in their network says it is OK. Now, that may or may not be a good idea, but it seems to be a reality of the current 3G architectures. We think that by opening up a QoS/AAA interface, and by doing this work in the IETF, we can at least make sure that the interface between application and bearer is an open, inter-domain one and allows for application servers to be placed anywhere on the Internet, assuming they can connect to the AAA cloud. That will allow for easy deployment of new applications, in keeping with the end-to-end principle. # - which application knowledge is sometimes needed Sometimes it is just the fact that some particular application server participated in the call set-up. # - the should be a clearer distinction between " the qos protocol # obtains information from the application signaling protocol" and "tight coupling". We can work on this for the next version. # - does this related a bit to john's draft draft-ietf-sipping-aaa-req-03.txt? Only indirectly. I think sipping-aaa is an attempt to capture the requirements of a AAA protocol that would support SIP. That is, you need to authenticate & authorize registrations, INVITEs, etc. In contrast, we are proposing a AAA protocol that would be used to authenticate QoS reservation requests. Now, the reservation requests may have been triggered after some SIP interaction took place, but that is just happenstance --- in general there is no need to execute SIP prior to a QoS reservation request. ... To meet the requirements of network operators while at the same time preserving the best of the end-to-end Internet service model, we propose that a AAA protocol be developed that can be used by bearer elements to authenticate, authorize, and account for individual application flows that require QoS. # there is already a aaa protocol used for this purpose => # # [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, # R., Sastry, A.: "The COPS(Common Open Policy Service) Protocol", RFC # 2748, January, 2000. # # [RFC2749] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, # R., Sastry, A.: "COPS usage for RSVP", RFC 2749, January, 2000. # # [RFC2750] Herzog, S.: "RSVP Extensions for Policy Control", RFC # 2750, January, 2000. # # is this insufficient for your purpose? COPS is one approach, but my personal bias would be to do this sort of thing with Diameter. Mainly, this is because the 3GPP2 operators will already have an inter-domain AAA infrastructure based on RADIUS (hopefully evolving to Diameter) and it would be good to re-use this infrastructure for QoS authorization as well as basic network access authentication. I don't mean to restart the COPS vs. Diameter thread here, but I think Diameter has some advantages over COPS. ... +------+ +------+ | Subs | | | | DB | | AS | | | | | +---\--+ +---/--+ \ / \ / /-\----------/\ //// \\\\ || || | AAA Cloud | || || \\\\ //// \-------+-----/ | +---+--+ Application | | Flow ===============+ BE +==========>> | | +------+ Figure 1. An architecture supporting QoS-AAA Figure 1 depicts a bearer element # why is it necessary to talk about bearer elements? These are the nodes that would process NSIS (or other reservation) messages, i.e., the IP routers along the path of the flow. # what is the subs db? This is short for "Subscriber Database" --- it would be (or be "behind") the home AAA server, and would store information about the subscription, i.e., what sorts of QoS the user is allowed. # what information is used to compute this authorization decision? If the subscriber database is used, it might just be a check of the requested QoS (and perhaps the link type and/or some other indication of cost) against what the user has signed up for. If an application server is used, it might be a check of the requested QoS against the e.g., SIP SDP that was negotiated. In more complex deployment models, the authorization will be based on dynamic application state, so the request must be authenticated and authorized based on information from one or more application servers. # what information would you like to use to compute this authorization decision? # how does the message flow look like? We could get into that in a protocol document; I'm not sure it belongs here in the requirements. At a high level, I think the bearer element would pick up the QoS request, and then send a AAA message to the authorizing entity containing various parameters of the request. The authorizing entity would then consult internal data structures and return a yea/nay response. Also, the authorizing entity could update the bearer element proactively if the subscriber profile changes or if the application state changes. If defined properly, the interface between the bearer element and AAA cloud would be identical in both cases. # the interface propably but the message routing seems to be more complex since # some information from the application server needs be incorporated? I'm not sure it has to be. Assuming there is an identifier for an "authorizing entity" and that entity has the ability to update the bearer element dynamically, we can really hide the details of what kind of authorizing entity is being used. However, I think it's important to talk about application servers explicitly in the requirements so that we know what role they will be playing in the overall architecture. ... Termination Actions On-line accounting allows for the on-line accounting authorization entity to terminate flows in real time. A termination action defines the action to be taken by the bearer element for the case where a flow has been terminated. For example flow packets might be dropped, might be redirected, or might be allowed to continue but not be counted. # the term "On-line accounting" is new to me? is it something similar to real-time credit control? Yes, also called "pre-paid." We should be more explicit about that. ... 4.1 Identity Information The QoS signaling protocol MUST carry information sufficient to identify an authorizing entity for a QoS request. For instance, the identity may be represented as the NAI of a user or FQDN of an application server. # this requirement is already included in the nsis requirements draft. in section # 5.7.1 "Authentication of signaling requests" we require that the entity requesting resources # has to be authenticated. Ok, good. Again, our document is intended to be a requirement for a AAA protocol rather than NSIS, but we thought it was important to list at least the basic attributes that must be supported by a reservation protocol. This sort of requirement may or may not go into a final requirements document, depending on what the WG thinks. 4.2 Flow Information The QoS signaling protocol MUST carry information sufficient to identify the application flow(s). # this is a natural requirement for qos signaling and therefore covered by the nsis requirements draft. Ok, good, but see above. However, the protocol MUST allow flow information to be under-specified ("wild carded") in the case when specific endpoints are not known at the time of resource reservation. # this is a new requirement. why would you like to specify wildcards? # wildcards for what (ports, ip addresses, transport protocol; source or destination ? # that might raise a number of questions! This is just an attempt to capture e.g., the wildcard sender selection supported by RSVP. Depending on the signaling protocol, the endpoint may or may not have complete information about the sender IP address/port, and may only have a range of destination ports... anyway, we are open to re-wording this. 4.3 Authentication Information # the subsection title does not match the content Could you be more specific? Do you not think that checking the integrity of a message is a form of authentication? The QoS signaling protocol MUST be integrity protected. # covered by requirement 5.7.3 Integrity protection See above with respect to requirements on a generic reservation protocol in this document. For example, each message could carry a cryptographic message authentication code to ensure that only valid requests are granted by the network. This is especially important when a user is being held responsible for charges associated with a QoS session. # how would you enable that? "held responsible for charges" sounds like non-repudidation I'm not sure we need a strong form of non-repudiation (really, that would require MACs on every packet in the flow!) but at least we should have an initial/periodic authenticated request. ... 5.1 Inter-domain Support The QoS AAA protocol MUST support inter-domain operation where the bearer elements, subscriber databases, and application servers can each belong to different administrative domains. # covered by the fact that mobility is a goal for nsis. # additionally we specified "5.9.4 SHOULD provide hooks for AAA protocols " This one is important for the AAA protocol, and not necessarily covered by the 2 NSIS requirements you quote. It is possible to have a mobile-aware NSIS that provides hooks for AAA, but where the supporting AAA infrastructure does not support inter-domain operation. This is a critical point that we want to ensure is addressed by the AAA protocol. ... 5.2 Identity-based Routing The QoS AAA protocol MUST route AAA requests to the authorizing entity based on the identity information given in the QoS signaling protocol. # this is the general procedure. Clearly, this requirement could easily be met by a Diameter or RADIUS protocol, but I don't think its a "general procedure" of NSIS, right? ... 6.1 Authentication Check The QoS AAA protocol MUST support verification of authentication information present in QoS signaling messages. # should this requirement be combined with 4.1 and 4.3 of the previous section? Again, this section covers the AAA protocol, whereas Section 4 covers the QoS reservation protocol. ... 7.1 Flow Information The QoS AAA protocol MUST carry flow information to and from the authorizing entity. # is this a typo? how should the authorizing entity know information about the flow? # what whould the authorizing entity do with the flow information? # between which entity is the flow information carried? The idea is to carry the flow information from the bearer element (e.g., NSIS signaling-aware node) to the authorizing entity, so that it can be matched against the application-layer signaling that was carried out. For example, if SIP is the upper layer signaling, and the authorizing entity is a SIP server, you would check that the SDP matched the flow requested in the NSIS signaling. ... However, the protocol MUST allow flow information to be under-specified ("wild carded") in the case when specific endpoints are not known at the time of initial resource authorization. # hmm. i am not sure that i really understand what you really need this for. See discussion above in section 4. Maybe we need to re-state these requirments. 7.2 Application State Pointer The QoS AAA protocol MUST carry information sufficient for an application server to identify the appropriate application session. Note that this requirement might be met by the same mechanism as for requirement 7.1, if flow information alone is sufficient to identify an application session. # nsis adds a session identifier? would that be useful? An NSIS session identifier wouldn't necessarily help the authorizing entity find the session information - it would be more like a token that would appear separately in the NSIS signaling, and which would be carried via AAA to the authorizing entity. 7.3 Dynamic Authorization The QoS AAA protocol MUST support dynamic authorization; that is, it MUST be possible to push updates towards the bearer element(s) from authorizing entities. # what do you call "dynamic authorization"? # is a authorization request which is given an answer? The authorization state may change even after the initial (successful) authorization. For instance, if the user's subscription is updated to remove QoS service, we may need to revoke an existing session. Similarly, if the application state changes, the corresponding QoS session may need to be revoked. This requirement would support runtime changes to a subscriber profile or application state transitions that would authorize/de- authorize application flows. # this sounds like assynchronous notifications from the user's home # network (in case of profile changes) to the networks where the user reserved # resources. Yes, exactly. # what information is contained in the profile that would require such a notification? For example, an upgrade/downgrade to a subscriber's allowed bandwidth. ... The QoS AAA protocol MUST allow the authorizing entity to gate authorized application flows. # this sounds to me like an interworking with midcom. # i would like to make sure that i correctly understood this issue: # an unsuccessful qos authorization would cause packet filters to be installed that # data traffic is disallowed to flow? At least, the packet filters would *not* be installed to support QoS for that flow. Perhaps also the (best effort) packets would be discarded, but this is harder to justify. ... 8.1 Accounting Records The QoS AAA protocol MUST define QoS accounting records containing duration or volume (bytecount) usage information, or both duration and Volume usage information. The records MUST also contain a description of the QoS attributes (e.g., bandwidth, delay, loss rate) that were supported for the flow. # this sounds like a useful requriement. haven't other groups (such as the 3gpp, packetcable or 3gpp) # worked on similar things? Yes, there are various accounting formats defined; hopefully the IETF could define the generic "IP-layer" accounting for QoS that would be useful to a wide variety of specific link layers. 8.2 Accounting Rules The QoS AAA protocol MUST allow the authorizing entity to transfer accounting rules that are applicable to specific flows. These rules would define the on-line ("pre-paid") versus off-line ("post-paid") nature of the accounting as well as convey other associated parameters such as record identifiers, rating information, usage quota, on-line termination actions, etc. # why would the authorizing entity exchange such rules? most information is # already available to the pep (such as flow identifier, qos objects, session id, etc.) The rules are not what to do with the traffic; rather, they are how to count the traffic. For example, you should be told whether to count different senders in distinct buckets, or count everything for a single reservation together. If pre-paid is used, you should be told how much quota is available and in what units it is represented. These all fall under the generic term "Accounting Rules". Perhaps we need to expand on these. # why does accounting of qos differ so much from traditional accounting (except for some new # fields describing the qos parameters)? Maybe it wouldn't, but at least pre-paid might have some impact over and above "traditional" accounting (not sure which tradition you are making reference to, of course). The QoS AAA protocol MUST allow for accounting rules to be provided at authorization time as well as to be pushed later as dynamic updates. # which protocol provides such a capability (radius, diameter, cops)? Again, our bias is towards Diameter, but you can clearly do this sort of thing in both RADIUS and COPS with the right extensions/modifications. 8.3 Sending Accounting Records The bearer element MUST send accounting records for a particular application flow to the authorizing entity for that flow or to another entity identified by the authorizing entity. # previously i had the impression that you would like to send an initial authorization request around. # this requirement, however, sounds like shipping accounting records around and asking for an authorization # based on these accounting record. It wasn't intended that way: this requirement simply requires accounting records to be sent. The destination for the accounting records depends on who authorized the session. 8.4 Loss of Bearer Notification Requirements The QoS AAA protocol MUST allow the bearer element to report loss of bearer to the authorizing entity. # isn't it possible to specify this requirement as a "termination" reason. Yes, that might be a more generic way to put it. # i guess a loss of bearer is more relevant for network access in general. # how do you detect a loss of bearer in general. some link layer mechanisms do not provide # such a mechanism. Right, but this is a key requirement of some of the 3G deployments. Cellular link layers, especially when a voice call is ongoing, are very connection-oriented and a loss of bearer indication is in fact available. 8.5 Accounting Correlation The QoS AAA protocol MUST support the exchange of sufficient information to allow for correlation between bearer accounting records and application accounting records. # what type of information must be exchanged? Might just be the session ID / token I mentioned above. ... 9. Interaction with other AAA Applications It is likely that an endpoint attached to a first-hop bearer element was authenticated and authorized for basic, best-effort Internet access prior to requesting any special QoS from the network. If the subscriber database for basic network access is the same as the one containing a QoS subscription, it may be expeditious to define some interactions between the AAA protocol used for basic access (e.g., NASREQ [10]) and the one outlined here for QoS. For example, it may be useful to return some QoS-related attributes to the first-hop bearer element at the time the endpoint is granted basic, best-effort access. # This is an often mentioned example. I am, however, not sure whether it is # really useful. What it really make sense to send information like # 'user x is allowed to request max 5mbits for a duration of 10 min, then only # 3 mbits (but only during weekdays)' # what type of policies would you send around? The example you give actually sounds very similar to the pre-paid accounting application being developed by 3GPP2! There is a notion of a "Tariff Switch" event that would happen at a given time-of-day, and this time is given to the NAS when the user is authorized. When the tariff switch occurs, the rating for the call might change (i.e., 10c/minute before 7pm, 5c/minute after). Anyway, it doesn't always have to be that complicated. There might be a simple profile like "this user is authorized for 2Mbit/sec when connecting via WLAN, or 100kbit/sec when connecting via cdma2000". # i often have the impression that this sounds great but has no # practical value. i have also listed it in the aaa draft but later # got the impression that this is the difficult to accomplish. I wouldn't dismiss it so quickly. # what information is stored in the user profile that could be used # for this purpose? is is desired by the user's home network provide # to distribute this type of information? this also assumes that the # user profile is sort-of standardized. this is, however, not the # case. Home operators definitely will want to distribute such information. We can help with the standardization here in the IETF. ... Also, it may be useful to allow application servers to push QoS authorization information to a bearer element prior to any explicit request from the endpoint. This could support application endpoints that do not support an explicit QoS signaling mechanism. In this case, the authorization may be pushed via the home AAA server, which presumably knows to which NAS the endpoint is currently attached. Alternatively, the QoS AAA protocol may define some sort of redirection facility that would allow application servers to send AAA messages directly to selected bearer elements such as a NAS. # huch - that is certainly not easy to accomplish. there are a number # of assumptions in there we need to be clarified. Yes indeed - but I think it's clear that the Home AAA server that authorizes basic IP access will have some information that could be made available to other applications, especially if they are Diameter applications running on the same server. ... The application endpoint makes a request for resources from the bearer element. The video server and the bearer element will verify that the application endpoint has not requested more resources than what were negotiated and for which the application has agreed to be financially responsible. # this bearer element is somewhat confusing. whatis the relationship between # the video server, application end point and bearer element? # what is the trust relationship between these entities? Sorry, terminology problem again. Think of the bearer element as any NSIS-aware IP router. It has the same degree of trust as any IP router between server and application endpoint. In addition, it may have a special relationship with the server (possibly via AAA brokers) so that the server is allowed to authorize QoS sessions, even if the subscriber's profile on its own wouldn't normally allow it. ... 11. Security Considerations The QoS AAA protocol whose requirements are given in this draft assumes that a security relationship exists between the authorizing entity (the home AAA server or application server) and the bearer element (AAA client). # this is a rather strong assumption. that might not be true in all cases. It seems like precisely the relationship that is required: think about it. The bearer element is making a decision about whether to admit a flow. It consults an authorizing entity. In order to trust the result from the authorizing entity, there must be a (possibly indirect) security relationship in place. This relationship implies that the bearer element should grant service based on the say-so of the authorizing entity, presumably because the used resources will be paid for in some later settlement phase. # payment is provided later only? # what about pre-paid cards which require real-time credit control. Yes, we should re-word it to allow that. The relationship may be direct or it may be indirect via a AAA cloud consisting of brokers and proxies. Each link in this chain of relationships MUST be secured to prevent spoofed authorizations. # securing the aaa interaction does not prevent spoofing since the end point is authenticated. # is entity authentication between the user and the home network required with every qos reservation request? # (or is data origin authentication sufficient?) The security referenced here is between bearer element and authorizing entity, possibly via AAA proxies. To answer your question, yes, I think that if any AAA interaction is done at a given NSIS node, then every QoS reservation should be independently authenticated. The authentication outlined in Section 6 MUST be cryptographically strong and protected against replay and other attacks. Once QoS resources have been authorized, it may be possible for an unauthorized party to subvert them for its own use. Steps MUST be taken to bind the authorization to the actual flow of packets using the QoS bearer in the bearer element. # this can actually only be prevented if the data traffic is cryptographically protected (either link layer or network layer # protection). do you mandate this? No, I would not. But we can at least make sure that the packets using the QoS actually match the transport endpoints authorized by an application. Actual mechanisms applied to the bearer traffic for this purpose might include, e.g., ingress filtering and/or IPSec, but in general are beyond the scope of a QoS AAA protocol. # ingress filtering does not prevent all attacks. No, but it would make the QoS reservation useless unless the spoofed traffic was carrying the same source IP address/port. -Pete _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 2 16:34:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13387 for ; Wed, 2 Jul 2003 16:34:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoIj-0002un-Hv for nsis-archive@odin.ietf.org; Wed, 02 Jul 2003 16:34:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KY1wt011203 for nsis-archive@odin.ietf.org; Wed, 2 Jul 2003 16:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoIj-0002ub-ED; Wed, 02 Jul 2003 16:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoHn-0002hy-Vf for nsis@optimus.ietf.org; Wed, 02 Jul 2003 16:33:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12902; Wed, 2 Jul 2003 16:32:57 -0400 (EDT) Message-Id: <200307022032.QAA12902@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 16:32:57 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rsvp-sec-properties-02.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : RSVP Security Properties Author(s) : H. Tschofenig Filename : draft-ietf-nsis-rsvp-sec-properties-02.txt Pages : 43 Date : 2003-7-2 This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done with RSVP and to capture the knowledge about past activities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-rsvp-sec-properties-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-rsvp-sec-properties-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rsvp-sec-properties-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rsvp-sec-properties-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161657.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 2 16:34:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13399 for ; Wed, 2 Jul 2003 16:34:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoIk-0002vP-3y for nsis-archive@odin.ietf.org; Wed, 02 Jul 2003 16:34:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KY2KN011238 for nsis-archive@odin.ietf.org; Wed, 2 Jul 2003 16:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoIj-0002vA-Vl; Wed, 02 Jul 2003 16:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoHr-0002kA-DN for nsis@optimus.ietf.org; Wed, 02 Jul 2003 16:33:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12936; Wed, 2 Jul 2003 16:33:02 -0400 (EDT) Message-Id: <200307022033.QAA12936@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 16:33:01 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-threats-02.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Security Threats for NSIS Author(s) : H. Tschofenig, D. Kroeselberg Filename : draft-ietf-nsis-threats-02.txt Pages : 22 Date : 2003-7-2 This threats document provides a detailed analysis of the security threats relevant for the NSIS working group. It motivates and helps to understand various security considerations in the NSIS Requirements, Framework and Protocol proposals. This document does not describe vulnerabilities of specific NSIS protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-threats-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-threats-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-threats-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-threats-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161708.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 2 18:11:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24018 for ; Wed, 2 Jul 2003 18:11:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xpob-0000sX-8e for nsis-archive@odin.ietf.org; Wed, 02 Jul 2003 18:11:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62MB1eD003374 for nsis-archive@odin.ietf.org; Wed, 2 Jul 2003 18:11:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xpob-0000sK-5S; Wed, 02 Jul 2003 18:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xpns-0000gv-Ua for nsis@optimus.ietf.org; Wed, 02 Jul 2003 18:10:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23556; Wed, 2 Jul 2003 18:10:10 -0400 (EDT) Message-Id: <200307022210.SAA23556@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 18:10:09 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-02.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Analysis of Existing Quality of Service Signaling Protocols Author(s) : J. Manner et al. Filename : draft-ietf-nsis-signalling-analysis-02.txt Pages : 35 Date : 2003-7-2 This document reviews some of the existing QoS signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid the mistakes during the design and the implementation of any new protocol in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-signalling-analysis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-signalling-analysis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2181348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-signalling-analysis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-signalling-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2181348.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 2 18:59:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24025 for ; Wed, 2 Jul 2003 18:11:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xpob-0000tB-Ps for nsis-archive@odin.ietf.org; Wed, 02 Jul 2003 18:11:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62MB1rN003414 for nsis-archive@odin.ietf.org; Wed, 2 Jul 2003 18:11:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xpob-0000sy-LU; Wed, 02 Jul 2003 18:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xpoa-0000s4-7z for nsis@optimus.ietf.org; Wed, 02 Jul 2003 18:11:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23855; Wed, 2 Jul 2003 18:10:53 -0400 (EDT) Message-Id: <200307022210.SAA23855@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 18:10:52 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-03.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Next Steps in Signaling: Framework Author(s) : R. Hancock et al. Filename : draft-ietf-nsis-fw-03.txt Pages : 45 Date : 2003-7-2 The Next Steps in Signaling working group is considering protocols for signaling information about a data flow along its path in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for such signaling protocols. This document provides a model for the network entities that take part in such signaling, and the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with a separate upper layers for each specific signaling application. An initial proposal for the split between these layers is given, describing the overall functionality of the lower layer, and discussing the ways that upper layer behavior can be adapted to specific signaling application requirements. This framework also considers the general interactions between signaling and other network layer functions, specifically routing and mobility. The different routing and mobility events that impact signaling operation are described, along with how their handling should be divided between the generic and application-specific layers. Finally, an example signaling application (for Quality of Service) is described in more detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-fw-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-fw-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2181748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-fw-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-fw-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2181748.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 3 06:14:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04864 for ; Thu, 3 Jul 2003 06:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y16H-0006iZ-Tj for nsis-archive@odin.ietf.org; Thu, 03 Jul 2003 06:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63AE1BI025824 for nsis-archive@odin.ietf.org; Thu, 3 Jul 2003 06:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y16H-0006iP-Fe; Thu, 03 Jul 2003 06:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y16A-0006iE-Cc for nsis@optimus.ietf.org; Thu, 03 Jul 2003 06:13:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04859 for ; Thu, 3 Jul 2003 06:13:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y166-0004vK-00 for nsis@ietf.org; Thu, 03 Jul 2003 06:13:50 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19Y165-0004vE-00 for nsis@ietf.org; Thu, 03 Jul 2003 06:13:49 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 11:13:20 +0100 Message-ID: From: "Hancock, Robert" To: Henning Schulzrinne Cc: nsis@ietf.org Subject: RE: AW: [NSIS] framework: proposal on congestion/flow control Date: Thu, 3 Jul 2003 11:13:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi henning, > > in my view, the cost of congestion control is not the per-packet > > processing overhead; it's the architectural constraint that (so far > > as we all can tell, I think) you can't send messages without > > knowing what congestion control state to apply, i.e. which > peer you are > > sending to. so, applying congestion control directly to > PATH messages > > (for example) is liable to be non-trivial. > > This depends. I just submitted a draft, temporarily at > http://www.cs.columbia.edu/~hgs/nsis/gimps/draft-schulzrinne-n > sis-ntlp-00.html > that tries to find a compromise similar to all existing > congestion-controlled transport protocols: the first small message is > (congestion-control) free. To be more precise, if you know > where you are > going, by previous state or some external knowledge (e.g., all your > non-local messages go through a border router or you are running a > link-state routing protocol that somehow conveys this > information or all > your routers support NTLP), you use an existing congestion-controlled > association. Large messages that could cause congestion > themselves are > always subject to congestion control. > > After all, TCP SYN and kin aren't congestion controlled, > either, except > that their loss causes exponential back-off. I think the best we can > hope to do is to mimick this behavior in environments where the first > message goes off into the blue yonder. I am familiar with the concepts you describe in that draft ... It's clear that something can be done. The key point i was trying to make was that the concept of a 'congestion controlled association' which you can use because 'you know where you are going' is hard to match with the use of PATH-like methods for refresh/route change probing. Some people think that's a big deal, some don't, but that's the point which needs to be confronted and resolved (IMHO). > > [As an aside, we've just finished writing an NSLP > definition which optionally > > sends some messages outside the NTLP like this, to skip > processing in network > > interior nodes - very like rfc3175 in fact. but it's very > hard to be convincing > > that the result is network friendly overall. i'd be much > happier with a > > congestion-controlling NTLP that was able to bypass > interior nodes the same > > way. I suspect that argument is still to come.] > > Nothing prevents 'short-cut' or 'express' NTLP connections, > in general. > This is just a matter of trivially tuning the discovery mechanism. > Broadly, I agree with you, and I'd be happier with a protocol that allowed this sort of 'express routing'. How it is done of course depends on what the rest of the protocol looks like (e.g. does it even have an identifiable discovery mechanism to be tuned in the first place). There are two additional points I would emphasise: a) Sometimes you really want messages to be routed through intermediate NSIS-aware (but NSLP-unaware) nodes, but processed statelessly (e.g. flow-id re-writing in a NAT, or imposing a policy forwarding rule). So, it's hard to have the intermediate nodes completely drop out of the picture. b) For scaling/aggregation reasons, you may want to be able to have some messages bypass a lot of NSIS processing in interior nodes. 3175 grabs a new protocol number and suggests modifications to the router alert option to achieve this. We haven't really looked at this up to now. cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 3 06:16:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04918 for ; Thu, 3 Jul 2003 06:16:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y18E-0006oB-5T for nsis-archive@odin.ietf.org; Thu, 03 Jul 2003 06:16:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63AG2fB026166 for nsis-archive@odin.ietf.org; Thu, 3 Jul 2003 06:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y18E-0006nw-1F; Thu, 03 Jul 2003 06:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y17I-0006nA-3C for nsis@optimus.ietf.org; Thu, 03 Jul 2003 06:15:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04883 for ; Thu, 3 Jul 2003 06:15:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y17E-0004vb-00 for nsis@ietf.org; Thu, 03 Jul 2003 06:15:00 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19Y17D-0004vU-00 for nsis@ietf.org; Thu, 03 Jul 2003 06:14:59 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 11:14:30 +0100 Message-ID: From: "Hancock, Robert" To: Henning Schulzrinne , Melinda Shore Cc: "Geib, Ruediger" , hgs+nsis@cs.columbia.edu, nsis@ietf.org Subject: RE: [NSIS] Re: [NSIS]: identifiers with global scope Date: Thu, 3 Jul 2003 11:14:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, There appear to be two or three different issues on the table here. The one identifier that we know needs global scope is the session identifier (f/w section 4.6.2). I believe (like Henning) that uniqueness problems for these can be solved by providing more bits and using good random number generators. (Essentially I believe this for the same reason that I believe that cryptographic security is possible without using one-time pads). That doesn't mean there are no issues with the session identifier, and Hannes has written a draft recently specifically about them (they are mainly security related). However, the session identifier format and generation mechanism shouldn't have much impact on the NTLP design. The origin of this particular discussion is a different identifier, the MESSAGE_ID in the shore draft. I have to confess to being unclear about the role it is supposed to play, but on the assumption that the NTLP role is just to deliver messages between adjacent NSIS nodes, I'd be rather shocked to find a) global scope was needed, or b) it was visible outside the NTLP. The message ID needs to be qualified with some message source identification, but hopefully this shouldn't be as hard as wanting (a). The main problem would be NAT traversal (as usual). There is a more general (and more fundamental) point here: in discussions up to now we have aimed for both a fairly strict NTLP/NSLP separation, and also for a fairly strict 'locality' of NTLP operation (i.e. between adjacent peers only). These are not just theological obsessions, they are the fundamental mechanisms to enable us to have a protocol suite which can evolve (by adding new signalling applications, or by improving NTLP performance, or whatever) without needing coordinated upgrades across the whole Internet. Remember, the main reason we are doing this work this way at all is that RSVP has proven impossible to extend in this way because the layering of it is not so strict. (And this also implies - at least to me - that directly re-using protocol components out of 2961, which is equally un-layered, is not likely to be the best approach. We have to re-use the ideas, of course.) If anyone thinks this is all wrong or misguided, they could comment to that effect on the relevant sections of the framework draft (currently -03 version). see you all in Vienna. robert h. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 01, 2003 16:07 > To: Melinda Shore > Cc: Geib, Ruediger; hgs+nsis@cs.columbia.edu; nsis@ietf.org > Subject: Re: [NSIS] Re: [NSIS]: identifiers with global scope > > > I've talked about that in depth at the interim meeting. This is a > well-known problem, also known as the "birthday problem". I > picked a 128 > bit random number as a reasonable compromise where the collision > probability is way below the '5 nines' reliability threshold. > > For example, I computed the collision probability (using bc, the > extended-precision library on Unix) for the case of d=2^127 and > n=10,000, i.e., 10,000 simultaneous sessions in a node, using my > suggested identifier length of 128 bits. The collision probability is > approximated according to Eq. (5) in > http://mathworld.wolfram.com/BirthdayProblem.html as > > .0000000000000000000000000000002938436127 > > Thus, this probability is far smaller than, say, the probability of > winning the Powerball lottery (which is approximately > .00000000125). For 32 bits, the collision probability increases to > .011 (roughly, 1%), which is clearly too large. 64 bits yields > .0000000000027102343806669673910162993043, which is also way > below any > other likely error contribution. > > I think I've gone through the other plausible alternatives > for defining > identifiers in an earlier message, and they all have fatal flaws in > practical networks. (Plausible does not include a central > mechanism for > doling out numbers....) There is one other reasonable approach that > combines a random, locally-unique identifier with a host IP address. > This works as long as the host is not on an > RFC-1918-addressed device. > If we assume that the number of such devices is much smaller than the > number of nodes overall, one could pick a combination of a > short random > identifier with the IP address. This seems dicier to me since > there may > well be two very large 1918-style networks that have a lot of flows > between them. > > Henning > > > Melinda Shore wrote: > > >>Practical solutions to the global ID scheme? A 32 bit > >>number, globally unique. Should there be a fixed "per > >>operator" code (AS number, country code, IP > >>address/prefix, other) and a variable one? Only a variable > >>one? How's the latter organised (I've got no expertise and > >>the sole statement that 32 bit coding space is sufficient > >>to avoid collisions doesn't help to much, even if I > >>believe it). Or did I miss something and the 32 bit number > >>is valid only in combination with an address or the like? > > > > > > A 32-bit number on its own is unfortunately insufficient to > > provide reasonable protection against collisions on its own. > > I think there are things we can do with high-resolution > > timestamps or cryptographically, but we're going to need > > more bits (potentially a lot more bits). This is not an > > uncommon problem and I expect there's been some useful work > > done already; a literature search is probably a good next > > step. > > > > I should add that I am not comfortable with a scheme that > > relies on a central registry. > > > > Melinda > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 3 08:01:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07806 for ; Thu, 3 Jul 2003 08:01:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y2ls-0000sy-90 for nsis-archive@odin.ietf.org; Thu, 03 Jul 2003 08:01:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63C1459003366 for nsis-archive@odin.ietf.org; Thu, 3 Jul 2003 08:01:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y2lq-0000sB-Ex; Thu, 03 Jul 2003 08:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y2le-0000rf-Gf for nsis@optimus.ietf.org; Thu, 03 Jul 2003 08:00:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07784 for ; Thu, 3 Jul 2003 08:00:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y2ld-0005bq-00 for nsis@ietf.org; Thu, 03 Jul 2003 08:00:49 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19Y2lc-0005bn-00 for nsis@ietf.org; Thu, 03 Jul 2003 08:00:48 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2003 04:57:03 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h63C0CpZ019060; Thu, 3 Jul 2003 05:00:12 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJD07410; Thu, 3 Jul 2003 05:00:10 -0700 (PDT) Message-Id: <200307031200.AJD07410@mira-sjc5-c.cisco.com> To: "Hancock, Robert" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Re: [NSIS]: identifiers with global scope In-Reply-To: Message from robert.hancock@roke.co.uk of "Thu, 03 Jul 2003 11:14:32 BST." Date: Thu, 03 Jul 2003 08:00:10 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , MESSAGE_ID is, indeed, hop-by-hop in 2961. It's used to support summary refreshes. I don't see an obvious reason why we would need an identifier with global scope, which isn't to say that there's not one lurking out there somewhere (mobility people might have some thoughts on that). In any event it certainly shouldn't be visible outside the NTLP. As far as NAT, the issue with source identification isn't NAT traversal but uniqueness. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 3 16:46:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05447 for ; Thu, 3 Jul 2003 16:46:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YAy1-00011q-7s for nsis-archive@odin.ietf.org; Thu, 03 Jul 2003 16:46:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Kk9bu003937 for nsis-archive@odin.ietf.org; Thu, 3 Jul 2003 16:46:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YAxs-00010z-JG; Thu, 03 Jul 2003 16:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YAxg-00010W-Nj for nsis@optimus.ietf.org; Thu, 03 Jul 2003 16:45:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05425 for ; Thu, 3 Jul 2003 16:45:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YAvu-00025l-00 for nsis@ietf.org; Thu, 03 Jul 2003 16:43:58 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19YAvt-00025i-00 for nsis@ietf.org; Thu, 03 Jul 2003 16:43:57 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h63KhlHX021198 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Jul 2003 16:43:50 -0400 (EDT) Message-ID: <3F049574.1000807@cs.columbia.edu> Date: Thu, 03 Jul 2003 16:43:32 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: Melinda Shore , "Geib, Ruediger" , hgs+nsis@cs.columbia.edu, nsis@ietf.org Subject: Re: [NSIS] Re: [NSIS]: identifiers with global scope References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hancock, Robert wrote: > However, the session identifier format and generation mechanism shouldn't > have much impact on the NTLP design. We should agree on a general approach. I don't think having half a dozen options in one protocol to choose from adds much value for this element. (I'm all for toolbox approaches elsewhere.) > > The origin of this particular discussion is a different identifier, > the MESSAGE_ID in the shore draft. I have to confess to being unclear > about the role it is supposed to play, but on the assumption that > the NTLP role is just to deliver messages between adjacent NSIS nodes, > I'd be rather shocked to find > a) global scope was needed, or > b) it was visible outside the NTLP. > The message ID needs to be qualified with some message source identification, > but hopefully this shouldn't be as hard as wanting (a). The main problem would > be NAT traversal (as usual). A message identifier would be used (in both drafts) for correlating messages in both directions, for example. However, this is much more similar to a sequence number, since this is strictly between two nodes. I'm unclear why this needs a global uniqueness scope of any sort, whether generated randomly or otherwise. This is similar to a transport-protocol sequence number, e.g., in TCP or SCTP. Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 3 17:03:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06381 for ; Thu, 3 Jul 2003 17:03:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBEM-0001pq-H9 for nsis-archive@odin.ietf.org; Thu, 03 Jul 2003 17:03:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63L32MD007052 for nsis-archive@odin.ietf.org; Thu, 3 Jul 2003 17:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBEM-0001pe-13; Thu, 03 Jul 2003 17:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBE2-0001oL-GI for nsis@optimus.ietf.org; Thu, 03 Jul 2003 17:02:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06342 for ; Thu, 3 Jul 2003 17:02:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YBE0-0002aK-00 for nsis@ietf.org; Thu, 03 Jul 2003 17:02:40 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19YBDz-0002aH-00 for nsis@ietf.org; Thu, 03 Jul 2003 17:02:39 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h63L2ZIQ015441 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Jul 2003 17:02:38 -0400 (EDT) Message-ID: <3F0499DC.9090004@cs.columbia.edu> Date: Thu, 03 Jul 2003 17:02:20 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: AW: [NSIS] framework: proposal on congestion/flow control References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hancock, Robert wrote: > It's clear that something can be done. The key point i was trying to make > was that the concept of a 'congestion controlled association' which you > can use because 'you know where you are going' is hard to match with > the use of PATH-like methods for refresh/route change probing. Some people > think that's a big deal, some don't, but that's the point which needs to > be confronted and resolved (IMHO). Fundamentally, if one has no clue where the next hop is, there is no way to maintain congestion state, since congestion state is generally tied to some sort of association. The only other solution is to have a "global" congestion state, i.e., a state that limits the number of unacknowledged messages to any destination. If each node is only allowed to have one "unknown destination" packet in the ether at any one time, congestion is going to be bounded. This is clearly extremely conservative and would limit the concurrent number of sessions to a very small number, but I think it is provable that given the "know nothing" constraint, that's the best you can do for those messages. In this context, I'd like to add some evidence to my contention that for most popular destinations, routing changes are rare, on the order of several days between events. See the paper BGP Routing Stability of Popular Destinations Jennifer Rexford, Jia Wang, Zhen Xiao, Yin Zhang ACM SIGCOMM IMW (Internet Measurement Workshop) 2002 http://citeseer.nj.nec.com/rexford02bgp.html for the details. Thus, there may be better ways to deal with these than probing every 30 seconds. I can think of a number of heuristics. I suspect that a 30-second probing interval is both too long and too short. It's too long if your signaling state is critical to the session and too short for efficiency and scaling. For example, for QoS, it might be better to use indications of trouble (packet loss) or change (changed TTL, for example) to resend the signaling message. If there's a routing change with a transient or flapping, it is not clear that any signaling protocol can keep up during that period of instability or that this is useful. By the time you've gotten AAA permission from the new routers, the route has oscillated again... > > Broadly, I agree with you, and I'd be happier with a protocol > that allowed this sort of 'express routing'. How it is done of course > depends on what the rest of the protocol looks like (e.g. does it even > have an identifiable discovery mechanism to be tuned in the first place). From what I can tell, it is not too difficult to provide this as an option. It does not appear to add any appreciable complexity to NTLP. > > There are two additional points I would emphasise: > a) Sometimes you really want messages to be routed through intermediate > NSIS-aware (but NSLP-unaware) nodes, but processed statelessly (e.g. > flow-id re-writing in a NAT, or imposing a policy forwarding rule). > So, it's hard to have the intermediate nodes completely drop out of > the picture. We clearly want to allow nodes that are 'generally aware', i.e., process all messages, but are a no-op at the NSLP level. I used the term omnivorous for those at some point :-) > b) For scaling/aggregation reasons, you may want to be able to have some > messages bypass a lot of NSIS processing in interior nodes. 3175 grabs a new > protocol number and suggests modifications to the router alert option to > achieve this. We haven't really looked at this up to now. There are probably three levels of ignorance: (1) bypass at router alert level (2) see NTLP message, but forward without inspection or modification (transparently) (3) do NSLP-unaware processing (allow modification of NTLP) > > cheers, > > robert h. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 3 23:26:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01767 for ; Thu, 3 Jul 2003 23:26:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YHD1-0003XD-3A for nsis-archive@odin.ietf.org; Thu, 03 Jul 2003 23:26:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h643Q32v013579 for nsis-archive@odin.ietf.org; Thu, 3 Jul 2003 23:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YHCz-0003Wu-FR; Thu, 03 Jul 2003 23:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6MF-0004Hy-Vx for nsis@optimus.ietf.org; Thu, 03 Jul 2003 11:50:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19159 for ; Thu, 3 Jul 2003 11:50:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6ME-00011z-00 for nsis@ietf.org; Thu, 03 Jul 2003 11:50:50 -0400 Received: from david.tmit.bme.hu ([152.66.246.102]) by ietf-mx with esmtp (Exim 4.12) id 19Y6M9-00010y-00 for nsis@ietf.org; Thu, 03 Jul 2003 11:50:47 -0400 Received: from ttt-atm.tmit.bme.hu (ttt-atm.tmit.bme.hu [152.66.246.81]) by david.tmit.bme.hu (8.12.9/8.12.9) with ESMTP id h63FoKej010211; Thu, 3 Jul 2003 17:50:20 +0200 (MET DST) Received: from TTT-ATM/SpoolDir by ttt-atm.tmit.bme.hu (Mercury 1.48); 3 Jul 03 17:50:48 +0100 Received: from SpoolDir by TTT-ATM (Mercury 1.48); 3 Jul 03 17:50:14 +0100 Received: from dzsessz.tmit.bme.hu (152.66.244.14) by ttt-atm.tmit.bme.hu (Mercury 1.48) with ESMTP; 3 Jul 03 17:48:36 +0100 Message-Id: <5.2.1.1.0.20030703173656.02ae64d8@goliat.eik.bme.hu> X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 03 Jul 2003 17:48:11 +0200 To: nsis@ietf.org From: Feher Gabor Cc: ifreytsis@cetacean.com, robert.hancock@roke.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [NSIS] A benchmarking draft, but signaling terminology Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, In the Benchmarking Working Group (BMWG) we have produced a draft about benchmarking routers supporting resource reservation. Some weeks ago we have updated the terminology draft that targets distinguished traffic, QoS sessions, resource reservation capable routers, protocols, etc.. We have tried to make the draft as much 'NSIS conform' as possible. Luckily, our thoughts about resource reservation are really close to yours, so it was not a break. Please take a look at on the draft: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-benchres-term-03.txt We would appreciate any question or comment! regards, Gabor _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 4 00:18:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02892 for ; Fri, 4 Jul 2003 00:18:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YI1K-0007Hg-1O for nsis-archive@odin.ietf.org; Fri, 04 Jul 2003 00:18:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h644I2lP027983 for nsis-archive@odin.ietf.org; Fri, 4 Jul 2003 00:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YI1J-0007HE-8O; Fri, 04 Jul 2003 00:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YI15-0007H1-9E for nsis@optimus.ietf.org; Fri, 04 Jul 2003 00:17:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02883 for ; Fri, 4 Jul 2003 00:17:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YI12-0001av-00 for nsis@ietf.org; Fri, 04 Jul 2003 00:17:44 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 19YI11-0001aW-00 for nsis@ietf.org; Fri, 04 Jul 2003 00:17:44 -0400 Received: from sait1gc9bc522b (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h644GqOT003738; Fri, 4 Jul 2003 13:16:52 +0900 (KST) From: "Sung Hycuk Lee" To: Cc: "Seong-Ho Jeong" , , Date: Fri, 4 Jul 2003 13:16:54 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Subject: [NSIS] QoS Signaling for IP-based Radio Access Networks Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 DQpIaSBhbGwsDQoNClRoZSBmb2xsb3dpbmcgZHJhZnQgcHJlc2VudHMgUW9TIHNpZ25hbGluZyBw cm9jZWR1cmVzIGZvciANCklQLWJhc2VkIHJhZGlvIGFjY2VzcyBuZXR3b3Jrcy4gVGhlIE5TSVMg d29ya2luZyBncm91cCBpcyBjdXJyZW50bHkgDQpzdGFuZGFyZGl6aW5nIGEgZ2VuZXJpYyBzaWdu YWxpbmcgcHJvdG9jb2wgd2l0aCBRb1Mgc2lnbmFsaW5nIGFzIHRoZSBmaXJzdCANCnVzZSBjYXNl LiBJdCBpcyBkZXNpcmFibGUgdG8gY29uc2lkZXIgUW9TIHNpZ25hbGluZyBmb3IgcmVzb3VyY2Ug cmVzZXJ2YXRpb25zIA0KaW4gcmFkaW8gYWNjZXNzIG5ldHdvcmtzIHdoZXJlIG1vYmlsZSBub2Rl cyB1bmRlcmdvIGZyZXF1ZW50IGhhbmRvZmZzLg0KVGhpcyBkcmFmdCBhaW1zIHRvIHByb3ZpZGUg ZmFzdCBRb1MgcmUtZXN0YWJsaXNobWVudCBhbmQgZmFzdCByZWxlYXNlIG9mIA0Kb2xkIHN0YXRl IGFmdGVyIGhhbmRvZmYuIFRoZSBkcmFmdCBhbHNvIHByZXNlbnRzIGEgc3BlY2lmaWMgUW9TIHNp Z25hbGluZyBzY2hlbWUgDQpiYXNlZCBvbiB0aGUgcHJvcG9zZWQgc2lnbmFsaW5nIHByb2NlZHVy ZXMuIFRoZSBmdXR1cmUgdmVyc2lvbnMgb2YgdGhlIGRyYWZ0IA0Kd2lsbCBpbmNsdWRlIG1vcmUg Z2VuZXJhbCBkZXNjcmlwdGlvbnMgb2YgdGhlIHNpZ25hbGluZyBwcm9jZWR1cmVzIGJhc2VkIG9u IA0KdGhlIGZ1bmN0aW9uYWxpdGllcyBvZiBOVExQL05TTFAuDQoNClRpdGxlIDogUW9TIFNpZ25h bGluZyBmb3IgSVAtYmFzZWQgUmFkaW8gQWNjZXNzIE5ldHdvcmtzDQpVUkw6IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxlZS1uc2lzLXNpZ25hbGluZy1yYW4tMDAu dHh0DQoNCldlIHdlbGNvbWUgYW55IGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zLg0KDQpSZWdhcmRz LA0KDQpTZW9uZ2hvIEplb25nL1N1bmcgSHl1Y2sgTGVlIA== _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 4 07:20:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23623 for ; Fri, 4 Jul 2003 07:20:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YObj-00039j-71 for nsis-archive@odin.ietf.org; Fri, 04 Jul 2003 07:20:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64BK3AD012129 for nsis-archive@odin.ietf.org; Fri, 4 Jul 2003 07:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YObi-00039O-LP; Fri, 04 Jul 2003 07:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YOb1-00038C-E2 for nsis@optimus.ietf.org; Fri, 04 Jul 2003 07:19:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23529 for ; Fri, 4 Jul 2003 07:19:18 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YOb0-0004Ku-00 for nsis@ietf.org; Fri, 04 Jul 2003 07:19:19 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19YOb0-0004Kr-00 for nsis@ietf.org; Fri, 04 Jul 2003 07:19:18 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h64BJHa12466 for ; Fri, 4 Jul 2003 14:19:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 4 Jul 2003 14:19:16 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Jul 2003 14:19:16 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Jul 2003 14:19:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Jul 2003 14:19:15 +0300 Message-ID: Thread-Topic: [NSIS] QoS Signaling for IP-based Radio Access Networks Thread-Index: AcNB40zHKjMe+FwKTkao38YKI53VfwAOljQw To: X-OriginalArrivalTime: 04 Jul 2003 11:19:16.0589 (UTC) FILETIME=[1AFF31D0:01C3421E] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] NSIS agenda at IETF 57 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Here is my first shot at trying to organize the agenda for IETF 57. As = you can tell, we have a very full agenda. If I have left anything out or if anyone has general comments on the = agenda, please let me know. Next Steps in Signaling Agenda MONDAY, July 14, 2003 1530-1730 Afternoon Session I =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Agenda bashing & WG Update 15 min Milestones Charter Update=20 Requirements Doc update "NSIS Transport Protocol" - 45 min - Melinda Shore & Henning Schulzrinne http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-ntlp-00.txt http://www.ietf.org/internet-drafts/draft-shore-ntlp-00.txt Security, Threats & Authorization issues - 30 minutes - Hannes = Tschofenig =20 "RSVP Security Properties" & "NSIS Threats"=20 http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-02.txt = http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-0= 2.txt = http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issue= s-00.txt http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-sid-00.txt "Next Steps in Signaling: Framework" - 15 minutes - Robert Handcock http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-03.txt http://www.ietf.org/internet-drafts/draft-hancock-nsis-overload-00.txt "Analysis of Existing Signaling Protocols" - 15 minutes - Jukka Manner = http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-0= 2.txt TUESDAY, July 15, 2003 1300-1400 Afternoon Session I =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D "NSIS QoS Application Protocol" - 20 minutes - TBA http://www.ietf.org/internet-drafts/draft-buchli-nsis-nslp-00.txt http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-qos-nslp-00.txt = http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-ns= lp-00.txt "NSIS Middle Box Signaling Application Protocol" - 20 minutes - Marcus = Brunner http://www.ietf.org/internet-drafts/draft-brunner-nsis-midcom-ps-00.txt Wrapup & Next Steps - 10 minutes - chair Other relevant documents ------------------------ Requirements for IPv6 Signaling as NTLP http://www.ietf.org/internet-drafts/draft-choi-ipv6-signaling-req-ntlp-00= .txt Mobility Support in NSIS http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.txt QoS Signaling for IP-based Radio Access Networks http://www.ietf.org/internet-drafts/draft-lee-nsis-signaling-ran-00.txt RSVP Domain of Interpretation for ISAKMP http://www.tschofenig.priv.at/drafts/draft-tschofenig-rsvp-doi-00.txt Signaling for QoS Measurement http://www.ietf.org/internet-drafts/draft-couturier-nsis-measure-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 4 11:18:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29113 for ; Fri, 4 Jul 2003 11:18:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSK2-0003NY-2Y for nsis-archive@odin.ietf.org; Fri, 04 Jul 2003 11:18:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64FI2AE012984 for nsis-archive@odin.ietf.org; Fri, 4 Jul 2003 11:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSK0-0003Mp-Nm; Fri, 04 Jul 2003 11:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSJY-0003MT-R9 for nsis@optimus.ietf.org; Fri, 04 Jul 2003 11:17:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29086 for ; Fri, 4 Jul 2003 11:17:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YSJX-0006dD-00 for nsis@ietf.org; Fri, 04 Jul 2003 11:17:31 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19YSJX-0006d9-00 for nsis@ietf.org; Fri, 04 Jul 2003 11:17:31 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h64FHQCf005796; Fri, 4 Jul 2003 17:17:27 +0200 (MET DST) Message-ID: <00a501c3423f$6235c610$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , References: Subject: Additional draft for [NSIS] NSIS agenda at IETF 57 Date: Fri, 4 Jul 2003 17:17:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John Could you please introduce the following draft into the list "NSIS Transport Protocol" ? http://www.ietf.org/internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-01.txt Best Regards, Georgios ----- Original Message ----- From: To: Sent: Friday, July 04, 2003 1:19 PM Subject: [NSIS] NSIS agenda at IETF 57 > Hi all, > > Here is my first shot at trying to organize the agenda for IETF 57. As you can tell, > we have a very full agenda. > > If I have left anything out or if anyone has general comments on the agenda, please let > me know. > > Next Steps in Signaling Agenda > > MONDAY, July 14, 2003 > 1530-1730 Afternoon Session I > ============================= > > Agenda bashing & WG Update 15 min > Milestones > Charter Update > Requirements Doc update > > "NSIS Transport Protocol" - 45 min - Melinda Shore & Henning Schulzrinne > http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-ntlp-00.txt > http://www.ietf.org/internet-drafts/draft-shore-ntlp-00.txt > > > Security, Threats & Authorization issues - 30 minutes - Hannes Tschofenig > "RSVP Security Properties" & "NSIS Threats" > http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-02.t xt > http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issues-0 0.txt > http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-sid-00.txt > > > "Next Steps in Signaling: Framework" - 15 minutes - Robert Handcock > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-03.txt > http://www.ietf.org/internet-drafts/draft-hancock-nsis-overload-00.txt > > "Analysis of Existing Signaling Protocols" - 15 minutes - Jukka Manner > http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-02.t xt > > > TUESDAY, July 15, 2003 > 1300-1400 Afternoon Session I > ============================= > > "NSIS QoS Application Protocol" - 20 minutes - TBA > http://www.ietf.org/internet-drafts/draft-buchli-nsis-nslp-00.txt > http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-qos-nslp-00.txt > http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-nslp- 00.txt > > > "NSIS Middle Box Signaling Application Protocol" - 20 minutes - Marcus Brunner > http://www.ietf.org/internet-drafts/draft-brunner-nsis-midcom-ps-00.txt > > Wrapup & Next Steps - 10 minutes - chair > > > Other relevant documents > ------------------------ > Requirements for IPv6 Signaling as NTLP > http://www.ietf.org/internet-drafts/draft-choi-ipv6-signaling-req-ntlp-00.tx t > > Mobility Support in NSIS > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.txt > > QoS Signaling for IP-based Radio Access Networks > http://www.ietf.org/internet-drafts/draft-lee-nsis-signaling-ran-00.txt > > RSVP Domain of Interpretation for ISAKMP > http://www.tschofenig.priv.at/drafts/draft-tschofenig-rsvp-doi-00.txt > > Signaling for QoS Measurement > http://www.ietf.org/internet-drafts/draft-couturier-nsis-measure-00.txt > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jul 6 20:10:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26345 for ; Sun, 6 Jul 2003 20:10:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZJa3-0006yB-DU for nsis-archive@odin.ietf.org; Sun, 06 Jul 2003 20:10:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h670A7Qa026785 for nsis-archive@odin.ietf.org; Sun, 6 Jul 2003 20:10:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZJZx-0006wz-LR; Sun, 06 Jul 2003 20:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZJZE-0006wV-S4 for nsis@optimus.ietf.org; Sun, 06 Jul 2003 20:09:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26329 for ; Sun, 6 Jul 2003 20:09:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZJZC-0005fo-00 for nsis@ietf.org; Sun, 06 Jul 2003 20:09:14 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19ZJZC-0005fk-00 for nsis@ietf.org; Sun, 06 Jul 2003 20:09:14 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6709EIQ003498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 6 Jul 2003 20:09:14 -0400 (EDT) From: "Charles Q. Shen" To: Subject: RE: [NSIS] Proposed draft "Mobility Support in NSIS" Date: Sun, 6 Jul 2003 20:09:11 -0400 Organization: Columbia University Message-ID: <000201c3441b$fe941830$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: <3F05804D.2040504@cs.uni-goettingen.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I think having such a draft discussing mobility issues with NSIS is helpful and inline with the WG charter. I started a similar effort in an earlier draft last July http://www.ee.columbia.edu/~charles/publication/draft-shen-nsis-mobility -fw-00.txt. Fu's draft incorporated some recent issues including NSLP/NTLP interaction, Discovery, peer-to-peer addressing etc. It would be good to elaborate those parts when they become clearer in the WG discussion. Disscussion of tunneling/non-optimized routing is also useful, but it would be beneficial to refer to RFC2746 which provides a very good example of solving tunneling issues in the case of RSVP. Some issues may also be grouped together. Basically there are cases of sender mobility and receiver mobility (The protocol itself could be either sender initiated or receiver initated). Handoff causes appropriate signaling actions in three segments of the network: the intact path, the new path and the obsoleted path. (This applies to both optimized/non-optimized routing, and possibly involves tunneling.) The handoff process would further impact subsequent regular soft-state refresh which has to be considered. Best regards, Charles --- Charles Q. Shen Department of Electrical Engineering Columbia University Email: charles@ee.columbia.edu Phone: +1 212 853 8475 http://www.ee.columbia.edu/~charles -------- Original Message -------- Subject: [NSIS] Proposed draft "Mobility Support in NSIS" Date: Sat, 28 Jun 2003 23:43:09 +0200 From: Xiaoming Fu To: nsis@ietf.org Hi all, Here is a new Internet Draft that we propose as a problem statement and proposed mechanisms to extend NSIS for mobility support: http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.txt or http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.pdf Following previous work (Michael Thomas, Cedric Westphal/Hemant Chaskar, Charles Shen, and many others), this Draft aims to provide an extensive view on mobility support related issues that will be of broad general use. We welcome your comments. We are also especially interested in other open issues and studying how they may be addressed by future versions of the Draft. Regards, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 7 03:57:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16690 for ; Mon, 7 Jul 2003 03:57:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQru-0004OY-Sl for nsis-archive@odin.ietf.org; Mon, 07 Jul 2003 03:57:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h677v2nK016893 for nsis-archive@odin.ietf.org; Mon, 7 Jul 2003 03:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQru-0004OM-55; Mon, 07 Jul 2003 03:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQqy-0004Ll-A6 for nsis@optimus.ietf.org; Mon, 07 Jul 2003 03:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16686 for ; Mon, 7 Jul 2003 03:56:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZQqv-0001hT-00 for nsis@ietf.org; Mon, 07 Jul 2003 03:56:01 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19ZQqu-0001hQ-00 for nsis@ietf.org; Mon, 07 Jul 2003 03:56:01 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h677twv13715; Mon, 7 Jul 2003 09:55:59 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h677tvc19790; Mon, 7 Jul 2003 09:55:57 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <3D8BJYGM>; Mon, 7 Jul 2003 09:55:56 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFF88@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Charles Q. Shen'" , nsis@ietf.org Subject: RE: [NSIS] Proposed draft "Mobility Support in NSIS" Date: Mon, 7 Jul 2003 09:55:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi charles, thanks for pointing to your draft. i haven't actually noticed that you submitted a draft. i will take a look at it as soon as possible. ciao hannes > -----Original Message----- > From: Charles Q. Shen [mailto:charles@ee.columbia.edu] > Sent: Monday, July 07, 2003 2:09 AM > To: nsis@ietf.org > Subject: RE: [NSIS] Proposed draft "Mobility Support in NSIS" > > > Hi, > > I think having such a draft discussing mobility issues with NSIS is > helpful and inline with the WG charter. I started a similar > effort in an > earlier draft last July > http://www.ee.columbia.edu/~charles/publication/draft-shen-nsi > s-mobility > -fw-00.txt. > > Fu's draft incorporated some recent issues including NSLP/NTLP > interaction, Discovery, peer-to-peer addressing etc. It would > be good to > elaborate those parts when they become clearer in the WG discussion. > > Disscussion of tunneling/non-optimized routing is also useful, but it > would be beneficial to refer to RFC2746 which provides a very good > example of solving tunneling issues in the case of RSVP. > > Some issues may also be grouped together. Basically there are cases of > sender mobility and receiver mobility (The protocol itself could be > either sender initiated or receiver initated). Handoff causes > appropriate signaling actions in three segments of the network: the > intact path, the new path and the obsoleted path. (This > applies to both > optimized/non-optimized routing, and possibly involves tunneling.) The > handoff process would further impact subsequent regular soft-state > refresh which has to be considered. > > Best regards, > > Charles > > --- > Charles Q. Shen > Department of Electrical Engineering > Columbia University > Email: charles@ee.columbia.edu > Phone: +1 212 853 8475 > http://www.ee.columbia.edu/~charles > > > -------- Original Message -------- > Subject: [NSIS] Proposed draft "Mobility Support in NSIS" > Date: Sat, 28 Jun 2003 23:43:09 +0200 > From: Xiaoming Fu > To: nsis@ietf.org > > Hi all, > > Here is a new Internet Draft that we propose as a problem > statement and > proposed mechanisms to extend NSIS for mobility support: > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.txt or > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.pdf > > Following previous work (Michael Thomas, Cedric > Westphal/Hemant Chaskar, > Charles Shen, and many others), this Draft aims to provide an > extensive > view on mobility support related issues that will be of broad general > use. > > We welcome your comments. We are also especially interested in other > open issues and studying how they may be addressed by future > versions of > the Draft. > > Regards, > Xiaoming > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 7 04:22:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17075 for ; Mon, 7 Jul 2003 04:22:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRG6-0005OX-46 for nsis-archive@odin.ietf.org; Mon, 07 Jul 2003 04:22:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h678M2Bs020737 for nsis-archive@odin.ietf.org; Mon, 7 Jul 2003 04:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRG5-0005OM-GI; Mon, 07 Jul 2003 04:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRFz-0005O3-Of for nsis@optimus.ietf.org; Mon, 07 Jul 2003 04:21:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17062 for ; Mon, 7 Jul 2003 04:21:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZRFw-0001vq-00 for nsis@ietf.org; Mon, 07 Jul 2003 04:21:52 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19ZRFv-0001vl-00 for nsis@ietf.org; Mon, 07 Jul 2003 04:21:51 -0400 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 07 Jul 2003 10:21:57 +0200 Message-ID: <3F092DAD.8060304@cs.uni-goettingen.de> Date: Mon, 07 Jul 2003 10:22:05 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles Q. Shen" , nsis@ietf.org Subject: Re: [NSIS] Proposed draft "Mobility Support in NSIS" References: <000201c3441b$fe941830$c7f027a0@president> In-Reply-To: <000201c3441b$fe941830$c7f027a0@president> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Thanks for your insightful comments. My comments inline: Charles Q. Shen wrote: > Hi, > > I think having such a draft discussing mobility issues with NSIS is > helpful and inline with the WG charter. I started a similar effort in an > earlier draft last July > http://www.ee.columbia.edu/~charles/publication/draft-shen-nsis-mobility-fw-00.txt. I read this draft and found it helpful. For example, your draft identified the necessity to soft-state refresh even for the _intact path_ (I find this term looks more appealing than _common path_ :)) before and after a handoff happens. This has also been summarized in issue 3 and section 4.1 in our draft. > > Fu's draft incorporated some recent issues including NSLP/NTLP > interaction, Discovery, peer-to-peer addressing etc. It would be good to > elaborate those parts when they become clearer in the WG discussion. Yes, to my understanding a concrete conclusion has not been drawn so far on whether end-to-end or peer-peer addressing will be used in NTLP. That's why the draft discusses both peer-peer and e2e addressing issues there, in align with framework draft. It is also my belief that with the further development of framework/protocol work, discovery and NSLP/NTLP issues would be clearer and we'll be able to look into these issues in depth. > > Disscussion of tunneling/non-optimized routing is also useful, but it > would be beneficial to refer to RFC2746 which provides a very good > example of solving tunneling issues in the case of RSVP. You're right! This is related to the addressing mode of NTLP messages. I think RFC2746 scheme would probably be most useful for at least e2e addressing approaches such as RSVP. For peer-peer addressing, it looks to me discovery component would help to identify next peer and IP-in-IP tunneled signaling message can be avoided, as long as the MIP tunnel endpoints support NTLP. > > Some issues may also be grouped together. Basically there are cases of > sender mobility and receiver mobility (The protocol itself could be > either sender initiated or receiver initated). Handoff causes > appropriate signaling actions in three segments of the network: the > intact path, the new path and the obsoleted path. (This applies to both > optimized/non-optimized routing, and possibly involves tunneling.) Thanks for your suggestions, such restructuring looks fine to me. > The handoff process would further impact subsequent regular soft-state > refresh which has to be considered. Regarding the two types of soft-state timers: the mobility management timer (let's assume "only" one mobility management, or minimal value of timers of all mobility management schemes) and the NSIS timer (let's assume NTLP would do some basic state management), there are a few open issues (have not explored in our draft yet): - Shall we use a smaller value for NSIS timer than mobility management timer? my conjecture would be "yes", to ensure NSIS signaling actually reflect mobility signaling. - How can we know this comparision at all? This could be through an API, or, say, a mobility routing interface issue. If this knowledge is unaware to NSIS at all, a simplest way presumably can be NSIS signlaing directly after each moibility management. Cheers, Xiaoming > Best regards, > > Charles > > --- > Charles Q. Shen > Department of Electrical Engineering > Columbia University > Email: charles@ee.columbia.edu > Phone: +1 212 853 8475 > http://www.ee.columbia.edu/~charles > > > -------- Original Message -------- > Subject: [NSIS] Proposed draft "Mobility Support in NSIS" > Date: Sat, 28 Jun 2003 23:43:09 +0200 > From: Xiaoming Fu > To: nsis@ietf.org > > Hi all, > > Here is a new Internet Draft that we propose as a problem statement and > proposed mechanisms to extend NSIS for mobility support: > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.txt or > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.pdf > > Following previous work (Michael Thomas, Cedric Westphal/Hemant Chaskar, > Charles Shen, and many others), this Draft aims to provide an extensive > view on mobility support related issues that will be of broad general > use. > > We welcome your comments. We are also especially interested in other > open issues and studying how they may be addressed by future versions of > the Draft. > > Regards, > Xiaoming > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 7 07:56:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21977 for ; Mon, 7 Jul 2003 07:56:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUbD-0005OM-6G for nsis-archive@odin.ietf.org; Mon, 07 Jul 2003 07:56:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Bu3cu020727 for nsis-archive@odin.ietf.org; Mon, 7 Jul 2003 07:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUbC-0005O7-HG; Mon, 07 Jul 2003 07:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUb2-0005NM-L9 for nsis@optimus.ietf.org; Mon, 07 Jul 2003 07:55:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21958 for ; Mon, 7 Jul 2003 07:55:50 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZUb1-0003Yh-00 for nsis@ietf.org; Mon, 07 Jul 2003 07:55:51 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ZUb0-0003Yc-00 for nsis@ietf.org; Mon, 07 Jul 2003 07:55:50 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h67Btma21501 for ; Mon, 7 Jul 2003 14:55:48 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 7 Jul 2003 14:55:48 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 7 Jul 2003 14:55:48 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 7 Jul 2003 14:55:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jul 2003 14:55:48 +0300 Message-ID: Thread-Topic: [NSIS] QoS Signaling for IP-based Radio Access Networks Thread-Index: AcNB40zHKjMe+FwKTkao38YKI53VfwAOljQwAJe/F8A= To: X-OriginalArrivalTime: 07 Jul 2003 11:55:48.0251 (UTC) FILETIME=[B49186B0:01C3447E] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Review of "Analysis of Existing Signaling Protocols" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, In preparing for IETF 57, I am trying to make a quick review of many of = the documents under discussion. http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-0= 2.txt Overall, I think that this document is looking quite good. I am happy = with the overall tone & structure of the document. I think there are still = some places for improvement, I hope that we can have some discussion of this = document and then a revision before we start the WG last call on it. Minor nits: End of Section 3.1: Text: In summary, in trying to introduce reliability in RSVP, we are getting closer to reinvent TCP. Furthermore, if head of line blocking is likely to occur, SCTP can be used. Certainly, if TCP, SCTP or similar protocols is the transport protocol for RSVP, the message reliability would not have been an issue. should be: a similar protocol is the transport protocol for RSVP, the message ^ ^ reliability would not have been an issue. Section 3.2: Text: According to RSVP [RFC2205], each RSVP message can only contain information for one session. In a network that has a reasonably large number of RSVP sessions, this constraint imposes a heavy processing burden on the routers. Many router OS is based on UNIX. [IP-OPT] should be: According to RSVP [RFC2205], each RSVP message can only contain information for one session. In a network that has a reasonably large number of RSVP sessions, this constraint imposes a heavy processing burden on the routers. Many router OSes are based on UNIX. [IP-OPT] ^^ ^^^=20 More stubstantial comments. Section 3.5 I don't completely disagree with the text here, but I don't agree with = it completely either. I don't think the authors have proven that: If a new transport protocol is needed, the protocol must be able to handle the following: - reliable messaging; - message packing; - the MTU problem; - small triggered message volume. =20 I think that the authors should not make such bold statements unless = they provide more text to back-up their claims. I think it would be more reasonable = to say that if reliability, fragmentation, etc. are determined to be problems for = NSIS, then they should be solved using known techniques. Further, I would strike = the final paragraph completely, unless there was some documentation to back-up the = claims. Section 6.2.1 says: It was proven that YESSIR one-pass reservation model has better performance and lower processing cost, comparing with a regular two- way signaling protocol, such as RSVP. A reference to where this was proven would be needed. 7. Summary needs improvements. Also, this is where any conclusions = drawn in the document should be placed. 8. Security Considerations needs improvement. Perhaps Hannes could = provide a paragraph or two summarizing some of the conclusions from the RSVP = Security Properties & Threats documents. References need to be split - I could provide the authors some clues = off-list=20 on how to do this. Finally, I think the appendix is not needed, I suggest it be deleted. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 7 08:08:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22223 for ; Mon, 7 Jul 2003 08:08:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUmn-00060q-Qa for nsis-archive@odin.ietf.org; Mon, 07 Jul 2003 08:08:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67C81wZ023109 for nsis-archive@odin.ietf.org; Mon, 7 Jul 2003 08:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUmm-00060C-Tz; Mon, 07 Jul 2003 08:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUmL-0005sr-Ov for nsis@optimus.ietf.org; Mon, 07 Jul 2003 08:07:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22130 for ; Mon, 7 Jul 2003 08:07:31 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZUmK-0003bW-00 for nsis@ietf.org; Mon, 07 Jul 2003 08:07:32 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ZUmK-0003bT-00 for nsis@ietf.org; Mon, 07 Jul 2003 08:07:32 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h67C7Ua02488 for ; Mon, 7 Jul 2003 15:07:30 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 7 Jul 2003 15:07:30 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 7 Jul 2003 15:07:28 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 7 Jul 2003 15:07:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jul 2003 15:07:28 +0300 Message-ID: Thread-Topic: [NSIS] QoS Signaling for IP-based Radio Access Networks Thread-Index: AcNB40zHKjMe+FwKTkao38YKI53VfwAOljQwAJe/F8AAAI9hkA== To: X-OriginalArrivalTime: 07 Jul 2003 12:07:28.0366 (UTC) FILETIME=[55DE98E0:01C34480] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Review of "Security Threats for NSIS " Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, In preparing for IETF 57, I am trying to make a quick review of many of = the documents under discussion. http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-02.txt Overall, I think this document is quite good & quite ready for WG Last = Call. If noone opposes, I would like to start WG last call on this document starting Wednesday July 9th and run it for 3 weeks until July 23rd. I am restricting my comments to some more general comments right now. 1) Abstract needs improvement. Text is: =20 This threats document provides a detailed analysis of the = security=20 threats relevant for the NSIS working group. It motivates and = helps=20 to understand various security considerations in the NSIS=20 Requirements, Framework and Protocol proposals. This document = does=20 not describe vulnerabilities of specific NSIS protocols.=20 Suggested change (feel free to modify accordingly): =20 This document provides a detailed analysis of the relevant = security=20 threats for the NSIS working group. It provides motivatation = behind=20 the various security considerations in the NSIS Requirements and = Framework=20 documents. This document is not meant to describe potential = vulnerabilities=20 of specific NSIS protocols, but provide input into protocol design to ensure security considerations are well thought out prior to design 2) Section 1 There probably is not a need to diagram the different NSIS documents, a = bulleted list might be enough. 3) Terminology shouldn't be a seperate section, perhaps a sub-section. = Are you sure there is no security-specific terminology that should be added = here? IKE, S/MIME, IPsec, SA probably should be expanded. 4) General comment: blank lines between paragraphs are missing in many = places. 5) A summary might be a nice touch at the end. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 7 15:50:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11712 for ; Mon, 7 Jul 2003 15:50:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbzy-0008GM-LN for nsis-archive@odin.ietf.org; Mon, 07 Jul 2003 15:50:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Jo61A031756 for nsis-archive@odin.ietf.org; Mon, 7 Jul 2003 15:50:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbzs-0008FS-Tz; Mon, 07 Jul 2003 15:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbzm-0008F1-Ij for nsis@optimus.ietf.org; Mon, 07 Jul 2003 15:49:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11648 for ; Mon, 7 Jul 2003 15:49:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zbzl-0001k6-00 for nsis@ietf.org; Mon, 07 Jul 2003 15:49:53 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19Zbzk-0001k3-00 for nsis@ietf.org; Mon, 07 Jul 2003 15:49:52 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h67JnpUO024781 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 7 Jul 2003 15:49:52 -0400 (EDT) From: "Charles Q. Shen" To: "'Tschofenig Hannes'" , Subject: RE: [NSIS] Proposed draft "Mobility Support in NSIS" Date: Mon, 7 Jul 2003 15:49:48 -0400 Organization: Columbia University Message-ID: <000c01c344c0$ecad0f00$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFF88@mchp905a.mch.sbs.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Monday, July 07, 2003 3:56 AM > To: 'Charles Q. Shen'; nsis@ietf.org > Subject: RE: [NSIS] Proposed draft "Mobility Support in NSIS" > > hi charles, > > thanks for pointing to your draft. i haven't actually noticed > that you submitted a draft. i will take a look at it as soon > as possible. > > ciao > hannes > Thank you Hannes. That draft is also an attempt to generalize the topic from RSVP-Mobility to NSIS Mobility. The experience from a working RSVP-MIP test-bed should be helpful when looking into NSIS-mobility. (Drafts and these related to our RSVP-MIP work are available through my homepage.). It is now also important to reflect the most current WG progress in such a document. Best regards Charles --- Charles Q. Shen http://www.ee.columbia.edu/~charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 7 15:54:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11951 for ; Mon, 7 Jul 2003 15:54:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc3l-0000Bo-8z for nsis-archive@odin.ietf.org; Mon, 07 Jul 2003 15:54:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Js1eL000719 for nsis-archive@odin.ietf.org; Mon, 7 Jul 2003 15:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc3l-0000BV-52; Mon, 07 Jul 2003 15:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc3h-0000BK-2j for nsis@optimus.ietf.org; Mon, 07 Jul 2003 15:53:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11934 for ; Mon, 7 Jul 2003 15:53:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zc3f-0001p9-00 for nsis@ietf.org; Mon, 07 Jul 2003 15:53:55 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19Zc3e-0001p6-00 for nsis@ietf.org; Mon, 07 Jul 2003 15:53:54 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h67JrprZ016613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 7 Jul 2003 15:53:52 -0400 (EDT) From: "Charles Q. Shen" To: "'Xiaoming Fu'" , Subject: RE: [NSIS] Proposed draft "Mobility Support in NSIS" Date: Mon, 7 Jul 2003 15:53:48 -0400 Organization: Columbia University Message-ID: <000d01c344c1$7bc28b70$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <3F092DAD.8060304@cs.uni-goettingen.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Xiaoming, Thanks for your reply. Please find comments inline. > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of Xiaoming Fu > Sent: Monday, July 07, 2003 4:22 AM > To: Charles Q. Shen; nsis@ietf.org > Subject: Re: [NSIS] Proposed draft "Mobility Support in NSIS" > > > Hi, > > Thanks for your insightful comments. My comments inline: Thanks :-) > > Charles Q. Shen wrote: > > Hi, > > > > I think having such a draft discussing mobility issues with NSIS is > > helpful and inline with the WG charter. I started a similar > effort in an > > earlier draft last July > > > http://www.ee.columbia.edu/~charles/publication/draft-shen-nsis-mobility -fw-00.txt. > > I read this draft and found it helpful. For example, your draft > identified the necessity to soft-state refresh even for the _intact > path_ (I find this term looks more appealing than _common path_ :)) > before and after a handoff happens. This has also been summarized in > issue 3 and section 4.1 in our draft. > Yes, I think it is very appropriate to include this issue into the draft. When we did our RSVP-Mobile IP implementation we found it actually causes many complexities as detailed in our implementation draft. http://www.ee.columbia.edu/~charles/publication/draft-shen-nsis-rsvp-mob ileipv6-00.txt As to the terminotlogy, we can always think about better ones :) > > > > Fu's draft incorporated some recent issues including NSLP/NTLP > > interaction, Discovery, peer-to-peer addressing etc. It > would be good to > > elaborate those parts when they become clearer in the WG > discussion. > > Yes, to my understanding a concrete conclusion has not been > drawn so far > on whether end-to-end or peer-peer addressing will be used in NTLP. > That's why the draft discusses both peer-peer and e2e > addressing issues > there, in align with framework draft. It is also my belief > that with the > further development of framework/protocol work, discovery and > NSLP/NTLP > issues would be clearer and we'll be able to look into these > issues in > depth. > That would be very helpful because those aspects differentiate the protocol from original RSVP and require new efforts that are different from existing work on RSVP mobility. > > > > Disscussion of tunneling/non-optimized routing is also > useful, but it > > would be beneficial to refer to RFC2746 which provides a very good > > example of solving tunneling issues in the case of RSVP. > > You're right! This is related to the addressing mode of NTLP > messages. I > think RFC2746 scheme would probably be most useful for at least e2e > addressing approaches such as RSVP. For peer-peer addressing, > it looks > to me discovery component would help to identify next peer > and IP-in-IP > tunneled signaling message can be avoided, as long as the MIP tunnel > endpoints support NTLP. > Yes, you are right, the two addressing modes should be treated differently on this issue. 1) in e2e mode like RSVP, RFC 2746 describes three possibilities of the (logical) link. That seems to me is a more generic description. You are certainly correct in pointing out the requirement for the two tunnel end points to be NSIS aware to achieve a true e2e signaling. 2) in p2p mode, if the discovery is done properly with the help of NSIS aware tunnel endpoints, you are probably right that such tunneling could be avoided. (Do we have the path-coupled assumption here? ) > > > > Some issues may also be grouped together. Basically there > are cases of > > sender mobility and receiver mobility (The protocol itself could be > > either sender initiated or receiver initated). Handoff causes > > appropriate signaling actions in three segments of the network: the > > intact path, the new path and the obsoleted path. (This > applies to both > > optimized/non-optimized routing, and possibly involves tunneling.) > > Thanks for your suggestions, such restructuring looks fine to me. Thanks. > > > The handoff process would further impact subsequent regular > soft-s tate > > refresh which has to be considered. > Regarding the two types of soft-state timers: the mobility management > timer (let's assume "only" one mobility management, or > minimal value of > timers of all mobility management schemes) and the NSIS timer (let's > assume NTLP would do some basic state management), there are > a few open > issues (have not explored in our draft yet): > > - Shall we use a smaller value for NSIS timer than mobility > management > timer? my conjecture would be "yes", to ensure NSIS signaling > actually > reflect mobility signaling. > > - How can we know this comparision at all? This could be > through an API, > or, say, a mobility routing interface issue. If this knowledge is > unaware to NSIS at all, a simplest way presumably can be NSIS > signlaing > directly after each moibility management. I think there is always a trade-off here in terms of signaling overheads and promptness of response. Upon handoff, trying to achieve an "on-demand" adjustment (i.e., movement triggers both MIP and NSIS) is probably appropriate. During normal refresh, I agree that generally the NSIS timer should not be larger than the mobility timer. After all, why should the specific NSIS signaling (e.g. QoS) be still there if the mobility entry has expired? Of course there might be more details to look at. Cheers Charles > > Cheers, > Xiaoming > > > Best regards, > > > > Charles > > > > --- > > Charles Q. Shen > > Department of Electrical Engineering > > Columbia University > > Email: charles@ee.columbia.edu > > Phone: +1 212 853 8475 > > http://www.ee.columbia.edu/~charles > > > > > > -------- Original Message -------- > > Subject: [NSIS] Proposed draft "Mobility Support in NSIS" > > Date: Sat, 28 Jun 2003 23:43:09 +0200 > > From: Xiaoming Fu > > To: nsis@ietf.org > > > > Hi all, > > > > Here is a new Internet Draft that we propose as a problem > statement and > > proposed mechanisms to extend NSIS for mobility support: > > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.txt or > > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.pdf > > > > Following previous work (Michael Thomas, Cedric > Westphal/Hemant Chaskar, > > Charles Shen, and many others), this Draft aims to provide > an extensive > > view on mobility support related issues that will be of > broad general > > use. > > > > We welcome your comments. We are also especially interested in other > > open issues and studying how they may be addressed by > future versions of > > the Draft. > > > > Regards, > > Xiaoming > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 06:23:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16776 for ; Tue, 8 Jul 2003 06:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zpcj-0001Ug-TL for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 06:23:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68AN1Ld005725 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 06:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zpci-0001U8-NN; Tue, 08 Jul 2003 06:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zpc1-0001TA-9x for nsis@optimus.ietf.org; Tue, 08 Jul 2003 06:22:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16739 for ; Tue, 8 Jul 2003 06:22:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zpbx-0000TV-00 for nsis@ietf.org; Tue, 08 Jul 2003 06:22:13 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19Zpbw-0000TR-00 for nsis@ietf.org; Tue, 08 Jul 2003 06:22:12 -0400 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 08 Jul 2003 12:22:20 +0200 Message-ID: <3F0A9B5E.2060405@cs.uni-goettingen.de> Date: Tue, 08 Jul 2003 12:22:22 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles Q. Shen" , nsis@ietf.org Subject: Re: [NSIS] Proposed draft "Mobility Support in NSIS" References: <000d01c344c1$7bc28b70$c7f027a0@president> In-Reply-To: <000d01c344c1$7bc28b70$c7f027a0@president> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Charles, Additional comments inline: > Yes, you are right, the two addressing modes should be treated > differently on this issue. > > 1) in e2e mode like RSVP, RFC 2746 describes three possibilities of the > (logical) link. That seems to me is a more generic description. You are > certainly correct in pointing out the requirement for the two tunnel end > points to be NSIS aware to achieve a true e2e signaling. > > 2) in p2p mode, if the discovery is done properly with the help of NSIS > aware tunnel endpoints, you are probably right that such tunneling could > be avoided. (Do we have the path-coupled assumption here? ) True. RSVP signaling uses RSVP-in-RSVP encapsulation to support IP-in-IP tunnels in the data path. In the p2p mode, due to the seperation of discovery from signaling, an NTLP hop (either in the (MIP) tunnel entrance or inside the tunnel) can discover the next NTLP hop along the path anyway, thus avoiding NTLP-in-NTLP. With p2p mode, signaling can be extended to be somehow path-decoupled, but we may look at path-coupled first only. > >>- How can we know this comparision at all? This could be >>through an API, >>or, say, a mobility routing interface issue. If this knowledge is >>unaware to NSIS at all, a simplest way presumably can be NSIS signlaing >>directly after each moibility management. > > I think there is always a trade-off here in terms of signaling overheads > and promptness of response. Upon handoff, trying to achieve an > "on-demand" adjustment (i.e., movement triggers both MIP and NSIS) is -------->"route change"? (the node can be mobile host, home agent,...) > probably appropriate. This is another possibility one can do. IMO NSIS signaling after MIP signaling might be less complex, as it can happen MIP fails but NSIS succeeds if a handoff triggers both (then you need additional signaling to release NSIS states). Since the places where a route change takes place after a handoff differ, we have to coordinate these events (see some discussions in our I-D). Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 08:02:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18562 for ; Tue, 8 Jul 2003 08:02:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrAY-0005jw-IP for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 08:02:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68C2203022061 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 08:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrAX-0005ji-N8; Tue, 08 Jul 2003 08:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrAI-0005jO-CZ for nsis@optimus.ietf.org; Tue, 08 Jul 2003 08:01:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18545 for ; Tue, 8 Jul 2003 08:01:44 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZrAH-0000yS-00 for nsis@ietf.org; Tue, 08 Jul 2003 08:01:45 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19ZrAG-0000yP-00 for nsis@ietf.org; Tue, 08 Jul 2003 08:01:44 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h68C1h921262 for ; Tue, 8 Jul 2003 15:01:43 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 8 Jul 2003 15:01:43 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 15:01:43 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 15:01:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Jul 2003 15:01:30 +0300 Message-ID: Thread-Topic: Short Review of draft-shore-ntlp-00.txt Thread-Index: AcNFSKstNnGkZu60Ske2DDaszxCg4A== To: X-OriginalArrivalTime: 08 Jul 2003 12:01:38.0077 (UTC) FILETIME=[AF7E7CD0:01C34548] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Short Review of draft-shore-ntlp-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I'm doing a quick review on documents to be discussed at IETF 57. As this document is quite preliminary, I don't intend to give a detailed = review, but an initial overview of the document. http://www.ietf.org/internet-drafts/draft-shore-ntlp-00.txt 1) Terminology=20 This section needs to be expanded, with definitions provided. 2) Introduction The introduction is well written, sets out the proposal for the draft = and seems to provide the correct intro for the document. 3) NTLP Messages 4) Sending NTLP Messages I'm combining these sections all together. In general, I would have = liked to see a (somewhat) simplified overview of the protocol upfront, so I could get the overall picture of the protocol in my mind before seeing the = bits & bytes. I do like the TLV structure & generally have no major = complaints about the initial message & parameter formats. 5) Messaging and State Maintenance This section does capture state reduction well, however the text is = somewhat dense and complicated. I do think that a slightly slimmed down version=20 of this removing things like exponential back-off procedures, etc. could = have been better for a version 00 draft. I worry that the overall protocol = workings will become more complicated over time - which is usual for most IETF = protocols, so a simple proposal at first might be needed. SUMMARY The draft has a number of good things going for it, some of the details=20 are quite useful - however, a good editing with a view towards=20 simplifying the protocol would be benefitial. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 08:03:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18596 for ; Tue, 8 Jul 2003 08:03:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrBV-0005oZ-Fo for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 08:03:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68C31SU022351 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 08:03:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrBV-0005oP-Bm; Tue, 08 Jul 2003 08:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrBN-0005oB-Vg for nsis@optimus.ietf.org; Tue, 08 Jul 2003 08:02:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18582 for ; Tue, 8 Jul 2003 08:02:51 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZrBM-0000yy-00 for nsis@ietf.org; Tue, 08 Jul 2003 08:02:53 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ZrBM-0000yv-00 for nsis@ietf.org; Tue, 08 Jul 2003 08:02:52 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h68C2oa17311 for ; Tue, 8 Jul 2003 15:02:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 8 Jul 2003 15:02:50 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 15:02:50 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 15:02:49 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 15:01:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Jul 2003 15:01:26 +0300 Message-ID: Thread-Topic: Short Review of draft-schulzrinne-nsis-ntlp-00 Thread-Index: AcNFSKiXvqO9Ao3SQ6mZEphKpzb8Xw== To: X-OriginalArrivalTime: 08 Jul 2003 12:01:27.0941 (UTC) FILETIME=[A973DB50:01C34548] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Short Review of draft-schulzrinne-nsis-ntlp-00 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I'm doing a quick review on documents to be discussed at IETF 57. As this document is quite preliminary, I don't intend to give a detailed = review, but an initial overview of the document. http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-ntlp-00.txt 1) Terminology=20 This section needs to be expanded, with definitions provided. 2) Introduction Needs some improvement - the introduction feels like it makes a jump=20 straight into the details, where I feel that some more introductory material would be useful. 3) Objectives I would quibble with this objective: 1. Discover the set of nodes along the path from the data sender to the receiver (peer discovery); I've always thought that discovery comes as part of signaling along the data path. I think it is more proper to consider something along the lines of determining the concerned nodes along the path, rather than full-fledged discovery. 4) Overview of Operations In generally, I think that this style of this section is effective in providing an overview of the protocol. However, after I reading this section, I have worries about the amount of state needed - I feel that the devil may be in the details here - which, of course, are left for future versions of this document. 5) Transport Usage This section is quite short, but after reading it, I started to think = that what we may want is to support datagram mode as the default and = connection mode multiplexing traffic, etc. This is a very vague thought - but I = wonder if this is what you were getting at in the document, Henning. 6) Message Format=20 Not much comment yet, probably would like to see a future update with = some of this fleshed out. 7) Security Considerations Not much comment, but I am glad to see a more than perfucntory security=20 considerations section SUMMARY The document is readable and does have a somewhat straight-forwardness = to it, which is a good thing in my opinion. I worry about some of the state management, which has been a problem with RSVP, so I think this is one area that requires a bit of work. thanks, John =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 08:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19294 for ; Tue, 8 Jul 2003 08:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrfV-0007Hp-AW for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 08:34:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68CY1Oo027992 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 08:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrfU-0007HN-TP; Tue, 08 Jul 2003 08:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zrf9-0007HA-Dc for nsis@optimus.ietf.org; Tue, 08 Jul 2003 08:33:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19276 for ; Tue, 8 Jul 2003 08:33:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zrf8-0001Ab-00 for nsis@ietf.org; Tue, 08 Jul 2003 08:33:38 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19Zrf7-0001AT-00 for nsis@ietf.org; Tue, 08 Jul 2003 08:33:37 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 8 Jul 2003 14:31:20 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <3NTLH54K>; Tue, 8 Jul 2003 14:31:19 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB52D@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Short Review of draft-shore-ntlp-00.txt Date: Tue, 8 Jul 2003 14:31:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi John, is it correct to draw the conclusion that you don't feel Melinda's=20 draft to be a bit short on security? The security section=20 currently reads: we need to determine exactly what we're protecting and why. Regards, R=FCdiger |Hi all, | |I'm doing a quick review on documents to be discussed at IETF 57. | |As this document is quite preliminary, I don't intend to give=20 |a detailed review, but an initial overview of the document. | |http://www.ietf.org/internet-drafts/draft-shore-ntlp-00.txt [snip] |SUMMARY | |The draft has a number of good things going for it, some of=20 |the details are quite useful - however, a good editing with |a view towards simplifying the protocol would be benefitial. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 08:40:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19450 for ; Tue, 8 Jul 2003 08:40:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrlK-0007kZ-3y for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 08:40:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Ce2g2029771 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 08:40:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrlJ-0007k4-NB; Tue, 08 Jul 2003 08:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zrkv-0007jU-Fr for nsis@optimus.ietf.org; Tue, 08 Jul 2003 08:39:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19438 for ; Tue, 8 Jul 2003 08:39:34 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zrku-0001CF-00 for nsis@ietf.org; Tue, 08 Jul 2003 08:39:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Zrkt-0001CC-00 for nsis@ietf.org; Tue, 08 Jul 2003 08:39:35 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h68CdY924598 for ; Tue, 8 Jul 2003 15:39:34 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 8 Jul 2003 15:39:34 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 15:39:33 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 15:39:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 15:39:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Short Review of draft-shore-ntlp-00.txt Date: Tue, 8 Jul 2003 15:39:31 +0300 Message-ID: Thread-Topic: [NSIS] Short Review of draft-shore-ntlp-00.txt Thread-Index: AcNFTRZFP/NpHS/TQaOB9a2UyC9ZKAAAGOxw To: Cc: X-OriginalArrivalTime: 08 Jul 2003 12:39:32.0682 (UTC) FILETIME=[FB43AAA0:01C3454D] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi R=FCdiger, > is it correct to draw the conclusion that you don't feel Melinda's=20 > draft to be a bit short on security? The security section currently = reads: > we need to determine exactly what we're protecting and why. It is short on security, and would definately need something more = significant in this section. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 08:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19638 for ; Tue, 8 Jul 2003 08:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zrr7-00083F-GU for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 08:46:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Ck1Ae030931 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 08:46:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zrr7-00082n-Co; Tue, 08 Jul 2003 08:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zrqv-00081w-JW for nsis@optimus.ietf.org; Tue, 08 Jul 2003 08:45:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19600 for ; Tue, 8 Jul 2003 08:45:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zrqu-0001EZ-00 for nsis@ietf.org; Tue, 08 Jul 2003 08:45:48 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19Zrqt-0001ER-00 for nsis@ietf.org; Tue, 08 Jul 2003 08:45:47 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2003 05:47:57 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h68CjFpZ011889; Tue, 8 Jul 2003 05:45:16 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJG58129; Tue, 8 Jul 2003 05:45:14 -0700 (PDT) Message-Id: <200307081245.AJG58129@mira-sjc5-c.cisco.com> To: "Geib, Ruediger" cc: john.loughney@nokia.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Short Review of draft-shore-ntlp-00.txt In-Reply-To: Message from Ruediger.Geib@t-systems.com of "Tue, 08 Jul 2003 14:31:13 +0200." <9F8582E37B2EE5498E76392AEDDCD3FE03DBB52D@G8PQD.blf01.telekom.de> Date: Tue, 08 Jul 2003 08:45:14 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I think it's fair to say that Melinda's draft is quite short on security. It seems to me that the security situation around the layer split is generally not that well-understood and needs further discussion - I'm not sure that it's meaningful to go through the list of security facets (privacy, integrity protection, etc.) and say "we need this, this, and this" at this point because we're not as clear as we need to be, I think, about what the issues are at the NTLP layer. Some are probably obvious (replay protection) but some are not, and there are some very difficult issues around both keying and authorization. There are some efforts elsewhere within the IETF that may or may not have some relevance (soBGP, for example). I'd actually like to see a separate security design team for the NTLP. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 09:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21448 for ; Tue, 8 Jul 2003 09:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZsoA-0002rn-SX for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 09:47:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Dl2BC011006 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 09:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zso9-0002rE-Bm; Tue, 08 Jul 2003 09:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zsnu-0002qk-T2 for nsis@optimus.ietf.org; Tue, 08 Jul 2003 09:46:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21426 for ; Tue, 8 Jul 2003 09:46:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zsns-0001fF-00 for nsis@ietf.org; Tue, 08 Jul 2003 09:46:44 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19Zsns-0001ex-00 for nsis@ietf.org; Tue, 08 Jul 2003 09:46:44 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 8 Jul 2003 15:46:13 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <3NTLH06F>; Tue, 8 Jul 2003 15:46:12 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB52E@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: mshore@cisco.com Cc: nsis@ietf.org Subject: RE: [NSIS] Short Review of draft-shore-ntlp-00.txt Date: Tue, 8 Jul 2003 15:46:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Melinda [snip] |Some are probably obvious (replay protection) |but some are not, and there are some very difficult issues |around both keying and authorization. When signaling crosses domain borders (lightweight) message integrity and authentication are required. Bogus messages should be identified and deleted at the lowest possible layer (NTLP is better than NSLP, but if feasible the transport below NTLP was better than NTLP). |There are some efforts elsewhere within the IETF |that may or may not have some relevance (soBGP, for |example). Yes, its a good idea to check their security requirements and solutions. |I'd actually like to see a separate security design |team for the NTLP. Reaching consensus on the way we'd like to proceed with NTLP security design certainly is helpful. Regards, Rudiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 13:42:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01594 for ; Tue, 8 Jul 2003 13:42:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZwTb-0008J5-Cm for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 13:42:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Hg33r031900 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 13:42:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZwTa-0008I3-0A; Tue, 08 Jul 2003 13:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZwTW-0008HZ-DH for nsis@optimus.ietf.org; Tue, 08 Jul 2003 13:41:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01556 for ; Tue, 8 Jul 2003 13:41:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZwTU-0003oi-00 for nsis@ietf.org; Tue, 08 Jul 2003 13:41:56 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ZwTP-0003oe-00 for nsis@ietf.org; Tue, 08 Jul 2003 13:41:55 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2003 10:39:05 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h68HfJrm022008; Tue, 8 Jul 2003 10:41:20 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFU94531; Tue, 8 Jul 2003 10:41:13 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA09210; Tue, 8 Jul 2003 10:41:13 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16139.569.394014.312229@thomasm-u1.cisco.com> Date: Tue, 8 Jul 2003 10:41:13 -0700 (PDT) To: "Geib, Ruediger" Cc: mshore@cisco.com, nsis@ietf.org Subject: RE: [NSIS] Short Review of draft-shore-ntlp-00.txt In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB52E@G8PQD.blf01.telekom.de> References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB52E@G8PQD.blf01.telekom.de> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Geib, Ruediger writes: > Melinda > > [snip] > |Some are probably obvious (replay protection) > |but some are not, and there are some very difficult issues > |around both keying and authorization. > > When signaling crosses domain borders (lightweight) message > integrity and authentication are required. Bogus messages > should be identified and deleted at the lowest possible > layer (NTLP is better than NSLP, but if feasible the > transport below NTLP was better than NTLP). I don't see why this is a priori true. In general, you gain the most flexibility by moving functionality up the stack. The tradeoff is the potential for lack of uniformity, and the corresponding possibility for breaches due to, oh say, insufficient review. Right now the two things that most resemble NSIS are RSVP and SIP to my mind. BGP has some of the same problems as Melinda points out, but I'm not as well clued in there. RSVP has elected to keep all of it at application layer, and SIP has elected to use lower level security for hop-by-hop and application layer for hop-spanning needs. The biggest win with the SIP approach, IMO, is that you inherit key management which has been well vetted. This is something that the RSVP integrity object lacks, and would require further standardization to make it useful. Which isn't to say that it's appropriate for NSIS because though similar to SIP, it is not the same (cf discovery...). Also: as with SIP, lower layer security protocols are not ideal either. TLS doesn't run over UDP, and IPsec has trouble with cross-layer binding of auth to authz. TLS also suffers from fairly trivial DoS attacks if you can see the traffic flowing by (otherwise it's O(guess-large-number)). So I guess I don't see this as really clear. With MIPv6 I made the argument for IPsec for binding updates primarily because of the keying problem. RSVP/NSIS do not have the same security considerations though and it's not even clear whether hop-by-hop integrity is even all that useful since we have the alternate means of auth/authz through policy objects and/or COPS. To my knowledge neither policy or integrity are widely implemented or used, but the one thing to be said about the policy objects is that the COPS model is extremely analogous to AAA which is pervasive. And that model does not require or care about hop-by-hop integrity. Which isn't to say that that's an arguably bad thing, just that it is in fact reality. Given this, it may well be that NSIS is exactly *inverted* from the SIP mechanism. That is, SIP's primarly line of auth/authz defense is made at the hop-by-hop transport level. NSIS -- like AAA -- may well be at the non-adjacent application layer, which should inform how much effort we should expend on each; a simple necessary and sufficient at hop-by-hop may actually be the right answer ala RSVP. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 13:51:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01919 for ; Tue, 8 Jul 2003 13:51:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZwcH-0000Ja-Rm for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 13:51:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Hp1id001208 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 13:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZwcH-0000JO-O2; Tue, 08 Jul 2003 13:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zwba-0000Ik-Ot for nsis@optimus.ietf.org; Tue, 08 Jul 2003 13:50:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01882 for ; Tue, 8 Jul 2003 13:50:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZwbY-0003u0-00 for nsis@ietf.org; Tue, 08 Jul 2003 13:50:16 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19ZwbY-0003tx-00 for nsis@ietf.org; Tue, 08 Jul 2003 13:50:16 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h68HoDkM019584; Tue, 8 Jul 2003 13:50:13 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h68HoCN20474; Tue, 8 Jul 2003 13:50:12 -0400 Message-ID: <3F0B0361.5090306@cs.columbia.edu> Date: Tue, 08 Jul 2003 13:46:09 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas CC: nsis@ietf.org Subject: Re: [NSIS] Short Review of draft-shore-ntlp-00.txt References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB52E@G8PQD.blf01.telekom.de> <16139.569.394014.312229@thomasm-u1.cisco.com> In-Reply-To: <16139.569.394014.312229@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think we should be somewhat careful in extrapolating from one application, QoS, to all of NTLP. It may well be possible to do this, but I could imagine that other near or long-term NSIS applications, such as network diagnostics or active code deposits, fall somewhere else on the transport-vs-application security axis. For example, it might be considered undesirable if random parties can easily spoof diagnostic information along a path. Also, unlike RSVP, the separation into two layers opens up additional DOS attacks, such as establishing lots of state on NSIS nodes. (Nodes sometimes have to establish state even if they do not understand the NSLP layer, or so has been argued.) Michael Thomas wrote: > Geib, Ruediger writes: > > Melinda > > > > [snip] > > |Some are probably obvious (replay protection) > > |but some are not, and there are some very difficult issues > > |around both keying and authorization. > > > > When signaling crosses domain borders (lightweight) message > > integrity and authentication are required. Bogus messages > > should be identified and deleted at the lowest possible > > layer (NTLP is better than NSLP, but if feasible the > > transport below NTLP was better than NTLP). > > I don't see why this is a priori true. In general, > you gain the most flexibility by moving > functionality up the stack. The tradeoff is the > potential for lack of uniformity, and the > corresponding possibility for breaches due to, oh > say, insufficient review. > > Right now the two things that most resemble NSIS > are RSVP and SIP to my mind. BGP has some of the > same problems as Melinda points out, but I'm not > as well clued in there. RSVP has elected to keep > all of it at application layer, and SIP has > elected to use lower level security for hop-by-hop > and application layer for hop-spanning needs. The > biggest win with the SIP approach, IMO, is that > you inherit key management which has been well > vetted. This is something that the RSVP integrity > object lacks, and would require further > standardization to make it useful. Which isn't to > say that it's appropriate for NSIS because though > similar to SIP, it is not the same (cf > discovery...). Also: as with SIP, lower layer > security protocols are not ideal either. TLS > doesn't run over UDP, and IPsec has trouble with > cross-layer binding of auth to authz. TLS also > suffers from fairly trivial DoS attacks if you can > see the traffic flowing by (otherwise it's > O(guess-large-number)). > > So I guess I don't see this as really clear. With > MIPv6 I made the argument for IPsec for binding > updates primarily because of the keying problem. > RSVP/NSIS do not have the same security > considerations though and it's not even clear > whether hop-by-hop integrity is even all that > useful since we have the alternate means of > auth/authz through policy objects and/or COPS. To > my knowledge neither policy or integrity are > widely implemented or used, but the one thing to > be said about the policy objects is that the COPS > model is extremely analogous to AAA which is > pervasive. And that model does not require or care > about hop-by-hop integrity. Which isn't to say > that that's an arguably bad thing, just that it is > in fact reality. Given this, it may well be that > NSIS is exactly *inverted* from the SIP mechanism. > That is, SIP's primarly line of auth/authz defense > is made at the hop-by-hop transport level. NSIS -- > like AAA -- may well be at the non-adjacent > application layer, which should inform how much > effort we should expend on each; a simple > necessary and sufficient at hop-by-hop may > actually be the right answer ala RSVP. > > Mike > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 14:21:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02895 for ; Tue, 8 Jul 2003 14:21:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zx5I-0002c8-6R for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 14:21:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68IL0X6010046 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 14:21:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zx5I-0002bw-3Q; Tue, 08 Jul 2003 14:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zx4u-0002bN-V8 for nsis@optimus.ietf.org; Tue, 08 Jul 2003 14:20:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02882 for ; Tue, 8 Jul 2003 14:20:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zx4s-0004FA-00 for nsis@ietf.org; Tue, 08 Jul 2003 14:20:34 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19Zx4r-0004F7-00 for nsis@ietf.org; Tue, 08 Jul 2003 14:20:33 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h68IKVkM022191; Tue, 8 Jul 2003 14:20:31 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h68IKUN23371; Tue, 8 Jul 2003 14:20:31 -0400 Message-ID: <3F0B0A7C.20905@cs.columbia.edu> Date: Tue, 08 Jul 2003 14:16:28 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] Short Review of draft-schulzrinne-nsis-ntlp-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Some remarks. john.loughney@nokia.com wrote: > 3) Objectives > > I would quibble with this objective: > > 1. Discover the set of nodes along the path from the data sender to > the receiver (peer discovery); > > I've always thought that discovery comes as part of signaling along > the data path. I think it is more proper to consider something > along the lines of determining the concerned nodes along the path, > rather than full-fledged discovery. This is probably more a difference in terminology than objective. It is probably both determining the nodes by sending packets towards the destination and, indirectly, discovering what they are (by any messages that tell a previous hop what the next hop is). One more general point is that I'd like to logically keep these separate as there is no technical necessity that discovery/next-hop-determination is only done by sending packets. It currently is, but as discussed during the 'reroute' discussion, under some circumstances it may be more expedient to consult the source of routing behavior rather than poll for it. > In generally, I think that this style of this section is effective in > providing an overview of the protocol. However, after I reading this > section, I have worries about the amount of state needed - I feel > that the devil may be in the details here - which, of course, are > left for future versions of this document. From our implementation, the amount of state is not terribly large and no larger than (and likely smaller than) RSVP. There is per-session state such as the next and previous hop address and a last-message timer, as well as housekeeping information. The additional transport state is per-peer, not per-session. The number of peers is likely to be much smaller than the number of sessions, or at least bounded by a constant (depending on state management policies). Clearly, this needs to be spelled out in more detail. > > 5) Transport Usage > > This section is quite short, but after reading it, I started to think that > what we may want is to support datagram mode as the default and connection > mode multiplexing traffic, etc. This is a very vague thought - but I wonder > if this is what you were getting at in the document, Henning. Yes, roughly. To put the motivation very sloppily: have NTLP handle the easy transport, punt to a professional transport protocol for the hard cases. Easy = short messages sent infrequently to new destinations with relaxed reliability, so that fragmentation, RTT estimation, less-than-N-RTT loss detection, flow control and congestion control are largely somebody else's problem. > > 6) Message Format > > Not much comment yet, probably would like to see a future update with some > of this fleshed out. Definitely. My current preference is RSVP TLV-like. Although we haven't talked about this much, judging from other contributions to this discussion, this may be the first IETF working group where the bit format is not a major bone of contention :-) > it, which is a good thing in my opinion. I worry about some of the > state management, which has been a problem with RSVP, so I think More details are needed, but the outline is that if there is transport state at all (many sessions won't need it), it needs to be subject to the same soft-state mechanisms as other NTLP state, but implementations should be free to trade the cost of establishing new state vs. the cost of maintaining state by hanging onto transport state if both ends agree. Thanks for your comments. Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 8 17:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11392 for ; Tue, 8 Jul 2003 17:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a04A-0008G7-Gc for nsis-archive@odin.ietf.org; Tue, 08 Jul 2003 17:32:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68LW21K031741 for nsis-archive@odin.ietf.org; Tue, 8 Jul 2003 17:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a049-0008Fq-NB; Tue, 08 Jul 2003 17:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a03W-0008BC-3c for nsis@optimus.ietf.org; Tue, 08 Jul 2003 17:31:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11375 for ; Tue, 8 Jul 2003 17:31:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a03T-0006tn-00 for nsis@ietf.org; Tue, 08 Jul 2003 17:31:19 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19a03R-0006sq-00 for nsis@ietf.org; Tue, 08 Jul 2003 17:31:17 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2003 14:33:31 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h68LUkMr028664; Tue, 8 Jul 2003 14:30:46 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFV22748; Tue, 8 Jul 2003 14:30:45 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09455; Tue, 8 Jul 2003 14:30:45 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16139.14340.907062.374071@thomasm-u1.cisco.com> Date: Tue, 8 Jul 2003 14:30:44 -0700 (PDT) To: Henning Schulzrinne Cc: Michael Thomas , nsis@ietf.org Subject: Re: [NSIS] Short Review of draft-shore-ntlp-00.txt In-Reply-To: <3F0B0361.5090306@cs.columbia.edu> References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB52E@G8PQD.blf01.telekom.de> <16139.569.394014.312229@thomasm-u1.cisco.com> <3F0B0361.5090306@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit At first I thought there was merit to the "QoS-specific" rap, but as I re-read it, I'm not sure that what I wrote is especially related to QoS. It's always true that there may be situations where you want confidentiality, key mgmt, etc in hop-by-hop, but it's really more of a question of prioritization and effort. That is, how worth is it to get this more "correct" for NSIS than it is for RSVP? SIP had pretty good motivation, not the least of which was the possiblity of transporting SRTP keys, but the UA/proxy architecture as the norm makes a pretty compelling argument as well. The question, really, is whether NSIS applications are more SIP-like or AAA-like in their authorization and delegation. I'm not a huge AAA fan, but I think it's unarguably the case that people like that model, and there's tons of deployment. Indeed, there's been plenty of noise even in SIP land to integrate with legacy AAA too. I tend to think that that lure will persist if not strengthen with NSIS, especially as policy becomes more complicated. So if I had to choose whether to put a bunch of effort making hop-by-hop auth/conf/authz better or hop-to-decision-maker architectures better, I'd choose the later. Maybe we have to do both, but I for one am not eager reopen the same debate with NSIS as was, IMO, unsatisfactorily resolved in SIP. There seems like there are better things to worry about. Mike Henning Schulzrinne writes: > I think we should be somewhat careful in extrapolating from one > application, QoS, to all of NTLP. It may well be possible to do this, > but I could imagine that other near or long-term NSIS applications, such > as network diagnostics or active code deposits, fall somewhere else on > the transport-vs-application security axis. For example, it might be > considered undesirable if random parties can easily spoof diagnostic > information along a path. > > Also, unlike RSVP, the separation into two layers opens up additional > DOS attacks, such as establishing lots of state on NSIS nodes. (Nodes > sometimes have to establish state even if they do not understand the > NSLP layer, or so has been argued.) > Michael Thomas wrote: > > > Geib, Ruediger writes: > > > Melinda > > > > > > [snip] > > > |Some are probably obvious (replay protection) > > > |but some are not, and there are some very difficult issues > > > |around both keying and authorization. > > > > > > When signaling crosses domain borders (lightweight) message > > > integrity and authentication are required. Bogus messages > > > should be identified and deleted at the lowest possible > > > layer (NTLP is better than NSLP, but if feasible the > > > transport below NTLP was better than NTLP). > > > > I don't see why this is a priori true. In general, > > you gain the most flexibility by moving > > functionality up the stack. The tradeoff is the > > potential for lack of uniformity, and the > > corresponding possibility for breaches due to, oh > > say, insufficient review. > > > > Right now the two things that most resemble NSIS > > are RSVP and SIP to my mind. BGP has some of the > > same problems as Melinda points out, but I'm not > > as well clued in there. RSVP has elected to keep > > all of it at application layer, and SIP has > > elected to use lower level security for hop-by-hop > > and application layer for hop-spanning needs. The > > biggest win with the SIP approach, IMO, is that > > you inherit key management which has been well > > vetted. This is something that the RSVP integrity > > object lacks, and would require further > > standardization to make it useful. Which isn't to > > say that it's appropriate for NSIS because though > > similar to SIP, it is not the same (cf > > discovery...). Also: as with SIP, lower layer > > security protocols are not ideal either. TLS > > doesn't run over UDP, and IPsec has trouble with > > cross-layer binding of auth to authz. TLS also > > suffers from fairly trivial DoS attacks if you can > > see the traffic flowing by (otherwise it's > > O(guess-large-number)). > > > > So I guess I don't see this as really clear. With > > MIPv6 I made the argument for IPsec for binding > > updates primarily because of the keying problem. > > RSVP/NSIS do not have the same security > > considerations though and it's not even clear > > whether hop-by-hop integrity is even all that > > useful since we have the alternate means of > > auth/authz through policy objects and/or COPS. To > > my knowledge neither policy or integrity are > > widely implemented or used, but the one thing to > > be said about the policy objects is that the COPS > > model is extremely analogous to AAA which is > > pervasive. And that model does not require or care > > about hop-by-hop integrity. Which isn't to say > > that that's an arguably bad thing, just that it is > > in fact reality. Given this, it may well be that > > NSIS is exactly *inverted* from the SIP mechanism. > > That is, SIP's primarly line of auth/authz defense > > is made at the hop-by-hop transport level. NSIS -- > > like AAA -- may well be at the non-adjacent > > application layer, which should inform how much > > effort we should expend on each; a simple > > necessary and sufficient at hop-by-hop may > > actually be the right answer ala RSVP. > > > > Mike > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 01:35:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22805 for ; Wed, 9 Jul 2003 01:35:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a7ba-000783-VI for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 01:35:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h695Z25t027399 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 01:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a7bY-00077j-MX; Wed, 09 Jul 2003 01:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a7an-00077A-Oj for nsis@optimus.ietf.org; Wed, 09 Jul 2003 01:34:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22799 for ; Wed, 9 Jul 2003 01:34:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a7ak-0003hY-00 for nsis@ietf.org; Wed, 09 Jul 2003 01:34:10 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19a7aj-0003hV-00 for nsis@ietf.org; Wed, 09 Jul 2003 01:34:10 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h695Y4Oa014565 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Jul 2003 01:34:07 -0400 (EDT) From: "Charles Q. Shen" To: "'Xiaoming Fu'" , Subject: RE: [NSIS] Proposed draft "Mobility Support in NSIS" Date: Wed, 9 Jul 2003 01:33:59 -0400 Organization: Columbia University Message-ID: <000c01c345db$b52808c0$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <3F0A9B5E.2060405@cs.uni-goettingen.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Xiaoming, a few comments inline. > -----Original Message----- > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: Tuesday, July 08, 2003 6:22 AM > To: Charles Q. Shen; nsis@ietf.org > Subject: Re: [NSIS] Proposed draft "Mobility Support in NSIS" > > True. RSVP signaling uses RSVP-in-RSVP encapsulation to > support IP-in-IP > tunnels in the data path. In the p2p mode, due to the seperation of > discovery from signaling, an NTLP hop (either in the (MIP) tunnel > entrance or inside the tunnel) can discover the next NTLP hop > along the > path anyway, thus avoiding NTLP-in-NTLP. > > With p2p mode, signaling can be extended to be somehow > path-decoupled, > but we may look at path-coupled first only. > I think the path-decoupled case is different in that signaling message itself may not care about optimized/non-optimized path, but the related actions (e.g. QoS allocation) performed will still involve the routing path used. I agree that we may look at path-coupled case only at this time. > > > >>- How can we know this comparision at all? This could be > >>through an API, > >>or, say, a mobility routing interface issue. If this knowledge is > >>unaware to NSIS at all, a simplest way presumably can be > NSIS signlaing > >>directly after each moibility management. > > > > I think there is always a trade-off here in terms of signaling > > overheads and promptness of response. Upon handoff, trying > to achieve > > an "on-demand" adjustment (i.e., movement triggers both MIP > and NSIS) > > is > -------->"route change"? (the node can > be mobile host, home > agent,...) Usually I refer to "movement" as mobile node changing its points of attachment at network edge. But there is a close relationship between this and route change inside the network. I remember that is exactly how we came up with using "RSVP local repair property" in the RSVP-mobility framework. > > probably appropriate. > > This is another possibility one can do. IMO NSIS signaling after MIP > signaling might be less complex, as it can happen MIP fails but NSIS > succeeds if a handoff triggers both (then you need additional > signaling > to release NSIS states). Yes, you are right. By loosely saying "trigger both", there are actually still possibilities of "triggering both in parallel" or "triggering both in sequential". Again there is a tradeoff of choosing either of them. > Since the places where a route change takes > place after a handoff differ, we have to coordinate these events (see > some discussions in our I-D). Not crystally clear about what you mean in this senstence, appreciate it if you could elaborate. BR/ Charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 02:50:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20472 for ; Wed, 9 Jul 2003 02:50:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8mB-0006Hf-2y for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 02:50:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h696o3a8024137 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 02:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8mA-0006Gu-8x; Wed, 09 Jul 2003 02:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8ld-0006FX-If for nsis@optimus.ietf.org; Wed, 09 Jul 2003 02:49:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20448 for ; Wed, 9 Jul 2003 02:49:26 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a8lZ-00047F-00 for nsis@ietf.org; Wed, 09 Jul 2003 02:49:25 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19a8lZ-00047C-00 for nsis@ietf.org; Wed, 09 Jul 2003 02:49:25 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h696nOk11120 for ; Wed, 9 Jul 2003 09:49:24 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 9 Jul 2003 09:49:24 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 09:49:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 09:49:24 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 09:49:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Proposed draft "Mobility Support in NSIS" Date: Wed, 9 Jul 2003 09:49:22 +0300 Message-ID: Thread-Topic: [NSIS] Proposed draft "Mobility Support in NSIS" Thread-Index: AcNFOvPyCF639ArbRf6NTo2VTSLCvAAqwvsw To: , , X-OriginalArrivalTime: 09 Jul 2003 06:49:23.0441 (UTC) FILETIME=[3B31A610:01C345E6] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Xiaoming, > With p2p mode, signaling can be extended to be somehow path-decoupled, = > but we may look at path-coupled first only. Just to be clear, right now path-decoupled operation is out of scope for NSIS. In order to support path-decoupled operation, we would need a rechartering & we would need to have completed more of our = deliverables. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 05:30:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25325 for ; Wed, 9 Jul 2003 05:30:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aBH2-00036E-7J for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 05:30:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h699U4gP011911 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 05:30:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aBH1-00035q-1J; Wed, 09 Jul 2003 05:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aBGq-00034y-JA for nsis@optimus.ietf.org; Wed, 09 Jul 2003 05:29:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25300 for ; Wed, 9 Jul 2003 05:29:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aBGm-0005Qj-00 for nsis@ietf.org; Wed, 09 Jul 2003 05:29:48 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 19aBGl-0005Qg-00 for nsis@ietf.org; Wed, 09 Jul 2003 05:29:47 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h699Tlx07384; Wed, 9 Jul 2003 11:29:47 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h699Tk010851; Wed, 9 Jul 2003 11:29:46 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <3D8BLPZM>; Wed, 9 Jul 2003 11:29:45 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFFAC@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Michael Thomas'" , "Geib, Ruediger" Cc: mshore@cisco.com, nsis@ietf.org Subject: RE: [NSIS] Short Review of draft-shore-ntlp-00.txt Date: Wed, 9 Jul 2003 11:29:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, please find further comments inline: > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, July 08, 2003 7:41 PM > To: Geib, Ruediger > Cc: mshore@cisco.com; nsis@ietf.org > Subject: RE: [NSIS] Short Review of draft-shore-ntlp-00.txt > > > Geib, Ruediger writes: > > Melinda > > > > [snip] > > |Some are probably obvious (replay protection) > > |but some are not, and there are some very difficult issues > > |around both keying and authorization. > > > > When signaling crosses domain borders (lightweight) message > > integrity and authentication are required. Bogus messages > > should be identified and deleted at the lowest possible > > layer (NTLP is better than NSLP, but if feasible the > > transport below NTLP was better than NTLP). > > I don't see why this is a priori true. In general, > you gain the most flexibility by moving > functionality up the stack. The tradeoff is the > potential for lack of uniformity, and the > corresponding possibility for breaches due to, oh > say, insufficient review. > > Right now the two things that most resemble NSIS > are RSVP and SIP to my mind. BGP has some of the > same problems as Melinda points out, but I'm not > as well clued in there. i have difficulties to see the relationship to the mentioned certificate distribution mechanism using bgp. > RSVP has elected to keep > all of it at application layer, this sounds like there was a design consideration phase which finally decided to support security at the application layer. actually, i think that there was no other choice (due to some design decisions). > and SIP has > elected to use lower level security for hop-by-hop > and application layer for hop-spanning needs. ... because design decisions in the protocol give the freedoom to chose a number of mechanisms. > The > biggest win with the SIP approach, IMO, is that > you inherit key management which has been well > vetted. certainly and there aren't too many flexible and standardized protocol which support authentication and key exchange (including subsequent message protection). > This is something that the RSVP integrity > object lacks, and would require further >standardization to make it useful. > Which isn't to > say that it's appropriate for NSIS because though > similar to SIP, it is not the same (cf > discovery...). the discovery combined with signaling message delivery, as pointed out several times, is not very helpful for a number of things (including security). > Also: as with SIP, lower layer > security protocols are not ideal either. TLS > doesn't run over UDP, and IPsec has trouble with > cross-layer binding of auth to authz. TLS also > suffers from fairly trivial DoS attacks if you can > see the traffic flowing by (otherwise it's > O(guess-large-number)). creating your own security solution at the application layer is also not trivial (see rsvp security). > > So I guess I don't see this as really clear. With > MIPv6 I made the argument for IPsec for binding > updates primarily because of the keying problem. > RSVP/NSIS do not have the same security > considerations though and it's not even clear > whether hop-by-hop integrity is even all that > useful since we have the alternate means of > auth/authz through policy objects and/or COPS. you might want to take a look at our nsis/aaa draft. we believe that hop-by-hop integrity is a useful concept. > To > my knowledge neither policy or integrity are > widely implemented or used, maybe since rsvp is not widely used ? microsoft implemented the kerberos authentication mechanism. in the packetcable environment the integrity mechanism is used. but the one thing to > be said about the policy objects is that the COPS > model is extremely analogous to AAA which is > pervasive. you might want to take a look at the 3gpp ims model (sip usage in the 3gpp environment): there you will find: - a protocol executed between the end host and a node in the network (sip) - a protocol between the visited network and the home network (let's call it aaa protocol) authentication, authorization is done initial (with the first few messages) - subsequently keys are in place to protect signaling messages between these nodes. i am unbiased with regard to cops - it could well be another protocol such as radius or diameter (but that does not change anything). if you look at the QoS NSLP Authorization Issues draft then you will find some questions which might, as a consequence, require either the above described approach or something else. certainly, it is not only a technical issue but also an issue of control (i.e. how much control do you want to place at the home network). but that's probably a longer story. > And that model does not require or care > about hop-by-hop integrity. Which isn't to say > that that's an arguably bad thing, just that it is > in fact reality. i hope that i misunderstood you. you are not saying that the hop-by-hop security is not required? entity authentication alone is not the whole story. if you only do the initial aaa communication then you have nothing more! > Given this, it may well be that > NSIS is exactly *inverted* from the SIP mechanism. i would like to know how you reached this conclusion. i think that nsis is closer to sip than one might think (with regard to some nslps). > That is, SIP's primarly line of auth/authz defense > is made at the hop-by-hop transport level. NSIS -- > like AAA -- may well be at the non-adjacent > application layer, which should inform how much > effort we should expend on each; could you explain this non-ajacent application layer issue a little bit more? is it something what we called "New Jersey Parkway Model" in the nsis/aaa draft? a simple > necessary and sufficient at hop-by-hop may > actually be the right answer ala RSVP. ciao hannes > > Mike > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 06:58:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27195 for ; Wed, 9 Jul 2003 06:58:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCeE-0002GP-TL for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 06:58:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Aw6HJ008658 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 06:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCeC-0002Dr-Bl; Wed, 09 Jul 2003 06:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aC91-0007qW-Sc for nsis@optimus.ietf.org; Wed, 09 Jul 2003 06:25:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26528 for ; Wed, 9 Jul 2003 06:25:47 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aC8y-0005hT-00 for nsis@ietf.org; Wed, 09 Jul 2003 06:25:48 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19aC8x-0005hP-00 for nsis@ietf.org; Wed, 09 Jul 2003 06:25:47 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h69APlk11845 for ; Wed, 9 Jul 2003 13:25:47 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 9 Jul 2003 13:25:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 13:25:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 13:25:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Short Review of draft-shore-ntlp-00.txt Date: Wed, 9 Jul 2003 13:25:45 +0300 Message-ID: Thread-Topic: [NSIS] Short Review of draft-shore-ntlp-00.txt Thread-Index: AcNFV3bMg04B1FSWQ4OcEnCgUP21cwArN/PA To: , Cc: X-OriginalArrivalTime: 09 Jul 2003 10:25:46.0316 (UTC) FILETIME=[759728C0:01C34604] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, > |I'd actually like to see a separate security design=20 > |team for the NTLP. >=20 > Reaching consensus on the way we'd like to proceed with=20 > NTLP security design certainly is helpful.=20 One of my suggestions in Vienna was to be about security / AAA aspects. Perhaps we should be prepared to discuss the next steps on this in Vienna. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 07:12:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27645 for ; Wed, 9 Jul 2003 07:12:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCrf-0004aJ-GA for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 07:11:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69BBxVE017616 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 07:11:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCrf-0004a1-Cl; Wed, 09 Jul 2003 07:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCqj-0003wv-5L for nsis@optimus.ietf.org; Wed, 09 Jul 2003 07:11:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27623 for ; Wed, 9 Jul 2003 07:10:56 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aCqe-00060i-00 for nsis@ietf.org; Wed, 09 Jul 2003 07:10:56 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19aCqd-00060e-00 for nsis@ietf.org; Wed, 09 Jul 2003 07:10:55 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h69BAua01075 for ; Wed, 9 Jul 2003 14:10:56 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 9 Jul 2003 14:10:56 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 14:10:54 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 14:10:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jul 2003 14:10:54 +0300 Message-ID: Thread-Topic: text conferencing at ietf57 Thread-Index: AcNEzQYLfajnmWJwQK2b7A+s65DN1gBPZ+VQ To: X-OriginalArrivalTime: 09 Jul 2003 11:10:54.0746 (UTC) FILETIME=[C3F0C7A0:01C3460A] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] FW: text conferencing at ietf57 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Anyone interested in being a scribe for this? Remote Access for the 57th IETF meeting in Vienna: Text Conferencing At each IETF meeting, two of the working group meeting rooms are = equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 57th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on ietf.jabber.at and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. In addition to the conference rooms for each wg that is meeting, there are three others of general interest: bar, hallway, and plenary. =20 1. Before the meeting: 1.1. If you want to participate =20 If you don't already have one, get yourself a Jabber client, here are = some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that.=20 =20 If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: =20 list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: =20 Group/Room: testing Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). =20 1.2. What the Chair does =20 If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) =20 So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? =20 =20 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as "scribe". If no one volunteers, read no further, we're done! Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: foobar Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along.=20 =20 2.4. Where to find the conference log =20 [ tbd: i'm still working on this one... ] =20 ####### _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 07:45:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27196 for ; Wed, 9 Jul 2003 06:58:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCeE-0002GM-TR for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 06:58:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Aw6eP008659 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 06:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCeD-0002EZ-FV; Wed, 09 Jul 2003 06:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCDE-0008Ct-M9 for nsis@optimus.ietf.org; Wed, 09 Jul 2003 06:30:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26640 for ; Wed, 9 Jul 2003 06:30:08 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aCDA-0005in-00 for nsis@ietf.org; Wed, 09 Jul 2003 06:30:08 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19aCD9-0005ik-00 for nsis@ietf.org; Wed, 09 Jul 2003 06:30:08 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h69AU8k15634 for ; Wed, 9 Jul 2003 13:30:08 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 9 Jul 2003 13:30:07 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 13:30:07 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 13:30:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Short Review of draft-schulzrinne-nsis-ntlp-00 Date: Wed, 9 Jul 2003 13:30:06 +0300 Message-ID: Thread-Topic: [NSIS] Short Review of draft-schulzrinne-nsis-ntlp-00 Thread-Index: AcNFfaHPNbiHaXPqSvKXracA8pqHwAAhuw7g To: Cc: X-OriginalArrivalTime: 09 Jul 2003 10:30:07.0148 (UTC) FILETIME=[110EF6C0:01C34605] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Henning, > > 3) Objectives > >=20 > > I would quibble with this objective: > >=20 > > 1. Discover the set of nodes along the path from the=20 > data sender to > > the receiver (peer discovery); > >=20 > > I've always thought that discovery comes as part of signaling along > > the data path. I think it is more proper to consider something > > along the lines of determining the concerned nodes along the path, > > rather than full-fledged discovery. >=20 > This is probably more a difference in terminology than objective. It = is=20 > probably both determining the nodes by sending packets towards the=20 > destination and, indirectly, discovering what they are (by any = messages=20 > that tell a previous hop what the next hop is). That is good - I was a bit worried about an active discovery mechanism that would/could search for off-path nodes, as that is clearly out of scope for the WG: > One more general point is that I'd like to logically keep these = separate=20 > as there is no technical necessity that = discovery/next-hop-determination=20 > is only done by sending packets. It currently is, but as discussed=20 > during the 'reroute' discussion, under some circumstances it may be = more=20 > expedient to consult the source of routing behavior rather than poll = for=20 > it. Sounds reasonable. > > In generally, I think that this style of this section is=20 > effective in > > providing an overview of the protocol. However, after I=20 > reading this > > section, I have worries about the amount of state needed - I feel > > that the devil may be in the details here - which, of course, are > > left for future versions of this document. >=20 > From our implementation, the amount of state is not terribly large = and=20 > no larger than (and likely smaller than) RSVP. There is per-session=20 > state such as the next and previous hop address and a last-message=20 > timer, as well as housekeeping information. The additional transport=20 > state is per-peer, not per-session. The number of peers is likely to = be=20 > much smaller than the number of sessions, or at least bounded by a=20 > constant (depending on state management policies). >=20 > Clearly, this needs to be spelled out in more detail. Perhaps that is the source of my concern - there seems not to be enough consideration on bounding this aspect. More detail is a good think. > >=20 > > 5) Transport Usage > >=20 > > This section is quite short, but after reading it, I=20 > started to think that > > what we may want is to support datagram mode as the default=20 > and connection > > mode multiplexing traffic, etc. This is a very vague=20 > thought - but I wonder > > if this is what you were getting at in the document, Henning. >=20 > Yes, roughly. To put the motivation very sloppily: have NTLP handle = the=20 > easy transport, punt to a professional transport protocol for the hard = > cases. Easy =3D short messages sent infrequently to new destinations = with=20 > relaxed reliability, so that fragmentation, RTT estimation,=20 > less-than-N-RTT loss detection, flow control and congestion control = are=20 > largely somebody else's problem. For example, 2961 has a lot of complexity - one may argue that not all = of the features of 2961 are actually needed for NSIS. However, rolling your own mechanisms in NTLP do accomplish some of what 2961 may be difficult. > > 6) Message Format=20 > >=20 > > Not much comment yet, probably would like to see a future update = with some > > of this fleshed out. >=20 > Definitely. My current preference is RSVP TLV-like. Although we = haven't=20 > talked about this much, judging from other contributions to this=20 > discussion, this may be the first IETF working group where the bit=20 > format is not a major bone of contention :-) Be thankful for small things ;) > > it, which is a good thing in my opinion. I worry about some of the > > state management, which has been a problem with RSVP, so I think >=20 > More details are needed, but the outline is that if there is transport = > state at all (many sessions won't need it), it needs to be subject to=20 > the same soft-state mechanisms as other NTLP state, but = implementations=20 > should be free to trade the cost of establishing new state vs. the = cost=20 > of maintaining state by hanging onto transport state if both ends = agree. Agreed, more text will help. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 11:13:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04337 for ; Wed, 9 Jul 2003 11:13:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGd6-00014v-H1 for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDC7V004121 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGcz-0000wZ-DG; Wed, 09 Jul 2003 11:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aDkC-0001B0-Cx for nsis@optimus.ietf.org; Wed, 09 Jul 2003 08:08:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28453 for ; Wed, 9 Jul 2003 08:08:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aDkB-0006EH-00 for nsis@ietf.org; Wed, 09 Jul 2003 08:08:19 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19aDkA-0006E7-00 for nsis@ietf.org; Wed, 09 Jul 2003 08:08:18 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h69C7kpp000440; Wed, 9 Jul 2003 05:07:47 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJH88817; Wed, 9 Jul 2003 05:07:45 -0700 (PDT) Message-Id: <200307091207.AJH88817@mira-sjc5-c.cisco.com> To: Michael Thomas cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Short Review of draft-shore-ntlp-00.txt In-Reply-To: Message from mat of "Tue, 08 Jul 2003 14:30:44 PDT." <16139.14340.907062.374071@thomasm-u1.cisco.com> Date: Wed, 09 Jul 2003 08:07:45 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > So if I had to choose whether to put a bunch of > effort making hop-by-hop auth/conf/authz better or > hop-to-decision-maker architectures better, I'd > choose the later. I think the latter obviously needs more attention in general, but when you slice apart the NSIS layers it becomes pretty clear that you need to focus on the hop-by-hop problem in the NTLP context or you end up doing things that aren't that meaningful for actually protecting the traffic or you end up overly constraining, I think, the design. For example, doing something like source authentication almost certainly doesn't make sense when you're providing a generalized mechanism for bundling NSLP payloads. It seems pretty clear to me that the NTLP security problem is hop-by-hop and the NSLP problem, depending on the application, will tend to be what you call "hop-to-decision- maker." Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 11:13:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04545 for ; Wed, 9 Jul 2003 11:13:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdG-0001Fb-6w for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDMa3004789 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdG-0001F9-21; Wed, 09 Jul 2003 11:13:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aFn1-00050M-Oa for nsis@optimus.ietf.org; Wed, 09 Jul 2003 10:19:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02624 for ; Wed, 9 Jul 2003 10:19:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aFmz-0006tn-00 for nsis@ietf.org; Wed, 09 Jul 2003 10:19:21 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19aFmy-0006tj-00 for nsis@ietf.org; Wed, 09 Jul 2003 10:19:20 -0400 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Wed, 09 Jul 2003 16:19:26 +0200 Message-ID: <3F0C246B.7060903@cs.uni-goettingen.de> Date: Wed, 09 Jul 2003 16:19:23 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles Q. Shen" , nsis@ietf.org Subject: Re: [NSIS] Proposed draft "Mobility Support in NSIS" References: <000c01c345db$b52808c0$c7f027a0@president> In-Reply-To: <000c01c345db$b52808c0$c7f027a0@president> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Charles, > I think the path-decoupled case is different in that signaling message > itself may not care about optimized/non-optimized path, but the related > actions (e.g. QoS allocation) performed will still involve the routing > path used. I agree that we may look at path-coupled case only at this > time. Independent of optimizated/non-optimized path, NSIS signaling can have minimum influence with MIP signaling - we may only need the "completion of MIP signaling" event (such as a mobility route change in the MN, HA and/or other nodes) to trigger/notify NSIS signaling. Then the latter will be following the data path and deliver signaling services (thru various NSLP messages) as needed. ...(snip) > >>Since the places where a route change takes >>place after a handoff differ, we have to coordinate these events (see >>some discussions in our I-D). > > > Not crystally clear about what you mean in this senstence, appreciate it > if you could elaborate. Meant "several nodes (such MN, HA and/or FA, possibly ARs in FMIP/CTP case) will have to change the routing entries for the data forwarding of flows sent to or received by the MN. As these events happen subsequently, one has to take care of a reasonable sequence of NSIS signaling process which will also go along these nodes." Some of such situations are discussed in issue 7 and section 4.1 of the I-D. Best regards, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 11:25:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05685 for ; Wed, 9 Jul 2003 11:25:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGoX-0004vx-CX for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 11:25:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FP1Kd018961 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 11:25:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGoX-0004vj-8E; Wed, 09 Jul 2003 11:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGna-0004g9-DM for nsis@optimus.ietf.org; Wed, 09 Jul 2003 11:24:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05581 for ; Wed, 9 Jul 2003 11:23:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aGnZ-0007WN-00 for nsis@ietf.org; Wed, 09 Jul 2003 11:24:01 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19aGnY-0007WK-00 for nsis@ietf.org; Wed, 09 Jul 2003 11:24:00 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h69FNwW23837; Wed, 9 Jul 2003 17:23:58 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h69FNw006791; Wed, 9 Jul 2003 17:23:58 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <3D8BL7XV>; Wed, 9 Jul 2003 17:23:57 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFFBB@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Melinda Shore'" , Michael Thomas , nsis@ietf.org Date: Wed, 9 Jul 2003 17:23:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] authorization Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi melinda, since you are raising the authorization discussion i would like to make things a little bit more precise: - which entities would you like to see involved in computing the authorization decision? - how long do you think is the authorization decision valid? (e.g. authorization decision only for a single request) - what information is needed to compute the authorization decision? (e.g. price, qos objects, etc.) do you think that the authorization decision along (together possible with entity authentication) is sufficient i.e. that there is no need for signaling message protection? ciao hannes > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, July 09, 2003 2:08 PM > To: Michael Thomas > Cc: nsis@ietf.org > Subject: Re: [NSIS] Short Review of draft-shore-ntlp-00.txt > > > > So if I had to choose whether to put a bunch of > > effort making hop-by-hop auth/conf/authz better or > > hop-to-decision-maker architectures better, I'd > > choose the later. > > I think the latter obviously needs more attention in > general, but when you slice apart the NSIS layers it becomes > pretty clear that you need to focus on the hop-by-hop > problem in the NTLP context or you end up doing things that > aren't that meaningful for actually protecting the traffic > or you end up overly constraining, I think, the design. For > example, doing something like source authentication almost > certainly doesn't make sense when you're providing a > generalized mechanism for bundling NSLP payloads. > > It seems pretty clear to me that the NTLP security problem > is hop-by-hop and the NSLP problem, depending on the > application, will tend to be what you call "hop-to-decision- > maker." > > Melinda > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 12:17:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08279 for ; Wed, 9 Jul 2003 12:17:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHd1-0001kb-Au for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 12:17:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69GHBLK006712 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 12:17:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHcr-0001ib-Tc; Wed, 09 Jul 2003 12:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHcT-0001ha-Kb for nsis@optimus.ietf.org; Wed, 09 Jul 2003 12:16:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08246 for ; Wed, 9 Jul 2003 12:16:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHcS-0000IP-00 for nsis@ietf.org; Wed, 09 Jul 2003 12:16:36 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19aHcR-0000IJ-00 for nsis@ietf.org; Wed, 09 Jul 2003 12:16:35 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2003 09:13:56 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h69GG17F016820; Wed, 9 Jul 2003 09:16:01 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJI08855; Wed, 9 Jul 2003 09:15:58 -0700 (PDT) Message-Id: <200307091615.AJI08855@mira-sjc5-c.cisco.com> To: Tschofenig Hannes cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] authorization In-Reply-To: Message from hannes.tschofenig@siemens.com of "Wed, 09 Jul 2003 17:23:56 +0200." <2A8DB02E3018D411901B009027FD3A3F03BBFFBB@mchp905a.mch.sbs.de> Date: Wed, 09 Jul 2003 12:15:58 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > do you think that the authorization decision along (together possible with > entity authentication) is sufficient i.e. that there is no need for > signaling message protection? I think that if you asked me today (which you did), I wouldn't do any authorization at the NTLP layer. I'm not sure if it's meaningful. It seems to me that the questions that would be asked are either "may I send you a packet?" and/or "may I send you an NSLP payload?," neither of which, I think, would be or even could be properly answered by NTLP. It wouldn't be very difficult to convince me to change my mind on this, but right now it seems that it's the wrong question for NTLP. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 14:57:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14485 for ; Wed, 9 Jul 2003 14:57:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aK7l-0003ja-4Z for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 14:57:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Iv5eX014350 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 14:57:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aK7g-0003jB-IN; Wed, 09 Jul 2003 14:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aK77-0003W8-5a for nsis@optimus.ietf.org; Wed, 09 Jul 2003 14:56:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14429 for ; Wed, 9 Jul 2003 14:56:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aK74-0001uF-00 for nsis@ietf.org; Wed, 09 Jul 2003 14:56:22 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19aK71-0001u5-00 for nsis@ietf.org; Wed, 09 Jul 2003 14:56:19 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h69Iu8kM011997; Wed, 9 Jul 2003 14:56:08 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h69Iu7N27911; Wed, 9 Jul 2003 14:56:07 -0400 Message-ID: <3F0C6454.1010401@cs.columbia.edu> Date: Wed, 09 Jul 2003 14:52:04 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas CC: nsis@ietf.org Subject: Re: [NSIS] Short Review of draft-shore-ntlp-00.txt References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB52E@G8PQD.blf01.telekom.de> <16139.569.394014.312229@thomasm-u1.cisco.com> <3F0B0361.5090306@cs.columbia.edu> <16139.14340.907062.374071@thomasm-u1.cisco.com> In-Reply-To: <16139.14340.907062.374071@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I would agree that spending a lot of time on NTLP-specific security may not be time well spent. Indicating the re-use of existing mechanisms is probably not much effort where that is feasible; part of the reason SIP ended up spending lots of time on this because there was a mandatory-to-implement decision tied in with that, which tends to get people excited. Michael Thomas wrote: > At first I thought there was merit to the > "QoS-specific" rap, but as I re-read it, I'm not > sure that what I wrote is especially related to > QoS. It's always true that there may be situations > where you want confidentiality, key mgmt, etc in > hop-by-hop, but it's really more of a question of > prioritization and effort. That is, how worth is > it to get this more "correct" for NSIS than it is > for RSVP? SIP had pretty good motivation, not the > least of which was the possiblity of transporting > SRTP keys, but the UA/proxy architecture as the > norm makes a pretty compelling argument as well. > > The question, really, is whether NSIS applications > are more SIP-like or AAA-like in their > authorization and delegation. I'm not a huge AAA > fan, but I think it's unarguably the case that > people like that model, and there's tons of > deployment. Indeed, there's been plenty of noise > even in SIP land to integrate with legacy AAA too. > I tend to think that that lure will persist if not > strengthen with NSIS, especially as policy becomes > more complicated. > > So if I had to choose whether to put a bunch of > effort making hop-by-hop auth/conf/authz better or > hop-to-decision-maker architectures better, I'd > choose the later. Maybe we have to do both, but I > for one am not eager reopen the same debate with > NSIS as was, IMO, unsatisfactorily resolved in > SIP. There seems like there are better things to > worry about. > > Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 15:23:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16853 for ; Wed, 9 Jul 2003 15:23:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKWr-0005UU-Ot for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 15:23:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69JN1tG021099 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 15:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKWr-0005UD-L1; Wed, 09 Jul 2003 15:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKWl-0005Tw-83 for nsis@optimus.ietf.org; Wed, 09 Jul 2003 15:22:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16837 for ; Wed, 9 Jul 2003 15:22:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKWk-0002Dx-00 for nsis@ietf.org; Wed, 09 Jul 2003 15:22:54 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19aKWj-0002Du-00 for nsis@ietf.org; Wed, 09 Jul 2003 15:22:53 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h69JMqkM014750; Wed, 9 Jul 2003 15:22:52 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h69JMqN30721; Wed, 9 Jul 2003 15:22:52 -0400 Message-ID: <3F0C6A98.1020606@cs.columbia.edu> Date: Wed, 09 Jul 2003 15:18:48 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] Short Review of draft-schulzrinne-nsis-ntlp-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > > That is good - I was a bit worried about an active discovery mechanism > that would/could search for off-path nodes, as that is clearly out of > scope for the WG: The active discovery mechanism specified or envisioned does not stray off-path. (The modularity may enable other mechanisms, including off-path, but that's hopefully not a drawback :-)) > Perhaps that is the source of my concern - there seems not to be > enough consideration on bounding this aspect. More detail is a good > think. My philosophy is that implementors should be given choices here (without impairing interoperability), since there's an inherent time/space trade-off, with the minimum state being a reasonable one. If that's not ok, please let me know. >>Yes, roughly. To put the motivation very sloppily: have NTLP handle the >>easy transport, punt to a professional transport protocol for the hard >>cases. Easy = short messages sent infrequently to new destinations with >>relaxed reliability, so that fragmentation, RTT estimation, >>less-than-N-RTT loss detection, flow control and congestion control are >>largely somebody else's problem. > > > For example, 2961 has a lot of complexity - one may argue that not all of > the features of 2961 are actually needed for NSIS. However, rolling > your own mechanisms in NTLP do accomplish some of what 2961 may be > difficult. The intent is to have only the most basic mechanism from 2961 (hop-by-hop exponential backoff retransmission) and leave everything else as a "hard case". I'm not sure if your statement is agreeing with mine, but I have no intent of re-inventing 2961. I don't think the subset mentioned is difficult, at least based on our implementation experience (one additional timer per pending session) and that of other bare-bones transport mechanisms (DNS, SLP, RADIUS, etc.) that do roughly the same thing. Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 9 23:25:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03630 for ; Wed, 9 Jul 2003 23:25:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aS3K-0006rF-LP for nsis-archive@odin.ietf.org; Wed, 09 Jul 2003 23:25:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A3P2PE026344 for nsis-archive@odin.ietf.org; Wed, 9 Jul 2003 23:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aS3J-0006qn-2G; Wed, 09 Jul 2003 23:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aS2U-0006os-8I for nsis@optimus.ietf.org; Wed, 09 Jul 2003 23:24:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03607 for ; Wed, 9 Jul 2003 23:24:07 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aS2S-0006VY-00 for nsis@ietf.org; Wed, 09 Jul 2003 23:24:08 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19aS2R-0006VV-00 for nsis@ietf.org; Wed, 09 Jul 2003 23:24:07 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6A3O6k28513 for ; Thu, 10 Jul 2003 06:24:06 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Jul 2003 06:24:06 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 06:24:05 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 06:24:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] authorization Date: Thu, 10 Jul 2003 06:24:04 +0300 Message-ID: Thread-Topic: [NSIS] authorization Thread-Index: AcNGNzOgsnzk3Ci6QUOLNM9fwjxSjwAW15YQ To: , Cc: X-OriginalArrivalTime: 10 Jul 2003 03:24:05.0772 (UTC) FILETIME=[B7B444C0:01C34692] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Melinda, > I think that if you asked me today (which you did), I > wouldn't do any authorization at the NTLP layer. I'm not > sure if it's meaningful. It seems to me that the questions > that would be asked are either "may I send you a packet?" > and/or "may I send you an NSLP payload?," neither of which, > I think, would be or even could be properly answered by > NTLP. It wouldn't be very difficult to convince me to > change my mind on this, but right now it seems that it's the > wrong question for NTLP. That makes sense, for example, for AAA services, the transport protocol is not authorized; it is the AAA protocol (RADIUS, Diameter) where the authorization takes place. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 00:57:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05513 for ; Thu, 10 Jul 2003 00:57:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aTUN-0003X6-2m for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 00:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A4v3qt013574 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 00:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aTUL-0003Wp-6K; Thu, 10 Jul 2003 00:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aTUG-0003WX-Ia for nsis@optimus.ietf.org; Thu, 10 Jul 2003 00:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05503 for ; Thu, 10 Jul 2003 00:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aTUD-00072r-00 for nsis@ietf.org; Thu, 10 Jul 2003 00:56:53 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19aTUC-00072n-00 for nsis@ietf.org; Thu, 10 Jul 2003 00:56:53 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6A4ujOa008255 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Jul 2003 00:56:48 -0400 (EDT) From: "Charles Q. Shen" To: "'Xiaoming Fu'" , Subject: RE: [NSIS] Proposed draft "Mobility Support in NSIS" Date: Thu, 10 Jul 2003 00:56:40 -0400 Organization: Columbia University Message-ID: <000201c3469f$a9b2af30$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <3F0C246B.7060903@cs.uni-goettingen.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Xiaoming, > ...(snip) > > > >>Since the places where a route change takes > >>place after a handoff differ, we have to coordinate these > events (see > >>some discussions in our I-D). > > > > > > Not crystally clear about what you mean in this senstence, > appreciate > > it if you could elaborate. > > Meant "several nodes (such MN, HA and/or FA, possibly ARs in FMIP/CTP > case) will have to change the routing entries for the data > forwarding of > flows sent to or received by the MN. As these events happen > subsequently, one has to take care of a reasonable sequence of NSIS > signaling process which will also go along these nodes." Some of such > situations are discussed in issue 7 and section 4.1 of the I-D. > Ok, so you are talking about the Synchronization/out of sequence problem. Usually it is solved by some kind of messages ID/sequence number (e.g., in related routing protocol updates, RSVP refreshes, and our RSVP-MIP test-bed). I am not very sure what is the difference between the Branch ID you mentioned in your draft from the message ID approach. Cheers/Charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 03:48:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21503 for ; Thu, 10 Jul 2003 03:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aW9r-00085N-6B for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 03:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A7m38I031074 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 03:48:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aW9p-000855-RW; Thu, 10 Jul 2003 03:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aW9d-00084l-Du for nsis@optimus.ietf.org; Thu, 10 Jul 2003 03:47:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21490 for ; Thu, 10 Jul 2003 03:47:45 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aW9a-0000JL-00 for nsis@ietf.org; Thu, 10 Jul 2003 03:47:46 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19aW9Z-0000JI-00 for nsis@ietf.org; Thu, 10 Jul 2003 03:47:46 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6A7lja20573 for ; Thu, 10 Jul 2003 10:47:45 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Jul 2003 10:47:42 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 10:47:43 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 10:47:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Short Review of draft-schulzrinne-nsis-ntlp-00 Date: Thu, 10 Jul 2003 10:47:43 +0300 Message-ID: Thread-Topic: [NSIS] Short Review of draft-schulzrinne-nsis-ntlp-00 Thread-Index: AcNGUDW02YihAjiZR0OcHMrCP1TFPAAZwbRg To: Cc: X-OriginalArrivalTime: 10 Jul 2003 07:47:43.0524 (UTC) FILETIME=[8BD1AE40:01C346B7] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Henning, > > That is good - I was a bit worried about an active discovery = mechanism > > that would/could search for off-path nodes, as that is clearly out = of > > scope for the WG: >=20 > The active discovery mechanism specified or envisioned does not stray=20 > off-path. (The modularity may enable other mechanisms, including=20 > off-path, but that's hopefully not a drawback :-)) Off-path is for future study, so it is not a drawback ... > > Perhaps that is the source of my concern - there seems not to be > > enough consideration on bounding this aspect. More detail is a good > > think. >=20 > My philosophy is that implementors should be given choices here = (without=20 > impairing interoperability), since there's an inherent time/space=20 > trade-off, with the minimum state being a reasonable one. If that's = not=20 > ok, please let me know. I think certain bounding of the problem needs to be captured, if nothing = else than for guidelines for implementors. > > For example, 2961 has a lot of complexity - one may argue that not = all of > > the features of 2961 are actually needed for NSIS. However, rolling > > your own mechanisms in NTLP do accomplish some of what 2961 may be > > difficult. >=20 > The intent is to have only the most basic mechanism from 2961=20 > (hop-by-hop exponential backoff retransmission) and leave everything=20 > else as a "hard case". I'm not sure if your statement is agreeing with = > mine, but I have no intent of re-inventing 2961.=20 I am agree agreeing. > I don't think the=20 > subset mentioned is difficult, at least based on our implementation=20 > experience (one additional timer per pending session) and that of = other=20 > bare-bones transport mechanisms (DNS, SLP, RADIUS, etc.) that=20 > do roughly the same thing. I think that we just need to be a bit more explicit, that is all. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 04:02:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21806 for ; Thu, 10 Jul 2003 04:02:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWNR-0000GQ-BF for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 04:02:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A8250V000997 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 04:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWNO-0000FI-St; Thu, 10 Jul 2003 04:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWMp-0000EG-Aq for nsis@optimus.ietf.org; Thu, 10 Jul 2003 04:01:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21772 for ; Thu, 10 Jul 2003 04:01:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aWMm-0000Mj-00 for nsis@ietf.org; Thu, 10 Jul 2003 04:01:24 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 19aWMl-0000Mg-00 for nsis@ietf.org; Thu, 10 Jul 2003 04:01:23 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h6A81MN15528; Thu, 10 Jul 2003 10:01:23 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h6A81M020444; Thu, 10 Jul 2003 10:01:22 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <3D8BMWHM>; Thu, 10 Jul 2003 10:01:21 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFFBE@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Melinda Shore'" Cc: nsis@ietf.org Subject: RE: [NSIS] authorization Date: Thu, 10 Jul 2003 10:01:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi melinda, i guess i misunderstood you. there are actually different places along the end to end path which experience different protection (see Figure 2 of [threats]). we can discuss this issue in more detail next week. however, i see you have already strong opinion. i will take a look at the existing ntlp proposals in more detail to provide you (and others) with more details. (btw, at which layer message protection takes place is actually not the difficult part - its the key management - and for some nslps authorization). as you know we have also explored the "protect messages at the nslp layer" part with draft-tschofenig-rsvp-doi-00.txt. ciao hannes > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, July 09, 2003 6:16 PM > To: Tschofenig Hannes > Cc: nsis@ietf.org > Subject: Re: [NSIS] authorization > > > > do you think that the authorization decision along > (together possible with > > entity authentication) is sufficient i.e. that there is no need for > > signaling message protection? > > I think that if you asked me today (which you did), I > wouldn't do any authorization at the NTLP layer. I'm not > sure if it's meaningful. It seems to me that the questions > that would be asked are either "may I send you a packet?" > and/or "may I send you an NSLP payload?," neither of which, > I think, would be or even could be properly answered by > NTLP. It wouldn't be very difficult to convince me to > change my mind on this, but right now it seems that it's the > wrong question for NTLP. > > Melinda > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 04:21:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22124 for ; Thu, 10 Jul 2003 04:21:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWfo-0001rI-B9 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 04:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A8L4P2007115 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 04:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWfl-0001qd-6Q; Thu, 10 Jul 2003 04:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWfY-0001py-Hf for nsis@optimus.ietf.org; Thu, 10 Jul 2003 04:20:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22112 for ; Thu, 10 Jul 2003 04:20:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aWfV-0000TX-00 for nsis@ietf.org; Thu, 10 Jul 2003 04:20:45 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 19aWfU-0000TU-00 for nsis@ietf.org; Thu, 10 Jul 2003 04:20:44 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h6A8KgN02702; Thu, 10 Jul 2003 10:20:43 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h6A8Kg011276; Thu, 10 Jul 2003 10:20:42 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <3D8BMW8N>; Thu, 10 Jul 2003 10:20:41 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFFBF@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'john.loughney@nokia.com'" , mshore@cisco.com Cc: nsis@ietf.org Subject: RE: [NSIS] authorization Date: Thu, 10 Jul 2003 10:20:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi john, i somehow got lost in this discussion. what is the question that should be answered? - is it about at which layer signaling message protection should take place? - is it about authorization? if so then we have to further differentiate between different messages and different locations along the end to end path. i also have to agree that certain authorization decisions make only sense at the nslp (and at a particular context). ciao hannes btw, the aaa context could be somewhat misleading here since the aaa protocol runs between the aaa server and the attendant whereas the nsis part would be between the client and the attendant. that's also the reason why the nsis working group does not really deal with aaa protocols or extensions. an nsis protocol therefore only serves as a "information provider" for a subsequent aaa interaction (as proposed in the past already). > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, July 10, 2003 5:24 AM > To: mshore@cisco.com; Tschofenig Hannes > Cc: nsis@ietf.org > Subject: RE: [NSIS] authorization > > > Hi Melinda, > > > I think that if you asked me today (which you did), I > > wouldn't do any authorization at the NTLP layer. I'm not > > sure if it's meaningful. It seems to me that the questions > > that would be asked are either "may I send you a packet?" > > and/or "may I send you an NSLP payload?," neither of which, > > I think, would be or even could be properly answered by > > NTLP. It wouldn't be very difficult to convince me to > > change my mind on this, but right now it seems that it's the > > wrong question for NTLP. > > That makes sense, for example, for AAA services, the transport > protocol is not authorized; it is the AAA protocol (RADIUS, > Diameter) where the authorization takes place. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 04:24:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22242 for ; Thu, 10 Jul 2003 04:24:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWif-0001x0-Tb for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 04:24:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A8O1ZO007492 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 04:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWif-0001wk-LX; Thu, 10 Jul 2003 04:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWiG-0001wU-Hs for nsis@optimus.ietf.org; Thu, 10 Jul 2003 04:23:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22213 for ; Thu, 10 Jul 2003 04:23:32 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aWiD-0000Uv-00 for nsis@ietf.org; Thu, 10 Jul 2003 04:23:33 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19aWiC-0000Us-00 for nsis@ietf.org; Thu, 10 Jul 2003 04:23:32 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6A8NWa26952 for ; Thu, 10 Jul 2003 11:23:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Jul 2003 11:23:21 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 11:23:21 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 11:23:21 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 11:23:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] authorization Date: Thu, 10 Jul 2003 11:23:18 +0300 Message-ID: Thread-Topic: [NSIS] authorization Thread-Index: AcNGvC+kypy6Ci1tR6mph4kKZJapMQAAA/Fw To: , Cc: X-OriginalArrivalTime: 10 Jul 2003 08:23:20.0780 (UTC) FILETIME=[85B910C0:01C346BC] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Hannes, What I think we need to discuss & decide upon are the following: 1) Security & robustness to DoS attacks at both the NTLP & NSLP layers. 2) Authentication & Authorization issues for services. =20 My gut feeling is that the AA issues would be most appropriate to handle at the NSLP layer. Does this make sense? John > -----Original Message----- > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: 10 July, 2003 11:21 > To: Loughney John (NRC/Helsinki); mshore@cisco.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] authorization=20 >=20 >=20 > hi john,=20 >=20 > i somehow got lost in this discussion.=20 >=20 > what is the question that should be answered?=20 >=20 > - is it about at which layer signaling message protection=20 > should take place? >=20 >=20 > - is it about authorization? > if so then we have to further differentiate between different messages = and > different locations along the end to end path. i also have to agree = that > certain authorization decisions make only sense at the nslp (and at a > particular context).=20 >=20 > ciao > hannes >=20 > btw, the aaa context could be somewhat misleading here since the aaa > protocol runs between the aaa server and the attendant whereas the = nsis part > would be between the client and the attendant. > that's also the reason why the nsis working group does not really deal = with > aaa protocols or extensions. an nsis protocol therefore only serves as = a > "information provider" for a subsequent aaa interaction (as proposed = in the > past already). >=20 > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Thursday, July 10, 2003 5:24 AM > > To: mshore@cisco.com; Tschofenig Hannes > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] authorization=20 > >=20 > >=20 > > Hi Melinda, > >=20 > > > I think that if you asked me today (which you did), I > > > wouldn't do any authorization at the NTLP layer. I'm not > > > sure if it's meaningful. It seems to me that the questions > > > that would be asked are either "may I send you a packet?" > > > and/or "may I send you an NSLP payload?," neither of which, > > > I think, would be or even could be properly answered by > > > NTLP. It wouldn't be very difficult to convince me to > > > change my mind on this, but right now it seems that it's the > > > wrong question for NTLP. > >=20 > > That makes sense, for example, for AAA services, the transport > > protocol is not authorized; it is the AAA protocol (RADIUS, > > Diameter) where the authorization takes place. > >=20 > > John > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 04:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22441 for ; Thu, 10 Jul 2003 04:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWsN-0002Ur-6v for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 04:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A8Y3XO009561 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 04:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWsL-0002Tv-9o; Thu, 10 Jul 2003 04:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWri-0002TP-OU for nsis@optimus.ietf.org; Thu, 10 Jul 2003 04:33:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22421 for ; Thu, 10 Jul 2003 04:33:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aWrf-0000Yo-00 for nsis@ietf.org; Thu, 10 Jul 2003 04:33:19 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 19aWre-0000Yk-00 for nsis@ietf.org; Thu, 10 Jul 2003 04:33:18 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h6A8XIN14078; Thu, 10 Jul 2003 10:33:18 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h6A8XI024827; Thu, 10 Jul 2003 10:33:18 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <3D8BMXKM>; Thu, 10 Jul 2003 10:33:17 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFFC3@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'john.loughney@nokia.com'" , mshore@cisco.com Cc: nsis@ietf.org Subject: RE: [NSIS] authorization Date: Thu, 10 Jul 2003 10:33:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi john, that adds some light to our discussion. > Hi Hannes, > > What I think we need to discuss & decide upon are the following: > > 1) Security & robustness to DoS attacks at both the NTLP & > NSLP layers. > 2) Authentication & Authorization issues for services. that's goes along with my observation. > My gut feeling is that the AA issues would be most > appropriate to handle > at the NSLP layer. some of the question we raised with NSIS AAA (draft-tschofenig-nsis-aaa-issues-01.txt) and with QoS NSLP Authorization Issues (draft-tschofenig-nsis-qos-authz-issues-00.txt) address this issue. it is certainly necessary to get some conclusion since it has an impact on the nslp protocol design. for the nat/firewall handling other authorization decisions are important as described in draft-brunner-nsis-midcom-ps-00.txt small note: authorization does not necessarily need to be combined with authentication (and also not necessarily at the same layer). > > Does this make sense? yes. ciao hannes > John > > > -----Original Message----- > > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: 10 July, 2003 11:21 > > To: Loughney John (NRC/Helsinki); mshore@cisco.com > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] authorization > > > > > > hi john, > > > > i somehow got lost in this discussion. > > > > what is the question that should be answered? > > > > - is it about at which layer signaling message protection > > should take place? > > > > > > - is it about authorization? > > if so then we have to further differentiate between > different messages and > > different locations along the end to end path. i also have > to agree that > > certain authorization decisions make only sense at the nslp > (and at a > > particular context). > > > > ciao > > hannes > > > > btw, the aaa context could be somewhat misleading here since the aaa > > protocol runs between the aaa server and the attendant > whereas the nsis part > > would be between the client and the attendant. > > that's also the reason why the nsis working group does not > really deal with > > aaa protocols or extensions. an nsis protocol therefore > only serves as a > > "information provider" for a subsequent aaa interaction (as > proposed in the > > past already). > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: Thursday, July 10, 2003 5:24 AM > > > To: mshore@cisco.com; Tschofenig Hannes > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] authorization > > > > > > > > > Hi Melinda, > > > > > > > I think that if you asked me today (which you did), I > > > > wouldn't do any authorization at the NTLP layer. I'm not > > > > sure if it's meaningful. It seems to me that the questions > > > > that would be asked are either "may I send you a packet?" > > > > and/or "may I send you an NSLP payload?," neither of which, > > > > I think, would be or even could be properly answered by > > > > NTLP. It wouldn't be very difficult to convince me to > > > > change my mind on this, but right now it seems that it's the > > > > wrong question for NTLP. > > > > > > That makes sense, for example, for AAA services, the transport > > > protocol is not authorized; it is the AAA protocol (RADIUS, > > > Diameter) where the authorization takes place. > > > > > > John > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 04:46:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22823 for ; Thu, 10 Jul 2003 04:46:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aX3w-0003oR-B0 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 04:46:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A8k0lN014654 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 04:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aX3v-0003oF-Sp; Thu, 10 Jul 2003 04:45:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aX2y-0003nF-UF for nsis@optimus.ietf.org; Thu, 10 Jul 2003 04:45:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22801 for ; Thu, 10 Jul 2003 04:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aX2v-0000ed-00 for nsis@ietf.org; Thu, 10 Jul 2003 04:44:57 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19aX2u-0000ea-00 for nsis@ietf.org; Thu, 10 Jul 2003 04:44:56 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h6A8iuv11449; Thu, 10 Jul 2003 10:44:56 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h6A8it007683; Thu, 10 Jul 2003 10:44:55 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <3D8BMXYX>; Thu, 10 Jul 2003 10:44:54 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFFC5@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Tschofenig Hannes , "'john.loughney@nokia.com'" , mshore@cisco.com Cc: nsis@ietf.org Subject: RE: [NSIS] authorization Date: Thu, 10 Jul 2003 10:44:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi i should mention that we should not only focus on the first/last peer communication (we we actually have a user). there this classical authentication, authorization (+ key exchange) example is found. authorization within other places (such as inter-domain, intra-domain, etc.) looks different and does not require a aaa infrastructure. there are certainly different security requirements between these parts in the end-to-end signaling path. ciao hannes > -----Original Message----- > From: Tschofenig Hannes > Sent: Thursday, July 10, 2003 10:33 AM > To: 'john.loughney@nokia.com'; mshore@cisco.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] authorization > > > hi john, > > that adds some light to our discussion. > > > Hi Hannes, > > > > What I think we need to discuss & decide upon are the following: > > > > 1) Security & robustness to DoS attacks at both the NTLP & > > NSLP layers. > > 2) Authentication & Authorization issues for services. > > that's goes along with my observation. > > > My gut feeling is that the AA issues would be most > > appropriate to handle > > at the NSLP layer. > > some of the question we raised with NSIS AAA > (draft-tschofenig-nsis-aaa-issues-01.txt) and with QoS NSLP > Authorization > Issues (draft-tschofenig-nsis-qos-authz-issues-00.txt) > address this issue. > it is certainly necessary to get some conclusion since it has > an impact on > the nslp protocol design. for the nat/firewall handling other > authorization > decisions are important as described in > draft-brunner-nsis-midcom-ps-00.txt > > small note: authorization does not necessarily need to be > combined with > authentication (and also not necessarily at the same layer). > > > > > Does this make sense? > yes. > > ciao > hannes > > > John > > > > > -----Original Message----- > > > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > > Sent: 10 July, 2003 11:21 > > > To: Loughney John (NRC/Helsinki); mshore@cisco.com > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] authorization > > > > > > > > > hi john, > > > > > > i somehow got lost in this discussion. > > > > > > what is the question that should be answered? > > > > > > - is it about at which layer signaling message protection > > > should take place? > > > > > > > > > - is it about authorization? > > > if so then we have to further differentiate between > > different messages and > > > different locations along the end to end path. i also have > > to agree that > > > certain authorization decisions make only sense at the nslp > > (and at a > > > particular context). > > > > > > ciao > > > hannes > > > > > > btw, the aaa context could be somewhat misleading here > since the aaa > > > protocol runs between the aaa server and the attendant > > whereas the nsis part > > > would be between the client and the attendant. > > > that's also the reason why the nsis working group does not > > really deal with > > > aaa protocols or extensions. an nsis protocol therefore > > only serves as a > > > "information provider" for a subsequent aaa interaction (as > > proposed in the > > > past already). > > > > > > > -----Original Message----- > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > Sent: Thursday, July 10, 2003 5:24 AM > > > > To: mshore@cisco.com; Tschofenig Hannes > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] authorization > > > > > > > > > > > > Hi Melinda, > > > > > > > > > I think that if you asked me today (which you did), I > > > > > wouldn't do any authorization at the NTLP layer. I'm not > > > > > sure if it's meaningful. It seems to me that the questions > > > > > that would be asked are either "may I send you a packet?" > > > > > and/or "may I send you an NSLP payload?," neither of which, > > > > > I think, would be or even could be properly answered by > > > > > NTLP. It wouldn't be very difficult to convince me to > > > > > change my mind on this, but right now it seems that it's the > > > > > wrong question for NTLP. > > > > > > > > That makes sense, for example, for AAA services, the transport > > > > protocol is not authorized; it is the AAA protocol (RADIUS, > > > > Diameter) where the authorization takes place. > > > > > > > > John > > > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 05:51:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24306 for ; Thu, 10 Jul 2003 05:51:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aY4t-00080U-Aq for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 05:51:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A9p33k030772 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 05:51:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aY4s-0007zo-4c; Thu, 10 Jul 2003 05:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aY4N-0007z4-Im for nsis@optimus.ietf.org; Thu, 10 Jul 2003 05:50:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24289 for ; Thu, 10 Jul 2003 05:50:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aY4J-00014J-00 for nsis@ietf.org; Thu, 10 Jul 2003 05:50:27 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19aY4J-000144-00 for nsis@ietf.org; Thu, 10 Jul 2003 05:50:27 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSK1JJZ>; Thu, 10 Jul 2003 10:49:53 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Date: Thu, 10 Jul 2003 10:49:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments on NTLP design proposals Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear All, I have some questions & observations about how we are proceeding with the NTLP design process. (Most of them have been stimulated in fact by reading Melinda's draft-shore-..., but the one I consider most important/interesting is actually pretty general, and I've put it at the start.) I have been out of the office for a few days and am not fully up to date with the recent mailing list discussions, so apologies in advance if any of what follows is redundant with that. 1. The single most important issue seems to me to be how the 'core' transport functions should be provided. I can see (at least) 4 options - a) take existing protocol components straight out of 2205+2961, re-arrange them in the NSIS layer model, and add pieces for additional functionality needed. b) do (a) but starting from a clean sheet, i.e. a new 'path coupled transport protocol'. c) build the NTLP out of an existing transport protocol, and live with a separated signalling transport and route discovery process. d) do (c) but trying to keep the ability to have unified transport and route discovery (like PATH does today). It may be that (b) is ruled out by the terms of John's 'Starting NTLP Work' slide from San Francisco, but I can't see that the others are. I feel that we need to bottom out this question before really getting into the details of protocol design (message formats and so on), since the 'shape' of the protocol depends so strongly on it. Just for the record, let me say that I can see the attraction of (a) in terms of providing a conceptual starting point. However, I have a suspicion that extra functionality - fragmentation, better congestion control, protection against denial-of-service attacks, pmtu discovery, and so on - will be hard for us to design and hard to build into the protocol in a nice way. (Another side effect of approach (a) might well be that the NTLP inherits functionality which was natural in 2961 - like message summarisation, awareness of signalling application state - which shouldn't logically be there.) On the other hand, I am not blind to the issues with (c), mainly the need for a separate discovery procedure. I suspect it's impossible to provide a proof (which satisfies everyone) that this doesn't matter. So, maybe (d) would be nice. Unfortunately, I think (d) is impossible using a fully reliable transport; however, I'm now pretty (90%) sure that something sensible can be done by re-using DCCP, and selectively layering reliability on top (where needed). (You could also use a different congestion response, like TFRC, which might be nice. In fact, DCCP seems to have *lots* of nice features...) 2. In earlier days of the WG, we were careful to consider the problems of signalling going through clouds which were not pure IP DA routed (see also recent discussion on this list about Allison's comments on the requirements). So, I'm nervous about protocol designs which assume that the IP DA fully defines the route taken by a flow (i.e. this is all you need in the PATH-like message). [Even RSVP uses both the flow SA and DA in PATH messages.] In fact, we have up to now had an object in the framework (the flow id, maybe a better name would be 'flow routing information') which supposedly exposed at the NTLP level all the information needed to work out where to send a signalling packet. In addition, this object could be processed at an NTLP-aware NAT to provide a traversal service for most signalling applications. I'd be interested to know if people think this should actually be reflected in NTLP design (or, if they think it is just a terminally silly idea - in which case I can take it out of the framework as well). 3. Just for the avoidance of confusion, the NSIS framework as currently defined has no concept of message identifiers (global or local), regarding them as purely internal. The thing it calls the session id (possibly referred to as flow-id in the Shore draft) identifies an application layer session. See you in Vienna, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 06:53:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26242 for ; Thu, 10 Jul 2003 06:53:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aZ2u-00048y-Oc for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 06:53:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AAr4sE015914 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 06:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aZ2r-000484-9t; Thu, 10 Jul 2003 06:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aZ2B-00041S-2X for nsis@optimus.ietf.org; Thu, 10 Jul 2003 06:52:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26203 for ; Thu, 10 Jul 2003 06:52:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aZ26-0001bk-00 for nsis@ietf.org; Thu, 10 Jul 2003 06:52:14 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19aZ25-0001bU-00 for nsis@ietf.org; Thu, 10 Jul 2003 06:52:14 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 10 Jul 2003 12:51:42 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <3NTLKTQD>; Thu, 10 Jul 2003 12:51:39 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB536@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] authorization Date: Thu, 10 Jul 2003 12:51:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable John, |What I think we need to discuss & decide upon are the following: | |1) Security & robustness to DoS attacks at both the NTLP & NSLP = layers. Agreed. Addition: NTLP must not enable new types of DoS attacks. |2) Authentication & Authorization issues for services. =20 | |My gut feeling is that the AA issues would be most appropriate=20 |to handle at the NSLP layer. I'd prefer to have some lightweight authentication at NTLP. A message=20 digest based on a shared secret would be nice. That's why I think=20 discovery and "keep alive" of upstream and downstream NTLP=20 adjacencies is important.=20 Route changes are an issue with this. But I'd rather try to solve=20 the latter than drop the former. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 07:08:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26542 for ; Thu, 10 Jul 2003 07:08:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aZHO-0004v4-4C for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 07:08:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AB82NZ018905 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 07:08:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aZHO-0004up-0P; Thu, 10 Jul 2003 07:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aZHL-0004uM-Nd for nsis@optimus.ietf.org; Thu, 10 Jul 2003 07:07:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26536 for ; Thu, 10 Jul 2003 07:07:53 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aZHH-0001hI-00 for nsis@ietf.org; Thu, 10 Jul 2003 07:07:55 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19aZHG-0001hF-00 for nsis@ietf.org; Thu, 10 Jul 2003 07:07:54 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6AB7sk03357 for ; Thu, 10 Jul 2003 14:07:54 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Jul 2003 14:07:54 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 14:07:53 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 14:07:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] comments on NTLP design proposals Date: Thu, 10 Jul 2003 14:07:52 +0300 Message-ID: Thread-Topic: [NSIS] comments on NTLP design proposals Thread-Index: AcNGyNBZuXb3xm+TSnOIcsloJbtTigACYZZw To: , X-OriginalArrivalTime: 10 Jul 2003 11:07:53.0313 (UTC) FILETIME=[82360D10:01C346D3] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Robert, Some random thoughts / comments. I've clipped the bits of your mail that I am replying to, complete email is left unmolested. > 1. The single most important issue seems to me to be how the > 'core' transport functions should be provided.=20 Perhaps you should define what you mean by 'core' transport functions. > It may be that (b) is ruled out by the terms of John's 'Starting > NTLP Work' slide from San Francisco, but I can't see that the others > are.=20 (b) is ruled out by our charter. If we want a clean sheet approach, we need to demonstate why something like 2205+2961 is not sufficient for the task at hand. > So, maybe (d) would be nice. Unfortunately, I think (d) is=20 > impossible using a fully reliable transport;=20 Using a fully reliable transport option as a starting point requires=20 proof that reliable transport is needed. I have yet to see good justification that a relaible transport is required. My gut feeling is = that we start with a connectionless protocol and see how & if a = connection-oriented protocol can be supported. John > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 10 July, 2003 12:50 > To: nsis@ietf.org > Subject: [NSIS] comments on NTLP design proposals >=20 >=20 > Dear All, >=20 > I have some questions & observations about how we are proceeding > with the NTLP design process. (Most of them have been stimulated > in fact by reading Melinda's draft-shore-..., but the one I=20 > consider most important/interesting is actually pretty general, > and I've put it at the start.) I have been out of the office for=20 > a few days and am not fully up to date with the recent mailing list > discussions, so apologies in advance if any of what follows is > redundant with that. >=20 > 1. The single most important issue seems to me to be how the > 'core' transport functions should be provided. I can see (at > least) 4 options - > a) take existing protocol components straight out of 2205+2961,=20 > re-arrange them in the NSIS layer model, and add pieces for=20 > additional functionality needed. > b) do (a) but starting from a clean sheet, i.e. a new 'path coupled > transport protocol'. > c) build the NTLP out of an existing transport protocol, and live=20 > with a separated signalling transport and route discovery=20 > process. > d) do (c) but trying to keep the ability to have unified=20 > transport and route discovery (like PATH does today). >=20 > It may be that (b) is ruled out by the terms of John's 'Starting > NTLP Work' slide from San Francisco, but I can't see that the others > are. I feel that we need to bottom out this question before really > getting into the details of protocol design (message formats and > so on), since the 'shape' of the protocol depends so strongly on > it. >=20 > Just for the record, let me say that I can see the attraction of=20 > (a) in terms of providing a conceptual starting point. However, I > have a suspicion that extra functionality - fragmentation,=20 > better congestion control, protection against=20 > denial-of-service attacks, pmtu discovery, > and so on - will be hard for us to design and hard to build into > the protocol in a nice way. (Another side effect of approach (a) > might well be that the NTLP inherits functionality which was=20 > natural in 2961 - like message summarisation, awareness of=20 > signalling application state - which shouldn't logically be there.) >=20 > On the other hand, I am not blind to the issues with (c), mainly > the need for a separate discovery procedure. I suspect it's=20 > impossible to provide a proof (which satisfies everyone) that this > doesn't matter. >=20 > So, maybe (d) would be nice. Unfortunately, I think (d) is=20 > impossible using a fully reliable transport; however, I'm now > pretty (90%) sure that something sensible can be done by > re-using DCCP, and selectively layering reliability on top > (where needed). (You could also use a different congestion response, > like TFRC, which might be nice. In fact, DCCP seems to have *lots* > of nice features...) >=20 > 2. In earlier days of the WG, we were careful to consider the > problems of signalling going through clouds which were not pure > IP DA routed (see also recent discussion on this list about > Allison's comments on the requirements). So, I'm nervous about > protocol designs which assume that the IP DA fully defines the > route taken by a flow (i.e. this is all you need in the PATH-like > message). [Even RSVP uses both the flow SA and DA in PATH messages.] >=20 > In fact, we have up to now had an object in the framework (the > flow id, maybe a better name would be 'flow routing information') > which supposedly exposed at the NTLP level all the information=20 > needed to work out where to send a signalling packet. In addition, > this object could be processed at an NTLP-aware NAT to provide > a traversal service for most signalling applications. I'd be=20 > interested to know if people think this should actually be reflected > in NTLP design (or, if they think it is just a terminally silly=20 > idea - in which case I can take it out of the framework as well). >=20 > 3. Just for the avoidance of confusion, the NSIS framework as > currently defined has no concept of message identifiers (global > or local), regarding them as purely internal. The thing it calls > the session id (possibly referred to as flow-id in the Shore draft) > identifies an application layer session. >=20 > See you in Vienna, >=20 > Robert H. >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 07:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27142 for ; Thu, 10 Jul 2003 07:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aZec-0006UP-7Z for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 07:32:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ABW2LZ024933 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 07:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aZeb-0006U2-TQ; Thu, 10 Jul 2003 07:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aZeR-0006Tn-EP for nsis@optimus.ietf.org; Thu, 10 Jul 2003 07:31:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27128 for ; Thu, 10 Jul 2003 07:31:48 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aZeQ-0001qn-00 for nsis@ietf.org; Thu, 10 Jul 2003 07:31:50 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19aZeP-0001qk-00 for nsis@ietf.org; Thu, 10 Jul 2003 07:31:49 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6ABVlk24724 for ; Thu, 10 Jul 2003 14:31:47 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Jul 2003 14:31:47 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 14:31:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 14:31:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] authorization Date: Thu, 10 Jul 2003 14:31:44 +0300 Message-ID: Thread-Topic: [NSIS] authorization Thread-Index: AcNG0UGPNCR5KKxHSt6x8YEzTK6TIgABWXcw To: Cc: X-OriginalArrivalTime: 10 Jul 2003 11:31:45.0647 (UTC) FILETIME=[D7F2DFF0:01C346D6] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi R=FCdiger, I think peer authentication of each NTLP hop could be filed under my point (1). I would not want to involve 3rd part authentication though - at least initially - as things might get complicated. John > -----Original Message----- > From: ext Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 10 July, 2003 13:52 > To: Loughney John (NRC/Helsinki) > Cc: nsis@ietf.org > Subject: RE: [NSIS] authorization=20 >=20 >=20 > John, >=20 > |What I think we need to discuss & decide upon are the following: > | > |1) Security & robustness to DoS attacks at both the NTLP &=20 > NSLP layers. >=20 > Agreed. Addition: NTLP must not enable new types of DoS attacks. >=20 > |2) Authentication & Authorization issues for services. =20 > | > |My gut feeling is that the AA issues would be most appropriate=20 > |to handle at the NSLP layer. >=20 > I'd prefer to have some lightweight authentication at NTLP. A message=20 > digest based on a shared secret would be nice. That's why I think=20 > discovery and "keep alive" of upstream and downstream NTLP=20 > adjacencies is important.=20 > Route changes are an issue with this. But I'd rather try to solve=20 > the latter than drop the former. >=20 > Regards, R=FCdiger >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 13:03:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12481 for ; Thu, 10 Jul 2003 13:03:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeou-0002Sd-Jt for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 13:03:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AH30W5009454 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 13:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeou-0002SO-GX; Thu, 10 Jul 2003 13:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeo3-0002Ns-0x for nsis@optimus.ietf.org; Thu, 10 Jul 2003 13:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12428 for ; Thu, 10 Jul 2003 13:02:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aeo1-0005Ds-00 for nsis@ietf.org; Thu, 10 Jul 2003 13:02:05 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19aeo0-0005DP-00 for nsis@ietf.org; Thu, 10 Jul 2003 13:02:04 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6AH1XVI067712 for ; Thu, 10 Jul 2003 19:01:33 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 7BDDB77BDE for ; Thu, 10 Jul 2003 18:43:43 +0200 (CEST) Date: Thu, 10 Jul 2003 19:01:27 +0200 From: Martin Stiemerling To: nsis@ietf.org Subject: Re: [NSIS] Review of "Security Threats for NSIS " Message-ID: <194280000.1057856487@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have read the -02 draft and it looks fine for me. Here some nits: - some more terminology would be good, since all the abbrevations, like SA or MITM, are not necessary good to guess for people that are not deeply involved. - in section 5.5 RFC3812 is referenced, but actually it is 3182 (as in the reference section) - in 5.10: May the 'adversary' use the the same session id not only for security abuse, but as well just by accident? Martin --On Monday, July 07, 2003 15:07:28 +0300 john.loughney@nokia.com wrote: | Hi all, | | In preparing for IETF 57, I am trying to make a quick review of many of | the documents under discussion. | | http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-02.txt | | | Overall, I think this document is quite good & quite ready for WG Last | Call. If noone opposes, I would like to start WG last call on this | document starting Wednesday July 9th and run it for 3 weeks until July | 23rd. | | I am restricting my comments to some more general comments right now. | | 1) Abstract needs improvement. | | Text is: | | This threats document provides a detailed analysis of the | security threats relevant for the NSIS working group. It | motivates and helps to understand various security | considerations in the NSIS Requirements, Framework and Protocol | proposals. This document does not describe vulnerabilities of | specific NSIS protocols. | | Suggested change (feel free to modify accordingly): | | This document provides a detailed analysis of the relevant | security threats for the NSIS working group. It provides | motivatation behind the various security considerations in the NSIS | Requirements and Framework documents. This document is not meant to | describe potential vulnerabilities of specific NSIS protocols, but | provide input into protocol design to ensure security considerations | are well thought out prior to design | | 2) Section 1 | | There probably is not a need to diagram the different NSIS documents, a | bulleted list might be enough. | | 3) Terminology shouldn't be a seperate section, perhaps a sub-section. | Are you sure there is no security-specific terminology that should be | added here? IKE, S/MIME, IPsec, SA probably should be expanded. | | 4) General comment: blank lines between paragraphs are missing in many | places. | | 5) A summary might be a nice touch at the end. | | thanks, | John | | _______________________________________________ | nsis mailing list | nsis@ietf.org | https://www1.ietf.org/mailman/listinfo/nsis Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 10 19:32:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26754 for ; Thu, 10 Jul 2003 19:32:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19akt6-0003Nn-Kc for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 19:31:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ANViXc013003 for nsis-archive@odin.ietf.org; Thu, 10 Jul 2003 19:31:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aksP-0003Ej-Kd; Thu, 10 Jul 2003 19:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19akrg-00034s-MK for nsis@optimus.ietf.org; Thu, 10 Jul 2003 19:30:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26730 for ; Thu, 10 Jul 2003 19:30:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19akrf-0000PE-00 for nsis@ietf.org; Thu, 10 Jul 2003 19:30:15 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19akre-0000Ov-00 for nsis@ietf.org; Thu, 10 Jul 2003 19:30:14 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSK1KBX>; Fri, 11 Jul 2003 00:29:42 +0100 Message-ID: From: "Hancock, Robert" To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] comments on NTLP design proposals Date: Fri, 11 Jul 2003 00:29:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi john, > Some random thoughts / comments. I've clipped the bits of your > mail that I am replying to, complete email is left unmolested. and it is grateful for that... > > > 1. The single most important issue seems to me to be how the > > 'core' transport functions should be provided. > > Perhaps you should define what you mean by 'core' transport functions. i suppose the most objective definition would actually be 'the difficult ones', i.e. ones which are hard to define correctly, but which are already provided in other protocols. head of my list would be congestion control and DoS protection (from initialisation floods). Message number management (including non-cryptographic replay protection) can also be tricky. Fragmentation/reassembly (and the associated PMTU discovery), multiplexing, and (optionally) selective reliability and flow control would probably come into several people's core list; however, I think of them as more just 'nice to be given' since they aren't so hard to design oneself given the other functionality described above - you don't need several decades' worth of experience just to avoid making horrendous errors. (Maybe fragmentation/ reassembly is a borderline case here - it's interesting that the DCCP people left it out.) > > > It may be that (b) is ruled out by the terms of John's 'Starting > > NTLP Work' slide from San Francisco, but I can't see that the others > > are. > > (b) is ruled out by our charter. If we want a clean sheet approach, > we need to demonstate why something like 2205+2961 is not sufficient > for the task at hand. > > > So, maybe (d) would be nice. Unfortunately, I think (d) is > > impossible using a fully reliable transport; > > Using a fully reliable transport option as a starting point requires > proof that reliable transport is needed. I have yet to see good > justification that a relaible transport is required. My gut > feeling is that we start with a connectionless protocol and see how & > if a connection-oriented protocol can be supported. Whether or not this is true, it's orthogonal (i.e. irrelevant) to the point I was making: if you want to re-use an existing transport, you probably can't retain having a PATH-like message if you reuse an existing reliable transport (regardless of whether or not you want its reliability properties). But you could re-use an unreliable transport. r. As an aside, what exactly do you mean by 'connectionless' and 'connection-oriented'? Are you using them as synonyms for 'unreliable' and 'reliable'? Or do you mean connectionless as 'holding no per-peer state'? Is 2961 connectionless in your book? (It has selective reliability and manages per-peer state, after all.) > > John > > > > -----Original Message----- > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: 10 July, 2003 12:50 > > To: nsis@ietf.org > > Subject: [NSIS] comments on NTLP design proposals > > > > > > Dear All, > > > > I have some questions & observations about how we are proceeding > > with the NTLP design process. (Most of them have been stimulated > > in fact by reading Melinda's draft-shore-..., but the one I > > consider most important/interesting is actually pretty general, > > and I've put it at the start.) I have been out of the office for > > a few days and am not fully up to date with the recent mailing list > > discussions, so apologies in advance if any of what follows is > > redundant with that. > > > > 1. The single most important issue seems to me to be how the > > 'core' transport functions should be provided. I can see (at > > least) 4 options - > > a) take existing protocol components straight out of 2205+2961, > > re-arrange them in the NSIS layer model, and add pieces for > > additional functionality needed. > > b) do (a) but starting from a clean sheet, i.e. a new 'path coupled > > transport protocol'. > > c) build the NTLP out of an existing transport protocol, and live > > with a separated signalling transport and route discovery > > process. > > d) do (c) but trying to keep the ability to have unified > > transport and route discovery (like PATH does today). > > > > It may be that (b) is ruled out by the terms of John's 'Starting > > NTLP Work' slide from San Francisco, but I can't see that the others > > are. I feel that we need to bottom out this question before really > > getting into the details of protocol design (message formats and > > so on), since the 'shape' of the protocol depends so strongly on > > it. > > > > Just for the record, let me say that I can see the attraction of > > (a) in terms of providing a conceptual starting point. However, I > > have a suspicion that extra functionality - fragmentation, > > better congestion control, protection against > > denial-of-service attacks, pmtu discovery, > > and so on - will be hard for us to design and hard to build into > > the protocol in a nice way. (Another side effect of approach (a) > > might well be that the NTLP inherits functionality which was > > natural in 2961 - like message summarisation, awareness of > > signalling application state - which shouldn't logically be there.) > > > > On the other hand, I am not blind to the issues with (c), mainly > > the need for a separate discovery procedure. I suspect it's > > impossible to provide a proof (which satisfies everyone) that this > > doesn't matter. > > > > So, maybe (d) would be nice. Unfortunately, I think (d) is > > impossible using a fully reliable transport; however, I'm now > > pretty (90%) sure that something sensible can be done by > > re-using DCCP, and selectively layering reliability on top > > (where needed). (You could also use a different congestion response, > > like TFRC, which might be nice. In fact, DCCP seems to have *lots* > > of nice features...) > > > > 2. In earlier days of the WG, we were careful to consider the > > problems of signalling going through clouds which were not pure > > IP DA routed (see also recent discussion on this list about > > Allison's comments on the requirements). So, I'm nervous about > > protocol designs which assume that the IP DA fully defines the > > route taken by a flow (i.e. this is all you need in the PATH-like > > message). [Even RSVP uses both the flow SA and DA in PATH messages.] > > > > In fact, we have up to now had an object in the framework (the > > flow id, maybe a better name would be 'flow routing information') > > which supposedly exposed at the NTLP level all the information > > needed to work out where to send a signalling packet. In addition, > > this object could be processed at an NTLP-aware NAT to provide > > a traversal service for most signalling applications. I'd be > > interested to know if people think this should actually be reflected > > in NTLP design (or, if they think it is just a terminally silly > > idea - in which case I can take it out of the framework as well). > > > > 3. Just for the avoidance of confusion, the NSIS framework as > > currently defined has no concept of message identifiers (global > > or local), regarding them as purely internal. The thing it calls > > the session id (possibly referred to as flow-id in the Shore draft) > > identifies an application layer session. > > > > See you in Vienna, > > > > Robert H. > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 11 04:50:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21457 for ; Fri, 11 Jul 2003 04:50:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atbO-0004qm-9g for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 04:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B8o2TQ018644 for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 04:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atbN-0004qb-QU; Fri, 11 Jul 2003 04:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atbG-0004q1-16 for nsis@optimus.ietf.org; Fri, 11 Jul 2003 04:49:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21420 for ; Fri, 11 Jul 2003 04:49:50 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19atbD-0003jR-00 for nsis@ietf.org; Fri, 11 Jul 2003 04:49:51 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19atbC-0003jN-00 for nsis@ietf.org; Fri, 11 Jul 2003 04:49:50 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6B8nnk09637 for ; Fri, 11 Jul 2003 11:49:49 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Jul 2003 11:49:49 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 11:49:49 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 11:49:48 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 11:49:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jul 2003 11:49:47 +0300 Message-ID: Thread-Topic: Request for a quick review on two NSIS proposals Thread-Index: AcNG1rrNfurepBkpROaudRfuhek5fAAsnynQ To: Cc: X-OriginalArrivalTime: 11 Jul 2003 08:49:48.0252 (UTC) FILETIME=[6257D1C0:01C34789] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Review of NTLP proposals Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I asked Brian Carpenter to look over the NTLP proposals, in preperation for Vienna. Here is is quick review. br, John > I see these as partly complementary and partly competing. Henning > gives more of an overview whereas Melinda gives a first cut at > a detailed spec. The question is whether the requirements implied > by Henning can be met by morphing the details proposed by Melinda, > or whether the distance is too great and you really have two > irreconcilable drafts. I'm not sure about that. I certainly think > Henning is correct to consider using either a reliable transport > or not; everyone who tries to bypass TCP ends up partially > recreating it. There's not the slightest reason Melinda's TLVs > couldn't travel over TCP or SCTP. The killer overhead is likely > to be crypto in any case. >=20 > I think there is scope for combining the two efforts but that > would need the two authors to agree on the implied requirements > and on the point about the transport layer. (I do agree with > Henning that it's a misnomer to call this thing a transport layer. > Better to call it what it is, a session support layer.) >=20 > Now a few specific comments on each draft: >=20 > draft-shore-ntlp >=20 > A classical TLV approach. If we accept the basic parameters of NSIS > this is the "obvious" way to go. (I don't mean to trivialize the work > by writing this, but this is the traditional approach and the details > hardly matter at this level of discussion). >=20 > I'd like to see some specific discussion of NAT-PT traversal=20 > and how it > will work in this scenario and in IPv6-in-IPv4 tunnel scenarios. >=20 > I'm worried by the complete lack of security analysis at a stage when > basics have been set. Without the threat model I have no idea whether > there is a problem. >=20 > How does it work in SCTP or multihoming scenarios when=20 > multiple IP addresses > may be involved? Do we assume that each time the path=20 > changes, NTLP is back to > square one? >=20 > draft-schulzrinne-nsis-ntlp (gimps) >=20 > This is still an abstract protocol description with details=20 > to be worked out. >=20 > > GIMPS can operate over any message or stream-oriented=20 > transport layer,=20 > > including UDP, DCCP, TCP and SCTP. [TBD: support raw IP?]=20 >=20 > I like. This feature is better than draft-shore, but=20 > multihoming should > also be discussed. >=20 > > Proxy support: > > The end systems in a session may not be capable of handling=20 > either the=20 > > signaling transport or the application and may instead rely=20 > on proxies=20 > > to initiate and terminate signaling sessions. >=20 > This is also a good feature, but the absence of NAT considerations is > a major shortfall. >=20 > As with draft-shore, I'd like to see discussion of mixed=20 > IPv4/IPv6 scenarios. >=20 > I'm glad to see the security discussion but very concerned=20 > about the performance > implications of crypto protection on a hop by hop basis. As=20 > for other fields > that need to be examined at every hop, crypto calculations=20 > may simply be > out of the question. >=20 > Brian >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 11 09:43:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29156 for ; Fri, 11 Jul 2003 09:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayAw-0002y3-6H for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 09:43:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BDh2Fa011401 for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 09:43:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayAu-0002xm-Jh; Fri, 11 Jul 2003 09:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayAK-0002xT-Ql for nsis@optimus.ietf.org; Fri, 11 Jul 2003 09:42:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29148 for ; Fri, 11 Jul 2003 09:42:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ayAI-0005lO-00 for nsis@ietf.org; Fri, 11 Jul 2003 09:42:22 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19ayAH-0005lL-00 for nsis@ietf.org; Fri, 11 Jul 2003 09:42:21 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 11 Jul 2003 15:41:43 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <3NTLM335>; Fri, 11 Jul 2003 15:41:43 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB53A@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: [NSIS] making progress on QoS NSLPs Date: Fri, 11 Jul 2003 15:41:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable John, all, after having read draft-buchli-nsis-nslp and = draft-mcdonald-nsis-qos-nslp I asked myself whether we shouldn't draft = QoS-NSLP requirements before we start to work on solutions. If we can = agree to proceed with a QoS NSLP requirements draft, I'd further = appreciate to separate "mandatory" and "nice to have" features. Some impressions I've collected: draft-buchli-nsis-nslp is rather general and leaves open many questions = (security and aggregation, to name two). draft-mcdonald-nsis-qos-nslp suggests a flexible (and complex) generic = qos signaling protocol. It contains information on security (relation = to the remainder of the document is not clear) and aggregation = (suggests e.g. IP in IP tunnels, if I got that correctly). It supports = options like service & resource negotiation and service mapping. I'd = prefer to see some application developer/ISP demand for these before = they get part of a protocol. This is not to say that I'd object to a = protocol which may be extended to support them. I'm currently not looking for a detailed discussion on either document. = I'm aware of the westberg-nslp draft which I'll try to read before the = meeting. Regards & see you in Vienna,=20 R=FCdiger =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 11 10:05:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29781 for ; Fri, 11 Jul 2003 10:05:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayWE-0004PW-Kd for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 10:05:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BE52rq016952 for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 10:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayWD-0004Ow-Jw; Fri, 11 Jul 2003 10:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayVp-0004Lr-Rf for nsis@optimus.ietf.org; Fri, 11 Jul 2003 10:04:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29647 for ; Fri, 11 Jul 2003 10:04:33 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ayVn-0005r8-00 for nsis@ietf.org; Fri, 11 Jul 2003 10:04:35 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19ayVm-0005r5-00 for nsis@ietf.org; Fri, 11 Jul 2003 10:04:34 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6BE4Xk17437 for ; Fri, 11 Jul 2003 17:04:33 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Jul 2003 17:04:33 +0300 Received: from [172.21.195.217] ([172.21.195.217]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 17:04:30 +0300 Reply-to: john.loughney@nokia.com To: "ext Geib, Ruediger" Cc: nsis@ietf.org Subject: RE: [NSIS] making progress on QoS NSLPs Date: Fri, 11 Jul 2003 17:04:19 +0300 Message-ID: X-Mailer: Symbian OS Email Version 7.0 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 11 Jul 2003 14:04:32.0922 (UTC) FILETIME=[5A7BC7A0:01C347B5] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi R=C3=BCdiger, I ugh that may be a good point. Let's discuss this in Veinna. I favour = focussing on a limited set of features. John -- original message -- Subject: [NSIS] making progress on QoS NSLPs From: "ext Geib, Ruediger" Date: 11th July 2003 3:41:42 pm John, all, after having read draft-buchli-nsis-nslp and draft-mcdonald-nsis-qos-nslp I = asked myself whether we shouldn't draft QoS-NSLP requirements before we = start to work on solutions. If we can agree to proceed with a QoS NSLP = requirements draft, I'd further appreciate to separate "mandatory" and = "nice to have" features. Some impressions I've collected: draft-buchli-nsis-nslp is rather general and leaves open many questions = (security and aggregation, to name two). draft-mcdonald-nsis-qos-nslp suggests a flexible (and complex) generic qos = signaling protocol. It contains information on security (relation to the = remainder of the document is not clear) and aggregation (suggests e.g. IP = in IP tunnels, if I got that correctly). It supports options like service & = resource negotiation and service mapping. I'd prefer to see some = application developer/ISP demand for these before they get part of a = protocol. This is not to say that I'd object to a protocol which may be = extended to support them. I'm currently not looking for a detailed discussion on either document. I'm = aware of the westberg-nslp draft which I'll try to read before the = meeting. Regards & see you in Vienna,=20 R=C3=BCdiger =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 11 12:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04907 for ; Fri, 11 Jul 2003 12:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0ih-0007YS-AT for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 12:26:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BGQ3HM029039 for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 12:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0if-0007YB-Hk; Fri, 11 Jul 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0ic-0007XL-NG for nsis@optimus.ietf.org; Fri, 11 Jul 2003 12:25:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04885 for ; Fri, 11 Jul 2003 12:25:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0ib-0006s8-00 for nsis@ietf.org; Fri, 11 Jul 2003 12:25:57 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19b0ia-0006rZ-00 for nsis@ietf.org; Fri, 11 Jul 2003 12:25:56 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSLD4ZQ>; Fri, 11 Jul 2003 17:25:24 +0100 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , "ext Geib, Ruediger" Cc: nsis@ietf.org Subject: RE: [NSIS] making progress on QoS NSLPs Date: Fri, 11 Jul 2003 17:25:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable john, ruediger, I also suspect it's a bit late for a starting a detailed discussion on the mailing list. However, some of the points here are interesting because they match the open issues which we have been identifying internally. The main issue raised is about flexibility/genericity. I'd stress that in draft-mcdonald-nsis-qos-nslp we didn't set out to build a complex protocol, we set out to build a simple protocol that could be used in complex ways if network engineers wanted to do so. So, there's no protocol element specifically for service mapping or negotiation (for example), and only minimal resource negotiation; however, if you want to use these facilities in a complex way, that's up to the definition of the QoS model in use and the energy of the implementor. In layering terms, this means we have a 'thin' (and flexible) NSLP, which could support thin or thick QoS models. Other people have taken the opposite approach, of having an NSLP which defines a more detailed and rich abstraction of QoS signalling, and a thinner QoS model definition above. What would I say are the major sources of complexity? In order, they are probably: *) the fact that we don't want to hard code a definition of what QoS is and how it should be requested and reserved (what we call a "QoS model" in the draft). The unknown nature of the QoS model prevents us leaving things out. For example, if we knew that QoS was always described by something with the properties of a 2205 Tspec and that the signalling pattern was OPWA (like RSVP) or just one-pass sender initiated, this would make the description of possible protocol = operation *far* simpler (even though the protocol itself might not change much). = Not specfiying a single QoS model is I think a (sensible) charter restriction, but the consequence is flexibility (and maybe complexity) in the protocol. *) supporting sender and receiver initiation and proxy operation. This comes basically from the requirements. *) supporting stateless interior nodes robustly.=20 Aggregation (we looked at general tunnel support as well as 3175-style aggregation) as well as route change support in the end didn't seem so complex - what is in the draft are examples of how the base protocol = can be used to support these functions, there is very little specific needed for = them. BTW, I'm not really clear why we would want something different from=20 the current WG document as a requirements draft for the QoS NSLP. After = all, one of the main complaints about the overall req. draft was that it was = too specific to QoS in the first place. [I recall, after our 20-hour side meeting on NSIS requirements=20 at IETF#53, joking that we might still be having the same discussion = the next time we were back in Minneapolis. Maybe that was premature.] cheers, robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, July 11, 2003 15:04 > To: ext Geib, Ruediger > Cc: nsis@ietf.org > Subject: RE: [NSIS] making progress on QoS NSLPs >=20 >=20 >=20 > Hi R=C3=BCdiger, > I ugh that may be a good point. Let's discuss this in Veinna.=20 > I favour focussing on a limited set of features. >=20 > John >=20 > -- original message -- > Subject: [NSIS] making progress on QoS NSLPs > From: "ext Geib, Ruediger" > Date: 11th July 2003 3:41:42 pm >=20 > John, all, >=20 > after having read draft-buchli-nsis-nslp and=20 > draft-mcdonald-nsis-qos-nslp I asked myself whether we=20 > shouldn't draft QoS-NSLP requirements before we start to work=20 > on solutions. If we can agree to proceed with a QoS NSLP=20 > requirements draft, I'd further appreciate to separate=20 > "mandatory" and "nice to have" features. >=20 > Some impressions I've collected: > draft-buchli-nsis-nslp is rather general and leaves open many=20 > questions (security and aggregation, to name two). > draft-mcdonald-nsis-qos-nslp suggests a flexible (and=20 > complex) generic qos signaling protocol. It contains=20 > information on security (relation to the remainder of the=20 > document is not clear) and aggregation (suggests e.g. IP in=20 > IP tunnels, if I got that correctly). It supports options=20 > like service & resource negotiation and service mapping. I'd=20 > prefer to see some application developer/ISP demand for these=20 > before they get part of a protocol. This is not to say that=20 > I'd object to a protocol which may be extended to support them. >=20 > I'm currently not looking for a detailed discussion on either=20 > document. I'm aware of the westberg-nslp draft which I'll try=20 > to read before the meeting. >=20 > Regards & see you in Vienna,=20 >=20 > R=C3=BCdiger =20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 11 12:29:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05007 for ; Fri, 11 Jul 2003 12:29:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0lZ-0007wU-96 for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 12:29:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BGT1kU030513 for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 12:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0lZ-0007w2-39; Fri, 11 Jul 2003 12:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0l6-0007vP-9l for nsis@optimus.ietf.org; Fri, 11 Jul 2003 12:28:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04984 for ; Fri, 11 Jul 2003 12:28:27 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0l4-0006u6-00 for nsis@ietf.org; Fri, 11 Jul 2003 12:28:30 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19b0l3-0006u3-00 for nsis@ietf.org; Fri, 11 Jul 2003 12:28:30 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6BGSTa07816 for ; Fri, 11 Jul 2003 19:28:29 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Jul 2003 19:28:26 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 19:28:27 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 19:28:27 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 19:28:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [NSIS] making progress on QoS NSLPs Date: Fri, 11 Jul 2003 19:28:26 +0300 Message-ID: Thread-Topic: [NSIS] making progress on QoS NSLPs Thread-Index: AcNHyQrlZstI0bwcR5mBBSiXxZVEkQAACNow To: , Cc: X-OriginalArrivalTime: 11 Jul 2003 16:28:26.0764 (UTC) FILETIME=[74A784C0:01C347C9] Content-Transfer-Encoding: base64 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQo+IEJUVywgSSdtIG5vdCByZWFsbHkgY2xlYXIgd2h5IHdlIHdvdWxkIHdhbnQg c29tZXRoaW5nIGRpZmZlcmVudCBmcm9tIA0KPiB0aGUgY3VycmVudCBXRyBkb2N1bWVudCBhcyBh IHJlcXVpcmVtZW50cyBkcmFmdCBmb3IgdGhlIFFvUyBOU0xQLiBBZnRlciBhbGwsDQo+IG9uZSBv ZiB0aGUgbWFpbiBjb21wbGFpbnRzIGFib3V0IHRoZSBvdmVyYWxsIHJlcS4gZHJhZnQgd2FzIHRo YXQgaXQgd2FzIHRvbw0KPiBzcGVjaWZpYyB0byBRb1MgaW4gdGhlIGZpcnN0IHBsYWNlLg0KDQpX aGF0IEkgdGhpbmsgaXMgdGhhdCB0aGUgZG9jdW1lbnRpbmcgcHJvY2VzcyBvZiB0aGUgUS1OU0xQ IHNob3VsZA0KaGF2ZSBpbiB0aGUgaW50cm9kdWN0aW9uIGEgY3Jpc3Agc2V0IG9mIGZlYXR1cmVz IHRoYXQgaXQgc3VwcG9ydHMuDQpJIGRvbid0IHRoaW5rIGEgc2VwZXJhdGUgZHJhZnQgd2lsbCBz ZXJ2ZSBhbnkgcHVycG9zZS4NCg0KSm9obg0K _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 11 15:00:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10323 for ; Fri, 11 Jul 2003 15:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b37i-0001K9-0v for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 15:00:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BJ01kT005085 for nsis-archive@odin.ietf.org; Fri, 11 Jul 2003 15:00:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b37h-0001Js-8e; Fri, 11 Jul 2003 15:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b37B-0001JL-00 for nsis@optimus.ietf.org; Fri, 11 Jul 2003 14:59:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10275 for ; Fri, 11 Jul 2003 14:59:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b377-0000i1-00 for nsis@ietf.org; Fri, 11 Jul 2003 14:59:25 -0400 Received: from mail-gw.carrieraccess.com ([65.221.135.10] helo=[172.1.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19b376-0000hW-00 for nsis@ietf.org; Fri, 11 Jul 2003 14:59:24 -0400 Received: from newman.carrieraccess.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 11 Jul 2003 12:58:42 -0600 Received: by newman.carrieraccess.com with Internet Mail Service (5.5.2653.19) id <3LN58PBX>; Fri, 11 Jul 2003 12:58:37 -0600 Message-ID: From: "Avella, Alejandro" To: "'nsis@ietf.org'" Date: Fri, 11 Jul 2003 12:58:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C347DE.6EEBBA00" Subject: [NSIS] Comment on draft-westberg-nsis-rsvp-as-ntlp-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C347DE.6EEBBA00 Content-Type: text/plain; charset="iso-8859-1" from draft-westberg-nsis-rsvp-as-ntlp-01.txt " The Resource ReSerVation Protocol (RSVPv1) has been on the standards track within the IETF for a number of years. During that time, the level of vendor support and deployment has been relatively slow, despite the desire of many to deploy technology to deliver services with different levels of quality of service (QoS) to their customers. The reasons for this are arguably well-understood and documented and are not the focus of this memo." Are the QoS deployment issues described correctly on this document? Or is document out-of-date? [RFC2990] G. Huston, Next Steps for the IP QoS Architecture, November 2000. http://www.ietf.org/rfc/rfc2990.txt?number=2990 If that is the case, this document maybe a good reference to your draft. As you said, the reasons are probably well-understood. It would be nice to have a pointer with documentation for the reasons of slow QoS deployment though. Cheers, Alejandro Avella ************************************************************************* This e-mail transmission, and any documents, files, or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution, or use of any of the information contained in or attached to this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving them in any manner. Thank you. ************************************************************************* ------_=_NextPart_001_01C347DE.6EEBBA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comment on draft-westberg-nsis-rsvp-as-ntlp-01.txt

from draft-westberg-nsis-rsvp-as-ntlp-01.t= xt
" The Resource ReSerVation Protocol = (RSVPv1) has been on the standards
   track within the IETF for a = number of years.  During that time, the
   level of vendor support and = deployment has been relatively slow,
   despite the desire of many t= o deploy technology to deliver services
   with different levels of qua= lity of service (QoS) to their customers.
   The reasons for this are arg= uably well-understood and documented and
   are not the focus of this me= mo."

Are the QoS deployment issues described co= rrectly on this document? Or is document out-of-date?
[RFC2990] G. Huston, Next Steps for the I= P QoS Architecture, November 2000. http://www.ietf.org/rfc/rfc2990.txt= ?number=3D2990

If that is the case, this document maybe a= good reference to your draft.  As you said, the reasons are probably =
well-understood.  It would be nice t= o have a pointer with documentation for the reasons of
slow QoS deployment though.

Cheers,

Alejandro Avella



************************************************************************* This e-mail transmission, and any documents, files, or previous
e-mail messages attached to it may contain information that is
confidential or legally privileged. If you are not the intended
recipient, or a person responsible for delivering it to the
intended recipient, you are hereby notified that you must not
read this transmission and that any disclosure, copying, printing,
distribution, or use of any of the information contained in or
attached to this transmission is strictly prohibited. If you have
received this transmission in error, please immediately notify the
sender by telephone or return e-mail and delete the original
transmission and its attachments without reading or saving them
in any manner. Thank you.
************************************************************************* ------_=_NextPart_001_01C347DE.6EEBBA00-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Jul 12 11:32:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23690 for ; Sat, 12 Jul 2003 11:32:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bMM1-0001Ct-SL for nsis-archive@odin.ietf.org; Sat, 12 Jul 2003 11:32:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6CFW5CE004634 for nsis-archive@odin.ietf.org; Sat, 12 Jul 2003 11:32:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bMLx-0001Bp-Ax; Sat, 12 Jul 2003 11:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bML3-0001AM-9A for nsis@optimus.ietf.org; Sat, 12 Jul 2003 11:31:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23629 for ; Sat, 12 Jul 2003 11:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bML2-0001Fa-00 for nsis@ietf.org; Sat, 12 Jul 2003 11:31:04 -0400 Received: from mail-gw.carrieraccess.com ([65.221.135.10] helo=[172.1.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19bML1-0001Ef-00 for nsis@ietf.org; Sat, 12 Jul 2003 11:31:03 -0400 Received: from newman.carrieraccess.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Sat, 12 Jul 2003 09:30:19 -0600 Received: by newman.carrieraccess.com with Internet Mail Service (5.5.2653.19) id <3LN58RZK>; Sat, 12 Jul 2003 09:30:15 -0600 Message-ID: From: "Avella, Alejandro" To: "'nsis@ietf.org'" Date: Sat, 12 Jul 2003 09:30:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C3488A.7A51E520" Subject: [NSIS] tenet reference on Analysis draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3488A.7A51E520 Content-Type: text/plain; charset="iso-8859-1" Page 20, Section 6.1 I couldn't find a reference for tenet on the document, What about using this one: Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, Dinesh C. Verma, Hui Zhang The Tenet Real-Time Protocol Suite: Design, Implementation, and Experiences (1996) IEEE ACM Transactions on Networking http://citeseer.nj.nec.com/banerjea96tenet.html Alejandro Avella ************************************************************************* This e-mail transmission, and any documents, files, or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution, or use of any of the information contained in or attached to this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving them in any manner. Thank you. ************************************************************************* ------_=_NextPart_001_01C3488A.7A51E520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable tenet reference on Analysis draft

Page 20, Section 6.1
I couldn't find a reference for tenet on = the document, What about using this one:

Anindo Banerjea, Domenico Ferrari, Bruce A= . Mah, Mark Moran, Dinesh C. Verma, Hui Zhang
The Tenet Real-Time Protocol Suite: Desig= n, Implementation, and Experiences (1996)
IEEE ACM Transactions on Networking
http://citeseer.nj.nec.com/banerjea96t= enet.html

Alejandro Avella



************************************************************************* This e-mail transmission, and any documents, files, or previous
e-mail messages attached to it may contain information that is
confidential or legally privileged. If you are not the intended
recipient, or a person responsible for delivering it to the
intended recipient, you are hereby notified that you must not
read this transmission and that any disclosure, copying, printing,
distribution, or use of any of the information contained in or
attached to this transmission is strictly prohibited. If you have
received this transmission in error, please immediately notify the
sender by telephone or return e-mail and delete the original
transmission and its attachments without reading or saving them
in any manner. Thank you.
************************************************************************* ------_=_NextPart_001_01C3488A.7A51E520-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Jul 12 16:18:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08607 for ; Sat, 12 Jul 2003 16:18:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bQok-0004yi-NN for nsis-archive@odin.ietf.org; Sat, 12 Jul 2003 16:18:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6CKI27Y019135 for nsis-archive@odin.ietf.org; Sat, 12 Jul 2003 16:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bQoj-0004yT-Px; Sat, 12 Jul 2003 16:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bQoe-0004y7-F2 for nsis@optimus.ietf.org; Sat, 12 Jul 2003 16:17:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08564 for ; Sat, 12 Jul 2003 16:17:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bQoc-0004sK-00 for nsis@ietf.org; Sat, 12 Jul 2003 16:17:54 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bQob-0004sE-00 for nsis@ietf.org; Sat, 12 Jul 2003 16:17:54 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6CKHokM017805; Sat, 12 Jul 2003 16:17:50 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6CKHjN01998; Sat, 12 Jul 2003 16:17:49 -0400 Message-ID: <3F106BF3.90403@cs.columbia.edu> Date: Sat, 12 Jul 2003 16:13:39 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] comments on NTLP design proposals References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hancock, Robert wrote: > > Just for the record, let me say that I can see the attraction of > (a) in terms of providing a conceptual starting point. However, I > have a suspicion that extra functionality - fragmentation, better congestion control, protection against denial-of-service attacks, pmtu discovery, > and so on - will be hard for us to design and hard to build into > the protocol in a nice way. (Another side effect of approach (a) > might well be that the NTLP inherits functionality which was > natural in 2961 - like message summarisation, awareness of > signalling application state - which shouldn't logically be there.) Agreed. 2961 suffered a bit from being a catch-all clean-up effort that commingled a number of separate problems, I believe more for historical reasons (they all appeared at roughly the same time, after people had had a bit of RSVP implementation experience), than technical reasons. > > On the other hand, I am not blind to the issues with (c), mainly > the need for a separate discovery procedure. I suspect it's > impossible to provide a proof (which satisfies everyone) that this > doesn't matter. I would find a logical separation that allows determining the next hop as a by-product a good compromise. It does not reduce performance, but allows the "swapping out" if the need should arise in the future. > > So, maybe (d) would be nice. Unfortunately, I think (d) is > impossible using a fully reliable transport; however, I'm now > pretty (90%) sure that something sensible can be done by > re-using DCCP, and selectively layering reliability on top > (where needed). (You could also use a different congestion response, > like TFRC, which might be nice. In fact, DCCP seems to have *lots* > of nice features...) Definitely a possible choice. I'm not convinced it has to be the only one. I'm somewhat perplexed by the reliability issue. I can't see how a reasonable QoS mechanism, for example, can be built without fast hop-by-hop recovery, where reasonable includes a call setup time that falls within the well-known human factors limits of post-"dial" delays. > > 2. In earlier days of the WG, we were careful to consider the > problems of signalling going through clouds which were not pure > IP DA routed (see also recent discussion on this list about > Allison's comments on the requirements). So, I'm nervous about > protocol designs which assume that the IP DA fully defines the > route taken by a flow (i.e. this is all you need in the PATH-like > message). [Even RSVP uses both the flow SA and DA in PATH messages.] I think we discussed this trade-off in a few previous meetings. The choices all seem uniformly bad under some circumstances. > > In fact, we have up to now had an object in the framework (the > flow id, maybe a better name would be 'flow routing information') > which supposedly exposed at the NTLP level all the information > needed to work out where to send a signalling packet. In addition, > this object could be processed at an NTLP-aware NAT to provide > a traversal service for most signalling applications. I'd be > interested to know if people think this should actually be reflected > in NTLP design (or, if they think it is just a terminally silly > idea - in which case I can take it out of the framework as well). It is probably still somewhat vague what this is meant to be. Can I take this to mean "simple flow descriptor", basically the 5-tuple + IPv6 flow ID + DSCP? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Jul 12 16:23:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08871 for ; Sat, 12 Jul 2003 16:23:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bQtZ-0005DC-GG for nsis-archive@odin.ietf.org; Sat, 12 Jul 2003 16:23:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6CKN1F5020017 for nsis-archive@odin.ietf.org; Sat, 12 Jul 2003 16:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bQtZ-0005Ck-CM; Sat, 12 Jul 2003 16:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bQtS-0005CR-GV for nsis@optimus.ietf.org; Sat, 12 Jul 2003 16:22:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08836 for ; Sat, 12 Jul 2003 16:22:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bQtQ-0004x5-00 for nsis@ietf.org; Sat, 12 Jul 2003 16:22:52 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bQtQ-0004x2-00 for nsis@ietf.org; Sat, 12 Jul 2003 16:22:52 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6CKMqkM018166; Sat, 12 Jul 2003 16:22:52 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6CKMpN02427; Sat, 12 Jul 2003 16:22:51 -0400 Message-ID: <3F106D25.40704@cs.columbia.edu> Date: Sat, 12 Jul 2003 16:18:45 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: robert.hancock@roke.co.uk, nsis@ietf.org Subject: Re: [NSIS] comments on NTLP design proposals References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > (b) is ruled out by our charter. If we want a clean sheet approach, > we need to demonstate why something like 2205+2961 is not sufficient > for the task at hand. Didn't we have this discussion, at length, in the context of fragmentation, flow control and congestion control, on this very list? > > >>So, maybe (d) would be nice. Unfortunately, I think (d) is >>impossible using a fully reliable transport; > > > Using a fully reliable transport option as a starting point requires > proof that reliable transport is needed. I have yet to see good > justification that a relaible transport is required. My gut feeling is that > we start with a connectionless protocol and see how & if a connection-oriented > protocol can be supported. That sounds familiar... I think this discussion would be helped if the word "reliable" is made a bit more precise. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Jul 12 16:38:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09648 for ; Sat, 12 Jul 2003 16:38:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bR85-0005uB-W1 for nsis-archive@odin.ietf.org; Sat, 12 Jul 2003 16:38:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6CKc1Va022682 for nsis-archive@odin.ietf.org; Sat, 12 Jul 2003 16:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bR85-0005tj-NX; Sat, 12 Jul 2003 16:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bR7S-0005n4-FR for nsis@optimus.ietf.org; Sat, 12 Jul 2003 16:37:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09594 for ; Sat, 12 Jul 2003 16:37:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bR7Q-00058e-00 for nsis@ietf.org; Sat, 12 Jul 2003 16:37:20 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bR7P-00058b-00 for nsis@ietf.org; Sat, 12 Jul 2003 16:37:19 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6CKb4kM020725; Sat, 12 Jul 2003 16:37:04 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6CKb3N03716; Sat, 12 Jul 2003 16:37:03 -0400 Message-ID: <3F107079.1010408@cs.columbia.edu> Date: Sat, 12 Jul 2003 16:32:57 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org, brian@hursley.ibm.com Subject: Re: [NSIS] Review of NTLP proposals References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian, thanks for your comments. Mostly questions in-line. john.loughney@nokia.com wrote: >>I think there is scope for combining the two efforts but that >>would need the two authors to agree on the implied requirements >>and on the point about the transport layer. (I do agree with >>Henning that it's a misnomer to call this thing a transport layer. >>Better to call it what it is, a session support layer.) I still think we're doing messaging at the core, from hop to hop, each with its own properties. I agree that the transport name evokes similarities that aren't apt - we are not building a multi-hop transport mechanism with intermediaries, but rather a chain of application-appropriate hop behavior. >>draft-schulzrinne-nsis-ntlp (gimps) >> >>I like. This feature is better than draft-shore, but >>multihoming should >>also be discussed. I wonder (in general) whether multi-homing and mobility are close cousins in this area. Can you identify how "source or destination uses different network layer addresses" and "source or destination changes network layer addresses" differ? Is one the more general version of the other or do we need to treat them separately? I think multihoming is a topic that has received almost no discussion in this group, while mobility has. >>This is also a good feature, but the absence of NAT considerations is >>a major shortfall. To be added. There seem to be two types of NAT behaviors: NTLP-aware NATs that can munge bits >> >>As with draft-shore, I'd like to see discussion of mixed >>IPv4/IPv6 scenarios. Can we constrain the transition mechanisms or should all be covered? >> >>I'm glad to see the security discussion but very concerned >>about the performance >>implications of crypto protection on a hop by hop basis. As >>for other fields >>that need to be examined at every hop, crypto calculations >>may simply be >>out of the question. This is clearly optional, but I don't see why symmetric crypto, as in IPsec or TLS, would be a big deal for anything but the multi-hundred Mb/s signaling channel. I agree that having to do key exchange for every session, with its public key operations, is likely to be a bear, so 'restart' (for TLS) is a minimum. As Michael Thomas has pointed out, this may not be a mode we need all that much, although I can think of a few cases where transport integrity protection would be useful, as they might be significantly cheaper than message-based (NSLP) crypto like CMS operations. One such example is network diagnostics where the querier wants to keep the results private from external listeners, but doesn't want to configure shared secrets in all routers. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jul 13 05:41:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06965 for ; Sun, 13 Jul 2003 05:41:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdLv-0000co-E6 for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 05:41:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6D9f7Le002402 for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 05:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdLp-0000c2-H8; Sun, 13 Jul 2003 05:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdGz-0000KD-Nd for nsis@optimus.ietf.org; Sun, 13 Jul 2003 05:36:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06658 for ; Sun, 13 Jul 2003 05:35:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bdGw-0000ol-00 for nsis@ietf.org; Sun, 13 Jul 2003 05:35:58 -0400 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by ietf-mx with esmtp (Exim 4.12) id 19bdGv-0000oC-00 for nsis@ietf.org; Sun, 13 Jul 2003 05:35:57 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6D9ZEo1042734; Sun, 13 Jul 2003 11:35:14 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6D9ZEkX226490; Sun, 13 Jul 2003 11:35:14 +0200 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA25498; Sun, 13 Jul 2003 11:35:12 +0200 Message-ID: <3F1127D8.7C746A63@hursley.ibm.com> Date: Sun, 13 Jul 2003 11:35:20 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Henning Schulzrinne CC: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Review of NTLP proposals References: <3F107079.1010408@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit below... Henning Schulzrinne wrote: > > Brian, thanks for your comments. Mostly questions in-line. > > john.loughney@nokia.com wrote: > > >>I think there is scope for combining the two efforts but that > >>would need the two authors to agree on the implied requirements > >>and on the point about the transport layer. (I do agree with > >>Henning that it's a misnomer to call this thing a transport layer. > >>Better to call it what it is, a session support layer.) > > I still think we're doing messaging at the core, from hop to hop, each > with its own properties. I agree that the transport name evokes > similarities that aren't apt - we are not building a multi-hop transport > mechanism with intermediaries, but rather a chain of > application-appropriate hop behavior. > > >>draft-schulzrinne-nsis-ntlp (gimps) > >> > > >>I like. This feature is better than draft-shore, but > >>multihoming should > >>also be discussed. > > I wonder (in general) whether multi-homing and mobility are close > cousins in this area. Can you identify how "source or destination uses > different network layer addresses" and "source or destination changes > network layer addresses" differ? Is one the more general version of the > other or do we need to treat them separately? I think multihoming is a > topic that has received almost no discussion in this group, while > mobility has. Well, Mobile IP is certainly in the set of solutions that don't quite solve the multihoming problem (excuse the sarcastic tone, but we really do have a challenge in meeting all the conflicting requirements for multihoming, hence the churn in the multi6 WG). So there is linkage, but the scenarios are not isomorphic. > > >>This is also a good feature, but the absence of NAT considerations is > >>a major shortfall. > > To be added. There seem to be two types of NAT behaviors: NTLP-aware > NATs that can munge bits > > >> > >>As with draft-shore, I'd like to see discussion of mixed > >>IPv4/IPv6 scenarios. > > Can we constrain the transition mechanisms or should all be covered? All is at least twelve mechanisms, so I don't think you want to go there. But at least the basic dual stack, IPv6-in-IPv4 tunnels, and ugly NAT/PT could be covered. > > >> > >>I'm glad to see the security discussion but very concerned > >>about the performance > >>implications of crypto protection on a hop by hop basis. As > >>for other fields > >>that need to be examined at every hop, crypto calculations > >>may simply be > >>out of the question. > > This is clearly optional, but I don't see why symmetric crypto, as in > IPsec or TLS, would be a big deal for anything but the multi-hundred > Mb/s signaling channel. I agree that having to do key exchange for every > session, with its public key operations, is likely to be a bear, so > 'restart' (for TLS) is a minimum. As Michael Thomas has pointed out, > this may not be a mode we need all that much, although I can think of a > few cases where transport integrity protection would be useful, as they > might be significantly cheaper than message-based (NSLP) crypto like CMS > operations. One such example is network diagnostics where the querier > wants to keep the results private from external listeners, but doesn't > want to configure shared secrets in all routers. In any case I think you need to discuss whether crypto overhead is a significant concern. Also whether IPSEC flows can actually get useful benefit from an NSIS environment which they can't get from RSVP). Brian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jul 13 05:45:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07181 for ; Sun, 13 Jul 2003 05:45:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdPh-0000mS-6U for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 05:45:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6D9j1lI002982 for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 05:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdPh-0000m0-03; Sun, 13 Jul 2003 05:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdPR-0000lj-Mw for nsis@optimus.ietf.org; Sun, 13 Jul 2003 05:44:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07137 for ; Sun, 13 Jul 2003 05:44:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bdPO-0000wq-00 for nsis@ietf.org; Sun, 13 Jul 2003 05:44:42 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bdPN-0000wn-00 for nsis@ietf.org; Sun, 13 Jul 2003 05:44:41 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6D9ifkM006751; Sun, 13 Jul 2003 05:44:41 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6D9iek32360; Sun, 13 Jul 2003 05:44:40 -0400 Message-ID: <3F112912.4070709@cs.columbia.edu> Date: Sun, 13 Jul 2003 05:40:34 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Review of NTLP proposals References: <3F107079.1010408@cs.columbia.edu> <3F1127D8.7C746A63@hursley.ibm.com> In-Reply-To: <3F1127D8.7C746A63@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Well, Mobile IP is certainly in the set of solutions that don't quite > solve the multihoming problem (excuse the sarcastic tone, but we really > do have a challenge in meeting all the conflicting requirements for > multihoming, hence the churn in the multi6 WG). So there is linkage, but > the scenarios are not isomorphic. You're extrapolating :-) I wasn't specifically talking about mobile IP, but the general problem that a node changes IP addresses (which mobile IP may then hide from, say, TCP). For example, in some versions of application-layer mobility, there is no mobile IP at all, but rather, changes in IP address are signaled at the application layer. At least with binding updates, the path would change. > In any case I think you need to discuss whether crypto overhead is > a significant concern. Also whether IPSEC flows can actually get > useful benefit from an NSIS environment which they can't get from RSVP). Your comment seems to reflect a view of IPsec as an NSIS *user*; I was thinking of the inverse - NSIS as an IPsec (or TLS) user to protect the upper-layer signaling information from intercept and modification. > > Brian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jul 13 08:49:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17921 for ; Sun, 13 Jul 2003 08:49:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgHm-0005xV-7g for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 08:49:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DCn2Dn022899 for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 08:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgHl-0005xE-BO; Sun, 13 Jul 2003 08:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgHB-0005wZ-6V for nsis@optimus.ietf.org; Sun, 13 Jul 2003 08:48:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17853 for ; Sun, 13 Jul 2003 08:48:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bgH9-0003cm-00 for nsis@ietf.org; Sun, 13 Jul 2003 08:48:23 -0400 Received: from bay8-f54.bay8.hotmail.com ([64.4.27.54] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19bgH9-0003c3-00 for nsis@ietf.org; Sun, 13 Jul 2003 08:48:23 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 13 Jul 2003 05:47:52 -0700 Received: from 81.160.141.224 by by8fd.bay8.hotmail.msn.com with HTTP; Sun, 13 Jul 2003 12:47:51 GMT X-Originating-IP: [81.160.141.224] X-Originating-Email: [hannestschofenig@hotmail.com] From: "Hannes Tschofenig" To: nsis@ietf.org Date: Sun, 13 Jul 2003 14:47:51 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2003 12:47:52.0645 (UTC) FILETIME=[F954B750:01C3493C] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA17854 Subject: [NSIS] ntlp security thoughts Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi all, i have compiled some thoughts on ntlp security. please see below: ciao hannes ---------------------------------------------------------- NTLP Security Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 1. Introduction Based on the discussions at the IETF #56 NSIS working group meeting two n= ew=20 NTLP proposals have been submitted (see [1] and [2]). The architectural two-layer split into an NTLP (a generic transport=20 mechanism) and an NSLP part (the NSLP part contains the application speci= fic=20 signaling payloads). Although this layer split (with regard to security) = was=20 already introduced with policy-aware and policy-ignorant nodes in RSVP, t= he=20 question was raised what type of security should be enforced at which lay= er. There is conconsus that - at least some authorization decisions should be handled specific for=20 certain applications. - non peer-to-peer security must be handled at the application layer Some members, however, believe that security protection for the signaling= =20 messages at the NTLP layer is not necessary. It should be noted that the introduction of the two-layer split might cau= se=20 that signaling messages traversing n NTLP nodes whereby only m of these=20 nodes (possibly with m<, (work in progress), May 2003. [2] H. Schulzrinne: "GIMPS: General Internet Messaging Protocol for=20 Signaling" , (work in progress), June= =20 2003. [3] H. Tschofenig, et al.: "Security Implications of the Session=20 Identifier", , (work in progress), May=20 2003. _________________________________________________________________ MSN Hotmail=A0 - =A0Absolut kostenfrei! Der weltweit gr=F6=DFte E-Mail-An= bieter im=20 Netz: http://www.msn.de/hotmail _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jul 13 09:37:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20859 for ; Sun, 13 Jul 2003 09:37:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh2D-0007N0-5V for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 09:37:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DDb1db028314 for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 09:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh2C-0007MZ-Tw; Sun, 13 Jul 2003 09:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh1Z-0007Lv-K6 for nsis@optimus.ietf.org; Sun, 13 Jul 2003 09:36:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20770 for ; Sun, 13 Jul 2003 09:36:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bh1X-0004Nk-00 for nsis@ietf.org; Sun, 13 Jul 2003 09:36:19 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bh1X-0004Ng-00 for nsis@ietf.org; Sun, 13 Jul 2003 09:36:19 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DDaHkM027277; Sun, 13 Jul 2003 09:36:17 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DDaGk00344; Sun, 13 Jul 2003 09:36:16 -0400 Message-ID: <3F115F5A.4030201@cs.columbia.edu> Date: Sun, 13 Jul 2003 09:32:10 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig CC: nsis@ietf.org Subject: Re: [NSIS] ntlp security thoughts References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id h6DDaHkM027277 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: Comments in-line. > It should be noted that the introduction of the two-layer split might=20 > cause that signaling messages traversing n NTLP nodes whereby only m of= =20 > these nodes (possibly with m< required. >=20 > Goal of this document is to describe some threats against the NTLP=20 > protocol. The reader should by itself decide whether these threats=20 > require countermeasures. It might be helpful to divide these into threats that are particularly=20 serious with non-NSLP-aware nodes and others that affect all nodes equall= y. Also, some of these attacks can effectively be prevented or limited by=20 forcing a return-routability test, without a full crypto mechanism. I=20 think it would be helpful to highlight those. Finally, it would be helpful to classify the attacks by whether they can=20 be perpetrated by a remote third party (without ability to listen) or=20 whether they need the attacker to be able to intercept the messages.=20 Some consider the ability of backbone snooping sufficiently unlikely=20 that those risks may not warrant mitigation. > - Terminate signaling >=20 > Unprotected error messages allow an adversary to delete NTLP state (and= =20 > possibly NSLP state) when returned unprotected. >=20 > - Combined discovery and signaling message delivery >=20 > Combining discovery together with signaling message delivery prevents=20 > usage of security mechanisms (even at the NSLP layer). Furthermore it=20 Depends. If NSLP messages are individually integrity-protected with the=20 sender's private key, this may not be the case. >=20 > - Create NTLP state >=20 > An RSVP path-alike message allows an adversary to create NTLP state at = a=20 > number of NSIS nodes along the path. This might be seen as an=20 > amplification attack. Or an adversary might just do a state-exhaustion attack by creating NTLP=20 state. Here, return routability can help some since one can then limit=20 the number of states that each previous hop can establish. >=20 > - Modification to the HOP address >=20 > When an RSVP path-alike signaling message is intercepted by an NTLP nod= e=20 > the HOP address is stored in the NTLP state table. This allows an=20 > adversary to change routing of NTLP (and therefore NSLP messages). This= =20 > might either lead to messages routed to unreachable IP addresses or to=20 > other NSIS nodes or to the adversary itself. Assuming that NSLP services, such as QoS, cost money, I can then route=20 the message to particularly expensive nodes, even though the data=20 doesn't go there. A local reservation in Vienna can take a slight detour=20 via New York, picking up reservation charges along the way. This is=20 particularly helpful if one of the nodes can be located in a small=20 Caribbean Island where the local telco has a cozy relationship with the=20 attacker. >=20 > - Modification of the refresh period >=20 > An adversary changing the refresh period is able to control the rate at= =20 > which refresh messages are expected. Together with bogus state creation= =20 > messages this might allow an adversary to store state much longer=20 > resulting in a more effective DoS attack. >=20 > Reducing the refresh interval causes NTLP nodes to expect refresh=20 > messages at a higher rate. This might cause state timeouts due to the=20 > absence of refresh messages. >=20 > - Teardown NTLP state >=20 > The NTLP protocol defines different operations on the NTLP state. One o= f=20 > this operation allows to delete NTLP state information. An adversary ca= n=20 > issue a teardown message in both direction. A RSVP path-alike teardown=20 > message might restrict the location of the adversary whereas the RSVP=20 > resv-alike teardown message can be initiated from any location to any=20 > NTLP node along the path. >=20 > The implications of deleted NTLP has implications for NSLPs (e.g.=20 > reverse routing is not possible if reverse routing information is not=20 > present). >=20 > - Session Ownership >=20 > Including the session identifier into the NTLP might be exploited by an= =20 > adversary as described in [3]. >=20 > - Flow ID modification >=20 > It was mentioned that the inclusion of the flow identifier in the NTLP=20 > allows NAT aware NTLPs to perform address translation independent of th= e=20 > NSLP. It needs to be verified whether the inclusion of the flow=20 > identifier for the purpose of network address translation helps in all=20 > cases. As an other alternative it is necessary to enable NATs to=20 > understand all NSLP protocols. >=20 > In any case if a flow identifier is included in the NTLP (unprotected)=20 > then an adversary is able to modify the flow identifier to e.g. make Qo= S=20 > reservations inefficient, exploit if for other purposes (e.g. theft of=20 > service), for DoS attacks etc. The same implications can be considered=20 > in case of NAT/firewall signaling. >=20 > 3. Summary >=20 >=20 > As a summary it is possible to add, modify and delete any state=20 > information available. This might cause NSLP signaling to become=20 > ineffective or to abort. Various denial of service attacks are possible. >=20 > 4. References >=20 > [1] M. Shore: "The NSIS Transport Layer Protocol (NTLP)",=20 > , (work in progress), May 2003. >=20 > [2] H. Schulzrinne: "GIMPS: General Internet Messaging Protocol for=20 > Signaling" , (work in progress),=20 > June 2003. >=20 > [3] H. Tschofenig, et al.: "Security Implications of the Session=20 > Identifier", , (work in progress), Ma= y=20 > 2003. >=20 > _________________________________________________________________ > MSN Hotmail - Absolut kostenfrei! Der weltweit gr=F6=DFte E-Mail-Anbi= eter=20 > im Netz: http://www.msn.de/hotmail >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jul 13 10:19:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24590 for ; Sun, 13 Jul 2003 10:19:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhgs-0000eg-7j for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 10:19:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DEJ2Gv002511 for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 10:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhgr-0000eO-Bm; Sun, 13 Jul 2003 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhgc-0000eD-8f for nsis@optimus.ietf.org; Sun, 13 Jul 2003 10:18:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24555 for ; Sun, 13 Jul 2003 10:18:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhga-00051D-00 for nsis@ietf.org; Sun, 13 Jul 2003 10:18:44 -0400 Received: from bay8-f23.bay8.hotmail.com ([64.4.27.23] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19bhgZ-00050o-00 for nsis@ietf.org; Sun, 13 Jul 2003 10:18:43 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 13 Jul 2003 07:18:12 -0700 Received: from 81.160.141.224 by by8fd.bay8.hotmail.msn.com with HTTP; Sun, 13 Jul 2003 14:18:11 GMT X-Originating-IP: [81.160.141.224] X-Originating-Email: [hannestschofenig@hotmail.com] From: "Hannes Tschofenig" To: hgs@cs.columbia.edu Cc: nsis@ietf.org Subject: Re: [NSIS] ntlp security thoughts Date: Sun, 13 Jul 2003 16:18:11 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2003 14:18:12.0771 (UTC) FILETIME=[97FA4F30:01C34949] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA24556 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi henning, thanks for your quick response. please find my comments inline: >From: Henning Schulzrinne >To: Hannes Tschofenig >CC: nsis@ietf.org >Subject: Re: [NSIS] ntlp security thoughts >Date: Sun, 13 Jul 2003 09:32:10 -0400 > >Hannes Tschofenig wrote: > > >Comments in-line. > >>It should be noted that the introduction of the two-layer split might=20 >>cause that signaling messages traversing n NTLP nodes whereby only m of= =20 >>these nodes (possibly with m<>required. >> >>Goal of this document is to describe some threats against the NTLP=20 >>protocol. The reader should by itself decide whether these threats requ= ire=20 >>countermeasures. > >It might be helpful to divide these into threats that are particularly=20 >serious with non-NSLP-aware nodes and others that affect all nodes equal= ly. that's certainly true although it is not simple for the following reasons= : a) i would need more information on the ntlp behavior with regard to the=20 nslp. (e.g. would you delete nslp state if you receive an ntlp "teardown" messa= ge) b) it might depend on certain nslps (and on the security of them) c) i would have to rate how harmful certain attacks are e.g. is flooding (dos) more serious than transmitting a bogus terminate=20 signaling message? i thought about it for the "security threats for nsis" draft. unfortunate= ly=20 it is not as easy as it sounds. i can, however, try it. > >Also, some of these attacks can effectively be prevented or limited by=20 >forcing a return-routability test, without a full crypto mechanism. I th= ink=20 >it would be helpful to highlight those. certainly. there are some non-crypto mechanisms that prevent certain=20 attacks. i haven't listed possible countermeasures e.g. deleting state information based on a bogus "teardown" message is=20 problematic. possible solution: do not support such a message (use soft-state timeout=20 only) > >Finally, it would be helpful to classify the attacks by whether they can= be=20 >perpetrated by a remote third party (without ability to listen) or wheth= er=20 >they need the attacker to be able to intercept the messages. Some consid= er=20 >the ability of backbone snooping sufficiently unlikely that those risks = may=20 >not warrant mitigation. true - separating adversaries into off-path an on-path makes sense. i will add some text. > >>- Terminate signaling >> >>Unprotected error messages allow an adversary to delete NTLP state (and= =20 >>possibly NSLP state) when returned unprotected. >> >>- Combined discovery and signaling message delivery >> >>Combining discovery together with signaling message delivery prevents=20 >>usage of security mechanisms (even at the NSLP layer). Furthermore it > >Depends. If NSLP messages are individually integrity-protected with the=20 >sender's private key, this may not be the case. that is certainly possible but the usage of public key cryptography creat= es=20 dos attack vulnerabilities. what prevents an adversary from flooding an nsis node with bogus (randoml= y=20 generated) messages? they cause the nsis node to verify the digital signature. additionally messages get large (certificates, digital signature etc.). > > >> >>- Create NTLP state >> >>An RSVP path-alike message allows an adversary to create NTLP state at = a=20 >>number of NSIS nodes along the path. This might be seen as an=20 >>amplification attack. > >Or an adversary might just do a state-exhaustion attack by creating NTLP= =20 >state. yes. i will add it. >Here, return routability can help some since one can then limit the numb= er=20 >of states that each previous hop can establish. > return routability can help to limit some problems. unfortunately not=20 entirely. a mobile node at the wireless link can create messages (and he would see = the=20 response). the return-routability makes it more difficult to mount the=20 attacks (since the adversary has to wait for the response) but does not=20 prevent it. for an offpath adversary return routability certainly helps. > >> >>- Modification to the HOP address >> >>When an RSVP path-alike signaling message is intercepted by an NTLP nod= e=20 >>the HOP address is stored in the NTLP state table. This allows an=20 >>adversary to change routing of NTLP (and therefore NSLP messages). This= =20 >>might either lead to messages routed to unreachable IP addresses or to=20 >>other NSIS nodes or to the adversary itself. > >Assuming that NSLP services, such as QoS, cost money, I can then route t= he=20 >message to particularly expensive nodes, even though the data doesn't go= =20 >there. A local reservation in Vienna can take a slight detour via New Yo= rk,=20 >picking up reservation charges along the way. This is particularly helpf= ul=20 >if one of the nodes can be located in a small Caribbean Island where the= =20 >local telco has a cozy relationship with the attacker. good idea - sounds like a interesting application :-) > > >> >>- Modification of the refresh period >> >>An adversary changing the refresh period is able to control the rate at= =20 >>which refresh messages are expected. Together with bogus state creation= =20 >>messages this might allow an adversary to store state much longer=20 >>resulting in a more effective DoS attack. >> >>Reducing the refresh interval causes NTLP nodes to expect refresh messa= ges=20 >>at a higher rate. This might cause state timeouts due to the absence of= =20 >>refresh messages. >> >>- Teardown NTLP state >> >>The NTLP protocol defines different operations on the NTLP state. One o= f=20 >>this operation allows to delete NTLP state information. An adversary ca= n=20 >>issue a teardown message in both direction. A RSVP path-alike teardown=20 >>message might restrict the location of the adversary whereas the RSVP=20 >>resv-alike teardown message can be initiated from any location to any N= TLP=20 >>node along the path. >> >>The implications of deleted NTLP has implications for NSLPs (e.g. rever= se=20 >>routing is not possible if reverse routing information is not present). >> >>- Session Ownership >> >>Including the session identifier into the NTLP might be exploited by an= =20 >>adversary as described in [3]. >> >>- Flow ID modification >> >>It was mentioned that the inclusion of the flow identifier in the NTLP=20 >>allows NAT aware NTLPs to perform address translation independent of th= e=20 >>NSLP. It needs to be verified whether the inclusion of the flow identif= ier=20 >>for the purpose of network address translation helps in all cases. As a= n=20 >>other alternative it is necessary to enable NATs to understand all NSLP= =20 >>protocols. >> >>In any case if a flow identifier is included in the NTLP (unprotected)=20 >>then an adversary is able to modify the flow identifier to e.g. make Qo= S=20 >>reservations inefficient, exploit if for other purposes (e.g. theft of=20 >>service), for DoS attacks etc. The same implications can be considered = in=20 >>case of NAT/firewall signaling. >> >>3. Summary >> >> >>As a summary it is possible to add, modify and delete any state=20 >>information available. This might cause NSLP signaling to become=20 >>ineffective or to abort. Various denial of service attacks are possible. >> >>4. References >> >>[1] M. Shore: "The NSIS Transport Layer Protocol (NTLP)",=20 >>, (work in progress), May 2003. >> >>[2] H. Schulzrinne: "GIMPS: General Internet Messaging Protocol for=20 >>Signaling" , (work in progress), Ju= ne=20 >>2003. >> >>[3] H. Tschofenig, et al.: "Security Implications of the Session=20 >>Identifier", , (work in progress), Ma= y=20 >>2003. >> >>_________________________________________________________________ >>MSN Hotmail - Absolut kostenfrei! Der weltweit gr=F6=DFte E-Mail-Anbi= eter im=20 >>Netz: http://www.msn.de/hotmail >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* =20 http://join.msn.com/?page=3Dfeatures/junkmail _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jul 13 10:40:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25977 for ; Sun, 13 Jul 2003 10:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bi1C-0001Oj-CF for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 10:40:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DEe270005365 for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 10:40:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bi1B-0001OM-Hl; Sun, 13 Jul 2003 10:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bi0H-0001LF-5t for nsis@optimus.ietf.org; Sun, 13 Jul 2003 10:39:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25866 for ; Sun, 13 Jul 2003 10:39:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bi0E-0005Jz-00 for nsis@ietf.org; Sun, 13 Jul 2003 10:39:02 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bi0E-0005Jw-00 for nsis@ietf.org; Sun, 13 Jul 2003 10:39:02 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DEd1kM003082; Sun, 13 Jul 2003 10:39:01 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DEcxk00483; Sun, 13 Jul 2003 10:39:00 -0400 Message-ID: <3F116E0D.9060906@cs.columbia.edu> Date: Sun, 13 Jul 2003 10:34:53 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig CC: nsis@ietf.org Subject: Re: [NSIS] ntlp security thoughts References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hannes Tschofenig wrote: > that's certainly true although it is not simple for the following reasons: > a) i would need more information on the ntlp behavior with regard to the > nslp. > (e.g. would you delete nslp state if you receive an ntlp "teardown" > message) I can't see how you can have free-floating NSLP state. This may be proposal-specific, but my assumption was that NTLP state is necessary for NSLP state. I can't see any disadvantages of this approach, but others will likely differ (but I would appreciate concrete benefits of allowing this, as it makes a lot of things far more complicated, in my view). > b) it might depend on certain nslps (and on the security of them) > c) i would have to rate how harmful certain attacks are > e.g. is flooding (dos) more serious than transmitting a bogus terminate > signaling message? I would only suggest classifying this on a per-attack basis, not generically. > i can, however, try it. Clearly, in some cases the answer is going to be "it depends". > e.g. deleting state information based on a bogus "teardown" message is > problematic. > possible solution: do not support such a message (use soft-state timeout > only) This is not a viable option, I'm afraid. If we can't agree on that within the working group, we have far bigger problems than worrying about DOS attacks, since there won't be any service to deny. > that is certainly possible but the usage of public key cryptography > creates dos attack vulnerabilities. Unless this has changed, I thought there was some agreement that we will need CMS-style PK at NSLP layer since none of the other solutions scale cross-domain. Is there another proposal, leaving optimizations for specific scenarios aside? I don't think we can make progress if we don't admit to certain realities, even if we disagree how often they are needed. Maybe we need to hum on such a list such as: - some applications will need PK crypto at NSLP layer - some applications will need reliable message delivery - some messages are going to exceed 500 bytes etc. > > what prevents an adversary from flooding an nsis node with bogus > (randomly generated) messages? > they cause the nsis node to verify the digital signature. Nothing. But that's where, say, return-routability allows me to throttle a particular host (attacker) and limit the ability of one attacker to cause damage. You just stick each peer into its own queue and serve them round-robin. That way, an attacker has to compromise lots of hosts to be effective. > > additionally messages get large (certificates, digital signature etc.). Yes, about 5 KB, at minimum, to be precise. Such is life :-) > a mobile node at the wireless link can create messages (and he would see > the response). the return-routability makes it more difficult to mount > the attacks (since the adversary has to wait for the response) but does > not prevent it. You are assuming that the wireless link is unprotected. One would hope that this is a temporary condition that only afflicts certain current implementations. I believe that 3G networks, for example, don't suffer from this problem. >> small Caribbean Island where the local telco has a cozy relationship >> with the attacker. > > > good idea - sounds like a interesting application :-) Can one file a business method patent on how to defraud people? Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jul 13 17:22:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05998 for ; Sun, 13 Jul 2003 17:22:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19boIJ-0004az-2r for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 17:22:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DLM7LY017659 for nsis-archive@odin.ietf.org; Sun, 13 Jul 2003 17:22:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19boID-0004aG-JM; Sun, 13 Jul 2003 17:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19beaO-0002kk-Mc for nsis@optimus.ietf.org; Sun, 13 Jul 2003 07:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11546 for ; Sun, 13 Jul 2003 07:00:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19beaK-00021u-00 for nsis@ietf.org; Sun, 13 Jul 2003 07:00:04 -0400 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by ietf-mx with esmtp (Exim 4.12) id 19beaJ-00021P-00 for nsis@ietf.org; Sun, 13 Jul 2003 07:00:03 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6DAxLZG013292; Sun, 13 Jul 2003 12:59:21 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6DAxLnM210186; Sun, 13 Jul 2003 12:59:21 +0200 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA46636; Sun, 13 Jul 2003 12:59:18 +0200 Message-ID: <3F113B8D.3077B1A3@hursley.ibm.com> Date: Sun, 13 Jul 2003 12:59:25 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Henning Schulzrinne CC: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Review of NTLP proposals References: <3F107079.1010408@cs.columbia.edu> <3F1127D8.7C746A63@hursley.ibm.com> <3F112912.4070709@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Brian E Carpenter wrote: > > > Well, Mobile IP is certainly in the set of solutions that don't quite > > solve the multihoming problem (excuse the sarcastic tone, but we really > > do have a challenge in meeting all the conflicting requirements for > > multihoming, hence the churn in the multi6 WG). So there is linkage, but > > the scenarios are not isomorphic. > > You're extrapolating :-) I wasn't specifically talking about mobile IP, > but the general problem that a node changes IP addresses (which mobile > IP may then hide from, say, TCP). For example, in some versions of > application-layer mobility, there is no mobile IP at all, but rather, > changes in IP address are signaled at the application layer. At least > with binding updates, the path would change. Certainly. SCTP is fun to think about in a multihoming world. > > > In any case I think you need to discuss whether crypto overhead is > > a significant concern. Also whether IPSEC flows can actually get > > useful benefit from an NSIS environment which they can't get from RSVP). > > Your comment seems to reflect a view of IPsec as an NSIS *user*; I was > thinking of the inverse - NSIS as an IPsec (or TLS) user to protect the > upper-layer signaling information from intercept and modification. Both ways round are interesting. Brian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 03:30:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29556 for ; Mon, 14 Jul 2003 03:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxmd-0008TJ-Cs for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 03:30:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E7U3qX032559 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 03:30:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxmb-0008Sf-Hw; Mon, 14 Jul 2003 03:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxm3-0008Rl-QK for nsis@optimus.ietf.org; Mon, 14 Jul 2003 03:29:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29521 for ; Mon, 14 Jul 2003 03:29:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bxm1-0002IT-00 for nsis@ietf.org; Mon, 14 Jul 2003 03:29:25 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19bxm0-0002Hf-00 for nsis@ietf.org; Mon, 14 Jul 2003 03:29:25 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSK1L6N>; Mon, 14 Jul 2003 08:28:46 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] Review of NTLP proposals Date: Mon, 14 Jul 2003 08:28:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Brian, Henning, all, Up to now I think we have been discussing multihoming rather implicitly, as something which - along with IP or higher layer mobility - can cause the general problem that the relationship between application-layer session and [micro]flow to be more than just a simple 1:1 relationship. That's what the session identifier functionality is about. However, I don't see that the NTLP should have a role in trying to 'solve' the multihoming problem, because the correct solution almost certainly depends on the demands of the signalling application (at the moment, the framework assumes that handling IP address change is a signalling application responsibility, essentially for the same reason). The NTLP should think in terms of single flows defined by fixed N-tuples, and anything cleverer has to be pushed upstairs, IMHO. cheers, Robert h. > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Sunday, July 13, 2003 12:59 > To: Henning Schulzrinne > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] Review of NTLP proposals > > > Henning Schulzrinne wrote: > > > > Brian E Carpenter wrote: > > > > > Well, Mobile IP is certainly in the set of solutions that > don't quite > > > solve the multihoming problem (excuse the sarcastic tone, > but we really > > > do have a challenge in meeting all the conflicting > requirements for > > > multihoming, hence the churn in the multi6 WG). So there > is linkage, but > > > the scenarios are not isomorphic. > > > > You're extrapolating :-) I wasn't specifically talking > about mobile IP, > > but the general problem that a node changes IP addresses > (which mobile > > IP may then hide from, say, TCP). For example, in some versions of > > application-layer mobility, there is no mobile IP at all, > but rather, > > changes in IP address are signaled at the application > layer. At least > > with binding updates, the path would change. > > Certainly. SCTP is fun to think about in a multihoming world. > > > > > > In any case I think you need to discuss whether crypto overhead is > > > a significant concern. Also whether IPSEC flows can actually get > > > useful benefit from an NSIS environment which they can't > get from RSVP). > > > > Your comment seems to reflect a view of IPsec as an NSIS > *user*; I was > > thinking of the inverse - NSIS as an IPsec (or TLS) user to > protect the > > upper-layer signaling information from intercept and modification. > > Both ways round are interesting. > > Brian > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 03:31:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29601 for ; Mon, 14 Jul 2003 03:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxna-0000AO-Om for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 03:31:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E7V2rc000602 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 03:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxna-000096-Dw; Mon, 14 Jul 2003 03:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxnG-00006B-GC for nsis@optimus.ietf.org; Mon, 14 Jul 2003 03:30:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29574 for ; Mon, 14 Jul 2003 03:30:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bxnD-0002JM-00 for nsis@ietf.org; Mon, 14 Jul 2003 03:30:40 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19bxnC-0002JI-00 for nsis@ietf.org; Mon, 14 Jul 2003 03:30:38 -0400 Received: from cs.uni-goettingen.de (ap26.ietf57.telekom.at [::ffff:81.160.140.226]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 14 Jul 2003 09:30:44 +0200 Message-ID: <3F125C1D.8050106@cs.uni-goettingen.de> Date: Mon, 14 Jul 2003 09:30:37 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles Q. Shen" , nsis@ietf.org Subject: Message ID v.s. Branch ID --was Re: [NSIS] Proposed draft "Mobility Support in NSIS" References: <000201c3469f$a9b2af30$c7f027a0@president> In-Reply-To: <000201c3469f$a9b2af30$c7f027a0@president> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Charles Q. Shen wrote: > Ok, so you are talking about the Synchronization/out of sequence > problem. Usually it is solved by some kind of messages ID/sequence > number (e.g., in related routing protocol updates, RSVP refreshes, and > our RSVP-MIP test-bed). I am not very sure what is the difference > between the Branch ID you mentioned in your draft from the message ID > approach. > Yes, the following terms sound similar: Epoch (RFC2961) ~ Session ID Message ID (RFC2961) ~ Branch ID However, they are not quite the same. To my understanding, Message ID (together with Epoch) concerns with signaling messages between _peering neighbers_, where out-of-order problem can come from retransmission/refresh. (Correct me if I'm wrong). While talking about Branch ID, I meant it (together Session ID) can be used for avoiding syncronization of signaling messages along different branches (each can consist of multiple hops). This can be generally useful for determining end of (explicit) teardown message to forward on along the common path. Thanks, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 03:42:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29785 for ; Mon, 14 Jul 2003 03:42:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxyE-0000ii-9Z for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 03:42:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E7g2VL002749 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 03:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxyD-0000iA-P5; Mon, 14 Jul 2003 03:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxxY-0000hL-Cr for nsis@optimus.ietf.org; Mon, 14 Jul 2003 03:41:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29757 for ; Mon, 14 Jul 2003 03:41:18 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bxxT-0002Lw-00 for nsis@ietf.org; Mon, 14 Jul 2003 03:41:15 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19bxxS-0002Lt-00 for nsis@ietf.org; Mon, 14 Jul 2003 03:41:14 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6E7fDk07330 for ; Mon, 14 Jul 2003 10:41:13 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 10:41:13 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 10:41:12 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 10:41:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Review of NTLP proposals Date: Mon, 14 Jul 2003 10:41:11 +0300 Message-ID: Thread-Topic: [NSIS] Review of NTLP proposals Thread-Index: AcNJ2dHWAKdu76n1SzWQaZa3EHb5igAARyYA To: , X-OriginalArrivalTime: 14 Jul 2003 07:41:12.0524 (UTC) FILETIME=[4C6AD0C0:01C349DB] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Robert, > Up to now I think we have been discussing multihoming rather = implicitly, > as something which - along with IP or higher layer mobility - can = cause > the general problem that the relationship between application-layer = session=20 > and [micro]flow to be more than just a simple 1:1 relationship. That's = what > the session identifier functionality is about. >=20 > However, I don't see that the NTLP should have a role in trying to = 'solve' > the multihoming problem, because the correct solution almost certainly = > depends on the demands of the signalling application (at the moment, = the > framework assumes that handling IP address change is a signalling = application > responsibility, essentially for the same reason). The NTLP should = think > in terms of single flows defined by fixed N-tuples, and anything = cleverer has to > be pushed upstairs, IMHO. I agree. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 06:05:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04733 for ; Mon, 14 Jul 2003 06:05:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Cc-0007cF-4c for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 06:05:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EA52ll029273 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 06:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Cb-0007c1-L6; Mon, 14 Jul 2003 06:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0By-0007ae-75 for nsis@optimus.ietf.org; Mon, 14 Jul 2003 06:04:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04705 for ; Mon, 14 Jul 2003 06:04:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0Bu-0003c3-00 for nsis@ietf.org; Mon, 14 Jul 2003 06:04:18 -0400 Received: from bay8-f52.bay8.hotmail.com ([64.4.27.52] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19c0Bt-0003bj-00 for nsis@ietf.org; Mon, 14 Jul 2003 06:04:17 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Jul 2003 03:03:48 -0700 Received: from 81.160.141.224 by by8fd.bay8.hotmail.msn.com with HTTP; Mon, 14 Jul 2003 10:03:47 GMT X-Originating-IP: [81.160.141.224] X-Originating-Email: [hannestschofenig@hotmail.com] From: "Hannes Tschofenig" To: hgs@cs.columbia.edu Cc: nsis@ietf.org Subject: Re: [NSIS] ntlp security thoughts Date: Mon, 14 Jul 2003 12:03:47 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jul 2003 10:03:48.0079 (UTC) FILETIME=[37ECE7F0:01C349EF] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA04706 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi henning, >From: Henning Schulzrinne >To: Hannes Tschofenig >CC: nsis@ietf.org >Subject: Re: [NSIS] ntlp security thoughts >Date: Sun, 13 Jul 2003 10:34:53 -0400 > >Hannes Tschofenig wrote: > > >>that's certainly true although it is not simple for the following reaso= ns: >>a) i would need more information on the ntlp behavior with regard to th= e=20 >>nslp. >>(e.g. would you delete nslp state if you receive an ntlp "teardown"=20 >>message) > >I can't see how you can have free-floating NSLP state. This may be=20 >proposal-specific, but my assumption was that NTLP state is necessary fo= r=20 >NSLP state. I can't see any disadvantages of this approach, but others w= ill=20 >likely differ (but I would appreciate concrete benefits of allowing this= ,=20 >as it makes a lot of things far more complicated, in my view). > ok. an unprotected ntlp signaling message would then destroy nslp state=20 although you have protection at the nslp layer. > >>b) it might depend on certain nslps (and on the security of them) >>c) i would have to rate how harmful certain attacks are >>e.g. is flooding (dos) more serious than transmitting a bogus terminate= =20 >>signaling message? > >I would only suggest classifying this on a per-attack basis, not=20 >generically. > >>i can, however, try it. > >Clearly, in some cases the answer is going to be "it depends". > >>e.g. deleting state information based on a bogus "teardown" message is=20 >>problematic. >>possible solution: do not support such a message (use soft-state timeou= t=20 >>only) > >This is not a viable option, I'm afraid. If we can't agree on that withi= n=20 >the working group, we have far bigger problems than worrying about DOS=20 >attacks, since there won't be any service to deny. sounds good to me. that's a "solution" discussion. > >>that is certainly possible but the usage of public key cryptography=20 >>creates dos attack vulnerabilities. > >Unless this has changed, I thought there was some agreement that we will= =20 >need CMS-style PK at NSLP layer since none of the other solutions scale=20 >cross-domain. that's true. however, this type of protection was in addition to the used= =20 peer-to-peer protection. hence the dos protection is already there. in addition you might want to establish symmetric keys based on an initia= l=20 pk-based roundtrip for usage with cms as proposed for diameter. Is there another proposal, leaving >optimizations for specific scenarios aside? I don't think we can make=20 >progress if we don't admit to certain realities, even if we disagree how= =20 >often they are needed. Maybe we need to hum on such a list such as: > >- some applications will need PK crypto at NSLP layer >- some applications will need reliable message delivery >- some messages are going to exceed 500 bytes >etc. sounds ok to me. > >> >>what prevents an adversary from flooding an nsis node with bogus (rando= mly=20 >>generated) messages? >>they cause the nsis node to verify the digital signature. > >Nothing. But that's where, say, return-routability allows me to throttle= a=20 >particular host (attacker) and limit the ability of one attacker to caus= e=20 >damage. You just stick each peer into its own queue and serve them=20 >round-robin. That way, an attacker has to compromise lots of hosts to be= =20 >effective. to prevent dos attacks you commonly add an additional roundtrip. however,= =20 certain message handling in, for example, rsvp does not allow this=20 procedure. you need to tailor your proposal to support this functionality. > > >> >>additionally messages get large (certificates, digital signature etc.). > >Yes, about 5 KB, at minimum, to be precise. Such is life :-) > >>a mobile node at the wireless link can create messages (and he would se= e=20 >>the response). the return-routability makes it more difficult to mount = the=20 >>attacks (since the adversary has to wait for the response) but does not= =20 >>prevent it. > >You are assuming that the wireless link is unprotected. One would hope t= hat=20 >this is a temporary condition that only afflicts certain current=20 >implementations. I believe that 3G networks, for example, don't suffer f= rom=20 >this problem. hopefully it will be protected in the near future. it is, however, diffic= ult=20 to make some assumptions here which are based on architectural decisions. i mentioned that there are some possible interactions with network access= =20 authentication. > >>>small Caribbean Island where the local telco has a cozy relationship w= ith=20 >>>the attacker. >> >> >>good idea - sounds like a interesting application :-) > >Can one file a business method patent on how to defraud people? > ...already writing.... ciao hannes >Henning > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _________________________________________________________________ Mit dem MSN Messenger eine Reise f=FCr 4 Personen nach Barcelona gewinnen= =96=20 jetzt mitmachen! http://www.sweepstakes2003.com/entry.aspx?locationid=3D1= 5 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 08:16:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14565 for ; Mon, 14 Jul 2003 08:16:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2FO-0001Vo-2U for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 08:16:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ECG2Fl005795 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 08:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2FN-0001VH-1f; Mon, 14 Jul 2003 08:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2Ez-0001Uf-Gv for nsis@optimus.ietf.org; Mon, 14 Jul 2003 08:15:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14542 for ; Mon, 14 Jul 2003 08:15:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c2Ey-0006G5-00 for nsis@ietf.org; Mon, 14 Jul 2003 08:15:36 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19c2Ex-0006G2-00 for nsis@ietf.org; Mon, 14 Jul 2003 08:15:35 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6ECFTkM009356; Mon, 14 Jul 2003 08:15:29 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6ECFTk04278; Mon, 14 Jul 2003 08:15:29 -0400 Message-ID: <3F129DEA.6070309@cs.columbia.edu> Date: Mon, 14 Jul 2003 08:11:22 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig CC: nsis@ietf.org Subject: Re: [NSIS] ntlp security thoughts References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hannes Tschofenig wrote: > ok. an unprotected ntlp signaling message would then destroy nslp state > although you have protection at the nslp layer. The only alternative I can see that NTLP state isn't removed until NSLP state is, but this doesn't work for the case of NTLP-only nodes. > sounds good to me. that's a "solution" discussion. We need to constrain the problem space - it's big enough as is solving "real" problems. > that's true. however, this type of protection was in addition to the > used peer-to-peer protection. hence the dos protection is already there. Peer-to-peer at NTLP or NSLP layer? > > in addition you might want to establish symmetric keys based on an > initial pk-based roundtrip for usage with cms as proposed for diameter. Yes, for state updates (and teardowns) this makes sense. However, I think peer-to-peer node (rather than session) tends to scale better, given that many signaling sessions may well be relatively short and the initial denial-of-service problem. > to prevent dos attacks you commonly add an additional roundtrip. > however, certain message handling in, for example, rsvp does not allow > this procedure. you need to tailor your proposal to support this > functionality. Indeed; this seems to be one of the fundamental trade-offs. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 10:38:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25120 for ; Mon, 14 Jul 2003 10:38:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4So-0000mY-Pg for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 10:38:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EEc2LR002989 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 10:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Sn-0000m6-J8; Mon, 14 Jul 2003 10:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Sj-0000lu-0O for nsis@optimus.ietf.org; Mon, 14 Jul 2003 10:37:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25060 for ; Mon, 14 Jul 2003 10:37:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4Sg-0000gA-00 for nsis@ietf.org; Mon, 14 Jul 2003 10:37:54 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19c4Sf-0000g6-00 for nsis@ietf.org; Mon, 14 Jul 2003 10:37:53 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6EEbmcM015017 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jul 2003 10:37:49 -0400 (EDT) From: "Charles Q. Shen" To: , Date: Mon, 14 Jul 2003 10:37:45 -0400 Organization: Columbia University Message-ID: <000201c34a15$7e703f80$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [NSIS] Presentation Slides Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John, The text conferencing does not seem to be running. Could you please put the presentation slides online? Thanks. Charles > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of john.loughney@nokia.com > Sent: Monday, July 14, 2003 3:41 AM > To: robert.hancock@roke.co.uk; nsis@ietf.org > Subject: RE: [NSIS] Review of NTLP proposals > > > Hi Robert, > > > Up to now I think we have been discussing multihoming rather > > implicitly, as something which - along with IP or higher layer > > mobility - can cause the general problem that the > relationship between > > application-layer session and [micro]flow to be more than just a > > simple 1:1 relationship. That's what the session identifier > > functionality is about. > > > > However, I don't see that the NTLP should have a role in trying to > > 'solve' the multihoming problem, because the correct > solution almost > > certainly depends on the demands of the signalling > application (at the > > moment, the framework assumes that handling IP address change is a > > signalling application responsibility, essentially for the same > > reason). The NTLP should think in terms of single flows defined by > > fixed N-tuples, and anything cleverer has to be pushed > upstairs, IMHO. > > I agree. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 10:40:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25365 for ; Mon, 14 Jul 2003 10:40:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Uj-0000z7-Cs for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 10:40:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EEe15i003770 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 10:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Uj-0000yi-8Q; Mon, 14 Jul 2003 10:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Tl-0000t4-8L for nsis@optimus.ietf.org; Mon, 14 Jul 2003 10:39:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25228 for ; Mon, 14 Jul 2003 10:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4Ti-0000iK-00 for nsis@ietf.org; Mon, 14 Jul 2003 10:38:59 -0400 Received: from chicory.cc.columbia.edu ([128.59.59.211] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19c4Ti-0000iC-00 for nsis@ietf.org; Mon, 14 Jul 2003 10:38:58 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by chicory.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6EEctf5028984 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jul 2003 10:38:55 -0400 (EDT) From: "Charles Q. Shen" To: , Date: Mon, 14 Jul 2003 10:38:52 -0400 Organization: Columbia University Message-ID: <000301c34a15$a638e120$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [NSIS] Presentation Slides Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John, The text conferencing does not seem to be running. Could you please put the presentation slides online? Thanks. Charles > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of john.loughney@nokia.com > Sent: Monday, July 14, 2003 3:41 AM > To: robert.hancock@roke.co.uk; nsis@ietf.org > Subject: RE: [NSIS] Review of NTLP proposals > > > Hi Robert, > > > Up to now I think we have been discussing multihoming rather > > implicitly, as something which - along with IP or higher layer > > mobility - can cause the general problem that the > relationship between > > application-layer session and [micro]flow to be more than just a > > simple 1:1 relationship. That's what the session identifier > > functionality is about. > > > > However, I don't see that the NTLP should have a role in trying to > > 'solve' the multihoming problem, because the correct > solution almost > > certainly depends on the demands of the signalling > application (at the > > moment, the framework assumes that handling IP address change is a > > signalling application responsibility, essentially for the same > > reason). The NTLP should think in terms of single flows defined by > > fixed N-tuples, and anything cleverer has to be pushed > upstairs, IMHO. > > I agree. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 12:50:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03803 for ; Mon, 14 Jul 2003 12:50:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6WY-0000zt-AC for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 12:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EGo2LP003826 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 12:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6WY-0000zW-1j; Mon, 14 Jul 2003 12:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6WH-0000wA-SA for nsis@optimus.ietf.org; Mon, 14 Jul 2003 12:49:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03732 for ; Mon, 14 Jul 2003 12:49:41 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c6WB-0002oS-00 for nsis@ietf.org; Mon, 14 Jul 2003 12:49:39 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19c6WB-0002oL-00 for nsis@ietf.org; Mon, 14 Jul 2003 12:49:39 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6EGnbk14206 for ; Mon, 14 Jul 2003 19:49:38 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 14 Jul 2003 19:49:37 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 19:49:36 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 19:49:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jul 2003 19:49:36 +0300 Message-ID: Thread-Topic: [NSIS] ntlp security thoughts Thread-Index: AcNJ73N6n8mqL7H/SG2g93JkW7dykgANhWnw To: X-OriginalArrivalTime: 14 Jul 2003 16:49:36.0500 (UTC) FILETIME=[E8B71B40:01C34A27] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Reliable Transport for NTLP Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi All, At today's meeting, Melinda pointed out that in her opinion, reliable = transport is not required for NTLP. R=FCdiger seemed to indicate that there is = not a significant cost to NTLP. Unfortunately, there has been no working = group consensus that NTLP will be using reliable transport. Also, I feel that R=FCdiger behavior was inappropriate for a professional meeting. I = should have asked R=FCdiger to display more professional courtesy at the mic. However, my point is that the WG has not come to agreement that NTLP should use reliable transport. In fact, there is a significant cost, in my opinion, in terms of setup time & latency. I will outline a = scenario. Two end hosts, A & B, need to setup some signaling between them. If TCP is used as a transport, it is not a simple 3 way handshake that is=20 needed. If A & B are x NTLP hops away, they will need x TCP connections, which, depending upon implementation, will result a 3 way handshake=20 between x+1 nodes, which is a significant problem. In addition, needing to setup TCP connections during fast mobility can also be a problem. My point is that I do not see the requirement for reliable transport in NTLP. If there are parties interested in using reliable transport, the burden of proof is with them. =20 Please note, that Henning has proposed that there may be some = advantageous of using a partially reliable transport mechanism, however, I think he has planned on providing more details to the list of how this could be achieved, as it was not completely specified in his draft. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 13:44:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07886 for ; Mon, 14 Jul 2003 13:44:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Mn-0004Wl-8u for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 13:44:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHi1xX017396 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 13:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Mn-0004WU-4w; Mon, 14 Jul 2003 13:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Mm-0004WJ-5v for nsis@optimus.ietf.org; Mon, 14 Jul 2003 13:44:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07866 for ; Mon, 14 Jul 2003 13:43:57 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Mk-0003r3-00 for nsis@ietf.org; Mon, 14 Jul 2003 13:43:58 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19c7Mj-0003qy-00 for nsis@ietf.org; Mon, 14 Jul 2003 13:43:57 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6EHhua03064 for ; Mon, 14 Jul 2003 20:43:56 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 20:43:56 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 20:43:56 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 20:43:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] comments on NTLP design proposals Date: Mon, 14 Jul 2003 20:43:51 +0300 Message-ID: Thread-Topic: [NSIS] comments on NTLP design proposals Thread-Index: AcNIs2M8cPDVmURPRtKT5DkwEZ1bEQBe6ehA To: Cc: , X-OriginalArrivalTime: 14 Jul 2003 17:43:55.0065 (UTC) FILETIME=[7EF8AA90:01C34A2F] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Henning, > > Using a fully reliable transport option as a starting point requires = > > proof that reliable transport is needed. I have yet to see good > > justification that a relaible transport is required. My gut feeling = is that > > we start with a connectionless protocol and see how & if a = connection-oriented > > protocol can be supported. >=20 > That sounds familiar... I think this discussion would be helped if the = > word "reliable" is made a bit more precise. Perhaps it would make more sense if we just were just direct. TCP/SCTP provides connection-oriented functionality + retransmission. It = provides congestion control. It requires a 3 way handshake. =20 For some trivial NSLP applications, retransmission & congestion control are probably not required, so in that sense, TCP would be overkill. =20 John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 13:58:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09160 for ; Mon, 14 Jul 2003 13:58:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7aL-0005TQ-52 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 13:58:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHw1EY021033 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 13:58:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7aK-0005T8-UB; Mon, 14 Jul 2003 13:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Zi-0005SC-MY for nsis@optimus.ietf.org; Mon, 14 Jul 2003 13:57:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09089 for ; Mon, 14 Jul 2003 13:57:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Zg-0004BD-00 for nsis@ietf.org; Mon, 14 Jul 2003 13:57:20 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19c7Zf-0004Am-00 for nsis@ietf.org; Mon, 14 Jul 2003 13:57:19 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSK1MY4>; Mon, 14 Jul 2003 18:56:44 +0100 Message-ID: From: "Hancock, Robert" To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Reliable Transport for NTLP Date: Mon, 14 Jul 2003 18:56:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable john, i don't think there is anyone arguing at the moment that *all*=20 signalling should be sent reliably. so, i'm assuming the question on the table is: a) should the NTLP provide only a single-shot message delivery attempt (you-the-NSLP don't get any feedback on whether it worked,=20 if you-the-NSLP want an acknowledgement you must get it from your peer NSLP) OR b) should the NTLP also provide a service which allows an NSLP to say "get this particular message to my peer or tell me if you can't" I can imagine doing a cost/benefit analysis of having (a) only vs. having (b) as well. I can't imagine doing a _proof_ (since there is no standard of proof to apply), but at least having a clear question would be a start. cheers, robert h. PS Incidentally, if we drop all reliability from the NTLP, drop=20 bundling from the NTLP (as Melinda suggested), and drop refresh reduction from the NTLP (as I believe it's a signalling application function), would we still claim as a WG that we=20 are using 2205+2961 as a starting point? > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, July 14, 2003 18:50 > To: nsis@ietf.org > Subject: [NSIS] Reliable Transport for NTLP >=20 >=20 > Hi All, >=20 > At today's meeting, Melinda pointed out that in her opinion,=20 > reliable transport > is not required for NTLP. R=FCdiger seemed to indicate that=20 > there is not a > significant cost to NTLP. Unfortunately, there has been no=20 > working group > consensus that NTLP will be using reliable transport. Also,=20 > I feel that > R=FCdiger behavior was inappropriate for a professional=20 > meeting. I should have > asked R=FCdiger to display more professional courtesy at the mic. >=20 > However, my point is that the WG has not come to agreement that NTLP > should use reliable transport. In fact, there is a significant cost, > in my opinion, in terms of setup time & latency. I will=20 > outline a scenario. > Two end hosts, A & B, need to setup some signaling between=20 > them. If TCP > is used as a transport, it is not a simple 3 way handshake that is=20 > needed. If A & B are x NTLP hops away, they will need x TCP=20 > connections, > which, depending upon implementation, will result a 3 way handshake=20 > between x+1 nodes, which is a significant problem. In=20 > addition, needing > to setup TCP connections during fast mobility can also be a problem. >=20 > My point is that I do not see the requirement for reliable transport > in NTLP. If there are parties interested in using reliable = transport, > the burden of proof is with them. =20 >=20 > Please note, that Henning has proposed that there may be some=20 > advantageous > of using a partially reliable transport mechanism, however, I think > he has planned on providing more details to the list of how this = could > be achieved, as it was not completely specified in his draft. >=20 > John >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 14:14:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10070 for ; Mon, 14 Jul 2003 14:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7pq-0006gi-6H for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIE23M025700 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7pq-0006gQ-1P; Mon, 14 Jul 2003 14:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7pN-0006fg-HD for nsis@optimus.ietf.org; Mon, 14 Jul 2003 14:13:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09963 for ; Mon, 14 Jul 2003 14:13:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7pL-0004Nh-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:13:31 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19c7pK-0004Nd-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:13:30 -0400 Received: from cs.uni-goettingen.de ([::ffff:81.160.249.12]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 14 Jul 2003 20:13:37 +0200 Message-ID: <3F12F2CA.7050300@cs.uni-goettingen.de> Date: Mon, 14 Jul 2003 20:13:30 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] mobility-related requirements from nsis-req-08 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, As John suggested, I tried to sort out requirements (out of nsis-req-08) which are related to mobility and hope they helpful for related discussions: 5.2 Signaling Flows...............................................10 5.2.2 NSIS MUST support path-coupled and MAY support path-decoupled signaling.........................................................11 ==> relates to different handling of MIP IP-in-IP encapsulation (tunnel). 5.3 Messaging.....................................................11 5.3.1 Explicit erasure of state MUST be possible..................12 ==> related to explicit teardown of obsoleted branch. Maybe a flag to indicate whether to do explicit teardown. 5.4 Control Information...........................................13 5.4.3 State MUST be addressed independent of flow identification..14 ==> mobility support may make use of this requirement. 5.5 Performance...................................................15 5.5.1 Scalability.................................................15 ==> NSIS "MUST be scalable in number of hand-offs in mobile environments." This can be related to, e.g., capability of dealing with pingpong, fast movement. 5.6 Flexibility...................................................16 5.6.2 Flexibility in the placement of the NSIS Initiator/Responder16 ==> somehow related to the issue of either MN or CN as data sender. 5.8 Mobility......................................................19 5.8.1 Allow efficient service re-establishment after handover.....19 ==> effectively establish states in new path due to handover. 5.9 Interworking with other protocols and techniques..............19 5.9.1 MUST interwork with IP tunneling............................19 ==> IP-in-IP encapsulation is one type of IP tunnels 5.9.2 MUST NOT constrain either to IPv4 or IPv6...................19 ==> should be able to work with both Mobile IPv4 protocols and Mobile IPv6 protocols. 5.9.5 SHOULD work with seamless handoff protocols.................20 ==> e.g., CTP Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 14:20:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10970 for ; Mon, 14 Jul 2003 14:20:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7vd-0007O8-NO for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:20:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIK1LQ028376 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:20:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7vd-0007NZ-B2; Mon, 14 Jul 2003 14:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7uj-0007Hp-R6 for nsis@optimus.ietf.org; Mon, 14 Jul 2003 14:19:05 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10855 for ; Mon, 14 Jul 2003 14:19:02 -0400 (EDT) Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6EIJ3kM021451; Mon, 14 Jul 2003 14:19:03 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6EIJ2g24552; Mon, 14 Jul 2003 14:19:02 -0400 Message-ID: <3F12F31F.4070408@cs.columbia.edu> Date: Mon, 14 Jul 2003 14:14:55 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: robert.hancock@roke.co.uk, nsis@ietf.org Subject: Re: [NSIS] comments on NTLP design proposals References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: >>That sounds familiar... I think this discussion would be helped if the >>word "reliable" is made a bit more precise. > > > Perhaps it would make more sense if we just were just direct. TCP/SCTP > provides connection-oriented functionality + retransmission. It provides > congestion control. It requires a 3 way handshake. > > For some trivial NSLP applications, retransmission & congestion control > are probably not required, so in that sense, TCP would be overkill. I think we're in agreement on this part; that understanding certainly informed my strawman. The only issue I raised in my presentation was whether that choice is made per-NSLP, per-hop or some combination. I'm not sure if others are disagreeing with that part of the discussion, but my reading is that most of those arguing for reliability don't see this as a "must always be used" issue. I also happen to think that some NSLP applications will not work well or be severely constrained if such a reliable mode is not available (without being forced on those NSLPs who do not need it). Do you agree with that statement? Also, since this seems to be common argument: the 3-way handshake overhead is not incurred with every session setup. It is only incurred, at least in the low fan-out cases I can think, once per peer. Thus, most sessions will never see that overhead. (They will still see the additional roundtrip time of finding the next hop.) We should also acknowledge, however, that one-message setup has potentially severe denial-of-service implications, as discussed in the context of Hanne' recent message. In general, I think it would be helpful to see this as an interconnected issue. Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 14:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12307 for ; Mon, 14 Jul 2003 14:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c89C-00006a-9A for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:34:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIY2Pt000400 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c89B-00006L-EK; Mon, 14 Jul 2003 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c895-000069-To for nsis@optimus.ietf.org; Mon, 14 Jul 2003 14:33:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12254 for ; Mon, 14 Jul 2003 14:33:52 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c893-0004xG-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:33:53 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19c892-0004xA-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:33:52 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6EIXpa04745 for ; Mon, 14 Jul 2003 21:33:51 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 21:33:50 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 21:33:49 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 21:33:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] comments on NTLP design proposals Date: Mon, 14 Jul 2003 21:33:48 +0300 Message-ID: Thread-Topic: [NSIS] comments on NTLP design proposals Thread-Index: AcNKNJKroF2t7nGtQOqzNQovUNAzEgAAeIDA To: Cc: , X-OriginalArrivalTime: 14 Jul 2003 18:33:49.0526 (UTC) FILETIME=[77CF2760:01C34A36] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Robert, > i don't think there is anyone arguing at the moment that *all*=20 > signalling should be sent reliably. Several people have come across as stating that, R=FCdiger's comment struck me as if he was of this opinion, for exampl =20 > so, i'm assuming the question on the table is: >=20 > a) should the NTLP provide only a single-shot message delivery > attempt (you-the-NSLP don't get any feedback on whether it worked,=20 > if you-the-NSLP want an acknowledgement you must get it from > your peer NSLP) >=20 > OR >=20 > b) should the NTLP also provide a service which allows an NSLP to > say "get this particular message to my peer or tell me if you > can't" My opinion is that a basic raw-IP / UDP mode is supported by default and we look at how TCP/SCTP could be supported without running into state bloat caused by multiple protocol support. It does not need to be a either / or question. =20 > I can imagine doing a cost/benefit analysis of having (a) only > vs. having (b) as well. I can't imagine doing a _proof_ (since there > is no standard of proof to apply), but at least having a clear > question would be a start. Proof in engineering terms is often quite different than in mathmatical terms. Proof, in my usage, is nearly equivalent to a strong argument that gains consensus. > PS Incidentally, if we drop all reliability from the NTLP, drop=20 > bundling from the NTLP (as Melinda suggested), and drop refresh > reduction from the NTLP (as I believe it's a signalling > application function), would we still claim as a WG that we=20 > are using 2205+2961 as a starting point? I think we can consider how much of 2205 + 2961 needs to be supported. I have not suggested, myself, dropping all of 2961, but to look at=20 what to support. 2961 lists the following enhancements to RSVP: RSVP Bundle Message MESSAGE_ID Extension=20 Summary Refresh Extension=20 Exponential Back-Off Procedures=20 The Exponential Back-Off Procedures is probably not needed. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 14:37:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12603 for ; Mon, 14 Jul 2003 14:37:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8C5-0000FB-R6 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:37:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIb1Xp000936 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8C5-0000F0-MY; Mon, 14 Jul 2003 14:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8B9-0000E5-Bm for nsis@optimus.ietf.org; Mon, 14 Jul 2003 14:36:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12469 for ; Mon, 14 Jul 2003 14:35:59 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8B6-00050C-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:36:00 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19c8B5-000508-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:35:59 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6EIZwk26539 for ; Mon, 14 Jul 2003 21:35:58 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 21:35:58 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 21:35:57 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 21:35:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] comments on NTLP design proposals Date: Mon, 14 Jul 2003 21:35:56 +0300 Message-ID: Thread-Topic: [NSIS] comments on NTLP design proposals Thread-Index: AcNKNJKroF2t7nGtQOqzNQovUNAzEgAAfarA To: Cc: , X-OriginalArrivalTime: 14 Jul 2003 18:35:56.0741 (UTC) FILETIME=[C3A29F50:01C34A36] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Henning, I basically agree with your text, I just wanted to add clarifying text - as I was unsure of the intention of some of the comments today. John > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 14 July, 2003 21:15 > To: Loughney John (NRC/Helsinki) > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > Subject: Re: [NSIS] comments on NTLP design proposals >=20 >=20 > john.loughney@nokia.com wrote: >=20 > >>That sounds familiar... I think this discussion would be=20 > helped if the=20 > >>word "reliable" is made a bit more precise. > >=20 > >=20 > > Perhaps it would make more sense if we just were just=20 > direct. TCP/SCTP > > provides connection-oriented functionality +=20 > retransmission. It provides > > congestion control. It requires a 3 way handshake. =20 > >=20 > > For some trivial NSLP applications, retransmission &=20 > congestion control > > are probably not required, so in that sense, TCP would be=20 > overkill. =20 >=20 > I think we're in agreement on this part; that understanding certainly=20 > informed my strawman. The only issue I raised in my presentation was=20 > whether that choice is made per-NSLP, per-hop or some combination. >=20 > I'm not sure if others are disagreeing with that part of the = discussion,=20 > but my reading is that most of those arguing for reliability don't see = > this as a "must always be used" issue. >=20 > I also happen to think that some NSLP applications will not work well = or=20 > be severely constrained if such a reliable mode is not available=20 > (without being forced on those NSLPs who do not need it). Do you agree = > with that statement? >=20 > Also, since this seems to be common argument: the 3-way handshake=20 > overhead is not incurred with every session setup. It is only = incurred,=20 > at least in the low fan-out cases I can think, once per peer. Thus, = most=20 > sessions will never see that overhead. (They will still see the=20 > additional roundtrip time of finding the next hop.) >=20 > We should also acknowledge, however, that one-message setup has=20 > potentially severe denial-of-service implications, as discussed in the = > context of Hanne' recent message. >=20 > In general, I think it would be helpful to see this as an = interconnected=20 > issue. >=20 > Henning >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 14:38:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12721 for ; Mon, 14 Jul 2003 14:38:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8D3-0000b0-Dw for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:38:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIc1PT002028 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8D2-0000WT-G5; Mon, 14 Jul 2003 14:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8CR-0000Qv-N4 for nsis@optimus.ietf.org; Mon, 14 Jul 2003 14:37:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12598 for ; Mon, 14 Jul 2003 14:37:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8CP-000521-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:37:21 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19c8CO-00051y-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:37:20 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6EIbKkM024579; Mon, 14 Jul 2003 14:37:20 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6EIbJg26351; Mon, 14 Jul 2003 14:37:19 -0400 Message-ID: <3F12F768.3060804@cs.columbia.edu> Date: Mon, 14 Jul 2003 14:33:12 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi All, > > > However, my point is that the WG has not come to agreement that NTLP > should use reliable transport. In fact, there is a significant cost, > in my opinion, in terms of setup time & latency. I will outline a scenario. > Two end hosts, A & B, need to setup some signaling between them. If TCP > is used as a transport, it is not a simple 3 way handshake that is > needed. If A & B are x NTLP hops away, they will need x TCP connections, > which, depending upon implementation, will result a 3 way handshake > between x+1 nodes, which is a significant problem. In addition, needing > to setup TCP connections during fast mobility can also be a problem. John, this is simply not true and has not been true in all of these discussions. There has always been the assumption that connections are, on average, already established since the number of peers in most cases is bounded. There is no need to start from scratch for every session. > > My point is that I do not see the requirement for reliable transport > in NTLP. If there are parties interested in using reliable transport, > the burden of proof is with them. I'm not sure what the threshold of "proof" is. I thought we had extensive, but inconclusive, discussions on how to address fragmentation, flow control and congestion control in NTLP. > > Please note, that Henning has proposed that there may be some advantageous > of using a partially reliable transport mechanism, however, I think > he has planned on providing more details to the list of how this could > be achieved, as it was not completely specified in his draft. Without trying to write a draft on the fly, here's the simple outline. I really need a whiteboard here. There are three choices: 1) one message, no reliability: just forward and have NSLP or e2e retransmission; subject to security issues such as DOS attacks, but quick and low overhead. 2) one message pair per hop: adds reliability, but no delay. Doesn't address DOS issues completely. 3) one message pair per hop + reliable protocol for large messages: adds reliability; adds delay for large signaling message. Addresses DOS issues better and. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 14:43:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13159 for ; Mon, 14 Jul 2003 14:43:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8Ht-00018Q-UU for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:43:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIh1lu004358 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8Ht-00017m-D1; Mon, 14 Jul 2003 14:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8HX-00017M-UQ for nsis@optimus.ietf.org; Mon, 14 Jul 2003 14:42:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13100 for ; Mon, 14 Jul 2003 14:42:36 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8HV-00059P-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:42:37 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19c8HU-00059J-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:42:36 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6EIgYk00643 for ; Mon, 14 Jul 2003 21:42:34 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 21:42:34 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 21:42:34 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 21:42:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Reliable Transport for NTLP Date: Mon, 14 Jul 2003 21:42:33 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNKNvxEycYPTtTHTf+r3Zae5S0sHAAACG3w To: Cc: X-OriginalArrivalTime: 14 Jul 2003 18:42:34.0193 (UTC) FILETIME=[B088FC10:01C34A37] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Henning, I just responded to Robert, but just to make sure we are clear, I will respond here: > > However, my point is that the WG has not come to agreement that NTLP > > should use reliable transport. In fact, there is a significant = cost, > > in my opinion, in terms of setup time & latency. I will outline a = scenario. > > Two end hosts, A & B, need to setup some signaling between them. If = TCP > > is used as a transport, it is not a simple 3 way handshake that is=20 > > needed. If A & B are x NTLP hops away, they will need x TCP = connections, > > which, depending upon implementation, will result a 3 way handshake=20 > > between x+1 nodes, which is a significant problem. In addition, = needing > > to setup TCP connections during fast mobility can also be a problem. >=20 > John, this is simply not true and has not been true in all of these=20 > discussions. There has always been the assumption that connections = are,=20 > on average, already established since the number of peers in most = cases=20 > is bounded. There is no need to start from scratch for every session. My example was to show that there is a trade-off with using TCP, it is not free. We can mitigate the effects with proper engineering, I agree. > > My point is that I do not see the requirement for reliable transport > > in NTLP. If there are parties interested in using reliable = transport, > > the burden of proof is with them.=20 >=20 > I'm not sure what the threshold of "proof" is. I thought we had=20 > extensive, but inconclusive, discussions on how to address=20 > fragmentation, flow control and congestion control in NTLP. I don't mean proof in a literal sense, but as a burden of proof, meaning that there needs to be a convincing argument. > > Please note, that Henning has proposed that there may be=20 > some advantageous > > of using a partially reliable transport mechanism, however, I think > > he has planned on providing more details to the list of how=20 > this could > > be achieved, as it was not completely specified in his draft. >=20 > Without trying to write a draft on the fly, here's the simple outline. = > I really need a whiteboard here. There are three choices: >=20 > 1) one message, no reliability: just forward and have NSLP or e2e=20 > retransmission; subject to security issues such as DOS attacks, but=20 > quick and low overhead. >=20 > 2) one message pair per hop: adds reliability, but no delay. Doesn't=20 > address DOS issues completely. >=20 > 3) one message pair per hop + reliable protocol for large messages: = adds=20 > reliability; adds delay for large signaling message. Addresses DOS=20 > issues better and. As we discussed earlier, I think this looks like the way to go to handle reliable transport, rather than turn it into an either / or debate. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 14:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14202 for ; Mon, 14 Jul 2003 14:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8RZ-00022e-7G for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:53:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIr1gq007831 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 14:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8RY-00022C-Vz; Mon, 14 Jul 2003 14:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8RG-00021p-De for nsis@optimus.ietf.org; Mon, 14 Jul 2003 14:52:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14143 for ; Mon, 14 Jul 2003 14:52:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8RD-0005QR-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:52:39 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19c8RC-0005QL-00 for nsis@ietf.org; Mon, 14 Jul 2003 14:52:39 -0400 Received: from cs.uni-goettingen.de ([::ffff:81.160.249.12]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 14 Jul 2003 20:52:46 +0200 Message-ID: <3F12FBF7.7000305@cs.uni-goettingen.de> Date: Mon, 14 Jul 2003 20:52:39 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Modeling of mobility? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Do you think it is useful to have a general modeling of data path features caused by (or, "related to") mobility? Examples: - independence of specific mobility protocols - IP-in-IP encasulation/tunnel - local repair & synchronization - even, anticipated handovers Cheers, Xiaoming PS. I've made the slides "mobility support in NSIS" online at: http://user.informatik.uni-goettingen.de/~fu/nsis/IETF-fu-nsis-mobility.pdf _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 15:04:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15306 for ; Mon, 14 Jul 2003 15:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8cD-0002SV-Ap for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 15:04:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EJ417d009444 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 15:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8cC-0002SD-SR; Mon, 14 Jul 2003 15:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8bq-0002RT-27 for nsis@optimus.ietf.org; Mon, 14 Jul 2003 15:03:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15162 for ; Mon, 14 Jul 2003 15:03:34 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8bn-0005fo-00 for nsis@ietf.org; Mon, 14 Jul 2003 15:03:35 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19c8bm-0005fl-00 for nsis@ietf.org; Mon, 14 Jul 2003 15:03:34 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6EJ3Xk13334 for ; Mon, 14 Jul 2003 22:03:33 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 22:03:33 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 22:03:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 22:03:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] mobility-related requirements from nsis-req-08 Date: Mon, 14 Jul 2003 22:03:12 +0300 Message-ID: Thread-Topic: [NSIS] mobility-related requirements from nsis-req-08 Thread-Index: AcNKM7uighxYBpsARFiHO0m1xAzL+QABs2rw To: , X-OriginalArrivalTime: 14 Jul 2003 19:03:30.0256 (UTC) FILETIME=[9D34FD00:01C34A3A] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Xiaoming, I think it is premature to do this at the moment - the framework document & the analysis document cover some mobility issues -=20 you should contact the author of those doucments to see what overlap, if any, there is between your proposal and those documents. John > -----Original Message----- > From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: 14 July, 2003 21:14 > To: nsis@ietf.org > Subject: [NSIS] mobility-related requirements from nsis-req-08 >=20 >=20 > Hi all, >=20 > As John suggested, I tried to sort out requirements (out of=20 > nsis-req-08)=20 > which are related to mobility and hope they helpful for=20 > related discussions: >=20 > 5.2 Signaling=20 > Flows...............................................10 > 5.2.2 NSIS MUST support path-coupled and MAY support=20 > path-decoupled > =20 > signaling.........................................................11 > =3D=3D> relates to different handling of MIP IP-in-IP=20 > encapsulation (tunnel). >=20 > 5.3=20 > Messaging.....................................................11 > 5.3.1 Explicit erasure of state MUST be=20 > possible..................12 > =3D=3D> related to explicit teardown of obsoleted branch. Maybe a flag = to=20 > indicate whether to do explicit teardown. >=20 > 5.4 Control=20 > Information...........................................13 > 5.4.3 State MUST be addressed independent of flow=20 > identification..14 > =3D=3D> mobility support may make use of this requirement. >=20 > 5.5=20 > Performance...................................................15 > 5.5.1=20 > Scalability.................................................15 > =3D=3D> NSIS "MUST be scalable in number of hand-offs in mobile=20 > environments." This can be related to, e.g., capability of=20 > dealing with=20 > pingpong, fast movement. >=20 > 5.6=20 > Flexibility...................................................16 > 5.6.2 Flexibility in the placement of the NSIS=20 > Initiator/Responder16 > =3D=3D> somehow related to the issue of either MN or CN as data = sender. >=20 > 5.8=20 > Mobility......................................................19 > 5.8.1 Allow efficient service re-establishment after=20 > handover.....19 > =3D=3D> effectively establish states in new path due to handover. >=20 > 5.9 Interworking with other protocols and=20 > techniques..............19 > 5.9.1 MUST interwork with IP=20 > tunneling............................19 > =3D=3D> IP-in-IP encapsulation is one type of IP tunnels >=20 > 5.9.2 MUST NOT constrain either to IPv4 or=20 > IPv6...................19 > =3D=3D> should be able to work with both Mobile IPv4 protocols and = Mobile=20 > IPv6 protocols. >=20 > 5.9.5 SHOULD work with seamless handoff=20 > protocols.................20 > =3D=3D> e.g., CTP >=20 > Cheers, > Xiaoming >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 15:48:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20329 for ; Mon, 14 Jul 2003 15:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9In-0005uK-SQ for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 15:48:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EJm1pQ022698 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 15:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9In-0005tV-1u; Mon, 14 Jul 2003 15:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9IU-0005tE-6k for nsis@optimus.ietf.org; Mon, 14 Jul 2003 15:47:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20256 for ; Mon, 14 Jul 2003 15:47:39 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9IS-0006dP-00 for nsis@ietf.org; Mon, 14 Jul 2003 15:47:40 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19c9IR-0006dC-00 for nsis@ietf.org; Mon, 14 Jul 2003 15:47:39 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6EJlaa14640 for ; Mon, 14 Jul 2003 22:47:36 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 22:47:36 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 22:47:36 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 22:47:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Modeling of mobility? Date: Mon, 14 Jul 2003 22:47:35 +0300 Message-ID: Thread-Topic: [NSIS] Modeling of mobility? Thread-Index: AcNKOTBiEHQ4FP3hS/GZ9W4Q5Ps9RwAB2K9g To: , X-OriginalArrivalTime: 14 Jul 2003 19:47:35.0743 (UTC) FILETIME=[C60A44F0:01C34A40] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Xiaoming, You may like to bring this up at the MIPv6 Signaling and=20 Handoff Optimization BOF on Wednesday, as this sounds=20 somewhat out of scope for NSIS. John > -----Original Message----- > From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: 14 July, 2003 21:53 > To: nsis@ietf.org > Subject: [NSIS] Modeling of mobility? >=20 >=20 > Hi all, >=20 > Do you think it is useful to have a general modeling of data path=20 > features caused by (or, "related to") mobility? Examples: > - independence of specific mobility protocols > - IP-in-IP encasulation/tunnel > - local repair & synchronization > - even, anticipated handovers >=20 > Cheers, > Xiaoming >=20 > PS. I've made the slides "mobility support in NSIS" online at: > http://user.informatik.uni-goettingen.de/~fu/nsis/IETF-fu-nsis > -mobility.pdf >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 16:19:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22600 for ; Mon, 14 Jul 2003 16:19:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9mn-0007od-NH for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 16:19:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EKJ1KL030039 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 16:19:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9mm-0007oO-Mo; Mon, 14 Jul 2003 16:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9m6-0007o5-59 for nsis@optimus.ietf.org; Mon, 14 Jul 2003 16:18:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22523 for ; Mon, 14 Jul 2003 16:18:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9m4-0007AD-00 for nsis@ietf.org; Mon, 14 Jul 2003 16:18:16 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19c9m3-0007A9-00 for nsis@ietf.org; Mon, 14 Jul 2003 16:18:15 -0400 Received: from cs.uni-goettingen.de ([::ffff:81.160.249.12]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 14 Jul 2003 22:18:22 +0200 Message-ID: <3F131007.1060206@cs.uni-goettingen.de> Date: Mon, 14 Jul 2003 22:18:15 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, john.loughney@nokia.com wrote: > I think it is premature to do this at the moment - the framework > document & the analysis document cover some mobility issues - Yes, I was following your suggestion to complete my comments from these requirements' point of view which can help later mobility discussions, :-) > you should contact the author of those doucments to see what > overlap, if any, there is between your proposal and those > documents. I looked into these docs before submitting the I-D: they did cover general state management (e.g., session ID) and local repair issues; I'll talk with the authors on latest versions and their plans. Thanks, Xiaoming > > John > > >>-----Original Message----- >>From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] >>Sent: 14 July, 2003 21:14 >>To: nsis@ietf.org >>Subject: [NSIS] mobility-related requirements from nsis-req-08 >> >> >>Hi all, >> >>As John suggested, I tried to sort out requirements (out of >>nsis-req-08) >>which are related to mobility and hope they helpful for >>related discussions: >> >> 5.2 Signaling >>Flows...............................................10 >> 5.2.2 NSIS MUST support path-coupled and MAY support >>path-decoupled >> >>signaling.........................................................11 >>==> relates to different handling of MIP IP-in-IP >>encapsulation (tunnel). >> >> 5.3 >>Messaging.....................................................11 >> 5.3.1 Explicit erasure of state MUST be >>possible..................12 >>==> related to explicit teardown of obsoleted branch. Maybe a flag to >>indicate whether to do explicit teardown. >> >> 5.4 Control >>Information...........................................13 >> 5.4.3 State MUST be addressed independent of flow >>identification..14 >>==> mobility support may make use of this requirement. >> >> 5.5 >>Performance...................................................15 >> 5.5.1 >>Scalability.................................................15 >>==> NSIS "MUST be scalable in number of hand-offs in mobile >>environments." This can be related to, e.g., capability of >>dealing with >>pingpong, fast movement. >> >> 5.6 >>Flexibility...................................................16 >> 5.6.2 Flexibility in the placement of the NSIS >>Initiator/Responder16 >>==> somehow related to the issue of either MN or CN as data sender. >> >> 5.8 >>Mobility......................................................19 >> 5.8.1 Allow efficient service re-establishment after >>handover.....19 >>==> effectively establish states in new path due to handover. >> >> 5.9 Interworking with other protocols and >>techniques..............19 >> 5.9.1 MUST interwork with IP >>tunneling............................19 >>==> IP-in-IP encapsulation is one type of IP tunnels >> >> 5.9.2 MUST NOT constrain either to IPv4 or >>IPv6...................19 >>==> should be able to work with both Mobile IPv4 protocols and Mobile >>IPv6 protocols. >> >> 5.9.5 SHOULD work with seamless handoff >>protocols.................20 >>==> e.g., CTP >> >>Cheers, >>Xiaoming >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 16:28:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23259 for ; Mon, 14 Jul 2003 16:28:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9vV-0008LJ-5z for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 16:28:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EKS1Yo032052 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 16:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9vU-0008KS-S8; Mon, 14 Jul 2003 16:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9v9-0008Jy-D2 for nsis@optimus.ietf.org; Mon, 14 Jul 2003 16:27:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23200 for ; Mon, 14 Jul 2003 16:27:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9v7-0007Kr-00 for nsis@ietf.org; Mon, 14 Jul 2003 16:27:37 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19c9v6-0007Ko-00 for nsis@ietf.org; Mon, 14 Jul 2003 16:27:37 -0400 Received: from cs.uni-goettingen.de ([::ffff:81.160.249.12]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 14 Jul 2003 22:27:44 +0200 Message-ID: <3F13123A.5020407@cs.uni-goettingen.de> Date: Mon, 14 Jul 2003 22:27:38 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] Modeling of mobility? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, john.loughney@nokia.com wrote: > You may like to bring this up at the MIPv6 Signaling and > Handoff Optimization BOF on Wednesday, as this sounds > somewhat out of scope for NSIS. Well, I shall have mentioned more clearly, that doing such a characterizing is not going to do MIP signaling at all, but to use the route change _resulting from_ MIP signaling (what meant by "independent of any specific MIP signaling") and to signaling into IP-in-IP tunnels (what meant by "IP-in-IP encasulation/tunnel"). My thought was that if NSIS finally needs to work with mobility, this can be necessary in NSIS. Thanks, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 14 16:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23650 for ; Mon, 14 Jul 2003 16:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9zN-0000GQ-9I for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 16:32:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EKW1GG001004 for nsis-archive@odin.ietf.org; Mon, 14 Jul 2003 16:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9zN-0000G6-5Y; Mon, 14 Jul 2003 16:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9zK-0000Fs-Ha for nsis@optimus.ietf.org; Mon, 14 Jul 2003 16:31:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23589 for ; Mon, 14 Jul 2003 16:31:55 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9zI-0007QE-00 for nsis@ietf.org; Mon, 14 Jul 2003 16:31:56 -0400 Received: from alc240.alcatel.be ([195.207.101.240] helo=relay1.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19c9zH-0007PZ-00 for nsis@ietf.org; Mon, 14 Jul 2003 16:31:55 -0400 Received: from bemail04.net.alcatel.be (bemail04.net.alcatel.be [138.203.144.6]) by relay1.alcatel.be (8.12.9/8.12.4) with ESMTP id h6EKUfrH017477; Mon, 14 Jul 2003 22:30:41 +0200 (MEST) Subject: Re: [NSIS] Reliable Transport for NTLP To: Henning Schulzrinne Cc: john.loughney@nokia.com, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 14 Jul 2003 22:30:37 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/14/2003 22:30:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, I would like to second Henning's opinion here, especially for core networks. It seems that there would be parts of the network where peering relations are stable enough for the cost of the overhead to be amortized over many flows. I believe this would make it a worthwhile addition to the protocol. Sven Henning Schulzrinne @ietf.org on 14/07/2003 20:33:12 Sent by: nsis-admin@ietf.org To: john.loughney@nokia.com cc: nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP john.loughney@nokia.com wrote: > Hi All, > > > However, my point is that the WG has not come to agreement that NTLP > should use reliable transport. In fact, there is a significant cost, > in my opinion, in terms of setup time & latency. I will outline a scenario. > Two end hosts, A & B, need to setup some signaling between them. If TCP > is used as a transport, it is not a simple 3 way handshake that is > needed. If A & B are x NTLP hops away, they will need x TCP connections, > which, depending upon implementation, will result a 3 way handshake > between x+1 nodes, which is a significant problem. In addition, needing > to setup TCP connections during fast mobility can also be a problem. John, this is simply not true and has not been true in all of these discussions. There has always been the assumption that connections are, on average, already established since the number of peers in most cases is bounded. There is no need to start from scratch for every session. > > My point is that I do not see the requirement for reliable transport > in NTLP. If there are parties interested in using reliable transport, > the burden of proof is with them. I'm not sure what the threshold of "proof" is. I thought we had extensive, but inconclusive, discussions on how to address fragmentation, flow control and congestion control in NTLP. > > Please note, that Henning has proposed that there may be some advantageous > of using a partially reliable transport mechanism, however, I think > he has planned on providing more details to the list of how this could > be achieved, as it was not completely specified in his draft. Without trying to write a draft on the fly, here's the simple outline. I really need a whiteboard here. There are three choices: 1) one message, no reliability: just forward and have NSLP or e2e retransmission; subject to security issues such as DOS attacks, but quick and low overhead. 2) one message pair per hop: adds reliability, but no delay. Doesn't address DOS issues completely. 3) one message pair per hop + reliable protocol for large messages: adds reliability; adds delay for large signaling message. Addresses DOS issues better and. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 03:11:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27782 for ; Tue, 15 Jul 2003 03:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cJxn-0001vi-P0 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 03:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F7B3gs007414 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 03:11:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cJxm-0001vS-E8; Tue, 15 Jul 2003 03:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cJxJ-0001uT-1k for nsis@optimus.ietf.org; Tue, 15 Jul 2003 03:10:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27767 for ; Tue, 15 Jul 2003 03:10:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cJxF-0004mp-00 for nsis@ietf.org; Tue, 15 Jul 2003 03:10:29 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 19cJxE-0004mm-00 for nsis@ietf.org; Tue, 15 Jul 2003 03:10:28 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 19cJxD-0002Hp-00; Tue, 15 Jul 2003 09:10:28 +0200 Received: from localhost ([127.0.0.1] helo=i72mn12.tm.uka.de) by irams1.ira.uka.de with smtp (Exim 3.30 #7 (Debian)) id 19cJxE-0000XL-00; Tue, 15 Jul 2003 09:10:28 +0200 Date: Tue, 15 Jul 2003 09:10:34 +0200 From: Roland Bless To: nsis@ietf.org, john.loughney@nokia.com Subject: Re: [NSIS] Reliable Transport for NTLP Message-Id: <20030715091034.31cb06af.bless@tm.uka.de> In-Reply-To: References: Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi John, On Mon, 14 Jul 2003 19:49:36 +0300 john.loughney@nokia.com wrote: > transport. Also, I feel that R=FCdiger behavior was inappropriate for a > professional meeting. I should have asked R=FCdiger to display more > professional courtesy at the mic. Maybe I missed something, but I don't remember any offending statement from him. He mainly asked Melinda to check for existing signaling protocols that use an underlying reliable transport. > However, my point is that the WG has not come to agreement that NTLP > should use reliable transport. In fact, there is a significant cost, > in my opinion, in terms of setup time & latency. I will outline a If NTLP must implement congestion control we may also need a three way handshake (see current DCCP spec). > scenario. Two end hosts, A & B, need to setup some signaling between > them. If TCP is used as a transport, it is not a simple 3 way > handshake that is needed. If A & B are x NTLP hops away, they will > need x TCP connections, which, depending upon implementation, will > result a 3 way handshake between x+1 nodes, which is a significant > problem. In addition, needing to setup TCP connections during fast > mobility can also be a problem. As others already stated: there may be already established connections that can be reused. > My point is that I do not see the requirement for reliable transport > in NTLP. If there are parties interested in using reliable transport, > the burden of proof is with them. =20 I think Henning mentioned the "SIP experience" several times and the current discussion reminds me somehow of it... =20 - Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 03:39:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29736 for ; Tue, 15 Jul 2003 03:39:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKOr-0003Xj-KZ for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 03:39:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F7d11e013574 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 03:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKOq-0003Wo-H4; Tue, 15 Jul 2003 03:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKOF-0003Vz-Lp for nsis@optimus.ietf.org; Tue, 15 Jul 2003 03:38:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29627 for ; Tue, 15 Jul 2003 03:38:19 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cKOD-0005FS-00 for nsis@ietf.org; Tue, 15 Jul 2003 03:38:21 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19cKOC-0005FJ-00 for nsis@ietf.org; Tue, 15 Jul 2003 03:38:20 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6F7cKa27180 for ; Tue, 15 Jul 2003 10:38:20 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 10:38:18 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 10:38:17 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 10:38:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Reliable Transport for NTLP Date: Tue, 15 Jul 2003 10:38:16 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNKRvmT48vFnd1QRBKMMRTYuIOo1AAXLHOA To: , Cc: X-OriginalArrivalTime: 15 Jul 2003 07:38:17.0414 (UTC) FILETIME=[0E74E660:01C34AA4] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Sven, > I would like to second Henning's opinion here, especially for core > networks. It seems that there would be parts of the network where = peering > relations are stable enough for the cost of the overhead to be = amortized > over many flows. I believe this would make it a worthwhile addition to = the > protocol. I think that figuring out the details of this is in-scope for NTLP. What I want to make sure is that we ensure the we get a handle on this, with the proper scope.=20 My current working assumption is that NTLP works in a lightweight datagram mode with the possibility of a reliable model, for example, provided by TCP / SCTP / etc. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 04:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03865 for ; Tue, 15 Jul 2003 04:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cL8N-0006IY-B2 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 04:26:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8Q3DX024203 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 04:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cL8M-0006IG-T5; Tue, 15 Jul 2003 04:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cL7X-0006Ha-Jf for nsis@optimus.ietf.org; Tue, 15 Jul 2003 04:25:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03773 for ; Tue, 15 Jul 2003 04:25:07 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cL7U-0006G0-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:25:08 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cL7T-0006Fn-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:25:08 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6F8P8k10243 for ; Tue, 15 Jul 2003 11:25:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 11:25:07 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 11:25:06 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 11:25:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Reliable Transport for NTLP Date: Tue, 15 Jul 2003 11:25:04 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNKoKqZXK6p6GB/R4WoNMdZ+/nzzgACKXxQ To: , X-OriginalArrivalTime: 15 Jul 2003 08:25:05.0785 (UTC) FILETIME=[98604E90:01C34AAA] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Roland, > Maybe I missed something, but I don't remember any offending statement > from him. He mainly asked Melinda to check for existing signaling > protocols that use an underlying reliable transport. If we were in a court of law, I think I would have claimed that he was badgering the witness - my main point was that as we do not have a working assumption that NTLP MUST be reliable, his questioning was inappropiate in tone. =20 As a side note, several people came up to me yesterday staying that several people at the mic & some on stage were too 'aggressive' in their questioning / responding to questions. I hope that we can be more curtious at today's meeting. =20 > > However, my point is that the WG has not come to agreement that NTLP > > should use reliable transport. In fact, there is a=20 > significant cost, > > in my opinion, in terms of setup time & latency. I will outline a >=20 > If NTLP must implement congestion control we may also need a three way > handshake (see current DCCP spec). At least our ADs have said that (currently) there is not a MUST for congestion control. > > scenario. Two end hosts, A & B, need to setup some signaling between > > them. If TCP is used as a transport, it is not a simple 3 way > > handshake that is needed. If A & B are x NTLP hops away, they will > > need x TCP connections, which, depending upon implementation, will > > result a 3 way handshake between x+1 nodes, which is a significant > > problem. In addition, needing to setup TCP connections during fast > > mobility can also be a problem. >=20 > As others already stated: there may be already established connections > that can be reused. This is a possibility, with detials which need to be provided. This is my 'burden of proof' principle, meaning that I would like to have = details not handwaving. This is a general comment on when we are now starting a design phase. Saying things are easy / hard / etc. SHOULD be backed up with some details. > > My point is that I do not see the requirement for reliable transport > > in NTLP. If there are parties interested in using reliable = transport, > > the burden of proof is with them. =20 John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 04:29:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04111 for ; Tue, 15 Jul 2003 04:29:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLBI-0006qX-2i for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 04:29:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8T48N026058 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 04:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLBF-0006mC-Hd; Tue, 15 Jul 2003 04:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLAu-0006iX-RU for nsis@optimus.ietf.org; Tue, 15 Jul 2003 04:28:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04042 for ; Tue, 15 Jul 2003 04:28:34 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLAq-0006Jm-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:28:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cLAp-0006Jh-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:28:35 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6F8SYk13361 for ; Tue, 15 Jul 2003 11:28:34 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 11:28:34 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 11:28:34 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 11:28:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Subject: thoughts on reiiable transport RE: [NSIS] Reliable Transport for NTLP Date: Tue, 15 Jul 2003 11:28:32 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNKoKqZXK6p6GB/R4WoNMdZ+/nzzgACfV1A To: , X-OriginalArrivalTime: 15 Jul 2003 08:28:33.0980 (UTC) FILETIME=[147857C0:01C34AAB] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Not meaning to pick on Roland specifically, but his comment: > I think Henning mentioned the "SIP experience" several times and the > current discussion reminds me somehow of it... =20 Made me do a little thinking on this subject. I've taken Henning's comment on SIP more to mean that supporting = multiple transport protocols are difficult. This is why I want to see more = details on how to support multiple transport. Additionally, I thought that Henning's earlier comments with regards to SIP & reliable were more = along the lines of, if you are going to do fragmentation, congestion control, etc. it is better to re-use existing transport rather than rolling your own mechanisms. =20 However, some comments in the WG yesterday seemed to be saying, for = example,=20 TCP does functionality x, y & z so let's use this. I believe Melinda was = attempting to suggest that maybe functionality x & y are not needed and maybe thinking about z is needed. Stating many protocols use TCP, so why are x, y & z problems seems not to be a helpful line for=20 discussion. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 04:30:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04231 for ; Tue, 15 Jul 2003 04:30:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLCE-0006xf-OT for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 04:30:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8U2dX026752 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 04:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLCE-0006xN-Ie; Tue, 15 Jul 2003 04:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLBl-0006wF-II for nsis@optimus.ietf.org; Tue, 15 Jul 2003 04:29:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04109 for ; Tue, 15 Jul 2003 04:29:28 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLBi-0006Lo-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:29:30 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19cLBh-0006Lh-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:29:29 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6F8TTa14707 for ; Tue, 15 Jul 2003 11:29:29 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 11:29:28 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 11:29:28 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 11:29:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jul 2003 11:29:27 +0300 Message-ID: Thread-Topic: Presentation Slides Thread-Index: AcNKFYY5ReDEOTHKRdacrEvsqVrHkAAlaAmQ To: , X-OriginalArrivalTime: 15 Jul 2003 08:29:28.0350 (UTC) FILETIME=[34E08BE0:01C34AAB] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RE: Presentation Slides Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, jabber was not working yesterday. I don't have all of the slides, if = you want I can post the slides from yesterday. John > -----Original Message----- > From: ext Charles Q. Shen [mailto:charles@ee.columbia.edu] > Sent: 14 July, 2003 17:38 > To: Loughney John (NRC/Helsinki); nsis@ietf.org > Subject: Presentation Slides >=20 >=20 > Hi John, >=20 > The text conferencing does not seem to be running. Could you=20 > please put > the presentation slides online? >=20 > Thanks. >=20 > Charles >=20 > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On=20 > > Behalf Of john.loughney@nokia.com > > Sent: Monday, July 14, 2003 3:41 AM > > To: robert.hancock@roke.co.uk; nsis@ietf.org > > Subject: RE: [NSIS] Review of NTLP proposals > >=20 > >=20 > > Hi Robert, > >=20 > > > Up to now I think we have been discussing multihoming rather=20 > > > implicitly, as something which - along with IP or higher layer=20 > > > mobility - can cause the general problem that the=20 > > relationship between=20 > > > application-layer session and [micro]flow to be more than just a=20 > > > simple 1:1 relationship. That's what the session identifier=20 > > > functionality is about. > > >=20 > > > However, I don't see that the NTLP should have a role in=20 > trying to=20 > > > 'solve' the multihoming problem, because the correct=20 > > solution almost=20 > > > certainly depends on the demands of the signalling=20 > > application (at the=20 > > > moment, the framework assumes that handling IP address=20 > change is a=20 > > > signalling application responsibility, essentially for the same=20 > > > reason). The NTLP should think in terms of single flows=20 > defined by=20 > > > fixed N-tuples, and anything cleverer has to be pushed=20 > > upstairs, IMHO. > >=20 > > I agree. > >=20 > > John > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 04:32:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04526 for ; Tue, 15 Jul 2003 04:32:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLEF-0007Q6-Dy for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 04:32:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8W7nl028505 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 04:32:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLEB-0007NH-5Z; Tue, 15 Jul 2003 04:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLDc-0007Lq-8b for nsis@optimus.ietf.org; Tue, 15 Jul 2003 04:31:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04398 for ; Tue, 15 Jul 2003 04:31:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLDZ-0006Q1-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:31:25 -0400 Received: from [137.194.192.1] (helo=infres.enst.fr) by ietf-mx with esmtp (Exim 4.12) id 19cLDY-0006Pv-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:31:24 -0400 Received: from luu (dhcp7-211.enst.fr [137.194.7.211]) by infres.enst.fr (Postfix) with SMTP id 793FA19D2 for ; Tue, 15 Jul 2003 10:31:24 +0200 (MEST) Message-ID: <000d01c34aab$b233ad20$d307c289@enst.fr> From: "Thanh Tra LUU" To: References: Subject: Re: [NSIS] Reliable Transport for NTLP Date: Tue, 15 Jul 2003 10:32:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, We have talked that NTLP can use TCP/SCTP/UDP or IP. Do we always keep this approach or we must choose a specific protocol (IP or transport protocols) to use ? According to me, reusing the existing transport protocols is good way to economize on time and deployment. But it is not the best way to implement a new signaling protocol. For example, if we use TCP : +for bundling a message, how can we place many NSLP messages in a IP(TCP(NTLP(NSLP messages))), is bundling as useful as we've thought ? +how we do fragementation when IP does it all even though we don't want to do fragmentation. + TCP congestion/flow control is appropriate to our characteristic signaling ? + Soft-state seems no much sense. I don't think using IP is easy, but it is useful because we implement a new signaling protocol only for signaling and implement it without constraint. Nary Tra ENST, Paris. ----- Original Message ----- From: To: ; Cc: Sent: Tuesday, July 15, 2003 9:38 AM Subject: RE: [NSIS] Reliable Transport for NTLP Hi Sven, > I would like to second Henning's opinion here, especially for core > networks. It seems that there would be parts of the network where peering > relations are stable enough for the cost of the overhead to be amortized > over many flows. I believe this would make it a worthwhile addition to the > protocol. I think that figuring out the details of this is in-scope for NTLP. What I want to make sure is that we ensure the we get a handle on this, with the proper scope. My current working assumption is that NTLP works in a lightweight datagram mode with the possibility of a reliable model, for example, provided by TCP / SCTP / etc. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 04:41:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05240 for ; Tue, 15 Jul 2003 04:41:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLMu-000853-Do for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 04:41:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8f4to031043 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 04:41:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLMs-00084B-LK; Tue, 15 Jul 2003 04:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLME-00083Y-7D for nsis@optimus.ietf.org; Tue, 15 Jul 2003 04:40:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05106 for ; Tue, 15 Jul 2003 04:40:17 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLMB-0006bO-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:40:19 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19cLMA-0006bL-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:40:18 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6F8eIa26280 for ; Tue, 15 Jul 2003 11:40:18 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 15 Jul 2003 11:40:18 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 11:40:18 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 11:40:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jul 2003 11:40:17 +0300 Message-ID: Thread-Topic: Presentation Slides Thread-Index: AcNKFYY5ReDEOTHKRdacrEvsqVrHkAAlaAmQAABXf4A= To: X-OriginalArrivalTime: 15 Jul 2003 08:40:18.0192 (UTC) FILETIME=[B8369100:01C34AAC] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Presentation Slides from Monday Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Yesterday's slides can be found from here: http://www-nrc.nokia.com/sua/ietf57/ John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:00:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06901 for ; Tue, 15 Jul 2003 05:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLfG-0000Os-BJ for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:00:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F902or001520 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLfG-0000O1-3p; Tue, 15 Jul 2003 05:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLeo-0000MN-L3 for nsis@optimus.ietf.org; Tue, 15 Jul 2003 04:59:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06839 for ; Tue, 15 Jul 2003 04:59:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLel-000733-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:59:31 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 19cLek-000730-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:59:31 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 19cLei-0003Fm-00; Tue, 15 Jul 2003 10:59:28 +0200 Received: from localhost ([127.0.0.1] helo=i72mn12.tm.uka.de) by irams1.ira.uka.de with smtp (Exim 3.30 #7 (Debian)) id 19cLei-000732-00; Tue, 15 Jul 2003 10:59:28 +0200 Date: Tue, 15 Jul 2003 10:59:34 +0200 From: Roland Bless To: Cc: Subject: Re: [NSIS] Reliable Transport for NTLP Message-Id: <20030715105934.0addf8b7.bless@tm.uka.de> In-Reply-To: References: Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John, On Tue, 15 Jul 2003 11:25:04 +0300 wrote: > As a side note, several people came up to me yesterday staying that > several people at the mic & some on stage were too 'aggressive' in > their questioning / responding to questions. I hope that we can > be more curtious at today's meeting. Ok, to close these non-technical issue, maybe it is helpful for participants to read and follow RFC 3184/BCP 54 from time to time again. http://www.ietf.org/rfc/rfc3184.txt RFC 3184 IETF Guidelines for Conduct. S. Harris. October 2001. (Format: TXT=7413 bytes) (Also BCP0054) (Status: BEST CURRENT PRACTICE) > > If NTLP must implement congestion control we may also need a three way > > handshake (see current DCCP spec). > > At least our ADs have said that (currently) there is not a MUST for > congestion control. Yes, I know (BTW: do we need to document this somewhere along with its reasoning?). I just wanted to show that it's not reliability only that may cause "complexity". Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:04:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07279 for ; Tue, 15 Jul 2003 05:04:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLj7-0000dU-Fs for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:04:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F941Gg002407 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLj7-0000cd-7R; Tue, 15 Jul 2003 05:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLj6-0000cQ-Gt for nsis@optimus.ietf.org; Tue, 15 Jul 2003 05:04:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07223 for ; Tue, 15 Jul 2003 05:03:55 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLj3-000781-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:03:57 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19cLj2-00077y-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:03:56 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6F93va18440 for ; Tue, 15 Jul 2003 12:03:57 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 12:03:56 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 12:03:56 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 12:03:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Reliable Transport for NTLP Date: Tue, 15 Jul 2003 12:03:54 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNKr2v84CPY0Qd/TpGbiDEp4W0zbQAAIjbA To: Cc: X-OriginalArrivalTime: 15 Jul 2003 09:03:55.0666 (UTC) FILETIME=[0517EF20:01C34AB0] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Roland, > Ok, to close these non-technical issue, maybe it is helpful for > participants to read and follow RFC 3184/BCP 54 from time to time > again.=20 > http://www.ietf.org/rfc/rfc3184.txt Thanks for posting this, this is a good thing to read. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:05:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07382 for ; Tue, 15 Jul 2003 05:05:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLk6-0000iE-2p for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:05:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F952YI002720 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLk5-0000hm-Uh; Tue, 15 Jul 2003 05:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLjp-0000hG-8P for nsis@optimus.ietf.org; Tue, 15 Jul 2003 05:04:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07302 for ; Tue, 15 Jul 2003 05:04:40 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLjm-00079C-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:04:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19cLjl-000796-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:04:41 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6F94fa18978 for ; Tue, 15 Jul 2003 12:04:41 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 12:04:41 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 12:04:40 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 12:04:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Congestion Control (was: [NSIS] Reliable Transport for NTLP) Date: Tue, 15 Jul 2003 12:04:38 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNKr2v84CPY0Qd/TpGbiDEp4W0zbQAAJyPg To: Cc: X-OriginalArrivalTime: 15 Jul 2003 09:04:39.0632 (UTC) FILETIME=[1F4C9D00:01C34AB0] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Roland, > > At least our ADs have said that (currently) there is not a MUST for > > congestion control. >=20 > Yes, I know (BTW: do we need to document this somewhere along with its > reasoning?). I just wanted to show that it's not reliability only that > may cause "complexity". I will ask for some documentation. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:14:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08133 for ; Tue, 15 Jul 2003 05:14:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLsn-0001Sh-Eu for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:14:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9E1Je005602 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLsn-0001SF-A9; Tue, 15 Jul 2003 05:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLsd-0001S1-DP for nsis@optimus.ietf.org; Tue, 15 Jul 2003 05:13:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08079 for ; Tue, 15 Jul 2003 05:13:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLsa-0007KF-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:13:48 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 19cLsZ-0007KC-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:13:47 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 19cLsJ-0003N7-00; Tue, 15 Jul 2003 11:13:32 +0200 Received: from localhost ([127.0.0.1] helo=i72mn12.tm.uka.de) by irams1.ira.uka.de with smtp (Exim 3.30 #7 (Debian)) id 19cLsK-0000DM-00; Tue, 15 Jul 2003 11:13:32 +0200 Date: Tue, 15 Jul 2003 11:13:35 +0200 From: Roland Bless To: Henning Schulzrinne Cc: john.loughney@nokia.com, nsis@ietf.org Subject: Re: thoughts on reiiable transport RE: [NSIS] Reliable Transport for NTLP Message-Id: <20030715111335.3b28b063.bless@tm.uka.de> In-Reply-To: <3F13C172.20500@cs.columbia.edu> References: <3F13C172.20500@cs.columbia.edu> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tue, 15 Jul 2003 04:55:14 -0400 Henning Schulzrinne wrote: > The SIP experience was that some thought that only UDP support would be > necessary. The tendency has been that the problems that seemed minor > (congestion, fragmentation) became rather annoying as things progressed > and as a more complete system was built. Thanks Henning, I was refering to exactly this fact. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:26:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09461 for ; Tue, 15 Jul 2003 05:26:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM4Q-000294-FD for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:26:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9Q25L008229 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM4P-00028Z-QA; Tue, 15 Jul 2003 05:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM4F-00028A-6T for nsis@optimus.ietf.org; Tue, 15 Jul 2003 05:25:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09384 for ; Tue, 15 Jul 2003 05:25:45 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM4B-0007dS-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:25:47 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cM4A-0007dP-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:25:46 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6F9Pkk09970 for ; Tue, 15 Jul 2003 12:25:46 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 12:25:45 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 12:25:44 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 12:25:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: thoughts on reiiable transport RE: [NSIS] Reliable Transport for NTLP Date: Tue, 15 Jul 2003 12:25:43 +0300 Message-ID: Thread-Topic: thoughts on reiiable transport RE: [NSIS] Reliable Transport for NTLP Thread-Index: AcNKr2g7zAhXPDCbSxiOnygk70EsygAAwv6A To: Cc: , X-OriginalArrivalTime: 15 Jul 2003 09:25:44.0188 (UTC) FILETIME=[11088BC0:01C34AB3] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Henning, Rather than re-hash history & noting that the IETF has trouble with revisiting decisions, or maybe it is better to say that the IETF often revisions decisions that should have been long decided, I propose: > Some of us have different opinions on these requirements and claim to=20 > have described clear use cases for these items. Maybe that's not been=20 > clear or convincing enough, but I don't think it helps to deny that = the=20 > attempts have been made or not at least to refer to those discussions. No rehashing the discussions, but rather working forward. In the NTLP & NSLP documents, we should at least have short appendicies that state what the protocol does with a summary reason or pointer to existing documentation. I don't intend these to be long appendicies, but just nearly like an issue tracker that is carried around with the document in the early stages. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:29:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09802 for ; Tue, 15 Jul 2003 05:29:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM7J-0002Vj-Cq for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:29:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9T1U9009634 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM7J-0002VH-3s; Tue, 15 Jul 2003 05:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM6M-0002Qb-8s for nsis@optimus.ietf.org; Tue, 15 Jul 2003 05:28:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09600 for ; Tue, 15 Jul 2003 05:27:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM6I-0007g9-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:27:59 -0400 Received: from lion.seas.upenn.edu ([158.130.12.194]) by ietf-mx with esmtp (Exim 4.12) id 19cM6I-0007g6-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:27:58 -0400 Received: from red.seas.upenn.edu (RED.SEAS.UPENN.EDU [158.130.64.176]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6F9RvM1031762 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 15 Jul 2003 05:27:58 -0400 Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6F9RvWQ023979; Tue, 15 Jul 2003 05:27:57 -0400 (EDT) Received: from localhost (rsofia@localhost) by red.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6F9RvSh023975; Tue, 15 Jul 2003 05:27:57 -0400 (EDT) Date: Tue, 15 Jul 2003 05:27:57 -0400 (EDT) From: HELENA RUTE SOFIA To: john.loughney@nokia.com cc: hgs@cs.columbia.edu, Subject: RE: [NSIS] Reliable Transport for NTLP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , John, question below: > > Without trying to write a draft on the fly, here's the simple outline. > > I really need a whiteboard here. There are three choices: > > > > 1) one message, no reliability: just forward and have NSLP or e2e > > retransmission; subject to security issues such as DOS attacks, but > > quick and low overhead. > > > > 2) one message pair per hop: adds reliability, but no delay. Doesn't > > address DOS issues completely. > > > > 3) one message pair per hop + reliable protocol for large messages: adds > > reliability; adds delay for large signaling message. Addresses DOS > > issues better and. > > As we discussed earlier, I think this looks like the way to go > to handle reliable transport, rather than turn it into an either / > or debate. > exactly to which option are you referring to?? 1), 2), or 3)? Rute _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:40:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10727 for ; Tue, 15 Jul 2003 05:40:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMHx-0003Mr-Ov for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:40:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9e1eF012918 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMHx-0003MF-9T; Tue, 15 Jul 2003 05:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMHc-0003Lg-2D for nsis@optimus.ietf.org; Tue, 15 Jul 2003 05:39:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10694 for ; Tue, 15 Jul 2003 05:39:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cMHT-00004p-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:39:31 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cMGy-00003O-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:39:00 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F9askM027077; Tue, 15 Jul 2003 05:36:54 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F9arg14041; Tue, 15 Jul 2003 05:36:53 -0400 Message-ID: <3F13CA3E.3030406@cs.columbia.edu> Date: Tue, 15 Jul 2003 05:32:46 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: HELENA RUTE SOFIA CC: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit To avoid artificial choices and unnecesary disagreements: I am arguing that all three are needed and can be readily supported without undue complexity in implementation, time or space. I'm *NOT* arguing that we need to make a choice here - the NSLP or NE gets to pick according to whatever trade-off it deems reasonable. (Who gets to suggest or force the choice is indeed an open issue.) HELENA RUTE SOFIA wrote: > John, > > question below: > > >>>Without trying to write a draft on the fly, here's the simple outline. >>>I really need a whiteboard here. There are three choices: >>> >>>1) one message, no reliability: just forward and have NSLP or e2e >>>retransmission; subject to security issues such as DOS attacks, but >>>quick and low overhead. >>> >>>2) one message pair per hop: adds reliability, but no delay. Doesn't >>>address DOS issues completely. >>> >>>3) one message pair per hop + reliable protocol for large messages: adds >>>reliability; adds delay for large signaling message. Addresses DOS >>>issues better and. >> >>As we discussed earlier, I think this looks like the way to go >>to handle reliable transport, rather than turn it into an either / >>or debate. >> > > exactly to which option are you referring to?? 1), 2), or 3)? > > Rute _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:46:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06898 for ; Tue, 15 Jul 2003 05:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLfF-0000Nh-TP for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:00:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F901MR001462 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:00:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLfF-0000NS-Hf; Tue, 15 Jul 2003 05:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLef-0000M9-BW for nsis@optimus.ietf.org; Tue, 15 Jul 2003 04:59:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06820 for ; Tue, 15 Jul 2003 04:59:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLec-00072x-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:59:22 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cLeb-00072u-00 for nsis@ietf.org; Tue, 15 Jul 2003 04:59:21 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F8xMkM022272; Tue, 15 Jul 2003 04:59:22 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F8xLg10647; Tue, 15 Jul 2003 04:59:22 -0400 Message-ID: <3F13C172.20500@cs.columbia.edu> Date: Tue, 15 Jul 2003 04:55:14 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: bless@tm.uka.de, nsis@ietf.org Subject: Re: thoughts on reiiable transport RE: [NSIS] Reliable Transport for NTLP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > I've taken Henning's comment on SIP more to mean that supporting multiple > transport protocols are difficult. This is why I want to see more details This needs to be qualified a bit, I think. The support for multiple protocols is not particularly difficult. For example, adding SCTP support to TCP was fairly trivial. The slightly difficult part was trying to achieve both low-latency end-to-end reliability and per-hop reliability. (The difficulty is not in the protocol, but to make sure no extra work is being done, i.e., that you don't end up retransmitting across a TCP connection.) If we had done purely hop-by-hop (that is, proxy-to-proxy or UA-to-proxy) mechanisms, this would have been fairly easy. SIP had special concerns that lead to this design (forking and human "end systems"), which don't apply here. Thus, one "lesson" is to do things only once or at different time-scales. It's no problem to have a long-term recovery mechanism (say, at RSVP 2205 timescales) that primarily deals with system and network failures and a short-term one dealing with packet loss. That's roughly the 2205 + 2916 combination. I happen to think we can improve upon the performance of the latter mechanism, while making it simpler (since we're not bolting it on after the fact). The SIP experience was that some thought that only UDP support would be necessary. The tendency has been that the problems that seemed minor (congestion, fragmentation) became rather annoying as things progressed and as a more complete system was built. > on how to support multiple transport. Additionally, I thought that > Henning's earlier comments with regards to SIP & reliable were more along > the lines of, if you are going to do fragmentation, congestion control, > etc. it is better to re-use existing transport rather than rolling your > own mechanisms. Certainly - any attempts to try to this at higher layers seems to end up re-inventing the same mechanisms while often lacking the access to the lower-level tools. > > However, some comments in the WG yesterday seemed to be saying, for example, > TCP does functionality x, y & z so let's use this. I believe Melinda was > attempting to suggest that maybe functionality x & y are not needed and > maybe thinking about z is needed. Stating many protocols use TCP, > so why are x, y & z problems seems not to be a helpful line for > discussion. Some of us have different opinions on these requirements and claim to have described clear use cases for these items. Maybe that's not been clear or convincing enough, but I don't think it helps to deny that the attempts have been made or not at least to refer to those discussions. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:55:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11670 for ; Tue, 15 Jul 2003 05:55:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMWT-0003lm-HP for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:55:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9t1Cj014473 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:55:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMWT-0003lI-9t; Tue, 15 Jul 2003 05:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMVa-0003kU-B8 for nsis@optimus.ietf.org; Tue, 15 Jul 2003 05:54:06 -0400 Received: from lion.seas.upenn.edu (LION-S12.SEAS.UPENN.EDU [158.130.12.194]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11485 for ; Tue, 15 Jul 2003 05:54:00 -0400 (EDT) Received: from red.seas.upenn.edu (RED.SEAS.UPENN.EDU [158.130.64.176]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6F9s2M1003309 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 15 Jul 2003 05:54:03 -0400 Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6F9s2WQ025253; Tue, 15 Jul 2003 05:54:02 -0400 (EDT) Received: from localhost (rsofia@localhost) by red.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6F9s2VM025250; Tue, 15 Jul 2003 05:54:02 -0400 (EDT) Date: Tue, 15 Jul 2003 05:54:02 -0400 (EDT) From: HELENA RUTE SOFIA To: Henning Schulzrinne cc: john.loughney@nokia.com, Subject: Re: [NSIS] Reliable Transport for NTLP In-Reply-To: <3F13CA3E.3030406@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Henning, John, > To avoid artificial choices and unnecesary disagreements: I am arguing > that all three are needed and can be readily supported without undue > complexity in implementation, time or space. I'm *NOT* arguing that we > need to make a choice here - the NSLP or NE gets to pick according to > whatever trade-off it deems reasonable. (Who gets to suggest or force > the choice is indeed an open issue.) > Ok, not sure if this makes sense here, but I second-motion the opinion aboeve; perhaps this could be addressed clearly on the next version of ntlp... Rute _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:56:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11791 for ; Tue, 15 Jul 2003 05:56:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMXQ-00042n-M9 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:56:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9u0HR015527 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:56:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMXQ-00042L-Hd; Tue, 15 Jul 2003 05:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMX0-0003zY-E2 for nsis@optimus.ietf.org; Tue, 15 Jul 2003 05:55:34 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11689 for ; Tue, 15 Jul 2003 05:55:27 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSK1NGQ>; Tue, 15 Jul 2003 10:51:47 +0100 Message-ID: From: "Hancock, Robert" To: john.loughney@nokia.com, sven.van_den_bosch@alcatel.be, hgs@cs.columbia.edu Cc: nsis@ietf.org Subject: RE: [NSIS] Reliable Transport for NTLP Date: Tue, 15 Jul 2003 10:51:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , john, > > My current working assumption is that NTLP works in a lightweight > datagram mode with the possibility of a reliable model, for example, > provided by TCP / SCTP / etc. for the avoidance of doubt, since you mention including the ability to use tcp/sctp: does this mean that design approaches which include explicit peer-peer connections for message forwarding, with the peer discovered by separate explicit discovery messages, are in scope for the working group as possible solutions? [i ask, since such approaches have been objected to in the past on architectural grounds, but I can see no other way to re-use protocols such as TCP.] robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 05:57:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11845 for ; Tue, 15 Jul 2003 05:57:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMYQ-00047O-B2 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:57:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9v24B015827 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 05:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMYQ-00047B-6s; Tue, 15 Jul 2003 05:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMXl-00046e-WF for nsis@optimus.ietf.org; Tue, 15 Jul 2003 05:56:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11787 for ; Tue, 15 Jul 2003 05:56:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cMXa-0000FF-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:56:10 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 19cMXA-0000DA-00 for nsis@ietf.org; Tue, 15 Jul 2003 05:55:44 -0400 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Tue, 15 Jul 2003 11:51:22 +0200 Received: from docomolab-euro.com ([192.168.99.2]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 15 Jul 2003 11:51:22 +0200 Message-ID: <3F13CE9D.6050200@docomolab-euro.com> Date: Tue, 15 Jul 2003 11:51:25 +0200 From: mendes User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: fu@cs.uni-goettingen.de, nsis@ietf.org Subject: Re: [NSIS] Modeling of mobility? References: In-Reply-To: Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-c073ec59-6566-4e9c-8791-18bad67ea6a6" X-OriginalArrivalTime: 15 Jul 2003 09:51:22.0862 (UTC) FILETIME=[A62790E0:01C34AB6] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-c073ec59-6566-4e9c-8791-18bad67ea6a6 Content-Type: multipart/alternative; boundary="------------070002080803000203020008" --------------070002080803000203020008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi John, I don't understand what you want to transmit with the sentence below. If I'm correct, MIPv6 Signaling and Handoff Optimization BOF is chartered to study HMIP and Fast-Handover issues only, in order to improve MIP performance.This BOF does not consider anything especific to signaling protocols like NSIS.. I think the question is not to change the MIPv6 Signaling and Handoff Optimization BOF to include QoS signalinfg specific issues, but to allow the future signaling transport protocol (read it NSIS) to be used in mobile environments. Just for clarify this issue: Are you saying that NSIS should not consider mobility? This is, are you assuming that the future Internet, for which NSIS is being made, will not have suficient mobile devices to justify a mobile-aware signaling transport protocol? Paulo john.loughney@nokia.com wrote: >Hi Xiaoming, > >You may like to bring this up at the MIPv6 Signaling and >Handoff Optimization BOF on Wednesday, as this sounds >somewhat out of scope for NSIS. > >John > > > > > >>-----Original Message----- >>From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] >>Sent: 14 July, 2003 21:53 >>To: nsis@ietf.org >>Subject: [NSIS] Modeling of mobility? >> >> >>Hi all, >> >>Do you think it is useful to have a general modeling of data path >>features caused by (or, "related to") mobility? Examples: >>- independence of specific mobility protocols >>- IP-in-IP encasulation/tunnel >>- local repair & synchronization >>- even, anticipated handovers >> >>Cheers, >>Xiaoming >> >>PS. I've made the slides "mobility support in NSIS" online at: >>http://user.informatik.uni-goettingen.de/~fu/nsis/IETF-fu-nsis >>-mobility.pdf >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > > --------------070002080803000203020008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John,

I don't understand what you want to transmit with the sentence below. If I'm correct, MIPv6 Signaling and Handoff Optimization BOF is chartered to study HMIP and Fast-Handover issues only, in order to improve MIP performance.This BOF does not consider anything especific to signaling protocols like NSIS..

I think the question is not to change the MIPv6 Signaling and Handoff Optimization BOF to include QoS signalinfg specific issues, but to allow the future signaling transport protocol (read it NSIS) to be used in mobile environments.

Just for clarify this issue: Are you saying that NSIS should not consider mobility? This is, are you assuming that the future Internet, for which NSIS is being made, will not have suficient mobile devices to justify a mobile-aware signaling transport protocol?

Paulo

john.loughney@nokia.com wrote:
Hi Xiaoming,

You may like to bring this up at the MIPv6 Signaling and 
Handoff Optimization BOF on Wednesday, as this sounds 
somewhat out of scope for NSIS.

John



  
-----Original Message-----
From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de]
Sent: 14 July, 2003 21:53
To: nsis@ietf.org
Subject: [NSIS] Modeling of mobility?


Hi all,

Do you think it is useful to have a general modeling of data path 
features caused by (or, "related to") mobility? Examples:
- independence of specific mobility protocols
- IP-in-IP encasulation/tunnel
- local repair & synchronization
- even, anticipated handovers

Cheers,
Xiaoming

PS. I've made the slides "mobility support in NSIS" online at:
http://user.informatik.uni-goettingen.de/~fu/nsis/IETF-fu-nsis
-mobility.pdf


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

    

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

--------------070002080803000203020008-- ------=_NextPartTM-000-c073ec59-6566-4e9c-8791-18bad67ea6a6-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 09:33:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18011 for ; Tue, 15 Jul 2003 09:33:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cPvU-0005lk-CV for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 09:33:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FDX41I022175 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 09:33:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cPvR-0005ks-7n; Tue, 15 Jul 2003 09:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cPv6-0005ka-Al for nsis@optimus.ietf.org; Tue, 15 Jul 2003 09:32:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17976 for ; Tue, 15 Jul 2003 09:32:35 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cPv4-0001ws-00 for nsis@ietf.org; Tue, 15 Jul 2003 09:32:38 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cPut-0001wi-00 for nsis@ietf.org; Tue, 15 Jul 2003 09:32:27 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FDWAk27844 for ; Tue, 15 Jul 2003 16:32:10 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 16:32:10 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 16:32:10 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 16:32:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34AD5.7D4B97DB" Subject: RE: [NSIS] Modeling of mobility? Date: Tue, 15 Jul 2003 16:32:08 +0300 Message-ID: Thread-Topic: [NSIS] Modeling of mobility? Thread-Index: AcNKtsO5jMOQOyd3QE+mJ23obvC4jAAHjYOg To: Cc: , X-OriginalArrivalTime: 15 Jul 2003 13:32:09.0772 (UTC) FILETIME=[7DED9EC0:01C34AD5] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C34AD5.7D4B97DB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paulo, =20 There seems to have been misunderstanding between what Xiaoming was = trying to say. I thought he was trying to suggest tying NSIS signaling = with some MIP signaling, which is out of scope for NSIS. NSIS should be = concerned with the data path after handovers have occured, so it should = be generic and not tied to any mobility signaling. =20 At present, since much of MIP related signaling is still preliminary, I = don't think we should be considering this like HMIP, FMIP, etc. yet in = NSIS, but rather stick with general mobility. I believe the discussion = up until now has been captured in the Framework document. As the = framework is nearing completion, perhaps if you have comments on that = section, it would be good to send them to the list. =20 thanks, John -----Original Message----- From: ext mendes [mailto:mendes@docomolab-euro.com] Sent: 15 July, 2003 12:51 To: Loughney John (NRC/Helsinki) Cc: fu@cs.uni-goettingen.de; nsis@ietf.org Subject: Re: [NSIS] Modeling of mobility? Hi John, I don't understand what you want to transmit with the sentence below. If = I'm correct, MIPv6 Signaling and Handoff Optimization BOF is chartered = to study HMIP and Fast-Handover issues only, in order to improve MIP = performance.This BOF does not consider anything especific to signaling = protocols like NSIS.. I think the question is not to change the MIPv6 Signaling and Handoff = Optimization BOF to include QoS signalinfg specific issues, but to allow = the future signaling transport protocol (read it NSIS) to be used in = mobile environments.=20 Just for clarify this issue: Are you saying that NSIS should not = consider mobility? This is, are you assuming that the future Internet, = for which NSIS is being made, will not have suficient mobile devices to = justify a mobile-aware signaling transport protocol? Paulo john.loughney@nokia.com wrote: Hi Xiaoming, You may like to bring this up at the MIPv6 Signaling and=20 Handoff Optimization BOF on Wednesday, as this sounds=20 somewhat out of scope for NSIS. John =20 -----Original Message----- From: ext Xiaoming Fu [ mailto:fu@cs.uni-goettingen.de] Sent: 14 July, 2003 21:53 To: nsis@ietf.org Subject: [NSIS] Modeling of mobility? Hi all, Do you think it is useful to have a general modeling of data path=20 features caused by (or, "related to") mobility? Examples: - independence of specific mobility protocols - IP-in-IP encasulation/tunnel - local repair & synchronization - even, anticipated handovers Cheers, Xiaoming PS. I've made the slides "mobility support in NSIS" online at: http://user.informatik.uni-goettingen.de/~fu/nsis/IETF-fu-nsis -mobility.pdf _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis =20 ------_=_NextPart_001_01C34AD5.7D4B97DB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Paulo,
 
There=20 seems to have been misunderstanding between what Xiaoming was trying to=20 say.  I thought he was trying to suggest tying NSIS signaling with = some MIP=20 signaling, which is out of scope for NSIS.  NSIS should be = concerned with=20 the data path after handovers have occured, so it should be generic and = not tied=20 to any mobility signaling.
 
At=20 present, since much of MIP related signaling is still preliminary, I = don't think=20 we should be considering this like HMIP, FMIP, etc. yet in NSIS, but = rather=20 stick with general mobility.  I believe the discussion up until now = has=20 been captured in the Framework document.  As the framework is = nearing=20 completion, perhaps if you have comments on that section, it would be = good to=20 send them to the list.
 
thanks,
John
-----Original Message-----
From: ext mendes=20 [mailto:mendes@docomolab-euro.com]
Sent: 15 July, 2003=20 12:51
To: Loughney John (NRC/Helsinki)
Cc:=20 fu@cs.uni-goettingen.de; nsis@ietf.org
Subject: Re: [NSIS] = Modeling=20 of mobility?

Hi John,

I don't understand = what you=20 want to transmit with the sentence below. If I'm correct, MIPv6 = Signaling and=20 Handoff Optimization BOF is chartered to study HMIP and Fast-Handover = issues=20 only, in order to improve MIP performance.This BOF does not consider = anything=20 especific to signaling protocols like NSIS..

I think the = question is=20 not to change the MIPv6 Signaling and Handoff Optimization BOF to = include QoS=20 signalinfg specific issues, but to allow the future signaling = transport=20 protocol (read it NSIS) to be used in mobile environments. =

Just for=20 clarify this issue: Are you saying that NSIS should not consider = mobility?=20 This is, are you assuming that the future Internet, for which NSIS is = being=20 made, will not have suficient mobile devices to justify a mobile-aware = signaling transport protocol?

Paulo

john.loughney@nokia.com = wrote:
Hi Xiaoming,

You may like to bring this up at the MIPv6 Signaling and=20
Handoff Optimization BOF on Wednesday, as this sounds=20
somewhat out of scope for NSIS.

John



  
-----Original Message-----
From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de]
Sent: 14 July, 2003 21:53
To: nsis@ietf.org
Subject: [NSIS] Modeling of mobility?


Hi all,

Do you think it is useful to have a general modeling of data path=20
features caused by (or, "related to") mobility? Examples:
- independence of specific mobility protocols
- IP-in-IP encasulation/tunnel
- local repair & synchronization
- even, anticipated handovers

Cheers,
Xiaoming

PS. I've made the slides "mobility support in NSIS" online at:
h=
ttp://user.informatik.uni-goettingen.de/~fu/nsis/IETF-fu-nsis
-mobility.pdf


_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.or=
g/mailman/listinfo/nsis

    

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.or=
g/mailman/listinfo/nsis

------_=_NextPart_001_01C34AD5.7D4B97DB-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 15 10:21:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21202 for ; Tue, 15 Jul 2003 10:21:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQfw-0008Mz-03 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 10:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FEL3YR032156 for nsis-archive@odin.ietf.org; Tue, 15 Jul 2003 10:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQft-0008M6-NG; Tue, 15 Jul 2003 10:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQfJ-0008LV-8I for nsis@optimus.ietf.org; Tue, 15 Jul 2003 10:20:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21088 for ; Tue, 15 Jul 2003 10:20:19 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQfH-0002Lm-00 for nsis@ietf.org; Tue, 15 Jul 2003 10:20:23 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19cQf6-0002LC-00 for nsis@ietf.org; Tue, 15 Jul 2003 10:20:12 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FEJ7a14939 for ; Tue, 15 Jul 2003 17:19:07 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 17:19:07 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 17:19:07 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 17:19:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Reliable Transport for NTLP Date: Tue, 15 Jul 2003 17:19:06 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNKtsPHMgl7Sdu8TA2OWJumm1IilwAJP90A To: , , Cc: X-OriginalArrivalTime: 15 Jul 2003 14:19:07.0186 (UTC) FILETIME=[0D3CE120:01C34ADC] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Robert, > > My current working assumption is that NTLP works in a lightweight > > datagram mode with the possibility of a reliable model, for = example, > > provided by TCP / SCTP / etc. >=20 > for the avoidance of doubt, since you mention including the ability=20 > to use tcp/sctp: >=20 > does this mean that design approaches which include explicit peer-peer > connections for message forwarding, with the peer discovered by=20 > separate explicit discovery messages, are in scope for the working > group as possible solutions? I don't object on principle, but I have concerns if we can do this = cleanly=20 or not, therefore I am looking forward to seeing how we can do this=20 cleanly. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 16 03:42:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19195 for ; Wed, 16 Jul 2003 03:42:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgvM-0007Zl-6Z for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 03:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G7g4Cb029117 for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 03:42:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgvJ-0007Yu-1x; Wed, 16 Jul 2003 03:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgun-0007Y4-E8 for nsis@optimus.ietf.org; Wed, 16 Jul 2003 03:41:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19170 for ; Wed, 16 Jul 2003 03:41:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cgul-00049e-00 for nsis@ietf.org; Wed, 16 Jul 2003 03:41:27 -0400 Received: from lion-s12.seas.upenn.edu ([158.130.12.194] helo=lion.seas.upenn.edu) by ietf-mx with esmtp (Exim 4.12) id 19cgua-00049P-00 for nsis@ietf.org; Wed, 16 Jul 2003 03:41:16 -0400 Received: from blue.seas.upenn.edu (BLUE.SEAS.UPENN.EDU [158.130.64.177]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6G7etM1019027 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Jul 2003 03:40:55 -0400 Received: from blue.seas.upenn.edu (localhost [127.0.0.1]) by blue.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6G7etOM013606; Wed, 16 Jul 2003 03:40:55 -0400 (EDT) Received: from localhost (rsofia@localhost) by blue.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6G7esCx013603; Wed, 16 Jul 2003 03:40:55 -0400 (EDT) Date: Wed, 16 Jul 2003 03:40:54 -0400 (EDT) From: HELENA RUTE SOFIA To: nsis@ietf.org cc: guerin@ee.upenn.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [NSIS] QoS analysis draft: novel inter-domain approach Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , All, Yesterday (Monday July 14th), in the NSIS meeting, it was mentioned that additional QoS signaling protocols could still be added to the draft "Analysis of Existing Quality of Service Signaling Protocols". We (myself and Roch Gue'rin) developed a novel inter-domain aggregation signaling protocol, SICAP (Shared-Segment Inter-domain Control Aggregation Protocol) that we thought might be of interest to the analysis above. Being an inter-domain aggregation solution (as BGRP), SICAP was developed not so much to be "another" alternative to BGRP, but more as part of an "exercise" aimed at gaining a better understanding of the overall solution space. In particular, we felt that while the sink-tree approach of BGRP offered clear advantages from an operational point of view, it was not obvious if and how this affected scalability and where BGRP actually stood, in the space of possible solutions. So,the investigation, besides identifying a possible alternative to BGRP (SICAP performs shared-segment aggregation), also illustrated the existence of a range of options and showed that further improvements in a protocol's ability to aggregate state information were indeed feasible. More detailed information on SICAP and the associated investigation can be found at: http://m306pc7.seas.upenn.edu/mnlab/paper/icnp02_173.pdf (addresses the aggregation algorithms; presents simulation results) http://m306pc7.seas.upenn.edu/mnlab/paper/hpsr03_paper3743.pdf (addresses SICAP's design and compares it against BGRP) If there is interest and a sense that this could be a useful addition to the topics addressed in the QoS protocols analysis draft, we would be more than happy to provide additional details. Rute _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 16 03:57:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19822 for ; Wed, 16 Jul 2003 03:57:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ch9o-0008Lg-O7 for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 03:57:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G7v0TJ032090 for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 03:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ch9o-0008LU-H9; Wed, 16 Jul 2003 03:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ch9U-0008Ku-Qh for nsis@optimus.ietf.org; Wed, 16 Jul 2003 03:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19790 for ; Wed, 16 Jul 2003 03:56:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ch9R-0004Im-00 for nsis@ietf.org; Wed, 16 Jul 2003 03:56:37 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19ch9G-0004HO-00 for nsis@ietf.org; Wed, 16 Jul 2003 03:56:26 -0400 Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 16 Jul 2003 10:53:05 +0300 Date: Wed, 16 Jul 2003 10:53:04 +0300 (EEST) From: Jukka MJ Manner To: HELENA RUTE SOFIA cc: nsis@ietf.org, guerin@ee.upenn.edu Subject: Re: [NSIS] QoS analysis draft: novel inter-domain approach In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, We can still consider additional protocols for the analysis draft, true. Yet, I would like to add new protocols only if they provide new insights to the hard problem of QoS signaling, for example, new solutions and good ideas that we could learn from when designing the NTLP and NSLPs. So, if you feel that SICAP has some unique properties and solutions that are not addressed with existing protocols, you are more than welcome to provide text. I'll try to read the documents you provided and evaluate myself the usefulness of an evaluation of an additional protocol. Still, the decision to add new protocols is not mine but for the whole WG and chair to decide. Regards, Jukka On Wed, 16 Jul 2003, HELENA RUTE SOFIA wrote: > All, > > Yesterday (Monday July 14th), in the NSIS meeting, it was mentioned that > additional QoS signaling protocols could still be added to the draft > "Analysis of Existing Quality of Service Signaling Protocols". > > We (myself and Roch Gue'rin) developed a novel inter-domain aggregation > signaling protocol, SICAP (Shared-Segment Inter-domain Control Aggregation > Protocol) that we thought might be of interest to the analysis above. > Being an inter-domain aggregation solution (as BGRP), SICAP was > developed not so much to be "another" alternative to BGRP, but more as > part of an "exercise" aimed at gaining a better understanding of the overall > solution space. In particular, we felt that while the sink-tree approach > of BGRP offered clear advantages from an operational point of view, it was > not obvious if and how this affected scalability and where BGRP actually > stood, in the space of possible solutions. > > So,the investigation, besides identifying a possible > alternative to BGRP (SICAP performs shared-segment aggregation), also > illustrated the existence of a range of options and > showed that further improvements in a protocol's ability to aggregate > state information were indeed feasible. > > More detailed information on SICAP and the associated investigation can be > found at: > http://m306pc7.seas.upenn.edu/mnlab/paper/icnp02_173.pdf > (addresses the aggregation algorithms; presents simulation results) > > http://m306pc7.seas.upenn.edu/mnlab/paper/hpsr03_paper3743.pdf > (addresses SICAP's design and compares it against BGRP) > > If there is interest and a sense that this could be a useful addition to > the topics addressed in the QoS protocols analysis draft, we would be more > than happy to provide additional details. > > Rute > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 16 04:11:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20309 for ; Wed, 16 Jul 2003 04:11:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chNN-00014A-QS for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 04:11:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G8B1mO004094 for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 04:11:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chNN-00013u-3t; Wed, 16 Jul 2003 04:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chMr-00012A-Ck for nsis@optimus.ietf.org; Wed, 16 Jul 2003 04:10:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20276 for ; Wed, 16 Jul 2003 04:10:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chMo-0004QT-00 for nsis@ietf.org; Wed, 16 Jul 2003 04:10:26 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 19chMd-0004Ps-00 for nsis@ietf.org; Wed, 16 Jul 2003 04:10:15 -0400 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Wed, 16 Jul 2003 10:08:42 +0200 Received: from docomolab-euro.com ([192.168.99.14]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 16 Jul 2003 10:08:41 +0200 Message-ID: <3F150809.9080506@docomolab-euro.com> Date: Wed, 16 Jul 2003 10:08:41 +0200 From: mendes User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: fu@cs.uni-goettingen.de, nsis@ietf.org Subject: Re: [NSIS] Modeling of mobility? References: In-Reply-To: Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-6d0b4820-6a49-4d36-b854-203776fdf823" X-OriginalArrivalTime: 16 Jul 2003 08:08:42.0462 (UTC) FILETIME=[78AEDFE0:01C34B71] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-6d0b4820-6a49-4d36-b854-203776fdf823 Content-Type: multipart/alternative; boundary="------------000709040008060004050403" --------------000709040008060004050403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi Paulo, > > There seems to have been misunderstanding between what Xiaoming was > trying to say. I thought he was trying to suggest tying NSIS > signaling with some MIP signaling, which is out of scope for NSIS. > NSIS should be concerned with the data path after handovers have > occured, so it should be generic and not tied to any mobility signaling. I completely agree with keeping the goal on generic mobility. Although the framework speaks about mobility, I had my doubts about if the generic mobility issues were going to be considered in NTLP and in some QoS related NLSP. Now, this issue is clear to me :). Cheers Paulo > At present, since much of MIP related signaling is still preliminary, > I don't think we should be considering this like HMIP, FMIP, etc. yet > in NSIS, but rather stick with general mobility. I believe the > discussion up until now has been captured in the Framework document. > As the framework is nearing completion, perhaps if you have comments > on that section, it would be good to send them to the list. thanks, > John > > -----Original Message----- > *From:* ext mendes [mailto:mendes@docomolab-euro.com] > *Sent:* 15 July, 2003 12:51 > *To:* Loughney John (NRC/Helsinki) > *Cc:* fu@cs.uni-goettingen.de; nsis@ietf.org > *Subject:* Re: [NSIS] Modeling of mobility? > > Hi John, > > I don't understand what you want to transmit with the sentence > below. If I'm correct, MIPv6 Signaling and Handoff Optimization > BOF is chartered to study HMIP and Fast-Handover issues only, in > order to improve MIP performance.This BOF does not consider > anything especific to signaling protocols like NSIS.. > > I think the question is not to change the MIPv6 Signaling and > Handoff Optimization BOF to include QoS signalinfg specific > issues, but to allow the future signaling transport protocol (read > it NSIS) to be used in mobile environments. > > Just for clarify this issue: Are you saying that NSIS should not > consider mobility? This is, are you assuming that the future > Internet, for which NSIS is being made, will not have suficient > mobile devices to justify a mobile-aware signaling transport protocol? > > Paulo > > john.loughney@nokia.com wrote: > >>Hi Xiaoming, >> >>You may like to bring this up at the MIPv6 Signaling and >>Handoff Optimization BOF on Wednesday, as this sounds >>somewhat out of scope for NSIS. >> >>John >> >> >> >> >> >>>-----Original Message----- >>>From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] >>>Sent: 14 July, 2003 21:53 >>>To: nsis@ietf.org >>>Subject: [NSIS] Modeling of mobility? >>> >>> >>>Hi all, >>> >>>Do you think it is useful to have a general modeling of data path >>>features caused by (or, "related to") mobility? Examples: >>>- independence of specific mobility protocols >>>- IP-in-IP encasulation/tunnel >>>- local repair & synchronization >>>- even, anticipated handovers >>> >>>Cheers, >>>Xiaoming >>> >>>PS. I've made the slides "mobility support in NSIS" online at: >>>http://user.informatik.uni-goettingen.de/~fu/nsis/IETF-fu-nsis >>>-mobility.pdf >>> >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >>> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > --------------000709040008060004050403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote:
Hi Paulo,
 
There seems to have been misunderstanding between what Xiaoming was trying to say.  I thought he was trying to suggest tying NSIS signaling with some MIP signaling, which is out of scope for NSIS.  NSIS should be concerned with the data path after handovers have occured, so it should be generic and not tied to any mobility signaling. 
I completely agree with keeping the goal on generic mobility. Although the framework speaks about mobility, I had my doubts about if the generic mobility issues were going to be considered in NTLP and in some QoS related NLSP. Now, this issue is clear to me :).

Cheers
Paulo
At present, since much of MIP related signaling is still preliminary, I don't think we should be considering this like HMIP, FMIP, etc. yet in NSIS, but rather stick with general mobility.  I believe the discussion up until now has been captured in the Framework document.  As the framework is nearing completion, perhaps if you have comments on that section, it would be good to send them to the list. 
thanks,
John
-----Original Message-----
From: ext mendes [mailto:mendes@docomolab-euro.com]
Sent: 15 July, 2003 12:51
To: Loughney John (NRC/Helsinki)
Cc: fu@cs.uni-goettingen.de; nsis@ietf.org
Subject: Re: [NSIS] Modeling of mobility?

Hi John,

I don't understand what you want to transmit with the sentence below. If I'm correct, MIPv6 Signaling and Handoff Optimization BOF is chartered to study HMIP and Fast-Handover issues only, in order to improve MIP performance.This BOF does not consider anything especific to signaling protocols like NSIS..

I think the question is not to change the MIPv6 Signaling and Handoff Optimization BOF to include QoS signalinfg specific issues, but to allow the future signaling transport protocol (read it NSIS) to be used in mobile environments.

Just for clarify this issue: Are you saying that NSIS should not consider mobility? This is, are you assuming that the future Internet, for which NSIS is being made, will not have suficient mobile devices to justify a mobile-aware signaling transport protocol?

Paulo

john.loughney@nokia.com wrote:
Hi Xiaoming,

You may like to bring this up at the MIPv6 Signaling and 
Handoff Optimization BOF on Wednesday, as this sounds 
somewhat out of scope for NSIS.

John



  
-----Original Message-----
From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de]
Sent: 14 July, 2003 21:53
To: nsis@ietf.org
Subject: [NSIS] Modeling of mobility?


Hi all,

Do you think it is useful to have a general modeling of data path 
features caused by (or, "related to") mobility? Examples:
- independence of specific mobility protocols
- IP-in-IP encasulation/tunnel
- local repair & synchronization
- even, anticipated handovers

Cheers,
Xiaoming

PS. I've made the slides "mobility support in NSIS" online at:
http://user.informatik.uni-goettingen.de/~fu/nsis/IETF-fu-nsis
-mobility.pdf


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

    

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


--------------000709040008060004050403-- ------=_NextPartTM-000-6d0b4820-6a49-4d36-b854-203776fdf823-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 16 05:06:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22052 for ; Wed, 16 Jul 2003 05:06:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciEc-0003vS-CZ for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 05:06:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G962O0015076 for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 05:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciEb-0003v1-P8; Wed, 16 Jul 2003 05:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciEX-0003uk-SD for nsis@optimus.ietf.org; Wed, 16 Jul 2003 05:05:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22044 for ; Wed, 16 Jul 2003 05:05:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciEU-0004vi-00 for nsis@ietf.org; Wed, 16 Jul 2003 05:05:54 -0400 Received: from lion.seas.upenn.edu ([158.130.12.194]) by ietf-mx with esmtp (Exim 4.12) id 19ciEJ-0004uk-00 for nsis@ietf.org; Wed, 16 Jul 2003 05:05:44 -0400 Received: from blue.seas.upenn.edu (BLUE.SEAS.UPENN.EDU [158.130.64.177]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6G91kM1031331 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Jul 2003 05:01:46 -0400 Received: from blue.seas.upenn.edu (localhost [127.0.0.1]) by blue.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6G91jOM019700; Wed, 16 Jul 2003 05:01:45 -0400 (EDT) Received: from localhost (rsofia@localhost) by blue.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6G91jlA019697; Wed, 16 Jul 2003 05:01:45 -0400 (EDT) Date: Wed, 16 Jul 2003 05:01:44 -0400 (EDT) From: HELENA RUTE SOFIA To: Jukka MJ Manner cc: nsis@ietf.org, Subject: Re: [NSIS] QoS analysis draft: novel inter-domain approach In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Jukka, > you feel that SICAP has some unique properties and solutions that are not > addressed with existing protocols, you are more than welcome to provide > text. I'll try to read the documents you provided and evaluate myself the > usefulness of an evaluation of an additional protocol. Still, the decision > to add new protocols is not mine but for the whole WG and chair to decide. the current analysis draft covers several protocols; however, and even though it provides input on e2e signaling protocols, there is not an explicit division of solutions, in terms of scope (intra-domain, inter-domain). So, in the inter-domain context, only BGRP is presented; hence, I believe SICAP does bring additional benefits: 1) it outperforms BGRP in state; 2) it presents another type of aggregation, showing that the sink-tree is not the only solution. Also, given that aggregation is to be included in the next document on the QoS-NSLP proposal, and given also that aggregation is still an open issue, I do believe that SICAP brings a significant contribution to this field. So, I think it should be considered in the context of the analysis document... Rute _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 16 08:57:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28420 for ; Wed, 16 Jul 2003 08:57:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19clqA-0000dD-US for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 08:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GCv2Ef002417 for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 08:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19clq9-0000c6-W3; Wed, 16 Jul 2003 08:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19clpH-0000bJ-78 for nsis@optimus.ietf.org; Wed, 16 Jul 2003 08:56:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28366 for ; Wed, 16 Jul 2003 08:56:03 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19clpF-0006pA-00 for nsis@ietf.org; Wed, 16 Jul 2003 08:56:05 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19clp4-0006nv-00 for nsis@ietf.org; Wed, 16 Jul 2003 08:55:55 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GCrvk25537 for ; Wed, 16 Jul 2003 15:53:57 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 15:53:56 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 15:53:55 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 15:53:55 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 15:53:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] QoS analysis draft: novel inter-domain approach Date: Wed, 16 Jul 2003 15:53:54 +0300 Message-ID: Thread-Topic: [NSIS] QoS analysis draft: novel inter-domain approach Thread-Index: AcNLebqn1vlU5vBJSHiJRsxhMrMTVgAH3s8Q To: , Cc: , X-OriginalArrivalTime: 16 Jul 2003 12:53:54.0840 (UTC) FILETIME=[50748980:01C34B99] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Helena, Send text to the mailing list & we will see if the WG is interested. John > -----Original Message----- > From: ext HELENA RUTE SOFIA [mailto:rsofia@seas.upenn.edu] > Sent: 16 July, 2003 12:02 > To: Jukka MJ Manner > Cc: nsis@ietf.org; guerin@ee.upenn.edu > Subject: Re: [NSIS] QoS analysis draft: novel inter-domain approach >=20 >=20 > Jukka, >=20 > > you feel that SICAP has some unique properties and=20 > solutions that are not > > addressed with existing protocols, you are more than=20 > welcome to provide > > text. I'll try to read the documents you provided and=20 > evaluate myself the > > usefulness of an evaluation of an additional protocol.=20 > Still, the decision > > to add new protocols is not mine but for the whole WG and=20 > chair to decide. >=20 > the current analysis draft covers several protocols; however, and even > though it provides input on e2e signaling protocols, there is=20 > not an explicit > division of solutions, in terms of scope (intra-domain, inter-domain). > So, in the inter-domain context, only BGRP is presented;=20 > hence, I believe > SICAP does bring additional benefits: > 1) it outperforms BGRP in state; > 2) it presents another type of aggregation, showing that the=20 > sink-tree is > not the only solution. >=20 > Also, given that aggregation is to be included in the next=20 > document on the > QoS-NSLP proposal, and given also that aggregation is still=20 > an open issue, > I do believe that SICAP brings a significant contribution to=20 > this field. > So, I think it should be considered in the context of the analysis > document... >=20 > Rute >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 16 11:40:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06369 for ; Wed, 16 Jul 2003 11:40:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coNs-0002eV-RE for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 11:40:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFe0D3010183 for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 11:40:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coNs-0002e8-IU; Wed, 16 Jul 2003 11:40:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coN8-0002WS-1d for nsis@optimus.ietf.org; Wed, 16 Jul 2003 11:39:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06324 for ; Wed, 16 Jul 2003 11:39:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coN7-0000Zw-00 for nsis@ietf.org; Wed, 16 Jul 2003 11:39:13 -0400 Received: from smtp.ietf57.telekom.at ([81.160.16.8]) by ietf-mx with esmtp (Exim 4.12) id 19coMw-0000ZY-00 for nsis@ietf.org; Wed, 16 Jul 2003 11:39:02 -0400 Received: from ccrle.nec.de (n-pool-0.ietf57.telekom.at [81.160.167.164]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6GFcCk27311 for ; Wed, 16 Jul 2003 17:38:12 +0200 (MEST) Message-ID: <3F15715C.3020206@ccrle.nec.de> Date: Wed, 16 Jul 2003 17:38:04 +0200 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP References: <3F13CA3E.3030406@cs.columbia.edu> In-Reply-To: <3F13CA3E.3030406@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > To avoid artificial choices and unnecesary disagreements: I am arguing > that all three are needed and can be readily supported without undue > complexity in implementation, time or space. I'm *NOT* arguing that we > need to make a choice here - the NSLP or NE gets to pick according to > whatever trade-off it deems reasonable. (Who gets to suggest or force > the choice is indeed an open issue.) I like the vision of supporting all three. I might even want to add a 4th, but this needs some more thinking on myside. Itmakes the NTLP pretty generic to be applicable in various environment running various NSLPs. Actually, I regard this open issue a much more interesting. It might raise issues on is the end system/NSLP initiator know what he needs. Is an adaption to an underlying L2 technology the relevant decision criterion. Then there is the question which entity is allowed to overrule another entities request. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 16 13:12:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08845 for ; Wed, 16 Jul 2003 13:12:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cpov-0007vX-9u for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 13:12:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GHC1nl030465 for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 13:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cpou-0007vG-Uy; Wed, 16 Jul 2003 13:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cpof-0007rr-Jq for nsis@optimus.ietf.org; Wed, 16 Jul 2003 13:11:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08815 for ; Wed, 16 Jul 2003 13:11:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cpod-0001Gr-00 for nsis@ietf.org; Wed, 16 Jul 2003 13:11:43 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19cpoS-0001Gg-00 for nsis@ietf.org; Wed, 16 Jul 2003 13:11:32 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6GHB7PW020153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 Jul 2003 13:11:08 -0400 (EDT) From: "Charles Q. Shen" To: "'Xiaoming Fu'" , Subject: RE: Message ID v.s. Branch ID --was Re: [NSIS] Proposed draft "Mobility Support in NSIS" Date: Wed, 16 Jul 2003 13:11:03 -0400 Organization: Columbia University Message-ID: <001201c34bbd$3d280180$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3F125C1D.8050106@cs.uni-goettingen.de> Importance: Normal X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Xiaoming, comments followed. > Charles Q. Shen wrote: > > Ok, so you are talking about the Synchronization/out of sequence > > problem. Usually it is solved by some kind of messages ID/sequence > > number (e.g., in related routing protocol updates, RSVP > refreshes, and > > our RSVP-MIP test-bed). I am not very sure what is the difference > > between the Branch ID you mentioned in your draft from the > message ID > > approach. > > > Xiaoming Fu wrote: > Yes, the following terms sound similar: > Epoch (RFC2961) ~ Session ID > Message ID (RFC2961) ~ Branch ID > However, they are not quite the same. > > To my understanding, Message ID (together with Epoch) concerns with > signaling messages between _peering neighbers_, where out-of-order > problem can come from retransmission/refresh. (Correct me if > I'm wrong). While talking about Branch ID, I meant it > (together Session ID) can be > used for avoiding syncronization of signaling messages along > different > branches (each can consist of multiple hops). This can be generally > useful for determining end of (explicit) teardown message to > forward on > along the common path. > My understanding is: a Message ID/Sequence Number approach can be used to detect out of order messages (carrying refresh information either QoS or mobility related). Whether it is of hop-by-hop (_peering neighbers_) significance or end-to-end significance depends on how it is used. We used Sequence Number in Mobility Update objects in our RSVP-MIP framework, which I guess might be similar to the branch ID you mentioned. Thanks and regards, Charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 16 15:14:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14151 for ; Wed, 16 Jul 2003 15:14:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19criz-00085B-4Y for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 15:14:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GJE1hY031065 for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 15:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19criy-00084v-TQ; Wed, 16 Jul 2003 15:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19criU-00084P-Rx for nsis@optimus.ietf.org; Wed, 16 Jul 2003 15:13:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14035 for ; Wed, 16 Jul 2003 15:13:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19criT-0002Nz-00 for nsis@ietf.org; Wed, 16 Jul 2003 15:13:29 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19criI-0002Nt-00 for nsis@ietf.org; Wed, 16 Jul 2003 15:13:19 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6GJClss018775 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 Jul 2003 15:12:50 -0400 (EDT) From: "Charles Q. Shen" To: , , Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Date: Wed, 16 Jul 2003 15:12:43 -0400 Organization: Columbia University Message-ID: <001401c34bce$3dedb2c0$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, You are certainly right that it is pre-mature to make any conclusive arguments about NSIS-mobility details at this time. However, since the framework document is approaching its completion, while work from RSVP-mobility to NSIS-mobility is probably still in its early phase, I do not feel you can fit everything into the framework/requirement document. My personal view is: aside from puting matured framework level mobility issues into the framework document, keeping a separate disscussion regarding ongoing NSIS-mobility details would be beneficial. Regards, Charles > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of john.loughney@nokia.com > Sent: Monday, July 14, 2003 3:03 PM > To: fu@cs.uni-goettingen.de; nsis@ietf.org > Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 > > > Hi Xiaoming, > > I think it is premature to do this at the moment - the > framework document & the analysis document cover some > mobility issues - > you should contact the author of those doucments to see what > overlap, if any, there is between your proposal and those documents. > > John > > > -----Original Message----- > > From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > > Sent: 14 July, 2003 21:14 > > To: nsis@ietf.org > > Subject: [NSIS] mobility-related requirements from nsis-req-08 > > > > > > Hi all, > > > > As John suggested, I tried to sort out requirements (out of > > nsis-req-08) > > which are related to mobility and hope they helpful for > > related discussions: > > > > 5.2 Signaling > > Flows...............................................10 > > 5.2.2 NSIS MUST support path-coupled and MAY support > > path-decoupled > > > > signaling.........................................................11 > > ==> relates to different handling of MIP IP-in-IP > > encapsulation (tunnel). > > > > 5.3 > > Messaging.....................................................11 > > 5.3.1 Explicit erasure of state MUST be > > possible..................12 > > ==> related to explicit teardown of obsoleted branch. Maybe > a flag to > > indicate whether to do explicit teardown. > > > > 5.4 Control > > Information...........................................13 > > 5.4.3 State MUST be addressed independent of flow > > identification..14 > > ==> mobility support may make use of this requirement. > > > > 5.5 > > Performance...................................................15 > > 5.5.1 > > Scalability.................................................15 > > ==> NSIS "MUST be scalable in number of hand-offs in mobile > > environments." This can be related to, e.g., capability of > > dealing with > > pingpong, fast movement. > > > > 5.6 > > Flexibility...................................................16 > > 5.6.2 Flexibility in the placement of the NSIS > > Initiator/Responder16 > > ==> somehow related to the issue of either MN or CN as data sender. > > > > 5.8 > > Mobility......................................................19 > > 5.8.1 Allow efficient service re-establishment after > > handover.....19 > > ==> effectively establish states in new path due to handover. > > > > 5.9 Interworking with other protocols and > > techniques..............19 > > 5.9.1 MUST interwork with IP > > tunneling............................19 > > ==> IP-in-IP encapsulation is one type of IP tunnels > > > > 5.9.2 MUST NOT constrain either to IPv4 or > > IPv6...................19 > > ==> should be able to work with both Mobile IPv4 protocols > and Mobile > > IPv6 protocols. > > > > 5.9.5 SHOULD work with seamless handoff > > protocols.................20 > > ==> e.g., CTP > > > > Cheers, > > Xiaoming > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 16 17:13:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17898 for ; Wed, 16 Jul 2003 17:13:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ctaA-0006GT-Bz for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 17:13:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GLD2la024064 for nsis-archive@odin.ietf.org; Wed, 16 Jul 2003 17:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cta9-0006Fx-Q6; Wed, 16 Jul 2003 17:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ctZK-0006FP-DR for nsis@optimus.ietf.org; Wed, 16 Jul 2003 17:12:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17862 for ; Wed, 16 Jul 2003 17:12:05 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ctZI-0003SF-00 for nsis@ietf.org; Wed, 16 Jul 2003 17:12:08 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ctZ7-0003S3-00 for nsis@ietf.org; Wed, 16 Jul 2003 17:11:57 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GLBaB24470 for ; Thu, 17 Jul 2003 00:11:36 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 00:11:36 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 00:11:36 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 00:11:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Reliable Transport for NTLP Date: Thu, 17 Jul 2003 00:11:35 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNLsJMoyMtUrCL6TnCHkT7edm6ZuwALYf/w To: , X-OriginalArrivalTime: 16 Jul 2003 21:11:36.0145 (UTC) FILETIME=[D72E1410:01C34BDE] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Marcus, Clipping part of your text out for further discussion: > It might raise issues on is the end system/NSLP initiator know what he = needs.=20 I take it you are proposing a few questions to study, for example: > Is an adaption to an underlying L2 technology the relevant decision = criterion.=20 In my mind, it is hard to say, I do feel uncomfortable about adapting = layer 3 4/5 protocols based upon layer 2 considerations - I am not sure if we = have any good ways to do this & I am not sure it is in our charter to invent = them. > Then there is the question which entity is allowed to overrule another = entities=20 > request. Agreed, however, I have a tendency to think that the end-points should = have the=20 ultimate say in this ... John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 03:06:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19244 for ; Thu, 17 Jul 2003 03:06:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d2q2-0006NU-4N for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 03:06:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H762mk024499 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 03:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d2q1-0006N2-KI; Thu, 17 Jul 2003 03:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d2pX-0006MK-NN for nsis@optimus.ietf.org; Thu, 17 Jul 2003 03:05:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19227 for ; Thu, 17 Jul 2003 03:05:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d2pT-0001zY-00 for nsis@ietf.org; Thu, 17 Jul 2003 03:05:27 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19d2pI-0001z8-00 for nsis@ietf.org; Thu, 17 Jul 2003 03:05:17 -0400 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h6H74eCf022381; Thu, 17 Jul 2003 09:04:40 +0200 (MET DST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h6H74bl2001437; Thu, 17 Jul 2003 09:04:38 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.6+Sun/8.10.2) id h6H74c123405; Thu, 17 Jul 2003 09:04:38 +0200 (MEST) Message-Id: <200307170704.h6H74c123405@janus.cs.utwente.nl> To: john.loughney@nokia.com Subject: RE: [NSIS] comments on NTLP design proposals Date: Thu, 17 Jul 2003 07:04:37 +0000 X-Mailer: IlohaMail/0.7.2 @ webmail.cs.utwente.nl From: "karagiannis" Reply-To: "karagiannis" CC: nsis@ietf.org Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John Please see my comments in line: >My opinion is that a basic raw-IP / UDP mode is supported by default >and we look at how TCP/SCTP could be supported without running into >state bloat caused by multiple protocol support. It does not need >to be a either / or question. I totally agree that a basic raw-IP / UDP mode should be supported by default. This means that this mode is the mandatory mode. A NSLP initiator should be able to select this mode. I am not sure about the TCP/SCTP mode. We probably have to investigate its complications. However, even this mode will be supported it should be an optional mode, that might also be selected by a NSLP initiator. >I think we can consider how much of 2205 + 2961 needs to be supported. >I have not suggested, myself, dropping all of 2961, but to look at >what to support. 2961 lists the following enhancements to RSVP: > > RSVP Bundle Message > MESSAGE_ID Extension > Summary Refresh Extension > Exponential Back-Off Procedures > >The Exponential Back-Off Procedures is probably not needed. The other three enhancements are actually interesting in quite static reservation environments. In mobile/wireless environments, where there is a high amount of dynamic reservations (due to handoff procedures) these features are not very usefull. Therefore, in my opinion these features should be optional. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 03:20:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19716 for ; Thu, 17 Jul 2003 03:20:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d33d-0007kS-5G for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 03:20:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H7K4T1029767 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 03:20:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d33Z-0007jy-C5; Thu, 17 Jul 2003 03:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d32p-0007hR-5c for nsis@optimus.ietf.org; Thu, 17 Jul 2003 03:19:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19677 for ; Thu, 17 Jul 2003 03:19:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d32m-00028r-00 for nsis@ietf.org; Thu, 17 Jul 2003 03:19:12 -0400 Received: from smtp.ietf57.telekom.at ([81.160.16.8]) by ietf-mx with esmtp (Exim 4.12) id 19d32b-00028Z-00 for nsis@ietf.org; Thu, 17 Jul 2003 03:19:02 -0400 Received: from ccrle.nec.de (n-pool-0.ietf57.telekom.at [81.160.167.164]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6H7IKk19777; Thu, 17 Jul 2003 09:18:20 +0200 (MEST) Message-ID: <3F164DAE.9000606@ccrle.nec.de> Date: Thu, 17 Jul 2003 09:18:06 +0200 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, > I take it you are proposing a few questions to study, for example: > > >>Is an adaption to an underlying L2 technology the relevant decision criterion. > > > In my mind, it is hard to say, I do feel uncomfortable about adapting layer 3 > 4/5 protocols based upon layer 2 considerations - I am not sure if we have > any good ways to do this & I am not sure it is in our charter to invent them. > For the NTLP this might turn into a configuration capability on each single node/interface. Whether this is a good idea or not I have not made up my mind. And you do not need to invent something, but we have to talk about the knobs and where they are placed, and which entity control the knob anyway. Also in Melindas approach there are quite a number of knobs per interface (e.g. time out for various mechnisms etc.) > >>Then there is the question which entity is allowed to overrule another entities >>request. > > > Agreed, however, I have a tendency to think that the end-points should have the > ultimate say in this ... Can you give an argument, which makes you think the end-point is a good idea? Given it is the end-point. Is it the NSLP on the end-point, the user(application) using the protocol, or the NTLP based on information about L2 access technology. Marcus > John > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 03:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20211 for ; Thu, 17 Jul 2003 03:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3FC-0008Et-J6 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 03:32:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H7W232031667 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 03:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3FC-0008Ef-CU; Thu, 17 Jul 2003 03:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Ev-0008D3-Ra for nsis@optimus.ietf.org; Thu, 17 Jul 2003 03:31:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20120 for ; Thu, 17 Jul 2003 03:31:42 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3Et-0002JX-00 for nsis@ietf.org; Thu, 17 Jul 2003 03:31:43 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19d3Ei-0002JO-00 for nsis@ietf.org; Thu, 17 Jul 2003 03:31:32 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H7UrJ09425 for ; Thu, 17 Jul 2003 10:30:53 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 10:30:53 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 10:30:53 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 10:30:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Reliable Transport for NTLP Date: Thu, 17 Jul 2003 10:30:52 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNMM5uUJTX0Ls2hQIG+pdBD0xaIIgAAO2BA To: Cc: X-OriginalArrivalTime: 17 Jul 2003 07:30:52.0610 (UTC) FILETIME=[5A28B220:01C34C35] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Marcus, > >>Is an adaption to an underlying L2 technology the relevant=20 > decision criterion.=20 > >=20 > >=20 > > In my mind, it is hard to say, I do feel uncomfortable about = adapting layer 3 > > 4/5 protocols based upon layer 2 considerations - I am not sure if = we have > > any good ways to do this & I am not sure it is in our charter to = invent them. > > >=20 > For the NTLP this might turn into a configuration capability on each=20 > single node/interface. Whether this is a good idea or not I have not=20 > made up my mind. And you do not need to invent something, but we have = to=20 > talk about the knobs and where they are placed, and which entity = control=20 > the knob anyway. This sounds more & more like operational issues with the protocols or=20 issues how the protocol can be run over specific layer-2s or in=20 special deployments. I think, but I could be wrong, that these belong best outside of the protocol document, but in an operational doc, deployment doc, applicability statement, bcp-type document, for example. > Also in Melindas approach there are quite a number of knobs per=20 > interface (e.g. time out for various mechnisms etc.) Well, protocols always need to define to have time-outs, etc. I would have to re-read Melinda's document to see what you are refering to, but I was not thinking of Melinda's document what I suggested what I did. > >>Then there is the question which entity is allowed to=20 > overrule another entities=20 > >>request. > >=20 > >=20 > > Agreed, however, I have a tendency to think that the end-points = should have the=20 > > ultimate say in this ... >=20 > Can you give an argument, which makes you think the end-point is a = good=20 > idea? Given it is the end-point. Is it the NSLP on the end-point, the=20 > user(application) using the protocol, or the NTLP based on=20 > information about L2 access technology. The end-user is requesting service, s authorized for the service and is=20 in the best position to know what is his expectations for the service. I have an allergic reaction to the suggestion that the network better understands my wants / my needs as an enduser than I do. However, I could be mis-interpretying your comments. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 03:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20316 for ; Thu, 17 Jul 2003 03:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3H8-0008R7-2b for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 03:34:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H7Y24g032412 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 03:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3H7-0008Qf-NG; Thu, 17 Jul 2003 03:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Gz-0008QF-0e for nsis@optimus.ietf.org; Thu, 17 Jul 2003 03:33:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20297 for ; Thu, 17 Jul 2003 03:33:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3Gw-0002Kh-00 for nsis@ietf.org; Thu, 17 Jul 2003 03:33:50 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19d3Gl-0002Kc-00 for nsis@ietf.org; Thu, 17 Jul 2003 03:33:40 -0400 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h6H7XPCf023248; Thu, 17 Jul 2003 09:33:25 +0200 (MET DST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h6H7XMl2005961; Thu, 17 Jul 2003 09:33:23 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.6+Sun/8.10.2) id h6H7XNE29294; Thu, 17 Jul 2003 09:33:23 +0200 (MEST) Message-Id: <200307170733.h6H7XNE29294@janus.cs.utwente.nl> To: Henning Schulzrinne Subject: Re: [NSIS] Reliable Transport for NTLP Date: Thu, 17 Jul 2003 07:33:22 +0000 X-Mailer: IlohaMail/0.7.2 @ webmail.cs.utwente.nl From: "karagiannis" Reply-To: "karagiannis" CC: nsis@ietf.org Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Henning Regarding the reliability issues, I think that the Melinda`s proposal which was stated during the NSIS meeting of Monday, was right. In order to make a decission on if per-hop realibility of some NTLP messages is needed, a motivation of its use is needed. Please note that in environments where performance in terms of delay is important, per-hop reliability (due to its complexity) is of less importance. Best Regards, Georgios Dr. ir. Georgios Karagiannis Group: Design and Analysis of Communication Systems (DACS) University of Twente The Netherlands _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 03:45:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20938 for ; Thu, 17 Jul 2003 03:45:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Rp-00019H-HQ for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 03:45:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H7j5oZ004398 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 03:45:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Rm-00018p-3W; Thu, 17 Jul 2003 03:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Re-00017a-Ir for nsis@optimus.ietf.org; Thu, 17 Jul 2003 03:44:54 -0400 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20861 for ; Thu, 17 Jul 2003 03:44:50 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H7iqJ24706 for ; Thu, 17 Jul 2003 10:44:52 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 10:44:52 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 10:44:52 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 10:44:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Reliable Transport for NTLP Date: Thu, 17 Jul 2003 10:44:51 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNMNdLt4UEj9uURTGevg2VTP3gZbAAABQKQ To: , Cc: X-OriginalArrivalTime: 17 Jul 2003 07:44:51.0630 (UTC) FILETIME=[4E40FCE0:01C34C37] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Georgios & Henning, > Regarding the reliability issues, I think that the Melinda`s proposal=20 > which was stated during the NSIS meeting of Monday, was right. > In order to make a decission on if per-hop realibility of some=20 > NTLP messages is needed, a motivation of its use is needed.=20 >=20 > Please note that in environments where performance in terms of delay=20 > is important, per-hop reliability (due to its complexity) is of less > importance. Point of procedure. I am working from the assumption that we are working on (some) solutions where per-hop reliability is not needed, therefore NTLP should be able to run in a mode without per-hop=20 reliability. This is consistent with our updated charter, which=20 states: The intention is to re-use, where appropriate, the protocol mechanisms of RSVP, while at the same time simplifying it=20 and applying a more general signaling model. =20 Please note that our updated charter is approved, there has just been some difficulties with the IETF Secretariat at posting the updated charter. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 04:05:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21964 for ; Thu, 17 Jul 2003 04:05:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3l8-0002tM-5g for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:05:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8523k011115 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3l7-0002t9-KE; Thu, 17 Jul 2003 04:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3l1-0002sg-UF for nsis@optimus.ietf.org; Thu, 17 Jul 2003 04:04:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21945 for ; Thu, 17 Jul 2003 04:04:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3kz-0002gK-00 for nsis@ietf.org; Thu, 17 Jul 2003 04:04:53 -0400 Received: from lion.seas.upenn.edu ([158.130.12.194]) by ietf-mx with esmtp (Exim 4.12) id 19d3ko-0002fA-00 for nsis@ietf.org; Thu, 17 Jul 2003 04:04:42 -0400 Received: from red.seas.upenn.edu (RED.SEAS.UPENN.EDU [158.130.64.176]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6H82QM1020947 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 17 Jul 2003 04:02:26 -0400 Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6H82QWQ028781; Thu, 17 Jul 2003 04:02:26 -0400 (EDT) Received: from localhost (rsofia@localhost) by red.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6H82O0j028778; Thu, 17 Jul 2003 04:02:25 -0400 (EDT) Date: Thu, 17 Jul 2003 04:02:24 -0400 (EDT) From: "Rute C. Sofia" To: john.loughney@nokia.com cc: jmanner@cs.Helsinki.FI, , In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [NSIS] SICAO description, QoS proposals analysis draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , John, here goes the description on SICAP. I tried to address the same issues already being addressed on the analysis draft. On Wed, 16 Jul 2003 john.loughney@nokia.com wrote: > Hi Helena, > > Send text to the mailing list & we will see if the WG is interested. > ......................................................... SICAP (Shared-segment Inter-domain Control Aggregation protocol) is an inter-domain signaling solution that performs shared-segment aggregation on the Autonomous System (AS) level with the purpose of reducing state required at Boundary Routers. SICAP performs aggregation based on path segments that different reservations share. Thus, reservations may be merged into aggregates that do not extend necessarily all the way until the reservation's destination. The motivation for creating "shorter" aggregates is, on the one hand, their abilitity to more easily accomodate future requests, and on the other hand, the minimization of aggregates created and consequently, the reduction of state required to manage established reservations. However, and in contrast to the sink-tree approach (used by BGRP), the shared-segment approach introduces intermediate deaggregation locations: these are ASes where aggregates may experience "re-aggregation". At these locations, routers that perform aggregation (AS egress routers) have to keep track of the mapping between reservations and aggregates. One possible way of doing this is to keep each reservation identifier and corresponding resources stored at each aggregator. However, this solution incurs a high state penalty on state. SICAP avoids this state penalty by keeping track of the mapping between aggregates and reservations at the level of destination domains rather than explicitly mapping individual reservations to aggregates. In other words, SICAP maintains per aggregate a list of the destination prefixes advertised by the destination AS an aggregate provides access to. In terms of messaging sequence, SICAP is very similar to BGRP: it is sender-initiated in the sense that the first border router triggers the process of reservation establishment; it establishes reservations using a two-phase establishment mechanism: on the first phase, the path is probed using a message that requires no state, and on the second phase, resources are allocated. Message delivery is reliable, given that SICAP exchanges messages over TCP connections. SICAP and BGRP attain the same signaling load, given that they use three similar messages to establish and to explicitely delete reservations. This means that both proposals do not present any signaling load reduction when compared to proposals that do not perform aggregation. In terms of bandwidth, both protocols provision aggregates with the exact bandwidth required by their merged reservations. Hence, their major difference is in state required to manage reservations: we've shown, carrying out simulations with the network simulator version 2, that SICAP significantly reduces state required when compared to BGRP. We consider this to be of importance not so much to offer a better performing alternative to BGRP, but to quantify the performance improvements that might still be available in the research field of control path aggregation. We have also performed a study, and devised a novel mechanism that can be used to lower the signaling load of aggregation approaches. Thanks, Rute _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 04:31:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22859 for ; Thu, 17 Jul 2003 04:31:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4AH-0004tu-Tr for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:31:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8V10S018822 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4AH-0004tQ-Of; Thu, 17 Jul 2003 04:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d49W-0004lc-R6 for nsis@optimus.ietf.org; Thu, 17 Jul 2003 04:30:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22841 for ; Thu, 17 Jul 2003 04:30:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d49T-00039F-00 for nsis@ietf.org; Thu, 17 Jul 2003 04:30:11 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 19d49I-00036h-00 for nsis@ietf.org; Thu, 17 Jul 2003 04:30:01 -0400 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Thu, 17 Jul 2003 10:28:28 +0200 Received: from docomolab-euro.com ([192.168.99.31]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 17 Jul 2003 10:28:28 +0200 Message-ID: <3F165E31.9090309@docomolab-euro.com> Date: Thu, 17 Jul 2003 10:28:33 +0200 From: Paulo Mendes User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles Q. Shen" CC: john.loughney@nokia.com, fu@cs.uni-goettingen.de, nsis@ietf.org Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: <001401c34bce$3dedb2c0$c7f027a0@president> In-Reply-To: <001401c34bce$3dedb2c0$c7f027a0@president> Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-b41cea4c-7899-4347-ac39-88af965bdcb4" X-OriginalArrivalTime: 17 Jul 2003 08:28:28.0566 (UTC) FILETIME=[6611BB60:01C34C3D] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-b41cea4c-7899-4347-ac39-88af965bdcb4 Content-Type: multipart/alternative; boundary="------------060308010906090007040606" --------------060308010906090007040606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Charles Q. Shen wrote: >John, > >You are certainly right that it is pre-mature to make any conclusive >arguments about NSIS-mobility details at this time. However, since the >framework document is approaching its completion, while work from >RSVP-mobility to NSIS-mobility is probably still in its early phase, I >do not feel you can fit everything into the framework/requirement >document. > >My personal view is: aside from puting matured framework level mobility >issues into the framework document, keeping a separate disscussion >regarding ongoing NSIS-mobility details would be beneficial. > > I agree with Charles's opinion. Some discussion is needed to reflect on some issues already mentioned in the Framework, but that need a more detailed analysis, such as seamless handover support for mobile real-time data transmission. Cheers, Paulo >Regards, > >Charles > > > > >>-----Original Message----- >>From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On >>Behalf Of john.loughney@nokia.com >>Sent: Monday, July 14, 2003 3:03 PM >>To: fu@cs.uni-goettingen.de; nsis@ietf.org >>Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 >> >> >>Hi Xiaoming, >> >>I think it is premature to do this at the moment - the >>framework document & the analysis document cover some >>mobility issues - >>you should contact the author of those doucments to see what >>overlap, if any, there is between your proposal and those documents. >> >>John >> >> >> >>>-----Original Message----- >>>From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] >>>Sent: 14 July, 2003 21:14 >>>To: nsis@ietf.org >>>Subject: [NSIS] mobility-related requirements from nsis-req-08 >>> >>> >>>Hi all, >>> >>>As John suggested, I tried to sort out requirements (out of >>>nsis-req-08) >>>which are related to mobility and hope they helpful for >>>related discussions: >>> >>> 5.2 Signaling >>>Flows...............................................10 >>> 5.2.2 NSIS MUST support path-coupled and MAY support >>>path-decoupled >>> >>>signaling.........................................................11 >>>==> relates to different handling of MIP IP-in-IP >>>encapsulation (tunnel). >>> >>> 5.3 >>>Messaging.....................................................11 >>> 5.3.1 Explicit erasure of state MUST be >>>possible..................12 >>>==> related to explicit teardown of obsoleted branch. Maybe >>> >>> >>a flag to >> >> >>>indicate whether to do explicit teardown. >>> >>> 5.4 Control >>>Information...........................................13 >>> 5.4.3 State MUST be addressed independent of flow >>>identification..14 >>>==> mobility support may make use of this requirement. >>> >>> 5.5 >>>Performance...................................................15 >>> 5.5.1 >>>Scalability.................................................15 >>>==> NSIS "MUST be scalable in number of hand-offs in mobile >>>environments." This can be related to, e.g., capability of >>>dealing with >>>pingpong, fast movement. >>> >>> 5.6 >>>Flexibility...................................................16 >>> 5.6.2 Flexibility in the placement of the NSIS >>>Initiator/Responder16 >>>==> somehow related to the issue of either MN or CN as data sender. >>> >>> 5.8 >>>Mobility......................................................19 >>> 5.8.1 Allow efficient service re-establishment after >>>handover.....19 >>>==> effectively establish states in new path due to handover. >>> >>> 5.9 Interworking with other protocols and >>>techniques..............19 >>> 5.9.1 MUST interwork with IP >>>tunneling............................19 >>>==> IP-in-IP encapsulation is one type of IP tunnels >>> >>> 5.9.2 MUST NOT constrain either to IPv4 or >>>IPv6...................19 >>>==> should be able to work with both Mobile IPv4 protocols >>> >>> >>and Mobile >> >> >>>IPv6 protocols. >>> >>> 5.9.5 SHOULD work with seamless handoff >>>protocols.................20 >>>==> e.g., CTP >>> >>>Cheers, >>>Xiaoming >>> >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >>> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > > --------------060308010906090007040606 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Charles Q. Shen wrote:
John, 

You are certainly right that it is pre-mature to make any conclusive
arguments about NSIS-mobility details at this time. However, since the
framework document is approaching its completion, while work from
RSVP-mobility to NSIS-mobility is probably still in its early phase, I
do not feel you can fit everything into the framework/requirement
document. 

My personal view is: aside from puting matured framework level mobility
issues into the framework document, keeping a separate disscussion
regarding ongoing NSIS-mobility details would be beneficial.
I agree with Charles's opinion. Some discussion is needed to reflect on some issues already mentioned in the Framework, but that need a more detailed analysis, such as seamless handover support for mobile real-time data transmission.

Cheers,
Paulo
Regards,

Charles


  
-----Original Message-----
From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On 
Behalf Of john.loughney@nokia.com
Sent: Monday, July 14, 2003 3:03 PM
To: fu@cs.uni-goettingen.de; nsis@ietf.org
Subject: RE: [NSIS] mobility-related requirements from nsis-req-08


Hi Xiaoming,

I think it is premature to do this at the moment - the 
framework document & the analysis document cover some 
mobility issues - 
you should contact the author of those doucments to see what 
overlap, if any, there is between your proposal and those documents.

John

    
-----Original Message-----
From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de]
Sent: 14 July, 2003 21:14
To: nsis@ietf.org
Subject: [NSIS] mobility-related requirements from nsis-req-08


Hi all,

As John suggested, I tried to sort out requirements (out of
nsis-req-08) 
which are related to mobility and hope they helpful for 
related discussions:

    5.2 Signaling
Flows...............................................10
    5.2.2 NSIS MUST support path-coupled and MAY support 
path-decoupled
    
signaling.........................................................11
==>  relates to different handling of MIP IP-in-IP
encapsulation (tunnel).

    5.3
Messaging.....................................................11
    5.3.1 Explicit erasure of state MUST be 
possible..................12
==> related to explicit teardown of obsoleted branch. Maybe 
      
a flag to 
    
indicate whether to do explicit teardown.

    5.4 Control
Information...........................................13
    5.4.3 State MUST be addressed independent of flow 
identification..14
==> mobility support may make use of this requirement.

    5.5
Performance...................................................15
    5.5.1 
Scalability.................................................15
==> NSIS "MUST be scalable in number of hand-offs in mobile 
environments." This can be related to, e.g., capability of 
dealing with 
pingpong, fast movement.

    5.6
Flexibility...................................................16
    5.6.2 Flexibility in the placement of the NSIS 
Initiator/Responder16
==> somehow related to the issue of either MN or CN as data sender.

    5.8
Mobility......................................................19
    5.8.1 Allow efficient service re-establishment after 
handover.....19
==> effectively establish states in new path due to handover.

    5.9 Interworking with other protocols and
techniques..............19
    5.9.1 MUST interwork with IP 
tunneling............................19
==> IP-in-IP encapsulation is one type of IP tunnels

    5.9.2 MUST NOT constrain either to IPv4 or
IPv6...................19
==> should be able to work with both Mobile IPv4 protocols 
      
and Mobile 
    
IPv6 protocols.

    5.9.5 SHOULD work with seamless handoff
protocols.................20
==> e.g., CTP

Cheers,
Xiaoming


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

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

    


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

--------------060308010906090007040606-- ------=_NextPartTM-000-b41cea4c-7899-4347-ac39-88af965bdcb4-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 04:33:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22909 for ; Thu, 17 Jul 2003 04:33:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4CI-0005Bm-LH for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:33:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8X6Yg019826 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:33:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4CE-00059f-LT; Thu, 17 Jul 2003 04:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Bn-00059H-ON for nsis@optimus.ietf.org; Thu, 17 Jul 2003 04:32:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22901 for ; Thu, 17 Jul 2003 04:32:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4Bk-0003BM-00 for nsis@ietf.org; Thu, 17 Jul 2003 04:32:33 -0400 Received: from smtp.ietf57.telekom.at ([81.160.16.8]) by ietf-mx with esmtp (Exim 4.12) id 19d4Ba-0003A9-00 for nsis@ietf.org; Thu, 17 Jul 2003 04:32:22 -0400 Received: from ccrle.nec.de ([81.160.167.164]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6H8VGk20008; Thu, 17 Jul 2003 10:31:16 +0200 (MEST) Message-ID: <3F165ECC.7000204@ccrle.nec.de> Date: Thu, 17 Jul 2003 10:31:08 +0200 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] comments on NTLP design proposals References: <3F106BF3.90403@cs.columbia.edu> In-Reply-To: <3F106BF3.90403@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> So, maybe (d) would be nice. Unfortunately, I think (d) is impossible >> using a fully reliable transport; however, I'm now >> pretty (90%) sure that something sensible can be done by >> re-using DCCP, and selectively layering reliability on top >> (where needed). (You could also use a different congestion response, >> like TFRC, which might be nice. In fact, DCCP seems to have *lots* >> of nice features...) > > > Definitely a possible choice. I'm not convinced it has to be the only > one. I'm somewhat perplexed by the reliability issue. I can't see how a > reasonable QoS mechanism, for example, can be built without fast > hop-by-hop recovery, where reasonable includes a call setup time that > falls within the well-known human factors limits of post-"dial" delays. If the "well-known human factors limits of post-"dial" delays" are the metric I would assume end-to-end reliability might be enough (implies that reliability is an NSLP issue). If the setup delay impacts an ongoing session (re-setup at a new location), setup delay needs to be in another range. Concerning recovery I wonder what the proposed trigger mechanisms are to detect the problem and start the recovery mechanism. So far I was assuming that we relay on the routing protocol or change in forwarding table. What is the detection time of a failure using for example TCP in function of the various timeout settings? > > >> >> In fact, we have up to now had an object in the framework (the >> flow id, maybe a better name would be 'flow routing information') >> which supposedly exposed at the NTLP level all the information needed >> to work out where to send a signalling packet. In addition, >> this object could be processed at an NTLP-aware NAT to provide >> a traversal service for most signalling applications. I'd be >> interested to know if people think this should actually be reflected >> in NTLP design (or, if they think it is just a terminally silly idea - >> in which case I can take it out of the framework as well). > I really like it to keep it in. The NTLP routing decision might even be based on that information. This would solve the DA only routed problem. I also like it for the NAT traversal case. > > It is probably still somewhat vague what this is meant to be. Can I take > this to mean "simple flow descriptor", basically the 5-tuple + IPv6 flow > ID + DSCP? > Yes I think so. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 04:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23662 for ; Thu, 17 Jul 2003 04:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Pn-0006G1-CS for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:47:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8l3s7024053 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Pn-0006Fq-5h; Thu, 17 Jul 2003 04:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Pc-0006FW-7k for nsis@optimus.ietf.org; Thu, 17 Jul 2003 04:46:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23631 for ; Thu, 17 Jul 2003 04:46:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4PZ-0003P2-00 for nsis@ietf.org; Thu, 17 Jul 2003 04:46:49 -0400 Received: from smtp.ietf57.telekom.at ([81.160.16.8]) by ietf-mx with esmtp (Exim 4.12) id 19d4PO-0003NU-00 for nsis@ietf.org; Thu, 17 Jul 2003 04:46:38 -0400 Received: from ccrle.nec.de ([81.160.167.164]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6H8iQk20045; Thu, 17 Jul 2003 10:44:26 +0200 (MEST) Message-ID: <3F1661E3.3050203@ccrle.nec.de> Date: Thu, 17 Jul 2003 10:44:19 +0200 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi Marcus, > > >>>>Is an adaption to an underlying L2 technology the relevant >> >>decision criterion. >> >>> >>>In my mind, it is hard to say, I do feel uncomfortable about adapting layer 3 >>>4/5 protocols based upon layer 2 considerations - I am not sure if we have >>>any good ways to do this & I am not sure it is in our charter to invent them. >>> >> >>For the NTLP this might turn into a configuration capability on each >>single node/interface. Whether this is a good idea or not I have not >>made up my mind. And you do not need to invent something, but we have to >>talk about the knobs and where they are placed, and which entity control >>the knob anyway. > > > This sounds more & more like operational issues with the protocols or > issues how the protocol can be run over specific layer-2s or in > special deployments. I think, but I could be wrong, that these > belong best outside of the protocol document, but in an operational > doc, deployment doc, applicability statement, bcp-type document, > for example. Sure they partly are. But some of the knobs might be turned using the NTLP protocol, thats where we need decisions. >>Can you give an argument, which makes you think the end-point is a good >>idea? Given it is the end-point. Is it the NSLP on the end-point, the >>user(application) using the protocol, or the NTLP based on >>information about L2 access technology. > > > The end-user is requesting service, s authorized for the service and is > in the best position to know what is his expectations for the service. > I have an allergic reaction to the suggestion that the network better > understands my wants / my needs as an enduser than I do. However, > I could be mis-interpretying your comments. So do you want to specify as a user whether we should use reliable NTLP or not? Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 04:52:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23894 for ; Thu, 17 Jul 2003 04:52:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Ua-0006vp-Ul for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:52:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8q0uI026626 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Ua-0006vM-Py; Thu, 17 Jul 2003 04:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Tw-0006oc-A8 for nsis@optimus.ietf.org; Thu, 17 Jul 2003 04:51:20 -0400 Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23828 for ; Thu, 17 Jul 2003 04:51:15 -0400 (EDT) Received: from ccrle.nec.de (n-pool-0.ietf57.telekom.at [81.160.167.164]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6H8nlk20057; Thu, 17 Jul 2003 10:49:47 +0200 (MEST) Message-ID: <3F166324.2010600@ccrle.nec.de> Date: Thu, 17 Jul 2003 10:49:40 +0200 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: karagian@cs.utwente.nl, hgs@cs.columbia.edu, nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Point of procedure. I am working from the assumption that we are > working on (some) solutions where per-hop reliability is not needed, Strong emphasis on "some" > therefore NTLP should be able to run in a mode without per-hop > reliability. I think nobody is against it and both proposals on the table do it. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 04:52:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23911 for ; Thu, 17 Jul 2003 04:52:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Ub-0006xz-I1 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:52:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8q1sT026674 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 04:52:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Ub-0006w6-Aq; Thu, 17 Jul 2003 04:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Tx-0006oh-AK for nsis@optimus.ietf.org; Thu, 17 Jul 2003 04:51:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23831 for ; Thu, 17 Jul 2003 04:51:16 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4Tu-0003R6-00 for nsis@ietf.org; Thu, 17 Jul 2003 04:51:18 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19d4Tj-0003QZ-00 for nsis@ietf.org; Thu, 17 Jul 2003 04:51:07 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H8n7B10201 for ; Thu, 17 Jul 2003 11:49:07 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 11:49:07 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 11:49:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 11:49:05 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 11:49:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Reliable Transport for NTLP Date: Thu, 17 Jul 2003 11:49:04 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNMP7HVMFLRi5YhTuitjpiJHPe5uQAADMug To: Cc: X-OriginalArrivalTime: 17 Jul 2003 08:49:05.0378 (UTC) FILETIME=[47444420:01C34C40] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Marcus, > > This sounds more & more like operational issues with the protocols = or=20 > > issues how the protocol can be run over specific layer-2s or in=20 > > special deployments. I think, but I could be wrong, that these > > belong best outside of the protocol document, but in an operational > > doc, deployment doc, applicability statement, bcp-type document, > > for example. >=20 > Sure they partly are. But some of the knobs might be turned using the=20 > NTLP protocol, thats where we need decisions. Yes, the devil is in the details, so maybe we need to take this as a case-by-case basis during the protocol design. > > The end-user is requesting services authorized for the service and = is=20 > > in the best position to know what is his expectations for the = service. > > I have an allergic reaction to the suggestion that the network = better > > understands my wants / my needs as an enduser than I do. However, > > I could be mis-interpretying your comments. >=20 > So do you want to specify as a user whether we should use reliable = NTLP=20 > or not? Well, there may be an operational mode that the TCP setup time may be an issue; fast mobility may be one of them. We could hypothesize about these, perhaps these are issues that the NSLPs should consider as they start their work and make recommendations to the NTLP authors. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 05:06:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24434 for ; Thu, 17 Jul 2003 05:06:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4i9-000806-Ku for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 05:06:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H961LI030737 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 05:06:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4i9-0007zI-15; Thu, 17 Jul 2003 05:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hS-0007tq-Dd for nsis@optimus.ietf.org; Thu, 17 Jul 2003 05:05:18 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24331 for ; Thu, 17 Jul 2003 05:05:13 -0400 (EDT) Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6H95EkM014882; Thu, 17 Jul 2003 05:05:14 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6H95Dg03229; Thu, 17 Jul 2003 05:05:13 -0400 Message-ID: <3F1665D0.7000508@cs.columbia.edu> Date: Thu, 17 Jul 2003 05:01:04 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcus Brunner CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] comments on NTLP design proposals References: <3F106BF3.90403@cs.columbia.edu> <3F165ECC.7000204@ccrle.nec.de> In-Reply-To: <3F165ECC.7000204@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Marcus Brunner wrote: > If the "well-known human factors limits of post-"dial" delays" are the > metric I would assume end-to-end reliability might be enough (implies > that reliability is an NSLP issue). I'm not sure I agree. The difficulty is that NSLP has a really hard time picking the appropriate timer on the first message. The first message is likely to trigger a number of AAA operations along the way, which can vary greatly in their delay. Thus, you'll either pick a very conservative delay appropriate for multiple AAA invocations (say, 3 seconds) or you pick an aggressive one reflecting a conservative estimate of network round-trip time (say, 500 ms). If you take the long value, a single packet loss means that you are talking about delays exceeding the typical post-dial delay, while the lower one will result in spurious retransmissions that could easily multiply the number of messages by a factor of 5 or 6. > > Concerning recovery I wonder what the proposed trigger mechanisms are to > detect the problem and start the recovery mechanism. So far I was > assuming that we relay on the routing protocol or change in forwarding > table. > What is the detection time of a failure using for example TCP in > function of the various timeout settings? There is no difference - you detect that the next hop has changed (e.g., by triggers) and re-send the message. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 05:25:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25786 for ; Thu, 17 Jul 2003 05:25:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d50Y-0001Ie-6s for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 05:25:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H9P2TC004989 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 05:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d50X-0001IL-GT; Thu, 17 Jul 2003 05:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d50K-0001I0-7N for nsis@optimus.ietf.org; Thu, 17 Jul 2003 05:24:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25722 for ; Thu, 17 Jul 2003 05:24:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d50G-0003m4-00 for nsis@ietf.org; Thu, 17 Jul 2003 05:24:44 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19d506-0003ls-00 for nsis@ietf.org; Thu, 17 Jul 2003 05:24:34 -0400 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h6H9O0Cf026763; Thu, 17 Jul 2003 11:24:00 +0200 (MET DST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h6H9Nvl2024373; Thu, 17 Jul 2003 11:23:57 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.6+Sun/8.10.2) id h6H9Nwe13290; Thu, 17 Jul 2003 11:23:58 +0200 (MEST) Message-Id: <200307170923.h6H9Nwe13290@janus.cs.utwente.nl> To: jmanner@cs.Helsinki.FI Date: Thu, 17 Jul 2003 09:23:58 +0000 X-Mailer: IlohaMail/0.7.2 @ webmail.cs.utwente.nl From: "karagiannis" Reply-To: "karagiannis" CC: nsis@ietf.org Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Subject: [NSIS] input (over RMD) for NSIS Analysis draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Jukka Please receive a proposed text related to the analysis of the RMD (Resource Management in DIffserv) specification that can be used as an input (section) for the NSIS Analyisis draft. If there are comments please let me know! Please note that during the following three weeks I will be out of office. You could forward the comments to Lars Westberg or Attila Bader! Best Regards, Georgios ----------------------------------------------------- x.x Resource Management in Diffserv (RMD) Resource Management in Diffserv (RMD) [WeCs02] represents a QoS framework that extends the Diffserv principles with new ones necessary to provide dynamic resource management and admission control in Diffserv domains. The development of RMD was initially based on two main design goals. The first one was that RMD should be stateless on some nodes (e.g. interior routers), i.e., no per-flow state is used, unlike RSVP [RFC2205], which installs one state for each flow on all the nodes in the communication path. The second goal was that RMD even though stateless should associate each reservation to each flow and therefore should provide certain QoS guarantees for each flow. These two goals are met by separating a complex reservation mechanism used in some nodes from a much simpler reservation mechanism needed in other nodes. In particular, it is assumed that some nodes will support “per-flow states”, i.e., are stateful. In RMD these nodes are denoted as “edge nodes”. However, any nodes that maintain reservation states could fulfill this requirement. The second assumption is that the nodes between these stateful nodes can have a simpler execution by using only one aggregated reservation state per traffic class. In RMD these nodes are denoted as interior nodes. The separation of the complex per domain reservation mechanism from the simple reservation mechanism needed for a node is accomplished by using two types of protocols the Per Domain Reservation (PDR) protocol and the Per Hop Reservation (PHR) protocol. The PDR protocol is used for resource management in the whole Diffserv domain and is used only on the edge nodes, while the PHR protocol is used for managing resources for each node, on per hop basis and per traffic class. The PDR protocol can either be a newly defined protocol or an existing one such as RSVP [RFC2205], while the PHR protocol is a newly defined protocol. The PDR reservation states at the edge nodes are identified by a flow Identifier (ID). This flow ID depends on the used existing reservation protocol. For example, a flow ID specification can be a combination of source IP address, destination IP address and the Diffserv Code Point (DSCP) field. The PHR reservation states are per traffic class aggregated states that are identified by a DSCP. The edges will generate reservation requests for each flow, similar to RSVP, but in order to achieve simplicity in interior nodes, a measurement-based approach on the number of the requested resources per traffic class, i.e., per Per Hop Behavior, is applied. In practice, this means that the aggregated reservation state per traffic class in the interior nodes is updated by a measurement-based algorithm that uses the requested and available resources as input. Moreover, RMD applies admission control on resource parameter values included in the reservation requests, i.e. signaling messages and available resources per traffic class. RMD is a sender oriented reservation protocol that can only be used for unicast reservations and can be applied with both IP versions, IPv4 and IPv6. Multicast reservations are not supported. Due to the fact that RMD is used as a sender oriented reservation protocol, backward reservation states in the interior nodes are not supported. The RMD protocol can support both uni-directional and bi-directional reservations. The authors of the RMD proposal show in [WeCs02] that the number of simultaneously maintained RMD reservation states in the interior nodes are independent of the number of simultaneously maintained flows. The number of simultaneously maintained RMD reservation states in the interior nodes is equal to the number of the supported traffic classes, i.e., supported Diffserv Per Hop Behaviors. Compared to RSVP, the RMD protocol provides limited functionality, i.e., no security and policy based interworking are provided. Due to the limited functionality of the RMD protocol, its messages are short and consume a relatively low amount of bandwidth. The authors of the RMD proposal show in [WeCs02] that the message processing of the RMD protocol implementation is considerable lower than the message processing of the ISI RSVP protocol implementation. This is mainly due to the limited functionality supported by the RMD protocol. Regarding the deployability issues, RMD is an edge to edge protocol. Therefore, it has to be integrated/interoperated with an end to end reservation protocol. References: -------------- [RFC2205] given in version 03 of the Analysis draft [WeCs02] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., Partain, D., Pop, O., Rexhepi, V., Szabo, R., Takacs, A., "Resource Management in Diffserv: A Functionality and Performance Behavior Overview", Seventh International Workshop on Protocols for High-Speed Networks - PfHSN 2002, 2002. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 05:30:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26204 for ; Thu, 17 Jul 2003 05:30:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d55N-0001jj-Cs for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 05:30:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H9U12m006657 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 05:30:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d55N-0001jH-8Q; Thu, 17 Jul 2003 05:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d551-0001h1-Rq for nsis@optimus.ietf.org; Thu, 17 Jul 2003 05:29:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26113 for ; Thu, 17 Jul 2003 05:29:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d54y-0003sp-00 for nsis@ietf.org; Thu, 17 Jul 2003 05:29:36 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19d54n-0003sc-00 for nsis@ietf.org; Thu, 17 Jul 2003 05:29:25 -0400 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h6H9TJCf026916; Thu, 17 Jul 2003 11:29:19 +0200 (MET DST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h6H9THl2025181; Thu, 17 Jul 2003 11:29:17 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.6+Sun/8.10.2) id h6H9THC13401; Thu, 17 Jul 2003 11:29:17 +0200 (MEST) Message-Id: <200307170929.h6H9THC13401@janus.cs.utwente.nl> To: john.loughney@nokia.com Subject: RE: [NSIS] Reliable Transport for NTLP Date: Thu, 17 Jul 2003 09:29:17 +0000 X-Mailer: IlohaMail/0.7.2 @ webmail.cs.utwente.nl From: "karagiannis" Reply-To: "karagiannis" CC: nsis@ietf.org Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John >Well, there may be an operational mode that the TCP setup time may be an >issue; fast mobility may be one of them. We could hypothesize about >these, perhaps these are issues that the NSLPs should consider as they >start their work and make recommendations to the NTLP authors. I agree! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 05:32:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26491 for ; Thu, 17 Jul 2003 05:32:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d57J-0002Kh-Od for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 05:32:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H9W1n2008949 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 05:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d57J-0002KF-Kl; Thu, 17 Jul 2003 05:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d571-0002Jd-7b for nsis@optimus.ietf.org; Thu, 17 Jul 2003 05:31:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26388 for ; Thu, 17 Jul 2003 05:31:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d56x-0003uV-00 for nsis@ietf.org; Thu, 17 Jul 2003 05:31:39 -0400 Received: from smtp.ietf57.telekom.at ([81.160.16.8]) by ietf-mx with esmtp (Exim 4.12) id 19d56m-0003p2-00 for nsis@ietf.org; Thu, 17 Jul 2003 05:31:29 -0400 Received: from ccrle.nec.de (n-pool-0.ietf57.telekom.at [81.160.167.164]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6H9RLk20136; Thu, 17 Jul 2003 11:27:21 +0200 (MEST) Message-ID: <3F166BF2.9070703@ccrle.nec.de> Date: Thu, 17 Jul 2003 11:27:14 +0200 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paulo Mendes CC: "Charles Q. Shen" , john.loughney@nokia.com, fu@cs.uni-goettingen.de, nsis@ietf.org Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: <001401c34bce$3dedb2c0$c7f027a0@president> <3F165E31.9090309@docomolab-euro.com> In-Reply-To: <3F165E31.9090309@docomolab-euro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paulo, Sure, go ahead with discussions based on what stands in the framework. I think Robert would be glad to get some input on mobility aspects. Marcus > I agree with Charles's opinion. Some discussion is needed to reflect on > some issues already mentioned in the Framework, but that need a more > detailed analysis, such as seamless handover support for mobile > real-time data transmission. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 08:42:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04052 for ; Thu, 17 Jul 2003 08:42:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d85B-0006nX-JR for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 08:42:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HCg1Uq026126 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 08:42:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d85B-0006nH-6e; Thu, 17 Jul 2003 08:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d852-0006n1-3B for nsis@optimus.ietf.org; Thu, 17 Jul 2003 08:41:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04048 for ; Thu, 17 Jul 2003 08:41:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d850-0005vK-00 for nsis@ietf.org; Thu, 17 Jul 2003 08:41:50 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19d84q-0005vH-00 for nsis@ietf.org; Thu, 17 Jul 2003 08:41:40 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSL1R06>; Thu, 17 Jul 2003 13:40:48 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SSK1PTC; Thu, 17 Jul 2003 13:40:45 +0100 From: "Hancock, Robert" To: Marcus Brunner Cc: Paulo Mendes , "Charles Q. Shen" , john.loughney@nokia.com, fu@cs.uni-goettingen.de, nsis@ietf.org Date: Thu, 17 Jul 2003 13:41:12 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 In-Reply-To: <3F166BF2.9070703@ccrle.nec.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > Paulo, > > Sure, go ahead with discussions based on what stands in the framework. I > think Robert would be glad to get some input on mobility aspects. Yes please, and do it sooooooon (and/or catch me this week). Actually, there was a more detailed discussion of some of the issues you mention in the -00/-01 versions (i can provide them if you don't have access). We took it out, partly because it seemed that no-one apart from the author was interested in the subject. A tiny summary of the proposed way forwards for those who are interested (in fact, the following - along with a potted summary of the overall analysis - might be the basis of the eventual framework content, with all the detail moved to another document): The framework layer split concept is that the NTLP works in terms of packet streams ("flows") which are identifiable by nodes inside the network. This is reflected practically in the fact that the NTLP universe revolves around "flow-ids" (3/5 tuple etc. - see other emails). The NTLP knows how to route (and re-route) signalling messages along the path corresponding to a flow ID, but it doesn't know anything about any relationships between different flows (i.e. with different flow IDs). An IP-visible mobility event (MIP/SIP/HIP/...) results intrinsically in a new flow ID and also an update of the packet classifiers and so on. The NTLP doesn't know how the new flow relates to the old; NSIS-aware nodes which see both flows handle the interactions between them at the signalling application level (i.e. in the NSLP). Essentially, the same reasoning applies to the multihoming case, i.e. it's an NSLP issue. The NTLP has a greater proportion of the responsibility for simple re-routing events (actually, the same responsibility, but the re-routing problem is much simpler for several reasons). Those people interested in the general problem of seamless handover support would first have to consider whether that is done by re-routing (i.e. there are updated host routes in the network) or by changing IP address. That's a nice subject. cheers, robert h. > > Marcus > > > I agree with Charles's opinion. Some discussion is needed to reflect on > > some issues already mentioned in the Framework, but that need a more > > detailed analysis, such as seamless handover support for mobile > > real-time data transmission. > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 08:56:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04549 for ; Thu, 17 Jul 2003 08:56:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Ik-0007gR-65 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 08:56:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HCu2IB029526 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 08:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Ik-0007g8-2g; Thu, 17 Jul 2003 08:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8I0-0007ds-AS for nsis@optimus.ietf.org; Thu, 17 Jul 2003 08:55:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04483 for ; Thu, 17 Jul 2003 08:55:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8Hy-000669-00 for nsis@ietf.org; Thu, 17 Jul 2003 08:55:14 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19d8Ho-00065M-00 for nsis@ietf.org; Thu, 17 Jul 2003 08:55:04 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSL1SDA>; Thu, 17 Jul 2003 13:54:28 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SSK1PTQ; Thu, 17 Jul 2003 13:54:23 +0100 From: "Hancock, Robert" To: Marcus Brunner Cc: john.loughney@nokia.com, nsis@ietf.org Date: Thu, 17 Jul 2003 13:54:50 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Subject: Re: [NSIS] Reliable Transport for NTLP In-Reply-To: <3F1661E3.3050203@ccrle.nec.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, I confess to being a bit confused by this conversation. The performance attributes that the NTLP should achieve for any particular message are selected by the NSLP instance on the node where it is generated. But, that node may be anywhere in the network along the path, and may have no relationship with the initiating NSLP and certainly not the user. And the attributes typically invoked may vary wildly along the path, even for a single application and a single flow. (Just like RSVP, in fact.) The NTLP specification needs to be powerful enough that it can provide these performance attributes (when requested) in a wide range of environments (including different link types). But the NSLP (and especially the user) has no idea and doesn't care how this is done (as we have discussed and agreed on this list several times). [To make an analogy: in an ideal world, users/applications would rely on strong e2e checksums to provided e2e data integrity, regardless of the mechanisms used to move messages on interior links.] I definitely agree that NTLP-over-foo/NTLP-in-bar-environments information should be in separate documents. But, if the NTLP base specification lacks the necessary capabilities, such documents would be hard to write. John, Marcus - have I just violently agreed with both of you, or is there a real issue here? cheers, r. On Thu, 17 Jul 2003, Marcus Brunner wrote: > Date: Thu, 17 Jul 2003 10:44:19 +0200 > From: Marcus Brunner > To: john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: Re: [NSIS] Reliable Transport for NTLP > > > > john.loughney@nokia.com wrote: > > > Hi Marcus, > > > > > >>>>Is an adaption to an underlying L2 technology the relevant > >> > >>decision criterion. > >> > >>> > >>>In my mind, it is hard to say, I do feel uncomfortable about adapting layer 3 > >>>4/5 protocols based upon layer 2 considerations - I am not sure if we have > >>>any good ways to do this & I am not sure it is in our charter to invent them. > >>> > >> > >>For the NTLP this might turn into a configuration capability on each > >>single node/interface. Whether this is a good idea or not I have not > >>made up my mind. And you do not need to invent something, but we have to > >>talk about the knobs and where they are placed, and which entity control > >>the knob anyway. > > > > > > This sounds more & more like operational issues with the protocols or > > issues how the protocol can be run over specific layer-2s or in > > special deployments. I think, but I could be wrong, that these > > belong best outside of the protocol document, but in an operational > > doc, deployment doc, applicability statement, bcp-type document, > > for example. > > Sure they partly are. But some of the knobs might be turned using the > NTLP protocol, thats where we need decisions. > > > >>Can you give an argument, which makes you think the end-point is a good > >>idea? Given it is the end-point. Is it the NSLP on the end-point, the > >>user(application) using the protocol, or the NTLP based on > >>information about L2 access technology. > > > > > > The end-user is requesting service, s authorized for the service and is > > in the best position to know what is his expectations for the service. > > I have an allergic reaction to the suggestion that the network better > > understands my wants / my needs as an enduser than I do. However, > > I could be mis-interpretying your comments. > > So do you want to specify as a user whether we should use reliable NTLP > or not? > > Marcus > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 09:06:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05199 for ; Thu, 17 Jul 2003 09:06:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8SP-0008Q3-6K for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 09:06:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HD61HK032360 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 09:06:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8SP-0008Pp-0z; Thu, 17 Jul 2003 09:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Rh-0008Nv-5b for nsis@optimus.ietf.org; Thu, 17 Jul 2003 09:05:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05119 for ; Thu, 17 Jul 2003 09:05:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8Rf-0006FJ-00 for nsis@ietf.org; Thu, 17 Jul 2003 09:05:15 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19d8RU-0006Ep-00 for nsis@ietf.org; Thu, 17 Jul 2003 09:05:05 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSL1SFT>; Thu, 17 Jul 2003 14:04:29 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SSK1P4G; Thu, 17 Jul 2003 14:04:25 +0100 From: "Hancock, Robert" To: Marcus Brunner Cc: Henning Schulzrinne , "Hancock, Robert" , nsis@ietf.org Date: Thu, 17 Jul 2003 14:04:53 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Subject: Re: [NSIS] comments on NTLP design proposals In-Reply-To: <3F165ECC.7000204@ccrle.nec.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > >> In fact, we have up to now had an object in the framework (the > >> flow id, maybe a better name would be 'flow routing information') > >> which supposedly exposed at the NTLP level all the information needed > >> to work out where to send a signalling packet. In addition, > >> this object could be processed at an NTLP-aware NAT to provide > >> a traversal service for most signalling applications. I'd be > >> interested to know if people think this should actually be reflected > >> in NTLP design (or, if they think it is just a terminally silly idea - > >> in which case I can take it out of the framework as well). > > > > I really like it to keep it in. The NTLP routing decision might even be > based on that information. This would solve the DA only routed problem. > I also like it for the NAT traversal case. Good, thanks. As an example of what we are trying to achieve, at least one of the recent rash of QoS-NSLP proposals is I believe automatically transparent to any NAT provided that that NAT is NTLP aware, since the NSLP carries no addressing information itself. In other words, an NTLP-aware NAT can support any NSLP without needing a signalling ALG, provided that the NSLP refers to what it wants to talk about as "this flow" rather than "the flow with IP SA fred and IP DA bert and protocol alf...". > > > > > > It is probably still somewhat vague what this is meant to be. Can I take > > this to mean "simple flow descriptor", basically the 5-tuple + IPv6 flow > > ID + DSCP? > > > Conceptually this is it. There are questions about exactly what fields are needed and which can be wildcarded - I'd leave these as details for the NTLP designers. The problem with wildcarding is that at some point the flow path becomes ambiguous (packets could go in more than one direction) - at that stage, I suppose, the NTLP could report an "I'm giving up here" error message (could be complicated, but useful in some access scenarios). r. > Yes I think so. > > Marcus > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 11:15:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11208 for ; Thu, 17 Jul 2003 11:15:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dATH-0007YP-4l for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 11:15:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HFF3Fj029033 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 11:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dATG-0007Xt-1S; Thu, 17 Jul 2003 11:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dASi-0007W8-4K for nsis@optimus.ietf.org; Thu, 17 Jul 2003 11:14:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11186 for ; Thu, 17 Jul 2003 11:14:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dASh-00077n-00 for nsis@ietf.org; Thu, 17 Jul 2003 11:14:27 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 19dASW-00077Z-00 for nsis@ietf.org; Thu, 17 Jul 2003 11:14:16 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 19dASP-0000iI-00; Thu, 17 Jul 2003 17:14:10 +0200 Received: from localhost ([127.0.0.1] helo=i72mn12.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 19dASO-00062m-00; Thu, 17 Jul 2003 17:14:08 +0200 Date: Thu, 17 Jul 2003 17:14:16 +0200 From: Roland Bless To: "Hancock, Robert" Cc: nsis@ietf.org Subject: Re: [NSIS] comments on NTLP design proposals Message-Id: <20030717171416.73ab8576.bless@tm.uka.de> In-Reply-To: References: Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > In fact, we have up to now had an object in the framework (the > flow id, maybe a better name would be 'flow routing information') > which supposedly exposed at the NTLP level all the information > needed to work out where to send a signalling packet. In addition, > this object could be processed at an NTLP-aware NAT to provide > a traversal service for most signalling applications. I'd be > interested to know if people think this should actually be reflected > in NTLP design (or, if they think it is just a terminally silly > idea - in which case I can take it out of the framework as well). Yes, I think it should be reflected and I'd like to keep it in for the same reasons that Marcus stated. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 11:23:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11444 for ; Thu, 17 Jul 2003 11:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAaz-00089i-BK for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 11:23:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HFN1vJ031343 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 11:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAaz-00089R-8M; Thu, 17 Jul 2003 11:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAal-000882-IN for nsis@optimus.ietf.org; Thu, 17 Jul 2003 11:22:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11415 for ; Thu, 17 Jul 2003 11:22:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dAak-0007BD-00 for nsis@ietf.org; Thu, 17 Jul 2003 11:22:46 -0400 Received: from smtp.ietf57.telekom.at ([81.160.16.8]) by ietf-mx with esmtp (Exim 4.12) id 19dAaZ-0007Ap-00 for nsis@ietf.org; Thu, 17 Jul 2003 11:22:35 -0400 Received: from ccrle.nec.de (n-pool-0.ietf57.telekom.at [81.160.167.164]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6HFLvk20968; Thu, 17 Jul 2003 17:21:57 +0200 (MEST) Message-ID: <3F16BF0E.2030303@ccrle.nec.de> Date: Thu, 17 Jul 2003 17:21:50 +0200 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, > I definitely agree that NTLP-over-foo/NTLP-in-bar-environments > information should be in separate documents. But, if the > NTLP base specification lacks the necessary capabilities, > such documents would be hard to write. Basically the question I have is who makes the decisions on what mode of operation the NTLP is running on, and what are the criterions. > John, Marcus - have I just violently agreed with both > of you, or is there a real issue here? As far as I understood John he is not willing to let the network decide on that. Marcus > > cheers, > > r. > > > On Thu, 17 Jul 2003, Marcus Brunner wrote: > > >>Date: Thu, 17 Jul 2003 10:44:19 +0200 >>From: Marcus Brunner >>To: john.loughney@nokia.com >>Cc: nsis@ietf.org >>Subject: Re: [NSIS] Reliable Transport for NTLP >> >> >> >>john.loughney@nokia.com wrote: >> >> >>>Hi Marcus, >>> >>> >>> >>>>>>Is an adaption to an underlying L2 technology the relevant >>>> >>>>decision criterion. >>>> >>>> >>>>>In my mind, it is hard to say, I do feel uncomfortable about adapting layer 3 >>>>>4/5 protocols based upon layer 2 considerations - I am not sure if we have >>>>>any good ways to do this & I am not sure it is in our charter to invent them. >>>>> >>>> >>>>For the NTLP this might turn into a configuration capability on each >>>>single node/interface. Whether this is a good idea or not I have not >>>>made up my mind. And you do not need to invent something, but we have to >>>>talk about the knobs and where they are placed, and which entity control >>>>the knob anyway. >>> >>> >>>This sounds more & more like operational issues with the protocols or >>>issues how the protocol can be run over specific layer-2s or in >>>special deployments. I think, but I could be wrong, that these >>>belong best outside of the protocol document, but in an operational >>>doc, deployment doc, applicability statement, bcp-type document, >>>for example. >> >>Sure they partly are. But some of the knobs might be turned using the >>NTLP protocol, thats where we need decisions. >> >> >> >>>>Can you give an argument, which makes you think the end-point is a good >>>>idea? Given it is the end-point. Is it the NSLP on the end-point, the >>>>user(application) using the protocol, or the NTLP based on >>>>information about L2 access technology. >>> >>> >>>The end-user is requesting service, s authorized for the service and is >>>in the best position to know what is his expectations for the service. >>>I have an allergic reaction to the suggestion that the network better >>>understands my wants / my needs as an enduser than I do. However, >>>I could be mis-interpretying your comments. >> >>So do you want to specify as a user whether we should use reliable NTLP >>or not? >> >>Marcus >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 13:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14651 for ; Thu, 17 Jul 2003 13:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCbq-0006M8-7W for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 13:32:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HHW28i024420 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 13:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCbp-0006Ll-P7; Thu, 17 Jul 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCbK-0006LR-Va for nsis@optimus.ietf.org; Thu, 17 Jul 2003 13:31:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14634 for ; Thu, 17 Jul 2003 13:31:27 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dCbI-000089-00 for nsis@ietf.org; Thu, 17 Jul 2003 13:31:28 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19dCb8-00007z-00 for nsis@ietf.org; Thu, 17 Jul 2003 13:31:18 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6HHUaB15322 for ; Thu, 17 Jul 2003 20:30:36 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 20:30:36 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 20:30:36 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 20:30:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [NSIS] Reliable Transport for NTLP Date: Thu, 17 Jul 2003 20:30:34 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNMdytsq2Ubt4ZeQBOuSOEf7+s1vwAEdIlg To: , Cc: X-OriginalArrivalTime: 17 Jul 2003 17:30:36.0110 (UTC) FILETIME=[21FF0EE0:01C34C89] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Marcus, > > I definitely agree that NTLP-over-foo/NTLP-in-bar-environments > > information should be in separate documents. But, if the > > NTLP base specification lacks the necessary capabilities, > > such documents would be hard to write. >=20 > Basically the question I have is who makes the decisions on=20 > what mode of=20 > operation the NTLP is running on, and what are the criterions. >=20 > > John, Marcus - have I just violently agreed with both > > of you, or is there a real issue here? >=20 > As far as I understood John he is not willing to let the=20 > network decide on that. That may be too strongly stated. I think the endpoints should decide in the cases that matter. I don't want to apply a blanket statement untill I see the proposals. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 17 13:50:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15187 for ; Thu, 17 Jul 2003 13:50:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCtF-0007ST-Js for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 13:50:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HHo1tE028657 for nsis-archive@odin.ietf.org; Thu, 17 Jul 2003 13:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCtF-0007S4-7o; Thu, 17 Jul 2003 13:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCsk-0007Rh-AM for nsis@optimus.ietf.org; Thu, 17 Jul 2003 13:49:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15174 for ; Thu, 17 Jul 2003 13:49:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dCsi-0000FR-00 for nsis@ietf.org; Thu, 17 Jul 2003 13:49:28 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 19dCsX-0000FI-00 for nsis@ietf.org; Thu, 17 Jul 2003 13:49:17 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 19dCsA-0001xT-00; Thu, 17 Jul 2003 19:48:54 +0200 Received: from localhost ([127.0.0.1] helo=i72mn12.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 19dCs9-0006I5-00; Thu, 17 Jul 2003 19:48:53 +0200 Date: Thu, 17 Jul 2003 19:48:55 +0200 From: Roland Bless To: "karagiannis" Cc: jmanner@cs.Helsinki.FI, nsis@ietf.org Subject: Re: [NSIS] input (over RMD) for NSIS Analysis draft Message-Id: <20030717194855.04a83642.bless@tm.uka.de> In-Reply-To: <200307170923.h6H9Nwe13290@janus.cs.utwente.nl> References: <200307170923.h6H9Nwe13290@janus.cs.utwente.nl> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Georgios, > Please receive a proposed text related to the analysis of the RMD > (Resource Management in DIffserv) specification that can be used as > an input (section) for the NSIS Analyisis draft. > If there are comments please let me know! I think it should be emphasized that RMD is an _intra-domain_ resource management scheme. Further comments below. > The authors of the RMD proposal show in [WeCs02] that the number of > simultaneously maintained RMD reservation states in the interior nodes are > > independent of the number of simultaneously maintained flows. The number > of > simultaneously maintained RMD reservation states in the interior nodes is > > equal to the number of the supported traffic classes, i.e., supported > Diffserv Per Hop Behaviors. What about the number of messages that has to be processed per interior node? > Regarding the deployability issues, RMD is an edge to edge protocol. ^^^ intra-domain Wouldn't it be good to mention special requirements for the signaling protocol to make your scheme work? Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 18 05:58:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25556 for ; Fri, 18 Jul 2003 05:58:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRzf-0006xz-35 for nsis-archive@odin.ietf.org; Fri, 18 Jul 2003 05:57:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9vdtU026778 for nsis-archive@odin.ietf.org; Fri, 18 Jul 2003 05:57:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRz2-0006tj-Rp; Fri, 18 Jul 2003 05:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRyc-0006sf-Ab for nsis@optimus.ietf.org; Fri, 18 Jul 2003 05:56:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25528 for ; Fri, 18 Jul 2003 05:56:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRyY-0007H2-00 for nsis@ietf.org; Fri, 18 Jul 2003 05:56:30 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19dRyN-0007GM-00 for nsis@ietf.org; Fri, 18 Jul 2003 05:56:19 -0400 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h6I9sQCf007306; Fri, 18 Jul 2003 11:54:26 +0200 (MET DST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h6I9sOl2000469; Fri, 18 Jul 2003 11:54:24 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.6+Sun/8.10.2) id h6I9sO622982; Fri, 18 Jul 2003 11:54:24 +0200 (MEST) Message-Id: <200307180954.h6I9sO622982@janus.cs.utwente.nl> To: Roland Bless Subject: Re: [NSIS] input (over RMD) for NSIS Analysis draft Date: Fri, 18 Jul 2003 09:54:24 +0000 X-Mailer: IlohaMail/0.7.2 @ webmail.cs.utwente.nl From: "karagiannis" Reply-To: "karagiannis" CC: nsis@ietf.org Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Roland Thank you very much for your comments. Please see my comments in line: >I think it should be emphasized that RMD is an _intra-domain_ >resource management scheme. We tried to emphasize that it is an edge to edge resource management scheme. Would it be okay for you if we change the following sentence from: `Resource Management in Diffserv (RMD) [WeCs02] represents a QoS framework that extends the Diffserv principles with new ones necessary to provide dynamic resource management and admission control in Diffserv domains.` Into: `Resource Management in Diffserv (RMD) [WeCs02] represents an edge to edge (intra-domain) QoS framework that extends the Diffserv principles with new ones necessary to providedynamic resource management and admission control in Diffserv domains.` >What about the number of messages that has to be processed >per interior node? You are right: We would like to add the following sentece: `The number of required refresh messages in the RMD protocol is the same as the number of required refresh messages in RSVP [RFC2205].` > >> Regarding the deployability issues, RMD is an edge to edge protocol. > ^^^ > intra-domain > Will the following change be okay: From: `Regarding the deployability issues, RMD is an edge to edge protocol.` INto: `Regarding the deployability issues, RMD is an edge to edge (intra-domain) protocol.` >Wouldn't it be good to mention special requirements for the signaling >protocol to make your scheme work? What do you mean by special requirements? Best Regards, Georgios Dr. ir. Georgios Karagiannis Group: Design and Analysis of Communication Systems (DACS) University of Twente The Netherlands _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 18 11:45:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04132 for ; Fri, 18 Jul 2003 11:45:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dXPV-00034a-AA for nsis-archive@odin.ietf.org; Fri, 18 Jul 2003 11:44:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IFif3r011808 for nsis-archive@odin.ietf.org; Fri, 18 Jul 2003 11:44:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dXOq-00032N-Re; Fri, 18 Jul 2003 11:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSCd-0007fn-37 for nsis@optimus.ietf.org; Fri, 18 Jul 2003 06:11:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25790 for ; Fri, 18 Jul 2003 06:10:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSCZ-0007Oe-00 for nsis@ietf.org; Fri, 18 Jul 2003 06:10:59 -0400 Received: from bay7-f15.bay7.hotmail.com ([64.4.11.15] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19dSCO-0007NX-00 for nsis@ietf.org; Fri, 18 Jul 2003 06:10:48 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Jul 2003 03:09:24 -0700 Received: from 81.160.97.2 by by7fd.bay7.hotmail.msn.com with HTTP; Fri, 18 Jul 2003 10:09:23 GMT X-Originating-IP: [81.160.97.2] X-Originating-Email: [svenvandenbosch@hotmail.com] From: "Sven Van den Bosch" To: nsis@ietf.org Date: Fri, 18 Jul 2003 12:09:23 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2003 10:09:24.0653 (UTC) FILETIME=[AA3105D0:01C34D14] Subject: [NSIS] NSLP design draft: way forward Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, During the NSIS meeting this week, it was decided to work towards a joint NSLP draft. The editing team consists of one representative of the author team of each individual NSLP contribution. This mail outlines the way in which we intend to proceed. The main purpose of the draft is the core NSLP design. The draft may also identify the need for other documents describing e.g. MIB, operational practices and /or bearer service definition. The currently proposed plan is agreed between the editors and the chair and may be updated at each IETF meeting. The intention is to have a -00 version by mid september and a -01 version by the next IETF meeting (Minneapolis). The -00 version would be an open, high-level document inviting comments from the group. It would contain a basic outline of operation, suggestions for additional documentation, potentially additional NTLP requirements and IANA considerations related to protocol extensibility (way of creating new objects) and QoS models (what makes up a QoS model, how is this reflected in standards procedure and can we map RSVP to it as an example). It would also contain a section describing security and AAA interactions mainly focused on the parties involved in the authorization decision and where it is invoked requirements on AAA object). The (many) open issues will be captured in a separate The purpose of the -01 version would be two-fold. On the one hand, more protocol issues will be discussed (examples include S/R operation and reduced state operation). On the other hand, the existing protocol basics will be worked out in more detail (message flows, high-level message formats). Later versions of the document will will contain additional functionality including aggregation, tunnel management, bidirectional/proxy operation and priority/preemption We welcome inputs from the group. For this purpose, open conference calls will be organized for which a number of lines will be available for interested parties. An agenda of discussion points will be circulated beforehand. Best regards, Sven _________________________________________________________________ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Jul 19 03:37:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07974 for ; Sat, 19 Jul 2003 03:37:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dmH8-0007Go-EJ for nsis-archive@odin.ietf.org; Sat, 19 Jul 2003 03:37:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6J7b2xg027934 for nsis-archive@odin.ietf.org; Sat, 19 Jul 2003 03:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dmH7-0007GB-8a; Sat, 19 Jul 2003 03:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dmGR-0007FL-Uh for nsis@optimus.ietf.org; Sat, 19 Jul 2003 03:36:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07957 for ; Sat, 19 Jul 2003 03:36:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dmGP-0007U3-00 for nsis@ietf.org; Sat, 19 Jul 2003 03:36:17 -0400 Received: from [137.194.192.1] (helo=infres.enst.fr) by ietf-mx with esmtp (Exim 4.12) id 19dmGE-0007Ta-00 for nsis@ietf.org; Sat, 19 Jul 2003 03:36:06 -0400 Received: from luu (dhcp7-211.enst.fr [137.194.7.211]) by infres.enst.fr (Postfix) with SMTP id 0DBF61937; Sat, 19 Jul 2003 09:34:59 +0200 (MEST) Message-ID: <000e01c34dc8$7adb5ba0$d307c289@enst.fr> From: "Thanh Tra LUU" To: "karagiannis" Cc: References: <200307180954.h6I9sO622982@janus.cs.utwente.nl> Subject: Re: [NSIS] input (over RMD) for NSIS Analysis draft Date: Sat, 19 Jul 2003 09:36:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I've read the draft of proposal for RSVPv2 NSLP. I have some questions. - For bi-directional reservation, you call NI (sender) and NR(receiver), it makes me confused because both of end hosts can be receiver and sender. Supposing the bi-directional reservation between A (and RSVPv2 aware) and B (another RSVPv2 aware end host) is initiated by A (NI) . The two reservation can be established on two different paths. The announcement of reservation success (A -> B) is carried by packet Path(NslpPathInit) from B to A. Because of asymmetry of routing, it is possible that the intermediate NTLP stateful nodes between A and B don't receive this message to know the success of reservation. They will only know it after receiving the refresh message from sender. In case unidirectional reservation, the intermediate nodes know it by receiving the NslpResvInit. Why is there this difference ? Is it useful ? - I don't understand how the NTLP stateless node can support the routing change. No state is established when NTLP stateless receives a Path(NslpPathInit) message. When NTLP stateless receives a Path(NslpPahInit), it adds the new required reservation units of a traffic class. When it receives a PathTear(NslpPathTear), it will subtract the required resource. As previous mail, you said "simultaneously maintained RMD reservation states in the interior nodes is equal to the number of the supported traffic classes", that means if there is a routing change, a deletion of a flux can delete a required resource on a intermediate NTLP stateless node which was not previously on the data path. - I don't understand refresh mechanism for the interior NTLP stateless node either. How does a interior NTLP stateless nodes know a refresh message belongs to a specific flux of a traffic class ? If there is not the refresh for a flux in the NTLP stateless nodes, what does the refresh mean here ? - For the severe congestion handling, interruption of a flux which is reserved doesn't seems interesting to me. If I want to reserve resource for a VoIP communication, it's better if network refuses the connection before I can begin the conversation rather than disrupt my communication. Nary Tra ENST, Paris _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 03:25:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19944 for ; Mon, 21 Jul 2003 03:25:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eV2e-0001oE-Op for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 03:25:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L7P4nC006937 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 03:25:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eV2b-0001nk-HH; Mon, 21 Jul 2003 03:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eV2Z-0001nR-M8 for nsis@optimus.ietf.org; Mon, 21 Jul 2003 03:24:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19905 for ; Mon, 21 Jul 2003 03:24:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eV2X-0000Yb-00 for nsis@ietf.org; Mon, 21 Jul 2003 03:24:57 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19eV2M-0000YP-00 for nsis@ietf.org; Mon, 21 Jul 2003 03:24:46 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jul 2003 09:23:09 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jul 2003 09:23:08 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB53E@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: john.loughney@nokia.com, mshore@cisco.com Cc: nsis@ietf.org Subject: [NSIS] apology to Melinda Date: Mon, 21 Jul 2003 09:22:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Melinda, John |Also, I feel that |R=FCdiger behavior was inappropriate for a professional meeting.=20 |I should have asked R=FCdiger to display more professional=20 |courtesy at the mic. I'm sorry if I offended somebody and I apologize to all who've felt=20 offended by me.=20 I especially apologize to Melinda. I didn't want to offend you=20 personally, nor did I want to challenge your professional skills. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 04:48:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21089 for ; Mon, 21 Jul 2003 04:48:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWL0-0004L9-FC for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 04:48:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L8m6pc016655 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 04:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWKu-0004Js-Kt; Mon, 21 Jul 2003 04:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWKF-0004Jd-Gm for nsis@optimus.ietf.org; Mon, 21 Jul 2003 04:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21064 for ; Mon, 21 Jul 2003 04:47:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eWKC-0000zn-00 for nsis@ietf.org; Mon, 21 Jul 2003 04:47:16 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19eWK1-0000zU-00 for nsis@ietf.org; Mon, 21 Jul 2003 04:47:05 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jul 2003 10:43:19 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jul 2003 10:43:19 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB53F@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] comments on NTLP design proposals Date: Mon, 21 Jul 2003 10:43:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable John, |> i don't think there is anyone arguing at the moment that *all*=20 |> signalling should be sent reliably. | |Several people have come across as stating that, R=FCdiger's comment |struck me as if he was of this opinion,=20 I'm a backbone engineer and my experience with backbone signaling=20 is that it is in many cases using reliable transport. It further=20 is in some way congestion aware. BGP is around for a while, but=20 also the later LDP uses TCP as a transport ptotocol. If a=20 new signaling protocol may create a heavy signaling and/or=20 processing load in the backbone, it should: - be congestion aware to enable backbone routers to reduce=20 signaling load. - minimize related state maintenance within backbone routers=20 (reliable transport between adjacent NTLP peers seems to=20 reach this aim better than NTLP per session message counting). I expect the signaling relations within the backbone to be=20 rather stable. Connection oriented transport seems to be=20 possible. Awareness of the next NTLP message receiver =20 may help to secure signaling (connection oriented transport alone however won't do, an NTLP keep alive mechanism is required). The connection between backbone NTLP peers is fired up and then be kept alive for a long time.=20 It is perfectly clear to me that an environment with a low amount=20 of signaling messages and frequent changes in signaling relations=20 results in other requirements. The same holds for stable=20 signaling relations with a rather low amount of message exchanges. But what's relevant in parts of the network may not be valid for=20 the whole network.=20 Regards, R=FCdiger =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 05:37:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22078 for ; Mon, 21 Jul 2003 05:37:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eX6M-0005sb-0c for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 05:37:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L9b1rY022584 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 05:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eX6L-0005s9-Ri; Mon, 21 Jul 2003 05:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eX5h-0005rK-AY for nsis@optimus.ietf.org; Mon, 21 Jul 2003 05:36:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22047 for ; Mon, 21 Jul 2003 05:36:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eX5d-0001JW-00 for nsis@ietf.org; Mon, 21 Jul 2003 05:36:17 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19eX5S-0001JG-00 for nsis@ietf.org; Mon, 21 Jul 2003 05:36:07 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jul 2003 11:30:50 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jul 2003 11:30:50 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB540@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Reliable Transport for NTLP Date: Mon, 21 Jul 2003 11:30:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable John, |I will=20 |outline a scenario. Two end hosts, A & B, need to setup=20 |some signaling between them. If TCP is used as a transport, |it is not a simple 3 way handshake that is needed. If A & B=20 |are x NTLP hops away, they will need x TCP connections, |which, depending upon implementation, will result a 3 way handshake=20 |between x+1 nodes, which is a significant problem. "Reliable transport" for signaling applications is an issue whith ample operational and implementation experience. Hence I'd suggest=20 that we stick to the "lessons learned" paradigm instead of constructing abstract scenarios. I've e.g. refered to BGP and LDP=20 as signaling protocols making use of TCP.=20 I'd ask you to point out issues with TCP transport based on past experience. I'd appreciate if you could =20 - provide reference to any signaling protocol which wasn't deployed in=20 backbone networks due to TCP transport. - provide reference to a TCP based backbone signaling protocol which=20 will result in an NSIS signaling failure due to TCP transport. =20 When answering, please keep in mind that I'm not asking to have NTLP=20 reliable transport as the only allowed mode of operation.=20 Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 06:19:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22872 for ; Mon, 21 Jul 2003 06:19:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eXl1-0007NT-RX for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 06:19:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LAJ3Ux028342 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 06:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eXkz-0007ML-5k; Mon, 21 Jul 2003 06:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eXkB-0007Jy-R3 for nsis@optimus.ietf.org; Mon, 21 Jul 2003 06:18:11 -0400 Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22757 for ; Mon, 21 Jul 2003 06:18:05 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jul 2003 12:16:51 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jul 2003 12:16:50 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB541@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: svenvandenbosch@hotmail.com Cc: nsis@ietf.org Subject: RE: [NSIS] NSLP design draft: way forward Date: Mon, 21 Jul 2003 12:16:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sven, |QoS models (what makes up a QoS model, how is=20 |this reflected in standards procedure and can=20 |we map RSVP to it as an example). =20 To me a minimum model seems to be to have - a QoS service id which is the first QoS specific=20 object read by NSLP. An example of the meaning=20 in the case of RSVP may be "native IntServ"=20 or "native IntServ controlled load". It may=20 be useful to have IANA reserved and private coding=20 space in it. The service ID also determines the NSLP mode of=20 operation. "Native IntServ" is receiver oriented. A=20 hypothetical "Sender oriented IntServ" may allow=20 for sender based reservations re-using IntServ=20 parametrisation (i.e. QoS specific "RESV" objects=20 in a "PATH" message). - a QoS service parametrisation. The service=20 parametrisation is determined by the service ID=20 (both are coupled non ambiguosly). IANA based service=20 IDs must or should have a standardised service=20 parametrisation. In the case of IntServ, here you'd=20 find the IntServ specific parameters.=20 Services sufficiently characterised by the service ID=20 (in terms of DiffServ e.g. qualitative services) don't=20 require a QoS service parametrisation.=20 This service identification differs from the one used by=20 IntServ. It's more generic, would support one pass=20 reservations and allows for admission control based on=20 sender provided parameters.=20 Space for private services is left while at the same time=20 standardised services may be supported. Interworking=20 with IntServ is possible. Clearly, existing IntServ=20 implementations can't be used to support the above. A good question is whether we need a generic "QoS NSLP"=20 and a "service ID" beyond. Maybe above syntax described=20 how NSLPs are to be defined in general.=20 Regards, R=FCdiger =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 07:15:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24229 for ; Mon, 21 Jul 2003 07:15:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eYdB-0000nV-Lu for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 07:15:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LBF1as003064 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 07:15:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eYdB-0000nJ-E7; Mon, 21 Jul 2003 07:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eYd3-0000mw-Rr for nsis@optimus.ietf.org; Mon, 21 Jul 2003 07:14:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24222 for ; Mon, 21 Jul 2003 07:14:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eYd3-0001rd-00 for nsis@ietf.org; Mon, 21 Jul 2003 07:14:53 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19eYcs-0001r9-00 for nsis@ietf.org; Mon, 21 Jul 2003 07:14:42 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Jul 2003 04:19:45 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6LBDmuD016874 for ; Mon, 21 Jul 2003 04:13:48 -0700 (PDT) Received: from cisco.com (sjc-vpn1-681.cisco.com [10.21.98.169]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIE55630; Mon, 21 Jul 2003 04:08:02 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Mon, 21 Jul 2003 13:13:49 +0200 Date: Mon, 21 Jul 2003 13:13:49 +0200 From: Scott W Brim To: nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP Message-ID: <20030721131349.D2620@sbrim-w2k01> Mail-Followup-To: Scott W Brim , nsis@ietf.org References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB540@G8PQD.blf01.telekom.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB540@G8PQD.blf01.telekom.de>; from Ruediger.Geib@t-systems.com on Mon, Jul 21, 2003 at 11:30:47AM +0200 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , On Mon, Jul 21, 2003 11:30:47AM +0200, Geib, Ruediger allegedly wrote: > "Reliable transport" for signaling applications is an issue whith > ample operational and implementation experience. Hence I'd suggest > that we stick to the "lessons learned" paradigm instead > of constructing abstract scenarios. I've e.g. refered to BGP and LDP > as signaling protocols making use of TCP. > I'd ask you to point out issues with TCP transport based on past > experience. I'd appreciate if you could > > - provide reference to any signaling protocol which wasn't deployed in > backbone networks due to TCP transport. > > - provide reference to a TCP based backbone signaling protocol which > will result in an NSIS signaling failure due to TCP transport. > > When answering, please keep in mind that I'm not asking to have NTLP > reliable transport as the only allowed mode of operation. A casual lurker speaks up ... I think the questions are extreme -- can you provide an example of a protocol which will fail because it does *not* run over TCP? Bad protocols don't get far enough for these questions to be asked. Thus I consider them rhetorical. However, if you want to consider advantages/disadvantages of TCP, consider CR-LDP versus RSVP-TE. CR-LDP used a TCP session. RSVP-TE used its own reliability mechanisms and did not ask for reliability in its lower layer. TCP is designed for stream reliability, not for transaction reliability. RSVP-TE was able to tune its own timers for its own needs, instead of using those optimized for the general case of an average application. It had control over whether, in a retransmission, the same message was retried, or a new, more up-to-date message was attempted instead. It was able to provide more control plane predictability because messages did not necessarily have to wait for previous messages to be acknowledged. When connectivity was lost and thousands of updates needed to be sent, it could choose whether to serialize them all at the transport layer (as LDP did with a single TCP connection) or send some/many in parallel (serializing at the link layer). People did not reject CR-LDP because it ran on TCP. However, the fact that it did was not seen as an advantage. ..swb _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 09:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26749 for ; Mon, 21 Jul 2003 09:34:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eani-0004e7-CQ for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 09:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LDY2tU017856 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 09:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eanh-0004dl-CY; Mon, 21 Jul 2003 09:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eamn-0004dF-82 for nsis@optimus.ietf.org; Mon, 21 Jul 2003 09:33:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26727 for ; Mon, 21 Jul 2003 09:33:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eaml-0002pj-00 for nsis@ietf.org; Mon, 21 Jul 2003 09:33:03 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 19eama-0002pR-00 for nsis@ietf.org; Mon, 21 Jul 2003 09:32:52 -0400 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Mon, 21 Jul 2003 15:31:00 +0200 Received: from docomolab-euro.com ([192.168.0.138]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 21 Jul 2003 15:31:00 +0200 Message-ID: <3F1BEC88.8000306@docomolab-euro.com> Date: Mon, 21 Jul 2003 15:37:12 +0200 From: Paulo Mendes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: Marcus Brunner , "Charles Q. Shen" , john.loughney@nokia.com, fu@cs.uni-goettingen.de, nsis@ietf.org Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-6ce13d44-84ef-469d-87bd-cd8adad425f6" X-OriginalArrivalTime: 21 Jul 2003 13:31:00.0204 (UTC) FILETIME=[52F0E2C0:01C34F8C] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ------=_NextPartTM-000-6ce13d44-84ef-469d-87bd-cd8adad425f6 Content-Type: multipart/alternative; boundary="------------090109090305040808030007" --------------090109090305040808030007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Robert, Below, I wrote some comments about the framework doc. Hancock, Robert wrote: >>Paulo, >> >>Sure, go ahead with discussions based on what stands in the framework. I >>think Robert would be glad to get some input on mobility aspects. >> >> > >Yes please, and do it sooooooon (and/or catch me this week). > >Actually, there was a more detailed discussion of some of the issues >you mention in the -00/-01 versions (i can provide them if you don't >have access). We took it out, partly because it seemed that no-one >apart from the author was interested in the subject. > > I'm interested in reading these two previous versions, and I do not have access to them :). >A tiny summary of the proposed way forwards for those who are >interested (in fact, the following - along with a potted summary >of the overall analysis - might be the basis of the eventual >framework content, with all the detail moved to another document): > I also agree with this division, as I already mentioned before: a complete description of the problems and possible solutions is too dense for the framework doc. >The framework layer split concept is that the NTLP works in terms >of packet streams ("flows") which are identifiable by nodes inside >the network. This is reflected practically in the fact that the >NTLP universe revolves around "flow-ids" (3/5 tuple etc. - see other >emails). The NTLP knows how to route (and re-route) signalling >messages along the path corresponding to a flow ID, but it >doesn't know anything about any relationships between different >flows (i.e. with different flow IDs). > > The need for a session ID is already understood as a basic need for NTLP. How can such session ID give support to other issues besides the discovery of the cross router, is another matter. For instance, should the session ID be tight related with the IP address of the old access router? The importance of this issue can depend on the way the protocol operates, namely if the release of resources in the old-path is done from the cross router or from the old access network. >An IP-visible mobility event (MIP/SIP/HIP/...) results intrinsically >in a new flow ID and also an update of the packet classifiers and >so on. The NTLP doesn't know how the new flow relates to the old; >NSIS-aware nodes which see both flows handle the interactions >between them at the signalling application level (i.e. in the NSLP). >Essentially, the same reasoning applies to the multihoming case, i.e. >it's an NSLP issue. > > Besides the session ID, the need for an implementation-neutral way of dealing with encapsulation is of major importance. This is already mentioned in the -03 version of the framework. >The NTLP has a greater proportion of the responsibility for >simple re-routing events (actually, the same responsibility, but >the re-routing problem is much simpler for several reasons). Those >people interested in the general problem of seamless handover >support would first have to consider whether that is done by >re-routing (i.e. there are updated host routes in the network) >or by changing IP address. That's a nice subject. > > The subject of seamless handover is of great importance, because in a mobile environment a signaling protocol should avoid the disruptions of the quality level of multimedia sessions during or after a handover. As mentioned in the framework (section 5.2) "The main issues for a resource signaling application are limiting the period after handovers during which the resources are not available along the path". Hence, in what concerns resource signaling, the quality level of a mobile session depends on two main factors: a) the capacity of the new access network b) the capacity of the new e2e path These two issues are of importance since the time available to setup resources in the new path are constrained by the time available for the handover. The problem of the capacity of the new access network is somehow mentioned in the framework, where in section 5.2.5, it is referred the work being done on the Seamoby WG. It is referred how NSIS can trigger context transfer and how NSIS can be used to transport such context information. However, there is no reference about the influence that CARD or other discovery protocols can have in the operation of NSIS. For instance, should/must NSIS be triggered by route advertisements of a mobile protocol such as MIP, or should/must NSIS wait for the information about the best access network provided by a CARD-like protocol? Even if the best access network can be provided by a CARD-like protocol, there is no insurance that the new e2e path can support the quality level required by the session. As said in section 5.1.2 "It is not guaranteed that the new path will be able to provide the same characteristics that were available on the old path". On the one hand, if NSIS tries to setup the new path but the minimum quality level required by the session is not support, the session is disrupted. On the other hand, if the minimum quality level is support, but not the desired quality level, some re-negotiation process is required, which can take longer time than the time available for the handover. In this case, the seamless desired characteristic of the handover can not be accomplish. Therefore, to enhance the support that NSIS can give to seamless handovers, it should be mentioned on point 5.2.5 the need to understand the relationship between NSIS and some kind of policy-based routing to avoid the dependency upon the capacity of the new shortest-e2e path. Since section 6.1.3 already mention that any QoS-NSLP has to be able to handle QoS-aware routing, only a pointer to 6.1.3 is needed in section 5.2.5. In what concerns section 6.1.3, two approaches are mentioned to make BGP QoS-aware. However, from the Router Area Meeting that happened in Vienna, it seems that there is no consensus about continuing to extend BGP or to use a new protocol to provide the extra required routing functionalities. Hence, section 6.1.3 should also consider other future options, such as the use of other protocol to signal "QoS-reachability" to BGP routers. Probably NSIS can be a candidate for this job, similar to the transport of context information between access networks, as mentioned in section 5.2.5. To avoid some of the BGP problems, namely the convergence time, probably this use of NSIS can be more efficient if done decoupled from the data path. Cheers, Paulo >cheers, > >robert h. > > > >>Marcus >> >> >> >>>I agree with Charles's opinion. Some discussion is needed to reflect on >>>some issues already mentioned in the Framework, but that need a more >>>detailed analysis, such as seamless handover support for mobile >>>real-time data transmission. >>> >>> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > >-- >Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, >Berkshire. RG12 8FZ > >The information contained in this e-mail and any attachments is confidential to >Roke Manor Research Ltd and must not be passed to any third party without >permission. This communication is for information only and shall not create or >change any contractual relationship. > > > -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ --------------090109090305040808030007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Robert,

Below, I wrote  some comments about the framework doc.

Hancock, Robert wrote:
Paulo,

Sure, go ahead with discussions based on what stands in the framework. I
think Robert would be glad to get some input on mobility aspects.
    

Yes please, and do it sooooooon (and/or catch me this week).

Actually, there was a more detailed discussion of some of the issues
you mention in the -00/-01 versions (i can provide them if you don't
have access). We took it out, partly because it seemed that no-one
apart from the author was interested in the subject.
I'm interested in reading these two previous versions, and I do not have access to them :).
A tiny summary of the proposed way forwards for those who are
interested (in fact, the following - along with a potted summary
of the overall analysis - might be the basis of the eventual
framework content, with all the detail moved to another document):
I also agree with this division, as I already mentioned before: a complete description of the problems and possible solutions is too dense for the framework doc.
The framework layer split concept is that the NTLP works in terms
of packet streams ("flows") which are identifiable by nodes inside
the network. This is reflected practically in the fact that the
NTLP universe revolves around "flow-ids" (3/5 tuple etc. - see other
emails). The NTLP knows how to route (and re-route) signalling
messages along the path corresponding to a flow ID, but it
doesn't know anything about any relationships between different
flows (i.e. with different flow IDs).
The need for a session ID is already understood as a basic need for NTLP.  How can such session ID give support to other issues besides the discovery of the cross router, is another matter. For instance, should the session ID be tight related with the IP address of the old access router? The importance of this issue can depend on the way the protocol operates, namely if the release of resources in the old-path is done from the cross router or from the old access network.
An IP-visible mobility event (MIP/SIP/HIP/...) results intrinsically
in a new flow ID and also an update of the packet classifiers and
so on. The NTLP doesn't know how the new flow relates to the old;
NSIS-aware nodes which see both flows handle the interactions
between them at the signalling application level (i.e. in the NSLP).
Essentially, the same reasoning applies to the multihoming case, i.e.
it's an NSLP issue.
Besides the session ID, the need for an implementation-neutral way of dealing with encapsulation is of major importance. This is already mentioned in the -03 version of the framework.
The NTLP has a greater proportion of the responsibility for
simple re-routing events (actually, the same responsibility, but
the re-routing problem is much simpler for several reasons). Those
people interested in the general problem of seamless handover
support would first have to consider whether that is done by
re-routing (i.e. there are updated host routes in the network)
or by changing IP address. That's a nice subject.
The subject of seamless handover is of great importance, because in a mobile environment a signaling protocol should avoid the disruptions of the quality level of multimedia sessions during or after a handover. As mentioned in the framework (section 5.2) "The main issues for a resource signaling application are limiting the period after handovers during which the resources are not available along the path". Hence, in what concerns resource signaling, the quality level of a mobile session depends on two main factors:
a) the capacity of the new access network
b) the capacity of the new e2e path

These two issues are of importance since the time available to setup resources in the new path are constrained by the time available for the handover.
The problem of the capacity of the new access network is somehow mentioned in the framework, where in section 5.2.5, it is referred the work being done on the Seamoby WG.  It is referred how NSIS can trigger context transfer and how NSIS can be used to transport such context information. However, there is no reference about the influence that CARD or other discovery protocols can have in the operation of NSIS. For instance, should/must NSIS be triggered by route advertisements of a mobile protocol such as MIP, or should/must NSIS wait for the information about the best access network provided by a CARD-like protocol?

Even if the best access network can be provided by a CARD-like protocol, there is no insurance that the new e2e path can support the quality level required by the session. As said in section 5.1.2 "It is not guaranteed that the new path will be able to provide the same characteristics that were available on the old path".
On the one hand, if NSIS tries to setup the new path but the minimum quality level required by the session is not support, the session is disrupted. On the other hand, if the minimum quality level is support, but not the desired quality level, some re-negotiation process is required, which can take longer time than the time available for the handover. In this case, the seamless desired characteristic of the handover can not be accomplish.
Therefore, to enhance the support that NSIS can give to seamless handovers, it should be mentioned on point 5.2.5 the need to understand the relationship between NSIS and some kind of policy-based routing to avoid the dependency upon the capacity of the new shortest-e2e path. Since section 6.1.3 already mention that any QoS-NSLP has to be able to handle QoS-aware  routing, only a pointer to 6.1.3 is needed in section 5.2.5.

In what concerns section 6.1.3, two approaches are mentioned to make BGP QoS-aware. However, from the Router Area Meeting that happened in Vienna, it seems that there is no consensus about continuing to extend BGP or to use a new protocol to provide the extra required routing functionalities. Hence, section 6.1.3 should also consider other future options, such as the use of other protocol to signal "QoS-reachability" to BGP routers. Probably NSIS can be a candidate for this job, similar to the transport of context information between access networks, as mentioned in section 5.2.5. To avoid some of the BGP problems, namely the convergence time, probably this use of NSIS can be more efficient if done decoupled from the data path.

Cheers,
Paulo
cheers,

robert h.

  
Marcus

    
I agree with Charles's opinion. Some discussion is needed to reflect on
some issues already mentioned in the Framework, but that need a more
detailed analysis, such as seamless handover support for mobile
real-time data transmission.
      
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

    

--
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.

  


-- 
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Tel. +49-89-56824-226
Fax. +49-89-56824-300
E-mail: mendes@docomolab-euro.com
http://www.docomoeurolabs.de/

--------------090109090305040808030007-- ------=_NextPartTM-000-6ce13d44-84ef-469d-87bd-cd8adad425f6-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 09:52:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27291 for ; Mon, 21 Jul 2003 09:52:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eb57-0005cr-Te for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 09:52:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LDq1n1021618 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 09:52:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eb57-0005cZ-Kw; Mon, 21 Jul 2003 09:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eb4n-0005cG-SD for nsis@optimus.ietf.org; Mon, 21 Jul 2003 09:51:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27280 for ; Mon, 21 Jul 2003 09:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eb4l-00031R-00 for nsis@ietf.org; Mon, 21 Jul 2003 09:51:39 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19eb4b-000311-00 for nsis@ietf.org; Mon, 21 Jul 2003 09:51:29 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jul 2003 15:50:36 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jul 2003 15:50:35 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB544@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: sbrim@cisco.com Cc: nsis@ietf.org Subject: RE: [NSIS] Reliable Transport for NTLP Date: Mon, 21 Jul 2003 15:50:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Scott, valid statement. I'd like to point out to draft-pan-nsis-rsvp-transport-00.txt. It says: ---begin quote--------- 2.4. RSVP-TE vs. Signaling Protocol for Real-Time Applications RSVP-TE works in an environment that is different from what the original RSVP has been designed for: in MPLS networks, the RSVP sessions that are used to support Label-Switched-Paths (LSP's) do not change frequently.....[snip] On the other hand, in many of the new applications where a signaling protocol is required, the user session duration can be relatively short. The dynamics of adding/dropping user sessions could introduce a large number of "triggered" messages in the network. This can clearly introduce a substantial amount of processing overhead to the routers. This is one area where a new signaling protocol may be needed to reduce the processing complexity in the resource reservation process. ------end quote----- As I mentioned in another mail, I think reliablbe transport isn't required if there's a "low" amount of signaling to be processed. If NSIS will be designed to prevent a "high" signaling load in backbones, I guess I won't have a problem. Besides RSVP TE (and DiffServ aware TE) there's also RFC 3175 ( aggregated RSVP). Both aim on rather stable state in the backbone by flow aggregation. Backbone load reduction is a "SHOULD" in the requirements, pointing to the framework for details. I was not able to clearly identify them. I'm concerned that NSIS is focused too much on end-system based signaling and might fail on the edge to edge part. Regards, Rudiger |-----Original Message----- |From: Scott W Brim [mailto:sbrim@cisco.com] |Sent: Monday, July 21, 2003 1:14 PM |To: nsis@ietf.org |Subject: Re: [NSIS] Reliable Transport for NTLP | | |On Mon, Jul 21, 2003 11:30:47AM +0200, Geib, Ruediger allegedly wrote: |> "Reliable transport" for signaling applications is an issue whith |> ample operational and implementation experience. Hence I'd suggest |> that we stick to the "lessons learned" paradigm instead |> of constructing abstract scenarios. I've e.g. refered to BGP and LDP |> as signaling protocols making use of TCP. |> I'd ask you to point out issues with TCP transport based on past |> experience. I'd appreciate if you could |> |> - provide reference to any signaling protocol which wasn't |> deployed in backbone networks due to TCP transport. |> |> - provide reference to a TCP based backbone signaling protocol which |> will result in an NSIS signaling failure due to TCP transport. |> |> When answering, please keep in mind that I'm not asking to have NTLP |> reliable transport as the only allowed mode of operation. | |A casual lurker speaks up ... I think the questions are extreme -- can |you provide an example of a protocol which will fail because it does |*not* run over TCP? Bad protocols don't get far enough for these |questions to be asked. Thus I consider them rhetorical. However, if |you want to consider advantages/disadvantages of TCP, consider CR-LDP |versus RSVP-TE. CR-LDP used a TCP session. RSVP-TE used its own |reliability mechanisms and did not ask for reliability in its lower |layer. | |TCP is designed for stream reliability, not for transaction |reliability. |RSVP-TE was able to tune its own timers for its own needs, instead of |using those optimized for the general case of an average application. |It had control over whether, in a retransmission, the same message was |retried, or a new, more up-to-date message was attempted instead. It |was able to provide more control plane predictability because messages |did not necessarily have to wait for previous messages to be |acknowledged. When connectivity was lost and thousands of updates |needed to be sent, it could choose whether to serialize them all at the |transport layer (as LDP did with a single TCP connection) or send |some/many in parallel (serializing at the link layer). | |People did not reject CR-LDP because it ran on TCP. However, the fact |that it did was not seen as an advantage. | |..swb | |_______________________________________________ |nsis mailing list |nsis@ietf.org |https://www1.ietf.org/mailman/listinfo/nsis | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 10:30:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29230 for ; Mon, 21 Jul 2003 10:30:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebfs-0006xx-Vw for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 10:30:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LEU0Ns026759 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 10:30:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebfs-0006xV-Rm; Mon, 21 Jul 2003 10:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebf8-0006uu-F9 for nsis@optimus.ietf.org; Mon, 21 Jul 2003 10:29:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29164 for ; Mon, 21 Jul 2003 10:29:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ebf5-0003Iy-00 for nsis@ietf.org; Mon, 21 Jul 2003 10:29:11 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19ebev-0003IY-00 for nsis@ietf.org; Mon, 21 Jul 2003 10:29:01 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSK1S1T>; Mon, 21 Jul 2003 15:27:54 +0100 Message-ID: From: "Hancock, Robert" To: "'Geib, Ruediger'" Cc: nsis@ietf.org, "Marcus Brunner (E-mail)" Date: Mon, 21 Jul 2003 15:27:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] aggregation and the framework (was RE: Reliable Transport for NTL P) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , brief comment, > Backbone load reduction is a "SHOULD" in the requirements, > pointing to > the framework for details. I was not able to clearly identify > them. I'm > concerned that NSIS is focused too much on end-system based > signaling and > might fail on the edge to edge part. I think that's the only place in the requirements where there is that type of forward reference to the framework, and it is probably inappropriate there. Probably 'The framework...' --> 'A signalling solution...' or something would be more apt. (Marcus?) The framework currently contains almost nothing on aggregation; that's partly because it seems to be mainly signalling-application specific, but that should be discussed (probably somewhere in 3.3). The main impact on the framework fundamentals would be on the message routing front, where the discussion at the end of 3.2.1 needs to be broadened to cover 3175-style processing. [In our qos-nslp work we cared about aggregation a lot.] I have a more substantive comment on the reliability front, which I'll save for later. cheers, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 10:48:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29806 for ; Mon, 21 Jul 2003 10:48:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebxJ-0007sz-9a for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 10:48:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LEm13w030296 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 10:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebxI-0007sX-MV; Mon, 21 Jul 2003 10:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebx7-0007sI-DM for nsis@optimus.ietf.org; Mon, 21 Jul 2003 10:47:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29795 for ; Mon, 21 Jul 2003 10:47:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ebx4-0003Tm-00 for nsis@ietf.org; Mon, 21 Jul 2003 10:47:46 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19ebwt-0003TS-00 for nsis@ietf.org; Mon, 21 Jul 2003 10:47:36 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jul 2003 16:47:00 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jul 2003 16:47:00 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB546@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Date: Mon, 21 Jul 2003 16:46:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RE: aggregation and the framework (was RE: Reliable Transport for NTL P) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Robert, |[In our qos-nslp work we cared about aggregation a lot.] Yes, your draft offers two solutions, and I think that=20 also the westberg draft specifies signaling aggregation.=20 Regards, R=FCdiger=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 10:56:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29973 for ; Mon, 21 Jul 2003 10:56:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ec53-000880-HQ for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 10:56:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LEu1VV031227 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 10:56:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ec52-000878-TY; Mon, 21 Jul 2003 10:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ec4b-00086o-27 for nsis@optimus.ietf.org; Mon, 21 Jul 2003 10:55:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29953 for ; Mon, 21 Jul 2003 10:55:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ec4Y-0003Xa-00 for nsis@ietf.org; Mon, 21 Jul 2003 10:55:30 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19ec4N-0003X3-00 for nsis@ietf.org; Mon, 21 Jul 2003 10:55:19 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jul 2003 16:54:23 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jul 2003 16:54:23 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB547@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Date: Mon, 21 Jul 2003 16:54:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RE: aggregation and the framework (was RE: Reliable Transport for NTL P) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Robert, |The framework currently contains almost nothing on aggregation; |that's partly because it seems to be mainly signalling-application |specific, but that should be discussed (probably somewhere in 3.3).=20 I agree that aggregation isn't a general requirement.=20 Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 14:19:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05705 for ; Mon, 21 Jul 2003 14:19:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efFW-0007SW-Bm for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 14:19:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LIJ2nY028655 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 14:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efFV-0007S4-4I; Mon, 21 Jul 2003 14:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efF9-0007Rs-1z for nsis@optimus.ietf.org; Mon, 21 Jul 2003 14:18:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05695 for ; Mon, 21 Jul 2003 14:18:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efF6-00059t-00 for nsis@ietf.org; Mon, 21 Jul 2003 14:18:36 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19efEv-00059h-00 for nsis@ietf.org; Mon, 21 Jul 2003 14:18:26 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2003 11:18:27 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6LIHl8B001815; Mon, 21 Jul 2003 11:17:49 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV11103; Mon, 21 Jul 2003 11:17:46 -0700 (PDT) Message-Id: <200307211817.AJV11103@mira-sjc5-c.cisco.com> To: "Geib, Ruediger" cc: john.loughney@nokia.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] apology to Melinda In-Reply-To: Message from Ruediger.Geib@t-systems.com of "Mon, 21 Jul 2003 09:22:58 +0200." <9F8582E37B2EE5498E76392AEDDCD3FE03DBB53E@G8PQD.blf01.telekom.de> Date: Mon, 21 Jul 2003 14:17:46 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Thank you very much for the apology, but everything is fine. It's important to be passionate about your work :-). Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 21 18:25:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13652 for ; Mon, 21 Jul 2003 18:25:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ej5Z-00017K-Ka for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 18:25:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LMP1ak004277 for nsis-archive@odin.ietf.org; Mon, 21 Jul 2003 18:25:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ej5Y-00016q-Oi; Mon, 21 Jul 2003 18:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ej4m-00016J-TV for nsis@optimus.ietf.org; Mon, 21 Jul 2003 18:24:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13600 for ; Mon, 21 Jul 2003 18:24:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ej4i-0006kb-00 for nsis@ietf.org; Mon, 21 Jul 2003 18:24:08 -0400 Received: from lion.seas.upenn.edu ([158.130.12.194]) by ietf-mx with esmtp (Exim 4.12) id 19ej4X-0006kQ-00 for nsis@ietf.org; Mon, 21 Jul 2003 18:23:57 -0400 Received: from blue.seas.upenn.edu (BLUE.SEAS.UPENN.EDU [158.130.64.177]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6LMNTM1002642 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 21 Jul 2003 18:23:29 -0400 Received: from blue.seas.upenn.edu (localhost [127.0.0.1]) by blue.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6LMNTOM011223; Mon, 21 Jul 2003 18:23:29 -0400 (EDT) Received: from localhost (rsofia@localhost) by blue.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6LMNSS1011220; Mon, 21 Jul 2003 18:23:28 -0400 (EDT) Date: Mon, 21 Jul 2003 18:23:28 -0400 (EDT) From: "Rute C. Sofia" To: Sven Van den Bosch cc: nsis@ietf.org Subject: Re: [NSIS] NSLP design draft: way forward In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Sven, first of all, the plan you described seems a quite good and complete one. Some questions and comments: > considerations related to protocol extensibility (way of creating new > objects) and QoS models (what makes up a QoS model, how is this reflected in > standards procedure and can we map RSVP to it as an example). It would also I believe that by "QoS model", you mean something as "signaling model", right? If you do mean QoS model, I'm a bit confused on how it fits in the draft... If you mean "signaling model", then possibly it would make sense to address definitions of "QoS profile" and "QoS item". Also, not sure if RSVP should really be used as an example in the draft. Current signaling proposals have been addressed in the analysis draft. RSVP is quite covered there... > including aggregation, tunnel management, bidirectional/proxy operation and > priority/preemption Another thing that would probably make sense in addressing (open issues, later draft versions) is a possible criteria for characterizing a proposal, e.g., scalability, complexity, adaptability, and so on... Rute _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 22 01:17:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19894 for ; Tue, 22 Jul 2003 01:17:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19epWI-0003on-JE for nsis-archive@odin.ietf.org; Tue, 22 Jul 2003 01:17:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M5H2Lx014673 for nsis-archive@odin.ietf.org; Tue, 22 Jul 2003 01:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19epWH-0003oY-LN; Tue, 22 Jul 2003 01:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eXo9-0007Rz-J3 for nsis@optimus.ietf.org; Mon, 21 Jul 2003 06:22:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22952 for ; Mon, 21 Jul 2003 06:22:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eXo5-0001W2-00 for nsis@ietf.org; Mon, 21 Jul 2003 06:22:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19eXnv-0001V3-00 for nsis@ietf.org; Mon, 21 Jul 2003 06:22:03 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6LAIVuG006949 for ; Mon, 21 Jul 2003 03:18:31 -0700 (PDT) Received: from cisco.com (sjc-vpn1-681.cisco.com [10.21.98.169]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIE54164; Mon, 21 Jul 2003 03:12:45 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Mon, 21 Jul 2003 12:18:32 +0200 Date: Mon, 21 Jul 2003 12:18:31 +0200 From: Scott W Brim To: nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP Message-ID: <20030721121831.A2080@sbrim-w2k01> Mail-Followup-To: Scott W Brim , nsis@ietf.org References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB540@G8PQD.blf01.telekom.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB540@G8PQD.blf01.telekom.de>; from Ruediger.Geib@t-systems.com on Mon, Jul 21, 2003 at 11:30:47AM +0200 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , On Mon, Jul 21, 2003 11:30:47AM +0200, Geib, Ruediger allegedly wrote: > "Reliable transport" for signaling applications is an issue whith > ample operational and implementation experience. Hence I'd suggest > that we stick to the "lessons learned" paradigm instead > of constructing abstract scenarios. I've e.g. refered to BGP and LDP > as signaling protocols making use of TCP. > I'd ask you to point out issues with TCP transport based on past > experience. I'd appreciate if you could > > - provide reference to any signaling protocol which wasn't deployed in > backbone networks due to TCP transport. > > - provide reference to a TCP based backbone signaling protocol which > will result in an NSIS signaling failure due to TCP transport. > > When answering, please keep in mind that I'm not asking to have NTLP > reliable transport as the only allowed mode of operation. A casual lurker speaks up ... I think the questions are extreme -- can you provide an example of a protocol which will fail because it does *not* run over TCP? Bad protocols don't get far enough for these questions to be asked. Thus I consider them rhetorical. However, if you want to consider advantages/disadvantages of TCP, consider CR-LDP versus RSVP-TE. CR-LDP used a TCP session. RSVP-TE used its own reliability mechanisms and did not ask for reliability in its lower layer. TCP is designed for stream reliability, not for transaction reliability. RSVP-TE was able to tune its own timers for its own needs, instead of using those optimized for the general case of an average application. It had control over whether, in a retransmission, the same message was retried, or a new, more up-to-date message was attempted instead. It was able to provide more control plane predictability because messages did not necessarily have to wait for previous messages to be acknowledged. When connectivity was lost and thousands of updates needed to be sent, it could choose whether to serialize them all at the transport layer (as LDP did with a single TCP connection) or send some/many in parallel (serializing at the link layer). People did not reject CR-LDP because it ran on TCP. However, the fact that it did was not seen as an advantage. ..swb _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 22 06:28:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08357 for ; Tue, 22 Jul 2003 06:28:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euNG-0008R9-VT for nsis-archive@odin.ietf.org; Tue, 22 Jul 2003 06:28:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MAS2SK032427 for nsis-archive@odin.ietf.org; Tue, 22 Jul 2003 06:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euNF-0008QU-JC; Tue, 22 Jul 2003 06:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euMH-0008Pt-B6 for nsis@optimus.ietf.org; Tue, 22 Jul 2003 06:27:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08325 for ; Tue, 22 Jul 2003 06:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19euMD-0003KU-00 for nsis@ietf.org; Tue, 22 Jul 2003 06:26:57 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19euM2-0003KC-00 for nsis@ietf.org; Tue, 22 Jul 2003 06:26:46 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSK1S5K>; Tue, 22 Jul 2003 11:25:57 +0100 Message-ID: From: "Hancock, Robert" To: "'Scott W Brim'" , nsis@ietf.org Subject: RE: [NSIS] Reliable Transport for NTLP Date: Tue, 22 Jul 2003 11:25:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Scott, You raise some interesting points, but I'm not sure which direction the argument leads in. It seems clear that the argument is not about whether reliability is needed for signalling messages - indeed, as you point out, both CR-LDP/RSVP-TE provided this, just in different ways. What's at issue is how to provide it (when it is needed), which is itself 2 questions in this working group context: a) whether to provide it as a common service (in the lower layer NSIS protocol), or whether to build it separately into each signalling application that wants it b) whether to do a customised NSIS design, or whether to re-use an existing transport protocol. The open question which is the biggest barrier to progress at the moment is actually (a), because it hinders us from splitting up design work between NTLP and NSLP. My personal view is that there are strong arguments for providing reliability as a (shared but optional) lower layer service, because e.g. *) retransmission behaviour has to be sensitive to network layer load (congestion avoidance), which I see as a general lower layer function; *) retransmission has to distinguish somehow between congestive loss and loss caused by next-peer change, which is also a lower layer function; *) in a multi-signalling-application environment there are gains from sharing the state required for reliability between applications; ...and so on. And I also think that different signalling applications will not have wildly different reliability requirements, so a common service makes sense. I suspect that SCTP (including partial reliability extensions) or something home-made on top of DCCP would be a better match to those requirements than TCP, but that's a later question (and you could still also do something completely home-made, like 2961 did). So far as the MPLS experience is concerned, there is one aspect of the environment which makes me wary of taking it too directly. AFAIK, RSVP-TE requires next-IP-hop routers to be RSVP-TE aware; in other words, reliability, congestion control, etc. etc. have to be provided over a single L2 hop (whose characteristics you know pretty well). That's a much much simpler environment than the NSIS one, where many of the likely scenarios involve large numbers of NSIS-unaware intermediate nodes. The design approach that "When connectivity was lost and thousands of updates needed to be sent, [RSVP-TE] could choose ... to send some/many in parallel" starts to sound dangerous here. cheers, r. > -----Original Message----- > From: Scott W Brim [mailto:sbrim@cisco.com] > Sent: Monday, July 21, 2003 12:14 > To: nsis@ietf.org > Subject: Re: [NSIS] Reliable Transport for NTLP > > > On Mon, Jul 21, 2003 11:30:47AM +0200, Geib, Ruediger allegedly wrote: > > "Reliable transport" for signaling applications is an issue whith > > ample operational and implementation experience. Hence I'd suggest > > that we stick to the "lessons learned" paradigm instead > > of constructing abstract scenarios. I've e.g. refered to BGP and LDP > > as signaling protocols making use of TCP. > > I'd ask you to point out issues with TCP transport based on past > > experience. I'd appreciate if you could > > > > - provide reference to any signaling protocol which wasn't > deployed in > > backbone networks due to TCP transport. > > > > - provide reference to a TCP based backbone signaling protocol which > > will result in an NSIS signaling failure due to TCP transport. > > > > When answering, please keep in mind that I'm not asking to have NTLP > > reliable transport as the only allowed mode of operation. > > A casual lurker speaks up ... I think the questions are > extreme -- can > you provide an example of a protocol which will fail because it does > *not* run over TCP? Bad protocols don't get far enough for these > questions to be asked. Thus I consider them rhetorical. However, if > you want to consider advantages/disadvantages of TCP, consider CR-LDP > versus RSVP-TE. CR-LDP used a TCP session. RSVP-TE used its own > reliability mechanisms and did not ask for reliability in its lower > layer. > > TCP is designed for stream reliability, not for transaction > reliability. > RSVP-TE was able to tune its own timers for its own needs, instead of > using those optimized for the general case of an average application. > It had control over whether, in a retransmission, the same message was > retried, or a new, more up-to-date message was attempted instead. It > was able to provide more control plane predictability because messages > did not necessarily have to wait for previous messages to be > acknowledged. When connectivity was lost and thousands of updates > needed to be sent, it could choose whether to serialize them > all at the > transport layer (as LDP did with a single TCP connection) or send > some/many in parallel (serializing at the link layer). > > People did not reject CR-LDP because it ran on TCP. However, the fact > that it did was not seen as an advantage. > > ..swb > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 22 16:13:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25543 for ; Tue, 22 Jul 2003 16:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3VN-0007W3-HC for nsis-archive@odin.ietf.org; Tue, 22 Jul 2003 16:13:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MKD1JJ028873 for nsis-archive@odin.ietf.org; Tue, 22 Jul 2003 16:13:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3VN-0007VV-D5; Tue, 22 Jul 2003 16:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3Re-0007Ph-1g for nsis@optimus.ietf.org; Tue, 22 Jul 2003 16:09:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25409; Tue, 22 Jul 2003 16:09:02 -0400 (EDT) Message-Id: <200307222009.QAA25409@ietf.org> From: The IESG To: IETF-Announce: ; Cc: John Loughney , nsis@ietf.org Date: Tue, 22 Jul 2003 16:09:02 -0400 Subject: [NSIS] WG Action: RECHARTER: Next Steps in Signaling (nsis) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , The Next Steps in Signaling (nsis) Working Group in the Transport Area of the IETF has been rechartered. For additional information, contact the Area Directors or the Working Group Chairs. Next Steps in Signaling (nsis) ------------------------------- Current Status: Active Working Group Chair(s): John Loughney Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion: nsis@ietf.org To Subscribe: nsis-request@ietf.org In Body: (un)subscribe Archive: www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html Description of Working Group: The Next Steps in Signaling Working Group is responsible for standardizing an IP signaling protocol with QoS signaling as the first use case. This working group will concentrate on a two-layer signaling paradigm. The intention is to re-use, where appropriate, the protocol mechanisms of RSVP, while at the same time simplifying it and applying a more general signaling model. The existing work on the requirements, the framework and analysis of existing protocols will be completed and used as input for the protocol work. NSIS will develop a transport layer signaling protocol for the transport of upper layer signaling. In order to support a toolbox or building block approach, the two-layer model will be used to separate the transport of the signaling from the application signaling. This allows for a more general signaling protocol to be developed to support signaling for different services or resources, such as NAT & firewall traversal and QoS resources. The initial NSIS application will be an optimized RSVP QoS signaling protocol. The second application will be a middle box traversal protocol. It may be that a rechartering of the working group occurs before the completion of this milestone. Security is a very important concern for NSIS. The working group will study and analyze the threats and security requirements for signaling. Compatibility with authentication and authorization mechanisms such as those of Diameter, COPS for RSVP (RFC 2749) and RSVP Session Authorization (RFC 3250), will be addressed. It is a non-goal of the working group to develop new resource allocation protocols. Resource reservation and traffic engineering are out of scope of this working group. Additionally, third party signaling is out of scope of this working group. Mobility protocols and AAA work are out of scope of the working group. The work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context Transfer, etc. NSIS also welcomes participation and expression of requirements from non-IETF standards organization members, for instance 3GPP, 3GPP2 and ITU-T. Goals and Milestones: Done Submit 'Signaling Requirements' to IESG for publication as an Informational RFC. Aug 03 Submit 'RSVP Security Properties' to IESG as Informational RFC Aug 03 Submit 'NSIS Threats' to IESG as Informational RFC Sep 03 Submit 'Analysis of Existing Signaling Protocols' to IESG as Informational RFC Sep 03 Submit 'Next Steps in Signaling: Framework' to IESG for publication as Informational RFC Feb 04 Submit 'NSIS Transport Protocol' to IESG for publication for Proposed Standard Mar 04 Submit 'NSIS QoS Application Protocol' to IESG for publication for Proposed Standard Sep 04 Submit 'NSIS Middle Box Signaling Application Protocol' to IESG for publication for Proposed Standard _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 22 16:13:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25554 for ; Tue, 22 Jul 2003 16:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3VN-0007Vp-Fm for nsis-archive@odin.ietf.org; Tue, 22 Jul 2003 16:13:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MKD1jd028865 for nsis-archive@odin.ietf.org; Tue, 22 Jul 2003 16:13:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3VN-0007VN-0J; Tue, 22 Jul 2003 16:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0KL-0006eO-NX for nsis@optimus.ietf.org; Tue, 22 Jul 2003 12:49:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19343 for ; Tue, 22 Jul 2003 12:49:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f0KK-0005vX-00 for nsis@ietf.org; Tue, 22 Jul 2003 12:49:24 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19f0K9-0005vU-00 for nsis@ietf.org; Tue, 22 Jul 2003 12:49:13 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6MGmljG024102; Tue, 22 Jul 2003 18:48:47 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <366DJPY9>; Tue, 22 Jul 2003 18:49:20 +0200 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28ET/ETH=29?= To: Thanh Tra LUU , karagiannis Cc: nsis@ietf.org Subject: RE: [NSIS] input (over RMD) for NSIS Analysis draft Date: Tue, 22 Jul 2003 18:48:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Nary, Thank you for your comments, please see my answers inline. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On > Behalf Of Thanh > Tra LUU > Sent: Saturday, July 19, 2003 9:37 AM > To: karagiannis > Cc: nsis@ietf.org > Subject: Re: [NSIS] input (over RMD) for NSIS Analysis draft > > > Hi, > > I've read the draft of proposal for RSVPv2 NSLP. I have some > questions. > > - For bi-directional reservation, you call NI (sender) and > NR(receiver), it makes me confused because both of end hosts can be > receiver and sender. Supposing the bi-directional reservation between > A (and RSVPv2 aware) and B (another RSVPv2 aware end host) is > initiated by A (NI) . The two reservation can be established on two > different paths. The announcement of reservation success (A -> B) is > carried by packet Path(NslpPathInit) from B to A. Because of asymmetry > of routing, it is possible that the intermediate NTLP stateful nodes > between A and B don't receive this message to know the success of > reservation. They will only know it after receiving the refresh > message from sender. In case unidirectional reservation, the > intermediate nodes know it by receiving the NslpResvInit. Why is there > this difference ? Is it useful ? I agree with you that NI and NR notations can be confusing in case of bidirectional resrevation. Especially if NSLP supports different types of bi-directional reservation methods. We should think of a better terminology for the next nslp design draft. In our concept general rules are: sender and ingress edge nodes should receive acknowledgement, other statefull NF nodes and egress edge nodes may get acknowledgement, NTLP stateless nodes cannot receive acknowledgement. In case of unidirectional reservation, NslpResvInit is sent back in RESV message, which is routed by NTLP, therefore NFs can get acknowledgement easily. In case of bidirectional reservation acknowledgement to NI is sent in PATH(NslpPathInit) in the simplest case. RESV(NslpResvInit) may be sent in both direction if NFs need acknowledgement. (This example is not shown in the figures.) > - I don't understand how the NTLP stateless node can support the > routing change. No state is established when NTLP stateless receives a > Path(NslpPathInit) message. When NTLP stateless receives a > Path(NslpPahInit), it adds the new required reservation units of a > traffic class. When it receives a PathTear(NslpPathTear), it will > subtract the required resource. As previous mail, you said > "simultaneously maintained RMD reservation states in the interior > nodes is equal to the number of the supported traffic classes", that > means if there is a routing change, a deletion of a flux can delete a > required resource on a intermediate NTLP stateless node which was not > previously on the data path. > In stateless nodes we have to rely on soft states. If routing changes in the domain, two things can happen. If it does not cause packet drop or delay, edge nodes do not notice route change, resources in the new route are added and resources along the old routes are removed automatically after time-out. If routing causes packet drop or delay, data packets are marked, which notify edge node. Edge node may block this flow and resource is removed after time out. You are right PathTear(NslpPathTear) should not be sent in this case, I think the figure in the draft is wrong. > - I don't understand refresh mechanism for the interior NTLP stateless > node either. How does a interior NTLP stateless nodes know a refresh > message belongs to a specific flux of a traffic class ? If there is > not the refresh for a flux in the NTLP stateless nodes, what does the > refresh mean here ? > The interior node does not know to which flow a resource unit belongs to. Refresh means, adding x number of resource units to a traffic class state. y resource unit, reserved in the previous refresh period is released. To be more exact the refresh period is divided to n number of time slots, and refresh units per slot per traffic class is counted and released after time out. > - For the severe congestion handling, interruption of a flux which is > reserved doesn't seems interesting to me. If I want to reserve > resource for a VoIP communication, it's better if network refuses the > connection before I can begin the conversation rather than disrupt my > communication. > Yes agree but severe congestion refers to an unexpected situation during call, like route change due to link or node failure. In new route all flows may can not be supported, some have to be terminated. > Nary Tra > ENST, Paris > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 23 05:41:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06942 for ; Wed, 23 Jul 2003 05:41:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fG7K-0002Ff-4x for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 05:41:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6N9f2it008651 for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 05:41:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fG7J-0002FQ-HP; Wed, 23 Jul 2003 05:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fG6M-0002El-MU for nsis@optimus.ietf.org; Wed, 23 Jul 2003 05:40:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06891 for ; Wed, 23 Jul 2003 05:39:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fG6J-0003YX-00 for nsis@ietf.org; Wed, 23 Jul 2003 05:39:59 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19fG68-0003YT-00 for nsis@ietf.org; Wed, 23 Jul 2003 05:39:48 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6N9dLjG006521; Wed, 23 Jul 2003 11:39:21 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <366DN1FP>; Wed, 23 Jul 2003 11:39:56 +0200 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28ET/ETH=29?= To: "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] Reliable Transport for NTLP Date: Wed, 23 Jul 2003 11:38:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert and All, I also think the question is very fundamental. Since NSIS addresses wider range of applications, most probably there will be NSLPs which like to use retransmission-like reliability, while other concepts intend to support reliability like RSVP does. Certainly both have advantages and disadvantages and it depends on the applications. In my view this latter is closer to the original concept of soft states and using RSVP as a base. Our stateless concept for example needs the simplest transport as possible and it may be reasonable for other NSLPs as well. I am afraid that if retransmission is a common service of NTLP, even if it is optional to use, it introduces unnecessary implementation complexity. The question can be put in another way as well: Should NTLP have optional features that can be invoked by different NSLPs, or NTLP should be a protocol supporting common basic features and optional feature are only in NSLP? I do not remember if we had a consensus regarding this question. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Hancock, Robert > Sent: Tuesday, July 22, 2003 12:26 PM > To: 'Scott W Brim'; nsis@ietf.org > Subject: RE: [NSIS] Reliable Transport for NTLP > > > Scott, > > You raise some interesting points, but I'm not sure which direction > the argument leads in. > > It seems clear that the argument is not about whether reliability > is needed for signalling messages - indeed, as you point out, both > CR-LDP/RSVP-TE provided this, just in different ways. What's at issue > is how to provide it (when it is needed), which is itself 2 questions > in this working group context: > a) whether to provide it as a common service (in the lower layer NSIS > protocol), or whether to build it separately into each signalling > application that wants it > b) whether to do a customised NSIS design, or whether to re-use an > existing transport protocol. > > The open question which is the biggest barrier to progress at the > moment is actually (a), because it hinders us from splitting > up design work > between NTLP and NSLP. > > My personal view is that there are strong arguments for providing > reliability as a (shared but optional) lower layer service, > because e.g. > *) retransmission behaviour has to be sensitive to network layer load > (congestion avoidance), which I see as a general lower layer function; > *) retransmission has to distinguish somehow between congestive loss > and loss caused by next-peer change, which is also a lower > layer function; > *) in a multi-signalling-application environment there are gains from > sharing the state required for reliability between applications; > ...and so on. > > And I also think that different signalling applications > will not have wildly different reliability requirements, so a common > service makes sense. I suspect that SCTP (including partial > reliability extensions) or something home-made on top of DCCP would be > a better match to those requirements than TCP, but that's a later > question (and you could still also do something completely home-made, > like 2961 did). > > So far as the MPLS experience is concerned, there is one aspect of the > environment which makes me wary of taking it too directly. > AFAIK, RSVP-TE > requires next-IP-hop routers to be RSVP-TE aware; in other > words, reliability, > congestion control, etc. etc. have to be provided over a single L2 hop > (whose characteristics you know pretty well). That's a much > much simpler > environment than the NSIS one, where many of the likely > scenarios involve > large numbers of NSIS-unaware intermediate nodes. The design > approach that > "When connectivity was lost and thousands of updates needed > to be sent, > [RSVP-TE] could choose ... to send some/many in parallel" starts > to sound dangerous here. > > cheers, > > r. > > > > -----Original Message----- > > From: Scott W Brim [mailto:sbrim@cisco.com] > > Sent: Monday, July 21, 2003 12:14 > > To: nsis@ietf.org > > Subject: Re: [NSIS] Reliable Transport for NTLP > > > > > > On Mon, Jul 21, 2003 11:30:47AM +0200, Geib, Ruediger > allegedly wrote: > > > "Reliable transport" for signaling applications is an issue whith > > > ample operational and implementation experience. Hence I'd suggest > > > that we stick to the "lessons learned" paradigm instead > > > of constructing abstract scenarios. I've e.g. refered to > BGP and LDP > > > as signaling protocols making use of TCP. > > > I'd ask you to point out issues with TCP transport based on past > > > experience. I'd appreciate if you could > > > > > > - provide reference to any signaling protocol which wasn't > > deployed in > > > backbone networks due to TCP transport. > > > > > > - provide reference to a TCP based backbone signaling > protocol which > > > will result in an NSIS signaling failure due to TCP transport. > > > > > > When answering, please keep in mind that I'm not asking > to have NTLP > > > reliable transport as the only allowed mode of operation. > > > > A casual lurker speaks up ... I think the questions are > > extreme -- can > > you provide an example of a protocol which will fail because it does > > *not* run over TCP? Bad protocols don't get far enough for these > > questions to be asked. Thus I consider them rhetorical. > However, if > > you want to consider advantages/disadvantages of TCP, > consider CR-LDP > > versus RSVP-TE. CR-LDP used a TCP session. RSVP-TE used its own > > reliability mechanisms and did not ask for reliability in its lower > > layer. > > > > TCP is designed for stream reliability, not for transaction > > reliability. > > RSVP-TE was able to tune its own timers for its own needs, > instead of > > using those optimized for the general case of an average > application. > > It had control over whether, in a retransmission, the same > message was > > retried, or a new, more up-to-date message was attempted > instead. It > > was able to provide more control plane predictability > because messages > > did not necessarily have to wait for previous messages to be > > acknowledged. When connectivity was lost and thousands of updates > > needed to be sent, it could choose whether to serialize them > > all at the > > transport layer (as LDP did with a single TCP connection) or send > > some/many in parallel (serializing at the link layer). > > > > People did not reject CR-LDP because it ran on TCP. > However, the fact > > that it did was not seen as an advantage. > > > > ..swb > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 23 06:46:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08100 for ; Wed, 23 Jul 2003 06:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH8E-0004F2-Py for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 06:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NAk2St016287 for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 06:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH8D-0004EZ-Rw; Wed, 23 Jul 2003 06:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH7k-0004Bb-0X for nsis@optimus.ietf.org; Wed, 23 Jul 2003 06:45:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08094 for ; Wed, 23 Jul 2003 06:45:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fH7f-0003q0-00 for nsis@ietf.org; Wed, 23 Jul 2003 06:45:27 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19fH7V-0003os-00 for nsis@ietf.org; Wed, 23 Jul 2003 06:45:17 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 23 Jul 2003 12:42:46 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 12:42:45 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB54F@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: attila.bader@ericsson.com Cc: nsis@ietf.org Subject: RE: [NSIS] Reliable Transport for NTLP Date: Wed, 23 Jul 2003 12:42:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Attila |The question can be put in another way as well: Should NTLP=20 |have optional features that can be invoked by different NSLPs,=20 |or NTLP should be a protocol supporting common basic features=20 |and optional feature are only in NSLP? I do not remember if we=20 |had a consensus regarding this question. I don't remember any past consensus on the issue. I'd like to=20 add that part of the problem is that re-inventing reliable=20 transport (or other interesting TCP/SCTP features) on higher=20 layers like NSLP probably isn't felt to be desirable by all. Regards, R=FCdiger=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 23 12:29:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18965 for ; Wed, 23 Jul 2003 12:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMU9-0001lh-Me for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 12:29:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NGT1jV006771 for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 12:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMU9-0001l6-2Y; Wed, 23 Jul 2003 12:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMU0-0001ku-3A for nsis@optimus.ietf.org; Wed, 23 Jul 2003 12:28:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18948 for ; Wed, 23 Jul 2003 12:28:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fMTy-000606-00 for nsis@ietf.org; Wed, 23 Jul 2003 12:28:50 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19fMTn-000600-00 for nsis@ietf.org; Wed, 23 Jul 2003 12:28:39 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6NGRlVI013413; Wed, 23 Jul 2003 18:27:48 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id F06594D481; Wed, 23 Jul 2003 18:07:52 +0200 (CEST) Date: Wed, 23 Jul 2003 18:27:47 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: mankin@psg.com, harald@alvestrand.no Cc: john.loughney@nokia.com, nsis@ietf.org Message-ID: <29712564.1058984867@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt - Comments 1 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit See comments inline. --On Donnerstag, 26. Juni 2003 21:31 -0700 Allison Mankin wrote: > The IESG reviewed the NSIS Requirements. There was some concern over > the readability. In addition, there were a few technical comments that > should be addressed. Here are Harald Alvestrand's. > > Allison > > ------- Forwarded Message > > > Date: Thu, 26 Jun 2003 08:35:22 -0700 > From: Harald Tveit Alvestrand > To: iesg@ietf.org > Subject: A couple of comments on draft-ietf-nsis-req > > > This section, from the start of section 5, worries me: > > > The parts of the networks we differentiate are the host-to-first > router, the access network, and the core network. The host to first > router part includes all the layer 2 technologies to access to the > Internet. This part of the division is especially informal and may > incorporate several access segments. In many cases, there is an > application and/or user running on the host initiating signaling. > The access network can be characterized by low capacity links, > medium speed IP processing capabilities, and it might consist of a > complete layer 2 network as well. The core network characteristics > include high-speed forwarding capacities and inter-domain issues. > These divisions between network types are not strict and do not > appear in all networks, but where they do exist they may influence > signaling requirements and will be highlighted as necessary. > > First of all, the grammar is sufficiently convoluted that I have problems > parsing it. > > Second, I have definitional problems. > > I have problems imagining how an access network can work if it does NOT > contain a "complete layer 2 network" - after all, a link is, in its way, > a layer 2 network. OTOH, I don't think GSM/GPRS can fairly be called a > "layer 2 network" - it's more complex than that - but it's definitely > being used as an access network. > > The sentence "host to first router part includes all the layer 2 > technologies to access to the Internet" does not parse, and makes the > definition only make sense when the first router is connected to the > Internet - I don't think that was intended. > > Since this paragraph is key to the overall architectural constraints, I > think it's rather important to make it crystal clear. > Actually, I don't think the paragraph is that much a key to the whole architecture. However in the consensus finding phase it help to make a number of people happy. It has been heavily discussed during the lifetime of the draft, therefore it went grammatically wrong. At this point in time, I think that the whole paragraph can be removed. Anybody objecting to this? > Section 5.5.1 on scalability worries me a lot, because it uses "scalable" > without referring to a scale; while it may be appropriate to "scale" an > end-system-to-first-router protocol to 10.000 users and say "good > enough", I think core routers have scalability requirements to millions > of active participants (which argues for them not having to see their > state....) > > I would like to see some hand-wringing here like: > > "The NSIS protocols MUST be scalable up to the level of ubiquity - that > is, if every end-user on the network uses NSIS functions, the system > MUST NOT be brought to a catastrophic failure, but continue to give > service appropriate to the resources available." > > There might be more than this, but this is at least worrying..... I understand the worry, but your proposal does at least for me not say something different that what is stated in the draft. Some people regarded the requirement as motherhood and apple pie anyway. Actually, what I think you are referring to is the robustness of the system, where as salability is concerned more with the performance of it. Somebody from the WG has an idea how to resolve that? Marcus -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 23 12:43:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19266 for ; Wed, 23 Jul 2003 12:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMhh-0002hH-Bw for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 12:43:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NGh1rl010362 for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 12:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMhg-0002gc-Vi; Wed, 23 Jul 2003 12:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMgy-0002g7-PN for nsis@optimus.ietf.org; Wed, 23 Jul 2003 12:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19227 for ; Wed, 23 Jul 2003 12:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fMgx-00063K-00 for nsis@ietf.org; Wed, 23 Jul 2003 12:42:15 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19fMgm-00063A-00 for nsis@ietf.org; Wed, 23 Jul 2003 12:42:04 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6NGfSVI014534; Wed, 23 Jul 2003 18:41:28 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D169BB6DEF; Wed, 23 Jul 2003 18:21:33 +0200 (CEST) Date: Wed, 23 Jul 2003 18:41:28 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: Allison Mankin , smb@research.att.com Cc: john.loughney@nokia.com, nsis@ietf.org Message-ID: <30533605.1058985688@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] Re: More IESG Review of draft-ietf-nsis-req-08.txt - Comments 2 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Donnerstag, 26. Juni 2003 21:41 -0700 Allison Mankin wrote: > > Steve Bellovin also had comments on the NSIS Requirements draft: > > Section 3 effectively rules out any requirement for security within a > domain. I don't think that's right. > That's definitely not right. I assume you refer to point 5 of section 3: 5. We can see the network at the level of domains/subdomains rather than individual routers (except in the special case that the domain contains one link). Domains are assumed to be administrative entities, so security requirements apply to the signaling between them. How about the following 5. We can see the network at the level of domains/subdomains rather than individual routers (except in the special case that the domain contains one link). Domains are assumed to be administrative entities. So security requirements might apply differently for the signaling between them and within them. > In 5.7.8, confidentiality SHOULD be supported. The ability to listen > to signaling channels is a major guide to what data channels are > interesting. Is ok for me. The requirement changes then from OLD: 5.7.8 Confidentiality of signaling messages Based on the signaling information exchanged between nodes participating in the signaling protocol an adversary may learn both the identities and the content of the signaling messages. To prevent this from happening, confidentiality of the signaling message in a hop-by-hop manner MAY be provided. Note that the protection can be provided on a hop-by-hop basis for most message payloads since it is required that entities which actively participating in the signaling protocol must be able to read and eventually modify the content of the signaling messages. to NEW: 5.7.8 Confidentiality of signaling messages Based on the signaling information exchanged between nodes participating in the signaling protocol an adversary may learn both the identities and the content of the signaling messages. Since the ability to listen to signaling channels is a major guide to what data channels are interesting ones. To prevent this from happening, confidentiality of the signaling message in a hop-by-hop manner SHOULD be provided. Note that the protection can be provided on a hop-by-hop basis for most message payloads since it is required that entities which actively participating in the signaling protocol must be able to read and eventually modify the content of the signaling messages. Objections? Marcus > > > > > > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 23 13:28:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20432 for ; Wed, 23 Jul 2003 13:28:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNPF-0004WI-Tf for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 13:28:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NHS1Zt017373 for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 13:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNPF-0004Vb-51; Wed, 23 Jul 2003 13:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNOP-0004UL-Ho for nsis@optimus.ietf.org; Wed, 23 Jul 2003 13:27:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20396 for ; Wed, 23 Jul 2003 13:27:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNOM-0006IF-00 for nsis@ietf.org; Wed, 23 Jul 2003 13:27:06 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19fNO6-0006Hi-00 for nsis@ietf.org; Wed, 23 Jul 2003 13:26:50 -0400 Received: from cs.columbia.edu (dhcp22.cs.columbia.edu [128.59.19.222]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6NHP7ue013592; Wed, 23 Jul 2003 13:25:07 -0400 (EDT) Message-ID: <3F1EC4F3.8090009@cs.columbia.edu> Date: Wed, 23 Jul 2003 13:25:07 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Attila_B=E1der_=28ET/ETH=29=22?= CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by opus.cs.columbia.edu id h6NHP7ue013592 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At least from our implementation experience with a vaguely related=20 protocol, the additional complexity of such choice is very modest (a few=20 tens of lines of code and an additional table). As I've said in an earlier message, I'd like to challenge advocates of=20 only offering only end-to-end reliability to address even the simple=20 issue of what RTT estimate to pick if nodes perform anything but trivial=20 forwarding. NSIS nodes are not just dumb packet routers with microsecond=20 latency... Attila B=E1der (ET/ETH) wrote: > Hi Robert and All, >=20 > I also think the question is very fundamental. Since NSIS addresses wid= er range of applications, most probably there will be NSLPs which like to= use retransmission-like reliability, while other concepts intend to supp= ort reliability like RSVP does. Certainly both have advantages and disadv= antages and it depends on the applications. >=20 > In my view this latter is closer to the original concept of soft states= and using RSVP as a base. Our stateless concept for example needs the si= mplest transport as possible and it may be reasonable for other NSLPs as = well. I am afraid that if retransmission is a common service of NTLP, eve= n if it is optional to use, it introduces unnecessary implementation comp= lexity. >=20 > The question can be put in another way as well: Should NTLP have option= al features that can be invoked by different NSLPs, or NTLP should be a p= rotocol supporting common basic features and optional feature are only in= NSLP? I do not remember if we had a consensus regarding this question. >=20 > Best regards, Attila _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 23 17:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03791 for ; Wed, 23 Jul 2003 17:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRFK-0008DT-CL for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 17:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NLY2U8031579 for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 17:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRFJ-0008D6-MZ; Wed, 23 Jul 2003 17:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fREe-000884-LZ for nsis@optimus.ietf.org; Wed, 23 Jul 2003 17:33:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03740 for ; Wed, 23 Jul 2003 17:33:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fREc-00011f-00 for nsis@ietf.org; Wed, 23 Jul 2003 17:33:18 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19fRER-00010w-00 for nsis@ietf.org; Wed, 23 Jul 2003 17:33:07 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 22:32:00 +0100 Message-ID: From: "Hancock, Robert" To: "'Henning Schulzrinne '" , =?iso-8859-1?Q?=27=22?= =?iso-8859-1?Q?Attila_B=E1der_=28ET/ETH=29=22_=27?= Cc: "Hancock, Robert" , "'nsis@ietf.org '" Subject: RE: [NSIS] Reliable Transport for NTLP Date: Wed, 23 Jul 2003 22:31:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Henning, As usual, there is more than one question here. I'm also not a fan of relying on only 'end-to-end' (in the sense of first-NSIS-node-to-last-NSIS-node) reliability. However, even if we agree that a signalling application needing reliability needs it between (say) adjacent NSLP peers rather than simply end-to-end, there is still the=20 question of which layer it should be provided at (NTLP or within each application). I argued in my email to Scott that there were good reasons why this functionality should be part of the=20 NTLP. I'd be interested in views on whether those arguments were valid (or what other arguments were=20 valid). I think the practical consequence would be that some form of reliable message transport (*) would be mandatory functionality in the NTLP, optional for an NSLP to invoke on a message-by-message basis. cheers, r. (*) coupled ideally with some form of express routing to bypass intermediate nodes between the NSLP peers. -----Original Message----- From: Henning Schulzrinne To: "Attila B=E1der (ET/ETH)" Cc: Hancock, Robert; nsis@ietf.org Sent: 23/07/2003 18:25 Subject: Re: [NSIS] Reliable Transport for NTLP At least from our implementation experience with a vaguely related=20 protocol, the additional complexity of such choice is very modest (a = few tens of lines of code and an additional table). As I've said in an earlier message, I'd like to challenge advocates of=20 only offering only end-to-end reliability to address even the simple=20 issue of what RTT estimate to pick if nodes perform anything but = trivial forwarding. NSIS nodes are not just dumb packet routers with = microsecond latency... Attila B=E1der (ET/ETH) wrote: > Hi Robert and All, >=20 > I also think the question is very fundamental. Since NSIS addresses wider range of applications, most probably there will be NSLPs which like to use retransmission-like reliability, while other concepts = intend to support reliability like RSVP does. Certainly both have advantages and disadvantages and it depends on the applications. >=20 > In my view this latter is closer to the original concept of soft states and using RSVP as a base. Our stateless concept for example = needs the simplest transport as possible and it may be reasonable for other NSLPs as well. I am afraid that if retransmission is a common service = of NTLP, even if it is optional to use, it introduces unnecessary implementation complexity. >=20 > The question can be put in another way as well: Should NTLP have optional features that can be invoked by different NSLPs, or NTLP = should be a protocol supporting common basic features and optional feature are only in NSLP? I do not remember if we had a consensus regarding this question. >=20 > Best regards, Attila _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 24 05:10:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29961 for ; Thu, 24 Jul 2003 05:10:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fc6s-0006cd-3m for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 05:10:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O9A2Hd025454 for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 05:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fc6r-0006cP-N7; Thu, 24 Jul 2003 05:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fc5y-0006Zu-08 for nsis@optimus.ietf.org; Thu, 24 Jul 2003 05:09:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29949 for ; Thu, 24 Jul 2003 05:09:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fc5u-0004ah-00 for nsis@ietf.org; Thu, 24 Jul 2003 05:09:02 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19fc5k-0004aZ-00 for nsis@ietf.org; Thu, 24 Jul 2003 05:08:52 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6O98OG6009380; Thu, 24 Jul 2003 11:08:24 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <366DS7G6>; Thu, 24 Jul 2003 11:09:03 +0200 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28ET/ETH=29?= To: "Hancock, Robert" , "'Henning Schulzrinne '" , "Geib, Ruediger" Cc: "'nsis@ietf.org '" Subject: RE: [NSIS] Reliable Transport for NTLP Date: Thu, 24 Jul 2003 11:07:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi All, My view is related to our stateless (or reduced states) concept in = which we do not distinguish individual flows in interior nodes. We rely = on reserve, refresh, tear messages, which add or remove resources in = reasonable timing. Hop-by-hop retransmission or = fragmentation/reassembling in the domain affect negatively the = performance of this kind of NSLP. What our NSLP provides is actually = edge-to-edge reliability.=20 On the other hand, I think, if pear-to-pear reliability is desirable = for other applications it is reasonable to be part of NTLP as an = option.=20 Regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Hancock, Robert > Sent: Wednesday, July 23, 2003 11:32 PM > To: 'Henning Schulzrinne '; ' Attila B=E1der (ET/ETH) ' > Cc: Hancock, Robert; 'nsis@ietf.org ' > Subject: RE: [NSIS] Reliable Transport for NTLP >=20 >=20 > Hi Henning, >=20 > As usual, there is more than one question here. >=20 > I'm also not a fan of relying on only 'end-to-end' > (in the sense of first-NSIS-node-to-last-NSIS-node) > reliability. >=20 > However, even if we agree that a signalling application > needing reliability needs it between (say) adjacent NSLP > peers rather than simply end-to-end, there is still the=20 > question of which layer it should be provided at (NTLP > or within each application). >=20 > I argued in my email to Scott that there were good > reasons why this functionality should be part of the=20 > NTLP. I'd be interested in views on whether those > arguments were valid (or what other arguments were=20 > valid). I think the practical consequence would be that > some form of reliable message transport (*) would be > mandatory functionality in the NTLP, optional for an > NSLP to invoke on a message-by-message basis. >=20 > cheers, >=20 > r. >=20 > (*) coupled ideally with some form of express routing > to bypass intermediate nodes between the NSLP peers. >=20 > -----Original Message----- > From: Henning Schulzrinne > To: "Attila B=E1der (ET/ETH)" > Cc: Hancock, Robert; nsis@ietf.org > Sent: 23/07/2003 18:25 > Subject: Re: [NSIS] Reliable Transport for NTLP >=20 > At least from our implementation experience with a vaguely related=20 > protocol, the additional complexity of such choice is very=20 > modest (a few >=20 > tens of lines of code and an additional table). >=20 > As I've said in an earlier message, I'd like to challenge=20 > advocates of=20 > only offering only end-to-end reliability to address even the simple=20 > issue of what RTT estimate to pick if nodes perform anything=20 > but trivial >=20 > forwarding. NSIS nodes are not just dumb packet routers with=20 > microsecond >=20 > latency... >=20 >=20 > Attila B=E1der (ET/ETH) wrote: >=20 > > Hi Robert and All, > >=20 > > I also think the question is very fundamental. Since NSIS addresses > wider range of applications, most probably there will be NSLPs which > like to use retransmission-like reliability, while other=20 > concepts intend > to support reliability like RSVP does. Certainly both have advantages > and disadvantages and it depends on the applications. > >=20 > > In my view this latter is closer to the original concept of soft > states and using RSVP as a base. Our stateless concept for=20 > example needs > the simplest transport as possible and it may be reasonable for other > NSLPs as well. I am afraid that if retransmission is a common=20 > service of > NTLP, even if it is optional to use, it introduces unnecessary > implementation complexity. > >=20 > > The question can be put in another way as well: Should NTLP have > optional features that can be invoked by different NSLPs, or=20 > NTLP should > be a protocol supporting common basic features and optional=20 > feature are > only in NSLP? I do not remember if we had a consensus regarding this > question. > >=20 > > Best regards, Attila >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 24 05:35:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00426 for ; Thu, 24 Jul 2003 05:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcV4-0007pa-As for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 05:35:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O9Z26d030085 for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 05:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcV3-0007p8-VQ; Thu, 24 Jul 2003 05:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcUO-0007nz-Nr for nsis@optimus.ietf.org; Thu, 24 Jul 2003 05:34:20 -0400 Received: from infres.enst.fr (infres.enst.fr [137.194.192.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00402 for ; Thu, 24 Jul 2003 05:34:14 -0400 (EDT) Received: from luu (dhcp7-211.enst.fr [137.194.7.211]) by infres.enst.fr (Postfix) with SMTP id 6B11E18F3; Thu, 24 Jul 2003 11:33:04 +0200 (MEST) Message-ID: <001001c351c6$560ef0a0$d307c289@enst.fr> From: "Thanh Tra LUU" To: =?iso-8859-1?Q?Attila_B=E1der_=28ET/ETH=29?= Cc: References: Subject: Re: [NSIS] Reliable Transport for NTLP Date: Thu, 24 Jul 2003 11:31:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA00403 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi Attila, I am a fan of E2E reliable delivery but I don't agree with your idea. If TCP is used, reliable delivery is always used even though your signaling application needs it or not. It belongs to lower layer and there is no relationship between stateless attribute and lower layer here. I feel that TCP is something too 'solid' and not flexible. If TCP is used, signaling application must bear all the security attacks of this protocol (e.g. SYN TCP attack). It will be easier for attack a signaling aware node because a packet can be sent from a distant host to a signaling node on the data path without Router Alert Option being set. I'll try to find some more arguments for using IP or UDP as a lower layer of NTLP. Nary Tra, ENST, Paris ----- Original Message ----- From: "Attila B=E1der (ET/ETH)" To: "Hancock, Robert" ; "'Henning Schulzrinne '" ; "Geib, Ruediger" Cc: Sent: Thursday, July 24, 2003 11:07 AM Subject: RE: [NSIS] Reliable Transport for NTLP Hi All, My view is related to our stateless (or reduced states) concept in which we do not distinguish individual flows in interior nodes. We rely on reserve, refresh, tear messages, which add or remove resources in reasonable timing. Hop-by-hop retransmission or fragmentation/reassembling in the domain affect negatively the performance of this kind of NSLP. What our NSLP provides is actually edge-to-edge reliability. On the other hand, I think, if pear-to-pear reliability is desirable for other applications it is reasonable to be part of NTLP as an option. Regards, Attila _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 24 09:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06162 for ; Thu, 24 Jul 2003 09:46:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgQ0-0005He-Va for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 09:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ODk46p020293 for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 09:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgPw-0005GO-Ip; Thu, 24 Jul 2003 09:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgPD-0005Ez-N2 for nsis@optimus.ietf.org; Thu, 24 Jul 2003 09:45:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06103 for ; Thu, 24 Jul 2003 09:45:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgPB-00068W-00 for nsis@ietf.org; Thu, 24 Jul 2003 09:45:13 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19fgOw-00068R-00 for nsis@ietf.org; Thu, 24 Jul 2003 09:44:58 -0400 Received: from cs.columbia.edu (dhcp22.cs.columbia.edu [128.59.19.222]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6ODiDue000627; Thu, 24 Jul 2003 09:44:13 -0400 (EDT) Message-ID: <3F1FE2AD.7070400@cs.columbia.edu> Date: Thu, 24 Jul 2003 09:44:13 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanh Tra LUU CC: =?ISO-8859-1?Q?=22Attila_B=E1der_=28ET/ETH=29=22?= , nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP References: <001001c351c6$560ef0a0$d307c289@enst.fr> In-Reply-To: <001001c351c6$560ef0a0$d307c289@enst.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Nary Tra, in order to make progress in this WG, we have to keep from repeating the same non-disagreements again and again. Nobody here, as far as I can tell, is suggesting that TCP be mandatory to support or use for a particular NSLP, only that it (or similar protocols, such as SCTP or DCCP) are appropriate parts of the tool kit. You may also find it interesting to read some of the proposals that indicate how router alert options are being used. The two issues are orthogonal. Maybe we need a FUD FAQ :-) Henning Thanh Tra LUU wrote: > hi Attila, > > I am a fan of E2E reliable delivery but I don't agree with your idea. > If TCP is used, reliable delivery is always used even though your > signaling application needs it or not. It belongs to lower layer and > there is no relationship between stateless attribute and lower layer > here. > > I feel that TCP is something too 'solid' and not flexible. If TCP is > used, signaling application must bear all the security attacks of this > protocol (e.g. SYN TCP attack). It will be easier for attack a > signaling aware node because a packet can be sent from a distant host > to a signaling node on the data path without Router Alert Option being > set. > > I'll try to find some more arguments for using IP or UDP as a lower > layer of NTLP. > > Nary Tra, > ENST, Paris > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 24 11:18:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10792 for ; Thu, 24 Jul 2003 11:18:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fhqz-0003vC-Fp for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 11:18:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OFI1oj015070 for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 11:18:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fhqz-0003ux-8U; Thu, 24 Jul 2003 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fhqM-0003rg-Al for nsis@optimus.ietf.org; Thu, 24 Jul 2003 11:17:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10752 for ; Thu, 24 Jul 2003 11:17:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fhqL-0006rB-00 for nsis@ietf.org; Thu, 24 Jul 2003 11:17:21 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19fhqA-0006qm-00 for nsis@ietf.org; Thu, 24 Jul 2003 11:17:10 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 16:16:06 +0100 Message-ID: From: "Hancock, Robert" To: "'Marcus Brunner'" , mankin@psg.com, harald@alvestrand.no Cc: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt - Commen ts 1 Date: Thu, 24 Jul 2003 16:16:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, These aren't easy. My view is that the two 'parts of the network' paragraphs (the one Harald quotes and the one before it) could be safely removed. The general point about being able to adapt to deployment conditions is made at the very start of section 5; the rest of the document uses the terms 'access' and 'core' in an informal (and probably self-explanatory) way, and I don't see a need for a stricter definition. (Indeed, IIRC Marcus made this point of deliberate vagueness very explicit when this 'parts of the network' issue came up in the Minneapolis WG meeting.) (We could add a comment in the middle of the 2nd paragraph of section 5 that: We use the terms 'access' and 'core' informally in the discussion of some particular requirements to refer to deployment conditions where particular protocol attributes, especially performance characteristics, have special importance. Or something like that.) ================================================== How to handle the scaling concern seems much harder. Part of the problem is that the signalling protocols have to be capable of per- microflow operation, and if network managers insist on trying to [ab]use them that way in the network core, there isn't much we can do about it. In general, achieving most of what Harald refers to is a matter of using a scalable resource management architecture, and scalable protocol behaviour will largely follow from that. But the resource management problem is out of scope for us anyway. In other words, the requirement he suggests cannot be satisfied by NSIS, but only by NSIS protocols supporting appropriate operational mechanisms (which we don't know all of in the first place, in fact). I can suggest 2 things: a) Add some text to 5.5.1 to say something like 'In order to be useful even in an environment where the use of signalling by hosts becomes universal, NSIS protocols must allow for use at a level above that of individual end-to-end flows (ref. 5.2.4 and 5.6.1).' b) Reinforce a little bit 5.5.4 to say that performance should degrade gracefully rather than catastrophically under overload conditions. (Which is actually something we are worrying about at the moment anyway.) Maybe these are over-specific or over-detailed. cheers, robert h. > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Wednesday, July 23, 2003 17:28 > To: mankin@psg.com; harald@alvestrand.no > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: [NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt > - Comments > 1 > > > See comments inline. > > --On Donnerstag, 26. Juni 2003 21:31 -0700 Allison Mankin > > wrote: > > > The IESG reviewed the NSIS Requirements. There was some > concern over > > the readability. In addition, there were a few technical > comments that > > should be addressed. Here are Harald Alvestrand's. > > > > Allison > > > > ------- Forwarded Message > > > > > > Date: Thu, 26 Jun 2003 08:35:22 -0700 > > From: Harald Tveit Alvestrand > > To: iesg@ietf.org > > Subject: A couple of comments on draft-ietf-nsis-req > > > > > > This section, from the start of section 5, worries me: > > > > > > The parts of the networks we differentiate are the host-to-first > > router, the access network, and the core network. The > host to first > > router part includes all the layer 2 technologies to > access to the > > Internet. This part of the division is especially > informal and may > > incorporate several access segments. In many cases, there is an > > application and/or user running on the host initiating signaling. > > The access network can be characterized by low capacity links, > > medium speed IP processing capabilities, and it might > consist of a > > complete layer 2 network as well. The core network > characteristics > > include high-speed forwarding capacities and inter-domain issues. > > These divisions between network types are not strict and do not > > appear in all networks, but where they do exist they may > influence > > signaling requirements and will be highlighted as necessary. > > > > First of all, the grammar is sufficiently convoluted that I > have problems > > parsing it. > > > > Second, I have definitional problems. > > > > I have problems imagining how an access network can work if > it does NOT > > contain a "complete layer 2 network" - after all, a link > is, in its way, > > a layer 2 network. OTOH, I don't think GSM/GPRS can fairly > be called a > > "layer 2 network" - it's more complex than that - but it's > definitely > > being used as an access network. > > > > The sentence "host to first router part includes all the layer 2 > > technologies to access to the Internet" does not parse, and > makes the > > definition only make sense when the first router is connected to the > > Internet - I don't think that was intended. > > > > Since this paragraph is key to the overall architectural > constraints, I > > think it's rather important to make it crystal clear. > > > > Actually, I don't think the paragraph is that much a key to the whole > architecture. However in the consensus finding phase it help > to make a > number of people happy. It has been heavily discussed during > the lifetime > of the draft, therefore it went grammatically wrong. At this > point in time, > I think that the whole paragraph can be removed. > > Anybody objecting to this? > > > > Section 5.5.1 on scalability worries me a lot, because it > uses "scalable" > > without referring to a scale; while it may be appropriate > to "scale" an > > end-system-to-first-router protocol to 10.000 users and say "good > > enough", I think core routers have scalability > requirements to millions > > of active participants (which argues for them not having > to see their > > state....) > > > > I would like to see some hand-wringing here like: > > > > "The NSIS protocols MUST be scalable up to the level of > ubiquity - that > > is, if every end-user on the network uses NSIS functions, > the system > > MUST NOT be brought to a catastrophic failure, but continue to give > > service appropriate to the resources available." > > > > There might be more than this, but this is at least worrying..... > > I understand the worry, but your proposal does at least for > me not say > something different that what is stated in the draft. Some > people regarded > the requirement as motherhood and apple pie anyway. > > Actually, what I think you are referring to is the robustness of the > system, where as salability is concerned more with the > performance of it. > > Somebody from the WG has an idea how to resolve that? > > Marcus > > -------------------------------------- > Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 24 14:27:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20084 for ; Thu, 24 Jul 2003 14:27:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkny-0004uz-UY for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 14:27:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OIR6dL018900 for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 14:27:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fknt-0004uj-NF; Thu, 24 Jul 2003 14:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fknL-0004uI-3u for nsis@optimus.ietf.org; Thu, 24 Jul 2003 14:26:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19985 for ; Thu, 24 Jul 2003 14:26:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fknI-0000iO-00 for nsis@ietf.org; Thu, 24 Jul 2003 14:26:24 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19fkn5-0000iH-00 for nsis@ietf.org; Thu, 24 Jul 2003 14:26:11 -0400 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Thu, 24 Jul 2003 20:25:48 +0200 Message-ID: <3F202487.2060800@cs.uni-goettingen.de> Date: Thu, 24 Jul 2003 20:25:11 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: Marcus Brunner , Paulo Mendes , "Charles Q. Shen" , john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Hancock, Robert wrote: > > The framework layer split concept is that the NTLP works in terms > of packet streams ("flows") which are identifiable by nodes inside > the network. This is reflected practically in the fact that the > NTLP universe revolves around "flow-ids" (3/5 tuple etc. - see other > emails). The NTLP knows how to route (and re-route) signalling > messages along the path corresponding to a flow ID, but it > doesn't know anything about any relationships between different > flows (i.e. with different flow IDs). Local repair/re-routing + host addressing (routing header and Home Address option) might be insufficient. Consider an example: an MN just moves from an foreign network to another, than non-route-optimized MIP may change a binding entry in the HA at the (mobile) IP level, and the common path (before and after a handoff) ends somewhere between the HA and MN. In this case, the NTLP instances in routers locating between the HA and the Crossover Router (CR) will be unable to route the NSIS signaling message according to universal flow-ids, without introducing new NTLP functionalities/objects. IMO mobility is more than an NSLP issue; it also involves with NTLP. One possible way is to distinguish NTLP instances by session ID, but let NSIS messages routed according to some object in NTLP independent of flow-id and allow NTLP instances be aware of mobility-caused route changes also in the middle of the network (not only route changes for hosts). Of course, NSLP needs certain neat work to reflect a signaled flow' traffic selector. Cheers, Xiaoming > > An IP-visible mobility event (MIP/SIP/HIP/...) results intrinsically > in a new flow ID and also an update of the packet classifiers and > so on. The NTLP doesn't know how the new flow relates to the old; > NSIS-aware nodes which see both flows handle the interactions > between them at the signalling application level (i.e. in the NSLP). > Essentially, the same reasoning applies to the multihoming case, i.e. > it's an NSLP issue. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 24 21:44:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08279 for ; Thu, 24 Jul 2003 21:44:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frcp-0001rw-1h for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 21:44:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1i3tg007180 for nsis-archive@odin.ietf.org; Thu, 24 Jul 2003 21:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frcn-0001rh-Qd; Thu, 24 Jul 2003 21:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frci-0001rO-3e for nsis@optimus.ietf.org; Thu, 24 Jul 2003 21:43:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08273 for ; Thu, 24 Jul 2003 21:43:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frcd-0003nX-00 for nsis@ietf.org; Thu, 24 Jul 2003 21:43:51 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19frcT-0003n8-00 for nsis@ietf.org; Thu, 24 Jul 2003 21:43:41 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6P1gW4O001600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jul 2003 21:42:36 -0400 (EDT) From: "Charles Q. Shen" To: "'Xiaoming Fu'" , "'Hancock, Robert'" Cc: "'Marcus Brunner'" , "'Paulo Mendes'" , , Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Date: Thu, 24 Jul 2003 21:42:27 -0400 Organization: Columbia University Message-ID: <000101c3524e$0506e310$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: <3F202487.2060800@cs.uni-goettingen.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, We have had a long debate on whether reliable transport (if applicable) should reside in NSLP or NTLP. It seems here comes another topic: should mobility-awareness be built in NSLP only or also in NTLP? I noticed that Robert and John have explicited said it should be an NSLP issue only. This sparks my curiousity to ask: "Is it already a WG consensus or is it true that many people still haven't got time to think about it?" IMHO it would be good to make it an NSLP issue only, if possible. However, I would like to see more proof as details being worked out. (Although it might still be arguable how detail about NSIS-mobility we should get into at this time). Xiaoming, frankly I do not completely understand your example yet. Does Robert mean that the flow-id (which very likely contains IP addresses) will change after the handoff (and the presumed session ID will be retained)? Thanks and regards, Charles > > Hancock, Robert wrote: > > > > The framework layer split concept is that the NTLP works in > terms of > > packet streams ("flows") which are identifiable by nodes inside the > > network. This is reflected practically in the fact that the NTLP > > universe revolves around "flow-ids" (3/5 tuple etc. - see other > > emails). The NTLP knows how to route (and re-route) signalling > > messages along the path corresponding to a flow ID, but it doesn't > > know anything about any relationships between different flows (i.e. > > with different flow IDs). > > Local repair/re-routing + host addressing (routing header and Home > Address option) might be insufficient. Consider an example: > an MN just > moves from an foreign network to another, than > non-route-optimized MIP > may change a binding entry in the HA at the (mobile) IP > level, and the > common path (before and after a handoff) ends somewhere > between the HA > and MN. In this case, the NTLP instances in routers locating > between the > HA and the Crossover Router (CR) will be unable to route the NSIS > signaling message according to universal flow-ids, without > introducing > new NTLP functionalities/objects. > > IMO mobility is more than an NSLP issue; it also involves > with NTLP. One > possible way is to distinguish NTLP instances by session ID, but let > NSIS messages routed according to some object in NTLP independent of > flow-id and allow NTLP instances be aware of mobility-caused route > changes also in the middle of the network (not only route changes for > hosts). Of course, NSLP needs certain neat work to reflect a signaled > flow' traffic selector. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 00:27:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11228 for ; Fri, 25 Jul 2003 00:27:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fu9c-0006Kd-0H for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 00:26:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P4Q3OM024333 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 00:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fu9Z-0006Jx-Tc; Fri, 25 Jul 2003 00:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnqo-0008Az-8d for nsis@optimus.ietf.org; Thu, 24 Jul 2003 17:42:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02225 for ; Thu, 24 Jul 2003 17:42:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnql-0002a1-00 for nsis@ietf.org; Thu, 24 Jul 2003 17:42:11 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 19fnqa-0002Zd-00 for nsis@ietf.org; Thu, 24 Jul 2003 17:42:00 -0400 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 288C461BAD; Thu, 24 Jul 2003 23:41:10 +0200 (CEST) Date: Thu, 24 Jul 2003 08:00:44 -0700 From: Harald Tveit Alvestrand To: Marcus Brunner , mankin@psg.com Cc: john.loughney@nokia.com, nsis@ietf.org Message-ID: <494154156.1059033644@localhost> In-Reply-To: <29712564.1058984867@[10.1.1.130]> References: <29712564.1058984867@[10.1.1.130]> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt - Comments 1 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Marcus, thanks for the follow-up! --On 23. juli 2003 18:27 +0200 Marcus Brunner wrote: >> >> This section, from the start of section 5, worries me: >> >> >> The parts of the networks we differentiate are the host-to-first >> router, the access network, and the core network. The host to first >> router part includes all the layer 2 technologies to access to the >> Internet. This part of the division is especially informal and may >> incorporate several access segments. In many cases, there is an >> application and/or user running on the host initiating signaling. >> The access network can be characterized by low capacity links, >> medium speed IP processing capabilities, and it might consist of a >> complete layer 2 network as well. The core network characteristics >> include high-speed forwarding capacities and inter-domain issues. >> These divisions between network types are not strict and do not >> appear in all networks, but where they do exist they may influence >> signaling requirements and will be highlighted as necessary. >> >> First of all, the grammar is sufficiently convoluted that I have problems >> parsing it. >> >> Second, I have definitional problems. >> >> I have problems imagining how an access network can work if it does NOT >> contain a "complete layer 2 network" - after all, a link is, in its way, >> a layer 2 network. OTOH, I don't think GSM/GPRS can fairly be called a >> "layer 2 network" - it's more complex than that - but it's definitely >> being used as an access network. >> >> The sentence "host to first router part includes all the layer 2 >> technologies to access to the Internet" does not parse, and makes the >> definition only make sense when the first router is connected to the >> Internet - I don't think that was intended. >> >> Since this paragraph is key to the overall architectural constraints, I >> think it's rather important to make it crystal clear. >> > > Actually, I don't think the paragraph is that much a key to the whole > architecture. However in the consensus finding phase it help to make a > number of people happy. It has been heavily discussed during the lifetime > of the draft, therefore it went grammatically wrong. At this point in > time, I think that the whole paragraph can be removed. > > Anybody objecting to this? Do you use the distinction between "host to first router", "access network" and "core network" elsewhere in the document? I could find "access network" and "core network", but not "host to first router". Defining those terms is important, since different people get upset based on where you place the boundary. OTOH, "host to first router" is relatively easy to figure out..... >> Section 5.5.1 on scalability worries me a lot, because it uses "scalable" >> without referring to a scale; while it may be appropriate to "scale" an >> end-system-to-first-router protocol to 10.000 users and say "good >> enough", I think core routers have scalability requirements to millions >> of active participants (which argues for them not having to see their >> state....) >> >> I would like to see some hand-wringing here like: >> >> "The NSIS protocols MUST be scalable up to the level of ubiquity - that >> is, if every end-user on the network uses NSIS functions, the system >> MUST NOT be brought to a catastrophic failure, but continue to give >> service appropriate to the resources available." >> >> There might be more than this, but this is at least worrying..... > > I understand the worry, but your proposal does at least for me not say > something different that what is stated in the draft. Some people > regarded the requirement as motherhood and apple pie anyway. It's been one of the major hassles of RSVP deployment (from my far-away ivory tower, at least) that it never got around to actually discussing numbers when talking about scaling; the technology works fine (I think) in an enterprise context where the number of users has 4 or 5 digits, and the provisioning of the network is under centralized control; the hassles we have had involve trying to imagine the operation, economics and politics of deploying something at "Internet scale". Given that we've already got a lot of history here about discussion of scale, I think being explicit is good. > > Actually, what I think you are referring to is the robustness of the > system, where as salability is concerned more with the performance of it. To my mind, scalability has two aspects: - How far can you go? - What happens when you hit the edge? There was one IOS version (beta code, I think) many years ago that, when you started listening to multicast groups, fell over when you hit the limit of resources available for multicast state. That's the worst kind of not scaling. And the fear that there might be more bugs like this has been a major worry of people thinking about deploying multicast, and other protocols where they lumped issues under the "scaling" label. Again - it's history that drives my worries..... > > Somebody from the WG has an idea how to resolve that? Thanks for the feedback, and hope this is useful! Harald _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 03:38:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27427 for ; Fri, 25 Jul 2003 03:38:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx9O-0006d3-Bs for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 03:38:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P7c2LA025468 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 03:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx9N-0006cc-L4; Fri, 25 Jul 2003 03:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx8x-0006V3-3B for nsis@optimus.ietf.org; Fri, 25 Jul 2003 03:37:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27279 for ; Fri, 25 Jul 2003 03:37:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fx73-000663-00 for nsis@ietf.org; Fri, 25 Jul 2003 03:35:38 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 19fx6t-000659-00 for nsis@ietf.org; Fri, 25 Jul 2003 03:35:27 -0400 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 25 Jul 2003 09:33:34 +0200 Received: from docomolab-euro.com ([192.168.0.138]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 25 Jul 2003 09:33:34 +0200 Message-ID: <3F20DD90.6010205@docomolab-euro.com> Date: Fri, 25 Jul 2003 09:34:40 +0200 From: Paulo Mendes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xiaoming Fu CC: "Hancock, Robert" , Marcus Brunner , "Charles Q. Shen" , john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: <3F202487.2060800@cs.uni-goettingen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2003 07:33:34.0626 (UTC) FILETIME=[0E086020:01C3527F] Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Xiaoming, Some comments below. Xiaoming Fu wrote: > Hi, > > Hancock, Robert wrote: > >> >> The framework layer split concept is that the NTLP works in terms >> of packet streams ("flows") which are identifiable by nodes inside >> the network. This is reflected practically in the fact that the >> NTLP universe revolves around "flow-ids" (3/5 tuple etc. - see other >> emails). The NTLP knows how to route (and re-route) signalling >> messages along the path corresponding to a flow ID, but it >> doesn't know anything about any relationships between different >> flows (i.e. with different flow IDs). > > > Local repair/re-routing + host addressing (routing header and Home > Address option) might be insufficient. Consider an example: an MN just > moves from an foreign network to another, than non-route-optimized MIP > may change a binding entry in the HA at the (mobile) IP level, and the > common path (before and after a handoff) ends somewhere between the HA > and MN. In this case, the NTLP instances in routers locating between > the HA and the Crossover Router (CR) will be unable to route the NSIS > signaling message according to universal flow-ids, without introducing > new NTLP functionalities/objects. What do you mean by "universal" flow-ids? > IMO mobility is more than an NSLP issue; it also involves with NTLP. > One possible way is to distinguish NTLP instances by session ID, but > let NSIS messages routed according to some object in NTLP independent > of flow-id and allow NTLP instances be aware of mobility-caused route > changes also in the middle of the network (not only route changes for > hosts). Of course, NSLP needs certain neat work to reflect a signaled > flow' traffic selector. It is clear to me that we need a session-ID in the case of mobility. But it is not clear to me what is the goal in "distinguishing" NTLP instances by session ID. If you mean the need to map the session-ID of a mobile session with the different flows-ID that the session can have before and after handover, I agree with you. However, I do not understand what you want to say with "NSIS messages routed according to some object in NTLP independent of flow-id". Are you suggesting that NSIS messages should be routed/transported based on something else than the flow-id? Cheers Paulo > > Cheers, > Xiaoming > >> >> An IP-visible mobility event (MIP/SIP/HIP/...) results intrinsically >> in a new flow ID and also an update of the packet classifiers and >> so on. The NTLP doesn't know how the new flow relates to the old; >> NSIS-aware nodes which see both flows handle the interactions >> between them at the signalling application level (i.e. in the NSLP). >> Essentially, the same reasoning applies to the multihoming case, i.e. >> it's an NSLP issue. > > > > > -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 03:58:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27877 for ; Fri, 25 Jul 2003 03:58:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxSk-0007bM-4E for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 03:58:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P7w2Xj029197 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 03:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxSj-0007ao-6B; Fri, 25 Jul 2003 03:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxSS-0007aR-U8 for nsis@optimus.ietf.org; Fri, 25 Jul 2003 03:57:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27865 for ; Fri, 25 Jul 2003 03:57:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxSQ-0006DN-00 for nsis@ietf.org; Fri, 25 Jul 2003 03:57:42 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19fxSF-0006Cy-00 for nsis@ietf.org; Fri, 25 Jul 2003 03:57:31 -0400 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 25 Jul 2003 09:57:02 +0200 Message-ID: <3F20E2B3.1060707@cs.uni-goettingen.de> Date: Fri, 25 Jul 2003 09:56:35 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paulo Mendes CC: nsis@ietf.org Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: <3F202487.2060800@cs.uni-goettingen.de> <3F20DD90.6010205@docomolab-euro.com> In-Reply-To: <3F20DD90.6010205@docomolab-euro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Paulo, Paulo Mendes wrote: > What do you mean by "universal" flow-ids? I was following what Robert used in his context. :) > >> IMO mobility is more than an NSLP issue; it also involves with NTLP. >> One possible way is to distinguish NTLP instances by session ID, but >> let NSIS messages routed according to some object in NTLP independent >> of flow-id and allow NTLP instances be aware of mobility-caused route >> changes also in the middle of the network (not only route changes for >> hosts). Of course, NSLP needs certain neat work to reflect a signaled >> flow' traffic selector. > > > It is clear to me that we need a session-ID in the case of mobility. But > it is not clear to me what is the goal in "distinguishing" NTLP > instances by session ID. If you mean the need to map the session-ID of a > mobile session with the different flows-ID that the session can have > before and after handover, I agree with you. However, I do not > understand what you want to say with "NSIS messages routed according to > some object in NTLP independent of flow-id". Are you suggesting that > NSIS messages should be routed/transported based on something else than > the flow-id? > This issue has been explored in various ways (e.g., in fw draft and maillist discussions). Session-ID can be useful, in my point of view, to distinguish from other sessions (note they may even have same NI/NR pair), and to determine the CR and avoid double reservations. My point was: even if one can have a universe flow-id, routing of NSIS messages is not as simple as expected. In the HA, for example, you can route NSIS messages towards the MN following the same rules as in MIP; for the nodes after HA, however, you have no knowledge of changes in MIP - how can you route them per flow-id? Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 04:07:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28103 for ; Fri, 25 Jul 2003 04:07:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxbW-0008ED-MU for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 04:07:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P876ul031600 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 04:07:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxbT-0008D3-Ft; Fri, 25 Jul 2003 04:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxb6-0008Bo-TD for nsis@optimus.ietf.org; Fri, 25 Jul 2003 04:06:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28079 for ; Fri, 25 Jul 2003 04:06:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxb4-0006I3-00 for nsis@ietf.org; Fri, 25 Jul 2003 04:06:38 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 19fxat-0006Hr-00 for nsis@ietf.org; Fri, 25 Jul 2003 04:06:27 -0400 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 25 Jul 2003 10:05:04 +0200 Received: from docomolab-euro.com ([192.168.0.138]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 25 Jul 2003 10:05:04 +0200 Message-ID: <3F20E4F2.9060003@docomolab-euro.com> Date: Fri, 25 Jul 2003 10:06:10 +0200 From: Paulo Mendes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles Q. Shen" CC: "'Xiaoming Fu'" , "'Hancock, Robert'" , "'Marcus Brunner'" , john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: <000101c3524e$0506e310$c7f027a0@president> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2003 08:05:04.0372 (UTC) FILETIME=[7468BB40:01C35283] Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Charles, Charles Q. Shen wrote: >Hi all, > >We have had a long debate on whether reliable transport (if applicable) >should reside in NSLP or NTLP. > Reliable transport in a session protocol, instead of a transport protocol?!! >It seems here comes another topic: should >mobility-awareness be built in NSLP only or also in NTLP? I noticed that >Robert and John have explicited said it should be an NSLP issue only. >This sparks my curiousity to ask: "Is it already a WG consensus or is it >true that many people still haven't got time to think about it?" > >IMHO it would be good to make it an NSLP issue only, if possible. >However, I would like to see more proof as details being worked out. >(Although it might still be arguable how detail about NSIS-mobility we >should get into at this time). > > I think that avoiding redundant functionalities is a good goal. Having this in mind, I think that only makes sense to include within NTLP functionalities that are common to different NSLPs. In the specific case of mobile session IDs, as said in the framework draft, it is desirable to update the flow:session mapping during the session lifetime. If this mapping is only needed to manage resources of mobile sessions, then it makes sense to be the QoS-NSLP protocol to keep the mapping info. If this mapping is required by other NSLPs, the state should be kept by the NTLP: Henning's NTLP proposal already mention a forwarding state table that includes the session-ID and the destination address. >Xiaoming, frankly I do not completely understand your example yet. Does >Robert mean that the flow-id (which very likely contains IP addresses) >will change after the handoff (and the presumed session ID will be >retained)? > > In the framework draft you can read "A flow is defined by a packet classifier (in the simplest cases, just the destination address and topological origin are needed). In general we assume that when discussing only the data flow path, we only need to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple or equivalent)." Hence, this clarify that a flow-ID contains IP addresses, and so the flow-ID changes when the care-of address of the mobile device changes. In what concerns the session-ID, it must *not* change due to a handover: only this way the cross router can be found, the state related to the flow in the old path (old flow-ID) can be released, and resources in the common path (from correspondent node to cross router) can be used more efficiently. Robert, this lead me to a comment to the QoS-NSLP draft, where section 4.3 pays some attention to the need of using session-ID to allow resources to be shared over the network region where different flows of a mobile session share the path. But, this section is lacking some reference to the need of a session-ID to identify the cross router and to release resources in the old path. Cheers, Paulo >Thanks and regards, > >Charles > -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 04:16:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28327 for ; Fri, 25 Jul 2003 04:16:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxkB-0000Uv-3z for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 04:16:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P8G3l8001876 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 04:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxkA-0000U9-Lx; Fri, 25 Jul 2003 04:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxjv-0000To-83 for nsis@optimus.ietf.org; Fri, 25 Jul 2003 04:15:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28309 for ; Fri, 25 Jul 2003 04:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxjs-0006M2-00 for nsis@ietf.org; Fri, 25 Jul 2003 04:15:44 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19fxjh-0006LJ-00 for nsis@ietf.org; Fri, 25 Jul 2003 04:15:33 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6P8Ed4O014289 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 25 Jul 2003 04:14:40 -0400 (EDT) From: "Charles Q. Shen" To: "'Xiaoming Fu'" , "'Paulo Mendes'" Cc: , "'Hancock, Robert'" , "'Marcus Brunner'" , Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Date: Fri, 25 Jul 2003 04:14:35 -0400 Organization: Columbia University Message-ID: <000001c35284$cb6ced20$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <3F20E2B3.1060707@cs.uni-goettingen.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Xiaoming, > > Hi Paulo, > > Paulo Mendes wrote: > > What do you mean by "universal" flow-ids? > > I was following what Robert used in his context. :) But as I understand, in Robert's context, the flow-id is the one that could change due to change of IP addresses, and Session ID is not. So why universal flow-ID? Snip .. > > This issue has been explored in various ways (e.g., in fw draft and > maillist discussions). Session-ID can be useful, in my point > of view, to > distinguish from other sessions (note they may even have same NI/NR > pair), and to determine the CR and avoid double reservations. > My point > was: even if one can have a universe flow-id, routing of NSIS > messages > is not as simple as expected. In the HA, for example, you can > route NSIS > messages towards the MN following the same rules as in MIP; for the > nodes after HA, however, you have no knowledge of changes in > MIP - how > can you route them per flow-id? Again I am a bit confused about the notion of universe flow-id and the (supposed to be unique) session ID here. Also are you talking about tunneling? Best regards, Charles >Cheers, > Xiaoming > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 04:47:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29038 for ; Fri, 25 Jul 2003 04:47:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyEA-0001cK-TJ for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 04:47:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P8l2St006216 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 04:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyE9-0001bl-BC; Fri, 25 Jul 2003 04:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyDr-0001bV-FI for nsis@optimus.ietf.org; Fri, 25 Jul 2003 04:46:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29018 for ; Fri, 25 Jul 2003 04:46:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fyDo-0006WC-00 for nsis@ietf.org; Fri, 25 Jul 2003 04:46:40 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19fyDd-0006W6-00 for nsis@ietf.org; Fri, 25 Jul 2003 04:46:29 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6P8kL4O019841 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 25 Jul 2003 04:46:22 -0400 (EDT) From: "Charles Q. Shen" To: "'Paulo Mendes'" Cc: "'Xiaoming Fu'" , "'Hancock, Robert'" , "'Marcus Brunner'" , , Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Date: Fri, 25 Jul 2003 04:46:17 -0400 Organization: Columbia University Message-ID: <000101c35289$36fa5b00$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <3F20E4F2.9060003@docomolab-euro.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Paulo, comments inline. > > Hi Charles, > > > Charles Q. Shen wrote: > > >Hi all, > > > >We have had a long debate on whether reliable transport (if > applicable) > >should reside in NSLP or NTLP. > > > Reliable transport in a session protocol, instead of a > transport protocol?!! I was referring specifically to the comments such as " [Robert] However, even if we agree that a signalling application needing reliability needs it between (say) adjacent NSLP peers rather than simply end-to-end, there is still the question of which layer it should be provided at (NTLP or within each application)." But I have no intention to create more debate on this topic :) > > >It seems here comes another topic: should > >mobility-awareness be built in NSLP only or also in NTLP? I noticed > >that Robert and John have explicited said it should be an NSLP issue > >only. This sparks my curiousity to ask: "Is it already a WG > consensus > >or is it true that many people still haven't got time to think about > >it?" > > > >IMHO it would be good to make it an NSLP issue only, if possible. > >However, I would like to see more proof as details being worked out. > >(Although it might still be arguable how detail about > NSIS-mobility we > >should get into at this time). > > > > > I think that avoiding redundant functionalities is a good > goal. Having > this in mind, > I think that only makes sense to include within NTLP functionalities > that are common > to different NSLPs. > In the specific case of mobile session IDs, as said in the framework > draft, it is desirable > to update the flow:session mapping during the session > lifetime. If this > mapping > is only needed to manage resources of mobile sessions, then it makes > sense to be the > QoS-NSLP protocol to keep the mapping info. If this mapping > is required > by other NSLPs, > the state should be kept by the NTLP: Henning's NTLP proposal already > mention a forwarding > state table that includes the session-ID and the destination address. > I think Robert's opinion (from his comments dated 7/17/03) is to let NTLP handle "re-routing" only while the association of n flow-id to possibly one session id is left to NSLP. The question is then "is this association a common function to different NSLPs?" If it is, then it seems make sense to me to consider puting it into NTLP as well. Another comment is, maybe we should call the topic "the association of flow-id with session-id", instead of "mobility", before the former covers more than mobility, (eg. Multi-homing?). > >Xiaoming, frankly I do not completely understand your > example yet. Does > >Robert mean that the flow-id (which very likely contains IP > addresses) > >will change after the handoff (and the presumed session ID will be > >retained)? > > > > > In the framework draft you can read "A flow is defined by a packet > classifier > (in the simplest cases, just the destination address and topological > origin are needed). > In general we assume that when discussing only the data flow path, we > only need > to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple or > equivalent)." Hence, this clarify that a flow-ID contains IP > addresses, and so the > flow-ID changes > when the care-of address of the mobile device changes. > In what concerns the session-ID, it must *not* change due to > a handover: > only this > way the cross router can be found, the state related to the > flow in the > old path (old flow-ID) > can be released, and resources in the common path (from correspondent > node to cross router) > can be used more efficiently. > > Thanks. I apologize. I should have used "Doesn't" instead of "Does" because that is also my understanding. > Robert, this lead me to a comment to the QoS-NSLP draft, > where section > 4.3 pays some attention to > the need of using session-ID to allow resources to be shared over the > network region where > different flows of a mobile session share the path. But, this > section is > lacking some reference > to the need of a session-ID to identify the cross router and > to release > resources in the old path. > As one possible reference, we tested and proved the concept in our RSVP-MIP test-bed http://www.cs.columbia.edu/~charles/publication/draft-shen-nsis-rsvp-mob ileipv6-00.txt Regards, Charles > Cheers, > Paulo > > >Thanks and regards, > > > >Charles > > > -- > Paulo Mendes > DoCoMo Communications Laboratories Europe GmbH > Landsberger Str. 312 > 80687 Munich, Germany > Tel. +49-89-56824-226 > Fax. +49-89-56824-300 > E-mail: mendes@docomolab-euro.com > http://www.docomoeurolabs.de/ > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 05:23:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29957 for ; Fri, 25 Jul 2003 05:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fymz-0002zm-Tz for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 05:23:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P9N1Ev011508 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 05:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fymz-0002zV-9a; Fri, 25 Jul 2003 05:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fym2-0002zD-BD for nsis@optimus.ietf.org; Fri, 25 Jul 2003 05:22:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29943 for ; Fri, 25 Jul 2003 05:21:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fylz-0006ip-00 for nsis@ietf.org; Fri, 25 Jul 2003 05:21:59 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19fylo-0006ig-00 for nsis@ietf.org; Fri, 25 Jul 2003 05:21:48 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jul 2003 10:20:58 +0100 Message-ID: From: "Hancock, Robert" To: "'Charles Q. Shen'" , "'Paulo Mendes'" , "'Xiaoming Fu'" Cc: nsis@ietf.org Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Date: Fri, 25 Jul 2003 10:20:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, some brief comments (well, brief by my standards anyway): *) for the sake of my sanity PLEASE don't discuss the reliable transport question in this thread. it's confusing enough as it is, and a totally separate issue. *) i don't think there has been a formal consensus called on the 'mobility primarily in NSLP' issue/proposal - one reason i posted my comments in that form (and also raised the issue in all the recent WG meetings) is to flush out some comments and discussion. But I think the assumption is that people looking to provide explicit support in the NTLP need to (a) define what that support really is, and (b) explain why the NTLP is a good place to provide it. There are arguments stretching back over quite a long time in favour of the 'mainly NSLP' approach, now (if ever) is the time to challenge them. *) The idea of of associating flows to a single session is to my mind a *problem* common to many signalling applications; however, I expect the *solution* may well not be common. There are two reasons: - it is critically dependent on the session id security issue (see Hannes' draft) which at the moment is probably NSLP dependent - what you mean by 'association' is also signalling application dependent (do you mean sharing? replacement of one by another? adding state together somehow? something else?) *) The next framework will probably broaden the mobility discussion to include multihoming as well. *) We know (among the authors of draft-mcdonald-...) that the mobility handling and session id aspects are not worked out. This will be picked up as the WG item develops (it will certainly not be addressed in the first version, however). *) I don't recall using the term 'universal flow-id'; I was trying to make the (somewhat informal) point that the NTLP sees the world in terms of flow-ids and nothing else (a bit like the way a child sees the world in terms of toys and food and nothing else). *) I'm not really sure what Xiaoming is suggesting in terms of routing NSLP messages *other* than on flow-id. The flow-id is essentially defined as 'the thing which characterises the data path', so routing on anything else is morally equivalent to off-path signalling. Apart from anything else, that's currently out scope for NSIS anyway. To take the concrete example, between the HA and CR, there will be two different downstream flows and two different upstream flows (and in fact, the CR may be different between the upstream and downstream flows). The fact that the two flows within a pair are following the same path is a consequence of the definition of CR, I'm very opposed to forcing the NTLP to work out that signalling messages for one CoA should be explicitly routed the same way as messages for another CoA. You could maybe build an NTLP which was tightly integrated with a specific mobility protocol with this property, but again, that's currently out of scope for NSIS. cheers, r. > -----Original Message----- > From: Charles Q. Shen [mailto:charles@ee.columbia.edu] > Sent: Friday, July 25, 2003 09:46 > To: 'Paulo Mendes' > Cc: 'Xiaoming Fu'; Hancock, Robert; 'Marcus Brunner'; > john.loughney@nokia.com; nsis@ietf.org > Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 > > > Hi Paulo, comments inline. > > > > > Hi Charles, > > > > > > Charles Q. Shen wrote: > > > > >Hi all, > > > > > >We have had a long debate on whether reliable transport (if > > applicable) > > >should reside in NSLP or NTLP. > > > > > Reliable transport in a session protocol, instead of a > > transport protocol?!! > > I was referring specifically to the comments such as " > [Robert] However, > even if we agree that a signalling application > needing reliability needs it between (say) adjacent NSLP peers rather > than simply end-to-end, there is still the > question of which layer it should be provided at (NTLP or within each > application)." But I have no intention to create more debate on this > topic :) > > > > > >It seems here comes another topic: should > > >mobility-awareness be built in NSLP only or also in NTLP? > I noticed > > >that Robert and John have explicited said it should be an > NSLP issue > > >only. This sparks my curiousity to ask: "Is it already a WG > > consensus > > >or is it true that many people still haven't got time to > think about > > >it?" > > > > > >IMHO it would be good to make it an NSLP issue only, if possible. > > >However, I would like to see more proof as details being > worked out. > > >(Although it might still be arguable how detail about > > NSIS-mobility we > > >should get into at this time). > > > > > > > > I think that avoiding redundant functionalities is a good > > goal. Having > > this in mind, > > I think that only makes sense to include within NTLP > functionalities > > that are common > > to different NSLPs. > > In the specific case of mobile session IDs, as said in the > framework > > draft, it is desirable > > to update the flow:session mapping during the session > > lifetime. If this > > mapping > > is only needed to manage resources of mobile sessions, then > it makes > > sense to be the > > QoS-NSLP protocol to keep the mapping info. If this mapping > > is required > > by other NSLPs, > > the state should be kept by the NTLP: Henning's NTLP > proposal already > > mention a forwarding > > state table that includes the session-ID and the > destination address. > > > > I think Robert's opinion (from his comments dated 7/17/03) is to let > NTLP handle "re-routing" only while the association of n flow-id to > possibly one session id is left to NSLP. The question is then "is this > association a common function to different NSLPs?" If it is, then it > seems make sense to me to consider puting it into NTLP as > well. Another > comment is, maybe we should call the topic "the association of flow-id > with session-id", instead of "mobility", before the former covers more > than mobility, (eg. Multi-homing?). > > > >Xiaoming, frankly I do not completely understand your > > example yet. Does > > >Robert mean that the flow-id (which very likely contains IP > > addresses) > > >will change after the handoff (and the presumed session ID will be > > >retained)? > > > > > > > > In the framework draft you can read "A flow is defined by a packet > > classifier > > (in the simplest cases, just the destination address and > topological > > origin are needed). > > In general we assume that when discussing only the data > flow path, we > > only need > > to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple or > > equivalent)." Hence, this clarify that a flow-ID contains IP > > addresses, and so the > > flow-ID changes > > when the care-of address of the mobile device changes. > > In what concerns the session-ID, it must *not* change due to > > a handover: > > only this > > way the cross router can be found, the state related to the > > flow in the > > old path (old flow-ID) > > can be released, and resources in the common path (from > correspondent > > node to cross router) > > can be used more efficiently. > > > > > > Thanks. I apologize. I should have used "Doesn't" instead of "Does" > because that is also my understanding. > > > Robert, this lead me to a comment to the QoS-NSLP draft, > > where section > > 4.3 pays some attention to > > the need of using session-ID to allow resources to be > shared over the > > network region where > > different flows of a mobile session share the path. But, this > > section is > > lacking some reference > > to the need of a session-ID to identify the cross router and > > to release > > resources in the old path. > > > > As one possible reference, we tested and proved the concept in our > RSVP-MIP test-bed > http://www.cs.columbia.edu/~charles/publication/draft-shen-nsi s-rsvp-mob ileipv6-00.txt Regards, Charles > Cheers, > Paulo > > >Thanks and regards, > > > >Charles > > > -- > Paulo Mendes > DoCoMo Communications Laboratories Europe GmbH > Landsberger Str. 312 > 80687 Munich, Germany > Tel. +49-89-56824-226 > Fax. +49-89-56824-300 > E-mail: mendes@docomolab-euro.com > http://www.docomoeurolabs.de/ > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 05:49:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00359 for ; Fri, 25 Jul 2003 05:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fzCA-0003nc-Qw for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 05:49:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P9n2X7014603 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 05:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fzC9-0003n2-3l; Fri, 25 Jul 2003 05:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fzBs-0003mj-5t for nsis@optimus.ietf.org; Fri, 25 Jul 2003 05:48:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00347 for ; Fri, 25 Jul 2003 05:48:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fzBo-0006os-00 for nsis@ietf.org; Fri, 25 Jul 2003 05:48:40 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19fzBd-0006oi-00 for nsis@ietf.org; Fri, 25 Jul 2003 05:48:29 -0400 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 25 Jul 2003 11:48:01 +0200 Message-ID: <3F20FCB5.4080305@cs.uni-goettingen.de> Date: Fri, 25 Jul 2003 11:47:33 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: "'Charles Q. Shen'" , "'Paulo Mendes'" , nsis@ietf.org Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, Thanks for your clarification. I really appreciate a framework view on discussions on mobility issues, and agree with you to first explore what is necessary for NTLP to support mobility, if needed. I followed up your previous mail regarding universe flow id because this is also (for both you and I) meant how to route the NSIS messages. Actually, in a previous version of fw draft it stated either way of using flow-id: *) Use a flow identification based on low level IP addresses (e.g. the Care of Address) and other 'standard' fields in the IP header. This makes least demands on the packet classification engines within the network. However, it means that even on a part of the flow path which is unchanged, the reservation will need to be modified to reflect the changed flow identification (see section 5.3.3). *) Use a flow identification that does not change (e.g. based on Home Address); this is the approach assumed in [23]. This simplifies the problem of reservation update, at the likely cost of considerably complicating the flow identification requirements. This can also answer some discussions. My worry, however, is that flow-id might be insufficient to address the NSIS messages in mobility scenarios, not talking about the mobility-coupled issue; I was trying to discuss in the context of decoupling NSIS signaling from MIP signaling. Hancock, Robert wrote: > *) I'm not really sure what Xiaoming is suggesting in terms of routing > NSLP messages *other* than on flow-id. The flow-id is essentially > defined as 'the thing which characterises the data path', so routing > on anything else is morally equivalent to off-path signalling. At least I can tell, if we use some on-path LMM schemes (e.g., fast handover, HMIP), this flow-id could be insufficient to route NSIS messages. In such cases, data path in the new segment(s) may not be fully characterized by the flow-id (3/5 tuple?). Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 06:21:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01017 for ; Fri, 25 Jul 2003 06:21:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fzgA-0004zY-6I for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 06:20:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PAK2UQ019171 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 06:20:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fzg9-0004yh-Lg; Fri, 25 Jul 2003 06:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fzfo-0004yB-JW for nsis@optimus.ietf.org; Fri, 25 Jul 2003 06:19:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00985 for ; Fri, 25 Jul 2003 06:19:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fzfk-00071i-00 for nsis@ietf.org; Fri, 25 Jul 2003 06:19:36 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19fzfa-00071e-00 for nsis@ietf.org; Fri, 25 Jul 2003 06:19:26 -0400 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 25 Jul 2003 12:19:31 +0200 Message-ID: <3F210417.8050102@cs.uni-goettingen.de> Date: Fri, 25 Jul 2003 12:19:03 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles Q. Shen" CC: nsis@ietf.org, HANCOCK ROBERT , Paulo Mendes Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: <000001c35284$cb6ced20$c7f027a0@president> In-Reply-To: <000001c35284$cb6ced20$c7f027a0@president> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Charles, > > Again I am a bit confused about the notion of universe flow-id and the > (supposed to be unique) session ID here. I think Robert's concept on *universe* flow-id doesn't need to be unchanged during a session; if I understand correctly, he only meant "universe" for signaling session at one time. > Also are you talking about tunneling? So far in this thread, not yet. However, in my view, IP-in-IP tunneling is an important issue for NSIS-mobility to work out. Re-routing and local repair issues in the data path changed by mobile IP may introduce problems other than (routing header + destination option in case of MIPv6) - imagine what if a message is encapulated into tunneled :-); reverse tunneling could be more complicated. My ideal model is that NTLP should be aware of any tunnel entry and exits, and route NSIS message when entering and inside a tunnel differently from the case outside the tunnel. Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 06:37:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01555 for ; Fri, 25 Jul 2003 06:37:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fzwb-0005Zh-Uj for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 06:37:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PAb1Yg021425 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 06:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fzwb-0005ZK-P9; Fri, 25 Jul 2003 06:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fzvs-0005Yb-G8 for nsis@optimus.ietf.org; Fri, 25 Jul 2003 06:36:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01551 for ; Fri, 25 Jul 2003 06:36:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fzvo-0007A6-00 for nsis@ietf.org; Fri, 25 Jul 2003 06:36:12 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19fzvd-00079x-00 for nsis@ietf.org; Fri, 25 Jul 2003 06:36:01 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jul 2003 11:35:12 +0100 Message-ID: From: "Hancock, Robert" To: "'Henning Schulzrinne'" , Thanh Tra LUU Cc: =?iso-8859-1?Q?=22Attila_B=E1der_=28ET/ETH=29=22?= , nsis@ietf.org Subject: RE: [NSIS] Reliable Transport for NTLP Date: Fri, 25 Jul 2003 11:35:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable dear all, just as an fyi, i am planning to write a small analysis draft on the reliability issue during august, which would hopefully summarise what we have and have not agreed and what questions still need to be answered once and for all. it will also=20 contain a proposal on this issue and the layer split. I hope that sounds like a good idea. if anyone has pointers to information that I should consider (e.g. in particular whatever was 'in the air' at the time=20 2961 was being put together, anything with quantitative analysis of rsvp behaviour/known problems) I'd be very interested to hear it. r. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, July 24, 2003 14:44 > To: Thanh Tra LUU > Cc: "Attila B=E1der (ET/ETH)"; nsis@ietf.org > Subject: Re: [NSIS] Reliable Transport for NTLP >=20 >=20 > Nary Tra, >=20 > in order to make progress in this WG, we have to keep from=20 > repeating the=20 > same non-disagreements again and again. Nobody here, as far as I can=20 > tell, is suggesting that TCP be mandatory to support or use for a=20 > particular NSLP, only that it (or similar protocols, such as SCTP or=20 > DCCP) are appropriate parts of the tool kit. >=20 > You may also find it interesting to read some of the proposals that=20 > indicate how router alert options are being used. The two issues are=20 > orthogonal. >=20 > Maybe we need a FUD FAQ :-) >=20 > Henning >=20 > Thanh Tra LUU wrote: >=20 > > hi Attila, > >=20 > > I am a fan of E2E reliable delivery but I don't agree with=20 > your idea. > > If TCP is used, reliable delivery is always used even though your > > signaling application needs it or not. It belongs to lower layer = and > > there is no relationship between stateless attribute and lower = layer > > here. > >=20 > > I feel that TCP is something too 'solid' and not flexible. If TCP = is > > used, signaling application must bear all the security=20 > attacks of this > > protocol (e.g. SYN TCP attack). It will be easier for attack a > > signaling aware node because a packet can be sent from a=20 > distant host > > to a signaling node on the data path without Router Alert=20 > Option being > > set. > >=20 > > I'll try to find some more arguments for using IP or UDP as a lower > > layer of NTLP. > >=20 > > Nary Tra, > > ENST, Paris > >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 09:58:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05128 for ; Fri, 25 Jul 2003 09:58:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g34r-0004dB-Vd for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 09:57:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PDvjic017800 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 09:57:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g34A-0004Zw-0c; Fri, 25 Jul 2003 09:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g33u-0004ZP-IN for nsis@optimus.ietf.org; Fri, 25 Jul 2003 09:56:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05031 for ; Fri, 25 Jul 2003 09:56:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g33s-0000Q8-00 for nsis@ietf.org; Fri, 25 Jul 2003 09:56:44 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19g33h-0000PY-00 for nsis@ietf.org; Fri, 25 Jul 2003 09:56:33 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6PDtWVI004323; Fri, 25 Jul 2003 15:55:32 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 48F9442618; Fri, 25 Jul 2003 15:35:19 +0200 (CEST) Date: Fri, 25 Jul 2003 15:55:32 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: Harald Tveit Alvestrand , mankin@psg.com Cc: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt - Comments 1 Message-ID: <18750792.1059148532@[10.1.1.130]> In-Reply-To: <494154156.1059033644@localhost> References: <29712564.1058984867@[10.1.1.130]> <494154156.1059033644@localhost> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Donnerstag, 24. Juli 2003 08:00 -0700 Harald Tveit Alvestrand wrote: > Marcus, > > thanks for the follow-up! > > --On 23. juli 2003 18:27 +0200 Marcus Brunner > wrote: >>> >>> This section, from the start of section 5, worries me: >>> >>> >>> The parts of the networks we differentiate are the host-to-first >>> router, the access network, and the core network. The host to first >>> router part includes all the layer 2 technologies to access to the >>> Internet. This part of the division is especially informal and may >>> incorporate several access segments. In many cases, there is an >>> application and/or user running on the host initiating signaling. >>> The access network can be characterized by low capacity links, >>> medium speed IP processing capabilities, and it might consist of a >>> complete layer 2 network as well. The core network characteristics >>> include high-speed forwarding capacities and inter-domain issues. >>> These divisions between network types are not strict and do not >>> appear in all networks, but where they do exist they may influence >>> signaling requirements and will be highlighted as necessary. >>> >>> First of all, the grammar is sufficiently convoluted that I have >>> problems parsing it. >>> >>> Second, I have definitional problems. >>> >>> I have problems imagining how an access network can work if it does NOT >>> contain a "complete layer 2 network" - after all, a link is, in its way, >>> a layer 2 network. OTOH, I don't think GSM/GPRS can fairly be called a >>> "layer 2 network" - it's more complex than that - but it's definitely >>> being used as an access network. >>> >>> The sentence "host to first router part includes all the layer 2 >>> technologies to access to the Internet" does not parse, and makes the >>> definition only make sense when the first router is connected to the >>> Internet - I don't think that was intended. >>> >>> Since this paragraph is key to the overall architectural constraints, I >>> think it's rather important to make it crystal clear. >>> >> >> Actually, I don't think the paragraph is that much a key to the whole >> architecture. However in the consensus finding phase it help to make a >> number of people happy. It has been heavily discussed during the lifetime >> of the draft, therefore it went grammatically wrong. At this point in >> time, I think that the whole paragraph can be removed. >> >> Anybody objecting to this? > > Do you use the distinction between "host to first router", "access > network" and "core network" elsewhere in the document? I could find > "access network" and "core network", but not "host to first router". > Defining those terms is important, since different people get upset based > on where you place the boundary. OTOH, "host to first router" is > relatively easy to figure out..... The only implication we make with he term access network is that is nearer to the edge and relatively low capacity. The term access network is used another 3 times in the draft 2 times because of the bandwidth characteristics and once concerning security (controlling and charging for the access). So think we should just make the definition clearer? > >>> Section 5.5.1 on scalability worries me a lot, because it uses >>> "scalable" without referring to a scale; while it may be appropriate to >>> "scale" an end-system-to-first-router protocol to 10.000 users and say >>> "good enough", I think core routers have scalability requirements to >>> millions of active participants (which argues for them not having to >>> see their state....) >>> >>> I would like to see some hand-wringing here like: >>> >>> "The NSIS protocols MUST be scalable up to the level of ubiquity - that >>> is, if every end-user on the network uses NSIS functions, the system >>> MUST NOT be brought to a catastrophic failure, but continue to give >>> service appropriate to the resources available." >>> >>> There might be more than this, but this is at least worrying..... >> >> I understand the worry, but your proposal does at least for me not say >> something different that what is stated in the draft. Some people >> regarded the requirement as motherhood and apple pie anyway. > > It's been one of the major hassles of RSVP deployment (from my far-away > ivory tower, at least) that it never got around to actually discussing > numbers when talking about scaling; the technology works fine (I think) > in an enterprise context where the number of users has 4 or 5 digits, and > the provisioning of the network is under centralized control; the hassles > we have had involve trying to imagine the operation, economics and > politics of deploying something at "Internet scale". Given that we've > already got a lot of history here about discussion of scale, I think > being explicit is good. Getting consensus is sometimes hard with being explicit. I will try to get the text clearer here as well. Thanks for the comments anyway. Marcus >> >> Actually, what I think you are referring to is the robustness of the >> system, where as salability is concerned more with the performance of it. > > To my mind, scalability has two aspects: > > - How far can you go? > - What happens when you hit the edge? > > There was one IOS version (beta code, I think) many years ago that, when > you started listening to multicast groups, fell over when you hit the > limit of resources available for multicast state. That's the worst kind > of not scaling. And the fear that there might be more bugs like this has > been a major worry of people thinking about deploying multicast, and > other protocols where they lumped issues under the "scaling" label. > > Again - it's history that drives my worries..... > >> >> Somebody from the WG has an idea how to resolve that? > > Thanks for the feedback, and hope this is useful! > > Harald > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jul 25 10:09:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05970 for ; Fri, 25 Jul 2003 10:09:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3FR-0005Ce-Lc for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 10:08:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PE8fbu019984 for nsis-archive@odin.ietf.org; Fri, 25 Jul 2003 10:08:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3En-000587-Fk; Fri, 25 Jul 2003 10:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3EX-00055K-C9 for nsis@optimus.ietf.org; Fri, 25 Jul 2003 10:07:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05801 for ; Fri, 25 Jul 2003 10:07:39 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3EV-0000Uy-00 for nsis@ietf.org; Fri, 25 Jul 2003 10:07:43 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19g3EK-0000Uf-00 for nsis@ietf.org; Fri, 25 Jul 2003 10:07:32 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6PE7AB04001 for ; Fri, 25 Jul 2003 17:07:10 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Jul 2003 17:07:03 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 25 Jul 2003 17:07:02 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 25 Jul 2003 17:06:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: reliability or not reliablility was: [NSIS] mobility-related requirements from nsis-req-08 Date: Fri, 25 Jul 2003 17:06:22 +0300 Message-ID: Thread-Topic: [NSIS] mobility-related requirements from nsis-req-08 Thread-Index: AcNSg5BwE7NT38y9RsOoARZKpcxf0wAMbNGw To: , Cc: , , , X-OriginalArrivalTime: 25 Jul 2003 14:06:56.0421 (UTC) FILETIME=[01CC7D50:01C352B6] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Popping up from vacation: > Reliable transport in a session protocol, instead of a=20 > transport protocol?!! There are many forms of reliability, in some protocols, there may need to be different forms of reliability. Basic signaling protocols may need explicit acks/nacks; may set timers & if no response is gotten within the timer, protocol may send again, etc. The question we have here is, what level of reliability do applications need? We have agreed that soft state is needed; also 'session' state should not be tied to transport state, i.e. - if the transport protocol session is terminated (for any reason, error, re-routing, time-out, etc) we don't assume that the session has ended. Rather than cycling on this, NSLP protocols probably should state what they need / expect and NTLP should provide this functionality, in terms of reliability.=20 John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Jul 26 00:21:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10520 for ; Sat, 26 Jul 2003 00:21:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gGYK-0003op-Aw for nsis-archive@odin.ietf.org; Sat, 26 Jul 2003 00:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6Q4L48K014675 for nsis-archive@odin.ietf.org; Sat, 26 Jul 2003 00:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gGYG-0003nz-31; Sat, 26 Jul 2003 00:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g51x-0003SV-RO for nsis@optimus.ietf.org; Fri, 25 Jul 2003 12:02:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10335 for ; Fri, 25 Jul 2003 12:02:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g51v-0001T3-00 for nsis@ietf.org; Fri, 25 Jul 2003 12:02:51 -0400 Received: from mailgate.urz.tu-dresden.de ([141.30.66.154]) by ietf-mx with esmtp (Exim 4.12) id 19g51T-0001Sf-00 for nsis@ietf.org; Fri, 25 Jul 2003 12:02:23 -0400 Received: from [141.30.128.170] (helo=dmz.secifn.et.tu-dresden.de) by mailgate.urz.tu-dresden.de with esmtp (exim-3.32) for id 19g51N-0003uz-00; Fri, 25 Jul 2003 18:02:17 +0200 Received: from localhost (localhost [127.0.0.1]) by dmz.secifn.et.tu-dresden.de (Postfix) with ESMTP id D71241EDC1 for ; Fri, 25 Jul 2003 18:02:17 +0200 (MEST) Received: by dmz.secifn.et.tu-dresden.de (Postfix, from userid 604) id EAEC91EC6C; Fri, 25 Jul 2003 17:56:31 +0200 (MEST) Received: from entlw7.et.tu-dresden.de (unknown [141.30.128.21]) by dmz.secifn.et.tu-dresden.de (Postfix) with ESMTP id 2E5C81EAE0 for ; Fri, 25 Jul 2003 17:56:29 +0200 (MEST) Received: from ifn.et.tu-dresden.de (entcph.et.tu-dresden.de [141.30.128.117]) by entlw7.et.tu-dresden.de (Postfix) with SMTP id 780DE48B1A for ; Fri, 25 Jul 2003 17:56:22 +0200 (MET DST) From: "itc18@ifn.et.tu-dresden.de" To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="= Multipart Boundary 0725031758" Date: Fri, 25 Jul 2003 17:58:04 +0200 Reply-To: "itc18@ifn.et.tu-dresden.de" Message-Id: <20030725155622.780DE48B1A@entlw7.et.tu-dresden.de> X-Virus-Scanned: by AMaVis*sweep*3.71*030714 on dmz Security OS Content-Transfer-Encoding: 7bit Subject: [NSIS] 18th Int. Teletraffic Congress 31 Aug - 5 Sept 2003, Berlin Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multipart MIME message. --= Multipart Boundary 0725031758 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Our apologies for receiving multiple copies of this email... Reminder: Eearly bird discount expires on 1 Aug 2003! CALL FOR PARTICIPATION CALL FOR PARTICIPATION CALL FOR PARTICIPATION 18th International Teletraffic Congress 31 August - 5 September 2003 Haus am Koellnischen Park, Berlin, Germany "Providing Quality of Service in heterogeneous Environments" http://www.itc18.org This year, the global teletraffic community convenes in Berlin, Germany in the first week of September. In this week you will have the chance to participate in six tutorials, 133 presentations plus four invited talks and to meet 400 experts in the field of teletraffic engineering for advanced fixed and mobile networks. Please find attached the Advance Programme (PDF). See you in Berlin! Joachim Charzinski, Ralf Lehnert, Phuoc Tran-Gia, Technical Programme Committee co-chairs --= Multipart Boundary 0725031758 Content-Type: application/octet-stream; name="ITC_18_Programme2.pdf" Content-Disposition: attachment; filename="ITC_18_Programme2.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy ZW50IDIzNCAwIFIgDS9SZXNvdXJjZXMgMiAwIFIgDS9Db250ZW50cyAzIDAg UiANL01lZGlhQm94IFsgMCAwIDg0MiAxMTkxIF0gDS9Dcm9wQm94IFsgMzku Njg1MDQgNTU4LjQyNTE3IDYzNS4wNzA4NiAxMTUxLjMxNDk2IF0gDS9Sb3Rh dGUgMCANPj4gDWVuZG9iag0yIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYg L1RleHQgL0ltYWdlQyBdIA0vRm9udCA8PCAvRjEgMjYzIDAgUiAvRjUgMjQ3 IDAgUiAvRjYgMjQ4IDAgUiA+PiANL1hPYmplY3QgPDwgL0ltMyA0IDAgUiAv SW00IDUgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjY4IDAgUiAvR1My IDI2OSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMjQ0IDAgUiAvQ3Mx MCAyNjIgMCBSIC9DczExIDEzOSAwIFIgPj4gDT4+IA1lbmRvYmoNMyAwIG9i ag08PCAvTGVuZ3RoIDgzNjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSInEV9tyG8cR/QL8wzwuU+Fweu7zaNOSolRSxZhM/ODKAwwtScQg QGNBufjJ+YucnlkAsyBXAiNRLlaRQHOmu09fTvf8NiExF5MkiKIWUVtxSmS1 WLdb2d3kJ7GcKHxJJCL+dZo/4QDLv7+anL31gsTVNS4o/CRho5bJORLOe+lS jOLqbnJ23jkx6/IRJbrZ5OzdJYmbDpqvZvzr90lDJ1f/gTpX1FE5ij/GW5nY NBEFmYwm1niqpFJK5+tS6RCzjr/Nu41YXYvz1XLTLjedKDp7FzXJwA6dGglw EP3Qq6G9FxfTm3bgyOnulpbOperWgfGfm/fLj/PNdDNfLcVmJd5fnQuKJ/++ +uveA59BeWGdl8pDKSlPkrxyjKl4IOTX/2FE+4i6lCQ5rXfWfW99Nmn0AXgj LXmAJ4kUuAPwzfnq7m6+2bRtNwj0DqZmmBq1pKyWwTjLhl4F4QswV64UzOYl mOuEX50kFEfzcIL/U7NZrefThbhYn6BOfbO6WU/v7tqRAvDshA9wR1tpiHW/ VgGMBmJoGYEIRwaCdoEI20AQKZmadna7nM8QhMu269AH3Vj5B0khQKqUkzHa dNjS3yQQBvxkaOhEQ56PnWqG55nvdl1fZ/7vq+WH6eNJMEj/nwHusr3ftHe/ tOsMeIcTJqIjJ1JSUidrv0aSR1DUJo4EkcvXNw9tV2HRn8USrAzKpNfEUplo KB2D5acTUCoK8MNyhyYCjRlB41CuTpMVyaEdyJj/H80Yhkpxo81R+bh9WNep sGPOKzhPCc5bGNM6fmkqxiBU6hsdj4Hwdj2vALixWoro/2hQSzpP9C+I/nFA ipnSG+ZwxGkZvUo1y1Ubxbt22a5BaO+X16v1XR7uz486zzkhL5JK0qlAr8Xn YxArs40ZLbdD/i4gf2xvsDity+rytp/mO2TcShZkHWErkXevyNUj4GrLx4HD Hvd4hw1wAMQAiElRxBCl0e5w6LzyXjKGrXKmMfYYbOfT5axdLHbFuB+rqEGV goh+v+K8NsAxWJULjXFHwPq5KZtTaFaztv0wX950Q9LYobNgD2vjH4mucuF5 dOPN9pfVpl2IH9uuXX98msJdsxlWYw9T+C2arbJ8XObqAYCX13Xb57FFmYqa Ww6mGC8UxopITiZvvt4OOAasstOYcMw426PxBc2/TpzNyB7aYXEGnmjYjiJm swlfsk+8BFFlrDGjA3rQZP2bZX3CT5bpsrtfrTdDKIaXcxNEiIAadfiWNDkC tHalMaML4cjr5LsPH+ZcfrvHWRg8zp5suMFjdUuavnLvjWGrrDVWvRDb++UG BXoKUKlZthtxPr3+7wFtMqNwOvHBK2wo3+KpNY628uJ5tJ8Ae7mazT+XxG0j BhOlItKvBncMYGX3Bekss+GHttvMl2UP+75dL+bPD4eAndVq9QdsYrXlxtLL 0BVEAou0+G42W93dT5ePGPPiol13q+Vg6XR4ekRPRgTlsbS9GOiY+1mb6ntt dJHcPyenm9vDt4vhNcRF4cGj2qQSiq/fP0fhGfhg/THL4/tl97DmBXK4Gvec 74OT3sZvuhqPYatcOQ5bTRUX0y6PNjFdfsDUznwx76Ziu5r89jDffuR3wnDV dByOhLnq8apDrl9ef5/CVek8MmeXt6v7e3TK8ymzVlofvsk6/DlolSvPQyvd df6w3i9Vj89vH15HGUOwr95eY1hq+3Z0W3ye6d4s2tlmPZ/NN49nF7erZSsu ppvZ7YDhsLs5SlaA5aSO/mvO5TFIlaXnIX1isX9zByLU3DA3nDRxiefLfNYe vNEiT1/jYBPZxbL9ChNqBFxtsQeX8qEkKGqpfOS+dpK0qkJd+uufmo+fvXUC 368nGN5ZuxZE2DuNhwoiD9ovr6Iq0e+vzimKt5jZy7yaXN5jkK3WXdHni75T I22EZ6eYnbvxAuI5UY1YzH9txWYlNrfT5a/43WI8Lhar33kudr0ynpg5zLgf UuJcadbT4Ph8LT5OFw/TXxat6B7uM+WtrgX8Amz24s3VhAT/dDMA0xh/QKOM l4EsICbp2DPrZAQlrduJDlom7BiksG0YTPq7yfWfJv+YnJ13Tsw6oaRWln8j uoi8Z71n7y61uOlgaC4mWiVpIiwqYjaIUKAVdiKUOkTQ6a3QPIcpQIDDybIA S3DURWCDFrOJxlmy+UyUHgo1UhA9C0hL7VmArdduDRHf0U5qZ/e2FxApGVJk NRYZxC0VJJdjFgTxcUIJ78LijOWlAye0zBHolTw+xbSYXKMMYiCuFEm+hNd6 iTrhU06apIGcnEYQTRFZWF9AhFgTOwTPLDuLQPsMVBMQ437AP3To9eAEVIco jaa9CHoix9+xKEmow+KrEp/gJKOjyUdEyfYC7VkLP16tLiLPbtmEv7b44nD5 EMEs43yacUInRRXrJBNWNpuLaxcjsjrHJuedUsgiu03iXoRBT1UeOUaE4A5F NkpitMpJlG+WIPLOD0WASn0VOcMSrOPa6KEIjlIa3NMwE81AdIiQU456BINm jKjokDMMQLpUIUIWylWPgtUDEU9GF0uOmSALRuPdQHSonm1qkK43sdeGXkE/ wTfn7V6EMsfcDFkbrhq4q2HRmF6XRY9rTkag/SW0iwOVlTM7PShYFVKpKvAF rqFEjCs1Q6hKzXkOoQi44qDHWFmqCEiiExqzM5nsH3xH3TzBwHWlVSGYXhgY GKHyt+3CokWmAVsKhguAux7KqXz38IO/a7XVDSOFBrzdJsBkNfDAlJ5KEo2k kXHnehQG7chqbAbOOPFhlrtelXYhmTA3NVNI0j0uVBVD0Mnv/Z09RZXrJqD4 duccQ6UINnNpL0L6k+pbmCEh9sxMpPocGq7PhKSGLTCXY68Q87SzlxgrXEjG b3OIEPGuEUyPjakOemzuc85h5D6naGXaFmiAvsi8ucVqITjEMOuBKVM1agFG tJcwU2G52LalY8dwhF3NAm0zCUdkNxYJ5SMgNWuKgNmf+KlT0qxAF2yeEleC 3YsWWcRVm68pBopQ2J7sHd6T2E5QYb4IfGY4wsTLJjP/c98egnpkpKDtUjAs NC63PuAccJLDAqTtQIR9v/AwvDS6iHi0URltitcLb2XNSI/ZKRWH5IaxkDKH 7G5F0LkpmhV4g6+h+tw2SpHHAkIdXRmazLc8JyJtaTqXEPmU516dMr+NI9M0 b0IeQzLHjQUqpwwoYmErFuE+BCFWIXp8GrUto+FsHUrNo08PQskkEswglNpw beo6lEw9oZRSCQpzY0ihjiUzls+lvNcEMiwMur2GYcINVcWSGTQVSi2x1JZZ Oe5jqXMB6DqW2hJCWIWXXUwyN18fSqZqR7YOJTvd91YJJQtM+h/hZbJiSXJE 0S/If3hrQXWHz+5rCYSWQov+gETDIrOFVP8PuueaR7zIAURBvTQLd7fZ7Fq5 u/KL13Dlf17ApsrZqaT7IbiawXCb9/7y2+N3Ye6k2nnMCsjnLx2Af6FCobdk 9KZCF4B/TPAE+jWqSnBTqKH42gkEVd5Cglz+3fhK7WcorWr3cMrRE4NTHEn2 jvoY1F5EzbbsW8M9q2iYS8W4FR27O5XHBM/MfYs48I6c4DEzFYYxqxU3bTlK gcPNGI6a7KC7qN/xwpGho8KZArVuOnskbnM24+2zfW8v/3payLazwmYGjhmg PVQH0Qz1uVWDLMN6ZXnk1bZpwbQlvTAfFf9cTKtlPZ4S6FaeRZ9kvu2WtNSz J0BW3wJuqndPBgAIVniCCp2aEVSSgNbRZIua5DgYlOC9KnlD88DdAtylclXj DzzUuppuEq2b3UC0qefiY53owyCvMRTDh27UpI2aGzTzVDr0gYjkoL0a740D zmHj1AnVWuKB0dH6cKvhxjRsVbGCh7mAbMBUG80HSoBWtSqoUdzParQxdBwA RNX/Qd7Iyswk03sZ78sqZYZvpF+6PdMC/dTD8dT0oAGIAjbzXsqWoJIu2d8b btKB1nI8WKct6rZQ6Rb4vbDWECpEjzghSp2gFAdGUUvHTg+wbm3N30eaGyMr 6lN7UxnhAb1CnIGmkN2v64VA+vI65YS8miOwBJpUWaZJGTJDGo8IrCbHahbB 9tAIygySwayoMkegt0mV2spWsrR+ovaDRzXDGUIN9MUJmcMw1nDMW0Q5Qqga 6OzmsFloWRAuiQNgvg5c2QnuOOl7vKB6cb4u7zrQTYaTnSk+50hXDd8yogJm K76QcndkvKw0crE7ci2vvSMl5yvb5jXTZ3HZNBBbY+0c9q33tk9laFykxpMc j6lX3zftonETiYWjb06/cRzz4W0AVG25LGnrxvGZGbuMqmuNzWk3Di+3I2Td dQk4WqNNSOQwZoNRt/DphJuxlH3HiVtwFJ6jf8MJs6yOFte68jec262P6lhD NeyDhsi1ZrC1OaFQYD1115K+5YDtbLuaAq33O44SfOV9q6z+DYeIz7Vut77j KIOaDVtRCN9xwoq3L3YZDikyiuyVC+8X5+l8ID2d5SsHaWsG7Fd+lvaFU29Z 9lmWfa0qG5rzoROu7t0r0U1tOG44h+v0BKM7pZsdO5qb1p1zGK6RwK3bsUK1 pUcyJiCG4Gq2oSlQ3EXr1yvGk6MOAZylFW/PMOG6PFzKRb9e1pyct8/2McHD nijZPqptnt7oXMT0/L4uurLbQqfuot+z0ye6bVkg7B5dDrowxi4Z8tl0a/kk NUpRXjtOJOQZfnIMQfJZVeMLIwcYSM5GXR91fMsxeostbDEVvzKyFb/f+cLR SlQM1JDddP8zp14mvH0xKipas3LNwETJPdGcHnaFzorQUcu3nLiFNHXw41uO IVq0qq4gpi2/3Dm3Wx/1sY4rIDb2j7wLEcQAflwt77LLo/pItxszs6if4Wnm 4LQPIFK3OmekUMtzF2KeEY050246ve4zl/HjdEeO5gU+ucv6pLL7SQH9xRnV 0PuTUYxSANvCheWEvVZHCCbTps0JQK6CcxrqVln7zCi3oOaiZlY/gPiboHlj XHFggzPwvWJ1cQzJ8/2V0N8msXnVCF9TqGWTAE6h/ZHwB7sZsGUFBJ/sc5pW DM9Nv3qdm6PcTmiYtp0SYG5oG9yNFl+9N84ZKHzoZKx7zTj+EIiArn7xMKji hjiV3We6z6Fly+EAAQtrlcKFaW0JPTyY2QwFTPu5bGgiskwWgsvIHF4c2FtT t8jsJpsNbpvrkWqyGV6/liJqibYqSF7osQSc3xmZUeB9bRooKwFDtsaFtbcu 7RdWqlIAQlSb2jvXbN3nk2K0d66GX5UNIwJMiqFRW/WiXx3L4yi3E4p2j6qb q9nPxwg6bSM+5kOMMYE+dhlVVFNGvD85dmfdo8BT69kYTg4V3q/JNqPCU2of OLE1vnkqldxvSXtxXL0h66M+zuNU9p63PGGVxwL9RxkXh96Ro7t1/V6kuo7X 000rWuxp1+0RXeB6f9O6kLox+fMEc6zdXtj0JeFibA3OB04FP5nwqnH65DF9 ks1qOy2CkxPiI02Uwzf6EnsyhPALYvYDjJm+bpYFzY3kGrtOHOyf+fnCRV++ OxmnDvuBS8ePVoDj//MiUKIB95h64kdipfrv30/e+8tvj99fDhFLkEaffvgv HYD/6x9/qnx+PpL//Xx9+fXPf0uPf/400l8qCKXbLznWXW2mjx/anujyuv6P P0hwyo0tKj8O/WPfm6xQ592s2T2onveXX//yXh5/+vfLX1+SnEg/0unKksjM m48f6rBTSfJ8mMhJIg/zXmcR0oNc1Quqp3i17le3zKmIL1mZVNBZ5fmjCSVc 7/7VL//fk7/94eYattUHe+XU/10N8OcGfBptU0V3xG6S1OEVAUG9yc7XgQQ6 0OixzTvjkupTa9gse0lcSm0YWXOJC+A0LXbaREVKAFsqdAkkJ3+1YOgFClf+ fdDOkmMUf28Ax5q0v1R2DbY/kOmNBvTG6ZNTc/W7aYXgqhOInaFXjtc19zIM DYWcrfck9UTLkzYU50KuuZfbjqsaaLl5uW02vBooQtc5rQBQjeWW0Ff7bhrV DteKFl2BoGR4XaD169qGkdXEYeQcDbP+4oKQNXMhRAOm8aSebmSdwnLUywq9 ofa+ctiR8a/oPFFbkEX+cZ6C4TfNDTzXP5zIPeiFJy56l/aToQQkm/WBmT7l 0olSeICYuyfP0xOVE+qD1b5uTQdo43NF3NlJ1TZXbXb2EGgXY3m7Ae1nFjLN yerwq/Q0q6DbGvtCYWFlkpZ4sirHeWHV7vAPrbtTw31YgpSn404lfFagE2CB TUYHWRtS0eC0kZrgy35SZTN+8ItgqIpYvmc7qitKI6uaE71JHud8lqdV3hOw tCh6XpIRkjQOqaSW0zRgT/rVTejQ6vY8QYUPv1DcNp70yNbp4rCpZr85SCnp lEnKzE10Vn2PuKHVaw5Hk6gnIc9MLPrhDRc/LFYvuTzFjtdomcueWiS+TtYa rgWiXLRGb0prl0pw6P1RGY5ND8e1YbRjukcKLuNJOLgE5xfBKqIFBqCJ1oZI upEzKiO8WSnQIma1bvKg2kWm8qS5MAw5nieokxrxJydvdE3pvGGOMJ9WhVQA JrxAD0JJefBIzlpljc1QQSsd1deU16qcRmGTtlKOeSLDZyoXHZ7yPDtP0C6p Xk3FNu+0YM0ou28FJ2/vq2HvUinRlZgwKNVb3rU3bIY4Xn30QqtRPONYLq5m rSs15wkwL5KuJEl06PN7dhpAHh9ouWnt82aAeTteUMlho0oy4Uc6tObTZHIc 9nSjErI5MxkW0teZBB0rlaWqwkp8RfceNI7t5cwHXXXrVB84Jr21eE2KYCm8 /M560ajZXWTPEwIiTDbRjQS50YfR3ZPDfokMcMItpT4OUzqGPMyMYTERBHh3 D2GBmurbrteSvVlQr1N3yClmyiZjx8FJJ+ftxolH376IEUfJUfBGAyc3BF8c Ob9On0nGgJxZHe3pzfPZ9knrdJGY37wnPQ8oATxxlRc13WjFJjrmyVHUqClE 1ntUT6WYcs03Lo5ag/rWk1YtFuvYmcpBRkhAXdd3RR/IoOtj1hvNXnaqlPHe 5rzdOGoZGpS+c8SsykwOyRz9SaMkBZSeJyazJTATO8iT1iZr9Hxxdjy+RujG 2c56d4QyGUpr1uC4Mlb0cuVtWm2lpH7P6Q2LsKW1AFuNEUTLzv2iX58yzhOX Xsp1MMtFC8PM8SFEoac0XyrOuuz1rrBK8yUPpScnrQ2u5JGOjy9aS0G1HusJ v7Y/loZI/x/31bZi13FEv2D/w360BWP1fXfnMUMibEiImQE9GGPCWKMknFGQ RtjJ32etqurLPhqDn8MIdGrt7q5LV1etehFBujQtEwPJ0gYpY2ib98+J0dch 03q0v6MtK9DExRLITOLKWVflotxlILjdrP5268EA3RlBw8vFEN7RisB3UjWc k1gWGyJeZxI1Fpc1y9ohPHNdEE1rl1OxHS7aDkV4H1IHeGhQ/6WvNnpdl3s5 3xzHtipe9vfxtCAaIcQXbS/0J4eGjop1zCcZHDxfvweZSnhpNfpFBtt01TYI wj6BEAQnFN2YOtXXtBB3DpZkXfbZo9ZGzXCSMcrZeH6Sxj8RdITGPJITOtX3 UVTEOAkvPWTyjsqH8iBstBe+hntPhxS6FPKUkc25SM8dSEa+79wflpLCmNXo l8uWILdlhfcyAcgYhl495V7Iri8KbvmmPM3MxNV5cNowkeCjcDqp0HgmQ4bh eugAsngWPOpWOhazoCKvWRpAQLOfWRlCUa5n3H/KUCF8ZCAwooAG8AThJ8PI sxsP0zHNKPpVpCX3FPMcjuKot1MebhmADMNL5nad1CyF2PjCkmGBxK6N7xAP aYxMkzzlcfwA8MJ5fuDoNa07WY/lEeknDvbmPBD2QSi+LAgsh8rYrOOww0Nk oxkij2RFTPN7MMYFDcyeIXt5adxgyCiuASQiHl8gQa2qRzohOo1S9r7M0gDW 3azcUGZowC1rPa2QQc7KayDHtuJiBWgg8NFV0dqtbzL8rQhSpzZDqiTuRNhq tAy5yJigTq0vLLLdr209JNxnmBWZcit6Avj5IiO1fbQd7dSiru+WdA1+hLLe dkdmXAeibQza8X8YTSpwHkxLFyOQUjwt8C7NMKckD3x2sYn0LkYeWextZ3dC ftN4InwEQoFZwdSbyKnXENqeHUlwktI3RFRCYRwTga2eK/oByF3ZYRpUVArM Ct+/c6hirmN/wZVPeWgYiJlg+7uBJw8etsft++3jhubomS6oRDfYHPZP7zr2 tL3dP2wOAnMOn27kFxYQf337jBf1vHv5e37YXr+58/v7582j6jAXQFjx6kA1 UpAR5AavJlTZ//gKuvsBDtngd7c7yftnzjToabHiADKuSl7FAQlHFSQKuJ0M SnAuprGGCKizPyHgi5xPCncbwl5YTwhu4WinXWftFwSKzBf1GvvwqHSgGUjV mQhMNzXKmFKEwLNU+yGTT2EODXVZgQYvtvQTuqw6lIEpwjERPHicgPqc66JD ZeXbakVf0a3sJ5z9eNj+IVoOiQDySl3rAKaWqmMVkWRI3VVWsaknB8qrytl8 bWj8jKG3aGBKE1n4WMXDdlNWdl1dWlaA4eK9FsyUysdNhuXMce7oCJpH0JFJ TsDd8u0PHSZzB6zI6wpY6WE3KJkji+6Ok6IFuwAFkC4oOySWcPGoLyEavst1 PCV9Gi9qzZ4O2NWT4saZGY33fiy5E5wT7twREqsjzuybcr/XiejNzxMsM4aO kTvdiL7ATLTMObvAxBF2yPDxoaQilLkjPXMUGYkjossjc0Re8oZWHrHNvAGf LDXOrIDVGYVoyZuWGeW5gBTkmGnT5Zk2A7G0sQN6TnQNM2vEhjYQsVHyTrNm ON2zZgI9R8jso08vIRa7yxfRZN6Q/eKK1wiT9ue47iNiT4uhWmVW3V+WFWAG eVmQJOpU4nm1Jj+I2igpPVeU5FXO+3+3CRThQxdBPNMJSHM6jtSWx4pfhLcn HwU5eCiGjRh4Bnp/OhYZJVr730BmjIrc4gsIH0ZQxHa9gLDotx4zRvEFZOzq sf8SWW8IvM45q4zKCwKfv7cUJvMDy9aMzoX0C2SrhSE/CGHLJS8rwGmrVr7W TGzy1JvvnLdJRh9RYt+B3tNICoNVwmsEFa8eJwQsiGbCLm/+i1Z0Y6l8KpOf kuEdcwX5atMVQk8YCT5VqCg1Gwd2lSqKeHBZkGFY4Lj0IiJRPvou9zKiUZeb AAMtYk8RlqHTRdWC1lgjE+IpFZG8Ed5X/U2iBZannUQYpMtFdqWgjDIdWgfR P2Q10qnFgVyE2TFFCthFxqxHVuqqdp4DXZDaorURyjoKgWLNFRHPJFgvW0VU raBziyGsa77JYCQOMGn4eroKk40qH+uKQ2ij3B9mrSkPHQMBUU1JV3hvEU18 91cxvrALIECH9A3QSyXGaSQKnnmKRgadRGtE3mQbP2JYVvApBtmf8iGukmzI +YdR+kWjNFgUET5JeXRNGCNqVUxVUoRlHVUlN6UsfH5ThjLeyAkAa6BcnD2I ehbzIRt4/QIUthGWsUNbekZJmTLCOzY0y6RcuYMsXdlcZKuCCu/DkLnD420e ywrYVvSE4tsic0JQHR2BmYiHZzyc1hbyZtrgvBYnjqNqlSvRELXbWySRACKj NpiskUqIlFawVIvYLUyCDUisgh+lDdmsyn6uoL0h6o0fccozVgPBezDHs7cW nKcKk6miWFfvK0BvpAfbAV2ct9ERZFmgn3jVwjTY+9J+nVEclz7+ntHm7SvM RsGjOAbjLUeSxs05NA8keMTzMKJCftZlISpS5weCnZxtfUStUHZaG08Av6WF wkNkAzprigIEki0YwfbNsuQ5MA4ZDC9Kh10RlkjK0mvSPKGnqBmFJPZaqEoq YoT3mpI0bsrTjY6AquKGaGWyxtNYcBmq3mm0HHsUjrysCHizwU7Iiwh3nagY CMzEWwy+SpeTyDQvKl01xhYsUk4GKQBerW49lCz6kGvpG7LtUEZ31CA2+6Zy SW0f122ymZT8XBHY5DWyjuxnyCNOHekJ0U8YCXNOKSakR+lMfO5IXmUfPrJL KzNrrFuRnTIKy0KhXWTkhOTAiji0NZGFY0EGFVdZH0LTsTSRKugDj+TceASH 15KO7j1l+JYkGhNJHDE8KrwvRr9wIT5iqEhpyDQqwtm8rEAwrDYmFxe5SuJy hyE086CjqGupSWjoBVRW8fLogwPpgNPYZY4abEPC2w4deCCH2EwWDUhHaaga Vu0WVgci60oZMlfjeKkntiKw+lelt+wXXZ5BGogXxjFOyJgj46LDZLoQZWLr CxL6YczzgCHPezCETTFxR2ZWIzeOph6v2cQM+x5FD9HzSPoaUOfAtQOrnGFP 21tUOwcBOVfx6UZ+sQwCf337nPfbu93J390tFn6HH//aHbT+unu3/2X/4Ue3 /7y9fnPn9/fPGyxl0c01y108bRFTQ8CJHblsd7AJa8cW3AqJO8zhbBX2CF5K 025QPhF3mPL4avvj/fb6z0iK/f5xq2JN3bHWs/vcP8Gu99sN+z7Kyf0DxPtf tx+++tunf7//9Penpx3lZP/2/nZ3sCH+lH96/PomYyhsX33av/3w+d2nD+8+ f/PxPz/vO4YR/os7rvcPaCr73bt/fn63h69/vP9u+9M97H7z2zGII6byS8iw /BAo6q/LhptGWyh97RRlg1RuFeVrclO88OAcUDVDUi05OxGoKOfxIQ5hqpv7 BjI2d6XziK53nnPHbIC3SAePVPjrhgUMwP+923Ln36irTEkUXaSdo8LipngZ XzNqi1lkCzrCEXSvKCixBKEUe0WNoABjchDV8/NAxpoYiynUeA9RYtjF7uBc 0IPAeNWc7HzEqwuX4fn83KMz10x96n4KJ/eHiL5OXhxZbzPltM+tUlwj2kMM pX9z1xuXuHLxELELLWLuhnmLUUUWm1J+mgbaxtXihxmeeWEpXF3YREAcRbec j4YjC+YRKk/X5gp3dcA5J6Z/GapcLMO9zDFp1WHycHIs6Db2A668eJBMGxeL ujbvVAQ0Tg56EqOaNP+4xX6SbMvFdAC02zbJr9RXUeAISvatG4obh9lPjn+q qH87xq7FsoeZ/jMjc73KyImINSVzMpt2jiOGIwW/SEnHilROBwxxWDEQNXEc YNb/T3Ar4N6DOwKuwgLVBDRfJOMpWkfLm9HyZrS8GS1vqF3eAAQYAPOq2BMN ZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMTI1IC9IZWlnaHQgNDUgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjQ0IDAgUiAvTGVuZ3RoIDExMzAg L0ZpbHRlciAvRENURGVjb2RlID4+IA1zdHJlYW0NCv/Y/+4ADkFkb2JlAGSA AAAAAf/bAIQADgoKCgsKDgsLDhUODA4VGBIODhIYHBcXFxcXHBsVGBcXGBUb GyAhIyEgGysrLi4rKz49PT0+QEBAQEBAQEBAQAEPDg4PEQ8TEBATFA8RDxQX EhQUEhciFxcZFxciLB8bGxsbHywmKSMjIykmLy8sLC8vOzs5OztAQEBAQEBA QEBA/8AAEQgALQB9AwEiAAIRAQMRAf/dAAQACP/EAT8AAAEFAQEBAQEBAAAA AAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoL EAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAIC AQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLh coKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMR AD8A7tJJQJcbdu4gbZjTxTVzNJDbbpBEuEzHkn9VsEwSAAfkUlM0lD1Ic+Ro 2NU/qDQQZPA+UpKZJIXq+4nUt2h0eCmbGgx4QCfikpkkgZ1j6sO+1hh7GOLT 4EDzWaz9qt6e/Muyi14YXsrDGeEjcdqBLLDEZR4uKMfVwC7sn6OyksXCd1PM wTfXllt0uAaWM2mP7KudIvvvxC7IO61r3NdIA47aJA2meAwEjxRlwS4ZAXd/ Y3kkkkWFSSSSSn//0O7USx2/eCOIiFJCsaA5p/ecJ+5NXL+kAQRqRMz3nVJ1 RMgGNwAOngma8g7QJaDt4KZjyGtaBJgnueD5JKZljpJBjdE6eCYVQQ5sAgkx 21CiHxYYEFwbAPzUjYRJj2tIaUlLmsndJ+k3bwkK4cTprE6eCYWPmIGri37u 6mx25od4pKYZNddtFldk7HNIdHMKtnWMf07J2aBtZH4K64BwLTweVS6hWyvp 2Tt0ms/kSPVfjJ44D+uGt0F7a+mBzuN7uFoYzKmteapix7nun953Kz+gNbZ0 3a7Ub3T+C1WMaxu1vCEdgv5gn3so7zLGy1tcbp18FJrg5ocODqmfWyyNwmOF JrQ0Bo4HCLCjsvZW7a6ZInREUH012GXDXhTSU//R7tM5gcRJOhkfFOkmrltg BJBInUjzTCsCIJkTB+Kkkkpgamkk66x+HCf02z8TJHiQpJJKYisDWTod3zKd rQ0QOE6SSlKrldPpyyfVfZtOhY15DdP5KtJJGuq6BmJD274v6u7SxulY+K4O pfY3WS3edp+IV1JJIV0TkOQy/WcXF/W3UkkkksUkkkkp/9kNZW5kc3RyZWFt DWVuZG9iag01IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMTI5IC9IZWlnaHQgMjUgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgMjQ0IDAgUiAvTGVuZ3RoIDE2NDggL0ZpbHRlciAv RENURGVjb2RlID4+IA1zdHJlYW0NCv/Y/+4ADkFkb2JlAGSAAAAAAf/bAIQA DgoKCgsKDgsLDhUODA4VGBIODhIYHBcXFxcXHBsVGBcXGBUbGyAhIyEgGysr Li4rKz49PT0+QEBAQEBAQEBAQAEPDg4PEQ8TEBATFA8RDxQXEhQUEhciFxcZ FxciLB8bGxsbHywmKSMjIykmLy8sLC8vOzs5OztAQEBAQEBAQEBA/8AAEQgA GQCBAwEiAAIRAQMRAf/dAAQACf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIE BQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQC BQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMH JZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU 5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYH BwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF 1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A7bq/WWdO 2saz1LniQ2YAHiVTHVeu7Q84Es0OgdMH5lT6/wBIvzHNycb3WNbtdWTBI5kL NxeudRwHijLaXsboWWCHgeR/vU8YxMRwgSl1trznITIkZRj+iQNHZ6z1S7p9 dL62NcbSZDp0gDwjxTjqdx6N+0djfUgnZrt0ft+KzvrLcy/Ew7qzLLNzm/MN RG/+JT+yf/PhQERwRNamVFJnLjmAdBCwiq+sPVbwTTiCwN52Ne6PuK0en9Qz 768h+Vjeh6TdzJa5u4wf3vgsTolvVK2XfYKW2tJbvLiBB1jlzV0NFmfZhXnO rbVZDtrWkERt8i5HIIiwBH7dfsRiMjRMpbHpp9rj0fWm911bbqmNqc4B7hMg HvyuiyL2Y+PZe/6LGl3xXDDELsA5bfzLPTf8CAWlX7+p2ZvTsXAZJvc4Ms89 ujPvRljiSOHQXUlsM0gDxGzVxbeF9ZMrIy6aHVVhtjw0kbp1+atdY61kdPyG VVVscHM3EumeSOxWJjUDH65VQ0yK7mtnxgqz9af6dX/xY/KUeCHHEAaGNo45 +3Ik+oSpsjrfWyARgEg6giuxW+pdXycLExbvSb6lw/SMeCNpgGOZ7oNOT9Yx XWG4lZZtbtMjiP66h9a/5nFn9535Am1EziKj12NryZCEjxSuh8wpu9G6v+0W vbY0MuZrtbwWnvqlg9Utyeo5OI9jWso3bXCZO1wbrqufcLei9UDhJYDI/lVu 7LQ6I9l3Wc17DLHh5B8QXhKUIgSkNjGwiOSRMYk+oSqXilt+sORbkmjp2P62 2dTJmO4AiArfT87qV2QaszF9Fu3c14BiQeJMhYmV0vqXTMh2Ri7nVgktsZqQ D2c1aPSOvvyrm4uU0Cx2jLG6AkdiEpRHDcACK36qjOXHUzKJvb9F3kkklA2X /9DtupW9YqvY7ArbbVt97TH0pPmCsjJxut9XfX69DaWskBxG0CeZkly6pJTQ uhw8HF+LXyVZ4vc4b1/dcDq/Ssh2Fh42Iw2+hIcZA7DXUozcLKH1e+yemftG 0j05H7+7mY4Wykl6+GO3z/in9XxTq/k+leDyeFi/WDBa9uPRAeQXTsPH9pa2 C7rFteQ3PYGyyKo2iSQf3StZJGd63wX4brcdaV7nDrv8rhdJ6XcOm5OJl1+m bXHaCQewg6T3VfonRcmjN9fLr2NqB9PUGXHSdD2XSpJH3Knt4/2KHtXj3/q/ 2vNHpef+3PtXon0PW375b9GeeZU/rB03Ny8tlmPUbGBgBIIGsnxIXRJIjj4o /LfDp5KPt8E/mrj123ecZb9aGMaxtIhoAGjOB/aResYfUM3Dw4q33t1uAIEE gea3kkNeKNcF30/arTglxe5VfpfscrrfTHZuI01NnIq1YPEd2qn9XunZuJlW WZFRra6vaCSDruB7EroUkBx+2duH8V0vb94b8Xht9Xn3Zn1lpkHGbYJIDtsn /oOCh0vo+ac/7dmgVw4v2CJLj/V4C6NJHXhPDwba8K308UeP3N/TxbWpJJJQ Nl//2Q1lbmRzdHJlYW0NZW5kb2JqDTYgMCBvYmoNPDwgDS9UeXBlIC9QYWdl IA0vUGFyZW50IDIzNCAwIFIgDS9SZXNvdXJjZXMgNyAwIFIgDS9Db250ZW50 cyA4IDAgUiANL01lZGlhQm94IFsgMCAwIDg0MiAxMTkxIF0gDS9Dcm9wQm94 IFsgMzkuNjg1MDQgNTU4LjQyNTE3IDYzNS4wNzA4NiAxMTUxLjMxNDk2IF0g DS9Sb3RhdGUgMCANPj4gDWVuZG9iag03IDAgb2JqDTw8IA0vUHJvY1NldCBb IC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YxIDI2MyAwIFIgL0Y1IDI0NyAw IFIgL0Y2IDI0OCAwIFIgL0YxMSAxNDEgMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgMjY4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAyNDQgMCBS IC9DczEwIDI2MiAwIFIgPj4gDT4+IA1lbmRvYmoNOCAwIG9iag08PCAvTGVu Z3RoIDMxMjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl8 V9ty2zoS/AL9w2yeqC2J4UXUJW+O43jt5CTeSCfZLfs8wBQkIeZFIUjbytdv DwheZGtPpcqRKGIw6Omeafwa+KRosCDfnwc0DyY09v1JQIVsnqWDH5QNPHxZ +DTHT2PzCS/w8/erwduPU/JptcECD/+wbB65oT8LKZpO3Wgxn9MqHbw91xHF 2rzikY4Hby+XPm01Iq9i/vM0cILh6ifCRXU4v34V/01nbjiZTpCCP3MXYeBz wLHnep4XmNWuF8zmHOLWucoeVSlKlWdU5nS1Ovfnw79W112WHo0DN5jOZrT6 YIP4NkgULmyQkpSmvCpoWwyx58yRoqR9IoWumgccXvFmkg55xd/KnaQLtd2V UmblzuyKzXzXD8M5b4YdZvNJk2Ypi+GYz+NkJl2R0Gro+x7HHnpOIstCbOq9 Niqm8zxrc9Ga7hwc7W44op1M1siD3ssiUdnI7Lr6J/byvWBa73Upi1Rkh+Es dOfOiDY2TJ7SWbWtdEmhjz84wFLuS5ney4KicjeiwPNCtxcw8AzGzgrnxO7Y NeYFZnt/EUWEjNeqPktyoLUUiaYnVe4YGS6tCQO8ozqvtXyUSb5PgRblGyrl yzNjWV4cSGTYotQk9vtExU1tm8S4hH4Qmsy4Amup1TYboVoiy1S2NcvzvSzq hXajOE/TKkO0sU3MhKmD8Gv6oAGFHlEmy6e8eMAnjqNl8ahiqV1iEPL7nzIu 1SM+bbrz+bPAxDEQacb1vuA8ynwrkWBBe5mDSsRh+TnQ47yb4497keaW1AzG RnGlQUOk/SgLDaAlspK/KlVDiBpXGxGXLUOLOv1xr4TR1DKcN7eo5MXx4Wjf EORRrRGETyAzcY+UuY5tMGhuVgeTz/FOZFuGgbBEaBNOPiO8kiCJ22ihEx5r YRrWyxlKfw6aWMQ2eVxp0Cq3wOR7HP/NTS8rhu3f+fJIYos6rI+4dVjg+i/J KquXbWUm80rTBTTbPMsYOP2mrmarvnjHxEio3bGPYLCw4beFSFMJXaapKiF5 amCPJeqDSoFrqNMTBJpyvlmV9uJ4kWcq4bDaAFsIbenqPlVag37g14dKNj1F 7wWqkqjUNjY96ihia4CjQHFAgfZizzWL8wpsuZck4lqkLvGilzXwas7ftpru 5dAeaAO5lCaTuCqahyBcT7/6VClCP2orcaQ5PsQ7ZMrtYpuS3qmN6T9XN+2e iUDOPdinoeUakquY97sTpbVaJV0WVU8HeFtL+cDEKnohm4iZfGp1PYK6YlmU QmXlASk9CRtkrelXJRKFp6iWfX10JIa6OfaFlDBAlOaZgsjAAfdUCTAtuxLE x11ecSFTNAvGGJy6RzMEbhmirpWGSrhQJ6EP6piQ0BuO+7Hq4OAD0B/5vYKg P4hSGAq3ddHv+o019BqNGnHMO3HwOS+Qbp6ar2d6D5LoNyN62qkYHV/ED4nU xx0jDGyf3uWllTW3Y3Nu+azQcQG+UcNl23d5o5buoTez8/PH57MvUMlZlpuW 2gXU0oDC0LVAohwA76j64Xwxa2CvCr0Wdjy6dJWRWNdjDLxRz1Ttx2U+XoOQ VFZcyHqsJcnJ6usnpMPjls9xYAuBLpuBPFIbeE9xwA/8oEkGebMOxRYUPFag ARMbryVGRkt+hD05PE+xwps0h5bZVmXSTIhC8Odt3xbcCw0kU4H98MfU147i buxy85g0g1wcaogOdDzAm204/r7AbKo1xtwBdQBIWfV64iSc2glcEwc6ZtAt RURR8qhkU8KP8qz5pd8M6ypsqmwtWDKc+MvGo2E+zVQ6WQovnLRGEo1Xdfvf N/gICJzJXlTpyPzSzEuZx3G1t5vAEZyaTqFnK13ahtusTVFvEPpGFuAp+AMh 9NEDXKXKQKIe/r5nxcAWQ/LAAfdxahCUZN0zGnMhu6IofnxfqWRtzVF/uEX1 UML+YisbY/YCvkaZUJ8pk+4qMJlMpk1TtfLdCdijey6BRCdse9Cp9t3LhXtP EFmy1i3weQQTyLJGU836oVS6z9GxMx5Rop5TDQHG/XiN7WRW4HdZ7FVtEBmj E76z8cuQbiWNgWsfL5xXzmrSdEozgYBfctCqNkJapVVSu88UDjBfm8aOIdW4 kK4MzRVqMg9cOGr/6ArVuymFDHl3QQqnE3fBd7MTN6TmcjOJbGn0rvEGcGjd sKl9vK7QvAU9sZQZTT4CHAR6Kvxfr32GzfQ0HiXXnf3Re5CE3+aGa9040Bv1 /Cl/fe0jzeg0zDN2qWHZK5E6S1lfuXDL6G4+/6jvjr5f3/IQ+dY5x/QeT51U Ym4LusxlscXFaTVc+O7UaVv5+U6o4m74Wq63znUu4p1K+RUT6Tc0+qBG9E0k G/osdxmswohudlUekwk7c9BOx5dKNMe7deyGR74yf2UeTRL6bkhm4cVq8PZc R3S+JA/lDI/+Ls+R5jUK/5P8ievPQnpiDvxBt395tB5YLtBiNnF5XKaDqRe5 i2DRPkkGy8F77PAxqrHqeASOuBMPbFvMPDcKvWlHo6AjX5u1ZszHC5A/iGgc Yqk/ZeCOideU9+JZxpW5LbUBXtX29V6My7u6ttM63ZCtGwvl/+3Uq1siKsyb D7Iqddy3+EPPSeQDRt3Z5Yje51ltolpExnaPfu+uIy9l3BC9FOBP+c6utMlF 7jyANDw7TdqMvg+jyMl52wf4gyXfl36PMAAu337/cDGij6DNw6Yqyhd52HC9 PHoIgeB5tqnb6NQx3unrpv6CLiZfZLZw0VCjV7DdOt8q3BhK+oYuK5MR/W0+ NsirWtt8rowvGftz13cy0/HYGq4flWbzcJ7DXKsEErw6O7eCa9M7QQOb342o Erp26VMFwY3oUhbGXt3V3MDn09r9zkgsHPi0A1qEeKAr3MYwHpkOWSrQpO/q d2YOe/UXwYx0b0RZYGAK+qGKcjeiP2Hk0SaXbEs0lh+T4dAtPQLlT/SKT3mH Cz6ZBjSi5ZNcY5a1LamoU5ZCV01Ri5dBLShnHI5fhg26ltmLczWHoYsU9qGs dIt21KLdlfDW+dLU6pvsJgL7J5ar/ptCOR/Eo8JF4JG3QSs8qzDWcE0SVtld QbgZJ7mmMxc8gLGjL1XGXvB9IX6rxDqII9yuIeD/MjARJsOIzjEZ1uIEGM5/ kPv2p8JxP+MPJs35TmXChkQVmzkL11bgN5nmcD81x+N2pjmfK7VV/LAsBZQJ l3CwIZxPuObo6kHSJ/EkcFtN8cK1wD2seeFrluVoI8/8A1+3vki+lSQYaLpN 43uC226qCrpy8Tti4Ezf+AbXnsn5qmNRYE5lvwXuTuNlXuYgyf/Yr5oVKWIg /AT9DrkqTEznr9PelIVFFgUZPS9L7+wgtDP+Ib6yb+FX1UnVdB88eZKBgcmX 1H8qVdVfMBmqMzQ3mbuDTCc1J+/QMx/Pn0XUa3QstO+bM8zdJK7IeouGjC/J 9gjm+fdp92r+8QAjH05nqk4fdx/0Nbw54kmTjNPhZ9NOJDetZb3venPsXtzu 8fcd60+mC6N1KWAsKb2l+ST4weIbcNd7m6P5duieni+tqLbtwp2oGB5l0Nl4 6jmuyvxST1sPNXhTPEejx7lwn+6fnu3SOOJhINBUjTBH2K+/Ho1x2dIvGNP7 l34wZn+g6T4263tzK30VzW/TVEfywaOZ8ioVNFFe8FZYVnOXQ7R+yI1WITPk LJBPo1M4k+Dksx18XLSk5BiQopTkIAhQdconO8LclKqIplfl7GnagLcYN3qM F+/QuTwF4L93m+/cLq5SSoZCaedIYXYKZzlNoTSLKkHbmTsM3WUoNmTykkBw DGBM8qxaj2VHaELIVeESb4Ecwwabg0rQgkDxKilW+YhXA7N4rsctOkqj+hb3 o1+5LxCfIxnzIYo6vk8IR6OsABMkBRt8bmduy3gRVyIWCK4eBUK4Yd6FUZmJ q1I6UgMr46XFk4ZHLyz6zYXpTrKRdbP8FDwTqIgFq2tK4TYC1jmh/iWociGL eynGtY6KxUkhaDY2ARsvJs40uVjUNb1TBj0KsPGRY1Tikn/EUpdTR3MGLqZt 9Kkx8So2KgKgxOdDY8hOhNUljKmK2tkgXBeWTZr+mpGpbDJSd9ianJJNF3aK CHEkYzUi54Qi5pUAgWKF7CwmioBqvagQ98QIoShrCRsvpr+U1mu9udaba725 1pt/XW/+CDAA++PG5w1lbmRzdHJlYW0NZW5kb2JqDTkgMCBvYmoNPDwgDS9U eXBlIC9QYWdlIA0vUGFyZW50IDIzNCAwIFIgDS9SZXNvdXJjZXMgMTAgMCBS IA0vQ29udGVudHMgMTEgMCBSIA0vTWVkaWFCb3ggWyAwIDAgODQyIDExOTEg XSANL0Nyb3BCb3ggWyAzOS42ODUwNCA1NTguNDI1MTcgNjM1LjA3MDg2IDEx NTEuMzE0OTYgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTEwIDAgb2JqDTw8 IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YxIDI2MyAw IFIgL0Y1IDI0NyAwIFIgL0Y2IDI0OCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwg L0dTMSAyNjggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDI0NCAwIFIg L0NzMTAgMjYyIDAgUiA+PiANPj4gDWVuZG9iag0xMSAwIG9iag08PCAvTGVu Z3RoIDIzNzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIns V8ty4zYW/QL9w11SKZnNt6jsJNntpxynpU6m46RSEAlLsEjQzYcd+7vmF+Y/ JlVZzBdklcVcgAJAsd3JTNWsprq6yyKIi/s89+Dy48AFBoMJuG7sQewFcOS6 gQclVe/ywffABw4uJi7EuHUkn1BAvJ+tBm/eRuDC6g4POPgPj8Wh7btjH8Io ssNJHMMqH7yZVyEklRRxoEoGb06XLmwq1LxKxJ+ngRUMV/eoLmzVua0o/kRj 2w+iAF1wx/bE91yh8MixHcdx5Wnb8cZjqeKs4EVJymdY0HxNy6rVuHfQgSPP 9iIhejy4teYZzSmv4Pvh2Ldjyx46FtyUpK5HMG2quiQZI8OfVhfinGu7vh+3 5262LGMP8I4lW1IO0aWxlVYjmBNO0vbA6isUu2A5fPP35ZY0my2nVfXcmukL Whck+djQCq7ImtZFk2V0BG9LwhMqnJeqbhgt95YoXFE4JVmmhZSeBWlK9sIK OP5XwjgZwXlNsue9DtwtcWtWcIyP9fZuSJEVkFJ4i2Z6B2+tBcOUNjDdsWeS 4+4FeSBcWz2jfAcrdp9jBlZbCte03tIyIzytlPorSnlKyxoui6qm/HNybUE9 UdBb6yRt2txGVlrAd+0TyzJ8OXHxcSSKtXwgTHvSwcOtNaN8U2Nh/QhThsnC av6ej2D5RFNqfD8mjyyFZcE326assOzvOatpCpeMb9IiV/7PscwZFmheiNK8 LrOs6SOFpQ2XpH7RQsua1LTq6zm24YYku9elbq1T+vJPOC2ql7rgGjPnq/dH K+34FPOGOHhildpRqSZlBSd88ygBIraOD3oKkRzYoR8GLZJXQ9d17IlFky1n CckQ/i3Kik1J8pxiyHnO6ppS1Qemf9qWxZhYWX3dbzPZLhMpZnrzoiDJFptC 5OGF8WqHOFyytgenpyNYNOjEVufhHcnuMEjsnRJL07o6bl2tEkQQZu8RO5zV v9VwrLqj6tRXdGpTJHgUITO2sFuOThkZmYPPUNwhSCS2Glq+rJty6Ak1G6Ni TsqcZqwmcPq72u2rmCnrGAr8aO3tNXVRMpJVIHP041Dq7Faiy0XnvKbl8MiN LWxQhl2awepmDvszvcTueWih2CcpYHqfF5wCvqoI33cwaLxcbpHLUphmRzO6 wZ7poxgUfv6xozAtsSuqquCqX8DwkIJH9UBLjIvmRcM+ZaL5tmQVzLKCpyLf M5ptWGOMfMO5YKJfBJn0qEDLXBQVxbwS5LMR3BRl3WxIpjbPaPnENrjdcEqz VwxkG4IsW2HyRy1JgGkQJEnEdVNv1xJXryfiVtjICeeCFReUlm1JPxVXIZ+k ecNTSaLLonkhgL8sexTRiyAy7cAPa7bhjD7BMYbGBZSWU7UnyoTKT7KKPNN0 BCeb54dabKqbNYg9exKG7sHN2rlAQyFs7k0/CuyJuLL/+uLE2mKpSzjJq5qg 6euifCIdBLVUeYKgZwf3o0nYkqr2wHskZSnpw0IwW6FlKniLza6vOjik8f0t gHDeNUKSphlVzK9R+SnxW1cN2zChsq6J7oJXrpczu3N94xWDN6rAMdbiNbXI Rd27Hs5IWQrq7WRBxyjC2cHZH2ukrWEYIHkfLV/IWiJj1iTVoZFbS15tE3G1 PcOM0B2cC2IRt+Qx5TnG3+linG2qBjv0kjyRCplUXcadBqVII3BJ9b3xObwe EwRhhjfyXS74QvqklHyQVBtbYlbYyovm0ejrOG/9TSAYLhjBv1fiL842Wxw9 Xk35JV5+KMXTdQuUCEHwn5R0IWCSIbPx9J5+fsg4R0cF+23lzff+Ur0/pmtS IRstWC1GG9NtiNhfsWNLWBQZ/1U3+FnDNzg/dsY4g1kUVUzPSqJ7XfW4OTMV VC7KipQ8teGaZS2fCuta6Dzb7YhoNE2q2AyMi6iM0EyhruAgi1tJbKDdegvT uxJvbSMsUiUucabclNzZVSiH0neFoL6qN2Vis9WY1SfcxoF1DwpDh0x7uWWw JKwu+pPgcltsqdgzW+o0oo0/6yu8kkg5E9hBSHfu2jOCk8AjEaTLkdTNdduv uTKJkezlsYyUfQ4cgkh4gyD6ro0Bm43yo2lWkxzryIvR4SQpa54TLV2iXPFK bbBP/BiLjB8Otmup6MTKs/TsqSheuXxDcC5Fldtufg8aRZTog4BjaIkqHH4t HLDSGUsp2TH4sDctasM/qcsCX1P4AYmjlL1uvm16k6GZR6zrzhDy+dkOC8sk 4cxIk/eHolXb23jblh2ECowxUskTCIr/aq7rsOZpw6XdIku2fcMnovYbLPB1 o+eyNf10spvyVO0LhxAIaS36P18XWVp3lCruQ0RmBiV/Mc5q6F3osRFOxBfp w28YpKabPw9/8QfHV8bklN8T/EjL0jZ3S0Ikzru+otmT1eDbgQubwZvTJf5U +Mxg4E9sJ/RxFIhdW8wEPjrljWOsp2dHAZR0cPfVYLbCUrttqWM5RsQg54ex 344am4PxYT85lO3nArixjd8cc3BC2/F/Dn++Gx6Fkwl2SAlyvuW0tj/+kgI4 kS3++wCu97U3BlhSvKYgkoGi+y6covILNH8Pjh3Ck5hmFnD7kwMpBiKC8CBv n8IYsoF8kK/89ikbRH6A8UVK1izlgSjSS7kbOGaZCcWhh+3rBa2VMHTkQhgK Q73h64UxZ87pN/qwMmpUKLtGz3LwZl5htPMlVmE5v8YZzRMJ+L8PW9bcbkMV kMSvHISdIwxGjllmejdE8t17tBdQb7IBTrrxOLb9SEQpFr4jF+hM6EnTZlu/ 0TI+UndrsM23XsocqqUK0AioJIh8xTj7tfoxX2qR6cjNtsqOkTH22vAD7yB8 vcRvgAg/AZCM8aNArAMwR3GRoCbf9r1I7Tn9g528CmG9xFMuMoQ+je51nIqk 8N6o2DIO7g92PU5MekzBAq9XMPMmtANpW+oPfU8KGBXt2oRmJJyegkNMmPhC NOX4kQ4vDIJDG/u1DlILKB+Vgl4UiUSaLizymqmpXLjIwOAFMkdx0OJPHNk/ JgPxMYKFUS/cUB2ST4GSEguUHAegDkSOVrZ/RGf2htTeWJ/qeJYY+BtEhnEP keaN9CYKQzvs+KlV6EAifJog5rREEB0o0EvthX7TuqgV7L3XJnR42gktER9q 6EWR/Am1fuGbL3zzhW++8M3/mm/+LcAAgKXgTw1lbmRzdHJlYW0NZW5kb2Jq DTEyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMzQgMCBSIA0v UmVzb3VyY2VzIDEzIDAgUiANL0NvbnRlbnRzIDE0IDAgUiANL01lZGlhQm94 IFsgMCAwIDg0MiAxMTkxIF0gDS9Dcm9wQm94IFsgMzkuNjg1MDQgNTU4LjQy NTE3IDYzNS4wNzA4NiAxMTUxLjMxNDk2IF0gDS9Sb3RhdGUgMCANPj4gDWVu ZG9iag0xMyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9G b250IDw8IC9GMSAyNjMgMCBSIC9GNSAyNDcgMCBSIC9GNiAyNDggMCBSIC9G MTEgMTQxIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDI2OCAwIFIgPj4g DS9Db2xvclNwYWNlIDw8IC9DczUgMjQ0IDAgUiAvQ3MxMCAyNjIgMCBSID4+ IA0+PiANZW5kb2JqDTE0IDAgb2JqDTw8IC9MZW5ndGggMjgwMiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZRX23LbOBL9Av1D1zxs0VsS TRAEL3mzlcSeJE48kbKpWtfUFC1BEhOKdHixR/nZedlvyNM+7AEoXiV5suXE JkGg0bfTp/vbiFFEo4AY823ybYcmjDk2ZbJe244+UzKy8BIw8vFpop+wQa1f zkfnr11iNF/hgIUfHPOFyZnHSbiuKQLfp/l2dD7NBS1yvcWifDE6v5oxWueQ PF+oX08jwz2bfxmxagf+uJ7JHdfBzcwzA24zJWdimZZlMX3ItGzPUyfvjM9n wjPSeLUOkzW9jvLFRmZnATM9Y0xTvKZ0tb2/Pvt9/gZ3TZjJOA9o/hInp2G2 lXFUhHT1IzuzPRxZj+lTEj3KLI+KHaUruszOmPogtzLRMub/xMnXWZh8p+sw K2J5P6b5GbN90zcms11eyG3e3hiY3oFNls/NgLlC2XRnXKblUj5FXxKIw71f 06wY00UIK5KBKriFWbhFLjZJGqfrnb7hiNMszzaF5wXVBdNNFuVF+rCha5ll 2zBJxnS7ieLoIaePMpfh3sLFprYP3mVIB+3dT3EWLTb0NorjsBjvdfC0DtEi jAcqXofb+7J25QT+ad86wpvQfVqm9DaL5LqN2GlX4qxxG5YxvTHp7X83yTBS s6IsijVColJJR+ljGK/ondwkMhuqrrKkPf+fgl7Wcc6X3UBfybQ2gD7++Cvu KVqJS9LHqFLzH9PUfHvVHp4VchUmNMOFUt7LWlArYxaptMrpojlkXIdJPrmV hczUuSe5knFvX23bDaISyphmP+I4aSW+KxcyKXq2qlSJZN+R7fl6J8Ajq9y4 iBdhgS+tUhXwbAU8GBUmyyzcn3MN+LtKINeQcRyN6f2rae+qDmrvjNtNmS5w VmsLDE2uonAYx8+VtFJm3w+z5854W2ZFLaEsEMev5f8p4RLumjDfSDZ16i8L nOGuckP8VT4LP28Av6F79nhBUXIrlyBuY/rXmXBwNF2GqzSRg1BcxMiNontE h9Nt0OAZkzPLuEnvo1ie9u3FMtxWQlQ5jPLvY4KlcfTTdhg3CGaUhPTvqED+ 3YcKNf2zb8MszrNyI1UevpqDQdQPSjp3HTPwVe3hwnR9j2zHMgNH0ITjwbe5 Yg1b2Ca3XPK9AEuKX1aqHvhU/9eChGnzvSCHe8Rsy7RxfsIc0/W0HJzS5CMq 8mkrIAfrOL7D8WwLU1S00dBOL046g3xkUJpFKGNzRtoNsGmgkANKc4Q3VMju KuQw1PnAbq/d7nVsVXN8xMVyveOqHerj1Op0XFx7Bgp4qs7XnsFJ2wqUIgJJ HAj/UJGGqbvO8mpnMWZyzwmOeEvnlmEFLzi4kxh/YVm0UcHXVGorHjV+zcIv hLIQSZ0W568Zq+7CHtt09J4PD4Wmi/eyeEqzrxGoGolZVInUyrozbJYXNEUN KxVIQf7G7sATbUh6nrC7nnBsAM4PKHA5bBPPOcLxvTo0xxxhMEdZDes95YVN U4Ln0TYtNju6Mukqi1ZVKVnBLK3wMTeAktKyUMbfww8SJebXpFDVyDUSWbQt yt4XM1n74DFaSLrNwDRLgBG6XDQcZUBEli7LRRGl8GhaO1V9ukwz7Kcr1POn cKcEFOkijWmP3hPQC+zAFEIcQ55rOaYlXAp4MPDqaSwGAIfLjyXXCSjaf4PE vn4DIAJl3G3ufAaHx9Q61EWchGGAW300yc+gcKjFcyAMLBgX8JMQHCQhNVl4 hA/p/Ag1Gej+FMHTUtKNRFacwmr31j1c6dVqFS0i1Vnc2reTIWb7eZoTOgSV hVHW9Hy6x78Jk3CtGpliyB5NZHs+HeBZmGpM4Vy76WfgfMylbfd5rKgpzEzR FcQw4laqMpUfeImbrq5oF0u6Ri+z95A2eugXiFilGt1wPAD8a56XMj+R3XVe gSt1Nh9Bn/CEGbgBRjExcMJp9PmMm57w7J+HH/8b+PUVPAq//aXPwe+oXofK uCfx5yMvWh9Bmu+7XfANdXgOfF4AoDJ2zElHCbBGHzJ/SyiyoKzz/VIXcR+S JFXTymX65zYc7KjkfsTsl0cJxqD3ZSK/T34rZfQlbLB9TjdppsbMekJL48ll GCvKOE0x1zJ83NUVIUTjGMX5CxqQSy8Dmjw12T5Tb9KljKucPmw1DQwmclnG isdeYpKKHvAo81OgbgNl9wLluL5pBz55FvKJ2T8F6aOBOkHQxvvoK8ZcehNG yQGKKwzPN7AhV6Q5TZNcceuJruQlorROVAcc0udIQ1qiSOQNCVfTKsGNdFPG RbSVyyjce+R8mguazqhSeDaF5Dd4+AJgCXpS9t3Q3e8WLfvNr+qit82SG6A0 otWJ+w1ptaleaje5qH2uF3Q31Uvtpl7TrlrbahP4tV3q7tp3W91d+6V2V03O 7aZ6pbNnX+Y7e/Yr7Z66yrR76pXOHivofsdb+80NhMlYV9l6JR7NemkW6LAE SDIbhUMwEqidIvD9KsmQ8BV9eU3XFHBO3d8IKfRn0O2JWncxxYh+z131UqPC Qd1GFE2HCb3XMR2nSvXenHe7rwbpOgu3W6lTEJmKC7hiJ8di7gDhmvR8ZURb YM/wnRn7MluJdPsiPZMzNC8QyVxFmZrpy2QZ7qphdkwX5bpE6eNsTLZlHeUN uKaJCNwKLToBqRb2zuiWZd+0HEud4Mh9wH7ogiF1T2xuoTBUxgWdoa6yxMLU iaYVJdJuLDk5kJBdnRJaHUHCQhVgOOY6iLHdiYfd5kauW5rWBGH5psfAbq4D kItAqFNGNdbs+sVI0Sf3uCIxk3HVkPZasLZhuesOWmN6Vy5UP6ZNRjVabJI0 Tte7quyP6dPsYs8RbociavvVBdzXKdF4IjnwxEOI6DJBOxli6NiEOcYWzCyr dFG2PWCtMyTCJO0MuSSMIr+kD+G3Uv5SC87H9LSJFhtIf0zjR0kfJq8mH2iR JpN9xVa2BlVz9ogxB/MMKKggiZddLYUSUJOJuWkp5XJM1R34U0STGp9NmdXl tVNU/UABnGzExHEElOftXIOU5CR8sJOr6uBs9BuYbD06v5rhT47nCJICDD9o fJgPCDk2cdsDgzkQZJsogpBTM9g+tr5WxSfsZao86IKy7oW3iiwmMw09Yj5s m08J+lj8D/HH6mwiwHmBkVWjIrxgfvtzSWS5pvrHCdz6wvaIZjIqJPltv3T1 DM+o+qILsH4SCoT6QS/x6gkkwh3T9tx6b/uqD7hu86q/wqvNa6wECxv4tp3q FiEs/aIuEqL5wJuX9rr2XLPSHK4vbUXU97ZyZopxYS0ol/2P/So3chiGgRW4 B1fgofmJ14SbUKr+41uAwEJi4OiiG2VaEs8uiAEp9MEHjZBnJ/xz2Xrm1vTS kmVI2yV9RaSAB3dbGc7IDHzleOT3c2zjVbqoFFCSApBpWVPHNldoU/AKnwln vQm1hg5dYBh4EaReA9fMjI96OTioPLa9OmET+ab8mi/yCXEDdYxBjDBMBsH1 Ga4A+N3AD2fJ3ffS6niqqxgTwgt3d3iD3olUV2NLKltB0BzPjPcoTxxYzcuB xQpebppb47eS1SBCTBzSwiItAa49EfoaUqXSKa/harzkMEyRNHCOHmBRsWun 8WAx1+JMFbwxgTHAtUajzv4TF/vcH/KOwcH4Am4vc9Kv6lYCYLnhWjCHnhjM PkHGEvneRq8Tsz3aPzqyjaUjY0XZ9NZe7cSTISik4+sHPUeL2i8BCMmCK5Mi Axh7pqA8kqDFuEZYVOxfRus9b+55c8+be9789bz5FWAA1Fz3hQ1lbmRzdHJl YW0NZW5kb2JqDTE1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAy MzQgMCBSIA0vUmVzb3VyY2VzIDE2IDAgUiANL0NvbnRlbnRzIDE3IDAgUiAN L01lZGlhQm94IFsgMCAwIDg0MiAxMTkxIF0gDS9Dcm9wQm94IFsgMzkuNjg1 MDQgNTU4LjQyNTE3IDYzNS4wNzA4NiAxMTUxLjMxNDk2IF0gDS9Sb3RhdGUg MCANPj4gDWVuZG9iag0xNiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9U ZXh0IF0gDS9Gb250IDw8IC9GMSAyNjMgMCBSIC9GNSAyNDcgMCBSIC9GNiAy NDggMCBSIC9GMTEgMTQxIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDI2 OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMjQ0IDAgUiAvQ3MxMCAy NjIgMCBSID4+IA0+PiANZW5kb2JqDTE3IDAgb2JqDTw8IC9MZW5ndGggMzYy MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXxXXZebthb9 Bf4PWn3oxXfZDGBjm9ynZDJJp800WR139SHtgwyyIRcQRTCO++vvPhLCYjK5 Kytjg6Wj87H3Pkd/z0JWsFnCwnAXsV20ZsswXEesFfZdNfuD1bMAD0nIdvhp qb9hAb1/s5/dvNuwkO2P2BDgH7btYn8Vblcs3mz8ONnt2L6a3dyqmKVKLwmY Smc37x9DdlKwvE/pz3nm7eb7L7PQrMDHZuuv1ps1Tg63frKKQrKzDPwgCEK9 yQ/WSax3prxktejOsv1vUZ9YoViXCybr8sLwIsMT7+htUTWlqETdiYwVNR0X IB4/XK0Stn8Li9Em2pHFz17T8rQrUsE49h9ly855keZMfC1UpxhnFe/6dg7P tp5wzp7/tf95tv83TK2DTWhMFfWx5apr+9TZUtRp2WfkLbkKp9p5RL+cRI1D 5ZG9f/j04fFqLkq2xprq4BEf7GQ++9jAzWv8iqW8ZgdRi2PRseOwTlaslGec MdoLtpvBYCoposOFWd+yPiW/Pi7vlh9ZKusn0apC1pRUa64/5axX5OfVIuqU GIulxHZrjSNrcvCxa3mtGtl2C3YoumXLO5PfM38SpahPXe6Y22yGUphdNmRU j6XWD6WWcLAWKdUEhiSS2Y5HK2nzjZSqnC8d63Gsw/daCjUTTyi18tlrilcV mWj5oRQMh3ZUC42ma56XhBxTlSiKjZMWe+PZwjqM+Itam7C/pRRDA0iwnMPv LBs3KZE5JYpXxvYPzYibH57l8pqV9GJgzosKlZKssTl6QjgUlhN9EG11bj3K nC7tuehy2WN3fYG3nWgrkRVUHqf+/kCYCDTZbgfCxJE2dE8REu/6TrYF3DsL ZFWlbXGgEk9tUgiyXnzDP03u3ZDQHxQgAe+eEPP3YgUEFWukLBVVybiK89UE lJGxd4UHVIAXLcnAtSISOy9MGHVATagsX/oauHIYnawH33A01fMFGLJaZgSk P+bxhgzPA49lhUp7BWK2hS7dpMJDiblqNIg12JDHCmbowVW1UTFGFnZ4WjjB rpLYqtewpDMFXlAKj+bdsUgZuFbUQhD4F5o44msnasNyg3dXKcLBqpakK7A6 mcpS7/6753VXHAEdhIBk1rLCITrjjRhxR+UF74wtcB+nASg8e8JmfkIlqQgD 1/jfvZGGK/Qh5hoHDo6jVTTkbyIPvATY5ktqG17NCUIva5cGYlX8o11xauZo UDg0GKmTLzRPbEGxiYzw2sBKToT4qhFBFK6Nk7qM+eXQFtnQTnjXiarpNGEd +RVMY996XCOZJ/sgpzw2KlaR5QGVA2SYyE5CU/bmXWw69DPugmtGBe5b/oU9 8roQwqwfOjr6+CpYoxtjuQdQ5oJnVg4fOP6iCRapRsyvtvv8SBaWw85Jbw3R w00eHi8KYSv221Ql3wrSW81LhPJGlCX7wA8SSIGkCOUAPVhZJn7otZju52EY aCLntSzlqSAO7nVjbaCxhfbxe9IMvrkQjYxieNnVHdpvJJx4WQ6s4eWFLBuY E5AUd6tuO0M34MTp8VStkUYpyb4iRzLe8QUgNiIev4zm3ea1trLhNn6fvW3n SYiN/lDMf6lpy3kxAdSCDkLUrirFw2hwlMA5ZiUEAAaMeCwnMdv4Xuq6S7fr av6vk2vblc9GlwWr+rIDuXip8YxDShxBKmcSr9zGO/iIkylvU4FbjCyAGhen WttClxelbHRF3cEFAqcnNY+XJyCtywFNmvio3n2NWaC8aA9GxHOTgFRWbr0T XROv6TsrbcZnn31qCzInR0wjUtg+U5chMUGAjqF4N9Dk1BcqR/YrUR1IXwzx OsK49gGToI3YThgDDd2MB0FE07L+age0F+gyuEUeplLXb+MJ0xtc2r94gB3H 7cD79przPSFy47VzlMxzO9Az7r8f1bmxsdzXKEKlczmB/kCrx7SgUVk7DtJA ge1ojb3ZyKGUZv3vMb8R7ZGk+tpQtjb5Fa/18D+QXLfi81BR9iLmKN6JjsRD tqe4A6RPebc8C/oAKGh4IbQ9fvz1ztZlwV4bJu8fFuzdb074gTX6Ar7hMtoo HfOtFLBSZNO2vossy8MkWbO2x/zSzuO1v/OWKEIneKX9uv/13cffHiAldwgd RzjJWm8HZ+7racPV6Afq/6F7Dm4ownT7bxRfo4u7I9YqSQYWHUqDfj0UwJHu wiDHRVoarby/u7tbsMf71w8apFf6JJtBG43jj+wL6dEy3MGz0sipI72CBipQ 9Cd3OsfAkLldIfBXG5usNz5s4WKbeK999iN7cB//9H6S9Z9zcs9tj3Tkp3xc +NanuyeZTvRVN2HrXeQncRyyGAvihLpyhWZNpNLJSCi6MNCr8bHarP1kt44Y hltkfBWFtH5CxdWQx8/e/0/+7UTV0TBle5lvV/ASWYVWXe+P3w4dn71bXtEs cxLs97rQt4RO794Bdnr9s4EjDHaboW1D9NyeUQoaAsfH40hmYvgr1pSCY2JT wHHedc2rm5u08g+QqqU9xhk0dMpKqJkPgcbCm0rdnHN5UxTqhmDl511VUkbv 9rObWxWz20cGOoz/H29h42ek+gsL1364XbEzZf2Bff4rYNlsyD5erUDVzZZV s00Q+0mUXF+Vs8fZm/118HJrt/ODdUDbMQpE0Wqja+0kNVy/ChAQC7evVgHL 2XwZBcHa00KaePZ6tY905Cj6Kog3bpo/e4NGs7urNhWkPZ+iT8tH0eqrrq4+ IAqd/E4GH0Y1MTMheqSOxfBhtx0q+Uvfdkblt3BOpfl/+4UDByryH8aNniRi 4/1z6FuMT+/NEwTl8p+XsPXT+DvmIoybuKyYQybWb2VZCuDvg6wzuuX8/ou2 NU6wEwDq+cNK1icxql0nlw2eQN8makBfZXOU8ydMkE+yJD1A+5a1cG9H06T5 q9heRioJdOOWCdEiVLsDke4dE7kU3bSN+OApTWuO6EfrIdkVaDDeh8xNVeXy DI8wMMN5dixK0CTnerxC20pzsFjU0yvDbhgvaM1ZHBhMHum7nXk62TDVSE3Q aYebRPIdju+G8fk1+hGEEB60HE24pTEnJZPk55jiQhkUQm5PeXkhqD1LaxxY 6aVJqS0OPTr6QlsYK2gG5VHaCrr1jnnyCfjjiU5aE4NhDzECYRR5WhJRboxt hvGfZ8XJtMFMF6XFZGom3uskGpph3DtcmPjaiVoBnfaCCQWqeprWzA2TbiS4 8lFCsMid+WzTqimSb5JUpzYYTlcF8bUBFOsOQlBezJV00tqDnZkSvLq3kyMB XJkhnjJI5QagKebhlAXDa2i+ku7F1V5hyO9K9maAoYHDTOhTdDx3k5eaCOTt iwD8JgSAwXhsZ5eXABYEdv+eNnRWEcem/lRkWt/gz9jbsj7V1xS8kjq3KEzT v9Q98G1Ahb7lyb5DpLCn0KP0LEm7edOUQ1H/x3619LhtxOBf4P8wR2+xVqV5 We6tSIFgL8EW21sPwcbSugLkeLNygOTf9+M8yBml21NPxQIGLM6DQ3I4Hz8u kSMjN9EqyY3qvUtWUiRiiof3UIesfh14UnegcsMwkeZbNV1V2ZW16TZGFLcL ivoYutLny7JMn6YZe8bIJCOrzQR2qI8sOI0x4WFthTeSvkws58fvSJ3Q6H0u HU4uFq1FG80KGyLdTzfH9W91hXZvDuvq4XP1qAF83/QHjbqc8TsxnD+3U7ji X+H7EkD2Pl/1E14QggBAzG9il5RU16xjH4FeBc/8mrn5bwIx6uH7ch3RCkJT Vc/4jjvXpoYnVLgDVTiqbjeaDDkFUgl2uyaWaPkuRyQtcnYYT3lyfIVr6dSP vFZSiwOJd4LLHxr1D0WZkBYsald1buD9CVnpMVPfxNEA4T8VPVmRGJIuRSvg Mt+khHn6Kuh70255ZwY0RGZaXmvKrsz9lutSZWsqgoCZ+etAhRkm7H7M8B3w ADNj2RBRzErPbXxL27v73Sdg1VADdTYYb/t5BgGh6ISH8Hyd5IlbG9ns9pxK QqiXBBOVriWm0S1iC3uGAiJM5gtscGrmoKcMoTqNnxOJv8WzzNcN6D4+otzf 3Rf54qPOrXhwHq9/XYaFqzvCOp2jaeSTIJBY1h1SXhd+UaV4fiS8Dj7WMMaV OWKsOl8ASPHxgWT/vunUafPz+wf8Lfie1MYcgGcGDUzfNdTJGKNBc8BjO914 NKPj5umnyKAT6+wDge5V6HpAyUODdKqansTrXi6nl8fzWXU90PSPdwrcvDUf 3cenmx2SFK/0JfIvRKj58m1QqvUN/YxSnf5F75V6GEEgQNCz/Z16zx0B+Miq HTiQFxpdQPgC6s+b8BGGTPyaN95Y1ASf14oYNnjPYpi1rYgzKXbaN3tt4ynO tUGgg5zjCcOCHCf7eIQ350NFRT5X9DxQhwRv0SJ1aIw+hKeOAPzv3Q533kRX KSdNT3nX0oG+FXHmWWf6bFFakEfmje5Uv+8b48lLEtAmkgBjnA5HyzSP8BoA XzowxpvFEMMsZgdlQQ4CxasHT476Ea8szOy5TOfoyBo5L7pvdeU+ix7L+h4v GW/MkWyVbIVwhCbTGO3zXLveWMSVFrOIXR1BRN4N8wqjfFicDqUpMTBtLC0+ SnjkwqxeXZiMuMaGs4N+B5SiBaIiyuKarGhXCuqcEP8cjmqNZ/ectfUZSWYn eUG2MStYeXEMmcYXC2CTOw1CBwhW2oYY9TbmH21Jn8cN4J0uJg+gGUibwpfN q0jAyr1VeYNvWVn6hDHpoDy3512FZUdJf8lI168yUkaCNd65xhV2sgp2xOPr gJzjFdZXClhkK3gkmsgKkvV8BLvHRvCKvtaw8uL4L9D6hjdvePOGN29481/j zd8CDAB5h70+DWVuZHN0cmVhbQ1lbmRvYmoNMTggMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDIzNCAwIFIgDS9SZXNvdXJjZXMgMTkgMCBSIA0v Q29udGVudHMgMjAgMCBSIA0vTWVkaWFCb3ggWyAwIDAgODQyIDExOTEgXSAN L0Nyb3BCb3ggWyAzOS42ODUwNCA1NTguNDI1MTcgNjM1LjA3MDg2IDExNTEu MzE0OTYgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE5IDAgb2JqDTw8IA0v UHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YxIDI2MyAwIFIg L0Y1IDI0NyAwIFIgL0Y2IDI0OCAwIFIgL0YxMSAxNDEgMCBSID4+IA0vRXh0 R1N0YXRlIDw8IC9HUzEgMjY4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0Nz NSAyNDQgMCBSIC9DczEwIDI2MiAwIFIgPj4gDT4+IA1lbmRvYmoNMjAgMCBv YmoNPDwgL0xlbmd0aCAzNjgwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJjFfbdptKEv0C/UM/olkGg0ACnCdfc5k4k4mUyZoVn4cWtCRi LgoN0vh8/ezqbhBYOZlZWVm25O7qql27qnb9nHgsY5OYeV40Y9EsYLbnBTNW i+67YvKNlRMXH2KPRfiTrX7DAfr+ZjW5fFgwj602uODiH65FMyfy5iGbLxbO PI4itioml7dyzhKpjrhMJpPLt0uPbeXEdh3XdWdsleCR1XFiee509WPi6YP4 sQgdP1gEcMALndifeWRO3/LULWcWBJG6mlRF0ZZZwpusKlkpmmNVP8sLlgqZ bUtWbRjPt1WdNbtCMl6m9JCLgBzP92O2uoMtz43mZOu71VRVLtmmqnG9wGG2 5lKkDG/s20bUjGcpPhbVOssFvWVP/1h9mKz+Rg757kIbIQfYPudlmZXbC3qT NTuBW6nI8Q25tGmbtp4ittASnc8nU/58HmtTUtSHLBGSZSVb7TJzJWVvRSlq HfH7Eo5NbcLJgqULOrrndZMlbc7rk1F3Fkba6F7gwjxwIstuKps+MfkiG1FI Rx0HOjNntghDQse6TtOMHuI5LAOZQj+bAcwDz3K+BhK8uWKEa+xEZxl0/ciZ L3QGXe3Armn2V5eXx+PRd3qbzw6yeGxF/eca0Mwozq2TikvZ8A2FHVmby6Zt ZLJ7bpWblw9zzcFf0Mb15k4UBbF6FKEvPMWVdwJPlSWSyx4JBLjcMzlyYjcm 9ynoHZcsR6alOADnnJXcQEDJzAhxmy7b5tKITW4QhzrO/tbeJK76IZJGJbMn Axnci1qBUCaCiQPP255WtnJ+ppxXxsBr3nA2Ir3UHPvZ8jxrXohehjYOeyfI TZX/BcrIwI/g1kKUuMWupcyAcNmwz52PGyElCoA37B0vTrkYMGkxD7Slr2UG fCRenYY+MnQBYlIc/UfO/qWtZjhE4f7ildsqb4t1xgcP+B3/Tw8QaJ/Ekf17 6nkuGaifL9jX5bWOnbOumqTg5tdkxzYiz6sjEDnZ9mJfc4FK8k4oQgn2UNX4 2ZZbuRWFyEp84JuGPVl3D2+fpoQjCN9D6Qa+ASBp6+7hsslfGN/vK6IHPJK9 SzxFhVFPOWtV9rDmQ9WDVPdQjYqlyEydrVsyZwqU8Pp6+/H+Xkd9cgktzECm AI9/B/jfeZ0j5yk7T9/yKFJROuyunsYebjkD4ELTI18VEdsNQk0ELKZsh+6Q VklTUe2kYtv9WZzMBShP0y7RmlWsWZkoYDady4XqmwMOgNr3NRrrVpSjEulm iTMLY9OEP+n+urBEsRaKwwtrO+JniHhPpXDk5jw1eBTG4+PN+IV+7oQG6LWQ jb3nexoLx450qeYj4k8qm7fNDpOHqpwdQUU7yZDLQc5nrq9yvq6qZ4bI/9mK lo5/MlNM2Xrk9XN1YLc7Dl4y+8RCTULrcdhKPg9ayT21Es01hfGtmWK9hcDz VSzWMskE3bje7/OuqbB9u84zuQMc6xf2odqV7BumHhViZ0CP7jiOHGam6mlu nAbO/ztBzgfz62mhh5YjhNMmucMTp32+RBURdy4VqvcrrTlul8ylUWT+L29h 6wNa+w/mBSCyz440LR7Z9z9clk701GDhPHIWgQfx47uRM4Pe6b7JJ0stes4G TggQ0aBxcu64MUWu501oJoAbX/mIiXn+leuyHZvaM9cNrBVVV2y1KJAMqKx8 5T145rvzxRhFb9bJineCH17YyvQ/PnWtLJdXo4wrKmjWLNHW0pZ40c30V8Ba d5lMMuS7FFIPQs/T4WluxKGv312Kgt2gP0JafGwT9Dm20s1BJLuyyqttJqRq xW/YP8qyYh8GTcNfBHp43VT/KfjF61rOynRXHQSm2gqFDtbvBJV3Kt+cWL7Q WFpfWlJ0ZVqxT20p/rRRK9kPmLz99v78OpA40fyUjne8TnZVbt/wnOpARQEL KF57AfGESNDSMDLKYWs0pxCgkR1GMIzorgZ1bAbs+xKNC/RuugQfBfp/0kqq cWppXYMD8Wla96miNphk9i8yhrnleUa+qZTRPEyqsulNqftkXGz0VxtoDTK/ I97YDSoNpdzUvPtzlozEoUYZc6/mCcChfpwoh408HaoU56zcv1uUgj5geEa6 QiqtW7V1PyDA2pzTQCOJKtE3fhGqu5iZfD1Z2dN0ascLzwmAah9s2upJQUQv qiY76I7SBcsoWJBAe6zhRBJd97VS87SQsXT1KE2Ga2VbIP6E2pWUrcA3XL4U +wYPJUgWVy24W3yCCLUy9+ejxed8v/HG+40fof5jiOLfLDheJ4Ios3DiwOus AocK8LxK+8KTLYQOxlivMdcc20lmnycX6wQiuCAOlJJSqWeV5MU+F5hkGBHQ L50ZDlZ2CbJ/hZ4XeEGfJpWn0I+dufVtOlfyLK94OkBOr1V6ccFcAQV6aZIo aXKepqhLUye3lmAn0dyooTfjXUexX6tg8OEgUE19KQzg8KLILEJ4P7LU4FuD 4yQDOow7um6zAqUGdDlWNiNPhmryBC29bWQ3yj3b7hrdh0cFxwiT34Lquv6J +xrVuZIldyLnL2dwcuWxMKr/1EcgHPlf8x7y2vT2RoxJ9ColrAP8yfq8fJpe kE42yAwARd8z+emEXtWWKZps8jz84jfGH25sZX8AbK9nl5BQDaQW+yIKKKCR piVD9MUKaWIPGWYUjC2/fF6NbfVJUgppSawhkb6tqRPZJmuSifKQdZbLAoPu f9C/a/fI1IESFag2dRq8ip3UTWH9ilpiKTSD5PDIX3enMDYQqIoSa8UvDCWH 3eYcgW+6TWKc+30FDYesDgAIvHCgtftVaU8ToqlYW244IrfV4oDZMmgmaKGN Yoi6STfQ3kfQmlriTQPEyBsYHI2criq6Z3+2HcpCg2zGqhFXPdjj4dpL/MD3 tKzsdYlWL2YqL5AYtFD3dM/r74XDsjerCtXt4zIZbSmUOE5S2Ih12xgdpScI Z2Yhgp7dCRK1VJS/21067XZE2EKJluF61c33gY65IE8gsF3dqcni593d2Nfx i6OdxTcOvvIiy9et2ohC2oheSafuyQBLYFt38rFbVzTy5MeG5zlZo6PYo9D0 VJc8dHunJKHF1b5Jbp3kXGRWDurRNI8wZj/yNTZFSAfl3zlut7xY11m6FRen 1QXKUtm5L7fkt8PeK7fnypcfFSSSye0gOejc+r5HJaHvj1atpZ4rAJimCrGT nr+BJDQXCVa/a56926pAem2sczwQx4ToY1vX6N/vsjxXUnLYnnxT5grAQu2r CgcyofCRTT9DHLbMaGC9SkE0sBfMI5N3nKEFl+eyMlvu0DyRaawZIHZDHxvW wJi38EYwaSJe51tE3ezOoCKjt8Tu4ZIZ6hWA5tUwG2SoW0lZt4E+WdDzT9PT kkmIe13lXheSTP+X/WpbjtuGoV+gf8Cj26llSRQpbt8ax3bdGSdO1nlqO5mN tE423Uuyl7if3wNeQGoTZ/rQp45nPGuBBEEABHAAp/MwW5X069xb58x0rcDp nrEA2YsQ8GrxVjJIdzbMU1Lj7j0cQf3pfoMGmKOSXqLyueq6A/Ds5rPAzDC5 z93ThayVWeaRnI/xEFyMd4zlC11mriDmw4Cm6a2uL69vCShgStdZcX5dCbJ+ IsyvoZVjgIhTRqYlOigvcj4sQof+bhNNGhx+zL9wX4bMOQgQwLPwMLRj3E2o kfkirza1Cp5YrOWN5jwCRHZXVjlAskGC5l9my4OgWL9ZrQ7f6FxP1hHq1nm6 9jF6Qj9YeiTQj8xnAiG1rbzYMK+Sm05HMGLLGgD/FYww2N9+KJ+X9CYOI3jY /U/Iwa5D2HIc+kzzuH4a5IyQo6l8qT+5fnZDt5vdftj0eBV4/5KHzwcaXOFl mfYUPxMX5xAtOVWrLtQMdgYqna+yR6E3UhGZBVEt5FkNReG+EVTEkoHsc5xW n3JZ+eOHki4TwGC9Q7ewXywRvp/2Pj6Zj/Jwq7Q0BZybD/lwknLtewk2xqg8 kM0xokk6ubL4lVYEFBp2zjnI7MU2K5MTE7T8t4mP8JUsz3RSqvkmzD6W+ACq 2YA8xBUOrPpNbKqHxRodada4NTaOWGxApqSgljgWzewqVuCLQ2rfZiNVTcjR I8uu15C6RyrRxZvXv7x4/vKmJJcbLjG4QPWbPC2Nce9wMjtgFN2eYdMXFlbg nievd5vNX64OfT7MDxzLUIvhncMOQXxxV7wqanpfnF1N8W+H7wUVmB4rraiu bV3atiGl6nJiGyRPUwLtt/Pi/sfi2R2StA5JivysyBJ4AREocSsk/ftR2+fN vd06/yCALfx/d06VBuy+1W/vMV5NJih2W/gAlQTlpfz890BUmZL/FFHd/Nx0 hMhawD1147wA/Wu6gvTfcP9HAqrQA9UV3dDvf1Y0wBK2oqGV/9KWloX7cEvK fy0Lo9qy6UzkTaQ7YIyQbretErlkwboBHmD0crdoXTmCL9JaNpQQ6bp0Tlbk cLw0iYj3JjnT4ux8B2vPp3iG6fkLDlR2wP/ebPfmpTeVY1JZjruKLzRVIpey q5WNGgWGuLIsmppsZ0tl2EomVOUIKKMbd3XalhXhUcqEC72/hXQ+jGQ0MDFE J7C/rG6DfPgrEkuxPG1H7ySedJ83v21G5gtpwGYtMhk5ppluKR0F0UOSwmBh 4l51fDDzKzMLiVM1l4h4GuplShnHHC7lraRgOJhr3Cf3pAdrm6MHSysaTW0T jdKqcQxJhKeTaYmjOhIwjolkn8ZVlTJinm7b8R2BFiOFIeoYBRxZ0btIk4dF YUtv6ghMRpqa1vnItj7++Ej47AtABj9MXKh1POS+2sjFBDi7luIBU4mw8All wkVxr5NTmWZ9Cv8UkdoeRWRacdoYrUud6SkixBCDrwliTjhaMxIgpGghK15F ERC0lyvEPFFCOOxYwpEV/XdK61O9eao3T/Xmqd781/XmHwEGABh+ng0NZW5k c3RyZWFtDWVuZG9iag0yMSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJl bnQgMjM0IDAgUiANL1Jlc291cmNlcyAyMiAwIFIgDS9Db250ZW50cyAyMyAw IFIgDS9NZWRpYUJveCBbIDAgMCA4NDIgMTE5MSBdIA0vQ3JvcEJveCBbIDM5 LjY4NTA0IDU1OC40MjUxNyA2MzUuMDcwODYgMTE1MS4zMTQ5NiBdIA0vUm90 YXRlIDAgDT4+IA1lbmRvYmoNMjIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMjYzIDAgUiAvRjUgMjQ3IDAgUiAv RjYgMjQ4IDAgUiAvRjExIDE0MSAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dT MSAyNjggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDI0NCAwIFIgL0Nz MTAgMjYyIDAgUiA+PiANPj4gDWVuZG9iag0yMyAwIG9iag08PCAvTGVuZ3Ro IDM2OTEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUV9uS 2kgS/QL+oZ52YaORdUPAvDja2O1px3ZPb8OEH+x5EFIBZUsqrAuY/fo9WVWS SnR7YzccYw+SKitv5+TJHyOPCTZaMs9b+Gzhh2zqeaHPSt4+y0efWTFy8WPp sQVeTdX/4QN6/m4zenMXMY9tdjjg4g+OLXxn4c3mbBZFzmy5WLBNPnqzqmYs qdQnLquS0ZuPa4/tq9HUdVzX9dkmwSWb82js+ZPNt5GnP8Q/0dwJwiiEA97c WQa+R+b0KU+dcvz5bKaOHnm5k2UeFwln/BRnTVwLWTjsd84qXp54xWTB6gNe pqKWpYgzuspFSI4XBEu2eQ9r7swPyNqX8VbG5QSXzscpkzuYOPEyztg32ZST qbcYF3FW3bC4SBlMiorFLOf5lpf08f3d/dPkr82n0eYfsOkFs0jb/DyZzcey /C6KPftorMvmyBCksoSj5OB9UXO6BBHjGooCF9+mJ1HJ8tLbdf3W7krmuahr zjsLmxUCh1d5LApmbuIVb0NKDkyoS8yLGv63PyzHZ+5CpRY2fjS8IbdhHU4o bwWdOh4zkSgfK1ZLdbkuxJSyq/0MTEp1bWJEc6ngG3xNZH5syI9Z6CzGU/zM m8LYU3cc2yxN7bjn2q20SdSH1aWqeV45dOObu5luSBTWd/xoPteFjXxvrg49 NymvRJFK9tgU/N/TfzVcfIv1UdPLXuAEi0WADsTRL2O4sBjzhIsTR7FVUnFf +fdKuTRtvx70URQEpjYp37eZRZ8UjCeykDmvSwFA7NrwcpW5D9a7Pl7fDRba 1nt+jMs650XdFvqut/1nAQfLStQXenmbV1190zjHzZbBcGmc85bLmcpzzJ4O DloOoF2O3zvXjg0vfojxzCpIMI90QXIUDlGRwZWpLFsnglPZce4D0n6QJ16Q r31/eG7ga3cs/zcTz3MpsORQyEzuL5Q7H7BXgD7HBLijrOppKhMW11Z3hP5S W7t/fL6/ZV/Ha3k8iJjdFrU4ykwAtXcldeLXSW9z1ZRtJos6uwDTFgyiuact XsGcMvPUJmobb0UG5yfzAK18wx55fQbUdTZus73dwWAzA4lS1Ie8Ymmf37hm q8/3uigVYFLHeNjBYMcrkMCgmqABbWtdy+SA1hQJ+wMYNKB8HsIe5l8U1Kqk r+lvrEr8v5bTqmTLnsNmfFFMnaT/k6KskN22gTvWYq9zVM9HL8hnQCiaG4b8 U5gK/ldeQchz7coD6vJ7773Mpu/ijAKge/o56URhFGlqUadNIEOSQaKBR+AQ UbWp12xjzltkQ9MQODY9YMpzhd9hOVZxJpARPcaADPTEO15+5xm/WJ3VzWZD FJHTsQ2s0oMp/lrevBq0QuiuKVJEs7VnVgSVQakmrx7Xd+wJGAaEMZAx4+54 lslzdRBHCpw+6ftQj2vdpaG3GIRbUQgPzr3TNpqDGarO7+Iso5C1pxWefJOi 4Knl0cIz6F7FJiV8L3Az+VLYmSPOKX4NysnSw48bC+XLpbGspqWiGq/rdFNq FWSywhcZrDAAWBhLDlsrZWG5Op+bckB7SFBRZ0schTUUKK+r2+cPH55ZfO5U jHNVKGse+IFydGxqB3gceHwSGbXDSWbkp6nH7eqBre8/PnzYPN+v1l1F/E6K qBuWV0A2uKp73FOHAFusOsbgqK2sDx00rXg9V7W1zl9+zDgRVi8OeH4E34kK 9Seq2BPlAf45j9vhQj0cLE2zVE2br1Rdnsk4ZSmKWYpto8kSZoyG6Wgdl7JK ZuoDxxZ1obZKofyCvVTqiNxLcSLH5K7G7EtkU/SSBzc2okYrWKbDmWF0RWTG dl61Neg4L1YaqkoOPG2ynvjaCWTosDccLlunhx9qERufLtM6FpmVHc39pPEu A0OeO+sNVZxd+VnLvutQ3EZkKXmnVHhZsTNmHpXzhbSzt4Fe5VH3WRSu2PjD Ru8UqzVznUX333oFev4Ecv3GvNDx5gE70xLxwL785bJ0pJcJFoUzx0eK81Hg LhwfIG2fZKO1XmoM1/d7yBzZI66OQkATO9DVGgKCDH9zMRqYN/8tcNmBTaZA ezjeEJaX40YvHGwTahYHh7lAjDVJvoyfZaPad4uxw9En7RZAhFSzNZInEktv nERKyZwyZdG9nggmj1/Gt8qSOhWNZSuZTZu/k+YFbLGPcc3P8cVcgY+hJ2Q2 LI7Xr2pfx+8+PkFD6ekIElUpGwzUL4jfW8JbkQPhF/bRwdojdjtR3LDbSRDh zeZvLWffsD/Xt1fD0iyV4QLpnwWzwVL5cncMhrtjEIXOkpbWXy+PoTfTDPO7 PBPt3T8BnkXBkaQTUT5pE2ACA6NdHvcZlF4/ivyFb5AwWNp4/ZaRSWwZV89/ Wciv4/v1U/V1YqucFq78J+ZCsect0ZhOEYUCBRVUX3fGzKIwyNHEVrS2PHZD S3EYS3qDUrjHz7dQCDraF/eV0Jcleqix9zEvWtoiZuKOKYs40nBqtAqzm9P0 fLHbIh3tcoSx/5Zt8EGtsGKbn7caCQA6C0QIIj9BqpC5Lfg/UTRoicVU2ppS Ow9FUKvTr6nIBCoWA+kAFUETHh5gDZNN1eaFdoYD8ov2iNO0Y3t7hLpLk1aa Rr0qJbWwp/ZRRLrvVsE9sJZq5j0DGHrnszeEsO0rRIjjw0J01KkQCueqhqQ9 xD55CJt/rJ/uJt6MlrkbNKFld+ZqVi1kjVu53gZSSKwiNdNEFQs2aFdKLmyX 8Z/CrDb9UO1oGsvp1eT/0QhDIPB7p5YVU5loUJmoq4xmAGKnWM0k4oIXh17j IdD5MnrZzbSmJdAcRyx7BxpnNHAsupvbdGcrwZa1ngb5ZYbpHNWfSTfpWrlV t+yumnNL2YP7w6mmRS/WPHiSSfmdBKvqN1ju2kvUCoGVmcj6CQRRSzZu0DoI eO3E3tIz2wsj+nAsCLUOKa1oIFPJnNsBG2VkAqFWFTtIbUhJEE6WcXBONWQS aMK4FJWmA10lu20X7cLwOgY3Si6IIsmaFOwSH0VqMQDJgoIyYtPVInilwD3x ob15Fl/MQeIdQHnik8G92oRqkfPqxkb9bN6JStUk6G+9FxkFqoWUji3W45Je KlaY9rtu0NISMQXSkvKdGhRXUCUUCY7KsEfZAZefBNHL90KebabrxiZE2F71 11AEDE137VZVTc6h783wfG1RHUqr0DeEvRkOZo23nQFbN4YXznzm+XpnHYge AhrLeKzkHf8JlVbTnHxBxVr0GDNXQiVo169hgV8bFrQ3ELhznm8BYNO1oLxH SCYAx+7DtrUfUNS92hsUqJ56Icne82Nc1vpVDT2iti7SI/aEMIn6Z7xV+vsu k+UhztlTXH6/wb1n9gnDm3eLTZvFOWXxetc72MtNBObUtpsi7Vq2jNMGvIRm 6kYFdSKECEKljsew27VtkFP89kriq71hbO2syNFnUQEVFWmuB1SqIszAE/aw 1hk5OO+dnmL8hdk9bA9U6CtgpaH1cI1+pvz9h/1q223bCKJfwH/YR7eAGZJ7 IdW3VHDTFIiBQH4LgkChaIsJJSqiBCd/nzN7mV3JVvPSp8KAAHH2MredOTOT 6DEfQ5AiJKN475XEoabyRv/Z3Ucg/TL2W3r2+AbCOhyv+7ickkE3HbCgCeFn l5b0qlY1P9iIeRA4SLn3d38GY5dGNg7cbjpMAagS/XXjo/UX7YZ1rR3W/FRr FzYjwMpNgs/NPN4zwL+yRrJ4x2HW8Z2sqCuFuKHJxRQ6nyGLw8rlyUWaxjV9 dVUC8asnPXBEnWJGswtmGEmzzMUZRl+aYa5er9CGtiEdpycZ9xZI1U2nA8PJ 5HI1Xy/3A+LtJqeLaEZRDG/Hr/3STQf2pnkG3yj6Qz5RCXx7c/dXaGdjhTnu CJ42I9oZvMzqeg1lt17Zp2MUPbf2GP/h3evbm7uPYk3heEBPuEP/ZpvbA4zk abefznvmpFVL28VGuzaM2jfL5rjbjXvXjXFtczFDI0i3tf5D2HD5QbfiOWw2 xy2KNt2wibqk3iEaRlUX8YcfwV3fHq/TPs7h5NUAt//gog/FUVdd927HAFuo 3QxiRRxG1LXx4dmOUOqQg+3yOLne5HPo+L5isEUGIDYe131ruzJuB9POkdd2 S6w91/qVxom5Wh33oWS34xFgbKu1oDpOr7xDF+ick4vFAZDQPfRd0lOpEDbk 7C0A/dC1623/DYFqu1caDTxAjBsSdOF9Pw/dZgoJ+z4rxUP26s0CfxO+e5HJ GcJJYhZtypyGUikrFD/EW5UbJfZddv+7y2CfF41N4EbY+bWWlLYFeKY+CM3q iLKx2YiywZBzNxeAhkJ+0p/uf7vWsxkyd+8KKVXQb99XQhQmp58Uoqz+qGqB mbRHzSlVUL8Ub8D9H8j/Iopci0cCknfiw8dCrGAIGVEBhOwXAnnI7Iddku5r yIxUgGMTzkbSXjCGSburikgOxFhXJge4OSlaF5YgQUjJsCGZiOLiPV7hy0Fo ZBHkRj6L7NV8grXzBZ5hMb+lZCUH/O/Ntm+eO1MpJmVDcVeQQFNEcuBdLZug kT8QVoasKkWDEiYNWUmELCwBZXRlRcdtXuEzUhov0PmbSevDQAYD44HgBPJX o5XnD38FYmDL43bwTjwT5TnzVXViPpMGxwCfqBb5TBOtRLwKogUnmdOY4PeK 84uJX+kwk7hVEkKE21AvUcrYw14obUUF/cVU4za6Jz6Yqs4eLK7oXFnZlr8G SNGByMLR0bR4ojhjcBoT0T6tCPgMm6eVOpXhaTaSDwQdA4MzK1obafywALb4 ppZA/6MFGibyUaNc/NEV/9lmVHLwMGGh1OGS/VLhFBE4WSsRLpiCmflPKOMF hb2abyWatTH8Y0Tq5iwi44rVxmid60RPZsGGGHzNEHN8QpkTBkyyFrziVGQG XnsWweaxEnyiOeVwZkX7L9D6gjcvePOCNy9481/jzU8BBgCgKMutDWVuZHN0 cmVhbQ1lbmRvYmoNMjQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50 IDIzNCAwIFIgDS9SZXNvdXJjZXMgMjUgMCBSIA0vQ29udGVudHMgMjYgMCBS IA0vTWVkaWFCb3ggWyAwIDAgODQyIDExOTEgXSANL0Nyb3BCb3ggWyAzOS42 ODUwNCA1NTguNDI1MTcgNjM1LjA3MDg2IDExNTEuMzE0OTYgXSANL1JvdGF0 ZSAwIA0+PiANZW5kb2JqDTI1IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYg L1RleHQgXSANL0ZvbnQgPDwgL0YxIDI2MyAwIFIgL0Y1IDI0NyAwIFIgL0Y2 IDI0OCAwIFIgL0YxMSAxNDEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg MjY4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAyNDQgMCBSIC9DczEw IDI2MiAwIFIgPj4gDT4+IA1lbmRvYmoNMjYgMCBvYmoNPDwgL0xlbmd0aCAz Mzg4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFfZcttG Fv0C/UM/TZEpEQJAAgT9JouSo5TlJWTGD3YemkCT7AhbsIjRfP2c2wvQlJTM lMsligLueu655/55ETDJLlYsCJKQJeGCzYJgEbJG2O+Ki2+svPDxyypgCf40 U5/wAH3/fntxdRezgG33eMHHP7yWhF4SREsWxbEXrZKEbYuLq5s2YmmrHvFZ m15cfdgE7NBezHzP9/2QbVM42Z4uJsFiuv3jItAP4ke89OaLeIEAgqW3mocB mdNvBeotz4+SOb36fXKSec52gmWiTRu5ExmTJeuOsmVd31WN5LnH7ktW86aT aZ/zZroKvOXkkt0z9eqhmv6+/QWBzAIvmM9XbLuG/XCBhJV9WXYVjNfdkeGD +KvOuXJAHjsu85btq4Zdf17/exqEiZfAMi9ZVc6U2e1PMIbyaluZKHiZXbJM th0vU8GeRIoYWTNFnstJ1XeyPLDa/tpVaZUr8zxjxyodLYb+ItImS9Gdquax 9dha7vV7e2EMCLhoUZvuJETJ2qoQrNqr0HPBM7hyQlyuVtpgighlxjuhE6NA M24MIm7eyapkr4p+CfNuwrGpXnfkHStEsRNNa53zPpMUmqk/lRMV47XNW6SS O9Xzw+XSGCPXFBRZ2dmneYbWwLT9vRU23PTITKu6qpYp48Mrnu156IUxmaee +8tFrB1d7zvRUJfSvm3J6Wje9KgT6bGUf/amSvRoVZYinb0FJjTLZgB46l4y 27gBiIizHArKisoGOySWirKzZaFhCKxV9cAKmfd5p+PRwahIX7gjEFNF7kuk OJ0FCSHo0ql2EiZqJnnLTgJh4WcrmieJfqksn0Tz7KYPeLC6Qpl2+TNNsQlu vjKYV7Czo8J3qN8I8CdJKGRfq41GeV3nMlUIQ5xAjguC1dwCnka889idLHkO n8u5GjpTRde20Jg/YoQH16KBJ3c2F74JtKCJvFT5mM67aZ6OEnAaEMQey+oE bDmg96PA9EMWYxTCuFTW2Q4hvLRUVh17Fh37QSXXI+IM+tJXmAT29fSeGklt /TFlHX8EYBQ9od0t0m3scIL+FO5NP9wZSo8gQoDbzOL97faOPVx/ut2yb9Mo ppCbR+rJhwHvtR6Wq7tIc/6LqQmDRAPmBpZzVOrWY18EGWnJ/bgqvHgZRuB3 vDUBO3P2qXqUnN0BZNXJDupNVczotZl5/JyUEwuCoi8NUNjmue1E0bKPaDAK UAGdoBxt+9czMnCaPl8YQzdCzYFZCbJ8Em0nD1xNTlHtZE4sZVuF7Fo7SGq0 ysyxGYbGZvZc8gJ0g67s5aE3XTlndfD1z4LRkkLSIpO0BYASx9zKEnIrMHI8 Z9c3Dwqc97e3t+yPqjfTy80GGsmtHRgj50Q4ZyD1/ZXdm3+Tlo1MTT1l2bKs SvsClTKRjuYWZnYsKT+oks3uv/w9mgbkGQIi5oJzN/PQYPW2PEiMe0MWttMg 8GGBt4/sznIjJurHhCD8Y6oHl3DVd0dEo0hw5tLlkLl9Yv9iubWzruHp45Bt a0E5ZIUH1YYfg42w6rRVNUQmSLDRl6dYh7QRHO8/I1B8KlStlT3ZPf+YOllH ViSgcm/VrR3Gih0NJ6O3Vfk/iokpMjttmAMJWuv6gX/eV0MFqJrX78EtLjtQ EnDzxBtZ9a1j2tYzrYpCdp0wu5Be/KQwD9CeTyDGuy9TmRuIObBcxGbr5G0F xLUVNEDnToZpAhHEOPxq+wwkFy4TU0I8VOs9/at4kuI0jRZqR1BolVVJEi6w L/qd3TmUNYbM3YWxKd7m/sPD5/f3H291T183QAdKBoEp6+F8om251PyerV82 xlvwA/8PQK8qRG40WE2vMteaTnZC8ZB3xLKrKix4RDSOIf31Opv9DAXwSU34 bCjX3F8mOiKC2piYqkh7JKXCyp6UGxWm5jVJuDPK82NjgJ9GCJ1kWSraIL1N +8AMkctPsGfItTRBOUiYR2dRZTNHvqivRiWGbtZYjFaVEkzI7tnYBybGwdmZ EdFW/Ugmg8CxooJqgg5UBRwoQn9Dl04ckrcRwFmqeoqaeY4qCgOVHKgA3e26 +t3VVS2qOhdeSQvLQ4RXtKFzKWplbN83KF5jBZSydbuF94TZ/zis5nHkhXO6 l0IAHedSuCBupvU5xx6d0+k29xMvXLF4gVUX0I23/0lfaDcbc6FtbrDbf8GH P2A3Yie6xB7Y9999lv1fHjZ0GtqLcJHg7xF66V6EwyX4+gKM3sgMAQULnCZz xIIIFh5hXt+E+FBcxH7krcLV+FWuYxikynhRzuME0PLV6wsEjgq8OikHjRQs 3vlQOSxYvpv77Mims9D3F5MtyYTVxFyVbBsrLMxokqLYFUVOdt8nW2ixg5Ld N0al2YlYi1YeFOtw9k1v41hv49dHBChI6RxNhdD5kIOZ5EaZBYHOd9h0KqXJ J/l4lDn7BRfWJfva85yYGtSTepfst831mTx7eQvFiZmbewqWhIrN+4TzEURD Kku2LWljdeSNghbyt2qwWTurPF6cQ0ES28VhCgJJnKtjEvVQ3PFSdBVDxjTE 7hDCrNEzmGzPyg4x9Sf2SIWGUJJYHwOP4pmlOTaMUDRkTg73IPCj1Xhu6vum LxGlEgsIFbmie8/sVPU5TgVR0Nd7S0qFexAsAmPpOJDPeYi2kGa5Mpp9noI1 JGRo+voc8BdB8E/yzbTCLiDs+bPzw7ltnBPDj1XCkyNkuA1EXT5VXh2kIL2B M6ZrpNKSKGNOvx5F4Q27BAOobWyPwnrQpwhaoCiV/faw3Vyym/XDNYbJv2Tf Pl5/enWfqG32+W79wFot65WLlxdHZBfX51JYqfJivUi1Xw3Fd4MuqWqhbgSl vN8GZxAbdDpNp8rQ62kFW/TFTpRiLztmpb5b8TPNuUpGBGh8e8xOlI3vMC5P VSp+0J06NDxT+Skl7oI+sgoZPUVn8YJS52+MoMfQkVbbq9QmabEv39hiWJD8 /IjQ+N4JHZRVIJa8LB3803HosjzE1NyIqbW6t+KJxxyCMmYMGy1BQDh8/dFK MFgxA6BOyPUwBWmnJb17M2AUvv52/VFnOzM2z7vtL023bz4/PChqpAQ3vIRp cQBn81ySijPSGiuahBmNmhU2ziAFKkHQWlPTKSrYr/9aYxqeZGvUJUXz0pGr Dqzc1L5B0R5bm+PUU1VSAm0nRMnsDaqG7CUVvKVSdMx2EGoOJHew8wx5/saU UTjzUJV6su5VNfUWAAszvH/ilP8TUUGm2VUj/EnkVU1gNBbdYoNnomHIM1Hn 1bOCrZngvcS0sfvNDE/teAu7lgNQ8lG1JmGs83EjMKAUTvPPrGa84yPZBImB vHFg3KGUN+sv6zdrTtXTj6Qid7fF0pQ372l+tEEz6Wrpt31No8h4npMeL+RB S8WzpNAkwxOUlb6BSsoO5dGw/rB5CP4aWdkIVM8y2Nnqjiym38hjyRytjoRq wJQuXcUPRNPQSrUoM1TQe4sew4U9U18YH+ZQ/Jf9ammNIgjCv2D/Qx9dSMbp 5/Z6Mwo5GaKrghAIYTaPhSHBzQr67/2qprtqZpScPMnCwnZ117tq6rGjgFCu nN10D0gHbA3b2/v6fkuxQqJ26CfdTa+eTBixBs7jKGpfxTeD9v+IP7TGA8/+ d+bz0tqWxU78cjIKkAuF7Yeb7Z5zxth1jifm8qF5/4dmQ4Pgxi/tY7TAKt/Q urKnXGFE2v54PvBwRH7clKwalaKr5diSr8Npt4Q/X+2XjgCglnGuqF2DePnU /+K4U5sh7geqLF8e4eb98+5QM4HKEifOLBAjnqsgrjh7O7V8pJxyJgd/ekIM YQ4NrX9rGvp+8W1pfeatiQoXI2Oe/7iw5n7x+nyDv2ecd5jk18hRj0k82yYH Z7x3De2ip9Y1KdAmgdWEx/gy1mae4rMBrqVtgDeJ+0ljKL7aP+HzwoxrM9rs 53cGC0Lrr+P13fI0rteo4HvkD7RFjWy+/9wa06aGft4Y696gq5rN7Q7utanq b835C1sR7R6Zlik+xYwNhA985YdTv0g+NBTPgqsgE6QkIL9isRKwJ8bRYV50 YZASY8sACYpRHrwAKk7p5EaIq1BlUeUqnw3th7AWC6LFLnbBoxevYv+52Rzz ZjCVctJnyruWBKZWwV5eIxK/aFQQ6k2/QBPNq9z4RFYS4FsGoEx0LFqf5UZw vE9F4OBvAdmHFawGKkJ1Avkrx1D4w18V6MVyfa7eURyVN5gf3MR8ARPQsDCi TTTo3oCDUVIAHTj5xrtU39o54civhCwgqCyViEoN9UZKJUYuQulJFSyEY407 dY8GLLhZwPQmNoFlM/+IKkUIymKA1TTFaGcMpjmh9kWIan0S82IIUxkFFiMF oepYGcys6DjTJLAobBpTBixKsHGBfZTDkH9EUo7dAu2AAlMvbKxEfAoViwBg roKpBKkVZuUIZYqg+rYSqpFmnaa/ZmTMs4zUG9YmxdjEkZ7CQgxJOK2Rc4IR 0oSBgKKF3AwqCoOivYgQ80QJwchTDjMruhdK67HeHOvNsd4c682/rje/BRgA WXIAow1lbmRzdHJlYW0NZW5kb2JqDTI3IDAgb2JqDTw8IA0vVHlwZSAvUGFn ZSANL1BhcmVudCAyMzQgMCBSIA0vUmVzb3VyY2VzIDI4IDAgUiANL0NvbnRl bnRzIDI5IDAgUiANL01lZGlhQm94IFsgMCAwIDg0MiAxMTkxIF0gDS9Dcm9w Qm94IFsgMzkuNjg1MDQgNTU4LjQyNTE3IDYzNS4wNzA4NiAxMTUxLjMxNDk2 IF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yOCAwIG9iag08PCANL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAyNjMgMCBSIC9GNSAy NDcgMCBSIC9GNiAyNDggMCBSIC9GMTEgMTQxIDAgUiA+PiANL0V4dEdTdGF0 ZSA8PCAvR1MxIDI2OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMjQ0 IDAgUiAvQ3MxMCAyNjIgMCBSID4+IA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8 IC9MZW5ndGggMjY5NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIidxX23KbyBb9Av3DfkRTUpu7YN5k2XHssR1PkE+qjpOaaqO2RIzAA8iO 87epOn9wfuCsbmhA8nVeT+UiGvqyL2utvfvvgUUJDUKyrMCmwHZpbFmuTYXQ 79aDL5QNTAxCiwJ8GqsnTJDv9+eDvQ8+WTS/wQITf7AssFlgeRPyfJ95YRDQ fD3Ym5UexaWaYlIZD/aOIouW5WBsMtM0bZrHOGT+MDAsfzj/jl29elerXoEf 2MUcxwxgiuUyJwhCuXG93lLrmWlPJnKTK2M+tCyThYaIV1kS85QiUZZJnpXD b/OTwXjC3DCAszbzPAuHH2DJWZ4t+OPQc1lgjHB4JO4qsb4WBdmm6ah1h/Pa kVlE2Nxxtv6PZvDgBLZ+h6nMmjj0IM0+o6tvJi0G/oQ5LkJl+iGbuA4CC1+Y jVi2r9JBJCPauVyvceUMn1lhGHQeq4hdGWb4u2OOLRP/02o4tvwwgNefhphk GXciS7Kldp2UC3sfLKuOrIlUslCmFO73wnhlfBlaExm7NM7XgqaLRTEc+wZ2 oetHOmE0S/mmHNHhDxFvquRe0Cxfr5OqEkIdoTa2HCfsNu7ld7biSUEyx2qe KwO1bUA/j6+acjG07ADZYkPpLQz7YyNW2YiOs0qoeRmv4DhPn5p1ZUwX90mZ Y5oVGI/wYJPFSUpfjePp7OuQlJXdMm3lGwZdMpqv8jVHcI5qC9Y8o7MkS8pK niRXPg5Ng/KbVyN1ZRwuNrEynni2oM+iFLyIVzBv/2z/A+z7alTX/OvwqYXv T+QfjNR338gfamNFUsHw/L4JnsTOGX/MizdszW9oXxRpkr3Tqk8NLusz17y4 VfZ8ZnSK9IkCRsyHoQXDNHufGmBcFPmy4Ou1BN+4zhYgBYI2PAtNGxwPezTT bxqWPaMwE5O5pu1TIEnkeUpfrgxFLqje76aimO14njFDAhG6iXEjBF0X9bPg t6RlwmQB6X8QhsaowA+YG/S5r9+0RvkvGuW7LHRlzJVR0pyxZWveu3KacZGK jBePLeMtzfnGVaTBMT2/Ib7KjHEuflRAK+Je4+1cVA+5TMkenV2cRg1RbWb7 kpM7qT/O7pNKLKiWW9/g6e1zKqOzVivA+fmWwm/trrgf1Nz/dFcla0j3UcGz TcqLpHoEcZRVNUA8Y5NlIi1fO7KHPOOInTP6nG/KW8nQU3bI6ITHt2UOzbiM pi9b1dlyGl3QRcpjsRZZRQ9JtaI/8wgYzMBwnmRVSUn2nNwcJBoxkSju95QT OtQ79s9/2w7yCTtjdAT+J3xEU3jA49UiGdEnRvvFBrZ/QIBi0UHvmcrUAHBi Wsx2+qzQb95mhR9CK0Lf3qm6wKKtCOJqgriez2zjFIK66nPjdWr4+LXRf3SW 6TdvU8P3HeYHpttQw1XU8DQ1PDMwLnjB01Sk/4QZWznoQOcbBb+pdfMmiekw WyaZEAUETad9lyvW7hYTvcVkdwuAhz5FFx86Fo7pDfWdyup7jQ0WNL27KxpF B0ReQlVXY/2aZxEKZy5WKWRfGadAtp9kP0W2ysVN97qraY/N5jutnxsgI57j bbV+Tzu8yQsdniMlTjYk6PBQtxzbeqXDkzRKYoGacY+8TpcaaDUzeYnCScdl uRFSM2p9wtdUVP3YP40R8sRkH+WjbkYoP+KuHNe/d2JEnzeAD1j4L9157LeT j1E2SwE2HohM1rRtfJlbmjvNqC8AMvFQkBgNJ93kBUW8EmkKYW27pJe7KSk8 mKy0u6zjuqWD9gSo1sLahA7pPcihnEWN5xFBX1DBkzxN1LNqCzxDoK2yDZly dFe92TUM8K4HhB03n/aUaGGSxQYK2vis+prTJLulGb/jsdT2L0PHlzlKlquq R6e+isroHHbpS2Sq30GpN9TWQCv0UWQLtDBLuMeUoP5MR7TPKKp4ld/Hyfgj T5N1orjRPMpoY3WdiOkGBSDhuzVkNxp2C+OmyM1XRXID55uC9pK2ULXS1N4s V7iAnKI0v6/sqXw3QeK3v+JS+TArf5U/f7XURvMV/eTX/x21VGGyT50hQT1d +LjJlrxpmbWcN6Sl0MWlzIJ++6bHQjvUL16Wbwe9j+macikO9P3gH+i3/ap+ 212zcXk2j3SiehQ443EjGDkdJJK6EoFHqOASL3JRJ8Gyyj8HxlmKnAutOwu6 LHFXPJCtfnK9qdrL5o68KKzFt9AJBS6puyPZi5+K5DpLqp/PyexzPcl2Echo invOYwXU9KrAD/QsqqmDBFYrQZd3aZ9xL1WWBjYIBN8KRd3vfBSt0/kSfSP6 qec4+EZT0/cecDz7z+K9AtNvy6Tfi3vZ/exWPyWksjVTcSmTUuf1VaeNz3yR 5K2/6PQyeVXZ1tVdVy5Z246K4lYoMl1oF9BWjwiN5ilfA2SjtlNW9PqSqJtq 4/YMXV4uiuVImaiV5cp4bzj6shKt8qJqDxPFmg4eM74GPKJHgHbdlM0oWW/q 2vF6WJrqVKqobkHifSHqBeBJcHrhG2KRfCuD2Ebj3XDYAi/OgK1rCQ06vOfp piXC8YWEgqLDs3CAJquwhTBEk1tpe0o1OqZxDBXSEXgD58B2xNcrXu2kHlfW lVjs9u5aTH3PYxb6s05N9Zt3yKnvAU+O80yj/h5ldd5W1i5C+V2e5stHOssX uIepmj5d0Mc83q62LwtXvVFg5A+8Ie+irHdL66on6FhxBDVHdSEdqPXZL3fI jdtzvQmPK0g97pONej1AzdRZz7QEaIr/vco3Eq8nkKc8WxR8qS6Kf0ioy3uM CjxuMCbz6IHkRcYLkRXLdlmA1tVGVXNdD2bhdjJxqBADF1eo0A3JC3zmOjK9 0eDPgUXLwd5RhJ8SzwkNnJCZnoOdAovJkCOXzAxd7GQz35Ub3fxWg6AxOFCm BKRaZxyFxJvYtN8517JwUeTLgq/XhGjS8XxGQJfp/OX9dTMce2GIjBZ1qBBo 9vePBZHpM/nXIcI1z54QcILGFOs1ZC06wu4nOP871ZEAFs/o6ptJC3givbDl rU4+eQHwqx7UK6d+Sge+4zJ5HWnmdkO1wPfbofqKuLbDVG7s2egb67sjBp6p BvIgz2s/OO2gO65b175pF+tDuy30ud0+0WBvVsLbWYQ0RLNzIMFWUPh/d1vl vEa9IzHpBBJ3pjzQN7th2n71nEBb1EzQb9IBqBJMAub40ks5cEw1gDGerY7u Prdv2jkO7gz1gXW826GKoR5qB7sJOggyXoHnNvsjXnqQtp53n3V0ujndebX7 rr3lfjvEFdEPAjAZHPPk2KVuKQYxdnKYY/v6m7m7sBdXObkdYpUlJUKvhnk9 o3w1+X/sV8ERwzAIm6A7ZIKe04LjzuP9dyhgELEfffXpn8EgROCUxIvqVRL0 xDvjno8nB0avZWDp4SdZbcNnUSkNSIhhZ2sZURaAeSeyP5ZS5V3RHss/xVTD bTSJgOAYAEsX3TYNgxVhy5macYoEi4TbM2o09k9T/Ngf+rKSwYTj5EiyE0WU GhJ50REJtQDMj0LGC8Xdhawbs57rnxvJbdnI9Bgb/W7gG09AoJEqp4/sHCKo TgAwwQKeQREAzh4l0B5IIKLNCEsX/Ye0br3ZerP1ZuvNv/XmK8AAQo3BAA1l bmRzdHJlYW0NZW5kb2JqDTMwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1Bh cmVudCAyMzYgMCBSIA0vUmVzb3VyY2VzIDMxIDAgUiANL0NvbnRlbnRzIDMy IDAgUiANL01lZGlhQm94IFsgMCAwIDg0MiAxMTkxIF0gDS9Dcm9wQm94IFsg MzkuNjg1MDQgNTU4LjQyNTE3IDYzNS4wNzA4NiAxMTUxLjMxNDk2IF0gDS9S b3RhdGUgMCANPj4gDWVuZG9iag0zMSAwIG9iag08PCANL1Byb2NTZXQgWyAv UERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAyNjMgMCBSIC9GNSAyNDcgMCBS IC9GNiAyNDggMCBSIC9GMTEgMTQxIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAv R1MxIDI2OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMjQ0IDAgUiAv Q3MxMCAyNjIgMCBSID4+IA0+PiANZW5kb2JqDTMyIDAgb2JqDTw8IC9MZW5n dGggMjgwMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidxX 21LbShb9Av/DfpqST9mN7pZ4mTIm3AYHD3aSmZDUKSG3cQdZ7egCx/mu+cBZ 3ZJ8AZswr1MhILX6si9rr736Z8siQa2QLCuwKbBd6lqWa1PGm7FF6wulLRMv oUUBPnX1Eyao8ZNJ6+jMJ4smMyww8Q/LApsFltcjz/eZFwYBTRato0HuUZzr KSblcevofGzRQ97qmsw0TZsmMQ6ZPLcMK2hPfmBXr9rVqlbgj99jjuu7sMTq sdCxLbVvtdzSy5lp93pqjzujn7UxqWfEc1HwuCizKKEzHuGhGuc5yRkVc04j +cyztueywOheR890G6VTuWh/n1zBnq7FLMcJaXKKPc+zaDmnoZzyRC2+TAss 7FqBkfLimD7KQm2a0ljOCroQPIvWNqyq/Tt618kf2z7fGZ/bjo+PZZJiyb1I RLEi2EDDMilEHOWFSB/0wqMzy6pist5C+21cMpyeZTLv0AWjWy6KouzQmUgT 7LMTTO1RGLhO5dEE/p/UVspoqg6jkyjnU+pP6ULGdCtLdTyNmkmFjGWyLzjf jJPBye23NnWpD2ueEKP+crneO57TTGYvtj3kVR0YuHWelfcIcmgx3+jQgNEw Koq54DlPO3Suwu8zy1hE6are64WfdmXcMPpLLMQv5cmHmTLJN2YiFjyNVyRS OklKXkhZzGkkYols5vQpb+zb8XMr6ip6jXvlw3xZFnSzLMQCQBtF8SMvaCx+ cRrzBPgTwMU3Y3IzGn9rv/b6zhgzGkfZY6Rd7cHVs7ZlB0AFGzLqpz/KRYdu GV1FAn5/Gvf3e6uzaox4hlAjJjGnyzwvgUr4OOZpjgR85MWzzB6VcxoXjRUv snmh7BGF1IAaijRaiA5OX0apPvnDpKrnwZhMFqz/jwfY5wrF+oMsl1k9h55V 3Q7p7rtJ01ZVvxS6HuvZPRCLYwbMBpc0I0lrvEMom9Lvmcw1bbXWZpZO6wJW Wu6xaXYt79gxaY5K9MzAGEUo9QToG/M8V2F3d2OFDDqm5+9EDEBNUGk6S2Oe PfEsV9FBTGxm+4pSVEy+qDoNDX7fzKEynfKMbvCcoHqOAe1nGsdzPi2Tvegx 4iilC54sd2P/EvcnTO2SST7dQB8wuIiyeC6T7kmUFOsPbay0jL2Q2Ni+g9oz FDlHnQ9kmtbIPBNZDgZD3fK3HbgzRhKRWula1vHobcVjH7AH7BQAKrMi6tCk bVkmVrC2yWxj1CC8bRowJkuiPMfmHRBS9Eskv3WnDpauuaq0FZtf336ifvIg M1HMFxszfWXmACz0mnUO1/eOhVeo4/RRPolYr/eY67jApg7Kf4A9y4JPHTWz DwqOpvIpSteze8zrOfb+6a9S17UcGNGzd9F3sbrPxJS2i1t3IuU4mtHNkqfd aymXhzhr3Ww0Y4kpl3Qq8iIT96XGwDMCRp8Ht3RWphoVkWpE+1IK/y64SKfJ SwauofqB0Qm6Xw4SBI9lytQ3kokMKgKW8eOmz/iGvG864YenKCmr0lTZ/Fx9 F4gcXOjKtPsmSRunfKF66XgF0C/yV3V3Z1yhyZTgOTDwYB6lyvwv7Z5TU++X muDThw6Nbge6Dr+Wj9pt5fS6o++gRVXkpGLyaJXINan3SwQccUUt/IPhwGZO vXtDrSbEjUPbv0GsNXn6MM037S3ybEbW5PlKNzXk6ePB9AKnJk9Fm13LB4Uq 8rQdzzMGclY5POOc7hupFD3SxrQdtm+McgNmhts2VQOH+byRcr7rMs/1/dok X/N5r+Hz0POZA0ZPQecAa1xWjP5mq1eS5qzc6DxVHEMJMHE6jYoITLNYlGnN 9vnxPo6reApMH8/VxESrsQ8QBnKhX/v5EsS5h+52Kg1oEtkSdSBTUGsCGVNU cAIXoUGtmb06zTe6gHRl6D5lo03smWbwEuA6Oijk/JgKSfccxqYSJcxr4fdC m7sBwOA53o42fy3BwwMS3PHdKtbv0eAa3hC2PJ9GjQImG91iiVpEPMg2TadB Vr0zDgkD1gsDoMk3PRba4WboMJ4cH4BzTb3cY7bnhhWizFAjymwQ5apaMEag 8ihbrSWCTW9phAZYlTdZ1JSIiBVjZFGMbix+VRT1t62uuEXVTQr39jDjMn3C JWVKRZQ8vqHKqtR8/PhS0O/t85s8GF/mUUGnEjJQNcghhwZRv/7+xlEGaO5W qVpFiDeQI8uoyKELFKOrfnXQAtBgo4lnQHK3ukzUPPd26EA9b7cuVbm87g+x QB1uOvsY8TtYj3U3/8qQf18puGtRKiJXmvtnKRJckgquLxf/Usw8Zl8Z/bvK IuZdr5d9nWuibvr1IaJugBw6LnOCcAvHzchhpl7DOHTAsK7Xq3nR1FRtvYeq DzD12irTYba5XV3NyDuKKwhD5vtuw9aWri377dpyfl9bRn0poRFSkSoZoAj3 VCxwZcEW9V1lB2fG9le6EA9zYJQDapcj6scxzm5uOvkbMN+B15Y6NehE6Z8p urJu6vXgTSKexEZ5K1GoykQxe/4OpbODRiWZBTRcv0rcUySSRvHgsrZWZvCo 9mNfo+rXaYesLdCR1j0PvWBLNqlgriNbXQh/07qG+gIil8uO8nBLcuFmJdN9 7ekdHjdJbuIsF/Ihi5bz1TEspEswAcx94nQSrXgu6ovmoXRVXNhHkla5eC3r DjSksXJGF3ZUKD+gZM+z6ImvGoH2zhzWYeojShHSlvBKIcyqQIHdBE8LkGwx l1OZyIfqvnSWyOd9WRwCxAUuLMgOUq84+jJVF7yuFSDEKS/2iXCkaIjbUhrt y8bvqMkP8Nfd4oB64B3E5AcWc0I/fNH2wQa25ii34SgX2s02rqFE5v8DPfme UiU7ptUj76An38PFyTO9mp5cTU9eQ0+eGUAsQX4nUJMNO3m/Z6dXqENjLPZx 0gHQ9aleoEFyy3PZ1CnKf7QuWfBBVa5jXBEKXmFmvzp9rUM+pA8i5bzB0I7G 3RDhfhhdcMhq/qIY/N1iQML+2bLooXV0PsafHM+CWk6IcDuQgsCECpbj2Myy VfBsBm2f8dbsjypn9ZGBTllAWj/29D3ExKbbgatiNsoUNywWhBKgy8mAAAbT +dP7c9buemhCoZFVRYLqYD//mhKZPlM/DhGAaPcIGQYnQmE29lt0jt2vcP4P gM6jZwWdId19N2kKT5QX+lalnjzVDfWDHnKqp6Tlo4HbPb+Zu3nVC9AZm1f9 1TU3r4na2LNBPbZbneJ5pn5RB3ne+oOzftkct1m3Hlkvbg7dbNGcu9ln3Doa 5PB2MEYaxoOPgKetAvB/77bOOfsv+9VuLDEIAyu4HlyBBxsJc/WQuv/4JIFW mOBFL3TGgj67QqOBLlV7Mlftu6QJSwp445RzdUbDwHfuj3x16lX3XFSlAnmi KRAyfFrqOMYObLI+VS1hrzeg1dChCwwDL4LWq8oXqseXejm4oTyOvTphE/m6 fDof8gHloVvkTyjDZv+yYtrCVUCTSHnPZ/GztDpOdVVjQPE6dES4t9CbSBUz Hkn1KAgOx5lxi/LEhdG5XFjs8E6W2+KzTCk1iBAdh7SwSEuAZ0+EPpZUKRfI Y6JnjoEhEgbO0QMsKpp1Gi5WBlvcqYFDRvB2ktWoUu8/dRnL9tEniVyMbxzs TrYit1Iglhdt7lASgo2lkBmJ/OyC18SsRftHR3JdOjJ2jE1h3nniiRAQUmT1 lZ6DBZVHAECwwE6niACDPVJAHkjAoj4jLCraH6P1nTfvvHnnzTtv/nve/AQY AAm88z4NZW5kc3RyZWFtDWVuZG9iag0zMyAwIG9iag08PCANL1R5cGUgL1Bh Z2UgDS9QYXJlbnQgMjM2IDAgUiANL1Jlc291cmNlcyAzNCAwIFIgDS9Db250 ZW50cyAzNSAwIFIgDS9NZWRpYUJveCBbIDAgMCA4NDIgMTE5MSBdIA0vQ3Jv cEJveCBbIDM5LjY4NTA0IDU1OC40MjUxNyA2MzUuMDcwODYgMTE1MS4zMTQ5 NiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzQgMCBvYmoNPDwgDS9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMjYzIDAgUiAvRjUg MjQ3IDAgUiAvRjYgMjQ4IDAgUiAvRjExIDE0MSAwIFIgPj4gDS9FeHRHU3Rh dGUgPDwgL0dTMSAyNjggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDI0 NCAwIFIgL0NzMTAgMjYyIDAgUiA+PiANPj4gDWVuZG9iag0zNSAwIG9iag08 PCAvTGVuZ3RoIDI1ODMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIncV9l22sgW/QL+4TyKXqaiGeE3BtvtxDgkIu2bZmX1kkUBFQsV0WAa f/09pzSBMcT39S7HsWo88z67frUMENDqgWF4JnimDR3DsE1IeDW3bj1A3NJx 0DPAw6WO+sINND+Ytj5cu2DAdIEHdPzBY57JPMPpguO6zOl5HkzXrQ/D1IEw VVt0SMPWhxvfgGXa6uhM13UTpiEKmW5bmqm3pz/xVqe41ShO4B+3yyzbtVET o8t6lmnQvXja7Hp0cKbdxhlP2rjoanO5DkQM03bPYI6WBItieiFCuIqXIuY8 EfEStiJbwVjEYh1EMLiZtH9MP6IaHYMZltWD6ajUaSjjhVjmSZAJGaeFfoZR KDj9o7TBUDaQPt1CH5/Bt1UklhfwmcFAxsEzj7M8aXdcjV/AgMGXXIpMxPjN o6XI10p8bTnqYTLTpdtGLa0fQ38ebDLxzOFOBnMYBFEQh2TFmGcrOYeFTGCc R5nYRJxUPLBDmwTZKoVvKR24juQW/AytSTMRnrJHxUT7yuBTsA1WQRJcwMdg E8QH4TlQcs8PM0353qt83z3yPYbnT8GTICmWw5UIMQjKgM6knJTPYo4hPRGV e55tZfJ0rH8TBO2GQX8j00xGciPzSKYXMAziYB78zgqzsOL2ZgJ3In6Ch7bl YgZxsVxl0E9TsYzXGE7ldWWqi6bGqaA5OnBC6Zl2HYgoL9OUp2XIf59MfQb3 eRgKlTh+uEokJ9eg4K52AZhqg1WQZUGIgWp3qEC03Q4jds8q7YJFdqGkoQzt m99HRzAYCZldwLdP5I2raVGlQx905tW//hA1/4gl+BMMmxldC7ZUjWOY/dBh 3iqqEnq6y3Sb4MLSPWYiQlQzUcs/gImmoLs6s3WTzprM7vVUPc80w77U9Y7h XFo6rNAUR/cweZMgingEPkfPyxjcw1JBn1m645K3e4RR6O2Z9pWnMq+yi0M/ imSoCrgKTRNy3BzMhYRXR8aYKUuuwozZ+jAcjfudQZDy+XFwZ3U20tarNU+W PA534IssL1HjKNLaJ6wtmcx3jxg2FcN7macCgYsjJlyLGAt8/s48RYR65klG hfVF+jCRkSDpGx4KLDylASqWSbjOX152x/rvZZ12J5dYq+TzNUdEPYsPM23M Jm3D9NBjDK45oRsztBg15y8XgFk755ho9Za2rsGEzxP5QnDCruujX/kLxzN1 ihYlPkiCFxG9C3H2ir4fB9EuFSmg0QTdMlkjVHIYkTlCFjCuKhd9dQSVB9ZN ykpFJKLEQ/9eQh+xU2KhEXgiumyqLRjFs+WMta/M9cgNzNK+740MDVEDy1Um 22B3pg/MtAG6divm2arjY61TwBENMEnTgwZQAulxoKmWsl1VSMex1f5mqEmO oEAQgfAxDiKZU35eJ+TEC6AjuHGm/YX694qQjkVK/WGEccwfeZxmnNoaZrQf rIq7zto0bRuGjpDF8a6Ih3K9zuMya1MoCwuufuUiEo8JNkrVuN+yLREYZnQQ ttYgEtmuIxcdnyfPND2kHhZSBrzd9WbU664i6L/I/AVjcYWtI8owcxrT7xg8 7BTLUJC6b9grEmR7CG6O5RyQoGOuY5TAa7k2IVfJbfBj3XJ1h/XMXjNVAmmD n5brIcLq6pTNbNswGyFH/eNdsNo9B6vWq+Io+9mYB2ndzwgr02N8PaHT1b8b jAan0kTQLC6ihC6IXMfwtJhnSHTCp0cZ87dA9y2S8VfbsXEOayN4FJQElzCW cx5h60emhBmiPiqlu/tKU/5T9uAylfobKTLGDJf5ckVZ0Yebgszx+BHxXjXU T0GEGcOfsEzKC1+BJRbIOuVbEb4Q/sF3UrarBRlHrb7XKNlRiPA3iln+rnr2 kbuPwJ9kSSAykAsI4Gby1UeiPa4CfGjQYe2gMp9EtBHv6Dza7Rxd1jQWlDXh yR7MLhNkWGXPgdvJeYitG2dBTqerCk/RzZs82yeq59EVnXst+DxqaNGkQVgN eV8SpamkwDFiU6Ic+VtkUnHdeGbUlqfFDXmWhqsnBLAb1dg0tO88ODed59Al t+sNQg/NjhIRRZ2R3ManmrBZ8WfCRE/j4SoWv/IS3ysa+tiQzr23TZHnZ92k DdmfDP4jEK0rpB8zAmpCVwx7VsBck3o14GvHzeB0iihGhfEnBpJVbD4N5Wan XIMljZU94lHd7N5MSkV7B4kUc3kB9BIRpBQC8z0WbYZqYKiGUbBY7F4D8h6m egiOpFUDqdXMaWpaQ6tnkDa2QtZXGLpv+3mknGkj/szxBUL5PZR5jCiE8Sxj Sbm/kptKbeyDlgX7/yMDr2zpuiYzHG/PlmrmdHfoOh5zDeToh80BWwIZ0jFc NIpagmk5DvLICkk5h8cKIYMnaNQ7eBrUimGdGYr/14qVM+9wcte06x6JarnK y91LKFuVSe+D42bl/S/NShtP7pAWB9kKPm8ysRYvxVOgQKYTT9jPcYRcvAKD cy/ZG3V9hWSXb7Wq66oK1uCvEKV5mnWUPkjKR5zek8XbgvoL8fhTVVxmVJ+4 yhZJzlzRrrHIiIDdEuOKBefq80HMfwY/g991EE09cEcC+2DJcRWFuvMnB74i /DmB5BUA7zsB/HyzkcWTZCQq1xEZg6trJWBw1WDuW40cKztN+RtwpiD6odiY k/k+vR+wxNIDAPjSMmDZwv6Hf1L8FtCyekx3LCRMHkrD5LQsyhYTLTKZa0PC W4s/imwtpXkqWT3AvcjDLMpQHS/dJzQFl5kkErveeg2Gx+B2OgQsA936x/ln 0e44vR6S26TgNUhp2K9/5wC6y+ifBWCYl2YXMLFFxsE0K/0NuMHbP6L8n1hu DmypaMYw+6HDHC0hK6jg1JdCAPWhpqziK2q5ls3MrlvtbYbqgOvWQ7Vq680w oosd02VYnYUUx9HVgAQ5Tr1g1YNGXHOunqkPV0KbKyq5zT1+68MwRWuHPobB H94j7JjkgP97s1XMWWEq5aTlUd7pJNDVm2FUrzqWV2lUbqhmopZpgNf1mOWS lTSwdDVAZRxTiW6W65l6j0XdSQks/F0PlQ+rYWVgs6FyAvnLQ3Zb3I/+qgZR bXmzXHmn2dPIK8y3zQPz6yG+r1xsHYhHrOfQ2IbmKA5CvMlilulWa/rrg3t+ pc31EE8ZBBHVaVRvTylXbS6F0lKjYHlwX+OwcU8TMNt8FbBmxmG2kq3udyxT bWiuKMaNac0O/dUFhznR2OegKN1ya/Mc2z6UUY5rI+sNlY7VBa+sCFWm1YFF YGtiqgYGQjD8l90qSAIQBIEv6A+9oKkZRHuP//9DoLBqh04duSHBuuTOqtz4 +o8Kdf1pi4V10+esHIwnruRNLSKv0oVUZtq9gU+AWShkbCP/ltE1MatD/kOR 8mxaFTkyjQ2ndKSJJyAwCEt0i+ZQQbwAYAkWyHSKADD22ALjgQQqyorwmqJ+ WGv4TfhN+E34zd9+8wgwAKTTOvENZW5kc3RyZWFtDWVuZG9iag0zNiAwIG9i ag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjM2IDAgUiANL1Jlc291cmNl cyA8PCAvQ29sb3JTcGFjZSA8PCAvQ1MxOCAyNDQgMCBSIC9DUzE5IDI3OSAw IFIgL0NTMjAgMjYyIDAgUiAvQ1MxNSAyNDQgMCBSIC9DUzE2IDI3OSAwIFIg DS9DUzE3IDI2MiAwIFIgL0NTMTIgMjQ0IDAgUiAvQ1MxMyAyNzkgMCBSIC9D UzE0IDI2MiAwIFIgL0NTOSAyNDQgMCBSIA0vQ1MxMCAyNzkgMCBSIC9DUzEx IDI2MiAwIFIgL0NTNiAyNDQgMCBSIC9DUzcgMjc5IDAgUiAvQ1M4IDI2MiAw IFIgDS9DUzMgMjQ0IDAgUiAvQ1M0IDI3OSAwIFIgL0NTNSAyNjIgMCBSIC9D UzAgMjQ0IDAgUiAvQ1MxIDI3OSAwIFIgDS9DUzIgMjYyIDAgUiAvQ3M1IDI0 NCAwIFIgL0NzMTAgMjYyIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxMiAy NjggMCBSIC9HUzEzIDI3OCAwIFIgPj4gL0ZvbnQgPDwgL1QxXzI0IDI0OCAw IFIgL1QxXzI1IDI0NyAwIFIgL1QxXzI2IDE0MSAwIFIgL1QxXzI3IDI2MyAw IFIgPj4gDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdID4+IA0vQ29udGVudHMg MjkyIDAgUiANL01lZGlhQm94IFsgMCAwIDg0MiAxMTkxIF0gDS9Dcm9wQm94 IFsgMzkuNjg1MDQgNTU4LjQyNTE3IDYzNS4wNzA4NiAxMTUxLjMxNDk2IF0g DS9Sb3RhdGUgMCANPj4gDWVuZG9iag0zOSAwIG9iag08PCANL1R5cGUgL1Bh Z2UgDS9QYXJlbnQgMjM2IDAgUiANL1Jlc291cmNlcyA0MCAwIFIgDS9Db250 ZW50cyA0MSAwIFIgDS9NZWRpYUJveCBbIDAgMCA4NDIgMTE5MSBdIA0vQ3Jv cEJveCBbIDM5LjY4NTA0IDU1OC40MjUxNyA2MzUuMDcwODYgMTE1MS4zMTQ5 NiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNDAgMCBvYmoNPDwgDS9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMjYzIDAgUiAvRjUg MjQ3IDAgUiAvRjYgMjQ4IDAgUiAvRjExIDE0MSAwIFIgPj4gDS9FeHRHU3Rh dGUgPDwgL0dTMSAyNjggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDI0 NCAwIFIgL0NzMTAgMjYyIDAgUiA+PiANPj4gDWVuZG9iag00MSAwIG9iag08 PCAvTGVuZ3RoIDI3MjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIncV1ty2zgWXYH2gE+qS4LBN5U/RY4dO3HaiZROzahSXZAES7Ap0s2H HfW6ehOzjNnJHIAEScmS0/071Z2EgPC4j3PPPfijZxNJeiNi25FDIscjQ9v2 HJIJM7ftfSNJj2EwskmEn4b6CwvU/NtZ7+wiIDaZ3WEDw3/YFjk0sv2Q+EFA /VEUkdm2dzbJfbLM9RJG8mXv7HJqk3XeGzLKGHPIbIlLZs89y/H6s3uc6len 2tUO/BOE1PUCD5bYIR25jq3OxW4njPTGcbxOM1lstnJJpmlcFjJNSHpHLmQi C0FuePaQPpGLuJQrdQODJ9R23RGZnddXfy5FKfLqetuu7p/9UptoaxPVdaFa PLc+UTJ+4Fl/ZNPQGpBZ9VH2mZU9iJ2Z/kBhzCbji2bm63Tc/z677r2bVVGZ TAmjUfNnOoE113D5ntgetUOXPCvvb8j8OyOrXhUFzODDRgy2PZdF1EFKmqm4 N91LTBvCkFGPOXq3S/0wHKkQzi02esPY0GZvXEY2/aHtuMy65RmPYxGTqchz FUnb0VY3iUFUXOYHKoqjyHNVFK3Z5JbcpCsRxzJZ10F2qBOokJ3jojH5re97 NLJElvNCxqJaTe7SjIzz3XYrigzZU8dM0zLrI9GhtURKqptNTvZSpxPxxBNy kWb9YWAJkRcDckOR8GR1L/IB+dYPXdxJkRkyXW6ETDY8W2HRbCP0ychxBYBP otiILMbGfA+Ee260GLBuRQbTtzxZCjJOeLzLZa4gpxzAWc9p9pCTjylfiZeQ 6wB/bi12sNINKMxfVEgKrIzfqQAE1p1cHgRgH5Rza9a3bWZc/E9ciCLVO1zK ApQse3HfX38NyIDc9m0nQoSxjdoWcqMtgLUqkJhJ+IBMEcg0Tv6bVUYNyPsy WQP1QzuydgeIqK/rxKpjpTVOyFVSiHXGC7Eit3z5IIqzizh97oAAgXsRqKNR flGkc6vyJjLefOTAbQwP3lfwWImEvBXZeh8bJv8WsEA66R+QL5R8SFN5P1AE ouZOI2Ju3ZSxgvMT3Bg/PtbATflyo73S/qEiyHSTZoV2Ul17Cg4VFuu6+9t0 9BV0tAP2ueKcdxg8IdBAewLWM9SjpuMCkRyQCSVvUeIPvBiYGMyti0wF2QCj CeV5uRAtb52KwVXyhOvlGoUNV3UN4wM13i1lpGDDnySCIpOXQQCS5VYMa5Lg 2U6dNOGPfCmLnako1LBIeCbTQ1rQLowpORcVlENLJCu5LCSyOVbuynS53MgB uSoAIsPBNaGGaFa273b41Mz8nE7DwKEBG3n/hE3d19jU0bg3/t4CfYmKxA3w mVbUdBB7TRmRoYxQUQaZADxFxmVS5Ci8vBB8pblpj12qpTdc8a7I3xxLiYr/ QsaykEKTG0cing9hXqSmAXYP3mfXCWiXLwuRyT+5as4vkN2F8yX9RME9txnP 4T3XGfytOljmm2ee8GLzM0yi3xisIPs5WAcA3wodVFWXX9JFmRcGV68xNKuM us0qRk6fpMqianKvEXPXH9jujExBQYssyoef2j+3zncJV3qmqYFbE/TGAhRS Exh9elaUPAa/FpvhsXRWgWi609dcnfEFTRERMVW6FUlBPgpN89Ba1nFPX0ig S2gdvpHJwICsEUPV3gOh6EWoH9/194TiSz3on9CDbuBVtbInCE+E/2iBmKA2 rVuBYgqUVmsQpvESVZE3TaKJ2jN0JvmcTsmvi3sBhgHzEbQI8hX0mRWoOWVz A/xzsW0lxVG8WxN6TnVPrDDxSqsZk0s00Ge+g7BY6joijfLVDrzfLTK5QiYK pcMKcQwEytZKNMDNzPgLupCAziTdbstE1ocbn4/l/60q0X/Vki4daMLnj7UO G5CP9GK/kbQambqWXpWIBj1fPxhKrjOLJMPAER4l217AfHyN2qnTrOwGEWUe U9sZuD2y/wktez8XuROEtYx51kbmkI/3pNYkzYuhaKWcVLUFJgcNovBUIgCy tEyKupa9y1PiwG6LokNZTQQ8ynzPq8Qe04rrAHHDesUJimteUnPrmpJrLjZI DlTypZGDAPHuFbbaU6RNzyq0rvpRDC8Fjqsg9U0axIEfYoSeTHfoT9tXdf5e UCHO3gpeLrIy0RL1VioUayuBO5iP5qdVDvrEir8wus1mV6De8rWyuCs3kY/L 6U2T6Td7+vOUebq6pnILkBxtc3uBghi9gjwFny83Wpq+RzzEnja3oECLPx91 jwY/jEvV1mP5mltaziqggtlzCekLX5S0Ug59AWHxZK0hrJZo5nr9eSIhId79 eEwTYFcxhGn+6IQ/5Lby8vUXChzD0+tZyLWIDaSOA6oVQBqRQYVIPB7etdSt awieiexJXz6smtp7OJKaVQoChemW8TESVG9BhEQrdKXft2Il+VF9hKjdpAv1 XjXF/+Ld2DDBSUXzGbktEXgNWGihRAl1Q8LqsYGkf5m0T5K9DCB+/y4fOpV4 iAPQJojRdUn37+mk4dLQdSkUSIdKzUzDpEc6bM2koTOifuSPDhrs3KrodIgW DHLVtBp6Lvh+0qRBCLIw1c4fSGtrRMyfrpXMo2Hkdq2sZ/4G34fMpo5rZLg2 CTT/Ot/7P+X7bmF/LkUp9EOu4itydVU3+r2o/Jpo2jO55ShhGbcvH2hofVAt I85lvjQROt6tx2VhtJlYN806h+og4yyTTzw+0Z3JB7kdqPcXrvlQt2X9PsTc JuOLXdN7j+jQNgTQoaIxkWvB+DEFazdidNE+EBY7FOaqTFbgz51mlq5D0WFE rxI0wlggMMka7EqaCHeJ9jStjOm14MkQelqCM/efr+GL52tbWxbU1jjDY1Xg bfgO33Gha6o6Qd0JjH7u2WTdO7uc4p8c35L03BFaqAu4R1CTYCnXdShD1wS8 aOCRTPTufqlgWhscaZRGRMvU0FXQZDj0sKGrp0W6xuNkS+wIHWE2IcA/c3/3 f7/rD/3RCCI8IzpYiSjoHz9WhLCAqv9dQgByJyQANdQecQJTYza5xOnXuP8e deaTZ1UtN2T+nZEVPFFeOOq9q778CBWmP/SUW33FvcD1qCLhem071BuCoBnq Xz3WDmN1sO8ENNQCTg18pgfqIt9vfnCbQXtdu6+ZaTabS9sjzL3tOdPe2SSH t5Mp0jCdfALfOCoA//du65zTylWFSVQccMfUhQFrh3Hzq+9GxqJ6gZmJe3hR RWFE3UB5qQYu0wMY4zv66vbnZqZZ47pBfWEV72aoY2iGxsF2gQmCileEp0V1 PuJlBnHjefuziU67pr2vct9z9txvhnh7Bnh6gmzpyFdjj7RbMVjiJJe6TmB+ Y4cbO3FVi5shdtmKIsxumNcxKtCL60vVT62B9cauxcs2PG3CPOcgYe2MTz19 tz7fB0upBe0R1bh1rV3BDg7Yx0Trn/8/9qvlCkIQBlZgD5agLkSsh/57cIjJ RDh42iO3BPOZMXnzAK22n5AeHhZ9D/NJkgGO0QsMLKpuGgcLYYuZqrNDgtcj 6T8q6dm/lmJmXdrFFIPxgz17klrJo5qDyBMPRUuQjcXMBBhr5N9OZr2Q1Vj/ 2Mhcho2ME0UjOeNSFThZgkQE1oWdY0SSrgBdouDJA5EFDD1bkB5BMKL0FQYW 9UNap95MvZl6M/Xm33pzCzAAJ1vLgw1lbmRzdHJlYW0NZW5kb2JqDTQyIDAg b2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMzYgMCBSIA0vUmVzb3Vy Y2VzIDQzIDAgUiANL0NvbnRlbnRzIDQ0IDAgUiANL01lZGlhQm94IFsgMCAw IDg0MiAxMTkxIF0gDS9Dcm9wQm94IFsgMzkuNjg1MDQgNTU4LjQyNTE3IDYz NS4wNzA4NiAxMTUxLjMxNDk2IF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag00 MyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8 IC9GMSAyNjMgMCBSIC9GNSAyNDcgMCBSIC9GNiAyNDggMCBSIC9GMTEgMTQx IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDI2OCAwIFIgPj4gDS9Db2xv clNwYWNlIDw8IC9DczUgMjQ0IDAgUiAvQ3MxMCAyNjIgMCBSID4+IA0+PiAN ZW5kb2JqDTQ0IDAgb2JqDTw8IC9MZW5ndGggMjY2NyAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIidxXWXLbSBI9Ae+Qn1QPCWEn6D+KWm1R Zgv0qCMUHR0QWCJLAgE2AEotnasPNJ/Tt5iXhY2r5O8J22EWasnKzJcvX/3Z MkhSq0+G4ZnkmTZ1DcM2KRXVt0XrjuKWjkHfIA9TXfULC/j7yaR1fO6SQZNH bNDxB9s8U/MMp0eO62pO3/NosmgdDzOHwkwt0SkLW8cXvkGzrNXVNV3XTZqE MDJ5bbVN92jyhFOd4lSj2IH/3J5m2a6Nmxg9rW+ZBp9bbDfUdk03ez0+4749 TBbLVR7kMomDiAbZUoR5RskjnQRREIdiSueBTI+6hteORZYd/T75CpOGUdjU 4aRmWFafJqc4bHJkGLrmtbUjvU0nfOK0QwONxmmyyuV/cYzbFh36qtFt8iDS POvQecpWOqQOnvyCQzD77yNcvNeWOCbNg0WCZTLGdaad0r5Tmzc102Vf2Pww iCK6Fi8iopMoCZ9lPGNPvt90v5+f0+Sob2huOw0ei9MfZUh+skqLUSgK37Y8 epX5nG5FnsogymgVT0VK+VwQhy0SuSB/HqRsZ5xEMnzbCo/y50o71WiUZOEc SxK4PD4yTA8mtSuNbuRzEgVpskxWEc+NePF1MktgJJdZpwpLkT2rTv59+4Kj qZltIULxQVQOpN0XyyANHiJBNyJ/TdLnjJSrP+IyHiKSatoX6YtIP8z7GjCR A438YCXSItgdutToNJiu4qBDF0Jd2WgvgriI1NmkgPvQJ8Cm/ucPYeArsPxE hq0ZPYteGdYjuv9dp2mrgDf1e7am92zUnaV7molSq75ELX+j3prK6OmarZu8 V9ccS3e3CuO+bRhfdL1rmF8sneZAvWnp7TEiFUUAlY8CQJ2Q4W4GHCdYuuNy TPpc+IhJezIc01k8Z3AvRJxnXKpbcB0lU0QZ2OG1+9CpMlIZPX2Lg4UEMXT3 4XSEkG6iGbX8tljmSc57CuCeDW+Ob89OK0wVLHIR5OI1eMsKLllD7jpcCsiq wkb+cFmjj8vKOA6eE1XVcZbKbLWcB8sO3Woo4euAK38E5GPJa/YsO/TDH3wK 1BJFvlysIkVKNACLvGVScRIuXwZlnqQ5XcsX8BOitxuRwrdhEsfgMxyz696B wjjTaBDlQGhDTQWr9Srnv8rFP7F474ClLJcrBYOViIIPqYlJFKFIK066K/c+ 0HmE8NCPTJFIkOYgGvJByGLXqZ0OcBU/JulCxelT/zy1Y8TuvWMHUw0oOs/l LJJiFoNjUbrDIBN5OTkSETigQ1c5ErDRabZ880WEICMT4xJ9yRLcLoVKWUBf ExnnIMx4JjJ10z3wxWxebUappQS/VFmsZ3CHW9kbP3hJUhny/WzN6qH69R00 /Y1CRofttzvcl8BI34I0Uo3pjm067eSoy6mNZPa+j6aaQi9N7OfX+/YAKQZx c0ZCpFEV+Hq2M1BtMqV/7cfsJo/W8aI6OC6Cg/TN4HA+X+zGY+0u7WsN7l2k UoTIrM9lmIVJlKylE+RbMqkLHWKADBsmrb58zqRuz9Mc17SYSX+WPnsf0ael 6PP7sghh1Z126LP9a+KTjKlaeLJKs5x8sEM4BxTrrtalAQav5f51zI1FqqoH Nb5BMtzeB1lWUSkOu0TA30vg1rwJdlgItnGg8sxtZvmGTphE701r3Ae0LYVo ewizYzkbCrFUf70D6s9y7aINfS7/DsYgiOlsOhOb0WV7StEUUWbCugHCC0YO wPgpdtysFlB2OGNTuZhrykVVg9cOoNNEPMvneyp7/22vNfptxZLiApJSpCkL pgvthtXkKnsOsqLFfMBUE6T2arEMwlwpXHZKotEWjQZ/VSOeV0S0ms0hjffR 1QHcqYhUgN2jBCHtLlHWTWc5r5Rg0VnGyXLJ/WauVNlcpCx5sy1tfCveYlmA qNeujqgkdxCGzNqNBRWpXOYdOhHRTK4WP9uBmyQ94BIc4Zzd499qym3yx9Ui ZzHLHFTkIV4rKfLy7SGVKCm4EFRiZa4iuVPyeyIITvum9PJL5f8JWgBusVrm wWcKAwmQlboSVXXHaLjoXd1bkUk0Qi6Euo29SOYrdnufW2WM+k0guhwl8MWW J/sc8ZkMGApouuO5RM6WGSsnJE5mz7F4q0jix7dKKZd1TV7f1no6615Xd7S+ 2a+/HGZry/U03dZ5MxxwC+H7s3Ttfap2d4TJ3fXgZoeyDyiuQxx0J+unCG5C ODH7ggX7EnEV52KWBkqDBOGzyI9ZVZVPwcFyWSU0COf7koGwX8v8ScTZRj1x Sd4m8gnPH36zgn1ewItTEaOW0tl6WSrFe5Ks0HrQcVk9YXweiVXx4o13avpn q3AU/AUlvGBByI+xkpvcips4TOd+d3D9/XJQaPwPq699Cpn6xnoiy9NAlq+S TUl1Unh5maymuULnSZTEU9aBFYF8wK8DtI0YsXmDeAyaDqqY4QTScgrbgHq2 VwVuOI5yTKKV4uVx5XOeQMF82CtUXX3Do4ufmz6Lw/Q5qKnyCh/A0ftpYi+Y WdGtPUX8fDV94z7BEmEdtmW3+4D1dululDxIpPRq/OLuw+Rv4IV/Cvi8d4dJ xvQGuTspnEnSEll5d5SUPxPujHSJJwSAnAs4ergFf6Bx9XUddqBkr7m4UG5x +AaD8TSpaBV5DxF+mS0y1SoQKLkHk2004UjBoggs+ikwd3V2dkaeDuVp1NS5 jU8I411Idui7eroEEQoVZToU6fQ/AMAy4Gw3ZQqlUL7Zyjq+k0/xLMBjRTXK O9CwWOCI8WZbPhU0jNB1m6MKklsrCNDzry2DZq3jCx//ZfgtqWX1Nd2xoMM8 Q2NwWZap6X08HwxTc21KRevxl4KwSwc9xdceKfHWswqxN9vIQsmZaQK+WyxA zhpdTYaETqBbfzh/PB51nX4fTSklJsU0Frn2519TIt3V+K9FBLo3ewR6l7kg 06vai0EXOP0r7D+Rrjn0yn1jRPe/6zSFJ+yFyS8E/uV46DXqh/pkFb+ilmvZ mtlzq7XNUG1w3XqoZm29GUZ8sGMiN6ZdWHEcXQ3YkOPUE1Y9aMw1++ov9ebK aHNEZbc5x28dDzN4O/SRBn94A6ybHID/e7dVzrXCVcak5THudDbo6s0wqmcd y6tuVC6ovkQtvDM8PAYtl73kgaWrAS7jmMp0M11/qddYrCmVwSLe9VDFsBpW DjYLqiBwvDzHLs9HvKpBVHveTFfRadY09gr3bXPD/XqIZ5iLVxh4TOs7PLap 2YpBiJMszTLdak7f3rgWV15cD7HLYIqoduN6a5dy1eLSKE81Fyw3rt84bMLT JMw2txLWfHE0W9lW5ztgKV7QHFGMG9eaFfrWAZuYaPxzYEq33No9x7Y3bfyP 3So5AhAGgRXYgxU4xoEk1pP+e5AgbI6HL5/5QQKbRXZ2tBxDosA5OsA0RVGl YbFibG2nmgSx4P0i/UaZXv3VFgvLVv8tZDF+ENibNCKvqolUJtq9IZ4As1DI 2EN+l9DVMStN/k2RnCdFthNlE5kP7ngCAoNEiW7RHCooDgBIwQInL0UAGHs8 gfFAAhV5RJimKB/Wuvxm+c3ym+U3f/vNI8AAKF2o7w1lbmRzdHJlYW0NZW5k b2JqDTQ1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMzYgMCBS IA0vUmVzb3VyY2VzIDQ2IDAgUiANL0NvbnRlbnRzIDQ3IDAgUiANL01lZGlh Qm94IFsgMCAwIDg0MiAxMTkxIF0gDS9Dcm9wQm94IFsgMzkuNjg1MDQgNTU4 LjQyNTE3IDYzNS4wNzA4NiAxMTUxLjMxNDk2IF0gDS9Sb3RhdGUgMCANPj4g DWVuZG9iag00NiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g DS9Gb250IDw8IC9GMSAyNjMgMCBSIC9GNSAyNDcgMCBSIC9GNiAyNDggMCBS IC9GMTEgMTQxIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDI2OCAwIFIg Pj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMjQ0IDAgUiAvQ3MxMCAyNjIgMCBS ID4+IA0+PiANZW5kb2JqDTQ3IDAgb2JqDTw8IC9MZW5ndGggMjU5MCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidxX3XLbuA5+Ar8Drs7I OzFD6l+9cxwnaVO3buSenplsZ4e1aJsbWcpKcrPp8/Zm32JBSpT8F2f39kzT RKRAAvgAfID+6DGQ0IuAsdCG0HZhwJhrQyHM3rr3BbIexUXEIMRXA/2EAmr/ YtY7v/KBwWyBByj+w2OhTULmBeD5PvGiMITZunc+Kj2Yl1qEQjnvnV/HDJZl b0AJpdSG2RyVzJ56lh32Z7/3xrP6yCgGSiLH2fkdj1D2Hd7zOzCXsMCBJ2AU JnD/lULS8wPiuGgUYwGJQhddcGhIbLS63Up7cW27V9vOarvwT0CJS2192iWu y2xlfW0k00YSageBsvTeYvYbhw6Yg79h1R/YrucT23q/yeYr+Fb0UVdgCf7Q /zp7pxwydtHQIZEfbdtlthq7jphDQ3yyPaczR2OGRvhvKB3YNv5WRqDdEfGs uz4KMUt+FwVc5LyCeLVZKIt8a5EKbdH5FWO19yjqUM/H0Cpw8N7LbY+tX61S CHjkSwEug0VeQCIqLtPy174KVQsihYGD1jJfXXBvzVabokz4c99zSWidgQux eKzE+psoDCKUhGD+Y1BbgGhAXIzzNkDNVhs4/8XAUeqQMFI43Vs0UuAw2kSI uUrKmqYi48Uz2lOWMs/QsgYQ7xgeTu3OF2kimuIx+CCqp7x4KPVJ9Nwmtq/y 4ohoLIrvci7gc6kg5FkCs37EMBIFX9RyCzk39zDCHCdS91ijFS/4vBKFLCuJ tSMzuJ7exZ1qDb4J4uyX3by4I3DL00RkZ3CNiA98TIc1z55r1WdoA2MUn0hf JQr8t+/4uOLFkp/BzSZbcjzDQsvI96kFFwS+1DmUb9Cs8qzGrdXMas0oFqOX WmC2EsrelShS3Cp3cd6D7WMGKIhHGvTyzXL1uKkgXyBo8HY8HkNIbcIYh12E D7G7t94PP0D8XGK+wZOsVo27eKBYy4ynJWyUhXAj0JFG3VJkIt+Uuz5pNK07 nsgcRnmWyAoz5iXo63q5ITDlCHuscKjyM7jFUOTf+DMvV/IM3vFHnu0XzjYO U2PQd5nIbHkIyPUGEyOrhNA5sQWMOIbEXjYiMOVe/aP999aQwAVH5sKg/Q8d +EuljCV+DEZ5WXGTQ20GBZhBlwQ+SY7+fY6HJwK7k5VXucJ/qaDMBOZ20uZh /pin+VLWPl2kG1HlOcbt0KNtqIfJ4CaftxUBAxhmMEyXeYExX8s5TDELH1ER EuGr5XK9+auQGLd3BO549tAEsHjASmhqZkxMnYhiKSpZdr5rNjvSqBpOC9yI uCHbojSz83orClwPbwvcvU6E1E91/2EN9duO51mj3HAKcvZWE4LTnBswj7i+ t21fs/M64wYMedJWtK8oV5sz0K3xBOV6JynX3ssb61Mew39gPM+zHKOqy+9I jjWwDE0+wFWaP8EkT0Sq29ZE/lltDCSl4pUrmR6tGU3QIRJ0Vi4wgzRpx1WL pk7hWV0HByS+V1fTPrNDvIsoBr0VbfW8JzDhZZlvUinOQFefSr4rLR4Y8TRt D3y+PcmeaB6vhC4g5esWiSjAlcHjLBlU+QD/AOI5ONJxLniJFdn0K12IHCab tJKDy3yN5kE8V2GU+UEtWSMyVA1nLUVWPkhNDjFPcqyii4L/kGl9Ym9UdNVQ 4znezqh4OBFGO2zZJaDju3W21HOdY7MTw9oQA4gAaQ4cPj4aeDjOagqvt+vH DjEV3dHUNAKMoShQBrlPd3H1+lKaqCu0jsUduWKYVmvVCK4KdfJk9O5k+TAY 1lc+cZNobSK30VzICtMmw0FiLbKqjpBpbU/5sZjOJLa5CdKYqE4zIEZsIjGJ zuBT0+c9i2fL1ymuCQNGBEdP1w6RRHyKlGVH3dbLLOf4IaEu1cc9EoZudMhz 9ZztGp57Yc5+ieKMfVHgEhq4W+aZnZc5rrUuQhrzHGpIztUk5xmSsx1qTbEp pylSjeE4Fv0bjrvXJFcH2t8q28MBcweb7lBb6/XAM768wnJdiQQJRkUxrvL5 iqtJ8hjhXeCsXslMFUfNdUZ4a9g4zPId8zHhL2SVZ5rMPhYJJtLbsuAiPZn4 akCM5XqTcjVYaeVDnM+eS6kJWg2Ed+K7yDZHeHp7Ehhhx8dJGa+oSWyY8EfV 9eHL1aeDvNfTTsyfRfaQn7X100zCNz/XP9OfiEU9CsQyrXizMIxgvcMBuESm 4ymev5KZGm5PjXTj7zzdaAfRpzuBrN+EbK7cK5FCaveneSrnDYUfqeVLNa1i 89EfBDs8XbO0+dKY8nlT7mhsTaIvfjRsc+QtmZAr069gnJYIUaLiiZPQ8Jnj 44S0aOH7wQ3OxQmy/Xj5/Fj90xkwFmtsKGKBflSiy/hlwde6sSo6xlE0eZJJ tToZdYxjmubzGjtEYZSv15tMNhs7n2h78R8R8xGWb1Baj3aGrjHo1xzhFIVp va8SuPURk20tf3ATY5xvK0XQlyLFJMTBpx1RVYzw5nqC6byqozRN+Vwz+8kw qWFhg6NDptvsbb5ozMaR4g6/ERrD/V3DkRcNEfq+Q/xtmm42/gEN+j7WiBOw f0GDNj1Fg85BegyTtaxPKhBNdqSaGur6eJUUJ4KX7aCn4BzUpNB8dai7Wy3H 2LBVHCjFmFifJ7P4DVJBtkwFjHAqgxFeeCyxYjJWlcGf8803ecAtoxVfqYra jcunHoNl7/w6xj8lPkvoORGhnoODTYhzKPYKx8HvO1uBZhPfhUL0Fr/UsWqU hzpUIehpKHBUfCheuj0M1ckzLepKAxYSeDsbAeYAdX7zflv0B14UkcjCYQiT t8hERf74MwGgPlE/DgA2YjsAjKwqXIca+xlc4+3vUP/v2HM9eFIpM4H7rxQS 9ER5YasvC/XkqTTTD3rLqZ/Snu+4xA58I9st9QHfb5f6rUu7Zaou9myfBLZb a/E8qhdKkee1L5x20anrzrU77WGjtLvC6O3uiXvnoxK9HcUYhnj0AevUVgD8 37utY05qV1VOOqHKO6oUIkW0y7R96zmhsagRMDtpDwf3MAiJ4ysv1cKheoHG eLZW3b1ud1oZx/EbhTXe7VJjaJbGwU7AgKDwCj23uR/xMou09bx7bdDpZDp9 tfuuveN+u8RPHB+/cJBkSOSptQvdUVzM8SaHOLZv3tH9g1u4KuF2iaeYoghz Gs3bMsrXwo1S9aozsDm4bfG8g6cLmGvvBazb8Yirdev7PWQpJdBdUa871zoJ unfBbk50/nmoijp+657nurs6mnXrZCtgbDQX7Hkx15nWBhaJrYupXjCkYLD/ Zr9KjgAGQWAFaSWTzACaeuy/h6DCejzyypMfEliXuLOO1P5Rpq6/2mJhOerN pAfjiZu9qUXkVXWhlfrO8Aa5AGahkrGN/FtC18SsDPkPRXLeFDkyjY0wnzzx BAQGEY0e1RwqSBYALMECmU4RAMYeW2A8kEBFXhG2KcqHtYbfhN+E34Tf/O03 rwADABOrSuQNZW5kc3RyZWFtDWVuZG9iag00OCAwIG9iag08PCANL1R5cGUg L1BhZ2UgDS9QYXJlbnQgMjM2IDAgUiANL1Jlc291cmNlcyA0OSAwIFIgDS9D b250ZW50cyA1MCAwIFIgDS9NZWRpYUJveCBbIDAgMCA4NDIgMTE5MSBdIA0v Q3JvcEJveCBbIDM5LjY4NTA0IDU1OC40MjUxNyA2MzUuMDcwODYgMTE1MS4z MTQ5NiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNDkgMCBvYmoNPDwgDS9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMjYzIDAgUiAv RjUgMjQ3IDAgUiAvRjYgMjQ4IDAgUiAvRjExIDE0MSAwIFIgPj4gDS9FeHRH U3RhdGUgPDwgL0dTMSAyNjggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1 IDI0NCAwIFIgL0NzMTAgMjYyIDAgUiA+PiANPj4gDWVuZG9iag01MCAwIG9i ag08PCAvTGVuZ3RoIDI2MjMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIncV8ly48gR/QL+Qx7JCRHCDrBvFLW0VrNF9rQ9momJElki0QIB DRbJ6i/1zeGj/8BHvyygAG4t9fjo6IWoLSvXl6/+6FgUUWdAlhXaFNou9S3L tSmTem7V+UJJx8RgYFGIpb76wgaeP5p2Dk99smj6gAMm/uBYaBuh5QXk+b7h DcKQpqvO4Sj3aJarLSbls87h2cSiRd7pm4ZpmjZNZ7hk+tLpOmZv+hVSvUqq VZ3Ajx8Yjuu70MQKjIFjWywXp+0g5IN33VMRZTTM82iRrGRSUPpAJw89bPa7 D9Es4qkbWbyk2SMN56sIG9Ok99v0Ahf3LcNynAFNjyFnlCZFVp1LYzoq5wtZ 5Grj4allVWpNf8LGa4OuIXV5QBODzuQyy6Pi2wFdYDqK7zORzIsDzGe9vm9Y 3ZVIXmsptW241zZsPwj43soRFjui+ymdUJTQeVLIRSYKOaeJzJ6jmczpSOQY no+1KfkHdteGBd3pUtIkjcsCBlKRUoHxWIpHuoUsGqcxvJEs6DzPS1k5e8Os KwO3FIVYxJE4oM8GXUZxLBpT3jPkrtt4lxpXBuxKBOQKarzCp7NHWdCtXJQx m7cvCpO0rE+y2fCGoE+lLCVrPnnNC7mil6hY0jiL0iwqXncDtJZad92fe5Yd GoOu0TO7dFyuRH5Ap2ouwBy2Wl06K2GoXEXJAY3Vkl9tv03vZQb7TxHSmfyx GN51xzJ7SLMVH6HrdC7jmFVHUux6haML3+7zgrI0p885H75Jk/5VlEiRbclA xNNsjws4RS+jZXxAQ6M2I89T2Hdk0JeoKGSyEtkj8vdFzmXCuXAyrWp1NCHT CJt/kxE0u0AhfiXLNazAoReuyWu6+82keaeqTRqwOxkzHDM0bMBEPRF3JhtQ 0RZ1YBquafNJD1JR3ajpu67lfjDNvuV9cExa9vqW7ZjdscgEohPDWVVu2dZm JOB8x/R89t8gdJ3Kfz/3PBdRT1E7lMLHqBzt5vWMHWtXPkdKNmJyLAuZIRei vIhmbf0hpKSEht0UuaHl7osdirQKm07RKoH3QMlGpl4YiNV1iXyB2IGFJDzg JLw06FwjST5bNms/DDC1M6A3FBvH4jUtC1SiRkj4Zjj/WuaFws5K8eFcPBXR s9y1bh2tTuChlShqv2mIPZa4It+Blw1TkZ03IrsvCxTXFRudPS1ftV3aWshJ 5m/aNe1ZlsmGvYgat+f5DvSPkD20B5kUyDPYjt+0smpOn6e3w5sdm1QTCqom dAYz/lX8+yFSfeAU1cVIMzJomBQCdfixTBbQsm+F3fe7Qe2mYSLiV5WFRTl/ ZSczonN30ObKJ5EVZT2SNI1W78RstEQ5zSBApXeNr9dlXGAsFlJHcU93YCBV MMqIeZ4slhKtjtuCnC0LBSyTQr4KBZiTGmWeszRZSFivlGJc+ogek5WJ5Mkj GS+icrXR9rcifCNf0GqLZTrfW4GfShFzfZ08i7isMpF37QtpFUfdPN8MJTJy UgIrT1B5D1LMlqmquQC5+flSSQZY1sjnO74ReNYa9OmZ97HPdxzDNhVN2kK+ dY/sgbeNJDmWzzJOn7hsR2mJ5I6AVl960AIZDlOX6VOdb1t8zQ2hh+d4G3yt 5mJW3RJMEC6H1v9HQ3B8l1WpCRk+Vh3f9IyBPWinGut36Jzjh4bpmuq4a7iu ZfO96xW3FgrlkL7lwzncEGzH80DTHirQfpCS7msAZ5ajQ7PVvxp1zdAxBv5g XV099f1gteqa7C/bc+pW5auABW+3KvutVmUr0naSzPtF2scPgf7VpG69Bm6l iFVlI/uVrdFcpjStUjIT2hmAie3i1vi5Bw108kBswqpy+oCWNTjKY2ajxxLd Zb6XBQPxPop/Mrlpe9K4YVboXNNqVjzK/H+iwwBALv4MlnFV35QrWDaDM9bK vcZEVhVp8baxIqmxEyAMRRIwUXSDRM4K/SDYsrDliQr0jnVjyvP4z7fhdRRW tLBCNLSnGZNhdvhaKqguCnTeJfljoTj0d5Fsw+S/GPQPEMns/j8HIJHZi/hh 11cKnJXIKPhMKl05E/sqE+vQbmTfaZy+5Iqb78ah+zFaLNUzZE9n+dILQC27 BvrmBb88Php/Rf+oElEkC26oI26p/Dm+HR1gLXDQBVSS/bIUKXB5MnyTKXB+ XIsEHU6xnIb2FekMLIBtQ3Kw3/FqOnm3akbpalUmSEWVgsO6ZmbLqEAutd1Y N70Nv56vnmKlBF5zipgKOo4aQNNolhSRev6dj5/9pifvsny4BTUPZs+PNFCN EoSz4vxX6TeuuvrlUoG5BsJgYK9hII9+AP6CMES3CP4M+Dnvg58mmhVDXgvR Dg5uEiN97FhTuad+RQaRMVH8gYY0idjR6tm1zQiHs3e5LTJmSyEaxgsm88tV RTE0kCgY4dTfjLbTcEdOl5pyeqCc33sE7LS+i5qFXBqVZYAhukxVnEdLmSiS heAndU1sXt/y7F/KxzWAQm6A6SNQkfhhDGYSmkc5Q23j91v4NV3RicjiV/Vi ajF0D+v6tTu8PTn+tfcWVinTw8r0W4aCK6HbiV9VOu78KhQtA4kc3sv5e2W/ YcYoRp30j0SOqpoU4j6Ko2/41C0VLBqNpX4VqUqkPqg7DT9dvwMGE7zJgIiM e1pw8co0lfniqYjadpOrjqy6/C4yVJ4a5nnZlOx3CSrg8VgyGiIF/obkABZG KjEuZR7NI/XuuMUefoFoF6H+P3UsWnQOzyb4yfEdUccZGCYYjWWFEIKadBwu ThvG2obvUiY7Dz9VyFBrEipgCAl7QfWcijIudgy5646zdJGJ1YpgPJ1PRwS4 MZ3fvd8fen1vMDAG3bqIUD/GH3+fE5m+wX8dIsv+YAcEIAGgkmNr/S06g/QL 3P8V3M6jFwaoa7r7zaQ5LGErGNjUlxcC1NSHmnKqr7jjO65hB77e2w7VAd9v hmrVNdthzII9G+TedqtbPM9UA77I85oFpxm017XnmpnmsL60FaHvbeVMOoej HNaOJgjDZHSDdLDZAf/3ZquYG5WpnJNOyHln8oW+2Q7jZtVzQq1RvUHPxB3b ojAIDcdnK3ngmGoAZTxbXd0uNzPNHoefVOrCyt/NUPlQD7WB7QbtBPZXCFyo 5MNfehA3lrfL2jvtnva+ynzX3jC/GeIx5+MtB6gyBh6PXWqPYjCDJMdwbF+v mdsH1/zKm5shTlkMEfo01FtTyleb60t5qVWwPriu8ax1Txsw194KWDvjGa66 W8n3HFttaEVU49a0doe5JWAzJ1r7PFxlOn5jnue6m3fU48bIZoPWUQvYsmKm Mq0JLICtjakaWIBgsl3lo9Ct8o+P1J+zDpMXBEZPWJ4+pL5cvYsH2BngqVof 8M1GWP0JZeqL9FrQnFrTbNamf5uRXriVkf8VQgTsGjNTUz1TJHfCjYB7xAzI sgSmObgKEzMUA+BcuCvgIhAnwg2Auh5uBdx7cEfAVVigmoDmi2Q8RetoeTNa 3oyWN6PlDbXLG4AAAwDtnH+3DWVuZHN0cmVhbQ1lbmRvYmoNNTEgMCBvYmoN PDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIzNiAwIFIgDS9SZXNvdXJjZXMg NTIgMCBSIA0vQ29udGVudHMgNTMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgODQy IDExOTEgXSANL0Nyb3BCb3ggWyAzOS42ODUwNCA1NTguNDI1MTcgNjM1LjA3 MDg2IDExNTEuMzE0OTYgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTUyIDAg b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0Yx IDI2MyAwIFIgL0Y1IDI0NyAwIFIgL0Y2IDI0OCAwIFIgL0YxMSAxNDEgMCBS IC9GMTIgMTQyIDAgUiAvRjEzIDE0MyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwg L0dTMSAyNjggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDI0NCAwIFIg L0NzMTAgMjYyIDAgUiA+PiANPj4gDWVuZG9iag01MyAwIG9iag08PCAvTGVu Z3RoIDI4MDkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIms V9ty2zgSrf0A/UO/LZUVYYLg1U8r27LHmdhxJGWyW05qCqEgiWOK1JCUHc8f 71/sAS+62LKVzaYymZAQ0eg+3X1w+s8Op5g6IXEe2BTYDpmcOzblql1bdD5R 2rHwEnIK8JNZPeEDvX4y7hyde8RpPMUGC3+wLbBZwF2fXM9jbhgENF50jk4L l6Ki+sSiIuocXYw4zYqOaTHLsmwaRzhk/NAxhN0d/wGrbm2V1zvwj+cz4XgO POE+C4XNtV3stv1Ab7w1htnXVVHSMFuVKqfTLJ2pooyzVD+WeRe7PCNL6GMR p7Pul/FbHGhyxoUIaXzWOMK1I7dGP4rUspRppEimEzpTS5mXq8qGbygaylLR lZLFeqmoDB6dc167PX4DKxeMLrKlTORdHhfzVKY9GjH6VRYqlz06ZfQukxOV d0MOz3r0L0afanMynfUqgzBTo/Jx1N+BBa7bzPZ8X7tegeDXIIxWy2WWlwiR Bt8iVRQ0VDIxx/FC0bg+KZfT+phpHNFDXM6pH5XxvXoJE7vG5KyFcEkfVmql nke8A+G/u9wODda1GDfol5UOiYYAZPWfPAYQN/g5YEH7wcUKcPdIh6nNDsZ1 xZyOyGLB+u/oFP69RTn8Qdxh3Bf0oCvjim6/WDTp1BWCFStgVojSFXiwUa3t StIZ7ZTsprh8izmWXe11mOt4QheXwb1jyzK5fywsmu/gj1CF5XoarFB3xTOw 1L1KsqVOw2m2QvnFqkB2hacBzO+KebZsA228Dl2H2YJved2uHPY6dC3mBehW OL2ThN0ATO4ANt/4JStRC5xbeIaPEY1QJ2iUJqMvh3hr1NvCeptujdFSyTuV F1Rm9FV3S4pwIzWpC6ucH6qq8ziVCd20tTXL5QKViqYt4nK9FykRrvOsS8/z eCIfu4ApQPu4CGNZqsVXNL9tWeIJvoEjgNEWvM3CYXQDByUqfA3urWGFFaLW GlH9lXGTqFTmjy2Q5L0Gpaih/E07DiS7lhGDZ7J7+H15Q/3JIq6NrGnL1x8x YSQtHpvW38HyMr0HaJMmt54hk7snTbqTh5pZrq8PEEvDru9TnU06A5Gk2j1d 2tmUqijg4HYI16p80EX+PPW3xjTL2z0yj7NVQacySfZFjWrompocEhpFc7XY x7G7pM1oGKtJ0lsXd0MuJ3JVwEJe9ugtI1RNOit6dAHmNT1jIdPH3Wy9DPCo BPEnmlRf91cH+SEbbcr6Pm4gOwBJYwEYxilJgD2tDUxRJCOV39NZtpBxegCI a0YniZoCX/NKJfKvv+IeXZYyedT87xs9GAMQ+OpMxrNEVbTbo/bCMa6AkVos 4lQliWx3okbQS2h9IWj7/6DkpsE8VzDf3abddmXdYs/u9LbFPBCYzd2g7rGq u6Az0Gm6x2zhusZp1l5aStHX9tqVd22XP7kmWp94yHw03JZPzcrhtve4x+wK 08onXvW93fY92JbBqyTTamKHQFsd5AQwBN7a0UHP5Y54DVrhOZoxGs2Dh0XH s1wW2uFm6WV0HdupD8a3DnMc/vSC2BYOF4PrwbD/ji6vz98Pr/pdX4BVx5fv r+uSZaHnhWQKYMO9um4vx6cQezQanA4H4/r7/vCy3dnUaAOv6cFpOLvVWcY5 6n6iShkn4Kw4RRssZKXXlgmklaIInSWj8niHnyph9dvZwETfTVVbB1qo6f4A C+1lnVG5FmoKDY8rJ0EZcXdd82cmcA09kINM76arvNSHrvtqK19gjYox8PMe ntig2rDmzTxL1XHXDHHzh8Y/nND8bFifu15oQmJYgWnD9hE5vr/P63P5DVtt 29dctr0XjgpuujYXOyrx1hiYoIdEn2c7xv1EmdETlIp/YpVF2aLduBWg8XH4 rgEblVKhDQHi2iimyp2Hh4dawLBtG+vMoNctneFNieyttLZsPg1OaHQ5HtQH tmWCkvYs5ymwQht52JTcXBa0bKOCNG+eJqDMebbAykxtfi9UWslhfXsl4O+i fI71diNsV2JrQ++baImjjTzF9HgPlk0+NGQVsbeQHSECHhztIofSsFxxEDlM OIOLy9F4uNWcdD4YjHZbzWeBcMIX7rDGrxOFGOurRaHCHEeTWb++fKZ6enp1 Ptou8P5qpocuDkoUvqspoF7oOvqq4ZUdU6tOcKo250OKP/HJuKpF22fd1z0a fBwO3uHaGQwGn7tvmnoUDbc1hqxGv7Rd+bedKuLMcqG2rCduG25o9Uxz16LD hNgx+J22fLe1ZdoAKeDeCxLXuM5Sc1FFeCiW7zzac35eGIH1WhjgzdUE7fPm YBq+8zj7J2ZAOK+5vqlRox+h8ZYgbc0CN5hVcFH/UFV5+grcA+GzkECFPPzf I+J7krFfjPcnk1gTFEan02z5qIX4TTsqREpNtMJtReJPaZ2Na/9/4rh9MHEt 38V6ojjJZEmj+aoVgIkCVcg1Ap+7Pxjp/nR6P5DOA4Whw/Qhf7azeQuFVKnx VZnlsUwOxvC9HfYTE2WvOS6oJGVAjR61yfMrwd7qSajVKmFvuqbPkUvjppq8 ZF7GUYzWKwuSy2VSdaAed/Q1WnNiMY+XpDX9Qt8acRolYBzc4xHKusIEzkEq oUDsp02AooedON+2FNViIDDWt3XzrmZxUeb1ra7v9+Ziao27LmaC2j7nbTCI Rrghc4w+FTUR/r2gCHNkPI2jjalKjuC0r4pUOsnyAlLh6yNiKFZLrUkLXLXP I6mAdp0mlJzmSk50H0+0oCkXOIxkqhXNcp6VWdR0uY6o8WU7Vg3ePhWi0Qqr 4odzDbgTtiOon2Owe9P7TqO9blokW0ElV+Uc0faQK3PrGZNjWap1fqsoClWY G0mxif+pm7eGHqMomstY72xFFqVZSeqbWixLmrY8t6ClrAqq/Wo7w0oVbD0a VsWLacpiLj0QhiqX2QJDlRViWrRcsh1Mao4L1wTzfEG56rgY72wb46IFcYZB crHeFdr4GN7ubnJe3xRADYXgNxv62bVfP2jU+dDhNOscXYzwT4HnGD6HTEtE DrZkuv+EsNF1MGQzrzp7+qYeAnmd1bZh8SnmRKH71ILN7dS2Wc1muVwsIKsZ aXmN8dISv7u/T7umG4YYWnK6TCEJU1WyP79NiOCo/k8QcfvY9gmDV1wqEk6L N6cLWH+L8/+gGnLMold0+8WiCQLRQdgaG/3kBphfq4dqSdRPSccTGD18r/12 81pt8Lz1a/UrUrF+TbRh1/aYbzv1Ka5rVS/6IPBc+4NYv2yO+y/71Y5cIQwD T8AdcgLi4A9+NX0ajkBLl/vPRJKtXXDxqlQZOq+tz64sBNAPO3D2pAzheRln nz63H1G77XIN+/YtLbe0nvvnsu3O++OlPRmr9l2wRyAQnjjNsTqjbuA75ySP Q13rHIuqVBCDASGTF0vNY+zAJuo/qiVs9Qa0Gjp0gTTwImi9qvy0tfhSLwcn lPPYq0Mb5mvy03KTD1jErMobVZ7sV1acPugq4JBIcY5L8bMwOl7qqsaA4vWl E8K9hd6FVDHjnlSPSLA7XhkfLA8vLC3DhXEnz8lyW/wsQ0oNGKJhSqNFGALc e4L6ctLBVyAvp3TP0TFEwsA5eoBBxWGdhouVwcY7NaBfSTL1rUY1tf5Tl748 JnkL6cX4hnwddSdbJbdSsNorwx1KQLC+FDI9kZ+t8LowO9j+7Mhch47kjrEp Oc/5whMhIKTI6lUSLVK5BQAEC+w0igjQ2SMF5IEELOo9wqDieDNan3nzzJtn 3jzz5q/nza8AAwBogvhFDWVuZHN0cmVhbQ1lbmRvYmoNNTQgMCBvYmoNPDwg DS9UeXBlIC9QYWdlIA0vUGFyZW50IDIzNiAwIFIgDS9SZXNvdXJjZXMgNTUg MCBSIA0vQ29udGVudHMgNTYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgODQyIDEx OTEgXSANL0Nyb3BCb3ggWyAzOS42ODUwNCA1NTguNDI1MTcgNjM1LjA3MDg2 IDExNTEuMzE0OTYgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTU1IDAgb2Jq DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YxIDI2 MyAwIFIgL0Y1IDI0NyAwIFIgL0Y2IDI0OCAwIFIgL0YxMiAxNDIgMCBSIC9G MTMgMTQzIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDI2OCAwIFIgPj4g DS9Db2xvclNwYWNlIDw8IC9DczUgMjQ0IDAgUiAvQ3MxMCAyNjIgMCBSID4+ IA0+PiANZW5kb2JqDTU2IDAgb2JqDTw8IC9MZW5ndGggMzIyMSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZxXWXLbSBKNOYDuUNE/A/YI EPbFX0NTtK1uW1KIHE90SP1RBIokWljYBGhaF+nrzS3me15tBEBStmPCDksm q7Jyefny5Z8XDsnJRUIcJ3ZJ7PrEdBzfJVumPysv/k2qCxv/SRwS4ytT/IYD /PO384urdyFxyHyJCzb+4FrsWrETRCQIQytI4pjMy4urSROQtBFHbNKkF1fv Zw5ZNRembdm27ZJ5ikfm+wvD80fzP2A1kFYdeQM/wsjy/NCHJ05kJZ7rcLvy uiOuW7YbRdzGo/HAVruCbsmkrpZsO8KFyGBVygi+yJt2S9u8rka/z3/p3LcR meV4XkLm17DlBI4r/Lmp0mKXsYbQrMybBvdIWxNaFGRTsIpuXwitMtKydF3l KS1IwxqTRzD/mVtx4kRY4fdgoiF7hpv4CRvtmpGM5sULKXZVumY4cUlu5hNk kKR11VmxfTuUcQ2Dga20LhnRn6Vsw+MitCU/faA7vFeSX2s8WOUN7MuApcUg Uhbv6fb5JxkC3NnmX9iWLGpYaNa7pbS7LNglqSsGpzYvpF6Kkxv1aG32rKr8 GyljWV6tGmGXksm1+XD3yRrUFel2LTfkF677IHg0Zi3SXbU/WqohAuzYl3HN 8jLnCECedXokJNJjSBy+PrxGFruWZDVqXtXtaXiPRi4xgdDOpkSHb4m7g0h5 6r1YWnlXb4eg4kbaXVtvc1ogd4DShsKj7sOer6a23QctPFS2D6HkCALAaBog dRR5VmxYKpnnCvFojLMs5xfxGGLLkQMV3f1xdOQ7RXGTRPpyarKkL2SBhO2U zXRNG5YBY2aTI1zkZfFySCfrI8yzPWl0Q19KjpJ93q6Ffyd1XTJGdhukQH/Y 4jmTc4dR8aDQOmewC8sFa+HMGVgs621pkW+kzxinsLqh1QsSRO7ZtkFPS9if Zxk7dHSS+jc38qbIU98P9GZdgS/yiof7B1ijF4GTRAL7hvBV5IWS5Q50k7GC rYAji8zXMi9LDr3ei4pqeNk8T+dBOZGfJUCe8hVrzbbGv2s41iOhvlNOGEhz wiv8ne2qjCooXpLxbrVrWuI5l+eLqChOGxTNnqgWF+eSjvbw91PdNz7DF6xc wDmYX9Q8IR0z9k1ipEiTv/63R5dkyI2KmR8ERb7lFDnrU2QvZjtWKRRFQLNU iClxcM4i4+MknoSMASKnRd6coVYwkq5I9qOMOpeP70b41DEUlfxf9JrYqprz HlUJRB1QAspq8zTfKPqpxOQo60PrcbT1+tlT/cyzzE/SJVCOszEi5UlSb1iE syWsuDxPK4oSUcUpOndUNNvBtOt6rmLrdsCCg5Egm4q3Q7Nhab7M0x4DPwG0 6XPPW658pLebA9lvcBactai/cq6s5Bg9zx1PI9Rfj4wBqSm89AcAaYqc53Of o4MXvenyBR9nPAhG03WX7qq1eibtJDgm3+LQF+2+hhcauije4pDDZ0gQKvUI aSqaPmv4d7YBDGX7tf7/bqtTfXgAcDG69GzNOmY/FGSI98QKgzggpmf5thMK PlWShr+YGONR5APuv32a3s6HADf11cFcjmNPSyI5WjgqTit5qaDOeXpBq2eC 4aVhyYTieWUya1rt5ij6HEZQACS95LlBmUua8WYiUz0b615ZncANu/47O/HW UlvCEqd+TFGaZ9wezb5QnDka/ppSlQC3HD9QAoIr53xbSvBiWop3wgGkNTIb nizRt+LNAVdL5hBzJfSHk5t7umCs6iEH1JpxjuZV/3w9NY/l+yETAikztv2S I4sCFtO53DEmM7VjzCY49gt++YPYVkD2fIX4RB5/t0l24YWB5Xo+SbzA8kKH uL5t+T4A4XhWGHl8u3Ec24oxu4AT3vfYg/Sl2HUx1qIfuzQ7uyL5Ma4GXjBY kXqFMLyAx9TtPkielfDt65vLj2wgMeProqj3HF0lurPOINaGS5UV2Fju7KNR YaDQqjwD1RJYYezG8jjIT2OBSwg+YrM3ojCmE0KE2Mmwrxw3Un3118gMPd6S EzmI1uzPHRd70loG+GRbuhfMQcl7BvBV5C3vMN4O/3q4E4+oppLNFauu17vj kyHddjw1ySw3iJXfxt+GQsyKgn78KouerfXK04ingi4KxvsJaISeaDUWGwbn OKei45zgkoR2kIQqCXwJiU9HqOow10lUC7/bIrblbtuSKxWtXCWHHeq4mLpJ fMZVWFKuigbURDykughqJFCFNjSj8kSYTmK5tp+8RlOIND4ZYFyWl9hYLR2q rEW/3F4cRP1yG29fSKrThlFEUk3+6PQdsLlVk5yADjbsHOOe1l156ziByoBU 5hz5mARPhhMI8h6XmjzSHFiafj2sFE1DJgc/UOksX+X9Tc8LFQ32vK12XEpK KXVJ2NdNDi2RYfZfggHT3TZvX8htbeH5gvI5J432NZyjKt/bSbCQNpjnYh85 nyV4x1Gxrgt0yN+hY2jJxLToi2xbubvgsyPLU9qKdepbYsQis3xV0VbPGTbU JAcgCI3aZUH6wQUVAIvo6+FaeQ4TXX/+NWQhefQU2d3jE9qsNSPp9XAIcM64 wPEplSnSIMec4Fu+qzui59pr7AAeGDhtxlYS2QPZ0fMdHo9vJ9OPH8cyKfOb u9sj7RFjisdHTWN7OuAbbHa0kXjg87oolOg4ln9rjMk9MNdigGInwBzU+8KR 8ghsf9DS35+yRA9WjOdlfSzVeLSulkpK06nt7RzSQJBaJ0hBog8tIQ7hR4Fe 7MHO10im0AdVViiBxPPRKSLQ7aVpQksLzaF9QBoGxntWIz/QC5l0hassi9x3 UoxxPSfUG5lcmw93n6TXLV8DF+xcXyjSPRP4QQ2dW++OBFhseQH2lGMRa9w/ 3E2m0+ub2/ezATBNfWEAnzBUzDKGzxsKGm0Os1kwYUd88FrRbXvGP/Osdo19 zYZdMTe7RZE3675O35xNJ+UJ7ddC71BIsqTs03uv7DyKAHjWaaczO+nzCBFR sBXID0/zzhAi/fUqKPLUA7lblV4JpY8MeIckNrQ4C44M4+CVp0FIuw3P/xcM UrrIC8wNzvFtH+COC4QPkZJYQacGgQIXEjRMYuDGF/Lx0fhwN59+JA/T2fQB o9f4PPKDbg0STASFFuKjK/lLZNy9e3czuRl/JPOHMT8dG59hYfx+ejv57Zhm T6RoGAVWJCIuhdAKEhn7h7plBYdfXZZ1JsFW0heesUVdPwvy0oHuVuvhctmV 8rCfYrtFRfhVnlK6QhJfyGR+QyZ1uaGY5PMR193c2raRhR3kSrvrY3Cj2DJX r90fma6PpAbG/bqu2BsyMj3sCIHxDyilJ8N+Gnm26YLroXLDRLv9aMzSdZ4+ F+g79P9/GAnMCJaQIeMd/foG6cZyiSIMrfjEt4nraivGtenYTpSQt2wL3uNt n+go/MjlUThgPmjlJHR5FAYzuRh7g8zyC/9MZTytyEPG1NhzT+BzMAbNCjaJ QlFBmfV1227eXF3t9/uRxxFiHRv9H/tVrxs3DIOfwO+gtQHq6N9y1xuCLEUL dw8KtzkUcFL0kqGP34+0RNoegg6digMOOFH8/UiZEilYzFptGBos7kObD8NQ pGEIb2L0qFK9FAxDecCwk3FwUJIc/k5n6j53zpy727sJfy9Y/zBdGHubcJ+7 4nqqbQh4JQ/06PZ9ZkOPN+vg5WqbZezF8ARF8wgBPu9eHSv+T5ef58vXpyfj Sm/uv5wMArLhIT08vnufxhEfz8XcP6O5P39/7X/9/maMzT39gsFH+8EPBrcn 9aiQW6qcuXtjEh0JhafxklaAvHS84K2wrpaO5iaPQlVZJVkhZyGZi7wKuZDh 5FFLH1cvKVkmyFFKwghCqDvVkx1Rbk7VRPOrdqbu9vQCtKcJZZhOH7lPIAH/ PWyueb9CpTOJSRXnzpLDbJVchJtCaRFVgbazdN6ZMqDjZ0JJRLBMIJjk2bWy ZUdkAr7j1eGabyE5h41sAFWgJYHyVVKs9pGvRiyCXNktOyqj/lb40e/gC4n7 KJeCLxnfWCI6GlUFMcNSwK2XG88eFTd5JWEhoeWoRTRthLcJKrNwdUosDbAq biOeNT1asOgPBdOd1Ef2zfbxbmMBNbHSCk0l7MHA/kwovgRXmFYFXopx76PS AlIEWozNwAHFzCdNCovGpjVlwqEFo4VzjvBAZBap1OXc4famwrQNl5oSr2KT ImLg/t8UshVjdYlgqqPGG0RrE9msx19PZCqHE6k7HE1OuN83cYoJAZKxGnHm RCLmnQEhJQrZWUMUAzV6cSHwJAiRKHsLBxTzG6312m+u/ebab6795l/3mz8C DABKA55gDWVuZHN0cmVhbQ1lbmRvYmoNNTcgMCBvYmoNPDwgDS9UeXBlIC9Q YWdlIA0vUGFyZW50IDIzNiAwIFIgDS9SZXNvdXJjZXMgNTggMCBSIA0vQ29u dGVudHMgNTkgMCBSIA0vTWVkaWFCb3ggWyAwIDAgODQyIDExOTEgXSANL0Ny b3BCb3ggWyAzOS42ODUwNCA1NTguNDI1MTcgNjM1LjA3MDg2IDExNTEuMzE0 OTYgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTU4IDAgb2JqDTw8IA0vUHJv Y1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YxIDI2MyAwIFIgL0Y1 IDI0NyAwIFIgL0Y2IDI0OCAwIFIgL0YxMSAxNDEgMCBSIC9GMTIgMTQyIDAg UiAvRjEzIDE0MyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyNjggMCBS ID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDI0NCAwIFIgL0NzMTAgMjYyIDAg UiA+PiANPj4gDWVuZG9iag01OSAwIG9iag08PCAvTGVuZ3RoIDMyNjAgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInUV11u20gSxh5AdygY WICaMWl28z9vjuMkzkzswNZssLDnoUW2LMYUqWGTVrzn2vvsRfZhq5pNirLs jAfwyzowIre6q6q/+qrq6z8mDHKYJMBYzCHmPtiM+Rxq2a+tJl+hnLj4R8Ig xq9s/Qk30Prb2eTofQgMZgs84OI/PBZzJ2ZBBEEYOkESxzBbTY5OVACp0ltc UOnk6MMVg1s1sV3HdV0OsxSdzDYTywuns28T1m3E/8LI8fzQxwBY5CQeZ2Su O8X0Kcf1okAf/Vg1slBQLUAUBdSikQpEmUFewkYUd3l5C1muGlGmEpoKmqWE tCpt8ufivRzmeQnM3pFJHkVk8tpayHqKjiNL0ql7WbYSRL8Ec0lGq0X393Zv 5kx/n32azH5CW9xF1LStf04Zc53YqlpYiQeYV9UdPFRtDUsKHGSOEdVwnws4 mZ39W8FGzkHljXyjjR29Z7xDmsx2FpdNs35zdLTZbKZeiI6dtFqthVINWlVO Js1BkyHmOyyOKE94SYKQ+fqWVlXD/AEWeVHQdRAugkY0jdDY2P25HYi4x+Mu iHQpM3OF/v63CDPin1clLKp6pbOgJKWi0Z7Ed0zAGxhA0lH87Cf2jeXeTD3X RtBs3+Wc/B+9D7r44z1OuF7sBOGYE9xwgmO8OjpNiqnNeOQy61JzYo0ol/nt sun9X1vHWdbHrhTuZh5jVl6mRZsRJPP+S3G3EArv0A4p74ywAAEJqTocn0Ue QXRtkR+FxwsJU9uLfc/hei2r2jmt0UF7dLIHd8Tua+vG+kq5TaxHDL6ZTu3Q T7gTWjo4pFW1wiUvSDCu0dIuBfbqKokSrCA/IAi3xLfeyVrcggYPPsqyzmXT yJ/wp8sI84w9jtQwjHK3Rfy3blfv1HGDINzSztzN4sw9tO1dgyEGw0b2Xmoq CIwppI7jeYw/V9DnEiv4svoPEnSaMKoZYF5PBOudzVyG1Hkra6wFsoerI2Zh OnxY5SWi33UN7vCQTO+Gc17da+Q6M/A578D7+RXBY1H8auC5yZ+Bp0vdep8r LPY6LxXejRt0XoIZ8u1PQTOlCl9EfQdnZWnsEeVM+/u/gs06LuR37HuyXhei +ZeBZVxhGrZ4FzaqdxYQWNQnWzo+5dRobk0HqnANDn6z34plCfyA2is0mwqw KVC7VYgxobUDspXPc2Vq+UI1czy6rBavWsqMv1opM999USlbxyUgPHCVLrvB Na//m97JXV5y3/shL4OX8/K4ECuZiYGWr8nKOHg19NjL0Lu2PufpUkgcKoZZ 6XLcEoO/0hJfUt6uw9xECyHr61KW0NJk1ELjH+9O7V7qkC7Lqk1ZVCLTX6JI ekqgeT7rbOmZqDXGupBCoaJbyvROl8WBAZQP6oeHbjBAShhshdN9Jkk8HeVN yuLdmZk4votKeJSKgw5fzwnDOHpmco+ISuonLfI+rI5OpP4w9gNnR+LsoHeN U1hkCLrUBweBIuv7rtiNghoifaxiWWSU57EiMAfZuhWwSt7joC9QkeW1IuVn JlbW1n16ULHkVUYid5C0buD5neGz2QmLD0nWYYdZoqYqHoY4Ec4Vaj4Uh5hU bIKon3dVIl7EHhn1Am3UMpcDoUCKGg3ih3WlVI6iyYHL0f1BLBrsAJ/aIgd2 OG6xRppy1/U6rY1XbeffZNpQMOJe5IWY50XePEwjD4VSp9f7J4wfu44feMHO E2b/pRLtpG4rrXw3cWLO9ZvFd7wY28Lem6XnxseL2emv8Pbi4pez8w9wcnH+ 7mx2dnF+pRnmO37sxbuUOFmK8lbSI2ePD1pmpyQOi0Iv/JAdXpx4OoQxoodY P2Rf7dlSsGpJ+coBZo4Z62BeiUzqV1adN0QbOouM3fQ8MxzAV41R/2+AxP4o 9z0cI/2PMALnzsgdM52rh6DeCfBpSOYSA+nZ3hNl8OvxyB8xZYODhKgi0lSu Gwx6g0+yqm0IlH4Od/fDW0ipRq88NwmSvx6dBq4jMZbayFromcrN+g5wY2H0 Dxg9UKg30y7YVLTY8wSc/nYJnIbIONSRQRYEnYSj9wf+qqp0YLbEos112Yss y3VEVB3mdrr6dcUOOWCsvyUV1diVA1+6/ltW1MWXotkeV/B49ygwevtQYO2a fDPXhb/rboewyUcExNWystWy2mh67kmqa6v3q+fA1p2CTdUWGaX2CVo+VK3T N9Kn2vBe4X8RD9jYmp157D47Bljcd6NjTNi6O6sGMtA9dRhIOmyYVdYxYynu 9TCcj1nhx2xUcFk+dNoGmVGRHFqLumkHvmNihyQMV2TM9KsYWeHtSAhumhN2 HdPeS82GlBIr9PnT2eToRAVwcgVdv7s6wbt/wg/fwHUC2FAD/AzXv7uQTQIf 2yeHBJVI6GEjnuD8dRKeDCvF5GrydjZqnV7oO0ns4xmGFZ/4/rZz+tsEpDVh j6GY7ZBgx8Xd6MHDdh7Gw8K+A/w+8hL2hAPe58swUmJJ4NXrjGpk8NidH3n0 PWzTqGyedUkbggDjH7vsLiL/aPPecrdtbDgInSTwfmA4iHDGM/+JuwzcC5m5 iy6q21bUomykhA1pMKNBDvsIOnujEIZ8PQtnn684iTHYQE+60YuxItmxyXVf 6N1BWpWL/HEK4yRCAyHdO0bFlQwL+9fG7wM/3vWJJaHrpm/hA6rd5pH5AG+Z hM+bx06JKOiItub3eoCkMutcmANjF1Hg+Nz7gQ/aEOszoyuUMnN6m3oDH9tM Amy/e3E/IT+2OYlCBxOh1Yv1a94Lnhe2rTAyzYbG9km1WgulYDbFB4Z+hqJc PCuxY1FCP6zmH7HZ3IsanZBgSxu1bVuchf3QGCRop+oEtpdb7IbUzQ9pQbXp 8pDKrSBDOERL3EgDfNsDXW5Eh6yNsapW0CsQanetalHRIska+b2hudvU2EwL 7SrVweVb6dEpTpx9NM3Hcs53QtQGtofiH1Hv306mk6NOe396eXp+cgqXpx/O rmaXx52OJO22q7psY+jRPDGX6PCMrWqKiFvDULjNFWkCKllU2IBEMa+bBdHb 3HO8ue7YTw8h7f6x1uOxmZCiaQQ+kfTEaWj+r3sUb2uBel1rt94ycdzGj4lV ksTHI/hWG6mniJk5cYIVPeQWRzZcocTJU8R0y5ipa4Esv1UPOvgDLe3teT/D MjvL1UgRct83ttOqLZuDQ3INz/rpxOkwD2VO03OsqHhohJ5+K+6owuP2lg4z B9632wmtBVy/x0wCE+r4IRQYRuQlGTaqjszpcb6m6SmK4olcadlVDUqk3hfD KGeqsRodq03fNyU1e5oImVR3pAhUjiqq74nVGnu+EWaLqiiqJxT4tbWhisbX nra5yPWrDav9Tc+r8WPkqv0f+1WzIzUMg5+g75DjLIKS/7b7AOwJBJoDBw4r 1J39kcoAsyDxJDwvn93EbocB7YETGqlS48T+/BPHcfY3H8sT6vnFCx8SSvcG ATXBIXNC79qwsSiP1tybnwaQAaPfM/TD5vXnNZJDe5I2290XQ0BD6ECdBoL5 dI4GB3O/7x5XKIhT6xnFPwXl/UWizd6vUZKnE0Ag4RRIvLRrU+4RraW8yxbd DgPEp1jx6vCwcmIYbAlFOiXuVRwXx9yD4VZNrQ/0AvURb1FnfMSTNiYEHf1R F8xhh+6sb3PsTLaROkFqnopUb+Gx7Z4mtG3eNc7cNS+vtvg9YvwA/QPORoB6 ZABdRSF4PJFQBmEuTiKAbp/N11fpRnu+vXoDXuegiluku9WVNKfn28NcqVAU Wy6OaFFsuE7Xt9ipYcBOoWai9B/2u2/t1x83xtjc0hcMYnXpO4OiQaci9DVm zlz9uYdFgsILT9GhEc771PCAp8I8mpqM7s13ufIqyQI5C8mriKuQEwEnn9vO x1kLmkUmSFFKshCEUHUqJzMiXJUqRNWrOFvq5uEt2nmHVv4NVco5gf5zt3nP y1mhnAw95Z3lQ2CVnGQ1hb5aVBjqzNTgfOGR19JT9hMTwTIBY5Jn1bosM8IT Qi4K53gLyTGsZHVQGWoQKF59igUf8arEJJ7rco2O8qi+2f3oV+4LmcGGXhIV G/0n0dGoKIgRSAGdRq5r9lhwEVdiFhJSjkpElYZ5C6MyMxeltKQGFsGlxaOG Rzcs+qMN0xm02ayb8ROqFDEoxEyra8phjwDWOaH+JaiyIYt7CVfSSkehxUlh qDZWgCMvRs402VgUNt1TJhxKMEo4x6iPc/6RSBmODW4e2pg64VIV4lGsXER0 3MRWgWwFrAxhTFFU1zqRWlg2avprRuL5tM5InWFrckptWtgpEOJIxmhAzglH zCsAIcUKmZlNFIBivagQ98QI4ejXCEdejH8pred6c64353pzrjf/ut78EmAA uR9/PQ1lbmRzdHJlYW0NZW5kb2JqDTYwIDAgb2JqDTw8IA0vVHlwZSAvUGFn ZSANL1BhcmVudCAyMzcgMCBSIA0vUmVzb3VyY2VzIDYxIDAgUiANL0NvbnRl bnRzIDYyIDAgUiANL01lZGlhQm94IFsgMCAwIDg0MiAxMTkxIF0gDS9Dcm9w Qm94IFsgMzkuNjg1MDQgNTU4LjQyNTE3IDYzNS4wNzA4NiAxMTUxLjMxNDk2 IF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag02MSAwIG9iag08PCANL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAyNjMgMCBSIC9GNSAy NDcgMCBSIC9GNiAyNDggMCBSIC9GNyAxNDQgMCBSIC9GMTIgMTQyIDAgUiA+ PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDI2OCAwIFIgPj4gDS9Db2xvclNwYWNl IDw8IC9DczUgMjQ0IDAgUiAvQ3MxMCAyNjIgMCBSID4+IA0+PiANZW5kb2Jq DTYyIDAgb2JqDTw8IC9MZW5ndGggMzI0OCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiaxXzXLjuBGuPIDfAaUTlYgcgn8ifVqNR55xMran LHn3MM4BoiARa/5oCFKy81z7bDnlkG6ApEhZnq1UpXa3VpLRjUb3119//eOC EkEuIkJp6JDQ8YhJqeeQkre/ZRe/kfzChi8RJSH8yVSf4AD+/nF58eE6IJQs N2Bgwz9gFjpWSP0p8YPA8qMwJMvs4sOV9Eks1RGbyPjiw+cFJVt5YdqWbdsO WcZwyfJwYbjhePn7BdUH4X/B1HK9wIMA6NSKXIeiO21F0Up9DKZo+924KrJd yiu+JuUYjk8NvhWyKlklipxsijKTJGOvZMWJ5HlFVq9kw14mRNalOf7n8u8Q gkkt6roRWX5Snh28BD1vWMzBVqSkKAk38ZNFZuBmx8A9P3efkCTnMZeSaefL v170Yy1fMSLCqorna5aDe1aRKuGkqquiFCyVhMl33oHnej6daah9xkW+4a0J ulwXHKIoKiLyOK3XcEeMEZGqGF5lHb05jhNob9dw0Y+aS7wVglkVtQ7wzS2Q cybV7xWLq15gCBXlCs1ullcADnJ1ar3gcfu1YhBNhYn49dP8zcnOsQLKgpd7 AY+xEC8frn2NwsBypoAW07U8mwZYRpWfJuf3d19v7ubkYf75ZrF8mI2nrhUa y5v7O+W6g7LZenEsgF2kvdAg8tTFD/1iQCKbdzXA2vESgQYQLPJU5JzsBdMR Ukd7VyBzWoT1wf/dOBwOYzewAsMSVUxDqyi31jA2eH8P/VAuD5pS2f6W8HyA F16KfNsWJ2F7Tl6LuoQy6SYhXdrXolc0J5g29Y9Zc2AN8MFH6SezfK0d7Vkq 1k0zELZet+4AX3B6gM/pEZ+i9VNstJszEGd7cMlWKe/h0g4DT3uZkbN+mnyf cXcQado2fesQk+hGTerYBpJFduw1Q1oAh4hXlhU1fFvXmDwJ9r30xlzsocSr 13OvPNsj8hTlbV39k7o6TV19quF2k+2KsmIQCfQxAP5So6mBQ2hFU2TeDk0K Ft+NR4m1h0ikurpu74ZHboESJNtwzUqm9tBCEnBO23ds6w4AUqcYwC2LnKUD PACLwgvL112FV65ZxXpJ8YM2xZKICjkRipJLyE0HPrJpPhaZvuXAV2TV/naQ UBnoMvwDfOxTKXUbdtlDpiMKpy1yk5MY4a4cse7VIgcqrFdNbSGKXes/5ute clSvDMJvCYw9AyLWe6gDJBDdwOTQb8mElA0OsfJv8deHXFffI2ljJrF9IBMN LevgAqPYlizL+AlSfPDiB32K61XeaFn2/u56/jC/u5qTX+d3j/MBaMzWhYPd PkUXxhdWA8dn5B8FT9NcyBjZ5Bsrn9FyMBehAc8cI4E5nZCxSSMPXv/JpDYF WH3kJTRlPwE0bNC1HFNqA/3y1LoEMxALkfE3LzKfDPtp7Nqm45LQDsjUtyeE XLOXnx0KXe9cI2pqulRo/WUVx+Y2WyXWmmOcDqgJ4/Hh6yVpstvSM/WsKPRD 3VNDWgaA9byczIzWrpdUiCXwFYCMJZR19G6OR9gYaREzlC45Z3rAnyYe8eg2 oCmBf0qyaGHMFcR1tv+QZI3YE3FFRrcC9MVoguT4ShgKqkzktdmviOO0vAXE cGDpM2EHmGW9rtwgFUoyS/kLkD8vdymr/jVRUFWzrs/1U6/xNmeyaiIiMdBq G6nV/qhCU9S67Zo9b1sg54e+JGmJ+kpUr+Sq5w27LisgJkAHVrRNAnB+lcCD DwJED3Sp6tmjR+qFzZBTjiIYWhWr4VwlJ8DdaXFkp1xskyoVG+BReAZgB+df xra52Ii4N1Awk01xZFLsdkiGIJlSvu+xKNr+AFqFcSMtskTWCiAEeCLMIH0K vJLf6zzWquvYPDiv/Ca3TVl7BFdjXcYOfumyCb+pC2NImglcJHK4sofDXjqi SKH0DDBjlhMgRZEqdaPlo5p82i2CtO3sZjyrmy7Jwp2QhQ//TXXKFtEErd4J 9JI8OurYYzjpZ7TV3/gnsF7V8pI4tjchTgC+D4mIEyKrYgdKGeuEXdABtxvl R4duGKm6G0lR8ZSMZmX1B34agZhPq6SotwiaNQCxQjDueV7zSduMOlVh6DZF +Ek7F20xoc7gcMdhfdjUKb5QBdMuS15oW57v+oNl6e1OFA13IjdArgHd995S pNRSE+aPWnCU1Fkhd0knSbDPkiIFJHOOc1tD81S19PcCGvgNceOEQsYf9R5e nnv4plOEkFVRYnFwLvfr63SbS2fIu+HP2TMxVWAmFh95AZnJRLZMioy3I7dK Oho8NwYaRvgIvCrJaCnSAghxdMtexEhDc7SIk7yGhjqZtBGoMFtNWkpD2s0D 43a+WMw+zxfDodqe7vM/hRfqIG5xEUTphevbmqd8y5Bv++toQ31DAXFmMT2K B0MJsBh1KkcBbEpRAcG2YNU3f0uKHFQjTLwQxu1wesLwNAOXtlmDnU8PWt+x IYQzZ73gXIbhSagCm3G7X3PzDZJ+2WYvx6HZbWuh7aqURbhvDVci4/76+ubq ZvaVfJ3dfX6EhA/zfTRu8z3sgMBuUj8D9S+5Emka5t3a220GCU9xySHzfJsK meh5qddD62cF+G7cFUSKrE5BoXMckkoSpsO9oxObe5hG6xOQgf4Ohjlo6gYL 6t3i2/2Dtl02VtPm9UezDm0qaX/RSWqcU8ujU7e/H7yRnx9fsTcvh2pm8NxB Wqnn+oO2mokSFxRJnhpJh9Dl6YR037IdTxNoVTUF4uTfOd9Aup/GvQEftjsn S9PiAPqlW7SqZub09Qgcgsb5HVCXq0SzI7FqYEZeE6PAxmilQXe2idjqQgQq 6PtX21/7LN2VfengBcdtdrDjfVFD5cQRjH+BwHjXIYz1qHGI6gY3DTgN0qEi rpZrSBRgRYH06m7TueMvVev07Baq2eTtIgoUgQR6Wh6LnCCswc4pwjQF/o8w Q5RpXTDo4fdgBjx0TOI1dNTzpoZXAlU5lmv4Y9tQqZA93jqev61zUAVQdNd3 oH+D4dFeeK1VgFZfWLaqlTAJjO3Y9Ck1nDEcpsY5+7dRLoBUqi3DKKce9PLp vcZXzvY9lQ4TGYSL5onRdSn4GgR7gowP+mqks/R/qQTtKqGAYcx0OwFfX7Hy J+UA3gSaXLEkh87+AuIKRu/TmMxAdPh9jHflMY/V+HD7nxzV0IcvLM8L2FQ0 aCeEvwhYSmYfyacWkoLHz+S6zp+rusxGnfYzNoViArjOthH8yjIvLAJiZ3S/ ghxCy/fTpS5+N2TaD/lYaxCh5Bj2k+Hqoj2N/yRUiJT0I+zC/rNILQz1XEFh twubeXUNxJZ1GwiCHRfYMtNggX+xr2W9Qi0kX2XFMxRCGlbvDKuGEyTnyhgW OOWo01kl0MK60VPADa0AK+KkPsaBvQChNTRBHQ2ao9A4HA5jN0ByWqlY/st+ ta1IEQPRL8g/1LNgNt25TMZHB1lWUJDeN5Fl6Z1dlB7FWUE/31PppKqn8bIP PsnAwOQkdU91pUqf+yTPPXdITl+rEo5X1+Zi9xhpN9Dc4g47HL/G4hM5G+k7 97xv6P0HR3cmbdAnQ57rk00Y4vqADhrlHp+7TZtAx70JMAIzbcwRQ8mWDo0n d9HmEFYs/pcsPkXb+wA9ySOAT9PTmLb4926t6C88DqNgjE8ybjDvTEcP5uJy wN8j1h/J+C1SyBN3qpZnA49a2cHw511vU9F9/8y8vOabq41HiXWmMkdAE0YI B6HLqlEbyOOXh+Pt4UBdtnR1vSMHQ/xNvLlHndxuUeuOdMUP7ef9N/v1xx2R S5Z/nqjrX8B0Gvb86oT5O8F9d3T5+ytG3sKLnoPDq5hpMmVRtvy8mkzyAWFJ jVZhYUhJYDlFWAVOLDgigTZ9mLXE6ApgRTHKgReg6pRPdoS5KVURTa/KGTjZ 4S2yvUOmv+X2hwPw37td7tzOrnJO+sx558o34BROchp9bhZVgrYzGdTWjHnG J/aSgXcFwBi8+qxaj2VHaDy+qFnhHG+BJYYNNgeVoAWB45VjqPIRrwYm8VyP W3SURvXN7of+xH2BiUtcxpeMbywyDqSsACMkeev71M7cmnERVyYWCK6OS0Tj hnkLo1Ihrkr5SA2sjEuLRw2PXljoVxemOxGPX9+ciqhSTKAiZqyuKYVbCTjN CfUvQhVPhiIhhFMdFYuTQtBsbAJWXowl0+RiUdj0TgvoUIJRwUuMcpjzj1nq cjTcbeJi2gY6qcpUVqFRMdiUJ6MxJCfC6hLGVEXtbCNcC8tGTX/NyJhXGak7 xRo8RDYu7BQR4kgKPIAGpQjpRIBAsUJ2ZhNFQLVeVIh7YoRQ5FMJKy/GP5TW c70515tzvTnXm39db34KMADev13ADWVuZHN0cmVhbQ1lbmRvYmoNNjMgMCBv YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIzNyAwIFIgDS9SZXNvdXJj ZXMgNjQgMCBSIA0vQ29udGVudHMgNjUgMCBSIA0vTWVkaWFCb3ggWyAwIDAg ODQyIDExOTEgXSANL0Nyb3BCb3ggWyAzOS42ODUwNCA1NTguNDI1MTcgNjM1 LjA3MDg2IDExNTEuMzE0OTYgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTY0 IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwg L0YxIDI2MyAwIFIgL0Y1IDI0NyAwIFIgL0Y2IDI0OCAwIFIgL0Y3IDE0NCAw IFIgL0YxMiAxNDIgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjY4IDAg UiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAyNDQgMCBSIC9DczEwIDI2MiAw IFIgPj4gDT4+IA1lbmRvYmoNNjUgMCBvYmoNPDwgL0xlbmd0aCAzMjY0IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtFdbctvKEa0sQHuY uj8hUyKMBwEC/pP1sJlrSyqKN/6w8zEChiSuQAwvHqJ115VNZCnZQL5zeh54 SKxUkqqUS2WRmunpx+nTp38781jOzhLmebHPYn/OZp4391kl7Hf7s6+sPHPx IfFYjD/N1G84QN9/WJ+9u4mYx9YbXHDxD9di34m9cMHCKHLCJI7Zen/27rIO WVqrIy6r07N3Hx88tq3PZq7juq7P1ikeWR/PJnN3uv4VVkNt1dM38J/ne07o ujFc8eZOEMcJGdb3PXXfcf3FQhm5uLparpd3txef2f3q7uPq4suXa0Z2A2cR JwmbBQ6iw60r8+r6l/Xdannx+UE/bkKaJY7vhgGb+Y4fkekr/Z565Ntkub5E tExupt7CWUw2oqoZZ7Vo8BWr8x+saRtZ5byo2TZ/zsst/prK/aHS58VOlLPp X9d/hg8zz/GCIFEOOXM8pl+o82fB8rIxN2TWpk0uS7L/VMpjIbKtmLWHjDd0 jNUHkeabPFVG13/SGYlVgI1Id6Us5DZPecFkxeRBVJyM4WMpmqOsnhgnA03t UBLcYdSuEy7cufZpvRP0EH9S4dpY2FEUxYycKlkjCoE4922Jx+iJUZCxNuhG sTEofsCVpmYbG+UesWRt3VQvrBA8o8RR2niZi5pcV7FQHF2cKkQ89wyf8gbH 3oYwBFqXFhWNejaiEPKiYI/ivTL77mahQaDtW3j+YQQQz5l7iwD47B54hcRv k4AdeMWLQhQDOKBWDdK4l9V05sWTEiG+Z98na++crQP8hN+nb4ExSd4HLtrv veueownUhwAfcNFnPxi6Y4dryj3j+sz4Z//XcP+/hMI3jTDBSAAUsfiIY46f 6GQs3hyez7wQUSCYSH1Y4MObYE7F4LhxEGifvsgOgZloeI6WgEsbWe0V8tie v6CkrAFcyyHCDnwrWHSq+3psNJJ5c+q1ZpfXzLat3FZ8vxeOQYnlKScI3GBI LJOvd6ufHz7d3bObuxW7uv7L9ee7++XtR3Z598vterW8fsU11sKw67zI14Rm qEYhdCfrRuWcerbeyQNDuIj+WRTyoJulBbHoBhhG5gddZBX1CLuRbfW6crWo aySutt2Ahpv6FPcW/Vcju6adFb34xPO6j6aJh0OtqDP+Ml0ETjw5Zz57EIdG 7B8Fnikztt611fDv8/7v+rrTmw7niXH2pq0QbWXqWytLr4ox4CH+jEP8scBv jSmR5w87mUwej8dpENGDIBYna1one3pHtNVUfGMJtKtt7JghkCyieQcSU5jb 9fXq9nrNLi9u/s7GFe3u9QV1Q4xQ5cJFyZZll3nMjEu++UeX9EKCOZHsUvxA raUqdyrLjbBxvpochlSD0A+1+XSQE+6wZTMeU2TvIFHpx7zImxcCeZbb82nT ubZwEnJuNFBMxXmaAioKe/biNq+bzsOMGdCCNJo8zcHfNFpGmY0cANwfpnby cHe5HI7tMaH1F7qc/veEtoAC0DVgHwWldysUwGzyd6LIVFyUJQXsaGL4zgZz Ym7TG35sMKuCVUgVvCpeZo82uVmtCUWwy1E5qV6NLfOsz3cAFaVNjg8/i7IV 7KdPvMUze/bzP4sC7ZlCUrB7Xj39NGrTntIe2nLQfxftFmOWBR69rel354yn 34B+FyS+/oeM069BmPTq4U3kX6chNaOYupMCDSnYSqQgBuLvUyx0UjT5npET vyuOYl/kMNKehzBiTaJt8t6Ce/ImnY5qbStx5zFEWhiEI4n7Vsl6I+z2SjaI 5k5CWhpKduEEkavuq7T+pxj2ornXJ9Q02or0D/sgEd/DrrXtXhhhQyOQHQqO fL9SZHbwxQvDTagHNXA5IvM+hYHDHhrqA8yawUj9qimVl2UtRJ9Ub+6ZWa1I hysP0qrFMBk49iJbqhpHN7bUeNZsu91ZU5QAzzcuYiKjI18YLyS8+CCqIi// hiGdp01roVX/hhYp0IR1yg/CYV93kAeD4eUmCjITKEwKhVxQDonyV/miIII5 eSC3KpXZTxwjlpqaavSqsZSIzRWa76sWxMrLP9bMeKlT6Nikj8gL73/Kt7sC P039/sTUjsJ4YcsS2PTOPgie7s7Z/Ya3At7XcOz75B5fyvSJLWuK2uguWwST uNv8SRb1k6TkNzuW7my60h27F42Z1Pe8LVBynto6HNGw4RxRDLjJnYfG6CeR qzw/5Z0xAX8e+HNO5bwcPPJ9es4+FshUnqLs9woO5ycWlkusMnRsB7rUp5yR HBxNVU+PvclF0wi0PVVBD01gDLqIuDgnqZoWbaYEoqrupkWxFd2+zXqQhKdo dyOAo4ssy83m1FAUTd1Ni74Fh6j1fcNNJ9oS3Hbos8NJYVEBjG616jYbjFVV Nzw2qG7gmiGBU7Gew3q5I8f26oaJGYsoOC3DWoWGQSwrc3h2amckAyqPSJ5K o3Wrbh9/JZmAPxq9pWTEyaXL8wdM1UkMrIeoFKLJum7VWcR+YfmslimN3K6A /06tTx7bGgHBSMrrlheO5tFeZ9DGMJs7YG2lM75Nrq4f1svbC92b6+XdLftw vfq8vDXzL+oVh7o6kuWmoBPNO+cqsx8Fdo4Szx/yhqN5NDOpYn3GLJI4hlGC KN6CzV1YNqfSrzABzwmvshRWLOxJ8z/nWG6Rsj1kqmnLgyzAowTtId6GY+jb 5Lo1G64kEnxLQq+2vWjRlws3FDUaLyzD05wuiBcTdiufzVxN4gTwqJ5EdrJO QeJpUMFOxo8l2eTQt0cmKq4qr5PJZsC/+g6/H3d5qrHeMW5k+lJlpM63ZQ69 DrXFoN73Cig70DRAKjTgLbxafZAwPYD6wpqDN7qAL/SulySurmoGGqJ9qNe4 VlZnlBg6Qlp92D4mf6p7TOLG2DAveKrRhz4q1T920A06/7ZItVkXKFC9B0Fd 5lx9NFsCerljpxTfW9sDm0aMTYxzpWaKmaXFHSQrrQumIA7WNoARdst6QyqZ 18P5Z6JFQx+wPmlyRXCJQZpJSWIIsKuxeQsRvfQPXrcdrgXOgA1VHc9RZ5Dv gO/CMLJJhlrMwSV7Jc/RdYBSSjpd5siJouWKxnZBW89ArIBmhoNsrnUfZVj5 dZRVkWFt0l56SeDWaF/ZQBDtceS+4M3vKGeFkd+rAW+xsG3Mtt3yRSP1WRbt XjczFkwzAfIUxoEKwpxUCwgES7/I5gMY+J5dLIYpUmsdyoEEdrdgUavbTV6h QcbPaZHBjuIEKJLE+A4xAYwWIjsfYfNQoHsoAt2TaDkaBDzb5/1kUk8bnjaF stqvRt5YfZANxueGUlKqxahXekL1Gs+EWpDwnyxGvaC2iMhkIYVyx3uPLyNa Koq3NSIM5QRN6hFDTTrgODStTxw0zpMot5gl0HPocNWjEnwF6VwqMnxWhKCm 1Yh0573KNTA3DYacWM5ge8x8ATvt3vRVV3COv1W2uACrnfD/Yr/aVqSIgegX 5B/yqILZ3Dvto4MuCIoyvi2ySO/uoMwqzgr6+Z6qdCrTDQ4s+CQDA5OT1D1V 1alXH9XF5iHpzVbXCWK7QXN9g8VXbU3Sv2ikeKuvPll9o0JOxoeo4Rw+ddpH DCoxoRUHk4eoD7cq22RGX3QqEUdF36s8YIbB5855vO/wsV4yhdNMdgRRfBRP wfhjw9q40zwDBi0fyqN48oi3ol3b9pcgbNUH5fROXVxu8feA9Retwmgsouhc cYbmtRAcBjcPSZ6chqC7Z+ol7ue1q6+FwhdUNM92MI/Hut3iC1uT5P3h++7w +f4ezxzDzx0YZMN1ur57+jyheY5PDmg+qJNvtz/Nj983Wtts6Be0dv6FHzTm MTwGoKklidOXJ/JiJC88HOVVKnqveMFboa72Kodo/JAbbYfMkLNAPkVcBe5J cPKoQzyNWEtKlgEpQr9uB0FAV9f5ZEeYm9IuountcrZUIfAWJeJQHu+oY1IA /nu3+c5NdZVyEhWCvLOkMNsO93KaQmkWzQRtZ69Q+mUoJmTykkCwDGBM8qy6 H8uO0AT04Kqwxlsgx7DB5mAnaEGgeBVMmFU+4tXAXjzvxy06nabrq+5Hv3Bf YKb3fEElo8YS4ag7K8AEScEEn9uZXTMexZWIBYLLUYto3DDvyKjMxLNSOuoG zozHFk89PP3Col9dWN9JJrJulp+CZ4IuouLuWqewKwHLnOj+JajC51fcSzEu dcxYnBSCZmMTsPJi4kyTi0Vj63fKwKEFo4VzjEqs+Ucs83JSNNrgYtqGS42J V7FRERi4/zeGbEXYvIQxs6J2NgjXkWVTT/+ekamsMrLvsDWZvshHdooIcSRj NSLnhCLmhQCBYoXsVBNFwGy9qBD3xAihKEsJKy+mE6313G/O/ebcb8795l/3 mz8CDAD6ejiGDWVuZHN0cmVhbQ1lbmRvYmoNNjYgMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDIzNyAwIFIgDS9SZXNvdXJjZXMgNjcgMCBSIA0v Q29udGVudHMgNjggMCBSIA0vTWVkaWFCb3ggWyAwIDAgODQyIDExOTEgXSAN L0Nyb3BCb3ggWyAzOS42ODUwNCA1NTguNDI1MTcgNjM1LjA3MDg2IDExNTEu MzE0OTYgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTY3IDAgb2JqDTw8IA0v UHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YxIDI2MyAwIFIg L0Y1IDI0NyAwIFIgL0Y2IDI0OCAwIFIgL0YxMiAxNDIgMCBSID4+IA0vRXh0 R1N0YXRlIDw8IC9HUzEgMjY4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0Nz NSAyNDQgMCBSIC9DczEwIDI2MiAwIFIgPj4gDT4+IA1lbmRvYmoNNjggMCBv YmoNPDwgL0xlbmd0aCAzNDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJfFfbcts4Ev0C/wPKL0ttWQwvulDz5jhxNpNrxZpKzcb7AFOQ iDFFMARoRfnZfd5/2Ic9DRAkZTtbqdimRDT6cvr06e9nMZPsbMXiOEtYlszY NI5nCWuE/2x/9pVVZxEeVjHL8NXU/oUX6POX67MX1wsWs/UWByL8w7EsCbN4 vmTzxSKcr7KMrfdnL670nOXavhIxnZ+9eHMTs50+m0ZhFEUJW+e4ZH04C2bJ ZP3XWexexK/FMkxnixkciJfhKk1iMudOxfZUGC3nGR39FjQTeicQU7EXzSRZ hstgJ6pcMLVlvNowfRCiltWO5QWvdkIzo5gpBBOVkfbsMhCTf61/hyvTOIzT dMXWr9wNibshl+Y4WaZhFoTscmtEw/y5tpJbmXMjVcVeiqaUFZP6gu2E2jW8 LvBVWR6ZrgWf2ivWf4fhNFvNneF7uHXBuLH+yAqWtxyO3wkDnyv2mmtjQ/g6 mS9wu8CjrLyhx0n8FrxurV+LQNUiZKfv+bTFK/fuW8MOXLNKGXZ3tKnBxabg dAOLUcALHxC9prYuYAQrKaQhmHiWdXXYCC13FTdiwzpHluTI3zQ7v0ICqRxX bWn8V+I8ZH9UTwzbNF8waYYrkiyO3RXayLJkhSo3qGIh8UOaEqE6u7xk4gFV JXddNidTC43KFoiXI6/naW8SCSZ0cO8X46wWzZ5XMMW2gg8ek13c0Bw3/MhK uRX/pxqByx7KAGA/rkKSrRajl4AZKgQSt1UNQtcMuPreCvbAGylc6vatFu1e X4zMJcuZi0FWednaIOA1iqnKUuQUsu6BWiIF+B7Q93Gi5EKVanckhJ1EMesK SqBEko1qrAe8MSFb47OqpUZz9W2198wC1V09wnoUz6yTgXOHl1ox565gWu0F y9tGKi2NRGOW8l5cuBxUVJccT3wUcDrvAi55W23glbsaL7FC7Ov+kRzX7Y43 3Scjd5Ll0pnAJZYEfCBG5t3bp50Tp85/CjxHCKZpbWrZQTX3DL/JyhuLF5bz WhqgsEDHbNvGTDvfyfU0dfcWxB5cahTbuunhhwTTc247pRoIARDOngNwlMx7 AO+ETT43puE5wUhWD4LqBjd8fHvkvmQK6LW24X25GbVYz6a3Qb4N2Wdl9Iaj zOwzkPPzgl0DiJtG5gWu25gBRBxdz1wuR86lK5e0S1gAB4IbWy0roTW7EhSU pzyUmu64KkR+XyvE2ycsjmauQ64KjhYRt5OQfS3AidKgDHvH4luuCyqFYx7P V8j+YCbzfX4n6BiQksODvqHxeg1cy7wtgRZC3lG1RAaUzgdemekYC7OoK+LO xw8Ud06EA/+jfuBSvuN46kp5AGHA4Q1i3D2HRup571TdGjdQ/mrBd2RJk9sd hfrrRlbmWfqITGybceCslhvMnw1Iq1RuBpKZwziRfa6ypIM6HNWFqul9JF2a gr1rAYY9uw3etc32v402oqIPbicXQ6ZXSTctR1Bp+L8dNB/hiS6/U5huROM+ bjGGY9QZ20g/IHynEit7906KqR07nbpIBDJkarbsUL7nOzu5ydidakvx0FcU 2YHvTPwgC9piIg3n7H4/6qWRyaWf5VTmD2KvGswxILrtaZYK/w9eikoL8Blx AxEfxhf8h/XBVpZ2aLAzRlXit3H72n7he2LcjSDQ7m0m0OVjDdM1j+/m83e8 3RbcntFORlCmEJo+p3LyV8J/eDsZ2GE0v8fCJYk6/u26uBNSdug8N2/7BkWK DQ00jK+n1DooOHALpjgNcDtL+PY/qOkrDAiaXHSRLCHn2j3hqJK7wgz2qLhu bgVWGFCCqF26nrgNaLYg8c5ZBWuNRsS48Yh+rdEPyWxg68izRqHaBj5clRhR 5IQk5hmUQk1824m8trqv1KGyrj9ILcd5WywXHUiIk7u0nV/iZ6U9RdzUfSOc M+JMzR9w+ymzgjFckBtR2gRYqYNfudJ7VasS86ciNWcHQV+hbVuWJ0qklw6o PkEnCujKC7KWU8gAqndHPUiwnKoQImf92N8VDDVFaiERxEgfjVzNor4zUBBL PJQb8tYWgaSuQXI9AO3c9qa2PawvulYcGtlRcWc89y9uqO8w+GTHnggdXE6/ HPF3ZTEeElpZuTs2miadOKaDVALxoy7VMCxMp3FgDmYhQQAiY0cF/a/7Ak6f o3joW0M2hoAp6wepC+snZ9T0rC4F19w2Nvc7h19OEgLSkpYTkCxoaT+0Pixt hOGy1DTS+ObBynkQjtMyL67jxO1r8SxcLBZYsmjFcY4dDodJSg6Fd06ybkR3 qNvxsHrMo+FMfgaXACW/+s2yKJzN0/nJ6jeSw8EspddfXM87F/otL83m4WoJ UYw1b4a1KFs9XfP6/L18/eX924/s+tMXdnl19enDZ5edy49/vv34hn1+/eXm 08ebU8eRsWiVLcaZo4Vl1k3xSySoE8pWfhHwbfqomj3S8dALiwfazUT17LYY OfYG0Wiv5E2htOgEhqwtseFTngNBeDoSo2DT0FCVA/VkTuMGh0JZTsX1wBqA CCVlt1qnNY9Yq646uekIBLtsP4uXiTMCPgrZ26rTWmWpDnTnQVilTXZ3EiE5 +BmMY9vBI73tmswLC8oLZPWO1lCXrG5fRM8J32wbqXM/R7xD1ggRwG/sBAnR aWWGWr9X4FR26fSsXRwGKj//II0BRT4tAolXq6FHooA6oz97OznFx8n9I8QC bBhDG1HdYQ4my3AR7BDQehLHEf5WE2Q4aJ7ePwLut+APOyFhg72XZKqnBJuM RxqpS1RwYzg3GuPI1zL4pwDVYn53z9+Cdx6YVY25+LPmJZaJ55bQYVa44OHN KyiXp9uofeeDW+Kwd4lyAGNfkM+4BlUH4bEvEKh3wM9pQJel+EEpa2rSd89Y SBdzBtXTizVslpgh137B0aIwbdMLq2BYCZjdAI4+IR/Fgd0cK75Tu1acRNOV 7g2hzxm1Cul7i/4Tzam7b0gdYveo9ry5N88kZcjeI+nah5ak7vswDO24gIqk 2VAZWbXC7ZZVi2Pc88tWYlpMcyRSP5Mf7ca59GsM+luVbrJUCPlka4HzJZap 8tcDgjYfv6y8tkOMGp+zYazSwmRn8nQ8dml5qBRIzhB6aWvxCvUx3S3m3ay0 Ow2zMx50AK1HZxTG3J+2X4hCMeWwe1bKOBmxE8QfjOTSWC4slp18w+ByyaDg 6fE2KOT0dkJa98juWuP2G/qmlFuw0bG0873ParpaxYMo52avdD2KEQr8IOCQ E/q9WJI/Oyn7dHoHuhY56QugO8ei8WsWO2URy4oNI1m4a+Xjufor8nDUu3JE gYHREZ9VL9CPF452vQzpvnXzRjiUWaE67GYQNumQj3VflwajCuMBR/c9SvtZ p/3aiGFmw39W1SAnG9ptG1nrLqF7PN8J7LqHqlR8Q7PwdHEa1MgKi5XXAotZ uMpmCVvM8Gm0TP7HfrW0qBEE4V8w/6GPScB2evphzx4jYSGQQHBvIYi4s7pB XaOzmJ+fr/pRPQ5hTzkFQbCrp7reTxoFaEkg0dd5Vtn2/fFuOh2MLP0e88q0 O2zQd7fTV6q6l25znnbL18uyX6FZTa6rYzDxu+PpZXPCfthNMGidernt97vo VTeeUoyzcmZaL5z2Ujlv85CiTDJCXDwHm2yekzs4CUWGbBAaZpBkomhtxBAW ve9TQs2iw1fUpceNlL2CvMhzP7x1oJn58oKhYljBDI/dRR746Byl5Lmmv9pk kKCv1ItodAHpHO/71XG4YzWmTlmfUnNYN54HgbSijS9IHprFGgGyOpyPL6f+ L8l1ee63SOtzlzL+tEIbCjn26aGazs9WzBciumMxRyR8xuGnqBE7F/LPF/H9 Ry0eK3QYFGWDYbIx0jcKGx0GU1hjorR0My1OXWWcluBq20Z6ZcS+WlTfKiU2 1fR+gb8zzs+i0q2srQYhrySFpNYYJDXoNNIZIvP0ofr4QHEcY8UH2bwAqlJg RJELmuMmizaaok4oj7nsYS5qC8JLu3x6P7FtK9t3J+QjQvjQ9fLX70chaifp p4VQzV0zE2LR0bBlTLAj7KPE/RsmaUmJBnqGk/ViV4VDuNLxtKucNrLBippw CxgeOMdg+AqrMrgjwrZBKjYmcrG2DgAxspY/aAYKu/KOb/hxZlpIZL6FzoKC A9oiOhQi4ysFKBngv1c7+FxGVSkmUUMQdzUxdHUBd/zVonIliRJCvtlVSBQ/ 81I70pIAXQcAwtgmsC6f+YZxNMpwZBjtzWCwYQazggUhG4HshZUn0Ye9MrBj zcvnbJ2CU/hF9U1zpT6D2EwdFlP0Wtlago0oTwGsQUlL3bj8rR4/HNiVkBnE K0UVIr+GeAOhXEBOTOlTETA9HEq8LuYpDjPNyGHlxkoTeAf6FkWKEAqJCBfV CkY9InAdE0U/a6jwOVbPGnPNI8GsJCNkGTOBkRbrEGnsWBS24tMAKFRgFPBg I29i/NGTdFxX6DvkmHyhbH4UTiZjEQDMGdpCeuBqJpaOECYxyt9m/Gog2bqE f4lI60cRWW6CNM5aaQdyMglWxOHUIuYYw7grAgyyFHwTRWQCSXpmweqxEIzh rymMtFi/UVpv9eZWb2715lZv/nW9+SPAAC3SrLoNZW5kc3RyZWFtDWVuZG9i ag02OSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjM3IDAgUiAN L1Jlc291cmNlcyA3MCAwIFIgDS9Db250ZW50cyA3MSAwIFIgDS9NZWRpYUJv eCBbIDAgMCA4NDIgMTE5MSBdIA0vQ3JvcEJveCBbIDM5LjY4NTA0IDU1OC40 MjUxNyA2MzUuMDcwODYgMTE1MS4zMTQ5NiBdIA0vUm90YXRlIDAgDT4+IA1l bmRvYmoNNzAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0v Rm9udCA8PCAvRjEgMjYzIDAgUiAvRjUgMjQ3IDAgUiAvRjYgMjQ4IDAgUiAv RjEyIDE0MiAwIFIgL0YxMyAxNDMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9H UzEgMjY4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAyNDQgMCBSIC9D czEwIDI2MiAwIFIgPj4gDT4+IA1lbmRvYmoNNzEgMCBvYmoNPDwgL0xlbmd0 aCAzNTg0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ5Ffb dtvGFV39AP3DWC8hWxLGlSTkl1qyaTetY1dS7NVaeRiCIwIlgIExgGjms/qF 3WdmAAKynKbPXY4dksCcOde99/ly5rGMncXM81Y+W/khm3te6LNadL8VZ59Y eebiS+yxFR7N9Se8QL9f3p49Xy+Yx27vccDFHxxb+c7Ki5YsWiycKF6t2G1x 9vxKRSxR+hWXqeTs+Zsbj+3U2dx1XNf12W2CS24PZ5MwnN7+C1YjY9UzJ/C/ xdIJwkUIT7ylEwe+R3Zx2l+u9MF1Vm4ZZ6rgec6UyEXSZLJk8p69Lnd5plK2 a7Ot2JJ5F2E4XhDE7PaVdcEjFyYHnu/V8+SY5II1sq2VccaGePtH/bIXLujG z5OX7ACLuGIKl5aTe1HTdXQuU425TrGDbPMty7M9WWSpyCt2lC2T5fSX2x/J pOt4C8/EgAc1O/AjU5I1KW/0mwdZ/gBromG5hNmsxCPBYtdl++Lf5F/n1iIw buW8nvrk0E6wS1HnWemwWxwZJcUkg+mAEUaTwrsqS3h+cgupXRqLoqhSrjLF ahOp2HH7aasY5TsrG9E9U41ytJHna883iUO+0RQB5e0VzHl3U+3QJSXldroM nNWEIr+byHrHy0zBsc2R/aVU8LEevHE3tYYXvd1THZFHdxkah29EFzrlSzXH XDxj/5h6ngsPkdPOfUGPX7f2m6zED4rtumeiRCwsyZrjoFQBhkJfoXOm638v ZVPxJlUz9qXNUCfV9CYa5Ad9qUTFa94ItkHInTUqmu5jVD7nuIzKhCTjP6ow TPNcdwP6hsov28YaE/qFRh5KW39YWpgWouoilaqtkLlEFveybvgG7UxxsKRu kd1aMVmzN7w+sjUGA5XrrdiST97Jtmw4kkMOo57dC74XRib+97hlY7oaczLI KEezNw1uLGT/m/ia5K3KHsSMHQRL+YMYtNnCt1XLsyJDwqTpcJX9KvQ84XNX E9lWitIhStX2xmlIKD94cZRa13bvhsp431kodH7gkMhzUXZjOtOZpauSlJeJ nlV8agZuhqGtvHxAaptUqlGIGIE6g7FyxyqJL4p8H8+F9vRR8P2MIdcFIMxh V7KoctEgVbijj3uXag/75gQ43Lfls87S58mVdQtOUd1odPQJ8bXKT17Sc/RY I1F74FZ/es70I/RfN9jsWmRJ+s0bBxp3spvInOCjHr1x3SqVcQxdgfbLOGC3 GD3/URwIic1ojp7YaeWKnV/xKmvQ+teiajd5lpzboY8GYOIvKG+v0KiYsQv2 zkzJjagaUWxMQz+NEhrtl7HJ+ZZn+ZEhlcCFwGW8oM/rOhPbGrFjjLlCkW8a rlET7vVdhMY5pQ9jEfkWfClHeiy6lJcUyt1kzdO65ltlbN1NMQgp7qBhP6R9 j2A6hi3sx1HXwjtKDtJ+nwEf0xesQNxM88UJJjt4w2xTU8MYr9GPQ4sd1/a8 +XmCco1NLLSJDd/uxDjzvQ3vxNcfkClxwUYJD/BOuAJt23x7viXM1z9fv2e+ e6KRFlzFKjIx62laVYLvaYz0ZL7QLsytyUeF9FfWcMhSjUIYHK44ilPr+Ami AUdtiURv+snZU5WvUpHs9aAOhjFwbU6uUo52FC+MQVSU8gimk/g36QxtM7BD T4QEqRX6pQLgghL6uTBp2opKqqxxRuIGTyfvNeP9KuqLUQojiJ3YNykkYost SjxR7Av2IZUlavCnMJ7fTdy7aeDOFzgceGE8M+mz5kZsOaD3OSAjZxdAjpLv RIGe/XNmLiJwn8YebnJQC/ZEK01+vv4b6xqgI3ywfeQtrfuWLw+HabBAczlD 05rZYdq4aY8NxMKw3wYe+1AQ06XjT95qLCPdoqUMVanROSF9seaFbFXX3foK JCAapuHz5BN5FU/41J3k+/9dgswfW6Q2im0bfdK6Cp50dvRly4n1dDixoEUz 5PSFbx9Qg57hhkoxCHu60FiOEScoAmsAjjvzdFG0sKRjkBXCRqXykFA3D5HL c1cWDBMDu4BsqwdhPpeyIE83Eqi61QpEVVmPVoadh+rItxz5ToAaQQCYsy4M mkFxf6KiFnrnplNK0ohI+R2Ccp1o1UVOb3yoLdH8Fd4pYsohUdIb1/KI299C xQwQkMINPGPmTX+i3MICgBnoOnKQzHw0X7JEO4Qkt0XJ5hiUev8IWYMRAdRI oNUub0SNuWKlIRG6ZSg4ifFQ+30pD9pat0aFK9cJoyAarVHfbksRzd1pSQoW oRPTmjbaksZDFPeKA5JJbsGcc9aWQLhtjhL3mS0yyDiSiLzuvN1pZQTwhEp7 ilS0S6S2ntkl68TTIxewHdoBWaPu8qDT1Jej6VXfjXwgOc2bhid71lbM9gc4 0O4p31K7Zy1vuNagu0GVO7Na2KDeO/aBUJ4T3iEHqAAGT9bzUVUXRg+XtCvR VPwkdTXXWMVETdtCDsxnW1kIIyEBGnRHKQ6D1Szo4r1vG70cEmBBeUBh9qva lr0hBTedU+EmpXbq7y2mG7BBhtcCAPLUekZkVZKapQ51HIfuL0n6C7NHvOZP FQSCByNlKJwi6NUjsKIvwCvIzJSGNKtm6JGtecXaGkIeGtQ21WUNZ0W5abvA sGeQlrV5eStzmfAWsNQhxGwQkRfb4XyboXiU3su23AvLQLMBaTPL0LOBKLJ8 Xw7r5xlAmvAkoY2mC6yQlF8iB0FIq6wYowHoegwF6rceL+rCs+d7HM/pJPpM w4fWCAU0gmrG4DwCybBTn1SYDh1+u/Zk7Cdx+O7MGYhH7Ufy4vsDeCJSI59f QoLlFPl74NzGUuX39bMXBY/0cwysIvkMDeQTH1bFt2pZR3GO4VNiw8v9+QCU w4XFdpwfaPLeIrT5kxbfJa8koGCrhj200raArVpxCfZPKTsJP2PjCxz/dEdE d/QVhxS0TIYX3wJ+hEog07Fo1PuG3cwveVr2i0G3sH5p+WAdHAn5sAOAcQDn V+A4/cO9EDBecHX+4nfI+vm3MPB5YjTqYzW//A01P5TwVsAFnYQPFn7YCzjI vD+M9KnnBEs/Pkn8vrWCMLTt7fmzOfTUWOvru5CcJHc6wT/vBL/RgKGzDKJH UtXvhbneCWas0/s5uqmXSaiqGuoJDQfUBnXTllmTAQ+HunyQuSqVjdzVvEqV nrdeeKE3+5IJldJgQiuUKHh/kyhb4Mjd9Jfv7EqDMf0dWn/Mk/93sv/ETqf9 NIDW/zj1Q9gQuZxrKQ7o/Zr9F5Q6od0isLNscFLUpsoPGfBB0pdOJQik8+M0 CuEcrmpwBx4ORpo9yF0rHPby1ERB4BkWTbNdmuOvXv70EgKeV3TI3MpURurJ i+PlrNfkPd74QWTH5tRYohneXkpG6yeaICs4FgW+yc2GS6JcMxaUSHockd/C VhoxRX1EDlt3Q1IwVK5yCoewf3VBMKu/EEO2OVQK2Lofr+1gcoLYenuVNcer ugWmI4/JMcn/w3617TYNBNEv8D8MT1zUuL7tesMLggghkECg9A2hyrXdNq3T hCQU+HvO7Hpn1wHxxBOqFCk7e5m7Z8442DzOEmjgLS5Qi9TybFJ6x+3/mlOv +ePHCDjClSwEwkZLCiWXR7rapNHbWo/qYOrDfNNMIPxFs1+1R2FFe5ev2s2K l6sdtLpdDUAGh98Hr2xejOnYbjisxQn6RcDxDoYASzBe7roVtwWMHyM77uJd N4HMpW8Izd3mwI0l8EqtPpG+XL9n1BDCg2GM8fENR2UECz0kcmJM3KHDLNLC 21CCwVR7veHqi77jufPQ6xwSwe89pDkra1gZ8VVqBC6RrgvAn05K4QjSC/oJ 6ANQiZn0sGvu+0E6d2/lx8D35A+Q1iu9x0R2+N6DcTHLY65bjC3XzXA523JD SUPfNtpCyCfLDefJ4w549rZnnS562q7QxzvWEU29QVbuDg0+zO3QtP0LIPsY sec+G72p+NzWj+hld2+HIMmefndvQQC8i9YLIeum49mWM3gC+zJdqbgKzSQD Gzr0Q7/lak5339bAX5TlNco2oW4ZTH7GcE6s9hNHjfkDJiZSg3jFQXYBhEpR Oh4lrfuCXp8ln5KcrpLTN0v87bFeUVLOEW5ggdzkKc+TZVkgrwxqbJECrO36 5PJZ8uqMa78rv8aOoIbs7FmXPHZmYBoXYqfwxx132jVKD6x6e7agTMHd5+r8 8ulMzedIacY++Gbu+kP69UdHlOmUfyWhWj0vaqJlz7iu0l7/nN6A+zvIvyHM IvSdseN7+vwlow6WsBUFrd1KGRoSu7BbpVsNiS6rtKi1vxtI+0BrIe1plQVy YMaqwDwAwGSlKJVZggUpJQelEEFceCc78tgLDSy83MBnmZwu9rB2sUQYlosP 3ErYAf+92TbmqTOVc7I0nHcZC9RZIAc5VaXxGo0X/M6QFDmZ2jDkxTETZWYJ KKMKKzocy47cKRnfWIHO30JaH3rSGxgueCewvwzqseMPf3liEMvDsfdOuBPk OfOrYmK+kBrXUEyAkNK5Yrqi8BREC06A/YX2Z9nxw8ivfFlIvMq5RPjXUC9S StvLo1A+CgqOD2ON2+CeELCqOApY2FFpZWVb/gpVii8EFo4OpoUb2RGDaU4E +xREZaUW81RVTWWMtBgpF7yOnsGRFa3NNAksCluIqSVylGAC7mUfmcrlHz8Z l22CMs6B8Ru58o/sqvK3mMDNuiL/QGfCbFxCmVGQP6vlVaRZG9I/ZKQyRxkZ dqw2WqlURXoKCzFEYzVHzsmNSk8YCClayI5TURiM2osIMU+UkBtmyuHIivYv pfWh3jzUm4d681Bv/nW9+SXAAA9GUn4NZW5kc3RyZWFtDWVuZG9iag03MiAw IG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjM3IDAgUiANL1Jlc291 cmNlcyA3MyAwIFIgDS9Db250ZW50cyA3NCAwIFIgDS9NZWRpYUJveCBbIDAg MCA4NDIgMTE5MSBdIA0vQ3JvcEJveCBbIDM5LjY4NTA0IDU1OC40MjUxNyA2 MzUuMDcwODYgMTE1MS4zMTQ5NiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoN NzMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8 PCAvRjEgMjYzIDAgUiAvRjUgMjQ3IDAgUiAvRjYgMjQ4IDAgUiAvRjEyIDE0 MiAwIFIgL0YxMyAxNDMgMCBSIC9GMTYgMTQ1IDAgUiA+PiANL0V4dEdTdGF0 ZSA8PCAvR1MxIDI2OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMjQ0 IDAgUiAvQ3MxMCAyNjIgMCBSID4+IA0+PiANZW5kb2JqDTc0IDAgb2JqDTw8 IC9MZW5ndGggMjkxNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiZRX23LbyBGtfAD/ocuVB3AjQhjcCPgpMsWVtGvLWpGSyyVvuUbkiIQN AjQGEKX92fxIHnJ6cOFF2iRbrrJAYKanL6dPn/nRE5RQLyYhIpci16eBEL5L hWrfrXqfKOs5+BELivBpYJ6wgN+/m/aOfw5J0PQBGxz8w7bItSMRDCkIQzuI o4imq97xSAc002aJQ3rWOz6bCFro3sCxHcdxaTrDIdNNz/LD/vRbT9QL8Scc 2p4f+nBADO3YcwWbq3cJs8t23OGQt95ZP+dVQSX+0ySLPtYPLUX3KskWlD/U vx9U+2FOSUbvVJEmmd3/ffoLIgnqSBwEaQvPi2l62ng1yrNSzsq37FsXsW97 wziEm7xsx43bfhBYqu9YaV7Kp4TOVvfnzUnmoEGzceeUO2vaF8KxI0ular3M M/WW/uHH9MVyvvQ9h3zf6w8EEhpbIvYdY2b6U89Sg5VM0rcI5SH/56OqD7Tn iv3E9xfZvbl+/5bqIIRbR+HagR+KOoo7a7PZ9L3QDi27szbLV01+mrgHzRb8 dUMO+nS3IPzo4isfd0J6JdOUNKKalUmeoQ60qJI5sr+R6XdNmwSf7xXparFQ usR72Wa5dTC24xdgcLzIDsIaDE6d9cbzyLLvyxVScKyyRZro5XGVlarYqIU+ Vl+rzdc/qodKa3tZrtL9sm8xJ0LPFvHQw7Pjc6wen3NnfRqf9Icejpiej68P chLbQRS8kpM6+Xbs+LWbH/K5KmSpqFSrNT9VBpChpTSt5DPnQj2tkS0DUHPI Hh73oO/5QVibnag1DN4D3bEAum16V5WUz2ZSI+sypUIC7YmmLC+pylDSVZ61 KILFuLUzrwpul3KJtXAvyec2TZdd0zzkXV9J+iZn3xVOKUhvFEIqSGbzrVHh R15tVGZUre7bnWkq2ZP2J/uiMkaE0og7AV6eCefAB6TiUQ22FsMgaCxmcFLz cWbVxXQE2qHr5BE+vMtlSXpZtQ2fKtoJtd7+qR8wA2RKz+VzXdIDDohtJ0SH erbviJDzbl1cTm6uTy5H4z0OGDQLt2VH4GC++hxkDunpu+zIQmaJVkVdZS4D Kr1U6bxLhF7nmU7u4S9HL7Pnl8Xn2rsGSFaSfauKZ7AdrWVRJrNkLbNSczHm ciUX6ogz81CaHKW51tx5KOigYQZYGkai9lIbhNyj37MF59Wmq12TeplXqUn0 KyhYye9qB0cNB1pYnBSUb4C5TFeFzGYATIG/C4Vil9qukxi0FBQGCHAn23fW FZcltk4mk6uP1/VpUzq5PKXbi8kJXY9/u7m4Hn8YX04nL8ipNrZXET+I2xHR up4sMnpMdFLmqIlijmDgn6lihdTTUj4qk9yuOlhC8vWStKh8lGkyp4s5libl M43aITTnslxJjQoXpU2nYMMF+gXst8wpU0x6O20Th25jLtGyzf6sHkAG7rWP /EpXqSy2sy2ZKUbAbgsGdT1ADTg+wWfQQF2cZb5SsAF2LPAeNU+V1IqRicCX suyAEgz9Jnl8+O3peIBpuJ2jXNqJKh6bw42HulpzqEjoblxuY+Y+n7Mn2xHN 3SAZ+Ei4eirBBgx/ekMX2WNSSjM43nBX7CEtMpHJ9TpNZrIdLpyzfXDFthdD sQBcHR7Mxsn5x6uri8uzw3auV++ix/fdlrs1U0u+3nU+zXF6rSY49O6D7B6R Y9M+r4EnDEWLTJRhXiSzpS4L+S+F0T+WuhzUuuFL3zTyr1Xx8O9Cc4bkarWT 2yhuevkLc1toALvdayicDOoA4nsASj122GRIIMsm+RzbTo6FM2wJfE5wqwkH E7tcdrEtlg2gYLdMflSq5uUs54JuunQAxh2TD4ztoGEfBt9no37YXK0IHhKY UE8/Km5Q1eYcDYPpATo3mUY4KtuZDqDdpg/nEsyIBs4qRW9uuLUJPUnvYVRl b2y60RVPmZphjg4rurXoelHjZL7G/oc25hV9yFEBw74oGz9hDDi0pAG5zlt+ OmqHTiuL/QhACrxgTxa/VL9DhuN4Wgvm0aQRzJMRvv+Ch2+EfqQNi5QPdPe7 Q/OeFwZwlDWRE9hiGJLrM2QD4Myzw6HPWt2P+fCoOTuGqp+wdt8qHi/07Zjl /X+R2cGwQeqkFS1AD4fOASMTIjSR2zQ56BCUCUKHx/oMk0jNX84LJDijSZX9 +TQWURC/7OHRzfX1+HL0mQ6buF6+28TITrAzlLeUCcFBs6rY0tkzt3I7ByBU GGvjNuAcfdn4JrxGN0KgRmAjp/GrreXf9pwCuoN6yX5WnVp5WdylBpe8a+Bi uQebL4RfIycd34vqaGatfJwnJc1k8wtd/cX6AP5QzYvtlyM6WWHWzTBBxk/r TnzqI7qtn8GgTDftl92m7dx2Y6chHDmbsfQ0/LfE7EhhaK5Yk/CgB2t0A7fm he5XKQ8IwW0sFqw6bBrt1KQEdowcfJotWUOQUdCojditTFuXsKtLgBr9r7JE GJIvClM7ZGjfEkeg6Ju/70+VgQhsP3aDA5A1U+nOGr8fj6bXF6OL6edjujr/ eDmmqxrauEL4trCmo/MD4eLbkXdgzx96NToYs7jpZRDl+QZ0xgM2Neh0cTu8 pZPREQUOnf9hvDyYMW5799iTdUnGY8SI/ZwqrUyC+WWBmyY4wMqg7bdN/B3k mT7vtK4X1PNXf0fxYcIoJmiSDHcXllTyETdT2crZsguA7widBo2DpuhTMwAi Sz1JoyKm9T3mZEwhkNwonvUyzzAMSpjoxhegisObc7fueZHfCtFm2wJEzaND QuzmC0wGKCLk7zRZQGKkxDjWeutZx0xfrIvJ6SWOaW5n27hgrE0Pj73S3oOz aJI+2knJ9vLUGcFlZcWyYi/zRs6wU0nBOkrv90kz5Vjqv95oNhmlUrdjXZjd fK7TasG6/DUeblRM21P5ylTjvtIJLkuaZjiqPeaAo0NbhJjpeyIeAv36zBD0 ZHzdH4TW7cVofCjY241b4AuB+rlNJ13l0HdAFgYIASRegClnASyvSvEujpPV PbQxtOkx/Zx0kx0iwaJ3RbKQc9UfeGAxQ42wLIRrDGL0bgdqhJYM3IOB6vFA DXy0cuxShFfC5YEaDjFZEZIDYhB/bU8YwTtwzCuD+0/3gH8xIfy/dE6EvDru qwLh5Z42C1EA5+Lh/3fQpPdbT9Cid3w2wR+N54R6HrQRbkhCRMJmieF5Lhrf hyVc1czpDz+xGgFz14iIjCqJyMgRHAUl4sDo7gBqoFHkiwJCmERk08V0RFBA jvc1+PrQH0DmoJMKXCHQV6Cy/7Bf7dgRwjDwBNyBE/CMbXnZXCBdmhyBlDTp cvyMhDUCiq1S5fHeFh5bv5G1spi+f77GMbVJf2Uc5/yWHyO+XHS+rItf/jy+ vxi1nsoia3Z0hYFqG2xhW2VfbUMrdcoYxLpsQFNojdBOkVfCTQ1Lxvye6+5F JBlQRyI8KAThLvS4Q2V3Gibcb9j51KETbDF1zpg4P/Tl0AT8e9p259NOVWsS oxXqLtmfIAXceCpl8Yi6gO9sA6YYDINTacpSQUkGEIxkcx3H3KFMKa073PNN aDl06ARDwJOg+VqkdvvIl4ONzOPYsxMy4W+nX/OJPiE+Ixq+YNB3p6cormOo AqywVKaSm5+lq+IhrypMCK1ZW4RrI7xDUM2Eu1M9igC74jHiNdITF1bz5cJi BxOd+Tb7gi6lAmFix0EtJNLFwLkmgp/AVSqN9KTWs4+OSZICHqMbuLBYrdJ4 sWhscacG0PgFLdxytNS9/lSlL9dBZ31cjG/M4kq2qi4l9h7oo+EKLdFYXyKY 7sjPHtQ6RLZG+UdFynKpyNixaBpefznESRMk0rB6ouYoUdvJACGj4M4eIg30 6OmC9BgEJZazhQuL9UVrvfvN3W/ufnP3m7/uN78CDAD5bLtrDWVuZHN0cmVh bQ1lbmRvYmoNNzUgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIz NyAwIFIgDS9SZXNvdXJjZXMgNzYgMCBSIA0vQ29udGVudHMgNzcgMCBSIA0v TWVkaWFCb3ggWyAwIDAgODQyIDExOTEgXSANL0Nyb3BCb3ggWyAzOS42ODUw NCA1NTguNDI1MTcgNjM1LjA3MDg2IDExNTEuMzE0OTYgXSANL1JvdGF0ZSAw IA0+PiANZW5kb2JqDTc2IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1Rl eHQgL0ltYWdlQyBdIA0vRm9udCA8PCAvRjEgMjYzIDAgUiAvRjUgMjQ3IDAg UiAvRjYgMjQ4IDAgUiAvRjcgMTQ0IDAgUiA+PiANL1hPYmplY3QgPDwgL0lt NSA3OCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyNjggMCBSID4+IA0v Q29sb3JTcGFjZSA8PCAvQ3M1IDI0NCAwIFIgL0NzMTAgMjYyIDAgUiA+PiAN Pj4gDWVuZG9iag03NyAwIG9iag08PCAvTGVuZ3RoIDE1NTMgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsV8lu20YYRh+A7zDwiQqiyewz TG91liZAllZKc3CCQJZoW4lExSQFt3nZXvoMPfXQf4azkLTjOmjQFoUhA57l X79/mZ/nGUVrlBWIUsOQYQJNKRUM1WU422avUZUR2BQUGbiauhUQ2PPv5tm9 RwpRND8BBgI/YDMMGyo1kkphWRiD5tvs3mEj0bJxJAQ1y+ze4xlFp002JZgQ wtB8CUrmF1kuzGT+HqTKTirtOOAf1QQroziYQgXmxhRWcMdPLX/+/MX84cxy P5x3Cg9nXuHsEKQ/hcV7RLBEF1beM3T0lqBVpjRYCT5QJrBhFDFBsBASHOVY aW5dZUTgQgbFBYAyu9J1oQusiRJIcokpI8pamL8S3iauJGZcXKtKFBRbxk4C daoosj8AjQuDaWHAemMwUQwxLbDmFE1FARZ2cbks4eRO9kN23oX6RiJe34HY hgidZ0yDRFVo56WgFGulKOKSYakMUlrhQsBiCWF+spXowQ7URYV/L7d8FnSq NRICUkqDJaqQgBy5eW5hwrSxCXaUv9wfb9ZLNJ8AUDKvF1XzcVe39ydv509B o+40EjAGM6lh88BmZkjPb7rs9IEHEips9IGol4lOm+60PaonVGOd77aoXqw3 F4tfUNMu2vWuQl6j97HAXBasL6tXFQcvmvZ4cVad7U4OBhYobIhQHVd+sW7P 0KB8GKZSsWsNnPG7aCbvOmOm1GDOgAach1gVlg0oNFAU3lqvl2NWGO31trvk U1+7wJIGIu/H00VV7cDOT8f1H8sPpXfGgz4tMOGMX4L+L1G/FOMOdWVRX6xr G98R2hIbzoqBabPl2e/VSblZjREmDNL9JgjngNLQUEmJuBp9Z2gPuYHQKZVY Mqn6cbgRgB6afwPAo/xgPqEUmnRenpabg3G+aGGuzUMHbdB1vG9G+jQkJqOf KQ9KxsAXmvNr1FngQYdlsjlvtBKXsW7a3cdxsJnRXm5P2MGs3bft6aJuyxq9 3CzaT8MUMljbh6vLkW/Rcle162pfosvZBOVcaF/O49LU4BRlLrb+Wv3X63KM OpRYudpvypUL8GZdlc3QMmiCJngPr+NdxJQcOigwY/BkRgetIBuoUf3Ag0rc yzqun+/LdVWvl2dTuyins7Ze/PpVq+gof1WtynrCbPmchjLaV6thPitMjQx+ vDIjyYoweW21vMlfr9u2rBZ7cKTeQvQa58mbCWp3XcLAqwPD1xVZfUVGcKgu EbrYjTCCHOL/KETsyyH6cX+2KY/LCk3RT90rDO60iy9E6rNA9TvAs9/qD+sG 0rtBz/ZNud86uNL0KhSMjsSMptd8tm5L2zEqPyKmUY8rrKAWKJUM+EGTLT8Y F6mwA5IkcE14fyR1Ux7MPXH86eY9KF1p6QzFdsTiHB4sZh8WhpUTBXxu1KK+ VzmLDQJaSqHXgZUEhPYx9mNUvTutF9stDPwYPZkfIiKhS7yT704mU1kUuMhr 9KSCjgiQ4/OfVwiBzfaPI0TZfaYRmpXWfUlcFJz3jz8/p/M4NbqVNGjjBknp jni32mSKQ4fQKtCmrWNQKm7dLQzgcbuxgiVTWMOs6rRISdzGKpIyXvC4SeoS XzyJzEFpEhH0JjkzO8aCt/DJQuFz5TkkF7MA/O/ddjHHnas2J13Oa2IVKpK2 m3gruQkWeYJwsslgQDAaRlhlvbQbTtwGjIGvFas6XceTSJNqrsM7laDp3QYH E0EAweJlpPDyAa+w2UTP03VAJ9EkfZ37gg3cj1sFZNCuOJS2+yiFMk6ssLHN w7YpFe7ImLGHqyWOW+CitkUEbjCvZ5RyxF6pvUoGesa+xamF9QIm2Chg6QS+ 55xuJ19Cl7IESUS3T64lCjISMMyJ5J8EVYSr6J4UYqjD76OTkSDYGASMvFi6 TIuBhcaWYuo2FFowYsJhZESXf5bFL5eZff8gMOGAysDkViJQ2Q1QaoECgyJR mF+CMV5RuNORq2fZMqV/ykhpRhmZTpw1SsJXSc/OKCI6omBVQM5FCqEGAuI2 WhFPOhOjAG99VBHdi0ZECjOUMPJieU1rve03t/3mtt/c9puv3W/+FGAAMbb/ nw1lbmRzdHJlYW0NZW5kb2JqDTc4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjcxIC9IZWlnaHQgNDEyIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDI0NCAwIFIgL0xlbmd0aCAx ODkxNiAvRmlsdGVyIC9EQ1REZWNvZGUgPj4gDXN0cmVhbQ0K/9j/7gAOQWRv YmUAZIAAAAAB/9sAhAAOCgoKCwoOCwsOFQ4MDhUYEg4OEhgcFxcXFxccGxUY FxcYFRsbICEjISAbKysuLisrPj09PT5AQEBAQEBAQEBAAQ8ODg8RDxMQEBMU DxEPFBcSFBQSFyIXFxkXFyIsHxsbGxsfLCYpIyMjKSYvLywsLy87Ozk7O0BA QEBAQEBAQED/wAARCAGcAQ8DASIAAhEBAxEB/90ABAAR/8QBPwAAAQUBAQEB AQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUG BwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGx QiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOE w9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn 9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR 8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj 80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwD0lJJJJSkklB9ldY3WODG8S4gD8UlM0kH7Zif6ev8Az2/3rn+p /WPrHSHPtzelB+EHQ3IpukBpMDcC3n7kqU9Mkuf6L9Yjl4N/VeovpxMJzy3G YXe4Bv0t57uPgFLK+sWMX1PwszEdSWy4WXNa6TqNHGREa/HySpTvJLJrzup2 kNZXR7nwx28asn6e0PJ1Z7h/DSR39SzKbd7HV2Vtp3XVuc0Fj2bg+I59wA+l /sSnaSWb0/PyL978r0amNaCA14JExq8fm8q59sxP9PX/AJ7f70lJkkH7Zif6 ev8Az2/3pfbMT/T1/wCe3+9JSZJB+2Yn+nr/AM9v96X2zE/09f8Ant/vSUmS QftmJ/p6/wDPb/el9sxP9PX/AJ7f70lJkkH7Zif6ev8Az2/3pfbMT/T1/wCe 3+9JSZJB+2Yn+nr/AM9v96X2zE/09f8Ant/vSUmSQftmJ/p6/wDPb/el9sxP 9PX/AJ7f70lJkkH7Zif6ev8Az2/3pfbMT/T1/wCe3+9JSZJB+2Yn+nr/AM9v 96duVjPcGsuY5x4AcCT+KSkqSSSSlJJJJKUkkkkp/9D0lJJJJSljfWGmq/8A ZtNzG2VPzKw9jwC0ja/QgrZWT1v+d6X/AOHa/wDqLEQpKPq/0IGR07Gkf8Ez +5ULuj52b1hv7TeMnpdLTbj1taGM9SYDbWyS7a3hdAklanlMP6m4jhnYedSH YvrGzAta6Hta8DcNPA+KIPqX9VmWsxXYz33Gsvk2Wahpa0uMOA1Ll06xsy1w f1TIYffVSzGq/wCMcHP/ABNjUrKmp1fqnTuh2VPyOm3GuuBTlVhrmj2hn0t0 g7RGqt9J6h0PrlT78VrXWEFt1TwA8Bxkhw8Ciuwb8Wn0qh9sw9u1+JcdzojX 03v5/qu+8LmMr6rxcepfVe92PlVGbMJxLXNP7vu4nwdoUlPYOwOm7H1voqLH jbY1wBBbo6HA/BA/5v8AQf8Ayuxv+2mf3LlMHMp6zl24fV3vwOpPAaai0Na9 4DWS2dRIb9H7iu3xaBjY1WO1xcKmNYHHk7REmEjp1U1q+h9Frdur6fjtd4ip n9ylb0/pldT3uxsdga0kvdWwAQOSSFdXFfXvqtz3UdBwpN2UWm4N5IJhjPmd SkNVNvpjDmXURj41tbXRkmpuM9rWito92yT7rA4iOy6D9mdN/wC4dH/bbP7l W6B0eno3Tq8SuDZ9K+z9555P8AtC2xlVbrLDtY0S4pEqcnM6T0DFq3HpuMbH HbWw1MEu/wA3gclLE6V9Xclvt6djbgA4j0WDQyAeODBQLbrsnLnaHOJDPRIm PzhSfl7rCPh2V834vSq667DussMvcBqTwXEdgOAPBHX6qV/zf6F/5XY3/bLP 7kDK6F0utgfj9IxboPvr2Ma4t/kS2J+MLXa4OaHNMg6ghOhZU8xj9G6M5zvs WHj2FutuDk1Nbayf3XOaXD5yPAq5jdK6NfY9v7GpqYwDc6ylgO8/mtEEEAdw VY6tVXeasZjZzLCfRtEh1LR9O3c2CI/E6I2VmMx9uN6duQ8smwVavawe3edR 38NfBK1Ih0DoDhLenYxHiKmf3J/+b/Qv/K7G/wC2Wf3IWFY+ihownDNw6/aK xDbq4/N1gOjwdB+Kv4+Xj5LSaXyW6PYQQ5p8HNOoS1U1f+b/AEL/AMrsb/tl n9yX/N/oX/ldjf8AbLP7lopIWVOd/wA3+hf+V2N/2yz+5UOo9K6Zh5PS7cTE posOYxpfXW1pgss0lo8l0Cyet/zvSv8Aw6z/AM92o2VOskkkgpSSSSSlJJJJ Kf/R9JSSSSUpZPW/53pf/h2v/qLFrLJ63/O9L/8ADtf/AFFiQU6ySSSSlLDr /TU44752c60/1KnOsYf82lq1M684+FkXjmutzgPMDRUsakV5uJizphYmo/lP LWA/dW5EKdVVsrBpyCLJNV7P5u+sw9vlPceR0VlJBTg9S6fTltDOsYX2kM+h m4wO9vmWN94/syEfCfk00BuHe3qWPXoA9wbe0ful3Dj/AFgFrrH650R2fX9o wrTidSqH6HIYS3d/IsjlqNqbtPUsax4peTRef8DcNjj/AFZ0d/ZJXEuczH/x il+do17h6DjxLq9tZ+/T4qxgfWLqQIwOv49Vzja6iLQGEuaGuGplmu7Tj4qx 1TofROoPY/Ivyen31jbX607W6yAHvBBE8Q/4I0h7FYfU8x95ikgVsPsceJEz aYMw2Ib/ACvkihvVThCv1KsysNg30ktssA7AatBd3O5Q6bU27IsFrmzjun0R pB5adv7rR9HsTr4IDult9MwvQrFlgPquEAOiWtOusfnOOrv7gFVzhkszLn14 7rt7WBhglunMrVuvqoaHWvDATAnuU1OTRfu9J4eW/SA7SkCd6Ui6ax9eDSyx pa8DVp0I1KLk5FeNS++0+1gmBqSeAAPEnQIqxcrItyrm20MFlVLy3HYXAb7B o+7XltfA89fBLcqR+rfVY/KscPVJb9oYzV4cf5rFZOnfXzkrUwcZ9LHW3kOy rzvucOJ7Mb/JaNAqXTMYWvGSSX01l32dzubHnR95+PDfL4rXSKmpkdPpuf6z C6jJHF9Wjvg7s4eTlRyhZX78+oksH6PqGLLXN/rt1Lfxb4wtlJK1OBg9etAa zMZv3RFleroidxY2dw82/cFt03031i2l7bKzw5pkKhmdEx79z6D6FrjuMCWO d4uZpr5iD5qq2tmKWtv3YGT9EZbDupt8PUJ0/wA+D4FLQqd1ZXW/53pX/h1n /nu1GGfbjQ3qDAxvbKrk1H+t3Z89PNA6y5rrOkuaQWnNrII1B/R2pKdZJJJB SkkkklKSSSSU/wD/0vSUkkklKWT1v+d6X/4dr/6ixaywvrTkvxKcDIZS699e Wwtpr1c87X6DlEKd1QtsZVW62wwxgLnHwAXMftL665/9F6dVgVn/AAmS7c4f LQ/9FQr6H1bLIs6p1qyxp5ooYW1kEd4DQR/ZSpBujW7cy+tb8bdl0VswchhL A6wi17P3mgNgHw1QsHquL1LIdh05IPUsPXGyXNLfVYRJY8ECf5QH9YeQsfDz 8al+Ayl1tT2Gs2W2l1IB/PbVs3A+S0341FVODh0sJbXbW6y0MIIFILw4mOXO aG/NNgZdWLEchPqvbqK1/a5r+vfWjIvuxsHpDGWUO2WPutBAMTMezQ8hP9i+ vWVrd1DHw2nltLNxH+c0/lWxg2M+0ZN9vssyLdlQeC0llY2tAnxIc4fFaKd9 GZ5UfV36zs99f1gebPB9ct+4uP5FFvXOu9EuZT9YaW34ryGs6hjjQE/vjT8g +a6xQtqrurdVawPreIcxwkEeYKVqeR+sWGzrzRWB6drCTQ4d3HT3/FP9VOpd duqv6VmUH1MU+n9qt4YP3XfvkDiPmtG7BnIOPg2NbtBJLvfoAWmvy+PZZbup O+0W111WP2PO41ljmh0hxbuZXEDjVIbakfVEpRjqTw+bo9WObi9Kvxvq9Xuu rJddaImSdz9oiHPPfw/Bc30f6xMy3tqygcfLqnZa07R57SfoeYMt+CNg9dry s0dPY2+u9xIa219TAT4AhkSVr3YGbRUbvsT7PSBc4NfS57zyfzAT8AnDRSsz rd7H4dNtQtuFrXeoCK27B7S63dPp6uHiD2PZW/q/l2353U6L27bsV1dToMgt AdtcPIhYnQ82rqxyPsZLMmoz9ktIE1QB+jd215aZb8JlN07LOD1+8YTa3faK QLsZziwiyp2zb+cGGHCPzfAwidqCnrM2yy6xvT6HFtlg3X2Dmurgn+s7hvzP ZUG4TrMk4ZI0aBaa521URDamcQ6yNfL5Kedm1dA6XdnZbhZlWHc6P8JaR7WN /kt4+CD9XOv9HzaRXTkfrlhL7mWwyx9h5IHB8oOgTEu+1rWNDWgBrRAA4ACd JJBSkkkklKTOa17S1wDmkQQdQQnSSU55wLcbXp7w1nfEsk1H+r3r+WnksvLx 2sv6ZYyl+JOaxr8YkGvdssO9gEj7o8wukWT1v+d6V/4dZ/57tRtTrJJJIKUk kkkpSSSSSn//0/SUkkklKWH9ZyW19PIMEZlZB/svW4sT6zMc+vp7WiXHLZA/ svRjuEHZv4OYMhmx+loGvmPELKf9W8kueRlUbXSIOO8mD4xkAH7kNj31vD2m HNOhW7iZTcmueHj6TU+UTHUbIBtxj9W8siDlY5Bif1Z/bj/tSqGR0zKYMx/r Y7vscNaRjvBfa8b9n9I0+m3XzXYLHuxxW+3DvcW05dvrY2UOWX7g9rH9tHNB Z4/R+LQSuRYX1fyMa+m12RTsqf6jq66HMJJbt+k658duy3VUwsp9u+jIAZl0 x6rBw4H6NjP5Lvw4VokASdAOSgSeql1Tfa/KLq6HbMdsi3IGkxy2s/ld27a8 Rst+1Nc4u9LBbq+2dptA8D2Z59+2nKZUcsN3M9PCbpXREF4HBeOzfBv3+CSm kxmPkZnpUEtxzXtbslsgfjB/FZGKfsdZ6d1KxtVTLHua2s3Mvkkw5npN2vBW 2x3+WT8x/wBFU+qX5tGbsbXkkWO21elseHk6+0HJrcNo59sJvDxdWPJj4iCD RHfUEHweQ6p08OfVhuotxupNG/CucD+sNJ3Ct23h7ex+R7Ld6J9cqL+lX43V rhRm0MLN79DZ+aP7QPP3ozn9QfmMrNWW7IraXAbKS5rXafS+1+3d+Ky+qO6f 0+zd1XCtbbeJZY/FpdLohztzch0mdeVIAAAOy6MeGIiOgpu9dd03G6Zm5eJZ VXZcKxivqcA+SPf9HUSs7o3SG9OdRm05QN95IFhIY1tG07nndrq6CO8Ce8K3 0rEwfrFbTXjV2M6XiWOuvY6ttbHPhuytoY9+vJcfDRbH2RjclvTmZtjCBAe1 zxBkO2fzncJxlZ8lRjTlj64dF6le/D6jjuNDCW4+WD7iPol0Ngt3eAn4Kn1P 6o4NtIzul5TH1PcGsLS1rtx4bHtaT/mx4Fa+Vi9TrbbZRaz1an7Mpl1lw9hd ua9h9Q7mub2+Shd0+9trYdvsu0bsLt8QCAd5MtE8GQgB2S4eJ9YvrL0B/o5j TmY1cBzbJ3NH9Yje3y3D4LsOj/W7o3VdtbLfQyT/AIC6Gkn+SeHKpl9Izq6a w6tuTXXrDNHjQAj94fFh/srnc/6udPyWm3FsFVu4tNRhrgQN0cNbp4ODD4ko UCp7zK6rjYt3oWNe6yGuDWN3E7t8AefsKPi5NeVjsyKwQx4kB0SIMEHaTqvP ejO65i9Ux8HL230O/RtfcwWPrY7T2mwbg08fu+C7DFy/sprZkW100Gyymtha 2pst+jt4GqXBpaOLWnYSTJ0xcpZPW/53pX/h1n/nu1ayyet/zvSv/DrP/Pdq QU6ySSSSlJJJJKUkkkkp/9T0lJJJJSlk9b/nel/+Ha/+osWssnrf870v/wAO 1/8AUWJBTLqODzfUPN7R+VUca92PaLG/Bw8QuhWPn4JqJtqH6M8j93/YpYSv 0laR1DHqf1lx+nX1Uml1otrFoc1wGheK4g95Ka3rONl353TrcfdXjh4tJeAX bGepLRz8DKr0YfT8u8NzavUluxpLnARO7a4NIBBPir1tHTKsi51VZsyLyRcx tjgwl42fpPdsBj5+CaRRpINuVi9doy8WnLLLRdi249TciWkvGSWja8jQ6RvE eB5Wj1nqdOPbZRdW+yujGOW+tpAFgDxWGOnzSd0zpdNBpyqW77RUBRSXlxFG lQEO3Es/e0UH42PfXbWMP9bprFVmPa9znWYxdvhj92s+PjoglfC6z0/qdjn2 O9KnGbU4stLWtFr93tdP5zC2I8UDJ+uOJjPza347zZiP2MaCP0sEhxZ/ViSt Tp+L039Lm4dQacsh1ztZLmyPc08EGZVLqHT+lC0sZiNvzrfVftJdDRaNtllh B0aR/sQ0Uxu63j1ty8mvDL34lVWRYQWgltrC/Qn90BRbl31ZmOHYz3ZfUmu2 Xuew+k1vuLGt4hog+aM3FqvL8arFEXV1159rw5rDWxu1rGDdJJHnp3Wm7Dx3 W0XFk2YwcKXSfaHDafwS0U4fTOu9Pqxcq57TTTjlzr77HB9ljw705cAOXHj7 lynUuq9W+t+VXhYlHpYJsAZIB1A1e9/k3WAtH67mnptNXTcSvZTnlzriXPdt LbGvljS7aJPOi6PpWJjdMwvtdjPRrZXtprjVlXOo/fsOrvOB2R8UIcrJ6d9U +k4+JWQ1zz6dU8uefp2u+HJ+5UKqQ+l+W67Y9rjtnkuA3czOqp/XTouXldPb 1myftFRm2iZFdLvotHm3l3xPYLM6BnnKxhQ8zdTAju5v5p/gnwU9blbOoYLc 4aXUjZktHJb4x3LfpD5jutLpmCyisXOeLrrACbZkbY0DT4LBfQMZjWW2bbnk OdXAd6YA9rj4OB1+C1ej5QYfsjtGmTSP3SPp1fLlvl8E2Wg02S7CqZfTcPM1 ur/SAQLW+148tw5HkdFbSTFOBfgOwqC3IIyMMPDhe6TbT29rIcPm2PgsHNZ0 3qRZVmZT7zUJLC+6Wk+XpLvVXyMLHyCHWNixv0LWkte34PbBThJFB5PC6hR0 ppx6M0tqJ/Q13OtfDQewfTpA8FfwvrTgWZNNVvUKnGwvDuzRx6fucxkErSyM XINfpZNTeo4w1AcGtubHccNcfP2lc51D6o9O6kXvwLIvGr6LJZa34kiT/bBn 95LQqeyfdVXX6j3hrNBuJ09xDW/eSsbqmbiZGR0xlFrbHNzK3ODTMA12LiHt +sfRA7El9uMSD9msn80hwLWz2ImWOPmtLpnWeldQzel10478fOrvra5pduYW Na+SHckz4pUp9CSSSTUqSSSSUpJJJJT/AP/V9JSSSSUpZPW/53pf/h2v/qLF rLJ65uD+nPDXPDMtjnBjS4wGP7BIKdZV8nLx6AWvO95H823UwfHsB5lUc7Oy a4D2OprcCRtiYBA99n0Wc/7VXqwL8sN09OrlznBwa4xBOwnc/wDt/ijSmpe6 l02h0Vu1YGmK2nwc/Rzz/JYreFhuzA22RWyuWh20B3O4ba/otidC6T5K8/pe OzHcGN3Wge2x2rtOw7NHkFV6Xf6d/pn6NmnzHCfvEnsjYupRjU0T6bfc76T3 Hc539Zx1KHm4jrw22l3p5VMmmztryx3i13f7+Ua66qit1tzxXW3VznGAsLqH WLrQ5lJOPV3cdLHfHvWD2/OPaEwWlML7JdkYTmUXXPNOXjWnRlwH02hvLo/z hCE2y77OWYoLbLHTk5LyHWP084A8PIcJnYWdfgMbXQymun3sqIIttdGrufYd ZG6Se8IHT8vHrv2ZLA+m3V1jmgbHTtnXXaTo4fmu8uFXZTfwsm7FrdWai+TI O4DsFo4mUMqo2Bu2CREzwn+xYn+hZ9wVHNvrYThY7hS2N2Ta3TY0/mt/lv7e A1QAU1M+rB6h1TEyb2GyrCe5lMCfVuJEwP3a458dFfY5vUcreCHYeI8hsaiy 5vJ+Ffbz+Cz2Y92U441M47tm0lo/otRBDWtn/CP/AAHyWJ9Scy7pvVMv6vZh h25zqp/fb9KP6zdU5T3Nlddtb6rGh1bwWvaeCCIIXkmZjX/Vj6x7Wuc2ut4f U8fnVOOnxjj4r15ct9euiftDpn2uls5OGC8Ry6v89vy5QiaKmriVHOc57bBB b6nqHWQSBP4olTyHGbNrqoh4kwWn2WDx28HxaVynQupPxg3DyHFtVwmh/Ygn Vv3j710+LVfZYHUs3bdXE/Rj+UTpCmOoQ9XhZIyqBZG2wEttZ+68fSH9ysLM osH2vGvrbsZm0k2V/wAtgaWn47SQtNQFKkkkklKQMjEx8mPVZLm/QsEte3+q 9sEfJHSSU5t+LkCs1Wsb1DG712hotHwd9F3zj4rAu6X02nq3TszELm3famss otBFjdzXnl3uI9vefIrsVk9bA9bpR7/bWf8Anu1EFTrJJJIKUkkkkpSSSSSn /9b0lJJJJSlS6jmvxRjtraHWZNzaGF30WlwJ3EDnjhXVk9b/AJ3pf/h2v/qL EgpuMw62uF2Q833N1D3xtb/Ubw38vmrBsrEy4COdRomsrZax1dg3Mdo4Huqd 3T+lV1uturYxg1e9xIGniZRU3tzT3C5/MbYzqDsfDYbbzDw1pgMB72O/NH+o Un4uM9vr1sGDh1xOW+Ra8AyPTDvoie7tT2HdGZj5N2M6vBacHFMneZ9e49z7 tWz4u93wTomv7UHVpZlGdk5gpdYzLvAaXNZLWUEkyDMhsiNTLj4QtTA6Vj40 W2Obbe3UO4YwkR7G6x8Tr5rOwbPsDttbdrJ97PHxJnv5rTp6b0uxm+qobXam HOGvn7kpAjyUDbfkLF6v08Auy6PonXJY0btCINgb30+kO481eb0np7Q0CrRn 0Zc4/fLtUnDE6XQ99bCN5AbW0kue86Na3ce6aPBLmYXUMprX4NDHXmQ3EvOr WtI5sMn2gat11GnKtZGPTj01YlbRfmWuNjXP19/599kdh/cEXFbT0zF35djK nXPlwmGNc8yK2eQUMWxuNm3tzDGRe/8AQ3n6D6/zK2HgFvdvzSUgsPUOn2Gj FpdbUW+o+/Zve9+202E+5suLwyB/qKrunsyr6s++hrOpTQ6xzQWOaCIeRu10 4W11J97MUuoDnPBEBgLj9zSCRPMFc71G6x+PZZn49noVAu3PruhsdyRYNE6B o2tkLD0uCZxwdxeNz9riZJbvdt1PkjkAggiQdCFynS+qPyMZjsFtluLWRW30 q7oAbHs1s/dXR4DrnYlTrw4WEah+jhrpu84QluT4pGzwOf0Cmrql/QrP0dWX OR0i48Ms/OqJ8HRH3Kx9X+puY2zo/VN32nHOxmO7l7t06cSYXQ/W7ppzelOy KTty8I+vjvHMt1LR8fyrnfrDis6t0rG63QRV1amtrsmlph5DfpHbzLIkeSIv sqwHqKXD0emPiCy51TgeW+y1kH4ELYXJ9A6hZn/V+vLtj1a8xhsI8Tazcfnv XSfbsOWj7RXLiGtG8akkgAa+RTSlsJJJIKUkkkkpSyet/wA70r/w6z/z3atZ ZPW/53pX/h1n/nu1IKdZJJJJSkkkklKSSSSU/wD/1/SUydUupPyQxtVOP9or tD23AHaQ3b2PaUlNyQqPU8W3JswXVRFGSy2yTHtDXAx96x8uplbHm3EexznE Vvfc1u+1xLRt453HhTtpfc2pn2K0bC7X1hu9xMnRGlPQXPeytzq2eo8D2skN k/Eqi7DyHD7TkhuVkt1pxwdtNZ8p5I/eInwAVJzba2BrcC+HucIFgJPqCHz7 TA9o1lCdiNc2u+ulwcXFhq9aXwIfoRwdw1Gv3pUpvZXTsu2l1l9pyLHCLcZv tqLO7axyHjlrjrPgETpWcbWjGtf6lrW76rePWqmN8dnNOjx2PxVjp1RqxWsN bqtXfo3O3ka9z58rP6ninGs+11O9Oou3mztRadPVj/Rv4sHz8Sl4KbOfgeoT dSPf+c3x+Hms/HybcZ8t4/OYe62cPKGTUS5vp3VnZfUTJY8dvMHkHuEHNwG3 A2V6W9x2cnxl+jLZaR1CVmdjOpdcXhjWAus3GNoHMrNGZuzG5WQyAxpexjjt GPTH87Zz73+HYaLPqabrG2OYX1h23Gq1/S2A/TMT7GfideAjOhoFe/1iHiy2 13FtjeDH7rew+aXCLoJvTV1cfHdmPOZmM9rgW4+O8fQrdoXOH7zxz4DTxQ7c O7HrNTGfbcE6OxbIL2D/AINzvpAeDvkeyG3q94HuY0+eoUv2xZ/o2/eUOCSr DWvmuucb7fU9pG1rhbY2J14FvZUMnLyrqbcfJflehbWWPa5jWyHaH+cxmRp5 rZHWH96h9/8AsT/tj/gf+l/sR4ZdlWHmujZWJ0rDsp6Z1Bha6wPNN5qsMu9p 27LWcBq36+oX2Uix3UsStv5xdXDmwfD7QQsX6vYDuh3ZdjXi5uTthhbt27S4 juZ+ktO/qTK5yHspq26+qWiR/aKXAeyLDOzZksPpWZefZ+Y4TVTPxAqrcPmU B+dg2X5NLb31vF27IcK59E7CzY+Wub7lRP1vwXsLjnRzoA5p08g1UcjKtZZ+ 2+kv9dr2FmdU062VnuQfzmpwBAOyDRILo9NxcfpPTM7AblMudbYbccAFhmBD SHcat8Vc+x/V82Ns+0P3V2CwDd9HaS8N+jxJPn5rA6Pk2dQoycmywg+oWYNN eLjuseQN0vil3EiSFp4mNkjczKdbuABsNWNjhwHZzqXUb4/q7lHYur1TxRvh vV6IdY6cTAuBMToDwEfHzMfJLhS/cWQXaEaGQOf6pXOs6Vc+bcHLZl430XV1 04rLWnuPdTtJ8jtWj0duHRZZW295ybAJouYyl7Q3cfbXWxgIlx1E/FIgLnYS SSTVKWT1v+d6V/4dZ/57tWssnrf870r/AMOs/wDPdqQU6ySSSSlJJJJKUkkk kp//0PSUkkklPPdc+p2D1nIbk2X3VWyN0O3NLe4a187fl9ypVfUvoPSszDyT fkGz1mNpa4sLTZq5odtrGntXXLM6xVZZb001sLgzLY5+0E7Whr/cY4CNqbJ6 fiHJGVtPrAlwcHuGpAadJjgKpm09IpJGUxxLWW3TLyS10NtMg66RI8Fqqn1L GffQH0gHIpPqUzwSBBYfJ7ZaUlMsBuIzGazDEUNna0TpOvf4qy5rXNLXAFrh BB1BBXO9HyW4uR9nBP2axofjl3PpkwGnzrd7SujSkKPmgOCWXdMzGMYC9pEY /wDwtTfcccn/AElepr8RI8Srd2R+0v1XCfNJaHZNwJHtcJbU0jUOd38B5kJd Zcy2j7EI9e33tfx6IYZ9ckcbDx4nTxQXdR9PFdXjNZVk3kux6yWtfYCfdbs9 o3HUgHkpJQ4mJc+91JhtgAGW+uC2qsasxqzA1I+l4D4rQd0nHP0XOb8wQp9N dh/ZhXiuJ2H9KHyLA86uNodruJ11VxHiI20RTlO6OfzbR8x/tQndJyRwWu+B /vC2kxMao8clcIeS6j0wXPazILmOYHD2kah42nxVR/Q8NxO0vaC1rIBnRha4 cg92rYz8lllrrT7GNEEu00HcrD6vn51FFQwaSbsl23HBaS98cvZXzA8T+Klv TVZXZt49NWG59VW+2257rRU0bnncZMBvYeJVp3TcfqmBcbwXY7dwsbtc1+6v UtAdt1BCX1d6R1anB2ZrzTbc42ZDmOm586BrrPzAB2bJ8wuiroqoobTW0Nra IDfLvyo5ZD0XCLxDPql0p9Qu+xZba3AODjtdodZiq6x33BWKMDE6bg5FmA3e xoc5+0l53AfRcDq0+RC6Xo17H4TMcEmzFaKbJBGrJZ35+is3617mMwvsn6LP ycmumu9mjw0yXajkeSQmQdgkhxem4OT0rF6dlNsFQvocbWms2yXu3lpY33Rt I1CjmdUwumXuvww7Gsvx3VMftcyv1Sfpta/eWgdtP711FzMbK6lYy6wN+y1N Yz3AHfaS52n9VrVWyOli2olmzKx3jtDgR8NQUwQiZWT4sRxevi6XxfVy+m5r rcDK6n1PVmK1jacuhzRe9wHvG9haHCeA75otc9VFl2M77aGbRcx7Q21piRof 0LnDxYWwszJ+rdbHOf0+12JYfpV/Srd3hzHf6+Sq25mdg9Ov6ZnYoppyHh1u fjNNkxH0mFzfDxA8k8xIZLeko6pmYpcxry/02lzse4PJAH8pw9VnxdvB7LWx +tYlkNunHeTA9QjYT/JsEtPwmfJctg9QaOhPsstr6vkm5oopG8mlhhoIAaHs jX+9X8OyqrHf1JprZjbjRsy3DZcJgGu+Jc09i9pPnCaQl6HPybsXGN2Pjuyr AQBS0wTJ5mDwsjL6i7JtoNnTczbiWC8OYzUvbLIgt9zYd5FXWNo/Zrm102Yr N4BqEOAO5v0dri3Z4wYiVXrxnXMx7asrJj1A0b9HNDQ76TT4oUlKeuu3urHT 8kvb22dp27uZ2+aZvXLi6D03JDRo52wzP8kbdR5/gqmNvuLa3XZjX3auLhAE As9/hMfkWCz62ZlNwc/p+XaKXSxr7DGjXM/0Xmlwqt7nDyjlVGx1NlBBjZaN ruA6e/irCwfq39Y7utVk24VmOWifViaXf1XGNfJbyClJJJJKf//R9JSSSSU5 dnWvRgX4trNztrDpBBfsGpI1Pgm/bbZ/oeRBIDYZqdJ18FR679UKOs5Lcl2X dU4ESydzI77Gu+iVVx/qX0rpuZi5Ls68vba30mPLYe8e4N0b5I6Kd1nVS8kN xLwQ0u9zABoC6OT4QhjrFg9tuDe1+hIa3cADt/O08VXt6n0XByrK8nqRZZtL HU2nQAkmYLfPlSOJ0w4zMyvKeaRWylttT5BG72wWjmXJaKanUMd0suprc03T kY1btHCzbN1B/wCMb7h/KC0cfq1RwGXD9La6G1Vj6VjnD2gfx8OUO7L6fkYR xxc5rqqhfVe9rpHpGBZJGpDhr4qjXhsY0ZTSKjktLrmuc0/Zw+HWMrb/AC3S nDUUUdWT95cXPcbnPeBcG6faLdDXRXPFdfjxEk6rWx+nViixuW1t9t8HIJHt MfRa0Hhrfzfv5Q+m47HH7W4NBEsx6m/Rqrnj+s/lx+S0k09kuLk9MvocLsdz 7QwQxzSPtFY8Gvdpa3+S/wC9ExesACMwgMB2/amghgP7tzHe6p39bTzWlbdV S3dY4NH4rDz8/GORXcysiwaF7RL3s7tLQRub8UQCeiHXys2nGYXE7nRLWjus fJys97nWucxoqYy0DcWtAfxrH3qlZbXcYaLKa9fY2sDQTDQ4v0GiJdbkOw3N ryTW9gZ7xQ1z3AH2gAv/ADedVJHhHn4rZcR2T0Yt+dkes/b6kBwtsbDW9t1O O7Vx/lv+QWj9ktxLG2YtAybXgi/ItfFmnAkjjyEALk8DptmJ1H9pu6hk25O2 SX1j3Tyx36Qz8F0Deq35mS3HDzi472t3Xhvv3Pc5ra/cXBm7YYP5Coza50H5 OfW1rzjMDRu9WbQA2D7YJb3UcXqT8qzYxlRbrvdXeywt8Pa0LnqcKnPtz8q8 usxcBvp10vcSLLGt37rNZdEqsMGyzLxsWkU13WOca8iqv0ba9jS7dNRDSOBq Eyz0AbHt441Gc5CRAJqNiN7W9HjvpwMzI+02NprsLnsdYQ1sOcX/AEj3LnuV DqOXTlfWDA9BzL68Ot13tcHN9S1wpYJHhqVPo1uR1mp1+Q80W1htTnVbfcWF wM72uVajKyHOynNcLG15Dq8V5Yxu4sippd6YZu/SvThrr4MM4mMjE7xJB+ia 7H6a+sdSzbbGnMscGsqaX7/pir2tY50hngrfT+odMwMVmLV9qexkkOfjXknc S48VDxVXL6XXhZ3TLx6InJAJZS2t383YdXNPGngtj9sdI/7nY/8A26z/AMkk UNS7qvSrxFlV5Pj9lvB+/wBNZ19+GJNIyHj912NeD/57XRUii6ttrS2xr/cH gyCCeQQpmmqD7QiJEIIBfP8AK6b0+5/r0U5WJkjVttNFzdfgGKvkZfXX1V4W bRkdQxa3B1VtdVtVrS36JMsh0ef3r0N2diVvFVlzWWQJDjHLS7v5NKI3KxnO a1tzC530WhwJPPGv8komV9FU899Xs3p/Tel14oZmBwJc8W41u7c4yfoMcPxV 3I+sVDHUiii+wPsDbice8bGQZf8AzeusLS+3YW4M+0VbnGGt3tkmY0E+Kh+0 cLc5nrCWP9J3OjySNvx0Tfolr/t7A/dyP/Ya/wD9Jpv29gfu5H/sLf8A+k0e vqnT7GB7L2wYgEw6Cds7TrEqZ6hgteys5Fe6wSz3DXjv5zokpqjrvTwIDMgA cAYt/wD6TT/t7A/dyP8A2Gv/APSatHOw9rnC9jgxhsdtcHEMHLobJhQPU+ni k3HIYGASZMO7/mnWdOEvopDX1zp1l9WPusrsuO2oW1WVBzomA6xjRK0Vzf1l e1+X0F7CHNdnMIcDIIhdIkp//9L0lJJJJSlk9b/nel/+Ha/+osWssnrf870v /wAO1/8AUWJBSbqvROm9Xq9PNpDiPoWDR7f6rlxGZ9W+udDNjulZIysN385j kiSB+9WTB+LdV6OsXKwOoW2QyqrY1zy1wucxzg47vcBU7j4ogqcjo9Luo4bO pZWPXilrWtrorcf0oY6dzmOPAE7R81PI6h0cB7K8nHc59j7Cx+jXVlu30nOj Sfw5V13SupODgK62B236OQ4fR8P0Hfumr6R1Jj2v2MdtIO12S8g88/oPNPEq BC0xsgufi9e6ZjNIZ1NjWk+0PD94Hg+GuBI4kcqzX9a+lte1z+qVuYDLmhj5 I/7bRsn6rUdWzDl9XqazaxrKq8ex0aFxcXexniFcxPqt0DEINWDWXD86ybD/ ANOUDJNONZ1LF6m4jp92Vc5xMvpxnPgeAdaWtHzUqfq0+x4fZTda6ZBzrGGs H941UfTI8CV1jWtaA1oDWjgAQFJAyKqeRzPq1VSzbkenkjIcC13pMqbXc0zW wenEMs+ideYW3hdO6Lfi12VYNDWkRsNTJaRo5p05B0Rs/I6ean4uVa0GwR6b TNnxa1sukLOw8nKw63ZFtRNVv88HuZSRY07RbFrmQLWwY8UtSFOl+yOlf9wq P+2mf3Kl1LDwMOk201V1F3sdjsaGjIaf8HtYJLv3SOD5JreuPc2KvRrLtA42 tud/Zqp3Fx8pSxum5N7/AF8hz6twgvcQch48NzfbU3+Sz70NeqXLuozOnfaf srPtOHksq9Wtpm6t7GsDnPZz7o1hZDLLn9R3YLL8fNtb6eK6NjNxJda6z1Gk RAHZCycPqlvUcnHbj3MFdljqK66v8DMVkPaJEnWZUsaz61YzqaGOy35EMeaL WOezbMWEl/I1Q4T0LN7sTRnj4pRAF2QDW3EE+D1LrnQukPyfs9WThu5yGv2v Y94kbm6zq7wUuifWDoNdPT8a8ux76SXZVtrdHOG58SJ/wjp1V2/GwsnqzPq7 bSXARk2uxXurqaRqPUpeXNE6ceKP1jp/Ruo5thvrrsJaKmkO9CwPYXbjW9zd lh1jnsnaMJJJJJsne271fLxcpvT341zLmfaPpVuDh/M2+C8iPJXZ1fVx/SOp 0ZtLnWUMcd1N0UvgtLdLHH0nc9nKuOgYLtW9J6qQeCPTI/6lHZDH6qdTor65 iEPvc6ytuMKiRsDiAyZ3fR0nhennfHA+/wD2LzrB6Xj4OZTmVdH6obKHB7A4 MiR4w1dP/wA5s7/yizv8wIFQT59dLslzLsB97YYfVr37iYLeWgCAHH875Rqq +O2mmxtjOk5DDWQKhJMBoOuroA/SO+Kf/nNnf+UWd/mBL/nNnf8AlFnf5gQ1 SsyrCqh7ek5IJh8w4mWkgTrPcol1dDb7t3TbXh1gePT3+5xBJe7hv50cnz7K H/ObO/8AKLO/zAh2fWzJqLBZ0XNYbHBlYLQNziCdo89EtVJaKMV8MPSrquQ0 umBs3ObJnvKBW2t+Ltd0e8P2+6t2/ZEtGm48w0I3/ObO/wDKLO/zAl/zmzv/ ACizv8wJaqXdS2jDF2P0txDmmu2guIt2P2h0N1n2+aExjLrN13R7GW2t9MmX bBLPTg9mthxEon/ObO/8os7/ADAl/wA5s7/yizv8wJaqQ/WCsVXfV2oN2hmZ U3aCXAQOATzC6dcfnZnUer9Q6UB0nKxmY2Uy2yy1ntDeDwuwSKn/0/SUkkkl KWT1v+d6X/4dr/6ixayyet/zvS//AA7X/wBRYkFOskkkkpSSSSSlJJIGVlMx aw9wLi47WNHc8xroOElL5OTVi1Gyw+TWjlx7NA8SsfJ6lbmMZXVW703zFVbv 0l5HLWO021j85/fgKva+3qF7XFpsFo/Q0To8fnHcB7aR3dy/gac7eFgtxgXv PqZDwBZbEaDhjB+axvYI7Kcvp1FGRbbWHupqeBbTTQBSHVnT3uYBYXNcC13u RuodIx66i/Go9jgWZNbBL3t+k2wT9J9btRPmqlpvxuoPAaBaLDbQ0aAudJfX 8LmD/PC6Ci+vIpZfUZrsAc0+RSKnJq6mxuLteWV3QHV3VgbLWAgOezQwQPpN IkKs/rVkN2ZAJLZfJGjtdB+rq71HAqLi6mN9h3vxt20vc3/CVH8ywePfgp8D qZllGU6S4llOQRt3uHNdjfzLR3Hft4I/RTQ/bV3pBxyWi0zLZ0Hhr6CuM6zX T07Mz77PUpxoIcQASdjTsENbPvMDRWuqdOPUKG1NuNJaXe4Ddo+t9LhEjtYY 81ymdgtf1h3SDe67DFv27qGnEn9FRoTJM/d8EtCpudAxsnHwbOpXf8rdafNc /mNdJb8mtl33BdPVi0V4zcYNDqmt27Xaz8Z5lVcKMq9+dEVNBpxB/JB97/7T hHwA8VoIFT5rnfWLJp6rkYmCW4dVdr6xtaSwtZPLX2enJI/dCr/86+oUZVTG sqGrfWdjB1cydYAeayY7lq9N+z0escj0meuW7DbtG7bM7d3MJHHxzc281MNz QWttLRuDTyA7mErU4D7smi31Te+h7jLhkN9MHQDW0Cyk8doVxnVcqracmoGp 3+F4aBp7t7C+uP7S1yARB4VN3SsPcX0tONYdS+hxrk+Lmt9rv7QKVqS4mZXl tLqwREc8GfBwkFWFj2dLyq3myp1dxPLjOPcfjbj6O+bFH7dm4v8AP72Ac/aG bm/9v40ho/rtSrsp2lldb/nelf8Ah1n/AJ7tRqeqV2MD3Vk1/wCmpIvrPwdV LvvaFU6rkUX2dLdRY2wDOYCWkGD6dvMJKdpJJJBSkkkklKSSSSU//9T0lJJJ JSlk9b/nel/+Ha/+osWssnrf870v/wAO1/8AUWJBTrJJJJKUkkkkpZzmtaXO IDQJJOgACw8vKs6hY2ilm+p/uqpdIFo/013dtI7Dl/wW4h041NLrH1th9rt9 jiSS4/E+HYdkQpFh4TMVriXGy+yDdc7lxH5GjsOytJJIKc7rGB9rx99el9Xu Y4aO010PkdR5rKx+qZNFLvSYP05cS0/4K4Dda0N8Hj9I35rplj9YxQ1wyWnY x+1l7x+Y5pmm/wDsO0PkfJEHupwX3XWWeq95NkzunX5KbSXue+pjXPt0ycY/ QvHM6cPHYjXw8EbKxiavtTGbBuLMiof4K0aOH9U8jyVNT6SCnWp6+3BwrLsg vuxa2n07SP0rHgSKMgDhx4a/g/Hmh0vFyXN9O2Rn59huy3xq1xEkCf8AQsdA 8HkKdWblZGXSBtDcZjhe/bPq+p7aaX+W6XfJbfRqXOYc2xxebRtoc6Z9IEkO 1k/pHEu+EeCiIq1OjXWyqttdYDWMAa1o4AGgCmkkmKUkkkkpSo53WOmdPsZV m5LKH2AlgeYkDSVeWN9ZM/Ew8OMrCdmts0Y01h1QeTtaLHO0bJPKQUmP1g6S b8fGpyWZF2S7bWygizjUudtOgHmrH7V6buex2VU11btrw5wbDgdse6O4XG9K 6NkfV36wdPtv2lvUW2VWBg9lVh94rb5aAD5rpR0oGy0Ow6WMsb/OVEteXtfv rmdOw18USFJLm9Cvuk2VDJM/pKbNlvtDnH3VODuGlZ768C7Jw8r9qMeyiwXN FzGG0hoc3Z6g2OA1/OBlWKemZtTZbTjtcXVzDQPaGPZZoBEw6B2+WihkYGZX 03JdVgYtuboaaQDsfLhu37nCTpzKWvdTp/tbpmz1PtdW0CT7xMf1eVOvqGDb YKq8hj7HGGta4EmBuMR5Lhsln1v9Peeh4rHN+jZWxtjxuPugG1/0p10XU9Cw rW47Ls3p9GFlt4bQZGoiSBoDr4lKlOykkkgpSSSSSn//1fSUkkklKWT1v+d6 X/4dr/6ixayyet/zvS//AA7X/wBRYkFOskkkkpSSSSSlJJJJKUkkkkpSjZWy xjq7AHMeC1zTwQdCFJJJTgUn7FlPoyPdUdtN5d+dW720XnzH82/5FUOrYJ6e 8v1dQdWEan+r8VvdWxfVqGQxnqPpDg+v/SVOEWV/MajzAVCh1mU6kZRJwent +0HJd9G/SaHT/Jbq7+UnxlWqkVPSmspxsF4nLyS67McD9CswHj7orHzK6MAN AAEAaABUum1ve2zOuBbdlEODTyyofzTPuMnzJV5NJtSklEPaXFgcC4QS2dQD 5KSClJJJJKUoWVV3MNdrGvYYlrgCDBngqaSSmLmMcWlzQS0y0kTB4kKSSSSl LO6tkXU2dOFTy0W5bK7APzmllhLT9y0Vk9b/AJ3pX/h1n/nu1IKdZJJJJSkk kklKSSSSU//W9JWN1Y5FnVOn4leTZj1XMvdYaiASWBm3kHxWysfP/wDFB0v/ AIrK/JWl38lIbsS+pod9rz3gvLDscwkAfnRs4QfsAzK/Wdk55GOW3U73MBL4 MFkMXQJJnEU0HCtx76rHMOT1FwABD2FjgZH9QcKAba4tIv6nscCd3s8jxtXQ JJcRVTi/Y8j095y8+fT9TbvZPP0focoPp3boN/U48fZ5fyF0CSXEVU4LKch9 jWfaOpN3O27nOrga8mGcK7+ybf8AyyzP89n/AKTWiklxFVOd+ybf/LLM/wA9 n/pNL9k2/wDllmf57P8A0mtFJLiPdVBzv2Tb/wCWWZ/ns/8ASazH5OEx7mO6 tmBzfpAvYIj+wujJDQXOMAaklcjksyurusPRaWsx6jH2izT1XTBDNwOgSBke v2p06twX4hiOqZusx769YifzPNWa+g024grbnZf2a0b/AEy9sHcd/GzxPCPg 9Fqpxq2ZW27IGr7GtDBMzoB4LRYxtbG1sENaA1o8hohxS7/YoiPRwc5vUOm5 nTzi5GRmuutex2NbYwNeBU930tgiIlZnXcU02Ms6XnZNfV8t/wDQKrvUaHnW zdr7Q3x4W/1T/lPo3/hiz/zxarNfR8KrqZ6nSwV3vrNdgYAA/c4O3O0+lpyp InTVaXl/q2wXdLzjl5FlHUHZXp5mRM2SzVgk8CVqtZa0Y+zqdzmXt21lrZ9z dz3F0uhvtgD+6Vr43TcbFy8rLqBFmYWuuE+2WCJA8+6tQESp56htObVXjV5t 7chz/WZc9p3AivYQZJaJI3QqfV+o09JyG42X1fIZY8eoSK9x2mQNsacrrYCD fhYeQ4PyMeu1wEB1jGuMeEuCGini8b6x9Lsy/Rb1bJabQ0es+v2F0bYiZB78 Ltsar0ceqncX+mxrd55dAiT8UCrpXTKb/tFWJVXdEB7WNBA8oGiuJadFNPNy c+lzBiYX2oEHefVbXtPb6Q1VX9odc/8AKj/2Zr/uWskj9FOT+0Ouf+VH/szX /cgX/tjOycEW9PGPVj5DbrLPXY/RrXtja0D95bqSV+ClJJJIKUkkkkpSSSSS n//X9JWPn/8Aig6X/wAVlfkrWwsfP/8AFB0v/isr8laXQ+RU3XZ2Gxxa65oc 0wRPBCj+0cH/AE7PvXO9TqtdkPIDLG+pYNpGrAHSJ/SNmfgqDMWARXVU7hxA 11jg/puVDbLwvbVX03gupeHgaEtMoizOiscyqxpcHwWgFoIEbeNXO/KtNEah YRRpSSjbYyqt9r9GMBc4gToNVmn6xdKDS42uABI+g7tHl5ogE7KdRJZb/rH0 qud1jtDH82866Hw80SvrnTrLW1MsO5xa0SxwEu4EkQlR7IdBJJZPWupW1Gvp +D7uoZOjB/o297HfwSAspRfWDqLfRd0vEPqZ2TFfps1LWu+kXRxotXDxmYmL VjV/RqaGg+Mcn5qt0vpON02qGDfe8fpr3auee+p7Sr6JIqghSSSSaly+qf8A KfRv/DFn/ni1bCx+qf8AKfRv/DFn/ni1bCkjsFpUkkkipSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSn//Q9JWPn/8Aig6X/wAVlfkrWwsfP/8AFB0v /isr8laXQ+RU6ZAcC08HQrlG9I6j0DIdkdMPr1P0dTYDBaT7G7gfpN4kwusS UYNJcXE+s+DY70s0HBvH0m3aM05h/EfGFpVZ+DdApyarCeNr2n8hQ8rpWFky bKmlx7locBrM7XS3nyWD1Xo3Tj1bpmKKA0X+p9o2Es3tY0HXYR+CdUT3CtXo 78urHLA8PcHzDmNLwI112yhjqFDyWBtocTtE1P7+e2Fnn6p9JaAKPVx41HpW HT/O3Kn1LoubhYz78LqWW9w5rssLt06Q3aWQgBE9Vatr6vMGEw49uTdkW3u3 s9at7CAGyRLi4fitpltTyQx4cWkggGYI5C5npnSendTxKbrM7Juuczc6p94c 5juHRLd0TxKNf0HqeMPVwc51/pHeyjJAeXFuoHqfw0S4Y7XS6c5TkZy1Mt60 /B6Nc+yz7N9askPaHfaqq3MeSAWtEMMT4kcK30zr1GdWzcx1dpIrtBiG2R9H mfhoqf1gaaOp9NzAAZL6HSA7Vw9mhjuUo7kfRBehSUKbBbSywAje0GCIOvkp pqlJJJJKcvqn/KfRv/DFn/ni1bCx+qf8p9G/8MWf+eLVsKSOwWlSSSSKlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKf//R9JWPn/8Aig6X/wAVlfkr WwsfP/8AFB0v/isr8laXQ+RU6iSSSiXKXOl9t31qxg8y2mu17BEQDLPALolz nT2vd9Z7TZu3MxjO6AQTZOsFw4PinR6+SHo1WzMitjHVe42OaYDAJE6B0u0H zTdQLxjy15Z72gxpILg2J579lz3VLMx1j8fHbebG0l9VjHtGu5rYlzXHTnVR mVGup77L4xsX0bmBXZjuZc2rYWmwmp7h/hSHmC3cBB04Vt1mRY82Gx1ZOgYx 0tDfmIJ84WP0jIfXhvZl5TbsgWmbfUad7XEbXM1hsjgeKvZBvNuLXgX1WC9r 7A+ww0MYGOG7bu1Id5JlZZXRGhZLgKsbhne1teO4MAaHEBxOv0iA5xnnmdVR zuidXfjsbiZdeRj1PFtFO0MLS2Y2PG6fmVbxb77LcijI9MupLAH0kuY4PaH/ AJ3xR978Z/rVCRxbWB9IEjXTuEMczCRjIak7qnHiFjp0YYn1iryHBrqXVmsE ZdZk2VOHfZElnn94Wyx7bGh7Dua4SCO4WX1HpVHUg3LxbPRzGfzWSznTTa8d ws3C6jlYlxw7mCjMDtzsd381c3WTjnhrjzHCs0Dsweb06SHRcy+llzJ2vEjc CD9xRExLl9U/5T6N/wCGLP8AzxathY/VP+U+jf8Ahiz/AM8WrYUkdgtKkkkk VKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU//S9JWPn/8Aig6X/wAV lfkrWwsfP/8AFB0v/isr8laXQ+RU6iSpZGVmb3VYmKXuGnq2ENrn/qihjAzM lzX9QvlrTIoplrJ/lO+kU0Q0uREfxP2K4ugBP4B0VidO9/1j6tZ+42msfNs/ wWvfdXj0WX2GK6ml7j5ASsf6rj1qMnqDzN+ZaX2AfmgfQb9xQGxP0T2b/Ua3 H07gGuZVJcHENiYhwLtFWreLGB4BAPYiCj51lj7Ps7SAwBj3Egkk7pEa/wAl V77PSpstifTa50eMCVVzUZADdsY74ddmgcHo+J7fTa18bxW0uLyGHfLWglxg jss+jFwct9rui2hhYx1V3qMe5vv/ADRucwgt2qnZ9Yqco05D8Yttl1TSLnND Q+sOLva3nWJS6d1jFwLLAzGNbSa67LHWaODbHUm0+wa9yVII5BEn1cXa9EcU bFVQ8NXe6V0+7Cbc6+1ttl797ixmwDSPoyfwWguey/rW3HseGY/q1McR6jX6 Foaxwd9HvvW7j2+tRVdG31GNfHhuEqGcZj1SFcTIJAk0bPVJgB5zbdji2pgG 9g4c92v5ETrfT687p9zPS9S9jHOxyNHB4Ht2lVhjsFjrNdztZBiDES2OFJmX k4m+y55vY52jPzh2aGwDqpseSOg1sUxTgdSt0fq1V2CKHucc7Gri6m2W2FzR qdeZWtU5z62Pc3a5wBLZmCe0rnOoFr/rDuaGA1YZcTZoCXuLPdx2cukYNrGt gCABA0HyU0h17sLmdU/5T6N/4Ys/88WrYWP1T/lPo3/hiz/zxathOjsEFSSS SKlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKf/0/SVjdRcGdd6Y5xh rasok+QFa2VhdYtZV1npz7G7mirJBaI1n0mxr8Uu/kpt4XVsbNsNVbXsft3N D2xubxIVq+5lFFl7/oVtL3fBolcO7qvVG2+oL6vVdq4PcdjNWltdbWuEAADX uhZWR1jLqNLrKfdIhheCd0e3V8ax3TSIE6HhHnaQJVrqXRGRb1Zot6tkvpxn gObh47HAEcjc+Nf9eFGnqNWDiZ3TMbI+z5TbQMZ72kCJDf3T2C1+kdZxCyrp 99Zw8qprWNpt0DgBA2O7yo5+KzKzxf1Asx8LG0b6jmg2Hn7lJEgiUJemJF/Z tS0kxlCcQJSidjt9Wp0vPszMarKyXucax6Xr7SGWEakn2jx7ps3qr2VMdjs3 mx/pVsMF1jpiAAePNalnX+hYtBLMuktrb7aq3NJMfmtaFhYedjZmd+08zIrp dBFFOpFVZMHgfTd9/wCEQe1EyMiDXQFlOWVdASb9OjrUsyrGA/ZWkM/nNpGr u/pzEqYEEMvqFdjtWtMGRzofyqTvrH0LHqhmQCGwAxjXdz2EAKvkfWTpdrNj 6Mi1vILGTB8QQ6U04ARoCEjKQddWF14pxTmWuaGMcQ6hjC5wAO07iJgCOYTY vVsbIrqewO2XFwoIBO/YdrtvwWdk2YWW4/ZMLPN7mGpjY9NpDnBztztTrGsp snovWsXp5yg+qtmLY7LqxKx/NEnc4NdtOneE44IEC9Cj3ZA93Yvy3VhmxhJc dpnTaRzuHPCjkerk1bqK3FlZ9Q2kQPbr7e6rMs67dj1dSNGFcS0Wi0bmuAj4 9lW+1X9Qn9o51teMdHVYlZbXH8p51+8FKHLa2NeHsqWfoaFs6MjqD8p/Useo XvuaKi8Elm1saD2eIVt/V+qstZU5rGvfMNMhxjs1u3VSb0HIw8ff0nqN7Kw0 vZU4C1rp90NB2jX4Kk36qZeTmPzsvId9pdtPqsArJkQ4e2Y0jsncI6yRxeCd mffmdU6YLSC6rIe14aNGv9G8Fs/ALq1y7Ols6Xl9JoY7cH5ltk6zrj2DWfgu oThtpqtO6kkkkUKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU//1PSV i9TrZb1zpldglpqyZHHHpHstpY+f/wCKDpf/ABWV+StLofIqbX7Mwv8ARn/P d/5JL9mYX+jP+e7/AMkrSr5ebVibTYCd0nSNIIHcjxUWi+z3LV63g4uT02/1 amudTU91Lu7S1pIg/JZP1f6LgZWKzKzGHJuc1p32l55Go1hpQOu9Wzsx7aOn 2tpxoLbgdHucdNp59uvC3Og4zsbDFRduDAGSdDI50kiNdE4Go1eqKPUKPQOn F5cKmBszs9OsiIAjVnlKTfq90xrtwpbwRt2MjVxd+75wtNJDiPdDVx+m4OOG 7KWF7SSLCxm6ZnlrQot6XjMbta+2AQR+lfpHhqriSVlLUPTaCQS63c0EB3qP mCQeZ8keuhrKPQcXWNggmw7iQfFESSsqeWw56V1C7pdp/QuBdjPcYHoukubq Y9p1+9b9WJs6cMRpbPpbNw4kiJXN9fyG9TrZW2nZfWZrtO5w2ke5ror7hExs 21uJjdPD7mvqGz1wTJbqIdNcaDhO4ga1rWz9OqDE71ejp+l1OzEZg1ObWWVh lmUCTq0xtZGvA1V27KbhV47byXvscyncBy4j6RRsehmPSymv6LBAnk+Z+KBm 9OqzLKH2Pc00PD2hpEEyDr9ydxRlKpaRsnQareEgaayoDVrdU/5T6N/4Ys/8 8WrYWP1T/lPo3/hiz/zxathCOwXFSSSSKFJJJJKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKf/V9JWT1TF6g7Pws3BrrtOO25r2W2Gv+c2QQQx/7q1kklOR 6/1i/wC4GN/7Eu/9IIV7OuZG31enYztsx+tWDn+rSPBbiSFDsqy879j6r/5W 4/8A7GW/+klYqPXqW7K+n4wbM/0p51PmaFtJJcMewTZ7uR6/1i/7g43/ALEu /wDSCXr/AFi/7g43/sS7/wBILXSSodkOR6/1i/7g43/sS7/0gl6/1i/7g43/ ALEu/wDSC10kqHZTkev9Yv8AuBjf+xLv/SCXr/WL/uBjf+xLv/SC10kqHZTh ej1f/wAqcL/t4/8AvOkKurgyOk4QI1B9Y/8AvOt1JKh2TZ7uR6/1i/7g43/s S7/0gl6/1i/7g43/ALEu/wDSC10kqHZDhnH61ldQwbsrHoopxbH2OLLnWOO6 t9cAGpn73itxJJFSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS U//W9JSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJT//1/SUkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSUpJJJJSkkkklKSSSSU//9D0lJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklP//ZDWVuZHN0cmVhbQ1lbmRvYmoNNzkgMCBvYmoNPDwgDS9UeXBlIC9Q YWdlIA0vUGFyZW50IDIzNyAwIFIgDS9SZXNvdXJjZXMgODAgMCBSIA0vQ29u dGVudHMgODEgMCBSIA0vUm90YXRlIC05MCANL01lZGlhQm94IFsgMCAwIDg0 MiAxMTkxIF0gDS9Dcm9wQm94IFsgMjA4LjA2MzAyIDMxMC42NzcxNSA4MDMu NDQ4ODIgMTE1Mi40NDg4MiBdIA0+PiANZW5kb2JqDTgwIDAgb2JqDTw8IA0v UHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YxIDI2MyAwIFIg L0Y1IDE2NyAwIFIgL0Y2IDE2NCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dT MSA5OCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTYzIDAgUiAvQ3M5 IDE2MSAwIFIgPj4gDT4+IA1lbmRvYmoNODEgMCBvYmoNWyANODMgMCBSIDg1 IDAgUiA4NyAwIFIgODkgMCBSIDkxIDAgUiA5MyAwIFIgOTUgMCBSIDk3IDAg UiANXQ1lbmRvYmoNODIgMCBvYmoNODA4IA1lbmRvYmoNODMgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA4MiAwIFIgPj4gDXN0cmVh bQ0KSImElk1rGzEQhn+B/oOObcGyPkfStaYtFHqyoYfSU5qEBDuh9SF/v7Pr 1TvSYhxC7M2zM4+k0Vf+KqeftPKWTPZRO5eCTjUbn0lvSgymVP3vXpUQ+F3x +qR+6hdl+Y/qdIleb+YnDpn4dndO+u6srSn4Pd+p7be9049nFSibwpJUg0k5 8bdJvrAikLEU5obs0omTevikYuSepJsJHMWtZKf7T24zEZlgs44pm+Q8Umvh iLxkfj6o7deknT488Jg2RXOX58aqK6RjCMbHmvXhxG+nH/ZurLHWcsYdt2t9 5Kc39WF3fD0/vTzq/f35/PT68vHwrL4c1KoMrUvZV0OhXBvNpe2qQ/Fc+Xyp QitboWQyN329Cq1WjntnMkWE+eyN83SrWK2FMTdfKXRIuv/kXPJpfnTO8mpx TnKtNza2UqdIJtK7YRjFEFbWYejwbdvVwVJMhngJrBeVD2le9kt/l8l6d+n1 M9zUN2b4vV5Nk1ziPAOU0iU1seqSOm+w3V5fluN+x+vyOz88s4f0G8+f/qF/ /bb6j/JcyGwrVyjkuTTJJR7QtKudN5VbYGMO0VRagoqf1ltDwUfjS9BHlTlx Wj990IK6IMvFs2nuPs/yCSCkYnytHLLe/SeQaY9GR52mb0vQJa+PsmWuax+1 LIijosIDJt+7OtRcguDqEFw8rDSqQGBqREQg8Cyz3IsEwQQkKkFwYeOJSxBc sj3hWu9YjuLy1ToOUBBcQOIS1FypkHFDt4Q0EwhEQuBZdmAvEgQTkKgEwYXT R1yC4JIzCq71scVRngz5oVYdggtIXILgmu7dMqhAYGpERCDNE7l6NQy16lAz CYKqQ3DxrrR1qFWH4AISlyC4cJyLSxBccujDtb4HOMpPp8SgAoGpERGBwGP5 QKSxVoJgAhKVoOYKhU9ZP9SqQ80lCK4OwYU7TVyC4JKbD671ZchRkV+G4WDv EFxA4hIEly/G1aFeHYILSFyC4OKXIcXBJQguIHEJai5fyvyfXefqUHMJgqtD cFExNF6EHYILSFyCmmvPF3zgy3i+R9K0tyxVk+vlxqvGTeVt6PhfgAEAoCRK cw1lbmRzdHJlYW0NZW5kb2JqDTg0IDAgb2JqDTc3OSANZW5kb2JqDTg1IDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODQgMCBSID4+ IA1zdHJlYW0NCkiJ7JbLbhNBEEW/YP6hlzMIt/r9YAdC7FjZEgvEAogFQXFA SSzE31NtT90qWyhfgCIlzrnVZ7prpns8lZZtjtV4F7OttZvDFEu1oRRBd1N2 xdZmOiU1NapJiWpyAFlLqLjHaGsMumYlUtN6t9UXVcPkbtpOzmbz2/A1W/SW JrnOq7UAIr7aqy2lo8aDqJoSbclReZiMGmpCribnTn/ZkwvAKEm2BJMDVaaz pVlHM2ZyvlLq0aTubQ51rQkpgZxXV8bqqs/Wh2JippI+LgkSkg1tCCtNK7is a0CSdanqmtDoPmZdA8+4x5EmLx4h7AGBRwg8hZZ6oWEAywpEwgCOlG2pVUtA YGEiGhB4qO0t6t4IgYeJeEDgoW71frEoEHiYiAeEPbkV6/V0ANjCABIAOEqx 0eneCIGFiWhA4En0IJaLyYDAw0Q8IPCEQs+87o0QeJiIBwSe805WGgawrEAk DNiRqFk96t4IYQsINELgoY3tuu6NEHiYiAcEnvXgUh4QeJiIBwSeUG3yWsMA lhWIhAEcbhxWF70BgYWJaEDYExsd5kH3Rgh7QOARAs96wCoPCDxMxAMCT6Ij NnbtAYGHiXhA4KHMd90fIfAwEQ8IPK5ZGqE9IPAwEQ8Ie0KjzOv+CGEPCDxC 4KHXy3jJKQ8IPEzEA8Ke7fRmNzmzoZetcaa6YKk6Ge9DtynTm3Z3oHj8PH6l D7vTr9/T7Por55bdjzE22NRcNLu3JxxPePdimr1ba9Z/VOJ14nUSdBJ0EnUS dZJ0knSSdZJ1UnRSdFJ1UnXSdNLWhBpAe5I25Vh/4On3wVw3dDPy6PjanP89 e6ZnG2paDCGZXMcTHEa6cdY5508PnnWU0cP3cd4tng6e+XZx82G/bOgbq7dx 3h7vbz7/WajlfX5JlM7KML8+fjs+PpnoQYJzcdmk7Ohr5/z+5z/GbPe/nvaH L/sHcz0q99ptoevXSAOO+8fnBofrwbTlbJs/LL7N+5v75wfH68GO1tjn3ffj w7Pj0tW42PzozbuH25vl018BBgBfxm8MDWVuZHN0cmVhbQ1lbmRvYmoNODYg MCBvYmoNOTEzIA1lbmRvYmoNODcgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0xlbmd0aCA4NiAwIFIgPj4gDXN0cmVhbQ0KSImUVl2P0zoQ/QX5 D35MEPW1PZ6x/cpeQCB0kdhIPKx4WCqX7aUfqJvC5d8z0zZJu80NRNVWG3cy 5/j4zHjqt0Uk7UNQRtV/F3fl/c8KvU7l82rmXNCuvM3fmrz+nHcKuzVnDFSf 6rfFy7qwSj6P84IM6pScstaAjpZXk44e1Mwap40PapeL4Jy2wSog0piiWheL Z8WLujBqFlVkDmRBB+J3TQBtYvCqXvOv8mGI8ma7WOSsPu/y/deq/lfwr2DX /ZIxlrN5tSpue55oSIfYx0PSFPGCZs8CnPYxXPNE57WnFISo04QuXhJ9t9/M Hy54XuG35DBpdIHxgbQhEPxD9nCET84NwIPXkExSCYGFDJPRI6EOxg6CH3Jb lViESEN7b8GjDZofJoMHx5JDHAMPIehoYAScomWNbJoKjokVCzgGTp5PxtsR cPSovYm/BUfPxUV4bs5uadCcnuuLkS9ryF2Ys2WJ7HIKAzXkAbnIIk4ooiv8 llyH36t0Sj9SHB2BxK2Eo2AyfmvPEXixp4eB2ujQxZ6J0vTdtxYZQRd/AqUR dLEItz/8c3RybKroj+KztfsGeo0vh+/8QH0QgHbIukhnCOKTyfgiPpt7CP6U /SC+hYHtd/AiPkkPnQwv6rvoxuBFfRNoBF7URzRuOrxHvuG4rbTwKXILPgdH w/cjjmB7F7XB9FtooxOAOv/mQOCXrdwrY9fTiQlEtisOnAKI9+LpcvLuqQlf 50Y12y+5eci7P+LSdoOOS38kPRSTsjjQNNuIFEhb6y8dcVe+qW+UjepjxYaJ Za5MuZpv11l9yHOePJbbTTtoDFJ0FDVxHbZXiuVjMzhMMSarYeDgwHGo96iC 1J19ItaJ34fldx6BXmzvG3X7sF8sVrlXjm12/i3K8ckE5y9vunjJ6oiqyLG2 Q6MQM9EAGBVJQaQr4eqKu3sq8/xhs5zfr9TL/+b73eOZYEcS2JFYdyttg1ud dzxppadHqQFEPFxNR0r8rOSPbR64NSMdBi7D/x316ujsq5nRtmy2uyVzsgcu f70irrF6IYlIkSQhw0VGYpskg9RhhOAXjZGSnXNg/aMo3/P5885EaP4tAgs6 s8yTB9VjrJXY8p/c/Njuvi43X5SEMrxlR7SRHMjvSbrlRrHjlbOPzTEOMdGT jD36XXmTN81+V81sLH+e9oHdPoYEMTzVBsDQb+ZAsGPwPyLxKP1LgAEARs+B Ew1lbmRzdHJlYW0NZW5kb2JqDTg4IDAgb2JqDTc1NiANZW5kb2JqDTg5IDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODggMCBSID4+ IA1zdHJlYW0NCkiJ5JbNUtswFIWfIO+gpbKwKsn67Y5CKTBDmyme6SLTheso oDaxGduB4e17FduJA04KLZsOi8xo7Kuf8+mc6yQXo3enCjGUzEcURQopRJFS MTFMacSoksQoo1GyHEWUUEo5SrL1kHF4ej+a4jOXjiNLLL57QMlYxzBK/aJ6 P/6eXIRKpqxCESMw8wT2WM+ZjJkmGrtyXpTLNM/cupgSTqnY1DYbsrAhjLgI U/FlMXOLCqX5bJz8hOeMxnJ3dXyV3bjZauHz66aESrktwSe+yvwtvHVVeP3u VG7UayJR+AEBLYmWigOBmBPNg/7NGaa4lbkaB3m4LkqfLpBcaxiiCboamlwR pZkJq+GjGTorsnCEcDRhtozwZ1ffF+WvnkrOehJ6F3EQJyPMCDaEE59X1eqQ fmkViU3QzygFEkw+hwDbQ0AaSoxQ8JhaQYTS9pGfmnv7clv7LF2skcCEmA9a oaMD14taC4DDthbYOMXnqL5xiLOqbuqk7BnxKcRjl9erchwxgx9aIYfRUKWI jqXaitn16h5K8V5KwEYo+XZT10P7z6nree6/SZ2wmjAdq5elju8hIIwkPBYh dIpQDaOh0LWq29DZsPtOlFiz88f53GceEoImfBK1vmHc2iGhU3zlQpB0sKfP XIO0gSOlegyndxoIrC/b2wE3bM8yxZdp3jr+2i3hIAciuuX4lxEVe5Ea6EsB qYJzccsHkX4tVnXXncKqupeDH4Dbubx9pSTMe4obn+e1K3NXd1YMqwg5aKpm y0lZ3PmZK6voKO+6ohF8CHRYvCxmq6z2RVdrBZMDHbQu0IdPk+f4dZvXHRsM wlV/hMstdI+m/eHkBlBWqC5aDrHu9Sp8XORV0I183uGODesVhC/Aiav8dY6K eatWKr1Lpm2qOEXffOkWrqo66JSaAS5XD1Xtlghi39ZRKR4HoeeHy9Wi9ks3 8+kBlBAWE5rqTvRfYNm9XYCGb0ls3mIb2DB97TZALfyLie2r9IHfAgwADEKv xA1lbmRzdHJlYW0NZW5kb2JqDTkwIDAgb2JqDTkxMiANZW5kb2JqDTkxIDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggOTAgMCBSID4+ IA1zdHJlYW0NCkiJrFbbbuM2EP0C/wMf5QezvIhD8jFNetmibt2Ni30I+iDY dKJWEQ1dsti/75CWZcW2bCPYhwAOPJyZc+bMHE9mjIJigsw4FWT5MGGUiZST 5ddJ8qlsXFW6hmTlerr8d4KhPFW8D8X/GWMYu5qw+GBR+bd87ap6dleS8AIf mFQcPRDhQUhe+XW7anK/j7UpV+/7iFkbT378ZRFCfvhZESy3wXIzTRUJf4yk XFPDJH7FpKAaX78OW3tKllMtqU3aaQCA6ao8KwhM/1n+hhmhzwgEQjZmaQrS YjZhKVNGh3zJ8iUvn2vS+I4IqVna95rc+7IOwEm+wxICDB8ENC+OPLg6fy6J 33RwFej31HChI+CMfMkrV7i63rPOmDlDzOO3unGvZOOrLo6p1J4jezedeVs0 +atb59kFLq2mXEsg1ipqmZAnZC6mIk2yKisKV0QKd2QcBveUPGLnONXpjKcp FQkfYxqQaYH8WmuCBs2hVux6QMlTMl/8/ki6QVbZZpOvYlbkRg5Ec6LIn8rn vHSuwuHdAho4NQbixD+CVIwiVdREpEpTYSEiTf6eLx9vaUqgvPWOnY80Jcea 0kAhNiWAKsHFEf393vitL/wzpmPJt31JxQHOst6Lc+7XrqjD6ejkbqQ4iDi5 W5Nf/arTbSr5QN/x+R+u+eqr/+obCDJWUqOU+ChB6TV9GptSa1J9QtBdJGW7 LfJVFj+GY9bpElL+rmSFASZ5w+PYlbuMSVkkzKrvsH7qmigNipLL9Hj9ks++ bW7bGyNCKqm/Q7ejZ7kfhsBhYO9xhT672rdV7fb3D5f33P3DSRWFDzOyqOd+ SFdQaYvXYHiVPgxKXwMVSkmBjhJAzV1Wt5Wb7dYGhJWHtXl1ZXOyE0D1afN4 yhTTEDM+uDdX+G03TOyWKT00rxa9OHd7t2FWigGWL1PUbVjFF7+9ICWJx5No hULgu1OS/Ll1ZV8Skw7scM/PqLQA7UdZY4gWkmoNML7cwAdOfGo+Y+4DgGdV oc+HCmgzPPb8V+ta1zUdDXVw5o6NtyafbgAAxlINLO4G23nZCIpLFjrmLAD4 tZJYBm+UAht5OjS6vF+QeIiLi4t8aBbnp8NPvKvNXqJ8zHFAc5oGykHhxQZz fFD3R39PfqrPWUyyKLJyICw2IA53p3nx6wuucYAqOP5WtBdc48pIxmyjFxZw Qy2X8hjlPY6jLbLwo+1/AQYAOgCtNA1lbmRzdHJlYW0NZW5kb2JqDTkyIDAg b2JqDTg3OSANZW5kb2JqDTkzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggOTIgMCBSID4+IA1zdHJlYW0NCkiJnFbLctNAEPwC/8Oe qPXBy+7s+5gKoQhFwJRd5JDiIJQNEchSSlbC4+uZlWT5AZJNDi7LLu1M90xP z05mnEnDBZkJBmT5aoK/Ocffy3RC34f6R1l9X0+X3yYvX2uC/95NOJlZpkn8 cGK8Zto7RxwoBlZKslxNMAIosvwxuaHzPBRJNZ0JR3+RRVivs7IgMP28fIsB TR/QEBODGYyhJQZThgnjbQzW4oGI54Yup1YyT6vk7i5Lyfl9UiVpHarsd4Ip OK1j9BdkKg2z9HoqLH6FL2QenwwN1V1ZrZIiDV3+UUJaeqYtyC0G0WLYo6SO UdFIBbgTMQy9zqqQYxHICYUVeA6c2cNxkFwPJNdOMeea5JqBs6ZJ/rFcYG0u 0rIoV1l6SmrMyqw1qulp188pKIpVz/OQN9mxNEZw1cvnhnZdRowKa0DFMErH VEQZ0wiwLcjH8Biy4mtEh6GFdroP3cuKLn6t67Bak8vLE1gY55k13B5noUdY mGMsjFdMKmX2BoAuz+fkoriPoptFrIIpq3YoNS+tQlGf0g+jNYunWyX8Pwd7 lIMGBkbCwdzRDw91liZ51xRlxbPtoqcCglnw8Gwu7pj2Dc48qE771+/O3g+j Ut4yYSXOmkPHENKMohrTuh9ApYxnCicRMwjGjZGbiWxKiqJwzvdh6bwqn7IY txuEY6i1ZGiW7rm1BD6EGs2WN6gxg/eth53drrL2eKsGAAX/GNHzsqirMidJ cRtfRAxe2wPVNOLqR7Jx6zLP0sh62KC3tIVnxoH426D/vwJisG+auaYCAPhg 4GC9fYqoHS2zNJDyKVTkcj4GPb7MpUbokmnwW0uib8q6q6e0bhdpt/HKhyzd cNGcy61YNlTiaYWzaQkw1Z59RiHkQCGkR43puI7QIkRXiL3VfHbb7mC0iqd2 waJTiB2naL29EzwotQvjKinwtEeiX0N0w5OKuDOsp/R/ZG5h6EYiPQZuaOMS EcIe3kjoRXE7q8vZRatygRtA+H96YzfrRzg57ZmTfsTipR3r35Ar9jyc4cw6 Iw54NJIWraav5u8WpBvHpimO1veb9ODV/vK6aZbDqrmBxf7FK9gp3XMQJ0va k7o3TnrIdLekMZeW4u/r5KLuUa/bDdclVHInIb16zOvsIQ8/x/14Q816gQ/u CLM/AgwAfqGpnQ1lbmRzdHJlYW0NZW5kb2JqDTk0IDAgb2JqDTEyMDggDWVu ZG9iag05NSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3Ro IDk0IDAgUiA+PiANc3RyZWFtDQpIibxW21IbRxD9gv2HeVylSsPcL35LDLjs CjYOKnhw5UEWI7PxapdIwjh/n9Ozq90FjB2/BBUgtVp9Oaf7tBZvirngTgrD 5pIrtjguPpQXaber2mY2l8ZwVUox+3Pxpjg6dUyyxboQbO6YY4LpKLiwwTEf PDch4t0NhRNCINIKkRYzr3kst8v1ulrlKJTN+jhkK8/a61TXVfNptvgLOeyY g3vLPLdIZKTnQWi8dJJb4d2YSFKi8jh9SXV720cRXAvrxxQv27tmv63Sjt6k j0WtJu1ezWQo2+3n3U17+1ynQXFlpWHeRm6cDk86PZ3JyH3ZzkS5Tavlbk+1 dMHGlqibriMXLbcxBGaU5EFK/agjPFM6ssU9Qp/XqVluwUYo/2HumQqdA1UW hRmjuHOW4n0oL2eEXNlWq8TaL2nLXp+zmXYw/Xq9qTLL7GULcNo6xz1ZIHPw kk3/7laFM5Y775lEedw7A+q5CxYgIphwmm1T0VWAt7ziBrOwKda/FL8tHgAQ WMi1aq6dVyw6wWUQGU3B6LHrWjeSWi/f3aYGOLLDQIK+5yq0zoH1SYUgyqrA 5grlSOW6CnNeFoXnKpiuQgE+7lnhheUKW0DEOKXwnnWWex8GSz36YAqdcNkH UypHC3ykzemcAtEZhc7HDpa6uCgkowcBqyw2B3OlItcGQEUejH6Aa4fiCJ7W RLRiLiCnxJMpeJj19Tol9nGblp8HvFzuUBseXRgR2hQaJUUZRxPV1iWbjKp0 XClsObGltVPdaD2Yyp4gJp+ZThsMDwHTGb0kMGMuejLjb9PXPXuVmrRdzubA oNxTuLdpf0+LyY7Y2fnvF9/bp0ORQWEKvdbfKVL/qEj8chF0Vpmyr4Gd18sm D+OyuWbH1SY1FOwbujUWNchWxDBK1akGipopUy4hFE2qEWm3uuum+wciG6FB QffoL24SO73b322x12t21n6s6sSOM3ax3C+x1JvNXVOtJmjuXuQMJDdhKn/Q aFOm1Q1517m7k1XbtJv8sheL3W1a7XdP8J9KdPRcemCGO8B1kK4bS9rinxZn +XPibLCoOjqJ1Jr7+EiaDwQewpsx9/SCHOj9L1eobzHT+T+cHkitcrm5KKA1 lPSq2qYa49xHDdKqR111vQ9jMD/kF8Z9q/8supmtvHg0Be/bi8dggFVJNXmj uTERh5/EFdR36ywNjfiqp/3d5ckfl69PrnoVwrngJB5SCk0XD/JzMAUopABx dZbDAISnTr1J28BVzE7TYxQhmpvBNDpd9HoXER06LmSWu8AReLCQ10H+e2fS YTrvm0I5hFJ6sNSDgNqoufW297HBD5bRx1jMjKQzgoMD+feDpUuaFdkKTFeY NttbjHWQdmrDQKFxDCcuvYXKIljqnCCEB8AeTGPtuXXwNHXqTYRG9FSYMbiL 9kGkg4mq1+h0ChldUzkSAzjgbEScsDDcnDEiOTk9STIBhPB0PQtGHRAmCyEs PTk/OfSbwTRl/z1u7Kfi6NUF/u3wvGJFUALLrJHZqjxvElpIuxoVj903hMM3 FvnoG0tQWD784COmu10IPl2fbuLxDetLle4Z//vrNWPoD3Ri3lDrC8gODlC1 T7iReSH+FWAAsM+ZTQ1lbmRzdHJlYW0NZW5kb2JqDTk2IDAgb2JqDTQ2NCAN ZW5kb2JqDTk3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5n dGggOTYgMCBSID4+IA1zdHJlYW0NCkiJ7FQ7jt0wDDyB78ATaEXqR9WvCBAg aV4ZbOWtFi9Vilw/siiS9gJbptrXacghZ0jZ2hC+bRG+Q4R3iKHAX8AIP+DX a4S3jVMCxELwe+PY5fgYxyPKEp0EPqKDmzAGxMVeQPjElhm0mCWDrYVGWTUo osPHgJplyRqZT7WmqdWmqwWmrQHTv28vtz8dbndAuN9+bjHQsYEvMPe89iDD EkIrJcRSDp8HGvwDDTHus9LzFjFOoR5SpeGvxUHIjA49S53EjOZXQBbYEqr+ 2KCih83meR3fOSWWJTjX5XCuS+Ga3fNrOw+Z2PUPRGX1ZmyhMluEsYzzcJCT nFfdvgnKo3UDq0qyI1FoyqTBQjplm1fOs/U8kKpplTo5+dz9VnxPGrFZkGvI pw7IaTFEwbDpe0TcWYfl3FV1NuwpxFSd0cu1g2HT0Ii60A7m8jrHfrrg+b05 rHneNw2eoNz1y6x1XogHRum+nWCay7XiVuEkU6cqh9ryyiF+KEQ8N3a4hL16 2Lo49nnsD/EvtMoXumwtrK6JObTuQ616H4vGajPZVNT5yLscC129aR7xWo14 bW+BpW/1Yu+D+/3zR/b57jzfnee783x3/tu780+AAQAi5xkGDWVuZHN0cmVh bQ1lbmRvYmoNOTggMCBvYmoNPDwgDS9UeXBlIC9FeHRHU3RhdGUgDS9TQSBm YWxzZSANL1NNIDAuMDIgDS9UUiAvSWRlbnRpdHkgDT4+IA1lbmRvYmoNOTkg MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIzNyAwIFIgDS9SZXNv dXJjZXMgMTAwIDAgUiANL0NvbnRlbnRzIDEwMSAwIFIgDS9NZWRpYUJveCBb IDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1Jv dGF0ZSAwIA0vVGh1bWIgMjMxIDAgUiANPj4gDWVuZG9iag0xMDAgMCBvYmoN PDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgMjE1 IDAgUiAvRjQgMjE0IDAgUiAvRjUgMjExIDAgUiAvRjYgMjA4IDAgUiAvVDIg MjAzIDAgUiAvVDQgMTk4IDAgUiANL1Q2IDE5MyAwIFIgL1Q4IDE3MSAwIFIg Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxMTggMCBSID4+IA0vQ29sb3JTcGFj ZSA8PCAvQ3M1IDE3MCAwIFIgPj4gDT4+IA1lbmRvYmoNMTAxIDAgb2JqDVsg DTEwMyAwIFIgMTA1IDAgUiAxMDcgMCBSIDEwOSAwIFIgMTExIDAgUiAxMTMg MCBSIDExNSAwIFIgMTE3IDAgUiANXQ1lbmRvYmoNMTAyIDAgb2JqDTg3NyAN ZW5kb2JqDTEwMyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDEwMiAwIFIgPj4gDXN0cmVhbQ0KSIm8VdtuGzcQRT5g/2EeSdSiOLws yTy1ceKgAQok8aJ9iPsgKCtXibVKd+Wm/ZF+b2ZIyrpUyGNhyMPLcDjnzOHs nw3CGhrvtIrgEDy0qoWxb36DoXnRNfMbAwjdqkEN/EeGfUNKCWwk127TzK8n D8sJise0bOavbxHup0ZDt+R/XxuBsvvUvOqadyWoq0FdCerA6KAchOSUTcl/ N+pMK63R59g0soEv+CCu5SwqFFs5cyqKoZiVNCqJfuzrfNnD++LXy5lRQdyX 9bX0YtqNi9369DzcbMeNDKoVIH/v3jCC1kNEqwy4yFRpSpvoWvF6SJjnxtB2 XvQeafjfdSLhCHtMEAIllVLmM+MzjC9DjVgA/kx5BNHJGbbKMVxPBiMcZxaC zzdhe3L/2SrdnvLlCYwLENpWUT0d351v1K6Si2jL3T9Jy2w9StTExX0xIA0S uxaBuDTiX+DlJG77L2V/JylaEFBm/ooyR2UF1Vrbp8kL3vVUDk1FGfOqEw8l 0rqYIQM88GXbxFopWRfGDkKDKjQmw8daIGbshJALO1mXvujyiR1DpSdvzapM Z/yUYS3O24d+MeXsCQss62ibUW3yLIovefbQ7yr2ghkWw0fKYPc4DrD7Y11P Tnt+KiOr7VijbM529tG21T4nYURi7UQWLhLqjFefMXFhh8WJhWykZaYq2HAg m2CHgzy1Lwz8+vLVTCI/t+vtsOIRMTFKJJwDPbvbMv6LpKKpsCYpI5gmQtRP V8WdlGLE7a5MylGWkBNTz6gdHVkMw+KhnK6m7wH9FbTaU3o3fGgshxbD5xJp 9VhW82Qn6RWimBfzC7tasVgPRxnM4XVf49CdlhnPTjI/vKGYf85E6amBReIp fkeP1u9VZ9TpA72wc7lPIkbWPiUfjrvFoRq1G94s/n7OjY510BLHP7g0k9ww 7kQ2mjEZcSfzrE1Aweghe+r2lp+1yfpqWflUM0OXio/cMZ3oS5wlF5kH3FyX /fTjsRcVTlG38uS1ISd7KkaCcaF3EtWudEk8654XdpiczpyTE1DR02xTqA/z pBDPuBDMEQaEve1e1o0614eVvcu551NR6IsZfahHcpkP38gYOA3O4ANpLL+K UXIt6Ae1Y18AgPxhOUXw/+aN/KT2qWc9RWYwg7DUy6ktWdYGHKP4JsAA1jC8 aA1lbmRzdHJlYW0NZW5kb2JqDTEwNCAwIG9iag03MTkgDWVuZG9iag0xMDUg MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMDQgMCBS ID4+IA1zdHJlYW0NCkiJpFXNbhMxEBYPsO/go33YweP1zzo3SKlUJFCl7gnE obQpFGhSpQGUB8h7M2N7291kqQp1K896xvZ883lmIlB0VxVaoemPBHoN2gof A2ityXhTadFdVPKF6r5VNRkxoOhld1QMZa0fNP2W/Z0vj8kJ+9TQti6UI4JN qDMK+g+eISTvhMMygo/yTCHKW1U7uTj/vlgrbMDQyU/d2+pNV3knAmrwwrae Zg1WrBfVFet9xLTGSIakdA7BTOhfdwTQZYCIGQ6KQFiFbzXEGD2DqhOqlmGl T+1E95sQdspDI68VBkK2+ZHlQtVowMqZ0uDkbgcg3pNKy/NiuFG18cON8O/j mM4ixN43kSPvSNVAKzfJ73N8MuYdD76CAhxy7oMpHI6Y3dMSr/t0ehzT2YR7 OtFnOt/RgxeMSG4ZswOUn8u611Ow4GVNAbbEwKpoYSaE2Asjj5HyTNWRdven LhIfgXlsBy42W+WIxFk5/3DLrr+YnYcxM66ZYmZPmzLO54yLzA9EbEQsJFlL c2GImCOCdKbmRBlDQS+Vlr/SqzgKQRPs2nAaXBRdv15+Ea8uL9e0ynSy7Y7Z DSQK5OLR0BwCAerhDVGhDUNYuTWk4i0xN4FiS/G5vVqbsDxWbSZAEx9aAOVT 6gHzFWUBWsqK2/PlNkG30BhfGkkuzJj3/k8dDcdRIgpLjThuPUlu/nJxSY2J 6hmlBSVWbk/00Y4omrBMFI5uwRVmcvOxOSXOyrtyvVu57lH3MqtzG6CgVkUN z2Xp6WPHVOQKyg9nwDTe5pfT98k9zCcKtKdkVEWH+kOiXBvviUophH2DQVMo m69+LjcqNcA1iyi3CrmFz7JSiOkMo1pgtOWLb5qKFuADdwUrT05Zeinmq8vF rE8KnubXm+2TH6CQt0uYqJxcax4nr9XT5B3oJ8ij2R3Unzz9ulou2ANxZXwc Fh3/Gv4RYAA8L8BtDWVuZHN0cmVhbQ1lbmRvYmoNMTA2IDAgb2JqDTc5MyAN ZW5kb2JqDTEwNyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDEwNiAwIFIgPj4gDXN0cmVhbQ0KSImsVUtu2zAQPYHuwO7IomL4l5hd +vGiiyAotEuycF3aUVFLgaWgyQF87w5/ji0LKFJUNkRpNDPkvPc4LG7xJX3T tYf/Pgx0QUrOqcVLGAVV+JkouL8l3z7c/AUpGAQjct98Lb40hdFIG04NAivi Fu1csS605lTM2D82BeeIwQ+GitEaeU9pbYWabVEyypiWqFkVt9iFtVpcEj/d lpTC0CpVYHFLuH/9FYc3IvP/rgCC1LRipoKims+xBqFiDUeg6SlmykZkBEB0 jNmZfQYzWdMqYcb8TJC5+ZkTSwPhs6lnvswkB5y5tSYkh1pUqMU/SYGa31DV 1YqUihqchp6UkgrPEK/w47J7IVyCuSWQSOFug27cjoBmBB5SQIfucLRcE8Cr xssY7D4QC2wiEihepAynweOxy3UOjEu4I9H1PQG1mzxchoj98RVpgxAJdb7S FqXHYpV/5174uU44FQJgVrVJqg8IJ3vaBxIQPqZk5gtQIgIjIhPCqJlQzVDp w2Hh8f1iYRBHzbqoQ2SdIv1OPWwsU/v48MhVrPEG0FMAzs6jCKMbXEeEpRKP bXrYQKuQGC2fkv0hjn0OGT4gL26BV70fNS4PrgR2Ns7+Ic0hyNNe4dfQbfqQ x9YTWuNxdA5Fm/EksyOX7yGjO6REyzhTF+w/0OCGoe2zLYSi1cOyDf413kHA Ln51qOtHIkKdBAipsXvOgGwfR7ROL7uQ2a8VCAbXsoa1P/q30JeAUI1fJrgd kI0r2LTDmE3LaBrbPoUkNNbODe98X9NJXBcLHck9lQUzcM+yCKKdaGGysZVV VKeucdIwmAZ9natWWZGVedJGzu3nTUTVcNzkDgWCq2RuIkxG6X3qu7VvFNxT CCLU2HUrhxZQfNy2sXYb0lokmQqLDGkPmobpIK1KU/m031w4n7RHOj2N4fAL 4hMiHCDH1haOF+lb0r9HEgXzp7PJO6yTQ3bMiSGNUpOWoSpLRe7JJ61h7gsA nQGJMFfc9+qAh4BTiLM6woCgQSoLHU7hKy9pjp82T9OyQOzawMo15lBgtNz/ EWAA0AfMgg1lbmRzdHJlYW0NZW5kb2JqDTEwOCAwIG9iag03MDUgDWVuZG9i ag0xMDkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAx MDggMCBSID4+IA1zdHJlYW0NCkiJrJXdbtMwFMfFA+QdfGlXi2fHH7EvgQWJ CRCMjBvKRddmZYgmVZpp2gPsvXf8tX5SwZgqObaP7XN8fufv1udZVWdaIakF YlQirmmB+ia7zpTi0N2ff1Nnp+8U4qi+zjhD7gefklGDpJKoXmQ5o4yVqJ5m DNV32Xf8kShqcUNyzvGCFG5w5QdhqodWYuTbMf52Vp2g6vKi8rYPJLf4hDCM 3pMf9Tl4pFbD4XDyWfbkB1dVNSak/gWh6RBaQUVpRVzn14yCPYbOqDDBCp6d oZbBYKnW0fBqZ4ddu+X+etBhItwRIWKowBA4QsoySnJNS5zDJzTIh7/hhcmN 4HyijvkT0i3LUzd6LHEFqZXYOSW5ogaXitE8D84iWQkrAsOS6i22ByxAdxeq cOgjVlHYDa6fSC4gStzBV8O39V/jLiwsjBdNNCyuYidN9H5FuZuVQjxRCcye S0DLFycg1ZqATR4rwjlV+JJoaC98G0gIbNgeicKkbMstDnvzByhwAy1Q2CkG HovhKwFlSDwQDu3trGkHdOFLo5nfOGFRjVdDPxnSoGtHhBdUxqwY78yAzM2m M+9Cy5TpVHljfAeyhDveEK7gsAFowlE/SSEh41ANIC58G0bRhpZ9N3VEBG6a WdzXhiXzsGFFwG2JQcdB6On+hYQDNhKwprUtXE158Z/CLV5euEf9iT+WaawY B/Wwdg9YDlQNg3LYrhofig6hvA5FM512CyIcmuWkvU8V0s7RsulXXRvun95V 0HXMsi+O9XOAR7sPbKk3pbwNC2qv/EtYIWUhYci4hMl/APRsNpwdZyOsDfnn 22ren9/nIspyrWZQf1Kz6wYwFp7R2cyxULTAQ+p07eR37Lr/S4PfEgkru2Va 0KzQZ7+5d2mCDVMvt2Bs5yt0+uV20j6dNxAIB9+jhwdK+F4qd5/jY8X+KMAA kN27eA1lbmRzdHJlYW0NZW5kb2JqDTExMCAwIG9iag03MDMgDWVuZG9iag0x MTEgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMTAg MCBSID4+IA1zdHJlYW0NCkiJtFXJbtswEEU/QP8wRzKAaA4pUpRzS+sA7aFA U/VU96AmcvfI8NLlA/IN/d0MF1mxozZIk8KwSA9Hs7w3j86kkBKhPs/8Rmqo f2RvGQB3QrPZmzMAlFLw3IqS5bTEB/B39YtsUhdAry6ySsgCJNTPMhki+SDs Ca8/Z5NTE12kqJLHnfnUn/LN6swa0LYSlI2+qhIWVm22yIxBoUZPTuoMJfgP LaUUjrwk+dbfQgG62JXiYinP66fciIJSWqEYOjgLPz/xHAth2fd2BSccKQnr mg28jtuP28Xia/JoYc6ai4v+hU2/6S6b3mXOJ6+2zeXuaMORgvy6uhK8FO4Q XaWFdveGN4IaIQXrIS3uQeHfwkvVY4aup29GhStGuTghB86nQ02d/d5jzlji pnCWyPEsBYKS3QULqgNGR06I0cmpjXWZwKxJxJpI64AR+CYQI/2YvHQlsKrK fgLK0E1OW1QmtlNT8U4g23JJTyJHsy5sV5zo8rNA1RhGdIYVztoPybQOzsmt 4bmfjWBK591lRL3HdRhNLF0qbrSJHU8+TBqGf1aYenxFF7pHUWK5y0gqZDPS kWYhrZFeLZaJPN8fCy/IkbHQMlnwUOgjJyNCV0iHiWYCre+DCN5uuCahdaQ7 x1ZehorGlwiN7KTp0iJhEPqqEqRoY5Cjo6MpvUjQVX7YWfyhw17y3As5DyYM Jn3DSfZOlLa6Db2294FeDdBHshm87ACP9+eGEj1CVP3QqOUwJsUuqoEYtcfd isrdGK2BOYbFVMocy6mWe0mMMDcvrwPJCFPcrZjxhtV/gbF4aNQhqNsFtccR xiQqkmEQiD6Qzi07CccF3bgkG1lF2YQEdrhJMM79nC3p4jM0uG2z5kgL0B9Z MJz7m+RLvE7o0SyXq265SocNl2zTwvvuZ+vfWs85147uIBr/awEGAIUlxm0N ZW5kc3RyZWFtDWVuZG9iag0xMTIgMCBvYmoNOTYyIA1lbmRvYmoNMTEzIDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTEyIDAgUiA+ PiANc3RyZWFtDQpIiYxVS5LjNgw9ge6A2VFdMYekqF92k0x6MWvturJQS7St xDYVfTLla+TEAUBKdrpmEbuKhAAQvweQzbfktyYpcshUIS3YqpAFKKQmlxw3 fsUcraQJ7DzXSP5I8kuTfH4tQENzTFCG/wpKhWqmLlGnuSYHJZUqUaFLiELe 9+RNvKQHXYlfcVXCj3fwR7gyy+EqiCxlLd5TK9zE/PmcmloM4+d5WYnq3Y22 JdUCuqizDMeha5fBswimh8G/+MwQOf2n1BQCvqRWCdjskato8vfmG2ZlQ1am llqVmFjzNVGcBWUg/kmbPx6pYz3KPOpIpVVNipS5rrOQ8JzqMkSqOWorhlRn mOMx0qXoSNQ+yY1GuU9tKW7EhfSQZdLiCWOQrcREoistkJpSFuJMZtjCzAeW oEme34l0tIAjxo2WPshxmehzJlOOFhbgGWTe0RF61rXM0LQ15MugL05opWVk 09PfAxfOWKkzU4diMPhqB58oLoafwBMYCB4fOuSZzLWt4KClzveTld7quDcO hmIrhbFgPyCUbU+t07uxpRAF2TRSYwEVN1FN8BtMFnWJBy2TPbQwsgG/+C72 30LfZ1J3MIcDGSZI6uzqtrDBrRZdO/E3C7n+iMU6L/DunjgDbXUIoKPlkhr8 XnuMiwxjn2eyilVQlL79QRMVZZyal9cAoy7DArGJbgRaR5xLYKw7ii4gS8oM VEvktFB/xMN8LtIPlWcNbhH28R+HwDrn0DXkgN342Mt7h7dEX0I3wzj5U+gT LTNb2ac+KbMd7SwmPLXXqwN0X2GRbgi9NOJyZ5C3oh02Q1vtgq1877ns6cbB 6fm4v3IjEgW840BsjBN3C/b6QJ5zMce7hVjUb6hygXENjO3Q6Gc3/wTjxbWz g2Xo/oTlu6cGu/uguUbNj37Hje+ObppcD8u6+IeuxW1oL2g72rmFEBzZ5lJk aEXV+aOkWaH3G+sNh6Wj9s5j4Yy0eV08lLVm5TdxmvyKsZgQG9fYKlkUtX70 J2miEO/A5iXOqtkqriN4X1IMqEbkDznBFjY4OjdD23V+6omjw4gQujQYJ1g8 TSINzdnByd3c1Aa9S9DDwaoRi/0UOtfi6HkqtZiu7bKZxeslR01CjMzx7BPR Q7fxenY6hNCWYCt+eRZFvRnLgSKISbR3RMcH0RpORa/wyIZ9hmC3hIIVF9HK ZZFZ8/HVCM8LjwlW10hT5E8gqSKCxJOBZsWn9FAW+zRoxY8wbuEVpsaiV5if 3mxDyDJC4mu7uJ9B/t9fePHCs/ivAAMAgfzjNA1lbmRzdHJlYW0NZW5kb2Jq DTExNCAwIG9iag02NjIgDWVuZG9iag0xMTUgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCAxMTQgMCBSID4+IA1zdHJlYW0NCkiJjFTJ jtQwEBUfkH8wN/sQY5fXcGMZDkggJKK5jDhEnfQoqJdR0gPMB/DflO2kO7N0 47TU5aXq1fOrsgupOXhTEUHqj4XgQghJ6lWB098F/Rs/Vv8s3nyyBDfWhQ0u +uRuTHAvw1CZEHRDOfnOJHBDe6bw/3bHpEXbHO7TYGCY1NDuLWE/6s8IrRO0 4c4bfYnJ4ntESjoevGNkoCKFDaHIJLiVWnHhwJISuD3yhiNv4RPvb4E10A2y Bto1Y0fGQBjoPSsV9/TubsNA4vyBrOeN4LrZkNXQtf2BrMLJgDbJDCmsJX3y 3rFS4ny9n7a3zaHfT1vksCdNQv+171vSdpvmIe0RJg3XKGaMQjHD2tDd9uNh QITktGfKx12D/6+ZcTEwyHtVF9YQEBUHor1FBQTXGF+sw7r0GBZXQKZFYzDB C+vva9TbTHoLEn5onOCeSIe6kXobhYUofRhJnXT9Eg6A9Q/H13Q8dCiMxtGq mQZt2iFTP9THfjB+6oZTI7xKhZ+ICL7s3GrOLCBlRkTPJQqhdDCElYZXaI/r KLik77astGi7oV81O3L1527oxvEpG4kUbS6dm5gkJiplyskcvcaJp/3YPD+p ghR4DpDGTk61lPZYG/GoZs/WsWZPS6VtKlXqfDcrpl1S7EMTSuJC7zo0bZqR r/s0mK9sPV88n9ARWKoZPl6o7XmVJKQgZAzVklM65EvgSoXzLcDPQ+pqdr0M acJjkAeJutocSHeRI+joiAYvV3SUVbVAXCSsdF7CyuedAPAq/h8O8BnVmYBY kCxIZXkuRyxITi+AsZd74aQzxHfpktLgfF5SD7kNCJXPakAlZG4DKixMTj8o fKvzAJXLgdPicj+clFZYFL1U+p8AAwBHsr4NZW5kc3RyZWFtDWVuZG9iag0x MTYgMCBvYmoNNjg0IA1lbmRvYmoNMTE3IDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMTE2IDAgUiA+PiANc3RyZWFtDQpIiZxVzW7b MAxGf4Z22LzfF9Bt0iGKKEuy3OPaDsMOvcy3ZiiCJB0ytM3gpNj2AHvvkZLt uLETBJODSKaoj+RHik44E8WPBDRT+OCUupSBcVKz4j6Jm8PCMWDFbQI+annU ctJEPaV8UD0Iqp9spboG9LpW3Q3prfT7QRoFtepOSKMsauwHqaFW3Q2pjXS7 ILUJqjgZoypVyPMWasuoybpGQcVtxYytAVrbl0Xi0JTRKFRIrHasnCW3ibUx gE35x6KFmCniTasIqKRSkLFikgzq5a/kmn8VXmZ8JgZapnzyWIqBxcVcDMDh vPrDrhZnTHwrvvTxAwbIZzJR8aPIgCLoreSDzepDO8kHB0+gtwNm2T5wnoja DzB3tWpfpjDBG8QifMUrmIpXJgZ5RtSOuADgd0LxsQDDlwI8XwlwnKX0zqbz 73N6XdHGMogWdOKB/iLzXqY+p0orLkIajWvSiIkP5srZuBRYrJwtMXWpNJhC rCc+nSGaw8UtZdiQW5afl5XObDoPmyt2Pi6n4fxIiFSh29FyVX/g+uuvI++p P9Wqv1Q3jisdHb8UgAr8t9ApTj+p8Iz0vByv6uXigV0IvNrIH55E8mZn7OaG fsNqbrmaNx6ptqcdcddR374n+drPiuDPi7twJwApDZcE+AcxyHDCnMmcs6vx PTrG5P+Ovzi2S4XJkYHOFu6F4AFiLMBs6jFMDAarNNu4ka2WkvXz1BEjT8PC VxfkKWHWRMKu+cHh0fEzrC+t+Mm+45TG85EC/eLlMU72VQR4/ebtu8Oj9ySp MU93jZNW8o3HxmI8VnSIIQRA4jyGRO23FWtHjO0Gn+UE2aQu5SV9HxXzGGvD RdP4Y99HxnO6CI4+UYFsehCi4XoNGhIDKZn2wPIGs4EylvpiavuB/gkwAA5W hUsNZW5kc3RyZWFtDWVuZG9iag0xMTggMCBvYmoNPDwgDS9UeXBlIC9FeHRH U3RhdGUgDS9TQSBmYWxzZSANL1NNIDAuMDIgDS9UUiAvSWRlbnRpdHkgDT4+ IA1lbmRvYmoNMTE5IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAy MzcgMCBSIA0vUmVzb3VyY2VzIDEyMCAwIFIgDS9Db250ZW50cyAxMjEgMCBS IA0vQiBbIG51bGwgbnVsbCBdIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBd IA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVu ZG9iag0xMjAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0v Rm9udCA8PCAvVFQyIDIyOCAwIFIgL1RUNCAyMjYgMCBSIC9UVDYgMjI0IDAg UiAvVFQ3IDIyMSAwIFIgL1RUOSAyMTkgMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgMTM4IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAyMTggMCBS ID4+IA0+PiANZW5kb2JqDTEyMSAwIG9iag1bIA0xMjMgMCBSIDEyNSAwIFIg MTI3IDAgUiAxMjkgMCBSIDEzMSAwIFIgMTMzIDAgUiAxMzUgMCBSIDEzNyAw IFIgDV0NZW5kb2JqDTEyMiAwIG9iag05MzYgDWVuZG9iag0xMjMgMCBvYmoN PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMjIgMCBSID4+IA1z dHJlYW0NCkiJbFXJkts2EL3zK/pIxCEEgCBA+paR4/E4lSrbYlUOLh9kWZqR o2VCamL7R/K9ed2AllFZqgIajaXf6403fTHpe0eW+lXR6S6QwV+EaHRLsYva GFNTvy0m07GhxSgnDI2LYnI7s3Q/Fob6BQ/fipJU/xViFYO23gfqX5100esY rT2rfu8Lozvb0uXIz7Kd6SzbmU0LS28hfMWJ6OgbWUN/0sdPhr5gZ00FlNF4 3XryTa0DtUF7GpbFzS/FjdDziR7bwB+Tta3GJTAMmduJU2XA1zphBKn2TOtj ederqtaxnPJ19al/y+j/KWyM2nmKIejGJbc5PCrm/6Id27+wmg8/M3vy3H/Z Je+vLrXxGioDrI8ATZcA0t3usFRe23LYzWU+KFuu93mxIRUAv09HNmk6DGlz tVovRKDpfnc/pM1RVU43mGRDKNvmmCBJstbrGonSWB3DGVzTMDhxZGMTut8U 3NKVT/dPo2p0DWwRaKi2sqIqLWfLx7SxFPVW4Q1bfoaqzqqBjMyNjL9iBDYn C8N4eeJFnRb5wA2m7vjCRnRrGXfy9ORWted9xWHezmWx+8G46yN9q5sGsa2s to3xnMjXmX8RNxSOhW9sra07+8aEY+CwKa55s0fcau0Rog9JGGVccsI54Kms wfyvskG35VxVyDL4j2Ehuimsr/fD9pSVlviPVEZdBNdwNqa6wPpUFc9L3aF8 AoXWa++v6oGhImmPAa1zQN+J3Q2Q2pLzpWZkHLpRFklFwO7Khch7yKCxfdyk vcPlkbnIuy80qJDvHp6wU0tAAuIkl+nwsE7v02rP+q0yUO6FOd5BeLyT8OTW 85PGxLELaTM3tmPNJ2JTFDqy25d3KIbt43wc6ajZPw0jvRo0/aHEGGA7oDos B7rdfn6TlWDE7mxZqB1K3l5I74A+lA/73fIlyU/ovwAVz4Fty44qqk2SIbos WspCJyYpdCncQgikHROqzgmGzIkxEZotHlDdnESx/FtZOA8RSMthPICNql3g YmiqmPVIqgb9phSAkvleI98ls0UCGy784NHlw2UnAwBEQOy+nn9/ibpy6ZVW PCPjCw+SaQdMO/ZPXso+nEc+650T88+TtTGBMVwZP4a48k63tqvZMeBlT46x 4bplWmOZMZoX3H6zzOKwWSPdGsYzkZB2Jd2qKkiH4Kob0JdQi7acc1pyA/mh cMyXP69AfGr8sQIrOA0luMrfpZC/Sy65Fm2+Q68HJ91efZb+F2AAT4yeTg1l bmRzdHJlYW0NZW5kb2JqDTEyNCAwIG9iag03NDEgDWVuZG9iag0xMjUgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMjQgMCBSID4+ IA1zdHJlYW0NCkiJnFXfb9MwEH7PX+G92RMxPv9MHjc6aUwIgRaEEOKhq7Kp 0DVTm2nsjT+du1zadCwZiFaNHX935+8++66Z0cbYJKpFltPUBFE9ZF/lTHld yrMTHt+9fc/vCo2cFBefePmLKnWSwoAq8PVIgdFBCpVbcKYbY6LxW3WRlcLg txS2BB1FNE4XxjhR3Wa0rSv2DCAyg8/oHjD6RkHUhVwqsDrKtq3XChyRWDQ8 WV8ve5vbeasgoCkGSrJZiwcFJVosVytBtl5e1WLLLOveuRVtIx55rSFHkPea KefWIdUctI0RFZpl+BpCIKaGOErBH1V9z15XlRcgquvMJh2cc5gsenS5waBu ybl9WNXzbS1aog3I16B6ix89x/nd3UYFzLXpx+W8N6w5MXHVZV7KnzWLsj1i iXUZWWWa+BBpCKXVfqf0AXUifVZlyaIFaofkAyYqLJ3Ops4uMxD03S7IxEdk 7zEkCQIWI5LN6XF2WmUABNG2PCscPUNMwwF36LbXgOWgWerVOG9alSfKDvBE VjjH3MSbOV4uPPAD6KbZPCprUCO8W4UJHtcul2y/vukda8QceLL/yCv36C3n 67a37CIOcYCECnLW3F8dRLAJUy7+KQJJT0riTUMxU6EdnoL2hci7Jwp1/Vew 2GEQMeknqPUlzSd8CaVTZjQZ2uYAdsjRTjoTmvbO0dHzEC68hknWhE5v7PFw yklfHwJeod2+VhdP0ADFC6RfRndCJ4rJIJXIH1KOonutxtGdGKPoPt1RdE95 FJ2uIQya7LPSPen7TeR+Y3QsQxraDfUYri/X1xddcrrMM0X9tFaWuur8BktI WynOu9Wuo2C11avutV+t15vlgVOr6Jc7rhGgrnWMHy6BoQMC0obkmVJX8zbs a94xp1/YacyrXOWx+8foA/QpRe0tkidXoHRmzzrXsBmyw83EYDq9YQi8of+P DYcCj4HOcryGGZuu4XHfXQ0zOlnDI86/BRgAN3ygyw1lbmRzdHJlYW0NZW5k b2JqDTEyNiAwIG9iag01MDUgDWVuZG9iag0xMjcgMCBvYmoNPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMjYgMCBSID4+IA1zdHJlYW0NCkiJ 5JO7rtNAEIZ7P8WWXoOHvV9KAhQggSi2QxQR5EhACCiKAFHx6MzefE4OsxKi RZEce779PRfPP91MWgnwjllnQQXmNGjHVgEmsPNhQhwMSNVxid+jm9YL0Oou NdZAHGqNtWC2vArCFbUy5PhA62NOZZ2BzqQCrypUJubQgOZ+1Zj2dkm6NUTS rWSS7tL0KCXDJEs3k5QgDBP4q3dB56s1EqwSmqXP07zj6WNWuKrAjyR9lqSn eC+E8Sy9K3cC+ffpzcxe8Qh2/sIdXr9xacG1h8uh/B0LZzsekNTQucY+lOup hNhLjjW5Frs0LVu41GDmhStk7eEBl+Bnxt+mF3d7w5WI1tdS11yhsr1Wr2ut v5j04eHK1/Lu/oLWqgOjdMyfW0gRS8NFn6V4uI6lJbPgcS7s9ugwoRKxJjT/ kPBZ6itnFQhyH0Nn0kVwV7QvJK3NNLpO/zBR31da3N1b6dC9A3F17yBxX3Za 29zb8o7cO5xWGSWu2a1P3L1ZUXCbBQl7rxTcmqHgVi0F/8a3KoAxzbdPxr4t u4nzaLtpXTPu6/0ZTSbnT3yV1VFSQJyfn07s8fHwIz/JeX96fzh/Pe4v3IKe f9bgsiz/l/3wHO09BGPjEaruOkRDyxGy7jdEQ7NRsuo0KlnfTELVPJZzXRns twADAOXhk7INZW5kc3RyZWFtDWVuZG9iag0xMjggMCBvYmoNNTA1IA1lbmRv YmoNMTI5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg MTI4IDAgUiA+PiANc3RyZWFtDQpIibyVTU8bMRCG7/4VPtpRd/D3xxEEUtVL L75VPQSaiFQBJKjUKz8de20nGxgXVFVVpM3uPH4949l5tWRLrAygArU6UgEm 0Gm+Pm7IlvgIWmUSwKoGpQKvKlUmltAIayXqvgMcDMjx5sYaiGN8KBrHF4mc pWSopGlLpARhqMi/ehd0uVppQZl8k+4Iu+TpZ1G4qhDgpS+SdElyO4RQOXxD yp2LNP0m3xjdXe+e6OeHX3xyENmG53Wa7SmXIj9+rdEnPimQrK25Xt/e3z6U BY5ta2jFXX5YUf49fVlWbMBF65cF2F6A17WAZyqV+DSVfSw7bNAO4MCo/D6L VIpYdhGzvkjz4nrYlsyCz6elx6XjhKYlNH+R8Cr1cVIWAjZqoSHpIrgT2CcN VRYYXYNelBQL2qcQlRbou9Rp0O6EtgnFpRkOk/bhRZXGWjA9p4JwAvtcj3rU +qcXM+/e9AihizZg9HhShC5Og9BFxQj9iBGFyn9Cf8iIOvSxDK4ZcfZgyDbK HlTZgef79R2fPHi2+bHmIbuMXmweSySw/e5+teKTLcH3PecPFrDdAsFWB7j/ ZTn1Tyw3vxDccjMaWw5VdsvNcGg5VNotN8Oh5XBptRyetA8pqmyWqzlHlhv1 qPVPvh3uCk2Mx2/Qa+UYhs7+2PvXWV8EGABBPJI2DWVuZHN0cmVhbQ1lbmRv YmoNMTMwIDAgb2JqDTc1NiANZW5kb2JqDTEzMSAwIG9iag08PCAvRmlsdGVy IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEzMCAwIFIgPj4gDXN0cmVhbQ0KSImU VNtO20AQffdXTJ+6i+rt3myvHwNEKpVKq8StKlUochMDaSFBjil8fmdvuQAO IZbi2TmzM2fPzDq5TKQumTagy5JlEri1U/ffNolHyzyiBWdKbsNKciYNZEIy ETejne+gPaktWqxT54qpfAc22ubsS+3RvtSI9pPWmWZlb+aA9mTWWcb0mrNk ZgfNhNkjR0B7Mu9Hj6vENYLj44wCw/CIpmSGcwXVbYLRnAsD1TRxloDqIflF KpqKgmXkuoGWpjkTZLm8panUTJLoqSnH/65Z0bRghkAd/A3cNcGExZymBvNc YT7BSnLt93yA4F+49dRnuKEKXfchdOag+SIsr+B3zB88vv5fXOHZyCW+lWUV 6HRQL2bQ1Y9+2bjggDGMtezoRfU5+VhVGvDYlwkH69Y6h+oUF1YSqwbGVX8C WKLYCPaoNqCoL0GaAkeYtPN/O0xvYElTHAQ8tHsBopJMJpMQ9YoV33XnZXhl 37UvEsmsHAXA3yl6cNCDInc+rA772pD8Pu4WVrsnxA8kvLFi9jXzNzB2PRpW iQD7rKZJIUEZw3K8UJnCW5LjTNpxPz6y847dLHw3Sz/2ceY1Xujczzx3yGq6 3eN3tse4OQ+jwEypFEatmy1js5X2zQYYfh99PRmMrKDS91PjCCprqDzzVpiw wAmFN9pnPay2K61jaW5iafz9OBsPqMicRqniMseePqvHWcnz4q0VuYgVpdhU HHyheNMMGY7OTgbnMHTHLslPioc25NtoOB77+qk0TEss664Tvl+4TtWRFzO3 /jQe05Y6oRmmw5Fxd2gG52699GsGE+quuZuhaPW7Nsgh0dsWWAubOqT4IVTk kUocNnI3b+tuvlzgLdpi2TUhen/2g8j4jLa+ldLK9OKHSGG/QrdUsdEw8xp+ Qnal1wy/O7OmfU+N/fjhRJ7bJkrPXJDbJ8zlmorcdm2g59h+V2Ti1je2qCE7 fMZWX03mHrpa1D60u2+3qO0t8RyNGm74X/wXYAALbOekDWVuZHN0cmVhbQ1l bmRvYmoNMTMyIDAgb2JqDTQ5MSANZW5kb2JqDTEzMyAwIG9iag08PCAvRmls dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEzMiAwIFIgPj4gDXN0cmVhbQ0K SInEVW1vmzAQ/u5f4Y92JQ5sg4F9W9+kVlsVad6XVlWFFrZRJVABe/v383EJ SZRKJa2yBSk+391zvnt4AHfNLhxTHK/uC0s119pAFPM4MWC5SlLIeFuy0xN2 6lgOueWRvwYjzSGx3NgUEh0Z7pYsGoK+TsTd8PeLCS7dI8sJtYYk1uNXEIgi YzA9QFMpBN2JWdt8hfBcJpCIFsKPUhtcZaA0aEHbDji/rNpOqkj0/GbILaQv k4ilzMGKUvrsTDzgbzQ3vikuWj8UHR6gMm+vTygPKnRYJ/LeXXv6AgXKcne+ RyeFYpsOQWTQbhiMiUHkCAy1q0W1qOpv/P183vq+DSjRyYAWFfmsd1JBLPiZ 5zATDUEg/DxsawJU6M3FTwJAeFWvsD3QCJi0bUxybULHroCUupM9KtGFBKbo vxOouJxmzWjWWJAOc1E+4ahYUY+1tXh4wTUxbc911Ao4n9qBPyu56Wr71Ldl 2Yc3JCCQKh6lfUQR3F7NQjpqJo2/Q03XFxRbrLU8Lw/U1WjSU/AWMZ1ti6n/ Q2ravR/HlQI10Pygfd23z/YwqdTUHg6R0Yqm2femLl8p8ldTc1n8xhdk+q+e sFFN29LZVU1GdFwEy6Ja4JfArvFmPN684NqEJqX/1wr3fwUYAElyCBYNZW5k c3RyZWFtDWVuZG9iag0xMzQgMCBvYmoNOTQ5IA1lbmRvYmoNMTM1IDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTM0IDAgUiA+PiAN c3RyZWFtDQpIiXxVwZLbNgy96ytw6QyZWSuiZMlWb9kkk2YvzWR0a3rgSvRa rSR6JDnp3vrpBQjQ9m6nnZ3xUiQIPDw8gM1D8rFJDNDf0ia7HEyWpdUWtmWR VmBMmeYwu+T+TXLfJG+bpkbD5pDUkOFfDbs6LSvIsyLd7rMCmjHJwgn6ytIs MzU0vKLDH8lv6t77P/vpCVptTLpVfur6tdemSA2ul59B/948UJyK42SwMamp oPkQvBR78rcJrit2+FVXyulMLW7+rk2WlsquvSePhZqWO21KBe2Rv+30xAu3 gBWTDmixVW3caN2gTZ5WarAr3e41xtshOj5fYKQwRp0p6Cq3H50sRts5NoR+ gh/a1LicdYG4MNEYH+zUyergZ7Gyc+c6CDE9+ob3mFmjzRahfIbHZ04O1qMD +8iXvWTs4GD/0nmR7hVMPmUSmbpttbuQV1zJM0zee13i9SPyEvH7A5ab8t9H RolP2qACXZNkE0fcICjLn4fVzQhQzqATR7YbxMPk4JvSpkLsD3pDrs5TtDbV HSWL3vKM9+RfwUG+aaJzjxv9MEArIc9LRG7hb1nl5d0mVvVoZ46HGZ5egJ7h 5ORs8VMKgWqjjnwqgBdGCa8+A8HNG2QQixzJYCULUSvn4iNBE9UPqy2UoAAZ IJWTV0e/yuGgsXK5gtHypZZ+MZGnF/hT+DJwOGcXsnBYewnrLlWwshN0I3sC anXDq6ykuBI1epgv4jifXudlYqXws1LZTyhn3plhiKGjSG5UeW3o8qpJmRCt pU5TLYHKFWMsqBl7XuGYINUjP36GYBrAFGqzHG++qKk4szy2G5FgV05hp45O /LhAMC6Y4oIBU6cHH/48dNcuP/BlCRJaNzauh2f248+ipkJdqtuG+aE6vtcL hjCocEyBF7+hTJ/0PmIIAi3VSHngZAs+/qu9zYXKrGYqf8H2FkJ2VG74GjYc z7fQ33XQSE/TuCZqcepgj1W4XGfLdm0cckuwduJuHcRPxxs0ougcPoQgHzVd YQS/6h3afQq/78I+2NmBROfrQx9ZZglVKCGLjR4YwJbyI1rjxdm9gHFNQW5N S3p5ROrbR6Sg+cdU5YGqjEhSX+zz6KYVX57mj/95eP6t03cI7mSl5CNjmqSu C8IU4Vou5OpEgT68PFHeojyRE3vx3Y3WIWhanHwXwfIX+Xq80SvwdXyAhMie NwRb11tB5wZBTR7oCdgpketnsDTDWXSYQ/siYH+iaCuK9Spq0W0/jyEtLEPQ 6FuswT8CDAAVlfyMDWVuZHN0cmVhbQ1lbmRvYmoNMTM2IDAgb2JqDTU1OSAN ZW5kb2JqDTEzNyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDEzNiAwIFIgPj4gDXN0cmVhbQ0KSImUUz1v3DAM3f0rOEpFrerTltc0 HZqlQ7UFReD47Ds1Fxm1fQnu35ey5F6KBEUDD6JJ8ZHvUXQ3BYdSMKGUAndd cMa5asB16HbPxS3x4YkKzioyUs4E8V366xnQH+6m+OScBgFuKBSrLPANQ9qI UUaTVwnpawAqFNOkDbQUipypagh07dxDC91EDVOkp0LiscNaivglJ3Rtiu7A z/DXxV8nv/2XAuMDFYbZtVdFUgT2p5zeppyw5OQ1J5d4RrvB8xB/kV6A+3FM 9oMPe0aFJvCN1pi2UMkMOfQTFRbDW6aPV+b+YwYMY0R4SJUQIcn1xRUCPaiU wCSrQdWWCQkoVFPB1BdDceWKBnXk0EDdMFPhTc605Tiex1VaUa/jicqapGw3 hsFPj+3iY7mGjOHCqo5DOx7hPoZM5CzRg6WW0xRQCMEkyo31LWFbi7kux0OC kNXrDnHsVRr71qvkJtF60eyfZ4Qqu58reYjf3BW1BMOZ1KANagxaMRnBrz68 5m9j5Q0xfnNiry4vzOYXBof2iTasJj3sTonw8bw6IIxp7GZjC8shSwLdemUM Ox/1sGTxYwqFdMy0VBFjGCdYcMwo2SGB5ITtwpRLzP2U+mgvUHlhmijjSi8a iWGFT4G/rVlaTq2ruFgrWRlv3JLPfsFRGhzymQqcELm7w4coV+Pd1sVzjaZG Ru3Sv5XxX3Df/T5boV3iquMGnCZaVnHn3gv2wvPvhIuRX/FvAQYAslYcbQ1l bmRzdHJlYW0NZW5kb2JqDTEzOCAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0 ZSANL1NBIGZhbHNlIA0vU00gMC4wMiANL1RSIC9JZGVudGl0eSANPj4gDWVu ZG9iag0xMzkgMCBvYmoNWyANL1NlcGFyYXRpb24gL1BBTlRPTkUjMjAzMDEj MjBDVkMgMjQ0IDAgUiAxNDAgMCBSIA1dDWVuZG9iag0xNDAgMCBvYmoNPDwg L0Z1bmN0aW9uVHlwZSAwIC9Eb21haW4gWyAwIDEgXSAvUmFuZ2UgWyAwIDEg MCAxIDAgMSBdIC9CaXRzUGVyU2FtcGxlIDggDS9TaXplIFsgMjU1IF0gL0xl bmd0aCA3MTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIks wldQknEAAHB77rGnXrruuq6rq6uurq6urrr2vOoa17zKa+feA7fmHoHm3jOW HzI/2SJTEAFBhqIIiIIismSo/bV+99va2toENzfDG5vh8EYIDG0Eg+FAMLwe CPnXQ35/yOcPen1BjzfgBj2BNdC97nKvr7r8Tpd/ZRX0LTt9jhWvfdm75PCA i3aPze5ZWHJbF90W0LZmtq3NW10mq2vO6pq1bDeaV2fmV6dNToPJqQfnnLo5 p9a4MmVc0cwsq3eqDA5QqXcoQJ19QmeXa5fGp7bLNItSzeLYpA2UTNrEqu0i 5YJQYRVMbOfLLaNyC2/cMiIzg1ypmSM1s8fmWZJ5Jig2McQmusg0LJyDBbO0 nVT+LIU/S+YZSTwjcWRmaCeBMw1xpgfZ03iQZcCxDFimHsPQo0G67g9dNwBr +2FtH0ib6qVN9VA13RRNF0XdRVZ3ktUdJHU7abKNqGoFh1QtBFUzQdkEKRsh ZQNeUY9X/MYp6nCKWuwECjOBxMiRaPkvtLx6YBys6pdV9ssq+mXlfbKyXmlp j7QE7B4r7h4rArskhV2Sgk5Jfqckr0Oc2y7OAdtE2W2irFYRolWY2SLMAJsF 6c2CtCZBaiM/pZGf3DCaBNaPJvzmxYN1vLg6XmztSEztSDSKG4Xi/kBxvyO5 35DcrzWcLzWczzXsT9Xsj2AVO7KKFVnJ+lDJel/BfFfBfFvOfFPGeF3GeFXK eFnKeFHCeF5Cf1ZCf1pMf1JMf/xz+FHR8MMi+EEhfL8QvlcA3y2A7+TTbufT buVRb+ZRb+RSr+dSruVQrmaTr2STL2eRL2WRLyJIFxCk8wjiuUzi2UzimYyh 0+lDp9IJJ9MIJ9IIx9MIx1KhoynQkRTocDJ0KBk6mAwdSBrcnzS4LxG/NxG/ JwG/OwG3Kx4XAcaB2IhYbEQM5v/onVHof/8KMABubxTrDWVuZHN0cmVhbQ1l bmRvYmoNMTQxIDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5 cGUxIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMjUwIA0vV2lkdGhzIFsg Mjc4IDI1OSA0MjYgNTU2IDU1NiA5MjYgNjMwIDI3OCAyNTkgMjU5IDM1MiA2 MDAgMjc4IDM4OSAyNzggMzMzIDU1NiANNTU2IDU1NiA1NTYgNTU2IDU1NiA1 NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCA2MDAgNjAwIDYwMCA1NTYgODAwIA02 NjcgNjg1IDcyMiA3MDQgNjExIDU3NCA3NTkgNzIyIDI1OSA1MTkgNjY3IDU1 NiA4NzAgNzIyIDc1OSA2NDggDTc1OSA2ODUgNjQ4IDU3NCA3MjIgNjExIDky NiA2MTEgNjExIDYxMSAyNTkgMzMzIDI1OSA2MDAgNTAwIDIyMiANNTE5IDU5 MyA1MzcgNTkzIDUzNyAyOTYgNTc0IDU1NiAyMjIgMjIyIDQ4MSAyMjIgODUy IDU1NiA1NzQgNTkzIA01OTMgMzMzIDQ4MSAzMTUgNTU2IDQ4MSA3NTkgNDgx IDQ4MSA0NDQgMzMzIDIyMiAzMzMgNjAwIDAgMCAwIDAgDTAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDIyMiAwIDAgMCAwIDAg MCAwIDI3OCANMCA1NTYgNTU2IDAgMCAwIDAgMjIyIDgwMCAwIDAgMCAzODkg MCAwIDAgNjAwIDAgMCAyMjIgNTU2IDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgNzIyIDAgNjExIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDc1OSANMCA3NTkgMCAwIDAgMCAwIDAgNTM3IDUxOSA1MTkgMCAwIDUxOSAw IDAgMCA1MzcgNTM3IDAgMCAwIDAgMCAwIA0wIDU1NiAwIDU3NCAwIDAgMCAw IDU3NCAwIDU1NiBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jh c2VGb250IC9IZWx2ZXRpY2FOZXVlLUl0YWxpYyANL0ZvbnREZXNjcmlwdG9y IDE0OCAwIFIgDT4+IA1lbmRvYmoNMTQyIDAgb2JqDTw8IA0vVHlwZSAvRm9u dCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIg MTgxIA0vV2lkdGhzIFsgMjc4IDI5NiA0ODEgNTU2IDU1NiA5NjMgNjg1IDI3 OCAyOTYgMjk2IDQwNyA2MDAgMjc4IDQwNyAyNzggMzg5IDU1NiANNTU2IDU1 NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCA2MDAgNjAw IDYwMCA1NzQgODAwIA02ODUgNzIyIDc0MSA3NDEgNjY3IDU5MyA3NTkgNzQx IDI5NiA1NTYgNzIyIDU3NCA5MDcgNzQxIDc3OCA2NjcgDTc3OCA3MjIgNjQ4 IDYxMSA3NDEgNjMwIDk0NCA2NjcgNjQ4IDY0OCAzMzMgMzg5IDMzMyA2MDAg NTAwIDI1OSANNTc0IDYxMSA1NTYgNjExIDU3NCAzNTIgNjExIDYxMSAyNTkg MjU5IDU1NiAyNTkgOTA3IDYxMSA1OTMgNjExIA02MTEgMzg5IDUxOSAzNzAg NjExIDUxOSA4MTUgNTE5IDUxOSA1MDAgMzMzIDIyMiAzMzMgNjAwIDI3OCAy NzggDTI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAy NzggMjc4IDI3OCAyNzggMjc4IDI3OCANMjc4IDI3OCAyNzggMjc4IDI3OCAy NzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IA0y NzggNTU2IDU1NiAyNzggMjc4IDI3OCAyNzggMjc4IDgwMCAyNzggMjc4IDI3 OCAyNzggMjc4IDI3OCAyNzggDTYwMCAyNzggMjc4IDI3OCA2MTEgXSANL0Vu Y29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvS0hJS0JEK0hl bHZldGljYU5ldWUtQm9sZEl0YWxpYyANL0ZvbnREZXNjcmlwdG9yIDE1MCAw IFIgDT4+IA1lbmRvYmoNMTQzIDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1 YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hhciAxIA0vV2lk dGhzIFsgNzUwIF0gDS9FbmNvZGluZyAxNTcgMCBSIA0vQmFzZUZvbnQgL0tI SUtDRytFdXJvU2Fucy1SZWd1bGFyIA0vRm9udERlc2NyaXB0b3IgMTUyIDAg UiANL1RvVW5pY29kZSAxNTggMCBSIA0+PiANZW5kb2JqDTE0NCAwIG9iag08 PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAx IA0vTGFzdENoYXIgMSANL1dpZHRocyBbIDc0NCBdIA0vRW5jb2RpbmcgMTU2 IDAgUiANL0Jhc2VGb250IC9LSEpCRkIrTVNUVDMxZDc0NTRkYjNPMTY2MTMz MDIgDS9Gb250RGVzY3JpcHRvciAxNDYgMCBSIA0+PiANZW5kb2JqDTE0NSAw IG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0 Q2hhciAxIA0vTGFzdENoYXIgMSANL1dpZHRocyBbIDU0OSBdIA0vRW5jb2Rp bmcgMTU5IDAgUiANL0Jhc2VGb250IC9LSEpKS0krTVNUVDMxODVhZTIxM2FP MTg0MDkwMDIgDS9Gb250RGVzY3JpcHRvciAxNTQgMCBSIA0vVG9Vbmljb2Rl IDE2MCAwIFIgDT4+IA1lbmRvYmoNMTQ2IDAgb2JqDTw8IA0vVHlwZSAvRm9u dERlc2NyaXB0b3IgDS9Bc2NlbnQgMCANL0NhcEhlaWdodCAwIA0vRGVzY2Vu dCAwIA0vRmxhZ3MgNCANL0ZvbnRCQm94IFsgNjIgMCA2NjAgNzIzIF0gDS9G b250TmFtZSAvS0hKQkZCK01TVFQzMWQ3NDU0ZGIzTzE2NjEzMzAyIA0vSXRh bGljQW5nbGUgMCANL1N0ZW1WIDAgDS9DaGFyU2V0ICgvY2lyY2xlNikNL0Zv bnRGaWxlMyAxNDcgMCBSIA0+PiANZW5kb2JqDTE0NyAwIG9iag08PCAvRmls dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDIyNiAvU3VidHlwZSAvVHlwZTFD ID4+IA1zdHJlYW0NCkiJYmRgYWRgZGSU9/bwcnJz0vYNDgkxNkwxNzE1SUky 9jc0MzM0NjYwAinR/SHDI/ZduFuG1V2G9QSr3AIGj6bG/93dcAYP+3ch/u+i gt3fJwgxMDEycsgnZxYl56Sa4TKUgYGxHaRQtuzXhO8iYkBTf06U+WXB/lfw u4joj4kyLCf+TGTjk2H9/N3hZ4Xod/Mj3+W/s3/nkPvOAaTkj343l/5u9l0+ 8DeQK/+d4zfH0d/yv82lflsEAmkgVw5IsP+WD/ptJv3b/Lf8EaASdvnfQAOC gOZYSPEBBBgAsD9agg1lbmRzdHJlYW0NZW5kb2JqDTE0OCAwIG9iag08PCAN L1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDcxNCANL0NhcEhlaWdo dCA3MTQgDS9EZXNjZW50IC0xOTggDS9GbGFncyA5NiANL0ZvbnRCQm94IFsg LTE2NiAtMjE0IDExMDYgOTU3IF0gDS9Gb250TmFtZSAvSGVsdmV0aWNhTmV1 ZS1JdGFsaWMgDS9JdGFsaWNBbmdsZSAtMTIgDS9TdGVtViA4NSANL1hIZWln aHQgNTE3IA0+PiANZW5kb2JqDTE1MCAwIG9iag08PCANL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yIA0vQXNjZW50IDcxNCANL0NhcEhlaWdodCA3MTQgDS9EZXNj ZW50IC0xODIgDS9GbGFncyAyNjIyNDAgDS9Gb250QkJveCBbIC0xNjYgLTIx OCAxMTI5IDk3NSBdIA0vRm9udE5hbWUgL0tISUtCRCtIZWx2ZXRpY2FOZXVl LUJvbGRJdGFsaWMgDS9JdGFsaWNBbmdsZSAtMTIgDS9TdGVtViAxNDIgDS9Y SGVpZ2h0IDUxNyANL0NoYXJTZXQgKC9hL3BlcmlvZC9yL3NwYWNlL2gvVi9n L3NsYXNoL3MvaS9wYXJlbmxlZnQvVy90L2VpZ2h0L3VuZGVyc2NvcmUvcGFy ZW5yaVwNZ2h0L24vdS9vbmUvay9IL0Ivdi90d28vbS9jb2xvbi9iL2wvdy90 aHJlZS9vL2MvVC95L3AveC9lL2h5cGhlbi9kL0Yvei9mXA0vSSkNL0ZvbnRG aWxlMyAxNTEgMCBSIA0+PiANZW5kb2JqDTE1MSAwIG9iag08PCAvRmlsdGVy IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMwNDIgL1N1YnR5cGUgL1R5cGUxQyA+ PiANc3RyZWFtDQpIiXRVa1RT2RW+N8k9BKVRcg1CIrlXQAVRJCgiiKCARRQR AaeIiPKIGkWiEBJRGYY10xEGUbRaFWXA+mCWstRaxQeCIjKAVUdHcRRf41JH F3VqZ9qVfXEzqz2Bdqb90ZXkrOSe/e39fXt/54RlFDKGZVlx3py4eVEx/nOM uVajxZSdmWAsNE6MMufmxFkyc03ZjphQScdIo1jJUybp5dIIRYmLTBJc3DAM 897/9D6b09ex/6yoGFxdnODpMMnFtWPUrz5WMxzLKmvOtj0KDDQEGAKDos3r ivJNK1dZRN9sP9EQOm3aBLqGBg6sk8VZOeYso5hcVGAxri0Q4/KyzfnrzPmZ FmNOgCjOys0VkxzYAjHJWGDMt9KnP5MWTQVipmjJz8wxrs3MXyOaV4jxpjyz pWidcSINyhVnxYqZeTmTzPmiiSYoKMwqMOWYMvNNxoL/ShIyVXQIFweV//Lc 0ZL/2x+GpS/GmWVUMkYtYzwYRscw3gwzjmH8WCaYYUJYZibDRCmZeI5JVjIT aNsZBePERDCFzDamnmll3rIz2FOyWbLNsu/lgnyxvEC+X96u8FBMUDRzAmfi rhGBZJHHTn5OGU57nP6oHK/cqGx1Fp2Nzg+HTBpSOuTYkPdDZw39eOhJzFM5 3ukYbH0/xsYeAXc5VPeZNeiLiZPRgFu1IUdw4slpemCI7XnRyxdaKL0K8RAF RfpfYOBMcXtxrgZ8IfEFGGCr9tl6mLjyqR4ZUhtcEzRZi6UpGI9RSGFBsApU 7FF4JD8KqzTQSo6AisNWQplUQAD7ISTLP3RzYSCINEAAh0FEJW639n1kY8sl T3n5Rg0QAsf7PuKQEFVHnVVKs4NgY99KQ+TSmr5EDSpJKrLh+V6fWkR3iCT+ /Wkc+NPQClBJq2llaQp4ySFWStE82Hbp1gNdR5N5dgAyy2NzBPSMQo+YEoxW SvtJvYPW9wRYcIKznZCphTGjbyKPwaP9MLxYr+ooprpXv4M54KyWZODnA578 G8iFOxr+dgtpa1yfEJa4NHJa9tUnuwTUEQwt/TYIInQwCTy6IfTOupaYg0Kl E7/qwf6r159oYRQOvYgKHOcTghOtetCRngOnzjzStZxftyAqypqwVVhONRTb YWNvkRU22NU28FoEPCwAr7HA8xdBBUs1fM/jzjP3v7yxMjJqUcY0PX9xXuKZ WwLfuAg6NYmnlzRZ9OVO/EU/S0SKqEUXYIPBH3xAfALed9LuL9ijp3QuPNp/ 9d4t7d+nPkMPPd9IjaCMwBEC3w28W+e5U/far+TFLUxeuXBJ3B++0g+ODNIh QE3HhslQQz/J/G2+7n8nyM+BzWDXuDD0+2oM4OiOCqx0IJBqX3YOpoNKLZWC ATVg4B/AGvhaAwHk2q3fzoz8TU6MgIsJzkaVRnIl4A1uPTBJ4H1vG9tjaxyE pzzb3Xz/Me1f0DH01uMVAmoaC2Gk5fiGRQIfMz9tTZIef01Ub+us0ERLhoI7 u6VvnHyLGxjIdWjioH3Qgl+SExDKwY/kC3Dn+qsoxXIK6QR3OGqjiDIHIojc gE4OzpK52OmQAf59GQ6FC/Eoh2dJOxwdcCym11n7MigKugZR/4lTUcP2UAKt fQo5BA7sqKQeDlZTu9Gib4gZ3Tmw0NrawQx3+0bI+9L7MjQYQvBQfwNXTtKl Bg4N5MlPGRzMJioppYL2PsIq7YTlFTb1PZgKx4DwKe/LHSgDwbz+GoriG4qk Gg7HE7T219LfpVKtI8slRxbKIl/ayVWSmv6dHAQS1XZ0bWYrpDI5uiqksub+ MqJ6WNwb9hi87oO+V/0JeNFLwDMW3PmN8FdI0/AXkzflJUzWZa34/PSNlr2t O4Qz2xq3nqxT4nRQaC7vOn+oRXeytSQ1Ln4najcJOGzzzPm+2uir84DT85+0 d9adO01HlQpeTmW7yvfs0tZWHq+q0fPqC5DD7The1XBQC8pKdK2dpENnlGWh W5GgKrZHW6VwO8yzqaUI8OI3wEMpXHOvfvFcgS8LykBenGu8cF3Pb3jdCG4g 1+Or/nANjCT8+QOPqdTowzctX+sg5jU1xBRwSXmHI2OzrEuWCeXkClRx6DV4 3J7Z2d1ULVUsl47BdxrwLPNpQ7UOE0bjOIxB/+cx9AhpX3WDplGgoNRNKzPi ddHrm7tenqJlma6G/AQH14A3NJWD6+4Bqj+6gee/TeFFkvBzOpBrhfFHFugw ORAjMULgv8Dh96bD8Osdh9qO6yvLuSTo19xuWBoXtBjdRs8xXen6rglc7QKd ix1GvgKZg+co2AGecukwWDRVh7fV12th/Phv0IfSZDEAQ3Hc63DQg193FyjP 62nh1VazMUkXseJMx+8qdm3dK1S/0rTX/enyI93TvUkfCCr0oW4N6/2LnT0g +coPuIEXeSmFcT+Q2l5uLOmo/uzkHV31/vLPqoWDP3BVubnbcnXoVxCD7mZh KrFN4J7Rg5DaC6wdut4E2NUbwGs0Ff+ST4FrdFK3G9LnTk5Ddkzc2iudT5tB 0SvwPnD6jQZHUfduCqct+Spv4eEYHYZNwGD0R/6bEBjWfvHQpVMC7QdfNta8 PtygW5p28HKlo/M4HJQZ/4DInptgOKF3HLQQUNCOs9IY8JOXONi3Qz13t/rc 3ee6hhOFucWfmrZsFuKxjaNbf4Y2bnvN75vrtK8+uOQXkLxsbaHe4YTdA07A Uppun+0dvepLoAlnwAz+bzSjNwGZtI9Db8L7wnxY7LjhvMl6dObo1sCf0z4b rLWxJdKLQQInILz7+re4yXHI0AO6/8Vo1cY2VYVhCn0P7oMGe9c5e2O7FIHd OBWCg2Rqx1IcyEBg4Kx8jBmDzo3gyLDbSudAibNsZbIUyMXF2rJl64BQv4gD IaIj4gx+MPkQgiY4Y12cTsS+ZzmXzPduy/jjD3OTm9x7cp73POc8z/scaotu EC4mSsXT/sB1njFRTfd+PZ4Ym4bZY0Ix8Yd1WoMKGs3Dz6AifTtOKwpSrFc9 fvWyfKy9avNOf73fZ18srunL0Af/c0jn3AN7u4JHDlv78z7KfTL/heIy25f1 7o7lcn7hllWl5ARp5dvfA52HaaKsvpkTZTuo7P/az/ynthRtsI3i9Y3i/X7H Wi1krX24ie4c8YVkpZUI9F6KStZ3wkF3BiCbuWzoSL/RjWl/X4yWFDyyQXdA 2WfnKH9yPEgt4CddXvwxElec8uMyievro8XL56wTd2cWlHef7z+F6f/YNbN2 00IrO4PNsIcVhXu3fiHj6l8wD5043XVNTF+2omp1hd0fAClL/QrEfXTxINoz MFkkY4a5nheN8z6JtSBl/vzO+9fRIIdCbzSE7J1og4Cvrskn5z2xadEYyMJ3 40C5b4rUDSAOmF/DjEeJLQE4qG3GpTW8hk+24L2BWYcFyLOF5Tlhyv3w5Qvb yPpoKIOunaEdL1rXr/eVri2OnLC1igzPVDENU54fwhSUTmLajRXH8tps0ppF EVh30KtGrLGYeupM29aNTbQvVM6IfQOG0yR97B2ebyH1VIi5MIe9kg1xiqso NNS+WfuqdYH/gue8HI0G9nTaD+Fk8Hu9u72yp7Ip1hwIBvbbdQcMsfAAzGSm OjQqg3xBtfkQaaCS/8hVHXaV0GXg8m105cjlZeEu9a2jzQftvXT+NFhIamio 3fGsxzr307WDF8919nTbAiSD7S5AkkFk1CKGKN83hX+gw1E8FWpGsn4FN4KY xb7RVMD5FId9jfggbQGO4EMUcvyBIck9fGl8Rq64rQdc53a8DeJ+JuZpk+i7 mk8CMZP16AgKox4/ogecGAHMosKN6BSKB497/kCFAJ38lrRZivEOHXIeo5RR ilABkc0wSeyiJwqYw6h5Oi8JJyAVvQfDYIqIpZjEr1YblvGbdxgs1hjVL+FM Z/CrFoTKmtdLl9RU762Rq0Qy7G5rb2iTEx+H+j+xm5obE/h5wuDmp6e40/lL LJIA8R7DH/Bs+BZoBWxbJmCAiSviLJi8rcMlraJcxccbGbYG/wpqV9Sp4z8P 3IXtLX+2aL8dSEokoyMlkZqKjtRpTakmjml8l+VfAQYAtdxe8w1lbmRzdHJl YW0NZW5kb2JqDTE1MiAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9y IA0vQXNjZW50IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgMCANL0ZsYWdz IDQgDS9Gb250QkJveCBbIDkgLTEyIDcwOSA2ODUgXSANL0ZvbnROYW1lIC9L SElLQ0crRXVyb1NhbnMtUmVndWxhciANL0l0YWxpY0FuZ2xlIDAgDS9TdGVt ViA2OCANL0NoYXJTZXQgKC9FdXJvLjAzNykNL0ZvbnRGaWxlMyAxNTMgMCBS IA0+PiANZW5kb2JqDTE1MyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29k ZSAvTGVuZ3RoIDM1NiAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJ YmRgYWJgZGSU8Pbw9HZ213YtLcoPTswr1g1KTS/NSSwCyZn94Gf4IcP4Q5bp hxzzDwmWH/I8YlPqf0b+dGSVW8D4v7sbQvKwf88T+F7I/71EcOoPTiEGVkZG Tp/YtDKQkXoGxubO+QWVRZnpGSUKGsmaCoaWlhYKjin5SakKwZXFJam5xQqe ecn5RQX5RYklqSl6Co45OQpg5cUKRanFqUVlQEGQUQog5ylAnQcXwHA3AwOj KwNjOwMTIyPLhO99fD+b6k99Dzl16tT3oFOM35nOM/+M/HFT9HSo+mYd6d+W v6V1fhulyVuw5fqwfmDrqutuapRq6m7qqZNzAQl9Z2X7bbThu7TWdxPppw82 bN4r/4DdP9I6xVD6t5j61e9c6fLff7CtPMX6R4Wta1rXlKlSU3um9syQ++EI Fgxk+86w6v3d74LS7+8k+u+R56uf/tN0OtsprvPcAAEGAJBEk1INZW5kc3Ry ZWFtDWVuZG9iag0xNTQgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRv ciANL0FzY2VudCAwIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IDAgDS9GbGFn cyA0IA0vRm9udEJCb3ggWyAxNyAwIDU1MCA2MjUgXSANL0ZvbnROYW1lIC9L SEpKS0krTVNUVDMxODVhZTIxM2FPMTg0MDkwMDIgDS9JdGFsaWNBbmdsZSAw IA0vU3RlbVYgMCANL0NoYXJTZXQgKC9jb25ncnVlbnQpDS9Gb250RmlsZTMg MTU1IDAgUiANPj4gDWVuZG9iag0xNTUgMCBvYmoNPDwgL0ZpbHRlciAvRmxh dGVEZWNvZGUgL0xlbmd0aCAyNzIgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3Ry ZWFtDQpIiWJkYGFiYGRklPf28PLy9tT2DQ4JMTa0ME1MNTI0TvQ3tDAxsDQw MAIp0f4hwyO2vvvXbxlWBla5BQweTY3/u7vhDB7270L830UFu79vEmJgYmTk UkzOz0svKk3NK8FlKAMDYztIqcwMGZazn8SA5v6aIvObgf1fyWrRXyEyLAf+ hbDx/frxa/KvRaJ72Gp/M2ZbhYdzhIX7FbpKZ6VOmpkonzjTc43RXo69Ru5L oqXjU6qzs+Szsstim/w44timf2dYc3v/QY4D+48uOyu9Zktz9W759fUXMz8H cyTePF2+V3rbuhnLlsuvX7tw19TjHP/y/pwS/bVO6986tt8rWH6t0wAy+AAC DADGmGxnDWVuZHN0cmVhbQ1lbmRvYmoNMTU2IDAgb2JqDTw8IA0vVHlwZSAv RW5jb2RpbmcgDS9EaWZmZXJlbmNlcyBbIDEgL2NpcmNsZTYgXSANPj4gDWVu ZG9iag0xNTcgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVu Y2VzIFsgMSAvRXVyby4wMzcgXSANPj4gDWVuZG9iag0xNTggMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyMTkgPj4gDXN0cmVhbQ0K SIlkkE1rwzAMhu/5FTq2lOKk5xAYaQ859IOl2921lWBIZCPbh/772enHGDtI IL167UcSbbfvyAQQF7aqxwCDIc3obWSFcMPREFQ70EaFZ7VkNUsHIpn7uw84 dzRYqOtCfCbRB77D6hDZ9pL8NrXiJHlTrkGcWSMbGmF1rb6+U6OPzk04IwUo oWlA41CI9ijdSc4I4v8jy0T1hLAavZMKWdKIUJdV80hI+q/2ctyGR/k7Wu/K j7YpkuOlZXPe7k2hInMCXE6wsGUGQ/i+krMuf5mj+BFgAHmVcNENZW5kc3Ry ZWFtDWVuZG9iag0xNTkgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0Rp ZmZlcmVuY2VzIFsgMSAvY29uZ3J1ZW50IF0gDT4+IA1lbmRvYmoNMTYwIDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjI4ID4+IA1z dHJlYW0NCkiJdJA9j8IwDIb3/gqPnG7IByBxUtWFWzpwoGu5PSRuFemaRG46 8O9JypcYGGzJef06j8229XftbAR2IK8bjNBZZwhHP5FGOGFvHQgJxup4q+as BxWAJXNzHiMOtes8lGXBfpM4RjrDYte07VJs1gqlWKq92Kz4F+fyk38A25NB sq6HRSuOf+mhmUL4xwFdBA5VBQa7gm13KvyoAYG9nTU3ihuSNzgGpZGU6xFK LqprQmdetbvj1F3LZ2sp5WpdFclx17I57/qA0RNR4pwPMiNmBuvwcbPgQ/4y R3ERYAA07m/UDWVuZHN0cmVhbQ1lbmRvYmoNMTYxIDAgb2JqDVsgDS9TZXBh cmF0aW9uIC9BbGwgMTYzIDAgUiAxNjIgMCBSIA1dDWVuZG9iag0xNjIgMCBv YmoNPDwgL0Z1bmN0aW9uVHlwZSAwIC9Eb21haW4gWyAwIDEgXSAvUmFuZ2Ug WyAwIDEgMCAxIDAgMSBdIC9CaXRzUGVyU2FtcGxlIDggDS9TaXplIFsgMjU1 IF0gL0xlbmd0aCA3NjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIn6////v79///z58/vXr18/f/z8/u37t6/fvnz++vnjl48fPn149/Hd 2w9vX79//fLtqxdvXjx7/fzJy6ePXzx5+PzRg6cP7z25f+fxvduP7tx8cPvG /ZvX7t24euf65dtXL926cuHGpfPXL569duHM1XOnLp89een08Yunjl04eeTc 8cNnjx06c+TA6cP7Tx7ae+LAnuP7dx3bt/Ponh2Hd287tGvrwR2bD2zftH/b xr1b1u/ZvG73prW7NqzeuX7VjnUrt69Zvm31si2rlm5euXjT8kUbli1Yv3T+ usXz1i6as3rh7FULZq2cN2P53OnL5kxbOnvqkpmTF8+YtHD6xAXTJsyf2j9v cu/cST2zJ3bPmtA1s79zRl/H9N72ad1tU7tapnQ2T+5omtTeOKG1ob+lrq+5 treppqexuruhqqu+srOuvKOmrL26tLWqpKWyuLmiqKm8sLGsoKE0v74kr644 t7Yop6Ywu6ogqzI/syI3ozwnvSw7rTQrtSQzpTgjuSg9qTAtMT81IS8lLjc5 NicpJjsxJishOjM+Kj02Ii0mPDU6NCUqJDkyODkiKCk8MDEsMCE0ID7EPy7Y LzbINybQJzrAO8rfO9LfK8LPM9zXI8zHPdTbLcTLLdjTNcjDJdDDOcDd2d/N yc/V0dfFwdfZ3sfJztvRzsvB1tPBxsPe2t3Oys3WytXG0sXawtna3MnKzNHS zNHC1MHcxN7c2M7M2NbUyNbE0MbE0NrYwMpI39JQz8JAz9xA10xfx0xPx1RX 20RX21hHy0hb00hL01BLw0BTQ19DXU9DTVddTVdNVUdNRVtVRUtFWVNFSUNZ SUNJUV1JUU1RQVVBQUVBXkVeTllOTklOVlFWVlFGRkFGWl5aSl5KUk5SXE5c TFZMREZEWEZYWFpISFJQUEJAUJxfQIyfX5SPT5iXV4iHR5CbR4Cbm5+Lm4+T i5eDk4eDg5udg5ONnYONjZ2VlQ2MWFmACAyYmZmZmJlQASMYMGADAAEGAM/H PCYNZW5kc3RyZWFtDWVuZG9iag0xNjMgMCBvYmoNWyANL0NhbFJHQiA8PCAv V2hpdGVQb2ludCBbIDAuOTUwNSAxIDEuMDg5IF0gL0dhbW1hIFsgMi4yMjIy MSAyLjIyMjIxIDIuMjIyMjEgXSANL01hdHJpeCBbIDAuNDEyNCAwLjIxMjYg MC4wMTkzIDAuMzU3NiAwLjcxNTE5IDAuMTE5MiAwLjE4MDUgMC4wNzIyIDAu OTUwNSBdID4+IA0NXQ1lbmRvYmoNMTY0IDAgb2JqDTw8IA0vVHlwZSAvRm9u dCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIg MTgxIA0vV2lkdGhzIFsgMjQwIDI1OCA0MDcgNDgwIDQ4MCA3NTkgNTU2IDI0 MCAyNDEgMjQxIDM1MiA2MDAgMjQwIDM1MiAyNDAgMjc4IDQ4MCANNDgwIDQ4 MCA0ODAgNDgwIDQ4MCA0ODAgNDgwIDQ4MCA0ODAgMjQwIDI0MCA2MDAgNjAw IDYwMCA0NDQgODAwIA01MDAgNTE5IDUxOSA1NTYgNDYzIDQ0NCA1MzcgNTM3 IDIwNCA0MjYgNTAwIDQ0NCA3MDQgNTU2IDU1NiA0ODEgDTU1NiA1MTkgNTAw IDQ2MyA1MTkgNDYyIDcyMiA0ODEgNDYyIDQ2MyAyNTkgMjc4IDI1OSA2MDAg NTAwIDIwNCANNDQ0IDQ2MyA0MjYgNDYzIDQ0NCAyNTkgNDYzIDQ2MyAyMDQg MjA0IDQ0NCAyMDQgNzIyIDQ2MyA0NDQgNDYzIA00NjMgMjk2IDQwNyAyNTkg NDYzIDQwNiA2NDggNDA2IDQwNiAzODkgMjU5IDIyMiAyNTkgNjAwIDI0MCAy NDAgDTI0MCAyNDAgMjQwIDI0MCAyNDAgMjQwIDI0MCAyNDAgMjQwIDI0MCAy NDAgMjQwIDI0MCAyNDAgMjQwIDI0MCANMjQwIDI0MCAyNDAgMjQwIDI0MCAy NDAgMjQwIDI0MCAyNDAgMjQwIDI0MCAyNDAgMjQwIDI0MCAyNDAgMjQwIA0y NDAgNDgwIDQ4MCAyNDAgMjQwIDI0MCAyNDAgMjQwIDgwMCAyNDAgMjQwIDI0 MCAyNDAgMjQwIDI0MCAyNDAgDTYwMCAyNDAgMjQwIDI0MCA0NjMgXSANL0Vu Y29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvTk1ERFBEK0hl bHZldGljYU5ldWUtQ29uZGVuc2VkIA0vRm9udERlc2NyaXB0b3IgMTY1IDAg UiANPj4gDWVuZG9iag0xNjUgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3Jp cHRvciANL0FzY2VudCA3MTQgDS9DYXBIZWlnaHQgNzE0IA0vRGVzY2VudCAt MTc2IA0vRmxhZ3MgMzIgDS9Gb250QkJveCBbIC0xNjQgLTIxMiAxMDAwIDkz MiBdIA0vRm9udE5hbWUgL05NRERQRCtIZWx2ZXRpY2FOZXVlLUNvbmRlbnNl ZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViA4NCANL1hIZWlnaHQgNTM2IA0v Q2hhclNldCAoL29uZS9rL3UvTy9IL0Ivdi90d28vY29sb24vbS9sL2IvQy9R L3cvTi9vL1AvYy9SL0QvVC95L3AveC9lL1MvRy9oeXBoZW4vXA1kL3ovYW1w ZXJzYW5kL2YvVS9JL0YvYS9FL3Ivc3BhY2UvaC9WL2cvcy9zbGFzaC9pL0Ev Vy9ML3QvTS9uKQ0vRm9udEZpbGUzIDE2NiAwIFIgDT4+IA1lbmRvYmoNMTY2 IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzE5MCAv U3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJdJULVNRmFscTZvINLyMl BnWwSawVtKKAaBFXVik+wBUsLwG3ogijIMoo4PAQenwcQZxFWx+t1qpDuyAi dX0VEBEUdWldx2pHLVPLoqR0XA+uni56M/2wu98gxz7O2ZOcfPm+3Jvvd+/9 34Sm1E4UTdNidNTs2W/PnhChW23Q5WWmpUbr1usmhuuz03XZubp0h8mbylBK 8aaVUU7KqyplpFoR3L3wNJzxU/FP0xjBRP/XaHxxdddAy1C490rtKHatJ6Wm 6a0Hjl4I168tzMlcmZEnjUsbLwWGhARIYen65ToprjA3T7cmV4rMTtPnrNXn pObp0idJUtjq1VKswz5XitXl6nIMZPUlnJSZK6VKeTmp6bo1qTlZkn6FtCAz W59XuFYnhc2TUrPT/fU5UibxzV2/PDczPTM1J1OX+yv/qcHSy9h+WXXE/P8S QNHkoDQUxVKUB0V50pQ3Rb3mTE10o95yphYwVJwzNZWkklITo0+pBuoGZafn 02voSvpnp0SnvU6NTh2qOaps1SbVh6qbqp/VUepS9WMmgWlmOpArCkQ5CGvi NPs0j51nOmc5d7sMd3nTJcNlg8stVzfXeNdjrj1u89xK3Brc7rqPcI9y3+Fe j/UsOXtLLCsM9lFmz7/K71phjLXRytVzx2GzkswXfcqsrzP87Zj2zJGa+s+P Zi//c5Y+a7UAGtzLp2fq1sR5c/Vzos9232m8ePkzsf0sX1XJNJ9pbryp7Y0+ FShwx6dHxAUnV6VVpYmVKxmuPjGdiUlJjwzTzj+JR8JbHQ01rW0CZzgXwTxE /sAz1cdrYUirNhSVLticVrLSmZWg3EpfhG2qi1DOwzYr3oZYHLnLYC/KpzdB i2pTCW9GUGwvYiIRazIZlJr2hTDbE7K7uBvXlRoeJvTXdCHuhD1poYa7UeYb snFyqTNrMlqVNgvdIEOWrFLmW3l8Ge1tOnLmVN3j7hHfftV4GSjtl+uAI9oc GxeAtYKMTu8ABuhvqiOjQ1csi10sxCxmZswLC8QjtIpEkPTGp9D01PO2bTi3 7LbyOu9O2Z76I87Uv0P94pY9YzJAkgUePaG3KPtUW7xs6AIkMVCAWnASY0M4 3p7CYFd0yYevQD/gRwyOR2y70QImM2y0eF6RIcc218b1gQ884PtQx1Xd+LlZ CyaJ2B0FhfOwCMH4zr/DWDn9epBJrNBwyrVDp65d04IY2DBJwHokh/P/RvdP LAvDTsGbV4g+5OUlFuWhxfOcDfbaptq4J9wDxZckecq2Yl/JG7MbQAshEHKA DKzIPfmhau70CtGGQCqL7sQ+3jh5FY7DETiiGsfBUpF7AAEXwAO8d4tsr9Gi XLfQ12XYb1OBv92LJ25T9uBxWMDDinAA9hP9B6DfQZDUCHMgApL1MAXniDgO sUYr7LFCnpW+IquueCmvWPFZ2AMHrfgg5MFn1n4GscUkld2/2MjQ/dvn1hJL zBXYaoGTg+FFmrkmrlkpUfbxJ7aXQjhOfckfX4fnQbTINVkvn//ikFiBuKI3 zIpGwzXjdeGIa4LRyG8z9sHsbzMicM3dR+bP2imyVgLTa4XGfAID5UROufYU Pgg34nJoDHqeIkMvlONemWhkt8lgT8kfZLanBJFAjFa7x+CKwlpxvd2DrEI5 MVT30O2y4ier2omtugLB5OdqRiaDXc1UPFcTfzwO4TH9V5lyMihXGTIlmQdX ZRmMcqB8PLCNcoe4FvbfYWAI2bH/ATHeqDxgMEKOtif1p0mCakiZau2r+Zc1 rSM1TYbkOogjtYlYBXE4WQxXA3sAa3EIDtlAht/lQ2QrSR7aiFwtjs1zbQN1 aQMawZB7t2EkpOIgY5SI578QYveJpFC/hKV/El8b4Egy2CcPlKrGxjVyBcqa ZXxza7iZabJ88OxH7SDBIJ3ANQ4CtpzZ90mtEHOB31i0fuu630l2EDagdPr6 BDGyfXECw7YTwq8t8N5ANxU4NN/ngPwa3BCnNF7cOn6X+D5WVWTsWvRR8cin yLDv3cNl324FdkTZFxktUbucSVf1/fNwdadVC8xsM1YLeIMjmj7U2bR0Dhb8 jIniFNLnL9qqVp5hg0I53Mbd4jqUBKWKh+HlUV/hUd44Uo+HR4rcLfwR9IAL TtHOTEieI3DfY770/l0xCGG/5qnwhycwpAlCBO4W7Mc92B2WaL9pOH1b4Dq6 qhNniSyRiIeVhoWyCo7YPXiIsPbHhcK85x7yQGfbX8+nz8tQJqvOQwaPfc0z YAxIN7+HVwVle1D/do2vPmHilMzmPsdUw+4wPlHs+XS5skIFs7xAjSCCfI78 EZb67Q6BSYqdzFg4YAQvJZ4IbLd9kQre8HqGflTuMBXoEVHYMwS+xInw0/3f EScf5TtmNPIZuMc0mTgEX2KOaYd/GcDJ7Fkjz+qC8C6uHjwVV/49zSHjfdul o9nJKcai6AIBM5kM1zTXkJU4Szvh7MLH51trzlULpD0Nc3eeNh7zNlXu/Mv7 YrtmW1lp+UbvdUZTpQitmkvGRzgYD0tMwKwAH+K1PNcUv+id+NiCkxeb9puq PxZOfnJ7V22dM+v4QijTLDAt37OtC5bIXDMRjYn/z8GnPdbDIXgYZvODQgML H4OTwBXPwCb+LuKazRWatA+a0q54g0cLDIcJoC6EP+KxCUnZSwrEctgSjNhV JWZ4aACVmT4mQ2yXShEUF/7LHPLD9MEh67A/0eSCtgDirP0cNPeEYBSzYWa4 z3ZSGki6UNX6D9PbicKv4Y7LsKSLwA0lcDDscKe15+DoMZgtDpoUmt8JwwQ4 qcTywXhLOTpbkPQ/Oqs2Jo4qirKu+4ZgsjYdBiKDs0WLlGKBtMWhUFpFSF0C BQKhWhC0fEhqRaVSykdaqJIWtiuRZqtrgEqriGFrW7CGWIwJipANU2lW+kXJ KNsGlBL8CL2PvDXxzlBi+sNkfsxkct475757zn09+SKLqmHb2MMs6RIzAT/8 TX//SS3T6q2TnFZ82KPAZsVw3gt52DiBcF04xfU6wM870ZmSKVVwXqtwlgOu Hp7E0fcA36fOwmM/IN/iBjlxrQ1WTUlmVoDzdq8CxGOYVI2TQSrdO6PEuMn5 Duc5qc+zkySUv5pgSU+y3uDMLF2BAA9dP5ztQU3JKtaGvwlv00pBF/RQTVys fAgM07pGC/87ZA4LiYS/uaOZu9hQ0J8tstAS9jgLT3Gwl3DSfNs90GGxp5Ky 1njmJ/FXi0o7B49aZMJCnCDYXCL4TQzDZs0ltFKrowEPOUM1DiFHQm6MfjFw 7f0X9kg+otJVnNt2j0n5WfuKqqTlM9SCmrqq/5xbPaIGjyDEJRM+dgoHuTon 69MH/8JubVEjtMO0ADIUmiIJy2I2UzNNkv8pVMFKxlWIZB2m+f+Sf0TFNFeX CmXNSRo1rRpuFZ7VnsBQftCt81NHz/SNr/Aj3AOfy3TDcvNLC/ZLo7VlZzLE XTlv7q6yNBP+ljuRM68sqwvmB/5XcZgOkxB2XYNhb9AUxdDjhTKvsQebjUVd YMEQA9F9eqdHlUIwdkN0CQtmURLG8T4hrnYB/MG/Y+GXO+0RzJ/510RstJhZ zAF4xkPj73NAZ93SnQXmj72zmrUCmFS9Ba21+Le01ZclqNBoJy93DlRcEsFy DrZhcm/KBxPjswuKixs0WXcV5MdkFFZ2JVVt0gzL96AumCG3f7pwsdtxrOWE xH80xfE9re8etteKma+/8uJ+DTk6KXPmXbqy1Z+qz6mQoKaoeh6b6KOCu6UJ /FisGJ2UH8GMlw+OVVn422NVSv3zIdszDr21pebHMez3XDsTIW3h5yEwLVpP p3VhAFu7rB+6Q66OtHWPdpTt0HzQ5KHrFN0E1CVgv/sISf3ktekvu1rtJ6Vx ruVIY3ONWNTQ/rUF7s4q0RCLvHSTV1avHBR9GqEyApN2vlG4/djlryRKZN8q Lt22BsK++/7zwS4t/A6mo4/zbIs0udrgoEF4uwqaIxBOXZjOEb5kTNoImqwn dbZtHmbnDY4lfyOIQfPkDk3DnP7Nl4Z3TeARsInE40cz2Yg/1pFY/T0O3zGl 8/QON3xAJSNsgF4cH6wXYX9B+T1Wrt1Vw6EX1oADN4pkOeshR9sxj6UoSyH3 aW1tEOoKTBWNte+UiAfqjtsPW6xci9PZ7BL/6FImTlkgho4jaINOOWyZcipe G0M9Bjg9Y+yjJQLUEXbU94TJCr962BEO3qOS6Qq7hoVzLhU6Wa4T1joJfNY2 3eYbOsEpAeojtDiQFgn/CjAA2lAWeQ1lbmRzdHJlYW0NZW5kb2JqDTE2NyAw IG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0 Q2hhciAzMiANL0xhc3RDaGFyIDE4MSANL1dpZHRocyBbIDI0MCAyOTYgNDYz IDQ4MCA0ODAgNzc4IDU5MyAyNjAgMjk2IDI5NiAzOTAgNjAwIDI0MCAzNzAg MjQwIDMzMiA0ODAgDTQ4MCA0ODAgNDgwIDQ4MCA0ODAgNDgwIDQ4MCA0ODAg NDgwIDI0MCAyNDAgNjAwIDYwMCA2MDAgNDgxIDgwMCANNTU2IDU1NiA1Mzcg NTc0IDQ4MSA0NjMgNTU2IDU1NiAyNTggNDYzIDUzNyA0NjMgNzQwIDU3NCA1 NTYgNTE5IA01NTYgNTU2IDUxOSA0ODAgNTM4IDUxOSA3NjAgNTM3IDUyMCA0 ODEgMzE1IDMzMiAzMTUgNjAwIDUwMCAyMjIgDTQ4MSA1MDAgNDYzIDUwMCA0 NjMgMjk2IDUwMCA1MDAgMjQwIDI0MCA1MDAgMjQwIDc1OCA1MDAgNDgwIDUw MCANNTAwIDMzMyA0NDQgMjk2IDUwMCA0NDQgNzA0IDQ2MiA0NDQgNDI2IDMx NSAyMjIgMzE1IDYwMCAyNDAgMjQwIA0yNDAgMjQwIDI0MCAyNDAgMjQwIDI0 MCAyNDAgMjQwIDI0MCAyNDAgMjQwIDI0MCAyNDAgMjQwIDI0MCAyNDAgDTI0 MCAyNDAgMjQwIDI0MCAyNDAgMjQwIDI0MCAyNDAgMjQwIDI0MCAyNDAgMjQw IDI0MCAyNDAgMjQwIDI0MCANMjQwIDQ4MCA0ODAgMjQwIDI0MCAyNDAgMjQw IDI0MCA4MDAgMjQwIDI0MCAyNDAgMjQwIDI0MCAyNDAgMjQwIA02MDAgMjQw IDI0MCAyNDAgNTAwIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0v QmFzZUZvbnQgL05NRERJTitIZWx2ZXRpY2FOZXVlLUJvbGRDb25kIA0vRm9u dERlc2NyaXB0b3IgMTY4IDAgUiANPj4gDWVuZG9iag0xNjggMCBvYmoNPDwg DS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA3MTQgDS9DYXBIZWln aHQgNzE0IA0vRGVzY2VudCAtMTc2IA0vRmxhZ3MgMjYyMTc2IA0vRm9udEJC b3ggWyAtMTY0IC0yMjQgMTA2NiA5NjEgXSANL0ZvbnROYW1lIC9OTURESU4r SGVsdmV0aWNhTmV1ZS1Cb2xkQ29uZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVt ViAxMzggDS9YSGVpZ2h0IDUzOCANL0NoYXJTZXQgKC9vbmUvay9IL08vdHdv L20vbC9nL3RocmVlL28vQS9SL2ZvdXIvcC9TL2ZpdmUvQi9hL3NpeC9zcGFj ZS9yL2IvVi9DL3Mvc1wNZXZlbi9XL2MvRC9UL2NvbW1hL3QvZWlnaHQvZS9H L3UvZC9uaW5lL0YvZi9JL3YvRS9jb2xvbi9oL1AvaS9ML3kveC96ZXJvXA0v TS9uKQ0vRm9udEZpbGUzIDE2OSAwIFIgDT4+IA1lbmRvYmoNMTY5IDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzUzNSAvU3VidHlw ZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJdFV7VBNnFp8hyRcEjJhxUuQxExW1 wiFmaRexUlkQEJCHvCy6SAskYHgFE5D6QN2tHkVEaT3VolhAAT0uS4tr1eKj glSLsiC+17J7PLseBcs5ttZ4h17c7pfguv6zJyf5JnPvfN/v97u/e4dl5E4M y7JCQnxEREyCf7SxcI2x1JSTlWAsMwaEmwsNi8zFBntGkDSJkbxYydtJ8pFJ U+SS4KbBYCz95fwvaQqhgf21qmr8100JnZPg4eQ2b/elakbOslsb2roXmUvW Wkx5q0q1b+bM0f5m/ny9NsxgzjZqU9ZaS41FVm1McY7ZUmK2ZJUaDTqtNqyw UJtsz7dqk41Wo2UNvfsKm9Zk1WZpSy1ZBmNRlqVAa87VxpmKzaVrS4zasMXa rGLDXLNFa6LPWsuyrSaDKctiMlpfe37ePK2dmtbOzVhsNRr+F7Lz/j8iMCz9 MBMZZrILM92ZCWAZPcu85cTMY5lwZyZOwaTImeUsE0QFZZwYGTOLsTAHmJ9Y E3vEaZLTFqeTslDZF7I7cnf5avklBavQKVIVpxQPFEg0JJUcJHeVIcrjyhvK fzuHOV+aMG2CcUKni8YlzuW6q5ur3tXkWuH6DzdvN6Nbt9uvE4smtk4cVnGq eNUulaoK9GwneMg6Qc+j/pv1ytx1eau2CpHK55823bZ5gkapiqgYlo4NswfB F/TgK4MgyY2H2P0Xr/QcyMYoYaESYzekxMWvPwFRAvoe43H3eR2EQt5eiIHl sDt9CEMxbzPGYrqgimhYI20fDgCDGmLBl7sG9zTcl6Pp05TctXcrkvICvDYG wLSx7UQVUQVyaYf9VAH86KnSCpDzWE8+aTl8/Kv27295DN48evmRJ6gir+N0 9I8KwzeEEhCUt3d+cuWG1+mm4qXhmwviksWkNMV0v/S3Ue0pRRM7Fdg0vHYN bB9W14OAU8ADptNVTbHcq4ccfrsSvfqDwUfgvob04+D2+MGqq/pasVrJnezb f+LifU+YHNqNU9AzLBJFATxI394zPR2NJTECdy+pLC1RyAgg3N/OkHu1SXHx f3wvMq7i9N8rRTttmE0JpZWztSAHLRUcPod9PGoJ5deoqCZYMzaZhxqcTRHN 7gf5YikN5xDcNJaooKifgBXkGU+AAbnaroiO4j0rvTsay48pCDe4eoxXAE+4 s3+paWw64dV7MB8nzF29Min+o2sdIgofkpCj6ALREHv6OcwFeS4Q9Ba4wYSs 9bklYiXZD79VQO24Oi020A2ra2mtA6guHD3nGSdJaVITDz6VupMzvXDjNkzB DAxrwkBYIXLPIPD6QwgCLmMY1fEZ1lyrWNlGft53547ASWfqCtJEnIXf8T80 tncL3LOLjUb/BR8lRoqcFL350uAOhzRSH7izjVK0rJESQnc4r0QRlyZiXhmG OoM/OQQZ/WCGCTDfGZwcfqT1g3QHTFo6geo5XsIR7mktZPDvHMWp1HnLj8LU wQc5AwsOCLR+I3fqm3vPe4IYchF55ENSUExvjr1TLlQquacL1udEBnpyI9Tg A/zVQ60dHYfyl8SY87OyzK1/Fbinm7Cf76/r7O2tS1scvS41NnZdV5/gAKKz Qcs4EI4CCXDoNXIM5vPoXT30wU9esHE3JMNKCLNAINrlwsAIPQYh1xEA6p6O w18cFqtNZMam0FCBG/n9uj9doCmboYf/fs/lgb69S9/ZKfiXGZNTytp/EOy9 CkbQq2m/vsE1dGrcGGoWPXoQ7gMwyl/9U9VQt/mDC9yislZJF2RVcvAjreCv gGTSinTxI5g0mqnAKPIvdOeryTW8paBWVNVU2aDgCSTa1OfGm502iB8nndPA NkILHdI1AvLH6ZdD9tobQrpe/+Wlu57gE3QKXQTcSsB3Gv8Nud5qWRydVxIi ZpPZ8h762JUOa3BwhiVKTCGqigqb1GJTt9HdI+juApVriPtR2iYV8T9vAH/M xsIS1GERFrWgDgoFbgiS2mEq6ET0JagzlrwXX3QcCiGz7uZNgfuxtyFzhqg6 VGWTdtjYbrppHJ0U3RooJ5DSCQQ+htw88MEMETc70H1HwOmzYKr+svK42eIS ooqsojKl0m8IuLCUs+zcaCb/IlMKABc8SANb6LqFBveAi1L1FpX1yuu5Gnri lddzxmZQDStscx9RCeEPNvVJmhANwhwb10HbtVrawcPMJYMYiHEpOAm3YFUb ekCkwHX0nT188c9iNeHWxdgkHiumPQ5Xch0LU3NNwetp0/8Ooo7cGBC4s98e jl4mOuo7AO7QXG7HQY9+iWUAQnAAfEcz0RebMQSaqWgq/LphzWhmuV0eGazU 2IMvMikZylwacmwgk9I0lMMeaWg8BEmOlvRlL4CHROiouqChF33VBLixPgXI 6Sr1KarH+sCD7mYivmM7FZVkprRTgfkO/rTErL3EK+jebTDKv6wmFLbQwVUE RSWgw8KXlaYW0EBK7a3792vD6FxJrQgPCqq4CamCqoCybLdBkc1B8u3/kmy/ S8D7YR+8+Xz5c5wlYo2jspfJjSM5keEGU7K9rHaBup5Atu2VPrBMesb3k962 /JiFhqIoMZGg79gsnka77pJvm0wp1eJu9Nlp3lVSWz4V9B+Tktptx3fcrgT/ DZ1zPnOuVg7WtV99TF83i3rsZv+cqArGrdxIbezpwGefln7cUCNY+WIlelwN hXkCdxP0j/rB/5/mLmToKJadUSQ0b2w55flV3YlegbvbdcgQLYJQT8BH10Vf K95BEXT0uV5aBlPeF7gHj/NbrbGeiVnm90M/PNknNCgd03KI+s9Bah81K53r +rEh8KV39XaTFlRBgtRUzu6SPpXtonEIfpGpgP/wXa1BTV1B2EjvvWBtBnMJ MknnBNQy1OpIURBftbWgYwcJzwKaOIgvWi0IdC7IQ6jUqaGAD1AmKBWoGMCa KgrIuzzaoB2KjtPiANpq2+kwUvnRwb305Ef3JOrUH+2PTHKS3b3f7tnv280W HoIZ4V/nfeznuaO8r3yeU8Lup7ZlM7kuQDwhkB+TK3EWjdkrOTyAJ3Mh/Fp0 MfEr0QUPKx2Htc6DMjRvYs0Y/CD9MqGygBcVsClxpGK3t8A62U1dKTTXWJrb qtKT9ublJBWQdRInti9JS0ry1bx7adWjoSZz/0WCXS8dO3hMKs92xXma13i0 tksDXwuT+4dp8MKgHdSdHEIu4Gjco47YlrFnT+6lax01F/oryNljteVfmF2V 8Q7GPZmGoExVG4rwa0DEXJSCGjW4VdgGbRV66kbd8vX68HwbuBFKKP6Cotk5 UCIkNFyRerXA9dwHAxji7lMuLllKTNGZQGL5LcfVx3VKUYdRfZAI8maYVIO4 eZyKVPTfQtPo/mHkN/h+Nwo+BKV3hbTLuCW/DxXL/bRtuOdUdBx5Ad5Xz+Gt fwrPNvgMXrjeAQ9VkMFDZhEqmfiWlOTqOC3CCkYZEzupoScYuN4r1V0NWDiG D9beA4+Jf0MsVjcKsGovzKKBNDyValANNGVIQAN42m7DvOOEuvObC7OSjdr4 7Bs3dS3CvZeqha4zA30Dp4yrSomSlmGTRUz8PqUYAeIy4glEjhibWNPON5or msrLPy8qJ38KJekZxenagJh9i3XhoUtvC8p4GvbrcljUNg0P/1jGJJ7Q+TiQ FmI7NMNt2aoWL+lNQn+aoWq3li7Oon5URRP63obZrS11Vy26khA+JnNHNBGv ZuecKD+kEzMOlReaqzRsul1dNhSH0z/w5i1YQOQyQWym9bQJtfR052Df2a10 vn92WGRkwdCPWGyEHsVKrWCd4IX42xA/zPC2uvr2a1VSLLELmM9CYTq+PTDS 8LExjZggh101OlozH8AcVTeQ+d0saSt+LfoPscFKUB/RJt5hBPGZCjRy6XbM CvztTaHzexBoGgdLeLoRRnHHSuYoftZRI2eSX2HBmQQ7nDAyu1teCTsZVlYr BlXlfHm8KnY6ED/hb1gaWpsq07cT+1x2Fl44y1rhr8QB//cSUqIkYuL7co2N YdrIxMytybjPieN91Etw1uJZfCyFePc/aiFed1QjIeP9FIwl3r3JvNnWr5xQ WNDDD3FbsF+pvs0PVpcSCOh9jPzSGx/T1Ud1NCDWj4bpmIDMPjE63F8Vgy2n ORgTvenIKMzGK6HLJAiahifPoDACTP4fP+2RajSTSvjEeqvU85SdOnHcSdDY 3VLCRwzn5ADDSVMwzWC8nzngxcKLlx1ZjvB3es93mCuLisyYvFBceLi4UBu1 64O4VFagW3eYq7cjRVUtuNO5WCCV8138rRZC1FnCopZNeJGuP/cDN76vdUU9 1i/Ywhkr82rqNFcazlmvnzkQS8C9hp+M6Kfz6ILoDQHrmwwjB1C3J5O5C5/U 5iRrElOlHYb0xnZShUDLjkxtYMRSIa3EAyNICSQOHeTFy1Rx7kOYddFSWtpA HglFhwuKCrQ7D59t1kErEg+nJRGcMiJHZT6/zSz4ic1l7FI6w+vTUgxJB6t7 iSxg/diV+nQbHnzb9eU39UwnvB2Nqzgub3SBLFiqNvFvyWoO1wPQ2a0crOBB K1sdih7gtDwpx7hADv7ReweCHHbe1Ix7fAMHi/gxCBmjIewT9YUGXL7NzELp TUOm5L+dD2mjIep+Hjwa6yC8QweechELHmp3xdmxRnZ1RHwDn7zts6zUeG1+ fnFJvk6ZZ57ZbqZRZlhg5qHu5MOT9r4yYXoOkJeL5yrhUw+5Q/2PAAMAKHLs tA1lbmRzdHJlYW0NZW5kb2JqDTE3MCAwIG9iag1bIA0vQ2FsUkdCIDw8IC9X aGl0ZVBvaW50IFsgMC45NTA1IDEgMS4wODkgXSAvR2FtbWEgWyAyLjIyMjIx IDIuMjIyMjEgMi4yMjIyMSBdIA0vTWF0cml4IFsgMC40MTI0IDAuMjEyNiAw LjAxOTMgMC4zNTc2IDAuNzE1MTkgMC4xMTkyIDAuMTgwNSAwLjA3MjIgMC45 NTA1IF0gPj4gDQ1dDWVuZG9iag0xNzEgMCBvYmoNPDwgDS9OYW1lIC9UOCAN L1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMyANL1Jlc291cmNlcyAxOTIg MCBSIA0vRm9udEJCb3ggWyAwIC0zNyAzNiAxMCBdIA0vRm9udE1hdHJpeCBb IDAuMDIgMCAwIC0wLjAyIDAgMCBdIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hh ciAxOSANL0VuY29kaW5nIDE5MSAwIFIgDS9DaGFyUHJvY3MgMTcyIDAgUiAN L1dpZHRocyBbIDMwIDIzIDExIDIzIDExIDAgMTEgNDEgMzAgMjMgOSAyMyAx NCAyMSAyNyA5IDIzIDIzIDIzIF0gDT4+IA1lbmRvYmoNMTcyIDAgb2JqDTw8 IA0vRCAxOTAgMCBSIA0vYSAxODkgMCBSIA0vdCAxODggMCBSIA0vZSAxODcg MCBSIA0vY29sb24gMTg2IDAgUiANL3BlcmlvZCAxODUgMCBSIA0vZWxsaXBz aXMgMTg0IDAgUiANL0ggMTgzIDAgUiANL28gMTgyIDAgUiANL2wgMTgxIDAg UiANL2QgMTgwIDAgUiANL3IgMTc5IDAgUiANL3MgMTc4IDAgUiANL1MgMTc3 IDAgUiANL2kgMTc2IDAgUiANL2cgMTc1IDAgUiANL24gMTc0IDAgUiANL3Ug MTczIDAgUiANPj4gDWVuZG9iag0xNzMgMCBvYmoNPDwgL0xlbmd0aCAxMTIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkyMlYwUDBW0DUy UzAyUDBUSDHkLeQ1NAcKGgAFzYFShgrJubxOnrz64QqG5rz6HgpGQNIpwFnB kFff01ehpKg0ldfThZf/Rz2Z6EM9OxA9qG8+UN/AUX+Ao/6BRP2H+v+8rp68 gbwAAQYAcz845Q1lbmRzdHJlYW0NZW5kb2JqDTE3NCAwIG9iag08PCAvTGVu Z3RoIDEwNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiTIy VjBQMFbQNTJXMDIAMlMMeQt5Dc0VQGyQIEg6OZfXyZNXP1zB0JxX30PBCEg6 BTgrGPLqe/oqlBSVpvJ6uvD+Z//Pw/yfg/E/B8N/xgf/mT/UswPRj3p+chGv qydvIC9AgAEAOKA3/Q1lbmRzdHJlYW0NZW5kb2JqDTE3NSAwIG9iag08PCAv TGVuZ3RoIDE2MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iTIyVjBQMFLQNTJXMDJQMDRQSDHkLeQ1tACKGijoGgNFQYLJubxOnrz64QqG Frz6HgrG5rz6TgHOCoa8+p6+CiVFpam8ni68f+T/f+Cxf8Bif4DB/uAD++YP 9u0/QIj9hz3/H5yI/QdUGVA9UNcDBpAJQHP+yNj//wNC8/8AZeubf9QffFB/ gOH/A8b/H5j//+H/z+vqyRvICxBgAF2pSoUNZW5kc3RyZWFtDWVuZG9iag0x NzYgMCBvYmoNPDwgL0xlbmd0aCA4NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIibJUMFAwUtA1NlMwA7JSDHkLeU2ADAOwkBGQTs7ldfLk 1Q9XMOHV91AwNuPVdwpwVjDk1ff0VSgpKk3l9XTh5QeB/yDAjxPwunryBvIC BBgA5WsVrQ1lbmRzdHJlYW0NZW5kb2JqDTE3NyAwIG9iag08PCAvTGVuZ3Ro IDE3MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiTSLMQrC MBhGUxwy/eQI/S8gbVKk3QpVwQ6CTh5AHR0UXe2QIdey9CLpDTp2KHxGRXjL 9x6fyTllw/MsZ7NgzSdNVzJZkGmQRUiajxeqakoObDJKNpwVlFS7JWtK6i3f b48z1StChFE0gyi9iF+TaiE7OAfr0P1BoANawDfwCkOESZQQ8WeMEpgBNnSF /odE79BbtBZdC+uf0gs1iPj7Aq1r2tNbgAEAhjJZ3A1lbmRzdHJlYW0NZW5k b2JqDTE3OCAwIG9iag08PCAvTGVuZ3RoIDE1OCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiRTIMQrCMBjF8ZQOnT56BL8LSPt1sU6BqmAG QScPoI4Ois5BOuRa9QReIUfIGCHwjPDn8fh1wi0Lz7sFyzKfs9CNpM/YZuyz CJ+uNBhqjiw9NVvu8g77FQs1ZseP+/NCZk2pRijhC0wKb48xWBet+8Lh3whM uRl8iagAZeEtokbSn6TrpKukXdSvYCeVQyiQKtDG0IF+AgwAMohH1Q1lbmRz dHJlYW0NZW5kb2JqDTE3OSAwIG9iag08PCAvTGVuZ3RoIDk3IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJMjRRMFAwUtA1MlcwBDFTDHkL eQ2NgCwDsCCIlZzL6+TJqx+uYGjEq++hYGTOq+8U4KxgyKvv6atQUlSayuvp wvtPnoefg59BnvE++38Q5CcK8rp68gbyAgQYAG2WKQQNZW5kc3RyZWFtDWVu ZG9iag0xODAgMCBvYmoNPDwgL0xlbmd0aCAxMzcgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIkyMlYwUDBS0DU2UzAyUDBUSDHkLeQ1tAAK GgAFzYFShgrJubxOnrz64QqGFrz6HgrG5rz6TgHOCoa8+p6+CiVFpam8ni68 ///Y40J/ZOw/8Ng/YLE/wGB/8IF98wf79h9QxP8HH4Koaf5hf/gDSOMDBpAh P3js/8j/53X15A3kBQgwAHt+TLwNZW5kc3RyZWFtDWVuZG9iag0xODEgMCBv YmoNPDwgL0xlbmd0aCA4MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIibJUMFAwUtA1NlMwA7JSDHkLeU2ADAOwkBGQTs7ldfLk1Q9XMOHV 91AwNuPVdwpwVjDk1ff0VSgpKk3l9XTh5ScC8Lp68gbyAgQYAEFbEP0NZW5k c3RyZWFtDWVuZG9iag0xODIgMCBvYmoNPDwgL0xlbmd0aCAxMzEgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkyMlYwUDBU0DUyVzAyBDJS DHkLeY0MFEBQ18hCASSWnMvr5MmrH65gZMCr76FgZMGr7xTgrGDIq+/pq1BS VJrK6+nC+4/9/w/G/x8Y/j9gqD/wwf7gD/vmP/Lt/0CI/z8/HgRRA1QM1ALU CNQONARoFNBAXldP3kBegAADAFSDOugNZW5kc3RyZWFtDWVuZG9iag0xODMg MCBvYmoNPDwgL0xlbmd0aCA5NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiTI2UDBQMFbQNTZTMDIHMlMMeQt5jUwUQMIgQWMgnZzL6+TJ qx+uYGTCq++hYGzGq+8U4KxgyKvv6atQUlSayuvpwsv//wPxiAEJkKQRgnhd PXkDeQECDABdg09kDWVuZHN0cmVhbQ1lbmRvYmoNMTg0IDAgb2JqDTw8IC9M ZW5ndGggODYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIky MVQwUDBR0DVVMDYDslIMeQt5jY2ALAOQmAmQSs7ldfLk1Q9XMDbi1fdQMOXV dwpwVjDk1ff0VSgpKk3l9XTh5f9j/wEd87p68gbyAgQYAPM1GiwNZW5kc3Ry ZWFtDWVuZG9iag0xODUgMCBvYmoNPDwgL0xlbmd0aCA4MCAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiTI0VDBQMFbQNVUwBzJSDHkLeU2A DAOQiDGQSs7ldfLk1Q9XMOHV91Aw5dV3CnBWMOTV9/RVKCkqTeX1dOHlBwFe V0/eQF6AAAMAQZkOvA1lbmRzdHJlYW0NZW5kb2JqDTE4NiAwIG9iag08PCAv TGVuZ3RoIDg2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ MjRUMFAwVtA1MlMwB7JSDHkLeU2ADAOwkDGQTs7ldfLk1Q9XMOHV91AwMuPV dwpwVjDk1ff0VSgpKk3l9XTh5QeB/2gALMjr6skbyAsQYADV2B+QDWVuZHN0 cmVhbQ1lbmRvYmoNMTg3IDAgb2JqDTw8IC9MZW5ndGggMTUyIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJMjJWMFAwVNA1MlcwMgQyUgx5 C3mNDBRAUNfIQgEklpzL6+TJqx+uYGTAq++hYGTBq+8U4KxgyKvv6atQUlSa yuvpwvuP/f8Pxv8fGP4/YKg/8MH+8B/75n/y7UD0X57/Pz8QMTAgEP///3DU /t++/R9/8z/+g3/kD/yQf8Bg/4Gh/gfD/3/M/3ldPXkDeQECDAAABTmDDWVu ZHN0cmVhbQ1lbmRvYmoNMTg4IDAgb2JqDTw8IC9MZW5ndGggMTA4IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJMjRUMABCXWNTBUMjBUOF FEPeQl4gCyJoBiQNFZJzeZ08efXDgSp49T0UjM149Z0CnBUMefU9fRVKikpT eT1deP/+//n/4/+HSJBBHgIf/icMH/x/IP9B/gP/H35eV0/eQF6AAAMAAVBI 6Q1lbmRzdHJlYW0NZW5kb2JqDTE4OSAwIG9iag08PCAvTGVuZ3RoIDE1NSAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiSTIMQrCMBSH8VDB To/cwP+7QEn7HOxWqApmEHTyAOrooOhsxcFr1Ztkc+3YISRSyvebPplzzsKZ LFiECz4VdCXJeSiTkod3vFBtyRxYcjIblpJMvVtyQcZu+X57nMmuKExip6JT z1ZV3x5vj0/ALyCOPKKDV3AKbYJmhldAGqBHfpD2mDg0Cdqpdlp3VaS1pT39 BRgATrc3Pg1lbmRzdHJlYW0NZW5kb2JqDTE5MCAwIG9iag08PCAvTGVuZ3Ro IDEzNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiTI2UDBQ MFbQNTZTMDIHMlMMeQt5jUwUQMIgQWMgnZzL6+TJqx+uYGTCq++hYGzGq+8U 4KxgyKvv6atQUlSayuvpwsvA+J+BoZ6BQZ6BgZ//Dzv/fyBq5v9/mP//Qf7/ D2HoAxEIrvgwGDWDjPrDDzQWbHg90CJeV0/eQF6AAAMAEpVFOg1lbmRzdHJl YW0NZW5kb2JqDTE5MSAwIG9iag08PCANL1R5cGUgL0VuY29kaW5nIA0vRGlm ZmVyZW5jZXMgWyAxIC9EIC9hIC90IC9lIC9jb2xvbiA3IC9wZXJpb2QgL2Vs bGlwc2lzIC9IIC9vIC9sIC9kIC9yIC9zIC9TIC9pIA0vZyAvbiAvdSBdIA0+ PiANZW5kb2JqDTE5MiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9JbWFn ZUIgXSANPj4gDWVuZG9iag0xOTMgMCBvYmoNPDwgDS9OYW1lIC9UNiANL1R5 cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMyANL1Jlc291cmNlcyAxOTcgMCBS IA0vRm9udEJCb3ggWyA4IC02NSA3MyAwIF0gDS9Gb250TWF0cml4IFsgMC4w MTExMSAwIDAgLTAuMDExMTEgMCAwIF0gDS9GaXJzdENoYXIgMSANL0xhc3RD aGFyIDEgDS9FbmNvZGluZyAxOTYgMCBSIA0vQ2hhclByb2NzIDE5NCAwIFIg DS9XaWR0aHMgWyA4MCBdIA0+PiANZW5kb2JqDTE5NCAwIG9iag08PCANL2Jv eDEgMTk1IDAgUiANPj4gDWVuZG9iag0xOTUgMCBvYmoNPDwgL0xlbmd0aCA5 NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibIwUDBQsFDQ NTNVMDcGMlMMeQt5gRyQMEjQAkgn5/I6efLqhyuYmfLqe4BJpwBnBUNefU9f hZKi0lReTxdeBiiox8Ng/w8GH0YZI5RBTCLhdfXkDeQFCDAAgpW7uw1lbmRz dHJlYW0NZW5kb2JqDTE5NiAwIG9iag08PCANL1R5cGUgL0VuY29kaW5nIA0v RGlmZmVyZW5jZXMgWyAxIC9ib3gxIF0gDT4+IA1lbmRvYmoNMTk3IDAgb2Jq DTw8IA0vUHJvY1NldCBbIC9QREYgL0ltYWdlQiBdIA0+PiANZW5kb2JqDTE5 OCAwIG9iag08PCANL05hbWUgL1Q0IA0vVHlwZSAvRm9udCANL1N1YnR5cGUg L1R5cGUzIA0vUmVzb3VyY2VzIDIwMiAwIFIgDS9Gb250QkJveCBbIDQgLTM2 IDQwIDAgXSANL0ZvbnRNYXRyaXggWyAwLjAyIDAgMCAtMC4wMiAwIDAgXSAN L0ZpcnN0Q2hhciAxIA0vTGFzdENoYXIgMSANL0VuY29kaW5nIDIwMSAwIFIg DS9DaGFyUHJvY3MgMTk5IDAgUiANL1dpZHRocyBbIDQ1IF0gDT4+IA1lbmRv YmoNMTk5IDAgb2JqDTw8IA0vYm94c2hhZG93ZHduIDIwMCAwIFIgDT4+IA1l bmRvYmoNMjAwIDAgb2JqDTw8IC9MZW5ndGggMTExIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJMjFVMFAwUdA1NlMwMQAyUwx5C3mBHBAb LAikk3N5nTx59cMVjM149T3ApFOAs4Ihr76nr0JJUWkqr6cLLwMQ/AcR9fb/ //+wBxHyIIJ/AAiQM5CIBhBxAE48ABEfQASvqydvIC9AgAEAOvtqmw1lbmRz dHJlYW0NZW5kb2JqDTIwMSAwIG9iag08PCANL1R5cGUgL0VuY29kaW5nIA0v RGlmZmVyZW5jZXMgWyAxIC9ib3hzaGFkb3dkd24gXSANPj4gDWVuZG9iag0y MDIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvSW1hZ2VCIF0gDT4+IA1l bmRvYmoNMjAzIDAgb2JqDTw8IA0vTmFtZSAvVDIgDS9UeXBlIC9Gb250IA0v U3VidHlwZSAvVHlwZTMgDS9SZXNvdXJjZXMgMjA3IDAgUiANL0ZvbnRCQm94 IFsgNiAtNTEgNTcgMCBdIA0vRm9udE1hdHJpeCBbIDAuMDE0MyAwIDAgLTAu MDE0MyAwIDAgXSANL0ZpcnN0Q2hhciAxIA0vTGFzdENoYXIgMSANL0VuY29k aW5nIDIwNiAwIFIgDS9DaGFyUHJvY3MgMjA0IDAgUiANL1dpZHRocyBbIDYy IF0gDT4+IA1lbmRvYmoNMjA0IDAgb2JqDTw8IA0vYm94c2hhZG93ZHduIDIw NSAwIFIgDT4+IA1lbmRvYmoNMjA1IDAgb2JqDTw8IC9MZW5ndGggMTI1IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJMjNSMFAwU9A1NVQw NQcyUwx5C3mBHAMgBAmaAenkXF4nT179cAVTQ159DzDpFOCsAKQ8fRVKikpT eT1deBlAgP0/mGKGUIz/5f8DQQOUqodQ9hBKfoRQ4JBgwE41QKgDKNQDCPUB Qv2AUH8gFK+rJ28gL0CAAQBNQ8oMDWVuZHN0cmVhbQ1lbmRvYmoNMjA2IDAg b2JqDTw8IA0vVHlwZSAvRW5jb2RpbmcgDS9EaWZmZXJlbmNlcyBbIDEgL2Jv eHNoYWRvd2R3biBdIA0+PiANZW5kb2JqDTIwNyAwIG9iag08PCANL1Byb2NT ZXQgWyAvUERGIC9JbWFnZUIgXSANPj4gDWVuZG9iag0yMDggMCBvYmoNPDwg DS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIgMzIg DS9MYXN0Q2hhciAxODEgDS9XaWR0aHMgWyAyNzggMzMzIDQ3NCA1NTYgNTU2 IDg4OSA3MjIgMjM4IDMzMyAzMzMgMzg5IDU4NCAyNzggMzMzIDI3OCAyNzgg NTU2IA01NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAzMzMg MzMzIDU4NCA1ODQgNTg0IDYxMSA5NzUgDTcyMiA3MjIgNzIyIDcyMiA2Njcg NjExIDc3OCA3MjIgMjc4IDU1NiA3MjIgNjExIDgzMyA3MjIgNzc4IDY2NyAN Nzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgNjExIDMzMyAy NzggMzMzIDU4NCA1NTYgMzMzIA01NTYgNjExIDU1NiA2MTEgNTU2IDMzMyA2 MTEgNjExIDI3OCAyNzggNTU2IDI3OCA4ODkgNjExIDYxMSA2MTEgDTYxMSAz ODkgNTU2IDMzMyA2MTEgNTU2IDc3OCA1NTYgNTU2IDUwMCAzODkgMjgwIDM4 OSA1ODQgMjc4IDI3OCANMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3 OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IA0yNzggMjc4IDI3 OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4 IDI3OCAyNzggDTI3OCA1NTYgNTU2IDI3OCAyNzggMjc4IDI3OCAyNzggNzM3 IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCANNTg0IDI3OCAyNzggMjc4 IDYxMSBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250 IC9OTUlES0krSGVsdmV0aWNhLUJvbGQgDS9Gb250RGVzY3JpcHRvciAyMDkg MCBSIA0+PiANZW5kb2JqDTIwOSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNj cmlwdG9yIA0vQXNjZW50IDcxOCANL0NhcEhlaWdodCA3MTggDS9EZXNjZW50 IC0yMDcgDS9GbGFncyAyNjIxNzYgDS9Gb250QkJveCBbIC0xNzAgLTIyOCAx MDAzIDk2MiBdIA0vRm9udE5hbWUgL05NSURLSStIZWx2ZXRpY2EtQm9sZCAN L0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxNDAgDS9YSGVpZ2h0IDUzMiANL0No YXJTZXQgKC9vbmUvay90d28vbS9xdW90ZXJpZ2h0L2wvZy90aHJlZS9vL0Ev Ui9wYXJlbmxlZnQvcC9mb3VyL1MvcGFyZW5yaWdodC9hdFwNL2ZpdmUvcS9C L2EvYXN0ZXJpc2svci9zcGFjZS9zaXgvYi9DL3BsdXMvcy9zZXZlbi9leGNs YW0vYy9EL1QvY29tbWEvdC9lXA1pZ2h0L2UvaHlwaGVuL3UvZC9uaW5lL0Yv Zi9JL3YvcGVyaW9kL2NvbG9uL2gvUC9zbGFzaC93L2kvZW5kYXNoL2VsbGlw c2lcDXMveS94L3plcm8vTS9uKQ0vRm9udEZpbGUzIDIxMCAwIFIgDT4+IA1l bmRvYmoNMjEwIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5n dGggMzk4NSAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJXFUNVBNX Fp4hmUmAEGLGiWcTzIynabRREcQKiqKkqNCggD8YqKcSSOS3RBN+u7W7bqui EG1tT+m2q6VWqBS0qHVFcddKpSuiFWtdqXhal/qzuqgr6t6JF7f7gnvanp4z c8+8+969797v3vsNTcmDKJqmdYsWpiTZUiYmu0oqXGWFeY7JVneJM7AzXTJQ UgQtjQ2SjDJptFwSVDpMwKpHv3uUyRgb6B9ra59IlQIOh8N3o9ojtFFaiqFp 5Y7Wg19ERUVHRkXFPudeXe0pzC8oEyfkPSNGz4h7dlJAxo7IGQE5I0pMdLpz XeKSam+Z6yWvmFKa5/asdnscZS5npCgmlpSIiwMevOJil9flqSDan6IVC72i QyzzOJyulxyeYtG9SkwtLHWXVa92iYkLREepc4rbIxYSW295rrfQWejwFLq8 v7APZPvT6lcgUDTBgVJy1Dg5NZ6iLBQVSVHRFBUTRFmVVKqaclNUNUXNJkBS ckpBJVKrqWZqgDbQC+kyuo5upDuDVEExQRuCfpTNltXLlfJ4eSczkbGzQewc di/7X8UcRYFinaJLqVSWKG8EBwfXBF8LiQ7xhQyE6kPfC+1T0ao4VYbqzyop LCmsIcyvflb9kfpK+Ljw1PA3w09rtBqzpmA4Wk0efFQL47qk92srtdcgEi1g 5nZzNfA6jONVFJpxHJhZLn2r1EKWYMNItCkO4FXmAkuMpQxoRA44bS+IXA7X 0Cv9QE71sZtc6/NTKpR2xYn6/lbQ6u+hqCAXYVrFI2slvRdMMvgKnbwVuIVg gDw95HWBoQ/GGE1sJGriyCXL9bh8ACOvosr4syFEEssdfg//DXLdaMA8PeZl oCEBxxiH2H+C5jtyYLkelk+DyKkQMOyUxsD3JLEm+AFXXeHSuQa47g8jIZoL GQidjqGKp/eUWe8XL7CcWtl7/WzUqUPzBx+0MGqxFrpRDnIt/B7kXA6R3Tza icbOcg2YBXIFUWaBHeRohyyUKwgWtWCme8AigyIw82hB8/fshtjcaterysw6 xZUPetohXE9SgWLQ0U3QIoMv4TaPLaiDFvbX5gR44gAsgQ1fhb+mki6CQRn0 +Mt5DGax8nENA8Gsugrkkg/kdAuYIIdA0wJ3ePRdQiXEQ/wlUIIPfLNAgfEY PwsV6DOCSQe2D3v7+z+cjza0lc+Ljy8/BzajuqFCWnsbwgnEfwBR1iut5WH2 8FoQ/dmoYDNr8uehwVDJqmtBIxVACL0HImAFOQgJ0kr+WN2Wy7cNZ5uXrYi3 5+PoSIGUT75+2oY4pVQNGjzJvt96tOXmGWXvkUvdoNaDCal+jEjF2ZX4W2Mg Byi9C2kE7CaIQA3oDoF9KYioBhN3kxuEQujhuXunb260zMp2LZm87h/7hLo6 Bsey6IHkV76Cp+7cAj2EzWjzbDP6FNytA9vb28/rwYKjOibhtLmT8DdG0LG7 aq//q6/++TVTEjY6jNxgOUtShmigoQsEGv4WyEUHO3iYD12Mjy2vQRnO1YNb N0tKxxgW/zicxGAYtGI0iBB9STES9rvkVRA0mojOEejpF6Q+Hg5CyLCezR7W w6j1zF+aOup2GC4021LnOBcnLyzZ37VeQJHFp7YBkwIyA7iOwtRBiEXVmUnz iyuq1wgjnreBPL8i0F7aT4hvFxmuo9IWqYl/9e9rG5z7lHsLZr5TasDN1biO TMG8g5hMumrsrfswReAuP5wHDI6fVVC0psq4ycfceKPh/nXDsUZ33lbhXezk J65w2pNXdvZdPd76+aGu0uiR2n8NGhpGkRSkXf5F/HANW4MaBh6yaTacjxWv YJsSTOyfSMdaYdXZC8qRGL0PIYkESHqPlEpPgNOjipRsiJSsRZrJp5UcPnis 9dNT7W2Fy+zFq5YK3BBswnz+hqt9wR5SgRPNu46d1N+ePYDjUWOxYlhK84tf uI3cEFJZtZPz9ZZTGEo6E9K7QLwmoGk9n+1Otdqc7Wf7jrb+9dvGRVlPekck 7xZQ0M3kyxkoQoLk5u+d3v7p+b1ZM2OXFWRnLt/5HyNqsYdHpn5gHoQZYDTo rsLHdzfCdtyMgmkmWjH0kgkiOjrrO1oE3yYGn9mckZ1hyClpOPqaUKcY4Ugz rAaz9gZYxhAW2fDLIeVypLflP48stFX1X7wLZYN3+mkIufMlUJB1BkZflknf Sio+5QVrUnZp27Hujm96j7TmZxubIZg/UurYnmVAfjqqcdTkC/ED+w/s2t0o +DYz+b7Gl3cbemHRRVLiNJwDakzBfHwO47AISyEJp0EJqVxQ19A5YSqbnZlY HGfARNRCCKlIAjCkq+cSVgyNxlik05Izve8c2PmG0AVvMTGs+hMyAxPISC+u pD/wJ8igCibwsJ09jBMYiGXxTX8ug4ksvv04l4GpLDwvfc772KvYxqCNGBMy gKUQRqZIo71IGIjQOvkXWLgHF3VwgoXx+3cd+EzY1/bR8RP6r8vOxbQaOan5 va7dQ/oLL0IQJhnxHgumYTMPS1juwfHj3lSro9gqYCorFclhLstJZw9Wpy9e UZYuYBK5rgp00uuEOw/BZJl/rlTJP3xtGkzAYgMuxKdxNG7FOhiLxBsk3yNz HdUsoIWNqc5YQQDh7IQMeVj5sOM8aHbOzKkXRsKXikjfX4Tx0E18kqh7WFh3 EjwEr4gsyMUNAp4jeaCGJ93f8++XsQBDcjEc1QKaWXU8Aa8TOJgOHPFBiJss eegFDnuJ7jFww289zn1C4Q0V/tzK/7O7P5f8HJ5s/I/vqg+K6rrirvDuAtGd hMcDuwtv+aoIwggoQgAVhYRYiTAKxmq0EiFgGeTD6oIRY0gyCbCUINAVmiAf oqgBGwgER1oxujUQFW1iIYj4AdGEkCHTSM5jzmbScxdJJ/mjs7PDXPbec3/n nN8553fBswT8lUTqIDQ+lWXUg6bL+c+ZDJ0sfUIRQ2elT8As2u2uTJQycLFM CODDQKtMCKWWCXBnmj2EwkSJSLN64gdlM0hMEkUQks5A2BXwCB1DvR6HrZcq oi3tfUL9VdvuZzJKItCWR6IWaiiPidY8+sAx6p3OlEeFIuIDLbCEgU15qu/q 8perdukhvJZlmEqaHmlBm1Gf0CSLj/7V2N4/pO1NBw/cKONPPGLXJbIWrx59 d2NqTGr2Cr1mTx5F+x26oI1I8hsq1WP0dz61i8/FsTbIkYK7cDHU9EF2LdFZ Cmr3bZTFQYzuFDIPbzNd1F7pr7sELqZVGWU0wthocQKdztZhwQ70iMBgsM0B u2z9YL4gjg3kXziwUbsqcn8MuhgG2otlnidllHIEr1BolKdIoUAmJWeYuJpp GeV5KJgMqVOCqJc1E7AN4CbmKW8orhK4oFtDFKpQ+BOGviKDjp0qM3Xe0J25 +HZCZnbh3rf16JgnBB9cu8lLK3bh3Nvbb413ffT+aVnM+3Nm6esVuXawuI7t Ly+o7tOi231J7Ppd3M7ns1Nrus2dR85XyubKhsrqv9hpIgpAvfA7GKQURBkc PyEMBRSYbuVZqJHicn2DgtNvDt1tvPfN2MnIUBkLlBclmiDiAUqnm1rsvlaq jm/p3WfWQfBVOroQ4ry+RPug5C279uqLyDeaULesE5tLBE8KAGyScvfExngU gdp8tWF0VL5SVp9Ynm4HngzCD6L8QagOn4simkeh7VkMoDn/QicEfPyO/ldA ucUC62Q6x0nrjhVFrGVvcneQDu29gjAOF15Fdwg299ZdbtGXEuDnrHgt9uTW nZNDY980hiyPTF8dHJT7bZ9MOG3B+QEfqKoGMpzJZ5EGAqXUQzsNKToUXv+y /S29ojrG4C387d89sWAvJq/DLFBHg9+DqQ5w+puMAKHSjYrWjqu6ro9zQir0 1LYp9zGTt8jofT7hDUqM9GAysI59ZKw5J7eBwIyv5hlf0i2OT8a5+h0rfQYt MUBKNQIzp6hrO0DfD+4w37GdAOWTp8PihBKqNEvicGSRunX/TvOiWVfXfxcM Tnda2z5s4NNjnTokLS0q/NDx42/K6M9QKAe7F2GuDmoOQ8BDPVkxqi0C1pMh eNL8wfkvOp4JWbMn3J+mYljWrX69lbJRdH2UQXWFcrqNsCudiq0E9uGfeK2K T/lDvlwEFejOGwOY2fC5jt6x0rUpMg5w9LzfKM2GEXDmstzlOiG2ELOVZrUY CEl8ULlTfbtzBUTbgDrTdR6cVIiUzJepfeUJEMkwCYYgAWgARDGMwe2CsmDm PvXP/WzmlDX3/AfqZ1s47u+9wMHxUwK2aubr5Cp2T1+bRb88JSEnX76Uln5i pS4gZUN6PpFUHP4CtRwiDBJBzHVnr94pidsu4+f0n8/UfcfO3viwNSfysXcR P9/xODRi1/9is3BnfAapHiYOzlo0q8WuX8WHaOxAJJ6piUpOtH9z5ZeI0ih6 0UdaiomYCNJS8KKPNAqJMno7xxoCcA7OMXzd33/0ayLHnKMBsdRccP0+SKIa G7QypZduPEDFO0za7bB0t2GmaK1FvOvmEOUXTtmi9kcDbTtRyna/27rp29m6 JeU2U7oBKVuSc8iHWdsOcBPmW7Ee5DxYTunk9DOkmgN1+HQsAV6EghkDIeLG +aYLzfpSbCLdbmAWB2yWQNfXcqH5wQESWarNv18b9vKlcf4sohiu2AdOhhYD z5Q4+CnxAU6yfx7tB9WRmpIikwyeamNhobFQtzzjhaTdPElfPUStWlMwRc46 /jDleJJa8FPgBlTVJNrdxXGidYnCJPA7hE82eekwfIvPCr04jlth5Fqw1rA/ PZrE3dKs97tIzDH0LAOXZNJiI+B3gsvWcdiM99bf0TZUNQ9QnAZMabvKeQG/ OQV3J1W3OdVyp8N4m/GO9vkMB9iz9dtgvvweq683Guv1U+ri114rLtRtKDad 0kPH/cllM3n2+l6hVsUDvNXKlA6KHtm4zPyfz9m2Y+tfb8swQuv/qNF1IP7R zYunL52WqVflRQH5WkJF42pQHVGO2yjt/KAv1bLFlQ/muYqrgIEMNlqa+UTW 3C+h2VsI3qqq6RKb6Sq+2ZuFWRxpb4TiKKAHi7IuwvjCl4EfP+fNRpQF9NoY sSzgC/4i6doH1QZVjdJgAxZolCAaqgV8mi3FJUGwRMCVDNZgNSnARgFWsIew 7CEuE2A10+AfwXZaY1BVKU02yhl+/SKGqhms7DHWzZZ/CGsOZr2xWfdqodFI 7xBbdfHRxuJaHWjeayKJqteAYUpVovTYKD1wT7L0eCg9VNS9/GVKshfWzXyd sn+pfufNgXv/b63Jq51+qRaTq8HfxKDRBA4VP7JKtVwXne/y0zx7cHAA9yeM 8zRKj9N0rPRfAQYAlyz9iA1lbmRzdHJlYW0NZW5kb2JqDTIxMSAwIG9iag08 PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAz MiANL0xhc3RDaGFyIDE4MSANL1dpZHRocyBbIDI3OCAyNzggMzU1IDU1NiA1 NTYgODg5IDY2NyAxOTEgMzMzIDMzMyAzODkgNTg0IDI3OCAzMzMgMjc4IDI3 OCA1NTYgDTU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3 OCAyNzggNTg0IDU4NCA1ODQgNTU2IDEwMTUgDTY2NyA2NjcgNzIyIDcyMiA2 NjcgNjExIDc3OCA3MjIgMjc4IDUwMCA2NjcgNTU2IDgzMyA3MjIgNzc4IDY2 NyANNzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgNjExIDI3 OCAyNzggMjc4IDQ2OSA1NTYgMzMzIA01NTYgNTU2IDUwMCA1NTYgNTU2IDI3 OCA1NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgDTU1 NiAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCAzMzQgMjYw IDMzNCA1ODQgMCAwIDAgMCANMCAwIDEwMDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDEwMDAgMCAwIDAgMCAwIDAgMCAwIA0yNzggMCA1 NTYgNTU2IDAgMCAwIDAgMCA3MzcgMCAwIDAgMzMzIDAgMCAwIDU4NCAwIDAg MCA1NTYgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9u dCAvTk1JRUJQK0hlbHZldGljYSANL0ZvbnREZXNjcmlwdG9yIDIxMiAwIFIg DT4+IA1lbmRvYmoNMjEyIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0 b3IgDS9Bc2NlbnQgNzE4IA0vQ2FwSGVpZ2h0IDcxOCANL0Rlc2NlbnQgLTIw NyANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtMTY2IC0yMjUgMTAwMCA5MzEg XSANL0ZvbnROYW1lIC9OTUlFQlArSGVsdmV0aWNhIA0vSXRhbGljQW5nbGUg MCANL1N0ZW1WIDg4IA0vWEhlaWdodCA1MjMgDS9DaGFyU2V0ICgvb25lL2sv SC90d28vbS9sL2cvUS90aHJlZS9vL0EvcGFyZW5sZWZ0L1IvcXVvdGVzaW5n bGUvdW5kZXJzY29yZS9wL2ZvdXJcDS9TL3BhcmVucmlnaHQvZml2ZS9VL2Vt ZGFzaC9hc3Rlcmlzay9hL0Ivci9zcGFjZS9WL2Ivc2l4L0MvTi9zL3NldmVu L2MvRFwNL2NvbW1hL1QvdC9laWdodC9lL0cvaHlwaGVuL3UvZC9uaW5lL0Yv Zi9JL3YvRS9jb2xvbi9aL2gvcGVyaW9kL1Avc2xhc2gvXA13L2kvc2VtaWNv bG9uL0wvZWxsaXBzaXMveS94L3plcm8vTS9uKQ0vRm9udEZpbGUzIDIxMyAw IFIgDT4+IA1lbmRvYmoNMjEzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggNDE1MiAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0N CkiJbFRrVFNXFr434d6AQIBcL9pEcwM4jE8MVZSniICYkVcBW58MAaJmfPAK iajt2I5VAbHtmrUqHa1SO1rriEVRGRQfqEutgw+qCEalBpRONKLl0X3ijmvm Qqftn1lnrf1j3/3t++3v7O/QlJuEomnaLzVFlzgnfdI8w2qzwWTM0w8lZxAV RcbQZKyEjJWSUW5krJc/RmLpq42vZjLqGvo/lZU/Ry8ZfOoDzX71YxRGBSWl afc9X2m1oSFa7Yz4gsKyYuOKlSbN+LwJmtCI8LDJQ3HmcIwYihFaTVx+Qa5B k1lWYjKsKdHo1uYVFBcWFOtNhvwQjSZu9WrNcIcSTbGhxFBsFrO/0tQYSzR6 jalYn29Yoy9epSlYrkk2ri0wlRUaNHFJGv3a/KkFxRqjiC0pzS0x5hv1xUZD yW94iqLFQ3lIKG8fKtCdmiKhQlkqiqJmU9QcdyqZoTJl1EqKKqOocopKELWi pBRDRVMl1GHqOtVFDdByOosuo29LsiQfStqk8dIiKbjlu21xO+n2gnmHOcB0 s57sVHYPe5V9yA7KYmWFsiPuAe4VHu4ewR45HhUe9R6XR6SNqB/xynOh50nP Xq8VXnu9Lnj95O3pbfD+wvupPEFeKn/s4++zwOddn2ZfiW+G7wrfv/nWWeQW +RFMNb+abaFv2qXwvrOIRwpDUjEQE5SYdhP9+lGrvsxGQWgGyCFCCZvPPnsE 09W/wiDWLn2GeTxQEHIVAiFBCWlJ4BcEWnU6ex9DL6EcI5S4eeGkGSjCekg8 1FdaFMfgGqZc4dK5mmOkm/eigDLOm9pkbLG3TGmqnfcDULWWC4EGBiRpKJEF HmXkFvx948tBuqtf2uV/nl26aZF+q3qZbO+O73fBGOXzIJn8CGx8QjdAuRRO wF0ey0OhnJVbKochkDko/iMooF/MVJmd2yz0emiRwmlnKa9jseL1NuYGK19n JVetdJ0dTtmlJAae8piwLCA4eNkgJEBC4+DLl40BmKC2+0NwPqzCbMzOx1UY jMHHcBVkQ/YxWAXBanmNmWxtBaUozOeioOjM5OeyBShbugnZv7gnQrhrq10m r+wkR62K/b2R3VBr5zpgNHmHb9rxCfjCG6q+bxIypy5YOztHCFnAcP+ekqWL 2YLB7qS006VgPzpQc+HZ+Tv1owcudp4HhRJGTbCiXM11xGKUCcsEcQj4/A6Y rYranjhbF+gqeubZOTv3HEzQwVd/tr1axf14pX8TjohMzgrFURseX98maNlP Imsi7+W6l9U2vHdOBUltIAWZffHppC+EKhn39OjOcyefKH+KvIdjMEWP3Di1 jW366K8/gp9q4O9z9dN0hUkC93zjhu3bNwri/BDbTpaK8z/qlpK9EMu3jyNL 58jwriuDCYMrGNsNsbJQIvBVeBvNouzt0GqFCTaahIuCJZJeHs7aXBT7tsu7 fStz8nDjl2dVXbeygqdlzNFGp37z8AORL4buhhHLf1BB4RGIuQe/Q4/7yCbn mE1rhhX41goJVvpoD5ztkZJKUs1D0Acoa4hU4fJFWIwhU3eGndAJMWc6SppV vScOHK8TTp/bc+62EqJReSFs0uIlhlJ1eRXTdhBSQd1euyzlUzUexPN856lW B9CHw1ImL9DNHJf94O7wdffa6DqyXlonMiejWFRhKI7Ej0twgbuDPQs3IBpM rXfcO1zrZUPc9rXDWqviqD2xB7b3zLVzfZyDbCJ7+IepvajF6Gz0mqM7suSK Sc31xa3JzgpTGitjb2eo/3ix7f1jKoi8DTQw5y33JtcLnOPQrsuHXiq5PnEP s/j71/WTUTLLNB/lBd9fbGls6RUrKtr5+enHb/xzX4u976uUnPmLF8eKCt0B nRWuWRUnesK7YX8fNwC74M98S+vXzfuFqnIG/1C6MHKSinPE6xu+2yJMY5Ma 0AsiYEs1tN0FthRWokhvAMfHIIMjBdT0TAd/dbWVT5+5G1T25n89fHk8MQqF N83LhCEHwqVBRVf/KK7mNxtyOaTa7RdHDjv7f0X/39ycth8uidDBoACZnDDi jhls9GfOkVJSBAb+OzQwgyxWO3MZlLC473Uu84K9CwbmaxsPMrjFVLGDeIsR gZWd8LEVijoVbQ6450h2iJPHOn14SGA5AtRxw7xpGQUhAsazE11v8vAtK36f 9sgh9vAJP7x0j8ARa93u66eUz+d2olKNt1iHi+MhUyyzPrYERy1cGCxgHisn 0ets5IGNbnghdc4gFTx4vTsJZJiiQgMqcAoW4UGYHgAzm6FwJ3xZL0xhMepP SK9JVuHcNPCHGHhr4Bn43xowoeKAILYTn4umTvqBg2heSB/4Qz0Lm1ohH8Ig D2UQiGkCNrCOcB50LIzu1KIOdRHjUSFgOjs0sw0226DQRtscUuKy8a5E2EzG 2lxjoZDMsrn2vs4lB1g5XBdFtf5SB/PBysOADQfEonE214evcx1iL9O6zhwz NHfCXpvi9Ati6OGayBvQzIOJnbVhfvIitf7tt7auUGHmEpgIwZA+2Ae8daAI /Q4JdhbCzDihHZUqfC8AF2F87A70AUmQsKLuSjb4qJ4/abjZJHAb94Uw18hI vDkko0ip2wZnLHSHg3iK7BtJBO/yhDMTRTrQTTyx2+HMnShuUI3ZmWuhe0Ti 6c5cfuIw20qb08tCt4u5uJ9zRD/0rMjJPypBSjaBjL5jJ9vsUmeVvzMX1TLM cfUz5SzqST+Dwn/prhaoKK4z7GSZGSSIsuNgyupMSUWKYFldgigoCqImIiFq eLVKWRq1JCjCkUe7KqlGRF4+QRBFTDR6RAtCDCo+cmINViCiC0sJWcGxqyS0 e/Kw/8V/Mb0DSV8nPWfOuTPn3Pnv//j+7//usHGAhHLHCmxtnsUcrHH8nf2S LsROsbS0QJ/l6Qjl1cKARChFMJYBoqVDoxkkkVpA0s0ir1roLuYI4+hmgRky zuBGkfuxFYqtNMnwyE7zrKIvgfvs1gb99Jg3A2V8nQt2giwO9DeAtYNzSD/+ REbLD+nvfyVraFa/9ryd7LILTSQYfi52vcaa0tZtT9GhfgaMp9iZN0AXPegH cDzOC9gYGh8v6++yQg5UoVH0tbCW7veBtXlCwBzIxGN4bA5mYoAkNGHA55gJ xyy3jpy+JNHtzwWxaoSHockKu6xaZRC+G5xlpx2xHFpE2KZ2jHP54pj0EmQq kmR4/jCXVrWzcnfDO+DxQr7deMRY5Sx8e/HkR+efeII/ujSii4R9aiBD451g J3e59w+o8VqQu0jGzWpmcqzkgVXbTMcVfGFbOCCYhW4ySPaIPfkZMB1LdRge js+hE7o/Sb2UJ4PPb1nhIbhsPJe5wHMquuRGBnjVUxLSc0vLX21ZJW04cy2F zlKaiVmXYD5wkR//okYWujH5Ept88NfVLZ7AfF3V0vtoPWr2SCPgH3LtZ+Dg oKZiyFWE/GHXwSFXyO93fDbazkNyNtMzSHgKwg8pmhyJPOp9jLMC/S9QnUPi pzsyefS04gR4HRIe0THuI5G1KlMVPiEkm6ke4jWgPBFH0EVYHMNBJSWpr+mi chajtl9hP7nQzxwntzSkjzZpNEeiSRN733HqJeLHO6Icl9m55Bbvhu5XmEJy XUOuo7t4xXE9gXczmZd0EF+z9o+2V3rhHUVoFGrhZ2SM2LC3osWuszakrYrL 2J5VIKN3Lis04rTcrd5JnjM/jf7yq+uX685KwlspJeUpf9FVH9pbWinf5gve zivYrsvNO1Ajw0c8eKJ/eTKKwYnoni9BFy4TBUrusXNe3nD2RtudQxf2SsBU 1OyvKHN2M1miW8iLPbA0W/snBWopOwgm8PIQmluL+Q1H6uIf6mDxNQgBd/AJ BQ5lOXp3XMYbq5wLoMLACaZhI0+c4LAoNCO/JtBvZWAdyH0VMAUEidqZvA/F pbIbrDFZ6BnM6QGV++2ibUecHafocOE8FDEI/R6gBnxgxlUYaz0gB3Ehpvik GB2O2wyavz4+9w0wneeTI8tk6mpKFkkacfWcDeoVSmT5tK4GrOQKdrCns1Ju +utQDkUOfdD9GobA4qufHL5bLxdTPyOsvNDsGEs9bd8HIkwGoQKnBKEcuHal 35oHwEvUOizoAH2PtmEAGpTZNuFbMgeCxd/sSlwWrJsW/2dgZKLlYPlCcEW/ /3ZdEsj9s9WH35XbPny3s+Q9Z0p3sth7u6uXDtx/nF0wd4+ssh2JNYO2h+lX NFBJYkWzoZX/oOJofVnF7t1lUg9ftGVr0VbdSwnrQuWZEeH3HLEKiaXQSTfD CzR5t5dRx2xQqwi9MOn/R0F1iRMcEoM5oXdhAf9jKem4WFt3XC4t3swvL6Eq 3z9rbqH195KBVrYKxv3ulg52FkFMlyoJR1PNtCpQQkXhNiAi+HrXzp2dFJea IRXAEcOwUYF6Or06P7h3v3r1Igm/UHi3MPpjdTbwdm27MgkCSLVocFQrnKAn z6h2sBt8eAqH0T1vZjPtfary7xXhVxDHohOHm3ETSwKDho19kMib22A2VrHA cqpZdVq00+QFqDWnZ6tTQfVSTQ11Ml19Jk6mwPUYcetF5cyV1qrYJAmfKXCP 72ju6OyqSYyQ0KbAMx58vE6tnLt+XWKS9L4p7cYM3Yw10Rtz5AKauM5g3u0/ 7JYolLT/Ff3MRLpNotu6O4NpXFDPC00jR/WfWK2XsItmYIuFTLUwFKE3bJpz UCmizoJetINCLOAFOtCFgReGYEgYeqFOsnl0nKDqQQvaE+gRGbkJPaja0G4C jw7JjV7WYNX3tR/tzV56V3tbHO2v0eb6d9dJsx0xogKVxdza4xdTO/6nbf1T YtKy1PAG1fDO0fhiekIHtN2KUEdF4g3Rcu3251KtjSvesbMoT/fyamP0enX3 nQdqlPxoB3tbtGf6lvRBTt8iZYTqVxIX8cRWkPDVqf5xyEdcXmvOlb7KoCTf lXNqS7LnaysyonDCtrbGXVIQF1VSSQVpig5cHrbCmLtvNCBzkrK7oYZdUpV+ 8IJna/eBk6ApX5VaJLll77AQdzNDLyNwUG2V2TDNgNMWhd/Fv/FRRxMfHHiv tOSMdOctPnd9YaMMj/lRGjNmaz9VoIAWTMghWzxItQEbaX3CUn1RsyLpVL8E doPDlUf3x2u77zedaamTqHAWcsLU+AoHyfxsZj/J0UDRoEr6k8l81puDlY5q luqgX5Jq1o8bUQ9O0J4FLtlUyi7TwFPiK1Kl6vBlbRz4000GzssRQCWJNwlg fblpI+8+9N2PAz9qysaNwB8uZMG+bKaMZGrgJtSIEAn71BGD4zAKx0EUiywH EbiPftWwoOEoQBLAAxNYcFINYGpPQtZQWra2jGTQAu4ZcVimDvtwEOs4Sy0l 79y6WpeZu6c0TxbSQ3ihLr/iYP4hHbAHymG9VW6HsE8grAXCnKkS+ylJgf3M TbPmJkmhet0M+8M5t6EVhU8Y4L+BXPWZmA4bf7gGuI6B/h97p7/ADjNT+NSk eWqCNvGZKfypiV4Vjw4Zj2JqJUyv5OB4GUwoHR57iJeOReRO+s51rMVFeZ5c nwhXxX8KMADuc0jUDWVuZHN0cmVhbQ1lbmRvYmoNMjE0IDAgb2JqDTw8IA0v VHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDMyIA0v TGFzdENoYXIgMTgxIA0vV2lkdGhzIFsgMjc4IDMzMyA0NzQgNTU2IDU1NiA4 ODkgNzIyIDIzOCAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4IDU1 NiANNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMzMzIDMz MyA1ODQgNTg0IDU4NCA2MTEgOTc1IA03MjIgNzIyIDcyMiA3MjIgNjY3IDYx MSA3NzggNzIyIDI3OCA1NTYgNzIyIDYxMSA4MzMgNzIyIDc3OCA2NjcgDTc3 OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYxMSAzMzMgMjc4 IDMzMyA1ODQgNTU2IDMzMyANNTU2IDYxMSA1NTYgNjExIDU1NiAzMzMgNjEx IDYxMSAyNzggMjc4IDU1NiAyNzggODg5IDYxMSA2MTEgNjExIA02MTEgMzg5 IDU1NiAzMzMgNjExIDU1NiA3NzggNTU2IDU1NiA1MDAgMzg5IDI4MCAzODkg NTg0IDAgMCAwIDAgDTAgMCAxMDAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDI3OCAwIDAgMCA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgDTI3OCAwIDU1NiA1 NTYgMCAwIDAgMCAwIDczNyAwIDAgMCAzMzMgMCAwIDAgNTg0IDAgMCAwIDYx MSBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9O TUlES0krSGVsdmV0aWNhLUJvbGQgDS9Gb250RGVzY3JpcHRvciAyMDkgMCBS IA0+PiANZW5kb2JqDTIxNSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0 eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDE4MSANL1dp ZHRocyBbIDI1MCAzMzMgNDA4IDUwMCA1MDAgODMzIDc3OCAxODAgMzMzIDMz MyA1MDAgNTY0IDI1MCAzMzMgMjUwIDI3OCA1MDAgDTUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCAyNzggNTY0IDU2NCA1NjQgNDQ0 IDkyMSANNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAzMzMgMzg5 IDcyMiA2MTEgODg5IDcyMiA3MjIgNTU2IA03MjIgNjY3IDU1NiA2MTEgNzIy IDcyMiA5NDQgNzIyIDcyMiA2MTEgMzMzIDI3OCAzMzMgNDY5IDUwMCAzMzMg DTQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAg Mjc4IDc3OCA1MDAgNTAwIDUwMCANNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAg NzIyIDUwMCA1MDAgNDQ0IDQ4MCAyMDAgNDgwIDU0MSAyNTAgMjUwIA0yNTAg MjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAy NTAgMjUwIDI1MCAyNTAgDTI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAy NTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCANMjUwIDUwMCA1 MDAgMjUwIDI1MCAyNTAgMjUwIDI1MCA3NjAgMjUwIDI1MCAyNTAgMjUwIDI1 MCAyNTAgMjUwIA01NjQgMjUwIDI1MCAyNTAgNTAwIF0gDS9FbmNvZGluZyAv V2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL05NSURCQStUaW1lcy1Sb21h biANL0ZvbnREZXNjcmlwdG9yIDIxNiAwIFIgDT4+IA1lbmRvYmoNMjE2IDAg b2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgNjk5IA0v Q2FwSGVpZ2h0IDY2MiANL0Rlc2NlbnQgLTIxNyANL0ZsYWdzIDM0IA0vRm9u dEJCb3ggWyAtMTY4IC0yMTggMTAwMCA4OTggXSANL0ZvbnROYW1lIC9OTUlE QkErVGltZXMtUm9tYW4gDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgODQgDS9Y SGVpZ2h0IDQ1MCANL0NoYXJTZXQgKC9vbmUpDS9Gb250RmlsZTMgMjE3IDAg UiANPj4gDWVuZG9iag0yMTcgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCAzNjEgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpI iWJkYGFiYGRkFPbz9XRxctQOycxNLdYNys9NzAMJm/6QZvghw/hDlumHHPMP SZYf8jxiv21+5/2q+SXGKreA8X93N4TkYf++nP/7KsGt318LMbAyMnLMWrpq q4GBoZ6BgblzfkFlUWZ6RomCRrKmgqGlhakOiDQHk5Yg0tJAwTElPylVIbiy uCQ1t1jBMy85v6ggvyixJDVFT0HBMSdHIQhkQrFCUGpxalEZUBTsUoXMYoVE hZKixJTU3MSibIX8NAWfzLz8ksqCVAVHd4XEvBT9/CKFTKC+4tKk4syUzMSi zNRiqF6wL8FMZF8DgRADEyMji833Pr4fHd2zfmqWM37PfMj8nUvs+4pZbA7l 03bL/3jD3tz728OAtZZ94eHu7unSa7sLy+T/RLI7pnUGdsrx1c78qTXzd9nU 78XdbN9nTf5T08NeO/NH2NTvcTM5fuf1/Cie/F2gm3M5131ugAADADlMj3cN ZW5kc3RyZWFtDWVuZG9iag0yMTggMCBvYmoNWyANL0NhbFJHQiA8PCAvV2hp dGVQb2ludCBbIDAuOTUwNSAxIDEuMDg5IF0gL0dhbW1hIFsgMi4yMjIyMSAy LjIyMjIxIDIuMjIyMjEgXSANL01hdHJpeCBbIDAuNDEyNCAwLjIxMjYgMC4w MTkzIDAuMzU3NiAwLjcxNTE5IDAuMTE5MiAwLjE4MDUgMC4wNzIyIDAuOTUw NSBdID4+IA0NXQ1lbmRvYmoNMjE5IDAgb2JqDTw8IA0vVHlwZSAvRm9udCAN L1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIg MTIxIA0vV2lkdGhzIFsgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDAgMCAwIDAgDTAgMCAwIDcy MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDY2NyAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCANMCAwIDAgMCA1NTYgMCA1NTYgNjExIDU1NiAwIDYxMSAw IDI3OCAwIDU1NiAwIDg4OSA2MTEgNjExIDAgMCAwIA01NTYgMzMzIDAgMCAw IDAgNTU2IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZv bnQgL0FyaWFsLEJvbGRJdGFsaWMgDS9Gb250RGVzY3JpcHRvciAyMjAgMCBS IA0+PiANZW5kb2JqDTIyMCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlw dG9yIA0vQXNjZW50IDkwNSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjEx IA0vRmxhZ3MgOTYgDS9Gb250QkJveCBbIC01NjAgLTM3NiAxMTU3IDEwMzEg XSANL0ZvbnROYW1lIC9BcmlhbCxCb2xkSXRhbGljIA0vSXRhbGljQW5nbGUg LTE1IA0vU3RlbVYgMTMzIA0+PiANZW5kb2JqDTIyMSAwIG9iag08PCANL1R5 cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMyAN L0xhc3RDaGFyIDMzIA0vV2lkdGhzIFsgODkxIF0gDS9CYXNlRm9udCAvTkNB RUxJK1dpbmdkaW5ncyANL0ZvbnREZXNjcmlwdG9yIDIyMiAwIFIgDT4+IA1l bmRvYmoNMjIyIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9B c2NlbnQgODk4IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTAgDS9GbGFn cyA0IA0vRm9udEJCb3ggWyAwIC0yMTEgMTM1OSA4OTkgXSANL0ZvbnROYW1l IC9OQ0FFTEkrV2luZ2RpbmdzIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDAg DS9Gb250RmlsZTIgMjIzIDAgUiANPj4gDWVuZG9iag0yMjMgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzMDYwIC9MZW5ndGgxIDU5 MTIgPj4gDXN0cmVhbQ0KSInMVn1QVNcVP/fe97G7gHy5iJLGtz4hRHYlfkVF g6vsrrA0EQTrrta6u4BZFJSgQ/1qBqMp+CCdZkLSiTUV05r6hfNWTIoZpzG2 WFrbsf6RNhmtSVs6ZtLQSaZa2+m09Nx3gQGmSftH/+g7/N4595xzz9e9b1gg AJACrcCgYk1V4fzK9qpigKxvovaJmsZo0yfVbA1A5icAZHlNyy7tXOGpU2i7 BSAXbWl6svHHd5eZAEo2gLT5yYY9W9IP2qYBpO9Gn3PxumjtT9u2VGO8D3D9 aBwVGZmObwA4uH12vHHX7rJVxmFcHwVg7Q07aqLTa6bPB8jIx3xXG6O7m9h6 8jPc34T+2vZoY93bGVuTAJxfRPvsph07d2Hd+Djd3N7UXNe05icPbQaYMhvj VcP/23PjMy3zkGpIiB6gG1D6NsTwfQRRi3gZuqCL9gofWIAwUQrCHXkA5kOz pV8A+/Htg7+Sk/B1S7McYmiPoXc/8mK01SAnVowu0mnxr8EhjP0p7aVX6BXL ugLjBrmHINorD6CexzsI5+A2uYw+++AFtF2EG3wXRu6CHrhP8pE6yB/IEK1A LeH5Mc429O7Cen8I78GfyVRSTAxyCX0y6AGrFpGtFX36kW5YUTg9ThrIDtJM DmPMQcroIoy6g7bTbmrSKywsFcsDSoayWG3AKAQo3oJ07JBHewKqMHMMnhqL KuiXhJJKUk3i5CXSjTX0kyGku9RDV+DUOb3IIlKy9KG8TX4VaUBZp75iUzC2 DArMAA1yYSF25ccclVhzLWyFvRbtQ9qPs3wGjkE3HIdTkIA34W2eE27CbbiP 00lF4n0tJkvJeqQwUjN5mhzCeXSMo+fIUdJL3sT6rpF36EzsWlADdi+qPEiP 0Av0Gv05fZ8O0o/opwyYnW1mMbaTnWCn2XV2XSqVuqXj0i3plkxk05pUhjJV 2aR0IHWqdnWbekh9Xn1FfcMxF6ZhX27sKwjrsas92Ml+aAfDOrUE0gV4HWkA PuJ9IA2PdMJpKfGRAFmHFCYbSIQ0kp1k91hH3yOvkZPkAvbyDtK75Cb5Lfkj +ZNF96lCs2jBWH8VtIqup9voS/RlepSewRvZSy/Rd+lt7HGQ3sMek1gGc7IH mZ8FkKrZRrabHWQ97Aq7yYbw3JKlx6RiaZ20CXu/Kg1KH+JJUpnJufIiuQgp Lm+Xn5Y75O/gjR6Sh5RkayoZSqayTGlTjim9ynvKP1SnmqXOQpqrzlOr1Aa1 RT2tDqp3bGftK+319maHG07DI/CDSV/v63i7f0Q3KYUwg9zE2/AUS0UvjX97 NFltsNfTXl6dWkXy8aR+A/eZHcqlq7CebYQGOcaS1I/hJNkpHSBnWADOwgm1 hVxiETbETsi5yjIxT3qEnVb3qBH1DlZ6l70gx9W5ZKXcQU7SFfhFN5NK+Au5 B1/BzLvoHLgKh6GdtIANumxnSQp+a/10JumQX2XnpW7ml58mD+MJ5sgD7FlY BE5IhnyYhXddhqkI8C5esnjhgvnzHimc63EXzHk4/6G83Nn6LJc288EvPJAz Y3r2tCzn1MyM9LTUKSnJSQ67TVVkiVECbr8eiGhmXsSU8vTSUg9f61FURMcp IqaGqsBEH1OLWG7aRE8vem6Z5OkVnt4xT5KmLYflHrfm1zXzFz5d6yMbKkMo P+fTw5o5ZMmPW7KUZy1ScOFy4Q7Nnx33aSaJaH4z0BI3/BEfxkskOUr0kjqH xw0JRxKKSSiZAb0pQQLFxBJowF+UoGBLwarMoO7zm2W6j5dgslx/tNasqAz5 fTkuV9jjNklJjR4zQV9lphZYLlBipTGVElO10mj1vB3o0BLuy0ZnXxrEIgXJ tXpt9Mshk0XDPEd6gbla95mr9w5me9x95LXqkGkv6SNQHboIweHWRFmrzxfm 2TJKQm2W+zR0n7Z3MIcZ/ux6jS8No00zuytD460u/g6HMajHXb425MKqdX+n xttYG7I6wKAkuxCL5Drepmi4TvdzTWSrZtr1VXrc2BrBw5phmLB2j+v8jKD3 4vAHEPRrRnVId5krcvRw1PdAYioYa/f0lnm1sokWjzuRli4mnZiSOiIkp4wX 6sZslmS5cwmrHh014RXpZXhFTK1Gw0pCuklzl/BX3RIwapagGz5hghOtx/lF jLQifhBybpquGfcAL4I+9PFETXREo+Sm3QMu8usyduXQPiqbBQXmnDn8pqgl eLRYWbG1XuRxt5jlelOaZpbjyKAihJvCRYU4cpeLn3JHnxdiuDBbK0NirUEs 5zx4CwvCJo1wy+VRi3Mdt7SOWsa2R3S8zheA/6Bzmra8sb/UtKxMf7zIJFmf Y64Tdvx8/FpCknONilBe1OjIyYsYnWE8mgB+ioYR0LWAETGifcOtMV1L041E ebnR5I+MttQ3fLkjx/R2huMEh2ouENMwM0tCLIeGhURzWNgDvA513j8rAJI6 AYavO963Khv//E4C/B+Oj4KwcRRD0J4PXY56xGUIqnnQZb8EPew09NvOQo86 C3rsqSPYLJDUhuiEHls/9Djegh75WwLcV9qBuIE2/AWjvghBWzfGPISyS9gt cHk16hFSL/QoIdxfJ6AeFpBqBbi/8hZ8aRS236NfKequYY430J6DSELdQtQd QO6ELqUMukZzyX8bwQACa1Y2ot45UsccUYvdi7GwbhXj2S4ix/7UryKex/UC 5NtFr7Zncf9jyLdAr6MA2iWcHcdoLpxncBKWTMA+9Nk3aRb/Y+BvwB52SvRs 5ZmMYwL/yU/ifoPjfUjaiO0Gyqn/NrYFEpuka/ts3/8Ottgk4G97m7i/8z4P DgXvpyLO3Dr3iXF/PSb/agQja2XRRNgMgTH73ydiTL8f+jn4GVvySuTjwG5C DXNCjW011HqTIRDAHjLSbd5SrY8+er50PrKDFiNnBTsj2CnBTgr2fcG+K9hx wY4JViZYqWCrBVslmFewYsGWC7ZUMEUwSTD2L/bLLbSJIArDZ3Y3mUmNdVND DcZL1nqDIr34YIOXJqkFa0qNVtCUoq2t1YKoKAq+lKAIilYXfbbetYi1qfVS iw9CrRb0sQpeQBB8s9IXfVDS+O/OqnjBCj4JnuWb/+w5w4E5u9mZSGGRVdCX 4AV4Dp6CAXAL3ATdoAtcBZ3gMjgNOsApcBQcAE1go12zW5buknJFyiUpF6Vc kNIhZbmUqJSlUsqkcCkuKYoUikSgz8ATMAQeggdgENwGN0AvuAbOgBNgH2he Uer3+D2LzD62N1LFzbPcPMnNdm7u4OY2brZwczM367lZx80kN9fz2WKWCIkZ YpqYKgIiX/hFntBFrvCKHCGEW2hCEXhH05PVuBKvjbF4+l4TxTeF0h9qC/pY zuq6tKsgxtJ5cYqvjQXSZYVp5ZB98uhj2R7Gjh0MWoeOO8RY9mB70NFkkvIL f7bAd3fxxL67NJMtIo5xYS+feZ9b0VpETTtqWlHTjgbY9QSVxhuPNEynXxT+ Zuy32e9mVrZay02s7xEUS1bUS+1VJuRgPQ1BIxnL13cusxe32Ai0Bfs1Yp00 AXuvF4e5icBKLYguiFop7FhWKtc65zmpQNtiI9jPOp2UjrAPrcT/Suxtagrf ehWLLIhM4sNMG2bnibQsubLqHfaGqGhsRB+h8ncYS4oX+gzfHMNnpFTKpBQa I9fQx7KUNkSo1YVdco9dy0OlvW78v+hjKyO5Qt2vpfBgGR33uJj1Y+PnPEWZ kbCe8YWpPIO6YV+4pJih7DxjCgama0s/DTS51MGPmUE2X1u2yXLs/Xju/+uH a90/d1mmOCctP94WGJsK3DS+Hf6DOf+yaTTfHjWrP6NGNitHfevXk6k6bg1B Lc5slXQix9fg647vhheyKmkeREJU7PgK5VLC8VXENzi+Br/N8d3wO2oqopXV VYXrWrdvaQa7x7unGqqgKFVSNVVRId6BVtpOW6jZ0d20hjZD99A2aqRd487+ 27zVhdfMS0XUjhUr6EYRhdGot+g3s7Jov0kuEvbX1H4cUqlFyfNiY/liP7a+ HEaR0dCoIVCWHvMSpdt5AkqKYtXd/o2TlrwXQWHPvth1cszSnkd8mGgskfOK l+DW++VZfxZgAPuJ8McKZW5kc3RyZWFtDWVuZG9iag0yMjQgMCBvYmoNPDwg DS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIg MzIgDS9MYXN0Q2hhciAxMjggDS9XaWR0aHMgWyAyNzggMjc4IDAgMCAwIDg4 OSAwIDE5MSAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4IDU1NiA1 NTYgNTU2IA01NTYgMCA1NTYgNTU2IDAgMCAwIDI3OCAwIDAgMCAwIDAgMCA2 NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggDTcyMiAyNzggNTAwIDAgNTU2 IDgzMyA3MjIgNzc4IDY2NyAwIDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2 NyANNjY3IDYxMSAwIDAgMCAwIDU1NiAwIDU1NiA1NTYgNTAwIDU1NiA1NTYg Mjc4IDU1NiA1NTYgMjIyIDAgNTAwIA0yMjIgODMzIDU1NiA1NTYgNTU2IDAg MzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwIDUwMCA1MDAgMCAwIDAgDTAg MCA1NTYgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9u dCAvQXJpYWwgDS9Gb250RGVzY3JpcHRvciAyMjUgMCBSIA0+PiANZW5kb2Jq DTIyNSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50 IDkwNSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgMzIg DS9Gb250QkJveCBbIC02NjUgLTMyNSAyMDI4IDEwMzcgXSANL0ZvbnROYW1l IC9BcmlhbCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0+PiANZW5kb2Jq DTIyNiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlw ZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDE1MCANL1dpZHRocyBbIDI3 OCAzMzMgMCAwIDAgMCAwIDAgMCAwIDAgNTg0IDI3OCAzMzMgMjc4IDI3OCA1 NTYgNTU2IDU1NiA1NTYgNTU2IA01NTYgNTU2IDU1NiA1NTYgNTU2IDMzMyAw IDAgMCAwIDAgMCA3MjIgNzIyIDcyMiA3MjIgMCA2MTEgNzc4IDcyMiANMjc4 IDAgNzIyIDAgMCAwIDc3OCA2NjcgNzc4IDcyMiA2NjcgNjExIDAgMCAwIDAg MCAwIDAgMCAwIDAgNTU2IA0wIDU1NiA2MTEgNTU2IDYxMSA1NTYgMzMzIDYx MSA2MTEgMjc4IDAgNTU2IDI3OCA4ODkgNjExIDYxMSA2MTEgDTYxMSAzODkg NTU2IDMzMyA2MTEgNTU2IDc3OCA1NTYgNTU2IDAgMCAwIDAgMCAwIDU1NiAw IDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2 IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0Fy aWFsLEJvbGQgDS9Gb250RGVzY3JpcHRvciAyMjcgMCBSIA0+PiANZW5kb2Jq DTIyNyAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50 IDkwNSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgMzIg DS9Gb250QkJveCBbIC02MjggLTM3NiAyMDM0IDEwNDggXSANL0ZvbnROYW1l IC9BcmlhbCxCb2xkIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDEzMyANPj4g DWVuZG9iag0yMjggMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAv VHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAzMiANL1dpZHRo cyBbIDI1MCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VG b250IC9UaW1lc05ld1JvbWFuIA0vRm9udERlc2NyaXB0b3IgMjI5IDAgUiAN Pj4gDWVuZG9iag0yMjkgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRv ciANL0FzY2VudCA4OTEgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTIxNiAN L0ZsYWdzIDM0IA0vRm9udEJCb3ggWyAtNTY4IC0zMDcgMjAyOCAxMDA3IF0g DS9Gb250TmFtZSAvVGltZXNOZXdSb21hbiANL0l0YWxpY0FuZ2xlIDAgDS9T dGVtViAwIA0+PiANZW5kb2JqDTIzMCAwIG9iag08PCANL0NvdW50IDAgDS9U eXBlIC9PdXRsaW5lcyANPj4gDWVuZG9iag0yMzEgMCBvYmoNPDwgL0ZpbHRl ciBbIC9BU0NJSTg1RGVjb2RlIC9EQ1REZWNvZGUgXSAvV2lkdGggNzQgL0hl aWdodCAxMDUgL0NvbG9yU3BhY2UgMjMzIDAgUiANL0JpdHNQZXJDb21wb25l bnQgOCAvTGVuZ3RoIDIzMiAwIFIgPj4gDXN0cmVhbQ0KczRJQT4hIk07KkRk bThYQTpPWFshITMsUyEvKD1cI1JDXEIjUmgiRyRrV2pTJFA9KmEkaypYXShf W1B0JywpMyEKJmVsI28nRzsydSldVG49KV0nYkYtUlUvYjIpQCRFMiozbF00 JCxNYzQkLE0pJTFXamIoKVM4NShhQ2RhK1hmKi0KNCQsTWM0JCxNYzQkLE1j NCQsTWM0JCxNYzQkLE1jNCQsTWM0JCxNYzQkLE1jNCQsTWM0JCxNYzQkLE1j czFlVUgKI1FTUT04Y28pKyEhM2A1IXRiUzZfdVcoJiEhKjYoITxFMyUhPDwq InohcnI/JyI5ZXU3I1JMaEchPDwtKCE8RTMlCiE8RTAjeiEhKickIXNBYzMj NyhWQyRQMzo9IjlBVCsiOUpgMyJwYkE3JG83bmEhWUdNOytWSEw1NXVEJigs JnIvaAoicioybllzS1pcJ2lNa1cxR2otKGQ2ZS1iUCNMbC9uUkhWdCg4QSpl LTpGJXNBND1BMUY+YXJgPFQ3VFxaXDY2RgpGbFcnXy1eOkVcWyRBU1pqUmY6 VmBSWClDPGI/TjBRRFYrMWYmbFpiN29zPklMUjRwSmE0S01LJkhEazYhPE5C LAohc0FjMyM2dEc6MiQhW1kmSGExMiZkMUt0QDwhSikiWXRYaydWVmN1LEpk OipuMXU+IWlHc081Nlc0XzBGIzxENQoicjxyPUsqTl9cX1U6aTk8MjE3Pzc5 KTZmQWBFOWVLWXU4XWo3PmEpVWtRMUBgNzNsP1Y3Ijptam4yWWRHKHU8Wwpb YDZuXHAqVmRoPShjYDRRYCU9NXM0UkddIXMmQicmSGBVRjU2MUBVUGgyX21m aDNtUj1QaEVnZlImSlQhKGA5QApEOURrWThSTUcpSitUSS1DWU8+OlhtVHQ8 MlJGSkdgaixsMmpsQThoUCspMjA7X283RWgqW1tzJmNhTWRBLXI4OQpcTEFz UjNQQG9FJFE0dEo0ZV4pRidsPihNKVJoJDcuQnVPUFhEJzxoT3BoUS5KPFQw bTQuWydfOXQ9V3EvLG9VWApjaTAvIzhvKFZJbUI0SmVjI1suWUNKLkAuWyEt VCtHcE9lLzhrRF9dQjJfaDdEbHJdYmsxOCJmR1FicDNLOStyUgpPTUB0c2Qr OEpXMjtqVDxYUWVfLSo+MjcvRmc2MkU8JXA5UD5WKEk1ZywxYUQ4UCFVMGYv L2YtW19TOFdsdD5FcAo4bS9pIltMaS43MWNpZjgtOWBLPVQnN10uM3JOS10+ MVlpLTBtTjc6cURxNUE/WCdESltCOC1icGIpNURuWFwwWwo1JVEjdUwlTyZi PUtdWlZNWDJURktERidtLGM4XlY7RyhxS0J1VF1gXjlVOkpbTWhFa144PWUs QzlGK2Y+ImRUJAonQVxmVm5PWjxRX1NyU2YuO1BqVUtgNSNKVjxsN0MkdXAs IW1KdDs1Rm5lNGRQYEQxTnBDZDxQJTJxTzVDI2RLOgo7SyZtT0oiWCJDZEpq My84UDhrPDBEWiVVITZjUFwnVTZTRGRwPzVmRmdablJxOllpOz9dW2lSUGEl dS5pRjtIRwokVSQpb29USiw/SlJxNj8sYTVnLXJyQWpYU1NCVW9hKE08MWBt VnUiUSVsWTtubkxjcUViXVJvMzZTaCEnREo8Igo6TjR0TkVHMT4mTSRZVkdT LjA8WmEjanFxY0lrRiQjcTtKNzFcYDVsOlJWK247Wl5TXV5cR0UqL1NRWGg4 bEE5JQowWEw2dVhiSFJuYGtlQFJnKWc3bzhdNiYhLkNLJVNWUCFgYT9ocnE4 P2FZMnJEWW0uSUIza0tDLj9laFcvbmtkOQpYSClARSssR1Q3YWdrTWpCRUol Z0JzIltpbmtyQmMhLEtPUSEpSHUjXC5WXVJmbm9eIl5cX3NxVkNdSD5FcEZJ bQpmOSc/bEw6Qj1ZQmRwRVBQYGhPdGdRTTdmbVslZWttZSo2OTgrKTZXLGMm c2gtL1B1MD9qR0FqXyEpbl0+QEFnKAoobVU0LHEja3FvNUlpJ2tyKCg2SUZs Z01raVlrI1pLZEBsVmdlODE8cnJDKD0hOXQ4X1VJRlNINjAlIURyaDJuVgpO LXBELyZHLEQjcnI+bGtWVVxgKGJII0tPVU9jcHNAMT1ESEEuW1w9KnBHLFts W0wpWCEtMVwmUCs1LGBCOzhoPApyPVNqWXBBWS0wTnI1aypbcC08UV8yMkVn bVZScSoxMiRcNzJKYDFXQEQ4IkNCQ11BTnBeXiVEVkhHKlZHX3UhSgpuKTpc UyEwSlFhMSMkP0JhXzpmR1YzMVFPUShPOWRVcStgaVxtIU8oaj5WO0NwM1Y5 PThrWFtTLnNCaUBdPT9WTQpyW1ArbVAqLnAnPElhT15JVGsvdEE8YG1Tbzxp LSUhRTAhOlsiLU84cXIuVjpEKShjMVZLTHNCKV1UZE8+PHRAZgo1OVpmakU9 IidZVnEmUU01UThsMHJyQWwuO19cM1JiMXRJKSRWbVZsYzdcbzVgU1ldLjdu cFpmPjEuQ3M3LysuSQpxdFo7ZCxyPF1RVzRMKGZYb15bZ3JyRSEzNVk0TyUw QnMhVCM4IUdRZlJOTzBQYSVXO0VaXltiRldRPlJeKDApYwpwSy06OVJ1JlJj LkhhdTI8T2dVOCRvJSZeTyY3clBjX0lMND9EZS4lKm1CY2U0PkguRE1lV0RB MUgqYkcoSExFYApua0JSV3JyPj4yMVRASSRRPEBFYitHL21aQTotPG0sYzhE W2Y0Zlw2QTJpYD9ELCpZclI9bFgxPyRSMHFaUihVMgpaNyFXbjhtaDlwZStB VUpPM2xNV2FYS0Q7JFJpNV0qQTYmTDVcaDJGT0QhNG1IWyk/YGIiPlEoRjNc bz1QMXEkXQpHVitBLCZga1c6OSlFW1pJYUBXVXJyRFVdLjo2dDJuKElcaDVR NDUjLysoVVtxYGlFSXJyQy5kVjEjbmheTSFCOwpyckRqP1BnLGFnW1lSIztr JExYSllVJCk1V0RaN2pZUmJkTlsvNnByOF9LNWVBJSNIUypwQi9zRSRiZzcq dSdzJQoscTEtIykiazhgP0BcM2lyckNjIjpOLCtGIV9RMlxEZmMyaWE4KSkl ITlsbjlZSSIsTEctYXE+VF9TPSk7J2RtaApEWW1RVmEuaUNsNUxMZ1FVNz1S J29GQE04MVxXL2pQbz1FTT8jRiVpTy5xKzxQYXMqREdQJXA4ITkzQUNbQTlW PwouN2t1MFU7ci1Ba05LRFEtKTdyNzczczxBPGdSXlgjRVhAcnJyQVdnO15U NTEtMihObypeYFlUJXRXRkk7WiFgNgpkYlhaTnJRLUttWituYENwWSNNZS40 XUdEZzxlWyQxIzAxVHJePCFjZ0cvVjNyYks5WixxUmVSQWtjaWlPO1ZIVQom YDE4OlBoOFEiOFBNKlBrI1RMLFxPMS10QmAvZStDI1k7REg1WVc3LiJCdV1x cEpCVSUuRihYNU9HYFNrcF1xbgpHUSNaK3A9VEI6UGNtRzlyb0ZbZkNrJGIn PS51MmIhLTNrbltRaEdPLyd1VEEhNGJKcmdFNTo4UkZQJSFacCo1NQpScCtz MURVXCMqNHQkKSY7S1MvIVBiYVA+UGJhUD5QYmFQPlBiYVA+UGJhUUQhPDpe fj4NZW5kc3RyZWFtDWVuZG9iag0yMzIgMCBvYmoNMjc1OSANZW5kb2JqDTIz MyAwIG9iag0vRGV2aWNlUkdCIA1lbmRvYmoNMjM0IDAgb2JqDTw8IA0vVHlw ZSAvUGFnZXMgDS9LaWRzIFsgMjQyIDAgUiAxIDAgUiA2IDAgUiA5IDAgUiAx MiAwIFIgMTUgMCBSIDE4IDAgUiAyMSAwIFIgMjQgMCBSIDI3IDAgUiANXSAN L0NvdW50IDEwIA0vUGFyZW50IDIzNSAwIFIgDT4+IA1lbmRvYmoNMjM1IDAg b2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMjM0IDAgUiAyMzYgMCBS IDIzNyAwIFIgXSANL0NvdW50IDI5IA0+PiANZW5kb2JqDTIzNiAwIG9iag08 PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDMwIDAgUiAzMyAwIFIgMzYgMCBS IDM5IDAgUiA0MiAwIFIgNDUgMCBSIDQ4IDAgUiA1MSAwIFIgNTQgMCBSIDU3 IDAgUiANXSANL0NvdW50IDEwIA0vUGFyZW50IDIzNSAwIFIgDT4+IA1lbmRv YmoNMjM3IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgNjAgMCBS IDYzIDAgUiA2NiAwIFIgNjkgMCBSIDcyIDAgUiA3NSAwIFIgNzkgMCBSIDk5 IDAgUiAxMTkgMCBSIF0gDS9Db3VudCA5IA0vUGFyZW50IDIzNSAwIFIgDT4+ IA1lbmRvYmoNMjM4IDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChEOjIwMDMw NjA2MTIzOTQ3WikNL1Byb2R1Y2VyIChBY3JvYmF0IERpc3RpbGxlciA0LjA1 IGZvciBNYWNpbnRvc2gpDS9Nb2REYXRlIChEOjIwMDMwNzAxMTU1MjA2KzAz JzAwJykNPj4gDWVuZG9iag0yNDEgMCBvYmoNPDwgDS9UeXBlIC9DYXRhbG9n IA0vUGFnZXMgMjM1IDAgUiANL091dGxpbmVzIDIzMCAwIFIgDS9NZXRhZGF0 YSAyOTQgMCBSIA0+PiANZW5kb2JqDTI0MiAwIG9iag08PCANL1R5cGUgL1Bh Z2UgDS9QYXJlbnQgMjM0IDAgUiANL1Jlc291cmNlcyAyNDMgMCBSIA0vQ29u dGVudHMgWyAyNTEgMCBSIDI1MyAwIFIgMjU1IDAgUiAyNTcgMCBSIDI1OSAw IFIgMjYxIDAgUiAyNjUgMCBSIDI2NyAwIFIgXSANL01lZGlhQm94IFsgMCAw IDg0MiAxMTkxIF0gDS9Dcm9wQm94IFsgMzkuNjg1MDQgNTU4LjQyNTE3IDMz NC41OTg0MiAxMTUxLjMxNDk2IF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0y NDMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIF0g DS9Gb250IDw8IC9GMSAyNjMgMCBSIC9GNSAyNDcgMCBSIC9GNiAyNDggMCBS ID4+IA0vWE9iamVjdCA8PCAvSW0xIDI3NCAwIFIgL0ltMiAyNzUgMCBSID4+ IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjY4IDAgUiAvR1MyIDI2OSAwIFIgPj4g DS9Db2xvclNwYWNlIDw8IC9DczUgMjQ0IDAgUiAvQ3M5IDI0OSAwIFIgL0Nz MTAgMjYyIDAgUiA+PiANPj4gDWVuZG9iag0yNDQgMCBvYmoNWyANL0NhbFJH QiA8PCAvV2hpdGVQb2ludCBbIDAuOTUwNSAxIDEuMDg5IF0gL0dhbW1hIFsg Mi4yMjIyMSAyLjIyMjIxIDIuMjIyMjEgXSANL01hdHJpeCBbIDAuNDEyNCAw LjIxMjYgMC4wMTkzIDAuMzU3NiAwLjcxNTE5IDAuMTE5MiAwLjE4MDUgMC4w NzIyIDAuOTUwNSBdID4+IA0NXQ1lbmRvYmoNMjQ1IDAgb2JqDTw8IA0vVHlw ZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgNzE0IA0vQ2FwSGVpZ2h0IDcx NCANL0Rlc2NlbnQgLTE5OCANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtMTY2 IC0yMTQgMTA3NiA5NTIgXSANL0ZvbnROYW1lIC9LSEZBTEIrSGVsdmV0aWNh TmV1ZS1Sb21hbiANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViA4NSANL1hIZWln aHQgNTE3IA0vQ2hhclNldCAoL1gvaHlwaGVuL2FhY3V0ZS9vL1kvdHdvc3Vw ZXJpb3IvcXVlc3Rpb24vcGVyaW9kL0gvcC9aL2dlcm1hbmRibHMvYXQvc2xh XA1zaC9xL2RpZXJlc2lzL2JyYWNrZXRsZWZ0L1QvQi96ZXJvL3Ivc3BhY2Uv YWRpZXJlc2lzL3JpbmcvZy9DL29uZS9zL2V4Y2xcDWFtL2Qvb2RpZXJlc2lz L0QvYnJhY2tldHJpZ2h0L3R3by90L3F1b3RlZGJsL0cvdGhyZWUvdS9xdW90 ZXNpbmdsZS9JL0FyaVwNbmcvZWdyYXZlL2Evdi9mb3VyL0ovZG9sbGFyL2Vh Y3V0ZS93L2ZpdmUvQS9ML3BlcmNlbnQveS9zaXgvTS9FL2IvYW1wZXJzXA1h bmQvei9zZXZlbi91ZGllcmVzaXMvTy9jL2VpZ2h0L1EvZS9wYXJlbmxlZnQv Ui9ncmF2ZS9uaW5lL2YvSy9uL2NvbG9uL2hcDS94L1MvYWN1dGUvcGFyZW5y aWdodC9zZW1pY29sb24vaS9VL2FzdGVyaXNrL2VuZGFzaC9GL04vai9WL2wv cGx1cy9rL1cvY1wNb21tYS9hZ3JhdmUvUC9tKQ0vRm9udEZpbGUzIDI3MSAw IFIgDT4+IA1lbmRvYmoNMjQ2IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2Ny aXB0b3IgDS9Bc2NlbnQgNzE0IA0vQ2FwSGVpZ2h0IDcxNCANL0Rlc2NlbnQg LTE4MiANL0ZsYWdzIDI2MjE3NiANL0ZvbnRCQm94IFsgLTE2NiAtMjE4IDEw NzggOTc1IF0gDS9Gb250TmFtZSAvS0hGQU1EK0hlbHZldGljYU5ldWUtQm9s ZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxNDIgDS9YSGVpZ2h0IDUxNyAN L0NoYXJTZXQgKC9oeXBoZW4vby9ZL3F1ZXN0aW9uL3BlcmlvZC9IL3AvYXQv Z2VybWFuZGJscy9zbGFzaC9xL2RpZXJlc2lzL1QvQi96ZXJvL1wNci9zcGFj ZS9hZGllcmVzaXMvZy9DL29uZS9zL2Qvb2RpZXJlc2lzL0QvdHdvL3QvcXVv dGVkYmwvRy90aHJlZS91L0kvYS92XA0vZm91ci9KL3cvZml2ZS9BL0wveS9z aXgvTS9FL2FtcGVyc2FuZC9iL3ovc2V2ZW4vdWRpZXJlc2lzL08vYy9FYWN1 dGUvZWlcDWdodC9RL2UvcGFyZW5sZWZ0L1IvZi9uaW5lL0svbi9jb2xvbi9o L3gvUy9wYXJlbnJpZ2h0L2FjdXRlL2kvVS9GL04vai9WL1wNbC9wbHVzL2sv Vy9jb21tYS9QL20pDS9Gb250RmlsZTMgMjcwIDAgUiANPj4gDWVuZG9iag0y NDcgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9G aXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyNTIgDS9XaWR0aHMgWyAyNzggMjc4 IDQ2MyA1NTYgNTU2IDEwMDAgNjg1IDI3OCAyOTYgMjk2IDQwNyA2MDAgMjc4 IDQwNyAyNzggMzcxIA01NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2 IDU1NiA1NTYgMjc4IDI3OCA2MDAgNjAwIDYwMCA1NTYgDTgwMCA2ODUgNzA0 IDc0MSA3NDEgNjQ4IDU5MyA3NTkgNzQxIDI5NSA1NTYgNzIyIDU5MyA5MDcg NzQxIDc3OCANNjY3IDc3OCA3MjIgNjQ5IDYxMSA3NDEgNjMwIDk0NCA2Njcg NjY3IDY0OCAzMzMgMzcxIDMzMyA2MDAgNTAwIA0yNTkgNTc0IDYxMSA1NzQg NjExIDU3NCAzMzMgNjExIDU5MyAyNTggMjc4IDU3NCAyNTggOTA2IDU5MyA2 MTEgDTYxMSA2MTEgMzg5IDUzNyAzNTIgNTkzIDUyMCA4MTQgNTM3IDUxOSA1 MTkgMzMzIDIyMyAzMzMgNjAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNzgg DTAgNTU2IDU1NiAwIDAgMCAwIDI1OSA4MDAgMCAwIDAgNDA3IDAgMCAwIDYw MCAwIDAgMjU5IDU5MyAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCA2NDggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0wIDAg MCAwIDAgMCAwIDYxMSAwIDAgMCAwIDU3NCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgDTYxMSAwIDAgMCAwIDAgNTkzIF0gDS9FbmNvZGlu ZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0tIRkFNRCtIZWx2ZXRp Y2FOZXVlLUJvbGQgDS9Gb250RGVzY3JpcHRvciAyNDYgMCBSIA0+PiANZW5k b2JqDTI0OCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBl MSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDI1MiANL1dpZHRocyBbIDI3 OCAyNTkgNDI2IDU1NiA1NTYgMTAwMCA2MzAgMjc4IDI1OSAyNTkgMzUyIDYw MCAyNzggMzg5IDI3OCAzMzMgDTU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1 NiA1NTYgNTU2IDU1NiAyNzggMjc4IDYwMCA2MDAgNjAwIDU1NiANODAwIDY0 OCA2ODUgNzIyIDcwNCA2MTEgNTc0IDc1OSA3MjIgMjU5IDUxOSA2NjcgNTU2 IDg3MSA3MjIgNzYwIA02NDggNzYwIDY4NSA2NDggNTc0IDcyMiA2MTEgOTI2 IDYxMSA2NDggNjExIDI1OSAzMzMgMjU5IDYwMCA1MDAgDTIyMiA1MzcgNTkz IDUzNyA1OTMgNTM3IDI5NiA1NzQgNTU2IDIyMiAyMjIgNTE5IDIyMiA4NTMg NTU2IDU3NCANNTkzIDU5MyAzMzMgNTAwIDMxNSA1NTYgNTAwIDc1OCA1MTgg NTAwIDQ4MCAzMzMgMjIyIDMzMyA2MDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgMCAwIDAgMCAwIDAgMCAw IDAgDTI3OCAwIDU1NiA1NTYgMCAwIDAgMCAyMjIgODAwIDAgMCAwIDM4OSAw IDAgMCA2MDAgMzMzIDAgMjIyIDU1NiANMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgNjQ4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0w IDAgMCAwIDAgMCAwIDAgMCAwIDU1NiA1MzcgNTM3IDAgMCA1MzcgMCAwIDAg NTM3IDUzNyAwIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgNTc0IDAgMCAwIDAg MCA1NTYgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9u dCAvS0hGQUxCK0hlbHZldGljYU5ldWUtUm9tYW4gDS9Gb250RGVzY3JpcHRv ciAyNDUgMCBSIA0+PiANZW5kb2JqDTI0OSAwIG9iag1bIA0vU2VwYXJhdGlv biAvc2Nod2FyeiAyNDQgMCBSIDI3MiAwIFIgDV0NZW5kb2JqDTI1MCAwIG9i ag0xOTM1IA1lbmRvYmoNMjUxIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggMjUwIDAgUiA+PiANc3RyZWFtDQpIiZxXyXJbxxX9gvcP vQRdZrPnYSnLlKwkjmQRqSxUWdAQRCHBYBGUVP77nNvzA8CNS1UC70Hf2+fO jS+TZBs2RSZlUCwow66lNIo9riu2m/7N9pOAECUL+Oo6/YUDhP+0nG5eOSbZ 8hMUBP5BLSgepPXMOsdtDIEtd9PNy6Nlq2M6IthxNd28vpPs4ThdCy6EUGy5 wiXL79NCiKvlfxMcNLvW3ETv2PLnclDSwcW/JJ25eWXzzdIlq/iQGgrOGtCV mjsTIl2+ePf+7ev3L3799ZbUZMinAw45rrzGaeFjOz0wWshAGs0zjfPBSZwP DvycofM4bnEjHX/6fHKBFdyH4J+94MPizf5p/Xh1LcNif/+0Oezvt+zqP8u/ TdeGW0/R5tI5TwGAlvI+BYr+Cilay9t/3C7fv3j16s1L9vLtP1+/v727y7Ep WZEqk1FMmsCDN2AldDghIzOZd49X0nO/OHzbfNzsH9hvh7tMRnNvYyQ2yIom Nh8Wmz37ZU3ks8rDer8+fD2y2/23TcX2u/X+6ZhMtGRpOBRRZ44brYbM5oD/ tH7cbvY/stfrx939/s9UCprrINPl6rQQtGQvvj58PT6xa2bZ3fqPp/Xu9/Uj U0Jo0hXcBOOa6uKXezC837G/H9bb7X5zXH1e79m7+8f//cjmUct1ig8UMo8o eeaQ8uDJ+ZMMvn28Up67xcM9DK4/st//zDHDGY9OQSKDMPaE+YfF8Y/D/ngo kepqvah74jRMRLhqg+XK+tRQqVk+LL5//35lDY8L/u3jmq8Ou5vN0wpVS6Zu l9Nv05fc4c5zjUCEiBrQkSkjeAQp1J3hXljqZ2XAxJRLAjX+D+jwvzwaaoN/ gWHk3ChdugI9pD2j2eAc82hTazVbYUS82Un28wGcG+u/fnkZNzL9G8aNhf9G M4d2tAqmIMPna4VwaHUxCp9+AJ82vnh0Fv8H49sYU2S3BpmYOG9RMp4pLqnQ peIGOYPtT5OX3GpXTjhYD5I7qxqw7YChJgfgUVvhEuAw6pBKABZVHi4AXaVe ewbUazG+kQhM3GplN0XwD2YwGyUPRM2ZFCwAAkzSASc0aos7mc9jZLEQuIi6 iasJlaat6t/DvAAFFIJEbTcRVryl4wXwmivUTtX2OE4ZL9aLuCIuoX8NZ7AB ksMe3CEaA2pwO2riAle0bHJyTaarrJfJEYxcUjaiO1JEMEN4ZejfG64wG51X WAShid2RCnh8Wla1KYq2RylJyQ1NzEiWloGXtTYFSaFLSCRLAbFIpgNXKQMZ 2DbA06QhoGb1DGhZ/UTFHXOzHFdo+IhYxVQaPmCxck+DX/PocwlLkYuoHtgB sZymIcVPOApnQqgWLiBZKyPeXEYkPSASgsmn54hGj+Xg2+gqUor7FBm1cjGd I/32uV/b5GvAlJKjrxIB8eOpEZGpLaSIvDTXCWBQnFXHlZo6RZAfDKhB6Qzo PlR258jgg8QdKld3SB5UGbHFuiMx5nwrFD/JMNjkFRTgR5qZ9QQ+RwNVJPv5 eJYVes+yrq5Q2oP9JK6mTqB9L2fqI/3V9Hmil51WanCoyioVAMnGqxQWav5+ Y5YzxTAg9A4Uo4EiVoeKSFVuWFfGp1OzgJG8mjqBeqISrBZGB1YpRzFtwVQy qIJdQqLuCHKLHUXzoyIklz7Fk6JJIGNSWDug6GFM2j5XnDDkcuSh7giTg1I5 ZGR7xmqbgo+FaXtH7oZTrQobQq93VZAY5IiAjxb9TKJrckwIT7LNVROjqg55 mxClqw0TcqkI70oMQh7rKss2aWRmZEPillnHjEj2GoiKarAC2eX6pDrOssnV YmOxqoq/GmOSZJk0sBjBh3g4ZZOMQZFdaQAcyJfitZhLwpdLQ0mfVjPZu3pn yOmnOU4mQ53aNqdbmyavhsRlZHuWyjQsFHVbH4tIr7JYlbMxDSSEkpqgKxLN DMHzPi2iroVni70E9FQ47Lx4EcE2LEpARDhB1EzHIumzMaloTs11gFh/ERm1 ciTOkWG4akyQ2oUxTSNCXAOgplWZf6gOmZKNI9q5E2Q0kzpNI4Wy12o2Leb7 EYhKO0shlr7cpkpPdMS4uRaeVHHmLGmZWbrI8mw9ntDJ3odS6K1aBqTsPu1L o58j/Xr8GHgG6VqWO+2fQSrHOZ/EEb90guynzt8zxqYd3NZJk/N6M7T1TN9+ hh4pbtyPBhUow3AC8migimWdNLksuKae91+zX/djI9C+lzP1kX7aj8akMdQd qnJZb5Ct8X37tRvbfgQl+nXYT3iUpR0sVLm6VOWy4Jp+WYBDzMqKbBzqicqx Whh9SCvSInN9fsAtC3IqO17emIRofxFpJWKpGy4jrfgsvbrniEi/DIY3JiE2 XkSalsGOVZeRfvvMrVSxTpZOa64OSKl9h/VZInyKdNJYw88gTcsGPF7iM0ih eMInc8SbSKsZx45URniLSHcRac9ehx+g5ZlyirR3b9M6R1TaMtt8ewgXkeY9 fvIE6S4i3de5X8lXT0+RzJp+Re4GBNWKtynJehgR+OkXh5GBcgdih0c1ycb7 MiLsIONBYGzRyIhKjUKyM6pNAboi2DYl/i/AABeabMINZW5kc3RyZWFtDWVu ZG9iag0yNTIgMCBvYmoNMTUzOSANZW5kb2JqDTI1MyAwIG9iag08PCAvRmls dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI1MiAwIFIgPj4gDXN0cmVhbQ0K SIl0V8uRBCsOtGB8aAceAeIn7JnYjT3MXNb/w0sJBKK75phZEvoL6vX6Sj0G 6vRqnULOL4GFJyzsYMbX8vqGfArEaTM/jlkqKcQuMIWehx4RiTfGEY0DUz8S wK2zHlBHczgHXvIT1xBjeR39GriRszDxdDJpUCYBF2ubJ1ByuIRSZlgI1DE/ X/8FV9SeaHVur19lOObN/DimBGozHfhWnoij00JF3E9MCpyqV/ogcqi9X5Y/ maNkEXwyZhtxMlqAfZhs6ckhNnVQmNYfmR0EmDH4kdnmwUS+mRhSTJovKf5k 4ngiThAj5PrMHNtXUDPOiiy31Ve/DiNvaDvAlmZqCA2cuMHXtjGaBEytfEk0 f4DB1bcbE/q8vo76HLV9vsLvr+PA+m7umbp3//vrf1Ao+NJdQIbXIAEzu0Hb FvcockeWqpPooeTqTjBsIRleo7j116C5nK1R3D6YhPloJ/gYvqVMAx3RTnV/ HbOrC2b8wWALNVYGaeT6yOy+ebOlbTJwZj5JNThrDMSxnxYYzdps9QiIXukS YKe+0EqnwVXhrTsbwM62/ti21+flmCk7t7U7RgnDx7HgqizE49nK29bujIFK 9+EEemg0nL5hC8XwquvWX3U/iVqNYQ7Y9+WeqTvnpSsoUkhUNZEN2+D3YgY2 CEXZNmlnXnDr5GojDHG+JJI6heIgdwfD6lgKaZVgZFIBSntkp4V+KiQEN/cd HvZ5M8rkejxaUQVjcJvC1x89opXyBzNaVgb6j4R1sRC5jEcGFnkzmd+YZFor H9zP/hBc13Uyu4RiDJWyk4ghry4pvTqMjNa0NPLqk4SzBbd8+kSjrQfPHNVc nQRho0yJkhycjfH90So/2j4t5ObvcmGYpxTBtZ/JjHYxaOI1zHPNUOSQE18M VuCwEvLFnOS3UP5gjhbCaeU6+fZZlxPSFeFba4itkMy1YyrpUnNMqpgl4CTX eUO/wLrgKu+phb9Vg6WMWwLXdO16AhaOhyXqKnJMb9OEdIxgHl2xdlvTIf/+ GmNWGThTeQHmRAobsrkhdkQfU3wSXSMB7FwUljJPr3JnLDz9oVKdBPqxJcWp OIiMqgHPyDNmZm1I9R8ZcV6DlMsCmJFPdUPqs/DMI+p4SaQ0rTTsEY/zsMwb kxCpYllRwDFOXGeiuFqkKRdl6kjqpszeZORakKFdmad6ILqj0DpAiRx6nOKS EsGZ8jSoqZ94lk5unUUAUp3fe+ED0RqcprgR0qA/Hy0721g2ME+fWe/4zWAw iviNL9WnEhkgvpKNJLrvTQfp6BueFpa8MgWBvEzdOt6OPzNhDhwJ8up3BHrj RiThLSpjMIos5SzaCCfbx+zMdsLyiNSdRNc9eU4wfOIyBs9LHq9zgs2C2TjT Yl6YhHlpJ9xx6KssYS+vGY0k969nWkQFgMtwFUvSqb5gKYZO3QnI6p8SRXp/ 47oePJtA7HkK9HGKpBZK8kUTH+iWaHnmP7Ybj6SLIOGmyn0zPxczdSiQr4hY 1W10ajbC4OxqNvCsy65mhk/NjLGM2wmrItvGrhm8yL5m4uWV/YOlPt8fFdO5 S+jaOO1kvDskn+P1D5LVX///jwgQFntvW+DXMXicJn1GpzGv6AdGbipdSiS7 k/5g5E11a70zSH3NqpW09E9MDkV1WF7WH3D6//MRkaaBsG3pjtKYHRMhVXeU m1mmCGPSPuGRz1jR+ZE53t2eTO9w+/V+eYd2GXMgOevvDhh5PhwiR1iv/uiM zZ7TxeBWlveb9Lo+HA9jMYz5wvvAW4MYu6FfIdzuaggZT6BafAiZ0YW3Nzhp FbtkMqa/ESNfxjKeArF4puDGvJSE4PTGNLp0kBrub6e0Vk/gYqdfMK/2IDZH cqoXg87zKh1T1S7sU6JpKujqdPz4HMca9Rng8riZ3VRlYCDqI7NMFzxaH/HR wFZp45HZKXrzRQOopNvH+wcb8RrAzcgbRgncoIWeiKODlfAHs2LYOu8Yco3e 7L4zpmPev2MfIesP6d8lavg9YfIpwHF1PY6b/kco08YjswPENxrPzHJPrhfe +F8BBgAGuzxVDWVuZHN0cmVhbQ1lbmRvYmoNMjU0IDAgb2JqDTE3NjYgDWVu ZG9iag0yNTUgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0 aCAyNTQgMCBSID4+IA1zdHJlYW0NCkiJdJfLbiU3Doaf4LzDWQfoapEiKWqd RdaDLOYBjHRm4R4g8fsD4UXUqSo7MOBufdaFosifrOfzAYIHtf4UkQP0+R6g T/gK9INiDIfIV+Nx9AFrBSueyI8HDDg68GY/g+gQI3RQZ1/nZPYLMesuO8Ho ts8FuHnzZY4fNE7DdhDPy4KrJWmdHKONuPQYGtaNo5Fs8h5EWDfx8UjHdTgN +SCYz7fHBnR0wvi7QNo57ZJxgPQ9fjsZkeT9k1nvj/8Z42M2zQs2WKaCzE18 nR6IL+JjjjEdzZzzGpuxBHF2ETmkSczoWG4LYxH28O1kRYD3T2aFV7Uf3OX8 5pvYhTK6FA+A+SXhY2hcx1YR938hgPdVd2KX5r5WcUTyZ7KiRS028PNwx87t Rn7Lvx7zCXbYU5Ge3wDsrf/+o9jPx3+f/380G9gpan/6Fv+zCc6///rBz7eP J8TPx9vj+2+/w/PPjwd2Cxb35phHG/y0oJ/2Kt+w25XYl//45fGfvb4dyGy/ afjv0ftlL1Vb5HfEQ8Ok3vhoTTZ5PxGxoPSr4yTL6v4lsf1GLOpH0/EFsAxD y7nTmi+IXSVCujcjY35JxF45zq47fCb7DuYRHHSojNNV0RZY8J6mOaG1cEag OFG9AE+oBIMX6JMiLhriIoJ6IyoZO03iqpZDbUoQsP2S9DFuRCADEKQvosRB EAJ4DGQyI8siHVI6zOeL5JJOc41HT4OJasaUlZ8xRS1qWtrLkcJOep6TlthY MDcZSIvosnZE+KNlSFvWqvAiuHJoQs2hSsRWc4RTG9vURZQCwAx3WvY2HEFQ ZREM3TZBHXMRiiuQidcCrHmSQF9kibALaYIJua9SEnN9y7MnwSJIFFrStEhX DoL53K4EA4N0KTJgVQDmRXSpFE9ZZM5SsjSQVhKZfi4n241xnDPPSJesPNiK kGSR7sSLSPhC7DmxyOSU9FFnDU2tXS6lyAqXs7acYU4YKXDY8yhzwghAGY8G AJK4RiXBrMljXdMA55S5rmluCicvrQjAMaZW5/SZauKSfCWKvAjFw1hKQL8R pDqbZgDS63iuwF9LrDNoeid9nE82wHAD8iIcYLysbbmJKl+I5ci23x3lHUgr Y2HpI23zw7tGWMuYhjnHxW09khdna33aeoH1kEaANgkDLWvWLe31KecQFhHS ICxFmHPVyu8VaAa04ixi0cCsJaa7Kd+91kBPgliLWoIuOzNmaj63IoOTCFWu RMNkZGgRGhpkYpHendgBlYTAEABbpXdL0BssBdDwJ0Xzk0S8qhthLSEhj5rh lYhLfST3USg9CoUyMts8idjwYtpL57ysGgEq0l02jOCKNTBvaZBesqucgLbs hhAbYdDSd4UgY5biCyXRVISsCT5ORfWqITeAacrstUfri2iVJ5/sdbelqhgZ DDfCQklGFT7CJIC1j183yKgyF8XxREb40cmuqENuIL4rHIicC/OF+MM76VD7 NrmSLPgOpFoCvgHv6aPdyChylxDdyLh0JKHg+hU5NR/XBsUbeoxvnC3uPzfY GWaLAC7AsicC7TQjtn0BC0FeM4gW6UshXoQlVUTn5UpnoHxKfvfCPI8lcj5A K9fi2mPwdi7cCTOeRMaA57wDkdrGcz4IyPnNtlT5s+YmjPXO4PXX3TeusbAV z+OlwZ3M9FTv1ezROmop5447I3Rp/1xvZ60aeFFgbwghvQepPNUivnTbY54l tH0KVF60VPsJVCS0aOv/zh0jlYKuLw4G1hTINaKXBDTQKwFRszpxndNXKZo1 I7pVL1dz3gnXyZnqu6Q5GVnkEPBGIOXfJSMiGiKyr2TVyi0rzToSvZFVYat7 dtL1RpjLExLJbd9Hu8Muglj3Gi2rOWyPBrG2QVvtHMJnZOynKsLb67WKOt1I 43k+3bqaKXIjY0tqfhXYv9d7Gen7XuENJwA3gjDOXt1d1wm0cXkuJ/0CLDS7 nN/YiOolDpwQ3sigPacnaDUlAs77Rq7ni6A0wtul8aVgAGpKRLa3nzuS86vK EnfUnEgQJ7jntFyFWqkXiWYEdKenZO+78mzlqzfDs0jk9Ks93p99NQpdMOme rRQntONC8tOxeu6SIAPjWrKcQAlOSNmrdV9qdwLro9UAlhaHZPoHwCrD9rd5 +SQo5TVCW8FDnS8kap+TXvvASPv6rH1avxKOmnH6IFnF5AKi3nihy48+b4II bwSWczD7bO/blskv4jJy+hq6VtD3x49fHrav1btXNbayStbLeJV5VWO2i8Xb bGIfrdQuVd3msFyqOlvFITo7mqY5iM5zbqeHSe3pPx9vj++//Y7PPz8ewFZO /ZmBIqR/BlFNQpZqPh4WnT6WkWPvWWv89o8AAwBAiE+wDWVuZHN0cmVhbQ1l bmRvYmoNMjU2IDAgb2JqDTE1MDMgDWVuZG9iag0yNTcgMCBvYmoNPDwgL0Zp bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyNTYgMCBSID4+IA1zdHJlYW0N CkiJdFc7snM3CF6B9+A6xRlJSCCtx5N/UthN9l8ECZDg2Knu5TPvlzjP5yO3 duWcn5jrhTSeudVrJFx0Ld3RcBE8Xw8PJCjPo6Bc1IWu9dCvZYJaCxwDqmjI Ro9F15JNom7gLQA0EaG+RLDQUjlaDkYnLSpK6oEjq9v8f6A1LgPqBUkYREG9 goVFCn8b5H/HPkS806Ip10WngSowMmzk/fjDGF61SVyVyvMTkLGSg1crRaTS WDRS3/RrSXSogWME+bH1C/dwxTNZzhI0p11o4Rf7h8P8Mw0+gtfjnyVTKN+i EoS1jLykYAzXEseuNQ372dBx0JV6dRqMPpEdZDR4Hg31ylhC5iYtNsSLw2F+ mwYfx+vx569lppI40hOt4OjC1jfydghcvTZFtKNHpeV9D1UlrlYOVe08HNlx MN1INZRAU98SjYIb/So6FXeEHcstIGwHl9qszSQpYcdayBl7jhAYZDJZvi8S q0Q+yyQCgrAAWHYkg9+IOboS3a/W22b7LGT2tI9n8DT3G1KdlCCQ8g1Jp5UU gBaQfhGOIBTdkfEd1yiSzsZp+ihSz/hhimVkOtfqC80IRAZArVDPSuM28foy +p4Tx1w2hFzMjwcab/G3B8yvWk5hvV9W6MGFdhxME5AbjkPbABpiI2oadIS3 jT3kM7iOgaOZBg560SheZ2wmMYogHTUwQF1pKgP57KtpFEfYaJy/0dxGO/lM FQINSLeMz/S+7/mWfmVshL2A+crFd/VB9l5gpOgztBbDpHt37ZAvIAr9kjnf FDhagbMYHK2LYSPeD0r0E9mLYSOyGJh0u3Q6kQ8tRqCMwFF06uZemJHn6vfC RvaEWQK/AL8VsFypaMI6rDQXttQ28g5Iwh4QVoX1uejQeOWqh3wtAetEY2hd ckhDaITjm0gYMrS2jCRwrcg6dEGriv2yms0K/mfo2riEjuagGii/ISdw1Mvq jpykmtQvpPUc0vULOVJSiG/ErPOGRPa2nJXNw8hPtLTKv3+7n/nahK4/p6tw C/LPq96zjcOF5BBZZdyyzb2lOP+GCwlnT0LgsIlZCjapi+wA68TZ4lZHM7BX ynbBOI6LoiEGsY4kxjDlW2CC6P6cUsUdSc6udWm9tTGnMbsjadM+NEPWFt8a bGxP8mywzQvjOH6LhhiHHEmspqe4DPmzoYeXeiNnGbYr2YkzdyFf5KGw7Zwq Wth2Qc2BYx7fZxce2nahIccNvuMp/0TOLjREdyF/C6A7kqZjMWfs+YDAkPAc STNyCkfSRs4wWQa/kbAO+YAvp8KfgEh3Mz18jvhMrvFFIZ5tCBwF3SeEo62L DiL9bRqs/83GmRDzwjiOl6IhxiETwgf7PTT03Y18o5158FZtPog3TQsctYHT YLSPzBDpbtNglTzZs1qbF8axvRYFIQidDr6Z3Yv1WcjIYW8rcJqSr/tRfyJH qPOlO34ip4tM6hdS7/Rc1jg/CfQxqHnRpdRNv5ZEaRQ5tOXaKjZ7YRJFBQxA NEd1hJDMxlB6iA89b1oKNRyyEzZfLPJk5Yl7PRxgYVsRvhH/fo2dQGxSKkNO IcbVUv+JzG0LhmTwCPGXge5ulWIEUv6JiHVB8v8gwEnfmgd6hK1jCVK3uFas LNe7yBF/sX0WMvQ67dzji6Z2NgXNGw79LmGkAAQOSLrqMgWaKKuEIUgSdeYZ kxsfs1jFri8M94+n5zX9ehyE55o39ooku5dzaizhvlue58BRQKtau/ipCo0f INzQNK/qdkdsQYPoqMMOvOZo+dAQrYZQr6pDEM5f1vw19z5vv/f+mbGS50gX 2QbjLl501jeQLFu+zusD0lUh0erzmZGqn0Uc1bLc6tngM6eOFr2juCto2tGv t5RroPN2RAGo2k5wHhrv1PyAeX25KW8gg710v06JL1G7JGQROkQ/CTainwST 7r5n+OLVq896hu9kiBzQ9XUZQlc4Ey0Shug3wUQSuhyxDrQ+W5R+MQ4zWaD4 37O9ovObYNP6TfCfAAMAk/k16Q1lbmRzdHJlYW0NZW5kb2JqDTI1OCAwIG9i ag0xNTQyIA1lbmRvYmoNMjU5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggMjU4IDAgUiA+PiANc3RyZWFtDQpIiXRXO5JrOQhdwduD 4wluCUlIaD2u1zWBO5n9B4MEXKDtjlznGAHiJ+7j8QdmvWDBY0C7FrXH6zC9 jY9Mv6BNZeTUJwYJlCll/sLYKbio0kfGrH+dc1Q7c/zL58sF1B9wtboe//0N f3d2k/TvclXA/ffXPyzR2AVR2md9fCdmQX1sPFB0lLIOJrjh8xxYYwQB/m01 KHC8TewTzuxf11Cv1dBNCBQT4oMLmI+mIN7i+effc6aX/uNmwrAWTsg51cTO pBrNbqh+0goCnUM3ggLD8WbGLGwP18BZHDUGb0O5mfjgAua1KMi3eErS+jVO tUjWvw8zF9zMKzBssaMyNDUvfR7fVkosXqX3lFm8oLckAec2W0NNeNJ9QiNm fuDVZvvI7FhgYtjOOGqrFpTEhB2jmqLGri8MEny1Ie1T6MCpFcwhEPmZe8ki +M6YnyfQyBr0gp1OoMdVQBga2xRjohCicdW6UhDH1fpIEr3qWIGZ8JygJ4wZ U5wbFyAKA3QiMpdWBdaEgftdEiEMlyrgkVin5ayUWWPz0harVUeJSTSUE9RJ /ZRELjvQ+0iZHddo9JMBjWoTJaOgKsGAuZG50kSrMZOH1Ssw/YT+2B2xp8xx Lw++bOo65GT53D64acQtWjHPrzM/PAuFi1Ny31CiXLgnj+Exw1TimAYslykN gwTb0cos0BOG2xElWtdyQp+d0Sms7UexbDe1bucFUN+eBeJ07bnPAuuqS1ts SmEzo6NpO7ou0P4Yc/tBfBhuvO3ShROTRFONCAnWbgeE4RjXKiYaaZX3hCtK 9JwpSEeiaAGqCRr9xmJiWAJUAodWFw3FEtzSzKfpzEsYe3tWlyOIoSt2ILxL 1MtOQWJdDcwJCridVMoJY/Zo9lAyjrCf8sqx7me+8T0VWyB0VdA4cKCq/81o SS7bmBJoqHfun2/V8NIKoeJv23di5F1nPMPrQIWtptFHu/AwSVQE1xCwvp+B OQ/7rUEb6LbhLWZeWIu5l7Ia5HvIarCuUeuPuwljL/u6Zsh6MKtZZ6bpc2ES 3Tp9K7hxvJox52W/NeiQCuGzMaZO2BRzr2U1yLeQ1YCAB4N2WT9Ti5luWeGC ZtjsLTxm4byAwSw7QriSY7NBctywX202SJcXDRYcs+HhMy9cQoPHc/ogtVDr NHmdg5t5CVPN5jxnKsZKcZtaKezVCmvlwYCp1gz7vYyxel1h942xs4rfXiSB VsPCtHGfd3aeb/k6rcfclv5tqb///nWpJ46qvqHIa9K3MmGp33iF3Y/2e5xv wlFZsbv3E6VDikCwm3i+GT1vKAu1pnsKPx/ficFKJ5HOiGuc4hLLz12zAq3X 6FkCayxQx5ZIY6xATYOVn9nwAuXrxfZuXm2nQuV9Pg/3wPuAXB/4rZGLgdZs 0TMSUau/etyNFcrW5koSM2xHETd5GQKzA/x6C7nsA0yi7z+ShtnWzbwSUwYl pp53dmOqkGIiS7gHjWtlhiWTMYB2+VI8/OtAThiz5CtlM7pDSgxY59LJLCoK DoMS92VbgDplW+ocAe8dotkBZezq5sQ7c38e3Kc+MUiQAvaJ8VM4PhFm++tY R/TF+q3/7e/f+5+/p2pq/03U0GPIi4Q/1RujjhRrf9SB4RITV2h/xiP3fzIq 7c/brHaJtb8z1v7OmGtkgR41uWbtvz8Pe5KANkL7O7b2N8ba3zRYnZoNr2S+ HmGSWKbh9DJq1Xn/7w+u1P47QjO0v0XUCpuNDscaQftmUwmNqHT/Da35b8J6 P8dbe39yBmX0721zJ2Gw8/pK7f2TMYUQbyyfcR5y/shoI0lUexz2d8yNtw09 YETf3zHbBNqc6gnvPpATxpQ6j8QccVqyUyNPy3FqKEp0LdFy6sC/jMBM2McU NBk2/EUHmlaQe3VNs6Sdjc6RCoPdpCjB0W02wAI8r+PzTyRwyMX7lKrAuRIm u5URS+SxxT5kj8KGIQdmWsPZw7vXc6jnWuZTqAiZOcQDhO6m+U6MxIZxWubp FFn0hD9T1kwSkjLXYNga0xlZwUyDpdRseNLNC5cwL01DvMfzfwEGAFLMNusN ZW5kc3RyZWFtDWVuZG9iag0yNjAgMCBvYmoNMTU1NSANZW5kb2JqDTI2MSAw IG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI2MCAwIFIg Pj4gDXN0cmVhbQ0KSIl0VzmSJDsIPUHfoewxMrSAgPNUTMcY1c6/v/GRAC1Z 1Vb3ewViFSIfj69/X5n5ShUeLdcLqDx+NqZcIvnRcW5lYOIyMECe+Dk0KMsh wUDHCYbNhmkEI1gf6wQYtpYNw6ZhXiyJ8DtO2ON4fn3/USW5kogJcR3ByVUT TOa1MeXiRM4A80dm16JUPjLqYD21PjFwxwyPjrFYGhDywC3zxM+h0TCfEoyG Kw5MoVFcIYjWwtFGYAz5EaU6FnOCcGI7o27MSpkaYTowJA4NZ1boVop3JlL4 /ZUlXVTcWxwFm8wshuSrpfoLI9QGky5xrTtTNWGhBUPrE8N417ozVjLTQiq/ MD2K11tcFmuZMaQr9/LrnWiP//7ajxc161MUHInoTLN0Zb0AihmtbCnJwMJt Yi2C1Ctj2STqVbz3mbNjmTaeb1ZffUCoVBVLSr+SPweDGtTrYMw3PbnRuqyb b36du6XEhwTyus0L+sAIwifKVPeJMw3MmdRdKNtM6i76AZrFDiGZhdwwFHyA ZG4eVcl5MMl1LJ96Rr9rilNe2LzksDIkVj4T1ANXzc+Z8Z7d11u+X2OQSe8t IwnsXigD5MXV3lFcK24JVV7wSLmWPbdNovf9nvOFI+nBRNbjhMhp2FhZDy+W BOCedpiDtBQKDW/CzrwGU0jcKg2dkve0L6uRdo2gylEYJhvOqZYDr8iCiYa1 E+KqrOzFZVIvEh0Shf06gkUaD0uv0POtZnbnwefAfJCUkUT7Q7IxqfHBaHs1 q7Xw3v14vNDdNmozyyFR2Osihmttc/6YRjACOKwqk3DLqp6BnmU/skBAOyHX sv+eJM8RvLCGhdUVgonQw4l3Zj4bU+sTg5yPhH1iQgvmSL4z+4OEOmjyTNTP YNhTGc9PMFpoDK+FYWuOdiWOp44H7s0euOciGLucry/T2RYeWVkYFv04Te3z cCHeu2D2NFko70yE8j3MIqz3Nl6mqrNUX6b1sza3Tjr7OekFxfFw9VFFWv5z VJG6so8quoj2UUW6u8AxqkhbrR0SueyjauG40MHEqIoT4gKEjXVFwoslwULb qKL59MeoUg04RxX5chWjivR530fVshqjinSV4kOi5n1ULbwiC8ZGVZwQg2hl L0aVegF0SFDZR1WP4xxVZ82sEXQFp5DiUUdlxPeH1ruYL2z7BqJLfDo90TW/ lEOCJXYYOjBRDg1nGlmO+Wq+pWUz6jcHsOww6zCyA4pXMeP4HY5FQU/L55Ol jMghwX4CA7uPvM851n/2W5NFrpzrjUniTO2HKI4zcEFbC55fG0G+QjqhicuW OIF1RZbT68pooO2UqLCG68DJhxRFpvYC27K30p+oetG5WNPb5dUiw97i6gnU o8W1LfIhAOg7UIYD5+mHExW8jcr6Wtx9wlJvTdK99BVJP1v4fXDNlbqktbnb t8Viom4lqUIqvzA2WTuTo8VuTHxJdKYd3xY7Y18Su9adiS+JzvSL8ZmxL4l7 XK8Ra7n274ufwVRqR2TBqP3x4ncGYgvXAdIxrvvcYStrSXoOBdqYgQnnpNkx 8dQgvLkhvlbcmb5u4sGonTaOZVxP43CsrY8JM9Mf/l0C4mOJB6zxLSXZFYyJ x3Gl8J2Zz+UfJfXn2IlHnhdGnQAdJ7CAUT8mSurZnrBb1haBfAggWD56P++4 CblGMERlSPj2x7UOSNHVJK7A/nXEYD6Fj1xO3A38M6cyev/KiGsxVlq1kny0 6+QdNpJMbFb7kF8S9vyvExZu3hyLgdoe6wSdDIibDcNmw7xYEuFlnLDHYbHp pj47wyvGq3tWNvrfbH76upIg3KzeGR66ZNkOUDfrak+v8fE7gHcf8YFbi54I BouVFM8gfZQXjobIvqo0E4Bqs1+dPXBOUZtg+lAeOL6p0JuQYrmPTNuU7l1l Gv6lS0Q7bBg95wSwuYTVnolK1XOEEz+Pi2MSMD9Z0MsQuDG6RjCSonDudDMb Usp8urxd0MO2GPwVAdxQhq1mCsUS0mszUprFsNjZth2Os2udzMD+vJZsrch5 Ye+jLJuE+k/RzHLgJiVy5AyJS6A/Ic1PqGUO8Of/AgwAhnY8pA1lbmRzdHJl YW0NZW5kb2JqDTI2MiAwIG9iag1bIA0vU2VwYXJhdGlvbiAvQWxsIDI0NCAw IFIgMjczIDAgUiANXQ1lbmRvYmoNMjYzIDAgb2JqDTw8IA0vVHlwZSAvRm9u dCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGlu ZyANL0Jhc2VGb250IC9Db3VyaWVyIA0+PiANZW5kb2JqDTI2NCAwIG9iag0x NTM1IA1lbmRvYmoNMjY1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMjY0IDAgUiA+PiANc3RyZWFtDQpIiXRXSZIrOQg9ge/gdS8y NCJ0Hsfv+At70/dfNGIQIl21quIZMTwQIp/PR0ntytCfkOs1Bz5ZnijynCyX Blt+8YkCLWrEA1WlqupLXm7K8/349x+GgH2UC9N4pitje+arlvn878/xc7ta Rf05XSX39TMb6FcdZRv4MNI7bOR9IPXC1hWBqpG28VwyG2lXSpNFpL8mv/jA PBCWu3LVSpAH7hOMeBhw5Tp/RCiw3ANCfuC5xFTL5owDo3hNFjcDggJUITkh i32XLKu+IHSgGjtVk78jFigTDdfImU312ZnohWiBc+Fg8WAIrmmRKIfjSvPk cFxZKEPMKvbt4PXl8v34y0aqUtZa5jAc6dR974BIYIM6ph0keWjGIlzQo0Yv Qyz0GuQ27IQghZl1C4Ua4PQhsqSfBxwaFKVZABBZ81/XUE+g5J8RNLPcpW+T nhFKyUbt4rXjlpVD7EHDOE2tBrnCuLG+GH5/ca79MKhnZ+gHQkoJtM90dgSS yxw6Aq9y0yianrQE7vliLRG9SksghYWhJRyxlnBEYkMi/7xYHpu1xKCLVQ+N QTerHy3hsrWEIdYSZsEKbj68JSg/bEGjmQUuL8lQQ0usEzO0xOIIjpYwTq3g 5BVGaAnicNZDwzmVlnDZWsIRa4nIubYEUgPUMIsnFXaEkWcIDUqiUZCc4Bil k26r9N9EZLm2ueXXwxF7SfhMOotFNovPNPaatTXpDr5CHAs5I/M5aPl8I3sy PkpOdDvKfl0+jEiRqK0JWXIGCNFN8OaTaEZUgCyhJBpcLi8Xqm9AIybYw7AC tSCvyF+PE0k0dZaccBxNQDFhbJN5YS9BY6A0Y+ILQHKTy5mHHugD1GlXSkHa Wy6dZqndntN5FxZp+fyRmk+btB1iXW+GqBvQQSjCpG/FmEHGnY4CU/XhfPIp /xae/MXQHK6xGLS3NEeOx7QTZydId2R6b8seE5+AMCskw7lakDx4DfNI8jVL DhpSK7dgso6iA1n7g1vQWm4fu9o7CtewKM3CmcdrDV7Cqo5rz63a+7NGIMkN z5K7Xyt74aHjGoVYzYcFkz03R3gQbwt6eQ7+9HbtKFzD4hYLMY8XDzMy24pu N9T2H0bA1lvk0bWRPd7Wf7n8iPipdQXhR2QPmn3qJ6TdZWxMA3ahoTchbray ZSFujn5okFd9fTuXfM1/PSG8OQBgCU/dx2GYk6HylCB0xVuyOIUDccrICY4g t4R2QhFPvcU5fCuO3DS6HV2j7VIwQ7wYje4B/ILoO0BIsbl3Q+oFaKeG7oPf CPb7qTsiJRMEJ/yCgLyPt7wkV/ouQGdk5do388aRIZV3REWy3c7FPX07VDju PH08NJdffKK3ETS6DtGUSpDX7q4nUr7FUfP4EVkPRQCoLNzLncp77EUrMN1p bGwQMnvQ2A8ziIWpU6RXPaCAFd4o/EYsUB4DtOf7V9yHgVHb7Zwge6UhBBXh lSavjwFfYUqmtX2MLa/wDNkrDZ/xjZRtNi+weFWbstIccVjjGuLUazpfwLnQ jKvFqb4BeW7G/oSU54j23ORPqWSDHYPGLD1YMNmGuiPy3JgFazzz4a1pUbiG BmkG2jnS//KJMuGWmCD22Ixb37lX6zuKE881BWl5nYcFkz0zR+SxMQtWV2fP niuLwjUsbrNw5qHPFdKM9qn5YaTnWHxDylVHVQQm/oLM1BXRrQ3X1wGJ2Fpg YB7yip+W734+6fP40M2H7Bw5ssa5WzAGzIdztBZxCBq705NECaOGnnSCFvL+ ooy/JXf68gUqNI5u330o+dez+1G/ptwTfUiE+0HZtLptnrLnb0gCyT/1dvT2 8uG3QfPPEDSGPVpTorI8kg7AmJlON9qCqxDfp3y7zAvbcVNpLS7HElxoKYYz WQJKgaBQdLRxskvGsj28vnwy7aTV9CN2fU5+AtJpG3gHhEMjubbjInlo1iPr g+W8aZMfUL9HLnsdQDtXbrNZ0E42F7vVVwypBoVmBihWllHfR+j7hJQhI2he BXX06ZlSjtIupxh39ckMePGd0dRqkCvQp9n/AgwAAEE2Rw1lbmRzdHJlYW0N ZW5kb2JqDTI2NiAwIG9iag0xNDE0IA1lbmRvYmoNMjY3IDAgb2JqDTw8IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjY2IDAgUiA+PiANc3RyZWFt DQpIiexX224cNwz9gvkHPSYBLIuSqEsf67aBA7Ro4AXyEARBsXHcFrsJ4hhI P7+H0ugy681jXwrDCTw8w9shNaSs1GIp6+SiCuS096QOi7VG+xAm5OOLxegc SBkdU1JGfd0vFIKOTgVrtfFJHQGwJi+I0845mFFwmjl2HUG8tikXncy+IFZz RDDL2iBo1QnEQDx0ckGa56CzoxUJ0W50oo5EGz+sc06bWJuUwWuhhGeXZxoJ 7NnONGLSSeoxaMSsOcfZdYw6JZ7DQydbP6fYPXcaQEqGQ8VpQ3l2k0g7swl1 knKhkaO2tKGRUSG36Ub2eLehASTGTYWyK3Gn+PBDZkOje+40ctAUaKOTtN14 CdqnbaRtxsLiy0JMOkWgzkinIs5GUheW4Cap+9vlzQv1CScWJYkzWWuyjnkm aw0SMDNZQbKbU7AGKdiZrPixYSY7PDeylox2diZryWq3cQOV4DehTlIWtkab ZPFFefwPKZRvKuEUlRytJg7lNEaUwFbE1/avCAWUqgBeOw5ngFJEt9rI5zsh GU9dpmxRLTlkWftIk4y2Oa+QWUe8ZhuhQeun7Upji79Q88zMq0WkTVpZu+xn YMv2sPxZMZYO4HdOmwpUZKqAdKA7Yj8DSYfMDRAxpzobCDNiyJ1eRzBFuFpU BzXoaVp7SRWTywgmA5RsmYANaQzZ4yGdAUYjAk684XOI5JLL98UJ3+B5hDWb aoVRwnQWwVeE1sxWj5CVw+ERK2lKWQhy5DvTgazELHZFtOEM0HlZvMrsziE9 1mmkEt1gakeeo3eklTXLPM5ngBELNmz5HNKrao3VqQyEx0irqjVt8zxGWlWH 1SNkMD1hVQ5/xPQ19dMOuZyoiNlguSMUMk6waKBv8Ndl1C1QlJPckHGeMEWd S+cQWLHNM4JsYvRKZA65yMGJ3DKr8r7k6h1vNEIIk4dVXmNUi4JMeaBd2Z5D Vj4T0hhHrpO0VeSkZnu5rLzGKsmKsClVwgq+IPJW1seKHZc3WCMGApqc8Oqi PMl+AY75gB9M48uXN6Tuvi7kuUwyMoTBiiWP+WpxbC980s4XO8T8skS5b6Bo Bj8euzYjFEEHDwq4jgbXrP1xubw+WvXTZ2TpJCEWEuCARUd1PlWHr5HJXU/C ZXyWTvLHdEDKDmfUk3Cz2DWryY+75fIXyX73cUklj6SgSyiS2h3B+G65wNox Bhp7iLtvy9tnv99/vrv/43jEkNPqenelcJ6Ne8/vPz6/wDek87N7df3p4fb+ 0+2D/vLPB6VwdOWfU4rsD1gG6ub2r4dbRc/f7V4tP++Q90s4f4Xwf2O3sfqG 0qlf1dt3Rn2onEsTKnuZ6GsZALn6dMAT+okT2XS7WAxc6GJ56+0QD+KYMdoj Wl+iMJsiSCDm/sJ1YYSb7BrSjVvQycUad/i5WS6vvoLt1Q26cHP1G7a8lQL8 72mXnpdel2t/IiEXjUxr3H26eOhv2aXVXVNoiCwGhS2JS1WZ9hAwIFwZpA4L VEKP1x3pOmVZU6/3EDlNbxvBodCKIPXCsm/+XRcOnfn0eq3O0BnxCn25Us/0 uyiG5eZEmnCzBODVsA31WoLbFm5d6zs6sUxTYffLJOIWjBUwrPH31ZRVKLez FlXejRRXyznn/ShQb1lTGC0bCGMu2U6LnS0aw0eVB7mhQVsPaXssBkP28hdQ 6AQZ03YTY5UHza7RsmweTnjsy2nrzcVsG30tAv4SYYVbpVQp+XoGxWR9lC1X etMA/B27GpUn37REgGZZlNUgmO5sfUQya6D2LnarKbP9+ASmU2lOTuVASjYO fjL3NLuHzsNBz2Hfdg38nu272JPoSM2wO1iT7yE6u5ZDU+gZrg5OOOy/P1yf Js7TxHmaOE8T5z+YOP8KMADb2yiQDWVuZHN0cmVhbQ1lbmRvYmoNMjY4IDAg b2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAy IA0vVFIgL0lkZW50aXR5IA0+PiANZW5kb2JqDTI2OSAwIG9iag08PCANL1R5 cGUgL0V4dEdTdGF0ZSANL1NBIHRydWUgDS9TTSAwLjAyIA0vVFIgL0lkZW50 aXR5IA0+PiANZW5kb2JqDTI3MCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURl Y29kZSAvTGVuZ3RoIDQ5NDUgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFt DQpIiWxVa1AUVxbuZpie4TUj0zTiNPS0ooIVBIYBEaNBUHnJI6gUKiiMMyMO IiAQQIy7VGLigwxa6lq6kYhJ8LEoCgRNLBQRRJ6CIGXUGE2MlZS7lS2zcU7j oWr3jm42+bHVXed233vOvf195zunacrZiaJpWrs8IS4mZekbCZaCckuZ1WRM tbxjmRtbVGB2rM6TeErypSU/J0mQSV7Oks7dGxdg4cv+lya5UE//u6bmtXVX QK8a7J59vt4XNJScppV1Te23QkP1wfrQsCVFxdtKrHmbysRA0xxRHzV/fhCx UaGvrEGMMRdtsIgrt5WWWbaUiomFpqKS4qISY5nFHCyKMQUF4gpHbKm4wlJq KSkns//7VtFaKhrFshKj2bLFWLJZLNooJlsLi8q2FVvmEqcCMSZeNBaaQ4pK RCvZoPSdDaVWs9VYYrWU/mGTyAjRgff3CQcF/4cPiiYXJaMoBUW50JS7mhJ9 qAUUFTuN2kFR71PUXyiqhaL6Keo+RT2mqHRCMOVMvA3UAC2no2kT/SFdR7fS t5x8nWKdDsmmyOJlDc6ezknOrXJBniT/gjEyRxVOigzFYUWn4kdlirJKuV/Z o5xwYV2yXWpcvned7XrA9aVboVutW7/bC/dE9wr3f3nEe9R63FIJqgxVn5pR h6hL1OfVN6bopuROafBUeOZ61mnUmiRNreYyq2TT2SPsVfZrL4XXB161Xoe9 jnudngxQkRsLJT8Yr6nQPLbft7PF7H74TPLj3Ck7jIsMW4+pOP7bm2rfDnCJ Kp9QPNM0Ap8LHLmmsGWSRuriMvNLTVsFNrD4bOHpL7UXzjScE9iypjMFG3Xs oQOTftzG/Lytq/mMrLaOG1ear5zQsQVwEIc5iGVwFixqvXKi78DANFQzuwrf 37JjawjIfcaar3d/qwW54QZSQaHLA1PO5DZnC+z+SHN0fIAW+ecLgfum/3RX t6Ca5DCi/OWsCroDZsggeaKIMyCbg2k4R4uhVzDsIfoK4MrEwEwrhEGYFkKa QD8O0/8Q+dwR6YxJ3BPQXII0mKOF0DUQFgV+Aroy4zjrHIZhmBZDNqE+BkVB taC+HLLsNNTYZWCXbJyIWZglAjF2yCIrmMUQemsgmO4FvazXe4yx5RTkGncq lyi+O3K790ctBKNeocKTsAlU9DXolF2DTRx0ggo7f4u8SSJvertToHc4Myrs 31c+UV1BV0t+suoqDhgGGieq5cgwKpIZ6T1woethBlQRLPXwgsNGcDWAACK4 PoFGaEDXJygiwWPABgFmeN+pgWhgQFmD0bELiUElMmTqvqCqL5fW2kFXQUMt 2UvynXibQznzrhhqDbQpRVg6uRZmKFQ1oJLyycdfAF8ocPAXIy3hxk9+/6j3 kjFR2BsRmZtiRI+owLi9OE8pHSbIHjFXxx62jrQrR9q7bvyqBT90foheuDAU 1Ri+X3CggPx/mlohAVw0dcCjK/BgIqMKAtl7UAm3uZGfbNMT1+Qsj7L03d2t Q57BiN0v5oKeBz9QfwsBOnb6veyBt44JNgU7b7DubM+QFjxRPYLOODM4EP0/ FIBnxvY2XxvlOy5b39axsW8a/py634EZ5hESowjoQeBlMOhNzp73E7gES1HI Mtg9GSRHb2hXgIszJjOQCLvkta+Ih0/sdkK9JDq42k24muSZuMmpcvBimk+d qrvK3/0yPXZZdlJMyrqLfTt1OIPBABuoFoMvD9N3gxvIYKYWpi6yo7Aq512z RdhjOwUGObS93v2IHfzsJLFBUOw44Lh0jAP1dv0oevCYFY2ZJHHLujGF6Gj2 zyAH/+tVNzZe1F0ypZ5K4+NXl60y6/bY5Pf2nQT+F779vCn7kG4W6rk75xIT k81J8UuNg4MjF3rv6hxJHwQfQrVKQxIaxI5IRx1YStAHHjM4DcMjcN12NCkh iGFDbZD2AD6GAPBSqiCUKHfsesvIUOf6hGWZWfHxKy+PCSiHAS6uaeVwpbBH EVWxJplUzxswNZ6w6g0+dyDgSdbA/E9ImoZOnO8a0Q6ngTvGIoOqJNQIwP2J 67vS1P3kWGpeWvbm9BVr/tZL5OFgAo78V+bFECQ7Cwkcqj9+uhQ8eMi6C5lE 0ctWQApuwtmBKEf/VcfSL+Tqclp7i27yw1c/vd6is+2RL9pVjPxMfm1e6+X3 dM9Bz8Vah4b6WwaHR9uSkuI2pkbrXhcgZEOwhpTvVLa+9/cyZHPJg500RdRj MJCyJJ5SLhFsIwQcBT36A/856NkR1gzxUiU3+tGZnjH+WmNhaoa1zFygYxNM BRvMH4Qr1wPfrDjU81XDxUYla7549ouWf2i/TgMlpuPsuf7ov5s0O4iYrOR+ bwDgVvVg7Nncx7Dn2dMHmvN/734O63qAv8c+qoZLMMYNdXwzdvFc3tq41VFL 1m0+f02AR1DORTHbM+QdZavrcnn0iUAONcGji75ra6tr/UxnY9hz1fm206Vt /ABEP4INkIwLwAOT0IyLMRLzMB8WYzhYwROce34Z1kUymZkLt0TyZFVNxLkE FhH5srCYyNMtHA1i6lsrSg62nDyoU+0jFWUgFZVUQe+cSJPt9AYD0+XQ9XGm E8kQyeDxifVyjGDu4VLOxjzFv8oxhVF9SvoKrLbDm0SIIwT5QQgiR+nZX6Ec RjmIZm59VRgbk1GRosOFDMmBioOfGfIrUvfBrB9yboV/rmMr+840td/WwrSQ S6T14w8MvHILYLo6dsSnbShZpUMDo7pZBT5SJfjQzaTPTqRIhdx/2K7ysCiu JI5C9+A1UdtBdlq7ZSTBE1CQO34iMioYFATERNkET0Rg8QACIkJ21eHyCGZR xFVBgoCuRlGiomjWA1cUNaIiV7IiLooxBqkmNft9Ww/QL+vmr543/brer6p+ v6p64BqPlq04ScQYtEBXYlEY0BNiyM/3qFTqc2WcwE9MDpo9XkSrYBhI4h1S SQ+rh7eCZuyS1VfTyWQwmWTA75DZGgu4xkPUayLTEkhBmdJLuK8xQJYaMOPB vsIOrXGy43x7GanFriIDdJgaJvYYIQPKN2Bp1NCfL6iCvoCJyiBaF/NqB4rv Wdrp+nYnnXkWLtCuC/RnO+1K49UPycmJsXCAchUOlkPJVcUEdMI5YanSbvGT YoGV2A8m88LeManzAt9/x6t7V8I88mQYx4NTAkot+MH/BabmbuGdS+Q3YblG yAvjuj0vewPnGpQhCagrlPJUiGVQyFhstNgf2xUa9xY0e8urWTKexfXZTcqe Ti+UxK5QDU4yxvIL02e5eCZU1EglqPtIhfZg7kMAwwtgXKukPvm/piCBb3kC EXiPg4U8XlFmUN87ymEIjyV4joNzrOU6sBzVvflGyaSa91Kp65ZXbDqsxdBY JQuW0kRUAzZKNNgIi8iyjWIgqZSCl9HAwSAevJQsLtOYBTYEPobHycZkzsCj u5LM0ZKFoweVDVSBjWn392syeagwruG6/bUxrqXt55W1HNrz6ue/IaJiSbCO U315S70YqpeuJMyV1H1cKf69GZBgkkVvmsCqEgfiEBwQTA+r3hRSuaSkZBNB WI9mWcmhgtkdpGxwJS7XULMwB3M9cKiXsbZXI2r++xuJ9vY+idNlVP8OtK51 uzST67mrt0pbX2nfxfQG880rewrPSC/tOCyGHZqbflzKpqj0de+Qqxe15+dB MStkt3scyyWlywwW9wq/iIQ/hoSvdIMuoVJbV7Rq2lfylwEG/b5Qc1pHn8ho 2lq++e762ql/M6eGv66u5Mj1Ji2YuD3GYZJR0+vTNP728Ui917JIbxmn8eqI BBpcMuiQfDpgGBWuzJ6n8L1QkA8pGpxhgDEfwmQRgl+1w3BwQsfSBTmyEIIz vw3feUl79fL+itpr66dsl6gVkvsjb+BYqqqSN36A2s6w19GSUNAR3blxqna6 c2Kgs+exNkntTd21jsIIcRRDiCOHaLmKJNpA7XVVby0i+ld3a5jC7NxD/3m8 1YqPaXYR4h48lJR57B8VBoOZLQTCfOD/DUGSOqSHbV90aU27hrLPnGgoMqYx QjooaRwtYcN/QjnwJobnpkM8LolVEiCeGJ7161Qh5FdP9o0tj/2Mm+gbmvnV Cg2VNjwONiYwI5ySwJE8wJ8ZceBhAK2JzIPoLRB7k3qOh53Ms50sVYU85Clz OPTi6cp4FN2ZBL15yDXO4tSjktrc6kFXCxK7RegglIrRBmUgLNII51ZvcUDT xWE5lRdO7DmdLZ3+siIjf785+nVovtt+9MBFsaIs1c/fLctxo+yQ7BCN/bRW Dz9uv16990y5JARmJGxL2J5oDtb8xv2bz5zRwgEVDMbBB61prB2wBP/wBSUh qdP2KTR1gm/c0It0dgo7+yLNebxwrjpTFVB8fd198RWYNkIA+KNpo7Wv79rg lbIBcmhmU94zLtJMWe7h7Ly87ocfj9U1NR3zcJTIn06ySPKg0awM/qUBy1Q0 +yeqRfQYjwNwCtp1YF+akEa01cLIPBlH8nNSl302W5wc9fje/cOtT64cW+2f Lau9FXfCQZVBhzkG/nzE3EN+Ik6YSrSScfR9pNtI9eX870qpXxsgWOMU7TrR YXlzfXPJo6eth92de2AMb4G+nX2KGJKTsE4DDrucYAzOEHHSKOyPduj4Es3A Gfo1U4s4IeMQPiJ18coA0eOPJ1u2yC1mJzIP3W4Ra4qXeeXIanxJhHVra+ns 00z2mi1Ap7i1t40t5k/l5h7P25tm2Cu9VmWsjclaI6J5wGx7eYnThGaV2htD 2sC8Ey49te2kXqODTSAKz5Wzym4NjepCvd6guhq+4OBMEd+fimrUoq6aZny7 qqpDF4vlzJm8Z8aKIA9x4ad5lRtltOKx/04Y8MnPIqQeButmGbMfaxyj6+89 OHr7UWvRNGfPJXo3mfVBxZnKhm9cH5bUxYSXcqqDfL6j9NSD6oLPnCQsp/Ud FQxb1ozjgz+K9l8hbYUDlFS10Z2+3h33E41vl0E3/DJzdDe9EOzpi4VsyNNR f2QbbdCHhpm67q03aWs86jWGPbmGPSKM/qbitaycQJ2xVLU05s9RySkZWakS mYjvyv2NiVHpkIjL2XEQGcdsCPFC+U0GVc9fqgQdJnJUqjASHtEcG8Cx6WYm +nGKgHTZYkCZzAilKUPJqEJ6Xs+cbx8LZgy+UMneQCUvHHt5K+/rli36uRKe on9Oqm7sqX5UvyNAL+G3tH6hAq3HeezrFRQWGilVRfvn+4izglYHL5dJ//Nu o1bVE9Vuw71BFR70RlUo//24zu2JKxm4i6KKia1XGLCNMB+HrzTo0oEmdMty 7gATcAFXHZjQiOmkQxN0ZRfSxqLGZ8+LXFxco1zGjY9qbCDF4pRY8CBDjE8M yGYC8vwi+mjod1omH3Lkyp+qRBh/n+Y/SRZGgM10GI5OvvPXBIZL5MvqaoIC u40eGruIR020oelw49MnpU6ukrDaOdLd9p0TSt6coFx6w9jZBtU/IvwO+pKK pjG+4iIYrG+runWQiRHTKa/GYcocTdORhtbHJY5uThEf2tlGNjRKaiynCI6G /sRvSwZdqOmOXxJR68nfa3/Zu9+wNUcCS1VWanJmiqj3DvWJ6Y7+MxY8tE5q A2gbWgQizb46mEHPYWSDOlQReGhw5A7oFwoDRegP/U/DiGduh132UYNy2+e+ 87y27MyOkvNlGwK3sasuCJtGH0dORFPkw9HSviGq4XNZKPh5/ZUNn2oXLkgM m7+goCqN4Db8hTRU09anlZIFG7scNeSr3ZQJP+Bl3vp+3I9fF2dsy5fAVLV1 Q1LaBvGT5L+elSH7l7bRRJUkMBvb/l+iyye0aSiO4wtdkkZrEFPFGagj6EQ2 QZ1bdbpe3LQKO8mkuiKjB4VeOjx0/tvJ2VmTOVemtVrECq5VGXOi4mGHQdSy gyADQS/+QYYU1GLH8kv55eDvlaHH9/J+Ie/l976f79f2D/5rlXP2NDs/DVm3 aNH+wJGzL7764BXNLIjonWmH5uJ8/s2077qgBA8C23Bb7R5yN+yUy06zYrr9 HC4z/nCwzON2AbqdDE9WVYYGHTpwaxzKECCIjVdfKqHqLKtpElqwUmNYK1R4 9AltuETDFljikUzsXvaCbcJ3KBO/fmCZhyaBjloHP2pxyEMChTiog+t0e0oJ K/f1eka7OpJMalMeiKrHaFEAEoyGysZdqO4EtYbXACZ5GdtXFIK7Yudddo59 EEGUR4ttQgKLp+wAR53zdyMXQycTDbFrsbGBUTdK4tVCIVlQf81OfX5Mytuu W2BaXM6OuXIb7JiFzwWy7yZvOcFGGBUxhyYvOx32J9BI8MZdUKyeIasgNKPG /xbYkxJJVATUBVApucI+u8QipAoSa+g5jKD0f0zXFKQtFRhZhENUZdIP7AFV qyWESyZTw9vC2yfPXj96l/D3hAZ6h4cN47Jvh2ik08YtVXnwZSbUFezrPTw0 ZIyRZLvFkcl8clIFZRE4WPut/8Oee5vJmB0ws0+L85vIatcViYp9p9GL9YZP jpLSnXgPx+VG2K3/hLDcDV06Bcqw3Ar7dcosYflCtnoqi9EMdOoCZCf+TDgf M+LKZNoND1PllFNKS9Yq0FZbNz0e0O541hge2Z7zVjvX/xVgAHzaPyENZW5k c3RyZWFtDWVuZG9iag0yNzEgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCA1NDkzIC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0K SImUVGtQFFcW7qaZngFhkGl60BmYaRVUQORhAEFEHgIjD0ERxegaRhgFAwwO CMEYcYkxKKDGXSlSiRFXjTErawBRNvERMIqIOgR0IgFlfIyk0BXjo07jYctt SHbXze6frbp1qu7p+50+33e/c0nC2oogSVIZr4mJSIj00uhyinSF2RnahboN Ou/F+lxt3ujnQF5J8C4k72rFqyh+gjWvtpNjCK57eellgkhVS76qqPgl2omh w4EXOda5TEyRESKSlOw7fqbT19dvpp+vf5Q+v8SQvTarkJue4cH5Bc+ePUOI wb5jcRYXkalfreNSSgoKdbkF3IK8DL0hX2/QFuoyZ3JcRE4Ot3gUW8At1hXo DEVC9l/NctkFnJYrNGgzdblaw9ucfg2XkJ2nLyzJ13kLh3K4iFhOm5fpozdw 2UKBgg2rC7Izs7WGbF3Ba0UCArgxwv/OjIrwvxQhSIK0IkRWhA1DcC5EGEFE TiSyCEJPEJtI4n2S2EsQhwjiOEFcIojLJGEkiC6C+JEgzASRIehNWBNiIpzI JV6RVVYqq6VWO606rIYoR2oqFUqlUvups9bjrDdb14lo0QbRYdqd3kOfpV+I l0poSYhkv+Rnm5k2i20MNjdsRmwdbOfZvmNbZXvVFsbFjSsf98ouw+6m3TP7 Gfap9gfte6W01Eu6QKqT3nMIc9jq0D9+9vjc8QOOro7zHDc6nnBskznLkmR7 ZUNMPLOR6Xeyd9I45TudcuLZOexatozdyx5n29nH8qnyj+Qmeb98QD4kB/kr Z7HzeOcJ2C4dXX0VQHXzRyqKZTeAchtkvmA0ED28irUjZmA+fQg7RM30IegQ MbvdRsqELFBAIUVLMYBfCdUCDEhjt5HJZ2qB5FcKB4xQHUszu4HD6n/upBt7 eXOv7JA53gLiVmAtTB/s4gNYzf4VB7oUP5yt79ijakULe73o/Pp5ioDUteEf qJhHWAc+bDWq+oPAebMkuPWWGJi9Az3AKsABiTNpNaqkT0SwQ9y2pSGjJk5i pteDOOF7JGok15YsEDM3UbzVLxjtFWjToYVJ2SrcJ2Zq59Qs+rb8vkTK+5W2 wr7WvNEgGzBB+K+LOceUQfIG9g7N1w1vEgXSzEHkRo6xSJzwA3uQnHr0DMi1 D3A8OmR6cSpTFdtWc+eGaW9AcmJp0LzwsrsXVMzKkavQ9f8gpCdLTdoifnoR /NEkO2bZbobZZuZr3gems8uylq2LU8ZoTnebv6u/Vq9miqAR/8YCRaMaAo5e rv5iT//EEHq77n3d5ixkwW9CZ8OVS2bFo6DT/m6LYuZGNugaF6uYct8V81LQ WrHoKLpCak9f3bWTKkaO8fCUzWnQNZ1UnGs62Hj2y6zVSam61etVgi0wuuhl QDH5tYWCA/gmOwO818A0CFVA4FfgMQieqjjaHV2W4Fz0VWDUJZzyED1fw4HU QrUKuJ/BpRXmgq8CohbCFK8x3CB6f4XTMFSBgWvQY8YYrpSPhjpMLAZtsewg fIeab5kswUS/G3PiUhTRkxpLVrzQxfk251x52Ol14ssFD4CsL/6GyxBJa2qL QG8k4TMjBXf5nWws6jEvFvJQbwQ95BkxT7Bru+Bz8jZQ1G35Rbrq7U3LV22S LBffPHCszaR4gpRYim9CWS95BpqoM1DGQlMvNv0n7DXv79lVNLylmCzhRVTJ RvY6DaeHt4giaWmpiTeayCYLNFuoJnjCou/HmA4GMHwM6eALfu9BOhrQ8B6m o5/KUsk+rwQNuIN7JWomT9qBGnRH9x2geaGS1hbxuwVKB80U8MPL2Tiae2fW ek9lLCSM7DaLpRUm/ryJPGWGI8L9sPwq1lze9OCx0tSeFuax8C20i1BPSwxM eg9DJXyGaYSgP733U/P9Fsm91v7L4KiACR7dgh89Azl026MSuobDRthokh01 R5uhxpJkYZ5CHtxhqz7ZV/mpsv/aSv+A+WmzPdM6BsrVgTROLR8MBDclTATq Bkw2a40Bn6mrxExOy6FTLe0KcJ55ER1wcpQ3KrepzPTtysaun5TdLRkRYQmZ UaWlFZWb1QI9CDGRMNBL8UECvVgafxjRioKhA0N6IeShyUuMXXLYAkOiKhwa 1RVumcDHRP7FDOcsFL9uOJHFp/SCEevrH4oajzV/3qIcvKLxRlHMkpDA5Nbr 20bbdNo5FA4OSgi+DRKwg0C3PpStWPpuVo56e1U9pIugYaxwlwliTLL6J3DE HG1hnkMD78g++mvkrKC0SJ+Zqd/fu3+ua1DNNEM2TGNB/PvIq2ijxFXJmIjL 0KMOl8AatYCKvQDKp+Ac8hhdwpL0cRnCP0RA7voTvAHuSmb6tVPa+D+M0ub/ 3kvC5EGK/0igMPLWHF5Cowf6oxj17+JWySBdI9hFAjUwBSZLxm7GlHsUCkyy RkucBT60JFqYHpDDSvbW1Zb+3quLwkKTkgNnJZwzqxinOOhj4xuTLxaomKOh +lVxQQp0fz4fXMD52Y/gem91e+DnKsb/wuHGC5cVlqQH6CNgkJwejzZqZqml nO06X2/sPKObH7Vcq4lOOd4z5oyYUYVkdZZwM5y8wzznvfkcNiglyj94UXfP 3fq+J4Nnw99QMcdwBFtYlFabF8I4JYTfAFfYDrVIdeEEQR509fJGV+R6PcGt 83J925/VVdtFGL8tzXeKkimPTWno/ED9y6zBN0DJhHlzZmpfmzgmHSjeU3gJ UNgBRf/m7G9Guq5th0kyOtP/BRNAfJNJ1mruAcrT/A+yqwUqivMKg+v8ixaX yjhry6Q7aFcUAhh5CIigQFBUAql6lJegEfUQoyE+QInVlBA9QFDsqdGiosQH xkcVX2CC1qBWQsQVIYswGtG4CnsA22i4s94x6d1Fj83pmT07O/PPnfvd+3/3 3m+/t2+3p7JBeFRU02IVb9ZkRJdKpVEZizIzXfj3Fi5MTg/zSOs4qTVVnzx7 2lB95sy5Ox7AB7YQuz2DjfiHEgN1qBB1w/9MRcjKq+s0TauDJtOPde5nTGaz EmHi7yqhSolw5mR6athUHB6UvOT0pfuNoOuSIKVWiGer4rmrq+ZXzBNxhB91 ACnwSmxHbc2Rf3whbWb8sYySypxjYhd4Ei2iIQ7HwjDiXgZOxDB8B5dAKE6A JTAMhjTCgG+leBY9yyfVV6TlESDBFIihMvWCSWQ+fDQGeEaiW0JewY7dZVvL S3dJunoqxKWyEpLrXGB7XVOg72EyLOWgjrXhUu4pwyO2dG4kOx8slDD4Dd7j cCPT9RTLQJ9c2b3NClbrdCtlMQpkAZYx2fyBf8Tc5DAJ85lvuAA9DEaaHz/9 IbUxcLe9RaxpPHjqcqtH0+ILaZWGA/NDi+NF3M6s9ORMdqfpz2MmZ2Sik4Qz KZGiQzM4n7VqbCHKJgF8V6ObjN4iZuNgGjoLMROcMJSKJY5y7wRTdku+DAfn xwTiUBEnxRDrQ8C7mcKO7L2d5LVH0sGgYlm5IDu3WRWqvzY9FDLIfwoifAx5 6AYDMFvCQgeWIAYxDUaMxJ0Ys3a6hAFMt+9lzGROtkqBrI6CYkUrq1rIVUbK 6l+Ybj3lUn71jBVkuC3jbVofLKtZFNLkPHlBDtTKUCm7n7Uqyzv4Wj7TNlR/ VXHFxnBYw/hdqN8aaMTRIgYGUwTe4NcMPhD10/0UdCqXrAzCs/G3TfiGiDnI aFxkYgLwGA1Zdy2HzXUUo9iP4WquPUzXFzDo9bLVlu6LV1VXuOpL1XN7b44t Pdf5jlVzR29fYbqpebJNynWusMJaak5v0dj1VcvZxOzkIP/V//re8IVvhhY9 zFFEpqALPd0GnVwMz9BifwuxgNTfCbunzUQS2o3P8DkHrgwblUj4Gk5z6Mbw Z1Q4UHxpcsk2Xe6LLC6TVZ1NR97hRDEw/xzlIbiSopQtSqWFT5P1FuVhCeOP wkr1IXebwUrlIVeiPrTY0lHPMEftxtVKN0e/HXHbA7plUX5v0dwiw6YSpgxS m7gntvRxamshU12VVs6Lnozq51WVVcm3aqrAJuAc0GIc5NKhJTLNgTlIZ8yl g+7jHINVD8YW2oZoiG5BHzSiMZpO0RgdTTeNBkcN1chQZt93qgdHzmtgOVG/ 6JYMv6NpG9mOIw3Y6CBXAuurnTd+fEqa56cSJvQDysixjZDdHZD4Gn6NLalQ 8DNzzU3Hn4Kzx//h4UtfQr5+uazySwMJdudAjq/BHZAptMdz65ctLVgsvoD3 a+jBHwTOmi35tnK6HgJ9RYYSRxE/sUQ4ilgRBCiBj7QPqubG/nHSqgAJz6mC YIUrsI7x9Y92vR27Tfp77LrIg8tdfmILa7e0fdJU0JRXH7rThWp71b19VTfv eQALbUEPAz5guvp+2X/CMtUKFgv1iRY+SWmjTgjjPkHNDfQSUY/CDGp5w0H7 LrAVEr+fvoHleXsYfbOD0Wn0P8HVMI4Rw8UImqR68K4HX/pnwU4hO2Dgk1B7 ANmOHzw65UNyjylj1GcGexXadDRjC6waKCBy60jVqaZwyO/vKXaSf2dVhlFb ec1B8jSG7tOmoCu6x9wAd4OSRre0OBOcx0M8TPnRCnEG3b5+dhUpzzSKjazG MHxH/YUrZDhf+YUzMih9ns6BE3l4VAyuY3KUbmDE4+3PPPikZ152NwxHEYcL Gb8XA4jFRoZBjmv0pCsfBjPoBb0MwojP1GlD1G66euXWpinS9zFIoYE3G7/i gDTDFkXjkEcjGCbgEZwCRzhkDDbgY85OSLsdHKYgPcg7OjFchJ34LnRypKTh kDqBwxoiqdbe1+w9sUK5pqnQK9dkNZUpicoFTlbLwxV/rfq2eoGzi/oUk+2Y yblZ1sB22/sCJv4cDIkmT9uxPvZqtU/WYMpASHwWjIlT+54f82S6ZBLEotn9 uIV05aYOvlMZBnFC2rxYHDg3dc+lhq/2XNpmuLzt20+P7nMBA6YKmz76uKhA zC7efUqCci0M8drr79jlMek4bKPUwVq3XKxoFr+u3xA1I3yr31qJPxSYF7QC B3kYby3oam7YX/elYVblyuqD5aV/KzPotm4wxzeQf3gr1/16B5gsfK2yBHYK Xplj0AUHzev6T3d1DzAYcN7Ph6pINeJOoYPxtTdKtAlVrbkXRQhoAzeanl4T wR0D35y2Yub7UiHsGf8yMOfjpEWL4YkAbhv86uy6MDQcdTgW/e/iAAgAfbsZ 3MulIBbxUUpqmIhO87usT6u6wa2pZtH0HdKvAB63gIkGgvI5bdh4LC9k9Ysm 7ZkjYkAEyQ0v9GpHdwi82bj/cqVEPfHN2A4tf1Q1wl+Ff5/sJWUw6JzfKJ8M b5oKA5K7qD8TQIg0g5cdI5wnmGEQKsStS8mKFZFLki2bJWU4g6Gls2ASziDh MYosx9KoK21DoqEILne+Afa5pLqBUWjfevH6A/Fu/fQJW0ilVZOITTCD3uzc 26Hp1XcoCY/No5tZzb4dp8t2F24sM3ynLf1w1eYPRf/kjBApMmjyfa1uPS42 wWtmRWiIf8GGMzLfDvtvCDgw60lnb/UDcO475feGzwIjDpR4K+Qrs4VwxrdH FWkvv/enQ9NFnJqIr1NuR9zCIeB/zXS4gfKQxdAlIxw1Bt48K6rim0121c+V wsDM7v/yXfUxTV1RfC+19+HQOvsoJFReXajGDcaXFREwU5GPolVYnCuOEdGh jIwwk4WPukhjzELXaBxzdTUEETUO4xTUOXTyEQUVYQFCKBpA35ROXDQSYDu3 ue+PnVchZn/oH+3t6b3n3nN/9/7O71w9rLz3JyT7K+5tCr5ctwQuSdUdLEEz GW/pm+y5tGOjyCYlGOdBlX+fLbKs22MpER1wGo9X5tDPXQbqKW2fFNKHm3TH EyFGghys9eLDJWUE2+bxBc0OgSjq1sXLf5Ct9opdlXbnwUpxHV917Nh3br3n +qUnBiHGVzdnxjXdCb+xev/8xWXoLJQLzbgEWMnwIKSyeiWTsK9gFPIhSyE1 s7NSNU2K5/1hKczuk1To4MvDSKFW2aECa7ck1Cnb85CLjeMTQ3WfZojsCZr8 cHvb6IMa6wbFpAv4f9OuGM2birYUindLs09t1K/PLs4uMGBqyhpK4jWvZkO4 hOY34LU2u3jDblHxG0W/fbOEAI9XdQFcOhbxiAVCAiQ8wpogAiJNWD8msAQT C2SRojcYtAP9Y2MDqUzLFqakxsWl9MNCZCxLLYVNOJMSwkvKjryesrJRztdJ cPwgeQNdibCsH6H738wvuTYiGGm9cmxEGElz8G/gG6uTiGyk1tdwjVUjahu8 lWXaO5LQeAchsyEqENJyH8JELx996KMdOxICMJIY4BAq08ukeFZa6wWblOFF WTx1FlbqWNDh57kQoJ8G/hIseLHyTHytQbAm18b+eCe07Za79WZnqfl7USKg PRBzgRF9rHF7+DKp5GE5yqZU/tBuDs1Mqdyaaj45VIUxnXJ6qMrDPZNUkOkz YUqJXr7mMRslkecrHos9ns/xplZfNMDgpMfIa/x5aFvZ7KlTuwILayZROWnG zJ2X74owGc/Geab6dTUsGuxs6L4gYhLKWDWMu/EzhXPTL1XUhm5xhL0rpyjS toSmqCMJbJHd6r/won7ofAr9/6As1vgKhUZfBY5djvyVkxRZbGdv0SR1FAn3 m2wuGh8QSETXJ2SKRqMoTsvRai/RpGHd0l7aAWac6AitEu4dCZ4kWOYUgZEV qYEjLBelUFiML5/96iWE6ZiZvQNmNeMIFlEOtcbEdnp8YWXcD7Rc5d9nrKLN /lUjcNUIAvmyq3C5unhvua1Qb7NVH95rWM0fqD3uOK4fOt84cdGgWeyHNrtT e4JmCH2omxke9oDgmn00SC20d8pL16C2sh55PmpnF80FFwY73StsF+qmaS5m kF5wpRONCSsTzkmrVLB/Dq0alquUrEIlCOe+hk/wTUMlXTdZAeFK7LM9LdjT 4u+AkFc9Y1PaEu9zb4hQByY6hgt4p2IVTLPCZ34rg642w6JmzqF8q6743tc1 NTQ0NTUUFxQUK5+GJjEv2NJq7epqbe3qsrZaLFarRfRfDLjeCxX+jGDzZnuF a8I3mBXoTwRU13/uv/t7zsao9SWJh8V0XqiHOQNlLHhF1uYYe6XzkN2wlne4 jzncegh7+jeEPfpsJNalPAOTB082dAyGQgDjbr3HApMTWaDCIjh3AwZucCd6 YVWvykvbdG0nrt2+2liSn1WwZ3WemLlry+5vlwbAzRuskrgu3z7T8UvAzXMd jZ7Q4YyriVGbLdFYi8MXkNoDeZociHM+g60zbe5M+7G/nZj5fwLtfbDeiU+W XA0kOWEutrYaX14NKzpK4HT1i2r56VHe87YU6Jk3T5o3n7YH0Ye6/wQYAE1W v7INZW5kc3RyZWFtDWVuZG9iag0yNzIgMCBvYmoNPDwgL0Z1bmN0aW9uVHlw ZSAwIC9Eb21haW4gWyAwIDEgXSAvUmFuZ2UgWyAwIDEgMCAxIDAgMSBdIC9C aXRzUGVyU2FtcGxlIDggDS9TaXplIFsgMjU1IF0gL0xlbmd0aCA2NTYgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkcwWswGgAcAHAf3Lnr rjtffHHnnHPXdTqX4xzH6Tg6cuSSi86rXJG8RZHyyiS0JEaWmFfmPcYw1lgt y8y0xsyamZk1a2Y2M5vZ3f/3u7q6+gcuLy//gj/g4uLiNzg/P/8Fzs7OfoIf 4PT09Ds4OTn5Bo6Pj78Cm832BRwdHX0GVqv1Ezg8PPwIDg4OPoD9/f33YG9v 7x3Y3d19CywWyxuws7PzGmxvb78CW1tbm5ubL4HZbH4BTCbTxsbGc7C+vv4M rK2tPQWrq6tGo/EJWFlZMRgMj4Fer9fpdI/A8vLy0tLSQ6DVah+AxcXFhYWF +2B+fn5ubm52dvYemJmZmZ6evgumpqYmJyfvgImJifHx8bGxsVEwMjIyPDw8 NDR0GwwODmo0moGBgf7+/r6+vt7e3p6enlugu7u7q6tLrVZ3dnaqVKqboKOj Q6lUtre3t7W13QCtra0tLS0KhaK5uVkulzc1NclksutAKpU2NjY2NDTU19dL JJK6ujqxWFxbW3sN1NTUiESi6urqqqqqysrKioqK8vJyoVAoEAjKysr4fH5p aWlJSQmPx+NyucXFxUVFRRwOp7CwsKCgID8/Py8vLzc3NycnJzs7Oysri81m Z2ZmslisjIyM9PR0JpPJYDDS0tLodDqNRktNTU1JSUlOTk5KSkpMTKRSqQkJ CfHx8RQKJS4ujkwmx8bGkkikmJgYIpEYHR0dFRUVGRlJIBAiIiLCw8PxeHxY WFhoaGhISEhwcDAOhwsKCgoMDAwICPD39/fz8/P19fXx8fH29vby8sJisZ6e nhgMxsPDA41Go1Aod3d3Nzc3V1dXFxcXZ2dnJycnR0dHJBKJQCAcHBzs7e3t 7Oz+CzAAHIXTRA1lbmRzdHJlYW0NZW5kb2JqDTI3MyAwIG9iag08PCAvRnVu Y3Rpb25UeXBlIDAgL0RvbWFpbiBbIDAgMSBdIC9SYW5nZSBbIDAgMSAwIDEg MCAxIF0gL0JpdHNQZXJTYW1wbGUgOCANL1NpemUgWyAyNTUgXSAvTGVuZ3Ro IDc2NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr///+/ v3///Pnz+9evXz9//Pz+7fu3r9++fP76+eOXjx8+fXj38d3bD29fv3/98u2r F29ePHv9/MnLp49fPHn4/NGDpw/vPbl/5/G924/u3Hxw+8b9m9fu3bh65/rl 21cv3bpy4cal89cvnr124czVc6cunz156fTxi6eOXTh55Nzxw2ePHTpz5MDp w/tPHtp74sCe4/t3Hdu38+ieHYd3bzu0a+vBHZsPbN+0f9vGvVvW79m8bvem tbs2rN65ftWOdSu3r1m+bfWyLauWbl65eNPyRRuWLVi/dP66xfPWLpqzeuHs VQtmrZw3Y/nc6cvmTFs6e+qSmZMXz5i0cPrEBdMmzJ/aP29y79xJPbMnds+a 0DWzv3NGX8f03vZp3W1Tu1qmdDZP7mia1N44obWhv6Wur7m2t6mmp7G6u6Gq q76ys668o6asvbq0taqkpbK4uaKoqbywsaygoTS/viSvrji3tiinpjC7qiCr Mj+zIjejPCe9LDutNCu1JDOlOCO5KD2pMC0xPzUhLyUuNzk2JykmOzEmKyE6 Mz4qPTYiLSY8NTo0JSokOTI4OSIoKTwwMSwwITQgPsQ/LtgvNsg3JtAnOsA7 yt870t8rws8z3NcjzMc91NstxMst2NM1yMMl0MM5wN3Z383Jz9XR18XB19ne x8nO29HOy8HW08HGw97a3c7KzdbK1cbSxdrC2drcycrM0dLM0cLUwdzE3tzY zszY1tTI1sTQxsTQ2tjAykjf0lDPwkDP3EDXTF/HTE/HVFfbRFfbWEfLSFvT SEvTUEvDQFNDX0NdT0NNV11NV01VR01FW1VFS0VZU0VJQ1lJQ0lRXUlRTVFB VUFBRUFeRV5OWU5OSU5WUVZWUUZGQUZaXlpKXkpSTlJcTlxMVkxERkRYRlhY WkhIUlBQQkBQnF9AjJ9flI9PmJdXiIdHkJtHgJubn4ubj5OLl4OTh4ODm52D k42dg42NnZWVDYxYWYAIDJiZmZmYmVABIxgwYAMAAQYAz8c8Jg1lbmRzdHJl YW0NZW5kb2JqDTI3NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDI0MyAvSGVpZ2h0IDE4NyAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAyNDQgMCBSIC9MZW5ndGggMTI3MDYgL0Zp bHRlciAvRENURGVjb2RlID4+IA1zdHJlYW0NCv/Y/+4ADkFkb2JlAGSAAAAA Af/bAIQADgoKCgsKDgsLDhUODA4VGBIODhIYHBcXFxcXHBsVGBcXGBUbGyAh IyEgGysrLi4rKz49PT0+QEBAQEBAQEBAQAEPDg4PEQ8TEBATFA8RDxQXEhQU EhciFxcZFxciLB8bGxsbHywmKSMjIykmLy8sLC8vOzs5OztAQEBAQEBAQEBA /8AAEQgAuwDzAwEiAAIRAQMRAf/dAAQAEP/EAT8AAAEFAQEBAQEBAAAAAAAA AAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAAB BAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIz NHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieU pIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKS Q1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE 1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A y9qUKcJQtNjRwlCJCUJKYQlCntS2oKRwlCJCW1JSMCVWqyQ7IspdoC4+kT5f mq5EGfBYeWwsve06EOMHxB1CizTMeEjukauxtShKneccWOElrA5+0gnbO2dZ HcKsc42PbRjMJtJgveBAI0MNCccsRV3qLrzVTYLU0IoYQI3Fx7uPJPcpi1PF 9UI4TQibUoRUjhKESE21JLCE0IkJtqCmG3SU0IkJiElIiFFzPBFhJ5ZurrJh zmy0Hv7nCPjokZAVfXRSDapMJEiY8+6mWq9RgU5DazW6HOPvYdCAPDxSJA3U 1vtt7AWho2TOo/ijfbcmANrSx2oMQR96uXdNtroDK3ewEuI7g9tVkue5p1na Dx2TRwy2U3x1vMpIa5jS2O41Q8vqz7gGxH7wCB6tljZFQ28zGiA5jnO3EanW OPypCMbulMfXs/ePM8pInoV/vOiN30fwSTtFP//QpQmhThKFpMTCEoUoTwkp hCUKcJQkphCUKcJ9qSkcKpmY5sex4r3hrSDt+lPb5K9tTurjHsvLwxrSWNnV xcG+pAaNeEzJwmNSKQdXOZknAxGYYebLrSfUpkbA13DT/EI+Ph044Owe9wh7 /wCA8lVoyGW5Vbm1+920bztncB7jA8uO604UWEA2e2g8EyKOEtqntShWFqIt TbUYtUS1JSMBPCntTbUlMNqYhEhNCSmG0KJaiwmhJKItVbqFD3tqe08Vny/P erhCMen5ORVTbS0OaQ9oBMEua5zi35jhVedyCGISJEfV18mfl4xnMiZocJ1c enMLYZkcRo/vHn4rQqufWWua729iO4+KoZmHZXALSA4epVMe5h51Hgn6ffBd jv1HNZnjuhgz8VCRsHYoy4uA+B2/a61uXda9rGEtBga8lbFONW2lv2ghx51A n8Fg+p6bt1MsMRPJ81F197jJscT4yrBjeg9LDTs5FGFUxxrcK57NJgn4LAeX cdhwVJxc7UklRKMY11tLHc/94/eknhJOU//RrwlCnCULRYUcJ4U9qfakphtS 2om1LakpHtShEhKElMNuoVO/Ifa90Wn7PjM2Ob23WDa4NB8Y/ir8KhdhZP2h 78VjrWWkPsrY3c5kc2a6Bup7qLLdAjoUx3arwW1049dZY9zxYHTzPt0/JytU t1KDj4t/qevkuDnRo1vj2JI007K0QACXGB3JSxRMQSdP7FSKPaouDWgucQ1o 5JIACi/LrBiuLD5TH4AoD3ZNjY3WNDp1Y1wiO30QhLNEaD1eSRElsMfiu/7V UtPgXf3BWG42M/8A7W1A8kEOWfTjuG0Fr7DOph4jw/OV9tj6wxja7BHcud27 keso/fn4LuELWVYbOeoYxPgS4H8hVcGpxiu2u3zrcHf7VfteLBBaRr+8T+TI VN1ZBlhLZJJZqRPw9V/KIzyvUKMR0Y7U21IOe0e8Ez3LXN++Wwpgsdo1wMeB U0ckZbHXsVhBCPam2ou1MWp6kJatXCzsbGw2Mtkva9ztgGv0pBk6LP2pOGjf n+UqvzXLw5iAx5OLh4uL0mjovhMwJI7Nq37JeMhkbq2E30tI4a8Rc1vmJ3fJ cuagMlu0bveAW+OsFbYEGQgV0MZbaYAdILT3g+CrQ5MYZxEZmUZkD1a1X8WX 3eKBBG3qURqVEhGLVEtWkwIoTEIu1RLUlMISU4SSS//Sm/GurE2VuaOASNPv UIW+X1147a7ACxw78EKv9hxL6fUrJY4nQc6/Aq4MvcfVhpyNqfatpvRqPSG6 5/rd4DS0HlTx+jY5gWvlwnVsifDlA5od1UXChIiNDprGun5V0XVW9Ow8drnV N9Zx/QemA124DcXHtDQJMovTetdN6vTbQybfSa31N7TDg7Sfdzwme/pYikRe Y2pbFsZXRnsc6yl7DVJIaZbtb4S6Roufsz7AQWYr2tGjzb7WAEe1xscGjXsI Unuxq7RRbG1Qc3HfYKnNLr2Ra0x7Qwy397kmOyfGtsyHvG1mkMDKw8nd4S8C ZCO7Ctxb8i7KHp79uz86GMHl4klIzBA7H9iqRPGys2OB2+IE6+CpXXWvcfTb c1hGghrZ+btU2Vles4O/TCkQA0HaNe/blV21AN3vxzY1sc2cTwO6gnkMjQ2Z Ixrfdk71WwHh+/QgOtJAHwalsawMkNDnid+5xIaDpp5kKNdTzcKGVNc98Q4E Ea9idvZT9YlzjXW2thgQ3UaCAeJ1Ua5LX6BcSBWG1t1knl5iApTQbIBrA01P EyOfNKsXCg27AfUsgOh2/wBjRPbQe8Jm2OY7bHt3FxaQYJPMyRyjaErvs4sL CREkEg6c8Idra9HQNrge5J3DQz8UfIyX1m6h7T9IA7GuABHO3bHM8oLb7fRs dU14dQ5lhsId6kTt0kcSdULSwAkF1YJLdJD3A6/nR+Ck31hIaHkCJG8OiT2D wUzch2XaZq3hvLCGsEOO0nURMu/IhvrLMhlD6m7yN7mbgZbrwWiIgIWO9Kpt tIcB7XjSfc2PxGidzCNCIPgUJtL2OBYSySWAttBEwHeYVnE6jVkWXY91QtbR oCHBrpDtp3HgyfAKeGcAerXxWGB6INiRaYGnj+UomRdSBdY2s1sY1zjW50n2 /miAh49zsipr3vbDp9xG0HYInQHgGE854XHXTqoRlR0Y7VEt141Usq77NT6o e2SWgFupbuMF0Edk9OTf6dbjWwtdEl3b5AJHmMfe/ojgkjLNYjUchR2q5fc8 PsDmMexr62+pWC0AWiWacu10Q6zj22bDLHSZb3G07TI+KdHNCXVRiQ1YTFqv vwXNghwcCY8FC+hnqewhs8t8FJxAoaW1JG2H+CSKn//T6S7DJgufv2j6HEjy I4VSyq7GINZJYDO09lYtvgmHGfJVXsDiXAucT2KmiT1OjEW1j5UtLrDJHAPb 4I7M9m7aAAf3lllj2jTv2VvAx6nuLrjO0huzwJAIn5FCUY0SVauF9Ysw5PUv s4nZVW1jp+jqRa+T56BX/q/GJVYRtLXiuHVncNN5jjk7pWGX12dRzcz6ZGRo G6ksL/Tbsb3I0Wtj5wre6t17Kg3e+xtlce47Q0Pg+5zhwO5SAFaqJI2dbK6t iVU+nkQBYCNjhG7WD9KAAO8rksy3plGVe+vLruo2kU17fUNZf9NlQd7Y81Z+ sOFZmYQuxT6jcbSwlpY6APd7TH0e+iyvq/iYN+S+jqG0BzQayCWEEHUtc386 PFNqtgkVVn7Hd6LV1CvGfkC37LgNqfY2R7y4jc5zQ5oM6RuPylVc3KP2fGrG RuvtYLMtxgmXe5tbfANB1ELQ6neaunPxfWOS95ZjvtcZLt53Tu0mawsK26x9 lmQawC9xPfsP5McNSNhcKOqC61wjbaSIG4kkAHXwCQNMMFljzIlzRu1M+2Pk pY1l9rzXU0Na4y7dxr89UdtLbmi214a+w6t2DTsOT5JvUeK5HSMR247LnbRB AMgE6DkjxKC2mj1i0G/YGFsOInft+lu3NH0uyutoJpc1uQ0Mc/6Ja0E7BzBc DHu0VTKpuqg12V2z2AH/AJIpEaXSmw3EpGPRuaQ4tc4Pc5rC7c/Q6WagBu1N 9lpEAOdP/GA/keVG4XhlDWuZbFLPdLPbMvdWPcBoSoenlHj0uDyaz/34oKdS 7Hq9R7m1FjSf5ob/AG6D2nbZt08lVNmFTXb9oc9zXshpaJ2O/NMl37yNfh2W 22PFlFskFtjm1nf7RJlhTYeFe3IrcG0MaDDrAxugPtJ9zo4KSmj9pxQwBlsk n/CNLhHb80hL7XiNcHG0F40DhXJA8J0MIdnReol04+K6xgP+DaC0k8jdJ+Sq uwbG0ne5gLSdzYdII0ILg3t8U00l0Tn4RbsNtpMzGz/aEP7dgOjebS0EkgMa NT3ncswtGoIImJkaD7uEe2lrPSsbaHn83axwkcT72tBSodlNt2dg9hdIABJD eB/aUv2rjgED1tn5rRtAaBx3WcxjNzA4urawzvLZif6qJdQxlj9pdYCPeSzZ +DktOym9+2KWmYtf5BzRz2mCov6zQ4bfQs28ybBM/wBaFUxKmW2Ey+stGkND iRx+8Ffb9Xs2ypttIBpsJLS9wYZBiS3VL6KYU9ZpMM+zuABBc4PEkDjTbEyr Yy8Gwh3qQ5rnvDbRt91kBxkbmzp4rNyenX4ZeMhprEEtfBLHkn81wEaIBreJ 2w8Bwb7DMkjtHKWxsdFO+YeNzfo+LdQoOal07o9zfeGF9xaCR9ENB8jyfFaj Oh5znbXhtYidxMiFeGQAAyqJ7Wwka6auVt8kltfsbG4+1/n7Poj6XMcpJe7H x+woov8A/9S8HO8SpstcPNGbbihwmlkeBCObMF5DnMaI+i0D+IU5l/VLFXi1 /tlVLS+7aG9y9waPIS7QLIxuoehdfe+xsWtdY0C6pwaWgvDQGPJ1K1OoU4lm De3RktPeRA7EO0AKyLMPGPTywms2fow2trKt257mtPur04PZRSl6hX4r4jQ2 iw8ahmMNzW22NBJa+fbY8e88dgJW3issZQWBzSG+57X6h5Hv1dHtknWG6LPu qdsdXQ3dA2NDdYJEcgaABxKvWY36JpfkvawRu9MNaS0GdQ0bnKRj1Oq2OBVi 2V5Q9MWtcXuNjTJe3Vzt7u8zOnwXG4ldL+oNxt28ucWNsbq0knZ7ex0K7PJx mnCtN5dY8N9rHkllUgwGMJI08TK5bp4jrNWQGmyGuvIrEud7TIaNJgppB0BX RI1bWe3HwqsbA3OY6s22btSLS4gVOjxgkH4KuSwsaNxkH3GHcd+VPIznXZ/2 6qQ2osFYI1hmuo8ZMqx9YMN2Ll1u9MFuSz1gRIEmN8g8a6psvBcOgLT2YxLj LiYgAmQCePpIopu2gujY0gj1Ng1B77jKDWyx7G1NYA22xtYMmOdHbpEBPaCN zXb3EEgxuIJBjmT3Tfp+xc2a62imsMx2mZG5+yXGSZaC7iOEO31Nu37NAs0G xjSDyfzXHwRXMyWvIJ99JqA9hjVsSBEe1Ae26fbS4isbZLRMiZIgajdMI301 VSU5QpyHenW6pza6q3gNYSQK2xzzxPCY9RfuE2WNIkSQ0R82lWMvEudlOd6I ufw6x1Q+k2G9hEQp/Y2tglhMt9wGPwYGmuhQ17qZZGXY20gOtpa0MGxsEN9j dOQgV3MseHWWPe0EEtc0cj/rnktQYgfD31Otc5rNzhU2HQ0eHhwmNNAlpw3O 049FoPKdSk/TraafXZt9P9K72OAlvkY3DRSoxsR730NY1tL3uDWBsDa4e+PD mUq67G33B8teXbnwNskgO3aIuO15ySSASbTLp/k/GEzqvGzyWW4jJvx/TbTQ y0tYxomNp2btzpdMea6PHopP1YYTSy51LHWMa8aS0OM6fkWT1zCLczKtbW7Y 4th7RLSSWkmV0PRWNd0OgPEsdWRLuNWlKkDcvGD1LG1+s8H6IDQ2APcIb9EC NV1H1kqb9iryKa2HIJZT6rm7ixri50t51lc7fjPofVNbqw5zdDoPpDQarrOp 1m/pr69u50N2MOskH80EooGxcDorrWdUssc4vsfS8l7g4bjuZqZAMrpg8uIN hHA3a+X8pcz0et9fU3sLCwip4IiDo5i6SHbW72h0DXxS+iY7JfSpvFLbWB4B D9pAP0SfFZR+rnT2uxw9oeG1lriCWl1jnbi53y0WpTxWO8/cJKZ7twZxIdBH J+SaV1OUOvY1LyJrc4e0y9zSI8vTcgWfWhn5ttfh9Ow/+ikRuNhWXWWZFTHP J1Lid2mg/BO/p/SW6mumD4an7pRlOidVnAGl/wA4q/8ATUxM8Wf+k0le/Z3S f9DX8dg+9JLjl3/JXAH/1b5vwA4g2U6Ad2+akMjp4IPqUgRqZaPBYlloG6nb Y8CW+oMgbSPFp9IGD2Sa4O+kyDG33ZIA18fYI+SPHLsqh3d6vL6ZuY420xqT O3iD4qeRb07MpBqsY8UvFji2BEbmjWBpqudIxqq2CwfR0AZkbiQP5LWodovD GPrxXikSXMcXvJY6TuO1ug8EhOV1QQY6b0y6jmlt7aGXW0WNL3uNYiSfdt+k NABoh9PzMq3IaHZdlzSx9jKXgw8sBMcnwVz7NjdQLMp9rKrHgHZ6nqPIDQ2P RqHh/uVnC6NUwttprvuIj07bX/ZmgGZiPf8A9FOAlxXotPCBTebk4z8N+95r a5ge11pDQQ73bRu7iIXN1MyMfMZm41Pp11lzW2XFranVuktHuLddfFbLPq81 95yrrRiWNj02YugaG6TvdrJ+CvWdM6U61jrg2+yYY66x12520u4sJB9uqeQT vosBEdtXlsjFyaK33ZEN3HfYWva4y937odKKHnJe3HfZ6T9ofUHEhu5zW7g4 GSN0DVbzundOtkfZKRuMO21gTGg4GnyWZ+xPtlrnghldexrJcRtdBHthp/dC bKFLhKy1aOnZFuXXitJZYZLzDtAAIcCTtI+av2fVuz0Xu+2B2SGGz0tkFzZ1 c0bi78EUU5GJTX6VjCPpi1vu/RscBY1ji3T3HhXazS99vUOnu9TqAY2m2kGW tDS4B/EnVLgFeajI3XZym9LpuqcaGNBZ4tMgkTD2+p5+CqO6Fkeuyp4GrHOk tI0YGl7vpx3gK3bj49Fz6hZjv2nUurtLiT7nSWMImT4pRgbtzn0ghpaIZaeY /kjwUdeTI1s3pVGy22va1gPqn2uJDInjXgO7KhRUysl1OQWmNdtdgkfJq2L8 jBbY14ILrnEPc1tugIIJEt51SZjdPJmtlt7nezbWLJJPYF0NH3p1AnRR0Ful jGm1tFLH2N/RVjRrw0QwdzoifZ2wdlsDVoaWk8O5gHxVjH6Y3Z62Rj1GwNH6 MQ97oaGtabH7R2WZ1Ww4XTXWXYf2a979jKmj1BtefbNm7aD3TtANVomCr1bK rr310MNIO8lzw0O2tG90QfpQShYvW3XPH2etjWuMt0018/TMcLEa692UzENf pWuBLTLQ4GCRqJ8Fp19Nz8wOvxTVfBDNjwAezj7X7hpOpUNm/NkttZOVU2su d0ytpedgcLXSXP8ACE+D1G0VNxDQDjMYJx3DaCOPpRqrmL9W8apjXZhFryJc ytoDR47YG4qnn9FpZS+wUGh7SBRUwiwWyfpbo3aeEJ3DIC1gyAmgjzb6IYw9 PqqJeLG7C5ztrD9ItAA580Y9QyL64fRXkAHQWAs2n4Bqy6uj9SfIqxWkSA5z mwB/nsT2dH6mz2nF3Ndp7K9408dtZQo1/Yusd0xzHVdScGU102isV7a9Wx9M w49z3HkthmVk+ixzhS/TVzyQ74RK5VjB6lNVu5v6SQx/GpNcR9EQTKujpHVG uhtDLGNAc14FIB3agw5oI47oWUu3fm5FQFn6LaPbFcuEu4Jb7iou6o5jWPsq YdsRBI1gl0yAsc4XWbnBv2ZriNTtbR8Tq0COELIxeoY8OurY2tzdzoEGsA8P LC0A/NLVVtje19uxri42brBruG0H95pIQyG1ubvDy52gaSZMcwD4SqmO9xse 42NFJMkkucGgj26NmDpwjAEWkgjaHOAtg7QIbDpjcJLtU2lNr9Yjl/0d/LuJ /rcpKv6jf9PT/wBuO/uSSpVv/9aq3o/TbKa8qxprbY1r3u3Q0btew0QLMHpx H6rV6dYMOyr3ENnwa3uflPkpEN1fIvtEQNRUJ4DY1d8oHmVq9Kpa02dSzXlt VTC1gMbWhsF7g2AGieAAgPUaUTQtbC6FsaHN/QyJD3NHqH+rWZDfnJ+C0G9M xTWyt/6b03mybJcXOPLnuPJ7armPrD1XqVuU7GfOPU4NdXUx072uG5r3ub9L TtwrT25vTel4HVKo9SwvreHNbHpuh1bYEQIZ2UgMRtH6sZ4jua8Hp6qmsBFD RW4CNjWhsga6bYmJRWn9GNdYmVm9L6vT1CphE1ZAMbNT7mjd7T8NVqWwWstA gPkOHg4f3qUHsxtewMcw127dlnteHcEHssvEGPjdQGA8xZWfXx3Ns3hoLDUa 3F2sRC1Htc+AwhrpDg52oEd47wVL9kdLybjkZDG3XgAOsJI4/kggBCQs2m2s XFt5bBkmRPkVkZmUasBgc99NVlrmXWsBIftBLGOA7e5dW3Bxa4axgbAho7ge R5hVrOmjcAxxG1hYK+K3zrFvM8IS1Comjbk5dNrOnW4w+jRW7awfm+3X4k8p fV61r8UurrYx+0tc5oAcSAQdx5OsHXxV1jvUtuw7KXU3GsuFVhA3NI2k1ubu a4Bc30jqttF5xMKgNL521S55scREOdtJnTtCJIFVsqibR47sR1JdXkSK/wCe pFZLm93HZPubPf70EZ3T92mV7T3FT5H4lbL/AKv9SdZ6xqpZkOdu9WhoaQTr w6sjTxBCp5XR7Ky5uQKm3nUObQHOce2+trHc+IUP0ZrCOvEsyb6xitOU152M uqILZdE7+XNgfvALr+mYxpxWNNYqcBJrBmCfHxce6yPq706zFc+29zC8Mmqp tYrcGGdztWtfBdpwuhqMVnX3d/4qSEas92LJK9OznZGYDkXUOsNYEAuaYLPa Htd90ql1r1XdCtFtwyT6lTg/aAGjeB7YJ48SqvV8W79rszmPYGgtrBsJaTYD uDa9NXK9mZlWThvxmVXFtrQWPaz6Lw/Wpwh0EbUpEEG9wqIox8XnMnFqbmV3 YznOtfaTcHEuAbpEBonXhdj0/C+wYzK3v9S462O+HaPILnfqzg3HqmVdBZRS 8wNA5zgTt3x2auqc6dBJA476JuOHUrskv0R9Wh1HOZRdU11oqc8ODAZ2nj28 jaT4omMHixr25TnUcGh5BAntIA08Dys7quGzPysRoaLC2x1r2kTLKx7mx5qd 3TcLp9BzsR/p1gbraHF2x7TrDQ8nY/8Ad81ITrqNmMDQa6l3m41P07Gh8fRD h7QORA40Qsx1V+NYx4c6gja8U7t8HSW7CD8VQxOrMuBorDoawu3ucC4Q7aWu a2eI5mEHpmZlXuGNdU2u0Nkk+5r2ng7Br8fNDT7VUfseZtyDXnWODg8V2Ocw EhziA7e0x4rqcLNF2MHWP2khhEdxHnwsvqfQ8x+eXY1lVVRY2K3BocdoDTBc yI08Vaowg2ljMy5++sQ0s27Q0HRoLW6x4quRRLaibFuhXe2o2u3SdoA1+K5D qudlDqFu4O9AvZPMSRzt01+S6K/Dwy1wF9h01O4a+WoWXZ07qHqb8Z9YDwC1 tkbpA4Pt8kDrSS5dVdDKr97Pc5zX1BkmDPcDWORCsMrq3gW2A0uAk1yJBY4t d4+1xjVWLuj9ZbWXPso2uADtpYDB18j92qGzovUmQ9pqLx9H9IZ08NzoSooa voiJ9Zsent+m76XE/CUlajrcT6RiN07u8xu/nEkNVfR//9fHda8udta5z3GG 7nlxk6aktWn9arzjYOP05hhsbrT4tr9rQY8XSUTG6WxuXQXCALGGDbWTo4Hg NBV3LZg29SY7IY6y6usP9AsaWuZED3WOAJ3v48k6I9J17BbK7Gni0ejN6b1n pVXT8oTmUh4xbGR6gaCXBs8fIq3n4tluJVRkZAdgYbmOyWtafVDQNrQXfR79 vin+zdExr7OpVY2RQa2kvBZtrl3s2MECXHyMIvUsnpluJWct1+PT7pZWIsaN urbANwjWD8k7SmM3fV53K6/VT1Gl+C0VYuJ7K6W6NcD/ADk/1vErtWXVDFuc 58VNAtDj2aBun/NXHZln1buDBXbZuc1tYaKa3O3Rtlz5bqta9mViYW3L6hZp U7fWwVsB9NolgO2T4JRO6ZAaOiMyh7GX47w9m/ZuEwTtcSPwU6bL8p21mT6D GOZvBDXbnGTtE8aBcnVlPbjHIqHqUOiKLSSayTDbCRt3TtIVjC6vQ7JyAz2N awGun83eyHu2n95waWp5kKCOF6rIbm32A15BxWAND2QC87XHdrJGo0CstzaH Ohp478k9/nwsRnUPVspxw/1Bkl1Tb9wM6Eif5R/BUsDJtyw5rawcqj9G9hgF xafwc0zHxhKha3V6XOq+00suo0yKXerQ46a92nwDhoV59kbsbq7rKJaW2iyv 95s+4NPmJgrf6n1ZmPjBrvZeOGg7HAme7D2XOi12T1P1GO32Pe0h0Ae4tBJM eCaaBXRunuMfI6tmMN9RGOwbi5hAv3RrFZBaCZ08PmjnIstcys1341lrQ4Os rnYJ94DgS1p2/lSoy6yxzMd8mr9GanaBj26Q4gSlZnWC70HNaHRJg7mkEwD+ b+KFeKL8G4cWm4NbYxrgz+bMQW/1XAyPkgZmJ+j2V320kCWvbY4kHxh5IcPi qxzLaXN9S2oVzJID+PKXrP6p9Yn4zrKQwOaA0NyGkw0v3BoLdT27JxrchAts YXT8fqOO6/Oq+0ZbbLK3XscWOaKzsbs9wiYmEWj6v9GsqrdssIYHNE2O3auL jJrdHKz/AKq5d+y9ri51dZawySGh4kmA7X8Fo2DBfbRYxh2tcS2isOrmzaL9 z2jbMR+d4ptDddZuklGFhVH7Oxm3bJa4F2+HHWHk7o+alZ07Jbv+zZ1jfboy 1rbWiZ7vaXH/ADln25bMawjKruDbHzWQBALj+a8GPxWjZ1JmNjercyxlYIlz 27gJ7k1bk80t1cvpzuo5uTZWbK8WzFEPsprY4PDj2LmyJjULWbg3V2i2GX2t Hsste6W/1W7C1p+CrUZ/Tn51dmPa02We14aT7mgEmW6cHyWvvadQfgRr96bQ S0S3Ior2VU0N1MV7nNaZ17ViNfJcS/rbq7L6XY7AwtcysBzpbZwHl7tznbfu XoORsNcuO13Y/DVeW5tDvtlzLC1gNjgXCXDV3PtGqbPYL8et22uo9Uy87Lde HPq3hoLG2OiWiO0KobssNgZFgI597j/Fah6VcxvLtPGl/wDCU7OkXQCA8zrp TZx84URJZQHLGTmnT17df+Edz8EvtWWBIyLS7nSxy1LOl3hv0bD21pf/ALUw 6JkDU79I/wABZ2HyS1U5TsrqBgDJtHcfpHf3ojcjqAaB9puM/S/SOj4QtEdJ vNjWw/a4hpip/f46fejO6DlNEtrsJHH81r91qVlVOV6vUI/nrPH+ccktT9kC Y9YeHJ+lG7b9Hnz480kr8VU//9CnU44FtVxeD6dtbXEXAlsH3CNNzS3mF0nV 8f1MMWADdQ7U7/TOzUH3fcUe7GpsouYGMaRW7aXVtdB5BgjspY9h9FpEOO1p LXcGADHzTojSUe+y3IKMZdi5vVsiu3Cd0qh05FLQ62BvY1tY32Ofu7fl4Sw8 LJo33Zhc3FdWwWYtTmkBjt3qD9Gxha1pduIH4q8+j0em5Yj9JZRc61w1L3lj nF0xqhdMfbY91lriSMeotBGvubY534tS8OyqsjrxWbcyr6sdMqzs2Gl9PoMv wjJJa4k8QfdqFk9bzKeo9U2EzjY1biwDl7jr8tzo+S0sfIzOkfV51mUdt7yW 4Ydq5jXagGfA+6FkdCwhm2Z78hjzYyg2s4aXO3D97SCkdB/eUNT/AHdEl7Nt TsqsiuqoCtlTSSQ1rRu57bnFAwsXEdgOybB6TtrzZZvPBPtcGR7oOkDXuodW vw/slAxHne9oGRWRBa4DX5E68pdHzKbMZ3S8vazFl+S+zQPfsZIpDv5RASl0 roFRG99WLestGPSyoFuTS9tlTtNgeA1pnXgwtLCfa3qWRe6r1QbWG5lMurdv YSSw8knUxwVhYnT35dVltch7baqwyNIuLmh0+RAC6Hqv2rphqotbYGBgD8me XVbxTtc3jsQEhI3fZRiKOm7sdQ6Nhdd6cLMN1bLawTU6trWjdzteInVcI1t2 BlhmSx1NtbwXBwIPgdPMLbstt6OMC6mxzbHmcvaedGPLYOmgetj6z4D+tXYL aNtbmhxtuf2Y6No01PfRGVEGW1LYk/LuDs5+L1ajJxnV12toyH6GwuayXtDB v93723koN2dkWW9PdWWusqrcy5+7c0EkDc9zN30jwgZnR3dMwMx9dp9Si+lm 9vD2WNLp8UXplDz0bMy35bHWP2BtG6Xt2WbpcPMjRAEnRJiBZc7qnVsx9gaX w2JiDpOsHd4Kk3MyrrmiS9znhzW9i/6LdF0vR+js6jljNy/dVU/0xT++5kSX eSyOqMoxesmvArc4Un9IH67nCXP0j6PbhAk91wAAGm4bQt690i51XpubaIst ZG9ry/UP0kfMLocXqeFcasnMy/QyPTLTjPLWtZvjd9NoPuAHdVqeodG6k04G Y0Y1tZLaLA47GO42sc0/R+5cxl0XXZDq3PdNbix73PNgc5vsJZOsaaI3Xisq /B7em7AsYMe3PrtrZH0zVsfEH36v4SzcHqGRik9PfS+sw5tLSa+35jvo/kXJ dG6cMrNGAXFleSNrnCCQW+5pgq50XJ6xb1GzAwct5xaXOm5wDw2tpidrp1PZ Hjve/or2z01QUnN6dddbkYrm5j7GFn2ge0jc7dLnfKDK6EddqOJWcnEN4eD7 gwmqeIba5o/BDyXZLc79m33Pzm5NLm2B/tDA4O+gxmhMgHyXNZ/VMnKorxQT DWtDQdAyB9EIXSjGzRGrpM+sLptxKnuDj7KrZADI9vI+kOeVmWXBmcbnj1K9 x5Ehzfo8O8vFA6XVQzqFIzpZil36RzRukdh7fE6FdD1T6vYz6n5HSbRbXtNj 8adWgal1U66fulI2RS4cMT5oR1LMJmrMe+k2gBsvY9tb/o6hzR/cuj6XY6/E fc5z7N/0HWl07RDZaHRAJmFV+rfT6LelMNhsc5zHDR5aIPIAb8FexiW0tALt hrEOc4u78S4ymAMoXrA9dkzodRJjg+ayetdUOB1Ngc61tLzDQ0u2RtEuaD7S Q7la9b3C5nukT8AsT620h1GPe1x9tm0t3EjVrtQ2Y7dkjsFFpt6hmNNXrZb7 KHbhcZdLY17v1AH39pUAMzJc+6htpY6wex7d7SwANOuwkcyfJdDjdOxXdMG4 P93piwb3Q4bgILQdsa+CNiYmGczMD8et7ha4BzmNJgBoGpCFahFOD6h2+psf 6e/b9Js7J9L/ADd/f8ISXTfYsWI9ER6Wz5Tu2/eklw/lf1TT/9HetJ9C8n/R ucOTpBUcZsmoB2ww0dzOnCpDqjHMs1AZazZJrvfAdppFbR3TDLqDdjss1t4L vSdWRoG+0lhfPzT+E6Uoyjtu6eQ5lVNnrtcatrhaA0uaWkah3xCqU9SxbGv+ zssufUNrq663bmtYCWtcdrY/tFMa8GXYr3eqWBzrvtD3PDQ36TnMkx/ahDye k4tjjkVUOLgJNjCanGP9E7v8He0p1y8LYqjf6QDk0Wt+sX27LyWubRgUvOPj jUb3Me7fYfEbUH6q13B/UfUDgfs7oDgeJEfJTzemWVY+Rk494NDmkmq2locT G32vYNu77j5KOL0W/FsLvXbdvaGuptY4EjnT3Tp5JlEnVkBAGjW690euurEv oB3ZLC+0kwwENb90yhXdAdkVfaelfpq27WuZ+cXBjC5zZ59x4XRZeNl2dCYa 2il1JNQ1JArDhDvcJ7LnjRlsAH2q1u7Xcx5a09tGt0PyKRFIjK7vu0aW5uLY 1tjH0PY4Fjntc2CDuDXTyJC6R/Vq8rpO/qNjPtNr3OLXA7TDXNaGN8QRCxLM XOeGPdlOy2NIBrL3EtJ9ojf8U2LY820h1oqbW4vo9YbRx7trnQPpefKWw8VE XprW7WH2nKs+02AH9I3cX8Avd3Hgu7ts9O0EkFtLGl4HcN+lsM6kDXb4cLCx +p4+FmWvzSLrdrGUugaAglxbLnCRuHdWzfQzCoy7aDbusFtmwOYahYHD1Gx4 NjyRIoV3pWvFY/RGnit9YHO/Z/UH0u9nqYrmls8GsEGfgVz259HTsTOa8m51 z26w6NkHSRInctnp1HVc5uS7BvnGZb6bfUIMhjQGE/oyPoqpTgZGT123GyoL 6LGGwfvbS1ntAA/NKaN9l0trdDpGRbj9DyMmyKA71X0uc3Qkw1v3uBhc5hfa 7LrcnEoda2uojKM7yWvaWPd7uCR9y7rAoxn9HqpyKmvrDHh7bNRDXuPB8Ilc tceq4H2Ol7RTiXVtaHwz03Cza525zW8gRM6oJOwrs0emYDct2ZZWdlVNT3t9 QB+2fog8ax3Q6bxYQAILWxt8IAC6Rz8PEY/Fwstjaciuz7RYWNOrA5u6rZtb LvNctmmLW2DYHlo3bNBIHPx8UT0WRNk/g3sfNswbXZVY/Ssa4VHwc72g/KZX Q/V+mrp3Ra83Iaa/XebbXkEktDttXyWFgdJs6iWuiMcW112HUSHnWPgF3+VX j76qnVh1ewsZUWjZtA4jjSEK0Xx/Jybep4NlmNZit3WnIr9a0NMtYwPsgE9o BXL9cpqwbciiquWtyi71o12uYHNrDo7btVt5vUqcTqQw8XGpijba4MqBO4ib B4BzREH5LMycpl9dtV+NNdtxyH+5zf0m3b+dMCEiaAve0a8R8nDbk+5kh0OP iPGPBa3SKM44mXnMudXRjOMS5zQSPd7dvJEDQ6Jx0Wm/Ix6XVnDY8l32kva+ vYBuO1w9pP8AaV7q2ZXgdKHR8PIOUyyC6wtA2N3b4G0wZKIPU9FsukRuXf8A qpYD0uuTrB0j4o9Ra+locQBsPzgqr9Vf+TqST2iPj5IjSLKmRIaATxp9JAmh 9GUMw0B7SHDmY1Qcu+vHqa+6svaA6WtaXO1a6NADGuspVl32mtvYGSfLwUM5 uU/0hgx9o3SxzpgANs3Ex5JvRTZwrWt6e1xd7Q1pfPGmvKfpttduTlPrIex9 ri1w1BkDghAxGG7pppfrVZXsO2AYIiBPdE6fVRjZGVTW3ZVRYWsb4NDWo9Y+ SkX7dxo3bLNnq+lu2eezd8N3tlJX9rY27K49KY2COd33Tr8UkL89+H6p1/a/ /9K7W+x91jQa3CoMPqAE/SnTf6hAiP3kLJqccU2Pbj7oaXSdrTqJDrYAjtqS jsnfp9r593rxu7/R3fhCq5fq/ZHxM7v+1np7+fPT4KU7LBuGp9tprj1Hsc7J LhdkN3u3S4Oc1oDY920M9pV1l/S22vbZT9nZAdW79Ya7w0Y0jiFXu9bfjx6e /YOfS9X6Tv5ufZCvs3+vp9LaN23Z9q/tT7dvwTQktF+LmuAL8qxzd0kue9rX AjQRaCHEcSo2YuS11RfZf6AkFpeHTPG0Ns0g/wAlabOTETt1/wC5Hz3aJ6ts 2R6UxrO71/nKOi3VzmZPWasN+DsfbU8OZLcd73weHOd6jSHa+CoWdO61iyRk OtDm7nMO5hMDvIcJCsdc/nWbPo9/sn87O3/D+p7p8OyL030/RPqbN29/9L37 +G/R9L27vH5IHfVcNtHDdZnt9ux7WuIJBfLYnd+bEGdVDJy8qq9rK7HNpYXi uYcAx5kgNK6fD27H7/s/857fX3bvl6f53xQsn6To2xp/xfP8rVDRVns8/ZXj Dp1XUKrWnJqvLbKJDZaYcC1g1AUq8/Pk44seMSwForZaXBjXabfpHxhWOp+n vE+jxr6m/Z34jutdkfZG/wA3O0/zszwP5z+KdQ79FOLhdQy3XNxWssh3taK3 M3FwGpO8FvZXbKMil37QynWNcNtdXrbTBcQA8GvTaOCj27fSd/Q/oj+bndx2 /gqeJG7vO0/zk7Pofn/yP3/km6XobKTtqNHW6llZleCW9PursoyG2hrXiHDd Lnt45MkiYXIZnUuo5tddWVb6raRFTfaI0DewHYLUZs/aVf8AM8H6G7/WVXu2 aR9g3aR6e/f8p9v3pHdQutezQxTWLwbpEEB1X0WvAIlrjOgWxm0YIrP0vsoe S0O0dWHmsfmyNA0hVbP8D/Q53aRz/a7QrNk7bY3cD6Men9IfSn81N06p1dPo IpZ077XZlNDBc17ay4Bjdp2ndryeeFsdT63iVnHfjubnOlzXV472ueJGh2js uHO+D/NT/Znnt2QmRtdP2aJ7zP4I3psqN613etqD/tIzqSzDyLg99dWQ7U+o HbmbABG7nUwqjfSznGzP6kyqZ2tkWP1HB4YweTViv2xZGz6A43bPzfo7lYoj 0WfzPb+c+l/u8EJUavRQvXrqldjW4zizGuoyaXODvT3MdU8j6O6qwjVUepV+ mxtzajjhxh9G4OYD41uBOnkVO2N7v5qP+j/eqeXHps/m+fzZnjumpe7+qzT+ zqXd9sg/NWqIFEGDAcBGn5xS+qe39k0/zX0TzKNVt9ARs/O+hMfTPindlwar HMNrAQZ3R96pdfuvw8EZGPLbq7WbHc6Hc0jXxBVxk/aPz+RyqP1l/wCSz9L+ eZzx9I/6lBTr9OoYMJm2PoDSAFCl7Rl57e/qO/6lqL0v+gM5+iPj8kLF/wCU M3j+dP8A1LUf3fJTZgRMael+HCSb/B/4D6P9n6f+v9pJN9P/AD/x7pf/2Q1l bmRzdHJlYW0NZW5kb2JqDTI3NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDc2IC9IZWlnaHQgNDUgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjQ0IDAgUiAvTGVuZ3RoIDE0Mzkg L0ZpbHRlciAvRENURGVjb2RlID4+IA1zdHJlYW0NCv/Y/+4ADkFkb2JlAGSA AAAAAf/bAIQADgoKCgsKDgsLDhUODA4VGBIODhIYHBcXFxcXHBsVGBcXGBUb GyAhIyEgGysrLi4rKz49PT0+QEBAQEBAQEBAQAEPDg4PEQ8TEBATFA8RDxQX EhQUEhciFxcZFxciLB8bGxsbHywmKSMjIykmLy8sLC8vOzs5OztAQEBAQEBA QEBA/8AAEQgALQBMAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAA AAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoL EAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAIC AQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLh coKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMR AD8A9JVDP6xh4J2Pdvu7VM1d8+w+aofWHrbsOMPFP6y8S9/7jT/ErkrLnMB1 Jsdq5x1Ovf4p8Y2mtLLu5v1py9RXtp8GtG9/zc7T8FUw39V6tad+TZXQ36b9 x+4CYlZQxry6HNIJOpK3K8tmLQKqRu2aQOZ8Sny4IR0qUj21pEeOUtuCI010 s+ZdarpXSmM2urda7u+x7i4/iFQ6h0mylpv6XkWsc3U0b3EH+qZlVj1i1ol1 ZAUmdVvc9oNZAJ1J7BQiYvSz5xLKcUwLNUf6wauL9Y+o0kNsudp+/wC8fPd7 vxW7ifWeswMuvaD/AIWv3N+beR+K5zqWP6l3rUt0s+mOBu8fmqbH2UO2vHtP I/iFOYwIBiRf7t6sIMrIlE0P0q0L6XVdVdWLKnh7HcOaZBU1wOB1S/ptwsqO 6lx/SVTo4eI8D5rtP2hi/Yft+/8AV9m/d5eHx7KLh1XVq//QbLyHZHUMi58k vsd2JgAwB9yqudLp8StTrOC/B6na0j9Fa42VO7EOMkfIrPtYWncPou1HxVjG RYVkFx0ZNcfSscSSRCZuVt4EKYNAYWMc5xcRy2FZbh7p9hA7SIUZ4fdmQCAa r0mPRljfswBkJGNiXrEuvgg9c2Y9hP5pH8VFmYXPa3XUgferNmM5tZY1pO49 gn+xQZA1TY/PPxIr7F0iOCA7A39rVy8k2WuaZhsBgHACrk8KzfTsf+l03ag8 8ILxXIFZLj3kRr5KTAYiHDIevuY9ep4mLmBI5OKMrhWwmNug4d12vHpwZ040 Ku/bLf2B9mk7PtP4bd2379VWc3YwM5PePErpP+b9v/N30dv63u+0be+6I2f5 v4pWL+quleD/AP/R77qHTsfqFHo3jjVjx9Jp8QuSzei5eFuFrPVx+1zBIj+U OWruEycCRskW+ZW476/c33V/vDt8Vu9IvqzKxU4j12DUfvD94fxWvn/83tx9 bZ6vf0Z3T5+l/Fc/cOhm8fZnZbb59nptrcZ8oc1SSkTECYI7GlsRHiJgf7wd v7F5IWRVTjVOuuIaxvc9/II1DerekItkdvXrZv8A/A7IWP1BtAuH7XszCfzQ 2uoV/wBnbYQmDfVfq5ORc/LyC5jedGtHYKzh4Fr3bKWG67uGiQ34ngfNbXT/ APmxtH0/+u/R+fpe3710eN9m9IfZdnpdvTjb/wBFSSnIgVEiPRjiIgnXimd3 J6T9XmYz25OWRZeNWMGrWHx8ytxJJQ2bX62//9kNZW5kc3RyZWFtDWVuZG9i ag0yNzggMCBvYmoNPDwgDS9UeXBlIC9FeHRHU3RhdGUgDS9TQSBmYWxzZSAN L09QIGZhbHNlIA0vb3AgZmFsc2UgDS9PUE0gMCANL0JHMiAvRGVmYXVsdCAN L1VDUjIgL0RlZmF1bHQgDS9UUjIgL0RlZmF1bHQgDS9IVCAvRGVmYXVsdCAN L0NBIDEgDS9jYSAxIA0vU01hc2sgL05vbmUgDS9BSVMgZmFsc2UgDS9CTSAv Tm9ybWFsIA0vVEsgdHJ1ZSANPj4gDWVuZG9iag0yNzkgMCBvYmoNL0Rldmlj ZUdyYXkgDWVuZG9iag0yOTIgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCAyOTMgMCBSID4+IA1zdHJlYW0NCkiJ3FfZdts4En3nV9Sj 3MeiuYgUlTdbdpw4tqOYSnpm7JweWIIkxFwULnKUr+8LgIs229Ovc3IUEwQB VN26davw0xiQbQcOBU6Purbdcyjjxp+UGD8NCzMDmwK866qnauZkGNoBTXKy 1L98YtgkyDi54xErxIoP0yjNRMyLTEwoE8bJZWg7NM+Ns7FxMrb/wkk2jWdG 1zIty3JoPKGB2gmmBI4Z2F6fPN83vUEQ0Dg2Oo5zNP6hl3qbS225FE9O36fx M9naHvzx+6bb83GMbffNgevYcpv7zmlCF7MjO+jMxETwpKBzPsGfjEXiN5/S 56R7LRJO46OB08lY/eXR9/EVsOjapu26AxqfG52LZI4PeSaSOZ1Gc3hbLGKa pRndjK5DuuXFc5o95Y3VvrZ6/AeMeH9kO4OOSWcRSyaLtTzrmK5NunlwPTtK k2O6NOmaT8vJMZ3xaC7KWFmw6T6scUzH7/elNfedHYNp0zyRULHgNMrkJM95 MuGUzrSPZZLwCB+p/TeioSANJKTbbrNkSucIcJaLYk3DNMmBnUiK/B29T7O4 lOFPE8Jn0vONGCnHr9k8Y8mcs0TinsbLFNvI70+XS2VdyiaL1tUWs05oUpiJ FcsLtmJAxaRPEnHxxORLBsjOgR+fLsQxfQ1Pj0keLxfemDQSaZYe0yiNKrP2 aaR93ob0lG7KCNY9/uATyWn6rNHVDLlLy0KCe5NOedTEfQNGzcx9BF9ixkHw FWqhOTTpIntkOYjBs6Ou34lZUtGmnRojxth8wTPpZ65MuRhXqToMsWvQ/MKh YfdMu++Sypkb2PgDvyu6/27RlAydPTTwbNMd9Ck2XCswHeR//SYywsO5rNxu 07BvmT0LLg56fTPwXE9noe2/s6yu3X/nWrQ46tqeFXRGDEkYAcuQ57nkxGCP 8zjBtTxfwjmQkjSeghgFGJcXYsIiHa9lxH9JQgPerYAiniOeIVDADglwmrBo nYtcZgJrV/KMnsGranUbtvvOKBMyydf0peQlzyXFwf9MJxVoD/U4zSRFo/wg g29MUPE0Aj//BS6nyRyxYwmbsl1G7tDwrNS0g2WfkXezKH2ms7REhDXrGsun dMfnpbJkL5u3XdkVi7DQXrB43/TdFK6167IUiFYskHnvM4noMd1CtMTTgiXp SnPzrkQkka135p2pNlY73LDfZTxlWcPfuxSa9MgzIPLvanf5tyMkRkjmt7Tv DKF4FtNiQeGCKcWTIaQPvOBaVOY84WmZg1nZSkz4Pjq7SXrfueM/S6FRiVEf XsVFpWu/SlepVGdplhfSbbp9cPvOg+vbPO+CN+KH1q7/PLOs2M/Y14mwSTbk R04fE1QIhB36zmjEJk+82AglPa7foMEZlsw1QqDTbs3T227S6yJZaUjSRGLy BlV2JfsT9FkUkwWPomM6NWmFIjDlYAyfrdJUwiFD/ToEIYthS3fEEN5rls05 yshKVHDIbBgfod7LIsXjV53vVEmsiHLJFE8TALosixeEuXELWXyDA35wSO6N duOrANMOxxMCXGmp7w3MnhNsaGn95oCW7guo73lmEHjOYQF1XGtfQG3rkILW eBwQ031lUNWt6Q92otFMKi28gPKVuvpDUj8mMvm62CYBK1HeIyi0itOrmbQV o1MTnLniCcgDqkshAW1G6ZLnk1I+Y3QrojyXDVP4zKc8aUK3316qJK97zF4A VGU12u4x3bd6zP52j+n6PY3dTpO5i6KMTCzViC5QqeKmRULB0Mlai2NnGDHE blZhpSh9ncrSdvFrspCdU96Up13f5PINnF9h8ZZeIYymzho0ElH3A5uKqZDM lumbRrA2qUaYDdNyyhJMX8zXy+Kf9qRnfMFWKKKSHyGcYo8R1wIzgUi8A2+j WXe/1Ubai1hETBVfiZpuZNMinaQRBGDJke5JJesvdFQSnAfX8U2S//9+Qsu4 VOn74Fp9ppqFwPR6riSISoT/Htl+v/Pg+D2QGE9RXa9015w98fULyaUg7la7 NXigU7lK0SfTECWKTcAF8btJFtWda/2uWoi6gVYBqqUdN5Ta9wlSnKveReE3 k1ti1aFri3T9jOXQbxwWArQFk+0SXXfDdV7w+PAVZVQV4pBFKzZNK+dlxqVz 1LFMVXX6duT2OwjkVPafI4h4OWfRa6Kzw5D6urWRFnDpA2erdbeSchHxvdK0 32Vv0aWFWDqay0L2pzSUP9I5K1DTRFIr2p7ft6bS9+wpXcli1fYwX9HDyDsH n/MKjM1WvOq1K0GggeWbFnQhNnzLMwfOoHnzqta7foCPLLneMXuDgZKTHa1/ +fpyUNBRH3mULqVID1HlCziQazTkHWSRLg9g2TMhjT2NpQZumvB8ytZHnge/ XSTqEsRBx0aOZbm7zgdwNXA3fK9e/G+uB5ZrOoHf10pqDZTv1ut1zv6HdU5X f4lJlQL0cee2usPTc5FPtFQXvDsWMafN/mHnFvBNwsReqnbbJQ6X1vcCBhzT B7SNWZlwju7ojEdzUcZvNUPKdghgxNbtdUaWDIYsTZbaJh4v1eVVWn1QXK8h rtLsqjmmHWy0izoZn1OdiWuU4LafR8Zuuaw0WhT5ZtU/nGx13fmErFyzWDeJ n9JHDPKFUKNb9sTm7BlTV2zJkjevAu3FiNF+1JRYdqWn4K5ydB+RjnIYXd2G +VSkuKzJcoX27llmzkHRRDTP0RjjtlFrxJVuEK85L58Zy1Cn1Ls7nqvLDRrG yoCqgL92G2iq9i4PlnxSICXq2rBELyp0cXgPpSs4tVfIirEj1IADrlclG+Ft 2CBjqXo5VhUmiePBC+5951tVM25ZGddXQFggvak14gt9IcOmOX6CjJM7dZdZ 8WEapRk2hjxNKBPGyWVoOzTPDXdgWp6LDA9sUyav6zqm5cJmx/R7lHFj9gdc mDe60t+rxIFSmIBUl9Z3tayMsnSOliwmOzDp43hIUCrL/cv7awZFt6xOpn1G 62r+/DUlkuLty4PJdt7hEMAjcXV6tV82XSJAHqnu8AYH/sDviu6/WzQleCE9 kOVAPXmy5VcP6pWrnyLDd3um0/frb9uhWuD7zVDN9qx2GMmNPbQ3fSirOsXz LDWQB3leM+E2g/a4dl3zpllcH9puUZ/b7hMaJ8PQsWgYAnwKh7dAwpFQ/N/7 3UbdcCUj3UByzJIH+lY7jJpZzw1qi6oP6jeRgctD0A9M15deyoFrqQGM8Rx1 dDvdvGm+cV2/OlDj3QwVhvWwdrD9oAZB4hV4vWp/4FUPosbzdrpGp/2mPU+7 33O23G+Gf7NfBUkMgyDw3lf0BU7SgEne4///0AV1UQ899ZibKCyLMDuK71bG bwt6k241W94RCqMA6UiHyUo929bA4V7NmSaidtOHHg16A6nszi2pHQXBFjgy LnE90TD5LA2LHU3iuR1fIVHmEBDVjtLCY1sA5pmI+lRM9jLLU5E5R7NZJB06 xw6wVFF80thYSFv01I0d+gud8zu6pM6fhbRleeHja43pG7v2IF9J9zIDnice fi0gbwRrS5BpifrZyaiBWYnxj4nUa5nI2HE2WTXpwJMQLCRjdWPm6CF5AqBJ FtypFAnQ2DMFyyMJelwzwlJF+aWtj+A8gvMIziM4/xacrwADAEep4KUNZW5k c3RyZWFtDWVuZG9iag0yOTMgMCBvYmoNMjcxMCANZW5kb2JqDTI5NCAwIG9i ag08PCAvVHlwZSAvTWV0YWRhdGEgL1N1YnR5cGUgL1hNTCAvTGVuZ3RoIDgy OCA+PiANc3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49JycgaWQ9J1c1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCcgYnl0ZXM9JzgyOCc/PgoKPHJkZjpSREYgeG1s bnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjJwogeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4w Lyc+CgogPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0nJwogIHhtbG5zPSdodHRw Oi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJwogIHhtbG5zOnBkZj0naHR0cDov L25zLmFkb2JlLmNvbS9wZGYvMS4zLyc+CiAgPHBkZjpDcmVhdGlvbkRhdGU+ MjAwMy0wNi0wNlQxMjozOTo0N1o8L3BkZjpDcmVhdGlvbkRhdGU+CiAgPHBk ZjpQcm9kdWNlcj5BY3JvYmF0IERpc3RpbGxlciA0LjA1IGZvciBNYWNpbnRv c2g8L3BkZjpQcm9kdWNlcj4KICA8cGRmOk1vZERhdGU+MjAwMy0wNy0wMVQx NTo1MjowNiswMzowMDwvcGRmOk1vZERhdGU+CiA8L3JkZjpEZXNjcmlwdGlv bj4KCiA8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnCiAgeG1sbnM9J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nCiAgeG1sbnM6eGFwPSdodHRwOi8v bnMuYWRvYmUuY29tL3hhcC8xLjAvJz4KICA8eGFwOkNyZWF0ZURhdGU+MjAw My0wNi0wNlQxMjozOTo0N1o8L3hhcDpDcmVhdGVEYXRlPgogIDx4YXA6TW9k aWZ5RGF0ZT4yMDAzLTA3LTAxVDE1OjUyOjA2KzAzOjAwPC94YXA6TW9kaWZ5 RGF0ZT4KICA8eGFwOk1ldGFkYXRhRGF0ZT4yMDAzLTA3LTAxVDE1OjUyOjA2 KzAzOjAwPC94YXA6TWV0YWRhdGFEYXRlPgogPC9yZGY6RGVzY3JpcHRpb24+ Cgo8L3JkZjpSREY+Cjw/eHBhY2tldCBlbmQ9J3InPz4NZW5kc3RyZWFtDWVu ZG9iag14cmVmDTAgMjk1IA0wMDAwMDAwMDM3IDY1NTM1IGYNCjAwMDAwMDAw MTYgMDAwMDAgbg0KMDAwMDAwMDE5NyAwMDAwMCBuDQowMDAwMDAwNDQ0IDAw MDAwIG4NCjAwMDAwMDg4ODIgMDAwMDAgbg0KMDAwMDAxMDE3OCAwMDAwMCBu DQowMDAwMDExOTkyIDAwMDAwIG4NCjAwMDAwMTIxNzMgMDAwMDAgbg0KMDAw MDAxMjM2MCAwMDAwMCBuDQowMDAwMDE1NTU2IDAwMDAwIG4NCjAwMDAwMTU3 MzkgMDAwMDAgbg0KMDAwMDAxNTkxNCAwMDAwMCBuDQowMDAwMDE4MzYxIDAw MDAwIG4NCjAwMDAwMTg1NDUgMDAwMDAgbg0KMDAwMDAxODczMyAwMDAwMCBu DQowMDAwMDIxNjEwIDAwMDAwIG4NCjAwMDAwMjE3OTQgMDAwMDAgbg0KMDAw MDAyMTk4MiAwMDAwMCBuDQowMDAwMDI1Njc3IDAwMDAwIG4NCjAwMDAwMjU4 NjEgMDAwMDAgbg0KMDAwMDAyNjA0OSAwMDAwMCBuDQowMDAwMDI5ODA0IDAw MDAwIG4NCjAwMDAwMjk5ODggMDAwMDAgbg0KMDAwMDAzMDE3NiAwMDAwMCBu DQowMDAwMDMzOTQyIDAwMDAwIG4NCjAwMDAwMzQxMjYgMDAwMDAgbg0KMDAw MDAzNDMxNCAwMDAwMCBuDQowMDAwMDM3Nzc3IDAwMDAwIG4NCjAwMDAwMzc5 NjEgMDAwMDAgbg0KMDAwMDAzODE0OSAwMDAwMCBuDQowMDAwMDQwOTIxIDAw MDAwIG4NCjAwMDAwNDExMDUgMDAwMDAgbg0KMDAwMDA0MTI5MyAwMDAwMCBu DQowMDAwMDQ0MTY4IDAwMDAwIG4NCjAwMDAwNDQzNTIgMDAwMDAgbg0KMDAw MDA0NDU0MCAwMDAwMCBuDQowMDAwMDQ3MTk4IDAwMDAwIG4NCjAwMDAwMDAw MzggMDAwMDEgZg0KMDAwMDAwMDE0OSAwMDAwMSBmDQowMDAwMDQ3ODU4IDAw MDAwIG4NCjAwMDAwNDgwNDIgMDAwMDAgbg0KMDAwMDA0ODIzMCAwMDAwMCBu DQowMDAwMDUxMDI1IDAwMDAwIG4NCjAwMDAwNTEyMDkgMDAwMDAgbg0KMDAw MDA1MTM5NyAwMDAwMCBuDQowMDAwMDU0MTM5IDAwMDAwIG4NCjAwMDAwNTQz MjMgMDAwMDAgbg0KMDAwMDA1NDUxMSAwMDAwMCBuDQowMDAwMDU3MTc2IDAw MDAwIG4NCjAwMDAwNTczNjAgMDAwMDAgbg0KMDAwMDA1NzU0OCAwMDAwMCBu DQowMDAwMDYwMjQ2IDAwMDAwIG4NCjAwMDAwNjA0MzAgMDAwMDAgbg0KMDAw MDA2MDY0NCAwMDAwMCBuDQowMDAwMDYzNTI4IDAwMDAwIG4NCjAwMDAwNjM3 MTIgMDAwMDAgbg0KMDAwMDA2MzkxMyAwMDAwMCBuDQowMDAwMDY3MjA5IDAw MDAwIG4NCjAwMDAwNjczOTMgMDAwMDAgbg0KMDAwMDA2NzYwNyAwMDAwMCBu DQowMDAwMDcwOTQyIDAwMDAwIG4NCjAwMDAwNzExMjYgMDAwMDAgbg0KMDAw MDA3MTMyNiAwMDAwMCBuDQowMDAwMDc0NjQ5IDAwMDAwIG4NCjAwMDAwNzQ4 MzMgMDAwMDAgbg0KMDAwMDA3NTAzMyAwMDAwMCBuDQowMDAwMDc4MzcyIDAw MDAwIG4NCjAwMDAwNzg1NTYgMDAwMDAgbg0KMDAwMDA3ODc0NCAwMDAwMCBu DQowMDAwMDgyMjYyIDAwMDAwIG4NCjAwMDAwODI0NDYgMDAwMDAgbg0KMDAw MDA4MjY0NyAwMDAwMCBuDQowMDAwMDg2MzA2IDAwMDAwIG4NCjAwMDAwODY0 OTAgMDAwMDAgbg0KMDAwMDA4NjcwNCAwMDAwMCBuDQowMDAwMDg5Njk0IDAw MDAwIG4NCjAwMDAwODk4NzggMDAwMDAgbg0KMDAwMDA5MDEwMSAwMDAwMCBu DQowMDAwMDkxNzI5IDAwMDAwIG4NCjAwMDAxMTA4MTQgMDAwMDAgbg0KMDAw MDExMTAwMSAwMDAwMCBuDQowMDAwMTExMTc0IDAwMDAwIG4NCjAwMDAxMTEy NTIgMDAwMDAgbg0KMDAwMDExMTI3MyAwMDAwMCBuDQowMDAwMTEyMTU5IDAw MDAwIG4NCjAwMDAxMTIxODAgMDAwMDAgbg0KMDAwMDExMzAzNyAwMDAwMCBu DQowMDAwMTEzMDU4IDAwMDAwIG4NCjAwMDAxMTQwNDkgMDAwMDAgbg0KMDAw MDExNDA3MCAwMDAwMCBuDQowMDAwMTE0OTA0IDAwMDAwIG4NCjAwMDAxMTQ5 MjUgMDAwMDAgbg0KMDAwMDExNTkxNSAwMDAwMCBuDQowMDAwMTE1OTM2IDAw MDAwIG4NCjAwMDAxMTY4OTMgMDAwMDAgbg0KMDAwMDExNjkxNSAwMDAwMCBu DQowMDAwMTE4MjAxIDAwMDAwIG4NCjAwMDAxMTgyMjIgMDAwMDAgbg0KMDAw MDExODc2NCAwMDAwMCBuDQowMDAwMTE4ODQyIDAwMDAwIG4NCjAwMDAxMTkw MTUgMDAwMDAgbg0KMDAwMDExOTIzOCAwMDAwMCBuDQowMDAwMTE5MzI1IDAw MDAwIG4NCjAwMDAxMTkzNDcgMDAwMDAgbg0KMDAwMDEyMDMwNCAwMDAwMCBu DQowMDAwMTIwMzI2IDAwMDAwIG4NCjAwMDAxMjExMjUgMDAwMDAgbg0KMDAw MDEyMTE0NyAwMDAwMCBuDQowMDAwMTIyMDIwIDAwMDAwIG4NCjAwMDAxMjIw NDIgMDAwMDAgbg0KMDAwMDEyMjgyNyAwMDAwMCBuDQowMDAwMTIyODQ5IDAw MDAwIG4NCjAwMDAxMjM2MzIgMDAwMDAgbg0KMDAwMDEyMzY1NCAwMDAwMCBu DQowMDAwMTI0Njk2IDAwMDAwIG4NCjAwMDAxMjQ3MTggMDAwMDAgbg0KMDAw MDEyNTQ1OSAwMDAwMCBuDQowMDAwMTI1NDgxIDAwMDAwIG4NCjAwMDAxMjYy NDUgMDAwMDAgbg0KMDAwMDEyNjMyNCAwMDAwMCBuDQowMDAwMTI2NTAwIDAw MDAwIG4NCjAwMDAxMjY2OTEgMDAwMDAgbg0KMDAwMDEyNjc3OCAwMDAwMCBu DQowMDAwMTI2ODAwIDAwMDAwIG4NCjAwMDAxMjc4MTYgMDAwMDAgbg0KMDAw MDEyNzgzOCAwMDAwMCBuDQowMDAwMTI4NjU5IDAwMDAwIG4NCjAwMDAxMjg2 ODEgMDAwMDAgbg0KMDAwMDEyOTI2NiAwMDAwMCBuDQowMDAwMTI5Mjg4IDAw MDAwIG4NCjAwMDAxMjk4NzMgMDAwMDAgbg0KMDAwMDEyOTg5NSAwMDAwMCBu DQowMDAwMTMwNzMxIDAwMDAwIG4NCjAwMDAxMzA3NTMgMDAwMDAgbg0KMDAw MDEzMTMyNCAwMDAwMCBuDQowMDAwMTMxMzQ2IDAwMDAwIG4NCjAwMDAxMzIz NzUgMDAwMDAgbg0KMDAwMDEzMjM5NyAwMDAwMCBuDQowMDAwMTMzMDM2IDAw MDAwIG4NCjAwMDAxMzMxMTUgMDAwMDAgbg0KMDAwMDEzMzE4NyAwMDAwMCBu DQowMDAwMTM0MDYxIDAwMDAwIG4NCjAwMDAxMzQ5MzEgMDAwMDAgbg0KMDAw MDEzNTczNSAwMDAwMCBuDQowMDAwMTM1OTM0IDAwMDAwIG4NCjAwMDAxMzYx MjAgMDAwMDAgbg0KMDAwMDEzNjMyNiAwMDAwMCBuDQowMDAwMTM2NTU4IDAw MDAwIG4NCjAwMDAxMzY4NzYgMDAwMDAgbg0KMDAwMDAwMDIzOSAwMDAwMSBm DQowMDAwMTM3MDg5IDAwMDAwIG4NCjAwMDAxMzc1MDAgMDAwMDAgbg0KMDAw MDE0MDYzNSAwMDAwMCBuDQowMDAwMTQwODYzIDAwMDAwIG4NCjAwMDAxNDEz MTEgMDAwMDAgbg0KMDAwMDE0MTU0NSAwMDAwMCBuDQowMDAwMTQxOTA5IDAw MDAwIG4NCjAwMDAxNDE5ODAgMDAwMDAgbg0KMDAwMDE0MjA1MiAwMDAwMCBu DQowMDAwMTQyMzQ2IDAwMDAwIG4NCjAwMDAxNDI0MTkgMDAwMDAgbg0KMDAw MDE0MjcyMiAwMDAwMCBuDQowMDAwMTQyNzc4IDAwMDAwIG4NCjAwMDAxNDM3 MDUgMDAwMDAgbg0KMDAwMDE0Mzg4NiAwMDAwMCBuDQowMDAwMTQ0Njg5IDAw MDAwIG4NCjAwMDAxNDUwNzcgMDAwMDAgbg0KMDAwMDE0ODM2MCAwMDAwMCBu DQowMDAwMTQ5MTYyIDAwMDAwIG4NCjAwMDAxNDk1NzEgMDAwMDAgbg0KMDAw MDE1MzE5OSAwMDAwMCBuDQowMDAwMTUzMzgwIDAwMDAwIG4NCjAwMDAxNTM2 NjMgMDAwMDAgbg0KMDAwMDE1MzkyMCAwMDAwMCBuDQowMDAwMTU0MTA4IDAw MDAwIG4NCjAwMDAxNTQyOTEgMDAwMDAgbg0KMDAwMDE1NDUyOSAwMDAwMCBu DQowMDAwMTU0NjkwIDAwMDAwIG4NCjAwMDAxNTQ5MzkgMDAwMDAgbg0KMDAw MDE1NTE3MyAwMDAwMCBuDQowMDAwMTU1MzQ1IDAwMDAwIG4NCjAwMDAxNTU1 NTggMDAwMDAgbg0KMDAwMDE1NTcxNCAwMDAwMCBuDQowMDAwMTU1OTIxIDAw MDAwIG4NCjAwMDAxNTYwOTAgMDAwMDAgbg0KMDAwMDE1NjI1MSAwMDAwMCBu DQowMDAwMTU2NDA2IDAwMDAwIG4NCjAwMDAxNTY1NjcgMDAwMDAgbg0KMDAw MDE1Njc5NSAwMDAwMCBuDQowMDAwMTU2OTc5IDAwMDAwIG4NCjAwMDAxNTcy MTAgMDAwMDAgbg0KMDAwMDE1NzQyMCAwMDAwMCBuDQowMDAwMTU3NTU1IDAw MDAwIG4NCjAwMDAxNTc2MDcgMDAwMDAgbg0KMDAwMDE1Nzg0MyAwMDAwMCBu DQowMDAwMTU3ODgzIDAwMDAwIG4NCjAwMDAxNTgwNTMgMDAwMDAgbg0KMDAw MDE1ODEyMSAwMDAwMCBuDQowMDAwMTU4MTczIDAwMDAwIG4NCjAwMDAxNTg0 MDMgMDAwMDAgbg0KMDAwMDE1ODQ1MSAwMDAwMCBuDQowMDAwMTU4NjM4IDAw MDAwIG4NCjAwMDAxNTg3MTQgMDAwMDAgbg0KMDAwMDE1ODc2NiAwMDAwMCBu DQowMDAwMTU5MDAwIDAwMDAwIG4NCjAwMDAxNTkwNDggMDAwMDAgbg0KMDAw MDE1OTI0OSAwMDAwMCBuDQowMDAwMTU5MzI1IDAwMDAwIG4NCjAwMDAxNTkz NzcgMDAwMDAgbg0KMDAwMDE2MDE3MSAwMDAwMCBuDQowMDAwMTYwNjU2IDAw MDAwIG4NCjAwMDAxNjQ3MzQgMDAwMDAgbg0KMDAwMDE2NTQzMiAwMDAwMCBu DQowMDAwMTY1OTMwIDAwMDAwIG4NCjAwMDAxNzAxNzUgMDAwMDAgbg0KMDAw MDE3MDg3OCAwMDAwMCBuDQowMDAwMTcxNjY5IDAwMDAwIG4NCjAwMDAxNzE5 MTQgMDAwMDAgbg0KMDAwMDE3MjM2NyAwMDAwMCBuDQowMDAwMTcyNTQ4IDAw MDAwIG4NCjAwMDAxNzI5NDggMDAwMDAgbg0KMDAwMDE3MzE0MyAwMDAwMCBu DQowMDAwMTczMzAxIDAwMDAwIG4NCjAwMDAxNzM1MDcgMDAwMDAgbg0KMDAw MDE3NjY1NyAwMDAwMCBuDQowMDAwMTc3MTY2IDAwMDAwIG4NCjAwMDAxNzcz NDYgMDAwMDAgbg0KMDAwMDE3Nzg4NiAwMDAwMCBuDQowMDAwMTc4MDczIDAw MDAwIG4NCjAwMDAxNzgyNTYgMDAwMDAgbg0KMDAwMDE3ODQ0NCAwMDAwMCBu DQowMDAwMTc4NDk2IDAwMDAwIG4NCjAwMDAxODE0MTUgMDAwMDAgbg0KMDAw MDE4MTQzOCAwMDAwMCBuDQowMDAwMTgxNDY3IDAwMDAwIG4NCjAwMDAxODE2 MTQgMDAwMDAgbg0KMDAwMDE4MTY5OSAwMDAwMCBuDQowMDAwMTgxODQ4IDAw MDAwIG4NCjAwMDAxODE5ODkgMDAwMDAgbg0KMDAwMDAwMDI0MCAwMDAwMSBm DQowMDAwMDAwMjc2IDAwMDAxIGYNCjAwMDAxODIxMzIgMDAwMDAgbg0KMDAw MDE4MjIyNyAwMDAwMCBuDQowMDAwMTgyNDc0IDAwMDAwIG4NCjAwMDAxODI3 MjYgMDAwMDAgbg0KMDAwMDE4MjkwNyAwMDAwMCBuDQowMDAwMTgzNjE1IDAw MDAwIG4NCjAwMDAxODQxODQgMDAwMDAgbg0KMDAwMDE4NTA0NCAwMDAwMCBu DQowMDAwMTg1OTE3IDAwMDAwIG4NCjAwMDAxODU5NzcgMDAwMDAgbg0KMDAw MDE4NjAwMCAwMDAwMCBuDQowMDAwMTg4MDE1IDAwMDAwIG4NCjAwMDAxODgw MzggMDAwMDAgbg0KMDAwMDE4OTY1NyAwMDAwMCBuDQowMDAwMTg5NjgwIDAw MDAwIG4NCjAwMDAxOTE1MjYgMDAwMDAgbg0KMDAwMDE5MTU0OSAwMDAwMCBu DQowMDAwMTkzMTMyIDAwMDAwIG4NCjAwMDAxOTMxNTUgMDAwMDAgbg0KMDAw MDE5NDc3NyAwMDAwMCBuDQowMDAwMTk0ODAwIDAwMDAwIG4NCjAwMDAxOTY0 MzUgMDAwMDAgbg0KMDAwMDE5NjQ5MSAwMDAwMCBuDQowMDAwMTk2NTk0IDAw MDAwIG4NCjAwMDAxOTY2MTcgMDAwMDAgbg0KMDAwMDE5ODIzMiAwMDAwMCBu DQowMDAwMTk4MjU1IDAwMDAwIG4NCjAwMDAxOTk3NDkgMDAwMDAgbg0KMDAw MDE5OTgyOCAwMDAwMCBuDQowMDAwMTk5OTA2IDAwMDAwIG4NCjAwMDAyMDQ5 NDQgMDAwMDAgbg0KMDAwMDIxMDUzMCAwMDAwMCBuDQowMDAwMjExMzQ4IDAw MDAwIG4NCjAwMDAyMTIyNzUgMDAwMDAgbg0KMDAwMDIyNTE1MSAwMDAwMCBu DQowMDAwMDAwMjc3IDAwMDAxIGYNCjAwMDAwMDAyODAgMDAwMDEgZg0KMDAw MDIyNjc1NyAwMDAwMCBuDQowMDAwMjI2OTY0IDAwMDAwIG4NCjAwMDAwMDAy ODEgMDAwMDEgZg0KMDAwMDAwMDI4MiAwMDAwMSBmDQowMDAwMDAwMjgzIDAw MDAxIGYNCjAwMDAwMDAyODQgMDAwMDEgZg0KMDAwMDAwMDI4NSAwMDAwMSBm DQowMDAwMDAwMjg2IDAwMDAxIGYNCjAwMDAwMDAyODcgMDAwMDEgZg0KMDAw MDAwMDI4OCAwMDAwMSBmDQowMDAwMDAwMjg5IDAwMDAxIGYNCjAwMDAwMDAy OTAgMDAwMDEgZg0KMDAwMDAwMDI5MSAwMDAwMSBmDQowMDAwMDAwMDAwIDAw MDAxIGYNCjAwMDAyMjY5OTQgMDAwMDAgbg0KMDAwMDIyOTc4NCAwMDAwMCBu DQowMDAwMjI5ODA3IDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgMjk1DS9J bmZvIDIzOCAwIFIgDS9Sb290IDI0MSAwIFIgDS9JRFs8ZTVjNGY0NjQ1YmYx OTQ0MmU5OTcyZGNkOWFkYjkyODQ+PGE0Yzk0OWFiOGE1ZWU0NjdkNTUyZDIz MDZjNWJhNzg5Pl0NPj4Nc3RhcnR4cmVmDTIzMDcyMA0lJUVPRg0= --= Multipart Boundary 0725031758-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Jul 26 22:37:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24137 for ; Sat, 26 Jul 2003 22:37:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gbPD-0000Xd-TY for nsis-archive@odin.ietf.org; Sat, 26 Jul 2003 22:37:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6R2b3I8002070 for nsis-archive@odin.ietf.org; Sat, 26 Jul 2003 22:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gbPB-0000WG-IW; Sat, 26 Jul 2003 22:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gbOS-0000Vf-Sz for nsis@optimus.ietf.org; Sat, 26 Jul 2003 22:36:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24130 for ; Sat, 26 Jul 2003 22:36:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gbOP-0007SG-00 for nsis@ietf.org; Sat, 26 Jul 2003 22:36:13 -0400 Received: from web41215.mail.yahoo.com ([66.218.93.48]) by ietf-mx with smtp (Exim 4.12) id 19gbOP-0007Ry-00 for nsis@ietf.org; Sat, 26 Jul 2003 22:36:13 -0400 Message-ID: <20030727023543.14343.qmail@web41215.mail.yahoo.com> Received: from [67.161.8.79] by web41215.mail.yahoo.com via HTTP; Sat, 26 Jul 2003 19:35:43 PDT Date: Sat, 26 Jul 2003 19:35:43 -0700 (PDT) From: Vishal Zinjuvadia To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [NSIS] Security concern during LSP establishment Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hello All: Following is a problem that may come up during exchange of label request and label mapping messages between two LERs using any signaling protocols. Label Edge Routers Alice and Bob: +-------+ +-------+ | |M(LR)-> | | |Alice |----------------------|Bob | | | <-Enc(M(LM))| | +-------+ ^ +-------+ | | | Trudy (intruder) Security Association is assumed to exist between Alice and Bob Let M(A) be a message A. and Enc(M(A)) be the encrypted message A. 1) label request sent from Alice to Bob: M(LR) 2) Encrypted label mapping sent from Bob to Alice: Enc(M(LM)) The way most signaling protocol are designed, following holds true: 1) Labels are assigned sequentially 2) The first label assigned after a LSR comes up is generally a constant value. Based on the above assumptions, any intruder Trudy can get enough plain-text cipher text combinations if he sniffs on the link for a long enough time. Posed risks are: 1) Label mapping may be discovered which could allow any intruder to steal resources from Bob (and probably many other LSRs on the LSP that Bob is a part of) 2) Trudy can play with plain-text, cipher-text pairs and probably break the security association that is in place between Alice and Bob. Has this problem been addressed so far? Can we use a non-deterministic crypto-system where if the same key is used to encrypt a given plain-text twice, the two resulting cipher-texts differ in a random fashion? (for e.g. the RPK algorithm proposed by Romeo, Romolotti, Mattaveli and Mlynek from Swiss Federal Institute of Technology). Such a solution seems to be addressing both the above risks. Comments are much appreciated. Thanks, Vishal __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 28 05:53:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25728 for ; Mon, 28 Jul 2003 05:53:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h4gj-0007o4-3I for nsis-archive@odin.ietf.org; Mon, 28 Jul 2003 05:53:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6S9r5cY030004 for nsis-archive@odin.ietf.org; Mon, 28 Jul 2003 05:53:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h4gf-0007nO-9S; Mon, 28 Jul 2003 05:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h4gV-0007mp-IV for nsis@optimus.ietf.org; Mon, 28 Jul 2003 05:52:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25690 for ; Mon, 28 Jul 2003 05:52:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h4gR-0000Ia-00 for nsis@ietf.org; Mon, 28 Jul 2003 05:52:47 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19h4gQ-0000IW-00 for nsis@ietf.org; Mon, 28 Jul 2003 05:52:47 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h6S9qlR25717; Mon, 28 Jul 2003 11:52:47 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6S9qkZ15919; Mon, 28 Jul 2003 11:52:46 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 11:52:46 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFFD4@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Vishal Zinjuvadia'" , nsis@ietf.org Subject: RE: [NSIS] Security concern during LSP establishment Date: Mon, 28 Jul 2003 11:52:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi vishal, thanks for raising your security issue. i have some basic questions to better understand the problem: are all signaling messages exchanged between alice and bob protected (data origin authentication, integrity and replay protection)? if yes, how is the security association established? how is it possible that an adversary can benefit from the discovered label mapping? what steps are necessary after discovering the label mapping to mount an attack? ciao hannes > -----Original Message----- > From: Vishal Zinjuvadia [mailto:vzinjuvadia@yahoo.com] > Sent: Sunday, July 27, 2003 4:36 AM > To: nsis@ietf.org > Subject: [NSIS] Security concern during LSP establishment > > > Hello All: > > Following is a problem that may come up during > exchange of label request and label mapping messages > between two LERs using any signaling protocols. > > Label Edge Routers Alice and Bob: > > +-------+ +-------+ > | |M(LR)-> | | > |Alice |----------------------|Bob | > | | <-Enc(M(LM))| | > +-------+ ^ +-------+ > | > | > | > Trudy (intruder) > > Security Association is assumed to exist between Alice > and Bob > > Let M(A) be a message A. > and Enc(M(A)) be the encrypted message A. > > 1) label request sent from Alice to Bob: M(LR) > 2) Encrypted label mapping sent from Bob to Alice: > Enc(M(LM)) > > The way most signaling protocol are designed, > following holds true: > > 1) Labels are assigned sequentially > 2) The first label assigned after a LSR comes up is > generally a constant value. > > Based on the above assumptions, any intruder Trudy can > get enough plain-text cipher text combinations if he > sniffs on the link for a long enough time. Posed risks > are: > > 1) Label mapping may be discovered which could allow > any intruder to steal resources from Bob (and probably > many other LSRs on the LSP that Bob is a part of) > > 2) Trudy can play with plain-text, cipher-text pairs > and probably break the security association that is in > place between Alice and Bob. > > Has this problem been addressed so far? Can we use a > non-deterministic crypto-system where if the same key > is used to encrypt a given plain-text twice, the two > resulting cipher-texts differ in a random fashion? > (for e.g. the RPK algorithm proposed by Romeo, > Romolotti, Mattaveli and Mlynek from Swiss Federal > Institute of Technology). Such a solution seems to be > addressing both the above risks. > > Comments are much appreciated. > > Thanks, > Vishal > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 28 11:28:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07096 for ; Mon, 28 Jul 2003 11:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9us-0002Jm-Uk for nsis-archive@odin.ietf.org; Mon, 28 Jul 2003 11:28:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SFS22g008909 for nsis-archive@odin.ietf.org; Mon, 28 Jul 2003 11:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9ur-0002JV-Ao; Mon, 28 Jul 2003 11:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9uJ-0002EW-Jp for nsis@optimus.ietf.org; Mon, 28 Jul 2003 11:27:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07016 for ; Mon, 28 Jul 2003 11:27:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9uH-00042F-00 for nsis@ietf.org; Mon, 28 Jul 2003 11:27:25 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19h9uG-00041X-00 for nsis@ietf.org; Mon, 28 Jul 2003 11:27:24 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 16:26:53 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Date: Mon, 28 Jul 2003 16:26:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] general comment on tunnel handling (was: RE: mobility-related req uirements...) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear all, I thought I'd make a general comment on assumptions about tunnel handling in NSIS. Although these assumptions have been mentioned randomly from time to time, they aren't [yet] documented anywhere, and probably should be made explicit. The basic assumption is that if some node in the network is encapsulating IP packets (for some flow) and sending them to a remote tunnel endpoint inside a tunnel, then the 'default' state of affairs is that any signalling traffic for that flow is encapsulated and tunnelled to the same endpoint. If you want to signal about the tunnel, that means that the tunnel origin (ideally, both endpoints) have to be NSIS-aware and that they generate logically separate signalling for the tunnel (i.e. the tunnel is a new flow). I've been not worrying about this assumption very much because it seems to be 'natural' given the way the rest of the framework is described, and also conceptually the same as RSVP tunnel handling (RFC2746). Obviously there are details about which layer of NSIS should carry information binding inner flows to outer tunnels, if that information needs to be carried, which I think can be left open for now. If there are objections to this view, please say so (and why). cheers, robert h. > -----Original Message----- > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: Friday, July 25, 2003 11:19 > To: Charles Q. Shen > Cc: nsis@ietf.org; Hancock, Robert; Paulo Mendes > Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 > > > Charles, > > > > > Again I am a bit confused about the notion of universe > flow-id and the > > (supposed to be unique) session ID here. > I think Robert's concept on *universe* flow-id doesn't need to be > unchanged during a session; if I understand correctly, he only meant > "universe" for signaling session at one time. > > > Also are you talking about tunneling? > > So far in this thread, not yet. However, in my view, IP-in-IP > tunneling > is an important issue for NSIS-mobility to work out. Re-routing and > local repair issues in the data path changed by mobile IP may > introduce > problems other than (routing header + destination option in case of > MIPv6) - imagine what if a message is encapulated into tunneled :-); > reverse tunneling could be more complicated. My ideal model > is that NTLP > should be aware of any tunnel entry and exits, and route NSIS message > when entering and inside a tunnel differently from the case > outside the > tunnel. > > Cheers, > Xiaoming > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 28 11:29:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07208 for ; Mon, 28 Jul 2003 11:29:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9vp-0002Qf-7E for nsis-archive@odin.ietf.org; Mon, 28 Jul 2003 11:29:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SFT1D7009288 for nsis-archive@odin.ietf.org; Mon, 28 Jul 2003 11:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9vp-0002PI-2D; Mon, 28 Jul 2003 11:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9uy-0002KV-IV for nsis@optimus.ietf.org; Mon, 28 Jul 2003 11:28:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07065 for ; Mon, 28 Jul 2003 11:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9ut-00042s-00 for nsis@ietf.org; Mon, 28 Jul 2003 11:28:03 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19h9us-00042L-00 for nsis@ietf.org; Mon, 28 Jul 2003 11:28:02 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 16:27:31 +0100 Message-ID: From: "Hancock, Robert" To: "'Xiaoming Fu'" Cc: "'Charles Q. Shen'" , "'Paulo Mendes'" , nsis@ietf.org Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Date: Mon, 28 Jul 2003 16:27:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi xiaoming, more clarifications (I hope): > I followed up your previous mail regarding universe flow id > because this > is also (for both you and I) meant how to route the NSIS messages. > Actually, in a previous version of fw draft it stated either way of > using flow-id: > *) Use a flow identification based on low level IP > addresses (e.g. > the Care of Address) and other 'standard' fields in the IP header. > This makes least demands on the packet classification > engines within > the network. However, it means that even on a part of the > flow path > which is unchanged, the reservation will need to be modified to > reflect the changed flow identification (see section 5.3.3). > > *) Use a flow identification that does not change (e.g. based on > Home Address); this is the approach assumed in [23]. This > simplifies > the problem of reservation update, at the likely cost of > considerably > complicating the flow identification requirements. [reh] and what we are assuming is the first approach and not the second. > > This can also answer some discussions. My worry, however, is that > flow-id might be insufficient to address the NSIS messages in > mobility > scenarios, not talking about the mobility-coupled issue; I > was trying to > discuss in the context of decoupling NSIS signaling from MIP > signaling. > > Hancock, Robert wrote: > > *) I'm not really sure what Xiaoming is suggesting in terms > of routing > > NSLP messages *other* than on flow-id. The flow-id is essentially > > defined as 'the thing which characterises the data path', so routing > > on anything else is morally equivalent to off-path signalling. > > At least I can tell, if we use some on-path LMM schemes (e.g., fast > handover, HMIP), this flow-id could be insufficient to route NSIS > messages. In such cases, data path in the new segment(s) may not be > fully characterized by the flow-id (3/5 tuple?). [reh] the fundamental question is: how are the data packets themselves being routed? whatever is making them follow the route they follow should be invoked to make the signalling packets follow the same route. (*how* to make that invocation is another issue; one approach is to make the signalling packets look like data packets, another is to make the nodes which do some forwarding which is not-purely-IP-DA NSIS-aware and have them route signalling packets at the NTLP level on the flow-id directly. see numerous other emails on that subject.) [if the data packets are being routed on something other than 3/5 tuple and possibly routing header, I suspect we are in deep trouble.] r. > > Cheers, > Xiaoming > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jul 28 17:17:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21216 for ; Mon, 28 Jul 2003 17:17:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hFMh-00057a-CB for nsis-archive@odin.ietf.org; Mon, 28 Jul 2003 17:17:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SLH7n1019682 for nsis-archive@odin.ietf.org; Mon, 28 Jul 2003 17:17:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hFMb-00053O-4R; Mon, 28 Jul 2003 17:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hFME-00052o-LN for nsis@optimus.ietf.org; Mon, 28 Jul 2003 17:16:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21213 for ; Mon, 28 Jul 2003 17:16:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hFMC-0000Dd-00 for nsis@ietf.org; Mon, 28 Jul 2003 17:16:36 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 19hFMB-0000DZ-00 for nsis@ietf.org; Mon, 28 Jul 2003 17:16:35 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h6SLGYZ24472 for ; Mon, 28 Jul 2003 23:16:35 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6SLGYR20500 for ; Mon, 28 Jul 2003 23:16:34 +0200 (MEST) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id XAA29954 for ; Mon, 28 Jul 2003 23:16:34 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 23:15:58 +0200 Message-ID: <4D486782CA36D4118A530000D11EA42A021AC310@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: nsis@ietf.org Date: Mon, 28 Jul 2003 23:15:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [NSIS] ntlp drafts differences Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear all, I tried analysing Hennings and Melindas NTLP drafts in order to find the fundamental differences. No doubt others have also done this; I would like to compare notes. - what transport protocol to use, if any. the most hotly debated difference. I don't dare going into details ;-) - Whether a NE know its next hop peer. In Melindas NTLP, the NE just knows its previous peer. The next NE peer is discovered by a PATH-like message and subsequently addressed implicitly. In Hennings NTPL, the NE may request to be informed of the next NE peer's address. To my knowledge, knowing the address of the next NE peer is necessary for channel security which we require to at least be possible (Requirements ID 5.7.5). So to me this looks like a necessary feature. And that's it...!? There was one more difference, because in Melindas draft, each PATH-like message must be replied to by a RESERVE-like message (Sec. 3.1). However at the nsis meeting, Melinda agreed there is no reason for the RESERVE message to be issued, so it could be dropped. There are a couple of what I believe are minor (i.e. not fundamental) differences, or may be rather the level of detail provided differs between the two drafts. I think they can be sorted out without too much problem - such as: - do we need a Logical Interface Handle? - Message bundling and Summary Refresh is only detailed in Melindas draft - According to Henning it is possible to not leave any state behind (set-up and tear-down in same message). However no details are given. - etc. I would be interested to know if others (incl the authors) arrived at the same conclusion, resp what I overlooked. Best regards, Cornelia. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 00:03:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29297 for ; Tue, 29 Jul 2003 00:03:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hLha-000152-BR for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 00:03:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T436GP004135 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 00:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hLhV-00014D-Sk; Tue, 29 Jul 2003 00:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hLhA-00013t-H0 for nsis@optimus.ietf.org; Tue, 29 Jul 2003 00:02:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29288 for ; Tue, 29 Jul 2003 00:02:35 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hLh8-0002Oe-00 for nsis@ietf.org; Tue, 29 Jul 2003 00:02:38 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19hLh7-0002Ob-00 for nsis@ietf.org; Tue, 29 Jul 2003 00:02:37 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6T42aJ02853 for ; Tue, 29 Jul 2003 07:02:37 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 29 Jul 2003 07:02:36 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Jul 2003 07:02:35 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Jul 2003 07:02:34 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Jul 2003 07:02:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Jul 2003 07:02:32 +0300 Message-ID: Thread-Topic: NTLP Editorial team Thread-Index: AcNVhjyEfBvuKzhnR4qSvt6f4jaNaw== To: X-OriginalArrivalTime: 29 Jul 2003 04:02:34.0325 (UTC) FILETIME=[3D8EC050:01C35586] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] NTLP Editorial team Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Melinda indicated that she is unable to continue working on the NTLP = document with Henning, so I have asked Robert Hancock to work together with = Henning on producing a version -00 of the NTLP document. I would like the = working group to review that document when it is published. Once published, focusing on big picture issues initially would be first steps for the WG to review. I hope that Henning & Robert can produce a good document within a = reasonable time frame so we can work towards fufilling our charter items. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 02:01:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02730 for ; Tue, 29 Jul 2003 02:01:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNXk-0004OC-1K for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 02:01:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T614i3016873 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 02:01:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNXi-0004Nz-2y; Tue, 29 Jul 2003 02:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNXf-0004Mm-BN for nsis@optimus.ietf.org; Tue, 29 Jul 2003 02:00:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02088 for ; Tue, 29 Jul 2003 02:00:54 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hNXb-0002rk-00 for nsis@ietf.org; Tue, 29 Jul 2003 02:00:55 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19hNXa-0002rh-00 for nsis@ietf.org; Tue, 29 Jul 2003 02:00:55 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6T60rJ22146 for ; Tue, 29 Jul 2003 09:00:54 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 29 Jul 2003 09:00:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Jul 2003 09:00:52 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Jul 2003 09:00:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Jul 2003 09:00:51 +0300 Message-ID: Thread-Topic: [NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt - Comments 1 Thread-Index: AcNStT0d/ktDKT5+RZGWxg38SDV+9wC4T0qQ To: X-OriginalArrivalTime: 29 Jul 2003 06:00:52.0864 (UTC) FILETIME=[C49DD800:01C35596] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] IETF 57 short summary Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Here is a short summary of the NSIS meeting, with a longer version to = follow. Please review this. If anyone feels that the consensus reached in the = meeting is in error, or disagrees with the consensus, please comment. thanks, John NSIS met for 2 sessions at IETF 57, the highlights of the meeting are as = follows: There was discussion of 2 I-Ds for NSIS Transport Protocol: http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-ntlp-00.txt http://www.ietf.org/internet-drafts/draft-shore-ntlp-00.txt Some techinical details were discussed. The summary of the discussion = was that there is sufficient commonality between the two proposals, should merge = draft. Areas=20 of disagreement to be left as open issues with discussion on mailing = list. Will organize=20 open design team conference calls as needed. Hannes Tschofenig discussed 4 drafts on ecurity, Threats & Authorization = issues. http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-02.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-0= 2.txt http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issue= s-00.txt http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-sid-00.txt The NSIS threats document was in WG last call, Hannes will reissue the = draft and the WG chair will review the draft to see if it is ready for AD = review. RSVP Security Properties draft is nearly ready for WGLC. The other drafts = raised issues which should be discussed during protocol design phase. Robert Hancock discussed the Next Steps in Signaling Framework. =20 http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-03.txt The WG felt that the draft is in good shape, and WGLC should start once = the draft is reissued. Xiaoming Fu discussed an individual draft, Mobility Support in NSIS=20 http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.txt Consensus was that work will continue on this, on an individual basis Jukka Manner discussed Analysis of Existing Signaling Protocols =20 http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-0= 2.txt There are a few open issues with the draft, Jukka will contact Michael = Thomas to see about including comments from his draft on mobility, and re-issue = the draft. Robert Hancock presented a proposal for NSIS QoS Application Protocol. = This discussion was a combined discussion of 3 proposals. The WG agreed that moving forward on this item is important, and the authors of the = proposals will work together to produce a -00 version as a WG document. Sven van = den Bosch will prepare a timetable (roadmap, review teams, open issue list,=20 needs for telephone conferences, etc.) for the work. Marcus Brunner discussed a proposal for a NSIS Middle Box Signaling = Application=20 Protocol http://www.ietf.org/internet-drafts/draft-brunner-nsis-midcom-ps-00.txt The working group felt that this was a good document, and should be a WG item. Marcus will work on preparing a timetable (roadmap, review teams, = open issue list, needs for telephone conferences, etc.) for the work. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 02:35:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13901 for ; Tue, 29 Jul 2003 02:35:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hO4e-0006s1-La for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 02:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T6Z41s026409 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 02:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hO4d-0006rT-Cp; Tue, 29 Jul 2003 02:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hO44-0006r3-2T for nsis@optimus.ietf.org; Tue, 29 Jul 2003 02:34:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13871 for ; Tue, 29 Jul 2003 02:34:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hO40-000334-00 for nsis@ietf.org; Tue, 29 Jul 2003 02:34:24 -0400 Received: from web41209.mail.yahoo.com ([66.218.93.42]) by ietf-mx with smtp (Exim 4.12) id 19hO3z-00032u-00 for nsis@ietf.org; Tue, 29 Jul 2003 02:34:23 -0400 Message-ID: <20030729063353.16125.qmail@web41209.mail.yahoo.com> Received: from [67.161.8.79] by web41209.mail.yahoo.com via HTTP; Mon, 28 Jul 2003 23:33:53 PDT Date: Mon, 28 Jul 2003 23:33:53 -0700 (PDT) From: Vishal Zinjuvadia Subject: RE: [NSIS] Security concern during LSP establishment To: nsis@ietf.org In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFFD4@mchp905a.mch.sbs.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hello Hannes: Thanks for your reply. I am hoping that the following points will help me in making the problem clear. The messages between Alice and Bob are expected to have some degree of security associated with them. Ideally they are expected to be talking over an encrypted control channel. But at the very least, sensitive information carried in the messages must be encrypted. Data origin authentication & message integrity are provided (using digitally signed hash of the message appended to the message itself) and so is replay protection (using sequence number or challenge nonce). Security association can be established administratively (offline) or using some other protocol. As a result, Alice and Bob share a secret key that is known only to those two entities. Let us assume that Trudy (intruder) is able to determine the label-mapping (label as well as the IP address of the node that Alice is trying to communicate with - for e.g. Fred) using methods described in my previous email. Then Trudy can get his traffic switched across Bob's domain without having to pay for it. If some sort of Service-Level Agreement for a fixed amount of bandwidth exists between Alice and Bob, traffic from Alice may occassionally be denied entry into Bob's domain. Moreover, Bob may be billing Alice based on the number of packets received with a particular label. Trudy can launch denial of service attacks on Bob (and also on Fred with whom the Alice is trying to communicate via Bob's domain) since he knows that incoming packets with valid label will not be dropped an will be switched & routed all the way. The impact can be much worse on Fred if the traffic injected by Trudy is actually control traffic for Fred. Your comments are much appreciated. Thanks, Vishal --- Tschofenig Hannes wrote: > hi vishal, > > thanks for raising your security issue. i have some > basic questions to > better understand the problem: > > are all signaling messages exchanged between alice > and bob protected (data > origin authentication, integrity and replay > protection)? > > if yes, how is the security association established? > > > how is it possible that an adversary can benefit > from the discovered label > mapping? > what steps are necessary after discovering the label > mapping to mount an > attack? > > ciao > hannes > > > -----Original Message----- > > From: Vishal Zinjuvadia > [mailto:vzinjuvadia@yahoo.com] > > Sent: Sunday, July 27, 2003 4:36 AM > > To: nsis@ietf.org > > Subject: [NSIS] Security concern during LSP > establishment > > > > > > Hello All: > > > > Following is a problem that may come up during > > exchange of label request and label mapping > messages > > between two LERs using any signaling protocols. > > > > Label Edge Routers Alice and Bob: > > > > +-------+ +-------+ > > | |M(LR)-> | | > > |Alice |----------------------|Bob | > > | | <-Enc(M(LM))| | > > +-------+ ^ +-------+ > > | > > | > > | > > Trudy (intruder) > > > > Security Association is assumed to exist between > Alice > > and Bob > > > > Let M(A) be a message A. > > and Enc(M(A)) be the encrypted message A. > > > > 1) label request sent from Alice to Bob: M(LR) > > 2) Encrypted label mapping sent from Bob to Alice: > > Enc(M(LM)) > > > > The way most signaling protocol are designed, > > following holds true: > > > > 1) Labels are assigned sequentially > > 2) The first label assigned after a LSR comes up > is > > generally a constant value. > > > > Based on the above assumptions, any intruder Trudy > can > > get enough plain-text cipher text combinations if > he > > sniffs on the link for a long enough time. Posed > risks > > are: > > > > 1) Label mapping may be discovered which could > allow > > any intruder to steal resources from Bob (and > probably > > many other LSRs on the LSP that Bob is a part of) > > > > 2) Trudy can play with plain-text, cipher-text > pairs > > and probably break the security association that > is in > > place between Alice and Bob. > > > > Has this problem been addressed so far? Can we use > a > > non-deterministic crypto-system where if the same > key > > is used to encrypt a given plain-text twice, the > two > > resulting cipher-texts differ in a random fashion? > > (for e.g. the RPK algorithm proposed by Romeo, > > Romolotti, Mattaveli and Mlynek from Swiss Federal > > Institute of Technology). Such a solution seems to > be > > addressing both the above risks. > > > > Comments are much appreciated. > > > > Thanks, > > Vishal > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > > http://sitebuilder.yahoo.com > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 05:07:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16290 for ; Tue, 29 Jul 2003 05:07:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQRj-0003Fs-Ri for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 05:07:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T973Jw012494 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 05:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQRh-0003EK-Us; Tue, 29 Jul 2003 05:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQRO-0003Dp-DC for nsis@optimus.ietf.org; Tue, 29 Jul 2003 05:06:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16277 for ; Tue, 29 Jul 2003 05:06:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hQRL-0003fn-00 for nsis@ietf.org; Tue, 29 Jul 2003 05:06:39 -0400 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 19hQRK-0003fk-00 for nsis@ietf.org; Tue, 29 Jul 2003 05:06:38 -0400 Received: from luu (dhcp7-211.enst.fr [137.194.7.211]) by infres.enst.fr (Postfix) with SMTP id 6E48618A8; Tue, 29 Jul 2003 11:06:37 +0200 (MEST) Message-ID: <006001c355b0$4ff3f920$d307c289@enst.fr> From: "Thanh Tra LUU" To: "Kappler Cornelia" Cc: References: <4D486782CA36D4118A530000D11EA42A021AC310@blns204e.bln.icn.siemens.de> Subject: Re: [NSIS] ntlp drafts differences Date: Tue, 29 Jul 2003 11:03:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Cornelia, > I tried analysing Hennings and Melindas NTLP drafts in order to find the fundamental differences. No doubt others have also done this; I would like to compare notes. > > - what transport protocol to use, if any. > the most hotly debated difference. I don't dare going into details ;-) :o) > - Whether a NE know its next hop peer. > In Melindas NTLP, the NE just knows its previous peer. The next NE peer is discovered by a PATH-like message and subsequently addressed implicitly. > In Hennings NTPL, the NE may request to be informed of the next NE peer's address. > To my knowledge, knowing the address of the next NE peer is necessary for channel security which we require to at least be possible (Requirements ID 5.7.5). So to me this looks like a necessary feature. > > And that's it...!? It is possible that a NE does not know the next node to send a message. By examining the RSVP-HOP (previous hop) object and INTEGRITY object, a NE can know which NE has sent this message and which key is used (following the security association between them). Maybe I don't understand clearly what you mean " next NE peer is necessary for channel security ". > There was one more difference, because in Melindas draft, each PATH-like message must be replied to by a RESERVE-like message (Sec. 3.1). However at the nsis meeting, Melinda agreed there is no reason for the RESERVE message to be issued, so it could be dropped. I think it is up to NSLP. > There are a couple of what I believe are minor (i.e. not fundamental) differences, or may be rather the level of detail provided differs between the two drafts. I think they can be sorted out without too much problem - such as: > > - do we need a Logical Interface Handle? LIH is used for multicast session. According to me, it is not used if we don't mind multicast signaling applications. Nary Tra ENST, Paris _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 05:24:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16581 for ; Tue, 29 Jul 2003 05:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQi9-0003sB-D6 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 05:24:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T9O1oT014860 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 05:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQi9-0003rZ-5l; Tue, 29 Jul 2003 05:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQhu-0003rH-2s for nsis@optimus.ietf.org; Tue, 29 Jul 2003 05:23:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16570 for ; Tue, 29 Jul 2003 05:23:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hQhq-0003jI-00 for nsis@ietf.org; Tue, 29 Jul 2003 05:23:42 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19hQhp-0003jF-00 for nsis@ietf.org; Tue, 29 Jul 2003 05:23:41 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h6T9Ngn15749; Tue, 29 Jul 2003 11:23:42 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6T9NfF00581; Tue, 29 Jul 2003 11:23:41 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 11:23:41 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFFEF@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Thanh Tra LUU'" , Kappler Cornelia Cc: nsis@ietf.org Subject: RE: [NSIS] ntlp drafts differences Date: Tue, 29 Jul 2003 11:23:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, ~snip~ > > > - Whether a NE know its next hop peer. > > In Melindas NTLP, the NE just knows its previous peer. The next NE > peer is discovered by a PATH-like message and subsequently addressed > implicitly. > > In Hennings NTPL, the NE may request to be informed of the next NE > peer's address. > > To my knowledge, knowing the address of the next NE peer is > necessary for channel security which we require to at least be > possible (Requirements ID 5.7.5). So to me this looks like a necessary > feature. > > > > And that's it...!? > > It is possible that a NE does not know the next node to send a > message. By examining the RSVP-HOP (previous hop) object and INTEGRITY > object, a NE can know which NE has sent this message and which key is > used (following the security association between them). Maybe I don't > understand clearly what you mean " next NE peer is necessary for > channel security ". the problem occurs with rsvp path-alike messages. you send a message and do not really know which node is actually going to intercept it. if you know it by some means - e.g. routing table (which is already a discovery mechanism - assuming you additionally know that the next node will be nsis aware) then you can select the proper security association (and key). still something can go wrong and the message ends up at the wrong node which will drop the incorrectly protected signaling message and you will not receive an error message. i guess everyone will tell you that securing discovery messages is hard. ~snip~ ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 11:55:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27048 for ; Tue, 29 Jul 2003 11:55:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWoc-00089F-SR for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 11:55:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TFt6Md031317 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 11:55:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWoX-00088Y-LE; Tue, 29 Jul 2003 11:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWoM-00088C-5U for nsis@optimus.ietf.org; Tue, 29 Jul 2003 11:54:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27036 for ; Tue, 29 Jul 2003 11:54:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hWoK-0006kH-00 for nsis@ietf.org; Tue, 29 Jul 2003 11:54:48 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19hWoJ-0006kE-00 for nsis@ietf.org; Tue, 29 Jul 2003 11:54:48 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h6TFslp18519; Tue, 29 Jul 2003 17:54:47 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6TFskd06271; Tue, 29 Jul 2003 17:54:46 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 17:54:46 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0003@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'vzinjuvadia@yahoo.com'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] Security concern during LSP establishment Date: Tue, 29 Jul 2003 17:54:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi vishal, from your description it sounds that the problem is that the adversary is able to injecting data traffic. the data traffic - i assume mpls traffic - is marked with a specific label to force some other entity to believe that the traffic belongs to someone else. is this observation correct? is the adversary able to observe the label mapping also from the data traffic itself or only from the signaling messages? what assumptions must be met in order for an adversary to inject data traffic? is only an in-path adversary able to perform this attack? is it necessary for the adversary to be located inside the mpls domain? i assume that it is not possible to inject bogus signaling messages since they experience proper security protection. ciao hannes > -----Original Message----- > From: Vishal Zinjuvadia [mailto:vzinjuvadia@yahoo.com] > Sent: Tuesday, July 29, 2003 8:33 AM > To: Tschofenig Hannes > Subject: RE: [NSIS] Security concern during LSP establishment > > > Hello Hannes: > > Thanks for your reply. > > I am hoping that the following points will help me in > making the problem clear. > > The messages between Alice and Bob are expected to > have some degree of security associated with them. > Ideally they are expected to be talking over an > encrypted control channel. But at the very least, > sensitive information carried in the messages must be > encrypted. Data origin authentication & message > integrity are provided (using digitally signed hash of > the message appended to the message itself) and so is > replay protection (using sequence number or challenge > nonce). > > Security association can be established > administratively (offline) or using some other > protocol. As a result, Alice and Bob share a secret > key that is known only to those two entities. > > Let us assume that Trudy (intruder) is able to > determine the label-mapping (label as well as the IP > address of the node that Alice is trying to > communicate with - for e.g. Fred) using methods > described in my previous email. Then Trudy can get his > traffic switched across Bob's domain without having to > pay for it. If some sort of Service-Level Agreement > for a fixed amount of bandwidth exists between Alice > and Bob, traffic from Alice may occassionally be > denied entry into Bob's domain. Moreover, Bob may be > billing Alice based on the number of packets received > with a particular label. Trudy can launch denial of > service attacks on Bob (and also on Fred with whom the > Alice is trying to communicate via Bob's domain) since > he knows that incoming packets with valid label will > not be dropped an will be switched & routed all the > way. The impact can be much worse on Fred if the > traffic injected by Trudy is actually control traffic > for Fred. > > Your comments are much appreciated. > > Thanks, > Vishal > > --- Tschofenig Hannes > wrote: > > hi vishal, > > > > thanks for raising your security issue. i have some > > basic questions to > > better understand the problem: > > > > are all signaling messages exchanged between alice > > and bob protected (data > > origin authentication, integrity and replay > > protection)? > > > > if yes, how is the security association established? > > > > > > how is it possible that an adversary can benefit > > from the discovered label > > mapping? > > what steps are necessary after discovering the label > > mapping to mount an > > attack? > > > > ciao > > hannes > > > > > -----Original Message----- > > > From: Vishal Zinjuvadia > > [mailto:vzinjuvadia@yahoo.com] > > > Sent: Sunday, July 27, 2003 4:36 AM > > > To: nsis@ietf.org > > > Subject: [NSIS] Security concern during LSP > > establishment > > > > > > > > > Hello All: > > > > > > Following is a problem that may come up during > > > exchange of label request and label mapping > > messages > > > between two LERs using any signaling protocols. > > > > > > Label Edge Routers Alice and Bob: > > > > > > +-------+ +-------+ > > > | |M(LR)-> | | > > > |Alice |----------------------|Bob | > > > | | <-Enc(M(LM))| | > > > +-------+ ^ +-------+ > > > | > > > | > > > | > > > Trudy (intruder) > > > > > > Security Association is assumed to exist between > > Alice > > > and Bob > > > > > > Let M(A) be a message A. > > > and Enc(M(A)) be the encrypted message A. > > > > > > 1) label request sent from Alice to Bob: M(LR) > > > 2) Encrypted label mapping sent from Bob to Alice: > > > Enc(M(LM)) > > > > > > The way most signaling protocol are designed, > > > following holds true: > > > > > > 1) Labels are assigned sequentially > > > 2) The first label assigned after a LSR comes up > > is > > > generally a constant value. > > > > > > Based on the above assumptions, any intruder Trudy > > can > > > get enough plain-text cipher text combinations if > > he > > > sniffs on the link for a long enough time. Posed > > risks > > > are: > > > > > > 1) Label mapping may be discovered which could > > allow > > > any intruder to steal resources from Bob (and > > probably > > > many other LSRs on the LSP that Bob is a part of) > > > > > > 2) Trudy can play with plain-text, cipher-text > > pairs > > > and probably break the security association that > > is in > > > place between Alice and Bob. > > > > > > Has this problem been addressed so far? Can we use > > a > > > non-deterministic crypto-system where if the same > > key > > > is used to encrypt a given plain-text twice, the > > two > > > resulting cipher-texts differ in a random fashion? > > > (for e.g. the RPK algorithm proposed by Romeo, > > > Romolotti, Mattaveli and Mlynek from Swiss Federal > > > Institute of Technology). Such a solution seems to > > be > > > addressing both the above risks. > > > > > > Comments are much appreciated. > > > > > > Thanks, > > > Vishal > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! SiteBuilder - Free, easy-to-use web site > > design software > > > http://sitebuilder.yahoo.com > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 17:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10499 for ; Tue, 29 Jul 2003 17:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hc4i-0007Ad-MF for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 17:32:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TLW4xv027559 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 17:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hc4g-0007A1-55; Tue, 29 Jul 2003 17:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hc3s-00079W-LB for nsis@optimus.ietf.org; Tue, 29 Jul 2003 17:31:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10456 for ; Tue, 29 Jul 2003 17:31:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hc3q-00025W-00 for nsis@ietf.org; Tue, 29 Jul 2003 17:31:10 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 19hc3p-00025S-00 for nsis@ietf.org; Tue, 29 Jul 2003 17:31:09 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h6TLV8g25982; Tue, 29 Jul 2003 23:31:08 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6TLV7k06141; Tue, 29 Jul 2003 23:31:07 +0200 (MEST) Received: from mchh246e.demchh201e.icn.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id XAA26126; Tue, 29 Jul 2003 23:31:07 +0200 (MET DST) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 29 Jul 2003 23:30:31 +0200 Message-ID: <4D486782CA36D4118A530000D11EA42A022C78AB@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'Thanh Tra LUU'" Cc: nsis@ietf.org Date: Tue, 29 Jul 2003 23:30:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [NSIS] LIH (was: ntlp drafts differences) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Nary, see inline > > - Whether a NE know its next hop peer. > > In Melindas NTLP, the NE just knows its previous peer. The next NE > peer is discovered by a PATH-like message and subsequently addressed > implicitly. > > In Hennings NTPL, the NE may request to be informed of the next NE > peer's address. > > To my knowledge, knowing the address of the next NE peer is > necessary for channel security which we require to at least be > possible (Requirements ID 5.7.5). So to me this looks like a necessary > feature. > > > > And that's it...!? > > It is possible that a NE does not know the next node to send a > message. By examining the RSVP-HOP (previous hop) object and INTEGRITY > object, a NE can know which NE has sent this message and which key is > used (following the security association between them). Maybe I don't > understand clearly what you mean " next NE peer is necessary for > channel security ". As Hannes already pointed out, in order to establish a security association / utilize the correct one you need to know the next NE peer. > > > - do we need a Logical Interface Handle? > > LIH is used for multicast session. According to me, it is not used if > we don't mind multicast signaling applications. I think we should be careful to understand what LIH is really necessary for. It is true (according to my understanding from reading 2205) that LIH is necessary to correctly route multicast RESV messages through tunnels over non-multicast aware routers. But is this the only usage? For example there is a - for me somewhat cryptic - paragraph in 2205 saying "The LIH may also be useful when RSVP reservations are made over a complex link layer, to map between IP layer and link layer flow entities." In fact, more generally, 2205 says the LIH is used to identify the (logical) interface on which the PATH message was sent out and on which the reservation is to be established. The RESERVE may arrive at a different interface, e.g. after traversing a non-RSVP cloud, or because of a tunneling situation, and the router must be enabled to asign the RESERVE to previously established PATH state. Do we need the this feature? Remember, although we may not have PATH/RESV, we do need reverse routing state for some nslps. Below an attempt at a more detailed analysis (it would be nice if an RSVP expert could shed more light on this) - excuse the length: Why would the router have difficulties assigning the RESERVE to PATH state on a different (logical) interface? Is it because processing is done per interface, and these processes dont talk to each other? Not in our situation, since we have the concept of an NE per node, and not NE per interface. Or is it because the session identifier in the RESV is not sufficient to uniquely identify the corresponding PATH state? I think such a situation can happen, but only in the special case of tunnels through a non-multicast node - not for other tunnels or general non-RSVP clouds: Assume a mc session originates in a host attached to router A. The next hop router B is non-mc. However the mc session branches in B towards routers C and D. In such a situation A would establish one tunnel each towards C and D. These tunnels would all leave A towards B via the same interface. The original PATH message is replicated, such that there is one traveling in each tunnel, popping out at C and D respectively. (Note we dont care about the reservation for the tunnels. This is only covered in 2746. We are just interested in correctly routing the RSVP messages) When C and D send back the RESVs, which they address directly to A, A needs some means to attach the RESVs to the correct tunnels. Obviously the session ID is identical. Here the LIH, which is different for each tunnel, comes to rescue. So, as we dont cover mc for now, we dont need to cover this situation either. Therefore, I come to the same conclusion after all ;-) we dont need the LIH. It might very well be though that I missed something. Cornelia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 19:06:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14521 for ; Tue, 29 Jul 2003 19:06:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdXe-0003aS-GT for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 19:06:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TN6204013772 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 19:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdXd-0003Zb-B6; Tue, 29 Jul 2003 19:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdXH-0003Z9-4V for nsis@optimus.ietf.org; Tue, 29 Jul 2003 19:05:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14485 for ; Tue, 29 Jul 2003 19:05:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdXD-0002lC-00 for nsis@ietf.org; Tue, 29 Jul 2003 19:05:35 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19hdXC-0002l9-00 for nsis@ietf.org; Tue, 29 Jul 2003 19:05:34 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6TN5YX13150; Tue, 29 Jul 2003 16:05:34 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id QAA26811; Tue, 29 Jul 2003 16:05:33 -0700 (PDT) Date: Tue, 29 Jul 2003 16:05:33 -0700 (PDT) Message-Id: <200307292305.QAA26811@gra.isi.edu> To: luu@enst.fr, cornelia.kappler@siemens.com Subject: Re: [NSIS] LIH (was: ntlp drafts differences) Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I think your analysis is not quite right, but your conclusion seems to be correct. Assume pure unicast. When the NSIS equivalent to an upstream RESV message arrives, how does the NSIS program figure out which outgoing interface should have the reservation? Matching the path state does not help, because path state is bound to incoming interfaces, not outgoing interfaces. But the NSIS program can make the proper assignment by consulting routing -- what interface will data packets for this session be sent out? Bind the reservation to that interface. So, the LIH is not logically necessary. (OTOH, the LIH is an awfully cheap way to avoid this routing lookup in the NSIS daemon!). That's the way it seems to me. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 19:21:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14966 for ; Tue, 29 Jul 2003 19:21:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdmB-0004Ww-Ow for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 19:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNL3OE017396 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 19:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdm9-0004V2-0L; Tue, 29 Jul 2003 19:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdlN-0004ON-QU for nsis@optimus.ietf.org; Tue, 29 Jul 2003 19:20:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14888 for ; Tue, 29 Jul 2003 19:20:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdlM-0002qs-00 for nsis@ietf.org; Tue, 29 Jul 2003 19:20:12 -0400 Received: from mtiwmhc13.worldnet.att.net ([204.127.131.117]) by ietf-mx with esmtp (Exim 4.12) id 19hdlL-0002qL-00 for nsis@ietf.org; Tue, 29 Jul 2003 19:20:11 -0400 Received: from cs.columbia.edu (76.chicago-01rh15rt.il.dial-access.att.net[12.84.96.76]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003072923194011300f1a4he>; Tue, 29 Jul 2003 23:19:41 +0000 Message-ID: <3F27010C.5030302@cs.columbia.edu> Date: Tue, 29 Jul 2003 19:19:40 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Braden CC: luu@enst.fr, cornelia.kappler@siemens.com, nsis@ietf.org Subject: Re: [NSIS] LIH (was: ntlp drafts differences) References: <200307292305.QAA26811@gra.isi.edu> In-Reply-To: <200307292305.QAA26811@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One question for clarification: How would do you find out the LIH in the first place, without consulting the routing table? Bob Braden wrote: > I think your analysis is not quite right, but your conclusion seems to > be correct. > > Assume pure unicast. > > When the NSIS equivalent to an upstream RESV message arrives, how does > the NSIS program figure out which outgoing interface should have the > reservation? Matching the path state does not help, because path state > is bound to incoming interfaces, not outgoing interfaces. But the NSIS > program can make the proper assignment by consulting routing -- what > interface will data packets for this session be sent out? Bind the > reservation to that interface. So, the LIH is not logically necessary. > > (OTOH, the LIH is an awfully cheap way to avoid this routing lookup in > the NSIS daemon!). > > That's the way it seems to me. > > Bob Braden > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 19:36:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15537 for ; Tue, 29 Jul 2003 19:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19he0g-0005Fh-Lb for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 19:36:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNa22b020188 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 19:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19he0g-0005FV-6t; Tue, 29 Jul 2003 19:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19he0R-0005FF-0Z for nsis@optimus.ietf.org; Tue, 29 Jul 2003 19:35:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15534 for ; Tue, 29 Jul 2003 19:35:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19he0P-00030H-00 for nsis@ietf.org; Tue, 29 Jul 2003 19:35:45 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19he0O-00030E-00 for nsis@ietf.org; Tue, 29 Jul 2003 19:35:44 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6TNZiX01572; Tue, 29 Jul 2003 16:35:44 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id QAA26854; Tue, 29 Jul 2003 16:35:44 -0700 (PDT) Date: Tue, 29 Jul 2003 16:35:44 -0700 (PDT) Message-Id: <200307292335.QAA26854@gra.isi.edu> To: braden@ISI.EDU, hgs@cs.columbia.edu Subject: Re: [NSIS] LIH (was: ntlp drafts differences) Cc: luu@enst.fr, cornelia.kappler@siemens.com, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> From nsis-admin@ietf.org Tue Jul 29 16:21:09 2003 *> Date: Tue, 29 Jul 2003 19:19:40 -0400 *> From: Henning Schulzrinne *> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 *> X-Accept-Language: en-us, en *> MIME-Version: 1.0 *> To: Bob Braden *> CC: luu@enst.fr, cornelia.kappler@siemens.com, nsis@ietf.org *> Subject: Re: [NSIS] LIH (was: ntlp drafts differences) *> Content-Transfer-Encoding: 7bit *> Content-Transfer-Encoding: 7bit *> X-BeenThere: nsis@ietf.org *> X-Mailman-Version: 2.0.12 *> List-Unsubscribe: , *> *> List-Id: Next Steps in Signaling *> List-Post: *> List-Help: *> List-Subscribe: , *> *> X-AntiVirus: scanned by AMaViS 0.2.1 *> X-Spam-Status: No, hits=-5.9 required=5.0 *> tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, *> RCVD_IN_NJABL,REFERENCES,REPLY_WITH_QUOTES, *> USER_AGENT_MOZILLA_UA *> version=2.55 *> X-Spam-Level: *> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) *> *> One question for clarification: *> *> How would do you find out the LIH in the first place, without consulting *> the routing table? Presumably you have to do that whenever you send a path message; it saves you doing it again when you receive a Resv message. Right? Bob *> *> Bob Braden wrote: *> *> > I think your analysis is not quite right, but your conclusion seems to *> > be correct. *> > *> > Assume pure unicast. *> > *> > When the NSIS equivalent to an upstream RESV message arrives, how does *> > the NSIS program figure out which outgoing interface should have the *> > reservation? Matching the path state does not help, because path state *> > is bound to incoming interfaces, not outgoing interfaces. But the NSIS *> > program can make the proper assignment by consulting routing -- what *> > interface will data packets for this session be sent out? Bind the *> > reservation to that interface. So, the LIH is not logically necessary. *> > *> > (OTOH, the LIH is an awfully cheap way to avoid this routing lookup in *> > the NSIS daemon!). *> > *> > That's the way it seems to me. *> > *> > Bob Braden *> > *> > _______________________________________________ *> > nsis mailing list *> > nsis@ietf.org *> > https://www1.ietf.org/mailman/listinfo/nsis *> *> *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jul 29 19:48:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15847 for ; Tue, 29 Jul 2003 19:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heCH-00064O-CM for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 19:48:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNm178023314 for nsis-archive@odin.ietf.org; Tue, 29 Jul 2003 19:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heCH-00063v-2Q; Tue, 29 Jul 2003 19:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heCE-00063e-8O for nsis@optimus.ietf.org; Tue, 29 Jul 2003 19:47:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15828 for ; Tue, 29 Jul 2003 19:47:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19heCC-00035I-00 for nsis@ietf.org; Tue, 29 Jul 2003 19:47:56 -0400 Received: from mtiwmhc11.worldnet.att.net ([204.127.131.115]) by ietf-mx with esmtp (Exim 4.12) id 19heCB-000358-00 for nsis@ietf.org; Tue, 29 Jul 2003 19:47:55 -0400 Received: from cs.columbia.edu (76.chicago-01rh15rt.il.dial-access.att.net[12.84.96.76]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030729234725111008coa0e>; Tue, 29 Jul 2003 23:47:25 +0000 Message-ID: <3F27078A.70708@cs.columbia.edu> Date: Tue, 29 Jul 2003 19:47:22 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Braden CC: nsis@ietf.org Subject: Re: [NSIS] LIH (was: ntlp drafts differences) References: <200307292335.QAA26854@gra.isi.edu> In-Reply-To: <200307292335.QAA26854@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Presumably you have to do that whenever you send a path message; it saves > you doing it again when you receive a Resv message. Right? From a practical perspective, if you send a UDP-based PATH message, you wouldn't know which interface it left on. I think even for raw IP packets, the kernel does the routing, without informing the sender of the details of the interface selection decision. (Many of us would like to implement NSIS outside the kernel...) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 30 00:53:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22587 for ; Wed, 30 Jul 2003 00:53:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hixX-0007uq-FL for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 00:53:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U4r7BX030410 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 00:53:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hixR-0007u0-HF; Wed, 30 Jul 2003 00:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hixL-0007to-CX for nsis@optimus.ietf.org; Wed, 30 Jul 2003 00:52:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22568 for ; Wed, 30 Jul 2003 00:52:48 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hixI-0004lb-00 for nsis@ietf.org; Wed, 30 Jul 2003 00:52:52 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19hixH-0004lY-00 for nsis@ietf.org; Wed, 30 Jul 2003 00:52:51 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6U4qnB10203 for ; Wed, 30 Jul 2003 07:52:50 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 30 Jul 2003 07:52:49 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 30 Jul 2003 07:52:49 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 30 Jul 2003 07:52:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Jul 2003 07:52:49 +0300 Message-ID: Thread-Topic: ID Nits Reminder Thread-Index: AcNV+pwwaoyot7f4QnGfcMvC2U1fsgAW5yRA To: X-OriginalArrivalTime: 30 Jul 2003 04:52:49.0325 (UTC) FILETIME=[6D0CFDD0:01C35656] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] FW: ID Nits Reminder Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, For those who are updating drafts or plan on submitting new ones, please review the ID Nits. thanks, John -----Original Message----- From: ext IETF Secretariat [mailto:ietf-secretariat@ietf.org] Sent: 29 July, 2003 20:32 To: wgchairs@ietf.org Cc: iesg@ietf.org Subject: ID Nits Reminder Dear Working Group Chairs: In the course of your efforts, you will be submitting Internet-Drafts to = the IESG for consideration as RFCs. Please note that all Internet-Drafts offered = for publication as RFCs must conform to the requirements specified in ID = Nits (http://www.ietf.org/ID-nits.html), or they will be returned to the = author(s) for revision. Therefore, the IETF Secretariat strongly recommends that = you address all of the issues raised in this document before submitting a request to = publish an Internet-Draft to the IESG. The content issues should be addressed = early on in the work since they are integral to the technical makeup of the = Internet-Draft. Thank you in advance for your cooperation. The IETF Secretariat _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 30 08:35:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28460 for ; Wed, 30 Jul 2003 08:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hqAd-0007A3-RJ for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 08:35:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UCZ7rJ027523 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 08:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hqAX-00079M-9s; Wed, 30 Jul 2003 08:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hqA8-00078k-Ow for nsis@optimus.ietf.org; Wed, 30 Jul 2003 08:34:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28445 for ; Wed, 30 Jul 2003 08:34:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hqA7-0007Js-00 for nsis@ietf.org; Wed, 30 Jul 2003 08:34:35 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19hqA6-0007Jp-00 for nsis@ietf.org; Wed, 30 Jul 2003 08:34:34 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h6UCYFO23110; Wed, 30 Jul 2003 14:34:16 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h6UCYFG06228; Wed, 30 Jul 2003 14:34:15 +0200 (MEST) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA09727; Wed, 30 Jul 2003 14:34:14 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 30 Jul 2003 14:33:37 +0200 Message-ID: <4D486782CA36D4118A530000D11EA42A021AC340@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: Bob Braden , hgs@cs.columbia.edu Cc: nsis@ietf.org Subject: AW: [NSIS] LIH (was: ntlp drafts differences) Date: Wed, 30 Jul 2003 14:33:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Stupid question: why do I not just store "outgoing interface ID" in the PATH state rather than LIH? Then I need to do the lookup only once, too. And then it seems to me the nsis problem in that respect is different to the RSVP problem, and nsis usually doesn't need LIH or similar information: The ntlp may be used for all sorts of nslps, not just QoS reservation. ntlp needs to be able to correctly do backwards routing, i.e. assign a message coming in on an arbitrary interface to the correct ntlp state. It can do this using the session ID (plus possibly other flow-specific information - i.e. not LIH or similar); however it does not manage interface specific "reservation state" or whatever other nslp state - which in a general case may not even be bound to a particular interface (or would it be?). Therefore at least ntlp doesn't need "outgoing interface information" (LIH or otherwise). What about nslp, particulary the QoS nslp? According to the framework (6.1.5), nslp just does signaling for QoS, it doesn't do resource management. The resource management function (RMF) may not even be co-located with the nsis node. So I would conclude, nslp, too, doesn't need to know what interface a reservation will be on. Welcoming comments on flaws in my analysis, Cornelia. > *> One question for clarification: > *> > *> How would do you find out the LIH in the first place, > without consulting > *> the routing table? > > Presumably you have to do that whenever you send a path > message; it saves > you doing it again when you receive a Resv message. Right? > > Bob > > *> > *> Bob Braden wrote: > *> > *> > I think your analysis is not quite right, but your > conclusion seems to > *> > be correct. > *> > > *> > Assume pure unicast. > *> > > *> > When the NSIS equivalent to an upstream RESV message > arrives, how does > *> > the NSIS program figure out which outgoing interface > should have the > *> > reservation? Matching the path state does not help, > because path state > *> > is bound to incoming interfaces, not outgoing > interfaces. But the NSIS > *> > program can make the proper assignment by consulting > routing -- what > *> > interface will data packets for this session be sent > out? Bind the > *> > reservation to that interface. So, the LIH is not > logically necessary. > *> > > *> > (OTOH, the LIH is an awfully cheap way to avoid this > routing lookup in > *> > the NSIS daemon!). > *> > > *> > That's the way it seems to me. > *> > > *> > Bob Braden > *> > > *> > _______________________________________________ > *> > nsis mailing list > *> > nsis@ietf.org > *> > https://www1.ietf.org/mailman/listinfo/nsis > *> > *> > *> _______________________________________________ > *> nsis mailing list > *> nsis@ietf.org > *> https://www1.ietf.org/mailman/listinfo/nsis > *> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 30 11:56:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05955 for ; Wed, 30 Jul 2003 11:56:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htJ9-0005n6-OX for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 11:56:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UFu7Ra022259 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 11:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htJ3-0005lW-Ii; Wed, 30 Jul 2003 11:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htId-0005kc-Aw for nsis@optimus.ietf.org; Wed, 30 Jul 2003 11:55:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05875 for ; Wed, 30 Jul 2003 11:55:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htIc-0001Hv-00 for nsis@ietf.org; Wed, 30 Jul 2003 11:55:34 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19htIb-0001Hs-00 for nsis@ietf.org; Wed, 30 Jul 2003 11:55:33 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6UFtVX21966; Wed, 30 Jul 2003 08:55:31 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id IAA26966; Wed, 30 Jul 2003 08:55:31 -0700 (PDT) Date: Wed, 30 Jul 2003 08:55:31 -0700 (PDT) Message-Id: <200307301555.IAA26966@gra.isi.edu> To: braden@ISI.EDU, hgs@cs.columbia.edu Subject: Re: [NSIS] LIH (was: ntlp drafts differences) Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> > *> > Presumably you have to do that whenever you send a path message; it saves *> > you doing it again when you receive a Resv message. Right? *> *> From a practical perspective, if you send a UDP-based PATH message, you *> wouldn't know which interface it left on. I think even for raw IP *> packets, the kernel does the routing, without informing the sender of *> the details of the interface selection decision. (Many of us would like *> to implement NSIS outside the kernel...) *> Henning, Then I don't see how NSIS can work with such a kernel. See my earlier message: NSIS has to be able to ask routing what decisision it will make. When you say "the kernel", you have to define which kernel you mean. Cisco IOS? Some particular flavor of Unix (different ones do it differently). This seems to have degenerated into a silly discussion, or else I don't get it. Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 30 12:21:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06961 for ; Wed, 30 Jul 2003 12:21:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hthF-0007ba-S8 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 12:21:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGL1tm029234 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 12:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hthE-0007at-QN; Wed, 30 Jul 2003 12:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htga-0007Zo-Ll for nsis@optimus.ietf.org; Wed, 30 Jul 2003 12:20:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06907 for ; Wed, 30 Jul 2003 12:20:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htgZ-0001WJ-00 for nsis@ietf.org; Wed, 30 Jul 2003 12:20:19 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19htgY-0001WG-00 for nsis@ietf.org; Wed, 30 Jul 2003 12:20:18 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6UGKHX13155; Wed, 30 Jul 2003 09:20:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id JAA26983; Wed, 30 Jul 2003 09:20:17 -0700 (PDT) Date: Wed, 30 Jul 2003 09:20:17 -0700 (PDT) Message-Id: <200307301620.JAA26983@gra.isi.edu> To: braden@ISI.EDU, hgs@cs.columbia.edu, cornelia.kappler@siemens.com Subject: Re: AW: [NSIS] LIH (was: ntlp drafts differences) Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> Stupid question: why do I not just store "outgoing interface ID" in the PATH state rather than LIH? Then I need to do the lookup only once, too. *> Cornelia, The LIH *is* (an opaque handle on) the "outgoing interface ID. That is, it is encoded in a manner that is understood by the sender but not necessarily by the downstream receiver. *> And then it seems to me the nsis problem in that respect is different to the RSVP problem, and nsis usually doesn't need LIH or similar information: *> *> The ntlp may be used for all sorts of nslps, not just QoS reservation. ntlp needs to be able to correctly do backwards routing, i.e. assign a message coming in on an arbitrary interface to the correct ntlp state. It can do this using the session ID (plus possibly other flow-specific information - i.e. not LIH or similar); however it does not manage interface specific "reservation state" or whatever other nslp state - which in a general case may not even be bound to a particular interface (or would it be?). Therefore at least ntlp doesn't need "outgoing interface information" (LIH or otherwise). It appears that you did not follow what I said. Indeed, it "doesn't need" the LIH, as I said, but it may be useful to have it. *> *> What about nslp, particulary the QoS nslp? According to the framework (6.1.5), nslp just does signaling for QoS, it doesn't do resource management. The resource management function (RMF) may not even be co-located with the nsis node. So I would conclude, nslp, too, doesn't need to know what interface a reservation will be on. Your argument seems a little strange, if I understand it. QoS reservation is to be one of the applications of NSIS. For QoS reservations, you had better know on which outgoing interface to apply the reservation. Therefore, either NSLP or NTLP must be able to make this mapping (In this discussion of LIH, I do not intend to take a stand on which layer has to provide this functionality; my Two-Level paper did take a stand on that issue, but you folks are rethinking that modularity.) Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 30 12:51:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07925 for ; Wed, 30 Jul 2003 12:51:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huAH-0000ad-Eb for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 12:51:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGp19S002261 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 12:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huAG-0000Zz-R7; Wed, 30 Jul 2003 12:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huA2-0000Zj-4o for nsis@optimus.ietf.org; Wed, 30 Jul 2003 12:50:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07903 for ; Wed, 30 Jul 2003 12:50:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huA0-0001jU-00 for nsis@ietf.org; Wed, 30 Jul 2003 12:50:44 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19hu9z-0001j8-00 for nsis@ietf.org; Wed, 30 Jul 2003 12:50:44 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 17:50:13 +0100 Message-ID: From: "Hancock, Robert" To: "'Bob Braden'" , hgs@cs.columbia.edu Cc: nsis@ietf.org Subject: RE: [NSIS] LIH (was: ntlp drafts differences) Date: Wed, 30 Jul 2003 17:50:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Bob, Henning, Cornelia, I think there are two questions being discussed here. In terms of needing to know the LIH, in the unicast-only case I think it's clear that the outgoing interface at a node is derivable from other information associated with signalling messages, namely some set of header fields (called the "flow-id" in NSIS, more associated with the SESSION object in RSVP). So, from that point of view, knowing the LIH is not needed like it was in RSVP. And, to be honest, I'd rather do the mapping between header-fields and interface locally as and when needed rather than relying on indirection via various handles being passed around, the latter just seems dangerous. So I don't think the LIH is useful to be sent back to the signalling originator. It might still be useful to the receiver - for example, detecting that it had changed even though the equivalent of the RSVP_HOP had not changed (i.e. route changes, peer doesn't). Or, the protocol might detect that some other way. Or, one might not care about such changes. I think this is a question of detailed design at this stage. The other question that has been raised is whether the NTLP can/should be implementable in a purely 'routing ignorant' way (informally, as a user space process), or whether it needs closer access to the network layer on a node. It would clearly be nice to implement the NTLP purely in user space, and logically, since the NTLP only moves messages around and doesn't actually configure interface behaviour directly, this could be possible. The NTLP could punt message routing decisions to the IP stack, and hope that signalling applications that cared about interfaces found them consistently with the way the IP stack did (which is then an implementation issue for those signalling applications). In practice, I suspect this will be possible in only simple cases. For example, if you receive messages with scoped addresses, you need to know which interface they arrive on and control which interface they are replied to on (this may be simpler if we don't have site-locals any more, but I'm not certain). Or, if packets are going to be sent into tunnels which aren't visible to the sending application, some layer has to adapt the signalling payloads which refer to header fields to reflect this. This might mean integration with all sorts of horrible VPN and other functions (MIP, L2TP, IPsec, ...) but I don't see a way round that. Or, if the node is applying some kind of policy forwarding, the NTLP may need to force a signalling packet out of the same interface that it knows data packets are going to use, even if the IP stack would naturally use a different one. I tend to think of the NTLP as operating system dependent for this reason. These aspects only have to be done once, and in a signalling application dependent way. It doesn't necessarily mean an in-kernel implementation, since modern OSs may allow all sorts of intimate access to kernel data structures to appropriately privileged processes. Cheers, Robert H. PS I'd be interested to know if this thinking is different from the original CSTP proposal, since I thought it wasn't. (It talks about maintaining neighbour state including the local interface used to reach the neighbour as well as its IP address, but I assumed this was just a cached lookup of the local routing table or something specific for multicast.) > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: Wednesday, July 30, 2003 16:56 > To: braden@ISI.EDU; hgs@cs.columbia.edu > Cc: nsis@ietf.org > Subject: Re: [NSIS] LIH (was: ntlp drafts differences) > > > > *> > > *> > Presumably you have to do that whenever you send a > path message; it saves > *> > you doing it again when you receive a Resv message. Right? > *> > *> From a practical perspective, if you send a UDP-based > PATH message, you > *> wouldn't know which interface it left on. I think even > for raw IP > *> packets, the kernel does the routing, without informing > the sender of > *> the details of the interface selection decision. (Many > of us would like > *> to implement NSIS outside the kernel...) > *> > > Henning, > > Then I don't see how NSIS can work with such a kernel. See my earlier > message: NSIS has to be able to ask routing what decisision it will > make. > > When you say "the kernel", you have to define which kernel you mean. > Cisco IOS? Some particular flavor of Unix (different ones do it > differently). > > This seems to have degenerated into a silly discussion, or > else I don't > get it. > > Bob > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 30 14:24:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11770 for ; Wed, 30 Jul 2003 14:24:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvcI-0005wM-ON for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 14:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UIO2xE022803 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 14:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvcH-0005uk-AF; Wed, 30 Jul 2003 14:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvbM-0005u6-NY for nsis@optimus.ietf.org; Wed, 30 Jul 2003 14:23:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11707 for ; Wed, 30 Jul 2003 14:22:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvbK-0002Vz-00 for nsis@ietf.org; Wed, 30 Jul 2003 14:23:02 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19hvbI-0002Vq-00 for nsis@ietf.org; Wed, 30 Jul 2003 14:23:00 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6UIMa75013480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Jul 2003 14:22:47 -0400 (EDT) From: "Charles Q. Shen" To: "'Hancock, Robert'" , "'Xiaoming Fu'" Cc: "'Paulo Mendes'" , Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Date: Wed, 30 Jul 2003 14:22:45 -0400 Organization: Columbia University Message-ID: <000701c356c7$93a7bc70$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, a few comments. > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of Hancock, Robert > Sent: Monday, July 28, 2003 11:27 AM > To: 'Xiaoming Fu' > Cc: 'Charles Q. Shen'; 'Paulo Mendes'; nsis@ietf.org > Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 > > > hi xiaoming, > > more clarifications (I hope): > > > I followed up your previous mail regarding universe flow id because > > this is also (for both you and I) meant how to route the NSIS > > messages. Actually, in a previous version of fw draft it stated > > either way of using flow-id: > > *) Use a flow identification based on low level IP > > addresses (e.g. > > the Care of Address) and other 'standard' fields in the > IP header. > > This makes least demands on the packet classification > > engines within > > the network. However, it means that even on a part of the > > flow path > > which is unchanged, the reservation will need to be modified to > > reflect the changed flow identification (see section 5.3.3). > > > > *) Use a flow identification that does not change > (e.g. based on > > Home Address); this is the approach assumed in [23]. This > > simplifies > > the problem of reservation update, at the likely cost of > > considerably > > complicating the flow identification requirements. > > [reh] and what we are assuming is the first approach and not > the second. > Since the second approach seems to be referring to our RSVP-MIP draft, I would like to make a slight clarification. The key point in that draft is the necessity to keep a unique Identifier (which I called Flow Identifer back then) during mobility, so that handoff signaling overhead may be minimized. Using Home Address is one possibily to achieve that. But the draft also mentioned other possibilities, such as using IPv6 flow label. A breif summary of my understanding so far is: 1. The identifier that should not change during mobilily (if there is one) is called the Session Identifier, while its detailed structure is still open. 2. The flow identifier is the low level identifier that is used to acutally route the packet at the NTLP level, its structure could contain IP 5-tuple, IPv6 flow label, or related IP fields. 3. The association of the two (layer split functionality, etc.) is still open. I think the framework draft already contains very good descriptions of the two IDs, but it would be helpful to document explicitly what are still open issues, either in that draft or somewhere else. Thanks and regards, Charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 30 14:46:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12538 for ; Wed, 30 Jul 2003 14:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvxb-0007Hx-C1 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 14:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UIk3wV028011 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 14:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvxa-0007Gt-QV; Wed, 30 Jul 2003 14:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvxO-0007GW-TF for nsis@optimus.ietf.org; Wed, 30 Jul 2003 14:45:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12534 for ; Wed, 30 Jul 2003 14:45:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvxM-0002gU-00 for nsis@ietf.org; Wed, 30 Jul 2003 14:45:48 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19hvxL-0002gM-00 for nsis@ietf.org; Wed, 30 Jul 2003 14:45:47 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 19:45:16 +0100 Message-ID: From: "Hancock, Robert" To: "'Charles Q. Shen '" , "Hancock, Robert" , "''Xiaoming Fu' '" Cc: "''Paulo Mendes' '" , "'nsis@ietf.org '" Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Date: Wed, 30 Jul 2003 19:45:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi charles, see below, marked [reh] -----Original Message----- From: Charles Q. Shen To: Hancock, Robert; 'Xiaoming Fu' Cc: 'Paulo Mendes'; nsis@ietf.org Sent: 30/07/2003 19:22 Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Hi Robert, a few comments. > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of Hancock, Robert > Sent: Monday, July 28, 2003 11:27 AM > To: 'Xiaoming Fu' > Cc: 'Charles Q. Shen'; 'Paulo Mendes'; nsis@ietf.org > Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 > > > hi xiaoming, > > more clarifications (I hope): > > > I followed up your previous mail regarding universe flow id because > > this is also (for both you and I) meant how to route the NSIS > > messages. Actually, in a previous version of fw draft it stated > > either way of using flow-id: > > *) Use a flow identification based on low level IP > > addresses (e.g. > > the Care of Address) and other 'standard' fields in the > IP header. > > This makes least demands on the packet classification > > engines within > > the network. However, it means that even on a part of the > > flow path > > which is unchanged, the reservation will need to be modified to > > reflect the changed flow identification (see section 5.3.3). > > > > *) Use a flow identification that does not change > (e.g. based on > > Home Address); this is the approach assumed in [23]. This > > simplifies > > the problem of reservation update, at the likely cost of > > considerably > > complicating the flow identification requirements. > > [reh] and what we are assuming is the first approach and not > the second. > Since the second approach seems to be referring to our RSVP-MIP draft, I would like to make a slight clarification. The key point in that draft is the necessity to keep a unique Identifier (which I called Flow Identifer back then) during mobility, so that handoff signaling overhead may be minimized. Using Home Address is one possibily to achieve that. But the draft also mentioned other possibilities, such as using IPv6 flow label. [reh] your draft is certainly the one referred to, i have seen the same idea since in other places. the key distinction is whether the stable identifier is only in the control plane, and you accept an update (probably end to end as well) in the data plane; or whether you attempt to put a stable identifier in the data plane itself. You could try to use the HA (or something else) in either place as part of the stable identifier, but the main point of the above distinction is to claim that the second is impossible for fairly fundamental reasons. A breif summary of my understanding so far is: 1. The identifier that should not change during mobilily (if there is one) is called the Session Identifier, while its detailed structure is still open. [reh] this is my view. designing it is an NTLP design matter (i.e. the framework at least will not comment further on it). i think this is generally agreed so far as it goes. 2. The flow identifier is the low level identifier that is used to acutally route the packet at the NTLP level, its structure could contain IP 5-tuple, IPv6 flow label, or related IP fields. [reh] this is also my view. the precise definition is 'it has to contain whatever fields that are used by routers to route packets'. discussion post-Vienna on the mailing list implies to me that this is also generally agreed. 3. The association of the two (layer split functionality, etc.) is still open. [reh] basically, yes. My current proposal is that the framework will explain the implications of the open-ness of this, but that the details will be worked out in 'later activities', i.e. individual mobility analysis work. The only thing I will assert is that the association machinery is in the NSLP rather than the NTLP - but we still don't really know what that machinery is. I think the framework draft already contains very good descriptions of the two IDs, but it would be helpful to document explicitly what are still open issues, either in that draft or somewhere else. [reh] i hope this reply goes some way in that direction. Thanks and regards, Charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 30 15:09:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11771 for ; Wed, 30 Jul 2003 14:24:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvcI-0005wQ-Ot for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 14:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UIO2IM022802 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 14:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvcH-0005us-Mf; Wed, 30 Jul 2003 14:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvbM-0005uB-Sj for nsis@optimus.ietf.org; Wed, 30 Jul 2003 14:23:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11709 for ; Wed, 30 Jul 2003 14:22:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvbK-0002Vx-00 for nsis@ietf.org; Wed, 30 Jul 2003 14:23:02 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19hvbI-0002Vp-00 for nsis@ietf.org; Wed, 30 Jul 2003 14:23:00 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6UIMa74013480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Jul 2003 14:22:39 -0400 (EDT) From: "Charles Q. Shen" To: , Cc: , , , Subject: RE: reliability or not reliablility was: [NSIS] mobility-related requirements from nsis-req-08 Date: Wed, 30 Jul 2003 14:22:34 -0400 Organization: Columbia University Message-ID: <000601c356c7$92144b30$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, July 25, 2003 10:06 AM > > Rather than cycling on this, NSLP protocols probably should > state what they need / expect and NTLP should provide this > functionality, in terms of reliability. > It is probably a good idea to include such a discussion in Robert's upcoming draft about reliability analysis. Regards, Charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jul 30 15:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15460 for ; Wed, 30 Jul 2003 15:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hx0Q-0001M3-8t for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 15:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UJr2OG005200 for nsis-archive@odin.ietf.org; Wed, 30 Jul 2003 15:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hx0O-0001Lk-Vu; Wed, 30 Jul 2003 15:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hx02-0001HB-MG for nsis@optimus.ietf.org; Wed, 30 Jul 2003 15:52:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15438 for ; Wed, 30 Jul 2003 15:52:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hwzz-00035a-00 for nsis@ietf.org; Wed, 30 Jul 2003 15:52:35 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19hwzz-00035X-00 for nsis@ietf.org; Wed, 30 Jul 2003 15:52:35 -0400 Received: from president (dyn-fair-240-199.dyn.columbia.edu [160.39.240.199]) (user=qs2005 mech=LOGIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6UJqU74029551 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Jul 2003 15:52:31 -0400 (EDT) From: "Charles Q. Shen" To: "'Hancock, Robert'" , "''Xiaoming Fu' '" Cc: "''Paulo Mendes' '" , Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Date: Wed, 30 Jul 2003 15:52:28 -0400 Organization: Columbia University Message-ID: <001101c356d4$1b5e0d70$c7f027a0@president> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, comments in the bottom marked [CS] > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Wednesday, July 30, 2003 2:45 PM > To: 'Charles Q. Shen '; Hancock, Robert; ''Xiaoming Fu' ' > Cc: ''Paulo Mendes' '; 'nsis@ietf.org ' > Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 > > > hi charles, > > see below, marked [reh] > > -----Original Message----- > From: Charles Q. Shen > To: Hancock, Robert; 'Xiaoming Fu' > Cc: 'Paulo Mendes'; nsis@ietf.org > Sent: 30/07/2003 19:22 > Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 > > Hi Robert, a few comments. > > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On Behalf Of > > Hancock, Robert > > Sent: Monday, July 28, 2003 11:27 AM > > To: 'Xiaoming Fu' > > Cc: 'Charles Q. Shen'; 'Paulo Mendes'; nsis@ietf.org > > Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 > > > > > > hi xiaoming, > > > > more clarifications (I hope): > > > > > I followed up your previous mail regarding universe flow > id because > > > this is also (for both you and I) meant how to route the NSIS > > > messages. Actually, in a previous version of fw draft it stated > > > either way of using flow-id: > > > *) Use a flow identification based on low level IP > > > addresses (e.g. > > > the Care of Address) and other 'standard' fields in the > > IP header. > > > This makes least demands on the packet classification engines > > > within > > > the network. However, it means that even on a part of the > > > flow path > > > which is unchanged, the reservation will need to be > modified to > > > reflect the changed flow identification (see section 5.3.3). > > > > > > *) Use a flow identification that does not change > > (e.g. based on > > > Home Address); this is the approach assumed in [23]. This > > > simplifies > > > the problem of reservation update, at the likely cost of > > > considerably > > > complicating the flow identification requirements. > > > > [reh] and what we are assuming is the first approach and not the > > second. > > > > Since the second approach seems to be referring to our > RSVP-MIP draft, I would like to make a slight clarification. > The key point in that draft is the necessity to keep a unique > Identifier (which I called Flow Identifer back then) during > mobility, so that handoff signaling overhead may be > minimized. Using Home Address is one possibily to achieve > that. But the draft also mentioned other possibilities, such > as using IPv6 flow label. > > [reh] your draft is certainly the one referred to, i have > seen the same idea since in other places. the key distinction > is whether the stable identifier is only in the control plane, and > you accept an update (probably end to end as well) in the > data plane; or whether you attempt to put a stable identifier > in the data plane > itself. You could try to use the HA (or something else) in either > place as part of the stable identifier, but the main point of the > above distinction is to claim that the second is impossible > for fairly fundamental reasons. > [CS] First, I completely agree with your view here. In fact I also discussed briefly the control/data plane identifer distinction issue in my later NSIS-mobility draft. Second (less important): the need for a unique identifier is still the starting point of the "Home address" approach, not the other way around. It was after that practice that the importance of separate views on control/data plane identifers became very clear to me. The rest all agreed and snipped :) Thanks and regards, Charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 31 05:39:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18209 for ; Thu, 31 Jul 2003 05:39:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i9tn-0007hK-Qj for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 05:39:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V9d3gX029589 for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 05:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i9tl-0007gc-0q; Thu, 31 Jul 2003 05:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i9tI-0007gL-C1 for nsis@optimus.ietf.org; Thu, 31 Jul 2003 05:38:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18166 for ; Thu, 31 Jul 2003 05:38:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i9tE-0001IC-00 for nsis@ietf.org; Thu, 31 Jul 2003 05:38:28 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19i9tE-0001I7-00 for nsis@ietf.org; Thu, 31 Jul 2003 05:38:28 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 10:37:58 +0100 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes'" , "'Thanh Tra LUU'" , Kappler Cornelia Cc: nsis@ietf.org Subject: RE: [NSIS] ntlp drafts differences Date: Thu, 31 Jul 2003 10:37:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, On this security front, there seems to be a choice between a) Find out (insecurely) who your downstream peer is, then send them a (secured) signalling message directly. b) Send a (secured) signalling message which only the right downstream peer can receive correctly, and get an error message if it ended up at the wrong place. Are there fundamental differences in what security can be achieved between these two methods? They seem to me to provide equal opportunities for securing the signalling data (and for getting this wrong), and equal opportunities for preventing DoS attacks (and getting this wrong). The threats are the same, they just apply at different stages in the message flow. Or, is there something subtle I am missing? (The main difference is in when in the message sequence the reaction to a route change takes place, but I don't see this as a security issue. Indeed, some people think it is a non-issue.) cheers, r. > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Tuesday, July 29, 2003 10:24 > To: 'Thanh Tra LUU'; Kappler Cornelia > Cc: nsis@ietf.org > Subject: RE: [NSIS] ntlp drafts differences > > > hi, > > ~snip~ > > > > > - Whether a NE know its next hop peer. > > > In Melindas NTLP, the NE just knows its previous peer. The next NE > > peer is discovered by a PATH-like message and subsequently addressed > > implicitly. > > > In Hennings NTPL, the NE may request to be informed of the next NE > > peer's address. > > > To my knowledge, knowing the address of the next NE peer is > > necessary for channel security which we require to at least be > > possible (Requirements ID 5.7.5). So to me this looks like > a necessary > > feature. > > > > > > And that's it...!? > > > > It is possible that a NE does not know the next node to send a > > message. By examining the RSVP-HOP (previous hop) object > and INTEGRITY > > object, a NE can know which NE has sent this message and > which key is > > used (following the security association between them). > Maybe I don't > > understand clearly what you mean " next NE peer is necessary for > > channel security ". > > > the problem occurs with rsvp path-alike messages. you send a > message and do > not really know which node is actually going to intercept it. > > if you know it by some means - e.g. routing table (which is already a > discovery mechanism - assuming you additionally know that the > next node will > be nsis aware) then you can select the proper security > association (and > key). still something can go wrong and the message ends up at > the wrong node > which will drop the incorrectly protected signaling message > and you will not > receive an error message. > > > i guess everyone will tell you that securing discovery > messages is hard. > > ~snip~ > > > ciao > hannes > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 31 06:24:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19336 for ; Thu, 31 Jul 2003 06:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iAbJ-00010G-NN for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 06:24:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VAO1Dn003846 for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 06:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iAbJ-0000zw-J4; Thu, 31 Jul 2003 06:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iAb7-0000zQ-92 for nsis@optimus.ietf.org; Thu, 31 Jul 2003 06:23:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19301 for ; Thu, 31 Jul 2003 06:23:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iAb3-0001q0-00 for nsis@ietf.org; Thu, 31 Jul 2003 06:23:45 -0400 Received: from [137.194.192.1] (helo=infres.enst.fr) by ietf-mx with esmtp (Exim 4.12) id 19iAb2-0001ps-00 for nsis@ietf.org; Thu, 31 Jul 2003 06:23:44 -0400 Received: from NaryTra (dhcp7-211.enst.fr [137.194.7.211]) by infres.enst.fr (Postfix) with SMTP id 84E7E1DA7; Thu, 31 Jul 2003 12:23:19 +0200 (MEST) Message-ID: <005c01c3574d$e3dfd020$d307c289@enst.fr> From: "Thanh Tra LUU" To: "Kappler Cornelia" Cc: References: <4D486782CA36D4118A530000D11EA42A022C78AB@blns204e.bln.icn.siemens.de> Subject: Re: [NSIS] LIH (was: ntlp drafts differences) Date: Thu, 31 Jul 2003 12:21:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Cornelia, When I wrote that a NE can send a downstream signaling message without knowing its next NE, I thought about a security association (SA) in domaine. That means every NE has a SA, which is known in a domaine. So it does not need to know its next NE. Sorry, I got a mistake. LIH, in fact, I think we can use SESSION_ID (of NSIS) for LIH. So LIH is not necessary anymore. Of course, SESSION_ID can be used for a multicast signaling application session. But SESSION_ID structure is still an open issue and multicast is out of scope of NSIS. Nary Tra, ENST, Paris. ----- Original Message ----- From: Kappler Cornelia To: 'Thanh Tra LUU' Cc: Sent: Tuesday, July 29, 2003 11:30 PM Subject: [NSIS] LIH (was: ntlp drafts differences) > Hi Nary, see inline > > > > - Whether a NE know its next hop peer. > > > In Melindas NTLP, the NE just knows its previous peer. The next NE > > peer is discovered by a PATH-like message and subsequently addressed > > implicitly. > > > In Hennings NTPL, the NE may request to be informed of the next NE > > peer's address. > > > To my knowledge, knowing the address of the next NE peer is > > necessary for channel security which we require to at least be > > possible (Requirements ID 5.7.5). So to me this looks like a necessary > > feature. > > > > > > And that's it...!? > > > > It is possible that a NE does not know the next node to send a > > message. By examining the RSVP-HOP (previous hop) object and INTEGRITY > > object, a NE can know which NE has sent this message and which key is > > used (following the security association between them). Maybe I don't > > understand clearly what you mean " next NE peer is necessary for > > channel security ". > > As Hannes already pointed out, in order to establish a security association / utilize the correct one you need to know the next NE peer. > > > > > > - do we need a Logical Interface Handle? > > > > LIH is used for multicast session. According to me, it is not used if > > we don't mind multicast signaling applications. > > I think we should be careful to understand what LIH is really necessary for. It is true (according to my understanding from reading 2205) that LIH is necessary to correctly route multicast RESV messages through tunnels over non-multicast aware routers. But is this the only usage? > > For example there is a - for me somewhat cryptic - paragraph in 2205 saying "The LIH may also be useful when RSVP reservations are made over a complex link layer, to map between IP layer and link layer flow entities." > > In fact, more generally, 2205 says the LIH is used to identify the (logical) interface on which the PATH message was sent out and on which the reservation is to be established. The RESERVE may arrive at a different interface, e.g. after traversing a non-RSVP cloud, or because of a tunneling situation, and the router must be enabled to asign the RESERVE to previously established PATH state. > > Do we need the this feature? Remember, although we may not have PATH/RESV, we do need reverse routing state for some nslps. Below an attempt at a more detailed analysis (it would be nice if an RSVP expert could shed more light on this) - excuse the length: > > Why would the router have difficulties assigning the RESERVE to PATH state on a different (logical) interface? > > Is it because processing is done per interface, and these processes dont talk to each other? Not in our situation, since we have the concept of an NE per node, and not NE per interface. > > Or is it because the session identifier in the RESV is not sufficient to uniquely identify the corresponding PATH state? I think such a situation can happen, but only in the special case of tunnels through a non-multicast node - not for other tunnels or general non-RSVP clouds: > > Assume a mc session originates in a host attached to router A. The next hop router B is non-mc. However the mc session branches in B towards routers C and D. In such a situation A would establish one tunnel each towards C and D. These tunnels would all leave A towards B via the same interface. The original PATH message is replicated, such that there is one traveling in each tunnel, popping out at C and D respectively. (Note we dont care about the reservation for the tunnels. This is only covered in 2746. We are just interested in correctly routing the RSVP messages) When C and D send back the RESVs, which they address directly to A, A needs some means to attach the RESVs to the correct tunnels. Obviously the session ID is identical. Here the LIH, which is different for each tunnel, comes to rescue. > > So, as we dont cover mc for now, we dont need to cover this situation either. Therefore, I come to the same conclusion after all ;-) we dont need the LIH. It might very well be though that I missed something. > > Cornelia > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 31 07:20:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20805 for ; Thu, 31 Jul 2003 07:20:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iBTV-0003Jq-0B for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 07:20:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VBK06V012752 for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 07:20:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iBTU-0003JY-K4; Thu, 31 Jul 2003 07:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iBSb-0003GA-Be for nsis@optimus.ietf.org; Thu, 31 Jul 2003 07:19:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20756 for ; Thu, 31 Jul 2003 07:19:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iBSa-0002Oh-00 for nsis@ietf.org; Thu, 31 Jul 2003 07:19:04 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19iBSa-0002Oc-00 for nsis@ietf.org; Thu, 31 Jul 2003 07:19:04 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h6VBJ2E09020; Thu, 31 Jul 2003 13:19:02 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6VBJ2s03061; Thu, 31 Jul 2003 13:19:02 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 13:19:00 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC001B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Hancock, Robert'" , "'Thanh Tra LUU'" , Kappler Cornelia Cc: nsis@ietf.org Subject: RE: [NSIS] ntlp drafts differences Date: Thu, 31 Jul 2003 13:18:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi robert, thanks for pointing to this issue. i think that it is important to differentiate between a) how rsvp handles it today and b) would are possible ways todo it. ad a) as described in the rsvp security properties draft, an rsvp message gets DROPPED when cryptographic verification fails. hence there is no error message which would allow the previous node to discover the next hop. ad b) it is certainly true that you can modify the path message to achieve the desired behavior. with regard to standard security mechanisms it is clear that ipsec cannot be used to protect this message. but even there you can reuse existing security mechanisms (to some extend) to support exising authentication and key exchange mechanisms (as described in draft-tschofenig-rsvp-doi-00.txt). there are other implications with regard to addressing which are not immediately relevant for security (hence i do not describe them). ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Thursday, July 31, 2003 11:38 AM > To: Tschofenig Hannes; 'Thanh Tra LUU'; Kappler Cornelia > Cc: nsis@ietf.org > Subject: RE: [NSIS] ntlp drafts differences > > > hi all, > > On this security front, there seems to be a choice between > a) Find out (insecurely) who your downstream peer is, then send > them a (secured) signalling message directly. > b) Send a (secured) signalling message which only the right > downstream peer can receive correctly, and get an error message > if it ended up at the wrong place. > > Are there fundamental differences in what security can be > achieved between these two methods? > They seem to me to provide > equal opportunities for securing the signalling data (and for > getting this wrong), and equal opportunities for preventing > DoS attacks (and getting this wrong). The threats are the same, > they just apply at different stages in the message flow. > Or, is there something subtle I am missing? > > (The main difference is in when in the message sequence the > reaction to a route change takes place, but I don't see this as > a security issue. Indeed, some people think it is a non-issue.) > > cheers, > > r. > > > -----Original Message----- > > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Tuesday, July 29, 2003 10:24 > > To: 'Thanh Tra LUU'; Kappler Cornelia > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] ntlp drafts differences > > > > > > hi, > > > > ~snip~ > > > > > > > - Whether a NE know its next hop peer. > > > > In Melindas NTLP, the NE just knows its previous peer. > The next NE > > > peer is discovered by a PATH-like message and > subsequently addressed > > > implicitly. > > > > In Hennings NTPL, the NE may request to be informed of > the next NE > > > peer's address. > > > > To my knowledge, knowing the address of the next NE peer is > > > necessary for channel security which we require to at least be > > > possible (Requirements ID 5.7.5). So to me this looks like > > a necessary > > > feature. > > > > > > > > And that's it...!? > > > > > > It is possible that a NE does not know the next node to send a > > > message. By examining the RSVP-HOP (previous hop) object > > and INTEGRITY > > > object, a NE can know which NE has sent this message and > > which key is > > > used (following the security association between them). > > Maybe I don't > > > understand clearly what you mean " next NE peer is necessary for > > > channel security ". > > > > > > the problem occurs with rsvp path-alike messages. you send a > > message and do > > not really know which node is actually going to intercept it. > > > > if you know it by some means - e.g. routing table (which is > already a > > discovery mechanism - assuming you additionally know that the > > next node will > > be nsis aware) then you can select the proper security > > association (and > > key). still something can go wrong and the message ends up at > > the wrong node > > which will drop the incorrectly protected signaling message > > and you will not > > receive an error message. > > > > > > i guess everyone will tell you that securing discovery > > messages is hard. > > > > ~snip~ > > > > > > ciao > > hannes > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to > Roke Manor Research Ltd and must not be passed to any third > party without > permission. This communication is for information only and > shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 31 07:44:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21347 for ; Thu, 31 Jul 2003 07:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iBql-0004AH-Vx for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 07:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VBi3E8015994 for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 07:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iBqj-00049U-FE; Thu, 31 Jul 2003 07:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iBqV-00049I-Qs for nsis@optimus.ietf.org; Thu, 31 Jul 2003 07:43:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21332 for ; Thu, 31 Jul 2003 07:43:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iBqV-0002ca-00 for nsis@ietf.org; Thu, 31 Jul 2003 07:43:47 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19iBqU-0002c2-00 for nsis@ietf.org; Thu, 31 Jul 2003 07:43:46 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 31 Jul 2003 13:43:15 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 13:43:14 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB572@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] ntlp drafts differences Date: Thu, 31 Jul 2003 13:43:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Robert |a) Find out (insecurely) who your downstream peer is, then send |them a (secured) signalling message directly. | |b) Send a (secured) signalling message which only the right |downstream peer can receive correctly, and get an error message |if it ended up at the wrong place. Without being a security expert: b) would base discovery on prior topology awareness or=20 error messages? If error messages would require changes on=20 existing security protocols while they could remain unchanged=20 to support a), the latter is my preferred choice. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 31 08:17:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22158 for ; Thu, 31 Jul 2003 08:17:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCMg-0005KS-NE for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 08:17:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VCH27j020478 for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 08:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCMf-0005Jk-SR; Thu, 31 Jul 2003 08:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCLs-0005IK-DF for nsis@optimus.ietf.org; Thu, 31 Jul 2003 08:16:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22125 for ; Thu, 31 Jul 2003 08:16:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iCLr-0002uW-00 for nsis@ietf.org; Thu, 31 Jul 2003 08:16:11 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19iCLq-0002tw-00 for nsis@ietf.org; Thu, 31 Jul 2003 08:16:10 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 13:15:39 +0100 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes'" , "'Thanh Tra LUU'" , Kappler Cornelia Cc: nsis@ietf.org Subject: RE: [NSIS] ntlp drafts differences Date: Thu, 31 Jul 2003 13:15:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi hannes, it would certainly be interesting to know why RSVP 2747 is specified that way. (A naive assumption would be that a receiver could generate a PathErr with the appropriate error code. I don't see how doing that would open up new security issues compared to those that already exist, but I haven't thought about it very hard.) r. > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, July 31, 2003 12:19 > To: Hancock, Robert; 'Thanh Tra LUU'; Kappler Cornelia > Cc: nsis@ietf.org > Subject: RE: [NSIS] ntlp drafts differences > > > hi robert, > > thanks for pointing to this issue. > > i think that it is important to differentiate between > > a) how rsvp handles it today and > b) would are possible ways todo it. > > ad a) > as described in the rsvp security properties draft, an rsvp > message gets > DROPPED when cryptographic verification fails. hence there is no error > message which would allow the previous node to discover the next hop. > > ad b) > it is certainly true that you can modify the path message to > achieve the > desired behavior. > > with regard to standard security mechanisms it is clear that > ipsec cannot be > used to protect this message. but even there you can reuse > existing security > mechanisms (to some extend) to support exising authentication and key > exchange mechanisms (as described in > draft-tschofenig-rsvp-doi-00.txt). > > there are other implications with regard to addressing which are not > immediately relevant for security (hence i do not describe them). > > ciao > hannes > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Thursday, July 31, 2003 11:38 AM > > To: Tschofenig Hannes; 'Thanh Tra LUU'; Kappler Cornelia > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] ntlp drafts differences > > > > > > hi all, > > > > On this security front, there seems to be a choice between > > a) Find out (insecurely) who your downstream peer is, then send > > them a (secured) signalling message directly. > > b) Send a (secured) signalling message which only the right > > downstream peer can receive correctly, and get an error message > > if it ended up at the wrong place. > > > > Are there fundamental differences in what security can be > > achieved between these two methods? > > They seem to me to provide > > equal opportunities for securing the signalling data (and for > > getting this wrong), and equal opportunities for preventing > > DoS attacks (and getting this wrong). The threats are the same, > > they just apply at different stages in the message flow. > > Or, is there something subtle I am missing? > > > > (The main difference is in when in the message sequence the > > reaction to a route change takes place, but I don't see this as > > a security issue. Indeed, some people think it is a non-issue.) > > > > cheers, > > > > r. > > > > > -----Original Message----- > > > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > > Sent: Tuesday, July 29, 2003 10:24 > > > To: 'Thanh Tra LUU'; Kappler Cornelia > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] ntlp drafts differences > > > > > > > > > hi, > > > > > > ~snip~ > > > > > > > > > - Whether a NE know its next hop peer. > > > > > In Melindas NTLP, the NE just knows its previous peer. > > The next NE > > > > peer is discovered by a PATH-like message and > > subsequently addressed > > > > implicitly. > > > > > In Hennings NTPL, the NE may request to be informed of > > the next NE > > > > peer's address. > > > > > To my knowledge, knowing the address of the next NE peer is > > > > necessary for channel security which we require to at least be > > > > possible (Requirements ID 5.7.5). So to me this looks like > > > a necessary > > > > feature. > > > > > > > > > > And that's it...!? > > > > > > > > It is possible that a NE does not know the next node to send a > > > > message. By examining the RSVP-HOP (previous hop) object > > > and INTEGRITY > > > > object, a NE can know which NE has sent this message and > > > which key is > > > > used (following the security association between them). > > > Maybe I don't > > > > understand clearly what you mean " next NE peer is necessary for > > > > channel security ". > > > > > > > > > the problem occurs with rsvp path-alike messages. you send a > > > message and do > > > not really know which node is actually going to intercept it. > > > > > > if you know it by some means - e.g. routing table (which is > > already a > > > discovery mechanism - assuming you additionally know that the > > > next node will > > > be nsis aware) then you can select the proper security > > > association (and > > > key). still something can go wrong and the message ends up at > > > the wrong node > > > which will drop the incorrectly protected signaling message > > > and you will not > > > receive an error message. > > > > > > > > > i guess everyone will tell you that securing discovery > > > messages is hard. > > > > > > ~snip~ > > > > > > > > > ciao > > > hannes > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > -- > > Registered Office: Roke Manor Research Ltd, Siemens House, > > Oldbury, Bracknell, > > Berkshire. RG12 8FZ > > > > The information contained in this e-mail and any attachments > > is confidential to > > Roke Manor Research Ltd and must not be passed to any third > > party without > > permission. This communication is for information only and > > shall not create or > > change any contractual relationship. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jul 31 11:49:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02320 for ; Thu, 31 Jul 2003 11:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFfp-0007rM-TA for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 11:49:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFn12R030197 for nsis-archive@odin.ietf.org; Thu, 31 Jul 2003 11:49:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFfp-0007qw-9G; Thu, 31 Jul 2003 11:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFfU-0007qf-Sm for nsis@optimus.ietf.org; Thu, 31 Jul 2003 11:48:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02288 for ; Thu, 31 Jul 2003 11:48:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFfT-0005FR-00 for nsis@ietf.org; Thu, 31 Jul 2003 11:48:39 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19iFfT-0005FO-00 for nsis@ietf.org; Thu, 31 Jul 2003 11:48:39 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6VFmcdf023926 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Jul 2003 11:48:38 -0400 (EDT) Message-ID: <3F293A56.9010006@cs.columbia.edu> Date: Thu, 31 Jul 2003 11:48:38 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Braden CC: nsis@ietf.org Subject: Re: [NSIS] LIH (was: ntlp drafts differences) References: <200307301555.IAA26966@gra.isi.edu> In-Reply-To: <200307301555.IAA26966@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bob Braden wrote: > Then I don't see how NSIS can work with such a kernel. See my earlier > message: NSIS has to be able to ask routing what decisision it will > make. > > When you say "the kernel", you have to define which kernel you mean. > Cisco IOS? Some particular flavor of Unix (different ones do it > differently). > > This seems to have degenerated into a silly discussion, or else I don't > get it. I do agree that we're probably agreeing and talking past each other at the same time. Clearly, if you want to set up resources, you better know which interface the traffic is leaving the box on. This does not necessarily mean that NTLP has to know this, as long as the PATH-like message reaches the same next hop. Thus, one model is that a QOS NSLP figures out (asking the routing table, for example) which interface is handling the packets, but NTLP doesn't have to. Since not all applications will need to set interface state, not all applications will need to know this information, so it seems best handled by those who need to know. I'm not aware of any Unix OS that propagates outgoing interface information to the socket; I'd definitely be curious as to whether this is supported somewhere. (Incoming interface information is available on Linux, via getsockopt IP_PKTINFO.) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis