From daemon@optimus.ietf.org Mon Jun 3 14:48: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 OAA27290 for ; Mon, 3 Jun 2002 14:48:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23318 for nsis-archive@odin.ietf.org; Mon, 3 Jun 2002 14:48: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 OAA22872; Mon, 3 Jun 2002 14:34: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 OAA22840 for ; Mon, 3 Jun 2002 14:34:33 -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 OAA26791 for ; Mon, 3 Jun 2002 14:34:04 -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 g53IboN04192; Mon, 3 Jun 2002 13:37:50 -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 g53IXeN12696; Mon, 3 Jun 2002 13:33:40 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 13:34:31 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB12@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Georgios Karagiannis (ELN)'" , "'nsis@ietf.org'" Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow reserv ations and default routing Date: Mon, 3 Jun 2002 13:34:30 -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 Georgios, In my mind this requirement has do with the layering relationship between QOS Signaling and Routing. In a hard-state solution once the QOS path is created it does not unchange. The signaling protocol uses input from the routing protocol to create this path. The path created is static. In an RSVP style solution without route pinning we have a reactive distributed algorithm that takes the default routing path as its input. While it should be possible to do this style of path that is dynamically determined by the default destination based routing, it must also be possible to build the path once based upon an initial set of inputs. Marco > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Wednesday, May 29, 2002 7:52 AM > To: Schneider, Marco; 'nsis@ietf.org' > Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow > reserv ations and default routing > > > 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@ns.ietf.org Tue Jun 4 00:47: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 AAA10126 for ; Tue, 4 Jun 2002 00:47:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA24286 for nsis-archive@odin.ietf.org; Tue, 4 Jun 2002 00:47: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 AAA22815; Tue, 4 Jun 2002 00:27: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 AAA22787 for ; Tue, 4 Jun 2002 00:27:10 -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 AAA09812 for ; Tue, 4 Jun 2002 00:26:40 -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 g544Pq912696 for ; Tue, 4 Jun 2002 07:25:52 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Jun 2002 07:27:07 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 4 Jun 2002 07:27:06 +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, 4 Jun 2002 07:27:06 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652EF@esebe004.NOE.Nokia.com> Thread-Topic: conference call next week? Thread-Index: AcILgBmRGDANfTBcSeKhKKhaIeSCoQ== To: X-OriginalArrivalTime: 04 Jun 2002 04:27:06.0992 (UTC) FILETIME=[15D6E700:01C20B80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA22788 Subject: [NSIS] conference call next week? 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 can reserve a conference call for next week, I will put up as a possible time: Tuesday June 11, 2002: 2 PM European Time / 8 AM Eastern Time Please let me know if you plan to attend, and if this time is a problem. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue Jun 4 03:02: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 DAA20169 for ; Tue, 4 Jun 2002 03:02:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA08323 for nsis-archive@odin.ietf.org; Tue, 4 Jun 2002 03:02: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 CAA07377; Tue, 4 Jun 2002 02:46: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 CAA07348 for ; Tue, 4 Jun 2002 02:46: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 CAA19895 for ; Tue, 4 Jun 2002 02:45: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 g546kdq22884 for ; Tue, 4 Jun 2002 09:46: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 for ; Tue, 4 Jun 2002 09:46:12 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 4 Jun 2002 09:46: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="iso-8859-1" Date: Tue, 4 Jun 2002 09:46:12 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652F3@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] conference call next week? Thread-Index: AcILj+15mH5e3fQWTsekoZ3oDlPdGQAA1i5g To: X-OriginalArrivalTime: 04 Jun 2002 06:46:12.0823 (UTC) FILETIME=[8457A670:01C20B93] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA07349 Subject: [NSIS] No Conference Call next week 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, Someone reminded me about IETF rules on conference calls, see the bottom of the mail. So, this is not feasible at the moment, so the conference call is off. thanks, John excerpt from: http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt - WG Interim meetings and Conference Calls need approval of relevant ADs - They must be announced at least 30 days in advance - The proposed agenda must be published at least 15 days before meeting - They cannot be held within 30 days prior to an IETF meeting - They must be scheduled (location/timing) with fair access for all WG participants - They do not substitute for the mailing list, and any decisions are not final and must be approved on the WG mailing list - Detailed minutes (including list of attendees) must be sent to minutes@ietf.org within 10 days of the meeting _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jun 5 23:38: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 XAA12193 for ; Wed, 5 Jun 2002 23:38:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA21148 for nsis-archive@odin.ietf.org; Wed, 5 Jun 2002 23:39: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 XAA20411; Wed, 5 Jun 2002 23:22: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 XAA20380 for ; Wed, 5 Jun 2002 23:22:09 -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 XAA11281 for ; Wed, 5 Jun 2002 23:21:37 -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 g563MW627773 for ; Thu, 6 Jun 2002 06:22:32 +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 ; Thu, 6 Jun 2002 06:22:07 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 6 Jun 2002 06:22:06 +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: Thu, 6 Jun 2002 06:22:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65336@esebe004.NOE.Nokia.com> Thread-Topic: IETF 54 info Thread-Index: AcINCVlnCNR4hmPmQYiuno4Yb7I1ng== To: X-OriginalArrivalTime: 06 Jun 2002 03:22:06.0681 (UTC) FILETIME=[55E62C90:01C20D09] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA20381 Subject: [NSIS] IETF 54 info 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, Tentatively, we are scheduled for Monday: MONDAY, July 15, 2002 0800-1930 IETF Registration - 0800-0900 Continental Breakfast 0900-1130 Morning Sessions APP apparea Applications Open Area Meeting INT ipoib IP over InfiniBand WG OPS bmwg Benchmarking Methodology WG TSV nsis Next Steps in Signaling WG TSV pwe3 Pseudo Wire Emulation Edge to Edge WG and draft cut off dates are: June 24th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 24th, at 09:00 US-EDT (eastern daylight time). July 1st: FINAL Internet-Draft Cutoff Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Thu Jun 6 08:01: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 IAA08826 for ; Thu, 6 Jun 2002 08:01:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28154 for nsis-archive@odin.ietf.org; Thu, 6 Jun 2002 08:02: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 HAA26546; Thu, 6 Jun 2002 07:45: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 HAA26515 for ; Thu, 6 Jun 2002 07:45:53 -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 HAA08080 for ; Thu, 6 Jun 2002 07:45:22 -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 g56Bk9605881 for ; Thu, 6 Jun 2002 14:46:13 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Jun 2002 14:45:43 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 6 Jun 2002 14:45:43 +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: Thu, 6 Jun 2002 14:45:43 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65354@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: What's in the charter of NSIS Thread-Index: AcIIxi8zhdXoFht1Qh6d0/iQGpyr+gEiXCLA To: , Cc: X-OriginalArrivalTime: 06 Jun 2002 11:45:43.0872 (UTC) FILETIME=[B0BF9C00:01C20D4F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA26516 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, > > 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? It hasn't changed. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 7 11:40: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 LAA01416 for ; Fri, 7 Jun 2002 11:40:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05533 for nsis-archive@odin.ietf.org; Fri, 7 Jun 2002 11:41: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 LAA04518; Fri, 7 Jun 2002 11:23:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04487 for ; Fri, 7 Jun 2002 11:23: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 LAA00703 for ; Fri, 7 Jun 2002 11:22:39 -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 g57FMa879279; Fri, 7 Jun 2002 17:22:36 +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 RAA10773; Fri, 7 Jun 2002 17:18:38 +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 556A43F801; Fri, 7 Jun 2002 17:18:37 +0200 (CEST) Date: Fri, 07 Jun 2002 17:18:39 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Schneider, Marco" , "'nsis@ietf.org'" Cc: "'sven.van_den_bosch@alcatel.be'" Subject: Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing Message-ID: <21044049.1023470319@[192.168.102.79]> In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D638BAF5@TRIMAIL2.ad.tri.sbc.com> References: <905A1C4ABF353F4C8CC16FA9F53DD0D638BAF5@TRIMAIL2.ad.tri.sbc.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 Marco, IMHO the problem you have shown in the example can be solved in 2 ways, and both are IMO out of scope for NSIS. 1) take care by introducing new links into your topology, something you might want to do on lightly loaded metworks anyway. 2) I think an other solution would be constraint/QoS routing, which is more going into the mechanis of provisioning, which is again out of scope. Marcus --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" wrote: > 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 -------------------------------------- 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 Jun 7 11:53: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 LAA01733 for ; Fri, 7 Jun 2002 11:53:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06153 for nsis-archive@odin.ietf.org; Fri, 7 Jun 2002 11:53: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 LAA05499; Fri, 7 Jun 2002 11:39: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 LAA05461 for ; Fri, 7 Jun 2002 11:39:15 -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 LAA01381 for ; Fri, 7 Jun 2002 11:38: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 g57Fcb879792; Fri, 7 Jun 2002 17:38:37 +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 RAA10904; Fri, 7 Jun 2002 17:34: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 EC2053668C; Fri, 7 Jun 2002 17:34:39 +0200 (CEST) Date: Fri, 07 Jun 2002 17:34:41 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Schneider, Marco" , "'nsis@ietf.org'" Subject: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing Message-ID: <22006313.1023471281@[192.168.102.79]> In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D638BAF5@TRIMAIL2.ad.tri.sbc.com> References: <905A1C4ABF353F4C8CC16FA9F53DD0D638BAF5@TRIMAIL2.ad.tri.sbc.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 Marco, We discussed the issue of route pinning and traffic engineering in Helsinki. The conclusion during the meeting was that we want to add an assuption saying: NSIS assumes normal/standard L3 routing Plus we add a requirement saying that NSIS protocol should not be broken by networks which do non-traditional L3 routing. Does this cover your concern? Do we really need to add that NSIS must work with default routing changes? Marcus NSIS should not be broken by networks which do non-traditional L3 routing. --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" wrote: > 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 -------------------------------------- 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 Jun 7 12:07: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 MAA02268 for ; Fri, 7 Jun 2002 12:07:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08800 for nsis-archive@odin.ietf.org; Fri, 7 Jun 2002 12: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 LAA06274; Fri, 7 Jun 2002 11: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 LAA06207 for ; Fri, 7 Jun 2002 11:54:34 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01775; Fri, 7 Jun 2002 11:54:02 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g57FriuF005929; Fri, 7 Jun 2002 08:53:44 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEC04593; Fri, 7 Jun 2002 08:51:06 -0700 (PDT) Message-Id: <5.1.0.14.0.20020607115325.0131f9c0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Jun 2002 11:58:44 -0400 To: midcom@ietf.org, nsis@ietf.org, midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [NSIS] RSVP for middlebox communication mailing list 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've established a mailing list, called "tist", for discussion of the use of RSVP (or an RSVP-like protocol) for middlebox communication. There's an initial protocol proposal at http://search.ietf.org/internet-drafts/draft-shore-tist-prot-00.txt and I'm in the process of putting together a proposed agenda for a BOF at the upcoming meeting. To subscribe, send email to mailer@cisco.com with "subscribe tist" in the body of the message. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 7 14:38: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 OAA08130 for ; Fri, 7 Jun 2002 14:38:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21847 for nsis-archive@odin.ietf.org; Fri, 7 Jun 2002 14:38: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 OAA20904; Fri, 7 Jun 2002 14: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 OAA20839 for ; Fri, 7 Jun 2002 14:24:59 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07564; Fri, 7 Jun 2002 14:24:27 -0400 (EDT) Received: from jku2.fokus.gmd.de (dhcp226.fokus.gmd.de [195.37.78.226]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g57INrC31156; Fri, 7 Jun 2002 20:23:53 +0200 Message-Id: <5.1.0.14.0.20020607200432.03738008@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Jun 2002 20:16:59 +0200 To: Melinda Shore , midcom@ietf.org, nsis@ietf.org, midcom@ietf.org From: Jiri Kuthan In-Reply-To: <5.1.0.14.0.20020607115325.0131f9c0@localhost> Mime-Version: 1.0 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 OAA20840 Subject: [NSIS] Re: [midcom] RSVP for middlebox communication mailing list 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 think it would be fair to refer to publications which came out with the same idea earlier. -Jiri Utz Roedig, Manuel Görtz, Martin Karsten, and Ralf Steinmetz. RSVP as Firewall Signalling Protocol. In Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunisia, pages 57-62. IEEE, July 2001. http://www.kom.e-technik.tu-darmstadt.de/publications/abstracts/RGKS01-1.html At 05:58 PM 6/7/2002, Melinda Shore wrote: >I've established a mailing list, called "tist", for discussion of >the use of RSVP (or an RSVP-like protocol) for middlebox communication. >There's an initial protocol proposal at >http://search.ietf.org/internet-drafts/draft-shore-tist-prot-00.txt >and I'm in the process of putting together a proposed agenda for >a BOF at the upcoming meeting. > >To subscribe, send email to mailer@cisco.com with "subscribe tist" >in the body of the message. > >Melinda > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 7 15:18: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 PAA09530 for ; Fri, 7 Jun 2002 15:18:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29903 for nsis-archive@odin.ietf.org; Fri, 7 Jun 2002 15:18: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 OAA22795; Fri, 7 Jun 2002 14:58: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 OAA22731 for ; Fri, 7 Jun 2002 14:58:14 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08636; Fri, 7 Jun 2002 14:57:41 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GXC00F01NBGU9@firewall.wcom.com>; Fri, 7 Jun 2002 18:57:16 +0000 (GMT) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GXC00DKTNBGV8@firewall.wcom.com>; Fri, 07 Jun 2002 18:57:16 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GXC00H01NBCNE@pmismtp06.wcomnet.com>; Fri, 07 Jun 2002 18:57:15 +0000 (GMT) Received: from rccc6131 ([166.35.225.32]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXC00FLPNBDMC@pmismtp06.wcomnet.com>; Fri, 07 Jun 2002 18:57:13 +0000 (GMT) Date: Fri, 07 Jun 2002 13:57:11 -0500 From: "Christopher A. Martin" In-reply-to: <5.1.0.14.0.20020607200432.03738008@mailhost.fokus.gmd.de> To: "'Jiri Kuthan'" , "'Melinda Shore'" , midcom@ietf.org, nsis@ietf.org, midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <000e01c20e55$221362a0$20e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id OAA22734 Subject: [NSIS] RE: [midcom] RSVP for middlebox communication mailing list 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 agree, and Melinda reminded me of TIST earlier today, I just think that the comparison was very well done and had was very easy reading, these should of course be included as well. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Jiri Kuthan Sent: Friday, June 07, 2002 1:17 PM To: Melinda Shore; midcom@ietf.org; nsis@ietf.org; midcom@ietf.org Subject: Re: [midcom] RSVP for middlebox communication mailing list I think it would be fair to refer to publications which came out with the same idea earlier. -Jiri Utz Roedig, Manuel Görtz, Martin Karsten, and Ralf Steinmetz. RSVP as Firewall Signalling Protocol. In Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunisia, pages 57-62. IEEE, July 2001. http://www.kom.e-technik.tu-darmstadt.de/publications/abstracts/RGKS01-1.htm l At 05:58 PM 6/7/2002, Melinda Shore wrote: >I've established a mailing list, called "tist", for discussion of >the use of RSVP (or an RSVP-like protocol) for middlebox communication. >There's an initial protocol proposal at >http://search.ietf.org/internet-drafts/draft-shore-tist-prot-00.txt >and I'm in the process of putting together a proposed agenda for >a BOF at the upcoming meeting. > >To subscribe, send email to mailer@cisco.com with "subscribe tist" >in the body of the message. > >Melinda > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Sun Jun 9 00:57: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 AAA17130 for ; Sun, 9 Jun 2002 00:57:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA28718 for nsis-archive@odin.ietf.org; Sun, 9 Jun 2002 00:57: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 AAA28258; Sun, 9 Jun 2002 00:39: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 AAA28229 for ; Sun, 9 Jun 2002 00:39:05 -0400 (EDT) Received: from mpivinc01 (mail.mpivinc.com [63.169.154.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16940 for ; Sun, 9 Jun 2002 00:38:06 -0400 (EDT) From: stopsmoking@nic-o-quit.com Received: from mail.mpivinc.com (unverified [63.169.154.227]) by mpivinc01 (Rockliffe SMTPRA 4.2.2) with ESMTP id for ; Sun, 9 Jun 2002 00:40:46 -0400 Message-ID: Content-type: text/html Date: Sat, 08 Jun 2002 15:36:54 -0500 To: nsis@ietf.org Subject: [NSIS] ADV: Stop Smoking in 7 Days Guaranteed 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

STOP SMOKING NOW

TRIED THE PATCH!!  DIDN'T WORK
TRIED THE GUM!!  DIDN'T WORK

IF YOU WANT TO STOP SMOKING USE

GUARANTEED TO STOP YOU FROM SMOKING

IN 7 DAYS

HAS A 100%MONEY BACK GUARANTEE
IF YOU DON'T STOP SMOKING.

WHAT'S THE RISK?

Want More Information Visit www.nic-o-quit.com

 

 

 

 

 

 

======================================================================
Welcome to MPIV!

IF YOU WANT TO BE REMOVED FROM FUTURE MAILINGS,
PLEASE CLICK ON THE LINK BELOW RO REMOVE YOURSELF FROM THE MAILING LIST.

HTTP://www.mpivinc.com/removeme.cfm
======================================================================

_______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Sun Jun 9 01:04: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 BAA17243 for ; Sun, 9 Jun 2002 01:04:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA29533 for nsis-archive@odin.ietf.org; Sun, 9 Jun 2002 01:03: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 AAA28376; Sun, 9 Jun 2002 00:47: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 MAA09370 for ; Fri, 7 Jun 2002 12:19:00 -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 MAA02665; Fri, 7 Jun 2002 12:18:27 -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 g57GDd201276; Fri, 7 Jun 2002 18:13:39 +0200 Message-ID: <000f01c20e3f$74161d10$8b6abb84@PROMETHEUS> From: "Kurt Tutschku" To: Date: Fri, 7 Jun 2002 18:21:08 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C20E50.17FA7E20" 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] ITC Specialist Seminar 2002: programm announcement 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_01C20E50.17FA7E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear colleagues, we're happy to announce that the final conference schedule and program = found their way on our homepage. Please find this information on=20 http://www.itcspecialistseminar.com. In addition we want to provide you with the following information: a) Seminar registration: A registration form for the workshop is available at:=20 http://www.itcspecialistseminar.com/RegistrationForm.pdf The deadline for early registration is June 22, 2002. b) Hotel reservation: The seminar's web pages provide a reservation form for=20 accommodations in Wuerzburg. The form is available at:=20 http://www.itcspecialistseminar.com/HotelReservation.pdf The deadline for advance hotel reservation is June 16, 2002. Please remember that July is touristic high season in Germany.=20 We strongly advise you to book your hotel as soon as possible.=20 We are looking forward to welcome you in Wuerzburg. Best Regards,=20 Phuoc Tran-Gia,=20 James Roberts,=20 Kurt Tutschku,=20 Michael Menth, Klaus Heck , your ITC Specialist Seminar Organizing Team ------=_NextPart_000_0007_01C20E50.17FA7E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear colleagues,
we're happy to announce that the=20 final conference schedule and program found their way on our = homepage.=20 Please find this information on
 
In addition we want to provide you with = the=20 following information:
 
a) Seminar registration:

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

http://www.itcspecialistseminar.com/RegistrationForm.pdf<= /A>

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

b) Hotel reservation:

The seminar's web pages = provide a=20 reservation form for
accommodations in Wuerzburg. The form is = available at:=20

http://www.itcspecialistseminar.com/HotelReservation.pdf<= /A>

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

Please remember that July is touristic high season in = Germany.=20
We strongly advise you to book your hotel as soon as possible. =

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

Best Regards, =
Phuoc=20 Tran-Gia,
James Roberts,
Kurt Tutschku,
Michael = Menth,
Klaus Heck=20 , your ITC Specialist Seminar Organizing Team
 
------=_NextPart_000_0007_01C20E50.17FA7E20-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Jun 9 13:55: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 NAA05862 for ; Sun, 9 Jun 2002 13:55:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02113 for nsis-archive@odin.ietf.org; Sun, 9 Jun 2002 13:56: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 NAA01619; Sun, 9 Jun 2002 13:39: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 NAA01562 for ; Sun, 9 Jun 2002 13:39:08 -0400 (EDT) Received: from 2mails447.com (node-c-09a8.a2000.nl [62.194.9.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05667 for ; Sun, 9 Jun 2002 13:38:30 -0400 (EDT) Message-Id: <200206091738.NAA05667@ietf.org> From: "JOSEPH EDWARD" Reply-To: jos_edw46@mail.com To: nsis@ietf.org Date: Sun, 9 Jun 2002 19:31:08 +0200 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA01564 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 STRICTLY CONFIDENTIAL & URGENT. I am Mr, Joseph Edward a native of Cape Town in South Africa and I am an Executive Accountant with the South Africa MINISTRY OF MINERAL RESOURCES AND ENERGY First and foremost, I apologized using this medium to reach you for a transaction/business of this magnitude, but this is due to Confidentiality and prompt access reposed on this medium. I have decided to seek a confidential co-operation with you in the execution of the deal described Hereunder for the benefit of all parties and hope you will keep it as a top secret because of the nature of this transaction. Within the Department of Mining & Natural Resources where I work as an Executive Accountant and with the cooperation of four other top officials, we have in our possession as overdue payment bills totaling Twenty! - One Million, Five Hundred Thousand U. S. Dollars ($21,500,000.) which we want to transfer abroad with the assistance and cooperation of a foreign company/individual to receive the said fund on our behalf or a reliable foreign non-company account to receive such funds. More so, we are handicapped in the circumstances, as the South Africa Civil Service Code of Conduct does not allow us to operate offshore account hence your importance in the whole transaction. This amount $21.5m represents the balance of the total contract value executed on behalf of my Department by a foreign contracting firm, which we the officials over-invoiced deliberately. Though the actual contract cost have been paid to the original contractor, leaving the balance in the Tune of the said amount which we have in principles gotten approval to remit by Key tested Telegraphic Transfer (K.T.T) to any foreign bank account you will provide by fi! ling in an application through the Justice Ministry here in South Africa for the transfer of rights and privileges of the former contractor to you. I have the authority of my partners involved to propose that should you be willing to assist us in the transaction, your share of the sum will be 25% of the $21.5 million, 70% for us and 5% for taxation and miscellaneous expenses. The business itself is 100% safe, on your part provided you treat it with utmost secrecy and confidentiality. Also your area of specialization is not a hindrance to the successful execution of this transaction. I have reposed my confidence in you and hope that you will not disappoint me. Endeavor to contact me immediately my e-mail address whether or not you are interested in this deal. If you are not, it will enable me scout for another foreign partner to carry out this deal I want to assure you that my partners and myself are in a positio! n to make the payment of this claim possible provided you can give us a very strong Assurance and guarantee that our share will be secured and please remember to treat this matter as very confidential matter, because we will not comprehend with any form of exposure as we are still in active Government Service and remember once again that time is of the essence in this business.kindly furnish us with your all your contacts,telephone and fax number for more details. I wait in anticipation of your fullest co-operation. Yours faithfully, JOSEPH EDWARD _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jun 10 09:44: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 JAA04081 for ; Mon, 10 Jun 2002 09:44:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03753 for nsis-archive@odin.ietf.org; Mon, 10 Jun 2002 09:45: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 JAA02463; Mon, 10 Jun 2002 09:29: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 JAA02437 for ; Mon, 10 Jun 2002 09:29: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 JAA03222 for ; Mon, 10 Jun 2002 09:28:35 -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 g5ADTZ613997 for ; Mon, 10 Jun 2002 16:29:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Jun 2002 16:29:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 16:29: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: req proposal (was Re: [NSIS] NSIS Requirement: Independence ofexisting flow reservations and default routing Date: Mon, 10 Jun 2002 16:29:07 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653BF@esebe004.NOE.Nokia.com> Thread-Topic: req proposal (was Re: [NSIS] NSIS Requirement: Independence ofexisting flow reservations and default routing Thread-Index: AcIOOYtih7wZI9yHQxqD8PoKwLLagQCSS5Bw To: , , X-OriginalArrivalTime: 10 Jun 2002 13:29:08.0319 (UTC) FILETIME=[CC8A16F0:01C21082] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA02438 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 & Marcus, > We discussed the issue of route pinning and traffic engineering in > Helsinki. The conclusion during the meeting was that we want to add an > assuption saying: NSIS assumes normal/standard L3 routing > > Plus we add a requirement saying that NSIS protocol should not be broken by > networks which do non-traditional L3 routing. > > Does this cover your concern? Do we really need to add that NSIS must work > with default routing changes? I agree with Marcus that this is what we are trying to say. Marco, is this text OK with you? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Jun 10 20:37: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 UAA00095 for ; Mon, 10 Jun 2002 20:37:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA10665 for nsis-archive@odin.ietf.org; Mon, 10 Jun 2002 20:38: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 UAA09484; Mon, 10 Jun 2002 20:24: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 UAA09427 for ; Mon, 10 Jun 2002 20:24:08 -0400 (EDT) From: owner-nsis@ns.ietf.org Received: from farley.colorado.edu (nobody@farley.Colorado.EDU [128.138.129.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29767; Mon, 10 Jun 2002 20:23:33 -0400 (EDT) Received: (from nobody@localhost) by farley.colorado.edu (8.11.2/8.11.2/ITS-5.0/webmail) id g5B0O7T15983; Mon, 10 Jun 2002 18:24:07 -0600 (MDT) To: nsis@ietf.org, seamoby@ietf.org, mobile-ip@sunroof.eng.sun.com Message-ID: <1023755047.3d05432724479@webmail.colorado.edu> Date: Mon, 10 Jun 2002 18:24:07 -0600 (MDT) 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.4 Content-Transfer-Encoding: 8bit Subject: [NSIS] master's thesis on RSVP/IntServ in mobile networks 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 Fragments of my master's thesis titled "Protocol Enhancements Required to Provide IP-based QoS in Mobile Networks" are posted on http://www3.sympatico.ca/ra.piechocinski/RSVP.htm I appreciate any comments and feedback on IntServ/RSVP additions described in that document. Please sent your comments to maciej.piechocinski@colorado.edu. Two aspects of QoS are considered: -RSVP signaling of traffic characterization parameters required by wireless environment -dynamic adaptation of IntServ/RSVP to changing resource availability in the network Regards, Maciej Piechocinski _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 14 06:47: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 GAA24264 for ; Fri, 14 Jun 2002 06:47:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA03304 for nsis-archive@odin.ietf.org; Fri, 14 Jun 2002 06:48: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 GAA02153; Fri, 14 Jun 2002 06:28: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 GAA02122 for ; Fri, 14 Jun 2002 06:28:17 -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 GAA23919 for ; Fri, 14 Jun 2002 06:27: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 g5EARfi14745 for ; Fri, 14 Jun 2002 13:27:41 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Jun 2002 13:27:13 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 14 Jun 2002 13:27:13 +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, 14 Jun 2002 13:27:13 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6545B@esebe004.NOE.Nokia.com> Thread-Topic: NSIS Analysis Document Thread-Index: AcITjgw322iB4ZuhQraUm782mshdOA== To: X-OriginalArrivalTime: 14 Jun 2002 10:27:13.0639 (UTC) FILETIME=[0C891770:01C2138E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA02123 Subject: [NSIS] NSIS Analysis Document 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, There has been some confusion on what the analysis document should be. I think that some folks think a comparison document would be applicable. For reference, Michael Thomas did a very good analysis of RSVP and IP mobility: http://www.watersprings.org/pub/id/draft-thomas-seamoby-rsvp-analysis-00.txt This is quite different than an evaluation, for example see: Criteria for Evaluating AAA Protocols for Network Access http://www.ietf.org/rfc/rfc2989.txt and Authentication, Authorization, and Accounting: Protocol Evaluation http://www.ietf.org/rfc/rfc3127.txt In summary, the goal of the analysis work is to learn from past failure (& successes) before doing any protocol work. It is not meant to help select a solution. I am hopeful that many of the folks who when through RSVP standardization, etc. would share with us some wisdom they learned so that we can improve upon the work already done and not make the same mistakes. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Jun 16 07:45: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 HAA01306 for ; Sun, 16 Jun 2002 07:45:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA09075 for nsis-archive@odin.ietf.org; Sun, 16 Jun 2002 07:46: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 HAA08332; Sun, 16 Jun 2002 07:21: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 HAA08303 for ; Sun, 16 Jun 2002 07:21:29 -0400 (EDT) Received: from zpz88-49a2c270r.xmgwbn.com ([211.162.36.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01192 for ; Sun, 16 Jun 2002 07:20:49 -0400 (EDT) Date: Sun, 16 Jun 2002 07:20:49 -0400 (EDT) Message-Id: <200206161120.HAA01192@ietf.org> X-Server: Advanced Direct Remailer From: 88biz<88biz@163.com> To: nsis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [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 ×ð¾´µÄÐÂÀÏ¿Í»§£ºÄúºÃ! ÏÃÃÅÊÐӯͨԶº½µç×ӿƼ¼ÓÐÏÞ¹«Ë¾http://www.88biz.comÌṩÓòÃû×¢²á£¬ Ö÷»ú×âÓã¬Ö÷»úÍйܵȷþÎñ¡£½üÆÚÄÚ¹«Ë¾²úÆ·´ó´ÙÏúÀñ°üÒ»(200M HTML¿Õ¼ä + 1¸ö¹ú¼ÊÓòÃûÒ»ÄêÖ»Ðè150Ôª)¡£²É¹º¶à¶àÓŻݶà¶à¡£»¶Ó­´ó¼Ò¶©¹º»òÀ´µç 0592-8857840, ¸ºÔðÈË: СÔø QQ£º38614851 ×Éѯ¡£ ÒÔÉÏÖ»ÊÇÁãÊÛ¼Û¸ñ¡£»¶Ó­Ñ¡¹º£¬Ò²»¶Ó­Äú³ÉΪÎÒÃǵĴúÀíÉÌ! ÎÒÃÇ»¹Óиü¶àµÄÀñ°üºÍÓŻݼ۸ñ£¬ÏêÇéÇë½ø http://www.88biz.com webmaster@88biz.com ÏÃÃÅÊÐӯͨԶº½µç×ӿƼ¼ÓÐÏÞ¹«Ë¾ --------------------------------------------------------------- ·ÐµãȺ·¢Óʼþ,À´×ÔÈí¼þ¹¤³Ìר¼ÒÍø(http://www.21cmm.com) ½øCMMÍøУ(http://www.21cmm.com)£¬³ÉÏîÄ¿¹ÜÀíר¼Ò _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jun 18 13:15: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 NAA26993 for ; Tue, 18 Jun 2002 13:15:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00592 for nsis-archive@odin.ietf.org; Tue, 18 Jun 2002 13:16: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 MAA29403; Tue, 18 Jun 2002 12:58: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 MAA29374 for ; Tue, 18 Jun 2002 12:58:57 -0400 (EDT) Received: from legend-mfy8zk0p ([61.144.241.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26505 for ; Tue, 18 Jun 2002 12:58:14 -0400 (EDT) From: xyz1000@163.net Message-Id: <200206181658.MAA26505@ietf.org> To: nsis@ietf.org Date: Wed, 19 Jun 2002 01:01:39 +0800 X-Priority: 3 X-Mailer: CSM 3.2 Subject: [NSIS] =?GB2312?B?sai+r8b3LS24+MTj0ru49rCyyKu1xLzSo6GjoQ==?= 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 -------------------------------------------------------------------------------- ¾«ÃÀÌ××°(Ö÷»ú1¸ö¡¢ÎÞÏߺìÍâ¡¢ÎÞÏßÃÅ´Å1¸ö¡¢Ò£¿ØÆ÷2¸ö) È«¹úÓʼÄÅú·¢¼Û380Ôª/Ì× ÓÀ»ªÎÞÏßÖÇÄÜ°²·À±¨¾¯ÏµÍ³°üÀ¨±¨¾¯ÖÐÐĺÍÖն˵¥ÔªÉ豸£¬¿ÉÓë¸÷Àà̽ͷ¼æÈÝ£¬¼¯³É¶È¸ß£¬¹¦ÄÜÇ¿´ó£¬Æ·ÖÊ¿É¿¿£¬ °²×°·½±ã£¬²Ù×÷¼òµ¥£¬ÐԼ۱ȸߡ£ÎÞÏßÖÇÄܱ¨¾¯ÏµÍ³ÄÜΪÓû§Ìṩ¹¦ÄÜÈ«ÃæµÄÇ¿´óµÄ°²·À±¨¾¯·þÎñ£¬±¨¾¯Ö÷Òª°üÀ¨ ÒÔÏÂËÄ´ó¹¦ÄÜ£º1) ·ÀµÁ£ºÈëÊÒµÁÇÔ±¨¾¯2) ·À¿ÉȼÆøÌåÖж¾£ºÈ¼Æø鶱¨¾¯3) ·À»ð£ºÑ̸б¨¾¯4) ÇóÖú¡¢·À½Ù£º½ô ¼±Çé¿ö±¨¾¯£¬¿ÉÓÃÓÚÀÏÈË¡¢Ð¡º¢ÒâÍâʹʡ¢¼±²¡±¨¾¯¡£ E-mail:zhujindong@163.com http://www.110alarm.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 20 10:10: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 KAA00720 for ; Thu, 20 Jun 2002 10:10:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24179 for nsis-archive@odin.ietf.org; Thu, 20 Jun 2002 10: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 JAA22670; Thu, 20 Jun 2002 09:53: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 JAA22641 for ; Thu, 20 Jun 2002 09:53:39 -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 JAA00086 for ; Thu, 20 Jun 2002 09:52:57 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 09:51:59 -0400 Message-ID: From: "Shahrier, Sharif M." To: nsis@ietf.org Subject: [NSIS] New I-D on framework for QoS signaling Date: Thu, 20 Jun 2002 09:51:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C21861.A5850DD0" 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_01C21861.A5850DD0 Content-Type: text/plain; charset="iso-8859-1" The following draft is a framework document for QoS signaling for NSIS. We request that it be considered for working group document. <> Sharif. ------_=_NextPart_000_01C21861.A5850DD0 Content-Type: text/plain; name="draft-shahrier-nsis-fwk-00.txt" Content-Disposition: attachment; filename="draft-shahrier-nsis-fwk-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft = S. M. Shahrier = =20 K. M. Shaheen=20 = Document: draft-shahrier-nsis-framework-00.txt InterDigital = Expires: December 2002 = =20 A Framework for Bi-Directional QoS Signaling=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 months=20 and may be updated, replaced, or obsolete by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material = or to cite them other than as "work in progress."=20 =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 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [1].=20 =20 Abstract=20 =20 This Internet Draft describes the end-to-end signaling architecture and = framework model for transmitting packets through a series of=20 heterogeneous networks. The Next-Steps-In-Signaling (NSIS) Working=20 Group is already working on defining a set of requirements for the QoS=20 signaling protocol [1]. This document is the follow on to the=20 requirements draft, and the precursor to any solutions document. It=20 outlines a framework for transporting end-to-end QoS parameters,=20 initiated and maintained by the =93Originator=94 of the service.=20 =20 This draft elaborates on the requirements draft. It defines more=20 precisely the scope of NSIS for end-to-end packet flows, in terms of =20 QoS Signaling, where the resource reservations for the service are =20 initiated by the =93Originator=94 end point and whether this service is = bi- directional or unidirectional (i.e., receive-only or send-only). The=20 draft is fully backward compatible; it requires no changes to the=20 existing QoS signaling protocols or procedures. It applysapplies=20 =20 Shahrier Standard Track =96 Expires December 2002 = 1 =0C A Framework for Bi-Directional RSVP June 2002=20 in the Wireless Internet=20 =20 generic messages to transport the information needed to establish the=20 desired QoS for traffic flows in either one or both directions. This=20 document can be used as the guideline for a prospective solution to the = QoS signaling problem. =20 =20 =20 1. Introduction=20 =20 With the current evolution toward wireless data, wireless internet, and = wireless multimedia applications such as Voice over IP (VoIP), video=20 conferencing, and Video telephony, performance requirements similar to=20 those of existing circuit switched or voice based wireless systems are=20 essential. Among these performance requirements are call setup time,=20 delay, reliability, and Quality of Service (QoS). Ensuring QoS,=20 providing faster call setup time, while reducing the number of QoS=20 control messages across the network, is the subject of this note. =20 =20 This draft introduces the concept of and the architectural framework = for=20 bi-directional resource reservation signaling protocol for both=20 Controlled-Load and Guaranteed QoS control services. The existing RSVP = signaling allows for uni-directional resource reservations only in the=20 =93send=94 direction, while the proposed signaling protocol generalizes = the=20 process by allowing simultaneous bi-directional (=93send=94 and = =93receive=94)=20 resource reservations on each hop. The proposed signaling protocol is=20 most suitable for applications in which the =93Originator=94 of a = service is=20 solely responsible for making the necessary reservations, = authentication=20 and their cost. =20 =20 While it is important and necessary to consider QoS from an end-to-end=20 prospective, the NSIS Working Group shall restrict the scope of its=20 activities to the transport and signaling of QoS packets in the NSIS=20 domain only. The objective of this draft is to provide an overview of=20 the architecture and signaling within the NSIS network.=20 =20 2. Bi-Directional Signaling Protocol Model=20 =20 The underlying assumption is that the =93Originator=94 of a multimedia=20 session negotiates the media information with the =93Terminated=94 = side. =20 Both sides have to agree on the means by which the session will be=20 carried, including the type of service (audio, video, or/and text),=20 codec information, bit rate for both directions, port numbers, etc. In = order to allocate resources for the negotiated session within the NSIS=20 network, the originator of the multimedia session invokes reservation=20 procedures using the proposed bi-directional signaling protocol. The = Bi- directional signaling protocol carries the QoS control objects that=20 specify the QoS necessary to carry the traffic in both directions.=20 =20 =20 Shahrier Standard Track - Expires December 2002 2=20 =0C A Framework for Bi-Directional RSVP June 2002=20 in the Wireless Internet=20 =20 =20 2.1 Summary of Bi-directional Signaling Protocol=20 =20 The operation of the bi-directional signaling proceeds as follows:=20 =20 1) The =93Originator=94 provides the QoS parameters describing the = nature of the traffic (including the transaction Type; uni- directional or bi-directional). This information is used to=20 construct the various objects of the message format. =20 =20 2) The =93Originator=94 sends an initial =93Setup=94 message to = the=20 =93Terminated=94 end point and waits for a response. =20 =20 3) The initial =93Setup=94 message follows a predetermined route = to the=20 =93Terminated=94 end point where it requests the assignment of=20 resources needed to carry the desired traffic flows. =20 =20 4) In each hop, the router updates certain fields that indicate=20 whether the requested resources are available and forwards the=20 updated initial =93Setup=94 message to the next hop. =20 =20 5) At the =93Terminated=94 end point, the updated =93Setup=94 = message is=20 examined. If the resource allocation is satisfactory, a =20 =93Terminated=94 end point wishing to complete the transaction=20 replies to the =93Setup=94 message with an =93Acceptance=94 = message. =20 =20 6) The =93Acceptance=94 message follows the same path that carried = the=20 =93Setup=94 message from the =93Originator=94 end point. = The=20 =93Acceptance=94 message carries the final resources that are = needed=20 to be installed in the various hops along the signaling route.=20 =20 7) At each hop ,hop, the =93Acceptance=94 message is processed to=20 establish the required resources and then forwarded to the next=20 hop toward the =93Originator=94 end point.=20 =20 8) At the =93Originator=94 end point, the final =93Acceptance=94 = message=20 is processed. If successful, the =93Originator=94 end point = replies=20 with a =93Confirmation=94 message back to the =93Terminated=94 = end point=20 to acknowledge the establishment of the traffic path.=20 =20 9) During the session, the =93Originator=94 end point is = responsible=20 for maintaining the resources.=20 =20 10)If either side decides to terminate the session, a = =93Disconnect=94=20 message is sent by the side terminating the resources along the=20 established route. =20 =20 Shahrier Standard Track - Expires December 2002 3=20 =0C A Framework for Bi-Directional RSVP June 2002=20 in the Wireless Internet=20 =20 =20 3. Signaling Diagrams=20 =20 This section shows, the signaling diagrams for the Bi-directional=20 signaling protocol. The diagrams show that the proposed protocol is=20 backward compatible with existing QoS signaling protocols.=20 =20 3.1 Connection Setup (Accepted)=20 =20 =20 Originator IP NETWORK = Terminated=20 | | | = |=20 | Setup(Type,QoS Param) | PATH(Type,QoS Param) | PATH(Type,QoS = Param) |=20 |------------------------>|--------------------- = -->|------------------------>|=20 | | | = |=20 | | | = |=20 | Accept(Type,QoS Param) | Accept(Type,QoS Param) | Accept(Type,QoS = Param) |=20 |<------------------------|<------------------------|<------------------= ------|=20 | | | = |=20 | | | = |=20 | CONF | | = | |------------------------>|------------------------>|-------------------= ----->|=20 | | | = |=20 =20 =20 3.2 Connection Setup (Rejected)=20 =20 =20 Originator IP NETWORK = Terminated=20 | | | = |=20 | Setup(Type,QoS Param) | PATH(Type,QoS Param) | PATH(Type,QoS = Param) |=20 |------------------------>|--------------------- = -->|------------------------>|=20 | | | = |=20 | | | = |=20 | Denied(Type,QoS Param) | Denied(Type,QoS Param) | Denied(Type,QoS = Param) |=20 |<------------------------|<------------------------|<------------------= ------|=20 | | | = |=20 | | | = |=20 | CONF | | = | |------------------------>|------------------------>|-------------------= ----->|=20 | | | = |=20 =20 =20 3.3 Connection Teardown=20 =20 =20 Shahrier Standard Track - Expires December 2002 4=20 =0C A Framework for Bi-Directional RSVP June 2002=20 in the Wireless Internet=20 =20 =20 Originator IP NETWORK = Terminated=20 | | | = |=20 | | DISCONN | = |=20 |------------------------>|------------------------>|-------------------= ----->|=20 | | | = |=20 =20 =20 =20 =20 4. References=20 =20 [1] Brunner, J., "Requirements for QoS Signaling Protocols=94, = draft- nsis-req-02.txt (work in progress), may 2002.=20 =20 =20 =20 5. Contact Information=20 =20 Sharif M. Shahrier=20 InterDigital =20 781 Third Ave. Phone: 1-610-878-7878=20 King of Prussia, PA. USA Email: sharif.shahrier@interdigital.com = =20 Kamel M. Shaheen=20 InterDigital =20 781 Third Ave. Phone: 1-610-878-7878=20 King of Prussia, PA. USA Email: kamel.shaheen@interdigital.com=20 =20 =20 =20 =20 =20 =20 Shahrier Standard Track - Expires December 2002 5=20 =0C ------_=_NextPart_000_01C21861.A5850DD0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 20 13:16: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 NAA07238 for ; Thu, 20 Jun 2002 13:16:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07577 for nsis-archive@odin.ietf.org; Thu, 20 Jun 2002 13:17: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 MAA06226; Thu, 20 Jun 2002 12:57: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 MAA06191 for ; Thu, 20 Jun 2002 12:56:58 -0400 (EDT) Received: from legend-mfy8zk0p ([61.144.241.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06569; Thu, 20 Jun 2002 12:56:11 -0400 (EDT) From: zhulinxi@yahoo.com.cn Message-Id: <200206201656.MAA06569@ietf.org> To: nsis@ietf.org Content-Type: multipart/mixed; boundary="=_NextPart_000_0018_01C1A1B3.E2C7FE20" MIME-Version: 1.0 Date: Fri, 21 Jun 2002 00:59:41 +0800 X-Priority: 3 X-Mailer: CSM 3.2 Subject: [NSIS] FJ-850 =?GB2312?B?uuzN4s/fzL3Nt7y8yvXTxcrG?= 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_0018_01C1A1B3.E2C7FE20 Content-Type: text/plain Content-Transfer-Encoding: 7bit ©ú©úÔÚµç×Ó·ÀµÁ̽²âÆ÷ÁìÓò£¬±»¶¯ºìÍâ̽²âÆ÷µÄÓ¦Ó÷dz£¹ã·º£¬ÒòÆä¼Û¸ñµÍÁ®¡¢¼¼ÊõÐÔÄÜÎȶ¨¶øÊܵ½¹ã´óÓû§ºÍר ÒµÈËÊ¿µÄ»¶Ó­¡£µ«Ëæ×ÅÈëÇÖÕߵķ´Õì²â¼¼ÊõÊֶεÄÌá¸ß£¬´Ó¶ø¶Ô̽ͷµÄÒªÇóÒ²Ô½À´Ô½¸ß£¬ÆÕͨ±»¶¯ºìÍâ̽ͷµÄ¾ÖÏÞ ÐÔÒ²Ô½À´Ô½Ã÷ÏÔ£¬ÕâÑù£¬ÐÂÒ»´úµÄ±»¶¯ºìÍâ̽ͷҲӦÔ˶øÉú¡£ÒòΪÈÕ±¾µÄ¸»ÊË´ï(FUJAIMD)µÄ̽ͷ²ÉÓÃÁ˺ܶà×îР¼¼Êõ£¬Ê¹ÓÃÒ²½ÏΪ¹ã·º¡£ËùÒÔ£¬ÏÂÃæ¾Í½áºÏ¸Ã²úÆ·µÄ¼¼ÊõÌØÐÔÀ´²ûÊö±»¶¯ºìÍâ̽ͷµÄ×îм¼Êõ¡£ ©ú©ú±»¶¯ºìÍâ̽ͷµÄ¹¤×÷Ô­Àí¼°ÌØÐÔ ©ú©ú±»¶¯ºìÍâ̽ͷÊÇ¿¿Ì½²âÈËÌå·¢ÉäµÄºìÍâÏ߶ø½øÐй¤×÷µÄ¡£Ì½Í·ÊÕ¼¯Íâ½çµÄºìÍâ·øÉäͨ¹ý¾Û¼¯µ½ºìÍâ¸ÐÓ¦Ô´ÉÏ¡£ ºìÍâ¸ÐӦԴͨ³£²ÉÓÃÈÈÊ͵çÔª¼þ£¬ÕâÖÖÔª¼þÔÚ½ÓÊÕÁ˺ìÍâ·øÉäζȷ¢Éú±ä»¯Ê±¾Í»áÏòÍâÊͷŵçºÉ£¬¼ì²â´¦Àíºó²úÉú ±¨¾¯¡£ ©ú©ú1)ÕâÖÖ̽ͷÊÇÒÔ̽²âÈËÌå·øÉäΪĿ±êµÄ¡£ËùÒÔ·øÉäÃô¸ÐÔª¼þ¶Ô²¨³¤Îª10UM×óÓҵĺìÍâ·øÉä±ØÐëÃô¸Ð¡£ ©ú©ú2)ΪÁ˽ö½ö¶ÔÈËÌåµÄºìÍâ·øÉäÃô¸Ð£¬ÔÚËüµÄ·øÉäÕÕÃæͨ³£¸²¸ÇÓÐÌØÊâµÄÂ˹âƬ£¬Ê¹»·¾³µÄ¸ÉÈÅÊܵ½Ã÷ÏԵĿØÖÆ ×÷Óᣠ©ú©ú3)±»¶¯ºìÍâ̽ͷ£¬Æä´«¸ÐÆ÷°üº¬Á½¸ö»¥Ïà´®Áª»ò²¢ÁªµÄÈÈÊ͵çÔª¡£¶øÇÒÖƳɵÄÁ½¸öµç¼«»¯·½ÏòÕýºÃÏà·´£¬»·¾³ ±³¾°·øÉä¶ÔÁ½¸öÈÈÊÍÔª¼þ¼¸ºõ¾ßÓÐÏàͬµÄ×÷Óã¬Ê¹Æä²úÉúÊ͵çЧӦÏ໥µÖÏû£¬ÓÚÊÇ̽²âÆ÷ÎÞÐźÅÊä³ö¡£ ©ú©ú4)Ò»µ©ÈËÇÖÈë̽²âÇøÓòÄÚ£¬ÈËÌåºìÍâ·øÉäͨ¹ý²¿·Ö¾µÃæ¾Û½¹£¬²¢±»ÈÈÊ͵çÔª½ÓÊÕ£¬µ«ÊÇÁ½Æ¬ÈÈÊ͵çÔª½ÓÊÕµ½µÄ ÈÈÁ¿²»Í¬£¬ÈÈÊ͵çÒ²²»Í¬£¬²»ÄܵÖÏû£¬¾­ÐźŴ¦Àí¶ø±¨¾¯¡£ ©ú©ú5)¶àÊÓ³¡µÄ»ñµÃ£¬Ò»ÊǶ෨ÏßС¾µÃæ×é³ÉµÄ·´¹â¾Û½¹£¬¾Û¹âµ½´«¸ÐÆ÷ÉϳÆ֮Ϊ·´Éäʽ¹âѧϵͳ¡£ÁíÒ»ÖÖÊÇ͸Éä ʽ¹âѧϵͳ£¬ÊǶàÃæ×éºÏÒ»ÆðµÄ͸¾µ¡ª¡ª·ÆÄá¶û͸¾µ¾Û½¹ÔÚºìÍâ´«¸ÐÆ÷ÉÏ¡£ ©ú©ú6)ÔÚÕâÀïÒªÖ¸³öµÄÊDZ»¶¯ºìÍâµÄ¼¸Êø¹â±íʾÓм¸¸öÊÓ³¡£¬²¢·Ç±»¶¯ºìÍâ·¢ºìÍâ¹â£¬ÊÓ³¡Ô½¶à£¬¿ØÖÆÔ½ÑÏÃÜ¡£ ©ú©ú±»¶¯ºìÍâ̽ͷµÄÓÅȱµã£º ©ú©úÓŵ㣺±¾Éí²»·¢ÈκÎÀàÐ͵ķøÉ䣬Æ÷¼þ¹¦ºÄºÜС£¬Òþ±ÎÐԺ᣼۸ñµÍÁ®¡£ ©ú©úȱµã£º ©ú©ú¡ôÈÝÒ×Êܸ÷ÖÖÈÈÔ´¡¢¹âÔ´¸ÉÈÅ ©ú©ú¡ô±»¶¯ºìÍ⴩͸Á¦²î£¬ÈËÌåµÄºìÍâ·øÉäÈÝÒ×±»ÕÚµ²£¬²»Ò×±»Ì½Í·½ÓÊÕ¡£ ©ú©ú¡ôÒ×ÊÜÉäƵ·øÉäµÄ¸ÉÈÅ¡£ ©ú©ú¡ô»·¾³Î¶ȺÍÈËÌåζȽӽüʱ£¬Ì½²âºÍÁéÃô¶ÈÃ÷ÏÔϽµ£¬ÓÐʱÔì³É¶ÌʱʧÁé¡£ ©ú©ú±»¶¯ºìÍâ̽²âм¼Êõ˵Ã÷ ©ú©úÏÂÃæÕë¶ÔÉÏÊöµÄ±»¶¯ºìÍâ̽²âÆ÷µÄȱµã£¬½áºÏ¸»ÊË´ïµÄºìÍâ̽²â¼¼Êõ£¬½øÐÐÏêϸ·ÖÎö¡£Í¨¹ý¶ÔÆäȱµã·ÖÎö·¢ÏÖ £¬ÎÒÃÇʵ¼ÊÉÏ¿ÉÒÔ½â¾öÎ󱨺Í̽²âϽµÉõÖÁʧÁéµÄÎÊÌ⣺ ©ú©ú1¡¢Îó±¨ÎÊÌâ ©ú©úΪÁ˽µµÍÎó±¨ÂÊ£¬Ö»ÒªÅųýÎ󱨵ÄÒòËؾͿÉÒÔ¡£ ©ú©úÎ󱨵ÄÒòËØ¿ÉÒÔ·ÖΪÁ½Àࣺ ©ú©úÍâ½çµÄÒòËØ: ©ú©ú¡ñ Íâ½çµÄÈȹâÔ´£¨ÓÈÆäÊÇ°×¹â¹âÔ´£©£ºÈçÑô¹â¡¢ÕÕÃ÷¹âÔ´µÈ; ©ú©ú¡ñ Íâ½çµÄÉäƵÐźš£ ©ú©úÄÚ²¿ÒòËØ: ©ú©ú¡ñÄÚ²¿ÓÉÓÚÆ÷¼þµÈµÄÔëÉùºÍ¸ÉÈÅ£¬Èç¹âÈÈÊ͸ÐÓ¦Æ÷µÄÐźÅ˲±äµÈ¡£ ©ú©úÕë¶ÔÒÔÉÏÇé¿ö£¬¸»Ê˴﹫˾µÄÐÂÒ»´øºìÍâ̽ͷ¡¢²ÉÓÃһЩ¶ÀÌصļ¼ÊõÀ´½â¾ö´ËÀàÎÊÌâ¡£ ©ú©úÐźųö/Èë·ÖÎö ©ú©úµ±ÓÐÎïÌå×ßÈë»ò×ß³öÒ»¸ö̽²âÇø¶Îʱ£¬ÔÚ·´¼«ÐÔ̽²â¸ÐÓ¦Æ÷ÉÏ»á²úÉúÁ½¸ö¼«ÐÔÏà·´µÄÐźţ¬ÕâÖÖ³ö/ÈëÐÅºÅµÄ ÄÜÁ¿½«±»¶ÀÁ¢·ÖÎö²¢´¢´æÔÚÄÚ´æ¼ÇÒäÄÚ¡£ Ö»ÓÐÔÚÒ»¶ÎÌض¨µÄʱ¼äÄÚ£¬µ±Á½¸ö¸ÐÓ¦Æ÷É϶¼ÊÕ¼¯µ½×ã¹»µÄ³ö/ÈëÄÜÁ¿Ê± ²Å»á´¥·¢¾¯±¨¡£ ©ú©úÆäÓŵ㣺 ¡°Ðźųö/Èë·ÖÎö¡±Äܳ¬ºõÏëÏóµØÌá¸ß̽ͷ¶ÔÆøÁ÷¡¢Ëæ»úÔëÒô¼°·¢ÈÈÆ÷µÄ¿¹¸ÉÈÅÄÜÁ¦¡£ÈçÔÙ¼ÓÉÏ¡°ËÄ Ô´ºìÍâ·´¼«ÐÔ̽²â¡±£¬ÄÜʹ̽ͷ¾ßÓг¬×¿µÄ¿¹¸ÉÈÅÄÜÁ¦£¬ÊÇÏÖ½ñÊг¡ÉÏ×îÓÅÐãµÄ²úÆ·¡£ ©ú©úËÄÔ´ºìÍâ·´¼«ÐÔ̽²â(רÀû) ©ú©ú̽ͷÄÚÖÃÁ½¸öºìÍâ¸ÐÓ¦Æ÷,Òƶ¯ÐźŻáʹÁ½¸ö¸ÐÓ¦Æ÷²úÉúÁ½¸ö¼«ÐÔÏà·´µÄÐźţ»¶ø·ÇÒƶ¯ÐźÅ(ÉäƵ¡¢µç´Å¡¢»ð »¨¡¢¾²µçµÈ¸ÉÈÅ),ÔòʹÁ½¸ö¸ÐÓ¦Æ÷²úÉúÁ½¸ö¼«ÐÔÏàͬµÄÐźš£ÀûÓôËÔ­Àí±ã¿É׼ȷÎÞÎóµØÇø·ÖÒƶ¯ºÍ·ÇÒƶ¯Ðźš£ ©ú©úÆäÓŵ㣺 ©ú©ú1.Ó¦Óô˼¼ÊõËù»ñµÃ¿¹¸ÉÈÅÄÜÁ¦ÊÇ´«Í³µÄÂ˲¨¼°ÆÁ±Î¼¼ÊõËùÎÞ·¨Ïà±ÈµÄ£» ©ú©ú2.¾ßÓг¬×¿µÄ·ÀС¶¯ÎïÄÜÁ¦¡£ ©ú©ú×Ô¶¯Âö³åÊýµ÷½Ú: ©ú©úËùÓи»ÊË´ïÅÆ̽ͷ¶¼ÓдËÏȽø¹¦ÄÜ¡£¡°×Ô¶¯Âö³åÊýµ÷½Ú¡±Äܼì²âÿ¸öºìÍâÐźÅÄÜÁ¿µÄ´óС£¬È»ºó°ÑÊý¾Ý´¢´æÔÚ ÄÚ´æ¼ÇÒäÄÚ¡£Ì½Í·ÄÜ×Ô¶¯¸ù¾ÝÄÚ´æ¼ÇÒäÄÚµÄÄÜÁ¿Ë®Æ½¸Ä±ä¹¤×÷ģʽ£º ©ú©ú1¡¢µ±ÄÜÁ¿Ë®Æ½¸ßʱ(´ËʱÎ󱨵ĻúÂʽϵÍ)£¬Ê¹ÓõÍÂö³åÊýģʽ£¬ ¹¦ÄܸúÒ»°ã·ÇÂö³åÊýµ÷½Ú̽ͷһÑù¡£ ©ú©ú2¡¢µ±ÄÜÁ¿Ë®Æ½µÍʱ(Î󱨵ĻúÂʽϸß)£¬ ʹÓøßÂö³åÊýģʽ(×î¸ß¿É´ï25¸öÂö³å)£¬¿ÉÓÐЧ·ÀÖ¹Î󱨵ķ¢Éú¡£ ©ú©úÓŵ㣺ÓÐЧ·ÀÖ¹Î󱨶ø²»½µµÍÁéÃô¶È¡£ ©ú©ú2¡¢Ì½²âÄÜÁ¦µÄ½µµÍ ©ú©ú̽²âÄÜÁ¦Ï½µ¿ÉÒÔ·ÖΪ¼¸¸ö·½Ã棺 ©ú©ú̽²âÆ÷¸÷̽²âÊÔ³¡·Ö²¼²»ºÏÀí£ºÈç¿Õ϶¹ý´ó£¬Ì½²âÆ÷±»ÕÚµ²£¬Èç±»ÅÝÄ­¡¢ÑÌÎí£¨ÈëÇÖÕß¾­³£Ê¹ÓõÄÊֶΣ©¡¢Ö½ ¡¢ÒÂÎïµÈ¡£ÓÉÓÚÌåκͻ·¾³²î±ð²»´ó£¬Ôì³É̽²âÄÜÁ¦Ï½µ¡£ Õë¶ÔÒÔÉÏÇé¿ö£¬¸»Ê˴﹫˾²ÉÓÃÒÔÏ·½·¨À´½â¾öÎÊÌâ ¡£ ©ú©ú¸ßÖÊ LODIF ¶Îʽ FRESNEL ͸¾µ (רÀû) ©ú©úÎÞÂÛÊÇÇåÉ«¶È£¬×¼È·¶È¼°¾Û½¹ÄÜÁ¦¸÷·½Ãæ¾ù±È´«Í³µÄFRESNEL͸¾µ¸ß³ö30%¡£Í¸¾µ²ÄÁϲÉÓøßÖÊ¿¹°×¹â¸ÉÈÅÎïÁÏ ÖÆÔ죬²¢²ÉÓ÷ֶÎʽÉè¼Æ¡£ ©ú©úÓŵ㣺 ©ú©ú1. ÄÜÓÐЧµØÊÕ¼¯ÈËÌå·¢³öµÄÄÜÁ¿£» ©ú©ú2. Ïû³ýËÀλ£» ©ú©ú3. ¸ß¿¹°×¹â¸ÉÈÅÄÜÁ¦¡£ ©ú©ú΢²¨·ÀÕÚµ²¹¦ÄÜ (רÀû) ©ú©úÖ»ÒªÓÐÈκÎÕÚµ²ÎïÔÚ̽ͷһÃ×¾àÀëÄÚÒƶ¯,±ã»áÂíÉÏ´¥·¢¾¯±¨¡£ ©ú©úÓŵ㣺¿ÉÓÐЧ·ÀÖ¹´³ÈëÕßÒÔÎï¼þÕÚµ²Ì½Í·£¬Ê¹Ì½Í·Ê§È¥×÷Óᣠ©ú©úÖ÷¶¯Î¢²¨×ÔÎÒ¼ì²â¹¦ÄÜ (ÃÀ¹úרÀûºÅ 5-287-111) ©ú©ú΢²¨·¢ÉäÆ÷ÿ¸ô3·ÖÖÓ±ã×ÔÎÒ¼ì²âÒ»´Î£¬ ¶ø×ÔÎÒ¼ì²âÊDz»Ðèͨ¹ýÒƶ¯ÎïÌå´¥·¢¡£Èç·¢ÏÖ¹ÊÕÏ£¬¹ÊÕÏ¿ª¹Ø±ãÂíÉÏ ±»´¥·¢¡£ ©ú©úÓŵ㣺¿ÉÈ·±£Ì½Í·¹¤×÷Õý³££¬ÍòÒ»·¢Éú¹ÊÕÏÒà¿É¼°Ê±¸ü»»¡£ ©ú©ú½»µþʽºìÍâÔ´(ISG)(רÀû) ©ú©ú´«Í³µÄËÄÔ´ºìÍâÉè¼ÆÔÚ̽²âÔ¶¾àÀëÎïÌåʱÁéÃô¶È»á½µµÍ, ÕâÊÇÒòΪÈËÌåÔÚÔ¶¾àÀëʱ²»»áͬʱͨ¹ýÉÏÏÂÁ½¸öºìÍâ Ô´, ËùÒÔ±ãÔì³ÉÁéÃô¶È½µµÍÉõÖÁʧÁé¡£"½»µþʽºìÍâÔ´"ÄÜÓÐЧµØ½â¾ö´ËÎÊÌâ¡£ ©ú©úÓŵ㣺 ©ú©ú1.ÓÐЧµØ½â¾öÔ¶¾àÀëÁéÃô¶È½µµÍ¼°Î¶ÈÉÏÉý¾àÀëËõ¶ÌµÄÎÊÌ⣻ ©ú©ú2.¿É°Ñ¾àÀëÌá¸ßÖÁ´«Í³Éè¼ÆµÄ¶þ±¶£» ©ú©ú3.¼ò»¯µ÷ÊÔ¹ý³Ì¡£ ©ú©ú×Ô¶¯Î¶Ȳ¹³¥ ©ú©ú¡°×Ô¶¯Î¶Ȳ¹³¥¡±ÄÜ×Ô¶¯µ÷½Ú·Å´óÆ÷¹¦ÂʵĴóСÀ´Æ½ºâÒòζȱ仯ÒýÆðµÄÁéÃô¶È±ä»¯ÏÖÏñ¡£ ©ú©úÓŵã: ʹ̽ͷÔÚÕû¶Î¹¤×÷ζÈÇøÄÚ¶¼ÓÐÎȶ¨µÄÁéÃô¶È¡£ ©ú©ú3¡¢ÆäËûһЩм¼ÊõÓ¦Óà ©ú©ú¡ñʵʱÊý×Ö´¦Àí¹¦ÄÜ ©ú©ú¡ñÒƶ¯¼¼Êõ ©ú©ú¡ñ±³¾°·ÖÎö ©ú©ú¡ñÉäƵ/µç´Å¸ÉÈű£»¤ ©ú©ú¡ñÍ걸µÄµçѹ¿ØÖÆ http://www.110alarm.com --=_NextPart_000_0018_01C1A1B3.E2C7FE20 Content-Type: application/octet-stream; name="ºìÍâÏß.gif" Content-Disposition: attachment; filename="ºìÍâÏß.gif" Content-Transfer-Encoding: base64 R0lGODlheABHAPf/AP///yEhISkpKTExMTk5OUJCQkpKSmNjY8bGxs7Ozr21tZyUlHNra1pSUmNa WlJKSkpCQkI5OTkxMTEpKVpKSko5OUIxMTkpKUIpKUopKVoxMWMxMXs5MWM5MYRCMXtCMaVSOZRj UoxKMXNKOWtCMa1aOaVSMUo5MXNSQqVaOZxSMWNCMXtKMZxaObVjOVJCOZxjQrVrQq1jOa1rQmNK OXtaQqVrQoRaOb17Sq1rObWMa5RrSoxjQr2EUpxrQrV7Sq1zQsa9tWNaUmNSQnNrY7WllFJKQntj SrWMY5xzSr2MWntaObWEUq2lnEpCOb2UY7WMWq2EUrWce62Uc6WMa2taQoxzUoRrSntjQr2UWq2E Sr2ca7WUY5x7Sr2tlHtrUsathJR7Usa9rb2le8ala3tzY8a1lL2tjLWlhKWUc5SEY4RzUr2lc7Wc a5yEUrWtnJSMe1JKObWcY8a1jL2thLWle5yMY6WchIR7Y62ca87Grb21nLWtlK2ljJSMc3NrUsa9 nKWce721lJyUc4yEY6Wcc721jM7OxtbWzrW1rZyclGtrY87OvZycjJSUhNbWvc7OtYSEc729pcbG rTk5MaWljNbWtcbGpWNjUr29nFpaSnt7Y5SUc3uEY4SMc1JaQoSMe3N7a73GtZyllHuEczlCMZyt lFJjSsbOxs7WzrW9taWtpa21rb3GvYyUjJylnJytnIycjJSllISUhHuMe3OEczE5MYSchCkxKVJj UnOMc2uEa2N7YzlKOVJrUkJrSkprUkJjSpStnHOMe2uEc1JrWkpjUoScjGN7a1pzYzlSQjljSpSl nHOEe1JjWjFCOa29taW1rYyclISUjCk5MUJjUnuMhDlKQjlaSkpjWlpzazlSSsbOzrW9vaWtrYyU lISMjGtzc3uEhGNra0pSUoycnGt7ezlCQjE5OWNzc1praykxMSEpKTlKSkpjYzFCQkJaWkJSWkpa Y0pSWkpaa8bGzjk5QjExOSEhKVpSWkpCSjEpMTkpMWNSWkIpMQAAACwAAAAAeABHAEAI/wARCUSU oGDBQwkQHkKYcKHDhxARIDiEoNWhIAgwBtnIMUgrjwqCKBhJUoGqkYkUJFrJkmWTRE1YNWmyaqZN mzVpNnm185XPnz4XKBoqdIHRo42adHu3b0DTdQOgrkOH7p24bq2wthK1VYGYRJL2hJWUSdCcOWfQ 0mGz5YkSHD9qSFi3bt+6CXcHTNB7Vyrev33xRhU8OLDeAQL4Oo3KF7Djw3sdC3CAoN0zdM+evXtX q1UrBIxAozo0mpFpRpAEgaGzWpKYsoJin6lDp/aZS60YBYE0KdMYHVCiMPkxorDjusjtMk48wHje vYkJM0ZMPbF1yIevC3iAwNg2A8HIyf9ShQDVwYKpCiJK5RDQEyhFUIVGFUSQodj2BfGJzYdPpjNt cMGGJKYFcUkdbSARHBNJWCAVY+vYMgA6EdqCTnO2PAhVc39Nx9hxj0VGHS6IbZdAMtVUY0w1zWCF ADcGJZCeQDLSiMghjxySCRJU7MHIIaZNcskkQtq3hyBj1DHGGWKgBgkgdIzBxhRbQAEFE0xU0Ysy 12zZ5TVggpnZmO+MmRk1Z9pCjS1qPqOmmgNQA2FzHM65Di76oJKMMcYAw6eKzbCiSjcIxChjjYfe eCOOqeTIyCOPPgIJb0RKcgkgmAJihhm1SdnWlT/48IkywSijzCefBGPAL6f44osDyRT/U0ysxfji jDHBbKPMmGquuSabvr75K5vApkkNOa3gik0wwSy7LLPBVBNMMqNAY203hKKiLWmkaVtRRZ+Bqwo0 q7yyyirM+MTKZ9rCiAo35bn74ouolFdevZ6h4plnoqiiSiKsADyTKYr0cccggwRChR1uJJGEDz60 ILEKIrAQRy8YZ9yLM8nyCS20uDLrS6u+AFOyq7WenIwus0zzzTTggCOOOeakk4469MxDTjsErKNP N/XAqF4CNMaYCkEFCQ0jN9zUI1E93rromQKirCRJE3z0gUYgUyARRRRazDCDDDKUQLbYMsTQggTN bddNMdnI6ousdM86KzLIaIMMMXzX/9LMMLQM04w1s8xizeGIJ6444dM0Po014ogDjsuyrAINoUxn Di8C2HbjLyugnyv6KqMM1YgjoMDhCSFlfHFEDTfELrHEInCggQS4NKWcU7isE0E390QW2PB42UUX OvOM04wrsgw1Sh8G+0HIH5pAgNg6ieWuPWMk5i7idcQPX1hz2u/jfWOMPdVY+CIK/9dkCLxD1fxU PeOOKvmOlttpTk6qxyUA1IMeLEHAAhYQEHMAAxncwgS40GAfzHFKXUjEvr6MzznfU0xzNqSd6mAH OtXJByrI8Q4uXSMXsGhFvVBRj4QchDQWgQQauMCFPojCJGKQxBv4YIj+7OdIPGyDDv/acAauTEoS deDCguJSl8QgZ04XitA9LhQV5TyHOtLhoAev074RQfABCSgGs8jhjFV0412GOhrR1rieQxgCClMI AkQgARtACCITmfChIaTUBjo0CTVIYgMXFMSEHqCAAM8oBa8yY4vLNNJN6LAQOtA0yQwBi1jU2AtU yle+9g1PABA4kYqAQUpi4O9FSUOPQdKjxjYeAhE5uoQg6iAFOpxhD5kwxBn48IZMSOKXlrIPGMYg JR18SglMwMKpTGWqLTGzF88w1TWi+QxoMpKRaHrTM34VrGBJaAASktOa6GIAVGQjWtBKEZ+KEQt/ YQWN5lEIe9jzkNMAyTSTSsQkwAL/kybAYhSNaMQsIrELBswiEZ9hhGf+BYtYWIN5sYiFLF4hC1lE 1HDWmAYtalELUtRiEX9wQC40oQkG3GIUt/BEJ9ZwBSzQ4ASXfBOxGtlIcnQDGB9jFqk+hitSkpIX s1hFNLxBVKKyAhqDwtagrgUNog51qN6IBioNtcoECM2qSYNa0LixQnuFayut8JcqQDeTShgsEGmg AhXc0LAu2OCtKYirxEzQghP0wgm9cIAqfGEMVwWDT34KGbPAw6e+AsMZ2QBGNhbrDnfIo7GNpYdk k6GOytIDZ5K9LM7MwYxuZO5QqQhtaNFDENFaVXOa89a+/gWwrN1BYQyLghtmANcU/8zAbGJzQQsc hBhcQKAVyQhuMnjBC7ztTRu74BstaHG4Wzj3GBGNqDSkEYtjULe60o2uKyJ6i1hMI6KyYAYsxguL VZTXvOhNl0+YEd7pyuJlMZuFOJrRDJqF477hGMc4DuAMB/gXEw14gIAfYAQCG8EIEDDCC5yw4Be8 oAIQjoCEKdCKewjgwri4sIYvjL0NY+/DAuiwh0M8AQ2DWAC4KLFdQhwdvUwgxU48jgDwEmII5u5O iIHgPibA47soZx922fEnIdghHvM4xSkucT9aQYAZm+/JN7bLPdbRjmZ443MseUPA3oC1ImgNDWOY gg7ekwQURAB7FBxA97ADPhBZ0P+Cavag+9L3oQp20TEQdEArzrGOKfq5z1WZBv72lZvcQCIIRBID ABedKQBqKoGecksPcMADB0WnKYDBoPjgTLzsaHA6HeQim7EogHxUpn6YoUpn8tUth/APEpfYVKYw tehLQMISj5DUbgxkCDbI4Upa0MISIHQcKD/ZLxvqNAiz2LYtYnHUzCl1ZTTzjmmGY9ASGQ1FEro/ M7CBDW3gw1dW8hr78OEM6EaDENtgiCDoZlKCYIOChAOEFwjA2JsMcl92xz27ZJDZzhZ1BqP9AG6Q QxnbSDgtWCGRVo8Gaa42RBae8IZ96SY/sakjLt9gCDlsYQwEChIagAMqH8xlg3P/YoyF6KQhOlGH 31Bxc5H1AuXq5MkZCQ9GMVZBHqZRlY2hPcQcoKADBbiaEbC5T354qJ9et4ENaHD3bvaYoOCEigBs ospMJ5R1C6mJKsOKE8pR7m/2jZpE1gmlGPmUi1eQB40wYiXRZkS0hVxikHsgzY+ABOtLZTwTaKAN baKOT061YQskZ4IWLoaxMVnTTGNCE6+oEUmZvilOGRKMXyBj7BsXQJTGWOzOszW09BiktOoRCKQm MYY8oGFIlNJDb/gjCDrwgUiIBsQZ6EBLeVupkFiAwDOh2UxlED8zu9oV5M2UzTVtU1iWlxCcIkR9 A3BjT4Xlky4GFS+qsnIg61nU/9EgBSneXIIsePwlICSRKUPMoVPffoKCevCDKowqGKNaJjP3X3zj P95NbsImzwd93uR1BKgm5YQiK6IifWIMyBAN3IdGpmd6oHUI9LQQkGIauOYkRDIJv4RH9sF7U5AH DbMDN8ADIRAJoNAJR7ADScBWVJAGd1AJjqA6nkAKnbAJmxAKpOAJKggKjvAKghI6rxALzZAMwbBN z7cmkcRNmOQm5IAAOJVOHyMtxcAM43I597ItC5EAo6EtjKAtYqhQCzVWoVMurzAUbuct9SIR4NKG hEZo/WISKwE6MGFeozAKsRBQjXAwg2AHdkAIXbADECMxHkACMEVTAPhIyCJYuf/SLM3yLNACDEEF OkeFVFsoEeECLkoFDdHwVEalQlx1CFflQgZBiknDNFvYhvoCLvxSNaBzNa9QCZXwWmmQVgzTBW4F Vy2QArRjMXdlfMXQDSuCTjn1MTj1CyXzC6TkC7twDMzADOgCC6/ADOXwDd8QjdooDdg4DfOVX9Dg c2s0dzJiWuXoc1zFNG2Yba5Yhv9iia9QBLWIVoDIVhCTAylANjLgAjIwAylgAQMgAbZAAd3AV8CQ C8gIWMHQjChTK7UCDHBTN76QDfMAD/MgDxiJkRcZDxzZkeLwWeoxgWl0KFiFWqmlWmH1jpnQBLU4 BWnFVl3gMGMzNiUwNjHgArr/JQFOBAGqkFh9cjJ9xVeF5QwRKVzaoDfIEA7EYA7hYDM2U1lPeTNO mQ40U5VOaQ7NwAzQ8CKaA1qs9JUlaVX0gpL9AjBXYzCFsDAvmARvZQO+SDsk4CBQ8WQCUAAKQCt0 I1xGuQvJVQuAs1yIcwuEMwvHcAuuUDgXFVGu4DiE2TLgNQrsRV6wUA7c+A3l4BPlsgrewArmFTDj kghmaIflogg06AhqQAhWsAZHgAJLMAIksAIaEJv+cAL+gAEAuRhNEZASwDZOAQEIYFzpwDd8Yw7D ADjW0F3gVVGyYAqwwJwVBQvi9QqmMJ3/RJ2mMAoVhZ3LOQqSeS6ScC7RIDrR/2CJocOZq3CG5kWN 0SgL1NU4kCMOtEBftYBf97UI4UAEDDAODEAE47AIi4CfDLAI/blf+xUOCPAABQABBVABEVAAEvag EBoBBCChEkoAFnqhFioBlLCbEkAAHfqh90AA9zCizcGbLudyPMZ5E0BkO3ZvOraifUEXdMFiJXZh NWpkOFpiNbphGxYAAZAPCoAOIbYYJ0qkdAJkdDFF9tAO7WAAO1MA9xAVNYabRbqiRPogdLIXRdoc mMaluXOiD6Ice0EixeMUQJabLJdyGzQZTDakW+pydNEO4SAN5yk6XPYGReBlaABmOoAEbnAEcSCl R7oXuqOmdfKmh8EhdQGm0/+RF2TqIVvacnAqAP2AAEIKqSxHFergDZ7hOXQIMCyhQ16AbnRQS2PQ FkrQA1pQAxWAPYdRqFh6qIiqpS8Hp416GGS6IYgqqWu6ZPYQq81BFe8wDWHVClSzL0EgCh4ITJlw KZvyrAk0TGwgaThgAzSAYmmqq4k6q1maF7aabOgjHZFqqFK6ZO0AdlPBhOjQIvsihkDSCofWgZMg Bv9zCQZUQHqgKWDABgvUA5NmAy9AFxckq2+qpR3yrWPXIRH0prxarnuWavXzDu3wCoTGLWOIGrtx KYAQQAOEa7mWa/gKJdOKTD8QA8XhqlqKpgXbrbSKcuBaZNpapA1bIg3QCuf/mhmY8QzbsAqeARrl ARHywQh6cBZECwi4tAdHkhZmcAl6AK+owQiTEG9tEBxA8APDtrCIih18obIptyEKm7V24nIX1gAI sA1kcg3b8AqayIYWEYaGJglSwgYgJwbjph88VAe0xEd7IHW6kQl1ABxRAARaQAOLeqIty6VpKrO3 CrNZO7NjiwAkdA5gsg23kC3bkhDapm2QACBbMAUuARY7ZAg9xAe4hCBPZwiToBuIZghVF7gwQAkk gqKyy6hZ2rWKCkKNq6Yr9gCoUA1oayrhkAjx0i0JkR4OgQoyJH9FUGhbYW49lHF70B/xNkReoFC7 EW9KFLhAEAeLSqi0qq6T/wSp6vOyzxGzjBqrubkdqOAd2xAe4/EuU7VKEGEGSoAEFfeuooAf5oYf eUS6bGBMfeARgPS/VxIFP0ADiLomcyInYLo7MYdF5ouwupq+eSJGuZINsHBG8VKKxrsokDC1aPAj YXgIk8B09qF0PhQbbEFECsUbdCBE81Z/4DRTkVTDYFfDXhdJUMHAyZabEZyt04GmAqAP3OAM6DR6 9FKKNiIjrzQJSuQF7noIqaF0ZoAf0isIbfB0dfBHUTsGVUe1cWAhASjGWkd5FkJ5lVTGl9QcPHy4 EnykbaMPYSQt1VAMKRS/VEUQepwKkMAGUIAGpQEkUixLsWFHsWEIgkdM7v+GGpzCFoTUAzuQMcsH gJCHGY1ESTGlwGrixkBsvqA0xypSDe30GVh1emxUI690CIDABTqQdwtRIJNgfoLQS0gyeD6CGpNg CFHiyAU8BF3SC11STdNUTZNczKnWfGwyw+eLqYgBAdeXIn6SDpfTCqWYKEgzd+uRI4AQIGfwI5RC JLIkvXuEBm8wKbyhy2tBwFfCBChQfBjjf8YXzJnxDhgzzIwkU883gDP1TTMbFQaQANrQJ4mVDbHQ s9wgkqrERnqsepBgBlLQBmggCJJAJHoAG/rxBvpEJICgy8T0bZ8CfKXCf85kfLuyJcQMeZecz064 z5dUgNJHDdZXDAtoMsX/8ArYQs1ptNAk+Qht9LFC+x97egZ90B+9BBZkoSm6vBpgsAWoOhzKtEwh TdJbMtLQ1HiLRMkD6Hws3U3SN8MwjQoyPUp9UtODQs0cPCOoF34YiCPk97SQIApiUCmXgkdm4H6r 4dHvoXiaoH/7l3/ujHxVvYjbhMw5y9IEOMZnXE7FoE4rsiLFMB7vVM3leCONcjQWiCOmkYG5Fq8e eH6AUBbuFyVMfSUxUNo3EAynoAl/8AedoAYJUwlFQLqZ8AZhYTV1CDqwIAvHYA3DgAxiNE1aTSxu 4nyS1yZnEoWLzYCj5CfNkFTlQYFgOU8QgYFPi8vLShY7JNSvNQh48AdV/yAEeNAIiQDXjYAHq/kC Q1AGoFA4tYAMB1AMuWAM5FBY8V1YybAJeBCE5TUKpiALofAHcRABagIV2oRNAXgs5sQsKRIt6lTH kO0i73LQBzFPqTCG8lEaCiUKVQMwnEmNpRMLhaMIqrBtn9GpYLUV7ygJ4SmZ5KWHruAKjjALtdAJ HRUKmxAJfuAHamAFg+gDPHADiEgJwyLY25QL3eEszqLg6JQMsGAt4yKK3eKuFx608rEvomCJovMT sHBKbLhC6rhC+PKG+9INouA57xgwiVAuTZCHtWiLaxUGDgMDMEA7HrACpaAx1QRNuZAskSiJkggt 7HSJ16JCYgiGcYgV2P/SVN5wLovuDdDwGTBCGk1zWqloVe/SVSgZh6pQllZTE3xAi26+Vg1jAz5g A7PTAiIgAiOAV85UAHrmiEh+jOi0C5Yznp9oLT2L6J2jVN3giU41ngz3IqRYKIcSd2GpjlzFQitU 4u2I4mDBCrDQBF5mi2mQBwzjBrtoAzmAjyagAirQAqueMQ5AjLIu68xISn2yC7EwOtL4CosOOtYS 79DACkR1LusFNEIDloYi4ehYkm647OUxNZwuCTLx6XdwB1NQCPXoMKWu7SlgAiBQAiWQAnFACaVQ Cg1wU8yCK46IK9Vw7iVjMifjKrswC9KQLuy1mJETOfWVDuNADwcgD/P/0A429VlyRzTgF34GcVVN w4puqIlZ8Y4rMRNexjXW/jVJAARjo49kg5MtQAkb8gA39Qsc/1dW/1cf71OusvVzw/WuopfqoF/q oJHtcA7vMKL3oA+sUMpyp/M0okapxDRBE+HKLoYLtRVWgzVbMwV2AAVuAASA/1Zmc5NkU9prUxcT 8AB75Qsb/1f1HVgcr/WkNNCLxVjukFmXhfmXLw+SlZHy8A2FMlo/l9AUuO9fDuYVseEEDwtaozBU IFtAkAQ5YAO3VZM4WfgjEG08KZSFZTK4Qg7BEN+Qn5fJoA3FH/baUFnKr/yadTPq4JRQiTPqEA7f 4FlXpdPfp0rpsTSW/66O+0KHV8OSr7UwduAwSUBbNiDx+1gCIPABFhBBoPQ2JnNYNE03cyMrwaUN 46A3wgkQ5ogRG0ZrWLNm5syJE5dQoUKG4haCk5gunUJwzLx1Q8DNYz1uIEF65JbAo0mPqFQiQNDK pShVrCQ1aVLpziA7asJY2cHDZwugIjbsW4drwIR9RgcIKNCqWDFfT4slo1o1mTZkxHTp0jqsoDVr tMLOmnZrVqxbt47NYmttFliy02JJk0V37jFp06aB+ybt1Spoqrq5RICKJDdUCFRBY8Vq1StZslzN AhUpUpk1a6745AE0qAgSHDZo8MdvwABc6yYsXTdgH9NWVpPxmk0bWb9WYrVo0ZrF+5Y1tWVjHYvl 6pbcWMldDXd1TK/e4nRljYJVfVV1YeWYMYMsi/ur74rAK5IV65ur8xTF0QpXi8GiAw6EUKBvBEIF Jy8gvHhRwb9/CyL4z78IAiTggVZo44WX25DZZaCBCqIlrVuSQ2uu5MqzcMPIRrHwrORAHMWUV16B xURYhBFmu+uuqw687eqKTBpXwLFGIofSGWecAw5wR558nJmnAXIeeAACJJF0wgn/7vvPAigpsYAS CR4ICAA7 --=_NextPart_000_0018_01C1A1B3.E2C7FE20-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 20 22:09: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 WAA18561 for ; Thu, 20 Jun 2002 22:09:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA04900 for nsis-archive@odin.ietf.org; Thu, 20 Jun 2002 22:10: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 VAA04077; Thu, 20 Jun 2002 21:55: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 VAA04045 for ; Thu, 20 Jun 2002 21:55:06 -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 VAA18373 for ; Thu, 20 Jun 2002 21:54:25 -0400 (EDT) From: Zhigang.Kan@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 g5L1uoW11220 for ; Fri, 21 Jun 2002 04:56:50 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Jun 2002 04:55:04 +0300 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 21 Jun 2002 04:55:03 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 21 Jun 2002 09:53:57 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [NSIS] New I-D on framework for QoS signaling Date: Fri, 21 Jun 2002 09:50:48 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD07E3BD@beebe001.NOE.Nokia.com> Thread-Topic: [NSIS] New I-D on framework for QoS signaling Thread-Index: AcIYZCnZSTuH9VenRra/T4Nn9KXingAX6Oug To: , X-OriginalArrivalTime: 21 Jun 2002 01:53:58.0021 (UTC) FILETIME=[81CEF350:01C218C6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id VAA04046 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, How about the scalability of your proposed QoS signaling? Must each hop store the state for per-flow traffic? BR/Kan Zhigang -----Original Message----- From: ext Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] Sent: 2002å¹´6月20æ—¥ 21:52 To: nsis@ietf.org Subject: [NSIS] New I-D on framework for QoS signaling The following draft is a framework document for QoS signaling for NSIS. We request that it be considered for working group document. <> Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 21 07:50: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 HAA08640 for ; Fri, 21 Jun 2002 07:50:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA06801 for nsis-archive@odin.ietf.org; Fri, 21 Jun 2002 07:50: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 HAA06313; Fri, 21 Jun 2002 07:37: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 HAA06277 for ; Fri, 21 Jun 2002 07:37:03 -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 HAA07917; Fri, 21 Jun 2002 07:36:19 -0400 (EDT) Message-Id: <200206211136.HAA07917@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, 21 Jun 2002 07:36:18 -0400 Subject: [NSIS] I-D ACTION:draft-shahrier-nsis-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 : A Framework for Bi-Directional QoS Signaling Author(s) : S. Shahrier, K. Shaheen Filename : draft-shahrier-nsis-framework-00.txt Pages : 5 Date : 20-Jun-02 This Internet Draft describes the end-to-end signaling architecture and framework model for transmitting packets through a series of heterogeneous networks. The Next-Steps-In-Signaling (NSIS) Working Group is already working on defining a set of requirements for the QoS signaling protocol [1]. This document is the follow on to the requirements draft, and the precursor to any solutions document. It outlines a framework for transporting end-to-end QoS parameters, initiated and maintained by the 'Originator' of the service. This draft elaborates on the requirements draft. It defines more precisely the scope of NSIS for end-to-end packet flows, in terms of QoS Signaling, where the resource reservations for the service are initiated by the ôOriginatorö end point and whether this service is bi- directional or unidirectional (i.e., receive-only or send-only). The draft is fully backward compatible; it requires no changes to the existing QoS signaling protocols or procedures. It applysapplies generic messages to transport the information needed to establish the desired QoS for traffic flows in either one or both directions. This document can be used as the guideline for a prospective solution to the QoS signaling problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shahrier-nsis-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-shahrier-nsis-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-shahrier-nsis-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: <20020620141523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shahrier-nsis-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shahrier-nsis-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020620141523.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Jun 21 16:23: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 QAA00373 for ; Fri, 21 Jun 2002 16:23:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07164 for nsis-archive@odin.ietf.org; Fri, 21 Jun 2002 16:24: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 QAA06689; Fri, 21 Jun 2002 16:09: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 QAA06658 for ; Fri, 21 Jun 2002 16:09:23 -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 QAA29978 for ; Fri, 21 Jun 2002 16:08:42 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 16:07:43 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'Zhigang.Kan@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] New I-D on framework for QoS signaling Date: Fri, 21 Jun 2002 16:07:41 -0400 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 QAA06659 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 The protocol can be made scalable by combining a group of flows into a single "aggregate flow" class, where all the flows in the aggregate set have the same QoS treatment. In this manner, the need to store state at each hop for every single flow is eliminated => better scalability. Another thing that can be done is not to replacate storing those QoS parameters that are common to some of the flows. Thus, it needs to be stored only once at each hop. This will also improve scalability. Sharif. -----Original Message----- From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] Sent: Thursday, June 20, 2002 9:51 PM To: Sharif.Shahrier@interdigital.com; nsis@ietf.org Subject: RE: [NSIS] New I-D on framework for QoS signaling Hi, How about the scalability of your proposed QoS signaling? Must each hop store the state for per-flow traffic? BR/Kan Zhigang -----Original Message----- From: ext Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] Sent: 2002å¹´6月20æ—¥ 21:52 To: nsis@ietf.org Subject: [NSIS] New I-D on framework for QoS signaling The following draft is a framework document for QoS signaling for NSIS. We request that it be considered for working group document. <> Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Jun 21 19:24: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 TAA03995 for ; Fri, 21 Jun 2002 19:24:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA14172 for nsis-archive@odin.ietf.org; Fri, 21 Jun 2002 19:24: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 TAA13917; Fri, 21 Jun 2002 19:10: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 TAA13886 for ; Fri, 21 Jun 2002 19:10:50 -0400 (EDT) Received: from google.com ([217.6.98.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03651 for ; Fri, 21 Jun 2002 19:10:05 -0400 (EDT) Message-Id: <200206212310.TAA03651@ietf.org> From: "Farmgirl19067" To: X-Priority: 3 X-Mailer: The Bat! (v1.53d) Date: Sat, 22 Jun 2002 03:13:56 +0400 Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-2" Status: R X-Status: N X-Set: qvlvClhwi1ruj@26161 Subject: [NSIS] Real ZOO web site, welcome! ID 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 The BEST zoo site on the @net!
Sex With Dogs
Horse Blow Jobs.
Snake Fuck.
REAL ANIMAL FUCKING!
100% HARDCORE!
ww1.only-beasts.com
unsub
Good luck, .

_______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sat Jun 22 04:07: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 EAA21684 for ; Sat, 22 Jun 2002 04:07:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08203 for nsis-archive@odin.ietf.org; Sat, 22 Jun 2002 04:08: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 DAA07578; Sat, 22 Jun 2002 03:54: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 DAA07547 for ; Sat, 22 Jun 2002 03:54:17 -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 DAA21422 for ; Sat, 22 Jun 2002 03:53:35 -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 g5M7u2W04750 for ; Sat, 22 Jun 2002 10:56:02 +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 ; Sat, 22 Jun 2002 10:54:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 22 Jun 2002 10:54:15 +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: Sat, 22 Jun 2002 10:54:15 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01130375@esebe004.NOE.Nokia.com> Thread-Topic: IETF 54 Thread-Index: AcIZi3jF8BcHEF3RTS6mHLyNDP0PUg== To: X-OriginalArrivalTime: 22 Jun 2002 07:54:16.0065 (UTC) FILETIME=[01946F10:01C219C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA07548 Subject: [NSIS] IETF 54 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, IETF 54 is coming up, if anyone has some draft they wish to discuss, please send a request to me, with the draft name, the person who will be making the 'discussion' & how much time is needed. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Sat Jun 22 13:48: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 NAA01267 for ; Sat, 22 Jun 2002 13:48:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27433 for nsis-archive@odin.ietf.org; Sat, 22 Jun 2002 13:48: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 NAA27126; Sat, 22 Jun 2002 13:34: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 NAA27095 for ; Sat, 22 Jun 2002 13:34:20 -0400 (EDT) Received: from localhost.com ([61.174.192.218]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00841 for ; Sat, 22 Jun 2002 13:33:36 -0400 (EDT) From: targetemailextractor@btamail.net.cn Message-Id: <200206221733.NAA00841@ietf.org> Reply-To: targetemailextractor@btamail.net.cn To: nsis@ietf.org Date: Sun, 23 Jun 2002 01:34:13 +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: Direct email blaster, email addresses extractor, maillist verify, maillist manager........... 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 =3CSTYLE=3E=3C=2FSTYLE=3E =3C=2FHEAD=3E =3CBODY bgColor=3D#ffffff=3E =3CDIV=3E=3CFONT size=3D2=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E =3CDIV=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial size=3D4=3EDirect Email Blaster=3C=2FFONT=3E=3C=2FSTRONG=3E =3C=2FDIV=3E=3CFONT size=3D2=3E =3CP=3E=3CFONT face=3DArial=3E=3CB=3E=3CFONT color=3D#006600=3E=3CI=3EThe program will send mail at the rate of over 1=2C 000 e-mails per minute=2E =3B=3C=2FI=3E=3C=2FFONT=3E=3CBR=3ELegal and Fast sending bulk emails =3B=3CBR=3E=3CFONT color=3D#006600=3E=3CI=3EBuilt in SMTP server =3B=3C=2FI=3E=3C=2FFONT=3E=3CBR=3EHave Return Path =3B=3CBR=3ECan Check Mail Address =3B=3CBR=3E=3CFONT color=3D#006600=3E=3CI=3EMake Error Send Address List=28 Remove or Send Again=29 =3B=3C=2FI=3E=3C=2FFONT=3E=3CBR=3ESupport multi-threads=2E =3B=3CBR=3ESupport multi-smtp servers=2E =3B=3CBR=3EManages your opt-in E-Mail Lists =3B=3CBR=3EOffers an easy-to-use interface! =3B=3CBR=3EEasy to configure and use =3B=3C=2FB=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Fedeb=5Fset=2Ezip=22=3E=3CSTRONG=3EDownload Now=3C=2FSTRONG=3E=3C=2FA=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial size=3D4=3EMaillist Verify=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3EMaillist Verify is intended for e-mail addresses and mail lists verifying=2E The main task is to determine which of addresses in the mail list are dead=2E The program is oriented=2C basically=2C on programmers which have their own mail lists to inform their users about new versions of their programs=2E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3EThe program works on the same algorithm as ISP mail systems do=2E Mail servers addresses for specified address are extracted from DNS=2E The program tries to connect with found SMTP-servers and simulates the sending of message=2E It does not come to the message =3CNOBR=3Esending ‿=3B=2FNOBR>=3B EMV disconnect as soon as mail server informs does this address exist or not=2E EMV can find=3C=2FNOBR=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CNOBR=3E =3Babout 90% of dead addresses ‿=3B=2FNOBR>=3B some mail systems receive all messages and only then see their =3B=3C=2FNOBR=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CNOBR=3Eaddresses and if the address is dead send the message back with remark about it=2E=3C=2FNOBR=3E=3C=2FFONT=3E=3C=2FP=3E=3CNOBR=3E =3CP=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Fbemv=5Fset=2Ezip=22=3E=3CSTRONG=3E=3CFONT face=3DArial size=3D3=3EDownload Now=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FA=3E=3C=2FP=3E =3CP=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial size=3D4=3EExpress Email Blaster =3B=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3EExpress Email Blaster =3B is a very fast=2C powerful yet simple to use email sender=2E Utilizing multiple threads=2Fconnections=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E =3Band multiple SMTP servers your emails will be sent out fast and easily=2E There are User Information=2C Attach Files=2C =3B=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3EAddress and Mail Logs four tabbed area for the E-mails details for sending=2E About 25 SMTP servers come with the =3B=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3Edemo version=2C and users may Add and Delete SMTP servers=2E About =3CFONT color=3D#008000=3E=3CB=3E60=2C000=3C=2FB=3E=3C=2FFONT=3E E-mails will be sent out per hour=2E=22=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CSTRONG=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Fbeeb=5Fset=2Ezip=22=3E=3CFONT face=3DArial size=3D3=3EDownload Now=3C=2FFONT=3E=3C=2FA=3E=3C=2FSTRONG=3E=3C=2FP=3E =3CP=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial size=3D4=3EExpress Email Address Extractor=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FP=3E=3CFONT size=3D4=3E =3CP=3E=3CFONT color=3D#008000 size=3D3=3EThis program is the most efficient=2C easy to use email address collector available on the =3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CFONT color=3D#008000 size=3D3=3E =3Binternet! =3C=2FFONT=3E=3CFONT color=3D#000000 size=3D3=3EBeijing Express Email Address Extractor =28ExpressEAE=29 is designed to extract=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT color=3D#000000 size=3D3=3E =3Be-mail addresses from web-pages on the Internet =28using HTTP protocols=29 =2EExpressEAE=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT color=3D#000000 size=3D3=3E =3Bsupports operation through many proxy-server and works very fast=2C as it is able of =3B=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT color=3D#000000 size=3D3=3Eloading several pages simultaneously=2C and requires very few resources=2E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT color=3D#000000 face=3DArial=3E=3CFONT size=3D3=3EWith it=2C you will be able to=3C=2FFONT=3E=3CFONT size=3D2=3E =3C=2FFONT=3E=3CFONT size=3D3=3Euse targeted searches to crawl the world wide web=2C extracting =3B=3C=2FFONT=3E=3C=2FFONT=3E =3CP=3E=3CFONT color=3D#000000 face=3DArial size=3D3=3Ethousands of clean=2C fresh email addresses=2E Ably Email address Extractor is unlike other =3B=3C=2FFONT=3E =3CP=3E=3CFONT color=3D#000000 face=3DArial size=3D3=3Eaddress collecting programs=2C which limit you to one or two search engines and are unable=3C=2FFONT=3E =3CP=3E=3CFONT color=3D#000000 face=3DArial size=3D3=3E =3Bto do auto searches HUGE address=2E Most of them collect a high percentage of incomplete=2C =3B=3C=2FFONT=3E =3CP=3E=3CFONT color=3D#000000 face=3DArial size=3D3=3Eunusable addresses which will cause you serious problems when using them in a mailing=2E =3B=3C=2FFONT=3E =3CUL=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EEasier to learn and use than any other email address collector program available=2E=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EAccesses eight search engines =3B=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EAdd your own URLs to the list to be searched=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial size=3D3=3E=3CFONT color=3D#008000=3ESupports operation through =3C=2FFONT=3E=3CFONT color=3D#ff00ff=3Ea lot of=3C=2FFONT=3E=3CFONT color=3D#008000=3E proxy-server and works very fast =28HTTP Proxy=29=3C=2FFONT=3E=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EAble of loading several pages simultaneously=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3ERequires very few resources=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3ETimeout feature allows user to limit the amount of time crawling in dead sites and traps=2E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial size=3D3=3E=3CFONT color=3D#008000=3EEasy to make =3C=2FFONT=3E=3CFONT color=3D#ff00ff=3EHuge=3C=2FFONT=3E=3CFONT color=3D#008000=3E address list=3C=2FFONT=3E=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EPause=2Fcontinue extraction at any time=2E=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EAuto connection to the Internet=3C=2FFONT=3E =3C=2FLI=3E=3C=2FUL=3E =3CDIV=3E=3CSTRONG=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Feeae=5Fset=2Ezip=22=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EDownload Now=3C=2FFONT=3E=3C=2FA=3E=3C=2FSTRONG=3E =3C=2FDIV=3E =3CDIV=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial=3EExpress Email Address Downloader=3C=2FFONT=3E=3C=2FSTRONG=3E =3C=2FDIV=3E =3CUL=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#006600 size=3D2=3EExpressEAD =3B =3C=2FFONT=3E=3CFONT color=3D#000000 size=3D2=3Eis a 32 bit Windows Program for e-mail marketing=2E It is intended for easy and convenient=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#000000 size=3D2=3E =3Bsearch large e-mail address lists from mail servers=2E The program can be operated on =3B=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#000000 size=3D2=3EWindows 95=2F98=2FME=2F2000 and NT=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#006600 size=3D2=3EExpressEAD =3B =3C=2FFONT=3E=3CFONT color=3D#000000 size=3D2=3Esupport multi-threads =28up to 1024 connections=29=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#006600 size=3D2=3EExpressEAD =3B =3C=2FFONT=3E=3CFONT color=3D#000000 size=3D2=3Ehas the ability =3B to reconnect to the mail server if the server has disconnected and =3B=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#000000 size=3D2=3Econtinue the searching at the point where it has been interrupted=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#006600 size=3D2=3EExpressEAD =3B =3C=2FFONT=3E=3CFONT color=3D#000000 size=3D2=3Ehas an ergonomic interface that is easy to set up and simple to use=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3C=2FLI=3E=3C=2FUL=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CP=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#008000 face=3DArial size=3D4=3EFeatures=3A=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CUL type=3Ddisc=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT face=3DArial size=3D2=3Esupport multi-threads=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT face=3DArial size=3D2=3Eauto get smtp server address=2Csupport multi-smtp servers=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT face=3DArial size=3D2=3Eauto save =3B E-Mail Lists=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT face=3DArial size=3D2=3Eoffers an easy-to-use interface!=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3C=2FLI=3E=3C=2FUL=3E =3CDIV=3E=3CSTRONG=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Feead=5Fset=2Ezip=22=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EDownload Now=3C=2FFONT=3E=3C=2FA=3E=3C=2FSTRONG=3E =3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial=3EExpress Maillist Manager=3C=2FFONT=3E=3C=2FSTRONG=3E =3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E=3CFONT size=3D2=3E =3CP=3E=3CFONT face=3DArial=3E=3CFONT color=3Dblack size=3D3=3EThis program was designed to be a complement to the =3C=2FFONT=3E=3CFONT color=3D#800080 size=3D3=3EDirect Email Blaster =3B =3C=2FFONT=3E=3CFONT color=3Dblack size=3D3=3Eand =3C=2FFONT=3E=3CFONT color=3D#800080 size=3D3=3EEmail Blaster =3C=2FFONT=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CFONT color=3Dblack size=3D3=3Esuite of bulk email software programs=2E Its purpose is to organize your email lists in order to be more =3B=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CFONT color=3Dblack size=3D3=3Eeffective with your email marketing campaign=2E Some of its features include=3A=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#008000 face=3DArial=3E=3CFONT size=3D3=3E‿=3BCombine several lists into one file=2E=3C=2FFONT=3E=3CBR=3E=3CFONT size=3D3=3E‿=3BSplit up larger lists to make them more manageable=2E=3C=2FFONT=3E=3CBR=3E=3CFONT size=3D3=3E‿=3BRemove addresses from file=2E=3C=2FFONT=3E=3CBR=3E=3CFONT size=3D3=3E‿=3BManual editing=2C adding=2C and deleting of addresses=2E=3C=2FFONT=3E=3CBR=3E=3CFONT size=3D3=3E‿=3BAbility to auto clean lists=2C that is=2C remove any duplicate or unwanted addresses=2E=3C=2FFONT=3E=3CBR=3E=3CFONT size=3D3=3E‿=3BMaintain all your address lists within the program so you no =3B longer need to keep all your=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3E =3Blists saved as separate text files=2E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CSTRONG=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Fbemm=5Fset=2Ezip=22=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EDownload Now=3C=2FFONT=3E=3C=2FA=3E=3C=2FSTRONG=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E=3C=2FP=3E =3CP=3E =3B=3C=2FP=3E =3CDIV=3E=3CFONT face=3DArial=3Eif you want to remove your email=2C please send email to =3CA href=3D=22mailto=3Atargetemailremoval=40btamail=2Enet=2Ecn=22=3Etargetemailremoval=40btamail=2Enet=2Ecn=3C=2FA=3E=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E=3C=2FFONT=3E=3C=2FDIV=3E=3C=2FFONT=3E=3C=2FNOBR=3E=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FDIV=3E=3C=2FBODY=3E=3C=2FHTML=3E _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Sun Jun 23 23:46: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 XAA11319 for ; Sun, 23 Jun 2002 23:46:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA07496 for nsis-archive@odin.ietf.org; Sun, 23 Jun 2002 23:46: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 XAA07000; Sun, 23 Jun 2002 23:31: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 XAA06969 for ; Sun, 23 Jun 2002 23:31:20 -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 XAA10800 for ; Sun, 23 Jun 2002 23:30:37 -0400 (EDT) Received: from Freedom.icr.a-star.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.12.1/8.12.1) with ESMTP id g5O3WUBL010173; Mon, 24 Jun 2002 11:32:30 +0800 (SGT) Message-Id: <5.1.0.14.2.20020624112950.02ac2288@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Jun 2002 11:30:09 +0800 To: "Shahrier, Sharif M." , "'Zhigang.Kan@nokia.com'" , nsis@ietf.org From: "Charles Q. Shen" Subject: RE: [NSIS] New I-D on framework for QoS signaling In-Reply-To: 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 XAA06970 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 Sharif So is this aggregate flow sent to a single receiver or multiple receivers? Is there any other major difference of the proposal from original RSVP except that routers may need to do two-way reservation based on messages passed through? Thx./Charles At 16:07 2002-6-21 -0400, Shahrier, Sharif M. wrote: >The protocol can be made scalable by combining a group of flows into a >single "aggregate flow" class, where all the flows in the aggregate set >have the same QoS treatment. In this manner, the need to store state at each >hop for every single flow is eliminated => better scalability. > >Another thing that can be done is not to replacate storing those QoS >parameters that are common to some of the flows. Thus, it needs to be stored >only once at each hop. This will also improve scalability. > >Sharif. > >-----Original Message----- >From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] >Sent: Thursday, June 20, 2002 9:51 PM >To: Sharif.Shahrier@interdigital.com; nsis@ietf.org >Subject: RE: [NSIS] New I-D on framework for QoS signaling > >Hi, > >How about the scalability of your proposed QoS signaling? Must each hop >store the state for per-flow traffic? > >BR/Kan Zhigang > >-----Original Message----- >From: ext Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] >Sent: 2002å¹´6月20æ—¥ 21:52 >To: nsis@ietf.org >Subject: [NSIS] New I-D on framework for QoS signaling > > >The following draft is a framework document for QoS signaling for NSIS. We >request that it be considered for working group document. > > <> > >Sharif. > >_______________________________________________ >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 Jun 24 01: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 BAA13260 for ; Mon, 24 Jun 2002 01:06:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA15001 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 01:07: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 AAA11071; Mon, 24 Jun 2002 00: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 AAA11042 for ; Mon, 24 Jun 2002 00:49:26 -0400 (EDT) Received: from ab17c958.com ([216.139.169.28]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12595 for ; Mon, 24 Jun 2002 00:48:24 -0400 (EDT) Message-Id: <200206240448.AAA12595@ietf.org> From: "MR.FRED MOMO" Reply-To: fredmomo914@hotmail.com To: nsis@ietf.org Date: Mon, 24 Jun 2002 05:42:44 +0200 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [NSIS] important 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 FROM=2E FRED=2EMOMO=2E BARRISTER AND SOLICITOR NO 24 CANAL STREET IKOYI LAGOS NIGERIA =2E MY DEAR BEFORE I START=2C I MUST FIRST APOLOGIZE FOR THIS UNSOLICITED MAIL TO YOU=2E I AM AWARE THAT THIS IS CERTAINLY AN UNCONVENTIONAL APPROACH TO STARTING A RELATIONSHIP=2C BUT AS TIME GOES ON YOU WILL REALIZE THE NEED FOR MY ACTION=2E MY NAME IS FRED MOMO=2C A SOLICITOR AND THE PERSONAL ATTORNEY TO MR=2E JOHN RYERSON=2C A CITIZEN OF AUSTRALIA=2C WHO WORKED WITH AN OIL COMPANY IN NIGERIA=2E HERE-IN-AFTER REFERRED TO AS MY CLIENT=2E ON THE 21ST OF APRIL 1999=2C MY CLIENT=2C HIS WIFE AND THEIR THREE CHILDREN WERE INVOLVED IN A GHASTLY MOTOR ACCIDENT ALONG SAGAMU EXPRESS ROAD=2E MY CLIENT AND HIS ENTIRE FAMILY UNFORTUNATELY LOST THEIR LIVES IN THE ACCIDENT=2E SINCE THEN I HAVE MADE SEVERAL ENQUIRIES TO THEIR EMBASSY TO LOCATE ANY OF MY CLIENT=92S EXTENDED RELATIVES=2C WHICH HAS PROVED ABORTIVE AFTER THESE SEVERAL UNSUCESSFUL ATTEMPTS=2C THE NEED TO CONTACT YOU=2E MY MAIN REASON FOR CONT! ACTING YOU IS TO ASSIST ME IN REPATRIATING THE MONEY AND PROPERTY LEFT BEHIND BY MY CLIENT BEFORE THEY ARE CONFISCATED OR DECLARED UNSERVICEABLE BY THE BANK WHERE THEY ARE DEPOSITED=2FLODGED=2E PARTICULARLY=2C THE UNION BANK PLC=2E WHERE THE DECEASED HAS A FIXED SUM OF SEVEN MILLION UNITED STATES DOLLARS=2E THE SAID BANK HAS ISSUED ME A FINAL NOTICE TO PROVIDE THE NEXT OF KIN OF MY CLIENT OR THEY WILL BE LEFT WITH NO OTHER CHOICE THAN TO CONFISCATE HIS FUNDS=2C A COPY OF THE SAID NOTICE I WILL FAX TO YOU ON GETTING YOUR REPLY=2E SINCE I HAVE BEEN UNSUCCESSFUL IN LOCATING MY CLIENT=92S RELATIVES FOR THE PAST 2 YEARS NOW I SEEK YOUR CONSENT TO PRESENT YOU AS THE NEXT OF KIN OF MY CLIENT =2C SO THAT THE SAID FUNDS AS STATED ABOVE THAT IS THE SUM OF SEVEN MILLION UNITED STATES DOLLARS CAN BE PAID TO YOU INSTEAD OF LEAVING FOR UNION BANK PLC=2E WE CAN TAKE PART OF IT AND LEAVE THE REST TO CHARITY=2E I HAVE ALL NECESSARY LEGAL DOCUMENTS THAT CAN BE USED TO BACK UP ANY CLAIM WE MA! Y MAKE ALL I REQUIRE IS YOUR HONEST COOPERATION TO ENABLE US SEE THIS ARRANGEMENT THROUGH=2E I GUARANTEE THAT THIS WILL BE EXECUTED UNDER A LEGITIMATE ARRANGEMENT THAT WILL PROTECT YOU FROM ANY BREACH OF THE LAW=2E PLEASE REPLY ME VIA THIS E-MAIL ADDRESS=3Afredmomo914=40hotmail=2Ecom=2C FINALLY KINDLY GIVE ME YOUR CONFIDENTAIL PHONE=2FFAX NUMBERS SO THAT I CAN FAX TO YOU ALL THE CORRESPONDENCE BETWEEN THE BANK AND ME=2E BEST REGARDS=2C FRED MOMO ESQ=2E _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Jun 24 04:40: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 EAA26083 for ; Mon, 24 Jun 2002 04:40:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA00203 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 04:41: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 EAA28442; Mon, 24 Jun 2002 04:27: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 EAA28406 for ; Mon, 24 Jun 2002 04:27:06 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25684 for ; Mon, 24 Jun 2002 04:26:21 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g5O8R4h06614 for ; Mon, 24 Jun 2002 10:27:04 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id g5O8R4B20065 for ; Mon, 24 Jun 2002 10:27:04 +0200 (MEST) From: "Hannes Tschofenig" To: Date: Mon, 24 Jun 2002 10:31:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [NSIS] RSVP Security Properties 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 Content-Transfer-Encoding: 7bit Dear all, I have submitted a draft about RSVP Security Properties. The draft contains a detailed description of RSVP security issues. You will also find a copy of the draft at following URL: http://www.ersue.de/nsis/draft-tschofenig-rsvp-sec-properties-00.txt Your comments are welcome! Ciao Hannes ======================================================================= Abstract As the work of the NSIS working group has begun there are also concerns about security and its implication for the design of a signaling protocol. In order to understand the security properties and available options of RSVP a number of documents have to be read. This document tries to summarize the security properties of RSVP and to view them from a different point of view. This work in NSIS is part of the overall process of analyzing other protocols and to learn from their design considerations. This document should also provide a starting point for further discussions. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Jun 24 04:47: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 EAA26211 for ; Mon, 24 Jun 2002 04:47:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA00456 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 04:47: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 EAA29766; Mon, 24 Jun 2002 04:34: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 EAA29729 for ; Mon, 24 Jun 2002 04:34:07 -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 EAA25874 for ; Mon, 24 Jun 2002 04:33:22 -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) for id 17MPHz-0001XA-00; Mon, 24 Jun 2002 10:33: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 g5O8XZt03629 for ; Mon, 24 Jun 2002 10:33:35 +0200 Message-ID: <3D16D95F.D568C7DA@ee.tu-berlin.de> Date: Mon, 24 Jun 2002 10:33: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: NSIS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] New Draft: draft-fu-rsvp-multicast-analysis-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: 7bit Hi all, We have made an analysis on RSVP regarding multicast and submitted a new draft to the internet drafts with the following abstract: RSVP version 1 has been designed for optimally support multicast. However, in reality multicast is being used much less frequently than anticipated. Still, even for unicast (one sender, one receiver) communication, full-fledged multicast-enabled RSVP signaling must be used. As pointed out in the NSIS requirement draft, multicast would not be necessarily required for an NSIS signaling protocol. This draft analyses ingredients of RSVP Version 1 which are affected by multicast, and derives how these ingredients may look like if multicast is not supported. We find removing multicast capability from RSVP will make it and its extensions considerably more light- weight. You can also download it from http://www-tkn.ee.tu-berlin.de/~fu/nsis/draft-fu-rsvp-multicast-analysis-00.txt All comments are appreciated very much! Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jun 24 08:08: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 IAA02171 for ; Mon, 24 Jun 2002 08:08:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA11206 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 08:09: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 HAA09242; Mon, 24 Jun 2002 07:46: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 HAA09208 for ; Mon, 24 Jun 2002 07:46:37 -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 HAA29866 for ; Mon, 24 Jun 2002 07:45:53 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 12:46:35 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3B7@rsys002a.roke.co.uk> From: "Hancock, Robert" To: NSIS Date: Mon, 24 Jun 2002 12:46:34 +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] New 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" Hi all, A group of us who were involved in past NSIS framework activities got together after the interim meeting to put together a joint framework document in the form of an all-new individual submission. It (roughly) follows the structure that was introduced and refined at that meeting. ========================================================================== Abstract The NSIS working group is considering protocol developments in signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in a separate document; This Internet Draft proposes a framework for such signaling. This initial version provides a model for describing the entities that take part in the signaling and the ways in which they can be used in different modes of operation. It also discusses the overall structure of such a signaling protocol. Finally, it considers the possible interactions of NSIS signaling with other protocols and functions, including security issues. ========================================================================== While it works its way through the i-d editor queue, you can find a copy here: http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt Comments are welcome. There is a list of open issue highlights in section 3. Cheers, Robert Hancock --------------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 Mon Jun 24 08:12: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 IAA02413 for ; Mon, 24 Jun 2002 08:12:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA11448 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 08:13: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 HAA09874; Mon, 24 Jun 2002 07:52: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 HAA09845 for ; Mon, 24 Jun 2002 07:52: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 HAA01152 for ; Mon, 24 Jun 2002 07:51:56 -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 g5OBr6i07110 for ; Mon, 24 Jun 2002 14:53:07 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Jun 2002 14:52:37 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 24 Jun 2002 14:52: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] New framework draft Date: Mon, 24 Jun 2002 14:52:36 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC654F2@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft Thread-Index: AcIbdTo3hQ/LfywqSYWOMxuH+E09LgAADQgQ To: , X-OriginalArrivalTime: 24 Jun 2002 11:52:37.0628 (UTC) FILETIME=[A2CD43C0:01C21B75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA09846 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, > A group of us who were involved in past NSIS framework > activities got together after the interim meeting to put > together a joint framework document in the form of an all-new > individual submission. It (roughly) follows the structure > that was introduced and refined at that meeting. Just as an FYI, I am listed as a co-author. I've tried to add a certain perspective on this work. However, I have done this purely as an individual, not as a WG chair. Therefor, this draft should be considered as the work of individuals & nothing more. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jun 24 09:48: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 JAA06853 for ; Mon, 24 Jun 2002 09:48:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16952 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 09:48: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 JAA16287; Mon, 24 Jun 2002 09:33: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 JAA16257 for ; Mon, 24 Jun 2002 09:33:15 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06246 for ; Mon, 24 Jun 2002 09:32:31 -0400 (EDT) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g5ODWhe21399 for ; Mon, 24 Jun 2002 19:02:43 +0530 (IST) Received: from wipro.com ([192.168.220.108]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GY7PME00.E9S; Mon, 24 Jun 2002 19:02:38 +0530 Message-ID: <3D171FB5.A29BF33D@wipro.com> Date: Mon, 24 Jun 2002 19:03:41 +0530 From: "rana pratap sircar" Organization: Wipro Technologies X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shahrier Sharif M." CC: nsis@ietf.org Subject: Re: [NSIS] New I-D on framework for QoS signaling References: Content-Type: multipart/mixed; boundary="------------E8BDA18A5D5FAB6480D7EBA0" 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. --------------E8BDA18A5D5FAB6480D7EBA0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Sharif, I am a novice in the NSIS concept. Thus, I have a few queries :- 1. Could you give an example / scenario of an applications in which the “Originator” of a service is solely responsible for making the necessary reservations, authentication and their cost. How will the cost of such a service be decided? 2. I could not understand how the connection Setup will take place in a heterogeneous IP network (where there are multiple service providers with complex SLA's) Best regards, Rana "Shahrier, Sharif M." wrote: > The following draft is a framework document for QoS signaling for NSIS. We > request that it be considered for working group document. > > <> > > Sharif. > > ------------------------------------------------------------------------ > Name: draft-shahrier-nsis-fwk-00.txt > draft-shahrier-nsis-fwk-00.txt Type: Plain Text (text/plain) > Encoding: quoted-printable --------------E8BDA18A5D5FAB6480D7EBA0 Content-Type: text/x-vcard; charset=us-ascii; name="rana.sircar.vcf" Content-Description: Card for Rana Pratap Sircar Content-Disposition: attachment; filename="rana.sircar.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sircar;Rana Pratap tel;fax:+91-80-5732696 / 5732441 tel;home:+91-80-5278075 tel;work:+91-80-5732293 extn. 1040/ VoIP- 8034038 x-mozilla-html:FALSE url:http://www.wipro.com/ org:Wipro Technologies;Telecom & Inter-Networking Solutions version:2.1 email;internet:rana.sircar@wipro.com title:Architect - Product Realisation adr;quoted-printable:;;26, Chamundi Complex, =0D=0AHosur main Road, =0D=0ABommanahalli;Bangalore;Karnataka;560 068;India fn:Rana Pratap Sircar end:vcard --------------E8BDA18A5D5FAB6480D7EBA0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jun 24 14:04: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 OAA21553 for ; Mon, 24 Jun 2002 14:04:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01363 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 14:04: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 NAA00181; Mon, 24 Jun 2002 13:48: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 NAA00151 for ; Mon, 24 Jun 2002 13:47:58 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20628 for ; Mon, 24 Jun 2002 13:47:14 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA25689 for ; Mon, 24 Jun 2002 10:47:21 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5OHlKu29972; Mon, 24 Jun 2002 10:47:20 -0700 X-mProtect: <200206241747> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.19.79.91, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpYmSTr; Mon, 24 Jun 2002 10:47:19 PDT Message-ID: <3D175B26.8020605@iprg.nokia.com> Date: Mon, 24 Jun 2002 10:47:18 -0700 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: nsis@ietf.org CC: hemant.chaskar@nokia.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] QoS framework. 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, we put together a document representing our perspective on a NSIS qos signaling framework. Here is the abstract: Abstract This draft provides a framework for QoS signaling that is optimized for Mobile IP handoffs. It covers the horizontal signaling between access routers (ARs) as well as the vertical signaling along the packet data path, both of which are triggered by handoff of mobile node (MN). The key design goals are wireless bandwidth economy, fast QoS establishment along the new data path after handoff and secure protocol operation. The document will eventually be available from the i-d editor queue. However, only after Yokohama meeting. You can find it at: http://people.nokia.net/~cedric/Papers/draft-westphal-nsis-qos-mobileip-00.txt in the meantime. Please send your comments, Cedric & Hemant. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jun 24 15:36: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 PAA26571 for ; Mon, 24 Jun 2002 15:36:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06353 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 15:37: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 PAA05353; Mon, 24 Jun 2002 15:23: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 PAA05324 for ; Mon, 24 Jun 2002 15:23: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 PAA26084 for ; Mon, 24 Jun 2002 15:22:46 -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 g5OJMxK83928 for ; Mon, 24 Jun 2002 21:22: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 VAA19306 for ; Mon, 24 Jun 2002 21:18:01 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E3A234CF5F for ; Mon, 24 Jun 2002 21:18:00 +0200 (CEST) Date: Mon, 24 Jun 2002 21:18:01 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <24265552.1024953481@[192.168.102.207]> 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] draft on middlebox communication and 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: 7bit I interpreted the cut-off time wrong (9:00) though to be in the evening) Nevertheless, those of you interested in middlebox communication, here is a short text on middlebox communication in the NSIS framework. http://www.brubers.org/marcus/papers/draft-brunner-nsis-mbox-fmwk-00.txt 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 Mon Jun 24 16:16: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 QAA28076 for ; Mon, 24 Jun 2002 16:16:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08552 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 16:16: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 PAA07367; Mon, 24 Jun 2002 15: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 PAA07326 for ; Mon, 24 Jun 2002 15:59:15 -0400 (EDT) Received: from legend-mfy8zk0p ([61.144.241.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27339 for ; Mon, 24 Jun 2002 15:58:28 -0400 (EDT) From: zhulinxi@yahoo.com.cn Message-Id: <200206241958.PAA27339@ietf.org> To: nsis@ietf.org Date: Tue, 25 Jun 2002 04:01:59 +0800 X-Priority: 3 X-Mailer: CSM 3.2 Subject: [NSIS] =?GB2312?B?1+6/7MvZ1+7KtdPD1+6+rbzDsai+r834?= 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 ¡°ÉñÓ¥---995¡±¸Ã²úÆ·×î´óÌصãÊǽ«ºìÍâ̽ͷ¼ì²âµÄÐźÅͨ¹ýBP»ú·¢ÉäÍ·Ö±½Ó·¢³öÈ¥£¨ÎÞÏßPOCSAGÂë¡¢´«Êä¾àÀëÔ¶ ¡¢ËÙÂʿ죩£¬Ò»Ì廯½ô´Õ½á¹¹£¬ÞðÆúµç»°²¦ºÅ¡¢ÓÐÏß±¨¾¯µÄÖî¶àȱÏÝ£¬Ò»²½£¨·¢Éä1£®5¹«À½«ÐźŴ«µ½Öµ°àÔ±µÄ רÅäBP»úÉÏ£¬´Ó¶øÀ­¿ªÐ¡Çø×î¿ìËÙ¡¢×î¾­¼Ã¡¢×îʵÓõı¨¾¯½¨ÍøάĻ£¬×öµ½´å´å¿ÉÓᢼҼҿÉÉÏ¡£Ã¿¸öºìÍâÏß̽ͷ ÄÚ×°ÓÐÒ»¸ö¶ÀÌصÄBP»ú·¢Éä»ú£¬ÖÐÐÄÒ²²»Òª½Ó¾¯»ú¡¢µçÄÔ£¬È¡¶ø´úÖ®ÊÇÒ»¸öרÅäµÄСÇÉBP»ú£¬ÕâÁ½¸öÍêÃÀµÄ¡°¶à·¢ Ò»ÊÕ¡±½áºÏ£¬Ê¹Ð¡Çø±¨¾¯Íø±äµÃ¼ò½Ý¡¢¿É¿¿¡¢Á®¼Û£¬ÒÔСÇøΪµ¥Î»£¬½øÐÐÈ«·½Ã渲¸Ç¡£ E-mail:zhujindong@163.com http://www.110alarm.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jun 24 16:44: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 QAA29419 for ; Mon, 24 Jun 2002 16:44:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10912 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 16:44: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 QAA09328; Mon, 24 Jun 2002 16:28: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 QAA09285 for ; Mon, 24 Jun 2002 16:28:45 -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 QAA28574 for ; Mon, 24 Jun 2002 16:27:59 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 16:27:02 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'rana pratap sircar'" , "Shahrier, Sharif M." Cc: nsis@ietf.org Subject: RE: [NSIS] New I-D on framework for QoS signaling Date: Mon, 24 Jun 2002 16:27:01 -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 1. Could you give an example / scenario of an applications in which the "Originator" of a service is solely responsible for making the necessary reservations, authentication and their cost. How will the cost of such a service be decided? Voice-over-IP, video telephony, video conferencing. Cost is determined by the resource requirements of both sender and receiver. The sender is responsible for the cost. 2. I could not understand how the connection Setup will take place in a heterogeneous IP network (where there are multiple service providers with complex SLA's) Note that the text does not say hetrogenous "IP" network. The hetrogenous refers to different wireline or wireless technologies, such as CDMS2000, 802.11, WCDMA, GSM. It is envisioned that these networks are interconnected via the NSIS network. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jun 24 16:56: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 QAA00108 for ; Mon, 24 Jun 2002 16:56:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12014 for nsis-archive@odin.ietf.org; Mon, 24 Jun 2002 16:56: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 QAA10700; Mon, 24 Jun 2002 16:42: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 QAA10667 for ; Mon, 24 Jun 2002 16:42:30 -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 QAA29304 for ; Mon, 24 Jun 2002 16:41:44 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 16:40:49 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'Charles Q. Shen'" , "Shahrier, Sharif M." , "'Zhigang.Kan@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] New I-D on framework for QoS signaling Date: Mon, 24 Jun 2002 16:40: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 QAA10668 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 Charles, So is this aggregate flow sent to a single receiver or multiple receivers? Aggregate flow consists of bundling of a large number of flows that have the same QoS treatment. At various points, the flows are again separated and directed to different receivers. Is there any other major difference of the proposal from original RSVP except that routers may need to do two-way reservation based on messages passed through? The only difference is the message formats needed to convey reservation information for send and receive direction simultaneously in the same message. Thx./Charles At 16:07 2002-6-21 -0400, Shahrier, Sharif M. wrote: >The protocol can be made scalable by combining a group of flows into a >single "aggregate flow" class, where all the flows in the aggregate set >have the same QoS treatment. In this manner, the need to store state at each >hop for every single flow is eliminated => better scalability. > >Another thing that can be done is not to replacate storing those QoS >parameters that are common to some of the flows. Thus, it needs to be stored >only once at each hop. This will also improve scalability. > >Sharif. > >-----Original Message----- >From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] >Sent: Thursday, June 20, 2002 9:51 PM >To: Sharif.Shahrier@interdigital.com; nsis@ietf.org >Subject: RE: [NSIS] New I-D on framework for QoS signaling > >Hi, > >How about the scalability of your proposed QoS signaling? Must each hop >store the state for per-flow traffic? > >BR/Kan Zhigang > >-----Original Message----- >From: ext Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] >Sent: 2002å¹´6æoe^20æ-¥ 21:52 >To: nsis@ietf.org >Subject: [NSIS] New I-D on framework for QoS signaling > > >The following draft is a framework document for QoS signaling for NSIS. We >request that it be considered for working group document. > > <> > >Sharif. > >_______________________________________________ >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 Jun 25 05:14: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 FAA27305 for ; Tue, 25 Jun 2002 05:14:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA28784 for nsis-archive@odin.ietf.org; Tue, 25 Jun 2002 05: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 EAA27805; Tue, 25 Jun 2002 04:57: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 EAA27776 for ; Tue, 25 Jun 2002 04:57:49 -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 EAA26977 for ; Tue, 25 Jun 2002 04:57:05 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 09:57:47 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3C6@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] draft on middlebox communication and NSIS Date: Tue, 25 Jun 2002 09:57:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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" Hi Marcus, I like this draft a lot. Especially since, following recent scope discussions, we've been supposed to think about NSIS != QoS signalling but broader, but all our instincts about the top level way the protocol should operate are clearly still driven by QoS-derived thinking (although we did our best to make the latest framework more generic, at least in the terminology). So, thinking about the middlebox aspect is interesting. On which basis, a few questions: 1. On the 'directional property' (6.3) I see the reasoning clearly. The implication of this (to me) is that the ability to support receiver initiation as well as sender initiation is a must (in fact, a MUST). Is this true? 2. With a QoS background, we've tended to think in terms of a chain-of-trust model (in fact, a chain-of-AAA-interactions) model. Does the same thinking apply in the middlebox case, or something more complicated? This assumption has quite a big impact on the way an eventual protocol gets structured (it's one of our framework critical issues.) 3. Relatedly, I guess that using NSIS for this might commonly result in partial failures ("i've set things up this far but the rest needs to be done from the other end"). Again, thinking about semantics of acknowledgement/error messages was one of our open issues. Do you think that this sort of thing could be service specific (and hence opaque to NSIS) or does the protocol have to account for it somehow? 4. The multihomed network problem (6.5) is clearly a headache. It seems to me that we really need a sort of ultra-lightweight path discovery message (icmp based?) which the sender can generate (maybe at receiver request), but which carries so little information that people will be happy-ish (maybe...) to let it through firewalls. But i don't know whether this is in the scope of NSIS to think about (it should be 'on-path' enough for most people...) Cheers, Robert > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 24 June 2002 20:18 > To: nsis@ietf.org > Subject: [NSIS] draft on middlebox communication and NSIS > > > I interpreted the cut-off time wrong (9:00) though to be in > the evening) > Nevertheless, those of you interested in middlebox > communication, here is a > short text on middlebox communication in the NSIS framework. > > http://www.brubers.org/marcus/papers/draft-brunner-nsis-mbox-f mwk-00.txt 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 --------------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 Tue Jun 25 08:02: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 IAA01577 for ; Tue, 25 Jun 2002 08:02:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06309 for nsis-archive@odin.ietf.org; Tue, 25 Jun 2002 08:03: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 HAA05550; Tue, 25 Jun 2002 07:49: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 HAA05516 for ; Tue, 25 Jun 2002 07:49: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 HAA01123 for ; Tue, 25 Jun 2002 07:48:55 -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) for id 17Mool-0000nS-00; Tue, 25 Jun 2002 13:49:07 +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 g5PBn7t12176 for ; Tue, 25 Jun 2002 13:49:07 +0200 Message-ID: <3D1858B3.4E00A883@ee.tu-berlin.de> Date: Tue, 25 Jun 2002 13:49:07 +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: NSIS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Multicast v.s. unicast in RSVP 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, Section 3.2.5 "Multicast versus Unicast" of [draft-hancock-nsis-fw-00.txt] states: Multicast support, compared to unicast support, would introduce a level of complexity into the NSIS protocol mainly related to: * complex state maintenance to support dynamic membership changes in the multicast groups, such as reservation state merging and maintenance. * a state per flow has to be maintained that is used during backward routing. RSVP, as a typical example, supports dynamic multicast member and large number of heterounous (QoS request of the) receivers. We think multicast brings more mandatory features to RSVPv1 than that described above: - Optimized as receiver-initiated way to support multicast receivers especially, heterounous (QoS request of the) receivers - Two-pass (Path/Resv) signaling message exchange (which results in complex state management) - Specification on "reservation styles" to tell network nodes which set of receivers and how simular these receivers' QoS request are (having to be used anywhere) - Complicated error handling (e.g., killer problems) These are analyzed in [draft-fu-rsvp-multicast-analysis-00.txt]. Due to the fact that vast majority of application being unicast, We think it could be interesting to remove multicast in RSVP. Although sender-initiated is recommended for a such simplication, it is possible to support both sender-initiated and receiver-initiated way, via high-level interaction of protocol components. In principle, end-to-end bi-directional way could be supported as well, however, hop-by-hop bi-directional support depends on the network topology and could be locally optimized if an AS (even an RSVPhop-RSVPhop pair) supports symmetric routing of data packets. A potential implication due to the sender-initiated one-way signaling message is some simpler abstraction like "QoS profile" could be used instead of Sender_TSpec/AdSpec and FlowSpec, even it would probably not developed within NSIS. Still, how to support multicast capability by a unicast-dedicated RSVP-variant would be an open issue. Nevertheless, we notice that there are some examples considering multicast as a function built on top of unicast routing rather than as an integral part of it. Thanks, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jun 25 08:51: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 IAA03413 for ; Tue, 25 Jun 2002 08:51:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA08523 for nsis-archive@odin.ietf.org; Tue, 25 Jun 2002 08:51: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 IAA07670; Tue, 25 Jun 2002 08:34: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 IAA07636 for ; Tue, 25 Jun 2002 08:34:32 -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 IAA02781 for ; Tue, 25 Jun 2002 08:33:46 -0400 (EDT) Received: from Freedom.icr.a-star.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.12.1/8.12.1) with ESMTP id g5PCZlBL026363; Tue, 25 Jun 2002 20:35:47 +0800 (SGT) Message-Id: <5.1.0.14.2.20020625203221.045e2e18@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Jun 2002 20:33:28 +0800 To: "'Zhigang.Kan@nokia.com'" , nsis@ietf.org From: "Charles Q. Shen" Subject: RE: [NSIS] New I-D on framework for QoS signaling In-Reply-To: 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 IAA07637 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 Fine. So problems and solutions with RSVP may largely apply to this as well. Charles At 16:40 2002-6-24 -0400, Shahrier, Sharif M. wrote: >Charles, > > >So is this aggregate flow sent to a single receiver or multiple receivers? > >Aggregate flow consists of bundling of a large number of flows that have the >same QoS treatment. At various points, the flows are again separated and >directed to different receivers. > >Is there any other major difference of the proposal from original RSVP >except that routers may need to do two-way reservation based on messages >passed through? > >The only difference is the message formats needed to convey reservation >information for send and receive direction simultaneously in the same >message. > >Thx./Charles > > >At 16:07 2002-6-21 -0400, Shahrier, Sharif M. wrote: > > >The protocol can be made scalable by combining a group of flows into a > >single "aggregate flow" class, where all the flows in the aggregate set > >have the same QoS treatment. In this manner, the need to store state at >each > >hop for every single flow is eliminated => better scalability. > > > >Another thing that can be done is not to replacate storing those QoS > >parameters that are common to some of the flows. Thus, it needs to be >stored > >only once at each hop. This will also improve scalability. > > > >Sharif. > > > >-----Original Message----- > >From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > >Sent: Thursday, June 20, 2002 9:51 PM > >To: Sharif.Shahrier@interdigital.com; nsis@ietf.org > >Subject: RE: [NSIS] New I-D on framework for QoS signaling > > > >Hi, > > > >How about the scalability of your proposed QoS signaling? Must each hop > >store the state for per-flow traffic? > > > >BR/Kan Zhigang > > > >-----Original Message----- > >From: ext Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > >Sent: 2002å¹´6æoe^20æ-¥ 21:52 > >To: nsis@ietf.org > >Subject: [NSIS] New I-D on framework for QoS signaling > > > > > >The following draft is a framework document for QoS signaling for NSIS. We > >request that it be considered for working group document. > > > > <> > > > >Sharif. > > > >_______________________________________________ > >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 Jun 25 09:08: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 JAA04047 for ; Tue, 25 Jun 2002 09:08:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09975 for nsis-archive@odin.ietf.org; Tue, 25 Jun 2002 09:09: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 IAA08385; Tue, 25 Jun 2002 08:48: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 IAA08355 for ; Tue, 25 Jun 2002 08:48:55 -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 IAA03253 for ; Tue, 25 Jun 2002 08:48:11 -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 g5PCm2BW029985; Tue, 25 Jun 2002 05:48:02 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEG21119; Tue, 25 Jun 2002 05:45:08 -0700 (PDT) Message-Id: <5.1.0.14.0.20020625084045.00a87d90@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Jun 2002 08:45:20 -0400 To: tist@external.cisco.com, nsis@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [NSIS] Network-friendly midcom draft revision 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've submitted a revision of the network-friendly midcom (i.e. using an RSVP-like approach for midcom) draft, which is basically a framework document for the protocol that's already in the internet drafts directory, but it will take a few days to work through the queue. In the interim it's available at http://www.employees.org/~shore/draft-shore-friendly-midcom-01.txt Thanks, Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jun 25 13:14: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 NAA16475 for ; Tue, 25 Jun 2002 13:14:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28423 for nsis-archive@odin.ietf.org; Tue, 25 Jun 2002 13:14: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 NAA26861; Tue, 25 Jun 2002 13:00: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 NAA26828 for ; Tue, 25 Jun 2002 13:00:01 -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 MAA15764 for ; Tue, 25 Jun 2002 12:59:17 -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 g5PGxIdg016438; Tue, 25 Jun 2002 09:59:18 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEG27100; Tue, 25 Jun 2002 09:56:15 -0700 (PDT) Message-Id: <5.1.0.14.0.20020625124236.05fad400@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Jun 2002 12:55:19 -0400 To: "Hancock, Robert" , "'brunner@ccrle.nec.de'" , nsis@ietf.org From: Melinda Shore Subject: RE: [NSIS] draft on middlebox communication and NSIS In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA3C6@rsys002a.roke.co.uk > 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 I'd like to take a shot at these, if I may. At 09:57 AM 6/25/02 +0100, Hancock, Robert wrote: >1. On the 'directional property' (6.3) I see the reasoning clearly. The implication of this (to me) is that the ability to support receiver initiation as well as sender initiation is a must (in fact, a MUST). Is this true? Not necessarily - a sender-initiated "reservation" may include rules to describe incoming packets. It's probably best to think of the problem in terms of who owns the policy in the firewall and who's allowed to manipulate it (and there are some rather difficult issues here with regard to firewalls outside the sender's policy domain). I tend to think of this use of signaling as being responsive to individual endpoint's *application's* needs, and not being useful for general firewall provisioning/configuration. >2. With a QoS background, we've tended to think in terms of a chain-of-trust model (in fact, a chain-of-AAA-interactions) model. Does the same thinking apply in the middlebox case, or something more complicated? This assumption has quite a big impact on the way an eventual protocol gets structured (it's one of our framework critical issues.) This is a huge problem, actually. Aside from the lack of authentication infrastructure that would allow arbitrary middleboxes to authenticate to each other, there's an authorization problem, as well. It is incorrect to assume that you can trust anybody who authenticates correctly (assuming that's possible in the first place). >4. The multihomed network problem (6.5) is clearly a headache. It seems to me that we really need a sort of ultra-lightweight path discovery message (icmp based?) which the sender can generate (maybe at receiver request), but which carries so little information that people will be happy-ish (maybe...) to let it through firewalls. But i don't know whether this is in the scope of NSIS to think about (it should be 'on-path' enough for most people...) I would argue that moving a path discovery mechanism out of scope (or at least out of the protocol) removes responsiveness to routing and topology changes. But aside from that, one of the tremendous advantages to using an RSVP-like approach to talking to middleboxes is that it allows correct operation in the face of the kind of minor topological complexity that would stymie midcom. For example, in the path from here to there you've got a firewall and you've got a NAT. How do you know what address to present to the firewall in your pinhole request? Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue Jun 25 15:51: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 PAA25557 for ; Tue, 25 Jun 2002 15:51:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12351 for nsis-archive@odin.ietf.org; Tue, 25 Jun 2002 15:52: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 PAA11593; Tue, 25 Jun 2002 15:36: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 PAA11552 for ; Tue, 25 Jun 2002 15:36:30 -0400 (EDT) Received: from legend-mfy8zk0p ([61.144.241.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24583 for ; Tue, 25 Jun 2002 15:35:42 -0400 (EDT) From: zhulinxi@yahoo.com.cn Message-Id: <200206251935.PAA24583@ietf.org> To: nsis@ietf.org Date: Wed, 26 Jun 2002 03:39:15 +0800 X-Priority: 3 X-Mailer: CSM 3.2 Subject: [NSIS] =?GB2312?B?zt7QuL/Ju/e1xNChx/i3wLXBsai+r8+1zbM=?= 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 http://www.110alarm.com E-mail:solar@szonline.net ÓÐÕâôһ¸öÖÇÄÜ»¯Ð¡Çø,ÓÐÒ»Ì×ÍêÉƵÄÖÇÄܱ¨¾¯ÏµÍ³: ©ú©ú ©ú©ú ³ÊÏÖÔÚÖ¸»ÓÖÐÐĵÄÊÇÒ»¸ö¸ßÑÅ´øÓÐÒº¾§ÏÔʾÖÐÐÄÕ¾ ,ͨ¹ý232½Ó¿ÚºÍµçÄÔÁª½Ó,ÕýÇ°·½µÄǽÃæÉϹÒ×ÅСÇøµÄƽÃæͼ;´Ëʱ¾¯µÆÏìÆð,µç×ÓµØͼÉÏÏÔʾ**¶°**ºÅ·¿¼Ò±»µÁ . ©ú©úСÇøÈκÎÒ»ÌõÏß,ÈκÎÒ»¸öÖÕ¶Ë(ºìÍâ¡¢½ô¼±°´Å¥ÃºÆø̽²âÆ÷ ÃŴŵȷÀÇø),ÈκÎÒ»¸öµçÔ´¿ªÂ·¡¢ ¶Ì· ¡¢Í£µç¡¢ ¾¡ÏÔÖÐÐÄ,ÿ¼Òÿ»§µÄÈκβ¼·À¡¢³··À¡¢ÃÜÂëÈý´ÎÊä´í¾¡±¨ÖÐÐÄ,¶ø²»Óû¨ÈκÎͨѶ·ÑÓÃ,Æä¸ß¿É¿¿ÐԺͱջ·(ÉÏÐб¨ ¾¯ÏÂÐÐѲ¼ì)½á¹¹¸üÊǵ绰²¦ºÅºÍÎÞÏß±¨¾¯Ëù²»ÄܱÈÄâµÄ,Õæ¿Éνһ̨°²È«ÔÚÎÒÐÄÖÐ ¡£©ú©ú ×ÜÏß²¼Ïß¼òµ¥Ã÷àÚ ©ú©ú ÔÚ·ÀÇ¿µç´®È뿹 À×»÷¸ü¾ßÓн³ÐĶÀÔË ©ú©ú¼Û¸ñ¸üÊǵ͵ÃÈÃÄúÐĶ¯¿ª»³©ú ©ú©úÈ«ÐÂSMTÌùƬ¹¤ÒÕ,´ó¼¯³É¾ñÑÚĤµç· ,ÓÐÄú³¬ºõÏëÏóµÄÎȶ¨, ©ú©ú¸üÓÐ82¸öСÇø5Íò¶àÓû§¶àÄê¿É¿¿Ê¹Óéú¿Éν"ǧ´¸°ÙÁ¶" ¹«°²²¿ÐÍʽ¼ì²â ½¨É貿ºÍ¹ú ¼ÒסլÖÐÐÄÁªºÏÍƼö ¹«°²²¿ÏÂÎÄÅú¸´¿ÉÒÔÖ±µÖ110רÍø©ú ISO9002¹ú¼ÊÈÏÖ¤ ¹ã¶«Ê¡ºÍ¹ú¼Ò¼¶Ë«ÖØÖصãвúƷϵͳ ----- ½éÉÜÓÀ»ªÖÇÄÜ485ÍøÂçÐÍ×ÜÏßÖÆ ©ú©úÓÀ»ªÖÇÄÜ×¢²áרÀûµÄÀûÓ÷ÀµÁÖ÷»ú×é³ÉÍøÂçͨ¹ýµç»°Ïß»òרÏßÏòÖÐÐÄ´«µÝ¸÷ÖÖÐÅÏ¢µÄÍøÂ繦ÄÜ×ÔÍƳöÊг¡ÒÔÀ´, Êܵ½Ð¡ÇøÓû§¼°ÎïÒµ¹ÜÀí²¿ÃŵĹ㷺»¶Ó­.©ú ©ú©úΪʹÍøÂ繦ÄÜÔÚ²»Í¬µÄСÇøÌõ¼þϵõ½ÁÜÀ쾡Öµķ¢»Ó, ÎåÄêÀ´,ÓÀ»ªÖÇÄܽÓÁ¬¿ª·¢ÁË×ÜÏßÖÆͨѶ·½Ê½µÄÖ÷»ú, ÅäÒÔ×îпª·¢Îó±¨Âʼ«µÍµÄÎü¶¥ºìÍâ̽ͷ, ¼ÓÉÏÎÞÏß´«Êä×Լ칦ÄÜ, ×é³ÉÒ»¸öÎÞи¿É»÷µÄ·ÀµÁ±¨¾¯ÏµÍ³, ʹÓû§ÔÚ ¼õÉÙÉõÖÁûÓжîÍâµç»°·ÑµÄͬʱ, ¾¡ÏíÍøÂ繦ÄÜ´øÀ´µÄÓÅÔ½ÐÔ, Ò»¾Ù½â¾öÇøÄÚ³µÁ¾·ÀµÁ, ʵʱѲ¸ü, ±£°²Ô±¾È»¤Ïµ ͳ, µç»°Ïß·À¼ôµÈÎÊÌâ.©ú ©ú©úÏÖÔÚ, Ô½À´Ô½¶àµÄÓû§Á˽⵽, ·ÀµÁ±¨¾¯ÏµÍ³Ö»ÓÐͨ¹ýÖÐÐÄÁªÍø²ÅÄÜÕæÕý·¢»Ó×÷ÓÃ, СÇøÆÕ±é²ÉÓõĵ绰ÏßÁª Íø, »á²úÉúÒ»¶¨µÄ»°·Ñ. ÒÔÿÌìËĴβ¼/³··À±¨¸æ¼Æ, Ò»Ìì´óÔ¼°ËëǮ, Ò»¸öÔÂÔ¼¶þÊ®¶àÔª, ¶ÔÓÚÒ»°ãÆÕͨ¼ÒÍ¥À´Ëµ , Ò²ÊÇÒ»¸öÊýÄ¿, Õâ²î²»¶à¿ÉÒÔ½»±¨¾¯¹ÜÀíÔ·ÑÁË. Õë¶ÔÕâ¸öÊг¡·´À¡ÐÅÏ¢, ÓÀ»ªÖÇÄܱê×¼ÐÍÔö¼ÓÁËÒ»¸ö¹¦ÄÜ, ²¼ ³··À±¨¸æ¿ÉÒÔ¶ÀÁ¢±à³Ì, Óû§¿ÉÒÔÑ¡Ôñ²¼/³··À²»±¨¸æ, ¶øµÍѹ, ÈõµçµÈ±¨¸æÕÕ¾É, Ö÷»úÔòÔö¼ÓÁËÒ»¸ö¶¨Ê±±¨¸æ, ÿ ÌìÒ»´Î, ·½±ãÖÐÐÄÕÆÎÕÓû§Ö÷»úʹÓÃÇé¿ö. ÍòÒ»Óû§ÓëÖÐÐÄ·¢ÉúÕùÒéʱ, Ö÷»ú´æÓÐ×îºó8´Î²¼/³··Àʱ¼ä¼Ç¼¿ÉÒÔÌá ¹©ÓйØ×ÊÁÏÖ¤Ã÷ (ºÚÏ»×Ó¹¦ÄÜ).©ú ©ú©úÔÚÒѾ­ÈëסµÄСÇø, ¿ÉÒÔÏÈ¿¼ÂÇʹÓÃ485±ê×¼ÐÍ, ͨ¹ýµç»°ÏßÁªÍø, ÃâÈ¥²¼ÏßµÄÂé·³. Èç¹ûÓû§·Ç³£ÔÚÒâ»°·ÑÖ§ ³ö, Ôò¿ÉÒÔ¿¼ÂÇÿ»§À­Ò»Ìõ4оÏß, ²ÉÓÃ×ÜÏßÖÆͨѶ, ÖÐÑ빩µç, ¿ÉÑ¡Ôñ485ÔöÇ¿ÐÍ, Áé»îÅäÓÃÎÞÏß»òÓÐÏß̽²âÆ÷. ÓÐÌõ¼þµÄÓû§Ôò¿ÉÑ¡ÓÃ485ºÀ»ªÐÍ, ÅäÓн϶à·ÀÇø, Èç¹û²»ÏëÆÆ»µÏÖÓÐ×°Ð޵Ļ°, Ò²¿ÉÑ¡ÔñʹÓÃÎÞÏß̽²âÆ÷¼°µç»°Ïß ÓëÖÐÐÄͨѶ(Óû§¿É±à³Ì). ©ú©úÔÚÉÐδÈëס, Õý´¦½¨ÖþÆÚµÄСÇø, ¿ÉÒÔÑ¡ÓÃ485¾­¼ÃÐÍ, ÀûÓÃ×ۺϲ¼Ïß(×ÜÏßÖÆ)×÷ΪÖÐÐÄͨѶ·½Ê½, ÓèÂñÓÐÏß̽ ²âÆ÷ÓëÖ÷»úÖ®¼äµÄÁ¬Ïß(Èç̽ͷ, ÃÅ´Å), ´ó´ó½µµÍÅä¼þ³É±¾, ͬʱÓÖ¿ÉÒòÓ¦¸ö±ðÓû§ÒªÇóËæÒâÔö¼ÓÎÞÏß̽²âÆ÷(ÈçÔÚ Ñǫ̂°²×°Ä»Á±Ì½Í·), Âú×ãÿ¸öÓû§µÄ²»Í¬ÐèÇó. ©ú©ú²»ÂÛÊÇÓÃ×ÜÏßÖÆ»¹Êǵ绰Ïß, 485Ö÷»úÈ«²¿ÄÚÖÃÎÞÏß½ÓÊÕÆ÷, ²»½ö·½±ãÎÞÏßÒ£¿Ø²¼/³··À¼°À©³äÎÞÏß·ÀÇø, ¶øÇÒ ´øÓÐÍøÂçת·¢¹¦ÄÜ, ¶ÔÓÚÀ´×Ô³µÁ¾ÍøÂç·¢Éä»ú, Ѳ¸üÕ¾Ö÷»ú, ±£°²Ô±Çó¾È·¢Éä»ú, µç»°Ïß·À¼ôÍøÂç·¢Éä»úµÄÐźŶ¼ ÄܽÓÊÕ½âÂ벢ͨ¹ý×ÜÏß»òµç»°Ïß±¨¸æÖÐÐÄ.©ú©ú ¶ÔÓÚ²ÉÓÃ×ÜÏßÖƵÄÎïÒµ¹ÜÀíÖÐÐÄ, ÔòÐèÒªÅ䱸½âÂëÆ÷ÓëSK-485ÖÐÐÄ Á¬½ÓÒÔ¼°²»¼ä¶ÏµçÔ´Ïò¸÷Óû§¹©µç, »¹ÐèÅäÖÃÊʵ±µÄµç»°ÏßÒÔ½ÓÊÕ¸ö±ðÓû§Ê¹Óõ绰Ïߵı¨¾¯, ²¢¿ÉÒÔÀûÓøÃÏßÏò Éϼ¶ÖÐÐı¨¾¯»òÏòÓû§²éѯ. ÓÀ»ªÖÇÄܽ«ÌṩÓëÖÐÐÄÏà¹ØµÄÈ«²¿É豸. ©ú©úÓÀ»ªÖÇÄÜ485·ÀµÁ±¨¾¯ÏµÍ³ÎªÐ¡ÇøÌṩÁ˵ͳɱ¾µÄÍøÂçϵͳ, Ô²Âú½â¾öÁËСÇøÄÚؽ´ý½â¾öµÄÆäËü°²È«·À·¶µÄÎÊÌâ , ÔÚ×ÜÏßÖÆÁã»°·ÑµÄÌõ¼þÏÂ, ×î´óÏ޶ȷ¢»ÓÁËÍøÂ繦ÄÜ (ÈÎÒâת·¢¶ø²»²úÉú»°·Ñ). ³ýÁËÏÖÓеķÀ³µÁ¾±»µÁ, ·Àµç»° ÏßÆÆ»µ, ÎÞÏßʵʱѲ¸ü, ±£°²Ô±¾È»¤ÏµÍ³µÈÍøÂ繦ÄÜÍâ, ½«À´¸ü¿ÉÀ©³äµ½ÊµÊ±¸ú×Ù, µçÌÝÇó¾ÈµÈ¶àÖÖÓ¦ÓÃ. ©ú©úÍøÂ繦ÄܹÌÈ»ÒýÈËÈëʤ, µ«ÊÇ×îÖ÷ÒªµÄ»¹ÊÇ·ÀµÁϵͳ±¾ÉíµÄ¹¦ÄܹýÓ²²ÅÄÜ»ñÈ¡Óû§µÄÐÅÐÄ, ¶ø´óÓû§Á¿µÄ°²×° ²ÅÄÜÐγÉÍøÂç. ÓÀ»ªÖÇÄÜÔÚ485·ÀµÁ±¨¾¯ÏµÍ³±¾Éí×÷³öÁ˾޴óµÄ¸Ä½ø, Õâ±íÏÖÔÚ¿ª·¢Ë«´«¸ÐÆ÷ºìÍâ̽ͷ´ó´ó½µµÍÎó±¨ ÂÊ; Ôö¼ÓÎÞÏß´«Êä×Լ칦ÄÜ, ¼«´óÌá¸ßÁËϵͳµÄ¿É¿¿ÐÔ.©ú ©ú©úºìÍâ̽ͷ¶ÔÓÚϵͳµÄÖØÒªÐÔÊDz»ÑÔ¶øÓ÷µÄ, °Ù·ÖÖ®¾ÅÊ®ÒÔÉϵÄÎó±¨ÊÇÀ´×Ô̽ͷ¡£ÏÖÖÇÄÜСÇø¶ÔºìÍâ̽ͷҪÇóÁ¿ ´ó¡¢¿É¿¿ÐԸߡ¢¼Û¸ñÊÊÖС£ÓÉÈÕ±¾°²·ÀÌṩÉ̸»ÊË´ï(FUJAIMD)¸ù¾ÝÖйú¹úÇéÍƳöÁËÐÂÒ»´ú¿¹¸ÉÈÅ·ÀÎ󱨺ìÍâÎü¶¥Ì½ ²âÆ÷(FJ-850),¾ßСÇÉ¡¢ÃÀ¹ÛÌصãÒò»·¾³ÒýÆðµÄÎ󱨾¯¿Éͨ¹ý¹â´ø×èÂ˲¨Æ÷ºÍµÍÔëÉùÈȵç̽²âµÄ×éºÏÀ´Ïû³ý¡£±¾²úÆ· ×°ÓÐÄÚÖù¤Á½²½±¸Óü«ÐÔÂö³å¼ÆÊýÆ÷×öΪ¸½¼ÓµÄÎ󱨱£»¤×°ÖøòúÆ·´ÓÉè¼ÆÉϱ£Ö¤Á˲úÆ·µÄ¿É¿¿¡¢³¤ÊÙÃüºÍÎÞ¹ÊÕÏ µÈÌØÐÔ¡£ ©ú©úÁíÍâ,ÓÀ»ª¹«Ë¾¿ª·¢ÁËúÆø̽²âÆ÷,¼ÛÁ®ÖÊÓÅ.©ú©ú ¶ÔÓÚʹÓÃ×ÜÏßÖƵÄ485ÐÂÐͺÅ,¶¼ÅäÓÐÓÐÏß/ÎÞÏß·ÀÇø, ¶øÎÞÏß ·ÀÇøÈ«²¿´øÓÐ×Լ칦ÄÜ, ̽²âÆ÷µÍѹ, »ò³¬³öÓÐЧ½ÓÊÕ¾àÀë, Ö÷»ú»áÖªµÀ²¢±¨¸æÖÐÐÄ.ÍòÎÞһʧµÄ·ÀµÁ¹¦ÄÜ, ¼ÓÉÏÎÞ ¿×²»ÈëµÄÍøÂ繦ÄÜ, 485 ·ÀµÁ±¨¾¯ÏµÍ³ÊÇÍêÈ«, ³¹µ×, ÎÞи¿É»÷µÄ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jun 26 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 HAA13253 for ; Wed, 26 Jun 2002 07:44:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA21210 for nsis-archive@odin.ietf.org; Wed, 26 Jun 2002 07:45: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 HAA19536; Wed, 26 Jun 2002 07:24: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 HAA19504 for ; Wed, 26 Jun 2002 07:24:22 -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 HAA12319 for ; Wed, 26 Jun 2002 07:23:37 -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 g5QBOmi00793 for ; Wed, 26 Jun 2002 14:24: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 for ; Wed, 26 Jun 2002 14:24:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 26 Jun 2002 14:24: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" Date: Wed, 26 Jun 2002 14:24:17 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65544@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] New I-D on framework for QoS signaling Thread-Index: AcIbv7qC88vYMmRaRx6FIW8aZ05B3wBQ+GYw To: X-OriginalArrivalTime: 26 Jun 2002 11:24:18.0243 (UTC) FILETIME=[02B73130:01C21D04] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA19505 Subject: [NSIS] NSIS Draft 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, The NSIS agenda is shaping up, actually it seems quite full. Not all draft links work yet. John NSIS IETF 54 Agenda =================== MONDAY, July 15, 2002 0900-1130 Morning Session Agenda Bashing - John Loughney 5 min Work Group Status - John Loughney 5 min NSIS Requirements - Marcus Brunner - 30 minutes http://search.ietf.org/internet-drafts/draft-ietf-nsis-req-02.txt NSIS Threats & Security requirements - Hannes Tschofenig - 15 min http://search.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-00.txt 2 Level Signaling Architecture - Bob Braden - 15 min http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-00.txt Framework ========= Framework Structure for QoS Signaling - Kan Zhigang - 10 min http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt A Framework for Bi-Directional QoS Signaling - Sharif Shahrier - 15 min http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-00.txt Next Steps in Signaling: A Framework Proposal - Robert Hancock - 10 min http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt Analysis Issues =============== NSIS Resilience - Sven van den Bosch - 10 minutes draft-vandenbosch-nsis-resilience-00.txt RSVP Security Properties - Hannes Tschofenig - 10 min http://www.ersue.de/nsis/draft-tschofenig-rsvp-sec-properties-00.txt Analysis on RSVP Regarding Multicast - X. Fu - 10 min http://www-tkn.ee.tu-berlin.de/~fu/nsis/draft-fu-rsvp-multicast-analysis-00.txt On path and off path signaling for NSIS - Alban Couturier - 10 min http://www.ietf.org/internet-drafts/draft-schelen-nsis-opopsig-00.txt Solutions ========= Consideration of RSVP-TE Extension for Metro Network - yhyoo@icu.ac.kr - 10 min http://www.ietf.org/internet-drafts/draft-choi-metro-signaling-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jun 26 08:34: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 IAA15386 for ; Wed, 26 Jun 2002 08:34:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25694 for nsis-archive@odin.ietf.org; Wed, 26 Jun 2002 08:35: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 IAA23435; Wed, 26 Jun 2002 08:17: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 IAA23406 for ; Wed, 26 Jun 2002 08:17: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 IAA14487 for ; Wed, 26 Jun 2002 08:16:53 -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 g5QCI5i13321 for ; Wed, 26 Jun 2002 15:18:05 +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 ; Wed, 26 Jun 2002 15:17:36 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 26 Jun 2002 15:17:35 +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, 26 Jun 2002 15:17:34 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6554A@esebe004.NOE.Nokia.com> Thread-Topic: reminder on agendas Thread-Index: AcIdCnKSyhIStdrjQXOqPnQkTfo72AAAHKuw To: X-OriginalArrivalTime: 26 Jun 2002 12:17:35.0413 (UTC) FILETIME=[74609E50:01C21D0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA23407 Subject: [NSIS] Rememinder on IETF 54 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, Just as a reminder, there are to be no presentations at the IETF meeting. The point of the meeting is for discussion of open issues - which assumes there has been discussion on the mailing list. In the event of time constaints, all drafts without discussion will either be given a reduced time at the meeting or dropped from the agenda - depending on the amount of issues with other drafts. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jun 26 09:14: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 JAA17270 for ; Wed, 26 Jun 2002 09:14:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28497 for nsis-archive@odin.ietf.org; Wed, 26 Jun 2002 09:14: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 IAA27416; Wed, 26 Jun 2002 08:57: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 IAA27387 for ; Wed, 26 Jun 2002 08:57:17 -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 IAA16510 for ; Wed, 26 Jun 2002 08:56:34 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 13:55:52 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3DB@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Melinda Shore'" , "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] draft on middlebox communication and NSIS Date: Wed, 26 Jun 2002 13:55:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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" Hi Melinda, Please excuse my verbose answer. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > I'd like to take a shot at these, if I may. You're welcome. Thanks for the bullets. > > At 09:57 AM 6/25/02 +0100, Hancock, Robert wrote: > >1. On the 'directional property' (6.3) I see the reasoning > clearly. The implication of this (to me) is that the ability > to support receiver initiation as well as sender initiation > is a must (in fact, a MUST). Is this true? > > Not necessarily - a sender-initiated "reservation" may include > rules to describe incoming packets. It's probably best to think > of the problem in terms of who owns the policy in the firewall > and who's allowed to manipulate it (and there are some rather > difficult issues here with regard to firewalls outside the > sender's policy domain). I tend to think of this use of signaling > as being responsive to individual endpoint's *application's* needs, > and not being useful for general firewall provisioning/configuration. I used the term 'receiver initiated' to mean 'receiver of data packets sets up the reservation' (this is the way I think it's used in the NSIS requirements draft). So, when you say 'sender-initiated reservation ... incoming packets' I think we must be describing the same requirement. (And we have to think of the incoming and outgoing flows as basically logically distinct, because of asymmetric routing reasons.) The reason I raise the question is that there is an open issue in the requirements draft about whether we can restrict NSIS to thinking about the sender initiated case (i.e. only support signalling for reservations about outgoing packets), since you can sometimes build a very lightweight protocol under this assumption. However, it appears that it can't cover all the bases (especially this one). > > >2. With a QoS background, we've tended to think in terms of > a chain-of-trust model (in fact, a chain-of-AAA-interactions) > model. Does the same thinking apply in the middlebox case, or > something more complicated? This assumption has quite a big > impact on the way an eventual protocol gets structured (it's > one of our framework critical issues.) > > This is a huge problem, actually. Aside from the lack of > authentication > infrastructure that would allow arbitrary middleboxes to authenticate > to each other, there's an authorization problem, as well. It is > incorrect to assume that you can trust anybody who authenticates > correctly (assuming that's possible in the first place). Yep, it's clear that this is a hard issue. But even apart from the solution, I'm still struggling to work out what the gross operational requirements are in the multi-'domain' case (it's one of our prime framework issues, section 3.3.3 of our latest framework draft). To be specific, consider the following example: host --[1]-- nsis entity A --[2]-- nsis entity B --> rest of world ([1] and [2] are logical associations - we call them 'peer sessions' - between peer NSIS entities, which might extend over multiple IP hops.) We've found it would be nice to assume that the AAA (at least, the first two As) aspects of [1] are independent of the AAA aspects of [2], and so host and NSIS B don't have any mutual authentication or authorisation (if they do, they set up a direct peer session). But we don't know if this is reasonable, because it obviously depends on the resource type being signalled for. Actually, there is a good case for saying that AAA aspects are out of NSIS scope because they're all resource specific (and opaque to us). But, authentication is related to key management, and we'd like NSIS to be able to do something sensible for its users in this area, and authorisation models seem to affect state storage requirements where authorisation at one node is contingent on authorisation at another node (before or after it in the signalling chain). So, it seems we at least need to be thinking about it at some level. > > >4. The multihomed network problem (6.5) is clearly a > headache. It seems to me that we really need a sort of > ultra-lightweight path discovery message (icmp based?) which > the sender can generate (maybe at receiver request), but > which carries so little information that people will be > happy-ish (maybe...) to let it through firewalls. But i don't > know whether this is in the scope of NSIS to think about (it > should be 'on-path' enough for most people...) > > I would argue that moving a path discovery mechanism out of scope > (or at least out of the protocol) removes responsiveness to routing > and topology changes. But aside from that, one of the tremendous > advantages to using an RSVP-like approach to talking to middleboxes > is that it allows correct operation in the face of the kind of minor > topological complexity that would stymie midcom. For example, in > the path from here to there you've got a firewall and you've got a > NAT. How do you know what address to present to the firewall in your > pinhole request? It's clear that we need technologies for path discovery for precisely this reason. I'm not sure how many technologies there should be. NSIS will (I hope) develop a general RSVP-like mechanism; I'm wondering if it also needs a special lightweight variant which firewall administrators are happy about being transparent to. Your question about NAT traversal is a good one, which we also tried to consider explicitly in our latest framework. In the simple host-NAT-firewall case, we would have the NAT as a nearly-transparent 'NSIS forwarder' that re-wrote the flow definition part of the message. By the firewall saw the signalling, the pinhole request in the opaque part of the message would refer to the modified (and locally valid) flow definition. But I haven't looked at all the other cases (e.g. in your TIST draft), and in particular I'm not sure whether NSIS should be able to carry actual mapping table entries (it's not an NSIS requirement at the moment). There are too many protocol specific NAT traversal proposals for me to keep up with ... > > Melinda > Robert H. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > --------------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@ns.ietf.org Wed Jun 26 12:04: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 MAA26078 for ; Wed, 26 Jun 2002 12:04:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09658 for nsis-archive@odin.ietf.org; Wed, 26 Jun 2002 12:05: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 LAA07036; Wed, 26 Jun 2002 11:48: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 LAA07004 for ; Wed, 26 Jun 2002 11:48: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 LAA24907 for ; Wed, 26 Jun 2002 11:47:35 -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 g5QFl1dg001832; Wed, 26 Jun 2002 08:47:01 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEG58009; Wed, 26 Jun 2002 08:44:07 -0700 (PDT) Message-Id: <5.1.0.14.0.20020626112425.00abf0f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Jun 2002 11:46:48 -0400 To: "Hancock, Robert" , nsis@ietf.org From: Melinda Shore Subject: RE: [NSIS] draft on middlebox communication and NSIS In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA3DB@rsys002a.roke.co.uk > 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 01:55 PM 6/26/02 +0100, Hancock, Robert wrote: >The reason I raise the question is that there is an open issue in the requirements draft about whether we can restrict NSIS to thinking about the sender initiated case (i.e. only support signalling for reservations about outgoing packets), since you can sometimes build a very lightweight protocol under this assumption. However, it appears that it can't cover all the bases (especially this one). I would tend to want to do that for this particular application, anyway, because 1) in the cases which make firewalls and NATs difficult in the first place (VoIP, for example) the receiver won't have sufficient information (i.e. addresses and port numbers) to request the reservation until the sender tells him, anyway, and 2) there may be policy reasons to have the person initiating the request "closer" to the administrative domain of the sender. That last bit is muddy, granted, and needs a lot more work in general - it's related to the security difficulties that we'll surely be grappling with. >We've found it would be nice to assume that the AAA (at least, the first two As) aspects of [1] are independent of the AAA aspects of [2], and so host and NSIS B don't have any mutual authentication or authorisation (if they do, they set up a direct peer session). But we don't know if this is reasonable, because it obviously depends on the resource type being signalled for. It's a little messier than that, actually - one of the benefits of talking to middleboxes like this is that you don't need to know where they are in advance. That is to say, you don't need an existing relationship with them. The difficulty is that for practical purposes there's no good way in the internet *today* to have arbitrary entities be authenticated to each other (TLS works because a limited number of servers buy certs from more-or- less trusted certificate agencies - imagine every middlebox doing that). But here's the real question - even if you could authenticate someone you'd never known existed, on what basis do you authorize them to, say, open a hole in your firewall? >It's clear that we need technologies for path discovery for precisely this reason. I'm not sure how many technologies there should be. NSIS will (I hope) develop a general RSVP-like mechanism; I'm wondering if it also needs a special lightweight variant which firewall administrators are happy about being transparent to. The problem is how you intend to use the information. Aside from the fact that the folks who run big networks don't *want* you to know where their firewalls are, I've been looking at some of the arguments for middlebox discovery and haven't found anything particularly compelling. Actually, that's not quite right - what I have found is a compelling argument for not doing it. It's like programming - if you do some work to find out whether or not you can do something and if you can then you try to do it, you create potential race conditions. If you just go ahead and do it and check the results you'll know whether or not you succeeded, you saved yourself the overhead of running checks ahead of time, and you avoid race conditions. I've gotten religion about this, and so you'll have to forgive me. If you do middlebox discovery it suggests that you intend to do something with the information that you collect. There are multiple problems with doing so, including that discovery only gives you a picture of the network at the time that you did the discovery, and yet one of the things we like (don't we?) about IP is that routing is adaptive to changes in network state on a per-packet basis. By establishing explicit connections to middleboxes and wiring state into middleboxes we're violating two fundamental IP design principles, one of them major and the other somewhat lesser. The major one is that of fate- sharing, which is part of what makes (or used to make) applications running over IP so robust. The lesser one is layering, although I feel pretty strongly that layer violations lead to network topology problems and perhaps isn't so lesser after all. I would tread quite lightly where discovery is concerned. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jun 26 18:34: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 SAA14002 for ; Wed, 26 Jun 2002 18:34:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05655 for nsis-archive@odin.ietf.org; Wed, 26 Jun 2002 18:34: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 SAA04213; Wed, 26 Jun 2002 18:09: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 SAA04179 for ; Wed, 26 Jun 2002 18:09:26 -0400 (EDT) Received: from odin.ietf.org ([81.24.15.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13281 for ; Wed, 26 Jun 2002 18:06:58 -0400 (EDT) Message-Id: <200206262206.SAA13281@ietf.org> From: "BENSON SEKO" Date: Tue, 25 Jun 2002 23:05:26 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] PLEASE CAN YOU ASSIST 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 FRIEND, I AM BENSON SEKO SON OF THE LATE MOBUTU SESE SEKO, THE FORMER PRESIDENT OF THE ZAIRE. I AM PRESENTLY UNDER PROTECTIVE CUSTODY IN NIGERIA AS A POLITICAL REFUGEE. I GOT YOUR CONTACT DURING MY SEARCH FOR A STRANGER THAT CAN COOPERATE WITH ME IN THIS MUTUAL TRANSACTION. I WANT YOU TO NOTE THAT THIS BUSINESS WILL BENEFIT BOTH OF US. HOWEVER, YOU MUST CONFIRM YOUR ABILITY TO HANDLE THIS BECAUSE IT INVOLVES A LARGE AMOUNT OF MONEY. THE MONEY (47 MILLION US DOLLARS ) I ESCAPED WITH MY PARENTS ALONG WITH MY BROTHER BASHER OUT OF DEMOCRATIC REPUBLIC OF CONGO (DRC) TO ABIDJAN, COTE D'IVOIRE WHERE MY FAMILY AND I SETTLED, WHILE WE LATER MOVED TO SETTLED IN MORROCO WHERE MY FATHER LATER DIED OF CANCER DISEASE.I DECIDED LAYING LOW IN AFRICA TO STUDY THE SITUATION TILL WHEN THINGS GETS BETTER, LIKE NOW THAT PRESIDENT KABILA IS DEAD AND THE SON TAKING OVER (JOSEPH KABILA). ONE OF MY LATE FATHER'S CHATEAUX IN SOUTHERN FRANCE WAS CONFISCATED BY THE FRENCH GOVERNMENT, THIS LED TO THE DECISION TO TURN THE REMAINING FUNDS OVER TO A SAFE SECURITY COMPANY IN EUROPE VIA THE DIPLOMATIC COURIER SERVICES FOR SAFE KEEPING AS MOST OF MY FATHER'S BILLIONS OF DOLLARS DEPOSITED IN SWISS BANKS AND OTHER FINANCIAL INSTITUTIONS HAVE BEEN FROZEN BY THE GOVERNMENT OF (DR) MR LAURENT KABILA HAVING CONCLUDED ARRANGEMENTS WITH THE SWISS GOVERNMENT AND OTHER CONTRIES INVOLVED. NOW THE CRISIS HAS ABATED I AM LOOKING FOR A PERSON LIKE YOU TO PROCEED TO THE PLACE OF THE SECURITY COMPANY IN ORDER TO CLEAR THE FUND AND INVEST ON MY BEHALF AS I DON’T WANT MY NAME TO BE USED FOR NOW AS I REALISE VERY MUCH THE TYPE OF HATRED LATE KABILA THE FORMER HEAD OF STATE HAS FOR MY LATE FATHER AND EVEN HIS SON WHO IS NOW THE HEAD OF STATE. NOTE THAT I WILL SEND TO YOU THE RELEVANT DOCUMENTS THAT WILL ENABLE YOU TAKE POSSESION OF THE FUND FOR ONWARD INVESTMENT FOR OUR MUTUAL BENEFIT. ALL I NEED FROM YOU IS AS FOLLOWS: 1. A COMMITTMENT THAT YOU WILL KEEP THE TRANSACTION STRICTLY CONFIDENTIAL. 2. YOUR CONFIRMATION OF YOUR ABILITY TO HANDLE THIS. 3. YOUR TELEPHONE AND FAX NUMBERS INCLUDING MOBILE FOR EASY COMMUNICATION. 4. YOUR FULL PERMANENT ADDRESS. AS SOON AS I GET THE ABOVE INFORMATION FROM YOU, I WILL DISCLOSE TO YOU THE NAME AND THE COUNTRY OF THE SECURITY COMPANY SO THAT YOU CAN MAKE ARRANGEMENTS TO TRAVEL AND COLLECT THE LUGGAGES. I AM WAITING FOR YOUR RESPONSE VIA EMAIL:bseko6@muchomail.com TO ENABLE US PROCEED. REGARDS. BENSON SEKO _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 27 04:04: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 EAA05454 for ; Thu, 27 Jun 2002 04:04:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09884 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 04:05: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 DAA08318; Thu, 27 Jun 2002 03:49: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 DAA08289 for ; Thu, 27 Jun 2002 03:49:13 -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 DAA04976 for ; Thu, 27 Jun 2002 03:47:14 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 08:47:49 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3E2@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Melinda Shore'" , nsis@ietf.org Subject: discovery & authorisation requirements (was: RE: [NSIS] draft on middlebox communication and NSIS) Date: Thu, 27 Jun 2002 08:47:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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" Hi Melinda, On "discovery": I think there's a small point and a bigger point. Small point (?): I don't want to imply too much by the term "discovery". So far as I'm concerned, the RSVP PATH message is a discovery mechanism (in the sense that it's the mechanism by which an RSVP capable node discovers its upstream neighbour to send RESV messages to), and I assume you're happy with that. It still seems the most general way for a receiver to find the ingress node for a flow, but some very stripped-down PATH-equivalent could be used for that (how many firewalls will happily pass a PATH message I wonder). I'm just not sure how many alternatives NSIS should try to investigate. I'm certainly not interested in developing a general purpose "let's go out and find all the middleboxes in the Internet" solution, and I don't think anyone else is proposing that either. Bigger point: it would clearly be nice if we could make 'what NSIS does' adaptive to network changes to the same extent that packet routing is. But NSIS is all about creating flow state or something (e.g. per-some-class state) derived from it. (If NSIS didn't modify the network state along the path, we could all pretty well stop now.) The ideal (for some people) seems to be that all that state should be soft, but as soon as authentication and message protection (let alone service negotiation and authorisation) are involved I guess this is going to be tricky. If your neighbour middlebox changes, do you really want to be kept ignorant of the fact? Just finding out automatically and reacting seems the best one can aim for; maybe I'm over pessimistic. Your questions about how on earth authorisation will take place are of course reasonable. But so far as I can tell, the mechanisms by which this will happen are highly resource-type specific and so defining them is out of scope of NSIS (we suggested this in our latest framework draft anyway); I think the best we can do is see if there are particular types of operations which don't need authorisation (e.g. if you can prove you're the same person who opened a pinhole, you probably don't need to be re-authorised to close it??). I don't know if this view is generally held (it's not compatible with a strict reading of the latest set of requirements). Robert H. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 26 June 2002 16:47 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] draft on middlebox communication and NSIS > > > At 01:55 PM 6/26/02 +0100, Hancock, Robert wrote: > >The reason I raise the question is that there is an open > issue in the requirements draft about whether we can restrict > NSIS to thinking about the sender initiated case (i.e. only > support signalling for reservations about outgoing packets), > since you can sometimes build a very lightweight protocol > under this assumption. However, it appears that it can't > cover all the bases (especially this one). > > I would tend to want to do that for this particular application, > anyway, because 1) in the cases which make firewalls and NATs > difficult in the first place (VoIP, for example) the receiver won't > have sufficient information (i.e. addresses and port numbers) to > request the reservation until the sender tells him, anyway, and > 2) there may be policy reasons to have the person initiating > the request "closer" to the administrative domain of the sender. > That last bit is muddy, granted, and needs a lot more work in > general - it's related to the security difficulties that we'll > surely be grappling with. > > >We've found it would be nice to assume that the AAA (at > least, the first two As) aspects of [1] are independent of > the AAA aspects of [2], and so host and NSIS B don't have any > mutual authentication or authorisation (if they do, they set > up a direct peer session). But we don't know if this is > reasonable, because it obviously depends on the resource type > being signalled for. > > It's a little messier than that, actually - one of the benefits > of talking to middleboxes like this is that you don't need to know > where they are in advance. That is to say, you don't need an > existing relationship with them. The difficulty is that for > practical purposes there's no good way in the internet *today* > to have arbitrary entities be authenticated to each other (TLS > works because a limited number of servers buy certs from more-or- > less trusted certificate agencies - imagine every middlebox doing > that). But here's the real question - even if you could authenticate > someone you'd never known existed, on what basis do you authorize > them to, say, open a hole in your firewall? > > >It's clear that we need technologies for path discovery for > precisely this reason. I'm not sure how many technologies > there should be. NSIS will (I hope) develop a general > RSVP-like mechanism; I'm wondering if it also needs a special > lightweight variant which firewall administrators are happy > about being transparent to. > > The problem is how you intend to use the information. Aside from > the fact that the folks who run big networks don't *want* you to know > where their firewalls are, I've been looking at some of the arguments > for middlebox discovery and haven't found anything particularly > compelling. Actually, that's not quite right - what I have found is > a compelling argument for not doing it. It's like programming - > if you do some work to find out whether or not you can do something > and if you can then you try to do it, you create potential race > conditions. If you just go ahead and do it and check the results > you'll know whether or not you succeeded, you saved yourself > the overhead > of running checks ahead of time, and you avoid race conditions. > > I've gotten religion about this, and so you'll have to forgive me. If > you do middlebox discovery it suggests that you intend to do something > with the information that you collect. There are multiple problems > with doing so, including that discovery only gives you a picture of > the network at the time that you did the discovery, and yet one of > the things we like (don't we?) about IP is that routing is adaptive > to changes in network state on a per-packet basis. By establishing > explicit connections to middleboxes and wiring state into middleboxes > we're violating two fundamental IP design principles, one of them > major and the other somewhat lesser. The major one is that of fate- > sharing, which is part of what makes (or used to make) applications > running over IP so robust. The lesser one is layering, although > I feel pretty strongly that layer violations lead to network > topology problems and perhaps isn't so lesser after all. > > I would tread quite lightly where discovery is concerned. > > Melinda > --------------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 Thu Jun 27 04: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 EAA06690 for ; Thu, 27 Jun 2002 04:54:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13350 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 04:54: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 EAA12937; Thu, 27 Jun 2002 04:40: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 EAA12901 for ; Thu, 27 Jun 2002 04:40:51 -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 EAA06454 for ; Thu, 27 Jun 2002 04:40:05 -0400 (EDT) From: Zhigang.Kan@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 g5R8fIi18740 for ; Thu, 27 Jun 2002 11:41:18 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 11:40:49 +0300 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 11:40:44 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 16:40:01 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Thu, 27 Jun 2002 16:35:59 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD07E3C2@beebe001.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft Thread-Index: AcIbdekvFiYAcFWvQ8qMwOB4nmRVTgCOwDyg To: , Cc: X-OriginalArrivalTime: 27 Jun 2002 08:40:01.0115 (UTC) FILETIME=[39D292B0:01C21DB6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id EAA12902 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, Resource Management Function is introduced in this draft as "RMF: an abstract concept, representing the management of resources in a domain or a node". I think that this definition is not appropriate for the aim of NSIS which is Signaling QoS, not Signaling resource. QoS Management Functioin (QMF) is suggested to be used because QMF includes RMF besides QoS Control, QoS provisioning, QoS policy, QoS mapping, QoS monitoring, etc.. BR/Kan Zhigang -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 2002å¹´6月24æ—¥ 19:47 To: NSIS Subject: [NSIS] New framework draft Hi all, A group of us who were involved in past NSIS framework activities got together after the interim meeting to put together a joint framework document in the form of an all-new individual submission. It (roughly) follows the structure that was introduced and refined at that meeting. ========================================================================== Abstract The NSIS working group is considering protocol developments in signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in a separate document; This Internet Draft proposes a framework for such signaling. This initial version provides a model for describing the entities that take part in the signaling and the ways in which they can be used in different modes of operation. It also discusses the overall structure of such a signaling protocol. Finally, it considers the possible interactions of NSIS signaling with other protocols and functions, including security issues. ========================================================================== While it works its way through the i-d editor queue, you can find a copy here: http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt Comments are welcome. There is a list of open issue highlights in section 3. Cheers, Robert Hancock _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 27 05:33: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 FAA07429 for ; Thu, 27 Jun 2002 05:33:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA15871 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 05:34: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 FAA14352; Thu, 27 Jun 2002 05:05: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 FAA14313 for ; Thu, 27 Jun 2002 05:05:41 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06895 for ; Thu, 27 Jun 2002 05:04:55 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g5R91b724676; Thu, 27 Jun 2002 11:01:37 +0200 Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function To: Zhigang.Kan@nokia.com Cc: , , X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 27 Jun 2002 11:05:00 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 06/27/2002 11:05:02 MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-jp 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 Zhigang, The RMF is not part of NSIS. It is part of the NSIS framework because it is one of the potential entities with which the NSIS entites could interoperate. We specifically decided on the use of Resource Management Function because NSIS technically isn't about QoS (alone) anymore. In the framework, a resource can refer to bandwidth but also to filtering space, schedulers, ... Hope this helps, Sven. Zhigang.Kan@nokia.com@ietf.org on 27/06/2002 10:35:59 Sent by: nsis-admin@ietf.org To: , cc: Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Hi, Resource Management Function is introduced in this draft as "RMF: an abstract concept, representing the management of resources in a domain or a node". I think that this definition is not appropriate for the aim of NSIS which is Signaling QoS, not Signaling resource. QoS Management Functioin (QMF) is suggested to be used because QMF includes RMF besides QoS Control, QoS provisioning, QoS policy, QoS mapping, QoS monitoring, etc.. BR/Kan Zhigang -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 2002$BG/(B6$B7n(B24$BF|(B 19:47 To: NSIS Subject: [NSIS] New framework draft Hi all, A group of us who were involved in past NSIS framework activities got together after the interim meeting to put together a joint framework document in the form of an all-new individual submission. It (roughly) follows the structure that was introduced and refined at that meeting. ========================================================================== Abstract The NSIS working group is considering protocol developments in signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in a separate document; This Internet Draft proposes a framework for such signaling. This initial version provides a model for describing the entities that take part in the signaling and the ways in which they can be used in different modes of operation. It also discusses the overall structure of such a signaling protocol. Finally, it considers the possible interactions of NSIS signaling with other protocols and functions, including security issues. ========================================================================== While it works its way through the i-d editor queue, you can find a copy here: http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt Comments are welcome. There is a list of open issue highlights in section 3. Cheers, Robert Hancock _______________________________________________ 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 Jun 27 05:33: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 FAA07442 for ; Thu, 27 Jun 2002 05:33:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA15882 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 05:34: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 FAA14556; Thu, 27 Jun 2002 05:10: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 FAA14522 for ; Thu, 27 Jun 2002 05:10: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 FAA06965 for ; Thu, 27 Jun 2002 05:10:09 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Jun 2002 11:09:32 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 11:10:22 +0200 Message-Id: From: "Geib, Ruediger" To: Zhigang.Kan@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Thu, 27 Jun 2002 11:10:19 +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 FAA14523 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 Kan, > Resource Management Function is introduced in this draft as > "RMF: an abstract concept, representing the management of > resources in a domain or a node". I think that this > definition is not appropriate for the aim of NSIS which is > Signaling QoS, not Signaling resource. And if it is going to be perfectly in the sense of IETF, NSIS is not only about QoS signaling, it is about service related signaling in general. What about calling the above system "Service Management Function"? Regards, Rüdiger > Hi all, > > A group of us who were involved in past NSIS framework > activities got together after the interim meeting to put > together a joint framework document in the form of an all-new > individual submission. It (roughly) follows the structure > that was introduced and refined at that meeting. > > ============================================================== > ============ > Abstract > > The NSIS working group is considering protocol developments in > signaling for resources for a traffic flow along its path in the > network. The requirements for such signaling are being > developed in a > separate document; This Internet Draft proposes a framework for > such signaling. This initial version provides a model for > describing > the entities that take part in the signaling and the ways in which > they can be used in different modes of operation. It also > discusses > the overall structure of such a signaling protocol. Finally, it > considers the possible interactions of NSIS signaling with other > protocols and functions, including security issues. > ============================================================== > ============ > > While it works its way through the i-d editor queue, you can > find a copy here: > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > Comments are welcome. There is a list of open issue > highlights in section 3. > > Cheers, > > Robert Hancock > > _______________________________________________ > 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 Jun 27 05:53: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 FAA07774 for ; Thu, 27 Jun 2002 05:53:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA16753 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 05:53: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 FAA16105; Thu, 27 Jun 2002 05:39: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 FAA16075 for ; Thu, 27 Jun 2002 05:39:17 -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 FAA07531 for ; Thu, 27 Jun 2002 05:38:31 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 10:38:59 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3E4@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Geib, Ruediger'" , Zhigang.Kan@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Thu, 27 Jun 2002 10:38:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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="utf-8" Content-Transfer-Encoding: quoted-printable hi all, I think it's valuable for Zhigang to highlight the point, because this = is one of the major changes in this NSIS framework input compared to = (most?) previous ones (certainly the ones I have been involved in). One = of the consequences of the email discussions around the time of the = interim meeting (e.g. = http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg01378.h= tml) was that we should look at more general resources than just QOS. = (IMHO, this is still not obvious even in the post-interim clarified = charter, BTW.) This has quite a big impact on what we write, at least. We still need a = good name for this "thing we are signalling for", "resource" (and hence = RMF) is a first guess. 'Service' seems to me to be too general. The key = point which is special about NSIS is that the relevant resources are = those which have to be provided by entities along the data path, but I = can't think of a snappy term for that. The other impact is that we might need to broaden our thinking about = how such a signalling protocol might fit into an overall solution to = some resource management problem (hence my interest in Marcus' firewall = draft). Certainly, the relationship between nsis and midcom/tist = activities seems important to understand. Robert H. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 27 June 2002 10:10 > To: Zhigang.Kan@nokia.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] New framework draft: Resource Management Function > v.s. QoS Management Function >=20 >=20 > Hi Kan, >=20 > > Resource Management Function is introduced in this draft as=20 > > "RMF: an abstract concept, representing the management of=20 > > resources in a domain or a node". I think that this=20 > > definition is not appropriate for the aim of NSIS which is=20 > > Signaling QoS, not Signaling resource.=20 >=20 > And if it is going to be perfectly in the sense of IETF, NSIS=20 > is not only about QoS signaling, it is about service related=20 > signaling in general. What about calling the above system=20 > "Service Management Function"? >=20 > Regards, R=C3=BCdiger >=20 > =20 > > Hi all, > >=20 > > A group of us who were involved in past NSIS framework=20 > > activities got together after the interim meeting to put=20 > > together a joint framework document in the form of an all-new=20 > > individual submission. It (roughly) follows the structure=20 > > that was introduced and refined at that meeting. > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Abstract=20 > > =20 > > The NSIS working group is considering protocol developments in=20 > > signaling for resources for a traffic flow along its path in the = > > network. The requirements for such signaling are being=20 > > developed in a=20 > > separate document; This Internet Draft proposes a framework for=20 > > such signaling. This initial version provides a model for=20 > > describing=20 > > the entities that take part in the signaling and the=20 > ways in which=20 > > they can be used in different modes of operation. It also=20 > > discusses=20 > > the overall structure of such a signaling protocol. Finally, it=20 > > considers the possible interactions of NSIS signaling with other = > > protocols and functions, including security issues.=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > While it works its way through the i-d editor queue, you can=20 > > find a copy here: > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > >=20 > > Comments are welcome. There is a list of open issue=20 > > highlights in section 3. > >=20 > > Cheers, > >=20 > > Robert Hancock > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 --------------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 Thu Jun 27 05:59: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 FAA07898 for ; Thu, 27 Jun 2002 05:59:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA17153 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 06:00:32 -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 FAA16486; Thu, 27 Jun 2002 05:47: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 FAA16455 for ; Thu, 27 Jun 2002 05:47: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 FAA07677 for ; Thu, 27 Jun 2002 05:46:17 -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 g5R9kwRb002229; Thu, 27 Jun 2002 11:46:58 +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 NHKQWZQG; Thu, 27 Jun 2002 11:46:58 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 11:42:56 +0200 Message-ID: X-Sybari-Trust: 5e4daaba 7216406a 0b6f7280 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" Cc: nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Thu, 27 Jun 2002 11:46:55 +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 FAA16456 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 agree with the explanation given by Robert regarding RMF. I am in favor of keeping the term RMF. Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Thursday, June 27, 2002 11:39 AM To: 'Geib, Ruediger'; Zhigang.Kan@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function hi all, I think it's valuable for Zhigang to highlight the point, because this is one of the major changes in this NSIS framework input compared to (most?) previous ones (certainly the ones I have been involved in). One of the consequences of the email discussions around the time of the interim meeting (e.g. http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg01378.html) was that we should look at more general resources than just QOS. (IMHO, this is still not obvious even in the post-interim clarified charter, BTW.) This has quite a big impact on what we write, at least. We still need a good name for this "thing we are signalling for", "resource" (and hence RMF) is a first guess. 'Service' seems to me to be too general. The key point which is special about NSIS is that the relevant resources are those which have to be provided by entities along the data path, but I can't think of a snappy term for that. The other impact is that we might need to broaden our thinking about how such a signalling protocol might fit into an overall solution to some resource management problem (hence my interest in Marcus' firewall draft). Certainly, the relationship between nsis and midcom/tist activities seems important to understand. Robert H. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 27 June 2002 10:10 > To: Zhigang.Kan@nokia.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] New framework draft: Resource Management Function > v.s. QoS Management Function > > > Hi Kan, > > > Resource Management Function is introduced in this draft as > > "RMF: an abstract concept, representing the management of > > resources in a domain or a node". I think that this > > definition is not appropriate for the aim of NSIS which is > > Signaling QoS, not Signaling resource. > > And if it is going to be perfectly in the sense of IETF, NSIS > is not only about QoS signaling, it is about service related > signaling in general. What about calling the above system > "Service Management Function"? > > Regards, Rüdiger > > > > Hi all, > > > > A group of us who were involved in past NSIS framework > > activities got together after the interim meeting to put > > together a joint framework document in the form of an all-new > > individual submission. It (roughly) follows the structure > > that was introduced and refined at that meeting. > > > > ============================================================== > > ============ > > Abstract > > > > The NSIS working group is considering protocol developments in > > signaling for resources for a traffic flow along its path in the > > network. The requirements for such signaling are being > > developed in a > > separate document; This Internet Draft proposes a framework for > > such signaling. This initial version provides a model for > > describing > > the entities that take part in the signaling and the > ways in which > > they can be used in different modes of operation. It also > > discusses > > the overall structure of such a signaling protocol. Finally, it > > considers the possible interactions of NSIS signaling with other > > protocols and functions, including security issues. > > ============================================================== > > ============ > > > > While it works its way through the i-d editor queue, you can > > find a copy here: > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > Comments are welcome. There is a list of open issue > > highlights in section 3. > > > > Cheers, > > > > Robert Hancock > > > > _______________________________________________ > > 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 Thu Jun 27 06:27: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 GAA08515 for ; Thu, 27 Jun 2002 06:27:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA18861 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 06:28: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 GAA18457; Thu, 27 Jun 2002 06:15:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18357 for ; Thu, 27 Jun 2002 06:15:00 -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 GAA08248 for ; Thu, 27 Jun 2002 06:14:13 -0400 (EDT) From: Zhigang.Kan@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 g5RAGmW09277 for ; Thu, 27 Jun 2002 13:16:48 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 13:14:57 +0300 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 13:14:57 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 18:13:53 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Thu, 27 Jun 2002 18:11:10 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD07E3C3@beebe001.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Thread-Index: AcIdwVaYqgKuJrzQQG6YIrPms1uEWAAAFOfw To: , Cc: X-OriginalArrivalTime: 27 Jun 2002 10:13:53.0854 (UTC) FILETIME=[573255E0:01C21DC3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id GAA18358 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, Maybe we don't care what term/name is called. The most important is that the "resources" and "resource management" should be defined exactly, and the relationship between resource and QoS should be clarified. Is RMF similar as BB? BR/Kan Zhigang -----Original Message----- From: ext Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: 2002å¹´6月27æ—¥ 17:47 To: 'Hancock, Robert' Cc: nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v. s. QoS Management Function Hi all I agree with the explanation given by Robert regarding RMF. I am in favor of keeping the term RMF. Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Thursday, June 27, 2002 11:39 AM To: 'Geib, Ruediger'; Zhigang.Kan@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function hi all, I think it's valuable for Zhigang to highlight the point, because this is one of the major changes in this NSIS framework input compared to (most?) previous ones (certainly the ones I have been involved in). One of the consequences of the email discussions around the time of the interim meeting (e.g. http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg01378.html) was that we should look at more general resources than just QOS. (IMHO, this is still not obvious even in the post-interim clarified charter, BTW.) This has quite a big impact on what we write, at least. We still need a good name for this "thing we are signalling for", "resource" (and hence RMF) is a first guess. 'Service' seems to me to be too general. The key point which is special about NSIS is that the relevant resources are those which have to be provided by entities along the data path, but I can't think of a snappy term for that. The other impact is that we might need to broaden our thinking about how such a signalling protocol might fit into an overall solution to some resource management problem (hence my interest in Marcus' firewall draft). Certainly, the relationship between nsis and midcom/tist activities seems important to understand. Robert H. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 27 June 2002 10:10 > To: Zhigang.Kan@nokia.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] New framework draft: Resource Management Function > v.s. QoS Management Function > > > Hi Kan, > > > Resource Management Function is introduced in this draft as > > "RMF: an abstract concept, representing the management of > > resources in a domain or a node". I think that this > > definition is not appropriate for the aim of NSIS which is > > Signaling QoS, not Signaling resource. > > And if it is going to be perfectly in the sense of IETF, NSIS > is not only about QoS signaling, it is about service related > signaling in general. What about calling the above system > "Service Management Function"? > > Regards, Rüdiger > > > > Hi all, > > > > A group of us who were involved in past NSIS framework > > activities got together after the interim meeting to put > > together a joint framework document in the form of an all-new > > individual submission. It (roughly) follows the structure > > that was introduced and refined at that meeting. > > > > ============================================================== > > ============ > > Abstract > > > > The NSIS working group is considering protocol developments in > > signaling for resources for a traffic flow along its path in the > > network. The requirements for such signaling are being > > developed in a > > separate document; This Internet Draft proposes a framework for > > such signaling. This initial version provides a model for > > describing > > the entities that take part in the signaling and the > ways in which > > they can be used in different modes of operation. It also > > discusses > > the overall structure of such a signaling protocol. Finally, it > > considers the possible interactions of NSIS signaling with other > > protocols and functions, including security issues. > > ============================================================== > > ============ > > > > While it works its way through the i-d editor queue, you can > > find a copy here: > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > Comments are welcome. There is a list of open issue > > highlights in section 3. > > > > Cheers, > > > > Robert Hancock > > > > _______________________________________________ > > 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 Thu Jun 27 06:52: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 GAA10456 for ; Thu, 27 Jun 2002 06:52:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA21943 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 06:53: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 GAA19824; Thu, 27 Jun 2002 06:39: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 GAA19791 for ; Thu, 27 Jun 2002 06:39: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 GAA08865; Thu, 27 Jun 2002 06:38:16 -0400 (EDT) Message-Id: <200206271038.GAA08865@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, 27 Jun 2002 06:38:15 -0400 Subject: [NSIS] I-D ACTION:draft-fu-rsvp-multicast-analysis-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 : Analysis on RSVP Regarding Multicast Author(s) : X. Fu, C. Kappler, H. Tschofenig Filename : draft-fu-rsvp-multicast-analysis-00.txt Pages : 17 Date : 26-Jun-02 RSVP version 1 has been designed for optimally support multicast. However, in reality multicast is being used much less frequently than anticipated. Still, even for unicast (one sender, one receiver) communication, full-fledged multicast-enabled RSVP signaling must be used. As pointed out in the NSIS requirement draft, multicast would not be necessarily required for an NSIS signaling protocol. This draft analyses ingredients of RSVP Version 1 which are affected by multicast, and derives how these ingredients may look like if multicast is not supported. We find removing multicast capability from RSVP will make it and its extensions considerably more light- weight. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-analysis-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-fu-rsvp-multicast-analysis-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-fu-rsvp-multicast-analysis-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: <20020626134547.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fu-rsvp-multicast-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-fu-rsvp-multicast-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626134547.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 Jun 27 06:55: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 GAA10520 for ; Thu, 27 Jun 2002 06:55:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22101 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 06:56: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 GAA19959; Thu, 27 Jun 2002 06:40: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 GAA19928 for ; Thu, 27 Jun 2002 06:40: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 GAA09194; Thu, 27 Jun 2002 06:39:42 -0400 (EDT) Message-Id: <200206271039.GAA09194@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, 27 Jun 2002 06:39:42 -0400 Subject: [NSIS] I-D ACTION:draft-hancock-nsis-fw-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 : Next Steps in Signaling: A Framework Proposal Author(s) : R. Hancock et al. Filename : draft-hancock-nsis-fw-00.txt Pages : 44 Date : 26-Jun-02 The NSIS working group is considering protocol developments in signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in a separate document [2]; This Internet Draft proposes a framework for such signaling. This initial version provides a model for describing the entities that take part in the signaling and the ways in which they can be used in different modes of operation. It also discusses the overall structure of such a signaling protocol. Finally, it considers the possible interactions of NSIS signaling with other protocols and functions, including security issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-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-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-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: <20020626134840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hancock-nsis-fw-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hancock-nsis-fw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626134840.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 Jun 27 06:58: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 GAA10623 for ; Thu, 27 Jun 2002 06:58:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22355 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 06:59: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 GAA21088; Thu, 27 Jun 2002 06:45: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 GAA21055 for ; Thu, 27 Jun 2002 06:45: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 GAA10011 for ; Thu, 27 Jun 2002 06:44:25 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 11:45:05 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3E5@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Zhigang.Kan@nokia.com'" , Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Thu, 27 Jun 2002 11:45:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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="utf-8" Content-Transfer-Encoding: quoted-printable Hi Zhigang, 'QoS' is one example of 'resource'. I'm actually not sure it is possible to define 'resource' precisely. = The basic point is that NSIS should provide a generally useful = signalling capability, which you could use for various types of = resource; exactly what types is going to be defined implicitly by = whether the NSIS capabilities are appropriate to the resource type = needs. In that sense, there's a benefit in vagueness. An RMF is absolutely not a BB. In our framework, "RMF" is just a name = for what NSIS offloads certain problems in resource management to, it's = a way to talk about the boundary of the NSIS problem space. NSIS = doesn't care how the RMF is implemented; it should be possible to = support both centralised and distributed resource management strategies = with the same NSIS protocol. The one thing that is ruled out = (initially) is NSIS signalling directly to a centralised (off-path) = entity; this is a consequence of recent scope guidance. Please see = especially section 5.1 of the draft (the hardest section to write, by = the way).=20 Yours, Robert H. > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: 27 June 2002 11:11 > To: Georgios.Karagiannis@eln.ericsson.se; Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS] New framework draft: Resource Management Function > v.s. QoS Management Function >=20 >=20 > Hi all, >=20 > Maybe we don't care what term/name is called. The most=20 > important is that the "resources" and "resource management"=20 > should be defined exactly, and the relationship between=20 > resource and QoS should be clarified. Is RMF similar as BB? >=20 > BR/Kan Zhigang >=20 > -----Original Message----- > From: ext Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 2002=E5=B9=B46=E6=9C=8827=E6=97=A5 17:47 > To: 'Hancock, Robert' > Cc: nsis@ietf.org > Subject: RE: [NSIS] New framework draft: Resource Management=20 > Function v. > s. QoS Management Function >=20 >=20 > Hi all >=20 > I agree with the explanation given by Robert regarding RMF. I am in > favor of keeping the term RMF. >=20 > Best Regards, > Georgios >=20 > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Thursday, June 27, 2002 11:39 AM > To: 'Geib, Ruediger'; Zhigang.Kan@nokia.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] New framework draft: Resource Management Function > v.s. QoS Management Function >=20 >=20 > hi all, >=20 > I think it's valuable for Zhigang to highlight the point,=20 > because this is one of the major changes in this NSIS=20 > framework input compared to (most?) previous ones (certainly=20 > the ones I have been involved in). One of the consequences of=20 > the email discussions around the time of the interim meeting=20 > (e.g.=20 > http://www1.ietf.org/mail-archive/working-groups/nsis/current/ > msg01378.html) was that we should look at more general=20 > resources than just QOS. (IMHO, this is still not obvious=20 > even in the post-interim clarified charter, BTW.) >=20 > This has quite a big impact on what we write, at least. We=20 > still need a good name for this "thing we are signalling=20 > for", "resource" (and hence RMF) is a first guess. 'Service'=20 > seems to me to be too general. The key point which is special=20 > about NSIS is that the relevant resources are those which=20 > have to be provided by entities along the data path, but I=20 > can't think of a snappy term for that. >=20 > The other impact is that we might need to broaden our=20 > thinking about how such a signalling protocol might fit into=20 > an overall solution to some resource management problem=20 > (hence my interest in Marcus' firewall draft). Certainly, the=20 > relationship between nsis and midcom/tist activities seems=20 > important to understand. >=20 > Robert H. >=20 > > -----Original Message----- > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > Sent: 27 June 2002 10:10 > > To: Zhigang.Kan@nokia.com > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: Resource=20 > Management Function > > v.s. QoS Management Function > >=20 > >=20 > > Hi Kan, > >=20 > > > Resource Management Function is introduced in this draft as=20 > > > "RMF: an abstract concept, representing the management of=20 > > > resources in a domain or a node". I think that this=20 > > > definition is not appropriate for the aim of NSIS which is=20 > > > Signaling QoS, not Signaling resource.=20 > >=20 > > And if it is going to be perfectly in the sense of IETF, NSIS=20 > > is not only about QoS signaling, it is about service related=20 > > signaling in general. What about calling the above system=20 > > "Service Management Function"? > >=20 > > Regards, R=C3=BCdiger > >=20 > > =20 > > > Hi all, > > >=20 > > > A group of us who were involved in past NSIS framework=20 > > > activities got together after the interim meeting to put=20 > > > together a joint framework document in the form of an all-new=20 > > > individual submission. It (roughly) follows the structure=20 > > > that was introduced and refined at that meeting. > > >=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Abstract=20 > > > =20 > > > The NSIS working group is considering protocol developments in = > > > signaling for resources for a traffic flow along its=20 > path in the=20 > > > network. The requirements for such signaling are being=20 > > > developed in a=20 > > > separate document; This Internet Draft proposes a=20 > framework for=20 > > > such signaling. This initial version provides a model for=20 > > > describing=20 > > > the entities that take part in the signaling and the=20 > > ways in which=20 > > > they can be used in different modes of operation. It also=20 > > > discusses=20 > > > the overall structure of such a signaling protocol.=20 > Finally, it=20 > > > considers the possible interactions of NSIS signaling=20 > with other=20 > > > protocols and functions, including security issues.=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > While it works its way through the i-d editor queue, you can=20 > > > find a copy here: > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > >=20 > > > Comments are welcome. There is a list of open issue=20 > > > highlights in section 3. > > >=20 > > > Cheers, > > >=20 > > > Robert Hancock > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 --------------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 Thu Jun 27 07:08: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 HAA10944 for ; Thu, 27 Jun 2002 07:08:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA23412 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 07:09: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 GAA22032; Thu, 27 Jun 2002 06:54: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 GAA21999 for ; Thu, 27 Jun 2002 06:54:49 -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 GAA10493 for ; Thu, 27 Jun 2002 06:54:04 -0400 (EDT) From: Zhigang.Kan@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 g5RAubW27575 for ; Thu, 27 Jun 2002 13:56:37 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 13:54:47 +0300 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 13:54:46 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 18:54:35 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Thu, 27 Jun 2002 18:52:39 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD07E3C4@beebe001.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft Thread-Index: AcIbdekvFiYAcFWvQ8qMwOB4nmRVTgCTgP5Q To: , X-OriginalArrivalTime: 27 Jun 2002 10:54:35.0206 (UTC) FILETIME=[065B1660:01C21DC9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id GAA22000 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, In the draft about In-Band & Out-of-Band: "In-band signaling means that the path followed by the user data packets is the same as the path followed by signaling messages. In other words, the signaling and data paths are identical. Out-of-band signaling means that the path followed by signaling messages might be different from the path used by the user data packets. " So in-band signaling is same as RSVP's operation mode? And must it install soft states in each router it passed through based on per-flow or per-class-flow? I think that it may be better if in-band signaling is used in access network and out-of-band signaling is used in backbone networks (i.e. the out-of-band signaling is used for communcation between RMFs which are responsible for the "resource" management independent of concrete user traffic in control plane). Is resource reservation really needed in backbone network now or in the future? I don't know why "the initial goal of NSIS is to concentrate mainly on the in-band case". BR/Kan Zhigang -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 2002å¹´6月24æ—¥ 19:47 To: NSIS Subject: [NSIS] New framework draft Hi all, A group of us who were involved in past NSIS framework activities got together after the interim meeting to put together a joint framework document in the form of an all-new individual submission. It (roughly) follows the structure that was introduced and refined at that meeting. ========================================================================== Abstract The NSIS working group is considering protocol developments in signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in a separate document; This Internet Draft proposes a framework for such signaling. This initial version provides a model for describing the entities that take part in the signaling and the ways in which they can be used in different modes of operation. It also discusses the overall structure of such a signaling protocol. Finally, it considers the possible interactions of NSIS signaling with other protocols and functions, including security issues. ========================================================================== While it works its way through the i-d editor queue, you can find a copy here: http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt Comments are welcome. There is a list of open issue highlights in section 3. Cheers, Robert Hancock _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 27 07:15: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 HAA11247 for ; Thu, 27 Jun 2002 07:15:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA24012 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 07:16: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 HAA22936; Thu, 27 Jun 2002 07:02: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 HAA22896 for ; Thu, 27 Jun 2002 07:02:15 -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 HAA10720 for ; Thu, 27 Jun 2002 07:01:30 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 12:02:11 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3E6@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Zhigang.Kan@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Thu, 27 Jun 2002 12:02:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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="utf-8" Content-Transfer-Encoding: quoted-printable Hi Zhigang, Please see inline: > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: 27 June 2002 11:53 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band >=20 >=20 > Hi,=20 >=20 > In the draft about In-Band & Out-of-Band: >=20 > "In-band signaling means that the path followed by the user=20 > data packets is the same as the path followed by signaling=20 > messages. In other words, the signaling and data paths are=20 > identical. Out-of-band signaling means that the path followed=20 > by signaling messages might be different from the path used=20 > by the user data packets. " >=20 > So in-band signaling is same as RSVP's operation mode?=20 [reh] basically yes, from a topological ("where the messages go") point = of view.=20 > And=20 > must it install soft states in each router it passed through=20 > based on per-flow or per-class-flow? [reh] that's one reasonable way for it to work. see 4.4 about general = state management issues; there are several different sorts of state and = several different ways to manage them. and some of the state management = is an RMF responsibility. > I think that it may be=20 > better if in-band signaling is used in access network and=20 > out-of-band signaling is used in backbone networks (i.e. the=20 > out-of-band signaling is used for communcation between RMFs=20 > which are responsible for the "resource" management=20 > independent of concrete user traffic in control plane). Is=20 > resource reservation really needed in backbone network now or=20 > in the future?=20 [reh] that's a good question. however, in our framework we tried hard = to avoid saying that NSIS would work in particular ways in particular = network parts. (ideally, I think there should be implementation and = deployment flexibility within the protocol to allow this.) >=20 > I don't know why "the initial goal of NSIS is to concentrate=20 > mainly on the in-band case".=20 [reh] that's a WG chair/AD question. >=20 > BR/Kan Zhigang Cheers, Robert H. >=20 > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 2002=E5=B9=B46=E6=9C=8824=E6=97=A5 19:47 > To: NSIS > Subject: [NSIS] New framework draft >=20 >=20 > Hi all, >=20 > A group of us who were involved in past NSIS framework=20 > activities got together after the interim meeting to put=20 > together a joint framework document in the form of an all-new=20 > individual submission. It (roughly) follows the structure=20 > that was introduced and refined at that meeting. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Abstract=20 > =20 > The NSIS working group is considering protocol developments in=20 > signaling for resources for a traffic flow along its path in the=20 > network. The requirements for such signaling are being=20 > developed in a=20 > separate document; This Internet Draft proposes a framework for=20 > such signaling. This initial version provides a model for=20 > describing=20 > the entities that take part in the signaling and the ways in which = > they can be used in different modes of operation. It also=20 > discusses=20 > the overall structure of such a signaling protocol. Finally, it=20 > considers the possible interactions of NSIS signaling with other=20 > protocols and functions, including security issues.=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > While it works its way through the i-d editor queue, you can=20 > find a copy here: > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt >=20 > Comments are welcome. There is a list of open issue=20 > highlights in section 3. >=20 > Cheers, >=20 > Robert Hancock >=20 --------------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 Thu Jun 27 07:26: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 HAA11634 for ; Thu, 27 Jun 2002 07:26:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA24671 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 07:27: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 HAA23264; Thu, 27 Jun 2002 07:07: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 HAA23225 for ; Thu, 27 Jun 2002 07:07:43 -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 HAA10846 for ; Thu, 27 Jun 2002 07:06:58 -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 g5RB89i16190 for ; Thu, 27 Jun 2002 14:08:09 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 14:07:40 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 14:07: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="utf-8" Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Thu, 27 Jun 2002 14:07:30 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65576@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft Thread-Index: AcIbdekvFiYAcFWvQ8qMwOB4nmRVTgCTgP5QAAGxHaA= To: , , X-OriginalArrivalTime: 27 Jun 2002 11:07:40.0556 (UTC) FILETIME=[DA75FCC0:01C21DCA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id HAA23226 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 Kan, > I don't know why "the initial goal of NSIS is to concentrate > mainly on the in-band case". This was part of the chartering process. NSIS is chartered to solve in-band signaling. Out of band signaling needs could be documented, but it is doubtful that NSIS will try to solve out-of-band signaling, or at least not until there is rechartering of the WG. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 27 07:27: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 HAA11664 for ; Thu, 27 Jun 2002 07:27:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA24697 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 07:28: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 HAA23851; Thu, 27 Jun 2002 07:14: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 HAA23819 for ; Thu, 27 Jun 2002 07:14: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 HAA11172 for ; Thu, 27 Jun 2002 07:13:30 -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 g5RBEgi20683 for ; Thu, 27 Jun 2002 14:14:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 14:14:13 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 14:14:13 +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] New framework draft: Resource Management Function v.s. QoS Management Function Date: Thu, 27 Jun 2002 14:14:12 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E80@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft Thread-Index: AcIbdekvFiYAcFWvQ8qMwOB4nmRVTgCOwDygAAaHSNA= To: , , X-OriginalArrivalTime: 27 Jun 2002 11:14:13.0233 (UTC) FILETIME=[C483BE10:01C21DCB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id HAA23821 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 Kan, > Resource Management Function is introduced in this draft as > "RMF: an abstract concept, representing the management of > resources in a domain or a node". I think that this > definition is not appropriate for the aim of NSIS which is > Signaling QoS, not Signaling resource. QoS Management > Functioin (QMF) is suggested to be used because QMF includes > RMF besides QoS Control, QoS provisioning, QoS policy, QoS > mapping, QoS monitoring, etc.. The problem about QoS is, noone knows exactly what it is. NSIS could potentially be used to install filters in a firewall, for example. There is some interest in using NSIS for NAT traversal. Finally, NSIS should be agnostic about exactly what is being signaled for, therefore I think Resource is better. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 27 07:30: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 HAA11779 for ; Thu, 27 Jun 2002 07:30:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25005 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 07:31: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 HAA24155; Thu, 27 Jun 2002 07:16: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 HAA24128 for ; Thu, 27 Jun 2002 07:16: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 HAA11282 for ; Thu, 27 Jun 2002 07:16:03 -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 g5RBHEi22357 for ; Thu, 27 Jun 2002 14:17:14 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 14:16:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 14:16: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="utf-8" Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Thu, 27 Jun 2002 14:16:44 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65578@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Thread-Index: AcIdwVaYqgKuJrzQQG6YIrPms1uEWAAAFOfwAAKVfPA= To: , , Cc: X-OriginalArrivalTime: 27 Jun 2002 11:16:45.0493 (UTC) FILETIME=[1F44C650:01C21DCC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id HAA24129 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 Kan, > Maybe we don't care what term/name is called. The most > important is that the "resources" and "resource management" > should be defined exactly, and the relationship between > resource and QoS should be clarified. Is RMF similar as BB? RMF is a generic term, it is not a BB - it could be a simple function that only does access control, or it could be a BB. It is out of scope of NSIS to deterime exactly what the RMF is. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 27 09:54: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 JAA18569 for ; Thu, 27 Jun 2002 09:54:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07404 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 09: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 JAA06218; Thu, 27 Jun 2002 09:36: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 JAA06188 for ; Thu, 27 Jun 2002 09:36:08 -0400 (EDT) Received: from mail.icu.ac.kr (mail.icu.ac.kr [210.107.128.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17777 for ; Thu, 27 Jun 2002 09:35:23 -0400 (EDT) Received: from gmlee (v33-146.icu.ac.kr [210.107.133.146]) by mail.icu.ac.kr (8.11.6/8.11.6) with SMTP id g5RDcQr24938 for ; Thu, 27 Jun 2002 22:38:26 +0900 (KST) Message-ID: <012001c21ddf$67539a80$92856bd2@gmlee> From: "Gyu Myoung Lee" To: References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65583@esebe004.NOE.Nokia.com> <011501c21ddf$038203c0$92856bd2@gmlee> Date: Thu, 27 Jun 2002 22:34:46 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id JAA06189 Subject: [NSIS] draft on features of IPv6 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 We have updated the draft on features of IPv6 signaling and submitted the new version to the IETF with the following abstract; In this draft, we describe the features and requirements of IPv6 signaling protocol and explain the needs of QoS signaling in IPv6 network. We also explain mapping of IPv6 signaling with IPv4 in some detail. This draft was revised as follows - added the requirements of QoS signaling protocol in IPv6 network (section 2.4) - added mapping of IPv6 signaling with IPv4 (section 3) - Appendix. The delivering methods of signaling messages in IPv6 network (specifying solution is moved into appendix) You can see it from http://opticalip.icu.ac.kr/draft-choi-ipv6-signaling-02.txt All comments are apprecieated very much. Regards, Gyu Myoung Lee _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 27 10:26: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 KAA20237 for ; Thu, 27 Jun 2002 10:26:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09689 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 10: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 KAA08717; Thu, 27 Jun 2002 10:09: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 KAA08688 for ; Thu, 27 Jun 2002 10:09:19 -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 KAA19419 for ; Thu, 27 Jun 2002 10:08:34 -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 g5RE8mdg014552; Thu, 27 Jun 2002 07:08:48 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEG89748; Thu, 27 Jun 2002 07:05:54 -0700 (PDT) Message-Id: <5.1.0.14.0.20020627095502.0568c040@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Jun 2002 10:08:42 -0400 To: "Hancock, Robert" , nsis@ietf.org From: Melinda Shore In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA3E2@rsys002a.roke.co.uk > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [NSIS] Re: discovery & authorisation requirements (was: RE: [NSIS] draft on middlebox communication and 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 At 08:47 AM 6/27/02 +0100, Hancock, Robert wrote: >I'm just not sure how many alternatives NSIS should try to investigate. I'm certainly not interested in developing a general purpose "let's go out and find all the middleboxes in the Internet" solution, and I don't think anyone else is proposing that either. No, certainly not - aside from the topology problems I've discussed, network operators typically do not want to make known the location of their firewalls. >Bigger point: it would clearly be nice if we could make 'what NSIS does' adaptive to network changes to the same extent that packet routing is. What I think I'm getting at here is the ability to allow applications to adapt to changes in network state, if needed. Consider two very different cases - firewalls and NATs. The sender periodically sends out idempotent Path messages that possibly are either signed or have some other sort of authentication mechanism. A routing change forces packets to traverse a new middlebox (i.e. one not on the original path). In the firewall case adaptation is pretty straightforward - the firewall authenticates the message (introducing new state - I would never suggest simply moving the state [although there are some interesting group keying possibilities evolving as that work progresses]) and opens the new pinhole (or not). In the NAT case in addition to adding new authentication/security state, the contents of the Resv message that are returned to the sender have changed. That is to say, the address at which the sender is seen by the receiver has changed. With that piece of information here is an opportunity for the application to adapt (although I think it highly unlikely that this kind of capability will creep into, say VoIP protocols). I would never suggest that it's the responsibility of the signaling system to do anything but carry the new address back to the sender. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 27 10:45: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 KAA21280 for ; Thu, 27 Jun 2002 10:45:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12120 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 10:45: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 KAA09541; Thu, 27 Jun 2002 10:25: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 KAA09447 for ; Thu, 27 Jun 2002 10:25:11 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20127 for ; Thu, 27 Jun 2002 10:24:26 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g5RELB807585 for ; Thu, 27 Jun 2002 16:21:11 +0200 To: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 27 Jun 2002 16:24:35 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 06/27/2002 16:24:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-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 Hi all, As a result of discussions at the interim meeting we put together a separate document on nsis resilience. It tries to list issues brought up at the interim meeting together with some new ones in a broader general scope. The document has finally made it through to the IETF repository. Some people have expressed interest during the interim meeting, so hopefully the document can help in structuring the discussion. Best regards, Sven ---------------------- Forwarded by Sven VAN DEN BOSCH/BE/ALCATEL on 27/06/2002 16:19 --------------------------- Internet-Drafts@ietf.org@cnri.reston.va.us on 27/06/2002 12:39:37 Please respond to Internet-Drafts@ietf.org Sent by: nsyracus@cnri.reston.va.us To: IETF-Announce: ; cc: Subject: I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NSIS resilience analysis Author(s) : S. Van den Bosch, M. Buchli Filename : draft-vandenbosch-nsis-resilience-00.txt Pages : 11 Date : 26-Jun-02 The Next Steps in Signaling (NSIS) working group is chartered to develop requirements, architecture and protocols for the next IETF steps in signaling Quality-of-Service (QoS). Although the NSIS protocol may eventually be used for other applications in addition to QoS, it is expected that these, in much the same way as QoS, will depend on predictable and high-availability service delivery. This document attempts to identify, list and classify potential resilience issues for the NSIS protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-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-vandenbosch-nsis-resilience-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-vandenbosch-nsis-resilience-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. ftp://ftp.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 27 12:15: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 MAA28387 for ; Thu, 27 Jun 2002 12:15:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23274 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 12:16: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 LAA20117; Thu, 27 Jun 2002 11:55: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 LAA20088 for ; Thu, 27 Jun 2002 11:55: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 LAA26283 for ; Thu, 27 Jun 2002 11:54:21 -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 g5RFt0rU003482; Thu, 27 Jun 2002 17:55:00 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHMT117K; Thu, 27 Jun 2002 17:55:00 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 17:54:59 +0200 Message-ID: X-Sybari-Trust: 5f8de42a 7216406a 0b6f7280 00000138 From: "Georgios Karagiannis (ELN)" To: "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Date: Thu, 27 Jun 2002 17:54:58 +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 I will only comment your draft starting from Section 5. Main comment that I have is related to the fact that you somehow emphasise that the per-class states complicate the failure notification and recovery issues, while I think that failure notification and recovery issues are independent of the type of these states. Another comment is related to the fact that you use a limted number of solutions, as the NSIS solutions, while these solutions might be just examples. See more comments in line with your text (copied from your draft). My comments are given betrween <<>>. Best regards, Georgios ------------ 5. Failure description 5.1. Internal data plane failures Data plane failures can result from the breakdown or misconfiguration of data path entities such as routers or links. In case of a router, the failure can be due to a power outage, a software crash or hardware failure, e.g. interface cards. Link failures can be due to defective interface cards or to lower layer failures such as cable cuts. We make a distinction between data plane failures that are internal to a QoS domain and failures at the edges of a QoS domain (In case of a QoS domain consisting of a single router, an internal failure can occur when a component link in a link bundle attached to the router fails). Internal data plane failures should be solved locally and should not involve NSIS signalling when succesful. << [georgios] What do you mean here? Do you mean that Internal data plane features should not involve NSIS 'signalling when sucessfull. Some of the NSIS modes of operation should be able to apply NSIS signaling for internal data plane failure.>> 5.2. External data plane failures Edge failures can for instance occur when an Autonomous System Border Router (ASBR) or the link between two ASBRs goes down. Recovery from this type of failures requires a coordinated action between two or more QoS domains and will therefore impact NSIS signalling. <<[georgios] probably you can find other terms than Autonomous System.>> 5.3. Control plane failures Two main types of control plane failures are distinguished: - Failure of an NSIS entity, e.g. a QI, QC or QR failure. If the QI is located at the end host, the end host is also considered to be part of the control plane of the NSIS signalling. - Loss of signalling messages between NSIS entities << [georgios] Please chnage terminology according to the new [hancock - framework] >> 5.4. QoS degradation A failure does not necessarily have to equal a loss of connectivity. In a QoS-enabled environment, a degradation of the perceived performance on the data path can also be categorised as a failure. It may be important to distinguish these failures from a 'hard' failure (involving loss of connectivity) in order to support hierarchical protection. << [georgios] This is a policing matter! is not a failure>> 6. Recovery issues 6.1. Failure detection In the data plane, node failures can be detected from the absence of hello messages from the Interior Gateway Protocol (IGP). Link failure indications can usually be derived from of lower-layer failure indications (loss of light, loss of signal). In case of logical links, failure detection can be more problematic and must either take place via the hello protocol or via a specific OAM procedure. << [georgios] Well other means could be used. Please do not restrict it only to this solution. Mention this as an example, please include other references, e.g., [RMD] >> In the control plane, NSIS failure detection involves the following issues: - When the QI is different from the end host, QI and end host need to be aware of each others failures. Two factors can complicate this problem. First, the QI may keep hard-state related to the end-host requests because the overhead of refreshes is deemed excessive. In this case, state refreshes can not be used as a failure detection mechanism. Second, the end host is not necessarily an NSIS speaker, which means that the detection mechanism must be supported outside of NSIS signalling. One potential solution is the use of higher and or lower layer triggers in the QI. This means that the QI should have higher/lower layer information available. << [georgios] is this related to out of band? Is this within NSIS scope?>> - When an NSIS entity is protected by a backup entity, a synchronisation failure between the two entities needs to be detected prior to the protection switch. Since both entities will be NSIS speakers, this functionality could be implemented in the NSIS protocol. << [georgios] Is this within NSIS scope??>> - In case of hop-by-hop routing of the NSIS signalling messages, a failure detection mechanism is required in NSIS, even when the communication between NSIS entities is done with a reliable transport mechanism. This is caused by the fact that the transport signalling is terminated at each NSIS hop. This means that messages can be lost in an NSIS entity without the transport layer noticing it. 6.2. Failure notification Any failure notification needed in the data plane, e.g. from lower layers, should normally be transparent to NSIS. An issue can arise for external failures. <<[georgios] I do not understand this??>> - If a failure of an external link or node is detected, a route change might be required in order to perform the recovery action. In that case, the failure should be notified to the QI if only per- class state is kept in the QC. <<[georgios] do you mean here external to a NSIS domain. If yes, why the failure notification is only needed when per-class state is kept? I think that this is independent of the type of reservation state. >> For control plane failures, an issue might arise when only per-class state is kept. << I do not agree with this, why?>> - When only per-class state is kept, which might for instance occur in a QC in order to reduce information storage, the QC cannot reroute the LSP without a message from the QI. << What do you mean with reroute! Is this within NSIS scope?>> This means that this situation is only feasible in combination with soft-state. In that case, the QC needs to notify the QI about the failure in response to the next refresh message, that therefore needs to contain an identification of the QI. - The failing reservation may be part of a service consisting of multiple such flows. An obvious example is a bi-directional service. It would seem appropriate for each flow to be protected separately and for the service not to be impacted when the protection action is successful. However, it would make little sense to keep one direction up when the other goes down. This would imply notification of the QI/QR of the flows making up the service in case of unsuccessful protection. 6.3. Recovery action The definition of a recovery strategy typically involves a decision on: - the scope of the protection action: this can be end-to-end path protection or local segment protection. We have already seen that the use of per-class state in the QC will prevent the application of local segment protection for external failures. <<[georgios] I do not understand this statement reagrding per class states>> - the timing of the protection action: protection paths can be pre- computed and pre-established in which case only a switch from primary to protection path is needed when a failure occurs. If the computation and/or establishment of the protection path is started after failure detection (rerouting), an additional recovery delay is introduced. <<[georgios] is routing also included in the NSIS scope?>> - resource allocation on the protection paths: resource reservation on protection paths prior to failure is very inefficient and leads to excessive usage of network capacity for protection purposes. This can be avoided by not reserving capacity on the protection path. In this case, however, the availability of the protection path can not be guaranteed when a failure occurs. Alternatively, protection capacity can be shared between protection paths that are unlikely to fail simultaneously. For this, a limited number of failure scenarios (e.g. single node or single link failures) is assumed. Sharing protection capacity is highly complicated by the interdomain scope of the NSIS signalling because of the lack of detailed information on the failure states and the primary path. << [georgios] Is this the only solution?>> Recovery on the control plane may involve any of the following issues: - If a failure can only be solved by means of a change of the interdomain path of the flow, the QC might be required to force a route change from the QI. << [georgios] Should this be done by NSIS; It is out of scope of NSIS >> Note that this can occur without any data plane failure when the QC of a QoS domain fails and the QCs of neighbouring domains want to bring up peering relations with QCs that are not realted to the next hop on the data path. - When only per-class state is kept in a QC and a setup message is lost, retransmission of the setup message may cause duplicate reservations in QoS domains upstream of the point where the loss occurred. In case of soft-state, this situation will last for several refresh intervals. Note that the impact of this type of failure can be restricted by the use of reliable transport between NSIS entities. <<[georgios] It can be solved by using explicit release messages, see RMD frmaework>> - In case of a QI or QR failure, the QC immediately following or preceding the failing entity may need to take up some proxy functionality for the failing entity. This functionality is optional for sending out teardown messages when soft-state is used, but mandatory for hard-state. It is also mandatory for replying to teardown messages, e.g. originating from the QI. - If the QoS Initiator does not receive a response on a signaling message within a certain time interval it will consider it as lost. It may decide to retransmit the signaling message. Therefore, the QoS Initiator must be able to make sure that the received ACK is not a delayed ACK from the previous transmitted signaling message. The signaling messages should therefore include a sequence number in order to associate a request (NEW, TEAR, REFRESH) with a response (ACK, NACK). <<[georgios] When soft state refresh is used, the TEAr messages do not neet to be authenticated>> 7. Reversion issues 7.1. Repair detection No issues are identified for the data plane. For the control plane, repair detection will most likely occur by means of discovery messages initiated by the repaired NSIS entity. It is proposed that this discovery process could be a preliminary phase prior to the NSIS protocol and can therefore remain out of its scope. It is nevertheless crucial that such a discovery protocol is standardised in order to allow NSIS entities from different vendors to discover each other. <<[georgios] I think that is out of scope of NSIS>> 7.2. Repair notification Repair notification will normally take place by means of the IGP in the data plane. In the control plane, repair notification may be needed when a QC has taken up some proxy functionality for the QI or QC. However, no special action should be needed for this since this information can be inferred from the repair detection. <<[georgios] If repair detection is out of scope will this also be out of NSIS scope>> 7.3. Reversion action On the data plane, reversion is unavoidable when in-band signaling is used because the signaling messages will follow the new data plane route. This might cause issues because resources are typically not reserved on the new route, which might cause (temporary) QoS degradation on the new route. <<[georgios] What is the reversion action about? Is this related to the severe congestion problem explained in the NSIS requirements draft?>> In case of out-of-band signaling reversion may be avoided by means of route pinning. However, it will usually be advantageous to move to a more favourable route when one becomes available, both from a performance and resource utilisation point of view. In that case, the separation of data plane and control plane might help delaying the route change until sufficient resources are reserved on the new path. From a control plane perspective, reversion makes little sense when backup NSIS entities are used. In that case, the reversion action will be limited to a synchronisation with the currently active NSIS entity. The repaired entity will then become the backup. <<[georgios] Is out of band out of NSIS scope? -------------------------------------------------------------------------------------------------- -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: Thursday, June 27, 2002 4:25 PM To: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Hi all, As a result of discussions at the interim meeting we put together a separate document on nsis resilience. It tries to list issues brought up at the interim meeting together with some new ones in a broader general scope. The document has finally made it through to the IETF repository. Some people have expressed interest during the interim meeting, so hopefully the document can help in structuring the discussion. Best regards, Sven ---------------------- Forwarded by Sven VAN DEN BOSCH/BE/ALCATEL on 27/06/2002 16:19 --------------------------- Internet-Drafts@ietf.org@cnri.reston.va.us on 27/06/2002 12:39:37 Please respond to Internet-Drafts@ietf.org Sent by: nsyracus@cnri.reston.va.us To: IETF-Announce: ; cc: Subject: I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NSIS resilience analysis Author(s) : S. Van den Bosch, M. Buchli Filename : draft-vandenbosch-nsis-resilience-00.txt Pages : 11 Date : 26-Jun-02 The Next Steps in Signaling (NSIS) working group is chartered to develop requirements, architecture and protocols for the next IETF steps in signaling Quality-of-Service (QoS). Although the NSIS protocol may eventually be used for other applications in addition to QoS, it is expected that these, in much the same way as QoS, will depend on predictable and high-availability service delivery. This document attempts to identify, list and classify potential resilience issues for the NSIS protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-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-vandenbosch-nsis-resilience-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-vandenbosch-nsis-resilience-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. ftp://ftp.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jun 27 12:18: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 MAA28555 for ; Thu, 27 Jun 2002 12:18:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23481 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 12:19: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 MAA22494; Thu, 27 Jun 2002 12:04: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 MAA22461 for ; Thu, 27 Jun 2002 12:04:40 -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 MAA27262 for ; Thu, 27 Jun 2002 12:03:54 -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 g5RG4SrU005153; Thu, 27 Jun 2002 18:04:28 +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 NHMT1H6M; Thu, 27 Jun 2002 18:04:28 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 18:00:26 +0200 Message-ID: X-Sybari-Trust: 4bbcb78a 7216406a 0b6f7280 00000138 From: "Georgios Karagiannis (ELN)" To: "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org Subject: Correction on comment Sec. 6.3 RE: [NSIS] I-D ACTION:draft-vanden bosch-nsis-resilience-00.txt Date: Thu, 27 Jun 2002 18:04:25 +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, A correction on a comment that I had sent in a previous e-mail for section 6.3 of draft: draft-vandenbosch-nsis-resilience-00.txt In place of: <<[georgios] When soft state refresh is used, the Tear messages do not need to be authenticated>> I meant: <<[georgios] When soft state refresh is used, the Tear messages do not need to be acknowledged>> Best Regards, Georgios -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Thursday, June 27, 2002 5:55 PM To: 'sven.van_den_bosch@alcatel.be'; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Hi Sven I will only comment your draft starting from Section 5. Main comment that I have is related to the fact that you somehow emphasise that the per-class states complicate the failure notification and recovery issues, while I think that failure notification and recovery issues are independent of the type of these states. Another comment is related to the fact that you use a limted number of solutions, as the NSIS solutions, while these solutions might be just examples. See more comments in line with your text (copied from your draft). My comments are given betrween <<>>. Best regards, Georgios ------------ 5. Failure description 5.1. Internal data plane failures Data plane failures can result from the breakdown or misconfiguration of data path entities such as routers or links. In case of a router, the failure can be due to a power outage, a software crash or hardware failure, e.g. interface cards. Link failures can be due to defective interface cards or to lower layer failures such as cable cuts. We make a distinction between data plane failures that are internal to a QoS domain and failures at the edges of a QoS domain (In case of a QoS domain consisting of a single router, an internal failure can occur when a component link in a link bundle attached to the router fails). Internal data plane failures should be solved locally and should not involve NSIS signalling when succesful. << [georgios] What do you mean here? Do you mean that Internal data plane features should not involve NSIS 'signalling when sucessfull. Some of the NSIS modes of operation should be able to apply NSIS signaling for internal data plane failure.>> 5.2. External data plane failures Edge failures can for instance occur when an Autonomous System Border Router (ASBR) or the link between two ASBRs goes down. Recovery from this type of failures requires a coordinated action between two or more QoS domains and will therefore impact NSIS signalling. <<[georgios] probably you can find other terms than Autonomous System.>> 5.3. Control plane failures Two main types of control plane failures are distinguished: - Failure of an NSIS entity, e.g. a QI, QC or QR failure. If the QI is located at the end host, the end host is also considered to be part of the control plane of the NSIS signalling. - Loss of signalling messages between NSIS entities << [georgios] Please chnage terminology according to the new [hancock - framework] >> 5.4. QoS degradation A failure does not necessarily have to equal a loss of connectivity. In a QoS-enabled environment, a degradation of the perceived performance on the data path can also be categorised as a failure. It may be important to distinguish these failures from a 'hard' failure (involving loss of connectivity) in order to support hierarchical protection. << [georgios] This is a policing matter! is not a failure>> 6. Recovery issues 6.1. Failure detection In the data plane, node failures can be detected from the absence of hello messages from the Interior Gateway Protocol (IGP). Link failure indications can usually be derived from of lower-layer failure indications (loss of light, loss of signal). In case of logical links, failure detection can be more problematic and must either take place via the hello protocol or via a specific OAM procedure. << [georgios] Well other means could be used. Please do not restrict it only to this solution. Mention this as an example, please include other references, e.g., [RMD] >> In the control plane, NSIS failure detection involves the following issues: - When the QI is different from the end host, QI and end host need to be aware of each others failures. Two factors can complicate this problem. First, the QI may keep hard-state related to the end-host requests because the overhead of refreshes is deemed excessive. In this case, state refreshes can not be used as a failure detection mechanism. Second, the end host is not necessarily an NSIS speaker, which means that the detection mechanism must be supported outside of NSIS signalling. One potential solution is the use of higher and or lower layer triggers in the QI. This means that the QI should have higher/lower layer information available. << [georgios] is this related to out of band? Is this within NSIS scope?>> - When an NSIS entity is protected by a backup entity, a synchronisation failure between the two entities needs to be detected prior to the protection switch. Since both entities will be NSIS speakers, this functionality could be implemented in the NSIS protocol. << [georgios] Is this within NSIS scope??>> - In case of hop-by-hop routing of the NSIS signalling messages, a failure detection mechanism is required in NSIS, even when the communication between NSIS entities is done with a reliable transport mechanism. This is caused by the fact that the transport signalling is terminated at each NSIS hop. This means that messages can be lost in an NSIS entity without the transport layer noticing it. 6.2. Failure notification Any failure notification needed in the data plane, e.g. from lower layers, should normally be transparent to NSIS. An issue can arise for external failures. <<[georgios] I do not understand this??>> - If a failure of an external link or node is detected, a route change might be required in order to perform the recovery action. In that case, the failure should be notified to the QI if only per- class state is kept in the QC. <<[georgios] do you mean here external to a NSIS domain. If yes, why the failure notification is only needed when per-class state is kept? I think that this is independent of the type of reservation state. >> For control plane failures, an issue might arise when only per-class state is kept. << I do not agree with this, why?>> - When only per-class state is kept, which might for instance occur in a QC in order to reduce information storage, the QC cannot reroute the LSP without a message from the QI. << What do you mean with reroute! Is this within NSIS scope?>> This means that this situation is only feasible in combination with soft-state. In that case, the QC needs to notify the QI about the failure in response to the next refresh message, that therefore needs to contain an identification of the QI. - The failing reservation may be part of a service consisting of multiple such flows. An obvious example is a bi-directional service. It would seem appropriate for each flow to be protected separately and for the service not to be impacted when the protection action is successful. However, it would make little sense to keep one direction up when the other goes down. This would imply notification of the QI/QR of the flows making up the service in case of unsuccessful protection. 6.3. Recovery action The definition of a recovery strategy typically involves a decision on: - the scope of the protection action: this can be end-to-end path protection or local segment protection. We have already seen that the use of per-class state in the QC will prevent the application of local segment protection for external failures. <<[georgios] I do not understand this statement reagrding per class states>> - the timing of the protection action: protection paths can be pre- computed and pre-established in which case only a switch from primary to protection path is needed when a failure occurs. If the computation and/or establishment of the protection path is started after failure detection (rerouting), an additional recovery delay is introduced. <<[georgios] is routing also included in the NSIS scope?>> - resource allocation on the protection paths: resource reservation on protection paths prior to failure is very inefficient and leads to excessive usage of network capacity for protection purposes. This can be avoided by not reserving capacity on the protection path. In this case, however, the availability of the protection path can not be guaranteed when a failure occurs. Alternatively, protection capacity can be shared between protection paths that are unlikely to fail simultaneously. For this, a limited number of failure scenarios (e.g. single node or single link failures) is assumed. Sharing protection capacity is highly complicated by the interdomain scope of the NSIS signalling because of the lack of detailed information on the failure states and the primary path. << [georgios] Is this the only solution?>> Recovery on the control plane may involve any of the following issues: - If a failure can only be solved by means of a change of the interdomain path of the flow, the QC might be required to force a route change from the QI. << [georgios] Should this be done by NSIS; It is out of scope of NSIS >> Note that this can occur without any data plane failure when the QC of a QoS domain fails and the QCs of neighbouring domains want to bring up peering relations with QCs that are not realted to the next hop on the data path. - When only per-class state is kept in a QC and a setup message is lost, retransmission of the setup message may cause duplicate reservations in QoS domains upstream of the point where the loss occurred. In case of soft-state, this situation will last for several refresh intervals. Note that the impact of this type of failure can be restricted by the use of reliable transport between NSIS entities. <<[georgios] It can be solved by using explicit release messages, see RMD frmaework>> - In case of a QI or QR failure, the QC immediately following or preceding the failing entity may need to take up some proxy functionality for the failing entity. This functionality is optional for sending out teardown messages when soft-state is used, but mandatory for hard-state. It is also mandatory for replying to teardown messages, e.g. originating from the QI. - If the QoS Initiator does not receive a response on a signaling message within a certain time interval it will consider it as lost. It may decide to retransmit the signaling message. Therefore, the QoS Initiator must be able to make sure that the received ACK is not a delayed ACK from the previous transmitted signaling message. The signaling messages should therefore include a sequence number in order to associate a request (NEW, TEAR, REFRESH) with a response (ACK, NACK). <<[georgios] When soft state refresh is used, the TEAr messages do not neet to be authenticated>> 7. Reversion issues 7.1. Repair detection No issues are identified for the data plane. For the control plane, repair detection will most likely occur by means of discovery messages initiated by the repaired NSIS entity. It is proposed that this discovery process could be a preliminary phase prior to the NSIS protocol and can therefore remain out of its scope. It is nevertheless crucial that such a discovery protocol is standardised in order to allow NSIS entities from different vendors to discover each other. <<[georgios] I think that is out of scope of NSIS>> 7.2. Repair notification Repair notification will normally take place by means of the IGP in the data plane. In the control plane, repair notification may be needed when a QC has taken up some proxy functionality for the QI or QC. However, no special action should be needed for this since this information can be inferred from the repair detection. <<[georgios] If repair detection is out of scope will this also be out of NSIS scope>> 7.3. Reversion action On the data plane, reversion is unavoidable when in-band signaling is used because the signaling messages will follow the new data plane route. This might cause issues because resources are typically not reserved on the new route, which might cause (temporary) QoS degradation on the new route. <<[georgios] What is the reversion action about? Is this related to the severe congestion problem explained in the NSIS requirements draft?>> In case of out-of-band signaling reversion may be avoided by means of route pinning. However, it will usually be advantageous to move to a more favourable route when one becomes available, both from a performance and resource utilisation point of view. In that case, the separation of data plane and control plane might help delaying the route change until sufficient resources are reserved on the new path. From a control plane perspective, reversion makes little sense when backup NSIS entities are used. In that case, the reversion action will be limited to a synchronisation with the currently active NSIS entity. The repaired entity will then become the backup. <<[georgios] Is out of band out of NSIS scope? -------------------------------------------------------------------------------------------------- -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: Thursday, June 27, 2002 4:25 PM To: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Hi all, As a result of discussions at the interim meeting we put together a separate document on nsis resilience. It tries to list issues brought up at the interim meeting together with some new ones in a broader general scope. The document has finally made it through to the IETF repository. Some people have expressed interest during the interim meeting, so hopefully the document can help in structuring the discussion. Best regards, Sven ---------------------- Forwarded by Sven VAN DEN BOSCH/BE/ALCATEL on 27/06/2002 16:19 --------------------------- Internet-Drafts@ietf.org@cnri.reston.va.us on 27/06/2002 12:39:37 Please respond to Internet-Drafts@ietf.org Sent by: nsyracus@cnri.reston.va.us To: IETF-Announce: ; cc: Subject: I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NSIS resilience analysis Author(s) : S. Van den Bosch, M. Buchli Filename : draft-vandenbosch-nsis-resilience-00.txt Pages : 11 Date : 26-Jun-02 The Next Steps in Signaling (NSIS) working group is chartered to develop requirements, architecture and protocols for the next IETF steps in signaling Quality-of-Service (QoS). Although the NSIS protocol may eventually be used for other applications in addition to QoS, it is expected that these, in much the same way as QoS, will depend on predictable and high-availability service delivery. This document attempts to identify, list and classify potential resilience issues for the NSIS protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-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-vandenbosch-nsis-resilience-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-vandenbosch-nsis-resilience-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. ftp://ftp.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Thu Jun 27 23: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 XAA29009 for ; Thu, 27 Jun 2002 23:46:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA13495 for nsis-archive@odin.ietf.org; Thu, 27 Jun 2002 23:47: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 XAA12502; Thu, 27 Jun 2002 23:23: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 XAA12469 for ; Thu, 27 Jun 2002 23:23:50 -0400 (EDT) Received: from legend-mfy8zk0p ([61.144.241.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28508; Thu, 27 Jun 2002 23:22:50 -0400 (EDT) From: zhulinxi@yahoo.com.cn Message-Id: <200206280322.XAA28508@ietf.org> To: nsis@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_000_0018_01C1A1B3.E2C7FE20" MIME-Version: 1.0 Date: Fri, 28 Jun 2002 11:26:38 +0800 X-Priority: 3 X-Mailer: CSM 3.2 Subject: [NSIS] =?GB2312?B?vNLTw8i8xvjQucKpsai+r8b30bDIq7n6uPe12LT6wO3JzKGivq3P+snM?= 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_0018_01C1A1B3.E2C7FE20 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =D5=E2=CA=C7=D2=BB=B8=F6HTML=B8=F1=CA=BD=B5=C4=D3=CA=BC=FE --=_NextPart_000_0018_01C1A1B3.E2C7FE20 Content-Type: text/html Content-Transfer-Encoding: quoted-printable =BC=D2=D3=C3=C8=BC=C6=F8=D0=B9=C2=A9=B1=A8=BE=AF=C6=F7=D1=B0=C8=AB=B9=FA= =B8=F7=B5=D8=B4=FA=C0=ED=C9=CC=A1=A2=BE=AD=CF=FA=C9=CC =20 =20 =A9=FA =A9=FA=A9=FA=CE=D2=B9=AB=CB=BE=CA=C7=D6=C2=C1=A6=D3=DA=C8=BC=C6=F8= =B0=B2=C8=AB=CF=B5=CD=B3=B2=FA=C6=B7=B5=C4=C9=E8=BC=C6=A1=A2=D6=C6=D4=EC= =B5=C4=BF=C6=BC=BC=B9=AB=CB=BE=A3=AC=B9=AB=CB=BE=D4=DA=C6=F8=C3=F4=B4=AB= =B8=D0=BC=BC=CA=F5=A1=A2=BF=D8=D6=C6=BC=BC=CA=F5=A1=A2=BB=B7=BE=B3=D3=A6= =D3=C3 =B5=C8=B7=BD=C3=E6=A3=AC=BE=DF=D3=D0=B7=E1=B8=BB=B5=C4=BF=AA=B7=A2=CA=B5= =D3=C3=BE=AD=D1=E9=BA=CD=D7=D4=D6=F7=B5=C4=BA=CB=D0=C4=BC=BC=CA=F5=A3=AC= =B2=A2=D3=EB=B9=FA=C4=DA=D0=D0=D2=B5=B5=C4=C8=A8=CD=FE=BB=FA=B9=B9=A1=A2= =B8=DF=B5=C8=D4=BA=D0=A3=BF=AA=D5=B9=B9=E3=B7=BA=B5=C4=BC=BC=CA=F5=BD=BB= =C1=F7=D3=EB =BA=CF=D7=F7=A1=A3=B9=AB=CB=BE=B4=AB=B8=D0=B1=E4=C1=F7=B2=B9=B3=A5=BC=BC= =CA=F5=D2=D1=C9=EA=B1=A8=B9=FA=BC=D2=B7=A2=C3=F7=D7=A8=C0=FB=A3=AC=C8=B7= =C1=A2=C1=CB=B9=AB=CB=BE=D0=D0=D2=B5=C4=DA=B5=C4=BC=BC=CA=F5=C1=EC=CF=C8= =D3=C5=CA=C6=A1=A3 =A9=FA=A9=FA=B9=AB=CB=BE=C9=FA=B2=FA=B5=C4YH-898 =CF=B5=C1=D0=C8=BC=C6=F8=B1=A8=BE=AF=C6=F7=A3=AC=CD=A8=B9=FD=B9=FA=BC=D2= =C8=BC=C6=F8=BC=EC=D1=E9=D6=D0=D0=C4=BC=EC=D1=E9=A3=AC=C6=E4=D3=C5=D2=EC= =B5=C4=D0=D4=C4=DC=BA=CD=B8=BB=D3=D0=BE=BA=D5=F9=C1=A6=B5=C4=BC=DB=B8=F1= =A3=AC=C9=EE=CE=AA=D3=C3=BB=A7=C8=CF=CD=AC=A1=A3 =B9=AB=CB=BE=C8=BC=C6=F8= =B1=A8 =BE=AF=C6=F7=B2=FA=C6=B7=B5=C4=D6=F7=D2=AA=CC=D8=B5=E3=CE=AA=A3=BA 1=A1=A2= =CE=C8=B6=A8=D0=D4 =B2=FA=C6=B7=B2=C9=D3=C3=D3=C5=D6=CA=B5=C4=C6=F8=C3=F4= =B4=AB=B8=D0=C6=F7=BC=FE=A3=AC=BE=DF=D3=D0=BF=B9=B1=A5=BA=CD=A1=A2=BF=B9= =D6=D0=B6=BE=C4=DC=C1=A6=A3=AC=CE=DE=B6=DB=BB=AF=CF=D6=CF=F3=A3=AC=D2=F2= =B4=CB=BF=C9=BB=F1=B5=C3=BD=CF=B8=DF=B5=C4=CE=C8=B6=A8=D0=D4=BA=CD=B3=A4= =CA=D9=C3=FC=A1=A3 =B2=FA=C6=B7=BE=DF=D3=D0=B4=AB=B8=D0=C6=F7=CA=A7=D0=A7= =D7=D4=B6=AF=BC=EC=B2=E2=B9=A6=C4=DC=A3=AC=CC=D8=D3=D0=B5=C4=D0=C5=BA=C5= =CA=B6=B1=F0=BC=BC=CA=F5=A3=AC=BF=C9=D3=D0=D0=A7=B5=D8=B7=C0=D6=B9=B5=E7= =D4=B4 =BC=B0=CD=E2=BD=E7=B5=E7=B4=C5=B7=F8=C9=E4=B5=C4=B8=C9=C8=C5=A1=A3=B1=A3= =D6=A4=B2=FA=C6=B7=BF=C9=BF=BF=B5=D8=B9=A4=D7=F7=A1=A3 2=A1=A2 =C1=E9=C3= =F4=B6=C8 =B2=FA=C6=B7=BE=DF=D3=D0=BF=ED=B9=E3=B5=C4=CF=DF=D0=D4=C5=A8=B6= =C8=CF=EC=D3=A6=B7=B6=CE=A7=A3=AC=B6=FE=BC=B6=B1=A8=BE=AF=B5=E7=C6=BD=BF= =C9 =B4=EF=B3=A3=CC=AC=B5=C4=A3=B1=A3=B0=B1=B6=A3=AC=D2=BB=BC=B6=B1=A8=BE=AF= =D0=C5=BA=C5=B5=E7=C6=BD=BF=C9=B4=EF=B3=A3=CC=AC=B5=C4=A3=B4=B1=B6=A3=AC= =B2=FA=C6=B7=BF=C9=D4=DA=BA=DC=B8=DF=B5=C4=C1=E9=C3=F4=B6=C8=CF=C2=B9=A4= =D7=F7=A3=AC=B6=F8=B2=BB=BB=E1=B2=FA=C9=FA=CE=F3=B1=A8=CF=D6=CF=F3=A1=A3= =CE=AA=CE=D2 =B9=AB=CB=BE=B2=FA=C6=B7=CB=F9=B6=C0=D3=D0=B5=C4=CC=D8=D0=D4=A1=A3 3=A1=A2= =D7=EE=C7=BF=B5=C4=BB=B7=BE=B3=CA=CA=D3=A6=C4=DC=C1=A6 =B2=FA=C6=B7=BE=AD= =B9=FD=B7=C0=BB=A4=B9=A4=D2=D5=B4=A6=C0=ED=A3=AC=BF=C9=D4=DA=B8=DF=CE=C2= =A1=A2=B8=DF=B5=CD=CE=C2=BC=B0=D1=CE=CE=ED=BB=B7=BE=B3=D6=D0=B3=A4=C6=DA= =B9=A4=D7=F7=A1=A3=B9=AB=CB=BE=B2=C9=D3=C3=D7=D4=D6=F7=B5=C4=D7=A8=C0=FB= =BC=BC=CA=F5=BD=F8=D0=D0=C6=F8=C3=F4=B4=AB=B8=D0=B2=B9=B3=A5=A3=AC=B2=BB= =B5=AB=BF=C9=B5=C3=B5=BD=D2=BB=B0=E3=D0=D4=B5=C4=CE=C2=A1=A2=CA=AA=B6=C8= =B2=B9=B3=A5=A3=AC=B6=F8=C7=D2=C6=E4=D1=A1=D4=F1=D0=D4=D2=B2=B2=BB=BB=E1= =CB=E6=CD=E2 =BD=E7=BB=B7=BE=B3=B1=E4=BB=AF=B6=F8=B1=E4=BB=AF=A3=AC=B4=D3=B6=F8=B1=A3= =D6=A4=B2=FA=C6=B7=B5=C4=D2=BB=D6=C2=B5=C4=A1=A2=CE=C8=B6=A8=B5=C4=CA=E4= =B3=F6=A1=A3 4=A1=A2 =D7=EE=B5=CD=B9=A6=BA=C4 =B9=AB=CB=BE=BF=AA=B7=A2=B5= =C4=CF=B5=C1=D0=B5=CD=B9=A6=BA=C4=B2=FA=C6=B7=A3=AC=B2=BB=B5=AB=BE=DF=D3= =D0 =BC=D3=C8=C8=D0=CD=C6=F8=C3=F4=D4=AA=BC=FE=B8=DF=C1=E9=C3=F4=B6=C8=A1=A2= =B8=DF=CE=C8=B6=A8=D0=D4=B5=C4=CC=D8=B5=E3=A3=AC=B6=F8=C7=D2=BE=DF=D3=D0= =BD=CF=B5=CD=B5=C4=B9=A6=BA=C4=A3=AC=B3=A3=CC=AC=CA=B1=20 http://www.110alarm.com --=_NextPart_000_0018_01C1A1B3.E2C7FE20-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 28 04:06: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 EAA13745 for ; Fri, 28 Jun 2002 04:06:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA03491 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 04:07: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 DAA02266; Fri, 28 Jun 2002 03:45: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 DAA02171 for ; Fri, 28 Jun 2002 03:44:56 -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 DAA13220 for ; Fri, 28 Jun 2002 03:44:10 -0400 (EDT) From: Zhigang.Kan@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 g5S7hTd22585 for ; Fri, 28 Jun 2002 10:43:29 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 10:44:54 +0300 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 10:44:54 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 15:44:42 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 15:42:30 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD07E3C7@beebe001.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft: In-Band & Out-of-Band Thread-Index: AcIdywgblKJkep7bQWasE+TMHfQkogAoyr0g To: , X-OriginalArrivalTime: 28 Jun 2002 07:44:42.0995 (UTC) FILETIME=[AA7B6430:01C21E77] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id DAA02172 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 Robert, Q1: "Node" used in your terminology can be a router, an end host or a server, right? In the case of distributed RMF, must each node have the resource management function in a NSIS domain? Q2: The RMF is responsible for all network provisioning and resource allocation functions, and "some" of the state management is an RMF responsibility. How about the "other" of the state management, and it is refered to the state management mechanism of NSIS related with "Refresh" message? If so, what relationship between these two parts of state management? Is it out of the scope of NSIS? I hope answer is no. BR/Kan Zhigang -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 2002å¹´6月27æ—¥ 19:02 To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Hi Zhigang, Please see inline: > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: 27 June 2002 11:53 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > Hi, > > In the draft about In-Band & Out-of-Band: > > "In-band signaling means that the path followed by the user > data packets is the same as the path followed by signaling > messages. In other words, the signaling and data paths are > identical. Out-of-band signaling means that the path followed > by signaling messages might be different from the path used > by the user data packets. " > > So in-band signaling is same as RSVP's operation mode? [reh] basically yes, from a topological ("where the messages go") point of view. > And > must it install soft states in each router it passed through > based on per-flow or per-class-flow? [reh] that's one reasonable way for it to work. see 4.4 about general state management issues; there are several different sorts of state and several different ways to manage them. and some of the state management is an RMF responsibility. > I think that it may be > better if in-band signaling is used in access network and > out-of-band signaling is used in backbone networks (i.e. the > out-of-band signaling is used for communcation between RMFs > which are responsible for the "resource" management > independent of concrete user traffic in control plane). Is > resource reservation really needed in backbone network now or > in the future? [reh] that's a good question. however, in our framework we tried hard to avoid saying that NSIS would work in particular ways in particular network parts. (ideally, I think there should be implementation and deployment flexibility within the protocol to allow this.) > > I don't know why "the initial goal of NSIS is to concentrate > mainly on the in-band case". [reh] that's a WG chair/AD question. > > BR/Kan Zhigang Cheers, Robert H. > > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 2002å¹´6月24æ—¥ 19:47 > To: NSIS > Subject: [NSIS] New framework draft > > > Hi all, > > A group of us who were involved in past NSIS framework > activities got together after the interim meeting to put > together a joint framework document in the form of an all-new > individual submission. It (roughly) follows the structure > that was introduced and refined at that meeting. > > ============================================================== > ============ > Abstract > > The NSIS working group is considering protocol developments in > signaling for resources for a traffic flow along its path in the > network. The requirements for such signaling are being > developed in a > separate document; This Internet Draft proposes a framework for > such signaling. This initial version provides a model for > describing > the entities that take part in the signaling and the ways in which > they can be used in different modes of operation. It also > discusses > the overall structure of such a signaling protocol. Finally, it > considers the possible interactions of NSIS signaling with other > protocols and functions, including security issues. > ============================================================== > ============ > > While it works its way through the i-d editor queue, you can > find a copy here: > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > Comments are welcome. There is a list of open issue > highlights in section 3. > > Cheers, > > Robert Hancock > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 28 04:38: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 EAA14557 for ; Fri, 28 Jun 2002 04:38:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05275 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 04:39:32 -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 EAA04073; Fri, 28 Jun 2002 04:23: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 EAA04042 for ; Fri, 28 Jun 2002 04:23: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 EAA14190 for ; Fri, 28 Jun 2002 04:22:38 -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 g5S8NCrU029816; Fri, 28 Jun 2002 10:23:16 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHMTJ52Q; Fri, 28 Jun 2002 10:22:53 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 10:22:02 +0200 Message-ID: X-Sybari-Trust: 4728e550 7216406a 0b6f7280 00000138 From: "Georgios Karagiannis (ELN)" To: "'Zhigang.Kan@nokia.com'" , robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 10:21:58 +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 EAA04043 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 In case of distributed RMF, each RMF function may be co-located (included) within each node that uses NSIS signaling. Each node might be NI, NF or NR. Best Regards, Georgios -----Original Message----- From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] Sent: Friday, June 28, 2002 9:43 AM To: robert.hancock@roke.co.uk; nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Hi Robert, Q1: "Node" used in your terminology can be a router, an end host or a server, right? In the case of distributed RMF, must each node have the resource management function in a NSIS domain? Q2: The RMF is responsible for all network provisioning and resource allocation functions, and "some" of the state management is an RMF responsibility. How about the "other" of the state management, and it is refered to the state management mechanism of NSIS related with "Refresh" message? If so, what relationship between these two parts of state management? Is it out of the scope of NSIS? I hope answer is no. BR/Kan Zhigang -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 2002å¹´6月27æ—¥ 19:02 To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Hi Zhigang, Please see inline: > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: 27 June 2002 11:53 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > Hi, > > In the draft about In-Band & Out-of-Band: > > "In-band signaling means that the path followed by the user > data packets is the same as the path followed by signaling > messages. In other words, the signaling and data paths are > identical. Out-of-band signaling means that the path followed > by signaling messages might be different from the path used > by the user data packets. " > > So in-band signaling is same as RSVP's operation mode? [reh] basically yes, from a topological ("where the messages go") point of view. > And > must it install soft states in each router it passed through > based on per-flow or per-class-flow? [reh] that's one reasonable way for it to work. see 4.4 about general state management issues; there are several different sorts of state and several different ways to manage them. and some of the state management is an RMF responsibility. > I think that it may be > better if in-band signaling is used in access network and > out-of-band signaling is used in backbone networks (i.e. the > out-of-band signaling is used for communcation between RMFs > which are responsible for the "resource" management > independent of concrete user traffic in control plane). Is > resource reservation really needed in backbone network now or > in the future? [reh] that's a good question. however, in our framework we tried hard to avoid saying that NSIS would work in particular ways in particular network parts. (ideally, I think there should be implementation and deployment flexibility within the protocol to allow this.) > > I don't know why "the initial goal of NSIS is to concentrate > mainly on the in-band case". [reh] that's a WG chair/AD question. > > BR/Kan Zhigang Cheers, Robert H. > > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 2002å¹´6月24æ—¥ 19:47 > To: NSIS > Subject: [NSIS] New framework draft > > > Hi all, > > A group of us who were involved in past NSIS framework > activities got together after the interim meeting to put > together a joint framework document in the form of an all-new > individual submission. It (roughly) follows the structure > that was introduced and refined at that meeting. > > ============================================================== > ============ > Abstract > > The NSIS working group is considering protocol developments in > signaling for resources for a traffic flow along its path in the > network. The requirements for such signaling are being > developed in a > separate document; This Internet Draft proposes a framework for > such signaling. This initial version provides a model for > describing > the entities that take part in the signaling and the ways in which > they can be used in different modes of operation. It also > discusses > the overall structure of such a signaling protocol. Finally, it > considers the possible interactions of NSIS signaling with other > protocols and functions, including security issues. > ============================================================== > ============ > > While it works its way through the i-d editor queue, you can > find a copy here: > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > Comments are welcome. There is a list of open issue > highlights in section 3. > > Cheers, > > Robert Hancock > _______________________________________________ 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 Jun 28 04:40: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 EAA14603 for ; Fri, 28 Jun 2002 04:40:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05328 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 04:41: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 EAA04345; Fri, 28 Jun 2002 04:27: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 EAA04317 for ; Fri, 28 Jun 2002 04:27:50 -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 EAA14316 for ; Fri, 28 Jun 2002 04:27:04 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 09:27:43 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3EE@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Zhigang.Kan@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 09:27:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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="utf-8" Hi Zhigang, Please see inline below. Cheers, Robert H. ps apologies about my email disclaimer, it's not entirely under my control to fix it, though we're doing what we can. i am aware that i am sending this email to a public mailing list ... > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: 28 June 2002 08:43 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > Hi Robert, > > Q1: "Node" used in your terminology can be a router, an end > host or a server, right? [reh] yes, in the broadest sense ('node' is a fancy name for 'box'). if you respect the 'on-path' restriction, a node that processes NSIS signalling must be on the data path, which probably rules out the 'server' case. > In the case of distributed RMF, must > each node have the resource management function in a NSIS domain? [reh] if you have a distributed approach to resource management, i guess we would typically expect most nodes would have a resource management responsibility, but there's no requirement for every node to do something with resource management. in particular: 1) not every node has to process NSIS messages (cf. RSVP operation over non-RSVP clouds) 2) even if a node does process NSIS messages, it might do so for reasons not associated with resource management. > > Q2: The RMF is responsible for all network provisioning and > resource allocation functions, and "some" of the state > management is an RMF responsibility. How about the "other" of > the state management, and it is refered to the state > management mechanism of NSIS related with "Refresh" message? > If so, what relationship between these two parts of state > management? Is it out of the scope of NSIS? I hope answer is no. [reh] this is a hard question to answer, and a hard question in general. 1. It's clear that to do resource management, you need to store some state information. That information might be at the flow level, or some 'resource class' level, or something else. Because the state you need to store depends on the resource you are trying to manage and the precision with which you need to manage it, we don't think NSIS can define how this is done. 2. You also need state to make a protocol operate correctly. This could include all (or none) of: *) information about how to reverse-path route messages for a flow *) information about who to send an acknowledgement to and when *) information about when to send a refresh message *) information about who was authenticated when a reservation was made *) and so on This is all in NSIS scope to worry about. Most of it is per-flow. 3. The relationship between these two types of state is something we discussed, but only in outline. I think a basic design goal could be stated as: "It should be possible to use [a|the] NSIS protocol in such a way that it only requires the minimum of state storage, in particular no more than the resource management mechanism that it is supporting." It's then (I think) mainly a job for the implementor to do both aspects of state management in an economical way (in particular, without duplication). So, I think we need to consider the possible interactions between the different parts of state management, and make sure they get reflected as goals for NSIS design in terms of flexibility and general usefulness of the protocol, but without defining details of exactly how the different types of state interact. This is actually a special case of a more general issue. Look also at draft-braden-2level-signal-arch-00.txt where there is the related question of the split between CSTP and ALSP. The general point is that we almost certainly can't have a pure structure of independent layers (I would expect the ALSP-like upper layer to hook into the operation of the lower layer quite intimately rather than the other way round, but that's more of a protocol design issue). The state management issue is just one aspect of this. So, I think the answer to your question is "yes and no" (if you see what I mean...) > > BR/Kan Zhigang > > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 2002å¹´6月27æ—¥ 19:02 > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > Hi Zhigang, > > Please see inline: > > > -----Original Message----- > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > Sent: 27 June 2002 11:53 > > To: Hancock, Robert; nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > Hi, > > > > In the draft about In-Band & Out-of-Band: > > > > "In-band signaling means that the path followed by the user > > data packets is the same as the path followed by signaling > > messages. In other words, the signaling and data paths are > > identical. Out-of-band signaling means that the path followed > > by signaling messages might be different from the path used > > by the user data packets. " > > > > So in-band signaling is same as RSVP's operation mode? > > [reh] basically yes, from a topological ("where the messages > go") point of view. > > > And > > must it install soft states in each router it passed through > > based on per-flow or per-class-flow? > > [reh] that's one reasonable way for it to work. see 4.4 about > general state management issues; there are several different > sorts of state and several different ways to manage them. and > some of the state management is an RMF responsibility. > > > I think that it may be > > better if in-band signaling is used in access network and > > out-of-band signaling is used in backbone networks (i.e. the > > out-of-band signaling is used for communcation between RMFs > > which are responsible for the "resource" management > > independent of concrete user traffic in control plane). Is > > resource reservation really needed in backbone network now or > > in the future? > > [reh] that's a good question. however, in our framework we > tried hard to avoid saying that NSIS would work in particular > ways in particular network parts. (ideally, I think there > should be implementation and deployment flexibility within > the protocol to allow this.) > > > > > I don't know why "the initial goal of NSIS is to concentrate > > mainly on the in-band case". > > [reh] that's a WG chair/AD question. > > > > > BR/Kan Zhigang > > Cheers, > > Robert H. > > > > -----Original Message----- > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: 2002å¹´6月24æ—¥ 19:47 > > To: NSIS > > Subject: [NSIS] New framework draft > > > > > > Hi all, > > > > A group of us who were involved in past NSIS framework > > activities got together after the interim meeting to put > > together a joint framework document in the form of an all-new > > individual submission. It (roughly) follows the structure > > that was introduced and refined at that meeting. > > > > ============================================================== > > ============ > > Abstract > > > > The NSIS working group is considering protocol developments in > > signaling for resources for a traffic flow along its path in the > > network. The requirements for such signaling are being > > developed in a > > separate document; This Internet Draft proposes a framework for > > such signaling. This initial version provides a model for > > describing > > the entities that take part in the signaling and the > ways in which > > they can be used in different modes of operation. It also > > discusses > > the overall structure of such a signaling protocol. Finally, it > > considers the possible interactions of NSIS signaling with other > > protocols and functions, including security issues. > > ============================================================== > > ============ > > > > While it works its way through the i-d editor queue, you can > > find a copy here: > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > Comments are welcome. There is a list of open issue > > highlights in section 3. > > > > Cheers, > > > > Robert Hancock > > > --------------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 Fri Jun 28 05:06: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 FAA15102 for ; Fri, 28 Jun 2002 05:06:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA06702 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 05:06: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 EAA05695; Fri, 28 Jun 2002 04:50: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 EAA05667 for ; Fri, 28 Jun 2002 04:50:52 -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 EAA14814 for ; Fri, 28 Jun 2002 04:50:05 -0400 (EDT) From: Zhigang.Kan@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 g5S8pIi00740 for ; Fri, 28 Jun 2002 11:51:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 11:50:50 +0300 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 11:50:50 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 16:48:35 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 16:41:49 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD07E3C9@beebe001.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft: In-Band & Out-of-Band Thread-Index: AcIefczfEKuPkX7dQoG5Sqh8rHx+KAAAGE0w To: , , X-OriginalArrivalTime: 28 Jun 2002 08:48:35.0998 (UTC) FILETIME=[97213BE0:01C21E80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id EAA05668 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, "NSIS Entity (NE) - the function within a 'NODE' which implements an NSIS protocol. " I refered to the "NODE" in the above definition, and can it be a router, a host, a server or whatever a new concept thing? In ohter words, may NI, NF and NR be a router, a server or a host? Is there any special requirements on network equipments in a existing netwok domain if it will become a NSIS domain? BR/Kan Zhigang -----Original Message----- From: ext Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: 2002å¹´6月28æ—¥ 16:22 To: Kan Zhigang (Nokia-RD/Beijing); robert.hancock@roke.co.uk; nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Hi In case of distributed RMF, each RMF function may be co-located (included) within each node that uses NSIS signaling. Each node might be NI, NF or NR. Best Regards, Georgios -----Original Message----- From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] Sent: Friday, June 28, 2002 9:43 AM To: robert.hancock@roke.co.uk; nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Hi Robert, Q1: "Node" used in your terminology can be a router, an end host or a server, right? In the case of distributed RMF, must each node have the resource management function in a NSIS domain? Q2: The RMF is responsible for all network provisioning and resource allocation functions, and "some" of the state management is an RMF responsibility. How about the "other" of the state management, and it is refered to the state management mechanism of NSIS related with "Refresh" message? If so, what relationship between these two parts of state management? Is it out of the scope of NSIS? I hope answer is no. BR/Kan Zhigang -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 2002å¹´6月27æ—¥ 19:02 To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Hi Zhigang, Please see inline: > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: 27 June 2002 11:53 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > Hi, > > In the draft about In-Band & Out-of-Band: > > "In-band signaling means that the path followed by the user > data packets is the same as the path followed by signaling > messages. In other words, the signaling and data paths are > identical. Out-of-band signaling means that the path followed > by signaling messages might be different from the path used > by the user data packets. " > > So in-band signaling is same as RSVP's operation mode? [reh] basically yes, from a topological ("where the messages go") point of view. > And > must it install soft states in each router it passed through > based on per-flow or per-class-flow? [reh] that's one reasonable way for it to work. see 4.4 about general state management issues; there are several different sorts of state and several different ways to manage them. and some of the state management is an RMF responsibility. > I think that it may be > better if in-band signaling is used in access network and > out-of-band signaling is used in backbone networks (i.e. the > out-of-band signaling is used for communcation between RMFs > which are responsible for the "resource" management > independent of concrete user traffic in control plane). Is > resource reservation really needed in backbone network now or > in the future? [reh] that's a good question. however, in our framework we tried hard to avoid saying that NSIS would work in particular ways in particular network parts. (ideally, I think there should be implementation and deployment flexibility within the protocol to allow this.) > > I don't know why "the initial goal of NSIS is to concentrate > mainly on the in-band case". [reh] that's a WG chair/AD question. > > BR/Kan Zhigang Cheers, Robert H. > > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 2002å¹´6月24æ—¥ 19:47 > To: NSIS > Subject: [NSIS] New framework draft > > > Hi all, > > A group of us who were involved in past NSIS framework > activities got together after the interim meeting to put > together a joint framework document in the form of an all-new > individual submission. It (roughly) follows the structure > that was introduced and refined at that meeting. > > ============================================================== > ============ > Abstract > > The NSIS working group is considering protocol developments in > signaling for resources for a traffic flow along its path in the > network. The requirements for such signaling are being > developed in a > separate document; This Internet Draft proposes a framework for > such signaling. This initial version provides a model for > describing > the entities that take part in the signaling and the ways in which > they can be used in different modes of operation. It also > discusses > the overall structure of such a signaling protocol. Finally, it > considers the possible interactions of NSIS signaling with other > protocols and functions, including security issues. > ============================================================== > ============ > > While it works its way through the i-d editor queue, you can > find a copy here: > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > Comments are welcome. There is a list of open issue > highlights in section 3. > > Cheers, > > Robert Hancock > _______________________________________________ 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 Jun 28 05:16: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 FAA15328 for ; Fri, 28 Jun 2002 05:16:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA07345 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 05:17: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 FAA06594; Fri, 28 Jun 2002 05:04: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 FAA06565 for ; Fri, 28 Jun 2002 05:03:59 -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 FAA15058 for ; Fri, 28 Jun 2002 05:03:13 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 10:03:55 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3EF@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Zhigang.Kan@nokia.com'" , Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 10:03:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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="utf-8" Content-Transfer-Encoding: quoted-printable hi, any node which processes NSIS messages has an NE inside it which does = that processing. we have given NEs different names depending on what = role they are playing within the protocol. if you accept that NSIS messages have to follow the data path, that = restricts what sorts of nodes can have NEs inside them. you can easily = think of scenarios where NI/NF/NR could be in router or hosts, but not = servers. (although I suppose you could backhaul NSIS messages to a = central server if you wanted to, we just aren't defining a backhaul = mechanism to do this.) i don't believe there are any special requirements on existing network = equipments to use NSIS in a domain (or rather, we have requirements - i = think - to allow incremental deployment and use of NSIS). obviously, to = use NSIS in the first place, you'll need to have _some_ equipment that = processes the messages. (terminology is never easy. suggestions are welcome.) cheers, robert h. ps apologies about my email disclaimer, it's not entirely under my = control to fix it, though we're doing what we can. i am aware that i am = sending this email to a public mailing list ... > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: 28 June 2002 09:42 > To: Georgios.Karagiannis@eln.ericsson.se; Hancock, Robert;=20 > nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band >=20 >=20 > Hi, >=20 > "NSIS Entity (NE) - the function within a 'NODE' which=20 > implements an NSIS protocol. " >=20 > I refered to the "NODE" in the above definition, and can it=20 > be a router, a host, a server or whatever a new concept=20 > thing? In ohter words, may NI, NF and NR be a router, a=20 > server or a host? >=20 > Is there any special requirements on network equipments in a=20 > existing netwok domain if it will become a NSIS domain? >=20 > BR/Kan Zhigang > -----Original Message----- > From: ext Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 2002=E5=B9=B46=E6=9C=8828=E6=97=A5 16:22 > To: Kan Zhigang (Nokia-RD/Beijing); robert.hancock@roke.co.uk; > nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band >=20 >=20 > Hi=20 >=20 > In case of distributed RMF, each RMF function may be co-located=20 > (included) within each node that uses NSIS signaling. > Each node might be NI, NF or NR. > Best Regards, > Georgios >=20 >=20 > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: Friday, June 28, 2002 9:43 AM > To: robert.hancock@roke.co.uk; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band >=20 >=20 > Hi Robert, >=20 > Q1: "Node" used in your terminology can be a router, an end=20 > host or a server, right? In the case of distributed RMF, must=20 > each node have the resource management function in a NSIS domain? >=20 > Q2: The RMF is responsible for all network provisioning and=20 > resource allocation functions, and "some" of the state=20 > management is an RMF responsibility. How about the "other" of=20 > the state management, and it is refered to the state=20 > management mechanism of NSIS related with "Refresh" message?=20 > If so, what relationship between these two parts of state=20 > management? Is it out of the scope of NSIS? I hope answer is no. >=20 > BR/Kan Zhigang >=20 > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 2002=E5=B9=B46=E6=9C=8827=E6=97=A5 19:02 > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band >=20 >=20 > Hi Zhigang, >=20 > Please see inline: >=20 > > -----Original Message----- > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > Sent: 27 June 2002 11:53 > > To: Hancock, Robert; nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > >=20 > >=20 > > Hi,=20 > >=20 > > In the draft about In-Band & Out-of-Band: > >=20 > > "In-band signaling means that the path followed by the user=20 > > data packets is the same as the path followed by signaling=20 > > messages. In other words, the signaling and data paths are=20 > > identical. Out-of-band signaling means that the path followed=20 > > by signaling messages might be different from the path used=20 > > by the user data packets. " > >=20 > > So in-band signaling is same as RSVP's operation mode?=20 >=20 > [reh] basically yes, from a topological ("where the messages=20 > go") point of view.=20 >=20 > > And=20 > > must it install soft states in each router it passed through=20 > > based on per-flow or per-class-flow? >=20 > [reh] that's one reasonable way for it to work. see 4.4 about=20 > general state management issues; there are several different=20 > sorts of state and several different ways to manage them. and=20 > some of the state management is an RMF responsibility. >=20 > > I think that it may be=20 > > better if in-band signaling is used in access network and=20 > > out-of-band signaling is used in backbone networks (i.e. the=20 > > out-of-band signaling is used for communcation between RMFs=20 > > which are responsible for the "resource" management=20 > > independent of concrete user traffic in control plane). Is=20 > > resource reservation really needed in backbone network now or=20 > > in the future?=20 >=20 > [reh] that's a good question. however, in our framework we=20 > tried hard to avoid saying that NSIS would work in particular=20 > ways in particular network parts. (ideally, I think there=20 > should be implementation and deployment flexibility within=20 > the protocol to allow this.) >=20 > >=20 > > I don't know why "the initial goal of NSIS is to concentrate=20 > > mainly on the in-band case".=20 >=20 > [reh] that's a WG chair/AD question. >=20 > >=20 > > BR/Kan Zhigang >=20 > Cheers, >=20 > Robert H. > >=20 > > -----Original Message----- > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: 2002=E5=B9=B46=E6=9C=8824=E6=97=A5 19:47 > > To: NSIS > > Subject: [NSIS] New framework draft > >=20 > >=20 > > Hi all, > >=20 > > A group of us who were involved in past NSIS framework=20 > > activities got together after the interim meeting to put=20 > > together a joint framework document in the form of an all-new=20 > > individual submission. It (roughly) follows the structure=20 > > that was introduced and refined at that meeting. > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Abstract=20 > > =20 > > The NSIS working group is considering protocol developments in=20 > > signaling for resources for a traffic flow along its path in the = > > network. The requirements for such signaling are being=20 > > developed in a=20 > > separate document; This Internet Draft proposes a framework for=20 > > such signaling. This initial version provides a model for=20 > > describing=20 > > the entities that take part in the signaling and the=20 > ways in which=20 > > they can be used in different modes of operation. It also=20 > > discusses=20 > > the overall structure of such a signaling protocol. Finally, it=20 > > considers the possible interactions of NSIS signaling with other = > > protocols and functions, including security issues.=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > While it works its way through the i-d editor queue, you can=20 > > find a copy here: > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > >=20 > > Comments are welcome. There is a list of open issue=20 > > highlights in section 3. > >=20 > > Cheers, > >=20 > > Robert Hancock > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 --------------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 Fri Jun 28 05:23: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 FAA15460 for ; Fri, 28 Jun 2002 05:23:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA07549 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 05:24: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 FAA06937; Fri, 28 Jun 2002 05:10: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 FAA06838 for ; Fri, 28 Jun 2002 05:10:27 -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 FAA15188 for ; Fri, 28 Jun 2002 05:09:41 -0400 (EDT) From: Zhigang.Kan@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 g5S9Asi16928 for ; Fri, 28 Jun 2002 12:10:54 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 12:10:25 +0300 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 12:10:25 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 17:09:43 +0800 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] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 17:09:43 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD07E3CA@beebe001.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft: In-Band & Out-of-Band Thread-Index: AcIefzSaPKx3BV4OTEKaMq6TbXZJEwAAb1SA To: , X-OriginalArrivalTime: 28 Jun 2002 09:09:43.0793 (UTC) FILETIME=[8ACB6610:01C21E83] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id FAA06839 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 Robert, I am more confused about 'node' is for 'box', but what in the box, a part of netwok or a whole network or whatever? Does the data pass through the box? How to understand the data path, based on per-router or per-network? Is NSIS Framework independent of the true networks and is it only abstract concept over the different environments? I cannot image how to deploy it in the future. BR/Kan Zhigang -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 2002å¹´6月28æ—¥ 16:28 To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Hi Zhigang, Please see inline below. Cheers, Robert H. ps apologies about my email disclaimer, it's not entirely under my control to fix it, though we're doing what we can. i am aware that i am sending this email to a public mailing list ... > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: 28 June 2002 08:43 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > Hi Robert, > > Q1: "Node" used in your terminology can be a router, an end > host or a server, right? [reh] yes, in the broadest sense ('node' is a fancy name for 'box'). if you respect the 'on-path' restriction, a node that processes NSIS signalling must be on the data path, which probably rules out the 'server' case. > In the case of distributed RMF, must > each node have the resource management function in a NSIS domain? [reh] if you have a distributed approach to resource management, i guess we would typically expect most nodes would have a resource management responsibility, but there's no requirement for every node to do something with resource management. in particular: 1) not every node has to process NSIS messages (cf. RSVP operation over non-RSVP clouds) 2) even if a node does process NSIS messages, it might do so for reasons not associated with resource management. > > Q2: The RMF is responsible for all network provisioning and > resource allocation functions, and "some" of the state > management is an RMF responsibility. How about the "other" of > the state management, and it is refered to the state > management mechanism of NSIS related with "Refresh" message? > If so, what relationship between these two parts of state > management? Is it out of the scope of NSIS? I hope answer is no. [reh] this is a hard question to answer, and a hard question in general. 1. It's clear that to do resource management, you need to store some state information. That information might be at the flow level, or some 'resource class' level, or something else. Because the state you need to store depends on the resource you are trying to manage and the precision with which you need to manage it, we don't think NSIS can define how this is done. 2. You also need state to make a protocol operate correctly. This could include all (or none) of: *) information about how to reverse-path route messages for a flow *) information about who to send an acknowledgement to and when *) information about when to send a refresh message *) information about who was authenticated when a reservation was made *) and so on This is all in NSIS scope to worry about. Most of it is per-flow. 3. The relationship between these two types of state is something we discussed, but only in outline. I think a basic design goal could be stated as: "It should be possible to use [a|the] NSIS protocol in such a way that it only requires the minimum of state storage, in particular no more than the resource management mechanism that it is supporting." It's then (I think) mainly a job for the implementor to do both aspects of state management in an economical way (in particular, without duplication). So, I think we need to consider the possible interactions between the different parts of state management, and make sure they get reflected as goals for NSIS design in terms of flexibility and general usefulness of the protocol, but without defining details of exactly how the different types of state interact. This is actually a special case of a more general issue. Look also at draft-braden-2level-signal-arch-00.txt where there is the related question of the split between CSTP and ALSP. The general point is that we almost certainly can't have a pure structure of independent layers (I would expect the ALSP-like upper layer to hook into the operation of the lower layer quite intimately rather than the other way round, but that's more of a protocol design issue). The state management issue is just one aspect of this. So, I think the answer to your question is "yes and no" (if you see what I mean...) > > BR/Kan Zhigang > > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 2002å¹´6月27æ—¥ 19:02 > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > Hi Zhigang, > > Please see inline: > > > -----Original Message----- > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > Sent: 27 June 2002 11:53 > > To: Hancock, Robert; nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > Hi, > > > > In the draft about In-Band & Out-of-Band: > > > > "In-band signaling means that the path followed by the user > > data packets is the same as the path followed by signaling > > messages. In other words, the signaling and data paths are > > identical. Out-of-band signaling means that the path followed > > by signaling messages might be different from the path used > > by the user data packets. " > > > > So in-band signaling is same as RSVP's operation mode? > > [reh] basically yes, from a topological ("where the messages > go") point of view. > > > And > > must it install soft states in each router it passed through > > based on per-flow or per-class-flow? > > [reh] that's one reasonable way for it to work. see 4.4 about > general state management issues; there are several different > sorts of state and several different ways to manage them. and > some of the state management is an RMF responsibility. > > > I think that it may be > > better if in-band signaling is used in access network and > > out-of-band signaling is used in backbone networks (i.e. the > > out-of-band signaling is used for communcation between RMFs > > which are responsible for the "resource" management > > independent of concrete user traffic in control plane). Is > > resource reservation really needed in backbone network now or > > in the future? > > [reh] that's a good question. however, in our framework we > tried hard to avoid saying that NSIS would work in particular > ways in particular network parts. (ideally, I think there > should be implementation and deployment flexibility within > the protocol to allow this.) > > > > > I don't know why "the initial goal of NSIS is to concentrate > > mainly on the in-band case". > > [reh] that's a WG chair/AD question. > > > > > BR/Kan Zhigang > > Cheers, > > Robert H. > > > > -----Original Message----- > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: 2002å¹´6月24æ—¥ 19:47 > > To: NSIS > > Subject: [NSIS] New framework draft > > > > > > Hi all, > > > > A group of us who were involved in past NSIS framework > > activities got together after the interim meeting to put > > together a joint framework document in the form of an all-new > > individual submission. It (roughly) follows the structure > > that was introduced and refined at that meeting. > > > > ============================================================== > > ============ > > Abstract > > > > The NSIS working group is considering protocol developments in > > signaling for resources for a traffic flow along its path in the > > network. The requirements for such signaling are being > > developed in a > > separate document; This Internet Draft proposes a framework for > > such signaling. This initial version provides a model for > > describing > > the entities that take part in the signaling and the > ways in which > > they can be used in different modes of operation. It also > > discusses > > the overall structure of such a signaling protocol. Finally, it > > considers the possible interactions of NSIS signaling with other > > protocols and functions, including security issues. > > ============================================================== > > ============ > > > > While it works its way through the i-d editor queue, you can > > find a copy here: > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > Comments are welcome. There is a list of open issue > > highlights in section 3. > > > > Cheers, > > > > Robert Hancock > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 28 05:43: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 FAA15899 for ; Fri, 28 Jun 2002 05:43:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA08889 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 05:44: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 FAA08214; Fri, 28 Jun 2002 05:30: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 FAA08174 for ; Fri, 28 Jun 2002 05:30:51 -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 FAA15651 for ; Fri, 28 Jun 2002 05:30:04 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 10:30:48 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3F0@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Zhigang.Kan@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 10:30:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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="utf-8" Content-Transfer-Encoding: quoted-printable Hi Zhigang, Apologies for maybe informal language. By 'box' I really mean typically = a physical thing you plug into a power supply, with wires carrying = packets into and out of it. So, usually it's a host or a router. If = signalling only follows the data path (which is considered at the = router level, not the network level), the only relevant nodes can be = the data flow endpoints, and the only relevant routers can be the = routers the flow passes through. We've tried to describe things in terms of signalling going between = signalling entities rather than hosts/routers and so on; one of the = goals of this is to aim for concepts and terminology to describe the = signalling that are re-usable if/when we subsequently think about = signalling paths that are less constrained. It may be (I get the impression) that the level of abstraction in the = framework makes it hard to get a grip on. I'm not sure what would be = the best way to handle this (maybe some concrete example scenarios or = something). We didn't want to make all the definitions very concrete, since that = implies building in assumptions about particular application domains. = Specifically, we have two potential degrees of freedom about NSIS = applicability which we've tried to reflect by using more abstract = language: *) what sort of resources are signalled for *) what sort of signalling paths are traversed Currently, the first is in scope and the second not. I hope we can = avoid too long confusion about the node/entity/network/whatever issue, = because if we can't, we'll probably be encouraged to re-write = everything in terms of routers and hosts, which will make any future = extension to other cases much harder. Cheers, Robert H. ps apologies about my email disclaimer, it's not entirely under my = control to fix it, though we're doing what we can. i am aware that i am = sending this email to a public mailing list ... > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: 28 June 2002 10:10 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band >=20 >=20 > Hi Robert, >=20 > I am more confused about 'node' is for 'box', but what in the=20 > box, a part of netwok or a whole network or whatever? Does=20 > the data pass through the box? How to understand the data=20 > path, based on per-router or per-network? Is NSIS Framework=20 > independent of the true networks and is it only abstract=20 > concept over the different environments? I cannot image how=20 > to deploy it in the future. >=20 > BR/Kan Zhigang >=20 >=20 >=20 > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 2002=E5=B9=B46=E6=9C=8828=E6=97=A5 16:28 > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band >=20 >=20 > Hi Zhigang, >=20 > Please see inline below. >=20 > Cheers, >=20 > Robert H. >=20 > ps apologies about my email disclaimer, it's not entirely=20 > under my control to fix it, though we're doing what we can. i=20 > am aware that i am sending this email to a public mailing list ... >=20 > > -----Original Message----- > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > Sent: 28 June 2002 08:43 > > To: Hancock, Robert; nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > >=20 > >=20 > > Hi Robert, > >=20 > > Q1: "Node" used in your terminology can be a router, an end=20 > > host or a server, right?=20 >=20 > [reh] yes, in the broadest sense ('node' is a fancy name for=20 > 'box'). if you respect the 'on-path' restriction, a node that=20 > processes NSIS signalling must be on the data path, which=20 > probably rules out the 'server' case. >=20 > > In the case of distributed RMF, must=20 > > each node have the resource management function in a NSIS domain? >=20 > [reh] if you have a distributed approach to resource=20 > management, i guess we would typically expect most nodes=20 > would have a resource management responsibility, but there's=20 > no requirement for every node to do something with resource=20 > management. in particular: > 1) not every node has to process NSIS messages (cf. RSVP=20 > operation over non-RSVP clouds) > 2) even if a node does process NSIS messages, it might do so=20 > for reasons not associated with resource management. >=20 > >=20 > > Q2: The RMF is responsible for all network provisioning and=20 > > resource allocation functions, and "some" of the state=20 > > management is an RMF responsibility. How about the "other" of=20 > > the state management, and it is refered to the state=20 > > management mechanism of NSIS related with "Refresh" message?=20 > > If so, what relationship between these two parts of state=20 > > management? Is it out of the scope of NSIS? I hope answer is no. >=20 > [reh] this is a hard question to answer, and a hard question=20 > in general. >=20 > 1. It's clear that to do resource management, you need to=20 > store some state information. That information might be at=20 > the flow level, or some 'resource class' level, or something=20 > else. Because the state you need to store depends on the=20 > resource you are trying to manage and the precision with=20 > which you need to manage it, we don't think NSIS can define=20 > how this is done. >=20 > 2. You also need state to make a protocol operate correctly.=20 > This could include all (or none) of: > *) information about how to reverse-path route messages for a flow > *) information about who to send an acknowledgement to and when > *) information about when to send a refresh message > *) information about who was authenticated when a reservation was = made > *) and so on > This is all in NSIS scope to worry about. Most of it is per-flow. >=20 > 3. The relationship between these two types of state is=20 > something we discussed, but only in outline. I think a basic=20 > design goal could be stated as: > "It should be possible to use [a|the] NSIS protocol in such a=20 > way that it only requires the minimum of state storage, in=20 > particular no more than the resource management mechanism=20 > that it is supporting." It's then (I think) mainly a job for=20 > the implementor to do both aspects of state management in an=20 > economical way (in particular, without duplication). So, I=20 > think we need to consider the possible interactions between=20 > the different parts of state management, and make sure they=20 > get reflected as goals for NSIS design in terms of=20 > flexibility and general usefulness of the protocol, but=20 > without defining details of exactly how the different types=20 > of state interact. >=20 > This is actually a special case of a more general issue. Look=20 > also at draft-braden-2level-signal-arch-00.txt where there is=20 > the related question of the split between CSTP and ALSP. The=20 > general point is that we almost certainly can't have a pure=20 > structure of independent layers (I would expect the ALSP-like=20 > upper layer to hook into the operation of the lower layer=20 > quite intimately rather than the other way round, but that's=20 > more of a protocol design issue). The state management issue=20 > is just one aspect of this. >=20 > So, I think the answer to your question is "yes and no" (if=20 > you see what I mean...) >=20 > >=20 > > BR/Kan Zhigang > >=20 > > -----Original Message----- > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: 2002=E5=B9=B46=E6=9C=8827=E6=97=A5 19:02 > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > >=20 > >=20 > > Hi Zhigang, > >=20 > > Please see inline: > >=20 > > > -----Original Message----- > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > Sent: 27 June 2002 11:53 > > > To: Hancock, Robert; nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > >=20 > > >=20 > > > Hi,=20 > > >=20 > > > In the draft about In-Band & Out-of-Band: > > >=20 > > > "In-band signaling means that the path followed by the user=20 > > > data packets is the same as the path followed by signaling=20 > > > messages. In other words, the signaling and data paths are=20 > > > identical. Out-of-band signaling means that the path followed=20 > > > by signaling messages might be different from the path used=20 > > > by the user data packets. " > > >=20 > > > So in-band signaling is same as RSVP's operation mode?=20 > >=20 > > [reh] basically yes, from a topological ("where the messages=20 > > go") point of view.=20 > >=20 > > > And=20 > > > must it install soft states in each router it passed through=20 > > > based on per-flow or per-class-flow? > >=20 > > [reh] that's one reasonable way for it to work. see 4.4 about=20 > > general state management issues; there are several different=20 > > sorts of state and several different ways to manage them. and=20 > > some of the state management is an RMF responsibility. > >=20 > > > I think that it may be=20 > > > better if in-band signaling is used in access network and=20 > > > out-of-band signaling is used in backbone networks (i.e. the=20 > > > out-of-band signaling is used for communcation between RMFs=20 > > > which are responsible for the "resource" management=20 > > > independent of concrete user traffic in control plane). Is=20 > > > resource reservation really needed in backbone network now or=20 > > > in the future?=20 > >=20 > > [reh] that's a good question. however, in our framework we=20 > > tried hard to avoid saying that NSIS would work in particular=20 > > ways in particular network parts. (ideally, I think there=20 > > should be implementation and deployment flexibility within=20 > > the protocol to allow this.) > >=20 > > >=20 > > > I don't know why "the initial goal of NSIS is to concentrate=20 > > > mainly on the in-band case".=20 > >=20 > > [reh] that's a WG chair/AD question. > >=20 > > >=20 > > > BR/Kan Zhigang > >=20 > > Cheers, > >=20 > > Robert H. > > >=20 > > > -----Original Message----- > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: 2002=E5=B9=B46=E6=9C=8824=E6=97=A5 19:47 > > > To: NSIS > > > Subject: [NSIS] New framework draft > > >=20 > > >=20 > > > Hi all, > > >=20 > > > A group of us who were involved in past NSIS framework=20 > > > activities got together after the interim meeting to put=20 > > > together a joint framework document in the form of an all-new=20 > > > individual submission. It (roughly) follows the structure=20 > > > that was introduced and refined at that meeting. > > >=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Abstract=20 > > > =20 > > > The NSIS working group is considering protocol developments in = > > > signaling for resources for a traffic flow along its=20 > path in the=20 > > > network. The requirements for such signaling are being=20 > > > developed in a=20 > > > separate document; This Internet Draft proposes a=20 > framework for=20 > > > such signaling. This initial version provides a model for=20 > > > describing=20 > > > the entities that take part in the signaling and the=20 > > ways in which=20 > > > they can be used in different modes of operation. It also=20 > > > discusses=20 > > > the overall structure of such a signaling protocol.=20 > Finally, it=20 > > > considers the possible interactions of NSIS signaling=20 > with other=20 > > > protocols and functions, including security issues.=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > While it works its way through the i-d editor queue, you can=20 > > > find a copy here: > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > >=20 > > > Comments are welcome. There is a list of open issue=20 > > > highlights in section 3. > > >=20 > > > Cheers, > > >=20 > > > Robert Hancock > > >=20 > >=20 >=20 --------------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 Fri Jun 28 05:46: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 FAA15958 for ; Fri, 28 Jun 2002 05:46:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA08963 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 05:47: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 FAA08529; Fri, 28 Jun 2002 05:33: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 FAA08501 for ; Fri, 28 Jun 2002 05:33:01 -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 FAA15714 for ; Fri, 28 Jun 2002 05:32:15 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 10:32:57 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3F1@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "Hancock, Robert" , "'Zhigang.Kan@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 10:32:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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="utf-8" Content-Transfer-Encoding: quoted-printable hi - minor correction - in 3rd sentence below, s/nodes/hosts/. r. > -----Original Message----- > From: Hancock, Robert=20 > Sent: 28 June 2002 10:31 > To: 'Zhigang.Kan@nokia.com'; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band >=20 >=20 > Hi Zhigang, >=20 > Apologies for maybe informal language. By 'box' I really mean=20 > typically a physical thing you plug into a power supply, with=20 > wires carrying packets into and out of it. So, usually it's a=20 > host or a router. If signalling only follows the data path=20 > (which is considered at the router level, not the network=20 > level), the only relevant nodes can be the data flow=20 > endpoints, and the only relevant routers can be the routers=20 > the flow passes through. >=20 > We've tried to describe things in terms of signalling going=20 > between signalling entities rather than hosts/routers and so=20 > on; one of the goals of this is to aim for concepts and=20 > terminology to describe the signalling that are re-usable=20 > if/when we subsequently think about signalling paths that are=20 > less constrained. >=20 > It may be (I get the impression) that the level of=20 > abstraction in the framework makes it hard to get a grip on.=20 > I'm not sure what would be the best way to handle this (maybe=20 > some concrete example scenarios or something). >=20 > We didn't want to make all the definitions very concrete,=20 > since that implies building in assumptions about particular=20 > application domains. Specifically, we have two potential=20 > degrees of freedom about NSIS applicability which we've tried=20 > to reflect by using more abstract language: > *) what sort of resources are signalled for > *) what sort of signalling paths are traversed > Currently, the first is in scope and the second not. I hope=20 > we can avoid too long confusion about the=20 > node/entity/network/whatever issue, because if we can't,=20 > we'll probably be encouraged to re-write everything in terms=20 > of routers and hosts, which will make any future extension to=20 > other cases much harder. >=20 > Cheers, >=20 > Robert H. >=20 > ps apologies about my email disclaimer, it's not entirely=20 > under my control to fix it, though we're doing what we can. i=20 > am aware that i am sending this email to a public mailing list ... >=20 >=20 > > -----Original Message----- > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > Sent: 28 June 2002 10:10 > > To: Hancock, Robert; nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > >=20 > >=20 > > Hi Robert, > >=20 > > I am more confused about 'node' is for 'box', but what in the=20 > > box, a part of netwok or a whole network or whatever? Does=20 > > the data pass through the box? How to understand the data=20 > > path, based on per-router or per-network? Is NSIS Framework=20 > > independent of the true networks and is it only abstract=20 > > concept over the different environments? I cannot image how=20 > > to deploy it in the future. > >=20 > > BR/Kan Zhigang > >=20 > >=20 > >=20 > > -----Original Message----- > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: 2002=E5=B9=B46=E6=9C=8828=E6=97=A5 16:28 > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > >=20 > >=20 > > Hi Zhigang, > >=20 > > Please see inline below. > >=20 > > Cheers, > >=20 > > Robert H. > >=20 > > ps apologies about my email disclaimer, it's not entirely=20 > > under my control to fix it, though we're doing what we can. i=20 > > am aware that i am sending this email to a public mailing list ... > >=20 > > > -----Original Message----- > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > Sent: 28 June 2002 08:43 > > > To: Hancock, Robert; nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > >=20 > > >=20 > > > Hi Robert, > > >=20 > > > Q1: "Node" used in your terminology can be a router, an end=20 > > > host or a server, right?=20 > >=20 > > [reh] yes, in the broadest sense ('node' is a fancy name for=20 > > 'box'). if you respect the 'on-path' restriction, a node that=20 > > processes NSIS signalling must be on the data path, which=20 > > probably rules out the 'server' case. > >=20 > > > In the case of distributed RMF, must=20 > > > each node have the resource management function in a NSIS domain? > >=20 > > [reh] if you have a distributed approach to resource=20 > > management, i guess we would typically expect most nodes=20 > > would have a resource management responsibility, but there's=20 > > no requirement for every node to do something with resource=20 > > management. in particular: > > 1) not every node has to process NSIS messages (cf. RSVP=20 > > operation over non-RSVP clouds) > > 2) even if a node does process NSIS messages, it might do so=20 > > for reasons not associated with resource management. > >=20 > > >=20 > > > Q2: The RMF is responsible for all network provisioning and=20 > > > resource allocation functions, and "some" of the state=20 > > > management is an RMF responsibility. How about the "other" of=20 > > > the state management, and it is refered to the state=20 > > > management mechanism of NSIS related with "Refresh" message?=20 > > > If so, what relationship between these two parts of state=20 > > > management? Is it out of the scope of NSIS? I hope answer is no. > >=20 > > [reh] this is a hard question to answer, and a hard question=20 > > in general. > >=20 > > 1. It's clear that to do resource management, you need to=20 > > store some state information. That information might be at=20 > > the flow level, or some 'resource class' level, or something=20 > > else. Because the state you need to store depends on the=20 > > resource you are trying to manage and the precision with=20 > > which you need to manage it, we don't think NSIS can define=20 > > how this is done. > >=20 > > 2. You also need state to make a protocol operate correctly.=20 > > This could include all (or none) of: > > *) information about how to reverse-path route messages for a flow > > *) information about who to send an acknowledgement to and when > > *) information about when to send a refresh message > > *) information about who was authenticated when a=20 > reservation was made > > *) and so on > > This is all in NSIS scope to worry about. Most of it is per-flow. > >=20 > > 3. The relationship between these two types of state is=20 > > something we discussed, but only in outline. I think a basic=20 > > design goal could be stated as: > > "It should be possible to use [a|the] NSIS protocol in such a=20 > > way that it only requires the minimum of state storage, in=20 > > particular no more than the resource management mechanism=20 > > that it is supporting." It's then (I think) mainly a job for=20 > > the implementor to do both aspects of state management in an=20 > > economical way (in particular, without duplication). So, I=20 > > think we need to consider the possible interactions between=20 > > the different parts of state management, and make sure they=20 > > get reflected as goals for NSIS design in terms of=20 > > flexibility and general usefulness of the protocol, but=20 > > without defining details of exactly how the different types=20 > > of state interact. > >=20 > > This is actually a special case of a more general issue. Look=20 > > also at draft-braden-2level-signal-arch-00.txt where there is=20 > > the related question of the split between CSTP and ALSP. The=20 > > general point is that we almost certainly can't have a pure=20 > > structure of independent layers (I would expect the ALSP-like=20 > > upper layer to hook into the operation of the lower layer=20 > > quite intimately rather than the other way round, but that's=20 > > more of a protocol design issue). The state management issue=20 > > is just one aspect of this. > >=20 > > So, I think the answer to your question is "yes and no" (if=20 > > you see what I mean...) > >=20 > > >=20 > > > BR/Kan Zhigang > > >=20 > > > -----Original Message----- > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: 2002=E5=B9=B46=E6=9C=8827=E6=97=A5 19:02 > > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > >=20 > > >=20 > > > Hi Zhigang, > > >=20 > > > Please see inline: > > >=20 > > > > -----Original Message----- > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > Sent: 27 June 2002 11:53 > > > > To: Hancock, Robert; nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > >=20 > > > >=20 > > > > Hi,=20 > > > >=20 > > > > In the draft about In-Band & Out-of-Band: > > > >=20 > > > > "In-band signaling means that the path followed by the user=20 > > > > data packets is the same as the path followed by signaling=20 > > > > messages. In other words, the signaling and data paths are=20 > > > > identical. Out-of-band signaling means that the path followed=20 > > > > by signaling messages might be different from the path used=20 > > > > by the user data packets. " > > > >=20 > > > > So in-band signaling is same as RSVP's operation mode?=20 > > >=20 > > > [reh] basically yes, from a topological ("where the messages=20 > > > go") point of view.=20 > > >=20 > > > > And=20 > > > > must it install soft states in each router it passed through=20 > > > > based on per-flow or per-class-flow? > > >=20 > > > [reh] that's one reasonable way for it to work. see 4.4 about=20 > > > general state management issues; there are several different=20 > > > sorts of state and several different ways to manage them. and=20 > > > some of the state management is an RMF responsibility. > > >=20 > > > > I think that it may be=20 > > > > better if in-band signaling is used in access network and=20 > > > > out-of-band signaling is used in backbone networks (i.e. the=20 > > > > out-of-band signaling is used for communcation between RMFs=20 > > > > which are responsible for the "resource" management=20 > > > > independent of concrete user traffic in control plane). Is=20 > > > > resource reservation really needed in backbone network now or=20 > > > > in the future?=20 > > >=20 > > > [reh] that's a good question. however, in our framework we=20 > > > tried hard to avoid saying that NSIS would work in particular=20 > > > ways in particular network parts. (ideally, I think there=20 > > > should be implementation and deployment flexibility within=20 > > > the protocol to allow this.) > > >=20 > > > >=20 > > > > I don't know why "the initial goal of NSIS is to concentrate=20 > > > > mainly on the in-band case".=20 > > >=20 > > > [reh] that's a WG chair/AD question. > > >=20 > > > >=20 > > > > BR/Kan Zhigang > > >=20 > > > Cheers, > > >=20 > > > Robert H. > > > >=20 > > > > -----Original Message----- > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > Sent: 2002=E5=B9=B46=E6=9C=8824=E6=97=A5 19:47 > > > > To: NSIS > > > > Subject: [NSIS] New framework draft > > > >=20 > > > >=20 > > > > Hi all, > > > >=20 > > > > A group of us who were involved in past NSIS framework=20 > > > > activities got together after the interim meeting to put=20 > > > > together a joint framework document in the form of an all-new=20 > > > > individual submission. It (roughly) follows the structure=20 > > > > that was introduced and refined at that meeting. > > > >=20 > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Abstract=20 > > > > =20 > > > > The NSIS working group is considering protocol=20 > developments in=20 > > > > signaling for resources for a traffic flow along its=20 > > path in the=20 > > > > network. The requirements for such signaling are being=20 > > > > developed in a=20 > > > > separate document; This Internet Draft proposes a=20 > > framework for=20 > > > > such signaling. This initial version provides a model for=20 > > > > describing=20 > > > > the entities that take part in the signaling and the=20 > > > ways in which=20 > > > > they can be used in different modes of operation. It also=20 > > > > discusses=20 > > > > the overall structure of such a signaling protocol.=20 > > Finally, it=20 > > > > considers the possible interactions of NSIS signaling=20 > > with other=20 > > > > protocols and functions, including security issues.=20 > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > While it works its way through the i-d editor queue, you can=20 > > > > find a copy here: > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > >=20 > > > > Comments are welcome. There is a list of open issue=20 > > > > highlights in section 3. > > > >=20 > > > > Cheers, > > > >=20 > > > > Robert Hancock > > > >=20 > > >=20 > >=20 >=20 --------------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 Fri Jun 28 06:19: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 GAA16677 for ; Fri, 28 Jun 2002 06:19:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA10687 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 06: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 GAA09980; Fri, 28 Jun 2002 06:06: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 GAA09946 for ; Fri, 28 Jun 2002 06:06:53 -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 GAA16364 for ; Fri, 28 Jun 2002 06:06:06 -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 g5SA7Ji00595 for ; Fri, 28 Jun 2002 13:07:19 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 13:06:51 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 12:42:42 +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] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 12:42:40 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65595@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft: In-Band & Out-of-Band Thread-Index: AcIefzSaPKx3BV4OTEKaMq6TbXZJEwAAb1SAAAGrhaA= To: , , X-OriginalArrivalTime: 28 Jun 2002 09:42:42.0239 (UTC) FILETIME=[260A4CF0:01C21E88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id GAA09947 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 Kan, > I am more confused about 'node' is for 'box', but what in the > box, a part of netwok or a whole network or whatever? Does > the data pass through the box? How to understand the data > path, based on per-router or per-network? Is NSIS Framework > independent of the true networks and is it only abstract > concept over the different environments? I cannot image how > to deploy it in the future. For IPv6, RFC 2460 defines the following terms: node - a device that implements IPv6. router - a node that forwards IPv6 packets not explicitly addressed to itself. [See Note below]. host - any node that is not a router. [See Note below]. Note: it is possible, though unusual, for a device with multiple interfaces to be configured to forward non-self-destined packets arriving from some set (fewer than all) of its interfaces, and to discard non-self-destined packets arriving from its other interfaces. Such a device must obey the protocol requirements for routers when receiving packets from, and interacting with neighbors over, the former (forwarding) interfaces. It must obey the protocol requirements for hosts when receiving packets from, and interacting with neighbors over, the latter (non-forwarding) interfaces. For me, this is the easier way to think about NSIS entities. More specifically, An NSIS entitity as most likely a protocol instance of the NSIS protocol in a node. Under most circumstances, I don't see a single NSIS entity that would be distributed over multiple nodes. I would imagine that NSIS entities would most likely be in the ingress and egress points of an administrative domain, for example. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 28 06:24: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 GAA16828 for ; Fri, 28 Jun 2002 06:24:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA10746 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 06:24: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 GAA10198; Fri, 28 Jun 2002 06:10: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 GAA10094 for ; Fri, 28 Jun 2002 06:10:24 -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 GAA16439 for ; Fri, 28 Jun 2002 06:09:37 -0400 (EDT) From: Zhigang.Kan@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 g5SA8ud09297 for ; Fri, 28 Jun 2002 13:08:56 +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, 28 Jun 2002 13:10:22 +0300 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 13:10:21 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 18:09:52 +0800 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] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 18:07:30 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD07E3CB@beebe001.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft: In-Band & Out-of-Band Thread-Index: AcIehxkzdbhXRuL6Ssa9rt+PkKcpQAAAaFGg To: , X-OriginalArrivalTime: 28 Jun 2002 10:09:52.0144 (UTC) FILETIME=[F18A1100:01C21E8B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id GAA10095 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 Robert, Till now, I understood the definition of NE. Thank you. :-) It is right that we must have the common understanding of the terms, so we can continue the discussion further. One more thing, If one/more router(s) on the data path does not support RMF (as you said: if you have a distributed approach to resource management, i guess we would typically expect most nodes would have a resource management responsibility, but there's no requirement for every node to do something with resource management.), how about in this case? Can the QoS of data on this path be affected by these routers? Next I would like to discuss the relationship of modes of NSIS protocol operation such as how the end-to-end, edge-to-edge, and end-to-edge signaling take effects when the per-flow/per-class-flow traffic is initiated by a host. Nice weekend. BR/Kan Zhigang -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 2002å¹´6月28æ—¥ 17:33 To: Hancock, Robert; Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band hi - minor correction - in 3rd sentence below, s/nodes/hosts/. r. > -----Original Message----- > From: Hancock, Robert > Sent: 28 June 2002 10:31 > To: 'Zhigang.Kan@nokia.com'; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > Hi Zhigang, > > Apologies for maybe informal language. By 'box' I really mean > typically a physical thing you plug into a power supply, with > wires carrying packets into and out of it. So, usually it's a > host or a router. If signalling only follows the data path > (which is considered at the router level, not the network > level), the only relevant nodes can be the data flow > endpoints, and the only relevant routers can be the routers > the flow passes through. > > We've tried to describe things in terms of signalling going > between signalling entities rather than hosts/routers and so > on; one of the goals of this is to aim for concepts and > terminology to describe the signalling that are re-usable > if/when we subsequently think about signalling paths that are > less constrained. > > It may be (I get the impression) that the level of > abstraction in the framework makes it hard to get a grip on. > I'm not sure what would be the best way to handle this (maybe > some concrete example scenarios or something). > > We didn't want to make all the definitions very concrete, > since that implies building in assumptions about particular > application domains. Specifically, we have two potential > degrees of freedom about NSIS applicability which we've tried > to reflect by using more abstract language: > *) what sort of resources are signalled for > *) what sort of signalling paths are traversed > Currently, the first is in scope and the second not. I hope > we can avoid too long confusion about the > node/entity/network/whatever issue, because if we can't, > we'll probably be encouraged to re-write everything in terms > of routers and hosts, which will make any future extension to > other cases much harder. > > Cheers, > > Robert H. > > ps apologies about my email disclaimer, it's not entirely > under my control to fix it, though we're doing what we can. i > am aware that i am sending this email to a public mailing list ... > > > > -----Original Message----- > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > Sent: 28 June 2002 10:10 > > To: Hancock, Robert; nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > Hi Robert, > > > > I am more confused about 'node' is for 'box', but what in the > > box, a part of netwok or a whole network or whatever? Does > > the data pass through the box? How to understand the data > > path, based on per-router or per-network? Is NSIS Framework > > independent of the true networks and is it only abstract > > concept over the different environments? I cannot image how > > to deploy it in the future. > > > > BR/Kan Zhigang > > > > > > > > -----Original Message----- > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: 2002å¹´6月28æ—¥ 16:28 > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > Hi Zhigang, > > > > Please see inline below. > > > > Cheers, > > > > Robert H. > > > > ps apologies about my email disclaimer, it's not entirely > > under my control to fix it, though we're doing what we can. i > > am aware that i am sending this email to a public mailing list ... > > > > > -----Original Message----- > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > Sent: 28 June 2002 08:43 > > > To: Hancock, Robert; nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > Hi Robert, > > > > > > Q1: "Node" used in your terminology can be a router, an end > > > host or a server, right? > > > > [reh] yes, in the broadest sense ('node' is a fancy name for > > 'box'). if you respect the 'on-path' restriction, a node that > > processes NSIS signalling must be on the data path, which > > probably rules out the 'server' case. > > > > > In the case of distributed RMF, must > > > each node have the resource management function in a NSIS domain? > > > > [reh] if you have a distributed approach to resource > > management, i guess we would typically expect most nodes > > would have a resource management responsibility, but there's > > no requirement for every node to do something with resource > > management. in particular: > > 1) not every node has to process NSIS messages (cf. RSVP > > operation over non-RSVP clouds) > > 2) even if a node does process NSIS messages, it might do so > > for reasons not associated with resource management. > > > > > > > > Q2: The RMF is responsible for all network provisioning and > > > resource allocation functions, and "some" of the state > > > management is an RMF responsibility. How about the "other" of > > > the state management, and it is refered to the state > > > management mechanism of NSIS related with "Refresh" message? > > > If so, what relationship between these two parts of state > > > management? Is it out of the scope of NSIS? I hope answer is no. > > > > [reh] this is a hard question to answer, and a hard question > > in general. > > > > 1. It's clear that to do resource management, you need to > > store some state information. That information might be at > > the flow level, or some 'resource class' level, or something > > else. Because the state you need to store depends on the > > resource you are trying to manage and the precision with > > which you need to manage it, we don't think NSIS can define > > how this is done. > > > > 2. You also need state to make a protocol operate correctly. > > This could include all (or none) of: > > *) information about how to reverse-path route messages for a flow > > *) information about who to send an acknowledgement to and when > > *) information about when to send a refresh message > > *) information about who was authenticated when a > reservation was made > > *) and so on > > This is all in NSIS scope to worry about. Most of it is per-flow. > > > > 3. The relationship between these two types of state is > > something we discussed, but only in outline. I think a basic > > design goal could be stated as: > > "It should be possible to use [a|the] NSIS protocol in such a > > way that it only requires the minimum of state storage, in > > particular no more than the resource management mechanism > > that it is supporting." It's then (I think) mainly a job for > > the implementor to do both aspects of state management in an > > economical way (in particular, without duplication). So, I > > think we need to consider the possible interactions between > > the different parts of state management, and make sure they > > get reflected as goals for NSIS design in terms of > > flexibility and general usefulness of the protocol, but > > without defining details of exactly how the different types > > of state interact. > > > > This is actually a special case of a more general issue. Look > > also at draft-braden-2level-signal-arch-00.txt where there is > > the related question of the split between CSTP and ALSP. The > > general point is that we almost certainly can't have a pure > > structure of independent layers (I would expect the ALSP-like > > upper layer to hook into the operation of the lower layer > > quite intimately rather than the other way round, but that's > > more of a protocol design issue). The state management issue > > is just one aspect of this. > > > > So, I think the answer to your question is "yes and no" (if > > you see what I mean...) > > > > > > > > BR/Kan Zhigang > > > > > > -----Original Message----- > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: 2002å¹´6月27æ—¥ 19:02 > > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > Hi Zhigang, > > > > > > Please see inline: > > > > > > > -----Original Message----- > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > Sent: 27 June 2002 11:53 > > > > To: Hancock, Robert; nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > Hi, > > > > > > > > In the draft about In-Band & Out-of-Band: > > > > > > > > "In-band signaling means that the path followed by the user > > > > data packets is the same as the path followed by signaling > > > > messages. In other words, the signaling and data paths are > > > > identical. Out-of-band signaling means that the path followed > > > > by signaling messages might be different from the path used > > > > by the user data packets. " > > > > > > > > So in-band signaling is same as RSVP's operation mode? > > > > > > [reh] basically yes, from a topological ("where the messages > > > go") point of view. > > > > > > > And > > > > must it install soft states in each router it passed through > > > > based on per-flow or per-class-flow? > > > > > > [reh] that's one reasonable way for it to work. see 4.4 about > > > general state management issues; there are several different > > > sorts of state and several different ways to manage them. and > > > some of the state management is an RMF responsibility. > > > > > > > I think that it may be > > > > better if in-band signaling is used in access network and > > > > out-of-band signaling is used in backbone networks (i.e. the > > > > out-of-band signaling is used for communcation between RMFs > > > > which are responsible for the "resource" management > > > > independent of concrete user traffic in control plane). Is > > > > resource reservation really needed in backbone network now or > > > > in the future? > > > > > > [reh] that's a good question. however, in our framework we > > > tried hard to avoid saying that NSIS would work in particular > > > ways in particular network parts. (ideally, I think there > > > should be implementation and deployment flexibility within > > > the protocol to allow this.) > > > > > > > > > > > I don't know why "the initial goal of NSIS is to concentrate > > > > mainly on the in-band case". > > > > > > [reh] that's a WG chair/AD question. > > > > > > > > > > > BR/Kan Zhigang > > > > > > Cheers, > > > > > > Robert H. > > > > > > > > -----Original Message----- > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > Sent: 2002å¹´6月24æ—¥ 19:47 > > > > To: NSIS > > > > Subject: [NSIS] New framework draft > > > > > > > > > > > > Hi all, > > > > > > > > A group of us who were involved in past NSIS framework > > > > activities got together after the interim meeting to put > > > > together a joint framework document in the form of an all-new > > > > individual submission. It (roughly) follows the structure > > > > that was introduced and refined at that meeting. > > > > > > > > ============================================================== > > > > ============ > > > > Abstract > > > > > > > > The NSIS working group is considering protocol > developments in > > > > signaling for resources for a traffic flow along its > > path in the > > > > network. The requirements for such signaling are being > > > > developed in a > > > > separate document; This Internet Draft proposes a > > framework for > > > > such signaling. This initial version provides a model for > > > > describing > > > > the entities that take part in the signaling and the > > > ways in which > > > > they can be used in different modes of operation. It also > > > > discusses > > > > the overall structure of such a signaling protocol. > > Finally, it > > > > considers the possible interactions of NSIS signaling > > with other > > > > protocols and functions, including security issues. > > > > ============================================================== > > > > ============ > > > > > > > > While it works its way through the i-d editor queue, you can > > > > find a copy here: > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > Comments are welcome. There is a list of open issue > > > > highlights in section 3. > > > > > > > > Cheers, > > > > > > > > Robert Hancock > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 28 06:42: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 GAA18472 for ; Fri, 28 Jun 2002 06:42:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13351 for nsis-archive@odin.ietf.org; Fri, 28 Jun 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 GAA10846; Fri, 28 Jun 2002 06:30: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 GAA10806 for ; Fri, 28 Jun 2002 06:30:00 -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 GAA16922 for ; Fri, 28 Jun 2002 06:29:13 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 11:29:50 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA3F3@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Zhigang.Kan@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 11:29:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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="utf-8" Content-Transfer-Encoding: quoted-printable Hi Zhigang, If you have an NSIS-unaware router on the path, in the time honoured = phrase, "your mileage may vary". There are two aspects: *) as a protocol, NSIS has to operate correctly even if some = intermediate nodes are not NSIS aware. this has quite significant = implications for security aspects, for example.=20 *) if an intermediate node is NSIS unaware, or is NSIS aware but = doesn't do any management for some particular resource, then there's = nothing NSIS can do directly to help the resource management at that = node. That doesn't stop you using some other technique to control the = resource at that node (some variant of SNMP or COPS or RMD or = whatever), but so far as NSIS is concerned, all of that would be hidden = inside your RMF implementation. i'll look forward to the 'modes of operation' questions! cheers, robert h. ps apologies about my email disclaimer, it's not entirely under my = control to fix it, though we're doing what we can. i am aware that i am = sending this email to a public mailing list ... > -----Original Message----- > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > Sent: 28 June 2002 11:08 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band >=20 >=20 > Hi Robert, >=20 > Till now, I understood the definition of NE. Thank you. :-)=20 > It is right that we must have the common understanding of the=20 > terms, so we can continue the discussion further. >=20 > One more thing, If one/more router(s) on the data path does=20 > not support RMF (as you said: if you have a distributed=20 > approach to resource management, i guess we would typically=20 > expect most nodes would have a resource management=20 > responsibility, but there's no requirement for every node to=20 > do something with resource management.), how about in this=20 > case? Can the QoS of data on this path be affected by these routers? >=20 > Next I would like to discuss the relationship of modes of=20 > NSIS protocol operation such as how the end-to-end,=20 > edge-to-edge, and end-to-edge signaling take effects when the=20 > per-flow/per-class-flow traffic is initiated by a host. >=20 > Nice weekend. >=20 > BR/Kan Zhigang >=20 > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 2002=E5=B9=B46=E6=9C=8828=E6=97=A5 17:33 > To: Hancock, Robert; Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band >=20 >=20 > hi - minor correction - in 3rd sentence below, s/nodes/hosts/. >=20 > r. >=20 > > -----Original Message----- > > From: Hancock, Robert=20 > > Sent: 28 June 2002 10:31 > > To: 'Zhigang.Kan@nokia.com'; nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > >=20 > >=20 > > Hi Zhigang, > >=20 > > Apologies for maybe informal language. By 'box' I really mean=20 > > typically a physical thing you plug into a power supply, with=20 > > wires carrying packets into and out of it. So, usually it's a=20 > > host or a router. If signalling only follows the data path=20 > > (which is considered at the router level, not the network=20 > > level), the only relevant nodes can be the data flow=20 > > endpoints, and the only relevant routers can be the routers=20 > > the flow passes through. > >=20 > > We've tried to describe things in terms of signalling going=20 > > between signalling entities rather than hosts/routers and so=20 > > on; one of the goals of this is to aim for concepts and=20 > > terminology to describe the signalling that are re-usable=20 > > if/when we subsequently think about signalling paths that are=20 > > less constrained. > >=20 > > It may be (I get the impression) that the level of=20 > > abstraction in the framework makes it hard to get a grip on.=20 > > I'm not sure what would be the best way to handle this (maybe > > some concrete example scenarios or something). > >=20 > > We didn't want to make all the definitions very concrete,=20 > > since that implies building in assumptions about particular=20 > > application domains. Specifically, we have two potential=20 > > degrees of freedom about NSIS applicability which we've tried=20 > > to reflect by using more abstract language: > > *) what sort of resources are signalled for > > *) what sort of signalling paths are traversed > > Currently, the first is in scope and the second not. I hope=20 > > we can avoid too long confusion about the=20 > > node/entity/network/whatever issue, because if we can't,=20 > > we'll probably be encouraged to re-write everything in terms=20 > > of routers and hosts, which will make any future extension to=20 > > other cases much harder. > >=20 > > Cheers, > >=20 > > Robert H. > >=20 > > ps apologies about my email disclaimer, it's not entirely=20 > > under my control to fix it, though we're doing what we can. i=20 > > am aware that i am sending this email to a public mailing list ... > >=20 > >=20 > > > -----Original Message----- > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > Sent: 28 June 2002 10:10 > > > To: Hancock, Robert; nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > >=20 > > >=20 > > > Hi Robert, > > >=20 > > > I am more confused about 'node' is for 'box', but what in the=20 > > > box, a part of netwok or a whole network or whatever? Does=20 > > > the data pass through the box? How to understand the data=20 > > > path, based on per-router or per-network? Is NSIS Framework=20 > > > independent of the true networks and is it only abstract=20 > > > concept over the different environments? I cannot image how=20 > > > to deploy it in the future. > > >=20 > > > BR/Kan Zhigang > > >=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: 2002=E5=B9=B46=E6=9C=8828=E6=97=A5 16:28 > > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > >=20 > > >=20 > > > Hi Zhigang, > > >=20 > > > Please see inline below. > > >=20 > > > Cheers, > > >=20 > > > Robert H. > > >=20 > > > ps apologies about my email disclaimer, it's not entirely=20 > > > under my control to fix it, though we're doing what we can. i=20 > > > am aware that i am sending this email to a public mailing list = ... > > >=20 > > > > -----Original Message----- > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > Sent: 28 June 2002 08:43 > > > > To: Hancock, Robert; nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > >=20 > > > >=20 > > > > Hi Robert, > > > >=20 > > > > Q1: "Node" used in your terminology can be a router, an end=20 > > > > host or a server, right?=20 > > >=20 > > > [reh] yes, in the broadest sense ('node' is a fancy name for=20 > > > 'box'). if you respect the 'on-path' restriction, a node that=20 > > > processes NSIS signalling must be on the data path, which=20 > > > probably rules out the 'server' case. > > >=20 > > > > In the case of distributed RMF, must=20 > > > > each node have the resource management function in a=20 > NSIS domain? > > >=20 > > > [reh] if you have a distributed approach to resource=20 > > > management, i guess we would typically expect most nodes=20 > > > would have a resource management responsibility, but there's=20 > > > no requirement for every node to do something with resource=20 > > > management. in particular: > > > 1) not every node has to process NSIS messages (cf. RSVP=20 > > > operation over non-RSVP clouds) > > > 2) even if a node does process NSIS messages, it might do so=20 > > > for reasons not associated with resource management. > > >=20 > > > >=20 > > > > Q2: The RMF is responsible for all network provisioning and=20 > > > > resource allocation functions, and "some" of the state=20 > > > > management is an RMF responsibility. How about the "other" of=20 > > > > the state management, and it is refered to the state=20 > > > > management mechanism of NSIS related with "Refresh" message?=20 > > > > If so, what relationship between these two parts of state=20 > > > > management? Is it out of the scope of NSIS? I hope answer is = no. > > >=20 > > > [reh] this is a hard question to answer, and a hard question=20 > > > in general. > > >=20 > > > 1. It's clear that to do resource management, you need to=20 > > > store some state information. That information might be at=20 > > > the flow level, or some 'resource class' level, or something=20 > > > else. Because the state you need to store depends on the=20 > > > resource you are trying to manage and the precision with=20 > > > which you need to manage it, we don't think NSIS can define=20 > > > how this is done. > > >=20 > > > 2. You also need state to make a protocol operate correctly.=20 > > > This could include all (or none) of: > > > *) information about how to reverse-path route messages for a = flow > > > *) information about who to send an acknowledgement to and when > > > *) information about when to send a refresh message > > > *) information about who was authenticated when a=20 > > reservation was made > > > *) and so on > > > This is all in NSIS scope to worry about. Most of it is per-flow. > > >=20 > > > 3. The relationship between these two types of state is=20 > > > something we discussed, but only in outline. I think a basic=20 > > > design goal could be stated as: > > > "It should be possible to use [a|the] NSIS protocol in such a=20 > > > way that it only requires the minimum of state storage, in=20 > > > particular no more than the resource management mechanism=20 > > > that it is supporting." It's then (I think) mainly a job for=20 > > > the implementor to do both aspects of state management in an=20 > > > economical way (in particular, without duplication). So, I=20 > > > think we need to consider the possible interactions between=20 > > > the different parts of state management, and make sure they=20 > > > get reflected as goals for NSIS design in terms of=20 > > > flexibility and general usefulness of the protocol, but=20 > > > without defining details of exactly how the different types=20 > > > of state interact. > > >=20 > > > This is actually a special case of a more general issue. Look=20 > > > also at draft-braden-2level-signal-arch-00.txt where there is=20 > > > the related question of the split between CSTP and ALSP. The=20 > > > general point is that we almost certainly can't have a pure=20 > > > structure of independent layers (I would expect the ALSP-like=20 > > > upper layer to hook into the operation of the lower layer=20 > > > quite intimately rather than the other way round, but that's=20 > > > more of a protocol design issue). The state management issue=20 > > > is just one aspect of this. > > >=20 > > > So, I think the answer to your question is "yes and no" (if=20 > > > you see what I mean...) > > >=20 > > > >=20 > > > > BR/Kan Zhigang > > > >=20 > > > > -----Original Message----- > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > Sent: 2002=E5=B9=B46=E6=9C=8827=E6=97=A5 19:02 > > > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > >=20 > > > >=20 > > > > Hi Zhigang, > > > >=20 > > > > Please see inline: > > > >=20 > > > > > -----Original Message----- > > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > > Sent: 27 June 2002 11:53 > > > > > To: Hancock, Robert; nsis@ietf.org > > > > > Subject: RE: [NSIS] New framework draft: In-Band & = Out-of-Band > > > > >=20 > > > > >=20 > > > > > Hi,=20 > > > > >=20 > > > > > In the draft about In-Band & Out-of-Band: > > > > >=20 > > > > > "In-band signaling means that the path followed by the user=20 > > > > > data packets is the same as the path followed by signaling=20 > > > > > messages. In other words, the signaling and data paths are=20 > > > > > identical. Out-of-band signaling means that the path followed = > > > > > by signaling messages might be different from the path used=20 > > > > > by the user data packets. " > > > > >=20 > > > > > So in-band signaling is same as RSVP's operation mode?=20 > > > >=20 > > > > [reh] basically yes, from a topological ("where the messages=20 > > > > go") point of view.=20 > > > >=20 > > > > > And=20 > > > > > must it install soft states in each router it passed through=20 > > > > > based on per-flow or per-class-flow? > > > >=20 > > > > [reh] that's one reasonable way for it to work. see 4.4 about=20 > > > > general state management issues; there are several different=20 > > > > sorts of state and several different ways to manage them. and=20 > > > > some of the state management is an RMF responsibility. > > > >=20 > > > > > I think that it may be=20 > > > > > better if in-band signaling is used in access network and=20 > > > > > out-of-band signaling is used in backbone networks (i.e. the=20 > > > > > out-of-band signaling is used for communcation between RMFs=20 > > > > > which are responsible for the "resource" management=20 > > > > > independent of concrete user traffic in control plane). Is=20 > > > > > resource reservation really needed in backbone network now or = > > > > > in the future?=20 > > > >=20 > > > > [reh] that's a good question. however, in our framework we=20 > > > > tried hard to avoid saying that NSIS would work in particular=20 > > > > ways in particular network parts. (ideally, I think there=20 > > > > should be implementation and deployment flexibility within=20 > > > > the protocol to allow this.) > > > >=20 > > > > >=20 > > > > > I don't know why "the initial goal of NSIS is to concentrate=20 > > > > > mainly on the in-band case".=20 > > > >=20 > > > > [reh] that's a WG chair/AD question. > > > >=20 > > > > >=20 > > > > > BR/Kan Zhigang > > > >=20 > > > > Cheers, > > > >=20 > > > > Robert H. > > > > >=20 > > > > > -----Original Message----- > > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > > Sent: 2002=E5=B9=B46=E6=9C=8824=E6=97=A5 19:47 > > > > > To: NSIS > > > > > Subject: [NSIS] New framework draft > > > > >=20 > > > > >=20 > > > > > Hi all, > > > > >=20 > > > > > A group of us who were involved in past NSIS framework=20 > > > > > activities got together after the interim meeting to put=20 > > > > > together a joint framework document in the form of an all-new = > > > > > individual submission. It (roughly) follows the structure=20 > > > > > that was introduced and refined at that meeting. > > > > >=20 > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > Abstract=20 > > > > > =20 > > > > > The NSIS working group is considering protocol=20 > > developments in=20 > > > > > signaling for resources for a traffic flow along its=20 > > > path in the=20 > > > > > network. The requirements for such signaling are being=20 > > > > > developed in a=20 > > > > > separate document; This Internet Draft proposes a=20 > > > framework for=20 > > > > > such signaling. This initial version provides a model for=20 > > > > > describing=20 > > > > > the entities that take part in the signaling and the=20 > > > > ways in which=20 > > > > > they can be used in different modes of operation. It also=20 > > > > > discusses=20 > > > > > the overall structure of such a signaling protocol.=20 > > > Finally, it=20 > > > > > considers the possible interactions of NSIS signaling=20 > > > with other=20 > > > > > protocols and functions, including security issues.=20 > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > >=20 > > > > > While it works its way through the i-d editor queue, you can=20 > > > > > find a copy here: > > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > >=20 > > > > > Comments are welcome. There is a list of open issue=20 > > > > > highlights in section 3. > > > > >=20 > > > > > Cheers, > > > > >=20 > > > > > Robert Hancock > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 --------------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 Fri Jun 28 06:47: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 GAA18681 for ; Fri, 28 Jun 2002 06:47:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13879 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 06:48: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 GAA11554; Fri, 28 Jun 2002 06:34: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 GAA11525 for ; Fri, 28 Jun 2002 06:34: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 GAA17079 for ; Fri, 28 Jun 2002 06:34:01 -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 g5SAZEi22414 for ; Fri, 28 Jun 2002 13:35:14 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 13:34:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 13:34: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="utf-8" Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Fri, 28 Jun 2002 13:34:44 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6559A@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft: In-Band & Out-of-Band Thread-Index: AcIejtaBXHu6Ga+5QMqyypfennq0gQAACIag To: , , X-OriginalArrivalTime: 28 Jun 2002 10:34:46.0248 (UTC) FILETIME=[6C183E80:01C21E8F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id GAA11526 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 Robert, > If you have an NSIS-unaware router on the path, in the time > honoured phrase, "your mileage may vary". There are two aspects: > *) as a protocol, NSIS has to operate correctly even if some > intermediate nodes are not NSIS aware. this has quite > significant implications for security aspects, for example. > *) if an intermediate node is NSIS unaware, or is NSIS aware > but doesn't do any management for some particular resource, > then there's nothing NSIS can do directly to help the > resource management at that node. That doesn't stop you using > some other technique to control the resource at that node > (some variant of SNMP or COPS or RMD or whatever), but so far > as NSIS is concerned, all of that would be hidden inside your > RMF implementation. I actually think that it is practical that intermediate routers are NSIS-unware. The most important parts of an NSIS network would be the ingress & egress points. Assuming one did a competent job of network configuration & provisioning, this may be enough in many cases. Also, it would be entirely reasonable to (and entirely out of scope of NSIS to standardize) use some protocol for communicating with resource management, such as a bandwidth broken, if this was something that you wanted to do. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 28 06:49: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 GAA18823 for ; Fri, 28 Jun 2002 06:49:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA14011 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 06:50: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 GAA11816; Fri, 28 Jun 2002 06:37: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 GAA11783 for ; Fri, 28 Jun 2002 06:36:58 -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 GAA17317; Fri, 28 Jun 2002 06:36:09 -0400 (EDT) Message-Id: <200206281036.GAA17317@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, 28 Jun 2002 06:36:09 -0400 Subject: [NSIS] I-D ACTION:draft-choi-metro-signaling-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 : Consideration of RSVP-TE Extension for Metro Network Author(s) : J. Choi, Y. Yoo Filename : draft-choi-metro-signaling-00.txt Pages : 8 Date : 27-Jun-02 This draft mentions the bandwidth reservation in Metro Network. At first, this lists the issues that should be generally checked for bandwidth reservation, and is intended to point out RSVP-TE for Metro Network. Moreover, this focuses on consideration issues to understand whether the existing RSVP-TE supports the demands for bandwidth reservation in Metro Network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-choi-metro-signaling-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-choi-metro-signaling-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-choi-metro-signaling-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: <20020627132957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-choi-metro-signaling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-choi-metro-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627132957.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 Jun 28 06:50: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 GAA18895 for ; Fri, 28 Jun 2002 06:50:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA14197 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 06:51: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 GAA12187; Fri, 28 Jun 2002 06:38: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 GAA12140 for ; Fri, 28 Jun 2002 06:38:23 -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 GAA17707; Fri, 28 Jun 2002 06:37:35 -0400 (EDT) Message-Id: <200206281037.GAA17707@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, 28 Jun 2002 06:37:35 -0400 Subject: [NSIS] I-D ACTION:draft-schelen-nsis-opopsig-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 : On path and off path signaling for NSIS Author(s) : A. Couturier, O. Schelen Filename : draft-schelen-nsis-opopsig-00.txt Pages : 10 Date : 27-Jun-02 The NSIS Work group will develop the requirements, architecture and protocols for the next IETF steps on signaling. Two approaches about the signaling model have been discussed: on-path and off-path. This draft provides a conceptual comparison between on-path and off-path signaling together with reasons for why an NSIS protocol should be designed to support both cases. The collection of data objects to be carried by the protocol should basically be the same in both cases and will evolve over time as new usages for NSIS protocol are identified. The differences between the two flavors of this NSIS protocol are then explained. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schelen-nsis-opopsig-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-schelen-nsis-opopsig-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-schelen-nsis-opopsig-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: <20020627133238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schelen-nsis-opopsig-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-schelen-nsis-opopsig-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627133238.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 Jun 28 06:51: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 GAA18975 for ; Fri, 28 Jun 2002 06:51:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA14288 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 06:52: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 GAA12475; Fri, 28 Jun 2002 06:39: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 GAA12432 for ; Fri, 28 Jun 2002 06:39: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 GAA17916; Fri, 28 Jun 2002 06:38:35 -0400 (EDT) Message-Id: <200206281038.GAA17916@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, 28 Jun 2002 06:38:35 -0400 Subject: [NSIS] I-D ACTION:draft-brunner-nsis-mbox-fmwk-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 : Middlebox Signaling in a NSIS framework Author(s) : M. Brunner, M. Stiemerling Filename : draft-brunner-nsis-mbox-fmwk-00.txt Pages : 6 Date : 27-Jun-02 The Next Steps in Signaling (NSIS) working group has started looking into signaling for QoS in various cases. In this draft, we show the similarities and differences of signaling for QoS versus signaling for NAT and firewall traversal. It seams that there are quite a number of similarities, which might make sense to use a potential NSIS protocol for NAT and firewall traversal as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-nsis-mbox-fmwk-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-brunner-nsis-mbox-fmwk-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-brunner-nsis-mbox-fmwk-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: <20020627152127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brunner-nsis-mbox-fmwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brunner-nsis-mbox-fmwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627152127.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 Jun 28 10:36: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 KAA28629 for ; Fri, 28 Jun 2002 10:36:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29716 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 10:37: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 KAA28385; Fri, 28 Jun 2002 10:19: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 KAA28294 for ; Fri, 28 Jun 2002 10:19:39 -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 KAA27774 for ; Fri, 28 Jun 2002 10:18:51 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5SEJXRb022512; Fri, 28 Jun 2002 16:19:33 +0200 (MEST) Received: from wrtw014.wrn.ki.sw.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA08324; Fri, 28 Jun 2002 16:19:32 +0200 Received: from wrtw014 by wrtw014.wrn.ki.sw.ericsson.se (8.8.8+Sun/client-1.3) id QAA06467; Fri, 28 Jun 2002 16:19:32 +0200 (MET DST) Message-Id: <200206281419.QAA06467@wrtw014.wrn.ki.sw.ericsson.se> Date: Fri, 28 Jun 2002 16:19:32 +0200 (MET DST) From: Gabor Fodor Reply-To: Gabor Fodor To: cedric@iprg.nokia.com, hemant.chaskar@nokia.com Cc: nsis@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xulppB/f2PDTaW77JTFbFw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Subject: [NSIS] Comments on draft-westphal-nsis-qos-mobileip-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 Hi Cedric and Hemant, I understand from the mail discussions and especially from the interim meeting, that the WG is encouraged to take into consideration the requirements formulated in : http://www.ietf.org/internet-drafts/ draft-ietf-mobileip-qos-requirements-02.txt From that perspective, I think that your draft is an important input and can evolve to a good design base. However, I also understand that the group is in the process of discussing the requirements and the framework drafts, so I am not sure whether starting discussing this draft is appropriate right now. Anyway, here comes a set of comments from my perspective. Best regards /Gabor --------------------------------------------------------------- 1 I agree that we need to consider a QoS signaling that works in a mobile/wireless environment and that the wireless bandwidth economy must be an important factor. From this point of view, I would like to see a more clear discussion on the requirements that this draft provides the solution for. Clearly, we have at least two important input documents: the NSIS requirement doc and the mobileip-qos-requirements doc. I think that your framework draft should try to identify which of these requirements it considers important and which new ones it adds to those. 2 I also agree that we need to differentiate between the "edge" signaling, the context transfer signaling and the "data path signaling". We need to be careful with statements like "lightweight signaling mechanism required over the wireless link". We indeed want to minimize both the number and the length of signaling messages over the air (so in that sense it should be lightweight), but we do want to provide enough information to efficiently configure wireless resources, often per user flow and per-flow state maintenance with support of bi-directional assymmetric reservation, etc. I think that the draft should define what is meant by "wireless bandwidth economy" and discuss more the requirements specifically on the edge signaling. 3 The draft talks about the negotiation procedures (in 4.2). In my opinion the draft should identify the requirement more clearly, preferably with a reference to either the NSIS or the mobile IP requirement draft. Is there a difference between negotiation (which takes place upon QoS initiation time) and QoS adaptation signaling which may take place upon hand-over ? 4 I am not sure that it is meaningful at this point to start discussing specific solution approaches. You seem to propose to use ICMP as a design base for both edge signaling and for context transfer (AR to AR). At least for the edge signaling, we need to consider the edge specific requirements before we start discussing what existing or new protocol can be the design base for that. 5 You mention RFC2998 as one of your basic references, which I think is a very useful RFC in this context as well. However, from the draft it is not clear how you use that in the proposed architecture. (Since ICMP seems to be the base and not RSVP.) 6 You identify QoS release as a necessary functionality. Here there is a need to identify if the protocol should support soft state (in which case this explicit QoS release may not be necessary) or not. 7 As a minor detail issue, I see some problems with the definition of the cross-over router. I believe that your definition in 4.1.3 would identify several routers as cross-over router, whereas later on it seems that only the first merging point is really used as cross-over router. By the way, the notion of cross-over router in my opinion should be introduced when you present the whole model around the figure in Section 1, but this is a presentation issue. > From: Cedric Westphal > To: nsis@ietf.org > CC: hemant.chaskar@nokia.com > Content-Transfer-Encoding: 7bit > Content-Transfer-Encoding: 7bit > Subject: [NSIS] QoS framework. > Hi all, > > we put together a document representing our perspective on a > NSIS qos signaling framework. > > Here is the abstract: > > Abstract > > This draft provides a framework for QoS signaling that is optimized > for Mobile IP handoffs. It covers the horizontal signaling between > access routers (ARs) as well as the vertical signaling along the > packet data path, both of which are triggered by handoff of mobile > node (MN). The key design goals are wireless bandwidth economy, > fast QoS establishment along the new data path after handoff and > secure protocol operation. > > > The document will eventually be available from the i-d editor queue. However, > only after Yokohama meeting. You can find it at: > http://people.nokia.net/~cedric/Papers/draft-westphal-nsis-qos-mobileip-00.txt > in the meantime. > Please send your comments, > > Cedric & Hemant. > > > > > _______________________________________________ > 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 Jun 28 11:11: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 LAA00186 for ; Fri, 28 Jun 2002 11:11:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01790 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 11:12: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 KAA00628; Fri, 28 Jun 2002 10:59: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 KAA00600 for ; Fri, 28 Jun 2002 10:59:01 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29572 for ; Fri, 28 Jun 2002 10:58:05 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g5SEsYJ29481; Fri, 28 Jun 2002 16:54:34 +0200 Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt To: "Georgios Karagiannis (ELN)" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 28 Jun 2002 16:57:54 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 06/28/2002 16:58:01 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, Thanks a lot for your comments. I have some replies inline. Cheers, Sven. "Georgios Karagiannis (ELN)" on 27/06/2002 17:54:58 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, nsis@ietf.org cc: Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Hi Sven I will only comment your draft starting from Section 5. Main comment that I have is related to the fact that you somehow emphasise that the per-class states complicate the failure notification and recovery issues, while I think that failure notification and recovery issues are independent of the type of these states. [sven] In general, per-class state has the effect of losing the link between a certain initiator and its associated reservation. As such, it causes an issues for failure notification because of the absence of state information on where to send the notification. Another comment is related to the fact that you use a limted number of solutions, as the NSIS solutions, while these solutions might be just examples. [sven] That is true. Please feel free to propose other examples that you feel might raise the same or other issues regarding resilience in nsis. See more comments in line with your text (copied from your draft). My comments are given betrween <<>>. Best regards, Georgios ------------ 5. Failure description 5.1. Internal data plane failures Data plane failures can result from the breakdown or misconfiguration of data path entities such as routers or links. In case of a router, the failure can be due to a power outage, a software crash or hardware failure, e.g. interface cards. Link failures can be due to defective interface cards or to lower layer failures such as cable cuts. We make a distinction between data plane failures that are internal to a QoS domain and failures at the edges of a QoS domain (In case of a QoS domain consisting of a single router, an internal failure can occur when a component link in a link bundle attached to the router fails). Internal data plane failures should be solved locally and should not involve NSIS signalling when succesful. << [georgios] What do you mean here? Do you mean that Internal data plane features should not involve NSIS 'signalling when sucessfull. Some of the NSIS modes of operation should be able to apply NSIS signaling for internal data plane failure.>> [sven] The idea here is that an NE 'manages' somehow a set of 'resources'. If an error occurs and a solution can be provided by the same entity then it is proposed that nsis signalling is not affected. If the error is such that the NE cannot handle it alone then nsis resilience should kick in. The rationale is to avoid unnecessary failure notifications. 5.2. External data plane failures Edge failures can for instance occur when an Autonomous System Border Router (ASBR) or the link between two ASBRs goes down. Recovery from this type of failures requires a coordinated action between two or more QoS domains and will therefore impact NSIS signalling. <<[georgios] probably you can find other terms than Autonomous System.>> [sven] resource domain? I gues QoS domain is not even valid anymore. I agree by the way that I should update terminology according to the framework draft. They were developed in parallel, so it was difficult to do that in this version. 5.3. Control plane failures Two main types of control plane failures are distinguished: - Failure of an NSIS entity, e.g. a QI, QC or QR failure. If the QI is located at the end host, the end host is also considered to be part of the control plane of the NSIS signalling. - Loss of signalling messages between NSIS entities << [georgios] Please chnage terminology according to the new [hancock - framework] >> [sven] see above. 5.4. QoS degradation A failure does not necessarily have to equal a loss of connectivity. In a QoS-enabled environment, a degradation of the perceived performance on the data path can also be categorised as a failure. It may be important to distinguish these failures from a 'hard' failure (involving loss of connectivity) in order to support hierarchical protection. << [georgios] This is a policing matter! is not a failure>> [sven] Not necessarily I think. Suppose you have a bundled link of which one component link fails. In that case the BW on that link is reduced and the QoS of flows on it might be affected. So you might need to move traffic away from it. However, when a cable cut occurs on this new path, you might be tempted to move the traffic back, because connectivity with degraded QoS might be preferable to no connectivity at all. 6. Recovery issues 6.1. Failure detection In the data plane, node failures can be detected from the absence of hello messages from the Interior Gateway Protocol (IGP). Link failure indications can usually be derived from of lower-layer failure indications (loss of light, loss of signal). In case of logical links, failure detection can be more problematic and must either take place via the hello protocol or via a specific OAM procedure. << [georgios] Well other means could be used. Please do not restrict it only to this solution. Mention this as an example, please include other references, e.g., [RMD] >> [sven] OK, I will do that. Can you provide a pointer to the section in the doc you mention? In the control plane, NSIS failure detection involves the following issues: - When the QI is different from the end host, QI and end host need to be aware of each others failures. Two factors can complicate this problem. First, the QI may keep hard-state related to the end-host requests because the overhead of refreshes is deemed excessive. In this case, state refreshes can not be used as a failure detection mechanism. Second, the end host is not necessarily an NSIS speaker, which means that the detection mechanism must be supported outside of NSIS signalling. One potential solution is the use of higher and or lower layer triggers in the QI. This means that the QI should have higher/lower layer information available. << [georgios] is this related to out of band? Is this within NSIS scope?>> [sven] The point-of-view of the draft is the same as that of the framework: we will not work on solutions for out-of-band but document issues for the complete problem space. - When an NSIS entity is protected by a backup entity, a synchronisation failure between the two entities needs to be detected prior to the protection switch. Since both entities will be NSIS speakers, this functionality could be implemented in the NSIS protocol. << [georgios] Is this within NSIS scope??>> [sven] I think so. The NE can be in-band. - In case of hop-by-hop routing of the NSIS signalling messages, a failure detection mechanism is required in NSIS, even when the communication between NSIS entities is done with a reliable transport mechanism. This is caused by the fact that the transport signalling is terminated at each NSIS hop. This means that messages can be lost in an NSIS entity without the transport layer noticing it. 6.2. Failure notification Any failure notification needed in the data plane, e.g. from lower layers, should normally be transparent to NSIS. An issue can arise for external failures. <<[georgios] I do not understand this??>> [sven] This refers to the case where you e.g. detect a IP link failure based on physical layer notification. - If a failure of an external link or node is detected, a route change might be required in order to perform the recovery action. In that case, the failure should be notified to the QI if only per- class state is kept in the QC. <<[georgios] do you mean here external to a NSIS domain. If yes, why the failure notification is only needed when per-class state is kept? I think that this is independent of the type of reservation state. >> [sven] well, if per-flow state is kept, the node that detects the failure can take action itself and doesn't need to notify the QI. Otherwise, it has to wait for the next refresh, which has to come from the QI, notify and let the QI take action. For control plane failures, an issue might arise when only per-class state is kept. << I do not agree with this, why?>> - When only per-class state is kept, which might for instance occur in a QC in order to reduce information storage, the QC cannot reroute the LSP without a message from the QI. << What do you mean with reroute! Is this within NSIS scope?>> [sven] it cannot link the failure to the affected flows. This means that this situation is only feasible in combination with soft-state. In that case, the QC needs to notify the QI about the failure in response to the next refresh message, that therefore needs to contain an identification of the QI. - The failing reservation may be part of a service consisting of multiple such flows. An obvious example is a bi-directional service. It would seem appropriate for each flow to be protected separately and for the service not to be impacted when the protection action is successful. However, it would make little sense to keep one direction up when the other goes down. This would imply notification of the QI/QR of the flows making up the service in case of unsuccessful protection. 6.3. Recovery action The definition of a recovery strategy typically involves a decision on: - the scope of the protection action: this can be end-to-end path protection or local segment protection. We have already seen that the use of per-class state in the QC will prevent the application of local segment protection for external failures. <<[georgios] I do not understand this statement reagrding per class states>> [sven] I need to think about this one. We can probably discuss more in Japan but I will try to come back on this one on the list before that. - the timing of the protection action: protection paths can be pre- computed and pre-established in which case only a switch from primary to protection path is needed when a failure occurs. If the computation and/or establishment of the protection path is started after failure detection (rerouting), an additional recovery delay is introduced. <<[georgios] is routing also included in the NSIS scope?> - resource allocation on the protection paths: resource reservation on protection paths prior to failure is very inefficient and leads to excessive usage of network capacity for protection purposes. This can be avoided by not reserving capacity on the protection path. In this case, however, the availability of the protection path can not be guaranteed when a failure occurs. Alternatively, protection capacity can be shared between protection paths that are unlikely to fail simultaneously. For this, a limited number of failure scenarios (e.g. single node or single link failures) is assumed. Sharing protection capacity is highly complicated by the interdomain scope of the NSIS signalling because of the lack of detailed information on the failure states and the primary path. << [georgios] Is this the only solution?>> [sven] Probably not. Can you rpovide me with pointers to other solutions? Recovery on the control plane may involve any of the following issues: - If a failure can only be solved by means of a change of the interdomain path of the flow, the QC might be required to force a route change from the QI. << [georgios] Should this be done by NSIS; It is out of scope of NSIS >> [sven] If it is a required action of the QC, it is in the scope of nsis. Note that this can occur without any data plane failure when the QC of a QoS domain fails and the QCs of neighbouring domains want to bring up peering relations with QCs that are not realted to the next hop on the data path. - When only per-class state is kept in a QC and a setup message is lost, retransmission of the setup message may cause duplicate reservations in QoS domains upstream of the point where the loss occurred. In case of soft-state, this situation will last for several refresh intervals. Note that the impact of this type of failure can be restricted by the use of reliable transport between NSIS entities. <<[georgios] It can be solved by using explicit release messages, see RMD frmaework>> [sven] I know about explicit release but that is when you are aware of the double reservation. This is an example where you are not, and hence will not react to it. - In case of a QI or QR failure, the QC immediately following or preceding the failing entity may need to take up some proxy functionality for the failing entity. This functionality is optional for sending out teardown messages when soft-state is used, but mandatory for hard-state. It is also mandatory for replying to teardown messages, e.g. originating from the QI. - If the QoS Initiator does not receive a response on a signaling message within a certain time interval it will consider it as lost. It may decide to retransmit the signaling message. Therefore, the QoS Initiator must be able to make sure that the received ACK is not a delayed ACK from the previous transmitted signaling message. The signaling messages should therefore include a sequence number in order to associate a request (NEW, TEAR, REFRESH) with a response (ACK, NACK). <<[georgios] When soft state refresh is used, the TEAr messages do not neet to be authenticated>> [sven] You mean not acknowledged, because they time out anyhow. That is true. 7. Reversion issues 7.1. Repair detection No issues are identified for the data plane. For the control plane, repair detection will most likely occur by means of discovery messages initiated by the repaired NSIS entity. It is proposed that this discovery process could be a preliminary phase prior to the NSIS protocol and can therefore remain out of its scope. It is nevertheless crucial that such a discovery protocol is standardised in order to allow NSIS entities from different vendors to discover each other. <<[georgios] I think that is out of scope of NSIS>> 7.2. Repair notification Repair notification will normally take place by means of the IGP in the data plane. In the control plane, repair notification may be needed when a QC has taken up some proxy functionality for the QI or QC. However, no special action should be needed for this since this information can be inferred from the repair detection. <<[georgios] If repair detection is out of scope will this also be out of NSIS scope>> 7.3. Reversion action On the data plane, reversion is unavoidable when in-band signaling is used because the signaling messages will follow the new data plane route. This might cause issues because resources are typically not reserved on the new route, which might cause (temporary) QoS degradation on the new route. <<[georgios] What is the reversion action about? Is this related to the severe congestion problem explained in the NSIS requirements draft?>> [sven] Reversion refers to what happens when something that failed comes up again. In case of out-of-band signaling reversion may be avoided by means of route pinning. However, it will usually be advantageous to move to a more favourable route when one becomes available, both from a performance and resource utilisation point of view. In that case, the separation of data plane and control plane might help delaying the route change until sufficient resources are reserved on the new path. From a control plane perspective, reversion makes little sense when backup NSIS entities are used. In that case, the reversion action will be limited to a synchronisation with the currently active NSIS entity. The repaired entity will then become the backup. <<[georgios] Is out of band out of NSIS scope? [sven] As I said, nsis will not work on out-of-band solutions for now. It was the agreement that we should document these issues. -------------------------------------------------------------------------------------------------- -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: Thursday, June 27, 2002 4:25 PM To: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Hi all, As a result of discussions at the interim meeting we put together a separate document on nsis resilience. It tries to list issues brought up at the interim meeting together with some new ones in a broader general scope. The document has finally made it through to the IETF repository. Some people have expressed interest during the interim meeting, so hopefully the document can help in structuring the discussion. Best regards, Sven ---------------------- Forwarded by Sven VAN DEN BOSCH/BE/ALCATEL on 27/06/2002 16:19 --------------------------- Internet-Drafts@ietf.org@cnri.reston.va.us on 27/06/2002 12:39:37 Please respond to Internet-Drafts@ietf.org Sent by: nsyracus@cnri.reston.va.us To: IETF-Announce: ; cc: Subject: I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NSIS resilience analysis Author(s) : S. Van den Bosch, M. Buchli Filename : draft-vandenbosch-nsis-resilience-00.txt Pages : 11 Date : 26-Jun-02 The Next Steps in Signaling (NSIS) working group is chartered to develop requirements, architecture and protocols for the next IETF steps in signaling Quality-of-Service (QoS). Although the NSIS protocol may eventually be used for other applications in addition to QoS, it is expected that these, in much the same way as QoS, will depend on predictable and high-availability service delivery. This document attempts to identify, list and classify potential resilience issues for the NSIS protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-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-vandenbosch-nsis-resilience-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-vandenbosch-nsis-resilience-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. ftp://ftp.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 28 12:32: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 MAA05355 for ; Fri, 28 Jun 2002 12:32:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12142 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 12:32: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 MAA10655; Fri, 28 Jun 2002 12:19: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 MAA10621 for ; Fri, 28 Jun 2002 12:19:25 -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 MAA04449 for ; Fri, 28 Jun 2002 12:18:39 -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 g5SGLFW27077 for ; Fri, 28 Jun 2002 19:21:15 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 19:19:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 19:19: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" Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Date: Fri, 28 Jun 2002 19:19:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC655AA@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Thread-Index: AcIetO26upxipyiXTY27o/bM9TphpQACjm7w To: , Cc: X-OriginalArrivalTime: 28 Jun 2002 16:19:24.0022 (UTC) FILETIME=[91022960:01C21EBF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA10623 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, > <<[georgios] probably you can find other terms than > Autonomous System.>> > > [sven] resource domain? I gues QoS domain is not even valid anymore. I > agree by the way that I should update terminology according to the > framework draft. They were developed in parallel, so it was > difficult to do that in this version. I think for now, we could call it an NSIS domain. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jun 28 18:47: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 SAA26607 for ; Fri, 28 Jun 2002 18:47:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10397 for nsis-archive@odin.ietf.org; Fri, 28 Jun 2002 18:47: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 SAA09757; Fri, 28 Jun 2002 18:33: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 SAA09726 for ; Fri, 28 Jun 2002 18:33:58 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26180 for ; Fri, 28 Jun 2002 18:33:09 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA20732; Fri, 28 Jun 2002 15:33:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5SMXOE01553; Fri, 28 Jun 2002 15:33:24 -0700 X-mProtect: <200206282233> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.19.79.91, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJdX3AK; Fri, 28 Jun 2002 15:33:21 PDT Message-ID: <3D1CE42A.20403@iprg.nokia.com> Date: Fri, 28 Jun 2002 15:33:14 -0700 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Gabor Fodor CC: hemant.chaskar@nokia.com, nsis@ietf.org References: <200206281419.QAA06467@wrtw014.wrn.ki.sw.ericsson.se> Content-Type: multipart/alternative; boundary="------------090702070103060107000302" Subject: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-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 --------------090702070103060107000302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Gabor, thanks for your comments. Gabor Fodor wrote: >Hi Cedric and Hemant, > >I understand from the mail discussions and especially from the >interim meeting, that the WG is encouraged to take into >consideration the requirements formulated in : > >http://www.ietf.org/internet-drafts/ >draft-ietf-mobileip-qos-requirements-02.txt > >>From that perspective, I think that your draft is an >important input and can evolve to a good design base. > Hemant has first hand knowledge of these requirements. > >However, I also understand that the group is >in the process of discussing the requirements and the framework >drafts, so I am not sure whether starting discussing this >draft is appropriate right now. > The draft will probably evolve as the requirements and framework do. > > >Anyway, here comes a set of comments from my perspective. > >Best regards /Gabor > >--------------------------------------------------------------- >1 >I agree that we need to consider a QoS signaling that works >in a mobile/wireless environment and that the wireless bandwidth >economy must be an important factor. From this point of view, >I would like to see a more clear discussion on the requirements >that this draft provides the solution for. Clearly, we have >at least two important input documents: the NSIS requirement >doc and the mobileip-qos-requirements doc. I think that your >framework draft should try to identify which of these requirements >it considers important and which new ones it adds to those. > One of our goal was to state that a 'one size fits all' solution cannot solve all the requirements in these drafts. There are then two approaches: one is to weed out requirements until it's solvable with one protocol. To us, it would bring a compromised solution as contradictory requirements are necessary in the different scenarios that the signaling encounters during the lifetime of a flow. The other approach is what we wanted to underline: that some existing tools might be combined into a signaling toolkit that would meet the requirements. To answer your point: we should definitely write up an analysis on how our proposal answers the requirements you mention. We will do it as we enter design phase. > > >2 >I also agree that we need to differentiate between the "edge" >signaling, the context transfer signaling and the >"data path signaling". We need to be careful with statements >like "lightweight signaling mechanism required over the >wireless link". We indeed want to minimize both >the number and the length of signaling messages over the air >(so in that sense it should be lightweight), but we do >want to provide enough information to efficiently configure >wireless resources, often per user flow and per-flow >state maintenance with support of bi-directional assymmetric >reservation, etc. >I think that the draft should define what is meant by "wireless >bandwidth economy" and discuss more the requirements >specifically on the edge signaling. > Ok. > > >3 >The draft talks about the negotiation procedures (in 4.2). >In my opinion the draft should identify the requirement more >clearly, preferably with a reference to either the NSIS or >the mobile IP requirement draft. Is there a difference between >negotiation (which takes place upon QoS initiation time) and >QoS adaptation signaling which may take place upon hand-over ? > We do not discuss much QoS initiation, as we assume that some 'general signaling' such as RSVP establishes the QoS in the first place. So the negotation is really what you name QoS adaptation signaling. We should add some emphasis to this. > > >4 >I am not sure that it is meaningful at this point to start >discussing specific solution approaches. You seem to propose >to use ICMP as a design base for both edge signaling and for >context transfer (AR to AR). At least for the edge signaling, >we need to consider the edge specific requirements before >we start discussing what existing or new protocol can be the >design base for that. > Let me explain a bit here: the design base for edge signaling and context transfer is really 'A context transfer protocol for seamless mobility', draft-koodli-seamoby-ctv6-03.txt. Earlier version of draft-koodli-seamoby-ctv6 were ICMP based. However, it is more general in this latest version, and not necessarily ICMP. As a consequence, we mention ICMP as a possible illustration. The main point is that QoS signaling is redundant with context transfer, one object being transferred being QoS context, and that CT signaling will do the job for the MN to AR QoS signaling. We will clarify this point. >5 >You mention RFC2998 as one of your basic references, which I >think is a very useful RFC in this context as well. >However, from >the draft it is not clear how you use that in the proposed >architecture. (Since ICMP seems to be the base and not RSVP.) > The architecture of rfc2998 is that of heterogeneous nodes on the path, some controlling the resource, and some forwarding traffic. This is inside the network, and orthogonal in a way to the edge signaling. What we meant by citing rfc2998 was that we were dealing with 'in-band signaling so a subset of the routers on the path'. > > >6 >You identify QoS release as a necessary functionality. >Here there is a need to identify if the protocol should >support soft state (in which case this explicit QoS release >may not be necessary) or not. > Good point; Hemant might correct me, but I don't think we discussed it? >7 >As a minor detail issue, >I see some problems with the definition of the cross-over router. >I believe that your definition in 4.1.3 would identify >several routers as cross-over router, whereas later on >it seems that only the first merging point is really used >as cross-over router. By the way, the notion of cross-over >router in my opinion should be introduced when you present >the whole model around the figure in Section 1, but this >is a presentation issue. > Will do. Thanks for the comments, Cedric. > > > > >>From: Cedric Westphal >>To: nsis@ietf.org >>CC: hemant.chaskar@nokia.com >>Content-Transfer-Encoding: 7bit >>Content-Transfer-Encoding: 7bit >>Subject: [NSIS] QoS framework. >>Hi all, >> >>we put together a document representing our perspective on a >>NSIS qos signaling framework. >> >>Here is the abstract: >> >>Abstract >> >> This draft provides a framework for QoS signaling that is optimized >> for Mobile IP handoffs. It covers the horizontal signaling between >> access routers (ARs) as well as the vertical signaling along the >> packet data path, both of which are triggered by handoff of mobile >> node (MN). The key design goals are wireless bandwidth economy, >> fast QoS establishment along the new data path after handoff and >> secure protocol operation. >> >> >>The document will eventually be available from the i-d editor queue. However, >>only after Yokohama meeting. You can find it at: >>http://people.nokia.net/~cedric/Papers/draft-westphal-nsis-qos-mobileip-00.txt >>in the meantime. >>Please send your comments, >> >>Cedric & Hemant. >> >> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > --------------090702070103060107000302 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Gabor,

thanks for your comments.

Gabor Fodor wrote:
Hi Cedric and Hemant,

I understand from the mail discussions and especially from the
interim meeting, that the WG is encouraged to take into 
consideration the requirements formulated in : 

http://www.ietf.org/internet-drafts/
draft-ietf-mobileip-qos-requirements-02.txt

>From that perspective, I think that your draft is an
important input and can evolve to a good design base.
Hemant has first hand knowledge of these requirements.

However, I also understand that the group is
in the process of discussing the requirements and the framework
drafts, so I am not sure whether starting discussing this
draft is appropriate right now.
The draft will probably evolve as the requirements and framework do.


Anyway, here comes a set of comments from my perspective.

Best regards /Gabor

---------------------------------------------------------------
1
I agree that we need to consider a QoS signaling that works
in a mobile/wireless environment and that the wireless bandwidth
economy must be an important factor. From this point of view,
I would like to see a more clear discussion on the requirements
that this draft provides the solution for. Clearly, we have 
at least two important input documents: the NSIS requirement
doc and the mobileip-qos-requirements doc. I think that your 
framework draft should try to identify which of these requirements
it considers important and which new ones it adds to those.
One of our goal was to state that a 'one size fits all' solution cannot solve all the requirements
in these drafts. There are then two approaches: one is to weed out requirements until it's
solvable with one protocol. To us, it would bring a compromised solution as contradictory
requirements are necessary in the different scenarios that the signaling encounters during the
lifetime of a flow. The other approach is what we wanted to underline: that some existing tools might be combined into a signaling toolkit that would meet the requirements.
To answer your point: we should definitely write up an analysis on how our proposal answers the requirements you mention. We will do it as we enter design phase.


2
I also agree that we need to differentiate between the "edge" 
signaling, the context transfer signaling and the 
"data path signaling". We need to be careful with statements
like "lightweight signaling mechanism required over the
wireless link". We indeed want to minimize both 
the number and the length of signaling messages over the air
(so in that sense it should be lightweight), but we do
want to provide enough information to efficiently configure
wireless resources, often per user flow and per-flow
state maintenance with support of bi-directional assymmetric
reservation, etc.
I think that the draft should define what is meant by "wireless
bandwidth economy" and discuss more the requirements 
specifically on the edge signaling.
Ok.


3
The draft talks about the negotiation procedures (in 4.2).
In my opinion the draft should identify the requirement more
clearly, preferably with a reference to either the NSIS or
the mobile IP requirement draft. Is there a difference between
negotiation (which takes place upon QoS initiation time) and 
QoS adaptation signaling which may take place upon hand-over ?
We do not discuss much QoS initiation, as we assume that some 'general signaling' such as RSVP establishes the QoS in the first place. So the negotation is really what you name QoS adaptation signaling. We should add some emphasis to this.


4
I am not sure that it is meaningful at this point to start
discussing specific solution approaches. You seem to propose
to use ICMP as a design base for both edge signaling and for
context transfer (AR to AR). At least for the edge signaling,
we need to consider the edge specific requirements before
we start discussing what existing or new protocol can be the
design base for that.
Let me explain a bit here: the design base for edge signaling and context transfer is
really 'A context transfer protocol for seamless mobility', draft-koodli-seamoby-ctv6-03.txt.
Earlier version of draft-koodli-seamoby-ctv6 were ICMP based. However, it is more general in this latest version, and not necessarily ICMP. As a consequence, we mention ICMP
as a possible illustration. The main point is that QoS signaling is redundant with context transfer, one object being transferred being QoS context, and that CT signaling will do the job for the MN to AR QoS signaling.
We will clarify this point.

            

            

              
5
You mention RFC2998 as one of your basic references, which I 
think is a very useful RFC in this context as well. 
However, from 
the draft it is not clear how you use that in the proposed
architecture. (Since ICMP seems to be the base and not RSVP.)

              

The architecture of rfc2998 is that of heterogeneous nodes on the path, some
controlling the resource, and some forwarding traffic. This is inside the
network, and orthogonal in a way to the edge signaling. What we meant by
citing rfc2998 was that we were dealing with

'in-band signaling so a subset of the routers on the path'.

              

                


6
You identify QoS release as a necessary functionality.
Here there is a need to identify if the protocol should
support soft state (in which case this explicit QoS release
may not be necessary) or not. 

                

Good point; Hemant might correct me, but I don't think we discussed it?

                

                  
7
As a minor detail issue,
I see some problems with the definition of the cross-over router.
I believe that your definition in 4.1.3 would identify 
several routers as cross-over router, whereas later on
it seems that only the first merging point is really used
as cross-over router. By the way, the notion of cross-over
router in my opinion should be introduced when you present
the whole model around the figure in Section 1, but this
is a presentation issue.

                  

Will do.

Thanks for the comments,

                  

                  

Cedric.

                  

                    





                    

                      
From: Cedric Westphal <cedric@iprg.nokia.com>
To: nsis@ietf.org
CC: hemant.chaskar@nokia.com
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [NSIS] QoS framework.
Hi all,

we put together a document representing our perspective on a
NSIS qos signaling framework.

Here is the abstract:

Abstract

   This draft provides a framework for QoS signaling that is optimized
   for Mobile IP handoffs. It covers the horizontal signaling between
   access routers (ARs) as well as the vertical signaling along the
   packet data path, both of which are triggered by handoff of mobile
   node (MN). The key design goals are wireless bandwidth economy,

   fast QoS establishment along the new data path after handoff and
   secure protocol operation.


The document will eventually be available from the i-d editor queue. However,
only after Yokohama meeting. You can find it at:
http://people.nokia.net/~cedric/Papers/draft-westphal-nsis-qos-mobileip-00.txt
in the meantime.
Please send your comments,

Cedric & Hemant.




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

                      

                      


                      

                      

                      
                      

--------------090702070103060107000302--


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



From daemon@optimus.ietf.org  Sat Jun 29 20:59: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 UAA09053
	for ; Sat, 29 Jun 2002 20:59:58 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA20509
	for nsis-archive@odin.ietf.org; Sat, 29 Jun 2002 21:00: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 UAA19848;
	Sat, 29 Jun 2002 20:45: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 UAA19816
	for ; Sat, 29 Jun 2002 20:45:02 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08859
	for ; Sat, 29 Jun 2002 20:44:17 -0400 (EDT)
From: Hemant.Chaskar@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5U0jVx18964
	for ; Sat, 29 Jun 2002 19:45:32 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Sat, 29 Jun 2002 19:45:01 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Sat, 29 Jun 2002 19:44:00 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Sat, 29 Jun 2002 20:43:59 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: 
Thread-Topic: Comments on draft-westphal-nsis-qos-mobileip-00.txt
Thread-Index: AcIertd7wgmRxw9VTM61SJ8TbIr/AQASCJbg
To: 
Cc: , 
X-OriginalArrivalTime: 30 Jun 2002 00:44:00.0759 (UTC) FILETIME=[39C35870:01C21FCF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA19817
Subject: [NSIS] RE: Comments on draft-westphal-nsis-qos-mobileip-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 Gabor:

Thanks for the comments. Please see inline: 

-----Original Message-----
From: ext Gabor Fodor [mailto:erafodo@ESEALNT448.al.sw.ericsson.se]
Sent: Friday, June 28, 2002 10:20 AM
To: Weshphal Cedric (IPRG/MtView); Chaskar Hemant (NRC/Boston)
Cc: nsis@ietf.org
Subject: Comments on draft-westphal-nsis-qos-mobileip-00.txt


Hi Cedric and Hemant,

I understand from the mail discussions and especially from the
interim meeting, that the WG is encouraged to take into 
consideration the requirements formulated in : 

http://www.ietf.org/internet-drafts/
draft-ietf-mobileip-qos-requirements-02.txt

From that perspective, I think that your draft is an
important input and can evolve to a good design base.
However, I also understand that the group is
in the process of discussing the requirements and the framework
drafts, so I am not sure whether starting discussing this
draft is appropriate right now.

[Hemant] Yes, NSIS is indeed in requirements and framework phase. Please note that the MIP QoS solution in our draft has good compatibility with current NSIS framework document. Some highlights are: in-band signaling, use of optimized solution modules for different parts of network (horizontal signaling and vertical signaling with respect to handoff) as well as specific items for MIP mentioned in the framework document. So, I think that it might be worthwhile to have some discussion (at least on mailing list) on this draft to create some kind of design base for MIP QoS signaling, as you have said above. Such discussion can also provide feedback to framework document.    

Anyway, here comes a set of comments from my perspective.

Best regards /Gabor

---------------------------------------------------------------
1
I agree that we need to consider a QoS signaling that works
in a mobile/wireless environment and that the wireless bandwidth
economy must be an important factor. From this point of view,
I would like to see a more clear discussion on the requirements
that this draft provides the solution for. 

[Hemant] The main air interface bandwidth saving procedures that we have contemplated in the draft are: use of context transfer signaling between ARs to avoid sending much of the information over the air as well as avoiding (as much as possible) any traversals of wireless links (on both MN and CN side) during vertical signaling procedures.

Clearly, we have 
at least two important input documents: the NSIS requirement
doc and the mobileip-qos-requirements doc. I think that your 
framework draft should try to identify which of these requirements
it considers important and which new ones it adds to those.

[Hemant] In this draft, we have considered following requirements as prime ones: air interface bandwidth saving, fast QoS establishment after handoff,   authentication of handoff-induced signaling (to avoid spoofing attacks) and minimizing the impact of signaling on the segment of packet path that remains unchanged after handoff.

2
I also agree that we need to differentiate between the "edge" 
signaling, the context transfer signaling and the 
"data path signaling". We need to be careful with statements
like "lightweight signaling mechanism required over the
wireless link". We indeed want to minimize both 
the number and the length of signaling messages over the air
(so in that sense it should be lightweight), but we do
want to provide enough information to efficiently configure
wireless resources, often per user flow and per-flow
state maintenance with support of bi-directional asymmetric
reservation, etc.
I think that the draft should define what is meant by "wireless
bandwidth economy" and discuss more the requirements 
specifically on the edge signaling.

[Hemant] As you can see, for now, the critical mass of the draft is on vertical signaling. We have briefly described horizontal signaling, mainly to show its relation to vertical signaling. This has been done with the hope that we can borrow context transfer work from Seamoby to the extent possible for the edge QoS signaling part.   

3
The draft talks about the negotiation procedures (in 4.2).
In my opinion the draft should identify the requirement more
clearly, preferably with a reference to either the NSIS or
the mobile IP requirement draft. Is there a difference between
negotiation (which takes place upon QoS initiation time) and 
QoS adaptation signaling which may take place upon hand-over ?

[Hemant] We have advocated one pass reservation approach in the interest of speed of QoS establishment (in other words, minimize the number of packets that may get default forwarding treatment after handoff, just because QoS signaling has not yet completed). In most of the handoff cases, the request will be granted. But, there could be cases when requested QoS < offered QoS, and then, MN may choose to have control over decision as to whether to continue or terminate the session. For this case, we have provided fallback mechanism in the form of negotiation procedure. If the MN knows at handoff time (e.g. handoff from 2.5G to WLAN or vice versa) as to whether it needs to adapt QoS after handover to the characteristics of new access, it will put the adapted QoS parameters in the QoS signaling packet in the first place. Even after that, if some router cannot offer the requested QoS, we have negotiation procedure as fallback.  

4
I am not sure that it is meaningful at this point to start
discussing specific solution approaches. You seem to propose
to use ICMP as a design base for both edge signaling and for
context transfer (AR to AR). At least for the edge signaling,
we need to consider the edge specific requirements before
we start discussing what existing or new protocol can be the
design base for that.

[Hemant] Continuing my earlier comment about reusing as much from Seamoby for edge signaling, ICMP has been proposed in anticipation that  context transfer protocol in Seamoby will be ICMP based. It is precisely for the reason you mention above, that we have refrained from specifying any specific protocol to carry vertical signaling. Rather, we have focused on the characteristics that such carrier protocol, the information it may convey, processing of that information at intermediate nodes and security of signaling. 

5
You mention RFC2998 as one of your basic references, which I 
think is a very useful RFC in this context as well. 
However, from 
the draft it is not clear how you use that in the proposed
architecture. (Since ICMP seems to be the base and not RSVP.)

[Hemant] RFC2998 has following conceptual elements in it: signaling follows data path (which now is also in NSIS charter statement) and a set of routers on end to end path (QCs) control the QoS. We also started with this architecture. From this point onward, RFC2998 goes on to specify how RSVP can signal QoS over this architecture, while we choose a different signaling method.

6
You identify QoS release as a necessary functionality.
Here there is a need to identify if the protocol should
support soft state (in which case this explicit QoS release
may not be necessary) or not. 

[Hemant] In soft state approach, explicit TEAR DOWN may not be required. Of course, if inter-REFRESH period is chosen long enough to save REFRESH signaling overhead, TEAR DOWN can still help. Finally, if we go for soft state & no tear down approach, the TEAR DOWN part of the protocol can be gracefully omitted.

7
As a minor detail issue,
I see some problems with the definition of the cross-over router.
I believe that your definition in 4.1.3 would identify 
several routers as cross-over router, whereas later on
it seems that only the first merging point is really used
as cross-over router. By the way, the notion of cross-over
router in my opinion should be introduced when you present
the whole model around the figure in Section 1, but this
is a presentation issue.

[Hemant] Thanks for the comments, and apologies if some of above points were not clear from the write-up.

Hemant



> From: Cedric Westphal 
> To: nsis@ietf.org
> CC: hemant.chaskar@nokia.com
> Content-Transfer-Encoding: 7bit
> Content-Transfer-Encoding: 7bit
> Subject: [NSIS] QoS framework.
> Hi all,
> 
> we put together a document representing our perspective on a
> NSIS qos signaling framework.
> 
> Here is the abstract:
> 
> Abstract
> 
>    This draft provides a framework for QoS signaling that is optimized
>    for Mobile IP handoffs. It covers the horizontal signaling between
>    access routers (ARs) as well as the vertical signaling along the
>    packet data path, both of which are triggered by handoff of mobile
>    node (MN). The key design goals are wireless bandwidth economy,
>    fast QoS establishment along the new data path after handoff and
>    secure protocol operation.
> 
> 
> The document will eventually be available from the i-d editor queue. However,
> only after Yokohama meeting. You can find it at:
> http://people.nokia.net/~cedric/Papers/draft-westphal-nsis-qos-mobileip-00.txt
> in the meantime.
> Please send your comments,
> 
> Cedric & Hemant.
> 
> 
> 
> 
> _______________________________________________
> 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 Jun 29 22:09: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 WAA10601
	for ; Sat, 29 Jun 2002 22:09:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA23004
	for nsis-archive@odin.ietf.org; Sat, 29 Jun 2002 22:09: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 VAA22238;
	Sat, 29 Jun 2002 21:56: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 VAA22202
	for ; Sat, 29 Jun 2002 21:56:28 -0400 (EDT)
Received: from legend-mfy8zk0p ([61.144.241.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10425
	for ; Sat, 29 Jun 2002 21:55:32 -0400 (EDT)
From: chinaalarm@21cn.com
Message-Id: <200206300155.VAA10425@ietf.org>
To: nsis@ietf.org
Content-Type: multipart/alternative; boundary="=_NextPart_000_0018_01C1A1B3.E2C7FE20"
MIME-Version: 1.0
Date: Sun, 30 Jun 2002 09:59:17 +0800
X-Priority: 3
X-Mailer: CSM 3.2
Subject: [NSIS] =?GB2312?B?zt7P37Govq/N+CAgs8/V0Lj3tdi0+sDtycw=?=
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_0018_01C1A1B3.E2C7FE20
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

=D5=E2=CA=C7=D2=BB=B8=F6HTML=B8=F1=CA=BD=B5=C4=D3=CA=BC=FE

--=_NextPart_000_0018_01C1A1B3.E2C7FE20
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable



=C3=E2=B7=D1=CC=E1=B9=A9=D0=A1=C7=F8=CE=DE=CF=DF=B1=A8=BE=AF=CD=F8 =D4=F6=
=C7=BF=B0=B2=C8=AB=B7=C0=B7=B6=D2=E2=CA=B6
=A3=A8=B3=CF=D5=D0=B8=F7=B5=D8=B4=FA=C0=ED=C9=CC=A3=A9 =20
=20
=A9=FA=A9=FA=A9=FA=A9=FA=A9=FA110CAS=D0=A1=C7=F8=B1=A8=BE=AF=CD=F8=A9=FA=
 =A9=FA=A9=FA

=A9=FA=A9=FA =B9=FA=C4=DA=D7=EE=BF=EC=CB=D9=D7=EE=C1=AE=BC=DB=D7=EE=CA=CA=
=BA=CF=B4=F3=C3=E6=B9=FA=C4=DA=D7=EE=BF=EC=CB=D9=D7=EE=C1=AE=BC=DB=D7=EE=
=CA=CA=BA=CF=B4=F3=C3=E6=BB=FD=CD=C6=B9=E3=B5=C4=D0=A1=C7=F8=B1=A8=BE=AF=
=CD=F8=BB=FD=CD=C6=B9=E3=B5=C4=D0=A1=C7=F8=B1=A8=BE=AF=CD=F8 =A9=FA=A9=FA=
=20
=BC=CC=BF=ED=C6=B5=CD=F8=C2=E7=D4=DA=C8=AB=B9=FA=B8=F7=D0=A1=C7=F8=BF=AA=
=CA=BC=BD=A8=CD=F8=A3=AC=D3=D6=D2=BB=C2=D6=D0=A1=C7=F8=B1=A8=BE=AF=CD=F8=
=D4=DA=B8=F7=CA=D0=B4=F3=D7=A5=B2=F0=B3=FD=B7=C0=B5=C1=CD=F8=B5=C4=BF=DA=
=BA=C5=D6=D0=BF=AA=CA=BC =BD=F8=C8=EB=D0=A1=C7=F8=A3=AC=BF=AA=CA=BC=D0=C2=
=D2=BB
=C2=D6=A1=B0=C8=A6=B5=D8=A1=B1 =A3=AC=D3=C0=BB=AA=B9=AB=CB=BE=D2=D4=CE=DE=
=CD=F9=B6=F8=B2=BB=CA=A4=D1=B8=CB=D9=D4=DA=B8=F7=D0=A1=C7=F8=CD=C6=B9=E3=
=A1=A3 =A9=FA 110CAS=D0=A1=C7=F8=B1=A8=BE=AF=CF=B5=C1=D0=B2=FA=C6=B7=D6=AE=
=D2=BB=A3=BA=A1=B0=C9=F1=D3=A5---995=A1=B1=B8=C3
=B2=FA=C6=B7=D7=EE=B4=F3=CC=D8=B5=E3=CA=C7=BD=AB=BA=EC=CD=E2=CC=BD=CD=B7=
=BC=EC=B2=E2=B5=C4=D0=C5 =BA=C5=CD=A8=B9=FDBP=BB=FA=B7=A2=C9=E4=CD=B7=D6=
=B1=BD=D3=B7=A2=B3=F6=C8=A5=A3=A8=CE=DE=CF=DFPOCSAG=C2=EB=A1=A2=B4=AB=CA=
=E4=BE=E0=C0=EB=D4=B6=A1=A2=CB=D9=C2=CA=BF=EC=A3=A9=A3=AC=D2=BB
=CC=E5=BB=AF=BD=F4=B4=D5=BD=E1=B9=B9=A3=AC =DE=F0=C6=FA=B5=E7=BB=B0=B2=A6=
=BA=C5=A1=A2=D3=D0=CF=DF=B1=A8=BE=AF=B5=C4=D6=EE=B6=E0=C8=B1=CF=DD=A3=AC=
=D2=BB=B2=BD=A3=A8=B7=A2=C9=E41=A3=AE5=B9=AB=C0=EF=A3=A9=BD=AB=D0=C5=BA=C5=
=B4=AB=B5=BD=D6=B5=B0=E0=D4=B1=B5=C4=D7=A8=C5=E4BP=BB=FA =C9=CF=A3=AC
=B4=D3=B6=F8=C0=AD=BF=AA=D0=A1=C7=F8=D7=EE=BF=EC=CB=D9=A1=A2=D7=EE=BE=AD=
=BC=C3=A1=A2=D7=EE=CA=B5=D3=C3=B5=C4=B1=A8=BE=AF=BD=A8=CD=F8=CE=AC=C4=BB=
=A3=AC=D7=F6=B5=BD=B4=E5=B4=E5=BF=C9=D3=C3=A1=A2=BC=D2=BC=D2=BF=C9=C9=CF=
=A1=A3 =A9=FA =BC=F2=D1=D4=CA=F6=D6=AE=A3=BA=C3=BF=B8=F6=BA=EC=CD=E2=CF=DF=
=CC=BD
=CD=B7=C4=DA=D7=B0=D3=D0=D2=BB=B8=F6=B6=C0=CC=D8=B5=C4BP=BB=FA=B7=A2=C9=E4=
=BB=FA=A3=AC=D6=D0=D0=C4=D2=B2=B2=BB=D2=AA=BD=D3=BE=AF=BB=FA=A1=A2=B5=E7=
=C4=D4=A3=AC =C8=A1=B6=F8=B4=FA=D6=AE=CA=C7=D2=BB=B8=F6=D7=A8=C5=E4=B5=C4=
=D0=A1=C7=C9BP=BB=FA=A3=AC=D5=E2=C1=BD=B8=F6=CD=EA=C3=C0=B5=C4=A1=B0
=B6=E0=B7=A2=D2=BB=CA=D5=A1=B1=BD=E1=BA=CF=A3=AC=CA=B9=D0=A1=C7=F8=B1=A8=
=BE=AF=CD=F8=B1=E4=B5=C3=BC=F2 =BD=DD=A1=A2=BF=C9=BF=BF=A1=A2=C1=AE=BC=DB=
=A3=AC=D2=D4=D0=A1=C7=F8=CE=AA=B5=A5=CE=BB=A3=AC=BD=F8=D0=D0=C8=AB=B7=BD=
=C3=E6=B8=B2=B8=C7=A1=A3 =A9=FA=A9=FA=CE=D2=B9=AB=CB=BE=CA=C7=C4=BF=C7=B0=
=B9=FA
=C4=DA=CE=A8=D2=BB=C8=A1=B5=C3=B9=AB=B0=B2=B2=BF=C8=AB=B9=FA=CE=DE=CF=DF=
=B1=A8=BE=AF=C6=B5=B5=E3=C8=EB=CD=F8=D6=A4=A3=AC=B2=A2=CA=DC=B9=AB=B0=B2=
=B2=BF=CE=AF=CD=D0=D6=C6=B6=A8=CD=A8=D1=B6 =D0=C5=C1=EE=B8=F1=CA=BD=A1=A3=
=B8=C3=B2=FA=C6=B7=BB=B9=BF=C9=B9=E3=B7=BA=D3=A6=D3=C3=D3=DA=D2=F8=D0=D0=
=A1=A2
=C9=CC=C6=CC=A1=A2=D1=A7=D0=A3=A1=A2=D2=BD=D4=BA=B5=C8=A3=AE 1=A1=A2 =CF=
=FA=CA=DB=B7=BD=CA=BD=A3=BA=B2=C9=D3=C3=A1=B0=CE=DE=CF=DF=C8=A6=B5=D8=A1=
=B1 =D3=AA=CF=FA=A3=AC=B2=BB=D3=C3=C0=AD=CF=DF=A1=A2=B2=BB=D3=C3=BF=AA=B2=
=DB=A3=AC=D6=BB=D2=AA=B7=D6=C5=E4=B8=F8=D5=E2=B8=F6=D0=A1=C7=F8=D2=BB=B8=
=F6=20
=B6=C0=C1=A2=B5=C4=D2=FD=B5=BC=C2=EBBP=BB=FA=A1=A3=CD=A8=CB=D7=BD=B2=A3=AC=
=B8=C3BP=BB=FA=D6=BB=C4=DC=BD=D3=CA=D5=B1=BE=D0=A1=C7=F8=D0=C5=BA=C5=A3=AC=
=B2=BB=BD=D3=CA=D5=B1=F0=B8=F6=D0=A1=C7=F8=B5=C4=D0=C5=BA=C5=A3=AC=D4=F2=
=BE=CD=C8=A6 =C1=CB=D5=E2=B8=F6=D0=A1=C7=F8=B1=A8=BE=AF=CD=F8=A3=AC
=BC=B4=B8=C3=D0=A1=C7=F8=C8=CE=BA=CE=D2=BB=BC=D2=B1=A8=BE=AF=A3=AC=BE=F9=
=BF=C9=D4=DABP=BB=FA=C9=CF=CF=D4=CA=BE=A1=B0**=B6=B0=A9=FA****=B7=BF=B1=BB=
=B5=C1=A1=B1 =B5=C4 =D0=C5=BA=C5=A3=AC=BC=F2=BD=DD=BF=EC=CB=D9=A1=A2=D2=BB=
=C4=BF=C1=CB=C8=BB=A3=AC=BB=B9=BF=C9=BC=C7=C2=BC=B1=A8=BE=AF
=CA=B1=BC=E4=A3=AC=B4=A2=B4=E620=B8=F6=B1=A8=BE=AF=D0=C5=CF=A2=A1=A3 2=A1=
=A2 =CD=C6=B9=E3=C0=ED=C4=EE=A3=BA=BD=E2=B3=FD=CE=EF=D2=B5=B9=DC=C0=ED=B4=
=A6=B5=C4=B9=CB=C2=C7=A3=AC=D7=CA=C1=CF=B3=E4=B7=D6=A3=AC=C6=E4=D6=D0=D3=
=D0=B9=AB=B0=B2=B2=BF=A1=A2=D0=C5=CF=A2=B2=FA=D2=B5=B2=BF=C8=EB=CD=F8
=D6=A4=A1=A2=BD=A8 =C9=E8=B2=BF=CD=C6=B9=E3=D6=A4=CA=E9=A1=A2=B9=E3=B6=AB=
=CA=A1=B9=AB=B0=B2=CC=FC=A1=A2=C9=EE=DB=DA=CA=D0=B9=AB=B0=B2=BE=D6=BC=BC=
=B7=C0=D0=ED=BF=C9=D6=A4=A3=A8=D4=F6=BC=D3=BF=C9=D0=C5=B6=C8=A3=A9=A1=A3=
 3=A1=A2 =D0=AD=D2=E9=C7=A9=B6=A8=A3=BA=D7=E9=D6=AF=BC=E6=D6=B0=D3=AA=CF=
=FA
=BC=B4=BA=CD=CE=EF=D2=B5=B9=DC=C0=ED=D2=AA=C7=A9=CA=F0=D0=AD=D2=E9=A3=AC=
=D2=BB=C7=A9=B6=A9=D0=AD=D2=E9=D4=F2=D7=DC=B4=FA=C0=ED=B4=A6=BC=C7=C9=CF=
=B8=C3=D0=A1 =C7=F8=A3=AC=C6=E4=CB=FB=C8=CB=D4=F2=B2=BB=C4=DC=D6=D8=B8=B4=
=A3=A8=B5=DA=D2=BB=B8=F6=D4=C2=D2=AA=B1=A3=D6=A4=D2=BB=B8=F6=B5=D7=CA=FD=
=A3=AC
=B2=BB=C8=BB=CE=DE=D0=A7=A3=A9=A3=BB 4=A1=A2 =D3=C3=BB=A7=D6=AE=C9=CF=A3=
=BA=B2=BB=D3=C3=CE=EF=D2=B5=B9=DC=C0=ED=B4=A6=B5=E6=B8=B6=D2=BB=B7=D6=C7=
=AE=A3=A8=BA=A6=C5=C2=CD=B6=D7=CA=A3=A9=A3=AC=D7=A1=BB=A7=B4=A6=B2=C9=D3=
=C3=D7=D4=D4=B8=D4=AD=D4=F2=A3=AC=CF=C8=B0=B2=D7=B0=A1=A2 =BA=F3=CA=D5=BF=
=EE
=A3=AC=D7=E2=C1=DE=BB=A7=B2=C9=D3=C3=BD=BB=D1=BA=BD=F0=A1=A2=C3=BF=D4=C2=
=B8=B6=D7=E2=C1=DE=B7=D1=D3=C3=A1=A3 5=A1=A2 =BF=EE=CF=EE=CA=D5=C8=A1=A3=
=BA=CA=D5=BF=EE=B2=C9=D3=C3=D6=B1=BD=D3=CF=F2=D3=C3=BB=A7=CA=D5=BF=EE=A3=
=AC=D4=D9=B7=B5=BB=D8=B8=F8=CE=EF=D2=B5=B9=DC=C0=ED=B4=A6=A3=A8=CA=B9=CD=
=CF
=C7=B7=BF=EE=CE=AA=C1=E3=A3=A9=A3=BB 6=A1=A2 =D0=FB=B4=AB=C3=BD=CC=E5=A3=
=BA=B3=FD=D4=DA=D0=A1=C7=F8=C3=C5=BF=DA=CC=F9=B9=E3=B8=E6=D6=BD=A3=AC=D2=
=AA=D7=A8=C3=C5=D7=E9=D6=AF4=D6=C15=B8=F6=C8=CB=C0=FB=D3=C3=CD=ED=C9=CF=A1=
=A2=BD=DA=BC=D9=C8=D5=B5=BD=B8=F7=D0=A1=C7=F8=B0=DA =CC=AF=C9=E8=B5=E3

=A3=AC=D7=EE=BA=C3=D7=F6=B8=F6=BF=C9=D2=C6=B6=AF=B5=C4=D1=F9=B0=E6=B7=BF=
=A3=AC=CF=D6=B3=A1=D1=DD=CA=BE=A1=A2=C9=A2=B7=A2=B4=AB=B5=A5=A3=AC=D7=F6=
=B5=BD=BC=D2=D3=F7=BB=A7=CF=FE=A3=AC=C8=CB=C8=CB=BD=D4=D6=AA=A3=AC=D1=AD=
=D0=F2 =BD=A5=BD=F8=A3=AC=C6=CC=B5=C3=B5=E3=B6=E0=C1=CB=A3=AC=C0=DB=BC=C6=
=CA=FD
=D2=B2=B6=E0=C1=CB=A1=A3=CD=AC=CA=B1=D2=B2=BE=A1=BF=C9=C4=DC=B7=A2=B6=AF=
=C3=BD=CC=E5=B5=C4=D0=FB=B4=AB=D7=F7=D3=C3=A3=AC=B4=F3=D4=EC=D3=DF=C2=DB=
=A1=B0=BC=D2=D3=D0=C9=F1 =D3=A5=A1=A2=B0=B2=C8=AB=D3=D0=B1=A3=D5=CF=A1=B1=
 =A1=A3 7=A1=A2 =CD=B3=D2=BB=BC=DB=B8=F1=A3=BA=D7=EE=BA=F3=B8=F8=D3=C3

=BB=A7=B5=C4=BC=DB=B8=F1=B1=D8=D0=EB=CA=C7=CD=B3=D2=BB=A3=AC=C8=E7=C9=EE=
=DB=DA=CA=D0=C8=AB=CA=D0=BC=DB=B8=F1=CE=AA995=D4=AA/=BB=A7=A3=A8=B0=FC=B0=
=B2=D7=B0=BA=CD=D2=BB =C4=EA=CE=AC=D0=DE=B7=D1=A3=AC=B4=CB=BC=DB=B8=F1=D7=
=EE=BA=C3=D3=D0=CE=EF=BC=DB=B2=BF=C3=C5=B5=C4=C9=F3=C5=FA=BA=AF=A3=A9
=A3=AC=D3=C0=BB=AA=B9=AB=CB=BE=B8=F8=D7=DC=B4=FA=C0=ED=C9=CC=B5=C4=BC=DB=
=B8=F1=CE=AA650=D4=AA/=BB=A7=A3=AC 345=D4=AA/=BB=A7=B5=C4=B2=EE=BC=DB=A3=
=AC=B7=B5=B9=DC=C0=ED=B4=A6100=D4=AA/=BB=A7=A3=AC=D6=D0=BC=E4=D3=AA=CF=FA=
=C8=CB=D4=B1215=D4=AA/=BB=A7=A3=AC=B0=B2=D7=B0
=B7=D130=D4=AA/=BB=A7=A1=A3 =B9=A4=D7=F7=D4=AD=C0=ED=A3=BA=B1=BE=B1=A8=BE=
=AF=C6=F7=CA=C7=D4=DA=CE=DE=C8=CB=D6=B5=CA=D8=B5=C4=B5=D8=B7=BD=A3=AC=CD=
=A8=B9=FD=B5=E7=D7=D3=CC=BD=B2=E2=BC=BC=CA=F5=C5=D0=B6=CF=B7=C7=B7=A8=C8=
=EB=C7=D6=D0=D0=CE=AA=A3=AC=C8=BB=BA=F3=D7=D4=B6=AF =D4=DA=CF=D6=B3=A1

=B7=A2=B3=F6=C9=F9=B9=E2=BE=AF=B1=A8=A3=AC=B2=A2=CD=AC=CA=B1=D7=D4=B6=AF=
=BD=AB=BE=AF=C7=E9=CD=A8=B9=FD=CE=DE=CF=DF=B7=A2=CB=CD=B5=C4=CA=D6=B6=CE=
=B4=AB=CB=CD=B5=BD=B1=A3=B0=B2=D4=B1=C5=E5=B4=F8=B5=C4=CB=E6=C9=EDBP =BB=
=FA=A1=A2110CAS=CD=F8=C2=E7=BB=F9=D5=BE=B5=C8=B1=A8=BE=AF=BD=D3
=CA=D5=D6=D5=B6=CB=A3=AC=B1=A8=BE=AF=BD=D3=CA=D5=D6=D5=B6=CB=CA=D5=B5=BD=
=B1=A8=BE=AF=D0=C5=BA=C5=BA=F3=A3=AC=D4=D9=C9=CF=B4=AB=C9=CF=D2=BB=BC=B6=
=B1=A8=BE=AF=D6=D0 =D0=C4=A3=AC=D2=D4=B4=EF=B5=BD=C1=AA=CD=F8=B1=A8=BE=AF=
=B5=C4=C4=BF=B5=C4=A1=A3 =20

=20
=20
=B8=D0=D0=BB=C4=FA=E4=AF=C0=C0=B1=BE=CD=F8=D2=B3 http://www.110alarm.com=
  =D4=B8=D4=DA=CE=B4=C0=B4=B5=C4=C8=D5=D7=D3=C0=EF=C4=DC=B8=FA=C4=FA=BA=CF=
=D7=F7! =B3=CF=D1=B0=B8=F7=B5=D8=B4=FA=C0=ED=C9=CC,=B1=BE=CD=F8=D5=BE=CB=
=F9=D3=D0=B2=FA=C6=B7
=BE=F9=BF=C9=B0=B4=C5=FA=B7=A2=BC=DB=D3=CA=BC=C4,=D1=F9=C6=B7=C8=FD=B8=F6=
=D4=C2=B0=FC=CD=CB=B0=FC=BB=BB=A1=A3 =20

--=_NextPart_000_0018_01C1A1B3.E2C7FE20--

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