From daemon@optimus.ietf.org Thu May 2 05:00:17 2002 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 FAA02709 for ; Thu, 2 May 2002 05:00:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20697 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 05:00:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20250; Thu, 2 May 2002 04:50:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20221 for ; Thu, 2 May 2002 04:50:47 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02306 for ; Thu, 2 May 2002 04:50:44 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 10:48:56 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 10:50:06 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Date: Thu, 2 May 2002 10:50:04 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA20222 Subject: [NSIS] Admission control relevant routing information Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Dear Markus, I'd like to suggest the following requirement to be added to the requirements draft. 5.8.11 The QoS signaling protocol must specify which model of admission control it is supporting and whether and which adress information has to be carried by it. QoS service provisioning may depend on service type and provider philosophy. A purely qualitative service may not require definition of a specific destination being serviced. In contrast, a resource intensive real time service may require detailed information on the route of the traffic for the purpose of admission control. In the latter case, the NSIS protocol may e.g. have to transport IP address information of some kind between adjacent QC nodes. An NSIS protocol must therefore specify, whether and how IP routing is relevant to the service supported. I hope it's getting clear what I mean. If somebody is able to provide a more comprehensive explanation, go ahead. Regards, Rüdiger Rüdiger Geib Senior Expert T-Systems Nova GmbH Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 832138 Fax: +49 6151 838103 mailto:Ruediger.Geib@t-systems.com http://www.t-nova.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 05:51:00 2002 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 FAA05427 for ; Thu, 2 May 2002 05:51:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA23375 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 05:51:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22872; Thu, 2 May 2002 05:37:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22844 for ; Thu, 2 May 2002 05:37:16 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04503 for ; Thu, 2 May 2002 05:37:12 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g429bLL86033; Thu, 2 May 2002 11:37:21 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 98B50C051; Thu, 2 May 2002 11:33:58 +0200 (CEST) Date: Thu, 02 May 2002 11:45:34 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Geib, Ruediger" Cc: nsis@ietf.org Message-ID: <5012397.1020339934@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA22845 Subject: [NSIS] Re: Admission control relevant routing information Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Ruediger, I think I have understood your point. However, we added an assumption saying, that a NSIS protocol user already knows about the service types before the nsis protocol even starts. And we do not specify how this is achieved (e.g. by web page, in the customer-provider contract, etc.) What I am not sure about is what exactly you mean by admission control model how is it different from a part of the service definition (service model)? Marcus --On Thursday, May 02, 2002 10:50 AM +0200 "Geib, Ruediger" wrote: > Dear Markus, > > I'd like to suggest the following requirement to be added to the > requirements draft. > > 5.8.11 The QoS signaling protocol must specify which model of admission > control it is supporting and whether and which adress information has to > be carried by it. QoS service provisioning may depend on service type and > provider philosophy. A purely qualitative service may not require > definition of a specific destination being serviced. In contrast, a > resource intensive real time service may require detailed information on > the route of the traffic for the purpose of admission control. In the > latter case, the NSIS protocol may e.g. have to transport IP address > information of some kind between adjacent QC nodes. An NSIS protocol must > therefore specify, whether and how IP routing is relevant to the service > supported. > > I hope it's getting clear what I mean. If somebody is able to provide a > more comprehensive explanation, go ahead. > > Regards, Rüdiger > > > Rüdiger Geib > Senior Expert > T-Systems Nova GmbH > Technologiezentrum > Am Kavalleriesand 3, 64295 Darmstadt > Germany > Fon: +49 6151 832138 > Fax: +49 6151 838103 > mailto:Ruediger.Geib@t-systems.com > http://www.t-nova.de > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 06:04:54 2002 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 GAA06406 for ; Thu, 2 May 2002 06:04:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA24364 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 06:04:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23622; Thu, 2 May 2002 05:56:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23589 for ; Thu, 2 May 2002 05:56:56 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05802 for ; Thu, 2 May 2002 05:56:52 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 11:55:10 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 11:56:21 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Date: Thu, 2 May 2002 11:56:20 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA23590 Subject: [NSIS] Operational QoS signaling protocol requirements Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Dear Markus, By and large operational NSIS protocol requirements miss in the requirements draft. I'd suggest to add: 5.12 Operational Stability The design of an NSIS protocol must provide a maximum of operational stability. The state of a unit involved into NSIS signalling must be stable no matter what the surronding conditions are. This leads to the following requirements: 5.12.1 Backwards compatibility A later version of an NSIS protocol must be backwards compatible with earlier versions of an NSIS protocol. 5.12.2 Unexpected situations and error restistance An NSIS protocol must define behaviour of NSIS signaling units during unexpected situations. Unexpected situtions are unknown messages, parameters and parameter settings as well as receiption of unexpected messages (e.g. a "Reservation Confirmation" without prior "Reservation Request"). 5.12.3 Default behaviour An NSIS protocol must define default behaviours and parameter settings wherever applicable. 5.12.4 Extendability An NSIS protocol must provide means to enhance a protocol with future procedures, messages, parameters and parameter settings. 5.12.5 Preventation of stale state An NSIS signalling protocol must provide means for an NSIS signaling unit to discover and remove local stale state. This may for example be done by means like soft state and periodic flooding or by a polling mechanism and hard state signaling. 5.12.6 Reliable Communication NSIS signaling procedures, connectivity between units involved in NSIS signaling as well as the basic transport protocol used by NSIS must provide a maximum of communication reliability. Procedures must define how an NSIS signaling systems behaves if some kind of request it sent stays without answer (this could require e.g. be timers, number of message retransmits and release messages). An NSIS signaling unit must be able to check its connectivity to an adjacent NSIS signaling unit at any time (this requirement must however not result in a DoS attack tool - the frequency of these checks must be limited, and flow control may be useful). The basic transport protocol to be used between adjacent NSIS units must ensure message integrity and reliable transport. 5.12.7 Smooth breakdown A unit participating in NSIS signaling must no cause further damage to other systems involved in NSIS signaling when it has to go out of service. Regards, Rüdiger Rüdiger Geib Senior Expert T-Systems Nova GmbH Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 832138 Fax: +49 6151 838103 mailto:Ruediger.Geib@t-systems.com http://www.t-nova.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 06:11:47 2002 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 GAA06891 for ; Thu, 2 May 2002 06:11:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA24790 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 06:11:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24315; Thu, 2 May 2002 06:03:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24284 for ; Thu, 2 May 2002 06:03:36 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06321 for ; Thu, 2 May 2002 06:03:33 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 12:01:48 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 12:02:58 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Date: Thu, 2 May 2002 12:02: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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA24285 Subject: [NSIS] Errored situation signaling requirements Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Dear Markus, An enhancement and a new "non QoS related signaling" requirement: 5.3.2 Release after failure After detection of a failure or stale state, any QoS controller/initiator must be able to release a reservation it is involved in. This may require signaling of the "Release after Failure" message upstream as well as downstream. 5.3.6 Error notification and error location An NSIS signaling node rejecting or releasing a reservation must indicate its identity. NSIS signalling should indicate why a requested resource is not or no longer available. (5.3.7 Explicit request of resources NSIS signaling must support the explicit request of resources.) That final one may not have to be stated explicitely.... Regards, Rüdiger Rüdiger Geib Senior Expert T-Systems Nova GmbH Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 832138 Fax: +49 6151 838103 mailto:Ruediger.Geib@t-systems.com http://www.t-nova.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 06:13:17 2002 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 GAA07025 for ; Thu, 2 May 2002 06:13:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA24859 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 06:13:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23689; Thu, 2 May 2002 05:57:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23656 for ; Thu, 2 May 2002 05:57:26 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05860 for ; Thu, 2 May 2002 05:57:23 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 11:55:43 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 11:56:54 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Date: Thu, 2 May 2002 11:56:52 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA23657 Subject: [NSIS] RE: Admission control relevant routing information Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Marcus, let's take the example of RSVP: the RSVP node must store the IP address of the prior RSVP signaling node in order to provide the service requested. let's take a centralized system supporting RSVP in a diffserv cloud: it must know by which gateway a specific RSVP reservation entered in order to provide the requested service. Note that the centralized unit may have to tap intradomain routing to provide service (out of scope of NSIS - but relevant to operators willing to make use of the particular NSIS protocol as part of their solution). There may be different situations where NSIS may have to transport some kind of address information only relevant to adjacent NSIS signaling units. That's why the designers of an NSIS protocol must describe, whether and how admission control for the services supported by their signaling protocol is influenced by routing. Regards, Rüdiger > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Thursday, May 02, 2002 11:46 AM > To: Geib, Ruediger > Cc: nsis@ietf.org > Subject: Re: Admission control relevant routing information > > > Ruediger, > > I think I have understood your point. However, we added an assumption > saying, that a NSIS protocol user already knows about the > service types > before the nsis protocol even starts. And we do not specify > how this is > achieved (e.g. by web page, in the customer-provider contract, etc.) > > What I am not sure about is what exactly you mean by > admission control > model how is it different from a part of the service > definition (service > model)? > > Marcus > > --On Thursday, May 02, 2002 10:50 AM +0200 "Geib, Ruediger" > wrote: > > > Dear Markus, > > > > I'd like to suggest the following requirement to be added to the > > requirements draft. > > > > 5.8.11 The QoS signaling protocol must specify which model > of admission > > control it is supporting and whether and which adress > information has to > > be carried by it. QoS service provisioning may depend on > service type and > > provider philosophy. A purely qualitative service may not require > > definition of a specific destination being serviced. In contrast, a > > resource intensive real time service may require detailed > information on > > the route of the traffic for the purpose of admission > control. In the > > latter case, the NSIS protocol may e.g. have to transport IP address > > information of some kind between adjacent QC nodes. An NSIS > protocol must > > therefore specify, whether and how IP routing is relevant > to the service > > supported. > > > > I hope it's getting clear what I mean. If somebody is able > to provide a > > more comprehensive explanation, go ahead. > > > > Regards, Rüdiger > > > > > > Rüdiger Geib > > Senior Expert > > T-Systems Nova GmbH > > Technologiezentrum > > Am Kavalleriesand 3, 64295 Darmstadt > > Germany > > Fon: +49 6151 832138 > > Fax: +49 6151 838103 > > mailto:Ruediger.Geib@t-systems.com > > http://www.t-nova.de > > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 06:35:16 2002 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 GAA09273 for ; Thu, 2 May 2002 06:35:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26156 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 06:35:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25054; Thu, 2 May 2002 06:19:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25023 for ; Thu, 2 May 2002 06:19:00 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07373 for ; Thu, 2 May 2002 06:18:56 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g42AJxL86205; Thu, 2 May 2002 12:19:59 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id D97FAC051; Thu, 2 May 2002 12:16:30 +0200 (CEST) Date: Thu, 02 May 2002 12:28:06 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Geib, Ruediger" Cc: nsis@ietf.org Message-ID: <7564727.1020342486@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA25024 Subject: [NSIS] RE: Admission control relevant routing information Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Ruediger, The question remains, and I think we will discuss it further quite some time. At the last IETF, people did not want to specify service specific information in NSIS WG, but somewhere else, but look into the req for the protocol itself. Actually, I am in process to remove many requirements being concerned with service-specific paramters etc. Now don't you think that information about admision control is service-specific? Or is your concern the routing of the signaling messages itself? But this has not necessarly to do with admission control, but might be service-specific. If the routing of signaling messages is service-specific, I think we need to add a requirement saying that the protocol must deal with this. And I fully agree that IP addresses need to be transported with NSIS, but my current feeling is it will be transported in the service-specific part of the messages. And we still have a requirement telling that the NSIS protocol needs to be independent of the provisioning (configuration) of the network and I would regard admission control at least partly in the that scope. Marcus --On Thursday, May 02, 2002 11:56 AM +0200 "Geib, Ruediger" wrote: > Hello Marcus, > > let's take the example of RSVP: the RSVP node must store the IP address > of the prior RSVP signaling node in order to provide the service > requested. > > let's take a centralized system supporting RSVP in a diffserv cloud: it > must know by which gateway a specific RSVP reservation entered in order > to provide the requested service. Note that the centralized unit may have > to tap intradomain routing to provide service (out of scope of NSIS - but > relevant to operators willing to make use of the particular NSIS protocol > as part of their solution). > > There may be different situations where NSIS may have to transport some > kind of address information only relevant to adjacent NSIS signaling > units. That's why the designers of an NSIS protocol must describe, > whether and how admission control for the services supported by their > signaling protocol is influenced by routing. > > Regards, Rüdiger > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: Thursday, May 02, 2002 11:46 AM >> To: Geib, Ruediger >> Cc: nsis@ietf.org >> Subject: Re: Admission control relevant routing information >> >> >> Ruediger, >> >> I think I have understood your point. However, we added an assumption >> saying, that a NSIS protocol user already knows about the >> service types >> before the nsis protocol even starts. And we do not specify >> how this is >> achieved (e.g. by web page, in the customer-provider contract, etc.) >> >> What I am not sure about is what exactly you mean by >> admission control >> model how is it different from a part of the service >> definition (service >> model)? >> >> Marcus >> >> --On Thursday, May 02, 2002 10:50 AM +0200 "Geib, Ruediger" >> wrote: >> >> > Dear Markus, >> > >> > I'd like to suggest the following requirement to be added to the >> > requirements draft. >> > >> > 5.8.11 The QoS signaling protocol must specify which model >> of admission >> > control it is supporting and whether and which adress >> information has to >> > be carried by it. QoS service provisioning may depend on >> service type and >> > provider philosophy. A purely qualitative service may not require >> > definition of a specific destination being serviced. In contrast, a >> > resource intensive real time service may require detailed >> information on >> > the route of the traffic for the purpose of admission >> control. In the >> > latter case, the NSIS protocol may e.g. have to transport IP address >> > information of some kind between adjacent QC nodes. An NSIS >> protocol must >> > therefore specify, whether and how IP routing is relevant >> to the service >> > supported. >> > >> > I hope it's getting clear what I mean. If somebody is able >> to provide a >> > more comprehensive explanation, go ahead. >> > >> > Regards, Rüdiger >> > >> > >> > Rüdiger Geib >> > Senior Expert >> > T-Systems Nova GmbH >> > Technologiezentrum >> > Am Kavalleriesand 3, 64295 Darmstadt >> > Germany >> > Fon: +49 6151 832138 >> > Fax: +49 6151 838103 >> > mailto:Ruediger.Geib@t-systems.com >> > http://www.t-nova.de >> > >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 06:36:28 2002 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 GAA09395 for ; Thu, 2 May 2002 06:36:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26209 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 06:36:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26011; Thu, 2 May 2002 06:31:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25983 for ; Thu, 2 May 2002 06:31:54 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09060 for ; Thu, 2 May 2002 06:31:50 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 12:30:12 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 12:31:22 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Date: Thu, 2 May 2002 12:31:20 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA25984 Subject: [NSIS] RE: Admission control relevant routing information Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Marcus, > Now don't you think that information about admision control is > service-specific? Yes, it's of service specific nature. > Or is your concern the routing of the > signaling messages itself? No. Certainly not. > And I fully agree that IP addresses need to be transported > with NSIS, but my current feeling is it will be transported > in the service-specific part of the messages. Then my requirement is one on the service specific part. I'm however not having a particular service in mind. My requirement is more of a fundamental issue (there are many others currently in the draft like relation to AAA, IPsec and so on). I'll wait to see the next version of the draft then. Do you also collect the service specific requirements or is all of that going to the dustbin? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 06:50:39 2002 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 GAA10527 for ; Thu, 2 May 2002 06:50:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26673 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 06:50:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26456; Thu, 2 May 2002 06:43:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26426 for ; Thu, 2 May 2002 06:43:10 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09990 for ; Thu, 2 May 2002 06:43:06 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g42Ai9L86317; Thu, 2 May 2002 12:44:09 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 1BC52C051; Thu, 2 May 2002 12:40:47 +0200 (CEST) Date: Thu, 02 May 2002 12:52:23 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Geib, Ruediger" Cc: nsis@ietf.org Message-ID: <9021151.1020343943@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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] routing of signaling messages (was RE: Admission control relevant routing information) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit >> Or is your concern the routing of the >> signaling messages itself? > > No. Certainly not. > Do you or somebody else has an opinion on that? Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 06:55:07 2002 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 GAA10832 for ; Thu, 2 May 2002 06:55:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26814 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 06:55:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26388; Thu, 2 May 2002 06:41:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26359 for ; Thu, 2 May 2002 06:41:48 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09901 for ; Thu, 2 May 2002 06:41:45 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g42AglL86313; Thu, 2 May 2002 12:42:47 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 5D2AAC051; Thu, 2 May 2002 12:39:24 +0200 (CEST) Date: Thu, 02 May 2002 12:51:00 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Geib, Ruediger" Cc: nsis@ietf.org Message-ID: <8938442.1020343860@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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: Admission control relevant routing information Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit >> And I fully agree that IP addresses need to be transported >> with NSIS, but my current feeling is it will be transported >> in the service-specific part of the messages. > > Then my requirement is one on the service specific part. I'm however not > having a particular service in mind. My requirement is more of a > fundamental issue (there are many others currently in the draft like > relation to AAA, IPsec and so on). I'll wait to see the next version of > the draft then. Do you also collect the service specific requirements or > is all of that going to the dustbin? Is currently going into /dev/null, but might actually be a good idea to keep them in a seperate draft. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 06:56:20 2002 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 GAA10922 for ; Thu, 2 May 2002 06:56:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26839 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 06:56:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26736; Thu, 2 May 2002 06:51:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26701 for ; Thu, 2 May 2002 06:51:38 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10636 for ; Thu, 2 May 2002 06:51:34 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g42AqcL86345; Thu, 2 May 2002 12:52:38 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 19681C051; Thu, 2 May 2002 12:49:15 +0200 (CEST) Date: Thu, 02 May 2002 13:00:51 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Geib, Ruediger" Cc: nsis@ietf.org Message-ID: <9529202.1020344451@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA26702 Subject: [NSIS] Re: Operational QoS signaling protocol requirements Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Ruediger, thanks, I fully agree that operational reqs are missing. Actually, I am not that sure about the extensibility req. I got the feeling that too much extensibility is too complex and finding the right degree is very difficult, therefore I would not pose extensibility as a major req (a MAY) If I understood "5.12.6 Reliable Communication" right you do not mean reliable transport of signaling message or? Marcus --On Thursday, May 02, 2002 11:56 AM +0200 "Geib, Ruediger" wrote: > Dear Markus, > > By and large operational NSIS protocol requirements miss in the > requirements draft. I'd suggest to add: > > 5.12 Operational Stability > The design of an NSIS protocol must provide a maximum of operational > stability. The state of a unit involved into NSIS signalling must be > stable no matter what the surronding conditions are. This leads to the > following requirements: > > 5.12.1 Backwards compatibility > A later version of an NSIS protocol must be backwards compatible with > earlier versions of an NSIS protocol. > > 5.12.2 Unexpected situations and error restistance > An NSIS protocol must define behaviour of NSIS signaling units during > unexpected situations. Unexpected situtions are unknown messages, > parameters and parameter settings as well as receiption of unexpected > messages (e.g. a "Reservation Confirmation" without prior "Reservation > Request"). > > 5.12.3 Default behaviour > An NSIS protocol must define default behaviours and parameter settings > wherever applicable. > > 5.12.4 Extendability > An NSIS protocol must provide means to enhance a protocol with future > procedures, messages, parameters and parameter settings. > > 5.12.5 Preventation of stale state > An NSIS signalling protocol must provide means for an NSIS signaling unit > to discover and remove local stale state. This may for example be done by > means like soft state and periodic flooding or by a polling mechanism and > hard state signaling. > > 5.12.6 Reliable Communication > NSIS signaling procedures, connectivity between units involved in NSIS > signaling as well as the basic transport protocol used by NSIS must > provide a maximum of communication reliability. Procedures must define > how an NSIS signaling systems behaves if some kind of request it sent > stays without answer (this could require e.g. be timers, number of > message retransmits and release messages). An NSIS signaling unit must > be able to check its connectivity to an adjacent NSIS signaling unit at > any time (this requirement must however not result in a DoS attack tool - > the frequency of these checks must be limited, and flow control may be > useful). The basic transport protocol to be used between adjacent NSIS > units must ensure message integrity and reliable transport. > > 5.12.7 Smooth breakdown > A unit participating in NSIS signaling must no cause further damage to > other systems involved in NSIS signaling when it has to go out of service. > > Regards, Rüdiger > > > Rüdiger Geib > Senior Expert > T-Systems Nova GmbH > Technologiezentrum > Am Kavalleriesand 3, 64295 Darmstadt > Germany > Fon: +49 6151 832138 > Fax: +49 6151 838103 > mailto:Ruediger.Geib@t-systems.com > http://www.t-nova.de > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 07:06:05 2002 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 HAA11517 for ; Thu, 2 May 2002 07:06:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA27779 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 07:06:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26643; Thu, 2 May 2002 06:49:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26612 for ; Thu, 2 May 2002 06:49:44 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10463 for ; Thu, 2 May 2002 06:49:41 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 12:48:02 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 12:49:12 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Date: Thu, 2 May 2002 12:49:11 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA26613 Subject: [NSIS] RE: routing of signaling messages (was RE: Admission control rele vant routing information) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit > >> Or is your concern the routing of the > >> signaling messages itself? > > > > No. Certainly not. > > > > Do you or somebody else has an opinion on that? My personal view is that reliable transmission is most important. Routing of signaling messages doesn't have to be real time, it may be in band, and it must not require an own routing protocol (i.e. a routing protocol only to transmit signaling). Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 07:21:50 2002 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 HAA12650 for ; Thu, 2 May 2002 07:21:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA28319 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 07:21:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27712; Thu, 2 May 2002 07:04:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27626 for ; Thu, 2 May 2002 07:04:24 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11420 for ; Thu, 2 May 2002 07:04:20 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 13:02:41 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 13:03:51 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Date: Thu, 2 May 2002 13:03:50 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA27627 Subject: [NSIS] RE: Operational QoS signaling protocol requirements Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Marcus > Actually, I am not that sure about the extensibility req. I > got the feeling that too much extensibility is too complex > and finding the right degree is very difficult, therefore > I would not pose extensibility as a major req (a MAY) If there's a basic protocoll and a service specific one, then the service specific one is a major extension. If NSIS is going to build this, then the service specific protocol would have to be extensible. The basic protocol must be stable. The basic protocol is just ruling some generic and always recurring dialogue types. If that is the direction NSIS is taking now, I agree - extensibility must be built into the service specific part of the protocol, not into the basic protocol. > If I understood "5.12.6 Reliable Communication" right you do not mean > reliable transport of signaling message or? I also mean reliable transport of the signalling message. They must arrive at their destination as they were sent. I don't look at real-time transmission beeing a critical requirement for signaling message transfer. I'd prefer to waste some milliseconds if that ensures error- and loss free transmission of signaling information. Regards, Rüdiger > --On Thursday, May 02, 2002 11:56 AM +0200 "Geib, Ruediger" > wrote: > > > Dear Markus, > > > > By and large operational NSIS protocol requirements miss in the > > requirements draft. I'd suggest to add: > > > > 5.12 Operational Stability > > The design of an NSIS protocol must provide a maximum of operational > > stability. The state of a unit involved into NSIS signalling must be > > stable no matter what the surronding conditions are. This > leads to the > > following requirements: > > > > 5.12.1 Backwards compatibility > > A later version of an NSIS protocol must be backwards > compatible with > > earlier versions of an NSIS protocol. > > > > 5.12.2 Unexpected situations and error restistance > > An NSIS protocol must define behaviour of NSIS signaling > units during > > unexpected situations. Unexpected situtions are unknown messages, > > parameters and parameter settings as well as receiption of > unexpected > > messages (e.g. a "Reservation Confirmation" without prior > "Reservation > > Request"). > > > > 5.12.3 Default behaviour > > An NSIS protocol must define default behaviours and > parameter settings > > wherever applicable. > > > > 5.12.4 Extendability > > An NSIS protocol must provide means to enhance a protocol > with future > > procedures, messages, parameters and parameter settings. > > > > 5.12.5 Preventation of stale state > > An NSIS signalling protocol must provide means for an NSIS > signaling unit > > to discover and remove local stale state. This may for > example be done by > > means like soft state and periodic flooding or by a polling > mechanism and > > hard state signaling. > > > > 5.12.6 Reliable Communication > > NSIS signaling procedures, connectivity between units > involved in NSIS > > signaling as well as the basic transport protocol used by NSIS must > > provide a maximum of communication reliability. Procedures > must define > > how an NSIS signaling systems behaves if some kind of > request it sent > > stays without answer (this could require e.g. be timers, number of > > message retransmits and release messages). An NSIS > signaling unit must > > be able to check its connectivity to an adjacent NSIS > signaling unit at > > any time (this requirement must however not result in a DoS > attack tool - > > the frequency of these checks must be limited, and flow > control may be > > useful). The basic transport protocol to be used between > adjacent NSIS > > units must ensure message integrity and reliable transport. > > > > 5.12.7 Smooth breakdown > > A unit participating in NSIS signaling must no cause > further damage to > > other systems involved in NSIS signaling when it has to go > out of service. > > > > Regards, Rüdiger > > > > > > Rüdiger Geib > > Senior Expert > > T-Systems Nova GmbH > > Technologiezentrum > > Am Kavalleriesand 3, 64295 Darmstadt > > Germany > > Fon: +49 6151 832138 > > Fax: +49 6151 838103 > > mailto:Ruediger.Geib@t-systems.com > > http://www.t-nova.de > > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 07:23:49 2002 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 HAA12831 for ; Thu, 2 May 2002 07:23:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA28465 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 07:23:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28052; Thu, 2 May 2002 07:11:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28019 for ; Thu, 2 May 2002 07:11:14 -0400 (EDT) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11861 for ; Thu, 2 May 2002 07:11:10 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 173EUS-0001bV-00; Thu, 02 May 2002 13:11:13 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 173EUS-0000B7-00; Thu, 02 May 2002 13:11:12 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g42BBC106875; Thu, 2 May 2002 13:11:12 +0200 Message-Id: <200205021111.g42BBC106875@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: "Geib, Ruediger" cc: brunner@ccrle.nec.de, nsis@ietf.org Subject: Re: [NSIS] RE: Admission control relevant routing information In-Reply-To: Message from "Geib, Ruediger" of "Thu, 02 May 2002 11:56:52 +0200." References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 02 May 2002 13:11:12 +0200 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Ruediger, I fully understand your requirement, but I don't think that the protocol has to specify the underlying admission control model. The real requirement seems to be: the protocol should be able to carry a great variety of address information objects, such as IPv4/v6 host addresses, IP network addresses, IP addresses + ports, AS numbers, etc. If there is a possibility in the signaling protocol to carry address information of the ingress node/router in request messages, it should match your requirement. If this address information is considered optional, we are independent of the actual admission control model. Regards, Roland > let's take the example of RSVP: the RSVP node must store the IP address of the prior RSVP signaling node in order to provide the service requested. > > let's take a centralized system supporting RSVP in a diffserv cloud: it must know by which gateway a specific RSVP reservation entered in order to provide the requested service. Note that the centralized unit may have to tap intradomain routing to provide service (out of scope of NSIS - but relevant to operators willing to make use of the particular NSIS protocol as part of their solution). > > There may be different situations where NSIS may have to transport some kind of address information only relevant to adjacent NSIS signaling units. That's why the designers of an NSIS protocol must describe, whether and how admission control for the services supported by their signaling protocol is influenced by routing. > > Regards, Rüdiger > > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: Thursday, May 02, 2002 11:46 AM > > To: Geib, Ruediger > > Cc: nsis@ietf.org > > Subject: Re: Admission control relevant routing information > > > > > > Ruediger, > > > > I think I have understood your point. However, we added an assumption > > saying, that a NSIS protocol user already knows about the > > service types > > before the nsis protocol even starts. And we do not specify > > how this is > > achieved (e.g. by web page, in the customer-provider contract, etc.) > > > > What I am not sure about is what exactly you mean by > > admission control > > model how is it different from a part of the service > > definition (service > > model)? > > > > Marcus > > > > --On Thursday, May 02, 2002 10:50 AM +0200 "Geib, Ruediger" > > wrote: > > > > > Dear Markus, > > > > > > I'd like to suggest the following requirement to be added to the > > > requirements draft. > > > > > > 5.8.11 The QoS signaling protocol must specify which model > > of admission > > > control it is supporting and whether and which adress > > information has to > > > be carried by it. QoS service provisioning may depend on > > service type and > > > provider philosophy. A purely qualitative service may not require > > > definition of a specific destination being serviced. In contrast, a > > > resource intensive real time service may require detailed > > information on > > > the route of the traffic for the purpose of admission > > control. In the > > > latter case, the NSIS protocol may e.g. have to transport IP address > > > information of some kind between adjacent QC nodes. An NSIS > > protocol must > > > therefore specify, whether and how IP routing is relevant > > to the service > > > supported. > > > > > > I hope it's getting clear what I mean. If somebody is able > > to provide a > > > more comprehensive explanation, go ahead. > > > > > > Regards, Rüdiger > > > > > > > > > Rüdiger Geib > > > Senior Expert > > > T-Systems Nova GmbH > > > Technologiezentrum > > > Am Kavalleriesand 3, 64295 Darmstadt > > > Germany > > > Fon: +49 6151 832138 > > > Fax: +49 6151 838103 > > > mailto:Ruediger.Geib@t-systems.com > > > http://www.t-nova.de > > > > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 07:43:44 2002 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 HAA14488 for ; Thu, 2 May 2002 07:43:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA29650 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 07:43:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28701; Thu, 2 May 2002 07:27:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28670 for ; Thu, 2 May 2002 07:27:33 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13294 for ; Thu, 2 May 2002 07:27:29 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 13:25:49 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 13:27:00 +0200 Message-Id: From: "Geib, Ruediger" To: bless@tm.uka.de Cc: brunner@ccrle.nec.de, nsis@ietf.org Subject: [NSIS] RE: Admission control relevant routing information Date: Thu, 2 May 2002 13:26: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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA28671 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Roland > I fully understand your requirement, but I don't think that > the protocol has to specify the underlying admission > control model. That's not quite what I expect. The developres of a signaling protocol should however have a rationale which types of QoS admission control could be supported by the protocol they defined. > The real requirement seems to be: the protocol should be > able to carry a great variety of address information > objects, such as IPv4/v6 host addresses, IP network > addresses, IP addresses + ports, AS numbers, etc. If > there is a possibility in the signaling protocol to > carry address information of the ingress node/router > in request messages, it should match your requirement. Yes, that's the basisic requirement. > If this address information is considered optional, > we are independent of the actual admission control model. I'm not sure. The more service specific we get, the closer we come to a mandatory requirement whether or not to provide which address information. NSIS doesn't specify the services and their admission control. It should provide a discussion on how to make use of a protocol. I wouldn't like a situation where two domains can't interoperate because one doesn't transmit the optional address information the other domain requires to do admission control. I'd suggest to stop the discussion on the latter now. It's to far from todays NSIS issues. Above formulation to allow NSIS to carry a variety of address information seems sufficient by now. Regards, Rüdiger > > > let's take the example of RSVP: the RSVP node must store > the IP address of the prior RSVP signaling node in order to > provide the service requested. > > > > let's take a centralized system supporting RSVP in a > diffserv cloud: it must know by which gateway a specific RSVP > reservation entered in order to provide the requested > service. Note that the centralized unit may have to tap > intradomain routing to provide service (out of scope of NSIS > - but relevant to operators willing to make use of the > particular NSIS protocol as part of their solution). > > > > There may be different situations where NSIS may have to > transport some kind of address information only relevant to > adjacent NSIS signaling units. That's why the designers of an > NSIS protocol must describe, whether and how admission > control for the services supported by their signaling > protocol is influenced by routing. > > > > Regards, Rüdiger > > > > > -----Original Message----- > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > Sent: Thursday, May 02, 2002 11:46 AM > > > To: Geib, Ruediger > > > Cc: nsis@ietf.org > > > Subject: Re: Admission control relevant routing information > > > > > > > > > Ruediger, > > > > > > I think I have understood your point. However, we added > an assumption > > > saying, that a NSIS protocol user already knows about the > > > service types > > > before the nsis protocol even starts. And we do not specify > > > how this is > > > achieved (e.g. by web page, in the customer-provider > contract, etc.) > > > > > > What I am not sure about is what exactly you mean by > > > admission control > > > model how is it different from a part of the service > > > definition (service > > > model)? > > > > > > Marcus > > > > > > --On Thursday, May 02, 2002 10:50 AM +0200 "Geib, Ruediger" > > > wrote: > > > > > > > Dear Markus, > > > > > > > > I'd like to suggest the following requirement to be added to the > > > > requirements draft. > > > > > > > > 5.8.11 The QoS signaling protocol must specify which model > > > of admission > > > > control it is supporting and whether and which adress > > > information has to > > > > be carried by it. QoS service provisioning may depend on > > > service type and > > > > provider philosophy. A purely qualitative service may > not require > > > > definition of a specific destination being serviced. In > contrast, a > > > > resource intensive real time service may require detailed > > > information on > > > > the route of the traffic for the purpose of admission > > > control. In the > > > > latter case, the NSIS protocol may e.g. have to > transport IP address > > > > information of some kind between adjacent QC nodes. An NSIS > > > protocol must > > > > therefore specify, whether and how IP routing is relevant > > > to the service > > > > supported. > > > > > > > > I hope it's getting clear what I mean. If somebody is able > > > to provide a > > > > more comprehensive explanation, go ahead. > > > > > > > > Regards, Rüdiger > > > > > > > > > > > > Rüdiger Geib > > > > Senior Expert > > > > T-Systems Nova GmbH > > > > Technologiezentrum > > > > Am Kavalleriesand 3, 64295 Darmstadt > > > > Germany > > > > Fon: +49 6151 832138 > > > > Fax: +49 6151 838103 > > > > mailto:Ruediger.Geib@t-systems.com > > > > http://www.t-nova.de > > > > > > > > > > > > > > > > -------------------------------------- > > > Dr. Marcus Brunner > > > Network Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > personal home page: http://www.brubers.org/marcus > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > -- > Roland Bless -- e-Mail: bless@tm.uka.de > Institute of Telematics, University of Karlsruhe, Germany > Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 > Phone: +49 721 608-6413 Fax: +49 721 388097 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 08:42:54 2002 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 IAA19573 for ; Thu, 2 May 2002 08:42:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03482 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 08:42:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03181; Thu, 2 May 2002 08:34:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03148 for ; Thu, 2 May 2002 08:33:57 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18664 for ; Thu, 2 May 2002 08:33:52 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g42CYuL86644; Thu, 2 May 2002 14:34:56 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 4C705C051; Thu, 2 May 2002 14:31:33 +0200 (CEST) Date: Thu, 02 May 2002 14:43:09 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Madjid.Nakhjiri@motorola.com Cc: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] refreshes Message-ID: <15667779.1020350589@[192.168.102.79]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FE0@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FE0@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Refreshes in RSVP are used for several thing at the same time: - state garbage handling - error behaviour - deal with route changes etc. So they are a solution for those problems. MArcus --On Thursday, April 25, 2002 6:51 AM +0300 john.loughney@nokia.com wrote: > Hi Madjid, > >> Well, it depends if you see reliability is a requirement or >> a solution. > > Reliablility is reliability. Refreshes can be used to achieve > reliability, so therefor it is a solution. > > John > > _______________________________________________ > 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/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:05:01 2002 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 JAA21474 for ; Thu, 2 May 2002 09:05:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05323 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:05:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04191; Thu, 2 May 2002 08:58:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04154 for ; Thu, 2 May 2002 08:58:20 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20899 for ; Thu, 2 May 2002 08:58:14 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42CwH0E013295 for ; Thu, 2 May 2002 14:58:17 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 02 14:58:16 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 14:55:41 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Geib, Ruediger'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] Admission control relevant routing information Date: Thu, 2 May 2002 14:57: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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Geib Please receive my comments in line! >> 5.8.11 The QoS signaling protocol must specify which model of >> admission control it is supporting and whether and which adress >> information has to be carried by it. >> QoS service provisioning may depend on service type and provider >> philosophy. A purely qualitative service may not require definition >> of a specific destination being serviced. In contrast, a resource >> intensive real time service may require detailed information >> on the route of the traffic for the purpose of admission control. >> In the latter case, the NSIS protocol may e.g. have to transport >> IP address information of some kind between adjacent QC nodes. >> An NSIS protocol must therefore specify, whether and how IP routing >> is relevant to the service supported. How a QoS initiator could specify the admission control mechanisms, since different parts of the network and during the same session (flow) might use different types of admission control mechanisms, or they will not use any admission control at all! This is an issue that should be left over to network providers. Moreover, regarding IP routing, how a QoS initiator (sender) will be able to know what kind of IP routing is used by a network provider? Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:05:34 2002 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 JAA21538 for ; Thu, 2 May 2002 09:05:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05362 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:05:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03784; Thu, 2 May 2002 08:49:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03752 for ; Thu, 2 May 2002 08:49:26 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20091 for ; Thu, 2 May 2002 08:49:21 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42CnN0E008065 for ; Thu, 2 May 2002 14:49:23 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 02 14:48:43 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 14:46:08 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Geib, Ruediger'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] Operational QoS signaling protocol requirements Date: Thu, 2 May 2002 14:48:38 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Geib Please receive my comments in line. >> 5.12 Operational Stability >> The design of an NSIS protocol must provide a maximum of >> operational stability. The state of a unit involved into NSIS >> signalling must be stable no matter what the surronding >> conditions are. This leads to the following requirements: I think that Operational stability is closer to the implementation process!! >> 5.12.1 Backwards compatibility >> A later version of an NSIS protocol must be backwards >> compatible with earlier versions of an NSIS protocol. I think that this requirement might be useful, but in my opinion it could be included in Section 5.1; >> 5.12.2 Unexpected situations and error restistance >> An NSIS protocol must define behaviour of NSIS signaling units >> during unexpected situations. Unexpected situtions are >> unknown messages, >> parameters and parameter settings as well as receiption >> of unexpected messages (e.g. a "Reservation Confirmation" >> without prior "Reservation Request"). This requirement is somehow similar to Open issues (53) and requirement 5.3.4. Moreover this requirement is emphasizing to many details that might not be necessary! >> 5.12.3 Default behaviour >> An NSIS protocol must define default behaviours and parameter >> settings wherever applicable. What do you mean wherever applicable? Is this service specific? >> 5.12.4 Extendability >> An NSIS protocol must provide means to enhance a >> protocol with future procedures, messages, parameters >> and parameter settings. Maybe this requirement could be a part of the modularity requirement 5.1.3! >> 5.12.5 Preventation of stale state >> An NSIS signalling protocol must provide means for an NSIS >> signaling unit to discover and remove local stale state. >> This may for example be done by means like soft state >> and periodic flooding or by a polling mechanism and hard state signaling. I do not understand this requirement! maybe we could just add a sentence in Section 5.3.1 about the soft state release of resources! I thought we had specified that somewhere! >> 5.12.6 Reliable Communication >> NSIS signaling procedures, connectivity between units >> involved in NSIS signaling as well as the basic >> transport protocol used by NSIS must provide a maximum >> of communication reliability. Procedures must define >> how an NSIS signaling systems behaves if some >> kind of request it sent stays without >> answer (this could require e.g. be timers, >> number of message retransmits and release messages). >> An NSIS signaling unit must be able to check its connectivity >> to an adjacent NSIS signaling unit at any time (this requirement >> must however not result in a DoS attack tool - the frequency >> of these checks must be limited, and flow control may be useful). >> The basic transport protocol to be used between adjacent >> NSIS units must ensure message integrity and reliable transport. I think that this requirement is embedded into Section 5.8. >> 5.12.7 Smooth breakdown >> A unit participating in NSIS signaling must no cause further >> damage to other systems involved in NSIS signaling when it >> has to go out of service. Is this a NSIS protocol requirement? Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:21:46 2002 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 JAA23049 for ; Thu, 2 May 2002 09:21:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06238 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:21:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04442; Thu, 2 May 2002 08:59:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04404 for ; Thu, 2 May 2002 08:59:24 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20985 for ; Thu, 2 May 2002 08:59:15 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g42Cwj839440; Thu, 2 May 2002 14:58:45 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA25177; Thu, 2 May 2002 14:56:53 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C58782EF0B; Thu, 2 May 2002 14:56:52 +0200 (CEST) Date: Thu, 02 May 2002 15:08:29 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" , "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] Operational QoS signaling protocol requirements Message-ID: <17187554.1020352109@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Thursday, May 02, 2002 2:48 PM +0200 "Georgios Karagiannis (ELN)" wrote: >>> 5.12.5 Preventation of stale state >>> An NSIS signalling protocol must provide means for an NSIS >>> signaling unit to discover and remove local stale state. >>> This may for example be done by means like soft state >>> and periodic flooding or by a polling mechanism and hard state >>> signaling. > > I do not understand this requirement! > maybe we could just add a sentence in Section 5.3.1 about the soft state > release of resources! > I thought we had specified that somewhere! I think we are not requiring soft state, but soft stateis a solution to that requirement I think. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:23:35 2002 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 JAA23205 for ; Thu, 2 May 2002 09:23:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06364 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:23:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05550; Thu, 2 May 2002 09:09:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05521 for ; Thu, 2 May 2002 09:09:35 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21887 for ; Thu, 2 May 2002 09:09:29 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g42D8v840127; Thu, 2 May 2002 15:08:57 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA25332; Thu, 2 May 2002 15:07:04 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EF36B43DCA; Thu, 2 May 2002 15:07:03 +0200 (CEST) Date: Thu, 02 May 2002 15:18:41 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (1) included in draft-ietf-nsis-req-01.txt Message-ID: <17799294.1020352721@[192.168.102.79]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FB5@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FB5@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Georgios, Could you explain, what is special on the VPN scenario, that we have not covered in the scenarios already. There might be a difference in servicespecification, but I don't see a fundamental difference in the NSIS protocol, nor any additional requirements. Marcus --On Monday, April 22, 2002 4:32 PM +0300 john.loughney@nokia.com wrote: > Hi Georgios, > >> > 1) (OPEN) add Scenarios >> > Do we need to add, remove, or change the scenarios? >> > - added scenario on QoS signalling between PSTN gateways and >> > backbone routers >> > - added: Application request end-to-end QoS path from the network >> > We can what ever scenario we want. The more the better to >> understand >> > the issues. Nevertheless, we have to take care that we are future >> > prove as well. >> >> [GK] Agree with these additions. I would very much appreciate >> if you could >> [GK] add also the following scenario (Section 3.4 of >> [GK] draft-partain-nsis-requirements-00.txt): >> >> "QoS for Virtual Private Networks >> >> There are two types of L3 VPNs, distinguished by where the endpoints >> of the tunnels exist. The endpoints of the tunnels may either be on >> the customer (CPE), or the provider equipment or provider edge (PE). >> >> Virtual Private networks are also likely to request bandwidth for >> Assured Forwarding style services in addition to the Expedited >> Forwarding services the PSTN GW are likely to use." > > I'm not so sure this is within out charter. I think we need more > justification before adding this to the draft. > > John -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:26:24 2002 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 JAA23420 for ; Thu, 2 May 2002 09:26:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06521 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:26:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05219; Thu, 2 May 2002 09:04:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05179 for ; Thu, 2 May 2002 09:03:57 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21375 for ; Thu, 2 May 2002 09:03:52 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42D3t0E016176 for ; Thu, 2 May 2002 15:03:55 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Thu May 02 15:03:54 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22815HQ2>; Thu, 2 May 2002 15:03:54 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Geib, Ruediger'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] Errored situation signaling requirements Date: Thu, 2 May 2002 15:03:50 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Geib Please receive my comments in line! >> 5.3.2 Release after failure >> After detection of a failure or stale state, any QoS >> controller/initiator must be able to release a >> reservation it is involved in. This may require signaling >> of the "Release after Failure" message upstream as well as downstream. Is this requirement not similar to 5.3.2? >> 5.3.6 Error notification and error location >> An NSIS signaling node rejecting or releasing a reservation >> must indicate its identity. NSIS signalling should indicate >> why a requested resource is not or no longer available. Is this not similar to Requirement 5.3.4 and open issue (53)! >> (5.3.7 Explicit request of resources >> NSIS signaling must support the explicit request of resources.) Is this not similar to Requirement 5.3.1! best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:33:25 2002 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 JAA24107 for ; Thu, 2 May 2002 09:33:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07426 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:33:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05627; Thu, 2 May 2002 09:10:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05593 for ; Thu, 2 May 2002 09:10:50 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21980 for ; Thu, 2 May 2002 09:10:45 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 15:09:03 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 15:10:14 +0200 Message-Id: From: "Geib, Ruediger" To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Operational QoS signaling protocol requirements Date: Thu, 2 May 2002 15:10:13 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Thanks Marcus, you made the point. > >>> 5.12.5 Preventation of stale state > >>> An NSIS signalling protocol must provide means for an NSIS > >>> signaling unit to discover and remove local stale state. > >>> This may for example be done by means like soft state > >>> and periodic flooding or by a polling mechanism and hard state > >>> signaling. > > Georgios: > > I do not understand this requirement! > > maybe we could just add a sentence in Section 5.3.1 about > > the soft state release of resources! > > I thought we had specified that somewhere! > Marcus said: > I think we are not requiring soft state, but soft state is a > solution to that requirement I think. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:36:33 2002 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 JAA24474 for ; Thu, 2 May 2002 09:36:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07552 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:36:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06279; Thu, 2 May 2002 09:22:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06251 for ; Thu, 2 May 2002 09:22:12 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23093 for ; Thu, 2 May 2002 09:22:08 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 15:20:29 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 15:21:39 +0200 Message-Id: From: "Geib, Ruediger" To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Errored situation signaling requirements Date: Thu, 2 May 2002 15:21:37 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA06252 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Georgios Comments in line. Regards, Rüdiger R >> 5.3.2 Release after failure R >> After detection of a failure or stale state, any QoS R >> controller/initiator must be able to release a R >> reservation it is involved in. This may require signaling R >> of the "Release after Failure" message upstream as well as R >> downstream. > G> Is this requirement not similar to 5.3.2? Exactly. Your interpretation that I suggest to replace 5.3.2 with this text is correct. Note that I numbered it as "5.3.2". R >> 5.3.6 Error notification and error location R >> An NSIS signaling node rejecting or releasing a reservation R >> must indicate its identity. NSIS signalling should indicate R >> why a requested resource is not or no longer available. > G> Is this not similar to Requirement 5.3.4 and open issue (53)! I'd like to repeat 3.4: "Prompt notification of QoS violation in case of error / failure to QoS Initiator and QoS Controller." QoS violation / failure happens on the data plane. My suggestion for 5.3.6 is about problems on the control plane. R >> (5.3.7 Explicit request of resources R >> NSIS signaling must support the explicit request of resources.) > G> Is this not similar to Requirement 5.3.1! 5.3.1 is: Explicit release of resources. My suggestion is about establishment of resources. I can see a difference. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:41:12 2002 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 JAA24951 for ; Thu, 2 May 2002 09:41:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07757 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:41:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06669; Thu, 2 May 2002 09:28:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06581 for ; Thu, 2 May 2002 09:28:19 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23614 for ; Thu, 2 May 2002 09:28:14 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42DSG0E000093 for ; Thu, 2 May 2002 15:28:16 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Thu May 02 15:27:11 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 15:24:36 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, Jim Murphy , "'Ping Pan'" Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (1) included in draft-ietf-nsis-req-01. txt Date: Thu, 2 May 2002 15:27:08 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus I think that is better if this question is answered by Jim Murphy or Ping Pan, since they have written it! Best Regards, Georgios -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: donderdag 2 mei 2002 15:19 To: john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (1) included in draft-ietf-nsis-req-01.txt Georgios, Could you explain, what is special on the VPN scenario, that we have not covered in the scenarios already. There might be a difference in servicespecification, but I don't see a fundamental difference in the NSIS protocol, nor any additional requirements. Marcus --On Monday, April 22, 2002 4:32 PM +0300 john.loughney@nokia.com wrote: > Hi Georgios, > >> > 1) (OPEN) add Scenarios >> > Do we need to add, remove, or change the scenarios? >> > - added scenario on QoS signalling between PSTN gateways and >> > backbone routers >> > - added: Application request end-to-end QoS path from the network >> > We can what ever scenario we want. The more the better to >> understand >> > the issues. Nevertheless, we have to take care that we are future >> > prove as well. >> >> [GK] Agree with these additions. I would very much appreciate >> if you could >> [GK] add also the following scenario (Section 3.4 of >> [GK] draft-partain-nsis-requirements-00.txt): >> >> "QoS for Virtual Private Networks >> >> There are two types of L3 VPNs, distinguished by where the endpoints >> of the tunnels exist. The endpoints of the tunnels may either be on >> the customer (CPE), or the provider equipment or provider edge (PE). >> >> Virtual Private networks are also likely to request bandwidth for >> Assured Forwarding style services in addition to the Expedited >> Forwarding services the PSTN GW are likely to use." > > I'm not so sure this is within out charter. I think we need more > justification before adding this to the draft. > > John -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:46:38 2002 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 JAA25438 for ; Thu, 2 May 2002 09:46:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08081 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:46:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06449; Thu, 2 May 2002 09:24:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06418 for ; Thu, 2 May 2002 09:24:12 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23280 for ; Thu, 2 May 2002 09:24:07 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 15:22:28 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 15:23:38 +0200 Message-Id: From: "Geib, Ruediger" To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Admission control relevant routing information Date: Thu, 2 May 2002 15:23:36 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA06419 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, my reply to Roland Bless comment on this list should clarify the point. Regards, Rüdiger > >> 5.8.11 The QoS signaling protocol must specify which model of > >> admission control it is supporting and whether and which adress > >> information has to be carried by it. > >> QoS service provisioning may depend on service type and provider > >> philosophy. A purely qualitative service may not require > definition > >> of a specific destination being serviced. In contrast, a resource > >> intensive real time service may require detailed information > >> on the route of the traffic for the purpose of admission control. > >> In the latter case, the NSIS protocol may e.g. have to transport > >> IP address information of some kind between adjacent QC nodes. > >> An NSIS protocol must therefore specify, whether and how > IP routing > >> is relevant to the service supported. > > How a QoS initiator could specify the admission control > mechanisms, since different parts > of the network and during the same session (flow) might use > different > types of admission control mechanisms, or they will not use > any admission control at all! > This is an issue that should be left over to network providers. > > Moreover, regarding IP routing, how a QoS initiator (sender) > will be able to know what kind of > IP routing is used by a network provider? > > Best Regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:50:31 2002 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 JAA25888 for ; Thu, 2 May 2002 09:50:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08286 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:50:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07940; Thu, 2 May 2002 09:45:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07907 for ; Thu, 2 May 2002 09:45:32 -0400 (EDT) Received: from fw9.telekom.de (gw9.telekom.de [62.156.152.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25338 for ; Thu, 2 May 2002 09:45:27 -0400 (EDT) Received: by fw9.telekom.de; (5.65v4.0/1.3/10May95) id AA28528; Thu, 2 May 2002 15:44:37 +0200 Received: from g8pbr.blf01.telekom.de by G8PXB.blf01.telekom.de with ESMTP; Thu, 2 May 2002 15:45:29 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 15:45:29 +0200 Message-Id: From: "Geib, Ruediger" To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Admission control relevant routing information Date: Thu, 2 May 2002 15:45:27 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA07908 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Georgios, > Sorry Geib, I have looked to your reply to the comment > of Roland Bless but it did not clarify the point I made! Please clarify which part of your comment wasn't answered by Rolands suggestion and my reply. Regards, Rüdiger > > my reply to Roland Bless comment on this list should clarify > the point. > > Regards, Rüdiger > > > >> 5.8.11 The QoS signaling protocol must specify which model of > > >> admission control it is supporting and whether and which adress > > >> information has to be carried by it. > > >> QoS service provisioning may depend on service type and provider > > >> philosophy. A purely qualitative service may not require > > definition > > >> of a specific destination being serviced. In contrast, a > resource > > >> intensive real time service may require detailed information > > >> on the route of the traffic for the purpose of admission > control. > > >> In the latter case, the NSIS protocol may e.g. have to transport > > >> IP address information of some kind between adjacent QC nodes. > > >> An NSIS protocol must therefore specify, whether and how > > IP routing > > >> is relevant to the service supported. > > > > How a QoS initiator could specify the admission control > > mechanisms, since different parts > > of the network and during the same session (flow) might use > > different > > types of admission control mechanisms, or they will not use > > any admission control at all! > > This is an issue that should be left over to network providers. > > > > Moreover, regarding IP routing, how a QoS initiator (sender) > > will be able to know what kind of > > IP routing is used by a network provider? > > > > Best Regards, > > Georgios > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 09:52:04 2002 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 JAA26037 for ; Thu, 2 May 2002 09:52:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08373 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 09:52:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07625; Thu, 2 May 2002 09:37:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07595 for ; Thu, 2 May 2002 09:37:04 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24522 for ; Thu, 2 May 2002 09:36:59 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42Db20E005460 for ; Thu, 2 May 2002 15:37:02 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 02 15:36:12 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 15:33:37 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Geib, Ruediger'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] Admission control relevant routing information Date: Thu, 2 May 2002 15:36:09 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA07596 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Geib Sorry Geib, I have looked to your reply to the comment of Roland Bless but it did not clarify the point I made! Best Regards, Georgios -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: donderdag 2 mei 2002 15:24 To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Admission control relevant routing information Hi Georgios, my reply to Roland Bless comment on this list should clarify the point. Regards, Rüdiger > >> 5.8.11 The QoS signaling protocol must specify which model of > >> admission control it is supporting and whether and which adress > >> information has to be carried by it. > >> QoS service provisioning may depend on service type and provider > >> philosophy. A purely qualitative service may not require > definition > >> of a specific destination being serviced. In contrast, a resource > >> intensive real time service may require detailed information > >> on the route of the traffic for the purpose of admission control. > >> In the latter case, the NSIS protocol may e.g. have to transport > >> IP address information of some kind between adjacent QC nodes. > >> An NSIS protocol must therefore specify, whether and how > IP routing > >> is relevant to the service supported. > > How a QoS initiator could specify the admission control > mechanisms, since different parts > of the network and during the same session (flow) might use > different > types of admission control mechanisms, or they will not use > any admission control at all! > This is an issue that should be left over to network providers. > > Moreover, regarding IP routing, how a QoS initiator (sender) > will be able to know what kind of > IP routing is used by a network provider? > > Best Regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 10:02:12 2002 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 KAA27121 for ; Thu, 2 May 2002 10:02:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09388 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 10:02:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08004; Thu, 2 May 2002 09:45:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07967 for ; Thu, 2 May 2002 09:45:46 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25358 for ; Thu, 2 May 2002 09:45:40 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g42DjB842223; Thu, 2 May 2002 15:45:11 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA25783; Thu, 2 May 2002 15:43:18 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 40D1243EBA; Thu, 2 May 2002 15:43:18 +0200 (CEST) Date: Thu, 02 May 2002 15:54:55 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01.txt Message-ID: <19973280.1020354895@[192.168.102.79]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FB6@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FB6@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Georgios, John, What is your rational behind the sender/receiver initiated reservations? What about 3rd parties? What does initation imply? On a high level perspective I don't see a reason for requiring the one or the other. Unfortunatly, this comes back to data path vs signaling path issues. The implications I see are: - an entity initating or triggering an initiation needs to be known (authentication process) or needs to pass money immediately - In practice, the initiator is the paying party (in real life this is the case in most scenarios, where one party wants to have a service from another party. Or at least the assurance that a 3rd party will pay needs to be given. - There is a tied relation to uni-directional vs bi-directional reservations Marcus --On Monday, April 22, 2002 4:34 PM +0300 john.loughney@nokia.com wrote: > Hi Marcus & Georgios, > >> Please receive my comments on Issue (2) included in the >> NSIS WG draft: draft-ietf-nsis-req-01.txt >> >> Comment on Issue (2): >> >> >> > 2) (OPEN) Sender/receiver initiation >> > What is the requirement concerning data sender or data receiver or >> > both to initiate a QoS request. >> > - does it matter who pays? >> > - terminology text added >> > open issue, what is a potential req (currently we say "both must be >> > possible") >> >> [GK] both should be possible but it should be optimized for >> sender initiated; > > I think that SHOULD is the right level of requirement for sender / > reciever driven requests. > > John -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 10:04:40 2002 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 KAA27446 for ; Thu, 2 May 2002 10:04:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09812 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 10:04:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08337; Thu, 2 May 2002 09:51:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08304 for ; Thu, 2 May 2002 09:51:05 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25940 for ; Thu, 2 May 2002 09:50:59 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g42DoW842440; Thu, 2 May 2002 15:50:32 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA25876; Thu, 2 May 2002 15:48:40 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1C60443E65; Thu, 2 May 2002 15:48:40 +0200 (CEST) Date: Thu, 02 May 2002 16:00:17 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" Cc: "'nsis@ietf.org'" Message-ID: <20295102.1020355217@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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: comments Issue (8) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit What is the value of bi-directional session setup? The cost IMO are the higher complexity in QI and QRs handling a bi-directional setup in one transaction. I think there are problems in error cases (what does it mean if one part has not been setup etc.) IMO we should exlude bi-directional setup completly. Marcus --On Monday, April 22, 2002 10:30 AM +0200 "Georgios Karagiannis (ELN)" wrote: > Hi Marcus > > Please receive my comments on Issue (8) included in the > NSIS WG draft: draft-ietf-nsis-req-01.txt > > Comment on Issue (8): > >> 8) (OPEN) bi-directional data path setup with one QoS request >> I have not seen consensus on whether to require bi-directional data >> path setup with QoS. >> - How can we actually perform bi-directional reservations when the >> forward and reverse paths are not reciprocal, with respect to >> routing topology and routing policy of network domains between >> sender and receiver? >> - The need to ensure that the return path is the same as the >> forwarding path is one of the problems with RSVP, particularly in a >> mobile environment. > > [GK] The bi-directional data path setup does not need to use the same > [GK] return path as the forwarding path. The only requirement to achieve > [GK] a bi-directional reservation is that the sender for the forwarding > path [GK] is also the receiver for the return path and that the receiver > for the [GK] forwarding path is also the sender for the return path. > [GK] Therefore, I think that the bi-directional option should not be > mandatory [GK] but at least optional; > -------------- > > > > Best regards, > Georgios > > > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 10:17:53 2002 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 KAA28802 for ; Thu, 2 May 2002 10:17:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10554 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 10:17:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09660; Thu, 2 May 2002 10:03:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09628 for ; Thu, 2 May 2002 10:03:30 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27293 for ; Thu, 2 May 2002 10:03:25 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42E3Ss7008342 for ; Thu, 2 May 2002 16:03:28 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 02 16:03:27 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 16:00:52 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01. txt Date: Thu, 2 May 2002 16:03:24 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus The sender initiated and receiver initiated terms that I was referring to are included in the terminology of the draft!! Best regards, Georgios -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: donderdag 2 mei 2002 15:55 To: john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01.txt Georgios, John, What is your rational behind the sender/receiver initiated reservations? What about 3rd parties? What does initation imply? On a high level perspective I don't see a reason for requiring the one or the other. Unfortunatly, this comes back to data path vs signaling path issues. The implications I see are: - an entity initating or triggering an initiation needs to be known (authentication process) or needs to pass money immediately - In practice, the initiator is the paying party (in real life this is the case in most scenarios, where one party wants to have a service from another party. Or at least the assurance that a 3rd party will pay needs to be given. - There is a tied relation to uni-directional vs bi-directional reservations Marcus --On Monday, April 22, 2002 4:34 PM +0300 john.loughney@nokia.com wrote: > Hi Marcus & Georgios, > >> Please receive my comments on Issue (2) included in the >> NSIS WG draft: draft-ietf-nsis-req-01.txt >> >> Comment on Issue (2): >> >> >> > 2) (OPEN) Sender/receiver initiation >> > What is the requirement concerning data sender or data receiver or >> > both to initiate a QoS request. >> > - does it matter who pays? >> > - terminology text added >> > open issue, what is a potential req (currently we say "both must be >> > possible") >> >> [GK] both should be possible but it should be optimized for >> sender initiated; > > I think that SHOULD is the right level of requirement for sender / > reciever driven requests. > > John -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 10:18:41 2002 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 KAA28910 for ; Thu, 2 May 2002 10:18:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10665 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 10:18:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08997; Thu, 2 May 2002 10:00:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08968 for ; Thu, 2 May 2002 10:00:30 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26876 for ; Thu, 2 May 2002 10:00:25 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 15:58:47 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 15:59:57 +0200 Message-Id: From: "Geib, Ruediger" To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Operational QoS signaling protocol requirements Date: Thu, 2 May 2002 15:59:57 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA08969 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Georgios, my comments in line. G> I think that Operational stability is closer to the G> implementation process!! In my view designing protocols which may operate stable is an activity starting with protocol design. R> 5.12.2 Unexpected situations and error restistance R> An NSIS protocol must define behaviour of NSIS signaling units R> during unexpected situations. Unexpected situtions are R> unknown messages, parameters and parameter settings as R> well as receiption of unexpected messages (e.g. a R> "Reservation Confirmation" without prior "Reservation Request"). G> This requirement is somehow similar to Open issues (53) G> and requirement 5.3.4. Moreover this requirement is G> emphasizing to many details that might not be necessary! 5.3.4 refers to behaviour in the case of problems in the data plane. My suggestion here is about unexpected events/errors in the control plane. If you think that this point carries to many details, let's split it up in several individual requirements. R> 5.12.3 Default behaviour R> An NSIS protocol must define default behaviours and parameter R> settings wherever applicable. > G> What do you mean wherever applicable? Is this service specific? Reworded 5.12.3 Default behaviour An NSIS protocol must define default behaviours and parameter settings wherever NSIS allows for a set of options. This is a basic state of the art signaling design paradigm. It is not service specific. R> 5.12.4 Extendability R> An NSIS protocol must provide means to enhance a R> protocol with future procedures, messages, parameters R> and parameter settings. > G> Maybe this requirement could be a part of the modularity G> requirement 5.1.3! No. This requirement says that coding space and rules must enable a modular build up of the NSIS protocol. It's not about more lightweight, its about more advanced. Maybe we should remove "lightweight" and "extendable" and concentrate on the requirement for a coding space and coding rules which must enable a modular build up of the NSIS protocol, sub- and supersets of it. R> 5.12.6 Reliable Communication R> NSIS signaling procedures, connectivity between units R> involved in NSIS signaling as well as the basic R> transport protocol used by NSIS must provide a maximum R> of communication reliability. Procedures must define R> how an NSIS signaling systems behaves if some R> kind of request it sent stays without R> answer (this could require e.g. be timers, R> number of message retransmits and release messages). R> An NSIS signaling unit must be able to check its connectivity R> to an adjacent NSIS signaling unit at any time (this requirement R> must however not result in a DoS attack tool - the frequency R> of these checks must be limited, and flow control may be useful). R> The basic transport protocol to be used between adjacent R> NSIS units must ensure message integrity and reliable transport. > G> I think that this requirement is embedded into Section 5.8. 5.8. is about security. 5.12.6 is about reliability in communication. The aim of a reliable protocol design is to prevent a node from keeping stale state. R> 5.12.7 Smooth breakdown R> A unit participating in NSIS signaling must no cause further R> damage to other systems involved in NSIS signaling when it R> has to go out of service. > G> Is this a NSIS protocol requirement? Yes. As all other parts of protocol design influencing operational stability. A signaling node being able to say "hello" to other signaling nodes may as well be enabled to say "good bye". Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 10:37:21 2002 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 KAA00927 for ; Thu, 2 May 2002 10:37:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11981 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 10:37:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11191; Thu, 2 May 2002 10:28:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11156 for ; Thu, 2 May 2002 10:28:47 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29989 for ; Thu, 2 May 2002 10:28:42 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g42ESE844776; Thu, 2 May 2002 16:28:14 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA26369; Thu, 2 May 2002 16:26:21 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 7FD8719CDE; Thu, 2 May 2002 16:26:20 +0200 (CEST) Date: Thu, 02 May 2002 16:37:58 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Message-ID: <22556224.1020357478@[192.168.102.79]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FBE@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FBE@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit John, I am afraid, I still not understand your complaint. Is it that the architecture/framework should choose the problem or do you explicitly want to have the decidion out of scope of the document (or even the WG?) Marcus --On Tuesday, April 23, 2002 6:48 AM +0300 john.loughney@nokia.com wrote: > Hi, > >> My main comment was related to the addition of >> the words "number of reservation states" and that is >> within the scope of NSIS. >> >> Regarding the header compression text; it was an example used >> by Anders. > > OK, the complaint I had was this: > > The architecture may choose any of these methods as > long as the requirement is met. > > I'd change it to be: > > Systems may use some of the above methods to meet > the requirement, but how this is done is outside the > scope of this document. > > John -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 10:37:41 2002 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 KAA01018 for ; Thu, 2 May 2002 10:37:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11997 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 10:37:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10951; Thu, 2 May 2002 10:22:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10922 for ; Thu, 2 May 2002 10:22:31 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29365 for ; Thu, 2 May 2002 10:22:25 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g42ELu844250; Thu, 2 May 2002 16:21:56 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA26299; Thu, 2 May 2002 16:20:03 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3FFF02A08F; Thu, 2 May 2002 16:20:02 +0200 (CEST) Date: Thu, 02 May 2002 16:31:40 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01. txt Message-ID: <22178020.1020357100@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Sure, I know. The question is what are we doing with the requirement? Both you and John favour SHOULD support sender initiated MAY support reciever initiated I would completly remove any requirements regarding initation. Marcus --On Thursday, May 02, 2002 4:03 PM +0200 "Georgios Karagiannis (ELN)" wrote: > Hi Marcus > > The sender initiated and receiver initiated terms > that I was referring to are included in the terminology of > the draft!! > > Best regards, > Georgios > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: donderdag 2 mei 2002 15:55 > To: john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included in > draft-ietf-nsis-req-01.txt > > > Georgios, John, > > What is your rational behind the sender/receiver initiated reservations? > What about 3rd parties? What does initation imply? On a high level > perspective I don't see a reason for requiring the one or the other. > Unfortunatly, this comes back to data path vs signaling path issues. > > The implications I see are: > - an entity initating or triggering an initiation needs to be known > (authentication process) or needs to pass money immediately > - In practice, the initiator is the paying party (in real life this is > the case in most scenarios, where one party wants to have a service from > another party. Or at least the assurance that a 3rd party will pay needs > to be given. > - There is a tied relation to uni-directional vs bi-directional > reservations > > Marcus > > --On Monday, April 22, 2002 4:34 PM +0300 john.loughney@nokia.com wrote: > >> Hi Marcus & Georgios, >> >>> Please receive my comments on Issue (2) included in the >>> NSIS WG draft: draft-ietf-nsis-req-01.txt >>> >>> Comment on Issue (2): >>> >>> >>> > 2) (OPEN) Sender/receiver initiation >>> > What is the requirement concerning data sender or data receiver or >>> > both to initiate a QoS request. >>> > - does it matter who pays? >>> > - terminology text added >>> > open issue, what is a potential req (currently we say "both must be >>> > possible") >>> >>> [GK] both should be possible but it should be optimized for >>> sender initiated; >> >> I think that SHOULD is the right level of requirement for sender / >> reciever driven requests. >> >> John > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 10:47:44 2002 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 KAA02266 for ; Thu, 2 May 2002 10:47:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12566 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 10:47:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12101; Thu, 2 May 2002 10:39:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12071 for ; Thu, 2 May 2002 10:39:30 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01279 for ; Thu, 2 May 2002 10:39:23 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42EdQ0E010978 for ; Thu, 2 May 2002 16:39:26 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Thu May 02 16:39:13 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <228152TK>; Thu, 2 May 2002 16:39:13 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" , "'john.loughney@nokia.com'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01. txt Date: Thu, 2 May 2002 16:39:08 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I am in favour of keeping it, and also in favour of keeping the proposal of John! Best Regards, georgios -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: donderdag 2 mei 2002 16:32 To: Georgios Karagiannis (ELN); john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01. txt Sure, I know. The question is what are we doing with the requirement? Both you and John favour SHOULD support sender initiated MAY support reciever initiated I would completly remove any requirements regarding initation. Marcus --On Thursday, May 02, 2002 4:03 PM +0200 "Georgios Karagiannis (ELN)" wrote: > Hi Marcus > > The sender initiated and receiver initiated terms > that I was referring to are included in the terminology of > the draft!! > > Best regards, > Georgios > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: donderdag 2 mei 2002 15:55 > To: john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included in > draft-ietf-nsis-req-01.txt > > > Georgios, John, > > What is your rational behind the sender/receiver initiated reservations? > What about 3rd parties? What does initation imply? On a high level > perspective I don't see a reason for requiring the one or the other. > Unfortunatly, this comes back to data path vs signaling path issues. > > The implications I see are: > - an entity initating or triggering an initiation needs to be known > (authentication process) or needs to pass money immediately > - In practice, the initiator is the paying party (in real life this is > the case in most scenarios, where one party wants to have a service from > another party. Or at least the assurance that a 3rd party will pay needs > to be given. > - There is a tied relation to uni-directional vs bi-directional > reservations > > Marcus > > --On Monday, April 22, 2002 4:34 PM +0300 john.loughney@nokia.com wrote: > >> Hi Marcus & Georgios, >> >>> Please receive my comments on Issue (2) included in the >>> NSIS WG draft: draft-ietf-nsis-req-01.txt >>> >>> Comment on Issue (2): >>> >>> >>> > 2) (OPEN) Sender/receiver initiation >>> > What is the requirement concerning data sender or data receiver or >>> > both to initiate a QoS request. >>> > - does it matter who pays? >>> > - terminology text added >>> > open issue, what is a potential req (currently we say "both must be >>> > possible") >>> >>> [GK] both should be possible but it should be optimized for >>> sender initiated; >> >> I think that SHOULD is the right level of requirement for sender / >> reciever driven requests. >> >> John > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 10:53:50 2002 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 KAA02866 for ; Thu, 2 May 2002 10:53:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12793 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 10:53:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11918; Thu, 2 May 2002 10:35:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11891 for ; Thu, 2 May 2002 10:35:44 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00705 for ; Thu, 2 May 2002 10:35:37 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g42EZC845517; Thu, 2 May 2002 16:35:12 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA26468; Thu, 2 May 2002 16:33:18 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C15ED2BBAD; Thu, 2 May 2002 16:33:18 +0200 (CEST) Date: Thu, 02 May 2002 16:44:55 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" Cc: "'nsis@ietf.org'" Message-ID: <22973914.1020357895@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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: comments Issue (14) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Monday, April 22, 2002 10:35 AM +0200 "Georgios Karagiannis (ELN)" wrote: > Hi Marcus > > Please receive my comments on Issue (14) included in the > NSIS WG draft: draft-ietf-nsis-req-01.txt > > Comment on Issue (14): >> 14) (OPEN, dependend on resolution of bi-directional) proposal to >> add "support grouping of microflows (possibly only for feedback)" >> "As a consequence of the optimization for the interactive multimedia >> services, the signaling should allow one unique request for several >> micro flows having the same origination and destination IP >> addresses. This is usually the case for multimedia SIP calls where >> the voice and video micro flows follow the same path. This grouping >> of requests allows optimization of the QoS processing. Note that >> this may be detrimental for the call setup time. The use of grouping >> for microflows may be restricted to teardown and/or notification >> messages when call setup time is a concern." >> open issue: first resolve the bi-directional issue which is somewhat >> related, because it seams to be an optimization as well > > [GK] I think that this requirement is useful in some scenarios. > [GK] I would not restrict it to teardown and/or notification, it might be > [GK] useful also for the procedure that refreshes reservation states. I see the complexity for setup. What is the semantic behind grouping reservations? What happens if 3 out of 4 reservations are granted and the 4th not? And there are other trandactional problems with it. Additionally, if it is only about the service you are requesting, you might do this in the service-specific part of the protocol. In this case the protocol just regards the group as one reservation (but for several streams). Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 10:59:13 2002 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 KAA03382 for ; Thu, 2 May 2002 10:59:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13112 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 10:59:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12408; Thu, 2 May 2002 10:42:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12321 for ; Thu, 2 May 2002 10:42:37 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01678 for ; Thu, 2 May 2002 10:42:33 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42EgX0E012409 for ; Thu, 2 May 2002 16:42:33 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 02 16:42:25 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281524N>; Thu, 2 May 2002 16:42:25 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] Admission control relevant routing information Date: Thu, 2 May 2002 16:42:20 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA12322 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rudiger Okay, you answered: R>That's not quite what I expect. The developers of R>a signaling protocol should however have a rationale R>which types of QoS admission control could be supported R>by the protocol they defined. I do not see how this answer justifies the need of specifying (in the NSIS protocol messages) the used admission control model, when more than one admission control models (during the same session), might be used in different parts of the network! Regarding routing: G> Moreover, regarding IP routing, how a QoS initiator (sender) G> will be able to know what kind of G> IP routing is used by a network provider? > This question was not answered in the e-mail sent to Roland! Best regards, Georgios -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: donderdag 2 mei 2002 15:45 To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Admission control relevant routing information Georgios, > Sorry Geib, I have looked to your reply to the comment > of Roland Bless but it did not clarify the point I made! Please clarify which part of your comment wasn't answered by Rolands suggestion and my reply. Regards, Rüdiger > > my reply to Roland Bless comment on this list should clarify > the point. > > Regards, Rüdiger > > > >> 5.8.11 The QoS signaling protocol must specify which model of > > >> admission control it is supporting and whether and which adress > > >> information has to be carried by it. > > >> QoS service provisioning may depend on service type and provider > > >> philosophy. A purely qualitative service may not require > > definition > > >> of a specific destination being serviced. In contrast, a > resource > > >> intensive real time service may require detailed information > > >> on the route of the traffic for the purpose of admission > control. > > >> In the latter case, the NSIS protocol may e.g. have to transport > > >> IP address information of some kind between adjacent QC nodes. > > >> An NSIS protocol must therefore specify, whether and how > > IP routing > > >> is relevant to the service supported. > > > > How a QoS initiator could specify the admission control > > mechanisms, since different parts > > of the network and during the same session (flow) might use > > different > > types of admission control mechanisms, or they will not use > > any admission control at all! > > This is an issue that should be left over to network providers. > > > > Moreover, regarding IP routing, how a QoS initiator (sender) > > will be able to know what kind of > > IP routing is used by a network provider? > > > > Best Regards, > > Georgios > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 11:08:23 2002 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 LAA04276 for ; Thu, 2 May 2002 11:08:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13939 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 11:08:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13163; Thu, 2 May 2002 10:59:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13129 for ; Thu, 2 May 2002 10:59:41 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03423 for ; Thu, 2 May 2002 10:59:38 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 May 2002 16:57:58 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 16:59:09 +0200 Message-Id: From: "Geib, Ruediger" To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Admission control relevant routing information Date: Thu, 2 May 2002 16:59: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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA13130 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios please find my comments below. > R>That's not quite what I expect. The developers of > R>a signaling protocol should however have a rationale > R>which types of QoS admission control could be supported > R>by the protocol they defined. > > I do not see how this answer justifies the need of > specifying (in the NSIS protocol messages) > the used admission control model, > when more than one admission control > models (during the same session), might be used > in different parts of the network! Certainly a difficult issue. As the QoS signaling protocol must provide sufficient information to allow admission control, addresses of upstream inter domain gateways or of the sending QC may be part of the admission control decision. As this information must be signaled, it has to be part of the protocol design. It is however part of the service specific protocol. As I mentioned in my response to Roland, I'd like to go on with this discussion once we finished the basic part of NSIS and start to get service specific. G> Moreover, regarding IP routing, how a QoS initiator (sender) G> will be able to know what kind of IP routing is used G> by a network provider? The routing protocol used by a provider is of no relevance to the requirement I stated. I do not suggest any changes to or interoperability with routing protocols. Regards, Rüdiger > > > Georgios, > > > Sorry Geib, I have looked to your reply to the comment > > of Roland Bless but it did not clarify the point I made! > > Please clarify which part of your comment wasn't > answered by Rolands suggestion and my reply. > > Regards, Rüdiger > > > > > my reply to Roland Bless comment on this list should clarify > > the point. > > > > Regards, Rüdiger > > > > > >> 5.8.11 The QoS signaling protocol must specify which model of > > > >> admission control it is supporting and whether and > which adress > > > >> information has to be carried by it. > > > >> QoS service provisioning may depend on service type > and provider > > > >> philosophy. A purely qualitative service may not require > > > definition > > > >> of a specific destination being serviced. In contrast, a > > resource > > > >> intensive real time service may require detailed information > > > >> on the route of the traffic for the purpose of admission > > control. > > > >> In the latter case, the NSIS protocol may e.g. have to > transport > > > >> IP address information of some kind between adjacent QC nodes. > > > >> An NSIS protocol must therefore specify, whether and how > > > IP routing > > > >> is relevant to the service supported. > > > > > > How a QoS initiator could specify the admission control > > > mechanisms, since different parts > > > of the network and during the same session (flow) might use > > > different > > > types of admission control mechanisms, or they will not use > > > any admission control at all! > > > This is an issue that should be left over to network providers. > > > > > > Moreover, regarding IP routing, how a QoS initiator (sender) > > > will be able to know what kind of > > > IP routing is used by a network provider? > > > > > > Best Regards, > > > Georgios > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 11:53:28 2002 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 LAA08517 for ; Thu, 2 May 2002 11:53:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16692 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 11:53:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15950; Thu, 2 May 2002 11:39:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15723 for ; Thu, 2 May 2002 11:35:57 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06950 for ; Thu, 2 May 2002 11:35:51 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42FZq0E004263 for ; Thu, 2 May 2002 17:35:52 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Thu May 02 17:35:09 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 17:32:34 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] Operational QoS signaling protocol requirements Date: Thu, 2 May 2002 17:35:07 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Rudiger G> I think that Operational stability is closer to the G> implementation process!! R> In my view designing protocols which may operate R> stable is an activity starting with protocol design. I agree with you, but such issues are already included in other parts of the requirements draft! My comment was related to the sentence: "The state of a unit involved into NSIS signaling must be stable no matter what the surrounding conditions are." I see this as an implementation issue! R> 5.12.2 Unexpected situations and error restistance R> An NSIS protocol must define behaviour of NSIS signaling units R> during unexpected situations. Unexpected situtions are R> unknown messages, parameters and parameter settings as R> well as receiption of unexpected messages (e.g. a R> "Reservation Confirmation" without prior "Reservation Request"). G> This requirement is somehow similar to Open issues (53) G> and requirement 5.3.4. Moreover this requirement is G> emphasizing to many details that might not be necessary! R>> 5.3.4 refers to behaviour in the case of problems in the data R>> plane. My suggestion here is about unexpected events/errors R>> in the control plane. If you think that this point carries R>> to many details, let's split it up in several individual R>> requirements. Section 5.3.4 does not specify if the errors are in the data plane or control plane! R> 5.12.3 Default behaviour R> An NSIS protocol must define default behaviours and parameter R> settings wherever applicable. > G> What do you mean wherever applicable? Is this service specific? [R]>> Reworded 5.12.3 Default behaviour [R]>> An NSIS protocol must define default behaviours and parameter [R]>> settings wherever NSIS allows for a set of options. [R]>> This is a basic state of the art signaling design paradigm. [R]>> It is not service specific. Could you please give an example!! R> 5.12.4 Extendability R> An NSIS protocol must provide means to enhance a R> protocol with future procedures, messages, parameters R> and parameter settings. > G> Maybe this requirement could be a part of the modularity G> requirement 5.1.3! [R]>> No. This requirement says that coding space and rules must [R]>> enable a modular build up of the NSIS protocol. It's not [R]>> about more lightweight, its about more advanced. [R]>> Maybe we should remove "lightweight" and "extendable" and [R]>> concentrate on the requirement for a coding space and coding [R]>> rules which must enable a modular build up of the NSIS [R]>> protocol, sub- and supersets of it. I do not agree on removing the term lightweight! R> 5.12.6 Reliable Communication R> NSIS signaling procedures, connectivity between units R> involved in NSIS signaling as well as the basic R> transport protocol used by NSIS must provide a maximum R> of communication reliability. Procedures must define R> how an NSIS signaling systems behaves if some R> kind of request it sent stays without R> answer (this could require e.g. be timers, R> number of message retransmits and release messages). R> An NSIS signaling unit must be able to check its connectivity R> to an adjacent NSIS signaling unit at any time (this requirement R> must however not result in a DoS attack tool - the frequency R> of these checks must be limited, and flow control may be useful). R> The basic transport protocol to be used between adjacent R> NSIS units must ensure message integrity and reliable transport. > G> I think that this requirement is embedded into Section 5.8. [R]>> 5.8. is about security. 5.12.6 is about reliability in [R]>> communication. The aim of a reliable protocol design [R]>> is to prevent a node from keeping stale state. Well message integrity is included in Section 5.8. Regarding the other part of reliability, maybe Marcus could give a better answer! R> 5.12.7 Smooth breakdown R> A unit participating in NSIS signaling must no cause further R> damage to other systems involved in NSIS signaling when it R> has to go out of service. > G> Is this a NSIS protocol requirement? [R]>> Yes. As all other parts of protocol design influencing [R]>> operational stability. A signaling node being able [R]>> to say "hello" to other [R]>> signaling nodes may as well be enabled to say "good bye". When a node has an abrupt breakdown, I do not know how this breakdown should be made (and required to be) smooth!! Moreover, there are other requirements such as 5.3.4 and open issue (53) that partially (or indirectly) solve this issue! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 14:03:59 2002 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 OAA20393 for ; Thu, 2 May 2002 14:03:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25711 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 14:03:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24480; Thu, 2 May 2002 13:54:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24448 for ; Thu, 2 May 2002 13:54:12 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19431 for ; Thu, 2 May 2002 13:54:07 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g42HsSn29811 for ; Thu, 2 May 2002 20:54:28 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 2 May 2002 20:54:09 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 2 May 2002 20:54:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Date: Thu, 2 May 2002 20:54:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC650A5@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Thread-Index: AcHx5ZmkZ0cxJgi+SzCkYzC56gpGLwAHFeyA To: , Cc: X-OriginalArrivalTime: 02 May 2002 17:54:08.0965 (UTC) FILETIME=[5BF3DF50:01C1F202] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA24449 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Marcus, My point was the recommending specific protocols / techniques for this issue, even if they are examples. I'd prefer not to have specifics, involving non-WG protocols. John > -----Original Message----- > From: ext Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 02 May, 2002 17:38 > To: Loughney John (NRC/Helsinki); Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (12) included in > draft-ietf-nsis-req-01 > > > John, > > I am afraid, I still not understand your complaint. > Is it that the architecture/framework should choose the problem > or > do you explicitly want to have the decidion out of scope of > the document > (or even the WG?) > > Marcus > > > --On Tuesday, April 23, 2002 6:48 AM +0300 > john.loughney@nokia.com wrote: > > > Hi, > > > >> My main comment was related to the addition of > >> the words "number of reservation states" and that is > >> within the scope of NSIS. > >> > >> Regarding the header compression text; it was an example used > >> by Anders. > > > > OK, the complaint I had was this: > > > > The architecture may choose any of these methods as > > long as the requirement is met. > > > > I'd change it to be: > > > > Systems may use some of the above methods to meet > > the requirement, but how this is done is outside the > > scope of this document. > > > > John > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 2 14:06:45 2002 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 OAA20798 for ; Thu, 2 May 2002 14:06:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25847 for nsis-archive@odin.ietf.org; Thu, 2 May 2002 14:06:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24273; Thu, 2 May 2002 13:49:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24245 for ; Thu, 2 May 2002 13:49:14 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18777 for ; Thu, 2 May 2002 13:49:10 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g42HmAO19822 for ; Thu, 2 May 2002 20:48:10 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 2 May 2002 20:49:11 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 2 May 2002 20:49:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Thu, 2 May 2002 20:49:10 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC650A2@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Thread-Index: AcHx5R/OrNDsZGjIRPm4uu6iRzp9WQAHGs4w To: , Cc: X-OriginalArrivalTime: 02 May 2002 17:49:11.0799 (UTC) FILETIME=[AAD3F070:01C1F201] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA24246 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, > The question is what are we doing with the requirement? > Both you and John favour > SHOULD support sender initiated > MAY support reciever initiated > > I would completly remove any requirements regarding initation. If we include requirements for initiation, I favor the above. However, I am not bothered if this is left out. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri May 3 01:40:45 2002 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 BAA26754 for ; Fri, 3 May 2002 01:40:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA11060 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 01:40:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09775; Fri, 3 May 2002 01:23:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09744 for ; Fri, 3 May 2002 01:23:00 -0400 (EDT) Received: from maktoob.com ([217.78.74.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26458 for ; Fri, 3 May 2002 01:22:54 -0400 (EDT) Message-Id: <200205030522.BAA26458@ietf.org> From: "Gen.H.Salama" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 3 May 2002 07:02:51 +0200 Reply-To: "Gen.H.Salama" X-Priority: 1 (Highest) Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [NSIS] BUSINESS RELATIONSHIP PROPOSAL Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit General Hama Salama. Email:ghsa lama@makto ob.com, BUSINESS RELATIONSH IP PROPOSAL Dear Sir, I received encouragin g informatio n about you, hence I decided to contact you. I am Gen. Hama Salama, Military Commander with POLISARIO( Political Front for the Liberation of Western Sahara) and a member of council of the National Secretaria t of Western Sahara(Sah arawi Democratic Republic) . See web site: www.arso.o rg or www.arso.o rg/secr.na te99.htm to confirm about me and also know more about Western Sahara. Prior to my promotion to this command, I was the second in command to the former military boss. He was killed in battle in early January. Some private , religious and corporate organizati ons who recognize us assist/aid us always in the war prosecutio n. Before the death of my former boss, we were given some funds(US$5 5m) to procures ammunition s. My boss deposited it with a private security company in Europe. It was only I and him that are aware of thiscash deposit. I now want to claim this funds and I have all the relating documents needed to collect the deposit including the Certificat e of Deposit with which the Cash was deposited as Precious stones and The Deposit Agreement. I therefore want you to team up with me to collect the funds in Europe as I require a foreigner to perfect the operation. Let me know your terms. I will provide you with all the necessary documentat ion needed and there are no risks involved. It is a simple and straight transactio n but must bekept highly confidenti al.Upon the receipt of your positive response, further details and the method of operation will be communicat ed to you. Therefore if you are interested , please do reach me via an immediate reply mail. I will want everything about this transactio n to be treated in strictest confidence even if you are notinteres ted. I await your urgent response through my personal mailbox:Em ail:ghsala ma@maktoob .com, Yours Gen Hama Salama Military Commander Western Sahara _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 3 03:51:34 2002 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 DAA06634 for ; Fri, 3 May 2002 03:51:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA17592 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 03:51:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17420; Fri, 3 May 2002 03:45:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17391 for ; Fri, 3 May 2002 03:45:29 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06421 for ; Fri, 3 May 2002 03:45:24 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g437iRO17703 for ; Fri, 3 May 2002 10:44:27 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 3 May 2002 10:45:27 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 3 May 2002 10:45:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Admission control relevant routing information Date: Fri, 3 May 2002 10:45:26 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC650B5@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Admission control relevant routing information Thread-Index: AcHx2SUG1GzeCaaJRE6I8QZ6q+vzgQAnTGMg To: , , Cc: X-OriginalArrivalTime: 03 May 2002 07:45:27.0043 (UTC) FILETIME=[7D9A9530:01C1F276] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA17392 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Georgios, > How a QoS initiator could specify the admission control > mechanisms, since different parts > of the network and during the same session (flow) might use > different > types of admission control mechanisms, or they will not use > any admission control at all! > This is an issue that should be left over to network providers. > > Moreover, regarding IP routing, how a QoS initiator (sender) > will be able to know what kind of > IP routing is used by a network provider? This is exactly correct. Admission control and routing are outside of the scope for NSIS. What may be needed later is some document describing some relationship between them, but that document is not the requirements document. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 3 04:36:23 2002 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 EAA07164 for ; Fri, 3 May 2002 04:36:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20451 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 04:36:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19541; Fri, 3 May 2002 04:28:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19510 for ; Fri, 3 May 2002 04:28:28 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07058 for ; Fri, 3 May 2002 04:28:23 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g438RQO06560 for ; Fri, 3 May 2002 11:27:26 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 3 May 2002 11:28:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 3 May 2002 11:28:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Operational QoS signaling protocol requirements Date: Fri, 3 May 2002 11:28:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DD9@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Operational QoS signaling protocol requirements Thread-Index: AcHxv8GIcpVxV/EgTKay+Og9B07bhwAu2CQA To: , Cc: X-OriginalArrivalTime: 03 May 2002 08:28:24.0257 (UTC) FILETIME=[7DBE3B10:01C1F27C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA19511 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger, Some comments - I am not sure what an NSIS signaling unit is. Have we defined it somewhere? Is it hardware or software, is a software process, a thread or what? I don't think it is useful to include this term in any requirements. > 5.12.1 Backwards compatibility > A later version of an NSIS protocol must be backwards > compatible with earlier versions of an NSIS protocol. I don't support this. What earlier version of NSIS protocols are you talking about? > 5.12.2 Unexpected situations and error restistance > An NSIS protocol must define behaviour of NSIS signaling > units during unexpected situations. Unexpected situtions are > unknown messages, parameters and parameter settings as well > as receiption of unexpected messages (e.g. a "Reservation > Confirmation" without prior "Reservation Request"). I think John Postel's words of wisdom are sufficient: 'Be generous in what you recieve and conservative in what you send.' > 5.12.3 Default behaviour > An NSIS protocol must define default behaviours and parameter > settings wherever applicable. Disagree with this, I don't think we can mandate this at all. > 5.12.4 Extendability > An NSIS protocol must provide means to enhance a protocol > with future procedures, messages, parameters and parameter settings. I don't support the we 'MUST provide means to enhance ..' that is too strong. Extensibility is not a bad thing, but managing this can be very difficult > 5.12.5 Preventation of stale state > An NSIS signalling protocol must provide means for an NSIS > signaling unit to discover and remove local stale state. This > may for example be done by means like soft state and periodic > flooding or by a polling mechanism and hard state signaling. I am not sure about this either, there are a few things embedded in this requirement, and I think this is already covered in other requirements. > 5.12.6 Reliable Communication > NSIS signaling procedures, connectivity between units > involved in NSIS signaling as well as the basic transport > protocol used by NSIS must provide a maximum of communication > reliability. Procedures must define how an NSIS signaling > systems behaves if some kind of request it sent stays without > answer (this could require e.g. be timers, number of message > retransmits and release messages). > An NSIS signaling unit must be able to check its connectivity > to an adjacent NSIS signaling unit at any time (this > requirement must however not result in a DoS attack tool - > the frequency of these checks must be limited, and flow > control may be useful). > The basic transport protocol to be used between adjacent NSIS > units must ensure message integrity and reliable transport. What is 'maximum reliability' - who should provide this function - is it an NSIS protocol, is it the transport protocol NSIS runs on top of, is it provided by the network? I don't like this requirement. > 5.12.7 Smooth breakdown > A unit participating in NSIS signaling must no cause further > damage to other systems involved in NSIS signaling when it > has to go out of service. I don't think this is a useful requirement. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 3 04:42:47 2002 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 EAA07255 for ; Fri, 3 May 2002 04:42:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20632 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 04:42:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19441; Fri, 3 May 2002 04:25:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19409 for ; Fri, 3 May 2002 04:25:39 -0400 (EDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07039 for ; Fri, 3 May 2002 04:25:35 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.36) id 173YNJ-00072B-00; Fri, 03 May 2002 10:25:09 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id g438P9C17948; Fri, 3 May 2002 10:25:09 +0200 Message-ID: <3CD24965.DD0C4BBC@ee.tu-berlin.de> Date: Fri, 03 May 2002 10:25:09 +0200 From: Xiaoming Fu Reply-To: fu@ee.tu-berlin.de Organization: Telecommunication Networks Group, Technical University Berlin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-686 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: "Georgios Karagiannis (ELN)" , john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt References: <22178020.1020357100@[192.168.102.79]> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi Marcus, I would favor your idea, i.e., removing requirement on sender- or receiver- initiation at all. Accounting may care, but this is much of an administrative problem. Another related issue is bi-directional session. Since unicast have been agreed as a must (while multicast is not), there is no special reason to keep bi-directional support for sessions. Moreover, (if I understand correctly,) current provisioning techniques (e.g., IntServ, DiffServ) only support uni-directional setup. Xiaoming Marcus Brunner wrote: > > Sure, I know. > The question is what are we doing with the requirement? > Both you and John favour > SHOULD support sender initiated > MAY support reciever initiated > > I would completly remove any requirements regarding initation. > > Marcus > > --On Thursday, May 02, 2002 4:03 PM +0200 "Georgios Karagiannis (ELN)" > wrote: > > > Hi Marcus > > > > The sender initiated and receiver initiated terms > > that I was referring to are included in the terminology of > > the draft!! > > > > Best regards, > > Georgios > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: donderdag 2 mei 2002 15:55 > > To: john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] comments Issue (2) included in > > draft-ietf-nsis-req-01.txt > > > > > > Georgios, John, > > > > What is your rational behind the sender/receiver initiated reservations? > > What about 3rd parties? What does initation imply? On a high level > > perspective I don't see a reason for requiring the one or the other. > > Unfortunatly, this comes back to data path vs signaling path issues. > > > > The implications I see are: > > - an entity initating or triggering an initiation needs to be known > > (authentication process) or needs to pass money immediately > > - In practice, the initiator is the paying party (in real life this is > > the case in most scenarios, where one party wants to have a service from > > another party. Or at least the assurance that a 3rd party will pay needs > > to be given. > > - There is a tied relation to uni-directional vs bi-directional > > reservations > > > > Marcus > > > > --On Monday, April 22, 2002 4:34 PM +0300 john.loughney@nokia.com wrote: > > > >> Hi Marcus & Georgios, > >> > >>> Please receive my comments on Issue (2) included in the > >>> NSIS WG draft: draft-ietf-nsis-req-01.txt > >>> > >>> Comment on Issue (2): > >>> > >>> > >>> > 2) (OPEN) Sender/receiver initiation > >>> > What is the requirement concerning data sender or data receiver or > >>> > both to initiate a QoS request. > >>> > - does it matter who pays? > >>> > - terminology text added > >>> > open issue, what is a potential req (currently we say "both must be > >>> > possible") > >>> > >>> [GK] both should be possible but it should be optimized for > >>> sender initiated; > >> > >> I think that SHOULD is the right level of requirement for sender / > >> reciever driven requests. > >> > >> John > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > 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 daemon@optimus.ietf.org Fri May 3 05:47:19 2002 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 FAA07984 for ; Fri, 3 May 2002 05:47:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA23669 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 05:47:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22537; Fri, 3 May 2002 05:28:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22506 for ; Fri, 3 May 2002 05:28:04 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07779 for ; Fri, 3 May 2002 05:28:00 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g439S3s7012844 for ; Fri, 3 May 2002 11:28:03 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Fri May 03 11:27:19 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 11:27:19 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'fu@ee.tu-berlin.de'" , brunner@ccrle.nec.de Cc: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Fri, 3 May 2002 11:27:12 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Xiaoming Regarding the need of having a sender initiated approach please look into draft: "draft-partain-nsis-requirements-00.txt" There are scenarios that require a sender initiated approach. Therefore, I am in favour of keeping it (as proposed by John); Regarding the bi-directional reservation I do not understand your argument regarding multicast. Bi-directional reservations are useful in certain unicast (not multicast) scenarios! Best regards, Georgios -----Original Message----- From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de] Sent: vrijdag 3 mei 2002 10:25 To: brunner@ccrle.nec.de Cc: Georgios Karagiannis (ELN); john.loughney@nokia.com; nsis@ietf.org Subject: Re: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Marcus, I would favor your idea, i.e., removing requirement on sender- or receiver- initiation at all. Accounting may care, but this is much of an administrative problem. Another related issue is bi-directional session. Since unicast have been agreed as a must (while multicast is not), there is no special reason to keep bi-directional support for sessions. Moreover, (if I understand correctly,) current provisioning techniques (e.g., IntServ, DiffServ) only support uni-directional setup. Xiaoming Marcus Brunner wrote: > > Sure, I know. > The question is what are we doing with the requirement? > Both you and John favour > SHOULD support sender initiated > MAY support reciever initiated > > I would completly remove any requirements regarding initation. > > Marcus > > --On Thursday, May 02, 2002 4:03 PM +0200 "Georgios Karagiannis (ELN)" > wrote: > > > Hi Marcus > > > > The sender initiated and receiver initiated terms > > that I was referring to are included in the terminology of > > the draft!! > > > > Best regards, > > Georgios > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: donderdag 2 mei 2002 15:55 > > To: john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] comments Issue (2) included in > > draft-ietf-nsis-req-01.txt > > > > > > Georgios, John, > > > > What is your rational behind the sender/receiver initiated reservations? > > What about 3rd parties? What does initation imply? On a high level > > perspective I don't see a reason for requiring the one or the other. > > Unfortunatly, this comes back to data path vs signaling path issues. > > > > The implications I see are: > > - an entity initating or triggering an initiation needs to be known > > (authentication process) or needs to pass money immediately > > - In practice, the initiator is the paying party (in real life this is > > the case in most scenarios, where one party wants to have a service from > > another party. Or at least the assurance that a 3rd party will pay needs > > to be given. > > - There is a tied relation to uni-directional vs bi-directional > > reservations > > > > Marcus > > > > --On Monday, April 22, 2002 4:34 PM +0300 john.loughney@nokia.com wrote: > > > >> Hi Marcus & Georgios, > >> > >>> Please receive my comments on Issue (2) included in the > >>> NSIS WG draft: draft-ietf-nsis-req-01.txt > >>> > >>> Comment on Issue (2): > >>> > >>> > >>> > 2) (OPEN) Sender/receiver initiation > >>> > What is the requirement concerning data sender or data receiver or > >>> > both to initiate a QoS request. > >>> > - does it matter who pays? > >>> > - terminology text added > >>> > open issue, what is a potential req (currently we say "both must be > >>> > possible") > >>> > >>> [GK] both should be possible but it should be optimized for > >>> sender initiated; > >> > >> I think that SHOULD is the right level of requirement for sender / > >> reciever driven requests. > >> > >> John > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > 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 daemon@optimus.ietf.org Fri May 3 06:34:05 2002 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 GAA08625 for ; Fri, 3 May 2002 06:34:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26006 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 06:34:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25271; Fri, 3 May 2002 06:26:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25241 for ; Fri, 3 May 2002 06:26:07 -0400 (EDT) Received: from fw1b.telekom.de (gw1.telekom.de [194.25.15.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08496 for ; Fri, 3 May 2002 06:26:04 -0400 (EDT) Received: by fw1b.telekom.de; (8.8.8/1.3/10May95) id MAA19429; Fri, 3 May 2002 12:25:12 +0200 (MET DST) Received: from U9JWN.mgb01.telekom.de by G8PXB.blf01.telekom.de with ESMTP; Fri, 3 May 2002 12:26:04 +0200 Received: from g8pbr.blf01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP; Fri, 3 May 2002 12:26:04 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 12:26:03 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Operational QoS signaling protocol requirements Date: Fri, 3 May 2002 12:26:02 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA25242 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello John, hello Georgios, chapter 5.12 as I proposed it sums up some of "the lessons learned" during the development of other signaling protocols. It's rather generic and certainly not service specific. I've started to work on protocols with ISDN in the early 90s and most of the principles I describe here were applied there. I've later worked on ATM too. Since 1998 I'm working on IP and I specified an "Inter Domain Bandwidth Broker Signaling" together with a couple of other folks for Internet2. Most of the principles I've used to structure these BB codings were taken from RFC3036 (LDP Specification). RFC 3036 is a good example of a state of the art signaling protocol. If I remember right, taking into account lessons learnt from other protocols was one of the most important aims of NSIS. Maybe I've got a wrong perception what these lessons are. My view is, that if these really basic design principles I've listed are not taken as guidance for the development of NSIS, it may not be very useful. I might be to pessimistic - NSIS may develop a protocol along these guidelines without stating them explicitely. Georgios gave me a discussion that notification of QoS violation in case of error or failure is related to the handling of problems in the control plane. I can't follow his conclusion. If the statement is truly is about problems in the control plane and their handling, it's worded rather bad. I'm having more problems with the draft but Marcus announced a review and I wanted to wait for it. Nothing I've suggested as new text is currently in the draft or you need a lot of imagination to find it there. If the requirements are not precise, so will be the solutions based on it. Regards, Rüdiger > > 5.12.1 Backwards compatibility > > A later version of an NSIS protocol must be backwards > > compatible with earlier versions of an NSIS protocol. > > I don't support this. What earlier version of NSIS > protocols are you talking about? > > > 5.12.2 Unexpected situations and error restistance > > An NSIS protocol must define behaviour of NSIS signaling > > units during unexpected situations. Unexpected situtions are > > unknown messages, parameters and parameter settings as well > > as receiption of unexpected messages (e.g. a "Reservation > > Confirmation" without prior "Reservation Request"). > > I think John Postel's words of wisdom are sufficient: > 'Be generous in what you recieve and conservative in what > you send.' > > > 5.12.3 Default behaviour > > An NSIS protocol must define default behaviours and parameter > > settings wherever applicable. > > Disagree with this, I don't think we can mandate this at all. > > > 5.12.4 Extendability > > An NSIS protocol must provide means to enhance a protocol > > with future procedures, messages, parameters and parameter settings. > > I don't support the we 'MUST provide means to enhance ..' that is > too strong. Extensibility is not a bad thing, but managing > this can be > very difficult > > > 5.12.5 Preventation of stale state > > An NSIS signalling protocol must provide means for an NSIS > > signaling unit to discover and remove local stale state. This > > may for example be done by means like soft state and periodic > > flooding or by a polling mechanism and hard state signaling. > > I am not sure about this either, there are a few things embedded > in this requirement, and I think this is already covered in other > requirements. > > > 5.12.6 Reliable Communication > > NSIS signaling procedures, connectivity between units > > involved in NSIS signaling as well as the basic transport > > protocol used by NSIS must provide a maximum of communication > > reliability. Procedures must define how an NSIS signaling > > systems behaves if some kind of request it sent stays without > > answer (this could require e.g. be timers, number of message > > retransmits and release messages). > > An NSIS signaling unit must be able to check its connectivity > > to an adjacent NSIS signaling unit at any time (this > > requirement must however not result in a DoS attack tool - > > the frequency of these checks must be limited, and flow > > control may be useful). > > The basic transport protocol to be used between adjacent NSIS > > units must ensure message integrity and reliable transport. > > What is 'maximum reliability' - who should provide this > function - is it an NSIS protocol, is it the transport protocol > NSIS runs on top of, is it provided by the network? I don't > like this requirement. > > > 5.12.7 Smooth breakdown > > A unit participating in NSIS signaling must no cause further > > damage to other systems involved in NSIS signaling when it > > has to go out of service. > > I don't think this is a useful requirement. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 3 06:43:11 2002 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 GAA08759 for ; Fri, 3 May 2002 06:43:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26322 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 06:43:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25212; Fri, 3 May 2002 06:25:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25189 for ; Fri, 3 May 2002 06:25:20 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08483 for ; Fri, 3 May 2002 06:25:15 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g43AOk876080; Fri, 3 May 2002 12:24:46 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA04445; Fri, 3 May 2002 12:22:50 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E771028430; Fri, 3 May 2002 12:22:49 +0200 (CEST) Date: Fri, 03 May 2002 12:34:30 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, Ruediger.Geib@t-systems.com Cc: nsis@ietf.org Subject: RE: [NSIS] Operational QoS signaling protocol requirements Message-ID: <12390897.1020429270@[192.168.102.79]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DD9@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DD9@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Friday, May 03, 2002 11:28 AM +0300 john.loughney@nokia.com wrote: >> 5.12.2 Unexpected situations and error restistance >> An NSIS protocol must define behaviour of NSIS signaling >> units during unexpected situations. Unexpected situtions are >> unknown messages, parameters and parameter settings as well >> as receiption of unexpected messages (e.g. a "Reservation >> Confirmation" without prior "Reservation Request"). > > I think John Postel's words of wisdom are sufficient: > 'Be generous in what you recieve and conservative in what > you send.' I pretty much like the requirement, because it is about taking care in the design and standardization of a potential protocol. Specifically the error resistance, even if implementation specific in many regards, is very important for operating a network using NSIS. >> 5.12.3 Default behaviour >> An NSIS protocol must define default behaviours and parameter >> settings wherever applicable. > > Disagree with this, I don't think we can mandate this at all. > This one I like as well. Standardized default behaviour enhances the reliability. >> 5.12.5 Preventation of stale state >> An NSIS signalling protocol must provide means for an NSIS >> signaling unit to discover and remove local stale state. This >> may for example be done by means like soft state and periodic >> flooding or by a polling mechanism and hard state signaling. > > I am not sure about this either, there are a few things embedded > in this requirement, and I think this is already covered in other > requirements. Here I think we have covered it in other reqs, but potentially not enough. As said in a previous mail, soft state is a solution for various issues, so explicitly having a req on stale state (garbage collection in OO systems) I find useful. >> 5.12.7 Smooth breakdown >> A unit participating in NSIS signaling must no cause further >> damage to other systems involved in NSIS signaling when it >> has to go out of service. > > I don't think this is a useful requirement. Here I agree with John. I have problems to see how we could meet this req in a protocol or architecture. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 3 09:41:35 2002 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 JAA13170 for ; Fri, 3 May 2002 09:41:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06560 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 09:41:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05159; Fri, 3 May 2002 09:18:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05074 for ; Fri, 3 May 2002 09:18:50 -0400 (EDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12514 for ; Fri, 3 May 2002 09:18:45 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.36) id 173cx1-0002H3-00; Fri, 03 May 2002 15:18:19 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id g43DIJC26535; Fri, 3 May 2002 15:18:19 +0200 Message-ID: <3CD28E1B.F5AE50CF@ee.tu-berlin.de> Date: Fri, 03 May 2002 15:18:19 +0200 From: Xiaoming Fu Reply-To: fu@ee.tu-berlin.de Organization: Telecommunication Networks Group, Technical University Berlin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-686 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" CC: brunner@ccrle.nec.de, john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi Georgios, The question is how far the requirement to be other than a solution? My comments inline: "Georgios Karagiannis (ELN)" wrote: > > Hi Xiaoming > > Regarding the need of having a sender initiated approach > please look into draft: "draft-partain-nsis-requirements-00.txt" Thanks. Although I agree that it is advantegous to have a uniformed model for e2e NSIS protocol, I am not sure about whether it is appropriate for NSIS limited to sender-initiated. In your draft section 4: "- While there are possible scenarios where the receiver initiates the signalling, such as a web QoS scenario, this should be solved at the application layer for unicast flows." This assumption indicates you have to introduce additional NSIS modules (which may be complex if bi-directional is supported - as you proposed - as an unavailability of resources for one directional setup would bring difficulty in admission control, for instance) or more complex in application (which may differ from one app to another app). > > There are scenarios that require a sender initiated approach. > Therefore, I am in favour of keeping it (as proposed by John); > > Regarding the bi-directional reservation I do not understand your > argument regarding multicast. > Bi-directional reservations are useful in certain unicast (not multicast) > scenarios! Do you mean the multi-sender, one-receiver scenarios? Following RSVPv1, unicast usually doesn't equal to one-to-one, but I am not clear whether "unicast" in NSIS would follow this definition... Regards Xiaoming > > Best regards, > Georgios > > -----Original Message----- > From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de] > Sent: vrijdag 3 mei 2002 10:25 > To: brunner@ccrle.nec.de > Cc: Georgios Karagiannis (ELN); john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > Hi Marcus, > > I would favor your idea, i.e., removing requirement on sender- or receiver- > initiation at all. Accounting may care, but this is much of an administrative > problem. > > Another related issue is bi-directional session. Since unicast have been > agreed as a must (while multicast is not), there is no special reason to keep > bi-directional support for sessions. Moreover, (if I understand correctly,) > current provisioning techniques (e.g., IntServ, DiffServ) only support > uni-directional setup. > > Xiaoming > > Marcus Brunner wrote: > > > > Sure, I know. > > The question is what are we doing with the requirement? > > Both you and John favour > > SHOULD support sender initiated > > MAY support reciever initiated > > > > I would completly remove any requirements regarding initation. > > > > Marcus > > > > --On Thursday, May 02, 2002 4:03 PM +0200 "Georgios Karagiannis (ELN)" > > wrote: > > > > > Hi Marcus > > > > > > The sender initiated and receiver initiated terms > > > that I was referring to are included in the terminology of > > > the draft!! > > > > > > Best regards, > > > Georgios > > > -----Original Message----- > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > Sent: donderdag 2 mei 2002 15:55 > > > To: john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] comments Issue (2) included in > > > draft-ietf-nsis-req-01.txt > > > > > > > > > Georgios, John, > > > > > > What is your rational behind the sender/receiver initiated reservations? > > > What about 3rd parties? What does initation imply? On a high level > > > perspective I don't see a reason for requiring the one or the other. > > > Unfortunatly, this comes back to data path vs signaling path issues. > > > > > > The implications I see are: > > > - an entity initating or triggering an initiation needs to be known > > > (authentication process) or needs to pass money immediately > > > - In practice, the initiator is the paying party (in real life this is > > > the case in most scenarios, where one party wants to have a service from > > > another party. Or at least the assurance that a 3rd party will pay needs > > > to be given. > > > - There is a tied relation to uni-directional vs bi-directional > > > reservations > > > > > > Marcus > > > > > > --On Monday, April 22, 2002 4:34 PM +0300 john.loughney@nokia.com wrote: > > > > > >> Hi Marcus & Georgios, > > >> > > >>> Please receive my comments on Issue (2) included in the > > >>> NSIS WG draft: draft-ietf-nsis-req-01.txt > > >>> > > >>> Comment on Issue (2): > > >>> > > >>> > > >>> > 2) (OPEN) Sender/receiver initiation > > >>> > What is the requirement concerning data sender or data receiver or > > >>> > both to initiate a QoS request. > > >>> > - does it matter who pays? > > >>> > - terminology text added > > >>> > open issue, what is a potential req (currently we say "both must be > > >>> > possible") > > >>> > > >>> [GK] both should be possible but it should be optimized for > > >>> sender initiated; > > >> > > >> I think that SHOULD is the right level of requirement for sender / > > >> reciever driven requests. > > >> > > >> John > > > > > > > > > > > > -------------------------------------- > > > Dr. Marcus Brunner > > > Network Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > personal home page: http://www.brubers.org/marcus > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 3 09:53:23 2002 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 JAA13564 for ; Fri, 3 May 2002 09:53:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07351 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 09:53:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06443; Fri, 3 May 2002 09:39:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06410 for ; Fri, 3 May 2002 09:39:15 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13078 for ; Fri, 3 May 2002 09:39:05 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g43Dd8s7009565 for ; Fri, 3 May 2002 15:39:08 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri May 03 15:39:07 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 15:38:06 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'fu@ee.tu-berlin.de'" Cc: brunner@ccrle.nec.de, john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Fri, 3 May 2002 15:38:59 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Xiaoming Thank you for your comments! Please note that we do not exclude receiver initiated approaches, but agree with the proposal of John Loughney: SHOULD support sender initiated MAY support receiver initiated MUST support unicast MAY support multicast. Best regards, Georgios -----Original Message----- From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de] Sent: vrijdag 3 mei 2002 15:18 To: Georgios Karagiannis (ELN) Cc: brunner@ccrle.nec.de; john.loughney@nokia.com; nsis@ietf.org Subject: Re: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Georgios, The question is how far the requirement to be other than a solution? My comments inline: "Georgios Karagiannis (ELN)" wrote: > > Hi Xiaoming > > Regarding the need of having a sender initiated approach > please look into draft: "draft-partain-nsis-requirements-00.txt" Thanks. Although I agree that it is advantegous to have a uniformed model for e2e NSIS protocol, I am not sure about whether it is appropriate for NSIS limited to sender-initiated. In your draft section 4: "- While there are possible scenarios where the receiver initiates the signalling, such as a web QoS scenario, this should be solved at the application layer for unicast flows." This assumption indicates you have to introduce additional NSIS modules (which may be complex if bi-directional is supported - as you proposed - as an unavailability of resources for one directional setup would bring difficulty in admission control, for instance) or more complex in application (which may differ from one app to another app). > > There are scenarios that require a sender initiated approach. > Therefore, I am in favour of keeping it (as proposed by John); > > Regarding the bi-directional reservation I do not understand your > argument regarding multicast. > Bi-directional reservations are useful in certain unicast (not multicast) > scenarios! Do you mean the multi-sender, one-receiver scenarios? Following RSVPv1, unicast usually doesn't equal to one-to-one, but I am not clear whether "unicast" in NSIS would follow this definition... Regards Xiaoming > > Best regards, > Georgios > > -----Original Message----- > From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de] > Sent: vrijdag 3 mei 2002 10:25 > To: brunner@ccrle.nec.de > Cc: Georgios Karagiannis (ELN); john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > Hi Marcus, > > I would favor your idea, i.e., removing requirement on sender- or receiver- > initiation at all. Accounting may care, but this is much of an administrative > problem. > > Another related issue is bi-directional session. Since unicast have been > agreed as a must (while multicast is not), there is no special reason to keep > bi-directional support for sessions. Moreover, (if I understand correctly,) > current provisioning techniques (e.g., IntServ, DiffServ) only support > uni-directional setup. > > Xiaoming > > Marcus Brunner wrote: > > > > Sure, I know. > > The question is what are we doing with the requirement? > > Both you and John favour > > SHOULD support sender initiated > > MAY support reciever initiated > > > > I would completly remove any requirements regarding initation. > > > > Marcus > > > > --On Thursday, May 02, 2002 4:03 PM +0200 "Georgios Karagiannis (ELN)" > > wrote: > > > > > Hi Marcus > > > > > > The sender initiated and receiver initiated terms > > > that I was referring to are included in the terminology of > > > the draft!! > > > > > > Best regards, > > > Georgios > > > -----Original Message----- > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > Sent: donderdag 2 mei 2002 15:55 > > > To: john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] comments Issue (2) included in > > > draft-ietf-nsis-req-01.txt > > > > > > > > > Georgios, John, > > > > > > What is your rational behind the sender/receiver initiated reservations? > > > What about 3rd parties? What does initation imply? On a high level > > > perspective I don't see a reason for requiring the one or the other. > > > Unfortunatly, this comes back to data path vs signaling path issues. > > > > > > The implications I see are: > > > - an entity initating or triggering an initiation needs to be known > > > (authentication process) or needs to pass money immediately > > > - In practice, the initiator is the paying party (in real life this is > > > the case in most scenarios, where one party wants to have a service from > > > another party. Or at least the assurance that a 3rd party will pay needs > > > to be given. > > > - There is a tied relation to uni-directional vs bi-directional > > > reservations > > > > > > Marcus > > > > > > --On Monday, April 22, 2002 4:34 PM +0300 john.loughney@nokia.com wrote: > > > > > >> Hi Marcus & Georgios, > > >> > > >>> Please receive my comments on Issue (2) included in the > > >>> NSIS WG draft: draft-ietf-nsis-req-01.txt > > >>> > > >>> Comment on Issue (2): > > >>> > > >>> > > >>> > 2) (OPEN) Sender/receiver initiation > > >>> > What is the requirement concerning data sender or data receiver or > > >>> > both to initiate a QoS request. > > >>> > - does it matter who pays? > > >>> > - terminology text added > > >>> > open issue, what is a potential req (currently we say "both must be > > >>> > possible") > > >>> > > >>> [GK] both should be possible but it should be optimized for > > >>> sender initiated; > > >> > > >> I think that SHOULD is the right level of requirement for sender / > > >> reciever driven requests. > > >> > > >> John > > > > > > > > > > > > -------------------------------------- > > > Dr. Marcus Brunner > > > Network Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > personal home page: http://www.brubers.org/marcus > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 3 10:12:38 2002 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 KAA14636 for ; Fri, 3 May 2002 10:12:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08744 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 10:12:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07254; Fri, 3 May 2002 09:52:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07224 for ; Fri, 3 May 2002 09:52:19 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13519 for ; Fri, 3 May 2002 09:52:15 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g43DpQV19083; Fri, 3 May 2002 09:51:27 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 09:51:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A8A@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'fu@ee.tu-berlin.de'" , brunner@ccrle.nec.de Cc: "Georgios Karagiannis (ELN)" , john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Fri, 3 May 2002 09:51:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F2A9.27EA09EE" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1F2A9.27EA09EE Content-Type: text/plain; charset="iso-8859-1" Can we guarantee that the semantics of the signalling do not change depending on whether it is sender initiated or receiver initiated? Probably not. Gary Kenward > -----Original Message----- > From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de] > Sent: May 3, 2002 04:25 > To: brunner@ccrle.nec.de > Cc: Georgios Karagiannis (ELN); john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > Hi Marcus, > > I would favor your idea, i.e., removing requirement on > sender- or receiver- > initiation at all. Accounting may care, but this is much of > an administrative > problem. > > Another related issue is bi-directional session. Since > unicast have been > agreed as a must (while multicast is not), there is no > special reason to keep > bi-directional support for sessions. Moreover, (if I > understand correctly,) > current provisioning techniques (e.g., IntServ, DiffServ) only support > uni-directional setup. > > Xiaoming > > Marcus Brunner wrote: > > > > Sure, I know. > > The question is what are we doing with the requirement? > > Both you and John favour > > SHOULD support sender initiated > > MAY support reciever initiated > > > > I would completly remove any requirements regarding initation. > > > > Marcus > > > > --On Thursday, May 02, 2002 4:03 PM +0200 "Georgios > Karagiannis (ELN)" > > wrote: > > > > > Hi Marcus > > > > > > The sender initiated and receiver initiated terms > > > that I was referring to are included in the terminology of > > > the draft!! > > > > > > Best regards, > > > Georgios > > > -----Original Message----- > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > Sent: donderdag 2 mei 2002 15:55 > > > To: john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] comments Issue (2) included in > > > draft-ietf-nsis-req-01.txt > > > > > > > > > Georgios, John, > > > > > > What is your rational behind the sender/receiver > initiated reservations? > > > What about 3rd parties? What does initation imply? On a high level > > > perspective I don't see a reason for requiring the one or > the other. > > > Unfortunatly, this comes back to data path vs signaling > path issues. > > > > > > The implications I see are: > > > - an entity initating or triggering an initiation needs > to be known > > > (authentication process) or needs to pass money immediately > > > - In practice, the initiator is the paying party (in real > life this is > > > the case in most scenarios, where one party wants to > have a service from > > > another party. Or at least the assurance that a 3rd party > will pay needs > > > to be given. > > > - There is a tied relation to uni-directional vs bi-directional > > > reservations > > > > > > Marcus > > > > > > --On Monday, April 22, 2002 4:34 PM +0300 > john.loughney@nokia.com wrote: > > > > > >> Hi Marcus & Georgios, > > >> > > >>> Please receive my comments on Issue (2) included in the > > >>> NSIS WG draft: draft-ietf-nsis-req-01.txt > > >>> > > >>> Comment on Issue (2): > > >>> > > >>> > > >>> > 2) (OPEN) Sender/receiver initiation > > >>> > What is the requirement concerning data sender or > data receiver or > > >>> > both to initiate a QoS request. > > >>> > - does it matter who pays? > > >>> > - terminology text added > > >>> > open issue, what is a potential req (currently we > say "both must be > > >>> > possible") > > >>> > > >>> [GK] both should be possible but it should be optimized for > > >>> sender initiated; > > >> > > >> I think that SHOULD is the right level of requirement > for sender / > > >> reciever driven requests. > > >> > > >> John > > > > > > > > > > > > -------------------------------------- > > > Dr. Marcus Brunner > > > Network Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > personal home page: http://www.brubers.org/marcus > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > 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 > ------_=_NextPart_001_01C1F2A9.27EA09EE Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt

Can we guarantee that the semantics of the signalling do not change
depending on whether it is sender initiated or receiver initiated?
Probably not.

Gary Kenward

> -----Original Message-----
> From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de]
> Sent: May 3, 2002 04:25
> To: brunner@ccrle.nec.de
> Cc: Georgios Karagiannis (ELN); john.loughney@nokia.com; nsis@ietf.org
> Subject: Re: [NSIS] comments Issue (2) included
> indraft-ietf-nsis-req-01. txt
>
>
> Hi Marcus,
>
> I would favor your idea, i.e., removing requirement on
> sender- or receiver-
> initiation at all. Accounting may care, but this is much of
> an administrative
> problem.
>
> Another related issue is bi-directional session. Since
> unicast have been
> agreed as a must (while multicast is not), there is no
> special reason to keep
> bi-directional support for sessions. Moreover, (if I
> understand correctly,)
> current provisioning techniques (e.g., IntServ, DiffServ) only support
> uni-directional setup.
>
> Xiaoming
>
> Marcus Brunner wrote:
> >
> > Sure, I know.
> > The question is what are we doing with the requirement?
> > Both you and John favour
> >   SHOULD support sender initiated
> >   MAY support reciever initiated
> >
> > I would completly remove any requirements regarding initation.
> >
> > Marcus
> >
> > --On Thursday, May 02, 2002 4:03 PM +0200 "Georgios
> Karagiannis (ELN)"
> > <Georgios.Karagiannis@eln.ericsson.se> wrote:
> >
> > > Hi Marcus
> > >
> > > The sender initiated and receiver initiated terms
> > > that I was referring to are included in the terminology of
> > > the draft!!
> > >
> > > Best regards,
> > > Georgios
> > > -----Original Message-----
> > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > > Sent: donderdag 2 mei 2002 15:55
> > > To: john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se
> > > Cc: nsis@ietf.org
> > > Subject: RE: [NSIS] comments Issue (2) included in
> > > draft-ietf-nsis-req-01.txt
> > >
> > >
> > > Georgios, John,
> > >
> > > What is your rational behind the sender/receiver
> initiated reservations?
> > > What about 3rd parties? What does initation imply? On a high level
> > > perspective I don't see a reason for requiring the one or
> the other.
> > > Unfortunatly, this comes back to data path vs signaling
> path issues.
> > >
> > > The implications I see are:
> > > - an entity initating or triggering an initiation needs
> to be known
> > > (authentication process) or needs to pass money immediately
> > > - In practice, the initiator is the paying party (in real
> life this is
> > > the  case in most scenarios, where one party wants to
> have a service from
> > > another party. Or at least the assurance that a 3rd party
> will pay needs
> > > to  be given.
> > > - There is a tied relation to uni-directional vs bi-directional
> > > reservations
> > >
> > > Marcus
> > >
> > > --On Monday, April 22, 2002 4:34 PM +0300
> john.loughney@nokia.com wrote:
> > >
> > >> Hi Marcus & Georgios,
> > >>
> > >>> Please receive my comments on Issue (2) included in the
> > >>> NSIS WG draft: draft-ietf-nsis-req-01.txt
> > >>>
> > >>> Comment on Issue (2):
> > >>>
> > >>>
> > >>> > 2) (OPEN) Sender/receiver initiation
> > >>> >    What is the requirement concerning data sender or
> data receiver or
> > >>> >    both to initiate a QoS request.
> > >>> >    - does it matter who pays?
> > >>> >    - terminology text added
> > >>> >    open issue, what is a potential req (currently we
> say "both must be
> > >>> >    possible")
> > >>>
> > >>> [GK] both should be possible but it should be optimized for
> > >>> sender initiated;
> > >>
> > >> I think that SHOULD is the right level of requirement
> for sender /
> > >> reciever driven requests.
> > >>
> > >> John
> > >
> > >
> > >
> > > --------------------------------------
> > > Dr. Marcus Brunner
> > > Network Laboratories
> > > NEC Europe Ltd.
> > >
> > > E-Mail: brunner@ccrle.nec.de
> > > WWW:    http://www.ccrle.nec.de/
> > > personal home page: http://www.brubers.org/marcus
> > >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > 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
>

------_=_NextPart_001_01C1F2A9.27EA09EE-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 3 14:24:42 2002 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 OAA23593 for ; Fri, 3 May 2002 14:24:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24153 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 14:24:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22396; Fri, 3 May 2002 14:00:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22359 for ; Fri, 3 May 2002 14:00:33 -0400 (EDT) Received: from help.netneo.co.kr ([210.102.20.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22278 for ; Fri, 3 May 2002 14:00:28 -0400 (EDT) Received: from test (unverified [12.109.16.76]) by help.netneo.co.kr (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 04 May 2002 03:00:25 +0900 Message-ID: Reply-To: medbreakreply00924@yahoo.com From: medbreak0092417@yahoo.com To: nsis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 3 May 2002 11:02:21 -0700 Subject: [NSIS] ===Medical Breakthrough... Aging can be reversed!=== 17 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org All HGH (Human Growth Hormone) products are not the same. There are three different types of products. Yet, all three are advertised as if they where the same. The three types are: 1) Homeopathic HGH 2) Pre-cursor HGH 3) Real or synthetic HGH (delivered by injection or, by an oral spray method). Do you know differences? Call us and we'll explain them to you. Our toll free number is 888-621-7300. For more information on HGH read on............ ***************************************************************************** HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs -- plus, all other symptoms related to old age. IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat and Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and Improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10 - 20 years * Live Longer AND Stronger All natural and organic plant based FEEL 10 YEARS YOUNGER WITH ORAL SPRAY HGH. GUARANTEED We are the manufacturer and we sell directly to Doctors, Chiropractors, and consumers world wide the highest grade HGH Oral Spray available. With internet marketing, we are able to save advertising cost and pass those savings along to you. But you must act now. To receive more information call us now. TOLL FREE 1-888-621-7300 We must speak to you in person to qualify your usage. All of your questions will be addressed and answered in a friendly, no pressure manner. Our main purpose is to provide you with information so you can make an educated decision. For more information call 1-888-621-7300 If you are on line write down our phone number and call us when you can. Soon, you and your loved ones will be very glad you did. Read what people are saying: "The effects of 6 months of GH on lean body mass and fat were equivalent in magnitude to the changes incurred during 10-20 years of aging." Dr. Daniel Rudman, MD, New England Journal of Medicine. "Within four months, my body fat decreased form 30% down to 21%! I noticed my skin is more supple and my overall mental outlook improved significantly." D.W., New Jersey "We have been on the spray for just 3 weeks now, and besides the tremendous energy we both feel, my husbands allergies and spells of depression have lifted. I am healing extremely fast after an accident and have lost 7 lbs. without trying!" C.B., Flagstaff. AZ Thanks for reading our letter, The HGH Staff USA Division PS: The HGH Staff guarantees the highest quality and lowest price. We manufacture and ship directly to your door. Offer expires 19 June 2002 Call us now 1-888-621-7300 *********************************************************** ======= End of message ======== To Qualify for a Free HGH Consultation call the HGH Staff -- Today. *********************************************************** The following statement is provided to be in compliance with commercial email laws. If you do not wish to receive further mailings, please click reply and type remvoe in the subject box. Then click send. This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title lll, Section 301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress and is not considered SPAM since it includes a remove mechanism. *********************************************************** This message is not intended for residents in the states of CA, NC, NV, RI, TN, VA & WA. Screening of addresses has been done to the best of our technical ability. *********************************************************** Call us now 1-888-621-7300 for your free HGH consultation. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri May 3 17:02:16 2002 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 RAA00868 for ; Fri, 3 May 2002 17:02:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05158 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 17:02:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03176; Fri, 3 May 2002 16:43:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03147 for ; Fri, 3 May 2002 16:43:55 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00251 for ; Fri, 3 May 2002 16:43:49 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 16:38:44 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93106@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Georgios Karagiannis (ELN)'" , "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Date: Fri, 3 May 2002 16:38:40 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, I disagree that we need to keep both scenarios. I think they are complementary and should be merged. The discussion about different ways a GW can get QoS from the network (with conclusion that NSIS has to deal with the most general case) from case 8.8 should lead to the presentation of signaling scenarios from 8.9 which is more detailed version of the discussion at the end of section 8.8. Speaking of Media Gateway Controller it is a logical entity that can be found (in my mind) in every PSTN GW and thus does not reduce generality. Regards, Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Monday, April 22, 2002 4:41 AM To: 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Marcus Please receive my comments on Issue (35) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (35): > 35) (OPEN) difference between the two PSTN gateway scenarios > (Section 8.8 and 8.9) > currently both are included > what are the essential issues? [GK] From what I understood Section 8.9 is discussing a specific PSTN gateway [GK] scenario that uses Media Gateway Controllers. Section 8.8 does not do that. [GK] Therefore, I propose that both scenarios should be kept! Best regards, Georgios _______________________________________________ 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 daemon@ns.ietf.org Fri May 3 17:30:07 2002 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 RAA01603 for ; Fri, 3 May 2002 17:30:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06679 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 17:30:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05478; Fri, 3 May 2002 17:08:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05439 for ; Fri, 3 May 2002 17:08:55 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01070 for ; Fri, 3 May 2002 17:08:49 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 17:03:44 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93108@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Georgios Karagiannis (ELN)'" , "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] comments Issue (53) included in draft-ietf-nsis-req-01 Date: Fri, 3 May 2002 17:03:39 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Georgios, In my understanding the recoverable error is a condition when the danger of degradation (or actual short term degradation) of the provided QoS was overcome by the network (QoS controllers). If I am correct could you explain what is potential value to notify about this condition QI or other QC. Regards, Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Monday, April 22, 2002 4:46 AM To: 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: [NSIS] comments Issue (53) included in draft-ietf-nsis-req-01 Hi Marcus Please receive my comments on Issue (53) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (53): > 53) (OPEN) add req 5.1.16. of draft-partain-...-00 Error handling > and redundancy considerations > Border nodes should be able to notify the users if there is an error > inside the network. There are two types of network errors: > - Recoverable errors: this type error can be locally repaired > by the network nodes. The network nodes do not have to > notify the users of the error immediately. > - Unrecoverable errors: the network nodes cannot handle this > type of error, and have to notify the users as soon as > possible. > Comments: > 1) notification of user in case of unrecoverable errors (has been > done by notification req, or will be done by asynch notification > 2) recoverable error (might need to be added) req 5.3.4 is going > into this direction [GK] I propose that both types of errors (recoverable, unrecoverable) [GK] should be explained and included in Section 5.3.4. > 3) what does this mean for different parts of the network > in different parts of the network) [GK] Any QoS Controller should be able to notify these errors to the QoS [GK] Initiator. > 4) hop-by-hop? OR right to the end? [GK] It is not hop by hop, but QoS controller to QoS initiator; Best regards, Georgios _______________________________________________ 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 daemon@ns.ietf.org Fri May 3 18:14:35 2002 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 SAA02078 for ; Fri, 3 May 2002 18:14:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08798 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 18:14:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07818; Fri, 3 May 2002 17:55:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07790 for ; Fri, 3 May 2002 17:55:36 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01833 for ; Fri, 3 May 2002 17:55:30 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 17:50:25 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93109@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Georgios Karagiannis (ELN)'" , "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] comments Issue (59) included in draft-ietf-nsis-req-01 .txt Date: Fri, 3 May 2002 17:50:16 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Georgios, I think this requirement is even closer to the requirement 5.3.4 (notification of QoS violation) than to failure recovery. Actually I fail to see what does it add on top of 5.3.4. What difference does it make (from the QoS perspective) if the provided QoS degraded due to hardware failure on a device or due to congestion caused by failures on some other devices? What is required from the protocol is to signal this failure to other participants (QCs or QI) in the hope that they can do something meaningful (e.g. re-routing) to correct the problem or tear down the flow. Best regards, Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Monday, April 22, 2002 4:54 AM To: 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: [NSIS] comments Issue (59) included in draft-ietf-nsis-req-01.txt Hi Marcus Please receive my comments on Issue (59) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (59): > 59) (OPEN) add req: ability to deal with severe congestion (req > 5.3.4 of draft-partain-..-00 > issues are: > - the use in highly utilized networks > - deos it belong to failure recovery (I would assume from a service > point of view this is failure > - hop by hop problem (issue from Jorge) [GK] I think that this requirement is somehow related to failure recovery, [GK] but is not the same. It occurs in a highly utilised network and [GK] if it is not solved very fast then the network performance will [GK] quickly collapse; [GK] I propose to include it as a separate QoS requirement; Best regards, Georgios _______________________________________________ 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 daemon@ns.ietf.org Fri May 3 18:22:59 2002 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 SAA02191 for ; Fri, 3 May 2002 18:22:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09023 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 18:23:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08760; Fri, 3 May 2002 18:12:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08727 for ; Fri, 3 May 2002 18:12:46 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02072 for ; Fri, 3 May 2002 18:12:42 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 18:07:35 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9310A@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Georgios Karagiannis (ELN)'" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Date: Fri, 3 May 2002 18:07:25 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Let me use this requirement as an example of the aspects of NSIS work that confuse me over and over again. I hope somebody will help me to sort it out: What are we trying to say here? In my mind we want that protocol(s) be able to express an idea of bi-directional reservation. In addition we want to say that support by the QCs of the bi-directional reservation is optional. But combination of these ideas is not properly expressed neither by the statement proposed by John not by Georgios. Regards, Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Monday, April 22, 2002 10:49 AM To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Hi John Yes, I agree the bi-directional requirement is an optional requirement! Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: maandag 22 april 2002 15:35 To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Hi, > Please receive my comments on Issue (8) included in the > NSIS WG draft: draft-ietf-nsis-req-01.txt > > Comment on Issue (8): > > > 8) (OPEN) bi-directional data path setup with one QoS request > > I have not seen consensus on whether to require > bi-directional data > > path setup with QoS. > > - How can we actually perform bi-directional > reservations when the > > forward and reverse paths are not reciprocal, with respect to > > routing topology and routing policy of network domains between > > sender and receiver? > > - The need to ensure that the return path is the same as the > > forwarding path is one of the problems with RSVP, > particularly in a > > mobile environment. > > [GK] The bi-directional data path setup does not need to use the same > [GK] return path as the forwarding path. The only requirement > to achieve > [GK] a bi-directional reservation is that the sender for the > forwarding path > [GK] is also the receiver for the return path and that the > receiver for the > [GK] forwarding path is also the sender for the return path. > [GK] Therefore, I think that the bi-directional option should not be mandatory > [GK] but at least optional; Perhaps 'Bi-directional QoS requests MAY be possible' is enough. 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 daemon@ns.ietf.org Fri May 3 19:51:14 2002 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 TAA03730 for ; Fri, 3 May 2002 19:51:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA12894 for nsis-archive@odin.ietf.org; Fri, 3 May 2002 19:51:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12309; Fri, 3 May 2002 19:32:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12281 for ; Fri, 3 May 2002 19:32:50 -0400 (EDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03327 for ; Fri, 3 May 2002 19:32:46 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g43NWmb05359; Fri, 3 May 2002 16:32:48 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA18687; Fri, 3 May 2002 23:32:48 GMT Date: Fri, 3 May 2002 23:32:48 GMT Message-Id: <200205032332.XAA18687@gra.isi.edu> To: Georgios.Karagiannis@eln.ericsson.se, john.loughney@nokia.com, brunner@ccrle.nec.de, ifreytsis@Cetacean.com Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org *> *> Let me use this requirement as an example of the aspects of NSIS work that *> confuse me over and over again. I hope somebody will help me to sort it out: *> *> What are we trying to say here? In my mind we want that protocol(s) be able *> to express an idea of bi-directional reservation. In addition we want to say *> that support by the QCs of the bi-directional reservation is optional. But *> combination of these ideas is not properly expressed neither by the *> statement proposed by John not by Georgios. *> *> Regards, *> Ilya I am sure I am missing something, but I don't know what you mean by a "bidirectional reservation". If you mean that both directions use the same path, that won't work for the Internet, where the data may use different paths. What am I missing? Bob Braden *> *> -----Original Message----- *> From: Georgios Karagiannis (ELN) *> [mailto:Georgios.Karagiannis@eln.ericsson.se] *> Sent: Monday, April 22, 2002 10:49 AM *> To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de *> Cc: nsis@ietf.org *> Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 *> *> Hi John *> *> Yes, I agree the bi-directional requirement is an optional requirement! *> *> Best regards, *> Georgios *> *> -----Original Message----- *> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] *> Sent: maandag 22 april 2002 15:35 *> To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de *> Cc: nsis@ietf.org *> Subject: RE: [NSIS] comments Issue (8) included in *> draft-ietf-nsis-req-01 *> *> *> Hi, *> *> > Please receive my comments on Issue (8) included in the *> > NSIS WG draft: draft-ietf-nsis-req-01.txt *> > *> > Comment on Issue (8): *> > *> > > 8) (OPEN) bi-directional data path setup with one QoS request *> > > I have not seen consensus on whether to require *> > bi-directional data *> > > path setup with QoS. *> > > - How can we actually perform bi-directional *> > reservations when the *> > > forward and reverse paths are not reciprocal, with respect to *> > > routing topology and routing policy of network domains between *> > > sender and receiver? *> > > - The need to ensure that the return path is the same as the *> > > forwarding path is one of the problems with RSVP, *> > particularly in a *> > > mobile environment. *> > *> > [GK] The bi-directional data path setup does not need to use the same *> > [GK] return path as the forwarding path. The only requirement *> > to achieve *> > [GK] a bi-directional reservation is that the sender for the *> > forwarding path *> > [GK] is also the receiver for the return path and that the *> > receiver for the *> > [GK] forwarding path is also the sender for the return path. *> > [GK] Therefore, I think that the bi-directional option should not be *> mandatory *> > [GK] but at least optional; *> *> Perhaps 'Bi-directional QoS requests MAY be possible' is enough. *> *> 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 *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun May 5 20:05:55 2002 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 UAA24930 for ; Sun, 5 May 2002 20:05:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09510 for nsis-archive@odin.ietf.org; Sun, 5 May 2002 20:06:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08834; Sun, 5 May 2002 19:48:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08806 for ; Sun, 5 May 2002 19:48:00 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24809 for ; Sun, 5 May 2002 19:47:52 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Sun, 5 May 2002 19:42:46 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9310C@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Bob Braden'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Date: Sun, 5 May 2002 19:42:45 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Bob, The topic of my posting was not really the bi-directional reservation but my (and maybe group's as well) confusion with the difference between the protocol requirements and requirements to support various parts of the protocol by the implementations. Speaking of the bi-direction reservations my impressions from what was said on this list is that in some mobile environments it has advantage or preferred over unidirectional. Ilya -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: Friday, May 03, 2002 7:33 PM To: Georgios.Karagiannis@eln.ericsson.se; john.loughney@nokia.com; brunner@ccrle.nec.de; ifreytsis@Cetacean.com Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 *> *> Let me use this requirement as an example of the aspects of NSIS work that *> confuse me over and over again. I hope somebody will help me to sort it out: *> *> What are we trying to say here? In my mind we want that protocol(s) be able *> to express an idea of bi-directional reservation. In addition we want to say *> that support by the QCs of the bi-directional reservation is optional. But *> combination of these ideas is not properly expressed neither by the *> statement proposed by John not by Georgios. *> *> Regards, *> Ilya I am sure I am missing something, but I don't know what you mean by a "bidirectional reservation". If you mean that both directions use the same path, that won't work for the Internet, where the data may use different paths. What am I missing? Bob Braden *> *> -----Original Message----- *> From: Georgios Karagiannis (ELN) *> [mailto:Georgios.Karagiannis@eln.ericsson.se] *> Sent: Monday, April 22, 2002 10:49 AM *> To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de *> Cc: nsis@ietf.org *> Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 *> *> Hi John *> *> Yes, I agree the bi-directional requirement is an optional requirement! *> *> Best regards, *> Georgios *> *> -----Original Message----- *> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] *> Sent: maandag 22 april 2002 15:35 *> To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de *> Cc: nsis@ietf.org *> Subject: RE: [NSIS] comments Issue (8) included in *> draft-ietf-nsis-req-01 *> *> *> Hi, *> *> > Please receive my comments on Issue (8) included in the *> > NSIS WG draft: draft-ietf-nsis-req-01.txt *> > *> > Comment on Issue (8): *> > *> > > 8) (OPEN) bi-directional data path setup with one QoS request *> > > I have not seen consensus on whether to require *> > bi-directional data *> > > path setup with QoS. *> > > - How can we actually perform bi-directional *> > reservations when the *> > > forward and reverse paths are not reciprocal, with respect to *> > > routing topology and routing policy of network domains between *> > > sender and receiver? *> > > - The need to ensure that the return path is the same as the *> > > forwarding path is one of the problems with RSVP, *> > particularly in a *> > > mobile environment. *> > *> > [GK] The bi-directional data path setup does not need to use the same *> > [GK] return path as the forwarding path. The only requirement *> > to achieve *> > [GK] a bi-directional reservation is that the sender for the *> > forwarding path *> > [GK] is also the receiver for the return path and that the *> > receiver for the *> > [GK] forwarding path is also the sender for the return path. *> > [GK] Therefore, I think that the bi-directional option should not be *> mandatory *> > [GK] but at least optional; *> *> Perhaps 'Bi-directional QoS requests MAY be possible' is enough. *> *> 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 *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 6 04:45:30 2002 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 EAA09931 for ; Mon, 6 May 2002 04:45:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05521 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 04:45:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05170; Mon, 6 May 2002 04:35:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05141 for ; Mon, 6 May 2002 04:35:13 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09867 for ; Mon, 6 May 2002 04:35:07 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g468YQ845289; Mon, 6 May 2002 10:34:26 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA05231; Mon, 6 May 2002 10:32:20 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 9D1064469D; Mon, 6 May 2002 10:32:19 +0200 (CEST) Date: Mon, 06 May 2002 10:44:16 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Bob Braden , Georgios.Karagiannis@eln.ericsson.se, john.loughney@nokia.com, ifreytsis@Cetacean.com Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Message-ID: <684664.1020681856@[192.168.102.79]> In-Reply-To: <200205032332.XAA18687@gra.isi.edu> References: <200205032332.XAA18687@gra.isi.edu> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Friday, May 03, 2002 11:32 PM +0000 Bob Braden wrote: > *> > *> Let me use this requirement as an example of the aspects of NSIS > work that *> confuse me over and over again. I hope somebody will help > me to sort it out: *> > *> What are we trying to say here? In my mind we want that protocol(s) > be able *> to express an idea of bi-directional reservation. In > addition we want to say *> that support by the QCs of the > bi-directional reservation is optional. But *> combination of these > ideas is not properly expressed neither by the *> statement proposed by > John not by Georgios. > *> > *> Regards, > *> Ilya > > I am sure I am missing something, but I don't know what you mean by > a "bidirectional reservation". If you mean that both directions use > the same path, that won't work for the Internet, where the data may > use different paths. > > What am I missing? The meaning behind bi-directional as far as I have understood is that both ends (data sender resv 1 == data receiver of stream 2) and vice versa. IMO, the bi-directional setup is an optimization towards low setup delays, however it adds complexity in the end-system stacks. Whether it adds complxity in the core as well is an open question for me. Marcus > > Bob Braden > > *> > *> -----Original Message----- > *> From: Georgios Karagiannis (ELN) > *> [mailto:Georgios.Karagiannis@eln.ericsson.se] > *> Sent: Monday, April 22, 2002 10:49 AM > *> To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de > *> Cc: nsis@ietf.org > *> Subject: RE: [NSIS] comments Issue (8) included in > draft-ietf-nsis-req-01 *> > *> Hi John > *> > *> Yes, I agree the bi-directional requirement is an optional > requirement! *> > *> Best regards, > *> Georgios > *> > *> -----Original Message----- > *> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > *> Sent: maandag 22 april 2002 15:35 > *> To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de > *> Cc: nsis@ietf.org > *> Subject: RE: [NSIS] comments Issue (8) included in > *> draft-ietf-nsis-req-01 > *> > *> > *> Hi, > *> > *> > Please receive my comments on Issue (8) included in the > *> > NSIS WG draft: draft-ietf-nsis-req-01.txt > *> > > *> > Comment on Issue (8): > *> > > *> > > 8) (OPEN) bi-directional data path setup with one QoS request > *> > > I have not seen consensus on whether to require > *> > bi-directional data > *> > > path setup with QoS. > *> > > - How can we actually perform bi-directional > *> > reservations when the > *> > > forward and reverse paths are not reciprocal, with respect to > *> > > routing topology and routing policy of network domains between > *> > > sender and receiver? > *> > > - The need to ensure that the return path is the same as the > *> > > forwarding path is one of the problems with RSVP, > *> > particularly in a > *> > > mobile environment. > *> > > *> > [GK] The bi-directional data path setup does not need to use the > same *> > [GK] return path as the forwarding path. The only requirement > *> > to achieve > *> > [GK] a bi-directional reservation is that the sender for the > *> > forwarding path > *> > [GK] is also the receiver for the return path and that the > *> > receiver for the > *> > [GK] forwarding path is also the sender for the return path. > *> > [GK] Therefore, I think that the bi-directional option should not > be *> mandatory > *> > [GK] but at least optional; > *> > *> Perhaps 'Bi-directional QoS requests MAY be possible' is enough. > *> > *> 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 > *> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 6 05:21:56 2002 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 FAA10443 for ; Mon, 6 May 2002 05:21:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA07000 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 05:22:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06718; Mon, 6 May 2002 05:12:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06685 for ; Mon, 6 May 2002 05:12:18 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10258 for ; Mon, 6 May 2002 05:12:11 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g469CDs7005469 for ; Mon, 6 May 2002 11:12:13 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Mon May 06 11:10:32 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22815TZD>; Mon, 6 May 2002 11:08:08 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Freytsis, Ilya'" , "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Date: Mon, 6 May 2002 11:07: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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Ilya Okay, but this will depend on how they will be merged! Best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: vrijdag 3 mei 2002 22:39 To: 'Georgios Karagiannis (ELN)'; 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Georgios, I disagree that we need to keep both scenarios. I think they are complementary and should be merged. The discussion about different ways a GW can get QoS from the network (with conclusion that NSIS has to deal with the most general case) from case 8.8 should lead to the presentation of signaling scenarios from 8.9 which is more detailed version of the discussion at the end of section 8.8. Speaking of Media Gateway Controller it is a logical entity that can be found (in my mind) in every PSTN GW and thus does not reduce generality. Regards, Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Monday, April 22, 2002 4:41 AM To: 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Marcus Please receive my comments on Issue (35) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (35): > 35) (OPEN) difference between the two PSTN gateway scenarios > (Section 8.8 and 8.9) > currently both are included > what are the essential issues? [GK] From what I understood Section 8.9 is discussing a specific PSTN gateway [GK] scenario that uses Media Gateway Controllers. Section 8.8 does not do that. [GK] Therefore, I propose that both scenarios should be kept! Best regards, Georgios _______________________________________________ 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 daemon@optimus.ietf.org Mon May 6 06:46:31 2002 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 GAA12056 for ; Mon, 6 May 2002 06:46:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA10785 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 06:46:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10569; Mon, 6 May 2002 06:38:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10538 for ; Mon, 6 May 2002 06:38:30 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11699 for ; Mon, 6 May 2002 06:38:23 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g46AcS0E015155 for ; Mon, 6 May 2002 12:38:28 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 06 12:35:09 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <228154KD>; Mon, 6 May 2002 12:32:45 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Bob Braden'" , john.loughney@nokia.com, brunner@ccrle.nec.de, ifreytsis@Cetacean.com Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Date: Mon, 6 May 2002 12:32:22 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Bob >> I am sure I am missing something, but I don't know what you mean by >> a "bidirectional reservation". If you mean that both directions use >> the same path, that won't work for the Internet, where the data may >> use different paths. No, by "bi-directional reservation" we define a resource reservation that applies on both directions, i.e., on the path from sender to receiver and on the path from receiver to sender, which is initiated and maintained by only one of the end points, e.g., the sender. Please note that the path from sender->receiver can be different than the path from receiver->sender. In this way a simpler edge-proxy resource reservation functionality will be implemented in the one of the end points, decreasing its complexity. Best regards, Georgios -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: zaterdag 4 mei 2002 1:33 To: Georgios.Karagiannis@eln.ericsson.se; john.loughney@nokia.com; brunner@ccrle.nec.de; ifreytsis@Cetacean.com Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 *> *> Let me use this requirement as an example of the aspects of NSIS work that *> confuse me over and over again. I hope somebody will help me to sort it out: *> *> What are we trying to say here? In my mind we want that protocol(s) be able *> to express an idea of bi-directional reservation. In addition we want to say *> that support by the QCs of the bi-directional reservation is optional. But *> combination of these ideas is not properly expressed neither by the *> statement proposed by John not by Georgios. *> *> Regards, *> Ilya I am sure I am missing something, but I don't know what you mean by a "bidirectional reservation". If you mean that both directions use the same path, that won't work for the Internet, where the data may use different paths. What am I missing? Bob Braden *> *> -----Original Message----- *> From: Georgios Karagiannis (ELN) *> [mailto:Georgios.Karagiannis@eln.ericsson.se] *> Sent: Monday, April 22, 2002 10:49 AM *> To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de *> Cc: nsis@ietf.org *> Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 *> *> Hi John *> *> Yes, I agree the bi-directional requirement is an optional requirement! *> *> Best regards, *> Georgios *> *> -----Original Message----- *> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] *> Sent: maandag 22 april 2002 15:35 *> To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de *> Cc: nsis@ietf.org *> Subject: RE: [NSIS] comments Issue (8) included in *> draft-ietf-nsis-req-01 *> *> *> Hi, *> *> > Please receive my comments on Issue (8) included in the *> > NSIS WG draft: draft-ietf-nsis-req-01.txt *> > *> > Comment on Issue (8): *> > *> > > 8) (OPEN) bi-directional data path setup with one QoS request *> > > I have not seen consensus on whether to require *> > bi-directional data *> > > path setup with QoS. *> > > - How can we actually perform bi-directional *> > reservations when the *> > > forward and reverse paths are not reciprocal, with respect to *> > > routing topology and routing policy of network domains between *> > > sender and receiver? *> > > - The need to ensure that the return path is the same as the *> > > forwarding path is one of the problems with RSVP, *> > particularly in a *> > > mobile environment. *> > *> > [GK] The bi-directional data path setup does not need to use the same *> > [GK] return path as the forwarding path. The only requirement *> > to achieve *> > [GK] a bi-directional reservation is that the sender for the *> > forwarding path *> > [GK] is also the receiver for the return path and that the *> > receiver for the *> > [GK] forwarding path is also the sender for the return path. *> > [GK] Therefore, I think that the bi-directional option should not be *> mandatory *> > [GK] but at least optional; *> *> Perhaps 'Bi-directional QoS requests MAY be possible' is enough. *> *> 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 *> _______________________________________________ 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 daemon@optimus.ietf.org Mon May 6 08:05:06 2002 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 IAA14214 for ; Mon, 6 May 2002 08:05:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA15002 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 08:05:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14288; Mon, 6 May 2002 07:59:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14255 for ; Mon, 6 May 2002 07:59:40 -0400 (EDT) Received: from bt0g2p.god.bel.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14059 for ; Mon, 6 May 2002 07:59:33 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g46BvBI13343; Mon, 6 May 2002 13:57:11 +0200 Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 To: "Georgios Karagiannis (ELN)" Cc: "'Freytsis, Ilya'" , "'Marcus Brunner'" , "'nsis@ietf.org'" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 6 May 2002 13:58:55 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/06/2002 13:58:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Ilya, Georgios, I agree with Ilya's statement that both scenarios are complementary. That is the reason why we thought they should both be included in the document. I don't think it means that they necessarily should be merged although with some rewriting it could be done. I would propose to keep them as they are unless the majority feels they should be merged. Then I guess it would become an action point for me and Georgios. Sven. "Georgios Karagiannis (ELN)" on 06/05/2002 11:07:44 To: "'Freytsis, Ilya'" , "'Marcus Brunner'" cc: "'nsis@ietf.org'" (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] comments Issue (35) included in : draft-ietf-nsis-req-01 Hi Ilya Okay, but this will depend on how they will be merged! Best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: vrijdag 3 mei 2002 22:39 To: 'Georgios Karagiannis (ELN)'; 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Georgios, I disagree that we need to keep both scenarios. I think they are complementary and should be merged. The discussion about different ways a GW can get QoS from the network (with conclusion that NSIS has to deal with the most general case) from case 8.8 should lead to the presentation of signaling scenarios from 8.9 which is more detailed version of the discussion at the end of section 8.8. Speaking of Media Gateway Controller it is a logical entity that can be found (in my mind) in every PSTN GW and thus does not reduce generality. Regards, Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Monday, April 22, 2002 4:41 AM To: 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Marcus Please receive my comments on Issue (35) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (35): > 35) (OPEN) difference between the two PSTN gateway scenarios > (Section 8.8 and 8.9) > currently both are included > what are the essential issues? [GK] From what I understood Section 8.9 is discussing a specific PSTN gateway [GK] scenario that uses Media Gateway Controllers. Section 8.8 does not do that. [GK] Therefore, I propose that both scenarios should be kept! Best regards, Georgios _______________________________________________ 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 daemon@optimus.ietf.org Mon May 6 08:14:55 2002 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 IAA14493 for ; Mon, 6 May 2002 08:14:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA15491 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 08:15:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15221; Mon, 6 May 2002 08:07:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15187 for ; Mon, 6 May 2002 08:07:15 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14306 for ; Mon, 6 May 2002 08:07:07 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 08:01:55 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9310D@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'sven.van_den_bosch@alcatel.be'" , "Georgios Karagiannis (ELN)" Cc: "Freytsis, Ilya" , "'Marcus Brunner'" , "'nsis@ietf.org'" Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Date: Mon, 6 May 2002 08:01:46 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Sven and Georgios, It is fine to keep both of them while working on requirements since they are used as a source of "inspiration". I probably thought more about future framework document (if it will include scenarios as well) where presence of two cases maybe confusing especially for the novice reader. Ilya -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: Monday, May 06, 2002 7:59 AM To: Georgios Karagiannis (ELN) Cc: 'Freytsis, Ilya'; 'Marcus Brunner'; 'nsis@ietf.org' Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Ilya, Georgios, I agree with Ilya's statement that both scenarios are complementary. That is the reason why we thought they should both be included in the document. I don't think it means that they necessarily should be merged although with some rewriting it could be done. I would propose to keep them as they are unless the majority feels they should be merged. Then I guess it would become an action point for me and Georgios. Sven. "Georgios Karagiannis (ELN)" on 06/05/2002 11:07:44 To: "'Freytsis, Ilya'" , "'Marcus Brunner'" cc: "'nsis@ietf.org'" (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] comments Issue (35) included in : draft-ietf-nsis-req-01 Hi Ilya Okay, but this will depend on how they will be merged! Best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: vrijdag 3 mei 2002 22:39 To: 'Georgios Karagiannis (ELN)'; 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Georgios, I disagree that we need to keep both scenarios. I think they are complementary and should be merged. The discussion about different ways a GW can get QoS from the network (with conclusion that NSIS has to deal with the most general case) from case 8.8 should lead to the presentation of signaling scenarios from 8.9 which is more detailed version of the discussion at the end of section 8.8. Speaking of Media Gateway Controller it is a logical entity that can be found (in my mind) in every PSTN GW and thus does not reduce generality. Regards, Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Monday, April 22, 2002 4:41 AM To: 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Marcus Please receive my comments on Issue (35) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (35): > 35) (OPEN) difference between the two PSTN gateway scenarios > (Section 8.8 and 8.9) > currently both are included > what are the essential issues? [GK] From what I understood Section 8.9 is discussing a specific PSTN gateway [GK] scenario that uses Media Gateway Controllers. Section 8.8 does not do that. [GK] Therefore, I propose that both scenarios should be kept! Best regards, Georgios _______________________________________________ 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 daemon@optimus.ietf.org Mon May 6 08:32:36 2002 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 IAA15669 for ; Mon, 6 May 2002 08:32:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16562 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 08:32:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15833; Mon, 6 May 2002 08:24:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15752 for ; Mon, 6 May 2002 08:24:36 -0400 (EDT) Received: from bt0g2p.god.bel.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15272 for ; Mon, 6 May 2002 08:24:28 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g46CMBZ26012; Mon, 6 May 2002 14:22:11 +0200 Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 To: "Freytsis, Ilya" Cc: "Georgios Karagiannis (ELN)" , "Freytsis, Ilya" , "'Marcus Brunner'" , "'nsis@ietf.org'" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 6 May 2002 14:23:54 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/06/2002 14:23:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Ilya, OK, let's make a mental note that we can merge them if needed if that turns out to be the case. Sven. "Freytsis, Ilya" on 06/05/2002 14:01:46 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, "Georgios Karagiannis (ELN)" cc: "Freytsis, Ilya" , "'Marcus Brunner'" , "'nsis@ietf.org'" Subject RE: [NSIS] comments Issue (35) included in : draft-ietf-nsis-req-01 Sven and Georgios, It is fine to keep both of them while working on requirements since they are used as a source of "inspiration". I probably thought more about future framework document (if it will include scenarios as well) where presence of two cases maybe confusing especially for the novice reader. Ilya -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: Monday, May 06, 2002 7:59 AM To: Georgios Karagiannis (ELN) Cc: 'Freytsis, Ilya'; 'Marcus Brunner'; 'nsis@ietf.org' Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Ilya, Georgios, I agree with Ilya's statement that both scenarios are complementary. That is the reason why we thought they should both be included in the document. I don't think it means that they necessarily should be merged although with some rewriting it could be done. I would propose to keep them as they are unless the majority feels they should be merged. Then I guess it would become an action point for me and Georgios. Sven. "Georgios Karagiannis (ELN)" on 06/05/2002 11:07:44 To: "'Freytsis, Ilya'" , "'Marcus Brunner'" cc: "'nsis@ietf.org'" (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] comments Issue (35) included in : draft-ietf-nsis-req-01 Hi Ilya Okay, but this will depend on how they will be merged! Best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: vrijdag 3 mei 2002 22:39 To: 'Georgios Karagiannis (ELN)'; 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Georgios, I disagree that we need to keep both scenarios. I think they are complementary and should be merged. The discussion about different ways a GW can get QoS from the network (with conclusion that NSIS has to deal with the most general case) from case 8.8 should lead to the presentation of signaling scenarios from 8.9 which is more detailed version of the discussion at the end of section 8.8. Speaking of Media Gateway Controller it is a logical entity that can be found (in my mind) in every PSTN GW and thus does not reduce generality. Regards, Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Monday, April 22, 2002 4:41 AM To: 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Marcus Please receive my comments on Issue (35) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (35): > 35) (OPEN) difference between the two PSTN gateway scenarios > (Section 8.8 and 8.9) > currently both are included > what are the essential issues? [GK] From what I understood Section 8.9 is discussing a specific PSTN gateway [GK] scenario that uses Media Gateway Controllers. Section 8.8 does not do that. [GK] Therefore, I propose that both scenarios should be kept! Best regards, Georgios _______________________________________________ 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 6 08:32:51 2002 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 IAA15706 for ; Mon, 6 May 2002 08:32:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16590 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 08:32:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15879; Mon, 6 May 2002 08:25:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15849 for ; Mon, 6 May 2002 08:25:08 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15352 for ; Mon, 6 May 2002 08:25:00 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g46CP60E014804 for ; Mon, 6 May 2002 14:25:06 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 06 14:24:24 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22815VBG>; Mon, 6 May 2002 14:21:59 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'sven.van_den_bosch@alcatel.be'" , "Georgios Karagiannis (ELN)" Cc: "'Freytsis, Ilya'" , "'Marcus Brunner'" , "'nsis@ietf.org'" Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Date: Mon, 6 May 2002 14:23:45 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi I agree with the proposal of Sven! Best regards, Georgios -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: maandag 6 mei 2002 13:59 To: Georgios Karagiannis (ELN) Cc: 'Freytsis, Ilya'; 'Marcus Brunner'; 'nsis@ietf.org' Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Ilya, Georgios, I agree with Ilya's statement that both scenarios are complementary. That is the reason why we thought they should both be included in the document. I don't think it means that they necessarily should be merged although with some rewriting it could be done. I would propose to keep them as they are unless the majority feels they should be merged. Then I guess it would become an action point for me and Georgios. Sven. "Georgios Karagiannis (ELN)" on 06/05/2002 11:07:44 To: "'Freytsis, Ilya'" , "'Marcus Brunner'" cc: "'nsis@ietf.org'" (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] comments Issue (35) included in : draft-ietf-nsis-req-01 Hi Ilya Okay, but this will depend on how they will be merged! Best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: vrijdag 3 mei 2002 22:39 To: 'Georgios Karagiannis (ELN)'; 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: RE: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Georgios, I disagree that we need to keep both scenarios. I think they are complementary and should be merged. The discussion about different ways a GW can get QoS from the network (with conclusion that NSIS has to deal with the most general case) from case 8.8 should lead to the presentation of signaling scenarios from 8.9 which is more detailed version of the discussion at the end of section 8.8. Speaking of Media Gateway Controller it is a logical entity that can be found (in my mind) in every PSTN GW and thus does not reduce generality. Regards, Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Monday, April 22, 2002 4:41 AM To: 'Marcus Brunner' Cc: 'nsis@ietf.org' Subject: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Hi Marcus Please receive my comments on Issue (35) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (35): > 35) (OPEN) difference between the two PSTN gateway scenarios > (Section 8.8 and 8.9) > currently both are included > what are the essential issues? [GK] From what I understood Section 8.9 is discussing a specific PSTN gateway [GK] scenario that uses Media Gateway Controllers. Section 8.8 does not do that. [GK] Therefore, I propose that both scenarios should be kept! Best regards, Georgios _______________________________________________ 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 daemon@ns.ietf.org Mon May 6 15:01:32 2002 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 PAA03138 for ; Mon, 6 May 2002 15:01:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13250 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 15:01:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12407; Mon, 6 May 2002 14:52:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12372 for ; Mon, 6 May 2002 14:52:46 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02780 for ; Mon, 6 May 2002 14:52:38 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 14:47:31 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93113@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'john.loughney@nokia.com'" , brunner@ccrle.nec.de, Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Mon, 6 May 2002 14:47:25 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I support the idea to leave this requirement out. If you add 3d party requesting case (SIP proxy, application proxy, softswitch, you name it) than you see that QI does not necessarily represent neither receiver nor sender and the whole question becomes a moot point. As Marcus has mentioned as soon as we agreed that signaling path might differ from the data path we'd better not associate QI with any particular end of the data flow. It seems that it can be useful if NSIS protocol semantics allows a QI to request the bi-directional reservation but it can be rejected by the QC if employed QoS mechanism does not support it. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, May 02, 2002 1:49 PM To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Marcus, > The question is what are we doing with the requirement? > Both you and John favour > SHOULD support sender initiated > MAY support reciever initiated > > I would completly remove any requirements regarding initation. If we include requirements for initiation, I favor the above. However, I am not bothered if this is left out. 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 daemon@ns.ietf.org Mon May 6 19:14:20 2002 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 TAA10759 for ; Mon, 6 May 2002 19:14:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01330 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 19:14:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01022; Mon, 6 May 2002 19:06:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00989 for ; Mon, 6 May 2002 19:06:29 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10472 for ; Mon, 6 May 2002 19:06:21 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 19:01:13 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93119@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Geib, Ruediger'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] Operational QoS signaling protocol requirements Date: Mon, 6 May 2002 19:01:04 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Ruediger, Marcus, Georgios and John, I have finally managed through my mail and would like to add my two cents. I am not convinced that the new requirement section is needed but I did find useful some of the proposed requirements. Most of them can be at home in section 5.1, I believe. I like that every requirement attempts to make a clear statement what is expected from the protocol. See comments in-line. Regards, Ilya -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: Thursday, May 02, 2002 5:56 AM To: brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: [NSIS] Operational QoS signaling protocol requirements Dear Markus, By and large operational NSIS protocol requirements miss in the requirements draft. I'd suggest to add: 5.12 Operational Stability The design of an NSIS protocol must provide a maximum of operational stability. The state of a unit involved into NSIS signalling must be stable no matter what the surronding conditions are. This leads to the following requirements: 5.12.1 Backwards compatibility A later version of an NSIS protocol must be backwards compatible with earlier versions of an NSIS protocol. IF> I like this requirement since it helps prevent design decisions that are short sighted and may make interoperability of the future version of the protocol more difficult and painful. 5.12.2 Unexpected situations and error restistance An NSIS protocol must define behaviour of NSIS signaling units during unexpected situations. Unexpected situtions are unknown messages, parameters and parameter settings as well as receiption of unexpected messages (e.g. a "Reservation Confirmation" without prior "Reservation Request"). IF> Basically you are saying that the state machine behind the protocol shall be complete (shall describe how react to any received message in any state). I do not think it is a requirement for NSIS since it is applicable to any signaling protocol but rather a guideline for the protocol designers. To be honest I cannot imagine how the NSIS protocol can be designed in any other way. 5.12.3 Default behaviour An NSIS protocol must define default behaviours and parameter settings wherever applicable. IF> I can make the same comment as above 5.12.4 Extendability An NSIS protocol must provide means to enhance a protocol with future procedures, messages, parameters and parameter settings. 5.12.5 Preventation of stale state An NSIS signalling protocol must provide means for an NSIS signaling unit to discover and remove local stale state. This may for example be done by means like soft state and periodic flooding or by a polling mechanism and hard state signaling. IF> I tend to agree with John that we have already had a number of requirements to address this or similar concerns. They may need better wording and clarification but not a new one. 5.12.6 Reliable Communication NSIS signaling procedures, connectivity between units involved in NSIS signaling as well as the basic transport protocol used by NSIS must provide a maximum of communication reliability. Procedures must define how an NSIS signaling systems behaves if some kind of request it sent stays without answer (this could require e.g. be timers, number of message retransmits and release messages). An NSIS signaling unit must be able to check its connectivity to an adjacent NSIS signaling unit at any time (this requirement must however not result in a DoS attack tool - the frequency of these checks must be limited, and flow control may be useful). The basic transport protocol to be used between adjacent NSIS units must ensure message integrity and reliable transport. IF> I would rephrase this requirement along the following line: NSIS protocol must specify procedures that guarantee reliable message delivery for every transport protocol it may ride on. 5.12.7 Smooth breakdown A unit participating in NSIS signaling must no cause further damage to other systems involved in NSIS signaling when it has to go out of service. IF> I think this one is a subset of 5.12.2. If 5.12.2 is achieved than NSIS signaling entity whether it breaks down smoothly or not will bring no damage to others. Regards, Rüdiger Rüdiger Geib Senior Expert T-Systems Nova GmbH Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 832138 Fax: +49 6151 838103 mailto:Ruediger.Geib@t-systems.com http://www.t-nova.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 daemon@ns.ietf.org Mon May 6 20:11:40 2002 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 UAA11800 for ; Mon, 6 May 2002 20:11:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04699 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 20:11:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04263; Mon, 6 May 2002 20:02:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04226 for ; Mon, 6 May 2002 20:02:53 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11561 for ; Mon, 6 May 2002 20:02:44 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4701lO05197 for ; Tue, 7 May 2002 03:01:47 +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, 7 May 2002 03:02:50 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 7 May 2002 03:02:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 7 May 2002 03:02:49 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8ECD2@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Thread-Index: AcH0j3S03a7/3Q2wSHuyBTIl+ww20AAkGitw To: , Cc: X-OriginalArrivalTime: 07 May 2002 00:02:50.0260 (UTC) FILETIME=[86EC9D40:01C1F55A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA04229 Subject: [NSIS] bi-directional signaling Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Ilya said: > The topic of my posting was not really the bi-directional > reservation but my > (and maybe group's as well) confusion with the difference between the > protocol requirements and requirements to support various parts of the > protocol by the implementations. > Speaking of the bi-direction reservations my impressions from > what was said > on this list is that in some mobile environments it has advantage or > preferred over unidirectional. [clip] Bob said: > I am sure I am missing something, but I don't know what you mean by > a "bidirectional reservation". If you mean that both directions use > the same path, that won't work for the Internet, where the data may > use different paths. Bi-directional signaling in NSIS SHOULD only be about the signaling, not about the nature of the reservation. It is my opinion that, within NSIS, the path which the data takes maybe an orthoginal issue. For the requirements draft, the issue if bi-directional signaling should only apply to if an endpoint signals both the inbound/outbound, uplink/downlink, sending/receiving (pick your favorite terminology) QoS needs. I wouldn't mind that a NSIS protocol support this, so a MAY or SHOULD would be nice to have in the requirements. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon May 6 20:13:27 2002 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 UAA11872 for ; Mon, 6 May 2002 20:13:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04738 for nsis-archive@odin.ietf.org; Mon, 6 May 2002 20:13:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04211; Mon, 6 May 2002 20:02:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04181 for ; Mon, 6 May 2002 20:02:49 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11556 for ; Mon, 6 May 2002 20:02:40 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g47036n06035 for ; Tue, 7 May 2002 03:03:07 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 7 May 2002 03:02:42 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 7 May 2002 03:02:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Tue, 7 May 2002 03:02:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8ECC9@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Thread-Index: AcHyrWYyUp0r7R90Q2KpVvVi1pbzCACbF0XA To: , , Cc: , X-OriginalArrivalTime: 07 May 2002 00:02:46.0432 (UTC) FILETIME=[84A48200:01C1F55A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA04182 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gary, > Can we guarantee that the semantics of the signalling do not change > depending on whether it is sender initiated or receiver initiated? > Probably not. As we are now discussing requirements, perhaps we could discuss if the requirements are different based upon sender vs. receiver initiated signaling. As a strawman, here are some ideas (not all good ideas ...) For example, for sender initiated, can we support implicit signaling (bundling the QoS requests with other signaling - registration, etc.)? For reciever initiated, do we need protoection against spamming - how do we protect against unwanted changes? There are some more things, are these relevant? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 7 00:29:42 2002 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 AAA18552 for ; Tue, 7 May 2002 00:29:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA18778 for nsis-archive@odin.ietf.org; Tue, 7 May 2002 00:29:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18109; Tue, 7 May 2002 00:18:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18078 for ; Tue, 7 May 2002 00:18:09 -0400 (EDT) Received: from eudoramail.com ([217.78.74.104]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18179 for ; Tue, 7 May 2002 00:17:52 -0400 (EDT) Message-Id: <200205070417.AAA18179@ietf.org> From: "MR.Michael Onyeze" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 7 May 2002 04:22:00 +0200 Reply-To: "MR.Michael Onyeze" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [NSIS] (no subject) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Mr.Michael Onyeze. 178 Dikko close Lagos-Nigeria Fax:234 1 7591693 Attn: President/Ceo. In order to transfer out Fifty Two Million United States Dollars from African Development Bank. I wish to ask for your assistance, believing that you will never let me down either now or in future. I got your e-mail address from the e-mail directory in the internet. I am Mr. Michael Onyeze, the Chief Auditor of African Development Bank (ADB). There was an account opened in this bank in 1983 and since 1989 nobody has operated on this account till date. After my long investigation to my greatest suprise I came to find out that the owner of the account who is Mr.Peter B. Andreas, a foreigner, crude oil exporter, who died in 1990. This account has no beneficiary, infact no other person knows about this account or anything about the account, and my investigation proved to me as well that this company does not exist anymore in NIgeria. The amount involved is USD 52M, which i seek your consent to transfer to a safe foreign account. I do not know any foreigner that i can trust either than you, I am only contacting you as a foreigner because this money can not be claimed by a Nigerian because the rightful owner of the account (Mr. Peter) is a foreigner and has dead. I know that this mail will come to you as a surprise as we do not know each other before hand. we will be needed to sign an Agreement as a security so that we cannot betray the trust that will be given to each other in this legitimate and joint venture, which demand utmost secrecy and confidential. I am contacting you because of the need to involve a foreigner with foreign account and foreign beneficiary. I need your full co-operation for us to have a successful transaction. Because the management is ready to approve this payment to any foreigner who has correct information of this account, which I will give to you immediately i receive your positive reply. With my position now in the office I can authorise the immediate transfer of this money to any foreign reliable account which you can provide with assurance that this money will be intact pending my physical arrival in your country for sharing and further investment. I will destroy all documents used in this transaction immediately we must have transferred this money to your nominated account sucessfully, so as to avoid any document trace by any person. I will apply for annual leave to get visa to your country immediately you confirm me that you are willing to assist me. I will also use my position and influence to effect legal approvals and onward transfer of this money to your account with appropriate clearance forms of the ministries and foreign exchange departments. At the conclusion of this business, you will be given 20% of the total amount, 75% will be for me, while 5% will be for expenses both parties might have incurred during the process of transferring. Awaiting your urgent reply and please do not FORGET TO INCLUDE YOUR PRIVATE FAX AND TELEPHONE NUMBERS FOR EASY COMMUNICATION. Thank you and God bless. Yours truly, Mr.Michael Onyeze. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 7 06:07:22 2002 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 GAA01319 for ; Tue, 7 May 2002 06:07:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA12187 for nsis-archive@odin.ietf.org; Tue, 7 May 2002 06:07:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11710; Tue, 7 May 2002 06:00:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11678 for ; Tue, 7 May 2002 06:00:43 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01207 for ; Tue, 7 May 2002 06:00:35 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g47A0fs7013975 for ; Tue, 7 May 2002 12:00:41 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue May 07 10:52:37 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22815YL5>; Tue, 7 May 2002 10:52:09 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , ifreytsis@Cetacean.com, braden@ISI.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] bi-directional signaling Date: Tue, 7 May 2002 10:51:54 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi I agree with John! Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: dinsdag 7 mei 2002 2:03 To: ifreytsis@Cetacean.com; braden@ISI.EDU Cc: nsis@ietf.org Subject: [NSIS] bi-directional signaling Hi all, Ilya said: > The topic of my posting was not really the bi-directional > reservation but my > (and maybe group's as well) confusion with the difference between the > protocol requirements and requirements to support various parts of the > protocol by the implementations. > Speaking of the bi-direction reservations my impressions from > what was said > on this list is that in some mobile environments it has advantage or > preferred over unidirectional. [clip] Bob said: > I am sure I am missing something, but I don't know what you mean by > a "bidirectional reservation". If you mean that both directions use > the same path, that won't work for the Internet, where the data may > use different paths. Bi-directional signaling in NSIS SHOULD only be about the signaling, not about the nature of the reservation. It is my opinion that, within NSIS, the path which the data takes maybe an orthoginal issue. For the requirements draft, the issue if bi-directional signaling should only apply to if an endpoint signals both the inbound/outbound, uplink/downlink, sending/receiving (pick your favorite terminology) QoS needs. I wouldn't mind that a NSIS protocol support this, so a MAY or SHOULD would be nice to have in the requirements. 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 daemon@optimus.ietf.org Tue May 7 07:10:29 2002 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 HAA02006 for ; Tue, 7 May 2002 07:10:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15238 for nsis-archive@odin.ietf.org; Tue, 7 May 2002 07:10:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14438; Tue, 7 May 2002 06:54:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14411 for ; Tue, 7 May 2002 06:54:07 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01885 for ; Tue, 7 May 2002 06:53:59 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g47As60E025862 for ; Tue, 7 May 2002 12:54:06 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue May 07 11:53:53 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 11:53:24 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Tue, 7 May 2002 11:53:09 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Ilya Maybe the terminology (in the NSIS requirements draft) is not clear, but what I mean with: * a sender initiated approach is that the sender of the data path starts the reservation towards the receiver, and * in the receiver initiated approach the receiver of the data path starts the reservation towards the sender. Additionally, note that the triggering of this initiation can also be done by entities that are not sender or receiver of the data path. In other words: * in a sender initiated approach, a QI, a QC or a QR that is not the sender of the data path will have to trigger the sender of the data path to start a sender initiated reservation. * in a receiver initiated approach, a QI, a QC or a QR that is not the receiver of the data path will have to trigger the receiver of the data path to start a receiver initiated reservation. I hope that this makes it more clear!! Best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: maandag 6 mei 2002 20:47 To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt I support the idea to leave this requirement out. If you add 3d party requesting case (SIP proxy, application proxy, softswitch, you name it) than you see that QI does not necessarily represent neither receiver nor sender and the whole question becomes a moot point. As Marcus has mentioned as soon as we agreed that signaling path might differ from the data path we'd better not associate QI with any particular end of the data flow. It seems that it can be useful if NSIS protocol semantics allows a QI to request the bi-directional reservation but it can be rejected by the QC if employed QoS mechanism does not support it. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, May 02, 2002 1:49 PM To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Marcus, > The question is what are we doing with the requirement? > Both you and John favour > SHOULD support sender initiated > MAY support reciever initiated > > I would completly remove any requirements regarding initation. If we include requirements for initiation, I favor the above. However, I am not bothered if this is left out. 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 daemon@optimus.ietf.org Tue May 7 10:16:10 2002 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 KAA09141 for ; Tue, 7 May 2002 10:16:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28376 for nsis-archive@odin.ietf.org; Tue, 7 May 2002 10:16:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27962; Tue, 7 May 2002 10:10:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27931 for ; Tue, 7 May 2002 10:10:42 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08782 for ; Tue, 7 May 2002 10:10:34 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 10:05:26 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9311E@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Georgios Karagiannis (ELN)'" , "Freytsis, Ilya" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Tue, 7 May 2002 10:05:20 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Georgios, Thanks for the detailed explanation. Unfortunately I think we have quite a different picture in mind. Yours I think originated in RSVP world but let's look at the case when you have centralized bandwidth broker (QC) managing pre-provisioned LSPs. The scenario I have in mind is this: 1. Endhosts (sender and receiver, let's say gaming consoles) do not speak NSIS and are not aware of any bandwidth provisioning 2. An application level entity (gaming server) exists somewhere on the network and acts as a QI for both of them by requesting network resources for the session from the bandwidth broker (QC) via NSIS signaling 3. The bandwidth broker accepts session and replies via NSIS to the server (QI). 4. The gaming server signal to the endhosts in the application specific way that the session is setup. I do not see place for the notion of sender/receiver-initiated approach in this case. What do you think? Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Tuesday, May 07, 2002 5:53 AM To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Ilya Maybe the terminology (in the NSIS requirements draft) is not clear, but what I mean with: * a sender initiated approach is that the sender of the data path starts the reservation towards the receiver, and * in the receiver initiated approach the receiver of the data path starts the reservation towards the sender. Additionally, note that the triggering of this initiation can also be done by entities that are not sender or receiver of the data path. In other words: * in a sender initiated approach, a QI, a QC or a QR that is not the sender of the data path will have to trigger the sender of the data path to start a sender initiated reservation. * in a receiver initiated approach, a QI, a QC or a QR that is not the receiver of the data path will have to trigger the receiver of the data path to start a receiver initiated reservation. I hope that this makes it more clear!! Best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: maandag 6 mei 2002 20:47 To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt I support the idea to leave this requirement out. If you add 3d party requesting case (SIP proxy, application proxy, softswitch, you name it) than you see that QI does not necessarily represent neither receiver nor sender and the whole question becomes a moot point. As Marcus has mentioned as soon as we agreed that signaling path might differ from the data path we'd better not associate QI with any particular end of the data flow. It seems that it can be useful if NSIS protocol semantics allows a QI to request the bi-directional reservation but it can be rejected by the QC if employed QoS mechanism does not support it. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, May 02, 2002 1:49 PM To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Marcus, > The question is what are we doing with the requirement? > Both you and John favour > SHOULD support sender initiated > MAY support reciever initiated > > I would completly remove any requirements regarding initation. If we include requirements for initiation, I favor the above. However, I am not bothered if this is left out. 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 daemon@optimus.ietf.org Tue May 7 11:10:48 2002 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 LAA11525 for ; Tue, 7 May 2002 11:10:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03273 for nsis-archive@odin.ietf.org; Tue, 7 May 2002 11:10:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01898; Tue, 7 May 2002 10:59:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01862 for ; Tue, 7 May 2002 10:59:00 -0400 (EDT) Received: from bt0g2p.god.bel.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11085 for ; Tue, 7 May 2002 10:58:53 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g47EuQb08158; Tue, 7 May 2002 16:56:26 +0200 Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt To: "Freytsis, Ilya" Cc: "'Georgios Karagiannis (ELN)'" , "Freytsis, Ilya" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 7 May 2002 16:58:13 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/07/2002 16:58:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Ilya, I like the scenario that you propose. I think we can conclude from it that any entity on or off the data path can assume the role of a QI for the purpose of nsis signaling. In that respect, it seems logical that only sender-initiated signaling needs to be supported, where sender-initiated refers to the entity that initiates the nsis reservation, not the data flow. You could eliminate the requirement, although I would be more in favour to add this explanation and keep the requirement. It is still possible that the QI triggers the QR and resources are only reserved on the way back Sven "Freytsis, Ilya" on 07/05/2002 16:05:20 To: "'Georgios Karagiannis (ELN)'" , "Freytsis, Ilya" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de cc: nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] comments Issue (2) included : indraft-ietf-nsis-req-01. txt Georgios, Thanks for the detailed explanation. Unfortunately I think we have quite a different picture in mind. Yours I think originated in RSVP world but let's look at the case when you have centralized bandwidth broker (QC) managing pre-provisioned LSPs. The scenario I have in mind is this: 1. Endhosts (sender and receiver, let's say gaming consoles) do not speak NSIS and are not aware of any bandwidth provisioning 2. An application level entity (gaming server) exists somewhere on the network and acts as a QI for both of them by requesting network resources for the session from the bandwidth broker (QC) via NSIS signaling 3. The bandwidth broker accepts session and replies via NSIS to the server (QI). 4. The gaming server signal to the endhosts in the application specific way that the session is setup. I do not see place for the notion of sender/receiver-initiated approach in this case. What do you think? Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Tuesday, May 07, 2002 5:53 AM To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Ilya Maybe the terminology (in the NSIS requirements draft) is not clear, but what I mean with: * a sender initiated approach is that the sender of the data path starts the reservation towards the receiver, and * in the receiver initiated approach the receiver of the data path starts the reservation towards the sender. Additionally, note that the triggering of this initiation can also be done by entities that are not sender or receiver of the data path. In other words: * in a sender initiated approach, a QI, a QC or a QR that is not the sender of the data path will have to trigger the sender of the data path to start a sender initiated reservation. * in a receiver initiated approach, a QI, a QC or a QR that is not the receiver of the data path will have to trigger the receiver of the data path to start a receiver initiated reservation. I hope that this makes it more clear!! Best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: maandag 6 mei 2002 20:47 To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt I support the idea to leave this requirement out. If you add 3d party requesting case (SIP proxy, application proxy, softswitch, you name it) than you see that QI does not necessarily represent neither receiver nor sender and the whole question becomes a moot point. As Marcus has mentioned as soon as we agreed that signaling path might differ from the data path we'd better not associate QI with any particular end of the data flow. It seems that it can be useful if NSIS protocol semantics allows a QI to request the bi-directional reservation but it can be rejected by the QC if employed QoS mechanism does not support it. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, May 02, 2002 1:49 PM To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Marcus, > The question is what are we doing with the requirement? > Both you and John favour > SHOULD support sender initiated > MAY support reciever initiated > > I would completly remove any requirements regarding initation. If we include requirements for initiation, I favor the above. However, I am not bothered if this is left out. 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 7 12:15:00 2002 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 MAA14210 for ; Tue, 7 May 2002 12:15:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08888 for nsis-archive@odin.ietf.org; Tue, 7 May 2002 12:15:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08489; Tue, 7 May 2002 12:06:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08458 for ; Tue, 7 May 2002 12:06:28 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14021 for ; Tue, 7 May 2002 12:06:20 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g47G6Ps7014942 for ; Tue, 7 May 2002 18:06:26 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue May 07 17:15:27 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 17:12:45 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'sven.van_den_bosch@alcatel.be'" , "Freytsis, Ilya" Cc: "Freytsis, Ilya" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de, nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Tue, 7 May 2002 17:15:24 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Sven The terms sender initiated and receiver initiated are terms that are used and applied in IETF since many years, see e.g., RFC 1633. Both are referring to the data path. I understand that if you will use bandwidth broker scenarios these terms will not make much sense, but the bandwidth brokering scenario is not the only scenario that the NSIS WG is considering! I am afraid that this bandwidth brokering scenarios complicate the NSIS protocol very much! I would suggest to use the terms sender initiated and receiver initiated as defined in e.g., RFC1633. Additionally I would keep the requirement about sender initiated and receiver initiated. best regards, Georgios -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: dinsdag 7 mei 2002 16:58 To: Freytsis, Ilya Cc: 'Georgios Karagiannis (ELN)'; Freytsis, Ilya; 'john.loughney@nokia.com'; brunner@ccrle.nec.de; nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Ilya, I like the scenario that you propose. I think we can conclude from it that any entity on or off the data path can assume the role of a QI for the purpose of nsis signaling. In that respect, it seems logical that only sender-initiated signaling needs to be supported, where sender-initiated refers to the entity that initiates the nsis reservation, not the data flow. You could eliminate the requirement, although I would be more in favour to add this explanation and keep the requirement. It is still possible that the QI triggers the QR and resources are only reserved on the way back Sven "Freytsis, Ilya" on 07/05/2002 16:05:20 To: "'Georgios Karagiannis (ELN)'" , "Freytsis, Ilya" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de cc: nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] comments Issue (2) included : indraft-ietf-nsis-req-01. txt Georgios, Thanks for the detailed explanation. Unfortunately I think we have quite a different picture in mind. Yours I think originated in RSVP world but let's look at the case when you have centralized bandwidth broker (QC) managing pre-provisioned LSPs. The scenario I have in mind is this: 1. Endhosts (sender and receiver, let's say gaming consoles) do not speak NSIS and are not aware of any bandwidth provisioning 2. An application level entity (gaming server) exists somewhere on the network and acts as a QI for both of them by requesting network resources for the session from the bandwidth broker (QC) via NSIS signaling 3. The bandwidth broker accepts session and replies via NSIS to the server (QI). 4. The gaming server signal to the endhosts in the application specific way that the session is setup. I do not see place for the notion of sender/receiver-initiated approach in this case. What do you think? Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Tuesday, May 07, 2002 5:53 AM To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Ilya Maybe the terminology (in the NSIS requirements draft) is not clear, but what I mean with: * a sender initiated approach is that the sender of the data path starts the reservation towards the receiver, and * in the receiver initiated approach the receiver of the data path starts the reservation towards the sender. Additionally, note that the triggering of this initiation can also be done by entities that are not sender or receiver of the data path. In other words: * in a sender initiated approach, a QI, a QC or a QR that is not the sender of the data path will have to trigger the sender of the data path to start a sender initiated reservation. * in a receiver initiated approach, a QI, a QC or a QR that is not the receiver of the data path will have to trigger the receiver of the data path to start a receiver initiated reservation. I hope that this makes it more clear!! Best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: maandag 6 mei 2002 20:47 To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt I support the idea to leave this requirement out. If you add 3d party requesting case (SIP proxy, application proxy, softswitch, you name it) than you see that QI does not necessarily represent neither receiver nor sender and the whole question becomes a moot point. As Marcus has mentioned as soon as we agreed that signaling path might differ from the data path we'd better not associate QI with any particular end of the data flow. It seems that it can be useful if NSIS protocol semantics allows a QI to request the bi-directional reservation but it can be rejected by the QC if employed QoS mechanism does not support it. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, May 02, 2002 1:49 PM To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Marcus, > The question is what are we doing with the requirement? > Both you and John favour > SHOULD support sender initiated > MAY support reciever initiated > > I would completly remove any requirements regarding initation. If we include requirements for initiation, I favor the above. However, I am not bothered if this is left out. 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 7 15:54:10 2002 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 PAA22361 for ; Tue, 7 May 2002 15:54:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15668 for nsis-archive@odin.ietf.org; Tue, 7 May 2002 15:54:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15012; Tue, 7 May 2002 15:44:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14978 for ; Tue, 7 May 2002 15:44:20 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22030 for ; Tue, 7 May 2002 15:44:11 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g47JhXO15018; Tue, 7 May 2002 15:43:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 15:43:36 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A9D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" , fu@ee.tu-berlin.de, brunner@ccrle.nec.de Cc: Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Tue, 7 May 2002 15:43:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F5FF.81CFFB22" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1F5FF.81CFFB22 Content-Type: text/plain; charset="iso-8859-1" Good thoughts John. I was thinking more along the line that the sender begins by stating "this is the QoS I want use when I send to you", versus the receiver asking "I would like you to send to me using this QoS". To make the semantic difference in this example a bit more real, the first statement absolutely requires a confirmation from the receiver, in the second case, the sender can response by simply establishing the QoS, and starting to send. The semantics are different enough to warrant different protocol exchanges in this simplistic example, I think. As for bundling, I have just been reviewing some ideas being tossed around for SDPng. There is a good case to be made for providing QoS specification with the session description. This is end to end QoS, of course, involving end-to-end negotiation that is will likely be coupled with other aspects of the session description. The material I was reading explicitly stated that QoS provisioning [along the path network] was not part of SDPng. However, my question is: how can two end systems negotiated session parameters without negotiating QoS? And, if the end systems are negotiating QoS, how can they do so without involving the network (or at least, having a fairly extensive a priori view of what QoS is available, end-to-end). Likewise, how does can the QI negotiate with the QC without the result impacting the session description, particularly the non-QoS components of the session description? A simple example of this is bandwidth: if, for example, the end hosts agree on G.711 for voice, then there is a minimum bandwidth requirement that must be met. This may be slightly off of what you had in mind in terms of bundling, but your suggestion raised the issue of the co-dependency between QoS and media type selection in SDPng. Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: May 6, 2002 20:03 > To: Kenward, Gary [WDLN2:AN10:EXCH]; fu@ee.tu-berlin.de; > brunner@ccrle.nec.de > Cc: Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > Hi Gary, > > > Can we guarantee that the semantics of the signalling do not change > > depending on whether it is sender initiated or receiver initiated? > > Probably not. > > As we are now discussing requirements, perhaps we could discuss if > the requirements are different based upon sender vs. receiver > initiated > signaling. > > As a strawman, here are some ideas (not all good ideas ...) > > For example, for sender initiated, can we support implicit signaling > (bundling the QoS requests with other signaling - registration, etc.)? > > For reciever initiated, do we need protoection against spamming - > how do we protect against unwanted changes? > > There are some more things, are these relevant? > > John > ------_=_NextPart_001_01C1F5FF.81CFFB22 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt

Good thoughts John.

I was thinking more along the line that the sender begins by stating
"this is the QoS I want use when I send to you", versus the receiver asking
"I would like you to send to me using this QoS". To make the semantic
difference in this example a bit more real, the first statement absolutely
requires a confirmation from the receiver, in the second case, the sender can
response by simply establishing the QoS, and starting to send.

The semantics are different enough to warrant different protocol exchanges in
this simplistic example, I think.

As for bundling, I have just been reviewing some ideas being tossed around for
SDPng. There is a good case to be made for providing QoS specification with the
session description. This is end to end QoS, of course, involving end-to-end negotiation
that is will likely be coupled with other aspects of the session description. The
material I was reading explicitly stated that QoS provisioning [along the path network]
was not part of SDPng. However, my question is: how can two end systems negotiated session
parameters without negotiating QoS? And, if the end systems are negotiating QoS, how can
they do so without involving the network (or at least, having a fairly extensive a priori
view of what QoS is available, end-to-end). Likewise, how does can the QI negotiate with
the QC without the result impacting the session description, particularly the non-QoS
components of the session description? A simple example of this is bandwidth: if, for
example, the end hosts agree on G.711 for voice, then there is a minimum bandwidth
requirement that must be met.

This may be slightly off of what you had in mind in terms of bundling, but your suggestion
raised the issue of the co-dependency between QoS and media type selection in SDPng.

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: May 6, 2002 20:03
> To: Kenward, Gary [WDLN2:AN10:EXCH]; fu@ee.tu-berlin.de;
> brunner@ccrle.nec.de
> Cc: Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) included
> indraft-ietf-nsis-req-01. txt
>
>
> Hi Gary,
>
> > Can we guarantee that the semantics of the signalling do not change
> > depending on whether it is sender initiated or receiver initiated?
> > Probably not.
>
> As we are now discussing requirements, perhaps we could discuss if
> the requirements are different based upon sender vs. receiver
> initiated
> signaling. 
>
> As a strawman, here are some ideas (not all good ideas ...)
>
> For example, for sender initiated, can we support implicit signaling
> (bundling the QoS requests with other signaling - registration, etc.)?
>
> For reciever initiated, do we need protoection against spamming -
> how do we protect against unwanted changes?
>
> There are some more things, are these relevant?
>
> John
>

------_=_NextPart_001_01C1F5FF.81CFFB22-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 7 16:18:40 2002 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 QAA23275 for ; Tue, 7 May 2002 16:18:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17575 for nsis-archive@odin.ietf.org; Tue, 7 May 2002 16:18:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17061; Tue, 7 May 2002 16:10:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17030 for ; Tue, 7 May 2002 16:10:40 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23019 for ; Tue, 7 May 2002 16:10:31 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g47K9pv24770; Tue, 7 May 2002 16:09:51 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 16:09:55 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4AA0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Georgios Karagiannis (ELN)'" , "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Tue, 7 May 2002 16:10:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F603.2ECFBAA8" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1F603.2ECFBAA8 Content-Type: text/plain; charset="iso-8859-1" Georgios: Actually, I was in agreement with you until I received this email. It would seem to me, that the "sender" ("receiver") is a higher order entity in the end-to-end scenario in that the "sender" ("receiver") not only initiates QoS, but also initiates AAA, session establishment, and ultimately, the actual data transfer (reception). So, the "sender"("reciever) would initiate the QI: either a QI at the end host, or a QI acting as a proxy within the network. In other words: the "sender"("receiver") represents the end host in this context. (Note that I have always equated QI with the end-host, for non-proxy scenarios, which would mean the "sender" ("receiver") is a QI - as well as having other roles, in those scenarios). In a proxy scenario, I do not understand why the QI would "initiate" the "sender" ("receiver") to "initiate" QoS. On the contrary, I see the "sender" instructing the proxy QI to initiate QoS setup, where the instruction may be explicit or implicit (i.e. NSIS does care what the form of this instruction is). Does this align with what you intended Georgios, or are we in disagreement/ Gary > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: May 7, 2002 05:53 > To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > Hi Ilya > > Maybe the terminology (in the NSIS requirements draft) > is not clear, but what I mean with: > > * a sender initiated approach > is that the sender of the data path starts the reservation > towards the receiver, and > > * in the receiver initiated approach the receiver of the data path > starts the reservation towards the sender. > > Additionally, note that the triggering of this initiation > can also be done by entities that are not sender or receiver of the > data path. > > In other words: > * in a sender initiated approach, a QI, a QC or a QR > that is not the sender of the data path will have to > trigger the sender of the data path to start > a sender initiated reservation. > > * in a receiver initiated approach, a QI, a QC or a QR > that is not the receiver of the data path will have > to trigger the receiver of the data path to start a > receiver initiated reservation. > > > I hope that this makes it more clear!! > > Best regards, > Georgios > > -----Original Message----- > From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > Sent: maandag 6 mei 2002 20:47 > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; > Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > I support the idea to leave this requirement out. > If you add 3d party requesting case (SIP proxy, application proxy, > softswitch, you name it) than you see that QI does not > necessarily represent > neither receiver nor sender and the whole question becomes a > moot point. As > Marcus has mentioned as soon as we agreed that signaling path > might differ > from the data path we'd better not associate QI with any > particular end of > the data flow. > It seems that it can be useful if NSIS protocol semantics > allows a QI to > request the bi-directional reservation but it can be rejected > by the QC if > employed QoS mechanism does not support it. > > Ilya > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, May 02, 2002 1:49 PM > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. > txt > > Hi Marcus, > > > The question is what are we doing with the requirement? > > Both you and John favour > > SHOULD support sender initiated > > MAY support reciever initiated > > > > I would completly remove any requirements regarding initation. > > If we include requirements for initiation, I favor the above. > However, > I am not bothered if this is left out. > > 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 > ------_=_NextPart_001_01C1F603.2ECFBAA8 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt

Georgios:

  Actually, I was in agreement with you until I received this email.
It would seem to me, that the "sender" ("receiver") is a higher order
entity in the end-to-end scenario in that the "sender" ("receiver") not
only initiates QoS, but also initiates AAA, session establishment, and
ultimately, the actual data transfer (reception). So, the "sender"("reciever)
would initiate the QI: either a QI at the end host, or a QI acting as a proxy
within the network. In other words: the "sender"("receiver") represents the
end host in this context.

(Note that I have always equated QI with the end-host, for non-proxy scenarios,
which would mean the "sender" ("receiver") is a QI - as well as having other roles,
in those scenarios).

In a proxy scenario, I do not understand why the QI would "initiate" the "sender"
("receiver") to "initiate" QoS. On the contrary, I see the "sender" instructing
the proxy QI to initiate QoS setup, where the instruction may be explicit or implicit
(i.e. NSIS does care what the form of this instruction is).

Does this align with what you intended Georgios, or are we in disagreement/

Gary


> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: May 7, 2002 05:53
> To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) included
> indraft-ietf-nsis-req-01. txt
>
>
> Hi Ilya
>
> Maybe the terminology (in the NSIS requirements draft)
> is not clear, but what I mean with:
>
> * a sender initiated approach
>   is that the sender of the data path starts the reservation
>   towards the receiver, and
>
> * in the receiver initiated approach the receiver of the data path
>   starts the reservation towards the sender.
>
> Additionally, note that the triggering of this initiation
> can also be done by entities that are not sender or receiver of the
> data path.
>
> In other words:
>  * in a sender initiated approach, a QI, a QC or a QR
>    that is not the sender of the data path will have to
>    trigger the sender of the data path to start
>    a sender initiated reservation.
>
>  * in a receiver initiated approach, a QI, a QC or a QR
>    that is not the receiver of the data path will have
>    to trigger the receiver of the data path to start a
>    receiver initiated reservation.
>
>
> I hope that this makes it more clear!!
>
> Best regards,
> Georgios
>
> -----Original Message-----
> From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com]
> Sent: maandag 6 mei 2002 20:47
> To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de;
> Georgios.Karagiannis@eln.ericsson.se
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) included
> indraft-ietf-nsis-req-01. txt
>
>
> I support the idea to leave this requirement out.
> If you add 3d party requesting case (SIP proxy, application proxy,
> softswitch, you name it) than you see that QI does not
> necessarily represent
> neither receiver nor sender and the whole question becomes a
> moot point. As
> Marcus has mentioned as soon as we agreed that signaling path
> might differ
> from the data path we'd better not associate QI with any
> particular end of
> the data flow.
> It seems that it can be useful if NSIS protocol semantics
> allows a QI to
> request the bi-directional reservation but it can be rejected
> by the QC if
> employed QoS mechanism does not support it.
>
> Ilya
> 
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Thursday, May 02, 2002 1:49 PM
> To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) included
> indraft-ietf-nsis-req-01.
> txt
>
> Hi Marcus,
>
> > The question is what are we doing with the requirement?
> > Both you and John favour
> >   SHOULD support sender initiated
> >   MAY support reciever initiated
> >
> > I would completly remove any requirements regarding initation.
>
> If we include requirements for initiation, I favor the above.
>  However,
> I am not bothered if this is left out.
>
> 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
>

------_=_NextPart_001_01C1F603.2ECFBAA8-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 7 16:27:43 2002 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 QAA23594 for ; Tue, 7 May 2002 16:27:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18261 for nsis-archive@odin.ietf.org; Tue, 7 May 2002 16:27:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17680; Tue, 7 May 2002 16:18:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17595 for ; Tue, 7 May 2002 16:18:48 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23285 for ; Tue, 7 May 2002 16:18:39 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g47KHsv25186; Tue, 7 May 2002 16:17:54 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 16:17:58 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4AA1@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Georgios Karagiannis (ELN)'" , "'sven.van_den_bosch@alcatel.be'" , "Freytsis, Ilya" Cc: "Freytsis, Ilya" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de, nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Tue, 7 May 2002 16:18:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F604.4C7779C8" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1F604.4C7779C8 Content-Type: text/plain; charset="iso-8859-1" Georgios: To follow-up on my previous comment: - we agree that sender initiated and receiver initiated belong (I am not convinced that QoS setup should always be initiated by the sender) - I am confused by your comment about bandwidth broker (perhaps because I missed the discussion). Ignoring the complexity of end-to-end inter-system negotiation for the moment, how is a bb different from a QC? - I believe the details of sender/receiver interaction with QI/QC/QR can be left to the design phase discussion. Do you concur? Can we capture the requirement sufficiently without addressing the nature/order of the interaction? Gary > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: May 7, 2002 11:15 > To: 'sven.van_den_bosch@alcatel.be'; Freytsis, Ilya > Cc: Freytsis, Ilya; 'john.loughney@nokia.com'; brunner@ccrle.nec.de; > nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > Hi Sven > > The terms sender initiated and receiver initiated are terms > that are used and applied in IETF since many years, see e.g., > RFC 1633. > > Both are referring to the data path. > > I understand that if you will use bandwidth broker scenarios > these terms will not make > much sense, but the bandwidth brokering scenario is > not the only scenario that the NSIS WG is considering! > > I am afraid that this bandwidth brokering scenarios > complicate the NSIS protocol very much! > > I would suggest to use the terms sender initiated and receiver > initiated as defined in e.g., RFC1633. > Additionally I would keep the requirement about sender > initiated and receiver initiated. > > best regards, > Georgios > > > > > > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: dinsdag 7 mei 2002 16:58 > To: Freytsis, Ilya > Cc: 'Georgios Karagiannis (ELN)'; Freytsis, Ilya; > 'john.loughney@nokia.com'; brunner@ccrle.nec.de; nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > Ilya, > > I like the scenario that you propose. I think we can conclude > from it that > any entity on or off the data path can assume the role of a QI for the > purpose of nsis signaling. In that respect, it seems logical that only > sender-initiated signaling needs to be supported, where > sender-initiated > refers to the entity that initiates the nsis reservation, not the data > flow. You could eliminate the requirement, although I would be more in > favour to add this explanation and keep the requirement. It is still > possible that the QI triggers the QR and resources are only > reserved on the > way back > > Sven > > > > > > "Freytsis, Ilya" on 07/05/2002 16:05:20 > > > > To: "'Georgios Karagiannis (ELN)'" > , > "Freytsis, Ilya" , > "'john.loughney@nokia.com'" > , > brunner@ccrle.nec.de > > cc: nsis@ietf.org(bcc: Sven VAN DEN > BOSCH/BE/ALCATEL) > > > > Subject RE: [NSIS] comments Issue (2) included > : indraft-ietf-nsis-req-01. txt > > > > > > > Georgios, > > Thanks for the detailed explanation. > Unfortunately I think we have quite a different picture in > mind. Yours I > think originated in RSVP world but let's look at the case > when you have > centralized bandwidth broker (QC) managing pre-provisioned LSPs. The > scenario I have in mind is this: > 1. Endhosts (sender and receiver, let's say gaming consoles) > do not speak > NSIS and are not aware of any bandwidth provisioning > 2. An application level entity (gaming server) exists somewhere on the > network and acts as a QI for both of them by requesting > network resources > for the session from the bandwidth broker (QC) via NSIS signaling > 3. The bandwidth broker accepts session and replies via NSIS > to the server > (QI). > 4. The gaming server signal to the endhosts in the > application specific way > that the session is setup. > > I do not see place for the notion of > sender/receiver-initiated approach in > this case. What do you think? > > Ilya > > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Tuesday, May 07, 2002 5:53 AM > To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. > txt > > Hi Ilya > > Maybe the terminology (in the NSIS requirements draft) > is not clear, but what I mean with: > > * a sender initiated approach > is that the sender of the data path starts the reservation > towards the receiver, and > > * in the receiver initiated approach the receiver of the data path > starts the reservation towards the sender. > > Additionally, note that the triggering of this initiation > can also be done by entities that are not sender or receiver of the > data path. > > In other words: > * in a sender initiated approach, a QI, a QC or a QR > that is not the sender of the data path will have to > trigger the sender of the data path to start > a sender initiated reservation. > > * in a receiver initiated approach, a QI, a QC or a QR > that is not the receiver of the data path will have > to trigger the receiver of the data path to start a > receiver initiated reservation. > > > I hope that this makes it more clear!! > > Best regards, > Georgios > > -----Original Message----- > From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > Sent: maandag 6 mei 2002 20:47 > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; > Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > I support the idea to leave this requirement out. > If you add 3d party requesting case (SIP proxy, application proxy, > softswitch, you name it) than you see that QI does not necessarily > represent > neither receiver nor sender and the whole question becomes a > moot point. As > Marcus has mentioned as soon as we agreed that signaling path > might differ > from the data path we'd better not associate QI with any > particular end of > the data flow. > It seems that it can be useful if NSIS protocol semantics > allows a QI to > request the bi-directional reservation but it can be rejected > by the QC if > employed QoS mechanism does not support it. > > Ilya > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, May 02, 2002 1:49 PM > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. > txt > > Hi Marcus, > > > The question is what are we doing with the requirement? > > Both you and John favour > > SHOULD support sender initiated > > MAY support reciever initiated > > > > I would completly remove any requirements regarding initation. > > If we include requirements for initiation, I favor the above. > However, > I am not bothered if this is left out. > > 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 > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1F604.4C7779C8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. = txt

Georgios:

  To follow-up on my previous comment:

     - we agree that sender = initiated and receiver initiated belong
       (I am not = convinced that QoS setup should always be initiated by the = sender)

     - I am confused by your = comment about bandwidth broker (perhaps because I missed
       the = discussion). Ignoring the complexity of end-to-end inter-system = negotiation
       for the moment, = how is a bb different from a QC?

     - I believe the details of = sender/receiver interaction with QI/QC/QR can be left
       to the design = phase discussion. Do you concur? Can we capture the requirement
       sufficiently = without addressing the nature/order of the interaction?

Gary

> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Kar= agiannis@eln.ericsson.se]
> Sent: May 7, 2002 11:15
> To: 'sven.van_den_bosch@alcatel.be'; Freytsis, = Ilya
> Cc: Freytsis, Ilya; 'john.loughney@nokia.com'; = brunner@ccrle.nec.de;
> nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) = included
> indraft-ietf-nsis-req-01. txt
>
>
> Hi Sven
>
> The terms sender initiated and receiver = initiated are terms
> that are used and applied in IETF since many = years, see e.g.,
> RFC 1633.
>
> Both are referring to the data path.
>
> I understand that if you will use bandwidth = broker scenarios
> these terms will not make 
> much sense, but the bandwidth brokering = scenario is
> not the only scenario that the NSIS WG is = considering!
>
> I am afraid that this bandwidth brokering = scenarios
> complicate the NSIS protocol very much!
>
> I would suggest to use the terms sender = initiated and receiver
> initiated as defined in e.g., RFC1633.
> Additionally I would keep the requirement about = sender
> initiated and receiver initiated.
>
> best regards,
> Georgios
>
>
>
>
>
> -----Original Message-----
> From: sven.van_den_bosch@alcatel.be
> [mailto:sven.van_den_bosch@= alcatel.be]
> Sent: dinsdag 7 mei 2002 16:58
> To: Freytsis, Ilya
> Cc: 'Georgios Karagiannis (ELN)'; Freytsis, = Ilya;
> 'john.loughney@nokia.com'; = brunner@ccrle.nec.de; nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) = included
> indraft-ietf-nsis-req-01. txt
>
>
> Ilya,
>
> I like the scenario that you propose. I think = we can conclude
> from it that
> any entity on or off the data path can assume = the role of a QI for the
> purpose of nsis signaling. In that respect, it = seems logical that only
> sender-initiated signaling needs to be = supported, where
> sender-initiated
> refers to the entity that initiates the nsis = reservation, not the data
> flow. You could eliminate the requirement, = although I would be more in
> favour to add this explanation and keep the = requirement. It is still
> possible that the QI triggers the QR and = resources are only
> reserved on the
> way back
>
> Sven
>
>
>
>
>
> "Freytsis, Ilya" = <ifreytsis@Cetacean.com> on 07/05/2002 16:05:20
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>   = To:          = "'Georgios Karagiannis = (ELN)'"          =       
>          = ;      = <Georgios.Karagiannis@eln.ericsson.se>,    &nb= sp;  
>          = ;      "Freytsis, Ilya" = <ifreytsis@Cetacean.com>,    
>          = ;      = "'john.loughney@nokia.com'"      = ;            = ; 
>          = ;      = <john.loughney@nokia.com>,      &nbs= p;           &nbs= p; 
>          = ;      = brunner@ccrle.nec.de        &nbs= p;           &nbs= p;     
>          = ;            = ;            = ;            = ;            = ;    
>   = cc:          = nsis@ietf.org(bcc: Sven VAN = DEN           &nb= sp;   
>          = ;      = BOSCH/BE/ALCATEL)         &= nbsp;           &= nbsp;       
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>   = Subject      RE: [NSIS] comments Issue (2) = included        
>   = :            = indraft-ietf-nsis-req-01.        = ;   txt       
>          = ;            = ;            = ;            = ;            = ;    
>
>
>
>
>
> Georgios,
>
> Thanks for the detailed explanation.
> Unfortunately I think we have quite a different = picture in
> mind. Yours I
> think originated in RSVP world but let's look = at the case
> when you have
> centralized bandwidth broker (QC) managing = pre-provisioned LSPs. The
> scenario I have in mind is this:
> 1. Endhosts (sender and receiver, let's say = gaming consoles)
> do not speak
> NSIS and are not aware of any bandwidth = provisioning
> 2. An application level entity (gaming server) = exists somewhere on the
> network and acts as a QI for both of them by = requesting
> network resources
> for the session from the bandwidth broker (QC) = via NSIS signaling
> 3. The bandwidth broker accepts session and = replies via NSIS
> to the server
> (QI).
> 4. The gaming server signal to the endhosts in = the
> application specific way
> that the session is setup.
>
> I do not see place for the notion of
> sender/receiver-initiated approach in
> this case. What do you think?
>
> Ilya
>
> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Kar= agiannis@eln.ericsson.se]
> Sent: Tuesday, May 07, 2002 5:53 AM
> To: 'Freytsis, Ilya'; = 'john.loughney@nokia.com'; brunner@ccrle.nec.de
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) included =
> indraft-ietf-nsis-req-01.
> txt
>
> Hi Ilya
>
> Maybe the terminology (in the NSIS requirements = draft)
> is not clear, but what I mean with:
>
> * a sender initiated approach
>   is that the sender of the data path = starts the reservation
>   towards the receiver, and
>
> * in the receiver initiated approach the = receiver of the data path
>   starts the reservation towards the = sender.
>
> Additionally, note that the triggering of this = initiation
> can also be done by entities that are not = sender or receiver of the
> data path.
>
> In other words:
>  * in a sender initiated approach, a QI, a = QC or a QR
>    that is not the sender of the = data path will have to
>    trigger the sender of the = data path to start
>    a sender initiated = reservation.
>
>  * in a receiver initiated approach, a QI, = a QC or a QR
>    that is not the receiver of = the data path will have
>    to trigger the receiver of = the data path to start a
>    receiver initiated = reservation.
>
>
> I hope that this makes it more clear!!
>
> Best regards,
> Georgios
>
> -----Original Message-----
> From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com= ]
> Sent: maandag 6 mei 2002 20:47
> To: 'john.loughney@nokia.com'; = brunner@ccrle.nec.de;
> Georgios.Karagiannis@eln.ericsson.se
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) = included
> indraft-ietf-nsis-req-01. txt
>
>
> I support the idea to leave this requirement = out.
> If you add 3d party requesting case (SIP proxy, = application proxy,
> softswitch, you name it) than you see that QI = does not necessarily
> represent
> neither receiver nor sender and the whole = question becomes a
> moot point. As
> Marcus has mentioned as soon as we agreed that = signaling path
> might differ
> from the data path we'd better not associate QI = with any
> particular end of
> the data flow.
> It seems that it can be useful if NSIS protocol = semantics
> allows a QI to
> request the bi-directional reservation but it = can be rejected
> by the QC if
> employed QoS mechanism does not support = it.
>
> Ilya
>
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Thursday, May 02, 2002 1:49 PM
> To: brunner@ccrle.nec.de; = Georgios.Karagiannis@eln.ericsson.se
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) included =
> indraft-ietf-nsis-req-01.
> txt
>
> Hi Marcus,
>
> > The question is what are we doing with the = requirement?
> > Both you and John favour
> >   SHOULD support sender = initiated
> >   MAY support reciever = initiated
> >
> > I would completly remove any requirements = regarding initation.
>
> If we include requirements for initiation, I = favor the above.
>  However,
> I am not bothered if this is left out.
>
> 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=
>
>
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis=
>

------_=_NextPart_001_01C1F604.4C7779C8-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed May 8 02:46:21 2002 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 CAA27618 for ; Wed, 8 May 2002 02:46:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA07584 for nsis-archive@odin.ietf.org; Wed, 8 May 2002 02:46:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07390; Wed, 8 May 2002 02:37:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07359 for ; Wed, 8 May 2002 02:37:35 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27508 for ; Wed, 8 May 2002 02:37:28 -0400 (EDT) Received: from g8pbv.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 8 May 2002 08:35:56 +0200 Received: by G8PBV.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 08:36:57 +0200 Message-Id: From: "Geib, Ruediger" To: gkenward@nortelnetworks.com Cc: nsis@ietf.org Date: Wed, 8 May 2002 08:34:20 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA07360 Subject: [NSIS] To BB or not to BB Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gary, > I am confused by your comment about bandwidth broker > (perhaps because I missed the discussion). Ignoring > the complexity of end-to-end inter-system negotiation > for the moment, how is a bb different from a QC? You didn't miss anything. NSIS still is in the requirements phase. Georgios comment isn't part of the ongoing discussion. I'd suggest to return to requirements before we start to talk about solutions. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed May 8 03:02:12 2002 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 DAA27803 for ; Wed, 8 May 2002 03:02:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA08574 for nsis-archive@odin.ietf.org; Wed, 8 May 2002 03:02:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07756; Wed, 8 May 2002 02:52:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07725 for ; Wed, 8 May 2002 02:52:54 -0400 (EDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27678 for ; Wed, 8 May 2002 02:52:42 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.36) id 175LJD-00045z-00; Wed, 08 May 2002 08:52:19 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id g486qFC12107; Wed, 8 May 2002 08:52:15 +0200 Message-ID: <3CD8CB1F.510688BB@ee.tu-berlin.de> Date: Wed, 08 May 2002 08:52:15 +0200 From: Xiaoming Fu Reply-To: fu@ee.tu-berlin.de Organization: Telecommunication Networks Group, Technical University Berlin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-686 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: Gary Kenward CC: "'Georgios Karagiannis (ELN)'" , "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de, nsis@ietf.org Subject: Re: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt References: <9FBD322B7824D511B36900508BF93C9C01AA4AA0@zcard031.ca.nortel.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary, I agree with you. While sender-initiated has advantages for many scenarios, limiting it as MUST for the requirement may implicate incompatiability with some other scenarios or complexity in e2e negotiation/interaction. Regards, Xiaoming > Gary Kenward wrote: > > Georgios: > > Actually, I was in agreement with you until I received this email. > It would seem to me, that the "sender" ("receiver") is a higher order > entity in the end-to-end scenario in that the "sender" ("receiver") not > only initiates QoS, but also initiates AAA, session establishment, and > ultimately, the actual data transfer (reception). So, the > "sender"("reciever) > would initiate the QI: either a QI at the end host, or a QI acting as a > proxy > within the network. In other words: the "sender"("receiver") represents the > end host in this context. > > (Note that I have always equated QI with the end-host, for non-proxy > scenarios, > which would mean the "sender" ("receiver") is a QI - as well as having other > roles, > in those scenarios). > > In a proxy scenario, I do not understand why the QI would "initiate" the > "sender" > ("receiver") to "initiate" QoS. On the contrary, I see the "sender" > instructing > the proxy QI to initiate QoS setup, where the instruction may be explicit or > implicit > (i.e. NSIS does care what the form of this instruction is). > > Does this align with what you intended Georgios, or are we in disagreement/ > > Gary > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: May 7, 2002 05:53 > > To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] comments Issue (2) included > > indraft-ietf-nsis-req-01. txt > > > > > > Hi Ilya > > > > Maybe the terminology (in the NSIS requirements draft) > > is not clear, but what I mean with: > > > > * a sender initiated approach > > is that the sender of the data path starts the reservation > > towards the receiver, and > > > > * in the receiver initiated approach the receiver of the data path > > starts the reservation towards the sender. > > > > Additionally, note that the triggering of this initiation > > can also be done by entities that are not sender or receiver of the > > data path. > > > > In other words: > > * in a sender initiated approach, a QI, a QC or a QR > > that is not the sender of the data path will have to > > trigger the sender of the data path to start > > a sender initiated reservation. > > > > * in a receiver initiated approach, a QI, a QC or a QR > > that is not the receiver of the data path will have > > to trigger the receiver of the data path to start a > > receiver initiated reservation. > > > > > > I hope that this makes it more clear!! > > > > Best regards, > > Georgios > > > > -----Original Message----- > > From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > > Sent: maandag 6 mei 2002 20:47 > > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; > > Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] comments Issue (2) included > > indraft-ietf-nsis-req-01. txt > > > > > > I support the idea to leave this requirement out. > > If you add 3d party requesting case (SIP proxy, application proxy, > > softswitch, you name it) than you see that QI does not > > necessarily represent > > neither receiver nor sender and the whole question becomes a > > moot point. As > > Marcus has mentioned as soon as we agreed that signaling path > > might differ > > from the data path we'd better not associate QI with any > > particular end of > > the data flow. > > It seems that it can be useful if NSIS protocol semantics > > allows a QI to > > request the bi-directional reservation but it can be rejected > > by the QC if > > employed QoS mechanism does not support it. > > > > Ilya > > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Thursday, May 02, 2002 1:49 PM > > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] comments Issue (2) included > > indraft-ietf-nsis-req-01. > > txt > > > > Hi Marcus, > > > > > The question is what are we doing with the requirement? > > > Both you and John favour > > > SHOULD support sender initiated > > > MAY support reciever initiated > > > > > > I would completly remove any requirements regarding initation. > > > > If we include requirements for initiation, I favor the above. > > However, > > I am not bothered if this is left out. > > > > 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 > > -- Xiaoming Fu fu@ee.tu-berlin.de http://www-tkn.ee.tu-berlin.de/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed May 8 05:13:35 2002 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 FAA29238 for ; Wed, 8 May 2002 05:13:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13937 for nsis-archive@odin.ietf.org; Wed, 8 May 2002 05:13:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13519; Wed, 8 May 2002 05:03:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13490 for ; Wed, 8 May 2002 05:03:32 -0400 (EDT) Received: from bt0g2p.god.bel.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29141 for ; Wed, 8 May 2002 05:03:23 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g4890rv12055; Wed, 8 May 2002 11:00:53 +0200 Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt To: "Georgios Karagiannis (ELN)" Cc: "Freytsis, Ilya" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 8 May 2002 11:02:38 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/08/2002 11:02:43 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, I have not found a clear defintion of both although RFC 1633 offers a rationale for the receiver-initiated reservation. I found no indication in the text that sender and receiver do not apply to the entities that initate the signaling. Of course, with RSVP this would be data path entities, my point was that in NSIS, they is not necessarily the case. They might be though when data flow sender/receiver acts as QI/QR but that is not necessarily the case. I think we can use the terminology applying it to QI/QC. Sven. "Georgios Karagiannis (ELN)" on 07/05/2002 17:15:24 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, "Freytsis, Ilya" cc: "Freytsis, Ilya" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de, nsis@ietf.org Subject RE: [NSIS] comments Issue (2) included : indraft-ietf-nsis-req-01. txt Hi Sven The terms sender initiated and receiver initiated are terms that are used and applied in IETF since many years, see e.g., RFC 1633. Both are referring to the data path. I understand that if you will use bandwidth broker scenarios these terms will not make much sense, but the bandwidth brokering scenario is not the only scenario that the NSIS WG is considering! I am afraid that this bandwidth brokering scenarios complicate the NSIS protocol very much! I would suggest to use the terms sender initiated and receiver initiated as defined in e.g., RFC1633. Additionally I would keep the requirement about sender initiated and receiver initiated. best regards, Georgios -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: dinsdag 7 mei 2002 16:58 To: Freytsis, Ilya Cc: 'Georgios Karagiannis (ELN)'; Freytsis, Ilya; 'john.loughney@nokia.com'; brunner@ccrle.nec.de; nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Ilya, I like the scenario that you propose. I think we can conclude from it that any entity on or off the data path can assume the role of a QI for the purpose of nsis signaling. In that respect, it seems logical that only sender-initiated signaling needs to be supported, where sender-initiated refers to the entity that initiates the nsis reservation, not the data flow. You could eliminate the requirement, although I would be more in favour to add this explanation and keep the requirement. It is still possible that the QI triggers the QR and resources are only reserved on the way back Sven "Freytsis, Ilya" on 07/05/2002 16:05:20 To: "'Georgios Karagiannis (ELN)'" , "Freytsis, Ilya" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de cc: nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] comments Issue (2) included : indraft-ietf-nsis-req-01. txt Georgios, Thanks for the detailed explanation. Unfortunately I think we have quite a different picture in mind. Yours I think originated in RSVP world but let's look at the case when you have centralized bandwidth broker (QC) managing pre-provisioned LSPs. The scenario I have in mind is this: 1. Endhosts (sender and receiver, let's say gaming consoles) do not speak NSIS and are not aware of any bandwidth provisioning 2. An application level entity (gaming server) exists somewhere on the network and acts as a QI for both of them by requesting network resources for the session from the bandwidth broker (QC) via NSIS signaling 3. The bandwidth broker accepts session and replies via NSIS to the server (QI). 4. The gaming server signal to the endhosts in the application specific way that the session is setup. I do not see place for the notion of sender/receiver-initiated approach in this case. What do you think? Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Tuesday, May 07, 2002 5:53 AM To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Ilya Maybe the terminology (in the NSIS requirements draft) is not clear, but what I mean with: * a sender initiated approach is that the sender of the data path starts the reservation towards the receiver, and * in the receiver initiated approach the receiver of the data path starts the reservation towards the sender. Additionally, note that the triggering of this initiation can also be done by entities that are not sender or receiver of the data path. In other words: * in a sender initiated approach, a QI, a QC or a QR that is not the sender of the data path will have to trigger the sender of the data path to start a sender initiated reservation. * in a receiver initiated approach, a QI, a QC or a QR that is not the receiver of the data path will have to trigger the receiver of the data path to start a receiver initiated reservation. I hope that this makes it more clear!! Best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: maandag 6 mei 2002 20:47 To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt I support the idea to leave this requirement out. If you add 3d party requesting case (SIP proxy, application proxy, softswitch, you name it) than you see that QI does not necessarily represent neither receiver nor sender and the whole question becomes a moot point. As Marcus has mentioned as soon as we agreed that signaling path might differ from the data path we'd better not associate QI with any particular end of the data flow. It seems that it can be useful if NSIS protocol semantics allows a QI to request the bi-directional reservation but it can be rejected by the QC if employed QoS mechanism does not support it. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, May 02, 2002 1:49 PM To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Hi Marcus, > The question is what are we doing with the requirement? > Both you and John favour > SHOULD support sender initiated > MAY support reciever initiated > > I would completly remove any requirements regarding initation. If we include requirements for initiation, I favor the above. However, I am not bothered if this is left out. 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed May 8 11:40:27 2002 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 LAA13430 for ; Wed, 8 May 2002 11:40:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07686 for nsis-archive@odin.ietf.org; Wed, 8 May 2002 11:40:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07021; Wed, 8 May 2002 11:34:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06991 for ; Wed, 8 May 2002 11:34:54 -0400 (EDT) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12957 for ; Wed, 8 May 2002 11:34:47 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 175TSv-00071q-00; Wed, 08 May 2002 17:34:53 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 175TSu-0007dJ-00; Wed, 08 May 2002 17:34:52 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g48FYp126962; Wed, 8 May 2002 17:34:51 +0200 Message-Id: <200205081534.g48FYp126962@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: ifreytsis@Cetacean.com, braden@ISI.EDU, nsis@ietf.org Subject: Re: [NSIS] bi-directional signaling In-Reply-To: Message from john.loughney@nokia.com of "Tue, 07 May 2002 03:02:49 +0300." <0C1353ABB1DEB74DB067ADFF749C4EEFD8ECD2@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD8ECD2@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 May 2002 17:34:51 +0200 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, > Bi-directional signaling in NSIS SHOULD only be about the > signaling, not about the nature of the reservation. It is > my opinion that, within NSIS, the path which the data > takes maybe an orthoginal issue. IMO it is not completely orthogonal (although data and signaling path may be different) and depends largely on the environment. For instance, in a DiffServ scenario, the reservation of path resources is usually set up in a two-way sequence from the sender down to the receiver and back, because traffic conditioning elements (token buckets/shapers etc.) have to be adapted upstream while processing the response. Otherwise marked packets may affect adversely other reservations or may be dropped downstream. This is an example were data path mechanisms imply also an NSIS signaling sequence order. However, there are possibilities to have also receiver-initiated reservations, but usually at some higher cost of a 4-way message exchange (also due to asymmetric paths), e.g. receiver directly asks the sender to set up a reservation for him. Furthermore, receiver initiation can and should be easily supported for multicast flows. > For the requirements draft, the issue if bi-directional signaling > should only apply to if an endpoint signals both the inbound/outbound, > uplink/downlink, sending/receiving (pick your favorite terminology) > QoS needs. You mean to signal a bi-directional reservation in a single request? > I wouldn't mind that a NSIS protocol support this, so a MAY or > SHOULD would be nice to have in the requirements. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 02:00:15 2002 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 CAA29642 for ; Fri, 10 May 2002 02:00:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA25464 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 02:00:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25075; Fri, 10 May 2002 01:51:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25044 for ; Fri, 10 May 2002 01:51:34 -0400 (EDT) Received: from localhost.com ([61.174.204.159]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29163 for ; Fri, 10 May 2002 01:51:25 -0400 (EDT) From: rose@china.com Message-Id: <200205100551.BAA29163@ietf.org> Reply-To: rose@china.com To: nsis@ietf.org Date: Fri, 10 May 2002 13:51:33 +0800 X-Mailer: QuickSender 1.05 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [NSIS] ADV: Harvest lots of Target Email addresses quickly ! Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: quoted-printable =3CHTML=3E=3CHEAD=3E =3CBODY bgColor=3D#ffccff=3E =3CTABLE border=3D0 cellPadding=3D0 cellSpacing=3D0 width=3D475=3E =3CTBODY=3E =3CTR=3E =3CTD align=3Dmiddle vAlign=3Dtop=3E=3C=2FTD=3E=3C=2FTR=3E=3C=2FTBODY=3E=3C=2FTABLE=3E=3CBR=3E =3CTABLE=3E =3CTBODY=3E =3CTR=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E =3CTD bgColor=3D#b8ecff borderColor=3D#0000ff width=3D=2290%=22=3E=3CFONT color=3D#ff0000 face=3D=22Arial Black=22 size=3D6=3E =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B Want To Harvest A Lot Of =3CFONT color=3D#0000ff=3ETarget =3C=2FFONT=3EEmail =3B =3B Addresses In A Very Short Time=3F=3C=2FFONT=3E =3CP=3E=3CB=3E=3CFONT face=3DArial size=3D4=3E=3C=2FFONT=3E=3CFONT color=3D#ff00ff face=3DArial size=3D4=3E=3CFONT color=3D#0000ff=3ETarget Email Extractor =3C=2FFONT=3Eis =3B a =3B powerful =3B Email =3B Software that =3B harvests Target Email Addresses from search engines=2C any specified starting URLs =2C including cgi =2C asp pages etc=2E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CFONT color=3D#000000 face=3D=CB=CE=CC=E5 size=3D2=3E =3B It Quickly and automatically search and spider from search engine=2C any specified starting URLs to find and extract e-mail addresses=3CBR=3E=3C=2FP=3E =3CLI=3EPowerful targeting ability=2E Only extract the specific email addresses that directly related to your business=2E=3CBR=3E =3CLI=3EIntegrated with 18 top popular search engines=3A Yahoo=2C Google=2C MSN=2C AOL=3CBR=3E =3CLI=3EFast Search Ability=2E Nearly can find thousands of e-mail addresses in an hour=2C allowing up to 500 simultaneous search threads!=3CBR=3E =3CLI=3EHelpful for anyone for internet Email marketing purposes=2E=3CBR=3E =3CLI=3EFree version updates=2E=3CBR=3E=3CBR=3E=3C=2FFONT=3E=3CFONT color=3D#ff0000 face=3DArial size=3D4=3E=3CI=3E=3CSTRONG=3EClick The Following Link To Download This Program=3A=3C=2FSTRONG=3E=3C=2FI=3E=3C=2FFONT=3E=3C=2FLI=3E =3CP=3E=3CB=3E=3CFONT color=3D#ff0000 face=3DArial size=3D4=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fdownload=2Femail=2FESE=2Ezip=22=3EDownload Site 1=3C=2FA=3E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#ff0000 face=3DArial size=3D4=3E=3CA href=3D=22http=3A=2F=2Fbestsoft=2E3322=2Eorg=2Fonlinedown=2FESE=2Ezip=22=3EDownload Site 2=3C=2FA=3E =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B =3C=2FFONT=3E=3C=2FB=3E=A1=A1=3CFONT size=3D2=3E=3CFONT color=3D#0000a0 face=3DArial size=3D3=3E=3CSTRONG=3EIf =3B you can not download this program =2C =3B please copy the following link into your URL =2C and then click =22 Enter=22 on your Computer Keyboard=2E=3C=2FSTRONG=3E=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT size=3D2=3E=3CFONT color=3D#0000a0 face=3DArial size=3D3=3E=3CSTRONG=3EHere is the download links=3A=3C=2FSTRONG=3E=3C=2FFONT=3E=3C=2FP=3E =3CDIV=3E =3CP=3Ehttp=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fdownload=2Femail=2FESE=2Ezip=3C=2FP=3E =3CP=3Ehttp=3A=2F=2Fbestsoft=2E3322=2Eorg=2Fonlinedown=2FESE=2Ezip=3C=2FP=3E=3C=2FFONT=3E=3C=2FDIV=3E =3CP=3E=3C=2FP=3E=3C=2FTD=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E=3C=2FTR=3E =3CTR=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E =3CTD bgColor=3D#0f95de width=3D=2290%=22=3E=3CFONT color=3D#ffffff face=3D=22Verdana=2C Tahoma=2C Helvetica=2C SansSerif=22 size=3D1=3E=3CB=3EDisclaimer=3A=3C=2FB=3E=3CBR=3EWe are strongly against continuously sending unsolicited emails to those who do not wish to receive our special mailings=2E We have attained the services of an independent 3rd party to overlook list management and removal services=2E This is not unsolicited email=2E If you do not wish to receive further mailings=2C please click this link =3CA href=3D=22 http=3A=2F=2Fwww=2Eautoemailremoval=2Ecom=2Fcgi-bin=2Fremove=2Epl =22 target=3D=5Fblank=3E=3CFONT color=3D#fdd32a=3E=3CB=3Ehttp=3A=2F=2Fwww=2Eautoemailremoval=2Ecom=2Fcgi-bin=2Fremove=2Epl =3C=2FB=3E=3C=2FFONT=3E=3C=2FA=3E=2E Auto Email Removal Company=2E Ref# 01222263545=3C=2FFONT=3E=3CB=3E=3CFONT class=3Ddisclaimer color=3D#000080 face=3DArial=3E=3CBR=3EThis message is a commercial advertisement=2E It is compliant with all federal and state laws regarding email messages including the California Business and Professions Code=2E We have provided the subject line =22ADV=22 to provide you notification that this is a commercial advertisement for persons over 18yrs old=2E=3C=2FFONT=3E=3C=2FB=3E=3C=2FTD=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E=3C=2FTR=3E=3C=2FTBODY=3E=3C=2FTABLE=3E =3CSTYLE=3E=3C=2FSTYLE=3E =3CBR=3E=3CBR=3E=3CBR=3E=3CBR=3E=3CA href=3D=22=22=3E=3C=2FA=3E=3CBR=3E=3CBR=3E=3CBR=3E=3CBR=3E=3CBR=3E=3CA href=3D=22=22=3E=3C=2FA=3E=3CBR=3E=3C=2FBODY=3E=3C=2FHTML=3E _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 02:13:30 2002 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 CAA08300 for ; Fri, 10 May 2002 02:13:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA26241 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 02:13:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25962; Fri, 10 May 2002 02:06:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25932 for ; Fri, 10 May 2002 02:06:05 -0400 (EDT) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07222 for ; Fri, 10 May 2002 02:05:57 -0400 (EDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4A65kp29590; Thu, 9 May 2002 23:05:46 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 23:05:23 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01486D05@zsc3c032.us.nortel.com> From: "Praveen Muley" To: "'nsis@ietf.org'" Cc: "'john.loughney@nokia.com'" Date: Thu, 9 May 2002 23:06:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F7E8.B5F0FD6C" Subject: [NSIS] Test mail Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1F7E8.B5F0FD6C Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01C1F7E8.B5F0FD6C Content-Type: text/html; charset="iso-8859-1" Test mail

------_=_NextPart_001_01C1F7E8.B5F0FD6C-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 04:33:52 2002 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 EAA10733 for ; Fri, 10 May 2002 04:33:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA03218 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 04:34:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02487; Fri, 10 May 2002 04:25:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02456 for ; Fri, 10 May 2002 04:25:48 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10641 for ; Fri, 10 May 2002 04:25:33 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4A8ObY24785 for ; Fri, 10 May 2002 11:24:37 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 10 May 2002 11:25:40 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 10 May 2002 11:25:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] To BB or not to BB Date: Fri, 10 May 2002 11:25:40 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DDE@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] To BB or not to BB Thread-Index: AcH2Wu6IxMUJLbVwSFSO0NnPkANaPgBoGBDw To: , Cc: X-OriginalArrivalTime: 10 May 2002 08:25:40.0613 (UTC) FILETIME=[45186350:01C1F7FC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA02457 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Just a general comment about Bandwidth Brokers and NSIS. Bandwidth Brokers (as the are commonly defined) are actually out of scope of NSIS. This means we are not defining a bandwidth broker architecture. There was quite a bit of discussion (at a highlevel) about this before NSIS was allowed to be chartered, and it was said to me that bandwidth brokers are not really thought of as part of the Internet architecture. However, I do know that there are many folks providing bandwidth broker solutions. My view is that a bandwidth broker comes dangerously close to how resources are provisioned, therefore are out of scope of NSIS. From the charter: It is noted that resource reservation and traffic engineering can be considered as part of network administration, and therefore beyond the scope of the IETF to mandate a particular mechanism. Additionally, some folks may wish to check on the TEWG (http://www.ietf.org/html.charters/tewg-charter.html) for work on traffic engineering. Finally, I do think it is perfectly acceptable to have a framework and/or solution that is friendly to bandwidth brokers, but I do not think that a bandwidth broker centric architecture or solution is what we should do. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 04:41:25 2002 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 EAA10822 for ; Fri, 10 May 2002 04:41:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA03397 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 04:41:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03200; Fri, 10 May 2002 04:33:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03167 for ; Fri, 10 May 2002 04:33:23 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10723 for ; Fri, 10 May 2002 04:33:13 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4A8Xdk05974 for ; Fri, 10 May 2002 11:33:39 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 10 May 2002 11:33:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 10 May 2002 11:33:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] bi-directional signaling Date: Fri, 10 May 2002 11:33:17 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC650DD@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] bi-directional signaling Thread-Index: AcH2per0W5F1DMPwTFqQIN/+tvdgLwBVr5Jg To: Cc: X-OriginalArrivalTime: 10 May 2002 08:33:18.0234 (UTC) FILETIME=[55DBCFA0:01C1F7FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA03168 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Roland, > > Bi-directional signaling in NSIS SHOULD only be about the > > signaling, not about the nature of the reservation. It is > > my opinion that, within NSIS, the path which the data > > takes maybe an orthoginal issue. > > IMO it is not completely orthogonal (although data and signaling path > may be different) and depends largely on the environment. For instance, > in a DiffServ scenario, the reservation of path resources is usually set > up in a two-way sequence from the sender down to the receiver and back, > because traffic conditioning elements (token buckets/shapers etc.) have > to be adapted upstream while processing the response. Otherwise marked > packets may affect adversely other reservations or may be dropped > downstream. This is an example were data path mechanisms imply also an > NSIS signaling sequence order. I actually meant that in the discussion at hand it was orthoginal, as NSIS is not working on resource reservation. In summary, the nature of the reservation is a different issue (and one which we are not trying to solve in NSIS) than what & how the user requests it. > > For the requirements draft, the issue if bi-directional signaling > > should only apply to if an endpoint signals both the inbound/outbound, > > uplink/downlink, sending/receiving (pick your favorite terminology) > > QoS needs. > > You mean to signal a bi-directional reservation in a single request? We are not talking about bi-directional reservations in NSIS. Reservation mechanisms are out of scope, and something that we are not chartered to do. What I mean is that, for example, if we support sender-initiated requests, we may wish to support bi-directional requests. So, I ask for 512K bw upstream and 256k bw downstream, for exampe ... John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 06:05:39 2002 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 GAA11786 for ; Fri, 10 May 2002 06:05:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA07151 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 06:05:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06352; Fri, 10 May 2002 05:57:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06321 for ; Fri, 10 May 2002 05:57:41 -0400 (EDT) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11543 for ; Fri, 10 May 2002 05:57:31 -0400 (EDT) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id LAA22071 for ; Fri, 10 May 2002 11:57:10 +0200 (MEST) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id g4A9udD05673 for nsis@ietf.org; Fri, 10 May 2002 11:56:39 +0200 Message-Id: <200205100956.g4A9udD05673@KOM.tu-darmstadt.de> To: nsis@ietf.org Date: Fri, 10 May 2002 11:56:39 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Announcement of RSVP implementation (fwd) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit I thought that the announcement below might be of interest for people on this list. Martin ----- Forwarded message (env-from mkarsten) ----- From mkarsten Fri May 10 11:54:23 2002 Subject: Announcement of RSVP implementation To: rsvp@isi.edu Date: Fri, 10 May 2002 11:54:23 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL66 (25)] I would like to announce, to any interested party, the release version 3.0 of the KOM RSVP implementation. Below is a brief overview about news in this version. Please consult the web site at http://www.kom.e-technik.tu-darmstadt.de/rsvp/ for further information and download instructions. Any feedback is welcome. Best Regards, Martin Karsten MPLS ---- Limited support for MPLS signalling and forwarding has been added, according to [1]. The daemon can interact with two open-source MPLS data planes for Linux, available from: http://www.cl.cam.ac.uk/Research/SRG/netos/netx/index.html http://sourceforge.net/projects/mpls-linux The mechanisms supported are label distribution and explicit routing. Refresh Reduction ----------------- Limited support for RSVP Refresh Reduction has been added, according to [2]. The mechanisms supported are summary refresh and nack messages. Remote API ---------- As an experimental extension to RSVP, a daemon can communicate via a remote API mechanism with clients. See [3] for details. One-pass Signalling ------------------- As an experimental extension to RSVP, it is possible to setup sender-oriented one-pass and duplex reservations. See [3] for details. ns2 Version ----------- The protocol engine has been ported to ns2. See README.ns2 for details. Traffic Generator ----------------- An RSVP-capable traffic generator has been added. See README.tg_config for details. This release also includes a kernel time stamping module, which can be used from the traffic generator. See altq/README for details. Java API -------- The Client API is accessible through a rudimentary Java Native Interface. Other ----- There have been many bugfixes and internal improvements. References ---------- [1] D. Awduche et al. RSVP-TE: Extensions to RSVP for LSP Tunnels. IETF RFC 3209. December 2001 [2] L. Berger et al. RSVP Refresh Overhead Reduction Extensions. IETF RFC 2961. April 2001 [3] Martin Karsten. Experimental Extensions to RSVP - Remote Client and One-Pass Signalling. In Proceedings of the Ninth IEEE/IFIP International Workshop on Quality of Service (IWQoS'01), Karlsruhe, Germany, pages 269-274. Springer LNCS 2092, June 2001. ----- End of forwarded message (env-from mkarsten) ----- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 06:55:10 2002 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 GAA13513 for ; Fri, 10 May 2002 06:55:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA09305 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 06:55:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09164; Fri, 10 May 2002 06:47:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09131 for ; Fri, 10 May 2002 06:47:08 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13223; Fri, 10 May 2002 06:46:57 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4AAlRk05886; Fri, 10 May 2002 13:47:27 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 10 May 2002 13:47:05 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 10 May 2002 13:47:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 10 May 2002 13:47:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DE1@esebe004.NOE.Nokia.com> Thread-Topic: Interim Meeting Updated Agenda Thread-Index: AcH4EAW+89df9vG3TpSUlWF9IEqdMA== To: , Cc: , X-OriginalArrivalTime: 10 May 2002 10:47:05.0436 (UTC) FILETIME=[0671A1C0:01C1F810] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA09132 Subject: [NSIS] Interim Meeting Updated Agenda Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Here is the updated agenda. Please indicate to me if there are any other drafts to be discussed. NSIS Interim Meeting Nokia Research Center, Helsinki Finland Tuesday May 21st 10 AM to 4 PM Wednesday May 22nd 9 AM to 4 PM Thursday May 23rd 9 AM to 12 Noon Tuesday AM ========== 10 AM Introduction 11 AM Requirements of a QoS Solution for Mobile IP (http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-02.txt) 12 Lunch 1 PM Requirements for QoS Signaling Protocols (http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-01.txt) Wednesday AM ============ 9 AM RSVP Proxy (http://www.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-03.txt) 10 AM Applicability of "Specification of the Null Service Type - RFC 2997" 11 AM Applicability of "A Framework For IntServ Operation Over Diffserv Networks - RFC 2998" 12 AM Lunch 1 PM Two-plane and Three-tier QoS Framework for Mobile IPv6 Networks (just submitted) 2 PM Towards a Framework for QoS Signaling in the Internet (http://search.ietf.org/internet-drafts/draft-hancock-nsis-framework-00.txt) 3 AM discussion of Framework issues Thursday ======== 9 AM Framework summary 10 AM Analysis of the Resource Reservation Protocol (to be submitted) 11 AM Anaysis discussion ========================== previous announcement ===================0 Hi all, NSIS will be having an Interim Meeting from May 21st through May 23rd, in Helsinki, Finland. Meeting location is tentatively planned to be at the Nokia Research Center facilities, at Itämerenkatu 11-13 in Helsinki. On a map, the location is here: http://kartta.hel.fi/kktesti/osoitehakuen/bigmap.asp?SearchOp=katunumero2&Desc=ITÄMERENKATU%2011%20HELSINKI%20&XValue=51042&YValue=72829 A good overview of Helsinki can be found here: http://www.explore-helsinki.com/ There are 2 hotels with special room rates, mention that you are Nokia guests when booking/paying a hotel room, so you can get the Nokia price. Seaside hotel: single room 90EUR, double room 112EUR Address: Ruoholahdenranta 3 FIN-00180 Helsinki, Finland Tel. +358 (0)9 693 60 Sales: +358 (0)9 6936 1016 Fax: +358 (0)9 6932 123 e-mail: seaside@seasidehotel.fi Web: www.seasidehotel.fi Toll free: 9800 2010 Best Western Worldwide Radisson SAS Royal hotel: single and double room 110EUR Address: Runeberginkatu, 2 SF-00100 Helsinki, Finland Phone: +358 9 695 80 Email: sales.royal.helsinki@radissonsas.com http://www.radisson.com/helsinkifi Helsinki is served by most major airlines. Busses are available from the Helsinki-Vanta Airport to the center of Helsinki, where there the hotels are located. Taxi service is available as well. It takes about 20 to 30 minutes to get to the center from the airport. The rough agenda is as follows: Tuesday May 21st 10 AM to 4 PM Wednesday May 22nd 9 AM to 4 PM Thursday May 23rd 9 AM to 12 Noon Topics are (dependent on draft submissions): Signaling Requirements. Analysis of existing signaling protocols. Framework Signaling Architecture Please indicate your attendance Tues ___ Wed ___ Thurs ___ Thank you, John Loughney _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 08:33:09 2002 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 IAA18061 for ; Fri, 10 May 2002 08:33:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13379 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 08:33:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12505; Fri, 10 May 2002 08:18:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12476 for ; Fri, 10 May 2002 08:18:32 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17275 for ; Fri, 10 May 2002 08:18:22 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4ACIpk29464 for ; Fri, 10 May 2002 15:18:51 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 10 May 2002 15:18:29 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 10 May 2002 15:18:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 10 May 2002 15:18:29 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC650FC@esebe004.NOE.Nokia.com> Thread-Topic: NSIS Interim Participants Thread-Index: AcH4HMtQSn95Ifo1TseAp053t0UD2A== To: X-OriginalArrivalTime: 10 May 2002 12:18:29.0925 (UTC) FILETIME=[CB743D50:01C1F81C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA12477 Subject: [NSIS] NSIS Interim Participants Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Could all of those attending the interim meeting please send me where you are staying (which hotel)? I need to send a list of the participants to the hotels, in order to get the Nokia rate for you. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 09:26:55 2002 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 JAA21289 for ; Fri, 10 May 2002 09:26:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15700 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 09:27:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15265; Fri, 10 May 2002 09:15:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15232 for ; Fri, 10 May 2002 09:15:07 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20547 for ; Fri, 10 May 2002 09:14:54 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4ADF2s7019920 for ; Fri, 10 May 2002 15:15:02 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri May 10 15:15:01 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 15:14:32 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Gary Kenward'" , "Georgios Karagiannis (ELN)" , "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Fri, 10 May 2002 15:10:10 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Gary I think that we are in agreement about the definition of sender/ receiver initiated. If you do not agree with the functionality that has to do with the triggering is Okay with me. In the scenarios that I am interested in, the QI will always be either an end host (or a proxy that operates as an end host). best regards, Georgios -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: dinsdag 7 mei 2002 22:10 To: 'Georgios Karagiannis (ELN)'; 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Georgios: Actually, I was in agreement with you until I received this email. It would seem to me, that the "sender" ("receiver") is a higher order entity in the end-to-end scenario in that the "sender" ("receiver") not only initiates QoS, but also initiates AAA, session establishment, and ultimately, the actual data transfer (reception). So, the "sender"("reciever) would initiate the QI: either a QI at the end host, or a QI acting as a proxy within the network. In other words: the "sender"("receiver") represents the end host in this context. (Note that I have always equated QI with the end-host, for non-proxy scenarios, which would mean the "sender" ("receiver") is a QI - as well as having other roles, in those scenarios). In a proxy scenario, I do not understand why the QI would "initiate" the "sender" ("receiver") to "initiate" QoS. On the contrary, I see the "sender" instructing the proxy QI to initiate QoS setup, where the instruction may be explicit or implicit (i.e. NSIS does care what the form of this instruction is). Does this align with what you intended Georgios, or are we in disagreement/ Gary > -----Original Message----- > From: Georgios Karagiannis (ELN) > [ mailto:Georgios.Karagiannis@eln.ericsson.se ] > Sent: May 7, 2002 05:53 > To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > Hi Ilya > > Maybe the terminology (in the NSIS requirements draft) > is not clear, but what I mean with: > > * a sender initiated approach > is that the sender of the data path starts the reservation > towards the receiver, and > > * in the receiver initiated approach the receiver of the data path > starts the reservation towards the sender. > > Additionally, note that the triggering of this initiation > can also be done by entities that are not sender or receiver of the > data path. > > In other words: > * in a sender initiated approach, a QI, a QC or a QR > that is not the sender of the data path will have to > trigger the sender of the data path to start > a sender initiated reservation. > > * in a receiver initiated approach, a QI, a QC or a QR > that is not the receiver of the data path will have > to trigger the receiver of the data path to start a > receiver initiated reservation. > > > I hope that this makes it more clear!! > > Best regards, > Georgios > > -----Original Message----- > From: Freytsis, Ilya [ mailto:ifreytsis@Cetacean.com ] > Sent: maandag 6 mei 2002 20:47 > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; > Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > I support the idea to leave this requirement out. > If you add 3d party requesting case (SIP proxy, application proxy, > softswitch, you name it) than you see that QI does not > necessarily represent > neither receiver nor sender and the whole question becomes a > moot point. As > Marcus has mentioned as soon as we agreed that signaling path > might differ > from the data path we'd better not associate QI with any > particular end of > the data flow. > It seems that it can be useful if NSIS protocol semantics > allows a QI to > request the bi-directional reservation but it can be rejected > by the QC if > employed QoS mechanism does not support it. > > Ilya > > -----Original Message----- > From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com ] > Sent: Thursday, May 02, 2002 1:49 PM > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. > txt > > Hi Marcus, > > > The question is what are we doing with the requirement? > > Both you and John favour > > SHOULD support sender initiated > > MAY support reciever initiated > > > > I would completly remove any requirements regarding initation. > > If we include requirements for initiation, I favor the above. > However, > I am not bothered if this is left out. > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 09:50:07 2002 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 JAA22659 for ; Fri, 10 May 2002 09:50:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17071 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 09:50:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16498; Fri, 10 May 2002 09:35:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16465 for ; Fri, 10 May 2002 09:35:37 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21766 for ; Fri, 10 May 2002 09:35:28 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 09:30:16 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93138@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Fri, 10 May 2002 09:30:13 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org John, I think as long as we agreed that the NSIS signaling path is allowed to diverge from the data forwarding path everybody who cares about BBs would be satisfied. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Friday, May 10, 2002 4:26 AM To: Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Hi all, Just a general comment about Bandwidth Brokers and NSIS. Bandwidth Brokers (as the are commonly defined) are actually out of scope of NSIS. This means we are not defining a bandwidth broker architecture. There was quite a bit of discussion (at a highlevel) about this before NSIS was allowed to be chartered, and it was said to me that bandwidth brokers are not really thought of as part of the Internet architecture. However, I do know that there are many folks providing bandwidth broker solutions. My view is that a bandwidth broker comes dangerously close to how resources are provisioned, therefore are out of scope of NSIS. From the charter: It is noted that resource reservation and traffic engineering can be considered as part of network administration, and therefore beyond the scope of the IETF to mandate a particular mechanism. Additionally, some folks may wish to check on the TEWG (http://www.ietf.org/html.charters/tewg-charter.html) for work on traffic engineering. Finally, I do think it is perfectly acceptable to have a framework and/or solution that is friendly to bandwidth brokers, but I do not think that a bandwidth broker centric architecture or solution is what we should do. 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 daemon@optimus.ietf.org Fri May 10 09:56:09 2002 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 JAA23079 for ; Fri, 10 May 2002 09:56:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17534 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 09:56:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16644; Fri, 10 May 2002 09:41:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16613 for ; Fri, 10 May 2002 09:41:15 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22120 for ; Fri, 10 May 2002 09:41:04 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4ADfDs7026504 for ; Fri, 10 May 2002 15:41:13 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Fri May 10 15:37:49 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22816J8A>; Fri, 10 May 2002 15:38:22 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Fri, 10 May 2002 15:36:24 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Ilya This is one of the requirements that are mainly related to bandwidth brokering scenarios and significantly complicate the NSIS protocol. best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: vrijdag 10 mei 2002 15:30 To: 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB John, I think as long as we agreed that the NSIS signaling path is allowed to diverge from the data forwarding path everybody who cares about BBs would be satisfied. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Friday, May 10, 2002 4:26 AM To: Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Hi all, Just a general comment about Bandwidth Brokers and NSIS. Bandwidth Brokers (as the are commonly defined) are actually out of scope of NSIS. This means we are not defining a bandwidth broker architecture. There was quite a bit of discussion (at a highlevel) about this before NSIS was allowed to be chartered, and it was said to me that bandwidth brokers are not really thought of as part of the Internet architecture. However, I do know that there are many folks providing bandwidth broker solutions. My view is that a bandwidth broker comes dangerously close to how resources are provisioned, therefore are out of scope of NSIS. From the charter: It is noted that resource reservation and traffic engineering can be considered as part of network administration, and therefore beyond the scope of the IETF to mandate a particular mechanism. Additionally, some folks may wish to check on the TEWG (http://www.ietf.org/html.charters/tewg-charter.html) for work on traffic engineering. Finally, I do think it is perfectly acceptable to have a framework and/or solution that is friendly to bandwidth brokers, but I do not think that a bandwidth broker centric architecture or solution is what we should do. 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 10:07:17 2002 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 KAA23773 for ; Fri, 10 May 2002 10:07:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18279 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 10:07:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17309; Fri, 10 May 2002 09:53:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17222 for ; Fri, 10 May 2002 09:52:57 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22817 for ; Fri, 10 May 2002 09:52:47 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 09:47:37 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9313A@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Georgios Karagiannis (ELN)'" , "Freytsis, Ilya" , "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Fri, 10 May 2002 09:47:33 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Georgios, You are absolutely correct. The question is can we afford to ignore the fact that it is a part of the reality. Are you sure that NSIS solution will get widely accepted if it will not support this requirement? By the way in my opinion centralized QoS management (that is what we are talking about here) often needed not only for bandwidth brokering. There are other QoS parameters as delay, jitter etc. that have to be considered for some services. Ilya -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Friday, May 10, 2002 9:36 AM To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Hi Ilya This is one of the requirements that are mainly related to bandwidth brokering scenarios and significantly complicate the NSIS protocol. best regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: vrijdag 10 mei 2002 15:30 To: 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB John, I think as long as we agreed that the NSIS signaling path is allowed to diverge from the data forwarding path everybody who cares about BBs would be satisfied. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Friday, May 10, 2002 4:26 AM To: Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Hi all, Just a general comment about Bandwidth Brokers and NSIS. Bandwidth Brokers (as the are commonly defined) are actually out of scope of NSIS. This means we are not defining a bandwidth broker architecture. There was quite a bit of discussion (at a highlevel) about this before NSIS was allowed to be chartered, and it was said to me that bandwidth brokers are not really thought of as part of the Internet architecture. However, I do know that there are many folks providing bandwidth broker solutions. My view is that a bandwidth broker comes dangerously close to how resources are provisioned, therefore are out of scope of NSIS. From the charter: It is noted that resource reservation and traffic engineering can be considered as part of network administration, and therefore beyond the scope of the IETF to mandate a particular mechanism. Additionally, some folks may wish to check on the TEWG (http://www.ietf.org/html.charters/tewg-charter.html) for work on traffic engineering. Finally, I do think it is perfectly acceptable to have a framework and/or solution that is friendly to bandwidth brokers, but I do not think that a bandwidth broker centric architecture or solution is what we should do. 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 10:48:02 2002 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 KAA26397 for ; Fri, 10 May 2002 10:48:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20436 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 10:48:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19727; Fri, 10 May 2002 10:31:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19696 for ; Fri, 10 May 2002 10:31:35 -0400 (EDT) Received: from nazare.cin.ufpe.br (nazare.cin.ufpe.br [150.161.2.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25231 for ; Fri, 10 May 2002 10:31:25 -0400 (EDT) Received: from jurema.cin.ufpe.br (jurema [172.17.33.106]) by nazare.cin.ufpe.br (8.11.6/8.11.6) with ESMTP id g4AEUqZ67642 for ; Fri, 10 May 2002 11:30:52 -0300 (EST) (envelope-from www-data@nazare.cin.ufpe.br) Received: from www-data by jurema.cin.ufpe.br with local (Exim 3.12 #1 (Debian)) id 176BQ4-0001Qc-00 for ; Fri, 10 May 2002 11:30:52 -0300 To: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Message-ID: <1021041052.3cdbd99c66f48@webmail.cin.ufpe.br> Date: Fri, 10 May 2002 11:30:52 -0300 (EST) From: cak@cin.ufpe.br References: <6D8664171C38D511B5AD0002B325CE66A9313A@mail.cetaceannetworks.com> In-Reply-To: <6D8664171C38D511B5AD0002B325CE66A9313A@mail.cetaceannetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 200.199.75.44 Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit I personally cannot see the deployment of QoS-based services involving different admnistrative domains just based on "signaling messages". Signaling is just a part on the e2e qos big picture. In my opinion, mehanisms for dynamic interdomain service negotiation and provisioning are necessary (a kind of BB). So, I don´t support the opinion that BB-like mechanisms are out of the scope of Internet architecture (btw, is there an Internet Architecture? RFC 1958, section 2). It is probably not within the scope of NSIS, but I agree with Ilya that this group should not ignore the reality. Regards Carlos Kamienski > Georgios, > > You are absolutely correct. The question is can we afford to ignore the > fact > that it is a part of the reality. Are you sure that NSIS solution will > get > widely accepted if it will not support this requirement? > By the way in my opinion centralized QoS management (that is what we are > talking about here) often needed not only for bandwidth brokering. There > are > other QoS parameters as delay, jitter etc. that have to be considered > for > some services. > > Ilya > > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Friday, May 10, 2002 9:36 AM > To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; > Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] To BB or not to BB > > Hi Ilya > > This is one of the requirements that are mainly related > to bandwidth brokering scenarios and significantly > complicate the NSIS protocol. > > > best regards, > Georgios > > > -----Original Message----- > From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > Sent: vrijdag 10 mei 2002 15:30 > To: 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; > gkenward@nortelnetworks.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] To BB or not to BB > > > John, > > I think as long as we agreed that the NSIS signaling path is allowed to > diverge from the data forwarding path everybody who cares about BBs > would be > satisfied. > > Ilya > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, May 10, 2002 4:26 AM > To: Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] To BB or not to BB > > Hi all, > > Just a general comment about Bandwidth Brokers and NSIS. Bandwidth > Brokers (as the are commonly defined) are actually out of scope > of NSIS. This means we are not defining a bandwidth broker > architecture. There was quite a bit of discussion (at a highlevel) > about this before NSIS was allowed to be chartered, and it was > said to me that bandwidth brokers are not really thought of > as part of the Internet architecture. > > However, I do know that there are many folks providing bandwidth > broker solutions. My view is that a bandwidth broker comes > dangerously close to how resources are provisioned, therefore > are out of scope of NSIS. From the charter: > > It is noted that resource reservation and traffic engineering can be > considered as part of network administration, and therefore beyond the > scope of the IETF to mandate a particular mechanism. > > Additionally, some folks may wish to check on the TEWG > (http://www.ietf.org/html.charters/tewg-charter.html) for work on > traffic engineering. > > Finally, I do think it is perfectly acceptable to have a framework > and/or solution that is friendly to bandwidth brokers, but I do not > think that a bandwidth broker centric architecture or solution is > what we should do. > > 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 > > _______________________________________________ > 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 daemon@optimus.ietf.org Fri May 10 10:51:36 2002 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 KAA26582 for ; Fri, 10 May 2002 10:51:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20522 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 10:51:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20010; Fri, 10 May 2002 10:35:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19974 for ; Fri, 10 May 2002 10:35:43 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25519 for ; Fri, 10 May 2002 10:35:32 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4AEYp817516; Fri, 10 May 2002 16:34:51 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA26560; Fri, 10 May 2002 16:32:31 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B648A45303; Fri, 10 May 2002 16:32:30 +0200 (CEST) Date: Fri, 10 May 2002 16:44:49 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Message-ID: <17960065.1021049089@[192.168.102.79]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DDE@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DDE@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit I am sorry, but I could not refrain from asking what Internet Architecture BB are not part of? Otherwise I agree with John, the reqs and framework should allow for various QoS architectures (including BB kind of architectures), defined by the IETF. Marcus --On Friday, May 10, 2002 11:25 AM +0300 john.loughney@nokia.com wrote: > Hi all, > > Just a general comment about Bandwidth Brokers and NSIS. Bandwidth > Brokers (as the are commonly defined) are actually out of scope > of NSIS. This means we are not defining a bandwidth broker > architecture. There was quite a bit of discussion (at a highlevel) > about this before NSIS was allowed to be chartered, and it was > said to me that bandwidth brokers are not really thought of > as part of the Internet architecture. > > However, I do know that there are many folks providing bandwidth > broker solutions. My view is that a bandwidth broker comes > dangerously close to how resources are provisioned, therefore > are out of scope of NSIS. From the charter: > > It is noted that resource reservation and traffic engineering can be > considered as part of network administration, and therefore beyond the > scope of the IETF to mandate a particular mechanism. > > Additionally, some folks may wish to check on the TEWG > (http://www.ietf.org/html.charters/tewg-charter.html) for work on > traffic engineering. > > Finally, I do think it is perfectly acceptable to have a framework > and/or solution that is friendly to bandwidth brokers, but I do not > think that a bandwidth broker centric architecture or solution is > what we should do. > > John > > > _______________________________________________ > 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/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 11:05:11 2002 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 LAA27410 for ; Fri, 10 May 2002 11:05:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21511 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 11:05:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20681; Fri, 10 May 2002 10:55:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20646 for ; Fri, 10 May 2002 10:55:38 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26797 for ; Fri, 10 May 2002 10:55:28 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AEsjN12318; Fri, 10 May 2002 10:54:46 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 10:54:52 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4AAD@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Georgios Karagiannis (ELN)'" , "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt Date: Fri, 10 May 2002 10:55:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F831.B8BF6904" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1F831.B8BF6904 Content-Type: text/plain; charset="iso-8859-1" Georgios: We are in agreement on the relative roles, but your comment on triggering has me perplexed. I do not recall making any explicit comment on triggering. At the moment, I think it is too early to identify specific mechanisms for triggering. It seems to me that QoS signalling should be initiated as a consequence of other network activities (e.g. SDPng session negotiation), however, it is not clear how we would describe the requirements for this without getting into gory detail (e.g. what SDPng protocol event triggers QoS signalling). (Note: I use SDPng only to provide an example.) Gary > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: May 10, 2002 09:10 > To: Kenward, Gary [WDLN2:AN10:EXCH]; Georgios Karagiannis (ELN); > 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > Hi Gary > > I think that we are in agreement about the definition of > sender/ receiver initiated. > If you do not agree with the functionality that has to do > with the triggering is Okay with me. > In the scenarios that I am interested in, the QI will always > be either an end host > (or a proxy that operates as an end host). > > best regards, > Georgios > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: dinsdag 7 mei 2002 22:10 > To: 'Georgios Karagiannis (ELN)'; 'Freytsis, Ilya'; > 'john.loughney@nokia.com'; brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments Issue (2) included > indraft-ietf-nsis-req-01. txt > > > > Georgios: > > Actually, I was in agreement with you until I received this email. > It would seem to me, that the "sender" ("receiver") is a higher order > entity in the end-to-end scenario in that the "sender" > ("receiver") not > only initiates QoS, but also initiates AAA, session > establishment, and > ultimately, the actual data transfer (reception). So, the > "sender"("reciever) > would initiate the QI: either a QI at the end host, or a QI > acting as a proxy > within the network. In other words: the "sender"("receiver") > represents the > end host in this context. > > (Note that I have always equated QI with the end-host, for > non-proxy scenarios, > which would mean the "sender" ("receiver") is a QI - as well > as having other roles, > in those scenarios). > > In a proxy scenario, I do not understand why the QI would > "initiate" the "sender" > ("receiver") to "initiate" QoS. On the contrary, I see the > "sender" instructing > the proxy QI to initiate QoS setup, where the instruction may > be explicit or implicit > (i.e. NSIS does care what the form of this instruction is). > > Does this align with what you intended Georgios, or are we in > disagreement/ > > Gary > > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [ mailto:Georgios.Karagiannis@eln.ericsson.se > ] > > Sent: May 7, 2002 05:53 > > To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; > brunner@ccrle.nec.de > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] comments Issue (2) included > > indraft-ietf-nsis-req-01. txt > > > > > > Hi Ilya > > > > Maybe the terminology (in the NSIS requirements draft) > > is not clear, but what I mean with: > > > > * a sender initiated approach > > is that the sender of the data path starts the reservation > > towards the receiver, and > > > > * in the receiver initiated approach the receiver of the data path > > starts the reservation towards the sender. > > > > Additionally, note that the triggering of this initiation > > can also be done by entities that are not sender or receiver of the > > data path. > > > > In other words: > > * in a sender initiated approach, a QI, a QC or a QR > > that is not the sender of the data path will have to > > trigger the sender of the data path to start > > a sender initiated reservation. > > > > * in a receiver initiated approach, a QI, a QC or a QR > > that is not the receiver of the data path will have > > to trigger the receiver of the data path to start a > > receiver initiated reservation. > > > > > > I hope that this makes it more clear!! > > > > Best regards, > > Georgios > > > > -----Original Message----- > > From: Freytsis, Ilya [ mailto:ifreytsis@Cetacean.com > ] > > Sent: maandag 6 mei 2002 20:47 > > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; > > Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] comments Issue (2) included > > indraft-ietf-nsis-req-01. txt > > > > > > I support the idea to leave this requirement out. > > If you add 3d party requesting case (SIP proxy, application proxy, > > softswitch, you name it) than you see that QI does not > > necessarily represent > > neither receiver nor sender and the whole question becomes a > > moot point. As > > Marcus has mentioned as soon as we agreed that signaling path > > might differ > > from the data path we'd better not associate QI with any > > particular end of > > the data flow. > > It seems that it can be useful if NSIS protocol semantics > > allows a QI to > > request the bi-directional reservation but it can be rejected > > by the QC if > > employed QoS mechanism does not support it. > > > > Ilya > > > > -----Original Message----- > > From: john.loughney@nokia.com [ > mailto:john.loughney@nokia.com ] > > Sent: Thursday, May 02, 2002 1:49 PM > > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] comments Issue (2) included > > indraft-ietf-nsis-req-01. > > txt > > > > Hi Marcus, > > > > > The question is what are we doing with the requirement? > > > Both you and John favour > > > SHOULD support sender initiated > > > MAY support reciever initiated > > > > > > I would completly remove any requirements regarding initation. > > > > If we include requirements for initiation, I favor the above. > > However, > > I am not bothered if this is left out. > > > > 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 > > > > > ------_=_NextPart_001_01C1F831.B8BF6904 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt

Georgios:

 We are in agreement on the relative roles, but your comment on
triggering has me perplexed. I do not recall making any explicit
comment on triggering. At the moment, I think it is too early to
identify specific mechanisms for triggering. It seems to me that QoS
signalling should be initiated as a consequence of other network
activities (e.g. SDPng session negotiation), however, it is not
clear how we would describe the requirements for this without
getting into gory detail (e.g. what SDPng protocol event triggers
QoS signalling).

(Note: I use SDPng only to provide an example.)

Gary

> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: May 10, 2002 09:10
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Georgios Karagiannis (ELN);
> 'Freytsis, Ilya'; 'john.loughney@nokia.com'; brunner@ccrle.nec.de
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) included
> indraft-ietf-nsis-req-01. txt
>
>
> Hi Gary
> 
> I think that we are in agreement about the definition of
> sender/ receiver initiated.
> If you do not agree with the functionality that has to do
> with the triggering is Okay with me.
> In the scenarios that I am interested in, the QI will always
> be either an end host
> (or a proxy that operates as an end host).
> 
> best regards,
> Georgios
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: dinsdag 7 mei 2002 22:10
> To: 'Georgios Karagiannis (ELN)'; 'Freytsis, Ilya';
> 'john.loughney@nokia.com'; brunner@ccrle.nec.de
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] comments Issue (2) included
> indraft-ietf-nsis-req-01. txt
>
>
>
> Georgios:
>
>   Actually, I was in agreement with you until I received this email.
> It would seem to me, that the "sender" ("receiver") is a higher order
> entity in the end-to-end scenario in that the "sender"
> ("receiver") not
> only initiates QoS, but also initiates AAA, session
> establishment, and
> ultimately, the actual data transfer (reception). So, the
> "sender"("reciever)
> would initiate the QI: either a QI at the end host, or a QI
> acting as a proxy
> within the network. In other words: the "sender"("receiver")
> represents the
> end host in this context.
>
> (Note that I have always equated QI with the end-host, for
> non-proxy scenarios,
> which would mean the "sender" ("receiver") is a QI - as well
> as having other roles,
> in those scenarios).
>
> In a proxy scenario, I do not understand why the QI would
> "initiate" the "sender"
> ("receiver") to "initiate" QoS. On the contrary, I see the
> "sender" instructing
> the proxy QI to initiate QoS setup, where the instruction may
> be explicit or implicit
> (i.e. NSIS does care what the form of this instruction is).
>
> Does this align with what you intended Georgios, or are we in
> disagreement/
>
> Gary
>
>
> > -----Original Message-----
> > From: Georgios Karagiannis (ELN)
> > [ mailto:Georgios.Karagiannis@eln.ericsson.se
> <mailto:Georgios.Karagiannis@eln.ericsson.se> ]
> > Sent: May 7, 2002 05:53
> > To: 'Freytsis, Ilya'; 'john.loughney@nokia.com';
> brunner@ccrle.nec.de
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] comments Issue (2) included
> > indraft-ietf-nsis-req-01. txt
> >
> >
> > Hi Ilya
> >
> > Maybe the terminology (in the NSIS requirements draft)
> > is not clear, but what I mean with:
> >
> > * a sender initiated approach
> >   is that the sender of the data path starts the reservation
> >   towards the receiver, and
> >
> > * in the receiver initiated approach the receiver of the data path
> >   starts the reservation towards the sender.
> >
> > Additionally, note that the triggering of this initiation
> > can also be done by entities that are not sender or receiver of the
> > data path.
> >
> > In other words:
> >  * in a sender initiated approach, a QI, a QC or a QR
> >    that is not the sender of the data path will have to
> >    trigger the sender of the data path to start
> >    a sender initiated reservation.
> >
> >  * in a receiver initiated approach, a QI, a QC or a QR
> >    that is not the receiver of the data path will have
> >    to trigger the receiver of the data path to start a
> >    receiver initiated reservation.
> >
> >
> > I hope that this makes it more clear!!
> >
> > Best regards,
> > Georgios
> >
> > -----Original Message-----
> > From: Freytsis, Ilya [ mailto:ifreytsis@Cetacean.com
> <mailto:ifreytsis@Cetacean.com> ]
> > Sent: maandag 6 mei 2002 20:47
> > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de;
> > Georgios.Karagiannis@eln.ericsson.se
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] comments Issue (2) included
> > indraft-ietf-nsis-req-01. txt
> >
> >
> > I support the idea to leave this requirement out.
> > If you add 3d party requesting case (SIP proxy, application proxy,
> > softswitch, you name it) than you see that QI does not
> > necessarily represent
> > neither receiver nor sender and the whole question becomes a
> > moot point. As
> > Marcus has mentioned as soon as we agreed that signaling path
> > might differ
> > from the data path we'd better not associate QI with any
> > particular end of
> > the data flow.
> > It seems that it can be useful if NSIS protocol semantics
> > allows a QI to
> > request the bi-directional reservation but it can be rejected
> > by the QC if
> > employed QoS mechanism does not support it.
> >
> > Ilya
> > 
> > -----Original Message-----
> > From: john.loughney@nokia.com [
> mailto:john.loughney@nokia.com <mailto:john.loughney@nokia.com> ]
> > Sent: Thursday, May 02, 2002 1:49 PM
> > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] comments Issue (2) included
> > indraft-ietf-nsis-req-01.
> > txt
> >
> > Hi Marcus,
> >
> > > The question is what are we doing with the requirement?
> > > Both you and John favour
> > >   SHOULD support sender initiated
> > >   MAY support reciever initiated
> > >
> > > I would completly remove any requirements regarding initation.
> >
> > If we include requirements for initiation, I favor the above.
> >  However,
> > I am not bothered if this is left out.
> >
> > John
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> <https://www1.ietf.org/mailman/listinfo/nsis> 
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> <https://www1.ietf.org/mailman/listinfo/nsis> 
> >
>
>

------_=_NextPart_001_01C1F831.B8BF6904-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 11:21:13 2002 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 LAA28254 for ; Fri, 10 May 2002 11:21:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22494 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 11:21:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21776; Fri, 10 May 2002 11:09:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21695 for ; Fri, 10 May 2002 11:09:31 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27598 for ; Fri, 10 May 2002 11:09:21 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AF7PQ10492; Fri, 10 May 2002 11:07:25 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 11:07:31 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4AAF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Georgios Karagiannis (ELN)'" , "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Fri, 10 May 2002 11:07:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F833.70F4B852" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1F833.70F4B852 Content-Type: text/plain; charset="iso-8859-1" This is not just related to bandwidth brokers. It is a requirement for any number of system architectures where the service control points (not bandwidth brokers) are not located along the bearer path, and for any system where there are performance advantages in having the QoS signalling take a separate path from the bearer traffic. Personally, I see a tremendous potential for confusion. The charter, as John pointed out, precludes discussions of resource reservation. And yet, the only reason, as far as I can tell, for requiring QoS signalling to traverse the bearer path is for the purposes of resource reservation. Perhaps I am missing something (as usual). Gary > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: May 10, 2002 09:36 > To: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; > Ruediger.Geib@t-systems.com; Kenward, Gary [WDLN2:AN10:EXCH] > Cc: nsis@ietf.org > Subject: RE: [NSIS] To BB or not to BB > > > Hi Ilya > > This is one of the requirements that are mainly related > to bandwidth brokering scenarios and significantly > complicate the NSIS protocol. > > > best regards, > Georgios > > > -----Original Message----- > From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > Sent: vrijdag 10 mei 2002 15:30 > To: 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; > gkenward@nortelnetworks.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] To BB or not to BB > > > John, > > I think as long as we agreed that the NSIS signaling path is > allowed to > diverge from the data forwarding path everybody who cares > about BBs would be > satisfied. > > Ilya > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, May 10, 2002 4:26 AM > To: Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] To BB or not to BB > > Hi all, > > Just a general comment about Bandwidth Brokers and NSIS. Bandwidth > Brokers (as the are commonly defined) are actually out of scope > of NSIS. This means we are not defining a bandwidth broker > architecture. There was quite a bit of discussion (at a highlevel) > about this before NSIS was allowed to be chartered, and it was > said to me that bandwidth brokers are not really thought of > as part of the Internet architecture. > > However, I do know that there are many folks providing bandwidth > broker solutions. My view is that a bandwidth broker comes > dangerously close to how resources are provisioned, therefore > are out of scope of NSIS. From the charter: > > It is noted that resource reservation and traffic engineering can be > considered as part of network administration, and therefore > beyond the > scope of the IETF to mandate a particular mechanism. > > Additionally, some folks may wish to check on the TEWG > (http://www.ietf.org/html.charters/tewg-charter.html) for work on > traffic engineering. > > Finally, I do think it is perfectly acceptable to have a framework > and/or solution that is friendly to bandwidth brokers, but I do not > think that a bandwidth broker centric architecture or solution is > what we should do. > > 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 > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1F833.70F4B852 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] To BB or not to BB

This is not just related to bandwidth brokers. It is a requirement
for any number of system architectures where the service control points
(not bandwidth brokers) are not located along the bearer path, and
for any system where there are performance advantages in having the
QoS signalling take a separate path from the bearer traffic.

Personally, I see a tremendous potential for confusion.
The charter, as John pointed out, precludes discussions of resource
reservation. And yet, the only reason, as far as I can tell, for requiring
QoS signalling to traverse the bearer path is for the purposes of resource
reservation. Perhaps I am missing something (as usual).

Gary



> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: May 10, 2002 09:36
> To: 'Freytsis, Ilya'; 'john.loughney@nokia.com';
> Ruediger.Geib@t-systems.com; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] To BB or not to BB
>
>
> Hi Ilya
>
> This is one of the requirements that are mainly related
> to bandwidth brokering scenarios and significantly
> complicate the NSIS protocol.
>
>
> best regards,
> Georgios
>
>
> -----Original Message-----
> From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com]
> Sent: vrijdag 10 mei 2002 15:30
> To: 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com;
> gkenward@nortelnetworks.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] To BB or not to BB
>
>
> John,
>
> I think as long as we agreed that the NSIS signaling path is
> allowed to
> diverge from the data forwarding path everybody who cares
> about BBs would be
> satisfied.
>
> Ilya
>
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Friday, May 10, 2002 4:26 AM
> To: Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] To BB or not to BB
>
> Hi all,
>
> Just a general comment about Bandwidth Brokers and NSIS.  Bandwidth
> Brokers (as the are commonly defined) are actually out of scope
> of NSIS.  This means we are not defining a bandwidth broker
> architecture.  There was quite a bit of discussion (at a highlevel)
> about this before NSIS was allowed to be chartered, and it was
> said to me that bandwidth brokers are not really thought of
> as part of the Internet architecture.
>
> However, I do know that there are many folks providing bandwidth
> broker solutions.  My view is that a bandwidth broker comes
> dangerously close to how resources are provisioned, therefore
> are out of scope of NSIS. From the charter:
>
>  It is noted that resource reservation and traffic engineering can be
>  considered as part of network administration, and therefore
> beyond the
>  scope of the IETF to mandate a particular mechanism.
>
> Additionally, some folks may wish to check on the TEWG
> (http://www.ietf.org/html.charters/tewg-charter.html) for work on
> traffic engineering.
>
> Finally, I do think it is perfectly acceptable to have a framework
> and/or solution that is friendly to bandwidth brokers, but I do not
> think that a bandwidth broker centric architecture or solution is
> what we should do.
>
> 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
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1F833.70F4B852-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 10 14:12:41 2002 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 OAA09362 for ; Fri, 10 May 2002 14:12:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04065 for nsis-archive@odin.ietf.org; Fri, 10 May 2002 14:12:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03750; Fri, 10 May 2002 14:04:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03719 for ; Fri, 10 May 2002 14:04:08 -0400 (EDT) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08782 for ; Fri, 10 May 2002 14:03:57 -0400 (EDT) Received: from juniper.net (panther.juniper.net [172.17.12.226]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4AI3HT29466; Fri, 10 May 2002 11:03:17 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3CDC0B64.9060704@juniper.net> Date: Fri, 10 May 2002 11:03:16 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20011222 X-Accept-Language: en-us MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: john.loughney@nokia.com, Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com, nsis@ietf.org Subject: Re: [NSIS] To BB or not to BB References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DDE@esebe004.NOE.Nokia.com> <17960065.1021049089@[192.168.102.79]> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Marcus, I think that IETF, especially NSIS, should not become a kitchen sink for all possible combinations of network architecture. We belong to an engineering community here, that is, we need to try our best to come up with some practical solutions for some practical problems. Hence, could any *non-research* provider please please tell me if and when they will deploy BB to their customers? If there is a real demand for BB, we should look into it in IETF (not sure within the scope of NSIS neither)? Otherwise, why not push the work to other places, such as IRTF? 2 cents, - Ping Marcus Brunner wrote: > I am sorry, but I could not refrain from asking what Internet > Architecture BB are not part of? > > Otherwise I agree with John, the reqs and framework should allow for > various QoS architectures (including BB kind of architectures), defined > by the IETF. > > Marcus > > --On Friday, May 10, 2002 11:25 AM +0300 john.loughney@nokia.com wrote: > >> Hi all, >> >> Just a general comment about Bandwidth Brokers and NSIS. Bandwidth >> Brokers (as the are commonly defined) are actually out of scope >> of NSIS. This means we are not defining a bandwidth broker >> architecture. There was quite a bit of discussion (at a highlevel) >> about this before NSIS was allowed to be chartered, and it was >> said to me that bandwidth brokers are not really thought of >> as part of the Internet architecture. >> >> However, I do know that there are many folks providing bandwidth >> broker solutions. My view is that a bandwidth broker comes >> dangerously close to how resources are provisioned, therefore >> are out of scope of NSIS. From the charter: >> >> It is noted that resource reservation and traffic engineering can be >> considered as part of network administration, and therefore beyond the >> scope of the IETF to mandate a particular mechanism. >> >> Additionally, some folks may wish to check on the TEWG >> (http://www.ietf.org/html.charters/tewg-charter.html) for work on >> traffic engineering. >> >> Finally, I do think it is perfectly acceptable to have a framework >> and/or solution that is friendly to bandwidth brokers, but I do not >> think that a bandwidth broker centric architecture or solution is >> what we should do. >> >> John >> >> >> _______________________________________________ >> 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/ > 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 daemon@optimus.ietf.org Sun May 12 22:15:37 2002 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 WAA10707 for ; Sun, 12 May 2002 22:15:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22116 for nsis-archive@odin.ietf.org; Sun, 12 May 2002 22:15:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20907; Sun, 12 May 2002 22:03:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20873 for ; Sun, 12 May 2002 22:03:34 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10294; Sun, 12 May 2002 22:03:21 -0400 (EDT) From: Zhigang.Kan@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4D23rk28056; Mon, 13 May 2002 05:03:53 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 May 2002 05:03:30 +0300 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 13 May 2002 05:03:30 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 13 May 2002 10:02:59 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Interim Meeting Updated Agenda X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 13 May 2002 10:02:55 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD0412CC@beebe001.NOE.Nokia.com> Thread-Topic: Interim Meeting Updated Agenda Thread-Index: AcH4EAW+89df9vG3TpSUlWF9IEqdMACEg2pg To: , , Cc: , X-OriginalArrivalTime: 13 May 2002 02:02:59.0045 (UTC) FILETIME=[4E2C6950:01C1FA22] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA20874 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, You can find the draft titled "Two-plane and Three-tier QoS Framework for Mobile IPv6 Networks" at http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt. Br/Kan Zhigang -----Original Message----- From: Loughney John (NRC/Helsinki) Sent: Friday, May 10, 2002 6:47 PM To: nsis@ietf.org; ietf-announce@ietf.org Cc: sob@harvard.edu; mankin@isi.edu Subject: [NSIS] Interim Meeting Updated Agenda Hi all, Here is the updated agenda. Please indicate to me if there are any other drafts to be discussed. NSIS Interim Meeting Nokia Research Center, Helsinki Finland Tuesday May 21st 10 AM to 4 PM Wednesday May 22nd 9 AM to 4 PM Thursday May 23rd 9 AM to 12 Noon Tuesday AM ========== 10 AM Introduction 11 AM Requirements of a QoS Solution for Mobile IP (http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-02.txt) 12 Lunch 1 PM Requirements for QoS Signaling Protocols (http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-01.txt) Wednesday AM ============ 9 AM RSVP Proxy (http://www.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-03.txt) 10 AM Applicability of "Specification of the Null Service Type - RFC 2997" 11 AM Applicability of "A Framework For IntServ Operation Over Diffserv Networks - RFC 2998" 12 AM Lunch 1 PM Two-plane and Three-tier QoS Framework for Mobile IPv6 Networks (just submitted) 2 PM Towards a Framework for QoS Signaling in the Internet (http://search.ietf.org/internet-drafts/draft-hancock-nsis-framework-00.txt) 3 AM discussion of Framework issues Thursday ======== 9 AM Framework summary 10 AM Analysis of the Resource Reservation Protocol (to be submitted) 11 AM Anaysis discussion ========================== previous announcement ===================0 Hi all, NSIS will be having an Interim Meeting from May 21st through May 23rd, in Helsinki, Finland. Meeting location is tentatively planned to be at the Nokia Research Center facilities, at Itämerenkatu 11-13 in Helsinki. On a map, the location is here: http://kartta.hel.fi/kktesti/osoitehakuen/bigmap.asp?SearchOp=katunumero2&Desc=ITÄMERENKATU%2011%20HELSINKI%20&XValue=51042&YValue=72829 A good overview of Helsinki can be found here: http://www.explore-helsinki.com/ There are 2 hotels with special room rates, mention that you are Nokia guests when booking/paying a hotel room, so you can get the Nokia price. Seaside hotel: single room 90EUR, double room 112EUR Address: Ruoholahdenranta 3 FIN-00180 Helsinki, Finland Tel. +358 (0)9 693 60 Sales: +358 (0)9 6936 1016 Fax: +358 (0)9 6932 123 e-mail: seaside@seasidehotel.fi Web: www.seasidehotel.fi Toll free: 9800 2010 Best Western Worldwide Radisson SAS Royal hotel: single and double room 110EUR Address: Runeberginkatu, 2 SF-00100 Helsinki, Finland Phone: +358 9 695 80 Email: sales.royal.helsinki@radissonsas.com http://www.radisson.com/helsinkifi Helsinki is served by most major airlines. Busses are available from the Helsinki-Vanta Airport to the center of Helsinki, where there the hotels are located. Taxi service is available as well. It takes about 20 to 30 minutes to get to the center from the airport. The rough agenda is as follows: Tuesday May 21st 10 AM to 4 PM Wednesday May 22nd 9 AM to 4 PM Thursday May 23rd 9 AM to 12 Noon Topics are (dependent on draft submissions): Signaling Requirements. Analysis of existing signaling protocols. Framework Signaling Architecture Please indicate your attendance Tues ___ Wed ___ Thurs ___ Thank you, John Loughney _______________________________________________ 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 daemon@optimus.ietf.org Sun May 12 23:59:18 2002 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 XAA15385 for ; Sun, 12 May 2002 23:59:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA26955 for nsis-archive@odin.ietf.org; Sun, 12 May 2002 23:59:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26316; Sun, 12 May 2002 23:46:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26280 for ; Sun, 12 May 2002 23:46:22 -0400 (EDT) Date: Sun, 12 May 2002 23:46:22 -0400 (EDT) Message-Id: <200205130346.XAA26280@optimus.ietf.org> From: iporpr-admin@ietf.org To: nsis@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings Subject: [NSIS] Mail sent to IPORPR Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Your mail to 'IPORPR' with the subject: Sos! Is being held until the list moderator can review it for approval. The reason it is being held: Postings from member addresses only. Either the message will get posted to the list, or you will receive notification of the moderator's decision. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 02:33:11 2002 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 CAA28587 for ; Mon, 13 May 2002 02:33:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA11311 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 02:33:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05572; Mon, 13 May 2002 01:22:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05516 for ; Mon, 13 May 2002 01:22:48 -0400 (EDT) Date: Mon, 13 May 2002 01:22:48 -0400 (EDT) Message-Id: <200205130522.BAA05516@optimus.ietf.org> From: rmt-admin@ietf.org To: nsis@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport Subject: [NSIS] Mail sent to Rmt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Your mail to 'Rmt' with the subject: And troubleshooters located in the Start Is being held until the list moderator can review it for approval. The reason it is being held: Only approved posters may post without moderator approval. Either the message will get posted to the list, or you will receive notification of the moderator's decision. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 04:30:47 2002 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 EAA00553 for ; Mon, 13 May 2002 04:30:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16917 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 04:30:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16317; Mon, 13 May 2002 04:21:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16274 for ; Mon, 13 May 2002 04:21:29 -0400 (EDT) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00398 for ; Mon, 13 May 2002 04:21:17 -0400 (EDT) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4D8KtT77664; Mon, 13 May 2002 01:20:56 -0700 (PDT) (envelope-from pingpan@juniper.net) Date: Mon, 13 May 2002 01:20:55 -0700 (PDT) From: Ping Pan To: "Geib, Ruediger" cc: Subject: RE: [NSIS] To BB or not to BB In-Reply-To: Message-ID: <20020513010323.R38220-100000@garnet.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id EAA16275 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit On Mon, 13 May 2002, Geib, Ruediger wrote: > Hello Ping, > > > Hence, could any *non-research* provider please please tell me if and > > when they will deploy BB to their customers? > > Yes, there is interest in having QoS signaling > architecture removing signaling support from > routers. The charm of a BB like QoS resource > administration is that it removes dependancies > of carriers from router vendors - and will work > with a heterogeneous router environment. BB's > may be developed and changed independant from > router operating systems. Of course this doesn't > come for free. The BB must provide a management > access to a router, which of course depends on > router operating systems. > After developed COPS multiple times in the past, my experience has been that BB is to simply lift all the work from a distributed system (router network) to a centralized system (BB network). Instead making things simple, BB's will do the same amount of message processing, state management etc. as the routers, but BB's will now have to somehow knowing the entire network AND to sync up states with the routers. At the end, BB's just make the whole thing more complex. > I'm not sure what you mean by "deploying a BB > to my customer". I guess a first step in > supporting automated QoS resource negotiation > will some kind of Web based access to a policy > management system. > It wouldn't change if a BB > is introduced. Between domains, BB's may talk > directly with each other. > > In some cases, like support of mobile wireless > terminals, a hybrid solution may be best. > Mobile signals to edge router, edge router > signals to BB. > This allows core routers to > stay out of signaling business. Of course the > argument of vendor independance gets lost. > However the required signaling functionalities > are still limited: simply forward message to > the BB and forward replies to the mobile. > Hoe about this: mobile devices create a session with some policy servers for billing. The packets may go through routers, and the routers don't have to do much about it. Only when the mobile devices want to get network resource, it can ask the routers, and routers can signal the rest of the network. In this case, routers don't have to care anything about BB or not BB, and mobile devices can talk to the servers without worrying about if routers will do something crazy to the packets. :-) > What I'd expect from NSIS on BB's is to allow > for specifications of inter domain signaling > specifications supporting a centralised QoS > resource administration. What kind of inter-domain are you referring to? Please tell me how to run centralised XYZ administration in the inter-domain enviornment in the Internet? :-) - Ping > Nothing else. This > at least should (better must) interwork with > a purely router based signaling protocol > developed by NSIS. > > Regards, > > Rüdiger > > PS: T-Systems is part of Deutsche Telekom. > That's a *non-research* provider. I'm talking > here as an individual, however. > > > Rüdiger Geib > Senior Expert > Systems Integration > T-Systems Nova GmbH > Technologiezentrum > Am Kavalleriesand 3, 64295 Darmstadt > Germany > Fon: +49 6151 832138 > Fax: +49 6151 838103 > mailto:Ruediger.Geib@t-systems.com > http://www.t-nova.de > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 15:32:41 2002 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 PAA28328 for ; Mon, 13 May 2002 15:32:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21303 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 15:32:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20818; Mon, 13 May 2002 15:24:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20787 for ; Mon, 13 May 2002 15:24:50 -0400 (EDT) Received: from hotmail.com (law2-f126.hotmail.com [216.32.181.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27898 for ; Mon, 13 May 2002 15:24:36 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 13 May 2002 12:24:13 -0700 Received: from 63.127.199.195 by lw2fd.hotmail.msn.com with HTTP; Mon, 13 May 2002 19:24:13 GMT X-Originating-IP: [63.127.199.195] From: "Ilya Freytsis" To: nsis@ietf.org Date: Mon, 13 May 2002 15:24:13 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 May 2002 19:24:13.0463 (UTC) FILETIME=[C3D41270:01C1FAB3] Subject: [NSIS] test Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 15:34:54 2002 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 PAA28458 for ; Mon, 13 May 2002 15:34:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21434 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 15:35:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20956; Mon, 13 May 2002 15:27:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20922 for ; Mon, 13 May 2002 15:26:57 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27989 for ; Mon, 13 May 2002 15:26:43 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 15:21:30 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93144@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'nsis@ietf.org'" Date: Mon, 13 May 2002 15:21:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="Windows-1251" Subject: [NSIS] requirements draft and NSIS "product" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org All, It took me for a while till I realized that my biggest problem with this draft is presented in its first statement: "This document defines requirements for signaling QoS across different network environments". I could not find the answer to the question - what is QoS signaling? Is it a protocol, collection of inter-working protocols (signaling architecture) or something different all together? Furthermore, without giving an answer to this question we have dived into the discussion of detailed requirements to ... whatever people have in their minds. The lack of clarity (at least in my mind) on this subject makes me feel often at odds with some pieces of the document while I am in the full agreement with others. It seems that the clarity and precision of the statements acceptable for the group charter are not sufficient to move forward requirements (followed by the framework). Am I missing something and this subject has been already discussed and agreed upon? I'll appreciate if somebody can clarify it for me. If I am not alone in my concerns I would like to start the interim meeting in Helsinki with this discussion. To have a meaningful requirement you should know how you could tell whether it is met or not. Without clearly defining the "product" it is not simply possible. Best regards, Ilya Freytsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 16:29:51 2002 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 QAA01496 for ; Mon, 13 May 2002 16:29:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24213 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:30:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14139; Mon, 13 May 2002 03:35:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14100 for ; Mon, 13 May 2002 03:35:24 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29899 for ; Mon, 13 May 2002 03:35:11 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 13 May 2002 09:33:46 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 09:34:52 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Date: Mon, 13 May 2002 09:34:49 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA14101 Subject: [NSIS] New requirements draft before interim meeting? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Marcus, you've mentioned that you already plan a new version of the NSIS requirements draft. The agenda for the interim meeting however lists version 01, so the next version won't get available before the interim? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 16:30:00 2002 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 QAA01524 for ; Mon, 13 May 2002 16:30:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24236 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:30:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18978; Mon, 13 May 2002 14:56:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18946 for ; Mon, 13 May 2002 14:56:34 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26269 for ; Mon, 13 May 2002 14:56:16 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 14:51:03 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93143@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'nsis@ietf.org'" Date: Mon, 13 May 2002 14:51:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="Windows-1251" Subject: [NSIS] requirements draft and NSIS "product" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org All, It took me for a while till I realized that my biggest problem with this draft is presented in its first statement: "This document defines requirements for signaling QoS across different network environments". I could not find the answer to the question - what is QoS signaling? Is it a protocol, collection of inter-working protocols (signaling architecture) or something different all together? Furthermore, without giving an answer to this question we have dived into the discussion of detailed requirements to ... whatever people have in their minds. The lack of clarity (at least in my mind) on this subject makes me feel often at odds with some pieces of the document while I am in the full agreement with others. It seems that the clarity and precision of the statements acceptable for the group charter are not sufficient to move forward requirements (followed by the framework). Am I missing something and this subject has been already discussed and agreed upon? I'll appreciate if somebody can clarify it for me. If I am not alone in my concerns I would like to start the interim meeting in Helsinki with this discussion. To have a meaningful requirement you should know how you could tell whether it is met or not. Without clearly defining the "product" it is not simply possible. Best regards, Ilya Freytsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 16:33:55 2002 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 QAA01745 for ; Mon, 13 May 2002 16:33:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24804 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:34:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17419; Mon, 13 May 2002 04:35:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17372 for ; Mon, 13 May 2002 04:35:30 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00644 for ; Mon, 13 May 2002 04:35:19 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4D8Yx872106; Mon, 13 May 2002 10:34:59 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA22524; Mon, 13 May 2002 10:32:29 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1941314700; Mon, 13 May 2002 10:32:29 +0200 (CEST) Date: Mon, 13 May 2002 10:45:02 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Geib, Ruediger" Cc: nsis@ietf.org Message-ID: <1662130.1021286702@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA17373 Subject: [NSIS] Re: New requirements draft before interim meeting? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Ruediger, Thanks for the hint. I think I am not able to submit a complete new draft, but I hope to extend the issues list from -01 with all the issues, which came up in the mailing list. Marcus --On Monday, May 13, 2002 9:34 AM +0200 "Geib, Ruediger" wrote: > Hello Marcus, > > you've mentioned that you already plan a new version of the NSIS > requirements draft. The agenda for the interim meeting however lists > version 01, so the next version won't get available before the interim? > > Regards, Rüdiger -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 16:38:52 2002 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 QAA01976 for ; Mon, 13 May 2002 16:38:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25133 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:39:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24781; Mon, 13 May 2002 16:33:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24743 for ; Mon, 13 May 2002 16:33:48 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01723 for ; Mon, 13 May 2002 16:33:36 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 16:28:22 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93145@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] new version of draft (-01) submitted Date: Mon, 13 May 2002 16:28:16 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Marcus, Please receive my comment to the draft made from the point of view on NSIS as a protocol (meta-protocol that can be instantiated in a number of protocols). Requirements are viewed as requirements that have to be satisfied by the protocols' semantics but may or may not be supported by the particular implementation in the particular network parts: Terminology QoS Initiator definition calling for QI to invoke local QoS provisioning. I think it is not always true (think application proxy). I suggest to slightly change definition "... as well as possibly invoking local QoS provisioning mechanisms" Problem statement and scope Discussing placement of QIs and QCs the draft presenting two extreme cases (every router incorporates QI and QC; only end systems incorporate QI and QC). I suggest adding another case when neither QI nor QC is on the data path. This case actually depicted in the fig 2 from the scenario 8.9 - trunking gateway with MGC acting as QI and separate (from MGC) QCs managing resources of the domains along the data path. Requirements I think the language in this section should be change to stricter, "requirement like". Like the one used in Ruediger's e-mails on operational and error signaling requirements. It seems to me that there is a number of requirements that nobody will be able to tell if they are satisfied or not by the developed "product". In particular it is applicable to the requirements from the section 5.6 Performance and open issue 33 (highest possible network utilization). I suggest reducing the number of sections in the Requirements section by merging content of the section 5.4 Layering into the section 5.1 Architecture and Design. Architecture and Design: - Requirements 5.1.5 is pretty much covered in 5.1.1 and can be removed - Requirements 5.2.2 is of architectural nature and belongs to the section 5.1. Additional Information beyond signaling: - Requirement 5.3.2. I understand that NSIS signaling should enable this type of behavior but the behavior itself is service specific and out of NSIS scope. For example, if in the scenario 8.9 (trunking gateway) the gateway controller (QI) dies you may want to preserve resources allocated for the active calls instead of releasing them. - Requirement 5.3.3. It is not clear what failure this requirement is dealing with. Is it failure of NSIS signaling entities (QI, QC) or failure in the data-forwarding plane (router)? Open issue 28: I support this requirement. Regards, Ilya Freytsis -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: Friday, April 12, 2002 12:54 PM To: nsis@ietf.org Subject: [NSIS] new version of draft (-01) submitted Dear NSIS WG, I have just now submitted a new version of the reqirements draft. It is meant to be an intermediate version to give you an impression of what has been going on in the last weeks. Major changes include - restructured the draft - added an extensive list of open and closed isues, coming from various places. -please check them whether is something miosssing from the issues side -some have volunteered to help with some of the issue (see the mail "home work" addressed to those) -some of the closed issues can be used as a change log - I currently see the following three areas, which are not covered - interaction with mobility and running signaling in mobile environements - security issues - fault handling issues - I am sorry, I am not able to put the thing on a web-page for those, which can not wait and want to work over the weekend :-) Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ 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 daemon@optimus.ietf.org Mon May 13 16:42:39 2002 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 QAA02134 for ; Mon, 13 May 2002 16:42:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25276 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:42:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11565; Mon, 13 May 2002 02:36:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11535 for ; Mon, 13 May 2002 02:36:25 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28667 for ; Mon, 13 May 2002 02:36:11 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4D6afk01312 for ; Mon, 13 May 2002 09:36:41 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 13 May 2002 09:36:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 13 May 2002 09:35:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 13 May 2002 09:35:16 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6510A@esebe004.NOE.Nokia.com> Thread-Topic: I-D ACTION:draft-rfc-editor-author-lists-00.txt Thread-Index: AcH4Jja7+L6L7jqXQD+Uo+5MhBu1zwCIdD+Q To: X-OriginalArrivalTime: 13 May 2002 06:35:16.0685 (UTC) FILETIME=[582A6FD0:01C1FA48] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA11536 Subject: [NSIS] FW: I-D ACTION:draft-rfc-editor-author-lists-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, I suggest that everyone read the following document, as it will shortly become 'official' IETF policy. This will be enforced, additionally, I do agree with the document. If folks have some issues on the document, my suggestion is for you to send the comments to the authors & to the IESG. best regards, John A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RFC Editor Guidelines on Author Lists Author(s) : J. Reynolds, B. Braden Filename : draft-rfc-editor-author-lists-00.txt Pages : 6 Date : 09-May-02 This memo presents a new set of guidelines to govern lists of authors on RFC documents. It is intended to counteract a recent tendency towards author list inflation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rfc-editor-author-lists-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-rfc-editor-author-lists-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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 16:46:06 2002 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 QAA02276 for ; Mon, 13 May 2002 16:46:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25419 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:46:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13081; Mon, 13 May 2002 03:09:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13039 for ; Mon, 13 May 2002 03:08:58 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29558 for ; Mon, 13 May 2002 03:08:45 -0400 (EDT) Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 13 May 2002 09:07:19 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 09:08:25 +0200 Message-Id: From: "Geib, Ruediger" To: pingpan@juniper.net Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Mon, 13 May 2002 09:08:22 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA13040 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Ping, > Hence, could any *non-research* provider please please tell me if and > when they will deploy BB to their customers? Yes, there is interest in having QoS signaling architecture removing signaling support from routers. The charm of a BB like QoS resource administration is that it removes dependancies of carriers from router vendors - and will work with a heterogeneous router environment. BB's may be developed and changed independant from router operating systems. Of course this doesn't come for free. The BB must provide a management access to a router, which of course depends on router operating systems. I'm not sure what you mean by "deploying a BB to my customer". I guess a first step in supporting automated QoS resource negotiation will some kind of Web based access to a policy management system. It wouldn't change if a BB is introduced. Between domains, BB's may talk directly with each other. In some cases, like support of mobile wireless terminals, a hybrid solution may be best. Mobile signals to edge router, edge router signals to BB. This allows core routers to stay out of signaling business. Of course the argument of vendor independance gets lost. However the required signaling functionalities are still limited: simply forward message to the BB and forward replies to the mobile. What I'd expect from NSIS on BB's is to allow for specifications of inter domain signaling specifications supporting a centralised QoS resource administration. Nothing else. This at least should (better must) interwork with a purely router based signaling protocol developed by NSIS. Regards, Rüdiger PS: T-Systems is part of Deutsche Telekom. That's a *non-research* provider. I'm talking here as an individual, however. Rüdiger Geib Senior Expert Systems Integration T-Systems Nova GmbH Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 832138 Fax: +49 6151 838103 mailto:Ruediger.Geib@t-systems.com http://www.t-nova.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 16:48:33 2002 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 QAA02411 for ; Mon, 13 May 2002 16:48:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25529 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:48:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26441; Mon, 13 May 2002 07:34:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26398 for ; Mon, 13 May 2002 07:34:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03682; Mon, 13 May 2002 07:34:10 -0400 (EDT) Message-Id: <200205131134.HAA03682@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: Mon, 13 May 2002 07:34:10 -0400 Subject: [NSIS] I-D ACTION:draft-kan-qos-framework-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Two-plane and Three-tier QoS Framework for Mobile IPv6 Networks Author(s) : Z. Kan, J. Ma Filename : draft-kan-qos-framework-00.txt Pages : 16 Date : 10-May-02 This document proposes a 'two-plane three-tier' QoS framework for mobile IPv6 networks. In this framework the Access Networks are connected with wired backbone through default routers. QoS policies which are implemented in inter-Administration Domains (between Qos Agents) and intra-Administration (between QoS Agent and Local QoS Agents) and QoS negotiations are in the control plane. User data is transported in the transport plane. COPS/Diameter is used for exchanging QoS policies. Three-Tier QoS mechanisms mean that QoS mechanisms should be done in three levels. The first level is Inter-Administration Domain QoS mechanisms across neighboring Administration Domains, and the second level is Intra-Administration Domain QoS mechanisms inside each Administration Domain while the third level is edge QoS negotiation and end-to-end QoS negotiation. The aggregate traffic crossing Administration Domain borders is served according to relatively stable, long-lived bilateral agreements. End-to-end QoS support is achieved through the concatenation of such bilateral agreements. QoS signalings are independent of the proposed framework. As an example, the extended Mobile IPv6 signalings that include Binding Update, Binding Request, and Binding Acknowledge are used for end- to-end QoS negotiations and resource advance reservation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kan-qos-framework-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-kan-qos-framework-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-kan-qos-framework-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: <20020510124200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kan-qos-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kan-qos-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020510124200.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 16:51:55 2002 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 QAA02558 for ; Mon, 13 May 2002 16:51:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25625 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:52:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18291; Mon, 13 May 2002 04:51:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18253 for ; Mon, 13 May 2002 04:51:17 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00865 for ; Mon, 13 May 2002 04:51:05 -0400 (EDT) Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 13 May 2002 10:49:38 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 10:50:44 +0200 Message-Id: From: "Geib, Ruediger" To: pingpan@juniper.net Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Mon, 13 May 2002 10:50:37 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA18254 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit > After developed COPS multiple times in the past, > my experience has been that BB is to simply lift > all the work from a distributed system (router > network) to a centralized system (BB network). > Instead making things simple, BB's will do the > same amount of message processing, state management > etc. as the routers, but BB's will now have to > somehow knowing the entire network AND to sync > up states with the routers. At the end, BB's just > make the whole thing more complex. BB's will be optimized to process signaling messages which of course have to be processed somewhere. I didn't argue for a centralized solution being simple. Coping with e.g. route changes will introduce complexity in any signaling architecture. I don't know by now which solution will be more complex. And I won't argue against a router based signaling mechanism based on IntServ development experiences (I personally don't have it). I must also admit that COPS isn't my favorite protocol. > Hoe about this: mobile devices create a session > with some policy servers for billing. The packets may > go through routers, and the routers don't have to do > much about it. Only when the mobile devices want to > get network resource, it can ask the routers, and > routers can signal the rest of the network. In this > case, routers don't have to care anything about BB or > not BB, and mobile devices can talk to the servers > without worrying about if routers will do something > crazy to the packets. :-) But what if the wireless mobile changes base station and expects a seamless handoff? If all routers know where to send and get signaling information to, a seamless handoff may be feasible while in your scenario some routers start to do things during handoff while some servers may do other things. You must synchronize them. Sounds complex too, doesn't it? Or do you expect all the related signaling to be done by the mobile. This wuoldn't quite be what mobile terminal developers dream of. > What kind of inter-domain are you referring to? > Please tell me how to run centralised XYZ > administration in the inter-domain enviornment in the > Internet? :-) Every domain may have its own centralized admin system signaling to other centralized or non centralized systems. This thread is only partially related to actual NSIS issues. I'm happy to continue private discussion. All I'm suggesting with regard to NSIS is that people contribute requirements instead of talking solutions - especially if they talk about solutions they don't like. Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 16:56:43 2002 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 QAA02763 for ; Mon, 13 May 2002 16:56:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25912 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:56:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02712; Mon, 13 May 2002 09:40:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02636 for ; Mon, 13 May 2002 09:39:52 -0400 (EDT) Received: from mail2.orchestream.com (mail2.orchestream.com [195.153.64.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09610; Mon, 13 May 2002 09:39:38 -0400 (EDT) From: john.loughney@nokia.com Received: from mx2.mail.uk.psi.net (unverified) by mail2.orchestream.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Fri, 10 May 2002 16:12:22 +0100 Received: from loki.ietf.org ([132.151.1.177]) by mx2.mail.uk.psi.net with esmtp (Exim 2.12 #2) id 176Anv-00069E-00; Fri, 10 May 2002 14:51:27 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA14290 for ietf-outbound.04@loki.ietf.org; Fri, 10 May 2002 09:44:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id JAA14270 for ; Fri, 10 May 2002 09:43:21 -0400 (EDT) Received: by ietf.org (8.9.1a/8.9.1a) id JAA22270 for ietf-mainout; Fri, 10 May 2002 09:43:12 -0400 (EDT) X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13299 for ; Fri, 10 May 2002 06:48:28 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4AAmxk06998 for ; Fri, 10 May 2002 13:48:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 10 May 2002 13:48:30 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 10 May 2002 13:48:37 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-OriginalArrivalTime: 10 May 2002 10:47:05.0436 (UTC) FILETIME=[0671A1C0:01C1F810] Date: Fri, 10 May 2002 13:48:36 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC650EC@esebe004.NOE.Nokia.com> Thread-Topic: Interim Meeting Updated Agenda Thread-Index: AcH4EAW+89df9vG3TpSUlWF9IEqdMA== To: , Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA13300 Precedence: bulk X-Loop: ietf@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by loki.ietf.org id JAB14290 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA02637 Subject: [NSIS] Interim Meeting Updated Agenda Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Here is the updated agenda. Please indicate to me if there are any other drafts to be discussed. NSIS Interim Meeting Nokia Research Center, Helsinki Finland Tuesday May 21st 10 AM to 4 PM Wednesday May 22nd 9 AM to 4 PM Thursday May 23rd 9 AM to 12 Noon Tuesday AM ========== 10 AM Introduction 11 AM Requirements of a QoS Solution for Mobile IP (http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-02.txt) 12 Lunch 1 PM Requirements for QoS Signaling Protocols (http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-01.txt) Wednesday AM ============ 9 AM RSVP Proxy (http://www.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-03.txt) 10 AM Applicability of "Specification of the Null Service Type - RFC 2997" 11 AM Applicability of "A Framework For IntServ Operation Over Diffserv Networks - RFC 2998" 12 AM Lunch 1 PM Two-plane and Three-tier QoS Framework for Mobile IPv6 Networks (just submitted) 2 PM Towards a Framework for QoS Signaling in the Internet (http://search.ietf.org/internet-drafts/draft-hancock-nsis-framework-00.txt) 3 AM discussion of Framework issues Thursday ======== 9 AM Framework summary 10 AM Analysis of the Resource Reservation Protocol (to be submitted) 11 AM Anaysis discussion ========================== previous announcement ===================0 Hi all, NSIS will be having an Interim Meeting from May 21st through May 23rd, in Helsinki, Finland. Meeting location is tentatively planned to be at the Nokia Research Center facilities, at Itämerenkatu 11-13 in Helsinki. On a map, the location is here: http://kartta.hel.fi/kktesti/osoitehakuen/bigmap.asp?SearchOp=katunumero2&Desc=ITÄMERENKATU%2011%20HELSINKI%20&XValue=51042&YValue=72829 A good overview of Helsinki can be found here: http://www.explore-helsinki.com/ There are 2 hotels with special room rates, mention that you are Nokia guests when booking/paying a hotel room, so you can get the Nokia price. Seaside hotel: single room 90EUR, double room 112EUR Address: Ruoholahdenranta 3 FIN-00180 Helsinki, Finland Tel. +358 (0)9 693 60 Sales: +358 (0)9 6936 1016 Fax: +358 (0)9 6932 123 e-mail: seaside@seasidehotel.fi Web: www.seasidehotel.fi Toll free: 9800 2010 Best Western Worldwide Radisson SAS Royal hotel: single and double room 110EUR Address: Runeberginkatu, 2 SF-00100 Helsinki, Finland Phone: +358 9 695 80 Email: sales.royal.helsinki@radissonsas.com http://www.radisson.com/helsinkifi Helsinki is served by most major airlines. Busses are available from the Helsinki-Vanta Airport to the center of Helsinki, where there the hotels are located. Taxi service is available as well. It takes about 20 to 30 minutes to get to the center from the airport. The rough agenda is as follows: Tuesday May 21st 10 AM to 4 PM Wednesday May 22nd 9 AM to 4 PM Thursday May 23rd 9 AM to 12 Noon Topics are (dependent on draft submissions): Signaling Requirements. Analysis of existing signaling protocols. Framework Signaling Architecture Please indicate your attendance Tues ___ Wed ___ Thurs ___ Thank you, John Loughney . _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 16:58:17 2002 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 QAA02880 for ; Mon, 13 May 2002 16:58:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25987 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:58:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14950; Mon, 13 May 2002 13:31:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14907 for ; Mon, 13 May 2002 13:30:56 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21208; Mon, 13 May 2002 13:30:41 -0400 (EDT) Message-Id: <200205131730.NAA21208@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: Mon, 13 May 2002 13:30:41 -0400 Subject: [NSIS] I-D ACTION:draft-kan-qos-framework-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Two-plane and Three-tier QoS Framework for Mobile IPv6 Networks Author(s) : Z. Kan, J. Ma Filename : draft-kan-qos-framework-00.txt Pages : 16 Date : 10-May-02 This document proposes a 'two-plane three-tier' QoS framework for mobile IPv6 networks. In this framework the Access Networks are connected with wired backbone through default routers. QoS policies which are implemented in inter-Administration Domains (between Qos Agents) and intra-Administration (between QoS Agent and Local QoS Agents) and QoS negotiations are in the control plane. User data is transported in the transport plane. COPS/Diameter is used for exchanging QoS policies. Three-Tier QoS mechanisms mean that QoS mechanisms should be done in three levels. The first level is Inter-Administration Domain QoS mechanisms across neighboring Administration Domains, and the second level is Intra-Administration Domain QoS mechanisms inside each Administration Domain while the third level is edge QoS negotiation and end-to-end QoS negotiation. The aggregate traffic crossing Administration Domain borders is served according to relatively stable, long-lived bilateral agreements. End-to-end QoS support is achieved through the concatenation of such bilateral agreements. QoS signalings are independent of the proposed framework. As an example, the extended Mobile IPv6 signalings that include Binding Update, Binding Request, and Binding Acknowledge are used for end- to-end QoS negotiations and resource advance reservation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kan-qos-framework-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-kan-qos-framework-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-kan-qos-framework-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: <20020510124200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kan-qos-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kan-qos-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020510124200.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 13 16:58:52 2002 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 QAA02954 for ; Mon, 13 May 2002 16:58:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26069 for nsis-archive@odin.ietf.org; Mon, 13 May 2002 16:59:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10763; Mon, 13 May 2002 12:04:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10726 for ; Mon, 13 May 2002 12:04:05 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17398 for ; Mon, 13 May 2002 12:03:53 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g4DG79N21016; Mon, 13 May 2002 11:07:09 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g4DG3DJ05929; Mon, 13 May 2002 11:03:13 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 11:03:59 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BAD7@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Ping Pan'" , brunner@ccrle.nec.de Cc: john.loughney@nokia.com, Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com, nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Mon, 13 May 2002 11:03:58 -0500 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Ping, I am not sure how you define a Bandwidth Broker. As I and one of my colleagues at SBC have expressed to you on several occasions, we at SBC want to enable our customers to signal for QOS flows across our network. If we are successfull NSIS will become the common signaling protocol to do that across all access methods. Because the timing does not fit our immediate needs, we have proposed extensions to RSVP as a way to access ATM and MPLS networks. In our architecture, customer initiated RSVP signaling will be directed to an controller which proxy signals for a connection across our network. It should come as no surprise that a number of other carriers share an interest in this approach as a way to exploit their already deployed ATM infrastructure. My 3 Cents, Marco > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: Friday, May 10, 2002 1:03 PM > To: brunner@ccrle.nec.de > Cc: john.loughney@nokia.com; Ruediger.Geib@t-systems.com; > gkenward@nortelnetworks.com; nsis@ietf.org > Subject: Re: [NSIS] To BB or not to BB > > > Marcus, > > I think that IETF, especially NSIS, should not become a > kitchen sink for > all possible combinations of network architecture. We belong to an > engineering community here, that is, we need to try our best > to come up > with some practical solutions for some practical problems. > > Hence, could any *non-research* provider please please tell me if and > when they will deploy BB to their customers? If there is a > real demand > for BB, we should look into it in IETF (not sure within the scope of > NSIS neither)? Otherwise, why not push the work to other > places, such as > IRTF? > > 2 cents, > > - Ping > > > > Marcus Brunner wrote: > > > I am sorry, but I could not refrain from asking what Internet > > Architecture BB are not part of? > > > > Otherwise I agree with John, the reqs and framework should > allow for > > various QoS architectures (including BB kind of > architectures), defined > > by the IETF. > > > > Marcus > > > > --On Friday, May 10, 2002 11:25 AM +0300 > john.loughney@nokia.com wrote: > > > >> Hi all, > >> > >> Just a general comment about Bandwidth Brokers and NSIS. Bandwidth > >> Brokers (as the are commonly defined) are actually out of scope > >> of NSIS. This means we are not defining a bandwidth broker > >> architecture. There was quite a bit of discussion (at a highlevel) > >> about this before NSIS was allowed to be chartered, and it was > >> said to me that bandwidth brokers are not really thought of > >> as part of the Internet architecture. > >> > >> However, I do know that there are many folks providing bandwidth > >> broker solutions. My view is that a bandwidth broker comes > >> dangerously close to how resources are provisioned, therefore > >> are out of scope of NSIS. From the charter: > >> > >> It is noted that resource reservation and traffic > engineering can be > >> considered as part of network administration, and > therefore beyond the > >> scope of the IETF to mandate a particular mechanism. > >> > >> Additionally, some folks may wish to check on the TEWG > >> (http://www.ietf.org/html.charters/tewg-charter.html) for work on > >> traffic engineering. > >> > >> Finally, I do think it is perfectly acceptable to have a framework > >> and/or solution that is friendly to bandwidth brokers, but I do not > >> think that a bandwidth broker centric architecture or solution is > >> what we should do. > >> > >> John > >> > >> > >> _______________________________________________ > >> 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/ > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 14 04:23:45 2002 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 EAA08796 for ; Tue, 14 May 2002 04:23:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16605 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 04:23:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16208; Tue, 14 May 2002 04:17:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16179 for ; Tue, 14 May 2002 04:17:44 -0400 (EDT) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08545 for ; Tue, 14 May 2002 04:17:31 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 177XV6-0003ci-00; Tue, 14 May 2002 10:17:40 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 177XV6-0005rJ-00; Tue, 14 May 2002 10:17:40 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g4E8Hd107580; Tue, 14 May 2002 10:17:39 +0200 Message-Id: <200205140817.g4E8Hd107580@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: "Georgios Karagiannis (ELN)" cc: "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com, nsis@ietf.org Subject: Re: [NSIS] To BB or not to BB In-Reply-To: Message from "Georgios Karagiannis (ELN)" of "Fri, 10 May 2002 15:36:24 +0200." References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 14 May 2002 10:17:39 +0200 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > This is one of the requirements that are mainly related > to bandwidth brokering scenarios and significantly > complicate the NSIS protocol. Sorry, but I disagree here. It gives you much more flexibility, but I don't see how it complicates things significantly. IMO an NSIS solution should allow at least both solutions, either router-based (RSVP-like) or BB-based, and, personally I don't think this will complicate things that much. Regards, Roland >-----Original Message----- >From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] >Sent: vrijdag 10 mei 2002 15:30 >To: 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; >gkenward@nortelnetworks.com >Cc: nsis@ietf.org >Subject: RE: [NSIS] To BB or not to BB > > >John, > >I think as long as we agreed that the NSIS signaling path is allowed to >diverge from the data forwarding path everybody who cares about BBs would be >satisfied. > >Ilya _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 14 04:29:03 2002 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 EAA08976 for ; Tue, 14 May 2002 04:29:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16919 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 04:29:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16769; Tue, 14 May 2002 04:26:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16734 for ; Tue, 14 May 2002 04:26:29 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08875 for ; Tue, 14 May 2002 04:26:15 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4E8QNs7007781 for ; Tue, 14 May 2002 10:26:23 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue May 14 10:25:56 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22816VZP>; Tue, 14 May 2002 10:25:05 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Roland Bless'" Cc: "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com, nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Tue, 14 May 2002 10:25:53 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi I think it will be very good if we will extensively discuss these issues in Helsinki (at interim meeting). Best Regards, Georgios -----Original Message----- From: Roland Bless [mailto:bless@tm.uka.de] Sent: dinsdag 14 mei 2002 10:18 To: Georgios Karagiannis (ELN) Cc: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com; nsis@ietf.org Subject: Re: [NSIS] To BB or not to BB Hi Georgios, > This is one of the requirements that are mainly related > to bandwidth brokering scenarios and significantly > complicate the NSIS protocol. Sorry, but I disagree here. It gives you much more flexibility, but I don't see how it complicates things significantly. IMO an NSIS solution should allow at least both solutions, either router-based (RSVP-like) or BB-based, and, personally I don't think this will complicate things that much. Regards, Roland >-----Original Message----- >From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] >Sent: vrijdag 10 mei 2002 15:30 >To: 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; >gkenward@nortelnetworks.com >Cc: nsis@ietf.org >Subject: RE: [NSIS] To BB or not to BB > > >John, > >I think as long as we agreed that the NSIS signaling path is allowed to >diverge from the data forwarding path everybody who cares about BBs would be >satisfied. > >Ilya _______________________________________________ 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 daemon@optimus.ietf.org Tue May 14 04:49:15 2002 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 EAA09656 for ; Tue, 14 May 2002 04:49:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18643 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 04:49:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18282; Tue, 14 May 2002 04:44:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18251 for ; Tue, 14 May 2002 04:44:32 -0400 (EDT) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09499 for ; Tue, 14 May 2002 04:44:18 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 177Xv4-00049Z-00; Tue, 14 May 2002 10:44:30 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 177Xv4-0006n3-00; Tue, 14 May 2002 10:44:30 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g4E8iT107708; Tue, 14 May 2002 10:44:29 +0200 Message-Id: <200205140844.g4E8iT107708@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Ping Pan cc: "Geib, Ruediger" , nsis@ietf.org Subject: Re: [NSIS] To BB or not to BB In-Reply-To: Message from Ping Pan of "Mon, 13 May 2002 01:20:55 PDT." <20020513010323.R38220-100000@garnet.juniper.net> References: <20020513010323.R38220-100000@garnet.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 14 May 2002 10:44:29 +0200 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Ping, see comments inline > > > Hence, could any *non-research* provider please please tell me if and > > > when they will deploy BB to their customers? > > > > Yes, there is interest in having QoS signaling > > architecture removing signaling support from > > routers. The charm of a BB like QoS resource > > administration is that it removes dependancies > > of carriers from router vendors - and will work > > with a heterogeneous router environment. BB's > > may be developed and changed independant from > > router operating systems. Of course this doesn't > > come for free. The BB must provide a management > > access to a router, which of course depends on > > router operating systems. > > > > After developed COPS multiple times in the past, my experience has been > that BB is to simply lift all the work from a distributed system (router > network) to a centralized system (BB network). Instead making things > simple, BB's will do the same amount of message processing, state > management etc. as the routers, but BB's will now have to somehow knowing > the entire network AND to sync up states with the routers. At the end, > BB's just make the whole thing more complex. I disagree here. BBs will take very much processing burden from routers which could instead fully concentrate on data path forwarding and processing routing protocol/management information. A logically centralized system has also a lot advantages and may even save signaling messages, too, e.g. by making resource-based and policy-based decisions at the same place. BBs can be also redundant SMP systems with scalable processing power to cope with all their tasks. > > I'm not sure what you mean by "deploying a BB > > to my customer". I guess a first step in > > supporting automated QoS resource negotiation > > will some kind of Web based access to a policy > > management system. > > It wouldn't change if a BB > > is introduced. Between domains, BB's may talk > > directly with each other. > > > > In some cases, like support of mobile wireless > > terminals, a hybrid solution may be best. > > Mobile signals to edge router, edge router > > signals to BB. > > This allows core routers to > > stay out of signaling business. Of course the > > argument of vendor independance gets lost. > > However the required signaling functionalities > > are still limited: simply forward message to > > the BB and forward replies to the mobile. > > > > Hoe about this: mobile devices create a session with some policy servers > for billing. The packets may go through routers, and the routers don't > have to do much about it. Only when the mobile devices want to get network > resource, it can ask the routers, and routers can signal the rest of the > network. In this case, routers don't have to care anything about BB or not > BB, and mobile devices can talk to the servers without worrying about if > routers will do something crazy to the packets. :-) > > > What I'd expect from NSIS on BB's is to allow > > for specifications of inter domain signaling > > specifications supporting a centralised QoS > > resource administration. > > What kind of inter-domain are you referring to? Please tell me how to run > centralised XYZ administration in the inter-domain enviornment in the > Internet? :-) :-) Surely not a centralized solution for the whole Internet. Maybe centralized within a single domain, but all domains negotiate on their own with their adjacent domains, thus an overall distributed architecture. [turning off BB political discussion, coming back to NSIS issues] I would expect an NSIS solution that works for both models router-based or BB-based. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 14 06:17:34 2002 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 GAA11747 for ; Tue, 14 May 2002 06:17:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA24797 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 06:17:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24491; Tue, 14 May 2002 06:13:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24390 for ; Tue, 14 May 2002 06:12:55 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11536 for ; Tue, 14 May 2002 06:12:42 -0400 (EDT) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4EACrs7005080 for ; Tue, 14 May 2002 12:12:53 +0200 (MEST) Received: from era.ericsson.se (rcur181ip162.ericsson.se [147.214.181.162]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0GW300GA1J1GTM@mbb1.ericsson.se> for nsis@ietf.org; Tue, 14 May 2002 12:12:53 +0200 (MET DST) Date: Tue, 14 May 2002 12:11:58 +0200 From: "Lars.Westberg" Subject: Re: [NSIS] To BB or not to BB To: "Schneider, Marco" Cc: "'Ping Pan'" , brunner@ccrle.nec.de, john.loughney@nokia.com, Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com, nsis@ietf.org Message-id: <3CE0E2EE.FA329830@era.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <905A1C4ABF353F4C8CC16FA9F53DD0D638BAD7@TRIMAIL2.ad.tri.sbc.com> Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi, Marco Could you explain more about your proxy-solution. I am not conviced that your proxy is the same as a bandwidth broker. - Lasse "Schneider, Marco" wrote: > Ping, > > I am not sure how you define a Bandwidth Broker. As I and one of my > colleagues at SBC have expressed to you on several occasions, we at SBC want > to enable our customers to signal for QOS flows across our network. If we > are successfull NSIS will become the common signaling protocol to do that > across all access methods. Because the timing does not fit our immediate > needs, we have proposed extensions to RSVP as a way to access ATM and MPLS > networks. In our architecture, customer initiated RSVP signaling will be > directed to an controller which proxy signals for a connection across our > network. It should come as no surprise that a number of other carriers share > an interest in this approach as a way to exploit their already deployed ATM > infrastructure. > > My 3 Cents, > > Marco > > > -----Original Message----- > > From: Ping Pan [mailto:pingpan@juniper.net] > > Sent: Friday, May 10, 2002 1:03 PM > > To: brunner@ccrle.nec.de > > Cc: john.loughney@nokia.com; Ruediger.Geib@t-systems.com; > > gkenward@nortelnetworks.com; nsis@ietf.org > > Subject: Re: [NSIS] To BB or not to BB > > > > > > Marcus, > > > > I think that IETF, especially NSIS, should not become a > > kitchen sink for > > all possible combinations of network architecture. We belong to an > > engineering community here, that is, we need to try our best > > to come up > > with some practical solutions for some practical problems. > > > > Hence, could any *non-research* provider please please tell me if and > > when they will deploy BB to their customers? If there is a > > real demand > > for BB, we should look into it in IETF (not sure within the scope of > > NSIS neither)? Otherwise, why not push the work to other > > places, such as > > IRTF? > > > > 2 cents, > > > > - Ping > > > > > > > > Marcus Brunner wrote: > > > > > I am sorry, but I could not refrain from asking what Internet > > > Architecture BB are not part of? > > > > > > Otherwise I agree with John, the reqs and framework should > > allow for > > > various QoS architectures (including BB kind of > > architectures), defined > > > by the IETF. > > > > > > Marcus > > > > > > --On Friday, May 10, 2002 11:25 AM +0300 > > john.loughney@nokia.com wrote: > > > > > >> Hi all, > > >> > > >> Just a general comment about Bandwidth Brokers and NSIS. Bandwidth > > >> Brokers (as the are commonly defined) are actually out of scope > > >> of NSIS. This means we are not defining a bandwidth broker > > >> architecture. There was quite a bit of discussion (at a highlevel) > > >> about this before NSIS was allowed to be chartered, and it was > > >> said to me that bandwidth brokers are not really thought of > > >> as part of the Internet architecture. > > >> > > >> However, I do know that there are many folks providing bandwidth > > >> broker solutions. My view is that a bandwidth broker comes > > >> dangerously close to how resources are provisioned, therefore > > >> are out of scope of NSIS. From the charter: > > >> > > >> It is noted that resource reservation and traffic > > engineering can be > > >> considered as part of network administration, and > > therefore beyond the > > >> scope of the IETF to mandate a particular mechanism. > > >> > > >> Additionally, some folks may wish to check on the TEWG > > >> (http://www.ietf.org/html.charters/tewg-charter.html) for work on > > >> traffic engineering. > > >> > > >> Finally, I do think it is perfectly acceptable to have a framework > > >> and/or solution that is friendly to bandwidth brokers, but I do not > > >> think that a bandwidth broker centric architecture or solution is > > >> what we should do. > > >> > > >> John > > >> > > >> > > >> _______________________________________________ > > >> 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/ > > > 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 > > > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue May 14 08:15:00 2002 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 IAA14913 for ; Tue, 14 May 2002 08:15:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03001 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 08:15:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02621; Tue, 14 May 2002 08:08:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02585 for ; Tue, 14 May 2002 08:08:13 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14644 for ; Tue, 14 May 2002 08:07:57 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4EC8Vk27680 for ; Tue, 14 May 2002 15:08:31 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 May 2002 15:08:07 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 14 May 2002 15:08:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 14 May 2002 15:08:06 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DE7@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] To BB or not to BB Thread-Index: AcH7L+6w1q/p+9idSJ6M/t3WfkO16AADyM3Q To: Cc: X-OriginalArrivalTime: 14 May 2002 12:08:07.0615 (UTC) FILETIME=[022E44F0:01C1FB40] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA02586 Subject: [NSIS] Scoping of BBs Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Lasse, > Could you explain more about your proxy-solution. I am not > conviced that your proxy is the same as a bandwidth broker. You make a good point. To provide some additional scoping, here are my thoughts: 1) entities involved in the reservation of resources are out of scope. 2) entities which relay signaling probably are not out of scope. 3) place holders for future work in signaling to & between resource reservation entities is probably in scope, the exact nature of the signaling is probably out of scope. 4) signaling to & from entities which 'proxy' qos is probably within scope. 5) signaling end-to-end is within scope 6) resource reservation end-to-end is not in scope. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 14 09:04:13 2002 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 JAA16957 for ; Tue, 14 May 2002 09:04:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06497 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 09:04:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05763; Tue, 14 May 2002 08:57:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05735 for ; Tue, 14 May 2002 08:57:20 -0400 (EDT) Received: from mail.alcatel.co.uk (mail.alcatel.co.uk [195.92.62.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16739 for ; Tue, 14 May 2002 08:57:07 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bt0g2p.god.bel.alcatel.be (relay01.net.alcatel.co.uk [127.0.0.1]) by mail.alcatel.co.uk (8.11.0/8.9.3) with ESMTP id g4ECvJQ15310; Tue, 14 May 2002 13:57:19 +0100 Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g4ECtHP30259; Tue, 14 May 2002 14:55:17 +0200 Subject: Re: [NSIS] Scoping of BBs To: john.loughney@nokia.com Cc: Lars.Westberg@era.ericsson.se, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 14 May 2002 14:57:12 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/14/2002 14:57:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org John, all, The fact that you decouple signaling from resource reservation seems to suggest the anticipated use of some sort of probing mechanism prior to connection setup. We were more thinking along the lines of hard-guaranteed QoS with per-flow admission control (also in the core), mandating the notion of resource reservation in the signaling protocol (much like in RSVP by the way). I agree that the actual way the reservation is carried out locally is out of scope, but I wouldn't like to exclude the notion from the protocol, nor exclude resource reservation entities to participate in it. Sven john.loughney@nokia.com on 14/05/2002 14:08:06 To: Lars.Westberg@era.ericsson.se cc: nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject [NSIS] Scoping of BBs : Hi Lasse, > Could you explain more about your proxy-solution. I am not > conviced that your proxy is the same as a bandwidth broker. You make a good point. To provide some additional scoping, here are my thoughts: 1) entities involved in the reservation of resources are out of scope. 2) entities which relay signaling probably are not out of scope. 3) place holders for future work in signaling to & between resource reservation entities is probably in scope, the exact nature of the signaling is probably out of scope. 4) signaling to & from entities which 'proxy' qos is probably within scope. 5) signaling end-to-end is within scope 6) resource reservation end-to-end is not in scope. 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 daemon@optimus.ietf.org Tue May 14 09:58:21 2002 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 JAA19594 for ; Tue, 14 May 2002 09:58:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10710 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 09:58:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10312; Tue, 14 May 2002 09:52:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10280 for ; Tue, 14 May 2002 09:52:03 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19229 for ; Tue, 14 May 2002 09:51:49 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 09:46:36 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93149@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'john.loughney@nokia.com'" , Lars.Westberg@era.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Scoping of BBs Date: Tue, 14 May 2002 09:46:27 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org John, 3) place holders for future work in signaling to & between resource reservation entities is probably in scope, the exact nature of the signaling is probably out of scope. Could you make it clearer what do you mean by "exact nature of the signaling"? I my mind the "signaling to & between resource reservation entities" IS one of the main objectives of this working group. I think you would agree that in RSVP-like model the routers ARE "resource reservation entities". Are you saying that we need only placeholders for the future work on signaling between routers? I hope not. If you mean that exact nature of the signaling is service specific I would agree with you. Ilya _______________________________________________ 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 daemon@ns.ietf.org Tue May 14 11:00:22 2002 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 LAA22322 for ; Tue, 14 May 2002 11:00:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15425 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 11:00:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14803; Tue, 14 May 2002 10:49:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14772 for ; Tue, 14 May 2002 10:49:33 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21918 for ; Tue, 14 May 2002 10:49:17 -0400 (EDT) Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 14 May 2002 16:47:53 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 16:48:59 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Scoping of BBs Date: Tue, 14 May 2002 16:48: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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA14773 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John, So IntServ/RSVP is out of scope as every router processing these messages reserves resources. Ilya made that point earlier and I'd interpret your statement the same way. > 1) entities involved in the reservation of resources are > out of scope. My expectation of NSIS is that it specifies the interfaces and signaling mechanisms to set up, maintain and remove service reservations of any kind. Done by any units providing service management. NSIS does not specify these services nor does NSIS specify how these reservations are translated into router configurations. Would that approximately describe what NSIS is about? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue May 14 14:41:49 2002 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 OAA29937 for ; Tue, 14 May 2002 14:41:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09988 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 14:42:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09614; Tue, 14 May 2002 14:33:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09585 for ; Tue, 14 May 2002 14:33:45 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29583 for ; Tue, 14 May 2002 14:33:31 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4EIYxd04210 for ; Tue, 14 May 2002 21:35:03 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 May 2002 21:33:36 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 14 May 2002 21:33:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Scoping of BBs Date: Tue, 14 May 2002 21:33:36 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6513E@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Scoping of BBs Thread-Index: AcH7XTHj/Zrp3+joQDysKYy8Vgk7rAAGITMQ To: , Cc: X-OriginalArrivalTime: 14 May 2002 18:33:37.0181 (UTC) FILETIME=[DC79F4D0:01C1FB75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA09586 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > I do not think that the entities involved in the reservation of > resources are out of NSIS scope, but the standardization of the > functionality that provides resource reservation, which is > included in such entities is out of NSIS scope!! I think we want to be care not to over-engineer any new entities in this. Of course, we will need to discuss some basic entities, but beyond that is probably out of scope. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue May 14 14:41:51 2002 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 OAA29928 for ; Tue, 14 May 2002 14:41:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09971 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 14:41:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09535; Tue, 14 May 2002 14:32:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09502 for ; Tue, 14 May 2002 14:32:25 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29537 for ; Tue, 14 May 2002 14:32:08 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4EIWck10362 for ; Tue, 14 May 2002 21:32:39 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 May 2002 21:32:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 14 May 2002 21:32:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Scoping of BBs Date: Tue, 14 May 2002 21:32:15 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6513D@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Scoping of BBs Thread-Index: AcH7Vn0o1Mc2YH/6QXqfD7fdqBobagAHsw8Q To: Cc: X-OriginalArrivalTime: 14 May 2002 18:32:16.0296 (UTC) FILETIME=[AC43E280:01C1FB75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA09503 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger, > So IntServ/RSVP is out of scope as every router > processing these messages reserves resources. > Ilya made that point earlier and I'd interpret > your statement the same way. I think so. RSVP, with IntServ removed is probably applicable. That is why it has been suggested we look at "Specification of the Null Service Type - RFC 2997" "A Framework For IntServ Operation Over Diffserv Networks - RFC 2998" > > 1) entities involved in the reservation of resources are > > out of scope. > > My expectation of NSIS is that it specifies the interfaces > and signaling mechanisms to set up, maintain and remove > service reservations of any kind. Done by any units > providing service management. > > NSIS does not specify these services nor does > NSIS specify how these reservations are translated into > router configurations. > > Would that approximately describe what NSIS is about? My personal (non-chair) opinion, would be that if we could do the above in a reasonable time period, we would have some interesting tools to do interesting things. Additionally, we would have fairly fertile ground to recharter or start an other WG. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue May 14 15:11:08 2002 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 PAA01337 for ; Tue, 14 May 2002 15:11:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12519 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 15:11:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25014; Tue, 14 May 2002 06:19:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24982 for ; Tue, 14 May 2002 06:18:59 -0400 (EDT) Received: from shadow.inria.fr (root@shadow.inria.fr [138.96.24.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11823 for ; Tue, 14 May 2002 06:18:45 -0400 (EDT) Received: from sophia.inria.fr by shadow.inria.fr (8.11.6/8.10.0) with ESMTP id g4EAIu910160 for ; Tue, 14 May 2002 12:18:56 +0200 (MET DST) X-Authentication-Warning: shadow.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr Message-ID: <3CE0E490.FA1ED9B8@sophia.inria.fr> Date: Tue, 14 May 2002 12:18:56 +0200 From: Rares Serban X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: nsis@ietf.org X-Priority: 1 (Highest) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Internet QoS Signaling Protocols Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi all, May be this paper will be helpfull for WG! http://www-sop.inria.fr/planete/Rares.Serban/Files/Communications2000.pdf Thank you, R. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue May 14 15:18:21 2002 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 PAA01637 for ; Tue, 14 May 2002 15:18:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12903 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 15:18:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01868; Tue, 14 May 2002 08:01:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01818 for ; Tue, 14 May 2002 08:01:42 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14316 for ; Tue, 14 May 2002 08:01:28 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4EC0WY22392 for ; Tue, 14 May 2002 15:00:33 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 May 2002 15:01:38 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 14 May 2002 15:01:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] To BB or not to BB Date: Tue, 14 May 2002 15:01:11 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6512B@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] To BB or not to BB Thread-Index: AcH7H93DUM5zRsyBTuaPCCJTnHXX8QAHq+bw To: Cc: X-OriginalArrivalTime: 14 May 2002 12:01:11.0596 (UTC) FILETIME=[0A36CEC0:01C1FB3F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA01819 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, > Sorry, but I disagree here. It gives you much more > flexibility, but I don't see how it complicates things > significantly. IMO an NSIS solution should allow at > least both solutions, either router-based (RSVP-like) > or BB-based, and, personally I don't think this will > complicate things that much. Complications are: security (we are developing for an open Internet) - 3rd parties involvment in any signaling is a known security hole. Discovery mechanisms (how do I discover the BB in my home network, my visited network, do I need to discover your BB if I am calling you .... Scalability - to what extent does this scale? Can we put a metric on it? Is it per domain, sub-domain, per link ..? I am very happy to see additional literature on this, I know that some of this will work in closed networks, but I don't know enough of how it works in an open network. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue May 14 15:19:43 2002 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 PAA01697 for ; Tue, 14 May 2002 15:19:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13004 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 15:19:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10699; Tue, 14 May 2002 09:58:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10653 for ; Tue, 14 May 2002 09:58:16 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19534 for ; Tue, 14 May 2002 09:57:57 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4EDwVk17529 for ; Tue, 14 May 2002 16:58:31 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 May 2002 16:58:09 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 14 May 2002 16:58:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Scoping of BBs Date: Tue, 14 May 2002 16:58:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65134@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Scoping of BBs Thread-Index: AcH7TGgY4F1+x7+eTEayKd1Sr2cPOgAAqP2w To: Cc: X-OriginalArrivalTime: 14 May 2002 13:58:08.0881 (UTC) FILETIME=[60D78610:01C1FB4F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA10654 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > One of the issues that we could discuss in Helsinki is: > Can one NSIS protocol fulfill all the requirements that we > have stated? > > In my opinion not! > Maybe it will be better to discuss the possibility of having > more than one protocols? I will tell you that we are only chartered to work on a (singular) protocol. To do more will require rechartering. Rechartering will be difficult. It may be that we need to leave some work for later. For example, we define requirements and a framework and choose a specific part of the framework to start protocol work. After that is completed, we can then seek to recharter or start a new working group. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue May 14 15:24:52 2002 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 PAA02015 for ; Tue, 14 May 2002 15:24:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13721 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 15:25:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16009; Tue, 14 May 2002 11:04:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15951 for ; Tue, 14 May 2002 11:04:16 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22521 for ; Tue, 14 May 2002 11:04:00 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4EF4D0E029522 for ; Tue, 14 May 2002 17:04:13 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Tue May 14 17:00:41 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <228165GZ>; Tue, 14 May 2002 17:03:34 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Geib, Ruediger'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Scoping of BBs Date: Tue, 14 May 2002 17:03:35 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA15970 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi I do not think that the entities involved in the reservation of resources are out of NSIS scope, but the standardization of the functionality that provides resource reservation, which is included in such entities is out of NSIS scope!! Best regards, Georgios -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: dinsdag 14 mei 2002 16:49 To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Scoping of BBs Hi John, So IntServ/RSVP is out of scope as every router processing these messages reserves resources. Ilya made that point earlier and I'd interpret your statement the same way. > 1) entities involved in the reservation of resources are > out of scope. My expectation of NSIS is that it specifies the interfaces and signaling mechanisms to set up, maintain and remove service reservations of any kind. Done by any units providing service management. NSIS does not specify these services nor does NSIS specify how these reservations are translated into router configurations. Would that approximately describe what NSIS is about? Regards, Rüdiger _______________________________________________ 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 daemon@ns.ietf.org Tue May 14 15:32:17 2002 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 PAA02357 for ; Tue, 14 May 2002 15:32:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14702 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 15:32:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09262; Tue, 14 May 2002 09:36:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09223 for ; Tue, 14 May 2002 09:36:51 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18444 for ; Tue, 14 May 2002 09:36:37 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4EDan0E008049 for ; Tue, 14 May 2002 15:36:49 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue May 14 15:36:27 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22816ZH4>; Tue, 14 May 2002 15:35:37 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'sven.van_den_bosch@alcatel.be'" , john.loughney@nokia.com Cc: "Lars Westberg (ERA)" , nsis@ietf.org Subject: RE: [NSIS] Scoping of BBs Date: Tue, 14 May 2002 15:36:18 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi I also agree with Sven. One of the issues that we could discuss in Helsinki is: Can one NSIS protocol fulfill all the requirements that we have stated? In my opinion not! Maybe it will be better to discuss the possibility of having more than one protocols? Best regards, Georgios -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: dinsdag 14 mei 2002 14:57 To: john.loughney@nokia.com Cc: Lars.Westberg@era.ericsson.se; nsis@ietf.org Subject: Re: [NSIS] Scoping of BBs John, all, The fact that you decouple signaling from resource reservation seems to suggest the anticipated use of some sort of probing mechanism prior to connection setup. We were more thinking along the lines of hard-guaranteed QoS with per-flow admission control (also in the core), mandating the notion of resource reservation in the signaling protocol (much like in RSVP by the way). I agree that the actual way the reservation is carried out locally is out of scope, but I wouldn't like to exclude the notion from the protocol, nor exclude resource reservation entities to participate in it. Sven john.loughney@nokia.com on 14/05/2002 14:08:06 To: Lars.Westberg@era.ericsson.se cc: nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject [NSIS] Scoping of BBs : Hi Lasse, > Could you explain more about your proxy-solution. I am not > conviced that your proxy is the same as a bandwidth broker. You make a good point. To provide some additional scoping, here are my thoughts: 1) entities involved in the reservation of resources are out of scope. 2) entities which relay signaling probably are not out of scope. 3) place holders for future work in signaling to & between resource reservation entities is probably in scope, the exact nature of the signaling is probably out of scope. 4) signaling to & from entities which 'proxy' qos is probably within scope. 5) signaling end-to-end is within scope 6) resource reservation end-to-end is not in scope. 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue May 14 15:34:10 2002 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 PAA02403 for ; Tue, 14 May 2002 15:34:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14886 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 15:34:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10554; Tue, 14 May 2002 09:55:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10517 for ; Tue, 14 May 2002 09:55:45 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19408 for ; Tue, 14 May 2002 09:55:23 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4EDuld13972 for ; Tue, 14 May 2002 16:56:48 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 May 2002 16:55:25 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 14 May 2002 16:55:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Scoping of BBs Date: Tue, 14 May 2002 16:55:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65133@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Scoping of BBs Thread-Index: AcH7Tow3ia5XHVmCTUuGxUBjsYGuAgAAA9Mg To: Cc: X-OriginalArrivalTime: 14 May 2002 13:55:25.0169 (UTC) FILETIME=[FF430E10:01C1FB4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA10520 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Ilya, > 3) place holders for future work in signaling to & between > resource reservation entities is probably in scope, the > exact nature of the signaling is probably out of scope. > > > Could you make it clearer what do you mean by "exact nature of the > signaling"? > I my mind the "signaling to & between resource reservation > entities" IS one > of the main objectives of this working group. I think you > would agree that > in RSVP-like model the routers ARE "resource reservation > entities". Are you > saying that we need only placeholders for the future work on signaling > between routers? I hope not. > If you mean that exact nature of the signaling is service specific I would > agree with you. NSIS cannot do everything ... when we consider that there may be specific needs for specific types of resource reservation, we may need some sort of 'mapping.' This is currently not in our charter, but we could put place holders so that we could recharter or start another working group on subject. For example, signaling needed between resource reservation entities for simple over-provisioned network domains is different than what is needed for IntServ domains. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue May 14 15:39:57 2002 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 PAA02643 for ; Tue, 14 May 2002 15:39:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15212 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 15:40:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17696; Tue, 14 May 2002 04:36:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17664 for ; Tue, 14 May 2002 04:36:22 -0400 (EDT) Received: from mail.alcatel.co.uk (mail.alcatel.co.uk [195.92.62.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09266 for ; Tue, 14 May 2002 04:36:08 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bt0g2p.god.bel.alcatel.be (relay01.net.alcatel.co.uk [127.0.0.1]) by mail.alcatel.co.uk (8.11.0/8.9.3) with ESMTP id g4E8aKM03355; Tue, 14 May 2002 09:36:20 +0100 Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g4E8YI711845; Tue, 14 May 2002 10:34:18 +0200 Subject: RE: [NSIS] To BB or not to BB To: "Georgios Karagiannis (ELN)" Cc: "'Roland Bless'" , "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 14 May 2002 10:36:16 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/14/2002 10:36:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, Roland, Leaving aside the application of the bandwidth broker, I think it is essential that the nsis protocol be applicable for out-of-band signaling (so directed to entities that are not necessarily on the data path). BB is a potential application, so is proxy signaling. Anyway, I look forward to the discussion on this in Helsinki. CU, Sven. "Georgios Karagiannis (ELN)" on 14/05/2002 10:25:53 To: "'Roland Bless'" cc: "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com, nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] To BB or not to BB : Hi I think it will be very good if we will extensively discuss these issues in Helsinki (at interim meeting). Best Regards, Georgios -----Original Message----- From: Roland Bless [mailto:bless@tm.uka.de] Sent: dinsdag 14 mei 2002 10:18 To: Georgios Karagiannis (ELN) Cc: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com; nsis@ietf.org Subject: Re: [NSIS] To BB or not to BB Hi Georgios, > This is one of the requirements that are mainly related > to bandwidth brokering scenarios and significantly > complicate the NSIS protocol. Sorry, but I disagree here. It gives you much more flexibility, but I don't see how it complicates things significantly. IMO an NSIS solution should allow at least both solutions, either router-based (RSVP-like) or BB-based, and, personally I don't think this will complicate things that much. Regards, Roland >-----Original Message----- >From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] >Sent: vrijdag 10 mei 2002 15:30 >To: 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; >gkenward@nortelnetworks.com >Cc: nsis@ietf.org >Subject: RE: [NSIS] To BB or not to BB > > >John, > >I think as long as we agreed that the NSIS signaling path is allowed to >diverge from the data forwarding path everybody who cares about BBs would be >satisfied. > >Ilya _______________________________________________ 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 daemon@ns.ietf.org Tue May 14 15:44:16 2002 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 PAA02911 for ; Tue, 14 May 2002 15:44:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15538 for nsis-archive@odin.ietf.org; Tue, 14 May 2002 15:44:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13344; Tue, 14 May 2002 10:31:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13305 for ; Tue, 14 May 2002 10:31:19 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21184 for ; Tue, 14 May 2002 10:31:05 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EEUfG03954; Tue, 14 May 2002 10:30:41 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 10:30:50 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4AC4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Scoping of BBs Date: Tue, 14 May 2002 10:31:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FB53.FF3CFC6E" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1FB53.FF3CFC6E Content-Type: text/plain; charset="iso-8859-1" John: I am somewhat confused by this problem description. NSIS is concerned with QoS signalling, correct? QoS in the internet almost always includes bandwidth, correct? So how does one signal QoS without being involved with bandwidth allocation? What does "involved" mean? Does NSIS provide the mechanisms to signal a router to allocate Q Mbps of bandwidth for flow xzy? Well, ok, perhaps not, but if NSIS is not telling the entity that performs this function to initiate the provisioning of Q Mbps, then what exactly is it doing? Ferrying DSCP's about? If NSIS ends up using RSVP, do we drop bandwidth from the TSpec and RSpec, or the other parameters, for they are used for provisioning? I am very concerned that the NSIS charter has defined a problem space wedged between session establishment and bearer path provisioning. A solution for this problem space is definitely required, but it must be questioned that yet another protocol solution is warranted. One has to wonder just how many protocols/entities are really necessary to establish end-to-end QoS, and just what the quality of this distributed, loosely coupled, multi-phasic solution will be? More important, will this solution really provide a viable alternative to the L2 centric solutions being worked on in other (notably wireless, but also PacketCable) SDOs (yes, I understand that these solutions do not address the end-to-end problem completely, but they are efficient solutions for the particular access network). Sorry if this seems like charter bashing: consider it a request for clarification. I would ask it at the interim, but I cannot be there. Cheers, Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: May 14, 2002 08:08 > To: Lars.Westberg@era.ericsson.se > Cc: nsis@ietf.org > Subject: [NSIS] Scoping of BBs > > > Hi Lasse, > > > Could you explain more about your proxy-solution. I am not > > conviced that your proxy is the same as a bandwidth broker. > > You make a good point. To provide some additional scoping, > here are my thoughts: > > 1) entities involved in the reservation of resources are > out of scope. > > 2) entities which relay signaling probably are not out of scope. > > 3) place holders for future work in signaling to & between > resource reservation entities is probably in scope, the > exact nature of the signaling is probably out of scope. > > 4) signaling to & from entities which 'proxy' qos is probably > within scope. > > 5) signaling end-to-end is within scope > > 6) resource reservation end-to-end is not in scope. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1FB53.FF3CFC6E Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] Scoping of BBs

John:

I am somewhat confused by this problem description. NSIS is
concerned with QoS signalling, correct? QoS in the internet almost
always includes bandwidth, correct? So how does one signal QoS without
being involved with bandwidth allocation? What does "involved" mean?

Does NSIS provide the mechanisms to signal a router to allocate Q Mbps
of bandwidth for flow xzy? Well, ok, perhaps not, but if NSIS is not
telling the entity that performs this function to initiate the provisioning
of Q Mbps, then what exactly is it doing? Ferrying DSCP's about? If NSIS
ends up using RSVP, do we drop bandwidth from the TSpec and RSpec, or the
other parameters, for they are used for provisioning?

I am very concerned that the NSIS charter has defined a problem space
wedged between session establishment and bearer path provisioning. A
solution for this problem space is definitely required, but it must be questioned
that yet another protocol solution is warranted. One has to wonder just how many
protocols/entities are really necessary to establish end-to-end QoS, and just
what the quality of this distributed, loosely coupled, multi-phasic solution will be?
More important, will this solution really provide a viable alternative to the L2
centric solutions being worked on in other (notably wireless, but also PacketCable)
SDOs (yes, I understand that these solutions do not address the end-to-end problem
completely, but they are efficient solutions for the particular access network).

Sorry if this seems like charter bashing: consider it a request for clarification.
I would ask it at the interim, but I cannot be there.

Cheers,
Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: May 14, 2002 08:08
> To: Lars.Westberg@era.ericsson.se
> Cc: nsis@ietf.org
> Subject: [NSIS] Scoping of BBs
>
>
> Hi Lasse,
>
> > Could you explain more about your proxy-solution. I am not
> > conviced that your proxy is the same as a bandwidth broker.
>
> You make a good point.  To provide some additional scoping,
> here are my thoughts:
>
> 1) entities involved in the reservation of resources are
>    out of scope.
>
> 2) entities which relay signaling probably are not out of scope.
>
> 3) place holders for future work in signaling to & between 
>    resource reservation entities is probably in scope, the
>    exact nature of the signaling is probably out of scope.
>
> 4) signaling to & from entities which 'proxy' qos is probably
>    within scope.
>
> 5) signaling end-to-end is within scope
>
> 6) resource reservation end-to-end is not in scope.
>
> John
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1FB53.FF3CFC6E-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed May 15 06:17:15 2002 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 GAA24033 for ; Wed, 15 May 2002 06:17:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA03361 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 06:17:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03152; Wed, 15 May 2002 06:12:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28802 for ; Wed, 15 May 2002 04:59:40 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22252 for ; Wed, 15 May 2002 04:59:23 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4F8xGk00921 for ; Wed, 15 May 2002 11:59:58 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 11:58:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 11:58:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Scoping of BBs Date: Wed, 15 May 2002 11:58:52 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DFA@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Scoping of BBs Thread-Index: AcH7Ruvb+1moVydMRJW0bhjQUzRtrAApsG+A To: Cc: , X-OriginalArrivalTime: 15 May 2002 08:58:53.0356 (UTC) FILETIME=[BCED96C0:01C1FBEE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA28805 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sven, > The fact that you decouple signaling from resource reservation seems to > suggest the anticipated use of some sort of probing mechanism prior to > connection setup. Why do you say that? Cannot the probe be the actual request? > We were more thinking along the lines of hard-guaranteed > QoS with per-flow admission control (also in the core), mandating the > notion of resource reservation in the signaling protocol (much like in RSVP > by the way). I agree that the actual way the reservation is carried out > locally is out of scope, but I wouldn't like to exclude the notion from the > protocol, nor exclude resource reservation entities to > participate in it. I wonder if we need hard-guaranteed-QoS with per-flow admission control in all cases. I definately think that this is a service, but I am not sure if it is the default. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed May 15 06:17:16 2002 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 GAA24047 for ; Wed, 15 May 2002 06:17:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA03372 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 06:17:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03079; Wed, 15 May 2002 06:12:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28435 for ; Wed, 15 May 2002 04:48:23 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22136 for ; Wed, 15 May 2002 04:48:07 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4F8mgk20305 for ; Wed, 15 May 2002 11:48:42 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 11:48:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 11:48:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] To BB or not to BB Date: Wed, 15 May 2002 11:48:17 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DF9@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] To BB or not to BB Thread-Index: AcH766OACqGAlZWLTo+INifGjnMWPAAAEtmg To: , Cc: X-OriginalArrivalTime: 15 May 2002 08:48:19.0864 (UTC) FILETIME=[43566180:01C1FBED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA28436 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger, > I don't know what your perception of a BB is. Mine is that > there's one per QoS domain, controlled by the operator > running the domain. There's no difference in per router > security requirements and BB security requirements if you > look at the single element. The number of routers involved > into signaling is higher and each has to as robust against > an attack as the few centralised BBs have to be. There is no 'bandwidth broker' term in the IETF lexicon, a quick RFC search turned up no references. I think this is part of the problem. Generally, the IETF has been allergic to centralized approaches, as this introduces single points of failures, etc. Anyhow, I have yet to see a clear, crisp definition of bandwidth broker, so I very hesitant in accepting it into NSIS. > > Discovery mechanisms (how > > do I discover the BB in my home network, my visited > > network, do I need to discover your BB if I am calling > > you .... > > As difficult to solve as AAA. Not really, I think the current AAA architecture is not so bad. > > Scalability - to what extent does this scale? > > Can we put a metric on it? Is it per domain, sub-domain, > > per link ..? > > Or per router, maybe even integrated into a router? If you'd > like to see more literatutre on the scalability of centralised > admission control, could you provide a couple of references > examining the scalability IntDiff? Noone is promoting Integrated Services over DiffServ networks as a solution to NSIS, as this work as already been done. Whether or not anyone uses it, is not an issue for us. I think we need to work on a more general approach, because we cannot ensure that all networks deploy DiffServ. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed May 15 06:18:01 2002 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 GAA24080 for ; Wed, 15 May 2002 06:18:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA03397 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 06:18:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03163; Wed, 15 May 2002 06:12:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01080 for ; Wed, 15 May 2002 05:36:22 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22830 for ; Wed, 15 May 2002 05:36:07 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 15 May 2002 11:34:43 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 11:35:49 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Date: Wed, 15 May 2002 11:35:49 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA01081 Subject: [NSIS] RE: What's in the charter of NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John > RFC 2998 discusses "Integrated Services Over Diffserv Networks." > Some folks (meaning area directors & IESG folks) have thought > that a more general solution is needed, meaning that 2998 is > a specific implementation of the general solution. And the fog started to lift... > Furthermore, maybe someone does not want IntServ exactly, > but perhaps a certain characteristic of IntServ, say > bandwidth. What happens to the remainder of IntServ in that case? Would one have to signal empty parameters? No answer required if this will be discussed in Helsinki! > Then you could have > > Bandwidth Assurance over IntServ Networks > Bandwidth Assurance over MPLS Networks > Bandwidth Assurance over Over Provisioned Networks > Bandwidth Assurance over a Bandwidth Broker Network That BB definition issue must be settled. The "friends of BB" could provide an architecture outline by now, if they are not charged of entering the solution discussion. It would be helpful to have such a document (and I see by your other message that you aggree). Your above example in my words would be: BW Assurancee over MPLS using a BB BW Assurance over Over Provisoned Networks using a BB or in general: BW Assurance over a network using a BB BB's of separated domains may signal with each other without bothering which layers/technologies are supported by the domain in which each operates. This solves the problem you've mentioned below (with regard to signaling): > Finally, what do you do when one party of a call/session has > one 'kind' of network and the other party has a different > 'kind'? You could do a hop-by-hop approach, at each > hop modifying or translating the necessary parameters, > but this gets ugly fast and may not work. Perhaps it is > better to have a general solution, then work later on > how the general solution can be mapped down to a specific > network or resource reservation mechanism. Regards, Rüdiger PS: My basic BB perception may be found in http://qbone.internet2.edu/bb/bboutline2.html That's work without progress. It's more than 10 pages. If anybody has got time and doesn't mind an 80% perfect document, he/she may like it. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 08:44:51 2002 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 IAA00339 for ; Wed, 15 May 2002 08:44:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA12499 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 08:45:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11080; Wed, 15 May 2002 08:41:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02033 for ; Wed, 15 May 2002 05:51:52 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23205 for ; Wed, 15 May 2002 05:51:36 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA15637; Wed, 15 May 2002 11:51:40 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA15136; Wed, 15 May 2002 11:51:42 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 11:51:42 +0200 Message-ID: <4D486782CA36D4118A530000D11EA42A012657B3@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'sven.van_den_bosch@alcatel.be'" , "Georgios Karagiannis (ELN)" Cc: "'Roland Bless'" , "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, gkenward@nortelnetworks.com, nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Wed, 15 May 2002 11:51:39 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Note that out-of-band signaling is also an issue when QoS Routing is employed. I.e. when the signaling packets are not identified the same way as the data packets they are signaling for (e.g. different DSCP, addresses etc) they might be routed differently and we have out-of-band signaling anyways. Cornelia > -----Original Message----- > From: sven.van_den_bosch@alcatel.be [SMTP:sven.van_den_bosch@alcatel.be] > Sent: Tuesday, May 14, 2002 10:36 AM > To: Georgios Karagiannis (ELN) > Cc: 'Roland Bless'; 'Freytsis, Ilya'; 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com; nsis@ietf.org > Subject: RE: [NSIS] To BB or not to BB > > Hi Georgios, Roland, > > Leaving aside the application of the bandwidth broker, I think it is > essential that the nsis protocol be applicable for out-of-band signaling > (so directed to entities that are not necessarily on the data path). BB is > a potential application, so is proxy signaling. Anyway, I look forward to > the discussion on this in Helsinki. > > CU, > Sven. > > > > > > "Georgios Karagiannis (ELN)" on > 14/05/2002 10:25:53 > > > > To: "'Roland Bless'" > > cc: "'Freytsis, Ilya'" , > "'john.loughney@nokia.com'" > , > Ruediger.Geib@t-systems.com, > gkenward@nortelnetworks.com, > nsis@ietf.org(bcc: Sven VAN DEN > BOSCH/BE/ALCATEL) > > > > Subject RE: [NSIS] To BB or not to BB > : > > > > > > > Hi > > I think it will be very good if we will extensively discuss > these issues in Helsinki (at interim meeting). > > Best Regards, > Georgios > > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: dinsdag 14 mei 2002 10:18 > To: Georgios Karagiannis (ELN) > Cc: 'Freytsis, Ilya'; 'john.loughney@nokia.com'; > Ruediger.Geib@t-systems.com; gkenward@nortelnetworks.com; nsis@ietf.org > Subject: Re: [NSIS] To BB or not to BB > > > Hi Georgios, > > > This is one of the requirements that are mainly related > > to bandwidth brokering scenarios and significantly > > complicate the NSIS protocol. > > Sorry, but I disagree here. It gives you much more > flexibility, but I don't see how it complicates things > significantly. IMO an NSIS solution should allow at > least both solutions, either router-based (RSVP-like) > or BB-based, and, personally I don't think this will > complicate things that much. > > Regards, > Roland > > >-----Original Message----- > >From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > >Sent: vrijdag 10 mei 2002 15:30 > >To: 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; > >gkenward@nortelnetworks.com > >Cc: nsis@ietf.org > >Subject: RE: [NSIS] To BB or not to BB > > > > > >John, > > > >I think as long as we agreed that the NSIS signaling path is allowed to > >diverge from the data forwarding path everybody who cares about BBs would > be > >satisfied. > > > >Ilya > > > > _______________________________________________ > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 08:59:39 2002 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 IAA01270 for ; Wed, 15 May 2002 08:59:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA14474 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 08:59:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01571; Wed, 15 May 2002 05:41:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26951 for ; Wed, 15 May 2002 04:27:31 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21696 for ; Wed, 15 May 2002 04:27:16 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4F8RWk03657 for ; Wed, 15 May 2002 11:27:50 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 11:27:10 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 11:27:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Scoping of BBs Date: Wed, 15 May 2002 11:27:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6514E@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Scoping of BBs Thread-Index: AcH76gZW1ohe98yPSjqep54f/9teIwAADbfA To: Cc: X-OriginalArrivalTime: 15 May 2002 08:27:10.0147 (UTC) FILETIME=[4E86F130:01C1FBEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA26952 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > As entities I am referring to (Layer 3) Routers. Then we are probably in agreement that this is something that NSIS will discuss. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:00:11 2002 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 JAA01322 for ; Wed, 15 May 2002 09:00:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14625 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:00:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01527; Wed, 15 May 2002 05:41:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26788 for ; Wed, 15 May 2002 04:24:56 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21637 for ; Wed, 15 May 2002 04:24:41 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4F8Oss7006602 for ; Wed, 15 May 2002 10:24:54 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 15 10:24:53 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 10:24:53 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] Scoping of BBs Date: Wed, 15 May 2002 10:24:21 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John As entities I am referring to (Layer 3) Routers. Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: dinsdag 14 mei 2002 20:34 To: Georgios.Karagiannis@eln.ericsson.se; Ruediger.Geib@t-systems.com Cc: nsis@ietf.org Subject: RE: [NSIS] Scoping of BBs Hi Georgios, > I do not think that the entities involved in the reservation of > resources are out of NSIS scope, but the standardization of the > functionality that provides resource reservation, which is > included in such entities is out of NSIS scope!! I think we want to be care not to over-engineer any new entities in this. Of course, we will need to discuss some basic entities, but beyond that is probably out of scope. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:00:20 2002 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 JAA01344 for ; Wed, 15 May 2002 09:00:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14646 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:00:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01468; Wed, 15 May 2002 05:41:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25566 for ; Wed, 15 May 2002 04:01:54 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21261 for ; Wed, 15 May 2002 04:01:40 -0400 (EDT) Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 15 May 2002 10:00:10 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 10:01:16 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Date: Wed, 15 May 2002 10:00:33 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA25567 Subject: [NSIS] What's in the charter of NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John > I think so. RSVP, with IntServ removed is probably > applicable. That is why it has been suggested we look at > > "Specification of the Null Service Type - RFC 2997" > > "A Framework For IntServ Operation Over Diffserv Networks - RFC 2998" I guess this latter one is the true charter of NSIS. This RFC 2998 mentions "admission control" only 39 times, "resource" pops up 77 times, "reservation/dynamic/policing/shaping/provisioning/mapping" together contribute another 75 hits. Only fools could believe that RFC 2998 is related to entities involved in the reservation of resources. > > > 1) entities involved in the reservation of resources are > > > out of scope. > My personal (non-chair) opinion, would be that if we could > do the above in a reasonable time period, we would have > some interesting tools to do interesting things. Yes. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:04:27 2002 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 JAA01581 for ; Wed, 15 May 2002 09:04:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15537 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:04:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11204; Wed, 15 May 2002 08:41:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02202 for ; Wed, 15 May 2002 05:59:07 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23398 for ; Wed, 15 May 2002 05:58:51 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4F9xNk24763 for ; Wed, 15 May 2002 12:59:23 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 12:59:01 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 12:59:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] To BB or not to BB Date: Wed, 15 May 2002 12:59:00 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65156@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] To BB or not to BB Thread-Index: AcH79pSXuk+dsK79QbCnVsP+zlq/GQAAHW9g To: Cc: X-OriginalArrivalTime: 15 May 2002 09:59:00.0903 (UTC) FILETIME=[23319370:01C1FBF7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA02203 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Cornelia & Sven, > Note that out-of-band signaling is also an issue when QoS > Routing is employed. > > I.e. when the signaling packets are not identified the same > way as the data packets they are signaling for (e.g. > different DSCP, addresses etc) they might be routed > differently and we have out-of-band signaling anyways. I think a reasonable requirement for NSIS is to support out of band signaling. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:05:45 2002 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 JAA01666 for ; Wed, 15 May 2002 09:05:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15662 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:05:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01472; Wed, 15 May 2002 05:41:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26352 for ; Wed, 15 May 2002 04:15:32 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21441 for ; Wed, 15 May 2002 04:15:18 -0400 (EDT) Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 15 May 2002 10:13:53 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 10:14:58 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com, bless@tm.uka.de Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Wed, 15 May 2002 10:14:57 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA26353 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John > Complications are: security (we are developing for an > open Internet) - 3rd parties involvment in any signaling > is a known security hole. I don't know what your perception of a BB is. Mine is that there's one per QoS domain, controlled by the operator running the domain. There's no difference in per router security requirements and BB security requirements if you look at the single element. The number of routers involved into signaling is higher and each has to as robust against an attack as the few centralised BBs have to be. > Discovery mechanisms (how > do I discover the BB in my home network, my visited > network, do I need to discover your BB if I am calling > you .... As difficult to solve as AAA. > Scalability - to what extent does this scale? > Can we put a metric on it? Is it per domain, sub-domain, > per link ..? Or per router, maybe even integrated into a router? If you'd like to see more literatutre on the scalability of centralised admission control, could you provide a couple of references examining the scalability IntDiff? I'm not sure whether the problem we discuss is of technical nature. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:07:36 2002 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 JAA01792 for ; Wed, 15 May 2002 09:07:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15789 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:07:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11530; Wed, 15 May 2002 08:41:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03483 for ; Wed, 15 May 2002 06:22:36 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24205 for ; Wed, 15 May 2002 06:22:22 -0400 (EDT) Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 15 May 2002 12:20:57 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:22:02 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Date: Wed, 15 May 2002 12:22:01 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA03484 Subject: [NSIS] RE: What's in the charter of NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John, right now we may have a private conversation, the NSIS mail server may be broken. To contents.. > As far as BB go, I don't think we need to completely > ignore them, however, I don't think we can make NSIS > a BB-centric archiecture. What I mean is that we cannot > mandate a BB architecure (i.e. - everyone who wants to > use an NSIS protocol MUST deploy a bandwidth broker.) > I see it more as something that the signaling can occur > without a BB, but we may be able to put the correct > hooks to allow those who want to deploy BBs to be able to > do so. The problem then is the "one protocol only paradigm". Speaking as a representative of my company, the aim is to deploy switched IP QoS services. The signaling architecture is certainly less important than the time to market. Consequently, I never expected a BB to be the one and only solution. I'm favouring a twofold approach, centralized versus decentralized modes. Of course both must be compatible. In the end, a carrier could choose what best suits his needs. I'll try to live with this, maybe NSIS is able to solve that knot. > To put it another way, I don't think that the IESG will > let us standardize Bandwidth Brokers, nor is that something > that I want to do. However, it is possible that NSIS > could support BBs, if they are present. To repeat that: I never expected NSIS (or any other forum) to standardize a BB. Service related signaling between separate BB's, that's all I hoped could be supported. Not quite fulfilled, but NSIS may not be too far away too. Thinks are clearer to me now. Thanks for the discussion. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:08:58 2002 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 JAA01885 for ; Wed, 15 May 2002 09:08:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15975 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:09:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11573; Wed, 15 May 2002 08:41:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03554 for ; Wed, 15 May 2002 06:26:30 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24283 for ; Wed, 15 May 2002 06:26:16 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4FARod11920 for ; Wed, 15 May 2002 13:27:50 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 13:26:25 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 13:26:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 15 May 2002 13:26:19 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6515B@esebe004.NOE.Nokia.com> Thread-Topic: What's in the charter of NSIS Thread-Index: AcH7+l6E7ThqvKefTtKbnL34R9O9JwAABskw To: Cc: X-OriginalArrivalTime: 15 May 2002 10:26:27.0026 (UTC) FILETIME=[F85C0320:01C1FBFA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA03555 Subject: [NSIS] RE: What's in the charter of NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, > right now we may have a private conversation, the NSIS > mail server may be broken. To contents.. Its just slow. > The problem then is the "one protocol only paradigm". > Speaking as a representative of my company, the aim is > to deploy switched IP QoS services. The signaling > architecture is certainly less important than the > time to market. > Consequently, I never expected a BB to be the one and > only solution. I'm favouring a twofold approach, > centralized versus decentralized modes. Of course > both must be compatible. In the end, a carrier could > choose what best suits his needs. > I'll try to live with this, maybe NSIS is able to solve > that knot. What I think is that one protocol might not solve everything that we want. If we discover that we need more than one, then we should flag this need. We may need to recharter the working group at this point, or simply focus on one part of the problem to begin with. I am nearly 100% positive, that if we are successful, we will be creating the need for more work in the future - however, let's start with what we can. > To repeat that: I never expected NSIS (or any other forum) > to standardize a BB. Service related signaling between > separate BB's, that's all I hoped could be supported. Not > quite fulfilled, but NSIS may not be too far away too. Thinks are > clearer to me now. I hope they are clearer & hopefully statisfactory as well. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:12:20 2002 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 JAA02148 for ; Wed, 15 May 2002 09:12:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16266 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:12:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01597; Wed, 15 May 2002 05:41:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27931 for ; Wed, 15 May 2002 04:38:35 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21950 for ; Wed, 15 May 2002 04:38:20 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4F8cjk12957 for ; Wed, 15 May 2002 11:38:50 +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, 15 May 2002 11:38:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 11:38:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 15 May 2002 11:38:22 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65150@esebe004.NOE.Nokia.com> Thread-Topic: What's in the charter of NSIS Thread-Index: AcH75rpRB0oobWhFTluLyHop7SBPRgABDkYw To: Cc: X-OriginalArrivalTime: 15 May 2002 08:38:23.0300 (UTC) FILETIME=[DFC1F040:01C1FBEB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA27932 Subject: [NSIS] RE: What's in the charter of NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger, RFC 2998 discusses "Integrated Services Over Diffserv Networks." Some folks (meaning area directors & IESG folks) have thought that a more general solution is needed, meaning that 2998 is a specific implementation of the general solution. So, for example, there could be other solutions like: IntServ over MPLS Networks IntServ over Over Provisioned Networks Intserv over a Bandwidth Broker Network ... etc. Furthermore, maybe someone does not want IntServ exactly, but perhaps a certain characteristic of IntServ, say bandwidth. Then you could have Bandwidth Assurance over IntServ Networks Bandwidth Assurance over MPLS Networks Bandwidth Assurance over Over Provisioned Networks Bandwidth Assurance over a Bandwidth Broker Network ... etc. Finally, what do you do when one party of a call/session has one 'kind' of network and the other party has a different 'kind'? You could do a hop-by-hop approach, at each hop modifying or translating the necessary parameters, but this gets ugly fast and may not work. Perhaps it is better to have a general solution, then work later on how the general solution can be mapped down to a specific network or resource reservation mechanism. > This RFC 2998 mentions "admission control" only > 39 times, "resource" pops up 77 times, > "reservation/dynamic/policing/shaping/provisioning/mapping" > together contribute another 75 hits. Only fools could > believe that RFC 2998 is related to entities involved > in the reservation of resources. I don't get your point. Can you restate it? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:14:22 2002 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 JAA02288 for ; Wed, 15 May 2002 09:14:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16545 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:14:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11116; Wed, 15 May 2002 08:41:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02174 for ; Wed, 15 May 2002 05:57:39 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23352 for ; Wed, 15 May 2002 05:57:21 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4F9vuk23265 for ; Wed, 15 May 2002 12:57:56 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 12:57:34 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 12:57:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 15 May 2002 12:57:33 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DFC@esebe004.NOE.Nokia.com> Thread-Topic: What's in the charter of NSIS Thread-Index: AcH78/c4ZKVbo7RSQTSIdJ05xzqSowAAjuMg To: Cc: X-OriginalArrivalTime: 15 May 2002 09:57:34.0220 (UTC) FILETIME=[EF86CCC0:01C1FBF6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA02175 Subject: [NSIS] RE: What's in the charter of NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rudiger, > > Furthermore, maybe someone does not want IntServ exactly, > > but perhaps a certain characteristic of IntServ, say > > bandwidth. > > What happens to the remainder of IntServ in that case? > Would one have to signal empty parameters? No answer > required if this will be discussed in Helsinki! My feeling is we should discuss what parts we signaling, but we de-couple the signaling from the resource reservation. > > Then you could have > > > > Bandwidth Assurance over IntServ Networks > > Bandwidth Assurance over MPLS Networks > > Bandwidth Assurance over Over Provisioned Networks > > Bandwidth Assurance over a Bandwidth Broker Network > > That BB definition issue must be settled. The "friends > of BB" could provide an architecture outline by now, > if they are not charged of entering the solution discussion. > It would be helpful to have such a document (and I see > by your other message that you aggree). Your above > example in my words would be: > > BW Assurancee over MPLS using a BB > BW Assurance over Over Provisoned Networks using a BB > or in general: BW Assurance over a network using a BB > > BB's of separated domains may > signal with each other without bothering which > layers/technologies are supported by the domain > in which each operates. This solves the problem > you've mentioned below (with regard to signaling): As far as BB go, I don't think we need to completely ignore them, however, I don't think we can make NSIS a BB-centric archiecture. What I mean is that we cannot mandate a BB architecure (i.e. - everyone who wants to use an NSIS protocol MUST deploy a bandwidth broker.) I see it more as something that the signaling can occur without a BB, but we may be able to put the correct hooks to allow those who want to deploy BBs to be able to do so. To put it another way, I don't think that the IESG will let us standardize Bandwidth Brokers, nor is that something that I want to do. However, it is possible that NSIS could support BBs, if they are present. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:15:04 2002 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 JAA02345 for ; Wed, 15 May 2002 09:15:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16642 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:15:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01541; Wed, 15 May 2002 05:41:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26877 for ; Wed, 15 May 2002 04:26:20 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21668 for ; Wed, 15 May 2002 04:25:58 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4F8P2Y02210 for ; Wed, 15 May 2002 11:25:05 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 11:26:07 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 11:26:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Scoping of BBs Date: Wed, 15 May 2002 11:26:06 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DF8@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Scoping of BBs Thread-Index: AcH7f/QC8/ZgXcIDSi6uMQhqxeUwEgAZzS6Q To: , X-OriginalArrivalTime: 15 May 2002 08:26:07.0148 (UTC) FILETIME=[28FA0EC0:01C1FBEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA26878 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Cary, > I am somewhat confused by this problem description. NSIS is > concerned with QoS signalling, correct? QoS in the internet almost > always includes bandwidth, correct? So how does one signal QoS without > being involved with bandwidth allocation? What does "involved" mean? If you signaling that you want x amount of bandwidth, and get a reply of 'OK' - then that is signaling bandwidth. For example, if you and I want to have some sort of media call, with a bandwidth of 50 k, my network uses no resource reservation mechanisms, just simple access control and overprovisioning, while yours uses a proprietary implementation of IntServ, how do we handle bandwidth allocation? Might it be enought that I signal to my network my needs (BW = 50k), which are passed on to you, you signal to your network your needs (BW = 50K). Assuming everything was OK, then we have a session of 50k between us. This kind of signaling is nice because when you roam into my network, you don't need to worry at all what kind of provisioning is done in my network, you just simply request. > Does NSIS provide the mechanisms to signal a router to allocate Q Mbps > of bandwidth for flow xzy? Well, ok, perhaps not, but if NSIS is not > telling the entity that performs this function to initiate the provisioning > of Q Mbps, then what exactly is it doing? Ferrying DSCP's about? If NSIS > ends up using RSVP, do we drop bandwidth from the TSpec and RSpec, or the > other parameters, for they are used for provisioning? See above example. > I am very concerned that the NSIS charter has defined a problem space > wedged between session establishment and bearer path provisioning. A > solution for this problem space is definitely required, but it must be questioned > that yet another protocol solution is warranted. One has to wonder just how many > protocols/entities are really necessary to establish end-to-end QoS, and just > what the quality of this distributed, loosely coupled, multi-phasic solution will be? Question to you, what is it that you are looking for in this space? > More important, will this solution really provide a viable alternative to the L2 > centric solutions being worked on in other (notably wireless, but also PacketCable) > SDOs (yes, I understand that these solutions do not address the end-to-end problem > completely, but they are efficient solutions for the particular access network). > Sorry if this seems like charter bashing: consider it a request for clarification. > I would ask it at the interim, but I cannot be there. The above is l2 specific or network specific. You have trouble using any of them on the open Interent. Since there is not a solution currently, you do see multiple solutions at l2 or network dependent. However, these solutions are not universal enough to be used on other l2s or in different networks. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:15:58 2002 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 JAA02405 for ; Wed, 15 May 2002 09:15:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16730 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:16:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11374; Wed, 15 May 2002 08:41:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03218 for ; Wed, 15 May 2002 06:13:33 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23849 for ; Wed, 15 May 2002 06:13:20 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4FACPY28198 for ; Wed, 15 May 2002 13:12:26 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 13:13:30 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 13:13:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] To BB or not to BB Date: Wed, 15 May 2002 13:13:29 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65158@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] To BB or not to BB Thread-Index: AcH6l9TdV3MBX5GDRmG7OXpckknR2gBYSy9g To: Cc: X-OriginalArrivalTime: 15 May 2002 10:13:30.0467 (UTC) FILETIME=[297E8330:01C1FBF9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA03219 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Marco, Your proposed solution sounds much more like a proxy archicecture than a bandwidth broker architecture. I think we will be able to work on the problem area you have suggested without too much trouble. We will have to sort out the details, of course. John > -----Original Message----- > From: ext Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: 13 May, 2002 19:04 > To: 'Ping Pan'; brunner@ccrle.nec.de > Cc: Loughney John (NRC/Helsinki); Ruediger.Geib@t-systems.com; > gkenward@nortelnetworks.com; nsis@ietf.org > Subject: RE: [NSIS] To BB or not to BB > > > Ping, > > I am not sure how you define a Bandwidth Broker. As I and one of my > colleagues at SBC have expressed to you on several occasions, > we at SBC want > to enable our customers to signal for QOS flows across our > network. If we > are successfull NSIS will become the common signaling > protocol to do that > across all access methods. Because the timing does not fit > our immediate > needs, we have proposed extensions to RSVP as a way to access > ATM and MPLS > networks. In our architecture, customer initiated RSVP > signaling will be > directed to an controller which proxy signals for a > connection across our > network. It should come as no surprise that a number of other > carriers share > an interest in this approach as a way to exploit their > already deployed ATM > infrastructure. > > My 3 Cents, > > Marco > > > > > > -----Original Message----- > > From: Ping Pan [mailto:pingpan@juniper.net] > > Sent: Friday, May 10, 2002 1:03 PM > > To: brunner@ccrle.nec.de > > Cc: john.loughney@nokia.com; Ruediger.Geib@t-systems.com; > > gkenward@nortelnetworks.com; nsis@ietf.org > > Subject: Re: [NSIS] To BB or not to BB > > > > > > Marcus, > > > > I think that IETF, especially NSIS, should not become a > > kitchen sink for > > all possible combinations of network architecture. We belong to an > > engineering community here, that is, we need to try our best > > to come up > > with some practical solutions for some practical problems. > > > > Hence, could any *non-research* provider please please tell > me if and > > when they will deploy BB to their customers? If there is a > > real demand > > for BB, we should look into it in IETF (not sure within the > scope of > > NSIS neither)? Otherwise, why not push the work to other > > places, such as > > IRTF? > > > > 2 cents, > > > > - Ping > > > > > > > > Marcus Brunner wrote: > > > > > I am sorry, but I could not refrain from asking what Internet > > > Architecture BB are not part of? > > > > > > Otherwise I agree with John, the reqs and framework should > > allow for > > > various QoS architectures (including BB kind of > > architectures), defined > > > by the IETF. > > > > > > Marcus > > > > > > --On Friday, May 10, 2002 11:25 AM +0300 > > john.loughney@nokia.com wrote: > > > > > >> Hi all, > > >> > > >> Just a general comment about Bandwidth Brokers and NSIS. > Bandwidth > > >> Brokers (as the are commonly defined) are actually out of scope > > >> of NSIS. This means we are not defining a bandwidth broker > > >> architecture. There was quite a bit of discussion (at a > highlevel) > > >> about this before NSIS was allowed to be chartered, and it was > > >> said to me that bandwidth brokers are not really thought of > > >> as part of the Internet architecture. > > >> > > >> However, I do know that there are many folks providing bandwidth > > >> broker solutions. My view is that a bandwidth broker comes > > >> dangerously close to how resources are provisioned, therefore > > >> are out of scope of NSIS. From the charter: > > >> > > >> It is noted that resource reservation and traffic > > engineering can be > > >> considered as part of network administration, and > > therefore beyond the > > >> scope of the IETF to mandate a particular mechanism. > > >> > > >> Additionally, some folks may wish to check on the TEWG > > >> (http://www.ietf.org/html.charters/tewg-charter.html) for work on > > >> traffic engineering. > > >> > > >> Finally, I do think it is perfectly acceptable to have a > framework > > >> and/or solution that is friendly to bandwidth brokers, > but I do not > > >> think that a bandwidth broker centric architecture or solution is > > >> what we should do. > > >> > > >> John > > >> > > >> > > >> _______________________________________________ > > >> 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/ > > > 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 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 09:16:37 2002 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 JAA02453 for ; Wed, 15 May 2002 09:16:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16839 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 09:16:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11350; Wed, 15 May 2002 08:41:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03063 for ; Wed, 15 May 2002 06:11:56 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23766 for ; Wed, 15 May 2002 06:11:38 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4FACAk05794 for ; Wed, 15 May 2002 13:12:11 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 13:11:48 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 13:11:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Subject: RE: [NSIS] requirements draft and NSIS "product" Date: Wed, 15 May 2002 13:11:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65157@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] requirements draft and NSIS "product" Thread-Index: AcH6ukGeEitHbunMTP+aacZCvVUOsABPgUhQ To: , X-OriginalArrivalTime: 15 May 2002 10:11:48.0737 (UTC) FILETIME=[ECDBBF10:01C1FBF8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA03064 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Ilya, The process is: 1) In order to signaling QoS, what are the requirements? I think that this need not be an overly specified set of requirements, but should help us focus our thoughts on what we are trying to do. 2) What is the framework needed to support signaling QoS? What entities are involved, who does what. 3) What have existing solutions achieved? Do a comparison against them in order not to re-invent the wheel or to try to invent something that cannot be invented. 4) Start protocol work. At this point, we should have a good understanding of the needs, the environment & what has been done before. At this point, I think we will be able to understand enough to know if a single protocol is sufficient, if an extensible protocol is sufficient, if no new protocol work is needed or of if multiple protocols are needed. We may need to choose a subset of the entire area to start on at first. John > -----Original Message----- > From: ext Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > Sent: 13 May, 2002 21:51 > To: 'nsis@ietf.org' > Subject: [NSIS] requirements draft and NSIS "product" > > > All, > > It took me for a while till I realized that my biggest > problem with this > draft is presented in its first statement: "This document defines > requirements for signaling QoS across different network > environments". I > could not find the answer to the question - what is QoS > signaling? Is it a > protocol, collection of inter-working protocols (signaling > architecture) or > something different all together? Furthermore, without giving > an answer to > this question we have dived into the discussion of detailed > requirements to > ... whatever people have in their minds. The lack of clarity > (at least in my > mind) on this subject makes me feel often at odds with some > pieces of the > document while I am in the full agreement with others. It > seems that the > clarity and precision of the statements acceptable for the > group charter are > not sufficient to move forward requirements (followed by the > framework). > Am I missing something and this subject has been already discussed and > agreed upon? I'll appreciate if somebody can clarify it for me. > If I am not alone in my concerns I would like to start the > interim meeting > in Helsinki with this discussion. To have a meaningful requirement you > should know how you could tell whether it is met or not. > Without clearly > defining the "product" it is not simply possible. > > Best regards, > Ilya Freytsis > > > _______________________________________________ > 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 daemon@ns.ietf.org Wed May 15 10:16:50 2002 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 KAA06120 for ; Wed, 15 May 2002 10:16:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA23623 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 10:17:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23391; Wed, 15 May 2002 10:13:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23361 for ; Wed, 15 May 2002 10:13:09 -0400 (EDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05938 for ; Wed, 15 May 2002 10:12:52 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.36) id 177zW7-0000iC-00; Wed, 15 May 2002 16:12:35 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id g4FECZC18675; Wed, 15 May 2002 16:12:35 +0200 Message-ID: <3CE26CD3.24671F1A@ee.tu-berlin.de> Date: Wed, 15 May 2002 16:12:35 +0200 From: Xiaoming Fu Reply-To: fu@ee.tu-berlin.de Organization: Telecommunication Networks Group, Technical University Berlin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-686 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: "Geib, Ruediger" CC: john.loughney@nokia.com, nsis@ietf.org Subject: RFCs referring BB was: Re: [NSIS] RE: What's in the charter of NSIS References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ftmail.ee.tu-berlin.de id g4FECZC18675 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA23363 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger and John, "Geib, Ruediger" wrote: > > That BB definition issue must be settled. john.loughney@nokia.com wrote: > There is no 'bandwidth broker' term in the IETF lexicon, a quick > RFC search turned up no references. I think this is part of the > problem. Generally, the IETF has been allergic to centralized > approaches, as this introduces single points of failures, etc. Chapter 4 of rfc2905 refers an explicit definition of bandwidth broker (which discussed by Internet2) and derives authorization aspects for the BB. Maybe it's helpful for NSIS to regard the BB as an item as well. As many folks here stated, BB is not usually a centralized approach in a larger scale than a single domain. There are a number of other rfcs (e.g., 2475, 2903, 2638) talk about the BB. Regards, -- Xiaoming Fu fu@ee.tu-berlin.de http://www-tkn.ee.tu-berlin.de/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 10:22:35 2002 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 KAA06633 for ; Wed, 15 May 2002 10:22:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24347 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 10:22:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23804; Wed, 15 May 2002 10:17:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23771 for ; Wed, 15 May 2002 10:17:41 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06212 for ; Wed, 15 May 2002 10:17:26 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4FEGXY21742 for ; Wed, 15 May 2002 17:16:33 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 17:17:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 15 May 2002 17:17:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFCs referring BB was: Re: [NSIS] RE: What's in the charter of NSIS Date: Wed, 15 May 2002 17:17:27 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6516B@esebe004.NOE.Nokia.com> Thread-Topic: RFCs referring BB was: Re: [NSIS] RE: What's in the charter of NSIS Thread-Index: AcH8GphkARvEByM/RBmCRxM1u/UE+gAADuDA To: , Cc: X-OriginalArrivalTime: 15 May 2002 14:17:27.0519 (UTC) FILETIME=[3DDB66F0:01C1FC1B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA23772 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Xiaoming, > Chapter 4 of rfc2905 refers an explicit definition of bandwidth > broker (which discussed by Internet2) and derives authorization > aspects for the BB. Maybe it's helpful for NSIS to regard the BB > as an item as well. As many folks here stated, BB is not usually > a centralized approach in a larger scale than a single domain. > > There are a number of other rfcs (e.g., 2475, 2903, 2638) talk > about the BB. 2905, 2475 and 2638 are all informational. 2903 is experimental. So, my feeling is that the IETF has not seriously considered BBs for any protocol work. Additionally, BBs are more about traffic engineering, network management and resource reservation, so the exact nature of them is out of scope for NSIS. However, we could discuss them as we would discuss other resource reservation, etc. mechanisms. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 10:32:54 2002 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 KAA07207 for ; Wed, 15 May 2002 10:32:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25742 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 10:33:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24544; Wed, 15 May 2002 10:25:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24512 for ; Wed, 15 May 2002 10:25:54 -0400 (EDT) Received: from sophia.inria.fr (IDENT:root@sophia.inria.fr [138.96.64.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06818 for ; Wed, 15 May 2002 10:25:38 -0400 (EDT) Received: from radio2 (radio2.inria.fr [138.96.250.232]) by sophia.inria.fr (8.11.6/8.11.6) with SMTP id g4FEPha16863; Wed, 15 May 2002 16:25:43 +0200 X-Authentication-Warning: sophia.inria.fr: Host radio2.inria.fr [138.96.250.232] claimed to be radio2 Message-ID: <004d01c1fc1c$6b813c00$e8fa608a@inria.fr> From: "Rares SERBAN" To: , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65156@esebe004.NOE.Nokia.com> Subject: Re: [NSIS] To BB or not to BB Date: Wed, 15 May 2002 16:25:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John, I read the draft ¨Requirements for QoS Signaling Protocols¨and I found that the definition of the QoS signaling makes no difference between out-of-band signaling and in-band signaling. So, for the next version of the draft it should be necessary to define such things. Also, we must to speek o the level 3 (network level). For QoS there are many signalization methods using IP header so NSIS should not forget of them. Thank you, R. ----- Original Message ----- From: To: Cc: Sent: Wednesday, May 15, 2002 11:59 AM Subject: RE: [NSIS] To BB or not to BB > Hi Cornelia & Sven, > > > Note that out-of-band signaling is also an issue when QoS > > Routing is employed. > > > > I.e. when the signaling packets are not identified the same > > way as the data packets they are signaling for (e.g. > > different DSCP, addresses etc) they might be routed > > differently and we have out-of-band signaling anyways. > > I think a reasonable requirement for NSIS is to support out of > band signaling. > > 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 daemon@ns.ietf.org Wed May 15 10:43:23 2002 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 KAA07967 for ; Wed, 15 May 2002 10:43:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27803 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 10:43:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26143; Wed, 15 May 2002 10:35:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26067 for ; Wed, 15 May 2002 10:35:23 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07330 for ; Wed, 15 May 2002 10:35:08 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 10:29:25 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93152@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] requirements draft and NSIS "product" Date: Wed, 15 May 2002 10:29:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="Windows-1251" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, I agree with the process you have described and I am glad that the discussions about NSIS charter, BB etc. happens now before finalizing requirement discussion. It helps to understand better where different thinking is coming from. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Wednesday, May 15, 2002 6:12 AM To: ifreytsis@cetacean.com; nsis@ietf.org Subject: RE: [NSIS] requirements draft and NSIS "product" Hi Ilya, The process is: 1) In order to signaling QoS, what are the requirements? I think that this need not be an overly specified set of requirements, but should help us focus our thoughts on what we are trying to do. 2) What is the framework needed to support signaling QoS? What entities are involved, who does what. 3) What have existing solutions achieved? Do a comparison against them in order not to re-invent the wheel or to try to invent something that cannot be invented. 4) Start protocol work. At this point, we should have a good understanding of the needs, the environment & what has been done before. At this point, I think we will be able to understand enough to know if a single protocol is sufficient, if an extensible protocol is sufficient, if no new protocol work is needed or of if multiple protocols are needed. We may need to choose a subset of the entire area to start on at first. John > -----Original Message----- > From: ext Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > Sent: 13 May, 2002 21:51 > To: 'nsis@ietf.org' > Subject: [NSIS] requirements draft and NSIS "product" > > > All, > > It took me for a while till I realized that my biggest > problem with this > draft is presented in its first statement: "This document defines > requirements for signaling QoS across different network > environments". I > could not find the answer to the question - what is QoS > signaling? Is it a > protocol, collection of inter-working protocols (signaling > architecture) or > something different all together? Furthermore, without giving > an answer to > this question we have dived into the discussion of detailed > requirements to > ... whatever people have in their minds. The lack of clarity > (at least in my > mind) on this subject makes me feel often at odds with some > pieces of the > document while I am in the full agreement with others. It > seems that the > clarity and precision of the statements acceptable for the > group charter are > not sufficient to move forward requirements (followed by the > framework). > Am I missing something and this subject has been already discussed and > agreed upon? I'll appreciate if somebody can clarify it for me. > If I am not alone in my concerns I would like to start the > interim meeting > in Helsinki with this discussion. To have a meaningful requirement you > should know how you could tell whether it is met or not. > Without clearly > defining the "product" it is not simply possible. > > Best regards, > Ilya Freytsis > > > _______________________________________________ > 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 daemon@ns.ietf.org Wed May 15 11:05:56 2002 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 LAA09231 for ; Wed, 15 May 2002 11:05:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00546 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 11:06:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29556; Wed, 15 May 2002 10:57:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29525 for ; Wed, 15 May 2002 10:57:18 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08813 for ; Wed, 15 May 2002 10:57:03 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 10:51:49 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93153@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, bless@tm.uka.de Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Wed, 15 May 2002 10:51:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA29526 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, John. As far as I understand when you are talking about centralized approach you mean an approach to the resource provisioning. As we agreed resource provisioning is out of NSIS scope anyway so there is no reason to get into this discussion. That is exactly the reason why I like so much QoS Initiator - QoS Controller terminology. It helps us not to deal with distributed and centralized approaches at all (or deal with them in uniform fashion - whatever you like more). Then the issue of having one or many QCs within domain becomes the issue of local QoS technology/provisioning rather than signaling. What I am looking for is very similar to Ruediger (I think) - the QoS signaling that will make interoperability between domains using different QoS technology easy (possible) and uniform. I do not what to deal with Intserve over Diffserve, Intserve over MPLS etc. I would like to end up with NSIS between all sorts of domains. My 2 cents. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Wednesday, May 15, 2002 4:48 AM To: Ruediger.Geib@t-systems.com; bless@tm.uka.de Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Hi Rüdiger, > I don't know what your perception of a BB is. Mine is that > there's one per QoS domain, controlled by the operator > running the domain. There's no difference in per router > security requirements and BB security requirements if you > look at the single element. The number of routers involved > into signaling is higher and each has to as robust against > an attack as the few centralised BBs have to be. There is no 'bandwidth broker' term in the IETF lexicon, a quick RFC search turned up no references. I think this is part of the problem. Generally, the IETF has been allergic to centralized approaches, as this introduces single points of failures, etc. Anyhow, I have yet to see a clear, crisp definition of bandwidth broker, so I very hesitant in accepting it into NSIS. > > Discovery mechanisms (how > > do I discover the BB in my home network, my visited > > network, do I need to discover your BB if I am calling > > you .... > > As difficult to solve as AAA. Not really, I think the current AAA architecture is not so bad. > > Scalability - to what extent does this scale? > > Can we put a metric on it? Is it per domain, sub-domain, > > per link ..? > > Or per router, maybe even integrated into a router? If you'd > like to see more literatutre on the scalability of centralised > admission control, could you provide a couple of references > examining the scalability IntDiff? Noone is promoting Integrated Services over DiffServ networks as a solution to NSIS, as this work as already been done. Whether or not anyone uses it, is not an issue for us. I think we need to work on a more general approach, because we cannot ensure that all networks deploy DiffServ. 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 daemon@ns.ietf.org Wed May 15 11:52:59 2002 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 LAA10655 for ; Wed, 15 May 2002 11:52:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04668 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 11:53:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04188; Wed, 15 May 2002 11:47:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04154 for ; Wed, 15 May 2002 11:47:24 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10429 for ; Wed, 15 May 2002 11:47:07 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4FFkI896269; Wed, 15 May 2002 17:46:18 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA23198; Wed, 15 May 2002 17:43:40 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 113B91A40D; Wed, 15 May 2002 17:43:36 +0200 (CEST) Date: Wed, 15 May 2002 17:56:21 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: sven.van_den_bosch@alcatel.be, john.loughney@nokia.com Cc: Lars.Westberg@era.ericsson.se, nsis@ietf.org Subject: Re: [NSIS] Scoping of BBs Message-ID: <16341648.1021485381@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Sven, I am not sure what you refer to with probing mechanisms. But agree that we really want to decouple signalling from resource reservation. Marcus --On Tuesday, May 14, 2002 2:57 PM +0200 sven.van_den_bosch@alcatel.be wrote: > John, all, > > The fact that you decouple signaling from resource reservation seems to > suggest the anticipated use of some sort of probing mechanism prior to > connection setup. We were more thinking along the lines of hard-guaranteed > QoS with per-flow admission control (also in the core), mandating the > notion of resource reservation in the signaling protocol (much like in > RSVP by the way). I agree that the actual way the reservation is carried > out locally is out of scope, but I wouldn't like to exclude the notion > from the protocol, nor exclude resource reservation entities to > participate in it. > > Sven > > > > > > john.loughney@nokia.com on 14/05/2002 14:08:06 > > > > To: Lars.Westberg@era.ericsson.se > > cc: nsis@ietf.org(bcc: Sven VAN DEN > BOSCH/BE/ALCATEL) > > > > Subject [NSIS] Scoping of BBs > : > > > > > > > Hi Lasse, > >> Could you explain more about your proxy-solution. I am not >> conviced that your proxy is the same as a bandwidth broker. > > You make a good point. To provide some additional scoping, > here are my thoughts: > > 1) entities involved in the reservation of resources are > out of scope. > > 2) entities which relay signaling probably are not out of scope. > > 3) place holders for future work in signaling to & between > resource reservation entities is probably in scope, the > exact nature of the signaling is probably out of scope. > > 4) signaling to & from entities which 'proxy' qos is probably > within scope. > > 5) signaling end-to-end is within scope > > 6) resource reservation end-to-end is not in scope. > > 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 -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 12:01:40 2002 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 MAA11057 for ; Wed, 15 May 2002 12:01:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06875 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 12:01:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04091; Wed, 15 May 2002 11:47:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04056 for ; Wed, 15 May 2002 11:47:19 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10421 for ; Wed, 15 May 2002 11:47:03 -0400 (EDT) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4FFlC0E015297 for ; Wed, 15 May 2002 17:47:12 +0200 (MEST) Received: from lm6068 (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0GW5008NAT6OXI@mbb1.ericsson.se> for nsis@ietf.org; Wed, 15 May 2002 17:47:12 +0200 (MET DST) Date: Wed, 15 May 2002 17:47:11 +0200 From: David Partain To: nsis@ietf.org Reply-to: David.Partain@ericsson.com Message-id: <200205151747.11597.David.Partain@ericsson.com> MIME-version: 1.0 X-Mailer: KMail [version 1.4] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [NSIS] new draft (draft-westberg-nsis-edge-edge-framework-00.txt) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, I have submitted the following to the I-D folks: Title : Framework for Edge-to-Edge NSIS Signaling Author(s) : L. Westberg, et al Filename : draft-westberg-nsis-edge-edge-framework-00.txt Pages : 26 Date : February 2002 This draft describes a framework for NSIS QoS signaling in edge to edge networks. The main goal is to provide a skeleton for lightweight edge to edge NSIS signaling in a network. This skeleton would be used as input to the NSIS "Framework signaling architecture". For the impatient, you'll find the draft at: http://standards.ericsson.net/partain/documents/draft-westberg-nsis-edge-edge-framework-00.txt It should show up in the I-D repository soon. Cheers, David _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 15 13:17:14 2002 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 NAA14011 for ; Wed, 15 May 2002 13:17:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13913 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 13:17:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13666; Wed, 15 May 2002 13:11:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13641 for ; Wed, 15 May 2002 13:11:49 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13801 for ; Wed, 15 May 2002 13:11:35 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 13:06:17 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93156@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: 'john.loughney@nokia.com', "'nsis@ietf.org'" Subject: RE: [NSIS] requirements draft and NSIS "product" Date: Wed, 15 May 2002 13:06:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="Windows-1251" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, I agree with the process you have described and I am glad that the discussions about NSIS charter, BB etc. happens now before finalizing requirement discussion. It helps to understand better where different thinking is coming from. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Wednesday, May 15, 2002 6:12 AM To: ifreytsis@cetacean.com; nsis@ietf.org Subject: RE: [NSIS] requirements draft and NSIS "product" Hi Ilya, The process is: 1) In order to signaling QoS, what are the requirements? I think that this need not be an overly specified set of requirements, but should help us focus our thoughts on what we are trying to do. 2) What is the framework needed to support signaling QoS? What entities are involved, who does what. 3) What have existing solutions achieved? Do a comparison against them in order not to re-invent the wheel or to try to invent something that cannot be invented. 4) Start protocol work. At this point, we should have a good understanding of the needs, the environment & what has been done before. At this point, I think we will be able to understand enough to know if a single protocol is sufficient, if an extensible protocol is sufficient, if no new protocol work is needed or of if multiple protocols are needed. We may need to choose a subset of the entire area to start on at first. John > -----Original Message----- > From: ext Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > Sent: 13 May, 2002 21:51 > To: 'nsis@ietf.org' > Subject: [NSIS] requirements draft and NSIS "product" > > > All, > > It took me for a while till I realized that my biggest > problem with this > draft is presented in its first statement: "This document defines > requirements for signaling QoS across different network > environments". I > could not find the answer to the question - what is QoS > signaling? Is it a > protocol, collection of inter-working protocols (signaling > architecture) or > something different all together? Furthermore, without giving > an answer to > this question we have dived into the discussion of detailed > requirements to > ... whatever people have in their minds. The lack of clarity > (at least in my > mind) on this subject makes me feel often at odds with some > pieces of the > document while I am in the full agreement with others. It > seems that the > clarity and precision of the statements acceptable for the > group charter are > not sufficient to move forward requirements (followed by the > framework). > Am I missing something and this subject has been already discussed and > agreed upon? I'll appreciate if somebody can clarify it for me. > If I am not alone in my concerns I would like to start the > interim meeting > in Helsinki with this discussion. To have a meaningful requirement you > should know how you could tell whether it is met or not. > Without clearly > defining the "product" it is not simply possible. > > Best regards, > Ilya Freytsis > > > _______________________________________________ > 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 daemon@ns.ietf.org Wed May 15 14:05:23 2002 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 OAA16061 for ; Wed, 15 May 2002 14:05:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17880 for nsis-archive@odin.ietf.org; Wed, 15 May 2002 14:05:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16826; Wed, 15 May 2002 13:56:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16796 for ; Wed, 15 May 2002 13:56:46 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15765 for ; Wed, 15 May 2002 13:56:31 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4FHtWY26291 for ; Wed, 15 May 2002 20:55:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 May 2002 20:56:38 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 15 May 2002 20:56:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] To BB or not to BB Date: Wed, 15 May 2002 20:56:37 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65171@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] To BB or not to BB Thread-Index: AcH8HGgQiLvTvZNzRZq/kOSJNb8+5QAHRASw To: Cc: X-OriginalArrivalTime: 15 May 2002 17:56:37.0990 (UTC) FILETIME=[DC260860:01C1FC39] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA16797 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, > I read the draft ¨Requirements for QoS Signaling Protocols¨and I found that > the definition of the QoS signaling makes no difference between out-of-band > signaling and in-band signaling. So, for the next version of the draft it > should be necessary to define such things. Also, we must to speek o the > level 3 (network level). For QoS there are many signalization methods using > IP header so NSIS should not forget of them. Feel free to document this. I am aware of them, but documentation is always helpful. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 16 07:26:52 2002 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 HAA20476 for ; Thu, 16 May 2002 07:26:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05261 for nsis-archive@odin.ietf.org; Thu, 16 May 2002 07:27:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04960; Thu, 16 May 2002 07:20:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04929 for ; Thu, 16 May 2002 07:20:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20157; Thu, 16 May 2002 07:19:44 -0400 (EDT) Message-Id: <200205161119.HAA20157@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: Thu, 16 May 2002 07:19:43 -0400 Subject: [NSIS] I-D ACTION:draft-westberg-nsis-edge-edge-framework-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Framework for Edge-to-Edge NSIS Signaling Author(s) : L. Westberg Filename : draft-westberg-nsis-edge-edge-framework-00.txt Pages : 26 Date : 15-May-02 Real-time applications impose very strict requirements on the underlying transmission network that requires a high level of quality of service (QoS). This level of QoS can only be achieved by means of QoS management on an end-to-end basis (i.e., end user to end user), from application to application, potentially across many domains, as the current Internet is a concatenation of many domains, usually managed by different QoS administrators (operators). The requirement for end-to-end QoS management does not necessarily mean that a single resource reservation protocol must be applied end- to-end. In fact it is most likely that the end-to-end QoS management architecture will consist of many interoperable and concatenated QoS management architectures rather than one global end-to-end QoS infrastructure. Usually a network consists of three network parts, i.e., a host to first hop router, access network and the backbone of the network. Each of these three network parts imposes different requirements on the provided QoS solution. This draft describes a framework for NSIS QoS signaling in edge to edge networks. The main goal is to provide a skeleton for lightweight edge to edge NSIS signaling in a network. This skeleton would be used as input to the NSIS 'Framework signaling architecture'. Even though designed for edge-to-edge signaling the applicability of this framework is not to be limited only to signaling between the edges of a network, but it can be extended in other signaling scenarios as well, such as end host - to - end host signaling. The QoS protocol that will be applied in an edge to edge network is denoted as edge-to-edge NSIS protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westberg-nsis-edge-edge-framework-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-westberg-nsis-edge-edge-framework-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-westberg-nsis-edge-edge-framework-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: <20020515120808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-westberg-nsis-edge-edge-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-westberg-nsis-edge-edge-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020515120808.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 16 14:06:35 2002 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 OAA04514 for ; Thu, 16 May 2002 14:06:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03654 for nsis-archive@odin.ietf.org; Thu, 16 May 2002 14:06:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02467; Thu, 16 May 2002 13:59:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02414 for ; Thu, 16 May 2002 13:59:56 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04211 for ; Thu, 16 May 2002 13:59:41 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4GHxO847839; Thu, 16 May 2002 19:59:24 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA05948; Thu, 16 May 2002 19:56:42 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4041646B95; Thu, 16 May 2002 19:56:42 +0200 (CEST) Date: Thu, 16 May 2002 20:09:33 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Geib, Ruediger" , Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Errored situation signaling requirements Message-ID: <35652325.1021579773@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Ruediger, Do you feel that there are implicit requests of resources? And I would say more it is a request for service (the ressource management needs to be done within a domain) Marcus --On Thursday, May 02, 2002 3:21 PM +0200 "Geib, Ruediger" wrote: > R >> (5.3.7 Explicit request of resources > R >> NSIS signaling must support the explicit request of resources.) >> > G> Is this not similar to Requirement 5.3.1! > > 5.3.1 is: Explicit release of resources. > My suggestion is about establishment of resources. I can see a difference. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 16 14:25:18 2002 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 OAA05255 for ; Thu, 16 May 2002 14:25:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04913 for nsis-archive@odin.ietf.org; Thu, 16 May 2002 14:25:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04454; Thu, 16 May 2002 14:18:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04423 for ; Thu, 16 May 2002 14:18:40 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05009 for ; Thu, 16 May 2002 14:18:25 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4GIHZ848137; Thu, 16 May 2002 20:17:35 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA06063; Thu, 16 May 2002 20:14:54 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 395B6430F9; Thu, 16 May 2002 20:14:53 +0200 (CEST) Date: Thu, 16 May 2002 20:27:45 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, bless@tm.uka.de Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Message-ID: <36744505.1021580865@[192.168.102.79]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC6512B@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6512B@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Tuesday, May 14, 2002 3:01 PM +0300 john.loughney@nokia.com wrote: > Hi all, > >> Sorry, but I disagree here. It gives you much more >> flexibility, but I don't see how it complicates things >> significantly. IMO an NSIS solution should allow at >> least both solutions, either router-based (RSVP-like) >> or BB-based, and, personally I don't think this will >> complicate things that much. > > Complications are: security (we are developing for an > open Internet) - 3rd parties involvment in any signaling > is a known security hole. I think security is a problem anyway no matter whether we use centralized or distributed environment. > Discovery mechanisms (how > do I discover the BB in my home network, my visited > network, do I need to discover your BB if I am calling > you .... We already today need to discover (or get configured( quite a number of things (e.g. DNS servers). > Scalability - to what extent does this scale? > Can we put a metric on it? Is it per domain, sub-domain, > per link ..? Scale in terms of what? > I am very happy to see additional literature on this, > I know that some of this will work in closed networks, > but I don't know enough of how it works in an open > network. What do you see as an open network? As soon as you start providing QoS you need to paretially close the network (and I do not see a way around it) Marcus > John > > _______________________________________________ > 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/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 16 16:28:04 2002 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 QAA09837 for ; Thu, 16 May 2002 16:28:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10714 for nsis-archive@odin.ietf.org; Thu, 16 May 2002 16:28:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10053; Thu, 16 May 2002 16:18:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10022 for ; Thu, 16 May 2002 16:18:04 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09632 for ; Thu, 16 May 2002 16:17:48 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4GKHX849941 for ; Thu, 16 May 2002 22:17:33 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA06967 for ; Thu, 16 May 2002 22:14:50 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 288703BC8F for ; Thu, 16 May 2002 22:14:50 +0200 (CEST) Date: Thu, 16 May 2002 22:27:42 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Subject: submitted requierements -02 (Re: [NSIS] New requirements draft before interim meeting?) Message-ID: <43941945.1021588062@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA10023 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit So, finally I was able to spend some little time to submit a new version (-02) of the req draft. There has not much changed (see Change log below). Basically, I tried to add some of the points, which came up on the list. Feel free to add more, if we need to discuss them in Helsinki. For early birds, the draft can be found on http://www.brubers.org/marcus/papers/draft-ietf-nsis-req-02.txt Change Log Version 01 -> 02 - added issues 62-72 - added some discussion text to open issues - req " highest possible network utilization" added (issue 33, closed) - issues closed: 34 (UMTS scenarios), 35 (PSTN gatway scenarios), - removed req "Avoid duplication of [sub]domain signaling functions", issue 51 - Section 5.3.4: added explanation of recoverable and unrecoverable errors (issue 53) - added the following requirement: (closed issue 55) Allow local QoS information exchange between nodes of the saeme administrative domain The QoS signaling protocol must be able to exchange local QoS information between QoS controllers located within one single domain. Local QoS information might, for example, be IP addresses, severe congestion notification, notification of successful or erroneous processing of QoS signaling messages. In some cases, the NSIS QoS signalling protocol may carry identification of the QoS controllers located at the boundaries of a domain. However, the identification of edge should not be visible to the end host (QoS initiator) and only applies within one QoS administrative domain. - closed issue 57: add text about "Minimal impact on interior (core) nodes" to requirement 5.6.8 "Ability to constrain load on devices" - added requirement "Allow efficient QoS re-establishment after handover", closed issue 60. - changed text in 5.3.2 --On Monday, May 13, 2002 9:34 AM +0200 "Geib, Ruediger" wrote: > Hello Marcus, > > you've mentioned that you already plan a new version of the NSIS > requirements draft. The agenda for the interim meeting however lists > version 01, so the next version won't get available before the interim? > > Regards, Rüdiger > > _______________________________________________ > 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/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 16 16:41:39 2002 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 QAA10315 for ; Thu, 16 May 2002 16:41:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11592 for nsis-archive@odin.ietf.org; Thu, 16 May 2002 16:41:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11346; Thu, 16 May 2002 16:32:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11318 for ; Thu, 16 May 2002 16:32:26 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09998 for ; Thu, 16 May 2002 16:32:11 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4GKVq850132 for ; Thu, 16 May 2002 22:31:52 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA07082 for ; Thu, 16 May 2002 22:29:10 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0A98E28879 for ; Thu, 16 May 2002 22:29:09 +0200 (CEST) Date: Thu, 16 May 2002 22:42:01 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <44800900.1021588921@[192.168.102.79]> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========44806548==========" Subject: [NSIS] open issues Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --==========44806548========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit I post here the list of open issues (and only those I regard as open still). They can also be found at the end of draft-ietf-nsis-req-02.txt. This is meant for preparation of the interim meeting. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus --==========44806548========== Content-Type: text/plain; charset=iso-8859-1; name="open_issues_02.txt" Content-Disposition: attachment; filename="open_issues_02.txt"; size=10502 Content-Transfer-Encoding: quoted-printable Open Issues: from draft-ietf-nsis-req-02.txt -------------------------------------------- 1) (OPEN) add Scenarios=20 Do we need to add, remove, or change the scenarios? 2) (OPEN) Sender/receiver initiation Proposals:=20 1)should be optimized for sender initiated 2) remove the requirement, because it is not relevant if we allow for = third party QoS initiators 3) SHOULD support sender initiated, MAY support reciever initiated Issues: - does it matter who pays? - for sender initiated, can we support implicit signaling=20 (bundling the QoS requests with other signaling - registration, etc.)? - For reciever initiated, do we need protection against spamming -=20 how do we protect against unwanted changes? 4) (OPEN) MUSTs, SHOULDs, MAY needs discussion 7) (OPEN) Hemant Chaskar: Section 3.1, items 1) Handoff decision and 2) = Trigger sources: The handoff decision and trigger sources should be out of = scope of NSIS. NSIS should rather focus only on "establishing" QoS along = the packet path after handoff.=20 8) (OPEN) bi-directional data path setup with one QoS request I have not seen consensus on whether to require bi-directional data path = setup with QoS.=20 Q: How can we actually perform bi-directional reservations when the forward = and reverse paths are not reciprocal, with respect to routing topology and = routing policy of network domains between sender and receiver?=20 A: bi-directional data path setup does not need to use the same return path = as the forwarding path. The only requirement to achieve a bi-directional = reservation is that the sender for the forwarding path is also the receiver = for the return path and that the receiver for the forwarding path is also = the sender for the return path. - The need to ensure that the return path is the same as the forwarding = path is one of the problems with RSVP, particularly in a mobile = environment. 14) (OPEN, dependend on resolution of bi-directional) proposal to add = "support grouping of microflows (possibly only for feedback)" "As a consequence of the optimization for the interactive multimedia = services, the signaling should allow one unique request for several micro = flows having the same origination and destination IP addresses. This is = usually the case for multimedia SIP calls where the voice and video micro = flows follow the same path. This grouping of requests allows optimization = of the QoS processing. Note that this may be detrimental for the call setup = time. The use of grouping for microflows may be restricted to teardown = and/or notification messages when call setup time is a concern." open issue: first resolve the bi-directional issue which is somewhat = related, because it seams to be an optimization as well Should not be restrict to teardown and/or notification, it might be useful = also for the procedure that refreshes reservation states 16) (OPEN) Req: 5.1.9 change provisioning into better term, since different = people understand different thing with provisioning 26) (OPEN) interaction of NSIS with seamoby (context transfer and CAR = discovery) 28) (OPEN) new requirement on "asynchronous events from the network" The content of the message might be very service specific, but the protocol = support for asynchronous events from the network might be a valuable = requirement. We have something about notification in case of = errors/failures. 29) (OPEN) NSIS in case of handovers The whole mobility area needs to be defined 37) (OPEN) ownership of a reservation The issue here is that a known party owns reservations done in the network. = (which might include that the party also pays). The question arose who is = allowed to tear-down, receive asynchronous notifications in case of network = initiated tear-down, etc. This also relates to how certain service granted is named/identified. 38) (OPEN) definition of security threats 39) (OPEN) simplify security requirements section 40) (OPEN) add mobility related requirements 42) (OPEN) add an assumption that QoS nmonitoring is application-specific = and with it out of scope of the WG 43) (OPEN) asynchronous notification of QoS Initiator, Controller, = Receiver, there are security issues related. Basically, an ownership issue. = Nevertheless, an asynch notifcation in case of an error, network failure = etc. is specifically in areas, where longer lived sessions are setup, = essential in order to notify upper layes (appluications etc. as well. 44) (OPEN) req 5.1.2 resource availability info on request come back to it = as soon as we have a more clear idea about service description issue=20 45) (OPEN) 5.3.4 Possibility for automatic re-setup of resources after = recovery=20 - more thoughts in failure conditions potentially=20 - better text=20 - operation under overload plays into issue 46) 46) (OPEN) we need multiple scenario for failure and recovery cases to = derive requirements. Or a list failre cases might be a start as well. 47) (OPEN) traffic engineering and route pinning I assume this would result in operational type of requirements Opinions on that? 52) (OPEN) New requirement: interaction with policy=20 this most likely is covered by an opaque token for authentication dependency on security changes 53) (OPEN) Section 5.3. Error handling=20 Comments: 1) notification of user in case of unrecoverable errors (has been done by = notification requirement, or will be done by asynch notification, issue 43) A description of both types of errors (recoverable, unrecoverable) are = listed in Section 5.3.4. 2) hop-by-hop? OR right to the end? 3) What is potential value to notify about recoverable errors? Proposal: not hop by hop, but QoS controller to QoS initiator 59) (OPEN) add req: ability to deal with severe congestion (req 5.3.4 of = draft-partain-..-00 issues are: - occurs in a highly utilised network and if it is not solved very fast = then the network performance will quickly collapse - deos it belong to failure recovery (I would assume from a service point = of view this is failure - hop by hop problem (issue from Jorge) - What difference does it make (from the QoS perspective) if the provided = QoS degraded due to hardware failure on a device or due to congestion = caused by failures on some other devices? What is required from the = protocol is to signal this failure to other participants (QCs or QI) in the = hope that they can do something meaningful (e.g. re-routing) to correct the = problem or tear down the flow. 61) (OPEN) add req: 6.1.8 from draft-bucheli-...-00 on multicast "Multicast consideration should not impact the protocol complexity for = unicast flows. Multicast support is not considered as a priority, because = the targeted interactive multimedia services are mainly unicast. For this = reason, if considered in the solution, multicast should not bring = complexity in the unicast scenario." Opinions? --------------------------------------------------- starting from -02 version --------------------------------------------------- 62) (OPEN) Request to add VPN scenario=20 - Related to issue 1) - Difference of VPN scenario compared to what we already have is missing 64) (OPEN) Request to add req: Backwards compatibility A later version of an NSIS protocol must be backwards compatible with = earlier versions of an NSIS protocol. 65) (OPEN) Request to add req: Unexpected situations and error restistance An NSIS protocol must define behaviour of NSIS signaling units during = unexpected situations. Unexpected situtions are unknown messages, = parameters and parameter settings as well as receiption of unexpected = messages (e.g. a "Reservation Confirmation" without prior "Reservation = Request"). Related to Open issues (53) and requirement 5.3.4.=20 This requirement is emphasizing to many details that might not be necessary Req 5.3.4 refers to behaviour in the case of problems in the data plane. My = suggestion here is about unexpected events/errors in the control plane. If = you think that this point carries to many details, let's split it up in = several individual requirements. 66) (OPEN) Request to add req: Default behaviour An NSIS protocol must define default behaviours and parameter settings = wherever applicable.=20 67) (OPEN) Request to add req: Extendability An NSIS protocol must provide means to enhance a protocol with future = procedures, messages, parameters and parameter settings. This was refering mostly to the service specific part of the protocol. could be a part of the modularity requirement 5.1.3 68) (OPEN) Request to add req: Preventation of stale state An NSIS signalling protocol must provide means for an NSIS signaling unit = to discover and remove local stale state. This may for example be done by = means like soft state and periodic flooding or by a polling mechanism and = hard state signaling. Might already be covered in other requirements, could also be that the = solutions known are solutions for different problems. I think distributed = garbage collection could also be a solution. 69) (OPEN) Request to add req: Reliable Communication NSIS signaling procedures, connectivity between units involved in NSIS = signaling as well as the basic transport protocol used by NSIS must provide = a maximum of communication reliability. Procedures must define how an NSIS = signaling systems behaves if some kind of request it sent stays without = answer (this could require e.g. be timers, number of message retransmits = and release messages).=20 An NSIS signaling unit must be able to check its connectivity to an = adjacent NSIS signaling unit at any time (this requirement must however not = result in a DoS attack tool - the frequency of these checks must be = limited, and flow control may be useful).=20 The basic transport protocol to be used between adjacent NSIS units must = ensure message integrity and reliable transport. MUST/SHOULD ensure error- and loss free transmission of signaling = information.=20 Do we really require this? Isn't this a soft state versus hard state issue? 70) (OPEN) Request to add req: Smooth breakdown A unit participating in NSIS signaling must no cause further damage to = other systems involved in NSIS signaling when it has to go out of service. 72) (OPEN) request to add "Error notification and error location" "An NSIS signaling node rejecting or releasing a reservation must indicate = its identity. NSIS signalling should indicate why a requested resource is = not or no longer available. " --==========44806548==========-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu May 16 21:40:09 2002 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 VAA16706 for ; Thu, 16 May 2002 21:40:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA25223 for nsis-archive@odin.ietf.org; Thu, 16 May 2002 21:40:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25190; Thu, 16 May 2002 21:34:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25154 for ; Thu, 16 May 2002 21:34:02 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16608 for ; Thu, 16 May 2002 21:33:47 -0400 (EDT) From: Zhigang.Kan@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4H1YJk11941 for ; Fri, 17 May 2002 04:34:23 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 May 2002 04:33:56 +0300 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 17 May 2002 04:33:56 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 17 May 2002 09:33:05 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: submitted requierements -02 (Re: [NSIS] New requirements draftbefore interim meeting?) Date: Fri, 17 May 2002 09:14:39 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD0412EB@beebe001.NOE.Nokia.com> Thread-Topic: submitted requierements -02 (Re: [NSIS] New requirements draftbefore interim meeting?) Thread-Index: AcH9JtJHf65VOdg1Tji9swGW6iDQEgAGR6ew To: , X-OriginalArrivalTime: 17 May 2002 01:33:05.0175 (UTC) FILETIME=[CA989270:01C1FD42] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA25155 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, Would you like to add "Table of Contents" to the draft so it can be more readable? BR/Kan Zhigang -----Original Message----- From: ext Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: Friday, May 17, 2002 4:28 AM To: nsis@ietf.org Subject: submitted requierements -02 (Re: [NSIS] New requirements draftbefore interim meeting?) So, finally I was able to spend some little time to submit a new version (-02) of the req draft. There has not much changed (see Change log below). Basically, I tried to add some of the points, which came up on the list. Feel free to add more, if we need to discuss them in Helsinki. For early birds, the draft can be found on http://www.brubers.org/marcus/papers/draft-ietf-nsis-req-02.txt Change Log Version 01 -> 02 - added issues 62-72 - added some discussion text to open issues - req " highest possible network utilization" added (issue 33, closed) - issues closed: 34 (UMTS scenarios), 35 (PSTN gatway scenarios), - removed req "Avoid duplication of [sub]domain signaling functions", issue 51 - Section 5.3.4: added explanation of recoverable and unrecoverable errors (issue 53) - added the following requirement: (closed issue 55) Allow local QoS information exchange between nodes of the saeme administrative domain The QoS signaling protocol must be able to exchange local QoS information between QoS controllers located within one single domain. Local QoS information might, for example, be IP addresses, severe congestion notification, notification of successful or erroneous processing of QoS signaling messages. In some cases, the NSIS QoS signalling protocol may carry identification of the QoS controllers located at the boundaries of a domain. However, the identification of edge should not be visible to the end host (QoS initiator) and only applies within one QoS administrative domain. - closed issue 57: add text about "Minimal impact on interior (core) nodes" to requirement 5.6.8 "Ability to constrain load on devices" - added requirement "Allow efficient QoS re-establishment after handover", closed issue 60. - changed text in 5.3.2 --On Monday, May 13, 2002 9:34 AM +0200 "Geib, Ruediger" wrote: > Hello Marcus, > > you've mentioned that you already plan a new version of the NSIS > requirements draft. The agenda for the interim meeting however lists > version 01, so the next version won't get available before the interim? > > Regards, Rüdiger > > _______________________________________________ > 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/ 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 daemon@optimus.ietf.org Fri May 17 03:16:10 2002 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 DAA04637 for ; Fri, 17 May 2002 03:16:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA19013 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 03:16:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17799; Fri, 17 May 2002 02:52:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17770 for ; Fri, 17 May 2002 02:52:15 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04328 for ; Fri, 17 May 2002 02:52:02 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 17 May 2002 08:50:35 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 08:51:40 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] Errored situation signaling requirements Date: Fri, 17 May 2002 08:51:37 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA17771 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Marcus, draft req 01 section 5.3.1 talks about resources and I adjusted my text to fit to it: New: requirement for a "thing" set up Existing: requirement for a "thing" release I prefer the term "service" instead of resource (in all cases). Implicit request may not be correct. The set up of a service certainly is what NSIS is about. But if a service request is implicit, would you have to express a wish to set it up explicitely (and that's what you do if you signal for it). I'm aware that I'm a bit formal here and we don't have to go to length. A "service set up" requirement can as well be dropped. Regards, Rüdiger > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Thursday, May 16, 2002 8:10 PM > To: Geib, Ruediger; Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] Errored situation signaling requirements > > > Ruediger, > > Do you feel that there are implicit requests of resources? > And I would say more it is a request for service (the > ressource management > needs to be done within a domain) > > Marcus > > --On Thursday, May 02, 2002 3:21 PM +0200 "Geib, Ruediger" > wrote: > > > R >> (5.3.7 Explicit request of resources > > R >> NSIS signaling must support the explicit request of resources.) > >> > > G> Is this not similar to Requirement 5.3.1! > > > > 5.3.1 is: Explicit release of resources. > > My suggestion is about establishment of resources. I can > see a difference. > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 04:37:51 2002 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 EAA05755 for ; Fri, 17 May 2002 04:37:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23075 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 04:38:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22035; Fri, 17 May 2002 04:21:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22004 for ; Fri, 17 May 2002 04:21:18 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05550 for ; Fri, 17 May 2002 04:21:03 -0400 (EDT) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4H8LH0E008160 for ; Fri, 17 May 2002 10:21:17 +0200 (MEST) Received: from lm6068 (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0GW800GHJXVHIH@mbb1.ericsson.se> for nsis@ietf.org; Fri, 17 May 2002 10:21:17 +0200 (MET DST) Date: Fri, 17 May 2002 10:21:16 +0200 From: David Partain To: nsis@ietf.org Reply-to: David.Partain@ericsson.com Message-id: <200205171021.16355.David.Partain@ericsson.com> MIME-version: 1.0 X-Mailer: KMail [version 1.4] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [NSIS] Yet another new draft. Happy reading! Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, Yesterday, I submitted the following to the I-D folks. It's an update which tries to take changes in the requirements draft into consideration in analyzing existing QoS solutions. Title : Analysis of Existing QoS Solutions Author(s) : P. O'Hanlon, et. al Filename : draft-demeer-nsis-analysis-01.txt Pages : 54 Date : 16-May-2002 This memo provides a brief analysis of existing IP quality of service (QoS) solutions and the implied signalling issues. This analysis is intended to point out open issues in QoS signalling. Moreover, this analysis is done in order to understand whether the strict QoS requirements imposed by future fixed and mobile applications are satisfied by the existing IP QoS solutions. The existing IP QoS solutions can be categorized as follows: * End-to-end per-flow resource reservation protocols * Integrated Services over Differentiated Services * Statically assigned trunk reservations based on Differentiated Services * Dynamic trunk reservations with Aggregated RSVP For the impatient, you'll find the draft at: http://standards.ericsson.net/partain/documents/draft-demeer-nsis-analysis-01.txt It should show up in the I-D repository soon. Cheers, David _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 04:48:59 2002 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 EAA05940 for ; Fri, 17 May 2002 04:48:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23648 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 04:49:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23318; Fri, 17 May 2002 04:43:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23287 for ; Fri, 17 May 2002 04:43:02 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05870 for ; Fri, 17 May 2002 04:42:46 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4H8h7k03107 for ; Fri, 17 May 2002 11:43:08 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 17 May 2002 11:42:44 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 17 May 2002 11:42:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 17 May 2002 11:42:44 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC651D0@esebe004.NOE.Nokia.com> Thread-Topic: Updated NSIS Interim Meeting Plan Thread-Index: AcH9fs/ATlCig0AuQmCxGtovHsfEKA== To: X-OriginalArrivalTime: 17 May 2002 08:42:44.0637 (UTC) FILETIME=[D05A4CD0:01C1FD7E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA23288 Subject: [NSIS] Updated NSIS Interim Meeting Plan Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Nokia Research Center, Helsinki Finland Tuesday May 21st 10 AM to 4 PM Wednesday May 22nd 9 AM to 4 PM Thursday May 23rd 9 AM to 12 Noon Tuesday AM ========== 9 AM coffee 10 AM Requirements of a QoS Solution for Mobile IP (http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-02.txt) 11 AM Requirements for QoS Signaling Protocols (http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-01.txt) 12 AM Lunch 1 PM Requirements for QoS Signaling Protocols cont (http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-01.txt) 3 PM Security requirements & analysis Wednesday AM ============ 9 AM RSVP Proxy (http://www.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-03.txt) 10 AM Applicability of "Specification of the Null Service Type - RFC 2997" Applicability of "A Framework For IntServ Operation Over Diffserv Networks - RFC 2998" 12 AM Lunch 1 PM Two-plane and Three-tier QoS Framework for Mobile IPv6 Networks (http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt) 1:30 PM Towards a Framework for QoS Signaling in the Internet (http://search.ietf.org/internet-drafts/draft-hancock-nsis-framework-00.txt) 2:00 PM Localized RSVP (http://www.cs.helsinki.fi/u/jmanner/papers/draft-manner-lrsvp-00.txt) 2:30 PM Framework for edge to edge QoS signaling (http://standards.ericsson.net/partain/documents/draft-westberg-nsis-edge-edge-framework-00.txt) 3:00 PM Relationship of Context Transfer to NSIS (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-03.txt) 3:30 PM discussion of Framework issues Thursday ======== 9 AM Framework summary 10 AM Analysis of the Resource Reservation Protocol (to be submitted) 11 PM "Analysis of Existing QoS Solutions" (http://standards.ericsson.net/partain/documents/draft-demeer-nsis-analysis-01.txt) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 04:57:05 2002 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 EAA06021 for ; Fri, 17 May 2002 04:57:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23911 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 04:57:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23574; Fri, 17 May 2002 04:47:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23465 for ; Fri, 17 May 2002 04:47:02 -0400 (EDT) Received: from FNVISION ([210.115.124.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05912 for ; Fri, 17 May 2002 04:46:47 -0400 (EDT) To: Cc: From: "medbrkthrgh77@yahoo.com" Date: 17 May 02 08:47:41 -0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain MIME-Version: 1.0 Message-ID: <0e52ca300506a007d2@[210.115.124.122]> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by optimus.ietf.org id EAA23470 Subject: [NSIS] Medical Breakthrough... aging can be reversed with HGH Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Do you want to LIVE LONGER? Do you want to LOOSE WEIGHT Easily? Do you need ENERGY? You can have these and more with HGH! HUMAN GROWTH HORMONE (HGH) Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs--plus all other symptoms related to old age. IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: *Reduce Body Fat and Build Lean Muscle WITHOUT EXERCISE! *Enhance Sexual Performance *Remove Wrinkles and Cellulite *Lower Blood Pressure and Improve Cholesterol Profile *Improve Sleep, Vision and Memory *Restore Hair Color and Growth *Strengthen the Immune System *Increase Energy and Cardiac Output *Turn back your body's Biological Time Clock *10-20 years in as little as six months. *All natural, plant based and 100% safe. We are the manufacturer and we sell directly to Doctors, Chiropractors, and rejuvenation clinics worldwide. As a recognized expert in the “HGH Field of Rejuvenation? our advice to clinics is well documented. With internet marketing, we are able to save distribution cost and offer you breakthrough pricing. At last, you can obtain an affordable, safe Oral Spray HGH. We ship directly to your door ? a product you’ll love. But, you must act now because this is a limited offer. Call 1-888-621-7300 (24 hours). All of your questions will be addressed and answered in a friendly, no pressure manner. Our main purpose is to provide you with scientific information, so you can make an educated decision. Discover the truth of HGH for yourself, call for your free "HGH Consultation". Call This Number Now: 1-888-621-7300. “In a few weeks you will look back on this moment as one of the best things you have every done for yourself? If you are on-line, please write down our phone number and call us when you can! Thanks, The HGH Staff Offer 05/02 Code: RR M-12 PS Read what people are saying: "The effects of 6 months of GH on lean body mass and fat were equivalent in magnitude to the changes incurred during 10-20 years of aging." Dr. Daniel Rudman, MD, New England Journal of Medicine. "Within four months, my body fat decreased form 30% down to 21%! I noticed my skin is more supple and my overall mental outlook improved significantly." D.W., New Jersey "We have been on the spray for just 3 weeks now, and besides the tremendous energy we both feel, my husbands allergies and spells of depression have lifted. I am healing extremely fast after an accident and have lost 7 lbs. without trying!" C.B., Flagstaff. AZ ************************************************** This email is sent to you as a one time email advertisement. Your address was purchased from an email list. Unless you contact us with a question or to place an order, you will not receive another email. ************************************************** The following statement is provided to be in compliance with commercial email laws. This message is sent in compliance with the new email bill section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618 and is not intended for residents in the State of WA, NV, CA and VA. If you have received this mailing in error, or do not wish to receive any further mailings pertaining to this topic, visit http://www.Autoremove.com Do Not hit the reply button, your address will not be deleted. We respect all removal requests. Your request may take over 8 weeks to process. . _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 06:00:14 2002 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 GAA06900 for ; Fri, 17 May 2002 06:00:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27310 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 06:00:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26657; Fri, 17 May 2002 05:46:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26627 for ; Fri, 17 May 2002 05:46:23 -0400 (EDT) Received: from mail.alcatel.co.uk (mail.alcatel.co.uk [195.92.62.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06758 for ; Fri, 17 May 2002 05:46:07 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bt0g2p.god.bel.alcatel.be (relay01.net.alcatel.co.uk [127.0.0.1]) by mail.alcatel.co.uk (8.11.0/8.9.3) with ESMTP id g4H9kJS27026; Fri, 17 May 2002 10:46:19 +0100 Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g4H9iBK12415; Fri, 17 May 2002 11:44:11 +0200 Subject: RE: [NSIS] Scoping of BBs To: john.loughney@nokia.com Cc: Lars.Westberg@era.ericsson.se, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 17 May 2002 11:46:08 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/17/2002 11:46:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi john, See some comments inline Sven john.loughney@nokia.com on 15/05/2002 10:58:52 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: Lars.Westberg@era.ericsson.se, nsis@ietf.org Subject RE: [NSIS] Scoping of BBs : Hi Sven, > The fact that you decouple signaling from resource reservation seems to > suggest the anticipated use of some sort of probing mechanism prior to > connection setup. Why do you say that? Cannot the probe be the actual request? Sven>> Maybe it can but it will never guarantee you QoS. There is absolutely no reason why the current state of the network would still allow the QoS when the actual data arrive or even that it remains that way for the duration of the connection one wishes to establish. That's why we think there is a case for hard-guaranteed QoS. > We were more thinking along the lines of hard-guaranteed > QoS with per-flow admission control (also in the core), mandating the > notion of resource reservation in the signaling protocol (much like in RSVP > by the way). I agree that the actual way the reservation is carried out > locally is out of scope, but I wouldn't like to exclude the notion from the > protocol, nor exclude resource reservation entities to > participate in it. I wonder if we need hard-guaranteed-QoS with per-flow admission control in all cases. I definately think that this is a service, but I am not sure if it is the default. Sven>> I assume the default service will still be BE and that we are trying with nsis to provide something in addition to that. Sven. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 06:01:11 2002 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 GAA06936 for ; Fri, 17 May 2002 06:01:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27566 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 06:01:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26894; Fri, 17 May 2002 05:54:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26865 for ; Fri, 17 May 2002 05:54:52 -0400 (EDT) Received: from mail.alcatel.co.uk (mail.alcatel.co.uk [195.92.62.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06847 for ; Fri, 17 May 2002 05:54:37 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bt0g2p.god.bel.alcatel.be (relay01.net.alcatel.co.uk [127.0.0.1]) by mail.alcatel.co.uk (8.11.0/8.9.3) with ESMTP id g4H9sph31065; Fri, 17 May 2002 10:54:51 +0100 Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g4H9qhe16400; Fri, 17 May 2002 11:52:43 +0200 Subject: Re: [NSIS] RE: What's in the charter of NSIS To: john.loughney@nokia.com Cc: Ruediger.Geib@t-systems.com, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 17 May 2002 11:54:20 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/17/2002 11:54:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Ruediger, John, all, Would it be fair to say then that we can indicate in the signaling that: a. we want to reserve resources b. how many we want of what type but c. without actually participating in the implementation or saying how it must be done. We can discuss next week if needed, Sven. john.loughney@nokia.com on 15/05/2002 11:57:33 To: Ruediger.Geib@t-systems.com cc: nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject [NSIS] RE: What's in the charter of NSIS : Hi Rudiger, > > Furthermore, maybe someone does not want IntServ exactly, > > but perhaps a certain characteristic of IntServ, say > > bandwidth. > > What happens to the remainder of IntServ in that case? > Would one have to signal empty parameters? No answer > required if this will be discussed in Helsinki! My feeling is we should discuss what parts we signaling, but we de-couple the signaling from the resource reservation. > > Then you could have > > > > Bandwidth Assurance over IntServ Networks > > Bandwidth Assurance over MPLS Networks > > Bandwidth Assurance over Over Provisioned Networks > > Bandwidth Assurance over a Bandwidth Broker Network > > That BB definition issue must be settled. The "friends > of BB" could provide an architecture outline by now, > if they are not charged of entering the solution discussion. > It would be helpful to have such a document (and I see > by your other message that you aggree). Your above > example in my words would be: > > BW Assurancee over MPLS using a BB > BW Assurance over Over Provisoned Networks using a BB > or in general: BW Assurance over a network using a BB > > BB's of separated domains may > signal with each other without bothering which > layers/technologies are supported by the domain > in which each operates. This solves the problem > you've mentioned below (with regard to signaling): As far as BB go, I don't think we need to completely ignore them, however, I don't think we can make NSIS a BB-centric archiecture. What I mean is that we cannot mandate a BB architecure (i.e. - everyone who wants to use an NSIS protocol MUST deploy a bandwidth broker.) I see it more as something that the signaling can occur without a BB, but we may be able to put the correct hooks to allow those who want to deploy BBs to be able to do so. To put it another way, I don't think that the IESG will let us standardize Bandwidth Brokers, nor is that something that I want to do. However, it is possible that NSIS could support BBs, if they are present. 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 daemon@optimus.ietf.org Fri May 17 06:13:14 2002 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 GAA07040 for ; Fri, 17 May 2002 06:13:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27974 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 06:13:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27629; Fri, 17 May 2002 06:02:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27600 for ; Fri, 17 May 2002 06:02:28 -0400 (EDT) Received: from mail.alcatel.co.uk (mail.alcatel.co.uk [195.92.62.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06955 for ; Fri, 17 May 2002 06:02:12 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bt0g2p.god.bel.alcatel.be (relay01.net.alcatel.co.uk [127.0.0.1]) by mail.alcatel.co.uk (8.11.0/8.9.3) with ESMTP id g4HA2RE01351; Fri, 17 May 2002 11:02:27 +0100 Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g4HA0JR20146; Fri, 17 May 2002 12:00:19 +0200 Subject: Re: [NSIS] Scoping of BBs To: brunner@ccrle.nec.de Cc: john.loughney@nokia.com, Lars.Westberg@era.ericsson.se, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 17 May 2002 12:02:22 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/17/2002 12:02:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus, As I said in the reply to John I agree with respect to the actual reservation act (as stated in some other mails in this thread this can happen e.g. with a BB) but it is essential to have to notion in the signaling to say that at least you can get confirmation that something is actually there for you when you send data. 2 more cents, Sven. Marcus Brunner on 15/05/2002 17:56:21 Please respond to brunner@ccrle.nec.de To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, john.loughney@nokia.com cc: Lars.Westberg@era.ericsson.se, nsis@ietf.org Subject Re: [NSIS] Scoping of BBs : Sven, I am not sure what you refer to with probing mechanisms. But agree that we really want to decouple signalling from resource reservation. Marcus --On Tuesday, May 14, 2002 2:57 PM +0200 sven.van_den_bosch@alcatel.be wrote: > John, all, > > The fact that you decouple signaling from resource reservation seems to > suggest the anticipated use of some sort of probing mechanism prior to > connection setup. We were more thinking along the lines of hard-guaranteed > QoS with per-flow admission control (also in the core), mandating the > notion of resource reservation in the signaling protocol (much like in > RSVP by the way). I agree that the actual way the reservation is carried > out locally is out of scope, but I wouldn't like to exclude the notion > from the protocol, nor exclude resource reservation entities to > participate in it. > > Sven > > > > > > john.loughney@nokia.com on 14/05/2002 14:08:06 > > > > To: Lars.Westberg@era.ericsson.se > > cc: nsis@ietf.org(bcc: Sven VAN DEN > BOSCH/BE/ALCATEL) > > > > Subject [NSIS] Scoping of BBs > : > > > > > > > Hi Lasse, > >> Could you explain more about your proxy-solution. I am not >> conviced that your proxy is the same as a bandwidth broker. > > You make a good point. To provide some additional scoping, > here are my thoughts: > > 1) entities involved in the reservation of resources are > out of scope. > > 2) entities which relay signaling probably are not out of scope. > > 3) place holders for future work in signaling to & between > resource reservation entities is probably in scope, the > exact nature of the signaling is probably out of scope. > > 4) signaling to & from entities which 'proxy' qos is probably > within scope. > > 5) signaling end-to-end is within scope > > 6) resource reservation end-to-end is not in scope. > > 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 -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 07:21:01 2002 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 HAA07969 for ; Fri, 17 May 2002 07:21:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA00246 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 07:21:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00137; Fri, 17 May 2002 07:12:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00106 for ; Fri, 17 May 2002 07:12:52 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07802 for ; Fri, 17 May 2002 07:12:36 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4HBB6873895; Fri, 17 May 2002 13:11:06 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA14728; Fri, 17 May 2002 13:08:22 +0200 Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id ECF71144CD; Fri, 17 May 2002 13:08:20 +0200 (CEST) Date: Fri, 17 May 2002 13:21:15 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Zhigang.Kan@nokia.com, nsis@ietf.org Subject: RE: submitted requierements -02 (Re: [NSIS] New requirements draftbefore interim meeting?) Message-ID: <11019835.1021641675@[192.168.102.79]> In-Reply-To: <4AE1AC3D692F55488F2D03518907B8AD0412EB@beebe001.NOE.Nokia.com> References: <4AE1AC3D692F55488F2D03518907B8AD0412EB@beebe001.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA00107 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit If it help, I can do this in the next version Marcus --On Friday, May 17, 2002 9:14 AM +0800 Zhigang.Kan@nokia.com wrote: > Hi Marcus, > > Would you like to add "Table of Contents" to the draft so it can be more > readable? > > BR/Kan Zhigang > > -----Original Message----- > From: ext Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Friday, May 17, 2002 4:28 AM > To: nsis@ietf.org > Subject: submitted requierements -02 (Re: [NSIS] New requirements > draftbefore interim meeting?) > > > So, finally I was able to spend some little time to submit a new version > (-02) of the req draft. There has not much changed (see Change log below). > > Basically, I tried to add some of the points, which came up on the list. > Feel free to add more, if we need to discuss them in Helsinki. > > For early birds, the draft can be found on > http://www.brubers.org/marcus/papers/draft-ietf-nsis-req-02.txt > > Change Log Version 01 -> 02 > - added issues 62-72 > > - added some discussion text to open issues > > - req " highest possible network utilization" added (issue 33, closed) > > - issues closed: 34 (UMTS scenarios), 35 (PSTN gatway scenarios), > > - removed req "Avoid duplication of [sub]domain signaling functions", > issue 51 > > - Section 5.3.4: added explanation of recoverable and unrecoverable > errors (issue 53) > > - added the following requirement: (closed issue 55) Allow local QoS > information exchange between nodes of the saeme administrative domain > > The QoS signaling protocol must be able to exchange local QoS information > between QoS controllers located within one single domain. Local QoS > information might, for example, be IP addresses, severe congestion > notification, notification of successful or erroneous processing of QoS > signaling messages. > In some cases, the NSIS QoS signalling protocol may carry identification > of the QoS controllers located at the boundaries of a domain. However, > the identification of edge should not be visible to the end host (QoS > initiator) and only applies within one QoS administrative domain. > > - closed issue 57: add text about "Minimal impact on interior (core) > nodes" to requirement 5.6.8 "Ability to constrain load on devices" > > - added requirement "Allow efficient QoS re-establishment after > handover", closed issue 60. > > - changed text in 5.3.2 > > > > --On Monday, May 13, 2002 9:34 AM +0200 "Geib, Ruediger" > wrote: > >> Hello Marcus, >> >> you've mentioned that you already plan a new version of the NSIS >> requirements draft. The agenda for the interim meeting however lists >> version 01, so the next version won't get available before the interim? >> >> Regards, Rüdiger >> >> _______________________________________________ >> 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/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > 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/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 07:31:28 2002 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 HAA08709 for ; Fri, 17 May 2002 07:31:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01231 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 07:31:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00374; Fri, 17 May 2002 07:25:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00340 for ; Fri, 17 May 2002 07:25:04 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08116; Fri, 17 May 2002 07:24:46 -0400 (EDT) Message-Id: <200205171124.HAA08116@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: Fri, 17 May 2002 07:24:46 -0400 Subject: [NSIS] I-D ACTION:draft-demeer-nsis-analysis-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Existing QoS Solutions Author(s) : H. De Meer Filename : draft-demeer-nsis-analysis-01.txt Pages : 54 Date : 16-May-02 This memo provides a brief analysis of existing IP quality of service (QoS) solutions and the implied signalling issues. This analysis is intended to point out open issues in QoS signalling. Moreover, this analysis is done in order to understand whether the strict QoS requirements imposed by future fixed and mobile applications are satisfied by the existing IP QoS solutions. The existing IP QoS solutions can be categorized as follows: * End-to-end per-flow resource reservation protocols * Integrated Services over Differentiated Services * Statically assigned trunk reservations based on Differentiated Services * Dynamic trunk reservations with Aggregated RSVP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-01.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-demeer-nsis-analysis-01.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-demeer-nsis-analysis-01.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: <20020516145337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-demeer-nsis-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-demeer-nsis-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020516145337.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 08:55:14 2002 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 IAA11325 for ; Fri, 17 May 2002 08:55:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA04558 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 08:55:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04016; Fri, 17 May 2002 08:46:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03981 for ; Fri, 17 May 2002 08:46:48 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10965 for ; Fri, 17 May 2002 08:46:33 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4HCmBd27480 for ; Fri, 17 May 2002 15:48:11 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 May 2002 15:46:42 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 17 May 2002 15:46:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] RE: What's in the charter of NSIS Date: Fri, 17 May 2002 15:46:44 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC651DE@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: What's in the charter of NSIS Thread-Index: AcH9iPH4MjvCscSiT1W8p+kNQvwQJAAF8g4A To: Cc: , X-OriginalArrivalTime: 17 May 2002 12:46:44.0999 (UTC) FILETIME=[E6B04170:01C1FDA0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA03982 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, > Would it be fair to say then that we can indicate in the > signaling that: > a. we want to reserve resources > b. how many we want of what type but > c. without actually participating in the implementation or > saying how it must be done. I think that a. could be re-worded to state: a. We want a service, which could be a resource reservation or require resource reservation. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 08:55:36 2002 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 IAA11343 for ; Fri, 17 May 2002 08:55:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA04581 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 08:55:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04085; Fri, 17 May 2002 08:47:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04050 for ; Fri, 17 May 2002 08:47:41 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10976 for ; Fri, 17 May 2002 08:47:25 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA14752 for ; Fri, 17 May 2002 14:47:35 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA01860 for ; Fri, 17 May 2002 14:47:37 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 14:47:35 +0200 Message-ID: <91B98F554ABCD21182430008C7B1C5CD01A626E9@MCHH242E> From: Frank Reinhard To: "'NSIS'" Date: Fri, 17 May 2002 14:47:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [NSIS] Bandwidth Broker discussion Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, to the ongoing BB discussion it might be useful to consider the work we have done in the AQUILA project (www.ist-aquila.org). Even if we have specified and implemented a specific solution, some of the ideas might be worth to be considered also in the current phase of the NSIS WG: In the AQUILA project we have both considered intra-domain reservations and inter-domain reservations. The intra-domain solution bases on the following cornerstones (as far as it concerns the BB discussion): - Separate admission control from resource control - Use a layer-2-independent description of a service for admission control. An end-user's requests is for a service, not for a implementation! - Place the admission control entities nearby the data path, e.g. at the edge routers or associated to the edge routers. - Keep the resource control independent from the data path. The admission control entities of AQUILA, called admission control agents (ACA), can easily be mapped to the QC of NSIS. The AQUILA resource control agents however (RCA), are something else and out of the scope of NSIS. Even when AQUILA uses a specific layer-2 technology (DiffServ), the signalling to and between the ACAs does not strictly depend on that. Much of the misunderstanding about the scope of the BB concept comes from the fact, that a BB does IMHO not clearly separate admission and resource control! For inter-domain resource reservations we added an additional level on top of the domains, based on BGRP. We have just published an I-D describing this architecture (http://www.ietf.org/internet-drafts/draft-salsano-bgrpp-arch-00.txt), and a second draft analysing the scalability of this approach will follow soon. Again in a very short form some of the cornerstones: - The signalling entities (BGRP agents, you might say inter-domain QCs) are located nearby the border routers. So the signalling basically follows the BGP route. - There is no extra inter-domain resource controller, as it uses the already established intra-domain resource control of each domain (it might be a solution as described above or just overprovisioning or whatever else). - Base admission control decisions on SLA's between domains (and on internal resource availability, of course). - Aggregate reservations to achieve scalability. - Allow to "skip over" some BGRP agents during signalling to further reduce the signalling load. This means, that signalling information is not only exchanged hop-by hop, but also leaving out some intermediate nodes, if we know, that all the intermediate nodes would say "yes" anyway. I think that AQUILA is pretty much an example for a two-layered QoS signalling approach, which could at least fulfil some of the NSIS requirements. I do not want to promote this solution as the one NSIS should adapt, as it still has a lot of open issues.. But there are also some things we could learn (and during the AQUILA project we already have learned): - Base your signalling on services (best: predefined, globally well known services, but that is another discussion). - Signalling should follow the path of entities, which perform admission control. These should be located nearby the data path. (Nearby means not necessarily on the routers, but associated with them). - Resource control is another story. For scalability, you should use a solution, which does not have to consult resource control for each individual reservation, but can group this. - Make inter-domain resource control an additional layer on top of the domains' resource control to keep it separated from each domain's implementation. - Place the control of the SLA's between domains in the inter-domain signalling path. - Do NOT place the control of the resources within a domain in the inter-domain signalling path. Instead use a intra-domain resource control for that. In AQUILA, we have developed two fully different signalling protocols for intra- and inter-domain resource control. I see this as a lack of the project and do not propose that. Instead I would be happy, if NSIS could create a way to do both with the same protocol. Best regards Martin and Reinhard _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 08:55:45 2002 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 IAA11362 for ; Fri, 17 May 2002 08:55:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA04595 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 08:55:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04127; Fri, 17 May 2002 08:47:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04092 for ; Fri, 17 May 2002 08:47:47 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10988 for ; Fri, 17 May 2002 08:47:32 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4HCnAd27886 for ; Fri, 17 May 2002 15:49:10 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 May 2002 15:47:41 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 17 May 2002 15:47:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Scoping of BBs Date: Fri, 17 May 2002 15:47:43 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC651DF@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Scoping of BBs Thread-Index: AcH9iQi0WyMP1aNMSMq7boxYpYqYcAAF+MZg To: Cc: , X-OriginalArrivalTime: 17 May 2002 12:47:44.0606 (UTC) FILETIME=[0A378FE0:01C1FDA1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA04093 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sven, > Sven>> Maybe it can but it will never guarantee you QoS. There is > absolutely no reason why the current state of the network > would still allow > the QoS when the actual data arrive or even that it remains > that way for > the duration of the connection one wishes to establish. > That's why we think there is a case for hard-guaranteed QoS. So, Hard-quaranteed QoS could be one service offered. That is reasonable. Do you think this implies additional requirements? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 09:27:29 2002 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 JAA12900 for ; Fri, 17 May 2002 09:27:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06359 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 09:27:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06072; Fri, 17 May 2002 09:21:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06019 for ; Fri, 17 May 2002 09:21:48 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12627 for ; Fri, 17 May 2002 09:21:32 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4HDM8k17435 for ; Fri, 17 May 2002 16:22:08 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 May 2002 16:21:45 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 17 May 2002 16:21:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 17 May 2002 16:21:28 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC651E4@esebe004.NOE.Nokia.com> Thread-Topic: I-D ACTION:draft-iab-considerations-00.txt,.ps Thread-Index: AcH9pPj7UZ928bhPRzmBK/qTvNH4KgAAIihQ To: Cc: X-OriginalArrivalTime: 17 May 2002 13:21:45.0252 (UTC) FILETIME=[CA896E40:01C1FDA5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA06020 Subject: [NSIS] Please read before the interim meeting: I-D ACTION:draft-iab-considerations-00.txt,.ps Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Enclosed is a very good document, which may help us to focus our thoughts prior to the interim meeting. I strongly suggest that everyone read it, as it contains quite a bit of wisdom. thanks, John > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 17 May, 2002 14:25 > Cc: iab@isi.edu > Subject: I-D ACTION:draft-iab-considerations-00.txt,.ps > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Internet Architecture Board > Working Group of the IETF. > > Title : General Architectural and Policy > Considerations > Author(s) : S. Floyd > Filename : draft-iab-considerations-00.txt,.ps > Pages : 17 > Date : 16-May-02 > > This document suggests general architectural and policy questions to > be addressed in our work in the IETF. We note that this document > contains questions to be addressed, as opposed to guidelines or > architectural principles to be followed. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iab-considerations-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-iab-considerations-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-iab-considerations-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. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 09:45:02 2002 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 JAA13698 for ; Fri, 17 May 2002 09:45:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08042 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 09:45:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07737; Fri, 17 May 2002 09:40:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07699 for ; Fri, 17 May 2002 09:40:07 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13470 for ; Fri, 17 May 2002 09:39:51 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4HDcvY29398 for ; Fri, 17 May 2002 16:38:57 +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 ; Fri, 17 May 2002 16:40:04 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 17 May 2002 16:40:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 17 May 2002 16:40:03 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E0F@esebe004.NOE.Nokia.com> Thread-Topic: Interim Meeting participants Thread-Index: AcH9qFjDdEcRjbBlS/+EFrcHX7OSOQ== To: X-OriginalArrivalTime: 17 May 2002 13:40:04.0522 (UTC) FILETIME=[59C0B8A0:01C1FDA8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA07700 Subject: [NSIS] Interim Meeting participants Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, So far I have as participating: Anders Bergsten Roland Bless Marcus Brunner Alban Couturier Gabor Fodor Ilya Freytsis Ralitsa Gateva Georgios Karagiannis Rajeev Koodli (Wednesday only) Mika Liljeberg Hans Lippitsch John Loughney Jukka MJ Manner Janne Rinne Jussi Ruutu (Wednesday only) Vilho Räisänen Olov Schelen Marco Schneider Ove Strandberg Tapio Suihko Hannes Tschofenig Sven Van Den Bosch Lars Westerberg Robert Hancock Eleanor Hepworth Kristofer Wårell Please let me know if you are attending but not on the list. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 11:35:00 2002 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 LAA17690 for ; Fri, 17 May 2002 11:35:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13507 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 11:35:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12622; Fri, 17 May 2002 11:27:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12544 for ; Fri, 17 May 2002 11:27:42 -0400 (EDT) Received: from nausicaa.coritel.it (IDENT:root@[193.205.242.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17515 for ; Fri, 17 May 2002 11:27:23 -0400 (EDT) Received: from uniroma2.it ([160.80.82.21]) by nausicaa.coritel.it (8.11.2/8.11.2) with ESMTP id g4HFVBT09873 for ; Fri, 17 May 2002 17:31:11 +0200 Message-ID: <3CE5215B.BEA7EF3@uniroma2.it> Date: Fri, 17 May 2002 17:27:23 +0200 From: Stefano Salsano X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: multipart/mixed; boundary="------------6C9F7A344A18A65E2E836A66" Subject: [NSIS] [Fwd: I-D ACTION:draft-salsano-bgrpp-arch-00.txt] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------6C9F7A344A18A65E2E836A66 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------6C9F7A344A18A65E2E836A66 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nausicaa.coritel.it (8.11.2/8.11.2) with ESMTP id g4EF9gP22765; Tue, 14 May 2002 17:09:43 +0200 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA09883 for ietf-123-outbound.07@ietf.org; Tue, 14 May 2002 10:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA08714 for ; Tue, 14 May 2002 08:01:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14270 for ; Tue, 14 May 2002 08:01:13 -0400 (EDT) Message-Id: <200205141201.IAA14270@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-salsano-bgrpp-arch-00.txt Date: Tue, 14 May 2002 08:01:13 -0400 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Inter-domain QoS Signaling: the BGRP Plus Architecture Author(s) : S. Salsano et al. Filename : draft-salsano-bgrpp-arch-00.txt Pages : 16 Date : 13-May-02 DiffServ architecture provides a set of 'user plane' tools for IP QoS. Deployment of DiffServ is starting with static, single-domain solutions. Dynamic QoS and multi-domain QoS are still open issues, as witnessed by the activity of the IETF NSIS WG, related to the 'signaling plane'. In order to realize true end-to-end QoS services in the Internet, spanning multiple administrative domains, efficient and scalable signaling and resource control mechanisms are needed. This document describes a scalable inter-domain resource control architecture for DiffServ networks. The architecture is called BGRP Plus, as it extends the previously proposed BGRP framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-salsano-bgrpp-arch-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-salsano-bgrpp-arch-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-salsano-bgrpp-arch-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: <20020513142056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-salsano-bgrpp-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-salsano-bgrpp-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020513142056.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------6C9F7A344A18A65E2E836A66-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 11:47:28 2002 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 LAA18026 for ; Fri, 17 May 2002 11:47:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14127 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 11:47:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13959; Fri, 17 May 2002 11:42:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13928 for ; Fri, 17 May 2002 11:42:15 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17864 for ; Fri, 17 May 2002 11:42:00 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4HFdt316644; Fri, 17 May 2002 11:39:56 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 11:39:55 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4ADF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'sven.van_den_bosch@alcatel.be'" , john.loughney@nokia.com Cc: Ruediger.Geib@t-systems.com, nsis@ietf.org Subject: RE: [NSIS] RE: What's in the charter of NSIS Date: Fri, 17 May 2002 11:39:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FDB9.1301388E" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1FDB9.1301388E Content-Type: text/plain; charset="iso-8859-1" I think the distinction that can be made is that NSIS should be able to describe the QoS requirements, including resource constraining QoS specifications such as the Tspec. And, there should be an interaction with NSIS and admission control. However, there are other resources that may need to be provisioned for QoS such as filters, queues, etc., and we would really have to show a significant advantage in managing these resources with NSIS rather then one of the existing solutions. Gary > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: May 17, 2002 05:54 > To: john.loughney@nokia.com > Cc: Ruediger.Geib@t-systems.com; nsis@ietf.org > Subject: Re: [NSIS] RE: What's in the charter of NSIS > > > Ruediger, John, all, > > Would it be fair to say then that we can indicate in the > signaling that: > a. we want to reserve resources > b. how many we want of what type > but > c. without actually participating in the implementation or > saying how it > must be done. > > We can discuss next week if needed, > Sven. > > > > > > john.loughney@nokia.com on 15/05/2002 11:57:33 > > > > To: Ruediger.Geib@t-systems.com > > cc: nsis@ietf.org(bcc: Sven VAN DEN > BOSCH/BE/ALCATEL) > > > > Subject [NSIS] RE: What's in the charter of NSIS > : > > > > > > > Hi Rudiger, > > > > Furthermore, maybe someone does not want IntServ exactly, > > > but perhaps a certain characteristic of IntServ, say > > > bandwidth. > > > > What happens to the remainder of IntServ in that case? > > Would one have to signal empty parameters? No answer > > required if this will be discussed in Helsinki! > > My feeling is we should discuss what parts we signaling, > but we de-couple the signaling from the resource reservation. > > > > Then you could have > > > > > > Bandwidth Assurance over IntServ Networks > > > Bandwidth Assurance over MPLS Networks > > > Bandwidth Assurance over Over Provisioned Networks > > > Bandwidth Assurance over a Bandwidth Broker Network > > > > That BB definition issue must be settled. The "friends > > of BB" could provide an architecture outline by now, > > if they are not charged of entering the solution discussion. > > It would be helpful to have such a document (and I see > > by your other message that you aggree). Your above > > example in my words would be: > > > > BW Assurancee over MPLS using a BB > > BW Assurance over Over Provisoned Networks using a BB > > or in general: BW Assurance over a network using a BB > > > > BB's of separated domains may > > signal with each other without bothering which > > layers/technologies are supported by the domain > > in which each operates. This solves the problem > > you've mentioned below (with regard to signaling): > > As far as BB go, I don't think we need to completely > ignore them, however, I don't think we can make NSIS > a BB-centric archiecture. What I mean is that we cannot > mandate a BB architecure (i.e. - everyone who wants to > use an NSIS protocol MUST deploy a bandwidth broker.) > I see it more as something that the signaling can occur > without a BB, but we may be able to put the correct > hooks to allow those who want to deploy BBs to be able to > do so. > > To put it another way, I don't think that the IESG will > let us standardize Bandwidth Brokers, nor is that something > that I want to do. However, it is possible that NSIS > could support BBs, if they are present. > > 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 > ------_=_NextPart_001_01C1FDB9.1301388E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] RE: What's in the charter of NSIS

I think the distinction that can be made is that NSIS = should be able to
describe the QoS requirements, including resource = constraining QoS
specifications such as the Tspec. And, there should = be an interaction
with NSIS and admission control. However, there are = other resources that
may need to be provisioned for QoS such as filters, = queues, etc., and we
would really have to show a significant advantage in = managing these
resources with NSIS rather then one of the existing = solutions.

Gary
 

> -----Original Message-----
> From: sven.van_den_bosch@alcatel.be
> [mailto:sven.van_den_bosch@= alcatel.be]
> Sent: May 17, 2002 05:54
> To: john.loughney@nokia.com
> Cc: Ruediger.Geib@t-systems.com; = nsis@ietf.org
> Subject: Re: [NSIS] RE: What's in the charter = of NSIS
>
>
> Ruediger, John, all,
>
> Would it be fair to say then that we can = indicate in the
> signaling that:
> a. we want to reserve resources
> b. how many we want of what type
> but
> c. without actually participating in the = implementation or
> saying how it
> must be done.
>
> We can discuss next week if needed,
> Sven.
>
>
>
>
>
> john.loughney@nokia.com on 15/05/2002 = 11:57:33
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>   = To:          = Ruediger.Geib@t-systems.com       &nb= sp;            =
>          = ;            = ;            = ;            = ;            = ;    
>   = cc:          = nsis@ietf.org(bcc: Sven VAN = DEN           &nb= sp;   
>          = ;      = BOSCH/BE/ALCATEL)         &= nbsp;           &= nbsp;       
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>   = Subject      [NSIS] RE: What's in the charter = of NSIS      
>   = :            = ;            = ;            = ;            = ;          
>          = ;            = ;            = ;            = ;            = ;    
>
>
>
>
>
> Hi Rudiger,
>
> > > Furthermore, maybe someone does not = want IntServ exactly,
> > > but perhaps a certain characteristic = of IntServ, say
> > > bandwidth.
> >
> > What happens to the remainder of IntServ = in that case?
> > Would one have to signal empty parameters? = No answer
> > required if this will be discussed in = Helsinki!
>
> My feeling is we should discuss what parts we = signaling,
> but we de-couple the signaling from the = resource reservation.
>
> > >     Then you = could have
> > >
> > >  Bandwidth Assurance over = IntServ Networks
> > >  Bandwidth Assurance over MPLS = Networks
> > >  Bandwidth Assurance over Over = Provisioned Networks
> > >  Bandwidth Assurance over a = Bandwidth Broker Network
> >
> > That BB definition issue must be settled. = The "friends
> > of BB" could provide an architecture = outline by now,
> > if they are not charged of entering the = solution discussion.
> > It would be helpful to have such a = document (and I see
> > by your other message that you aggree). = Your above
> > example in my words would be:
> >
> > BW Assurancee over MPLS using a BB
> > BW Assurance over Over Provisoned Networks = using a BB
> > or in general: BW Assurance over a network = using a BB
> >
> > BB's of separated domains may
> > signal with each other without bothering = which
> > layers/technologies are supported by the = domain
> > in which each operates. This solves the = problem
> > you've mentioned below (with regard to = signaling):
>
> As far as BB go, I don't think we need to = completely
> ignore them, however, I don't think we can make = NSIS
> a BB-centric archiecture.  What I mean is = that we cannot
> mandate a BB architecure (i.e. - everyone who = wants to
> use an NSIS protocol MUST deploy a bandwidth = broker.)
> I see it more as something that the signaling = can occur
> without a BB, but we may be able to put the = correct
> hooks to allow those who want to deploy BBs to = be able to
> do so.
>
> To put it another way, I don't think that the = IESG will
> let us standardize Bandwidth Brokers, nor is = that something
> that I want to do.  However, it is = possible that NSIS
> could support BBs, if they are present.
>
> 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=
>

------_=_NextPart_001_01C1FDB9.1301388E-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 12:19:01 2002 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 MAA19551 for ; Fri, 17 May 2002 12:19:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17361 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 12:19:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17195; Fri, 17 May 2002 12:14:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17162 for ; Fri, 17 May 2002 12:14:15 -0400 (EDT) Received: from hawk.cs.ucla.edu (Hawk.CS.UCLA.EDU [131.179.128.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19412 for ; Fri, 17 May 2002 12:13:59 -0400 (EDT) Received: from [192.168.0.147] (user-119bqhl.biz.mindspring.com [66.149.234.53]) by hawk.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id g4HGCkt29068; Fri, 17 May 2002 09:12:46 -0700 (PDT) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Fri, 17 May 2002 09:12:41 -0700 Subject: Re: [NSIS] RE: What's in the charter of NSIS From: Lixia Zhang To: Gary Kenward , "'sven.van_den_bosch@alcatel.be'" , CC: , Message-ID: In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4ADF@zcard031.ca.nortel.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit On 5/17/02 8:39 AM, "Gary Kenward" wrote: > I think the distinction that can be made is that NSIS should be able to > describe the QoS requirements, including resource constraining QoS > specifications such as the Tspec. And, there should be an interaction > with NSIS and admission control. However, there are other resources that > may need to be provisioned for QoS such as filters, queues, etc., and we > would really have to show a significant advantage in managing these > resources with NSIS rather then one of the existing solutions. > > Gary Due to my teaching overload this quarter I have not been able to keep up with the email on this list, thus I've been refraining myself from commenting when occasionally I look up one or two msgs, since I know I wont be able to keep up with the follow-on discussion. But I cannot help throwing a comment on this specific one: NSIS stands for "Next Step in Signaling", not next step in QOS. I personally do NOT think a signaling protocol should involve itself into the definitions of what QOS requirements should be. QOS requirements may change over time, yet one wishes that the signaling protocol, which is used to carry the QOS requirements, does NOT have to change. Besides, there WILL be other uses of a signaling protocol other than QOS need. My understanding is that NSIS is chartered to look into the need for a signaling protocol, NOT the QOS requirement. My personal 2 cents, Lixia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 12:58:18 2002 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 MAA20839 for ; Fri, 17 May 2002 12:58:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18941 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 12:58:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18564; Fri, 17 May 2002 12:47:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18540 for ; Fri, 17 May 2002 12:47:08 -0400 (EDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20347 for ; Fri, 17 May 2002 12:46:52 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g4HGl7b17833; Fri, 17 May 2002 09:47:07 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA00790; Fri, 17 May 2002 16:47:07 GMT Date: Fri, 17 May 2002 16:47:07 GMT Message-Id: <200205171647.QAA00790@gra.isi.edu> To: john.loughney@nokia.com, lixia@CS.UCLA.EDU Subject: Re: [NSIS] RE: What's in the charter of NSIS Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Lixia wrote: ... *> *> But I cannot help throwing a comment on this specific one: NSIS stands for *> "Next Step in Signaling", not next step in QOS. *> *> I personally do NOT think a signaling protocol should involve itself into *> the definitions of what QOS requirements should be. *> QOS requirements may change over time, yet one wishes that the signaling *> protocol, which is used to carry the QOS requirements, does NOT have to *> change. *> *> Besides, there WILL be other uses of a signaling protocol other than QOS *> need. My understanding is that NSIS is chartered to look into the need for *> a signaling protocol, NOT the QOS requirement. *> I want to say "amen" to all of that. The original message from Gary Kenward included, "... QoS specifications such as the Tspec." The Tspec is not by itself a QoS specification. In fact, even talking about "a QoS specification" is to oversimplify a complex process, which may involve two passes, one pass with advertising, etc. There are many possible QoS models; int-serv chose just two of them. And NSIS should choose NONE of them; a next-generation signaling protocol should be able to handle any future model. This observation, together with Lixia's comment, leads me to the realization that RSVP may have had the modularity wrong (and NSIS might pay attention to this point). RSVP design and specification may ahve talked too much about int-serv specific things like Tspecs. We should instead have defined RSVP strictly in terms of transporting opaque QoS objects upstream and downstream, and applying some model-specific algorithms at merge and branch points. The definition of these objects and algorithms would then be completely contained in documents that define QoS models. Our vision was imperfect when we began the Internet integrated services work in 1993. If we had gotten the modularity better, we would perhaps have avoided some of the immense amount of misunderstanding that is still current about Internet QoS issues. BTW, see draft-braden-2level-signal-arch-00.txt for a glimmer of a better modularity. Bob Braden *> My personal 2 cents, *> Lixia *> *> *> _______________________________________________ *> 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 daemon@optimus.ietf.org Fri May 17 13:23:48 2002 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 NAA22137 for ; Fri, 17 May 2002 13:23:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20396 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 13:24:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20147; Fri, 17 May 2002 13:15:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20114 for ; Fri, 17 May 2002 13:15:46 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21705 for ; Fri, 17 May 2002 13:15:30 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4HHEQ324228; Fri, 17 May 2002 13:14:26 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 13:14:26 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4AE1@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Bob Braden'" , john.loughney@nokia.com, lixia@CS.UCLA.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] RE: What's in the charter of NSIS Date: Fri, 17 May 2002 13:14:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FDC6.47A196EE" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1FDC6.47A196EE Content-Type: text/plain; charset="iso-8859-1" It is a valid observation that my point was very much into the detail. However, it had nothing to do with how Int Serv, Diff Serv or any other QoS model happens to work. It had everything to do with the on-going thread as to whether NSIS was chartered to look at resource allocation (which is not). I was simply attempting to draw a distinction between QoS specification and resource allocation. In no way did I intend d to imply, nor do I believe that I actually implied, that NSIS was building the next QoS "model". As for the point that Lixia was making, I think it is a valid one, However, correct me if I am wrong here, but the charter states: "This working group will develop the requirements, architecture and protocols for the next IETF steps on signalling QoS. The working group will use existing IETF signalling as the basis for this work, evaluating RSVP in particular as the starting point. Additionally, the working group will consider how to signal QoS (what sort of QoS parameters to use), and where to signal (end-to-end, end-to-edge, end-to-proxy, edge-to-edge, etc.)." Sounds like NSIS is really NSIQoSS, if one was to worry about names (a rose is a rose . . .). Finally, I do agree that NSIS should absolutely be defined with some attention to future needs, as long as we keep it real. Predicting the future is neither easy, nor reliable. Cheers, Gary > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: May 17, 2002 12:47 > To: john.loughney@nokia.com; lixia@CS.UCLA.EDU > Cc: nsis@ietf.org > Subject: Re: [NSIS] RE: What's in the charter of NSIS > > > > Lixia wrote: > > ... > > *> > *> But I cannot help throwing a comment on this specific > one: NSIS stands for > *> "Next Step in Signaling", not next step in QOS. > *> > *> I personally do NOT think a signaling protocol should > involve itself into > *> the definitions of what QOS requirements should be. > *> QOS requirements may change over time, yet one wishes > that the signaling > *> protocol, which is used to carry the QOS requirements, > does NOT have to > *> change. > *> > *> Besides, there WILL be other uses of a signaling > protocol other than QOS > *> need. My understanding is that NSIS is chartered to > look into the need for > *> a signaling protocol, NOT the QOS requirement. > *> > > I want to say "amen" to all of that. > > The original message from Gary Kenward included, "... QoS > specifications such as the Tspec." The Tspec is not by itself a QoS > specification. In fact, even talking about "a QoS > specification" is to > oversimplify a complex process, which may involve two passes, one pass > with advertising, etc. There are many possible QoS models; int-serv > chose just two of them. And NSIS should choose NONE of them; a > next-generation signaling protocol should be able to handle any future > model. > > This observation, together with Lixia's comment, leads me to the > realization that RSVP may have had the modularity wrong (and > NSIS might > pay attention to this point). RSVP design and specification may ahve > talked too much about int-serv specific things like Tspecs. We should > instead have defined RSVP strictly in terms of transporting opaque QoS > objects upstream and downstream, and applying some model-specific > algorithms at merge and branch points. The definition of > these objects > and algorithms would then be completely contained in documents that > define QoS models. > > Our vision was imperfect when we began the Internet > integrated services > work in 1993. If we had gotten the modularity better, we > would perhaps > have avoided some of the immense amount of misunderstanding that is > still current about Internet QoS issues. > > BTW, see draft-braden-2level-signal-arch-00.txt for a glimmer of a > better modularity. > > Bob Braden > > > > > *> My personal 2 cents, > *> Lixia > *> > *> > *> _______________________________________________ > *> 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 > ------_=_NextPart_001_01C1FDC6.47A196EE Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] RE: What's in the charter of NSIS

It is a valid observation that my point was very much into the
detail. However, it had nothing to do with how Int Serv, Diff
Serv or any other QoS model happens to work. It had everything
to do with the on-going thread as to whether NSIS was chartered
to look at resource allocation (which is not). I was simply attempting
to draw a distinction between QoS specification and resource allocation.
In no way did I intend d to imply, nor do I believe that I actually implied,
that NSIS was building the next QoS "model".

As for the point that Lixia was making, I think it is a valid one,
However, correct me if I am wrong here, but the charter states:

"This working group will develop the requirements, architecture and
protocols for the next IETF steps on signalling QoS. The working group
will use existing IETF signalling as the basis for this work, evaluating
RSVP in particular as the starting point. Additionally, the working
group will consider how to signal QoS (what sort of QoS parameters to
use), and where to signal (end-to-end, end-to-edge, end-to-proxy,
edge-to-edge, etc.)."

Sounds like NSIS is really NSIQoSS, if one was to worry about names
(a rose is a rose . . .).

Finally, I do agree that NSIS should absolutely be defined with some
attention to future needs, as long as we keep it real. Predicting
the future is neither easy, nor reliable.

Cheers,
Gary

> -----Original Message-----
> From: Bob Braden [mailto:braden@ISI.EDU]
> Sent: May 17, 2002 12:47
> To: john.loughney@nokia.com; lixia@CS.UCLA.EDU
> Cc: nsis@ietf.org
> Subject: Re: [NSIS] RE: What's in the charter of NSIS
>
>
>
> Lixia wrote:
>
> ...
>
>   *>
>   *> But I cannot help throwing a comment on this specific
> one: NSIS stands for
>   *> "Next Step in Signaling", not next step in QOS.
>   *>
>   *> I personally do NOT think a signaling protocol should
> involve itself into
>   *> the definitions of what QOS requirements should be.
>   *> QOS requirements may change over time, yet one wishes
> that the signaling
>   *> protocol, which is used to carry the QOS requirements,
> does NOT have to
>   *> change.
>   *>
>   *> Besides, there WILL be other uses of a signaling
> protocol other than QOS
>   *> need.  My understanding is that NSIS is chartered to
> look into the need for
>   *> a signaling protocol, NOT the QOS requirement.
>   *>
>
> I want to say "amen" to all of that.
>
> The original message from Gary Kenward included, "... QoS
> specifications such as the Tspec." The Tspec is not by itself a QoS
> specification.  In fact, even talking about "a QoS
> specification" is to
> oversimplify a complex process, which may involve two passes, one pass
> with advertising, etc.  There are many possible QoS models; int-serv
> chose just two of them.  And NSIS should choose NONE of them; a
> next-generation signaling protocol should be able to handle any future
> model.
>
> This observation, together with Lixia's comment, leads me to the
> realization that RSVP may have had the modularity wrong (and
> NSIS might
> pay attention to this point).  RSVP design and specification may ahve
> talked too much about int-serv specific things like Tspecs.  We should
> instead have defined RSVP strictly in terms of transporting opaque QoS
> objects upstream and downstream, and applying some model-specific
> algorithms at merge and branch points.  The definition of
> these objects
> and algorithms would then be completely contained in documents that
> define QoS models.
>
> Our vision was imperfect when we began the Internet
> integrated services
> work in 1993.  If we had gotten the modularity better, we
> would perhaps
> have avoided some of the immense amount of misunderstanding that is
> still current about Internet QoS issues.
>
> BTW, see draft-braden-2level-signal-arch-00.txt for a glimmer of a
> better modularity.
>
> Bob Braden
>
>
>
>
>   *> My personal 2 cents,
>   *> Lixia
>   *>
>   *>
>   *> _______________________________________________
>   *> 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
>

------_=_NextPart_001_01C1FDC6.47A196EE-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 13:24:42 2002 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 NAA22225 for ; Fri, 17 May 2002 13:24:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20435 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 13:24:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19634; Fri, 17 May 2002 13:05:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19603 for ; Fri, 17 May 2002 13:05:20 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21186 for ; Fri, 17 May 2002 13:05:04 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4HH4GHs013000; Fri, 17 May 2002 10:04:16 -0700 (PDT) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADX07498; Fri, 17 May 2002 10:00:56 -0700 (PDT) Message-Id: <5.1.0.14.0.20020517125908.0131cc70@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 17 May 2002 13:08:19 -0400 To: Bob Braden , john.loughney@nokia.com, lixia@CS.UCLA.EDU From: Melinda Shore Subject: Re: [NSIS] RE: What's in the charter of NSIS Cc: nsis@ietf.org In-Reply-To: <200205171647.QAA00790@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org At 04:47 PM 5/17/02 +0000, Bob Braden wrote: >This observation, together with Lixia's comment, leads me to the >realization that RSVP may have had the modularity wrong (and NSIS might >pay attention to this point). RSVP design and specification may ahve >talked too much about int-serv specific things like Tspecs. I've written a document describing the use of RSVP for firewall traversal and NAT traversal (which I'll be sending to the secretariat next week) and another describing the use of of RSVP for IPSec tunnel endpoint discovery and rudimentary SDB management ("don't encapsulate this"). The latter will probably not be submitted in its current form but was interesting to write. What I found was 1) the RSVP protocol machinery is *extremely* well suited to addressing generic middlebox problems, and 2) exactly what you're saying - some of the required data are inapplicable to generic middlebox problems (this may apply to the rich variety of reservation styles, as well). I think that a number of the proposed middlebox "solutions" share the same problem, and that is that by violating protocol layers to have, say, applications try to influence network-layer services you're introducing some nasty topological problems, that you can avoid by using a protocol like RSVP. As a sort of a side note, one of the principal anti-RSVP arguments, resource utilization, doesn't apply to the middlebox problem because the middleboxes in question [firewall, NAT] tend to be very highly stateful and RSVP would tend to be manipulating existing state rather than introducing new state. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 17 14:03:15 2002 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 OAA24472 for ; Fri, 17 May 2002 14:03:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23125 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 14:03:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22057; Fri, 17 May 2002 13:49:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22026 for ; Fri, 17 May 2002 13:49:53 -0400 (EDT) Received: from hawk.cs.ucla.edu (Hawk.CS.UCLA.EDU [131.179.128.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23873 for ; Fri, 17 May 2002 13:49:37 -0400 (EDT) Received: from [192.168.0.147] (user-1121ck4.dsl.mindspring.com [66.32.178.132]) by hawk.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id g4HHmet29420; Fri, 17 May 2002 10:48:41 -0700 (PDT) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Fri, 17 May 2002 10:48:35 -0700 Subject: Re: [NSIS] RE: What's in the charter of NSIS From: Lixia Zhang To: Gary Kenward , "'Bob Braden'" , CC: Message-ID: In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4AE1@zcard031.ca.nortel.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit On 5/17/02 10:14 AM, "Gary Kenward" wrote: > It is a valid observation that my point was very much into the > detail. However, it had nothing to do with how Int Serv, Diff > Serv or any other QoS model happens to work. It had everything > to do with the on-going thread as to whether NSIS was chartered > to look at resource allocation (which is not). I was simply attempting > to draw a distinction between QoS specification and resource allocation. > In no way did I intend d to imply, nor do I believe that I actually implied, > that NSIS was building the next QoS "model". > > As for the point that Lixia was making, I think it is a valid one, > However, correct me if I am wrong here, but the charter states: > > "This working group will develop the requirements, architecture and > protocols for the next IETF steps on signalling QoS. I personally believe that statement is an inaccurate description of NSIS's goal, it's inconsistent with prior discussions that led to the birth of this WG (of course there is also a possibility that I understood incorrectly). I brought up this issue with the area ADs earlier. I fully agree that this issue needs to be clarified. > The working group > will use existing IETF signalling as the basis for this work, evaluating > RSVP in particular as the starting point. Additionally, the working > group will consider how to signal QoS (what sort of QoS parameters to > use), and where to signal (end-to-end, end-to-edge, end-to-proxy, > edge-to-edge, etc.)." > > Sounds like NSIS is really NSIQoSS, if one was to worry about names > (a rose is a rose . . .). > > Finally, I do agree that NSIS should absolutely be defined with some > attention to future needs, as long as we keep it real. Predicting > the future is neither easy, nor reliable. > > Cheers, > Gary _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri May 17 14:20:28 2002 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 OAA25522 for ; Fri, 17 May 2002 14:20:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23705 for nsis-archive@odin.ietf.org; Fri, 17 May 2002 14:20:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23383; Fri, 17 May 2002 14:08:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23349 for ; Fri, 17 May 2002 14:08:56 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24776 for ; Fri, 17 May 2002 14:08:39 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 14:03:24 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9315C@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'john.loughney@nokia.com'" , sven.van_den_bosch@alcatel.be Cc: Ruediger.Geib@t-systems.com, nsis@ietf.org Subject: RE: [NSIS] RE: What's in the charter of NSIS Date: Fri, 17 May 2002 14:03:19 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Since whatever is requesting service cannot know how exactly resources are measured or managed I think that (b) should be expressed in terms of QoS requirements/parameters of the data flow the service is requested for. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Friday, May 17, 2002 8:47 AM To: sven.van_den_bosch@alcatel.be Cc: Ruediger.Geib@t-systems.com; nsis@ietf.org Subject: RE: [NSIS] RE: What's in the charter of NSIS Hi, > Would it be fair to say then that we can indicate in the > signaling that: > a. we want to reserve resources > b. how many we want of what type but > c. without actually participating in the implementation or > saying how it must be done. I think that a. could be re-worded to state: a. We want a service, which could be a resource reservation or require resource reservation. 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 daemon@optimus.ietf.org Sat May 18 06:11:35 2002 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 GAA07337 for ; Sat, 18 May 2002 06:11:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA09047 for nsis-archive@odin.ietf.org; Sat, 18 May 2002 06:11:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08961; Sat, 18 May 2002 06:06:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08929 for ; Sat, 18 May 2002 06:06:10 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07263 for ; Sat, 18 May 2002 06:05:53 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 18 May 2002 11:05:03 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED418045952F0@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Sat, 18 May 2002 11:05:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [NSIS] a very small framework draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" dear all, we have made a little draft about what sort of things need to be in an NSIS framework, as well as some modest assumptions about how the NSIS signalling protocols might relate to 'other things' (like resource management...). in some ways, it's a prequel to the framework draft we discussed at minneapolis. it is (we hope) working its way through the i-d system, in the meantime you can get it from http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-outline-00.txt best news of all: not counting the trimmings at each end, it's only 11 pages long! see you all in helsinki, robert h. ======================================================================= Abstract The Next-Steps-in-Signalling (NSIS) working group of the IETF is considering the requirements for QoS signalling protocols [2]. One element of this, and follow up work, is to develop a framework within which existing and proposed protocols can be analysed, and which captures how QoS signalling protocols should interact, both with each other and with other components of the Internet, such as routing protocols or AAA mechanisms. Because of this aspect of interactions, the scope of an NSIS framework is necessarily broader than the scope of any new NSIS protocol. Previous work suggests that a complete QoS signalling framework is a major undertaking. This Internet Draft outlines the principal components of such a framework and their interrelationships. It could be used as a starting point for more detailed investigation of individual components. It could also be used to refine the scope of NSIS more precisely, both in terms of what functions are to be considered and how many variant approaches are relevant. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun May 19 07:01:50 2002 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 HAA02723 for ; Sun, 19 May 2002 07:01:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01074 for nsis-archive@odin.ietf.org; Sun, 19 May 2002 07:02:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00318; Sun, 19 May 2002 06:55:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00283 for ; Sun, 19 May 2002 06:55:04 -0400 (EDT) Received: from my-public.sc.cninfo.net ([61.139.33.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02502 for ; Sun, 19 May 2002 06:54:47 -0400 (EDT) Received: from ahlj([61.188.244.235]) by my-public.sc.cninfo.net(AIMC 2.9.5.2) with SMTP id jm123ce7b528; Sun, 19 May 2002 18:51:24 +0800 Message-ID: <000801c1ff25$d6afc1c0$0100a8c0@61.139.8.6> From: "ahl" To: Date: Sun, 19 May 2002 19:10:51 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1FF68.E4883D20" 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 Subject: [NSIS] invitation Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1FF68.E4883D20 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SU5WSVRBVElPTiANCg0KRGVhciAgRGlzdGluZ3Vpc2hlZCAgQ29sbGVhZ3VlcyANCg0KQXBwcm92 ZWQgYnkgdGhlIGdvdmVybm1lbnQgb2YgdGhlIFBlb3BsZaGvcyBSZXB1YmxpYyBvZiBDaGluYSB0 aGUgSW50ZXJuYXRpb25hbCBTeW1wb3NpdW0gb24gRmVtYWxlIGFudGhyb3BvbG9neSBhbmQgTWF0 cmlhcmNoYWwgQ3VsdHVyZSBpbiB0aGUgV29tZW4tZG9taW5hdGluZyBLaW5nZG9tIGFyb3VuZCB0 aGUgTHVndSBMYWtlIGlzIHRvIGJlIGhlbGQgb24gTWFyY2ggOHRoIHRvIDEydGgsIDIwMDMgaW4g dGhlIGFuY2llbnQgY2l0eSwgTGlqaWFuZyAoZml4ZWQgZm9yIHRpbWUgYmVpbmcpLCB3aGljaCBp cyBuYW1lZCBjdWx0dXJhbCBoZXJpdGFnZSBvZiB0aGUgd29ybGQgYnkgdGhlIFVuaXRlZCBOYXRp b25zLiAoQ2xvc2luZyBjZXJlbW9ueSBvZiBzeW1wb3NpdW0gYW5kIHNvY2lhbCBpbnZlc3RpZ2F0 aW9uICAgd2lsbCBiZSBkb25lIGFyb3VuZCB0aGUgTHVndSBMYWtlKS4gDQoNCkFyb3VuZCB0aGUg THVndSBMYWtlIGJldHdlZW4gWXVubmFuIGFuZCBTaWNodWFuIFByb3ZpbmNlcyB0aGVyZSBhcmUg TW9zdW8gcGVvcGxlIGxpdmluZyBpbiBhbmQgc3RpbGwgaGF2ZSBrZXB0IGEgc3BlY2lhbCAgd2F5 ICBvZiAgb3JnYW5pemluZyB0aGVpciBmYW1pbGllcywgaGF2aW5nICBsb3ZlICBhZmZhaXJzICBh bmQgIG1hcnJpYWdlLiBUaGUgaG91c2V3aWZlIGRvbWluYXRlcyBmYW1pbHkgYW5kIGNoaWxkcmVu LiBJbiAgdGhpcyAgYXJlYSAgd2hlcmUgIGV2ZXJ5dGhpbmcgIGlzIGRvbWluYXRlZCAgYnkgd29t ZW4sIHRoZXJlIGlzICBubyAgcGF0cmlhcmNoeSAgYW5kICB0aGUgZmVtYWxlIGFuZCAgbWFsZSBh cmUgIGVxdWFsICBvbiAgY29uZGl0aW9uIHRoYXQgd29tZW4gYXJlIG1hc3RlcnMgb2YgdGhlICBm YW1pbHkuIFRoZXkgICBwcmFjdGljZSAgcHJlbGltaW5hcnksIHJvbWFudGljICBhbmQgc2ltcGxl IG1hcnJpYWdlIHN5c3RlbSAgdGhhdCAgaXMgY2FsbGVkIEF4aWEgdmlzaXRpbmctbWFycmlhZ2Ug KGFjdHVhbGx5IG5vIG1hcnJpYWdlIHN5c3RlbSBhdCBhbGwpLlRoZSB2aXNpdGluZyBtYXJyaWFn ZSAgZGV2ZWxvcGVkICB0aGUgc2FmZSAgYW5kICBlcXVhbCAgc2V4LCAgdGhlICBmYW1pbHkgIHdp dGhvdXQgZmF0aGVyIGFuZCBodXNiYW5kLiBUaGUgZnV0dXJlIG9mIHRoZSBmYW1pbHkgYmVsb25n cyB0byB0aGUgZ2lybHMuIFNvICBpdCdzICB0aGUgICBsaXZpbmcgZm9zc2lsICBmb3IgIHRoZSBz dHVkeSAgb2YgIHRoZSBkZXZlbG9wbWVudCAgb2YgIHRoZSAgaHVtYW4gYmVpbmcgIHNvY2lldHkg IG9yICBjYWxsZWQgIHRoZSAgTHVndSAgTGFrZSAgV29tZW4tZG9taW5hdGluZyAga2luZ2RvbS4u IA0KDQpJbiB0aGlzIGtpbmdkb20sIG5laXRoZXIgbWFsZSBkb21pbmF0ZSBmZW1hbGUgbm9yIGZl bWFsZSBkb21pbmF0ZSBtYWxlIGluIHRoZSBmYW1pbHksIGhvd2V2ZXIgaXQncyAgYSBzcGVjaWFs IHNvY2lldHkgIG1vZGVsIHRoYXQgIGlzICBwYXJ0bmVyo61zaGlwIGluc3RlYWQgb2YgZG9taW5h dGlvbiBzeXN0ZW0uIFRoZSBNb3N1byBjb21tdW5pdHkgd2FzIGdpdmVuIHRoZSB0aXRsZSBvZiBt b2RlbCBjb21tdW5pdHkgYXQgIHRoZSAgb2NjYXNpb24gIG9mICB0aGUgIDUwdGggYW5uaXZlcnNh cnkgIG9mICB0aGUgVW5pdGVkIE5hdGlvbnMuICBOb3cgdGhlICBMdWd1ICBMYWtlICBpcyAgbGlz dGVkICBpbiAgdGhlICB0b3VyaXN0ICBhcmVhICBvZiAgdGhlIE5hdGlvbmFsICBsZXZlbC4gVGhl IHNwZWNpYWwgcmVsYXRpb24gYmV0d2VlbiBtZW4gYW5kIHdvbWVuLCBhbmQgc29jaWV0eSBtb2Rl bCBwcm92aWRlIHR5cGljYWwgc2l0dWF0aW9uIGFuZCB2YWx1YWJsZSBtYXRlcmlhbHMgZm9yICB0 aGUgc3R1ZHkgIG9mICBodW1hbiBzb2NpZXR5LCByZWxhdGlvbiAgYmV0d2VlbiAgbWVuICBhbmQg IHdvbWVuLCBzdGF0dXMgYW5kIHJpZ2h0cyBvZiB3b21lbiwgbWFycmlhZ2UgYW5kIGZhbWlsaWVz LiBUbyBrbm93IG90aGVycyBmb3Iga25vd2luZyBvdXJzZWx2ZXMgYW5kIGtub3cgdGhlIHBhc3Qg Zm9yIHRvZGF5IGFuZCB0b21vcnJvdy4gSXQgaXMgc28gaW50ZXJlc3RpbmcgYSB0b3BpYyB0aGF0 IEkgaG9wZSB0aGF0IHdlIGNhbiAgam9pbnRseSAgc3BvbnNvciAgYW4gaW50ZXJuYXRpb25hbCBz eW1wb3NpdW0gIG9uICBmZW1hbGUgIHNvY2lvbG9neSAgYW5kICBPcmllbnRhbCAgV29tZW4tZG9t aW5hdGluZyBLaW5nZG9tLiANCg0KTm93YWRheXMsICB3b21lbiBhcmUgc3RpbGwgaW4gdGhlIHN0 YXRlICBpbiAgd2hpY2ggdGhleSAgYXJlICBhdHRhY2hlZCB0byBtZW4gaW4gcG9saXRpY2FsLCBl Y29ub21pYyBwb3NpdGlvbiBhbmQgc2V4dWFsIGxpZmUuIE1hbnkgd29tZW4gIGluIHRoZSB3b3Js ZCBhcmUgbG9va2VkIGRvd24gdXBvbiBhbmQgaWxsLXRyZWF0ZWQuIEluIHNvbWUgY291bnRyaWVz IGFuZCBhcmVhcyBmZW1hbGUgY2hpbGRyZW4gIGFyZSAgZmFjaW5nICB0aGUgIHByb2JsZW0gb2Yg IGxpdmluZy4gSWYgd2UgZG8gIG5vdCBwYXkgIHNwZWNpYWwgIGF0dGVudGlvbiAgdG8gaXQsIHRo ZSAgc2V4dWFsIGJhbmFuYSAgb2YgIGZlbWFsZSAgYW5kICBtYWxlIHdpbGwgYmUgbG9zdC4gQnV0 IEh1bWFuaXRhcmlhbmlzbSBhbmQgaHVtYW4gcmlnaHRzIGFyZSBmb3VuZCBhbmQgIGluIGZ1bGwg c3dpbmcgaW4gdGhpcyBjb21tdW5pdHkuIFRoZSAgbWF0cmlhcmNoYWwgIGZhbWlsaWVzICBwcm92 aWRlICB1cyB3aXRoICBtdWNoIHRoYXQgd2UgIGNhbiAgbWFrZSB1c2Ugb2YgIGl0IHNvbHZpbmcg ICB0aGUgIHByb2JsZW1zICBpbiAgbW9kZXJuIHdvcmxkLiBJdCAgaXMgIGFsc28gIGFuICBpbnNw aXJhdGlvbiAgdG8gIHVzICBhYm91dCAgdGhlICBtYXJyaWFnZSAgYW5kICBmYW1pbHkgIGluICB0 aGUgIGZ1dHVyZS4gSWYgd2UgbWFrZSBhIHN0dWR5IGFib3V0IGludGVycGVyc29uYWwgcmVsYXRp b25zIGFuZCBzZXh1YWwgcGFydG5lcnMgIGluICB0aGUgIE1vc3VvICBjb21tdW5pdHksIGl0ICB3 aWxsICBzaG93ICBwcm9mb3VuZCAgZ3JlYXQgc2lnbmlmaWNhbmNlICBpbiAgcmVjb2duaXppbmcg IHdvbWVuLCAgcHJvbW90aW5nICAgdGhlICAgZXF1YWxpdHkgICBvZiAgd29tZW4gIGFuZCAgbWVu LiANCg0KV2l0aCAgYmVzdCAgd2lzaGVzISANCg0KQWhhaSBMdWppbiANCg0KUmVzZWFyY2ggZmVs bG93IG9mIGZlbWFsZSBhbnRocm9wb2xvZ3kgYW5kIHNleHVhbCBzb2Npb2xvZ3kgDQoNClByZXNp ZGVudCBvZiBJbnRlcm5hdGlvbmFsIFN5bXBvc2l1bSBvbiBGZW1hbGUgQW50aHJvcG9sb2d5ICYg TWF0cmlhcmNoYWwgQ3VsdHVyZSBpbiB0aGUgV29tZW4ncy1Eb21pbmF0aW5nIEtpbmdkb20gYXJv dW5kIHRoZSBMdWd1IExha2UgDQoNCk5PVEVTDQoNClBsZWFzZSBjb25zdWx0IEUtbWFpbCBhbmQg aHR0cDovL3d3dy5MdWd1LUxha2UuY29tIHRvIGtub3cgdGhlIGRldGFpbGVkIGluZm9ybWF0aW9u IGFib3V0IHRoZSBzeW1wb3NpdW0sIHN1Y2ggYXMgaGUgc2NoZWR1bGUsIHRyYW5zcG9ydGF0aW9u LCB0b3VyaXNtLCBhY2NvbW1vZGF0aW9ucywgZHVlcyBhbmQgc28gb24uDQoNCg== ------=_NextPart_000_0005_01C1FF68.E4883D20 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj4NCjxESVY+PEZPTlQgc2l6 ZT0yPg0KPFAgYWxpZ249Y2VudGVyIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iVEVYVC1BTElH TjogY2VudGVyIj48Qj48U1BBTiANCmxhbmc9RU4tVVMgDQpzdHlsZT0iQ09MT1I6IGJsdWU7IEZP TlQtRkFNSUxZOiAnTW9ub3R5cGUgQ29yc2l2YSc7IEZPTlQtU0laRTogMjJwdDsgbXNvLWJpZGkt Zm9udC1zaXplOiAxMC41cHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+SU5WSVRBVElP TiANCjwvU1BBTj48L0I+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxCPjxTUEFOIGxhbmc9 RU4tVVMgDQpzdHlsZT0iQ09MT1I6IHJlZDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4n OyBGT05ULVNJWkU6IDE0cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuNXB0Ij5EZWFyPFNQQU4g DQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+RGlzdGluZ3Vpc2hlZDxT UEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPkNvbGxlYWd1ZXMg PC9TUEFOPjwvQj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgDQpzdHlsZT0iVEVYVC1BTElH TjoganVzdGlmeTsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgiPjxTUEFOIGxhbmc9RU4t VVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj5BcHByb3ZlZCBieSB0 aGUgZ292ZXJubWVudCBvZiB0aGUgDQpQZW9wbGWhr3MgUmVwdWJsaWMgb2YgQ2hpbmEgdGhlIElu dGVybmF0aW9uYWwgU3ltcG9zaXVtIG9uIEZlbWFsZSBhbnRocm9wb2xvZ3kgDQphbmQgTWF0cmlh cmNoYWwgQ3VsdHVyZSBpbiB0aGUgV29tZW4tZG9taW5hdGluZyBLaW5nZG9tIGFyb3VuZCB0aGUg THVndSBMYWtlIGlzIA0KdG8gYmUgaGVsZCBvbiBNYXJjaCA4dGggdG8gMTJ0aCwgMjAwMyBpbiB0 aGUgYW5jaWVudCBjaXR5LCBMaWppYW5nIChmaXhlZCBmb3IgDQp0aW1lIGJlaW5nKSwgd2hpY2gg aXMgbmFtZWQgY3VsdHVyYWwgaGVyaXRhZ2Ugb2YgdGhlIHdvcmxkIGJ5IHRoZSBVbml0ZWQgDQpO YXRpb25zLiAoQ2xvc2luZyBjZXJlbW9ueSBvZiBzeW1wb3NpdW0gYW5kIHNvY2lhbCBpbnZlc3Rp Z2F0aW9uPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyA8L1NQ QU4+d2lsbCBiZSBkb25lIGFyb3VuZCB0aGUgTHVndSANCkxha2UpLiA8L1NQQU4+PC9QPg0KPFAg Y2xhc3M9TXNvUGxhaW5UZXh0IA0Kc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnk7IFRFWFQtSlVT VElGWTogaW50ZXItaWRlb2dyYXBoIj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFN SUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+QXJvdW5kIHRoZSBMdWd1IExha2UgYmV0d2VlbiBZdW5u YW4gYW5kIA0KU2ljaHVhbiBQcm92aW5jZXMgdGhlcmUgYXJlIE1vc3VvIHBlb3BsZSBsaXZpbmcg aW4gYW5kIHN0aWxsIGhhdmUga2VwdCBhIA0Kc3BlY2lhbDxTUEFOIHN0eWxlPSJtc28tc3BhY2Vy dW46IHllcyI+Jm5ic3A7IDwvU1BBTj53YXk8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7IDwvU1BBTj5vZjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 IA0KPC9TUEFOPm9yZ2FuaXppbmcgdGhlaXIgZmFtaWxpZXMsIGhhdmluZzxTUEFOIHN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7IA0KPC9TUEFOPmxvdmU8U1BBTiBzdHlsZT0ibXNvLXNw YWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+YWZmYWlyczxTUEFOIA0Kc3R5bGU9Im1zby1zcGFj ZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPmFuZDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj4mbmJzcDsgPC9TUEFOPm1hcnJpYWdlLiBUaGUgaG91c2V3aWZlIGRvbWluYXRlcyBmYW1p bHkgDQphbmQgY2hpbGRyZW4uIEluPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsgPC9TUEFOPnRoaXM8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwv U1BBTj5hcmVhPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+ d2hlcmU8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5ldmVy eXRoaW5nPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+aXMg ZG9taW5hdGVkPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+ Ynkgd29tZW4sIHRoZXJlIGlzPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L1NQQU4+bm88U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyANCjwvU1BB Tj5wYXRyaWFyY2h5PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFO PmFuZDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPnRoZSBm ZW1hbGUgYW5kPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+ bWFsZSBhcmU8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5l cXVhbDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPm9uPFNQ QU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgDQo8L1NQQU4+Y29uZGl0aW9uIHRo YXQgd29tZW4gYXJlIG1hc3RlcnMgb2YgdGhlPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyA8L1NQQU4+ZmFtaWx5LiBUaGV5PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyA8L1NQQU4+cHJhY3RpY2U8U1BBTiANCnN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5wcmVsaW1pbmFyeSwgcm9tYW50aWM8U1BBTiANCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5hbmQgc2ltcGxlIG1hcnJpYWdl IHN5c3RlbTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPnRo YXQ8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5pcyBjYWxs ZWQgQXhpYSB2aXNpdGluZy1tYXJyaWFnZSANCihhY3R1YWxseSBubyBtYXJyaWFnZSBzeXN0ZW0g YXQgYWxsKS5UaGUgdmlzaXRpbmcgbWFycmlhZ2U8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7IDwvU1BBTj5kZXZlbG9wZWQ8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7IDwvU1BBTj50aGUgc2FmZTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj4mbmJzcDsgPC9TUEFOPmFuZDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDsgPC9TUEFOPmVxdWFsPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L1NQQU4+c2V4LDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9T UEFOPnRoZTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPmZh bWlseTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPndpdGhv dXQgZmF0aGVyIGFuZCBodXNiYW5kLiBUaGUgZnV0dXJlIA0Kb2YgdGhlIGZhbWlseSBiZWxvbmdz IHRvIHRoZSBnaXJscy4gU288U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyAN CjwvU1BBTj5pdCdzPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFO PnRoZTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgPC9TUEFO PmxpdmluZyBmb3NzaWw8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwv U1BBTj5mb3I8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj50 aGUgc3R1ZHk8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5v ZjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IA0KPC9TUEFOPnRoZSBkZXZl bG9wbWVudDxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5vZjxT UEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPnRoZTxTUEFOIA0K c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPmh1bWFuIGJlaW5nPFNQQU4g DQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+c29jaWV0eTxTUEFOIA0K c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPm9yPFNQQU4gc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgDQo8L1NQQU4+Y2FsbGVkPFNQQU4gc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPnRoZTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDsgPC9TUEFOPkx1Z3U8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7IDwvU1BBTj5MYWtlPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOyA8L1NQQU4+V29tZW4tZG9taW5hdGluZzxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj4mbmJzcDsgPC9TUEFOPmtpbmdkb20uLiA8L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxh aW5UZXh0IA0Kc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnk7IFRFWFQtSlVTVElGWTogaW50ZXIt aWRlb2dyYXBoIj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJyI+SW4gdGhpcyBraW5nZG9tLCBuZWl0aGVyIG1hbGUgZG9taW5hdGUgDQpmZW1h bGUgbm9yIGZlbWFsZSBkb21pbmF0ZSBtYWxlIGluIHRoZSBmYW1pbHksIGhvd2V2ZXIgaXQnczxT UEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPmEgc3BlY2lhbCBz b2NpZXR5PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+bW9k ZWwgdGhhdDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPmlz PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgDQo8L1NQQU4+cGFydG5lcjwv U1BBTj48U1BBTiANCnN0eWxlPSJtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bic7IG1zby1hc2NpaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1oYW5zaS1m b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPqOtPC9TUEFOPjxTUEFOIA0KbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj5zaGlwIGluc3RlYWQgb2Yg ZG9taW5hdGlvbiANCnN5c3RlbS4gVGhlIE1vc3VvIGNvbW11bml0eSB3YXMgZ2l2ZW4gdGhlIHRp dGxlIG9mIG1vZGVsIGNvbW11bml0eSBhdDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsgPC9TUEFOPnRoZTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsgPC9TUEFOPm9jY2FzaW9uPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L1NQQU4+b2Y8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyANCjwvU1BB Tj50aGU8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+NTB0aCBh bm5pdmVyc2FyeTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFO Pm9mPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgDQo8L1NQQU4+dGhlIFVu aXRlZCBOYXRpb25zLjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BB Tj5Ob3cgDQp0aGU8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+ THVndTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPkxha2U8 U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5pczxTUEFOIHN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IA0KPC9TUEFOPmxpc3RlZDxTUEFOIHN0eWxl PSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5pbjxTUEFOIA0Kc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPnRoZTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDsgPC9TUEFOPnRvdXJpc3Q8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7IDwvU1BBTj5hcmVhPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyA8L1NQQU4+b2Y8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyAN CjwvU1BBTj50aGUgTmF0aW9uYWw8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L1NQQU4+bGV2ZWwuIFRoZSANCnNwZWNpYWwgcmVsYXRpb24gYmV0d2VlbiBtZW4gYW5kIHdv bWVuLCBhbmQgc29jaWV0eSBtb2RlbCBwcm92aWRlIHR5cGljYWwgDQpzaXR1YXRpb24gYW5kIHZh bHVhYmxlIG1hdGVyaWFscyBmb3I8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyANCjwvU1BBTj50aGUgc3R1ZHk8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L1NQQU4+b2Y8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BB Tj5odW1hbiBzb2NpZXR5LCByZWxhdGlvbjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsgPC9TUEFOPmJldHdlZW48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7IDwvU1BBTj5tZW48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 IDwvU1BBTj5hbmQ8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BB Tj53b21lbiwgc3RhdHVzIGFuZCByaWdodHMgb2Ygd29tZW4sIA0KbWFycmlhZ2UgYW5kIGZhbWls aWVzLiBUbyBrbm93IG90aGVycyBmb3Iga25vd2luZyBvdXJzZWx2ZXMgYW5kIGtub3cgdGhlIHBh c3QgDQpmb3IgdG9kYXkgYW5kIHRvbW9ycm93LiBJdCBpcyBzbyBpbnRlcmVzdGluZyBhIHRvcGlj IHRoYXQgSSBob3BlIHRoYXQgd2UgDQpjYW48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyA8L1NQQU4+am9pbnRseTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDsgPC9TUEFOPnNwb25zb3I8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7IDwvU1BBTj5hbiBpbnRlcm5hdGlvbmFsIHN5bXBvc2l1bTxTUEFOIA0Kc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPm9uPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj4mbmJzcDsgDQo8L1NQQU4+ZmVtYWxlPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsgPC9TUEFOPnNvY2lvbG9neTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsgPC9TUEFOPmFuZDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsgPC9TUEFOPk9yaWVudGFsPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L1NQQU4+V29tZW4tZG9taW5hdGluZyBLaW5nZG9tLiA8L1NQQU4+PC9QPg0KPFAgY2xhc3M9 TXNvUGxhaW5UZXh0IA0Kc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnk7IFRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoIj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAn VGltZXMgTmV3IFJvbWFuJyI+Tm93YWRheXMsPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyA8L1NQQU4+d29tZW4gYXJlIHN0aWxsIGluIHRoZSBzdGF0ZTxTUEFOIA0Kc3R5 bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPmluPFNQQU4gc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsgDQo8L1NQQU4+d2hpY2ggdGhleTxTUEFOIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5hcmU8U1BBTiANCnN0eWxlPSJtc28tc3BhY2Vy dW46IHllcyI+Jm5ic3A7IDwvU1BBTj5hdHRhY2hlZCB0byBtZW4gaW4gcG9saXRpY2FsLCBlY29u b21pYyANCnBvc2l0aW9uIGFuZCBzZXh1YWwgbGlmZS4gTWFueSB3b21lbjxTUEFOIHN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7IA0KPC9TUEFOPmluIHRoZSB3b3JsZCBhcmUgbG9va2Vk IGRvd24gdXBvbiBhbmQgaWxsLXRyZWF0ZWQuIEluIHNvbWUgY291bnRyaWVzIGFuZCANCmFyZWFz IGZlbWFsZSBjaGlsZHJlbjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwv U1BBTj5hcmU8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5m YWNpbmc8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj50aGU8 U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5wcm9ibGVtIG9m PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+bGl2aW5nLiBJ ZiB3ZSBkbzxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPm5v dCBwYXk8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5zcGVj aWFsPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+YXR0ZW50 aW9uPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+dG8gaXQs IHRoZTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPnNleHVh bCBiYW5hbmE8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5v ZjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IA0KPC9TUEFOPmZlbWFsZTxT UEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5hbmQ8U1BBTiANCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5tYWxlIHdpbGwgYmUgbG9zdC4g QnV0IEh1bWFuaXRhcmlhbmlzbSANCmFuZCBodW1hbiByaWdodHMgYXJlIGZvdW5kIGFuZDxTUEFO IHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5pbiANCmZ1bGwgc3dpbmcg aW4gdGhpcyBjb21tdW5pdHkuIFRoZTxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7IA0KPC9TUEFOPm1hdHJpYXJjaGFsPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDsgPC9TUEFOPmZhbWlsaWVzPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOyA8L1NQQU4+cHJvdmlkZTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsgPC9TUEFOPnVzIHdpdGg8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 IDwvU1BBTj5tdWNoIHRoYXQgd2U8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7IDwvU1BBTj5jYW48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwv U1BBTj5tYWtlIHVzZSBvZjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsg PC9TUEFOPml0IHNvbHZpbmc8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 Jm5ic3A7IDwvU1BBTj50aGUgPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OzwvU1BBTj5wcm9ibGVtczxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsg PC9TUEFOPmluPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgDQo8L1NQQU4+ bW9kZXJuIHdvcmxkLiBJdDxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwv U1BBTj5pczxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPmFs c288U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5hbjxTUEFO IHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IA0KPC9TUEFOPmluc3BpcmF0aW9uPFNQ QU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPnRvPFNQQU4gDQpzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+dXM8U1BBTiBzdHlsZT0ibXNvLXNw YWNlcnVuOiB5ZXMiPiZuYnNwOyANCjwvU1BBTj5hYm91dDxTUEFOIHN0eWxlPSJtc28tc3BhY2Vy dW46IHllcyI+Jm5ic3A7IDwvU1BBTj50aGU8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7IDwvU1BBTj5tYXJyaWFnZTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsgPC9TUEFOPmFuZDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsgPC9TUEFOPmZhbWlseTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsg PC9TUEFOPmluPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgDQo8L1NQQU4+ dGhlPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPmZ1dHVyZS4g SWYgd2UgbWFrZSBhIA0Kc3R1ZHkgYWJvdXQgaW50ZXJwZXJzb25hbCByZWxhdGlvbnMgYW5kIHNl eHVhbCBwYXJ0bmVyczxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9T UEFOPmluPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgDQo8L1NQQU4+dGhl PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPk1vc3VvPFNQQU4g DQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+Y29tbXVuaXR5LCBpdDxT UEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPndpbGw8U1BBTiAN CnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5zaG93PFNQQU4gDQpzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+cHJvZm91bmQ8U1BBTiANCnN0eWxl PSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5ncmVhdCBzaWduaWZpY2FuY2U8U1BB TiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5pbjxTUEFOIHN0eWxl PSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IA0KPC9TUEFOPnJlY29nbml6aW5nPFNQQU4gc3R5 bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPndvbWVuLDxTUEFOIA0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPnByb21vdGluZzxTUEFOIA0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgPC9TUEFOPnRoZTxTUEFOIA0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgPC9TUEFOPmVxdWFsaXR5PFNQQU4gDQpz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyA8L1NQQU4+b2Y8U1BBTiANCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj53b21lbjxTUEFOIA0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPmFuZDxTUEFOIA0Kc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPm1lbi4gPC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1z b1BsYWluVGV4dD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJyI+V2l0aDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsg PC9TUEFOPmJlc3Q8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BB Tj53aXNoZXMhIDwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEI+PFNQQU4gbGFu Zz1FTi1VUyANCnN0eWxlPSJDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t YW4nIj5BaGFpIA0KTHVqaW48L1NQQU4+PC9CPjxCPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+IA0KPC9TUEFOPjwvQj48L1A+DQo8UCBjbGFz cz1Nc29QbGFpblRleHQgDQpzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ4cHQ7IFRFWFQtSU5ERU5UOiAt NDhwdDsgbXNvLWNoYXItaW5kZW50LWNvdW50OiAtNC4wOyBtc28tY2hhci1pbmRlbnQtc2l6ZTog MTIuMHB0Ij48U1BBTiANCmxhbmc9RU4tVVMgc3R5bGU9IkNPTE9SOiBuYXZ5OyBGT05ULUZBTUlM WTogJ1RpbWVzIE5ldyBSb21hbiciPlJlc2VhcmNoIGZlbGxvdyANCm9mIGZlbWFsZSBhbnRocm9w b2xvZ3kgYW5kIHNleHVhbCBzb2Npb2xvZ3k8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxl PSJDT0xPUjogZnVjaHNpYTsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJ WkU6IDE2cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuNXB0Ij4gDQo8L1NQQU4+PC9QPg0KPFAg Y2xhc3M9TXNvUGxhaW5UZXh0IA0Kc3R5bGU9Ik1BUkdJTi1MRUZUOiA0OHB0OyBURVhULUFMSUdO OiBqdXN0aWZ5OyBURVhULUlOREVOVDogLTQ4cHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dy YXBoOyBtc28tY2hhci1pbmRlbnQtY291bnQ6IC00LjA7IG1zby1jaGFyLWluZGVudC1zaXplOiAx Mi4wcHQiPjxTUEFOIA0KbGFuZz1FTi1VUyBzdHlsZT0iQ09MT1I6IGZ1Y2hzaWE7IEZPTlQtRkFN SUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+UHJlc2lkZW50IG9mIA0KSW50ZXJuYXRpb25hbCBTeW1w b3NpdW0gb24gRmVtYWxlIEFudGhyb3BvbG9neSAmYW1wOyBNYXRyaWFyY2hhbCBDdWx0dXJlIGlu IHRoZSANCldvbWVuJ3MtRG9taW5hdGluZyBLaW5nZG9tIGFyb3VuZCB0aGUgTHVndSBMYWtlIDw/ eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5zID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6b2ZmaWNlIiAvPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1Bs YWluVGV4dCANCnN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5OyBURVhULUpVU1RJRlk6IGludGVy LWlkZW9ncmFwaCI+PEI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJDT0xPUjogYmx1ZTsgRk9O VC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj5OT1RFUzwvU1BBTj48L0I+PFNQQU4gDQpsYW5n PUVOLVVTIHN0eWxlPSJDT0xPUjogYmx1ZSI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xh c3M9TXNvUGxhaW5UZXh0IA0Kc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnk7IFRFWFQtSlVTVElG WTogaW50ZXItaWRlb2dyYXBoIj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZ OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdNUyBNaW5jaG8n Ij5QbGVhc2UgDQpjb25zdWx0IEUtbWFpbCBhbmQgPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgDQpz dHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdNUyBNaW5jaG8nIj48QSANCmhyZWY9Imh0 dHA6Ly93d3cubHVndS1sYWtlLmNvbS8iPmh0dHA6Ly93d3cuTHVndS1MYWtlLmNvbTwvQT48L1NQ QU4+PFNQQU4gDQpsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdNUyBNaW5jaG8nIj4gdG8gDQprbm93IHRo ZSBkZXRhaWxlZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc3ltcG9zaXVtLCBzdWNoIGFzIGhlIHNj aGVkdWxlLCANCnRyYW5zcG9ydGF0aW9uLCB0b3VyaXNtLCBhY2NvbW1vZGF0aW9ucywgZHVlcyBh bmQgc28gDQpvbi48L1NQQU4+PC9QPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwv SFRNTD4NCg== ------=_NextPart_000_0005_01C1FF68.E4883D20-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun May 19 12:57:53 2002 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 MAA13926 for ; Sun, 19 May 2002 12:57:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17929 for nsis-archive@odin.ietf.org; Sun, 19 May 2002 12:58:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17594; Sun, 19 May 2002 12:53:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17567 for ; Sun, 19 May 2002 12:53:01 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13783 for ; Sun, 19 May 2002 12:52:44 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4JGrLk12549 for ; Sun, 19 May 2002 19:53:21 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 19 May 2002 19:52:59 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 19 May 2002 19:52:58 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] RE: What's in the charter of NSIS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 19 May 2002 19:52:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC651EE@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: What's in the charter of NSIS Thread-Index: AcH9vcq0dx+2S45MTTeyyvLVawwJ8QBl6aag To: , , Cc: , X-OriginalArrivalTime: 19 May 2002 16:52:58.0998 (UTC) FILETIME=[A1811960:01C1FF55] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA17568 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Lixia, > But I cannot help throwing a comment on this specific one: > NSIS stands for "Next Step in Signaling", not next step in QOS. Exactly. > I personally do NOT think a signaling protocol should involve > itself into the definitions of what QOS requirements should be. > QOS requirements may change over time, yet one wishes that > the signaling protocol, which is used to carry the QOS requirements, does > NOT have to change. I completely agree. > Besides, there WILL be other uses of a signaling protocol other than QOS > need. My understanding is that NSIS is chartered to look into the need for > a signaling protocol, NOT the QOS requirement. I also agree. One can think of the term 'QoS' in the charter as a use case for the signaling protocol developed in NSIS. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun May 19 13:01:00 2002 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 NAA14022 for ; Sun, 19 May 2002 13:00:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18463 for nsis-archive@odin.ietf.org; Sun, 19 May 2002 13:01:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17737; Sun, 19 May 2002 12:56:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17709 for ; Sun, 19 May 2002 12:56:18 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13860 for ; Sun, 19 May 2002 12:56:00 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4JGubk12894 for ; Sun, 19 May 2002 19:56:37 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 19 May 2002 19:56:14 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 19 May 2002 19:56:14 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] RE: What's in the charter of NSIS MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FF56.15B72CDC" Date: Sun, 19 May 2002 19:56:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC651F0@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: What's in the charter of NSIS Thread-Index: AcH9xlVAGstCN0YrTEmHunj73D+HUwBj5yfQ To: , , Cc: X-OriginalArrivalTime: 19 May 2002 16:56:14.0799 (UTC) FILETIME=[1635F5F0:01C1FF56] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1FF56.15B72CDC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gary, =20 I have yet to understand your point. If you feel the current document is missing something, please speak up. =20 Right now, I am under the assumption that the WG will not define the format of the QoS object to be signaled. =20 John -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 17 May, 2002 20:14 To: 'Bob Braden'; Loughney John (NRC/Helsinki); lixia@CS.UCLA.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] RE: What's in the charter of NSIS It is a valid observation that my point was very much into the=20 detail. However, it had nothing to do with how Int Serv, Diff=20 Serv or any other QoS model happens to work. It had everything=20 to do with the on-going thread as to whether NSIS was chartered=20 to look at resource allocation (which is not). I was simply attempting=20 to draw a distinction between QoS specification and resource allocation. = In no way did I intend d to imply, nor do I believe that I actually = implied,=20 that NSIS was building the next QoS "model".=20 As for the point that Lixia was making, I think it is a valid one,=20 However, correct me if I am wrong here, but the charter states:=20 "This working group will develop the requirements, architecture and=20 protocols for the next IETF steps on signalling QoS. The working group=20 will use existing IETF signalling as the basis for this work, evaluating = RSVP in particular as the starting point. Additionally, the working=20 group will consider how to signal QoS (what sort of QoS parameters to=20 use), and where to signal (end-to-end, end-to-edge, end-to-proxy,=20 edge-to-edge, etc.)."=20 Sounds like NSIS is really NSIQoSS, if one was to worry about names=20 (a rose is a rose . . .).=20 Finally, I do agree that NSIS should absolutely be defined with some=20 attention to future needs, as long as we keep it real. Predicting=20 the future is neither easy, nor reliable.=20 Cheers,=20 Gary=20 > -----Original Message-----=20 > From: Bob Braden [ mailto:braden@ISI.EDU]=20 > Sent: May 17, 2002 12:47=20 > To: john.loughney@nokia.com; lixia@CS.UCLA.EDU=20 > Cc: nsis@ietf.org=20 > Subject: Re: [NSIS] RE: What's in the charter of NSIS=20 >=20 >=20 >=20 > Lixia wrote:=20 >=20 > ...=20 >=20 > *>=20 > *> But I cannot help throwing a comment on this specific=20 > one: NSIS stands for=20 > *> "Next Step in Signaling", not next step in QOS.=20 > *>=20 > *> I personally do NOT think a signaling protocol should=20 > involve itself into=20 > *> the definitions of what QOS requirements should be.=20 > *> QOS requirements may change over time, yet one wishes=20 > that the signaling=20 > *> protocol, which is used to carry the QOS requirements,=20 > does NOT have to=20 > *> change.=20 > *>=20 > *> Besides, there WILL be other uses of a signaling=20 > protocol other than QOS=20 > *> need. My understanding is that NSIS is chartered to=20 > look into the need for=20 > *> a signaling protocol, NOT the QOS requirement.=20 > *>=20 >=20 > I want to say "amen" to all of that.=20 >=20 > The original message from Gary Kenward included, "... QoS=20 > specifications such as the Tspec." The Tspec is not by itself a QoS=20 > specification. In fact, even talking about "a QoS=20 > specification" is to=20 > oversimplify a complex process, which may involve two passes, one pass = > with advertising, etc. There are many possible QoS models; int-serv=20 > chose just two of them. And NSIS should choose NONE of them; a=20 > next-generation signaling protocol should be able to handle any future = > model.=20 >=20 > This observation, together with Lixia's comment, leads me to the=20 > realization that RSVP may have had the modularity wrong (and=20 > NSIS might=20 > pay attention to this point). RSVP design and specification may ahve=20 > talked too much about int-serv specific things like Tspecs. We should = > instead have defined RSVP strictly in terms of transporting opaque QoS = > objects upstream and downstream, and applying some model-specific=20 > algorithms at merge and branch points. The definition of=20 > these objects=20 > and algorithms would then be completely contained in documents that=20 > define QoS models.=20 >=20 > Our vision was imperfect when we began the Internet=20 > integrated services=20 > work in 1993. If we had gotten the modularity better, we=20 > would perhaps=20 > have avoided some of the immense amount of misunderstanding that is=20 > still current about Internet QoS issues.=20 >=20 > BTW, see draft-braden-2level-signal-arch-00.txt for a glimmer of a=20 > better modularity.=20 >=20 > Bob Braden=20 >=20 >=20 >=20 >=20 > *> My personal 2 cents,=20 > *> Lixia=20 > *>=20 > *>=20 > *> _______________________________________________=20 > *> nsis mailing list=20 > *> nsis@ietf.org=20 > *> https://www1.ietf.org/mailman/listinfo/nsis=20 > *>=20 >=20 > _______________________________________________=20 > nsis mailing list=20 > nsis@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 ------_=_NextPart_001_01C1FF56.15B72CDC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] RE: What's in the charter of NSIS
Hi=20 Gary,
 
I have=20 yet to understand your point.  If you feel the = current
document is missing something, please speak = up.
 
Right=20 now, I am under the assumption that the WG will
not=20 define the format of the QoS object to be signaled.
 
John
-----Original Message-----
From: ext Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: 17 May, 2002=20 20:14
To: 'Bob Braden'; Loughney John (NRC/Helsinki);=20 lixia@CS.UCLA.EDU
Cc: nsis@ietf.org
Subject: RE: = [NSIS]=20 RE: What's in the charter of NSIS

It is a valid observation that my point was very = much into=20 the
detail. However, it had nothing to do = with how Int=20 Serv, Diff
Serv or any other QoS model = happens to=20 work. It had everything
to do with the = on-going thread=20 as to whether NSIS was chartered
to look at = resource=20 allocation (which is not). I was simply attempting
to=20 draw a distinction between QoS specification and resource = allocation.=20
In no way did I intend d to imply, nor do I believe = that I=20 actually implied,
that NSIS was building the = next QoS=20 "model".

As for the point that Lixia was making, I think it = is a valid=20 one,
However, correct me if I am wrong here, = but the=20 charter states:

"This working group will develop the requirements,=20 architecture and
protocols for the next IETF = steps on=20 signalling QoS. The working group
will use = existing=20 IETF signalling as the basis for this work, evaluating =
RSVP in particular as the starting point. Additionally, the = working=20
group will consider how to signal QoS (what = sort of=20 QoS parameters to
use), and where to signal=20 (end-to-end, end-to-edge, end-to-proxy,
edge-to-edge,=20 etc.)."

Sounds like NSIS is really NSIQoSS, if one was to = worry about=20 names
(a rose is a rose . . .).

Finally, I do agree that NSIS should absolutely be = defined=20 with some
attention to future needs, as long = as we=20 keep it real. Predicting
the future is = neither easy,=20 nor reliable.

Cheers,
Gary

> -----Original Message-----
>=20 From: Bob Braden [mailto:braden@ISI.EDU] =
> Sent: May 17, 2002 12:47
> = To:=20 john.loughney@nokia.com; lixia@CS.UCLA.EDU
> Cc:=20 nsis@ietf.org
> Subject: Re: [NSIS] RE: = What's in=20 the charter of NSIS
>
>=20
>
> Lixia = wrote:=20
>
> ... =
>
>   *> =
>   *> But I cannot help throwing a comment = on this=20 specific
> one: NSIS stands for =
>   *> "Next Step in Signaling", not next = step in=20 QOS.
>   *>
>   *> I personally do NOT think a signaling = protocol=20 should
> involve itself into =
>   *> the definitions of what QOS = requirements should=20 be.
>   *> QOS requirements = may change=20 over time, yet one wishes
> that the=20 signaling
>   *> protocol, = which is=20 used to carry the QOS requirements,
> = does NOT have=20 to
>   *> change. =
>   *>
>   *>=20 Besides, there WILL be other uses of a signaling
>=20 protocol other than QOS
>   = *>=20 need.  My understanding is that NSIS is chartered to =
> look into the need for
>  =20 *> a signaling protocol, NOT the QOS requirement.
>   *>
> =
> I want to say "amen" to all of that.
>=20
> The original message from Gary Kenward = included,=20 "... QoS
> specifications such as the = Tspec." The=20 Tspec is not by itself a QoS
> = specification. =20 In fact, even talking about "a QoS
> = specification"=20 is to
> oversimplify a complex process, = which may=20 involve two passes, one pass
> with = advertising,=20 etc.  There are many possible QoS models; int-serv =
> chose just two of them.  And NSIS should choose = NONE of them;=20 a
> next-generation signaling protocol = should be=20 able to handle any future
> model. =
>
> This observation, = together with=20 Lixia's comment, leads me to the
> = realization that=20 RSVP may have had the modularity wrong (and
> NSIS=20 might
> pay attention to this = point).  RSVP=20 design and specification may ahve
> = talked too much=20 about int-serv specific things like Tspecs.  We should =
> instead have defined RSVP strictly in terms of = transporting opaque=20 QoS
> objects upstream and downstream, = and applying=20 some model-specific
> algorithms at merge = and=20 branch points.  The definition of
> = these=20 objects
> and algorithms would then be = completely=20 contained in documents that
> define QoS=20 models.
>
> = Our vision=20 was imperfect when we began the Internet
>=20 integrated services
> work in 1993.  = If we had=20 gotten the modularity better, we
> would=20 perhaps
> have avoided some of the = immense amount=20 of misunderstanding that is
> still = current about=20 Internet QoS issues.
>
>=20 BTW, see draft-braden-2level-signal-arch-00.txt for a glimmer of = a=20
> better modularity.
>=20
> Bob Braden
>=20
>
> =
>
>   *> My = personal 2=20 cents,
>   *> Lixia =
>   *>
>   *>=20
>   *>=20 _______________________________________________
>   *> nsis mailing list
>   *> nsis@ietf.org
>   *> https://www1.ietf.or= g/mailman/listinfo/nsis=20
>   *>
>=20
>=20 _______________________________________________
>=20 nsis mailing list
> nsis@ietf.org =
> https://www1.ietf.or= g/mailman/listinfo/nsis=20
>

------_=_NextPart_001_01C1FF56.15B72CDC-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun May 19 13:11:44 2002 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 NAA14361 for ; Sun, 19 May 2002 13:11:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19134 for nsis-archive@odin.ietf.org; Sun, 19 May 2002 13:11:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18880; Sun, 19 May 2002 13:07:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18849 for ; Sun, 19 May 2002 13:07:19 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14226 for ; Sun, 19 May 2002 13:07:01 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4JH68Y15532 for ; Sun, 19 May 2002 20:06:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 19 May 2002 20:07:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 19 May 2002 20:07:15 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] RE: What's in the charter of NSIS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 19 May 2002 20:07:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC651F4@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: What's in the charter of NSIS Thread-Index: AcH9uYWL3cYwChLQTjyQ3xjkINp/ZwBnfanQ To: , Cc: , X-OriginalArrivalTime: 19 May 2002 17:07:15.0977 (UTC) FILETIME=[A04DB790:01C1FF57] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA18850 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gary, > I think the distinction that can be made is that NSIS should be able to > describe the QoS requirements, including resource constraining QoS > specifications such as the Tspec. And, there should be an interaction > with NSIS and admission control. However, there are other resources that > may need to be provisioned for QoS such as filters, queues, etc., and we > would really have to show a significant advantage in managing these > resources with NSIS rather then one of the existing solutions. These can all be considered services, and are out of scope for NSIS. NSIS will not define these. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun May 19 13:17:30 2002 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 NAA14531 for ; Sun, 19 May 2002 13:17:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19426 for nsis-archive@odin.ietf.org; Sun, 19 May 2002 13:17:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19238; Sun, 19 May 2002 13:12:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19205 for ; Sun, 19 May 2002 13:12:57 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14398 for ; Sun, 19 May 2002 13:12:39 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4JHDHk15011 for ; Sun, 19 May 2002 20:13:17 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 19 May 2002 20:12:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 19 May 2002 20:12:54 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 19 May 2002 20:12:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC651F6@esebe004.NOE.Nokia.com> Thread-Topic: some charter restrictions - fwd from Scott Thread-Index: AcH9qR1fLye8wO1lQYityuPJG5h3SABrr0BQ To: X-OriginalArrivalTime: 19 May 2002 17:12:54.0796 (UTC) FILETIME=[6A4164C0:01C1FF58] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA19206 Subject: [NSIS] Some charter scoping / restrictions Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Even before the last few email discussions on NSIS & its charter, the Area Directors and I had a small chat. There is some worry that some of the discussion on the list is distinctly out of scope, and here is the scoping that we have come up with: NSIS will work on signaling from an end system that follows a path through the net that is determined by the normal L3 routing and is used to convey per-flow information to the devices the signals pass through - the signaling can install soft state (maintained by repetition) in the devices it passes through. An end system could be a device along the path that signals for a data flow that passes through it. There is no requirement that the per-flow information be QoS related i.e. NSIS should only worry about how to do the signaling - what the signaling conveys should be opaque to NSIS. QoS has been thought of the first application of such a system, and used to help focus discussion. However, it seems that QoS has done the opposite, and created divergence from the charter. This rules out bandwidth brokers, 3rd party QoS controllers, hard state, etc. After we fufill the above stated goals, the WG could move on to other things (like BBs). This is as definitive statement as can be made. Best regards John, Scott & Allison _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun May 19 15:03:15 2002 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 PAA17860 for ; Sun, 19 May 2002 15:03:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25430 for nsis-archive@odin.ietf.org; Sun, 19 May 2002 15:03:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24771; Sun, 19 May 2002 14:58:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24743 for ; Sun, 19 May 2002 14:58:44 -0400 (EDT) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17740 for ; Sun, 19 May 2002 14:58:26 -0400 (EDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4JIwH818924; Sun, 19 May 2002 11:58:17 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 19 May 2002 11:57:58 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01486D3D@zsc3c032.us.nortel.com> From: "Praveen Muley" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Some charter scoping / restrictions Date: Sun, 19 May 2002 11:58:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FF66.790C3116" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C1FF66.790C3116 Content-Type: text/plain; charset="iso-8859-1" Hi John, Does that mean that we will be also dealing with autoneogtiation of services ( different applications) between the mobile device and the edge offering services in this charter ? Thanks, Praveen -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Sunday, May 19, 2002 10:13 AM To: nsis@ietf.org Subject: [NSIS] Some charter scoping / restrictions Hi all, Even before the last few email discussions on NSIS & its charter, the Area Directors and I had a small chat. There is some worry that some of the discussion on the list is distinctly out of scope, and here is the scoping that we have come up with: NSIS will work on signaling from an end system that follows a path through the net that is determined by the normal L3 routing and is used to convey per-flow information to the devices the signals pass through - the signaling can install soft state (maintained by repetition) in the devices it passes through. An end system could be a device along the path that signals for a data flow that passes through it. There is no requirement that the per-flow information be QoS related i.e. NSIS should only worry about how to do the signaling - what the signaling conveys should be opaque to NSIS. QoS has been thought of the first application of such a system, and used to help focus discussion. However, it seems that QoS has done the opposite, and created divergence from the charter. This rules out bandwidth brokers, 3rd party QoS controllers, hard state, etc. After we fufill the above stated goals, the WG could move on to other things (like BBs). This is as definitive statement as can be made. Best regards John, Scott & Allison _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C1FF66.790C3116 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Some charter scoping / restrictions

Hi John,
       Does that mean = that we will be also dealing with autoneogtiation of services ( = different applications) between the mobile device and the edge offering = services in this charter ?

Thanks,
Praveen

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Sunday, May 19, 2002 10:13 AM
To: nsis@ietf.org
Subject: [NSIS] Some charter scoping / = restrictions


Hi all,

Even before the last few email discussions on NSIS = & its charter,
the Area Directors and I had a small chat.  = There is some worry
that some of the discussion on the list is = distinctly out of
scope, and here is the scoping that we have come up = with:

NSIS will work on signaling from an end system that = follows a path
through the net that is determined by the normal L3 = routing and is
used to convey per-flow information to the devices = the signals pass
through - the signaling can install soft state = (maintained by repetition)
in the devices it passes through.

An end system could be a device along the path that = signals for a data
flow that passes through it.

There is no requirement that the per-flow information = be QoS related i.e.
NSIS should only worry about how to do the signaling = - what the  signaling
conveys should be opaque to NSIS.  QoS has been = thought of the first
application of such a system, and used to help focus = discussion.
However, it seems that QoS has done the opposite, = and created divergence
from the charter.

This rules out bandwidth brokers, 3rd party QoS = controllers, hard state,
etc.  After we fufill the above stated goals, = the WG could move on to
other things (like BBs).

This is as definitive statement as can be made.  =

Best regards
John, Scott & Allison

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

------_=_NextPart_001_01C1FF66.790C3116-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun May 19 15:32:16 2002 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 PAA18250 for ; Sun, 19 May 2002 15:32:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27225 for nsis-archive@odin.ietf.org; Sun, 19 May 2002 15:32:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26468; Sun, 19 May 2002 15:27:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26382 for ; Sun, 19 May 2002 15:27:08 -0400 (EDT) Received: from ssaserv1.roesti.cc (TK212017094024.teleweb.at [212.17.94.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18157 for ; Sun, 19 May 2002 15:26:48 -0400 (EDT) Received: by TK212017094024.teleweb.at with Internet Mail Service (5.5.2653.19) id ; Sun, 19 May 2002 21:18:19 +0200 Message-ID: <71C667A91D79D41197910050DA46B3C902FD42@TK212017094024.teleweb.at> From: Hannes Tschofenig To: "'nsis@ietf.org '" Date: Sun, 19 May 2002 21:18:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1FF69.EEEFDAB0" Subject: [NSIS] NSIS Interim Meeting Contribution: NSIS Threats Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_000_01C1FF69.EEEFDAB0 Content-Type: text/plain dear all, hereby i submit a memo describing security threats relevant for nsis. this document should serve as a basis for further discussion (especially at the nsis interim meeting). ciao hannes ps: please sent your comments to hannes.tschofenig@mchp.siemens.de ------_=_NextPart_000_01C1FF69.EEEFDAB0 Content-Type: application/octet-stream; name="draft-tschofenig-nsis-threats-00.txt" Content-Disposition: attachment; filename="draft-tschofenig-nsis-threats-00.txt" Content-Transfer-Encoding: quoted-printable =0A= NSIS Working Group = Internet Draft Hannes Tschofenig = Document: draft-tschofenig-nsis-threats- Siemens = 00.txt=20 Expires: August 2002 May 2002 = =20 =20 NSIS Threats=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026.=20 =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that = =20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents = at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress." = =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Informational - Expires August 2002 1 = =0C NSIS Threats May 2002=20 =20 Abstract=20 =20 As the work in the NSIS working has begun to describe requirements=20 and the framework people started thinking about possible security=20 implication. This document should provide a starting point for the=20 discussion at the NSIS interim meeting and at the NSIS working group = mailing list regarding the security issues that have to be=20 addressed. It does not describe threats for a particular published=20 protocol. This memo is furthermore meant to create awareness for the = security within the group. The threat scenarios in this document are = matched against the security requirements described in [1]. =20 =20 1 Introduction=20 =20 It is often argued that QoS signaling protocols are similar to other = signaling protocols and one might re-use their security mechanisms=20 for avoiding reengineering overhead. This is true up to some point:=20 A QoS signaling protocol might borrow many security mechanisms from=20 other protocols but different trust assumptions, and different=20 protocol processing may demand different solutions or adaptations.=20 This document tries to show security issues that need to be=20 addressed by a QoS signaling protocol that claims to be secure.=20 Although the base protocol might be sure, some extensions may cause=20 problems when used in a particular environment. We think that it is=20 necessary to investigate the kontext in which a QoS protocol is=20 integrated and in which sequence protocols are executed (when=20 combined together with other protocols). A particular focus of QoS=20 signaling protocols should be given to the interaction with=20 accounting and charging solutions: Without an appropriate=20 integration of QoS and accounting protocols there is no good=20 incentive for network operators to deploy them. =20 =20 Independent of the threat scenarios described in Section 3 we=20 indentify the following structural pieces, which require different=20 security protection because of different trust relationships. The=20 sub-parts are:_access network part, intra and inter-domain part, and = the issues related to the end-to-end communication. These parts are=20 briefly described. The threat scenarios in Section 3 can be assigned = to the individual parts. =20 =20 a) Access Network =20 =20 This section addresses threats that arise when the QoS Inititiator=20 (QI) is attached to access network and transmits and receives QoS=20 signaling messages. There might not exist a pre-established trust=20 relationship between a user and the access network, as in many=20 mobility scenarios it is usually assumed.=20 =20 Threat scenarios dealing with initial QoS security association=20 setup, replay attacks, lack of confidentiality, denial of service,=20 integrity violation, identity spoofing and fraud are applicable.=20 From a security point of view this part of the network causes the=20 most problems. =20 =20 =20 Tschofenig Informational - Expires August 2002 2 = =0C NSIS Threats May 2002=20 =20 b) Intra-Domain=20 =20 After receiving and verifying a QoS request at the access network=20 the signaling messages traverse the network within the same=20 administrative domain. Since the request has already been=20 authenticated and authorized threats are different compared to those = described in the previous section. To differentiate the user-to- access network interface with the intra-domain communication (i.e.=20 communication within the core-network) we assume that no user hosts=20 are attached to the core-network. (That is: the interface between=20 any host and the first router is part of the access network). We=20 furthermore assume that nodes within one administrative domain have=20 a stronger trust relationship between each other. =20 =20 c) Inter-Domain=20 =20 The security considerations at the border between different=20 administrative domains largely depends on how accounting is done. If = one domain transmits forged QoS reservations (for example stating a=20 higher QoS reservation than a aggregated number of user did) to next = domain then it is likely that the originating network domain has=20 also has to pay for the reservation. Hence in this case, there is no = real benefit for the first network domain to forge a QoS=20 reservation. But if the user is directly charged by intermediate=20 domains too then this kind of attack may be reasonable. Security=20 protection of messages transmitted between different administrative=20 domains is still necessary to tackle attacks like spoofing,=20 integrity violation, denial of service etc. The lower number of=20 networks and higher trust relationship (compared in the access=20 network case) cause fewer problems for a key management. =20 =20 d) End-to-End =20 =20 In our opinion end-to-end security for QoS signaling messages is=20 rarely required if we assume that end-to-end issues like charging=20 and the selection which user has to pay for a reservation is already = securely negotiated by preceding upper layer protocols (for example=20 SIP). Information carried within a QoS signaling protocol for the=20 purpose of charging is therefore assumed opaque to the QoS protocol=20 itself and appropriately protected as part of the AAA interaction.=20 For accounting data, the QoS signaling protocol is therefore only=20 used as a transport mechanism. Note however that this assumption=20 strongly depends on the chosen solution of a protocol interaction=20 with AAA, QoS and application layer protocol. It is however possible = to select a charging solution that requires end-to-end protection of = information delivered within the QoS signaling protocol. The=20 following example requires some sort of end-to-end protection: Alice = wants Bob to pay for the QoS reservation. (reverse charging) Bob=20 wants to be assured that the QoS signaling message he receives are=20 transmitted by Alice because he is only willing to pay for=20 particular users and not for everyone. Hence Bob requires Alice to=20 authenticated the request. =20 =20 =0A= =20 Tschofenig Informational - Expires August 2002 3 = =0C NSIS Threats May 2002=20 =20 2 Terminology=20 =20 Some threat scenarios in this document use the entity user instead=20 of the QoS Initiator (as introduced by [1]). This is mainly due to=20 the fact that security protocols allow a differentiation between=20 entities being hosts or users. Since the QoS Initiator as used in=20 [1] also allows to act on behalf of various entities including a=20 network it is reasonable to distinguish between these identities. =20 =20 We use the term access network for a network to which a mobile node=20 is attached. Other terms often used in this context are foreign or=20 visited network. The missing direct trust relationship between the=20 mobile node and the visited networks is characteristic for such an=20 interface and complicates authentication and key agreement. Usually=20 AAA protocols (like Radius or Diameter) are used for such a purpose. = These protocols exploit the infrastructure and trust relationships=20 between the access network and the home network of the user. =20 =20 The term security association is used to describe established=20 security-relevant data structure between two entities. This data=20 structure consists of keys, algorithms including their parameters,=20 values used for replay protection etc. Using this information two=20 nodes are able to protect QoS signaling messages. =20 =20 3 Threat Scenarios=20 =20 This section provides threat scenarios that are applicable to the=20 quality of service signaling protocols.=20 =20 Additionally, it might also be possible that the QoS initiator acts=20 on behalf of an other user and must therefore interact with this=20 node to be able to trigger the reservation setup. This issue however = requires further investigation based on specific protocol proposals. = =20 =20 3.1 Man-in-the-Middle Attacks=20 =20 This Section describes man-in-the-middle attacks of the following=20 type: During the process of establishing a security association an=20 adversary fools the QI with respect to the entity to which it has to = authenticate. The man-in-the-middle adversary is able to modify=20 signaling messages transmitted to the real network requesting=20 different QoS parameters. The QI wrongly believes that it talks to=20 the =93real=94 network whereas it is actually attached to an = adversary.=20 Note that a solution for protecting QoS signaling messages does not=20 necessarily need to establish a security association. In general it=20 is however advisable to create one because of performance reasons. =20 =20 For this attack to be successful, pre-conditions have to hold which=20 are described with the two scenarios below: =20 =20 a) No authentication=20 =20 The first case considers the case that no authentication between the = QI and other entity (access network, other networks, a single node)=20 =20 Tschofenig Informational - Expires August 2002 4 = =0C NSIS Threats May 2002=20 =20 takes places: Without authentication the QI is unable to detect an=20 adversary. =20 =20 b) Unilateral authentication=20 =20 In case of only unilateral authentication (that is, a missing=20 authentication of the access network to the QI) the QI is not able=20 to discover the man-in-the-middle adversary. In the=20 telecommunication world this type of attack is known as the false=20 base-station attacks (if the unilateral authentication is executed=20 between a user and the access network).=20 =20 The two threats described above are a general problem of network=20 access without appropriate authentication, not only for QoS. Still=20 these issues need to be correctly addressed in a proposed protocol=20 since the impacts may reach beyond the local network.=20 =20 3.2 Missing real-time notifications of QoS reservation costs (cost=20 control)=20 =20 An other type of attack uses the fact that a user is not able to=20 authorize a particular network service provider (i.e. because of a=20 large number of providers). A large number of service providers with = complex roaming agreements create a non-transparent cost-structure.=20 Using AAA protocols in a subscription-based scenario (i.e. user is=20 registered with his home service provider) the user does not learn=20 the identity of the network using a regular message exchange. The=20 user is only authenticated to the home network (and possibly vice=20 versa). The identity of the access network is possibly not revealed. = Furthermore one service provider =93steals=94 users from an other = close- by service provider and because of a missing cost-notification the=20 user is unable to refuse the more expensive service provider=20 although he could route his traffic possible via both providers. The = user is not able to select the =93cheapest=94 access router (in = terms of=20 QoS costs). =20 =20 Although real-time notifications of quality of service reservation=20 costs (cost control) to the user are outside the scope of a quality=20 of service protocol itself there are still interactions with AAA and = other protocols.=20 =20 3.3 Eavesdropping and Traffic Analysis=20 =20 This Section covers two threats: The first one is related to privacy = concerns whereas the second addresses problems caused by weak=20 authentication mechanisms and the increased risk of eavesdropping on = the wireless link in absence of appropriate confidentiality=20 protection. =20 =20 The first threat case covers adversaries that are unable to actively = participate in the QoS signaling (passive adversary) but eavesdrop=20 messages. The collected signaling packets may serve for the purpose=20 of traffic analysis or to later mount replay attacks as described in = the next Section. By eavesdropping an adversary might violate a=20 =20 Tschofenig Informational - Expires August 2002 5 = =0C NSIS Threats May 2002=20 =20 user=92s privacy preference. Especially QoS signaling messages = provide=20 information that may be interesting for an adversary since the=20 messages include user and/or application identities, policy=20 information, information about the desired QoS reservation, etc. The = information gathered by an adversary can be to learn usage patterns=20 of users requesting resources and track QoS reservations. =20 =20 The second threat case addresses weak authentication mechanisms=20 whereby information transmitted within the QoS signaling protocol=20 may leak passwords and may allow offline dictionary attacks. This=20 threat is not specific to QoS signaling protocols by may also be=20 applicable and countermeasures must be taken.=20 =20 3.4 Adversary being able to replay signaling messages=20 =20 This threat scenario covers the case where an adversary eavesdrops=20 and collects signaling messages and replays them at a latter point=20 in time (or at a different place, or uses parts of them at a=20 different place or in a different way =96 e.g. cut and paste = attacks).=20 The adversary may use this technique in absence of appropriately=20 protected messages to mount denial of service attacks. Furthermore=20 also theft of service is possible. =20 =20 A more difficult attack that may cause problems even in case of=20 replay protection requires the adversary to crash a QoS aware node=20 (router, broker, etc.) to lose synchronization and to be able to=20 replay old QoS signaling messages. =20 =20 3.5 Identity Spoofing=20 =20 An adversary with the capability to spoof the identity may mount the = following attacks:=20 =20 Eve, acting as an adversary, claims to be the registered user Alice=20 by spoofing the identity of Alice. Thereby Eve causes the network to = charge Alice for the consumed network resources. Using unprotected=20 messages Eve may experience no particular problems in succeeding. =20 =20 In case that the signaling request is properly protected the=20 situation becomes more difficult. This threat tries to address=20 possible problems with network based QoS traffic classification=20 based on some identifiers (IP address, ports, other header=20 information etc.). The situation does not change when the data=20 traffic is marked by the transmitting host (i.e. using DSCP).=20 =20 After the network receives a properly protected reservation request, = transmitted by the legitimate user Alice, traffic filters are=20 installed at edge devices. These traffic filters allow data traffic=20 originated from a given address to be assigned to a particular QoS=20 class. The adversary Eve now spoofs the IP address of the Alice (or=20 whatever identifier is used in the flow classification).=20 Additionally Alice=92s host may be crashed by the adversary as a=20 result of a denial of service attack or lost connectivity for a=20 variety of other reasons. In any case Eve is now able to receive and = =20 Tschofenig Informational - Expires August 2002 6 = =0C NSIS Threats May 2002=20 =20 transmit data (for example RTP data traffic), that receives=20 preferential QoS treatment, using Alice=92s IP address (or whatever=20 identifier is used in the flow classification) until the next=20 signaling message appears and forces Eve to respond with a protected = signaling message. Again this issue is not only applicable to QoS=20 traffic but the existence of QoS reservation causes more=20 difficulties since this type of traffic is more expensive. =20 =20 3.6 Adversary being able to inject/modify messages=20 =20 The next type of threat is caused by an integrity violation: An=20 adversary modifies signaling messages (e.g. by acting as a man-in- the-middle) to achieve an unexpected network behavior with the bogus = request. Possible actions are reordering, delaying, dropping,=20 injecting and modifying. =20 =20 Using a different identity the adversary may forward a modified a=20 QoS signaling message requesting a large amount of resources (using=20 a different identity). If granted it causes other user's resource- request not to be successful and a different user to pay for the=20 reservation. This attack is only useful in absence of user=20 authentication or if the adversary is able to spoof someone=92s=20 identity since the attack is useless if the adversary itself is=20 charged for the huge resource reservation. =20 =20 3.7 Missing Non-Repudiation Property=20 =20 Repudiation in this context refers to a problem where one party=20 later denies to have made a reservation. This issue comes in two=20 flavors: =20 =20 From a service provider point-of-view the following threat may be=20 worth an investigation because a user may deny to have issued=20 reservation requests for which he was charged. A service provider=20 may then like to prove that a particular user issued the reservation = request. =20 =20 The same threat can be interpreted from the users point-of-view. A=20 service provider claims to have received a number of reservation=20 requests. The user in question thinks that he never issued those=20 requests and wants to have a proof for correct service usage for a=20 given set of QoS parameters.=20 =20 3.8 Malicious Edge-Router=20 =20 Network elements within a domain (intra-domain) experience a=20 different trust relationship with regard to the security protection=20 of signaling messages compared to edge routers. Assuming that edge=20 routers have the responsibility to perform cryptographic processing=20 (authentication, integrity and replay protection, authorization and=20 accounting). If however an adversary manages to take over an edge=20 router then the security of the entire network is affected. An=20 adversary can then launch a number of attacks including denial of=20 service, integrity violation, replay attacks etc. Note that this=20 =20 Tschofenig Informational - Expires August 2002 7 = =0C NSIS Threats May 2002=20 =20 problem is not only restricted to the QoS protocols. In such a case=20 even the chain-of-trust principle does not prevent the network from=20 being vulnerable: If we assume that the adversary, with access to=20 the edge router, is able to access the keys used to secure messages=20 to other nodes. =20 =20 Thus the edge router is a critical component that requires strong=20 security protection. This does not necessarily imply that all=20 routers within the core network do not need to cryptographically=20 verify signaling messages and that these routers cannot have any=20 security effect if they act maliciously. If the (hop-by-hop) chain- of-trust principle is deployed then the security of the path (in=20 this case within the network of a single administrative domain) is=20 as strong as the weakest link. In our case the edge router is the=20 most critical component of this network that may also act as a=20 security gateway/firewall for incoming/outgoing traffic. For=20 outgoing traffic this device has to act according to the security=20 policy of the local domain to apply the appropriate security=20 protection. =20 =20 3.9 Denial of Service in a two phase reservation=20 =20 This threat tries to address potential denial of service attacks=20 when the reservation setup is split into two phases i.e. path and=20 reservation. For this example we assume that the node transmitting=20 the path message is not charged for this message and is able to=20 issue a high number of reservation request (possibly in a=20 distributed fashion). The reservations are however never intended to = be successful because of various reasons: for example the=20 destination node cannot be reached or is not responding node or=20 rejects the reservation. An adversary can benefit from the fact that = resources are already consumed along the path for various processing = tasks including path pinning. =20 =20 3.10 Denial of Service with a bogus reservation request =20 =20 With a resource reservation request received at a network element=20 (for example by the first QoS aware router) processing is required=20 for authentication and authorization (processing by other nodes=20 including policy server, LDAP server, etc. is also possible=20 depending on the network architecture). The verification of the=20 provided credentials requires computations and resources to be=20 allocated memory for state maintenance, setting timers, additional=20 messages transmitted to other nodes, cryptographic computations). If = an adversary is able to transmit a large number of reservation=20 request (flooding) with bogus credentials and assuming that the=20 verification is expensive in terms of resource consumption then the=20 verifying node may not be able to process further reservation=20 messages by legitimate user.=20 =20 3.11 Disclosing the networking structure=20 =20 In some architectures a network provider does not want to reveal its = internal network structure to the outside world. An adversary might=20 =20 Tschofenig Informational - Expires August 2002 8 = =0C NSIS Threats May 2002=20 =20 be able to use NSIS messages for network mapping (e.g. discovering=20 which nodes existed, which used NSIS, what version etc.). This=20 requirement might conflict with a protocol solution that provides a=20 mean to automatically discover NSIS aware nodes and their identity=20 (the identity required for security protection). =20 =20 3.12 Modification of subsequent reservation request=20 =20 An adversary might be able to modify an existing reservation which=20 had already been established within the network as a result of a=20 previous QoS signaling message. This means that a QoS signaling=20 messages that modifies established state must be subject to security = protection comparable to the original signaling message setting up=20 the reservation. Furthermore it might be necessary to provide=20 (possibly cryptographic) information to assure a correct binding to=20 a specific state/session. =20 =20 3.13 Faked Error/Response messages=20 =20 An adversary may be able to use false error/response messages as=20 part of a denial of service attack. This could be either at the=20 reservation level or at the protocol level. =20 =20 4 Security Considerations=20 =20 This entire memo discusses security issues. =20 =20 5 References=20 =20 [1] Brunner, M., "Requirements for QoS Signaling Protocols", draft- ietf-nsis-req-02.txt, Work In Progress, May 2002.=20 =20 6 Acknowledgments=20 =20 I would like to thank (in alphabetical order) Marcus Brunner, Jorge=20 Cuellar, Xiaoming Fu and Robert Hancock for their comments to this=20 draft. Jorge and Robert gave me an extensive list of comments for=20 this memo and provided more information on additional threats that=20 should be added. =20 =20 7 Author's Addresses=20 =20 Hannes Tschofenig =20 Siemens AG=20 Otto-Hahn-Ring 6=20 81739 Munchen=20 Germany=20 Email: Hannes.Tschofenig@mchp.siemens.de=20 =20 =0A= =0A= =0A= =0A= =0A= =20 Tschofenig Informational - Expires August 2002 9 = =0C ------_=_NextPart_000_01C1FF69.EEEFDAB0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 20 01:18:42 2002 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 BAA14896 for ; Mon, 20 May 2002 01:18:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA07975 for nsis-archive@odin.ietf.org; Mon, 20 May 2002 01:18:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA07920; Mon, 20 May 2002 01:13:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA07889 for ; Mon, 20 May 2002 01:13:53 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14650 for ; Mon, 20 May 2002 01:13:34 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4K5CcY08607 for ; Mon, 20 May 2002 08:12:38 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 May 2002 08:13:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 20 May 2002 08:13:46 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] Some charter scoping / restrictions MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 20 May 2002 08:13:45 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC651FD@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Some charter scoping / restrictions Thread-Index: AcH/Zx2j4tOmXujmRdWyAsXEQA8nrQAVefNw To: , X-OriginalArrivalTime: 20 May 2002 05:13:46.0753 (UTC) FILETIME=[1E6E4710:01C1FFBD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA07890 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Praveen, > Does that mean that we will be also dealing with autoneogtiation > of services (different applications) between the mobile device and > the edge offering services in this charter ? That is out of scope for the current NSIS charter. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 20 01:43:20 2002 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 BAA15836 for ; Mon, 20 May 2002 01:43:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA08878 for nsis-archive@odin.ietf.org; Mon, 20 May 2002 01:43:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08775; Mon, 20 May 2002 01:38:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08744 for ; Mon, 20 May 2002 01:37:59 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15685 for ; Mon, 20 May 2002 01:37:41 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4K5dMd16909 for ; Mon, 20 May 2002 08:39:22 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 May 2002 08:37:56 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 20 May 2002 08:37:56 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] RE: What's in the charter of NSIS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 20 May 2002 08:37:54 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E11@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: What's in the charter of NSIS Thread-Index: AcH9xQuzO9T3nWbERRyzcJvS2uF1HQB+ou9A To: , , Cc: X-OriginalArrivalTime: 20 May 2002 05:37:56.0273 (UTC) FILETIME=[7E697A10:01C1FFC0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA08745 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Melinda, > I've written a document describing the use of RSVP for firewall > traversal and NAT traversal (which I'll be sending to the secretariat > next week) and another describing the use of of RSVP for IPSec > tunnel endpoint discovery and rudimentary SDB management ("don't > encapsulate this"). The latter will probably not be submitted > in its current form but was interesting to write. > > What I found was 1) the RSVP protocol machinery is *extremely* > well suited to addressing generic middlebox problems, and 2) exactly > what you're saying - some of the required data are inapplicable > to generic middlebox problems (this may apply to the rich variety > of reservation styles, as well). I agree, I think that as a pure signaling protocol, RSVP is not so bad. If one can seperate IntServ from it, and maybe multicast, and add support for some sort of signaling request (maybe some sort of opaque blob) then we'd already have a nice tool for doing some interesting things. In my opinion, NSIS should try to think modestly about the results of our work. I think that producing a nice 'tool' which allows service providers to be able to start offering some services and allowing end-systems to signaling robustly for these services would be a good step forward. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 20 04:35:42 2002 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 EAA00111 for ; Mon, 20 May 2002 04:35:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17902 for nsis-archive@odin.ietf.org; Mon, 20 May 2002 04:35:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17490; Mon, 20 May 2002 04:30:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17450 for ; Mon, 20 May 2002 04:30:47 -0400 (EDT) Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00055 for ; Mon, 20 May 2002 04:30:29 -0400 (EDT) Received: from mannersaari.cs.Helsinki.FI (IDENT:jmanner@mannersaari.cs.Helsinki.FI [128.214.11.173]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g4K8UeB30436 for ; Mon, 20 May 2002 11:30:44 +0300 Date: Mon, 20 May 2002 11:30:36 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Subject: [NSIS] I-D ACTION:draft-manner-lrsvp-00.txt (fwd) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, The concepts presented in this draft were one item for the Interim meeting. The work is still ongoing, but hopefully the draft succeeds in giving a reasonable view of the need and concepts of a localized signalling and our rough technical solution. Hopefully the ideas would provide usefull for the work in NSIS. Best regards, Jukka ---------- Forwarded message ---------- Date: Wed, 15 May 2002 07:11:21 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-manner-lrsvp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Localized RSVP Author(s) : J. Manner et al. Filename : draft-manner-lrsvp-00.txt Pages : 14 Date : 14-May-02 Guaranteed QoS for multimedia applications is based on reserved resources in each node on the end-to-end path. For stationary nodes this may be achieved but not so easily for mobile nodes. Many multimedia applications become less useful if the continuity of QoS is disturbed due to end-to-end signalling or slow re-reservations of resources after each handover. Additionally, if the correspondent node does not support QoS, it would be useful to be able to reserve at least local resources, especially wireless link resources. This draft proposes small modifications to RSVP, so that initial resource reservations and re-reservations due to host mobility can be done locally in an access network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manner-lrsvp-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-manner-lrsvp-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-manner-lrsvp-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. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 20 07:54:46 2002 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 HAA08216 for ; Mon, 20 May 2002 07:54:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA27932 for nsis-archive@odin.ietf.org; Mon, 20 May 2002 07:55:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27188; Mon, 20 May 2002 07:42:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27147 for ; Mon, 20 May 2002 07:42:05 -0400 (EDT) Received: from web11407.mail.yahoo.com (web11407.mail.yahoo.com [216.136.131.237]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07368 for ; Mon, 20 May 2002 07:41:48 -0400 (EDT) Message-ID: <20020520114204.52309.qmail@web11407.mail.yahoo.com> Received: from [146.48.89.63] by web11407.mail.yahoo.com via HTTP; Mon, 20 May 2002 04:42:04 PDT Date: Mon, 20 May 2002 04:42:04 -0700 (PDT) From: Xiaoming Fu Reply-To: fu@ee.tu-berlin.de Subject: RE: [NSIS] RE: What's in the charter of NSIS To: john.loughney@nokia.com, lixia@cs.ucla.edu, gkenward@nortelnetworks.com, sven.van_den_bosch@alcatel.be Cc: Ruediger.Geib@t-systems.com, nsis@ietf.org In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC651EE@esebe004.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, --- john.loughney@nokia.com wrote: > > One can think of the term 'QoS' in the charter as > a use case for the signaling protocol developed in NSIS. > Do you indicate the "use case" is also going to be developed in NSIS? Maybe then we need some format of e.g., QoS object? Thanks. Xiaoming -- fu@ee.tu-berlin.de __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 20 07:55:03 2002 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 HAA08300 for ; Mon, 20 May 2002 07:55:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA27963 for nsis-archive@odin.ietf.org; Mon, 20 May 2002 07:55:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27318; Mon, 20 May 2002 07:44:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27282 for ; Mon, 20 May 2002 07:44:08 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07461 for ; Mon, 20 May 2002 07:43:49 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4KBiRk01790 for ; Mon, 20 May 2002 14:44:27 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 May 2002 14:44:05 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 20 May 2002 14:44:05 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] RE: What's in the charter of NSIS X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 20 May 2002 14:44:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6520B@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: What's in the charter of NSIS Thread-Index: AcH/83EFW1rI43HCQ+CtXD9oeCU5PgAAAw+Q To: Cc: X-OriginalArrivalTime: 20 May 2002 11:44:05.0288 (UTC) FILETIME=[A4F72280:01C1FFF3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA27283 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Xiaoming, > > One can think of the term 'QoS' in the charter as > > a use case for the signaling protocol developed in NSIS. > > Do you indicate the "use case" is also going to be developed in NSIS? > Maybe then we need some format of e.g., QoS object? Thanks. This work would be possible after we fulfill our charter, and recharter the working group. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 20 08:06:49 2002 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 IAA09315 for ; Mon, 20 May 2002 08:06:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29194 for nsis-archive@odin.ietf.org; Mon, 20 May 2002 08:07:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28178; Mon, 20 May 2002 07:56:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28147 for ; Mon, 20 May 2002 07:55:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08470; Mon, 20 May 2002 07:55:40 -0400 (EDT) Message-Id: <200205201155.HAA08470@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: Mon, 20 May 2002 07:55:40 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-02.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --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 : Requirements for QoS Signaling Protocols Author(s) : M. Brunner Filename : draft-ietf-nsis-req-02.txt Pages : 51 Date : 17-May-02 This document defines requirements for signaling QoS across different network environments. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. We also provide an outline structure for the problem, including QoS related terminology. Taken with the scenarios, this allows us to focus more precisely on which parts of the overall QoS problem needs to be solved. We present the assumptions and the aspects not considered within scope before listing the requirements grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-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-req-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-req-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: <20020517135245.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020517135245.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 20 09:00:34 2002 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 JAA12702 for ; Mon, 20 May 2002 09:00:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02755 for nsis-archive@odin.ietf.org; Mon, 20 May 2002 09:00:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01867; Mon, 20 May 2002 08:49:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01836 for ; Mon, 20 May 2002 08:49:26 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12006 for ; Mon, 20 May 2002 08:49:08 -0400 (EDT) Received: by idcpa4.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 08:46:55 -0400 Message-ID: From: "Shaheen, Kamel M." To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Some charter scoping / restrictions Date: Mon, 20 May 2002 08:46:53 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, Does this mean that NSIS is moving toward a direction similar to what SIP is doing? Regards, Kamel Shaheen, Ph.D. InterDigital Communications -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Sun, May 19, 2002 1:13 PM To: nsis@ietf.org Subject: [NSIS] Some charter scoping / restrictions Hi all, Even before the last few email discussions on NSIS & its charter, the Area Directors and I had a small chat. There is some worry that some of the discussion on the list is distinctly out of scope, and here is the scoping that we have come up with: NSIS will work on signaling from an end system that follows a path through the net that is determined by the normal L3 routing and is used to convey per-flow information to the devices the signals pass through - the signaling can install soft state (maintained by repetition) in the devices it passes through. An end system could be a device along the path that signals for a data flow that passes through it. There is no requirement that the per-flow information be QoS related i.e. NSIS should only worry about how to do the signaling - what the signaling conveys should be opaque to NSIS. QoS has been thought of the first application of such a system, and used to help focus discussion. However, it seems that QoS has done the opposite, and created divergence from the charter. This rules out bandwidth brokers, 3rd party QoS controllers, hard state, etc. After we fufill the above stated goals, the WG could move on to other things (like BBs). This is as definitive statement as can be made. Best regards John, Scott & Allison _______________________________________________ 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 daemon@optimus.ietf.org Mon May 20 09:45:43 2002 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 JAA16621 for ; Mon, 20 May 2002 09:45:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05530 for nsis-archive@odin.ietf.org; Mon, 20 May 2002 09:46:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04325; Mon, 20 May 2002 09:29:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04296 for ; Mon, 20 May 2002 09:29:33 -0400 (EDT) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14517 for ; Mon, 20 May 2002 09:29:13 -0400 (EDT) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id PAA03837; Mon, 20 May 2002 15:28:51 +0200 (MEST) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id g4KDSJQ28631; Mon, 20 May 2002 15:28:19 +0200 Message-Id: <200205201328.g4KDSJQ28631@KOM.tu-darmstadt.de> Subject: Re: [NSIS] RE: What's in the charter of NSIS In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E11@esebe004.NOE.Nokia.com> from "john.loughney@nokia.com" at "May 20, 2002 08:37:54 am" To: nsis@ietf.org Date: Mon, 20 May 2002 15:28:19 +0200 (CEST) CC: mshore@cisco.com, Utz Roedig X-Mailer: ELM [version 2.4ME+ PL66 (25)] 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > > What I found was 1) the RSVP protocol machinery is *extremely* > > well suited to addressing generic middlebox problems, and 2) exactly > > what you're saying - some of the required data are inapplicable > > to generic middlebox problems (this may apply to the rich variety > > of reservation styles, as well). > > I agree, I think that as a pure signaling protocol, RSVP is not > so bad. If one can seperate IntServ from it, and maybe multicast, > and add support for some sort of signaling request (maybe > some sort of opaque blob) then we'd already have a nice > tool for doing some interesting things. I fully agree. We have once built a small prototype to use RSVP as a firewall signalling protocol: http://www.kom.e-technik.tu-darmstadt.de/publications/abstracts/RGKS01-1.html Longer version at: http://www.kom.e-technik.tu-darmstadt.de/publications/abstracts/RGKS00-1.html Starting with RSVP, thinking again carefully about group communication (multicast, multi-sender and filter styles) and adding new features in a modular way. That seems to be a very reasonable mixture. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 21 01:57:33 2002 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 BAA11380 for ; Tue, 21 May 2002 01:57:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA24332 for nsis-archive@odin.ietf.org; Tue, 21 May 2002 01:57:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23561; Tue, 21 May 2002 01:43:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23530 for ; Tue, 21 May 2002 01:43:16 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10691 for ; Tue, 21 May 2002 01:42:59 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4L5hdk26713 for ; Tue, 21 May 2002 08:43:39 +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, 21 May 2002 08:43:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 21 May 2002 08:43:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Some charter scoping / restrictions Date: Tue, 21 May 2002 08:43:14 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6521D@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Some charter scoping / restrictions Thread-Index: AcH//Le1CLvBREyEToWzzXsP1qgtOgAjYdow To: , X-OriginalArrivalTime: 21 May 2002 05:43:15.0036 (UTC) FILETIME=[66D299C0:01C2008A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA23531 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Kamel, > Does this mean that NSIS is moving toward a direction similar > to what SIP is doing? SIP messages don't follow the routing (or media) path, is working at a different layer. Beside those comments, I'm not exactly sure what you mean. Could you be more specific? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 21 02:04:20 2002 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 CAA16864 for ; Tue, 21 May 2002 02:04:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA24941 for nsis-archive@odin.ietf.org; Tue, 21 May 2002 02:04:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24001; Tue, 21 May 2002 01:51:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23958 for ; Tue, 21 May 2002 01:51:49 -0400 (EDT) Received: from eudoramail.com ([217.78.74.104]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11107 for ; Tue, 21 May 2002 01:51:18 -0400 (EDT) Message-Id: <200205210551.BAA11107@ietf.org> From: "michael onyeze" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 20 May 2003 18:45:03 +0200 Reply-To: "michael onyeze" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [NSIS] (no subject) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Mr.Michael Onyeze. 178 Dikko close Lagos-Nigeria Fax:234 1 7591693 Attn: President/Ceo. In order to transfer out Fifty Two Million United States Dollars from African Development Bank. I wish to ask for your assistance, believing that you will never let me down either now or in future. I got your e-mail address from the e-mail directory in the internet. I am Mr. Michael Onyeze, the Chief Auditor of African Development Bank (ADB). There was an account opened in this bank in 1983 and since 1989 nobody has operated on this account till date. After my long investigation to my greatest suprise I came to find out that the owner of the account who is Mr.Peter B. Andreas, a foreigner, crude oil exporter, who died in 1990. This account has no beneficiary, infact no other person knows about this account or anything about the account, and my investigation proved to me as well that this company does not exist anymore in NIgeria. The amount involved is USD 52M, which i seek your consent to transfer to a safe foreign account. I do not know any foreigner that i can trust either than you, I am only contacting you as a foreigner because this money can not be claimed by a Nigerian because the rightful owner of the account (Mr. Peter) is a foreigner and has dead. I know that this mail will come to you as a surprise as we do not know each other before hand. we will be needed to sign an Agreement as a security so that we cannot betray the trust that will be given to each other in this legitimate and joint venture, which demand utmost secrecy and confidential. I am contacting you because of the need to involve a foreigner with foreign account and foreign beneficiary. I need your full co-operation for us to have a successful transaction. Because the management is ready to approve this payment to any foreigner who has correct information of this account, which I will give to you immediately i receive your positive reply. With my position now in the office I can authorise the immediate transfer of this money to any foreign reliable account which you can provide with assurance that this money will be intact pending my physical arrival in your country for sharing and further investment. I will destroy all documents used in this transaction immediately we must have transferred this money to your nominated account sucessfully, so as to avoid any document trace by any person. I will apply for annual leave to get visa to your country immediately you confirm me that you are willing to assist me. I will also use my position and influence to effect legal approvals and onward transfer of this money to your account with appropriate clearance forms of the ministries and foreign exchange departments. At the conclusion of this business, you will be given 20% of the total amount, 75% will be for me, while 5% will be for expenses both parties might have incurred during the process of transferring. Awaiting your urgent reply and please do not FORGET TO INCLUDE YOUR PRIVATE FAX AND TELEPHONE NUMBERS FOR EASY COMMUNICATION. Thank you and God bless. Yours truly, Mr.Michael Onyeze. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 21 07:44:50 2002 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 HAA05408 for ; Tue, 21 May 2002 07:44:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA12658 for nsis-archive@odin.ietf.org; Tue, 21 May 2002 07:45:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11559; Tue, 21 May 2002 07:30:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11520 for ; Tue, 21 May 2002 07:30:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04780; Tue, 21 May 2002 07:30:05 -0400 (EDT) Message-Id: <200205211130.HAA04780@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, 21 May 2002 07:30:05 -0400 Subject: [NSIS] I-D ACTION:draft-hancock-nsis-fw-outline-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Outline Framework for QoS Signalling Protocols Author(s) : R. Hancock, E. Hepworth Filename : draft-hancock-nsis-fw-outline-00.txt Pages : 14 Date : 20-May-02 The Next-Steps-in-Signalling (NSIS) working group of the IETF is considering the requirements for QoS signalling protocols [2]. One element of this, and follow up work, is to develop a framework within which existing and proposed protocols can be analysed, and which captures how QoS signalling protocols should interact, both with each other and with other components of the Internet, such as routing protocols or AAA mechanisms. Because of this aspect of interactions, the scope of an NSIS framework is necessarily broader than the scope of any new NSIS protocol. Previous work suggests that a complete QoS signalling framework is a major undertaking. This Internet Draft outlines the principal components of such a framework and their interrelationships. It could be used as a starting point for more detailed investigation of individual components. It could also be used to refine the scope of NSIS more precisely, both in terms of what functions are to be considered and how many variant approaches are relevant. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-outline-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-hancock-nsis-fw-outline-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-hancock-nsis-fw-outline-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: <20020520143148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hancock-nsis-fw-outline-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hancock-nsis-fw-outline-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520143148.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 21 08:01:09 2002 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 IAA06148 for ; Tue, 21 May 2002 08:01:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13809 for nsis-archive@odin.ietf.org; Tue, 21 May 2002 08:01:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12612; Tue, 21 May 2002 07:44:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12581 for ; Tue, 21 May 2002 07:44:50 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05395 for ; Tue, 21 May 2002 07:44:32 -0400 (EDT) Received: by idcpa4.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 07:42:12 -0400 Message-ID: From: "Shaheen, Kamel M." To: "'john.loughney@nokia.com'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Some charter scoping / restrictions Date: Tue, 21 May 2002 07:42:04 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, I agree with some of your comments about the routing of SIP and the underlaying media (they do not necessary follow the same route, but nothing prevent some cases from doing so specially in the IP cloud). In 3GPP, SIP is used to carry some QoS information and is used to initiate resources reservation at least inside 3GPP system not through out the IP network. And this is where I see the convergence at least in the paradigm level. May be I mistaken but I thought that SIP and RSVP are operating on similar layers on top of IP. Kamel -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Tue, May 21, 2002 1:43 AM To: Kamel.Shaheen@interdigital.com; Subject: RE: [NSIS] Some charter scoping / restrictions Hi Kamel, > Does this mean that NSIS is moving toward a direction similar > to what SIP is doing? SIP messages don't follow the routing (or media) path, is working at a different layer. Beside those comments, I'm not exactly sure what you mean. Could you be more specific? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 21 12:30:23 2002 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 MAA17627 for ; Tue, 21 May 2002 12:30:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29696 for nsis-archive@odin.ietf.org; Tue, 21 May 2002 12:30:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28295; Tue, 21 May 2002 12:14:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28264 for ; Tue, 21 May 2002 12:14:18 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16346 for ; Tue, 21 May 2002 12:13:58 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LGCsV01314; Tue, 21 May 2002 12:12:54 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 12:12:57 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4AEB@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" , braden@ISI.EDU, lixia@CS.UCLA.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] RE: What's in the charter of NSIS Date: Tue, 21 May 2002 12:13:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C200E2.621D4710" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C200E2.621D4710 Content-Type: text/plain; charset="iso-8859-1" John: And, if you look back into the archives, you will notice that I have made the same point a number of times - that NSIS should not be defining QoS or QoS objects. However, we did get into a rat hole on resource allocation, and in the discussion, the role of NSIS in conveying bandwidth requirements (as part of the QoS object), and perhaps interacting with important control points such as admission control, seemed to become unclear. I was simply trying to clarify this when I was criticized for following the thread, and I must say, adhering to the charter. I note that the charter does not say that "QoS is a use case scenario for a general signalling protocol". It may be useful to say that NSIS is the first step in a series of evolutionary generations of a general protocol. But the intent should be clear, not "implied". References to QoS signalling appear in almost every paragraph, and I cannot find any references to other types of signalling that NSIS itself is supposed to support. So, are Bob and Lixia correct in their criticism of my posting? Should we start talking about the general requirements for signalling? Or, should we continue as we have been, trying to solidify the requirements for QoS signalling, which seems to be contentious enough. I think it is dangerous to pretend that NSIS will be a general protocol, when the only application driving the requirements and the framework is QoS. And, I do not know how we can discuss these specific requirements, without being focussed on QoS. Gary -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: May 19, 2002 12:56 To: Kenward, Gary [WDLN2:AN10:EXCH]; braden@ISI.EDU; lixia@CS.UCLA.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] RE: What's in the charter of NSIS Hi Gary, I have yet to understand your point. If you feel the current document is missing something, please speak up. Right now, I am under the assumption that the WG will not define the format of the QoS object to be signaled. John -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 17 May, 2002 20:14 To: 'Bob Braden'; Loughney John (NRC/Helsinki); lixia@CS.UCLA.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] RE: What's in the charter of NSIS It is a valid observation that my point was very much into the detail. However, it had nothing to do with how Int Serv, Diff Serv or any other QoS model happens to work. It had everything to do with the on-going thread as to whether NSIS was chartered to look at resource allocation (which is not). I was simply attempting to draw a distinction between QoS specification and resource allocation. In no way did I intend d to imply, nor do I believe that I actually implied, that NSIS was building the next QoS "model". As for the point that Lixia was making, I think it is a valid one, However, correct me if I am wrong here, but the charter states: "This working group will develop the requirements, architecture and protocols for the next IETF steps on signalling QoS. The working group will use existing IETF signalling as the basis for this work, evaluating RSVP in particular as the starting point. Additionally, the working group will consider how to signal QoS (what sort of QoS parameters to use), and where to signal (end-to-end, end-to-edge, end-to-proxy, edge-to-edge, etc.)." Sounds like NSIS is really NSIQoSS, if one was to worry about names (a rose is a rose . . .). Finally, I do agree that NSIS should absolutely be defined with some attention to future needs, as long as we keep it real. Predicting the future is neither easy, nor reliable. Cheers, Gary > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: May 17, 2002 12:47 > To: john.loughney@nokia.com; lixia@CS.UCLA.EDU > Cc: nsis@ietf.org > Subject: Re: [NSIS] RE: What's in the charter of NSIS > > > > Lixia wrote: > > ... > > *> > *> But I cannot help throwing a comment on this specific > one: NSIS stands for > *> "Next Step in Signaling", not next step in QOS. > *> > *> I personally do NOT think a signaling protocol should > involve itself into > *> the definitions of what QOS requirements should be. > *> QOS requirements may change over time, yet one wishes > that the signaling > *> protocol, which is used to carry the QOS requirements, > does NOT have to > *> change. > *> > *> Besides, there WILL be other uses of a signaling > protocol other than QOS > *> need. My understanding is that NSIS is chartered to > look into the need for > *> a signaling protocol, NOT the QOS requirement. > *> > > I want to say "amen" to all of that. > > The original message from Gary Kenward included, "... QoS > specifications such as the Tspec." The Tspec is not by itself a QoS > specification. In fact, even talking about "a QoS > specification" is to > oversimplify a complex process, which may involve two passes, one pass > with advertising, etc. There are many possible QoS models; int-serv > chose just two of them. And NSIS should choose NONE of them; a > next-generation signaling protocol should be able to handle any future > model. > > This observation, together with Lixia's comment, leads me to the > realization that RSVP may have had the modularity wrong (and > NSIS might > pay attention to this point). RSVP design and specification may ahve > talked too much about int-serv specific things like Tspecs. We should > instead have defined RSVP strictly in terms of transporting opaque QoS > objects upstream and downstream, and applying some model-specific > algorithms at merge and branch points. The definition of > these objects > and algorithms would then be completely contained in documents that > define QoS models. > > Our vision was imperfect when we began the Internet > integrated services > work in 1993. If we had gotten the modularity better, we > would perhaps > have avoided some of the immense amount of misunderstanding that is > still current about Internet QoS issues. > > BTW, see draft-braden-2level-signal-arch-00.txt for a glimmer of a > better modularity. > > Bob Braden > > > > > *> My personal 2 cents, > *> Lixia > *> > *> > *> _______________________________________________ > *> 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 > ------_=_NextPart_001_01C200E2.621D4710 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] RE: What's in the charter of NSIS

John:

  And, if you look back into the archives, you will notice that I have made the
same point a number of times - that NSIS should not be defining QoS or QoS
objects. However, we did get into a rat hole on resource allocation, and in the
discussion, the role of NSIS in conveying bandwidth requirements (as part of
the QoS object), and perhaps interacting with important control points such as
admission control, seemed to become unclear.

  I was simply trying to clarify this when I was criticized for following the thread,
and I must say, adhering to the charter. I note that the charter does not say that
"QoS is a use case scenario for a general signalling protocol".

  It may be useful to say that NSIS is the first step in a series of evolutionary generations
of a general protocol. But the intent should be clear, not "implied". References to QoS signalling
appear in almost every paragraph, and I cannot find any references to other types of signalling that
NSIS itself is supposed to support. So, are Bob and Lixia correct in their criticism of my posting?
Should we start talking about the general requirements for signalling? Or, should we continue as
we have been, trying to solidify the requirements for QoS signalling, which seems to be contentious
enough.

  I think it is  dangerous to pretend that NSIS will be a general protocol, when the only application
driving the requirements and the framework is QoS. And, I do not know how we can discuss these specific
requirements, without being focussed on QoS.

Gary

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: May 19, 2002 12:56
To: Kenward, Gary [WDLN2:AN10:EXCH]; braden@ISI.EDU; lixia@CS.UCLA.EDU
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: What's in the charter of NSIS


Hi Gary,
 
I have yet to understand your point.  If you feel the current
document is missing something, please speak up.
 
Right now, I am under the assumption that the WG will
not define the format of the QoS object to be signaled.
 
John
-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 17 May, 2002 20:14
To: 'Bob Braden'; Loughney John (NRC/Helsinki); lixia@CS.UCLA.EDU
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: What's in the charter of NSIS


It is a valid observation that my point was very much into the
detail. However, it had nothing to do with how Int Serv, Diff
Serv or any other QoS model happens to work. It had everything
to do with the on-going thread as to whether NSIS was chartered
to look at resource allocation (which is not). I was simply attempting
to draw a distinction between QoS specification and resource allocation.
In no way did I intend d to imply, nor do I believe that I actually implied,
that NSIS was building the next QoS "model".
As for the point that Lixia was making, I think it is a valid one,
However, correct me if I am wrong here, but the charter states:
"This working group will develop the requirements, architecture and
protocols for the next IETF steps on signalling QoS. The working group
will use existing IETF signalling as the basis for this work, evaluating
RSVP in particular as the starting point. Additionally, the working
group will consider how to signal QoS (what sort of QoS parameters to
use), and where to signal (end-to-end, end-to-edge, end-to-proxy,
edge-to-edge, etc.)."
Sounds like NSIS is really NSIQoSS, if one was to worry about names
(a rose is a rose . . .).
Finally, I do agree that NSIS should absolutely be defined with some
attention to future needs, as long as we keep it real. Predicting
the future is neither easy, nor reliable.
Cheers,
Gary
> -----Original Message-----
> From: Bob Braden [mailto:braden@ISI.EDU]
> Sent: May 17, 2002 12:47
> To: john.loughney@nokia.com; lixia@CS.UCLA.EDU
> Cc: nsis@ietf.org
> Subject: Re: [NSIS] RE: What's in the charter of NSIS
>
>
>
> Lixia wrote:
>
> ...
>
>   *>
>   *> But I cannot help throwing a comment on this specific
> one: NSIS stands for
>   *> "Next Step in Signaling", not next step in QOS.
>   *>
>   *> I personally do NOT think a signaling protocol should
> involve itself into
>   *> the definitions of what QOS requirements should be.
>   *> QOS requirements may change over time, yet one wishes
> that the signaling
>   *> protocol, which is used to carry the QOS requirements,
> does NOT have to
>   *> change.
>   *>
>   *> Besides, there WILL be other uses of a signaling
> protocol other than QOS
>   *> need.  My understanding is that NSIS is chartered to
> look into the need for
>   *> a signaling protocol, NOT the QOS requirement.
>   *>
>
> I want to say "amen" to all of that.
>
> The original message from Gary Kenward included, "... QoS
> specifications such as the Tspec." The Tspec is not by itself a QoS
> specification.  In fact, even talking about "a QoS
> specification" is to
> oversimplify a complex process, which may involve two passes, one pass
> with advertising, etc.  There are many possible QoS models; int-serv
> chose just two of them.  And NSIS should choose NONE of them; a
> next-generation signaling protocol should be able to handle any future
> model.
>
> This observation, together with Lixia's comment, leads me to the
> realization that RSVP may have had the modularity wrong (and
> NSIS might
> pay attention to this point).  RSVP design and specification may ahve
> talked too much about int-serv specific things like Tspecs.  We should
> instead have defined RSVP strictly in terms of transporting opaque QoS
> objects upstream and downstream, and applying some model-specific
> algorithms at merge and branch points.  The definition of
> these objects
> and algorithms would then be completely contained in documents that
> define QoS models.
>
> Our vision was imperfect when we began the Internet
> integrated services
> work in 1993.  If we had gotten the modularity better, we
> would perhaps
> have avoided some of the immense amount of misunderstanding that is
> still current about Internet QoS issues.
>
> BTW, see draft-braden-2level-signal-arch-00.txt for a glimmer of a
> better modularity.
>
> Bob Braden
>
>
>
>
>   *> My personal 2 cents,
>   *> Lixia
>   *>
>   *>
>   *> _______________________________________________
>   *> 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
>

------_=_NextPart_001_01C200E2.621D4710-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue May 21 18:15:48 2002 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 SAA03604 for ; Tue, 21 May 2002 18:15:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA18980 for nsis-archive@odin.ietf.org; Tue, 21 May 2002 18:16:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17780; Tue, 21 May 2002 17:59:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17699 for ; Tue, 21 May 2002 17:59:14 -0400 (EDT) Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [203.61.155.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02845 for ; Tue, 21 May 2002 17:58:47 -0400 (EDT) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id g4LLvKU10278; Wed, 22 May 2002 07:57:20 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id g4LLwvP03763; Wed, 22 May 2002 07:58:58 +1000 (EST) Received: from ericsson.com.au (dhcp-239-96.epa.ericsson.se [146.11.239.96]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L2S8QAX1; Wed, 22 May 2002 07:58:56 +1000 Message-ID: <3CEAC304.4030000@ericsson.com.au> Date: Wed, 22 May 2002 07:58:28 +1000 From: Brian Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shaheen, Kamel M." CC: "'john.loughney@nokia.com'" , "'nsis@ietf.org'" Subject: Re: [NSIS] Some charter scoping / restrictions References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi All. I just though I should correct some statements here. /brian Shaheen, Kamel M. wrote: > Hi John, > In 3GPP, SIP is used to carry some QoS information and is used to initiate > resources reservation at least inside 3GPP system not through out the IP > network. And this is where I see the convergence at least in the paradigm > level. SIP carries SDP which is used by 3GPP to derive QoS related information. The UE initiates all resource reservation, which typically will use information from the SIP/SDP. However, SIP itself does not initiate the resource reservation in any way. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 22 14:02:02 2002 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 OAA22292 for ; Wed, 22 May 2002 14:02:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12420 for nsis-archive@odin.ietf.org; Wed, 22 May 2002 14:02:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11045; Wed, 22 May 2002 13:44:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11007 for ; Wed, 22 May 2002 13:44:34 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21516 for ; Wed, 22 May 2002 13:44:11 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MHi1q20468; Wed, 22 May 2002 12:44:01 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 12:44:08 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03CEF930@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Some charter scoping / restrictions Date: Wed, 22 May 2002 12:44:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201B8.45983B50" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org 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_01C201B8.45983B50 Content-Type: text/plain; charset="iso-8859-1" First of all, thank you very much for re-affirming the scope. I could use a little more elaboration on this sentence, though. Can you give an example of what you mean, exactly by this: > > An end system could be a device along the path that signals for a data > flow that passes through it. > I.e. do you mean "should initially be considered to" instead of "could". I'm just trying to hammer down exactly where the line in the sand has been drawn for immediate attention. Thanks, Glenn ------_=_NextPart_001_01C201B8.45983B50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Some charter scoping / restrictions

First of all, thank you very much for re-affirming = the scope.

I could use a little more elaboration on this = sentence, though. Can you give an example of what you mean, exactly by = this:

>
> An end system could be a device along the path = that signals for a data
> flow that passes through it.
>

I.e. do you mean "should initially be considered = to" instead of "could".

I'm just trying to hammer down exactly where the line = in the sand has been drawn for immediate attention.

Thanks,

Glenn

------_=_NextPart_001_01C201B8.45983B50-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 22 14:51:38 2002 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 OAA25004 for ; Wed, 22 May 2002 14:51:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15548 for nsis-archive@odin.ietf.org; Wed, 22 May 2002 14:51:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15020; Wed, 22 May 2002 14:38:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14991 for ; Wed, 22 May 2002 14:38:31 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24421 for ; Wed, 22 May 2002 14:38:07 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4MIcmk06233 for ; Wed, 22 May 2002 21:38:48 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 May 2002 21:38:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 21:38:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [NSIS] Some charter scoping / restrictions Date: Wed, 22 May 2002 21:38:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E1A@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Some charter scoping / restrictions Thread-Index: AcIBuD0mlfySU4iqS+S4KoWu/LefrwABxxNE To: , X-OriginalArrivalTime: 22 May 2002 18:38:24.0532 (UTC) FILETIME=[DB0E3D40:01C201BF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id OAA14992 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Glenn, > I could use a little more elaboration on this sentence, though. Can you give an example of > what you mean, exactly by this: > > > > An end system could be a device along the path that signals for a data > > flow that passes through it. > > > I.e. do you mean "should initially be considered to" instead of "could". NSIS, hopefully, will come up with a modular framework, which will allow a device along the path to signaling on behalf of a flow that passes through it. It should also allow the endpoint to do the signaling itself. It seems that your question is alot more deployment oriented, and deployment is not within scope of NSIS. So, the term you use 'should initially be' is inappropriate for the charter, but could possibly find its way into the framework if there was support for it. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 22 15:20:32 2002 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 PAA26505 for ; Wed, 22 May 2002 15:20:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17459 for nsis-archive@odin.ietf.org; Wed, 22 May 2002 15:20:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16705; Wed, 22 May 2002 15:05:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16661 for ; Wed, 22 May 2002 15:05:53 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25747 for ; Wed, 22 May 2002 15:05:30 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4MJ5HEU009602 for ; Wed, 22 May 2002 12:05:17 -0700 (PDT) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADY24846; Wed, 22 May 2002 12:02:22 -0700 (PDT) Message-Id: <5.1.0.14.0.20020522150820.00a8cec0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 22 May 2002 15:09:44 -0400 To: nsis@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [NSIS] Fwd: I-D ACTION:draft-shore-tist-prot-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I written up a straw proposal for using RSVP to talk to firewall and NAT-type middleboxes that may be interesting for people considering other applications of NSIS beyond QoS. Thanks, Melinda >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-shore-tist-prot-00.txt >Date: Tue, 21 May 2002 07:31:41 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The TIST (Topology-Insensitive Service Traversal) > Protocol > Author(s) : M. Shore > Filename : draft-shore-tist-prot-00.txt > Pages : 19 > Date : 20-May-02 > >TIST is an application of the RSVP protocol to the problem of com- >municating application requests, such as pinhole openings and NAT >table entries, to NATs and firewalls. By using RSVP we avoid the >problem of having to locate these devices in the network and estab- >lish trusted relationships with each one we would like to influ- >ence. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-shore-tist-prot-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-shore-tist-prot-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-shore-tist-prot-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. >Content-Type: text/plain >Content-ID: <20020520150931.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-shore-tist-prot-00.txt > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 22 17:17:00 2002 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 RAA01628 for ; Wed, 22 May 2002 17:16:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24033 for nsis-archive@odin.ietf.org; Wed, 22 May 2002 17:17:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23510; Wed, 22 May 2002 17:03:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23480 for ; Wed, 22 May 2002 17:03:56 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00598 for ; Wed, 22 May 2002 17:03:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11818; Wed, 22 May 2002 14:03:19 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [129.146.200.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25275; Wed, 22 May 2002 14:03:18 -0700 (PDT) Received: from sun.com (vpn-129-149-241-78.SFBay.Sun.COM [129.149.241.78]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g4ML3GN03360; Wed, 22 May 2002 14:03:16 -0700 (PDT) Message-ID: <3CEC07FC.7E76A62D@sun.com> Date: Wed, 22 May 2002 17:05:00 -0400 From: Mauricio Arango X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: Kamel.Shaheen@InterDigital.com, nsis@ietf.org Subject: Re: [NSIS] Some charter scoping / restrictions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6521D@esebe004.NOE.Nokia.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit John, I think Kamel's message raises a valid point by asking about NSIS's relationship with SIP. Assuming NSIS is about next steps in signaling, general purpose and not just QoS, the effort should address its relationship with key existing signaling protocols, SIP being one of them. Regarding the NSIS requirement of following paths determined by L3 routing, it is something that SIP messages do when traveling between a SIP user agent (NSIS end-system) and a SIP proxy, or between SIP proxys. With SIP, if an end system chooses the next hop as the other end system (no intermediate proxys), messages between them will follow a L3-routed path. However, a combination of L3 routing and higher-level routing could be convenient for NSIS. For example one may want to have L3 routing from an end system up to a certain edge router, and then to follow higher level routing between proxys. I believe this has been also addressed for RSVP in: draft-ietf-rsvp-proxy-03.txt Additional reasons for considering SIP include its use of SDP to describe what is being negotiated as well as all the other mechanisms for setting up, modifying and terminating general purpose sessions. SIP is one possibility, there are others, in general these are general-purpose protocols for transporting control information over overlay networks on top of IP transport. These overlay networks assume the use of relays (proxys) that provide higher level routing. Other examples to think about are BEEP/APEX and JXTA. Regards, Mauricio Arango -------------------- john.loughney@nokia.com wrote: > > Hi Kamel, > > > Does this mean that NSIS is moving toward a direction similar > > to what SIP is doing? > > SIP messages don't follow the routing (or media) path, is working > at a different layer. > > Beside those comments, I'm not exactly sure what you mean. Could > you be more specific? > > 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 daemon@optimus.ietf.org Thu May 23 03:53:03 2002 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 DAA29472 for ; Thu, 23 May 2002 03:53:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA00383 for nsis-archive@odin.ietf.org; Thu, 23 May 2002 03:53:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00130; Thu, 23 May 2002 03:38:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00103 for ; Thu, 23 May 2002 03:38:18 -0400 (EDT) Received: from fw11.telekom.de (gw11.telekom.de [62.225.183.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29292 for ; Thu, 23 May 2002 03:37:57 -0400 (EDT) Received: by fw11.telekom.de; (8.8.8/1.3/10May95) id JAA23358; Thu, 23 May 2002 09:37:01 +0200 (MET DST) Received: from g8pbr.blf01.telekom.de by G8PXB.blf01.telekom.de with ESMTP; Thu, 23 May 2002 09:37:28 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 09:36:13 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Some charter scoping / restrictions Date: Thu, 23 May 2002 09:36:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA00104 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John > NSIS, hopefully, will come up with a modular framework, which > will allow a device along the path to signaling on behalf of > a flow that passes through it. > It should also allow the endpoint to do the signaling itself. If proxies and centralised service management are out of scope the endpoint must signal for itself. Is it possible to trigger an endpoint externally to start some NSIS signaling? I'm only asking because that's how RSVP-TE signaling is used. "Endpoint" is some kind of service termination point. The data flow on which "service" is applied could transit through that signaling/service endpoint. The charter should explain this optional difference between service termination and data flow termination. I'd too appreciate if the next charter clearly says what's in scope of NSIS and what isn't. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 24 03:00:14 2002 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 DAA18945 for ; Fri, 24 May 2002 03:00:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22332 for nsis-archive@odin.ietf.org; Fri, 24 May 2002 03:00:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21488; Fri, 24 May 2002 02:35:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21457 for ; Fri, 24 May 2002 02:35:13 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18575 for ; Fri, 24 May 2002 02:34:52 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4O6ZZk04317 for ; Fri, 24 May 2002 09:35:35 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 May 2002 09:35:12 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 May 2002 09:35:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [NSIS] Some charter scoping / restrictions Date: Fri, 24 May 2002 09:35:11 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65264@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Some charter scoping / restrictions Thread-Index: AcICLMwjAa0qIdyGTUKR/Vy8Avl52wAwAHzg To: Cc: X-OriginalArrivalTime: 24 May 2002 06:35:12.0034 (UTC) FILETIME=[27F00020:01C202ED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id CAA21458 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger > If proxies and centralised service management are out of scope > the endpoint must signal for itself. Is it possible to trigger > an endpoint externally to start some NSIS signaling? I'm only > asking because that's how RSVP-TE signaling is used. Proxies are not out of scope & the ADs have expressed concerns that centralized service management is outside of the initial scope of the WG. There may be some use in documenting some of the needs of centralized resource management on signaling, perhaps in the framework and can be used to note future work needed. > "Endpoint" is some kind of service termination point. The data > flow on which "service" is applied could transit through that > signaling/service endpoint. The charter should explain this > optional difference between service termination and data > flow termination. I'm not sure that the charter is the right place, but I think the framwork document would be appropriate. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 24 04:53:09 2002 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 EAA20545 for ; Fri, 24 May 2002 04:53:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA27182 for nsis-archive@odin.ietf.org; Fri, 24 May 2002 04:53:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25948; Fri, 24 May 2002 04:27:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25917 for ; Fri, 24 May 2002 04:27:25 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20138 for ; Fri, 24 May 2002 04:27:04 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4O8QCY09632 for ; Fri, 24 May 2002 11:26:12 +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 ; Fri, 24 May 2002 11:27:22 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 May 2002 11:27:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 24 May 2002 11:27:22 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6526E@esebe004.NOE.Nokia.com> Thread-Topic: I-D ACTION:draft-ymbk-arch-guidelines-00.txt Thread-Index: AcIAyq97InUSziJlTjG8KzQDLgzIcQCMeBXw To: X-OriginalArrivalTime: 24 May 2002 08:27:22.0791 (UTC) FILETIME=[D3C80370:01C202FC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA25918 Subject: [NSIS] FW: I-D ACTION:draft-ymbk-arch-guidelines-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Here is an interesting document to consider when we make our framework. John > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 21 May, 2002 14:31 > Subject: I-D ACTION:draft-ymbk-arch-guidelines-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Some Internet Architectural > Guidelines and Philosophy > Author(s) : R. Bush, T. Griffin, D. Meyer > Filename : draft-ymbk-arch-guidelines-00.txt > Pages : 26 > Date : 20-May-02 > > RFC 1958 [RFC1958] describes the underlying principles of the > Internet architecture. This note extends that work by outlining some > of the philosophical guidelines to which architects and designers of > Internet backbone networks should adhere. While many of the areas > outlined in this document may be controversial, the unifying > principle described here, controlling complexity as a mechanism to > control costs and reliability, should not be. Complexity in carrier > networks networks can derive from many sources. However, as stated in > [DOYLE2002], 'Complexity in most systems is driven by the need for > robustness to uncertainty in their environments and component parts > far more than by basic functionality'. Thus the major thrust of this > document is to raise awareness about the complexity of some of our > current architectures, and to examine the effect such complexity will > almost certainly have on the IP carrier industry's ability to > succeed. > The rest of this document is organized as follows: The first section > describes the Simplicity Principle. The remainder of the document > outlines the high-level consequences of the Simplicity Principle and > how it should guide large scale network architecture and design > approaches. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ymbk-arch-guidelines-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-ymbk-arch-guidelines-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-ymbk-arch-guidelines-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. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 24 08:09:24 2002 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 IAA24955 for ; Fri, 24 May 2002 08:09:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06138 for nsis-archive@odin.ietf.org; Fri, 24 May 2002 08:09:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04965; Fri, 24 May 2002 07:56:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04936 for ; Fri, 24 May 2002 07:56:00 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24414 for ; Fri, 24 May 2002 07:55:39 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA10797 for ; Fri, 24 May 2002 13:55:57 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA29533 for ; Fri, 24 May 2002 13:55:58 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 13:55:57 +0200 Message-ID: From: Ersue Mehmet To: "'nsis@ietf.org'" Date: Fri, 24 May 2002 13:55:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [NSIS] NSIS Threats as I-D Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Dear all, I submitted on behalf of Hannes the NSIS threats draft as an I-D. This draft has been already posted to the WG maillist and discussed in Helsinki interim meeting this week. Please find a copy of the I-D on following URL: http://www.ersue.de/nsis/draft-tschofenig-nsis-threats-00.txt Regards, Mehmet _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 24 10:49:31 2002 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 KAA00636 for ; Fri, 24 May 2002 10:49:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14870 for nsis-archive@odin.ietf.org; Fri, 24 May 2002 10:49:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14070; Fri, 24 May 2002 10:32:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14031 for ; Fri, 24 May 2002 10:32:55 -0400 (EDT) Received: from mail.alcatel.co.uk (mail.alcatel.co.uk [195.92.62.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00188 for ; Fri, 24 May 2002 10:32:34 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bt0g2p.god.bel.alcatel.be (relay01.net.alcatel.co.uk [127.0.0.1]) by mail.alcatel.co.uk (8.11.0/8.9.3) with ESMTP id g4OEWrV17281 for ; Fri, 24 May 2002 15:32:53 +0100 Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g4OEUWg21090 for ; Fri, 24 May 2002 16:30:32 +0200 To: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 24 May 2002 16:32:46 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/24/2002 16:32:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] tequila website Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi all, At the interim meeting I promised to provide a pointer to the work that was carried out in the IST Tequila project. The URL for this is: http://www.ist-tequila.org Sven. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun May 26 14:36:00 2002 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 OAA27434 for ; Sun, 26 May 2002 14:35:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22543 for nsis-archive@odin.ietf.org; Sun, 26 May 2002 14:36:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21749; Sun, 26 May 2002 14:21:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21720 for ; Sun, 26 May 2002 14:21:57 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27297 for ; Sun, 26 May 2002 14:21:33 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4QIIYq29706 for ; Sun, 26 May 2002 21:22:19 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 26 May 2002 21:18:09 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 26 May 2002 21:18:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 26 May 2002 21:18:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E2B@esebe004.NOE.Nokia.com> Thread-Topic: Interim Meeting Report Thread-Index: AcIE4a/urE2imhwTSCS3l79tOaO2fA== To: X-OriginalArrivalTime: 26 May 2002 18:18:09.0544 (UTC) FILETIME=[B084C880:01C204E1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA21721 Subject: [NSIS] Interim Meeting Report Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, I have assembled the meeting minutes, presentations, etc. here: http://www-nrc.nokia.com/sua/nsis/interim/ Things still need to be checked, edited, etc. Please send comments to the list. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun May 26 14:50:27 2002 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 OAA27544 for ; Sun, 26 May 2002 14:50:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22841 for nsis-archive@odin.ietf.org; Sun, 26 May 2002 14:50:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22630; Sun, 26 May 2002 14:37:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22597 for ; Sun, 26 May 2002 14:37:21 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27453 for ; Sun, 26 May 2002 14:36:57 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4QIZ3a15527 for ; Sun, 26 May 2002 21:38:48 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 26 May 2002 21:33:33 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 26 May 2002 21:33:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 26 May 2002 21:33:32 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65296@esebe004.NOE.Nokia.com> Thread-Topic: Framework Discussion Thread-Index: AcIE49aI5AQZP5yZS92LosD4pNCb8Q== To: X-OriginalArrivalTime: 26 May 2002 18:33:33.0212 (UTC) FILETIME=[D71155C0:01C204E3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA22598 Subject: [NSIS] Framework Discussion Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi All, At the interim meeting, it was felt that work should begin on the NSIS Framework document. In order to assist this, I prepared an outline of a possible draft. We discussed it and it was felt that it was a useful starting point. Since several others have submitted framework-ish documents, it was thought that a conference call would be good to help kick this work off. I will arrange one in 2 weeks, if this is acceptable. The call will be open to all. Attached is the outline, please comment on it and if this is a useful way forward. thanks, John NSIS Framework Outline Introduction Statement of Purpose To develop the 'realms/domains' and modes of operation where an NSIS protocol can be used. Identify the relationship of an NSIS protocol to other protocols. Identify areas for future work, especially if there are needs for additional protocol work. Allow for the NSIS protocol to be deployed in different parts of the Internet, for different needs, without requiring a complete end-to-end deployment. Support and take advantage of other protocols. Terminology Define entity names Scoping of the document Framework Structure Entities & interfaces involved Parts of the network(s) End-to-end Intradomain Interdomain Proxy Issues 'Global' operation 'Local' operation overall protocol operation inbound outbound Protocol Components Lower Layer Needs Upper Layer Services Abstract protocol components Identity Needs (flow id, reservation id, etc.) Protocol vs. Resource/Service needs Relation to and of Other Protocols/functions Resource allocation / Network Management AAA L3 Routing Issues Non-standard L3 Routing (load sharing, route pinning) Mobility, Context-Transfer Interworking with existing solutions How Applications use NSIS Avoid mention of specific protocols Security Implications of Threat Analysis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 27 05:22:50 2002 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 FAA15128 for ; Mon, 27 May 2002 05:22:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA02076 for nsis-archive@odin.ietf.org; Mon, 27 May 2002 05:23:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00929; Mon, 27 May 2002 05:09:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00898 for ; Mon, 27 May 2002 05:09:24 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14887 for ; Mon, 27 May 2002 05:09:01 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 27 May 2002 11:06:08 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 11:07:09 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Date: Mon, 27 May 2002 11:07:04 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA00899 Subject: [NSIS] Flow related signaling Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello John while I read the minutes of the interim meeting I thought about the "flow related signaling" issue. What exactly is required by NSIS signaling? - in a connectionless network, network service is always offered to a flow. - without prior knowledge of what identifies a flow, "service" is applied to all traffic passing a point which supports "service". - "flow" could probably be very fine grained (e.g. source/destination address, port and application) or rather corse (the entire traffic passing the service supporting device) or something in between. NSIS apply constraints here, but I'm not sure whether this is useful. It probably has to be the service specification which determines the level of signaled information required to identify a flow. NSIS however must be able to carry the information identifying the service specific flow. Would NSIS define a kind of abstract Flow ID toolbox? Some kind of flexible Flow ID TLV, data formats and protocol layers (e.g. IP information only) which may be used to identify a flow? Regards, Rüdiger PS: The URL to "Edited Charter (Word, with changebars)" is indicated as invalid by my browser. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon May 27 09:27:59 2002 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 JAA18468 for ; Mon, 27 May 2002 09:27:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15512 for nsis-archive@odin.ietf.org; Mon, 27 May 2002 09:28:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14904; Mon, 27 May 2002 09:14:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14865 for ; Mon, 27 May 2002 09:14:01 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18328 for ; Mon, 27 May 2002 09:13:37 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4RDDs6n014597; Mon, 27 May 2002 15:13:54 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LXW1J8KK; Mon, 27 May 2002 15:13:52 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 15:12:40 +0200 Message-ID: X-Sybari-Trust: f9bd651a bd9ca16c ba73248f 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com Cc: nsis@ietf.org Subject: RE: [NSIS] Some charter scoping / restrictions Date: Mon, 27 May 2002 15:13:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA14866 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rudiger and John The NSIS protocol can be used for QoS signaling on Layer 3 routers (please see e-mail archived at the URL: http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg01328.html) Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: vrijdag 24 mei 2002 8:35 To: Ruediger.Geib@t-systems.com Cc: nsis@ietf.org Subject: RE: [NSIS] Some charter scoping / restrictions Hi Rüdiger > If proxies and centralised service management are out of scope > the endpoint must signal for itself. Is it possible to trigger > an endpoint externally to start some NSIS signaling? I'm only > asking because that's how RSVP-TE signaling is used. Proxies are not out of scope & the ADs have expressed concerns that centralized service management is outside of the initial scope of the WG. There may be some use in documenting some of the needs of centralized resource management on signaling, perhaps in the framework and can be used to note future work needed. > "Endpoint" is some kind of service termination point. The data > flow on which "service" is applied could transit through that > signaling/service endpoint. The charter should explain this > optional difference between service termination and data > flow termination. I'm not sure that the charter is the right place, but I think the framwork document would be appropriate. 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 daemon@optimus.ietf.org Tue May 28 00:22:41 2002 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 AAA29734 for ; Tue, 28 May 2002 00:22:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA28583 for nsis-archive@odin.ietf.org; Tue, 28 May 2002 00:23:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26977; Mon, 27 May 2002 23:54:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26946 for ; Mon, 27 May 2002 23:54:37 -0400 (EDT) Received: from odin.ietf.org ([212.100.64.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29533 for ; Mon, 27 May 2002 23:54:10 -0400 (EDT) Message-Id: <200205280354.XAA29533@ietf.org> From: "BARRISTER P. OLUCHI" Date: Mon, 27 May 2002 05:02:50 To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Business relationship Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Dear Sir, I am highly compelled upon strict recommendation,To write you this very urgent and confidential letter.I am BARRISTER PAUL OLUCHI, the Lawyer to MRS.MARIAM ABACHA the wife of the late Nigerian Head of State Genera l Sani Abacha who died of heart attack on Monday, the 8th of June, 1998. Upon the sudden and tragic death of her husband, General Abacha, there has been an intensive but secret exercise by the present civilian government to close/freeze all his bank accounts both home and abroad as he was confirmed to have directed a certain percentage of oil proceeds totalling over US$500M (FIVE HUNDRED MILLION U. S. DOLLARS)into private bank accounts scattered in several countries of the world accumulated during his 5 years of military rule. An issue that was already on press before his sudden death. Since this exercise started few month ago, my client who is still in confinement has been in a very serious agony and mental stress as the entire family have virtually lost everything including landed properties and major investments both home and abroad. Luckily, there happens to be a special security account which my client deposited a sum of US$51,357, 000. 00 (FIFTY ONEMILLION, THREE HUNDRED AND SEVENTY FIVE THOUSAND U. SDOLLARS). This fund is in my company's name and is lodged in a Company Security Account Deposit(CSAD) with a West African Sub- Regional Bank. The fear there is that my client is one of the directors and invariably a major shareholder in the company, there exists a possible trace of this fund when once they finish with the accounts/assets principally owned by her husband, the Late Head of State himself. It is therefore on this note that my client have taskfully delegated me to quickly source a trustworthy and reliable person/company in your country who will kindly help us to accommodate and safeguard this fund into his account to save us from the calamities of the present clamp on her husband (the expresident) bank accounts/assets all over the world. Note that we have concluded arrangements for the release of the aforementioned sum to your bank account within the shortest possible time as soon as we conclude talks. As a result of this and other higher levels of financial transaction which I would want to enter with you as made possible by the death of my client's husband, I am suggesting ! that we schedule a meeting immediately. Please endeavour to contact me immediately through my private and confidential telephone number: 234-1-4818272. or better still Email me,whether or not this offer is acceptable to you, so as to enable me make other alternative contacts on the contrary. I await your urgent reply while believing you do understand the confidential nature of this transaction. Best regards, BARRISTER PAUL OLUCHI. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 28 06:55:04 2002 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 GAA12242 for ; Tue, 28 May 2002 06:55:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA00059 for nsis-archive@odin.ietf.org; Tue, 28 May 2002 06:55:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29182; Tue, 28 May 2002 06:34:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29149 for ; Tue, 28 May 2002 06:34:00 -0400 (EDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11945 for ; Tue, 28 May 2002 06:33:32 -0400 (EDT) Received: from Freedom.cwc.nus.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.12.1/8.12.1) with ESMTP id g4SAZ1BL021799; Tue, 28 May 2002 18:35:01 +0800 (SGT) Message-Id: <5.1.0.14.2.20020528181654.029a0a10@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 May 2002 18:34:05 +0800 To: john.loughney@nokia.com;, Ruediger.Geib@t-systems.com From: "SHEN, Qi (Charles)" Cc: nsis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA29150 Subject: [NSIS] Re: Flow Related Signaling Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, I think NSIS should allow a very flexible flow (or flow aggregate) identification. Besides the traditional IP five-tuple, the IPv6 Flow Label should possibly be incorporated. Moreover, should we consider using higher level identities like what RFC 2872 defines: the "Application and Sub Application Identity for use with RSVP"? Charles >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> · To: · john.loughney@nokia.com · Subject: [NSIS] Flow related signaling · From: "Geib, Ruediger" <· Ruediger.Geib@t-systems.com> · Date: Mon, 27 May 2002 11:07:04 +0200 · Cc: · nsis@ietf.org · List-Id: Next Steps in Signaling · Sender: · nsis-admin@ietf.org Hello John while I read the minutes of the interim meeting I thought about the "flow related signaling" issue. What exactly is required by NSIS signaling? - in a connectionless network, network service is always offered to a flow. - without prior knowledge of what identifies a flow, "service" is applied to all traffic passing a point which supports "service". - "flow" could probably be very fine grained (e.g. source/destination address, port and application) or rather corse (the entire traffic passing the service supporting device) or something in between. NSIS apply constraints here, but I'm not sure whether this is useful. It probably has to be the service specification which determines the level of signaled information required to identify a flow. NSIS however must be able to carry the information identifying the service specific flow. Would NSIS define a kind of abstract Flow ID toolbox? Some kind of flexible Flow ID TLV, data formats and protocol layers (e.g. IP information only) which may be used to identify a flow? Regards, Rüdiger PS: The URL to "Edited Charter (Word, with changebars)" is indicated as invalid by my browser. _______________________________________________ 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 daemon@optimus.ietf.org Tue May 28 08:03:27 2002 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 IAA14331 for ; Tue, 28 May 2002 08:03:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA04898 for nsis-archive@odin.ietf.org; Tue, 28 May 2002 08:03:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02987; Tue, 28 May 2002 07:41:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02956 for ; Tue, 28 May 2002 07:41:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13215; Tue, 28 May 2002 07:41:01 -0400 (EDT) Message-Id: <200205281141.HAA13215@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, 28 May 2002 07:41:01 -0400 Subject: [NSIS] I-D ACTION:draft-tschofenig-nsis-threats-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NSIS Threats Author(s) : H. Tschofenig Filename : draft-tschofenig-nsis-threats-00.txt Pages : 9 Date : 24-May-02 As the work in the NSIS working has begun to describe requirements and the framework people started thinking about possible security implication. This document should provide a starting point for the discussion at the NSIS interim meeting and at the NSIS working group mailing list regarding the security issues that have to be addressed. It does not describe threats for a particular published protocol. This memo is furthermore meant to create awareness for the security within the group. The threat scenarios in this document are matched against the security requirements described in [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-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-tschofenig-nsis-threats-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-tschofenig-nsis-threats-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: <20020524143600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tschofenig-nsis-threats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-tschofenig-nsis-threats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020524143600.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 28 16:21:16 2002 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 QAA29979 for ; Tue, 28 May 2002 16:21:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13297 for nsis-archive@odin.ietf.org; Tue, 28 May 2002 16:21:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12543; Tue, 28 May 2002 16:03:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12513 for ; Tue, 28 May 2002 16:03:46 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29455 for ; Tue, 28 May 2002 16:03:20 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g4SK6hN03505; Tue, 28 May 2002 15:06:43 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g4SK2cs16679; Tue, 28 May 2002 15:02:38 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 15:03:27 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BAF4@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'nsis@ietf.org'" Cc: "'sven.van_den_bosch@alcatel.be'" Date: Tue, 28 May 2002 15:03:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] Scenario Requiring Effectively Persistent State Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi All, In the current requirements draft there is discussion of the need for automatic release of resources after failure (5.3.2). In the following I discuss a scenario where "effectively persistent" state is required. In other words it is desirable that resources are not released after failure. First consider the case where an end-system (corresponding to an individual customer) signals NSIS. Let us assume that it has signaled for a number of QOS flows with itself as either the source or sink of data. Clearly in most circumstances, if the end-system goes down, there is no reason to maintain these existing flows since in any case they cannot be utilized during the period that the end-system is down. As long as flows can easily be re-established when the end-system comes back up this should satisfy most requirements. Nevertheless in the case of a "lifeline connection" for voice over IP, this may not be enough. In contrast to the above scenario, consider an NSIS proxy controller under the control of a network operator that signals on behalf of end-systems. Clearly no existing devices support NSIS and if NSIS becomes successful there will still be a large number of end-systems and mobile devices that do not support this protocol. For instance many users may not want to upgrade their desktop to the newest version of their operating system due to prohibitive costs. There may also be devices with limited memory or processing power that cannot signal using NSIS (perhaps less likely). For all these reasons we may see NSIS proxy controllers that proxy signal NSIS on behalf of large numbers of end-systems. One particularly important case will be IP telephony. In such cases the NSIS proxy controller, which is the initiator of the flow reservations, is independent of the data path and may be responsible for thousands of simultaneous flows. Such reservations may include lifeline services. In the case of NSIS proxy controller failure, it is essential that the existing flow reservations do not get torn down. The flow reservations generated by this privileged network controlled device must be effectively persistent in the face of its failure. The requirement is that NSIS support graceful implementations that enable effectively persistent state in the face of proxy controller failure. This may or may not mean that the flow reservations are truly persistent. Best Regards, Marco _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue May 28 16:34:55 2002 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 QAA00324 for ; Tue, 28 May 2002 16:34:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14449 for nsis-archive@odin.ietf.org; Tue, 28 May 2002 16:35:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13100; Tue, 28 May 2002 16:17:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13071 for ; Tue, 28 May 2002 16:17:57 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29751 for ; Tue, 28 May 2002 16:17:32 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g4SKL0N03615; Tue, 28 May 2002 15:21:00 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g4SKGtl17387; Tue, 28 May 2002 15:16:55 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 15:17:44 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BAF5@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'nsis@ietf.org'" Cc: "'sven.van_den_bosch@alcatel.be'" Date: Tue, 28 May 2002 15:17:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi All, One of the Open issues mentioned in the current requirements draft is Route Pinning (item 47). In the following I discuss a very strong motivation for the ability to do route pinning if a soft state solution is used for NSIS. I have tried to express this as a requirement upon NSIS rather than the mechanism (route pinning being the obvious one) by which this requirement may be achieved. Requirement: NSIS must directly support the ability to insulate a flow reservation from changes in the default routing behaviour except in those cases where said changes result from loss of resources (layer 3 hops, capacity etc.) along the existing flow reservation path. For instance, utilizing traffic engineering in a layer 2 network (e.g. MPLS or ATM) we may provision additional links or change the resources associated with existing links. Additionally failures in the network may cause changes. Such changes must not affect existing layer 3 reservation paths with the exception of those cases where the existing reservation path no longer exists or no longer has capacity to support the flow reservation. As a simple example consider a network with two routers A and B and assume that the shortest path from A to B is two hops. Based upon NSIS signaling, as directed by default routing based upon number of hops, a reservation path is setup from A to B along a path of two hops, where both hops have a capacity of 10 and the reservation uses a capacity of 6. Now let us assume that a direct link with capacity 5 is provisioned between A and B resulting in a new and direct default route of 1 hop. If NSIS uses a soft state solution without route pinning then the existing flow reservation will be redirected along the new link, which cannot support it. Thus the existing flow reservation is lost due a change in the network unrelated to its current path. In fact thousands of reservations may have been routed along the original path and would now be disrupted. Such protocol behaviour is not acceptable. Best Regards, Marco _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 29 01:44:59 2002 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 BAA10646 for ; Wed, 29 May 2002 01:44:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26083 for nsis-archive@odin.ietf.org; Wed, 29 May 2002 01:45:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24785; Wed, 29 May 2002 01:28:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24760 for ; Wed, 29 May 2002 01:28:25 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10282 for ; Wed, 29 May 2002 01:27:58 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4T5Siq06590 for ; Wed, 29 May 2002 08:28:45 +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, 29 May 2002 08:28:21 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 29 May 2002 08:28:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 29 May 2002 08:28:20 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD8B@esebe004.NOE.Nokia.com> Thread-Topic: Flow Related Signaling Thread-Index: AcIGMysebZOegyzKQOSJXSqWUB5dwQAnTInQ To: , , X-OriginalArrivalTime: 29 May 2002 05:28:21.0052 (UTC) FILETIME=[A54577C0:01C206D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA24761 Subject: [NSIS] RE: Flow Related Signaling Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, In the interim meeting, there was some discussion of a 'flow' I think we should at least define (for NSIS) what a flow is and some abstract representation of it. There may be some places where the flow may not be needed, however. This would be good to discuss some more on the list. thanks, John > -----Original Message----- > From: ext SHEN, Qi (Charles) [mailto:shenqi@cwc.nus.edu.sg] > Sent: 28 May, 2002 13:34 > To: Loughney John (NRC/Helsinki); Ruediger.Geib@t-systems.com > Cc: nsis@ietf.org > Subject: Re: Flow Related Signaling > > > Hi, > > I think NSIS should allow a very flexible flow (or flow aggregate) > identification. Besides the traditional IP five-tuple, the > IPv6 Flow Label > should possibly be incorporated. Moreover, should we consider > using higher > level identities like what RFC 2872 defines: the "Application and Sub > Application Identity for use with RSVP"? > > Charles > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > · To: · john.loughney@nokia.com > · Subject: [NSIS] Flow related signaling > · From: "Geib, Ruediger" <· Ruediger.Geib@t-systems.com> > · Date: Mon, 27 May 2002 11:07:04 +0200 > · Cc: · nsis@ietf.org > · List-Id: Next Steps in Signaling > · Sender: · nsis-admin@ietf.org > > Hello John > > while I read the minutes of the interim meeting I thought > about the "flow related signaling" issue. What exactly is > required by NSIS signaling? > > - in a connectionless network, network service is always > offered to a flow. > - without prior knowledge of what identifies a flow, > "service" is applied to all traffic passing a point > which supports "service". > - "flow" could probably be very fine grained (e.g. > source/destination address, port and application) > or rather corse (the entire traffic passing the > service supporting device) or something in between. > NSIS apply constraints here, but I'm not sure whether > this is useful. > > It probably has to be the service specification which > determines the level of signaled information required > to identify a flow. NSIS however must be able to carry > the information identifying the service specific flow. > Would NSIS define a kind of abstract Flow ID toolbox? > Some kind of flexible Flow ID TLV, data formats > and protocol layers (e.g. IP information only) which may > be used to identify a flow? > > Regards, Rüdiger > > > PS: The URL to "Edited Charter (Word, with changebars)" > is indicated as invalid by my browser. > > _______________________________________________ > 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 daemon@ns.ietf.org Wed May 29 03:07:30 2002 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 DAA04966 for ; Wed, 29 May 2002 03:07:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA15494 for nsis-archive@odin.ietf.org; Wed, 29 May 2002 03:07:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13008; Wed, 29 May 2002 02:49:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12977 for ; Wed, 29 May 2002 02:49:52 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04511 for ; Wed, 29 May 2002 02:49:27 -0400 (EDT) Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 29 May 2002 08:48:18 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 08:49:18 +0200 Message-Id: From: "Geib, Ruediger" To: schneider@tri.sbc.com Cc: nsis@ietf.org Subject: RE: [NSIS] Scenario Requiring Effectively Persistent State Date: Wed, 29 May 2002 08:49:16 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA12978 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marco, quite a reasonable argument. I've been going through this discussion in another group and we concluded: - As long as an adjacent signaling unit still up discovers no lack of state (e.g. no response on a new reservation related message), keeping the service up is allright. - The proxy coming into service again must be able to re-install its own state. A secure solution is to just allow a check of the remainders of the proxy service reservation database in communication with adjacent signaling systems. The latter issue of the proxy being able to re-install state is quite important. If you can't do that, "release" is the best option. Regards, Rüdiger > For all these reasons we may see NSIS proxy controllers > that proxy signal NSIS on behalf of large numbers of > end-systems. One particularly important case will be > IP telephony. In such cases the NSIS proxy controller, > which is the initiator of the flow reservations, is > independent of the data path and may be responsible > for thousands of simultaneous flows. Such reservations > may include lifeline services. In the case of NSIS proxy > controller failure, it is essential that the existing > flow reservations do not get torn down. The flow > reservations generated by this privileged network > controlled device must be effectively persistent in the > face of its failure. The requirement is that NSIS > support graceful implementations that enable effectively > persistent state in the face of proxy controller failure. > This may or may not mean that the flow reservations are > truly persistent. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed May 29 06:43:15 2002 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 GAA10031 for ; Wed, 29 May 2002 06:43:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA00102 for nsis-archive@odin.ietf.org; Wed, 29 May 2002 06:43:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28887; Wed, 29 May 2002 06:25:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28858 for ; Wed, 29 May 2002 06:25:00 -0400 (EDT) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09819 for ; Wed, 29 May 2002 06:24:35 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 17D0c1-0006BJ-00 for ; Wed, 29 May 2002 12:23:25 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 17D0c0-0007iI-00 for ; Wed, 29 May 2002 12:23:24 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g4TANOg06111 for ; Wed, 29 May 2002 12:23:24 +0200 Message-Id: <200205291023.g4TANOg06111@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: nsis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 May 2002 12:23:24 +0200 From: Roland Bless Subject: [NSIS] NSIS Requirements: grouping microflows Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, I've got a comment to Open issue 14) add "support grouping of microflows" If I remember correctly, Georgios supported this requirement due to its usefulness for refreshing states. IMO this is better solved by a refresh reduction method such as the proposed one for RSVP. Therefore: shouldn't we remove this requirement? Though grouping microflows in a request is really complex due to handling of failed requests for single flows, it might be useful to have a list of reservation-IDs for error messages such as a release due to failure. But this seems to be an implementation specific optimization rather than a functional requirement. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed May 29 08:01:01 2002 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 IAA12504 for ; Wed, 29 May 2002 08:01:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05051 for nsis-archive@odin.ietf.org; Wed, 29 May 2002 08:01:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03576; Wed, 29 May 2002 07:44:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03542 for ; Wed, 29 May 2002 07:44:24 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11621 for ; Wed, 29 May 2002 07:43:58 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TBiImG026147; Wed, 29 May 2002 13:44:18 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LY0FGBJZ; Wed, 29 May 2002 13:44:18 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 13:44:17 +0200 Message-ID: X-Sybari-Trust: c995f486 bd9ca16c 726356b0 00000138 From: "Georgios Karagiannis (ELN)" To: "'Roland Bless'" , nsis@ietf.org Subject: RE: [NSIS] NSIS Requirements: grouping microflows Date: Wed, 29 May 2002 13:44:16 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Roland But this requirement can be seen as a more general definition of the refresh reduction method used in RSVP! Thus, I do not know why you should remove it? Best regards, Georgios -----Original Message----- From: Roland Bless [mailto:bless@tm.uka.de] Sent: woensdag 29 mei 2002 12:23 To: nsis@ietf.org Subject: [NSIS] NSIS Requirements: grouping microflows Hi, I've got a comment to Open issue 14) add "support grouping of microflows" If I remember correctly, Georgios supported this requirement due to its usefulness for refreshing states. IMO this is better solved by a refresh reduction method such as the proposed one for RSVP. Therefore: shouldn't we remove this requirement? Though grouping microflows in a request is really complex due to handling of failed requests for single flows, it might be useful to have a list of reservation-IDs for error messages such as a release due to failure. But this seems to be an implementation specific optimization rather than a functional requirement. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ 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 daemon@optimus.ietf.org Wed May 29 09:03:38 2002 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 JAA15148 for ; Wed, 29 May 2002 09:03:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11548 for nsis-archive@odin.ietf.org; Wed, 29 May 2002 09:03:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09245; Wed, 29 May 2002 08:43:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09157 for ; Wed, 29 May 2002 08:43:27 -0400 (EDT) Received: from ab97c1790.com ([216.139.170.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14045 for ; Wed, 29 May 2002 08:42:32 -0400 (EDT) Message-Id: <200205291242.IAA14045@ietf.org> From: "Mr. Pakwesi Oduro" Reply-To: pakwesioduro@lycos.com To: nsis@ietf.org Date: Wed, 29 May 2002 13:46:46 +0200 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===_SecAtt_000_1fvipomenjtsib" Subject: [NSIS] (no subject) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --===_SecAtt_000_1fvipomenjtsib Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --===_SecAtt_000_1fvipomenjtsib Content-Type: application/octet-stream; name="pakwesi.doc" Content-Disposition: attachment; filename="pakwesi.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMAAAAAAAAAAA EAAAMgAAAAEAAAD+////AAAAAC8AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA+BK/AAAAAAAAEAAAAAAABAAASRIAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIhwAADd8AAA3fAAASQ4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAAoBAAAAAAAACgEAAAoB AAAAAAAACgEAAAAAAAAKAQAAAAAAAAoBAAAAAAAACgEAABQAAAAAAAAAAAAAAB4BAAAAAAAAtgMA AAAAAAC2AwAAAAAAALYDAAAAAAAAtgMAAAwAAADCAwAAFAAAAB4BAAAAAAAA+wcAALYAAADiAwAA KAAAAAoEAAAAAAAACgQAAAAAAAAKBAAAAAAAAAoEAAAAAAAACgQAAAAAAAAKBAAAAAAAAAoEAAAA AAAAegcAAAIAAAB8BwAAAAAAAHwHAAAAAAAAfAcAAAAAAAB8BwAAAAAAAHwHAAAAAAAAfAcAACQA AACxCAAAIAIAANEKAABSAAAAoAcAABUAAAAAAAAAAAAAAAAAAAAAAAAACgEAAAAAAAAKBAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAKBAAAAAAAAAoEAAAAAAAACgQAAAAAAAAKBAAAAAAAAKAHAAAAAAAA aAYAAAAAAAAKAQAAAAAAAAoBAAAAAAAACgQAAAAAAAAAAAAAAAAAAAoEAAAAAAAAtQcAABYAAABo BgAAAAAAAGgGAAAAAAAAaAYAAAAAAAAKBAAANgEAAAoBAAAAAAAACgQAAAAAAAAKAQAAAAAAAAoE AAAAAAAAegcAAAAAAAAAAAAAAAAAAGgGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAACgQAAAAAAAB6BwAAAAAAAGgGAAASAQAAaAYAAAAAAAAAAAAA AAAAAHoHAAAAAAAACgEAAAAAAAAKAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAegcAAAAAAAAKBAAAAAAAANYDAAAMAAAAwB0hTwAH wgEeAQAAmAIAALYDAAAAAAAAQAUAAI4AAAB6BwAAAAAAAAAAAAAAAAAAegcAAAAAAADLBwAAMAAA APsHAAAAAAAAegcAAAAAAAAjCwAAAAAAAM4FAACaAAAAIwsAAAAAAAB6BwAAAAAAAGgGAAAAAAAA HgEAAAAAAAAeAQAAAAAAAAoBAAAAAAAACgEAAAAAAAAKAQAAAAAAAAoBAAAAAAAAAgDZAAAARlJP TTogTVIuIFBBS1dFU0kgT0RVUk8NUC4gTy4gQk9YLCAxMjMgQUNISU1PVEEsDUFDQ1JBIC0gR0hB TkENRS1NQUlMOiATIEhZUEVSTElOSyAibWFpbHRvOnBha3dlc2lvZHVyb0BteXNlbGYuY29tIiAB FHBha3dlc2lvZHVyb0BteXNlbGYuY29tFQ1EYXRlOiAyOHRoIE1heSAyMDAyDQ1EZWFyLA0NTXkg bmFtZSBpcyBNci5QYWt3ZXNpIE9kdXJvLCAzNiBZZWFycyBPbGQgR2hhbmlhbiBOYXRpb25hbCBt YXJyaWVkIHdpdGggdHdvIGNoaWxkcmVuLiAgSSB3b3JrIGFzIGEgUmVjb3JkcyBNYW5hZ2VyIHdp dGggU3RhbmRhcmQgU2VjdXJpdHkgYW5kIFNlcnZpY2VzIEdoYW5hIExpbWl0ZWQgaW4gQWNjcmEt R2hhbmEuICBJIGVhcm4gc2FsYXJ5IG9mIDEuNSBtaWxsaW9uIEdoYW5hIENlZGlzICgkMjAwIFVu aXRlZCBTdGF0ZSBEb2xsYXJzKSBlcXVpdmFsZW50IG1vbnRobHkuIEkgam9pbmVkIHRoZSBzZXJ2 aWNlcyBvZiB0aGlzIGNvbXBhbnkgaW4gMTk5MSBhcyBvZmZpY2UgYXNzaXN0YW5jZS4gIEkgZ290 IHRoZSBpbmZvcm1hdGlvbiBjb25jZXJuaW5nIHlvdSBmcm9tIHRoZSBJbnRlcm5ldCBhbmQgYWZ0 ZXIgZHVlIGNvbnN1bHRhdGlvbiBJIGRlY2lkZWQgdG8gY29udGFjdCB5b3UgYmVsaWV2aW5nIHRo YXQgYnkgdGhlIGdyYWNlIG9mIEdPRCB0aGF0IHlvdSB3aWxsIGFjY2VwdCB0byBiZSBteSBwYXJ0 bmVyIGluIHRoaXMgZGVhbC4NDUkgaGF2ZSBiZWVuIHdvcmtpbmcgd2l0aCB0aGlzIGNvbXBhbnkg Zm9yIG92ZXIgdGVuIHllYXJzLiAgV2l0aGluIHRoaXMgcGVyaW9kLCBJIGhhdmUgd2F0Y2hlZCB3 aXRoIG1ldGljdWxvdXMgcHJlY2lzaW9uIGhvdyBBZnJpY2FuIEhlYWRzIG9mIFN0YXRlIGFuZCBn b3Zlcm5tZW50IGZ1bmN0aW9uYXJpZXMgaGF2ZSBiZWVuIHVzaW5nIHByby1zZWN1cml0eSBhbmQg ZmluYW5jZSBzZXJ2aWNlcyBHaC4gTHRkIHRvIG1vdmUgaHVnZSBzdW1zIG9mIG1vbmV5IFVTRCwg cG91bmQgc3RlcmxpbmcsIEZyZW5jaCBGcmFuY2UtKENhc2gpIHRvIHRoZWlyIGZvcmVpZ24gcGFy dG5lcnMuICBUaGV5IGJyaW5nIGluIHRoZXNlIGNvbnNpZ25tZW50cyBvZiBtb25leSBjYXNoIGFu ZCBzZWNyZXRseSAgZGVjbGFyZSB0aGUgY29udGVudHMgYXMgamV3ZWxyaWVzLCBnb2xkLCBkaWFt b25kLCBwcmVjaW91cyBzdG9uZSwgZmFtaWx5IHRyZWFzdXJlLCBkb2N1bWVudHMgZXRjLiBHZW4u IFNhbmkgQWJhY2hhIG9mIE5pZ2VyaWEoZGVhZCksIE1vYnV0dSBzZXNlIHNla28gb2YgWmFpcmUg KGRlYWQpLCBGb2RheSBTYW5rb3kgb2YgU2llcmEtTGVvbmUsIEJhYmFuZ2lkYSBvZiBOaWdlcmlh LCBGZWxleCBIb3VwaGV0IEJ1aWdueSBvZiBJdm9yeSBDb2FzdCAoZGVhZCksIEthbmFuIEJlZGll IG9mIEl2b3J5IENvYXN0IGV0YywgQWxsIHRoZXNlIHBlb3BsZSBoYXZlIGh1bmRyZWRzIG9mIGNv bnNpZ25tZW50IGRlcG9zaXRlZCB3aXRoIG15IG9mZmljZS4NDVRoZWlyIGZvcmVpZ24gcGFydG5l cnMsIGZyaWVuZDsgYW5kIHJlbGF0aXZlcywgYXJlIGNsYWltaW5nIG1vc3Qgb2YgdGhlc2UgY29u c2lnbm1lbnRzLiAgQSBsb3Qgb2YgdGhlbSBhcmUgbHlpbmcgaGVyZSB1bmNsYWltZWQgZm9yIGFz IG11Y2ggYXMgMTUgeXJzLiAgTm9ib2R5IHdpbGwgZXZlciBjb21lIGZvciB0aGVtIGJlY2F1c2Ug aW4gbW9zdCBjYXNlcywgdGhlIGRvY3VtZW50cyBvZiBkZXBvc2l0IGFyZSBuZXZlciBhdmFpbGFi bGUgdG8gYW55IGJvZHkgZXhjZXB0IHRoZSBkZXBvc2l0b3JzLW1vc3Qgb2YgdGhlbSBhcmUgZGVh ZC4NDVNpbmNlIHRoZSBpbmNlcHRpb24gb2YgdGhlIDIwMDAgbWlsbGVubml1bSwgb3VyIGNvbXBh bnkgTWFuYWdlbWVudCBjaGFuZ2VkIHRoZSBwcm9jdXJlIG9mIGNsYWltcyBvZiBDb25zaWdubWVu dHMsIGFzIHNvb24gYXMgeW91IGFyZSBhYmxlIHRvIHByb2R1Y2UgdGhlIHNlY3JldCBpbmZvcm1h dGlvbiBhcyBjb250YWluZWQgaW4gdGhlIHNlY3JldCAgb2YgYW55IGNvbnNpZ25tZW50LCBpdCB3 aWxsIGJlIHJlbGVhc2VkIHRvIHlvdSB1cG9uIGRlbWFuZC4gIEZyb20gb3VyIHJlY29yZCwgbW9y ZSB0aGFuIDE2MCBjb25zaWdubWVudCBiZWxvbmdpbmcgdG8gR2VuLiBBYmFjaGEgL01vYnV0dSBT ZXNlIFNla28sIGhhcyBiZWVuIGNsYWltZWQgaW4gdGhlIHBhc3Qgc2l4IG1vbnRocywgdGhpcyBp cyB3aHkgSSBhbSBzb2xpY2l0aW5nIGZvciB5b3VyIGNvLW9wZXJhdGlvbiBhbmQgYXNzaXN0YW5j ZSwgR2VuLiBBYmFjaGEgaGFzIDEwNiBjb25zaWdubWVudCwgZGVwb3NpdGVkIHdpdGggc2V2ZXJh bCBuYW1lcyBhbmQgY29kZXMuICA2NCBoYXZlIGJlZW4gY2xhaW1lZCBpbiB0aGUgcGFzdCBzaXgg bW9udGhzLg0NU2luY2UgaGUncyBkZWFkLCBoaXMgZmlyc3Qgc29uIGlzIGRlYWQgaW4gcGxhbmUg Y3Jhc2ggdGhlIHNlY29uZCBzb24gaXMgZmFjaW5nIHRyaWFsIGZvciBtdXJkZXIgYW5kIGVtYmV6 emxlbWVudCwgdGhlIGZhbWlseSBtZW1iZXJzIGFyZSB1bmRlciByZXN0cmljdGVkIGFycmVzdCB3 aXRob3V0IGNvbW11bmljYXRpb24uICBJIGhhdmUgZmluaXNoZWQgZXZlcnkgYXJyYW5nZW1lbnQg Zm9yIHlvdSB0byBjb21lIGFuZCBjbGFpbSBjb25zaWdubWVudCBOby4xNDAxLDE0MDIsMTQwMywg Y29udGFpbmluZyAyME0gVVNELiBNeSBkdXR5IGlzIHRvIHN1cHBseSB5b3Ugd2l0aCBhbGwgdGhl IGluZm9ybWF0aW9uIGFuZCBkb2N1bWVudHMsIGJ5DSBmYXggeW91IHdpbGwgZGVhbCB3aXRoIHRo ZSBtYW5hZ2VtZW50IGRpcmVjdGx5Lg0NVGhlIHByb2NlZHVyZSBpcyBzaW1wbGU6LSBBcHBseSBv ZmZpY2lhbGx5IHRvIHRoZSBkaXJlY3RvciBvZiBvcGVyYXRpb25zIG9mIFBSTy1TRUNVUklUWSBB TkQgRklOQU5DRSAoR0gpIExURCBmb3IgdGhlIHJlbGVhc2Ugb2YgY29uc2lnbm1lbnQgTm8uIDE0 MDEgYW5kIE5vLiAxNDAyLiAgVGhleSB3aWxsIGRlbWFuZCBzb21lIGRvY3VtZW50cyBhbmQgc2Vj cmV0IGNvZGUgY29udGFjdCBtZSBpbW1lZGlhdGVseSwgSSdsbCBzdXBwbHkgeW91IGV2ZXJ5IGRl dGFpbGVkIGluZm9ybWF0aW9uLiAgQW5kIGZheCBpdCB0byAgdGhlbS4gICBBcyBzb29uIGFzIHRo ZXkgY29uZmlybSBpdCB0byBiZSBjb3JyZWN0LiBUaGV5IHdpbGwgaW52aXRlIHlvdSBpbiBmb3Ig dGhlIGNvbGxlY3Rpb24uDQ1JICcgbGwgc3VnZ2VzdCB1cG9uIGNvbmNsdXNpb24sIHdlIHNoYXJl IDUwJSBmb3IgeW91LCBvZiB0aGlzIHRyYW5zYWN0aW9uIHdoaWxlIDUwJSBhZnRlciBkZWR1Y3Rp bmcgYW55IGV4cGVuc2VzIHdlIG1pZ2h0IGluY3VyIGluIHRoZSBjb3Vyc2UuIEkgYXNzdXJlIHlv dSB0aGF0IHRoZSBidXNpbmVzcyBoYXZlIGJlZW4gaGF0Y2hlZCBmb3IgNSB5ZWFycyBub3csIGl0 IGlzIHZlcnkgc2VjdXJlIGFuZCByaXNrIGZyZWUuICBZb3UgY2FuIHJlYWNoIG1lIG9uIG15IGVt YWlsIGFkZHJlc3MuDQ1JIGFtIGF0IGxlYXN0IHRvIGZ1cm5pc2ggeW91IHdpdGggZXhwbGFuYXRp b25zIGFuZCBkaXJlY3RpdmVzIG9uIHRoZSBwcm9jZWR1cmUuICBHb2QgYmxlc3MgeW91Lg0NVGhh bmtzLg0NQmVzdCByZWdhcmRzLA1Nci4gUGFrd2VzaSBPZHVyby4NRS1tYWlsOiATIEhZUEVSTElO SyAibWFpbHRvOnBha3dlc2lvZHVyb0BteXNlbGYuY29tIiABFHBha3dlc2lvZHVyb0BteXNlbGYu Y29tFSANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAGBAAAGAQA ADAEAABHBAAASAQAAHQEAAB1BAAAdgQAAI0EAACOBAAAlwQAAJkEAADlEQAA+BEAAAASAAABEgAA LRIAAC4SAAAvEgAARhIAAEcSAABIEgAASRIAAPfr4ffU98TUudT3r/fr95/rjJ9+n+v3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABowShAANQiBQ0oUAE9KAgBRSgIAXAiBXkoCAAAlAgiBA2rjAAAABggBNQiB Q0oUAE9KAgBRSgIAVQgBXAiBXkoCAB8DagAAAAA1CIFDShQAT0oCAFFKAgBVCAFcCIFeSgIAE0NK FABIKgFPSgIAUUoCAF5KAgAUMEoQAENKFABPSgIAUUoCAF5KAgAAHwIIgQNqAAAAAAYIAUNKFABP SgIAUUoCAFUIAV5KAgAZA2oAAAAAQ0oUAE9KAgBRSgIAVQgBXkoCABNDShQAT0oCAFFKAgBcCIFe SgIAFjUIgUNKFABPSgIAUUoCAFwIgV5KAgAAEENKFABPSgIAUUoCAF5KAgAXAAQAABgEAAAxBAAA PwQAAI8EAACjBAAApAQAAKoEAACrBAAAwQYAAMIGAAC4CQAAuQkAAO0KAADuCgAALA0AAC0NAACZ DgAAyg4AAMsOAABSEAAAUxAAAGwRAABtEQAAzREAAM4RAADWEQAA1xEAAOURAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAABAAAAyQDYSQDABwABAAASRIAAP0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAeURAAD4EQAASRIAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAMkA2EkAwACIAAxkGgBH7DQLyCw4D0h sAgHIrAIByOQHAIkkDgEJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADjAAAARAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5 +brOEYyCAKoAS6kLAgAAABcAAAAYAAAAcABhAGsAdwBlAHMAaQBvAGQAdQByAG8AQABtAHkAcwBl AGwAZgAuAGMAbwBtAAAA4Mnqefm6zhGMggCqAEupCz4AAABtAGEAaQBsAHQAbwA6AHAAYQBrAHcA ZQBzAGkAbwBkAHUAcgBvAEAAbQB5AHMAZQBsAGYALgBjAG8AbQAAAOMAAABEAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5 us4RjIIAqgBLqQsCAAAAFwAAABgAAABwAGEAawB3AGUAcwBpAG8AZAB1AHIAbwBAAG0AeQBzAGUA bABmAC4AYwBvAG0AAADgyep5+brOEYyCAKoAS6kLPgAAAG0AYQBpAGwAdABvADoAcABhAGsAdwBl AHMAaQBvAGQAdQByAG8AQABtAHkAcwBlAGwAZgAuAGMAbwBtAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAARAAoAAQBpAA8AAwAAAAAAAAAAADgA AEDx/wIAOAAMAAYATgBvAHIAbQBhAGwAAAACAAAAGABDShgAX0gBBGFKGABtSAkEc0gJBHRICQQA AAAAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwADAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcA cgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAMABCQAEA8gAwAAwACQBCAG8AZAB5ACAAVABl AHgAdAAAAAgADwADJANhJAMEAENKFgAuAFVAogABAS4ADAAJAEgAeQBwAGUAcgBsAGkAbgBrAAAA DAA+KgFCKgJwaAAA/wAAAAAASQ4AAAQAABwAAAAA/////wAAAAAYAAAAMQAAAD8AAACPAAAAowAA AKQAAACqAAAAqwAAAMECAADCAgAAuAUAALkFAADtBgAA7gYAACwJAAAtCQAAmQoAAMoKAADLCgAA UgwAAFMMAABsDQAAbQ0AAM0NAADODQAA1g0AANcNAADlDQAA+A0AAEsOAACYAAAAADAAAAAAAAAA gAAAAICaAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAIAABAAASRIAAAoAAAAABAAA5REAAEkSAAALAAAADQAAAAAEAABJEgAADAAA AEcAAAB1AAAAjQAAAAAOAAAuDgAARg4AAEkOAAATWBT/FYATWBT/FYAAAAAAtgAAAMAAAADBAAAA xgAAANUAAADcAAAAhAEAAIkBAACkAwAApgMAALEEAAC1BAAAtgQAALwEAADWBAAA2gQAANsEAADf BAAA8QQAAPYEAAD3BAAA/QQAAAEFAAAGBQAADgUAABcFAAAkBQAAKQUAACoFAAAxBQAAMgUAADgF AABQBQAAVQUAAFYFAABbBQAAMAgAADYIAAA/CAAAQwgAAEQIAABICAAAuggAAMAIAABXDAAAWQwA AOkNAADwDQAA8Q0AAPYNAABLDgAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAAAAAAOkDAADrAwAAQAQAAFEEAADABAAAyAQAANcFAADYBQAArgcAALgHAAA1CgAA PwoAAJoKAACdCgAA4goAAOQKAADICwAA4gsAAPALAAD4CwAA/AsAACUMAABLDgAABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAAAAAAXAAAAMAAAADwAAAA8AAAA RwAAAKIAAAAWAQAAKwEAAEgBAABSAQAAlwEAAKQBAAAUAgAAFQIAAKQDAAClAwAAYgQAAGsEAADp BwAA6QcAAM4NAADODQAAAA4AAEgOAABLDgAAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA BAADAAQAAwAEAAMABAADAAQABwD//wQAAAAGAFUAUwBFAFIAMQA4ADsAQwA6AFwARABvAGMAdQBt AGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAEEAZABtAGkAbgBpAHMAdAByAGEA dABvAHIAXABEAGUAcwBrAHQAbwBwAFwAcABhAGsAdwBlAHMAaQAuAGQAbwBjAAYAVQBTAEUAUgA0 ADAAOwBDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwA QQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgBcAEQAZQBzAGsAdABvAHAAXABwAGEAawB3AGUAcwBp AC4AZABvAGMA/0ADgAEA9w0AAPcNAADokXMAewB7APcNAAAAAAAA9w0AAAAAAAACEAAAAAAAAABJ DgAAQAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA //8AAAIA//8AAAAA//8AAAIA//8AAAAAAwAAAEcWkAEAAAICBgMFBAUCAwSHegAgAAAAgAgAAAAA AAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYC BQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSH egAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAAiAAQAcQiIGADw0AIAAGgBAAAAALXc ZSZC62VmAAAAAAQABgAAABACAADHCwAAAQAGAAAABAADEBkAAAAAAAAAAAAAAAEAAQAAAAEAAAAA AAAAIQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAccArQAtACBgTIwAAAAAAAAAAAA AAAAAAB2DgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAMoMRAPAQAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA//8SAAAAAAAAAAgARgBSAE8ATQA6ACAATQBSAAAAAAAAAAYAVQBTAEUAUgAxADgA BgBVAFMARQBSADEAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y +U9oEKuRCAArJ7PZMAAAAGwBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAACsAAAABAAAALgAAAAF AAAAyAAAAAYAAADUAAAABwAAAOAAAAAIAAAA8AAAAAkAAAAAAQAAEgAAAAwBAAAKAAAAKAEAAAwA AAA0AQAADQAAAEABAAAOAAAATAEAAA8AAABUAQAAEAAAAFwBAAATAAAAZAEAAAIAAADkBAAAHgAA AAkAAABGUk9NOiBNUgAAIAAeAAAAAQAAAABST00eAAAABwAAAFVTRVIxOABSHgAAAAEAAAAAU0VS HgAAAAEAAAAAU0VSHgAAAAcAAABOb3JtYWwAUh4AAAAHAAAAVVNFUjE4AFIeAAAAAgAAADQARVIe AAAAEwAAAE1pY3Jvc29mdCBXb3JkIDkuMAAAQAAAAACkk9YAAAAAQAAAAAD+Z/WeBcIBQAAAAACE fkEAB8IBAwAAAAEAAAADAAAAEAIAAAMAAADHCwAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgA Kyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuOAEAAPQAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACA AAAABgAAAIgAAAARAAAAkAAAABcAAACYAAAACwAAAKAAAAAQAAAAqAAAABMAAACwAAAAFgAAALgA AAANAAAAwAAAAAwAAADVAAAAAgAAAOQEAAAeAAAABwAAAFdFQkNPTQAAAwAAABkAAAADAAAABgAA AAMAAAB2DgAAAwAAAKAKCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAA CQAAAEZST006IE1SAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAA0AQAAAwAAAAAAAAAg AAAAAQAAADgAAAACAAAAQAAAAAEAAAACAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAAQQAAAOwA AAAMAAAAAwAAAGkAVwADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHwAAAG0AYQBpAGwAdABv ADoAcABhAGsAdwBlAHMAaQBvAGQAdQByAG8AQABtAHkAcwBlAGwAZgAuAGMAbwBtAAAAAAAfAAAA AQAAAAAAAAADAAAAaQBXAAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8AAAAfAAAAbQBhAGkAbAB0 AG8AOgBwAGEAawB3AGUAcwBpAG8AZAB1AHIAbwBAAG0AeQBzAGUAbABmAC4AYwBvAG0AAAAAAB8A AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAA DQAAAA4AAAD+////EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAAP7///8YAAAAGQAAABoAAAAb AAAAHAAAAB0AAAAeAAAA/v///yAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAD+////KAAAACkA AAAqAAAAKwAAACwAAAAtAAAALgAAAP7////9////MQAAAP7////+/////v////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAA AACAejZPAAfCATMAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgABAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXAAAAABAAAAAAAABXAG8AcgBk AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQYAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAi HAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAHwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQIAAAAHAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUA YwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW AAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAACAejZPAAfCAYB6Nk8AB8IBAAAAAAAA AAAAAAAAAQAAAP7///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3Vt ZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA== --===_SecAtt_000_1fvipomenjtsib --===_SecAtt_000_1fvipomenjtsib-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed May 29 09:09:02 2002 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 JAA15337 for ; Wed, 29 May 2002 09:09:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11951 for nsis-archive@odin.ietf.org; Wed, 29 May 2002 09:09:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10324; Wed, 29 May 2002 08:52:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10273 for ; Wed, 29 May 2002 08:52:33 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14582 for ; Wed, 29 May 2002 08:52:06 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TCqTmG022498; Wed, 29 May 2002 14:52:29 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LY0D7DHX; Wed, 29 May 2002 14:52:26 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 14:52:26 +0200 Message-ID: X-Sybari-Trust: 15b6e0f9 bd9ca16c 726356b0 00000138 From: "Georgios Karagiannis (ELN)" To: "'Schneider, Marco'" , "'nsis@ietf.org'" Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow reserv ations and default routing Date: Wed, 29 May 2002 14:52:24 +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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marco I am not sure, but it, at least seems to me, that this requirement is more associated to routing than to QoS signaling. Is this true? Best regards, Georgios -----Original Message----- From: Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: dinsdag 28 mei 2002 22:18 To: 'nsis@ietf.org' Cc: 'sven.van_den_bosch@alcatel.be' Subject: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing Hi All, One of the Open issues mentioned in the current requirements draft is Route Pinning (item 47). In the following I discuss a very strong motivation for the ability to do route pinning if a soft state solution is used for NSIS. I have tried to express this as a requirement upon NSIS rather than the mechanism (route pinning being the obvious one) by which this requirement may be achieved. Requirement: NSIS must directly support the ability to insulate a flow reservation from changes in the default routing behaviour except in those cases where said changes result from loss of resources (layer 3 hops, capacity etc.) along the existing flow reservation path. For instance, utilizing traffic engineering in a layer 2 network (e.g. MPLS or ATM) we may provision additional links or change the resources associated with existing links. Additionally failures in the network may cause changes. Such changes must not affect existing layer 3 reservation paths with the exception of those cases where the existing reservation path no longer exists or no longer has capacity to support the flow reservation. As a simple example consider a network with two routers A and B and assume that the shortest path from A to B is two hops. Based upon NSIS signaling, as directed by default routing based upon number of hops, a reservation path is setup from A to B along a path of two hops, where both hops have a capacity of 10 and the reservation uses a capacity of 6. Now let us assume that a direct link with capacity 5 is provisioned between A and B resulting in a new and direct default route of 1 hop. If NSIS uses a soft state solution without route pinning then the existing flow reservation will be redirected along the new link, which cannot support it. Thus the existing flow reservation is lost due a change in the network unrelated to its current path. In fact thousands of reservations may have been routed along the original path and would now be disrupted. Such protocol behaviour is not acceptable. Best Regards, Marco _______________________________________________ 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 daemon@optimus.ietf.org Wed May 29 15:11:21 2002 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 PAA29477 for ; Wed, 29 May 2002 15:11:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10708 for nsis-archive@odin.ietf.org; Wed, 29 May 2002 15:11:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09090; Wed, 29 May 2002 14:55:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08957 for ; Wed, 29 May 2002 14:55:28 -0400 (EDT) Received: from localhost.bur.adelphia.net (ma-northadams3a-202.bur.adelphia.net [24.52.12.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28803 for ; Wed, 29 May 2002 14:55:02 -0400 (EDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.bur.adelphia.net (8.10.2/8.10.2) with ESMTP id g4TIsve26892 for ; Wed, 29 May 2002 14:54:57 -0400 (EDT) Date: Wed, 29 May 2002 14:54:57 -0400 (EDT) Message-Id: <200205291854.g4TIsve26892@localhost.bur.adelphia.net> From: "The Man From Nantucket" To: nsis@ietf.org Reply-To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/html; Subject: [NSIS] Are You The Man From Nantucket? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Are You The Man From Nantucket? Are You The Man From Nantucket?

Announce it to the world with this T-Shirt for $14.99.
Click HereTo visit the store.

Don't forget, Father's Day is coming soon.





_______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed May 29 21:10:49 2002 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 VAA09680 for ; Wed, 29 May 2002 21:10:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA03655 for nsis-archive@odin.ietf.org; Wed, 29 May 2002 21:11:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02245; Wed, 29 May 2002 20:57:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02204 for ; Wed, 29 May 2002 20:57:38 -0400 (EDT) Received: from maktoob.com ([217.78.74.104]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09385 for ; Wed, 29 May 2002 20:57:01 -0400 (EDT) Message-Id: <200205300057.UAA09385@ietf.org> From: "GEN.HAMA SALAMA" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 30 May 2002 01:07:41 +0200 Reply-To: "GEN.HAMA SALAMA" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [NSIS] BUSINESS RELATIONSHIP PROPOSAL Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit BUSINESS RELATIONSHIP PROPOSAL Dear Sir, I received encouraging information about you, hence I decided to contact you. I am Gen. Hama Salama, Military Commander with POLISARIO(Political Front for the Liberation of Western Sahara) and a member of council of the National Secretariat of Western Sahara(Saharawi Democratic Republic). See web site: www.arso.org or www.arso.org/secr.nate99.htm to confirm about me and also know more about Western Sahara. Prior to my promotion to this command, I was the second in command to the former military boss. He was killed in battle in early January. Some private , religious and corporate organizations who recognize us assist/aid us always in the war prosecution. Before the death of my former boss, we were given some funds(US$55m) to procures ammunitions. My boss deposited it with a private security company in Europe. It was only I and him that are aware of thiscash deposit. I now want to claim this funds and I have all the relating documents needed to collect the deposit including the Certificate of Deposit with which the Cash was deposited as Precious stones and The Deposit Agreement. I therefore want you to team up with me to collect the funds in Europe as I require a foreigner to perfect the operation. Let me know your terms. I will provide you with all the necessary documentation needed and there are no risks involved. It is a simple and straight transaction but must bekept highly confidential. Upon the receipt of your positive response, further details and the method of operation will be communicated to you. Therefore if you are interested, please do reach me via an immediate reply mail. I will want everything about this transaction to be treated in strictest confidence even if you are notinterested.I await your response. Yours Gen Hama Salama Military CommanderWestern Sahara _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Thu May 30 00:43:02 2002 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 AAA13798 for ; Thu, 30 May 2002 00:42:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA15314 for nsis-archive@odin.ietf.org; Thu, 30 May 2002 00:43:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA13945; Thu, 30 May 2002 00:27:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04219 for ; Mon, 27 May 2002 05:49:33 -0400 (EDT) Received: from nero.informatik.uni-wuerzburg.de (root@wi3x05.informatik.uni-wuerzburg.de [132.187.106.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15478; Mon, 27 May 2002 05:48:52 -0400 (EDT) Received: from PROMETHEUS (prometheus.informatik.uni-wuerzburg.de [132.187.106.139]) by nero.informatik.uni-wuerzburg.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with SMTP id g4R9mo130064; Mon, 27 May 2002 11:48:51 +0200 Message-ID: <000b01c20564$b20cb180$8b6abb84@PROMETHEUS> From: "Kurt Tutschku" To: "mpls \(ietf\)" , "sigtran \(ietf\)" , "end2end \(irtf\)" , "ITC list" , "nsis \(ietf\)" , "cost 279" , "ppvpn \(ietf\)" , "ITG Fachtagung Messung, Modellierung und Bewertung" , "ITG 524" , "ITG 523" , "ITG 521" , "cost 257" , "ipo \(ietf\)" , "tewg \(ietf\)" , "ippm \(ietf\)" , "mobileip \(ietf\)" , "manet \(ietf\)" , "nmrg \(irtf\)" , "rr \(irtf\)" , "ccamp \(ietf\)" , "ipv6 \(ietf\)" , "disman \(ietf\)" , =?iso-8859-1?Q?Paul_Schl=FCter?= , "Notker Gerlich" , "Hans Schwefel" , "Thomas Reim" , "Stefan Schneeberger" , "Michael Schopp" , "Franz Hartleb" , "Klaus Dolzer" , "Bart Sanders" , =?iso-8859-1?Q?Michael_S=F6llner?= , "Wolfgang Wagner" , "Walter Leonhardt" , "Norbert Rauh" , =?iso-8859-1?Q?Silvia_Sch=E4ffler?= , "Wolfgang Stegmann" , "Andreas Lamsa" , "Karl Heinz Allgeyer" , "Lothar Lux" , =?iso-8859-1?Q?Bernd_Schr=F6der?= , "Albert Weller" , =?iso-8859-1?Q?J=FCrgen_Tenckhoff?= , "Norbert Schultze" , =?iso-8859-1?Q?Norbert_Schl=FCter?= , "Laslo Slawitschka" , "Gabriel Zgunea" , "Bernhard Liesenfeld" , =?iso-8859-1?Q?J=FCrgen_Beyer?= , "Zhongrong Liu" , "Bernd Pfeiffer" , "Hans Barth" , "Wolf Mende" , "Wolfgang Urmoneit" , "Dieter Marger" , "Charles E. Perkins" , "Ake Arvidsson" , =?iso-8859-1?Q?Angelika_M=FCller?= , "Armin Heindl" , "Bo Friis Nielsen" , "Holger Hermanns" , "Jacques Resing" , "Jose Brazio" , "Stephen Hanly" , "Matthew Roughan" , "Reinhard German" , "Rudolf Mathar" , "Ulrich Herzog" , "Dieter Baum" , "Lothar Breuer" , "Marie-Ange Remiche" , "Markus Siegle" , "Nikhil Jain" , "Peter Taylor" , "Sem Borst" , "Ute Kohlhaas" , "Jeroen Wieland" Date: Mon, 27 May 2002 11:55:40 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01C20575.6CDE84B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [NSIS] 15th ITC Specialist Seminar: Call for participation Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C20575.6CDE84B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C20575.6CE93310" ------=_NextPart_001_0008_01C20575.6CE93310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE COPIES =20 1st CALL FOR PARTICIPATION: =20 Dear colleagues, =20 we'd like to announce an upcoming ITC Specialist Seminar: =20 15th ITC Specialist Seminar: "Internet Traffic Engineering=20 and Traffic Management (IP2002)", July 22-24 2002, Wuerzburg,=20 Germany. =20 http://www.itcspecialistseminar.com/=20 =20 The seminar will bring researchers and practitioners in the=20 area of Internet traffic engineering and traffic management=20 together to present the most up-to-date results and achievements=20 in the field. =20 The seminar will feature 28 rigorously reviewed contributions,=20 a keynote speech from one of the leading experts in IP tele- traffic engineering, and a high-ranked panel of industry experts and researchers.=20 The program of the workshop will soon be available on the seminar's website.=20 =20 =20 a) Seminar registration: =20 A registration form for the IP2002 workshop is available at:=20 =20 http://www.itcspecialistseminar.com/RegistrationForm.pdf =20 The deadline for early registration is June 22, 2002. =20 =20 b) Hotel reservation: =20 The seminar's web pages provides a reservation form for=20 accommodations in Wuerzburg. A hotel reservation form is available at:=20 =20 http://www.itcspecialistseminar.com/HotelReservation.pdf =20 The deadline for advance hotel reservation is June16, 2002. =20 Please remember that July is touristic high season in Germany.=20 We strongly advise you to book your hotel as soon as possible.=20 =20 =20 We are looking forward to welcome you in Wuerzburg. Best Regards, Phuoc Tran-Gia James Roberts Kurt Tutschku Klaus Heck, your IP2002 Organizing Team ------=_NextPart_001_0008_01C20575.6CE93310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE=20 COPIES

 

1st=20 CALL FOR PARTICIPATION:

 

Dear=20 colleagues,

 

we'd=20 like to announce an upcoming ITC Specialist=20 Seminar:

 

15th=20 ITC Specialist Seminar: "Internet Traffic Engineering=20

and=20 Traffic Management (IP2002)", July 22-24 2002, Wuerzburg,=20

Germany.

 

http://www.itcspecialistseminar.com/=20

 

The=20 seminar will bring researchers and practitioners in the=20

area=20 of Internet traffic engineering and traffic management=20

together to present the most up-to-date results = and=20 achievements

in=20 the field.

 

The=20 seminar will feature 28 rigorously reviewed contributions,=20

a=20 keynote speech from one of the leading experts in IP=20 tele-

traffic engineering, and a high-ranked panel of = industry=20 experts

and=20 researchers.

The=20 program of the workshop will soon be available on the=20 seminar=92s

website.

 

 

a)=20 Seminar registration:

 

A=20 registration form for the IP2002 workshop is available at:=20

 

http://www.itcspecialistseminar.com/RegistrationForm.pdf

 

The=20 deadline for early registration is June 22,=20 2002.

 

 

b)=20 Hotel reservation:

 

The=20 seminar=92s web pages provides a reservation form for=20

accommodations in Wuerzburg. A hotel = reservation form=20 is

available at: =

 

http://www.itcspecialistseminar.com/HotelReservation.pdf

 

The=20 deadline for advance hotel reservation is June16,=20 2002.

 

Please remember that July is touristic high = season in=20 Germany.

We=20 strongly advise you to book your hotel as soon as possible.=20

 

 

We=20 are looking forward to welcome you in=20 Wuerzburg.

Best=20 Regards,

Phuoc=20 Tran-Gia

James Roberts

Kurt Tutschku

Klaus=20 Heck, your IP2002 Organizing=20 Team

------=_NextPart_001_0008_01C20575.6CE93310-- ------=_NextPart_000_0007_01C20575.6CDE84B0 Content-Type: application/pdf; name="ITC_c4p.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ITC_c4p.pdf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjEyMiAwIG9iag08PCANL0xpbmVhcml6ZWQgMSANL08gMTI1IA0vSCBb IDgzMDUgNzczIF0gDS9MIDE0NjU3NyANL0UgMTMwNTI2IA0vTiAyIA0vVCAxNDQwMTggDT4+IA1l bmRvYmoNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTEyMiAzNzQgDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwNzgzMiAwMDAwMCBuDQow MDAwMDA4MTY5IDAwMDAwIG4NCjAwMDAwMDkwNzggMDAwMDAgbg0KMDAwMDAxMzA3OCAwMDAwMCBu DQowMDAwMDEzMjM1IDAwMDAwIG4NCjAwMDAwMTMzOTYgMDAwMDAgbg0KMDAwMDAxMzU1NyAwMDAw MCBuDQowMDAwMDEzNzE3IDAwMDAwIG4NCjAwMDAwMTM4NzggMDAwMDAgbg0KMDAwMDAxNDAzNyAw MDAwMCBuDQowMDAwMDE0MDg4IDAwMDAwIG4NCjAwMDAwMTQxMzkgMDAwMDAgbg0KMDAwMDAxNDE5 MCAwMDAwMCBuDQowMDAwMDE0MjQxIDAwMDAwIG4NCjAwMDAwMTQyOTIgMDAwMDAgbg0KMDAwMDAx NDM0MyAwMDAwMCBuDQowMDAwMDE0Mzk0IDAwMDAwIG4NCjAwMDAwMTQ0NDQgMDAwMDAgbg0KMDAw MDAxNDQ5NSAwMDAwMCBuDQowMDAwMDE0NTQ2IDAwMDAwIG4NCjAwMDAwMTQ1OTcgMDAwMDAgbg0K MDAwMDAxNDY0OCAwMDAwMCBuDQowMDAwMDE0Njk5IDAwMDAwIG4NCjAwMDAwMTQ3NTAgMDAwMDAg bg0KMDAwMDAxNDgwMSAwMDAwMCBuDQowMDAwMDE0ODUyIDAwMDAwIG4NCjAwMDAwMTQ5MDMgMDAw MDAgbg0KMDAwMDAxNDk1NCAwMDAwMCBuDQowMDAwMDE1MDA1IDAwMDAwIG4NCjAwMDAwMTUwNTYg MDAwMDAgbg0KMDAwMDAxNTEwNyAwMDAwMCBuDQowMDAwMDE1MTU4IDAwMDAwIG4NCjAwMDAwMTUy MDkgMDAwMDAgbg0KMDAwMDAxNTI2MCAwMDAwMCBuDQowMDAwMDE1MzExIDAwMDAwIG4NCjAwMDAw MTUzNjIgMDAwMDAgbg0KMDAwMDAxNTQxMyAwMDAwMCBuDQowMDAwMDE1NDY0IDAwMDAwIG4NCjAw MDAwMTU1MTUgMDAwMDAgbg0KMDAwMDAxNTU2NiAwMDAwMCBuDQowMDAwMDE1NjE2IDAwMDAwIG4N CjAwMDAwMTU2NjcgMDAwMDAgbg0KMDAwMDAxNTcxOCAwMDAwMCBuDQowMDAwMDE1NzY5IDAwMDAw IG4NCjAwMDAwMTU4MjAgMDAwMDAgbg0KMDAwMDAxNTg3MSAwMDAwMCBuDQowMDAwMDE1OTIxIDAw MDAwIG4NCjAwMDAwMTU5NzIgMDAwMDAgbg0KMDAwMDAxNjAyMyAwMDAwMCBuDQowMDAwMDE2MDc0 IDAwMDAwIG4NCjAwMDAwMTYxMjUgMDAwMDAgbg0KMDAwMDAxNjE3NiAwMDAwMCBuDQowMDAwMDE2 MjI2IDAwMDAwIG4NCjAwMDAwMTYyNzcgMDAwMDAgbg0KMDAwMDAxNjMyOCAwMDAwMCBuDQowMDAw MDE2Mzc5IDAwMDAwIG4NCjAwMDAwMTY0MzAgMDAwMDAgbg0KMDAwMDAxNjQ4MSAwMDAwMCBuDQow MDAwMDE2NTMyIDAwMDAwIG4NCjAwMDAwMTY1ODMgMDAwMDAgbg0KMDAwMDAxNjYzNCAwMDAwMCBu DQowMDAwMDE2Njg1IDAwMDAwIG4NCjAwMDAwMTY3MzYgMDAwMDAgbg0KMDAwMDAxNjc4NyAwMDAw MCBuDQowMDAwMDE2ODM4IDAwMDAwIG4NCjAwMDAwMTY4ODkgMDAwMDAgbg0KMDAwMDAxNjk0MCAw MDAwMCBuDQowMDAwMDE2OTkxIDAwMDAwIG4NCjAwMDAwMTcwNDIgMDAwMDAgbg0KMDAwMDAxNzA5 MyAwMDAwMCBuDQowMDAwMDE3MTQ0IDAwMDAwIG4NCjAwMDAwMTcxOTUgMDAwMDAgbg0KMDAwMDAx NzI0NiAwMDAwMCBuDQowMDAwMDE3Mjc2IDAwMDAwIG4NCjAwMDAwMTczMTcgMDAwMDAgbg0KMDAw MDAxNzM2OCAwMDAwMCBuDQowMDAwMDE3NDE4IDAwMDAwIG4NCjAwMDAwMTc0NjkgMDAwMDAgbg0K MDAwMDAxNzUxOSAwMDAwMCBuDQowMDAwMDE3NTcwIDAwMDAwIG4NCjAwMDAwMTc2MjEgMDAwMDAg bg0KMDAwMDAxNzY3MiAwMDAwMCBuDQowMDAwMDE3NzIyIDAwMDAwIG4NCjAwMDAwMTc3NzMgMDAw MDAgbg0KMDAwMDAxODUzMiAwMDAwMCBuDQowMDAwMDE4NzU2IDAwMDAwIG4NCjAwMDAwMTg4MDcg MDAwMDAgbg0KMDAwMDAxODg1OCAwMDAwMCBuDQowMDAwMDE4OTA5IDAwMDAwIG4NCjAwMDAwMTg5 NTkgMDAwMDAgbg0KMDAwMDAxOTAxMCAwMDAwMCBuDQowMDAwMDE5MDYxIDAwMDAwIG4NCjAwMDAw MTkxMTIgMDAwMDAgbg0KMDAwMDAxOTE2MyAwMDAwMCBuDQowMDAwMDE5MjE0IDAwMDAwIG4NCjAw MDAwMTkyNjUgMDAwMDAgbg0KMDAwMDAxOTMxNiAwMDAwMCBuDQowMDAwMDE5MzY3IDAwMDAwIG4N CjAwMDAwMTk0MTggMDAwMDAgbg0KMDAwMDAxOTQ2OSAwMDAwMCBuDQowMDAwMDE5NTIwIDAwMDAw IG4NCjAwMDAwMTk1NzEgMDAwMDAgbg0KMDAwMDAxOTYyMiAwMDAwMCBuDQowMDAwMDE5NjczIDAw MDAwIG4NCjAwMDAwMTk3MjQgMDAwMDAgbg0KMDAwMDAxOTc3NSAwMDAwMCBuDQowMDAwMDE5ODI2 IDAwMDAwIG4NCjAwMDAwMTk4NzcgMDAwMDAgbg0KMDAwMDAxOTg5OSAwMDAwMCBuDQowMDAwMDIw NzIzIDAwMDAwIG4NCjAwMDAwMjA3NDUgMDAwMDAgbg0KMDAwMDAyMTM5OCAwMDAwMCBuDQowMDAw MDIxNDIwIDAwMDAwIG4NCjAwMDAwMjIwNTEgMDAwMDAgbg0KMDAwMDAyMjI3OSAwMDAwMCBuDQow MDAwMDIyNjAyIDAwMDAwIG4NCjAwMDAwMjMwMjEgMDAwMDAgbg0KMDAwMDAyMzIzNyAwMDAwMCBu DQowMDAwMDIzMjU5IDAwMDAwIG4NCjAwMDAwMjM5NjggMDAwMDAgbg0KMDAwMDAyMzk5MCAwMDAw MCBuDQowMDAwMDI0NzQ2IDAwMDAwIG4NCjAwMDAwMjQ3NjggMDAwMDAgbg0KMDAwMDAyNTUyOSAw MDAwMCBuDQowMDAwMDI1NzE5IDAwMDAwIG4NCjAwMDAwMjU5MzQgMDAwMDAgbg0KMDAwMDAyNTk1 NiAwMDAwMCBuDQowMDAwMDI2NzM1IDAwMDAwIG4NCjAwMDAwMjY3NTcgMDAwMDAgbg0KMDAwMDAy NzUzOSAwMDAwMCBuDQowMDAwMDI3NzI4IDAwMDAwIG4NCjAwMDAwMjc4MjEgMDAwMDAgbg0KMDAw MDAzNzkwMSAwMDAwMCBuDQowMDAwMDU5MDIzIDAwMDAwIG4NCjAwMDAwNTkxMjIgMDAwMDAgbg0K MDAwMDA1OTIwNiAwMDAwMCBuDQowMDAwMDU5Mjk5IDAwMDAwIG4NCjAwMDAwNTk0MDcgMDAwMDAg bg0KMDAwMDA1OTQ5MSAwMDAwMCBuDQowMDAwMDc0MTYyIDAwMDAwIG4NCjAwMDAwNzQzMzkgMDAw MDAgbg0KMDAwMDA3NDQzNSAwMDAwMCBuDQowMDAwMDc0NTQ5IDAwMDAwIG4NCjAwMDAwNzQ2Mzkg MDAwMDAgbg0KMDAwMDA3NDc2OCAwMDAwMCBuDQowMDAwMDc0ODY0IDAwMDAwIG4NCjAwMDAwNzQ5 NjMgMDAwMDAgbg0KMDAwMDA3NTE0NiAwMDAwMCBuDQowMDAwMDc1MzI0IDAwMDAwIG4NCjAwMDAw NzU0MjAgMDAwMDAgbg0KMDAwMDA3NTU5MCAwMDAwMCBuDQowMDAwMDc1NjgzIDAwMDAwIG4NCjAw MDAwNzU3NDIgMDAwMDAgbg0KMDAwMDA3NTgwNSAwMDAwMCBuDQowMDAwMDc1OTM3IDAwMDAwIG4N CjAwMDAwNzYwNjkgMDAwMDAgbg0KMDAwMDA4MzgxMiAwMDAwMCBuDQowMDAwMDgzOTQxIDAwMDAw IG4NCjAwMDAwODQwNDAgMDAwMDAgbg0KMDAwMDA4NDEzNiAwMDAwMCBuDQowMDAwMDg0MjMyIDAw MDAwIG4NCjAwMDAwODY5MTAgMDAwMDAgbg0KMDAwMDA4NzAwMCAwMDAwMCBuDQowMDAwMDg3MTI5 IDAwMDAwIG4NCjAwMDAwODcyNDAgMDAwMDAgbg0KMDAwMDA4NzMzNiAwMDAwMCBuDQowMDAwMDg3 NDMyIDAwMDAwIG4NCjAwMDAwODc1MjIgMDAwMDAgbg0KMDAwMDA4NzYxNSAwMDAwMCBuDQowMDAw MDg3NzExIDAwMDAwIG4NCjAwMDAwODc4MTMgMDAwMDAgbg0KMDAwMDA4NzkwOSAwMDAwMCBuDQow MDAwMDg4MDA4IDAwMDAwIG4NCjAwMDAwODgxMDEgMDAwMDAgbg0KMDAwMDA4ODE5NyAwMDAwMCBu DQowMDAwMDg4Mjk5IDAwMDAwIG4NCjAwMDAwODg0MDQgMDAwMDAgbg0KMDAwMDA4ODQ5NCAwMDAw MCBuDQowMDAwMDg4NTk5IDAwMDAwIG4NCjAwMDAwODg3MDQgMDAwMDAgbg0KMDAwMDA4ODgxNSAw MDAwMCBuDQowMDAwMDg4OTExIDAwMDAwIG4NCjAwMDAwODkwMTYgMDAwMDAgbg0KMDAwMDA4OTIy MyAwMDAwMCBuDQowMDAwMDg5MzAyIDAwMDAwIG4NCjAwMDAwODkzNzQgMDAwMDAgbg0KMDAwMDA4 OTQ3MiAwMDAwMCBuDQowMDAwMDg5NTUzIDAwMDAwIG4NCjAwMDAwODk2MjcgMDAwMDAgbg0KMDAw MDA4OTcyNSAwMDAwMCBuDQowMDAwMDg5ODA2IDAwMDAwIG4NCjAwMDAwODk5MDIgMDAwMDAgbg0K MDAwMDA5MDA4MiAwMDAwMCBuDQowMDAwMDkwMjA4IDAwMDAwIG4NCjAwMDAwOTAzMjIgMDAwMDAg bg0KMDAwMDA5MDUxNCAwMDAwMCBuDQowMDAwMDkwNjQwIDAwMDAwIG4NCjAwMDAwOTA4MTEgMDAw MDAgbg0KMDAwMDA5MDk4NCAwMDAwMCBuDQowMDAwMDkxMTcwIDAwMDAwIG4NCjAwMDAwOTEyNzIg MDAwMDAgbg0KMDAwMDA5MTM2OCAwMDAwMCBuDQowMDAwMDkxNDY0IDAwMDAwIG4NCjAwMDAwOTE1 NTEgMDAwMDAgbg0KMDAwMDA5MTY0NCAwMDAwMCBuDQowMDAwMDkxNzMxIDAwMDAwIG4NCjAwMDAw OTE5MzUgMDAwMDAgbg0KMDAwMDA5MjA0NiAwMDAwMCBuDQowMDAwMDkyMTM5IDAwMDAwIG4NCjAw MDAwOTIyMjkgMDAwMDAgbg0KMDAwMDA5MjMxNiAwMDAwMCBuDQowMDAwMDkyNDAzIDAwMDAwIG4N CjAwMDAwOTI0OTAgMDAwMDAgbg0KMDAwMDA5MjU2NSAwMDAwMCBuDQowMDAwMDkyNjU4IDAwMDAw IG4NCjAwMDAwOTI3NTEgMDAwMDAgbg0KMDAwMDA5MjgzNSAwMDAwMCBuDQowMDAwMDkyOTI1IDAw MDAwIG4NCjAwMDAwOTMxOTggMDAwMDAgbg0KMDAwMDA5MzM4MSAwMDAwMCBuDQowMDAwMDkzNDk1 IDAwMDAwIG4NCjAwMDAwOTM2NzMgMDAwMDAgbg0KMDAwMDA5Mzc5OSAwMDAwMCBuDQowMDAwMDkz ODk1IDAwMDAwIG4NCjAwMDAwOTM5OTEgMDAwMDAgbg0KMDAwMDA5NDEwOCAwMDAwMCBuDQowMDAw MDk0MjEwIDAwMDAwIG4NCjAwMDAwOTQzMzYgMDAwMDAgbg0KMDAwMDA5NDQxMSAwMDAwMCBuDQow MDAwMDk0NjcyIDAwMDAwIG4NCjAwMDAwOTQ3OTUgMDAwMDAgbg0KMDAwMDA5NDg5NCAwMDAwMCBu DQowMDAwMDk1MDI2IDAwMDAwIG4NCjAwMDAwOTUxNDkgMDAwMDAgbg0KMDAwMDA5NTI3NSAwMDAw MCBuDQowMDAwMDk1NDAxIDAwMDAwIG4NCjAwMDAwOTU1ODcgMDAwMDAgbg0KMDAwMDA5NTc3NCAw MDAwMCBuDQowMDAwMDk1OTYwIDAwMDAwIG4NCjAwMDAwOTYxNDcgMDAwMDAgbg0KMDAwMDA5NjMz NCAwMDAwMCBuDQowMDAwMDk2NTIyIDAwMDAwIG4NCjAwMDAwOTY3MTcgMDAwMDAgbg0KMDAwMDA5 NjkxNiAwMDAwMCBuDQowMDAwMDk3MTIxIDAwMDAwIG4NCjAwMDAwOTczMjYgMDAwMDAgbg0KMDAw MDA5NzUzNCAwMDAwMCBuDQowMDAwMDk3NzQ2IDAwMDAwIG4NCjAwMDAwOTc5NTcgMDAwMDAgbg0K MDAwMDA5ODE3MCAwMDAwMCBuDQowMDAwMDk4Mzg2IDAwMDAwIG4NCjAwMDAwOTg2MDMgMDAwMDAg bg0KMDAwMDA5ODgxNiAwMDAwMCBuDQowMDAwMDk5MDMyIDAwMDAwIG4NCjAwMDAwOTkyNDYgMDAw MDAgbg0KMDAwMDA5OTQ2NyAwMDAwMCBuDQowMDAwMDk5Njk0IDAwMDAwIG4NCjAwMDAwOTk5MzIg MDAwMDAgbg0KMDAwMDEwMDE4NSAwMDAwMCBuDQowMDAwMTAwNDM2IDAwMDAwIG4NCjAwMDAxMDA2 OTYgMDAwMDAgbg0KMDAwMDEwMDk1MyAwMDAwMCBuDQowMDAwMTAxMjE3IDAwMDAwIG4NCjAwMDAx MDE0NzggMDAwMDAgbg0KMDAwMDEwMTczMSAwMDAwMCBuDQowMDAwMTAxOTg1IDAwMDAwIG4NCjAw MDAxMDIyNTYgMDAwMDAgbg0KMDAwMDEwMjUyMiAwMDAwMCBuDQowMDAwMTAyNzgxIDAwMDAwIG4N CjAwMDAxMDMwMjIgMDAwMDAgbg0KMDAwMDEwMzI2MCAwMDAwMCBuDQowMDAwMTAzNTAwIDAwMDAw IG4NCjAwMDAxMDM3MzQgMDAwMDAgbg0KMDAwMDEwMzk3MCAwMDAwMCBuDQowMDAwMTA0MjA1IDAw MDAwIG4NCjAwMDAxMDQ0MzYgMDAwMDAgbg0KMDAwMDEwNDY3MCAwMDAwMCBuDQowMDAwMTA0OTAz IDAwMDAwIG4NCjAwMDAxMDUxMzQgMDAwMDAgbg0KMDAwMDEwNTM2NiAwMDAwMCBuDQowMDAwMTA1 NjAwIDAwMDAwIG4NCjAwMDAxMDU4MzUgMDAwMDAgbg0KMDAwMDEwNjA5MSAwMDAwMCBuDQowMDAw MTA2MzE5IDAwMDAwIG4NCjAwMDAxMDY1NTAgMDAwMDAgbg0KMDAwMDEwNjc4MSAwMDAwMCBuDQow MDAwMTA3MDEwIDAwMDAwIG4NCjAwMDAxMDcyMzMgMDAwMDAgbg0KMDAwMDEwNzQ1NSAwMDAwMCBu DQowMDAwMTA3NzAyIDAwMDAwIG4NCjAwMDAxMDc5MjggMDAwMDAgbg0KMDAwMDEwODE2MSAwMDAw MCBuDQowMDAwMTA4Mzk2IDAwMDAwIG4NCjAwMDAxMDg2MzEgMDAwMDAgbg0KMDAwMDEwODg2MyAw MDAwMCBuDQowMDAwMTA5MDk2IDAwMDAwIG4NCjAwMDAxMDkzMjggMDAwMDAgbg0KMDAwMDEwOTU2 NCAwMDAwMCBuDQowMDAwMTA5Nzk5IDAwMDAwIG4NCjAwMDAxMTAwMzQgMDAwMDAgbg0KMDAwMDEx MDI5OCAwMDAwMCBuDQowMDAwMTEwNTI3IDAwMDAwIG4NCjAwMDAxMTA4NzYgMDAwMDAgbg0KMDAw MDExMTExNyAwMDAwMCBuDQowMDAwMTExNTAxIDAwMDAwIG4NCjAwMDAxMTE3NTcgMDAwMDAgbg0K MDAwMDExMjIxMSAwMDAwMCBuDQowMDAwMTEyNDQ1IDAwMDAwIG4NCjAwMDAxMTI3MTUgMDAwMDAg bg0KMDAwMDExMzAwMiAwMDAwMCBuDQowMDAwMTEzMjUzIDAwMDAwIG4NCjAwMDAxMTM0OTQgMDAw MDAgbg0KMDAwMDExMzczMSAwMDAwMCBuDQowMDAwMTEzOTY0IDAwMDAwIG4NCjAwMDAxMTQyNDAg MDAwMDAgbg0KMDAwMDExNDQ2OSAwMDAwMCBuDQowMDAwMTE0NzMzIDAwMDAwIG4NCjAwMDAxMTQ5 NjIgMDAwMDAgbg0KMDAwMDExNTE4NyAwMDAwMCBuDQowMDAwMTE1NDA3IDAwMDAwIG4NCjAwMDAx MTU2MjEgMDAwMDAgbg0KMDAwMDExNTgzOSAwMDAwMCBuDQowMDAwMTE2MDU2IDAwMDAwIG4NCjAw MDAxMTYyNjggMDAwMDAgbg0KMDAwMDExNjQ4MyAwMDAwMCBuDQowMDAwMTE2NjkzIDAwMDAwIG4N CjAwMDAxMTY5MDMgMDAwMDAgbg0KMDAwMDExNzEzOCAwMDAwMCBuDQowMDAwMTE3MzU1IDAwMDAw IG4NCjAwMDAxMTc1ODQgMDAwMDAgbg0KMDAwMDExNzgyMCAwMDAwMCBuDQowMDAwMTE4MDUyIDAw MDAwIG4NCjAwMDAxMTgyODMgMDAwMDAgbg0KMDAwMDExODUxNyAwMDAwMCBuDQowMDAwMTE4NzQ4 IDAwMDAwIG4NCjAwMDAxMTg5ODMgMDAwMDAgbg0KMDAwMDExOTIxNCAwMDAwMCBuDQowMDAwMTE5 NDQ4IDAwMDAwIG4NCjAwMDAxMTk2NzggMDAwMDAgbg0KMDAwMDExOTkwNyAwMDAwMCBuDQowMDAw MTIwMTM4IDAwMDAwIG4NCjAwMDAxMjAzNjggMDAwMDAgbg0KMDAwMDEyMDYxMSAwMDAwMCBuDQow MDAwMTIwODYwIDAwMDAwIG4NCjAwMDAxMjExMTUgMDAwMDAgbg0KMDAwMDEyMTM3NiAwMDAwMCBu DQowMDAwMTIxNjI2IDAwMDAwIG4NCjAwMDAxMjE4NzkgMDAwMDAgbg0KMDAwMDEyMjEyNyAwMDAw MCBuDQowMDAwMTIyMzU4IDAwMDAwIG4NCjAwMDAxMjI1ODIgMDAwMDAgbg0KMDAwMDEyMjc5NyAw MDAwMCBuDQowMDAwMTIzMDE0IDAwMDAwIG4NCjAwMDAxMjMyMzEgMDAwMDAgbg0KMDAwMDEyMzQ0 OCAwMDAwMCBuDQowMDAwMTIzNjYxIDAwMDAwIG4NCjAwMDAxMjM4NzMgMDAwMDAgbg0KMDAwMDEy NDA4NSAwMDAwMCBuDQowMDAwMTI0Mjk2IDAwMDAwIG4NCjAwMDAxMjQ1MDcgMDAwMDAgbg0KMDAw MDEyNDcxNSAwMDAwMCBuDQowMDAwMTI0OTI0IDAwMDAwIG4NCjAwMDAxMjUxMjIgMDAwMDAgbg0K MDAwMDEyNTMyNiAwMDAwMCBuDQowMDAwMTI1NTE5IDAwMDAwIG4NCjAwMDAxMjU3MDcgMDAwMDAg bg0KMDAwMDEyNTg5NCAwMDAwMCBuDQowMDAwMTI2MDgxIDAwMDAwIG4NCjAwMDAxMjYyNjcgMDAw MDAgbg0KMDAwMDEyNjQ1MyAwMDAwMCBuDQowMDAwMTI2NjM5IDAwMDAwIG4NCjAwMDAwMDgzMDUg MDAwMDAgbg0KMDAwMDAwOTA1NiAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDQ5Ng0vSW5mbyAx MTkgMCBSIA0vUm9vdCAxMjMgMCBSIA0vUHJldiAxNDQwMDcgDS9JRFs8YzdiMTAwMjQxOTkwOTEx ZTdhYjE5YjJmOTVjNTEwMjM+PGY1MTU3OTNlYjIyM2RhYTRhYjM4NjljMWZhYTY3YjIzPl0NPj4N c3RhcnR4cmVmDTANJSVFT0YNICAgIA0xMjMgMCBvYmoNPDwgDS9UeXBlIC9DYXRhbG9nIA0vUGFn ZXMgMTIxIDAgUiANL01ldGFkYXRhIDEyMCAwIFIgDS9PcGVuQWN0aW9uIFsgMTI1IDAgUiAvWFla IG51bGwgbnVsbCBudWxsIF0gDS9QYWdlTW9kZSAvVXNlTm9uZSANL1BhZ2VMYWJlbHMgMTE4IDAg UiANL1N0cnVjdFRyZWVSb290IDEyNCAwIFIgDS9QaWVjZUluZm8gPDwgL01hcmtlZFBERiA8PCAv TGFzdE1vZGlmaWVkIChEOjIwMDIwNTI3MTE1MzQ4KT4+ID4+IA0vTGFzdE1vZGlmaWVkIChEOjIw MDIwNTI3MTE1MzQ4KQ0vTWFya0luZm8gPDwgL01hcmtlZCB0cnVlIC9MZXR0ZXJzcGFjZUZsYWdz IDAgPj4gDT4+IA1lbmRvYmoNMTI0IDAgb2JqDTw8IA0vVHlwZSAvU3RydWN0VHJlZVJvb3QgDS9D bGFzc01hcCA5IDAgUiANL1JvbGVNYXAgOCAwIFIgDS9LIDEwMSAwIFIgDS9QYXJlbnRUcmVlIDEw NCAwIFIgDS9QYXJlbnRUcmVlTmV4dEtleSA3IA0+PiANZW5kb2JqDTQ5NCAwIG9iag08PCAvUyA0 MjIgL0wgMTE4OSAvQyAxMjA1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNDk1IDAgUiA+ PiANc3RyZWFtDQpIieRTTUhUURT+7n0/896M4/jykToz0sMQsygHHaNcxE2GiCh7pZJIP5MImYk9 TcuFxCUqbBNBLVpUvMJsiIJZ9GO1eSRESMhblLVw8RZC0splUVRXEaRNmNsOHD6+c75zzj0XDgAZ sPqgA6E8DCybAU1EZWjPOObuisDHKP47O7DemDxUfGVy9un+zYZmraKDVLe1a2QVxoFWAYs/L0wB JcUA6RN+ZjGyFrF1Jk3KbVreYBVehpejAQOYI77khlgh/qT8LxTL1FvOOiuqZTKKl8RLtUk0RC6q 9sqfgbIioCkASfEp2q6mVUFbBT0ttn5DXVUDjrogw3iAq7c3Xs/KfsgzvE3Y0d9Pe6iteBqPe5XY RxqpQ22daYHOTN6LmaFRqU32dbbmUgoZTJNOasuuxg0htnGDpOk22Q3D9CrQjLGFrJIqsQpZGfbi LHyalfI6q+JpHCYtxJVzumNyE5XYgwskSbVINmIZonanoDLJyY4WxHgFvpNG4siBysVcXsNt+Hgf GlJt3U3wWt4l+l5TNoSZ6VazZjwmHXRGGY+4JV4NO8Zfk8v0h1pUgNKgjvXgM5mUxkNtMas82O4N 4BuZk56on6I8wepxCh/IPclWb0aL4oJ28y/klpRRRwrmy6xaOPwdGZNa1FzUimfTfEH8UHqrDplO ItvOB0me5KRA211oJ7L13kn+k9xZyBbkS70UOjBBhiVZCSJe3E15J/g0GRWdXTHITbNu+EKcUXnU T2Yb2Dk+S6akETHXLbVS3nE+Qc7Tr8p8xC9xt/AjPE966CMlFbbFvjiI0cQudFLn369oELT6vkAq vEl4SJzDmMBeoOqXwDC0cfpCeiW/VJ6rvwUYAMG08oINZW5kc3RyZWFtDWVuZG9iag00OTUgMCBv YmoNNjQ4IA1lbmRvYmoNMTI1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxMjEgMCBS IA0vUmVzb3VyY2VzIDw8IC9Db2xvclNwYWNlIDw8IC9DUzk2IDE5NiAwIFIgL0NTOTcgMTk1IDAg UiAvQ1M5OCAxOTggMCBSIC9DUzk5IDIwNCAwIFIgL0NTMTAwIDIwMCAwIFIgDS9DUzEwMSAyMjkg MCBSIC9DUzEwMiAyMTggMCBSIC9DUzEwMyAyMTUgMCBSIC9DUzEwNCAyMjQgMCBSIC9DUzEwNSAy MjEgMCBSIA0vQ1MxMDYgMTUwIDAgUiAvQ1MxMDcgMTQ5IDAgUiAvQ1MxMDggMTkyIDAgUiAvQ1Mx MDkgMTYwIDAgUiAvQ1MxMTAgMTU1IDAgUiANL0NTMTExIDEzNSAwIFIgL0NTMTEyIDEzNCAwIFIg L0NTMTEzIDEzOCAwIFIgL0NTMTE0IDE0NSAwIFIgL0NTMTE1IDE0MCAwIFIgDS9DUzExNiAxODEg MCBSIC9DUzExNyAxODAgMCBSIC9DUzExOCAxNzkgMCBSIC9DUzExOSAxOTAgMCBSIC9DUzEyMCAx ODUgMCBSIA0vQ1MxMjEgMTc2IDAgUiAvQ1MxMjIgMTY3IDAgUiAvQ1MxMjMgMTYzIDAgUiAvQ1Mx MjQgMTc0IDAgUiAvQ1MxMjUgMTY5IDAgUiANL0NTMTI2IDE3MSAwIFIgL0NTMTI3IDE3MCAwIFIg L0NTMTI4IDE3MiAwIFIgL0NTMTI5IDE3NSAwIFIgL0NTMTMwIDE3MyAwIFIgDS9DUzEzMSAxNjgg MCBSIC9DUzEzMiAxNjIgMCBSIC9DUzEzMyAxNjQgMCBSIC9DUzEzNCAxNjYgMCBSIC9DUzEzNSAx NjUgMCBSIA0vQ1MxMzYgMTg3IDAgUiAvQ1MxMzcgMTg2IDAgUiAvQ1MxMzggMTg4IDAgUiAvQ1Mx MzkgMTkxIDAgUiAvQ1MxNDAgMTg5IDAgUiANL0NTMTQxIDE4NCAwIFIgL0NTMTQyIDE3OCAwIFIg L0NTMTQzIDE3NyAwIFIgL0NTMTQ0IDE4MyAwIFIgL0NTMTQ1IDE4MiAwIFIgDS9DUzE0NiAxNjEg MCBSIC9DUzE0NyAxNDEgMCBSIC9DUzE0OCAxMzkgMCBSIC9DUzE0OSAxNDIgMCBSIC9DUzE1MCAx NDQgMCBSIA0vQ1MxNTEgMTQzIDAgUiAvQ1MxNTIgMTMzIDAgUiAvQ1MxNTMgMTMyIDAgUiAvQ1Mx NTQgMTM3IDAgUiAvQ1MxNTUgMTM2IDAgUiANL0NTMTU2IDE0NiAwIFIgL0NTMTU3IDE1NiAwIFIg L0NTMTU4IDE1NCAwIFIgL0NTMTU5IDE1NyAwIFIgL0NTMTYwIDE1OSAwIFIgDS9DUzE2MSAxNTgg MCBSIC9DUzE2MiAxNDggMCBSIC9DUzE2MyAxNDcgMCBSIC9DUzE2NCAxNTIgMCBSIC9DUzE2NSAx NTEgMCBSIA0vQ1MxNjYgMTUzIDAgUiAvQ1MxNjcgMjIyIDAgUiAvQ1MxNjggMjIzIDAgUiAvQ1Mx NjkgMjI1IDAgUiAvQ1MxNzAgMjIwIDAgUiANL0NTMTcxIDIyNiAwIFIgL0NTMTcyIDIxNyAwIFIg L0NTMTczIDIxOSAwIFIgL0NTMTc0IDIxNiAwIFIgL0NTMTc1IDIyOCAwIFIgDS9DUzE3NiAyMjcg MCBSIC9DUzE3NyAxOTQgMCBSIC9DUzE3OCAxOTkgMCBSIC9DUzE3OSAyMDEgMCBSIC9DUzE4MCAy MDMgMCBSIA0vQ1MxODEgMjAyIDAgUiAvQ1MxODIgMjE0IDAgUiAvQ1MxODMgMTkzIDAgUiAvQ1Mx ODQgMTk3IDAgUiAvQ1MxODUgMjA1IDAgUiANL0NTMTg2IDIwOSAwIFIgL0NTMTg3IDIwOCAwIFIg L0NTMTg4IDIxMCAwIFIgL0NTMTg5IDIxMyAwIFIgL0NTMTkwIDIxMiAwIFIgDS9DUzE5MSAyMTEg MCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzIgMzA2IDAgUiAvR1MzIDMwNSAwIFIgPj4gL0ZvbnQg PDwgL1RUNCAyMDYgMCBSIC9UVDUgMjM4IDAgUiAvVFQ2IDIzNyAwIFIgL1RUNyAyNDYgMCBSID4+ IA0vWE9iamVjdCA8PCAvSW0xMzYgMzU4IDAgUiAvSW0xMzcgMzU5IDAgUiAvSW0xMzggMzYwIDAg UiAvSW0xMzkgMzYxIDAgUiAvSW0xNDAgMzYyIDAgUiANL0ltMTQxIDM2MyAwIFIgL0ltMTQyIDM2 NCAwIFIgL0ltMTQzIDM2NSAwIFIgL0ltMTQ0IDM2NiAwIFIgL0ltMTQ1IDM2NyAwIFIgDS9JbTE0 NiAzNjggMCBSIC9JbTE0NyAzNjkgMCBSIC9JbTE0OCAzNzAgMCBSIC9JbTE0OSAzNzEgMCBSIC9J bTE1MCAzNzIgMCBSIA0vSW0xNTEgMzczIDAgUiAvSW0xNTIgMzc0IDAgUiAvSW0xNTMgMzc1IDAg UiAvSW0xNTQgMzc2IDAgUiAvSW0xNTUgMzc3IDAgUiANL0ltMTU2IDM3OCAwIFIgL0ltMTU3IDM3 OSAwIFIgL0ltMTU4IDM4MCAwIFIgL0ltMTU5IDM4MSAwIFIgL0ltMTYwIDM4MiAwIFIgDS9JbTE2 MSAzODMgMCBSIC9JbTE2MiAzODQgMCBSIC9JbTE2MyAzODUgMCBSIC9JbTE2NCAzODYgMCBSIC9J bTE2NSAzODcgMCBSIA0vSW0xNjYgMzg4IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkwIDAg UiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAgMzkyIDAgUiANL0ltMTcxIDM5MyAwIFIgL0ltMTcyIDM5 NCAwIFIgL0ltMTczIDM5NSAwIFIgL0ltMTc0IDM5NiAwIFIgL0ltMTc1IDM5NyAwIFIgDS9JbTE3 NiAzOTggMCBSIC9JbTE3NyAzOTkgMCBSIC9JbTE3OCA0MDAgMCBSIC9JbTE3OSA0MDEgMCBSIC9J bTE4MCA0MDIgMCBSIA0vSW0xODEgNDAzIDAgUiAvSW0xODIgNDA0IDAgUiAvSW0xODMgNDA1IDAg UiAvSW0xODQgNDA2IDAgUiAvSW0xODUgNDA3IDAgUiANL0ltMTg2IDQwOCAwIFIgL0ltMTg3IDQw OSAwIFIgL0ltMTg4IDQxMCAwIFIgL0ltMTg5IDQxMSAwIFIgL0ltMTkwIDQxMiAwIFIgDS9JbTE5 MSA0MTMgMCBSIC9JbTE5MiA0MTQgMCBSIC9JbTE5MyA0MTUgMCBSIC9JbTE5NCA0MTYgMCBSIC9J bTE5NSA0MTcgMCBSIA0vSW0xOTYgNDE4IDAgUiAvSW0xOTcgNDE5IDAgUiAvSW0xOTggNDIwIDAg UiAvSW0xOTkgNDIxIDAgUiAvSW0yMDAgNDIyIDAgUiANL0ltMjAxIDQyMyAwIFIgL0ltMjAyIDQy NCAwIFIgL0ltMjAzIDQyNSAwIFIgL0ltMjA0IDQyNiAwIFIgL0ltMjA1IDQyNyAwIFIgDS9JbTIw NiA0MjggMCBSIC9JbTIwNyA0MjkgMCBSIC9JbTIwOCA0MzAgMCBSIC9JbTIwOSA0MzEgMCBSIC9J bTIxMCA0MzIgMCBSIA0vSW0yMTEgNDMzIDAgUiAvSW0yMTIgNDM0IDAgUiAvSW0yMTMgNDM1IDAg UiAvSW0yMTQgNDM2IDAgUiAvSW0yMTUgNDM3IDAgUiANL0ltMjE2IDQzOCAwIFIgL0ltMjE3IDQz OSAwIFIgL0ltMjE4IDQ0MCAwIFIgL0ltMjE5IDQ0MSAwIFIgL0ltMjIwIDQ0MiAwIFIgDS9JbTIy MSA0NDMgMCBSIC9JbTIyMiA0NDQgMCBSIC9JbTIyMyA0NDUgMCBSIC9JbTIyNCA0NDYgMCBSIC9J bTIyNSA0NDcgMCBSIA0vSW0yMjYgNDQ4IDAgUiAvSW0yMjcgNDQ5IDAgUiAvSW0yMjggNDUwIDAg UiAvSW0yMjkgNDUxIDAgUiAvSW0yMzAgNDUyIDAgUiANL0ltMjMxIDQ1MyAwIFIgL0ltMjMyIDQ1 NCAwIFIgL0ltMjMzIDQ1NSAwIFIgL0ltMjM0IDQ1NiAwIFIgL0ltMjM1IDQ1NyAwIFIgDS9JbTIz NiA0NTggMCBSIC9JbTIzNyA0NTkgMCBSIC9JbTIzOCA0NjAgMCBSIC9JbTIzOSA0NjEgMCBSIC9J bTI0MCA0NjIgMCBSIA0vSW0yNDEgNDYzIDAgUiAvSW0yNDIgNDY0IDAgUiAvSW0yNDMgNDY1IDAg UiAvSW0yNDQgNDY2IDAgUiAvSW0yNDUgNDY3IDAgUiANL0ltMjQ2IDQ2OCAwIFIgL0ltMjQ3IDQ2 OSAwIFIgL0ltMjQ4IDQ3MCAwIFIgL0ltMjQ5IDQ3MSAwIFIgL0ltMjUwIDQ3MiAwIFIgDS9JbTI1 MSA0NzMgMCBSIC9JbTI1MiA0NzQgMCBSIC9JbTI1MyA0NzUgMCBSIC9JbTI1NCA0NzYgMCBSIC9J bTI1NSA0NzcgMCBSIA0vSW0yNTYgNDc4IDAgUiAvSW0yNTcgNDc5IDAgUiAvSW0yNTggNDgwIDAg UiAvSW0yNTkgNDgxIDAgUiAvSW0yNjAgNDgyIDAgUiANL0ltMjYxIDQ4MyAwIFIgL0ltMjYyIDQ4 NCAwIFIgL0ltMjYzIDQ4NSAwIFIgL0ltMjY0IDQ4NiAwIFIgL0ltMjY1IDQ4NyAwIFIgDS9JbTI2 NiA0ODggMCBSIC9JbTI2NyA0ODkgMCBSIC9JbTI2OCA0OTAgMCBSIC9JbTI2OSA0OTEgMCBSIC9J bTI3MCA0OTIgMCBSIA0vSW0yNzEgNDkzIDAgUiA+PiANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9J bWFnZUMgL0ltYWdlSSBdID4+IA0vQ29udGVudHMgWyAyMzEgMCBSIDIzMyAwIFIgMjM1IDAgUiAy NDEgMCBSIDI0MyAwIFIgMjQ1IDAgUiAyNDkgMCBSIDI1MSAwIFIgXSANL0Fubm90cyBbIDEyNiAw IFIgMTI3IDAgUiAxMjggMCBSIDEyOSAwIFIgMTMwIDAgUiAxMzEgMCBSIF0gDS9NZWRpYUJveCBb IDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0vU3Ry dWN0UGFyZW50cyAwIA0+PiANZW5kb2JqDTEyNiAwIG9iag08PCANL0Rlc3QgWyAxMjUgMCBSIC9Y WVogNzcgOTQgbnVsbCBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDQ4 NSA2MTEgNDkwIDYyMSBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMCBdIA0vSCAvTyAN Pj4gDWVuZG9iag0xMjcgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9S ZWN0IFsgMTk5LjE0NzQzIDU2NC4yNDY3NyAzOTUuOTA0NjYgNTgwLjU4NzgzIF0gDS9Cb3JkZXIg WyAwIDAgMCBdIA0vSCAvSSANL0EgMzA5IDAgUiANL1N0cnVjdFBhcmVudCAxIA0+PiANZW5kb2Jq DTEyOCAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyAyMTUu ODg0ODYgNTUwLjQ0OTA0IDM3OS4yNzg2OSA1NjYuNzkwMTYgXSANL0JvcmRlciBbIDAgMCAwIF0g DS9IIC9JIA0vQSAzMTAgMCBSIA0vU3RydWN0UGFyZW50IDIgDT4+IA1lbmRvYmoNMTI5IDAgb2Jq DTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDE5OS4xNDc3MSAyNjUu MDE3NCAzOTUuOTA0OTcgMjgxLjM1ODUyIF0gDS9Cb3JkZXIgWyAwIDAgMCBdIA0vSCAvSSANL0Eg MzEyIDAgUiANL1N0cnVjdFBhcmVudCAzIA0+PiANZW5kb2JqDTEzMCAwIG9iag08PCANL1R5cGUg L0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyAxNDEuNjE3MDIgMjA5LjgyNTk3IDQ0Ni4y MzQ1NiAyMjYuMTY3MDcgXSANL0JvcmRlciBbIDAgMCAwIF0gDS9IIC9JIA0vQSAzMTEgMCBSIA0v U3RydWN0UGFyZW50IDQgDT4+IA1lbmRvYmoNMTMxIDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9T dWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDE0NS4yNzY2IDExMy4yNDIzOSA0NDkuODcwMyAxMjkuNTgz NDggXSANL0JvcmRlciBbIDAgMCAwIF0gDS9IIC9JIA0vQSAzMDggMCBSIA0vU3RydWN0UGFyZW50 IDUgDT4+IA1lbmRvYmoNMTMyIDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMjUgMzU0IDAgUiAN XQ1lbmRvYmoNMTMzIDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMjIgMzU1IDAgUiANXQ1lbmRv YmoNMTM0IDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMTkgMjY0IDAgUiANXQ1lbmRvYmoNMTM1 IDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMjYgMjcyIDAgUiANXQ1lbmRvYmoNMTM2IDAgb2Jq DVsgDS9JbmRleGVkIDE5NiAwIFIgMjkgMzQzIDAgUiANXQ1lbmRvYmoNMTM3IDAgb2JqDVsgDS9J bmRleGVkIDE5NiAwIFIgMjMgMzQ5IDAgUiANXQ1lbmRvYmoNMTM4IDAgb2JqDVsgDS9JbmRleGVk IDE5NiAwIFIgMTEgMjY1IDAgUiANXQ1lbmRvYmoNMTM5IDAgb2JqDVsgDS9JbmRleGVkIDE5NiAw IFIgNiAzNTAgMCBSIA1dDWVuZG9iag0xNDAgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMyAy NzEgMCBSIA1dDWVuZG9iag0xNDEgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiA1NiAzNTEgMCBS IA1dDWVuZG9iag0xNDIgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxNCAzNTMgMCBSIA1dDWVu ZG9iag0xNDMgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAyMyAzNTcgMCBSIA1dDWVuZG9iag0x NDQgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAyMyAzNTYgMCBSIA1dDWVuZG9iag0xNDUgMCBv YmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxNCAyODAgMCBSIA1dDWVuZG9iag0xNDYgMCBvYmoNWyAN L0luZGV4ZWQgMTk2IDAgUiAxOSAzNDIgMCBSIA1dDWVuZG9iag0xNDcgMCBvYmoNWyANL0luZGV4 ZWQgMTk2IDAgUiAxNSAzMjIgMCBSIA1dDWVuZG9iag0xNDggMCBvYmoNWyANL0luZGV4ZWQgMTk2 IDAgUiAxMyAzNDUgMCBSIA1dDWVuZG9iag0xNDkgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAy OCAyNjIgMCBSIA1dDWVuZG9iag0xNTAgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAzMiAyNTIg MCBSIA1dDWVuZG9iag0xNTEgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxNSAyOTcgMCBSIA1d DWVuZG9iag0xNTIgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxNiAyOTggMCBSIA1dDWVuZG9i ag0xNTMgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMyAyOTYgMCBSIA1dDWVuZG9iag0xNTQg MCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAyMyAzNDQgMCBSIA1dDWVuZG9iag0xNTUgMCBvYmoN WyANL0luZGV4ZWQgMTk2IDAgUiAzMCAyNjkgMCBSIA1dDWVuZG9iag0xNTYgMCBvYmoNWyANL0lu ZGV4ZWQgMTk2IDAgUiAzMCAzNDEgMCBSIA1dDWVuZG9iag0xNTcgMCBvYmoNWyANL0luZGV4ZWQg MTk2IDAgUiAyMCAzNDcgMCBSIA1dDWVuZG9iag0xNTggMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAg UiAxMyAzNDYgMCBSIA1dDWVuZG9iag0xNTkgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxNSAz NDggMCBSIA1dDWVuZG9iag0xNjAgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAyNCAyODUgMCBS IA1dDWVuZG9iag0xNjEgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAyMiAzNTIgMCBSIA1dDWVu ZG9iag0xNjIgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiA5IDMzOCAwIFIgDV0NZW5kb2JqDTE2 MyAwIG9iag1bIA0vSW5kZXhlZCAxOTYgMCBSIDEyIDI1MyAwIFIgDV0NZW5kb2JqDTE2NCAwIG9i ag1bIA0vSW5kZXhlZCAxOTYgMCBSIDExIDMzOSAwIFIgDV0NZW5kb2JqDTE2NSAwIG9iag1bIA0v SW5kZXhlZCAxOTYgMCBSIDEyIDMzNiAwIFIgDV0NZW5kb2JqDTE2NiAwIG9iag1bIA0vSW5kZXhl ZCAxOTYgMCBSIDEyIDMzNyAwIFIgDV0NZW5kb2JqDTE2NyAwIG9iag1bIA0vSW5kZXhlZCAxOTYg MCBSIDEyIDI1OCAwIFIgDV0NZW5kb2JqDTE2OCAwIG9iag1bIA0vSW5kZXhlZCAxOTYgMCBSIDYg MzM1IDAgUiANXQ1lbmRvYmoNMTY5IDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMTMgMjYzIDAg UiANXQ1lbmRvYmoNMTcwIDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMTAgMzI3IDAgUiANXQ1l bmRvYmoNMTcxIDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMTQgMjU2IDAgUiANXQ1lbmRvYmoN MTcyIDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMTAgMzM0IDAgUiANXQ1lbmRvYmoNMTczIDAg b2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMTAgMzMyIDAgUiANXQ1lbmRvYmoNMTc0IDAgb2JqDVsg DS9JbmRleGVkIDE5NiAwIFIgOSAyNjAgMCBSIA1dDWVuZG9iag0xNzUgMCBvYmoNWyANL0luZGV4 ZWQgMTk2IDAgUiAxMCAzMzMgMCBSIA1dDWVuZG9iag0xNzYgMCBvYmoNWyANL0luZGV4ZWQgMTk2 IDAgUiAxMyAyNjcgMCBSIA1dDWVuZG9iag0xNzcgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAz NyAzMjggMCBSIA1dDWVuZG9iag0xNzggMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMiAzMzAg MCBSIA1dDWVuZG9iag0xNzkgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMyAyODIgMCBSIA1d DWVuZG9iag0xODAgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxNCAyNjggMCBSIA1dDWVuZG9i ag0xODEgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMiAyNzMgMCBSIA1dDWVuZG9iag0xODIg MCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiA2MCAzNDAgMCBSIA1dDWVuZG9iag0xODMgMCBvYmoN WyANL0luZGV4ZWQgMTk2IDAgUiAxOCAyODYgMCBSIA1dDWVuZG9iag0xODQgMCBvYmoNWyANL0lu ZGV4ZWQgMTk2IDAgUiAxOCAzMjkgMCBSIA1dDWVuZG9iag0xODUgMCBvYmoNWyANL0luZGV4ZWQg MTk2IDAgUiAxMyAyODEgMCBSIA1dDWVuZG9iag0xODYgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAg UiAxMCAzMjUgMCBSIA1dDWVuZG9iag0xODcgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMSAz MzEgMCBSIA1dDWVuZG9iag0xODggMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMyAzMjQgMCBS IA1dDWVuZG9iag0xODkgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMiAzMjYgMCBSIA1dDWVu ZG9iag0xOTAgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMSAyODQgMCBSIA1dDWVuZG9iag0x OTEgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMyAzMjMgMCBSIA1dDWVuZG9iag0xOTIgMCBv YmoNWyANL0luZGV4ZWQgMTk2IDAgUiAyNCAyNzkgMCBSIA1dDWVuZG9iag0xOTMgMCBvYmoNWyAN L0luZGV4ZWQgMTk2IDAgUiAyMyAzMTUgMCBSIA1dDWVuZG9iag0xOTQgMCBvYmoNWyANL0luZGV4 ZWQgMTk2IDAgUiAxMyAyOTMgMCBSIA1dDWVuZG9iag0xOTUgMCBvYmoNL0RldmljZUdyYXkgDWVu ZG9iag0xOTYgMCBvYmoNWyANL0lDQ0Jhc2VkIDI4MyAwIFIgDV0NZW5kb2JqDTE5NyAwIG9iag1b IA0vSW5kZXhlZCAxOTYgMCBSIDI5IDMxNCAwIFIgDV0NZW5kb2JqDTE5OCAwIG9iag1bIA0vSW5k ZXhlZCAxOTYgMCBSIDEgMjc0IDAgUiANXQ1lbmRvYmoNMTk5IDAgb2JqDVsgDS9JbmRleGVkIDE5 NiAwIFIgMTQgMjk0IDAgUiANXQ1lbmRvYmoNMjAwIDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIg OSAyNTcgMCBSIA1dDWVuZG9iag0yMDEgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxNSAyOTIg MCBSIA1dDWVuZG9iag0yMDIgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxNiAzMDQgMCBSIA1d DWVuZG9iag0yMDMgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMyAyOTEgMCBSIA1dDWVuZG9i ag0yMDQgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAyIDI3NSAwIFIgDV0NZW5kb2JqDTIwNSAw IG9iag1bIA0vSW5kZXhlZCAxOTYgMCBSIDMzIDMxNyAwIFIgDV0NZW5kb2JqDTIwNiAwIG9iag08 PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RD aGFyIDI1MiANL1dpZHRocyBbIDI3OCAwIDM1NSAwIDAgMCAwIDE5MSAzMzMgMzMzIDM4OSAwIDI3 OCAzMzMgMjc4IDI3OCA1NTYgNTU2IDU1NiA1NTYgDTU1NiAwIDU1NiAwIDU1NiAwIDI3OCAwIDAg MCAwIDAgMCAwIDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiANMjc4IDUwMCA2NjcgMCA4MzMg NzIyIDc3OCA2NjcgMCA3MjIgNjY3IDYxMSA3MjIgMCA5NDQgMCAwIDAgMCAwIA0wIDAgMCAwIDU1 NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgzMyA1NTYgDTU1 NiA1NTYgMCAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCAwIDAgMCAwIDAgMCAw IDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDIyMiAzMzMgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGlu ZyANL0Jhc2VGb250IC9ER09DT0YrQXJpYWwgDS9Gb250RGVzY3JpcHRvciAyMDcgMCBSIA0+PiAN ZW5kb2JqDTIwNyAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDkwNSAN L0NhcEhlaWdodCA3MTggDS9EZXNjZW50IC0yMTEgDS9GbGFncyAzMiANL0ZvbnRCQm94IFsgLTY2 NSAtMzI1IDIwMjggMTAzNyBdIA0vRm9udE5hbWUgL0RHT0NPRitBcmlhbCANL0l0YWxpY0FuZ2xl IDAgDS9TdGVtViA5NCANL1hIZWlnaHQgNTE1IA0vRm9udEZpbGUyIDI1NSAwIFIgDT4+IA1lbmRv YmoNMjA4IDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMzEgMzIxIDAgUiANXQ1lbmRvYmoNMjA5 IDAgb2JqDVsgDS9JbmRleGVkIDE5NiAwIFIgMjkgMzIwIDAgUiANXQ1lbmRvYmoNMjEwIDAgb2Jq DVsgDS9JbmRleGVkIDE5NiAwIFIgMjcgMzE5IDAgUiANXQ1lbmRvYmoNMjExIDAgb2JqDVsgDS9J bmRleGVkIDE5NiAwIFIgNSAzMDcgMCBSIA1dDWVuZG9iag0yMTIgMCBvYmoNWyANL0luZGV4ZWQg MTk2IDAgUiAxMyAzMTMgMCBSIA1dDWVuZG9iag0yMTMgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAg UiAyMyAzMTggMCBSIA1dDWVuZG9iag0yMTQgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxOSAz MTYgMCBSIA1dDWVuZG9iag0yMTUgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAyOSAyNzAgMCBS IA1dDWVuZG9iag0yMTYgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMyAyODggMCBSIA1dDWVu ZG9iag0yMTcgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMiAyOTUgMCBSIA1dDWVuZG9iag0y MTggMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAyNSAyNzYgMCBSIA1dDWVuZG9iag0yMTkgMCBv YmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMSAyODkgMCBSIA1dDWVuZG9iag0yMjAgMCBvYmoNWyAN L0luZGV4ZWQgMTk2IDAgUiAxNiAzMDEgMCBSIA1dDWVuZG9iag0yMjEgMCBvYmoNWyANL0luZGV4 ZWQgMTk2IDAgUiAyNCAyNjYgMCBSIA1dDWVuZG9iag0yMjIgMCBvYmoNWyANL0luZGV4ZWQgMTk2 IDAgUiAxMSAyOTkgMCBSIA1dDWVuZG9iag0yMjMgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAx OCAzMDIgMCBSIA1dDWVuZG9iag0yMjQgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAyNSAyNzcg MCBSIA1dDWVuZG9iag0yMjUgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMyAzMDMgMCBSIA1d DWVuZG9iag0yMjYgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxNiAzMDAgMCBSIA1dDWVuZG9i ag0yMjcgMCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMiAyOTAgMCBSIA1dDWVuZG9iag0yMjgg MCBvYmoNWyANL0luZGV4ZWQgMTk2IDAgUiAxMyAyODcgMCBSIA1dDWVuZG9iag0yMjkgMCBvYmoN WyANL0luZGV4ZWQgMTk2IDAgUiAxNyAyNTkgMCBSIA1dDWVuZG9iag0yMzAgMCBvYmoNNzQ0IA1l bmRvYmoNMjMxIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjMwIDAgUiA+ PiANc3RyZWFtDQpIiXSUzY4TOxBG9/0UXnIX1/FPlatKQizIIMQCCZi8wCjKQK4yE25mBK/P54au jkdC2bQ6feyqr469+RRev9583H64CSm8efP2ZjtttrfWwv4JL/ovPO0fpxyOYdp8OZzuno8/Dtvz 6Xw5PhyeL8d9uBynzfvbEr4+TW9302a3o5DD7n5KMaVcwm4f/u2PCS9/hlyjici88PJcKkWl3IKw xiRUw+5herW9O53C/fkSPt1dno/743fsfH4M/+z+m97tpncfUedaev5T+lhA3zv9dVeTyJY1COVo JvOmw/IfHk/Hx8Ptt7vvB9+oLBm9v63oOPw/1Rxbpt9rp0hiFoqWyLVKkKqRsyDMByz3kGsLN+fp 8wRKouW6UFw7JRYpUwElv0tcKFkoarHmUkeKYhOeIapXkC4Q48uMdAcIBQpXUC2qiTplTnEsnHSk en8sM1VZbKEoOaWoPJUhjKZRGcOtHHXdifLCtBJbsbG+1qJwqzNUq2anilNot+hYX6OIRnt9FMW0 OFUXCh0waRmpGpM1m6nCVxQ5VaMUGYfVMtqTPiz8mbU6xU4hpCbjsNgwdqGZyqLklIvRJdA26oRU EXfvC1GZslMuBoRrrY19MTKsYjOVWV1CcjMU4SYeM8TcUVjvq3ut7hO5GSpRlWmkav+YZyqJ+pTZ zTDcAchmgPop0d5Wf6OuE7sa1tWgUQ3O0Bk7SEGWtkJuhmH4SqODOAMEtzvD2VwndjGsRUr44non MsRuiKJ0q68oF8M0EtWxPsKwqtFMYU/XiV2MnFJsqY7TIoF8hgQL4jVzn7itGJzRMo6LGEaYzhiK daFYVgy3ayo85AEss/VAcP7F3CjWFev6vrhrCAeMcJF3DE26UmwrhrurvGgNcqTUc2QcS3OlWlop zIWyvMQSYpoxRONONdcjZ9hGebSKCt6lnj88yFdYWTEciJJftAatUuIZy7J61eqK4aTj2hpyxENJ ULjgP0folwADAFYHjHgNZW5kc3RyZWFtDWVuZG9iag0yMzIgMCBvYmoNNTczIA1lbmRvYmoNMjMz IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjMyIDAgUiA+PiANc3RyZWFt DQpIiXTVO5LUMBCA4XxO4RM0/VI/chJCzkC8RXH/hJYZq20VUwQbsJ9lq39pj++/Xz9ff15ECsGY B85/MCTzYEmIwDicBciQjl9fr28/vsjGsdiAUPSdKdajnBmMkRezZg6pqE8WIEynwkBZylsl4Hze Qzl40GQEQ28sFmOEfSkHQeITIeJYKBvV/4yMN1M/mYEbSbF6EKNdzLFZfbKnPVcbYEHj8Hr/jNqs i1EzAR+pOyMlO5nqjXEzBc6UDywgsaZ3MWk2QCjpyRTMyE8mVtO7mDYzEMnnjijUTk3llcoKxDsQ rkmP2AKRGgjlqUSpWQfCAZphH5hBzPFdzO8sPcaTMQzjU7HdVAciFcgI2RXyzLEKr0x0sU5EKhGP LUcCDeaTUTSLTqSeTGMLC+s4cIVVp9CRVo/RhdTHV7b/2Fy30pxMkbWY1EGjVUh0ITUgHv7cR64M +c0waBUScmeePnYmwTPj2tA5h4t1IdWeiOtHhn0ZRCdSx0qGy2NHapChPCuuYz3ncDH7wN6LLVY7 GjfWidTZV3HamSD7yXQO4mK3RirIYfnY/2q7Zl33I9Y3Gvew884yLZ6rOXBwdYwx/Zp23hrJ+l3z 55bcmMyPvFhHohUymX9Yrd52fuTF+M7GsC2SuutUTsXGq5HsRrS2IW38X9VPvim9KxPTXTEKnYzm u16sG9E6NG5bI4vVEe2bP+2D2herE2qyEkm/s7ot+AOri7Juh8U6Ea2/kmlbWfP2eDMMmS/5V4AB ANU9hAQNZW5kc3RyZWFtDWVuZG9iag0yMzQgMCBvYmoNNTUxIA1lbmRvYmoNMjM1IDAgb2JqDTw8 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjM0IDAgUiA+PiANc3RyZWFtDQpIiYyUO66a QQxGe1bBChy/xvb0aVJmDamvouy/yTeIO49fICEqhA4e+zv27cevL+n9/vPv7fft303cKC3ujI8Q Z6+7aqNUk3uyEbO1+5+vGyhlfkUxeeL/NkqpKX78puQVpRS9x6LwjUp9QvpJqQGZu0zKXpeSdpZK kvJVyz+rFZTsaxjts7YcI/Q+qfislmGEq1TukLaQM64gdD4oJfdmE6uFKaWEvsGELNoaR98xybDn G5s93ogxuIFi5NXmG2VzQygs/OxsUeZtuiHyhjprFdzglpPSneIe7aSStLQ/MI0N2+xgYok855Fo SAtYQY82IxN/ic3OJpbwI6aLsvywIkhRZ7UiY01gQaGI5htbglhSzzxbKyrXeFBcMaOW3Cm3lBPD miAsYI2ax4xaliEWZC3tinXFTg6MOVbWyxBrVJKXrCfmsDhm2MpvsGs1o14bthwxp+x5pm0oy0/M HVP+xnTHtGVcse463FLqvGFLEsOC5iWAHbOIKYkuSWzcgOwnJuSwBJjAlmmkbo5Afyk5Bol/4tH+ oMxzqqWbI6NCnYsNrMWoxdA/pyO6HMGoGy7g+UTcekeykR1HKKcjuhyBfY5krlgreDQwqQ1bjmBD XKpOzEmGtZFF4TnVsuUIlt+snwNxinhS2MOpiC1FcEJN+qk/bMOhwNZkYtdyjt+WIgpFercrhsm3 B8aVUxFbiijOsfSLkLir42jgfVi2HIr8F2AA1p6FBg1lbmRzdHJlYW0NZW5kb2JqDTIzNiAwIG9i ag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDkwNSANL0NhcEhlaWdodCA3MTgg DS9EZXNjZW50IC0yMTEgDS9GbGFncyA5NiANL0ZvbnRCQm94IFsgLTU2MCAtMzc2IDExNTcgMTAz MSBdIA0vRm9udE5hbWUgL0RHT0VNSytBcmlhbCxCb2xkSXRhbGljIA0vSXRhbGljQW5nbGUgLTE1 IA0vU3RlbVYgMTQzLjg0OSANL0ZvbnRGaWxlMiAyNTQgMCBSIA0+PiANZW5kb2JqDTIzNyAwIG9i ag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xh c3RDaGFyIDg0IA0vV2lkdGhzIFsgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDM4OSAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgDTAgMCA3MjIgMCA3MjIgNzIyIDY2NyA2MTEg Nzc4IDAgMjc4IDAgMCAwIDgzMyA3MjIgMCAwIDAgNzIyIDAgNjExIA1dIA0vRW5jb2RpbmcgL1dp bkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9ER09FTUsrQXJpYWwsQm9sZEl0YWxpYyANL0ZvbnRE ZXNjcmlwdG9yIDIzNiAwIFIgDT4+IA1lbmRvYmoNMjM4IDAgb2JqDTw8IA0vVHlwZSAvRm9udCAN L1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTE4IA0vV2lkdGhz IFsgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDAgMCAwIDU1NiAwIDAg MCAwIDMzMyAwIDAgDTAgMCAwIDAgNzIyIDAgNzIyIDAgNjY3IDAgMCA3MjIgMjc4IDAgMCA2MTEg ODMzIDcyMiAwIDY2NyAwIDcyMiANNjY3IDYxMSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYg MCAwIDAgNTU2IDAgNjExIDAgMjc4IDAgMCAyNzggDTg4OSA2MTEgNjExIDYxMSAwIDM4OSA1NTYg MzMzIDAgNTU2IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0RHT0VK RytBcmlhbCxCb2xkIA0vRm9udERlc2NyaXB0b3IgMjM5IDAgUiANPj4gDWVuZG9iag0yMzkgMCBv YmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9DYXBIZWlnaHQgNzE4 IA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgMzIgDS9Gb250QkJveCBbIC02MjggLTM3NiAyMDM0IDEw NDggXSANL0ZvbnROYW1lIC9ER09FSkcrQXJpYWwsQm9sZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVt ViAxNDQgDS9Gb250RmlsZTIgMjYxIDAgUiANPj4gDWVuZG9iag0yNDAgMCBvYmoNNjI5IA1lbmRv YmoNMjQxIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjQwIDAgUiA+PiAN c3RyZWFtDQpIiVyVO5bbMAxFe6/CK0BA4t+nSZk1pJ6Tk/03edTMgKKOG9nWJcWHC+j149fHFH3/ /Pv6/fr3GnOSR/mb14dMqt5TnOYc+vZwYs73n4/XRdmmBrFVflEaX1T4EFBGNjflm2JiPXcKEh4T jFJlzoaioZGkyXJiSTLHRaneqNxUkPJzs6R0LmBCxSmN1cYcC/MjjVpLfWLiqd+Y8saUcuKWB5aJ 8Dwm/kxrbGxMKPD1HqLiYnJclGh6U3NTgyzHeTTFb8wGbBA2jcZkYwg/x3k0nagUy4VNv2HbD0b8 Ps6jqRD7hTHFzGpsC8JOqXOemNJQHhc2btQWhA2HnvqkHIJ4ketmth+MEOeMM0UjL+i5qOE1GtuC 8KTxsEqhvRSy98SW1Vrp9oMRossDC5pWdmGc1VpZ+1EB3yROCgpLocc8yLTaKms9yqDrI4sisZoX BCXbKWs7Cmmw6pGG4QKOuzuqfYPajUI3u+axlcGokStCQ2dWi2itRiaV21lig1CScVGq1UPA2oyE GI6vByXkI1eCmAJcXWVrM1IxkU53DV4ImnhB4jeo1cjVKI8EDTVG94AS2hPA2osoBOvnYDMUOKIu RozbJmsvMCcF4+HcCdNGwkGh/6HbN+WtRSxz49TCimqEXtQM7if01gJK65pCdwo3m63UB4XcoNYC 5cjHfEJsGHef0ChuAb21wKqcj1cDFgrxVSomN26ZvLXAuVW6sz4ThK4pPi5qBLdM3lqYoS58KoiT SqE0jlBcuKeTtxboB8YL4qCQKhvcXhTXfnt5e4HxNWQ+KNgUOBae3oxbJm8x8PJQkzOMCIrSTwrP Aei/AAMAhXyBiw1lbmRzdHJlYW0NZW5kb2JqDTI0MiAwIG9iag02NzYgDWVuZG9iag0yNDMgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyNDIgMCBSID4+IA1zdHJlYW0NCkiJ pFXLbhpBELzvV/QxiezeeT8syxKGNdkorBwYKZdcCFnbJAZjHrKcr0/vrsFgD1hJxIEBaaqrqmu6 kzSfCOOhc5d8Se4T4VBJLYFVH9TSexBOINPSgtEWleUcRpOkumVZcyvrtZP0Ek5P014774CEs7Pz Dv3VHQi4XiTnIUlDUMAhXCWcIeOuwV+fpfGotBfPBcIkeQfvw88kCy/R1RP6m6jCW9SeeTDKIbfy IKr+e1Rp0HJ9ENXsoOoG9ZiQGLMQRlCdhIfwAJyj966p1BwFkygVNcYIicIaVxfiOnyEPLRhcJm1 89bnfBBgkPXyotU/gT0s7A4Ls8WicrphIWWcBWcOmRPUe0Y9stSjikVehKxfZAFCv3VxkbchK7p5 kWX9vOhCq+hs/u9VjF6jKmbQGSF2UVtFq5vtu6E9eu317o2sCNuSB7PhdKPaxVSzWm8l1aK3ztYl no7KSfSCcTBcVTWbEh/invoYeoS2s8ikN2vaB9PCWSyEdVo2fRJ8T5+qWArrgDxCq7isC31a3T6C EMdCUZyYOIKv36RV89/fV/PrI+iW88lw+riPDY+y2RgYSWz9NDhoR78VzYtXWncaxMVTgWbUWCYA FqPpPvUxzR65sgq0oQeuTGPuzXI5O0nT8XKE4+nVHUlcjn/hajo+fliVjXT8UaZbtBocss5QKh31 0tM3RZ6eiId5mVzt2CK3WccYx8lK6ou3dZWa7FvmqP80R3BNYpQHrRXNEademLOYlaPx8Ha8WC7K yXg6nOPobrLtSgOg6b6kCUBuG4lVruKu6H90xXqk2Og1S3nwfZjokH4NqskwRdNFK9pgmsWCeDOc lc8rRTxvLEkbC+4TxVE43sAqoiaFAWEV7QCa+OQmmmozrvcg396DfwQYACeKnAINZW5kc3RyZWFt DWVuZG9iag0yNDQgMCBvYmoNNjgxIA1lbmRvYmoNMjQ1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlIC9MZW5ndGggMjQ0IDAgUiA+PiANc3RyZWFtDQpIiZyUO2/bMBSFd/+Kiy5NgJjhQyIl IMiQOAg8BAhgFV280DLtsJUlg6YSpL++V5JlW42koeDC6Xz3nPuAu7vbl8f5DJiC+/uH2ePk9nnB YXuYPCST2yQJgEGymVBCKcVfCtWP4+8DGCNxHAHFd/wyRomKOIdACRIGKJnsJlczs9fO70zuodjA zB68s6vSmzUsPg/e7A43cJ38ahCiRbC4HyEoKsdYSgfxI7fvxh2s/6wQP5dCBe7PqnTbG3g2bqfz T1IjavVaGBksEo3y8R9EAQm6unVhT8nk6QVzeYVTVtExq05GfZo8VlgumgkkI5KKeFQ27pX9koGi JOIoGUSER+GoJKd9ktM66+DUTtmfdcsRmEuEZppmagdpkWVGb0tzbF0Pl/VxL/IfhHFKZEzlqCk+ aKodUSb4OIZKEsWNpQ/zfQ2Z/W3AF6DzvCjz1OAHyn1a7Gy+hXnyCIu9Sa2uCpp2loEN7ILgjDCp gg4qw+GHhUFRTHHJuZjn3rjceEic3mxsCk/51ubGuOmZdNoJFY56ErEgNA6DmlSVrfP1SfdF53pr 6iVcXs1fOXZ9ef2NQPJm4GDOsKiFSTHgi+FES/UPrnH0YbMMVq5iO3PoccAHHOC+ESkY74riqKVv uNa1kb3TqbfT8xoTGrGBGttAVExwAaNazNsir7RsDh49a2d0dStODfDHoL5WrYZy51IRGkreBZlj B9sOtMK7cwd8sTVYhKsG7tIQ5eNTK2RIwnr0kLPHiGsxdLMrcK7K/dQX07X2pkq/zPzZSngCqAEr ISPVdeoQmuB1+mbNe134Kb2NNdmaDK2n+M/dF1iEqmdkZPeD4YMmjy5FNcVjHKFITIPmcDYLcDG/ G6N96QzwCJw9R9heS64GriXnEqMT7FL+rwADAF6CyKUNZW5kc3RyZWFtDWVuZG9iag0yNDYgMCBv YmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9M YXN0Q2hhciAzMiANL1dpZHRocyBbIDI1MCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyAN L0Jhc2VGb250IC9ER09GT0UrVGltZXNOZXdSb21hbiANL0ZvbnREZXNjcmlwdG9yIDI0NyAwIFIg DT4+IA1lbmRvYmoNMjQ3IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQg ODkxIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTYgDS9GbGFncyAzNCANL0ZvbnRCQm94IFsg LTU2OCAtMzA3IDIwMjggMTAwNyBdIA0vRm9udE5hbWUgL0RHT0ZPRStUaW1lc05ld1JvbWFuIA0v SXRhbGljQW5nbGUgMCANL1N0ZW1WIDAgDS9Gb250RmlsZTIgMjc4IDAgUiANPj4gDWVuZG9iag0y NDggMCBvYmoNNjk5IA1lbmRvYmoNMjQ5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9M ZW5ndGggMjQ4IDAgUiA+PiANc3RyZWFtDQpIiZxVS2+cMBC+8yvmmEpdr20MxlGUQx6VcogUNRx7 8bJm1w1rVoYNTX99x+yTZkPVCAlx+l7zzRBdLGpfb5rqDbx5taYzcyhq13o727S2ds1X0PBi3lzd GmjWxhRLKH29gi/5z2hCCaVUQl4AJSyWCvIOGCNKZUDx2X1KSjKuIOaCMCpjyFfRRe0M1CW0SwOV 0XPrFmB+rY1vG7AOHp6gNZVpvQ40AVsk57F5JghncTJEL0tbgHEL64zxiI0m3ByNLO1iOfHavaDL tXamChqOTsTOCU/ScSeMkpiqtOeybr5pWv920B+ovGmM9sXS+IZAjibX/kij9jQx+8CUQlOKZUOi euH1ah9aV/uXZlmvobNVBTOcTV070K/aVpMjU7JlopTLUUNcpSRhvKfRswpH43qWxqys0/4H57yB zswa2xoCfWL3eXT/eBtNn+Dqavp4+3AHPIHr65u72+gmj6Z5LgDdlRHtJYyzZ5xIJkRPPwB/xiEd 8dMdfkCgRFIO0BTuL7pgmwXO93RMKcKElIiUEcVS2RMu23Z9OZ3atiDWlbVf6da+kI2zk25j/O/Z xi/I3ExPZG1xcEypJClWhWF6GSaMmSucfFQOUpGnqs8pPi82VglRsmcJYpPsfTonJNm56D8IPMPE k4QwlvFRTDXATE7yjfe1YmMbH3gEIzEPNUSe522ZMKGFxYXR4bxc9uRHydva8kNtxXl8hguiBOof EOgBNIRZhlff5IcnHnAPa2Ob7bL0bdft5UeljumnSh28c0kSjimOtxpvwL9bPRmtNWaQMmw1i4nk SXza6q7rCDYbD3dhdYXZ7DaaFPVq+v0krW8YFlnPy9OaH3A5ESleWCpIisbO1jzmn6u5ECleuFTs 1bOxSsbxf9Rc9fuuuExGIcU5yMHvAHsz/jtgWYrHXIUN/SPAAAhvyecNZW5kc3RyZWFtDWVuZG9i ag0yNTAgMCBvYmoNNzAyIA1lbmRvYmoNMjUxIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMjUwIDAgUiA+PiANc3RyZWFtDQpIiZxUW0/bMBR+z684j2wCx46d2EYIiQLamNQN bZl4YDyY1G3NmqRKDB38+p1curYiRRN9qNy0/a7nODhI5xYm1kwWrrAwLSuwplo8Q2VnrvaV8a4s wNXw5RG/jqJDiCiNCHxIH4LLNLgcnwfhNZychOPzqwvgMZyeji7Og1EahGkqgEE6DSikGeDbChgj Wis80/VRUqIiDUxGhPMogjQPDvaBJzvgcQ9OKKWsZcBTxN6miRWJuUhams+ltwv0WdvqqbV53BJv dB+12NE/bDGMzWRCIs7iXXSzjdzkmrfhmiwr87yctI9rcAXc/OJSVC/3j9Wsydk8Gbcw9wvbiml4 mVgroOptd0IQyWVH749hX47yvSVxSjTX/HVJP5am2OCrHr9BoERiglBnxS5dly1vSAcSFTGJZJLg Z0mYYJ2luffL4zBcrVbE+axe2syZBc5obXNXmKrRs9XYa1ROsZ5Ei11Ugn2E7Sh83/RFlpPplr9O j8Q/xkQphkiCJBgI0mmsOZjuxKu37Q9Yp8PyhNBE01it5Q3swlnl3dRkHkbjdXuyw2RonCne4fXn vjWdEK76oYQ3Xw3VEBATCREs+W+kQckYT/q8tBBemxnW1W5FeOa9yeZ2ArfhqPS+zOEuHI3KP3CL 4mOJ4hWuloAIg6dxDFqTCNfhrgt4bVARnWC2ghMtk6YUobpW3hEawhNF412ve0dd0KFVwrSk0i1s f+yVKk2kiru5+zi8nIINIR5t3T9DTXPChYpBNdqTuBP9ULrC40VeVjNTuBcMeeX8HDxe97yawM/C Pdmqdh5/MV1fNWgcZ7Nj0/vYogTdYNA7bDePtrvDwqv0E9yU1e96Xi4BS766hq/Wr/AJjE1hZja3 hT+EzbqyDSff67AJsAmyd9pwXi9MUbhidgimmMC3pXe5q7vB2sr2rwADAHmKoy4NZW5kc3RyZWFt DWVuZG9iag0yNTIgMCBvYmoNPDwgL0xlbmd0aCAxMTQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIkAYwCc/wAAAAAAzMXF8wEBzAgIzRwc0TY21kpK2lFR21JS21RU3AMDAxYW0ExM 28wAAAMDzAoKzhcX0Coq00dH2Wpq4Gxs4FVV3T8/1yws1B0d0RkZ0Ssr1EBA2HBw4Tk51xAQzwIC zAIMADbEJn8KZW5kc3RyZWFtDWVuZG9iag0yNTMgMCBvYmoNPDwgL0xlbmd0aCA0MCA+PiANc3Ry ZWFtDQoAAAAAAMzFxfMEBMwZGdFUVNzMAAABAQEJCc0sLNRubuFQUNwWFs8KZW5kc3RyZWFtDWVu ZG9iag0yNTQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA5OTg5IC9MZW5n dGgxIDE5MjE2ID4+IA1zdHJlYW0NCkiJXFYLdI1XFv72Oee/94YkEkJeyh9XQuXGI0XjlYTkhnpG UIml3EsSCQlRmRC1qmipW1QxM96rxmO1DP5IWYSSlGIs6q1eNdrKjI7HQj3WaNx/9r06hrln/fff 5+x9zv72Pnt/94IABOEDSGQOGtIucczl7JlA3495deDYYnfJ2kF564HeLoBKx5aV6gPqcpey7ipg WZ1fMq54+LSAIYB1GqBNGFdUnj9+b+xfgFZHgVBRkOfOrVn2y1A+7yLv6VzAC4FZts+BwBs8b1lQ XDotNe5hHQOwAcGeoklj3eiWUAYkHef5smL3tJKAqKD9vL+A7fWJ7uK8DsNuxQB9HjKeySWTppSa LPH8nE9f8m5eyfdrx14Copexj45aFaL9zyZEqzhEA2btfx/vBLPWp/MWmbXin3xa0+fP75/puECt KAKPqCG202s4hq9wkdpgBk5QLpogHHWiJXTSYEEEhmIzjpEVOag0f8EXGI7bivAZrpMDb+M4BXN2 h2ENBlJjcwtukTCv8wldkYnFFKaVaRdpNjSS4iOzHYJ45xyEIRmrcZZmBOw0z+NNfK36m/exnCJE GwSjBP/APcaXIJLEO2Yx3JiJGrLING2p6cBE1Mm55npGYsUQ9jsa7+PP7DWZqsV2LRdNkYI+6It3 UIxN2CrytXsgCMShiLEfwU3aSlfkTflvZVOj1AIt1pvCPlvgDSRxZKMxBlOwAMuxn0DNKYtWaInP ZnFOdD6hA9t8gNmYj0rWBlMoNaa3aY14X5wUd9WX2kXzJFt1RBljmoMafItbeEAWakvtaTbtodOC RLl4KnUT5j60Rm9kYSSmYhYWYwV2YB9ns0YMkGlyqjTULfWb9xACMYIxvYdK/A3n+d4aUlMRJ27L GPmRXC+Py0ccSSM1h22vcxTtGWN/HkM4/il8z/OwCOuwBbtQxXhO4TSuoJZRJ9EEmkFraS89pqci RrQQ3cUk8UdhiCrxk2wiB8uhcrL8k1wpD8uzKlT1Uv3UGrVLXbYkWG5a3d6N3p/NgWa2OctcYu41 vzHPmncRwJ3WAnY4UMi5nsxxzeRMbsN+HkfxPS7hMndWLVcdKJCiqRP1pSE0jIroXVpEn9IyWk7f 0neinggVjcUgkSnGibniqDgpu8hucrdqrRKVU41QE1Spmqsl8higLdC+0DZrW7R7Wp2loWWzDbbj z9o8u+Yt8JZ5fzDrmcFmM7O9WWg+goZmfHtujOOcrOKcbODq+CuqcQjHOSvnGN1V/IBr+Dsj/BV1 FEZNKIJHNDm4tgbSeJpGs/gWl9MqWk+7aDfto4N0gk7RaTpDF+lH+on+RXfpnpAiUjQXdhEvRosC MZPHXLFUrBArxTGuk5PilLggboo7MkS2kO1kEo/usqfsJT1yizylGqtwzvYg9Qc1nTO+SVWrGnVa /axBC9EaaS01h9ZP+0Sr1o74Yw62RFjiLBMtcywfWjZadluVtYm1s3W2db51lXWd9ZwtzGa3fW7b y1G0pkiKwksfyqbD2C77Uw7No6EURB7KQZiIxzo1WfRVq8Wnoo3Y4rO0dFGG7y2/xCJJooFaLD+j ZdhJhG74kJIxlZbwTR+mEq4uB1bKA9IrMohpgTZQEh7Lk8xJ5zlbHakD9UZfcVR9px0ZOU+0FKPo khplCVCHsVTsVS7VSRHntpxp+2O5EJ1xV06RN7gritVi7sgZpNBDdMNDfl/gGgqhWNEWKfSWjKRM mU9RHKdv73lmiUJRIVJwiJaJCbI1vUeJeAQvKrWDWKFlqfPmQLXT1Hlluj8Zm/kcjpEWSJd63Rzu fULzZISokXGiBz1QblHo3UaDqKOolR1oiiil36iSWnMFHRMDRE+KEhu49h/hNtdQHe5jh1oqF5rX 5BbvYLEPLbWROMOMZsFgUUW/4izz6X6uChtz7lbVGTvlRNyTLrFbPKMn4gnWYhuz8HbRiq6IVNyx jFbXqXZSMDWT+cxpAhuZlcfIu+hp/ojmVGqeNA9QNPdLFfPSfe2gmIQlzBf7mVHeZx5zczUXIZDK uQOCeVRy7T9gfgjn69GYQydyn65kvqxivjjPrHGT9VfxmHt3Ba4IQqZlNSO/h284vqdkwx4k8m9G MPfSDfOxOsO5+wrzJeGgtZElWc3F19oBa3Jqz9SU5B7du3XtkvRm504d30js0L5d2wRHfJvXW7eK i21pbxGjN2/2WtPoqMiI8CaNwxo1DA1pEBwUWL9egM1q0ZRkvw6nPcOlG3EuQ8XZ+/RJ8M3tbl5w v7TgMnReynjVxtBdfjP9VctUtsz/P8vU55apLywpRO+O7gkO3WnXjRPpdn03jRiczfLCdHuObtzx ywP8sorzT4J4EhPDO3RnREG6bpBLdxoZZQUepyudz6uoXy/NnpZXL8GBinr1WazPkhFuL6mg8GTy CyLc2bVCwBbEqIwoe7rTiLSn+yAYMtbpzjUyB2c706NjYnISHAaljbWPMWDvZTSI95sgze/GsKQZ Vr8bvdAXDj7RKxzVngW7QzDGFR+Ya891j8w2pDvH5yM0nv2mG+HTb0T8b8qHN0zLnveyNlp6nBGF um/q8czTjerB2S9rY3zfOTl8Bu8VsRkuTwa7XuDLYkQ7BuKD7wvleVB5dqdvxTVeNwLsvewFnvEu vpAoj4Gs8pgdUVGpe/hvQ5RT9wzNtscYKdH2HHd604oweLLKKyNT9chXNQmOipDQ59msCG7wuxAY 9LKQ90Lnl/zmPqlf1ot0kg+R/a3/sF4tQFFeV/j8r13wEbcqNC21XdgSW1e7CFURoywiuIAKojIs sXV9m9BWUzpGjSPm0dAsMaG12phojZ3Y2DWmG9ammDSKtjPWGE07usq0TPDRpOpKdRK1GYP8/c79 /39ZMA/bKfD959xz7rn33HvPPeeCMAg7FzrhSbULC8nlz+JcCi7MRTf8+CVYhRfhGO4PJxcGgo48 lrN9WMt0uJzB64Rjd3Ve7i2Zb0psmY7rxCwHRzzAoLf4sNsdHjGC48JeiIOEj5NEe8yokStb5CrX CocTBNtHFdUw8+d5sOfp6XyqjS1eWoBGeP3MaqPtpAVpzeT1uP1hOcCaVkuTMoc16y1N3DzgQvju JX4qp4ST7on/DXKkDilalheWUj9DvdjQl81ylc2sqXYWBQPm3pbN7tUy9LlxnclJhgIbHlYzsVMl LkRcZU01C/CnZRa7iu4P+HDD4GN4SGG1kib7DU5OU8RQCNu58ZG5UT2Ax1IzbSLsF4UVhK0QSM7i sCPgM77+funpn2rTYk9KMGrRr7KVID1m5pLCee7e7Qm92r28GxBU4K96j1w2uyYY7NdLV4wcFQwW u5zFwUBwfou+foHL6XAF9+ExWBhcURSwTr9Ff70xLVz8lB+LWCbljSI+Gfuk7hlUmOz++Ilbi5ML KB15PeFH2WETx0ckjzcRonXKUcmj1tECoMY+jF7XDlNI+qc0FroGOaQHlGF0RH2ZdqJ/CmTloDXy eP0l9H8c+BBYCywDcoFHgV8DJ4EGbsOmCZiFMX7L4wh6nrrsx+jH2mH9IuarBA4Bfq2KZkNXYRtP v+M25pqKMSaAnwn5XBvGAT8X+gj6zhL0MNWAXwf9DfBvgL9g30BXtSr9EPgY5DmYfyjGegHreRrz n1br9E45JA3G2HOhLwV9GHQ16EPo+wPwXqAKNpVYqxPy6eArsD8lLAfWquf166BrsD+ToR8Fu+fQ bgK/BX5txBwnwA9UiTLQp0qeSGFlmF6J+Z/EujvNtbOPs+Nrgv/Cp96YYtI17F8iDP960OPbbWjq hTrao+TQWdBVwAhgpHxMnFsN9D7tPZwFkETSN7BPq7C2Peoi2plE+n74uV3bSxfQfjSOOhqtbtX3 KtdoGXRv2Tbj9bgI8TUauEG75Mv0c1smNWD/8jH+94BxGPNuEQ+LcOZ1+mXQ5ep78L+OdgHfSiLa b+yRfpH3Bu0NOFesW+8CTypiGbBj3R3ALfYD8z/Je87nLlV1K+B5njV8/pjzIeBHsO9G/40czzgb O8ZqxBwfGOeA+ZgCHHuJYB8siDgzIfY+RHUyv+ZC9ArvFfZsBvBt8HcBU4B64Azm/yr6TxTxipjh 2OT44NjAWGV8ViJmjTXMQox1mnfmTdjHgF3AVtvL9ArwNvA81nOV7wvHLPtpjc2xxXFtURHftfSU HJIdvE6OqR6K847RavZB3EHElkX53nHsM1XcNB3Ur0RpGscsx5tFeV+E/7iPfCfitGetN+D7T5jC fpuIdcSiRa29iNOz5Bf7jf8w1BuI4XPIVSepWiuntUoR7dB2QFaL/YlC7qbVSVEairMsh+2WPvRZ hj0qPYC5oupu7CfmF/salTPUqKRpu3HuJB3RdsvrBH8b7Qup1dAxZSTq/lv5/wL5lLabloC/pEV1 Hev5Gd8Je0zKApwWhbwZWA+MSHJLzybVSi32OeSwEV0DlqteytO8NE5txb1MQc4jyoR8jm2yyLvz MMcsKSaNVaKSx55CG9R0ms9zyacQEwCPD7oiIY56xVzfWLKoFa99KcehGVN+M/9ONXNbXzoI+DLX Bs7Poj4gRwOVRrzqjfH4PEILQSut+Owdp/rphPg8hvgc2Tcu+1KuLZzfrXvKd8NaP+dHznGcIznP cQ6w+velPfYS16dfiDx8jGrMu70NCAE/hG4Y6tYfjTysx7h22KJUZ8+nOuUI1dkO0lL7g/S47TAt xbo74jV1nv6qWU9zrFrK+4S6+KpVR7XJ9EWRz/bTfSLf7KPhoo7CN66fth10wZZPg828EuN7yHcQ fWaLevMG/P63fg2+/1K5QrUsV1fSJqFrEHn9ffWE/hHXRGULrRC1qE0/r06memG7Xf+OzYN6uYce i4/HfUBZxv7bU6Uk9SL8axU1f52Vj/nskw7qJ5OqkCdO0g31JnJYLW3VDoLyHoREPFYK28P6EjFW rX5O+zpyF/cB1Bhovf43cz9EvhG6KtE+JPYCY2IP9oj3RBT7GpKS7VHy2y+if5TacO8gA1ppM/uC +3hK1OtreB9FURuL8D74wKjd2j/0t3HPvhKvw3ch59/UjyP3VqCvz6zV5eJtgfsj3huIEftQrrH6 Cc2N/Bmio5A32R9GTO6iRvhQifs7VX2Aymwx8K/pbWberlIOYsxH6DHxPom/E3Sn/aB+HPFjvBfY B36nsD/PIbf/gXKxpmnJbqylmXYg/hoRdx3AvwzQIcAL5AMlBuQB0P0VMcq1druyUfKA3ywvpq1y SB0IGfR4R/6G7lOfpxnKS9RPXYJ6eImelj3UoMzAGXdSg6bQGbRj6ki6pHSi30d0BX41aP1oGeRZ SireJxfwfvRTf6z5lNpMyxWdLqt3Y/2byA27mNZCZ7WFqCHfpSwgxpDHUpuaTG22RrxpMR+PDxzC +OkMdTVlC7sECF8tsM+/SvB5E61SHkHeY383Yd8S/GVf43620jn28ZP8E37wuLATff5OG4j0diDT oN0zE2jqHaA9gTqZ8huc64Itgrieh9y3Cm+W16gJY35I1IV+t3hOvNRubYNsLvgJQDb4DMgeBP0p +p0GXwv5ceBPkE1W06jAzFO70O6Gvg00BPp99PkCKPp2/Z7o4ysGbrnRLgBcwFJAgbwRNNeg3e/D rgTUZ+i6mmFzAHjLRKoh65oCzIDNE5AVARPRrgNqObZvf9f8n+mn1LM7pT31S7/J6FuT7pha5/k5 tG/tss7/82jCG7Q3NffBWkdCLf3MmmlRhGK++Uv7yKtMj3hysr0tyvTmSTlMIkUlRrNCNJtrDLI4 Zz0r09KEMjJ4qEH7D8weVJCiTKd64AqgUD6+5cAzgA6oNMjUy8q0iJTxtcCbShnaZSRj+pJIYWF2 /QGlBBmrhDoARUizhFMlkTFjDOoZbdDhww2akYmJB6B7PlAPvGOaa8I8eUi2pyBdKYWqFPM8g+8B 4B2gA7gCaPCrlDxAORAAtselHcLKq5RGvpnH85WaCy6N9HdkVxQ4FB8G9sHAB3f5K8HEh2F9wswX SXZkD96nt8rtzd6CbIMZf69g3o3cW5B9suBL8rswypLbkcXbqQIIAH8BzgBXATv+b2unJuAFIIwR 1HFNBRnyUdg1yX/G1yt4r+CzBJ8leKfgnWafnSQBK2HzIkZ68T+sVn9sE9cdf+/d2XfnOPHZSZwz tvNsEnLmvCb8chKEQ16cZBsxJUAgxNAodAwha6MNJNBRdWU/1DGkrfXaaW2Z1qBtSBH5I5dLmzhh W6K1mtpuSBXrpG3SBn+kk2BC6ySgogVl37vnFCbxx/7Y2Z/3ee/7Pvfu6+89v+8XEfJLtmbomvua RBbcCxKZdE9KZMw9JpFed69EfG5fyebrGBQyEKAMBCgDvzLjvMoMRDyDhgCTgEXAMsCNmuCAPw0g UBY2IwqwLe2AXsBLgDHAAkBGk9BiR7eiGSrdvQxwI5WkYJRy1kqBJgWBSUGkbRt2ZtsBvbZN6IFP RsiQFvg0wydFUhDlP1jxTU64f7/SeX+l895K5127U1xenD66Ku3w9VUpewIfsKBjG54r8ckSHyxx I2fL2LTRoY2cNnBaz2kdpyZOBqe1nBKc4pxqOAU5VXOq4lTJKcCpnJOXU5lN00bJGZ07o3NndO6M zp3RuTM6d0bnzujcGZ07o3NndO6Mzp3RuTM6d0bnzujcGZ07o3NndO6MXopQ3GZ4C/UpWoR34ND7 nN7j9C4rAz5an6bX7TE+wCjwc4CTgIOARoAB0AFxWyO0Wy+uBdo6HaujQx2K0AalRxv8E9vgD96G RGHzdCxOKZxHrbBtW2GjtsLWbYVtOwbtJGABIHw+R4TUDKz7Unsanh+aAVc+cVyZdjzEE5z6Oe3l FGY7gD8F3ABcATwDeAqwD7Ad0AloA6QALRgFruGPMQkM42/hAhYwRgom8BeoqYGDOOCX2SUCaRUp 5KyVr4T137ISR+AX4DdRQsSI4mk85LCJ8g5PIB2vAb4I3A/8c8t4A24bg90H9DPYYUCHrUQU6KtW IgZ0yEqsA3rSSnTYcbb0N2iHgvchXbYX7EcGPge81zLOwvQeTn2W0QlE+Qq1VuIV2lGGoyhPJkAb RrrDIWSQCYt+qhdFbNG7epFMzNBPjF56wyjKeIZeN07RPyWKBDMf/bDxMr0Sv0zfTjTR3+ZBycro Yv4y/Q3Ip+qdBc4ZEG0wv2600h8ZsBkawQzjZ+DWk8YEHYal4HFPU0f9VLyIz8HsUf0Vetj4Nj2o w3iGDhkG3ddYxGssuhseA8LtMOqfoVl4+LbSg79kJGkXPLzT9tOiHQlnRQYrYBambfElugV8aGm8 RFPGFrq+cYnWGd10dR4WmqV7y5VypaVQxHWsWSr8TSoclwp7pcImqdAkFZJSoUEqrJEKtVIhKlXJ AVmVK2Sv7JFl2S2LMpGRXFVcvsa+gOAoq3KrNrlFuxWdvkrsFhpoEcEyQT0oYFYKWZLty5ityWxR Wt5ttiSzprzzwMAUxi/mbKu5eAhlvxIz7/TVFbFn137TVZfBZiCLsnsymkm+X8RozwDscvuGF8Jm oHNgDmEceuGH4RLncp0D83BGBxEeyaHgyXatPbDVv/mLXY9oDpba5INLe6ifzO48NQfbY3xaos0S DPtgWLCHBXuoRc2fZPsGzIvRnLnB7ixHc1nzbF/siYE5opFgd9ccqbEpNzAnThOte7dtF6e7crks vGJHB9lNAx2qtwl0FTKK2ToUq5AdHZngOkpqbF3CJtBpFxB1dFS74OhEbOum8rHurqlYzNFAeZx3 NPk69JBmDg+helDV13PVeTxkq/BQ3XlbZSadhXQdJI26I8ERpDsL6TjiSFIPJPGSZOhzyZAj+cED icElwsUViXARJMn/w3U4053vy+DszoEpGWVynU9wDqrDW52dUR7aeiE8j64I/0RlyZzpqcuYZXWQ +Nu1pJrGTYNwg3Ua48Gc0/uX3XN7TTfIJIC9wpa49nx4XkR43FnBC+by0tRjHY912FOw5+2pCjD7 SlPa81vi4Xk8XppSweyH5z7qJ4yMjCZHHjY8UvW/XUjrznfxr1YCLH/CwejIqH2NdHfBdxRlTaMv a7bu2j8wJUndJjvYlQNb44pNEBzblKIAP9mVGyldydETo/AgiBZbz6BqYFAyMKgXGBQLDCoFBmUC gwTOIHszSN0M8jaDpM0gY5/v8Dj13Hmnnhtz+mOQPjdiBlUFg5KCQUJnkM0ZlAkMsjOD+oJBWmdQ YDAjChW07jTxjf8VJMexh64cSsIvtidGgfjUiSQeWTGXgkXgXIIy2YUgk0oo/SbBs26pSG4zDbnE WQF5JHEWo5Dsds0SwVQW/g6b5k76fnqHeiv9+P00aoe+eg+a9evi/rh/DTRw9qF7MWHxHnOhz1BM XLQPv4igkX+7/ohqcRnL7/f+1Et8Ub+nqqy60l/lr+6NShUsXrdJLQ9URHxU1b31Pl01/IlIQ23K 21LR4kv7N0eaa5+NfE87G/px2cvescqxqtdCf9b+Erkh3I1EFDWkrlW78LZQT7gn8qz3rvduuUdz zWMV+clnM16v4gl/DRdxrxXpRr/GSVSBggKFRD1uVXd7ioLKVF9FtAK7vP6oVuGTgkoE8i9TxsLL YRIeDyJ7FCnYyR+PK9XjahAHf+cZR4qqECVEJ09oSYjI4ONL9weXgG/a8AdqNqP2JjV9a+neR+r9 pVv/8Ac2N31khwofG0yiQXy8Um9uaW5p0Bv0lmBNQ2pjlWSPa9xSTbBG0t23X/3yDiqHTu4Nb/nu Ec0KV2X2b089/fI36qtfP9MmaCd29dTKYrTaY6bYL45se1uma6NvhbQza1cdvvp1RJavw5s95JqH 9+pBt9meqwpmXhzzDnv/Knwoir3eU+KC9wPvx15Xg2CICaVf6Pe8Jr7qkRQFebehrLtHZl43khUJ exSFuNzu1ZJSJUmKKAiriVJFiKIUSc4SZY9dAFZA5hFcInFLEhFkd5F8h5XFpNMS2SldlYh0CVcj BQkkxzyUNJFhco2IpEhmmA8pTBlWPlBEHs1f4Q2ojFhkFmnJEMTx2J1B7abT0W7Cdkur6fY0xNHe dzfPuBqT31TfOdOo2SSp6fSZd3h4B4/h4+gYjgtxHP8P21UD29R5Rb/7/bwfvxf7xXFw7JHYTiAJ DSRZ/o3S5Y2GpMAgrgYL6fDIpNGxiZU5a9EGbVM6GIWuS1pp/LXUbCqUdVsJhNDEBRG1K2HQ0kza mFpVCkMRsI1ApAWQAL/sPjsbUGo5+ZxrW9E599zznZsVYgy4J/lej3WaPQwtV60L31pmvQGN1jGR uNVE6+iS5GHU6PuTF8VN1OhXyGGztIW0gOk0XVz2er0laomjxPOoaHE1exbmtNHH2eP6djUDB8PZ 4lrpoq4E/JG46RnTobEy0kBMnCa75MPSXK6S4rVwAmgLrIQ4psaNrmLiNJzUecbMhfO5EMw1cyO5 7bk8d1qxKUfkdhln0UDO+unu3unhCnvkorExIxbtQFlNRKPIQ3I02pCciIZRUog3imISEikIkswq 94zKCu4VhYUF+RLN9kyrrKjh66G8zXr9mvUf6y9nYPVfr0Kh3xrJ2drx7Kcv/O65pz+gRulN6zY0 QtUtiH8++fn053+y0zr+m57BnRhd2lBFH6GKMkmAvGbmb86BWlLtXuRtdbcGEtkD3tPZp6epAbc7 QMCDk57lRjEcySRKXmot8FOcGGL4ionDcFCH3wxBMAQnsCuBY/RV5GwGLrSNZuYgGSa0HImLIHX1 QeLtp28fQuQp6KPJ0SVGNNZxI7p4DO+slOnYP1PtTxNQCaEKbx7P9lBZkqWCIsRdW+OursLpKiho g0p4aV/pt7ueXlbat/UH+7/zwf5d+3/9tbb1qxZWbT4oEkKtW/WrgSfHrFfWLC2edmVW3WPgfPf1 PX637V1LkYEPkQGNXDZLWtU4i8txjdeoJjVZK+cKBB1BrZZwoaicq+oUEZKw8btkpUxpUXqUQYyL KuM2OUiJAyfn1FGNYGg35ASdRyTcumqqJfulRuf1mY52ZCuBDDE6z8yKIIfUwLGJUB7Hr/szuM2e +uXs6Wn21tzL3o1otGPx6ER0dKJk9F4KM8PRsrtMyvX29ESjNpkyzk7qZylU8IbKO9ea6M3KpLqC LasSietW73Wr47rNTgTZ2YzsqKTP9CnQyluVv6tcEVz9Ahd9sjLFgOlADGoafD+dd3RYgh4JEPwj Kbie7jTcQcqoP6hBRAONH8Meq7Tty/A6iDdB38Z/dL9cbqQRx6bwptE+CPYu1AhUclqVnL2QnqxM zn3BRrn3erIbMfZNXpIWoDOEYCmGUmxVVjjUPzloxrLCPlashdkCtlzbkrcj7828vQH1BO3NozIF iUrMAIMazOs38oyAEZxNizJK82YF5kp1rjojHIjACtcKIw7xvDcC8eCb5C36e36OngvcgrzMbHcw EMingD4LgSAV04MHcWps9jQIpnjHdXR6PzqMKtSVbsCn2/acbLviZDS/GKiBn59nZpMWAhESJyNk Eu9mX+BMVxCC/XRGX4R04Xjan8l1F5uZQDLByITMfQW+YlONqO0qS3syGtHRfIzx+Y7wAH0nxXP9 lCldR6tFT0pGJ1BKsbLR1DuDKYOKNSRteUXrk9F69Cl3eIuztEQg82TKtSBGYlFMMWjTEi8IFhVm VtXWkAfsq7Y2xDbR7k1PWQcPWuOvnFz2BPzUsqCywro0c9+zr05sO/Db7360cI61jbmSLy1aveEA NJz70xXgVy4En3lup/X+sYFDtYWf2VptxiXsLdQqI8MDREwO9j7SXCWwkb0NZvqsfzh9Vlalz7Ly 1Gl+vWhOVbcABTc4U7TSiGgXnWKvGKKX6HkxLnRDrBRx0SOGhTAFUMamhI86Zymd0+O00b79SDCl 4OCPSTfZS3oIt1XcTphB4DyBdqxR8g9+3wCj8XX4Rv3JlI5zbCHf9b0OvBPSSQ5lDM3ocnOss/al ZqP9JiGyjGh1uG1ecEqqrCrzyXzW5HhSWSdtJttgkzSu6uVO0znsZC5Z1YvobH2h3KR3yt3yCV31 qX494CwkD6mz9aBTZhrTL5J/KZf1cackEQ1cVBGqLCnMIX9IPlGGHCe1U7rY4XhNP0LeU/rUd3Xp Rccv9T0S+qWyS5U2qM/oXdLLcpeyVZVW6+3On5FOqVPeoEgLlGZ9ubpcXyutkaWwWqe3SN+QuU6f UGQ5RHRkEgOcI1/TPZqmC87zGfUwhoPBdI0ywyUH8LY8TjdhltXpC+gTjUecXq8fc8lGs3ilNqLR Tm1Soy4NrtlnXIMuDToRgbbWrga0Fo1pCTiMrB02pzXgPT0CzAWdQDUIQBdMAofj+DYjItXGjWZZ Fz/BJzkr5yaP8LW8k8e5xH0Zmpd5MzK4rmdQhQqqoWK4Urc+pwT3LXzYCRCfJam0GFs8NmoPUYeF TbYfsVhHcsn8VY0XF0+MGWNR7DcuaPiVLfemnC0cT5Fu/7oyXxks6tEeW97rVDO4/fk2iP7/YUfM WAjTjx2CUB8hYHHrQvU/rXGogHfmwAT0Wh9bYxDif75dKxK3k5zdakrn9RWESH7b1WHI3AeyH8Me oVTHbOiHbOoVfllxz6bfoz+Ut9Pd8lV5XJZHKMwks6AY81QzWyBFtNXwfbaOrpd/QV+Ud5BdsJ3u FLvlA2Q//4N8QDmgHiMD8oCSUIfIKRhiQ/y0OCl9Bv+WbpIb9I5c+LwGKiH5oHgAFAkzJxcezoW8 h9A9QlVwJaGYRIEoCghuYEI/bD4EZqQazEcXVIFZX90Fn6T7WIYNZfZrSjCAjaTa2Q8/OoJOqjFb I1mDfJjTdC8Zr3eAl6cm8Oc4gVM+h9EL5xD/vJFqy/+SKP4yxr4YRL9ajmukD9dIH66RA0SePHuI VtTV2cvlTKwWPVC1V87SqWriEG1KVyuwWnF/FZMt6Yji5mnXxk2vFqY5njAYnrDAUwSNMK0xwnL/ 5OlDRhimdrySNjsfhbD7tgSyQvyydcl66qx1CVXgh5c/hhz26Z0ikbhTwv6GBvlf9qsoNooqit73 3uzM7HZnd3YLs8vGprstKbUlpdiWWgR3iltq05QiwawhQW0obRqb0C0YP+iPqRANRvlEf9qkJvhB opGasGJCfzQU+Gj4a5XYpGI0MaIhmBh063kzY6WNkfSDhI95k/PenTvvzeyeM2/uvXQIEf0XaG8h 3u22T+pcRTC3ApUozCpiWjxkhmPh8rrUxWCgzqhJPVO223g61pbqDXUZXWae8izP8+F8Zjz4buz9 +IfGB+Z5oxgqlhWNojlbdt2YNb8xFsz52O3QnfKfUn+Y91PVViJDGaJKxiE1T6YTjQk7cVZq4IRa SHHt842WhcxRhj8DGz8SjRK+xcyMogKxKz+NsMi5J2rT2ow25ybPVzShXberWbqaVWdk7kD49nIn d2BzjDcym+1HKr6rijlC9/+bOpgFKTVCmpdqOjJ7qUP94TXJAytAC9tM2fG2TUASSAAkeQfr4Dzz lGVt3KBqVsIqz9QIJxttRVDb0dIMM8PeLt1kTfzMx5ePLy7tbDo6Vvpyy+ize+tfO9kweXfiUHvt qdJ04IuOS+OX71Y0v3ih9PUY097bXvHtzrHc/tqk3Km/Q60LsspjKfvlkSCLiqgSCUTUee1Hrs7z OWUuIC5qs/yqJqb4lDbNxYQyEThP4h1+RjvHxRv0Fp1iwlYHaZCJTvY871VEVmSVThLaiigkt6Bk P4gSD7wHiooUJ9ci3CHgDqoMlslcC6mmytPqiDqpClJn1EX1V1VBTTg4nQ5iV0vRqphSNAVrFJOC kxgRi0IIWzAxyZgGdRahziW+d1oPssTpIkuSsxV/QF3XVtiGrfg9tl0BQh2WVD+Q0j5QE6w0VpBC tCLH4zdBN5UONCnjTaWXlK/uIYX12sD6wRYeHUTIhZKGvlX4GtuI5puJ9J9dBBdWI2wRReKrEZ1x EeM+fPjw4cOHDx8+fPjw4eNxBXFiTl26gYS0WApQ6aFNrFjGf0/YTDVbap+so62wG7eja6HWh9/2 8WkKvYo+Tib+Kqc01VE7dVIX7aMDdHB5Gddc33Pw9bi+5aXVh8fs2gbqln/732frNOCtFZRAz7xf lMDh2iqsBqmYEoSngTo8m1OEjnu2gP9Nz1Zgf+LZKuxbuc7ejp7u+vbRob7hrXuODfd3negbHjqy PjflQEkvHt5D3VQPMkZpiPpoGKLvoWMY+0HOCcczREdA0lEapNdx1oeZ61v7KGe7DIuP0GUpTwGw aNI2LCPlVrjZ0R8EsrO4oiuw5Nk/Iw3wOJavtLVSZtHIxrtyUJe3uaFnFe4pitG803H7leiue/om 3Zk99cKVHXL8rPu7pfun//wr2K5ncSo1du78twADAIs8jKkKZW5kc3RyZWFtDWVuZG9iag0yNTUg MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyMTAzMCAvTGVuZ3RoMSAzNTA0 OCA+PiANc3RyZWFtDQpIiVxUCXhU1RX+z733zYRkAgGBLKC84ZEIWQSCyJaGQDIBCwkJi0woywxJ SIKETFiDRhYxBIdVilQQsBSRIAVfaIiBQouKaD8MoWhVrGUTCy4I7fchVmRezwxIoe98771zzz3r f889IACRWAyJvFFjeqZO9RU8Ciz3sDS3sNzrK55sPg/UFAF0tHDeHH2D79Q83vscsPWa5ispn//w ruuA3QFoZsmMBdO2rEtvBJI7Ay5VWuwtem/YN7nsz2Sbx0pZ0K687RrAcYjX3UrL51SNf3Mm+3ac A9oPnFFR6KWR078GKnVeZ5V7q3ytGh2/ZvsM1tdnesuLtx7reRGoHc7rH3wVs+dw3vzUdg/u+2YV +77ZU3kBcHL88FvaQcTyG6ftRKxKQAxgXeL3cvAfKLMuB/eDf8ER0XTnBeqwh8qwB3/G23SNrd7A ATTgfUQjC5tRjfWohQ0TWPI8RjNpLF9PsVYDemIb57MNzaw7HgtxEB0pxvoKi1AjP2SrGka6K4Yg DxVYRSOtuZiIs2op+mEkZsJHiy23tdpaZ72KHTgg37duIQJxKGRqtr7TPrU+RwpbvIiNOEvrWu1H BkdZzJpbMAub5CRFVon1I2fgxHzOQSEHzXREJLH3YlyiGKqWmexlu2VaR1mrMyahFJtwkPrSMOHU Jlo5VjM6cowq9roR+9DI1ITD+Iwc2jXrVesaYpGMx7meBpygIzJwa0lgMCOmMUo9MIB3KvAnvIeT ZNBbokJzaKlahvaU9RHaozfGcbY72fKfdEMsZFokj6lsayhaMy4vBNHGuzhPcdSTRtETooeoEFvl LIRxxN5MRShjvF9i72coiRqFQ7TI7Wq3uml7MHDOas0nkoCXsQVvUSRXqtNsepY+pi9EppgiXhYX 5Hq1S52ye7nqySjHKuzGDWpH/SmffkWlVE219AJtpGY6SZfFEDFWPCmuylJZKQ+roUxj1Gy1VFum rbBdDrgDRwN/DdywUq1lyOd+WMLZv4itXNkBtOA001lcII0iqDWTTk4aR08zLaRV9Duqo13UwFFO 0gX6iv5N1+mmAJNNdBJO0ZXJELPEfLFebBYtTCfFt+I/Mlp2lUmyr0yTBbKCs6qVa5n2y/MqTrUo i3FO1TZor2h12m7tbe2azWF/NgxhH/y0/VbirTMBBJYHNgT2BRqs8+jAZxjHKHRBGmfvZZrO572B O+4NfEgOxi6OEimdRjIyU2g6VVIVI/kcbaIdodz30iFG6RO6yjlHis6hnB8RfcVQMYppsigWlWKt WCcaxMfiR2mXEbKN7CAT5TA5SRbLOXKB3CBN+YH8h7wgv5c/MVkqXHVRXVWCSlLD1BQ1V21Vl9Ql baJ2XPvSFm4rty2zNdn+ZX/Mnm7Ps+fbJ9nX2BvtH4V5uDvfwX68iXseOieXSJfcj9Wij4oVJ8QJ 7ucpKJI5gjtV1NFy8Qw1iG5alW2QGES5uKYSGOtj4hXxvRgkc2gEjcF00fu2N1t79Tr/0tQ7uKIO cW0n2HOVzUELxVWbA/sIYgDHfFf2UknyOD6TZ8mutuHvKpyi6YrYKfO4Cw6rdM0Np9yMvbKSnsF+ 4eLpdDNsJfdxLr3Oc2EspdIP0oIUudxF/eQXWIonxae4wvd4OX5DRaoEq9GHqnEJr/Gt6KHNtCXa OtBfRJnyiweoAULt4uoGUDeSWns8R5PkJttVcRpz0aLCcUb+nrNvEXtljrqmjaZSvgHPYBkqrSVY oLnVKSqBpCcQr87xdKuWqcrJ/0U8VSbyTGvk232Q58AQmcOSGO6ckdwX43hCbGJ6ieeE4g4q4zs+ nqfYCTTYxoomlGitiacOoI4HRmOC9Ro2WiWYaa1DCs+DWquaPdbhS6xBHdUEnoYPD/HNOUMjtWzR omVbKcIvTosxYsP958tox1MMvmbai2yka3+EX32CMRhsrbT+xt3dnSfsRkzFL3GRq/yOIwyXR9An kCvqrWzp43rPIt/aaXWhcJRaMzAKh7DDrsFrT8oYMiRjcPov0gYNHNC/X99H+6T27tXzkZTkpMQe 3R9OiO9mdHXqXR56sHOnuNiY6I4d2j/Qrm1Um9aRjojwVmF2m6akICS7jGyPbiZ4TJVgDB+eElwb XhZ47xF4TJ1F2ffrmLonpKbfr5nBmtP+TzPjtmbGXU2K0tOQlpKsuwzdbM4y9CaakO9mflWWUaCb V0J8TohfG+IjmXc62UB3xZRm6SZ5dJeZPa/U7/Jksbv6iPBMI7M4PCUZ9eERzEYwZ0YbvnqKTqcQ I6JdA+sFwiI5KTPOyHKZsUZWMANTxru8RWZevtuV1cnpLEhJNimz0JhqwhhqtkkKqSAzFMa0ZZr2 UBi9LFgNVuj1yUf8K5uiMNWT5CgyirwT3ab0FgRjtE3iuFlm9FMXY/63ZOftMt219+52kn5XTJke XPr9tbr523z3vbvO4LeggH2wrYjP9vizOfRKBnHEGJ2jiZoCt0k1HFIPVhKs6nZ9xYYrKPFM181W xlCj1D/dw0cT5zcxeoFzX1xcxgHrHOJcun+s23CagzsZBd6szvXt4R+94A+xGXrs/TspyfVRbW8D W9+6zR3GEXkvU3x3L8SF1IPciNF3kaVgRsbj3BCmXqhzJm6Da+of/BT3h7+wP6vxU0BsZRbxiZSZ rTI9/qiBQXnQ3tTiowzdfx3cAcaVb++XeO9IbPFR1xFkg31yt9V4/2feTEoyExODLWLP5DPlHNND 674pyfOahGH4onT+MXzIY2y9BQN7MvxOZ/CAVzRlYCovzMX57ttrHf/lvlqDq7qq8Drn7HPuhYIE 4oVChpIQUqAQEhJ5RZDLKwUi0BDyuqUSHlZKQLDYik5bLhMe4ZJoRWFSoDSJIDHB4QKpDUyVwEwb qVPQjqFq8dFHZmzjWNqhnSmUHL+1zz6XmwPTYNU/Zu6Xb6+1X2uvvfba+6xIOkHBjDGlUb2Ma1rd mkAh14Tdmlj3slREcjPxQzYQ9d8b+/VLGJg4Z3VOVBv4GdVfd+rzClLz8kMlyXMiZcq3eUu6SU79 5FidKkUTZ5UYSboq6UmGrEVQLo01ZqGkT1Sk4WfJoF7V4vMjKqVGS86NJpTNdf6X9k5JucNOLfYV 7iXpZjdlZjRnTHf5y93kbub1iRgwGJdg3pJQJNK7Wx1CzZlwniJEPC0pSUmeFaVCnMw0/Frs1smM 0qRoEC6bxQ0Qf45Kid0aJqlyKf44OtPH5iLRRSK5qcm5kbLI8hY7vCI1OSE1cko/p5+LbJhT5gZO i316V1I0t6oUvlqt5aTznvq+0rWQZiXQtWNd2Qk5cpfj/sy+llLxPa0Q1V+nr4mNFADm+YbSd8wi KtF2UEhvpCcYxlAKiqP0KNo2Qp4BPs190b4Q+CswFSgChijdAmA5UMAy2p7ivhhjA48jeSOF/MNo vVlk38B8e802ehg4iHK9eJsarCm0DvIh9DsjiCZxG/TZazVSDfQHUL8SuoPgEsh1KC9Fv0xV7uWr xrcOGLCgH41xdqn1jjTO0kSx0X4TaynFmPOB7ZjjAXAukIc2ieCZwA6tjSq1Nrse9WCqwPw7WA/M VjwX42xD/XT0GwG5AuUhsMMC9wNSgFH6UZqif5FeBGdg/cXOuoE2Ws1rjq0J9iubboVjY148MOcv gVR9it0B7hVnmxcVHswzsikMLgeSgHz9VVonvkoa/PWM2UEGw0/EfvoLME2sooWQNdhZYDbTPpaB BRIb7RviANUaV2ky6r5n7cU68CXLL0f9Y8rQ/0HpVhptRnzNxvhbgIMY8+8yHlbREsw/DpwtOmQM bQeqMNf7rp/YN5C3YF8XY65P/RzDjVQA3I99CQNr2R7Mn8E+533XirqmoO07aLOUAf0gCaydY5L7 cH+MlabisP4mUz3aVMOvfwMLIMA2uJBxpoC6lzHOYMAChgLjgA6gHigHcoAXgFGYmzCvIeMVMcOx KeMDsWG2wYewTcass4aDcj+dM1OnxuJ5UqyjVK6QwmPyeeGYhS3H3bH5THHMuCzju5zjXvuA18kx FWOcPdFJ97MN8gwitlzmcweb+Tzs1QupErwPcVzBMcv2ucx+4ViTPsGZUDw1bq2Z8oyADaJUFesV Lru+iPFqOoQxy6wVyCm1NFd8G2/XH9IKcYVmG6NpnJkJHdaDtlG9kxb78a7FXi6C/IyHaxi+dm2N 2Yp1NsGf7fQsfPot0a4PF+2aaTbZ75qknTeb9Kdk+Rb2Qmt16pgZ8XX/rv7zQL9kNiFnNtnvme22 jfXs5jPh69QygWSXoT8BhIH7/GO0Gn+51uIrpASL6CqwXgQpxwzSJNGK/Qkgz+MsQF9ovklnjGra KdrtP2phCuvttN0XoOX4/ujHc+mXqILB44M3xMVRt5jzxpLLbrx6mXO+iqlhYAvn74LCOwofAx8h jn6iOXNM4vws7wfkaGC7E6/2tVh8nqfD4F1ufHritNwTn328cellebcgv7vnFHbsdNfP+ZFzHOdI znOcZ9z2Xo7rH9EbEcech1+lkDrXwxXmw8a31NlHHsZ+F9u2lWsfsZrtBmOA3WBlofwHwLSPYN2b Yndqid2l7tPR7l3q6Oku9x41s2mdymeHZL75kH4s79EiaV8v6xhtNq9j35EDpb216gzCn7C7XJTB 5/uoCusYbOzAeYQeWMo+kXtBdDffC3wnGnvgZ76LqqnCeAPvBe6bTf3lfTGdimH7eanDncrMOrOY 6q1OyhKFyLWttIr3itfB9vDe+x+jvv4A8kQ7jRc/Q5sA9Ua7WumDIB2RccF9y/H6gS98K8mHmF2I NjxenewTpAHKH4ekL2R/vEU4vtgXGNMK0GL5nuik58xCKsYZqvOFqc4qxJkLUAPGOIx+hWwL+g2R 9/UeehDnqxK5qRI5h2T8h+zrRhPWswl5HTDC8FET3W2G4cNyufbZwsmxO/j8GI10L8eItQd5mN8T eygixtAcq5yqoas2kScx7y7otuL8ZuLs7kT/YSpvE+beCT33nc5vGX4j8HnxBSnRCst3AEkb+J2C +Y13qc6YT5WI4xn+PfDDNkrHfaEh9u4BxjuQ8lMKVQ6kLsFhLcVIoCelPpte0xuNuxC3fIeeElvo EVFEWcZ4Giz6U7r4Hc7qJ7Tf6EfLxCu0X7RQFcsikUYZeOcazXhbsv4iPcB6/TXINRQSU9G/kr4p ltFG4zhi7/fUWzyMvUY/8/uIkxHo/yHGVdDeppBRhLO1HeVP7KPcTs7RbBczxFxKl/3iIG114bFZ z4Pf5mNPYS+Xu9kLW2N2ujbexj65Th4X/biN2E9TiezLQJrDXfl6NTUBtfqfaJaxgL6rNSDBHKBc rQM4oPBzmiv5OJCPO36C9gQwTkygF4AtKI8F/wo45sh4u02gN4BtGPss+CR/FzD0mTSRGbqDQA3w G7cuHjzX7fTxMJOou/w8hRnaVfsGw9sefp6I+SaKafAngFh8mmFtppDvcezfSOjvwZgeGfNkiedp TU/29ATtImVKHzoIxq/R3Q/wwDvA5ThOZlZ3w39k3+cB9ncz8JD07z8poGLoC9olGg4uAhcZj9Em BuR0yKWuP7WriDVGA/1I6mP75+gRK4R33DSv3it797UnWT9Jh+PhxkEsHnbTVoaYjvaAV/afp60M 6yXUvXSrLI70gBDdZ+yTNpGMMY9sLcKdCegjYOsQ2aeKEZMv4iwD3Fb270vVDHl2Ab2ZHmHE6icg fwNxfp3IfsWcst7dH3dfvPsD+4LiAhDCXXGBMsEF4Bkux+Jb5YtuMZ/vxHtM5lzS4Wlz80zcPBsX +a65/Zj/T8DZeQVoA17+X8/FWYZzRALnict4h0zHO7Id75MHqYLoBnLJpxnAT5GHloBfhw63d9do oC/K/aH7BvhZousfofwo9O0ObF0kUa16Vw6G7heqr1+NV+D0v/5romuIqGvHnP7XG4E1KH8APIny n8FnwTVo/x76bQWfc+pvLIP8OPAi5E7Ia4ESlJ8GB8BjgURgAPrvZfB75Jbv0P863/77404Zb5aV sHMY+DT4Ce83xB2zu589sPdbw93/nthU3xK3suMHfDO9hXdfNP7b57O+cVzGfqo/PAhTqZ8xiN4H bMCgYfifASwClgE/AJ4DLNmONeuBzcAZ4IqsCRqDTuzODraAdkk6uWZtlhSXO+LSh6R4srjU4QX5 Ds+e5zTLcZqN/5KjHjfT4ZFjHR6QlhVm7t03q3XGQGMg/RbQ/8V4tcZGcV3he+7s7syusXd2wfYm Xu+MvfbyGMBgnCzGhp01dqGsKOZR5HUNGIglSiol1fJQo5aOpaYKeYFalRaq1ig/2qpJlPFuRNfG lancpo0bQpQQKpHwSMqP8oNX1BBQsN3vzi5QWip17n7nnDnnu+fcuXvnzgx7GpL4H5mfiGnsqFTO bIBLnqLHlIK5uljjwKjkYiRxidgTTJs6IVG2NNCY9PEpfo0FsQyu8iuFCL+SKws0DiRX8U/ZG8Ao IPFP0T7hn+CZexG3sx8yAQwAo8Ap4Brg4RfRLqCd5+fBOscagASwBRgARoFrgMzPQar8Y7E5OFLY CYDzjyFV/hEu6yNIP94QiZ/lZzG0D7Lx5sYhxzAaioZWXzQqq4pGsKIxz9/P3p6t5fnfc7qhHU0u 4KeZDXAUO43kp5kOdAK9wNOAB9YZWGeYBRwEjgI2gC8PSBXQ+TjwDnCGLQBMoBNQ+HtZlMnzU9lY m5as4O/yP7NKTOpJ/hdHv8PfcvRf+Z8c/TZ0BHqcv5WNaCxZgjhDHxVahW5A3M3/kKsLalPJAB/F 9GiQDUACWANsAQ4AHj7Ka7NPaEEkOc7Gse9pPMsuO/pX7BWFmTs1M7Yca0wXIrZkKSyIAX0gxs3Y ocM4FSL28o9gCRH7wYuwhIg90w9LiNi39sASIvbETlhCxLq3wBIitmYDLIg8/+Xv6mZq8TVPkp70 872Ypb2Ypb2Ypb3MxfeKxm67xNh+np0zBzN2xDRmz9GsYbJGyFpH1itk9ZG1j6x+slrJ2kyWQVaY rAhZJlnHaTGmwiLzzQdOm80QWeNkvU5WhqwYWfVk1ZGlU9zM85rsVxc5qsNRuaS4r6CXLmv0Y4w1 mNEaLOsa3PajkKeAKefMBEmvLZAfiQhdm5uTKJzPX9L4VHIlH0PHMfwNY+wC4MIfNIZlNIYkY0jg h0wAW4ATwDVgCvCAXYuBH3CkH7IBSABbgO8D1wCPM5xrAGdPFYf4hjOwhuKg14gzPoZWi1bDa8xq Nawa6krpQJj8EVoTmYrwOKvA+zoLBpRAnkqPfVF664tS5k16+cv8AKvGH3GwqA9kb1drefpZNnZc S5bTT1nEhVVHzSxG9dCL8eonzh9jYUXoJhbmr0I3ZsMb0c2fjc3VhqlM9Dqm3Q5f0i6H8xzmP8LH tb/peRdltQ/hefWYdjq8X3u7Ia/AMxLLE9Sw7lCHwou118cdaj8CR7LaPqGOad8Lr9CeDDuBvkJg cwZnpl9bF+vWViJfe3ibZmaQ85iWCG/WWgusx0SfY9oCDMEomHMw2Nlhp2g04iT8ejxPO8y58iG5 S14jPy43ynPlGlmTq+UqeYYSVFSlTJmm+BRF8SguhStMmZGfumgaeENlMzyqUOJ5hI8Qx1a5kBDO vkYKZ6uYPV1K8dT6NkrZJ7az1Dbdvrk+miff2m7bHW0jO5hiqQ1t9mIjlZen1tlxI2XLnd/oGiR6 OQ2vzZ/LE9vQlacp4Xq2yg4u7xpiRIFnX6oSetazL6XTLFSxJxFKBJcFmr/S/hDRW5TG/SP0gF1t H0qt77J/W522G4UxVZ1O2T9er/d0DdFndL2jfYhuCJXuGpKW0Wcd64RfWtaeTqfytNHhMZ1ugIcV c8PhKRGmCx7TlUiBd6TAq0d/8OqEAs/rZfUOr97rdXguErzBTF1H+2BdncOp1FnG4WQq9X/njNeD U1/vcCosNu5wxisswbGXOZRwGJRI2KHQoyzsUML0qEPZeJ/SUKTsv0fZ71SS6D4nXOCUXrzLKb0I jvH/Hn1thkG5lvT2no6+aEdvtKMP6LVf2LMjZFvbdH1we1oEdFuK9W7bvkPorX12OtrXbm+PtuuD LT0PCfeIcEu0fZD1dGzoGuwx+9qzLWZLR3Rrezq3orMp/kCt/fdqNXU+JFmnSNYkaq2IPyQcF+EV olZc1IqLWivMFU4t5qzxzq5BhbWll/cUdI6X+LBee6tq0m0V6tPLnMXbUhPaVzXsEh+NJUbanhZt s0sBEZqXnJcUIdxTIlQGt78YCu1rqakapt8UQyrcgWgbM3btzuxmoY5vthd+GRxw7dotJrwgjcz/ OhDrsM2t7ZldjKXsOetTdmJtd9egLMPbKy7JXnLXV1LSkZ86UXDOh3OJcErSPaLwtQqf11sk/vf/ v7uol4u7wOLHc2RGaBfLpCU7ktrAsRVs6Ma19nR3DeN1STweMmlcYIYMytzN4QybFWwmrvcudu0u WsV52FXUhV7okrk7HfcO9MFWhY0Kwo2Gp4vM2t7kdMkj5/lhczpzuy5JzCe7LhF7RPG4L3FphC9k XjpM81nIUG+2TrR+Tf1n6+qJVpaArd6BWLigJlATqIfAtsju6NKJO6abfcl01wnUYpulHN/rHka5 ErZ7CB9xt3K19U3u/NQtszY2u6nE45PdDA8bt9tTctWrKJLEmay0+vxey8u9mFqzvNTf5D1PkquV k1kaaKJHpn371yEDAzHESNQJY1OrMyAVbaIVggLB5maBhQvIMKZLjy0qlxY58mDjyXnnFp5cIOWo 8vr1ycsFKfbvbrhmOuOMmeXMLZH7KmdSv04HidNOj6io3tx0hSWuUCFzIe1z851kwc8/n7yKLN+d XMt73R8wlS01fTP9eEQEZUVV87QoxwbKFGgzIA+UbWaSKumSJL0W+MWLTuKJm1fUm8jemsCE0iaK 8UBT/PH4Io+MVq4SXfjJu6u7R/q/M3Np1CBjcu0I3aKyq2cnvnwv/fyh47+f1Cb1/6g/bRafpXKv TyUW9IoR+AYkEiPw4/Nms79MK+NlrwUfXn96lAWaZsbQFlVUVpSrfKIfM1m7dOYz/SPdq09NrqWL 9MnI0KHnu9//cuLs1cnPJhVUN6Xt/ENUD7EfmqtKqMRXRVU+l887rcyvBmRPCfFQRfmM6TJzSUpl sFSWPe4Qsk8P/ovpcg9q6srj+DnnvvK4l9wkNwkJIV6IRmkQUJ6xabl0dbe6Upz6qO6aoRVGLbEj iFpFFEUEfON2fXW0RVdXcUttETSCW7Xr6Mgssw8cZ3S3urujaJ3S+gfL7qyS7O/egJXJzWGSO7m/ 8z2f7+98j1k0CbxRojlKhw0sY0RIlCUsXWaBmpNsBO9XBOYkUszWHOR0Vu6KL37x0MgDFcNQMJAZ tDgC8IKl0UZ1mJKFQtZ8uwOmwHJ5+Q6Wszs430SWm5iX71MyPn3TivdR0rJtGXU1r61cN61kVsHa 1VO30O17CtK6ppftz0nf80pCbvP8kubds+bvzXCqjJyJ3sNbUR8yoLe6DGCe30FpcxQfpoKEYAMO IgMcuaggYgu4aSWoFK1EdagViGo1HjsEKg+Fhh6Ig8AnQKTCOiiOaDBNycoGlCS1srz8831z3pka yKP6+qp2+oqd7/0SnluEI6SCfAB+TVeclaSSIsW4GB7pRcTFVMINTrpytyrKg5A4gDKLB2HuVbCI uSm2IpKGI11davXd8NYE1VNogpJI1GKD8RLPIroVvm+ltSqHQxrl8aK6+/r6tHQTe0QCsLIUmnsR UbF7HVKARGL3FFkKHKQwoT6lzsJxcy3CEtwNDQa6CPUYkcfAWxs8nD5XA78cFIcGxThjTUyGP7RR vKay5vfbcDbGbS3RhU7mu/9JateYH3tEm5krwHEy6upkZafojsSedhDZ+FXsH8gOlwUuE2SzJTTb RJqNzaabCYyeMyaSGdbZtlnOnyTNsy62LXa+nRTmwsYy6wpb2Plu0nryIbvWWGNqYg9xB8SbiXfJ bfa28W8ml8tDM5JHEBzVeiXFm5Olx0gvQv9pGWeuRmoTSoBPZaRAaS2eGzs1mfzgmFCVXxVLlQuH qlAIFah/GC6raMnLnmq3W8A8rDd1os8q2rOn5plFnzeVY+eH+1vXdqx+o6L/2K31+y621da2tW2q nRUi/ZjGr31Wei4auxuNRv/QfugCPho9+MNTvBxXfP9+o7oW90GgZ6CNAVUrMqV2xDBdR/aSwzr6 MxrrEcsQSs9gnuBeg1a7RZ0Rwmp/cPGMAu2UGZtSFoNlRmEI4zR24yDehuIUVfn92tzinb5QNZba S0Mo5E/xmlmWywVSs8mzzqL+eQf/lbma3vB67bjPf9ZbqtYXhPXmoD4PeqTkvcq8yvYwl9ke7obu ppubyS/i5yWE+fKEGkuNdbvlkuWh62HSUxd/2XjBSpLgRJMsekT2q9hTxMEC62DUx54qLo9B1LFs r9slud0undsFzOlcbkrwiBFy4lyJGcN5J7FL8EgM8kRIj2LChDdUO/qhHnU9cQ/ZgmQk4gKFN3cV klKyktQRmnST8XCq2ftlfEGBzmG/Cqm2uRUOjoQemMeaSlNChj8BgI37FY2tcgEK4dCqCbYUXz4o kpeXmwPLqxkZ1h4sDc2b5WjueT5xTPjNxz+cPryh/gi+aP3vX/qH3zz19fHFnvb2omDZlU3XHi4N f3Rkh/VPd560Lzxz6UTze1NAyQWxAdoOSvpRvzKJEezCDKFRoGeY3zGvTaLetq8QK6Ry+xphvdQo 7JC2J50UDIxMqQcWo5EXEmgOewUeqwIp8GM9OBGlIQHndvK8jU7sJieQkyxXxts8bob2pAmW6lJ5 pUzkzVy1T/OADyOf6CO+lsmJEVzQ4ezH3XAwRECO8UczpEfwr74c88PQqCOGQnFTjIB+gUxoc6qQ cR2BIlAOQMJV0JxVR2iScfkv/h1TT5WPU9+RN9W3oHPc/nDd2eMbs2dLFmN1pLHi/V1SZ8qTz9f1 hpeW17dEH9++GsNbEw83fVFfe0z6hKzbWFbf0CB33VjWUV56JMPz+z1Xov8egIpdQKcI+7wBCWhI ybMs5JfzH/Nt/E2emU3NFn5NUxZgC/EsxTEGI8UhnheEXoqWKIqmBER4AXapHtKDdBCkWhUDomm4 BfUa6AhZeoFhDEryuBxDBOcrAqekenO4zSm5XIuJqI4TBCkHEZHIhCJdCRG8S1PuuxCo5/dDmhEH RM1vELGGg+ZAQEsaTRl+GsAzmUygnRYlBei/loAQid1SjNkBKnVygKKTk4NqxFsEysI9isQrxgC/ eU6AV3wBPtUN4+SAFgIXQVDLxdnmbJvXTJkxOTDSQI5+dP16ZzQXl56kzj+fdTJ6DKyxfyQMahVD H7YBgcnoFdShTAw78XROsU13Tpd/YZknh6lyrlxXYSmXV+vWuLfpGt23dbfsZg4Q7Jwoe+UUlUXz JI8izBEITD4J95cCiRHATs94kphUjyTADlEAgatrQrWoUQdpRRRFIrakG1TcPDigGAodpY6VjjoH 7YiQ8ef8o/13cIy2Udg0yDJDgxpio5DBhq/1W0gAwJRFdaQ3FZnFfJUwLP0IIEs9O5eYPjO8oGj+ ElJ0aVnnyId/bvhn9MHR7Y/bvxnJL9nz1qoTxzfUnKHnJlRkFWe9/v3fy96N/uevOwY34Z/jWtx2 9fTXz78JnVkU+eTQ2bNqsp4LyjlBOQfyoix0X8nPteM0+0z7TN8A/20Wo8/CG9FGXEuv1lUZV/Fr hBrHTrQD76IbdVuMDXyjsNvxR/N1qyUVJOxwyy51kOVMdZgs+1RdPWkyjzyJiE/yZLRm4AxLiodl Jnksgqf6sh7rI2SZIvqrTYoMokIQNYkmYorgfeenJlZ/ASkFvu8YX217sbfZFBuxtUx5sbeBhyGw vGRmSyCUOTjK5KjEcZlXVUHY8Plyc0Z73phpEXxilV5S+GW5cUXlioHLV56EP2jaHR2+cyc6vG9J Y3j5tu1LlzVPm9kyd8vp9vq6U1RS2qGK1rv3W5ceTEu/1nwphjC+svcqnre8YWtpWVPD81hxS8lv N9efOQ2swuECN9I+7VRToMg0g1hOT9ggTQUxS0PayUSFiKi74DHdaB6rgqkVQibRJhVP9Wqoh+si BB9qUV/f81N9amI6AF3jW+gaZs0JW5Q5NP3T/3NdLbBNXWf4PO7j3Ht9/bZjO7FzHcfOC0oeJMEk tFYZ6SBNmzIWGsAoFBU6OtY8gK17gKG81CEBbceAIogYpenajIRAFtJOQIbENFYNTStQdUNoA7oi RUUdYowkzv5zbWjHTe49/z12cv5z/u///++LtERWRLqUzYr0vcBasV3p0l4TX9OkIq9CfUWlIW9Q UVzOUGlpSQnKC4YIJvmhkAMxX0xaEI1ZAlOCIcPsycmyuiXmoZvq6m7T6IMGBDcAGgQOEFwH1zM4 U0AB2FWO8DcqpJVEcLgy035iEUjwytrHScbeQ2I9F7pWrNyyc2Hq7I70m3jWxhnzGhs2HUx/hlcv jc1eNHPBL3ake8Xh1lMvLj1aVfRRamV/WwWd7/CuaJr7SslYt2yZ8XLD/FcreGdfMfm5uA5YYBAN JdqWk1VBOM1KfTlqR2uCKbQ5uAvtF9+n7+in6An9vH4RXQ/+O+iwOoOOYJCWSsWO0jwj/ym9xb3Q 0+J/SXw5+BPnz5376T7r/rwefIT0OD6xupAbBexue0Dg9PJ4cRxzgBYVx+02hIVcV8hCc0OCYo/Z 5qGYgTEO5OfEDIaZP7R8iSkLkk2jcIjJpgdlwZGTUYFJTs9wJ86RhEhBIZyOs7CqUgBFwNFIPG4n x6ZwYmRW+vc3RtOX3z6GZ4/8DU+pO1018uZ7/1yy+ubWX/2DkIovx87iH/zlBv5u/7ULU7vfOJz+ cveH6S9e/wjwdxAhcRFgxAbnszkRM/LxbJYJvMMesiEGjkJeBvKD9mzcQ1/HPSMts0GvKJ/9aqKG 5spMYiITmCD5fQEfkTTVouoqlTxet9flpVIuzQljpxUePpYXxl7VEUZlIA7LSuHaiE2Q5IB8g7JH ACLRcGWWokBNDB/E/31/0frWNV3P/Hj3x1vS/Ti++52KOU2//P4zvek/icOe4NMvpP987t10+r1l lb01FXO+OHrzP6UhjoLDkAv/gn1qaHHCI4khxmQZUYFvVFVCGmIyj1me3TldXkDnGaqhEzWgC0p2 15a6xZlAcXJphurO9bJHAQ/qwxH2hLP3YaFw/CAtG/+EbhaHe9NPfJDWe7knPeDJFvBEQY2JUtOT nTJ+6Aw4cgD4jEZIQHu4ulq35JHVQUNmF04+unIP/fv4DdI30cxXndk7sQL+w2rIgVOQA1F0JTEn 153rIW1FeClzYSctLERhZw6JIlgdSzkhK4WSrGAcK4oWGpSCL0Vt0Pk7U0W4KBgzVKz6Y8sXP0Bt kz0JUGgCF3gby5bcafXma4Y9xTn1BGh8S4jk5gXy/HlUssTsUU8sP8aiQiwS9enBMPLaXGH4sttl yPBWIEbDOE8DjLgd8Agp4TAqpPBAnAwAVkCVmczBvDhqIEuqo47/yxJvjvwYgTQBNguJIkCi1Dro 02T1zvTF7ivpQycGcPNnhzB+I3Ys/MLgK1tGfhiesQ2T3etvP06e+ABPXOvsOoWXXrmEu06sHHqr vD3V9NzmZ7cfOpe+l1pWix08kkcgdwpMTL3E+Q2kvMszXaAhRe1WL6pEFQnRGCSDIctSMqVjnWiZ gHKoeeC7gCtDxwYQjTa9XRfqWn1lyQ6gVWZyJe/Wm8QKEAZNzMwwXAYUyBGGOwLPIyPk/sjIhCQO Txwli+43kIGJJvjnp8G1jeAVRW+d5HgiXDcNzJhl6qeBqumZcWp5ZiwuyYyRaGYMhjKjL5DRW9N0 +3RD3CUeEwELGKGdqBv1IWEaEOlmEHW3keg0YHIXLHdYuNRqlgbgcsdT0PSSrR2d9RPJB3HiJJED tcpxekQcvt8AvtZOfk6XmR2qKWF/kayU1pC10nZ9u0NSCHCsQCIshGyKElNVFtOShgsbroSr2dXm Elw4hhqdg+aCo/Zkx93RejuvnaOwBEpmWXpNNSxmsqdY3TG5ffncVcUjrWc3nf0Yd/t6fjq7az39 atw/9MdVV3k0oVuK83k08ZZEBS2ojTNlZpFaLdWoT6kL6VZ6mcrr1E/ppyotFncIr4u/Fm4xURVw tXBJIAonN4ozPJ0a/AFtYMASd/LZAXhn2VHgY9Aczww4vXz+amKWH1aKRmcxxe+fBWhVVIWpIhUE Q1TdQM0VBgCS3IAhVUUiETCRNYaYSomGEfD3mQlbuYi7xT7xjHhNFMR5jM9p5TI25JTcJ1N5iGwF cWVkC1mPSSKAeXaMci7BU6mew6y+nt+QvdvEjGqE0WeyeJnZ61k9buzzfaexL/e5RcDmhckrM1rN FmVenL07lALYyRR/XOB3QW4c8HN10AumNy7xjWrOOCtwx4WEO843fjIKpide9vXVytMbd3QmUQeA hgMFhzH8yo49I+QKlif2kU2TaOLubUB8Cbk88ZvxveTmrbTAo7cXIckG0bPjtYkNiNiYm+QyYZ1l q+UPFqpY5lrm2miJENWnWJ+ni4V1+o+s23SmEZHF9Rrrs6SRgkRgTfqTVnUv2Uf3yHtYD31XlpzE ZrWWiwQCQRhoqnKRgcks823zcQITwpiiapquW612xBTS5kw5iXOY9IBkrTguGmwIVyRUi6IaCcsG DWvDpAVZsQafkCGsJRSguIat3Y7tQ6Tlt4bYJqZEKg6RngEHrwV+iBPUfB8Ug9GA3w7hqg88fLme RD7oAfX2b/wE7KOjPHrbfnZuG8QOBkiGxj4NwhaCsP0OWSbHEJu8hMjkJWDBrRBSC3xWbIZUn7zX b1X5bFav/XUwHLdOCZuabbA2bq2sNc2TU2E2q8vKWjs7eLTMto29OTW1OAy1CUewYy8uxIvLvX4Q aFj8MN1yLP28ODz21e5vN79Nx+83CBfGqoVrYwaP3QHIvHyzI97qd2q86lRDcWQEKo7MAPiMyJQy RSBEkZlADUkSk4aGDa1Za9PatZQmagxapVlWLfCX2Z6ZKUZlZi3tuPOwmDq5HACFKjyWOSDM0XuC JRrikLZnBhviLFGZMSvjMkCac7pBP5iVGZPPRkwzoUXistUNt4u/3xl0gRnMmEEwPdy81/8Q49ls MZtYK8Ab80KOHQfOUzJ8fjwNx7NR2ABHk/of1WUC3MR1xvF9e+iwtKek3dXqtqWVD4wv+RCYeJPa GIyNYSjYBquYgLkxGAONydDAEMwZktIGQksSKNNMIaGQODiuYQqlngaSTMikGWhoadrUEGigZQql w6F1v5UFQ0Z6+572STOr73vf//v9H6wHMpsLPfsy9QXGYB7sBa1NYZGTczo9ksdDkhzptEk2D3lI 6mP+wBCSJHvwoE/jGx2NkqY0U83WJm46P9sxU5otz1CaPNulvTjn9hOE4LdZXWoQgENZ70M+VjVi 5fY+iaEJg0NTndygduBPgFAHh4WKSQPJUh22nMNKijE+hgOGYnPRFlT2MRr/9vt636nz+sCvziLf xT8jT/f1H3+qX8Q/QsvQ62f0X/7lK33/8bNo5m/1/+nnUQx5epHtJ/oVbIRBySTkn8ZkrEkrbeeX OPFJ3CTnLG6Wk7TZ/VCCmCSP0JGgWpSgguCtyHQaj9xPWpHOxF3j8R9hWaptpr2H5AdkxkMhHtaP iRLP2dWwdFfLv/Rz+hb0/Mk3EvVFL+pbqQFGaO9bdkJPJt8h0I4XWje6aHjSA3BSwXbAc2aieo0V bAwSyrwzA/MtywKk0D/8da+gxGC+1ZsZjfHGZ180xqVnNj3D/p96ferIPnyfS8/GvtYFiwhT560L TrO1epd5V1qfY7rZTRlb2D30IbafvcZ8w3KM3R7kWSfPszxrtwoePKSIGSaB52g7JVutoqS4/ZKE hTJTMZNllmUsfpXZZ0oEwyvC68NEOFNOxy7L6AeP0BJy7x6SDaY31CQdQrgNVg5MHAJXspkZnUdB SzCC+li3MaPjaxkWjY2z3BheGGOcb9SZkhEGykRxx3koJAEGo3njHDQBLjMA43FltDxhDQH+HVnE aByyk5XKlJGqrNABfNvgJ2s/+mND9vT64Ttnpnc05Ycm/R0d2LR78p6DeiE10Hi2e98FXyQ8ebXe iYpe3FFhMydXEyXl3bULewyVaR3+hvwWGLgQ07V9c4m5ZBexiiQj0VIi7v0eMdFc76sJVIfHR6cR LeZWX1P2VgeTTathPExEI2VsLKs6UlMwMzgja3pkqW0xvYSZ72yXu21r6bXsOm51uCvSQ2yzbaW3 sS9xm8IbI7vo3exulz8SZmgbFQJH5bGYTSSBm1AknAn3APw9+S/DKb4pYvkcCqIpqA2tQK8gE3DP MS2S7/eLBOXPt3pUpc6qYjkoRykOqQJShe+narboMYQP3eS+6x65ZGIIxh0ekgY54w3FEwxHiSU6 oaId5X68pDjtqcJRVS2NlZWVQPjTvtLllERSSmUDyCmstn5Azz67bvnhaVNax+pLpy5a8KP//PTg vR5qgD1y6NiBeAX6snn92p4Hr3+o396LLnIdLzU901VdsyBLmpNXfrB9+e/mLfpkA7N954ZZjSUl S7LHHl+z+nzXquvwHwqh7gegmsxYo0ZTuB/CA/bHRJHWfryrN0gish+hD0xBhBcQiID1cTSCz7Br 6ds7UvPG0eWSQ4mrxpEdqfuiQnBCpYYXwh26j9ymeyj6yJH7t41TcABU1WB2J9apZahsM9lsOWch RaN1iNA6YuRYy3iyzrKGfYu6xprtGM734yc0r8nqVPFEUERBcYqIt4krxPUiIdIpP2T81gq/zUi4 jJ4DOclLGMYIoHRESFMSBFWCAEZHBDTFpSlE5cm2M/P0B198qt9fcab2yLoLfdTAw3cv6w8P7kT0 daLx4Xunjj97BjmNZ3djmHmNoT5oh1adg6l8jqDKcayMjwtl8kSslp8o1MrNWBPfLDTJ3GuW11ic IAFcTGZwIRk2u91KMyxrdzoEwSVKsuzqH67spTA5aMx2gTdmbaYLeilwJg4N1YkQJlMWi98lO10u WbBbrX6XAEuBt7NskOOdHMcLVrtFdlEsz0G0KJedImSOBWi3WHBQH1kQeB6zKJKkcE9b0VQsiNnh 6oKhYRSa2hcMIoTc7n60/d20EinuhiRwTlJxJ+XJNe3VVx/r0SPOMcQIDjX/aEA3b3iSer47gb5s ZrjBQbhUDj5aPXkBDGIBg3jAoPeEDLl/+O4IG0XgZm6KjbDh0xUtaZJi4E6vXaO0ihQBr0yEUIkj hT4lDgEmRwngjxo1mRF6Q3/+w6/CSkUGkv75eWOWN//q7/WOE/rHUbPk1M9Boqv2vPptmPhrUtFv 3N7+PvFraP6JHcH22gcHjb5YN3yN9JJPYdlYOfJpO620NddNK7k5dG4uUKur3DMmd2Jugk7kLqYX 5bYVbqN7cn4m/lw5RLvech/O7nOfyB50n8/+3HU521ItooAUkPNG5cbiZHzURHLCqBmWlrz5lkV5 a+yb7efs9+h7eXx5jEEkVxCOScUhpzw7Z3kOnuMtYKqYl5k3mWGGepM5yvybIRjGS0j9+GFNlF91 er1mrCaaUewlbDlzuDlYJBTux2dpXFTDVE4NqoXqUZVSi+JGlQT8WbHC+Ok4vj+O4lJEziwInzKd N+EBU5UJNxVVQD2DKTHsXN7dxM07lckrV4z6Gaq6mRyCRBfAbifMKUHj04qGDACNpDyeoWPlqVdp LGoomTn6FJ4SNtHlcopSlkqYzAwwgFF48CWict5vFh89Wds1oXTJpQWopGbLC92+Y3LHZ1u3HJ7C WaXMk17p2cHlrcXLFi38herbOH3825smb5jsZGglHMnoyB/X0il3bp+kzakb/dytB5vGVaDL2V4u u6FgQtusxnE/hAz2QAYNsuUwH3ZBewdRdjZMlVI1FFUVOBbAA4FMb4n3Ge+KwCsB0xhHpVip1Iv1 SsKSoJvZhPgDZbFlKb2Q7RA7lNOBL+2XpEvurx03pBvuf/j+FhgOuINUAVvgLKSqWI2qZ6dQ86lL vv+S9zk752JIE455vHAKM1xexiaHP7MhzqYBMK+3kbZVgJ5YCRHB8dMIes5+dAzdQmQAVaFGRCC3 v7Z8pBQ7V1Y2cMk7RjfpTEkZvHkj/qnIwzbWGcr6P9NVHxTFecbfd/fd3dvd29u9u71b7lg8DjhQ 7+LXHSiWCWuJOBYR8BtHGhI/YrBthCoxMUTMh5rGJNSZpDEmBauxJtEISFq1ttLq+EeqA7bqTEn8 6ASnmpTIpIbED7g+754fuZnbh13unX3f5/k9z+/3g1kG9AHaSkPZWXkssEfclldQAPzQ77saOh4/ UG+NfPPno6uYxPxfN+57f23jPnBw375R8canvxy5PnL+PfzWsfmvnv5778nTMOUqk1fZAUB9EJ22 ZohOHDJLvCXGXO9co9Zba+xgdrDvKLu13UGnQwlIdcyTbB231rlaaVb2OD8R/yB94nT6wfV9wbCu rEfVp9QNKqtiCtaZE2DiVKJatBq1oDZ0GQ2C4VBVGUjIY8pCmklkU8VqjisrHXaRI0dDMP1gNs00 fTk9Ag4JxQIjTExPnLB5p34ALg1lc7PL7AGB6YAYaLgx0GAzMGDVXTheAxqu6b9Hu9igIAXV7KFk e59rabLYoo6M6x/3jXzXcO2V/Z+HDgQ2LN7y4e6X6l7HLxt/7MEZWNqHmY0Hdqav+tnxf57/2wuA rFLI0iVAlttG1kcSQ5SIklAeUbh8Pd9cyMyT5uhzzSeYZdxycalea3aHznLnvBcCV7xX9OvGV4Er NoL8oVA0SGFXFqQYFMYxOco4/1QmXyljpiul+kxzobRAeUK5wv/HfwvfcGnYx7pkTQVkyYIbAbRY OS2OUcStRjSt1401t+WudTe7iXuNJ+eY0CNcEpICobmrEFghMCpReRdY5QMAKbCy4Mr6bY6k3wfQ ok0dzqdNDV2dShjADOsPoMVOWX5iw7m1dWdfrH1r/MHhzH1rG9/fu37dzk2/3Xp7Vytmf1U1jXHd KmU8pz7968m+UycgZ2XQjaMAWT7I2UVrWQiZPmY+W8PViPPl5ewq7ilxuezQkIY1Js/zL+6WPhQU JnqmBiaa0zzlwWlmlWdJYI75mOfnwcfMdfw63xAzlKYhP1YVw6j0U1HA+k21RWvTGE0j6aYkIAo8 Eb/pBXAZlmIrhbyxiXYFK8EQ3B2M5CZotDLoZAzhkD+u5QhWztjED1J2txej5cP9YG+i0aH6qK0r hvttoIHtqS/CdCbS3FGvg+sb7oEtZdR0IWyLDRzOteci+9Mjsa8PXxu5jvXPz2EXvnNV6nx56dbh PqbKOWXBK899gBcYu7pwCGaBE48euThyU8s8cGQlfnNTyco9VIl4gZ6aQUsb6KA1ShexGhgfmBCw AqsDO5zvKh8ojqAyWmkPdAdIgJ5udDCUyHAorFM1JexjorqXsDySWnWsJ70WMSIEscw2aDeakolT EjRakhlKtMC7dqUFjuIjKIyGsITS4PhgPED1gQwA3TtQQyVfEYi+4gHQARMnlDxj6ZqbFwXeAZSi gTlCbl5Nx1EcHbtxI44CsBri7uz8eH5iMlW90Ie0DX1xX7a7s7XVG3yxcdaS9CmT5jzS08O+s7V+ VaJ0oec9qbT28a13VgCGfjxSxX4JGBqFxqJBq1aWOT0mR/RZ8nSdFzMCGTE5V49lF8oF+k/kUn2B sEheKd+SvvW5xmXH8h7OfjhvVl5LrC0mFIQLxhTHSuXS8PQx88LzxjwpLA0vHVMba4715V0Nf519 Pc9t+HnfIaaja7TpFewJpmWCZKbzqxl1o15E0dVkTeNMU5WmZ5lOye+LR+JSJC2t18CaYRm1RrNB jDUqjqCsUM4xtUe9pCZVElKL1QqYioFobE2YNmR0tt2QN6hxqKdiegiE9ABl3Zp+Gm39Wg9TzABv luLOPEAXk+pMIx+0rM2/3h+054oD8qSSNU1b0ly4sf2zwV+cee3os3uWf9b2ly+372l6bu/+Z9ft XRSsikxatnhy+6u46MLbGG99u/lO3fc96z5ix57pPnbq+MnjUP3NCLFXbb3ecRj5ARaKz0hESD47 nT2iEPZQ8rKVYwQShsPtdOssh5FqcoIuS86IaMULEkkRd4tYnG0LfCNRkGj3D/qZ1f42f7s/6Sd+ Ro/YqLN88ONBeB/o017gBoJm+2ZUpiZ9FNBFJQkkKQp9V5TiQKpAbbi5eJcQcfHOdKw4AGgIkBbd iKI1OBpPMSM4KXe2284K73Nv7nq+u/Hjsq61qypfKwIa/GZbze53hx9ldm5eP/f1puE/Aca2QIvB vxALJW6yairEFrFNbBe7xUvioCggMSSuFpvF1ruPLotJUQqJwFUCYViRZ5/HiOd4IvFChEOklbSR dtJNLhO+mwwSBpFM0gt3hMx23DthA5yQ9lHxAL6nqWnJG+q9+XEfC6fY0tXVRb7q6bntI7m3+6D5 k78bqcJT7T160HarnHAR7kckzm3iOMPBcQIhDOG8CCsyw+pO4uZkge5L5gXTrbZA34MfcDqViCS1 yDgkF8sVMisHvPr+8Ix7gKTKo2i2Rg1APSoup9oDNuYpvL9Fdzy+WXMUpYrg0NRchyalY9ElpKNU EXAN3T+ebKOSOi4BULqpa2RlVkFockFXfNpvZpJrZ87cXL/dNXMbWXK77UT5MjrdIP/s93A2GZ+y ggK/gF8ssqryP26IZ+ezT0uMh8/0hhOOQ8nBg568hAixC6KHsx+E7QfWS/CEJ4Qj/GRxBmSHf0ha JD3NrpX62C94YQ+Ps/lcIeIo5KeIxUqFUk2q+UVCtdhEnuG2iyf5f5DzfD9/TfiOv+nweSSJY1nC 8LwAtgpuwFtFBF4XBJ4lJMJJOsdJElSeODDUl6N+T5aRRA5htZPLckCwsjNt/RJsAeqRI4iJgO5D uBhVAN4CTuXf4RkrHuQdBiswzVANnQn3zRfQs1G4mRsXJU3aCYhpURf8IUAFHEWsfQXMlCxZZEli LKNQdGRkFPGHkhc7MwohnO3MtENHuDBKP9XA78BTKBqFFYcRn+zuDBdCN3d3+mm42KkV8qlg3znt 0CGnFkerobp0oeW5QLBD98PbdL3IvsCqoc40uvi/Hempn+Oaalus0nbEcQzuTABA4w+vjdThY/+n u9qDorjv+O+3t3u3+7sHu/fY270D7ry3HBI5DglovNNqoD4gamIVDnUsmoKQIhrFqi3UB5oYRa2j 6ST1RbVtMiMC1kfjlHbUGR8Z6aS2MR2LmZA2U8uM02H8o85Bv789oM50OsP8fr899h7f734/r7+O nv4RBLFPcPfolnQd4/nBaA1MwC4YgxJtug9cRRyIUsnLcY6KU7w4s08vzOy+oLYng8BKWZyHO8kN cmwVLE85nYdr5tq4MY4FViGMLkM09JM0wnGBAp1EuB9sKPMC67CTmIxGM6jUyLdFq4RWsKuPu/bv VzPMqA+BEvnRratIGPs8OcdoBmYcYoeEL51fe7kH3DMv4+S9fkFxewWdzp+brXdkGwGCWO93qSIZ COLO4KkgEwQsWoKdEpau4NpLSrDTjd1wSqqIKfIH8QDC1C8zHkSnRYfUQPAKbu39L1AhI6SHwKAM j9SmKzW4ggkGTQZC0UYJxgZryM0g1WS3hewmyY2tZscEXVLXQqtzzNCsHl0ynKmJ84vseTp2rmHL cc8P7/zsV73+1Ozmn/StqFvUXsaGjlWuXrvi2oVfp8PMh42ry451pY8zPa2tr/30cPrhuI78Dbol o3tJG6fT25hfiFfEr3R/tz3VPbPpWYrZQmjgNhGfEAeUx8qYwnp5u8UuW0FQsF42E7PFZAkYNVUx YvgzVirag6SqojxVmGbllNKt9CusomOKHPK4sFj/R1icE6IyMiuTdEFWAGFUWYDiJnVF1ksC4YmB 6PRiSNJb3DiLWMcbltdOBTmqzbRjxnjEfaFhHWfefrTm9Gsi6cvbULHpPBs6fmF+8+LYzvQmZu9b TXOO3Et/AlM3D/xwGHpiRir6XbLWaiCqqVxfwS/Xr+Tf1NfzfFwss5bJxcp8caF1oTxfSXEpYalY a62VlypNXJNQJzZZm+Q6ZSt2CHrOXKN7nXud1Jgadeu4daTRRJzZrEGCkbMHDLQVtkAwPt2AkUE0 eMHaFg7SQYPXVWp+4WwJoCTcQgeNQYUuanyhVdFhML21z2pro1oCHQY80HRA4S8s45YJa7m1AgsY t4kl0Ank0LwIetGLzOvaf/MvWN7+5N3B0eGrPR17e3r3dPQwNhw+uGX0y/SnT36Mc7H53t17f7h5 9w58dcdoPTsF+mIFl3c/+XOTOE18RVwosglvt5fxeKea/DkxRyxnbk6zt9PLlznL3AucC9wr+RpT yplyN/AbTPVik3ODu9/7mf2R8sj1We6QfSj3sXfMK/vZqBh1FLNl4qvsArFa/Nr4JGdUNEoWSA7Z FJlytsWILGpggGCRJMka0kZYshnbipgiaxChfqBtfAp346eY9eAErgKLrnrKSxSciVUtVDVHhqiR g24lNNEsHc9U8F+00TYBMtlhZ6hpC0u6F1rV0VV25Hv7BhreHtxefahAOrel9aPzmzddHK3nrr+z ZMmBsRNnR5+/u6gs/VzX9emNuw/u3vkzjPYeMAS3oF8S2pWc+ZINiyz2s3H2W+wydj27mdULEi/w gtkmCWak47FRKxQRIdLJY97ntWEb45P+rw+zlt+Y9GFDYu1IC+RFrSzwYBkzgMTbHZadN2iRLbh2 gkYyzt4AaNhzZnZ9ombV7LlzZ66y57Kh0xsrys6HyxNrWtJ/pHqfGPtGdxF+/3T8MLmd9dl9ZcIC YV5guW+db4dwUNgdOGf7KP/3OrPgdCnO6Qvz/+Tk3MwbDCPGMFFSfEpIkZQxZUqZG/gGoYE0GBtM Dea+UF84KxwKhANTZwSqyUpjXagustm/OdAWOEo+MB2JHM8/Nr2L/NJ0NtwV6Q3dDMk5IHFJa25p NR8Omgjr8oYcrLEgx0Wtf7ZHTahV6mr1gnpf1WepHvX76qDKetRDKqP+hnkDMi2iCUHEScyIeAB8 ABYxg6ni2OU43ZO5FimOcUEqpzGHycl2GNjsAqPHhV0BNWlT4uoVpqbHEMiDOy9nlw7k4TxXjL4r BHl1Taw/xiRibTEmJmKMA8gbyPINTtqHwomIunExZIjhlkqN1mhKHYkOt2ig3QhBNQp81aKNZssQ PDZJs3LODNklw9Ny/RClQpJoFW2iTu8ze91IiBjcmJsGS64dLqdY/G7k85tN/FQwepGwQPRR1o08 Yg6lxSi1KZmF2oNoXrS9nfrwjdTI1tpK5MyUh0PhAkguM0oyKIAp0SjTTqONM5fJ0Eco0ZO1f/uO 1uLg0VvvV815Oe/wsp3Xq6Vu06b6HQ2y/JJ792+PL6+/tfP+Q/xK9oaWdfNe8SvB2LfbK8u3RTzR iu1vKktTS0v82Tk2EiiasyNVffI7H9NJC4z9i8nj3kdO1HYVEXg2/hC1i/3JOXBoU8HDm8wE65As CtEsAmSgM2aJPuTDZmvQhMcM/Hxh/hpDs6HN0GlgEbDoKUO3od8wYNAbrjENSMEzLq7PgAU4YJjm lqERmuUScKQ8AJZZvE0NRTQadNI6Q8WSH/JbCWDGL9lpixjRtWjW2sb83bt7L12yRSO5p0+Ks9ed Yb57ABsaR987kD66ON9Fa9kFqHnMhpCCrl9FLqhBAA/EeG1yPIuK6VSrPR614QBvk03YJhsB8BKU g4rkoOLURNSJ+53YWenSYE9F1PXUxTS7Trm6XWMu1gUJbpIQIN0IXmEAsg4rVKqTwWx4Qj+BGWiV iVkZRtBGysWKFnOWmQE3rOc5HlSUNbmRmZcy8SAvrx04EeZkSrHWiHBIiwhObUy0uKBL7Hiw6myV aOwzSm8tWXJwZt8HfRVNVcWbmCPp3vcKy5csO7SPKYU4hJGLplToBcGrLhdDCPVJpYSi2SyVCmAg 4jxdmCtj/+iFHY/vcMfnSSF3ShxFYIGrb5IC+EkkwwJXXyQvRQriyAtLlmkqigghUoqKSQUqJ8vx cmYlv0JYj9cz9Xy90Iq24q3MNr5V2Eo6cAezV7ffsI9/R/gQnRAOk4/RGXIdXTZcJLfRTfIFekD+ ib4iz9EIySeIIwqSSQSFSAmpQuDduaRVjnNJsEIEYkRQIHZBIEjHQGJAdvwfqqs1uInrCt97V7t7 9717d2VLthzLAtsyYmq3tjEiomxIy8tDTQpNsIkamGRgKC7GLYHhEUNmkjhpUtxmOgk0P8hMkwI/ WgN+iccUAgwDSRNIS4eWNg2dmoSkddNOHU+pK6nnSuaRla/27JV25Xu/c77zfRhuUIG6KSUES7Kq CAiL9TrWY9T3fXClRMng8iEfhC8RIfKVKPFxTPv0NxyysbJwNp1Nl4XGRtOcuDl337YXTsFb9D51 rhecRW+BzUG6d6cT9xwoXYUbXdCHLS7o+F/mOn81Wl0ZSvz9WG5joCb7zLquFVvI89yfYiQhJI4A Iowc8W3LwzMCdSpZ4qxy9jiCw/NTqaxqsiMVRf/m/6JyelNA0hVXKlfCTAyggKQpmkmZjVzBkyO0 XKsAeVItz6AJswk1y3Po/ebXhIWSLy+lrdqD1kJnCVtlfZNtkJ+g69g2abu8mR6TjlvD7HNpUolr ThzFjVozbtWyem82amFb6XN0r/CqfgAfJAe1n+tDaFg6bl4A3/cH5WbgpvUxG5f+q0SYIIqQwrKo qCrVdF21HQfqq3VARCyayS/216qWGT3ryDQqO4wlRBnMoGyqul5tmJ5hmNSxrIRKPbgdiXdQRATL LEAtRzcN1VEDAjN0nVJZ5rAyyzJNpHoTtoFXG5uM3YZgZPABX422qbhL3aUSNUO+5SttDu5ydjnE 4VeaLeLVBccjAPAHhvCEO7G20BbCS8fT6RDQPvzxBEiHPrqDuj31YkWPwDPCKbz3Lr03Gb54gkzo NcF6mnaKDx7z0Xq4cvnKQSOqR8nJ/HWEYZj5y4OowYqyTP46nj11tLcebloOppPmLx+RG3Bhomp5 6+HGhzoKs9ePyNHiLIPZ+wqz8KBhK8qfTTP5y0flBv7Eo2g2OV78pTsPv3NfaeE+J399QI0Gooh/ AMRbcLtm/sowS6KZMDL5K0dcblPbix4PdYNO40leyHG3lCf6NKFWwK25E8cPzQs0Hjq2v3nucH9u 8MShuquQ9K+NOm+Tjdm977xL1k5eIzuH/ncJst8CPvoXZL+Nt45YDFuxcFLifDQcTnZYrwReofvM n1qnxdPSafkdS7H8kmSZ4CpBo8xuxnO0p/EejdazRwLtcru20nwV71X3aiMko1/Q3jZ/bV8Tfqe8 b/zRvqEyJkmCTBUFS5IiBgToVhaQroEty7A14GxiaIJuq5JFLNU+j84rxK5GioeQIhDjvIGNal3w dF1QFTCoRLINyEKktjHMFhs9eky11khKj68CkYz40jJptyRIGfKgb0aFHhJrg4UudnYW1eF4kVuA Wuwb9vjYR+kvpBinlvRUAqWfss8hnmuW1UsLiVN8hxPPphRNFXEaNEMVSY3vmlaR1GOlSQEGvz5a lbR5Z1KDSRyrSip+JHmboNoLrgx4Kw381FjKmaoFIkAQW/iZ3L6//OxLkZnVA1dzP8YvfnBtTu4T Ese5Wwsb5jdO5vTse3hJey7N2asq95DwD8CvDPcOWBFs8f/ijUgy7j1s9auCb/iwodF4Q5PN32Rd YSVGiNVqtXqtMUufZTSb+xwtzuLuopJ21u62B9ez9e764DZpi7HN2e5tDz5r/MB5ib3kvuDtVQ9q J+0TznHvU/Vj73Mja9/y8pH7gAJ0G/gEmD/suW41Uz24sHQgjGpN9TRNdRnTdU0SImELRewIqY+c ipBIhswbslyf+V6GrPC1ecxn5DF2ihGWwfOHLRxDXy9X+UfMimq+H9Ub9DZdWKbndaLDNwbqLVgs mTdYHt0J5FEWtrPdICsBVQjHQvb4aNgeBWtTFrLHChEKcXFzG2IK0MI5lDCnMO4tAArMYEJFhqAi TyA9fxNp+Zv4nnr08n8ebkmqsZakCU14KJh0YsHkFJyFkgQ83VquC1r4624LAncB2mGXd//M1KJS p0bUct8980EiVpn462Cu84HpDTsfbsqtO2THp5dvsCoC8ey+J5/euYVsmLzQP799Occ5DnV6BXA2 8fO+wTLkIiUMf4WVNgHLvOcrEOCvgjaAqzP+EgjqSFypt5M4qS7GC8gCulhpsx/FK8gK2qEsszvx 4+RxsCA78Ga6Q3kRP0tfUG7hcVIepjW4jiaUJH2TXsUyz94RO9hEgIGg+13xa0GKkzmKSqiqVmMC DYJg6BwSWSMmYInqGgMZCVMlGWwNQpMQoQhX+TORHDNeNzEyfXO1udv8pymam5Hag3E/wm2oC+WR gMKWvbmKl2jiG4AjmNMxrv9To/Y4By0Loi1l3wB1esPhfmBKAdjmuQRgAwB0pxHHAVAaqsM1lPuZ 4rZQvklwdWaEbw/fo8IXcXc7ThcwpVCnFl/d1OnmSHlSoSXlc3m7P1rKp/7jqyVJ4sEoK7lbwY3N WJpW1VwVxPKsxqpgnLzx/ZW5NuGJ7Ftd276D//ayQKWXt2a/vUN5LZ8vamDxLKlBKwFOGe1Bf0II VUB54k2g5sOVjvMAJiR6jMRQHVed6eZm6L1obmCCbBTPwgbJaJE/DeSVnII+jyRZDBABIzkV2C+k HoNN7EM/Qq8jEWXI9AG66YdFn7U0O5G93Tk5z41Bz/xyg9vcGGyEMffksZOBiXfhgF9aLvybdIi/ RRp4jt/7j+4HA0k+kz9zyYfyhy65JF9yySn5lEv65X6X7Jf3u6RP7nNJj9zjkkk66ZFO2umRDtrh EZ3qHvFcKpfqloYE65Yp3CKmQbCeMlDKwBm8zK93u+Rdcp8syNid7aVMQ0+BmPBLy5rMJ7E8m6YI RilB6COYhEPdB4rLgbQAp5IdtScSqWKE5qXBsYCXLKwRzrhoGJF9kfsX9L3u7m7cPXXgNA5Oa26C yiyVJLnqnhh7b0VnrJrZ0iTgn9yOAufef/O51LK6BaWrHrkbQS12Cp/gueJF2KnNfs3/2S+XmKaC KAz/90E70gIFKlBAaFAotLVAgUKw8iyt8rCAARRUQAWCYWEwJkrcaNSVMQRMVCILWZm4EB9xaWJ0 4YKVGuNOkm6McWFINMbQ1HN7L2jUCiQsWMxpvpm/05PpOf/cNve+0Yf04kP9C724xIRpdpeJZ9gl JnaxIbrxZQIzSGD39UrHOQK5IAoGeAWIkhfUpA2wCoJgMc6eX22QnsfCdFZhtZ9wtCGstKL0opye mZ7jbB5P5YXnuY4+p6dCkr9TiXs6igJp/fR/ocbY3wjmf9BL0K2wSFemVKUxT3wDZDcxR3fIzwDd MUB/D2DLQLxdxXBSxfhOJcH9fxJp76RuwFRDvAKSvUDKFJBK/2+pbwHzAJCWo5JONWV8ASw0Z15W ya6jH81rIMcP5Ioq1qX1kfcE2PkRyE8EChoA2zWg8CpQRH3aP9Gj3nXAeQpwkU/FJqCEaiztBNy0 VjajUk5eeV4ClZNA1R2g2gXsdQI1n4E6qr/hxhZjYeM0erYevoFfNMkcDofD4XA4HA6Hw+FwOJzN ACIEKGGGpCghk9BhzZAQp0zxBmMCkkzJKanm7WnpsCALO7SM/AJbYZHd4dztQkmpuwwVnsoqVK9u 4GvyB/btb25pbTsQbO/oPIiu7p5Dh3v7jhyN8Y1PH69d1ebERWWQMU9jAaykdDTmwY5yeKD00IJ2 dKEHpzGBKUxj2WqxZkcilK/k2eDU8hrQhk7KG8T473mRUKwXdsEaubI4u3hTO5X1hLRmBsOwtp8E I42qlkkbNa0jlaFcAfI2WsmgOlQtIhFeTUu03qxpmfRxTetIT/gCwcag31E/Pjo4FkvDhwCCaCT8 cKCeXBklb8bIoyGM4CwpxalYWRtdp87iTDTU4gRdrCJMKKYTgWyMD1PlomKAMEmfMBly1I6VGcNi Cpm0Gn/aWUuBOjrrZaZss8BapVuaq+LtGZxrcvUneb+yLBbNngvZ7Mr8qOXD+x8PwiOmatZKbxWf ozv/FGAAjR110AplbmRzdHJlYW0NZW5kb2JqDTI1NiAwIG9iag08PCAvTGVuZ3RoIDQ2ID4+IA1z dHJlYW0NCgAAAAAAzMXF8wQEzBkZ0VRU3MwAAFVV3V1d3h8f0gYGzR0d0Vtb3VZW3Roa0QplbmRz dHJlYW0NZW5kb2JqDTI1NyAwIG9iag08PCAvTGVuZ3RoIDMxID4+IA1zdHJlYW0NCgAAAAAAzMXF 8wEBzAICzAMDzAQEzAMDAwICAgEBAQplbmRzdHJlYW0NZW5kb2JqDTI1OCAwIG9iag08PCAvTGVu Z3RoIDQwID4+IA1zdHJlYW0NCgAAAAAAzMXF8wQEzBkZ0VRU3MwAAAUFzRwc0VdX3Vpa3R4e0gYG zQplbmRzdHJlYW0NZW5kb2JqDTI1OSAwIG9iag08PCAvTGVuZ3RoIDU1ID4+IA1zdHJlYW0NCuvr 69PT0wAAAAAAzMXF8wEBzAICzAMDzAYGzQoKzhERzxYW0BgY0BcX0AQEzAMDAwICAgEBAQplbmRz dHJlYW0NZW5kb2JqDTI2MCAwIG9iag08PCAvTGVuZ3RoIDMxID4+IA1zdHJlYW0NCgAAAAAAzMXF 8wQEzBkZ0VRU3MwAAAICzBISz0BA2AplbmRzdHJlYW0NZW5kb2JqDTI2MSAwIG9iag08PCAvRmls dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE0NTc5IC9MZW5ndGgxIDI3Njk2ID4+IA1zdHJlYW0N CkiJfFUNeIxXFn7PvfebiSSSICSThP2SIbUyQbIlQRDJJKQqIlFN/HQzkmgSQlqpxWpTwbJDF6W2 u9RWUOqn+4Vsqd+gumWp5qFWVds8SpVKH+tnWZX59sywln2e7b3Pl5x77rnnvOd3QABa41VI5AzP 65E4/mz+h8DEjczNLqpwVS7YcGQAUFoF0IdF06r0H84sP8Z35wBr8oTK5ytq5Q+hgB9/2uDnJ82Y sLjJmAUkdgViLKUlruK/rppQwPru8Jvepcxoe6jNVjY4ls+dSyuqpt88mPsFn18FQvtOmlLkwrrg p4CRPfnsrHBNrwy40eYmv1/A8vpkV0XJ8EN1SUB5PuPpUTllahXj5lWe7L2vfLGkcm2HmvZA9B4g ZJK2C1G+bwOiVCyiAPPCfz5PmXnBe+f9L66wto73vwdrG7bg79SVdGynuwjDHbJRArKgcJst/hkt eAOhGIkV1Bad0QHPIIsUy8RhEa00p5mX0R+vo9bcQTXmJr5fjI9whxF8pQhJyGb5Z1CCy/IiCsw/ wg/zEYB+yKUOcOE071uMYRmWYx/NMu+w1VDUsL4UDMIg84B5D92wSC3RzrT6C5ZiN1nMIrMMnRAD t4gzT5tfIxYFWIstjCmOGtQQRGMi5uFNssmPmHoD6+ChQDFOpmv72VIWRmEyfgU3NuEotaUc7Yx2 zfy1eQkWtENXxlSGy9SLhon1KtAcYJ7FGHyAj9lf725QY9QGbYxnoPmWeRDtsYP8aQ8d0BK137XM NteY7yGQ8SRwRLLZznjMwQEcwT9wXVSb1RiCPLZ8mDqSTrEc8dPCJl4Rr8iT6M7ejmO0L+FPMDgj u7Abezk2X6AJFymUIukpGk9L6boIFMXihFwp6+UpRepdjrcdXThGVViP93EMx3GCNNbfk3KonKbQ 7+ktahKGuCpuKz81R/2oWrRYT5PnRzPbvIVwROBpzEQ1x3YttqMen+AzXMcN/JNCKJlKaQ0Z1ERX RSsRI4aLSrFCrBdbZbZcKg+oXipNTVTH1VntN9pCq8vqufeOZ5lnq6fR3GE2cu0Esf5YZHJEZ3NV rMd+nGTtn+NLnPfWD+vvR6PpObYylRbQctpKh6mRrrCX8O0Y0U842eoU8SLHqUYsE8vZ+gnen4qz 4kvxvbglNRkje8sX5BppyJ3yU/mtClGxqrtKUMPVaGVyZhK1wVqetlHbrB3UrllSLMWWSst31hrr XL9jLd1avvLAU+oxPNu5dv24kmZyJFajluu+nnNwlCP6CSNuwk3OQgRF0xOMuw9l0lAaRs/SWCqh GppPr9ObtJJq6T32gH0QVsYeJwaJPOESJWKumC9eE/W8d4kj4rQ4I5oZeZi0yziZILPkaDlGTmYf quQrci5HdqncJE/Ik/KS/E42c9bCVCf1kpqp/qA2qHrVqD2tVfCu1fZrDVqjdk+7ZxGWCEuUpYel 3LLRct5qsfa25lh/az1lveFXSVHUjZHreGQJG/dgJ7FJhKpqamZGR1IIZs/jOA953BU3MFB6OC9B 3nvG1l7YVDvvS0uqMvh9Fe1GLzqMaouQPFVVE7bROdGkDon++IwKyaY2yMnaURGNzTyNlog9Yjel oV6kiFFilQRdpI24yPU+HctpIk3FZmqmvvQyJVE1TokOMo/mIsWsFYpaURZdAyPAbFWM5/CTi/rw tL7sWa1aq1k8n3ZiBWd0C76md3GXNPMqTzfJ08jFU2YR1/s8eKfeOO6zau5HG0+QSZYTqCcLT/wk ywA1E9fwL1zWdnFFpfEkveQpU6vVN2aSGc8dxl2Gjdx3pRjMHXORq2Qvn72nsdzp/jxLErmrczAa xXiZp95S0zBXmXPMGeYU/I3f3iUH3aW3uSN28osUfMx7MT6nhdyHg3/az/+3PMVowBUKpy6UyP3Q rE3TlmibtHptn3bcksDRnouVXNHnuZr92YMiNOIKbpMf58YGB55kvMmMPR+TRIHci3SKQCX3bFee 42kPPJnKWmo4equ4n/dyb1zjOTEW+3CGBIWxR0Vs34/1DOU4/5Kl3+EMzqHtzCnmqd0N37PfQZQs qtheKmtawVOrgTGdw7ccbdOHy8FzwUmjWNdtPItittAbOVSHTPN9nlTZcMpjHO/OFII0iqF1/K6Q OzQIHdFH+4YEHJ5sM1mUyb38G2My/23+9YpEf3qBUQSzHy1oT8PRy5MLR2pq6sAB/VP69e2TnNTr yV8kJvTs0T3eEdft512fiO3S2R4Trf+sU8eoyAhbeFiH9qHt2rYJCQ5qHRjg38rPatGUFARHhj2z UDdiCw0Vax8yJN57truY4XqEUWjozMp8XMbQC31i+uOSqSw54X8kU+9Lpj6UpBA9BSnxDj3DrhvH nXZ9J40ekc/0a057gW40++hhPnqJj27NdHQ0P9AzwkudukGFeoaROa3UnVHoZHV1Af7p9vQS/3gH 6vwDmAxgygizV9ZR2ADyESIso2+dgF9rBmVE2J0Zhs3u9CIwZJcMV7GRMyI/wxkZHV0Q7zAovcg+ 3oA9zQiO84kg3WfGsKQbVp8ZvczrDRbqdY4G96KdIRhfGBdYbC92jc03pKvAa6NNHNt1GmEzL4T/ 98jK26bnz3/0NlK6M8LLdO/R7Z6vGw0j8h+9jfb+LShgHfxWdMksdGey6UUcxKF5OlsT8wryDZrH JnWvJ16v7vtXYs/wcgrLdaOVPc1e6i4v5NREuA3kzojeFhGR+oHZhIgM3T0y3x5tDIy0F7icUXWh cOfO2G5L1W2P38Q76kLa3A9sXVDwAyKw9aNEycM7H+UT91JDcx9GlryI7FlcEIZepDOSfDv7lPxv 7ss/qsr6juOf5/eVLO9mMMWTXsaBqeBA8yc2vYwDc2MRKCCgKyS0hDVdHDm5c0TnaUkXKX+LgM7V ygJb1x9/3MK269oZYWO1U7SO63Sazk1Ft3XSVYA8e3++z/NcL48a1rZ/Brz4fH//+Hzf3x8P/1s+ mwL3z0Yx/JRKqBWsxIqsDI7IKg94Mzid6we1JG+iL3CZoIDEixeGpiyzU/Qk72XiIOskIjXkO+Fg Skpw8mSWiJGFNcUY54n4jCmptSF5ZuJqrw8G7qN8+HZZaUYa3J+QwAvcEPJTBSLBDQUlVtxHFeMO kz8tpTQol3NO2MmJLeKcDU5OpHp5IpR8lPg9Hxv0JEf+RnnjRmc/mBGU4j4je7mVn7soMbegrMSX HSi3fZtbOCRm5c+O5Nmh4OisEmWcbIfkcYrIhSiXRgpzpGRkUE3Cny5EXRlUIEqRIPlygt7yBdb/ 0piEhBvWCRmeqEoh859cS5ir1exRBjNShsbnDokPGd3IgILxqslybmFZIBAzJC8HB1AgkJPoywmU B5aFzA0ViT5vYuAl+YB8ILA6u9xZ0JD5csO4YM7mUkziQSljCrGzjXmDeZTlpb6+wQJvtnB/1I92 q24nyXNs2iikvE6r1Rr6Msgx7qBSrZPKpL/RUuRVgyzlDnzPHKQilF+DeA3sdnmOeQXli8FT4E5w N0gGS8Bim0UgE3W6QBvauI/bEfY0VRnd9A30RWAXWAZ2aMW0E3m79TlUwenoazPaSER4D9L36m20 FeEm5JdyWWG5fjF9B/mpCG/Xik3TaCQDaYTwFaTHof9tPGbYZPRfo9aYFxGejLa/jfxNsEWwhfZ4 x4jwaa4j5spzfJzD8E8d0reChaABLIF/uH466k1AvBHhWzCuEbAjwW0qPk5R5i68y4KwU9B/lj1v EvPGPCJzwvjFmK4P+zQzGoyJ53UOdIM3o8bmpnEINbjB7xTrx3O+FcyVu+mb8Msgz0s7Y37MeIje xbw6gIa331QPmW0Y53ztKDUhPg3cJaghSW2lVcolrMFR+pG+i36GdJKngn9RknyB4vUkmgX/laD9 xWA52nxV6KGSx2BegJ2gnqF4tFUOqtB3l+Mn9g3iC7CuJSg7gDAekPQoWAkfNIGHeXzoP419jnX/ WCoefB5lP0A/uQz6nCDA3K11pTWo/0O0JYl+rHWwLEB+FXz6C/ArcJzH4CB0ZiPaaiNFbjM/gh0N 4kE32Mp6A+VgP5dB/zEoHyP0Cs2wNlkfrA2tU2h1EY/dmoPYCw32nnkI9ZeAsWCifpCW2kxEWfZP BWuW94vTNmuLde1Yoelq1r10nufJmoqyO7QwFfAYRL/QlmN536HdtWzxDcBjalZ6aAtrlvXmWPYL a433I+8J2+ZHzTXV3iOpqD9eaB1adKzji4h9g5rRZrG+FTrtpTz1JOXh1ZmnrYXdhvm9hDTMR8Xr XUmhezxhmoS1vAd197hsE2P0SFXo60m1Hb7oob3Crz3yV9UeSdPazXMaSV1au1wnwtdYN1LYymPL ROd93vQvgvyO1k4rED6v9Zgm5rON94TRK6UDn2ORfhhsAJM9KVKTp1oKGUXkxefVJbBK9VOG5qdZ apjmq7Hkh5+SkF6kf0ucu1vQfqfUS41Yr8eMWEpUzuFsRF/yO7gfALcPe3eUjoZozq0lxzp6dVvW DJ+7sBrsWOy7l0EHOGnzZ3AKevyB2L+4G/h8FvcDzmjQaOnVvBjRZxe1wj7h6NOl08kufRpuXbot 3y18vou7BfsU42h05s/nI59xfEbyOcd3n1PebaPq78TZ8UdxDndTmb2vJ4F0kIY2jtnnSIcSMi9h j57V3zI7jPlmh3LC7ND3mM8a1eZr+lGzFfOeFLlTw9ZZxvvJuUvZT3wvOveolkwr7POsWZRF/+Ie LRbnAOlrsf+qqALt/o7vVd6HSiv2HfyJ9jaqz9H31VO0BWMfpbxopauLKI/PRLUWYaTjTOf8W5Qt In+h+hHVqpMQfg62hb6kG1Sr/5rrmN0i7bSVx2laGe2G7tLUx+nn2iEq4bXiecgzzBO89tjz8Z4N tNcgaPgUNat9mHMYc+wUtkXoieseMft4fsZc+oqmYH5cBnAdbS/5bH/sEr4ICx/tFBqGL7hN/W3x 3iDtXZT/Ka3zxFCz52s4ny5TvIGzRPR1iBZ7/MLvqrivP8T+6IXGiqheu938VOj/oGkqfdhDvdhf jIS8WBqr9VIL9lK98I9lG3j/KL0UyxrB/ArFe6IXGn+GHtbbabMehu56cBf0YN16MZdqmo3wVrXd 7EfZbLRB3DfSC8T7hO8pv/km7xcjTGMMP/pHGR6DeP+hX+UMxrud6nGWZHp66Wndx+8aSYL2xoOp FiK+HtSBzRYizWtZKQFtrBPpy+k1uU2RoW/O71Kfx95roUzlAMWoK/B+OE8b5TTapORBdxdxZyio h7iaShOVi5SrfCLun01aDM0S5eJwj5+lfLUU9cNUqR6mSsVEeAzYCT2inhaiMu1+vLPuRTs28kzU GUH5egPCaeZBLif6+MSMY9S1NE3Ui0KM1YHH/FTUmHfCtz+GHni8CEePl8caGac9xuuNT8yT20U9 UeZPlElkvgeSLDtYIDdSO9gvn8Q7PEx10i48VlopRzoDWm1eoAXCHgIFlKPWSfUgH6hqHe2DnQJ7 HvSAVnAM/F2dQT9B28dhj/B3ASP/EmcXLPKfAa+A9528aLiv66VHo/6VhsS1abSekVPxJkyla8vv o+nqIziH0+FPoNRSPqPfRqsMD62STyGdzyRXXJtIu9VVNH648QyH9AalCx9a+KPn6KwHbNxN8F6U 9bHF/prC9/N/OsbPC9Z3PXhA+H8/fV1o6Cz8b9AI6RjdK30A/bXSdxk7Xi78uQ/73l4npNeLdNf6 QSszlYXkd6cjvJFx4u51HS6Odl+MxtGBgzENbxGgvo/ywB3HffAYo7PGUkV8HePEI/3eiEKaDj/l wJLQmCuue2kNI69GvIlY5w8xkXgh3lWFlj4Z+HYlAx8Sg7QHGPiOGJR9lInyawn7FX1yXXLWx9G5 e314XOpvUO4veDMXUrzbRvRtnxdDNF9g6T0S57PkjKvM1T1xdW9gr9yozf8nsHdOgE7w2/91X3zK 8Bnh5XPiLbw3gnirPo1vzNepkehKPVH/caKB+3AOTYV9AWlFCCfDfgjGIG0lLG6jfqhsAGocfBt0 g/3qOHrEfleORTzbqnvlWbu9JKs+1+vDa6d/plW/fxNoQfj3ACrrfxV2B+xllA+iXilsHdI2wk5H PB/kIP4HxOcBGeEMcA5gnAN4xgykof4+UMvvket8h/537Q2+P27WYoxV4HvizYnxur8hbto66zmM dX9rOOs/nHW+Ja6xth/w5jvBRH37fOY3jmOxnp/i99LgP4heUZpplCTRBDOsNB3x3j7NH1L2HBn1 b9LLMLap44Djd/eMn2PixIQQXEK4B8Z24tTFccMMAsXvBYdqtaa4kFb2oKqBRuo0qVhqUjZok8CE RIJIs02dNFVa3EqL0Fib5/OgdhOEu6xStanD2jQtnTTNH9inUdEP075N2f/OHnQSX6ol+t///O7/ u7t3d362t8ZMy6u9jWfz24QRW/sWqUKMnNV+SKYhhnhKRAZiFVkpudtiXuSvEgOagTRSQEnVaxOS +aulrV2y+x+I9i2KuyCig41KyeuLpa1O7XuEauPaq8RPuDYF3wU/A++Bn9ZeJh41T7PU7o3NYLwE 4gltG+lDs4VvZzF4UttBulVsUrQ1xpkUveGY5daOaD4Vadc8ZBDu0nQR48aKZmKmpnal1LJZzu+K 8G6L3dYuazrpRGoGqe28/bbmJvsgeSdjpRZPbMFq1cZwm2NYFo45UrKoSlN7VaAjjDei7SRdaPsu fpBugx/VdoltvLqC79Ey9iPZC8YbEq6npZU8bbGq1aINodXW5rHi82q0hVLwQIxYQa2XRCGGRZ1G bRo1rzaH2hy2aQ5bM4etmcMs5vDkIdosWmaR2aedJ3ntHFmAFlF3oMttAitYUZW9vbGK9oTmw0p4 V7B2FFd3lFra5Mx8omOrivlKrW2xxG3tNTIKMUx+orTdFzu7ooXVrTxZ8nVLIC9aWrF02xt7AbBL 7sFtbae2S61Ej1oB2+J4TfHjkhPKfstqcnXYH9mf5P6yu3gt/XdN/6zpv2/4RpXVShjFLLM/SK9b O9nf0dlL7K9kETXGVtgaiQL4CyvLWbDPWYUk4Ot4/TK8An8a/pHY/Skvs3IJhrm/Izxd8mbZmujf 16zwQLOyvbtZ6eiKWQH2a/Yx2Yku/gzfC/+YVcke+B24D15lE+RT+E22nxyC/6rpv2Gr8kyzD9kt cgBeEm1yCrbQpS0Lp7QPBGm8Su/jq+wDdoPsQPR9EdyBq9dLwb28fQX9UfZzNiF6eIflZu/SDP0n QgWyLp10sPdEXHayIFYNXmELbMH0xc2AGTGXtGggGokuaUbAiBhxY8mwvGyebMLi4Q3LrqKME4Ph 9EAmtMBmhSNuW//GPcn7YmQGZUHVcijzqkZQeh+2fqlqCXaZjEIMfUxB09AMdJE4UJ6HLkBvQG+q KxPQJHQOj488iDyIPIi8IvIg8iDyIPKKyKvRJyFJ5EDkQORA5BSRA5EDkQORU4Scbw5EThFpEGkQ aRBpRaRBpEGkQaQVkQaRBpFWhAnCBGGCMBVhgjBBmCBMRZggTBCmIqIgoiCiIKKKiIKIgoiCiCoi CiIKIqoIA4QBwgBhKMIAYYAwQBiKMEAYIAxFeEF4QXhBeBXhBeEF4QXhVYRX7c8kJIk6iDqIOoi6 Iuog6iDqIOqKqIOog6izc0WtZn0CpAakBqSmkBqQGpAakJpCakBqQGrNW59Qi8FwbKagaWgGkmwV bBVsFWxVsVV1vCYhydogbBA2CFsRNggbhA3CVoQNwgZhK6IAogCiAKKgiAKIAogCiIIiCurgTkKS +PqH8mtvDbtIMy58uLIZ2qd8mtxXPkXWlb9JisrfIEvKL5BLys+TuPJzJKgc/SmfINxFBY+3W114 BIxCL0FnoUVoGboD6ap2F/obtMH2m3sc7fqovqgv63f0Tct6XWftzlHnonPZece5adlZdzLD6mYe 9RzFo4W8pcpplA8gfIigTKhagg1i3EE8Z/fjf5ANmlu+MB6E6d0wvROmy2H6VphaLewZ6lBPOoPE GSZOM2ZrcIivQ/FgaAhPpvlb97dzEfwGL9PVhvWZ/fD7UBFagi5BcSgGRaAAxNW1MPIZc0+zy1Uo BO2GDDkE6erC9+2OLS6zwjx0qfSJh7TIcUK94FZEKAori9Ao7EMROs2tFnqLhOTXIHoTO3cDviz4 PTS/37BfCr4Cuy74IOxFEXoKdkKEPuOWhz5PuEOiY00/jvuWfkzwFxB7TvA+WL8IBWU6jIECaO2j GXIPHmhSexsj+QU/BNsj+EGZdpGQ3HjqJBE1vU2QdK2ECT2o0IyDmpv5F/zH/D7wf2BhcTw+N8oO 2N1Amb5guvlq5GcIW1xYbpnH50Ox6bb0m3wpMMvfQV80cIv/lD/F5yNlFy5fw7xn1RCCXzLK7Ia5 lc/wKJ+I3OOv8Wf5KX6MvxjAdcFP8lU5TZKlGXbjFk+jw2/iLgKCPxMoqyke5d/nJg/xg8aqXF9y oNFvPLIqV4DEGqM/ifUNB8ryjD8fL9MtZlj/Ul/QT+jD+iHdr+/Rd+k9eqerw+V1tblaXW6Xy+V0 OVzMRVyd5Y262U9wbDudXmlOhywdqu5lskQhf5Ax6mLkWWJv1VIsdXyYpuzqGZI6bdj/Ou4vU/dz 37Y3+Yep3ZEiqbFh+0B/qqxvHLPj/SlbT5/IFCmdz+Kqza6UKRnLlOmGvHS52+44gkZy+Vp3hVD6 xOVr2Szxdb2e8CU6hrYcPJp8TJFrlv2P/nxfrfbYP0kdz9i/6MnaMVnZ6Mmm7IvHjZOZCmtnnpFk hbVJy2YqjjxrHzkmrzvyySxi91QMp7kNMRKShphrmBgyhufJsIxhjxq5IHDkdktDzu0hQZULuj0q 56AyV1w3RpJFw1AZ/MBcV5n1APlKBicGbLIYDKqU36AZmaIZv6Em1qc64hyRCFcRiu91qiNO1WD2 vkeRQDOy/2FkvxpLo48yvJHp7P1vprMXmf7/8298uJ+WBian1kbG/SM5/8g4lLOvvv6Kz545bRjF qUnZYNhaMHf6zCvST43bk/7xpD3lTxrFgbXHNK/J5gF/skjWRsYyxTVzPCkGzIER/6lktpQ4nLH+ Z6zZh2NlDj+ms8Oys4wcK2E9ptmSzQk5liXHsuRYCTOhxhr5jjz36UzRRYazR042vMQ2u3GGc927 s8Nd3vyQPNCVQ7t9U90fOQi9Tjb3Z+1W/7DtgWRTxIpYsgnvM9nU9h+2qz44qquK38/33r27b/N2 s8kmS9LdJWwI2YbdhA1JYOs+mYDWTICK0/Ixy4eKUDoDDUmg1GmJUyXWZiT+QWudqYm2jZ3WKSEp 7RJAMg6i2OmIU0ah+kdG0bQMscwYg4Xsi+duEmSU93HPfefed8/H79xz7wV2wVxTybMrIwtG8Btz TRawvRWr0LxrkerUMlj/SMtgZMPmjSpUBu0d98esXV355hK0+vFmeOC7I//CfW9P1H7fq+N+V2dn Z7sqOmPtCLUMVm9oGVz+CGii6yBqe/Mm4C2d51Ga550QYnV2ZhQaY6AE7lDiVC2GY+BBW8KpSyf9 Wr9O1FGhYzhYXrfvLKzgh+GFcxw5OBSvzZ8iDg4vjKrzS8dwvH6WwvlU0aFgpA4kDDfAr4pGZ6nt rYFKb7S3prehP9pf09+gAffdAWCGBtRSOhQfoKgj1j7vCKh2bAJng1pK3k+GysrzgvtVJRbbFGvH eX/9v7PxvNPvOrZ9btT2/PAd84DM8tvRbOfZxljn/E+dc7/kGzvzvyh5sCoiOGlwOJ3CHmXVOwQ7 mp4labsQceZQJHXmYFRqaNwh9AyuRAIP4hJUErOmUrnUWmsy1ZpLoTTUrWkoahMRb8QbhQLSPJoO 09Fpm6M7KMxGVZ7/KYip5KNIoEdt8QT5JpxtKGGwzxjexjHPkq3vGYJj5BboNGQsAoefjG1yxEIs zAYZY6VyBP8M94N4kJxJtSodQHg6NZmZaKpNoEwk4tX0+uWLGpbRSmf8R7/fi0niGqvoXT2z6OIR pcGWmXFWzwdQObbsJYYn7G7wrfY9XPqy+WPPS76PPMLnLfRFvBW+7/hALDal2236vN4s6beLPabf 4zF90h/GCWxjuh73YoJhPT9pgXpgxszoe77iJBtYYLqzZLNthmRcEmkDTw74VdC4/MXJsD/ht/3U n8Vv2X6vN2TFLRK30tY6i1qqq6VkFRYUeFiBNaZfuRTAdgAHgiFPFkdsn3kQn7mEsI360HFArPSB D0/hL8y5o611YvLaWmsqX1FusXKxTFsKGLFcrO1aWhWZNq+vqZsvjXmesc5jbxOCT3hqE7gtUxgt Ll5Wt7w+WVmxUF9cCBjqy5fVoSK/rlUsXLQFl7gPtG58+tCOQ9uv9ZLx3D8e3PrV05g9ftR5fwbh Q+Xb9h3t7e5+IkLuOJ99FnduXj35/V9+BBheBLf/hVXm42upvYA2Yk1rZFIcp4RolTjME5zw48YH b6mYyqhASk2h9ER6ojZRCLGE4b2IS51xXEpNRaf/qUqU3zkgfo6PwLgS151C+swVWzQ0JbUqKHTl b1FVn9RsKODrir0+shjaoFiCqlk1r5JxdyNq4Gn3HrSH7KTf4LuNXfJjWvAlDRNDYCqFYLrAOIx0 P0K6JhgLc83PuWZIO1j+OZmHNFielFFCqcbUdtb2aDrhDHZyhjsQCKIs2QEbLRgDQqYLU5wli2wR EjghugQRI2QRYtBDhCH6S11bvzYLZGuuFEAEQEtya1fvbP47QAlOSadaJwCqeCoXi6UUhN3PnO9e WqKIbqVS3efPA4otgy5IkQ9AijyF6IwzZDA5MuOAa6ZPaKxRXZsA6dmMEIlQuHGkkFJ+zvlFV+7d Q84FshI3Vf/2Am51hvnI9PdIODcGs2bHzDjfyj9EQXTZbj0invc/X9yHfqj9Wlyml13/oiIqqtxV 5hL/kuJO3imOcEMv1AOBwkBgCammUa5X8TReh1/mL4mL9FcuHX/ZQngM3QQMVU71liTzVJpA8WY7 UFLDDI/t8SU9LdsK8LoCXGAXlSQLsrjKXuirkbTgU8+j6FMEQxIcTJThsqLF/Tou0EN6QqeQvXqG Fzy74e6kWGtlpjIwJSZQOjcJM+JaTFFVURkDZzIZzDVWEUZeC0XCgeIAr4QZoHktNRtYGodWOR/c cP7sfBc/jZPYfOPrdc6fgq8fePX93/QfeJMs2HLzE3wUb8Z78bG+rYNr9n/7unPbuX7jRZVtjiHE bkKEulCv/ZDBmW5ENV+I4wQ/DkHPBWVRgokUURcydK2Fki9K5MKuYNhMmLZJTSbCEH4J5SfywrC7 dsN84lOpF6xKtU6mJmfTr3q9TfFMm1phEJ8ZHSpv4tmZrqFgnpwobALIN0EnyiFaahPLvJGiyNx7 jKWnPyFjuTBdxkf+7Zy+5bTdAu3BBF6d1/5VOyoYl5QIGWW+4xRTijTOQXfdMEB3boS13+kYXP+C vdA215vbTfqk2WUSZUi/OWoyk7hmTRmFRDBrTOd/jWm1Mm37pzJza0k+2KGAYM/kraF5ayjECFij yP9YM2/Q3ftFXEWacZVzJXeGj+TOkc/fXkO+lTsMNvUALO+ATRTty3tpuC6Z5Cr4KqJ5aqf9gSTi Nl/Pu/gY5yG+nT/Jb3LWxSHYCEUGoVdhzRxEY4iOqhBWRl2CL4b2stq+uajbP2dKGhTD8AnaKv16 cBUfub0G9HgFIuN1/jYsvA/ZwfW6GpvBTEEG40Gd0Hth12pP3Qu7o8Ztzc0Nnbe66BWwd4y/fefh WyrqfoCQVgo2uvHPbZeLVhqVLsoAMwgDW5StSMrwipVJAWez4Tlqv1a2FLhQaMKQfxU3JGNCykJS xiwRkhXkQRYWcbmL7GY7xR55kDzFXhNvypNiRE6J27K4j/WKPnlBXJR/JFfYH8RVOU4+Zn8T16V5 UDwlnyM97DnRI3uJvtG1k+xhu8RueYAcYnozaWHNokU+ZjwmNkq9RMY9SbKCJcVKmfbolLiZJoQs IkEWEJDDV9o1kJXDzBCijjI/pQy2x7KOEqgSl0GpmxHilpC4dSPkwbBkmsO6xtkIacxjvSUzi3Fg w1eSvE639cMGNs4eBtecdYVdbpIljbYPwLWhI7KhE6oLubFbDWP+h+pqDW7iusJ77672IWlXK3n1 1tqSVrYM8gt7bdBg8BJA2BiwicHBaQxuMubhTscWAwE6AximPNKEFmhKUtopbpMCDZliTHFtHsOj bUjSHzDQ8Cil5OFpKBnDTCaTOiSWe+7KDCDP3jP37vXu3XO+853vELjKX6WHEwm5+r5cHfDLo+nR dHXAB1U2AQvyUJqUXBO7Lm/yaYJOmNSc0wRY5sc+PmYLEx5uNX8mNkD3pUkoESLoRRHk3INOISvi 0OnMcOZ25rPMv4GNffTdhylm67ebyAVxfhPyU4M4C+igIQk0y/tpL8+4AKEQauq4y1ZDcoV8NbHG RPggupzjFY7jaR5jjhbAXeAqmiEfzJAPZsrZS6YSe9XwG7ZGW5uN7rJ123CP7ZwNh21lNnCzMP5Q Yg2pqUkXyp/KbOsTmQ2lCnL7UXLDzMwJBHUsScG1o4R8PDhoUtlMM8+7+22VfLet0jzwtECJzjfB YKE9dDlt0EyK3sbv5nv4Pn6IZv9KX+L/ydNhupTX6al8A7+XPsD30Ef5Xvosb8sKgIpKHRsVpgD4 2BBLy3UcJgOnVMLKG4YQKdHxIhjM3ancMMxg4DHH+TDt5YpwnJuKK7gF2OBewM2coOAgNx/P5vZz R7i/45v4Lv6c+wbb4riQm8ut53Zy72KW5Pvqxx3QoxC3UGaESb4i55sojJegnMz10WMQ2GL66sMU ffq7WUTVkJoxAlF1UEFqnZHPWgaVQR89x4JWWK5ZsMuZL0oSFZRJ4XBQvCd+lPAuRESw6aT0GZ48 tUxtU7vUbtWiyo4nmST0ZAGZL6e/TkB5NCMyWm0qi2pSEdMmq0Ah9LgVlgXxp/kxVEIiDOMF2i/Q LSQ9u+mdF99Y0PHB+d8dfXnm0trKHstJT+T20R0Dq5zu0evMhUxbyYszGleKVngxqSLAwpSbilAj xtako87xHNdh67C/IxySerR+6YZgZXnW6uU91iopJaUcHC8LTkVSHIpcJVU55jjWShvkq1bbemG9 /2V1p7DTv11lBY8i2B1Sk7RW+rH0uvSWZJHCol0RRbvD7ha9nvwcWUFtSo+CFYUKR4i7wHFuipeI TItToixi8R/BeA/by55jL7MMu6NLQ2GtTMNaxP2k16KTXnrsNShUX7cOQ7vxqE6ZngOZPZpFNSC6 9QltbSqMdCtxaLnpT87j8eZE6BKsaU7nY69q+3DnFx91XzjftrHjeOY311YvWrq8+tZHHdUNtbE/ fW452fDh1t9fD03ZfiTzKao50hIZ/TW9ILbkmbnfs1sI488d+w/zJeizItRrTBt0Dqj9he8VMSDC 3CDC3L5Eu6W9cA27XlxTeNN+TbO3WBdLi6Mt2kr7cteKyKrCFUXr1O3qvojdpZGqkJunE2u0+wP6 wuhC7Xz0vMako2ltS3SL9kn0E41NWCeKsWhMS4q6Vm+tF2dFZ2odYru2QfxR9BXxJ9GD1kPi4WiO YBVENspqfqtf9ES5qGYVGeRt9hn+sN7pQ52+Az7sO4nbqSBknz2QzAuiYLFCU7WIpGNdIKyTRqsR tUGn1QN95znEo/uMEUjKDGKKJwq+B2PQGxk5Xt1bz8ULAiV58R65V8ZyPXrgzAbQX3xlHPP1TUuO UcaUlvkketAmgU2sJpownfiqNTGUtasTQ0De2ZQ1pUcU/BFUp4M/Lo/bz/pyklFwDxiYfdDnIrPL hsOVFMOupNW8HGTtriHZYU1MWn3kMiXL41/LeKo97rri5l+lXlVVEWayIpRj3YrXw5jIIQp1LgoH Duz42Z5p8/TB+207Nj/4A1KQl8vcyNm4cUtdadEU1Htp7Wtj1NnMvcw1dDu0Z+eGhXpd0FUytXnD H7v+svzLD8X0S5XRpJ5fuvyHZ17d9K8fIETwUwScM2h2UqsNrVQoY8osjUIX9Ci7BY5FFpzP0Jij eAFaGmYzqQ+o2LCyHHQ11GaSJTB10lIj7sLdeDdmsJ8ffXfc6wuXHMPgdVCqpLeDATqaoXHOqTYl DBBiJdGh6E5mPrMrs4C5MDLy7XR4bN3YXaaEmU5pVDlaYKzkAnzIonoCc4O1obr8W/Idp1DlT/mf K1juX1GwvWCv/+eBg4HB4MXA+0E7y4puD+v3xNkJ7hb/OrwdH2RPsO+x9rP6TRmrsfJJziIxZiRK 9JgRLYTBr+qdse9iOJZSCfbKJIc+TUWUKqu96jcqo6pFqIIyYNVB5cHRFkeMkLMmYgRlGHwBPTKA 15xgOLtoLSJcDPdMC7dNCzuKYIdhKLbcSQX8BKFQbMmzH7BjkBdjoDAMyaPbAw060tsgGj8tQwhV TIgs86I7XtTgXebt9NJef8WqGY/UJWA3PdxKWoBEdjZE1CZokwQ4FsqsiWiTlxLDpNsDJqIlOevv dCvBXRxQRhiJVjzeCAEey2pRE3yTqyYDGKEBQoT83QqgE5aqKlH7WOLKpdMD9XQwP3PPJnN07dut b59p/tXev81r7KxfhJZW3YtNXjJr3uwK2YY/Ldn/essrf84MvLZtXmiyn0+l+nY+v6s+lB8OLZw9 NXPFVe6LV09tLi+YHGsnVW8GxDoOsVaoEHprkJLHRoyULflLYb+4Tz5sOWQ9JZwSBwI8r6BaPIdN WRtyD4v9bH/govV9+zXrDfsI9z9RDDlCbiOo6m5DcuoO91n3JTftJv535NaYVvKCxbsMKByuRqlN wpLPRbim3x/UUYXL7ELVcLYbjU7I2kRx1vpCpjUcAIIeiBIlw7GXuVwQ1+OMzeUj8Y3ZOCqCSt2R BlCfgdLcZbmduQdymVxHhDdEh8771fEYJp5qS4eBagzFZxQqNT4j1wEDAMdHEGYyRc2oSUUuOATs cJHDwCbXOMCI7Xu0FcBhsov5DxTccCXJofu8xPQeF6zTzemMSA1ITtg/RKDRar5eMsBLEnmpRF4v GeAsynwoCINEAggRKlyF2c5QrQlkAcCEga5kqqKcoiMmieVkOcuLHyJf1X+PZr7YtgopV4eRix01 6K3ff+b5OL2++YXqaoSeLd3/2xN7bgOfJzIXM2f+T3a1wEZxXdF5s/PZ2Z3Z/87sz17vb2bHa7CN 1xgHJzuOzYaPUszHrpfG9SoJxg6psZNQklYBq1hAcYRLUmND+LioLaaljYMhspNIoUpbFKVVURsq hVYFtUQmVSygooY09rr3za5VpO5q9s17O5937z33nnNfHViNnv/OnoaGFzEWNuc2UFk978vRMi27 q2h/EenghZ7KfUJfJVWCgKENFaiKrDJoqIFsMGSsGVcm1qK2wFYf2B847SuFKnFlvKoMiElcF28s u8PPS6ZDkGdmXjCX8oJiESX3EoGH0uqJ4vhf1OOvh9li1100YebzY7w0H37oD/WxMpmHAef268na DmL5pfNBq4IHi2kJhoHZzXq8TKlqln2eSaRqnNfr8w1Woko0iSY1E1EVDTm8Fa11OhQwBL4GWgwE 2YxtXi+NM/Cdv1fQkDcTICwkXU3U4gPUEZZpvW0QiIZWTeiydrm6YtvUjkRXOdMGKlOiRWkxaash qwtBkqpDIKrISAlkudNV4BxI81dQvbEo3tJdE3MKuy/9+dWnEfrgN32IfaznvcHcv/4+tze77dCB zq1708oKd3FIrIx8881zFwevIjPy/WJo7on3332ubuqQhdx79sSPTv5k9ATE7w2glHPAJgbgk11T BAfeStlNKY1r4sg+bpy7xF3hbnN0kMtye7hRWKANDEvQlMFKII24QtyAO9tIRDA0w1ImkpURpXs8 FE1SXmMq77YEVmM6jwCTgP4y0DYsyPIV7oWEE/dRcLyBvLlp5KXeQVRu7qu1lPzVNQja/3a4aQp3 hpqK90c30WQfPU5foq/Qt2k6SGfpPfQoLNCwGQNhIg0yIhZ3Qnip/9tJ4d1V+ffS7/4nDe/aTRDM CKBZQSunCBXuboN3Qfbwbkbkk4akMelJRhrJVcZVnsYID92MuonLqn3qKfXHzBn2p/xF5iI/rl5R b6gWQi1Xm+CPD9TrKqNqvkAyBfM+/U+aDVGsr0jEMDSxmI+0Yoq12e2KPxCQFRO402qTHXZtS3XW jnaAcybJtGb1+eWiAKztCKBsAAVg7UJMlhUAqnqeIBS9eHIpPGrLYd8KXKpo9XDUwRFVkor2yKPJ cuUPynXFYFWCSp9iIJQSpUJZUCjFG/9H3SJlFWRPHuV1s1CnQADM9rbhQXceBA9/Mfixks6rZ/RC AvMVSjhDbkxYkk5bkugGFycVDF9GP5UXT3cjw8CljiMV6dNP7TwdL8pNFykbVnYuzU0Xp5bXdy7J TVPy4bObm5s3tz/VODKfIdtPLq1bPXAkR5LpN7eUpfuPzs9BzA6DHspAzETilOZhnZJzi7HTSE1S CKJlazQ2Wj+30Qx2cZGdtQgMbzYjgAeSRUIriSbfItACPARyH7wmhqPJH3hGPWSP546HvO1BHpNZ 5i3Yv9Cr6IQCt4zy6A7UJ69UwBT4q+ApoAmYzOoLuqf0riM1U+gsQg8bb9edVEy6qUxuOrqhds1L CQA/PfCntmPrg2Txua0rmvrP54KUfPxCQ2f/d3Gt3Qi8ewwsFQgvMaytvoWmjfed993UZfIWNJte 2suRGVuLs0XMeIbJEWbEOMxPclfJv9B/5a7y0/Q0c0uwnTF+TP6O+dD4W57eafw+02802HUUmiXs IhfFumpZX9bf4yf9lhDh9bXWFwofLnu4AZ3RzVmsaFyXrcPRIXZ5KITLGUjkpAPMItwuIhKOyrGH atfGg/PH76Jk7qMvXs/dP4hKjnR3Dw11dx8hw68h5mDu8u27uQ/7F8ZOjo2NHh8bw/YO5J6nhsFe GxEgjmlLVzhXO0lH0lAr1DqT/kbDGmGNs9H/pZ9rYVpMGUeL2OLJBGbZL/1GyB8ftopmXdgq0Wy2 WS1SyOjrKUbFdtVisco2G04bzdxD9OHOoyiVt7P3yZk6CKTt5qK5+QKva18wD9fwDqbD1AU2d3i6 AnoNx3DHNtttYLOs2EPoIasHEFP1y+emEJmbm2odXA8hFg91PP29fc9sOwChbXo297fcfG4292m6 ef5zw9TEz09MnDl9CgC5nyAMNbrtY1p8mEacBW2iO+idtKHc0WrptPQ4KBNn5YM8Ocgv8GSKX8+T /CS5S1NZFvBtIBlTnOBsXAW0BhTn2+M45SDbHXscbzmuOCiHjZCRQbefJPugXSOR156aQgEi74SH 4Dzb5n3yJuHRa/cMoLt2Wd4VvcS6cWnTuvHqDVta3zYtWwF+COmYBk9IrA5yOxrFiG7Y3pjNfP2J R1duLKfk4e2N1f9eWv+z3F2wsQLwbAMbS8lu7SRjZyJGRbJLkRHHiGtYGSrlWFfaRTreE6Ysl0Of RR4Is2FGFZqFrcKQedhxJjzFs/URLdoobws/K+937HftC++NcjXyKiZtXiust6ZDj0MfG1XkGr46 VB2ujlRHWcZE27mQR1D4cDgcYaNhrexF/mXXK+5vqztLD7j7S4+5h0ovhC9EhD40KL3mOVp6tnS8 jIEO8WOsLkKFEfeUE8VRPL8xEYzm516fPtf8cLJdQMvD6fCI8MPwr8OfhJlQmBcoykcU9AtRhZXM hLQkhQpST5+HY0k8akXAFgSqQBpqQlQW9aE7yEAgG8yyiNKvdIpwJUJaD0GhduoORVLpuFnU4NFi laTBcyUNHipp1TVJCXdOkhZT4Qeea5WCepNCSc0+Deqd1YeafAs+0pd2slJI1EKRpKgFgsmgiK6L SKwyhppigzEypnmKkjEf7pA0CcilqQxVlKHyMlRWHKqwIVsVChEFAtJHuCRPv5wA9Jt4eRIjaw5I RW+HCoUy0YtnQDeQaKALcCdUkFF4ei9RoCIsfKXaglpO5NuiXvi0tenSObrwkcaZHSlrHH4gAl+8 I9TyLr4Wn57nayE2/3zbXKvLYwQKGWqXMybqoqsaaEkBgEArhZmKzktitwu0JtCWC3dZFcjn6H7m WzUxl3tN7tw3dl/77Non8dx9e3vrjoqSgIx+lWm9d/vTeVSe2NgcD5SXuF32dY+1HD34/qGBysce D4qRYnegY+26fa//cRwQH1y4RR6mT0D9/r2mlhAgj02q9ZH/sl9+oXEUcRz/zu7e3v65P3uXuezd NtpL2l6OXsJdSM6YeJBrzZF6bXppTJSIoUlsK4WDStAgxYdWUBF8CIIvfbGI4KOhpRj7IHkoKKVU 0RfxQYMVHwRLkfhS2jt/c3upSaucQhGE/S2fmd/M/nbu5jczv5kJlUMzYX8ihrjcHoMdbePMjkqc xWXdb/gDcTHQYdjn7RVbnqNsjW6Yq0y5EGMivF1ETPWLMBcKmHrWyIJO4kdpRZNFMR2XU3Z0OjbC 3+cfc3mOn+HL/Ct+i/vALZ7kOa7whPPq+c2N/+DKIK3pJ2hNfwpeX3t8pjB+h/b8jdmCtZEQYYBC IUVHMv2JtvxIf5hExAMW2xXhDZ/awml0R81HduX783si0uk1s7ujuxxfeO3Q6SFTP3uWOUpqvTb1 eqZjx3d7+4+U+t5jX65/82HtbfKPSXv5c0qK8pvFmC/tZAf8IlFFoolEXq1/e5HyxiEz6QwPnFOY KpuaZgTMGItJUdnRHaMLvebnZoAm4K1imu6IBnwmR8Lcg73mAIbNt6CbMBTT0HVJYirp+lBQtBjv SA+YwZ3BXLAYVIK27VjGiFExZGNVyhVNRRoylRGlosjKZSlHB4czxXAgD5akhSqzROAK+TEhHJmJ j/86SxF0NnG4dHz050a5cW4Sh6boEKObgZjFmVlxOWtM6k7W2WbTJWCwrZOxT2pTrPuLYVsNWVdZ Z40ccvfHS6X23l7pUToRb0r1IXNzO9LcX3D571F2u/ied1GdLVB7/qUtfA3o9I257BKYcwleASyF OPfvib65Hf6uS/tkk40/sem3EpyoAQ79tx2/uHRcB3auAcl1ly7Vw8PDw8PDw8PDw8PDw8PDw8Pj /wkkMAjhkIXGHEJFS5Hvr+BEXCiPuOXdSCENZHqAbK4P/cg/NrjVfpQ4gDIOAZWJI5NPY/qZZzHT +of/K1GwQmkKSdJUSvuQxzD24UmU8BQOYwJTmMdxvIiTeAkvY6leJ/vtdgeodxOYvGdXxaKwq99o /TRH5Z/IA0PxgGg40WxPRoRS1uxhhB5XV0nrEjNA0ammi4bL1SWEMN3UZap/oakrpL/R1FXSPxod q5TKY5l9iyfnqz37T1WPta6gKTCGCrmpTHmGXLZILponJ/VgP05RfoxcJxz3Cunz9La1/cOwEB7x WfgNBeqtjzxgIUuGUMetKvVYEo5jy/RGU0gTpc0cJ6QofX5P7h+GERIUaY4saaKZa9qCIjVHg/LP 3rkWPBou/K4ltIb1BzcKjaV04eAP39++feeuVdIWqCjGp9HyHwIMAFHe1DoKZW5kc3RyZWFtDWVu ZG9iag0yNjIgMCBvYmoNPDwgL0xlbmd0aCAxMDIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIkAVwCo/wAAAAAAzMXF8wICzBAQzzg418wAAAMDAxgY0FBQ2wMDzAQEzA8PzyYm00VF 2Wtr4Wlp4EhI2i0t1Rwc0RISzwsLzgYGzQoKzh0d0TQ01ltb3UtL2xYW0AIMABrlH5sKZW5kc3Ry ZWFtDWVuZG9iag0yNjMgMCBvYmoNPDwgL0xlbmd0aCA0MyA+PiANc3RyZWFtDQoAAAAAAMzFxfME BMwZGdFUVNzMAAADA8wXF9BNTdpvb+ErK9MLC84BAQEKZW5kc3RyZWFtDWVuZG9iag0yNjQgMCBv YmoNPDwgL0xlbmd0aCA2MSA+PiANc3RyZWFtDQoAAAAAAMzFxfMEBMwZGdFUVNzMAAABAcwCAswD A8wICM0cHNFXV90KCs4lJdJbW95vb+EyMtUREc8HB80KZW5kc3RyZWFtDWVuZG9iag0yNjUgMCBv YmoNPDwgL0xlbmd0aCAzNyA+PiANc3RyZWFtDQoAAAAAAMzFxfMEBMwZGdFUVNzMAAAFBc0YGNBG RtlJSdoBAcwKZW5kc3RyZWFtDWVuZG9iag0yNjYgMCBvYmoNPDwgL0xlbmd0aCA3NiA+PiANc3Ry ZWFtDQoAAAAAAMzFxfMCAswICM0QEM8WFtAYGNAZGdE4ONfMAAABAQEEBAQLC84XF9AqKtNISNpp aeBra+FXV9xQUNtnZ98/P9cdHdEBAcwKZW5kc3RyZWFtDWVuZG9iag0yNjcgMCBvYmoNPDwgL0xl bmd0aCA0MyA+PiANc3RyZWFtDQoAAAAAAMzFxfMEBMwZGdFUVNzMAAADA8wTE89CQtlvb+ErK9ML C84BAQEKZW5kc3RyZWFtDWVuZG9iag0yNjggMCBvYmoNPDwgL0xlbmd0aCA0NiA+PiANc3RyZWFt DQoAAAAAAMzFxfMEBMwZGdFUVNzMAAABAQEKCs4pKdNpaeB1deI0NNYQEM4DAwMKZW5kc3RyZWFt DWVuZG9iag0yNjkgMCBvYmoNPDwgL0xlbmd0aCAxMDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIkAXQCi/wAAAAAAzMXF8wQEzBkZ0VRU3MwAAAEBAQgIzRwc0TY21kpK2lFR21JS 21VV3GNj34uL5wEBzAQEBBAQzi4u1V9f3i8v1RERzwUFzQUFBSws1E9P2klJ2SMj0wkJzQIMABoy IdQKZW5kc3RyZWFtDWVuZG9iag0yNzAgMCBvYmoNPDwgL0xlbmd0aCAxMDMgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl6+fIlAwicOXr0MxPTGQ6OswIC58XELkhIXJCUvMjIeIaF 5QwX1zkhofMyMhd1dK44ONzw978dFXUvN/fhGQaGzMwHERF3goPv+PjcsrO7rqV1RVz8Ajf3OUZG RoAAAwA3KyLICmVuZHN0cmVhbQ1lbmRvYmoNMjcxIDAgb2JqDTw8IC9MZW5ndGggNDMgPj4gDXN0 cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAAAQEBCgrOJyfTXV3eRkbZFxfQBAQECmVuZHN0cmVh bQ1lbmRvYmoNMjcyIDAgb2JqDTw8IC9MZW5ndGggOTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIkAUQCu/wAAAAAAzMXF8wQEzBkZ0VRU3MwAAAICzAgIzRAQzxYW0BgY0Bwc0S8v 1WVl4AMDAw8Pzyws1GBg32Ji3xAQzg4Ozh8f0iYm0h4e0g0NzgMDzAIMAGa8HCEKZW5kc3RyZWFt DWVuZG9iag0yNzMgMCBvYmoNPDwgL0xlbmd0aCA0MCA+PiANc3RyZWFtDQoAAAAAAMzFxfMEBMwZ GdFUVNzMAAAXF9BGRtlcXN0nJ9MKCs4BAQEKZW5kc3RyZWFtDWVuZG9iag0yNzQgMCBvYmoNPDwg L0xlbmd0aCA3ID4+IA1zdHJlYW0NCgAAAAAAzAplbmRzdHJlYW0NZW5kb2JqDTI3NSAwIG9iag08 PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0NCgAAAAAAzMXF8wplbmRzdHJlYW0NZW5kb2JqDTI3NiAw IG9iag08PCAvTGVuZ3RoIDc5ID4+IA1zdHJlYW0NCtTU1AAAAAAAzMXF8wEBzAICzAMDzAQEzAUF zQoKzhISzxcX0B4e0iws1D8/2EtL2k9P2lBQ3E5O2kpK2j4+2Csr1BkZ0RYW0BERzwEBAQplbmRz dHJlYW0NZW5kb2JqDTI3NyAwIG9iag08PCAvTGVuZ3RoIDc5ID4+IA1zdHJlYW0NCgAAAAAAzMXF 8wEBzAICzAMDzAQEzAgIzRwc0TY21kpK2lFR21JS21RU3AsLzhcX0Ckp00FB2VVV3G1t4MwAAGlp 4EhI2isr1BYW0AkJzQplbmRzdHJlYW0NZW5kb2JqDTI3OCAwIG9iag08PCAvRmlsdGVyIC9GbGF0 ZURlY29kZSAvTGVuZ3RoIDc2NTIgL0xlbmd0aDEgMTg4NDQgPj4gDXN0cmVhbQ0KSIlcVQlUlccV /u7M/O8hxBXxEbXy4MmigCzBDYmi8OApLrigYJPIQ2QT5KmIS03UEJcDLokHt3OUaA2BBKsPU40a 26BH0xhj3Nca0apxabXWmNQe9U0vNO1J+n/n/8/9Z+7M/ebOnW9AANpiMSTSx4yPis1Jy+wKDO/M raOnljhdGG8MBVIcACVMLS+zfj/qyhLuuwqYj+S58kv6z6mLAry2Asbs/OL5efVzq28CMSvZp7xg mjP3S++/sDk8lz/9CrjBt1fHWqBdy/w9C0rK5v1zXcwu/h8AdI4vLp3qhMjIBmIV/yeXOOe5fGZ3 2AE4nrC/dYazZFrCoQwnkPoB80l3lc4uY978pL7T0u+aNc11Ji+cfYPKgPb+xmpmNRIB/HaX1egG 6Bv83uL3rmeEfm5Mh81TpK9LXx79u59eIBjr8T564hHF4DCaMAIfYijSUY1UnMQutMN8Og4FG5JR j2AKgEAKLGRgEy7jNczCbVxHGNJwjTrxPHa40AUD9T3+pmGF3s9e3kjCThygYhqPKLYdIoLCOfIa 3QQLwvQJfYn/tuA29dSNcLD1HToiFIvwHjqhCF/p5y0ZRA7qaCHdQyCyUaXiVKWejkHYg/OUxtYo zDcutdmDYh61nSzUpJv1HfxREabxTG9jBTPejSbRRyYZW2FFCF7FaDi59ze4TL4UIxN1qB6mN3Fr HR6LcPGFNDOPcAzHFKzCNs7GBdzCD+RDfWkLNTBO00PjEnNLwxws4Lrawtmrww7spxiKERZh4WxZ 0AsZ3LcGtRz/E5yiNMqiJjoka41ozxDdWfvpO1qjNzKZ4fs4xDGeUDT7cAQZJMtUD1VmxL5YwivM xWacwmnmcY3z/gOeUm/GDfGWWKQn6Xp9m7l4IQADMBaTUYpyzMVveVcP4wj+Qc9EG/Y8qY4aC4xH ei3nNgTDmPsY9h7Pc1fxLu3GPsYFXmVHsvIqBtBoGkf5tIbW0z66TJeFSQSKmeK+dMvj8qrqZxg6 nmfqgh4c14ZJKOAdeIuzvZbXW4+jOEZ+FEKRvKILPP5HMUgkM7aLk+KaXCrXqOfGMs91z189z3Ql zFxlqZyHOfiYs/B36sIcelERzaabzPxd8XvZTnaQNtlXDpUTZJZcIavll/IbNUs1qCvGcMNpNJid nhme0zpNt5wSgol5hSICcejP9ZPH1TSd+bkYs7AQS1CJ1Vwva7EVDbzuz3EM5/Et/sY7AApkzoUc vYSrbimtZmyiHXSIjtIxukE/tkAEMcJEPzFEJIkUkS+WMqrFKXFB3JXd5VS5SC5m1Mi98rKCUkob sQyHUWXUmY6bw8wOc47X188fvOj9IuvFNQ88XT2/9qz3HPLc0RP1fOYfjEj0YabLmeUmrsFaxsdc iXvxBb7GxVauj0mQwRXvTzauhgjetSGUSsMZo2gsI4MxiSYznJRDBYxFtJjepgp6h1bRulZs5LXV 0ke0l/EpHWCcp2b6ju7TY8FFLCRXc7AIFVFiIK80SaSKMWIcI1+UMlxilijnHaoTn4j94oL0lcEy UjrlTLlJ7pSH5Tn5LyVUhIpSCWqiylcV6qQ6rS6pZ0aAYTcKjBrjsKmbKc6UYSoybTTtMt01PTeb zOnmHPNC8zmz9gpmtfoTr3sPfv5EmU7SbKOzmiea+Vz4S5exnDI4YyYxQRbL1fKMkUePpJWuUKUs lNP1dpkinspSmig+pyAZYMTLPKyEpgZxQzwRd5QfTRD3KEy9R5+KUpkkTC1BjLPKT1UYdwFxEfHi TWoSR2WFrNB/QLxRQ81GjTgNq7oufNHMp3q52MCDvhGFogqZKs54hkLO+0fGPM73YLGCestzqga3 pU18T49oPavGCRqheoo3xEBqYMV9QT3wgGbCReuQSJ/Rt7QPRPWyjkaKl3i33KIt9edr7IQMpHPS G1ktHClE+FG6eCQy5EHTKdmXiFXiDBaQpGiunf8+HszgE1AtQlnT7KwmZykW/tjAev/Ec7BFsY1L RhXX2TYZgXGIxuviOOL5bNxmZGIZYnGAa3AFosVGLNSLKZd1fxTrp8A+KkIU+bBaWpjbIr4vuogg 1sIpHPUp6/9XrPpp9BBzyconqwlhqqVnpbKzMmWz/lYxcvE6/23GWtMe4yzGkAVQVk8NV/lVvMF3 zk2O3xUJzG8ytqkIZm1lZZ7JIzZ7HEhkLMNxEniTOQ/mc56uHKy863URr7CQ76iRfCceQ6HegCTe u3G6Qldhit6mX0M+xut61t9yvRv9sNzIEhONcBXHGnuMjvB99GeqYt124ArrUTD54z5jJzMabHyG SnWRtXOIXqnPw4/zEcQZyuFb9BZK8JDz5pBNeMUzWjTqFOniG6oZY3WdDiBvFOhiVt6DqDUbrD2L 0cOoTUxMHDL41YRB8QMH9O/XN+6V2JjoqD6REeG9e4WFhgT3tAUFWgN6/Kp7t64v+1u6dPbt1LFD +3ZtX/LxbuNlNhlKCkKE3ZaSbXWHZLtViM3hiGz5tzm5wfmzhmy3lZtSfunjtma3ull/6ZnInnn/ 55n4H8/E/3lSB2sCEiIjrHab1X0i2WbdR5PHZrK9KtmWZXU/aLVHtdrvttpt2Q4M5AFWu39BstVN 2Va7O6W8oNKenczTNfp4J9mSpnlHRqDR24dNH7bcFpurkSyDqdUQFnt8o4BXWybl7mpLtrtftiW3 MHDLYLsz150+NtOe3C0wMCsywk1JU205btiGuduHt7ogqTWM2/Rv7qs1NqrjCp975+4jxMZr87YN 2fVljfzCPGrDmgKb2LsxmIb4gdl1nXYNJsK4Sah4pLRRMEqA5AJtSNKIIIIQalOE23ANpDWthIwq hNIKaFUZlEfblIS2tAlECCpBVN9+Z+7eZb2QQqv+quVvz8yceZw58505c2tNj1zG38W7oW3+vvIB Y3u/j5YlyrI69c6O9pgpOuK8Rm4Z1q0zx3374/G3qpg8rza2NV1bIIzI+C4/Vw1jq9/c1xhL1wb4 Nx7HHKYajCaMKBbeDhc2NPuxlro5HjOVzVjQz/vgPdm7W6FHuCWxym/epz+krzRWJXAw+YZJTRsC h/Pzw8esDyk/4jdaYnrAnF+gxzvqCvtGk9G04ciEsH/CcE1FeZ8v13Zr38icZCErO72wIqWTJdmd Sw1NKb8qbJG+AHQw/cv9sCSmY0+z+WfFbDKWz0Y3/MUVjDI7cR5d5n21CcNXg3YfjzddQZ/uN64T zl//9JPhLR3JFnfQd524yCxJEQ16p2yWlZmlpUwQTy1OFDbOk/WqivL1/aqpr/b5IeA+ehS+7YjX VML5gQAf77b+MC1DxexpjNl1Py0rOEzhyrK4qSZYM+BoxixhTY+jSQ1P6ODxUeIvizGmtzj1n+Mb OyqyssZUxv4b9Qpb39CsNzS2xfwRI5H0bUPLsJqtn53SJUuKrYDDTS0ITy3QQb2mthg34N8VjOqR rkQ9Qg02mqNqY6JAjdsltUDIqcDf9tTMXIll8Vxa0C3539nv8YLAskXxR01fot7+jY8IBO5xUL/1 GY+S4taw5J7MmrLh9TnD6sPMyzIEDNaK1YaWNsMYMUwXxWVlGFHdHzUSRke/1bNM9/t045iIiZix OpJwjr/f+vm2AjO6PY5NrFRqKviNSJ7AUISW+ujztUNNvhp5WGl/rmx3SCnkkuoAr1NRR5vx4RYE vuE+SPXuEDLcN6kRuhZgKtp3as9REP2fRL0ZcqcaIoH2hcBnQDnQDPiBZUAMWAQ8AzSirwl8l+dw IHZQu+dr1OE6RT5XKxUBC1HWtY+oVFtDAZTruY71ZoqJVIpyEXQlnonoe8q6yHr0K5L9WjFuDfVA Pw/1+4E8zw4qgMwBRqE9H/McYJshG8QJ3qt1BeX1sGMByp9DRmFrHeQitC9GeS6QjTFfVkPWcpRz UZ4L3+SinAVEMO4Gj0H/bNjYCf1o1FXui3WzIQu4L+YsEeeVAmU33iPnqU9rodHQj5TAvnnPzp7Y frbpCxBl+9Jh2yfBtqq3bLsNagZWiJnyrDYl97pHPU2rxT7rKsq6ezRFGJ7zNAn7+wQIaZ00wTPR +itsXOA6SlWoe4HxEjznHtoirlEYujL3a+BNJ81Tp0NRZd1Uv0MT3UF6GPuFv2kKbI8z98CFyejX LMd30iTtIuWjHGZ4if6c8hN8g7NvgKyF3y97yfoUc9QyMM8x4ATGj8P6lewDPneldagXfS9B9zSw BhyZAIyDfpvkMMbweKzzIK9hnwP5JAcB5h4ww0HyfBzc70D6/6DEWGAcMAvgdV8DfgE8ArzKfTDv WPSfBDueZc4wN5kfzA3Jf/BJcpbPcQ18wxyzY+aH6uP0AjAaKMeDfksSpegr44XPkW3mWOC5mVvM GUdCX2zzXrnC+2ROpUndVS7XljHI3EqTJcx9liIs91CiDlA1c9b2tSOlDRGOR44JRzr2cHzKGIEU 3TSKfcfn7kjHFym5j4LQLXK9Sw9r02mpOAn+t6P8KOQs+GevjMEr2vfpY3UzqZ4BKsdZcuy+niF3 MTyDyirMNwBfFmun6XUpB9UibVBxuXqtS65e9VkbTjldZkIZsHUsGem6/7T9v4F6ztVLj6P8N9eg ZWmD9DL2Sp6/K9MAvyPRfhjoAUq9Zcoub7fS71lCPvDmGvCUFsa3X5hmaQM0Xxsj4y6I9iWYu1Lr pjkYJ/CV86JYQvvdvfQlMYhzxFrqOXqOwfNDrk7xKJNzt3NJSoevd5AcA9mOlDEVsv4g4ypk/VHG ZMgasiWFODfw/SzzA8m7Odfha4qXb1CxuJ7GzwyepvFzDsb5MnmZJkeyTOaWbCdOMWYs5xrev7wf W2U8yXsOusNO/0yZGn+Q+tWD1vvyHj5NbU5cA9OBIPS/TN4juIdx3pwzd1jt7qetdrHQasc+f+re CnnVOqJOsfpSOTVIM5J3Wb6TS9lPrtNUmMqjQVqcvM+CnE+1A8jhdh4dJfPnX2i866q822ZIezkO OQYrce9NQR7/h3VTy6MnxYtEAnHJ7eBII+s0L40Rf8Kdu5DWir3W78ROeQdFxBDFRRliGGPhs/Eu lQpdddSAMSTn4z6Q3Mb2uzXwk++CetRxVs69zGfvvknZwBTXZdxHrehzUO41KO/xXTSZ/SDHrkNe wVyeMsrTVCpL9gnKMU/gvSD9gTswzRfJ3DyP53Q3Sc7myDEzrZvePAoxXG9SNdYPyrXqqcYbomJX q3VZvivy6BFxiqaJenoA5XzJ+63IUSXIl/XIj4D4CBgCN312XeZqKa0bMt9vlPk8y1VJS+V7gnVu muQuoakMTYcuQRXiTczzFHh1E+W3LEu+D35Pubw22qPJ9wm/E1QZL7/FuHeogmOMbZD5hu3ZDb6d pQc4J3r2w4cjOAYVBf4uTObBPNRVyO+l4aVkW6EtlYD6LrVKXQt9qB5XD6nHrW5+B4r36OviBzi/ QxQQbcjfJ5Eb5yCHL4SvfkMxcQblIrTvBdbj7beWcrQc6hQX0G8GdKsx7jTm2A89YwvGfAD5Fs0V v6IuMYD3wQV+I1BAWwf5GFBHtcqPqVu9Qd3uauTkOdYbcn7GWuurEvuRNy8kxyYhbXVwJ5s34G13 B3ulrel2so13sI/n4HnlOPTRNMohsj4AgrYcalR3UC+wT30Pfb9CG5QDeObvoahyEdiTxE+oXso+ oBExVqU8A0zVquhnwCaUyyGPA4fsOu0G3gc2Y+4TkEfc+FRgqA+Bz5Bo2wvsAn7t6NLBa92pPR2u Ahpef5t6GMo165+MzP7aJqrGetXaXCKGuEQvMdwbqc2zntoE7gdtEubMqGOdGdrbtOpu9twNylma Jn1oI3wve7xXcOxyfv5fzXevwPluBB6TNlzGfWxzaKRyjoogWyFbxTr6FgP1CtTjjj+Va+Aa4wC9 IttT52e3gyskOGdntGfWM8/1bnX1CN66aXB4kOLDy/Q8Q5uP/kBm3fsOPc9wn4Tu5O117Ud3QRve KLulTSQ5llF3L6YnGOpk2Jovx2xnpOpn8a0BcF85Ppt2MGTsAupR6mKk9FW0jZHm12r2K9aUeud8 nHPJPB/YF9bOAG14z56haZDNkA86MsXv5H0xjPONNt9Tdb5LLmb0uRUTt2IDsfJFc/4/4V+0V21s U9cZPuce59rG3NikgQIhOU5uDAkxTTDrwodbXwcbljhq0sIgyaY6H6RUFJQwGNW6ZAFtbLC2SzYY UFhJ2jVsapLl5hqoU9iIOq1Vq2pk0qRNE4Kw8W8/lrYbU7dA9pxjhw8t1Vqps/U8zznv+573Pff4 +N5z8d95D3gHePv/XYvi/iDuER5AnlHXkaj6MM6eWwheV2+9T8hUNvQBPBfwz5uaQPv3aDcDJWi/ AdsJ6CEo0kzdhn0azxFspdunbYtxfifkEIAct9tTY2/dBJ5N5bh1gZB//zGNvanxUy8AG+DDLpw6 C2D3Tv0CiGDMTJ4for8b+mv0N6ZyTaF96zrwPSAGHE/p1PcB4Xeixh/EeWSW99DPVT/p/ePTavo9 Izij//UO8Vl03afS+945Zn7//6Uz7xKzqFyH9PzVe+bzSe849yn2jzP1JWR0eoxdT0SjASMJLXlI qlVUHJAOa/GSwC/ZdWWQLCMchmvWghzpuWpVVKQbX1ydaiSWrwhcC89hV8nfAIVdZddIUWpUouih wGRYg4GybxE3pYSTPpxkTUAhBvtTonBpoPcSex/+99i7ZJsc9q6lzQsg4TvsDZKFE+95di7tOZfI nBcg4T1YBErGwOPABDAJ2Egb+xnpArqBYQBHMDAHSoEaYWEDbADz7Md4N7gUaAO6ARvZzF6H/RnB 7OdsBynA2BfYUTIf+jw7IvU16GLoq7DnQV9BX2hvun8KKvwn0/aX0F8APZHW47DnQI+hL/TH6f4+ PBTEuL1p7WN7rDzuCefB7wXKAIbWUbSOYumOiqc1mLJvs52y0gg0AN2VUixXp5Wvy9+oM/HgokAf lrQTS9+JlevEynUSG1wdMzEdqZgVrAMxHYjpQEwHVqWM7UG9PWL7gD2AF2BY9z1Yd2E3wWPAuLR/ B9wD9IkeexbrWIxZHWY7rCKOTbY9scYIhC6wp7DUBnsqsSg30H2355wjNiI0M61uEdsqva0J51xh bU0szk0pop4JZ7IW8k1AIdngQuALQASwsRarsJS/yR4juxzEyORdShfrsnVl2MoiNOsSC5Ba3Fs5 yWIrSBABxTwepOWNznbnfifzOL3OMqfhrHVmtLEu1s0YZ6UsxGpYnGUkp8cs+9pVEGOjunZVj6vP ZbrGXOOuDFMdU8fVCXVSzfCqZaqh1qqNaru6X+1R+1Rnj9pjVxpd7a79LuZxeV1lLsNV68rgdtoX PsiaxVMD7AHagR7AhjWOw+5lTwJx/BpxLMWT4gwKJuh5gHG0J6AZ6LkR50acG1Y3rG5YCVh4aoFG oD3tVe94ZsaI+EnhAcRxJRPWTKztBHhStIAq9DT0NPQ0RI0rU5ihB+wFagEmbRMAdg14xleW9jcC qvRPypgZnyHGKlNG07KxYmoW075i2lNMjWAoHDAKQFlZWXE97osXxfttbXqbr62ord9Wo9f4aopq +m0hPeQLFYX6baV6qa+0qLTfxnXu40W839ZdPVx9qfpytS1e3VbdVc3K8dMlrJKygNQCn9Bz1qLF gXJ3+BG8G1ISB/cC1wBG3GAOlAIhoA3IUIaldQjWIViHSA0QBzIwakjcYsA87RP2XukTLeFX7vMz XPygtXZVTbgat9040Asw5B6Ef1BGp1rD0m6CJ6S9Jh3fJ+0iigMz48RNsEHe7hrwN2wgISAOtAMZ 5DLbSq4ByA7mQDswDNhYA75b2VZlCN9BZZD5DW3lfE4WLMCRJmuewxP2KHOxFzQcgwWfkHxYckhy oZFZpd2s0n5VpX23SluGhlJEwnAclZxvuMLa2bBWE9aKwxqyPUjyiabMl6wKpn+V/Jhkv5Gdr32c r32Ur32Qr72cr+3O1x7JF+OW4D+sKdmSXYLpMclVkpcaLq69zbWtXCvnWlijpymqkwrJeZJzBNMP z7ojbuK8QD8kEWSiVrCYJxUihU5bwTDkthXcCLllBU9D/mUFj/CL9GMqH230plV4g4fn07/TSpvo f5TWD2glGYBOQrdDz5Ag9UFfs4IHRPxPMf4k+q+SAoeIf4XUynG9tFLaX06P+4nlb0bVU5b/G6h6 kvhl1eOW/wasRyz/YciPLP9OSLflExPcYQWX8/A8up0UKiK2hfgUMZPqdMUvIfNO6MbU4KjlF6Mi okCSrrf0lZBlYpYXqU5qZTlu6fIic4kuUywhupx0DvFJzaRuOXmNFEh1WPoBZFHP+m7wfwYviAsn /6Bu6zT/y0Vc3xZ0/0wrrQH+u1GxXBa/7E9S33n+W/0C/01hkm6x+Jg/6YDjkj+p0HN8BItsIlah 5/mwfzsf0qW3X4cXP3VvcAU/pTfwl3zoW/yA/6KYBtmFK94Cd73/UV4dHOAbfEkKtxFEMWMOX6t/ ja+BeXWSViYG+MrCpJhKGXIMnOfLUXGpLqfy5fI3lYeJnX7d8Nv32pvtW+yP29fZV9lX2L32XPsS e7Yjy+FxZDrmOuY4HA7VYXMoDuLITk5PGDjWU5KteoSoNsE22fYogkHi7q9Qh4L/jvkAiymxTRXU zIqR2OYKs7wklrRPP2GuLomZjtqv1I1Q+oN69EzlUJKSzXXYoMJ0MMfMWl83SigtPfhijtCOgy/W 19OYOdZCYs1e8+YmXMecxxvMDL1iIVmwL7QwlPXovDUbIrNQY5pL7n4Wltz7WZhrHottqjNfz603 A6IxnVsfMzdu8n61blTZrbRFI6NKu5D6ulH6nLI7+oSw0+ci9XfCSIHSjjCcydtTYQlSIMJIAU3I sGoZhm1aEI2MFBSkgt6ilSII2+ctGbQ9lasQJZCrVgjClDxSKHMVKnkiDPshlcx9b7K5hLplMvdc IpMtEUEjPh9C/D4RMlLuQ8CIr1y6B+66dV9qOvXEJ+v4aL2sQ+ndmKJUDHZBOkZxIKbk8/y0VnyG YJpourKtJdqqRxv1aCvQaD6/7+mF5v5mr3dk2xXh8JpsaWNzy9NCm1rNK3prxNymR7wjTS2zuFuE u0mPjJCW6Oa6kRajNWI1GU1RvSlSnzjTtT52X63Dd2qt75olWZdItl7UOhObxR0T7jOiVkzUiola /2G3fEKiiOI4/nszu+uotY4WMSXB7khgDEu1EkQ9cnfd1cPiauphV6SS0lhKN5yZuuWha2DQqS5C QXRr0woxUDHoEIWHbp0Cb12C/h1Sse+bmYSC0EOX4P2Yz+/3e7/3Zt7w+7038x6mHnpz5fsyLN9b fKJRptQx5NtZpb4O++F8c7yU2adfPe1tjlNx40bzfIjw26q3StVdLZnqbiC6EulEWnRhd4quKMIN QZdx41S8eZ49Crp0hBtbMmSRkStnty7bth2B61rQjmt4MQebNt6fr3aeGSxWeZXnqqnz2RIT5XAD 6Sim9EW+wpUKn+RTfJo/5mHXLSHctGiumMo5s2JOmlPmtPnYjIiOoeLzFJ82P5mqi9XEHEgu683p wuISTce1hRAmsIE/neVaHcW0SRdw6mU4oSdoD2gBbaAfhOkl9DuwCr6AEN2EvgMegFkRURNqImeU s2LGkiU+OoaanD16PHliDnZ41Lf9g77NFXzL00kDdqa9rS7dgAM4o3no1+A9+Ah+gLCaVJPew11/ 1ZZssi2G1yc0HKFsy2EWHCbS7diWRQKxwFEBDLXY7+uemO0SUoGCwGCQF7XFba6wW+PwnyRkQJyZ qYa6nyjshbKAw2qNsjhD4dCcsvBUpboa4TxjtF+LhBfRr5DKDlMtu8zOkmHp3/kGL+hfefcGp3b4 +jrUsaPxxnjjISh8+mk9pi6tp8K0RrHQEv2SaxKJRCKRSCQSiUQikUgkEolE8hcUYiRkL6nCYwdA hLYVdfsh/7eEqNXTIS8/sc1NX2+uBvnaSQo0Gg1Gq8gvBX4I/t7Aj8BrFZkP1SLSSjzwFYrSxcBX EZ8IfPFW9wI/An8529XT2ZOzBspjI3Zh5HpfZWx4fKcxylIX9VAnyJFFA1SmMRohmwrQ16mPKmgP 0zi8EbpELl1Ba2LHd/3rcchYWKfPyFGFwsiQTkcojdjbBgMZUURi2W30aKJoful8S6NKE5K/JX+W qR1CKYpRTBOPeaNFVTuolnL3XmL2Ve+5Bv5N2695o++vHlwWdib/oX7N2biln9SiaIr6eU/+KcAA wL9UCgplbmRzdHJlYW0NZW5kb2JqDTI3OSAwIG9iag08PCAvTGVuZ3RoIDc2ID4+IA1zdHJlYW0N CgAAAAAAzMXF8wMDzBYW0ExM28wAAAMDAwQEzBAQzyws1Ftb3m9v4UlJ2hYWzwsLzgUFzQICzAEB AQEBzAYGzRAQzicn00ZG2XBw4gplbmRzdHJlYW0NZW5kb2JqDTI4MCAwIG9iag08PCAvTGVuZ3Ro IDQ2ID4+IA1zdHJlYW0NCgAAAAAAzMXF8wQEzBkZ0VRU3MwAAAMDzBAQzzIy1XBw4mtr4Sws1AsL zgEBAQplbmRzdHJlYW0NZW5kb2JqDTI4MSAwIG9iag08PCAvTGVuZ3RoIDQzID4+IA1zdHJlYW0N CgAAAAAAzMXF8wQEzBkZ0VRU3MwAAAEBAQkJzSws1G5u4UBA2BISzwICzAplbmRzdHJlYW0NZW5k b2JqDTI4MiAwIG9iag08PCAvTGVuZ3RoIDQzID4+IA1zdHJlYW0NCgAAAAAAzMXF8wQEzBkZ0VRU 3MwAAAMDzBISz0FB2Vtb3R4e0QcHzQEBAQplbmRzdHJlYW0NZW5kb2JqDTI4MyAwIG9iag08PCAv TiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvTGVuZ3RoIDI1NzUgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVB RAUURUSEqpUy1m10Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733 nfMAoCelqrXVMAsAjdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0i TMrAMPD/iS3X6Q0AQBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1W gbMpZ51CozDxaZxX1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC 8wIAyHTVO1z6DhuUDQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/ 85w4ptpieJGDRaHBwUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA 8uZbm8v7ADDxvh2++M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqA meomr66qNuqxWp1MrsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80 P9e4uGOvAa/YB7Au8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVg cqO+bn7P9FkCAqACJuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwC w2A7GAO7wX5wEIyDj8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1Kh LKgAKoFUkBYyQi3QCqgH6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPg HHgJrIJr4Ca4E14HD8Gj8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/ cgw5i1xBJpFHyAuUiHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgq Qj2hizBI2En4iHCGcI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kky koHURdpC2kf6jHSZNE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijH KBcp05RXVDZVQI2g5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib 6evoH9KP07+iP2EwGG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lN zEHmIeZF5iMWheXGkrBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7C deZKuHLuCu4Y9wx3mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+l hZ1FjIXSYo3FfovLFs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOz CbeR23TbHLS5aQvbetpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGH zxz+ipljMVgVNoSdxmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1 uelKcRW7lrtudj3r+sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2D PMs9RzwvesFewV5qr61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97Vf kF+V35jfLRFHlCzqEB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRY H7w/+EGIS0hJyHshN8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0I pwhZxI6IyUgssiTy/cjJKMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8Ql xnXHTcRz4nPjh+O/TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT 6pmqTz2WBqclp21Mu73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9z YnP6cm7luucac0/mMfOK8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRV dH2JYEnDknNLrZdWLf2kmFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/y XllEWX/ZfVWEaqPqQXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD 9SWdl65LN1kTVrOpZkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6Naxrv NSU0/aYZbZY3n2xxbGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO 5Z13Vyau3Ntl1qXvurEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URf cN+29cT12vXXN0Rt2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkk mZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTil qaYapoum/adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJL ssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/ 9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21 zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXc it0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw 6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7 d/wH/Jj9Kf26/kv+3P9t//8CDAD3hPP7CmVuZHN0cmVhbQ1lbmRvYmoNMjg0IDAgb2JqDTw8IC9M ZW5ndGggMzcgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAABQXNHBzRVVXcUFDcFhbP CmVuZHN0cmVhbQ1lbmRvYmoNMjg1IDAgb2JqDTw8IC9MZW5ndGggNzYgPj4gDXN0cmVhbQ0KAAAA AADMxcXzAgLLGBjQU1PczAAAAgICEBDPODjXAgLMBATMEBDOLi7VYGDfYmLfNDTWGRnRCwvOAQEB AwPMCgrOMjLVPDzXERHPCmVuZHN0cmVhbQ1lbmRvYmoNMjg2IDAgb2JqDTw8IC9MZW5ndGggNTgg Pj4gDXN0cmVhbQ0KAADMAAAAxcXzBATMGRnRVFTczAAABAQEEBDOLi7VX1/eQ0PZGBjQBwfNAQEB CQnNDg7ODQ3OAgLMCmVuZHN0cmVhbQ1lbmRvYmoNMjg3IDAgb2JqDTw8IC9MZW5ndGggNDMgPj4g DXN0cmVhbQ0KAAAAAADMxcXzBQUFHBzRVlbdzAAAVFTcGRnRBAQEdHTiMzPVEBDPAwMDCmVuZHN0 cmVhbQ1lbmRvYmoNMjg4IDAgb2JqDTw8IC9MZW5ndGggNDMgPj4gDXN0cmVhbQ0KAAAAAADMxcXz AQEBCgrNLCzUb2/hzAAAVFTcGRnRBAQEW1vdJCTSCQkJCmVuZHN0cmVhbQ1lbmRvYmoNMjg5IDAg b2JqDTw8IC9MZW5ndGggMzcgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBAQEFxfQSUnazAAAVFTcGRnR QEDYEhLPAwMDCmVuZHN0cmVhbQ1lbmRvYmoNMjkwIDAgb2JqDTw8IC9MZW5ndGggNDAgPj4gDXN0 cmVhbQ0KAAAAAADMxcXzAwMDEhISQEDYzAAAVFTcGRnRBAQEVlbcHh7SBgYGCmVuZHN0cmVhbQ1l bmRvYmoNMjkxIDAgb2JqDTw8IC9MZW5ndGggNDMgPj4gDXN0cmVhbQ0KAAAAAADMxcXzAwMDEhLP QUHZzAAAU1PcGBjQAgICFhbQTEzbQEDYAwPMCmVuZHN0cmVhbQ1lbmRvYmoNMjkyIDAgb2JqDTw8 IC9MZW5ndGggNDkgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBgYGHh7SVlbczAAAVFTcGRnRBAQEAgIC GBjQU1PcVlbdHBzRBQXNCmVuZHN0cmVhbQ1lbmRvYmoNMjkzIDAgb2JqDTw8IC9MZW5ndGggNDMg Pj4gDXN0cmVhbQ0KAAAAAADMxcXzAQEBCQkJJCTSW1vdzAAAVFTcGRnRBAQEQkLZExPPAwMDCmVu ZHN0cmVhbQ1lbmRvYmoNMjk0IDAgb2JqDTw8IC9MZW5ndGggNDYgPj4gDXN0cmVhbQ0KAAAAAADM xcXzAwMDEBDPMzPVdHTizAAAVFTcGRnRBAQEbm7hLCzUCQnNAQHMCmVuZHN0cmVhbQ1lbmRvYmoN Mjk1IDAgb2JqDTw8IC9MZW5ndGggNDAgPj4gDXN0cmVhbQ0KAAAAAADMxcXzAQEBCwvOLCzUamrg zAAAVlbdGhrRBAQEHBzRBQUFCmVuZHN0cmVhbQ1lbmRvYmoNMjk2IDAgb2JqDTw8IC9MZW5ndGgg NDMgPj4gDXN0cmVhbQ0KAAAAAADMxcXzAQEBBAQECwvOFxfQKirTR0fZamrgzAAAZWXfODjXBgbN CmVuZHN0cmVhbQ1lbmRvYmoNMjk3IDAgb2JqDTw8IC9MZW5ndGggNDkgPj4gDXN0cmVhbQ0KAAAA AADMxcXzAQEBBAQECwvOFxfQKirTR0fZamrgzAAAWlrdMTHVFhbQCAjNAgICCmVuZHN0cmVhbQ1l bmRvYmoNMjk4IDAgb2JqDTw8IC9MZW5ndGggNTIgPj4gDXN0cmVhbQ0KAAAAAADMxcXzAQEBBAQE CwvOFxfQKirTR0fZamrgzAAAb2/hVVXcPj7XJSXTEBAQBQUFCmVuZHN0cmVhbQ1lbmRvYmoNMjk5 IDAgb2JqDTw8IC9MZW5ndGggMzcgPj4gDXN0cmVhbQ0KAAAAAADMxcXzAgICCQnNFhbQKyvUSEja amrgzAAAIyPTAQEBCmVuZHN0cmVhbQ1lbmRvYmoNMzAwIDAgb2JqDTw8IC9MZW5ndGggNTIgPj4g DXN0cmVhbQ0KAAAAAADMxcXzBAQEFxfQSEjazAAAXl7eISHSCQkJAwMDBATMAwPMCQnNbm7hLCzU AQEBCmVuZHN0cmVhbQ1lbmRvYmoNMzAxIDAgb2JqDTw8IC9MZW5ndGggNTIgPj4gDXN0cmVhbQ0K AAAAAADMxcXzAQEBCgoKKCjUaGjgzAAAeXnkPDzXISHSGhrRGRnRGBjQQkLZExPPAwMDCmVuZHN0 cmVhbQ1lbmRvYmoNMzAyIDAgb2JqDTw8IC9MZW5ndGggNTggPj4gDXN0cmVhbQ0KAAAAAADMxcXz AQHMCAjNHBzRPz/YaGjgzAAATk7bHR3RBwcHAgLMDg7OMzPWc3PjMjLWDw/PAwMDCmVuZHN0cmVh bQ1lbmRvYmoNMzAzIDAgb2JqDTw8IC9MZW5ndGggNDMgPj4gDXN0cmVhbQ0KAAAAAADMxcXzAgIC Dw/PODjXzAAAd3fiXFzdVFTc4nd3V1fdHR3RBgbNCmVuZHN0cmVhbQ1lbmRvYmoNMzA0IDAgb2Jq DTw8IC9MZW5ndGggNTIgPj4gDXN0cmVhbQ0KAAAAAADMxcXzAQHMCgrOKSnTaWngzAAATk7bFRXP AwMDAgICEBDPODjXW1vdJCTSCQnNCmVuZHN0cmVhbQ1lbmRvYmoNMzA1IDAgb2JqDTw8IA0vVHlw ZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9PUCBmYWxzZSANL29wIGZhbHNlIA0vT1BNIDAgDS9C RzIgL0RlZmF1bHQgDS9VQ1IyIC9EZWZhdWx0IA0vVFIyIC9EZWZhdWx0IA0vSFQgL0RlZmF1bHQg DS9DQSAxIA0vY2EgMSANL1NNYXNrIC9Ob25lIA0vQUlTIGZhbHNlIA0vQk0gL05vcm1hbCANL1RL IHRydWUgDT4+IA1lbmRvYmoNMzA2IDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFs c2UgDS9TTSAwLjAyIA0vVFIyIC9EZWZhdWx0IA0+PiANZW5kb2JqDTMwNyAwIG9iag08PCAvTGVu Z3RoIDE5ID4+IA1zdHJlYW0NCgAAAAAAzMXF8wEBzAICzAMDzAplbmRzdHJlYW0NZW5kb2JqDTMw OCAwIG9iag08PCANL1MgL1VSSSANL1VSSSAoaHR0cDovL3d3dy5pdGNzcGVjaWFsaXN0c2VtaW5h ci5jb20vSG90ZWxSZXNlcnZhdGlvbi5wZGYpDT4+IA1lbmRvYmoNMzA5IDAgb2JqDTw8IA0vUyAv VVJJIA0vVVJJIChodHRwOi8vaXRjLmluZm9ybWF0aWsudW5pLXd1ZXJ6YnVyZy5kZS8pDT4+IA1l bmRvYmoNMzEwIDAgb2JqDTw8IA0vUyAvVVJJIA0vVVJJIChodHRwOi8vaXRjc3BlY2lhbGlzdHNl bWluYXIuY29tLykNPj4gDWVuZG9iag0zMTEgMCBvYmoNPDwgDS9TIC9VUkkgDS9VUkkgKGh0dHA6 Ly93d3cuaXRjc3BlY2lhbGlzdHNlbWluYXIuY29tL1JlZ2lzdHJhdGlvbkZvcm0ucGRmKQ0+PiAN ZW5kb2JqDTMxMiAwIG9iag08PCANL1MgL1VSSSANL1VSSSAoaHR0cDovL2l0Yy5pbmZvcm1hdGlr LnVuaS13dWVyemJ1cmcuZGUvKQ0+PiANZW5kb2JqDTMxMyAwIG9iag08PCAvTGVuZ3RoIDQzID4+ IA1zdHJlYW0NCgAAAAAAzMXF8wICAggIzRAQzxYW0BgY0BERzwsLzgYGzQQEzAMDAwEBAQplbmRz dHJlYW0NZW5kb2JqDTMxNCAwIG9iag08PCAvTGVuZ3RoIDEwNSAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiQBaAKX/AAAAAADMxcXzBATMFxfQSEjazAAAb2/hW1vdVFTcUlLbTEza PDzXJCTTDg7OAwPMAQEBAwMDBQXNCgrOERHPFhbQGBjQGRnRHh7SKyvTQEDYTU3aQUHZEhLPAgwA xGQgRQplbmRzdHJlYW0NZW5kb2JqDTMxNSAwIG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0N CgAAAAAAzMXF8wEBzAsLziws1Gpq4MwAAFRU3CQk0wkJzQEBAQICzAgIzRERzxwc0UBA2E1N2lJS 21tb3W9v4VZW3B4e0gYGzQplbmRzdHJlYW0NZW5kb2JqDTMxNiAwIG9iag08PCAvTGVuZ3RoIDYx ID4+IA1zdHJlYW0NCgAAAAAAzMXF8wQEzBcX0EhI2swAAD4+2BERzwICAgEBAQgIzRwc0Tk511RU 3G9v4nR04jMz1RAQzwMDzAplbmRzdHJlYW0NZW5kb2JqDTMxNyAwIG9iag08PCAvTGVuZ3RoIDEx NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQBmAJn/AAAAAADMxcXzAQEBCwvO LCzUamrgzAAAcHDiWlrdTk7aPz/XKyvTHh7SGRnRGBjQFhbQERHPCQnNAwPMAgICAwMDBAQEBgbN QEDYTU3aUlLbVFTcW1vdb2/hZmbfKirUCgrOAQHMAgwAHJ4kawplbmRzdHJlYW0NZW5kb2JqDTMx OCAwIG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0NCgAAAAAAzMXF8wEBAQkJzR0d0Tc31kpK 2lBQ205O20BA2Csr0x4e0hkZ0RcX0BERzwsLzgYGBgQEBAMDAwICAgEBzAICzAMDzAplbmRzdHJl YW0NZW5kb2JqDTMxOSAwIG9iag08PCAvTGVuZ3RoIDk3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJYmAAgjNHj35mYWERE7vg4HDjDANDfv7D6Oi7ISF3fH1vaWtflpO7JCl5UVz8 gqDgeW7uc2xsZ5mZmZmYmBgZGZmYzjAzn2FhOcPFdU5E5IKAwHkOjrMAAQYAl94Z1AplbmRzdHJl YW0NZW5kb2JqDTMyMCAwIG9iag08PCAvTGVuZ3RoIDk5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJYmAAgjNHj35mYWERF7/g4XHrDANDfv7D6Oi7ISF3fH1vOTjc0Na+LCd3SUjo PDf3OTa2sywsZ5iZmZmYmBhB4AwTE5B7RlDwvJjYBQmJC5KSF4OCbhcUPAIIMABQxB2aCmVuZHN0 cmVhbQ1lbmRvYmoNMzIxIDAgb2JqDTw8IC9MZW5ndGggMTExIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJAGAAn/8AAAAAAMzFxfMBAQELC84qKtNpaeHMAABvb+FbW91UVNxNTdpA QNgrK9MeHtIZGdEXF9AREc8GBs0DA8wCAgIDAwMEBMwWFtAYGNAsLNQ/P9hGRto2NtYdHdEJCc0B AcwCDABccSEOCmVuZHN0cmVhbQ1lbmRvYmoNMzIyIDAgb2JqDTw8IC9MZW5ndGggNDkgPj4gDXN0 cmVhbQ0KAAAAAADMxcXzAQEBBAQECwsLFxfQKirTR0fZamrgzAAALCzUHBzREhLPCQkJAwMDCmVu ZHN0cmVhbQ1lbmRvYmoNMzIzIDAgb2JqDTw8IC9MZW5ndGggNDMgPj4gDXN0cmVhbQ0KAAAAAADM xcXzBATMGRnRVFTczAAABQXNHBzRV1fdb2/hKyvTCwvOAQEBCmVuZHN0cmVhbQ1lbmRvYmoNMzI0 IDAgb2JqDTw8IC9MZW5ndGggNDMgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAAAQEB CQnNLCzUbm7hW1vdHR3RBgbNCmVuZHN0cmVhbQ1lbmRvYmoNMzI1IDAgb2JqDTw8IC9MZW5ndGgg MzQgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAAAgICEhLPQEDYVVXdCmVuZHN0cmVh bQ1lbmRvYmoNMzI2IDAgb2JqDTw8IC9MZW5ndGggNDAgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATM GRnRVFTczAAAAwPMExPPQkLZQEDYEhLPAgLMCmVuZHN0cmVhbQ1lbmRvYmoNMzI3IDAgb2JqDTw8 IC9MZW5ndGggMzQgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAAAQEBCwvOKyvTb2/h CmVuZHN0cmVhbQ1lbmRvYmoNMzI4IDAgb2JqDTw8IC9MZW5ndGggMTI5IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJAHIAjf8AAAAAAMzFxfMEBMwZGdFUVNzMAAABAQEJCc0kJNJc XN5cXN0nJ9MKCs4DA8wQEM8yMtVwcOJGRtkXF9AFBc0YGNBqauArK9MLC80CAswBAcwlJdJbW95O TtsgINICAgIDAwMPD88sLNRgYN99feMeHtECDAD3CijZCmVuZHN0cmVhbQ1lbmRvYmoNMzI5IDAg b2JqDTw8IC9MZW5ndGggNTggPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAAAQEBCQnN LCzUbm7hUFDcFhbPBQXNHBzRVlbdW1vdHh7RBwfNCmVuZHN0cmVhbQ1lbmRvYmoNMzMwIDAgb2Jq DTw8IC9MZW5ndGggNDAgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAAAwPMEhLPQEDY dXXiNDTWEBDOCmVuZHN0cmVhbQ1lbmRvYmoNMzMxIDAgb2JqDTw8IC9MZW5ndGggMzcgPj4gDXN0 cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAAFhbPUFDcTU3aFxfQAwPMCmVuZHN0cmVhbQ1lbmRv YmoNMzMyIDAgb2JqDTw8IC9MZW5ndGggMzQgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTc zAAAAgLLGBjQUlLbBAQECmVuZHN0cmVhbQ1lbmRvYmoNMzMzIDAgb2JqDTw8IC9MZW5ndGggMzQg Pj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAAAwPMFxfQTU3aBAQECmVuZHN0cmVhbQ1l bmRvYmoNMzM0IDAgb2JqDTw8IC9MZW5ndGggMzQgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnR VFTczAAAAgLMEhLPQEDYBAQECmVuZHN0cmVhbQ1lbmRvYmoNMzM1IDAgb2JqDTw8IC9MZW5ndGgg MjIgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAACmVuZHN0cmVhbQ1lbmRvYmoNMzM2 IDAgb2JqDTw8IC9MZW5ndGggNDAgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAABgbN Hh7SWlrdQEDYEhLPAgICCmVuZHN0cmVhbQ1lbmRvYmoNMzM3IDAgb2JqDTw8IC9MZW5ndGggNDAg Pj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAAAgLMEhLPQEDYXV3eHx/SBgbNCmVuZHN0 cmVhbQ1lbmRvYmoNMzM4IDAgb2JqDTw8IC9MZW5ndGggMzEgPj4gDXN0cmVhbQ0KAAAAAADMxcXz BATMGRnRVFTczAAAAgLLGBjQUlLbCmVuZHN0cmVhbQ1lbmRvYmoNMzM5IDAgb2JqDTw8IC9MZW5n dGggMzcgPj4gDXN0cmVhbQ0KAAAAAADMxcXzBATMGRnRVFTczAAAAwPMFxfQTU3aVlbdGhrRCmVu ZHN0cmVhbQ1lbmRvYmoNMzQwIDAgb2JqDTw8IC9MZW5ndGggMTk4IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJALcASP8AAMwAAADFxfMEBMwZGdFUVNzMAAAQEM4uLtVfX95vb+E3 N9YKCs4DA8wBAQELC84XF9AnJ9MxMdUoKNQVFdAGBs1gYN9ycuJGRtkCAgIFBc0rK9RGRtpfX98i ItIJCc0BAcwQEM8sLNRbW95dXd4zM9UeHtITE88EBAQSEs8cHNEtLdVISNppaeFTU9whIdIICM0P D88mJtNFRdlra+Fzc+JXV91BQdkdHdEYGNBAQNhSUttra+ACDAACl0ZmCmVuZHN0cmVhbQ1lbmRv YmoNMzQxIDAgb2JqDTw8IC9MZW5ndGggMTA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJAF0Aov8AAAAAAMzFxfMCAgIHBwcMDM4REc8XF88oKNQ+PtdOTtpaWt1vb+HMAABubuFV VdxAQNgsLNQcHNESEs8LC84FBQUBAQEDAwMGBs0ODs4dHdEvL9Q8PNdLS9poaOACDACSdR9zCmVu ZHN0cmVhbQ1lbmRvYmoNMzQyIDAgb2JqDTw8IC9MZW5ndGggNjEgPj4gDXN0cmVhbQ0KAAAAAADM xcXzAQEBAgICBAQECgrOERHPFxfQHh7SKyvTQEDYVVXcbm7hzAAALCzUHBzREhLPCwsLBQUFCmVu ZHN0cmVhbQ1lbmRvYmoNMzQzIDAgb2JqDTw8IC9MZW5ndGggMTAzIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmAAgjNHj35mZGRkYmJiZWXl4jonJHReXPyCnNwlbe3L9vbX/fxu RUXdzc9/eIaBoaDgkaTkRVHR84KCglxcXMzMzGxsbNzc3DIyF3V0rkRH3w0JuePre8vB4QZAgAEA mUsbtgplbmRzdHJlYW0NZW5kb2JqDTM0NCAwIG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0N CgAAAAAAzMXF8wEBAQICAgUFzQsLzhERzh0d0TAw1FFR264mJrQsLLNDQ8wAAG5u4VVV3EBA2Cws 1Bwc0RISzwoKCgQEBAEBzAplbmRzdHJlYW0NZW5kb2JqDTM0NSAwIG9iag08PCAvTGVuZ3RoIDQz ID4+IA1zdHJlYW0NCgAAAAAAzMXF8wEBAQQEBAsLzhcX0Coq00hI2mlp4MwAABYWzwUFBQICAgpl bmRzdHJlYW0NZW5kb2JqDTM0NiAwIG9iag08PCAvTGVuZ3RoIDQzID4+IA1zdHJlYW0NCgAAzAAA AMXF8wEBAQQEBAsLzhcX0Ckp00FB2VVV3G5u4cwAAG9v4QsLCwplbmRzdHJlYW0NZW5kb2JqDTM0 NyAwIG9iag08PCAvTGVuZ3RoIDY0ID4+IA1zdHJlYW0NCgAAAAAAzMXF8wEBAQICAgUFzQsLzhIS zxwc0Sws1EBA2FZW3HJy4cwAAG5u4VVV3EFB2Skp0xcX0AICzAEBzAplbmRzdHJlYW0NZW5kb2Jq DTM0OCAwIG9iag08PCAvTGVuZ3RoIDQ5ID4+IA1zdHJlYW0NCgAAAMXF8wAAzAEBAQQEzAoKzhIS zxwc0Sws1EBA2FVV3G5u4cwAAGlp4EdH2QQEBAplbmRzdHJlYW0NZW5kb2JqDTM0OSAwIG9iag08 PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0NCgAAAAAAzMXF8wEBAQICAgMDAwYGBgsLCxISzxcX0B4e 0isr0z8/105O2lpa3XBw4swAAG9v4Vtb3VRU3E1N2kBA2AsLzgQEBAplbmRzdHJlYW0NZW5kb2Jq DTM1MCAwIG9iag08PCAvTGVuZ3RoIDIyID4+IA1zdHJlYW0NCgAAAAAAzMXF8wEBzAICzAMDzAQE zAplbmRzdHJlYW0NZW5kb2JqDTM1MSAwIG9iag08PCAvTGVuZ3RoIDE4NiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiQCrAFT/AADMAAAAxcXzAgLLGBjQU1PczAAAAwPMFhbQTEzb AQHMBATMCwvOFxfQKirTSEjaaWngaGjgRUXZJSXTDg7OAgLMEBDPODjXKSnTQUHZVVXcbW3gV1fc Tk7bPz/YKirUCgrOCAjNHBzRNjbWSkraUVHbUlLbVFTcEhLPLCzUQEDYUVHcUFDbT0/aUFDcTk7a Pj7YKyvUHR3RERHPAQEBGRnRBQXNBgbNAgICAgwAMRVB1gplbmRzdHJlYW0NZW5kb2JqDTM1MiAw IG9iag08PCAvTGVuZ3RoIDcwID4+IA1zdHJlYW0NCgAAzAAAAMXF8wQEzBkZ0VRU3MwAAAICyxgY 0FNT3AMDzAoKzhcX0Coq00dH2Wpq4Gtr4FdX3FBQ209P2mlp4CUl0wEBzAplbmRzdHJlYW0NZW5k b2JqDTM1MyAwIG9iag08PCAvTGVuZ3RoIDQ2ID4+IA1zdHJlYW0NCgAAAAAAzMXF8wICAgMDAwQE BAQEzAEBAQYGBgsLCxERzxYW0BgY0BkZ0QsLzgplbmRzdHJlYW0NZW5kb2JqDTM1NCAwIG9iag08 PCAvTGVuZ3RoIDc5ID4+IA1zdHJlYW0NCgAAAAAAzMXF8wICAgMDAwYGBgsLzhISzxcX0B4e0isr 00BA2E1N2lRU3Ftb3W9v4cwAAHBw4lpa3U5O2j8/1xkZ0RUVzxERzwsLCwEBAQplbmRzdHJlYW0N ZW5kb2JqDTM1NSAwIG9iag08PCAvTGVuZ3RoIDcwID4+IA1zdHJlYW0NCgAAAAAAzMXF8wEBAQIC AgMDzAYGzQsLzhERzxcX0BkZ0R4e0isr00BA2E1N2lJS21RU3Ftb3W9v4cwAABISzwQEBAMDAwpl bmRzdHJlYW0NZW5kb2JqDTM1NiAwIG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0NCgAAAAAA zMXF8wEBAQICAgMDAwQEBAYGzQsLzhERzxYW0BgY0BkZ0R4e0isr00BA2E1N2lJS21RU3AsLCwYG Bltb3W9v4cwAAAplbmRzdHJlYW0NZW5kb2JqDTM1NyAwIG9iag08PCAvTGVuZ3RoIDczID4+IA1z dHJlYW0NCgAAAAAAzMXF8wEBzAICAgMDAwQEBAYGBgsLzhERzxYW0BgY0BkZ0R4e0isr00BA2E1N 2lJS21RU3Ftb3W9v4cwAAAsLCwICzAplbmRzdHJlYW0NZW5kb2JqDTM1OCAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDYwIC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxOTggMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYIADRmIAAxIACDAABLcAJgplbmRzdHJlYW0NZW5kb2JqDTM1 OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcyIC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxOTggMCBSIC9MZW5ndGggMjEg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAADRrIBRD8DQIABAAiNADsKZW5k c3RyZWFtDWVuZG9iag0zNjAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA4OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTk4 IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCAAUaq AJhpAAEGAAw9AEcKZW5kc3RyZWFtDWVuZG9iag0zNjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA5NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMTk4IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJYmAAAkaaAJDJDAABBgAQqwBXCmVuZHN0cmVhbQ1lbmRvYmoNMzYyIDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTA1IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxOTggMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAACRpoCBjAACDAAFA4AXwplbmRzdHJlYW0NZW5k b2JqDTM2MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEx MiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTk4IDAgUiAvTGVu Z3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBgYGCkD2AAAYAAAwAX XwBoCmVuZHN0cmVhbQ1lbmRvYmoNMzY0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMTE5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxOTggMCBSIC9MZW5ndGggMjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIliYAACRlIBSAsDHEDFiNfMwAAQYAAXJQBiCmVuZHN0cmVhbQ1lbmRvYmoNMzY1IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTI4IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyMDQgMCBSIC9MZW5ndGggMzIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAABRlIBA1QbAwMTBMDMIME4sFKAAAMAG+cAbgpl bmRzdHJlYW0NZW5kb2JqDTM2NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDEzNCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug MjA0IDAgUiAvTGVuZ3RoIDM4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBg YCQHMDAwAQFQL5iGAAaIWQxgwEikuWDFAAEGACLAAH8KZW5kc3RyZWFtDWVuZG9iag0zNjcgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNDAgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIwNCAwIFIgL0xlbmd0aCAzOCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgYGAkHiCpZWBgAgOgEJQF5TPAZRkYiDcc pBYgwAAnwACOCmVuZHN0cmVhbQ1lbmRvYmoNMzY4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMTQ1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAyMDQgMCBSIC9MZW5ndGggNDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIliYGBgYCQWMCArBrKZIAAoBmPCRBjACmAcBoQWghYABBgAKbYAkwplbmRzdHJlYW0N ZW5kb2JqDTM2OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDE1MSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjA0IDAgUiAv TGVuZ3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBgYGRgJBYwgAGC xwQDQDEEByoEUseA4EH1IRsAMwfTFoAAAwAt7wCbCmVuZHN0cmVhbQ1lbmRvYmoNMzcwIDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTU3IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyMDQgMCBSIC9MZW5ndGggNDQgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGBgYCQaABUzMCE0ADkIABRF5kIFUUWhWhkg AM1kTKsAAgwAM14ApAplbmRzdHJlYW0NZW5kb2JqDTM3MSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE2MiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgMjA0IDAgUiAvTGVuZ3RoIDQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJYmBgYGAkATAwMAEBAyoXBoDCKHyoKAOqKNRGBihAMRxNACQCEGAAObsArwpl bmRzdHJlYW0NZW5kb2JqDTM3MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDE2NyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug MjA0IDAgUiAvTGVuZ3RoIDQ5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBg YCQFMDAwMIEAXBuUDwNAYVQBuDiaOgaEdqCZDCg2MKCKAIUAAgwAP1YAvQplbmRzdHJlYW0NZW5k b2JqDTM3MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE3 MSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjA0IDAgUiAvTGVu Z3RoIDUwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBgYMQPGBhQlDAwMEEA AxqfCSGOLgSTQBOHGgwxgQHZHgY0S8FCAAEGAENYAMgKZW5kc3RyZWFtDWVuZG9iag0zNzQgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNzYgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIwNCAwIFIgL0xlbmd0aCA0NiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgYCQEGBgYUHhMUAAThQsgSWCIwWTQJSBm ww1lQLcMWQDEBggwAErgANYKZW5kc3RyZWFtDWVuZG9iag0zNzUgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxODAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDIwNCAwIFIgL0xlbmd0aCA0OSAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiWJgYGDEDxgYkJUAOUwwABdHCMFksIjBpTCFGCAmw3gI+xgg1qE5ACDA AE0yAN4KZW5kc3RyZWFtDWVuZG9iag0zNzYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAxODMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDIwNCAwIFIgL0xlbmd0aCA0NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgYCQAGEAAmc+EAAxYxOAymIK4AcQGBgYmBnTrQIIQFUjCDAABBgBSuADoCmVuZHN0cmVh bQ1lbmRvYmoNMzc3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMTg3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyMDQgMCBS IC9MZW5ndGggNTQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGBgRANoIgxg gCzAhAAMcEVM6IABVSUqYMQUglgCtYoBai0DqukIdwClAAIMAFJ/AOQKZW5kc3RyZWFtDWVuZG9i ag0zNzggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxOTEg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIwMCAwIFIgL0xlbmd0 aCA2MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgYGBEBQzYRBhQuExIACaD IgiRYUBXi6oPXTUD1B5mFlZWVjZWdnYOTiSbGZAVwl0CEGAAXK0BGwplbmRzdHJlYW0NZW5kb2Jq DTM3OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE5NiAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjI5IDAgUiAvTGVuZ3Ro IDcxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmJGAUxMGCLMzBhKWBAA ppwJG8AuDNcJpWBqQYCVjZ2Dk4ubh4eHl5ebi5ODj19AECKHbCvCkUxMAAEGAOZXAr8KZW5kc3Ry ZWFtDWVuZG9iag0zODAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAxOTkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIxOCAw IFIgL0xlbmd0aCA4NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGRCAYxg gCGAIgYTYQYDRoQoEwsrGxsbOx4AlGZlAaqF6GRkQjUZZAAHJxc3Dy8fv4CAgKCQsIgoj5i4BCe7 JEQVzE6Ibka4xQABBgACrQNcCmVuZHN0cmVhbQ1lbmRvYmoNMzgxIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjAyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAyMTUgMCBSIC9MZW5ndGggODQgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYGRkZEICjGCAJsIMBOjCyMoZERwWVjZ2Dg5OPICDg52NlQXdIqhB jFzcPLx8/AKCQsIiMCAqJi4hKSUtwy0LUQ92DhTATWBkBAgwAEPFBGEKZW5kc3RyZWFtDWVuZG9i ag0zODIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMDUg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIyNCAwIFIgL0xlbmd0 aCA5MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXyOVwrAMAxD1Tg7adM97n/R xg2BDugD/zywJADNHUCIp2LDZElSKaXzSWKP1y9DxjofYvtDDN5ZQzUdJemqAOku9cM4zR+WddsP WRrrpLKrrgBOAQYAe00EzwplbmRzdHJlYW0NZW5kb2JqDTM4MyAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIwOCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgMjIxIDAgUiAvTGVuZ3RoIDkwIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJjI5LEoAwCENBoFj/2vq5/0nVobbOuPHtyCQkAPgGoLqAj2IqsTjVWtUJ E5rVKG4S3/zAC1nyfoGpA9quH8Zpzq4lxBjyuW47H9ZWVqURT/0pwABdrAQhCmVuZHN0cmVhbQ1l bmRvYmoNMzg0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MjExIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNTAgMCBSIC9M ZW5ndGggOTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMjkkWgCAMQyMyiSLO Co73P6W+JyLu/IsukrYJkMQAIBf4SMQDpJRxITOVScEZTYNzWeEeeaHLH+jCxK/vaaq6abtnpR/G yTpn50WtXtr2A77fmx5XAE4BBgDuQgXiCmVuZHN0cmVhbQ1lbmRvYmoNMzg1IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjEzIC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNDkgMCBSIC9MZW5ndGggOTQgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMjscOgCAQRIelCGIXsf7/dwoaFG++yyZTsgOwDAAUCCeT KBFELqRKSME/3pMutFE/MLp8+8QQ/9qqbtoU6PphdJO31s9uWbdb3I+rFRdm0yibDZwCDABFfAPn CmVuZHN0cmVhbQ1lbmRvYmoNMzg2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMjE2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSAxOTIgMCBSIC9MZW5ndGggODYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl8 jkcSgDAMA2UnoYTe+f9LMcyYERf2qGILEAKA3uCjqQPTQ0yFk2IAe2+6pNAP3FcV2JGqzo3bbZf7 YZxmWyVLWLf9OLn1fKQ+zQAuAQYAKI0DSwplbmRzdHJlYW0NZW5kb2JqDTM4NyAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIxOCAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTYwIDAgUiAvTGVuZ3RoIDg3IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjI5JDoAgEARbGTZx3///UtMYzBgv1o2uCSmgUgB1Bt/p 2Y1YV7BioB3v88OH6H4QQwP9O5Dari92GKc5LWABFdZNdsrj9KrzFcgNd/YlwAA3rANZCmVuZHN0 cmVhbQ1lbmRvYmoNMzg4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMjIwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNTUg MCBSIC9MZW5ndGggMTAzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJZI5JFoAg DEOjgoCK4Ijz/Y8pwgOnv2vStAGSGyD1AH/N6ZeSEZoHKMnwMm3ADYyLoqwk9dRKx4hWtRdlVRaC N3ieR9v1Q9gcRjOx8N96QDObZc23/WAxgk/FWB84BRgAePYEIAplbmRzdHJlYW0NZW5kb2JqDTM4 OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyNCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTM1IDAgUiAvTGVuZ3RoIDk5 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJZI5XDoAwDENdEqClgz3vf1BALSUI f0TKky0bUEJAEQX82cuJy+pRyZRDKZC+WpvGWma+j/MhR4J3EVrbGF0rUQDVdv3wGEc/kajHtQWg eVm3/cB3kxwpKE4BBgBa3wOKCmVuZHN0cmVhbQ1lbmRvYmoNMzkwIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjI2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxMzQgMCBSIC9MZW5ndGggOTIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIlsjgsOwCAIQ+vQIX728/53ndFpJFkTSFp4AZhFwPYJP1nL+4Cs24ec JWgKw7EXEaLWQkwTSTH0tJbnCTSI83GOvet+SN1HfQeQkosYnSu7/opXgAEAPvQDEQplbmRzdHJl YW0NZW5kb2JqDTM5MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDIyOCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTM4IDAg UiAvTGVuZ3RoIDc0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJZI5JEoAgDARb CKD4//9qsaQyRR8zW+BygLQgHFOAJWQrdVMsI+qOhOozIhphoN2P+7o13f87R+8robmlRn8IPgEG ANgVAfkKZW5kc3RyZWFtDWVuZG9iag0zOTIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAyMzAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDE0NSAwIFIgL0xlbmd0aCA3MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiXSOSRKAIAwEWwIIiv7/uRwkEKHo4yzJwNEBp8CqfUbTxYeoBC/8XMaZwVKxmAdnypfG7vK8 0wCzjlncRakCDADe/gIJCmVuZHN0cmVhbQ1lbmRvYmoNMzkzIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjMzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSAxNDAgMCBSIC9MZW5ndGggNzMgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIlsjkkSgCAMBDsQUFD//10PEmIF5tiz1IBMQTLh2OHnGM9aqqlo5m8TSmMz VnapxHG2PmPX/awpGQejw4rsE68AAwD1OAI0CmVuZHN0cmVhbQ1lbmRvYmoNMzk0IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjM1IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxODEgMCBSIC9MZW5ndGggNjcgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlsjskNACAMw8x97j8vQlAkoHk2thowJ2AloBzvBudD lATvFrfbRxJXVX4q5UOV2rpKzSW/j/56jmYIMAD2pQI0CmVuZHN0cmVhbQ1lbmRvYmoNMzk1IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjM2IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxODAgMCBSIC9MZW5ndGggNjkgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl0jjkSwCAMxMQVCDn+/1wajIkhKtfSjHEC eAWd/ReGHmI6hBQD0xlb9XabWHI5q0jX/bx76wdYPu6zowkwAAS1AlIKZW5kc3RyZWFtDWVuZG9i ag0zOTYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMzgg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE3OSAwIFIgL0xlbmd0 aCA2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJghAMGJgRgwCoKloFKMTAw MLOwssEAKwszA5I0ui6YZmxaMBSxc3DCFXFx8/BiNwsnYMBuO9BhDAABBgAFEAJQCmVuZHN0cmVh bQ1lbmRvYmoNMzk3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjQwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxOTAgMCBS IC9MZW5ndGggNjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGCEAgYGJgRg wC4MloJLMDCzsLLBACsLMwOSNLoumGZsWjAUsXNwwhVxcWNXhAcw4LAeJA4QYAD/iAI6CmVuZHN0 cmVhbQ1lbmRvYmoNMzk4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMjQzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxODUg MCBSIC9MZW5ndGggNjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGCEAQYG JgTAIYwsBRRnYGZhZYMBVhZmBiR5dG0w3di0oKth5+Dkgivi5uHFYRZuwIDDeqDbGAACDAANdAJX CmVuZHN0cmVhbQ1lbmRvYmoNMzk5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMjQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSAxNzYgMCBSIC9MZW5ndGggNjYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl0 jkcOACAMw8ze//8ucGAIUR+buApqAfqC/3kmnABjnV84azjqq239p7ydENPu5FKb9EwGYcBYTxdg ABC0AlkKZW5kc3RyZWFtDWVuZG9iag00MDAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAyNDUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDE2NyAwIFIgL0xlbmd0aCA2NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJghAEGBiYkwIBdGFkKJMHAzMLKBgOsLMwMcAWY+mDasWlBV8POwQlXw8XNg8ssfICBEacE QIABABD2AlgKZW5kc3RyZWFtDWVuZG9iag00MDEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAyNDcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDE2MyAwIFIgL0xlbmd0aCA2NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiXyLyQ0AIAzDwlHu/edFSKWqoOBnYgOOAbwG9rweqAchUtpQDJD26qS3kkPJpTZx+rAc xj2fH1OAAQAU6QJhCmVuZHN0cmVhbQ1lbmRvYmoNNDAyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjQ5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxNzQgMCBSIC9MZW5ndGggNjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYIQBBgYmZMDAgE0UIgXTAeYws7CywQArCzMDXC8WnVD9WLSgK2Hn4IQrYePk YMdpGF6A0w2MDAABBgAYxAJcCmVuZHN0cmVhbQ1lbmRvYmoNNDAzIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjUxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxNjkgMCBSIC9MZW5ndGggNjggL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIl0jkcSACAIAyPYy/+/qwesIzlmNwyAkQB0BgLuVtg5AFvnZ5xlbOEz VSevEmJaSi61qceIjI6gPTFAF2AAIlQCbAplbmRzdHJlYW0NZW5kb2JqDTQwNCAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1MyAvSGVpZ2h0IDIgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTcxIDAgUiAvTGVuZ3RoIDg5IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjI9JEoAgDMBSFhdc/v9cL1J0aJUcaQoE5AbCk3YeOnhN iClPlZwi1cBY9Vd6ZVZlWYt71w+IO8Br13jr0dF4/0cD8WXbVTlOS2l4gZ8glwADAJgSBM4KZW5k c3RyZWFtDWVuZG9iag00MDUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyNTUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE3 MCAwIFIgL0xlbmd0aCA2MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJghAIG BiYUwMCAXRxJDibDwMzCygYDrCzMDDAVWLTi1oKugp2Dkwu/EiSAxyqgJG4pgAADACLWAmIKZW5k c3RyZWFtDWVuZG9iag00MDYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyNTYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE3 MiAwIFIgL0xlbmd0aCA2NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgYIQA BgYmVACXYMIEDKhSDMwsrGwwwMrCzABTgU0vTi3oKtg5ONmQlHDhNgzsInyyOAEjQIABACjEAmsK ZW5kc3RyZWFtDWVuZG9iag00MDcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAyNTcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDE3NSAwIFIgL0xlbmd0aCA2NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJg hAAGBiZUwACTYMICGFD1MDCzsLLBACsLMwNUBYahSCZgakFXwc7ByYakhAunWYQBI24pgAADACzv AnIKZW5kc3RyZWFtDWVuZG9iag00MDggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCAyNTkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDE3MyAwIFIgL0xlbmd0aCA2MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iWJgYAQDBgYmNIBTAiQHkYRLMTCzsLLBACsLMwNUOza9uLWgq2Dn4GRDUsKFxzSCgBG3FECAAQAw BAJ0CmVuZHN0cmVhbQ1lbmRvYmoNNDA5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMjU5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxNjggMCBSIC9MZW5ndGggNTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIliYIQABiY0wMCAQwIsCZGCyzEws7CywQArCzMDVAlWzTi14FOBXQkKwGcbPm0AAQYAKzECYQpl bmRzdHJlYW0NZW5kb2JqDTQxMCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDI2MSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug MTY4IDAgUiAvTGVuZ3RoIDU1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCE AAYmdMCASwIhiZBjYGZhZYMBVhZmBiYGBty6cWjBqwK7ElQ34ZVnxC0FEGAAMQkCZQplbmRzdHJl YW0NZW5kb2JqDTQxMSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDI2MyAvSGVpZ2h0IDIgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTY4IDAg UiAvTGVuZ3RoIDgwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnJBJCgAgDAPH uvz/yYroRdMK5toZSANpBuwM3kHdyKW2nVoyG1G2p4SERo5SMeAlrbLKB3+F+8frp1DXSky8Zxit /mYw6wIMANWjBMgKZW5kc3RyZWFtDWVuZG9iag00MTIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNjQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDE2MiAwIFIgL0xlbmd0aCA1OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgYAQDBiZ0gFMCSRZJkoGZhZUNBlhZmBkYGPBox64FUwU7BycbfiXorsKnghG3 FECAAQA6/AJ1CmVuZHN0cmVhbQ1lbmRvYmoNNDEzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMjY1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAxNjQgMCBSIC9MZW5ndGggNjYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIl8jkcOACAMwwKFsv7/XyTWoQNf7UhBWABRgmOUWBJSglLmS06EndhzZ6KLUtsruA8j kZ9/hS8DpgADAD/wAnwKZW5kc3RyZWFtDWVuZG9iag00MTQgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDE2NiAwIFIgL0xlbmd0aCA2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiWJgBAMGJnTAwACRwJQBy2LoYmBmYWWDAVYWZgaIAdi149CCqYKdgxOugo2L mwefcRBn4bWQEbcMA0CAAQBGewKGCmVuZHN0cmVhbQ1lbmRvYmoNNDE1IDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjY3IC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNzAgMCBSIC9MZW5ndGggNjggL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIl8jkkOACAIA6uCKP9/sMYtxoVep1OAawH8GQxygY3uEIE4zjAF AIb/Vu6GpKyrojmJMdf/sg76L6xeEWAAS5ICkAplbmRzdHJlYW0NZW5kb2JqDTQxNiAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI2OCAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTY1IDAgUiAvTGVuZ3RoIDY1IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAEAwYmDMCAUwYuy4AsycDMwsoGA6wszAwMDHj0 Y9eCRQk7BydcCRsXNw8+8yDuwqeCEZ8+gAADAEz5Ao0KZW5kc3RyZWFtDWVuZG9iag00MTcgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNjkgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE4NyAwIFIgL0xlbmd0aCA2NiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgYAQBBgYmDACVwZRAyKJIMjCzsLLBACsL MwMDAw6TcWvBpoSdA66EjZOLG595EHcRUIFTIwNAgAEASloChwplbmRzdHJlYW0NZW5kb2JqDTQx OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3MCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTg2IDAgUiAvTGVuZ3RoIDY1 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAEAwYmTMAAlsAmg5BFEWFmYWWD AVYWZgYGBhwm49aCRQk7BydcCRsXVjVoDsOnArcs0LEMAAEGAE3bAoEKZW5kc3RyZWFtDWVuZG9i ag00MTkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNzAg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE4OCAwIFIgL0xlbmd0 aCA2OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgBAEGBiZMwACWwSIBlsSU ZWBmYWWDAVYWZgawGlwGYNeCRQ07BycXXA03Dy9eA8HOxqcCtyzQsQwAAQYAVnACmQplbmRzdHJl YW0NZW5kb2JqDTQyMCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDI3MSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTkxIDAg UiAvTGVuZ3RoIDY4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAEAQYmTMDA gEsGLAuWRJFlYGZhZYMBVhZmBrAJuAzArgWbGnYOTrgaLm4eXrwmgl2GRwUeWZAUQIABAFePApcK ZW5kc3RyZWFtDWVuZG9iag00MjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAyNzIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDE4OSAwIFIgL0xlbmd0aCA2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXyO WwoAIAgEt7J39z9vJRRk4vzOuAi4BeB/2DjNXPtKBIrpEClAaeSKPNGaXOptUuvDXOTPjMKwW00B BgBXNAKTCmVuZHN0cmVhbQ1lbmRvYmoNNDIyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMjczIC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxODQgMCBSIC9MZW5ndGggOTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIm0kMkOgEAIQ+ssjvv2/x9rxEgyk8LNHnmFlKJ7hEAEIRQprUcx5f5TThHE015pV5inDOOk pnmhpjqZmfrNbVBZhFmI/w6jPxUSsG67mo7zKn4jzss+FXQLMAB8VgVFCmVuZHN0cmVhbQ1lbmRv YmoNNDIzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjcz IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNzggMCBSIC9MZW5n dGggNjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAQBBiZMwIBTBpcsAzML KxsMsLIwMzDgMwG7FqyK2Dk44Yq4uHnY8RoJdhpuFXhkwVIAAQYAW9EClQplbmRzdHJlYW0NZW5k b2JqDTQyNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3 MyAvSGVpZ2h0IDUgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTc3IDAgUiAvTGVu Z3RoIDE4MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicyT2Q7CIBBFL7S1dcEF 1+K+/f8vqqRgQmewMcE4j9wDDAeAeBYg2wVhIyLxaTAPWV70XBV5BsRWoKeQVFn1B54ajlTJrvnq CNFNI6mN+J67CAnGUgnBeDKdeUzPGcx2BSQVQr6ddxqMJROCxVJ7bLXe1BwnGiPfC+GfQfw0PxUi YdR257n9QR3JT97c4WchjE8nhM7/SYjE6Xy5Ou6m75VpkzC1MZ2EMLEV8hBgALpJDukKZW5kc3Ry ZWFtDWVuZG9iag00MjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAyNzMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE4MyAw IFIgL0xlbmd0aCA3NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgYGBgZMIG GBlwSuGQZWRmYWWDAVYWZkb8RmDVglMhOwcnF1wlNw8vHyOqWkY+dn4BQV4hBrCtuC3F4yawRoAA AwB1vgL1CmVuZHN0cmVhbQ1lbmRvYmoNNDI2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMjczIC9IZWlnaHQgNCAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxODIgMCBSIC9MZW5ndGggMjE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJvFLXEoJADEw8BBtNxYYVe++C5f+/SyknM3gHjOO4j8kmt7sXAADMsIBuh90KutFBJEJW pMgKBFmkhJEYppTLU2ahKJRkDNUhKkTV9HKlaoD3aswe4Pny5fJdp9mb4O6ngbiJ1Ci13tAlQ1bQ h9JsqZrZ7ohit9fH2J8MNLFBA+Fb/n8g/JNEIANr+CaPxpOpahAiz2ZGab5Yrtav4ma7U4JAeIBk fB1IVD0nEMaSUN/HSAyA7A/HE2WfL7blXF045u3+8Gp2laQwzL0Rt/EUYAALRxHlCmVuZHN0cmVh bQ1lbmRvYmoNNDI3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjczIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNjEgMCBS IC9MZW5ndGggODkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl8j0EOgCAMBLcC AqIioP7/qTYS8GB1Lj3MbjYFQIMEEVjJTrZESpuxYbS6Q5x6gwpf63yveGfxzxTmZY29sKVcSslp b5tHOOl79dkW/6rqEmAAd9UDGQplbmRzdHJlYW0NZW5kb2JqDTQyOCAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3MyAvSGVpZ2h0IDUgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTQxIDAgUiAvTGVuZ3RoIDI4NiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiZyTCXPCIBCFNxVdJKW1B7GXlcRoD3vHHv//lxUE01pgzfTNZCaT xxv2ewEAyPYCZVZgrKQg4kKP9Qcb9VkPOgj5sI0MOaY3dBL5vjw4HA1iOjo+OUXYzBZCebK066wo dReULnSx2ralinEbGRcqS4G0OLaSs/OLy+0yRleT66nUaPNkIZTrjgBJSKFE3IDObUEBirKa1fPF zWJez6pS0H24mUWub6u7+8ly+fBo9fRcv7y+yUbnq2wHMun6aclrkYaJuCGd24IGVGXBGXtnjBel ohe3OAI/dGNSTlLyRn+iEn6e/14Zf56TWcLy8b9uQNelEBAKEXPzKLFj8c/Qpvt1ai3z8rWy336t Sf5JdyNirq/qW4ABAMDoF4gKZW5kc3RyZWFtDWVuZG9iag00MjkgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNzMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDEzOSAwIFIgL0xlbmd0aCA2NyAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiXyNQRIAMAQDo+j/n9yUnjrYGRcbARGsGvSqtlypufvmmF7PzdTBkwdj yRTOF9GIjz/T9mRBpcMIjgADAPySAbwKZW5kc3RyZWFtDWVuZG9iag00MzAgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNzIgL0hlaWdodCAyIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE0MiAwIFIgL0xlbmd0aCAxMDIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImskEsOgCAMRKdSAaF6/+NCqCZqbMPCWTWdST8PhMUQyPY+ XTw1Ms6IwMyrKsaz6K2Q3KXuUVfG+8lwh0PAjzxmTgOScshbqSL7SyK1HFnBdDTz79wWOBGYAxQH oQkwAPeeBS4KZW5kc3RyZWFtDWVuZG9iag00MzEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAyNzEgL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDE0NCAwIFIgL0xlbmd0aCAxMTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSImskO0OQDAMRTvWsk/G8P5vKhVhxCYR5++9aXMPCAHVM5CPXtOjk5RqiUjUtEobY63z XR/CcCOEvvPOMsZoNUYiRJR1erD8liulSZl0TwqrftIBFWwiIns4NUzzkmGeLmZYSxuJpQAUpqa7 PutYBRgAD1UKPQplbmRzdHJlYW0NZW5kb2JqDTQzMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMTQzIDAgUiAvTGVuZ3RoIDg0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJYmBkYMIBGHBLgSTxycLVMLOwsrFzcHJx8/Dy8QsICgkJi4gSD0SEhYQEBQX4+Xh5 uLk4xdhZxZkZGfBaywC0E6fLwHJYZaHaGAACDACMyQa3CmVuZHN0cmVhbQ1lbmRvYmoNNDMzIDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjY5IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMzMgMCBSIC9MZW5ndGggNzQgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRkYMIOGHDKgCXxyYJVMLOwsrFzcHJx 8/Dy8QsICgmTDYQEBfj5eHm4OUXY2UTFWPBZyggCOFwGlcQiC5UBCDAApjkG/AplbmRzdHJlYW0N ZW5kb2JqDTQzNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDI2OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTMyIDAgUiAv TGVuZ3RoIDcwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkZGDCDhhwSxGU ZWJmYWVj5+Dk4ubh5eMXoAoQFBIW4eIUFROXYGVhlsTpKqC7cDgMLInN1RAJRgaAAAMAih0G2wpl bmRzdHJlYW0NZW5kb2JqDTQzNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDI2OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug MTM3IDAgUiAvTGVuZ3RoIDY2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBk YMIBGHBLgSRxyTKzsLKxc3BycfPw8vELUBcICgmLiHJzcXKIsYmzYncVTndBJLHJQiQYGQACDADD mwc+CmVuZHN0cmVhbQ1lbmRvYmoNNDM2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMjY2IC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxMzYgMCBSIC9MZW5ndGggMTA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJYmBkYMIOGHDKgCWxyjKzsLKxc3BycfPw8vHTCAjw8nBzcQoKCYuwsqA5Cugq7O5CSGLKQiSA Mrj9i0UXvpBgZhEVE2eXkKRlKMAAn5S0jKykBLs4SmBAvYTTxdglIRKMDAABBgBf9g9OCmVuZHN0 cmVhbQ1lbmRvYmoNNDM3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMjY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNDYg MCBSIC9MZW5ndGggNjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRgwgEY cEthSDKzsLKxc3BycfPw8tEL8PJw8wsICgmzMMPdBAQM2B0NlmPE4iOYBANAgAEA3uMHgAplbmRz dHJlYW0NZW5kb2JqDTQzOCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDI2NCAvSGVpZ2h0IDIgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTU2 IDAgUiAvTGVuZ3RoIDk3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvNE3FoAw DANQ2aH3Gjr3PyY8yMsSzBitf7FkEFiILMwgq4AKwihO0iwvSr+p6qbt+mFU+rmDiISbXyM4auAW ue0PWQT0NC/rth+n5w2cKUxV6W3faGe4BBgAxycPwgplbmRzdHJlYW0NZW5kb2JqDTQzOSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI2MiAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTU0IDAgUiAvTGVuZ3RoIDYyIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYMIOGHDKQCSBgJmFlY2dg5OLm4eXb8AA v4CgkLCIqJg4IxBgdTIDAyMjVkmoOCMDQIABADWwCG4KZW5kc3RyZWFtDWVuZG9iag00NDAgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNjEgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE1NyAwIFIgL0xlbmd0aCA1OCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZMIOGBgZcMhAJJlZWNnYOTi5uHl4Bxrw 8QsICrGxCoswYHUyAyMYYMgxwCQYAAIMABQlCBQKZW5kc3RyZWFtDWVuZG9iag00NDEgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTkgL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE1OSAwIFIgL0xlbmd0aCA1MyAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgxAEYmHDJAOWYWVjZ2Dk4ubh5Bgfg5eNgZ2Pl Z8bqDzBgYEAXh0owMQAEGACoFgdLCmVuZHN0cmVhbQ1lbmRvYmoNNDQyIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjU4IC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNTggMCBSIC9MZW5ndGggNDcgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGQiGTCzsLKxc3BycQ8iwMPJwc7Gy8KM4VhGBjDA8CZUnIER IMAAn/kHIgplbmRzdHJlYW0NZW5kb2JqDTQ0MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDI1OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgMTQ4IDAgUiAvTGVuZ3RoIDUxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJYmBkYMIBGLELM7OwsrFzcHINOsDJwc7NysOL6loGBkYQYED3JUQYJAEQYABpYQbECmVu ZHN0cmVhbQ1lbmRvYmoNNDQ0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMjU2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAx NDcgMCBSIC9MZW5ndGggNTAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRg wgEYsYgxs7CysXNwcg1KwMnBzcPLx4/kXAYGRjBA9yNMnJEBIMAAc48G8gplbmRzdHJlYW0NZW5k b2JqDTQ0NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1 NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTUyIDAgUiAvTGVu Z3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYCIWMLOwsrFzcHIN WsDNw8vHL8AMcy8DIxSgeREhzgAQYACCnAcSCmVuZHN0cmVhbQ1lbmRvYmoNNDQ2IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjU0IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNTEgMCBSIC9MZW5ndGggNDggL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRgwgEYUbnMLKxs7BycXIMbcPPw8vFDHMzAwAgB aD6EizMyAAQYAIirBycKZW5kc3RyZWFtDWVuZG9iag00NDcgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDE1MyAwIFIgL0xlbmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiWJgZGAiAjCzsLKxc3ByDXrAzcPGC/YRAwMjBDCgehBJHCDAAIq7ByIKZW5k c3RyZWFtDWVuZG9iag00NDggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIy MiAwIFIgL0xlbmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGDC DhASDMwsrGzsHJxDAnCxcIPdzAgFqN6DCzMyAAQYADS1BoQKZW5kc3RyZWFtDWVuZG9iag00NDkg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNDggL0hlaWdo dCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIyMyAwIFIgL0xlbmd0aCA2OCAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGDCChhgEgzMLKxs7BxDA3BycUMc DwWonmNAiDOgyyF5HErz8PINtHeIBfwCgkLI/mNA8RuytwECDACITQvtCmVuZHN0cmVhbQ1lbmRv YmoNNDUwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjQ2 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyMjUgMCBSIC9MZW5n dGggNTAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRkYMILmFlY2YgF7Byc NAAcXERaz83DC/QMAwMjBDAg+wwuChIHCDAAt6gFjgplbmRzdHJlYW0NZW5kb2JqDTQ1MSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI0NCAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjIwIDAgUiAvTGVuZ3RoIDYyIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBgZGDCCqDizCysbOzEAQ5OLm4eXl5eHqoB kGHcXJwcxNnPxy8AdDMDIxQg+4sBLgoUBwgwAFQ5BukKZW5kc3RyZWFtDWVuZG9iag00NTIgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNDIgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIyNiAwIFIgL0xlbmd0aCA2OSAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGRgwgYYoOLMLKxsxAF2Dk5mZi4uLmZm bmaCgJuwGm5uHh6gYbwc7ERZz8fPKwByNhQwoHoGLswAEGAA3Y0D+QplbmRzdHJlYW0NZW5kb2Jq DTQ1MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI0MCAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjE3IDAgUiAvTGVuZ3Ro IDY1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjI1HCgAgEMSy9vb/94oNBBXM cWASREBdQPqsjXX+ixAT63k1bm5e1S3fAFIMf/lc6OJ5PFxjrgIMAJnEA1gKZW5kc3RyZWFtDWVu ZG9iag00NTQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAy MzggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIxOSAwIFIgL0xl bmd0aCA2NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGRgYMICGBjBwsws rGxEAXYOZlSdeAADIyElQBUQhzFzsBNlPScXNwMDWBcjqo8QokBhgAADAGoqAvoKZW5kc3RyZWFt DWVuZG9iag00NTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAyMzYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIxNiAwIFIg L0xlbmd0aCA2NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGRkYGDCAAxA YSDFzMLKxk4M4ODkguvEYhw2s/EoAKqAqOHi5CDGdm4eXmawHkaYRmSDoKIMAAEGAI8/A1YKZW5k c3RyZWFtDWVuZG9iag00NTYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyMzQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIy OCAwIFIgL0xlbmd0aCA2NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGRk YGDCAAxAYSDFzMLKRgxg5+BE1YgHEFQBVMAIUcPJwU6E5VzcPLwQPTB9UHMQgkA/AgQYAGIrAwIK ZW5kc3RyZWFtDWVuZG9iag00NTcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAyMzMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDIyNyAwIFIgL0xlbmd0aCA2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYyP 2w4AEAxDW7cZ/v97RYQQIs5j07UdQBIwB0CTrfPhB4k6D3lJ25L5drRF7B6N8lGecuFgeQXgIlcB BgBZtQLwCmVuZHN0cmVhbQ1lbmRvYmoNNDU4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMjMwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxOTQgMCBSIC9MZW5ndGggNjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIliYGAEAgYmDAAUZ2BgZmFlYycCcHByITRiMQzdYALyIBeB1HBxchBhOTcPLyMUINnNwMCI EAUIMAB3hQM+CmVuZHN0cmVhbQ1lbmRvYmoNNDU5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMjI4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAxOTkgMCBSIC9MZW5ndGggNjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIliYGBkZGRgYMIADCBhZhZWNnbCgIOTC6GREdMsdHPxSYPcA1XCxclB2G5uHl4+Rihg QJjCwAgXZAAIMABwbAM+CmVuZHN0cmVhbQ1lbmRvYmoNNDYwIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjI1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSAyMDEgMCBSIC9MZW5ndGggNjMgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIliYGBkZGBgYEIHYGFmFlY2woCdgxOhjxHDJAxj8UuDAFgJFzcPYbt5+fgZ oXrg5jJATYGIAgQYAEYyAuwKZW5kc3RyZWFtDWVuZG9iag00NjEgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDIwMyAwIFIgL0xlbmd0aCA2MiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiWJgYAQCBgYmNAASZmZhZSMM2Dk40TXjBEBTMWxCkgW7BaqEmYubsN08 LLyMSHqQzIAIMgAEGAA/yQLVCmVuZHN0cmVhbQ1lbmRvYmoNNDYyIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjIxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAyMDIgMCBSIC9MZW5ndGggNjQgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYAQBBgYmNMDAyMjMwsrGThBwcHIhaWNENwfdUAyLUGTBbgFzuHl4 CVrNxy/AjKwHbgRUkAEgwABhNgM1CmVuZHN0cmVhbQ1lbmRvYmoNNDYzIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjE4IC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyMTQgMCBSIC9MZW5ndGggNjMgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGAEAQYGJhTAABRmZmFlIwjYOTiZiAVAMxlwS6I4hIubh5eP H6/NAoJCwshaGBigRkAFAQIMADqvAwEKZW5kc3RyZWFtDWVuZG9iag00NjQgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMTYgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE5MyAwIFIgL0xlbmd0aCA3NiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgYAQBBgYmFMDAwMjMwsrGTgBwcHJxI2tjZMIDgDYx4JME uwPK4+Hl42cVEBTiEBbBYbWomDjE4QwQ90INgBrDABBgAF6nA2oKZW5kc3RyZWFtDWVuZG9iag00 NjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMTIgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE5NyAwIFIgL0xlbmd0aCA4 MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXyOVw6AIADFigvBgXt7/2uqUYma YL/bvAfiAPAegPCDMHIiY6WTNMvNq/pl33HKnCesQFFWddN2/TBOs1Yqlt8Dy2pscNcXsAkwAFzy A7AKZW5kc3RyZWFtDWVuZG9iag00NjYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCAyMDkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDIwNSAwIFIgL0xlbmd0aCA4OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iWzORxKAIAADwCDYqSr2+v9POnBwUNlzMglAHABJAJSlWR5TlFXNhVTaNO2r8oEPPxHhor8HAO2s 7QdmtJJS8HGal3V7PuzHefmGnyEh4BZgAGnlBAEKZW5kc3RyZWFtDWVuZG9iag00NjcgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMDYgL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIwOSAwIFIgL0xlbmd0aCA5NCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWyO2RZAMBBDU4putFNL1fL/v4m+UNynOTnJJABL AMUDlLyqXzRCKm1a3llH3vdDFrgyT9iHHynVAveF7BsbpxCInJ3jsrZGq02K/RyiIyV78a4BDgEG AEsaA48KZW5kc3RyZWFtDWVuZG9iag00NjggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAyMDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDIwOCAwIFIgL0xlbmd0aCA4MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgYAQDBgYmBGBmYWVjhwMOTi5uHl4+fgFBFiFhEWYGZKUMMMCIDhiQACqPGC0IMWYRUVEx IRZBcQl+PkkpaRlZOXlGbPoZGAACDAAU5wMQCmVuZHN0cmVhbQ1lbmRvYmoNNDY5IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjAwIC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyMTAgMCBSIC9MZW5ndGggODYgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlkzVkOgCAMBNABxF0RBdzuf0+DTVqD76vJTFtAvQBo ZipbZ03b9XYYp9kt3qxbAPdAFKNIyDGdI/0n++UpfEYqhpjS7g93XncsP1PvEWAA9I4CkgplbmRz dHJlYW0NZW5kb2JqDTQ3MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDE5NyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjEz IDAgUiAvTGVuZ3RoIDgxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBghAAG BgYmCGBmYWVj5+Dk4ubh5eMXEBQSFmEGyzEwgFUxMMC0QHkQwIQDgDThkoAaAjabAdVomIsQQqJi 4mKi6GogygACDADYYwHyCmVuZHN0cmVhbQ1lbmRvYmoNNDcxIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTk0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSAyMTIgMCBSIC9MZW5ndGggNjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIliYGCEAgYGBiYQYGBmYWVjZ+Pg5OLmYeaFiIGEGZBVggETEQCoCbs6mGnI skh2wOxhxCsAEgIIMACWCAFFCmVuZHN0cmVhbQ1lbmRvYmoNNDcyIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTkwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAyMTEgMCBSIC9MZW5ndGggNTcgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYGCEAQYGBiYmJgZmFlZWVhZmiABYBARQFRELgNqwKoeZx4CmGMkW RjSAKQQUAQgwAGklAQUKZW5kc3RyZWFtDWVuZG9iag00NzMgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxODYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDIwNCAwIFIgL0xlbmd0aCA0OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiWJgYGCEAgYEQBJBYQFJJuIBUAc25QjjkcXgzmBEdgFMhBENAFUABBgATY0A 2AplbmRzdHJlYW0NZW5kb2JqDTQ3NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDE4MiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgMjA0IDAgUiAvTGVuZ3RoIDUwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ YmBgYIQBBjhAE2JiYoKIgZnogBGbIFAHIzYJuNkMmEJQCxkJAKASgAADAEu4ANgKZW5kc3RyZWFt DWVuZG9iag00NzUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAxNzggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIwNCAwIFIg L0xlbmd0aCA1MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgYGCEAQYYQBZh AgOoGIyLBBgYMcXAwljE4SbDzUGyCyzMSAAAHQQQYABKCADUCmVuZHN0cmVhbQ1lbmRvYmoNNDc2 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTczIC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyMDQgMCBSIC9MZW5ndGggNTAg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGBEBQwMSEwQYAICqCCUhwwYGDGE wKKYwnCDYYYwMDBgtxc7ACoHCDAARlYAzAplbmRzdHJlYW0NZW5kb2JqDTQ3NyAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE2OSAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjA0IDAgUiAvTGVuZ3RoIDQ2IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBgYEQCDGCAwmdiYoIJQXhIACiMJoJLFG4mVAbVWkIA aDFAgAEAQJ8AxgplbmRzdHJlYW0NZW5kb2JqDTQ3OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE2NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMjA0IDAgUiAvTGVuZ3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJYmBgYEQCDGCAymdigomAOUgAKIwqgEOQAW4ahItiJSEAtBQgwAA7xQC8CmVuZHN0 cmVhbQ1lbmRvYmoNNDc5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMTYwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyMDQg MCBSIC9MZW5ndGggNDUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGBgRAEM IIDGZUBwmJAAAyMqHyLGiCaG0A3hodmHDwAVAwQYADYhALAKZW5kc3RyZWFtDWVuZG9iag00ODAg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNTUgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIwNCAwIFIgL0xlbmd0aCA0NCAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgYGBEAQyoAgwMCAEgiwkBgKLIXKxC SFqZGNBtwgdAtgIEGAAzEACnCmVuZHN0cmVhbQ1lbmRvYmoNNDgxIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAyMDQgMCBSIC9MZW5ndGggNDQgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYGBgJADgKhiAgAkKGBiBEM6DCjEiCzAgTGZgIGwLioUAAQYALy8A nwplbmRzdHJlYW0NZW5kb2JqDTQ4MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDE0NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgMjA0IDAgUiAvTGVuZ3RoIDQxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ YmBgYMQPEPIMQMAEBgxgHhMSAIog+MhmEjQf2SogAAgwACwAAJgKZW5kc3RyZWFtDWVuZG9iag00 ODMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNDAgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIwNCAwIFIgL0xlbmd0aCA0 MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgAAFGnABFCqSUiYkJogHMhAIg H85DNg2Pwej2AAFAgAEAJRgAiQplbmRzdHJlYW0NZW5kb2JqDTQ4NCAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEzMiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMjA0IDAgUiAvTGVuZ3RoIDMxIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmBgYCQSMEAAhM0EAwxwDvEmoZkJEGAAIY4AgAplbmRzdHJlYW0N ZW5kb2JqDTQ4NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDEyNSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjA0IDAgUiAv TGVuZ3RoIDM3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBgYGAkEjAwQBSD aQYmJiYQjwEKiDUE2SyAAAMAGJQAYwplbmRzdHJlYW0NZW5kb2JqDTQ4NiAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDExOCAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTk4IDAgUiAvTGVuZ3RoIDI2IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJYmAAAkZSAQMDRBsZWsF6AQIMABe1AGYKZW5kc3RyZWFtDWVu ZG9iag00ODcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAx MTEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE5OCAwIFIgL0xl bmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgYGBgpA8A2sQAEGAA FvcAaAplbmRzdHJlYW0NZW5kb2JqDTQ4OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDEwNSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgMTk4IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJYmCAAEbaAYgFAAEGABLlAFwKZW5kc3RyZWFtDWVuZG9iag00ODkgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA5MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTk4IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmBgYGCkMmCAAYAAAwAP1QBRCmVuZHN0cmVhbQ1lbmRvYmoNNDkw IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODIgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE5OCAwIFIgL0xlbmd0aCAyMCAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgAANG6gCQUQABBgALagBICmVuZHN0 cmVhbQ1lbmRvYmoNNDkxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggNzMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE5OCAw IFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJggAJGMgAD EgAIMAAIGwA1CmVuZHN0cmVhbQ1lbmRvYmoNNDkyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggNTQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDE5OCAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiWJgQAGM+ABCGUCAAQADCwAeCmVuZHN0cmVhbQ1lbmRvYmoNNDkzIDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODYgL0hlaWdodCA5MyAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxOTYgMCBSIC9MZW5ndGggMzM0NiAvRmlsdGVyIC9E Q1REZWNvZGUgPj4gDXN0cmVhbQ0K/9j/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsK CxEVDwwMDxUYExMVExMYFxIUFBQUEhcXGxweHBsXJCQnJyQkNTMzMzU7Ozs7Ozs7Ozs7AQ0LCw0O DRAODhAUDg8OFBQQEREQFB0UFBUUFB0lGhcXFxcaJSAjHh4eIyAoKCUlKCgyMjAyMjs7Ozs7Ozs7 Ozv/wAARCABdAFYDASIAAhEBAxEB/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQAB BQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWET InGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N1 4/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcH BgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJE k1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH /9oADAMBAAIRAxEAPwDv/rTjWZPQssVOc26pnrVOYSHB1fv0I8hC8wo+s3X8f+bz79Oznl4+58r2 N7GvY5jxLXAtcPEHReH5lBx8u/HPNNjq9f5JLVS5y4mMgSL008Hp/wDi17eXHnw5IRnwyjMccRL5 tDv5O7R9f/rJUAHXMuj/AElbf++bVfp/xm9TbHr4lNnjtLmH8S5ceyuyxwZW0veeGtEk/IKd+LlY 5AyKbKSePUaWz/nBVxnzDaR/N2Mnwv4fM1LBjBPSI4T/AM2nu6f8Z+Mf5/Ae3zY8O/K1qv0/4xug Wfzjb6v6zAR/0XFeYJJw5vKOoPmGvP8A4vfD5bQlD+7M/wDdW+t1fXb6s28ZgYfB7Ht/K1XKvrD0 K2NmfjmexsaPyleMJJ452fWMWtP/AIscsfly5Y+fDL9gfcq83Ds/m763/wBV7T+QooIIkGQvCERt 9zPo2ObHgSE8c93h+LDL/isP0eZ+3H/6E+6JLxvG6zm19OzcY5FhN/pbZe4kbHbjGuiSd99jXy9L 38WD/kzl4q94Vx8N8H6PDxcW/fR9kXj/ANa8cs+s2dU0avu3AedgDv8Avy9gXlX15LqfrVfY3R0V PHxDG/3I86P1YP8AWWf8WZEc3kiP0sR+0SD3/wBXvq/h9FwmV1sByXNBvvj3Od3E/ujsFoZWJjZl DsfKrbdU8Q5jxIVfo/VsXq+BXmY7gdwHqM7sf3a5XHvZWwve4NY0S5xMAAdyVYiI8AEa4a/ByM88 5zzllMvfEvVfzCT499ZekDo/WLsNhJp0fSTzsdqAfhwspbP1t6tT1Xrd2RQZoYBVU795rPzvmSVj LJycPHLh+WzT6ByZynlsJzfzphHjvfirW/F7f6o/UjGzcNvUeqhzmXa0UAloLf33Ea69guxxfq/0 TEEUYNLfMsDnf5zpK5Jv+MfGxsGjHw8JzrKq2sPqODWgtAbptkn8Fk5P+MD6xXOJrsrx29m1sB/F +5XI5eXxxAA4j1IGv4vO5+R+Mc5lnKcvZxmR4YSyVER6emNvouR0To+UzZfhUvH9RoPyIAK82+un QMXovUa24hPoZDC9tbjJYQYInuPBd99XsrqLehNzeuWgWEOuLnAM21RLd20DtqvNPrJ1l3Wuq25c FtQ9lDT2rbx8zylzRgccTw1KWo70r4DDmo85lh7pnhw8UclSMscpdOG3LSSSVF6l94XlX+MAz9Zb vKusf9EL1VeSfXe31PrNmeDCxg+TGrQ53+bH94PHf8WRfOzPbFL/AKUUX1dwPrFk3us6IbKy07bL Wv2MHk4k6/Bdk36oda6jWG9d6vZZXoTj0/R+ZMD/AKKyv8XtmacTq9OCWDK9Nj8b1QSz1IsDd0QY mJVh/wBTvrP1Bhv+sn1mtpYdX4+FFNTfLf7Qfm1DlsMZYxIkm70vT7GT4z8Sz4ucnixxxwOPh4cg gDk1iD80rr6O7ifUv6s4pA+zC+wd7nF5P9n6P4LyvNY1mZexohrbHgDyDiu9+rv1U+pXTOs05HT+ pHL6nWH7GPyWWOO5pa47GROhK4TqH9Pyf+Nf/wBUUznIRiIcIA32bP8Axc5jNmycwcuSeQ1D55E1 vs111P1I+rJ6nljOy2Tg4ztAeLLBw34DusXonS7Or9TowGO2eqTvf4NaNziPOAvV8rp1tHQ7On9H LcextXp45PA8dfE66+Kj5bDxEzIuMenctv438R9iMeWxyEMufQzO2OB04ni/r39aPtdrukYT/wBW pd+sPb+e8fm/1W/lXGqzn9Ozun3mjNpdTYOzhofNp4I+CrKLLOU5ky37dvB0OR5fDy/Lwx4SJQq+ Ma8ZO8r8VJJJJjZfeF4z9ZLhf1/PsGo9d7QfJp2/wXsd1raan2v+jW0ud8AJXht1puustPNji4/2 jKvc8dIDxJeV/wCK2O8nMZP3Yxh/jG/2PXfUCnOtxesDp9raMw1Mbj2vG5rbD6m0uHhorOR9RX3M 9f63fWbIuB1dW2xuPQPIB8j8An+oWBdldC6oyi9+Jdku9KvJr+kxwZIcPhuVrF/xV/V0P9fqtmT1 fJOr7cm10E/BhB+8lTcqKwx+v5ud8clxfEc/gYR+yIYfVrov+LjB6zS7omTVd1VrXivbkG1xBaQ8 7dxb9GVwea7dmXu8bHn73FeuYH1X+rvSrW5OB0+jGvqaQ25jAHgEQfdzwvILXbrHu/ecT95UHPbQ +rp/8Vh6uZPhjH/SS4Gdk9Py68zFdsupMtPI8CCPAhd90z/GTgWtazqVLsazvZX72fGPpD8V5ytn oP1W6n1uwGlvpYoPvyXj2/Bv7x+Cr4cmWJrHrf6LsfEuT5HNj9zm6hwChkvhkPDx8n0myv6v/WbE ImrMrbpuafewn7nNXnX1r+rTug5TAyw24uRJpcfpDbEtd8J5XpXROhYPRMT7PiNJLtbbXfSe7xP8 AuC/xgdZo6h1KrGxnCyrCa5rnjUGxxG4D4bQrXMxHtCUwBk02cP4HlyDnpYeWnOfJjiJGToK0PgS XlwwlrnDhsT80loYOKbOjdTyI0o9CT/XeWpKlw6X4cX409N78ePg/wBZ7X19v3PyfTvrdmfY/q7m 2TDn1+k342HZ+Qrx9ehf4zM7Zh4mA062vNrx5MG0fi5eeqfnJXkr90U5f/FzBwclxnfNOUvoPSPy L6p/i/x/R+rdT4g32WWfjs/76ukXO9G630DpvRcPGtz6Q+qlm9ocHEOI3O0bPcoeV/jB+rtAPpPs yXDtWwgffZtVuE8cMcQZAUB1ed5nleb5nm808eDJITyTIPAaq9NXoM1/p4d9n7lb3fc0leKYeFlZ 2SzFxKzddYfaxv4ldT1f/GJl5lFuNh4zaKrWuY57zvftcIMRAH4rlcTMysLIbk4ljqbmfRe3nXQq pzOWGSUaJMY7/wBj0HwTkOa5TDnM4xhly1wCRsXEGuLh83v+g/4vMbH25HVyMi3kY7f5sf1j+d+R dD1LrfR+iUAZNrKg0RXj1gF5Hg1jf9y8wu+tn1jvYWWZ9u087IYfvYAVlPe+xxe9xe92rnOMknzJ RHMwhGsUK8ZMcvgnM81l9znuZ4ojaGLb6Xt9j0vX/r31HqYfj4k4eI7Qhp/SOH8p3b4Bcwkkq85y mbkbdrl+Vw8vD28MBCPhufEnq9L0umPqP1q+Pp20Mn+pZWf+/pLQx6DX/izynxHrWh/xi+tn/fUl Y4fTX+p4v+dbke/+t4//AD5+1/4z7bl/XrPGZ9YbmtMsxQKG/Furv+kSsKqi+922mt1rvBjS4/gv Renf8wfXd/N/a959T7bO/fOs+r7ZnwXU4v2P0/1T0/T/AOC27f8Ao6IywCU5GeWMSTtazD8VyYuX xY+V5HPmhCAjGZgRGVdfSJbvkmP9U/rHkgGvBtAPeyK/+rLVoU/4u/rFZ9MU0+T7J/6gOXqKScMH LjfID/hBgyfFvjMvk5OUP+o5CXzln+LLqZ/nMuhvwD3fwCn/AONjm/8Ac6r/ADHf3r0NJO9rlf3o /wCOwH4h8d/zWUf+m/8A6C+cWf4s+qtH6LKof5He3/vpWflfUP6yY4LhQ28DvU8H8HbSvV0kDh5Y 7TA/wwyY/ifxuJ9XLTyf3uXkP+jT4dlYObhv2ZdFlDuwsaW/dKAvccz7F9nd9u9P7PHv9aNnz3aL zT6yj6lmx37Lfay/v6DQ6gnw/SOaR/Z0UGTBEawyRl4WLdTlPiufIRHmOSz4SdOOOOUofXSw9X9g P/jf/Zo932L1Y849b8qS3P1b9k/91vs//gez+5JXeGPcfzfDv07+TzXv5/8ANz/3Z7vyn+c/c/ve D//ZCmVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTIx IDAgUiANL1Jlc291cmNlcyA8PCAvQ29sb3JTcGFjZSA8PCAvQ1MzIDE5NiAwIFIgL0NTNCAxOTUg MCBSIC9DUzUgNSAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR1MyIDMwNiAwIFIgL0dTMyAzMDUgMCBS ID4+IA0vRm9udCA8PCAvVFQyIDIwNiAwIFIgL1RUMyAyMzggMCBSID4+IC9YT2JqZWN0IDw8IC9J bTEgNCAwIFIgPj4gDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSA+PiAN L0NvbnRlbnRzIDIgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAg MCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANL1N0cnVjdFBhcmVudHMgNiANPj4gDWVuZG9iag0yIDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMyAwIFIgPj4gDXN0cmVhbQ0KSIms lstO3DAUhvd5irNsJerxJb5VVRcMFaUVKoVIbLoxGXeSksTUTkD06etMplBKkgFUzWIcaeb/zsXn z1mcwLt3i+Pl0QFgeP9+/2CZLJZnDPIQn/sPhLxJCJSQLE5tZdry2i5d5XxZ29aXOfgyWRyeUViH ZD9LFllGgUD2PSEEaa02Etsj1RJxTShIgRHmKWR18gpeZz+SD1ny4TiC72Mh21geSL6Jf8OYQ5ZD f6ISsht4zJEYKaoJyFQgysXAyQoLK2tWVdlY+O48mNW1aXILhWttBd4G669jdq6BMsCnLv6KiD2g EYMmYqRjMeJNdDsCYxSlXMm5ArBR8T5rukOcKCQEIRvxk8qaYGN2ta0vrIe2MG1Mrrrtk2xd58vQ xh72IQzFZXfF5eMYKllsIqcPOUW5LiBEVl++Bg6tr01zi+DcQmi9a9aRGAtexljuWbRnzSSCU6QE 4xvAretivHDh3CXEs9+2zQQILjLj95ULobyoLIKJiqYvbZfQBGHB9Vy7+Jj4jKSUiApF5yTFMyUF Q6nEYk5STk/VzsbfcVKNhGQbTGyv8Raq2JWyWfdjdWP8qm/Uja1yV9u+V/2FOP/GZOp/XXR+PTVN 6sXtYRwpOW8n+qXTJChFWMphVPdtaOHUrmOOYW/KuPD/qDFWiCq8neGiczlk3jRvDkszhZ0xzB1z xnWKUkWHOftkahvg1EWzaMMUa9z4ehS5y5DMZ8gVRkKlagP93PkWsq4NeXHZTUFHDfGZdeVCIKXk MHbHZV6Y6CHHtmmLKeq4afQosQPFGcJKD+P4uTJdgI82v9wb3OvopH+xwBe/Nk35q5+dzJp6KoiH 5sKePhqcaUQZmXUuIsbUZzQpRylL2aymHNN82m2Mz0KL4TaeXbkmOP92CqMmCzMNSOMWorQaqclR 0y8HZ4W5sveIP84RdxwWdxz4mWiKtEr5oB1tXEqyFYc02rpWBPI6qtUEDlzy9dHWgO8V/9qaJutO oq8rEl+Df8T/jfu3AAMAzFhDEQ1lbmRzdHJlYW0NZW5kb2JqDTMgMCBvYmoNNzYzIA1lbmRvYmoN NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEyNCAvSGVp Z2h0IDIzIC9CaXRzUGVyQ29tcG9uZW50IDQgDS9Db2xvclNwYWNlIDUgMCBSIC9MZW5ndGggNTcw IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJpJTBitpQFIafQabbFqT7LvoAQukz 3EDS4M4BrbrvcnZ9gQg60Z2BEc1bGIiY7DpUmpzF0IlGcv5n6LlqO7EYOkxPDpebk/Nx7n/uvfn+ 9WAxXmQ3tbf1q3qtUQqxN3TXz6Rfof5md0bn4zSwyjlF5cpuGkLr8an0MkZyRueV9AfS9MO7Usgh cKeck1XS76HpnyWahcasnDOtpD8e6F2jXHsCrJPZLF7N4mK4iEI1mlPhjMCzSehSOJJODOfRKVvo svHSiEA8taKkHXlR0Fy1RnNeLoIJB7brzF3H52ARdi/T2CrlilibuJtaSJpwYmKD9jZtTMralDUx AB9o1de0jHg0jq9Ip0qNsTdR9AsT6LMTY29B5lsLG3EbBrGrCdU80E2ZK0039drvlAlWtPdZuRRL beSWDuQ2ju50KdXEJRrpRhE7fkaYqjahFeObMWyrOLNxcF4qMz4Rf+seS/WWj2U/lOZeiwip/Wiu 1+un2uyoiq5pRTz1+f6TCyb2LK07s1g+ieKjUxqYFT2X/dQHJDd7KHwkJjnRPj8c3T+1x0hbdKJf n9PXEh/IotUERQ8wRXeeSBs3+K0bsvbBMXlXu6Iz2hmjsCXUivQuFTY8PyTpnEvZZ5Gu3aTTTXio iZ3pvvVmA+koPH0iR16M+2sXm86dnzjGZGtMNobfGXk+LhvzKiKkx5uSRAyWfwWvFiQ9BIggTxJV wBpPZc/iXmXCP61Q6/HLaXzx6D/oH4tn0L8EGACmAoW4CmVuZHN0cmVhbQ1lbmRvYmoNNSAwIG9i ag1bIA0vSW5kZXhlZCAxOTYgMCBSIDE1IDYgMCBSIA1dDWVuZG9iag02IDAgb2JqDTw8IC9MZW5n dGggNDkgPj4gDXN0cmVhbQ0KAAAA/wBm/DqI+XKp+Iy3oKCgqKiotbW19rXQvLy8ycnJ1tbW3t7e 7ezs8/PzAAAACmVuZHN0cmVhbQ1lbmRvYmoNNyAwIG9iag08PCANL1MgL1RpdGVsIA0vQyAvVGl0 ZWwgDS9QZyAxMjUgMCBSIA0vSyAwIA0vUCAxMDEgMCBSIA0+PiANZW5kb2JqDTggMCBvYmoNPDwg DS9UaXRlbCAvUCANL1N0YW5kYXJkIC9QIA0vVGV4dGsjQzMjQjZycGVyIC9QIA0vVGV4dEJveCAv RGl2IA0vRnJhbWUgL0RpdiANL0Zvb3Rub3RlIC9Ob3RlIA0vRW5kbm90ZSAvTm90ZSANL1NoYXBl IC9GaWd1cmUgDS9JbmxpbmVTaGFwZSAvRmlndXJlIA0vVE9BIC9UT0MgDS9UT0FJIC9UT0NJIA0v VE9GIC9UT0MgDS9UT0ZJIC9UT0NJIA0vU3VwZXJzY3JpcHQgL1NwYW4gDS9TdWJzY3JpcHQgL1Nw YW4gDS9TdHJpa2VvdXQgL1NwYW4gDS9VbmRlcmxpbmUgL1NwYW4gDS9Ecm9wQ2FwIC9GaWd1cmUg DT4+IA1lbmRvYmoNOSAwIG9iag08PCANL1RpdGVsIDEwIDAgUiANL1N0YW5kYXJkIDE0IDAgUiAN L1RleHRrI0MzI0I2cnBlciAyNyAwIFIgDT4+IA1lbmRvYmoNMTAgMCBvYmoNPDwgDS9PIC9MYXlv dXQgDS9Xcml0aW5nTW9kZSAvTHJUYiANL1N0YXJ0SW5kZW50IDAgDS9FbmRJbmRlbnQgMCANL1Rl eHRBbGlnbiAvQ2VudGVyIA0vU3BhY2VCZWZvcmUgMCANL1NwYWNlQWZ0ZXIgMCANL1RleHRJbmRl bnQgMCANPj4gDWVuZG9iag0xMSAwIG9iag08PCANL1MgL1RpdGVsIA0vQyAvVGl0ZWwgDS9QZyAx MjUgMCBSIA0vSyAxIA0vUCAxMDEgMCBSIA0+PiANZW5kb2JqDTEyIDAgb2JqDTw8IA0vUyAvU3Rh bmRhcmQgDS9BIFsgMTMgMCBSIF0gDS9DIC9TdGFuZGFyZCANL1BnIDEyNSAwIFIgDS9LIFsgMTUg MCBSIDMgXSANL1AgMTAxIDAgUiANPj4gDWVuZG9iag0xMyAwIG9iag08PCANL08gL0xheW91dCAN L1RleHRBbGlnbiAvQ2VudGVyIA0+PiANZW5kb2JqDTE0IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0v V3JpdGluZ01vZGUgL0xyVGIgDS9TdGFydEluZGVudCAwIA0vRW5kSW5kZW50IDAgDS9UZXh0QWxp Z24gL1N0YXJ0IA0vU3BhY2VCZWZvcmUgMCANL1NwYWNlQWZ0ZXIgMCANL1RleHRJbmRlbnQgMCAN Pj4gDWVuZG9iag0xNSAwIG9iag08PCANL1MgL0lubGluZVNoYXBlIA0vUGcgMTI1IDAgUiANL0sg MiANL1AgMTIgMCBSIA0vQWx0ICgpDS9BIFsgMTEzIDAgUiBdIA0+PiANZW5kb2JqDTE2IDAgb2Jq DTw8IA0vUyAvU3RhbmRhcmQgDS9BIFsgMTcgMCBSIF0gDS9DIC9TdGFuZGFyZCANL1BnIDEyNSAw IFIgDS9LIDQgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoNMTcgMCBvYmoNPDwgDS9PIC9MYXlvdXQg DS9UZXh0QWxpZ24gL0NlbnRlciANPj4gDWVuZG9iag0xOCAwIG9iag08PCANL1MgL1N0YW5kYXJk IA0vQSBbIDE5IDAgUiBdIA0vQyAvU3RhbmRhcmQgDS9QZyAxMjUgMCBSIA0vSyA1IA0vUCAxMDEg MCBSIA0+PiANZW5kb2JqDTE5IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50 ZXIgDT4+IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0EgWyAyMSAwIFIgXSAN L0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiANL0sgNiANL1AgMTAxIDAgUiANPj4gDWVuZG9iag0y MSAwIG9iag08PCANL08gL0xheW91dCANL1RleHRBbGlnbiAvQ2VudGVyIA0+PiANZW5kb2JqDTIy IDAgb2JqDTw8IA0vUyAvU3RhbmRhcmQgDS9BIFsgMjMgMCBSIF0gDS9DIC9TdGFuZGFyZCANL1Bn IDEyNSAwIFIgDS9LIFsgNyAyNCAwIFIgOSBdIA0vUCAxMDEgMCBSIA0+PiANZW5kb2JqDTIzIDAg b2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDT4+IA1lbmRvYmoNMjQgMCBv YmoNPDwgDS9TIC9TdXBlcnNjcmlwdCANL1AgMjIgMCBSIA0vQSAxMDYgMCBSIA0vUGcgMTI1IDAg UiANL0sgOCANPj4gDWVuZG9iag0yNSAwIG9iag08PCANL1MgL1RleHRrI0MzI0I2cnBlciANL0Eg WyAyNiAwIFIgXSANL0MgL1RleHRrI0MzI0I2cnBlciANL1BnIDEyNSAwIFIgDS9LIDEwIA0vUCAx MDEgMCBSIA0+PiANZW5kb2JqDTI2IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9D ZW50ZXIgDT4+IA1lbmRvYmoNMjcgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9Xcml0aW5nTW9kZSAv THJUYiANL1N0YXJ0SW5kZW50IDAgDS9FbmRJbmRlbnQgMCANL1RleHRBbGlnbiAvU3RhcnQgDS9T cGFjZUJlZm9yZSAwIA0vU3BhY2VBZnRlciAwIA0vVGV4dEluZGVudCAwIA0+PiANZW5kb2JqDTI4 IDAgb2JqDTw8IA0vUyAvVGV4dGsjQzMjQjZycGVyIA0vQSBbIDI5IDAgUiBdIA0vQyAvVGV4dGsj QzMjQjZycGVyIA0vUGcgMTI1IDAgUiANL0sgMTEgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoNMjkg MCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0QWxpZ24gL0NlbnRlciANPj4gDWVuZG9iag0zMCAw IG9iag08PCANL1MgL1RleHRrI0MzI0I2cnBlciANL0EgWyAzMSAwIFIgXSANL0MgL1RleHRrI0Mz I0I2cnBlciANL1BnIDEyNSAwIFIgDS9LIFsgMzIgMCBSIDEzIF0gDS9QIDEwMSAwIFIgDT4+IA1l bmRvYmoNMzEgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0QWxpZ24gL0NlbnRlciANPj4gDWVu ZG9iag0zMiAwIG9iag08PCANL1MgL0xpbmsgDS9QIDMwIDAgUiANL0sgWyAzMyAwIFIgPDwgL1R5 cGUgL09CSlIgL1BnIDEyNSAwIFIgL09iaiAxMjcgMCBSID4+IF0gDT4+IA1lbmRvYmoNMzMgMCBv YmoNPDwgDS9TIC9VbmRlcmxpbmUgDS9QIDMyIDAgUiANL0EgMTA3IDAgUiANL1BnIDEyNSAwIFIg DS9LIDEyIA0+PiANZW5kb2JqDTM0IDAgb2JqDTw8IA0vUyAvVGV4dGsjQzMjQjZycGVyIA0vQSBb IDM1IDAgUiBdIA0vQyAvVGV4dGsjQzMjQjZycGVyIA0vUGcgMTI1IDAgUiANL0sgWyAzNiAwIFIg MTUgXSANL1AgMTAxIDAgUiANPj4gDWVuZG9iag0zNSAwIG9iag08PCANL08gL0xheW91dCANL1Rl eHRBbGlnbiAvQ2VudGVyIA0+PiANZW5kb2JqDTM2IDAgb2JqDTw8IA0vUyAvTGluayANL1AgMzQg MCBSIA0vSyBbIDM3IDAgUiA8PCAvVHlwZSAvT0JKUiAvUGcgMTI1IDAgUiAvT2JqIDEyOCAwIFIg Pj4gXSANPj4gDWVuZG9iag0zNyAwIG9iag08PCANL1MgL1VuZGVybGluZSANL1AgMzYgMCBSIA0v QSAxMDggMCBSIA0vUGcgMTI1IDAgUiANL0sgMTQgDT4+IA1lbmRvYmoNMzggMCBvYmoNPDwgDS9T IC9TdGFuZGFyZCANL0EgWyAzOSAwIFIgXSANL0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiANL0sg MTYgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoNMzkgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFy dEluZGVudCAxMDYuMzUwMDEgDS9UZXh0QWxpZ24gL0NlbnRlciANPj4gDWVuZG9iag00MCAwIG9i ag08PCANL1MgL1N0YW5kYXJkIA0vQSBbIDQxIDAgUiBdIA0vQyAvU3RhbmRhcmQgDS9QZyAxMjUg MCBSIA0vSyAxNyANL1AgMTAxIDAgUiANPj4gDWVuZG9iag00MSAwIG9iag08PCANL08gL0xheW91 dCANL1RleHRBbGlnbiAvQ2VudGVyIA0+PiANZW5kb2JqDTQyIDAgb2JqDTw8IA0vUyAvU3RhbmRh cmQgDS9BIFsgNDMgMCBSIF0gDS9DIC9TdGFuZGFyZCANL1BnIDEyNSAwIFIgDS9LIDE4IA0vUCAx MDEgMCBSIA0+PiANZW5kb2JqDTQzIDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9D ZW50ZXIgDT4+IA1lbmRvYmoNNDQgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0EgWyA0NSAwIFIg XSANL0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiANL0sgMTkgDS9QIDEwMSAwIFIgDT4+IA1lbmRv YmoNNDUgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0QWxpZ24gL0p1c3RpZnkgDT4+IA1lbmRv YmoNNDYgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0EgWyA0NyAwIFIgXSANL0MgL1N0YW5kYXJk IA0vUGcgMTI1IDAgUiANL0sgMjAgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoNNDcgMCBvYmoNPDwg DS9PIC9MYXlvdXQgDS9UZXh0QWxpZ24gL0p1c3RpZnkgDT4+IA1lbmRvYmoNNDggMCBvYmoNPDwg DS9TIC9TdGFuZGFyZCANL0EgWyA0OSAwIFIgXSANL0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiAN L0sgMjEgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoNNDkgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9U ZXh0QWxpZ24gL0p1c3RpZnkgDT4+IA1lbmRvYmoNNTAgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCAN L0EgWyA1MSAwIFIgXSANL0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiANL0sgMjIgDS9QIDEwMSAw IFIgDT4+IA1lbmRvYmoNNTEgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0QWxpZ24gL0p1c3Rp ZnkgDT4+IA1lbmRvYmoNNTIgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0EgWyA1MyAwIFIgXSAN L0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiANL0sgMjMgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoN NTMgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0QWxpZ24gL0p1c3RpZnkgDT4+IA1lbmRvYmoN NTQgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0EgWyA1NSAwIFIgXSANL0MgL1N0YW5kYXJkIA0v UGcgMTI1IDAgUiANL0sgMjQgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoNNTUgMCBvYmoNPDwgDS9P IC9MYXlvdXQgDS9UZXh0QWxpZ24gL0p1c3RpZnkgDT4+IA1lbmRvYmoNNTYgMCBvYmoNPDwgDS9T IC9TdGFuZGFyZCANL0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiANL0sgMjUgDS9QIDEwMSAwIFIg DT4+IA1lbmRvYmoNNTcgMCBvYmoNPDwgDS9TIC9UZXh0ayNDMyNCNnJwZXIgDS9BIFsgNTggMCBS IF0gDS9DIC9UZXh0ayNDMyNCNnJwZXIgDS9QZyAxMjUgMCBSIA0vSyBbIDU5IDAgUiAyNyBdIA0v UCAxMDEgMCBSIA0+PiANZW5kb2JqDTU4IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWdu IC9DZW50ZXIgDT4+IA1lbmRvYmoNNTkgMCBvYmoNPDwgDS9TIC9MaW5rIA0vUCA1NyAwIFIgDS9L IFsgNjAgMCBSIDw8IC9UeXBlIC9PQkpSIC9QZyAxMjUgMCBSIC9PYmogMTI5IDAgUiA+PiBdIA0+ PiANZW5kb2JqDTYwIDAgb2JqDTw8IA0vUyAvVW5kZXJsaW5lIA0vUCA1OSAwIFIgDS9BIDEwOSAw IFIgDS9QZyAxMjUgMCBSIA0vSyAyNiANPj4gDWVuZG9iag02MSAwIG9iag08PCANL1MgL1N0YW5k YXJkIA0vQyAvU3RhbmRhcmQgDS9QZyAxMjUgMCBSIA0vSyAyOCANL1AgMTAxIDAgUiANPj4gDWVu ZG9iag02MiAwIG9iag08PCANL1MgL1N0YW5kYXJkIA0vQyAvU3RhbmRhcmQgDS9QZyAxMjUgMCBS IA0vSyAyOSANL1AgMTAxIDAgUiANPj4gDWVuZG9iag02MyAwIG9iag08PCANL1MgL1N0YW5kYXJk IA0vQyAvU3RhbmRhcmQgDS9QZyAxMjUgMCBSIA0vSyAzMCANL1AgMTAxIDAgUiANPj4gDWVuZG9i ag02NCAwIG9iag08PCANL1MgL1N0YW5kYXJkIA0vQSBbIDY1IDAgUiBdIA0vQyAvU3RhbmRhcmQg DS9QZyAxMjUgMCBSIA0vSyBbIDY2IDAgUiAzMiBdIA0vUCAxMDEgMCBSIA0+PiANZW5kb2JqDTY1 IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vU3RhcnRJbmRlbnQgMzUuNDAwMDEgDS9UZXh0SW5kZW50 IDM1LjQwMDAxIA0+PiANZW5kb2JqDTY2IDAgb2JqDTw8IA0vUyAvTGluayANL1AgNjQgMCBSIA0v SyBbIDY3IDAgUiA8PCAvVHlwZSAvT0JKUiAvUGcgMTI1IDAgUiAvT2JqIDEzMCAwIFIgPj4gXSAN Pj4gDWVuZG9iag02NyAwIG9iag08PCANL1MgL1VuZGVybGluZSANL1AgNjYgMCBSIA0vQSAxMTAg MCBSIA0vUGcgMTI1IDAgUiANL0sgMzEgDT4+IA1lbmRvYmoNNjggMCBvYmoNPDwgDS9TIC9TdGFu ZGFyZCANL0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiANL0sgMzMgDS9QIDEwMSAwIFIgDT4+IA1l bmRvYmoNNjkgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAg UiANL0sgMzQgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoNNzAgMCBvYmoNPDwgDS9TIC9TdGFuZGFy ZCANL0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiANL0sgMzUgDS9QIDEwMSAwIFIgDT4+IA1lbmRv YmoNNzEgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiAN L0sgMzYgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoNNzIgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCAN L0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiANL0sgMzcgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoN NzMgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0EgWyA3NCAwIFIgXSANL0MgL1N0YW5kYXJkIA0v UGcgMTI1IDAgUiANL0sgWyA3NSAwIFIgMzkgXSANL1AgMTAxIDAgUiANPj4gDWVuZG9iag03NCAw IG9iag08PCANL08gL0xheW91dCANL1RleHRBbGlnbiAvQ2VudGVyIA0+PiANZW5kb2JqDTc1IDAg b2JqDTw8IA0vUyAvTGluayANL1AgNzMgMCBSIA0vSyBbIDc2IDAgUiA8PCAvVHlwZSAvT0JKUiAv UGcgMTI1IDAgUiAvT2JqIDEzMSAwIFIgPj4gXSANPj4gDWVuZG9iag03NiAwIG9iag08PCANL1Mg L1VuZGVybGluZSANL1AgNzUgMCBSIA0vQSAxMTEgMCBSIA0vUGcgMTI1IDAgUiANL0sgMzggDT4+ IA1lbmRvYmoNNzcgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0EgWyA3OCAwIFIgXSANL0MgL1N0 YW5kYXJkIA0vUGcgMSAwIFIgDS9LIDAgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoNNzggMCBvYmoN PDwgDS9PIC9MYXlvdXQgDS9UZXh0QWxpZ24gL0NlbnRlciANPj4gDWVuZG9iag03OSAwIG9iag08 PCANL1MgL1N0YW5kYXJkIA0vQyAvU3RhbmRhcmQgDS9QZyAxIDAgUiANL0sgMSANL1AgMTAxIDAg UiANPj4gDWVuZG9iag04MCAwIG9iag08PCANL1MgL1N0YW5kYXJkIA0vQyAvU3RhbmRhcmQgDS9Q ZyAxIDAgUiANL0sgMiANL1AgMTAxIDAgUiANPj4gDWVuZG9iag04MSAwIG9iag08PCANL1MgL1N0 YW5kYXJkIA0vQyAvU3RhbmRhcmQgDS9QZyAxIDAgUiANL0sgMyANL1AgMTAxIDAgUiANPj4gDWVu ZG9iag04MiAwIG9iag08PCANL1MgL1N0YW5kYXJkIA0vQyAvU3RhbmRhcmQgDS9QZyAxIDAgUiAN L0sgNCANL1AgMTAxIDAgUiANPj4gDWVuZG9iag04MyAwIG9iag08PCANL1MgL1N0YW5kYXJkIA0v QyAvU3RhbmRhcmQgDS9QZyAxIDAgUiANL0sgNSANL1AgMTAxIDAgUiANPj4gDWVuZG9iag04NCAw IG9iag08PCANL1MgL1N0YW5kYXJkIA0vQyAvU3RhbmRhcmQgDS9QZyAxIDAgUiANL0sgNiANL1Ag MTAxIDAgUiANPj4gDWVuZG9iag04NSAwIG9iag08PCANL1MgL1N0YW5kYXJkIA0vQyAvU3RhbmRh cmQgDS9QZyAxIDAgUiANL0sgNyANL1AgMTAxIDAgUiANPj4gDWVuZG9iag04NiAwIG9iag08PCAN L1MgL1N0YW5kYXJkIA0vQyAvU3RhbmRhcmQgDS9QZyAxIDAgUiANL0sgOCANL1AgMTAxIDAgUiAN Pj4gDWVuZG9iag04NyAwIG9iag08PCANL1MgL1N0YW5kYXJkIA0vQyAvU3RhbmRhcmQgDS9QZyAx IDAgUiANL0sgOSANL1AgMTAxIDAgUiANPj4gDWVuZG9iag04OCAwIG9iag08PCANL1MgL1N0YW5k YXJkIA0vQyAvU3RhbmRhcmQgDS9QZyAxIDAgUiANL0sgMTAgDS9QIDEwMSAwIFIgDT4+IA1lbmRv YmoNODkgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0MgL1N0YW5kYXJkIA0vUGcgMSAwIFIgDS9L IDExIA0vUCAxMDEgMCBSIA0+PiANZW5kb2JqDTkwIDAgb2JqDTw8IA0vUyAvU3RhbmRhcmQgDS9D IC9TdGFuZGFyZCANL1BnIDEgMCBSIA0vSyAxMiANL1AgMTAxIDAgUiANPj4gDWVuZG9iag05MSAw IG9iag08PCANL1MgL1N0YW5kYXJkIA0vQyAvU3RhbmRhcmQgDS9QZyAxIDAgUiANL0sgMTMgDS9Q IDEwMSAwIFIgDT4+IA1lbmRvYmoNOTIgMCBvYmoNPDwgDS9TIC9TdGFuZGFyZCANL0MgL1N0YW5k YXJkIA0vUGcgMSAwIFIgDS9LIDE0IA0vUCAxMDEgMCBSIA0+PiANZW5kb2JqDTkzIDAgb2JqDTw8 IA0vUyAvU3RhbmRhcmQgDS9DIC9TdGFuZGFyZCANL1BnIDEgMCBSIA0vSyAxNSANL1AgMTAxIDAg UiANPj4gDWVuZG9iag05NCAwIG9iag08PCANL1MgL1N0YW5kYXJkIA0vQyAvU3RhbmRhcmQgDS9Q ZyAxIDAgUiANL0sgMTYgDS9QIDEwMSAwIFIgDT4+IA1lbmRvYmoNOTUgMCBvYmoNPDwgDS9TIC9T dGFuZGFyZCANL0MgL1N0YW5kYXJkIA0vUGcgMSAwIFIgDS9LIDE3IA0vUCAxMDEgMCBSIA0+PiAN ZW5kb2JqDTk2IDAgb2JqDTw8IA0vUyAvU3RhbmRhcmQgDS9DIC9TdGFuZGFyZCANL1BnIDEgMCBS IA0vSyAxOCANL1AgMTAxIDAgUiANPj4gDWVuZG9iag05NyAwIG9iag08PCANL1MgL1N0YW5kYXJk IA0vQyAvU3RhbmRhcmQgDS9QZyAxIDAgUiANL0sgWyA5OCAwIFIgMjAgXSANL1AgMTAxIDAgUiAN Pj4gDWVuZG9iag05OCAwIG9iag08PCANL1MgL0lubGluZVNoYXBlIA0vUGcgMSAwIFIgDS9LIDE5 IA0vUCA5NyAwIFIgDS9BbHQgKCkNL0EgWyAxMTYgMCBSIF0gDT4+IA1lbmRvYmoNOTkgMCBvYmoN PDwgDS9TIC9TdGFuZGFyZCANL0MgL1N0YW5kYXJkIA0vUGcgMTI1IDAgUiANL0sgWyAxMDAgMCBS IDQxIF0gDS9QIDEwMiAwIFIgDT4+IA1lbmRvYmoNMTAwIDAgb2JqDTw8IA0vUyAvU3VwZXJzY3Jp cHQgDS9QIDk5IDAgUiANL0EgMTEyIDAgUiANL1BnIDEyNSAwIFIgDS9LIDQwIA0+PiANZW5kb2Jq DTEwMSAwIG9iag08PCANL1MgL1NlY3QgDS9QIDEyNCAwIFIgDS9LIFsgNyAwIFIgMTEgMCBSIDEy IDAgUiAxNiAwIFIgMTggMCBSIDIwIDAgUiAyMiAwIFIgMjUgMCBSIDI4IDAgUiAzMCAwIFIgDTEw MyAwIFIgMzQgMCBSIDM4IDAgUiA0MCAwIFIgNDIgMCBSIDQ0IDAgUiA0NiAwIFIgNDggMCBSIDUw IDAgUiANNTIgMCBSIDU0IDAgUiA1NiAwIFIgNTcgMCBSIDYxIDAgUiA2MiAwIFIgNjMgMCBSIDY0 IDAgUiA2OCAwIFIgNjkgMCBSIA03MCAwIFIgNzEgMCBSIDcyIDAgUiA3MyAwIFIgMTAyIDAgUiA3 NyAwIFIgNzkgMCBSIDgwIDAgUiA4MSAwIFIgDTgyIDAgUiA4MyAwIFIgODQgMCBSIDg1IDAgUiA4 NiAwIFIgODcgMCBSIDg4IDAgUiA4OSAwIFIgOTAgMCBSIDkxIDAgUiANOTIgMCBSIDkzIDAgUiA5 NCAwIFIgOTUgMCBSIDk2IDAgUiA5NyAwIFIgXSANPj4gDWVuZG9iag0xMDIgMCBvYmoNPDwgDS9T IC9Gb290bm90ZSANL1AgMTAxIDAgUiANL0sgOTkgMCBSIA0+PiANZW5kb2JqDTEwMyAwIG9iag08 PCANL1MgL1NoYXBlIA0vQWx0ICgpDS9QZyAxMjUgMCBSIA0vSyA0MiANL1AgMTAxIDAgUiANL0Eg MTE0IDAgUiANPj4gDWVuZG9iag0xMDQgMCBvYmoNPDwgDS9OdW1zIFsgMCAxMDUgMCBSIDEgMzIg MCBSIDIgMzYgMCBSIDMgNTkgMCBSIDQgNjYgMCBSIDUgNzUgMCBSIDYgMTE1IDAgUiANXSANPj4g DWVuZG9iag0xMDUgMCBvYmoNWyANNyAwIFIgMTEgMCBSIDE1IDAgUiAxMiAwIFIgMTYgMCBSIDE4 IDAgUiAyMCAwIFIgMjIgMCBSIDI0IDAgUiAyMiAwIFIgDTI1IDAgUiAyOCAwIFIgMzMgMCBSIDMw IDAgUiAzNyAwIFIgMzQgMCBSIDM4IDAgUiA0MCAwIFIgNDIgMCBSIDQ0IDAgUiANNDYgMCBSIDQ4 IDAgUiA1MCAwIFIgNTIgMCBSIDU0IDAgUiA1NiAwIFIgNjAgMCBSIDU3IDAgUiA2MSAwIFIgNjIg MCBSIA02MyAwIFIgNjcgMCBSIDY0IDAgUiA2OCAwIFIgNjkgMCBSIDcwIDAgUiA3MSAwIFIgNzIg MCBSIDc2IDAgUiA3MyAwIFIgDTEwMCAwIFIgOTkgMCBSIDEwMyAwIFIgDV0NZW5kb2JqDTEwNiAw IG9iag08PCANL08gL0xheW91dCANL0Jhc2VsaW5lU2hpZnQgNiANPj4gDWVuZG9iag0xMDcgMCBv YmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0RGVjb3JhdGlvblR5cGUgL1VuZGVybGluZSANPj4gDWVu ZG9iag0xMDggMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0RGVjb3JhdGlvblR5cGUgL1VuZGVy bGluZSANPj4gDWVuZG9iag0xMDkgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0RGVjb3JhdGlv blR5cGUgL1VuZGVybGluZSANPj4gDWVuZG9iag0xMTAgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9U ZXh0RGVjb3JhdGlvblR5cGUgL1VuZGVybGluZSANPj4gDWVuZG9iag0xMTEgMCBvYmoNPDwgDS9P IC9MYXlvdXQgDS9UZXh0RGVjb3JhdGlvblR5cGUgL1VuZGVybGluZSANPj4gDWVuZG9iag0xMTIg MCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9CYXNlbGluZVNoaWZ0IDUgDT4+IA1lbmRvYmoNMTEzIDAg b2JqDTw8IA0vTyAvTGF5b3V0IA0vQkJveCBbIDIyNSA2NTcgMzY5IDczOCBdIA0vUGxhY2VtZW50 IC9JbmxpbmUgDT4+IA1lbmRvYmoNMTE0IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vQkJveCBbIDI3 NCA0ODQgMzE1IDUyOCBdIA0vUGxhY2VtZW50IC9CbG9jayANL1N0YXJ0SW5kZW50IDIwMy4xNDk5 OSANL0VuZEluZGVudCAyMDkuMTQ5OTkgDT4+IA1lbmRvYmoNMTE1IDAgb2JqDVsgDTc3IDAgUiA3 OSAwIFIgODAgMCBSIDgxIDAgUiA4MiAwIFIgODMgMCBSIDg0IDAgUiA4NSAwIFIgODYgMCBSIDg3 IDAgUiANODggMCBSIDg5IDAgUiA5MCAwIFIgOTEgMCBSIDkyIDAgUiA5MyAwIFIgOTQgMCBSIDk1 IDAgUiA5NiAwIFIgOTggMCBSIA05NyAwIFIgDV0NZW5kb2JqDTExNiAwIG9iag08PCANL08gL0xh eW91dCANL0JCb3ggWyA3MCA0NzcgMTYzIDQ5NSBdIA0vUGxhY2VtZW50IC9JbmxpbmUgDT4+IA1l bmRvYmoNMTE3IDAgb2JqDTw8IA0vUyAvRCANPj4gDWVuZG9iag0xMTggMCBvYmoNPDwgDS9OdW1z IFsgMCAxMTcgMCBSIF0gDT4+IA1lbmRvYmoNMTE5IDAgb2JqDTw8IA0vUHJvZHVjZXIgKEFjcm9i YXQgRGlzdGlsbGVyIDUuMCBcKFdpbmRvd3NcKSkNL0F1dGhvciAoUk9CRVJUUykNL0NyZWF0b3Ig KEFjcm9iYXQgUERGTWFrZXIgNS4wIGZvciBXb3JkKQ0vTW9kRGF0ZSAoRDoyMDAyMDUyNzExNTM0 OCswMycwMCcpDS9UaXRsZSAoQ2FsbCBmb3IgUGFwZXJzKQ0vQ3JlYXRpb25EYXRlIChEOjIwMDIw NTI3MTE1MzIyKzAyJzAwJykNPj4gDWVuZG9iag0xMjAgMCBvYmoNPDwgL1R5cGUgL01ldGFkYXRh IC9TdWJ0eXBlIC9YTUwgL0xlbmd0aCAxMDM0ID4+IA1zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0n JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJyBieXRlcz0nMTAzMyc/PjxyZGY6UkRGIHht bG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1s bnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+PHJkZjpEZXNjcmlwdGlvbiBhYm91 dD0nJyB4bWxucz0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgeG1sbnM6cGRmPSdodHRw Oi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyBwZGY6Q3JlYXRpb25EYXRlPScyMDAyLTA1LTI3VDA5 OjUzOjIyWicgcGRmOk1vZERhdGU9JzIwMDItMDUtMjdUMDk6NTM6MjJaJyBwZGY6UHJvZHVjZXI9 J0Fjcm9iYXQgRGlzdGlsbGVyIDUuMCAoV2luZG93cyknIHBkZjpBdXRob3I9J1JPQkVSVFMnIHBk ZjpDcmVhdG9yPSdBY3JvYmF0IFBERk1ha2VyIDUuMCBmb3IgV29yZCcgcGRmOlRpdGxlPSdDYWxs IGZvciBQYXBlcnMnLz4KPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0nJyB4bWxucz0naHR0cDovL25z LmFkb2JlLmNvbS94YXAvMS4wLycgeG1sbnM6eGFwPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8x LjAvJyB4YXA6Q3JlYXRlRGF0ZT0nMjAwMi0wNS0yN1QwOTo1MzoyMlonIHhhcDpNb2RpZnlEYXRl PScyMDAyLTA1LTI3VDA5OjUzOjIyWicgeGFwOkF1dGhvcj0nUk9CRVJUUycgeGFwOk1ldGFkYXRh RGF0ZT0nMjAwMi0wNS0yN1QwOTo1MzoyMlonPjx4YXA6VGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4 bWw6bGFuZz0neC1kZWZhdWx0Jz5DYWxsIGZvciBQYXBlcnM8L3JkZjpsaT48L3JkZjpBbHQ+PC94 YXA6VGl0bGU+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1s bnM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyB4bWxuczpkYz0naHR0cDovL3B1 cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIGRjOmNyZWF0b3I9J1JPQkVSVFMnIGRjOnRpdGxlPSdD YWxsIGZvciBQYXBlcnMnLz4KPC9yZGY6UkRGPjw/eHBhY2tldCBlbmQ9J3InPz4KZW5kc3RyZWFt DWVuZG9iag0xMjEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyAxMjUgMCBSIDEgMCBS IF0gDS9Db3VudCAyIA0+PiANZW5kb2JqDXhyZWYNMCAxMjIgDTAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDEzMDE1MiAwMDAwMCBuDQowMDAwMTMwNTI2IDAwMDAwIG4NCjAwMDAxMzEzNjUgMDAwMDAg bg0KMDAwMDEzMTM4NSAwMDAwMCBuDQowMDAwMTMyMTIwIDAwMDAwIG4NCjAwMDAxMzIxNjcgMDAw MDAgbg0KMDAwMDEzMjI2NyAwMDAwMCBuDQowMDAwMTMyMzQzIDAwMDAwIG4NCjAwMDAxMzI2NTEg MDAwMDAgbg0KMDAwMDEzMjczMiAwMDAwMCBuDQowMDAwMTMyODg0IDAwMDAwIG4NCjAwMDAxMzI5 NjEgMDAwMDAgbg0KMDAwMDEzMzA3MCAwMDAwMCBuDQowMDAwMTMzMTI2IDAwMDAwIG4NCjAwMDAx MzMyNzcgMDAwMDAgbg0KMDAwMDEzMzM3MiAwMDAwMCBuDQowMDAwMTMzNDcwIDAwMDAwIG4NCjAw MDAxMzM1MjYgMDAwMDAgbg0KMDAwMDEzMzYyNCAwMDAwMCBuDQowMDAwMTMzNjgwIDAwMDAwIG4N CjAwMDAxMzM3NzggMDAwMDAgbg0KMDAwMDEzMzgzNCAwMDAwMCBuDQowMDAwMTMzOTQ1IDAwMDAw IG4NCjAwMDAxMzQwMDEgMDAwMDAgbg0KMDAwMDEzNDA4NCAwMDAwMCBuDQowMDAwMTM0MTk3IDAw MDAwIG4NCjAwMDAxMzQyNTMgMDAwMDAgbg0KMDAwMDEzNDQwNCAwMDAwMCBuDQowMDAwMTM0NTE3 IDAwMDAwIG4NCjAwMDAxMzQ1NzMgMDAwMDAgbg0KMDAwMDEzNDY5NyAwMDAwMCBuDQowMDAwMTM0 NzUzIDAwMDAwIG4NCjAwMDAxMzQ4NTYgMDAwMDAgbg0KMDAwMDEzNDkzOCAwMDAwMCBuDQowMDAw MTM1MDYyIDAwMDAwIG4NCjAwMDAxMzUxMTggMDAwMDAgbg0KMDAwMDEzNTIyMSAwMDAwMCBuDQow MDAwMTM1MzAzIDAwMDAwIG4NCjAwMDAxMzU0MDIgMDAwMDAgbg0KMDAwMDEzNTQ4MiAwMDAwMCBu DQowMDAwMTM1NTgxIDAwMDAwIG4NCjAwMDAxMzU2MzcgMDAwMDAgbg0KMDAwMDEzNTczNiAwMDAw MCBuDQowMDAwMTM1NzkyIDAwMDAwIG4NCjAwMDAxMzU4OTEgMDAwMDAgbg0KMDAwMDEzNTk0OCAw MDAwMCBuDQowMDAwMTM2MDQ3IDAwMDAwIG4NCjAwMDAxMzYxMDQgMDAwMDAgbg0KMDAwMDEzNjIw MyAwMDAwMCBuDQowMDAwMTM2MjYwIDAwMDAwIG4NCjAwMDAxMzYzNTkgMDAwMDAgbg0KMDAwMDEz NjQxNiAwMDAwMCBuDQowMDAwMTM2NTE1IDAwMDAwIG4NCjAwMDAxMzY1NzIgMDAwMDAgbg0KMDAw MDEzNjY3MSAwMDAwMCBuDQowMDAwMTM2NzI4IDAwMDAwIG4NCjAwMDAxMzY4MTIgMDAwMDAgbg0K MDAwMDEzNjkzNiAwMDAwMCBuDQowMDAwMTM2OTkyIDAwMDAwIG4NCjAwMDAxMzcwOTUgMDAwMDAg bg0KMDAwMDEzNzE3NyAwMDAwMCBuDQowMDAwMTM3MjYxIDAwMDAwIG4NCjAwMDAxMzczNDUgMDAw MDAgbg0KMDAwMDEzNzQyOSAwMDAwMCBuDQowMDAwMTM3NTM5IDAwMDAwIG4NCjAwMDAxMzc2MjAg MDAwMDAgbg0KMDAwMDEzNzcyMyAwMDAwMCBuDQowMDAwMTM3ODA1IDAwMDAwIG4NCjAwMDAxMzc4 ODkgMDAwMDAgbg0KMDAwMDEzNzk3MyAwMDAwMCBuDQowMDAwMTM4MDU3IDAwMDAwIG4NCjAwMDAx MzgxNDEgMDAwMDAgbg0KMDAwMDEzODIyNSAwMDAwMCBuDQowMDAwMTM4MzM1IDAwMDAwIG4NCjAw MDAxMzgzOTEgMDAwMDAgbg0KMDAwMDEzODQ5NCAwMDAwMCBuDQowMDAwMTM4NTc2IDAwMDAwIG4N CjAwMDAxMzg2NzIgMDAwMDAgbg0KMDAwMDEzODcyOCAwMDAwMCBuDQowMDAwMTM4ODA5IDAwMDAw IG4NCjAwMDAxMzg4OTAgMDAwMDAgbg0KMDAwMDEzODk3MSAwMDAwMCBuDQowMDAwMTM5MDUyIDAw MDAwIG4NCjAwMDAxMzkxMzMgMDAwMDAgbg0KMDAwMDEzOTIxNCAwMDAwMCBuDQowMDAwMTM5Mjk1 IDAwMDAwIG4NCjAwMDAxMzkzNzYgMDAwMDAgbg0KMDAwMDEzOTQ1NyAwMDAwMCBuDQowMDAwMTM5 NTM5IDAwMDAwIG4NCjAwMDAxMzk2MjEgMDAwMDAgbg0KMDAwMDEzOTcwMyAwMDAwMCBuDQowMDAw MTM5Nzg1IDAwMDAwIG4NCjAwMDAxMzk4NjcgMDAwMDAgbg0KMDAwMDEzOTk0OSAwMDAwMCBuDQow MDAwMTQwMDMxIDAwMDAwIG4NCjAwMDAxNDAxMTMgMDAwMDAgbg0KMDAwMDE0MDE5NSAwMDAwMCBu DQowMDAwMTQwMjg4IDAwMDAwIG4NCjAwMDAxNDAzODIgMDAwMDAgbg0KMDAwMDE0MDQ3OCAwMDAw MCBuDQowMDAwMTQwNTYzIDAwMDAwIG4NCjAwMDAxNDEwMDIgMDAwMDAgbg0KMDAwMDE0MTA2NCAw MDAwMCBuDQowMDAwMTQxMTUyIDAwMDAwIG4NCjAwMDAxNDEyNTQgMDAwMDAgbg0KMDAwMDE0MTU4 MyAwMDAwMCBuDQowMDAwMTQxNjM4IDAwMDAwIG4NCjAwMDAxNDE3MDcgMDAwMDAgbg0KMDAwMDE0 MTc3NiAwMDAwMCBuDQowMDAwMTQxODQ1IDAwMDAwIG4NCjAwMDAxNDE5MTQgMDAwMDAgbg0KMDAw MDE0MTk4MyAwMDAwMCBuDQowMDAwMTQyMDM4IDAwMDAwIG4NCjAwMDAxNDIxMjIgMDAwMDAgbg0K MDAwMDE0MjI1MSAwMDAwMCBuDQowMDAwMTQyNDIzIDAwMDAwIG4NCjAwMDAxNDI1MDYgMDAwMDAg bg0KMDAwMDE0MjUzOCAwMDAwMCBuDQowMDAwMTQyNTg0IDAwMDAwIG4NCjAwMDAxNDI4MTQgMDAw MDAgbg0KMDAwMDE0MzkzMyAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDEyMg0vSURbPGM3YjEw MDI0MTk5MDkxMWU3YWIxOWIyZjk1YzUxMDIzPjxmNTE1NzkzZWIyMjNkYWE0YWIzODY5YzFmYWE2 N2IyMz5dDT4+DXN0YXJ0eHJlZg0xNzMNJSVFT0YN ------=_NextPart_000_0007_01C20575.6CDE84B0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Thu May 30 00:46:53 2002 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 AAA13893 for ; Thu, 30 May 2002 00:46:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA15356 for nsis-archive@odin.ietf.org; Thu, 30 May 2002 00:47:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14886; Thu, 30 May 2002 00:37:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14849 for ; Thu, 30 May 2002 00:37:09 -0400 (EDT) Received: from [202.109.103.226] ([202.109.103.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13633; Thu, 30 May 2002 00:36:42 -0400 (EDT) From: Age_Reversal_Center@excite.com Message-Id: <200205300436.AAA13633@ietf.org> Received: from no.name.available by [202.109.103.226] via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 30 May 2002 05:30:17 UT Received: from fwshanghai.spray.com.cn ([10.237.2.1]) by sssfsvr1.china.spray.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L8MTQN3Y; Thu, 30 May 2002 12:36:54 +0800 Reply-To: Age_Reversal_Center@excite.com To: nsirt@aol.com CC: nsis-request@ietf.org, nsis@ietf.org, nsiskowic@caprica.com, nsisok@earthlink.net, nsisson@mindspring.com, nsistrunk@hotmail.com Received: from [66.73.143.2] by fwshanghai.spray.com.cn via smtpd (for [10.237.2.5]) with SMTP; 30 May 2002 05:29:54 UT Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Wed, 29 May 2002 21:38:28 -0700 Subject: [NSIS] Medical Breakthrough... aging can be reversed with HGH Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org There are three different types of HGH products

There are three different types of HGH products.
The confusion is that all three are
advertised as if they were the same.
 
        The three types are:
 
1) --- Homeopathic HGH
2) --- Pre-cursor HGH
3) --- Real or synthetic HGH (delivered by injection
        or, by an oral spray method).
 
Do you know differences?
 
Call us and we'll explain them to you.
 
Our toll free number is 1-888-621-7300
An HGH staff member is available
9 to 5 Pacific Time.
If after hours, please leave you name
and day and evening phone numbers.
We will call you back in a no pressure,
educational manner.
If you are overseas call your long distance
operator and ask to be connected to our
phone number.  We will call you back so
we can pay for the long distance charges.
 
For more information on HGH read on............
 
HAVE YOU HEARD OF
HUMAN GROWTH HORMONE (HGH)???
 
     Released by your own pituitary gland, HGH starts declining
in your 20s, even more in your 30s and 40s, eventually resulting
in the shrinkage of major organs -- plus, all
other symptoms related to old age.
 
 
IN THOUSANDS OF CLINICAL STUDIES,
HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING:
 
* Reduce Body Fat and Build Lean Muscle
   WITHOUT EXERCISE!
 
* Enhance Sexual Performance
 
* Remove Wrinkles and Cellulite
 
* Lower Blood Pressure and Improve Cholesterol Profile
 
* Improve Sleep, Vision and Memory
 
* Restore Hair Color and Growth
 
* Strengthen the Immune System
 
* Increase Energy and Cardiac Output
 
* Turn back your body's Biological Time Clock 10 - 20 years
 
* Live Longer AND Stronger
 
All natural and organic plant based
 
FEEL 10 YEARS YOUNGER WITH ORAL SPRAY HGH.
GUARANTEED
 
    We are the manufacturer and we sell directly to Doctors,
Chiropractors, and consumers world wide the highest grade
 HGH Oral Spray available. 
 
     With internet marketing, we are able to save advertising
cost and pass those savings along to you.
But you must act now. 
 
To receive more information call  us now.
 
            TOLL FREE 1-888-621-7300
 
We must speak to you in person to qualify your usage.
 
     All of your questions will be addressed and answered in a friendly,
no pressure manner.  Our main purpose is to provide you with
 information so you can make an educated decision.
 
     For more information call
 
            1-888-621-7300
 
 If you are on line write down our
phone number and call us when you can.
 
Soon, you and your loved ones will be very glad you did.
 
Read what people are saying:
 
"The effects of 6 months of GH on
lean body mass and fat were equivalent
in magnitude to the changes incurred
during 10-20 years of aging."
Dr. Daniel Rudman, MD,
New England Journal of Medicine.
 
"Within four months, my body fat decreased
 form 30% down to 21%! I noticed my skin
 is more supple and my overall mental
 outlook improved significantly."
 D.W., New Jersey
 
"We have been on the spray for just 3 weeks
now, and besides the tremendous energy we
both feel, my husbands allergies and spells
of depression have lifted. I am healing
extremely fast after an accident and have
lost 7 lbs. without trying!"
C.B., Flagstaff. AZ
 
Thanks for reading our letter,
The HGH Staff
USA Division
 
PS:  The HGH Staff guarantees the
highest quality and lowest price.
 
 We manufacture and ship directly to your door.
 
Call us now 1-888-621-7300
 
=======   End of message ======== 
 
   The following statement is provided to be
in compliance with commercial email laws.
 
   If you do not wish to receive further
mailings, please click reply and type remove in the subject box.
Then click send.
 
   This message is in full compliance with
U.S. Federal requirements for commercial
email under bill S.1618 Title lll, Section 301,
Paragraph (a)(2)(C) passed by the 105th U.S.
Congress and is not considered SPAM
since it includes a remove mechanism.*
This message is not intended for residents in the
states of CA, NC, NV, RI, TN, VA & WA.
Screening of addresses has been done to the best
of our technical ability.
 
             Call us now 1-888-621-7300 for your
             free HGH consultation.


Thank you

..... 18964332221111 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri May 31 04:58:13 2002 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 EAA09250 for ; Fri, 31 May 2002 04:58:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16292 for nsis-archive@odin.ietf.org; Fri, 31 May 2002 04:58:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15679; Fri, 31 May 2002 04:46:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15645 for ; Fri, 31 May 2002 04:46:04 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09161 for ; Fri, 31 May 2002 04:45:38 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4V8im901227 for ; Fri, 31 May 2002 11:44:48 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 May 2002 11:46:01 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 11:46:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Interim Meeting Report Date: Fri, 31 May 2002 11:46:00 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652C3@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Interim Meeting Report Thread-Index: AcIIeLc+X6OolJ2wSUevYHuRyoKpTwABsIjA To: Cc: X-OriginalArrivalTime: 31 May 2002 08:46:01.0456 (UTC) FILETIME=[9772FF00:01C2087F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA15651 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, I have updated the webpage with the interim meeting material, it can be found here: http://www-nrc.nokia.com/sua/nsis/interim/ Comments are welcome, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri May 31 06:17:16 2002 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 GAA10356 for ; Fri, 31 May 2002 06:17:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA20392 for nsis-archive@odin.ietf.org; Fri, 31 May 2002 06:17:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19155; Fri, 31 May 2002 05:57:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19124 for ; Fri, 31 May 2002 05:57:41 -0400 (EDT) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10149 for ; Fri, 31 May 2002 05:57:14 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 17DjAB-0004Xb-00; Fri, 31 May 2002 11:57:39 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 17DjAB-0005aH-00; Fri, 31 May 2002 11:57:39 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g4V9vcg05964; Fri, 31 May 2002 11:57:38 +0200 Message-Id: <200205310957.g4V9vcg05964@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: "Georgios Karagiannis (ELN)" cc: nsis@ietf.org Subject: Re: [NSIS] NSIS Requirements: grouping microflows In-Reply-To: Message from "Georgios Karagiannis (ELN)" of "Wed, 29 May 2002 13:44:16 +0200." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 May 2002 11:57:38 +0200 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, > But this requirement can be seen as a more general > definition of the refresh reduction method used in > RSVP! > > Thus, I do not know why you should remove it? As said before, if used in a request for initially establishing the reservations, it is difficult to handle situations when some of the grouped reservations fail. This would be typically best solved by the application itself and a good example to apply the end-to-end design principle. However, there may be other message types in which grouping several reservation-IDs can be useful, but I doubt that we need it as a functional _requirement_. Regards, Roland > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: woensdag 29 mei 2002 12:23 > To: nsis@ietf.org > Subject: [NSIS] NSIS Requirements: grouping microflows > > > Hi, > > I've got a comment to > Open issue > 14) add "support grouping of microflows" > > If I remember correctly, Georgios supported this requirement > due to its usefulness for refreshing states. IMO this is > better solved by a refresh reduction method such as the > proposed one for RSVP. > Therefore: shouldn't we remove this requirement? > Though grouping microflows in a request is really complex > due to handling of failed requests for single flows, > it might be useful to have a list of reservation-IDs > for error messages such as a release due to failure. > But this seems to be an implementation specific optimization > rather than a functional requirement. > > Regards, > Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri May 31 13:28:17 2002 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 NAA23208 for ; Fri, 31 May 2002 13:28:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22319 for nsis-archive@odin.ietf.org; Fri, 31 May 2002 13:28:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21699; Fri, 31 May 2002 13:11:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21666 for ; Fri, 31 May 2002 13:11:15 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22811 for ; Fri, 31 May 2002 13:10:48 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g4VHETN22852; Fri, 31 May 2002 12:14:29 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g4VHALh21505; Fri, 31 May 2002 12:10:21 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 12:11:11 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB0E@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com Cc: nsis@ietf.org Subject: RE: [NSIS] RE: What's in the charter of NSIS Date: Fri, 31 May 2002 12:11:03 -0500 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > To put it another way, I don't think that the IESG will > let us standardize Bandwidth Brokers, nor is that something > that I want to do. However, it is possible that NSIS > could support BBs, if they are present. > > John John, What is your current view on this in light of recent discussions and charter scoping announcements? Marco > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, May 15, 2002 4:58 AM > To: Ruediger.Geib@t-systems.com > Cc: nsis@ietf.org > Subject: [NSIS] RE: What's in the charter of NSIS > > > Hi Rudiger, > > > > Furthermore, maybe someone does not want IntServ exactly, > > > but perhaps a certain characteristic of IntServ, say > > > bandwidth. > > > > What happens to the remainder of IntServ in that case? > > Would one have to signal empty parameters? No answer > > required if this will be discussed in Helsinki! > > My feeling is we should discuss what parts we signaling, > but we de-couple the signaling from the resource reservation. > > > > Then you could have > > > > > > Bandwidth Assurance over IntServ Networks > > > Bandwidth Assurance over MPLS Networks > > > Bandwidth Assurance over Over Provisioned Networks > > > Bandwidth Assurance over a Bandwidth Broker Network > > > > That BB definition issue must be settled. The "friends > > of BB" could provide an architecture outline by now, > > if they are not charged of entering the solution discussion. > > It would be helpful to have such a document (and I see > > by your other message that you aggree). Your above > > example in my words would be: > > > > BW Assurancee over MPLS using a BB > > BW Assurance over Over Provisoned Networks using a BB > > or in general: BW Assurance over a network using a BB > > > > BB's of separated domains may > > signal with each other without bothering which > > layers/technologies are supported by the domain > > in which each operates. This solves the problem > > you've mentioned below (with regard to signaling): > > As far as BB go, I don't think we need to completely > ignore them, however, I don't think we can make NSIS > a BB-centric archiecture. What I mean is that we cannot > mandate a BB architecure (i.e. - everyone who wants to > use an NSIS protocol MUST deploy a bandwidth broker.) > I see it more as something that the signaling can occur > without a BB, but we may be able to put the correct > hooks to allow those who want to deploy BBs to be able to > do so. > > To put it another way, I don't think that the IESG will > let us standardize Bandwidth Brokers, nor is that something > that I want to do. However, it is possible that NSIS > could support BBs, if they are present. > > 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 daemon@ns.ietf.org Fri May 31 13:38:41 2002 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 NAA23633 for ; Fri, 31 May 2002 13:38:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23466 for nsis-archive@odin.ietf.org; Fri, 31 May 2002 13:39:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22189; Fri, 31 May 2002 13:25:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22156 for ; Fri, 31 May 2002 13:25:05 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23145 for ; Fri, 31 May 2002 13:24:38 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g4VHSKN22943; Fri, 31 May 2002 12:28:20 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g4VHOCa22018; Fri, 31 May 2002 12:24:12 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 12:25:01 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB0F@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, bless@tm.uka.de Cc: nsis@ietf.org Subject: RE: [NSIS] To BB or not to BB Date: Fri, 31 May 2002 12:24:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA22157 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Illya, I like how you have phrased the problem here as "the QoS signaling that will make interoperability between domains using different QoS technology easy(possible) and uniform. I would only add that perhaps the most important case of "different domains" is the user to the network. Marco > -----Original Message----- > From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] > Sent: Wednesday, May 15, 2002 9:52 AM > To: 'john.loughney@nokia.com'; Ruediger.Geib@t-systems.com; > bless@tm.uka.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] To BB or not to BB > > > Hi, John. > > As far as I understand when you are talking about centralized > approach you > mean an approach to the resource provisioning. As we agreed resource > provisioning is out of NSIS scope anyway so there is no > reason to get into > this discussion. That is exactly the reason why I like so > much QoS Initiator > - QoS Controller terminology. It helps us not to deal with > distributed and > centralized approaches at all (or deal with them in uniform fashion - > whatever you like more). Then the issue of having one or many > QCs within > domain becomes the issue of local QoS technology/provisioning > rather than > signaling. > > What I am looking for is very similar to Ruediger (I think) - the QoS > signaling that will make interoperability between domains > using different > QoS technology easy (possible) and uniform. I do not what to deal with > Intserve over Diffserve, Intserve over MPLS etc. I would like > to end up with > NSIS between all sorts of domains. > > My 2 cents. > > Ilya > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, May 15, 2002 4:48 AM > To: Ruediger.Geib@t-systems.com; bless@tm.uka.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] To BB or not to BB > > Hi Rüdiger, > > > > I don't know what your perception of a BB is. Mine is that > > there's one per QoS domain, controlled by the operator > > running the domain. There's no difference in per router > > security requirements and BB security requirements if you > > look at the single element. The number of routers involved > > into signaling is higher and each has to as robust against > > an attack as the few centralised BBs have to be. > > There is no 'bandwidth broker' term in the IETF lexicon, a quick > RFC search turned up no references. I think this is part of the > problem. Generally, the IETF has been allergic to centralized > approaches, as this introduces single points of failures, etc. > > Anyhow, I have yet to see a clear, crisp definition of bandwidth > broker, so I very hesitant in accepting it into NSIS. > > > > Discovery mechanisms (how > > > do I discover the BB in my home network, my visited > > > network, do I need to discover your BB if I am calling > > > you .... > > > > As difficult to solve as AAA. > > Not really, I think the current AAA architecture is not > so bad. > > > > Scalability - to what extent does this scale? > > > Can we put a metric on it? Is it per domain, sub-domain, > > > per link ..? > > > > Or per router, maybe even integrated into a router? If you'd > > like to see more literatutre on the scalability of centralised > > admission control, could you provide a couple of references > > examining the scalability IntDiff? > > Noone is promoting Integrated Services over DiffServ networks as > a solution to NSIS, as this work as already been done. Whether > or not anyone uses it, is not an issue for us. I think we need > to work on a more general approach, because we cannot ensure > that all networks deploy DiffServ. > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri May 31 19:27:15 2002 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 TAA06764 for ; Fri, 31 May 2002 19:27:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA12068 for nsis-archive@odin.ietf.org; Fri, 31 May 2002 19:27:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11595; Fri, 31 May 2002 19:13:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11566 for ; Fri, 31 May 2002 19:13:02 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06603 for ; Fri, 31 May 2002 19:12:36 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 19:07:10 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9318F@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'nsis@ietf.org'" Date: Fri, 31 May 2002 19:07:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1251" Subject: [NSIS] Cases that can benefit from the out of band NSIS signaling Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi all. I want to be clear: I am not advocating out of band NSIS signaling (that requires some sort of discovery of your signaling peers) as the only option. I just argue the value to the support NSIS out of band signaling option as well. Cases that can benefit from the out of band NSIS signaling. 1. Application layer NSIS signaling proxy. The typical logical places for these kinds of proxies are: - SIP proxy/H323 Gatekeeper/Media Gateway Controller (MEGACO) in IP telephony. - Gaming Server - Video On Demand management server - Video Conferencing management server The common functionality shared by these entities: - Application layer user authentication - Application layer session admission and resource management such as media processing resources, bandwidth allocated to the application, video-streaming resources etc. - Application layer accounting The benefits of enabling these application proxies to function as NSIS (QoS) initiator in behalf of the end hosts are: - Deployment does not require NSIS support form the end hosts - installed based of the devices can be used immediately. - Easier prevention of the resource theft. - Usually this entities less constrained with the computation resources than hosts Potential complication for the application proxies - they may have to be aware of the network topology to know "where" to signal. 2. Centralized resource management systems (aka BB) The benefits to enable BBs with NSIS signaling: - It enables direct communication between BBs of the neighboring domains/sub-domains - It removes need for topology awareness from the NSIS signaling proxies (since the centralize entity most likely is topology aware). Ilya _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis