From mailnull@www1.ietf.org Tue Jan 7 20:01:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06412 for ; Tue, 7 Jan 2003 20:01:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h081Cn101500 for nsis-archive@odin.ietf.org; Tue, 7 Jan 2003 20:12:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h081CjJ01487; Tue, 7 Jan 2003 20:12:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h081BoJ01413 for ; Tue, 7 Jan 2003 20:11:50 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06362 for ; Tue, 7 Jan 2003 20:00:21 -0500 (EST) 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 h0812i002708 for ; Wed, 8 Jan 2003 03:02:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 03:03:36 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 03:03:36 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 03:03:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 8 Jan 2003 03:03:35 +0200 Message-ID: Thread-Topic: [NSIS] Service definition and negotiation Thread-Index: AcKufOi7hB8b/4mDS/SoeWI8pe7i+QIJg2fwAACx73A= To: Cc: X-OriginalArrivalTime: 08 Jan 2003 01:03:35.0937 (UTC) FILETIME=[C5894710:01C2B6B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h081BoJ01414 Subject: [NSIS] NSIS Interim Meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear All, Columbia University has graciously agreed to host the NSIS Interim Meeting. The meeting will take place between February 10th - 12th at Columbia University, 500 W 120th Street, NY, NY. Information on hotels in the area follows. http://www.cs.columbia.edu/~hgs/information.html and http://www.cs.columbia.edu/~hgs/etc/hotels.html Probably the easiest is to type the address of 500 W 120th Street, NY, NY into Expedia. They list a number of hotels starting at $48/night (shared bath...). Anything on the Upper West Side (80th and above) is going to be either a brisk walk, a short cab ride or a short subway ride away. The topics to be discussed are: NSIS Framework Two Layer Split Protocol Requirements NSIS Security Issues Interaction with Mobility Detailed agenda to be provided closer to the meeting. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jan 7 20:01:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06428 for ; Tue, 7 Jan 2003 20:01:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h081Ctx01530 for nsis-archive@odin.ietf.org; Tue, 7 Jan 2003 20:12:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h081CqJ01522; Tue, 7 Jan 2003 20:12:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h081BqJ01417 for ; Tue, 7 Jan 2003 20:11:52 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06364 for ; Tue, 7 Jan 2003 20:00:22 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0812j002730 for ; Wed, 8 Jan 2003 03:02:45 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 03:03:36 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 03:03:35 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 03:03:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 8 Jan 2003 03:03:34 +0200 Message-ID: Thread-Topic: [NSIS] Service definition and negotiation Thread-Index: AcKufOi7hB8b/4mDS/SoeWI8pe7i+QIJg2fwAAB3GUA= To: Cc: X-OriginalArrivalTime: 08 Jan 2003 01:03:35.0061 (UTC) FILETIME=[C5039C50:01C2B6B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h081BqJ01418 Subject: [NSIS] How to submit issues on draft-ietf-nsis-req-06.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, The draft can be found here: http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-06.txt In order to make the process move smoothly, I request that people submitting issues do so in the following format: Issue Name: assigned by WG chair Submitter name: xxx Submitter email address: xxx Date first submitted: DATE Reference: pointer to any discussion on the relevant issue Document: in this case, draft-ietf-nsis-req-06.txt Comment type: E or T (editorial or technical) Priority: 1 / 2 / 3 (1 = serious; 2 = minor; 3 = nit) Document Section: list section issue is related to Rationale/Explanation of issue: explain the reason for submitting the issue Requested change: supply text for change, be precise as a possible. I will track the issues via a webpage, details to be submitted later. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jan 7 20:03:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06514 for ; Tue, 7 Jan 2003 20:03:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h081E5Y01610 for nsis-archive@odin.ietf.org; Tue, 7 Jan 2003 20:14:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h081E2J01602; Tue, 7 Jan 2003 20:14:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h081DKJ01570 for ; Tue, 7 Jan 2003 20:13:20 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06411 for ; Tue, 7 Jan 2003 20:01:51 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08174t24421 for ; Wed, 8 Jan 2003 03:07:04 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 03:03:34 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 03:03:34 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 03:03:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 8 Jan 2003 03:03:33 +0200 Message-ID: Thread-Topic: [NSIS] Service definition and negotiation Thread-Index: AcKufOi7hB8b/4mDS/SoeWI8pe7i+QIJg2fw To: Cc: X-OriginalArrivalTime: 08 Jan 2003 01:03:34.0322 (UTC) FILETIME=[C492D920:01C2B6B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h081DKJ01571 Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear all, Marcus Brunner has submitted an updated version of the requirements document. He feels that he has addressed all of the remaining open issues, and we feel that it is ready for WG last call. There are a number of editorial nits, but otherwise the document is in good shape. Therefore, I am asking the working group to review the document and submit any issues found. The working group last call will last until Wednesday January 22nd, 4 PM Pacific Coast Time. I will send a subsequent mail outlining the procedure for submitting issues. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 10 09:10:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28490 for ; Fri, 10 Jan 2003 09:10:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AEMtu01876 for nsis-archive@odin.ietf.org; Fri, 10 Jan 2003 09:22:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AEMqJ01867; Fri, 10 Jan 2003 09:22:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AEKYJ01767 for ; Fri, 10 Jan 2003 09:20:34 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28418 for ; Fri, 10 Jan 2003 09:07:50 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h0AEB3628304 for ; Fri, 10 Jan 2003 15:11:03 +0100 (MET) To: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 10 Jan 2003 15:11:00 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/10/2003 15:11:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] conference call on out-of-band signalling Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, At the Atlanta IETF meeting, there was a mini-BOF presentation (available at http://users.skynet.be/besvand1/offpath.ppt) on out-of-band signalling in the TSVWG meeting. In order to proceed with this work, I would like to organize a conference call between all interested parties to gauge the interest in and potential participation to a BOF on out-of-path signalling at the next IETF. In order to have a realistic chance of getting some work in this area accepted, we need to restrict the scope of what we will be trying to achieve. The purpose of the proposed call would therefore be to find out: - is there sufficient interest in off-path signalling to have a succesful BOF - can we get an overview of why people want offpath signalling (what is the application/driver) - can we define a charter that is broad enough to cover these desires yet restrict it to something that is both feasible in and acceptable to the IETF. Note that a draft charter is already available http://users.skynet.be/besvand1/draft-charter.txt I would like to offer to host this call next thursday, Januari 16 (4pm-5pm CET). You can call in via the number of Lieve Van Staey (+32 3 240 7831) who will transfer you to the conference bridge. An access code will not be required. Please indicate if you intend to attend the call. We can then wait a couple of minutes for all confirmed participants to connect. Hope to hear you next thursday, Sven. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 10 10:45:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01323 for ; Fri, 10 Jan 2003 10:45:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AFwEL08729 for nsis-archive@odin.ietf.org; Fri, 10 Jan 2003 10:58:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFwAJ08714; Fri, 10 Jan 2003 10:58:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFu7J08565 for ; Fri, 10 Jan 2003 10:56:07 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01154 for ; Fri, 10 Jan 2003 10:43:21 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0AFkcKV007238 for ; Fri, 10 Jan 2003 16:46:38 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1F8BJH; Fri, 10 Jan 2003 16:46:38 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 16:45:29 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB855@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 30adf64f 1864f774 21c82a8a 00000138 From: "Georgios Karagiannis (ELN)" To: nsis@ietf.org Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Fri, 10 Jan 2003 16:46:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all I have a first comment on draft-ietf-nsis-req-06.txt related to Section 5.1.5. Section 5.1.6 emphasizes that the NSIS protocol must support independence of signaling and provisioning paradigm. If that is true I do not understand why then Section 5.1.5 emphasizes that the NSIS protocol MUST reuse existing provisioning functions and protocols! NSIS is a signaling protocol and it should actually not depend on any provisioning function or protocol. Therefore, I propose to remove Section 5.1.5. Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: woensdag 8 januari 2003 2:04 To: nsis@ietf.org Cc: mankin@psg.com Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Dear all, Marcus Brunner has submitted an updated version of the requirements document. He feels that he has addressed all of the remaining open issues, and we feel that it is ready for WG last call. There are a number of editorial nits, but otherwise the document is in good shape. Therefore, I am asking the working group to review the document and submit any issues found. The working group last call will last until Wednesday January 22nd, 4 PM Pacific Coast Time. I will send a subsequent mail outlining the procedure for submitting issues. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Jan 11 01:55:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27148 for ; Sat, 11 Jan 2003 01:55:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B77X029496 for nsis-archive@odin.ietf.org; Sat, 11 Jan 2003 02:07:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B77TJ29415; Sat, 11 Jan 2003 02:07:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B74WJ25739 for ; Sat, 11 Jan 2003 02:04:32 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27095 for ; Sat, 11 Jan 2003 01:51:28 -0500 (EST) 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 h0B6rp019994 for ; Sat, 11 Jan 2003 08:53:51 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 11 Jan 2003 08:54:36 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 11 Jan 2003 08:54:35 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 11 Jan 2003 08:54:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Sat, 11 Jan 2003 08:54:34 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcK4v+J96sBRR+faQoCeF+y1L+F7wwAe6xaA To: , X-OriginalArrivalTime: 11 Jan 2003 06:54:35.0014 (UTC) FILETIME=[4CF6AA60:01C2B93E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0B74WJ25740 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Georgios, > I have a first comment on draft-ietf-nsis-req-06.txt > related to Section 5.1.5. > > Section 5.1.6 emphasizes that the NSIS protocol must support > independence of signaling and provisioning paradigm. > If that is true I do not understand why then Section 5.1.5 > emphasizes that the NSIS protocol MUST > reuse existing provisioning functions and protocols! What I think is meant is that NSIS protocol SHOULD NOT define new provisioning paradigms, but try to re-use existing ones. > NSIS is a signaling protocol and it should actually not depend > on any provisioning function or protocol. Therefore, I propose > to remove Section 5.1.5. I don't think it is meant that NSIS MUST depend on a provising function or paradigm. Does this make sense? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Jan 12 01:05:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25733 for ; Sun, 12 Jan 2003 01:05:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0C6J1f03116 for nsis-archive@odin.ietf.org; Sun, 12 Jan 2003 01:19:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C6IoJ03101; Sun, 12 Jan 2003 01:18:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AHmuJ16755 for ; Fri, 10 Jan 2003 12:48:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05374; Fri, 10 Jan 2003 12:36:10 -0500 (EST) Message-Id: <200301101736.MAA05374@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, 10 Jan 2003 12:36:10 -0500 Subject: [NSIS] I-D ACTION:draft-westberg-nsis-rsvp-as-ntlp-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for modifications on RFC2205 Author(s) : L. Westberg et al. Filename : draft-westberg-nsis-rsvp-as-ntlp-00.txt Pages : 19 Date : 2003-1-10 The Resource ReSerVation Protocol (RSVPv1) has been on the standards track within the IETF for a number of years. During that time, the level of vendor support and deployment has been relatively slow, despite the desire of many to deploy technology to deliver services with different levels of quality of service (QoS) to their customers. The reasons for this are arguably well-understood and documented and are not the focus of this memo. This memo is proposing a (NSIS Transport Layer Protocol) NTLP, that is a modified version of RSVPv1 specified in RFC2205. Furthermore, it provides design guidelines and specifications for the development of the NLTP that is based on a modified version of RSVPv1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-westberg-nsis-rsvp-as-ntlp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-10122541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-westberg-nsis-rsvp-as-ntlp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-10122541.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 13 03:54:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04799 for ; Mon, 13 Jan 2003 03:54:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0D98EP06442 for nsis-archive@odin.ietf.org; Mon, 13 Jan 2003 04:08:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D985J06421; Mon, 13 Jan 2003 04:08:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D93DJ05609 for ; Mon, 13 Jan 2003 04:03:13 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04659 for ; Mon, 13 Jan 2003 03:49:04 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 13 Jan 2003 09:52:17 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 09:52:17 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B2A9@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: AW: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Mon, 13 Jan 2003 09:52:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0D955J05681 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit John, my remarks in line. Regards, Rüdiger | > I have a first comment on draft-ietf-nsis-req-06.txt | > related to Section 5.1.5. | > | > Section 5.1.6 emphasizes that the NSIS protocol must support | > independence of signaling and provisioning paradigm. | > If that is true I do not understand why then Section 5.1.5 | > emphasizes that the NSIS protocol MUST | > reuse existing provisioning functions and protocols! | | What I think is meant is that NSIS protocol SHOULD NOT define | new provisioning paradigms, but try to re-use existing ones. Only SHOULD NOT? The suggested new charter says: "It is a non-goal of the working group to develop new resource allocation protocols. Resource reservation and traffic engineering are out of scope of this working group." "Should not" means that NSIS is allowed to work on provisioning if that is felt to be required. Could you clarify what kind of work on provivioning is within scope and the relation of this to the charter? should the following be correct, "Specification of any provisioning function is out of scope of the NSIS WG. Any protocols developed by NSIS may assume existing standard-provisioning functions if information about provisioning mechanisms is required for the protocol design." 5.1.5. could be removed and the above could be inserted wherever it fits (a charter non goal with some explanation or a requirement). If wording of the text I proposed may be misleading, it should be improved. I hope the sense gets through. "Provisioning" my be replaced by "resource allocation" and/or "TE". Or is there a significant difference between provisioning and resource allocation? Where is it defined? | > NSIS is a signaling protocol and it should actually not depend | > on any provisioning function or protocol. Therefore, I propose | > to remove Section 5.1.5. | | I don't think it is meant that NSIS MUST depend on a provising | function or paradigm. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 13 04:04:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05148 for ; Mon, 13 Jan 2003 04:04:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0D9IBL07981 for nsis-archive@odin.ietf.org; Mon, 13 Jan 2003 04:18:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D9I7J07964; Mon, 13 Jan 2003 04:18:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D9HHJ07941 for ; Mon, 13 Jan 2003 04:17:17 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05131 for ; Mon, 13 Jan 2003 04:03:10 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0D96LAv007117; Mon, 13 Jan 2003 10:06:21 +0100 (MET) 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.2655.55) id ZGNMG7KV; Mon, 13 Jan 2003 10:06:21 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 10:06:21 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0D56029@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 1cf3a4b9 1864f774 db1b383b 00000138 From: "Vlora Rexhepi (ELN)" To: "'john.loughney@nokia.com'" , "Georgios Karagiannis (ELN)" , nsis@ietf.org Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Mon, 13 Jan 2003 10:06:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John, |I don't think it is meant that NSIS MUST depend on a provising |function or paradigm. True. So why a "MUST" for the NSIS protocol to reuse the existing provisioning functions and protocols? If the protocol is independent of these functions then it can be used with any provisioning functions and protocols, existing and new ones. Regards, Vlora _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 13 04:34:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05774 for ; Mon, 13 Jan 2003 04:34:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0D9liT09993 for nsis-archive@odin.ietf.org; Mon, 13 Jan 2003 04:47:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D9laJ09982; Mon, 13 Jan 2003 04:47:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D9ktJ09914 for ; Mon, 13 Jan 2003 04:46:55 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05731 for ; Mon, 13 Jan 2003 04:32:49 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0D9ZB003501 for ; Mon, 13 Jan 2003 11:35:11 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Jan 2003 11:36:07 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 11:36:06 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 11:36:05 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 11:36:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Mon, 13 Jan 2003 11:36:04 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcK64xVq+SsSKtulSgu8qSkrG9XDdAABAamA To: , , X-OriginalArrivalTime: 13 Jan 2003 09:36:05.0470 (UTC) FILETIME=[31C067E0:01C2BAE7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0D9ktJ09915 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Vlora, > |I don't think it is meant that NSIS MUST depend on a provising > |function or paradigm. > > True. So why a "MUST" for the NSIS protocol to reuse the existing > provisioning functions and protocols? If the protocol is independent > of these functions then it can be used with any provisioning functions > and protocols, existing and new ones. I think it is meant that it MUST be possible to use existing provishing protocols, which I think is reasonable. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 13 06:02:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07819 for ; Mon, 13 Jan 2003 06:02:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DBGRG15623 for nsis-archive@odin.ietf.org; Mon, 13 Jan 2003 06:16:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DBGNJ15616; Mon, 13 Jan 2003 06:16:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DBFKJ15584 for ; Mon, 13 Jan 2003 06:15:20 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07792 for ; Mon, 13 Jan 2003 06:01:12 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0DB4VKV000197; Mon, 13 Jan 2003 12:04:31 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNARFLN; Mon, 13 Jan 2003 12:04:31 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 12:04:33 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB85B@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: b01971ac 1864f774 db1b383b 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Mon, 13 Jan 2003 12:04:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John >> I think it is meant that it MUST be possible to use >> existing provishing >> protocols, which I think is reasonable. Yes, but does this also mean that it is not allowed to use new provisioning functions? If that is true then we actually limit the modularity and flexibility capabilities of the NSIS protocol. Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: maandag 13 januari 2003 10:36 To: Vlora.Rexhepi@eln.ericsson.se; Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Hi Vlora, > |I don't think it is meant that NSIS MUST depend on a provising > |function or paradigm. > > True. So why a "MUST" for the NSIS protocol to reuse the existing > provisioning functions and protocols? If the protocol is independent > of these functions then it can be used with any provisioning functions > and protocols, existing and new ones. I think it is meant that it MUST be possible to use existing provishing protocols, which I think is reasonable. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 13 06:37:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08423 for ; Mon, 13 Jan 2003 06:37:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DBpRw17701 for nsis-archive@odin.ietf.org; Mon, 13 Jan 2003 06:51:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DBpMJ17694; Mon, 13 Jan 2003 06:51:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DBoxJ17667 for ; Mon, 13 Jan 2003 06:50:59 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08408 for ; Mon, 13 Jan 2003 06:36:50 -0500 (EST) 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 h0DBdF029725 for ; Mon, 13 Jan 2003 13:39:15 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Jan 2003 13:40:09 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 13:40:08 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 13:40:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Mon, 13 Jan 2003 13:40:07 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcK68759zQ2NrbIPRSiTNE2Hym4GGgABF9mg To: , X-OriginalArrivalTime: 13 Jan 2003 11:40:08.0449 (UTC) FILETIME=[861CDF10:01C2BAF8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0DBoxJ17668 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, > Yes, but does this also mean that it is not allowed to use > new provisioning functions? We are not defining new provisioning functions now in NSIS, so this is out of scope. We are not preventing the use of new mechanisms, it is just out of scope. > If that is true then we actually limit the modularity and flexibility > capabilities of the NSIS protocol. So, I propose we change the text from: 5.1.5 NSIS MUST reuse existing provisioning Reuse existing functions and protocols for provisioning within a domain/subdomain unchanged. (Motivation: 'Don't re-invent the wheel'.) to: 5.1.5 NSIS MUST be able to reuse existing provisioning Reuse, where possible, existing functions and protocols for provisioning within a domain/subdomain unchanged. (Motivation: 'Don't re-invent the wheel'.) This text puts no restriction on future protocol use or evolution. best regards, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 13 06:39:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08498 for ; Mon, 13 Jan 2003 06:39:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DBr6d17827 for nsis-archive@odin.ietf.org; Mon, 13 Jan 2003 06:53:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DBr3J17798; Mon, 13 Jan 2003 06:53:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DBqFJ17740 for ; Mon, 13 Jan 2003 06:52:15 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08440 for ; Mon, 13 Jan 2003 06:38:06 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0DBeV000761 for ; Mon, 13 Jan 2003 13:40:31 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Jan 2003 13:41:24 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 13:41:24 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 13:41:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Mon, 13 Jan 2003 13:41:22 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcK64ReMzo+lNMY0RXGAJX37T8LYgwAF2/qw To: Cc: X-OriginalArrivalTime: 13 Jan 2003 11:41:23.0136 (UTC) FILETIME=[B2A13400:01C2BAF8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0DBqFJ17741 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rüdiger, > | > I have a first comment on draft-ietf-nsis-req-06.txt > | > related to Section 5.1.5. > | > > | > Section 5.1.6 emphasizes that the NSIS protocol must support > | > independence of signaling and provisioning paradigm. > | > If that is true I do not understand why then Section 5.1.5 > | > emphasizes that the NSIS protocol MUST > | > reuse existing provisioning functions and protocols! > | > | What I think is meant is that NSIS protocol SHOULD NOT define > | new provisioning paradigms, but try to re-use existing ones. > > Only SHOULD NOT? The suggested new charter says: "It is a > non-goal of the working group to develop new resource allocation > protocols. Resource reservation and traffic engineering are out > of scope of this working group." > "Should not" means that NSIS is allowed to work on provisioning > if that is felt to be required. Could you clarify what kind of > work on provivioning is within scope and the relation of this to > the charter? I agree with you - I meant provisioning mechanisms are currently out of scope for NSIS. The requirement should probably say that the work MUST be able to re-use existing mechanisms. See my mail (just sent) on this topic. John > should the following be correct, > > "Specification of any provisioning function is out > of scope of the NSIS WG. Any protocols developed by > NSIS may assume existing standard-provisioning > functions if information about provisioning > mechanisms is required for the protocol design." > > 5.1.5. could be removed and the above could be inserted wherever it > fits (a charter non goal with some explanation or a requirement). > > If wording of the text I proposed may be misleading, it should be > improved. I hope the sense gets through. "Provisioning" my be > replaced by "resource allocation" and/or "TE". Or is there a > significant difference between provisioning and resource allocation? > Where is it defined? > > | > NSIS is a signaling protocol and it should actually not depend > | > on any provisioning function or protocol. Therefore, I propose > | > to remove Section 5.1.5. > | > | I don't think it is meant that NSIS MUST depend on a provising > | function or paradigm. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 13 06:47:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08704 for ; Mon, 13 Jan 2003 06:47:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DC17s18191 for nsis-archive@odin.ietf.org; Mon, 13 Jan 2003 07:01:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DC13J18184; Mon, 13 Jan 2003 07:01:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DC0cJ18147 for ; Mon, 13 Jan 2003 07:00:38 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08665 for ; Mon, 13 Jan 2003 06:46:30 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0DBptt19014 for ; Mon, 13 Jan 2003 13:51:55 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 13 Jan 2003 13:49:48 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 13:49:48 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 13:49:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 13:49:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 13 Jan 2003 13:49:46 +0200 Message-ID: Thread-Topic: IETF 56 Thread-Index: AcK6+d5V5LlvvuQiQ6SmbqGCq2/5dA== To: X-OriginalArrivalTime: 13 Jan 2003 11:49:47.0284 (UTC) FILETIME=[DF201540:01C2BAF9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0DC0cJ18148 Subject: [NSIS] IETF 56 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, It is that time again. I need to schedule NSIS for IETF 56. Please submit any requirements for the meeting. Information about which WGs to avoid conflicts with would be good. Also, would multicast support be a good thing (so those not able to attend in person could view the meeting). thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 13 08:22:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10465 for ; Mon, 13 Jan 2003 08:22:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DDaLm24069 for nsis-archive@odin.ietf.org; Mon, 13 Jan 2003 08:36:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDaIJ24046; Mon, 13 Jan 2003 08:36:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDZZJ24017 for ; Mon, 13 Jan 2003 08:35:35 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10424 for ; Mon, 13 Jan 2003 08:21:24 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h0DDOpfm029684; Mon, 13 Jan 2003 05:24:51 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACB30817; Mon, 13 Jan 2003 05:24:43 -0800 (PST) Message-Id: <200301131324.ACB30817@mira-sjc5-c.cisco.com> To: john.loughney@nokia.com cc: Ruediger.Geib@t-systems.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt In-Reply-To: Message from john.loughney@nokia.com of "Mon, 13 Jan 2003 13:41:22 +0200." Date: Mon, 13 Jan 2003 08:24:43 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > I agree with you - I meant provisioning mechanisms are currently > out of scope for NSIS. The requirement should probably say that > the work MUST be able to re-use existing mechanisms. If it's out-of-scope, what are the consequences of just dropping it? If there are consequences, doesn't that imply that it's in scope? Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 13 08:23:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10484 for ; Mon, 13 Jan 2003 08:23:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DDb6w24252 for nsis-archive@odin.ietf.org; Mon, 13 Jan 2003 08:37:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDb2J24172; Mon, 13 Jan 2003 08:37:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDaoJ24081 for ; Mon, 13 Jan 2003 08:36:50 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10462 for ; Mon, 13 Jan 2003 08:22:39 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0DDPxKV016912; Mon, 13 Jan 2003 14:25:59 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1GKBCV; Mon, 13 Jan 2003 14:25:59 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 14:26:00 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB85C@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: fd47ec6d 1864f774 db1b383b 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Mon, 13 Jan 2003 14:25:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John Thank you! I totally agree with your proposal! Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: maandag 13 januari 2003 12:40 To: Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Hi, > Yes, but does this also mean that it is not allowed to use > new provisioning functions? We are not defining new provisioning functions now in NSIS, so this is out of scope. We are not preventing the use of new mechanisms, it is just out of scope. > If that is true then we actually limit the modularity and flexibility > capabilities of the NSIS protocol. So, I propose we change the text from: 5.1.5 NSIS MUST reuse existing provisioning Reuse existing functions and protocols for provisioning within a domain/subdomain unchanged. (Motivation: 'Don't re-invent the wheel'.) to: 5.1.5 NSIS MUST be able to reuse existing provisioning Reuse, where possible, existing functions and protocols for provisioning within a domain/subdomain unchanged. (Motivation: 'Don't re-invent the wheel'.) This text puts no restriction on future protocol use or evolution. best regards, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 13 08:25:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10541 for ; Mon, 13 Jan 2003 08:25:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DDd6M24848 for nsis-archive@odin.ietf.org; Mon, 13 Jan 2003 08:39:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDd2J24841; Mon, 13 Jan 2003 08:39:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDcQJ24823 for ; Mon, 13 Jan 2003 08:38:26 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10504 for ; Mon, 13 Jan 2003 08:24:14 -0500 (EST) 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 h0DDQc004762 for ; Mon, 13 Jan 2003 15:26:38 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Jan 2003 15:27:32 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 15:27:32 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 15:27:31 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 15:27:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Mon, 13 Jan 2003 15:27:29 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcK7BzA2k1VmmyJERcqG/KAJUDJmsAAABKfQ To: Cc: , X-OriginalArrivalTime: 13 Jan 2003 13:27:30.0701 (UTC) FILETIME=[85FE83D0:01C2BB07] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0DDcQJ24824 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, > > I agree with you - I meant provisioning mechanisms are currently > > out of scope for NSIS. The requirement should probably say that > > the work MUST be able to re-use existing mechanisms. > > If it's out-of-scope, what are the consequences of just > dropping it? Dropping it may imply that provisioning mechanisms could be considered part of an NSIS protocol. > If there are consequences, doesn't that imply that it's in scope? How to re-use provisioning mechaisms is in scope, developing new ones is not in scope. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 17 09:04:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22627 for ; Fri, 17 Jan 2003 09:04:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HEKYY01895 for nsis-archive@odin.ietf.org; Fri, 17 Jan 2003 09:20:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEKVJ01887; Fri, 17 Jan 2003 09:20:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEJOJ01811 for ; Fri, 17 Jan 2003 09:19:24 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22594 for ; Fri, 17 Jan 2003 09:03:16 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0HE6cKV021828 for ; Fri, 17 Jan 2003 15:06:38 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGND44L8; Fri, 17 Jan 2003 15:06:37 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jan 2003 15:06:38 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0D56053@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 3909d3a7 9ffcebbb 6f685166 00000138 From: "Vlora Rexhepi (ELN)" To: nsis@ietf.org Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Fri, 17 Jan 2003 15:06:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, Some minor comments on the draft: 1. In Section 5 on Requirements, it is written: "This section defines more detailed requirements for a signaling solution, respecting the framework,..." framework is mentioned without any reference, so it might be confusing. This is also the case for Section 5.1. 5.5.4 and 10.2 under 2). 2. If we consider the 2 layer-model and the separation between the transport protocol and the signaling application we might want to re-formulate the requirement on "5.1.7 NSIS MUST be application independent", such that it is clear that this is the requirement about the higher than network layer applications. My worry is related to the paragraph: " The requirement relates to the way the signaling interacts with upper layer functions (users, applications, and QoS administration), and lower layer technologies. " as the signaling application layer functions can also be seen as "upper layer functions", in which case we can't say that the protocol is application independent. I suggest to change this into: "The requirement relates to the way the signaling interacts with upper (than NSIS protocol) layer functions (users, applications, and QoS administration), and lower (than NSIS) layer technologies." Does this make sense? Regards, Vlora _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 17 19:23:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08095 for ; Fri, 17 Jan 2003 19:23:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0I0cpB09242 for nsis-archive@odin.ietf.org; Fri, 17 Jan 2003 19:38:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0I0ckJ09235; Fri, 17 Jan 2003 19:38:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0I0bUJ09178 for ; Fri, 17 Jan 2003 19:37:30 -0500 Received: from fep03-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08081 for ; Fri, 17 Jan 2003 19:21:11 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20030118002321.XWMV148587.fep03-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Fri, 17 Jan 2003 19:23:21 -0500 Message-ID: <3E289E9D.1040104@ee.ryerson.ca> Date: Fri, 17 Jan 2003 19:23:57 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Fri, 17 Jan 2003 19:23:18 -0500 Content-Transfer-Encoding: 7bit Subject: [NSIS] CFP: IEEE VTC Symposium on IP Mobility 2003 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline: February 15, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The theme of this symposium is **Support for Network Mobility**. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to the symposium theme. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create your own account in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: February 15, 2003 Acceptance Notification: April 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (USC) * Yasser Rasheed (Intel) * Raouf Boutaba (University of Waterloo) * Sajal Das (The University of Texas at Arlington) * Haseeb Akhtar (inCode Telecom group, CA) * Lars Wolf (TU Braunschweig, Germany) * Samir R. Das (SUNY at Stony Brook) * Thiery Ernst (Wide, Keio U Japan) * Abdelsalam Helal (U of Florida, Gainesville) * Govindan Ravindran (Soma Networks) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 20 10:31:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21859 for ; Mon, 20 Jan 2003 10:31:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KFmLV26940 for nsis-archive@odin.ietf.org; Mon, 20 Jan 2003 10:48:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KFm6J26916; Mon, 20 Jan 2003 10:48:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KFkYJ26785 for ; Mon, 20 Jan 2003 10:46:34 -0500 Received: from igate2.vodafone.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21804 for ; Mon, 20 Jan 2003 10:28:54 -0500 (EST) Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id PAA10144; Mon, 20 Jan 2003 15:32:14 GMT Received: from putney.vfl.vodafone (putney [10.33.112.118]) by mailguard4 (4.6.1.123) with ESMTP id for ; Mon, 20 Jan 2003 15:27:50 GMT Received: from ukwmxc01.vf-uk.internal.vodafone.com (UKWMXC01.vfl.vodafone [10.33.126.160]) by putney.vfl.vodafone with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YL9AVSR3; Mon, 20 Jan 2003 15:32:06 -0000 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 20 Jan 2003 15:31:19 +0000 Received: from ukwmxm01.vf-uk.internal.vodafone.com ([10.33.126.162]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 20 Jan 2003 15:31:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Date: Mon, 20 Jan 2003 15:31:18 -0000 Message-ID: <6FC554FA1F33BE4C9AC844FC3B3B71280665BE@UKWMXM01> Thread-Topic: What is the aim of NSIS? Thread-Index: AcLAmStiTyQGfixNEdebQABQBFRDqA== From: "Holmes, Matthew, CND Tech Dev, VF UK" To: X-OriginalArrivalTime: 20 Jan 2003 15:31:18.0932 (UTC) FILETIME=[FA74DD40:01C2C098] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0KFkYJ26786 Subject: [NSIS] What is the aim of NSIS? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi All I've just started looking at NSIS and have a question about what exactly the group is trying to do. I understand that at present current QoS signaling protocols are being looked at and the threats and issues being analysed. I'm a little confused with what the end result of the group is. i.e. What will the 'Next Step QoS Signaling' RFC be? In the description of the Working Group it states that the group will develop the requirements, architecture and protocols for the next IETF steps on signaling QoS. However, later it says that it is not the groups intention to invent new signaling protocols. So will the RFC result in a signaling protocol? If not what will it be? If anyone can help and give me a bit more detail I would appreciate it. Thank you Matthew Holmes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jan 22 03:21:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18849 for ; Wed, 22 Jan 2003 03:21:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M8dX202954 for nsis-archive@odin.ietf.org; Wed, 22 Jan 2003 03:39:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8ckJ02939; Wed, 22 Jan 2003 03:38:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8bmJ02851 for ; Wed, 22 Jan 2003 03:37:48 -0500 Received: from tms002bb.han.telia.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18817 for ; Wed, 22 Jan 2003 03:19:18 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from tms041mb.han.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 09:22:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Wed, 22 Jan 2003 09:22:43 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA71291B895E9@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] Service definition and negotiation Thread-Index: AcKufOi7hB8b/4mDS/SoeWI8pe7i+QIJg2fwArAXPiA= To: , X-OriginalArrivalTime: 22 Jan 2003 08:22:43.0617 (UTC) FILETIME=[6FC2B110:01C2C1EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0M8bmJ02852 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit John, here are some of my issues to the document. Sorry for posting them late. Issue Name: Submitter name: Anders Bergsten Submitter email address: anders.p.bergsten@telia.se Date first submitted: 03-01-20 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 Document Section: 2, pg 3, last paragraph Rationale/Explanation of issue: Definition of Receiver-initiated signaling protocol seems flawed. The definition states that the NSIS responder _initiates_ the reservation on behalf of the receiver. According to the definition of NSIS Responder, the NSIS Responder _responds_ to NSIS messages. The NSIS Responder does not initiate a message, hence, the definition is flawed. The definition of Receiver-initiated signaling protocol should be defined by where the NSIS Initiator is situated, not where the NSIS Responder is situated. Therefore I propose a change to something similar to the below. Requested change: "Receiver-initiated signaling protocol: A receiver-initiated signaling protocol is a protocol where the resources that the signaling protocol should reserve is situated topologically closer to the source than the NSIS Initiator is. This means is that the resource management functions need to be processed from the NSIS Initiator back towards the sender." Issue Name: Submitter name: Anders Bergsten Submitter email address: anders.p.bergsten@telia.se Date first submitted: 03-01-20 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 (?) Document Section: 5.2.2 Rationale/Explanation of issue: The section contain two different and possibly opposing requirement. The title says "No constraint MUST be posed on the signaling..." and page 12, paragraph 5 says "... NSIS signaling used between those virtual routers MUST follow the same path as the data". These are two different requirements where the second actually pose a contraint on the signaling path. Requested change: I personally prefer the second requirement and propose to use only that. This requirement states that it is some contraint on the path followed, which I think is good. I think it also sufficiently covers both the "bandwidth broker" and on-path alternatives to signaling. If people still prefer the first, I would like the requirement to state the following: "The only constraint on the signaling and NSIS forwarders is that they follow the correct AS-path" (or some equivilant term for AS-path). Issue Name: Submitter name: Anders Bergsten Submitter email address: anders.p.bergsten@telia.se Date first submitted: 03-01-13 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 Document Section: 5.3.4 Rationale/Explanation of issue: "A request for service MUST be answered at least with a yes or no". This does not state by whom the reply should be sent, neither is it clear enough on how to be interpreted. The only thing this adds to me is uncertainty - there is a risk that someone interpretes this as "if I have sent a request I can expect a reply", ie "The network MUST answer a request for service". This is impossible to promise, since packets can be lost. Requested change: I prefer to keep the requirement in the title and let that be the requirement. This requirement is slightly different than what is written within the text, and it talks about "success" of a service. If the requirement in the text should be interpreted as "A NSIS responder MUST answer a request for service", I want that stated. Thus, I request one of two resolutions to this issue: 1) Use only the requirement in the title (only a success needs to be reported) and remove the "clarifying" requirement in the text. 2) Add information on WHO must answer to the request (Something along, "The NSIS responder MUST reply with at least a yes/no"). Issue Name: Submitter name: Anders Bergsten Submitter email address: anders.p.bergsten@telia.se Date first submitted: 03-01-20 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 Document Section: 5.4.5 Rationale/Explanation of issue: The requirement ("the network MUST NOT know that a relationship between the group flows exists", etc) in last paragraph of the section is a very hard requirement to meet up with, I think. The interaction between routing and state maintainance causes some problems here. I start with a pure on-data-path signaling scenario. If a router is to maintain state and get a group of state requests, it must assume that they actually belong to him, otherwise it does not make sense. This requires either that the previous node does group flows together that have a relation with next-hop node or that the node can force relationship onto a group of flows (this method is used by MPLS), where we control the path. If we do not allow for "the network" to know relationships between flows, a node cannot assume that the resource belongs to him and need to have a method to find the right owner of the flow - which may be harder to solve than allowing a node to know a r! elationship between flows. Requested change: Not sure how to resolve the issue, unfortunately. The best thing would be to remove the paragraph and leave only the requirement on that NSIS MAY group flows. Then I have a general comment about the use of MUST/SHOULD... I feel there are too many requirements that are MUSTs, and I am not sure that it is understood how these requirements is met up by a protocol (ie what is the cost for having to implement this). For example, what is the implications of this requirement "State MUST be addressed independent of flow identification"? I would request that the MUSTs/SHOULDs etc is not to be interpreted as in RFC2119 as I believe that would be hard to find a protocol that match all the MUSTs. I would request to use must/should/may instead so that subsequent work do not interprete them as "hard" requirements, but rather as indications of requirement. Anders > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 8 januari 2003 02:04 > To: nsis@ietf.org > Cc: mankin@psg.com > Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Dear all, > > Marcus Brunner has submitted an updated version of the > requirements document. He feels that he has addressed all of > the remaining open issues, and we feel that it is ready for > WG last call. There are a number of editorial nits, but > otherwise the document is in good shape. > > Therefore, I am asking the working group to review the > document and submit any issues found. > > The working group last call will last until Wednesday January > 22nd, 4 PM Pacific Coast Time. > > I will send a subsequent mail outlining the procedure for > submitting issues. > > thanks, > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jan 22 15:25:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06085 for ; Wed, 22 Jan 2003 15:25:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MKhxZ18017 for nsis-archive@odin.ietf.org; Wed, 22 Jan 2003 15:43:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKhoJ18010; Wed, 22 Jan 2003 15:43:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKgcJ17952 for ; Wed, 22 Jan 2003 15:42:38 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06049 for ; Wed, 22 Jan 2003 15:23:52 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0MKRI815045 for ; Wed, 22 Jan 2003 15:27:18 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 15:27:18 -0500 Message-ID: From: "Louis-Nicolas Hamer" To: nsis@ietf.org Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Wed, 22 Jan 2003 15:27:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C254.A6E8F3E2" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C254.A6E8F3E2 Content-Type: text/plain All, Issue Name: ? Submitter name: Louis-Nicolas Hamer Submitter email address: nhamer@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 Section: 10.3 I have a few comments on section 10.3 UMTS access. Sorry for sending the late comments. Section 10.3 provides a good description of the UMTS access overall architecture for 3GPP release 5. But, it then speculates on how NSIS could fit into the 3GPP release 6, which is still not yet defined by the way. Although, I agree NSIS could indeed have a place in 3GPP release 6, I can't agree with the way it is depicted in the draft currently. First, I am not convinced the PCF is the right place to locate the NSIS Initiator. Why not consider the GGSN? Or the UE? Secondly, if it would be located in the PCF (or the GGSN for that matter), what would be the value-added? I personally think the important section of the network where nsis signaling would be needed is at the access level, not in the backbone network. So why originate NSIS after the access network? Value is limited IMHO. I think having this example, as it is currently is not acceptable. I propose we clean it up: -maybe we can agree on a more acceptable example usage of nsis in UMTS access? -maybe we could instead list all of the possible usages (instead of listing only one) -or strip out the example all together (I would prefer not too). I am not sure who contributed this section, so I guess in order to achieve closure, it would be best if the contributors contacted me directly or through the mailing list. Unless the chair (or someone else) has a better way forward. Cheers, L-N > -----Original Message----- > From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia.se] > Sent: Wednesday, January 22, 2003 3:23 AM > To: john.loughney@nokia.com; nsis@ietf.org > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > John, > > here are some of my issues to the document. Sorry for posting > them late. > > Issue Name: > Submitter name: Anders Bergsten > Submitter email address: anders.p.bergsten@telia.se > Date first submitted: 03-01-20 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Document Section: 2, pg 3, last paragraph > Rationale/Explanation of issue: Definition of > Receiver-initiated signaling protocol seems flawed. The > definition states that the NSIS responder _initiates_ the > reservation on behalf of the receiver. According to the > definition of NSIS Responder, the NSIS Responder _responds_ > to NSIS messages. The NSIS Responder does not initiate a > message, hence, the definition is flawed. The definition of > Receiver-initiated signaling protocol should be defined by > where the NSIS Initiator is situated, not where the NSIS > Responder is situated. Therefore I propose a change to > something similar to the below. > > Requested change: > "Receiver-initiated signaling protocol: A receiver-initiated > signaling protocol is a protocol where the resources that the > signaling protocol should reserve is situated topologically > closer to the source than the NSIS Initiator is. This means > is that the resource management functions need to be > processed from the NSIS Initiator back towards the sender." > > > Issue Name: > Submitter name: Anders Bergsten > Submitter email address: anders.p.bergsten@telia.se > Date first submitted: 03-01-20 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 (?) > Document Section: 5.2.2 > Rationale/Explanation of issue: The section contain two > different and possibly opposing requirement. The title says > "No constraint MUST be posed on the signaling..." and page > 12, paragraph 5 says "... NSIS signaling used between those > virtual routers MUST follow the same path as the data". These > are two different requirements where the second actually pose > a contraint on the signaling path. > > Requested change: I personally prefer the second requirement > and propose to use only that. This requirement states that it > is some contraint on the path followed, which I think is > good. I think it also sufficiently covers both the "bandwidth > broker" and on-path alternatives to signaling. If people > still prefer the first, I would like the requirement to state > the following: "The only constraint on the signaling and NSIS > forwarders is that they follow the correct AS-path" (or some > equivilant term for AS-path). > > > Issue Name: > Submitter name: Anders Bergsten > Submitter email address: anders.p.bergsten@telia.se > Date first submitted: 03-01-13 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Document Section: 5.3.4 > Rationale/Explanation of issue: "A request for service MUST > be answered at least with a yes or no". This does not state > by whom the reply should be sent, neither is it clear enough > on how to be interpreted. The only thing this adds to me is > uncertainty - there is a risk that someone interpretes this > as "if I have sent a request I can expect a reply", ie "The > network MUST answer a request for service". This is > impossible to promise, since packets can be lost. > > Requested change: I prefer to keep the requirement in the > title and let that be the requirement. This requirement is > slightly different than what is written within the text, and > it talks about "success" of a service. If the requirement in > the text should be interpreted as "A NSIS responder MUST > answer a request for service", I want that stated. Thus, I > request one of two resolutions to this issue: > 1) Use only the requirement in the title (only a > success needs to be reported) and remove the "clarifying" > requirement in the text. > 2) Add information on WHO must answer to the request > (Something along, "The NSIS responder MUST reply with at > least a yes/no"). > > > Issue Name: > Submitter name: Anders Bergsten > Submitter email address: anders.p.bergsten@telia.se > Date first submitted: 03-01-20 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Document Section: 5.4.5 > Rationale/Explanation of issue: The requirement ("the network > MUST NOT know that a relationship between the group flows > exists", etc) in last paragraph of the section is a very hard > requirement to meet up with, I think. The interaction between > routing and state maintainance causes some problems here. I > start with a pure on-data-path signaling scenario. If a > router is to maintain state and get a group of state > requests, it must assume that they actually belong to him, > otherwise it does not make sense. This requires either that > the previous node does group flows together that have a > relation with next-hop node or that the node can force > relationship onto a group of flows (this method is used by > MPLS), where we control the path. If we do not allow for "the > network" to know relationships between flows, a node cannot > assume that the resource belongs to him and need to have a > method to find the right owner of the flow - which may be > harder to solve than allowing a node to know a r! elationship > between flows. > Requested change: Not sure how to resolve the issue, > unfortunately. The best thing would be to remove the > paragraph and leave only the requirement on that NSIS MAY > group flows. > > > Then I have a general comment about the use of MUST/SHOULD... > I feel there are too many requirements that are MUSTs, and I > am not sure that it is understood how these requirements is > met up by a protocol (ie what is the cost for having to > implement this). For example, what is the implications of > this requirement "State MUST be addressed independent of flow > identification"? I would request that the MUSTs/SHOULDs etc > is not to be interpreted as in RFC2119 as I believe that > would be hard to find a protocol that match all the MUSTs. I > would request to use must/should/may instead so that > subsequent work do not interprete them as "hard" > requirements, but rather as indications of requirement. > > Anders > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: den 8 januari 2003 02:04 > > To: nsis@ietf.org > > Cc: mankin@psg.com > > Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > > > > Dear all, > > > > Marcus Brunner has submitted an updated version of the > > requirements document. He feels that he has addressed all of > > the remaining open issues, and we feel that it is ready for > > WG last call. There are a number of editorial nits, but > > otherwise the document is in good shape. > > > > Therefore, I am asking the working group to review the > > document and submit any issues found. > > > > The working group last call will last until Wednesday January > > 22nd, 4 PM Pacific Coast Time. > > > > I will send a subsequent mail outlining the procedure for > > submitting issues. > > > > thanks, > > John > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C2C254.A6E8F3E2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt

All,

Issue Name: ?
Submitter name: Louis-Nicolas Hamer
Submitter email address: = nhamer@nortelnetworks.com
Date first submitted: 22/01/2003
Reference: none
Document: draft-ietf-nsis-req-06.txt
Comment type: T
Priority:  2 
Section: 10.3


I have a few comments on section 10.3 UMTS = access.
Sorry for sending the late comments.

Section 10.3 provides a good description of the UMTS = access overall
architecture for 3GPP release 5. But, it then = speculates on how NSIS
could fit into the 3GPP release 6, which is still = not yet defined by the way.
Although, I agree NSIS could indeed have a place in = 3GPP release 6,
I can't agree with the way it is depicted in the = draft currently.

First, I am not convinced the PCF is the right place = to locate the NSIS
Initiator. Why not consider the GGSN? Or the = UE?
Secondly, if it would be located in the PCF (or the = GGSN for that matter), what
would be the value-added? I personally think the = important section of the network
where nsis signaling would be needed is at the = access level, not in the backbone network.
So why originate NSIS after the access network? = Value is limited IMHO.

I think having this example, as it is currently is = not acceptable. I propose
we clean it up:
        -maybe we = can agree on a more acceptable example usage of nsis in UMTS = access?
        -maybe we = could instead list all of the possible usages (instead of listing only = one)
        -or strip = out the example all together (I would prefer not too).

I am not sure who contributed this section, so I = guess in order to achieve closure, it would be best
if the contributors contacted me directly or through = the mailing list. Unless the chair (or someone else) has a better way = forward.

Cheers,

L-N



> -----Original Message-----
> From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@teli= a.se]
> Sent: Wednesday, January 22, 2003 3:23 = AM
> To: john.loughney@nokia.com; = nsis@ietf.org
> Subject: RE: [NSIS] WG Last Call on = draft-ietf-nsis-req-06.txt
>
>
> John,
>
> here are some of my issues to the document. = Sorry for posting
> them late.
>
> Issue Name:
> Submitter name: Anders Bergsten
> Submitter email address: = anders.p.bergsten@telia.se
> Date first submitted: 03-01-20
> Reference: -
> Document: draft-ietf-nsis-req-06.txt
> Comment type: T
> Priority:  2
> Document Section: 2, pg 3, last = paragraph
> Rationale/Explanation of issue: Definition of =
> Receiver-initiated signaling protocol seems = flawed. The
> definition states that the NSIS responder = _initiates_ the
> reservation on behalf of the receiver. = According to the
> definition of NSIS Responder, the NSIS = Responder _responds_
> to NSIS messages. The NSIS Responder does not = initiate a
> message, hence, the definition is flawed. The = definition of
> Receiver-initiated signaling protocol should be = defined by
> where the NSIS Initiator is situated, not where = the NSIS
> Responder is situated. Therefore I propose a = change to
> something similar to the below.
>
> Requested change:
> "Receiver-initiated signaling protocol: A = receiver-initiated
> signaling protocol is a protocol where the = resources that the
> signaling protocol should reserve is situated = topologically
> closer to the source than the NSIS Initiator = is. This means
> is that the resource management functions need = to be
> processed from the NSIS Initiator back towards = the sender."
>
>
> Issue Name:
> Submitter name: Anders Bergsten
> Submitter email address: = anders.p.bergsten@telia.se
> Date first submitted: 03-01-20
> Reference: -
> Document: draft-ietf-nsis-req-06.txt
> Comment type: T
> Priority:  2 (?)
> Document Section: 5.2.2
> Rationale/Explanation of issue: The section = contain two
> different and possibly opposing requirement. = The title says
> "No constraint MUST be posed on the = signaling..." and page
> 12, paragraph 5 says "... NSIS signaling = used between those
> virtual routers MUST follow the same path as = the data". These
> are two different requirements where the second = actually pose
> a contraint on the signaling path.
>
> Requested change: I personally prefer the = second requirement
> and propose to use only that. This requirement = states that it
> is some contraint on the path followed, which I = think is
> good. I think it also sufficiently covers both = the "bandwidth
> broker" and on-path alternatives to = signaling. If people
> still prefer the first, I would like the = requirement to state
> the following: "The only constraint on the = signaling and NSIS
> forwarders is that they follow the correct = AS-path" (or some
> equivilant term for AS-path).
>
>
> Issue Name:
> Submitter name: Anders Bergsten
> Submitter email address: = anders.p.bergsten@telia.se
> Date first submitted: 03-01-13
> Reference: -
> Document: draft-ietf-nsis-req-06.txt
> Comment type: T
> Priority:  2
> Document Section: 5.3.4
> Rationale/Explanation of issue: "A request = for service MUST
> be answered at least with a yes or no". = This does not state
> by whom the reply should be sent, neither is it = clear enough
> on how to be interpreted. The only thing this = adds to me is
> uncertainty - there is a risk that someone = interpretes this
> as "if I have sent a request I can expect = a reply", ie "The
> network MUST answer a request for = service". This is
> impossible to promise, since packets can be = lost.
>
> Requested change: I prefer to keep the = requirement in the
> title and let that be the requirement. This = requirement is
> slightly different than what is written within = the text, and
> it talks about "success" of a = service. If the requirement in
> the text should be interpreted as "A NSIS = responder MUST
> answer a request for service", I want that = stated. Thus, I
> request one of two resolutions to this issue: =
>       1) Use only the = requirement in the title (only a
> success needs to be reported) and remove the = "clarifying"
> requirement in the text.
>       2) Add = information on WHO must answer to the request
> (Something along, "The NSIS responder MUST = reply with at
> least a yes/no").
>
>
> Issue Name:
> Submitter name: Anders Bergsten
> Submitter email address: = anders.p.bergsten@telia.se
> Date first submitted: 03-01-20
> Reference: -
> Document: draft-ietf-nsis-req-06.txt
> Comment type: T
> Priority:  2
> Document Section: 5.4.5
> Rationale/Explanation of issue: The requirement = ("the network
> MUST NOT know that a relationship between the = group flows
> exists", etc) in last paragraph of the = section is a very hard
> requirement to meet up with, I think. The = interaction between
> routing and state maintainance causes some = problems here. I
> start with a pure on-data-path signaling = scenario. If a
> router is to maintain state and get a group of = state
> requests, it must assume that they actually = belong to him,
> otherwise it does not make sense. This requires = either that
> the previous node does group flows together = that have a
> relation with next-hop node or that the node = can force
> relationship onto a group of flows (this method = is used by
> MPLS), where we control the path. If we do not = allow for "the
> network" to know relationships between = flows, a node cannot
> assume that the resource belongs to him and = need to have a
> method to find the right owner of the flow - = which may be
> harder to solve than allowing a node to know a = r! elationship
> between flows.
> Requested change: Not sure how to resolve the = issue,
> unfortunately. The best thing would be to = remove the
> paragraph and leave only the requirement on = that NSIS MAY
> group flows.
>
>
> Then I have a general comment about the use of = MUST/SHOULD...
> I feel there are too many requirements that are = MUSTs, and I
> am not sure that it is understood how these = requirements is
> met up by a protocol (ie what is the cost for = having to
> implement this). For example, what is the = implications of
> this requirement "State MUST be addressed = independent of flow
> identification"? I would request that the = MUSTs/SHOULDs etc
> is not to be interpreted as in RFC2119 as I = believe that
> would be hard to find a protocol that match all = the MUSTs. I
> would request to use must/should/may instead so = that
> subsequent work do not interprete them as = "hard"
> requirements, but rather as indications of = requirement.
>
> Anders
>
> > -----Original Message-----
> > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > Sent: den 8 januari 2003 02:04
> > To: nsis@ietf.org
> > Cc: mankin@psg.com
> > Subject: [NSIS] WG Last Call on = draft-ietf-nsis-req-06.txt
> >
> >
> > Dear all,
> >
> > Marcus Brunner has submitted an updated = version of the
> > requirements document.  He feels that = he has addressed all of
> > the remaining open issues, and we feel = that it is ready for
> > WG last call.  There are a number of = editorial nits, but
> > otherwise the document is in good = shape.
> >
> > Therefore, I am asking the working group = to review the
> > document and submit any issues = found.
> >
> > The working group last call will last = until Wednesday January
> > 22nd, 4 PM Pacific Coast Time.
> >
> > I will send a subsequent mail outlining = the procedure for
> > submitting issues.
> >
> > thanks,
> > John
> > = _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis=
> >
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis=
>

------_=_NextPart_001_01C2C254.A6E8F3E2-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jan 22 17:42:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10392 for ; Wed, 22 Jan 2003 17:42:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MN0i726791 for nsis-archive@odin.ietf.org; Wed, 22 Jan 2003 18:00:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MN0VJ26771; Wed, 22 Jan 2003 18:00:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMxYJ26715 for ; Wed, 22 Jan 2003 17:59:34 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10259 for ; Wed, 22 Jan 2003 17:40:49 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0MMiRS14650 for ; Wed, 22 Jan 2003 16:44:27 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DJCCCZT4; Wed, 22 Jan 2003 16:44:14 -0600 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VSN2S1CW; Wed, 22 Jan 2003 16:44:14 -0600 Message-ID: <3E2F1DAB.3040806@iqmail.net> Date: Wed, 22 Jan 2003 16:39:39 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, There is a need to capture the scope of signaling (NSIS) in all 3G wireless networks besides UMTS (e.g. need to cover cdma2000). Otherwise, it gives a false impression that, the NSIS requirements are UMTS centric. I read the sections 10.2 and 10.3. There is a good similarity between 3GPP and 3GPP2 IP networks. The following is my attempt to generalize the Figure: +--------+ +----------| P-CSCF |-------> SIP signaling / +--------+ / SIP : : +--------+ +----------------+ : | Policy | | NSIS Forwarder | : +--------+ +----------------+ : : | : : COPS | : : | +----+ +--------+ | | UE |----------| Access |------------+ +----+ +----+ | Gateway|----------------------| ER | +--------+ +----+ I also agree with Louis that UE and/or the Access Gateway are the most natural candidates for NSIS initiator. Therefore I changed the above figure to reflect that. There is also similarity between UMTS/GPRS and cdma2000 radio link QoS setup e.g. UMTS creates different radio bearers with different QoS needs and in cdma2000 the same is done with multiple service instances. If my suggestion is agreeable, then I will be happy to provide updated text for section 10.2 and 10.3. Regards, Kuntal Hamer, Louis-Nicolas [CAR:DR13:EXCH] wrote: > All, > > Issue Name: ? > Submitter name: Louis-Nicolas Hamer > Submitter email address: nhamer@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 10.3 > > > I have a few comments on section 10.3 UMTS access. > Sorry for sending the late comments. > > Section 10.3 provides a good description of the UMTS access overall > architecture for 3GPP release 5. But, it then speculates on how NSIS > could fit into the 3GPP release 6, which is still not yet defined by the > way. > Although, I agree NSIS could indeed have a place in 3GPP release 6, > I can't agree with the way it is depicted in the draft currently. > > First, I am not convinced the PCF is the right place to locate the NSIS > Initiator. Why not consider the GGSN? Or the UE? > Secondly, if it would be located in the PCF (or the GGSN for that > matter), what > would be the value-added? I personally think the important section of > the network > where nsis signaling would be needed is at the access level, not in the > backbone network. > So why originate NSIS after the access network? Value is limited IMHO. > > I think having this example, as it is currently is not acceptable. I > propose > we clean it up: > -maybe we can agree on a more acceptable example usage of nsis > in UMTS access? > -maybe we could instead list all of the possible usages (instead > of listing only one) > -or strip out the example all together (I would prefer not too). > > I am not sure who contributed this section, so I guess in order to > achieve closure, it would be best > if the contributors contacted me directly or through the mailing list. > Unless the chair (or someone else) has a better way forward. > > Cheers, > > L-N > > > > > -----Original Message----- > > From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia.se] > > Sent: Wednesday, January 22, 2003 3:23 AM > > To: john.loughney@nokia.com; nsis@ietf.org > > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > > > > John, > > > > here are some of my issues to the document. Sorry for posting > > them late. > > > > Issue Name: > > Submitter name: Anders Bergsten > > Submitter email address: anders.p.bergsten@telia.se > > Date first submitted: 03-01-20 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: 2 > > Document Section: 2, pg 3, last paragraph > > Rationale/Explanation of issue: Definition of > > Receiver-initiated signaling protocol seems flawed. The > > definition states that the NSIS responder _initiates_ the > > reservation on behalf of the receiver. According to the > > definition of NSIS Responder, the NSIS Responder _responds_ > > to NSIS messages. The NSIS Responder does not initiate a > > message, hence, the definition is flawed. The definition of > > Receiver-initiated signaling protocol should be defined by > > where the NSIS Initiator is situated, not where the NSIS > > Responder is situated. Therefore I propose a change to > > something similar to the below. > > > > Requested change: > > "Receiver-initiated signaling protocol: A receiver-initiated > > signaling protocol is a protocol where the resources that the > > signaling protocol should reserve is situated topologically > > closer to the source than the NSIS Initiator is. This means > > is that the resource management functions need to be > > processed from the NSIS Initiator back towards the sender." > > > > > > Issue Name: > > Submitter name: Anders Bergsten > > Submitter email address: anders.p.bergsten@telia.se > > Date first submitted: 03-01-20 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: 2 (?) > > Document Section: 5.2.2 > > Rationale/Explanation of issue: The section contain two > > different and possibly opposing requirement. The title says > > "No constraint MUST be posed on the signaling..." and page > > 12, paragraph 5 says "... NSIS signaling used between those > > virtual routers MUST follow the same path as the data". These > > are two different requirements where the second actually pose > > a contraint on the signaling path. > > > > Requested change: I personally prefer the second requirement > > and propose to use only that. This requirement states that it > > is some contraint on the path followed, which I think is > > good. I think it also sufficiently covers both the "bandwidth > > broker" and on-path alternatives to signaling. If people > > still prefer the first, I would like the requirement to state > > the following: "The only constraint on the signaling and NSIS > > forwarders is that they follow the correct AS-path" (or some > > equivilant term for AS-path). > > > > > > Issue Name: > > Submitter name: Anders Bergsten > > Submitter email address: anders.p.bergsten@telia.se > > Date first submitted: 03-01-13 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: 2 > > Document Section: 5.3.4 > > Rationale/Explanation of issue: "A request for service MUST > > be answered at least with a yes or no". This does not state > > by whom the reply should be sent, neither is it clear enough > > on how to be interpreted. The only thing this adds to me is > > uncertainty - there is a risk that someone interpretes this > > as "if I have sent a request I can expect a reply", ie "The > > network MUST answer a request for service". This is > > impossible to promise, since packets can be lost. > > > > Requested change: I prefer to keep the requirement in the > > title and let that be the requirement. This requirement is > > slightly different than what is written within the text, and > > it talks about "success" of a service. If the requirement in > > the text should be interpreted as "A NSIS responder MUST > > answer a request for service", I want that stated. Thus, I > > request one of two resolutions to this issue: > > 1) Use only the requirement in the title (only a > > success needs to be reported) and remove the "clarifying" > > requirement in the text. > > 2) Add information on WHO must answer to the request > > (Something along, "The NSIS responder MUST reply with at > > least a yes/no"). > > > > > > Issue Name: > > Submitter name: Anders Bergsten > > Submitter email address: anders.p.bergsten@telia.se > > Date first submitted: 03-01-20 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: 2 > > Document Section: 5.4.5 > > Rationale/Explanation of issue: The requirement ("the network > > MUST NOT know that a relationship between the group flows > > exists", etc) in last paragraph of the section is a very hard > > requirement to meet up with, I think. The interaction between > > routing and state maintainance causes some problems here. I > > start with a pure on-data-path signaling scenario. If a > > router is to maintain state and get a group of state > > requests, it must assume that they actually belong to him, > > otherwise it does not make sense. This requires either that > > the previous node does group flows together that have a > > relation with next-hop node or that the node can force > > relationship onto a group of flows (this method is used by > > MPLS), where we control the path. If we do not allow for "the > > network" to know relationships between flows, a node cannot > > assume that the resource belongs to him and need to have a > > method to find the right owner of the flow - which may be > > harder to solve than allowing a node to know a r! elationship > > between flows. > > Requested change: Not sure how to resolve the issue, > > unfortunately. The best thing would be to remove the > > paragraph and leave only the requirement on that NSIS MAY > > group flows. > > > > > > Then I have a general comment about the use of MUST/SHOULD... > > I feel there are too many requirements that are MUSTs, and I > > am not sure that it is understood how these requirements is > > met up by a protocol (ie what is the cost for having to > > implement this). For example, what is the implications of > > this requirement "State MUST be addressed independent of flow > > identification"? I would request that the MUSTs/SHOULDs etc > > is not to be interpreted as in RFC2119 as I believe that > > would be hard to find a protocol that match all the MUSTs. I > > would request to use must/should/may instead so that > > subsequent work do not interprete them as "hard" > > requirements, but rather as indications of requirement. > > > > Anders > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: den 8 januari 2003 02:04 > > > To: nsis@ietf.org > > > Cc: mankin@psg.com > > > Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > > > > > > > Dear all, > > > > > > Marcus Brunner has submitted an updated version of the > > > requirements document. He feels that he has addressed all of > > > the remaining open issues, and we feel that it is ready for > > > WG last call. There are a number of editorial nits, but > > > otherwise the document is in good shape. > > > > > > Therefore, I am asking the working group to review the > > > document and submit any issues found. > > > > > > The working group last call will last until Wednesday January > > > 22nd, 4 PM Pacific Coast Time. > > > > > > I will send a subsequent mail outlining the procedure for > > > submitting issues. > > > > > > thanks, > > > John > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jan 22 17:49:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10508 for ; Wed, 22 Jan 2003 17:49:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MN7aQ27734 for nsis-archive@odin.ietf.org; Wed, 22 Jan 2003 18:07:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MN7KJ27461; Wed, 22 Jan 2003 18:07:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MN6aJ27022 for ; Wed, 22 Jan 2003 18:06:36 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10466 for ; Wed, 22 Jan 2003 17:47:52 -0500 (EST) Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0MMpTS15543 for ; Wed, 22 Jan 2003 16:51:29 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c001.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZC52YJTF; Wed, 22 Jan 2003 16:51:16 -0600 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VSN2S1C8; Wed, 22 Jan 2003 16:51:16 -0600 Message-ID: <3E2F1F51.8060402@iqmail.net> Date: Wed, 22 Jan 2003 16:46:41 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Here are a few issues that I found so far. IMHO, the document needs a through editorial scrub. Regards, Kuntal Issue Name: Submitter name: Kuntal Chowdhury Submitter email address: kuntal@iqmail.net Date first submitted: 03-01-22 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 2 Document Section: 2 Rationale/Explanation of issue: Definition of RMF should also mention about de-allocation Requested change: Resource Management Function (RMF): An abstract concept,representing the management of resources in a domain or a node. This includes admission control and resource allocation/de-allocation. Issue Name: Submitter name: Kuntal Chowdhury Submitter email address: kuntal@iqmail.net Date first submitted: 03-01-22 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: Document Section: 2 Rationale/Explanation of issue: The current definition of Provisioning has unnecessary texts. For example it says LSP initiation in MPLS is a matter of provisioning. IMO, it's not entirely correct, LSPs can be initiated by a LER based on it's internal logic which may be configured by suitable provisioning mechanism. Requested change: Provisioning: the act of configuring an NE for allocating resources to a flow or aggregate of flows. Issue Name: Submitter name: Kuntal Chowdhury Submitter email address: kuntal@iqmail.net Date first submitted: 03-01-22 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: Document Section: 2 Rationale/Explanation of issue: QoS technology definition needs a bit of correction, e.g. MPLS is not really a QoS technology, it is more used for Traffic Engineering. Requested change: QoS Technology: a generic term for a set of protocols, standards and mechanisms that can be used within a QoS domain/subdomain to manage the QoS provided to flows or aggregates that traverse the domain. An example QoS technology is DiffServ. A QoS technology is associated with certain QoS provisioning techniques. Issue Name: Submitter name: Kuntal Chowdhury Submitter email address: kuntal@iqmail.net Date first submitted: 03-01-22 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: Document Section: 2 Rationale/Explanation of issue: The document states that NSIS is not restricted to QoS signaling only, it also covers signaling required for other purposes such as ....not mentioned! The requirements are based on the fact that a signal is initiated from an NSIS initiator for allocation of network resources. It would be nice to see some examples of non-QoS signals that require allocation of network resources in the internet. Issue Name: Submitter name: Kuntal Chowdhury Submitter email address: kuntal@iqmail.net Date first submitted: 03-01-22 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: Document Section: 4.1 Rationale/Explanation of issue: " 6. NSIS assumes to operate with networks using standard ("normal") L3 routing. Where "normal" is not specified more exactly on purpose." this is very vague assumption. Not sure which routing scheme is considered "normal". If some are normal then which ones are "abnormal"? Requested change: 6. NSIS assumes to operate with networks using standard L3 routing. Issue Name: Submitter name: Kuntal Chowdhury Submitter email address: kuntal@iqmail.net Date first submitted: 03-01-22 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: Document Section: 5.2.1 Rationale/Explanation of issue: "5.2.1 The placement of NSIS Initiator, Forwarder, Responder MUST be free" MUST be free of what? Requested change: 5.2.1 The placement of NSIS Initiator, Forwarder, and Responder anywhere in the network MUST be allowed" Issue Name: Submitter name: Kuntal Chowdhury Submitter email address: kuntal@iqmail.net Date first submitted: 03-01-22 Reference: - Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: Document Section: 5.2.2 Rationale/Explanation of issue: "5.2.2 No constraint MUST be posed the signaling and NSIS Forwarders to be in the data path. " Need to rephrase this requirement. Requested change: 5.2.2 There MUST not be any constraint to always require the NSIS forwarder to be on the data path. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jan 22 19:20:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12164 for ; Wed, 22 Jan 2003 19:20:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N0ciV00457 for nsis-archive@odin.ietf.org; Wed, 22 Jan 2003 19:38:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N0cZJ00450; Wed, 22 Jan 2003 19:38:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N0brJ00394 for ; Wed, 22 Jan 2003 19:37:53 -0500 Received: from zctfs063.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12139 for ; Wed, 22 Jan 2003 19:19:05 -0500 (EST) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0N0MUi13696 for ; Thu, 23 Jan 2003 01:22:30 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 01:22:28 +0100 Message-ID: From: "Cedric Aoun" To: "'nsis@ietf.org'" Date: Thu, 23 Jan 2003 01:22:28 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [NSIS] comments on draft-ietf-nsis-req-06.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, I have some comments on the draft, sorry for being late ... Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: Abstract, page 1 line 41 Rationale/Explanation of issue:typo error "in recent year" Requested change:"in the recent year" Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 1, page 2 line 51 Rationale/Explanation of issue:typo error "to t4est" Requested change:"to test" Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 1, page 3 line 3 Rationale/Explanation of issue:typo error "requirement documents", "other application" Requested change:"requirements document", "other applications" Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 2, page 3 line 14 Rationale/Explanation of issue:text editing/formating Requested change:Need to have a formal section introduction or take it out Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 2, page 4 line 17 Rationale/Explanation of issue: simplify the text and make it generic "Control Information: the information the governs for instance the QoS treatment to be applied to a flow or aggregate, including the service class, flow administration, and any associated security or accounting information." Requested change:"Control information: information that governs the treatment to be applied to a flow or aggregate" Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 3, page 5 line 10 Rationale/Explanation of issue: simplify the text "A basic goal should be to re-use these wherever possible, and to focus requirements work at an early stage on those areas where a new solution is needed (e.g. an especially simple one). We also try to avoid defining requirements related to internal implementation aspects." Requested change:"A basis goal should be to re-use the proposed architecture wherever possible” Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 Section: 3, page 6 line 29 Rationale/Explanation of issue: What about the NSIS responder? we should not impose where that function is hosted “The placement of the NSIS Initiators and NSIS Forwarders is not fixed.” Requested change: “The placement of the NSIS Initiators, responders and NSIS Forwarders is not fixed.” Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 3, page 8 line 39 Rationale/Explanation of issue: “ the protection of non-signaling messages â€Ĥ corresponding application layer protocol”. It could confuse people on point #7 “protection of non-signaling messages is outside the scope of the protocol”. Requested change: Either we put it in the annex as is or suggest to reword it as: “The NSIS Forwarder need to have sufficient information to be able to uniquely identify a specific user flow even when security mechanisms are applied to that flow” Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 Section: 5.1.1 Rationale/Explanation of issue: “MUST be applicable for different technologies” Isn’t the requirement about having different types of services that could be signaled with the NSIS protocol? It is probably best to reword it for more clarity Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 5.2.2 Rationale/Explanation of issue: Typo error.“No constraint MUST be posed the signaling and NSIS Forwarders to be in the data path.” Requested change: could be simply reworded to "independence of the signaling path and the data path" Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 5.3.3 page 13 line 41 Rationale/Explanation of issue: Typo error.“the network nodes can locally repair this type error” Requested change: “the network nodes can locally repair this type of error” Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 Section: 5.3.3 page 14 line 3 Rationale/Explanation of issue: “Service upgrade available: If a previously requested better service becomes available.” We might want to have this notification sent even if the service was not asked for it. The decision of sending or not the notification is a policy issue but we need to make sure that we can send the notification. Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 5.3.4 page 14 line 30 Rationale/Explanation of issue: rewording - “to also get a description of what amount of resources a request is possible” Requested change: “to also get a description of what amount of available requested resources are available” Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 5.4.1 page 15 line 14 Rationale/Explanation of issue: rewording - ”note that a provider or that particular services requested” Requested change: “note that the provider of the particular requested service” Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: E Priority: 3 Section: 5.4.2 page 15 line 18 Rationale/Explanation of issue: rewording - ”SHOULD possible to add and remove local domain information" Requested change: "It SHOULD be possible to add and remove local domain information” Issue Name: ? Submitter name: Cedric Aoun Submitter email address: cedric.aoun@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 Section: 5.4.5 page 16 line 3 Rationale/Explanation of issue: “However, the network MUST NOT know that a relationship between the grouped flows exists. There MUST NOT be any transactional semantic associated with the grouping. It is only meant for optimization purposes and each reservation MUST be handled separately from each other.” We need to have a MAY for having semantics to group flows that are bundled. I agree that the flows could have independent properties and associated resource reservations could still be taken down or processed independently. The usefulness of grouping these flows is primarily to tear down all their associated states at the same time without repeating the tear down message several time (i.e. command aggregation) and to minimize the size of the message data. Regards Cedric _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 23 03:35:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00054 for ; Thu, 23 Jan 2003 03:35:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N8rmR06062 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 03:53:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8rXJ06054; Thu, 23 Jan 2003 03:53:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8qnJ06004 for ; Thu, 23 Jan 2003 03:52:49 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00024 for ; Thu, 23 Jan 2003 03:33:51 -0500 (EST) 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 h0N8aH005123 for ; Thu, 23 Jan 2003 10:36:17 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 23 Jan 2003 10:37:17 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:37:17 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:37:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Thu, 23 Jan 2003 10:37:16 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcK7B2ExmI0pA0bxRtmn+v7xC65rdwHszcdw To: X-OriginalArrivalTime: 23 Jan 2003 08:37:17.0272 (UTC) FILETIME=[A2E99D80:01C2C2BA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0N8qnJ06005 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Assigned issue 1: http://www-nrc.nokia.com/sua/nsis/nsis-issues.htm > -----Original Message----- > From: ext Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 13 January, 2003 15:26 > To: Loughney John (NRC/Helsinki); nsis@ietf.org > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Hi John > > Thank you! > I totally agree with your proposal! > > Best Regards, > Georgios > > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: maandag 13 januari 2003 12:40 > To: Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Hi, > > > Yes, but does this also mean that it is not allowed to use > > new provisioning functions? > > We are not defining new provisioning functions now in NSIS, so > this is out of scope. We are not preventing the use of new > mechanisms, it is just out of scope. > > > If that is true then we actually limit the modularity and > flexibility > > capabilities of the NSIS protocol. > > So, I propose we change the text from: > > 5.1.5 NSIS MUST reuse existing provisioning > > Reuse existing functions and protocols for provisioning within a > domain/subdomain unchanged. (Motivation: 'Don't re-invent the > wheel'.) > > to: > > 5.1.5 NSIS MUST be able to reuse existing provisioning > > Reuse, where possible, existing functions and protocols > for provisioning > within a domain/subdomain unchanged. (Motivation: 'Don't > re-invent the > wheel'.) > > This text puts no restriction on future protocol use or evolution. > > best regards, > > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 23 03:35:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00072 for ; Thu, 23 Jan 2003 03:35:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N8s8t06121 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 03:54:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8s2J06095; Thu, 23 Jan 2003 03:54:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8rOJ06035 for ; Thu, 23 Jan 2003 03:53:24 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00031 for ; Thu, 23 Jan 2003 03:34:26 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0N8eBt21516 for ; Thu, 23 Jan 2003 10:40:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 10:37:52 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:37:52 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:37:50 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:37:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Thu, 23 Jan 2003 10:37:49 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcK+MeBu7CcoPPYsRgecFueB3p8UTwEiM/BQ To: , X-OriginalArrivalTime: 23 Jan 2003 08:37:50.0342 (UTC) FILETIME=[B69FB260:01C2C2BA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0N8rOJ06036 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Assigned issues 24 & 25: http://www-nrc.nokia.com/sua/nsis/nsis-issues.htm > -----Original Message----- > From: ext Vlora Rexhepi (ELN) [mailto:Vlora.Rexhepi@eln.ericsson.se] > Sent: 17 January, 2003 16:07 > To: nsis@ietf.org > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Hi, > > Some minor comments on the draft: > > 1. In Section 5 on Requirements, it is written: > "This section defines more detailed requirements for > a signaling solution, respecting the framework,..." > framework is mentioned without any reference, so it might > be confusing. This is also the case for Section 5.1. 5.5.4 > and 10.2 under 2). > > 2. If we consider the 2 layer-model and the separation between > the transport protocol and the signaling application we might > want to re-formulate the requirement on "5.1.7 NSIS MUST be > application independent", such that it is clear that this is > the requirement about the higher than network layer applications. > My worry is related to the paragraph: > " > The requirement relates to the way the signaling interacts with > upper layer functions (users, applications, and QoS > administration), > and lower layer technologies. > " > as the signaling application layer functions can also be seen > as "upper layer functions", in which case we can't say that the > protocol is application independent. > I suggest to change this into: > "The requirement relates to the way the signaling interacts with > upper (than NSIS protocol) layer functions (users, applications, > and QoS administration), and lower (than NSIS) layer > technologies." > > Does this make sense? > > Regards, > Vlora > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Jan 23 03:35:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00091 for ; Thu, 23 Jan 2003 03:35:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N8sMB06142 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 03:54:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8s4J06110; Thu, 23 Jan 2003 03:54:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8rwJ06077 for ; Thu, 23 Jan 2003 03:53:58 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00041 for ; Thu, 23 Jan 2003 03:34:58 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0N8bO006184 for ; Thu, 23 Jan 2003 10:37:24 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 10:38:22 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:38:23 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:38:23 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:38:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C2BA.C9838850" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Thu, 23 Jan 2003 10:38:22 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcLCVWmnz0myWo0AQE+9CiE/2XnCOgAZVJMA To: , X-OriginalArrivalTime: 23 Jan 2003 08:38:22.0770 (UTC) FILETIME=[C9F3D120:01C2C2BA] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C2BA.C9838850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assigned issue 7: http://www-nrc.nokia.com/sua/nsis/nsis-issues.htm -----Original Message----- From: ext Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com] Sent: 22 January, 2003 22:27 To: nsis@ietf.org Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt All,=20 Issue Name: ?=20 Submitter name: Louis-Nicolas Hamer=20 Submitter email address: nhamer@nortelnetworks.com=20 Date first submitted: 22/01/2003=20 Reference: none=20 Document: draft-ietf-nsis-req-06.txt=20 Comment type: T=20 Priority: 2 =20 Section: 10.3=20 I have a few comments on section 10.3 UMTS access.=20 Sorry for sending the late comments.=20 Section 10.3 provides a good description of the UMTS access overall=20 architecture for 3GPP release 5. But, it then speculates on how NSIS=20 could fit into the 3GPP release 6, which is still not yet defined by the = way.=20 Although, I agree NSIS could indeed have a place in 3GPP release 6,=20 I can't agree with the way it is depicted in the draft currently.=20 First, I am not convinced the PCF is the right place to locate the NSIS=20 Initiator. Why not consider the GGSN? Or the UE?=20 Secondly, if it would be located in the PCF (or the GGSN for that = matter), what=20 would be the value-added? I personally think the important section of = the network=20 where nsis signaling would be needed is at the access level, not in the = backbone network.=20 So why originate NSIS after the access network? Value is limited IMHO.=20 I think having this example, as it is currently is not acceptable. I = propose=20 we clean it up:=20 -maybe we can agree on a more acceptable example usage of nsis = in UMTS access?=20 -maybe we could instead list all of the possible usages (instead = of listing only one)=20 -or strip out the example all together (I would prefer not too). = I am not sure who contributed this section, so I guess in order to = achieve closure, it would be best=20 if the contributors contacted me directly or through the mailing list. = Unless the chair (or someone else) has a better way forward. Cheers,=20 L-N=20 > -----Original Message-----=20 > From: Anders.P.Bergsten@telia.se [ mailto:Anders.P.Bergsten@telia.se]=20 > Sent: Wednesday, January 22, 2003 3:23 AM=20 > To: john.loughney@nokia.com; nsis@ietf.org=20 > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt=20 >=20 >=20 > John,=20 >=20 > here are some of my issues to the document. Sorry for posting=20 > them late.=20 >=20 > Issue Name:=20 > Submitter name: Anders Bergsten=20 > Submitter email address: anders.p.bergsten@telia.se=20 > Date first submitted: 03-01-20=20 > Reference: -=20 > Document: draft-ietf-nsis-req-06.txt=20 > Comment type: T=20 > Priority: 2=20 > Document Section: 2, pg 3, last paragraph=20 > Rationale/Explanation of issue: Definition of=20 > Receiver-initiated signaling protocol seems flawed. The=20 > definition states that the NSIS responder _initiates_ the=20 > reservation on behalf of the receiver. According to the=20 > definition of NSIS Responder, the NSIS Responder _responds_=20 > to NSIS messages. The NSIS Responder does not initiate a=20 > message, hence, the definition is flawed. The definition of=20 > Receiver-initiated signaling protocol should be defined by=20 > where the NSIS Initiator is situated, not where the NSIS=20 > Responder is situated. Therefore I propose a change to=20 > something similar to the below.=20 >=20 > Requested change:=20 > "Receiver-initiated signaling protocol: A receiver-initiated=20 > signaling protocol is a protocol where the resources that the=20 > signaling protocol should reserve is situated topologically=20 > closer to the source than the NSIS Initiator is. This means=20 > is that the resource management functions need to be=20 > processed from the NSIS Initiator back towards the sender."=20 >=20 >=20 > Issue Name:=20 > Submitter name: Anders Bergsten=20 > Submitter email address: anders.p.bergsten@telia.se=20 > Date first submitted: 03-01-20=20 > Reference: -=20 > Document: draft-ietf-nsis-req-06.txt=20 > Comment type: T=20 > Priority: 2 (?)=20 > Document Section: 5.2.2=20 > Rationale/Explanation of issue: The section contain two=20 > different and possibly opposing requirement. The title says=20 > "No constraint MUST be posed on the signaling..." and page=20 > 12, paragraph 5 says "... NSIS signaling used between those=20 > virtual routers MUST follow the same path as the data". These=20 > are two different requirements where the second actually pose=20 > a contraint on the signaling path.=20 >=20 > Requested change: I personally prefer the second requirement=20 > and propose to use only that. This requirement states that it=20 > is some contraint on the path followed, which I think is=20 > good. I think it also sufficiently covers both the "bandwidth=20 > broker" and on-path alternatives to signaling. If people=20 > still prefer the first, I would like the requirement to state=20 > the following: "The only constraint on the signaling and NSIS=20 > forwarders is that they follow the correct AS-path" (or some=20 > equivilant term for AS-path).=20 >=20 >=20 > Issue Name:=20 > Submitter name: Anders Bergsten=20 > Submitter email address: anders.p.bergsten@telia.se=20 > Date first submitted: 03-01-13=20 > Reference: -=20 > Document: draft-ietf-nsis-req-06.txt=20 > Comment type: T=20 > Priority: 2=20 > Document Section: 5.3.4=20 > Rationale/Explanation of issue: "A request for service MUST=20 > be answered at least with a yes or no". This does not state=20 > by whom the reply should be sent, neither is it clear enough=20 > on how to be interpreted. The only thing this adds to me is=20 > uncertainty - there is a risk that someone interpretes this=20 > as "if I have sent a request I can expect a reply", ie "The=20 > network MUST answer a request for service". This is=20 > impossible to promise, since packets can be lost.=20 >=20 > Requested change: I prefer to keep the requirement in the=20 > title and let that be the requirement. This requirement is=20 > slightly different than what is written within the text, and=20 > it talks about "success" of a service. If the requirement in=20 > the text should be interpreted as "A NSIS responder MUST=20 > answer a request for service", I want that stated. Thus, I=20 > request one of two resolutions to this issue:=20 > 1) Use only the requirement in the title (only a=20 > success needs to be reported) and remove the "clarifying"=20 > requirement in the text.=20 > 2) Add information on WHO must answer to the request=20 > (Something along, "The NSIS responder MUST reply with at=20 > least a yes/no").=20 >=20 >=20 > Issue Name:=20 > Submitter name: Anders Bergsten=20 > Submitter email address: anders.p.bergsten@telia.se=20 > Date first submitted: 03-01-20=20 > Reference: -=20 > Document: draft-ietf-nsis-req-06.txt=20 > Comment type: T=20 > Priority: 2=20 > Document Section: 5.4.5=20 > Rationale/Explanation of issue: The requirement ("the network=20 > MUST NOT know that a relationship between the group flows=20 > exists", etc) in last paragraph of the section is a very hard=20 > requirement to meet up with, I think. The interaction between=20 > routing and state maintainance causes some problems here. I=20 > start with a pure on-data-path signaling scenario. If a=20 > router is to maintain state and get a group of state=20 > requests, it must assume that they actually belong to him,=20 > otherwise it does not make sense. This requires either that=20 > the previous node does group flows together that have a=20 > relation with next-hop node or that the node can force=20 > relationship onto a group of flows (this method is used by=20 > MPLS), where we control the path. If we do not allow for "the=20 > network" to know relationships between flows, a node cannot=20 > assume that the resource belongs to him and need to have a=20 > method to find the right owner of the flow - which may be=20 > harder to solve than allowing a node to know a r! elationship=20 > between flows.=20 > Requested change: Not sure how to resolve the issue,=20 > unfortunately. The best thing would be to remove the=20 > paragraph and leave only the requirement on that NSIS MAY=20 > group flows.=20 >=20 >=20 > Then I have a general comment about the use of MUST/SHOULD...=20 > I feel there are too many requirements that are MUSTs, and I=20 > am not sure that it is understood how these requirements is=20 > met up by a protocol (ie what is the cost for having to=20 > implement this). For example, what is the implications of=20 > this requirement "State MUST be addressed independent of flow=20 > identification"? I would request that the MUSTs/SHOULDs etc=20 > is not to be interpreted as in RFC2119 as I believe that=20 > would be hard to find a protocol that match all the MUSTs. I=20 > would request to use must/should/may instead so that=20 > subsequent work do not interprete them as "hard"=20 > requirements, but rather as indications of requirement.=20 >=20 > Anders=20 >=20 > > -----Original Message-----=20 > > From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com]=20 > > Sent: den 8 januari 2003 02:04=20 > > To: nsis@ietf.org=20 > > Cc: mankin@psg.com=20 > > Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt=20 > >=20 > >=20 > > Dear all,=20 > >=20 > > Marcus Brunner has submitted an updated version of the=20 > > requirements document. He feels that he has addressed all of=20 > > the remaining open issues, and we feel that it is ready for=20 > > WG last call. There are a number of editorial nits, but=20 > > otherwise the document is in good shape.=20 > >=20 > > Therefore, I am asking the working group to review the=20 > > document and submit any issues found.=20 > >=20 > > The working group last call will last until Wednesday January=20 > > 22nd, 4 PM Pacific Coast Time.=20 > >=20 > > I will send a subsequent mail outlining the procedure for=20 > > submitting issues.=20 > >=20 > > thanks,=20 > > John=20 > > _______________________________________________=20 > > nsis mailing list=20 > > nsis@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/nsis=20 > >=20 > _______________________________________________=20 > nsis mailing list=20 > nsis@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 ------_=_NextPart_001_01C2C2BA.C9838850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt

Assigned issue 7:

http://www-nrc.nokia.com/sua/nsis/nsis-issues.htm

-----Original Message-----
From: ext Louis-Nicolas = Hamer=20 [mailto:nhamer@nortelnetworks.com]
Sent: 22 January, 2003=20 22:27
To: nsis@ietf.org
Subject: RE: [NSIS] WG = Last Call=20 on draft-ietf-nsis-req-06.txt

All,

Issue Name: ?
Submitter = name:=20 Louis-Nicolas Hamer
Submitter email address: = nhamer@nortelnetworks.com
Date first = submitted:=20 22/01/2003
Reference: none
Document: draft-ietf-nsis-req-06.txt
Comment=20 type: T
Priority:  2  =
Section: 10.3


I have a few comments on section 10.3 UMTS = access.=20
Sorry for sending the late comments.

Section 10.3 provides a good description of the UMTS = access=20 overall
architecture for 3GPP release 5. = But, it then=20 speculates on how NSIS
could fit into the = 3GPP release=20 6, which is still not yet defined by the way.
Although, I agree NSIS could indeed have a place in 3GPP = release 6,=20
I can't agree with the way it is depicted in = the draft=20 currently.

First, I am not convinced the PCF is the right place = to locate=20 the NSIS
Initiator. Why not consider the = GGSN? Or the=20 UE?
Secondly, if it would be located in the = PCF (or=20 the GGSN for that matter), what
would be the = value-added? I personally think the important section of the = network=20
where nsis signaling would be needed is at the = access level,=20 not in the backbone network.
So why = originate NSIS=20 after the access network? Value is limited IMHO.

I think having this example, as it is currently is = not=20 acceptable. I propose
we clean it up: =
        -maybe = we can=20 agree on a more acceptable example usage of nsis in UMTS = access?=20
        -maybe = we could=20 instead list all of the possible usages (instead of listing only = one)=20
        -or = strip out the=20 example all together (I would prefer not too).

I am not sure who contributed this section, so I = guess in=20 order to achieve closure, it would be best
if the=20 contributors contacted me directly or through the mailing list. Unless = the=20 chair (or someone else) has a better way forward.

Cheers,

L-N



> -----Original Message-----
>=20 From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia= .se]=20
> Sent: Wednesday, January 22, 2003 3:23 = AM=20
> To: john.loughney@nokia.com; = nsis@ietf.org=20
> Subject: RE: [NSIS] WG Last Call on=20 draft-ietf-nsis-req-06.txt
> =
>
> John,
>=20
> here are some of my issues to the = document. Sorry=20 for posting
> them late.
>
> Issue Name: =
> Submitter name: Anders Bergsten
>=20 Submitter email address: anders.p.bergsten@telia.se
> Date first submitted: 03-01-20
>=20 Reference: -
> Document:=20 draft-ietf-nsis-req-06.txt
> Comment = type: T=20
> Priority:  2
> Document=20 Section: 2, pg 3, last paragraph
>=20 Rationale/Explanation of issue: Definition of
>=20 Receiver-initiated signaling protocol seems flawed. The =
> definition states that the NSIS responder _initiates_ = the=20
> reservation on behalf of the receiver. = According=20 to the
> definition of NSIS Responder, = the NSIS=20 Responder _responds_
> to NSIS messages. = The NSIS=20 Responder does not initiate a
> message, = hence, the=20 definition is flawed. The definition of
> = Receiver-initiated signaling protocol should be defined by =
> where the NSIS Initiator is situated, not where the NSIS =
> Responder is situated. Therefore I = propose a=20 change to
> something similar to the = below.=20
>
> = Requested change:=20
> "Receiver-initiated signaling protocol: = A=20 receiver-initiated
> signaling protocol = is a=20 protocol where the resources that the
> = signaling=20 protocol should reserve is situated topologically
>=20 closer to the source than the NSIS Initiator is. This means =
> is that the resource management functions need to be=20
> processed from the NSIS Initiator back = towards=20 the sender."
>
>=20
> Issue Name:
>=20 Submitter name: Anders Bergsten
> = Submitter email=20 address: anders.p.bergsten@telia.se
> = Date first=20 submitted: 03-01-20
> Reference: - =
> Document: draft-ietf-nsis-req-06.txt
>=20 Comment type: T
> Priority:  2 = (?)=20
> Document Section: 5.2.2
>=20 Rationale/Explanation of issue: The section contain two =
> different and possibly opposing requirement. The title = says=20
> "No constraint MUST be posed on the = signaling..."=20 and page
> 12, paragraph 5 says "... NSIS = signaling=20 used between those
> virtual routers MUST = follow=20 the same path as the data". These
> are = two=20 different requirements where the second actually pose
> a contraint on the signaling path.
>=20
> Requested change: I personally prefer = the second=20 requirement
> and propose to use only = that. This=20 requirement states that it
> is some = contraint on=20 the path followed, which I think is
> = good. I think=20 it also sufficiently covers both the "bandwidth
>=20 broker" and on-path alternatives to signaling. If people =
> still prefer the first, I would like the requirement to = state=20
> the following: "The only constraint on = the=20 signaling and NSIS
> forwarders is that = they follow=20 the correct AS-path" (or some
> = equivilant term for=20 AS-path).
>
>=20
> Issue Name:
>=20 Submitter name: Anders Bergsten
> = Submitter email=20 address: anders.p.bergsten@telia.se
> = Date first=20 submitted: 03-01-13
> Reference: - =
> Document: draft-ietf-nsis-req-06.txt
>=20 Comment type: T
> Priority:  = 2=20
> Document Section: 5.3.4
>=20 Rationale/Explanation of issue: "A request for service MUST =
> be answered at least with a yes or no". This does not = state=20
> by whom the reply should be sent, = neither is it=20 clear enough
> on how to be interpreted. = The only=20 thing this adds to me is
> uncertainty - = there is a=20 risk that someone interpretes this
> as = "if I have=20 sent a request I can expect a reply", ie "The
>=20 network MUST answer a request for service". This is
> impossible to promise, since packets can be lost. =
>
> Requested change: I = prefer to keep=20 the requirement in the
> title and let = that be the=20 requirement. This requirement is
> = slightly=20 different than what is written within the text, and
> it talks about "success" of a service. If the = requirement in=20
> the text should be interpreted as "A = NSIS=20 responder MUST
> answer a request for = service", I=20 want that stated. Thus, I
> request one = of two=20 resolutions to this issue:
>=20       1) Use only the requirement in the = title (only=20 a
> success needs to be reported) and = remove the=20 "clarifying"
> requirement in the = text.=20
>       2) Add = information on WHO=20 must answer to the request
> (Something = along, "The=20 NSIS responder MUST reply with at
> least = a=20 yes/no").
>
>=20
> Issue Name:
>=20 Submitter name: Anders Bergsten
> = Submitter email=20 address: anders.p.bergsten@telia.se
> = Date first=20 submitted: 03-01-20
> Reference: - =
> Document: draft-ietf-nsis-req-06.txt
>=20 Comment type: T
> Priority:  = 2=20
> Document Section: 5.4.5
>=20 Rationale/Explanation of issue: The requirement ("the network =
> MUST NOT know that a relationship between the group = flows=20
> exists", etc) in last paragraph of the = section is=20 a very hard
> requirement to meet up = with, I think.=20 The interaction between
> routing and = state=20 maintainance causes some problems here. I
> start=20 with a pure on-data-path signaling scenario. If a
>=20 router is to maintain state and get a group of state
> requests, it must assume that they actually belong to = him,=20
> otherwise it does not make sense. This = requires=20 either that
> the previous node does = group flows=20 together that have a
> relation with = next-hop node=20 or that the node can force
> relationship = onto a=20 group of flows (this method is used by
> = MPLS),=20 where we control the path. If we do not allow for "the =
> network" to know relationships between flows, a node = cannot=20
> assume that the resource belongs to him = and need=20 to have a
> method to find the right = owner of the=20 flow - which may be
> harder to solve = than allowing=20 a node to know a r! elationship
> between = flows.=20
> Requested change: Not sure how to = resolve the=20 issue,
> unfortunately. The best thing = would be to=20 remove the
> paragraph and leave only the = requirement on that NSIS MAY
> group = flows.=20
>
> =
> Then I have a general comment about the use of = MUST/SHOULD...=20
> I feel there are too many requirements = that are=20 MUSTs, and I
> am not sure that it is = understood=20 how these requirements is
> met up by a = protocol=20 (ie what is the cost for having to
> = implement=20 this). For example, what is the implications of
>=20 this requirement "State MUST be addressed independent of flow =
> identification"? I would request that the MUSTs/SHOULDs = etc=20
> is not to be interpreted as in RFC2119 = as I=20 believe that
> would be hard to find a = protocol=20 that match all the MUSTs. I
> would = request to use=20 must/should/may instead so that
> = subsequent work=20 do not interprete them as "hard"
> = requirements,=20 but rather as indications of requirement.
>=20
> Anders
>=20
> > -----Original Message----- =
> > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20
> > Sent: den 8 januari 2003 02:04 =
> > To: nsis@ietf.org
> = > Cc:=20 mankin@psg.com
> > Subject: [NSIS] WG = Last Call=20 on draft-ietf-nsis-req-06.txt
> >=20
> >
> = > Dear=20 all,
> >
> >=20 Marcus Brunner has submitted an updated version of the =
> > requirements document.  He feels that he has = addressed=20 all of
> > the remaining open issues, = and we=20 feel that it is ready for
> > WG last=20 call.  There are a number of editorial nits, but
> > otherwise the document is in good shape. =
> >
> > Therefore, I am = asking the=20 working group to review the
> > = document and=20 submit any issues found.
> > =
> > The working group last call will last until = Wednesday=20 January
> > 22nd, 4 PM Pacific Coast=20 Time.
> >
> > I=20 will send a subsequent mail outlining the procedure for =
> > submitting issues.
> = >=20
> > thanks,
> >=20 John
> >=20 _______________________________________________
>=20 > nsis mailing list
> > = nsis@ietf.org=20
> > https://www1.ietf.or= g/mailman/listinfo/nsis=20
> >
>=20 _______________________________________________
>=20 nsis mailing list
> nsis@ietf.org =
> https://www1.ietf.or= g/mailman/listinfo/nsis=20
>

------_=_NextPart_001_01C2C2BA.C9838850-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 23 03:36:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00128 for ; Thu, 23 Jan 2003 03:36:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N8tD006227 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 03:55:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8t3J06193; Thu, 23 Jan 2003 03:55:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8sgJ06160 for ; Thu, 23 Jan 2003 03:54:42 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00085 for ; Thu, 23 Jan 2003 03:35:43 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0N8fSt22530 for ; Thu, 23 Jan 2003 10:41:28 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 23 Jan 2003 10:39:03 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:39:02 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:38:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Thu, 23 Jan 2003 10:38:59 +0200 Message-ID: Thread-Topic: [NSIS] Service definition and negotiation Thread-Index: AcKufOi7hB8b/4mDS/SoeWI8pe7i+QIJg2fwArAXPiAAVd9KIA== To: X-OriginalArrivalTime: 23 Jan 2003 08:38:59.0432 (UTC) FILETIME=[DFCDFE80:01C2C2BA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0N8sgJ06161 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Assigned issues 2 - 6: http://www-nrc.nokia.com/sua/nsis/nsis-issues.htm > -----Original Message----- > From: ext [mailto:Anders.P.Bergsten@telia.se] > Sent: 22 January, 2003 10:23 > To: Loughney John (NRC/Helsinki); nsis@ietf.org > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > John, > > here are some of my issues to the document. Sorry for posting > them late. > > Issue Name: > Submitter name: Anders Bergsten > Submitter email address: anders.p.bergsten@telia.se > Date first submitted: 03-01-20 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Document Section: 2, pg 3, last paragraph > Rationale/Explanation of issue: Definition of > Receiver-initiated signaling protocol seems flawed. The > definition states that the NSIS responder _initiates_ the > reservation on behalf of the receiver. According to the > definition of NSIS Responder, the NSIS Responder _responds_ > to NSIS messages. The NSIS Responder does not initiate a > message, hence, the definition is flawed. The definition of > Receiver-initiated signaling protocol should be defined by > where the NSIS Initiator is situated, not where the NSIS > Responder is situated. Therefore I propose a change to > something similar to the below. > > Requested change: > "Receiver-initiated signaling protocol: A receiver-initiated > signaling protocol is a protocol where the resources that the > signaling protocol should reserve is situated topologically > closer to the source than the NSIS Initiator is. This means > is that the resource management functions need to be > processed from the NSIS Initiator back towards the sender." > > > Issue Name: > Submitter name: Anders Bergsten > Submitter email address: anders.p.bergsten@telia.se > Date first submitted: 03-01-20 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 (?) > Document Section: 5.2.2 > Rationale/Explanation of issue: The section contain two > different and possibly opposing requirement. The title says > "No constraint MUST be posed on the signaling..." and page > 12, paragraph 5 says "... NSIS signaling used between those > virtual routers MUST follow the same path as the data". These > are two different requirements where the second actually pose > a contraint on the signaling path. > > Requested change: I personally prefer the second requirement > and propose to use only that. This requirement states that it > is some contraint on the path followed, which I think is > good. I think it also sufficiently covers both the "bandwidth > broker" and on-path alternatives to signaling. If people > still prefer the first, I would like the requirement to state > the following: "The only constraint on the signaling and NSIS > forwarders is that they follow the correct AS-path" (or some > equivilant term for AS-path). > > > Issue Name: > Submitter name: Anders Bergsten > Submitter email address: anders.p.bergsten@telia.se > Date first submitted: 03-01-13 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Document Section: 5.3.4 > Rationale/Explanation of issue: "A request for service MUST > be answered at least with a yes or no". This does not state > by whom the reply should be sent, neither is it clear enough > on how to be interpreted. The only thing this adds to me is > uncertainty - there is a risk that someone interpretes this > as "if I have sent a request I can expect a reply", ie "The > network MUST answer a request for service". This is > impossible to promise, since packets can be lost. > > Requested change: I prefer to keep the requirement in the > title and let that be the requirement. This requirement is > slightly different than what is written within the text, and > it talks about "success" of a service. If the requirement in > the text should be interpreted as "A NSIS responder MUST > answer a request for service", I want that stated. Thus, I > request one of two resolutions to this issue: > 1) Use only the requirement in the title (only a > success needs to be reported) and remove the "clarifying" > requirement in the text. > 2) Add information on WHO must answer to the request > (Something along, "The NSIS responder MUST reply with at > least a yes/no"). > > > Issue Name: > Submitter name: Anders Bergsten > Submitter email address: anders.p.bergsten@telia.se > Date first submitted: 03-01-20 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Document Section: 5.4.5 > Rationale/Explanation of issue: The requirement ("the network > MUST NOT know that a relationship between the group flows > exists", etc) in last paragraph of the section is a very hard > requirement to meet up with, I think. The interaction between > routing and state maintainance causes some problems here. I > start with a pure on-data-path signaling scenario. If a > router is to maintain state and get a group of state > requests, it must assume that they actually belong to him, > otherwise it does not make sense. This requires either that > the previous node does group flows together that have a > relation with next-hop node or that the node can force > relationship onto a group of flows (this method is used by > MPLS), where we control the path. If we do not allow for "the > network" to know relationships between flows, a node cannot > assume that the resource belongs to him and need to have a > method to find the right owner of the flow - which may be > harder to solve than allowing a node to know a relationship > between flows. > Requested change: Not sure how to resolve the issue, > unfortunately. The best thing would be to remove the > paragraph and leave only the requirement on that NSIS MAY > group flows. > > > Then I have a general comment about the use of MUST/SHOULD... > I feel there are too many requirements that are MUSTs, and I > am not sure that it is understood how these requirements is > met up by a protocol (ie what is the cost for having to > implement this). For example, what is the implications of > this requirement "State MUST be addressed independent of flow > identification"? I would request that the MUSTs/SHOULDs etc > is not to be interpreted as in RFC2119 as I believe that > would be hard to find a protocol that match all the MUSTs. I > would request to use must/should/may instead so that > subsequent work do not interprete them as "hard" > requirements, but rather as indications of requirement. > > Anders > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: den 8 januari 2003 02:04 > > To: nsis@ietf.org > > Cc: mankin@psg.com > > Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > > > > Dear all, > > > > Marcus Brunner has submitted an updated version of the > > requirements document. He feels that he has addressed all of > > the remaining open issues, and we feel that it is ready for > > WG last call. There are a number of editorial nits, but > > otherwise the document is in good shape. > > > > Therefore, I am asking the working group to review the > > document and submit any issues found. > > > > The working group last call will last until Wednesday January > > 22nd, 4 PM Pacific Coast Time. > > > > I will send a subsequent mail outlining the procedure for > > submitting issues. > > > > thanks, > > John > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 23 03:37:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00156 for ; Thu, 23 Jan 2003 03:37:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N8uAF06347 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 03:56:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8u2J06297; Thu, 23 Jan 2003 03:56:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8t7J06219 for ; Thu, 23 Jan 2003 03:55:07 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00109 for ; Thu, 23 Jan 2003 03:36:08 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0N8fst22802 for ; Thu, 23 Jan 2003 10:41:54 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 10:39:33 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:39:33 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:39:32 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:39:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Thu, 23 Jan 2003 10:39:30 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcLCaVU7OLLNCx1aSVi5WtfMcPaHegAUZFLw To: , X-OriginalArrivalTime: 23 Jan 2003 08:39:32.0073 (UTC) FILETIME=[F3429D90:01C2C2BA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0N8t7J06220 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Assigned issues 8 - 14: http://www-nrc.nokia.com/sua/nsis/nsis-issues.htm > -----Original Message----- > From: ext Kuntal Chowdhury [mailto:kuntal@iqmail.net] > Sent: 23 January, 2003 00:47 > To: nsis@ietf.org > Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Hi all, > Here are a few issues that I found so far. IMHO, the document needs a > through editorial scrub. > > Regards, > Kuntal > > > > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 2 > Document Section: 2 > Rationale/Explanation of issue: Definition of RMF should also mention > about de-allocation > > Requested change: > Resource Management Function (RMF): An abstract > concept,representing the > management of resources in a domain or a node. This includes > admission > control and resource allocation/de-allocation. > > > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: > Document Section: 2 > Rationale/Explanation of issue: The current definition of > Provisioning > has unnecessary texts. For example it says LSP initiation in > MPLS is a > matter of provisioning. IMO, it's not entirely correct, LSPs can be > initiated by a LER based on it's internal logic which may be > configured > by suitable provisioning mechanism. > > Requested change: > Provisioning: the act of configuring an NE for allocating > resources to a > flow or aggregate of flows. > > > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: > Document Section: 2 > Rationale/Explanation of issue: QoS technology definition > needs a bit of > correction, e.g. MPLS is not really a QoS technology, it is more used > for Traffic Engineering. > > Requested change: > QoS Technology: a generic term for a set of protocols, standards and > mechanisms that can be used within a QoS domain/subdomain to > manage the > QoS provided to flows or aggregates that traverse the domain. > An example > QoS technology is DiffServ. A QoS technology is associated > with certain > QoS provisioning techniques. > > > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: > Document Section: 2 > Rationale/Explanation of issue: The document states that NSIS is not > restricted to QoS signaling only, it also covers signaling > required for > other purposes such as ....not mentioned! > The requirements are based on the fact that a signal is > initiated from > an NSIS initiator for allocation of network resources. It > would be nice > to see some examples of non-QoS signals that require allocation of > network resources in the internet. > > > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: > Document Section: 4.1 > Rationale/Explanation of issue: > " 6. NSIS assumes to operate with networks using standard ("normal") > L3 routing. Where "normal" is not specified more exactly > on purpose." > > this is very vague assumption. Not sure which routing scheme is > considered "normal". If some are normal then which ones are > "abnormal"? > > Requested change: > 6. NSIS assumes to operate with networks using standard L3 routing. > > > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: > Document Section: 5.2.1 > Rationale/Explanation of issue: > "5.2.1 The placement of NSIS Initiator, Forwarder, Responder > MUST be free" > > MUST be free of what? > > Requested change: > 5.2.1 The placement of NSIS Initiator, Forwarder, and > Responder anywhere > in the network MUST be allowed" > > > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: > Document Section: 5.2.2 > Rationale/Explanation of issue: > "5.2.2 No constraint MUST be posed the signaling and NSIS > Forwarders to > be in the data path. " > > Need to rephrase this requirement. > > Requested change: > 5.2.2 There MUST not be any constraint to always require the NSIS > forwarder to be on the data path. > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Jan 23 03:37:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00170 for ; Thu, 23 Jan 2003 03:37:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N8uFj06361 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 03:56:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8u5J06329; Thu, 23 Jan 2003 03:56:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8tcJ06263 for ; Thu, 23 Jan 2003 03:55:38 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00122 for ; Thu, 23 Jan 2003 03:36:39 -0500 (EST) 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 h0N8d6007408 for ; Thu, 23 Jan 2003 10:39:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 10:40:06 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:40:05 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:40:04 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:40:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments on draft-ietf-nsis-req-06.txt Date: Thu, 23 Jan 2003 10:40:01 +0200 Message-ID: Thread-Topic: [NSIS] comments on draft-ietf-nsis-req-06.txt Thread-Index: AcLCdv8sR9MeAM6lTeuuNcIqMQOTcwAQ/fNQ To: , X-OriginalArrivalTime: 23 Jan 2003 08:40:02.0601 (UTC) FILETIME=[0574D190:01C2C2BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0N8tcJ06264 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Assigned issues 15 - 23: http://www-nrc.nokia.com/sua/nsis/nsis-issues.htm > -----Original Message----- > From: ext Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] > Sent: 23 January, 2003 02:22 > To: 'nsis@ietf.org' > Subject: [NSIS] comments on draft-ietf-nsis-req-06.txt > > > Hi, > I have some comments on the draft, sorry for being late ... > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: Abstract, page 1 line 41 > Rationale/Explanation of issue:typo error "in recent year" > Requested change:"in the recent year" > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 1, page 2 line 51 > Rationale/Explanation of issue:typo error "to t4est" > Requested change:"to test" > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 1, page 3 line 3 > Rationale/Explanation of issue:typo error "requirement > documents", "other > application" > Requested change:"requirements document", "other applications" > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 2, page 3 line 14 > Rationale/Explanation of issue:text editing/formating > Requested change:Need to have a formal section introduction > or take it out > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 2, page 4 line 17 > Rationale/Explanation of issue: simplify the text and make it generic > "Control Information: the information the governs for instance the QoS > treatment to be applied to a flow or aggregate, including the > service class, > flow administration, and any associated security or > accounting information." > > Requested change:"Control information: information that governs the > treatment to be applied to a flow or aggregate" > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 3, page 5 line 10 > Rationale/Explanation of issue: simplify the text > "A basic goal should be to re-use these wherever possible, > and to focus > requirements work at an early stage on those areas where a > new solution is > needed (e.g. an especially simple one). We also try to avoid defining > requirements related to internal implementation aspects." > Requested change:"A basis goal should be to re-use the > proposed architecture > wherever possibleâEUR > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 3, page 6 line 29 > Rationale/Explanation of issue: What about the NSIS > responder? we should not > impose where that function is hosted > âEURoeThe placement of the NSIS Initiators and NSIS Forwarders > is not fixed.âEUR > Requested change: âEURoeThe placement of the NSIS Initiators, > responders and NSIS > Forwarders is not fixed.âEUR > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 3, page 8 line 39 > Rationale/Explanation of issue: âEURoe the protection of > non-signaling messages âEURĤ > corresponding application layer protocolâEUR. > It could confuse people on point #7 âEURoeprotection of > non-signaling messages is > outside the scope of the protocolâEUR. > Requested change: > Either we put it in the annex as is or suggest to reword it as: > âEURoeThe NSIS Forwarder need to have sufficient information to > be able to > uniquely identify a specific user flow even when security > mechanisms are > applied to that flowâEUR > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 5.1.1 > Rationale/Explanation of issue: âEURoeMUST be applicable for different > technologiesâEUR IsnâEUR(tm)t the requirement about having > different types of services > that could be signaled with the NSIS protocol? It is probably > best to reword > it for more clarity > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 5.2.2 > Rationale/Explanation of issue: Typo error.âEURoeNo constraint > MUST be posed the > signaling and NSIS Forwarders to > be in the data path.âEUR > Requested change: could be simply reworded to "independence > of the signaling > path and the data path" > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 5.3.3 page 13 line 41 > Rationale/Explanation of issue: Typo error.âEURoethe network > nodes can locally > repair this type errorâEUR > Requested change: âEURoethe network nodes can locally repair > this type of errorâEUR > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 5.3.3 page 14 line 3 > Rationale/Explanation of issue: âEURoeService upgrade available: > If a previously > requested better service becomes available.âEUR > We might want to have this notification sent even if the > service was not > asked for it. The decision of sending or not the notification > is a policy > issue but we need to make sure that we can send the notification. > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 5.3.4 page 14 line 30 > Rationale/Explanation of issue: rewording - âEURoeto also get a > description of > what amount of resources a request is possibleâEUR > Requested change: âEURoeto also get a description of what amount > of available > requested resources are availableâEUR > > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 5.4.1 page 15 line 14 > Rationale/Explanation of issue: rewording - âEURnote that a > provider or that > particular services requestedâEUR > Requested change: âEURoenote that the provider of the particular > requested > serviceâEUR > > > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 5.4.2 page 15 line 18 > Rationale/Explanation of issue: rewording - âEURSHOULD > possible to add and > remove local domain information" > Requested change: "It SHOULD be possible to add and remove > local domain > informationâEUR > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 5.4.5 page 16 line 3 > Rationale/Explanation of issue: âEURoeHowever, the network MUST > NOT know that a > relationship between the grouped flows exists. There MUST NOT be any > transactional semantic associated with the grouping. It is > only meant for > optimization purposes and each reservation MUST be handled > separately from > each other.âEUR > > We need to have a MAY for having semantics to group flows > that are bundled. > I agree that the flows could have independent properties and > associated > resource reservations could still be taken down or processed > independently. > The usefulness of grouping these flows is primarily to tear > down all their > associated states at the same time without repeating the tear > down message > several time (i.e. command aggregation) and to minimize the > size of the > message data. > > Regards > Cedric > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Jan 23 03:45:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00333 for ; Thu, 23 Jan 2003 03:45:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N93Rj07049 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 04:03:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N93FJ07037; Thu, 23 Jan 2003 04:03:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N92gJ07000 for ; Thu, 23 Jan 2003 04:02:42 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00321 for ; Thu, 23 Jan 2003 03:43:43 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0N8k9013474 for ; Thu, 23 Jan 2003 10:46:09 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 10:47:06 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:47:08 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:47:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 23 Jan 2003 10:47:07 +0200 Message-ID: Thread-Topic: [NSIS] comments on draft-ietf-nsis-req-06.txt Thread-Index: AcLCdv8sR9MeAM6lTeuuNcIqMQOTcwARMQ7w To: , X-OriginalArrivalTime: 23 Jan 2003 08:47:07.0810 (UTC) FILETIME=[02E69020:01C2C2BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0N92gJ07001 Subject: [NSIS] Issues 15 - 23 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Cedric, Thanks for the comments, I can support them. What does the WG feel? br, John > -----Original Message----- > From: ext Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] > Sent: 23 January, 2003 02:22 > To: 'nsis@ietf.org' > Subject: [NSIS] comments on draft-ietf-nsis-req-06.txt > > > Hi, > I have some comments on the draft, sorry for being late ... > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: Abstract, page 1 line 41 > Rationale/Explanation of issue:typo error "in recent year" > Requested change:"in the recent year" > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 1, page 2 line 51 > Rationale/Explanation of issue:typo error "to t4est" > Requested change:"to test" > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 1, page 3 line 3 > Rationale/Explanation of issue:typo error "requirement > documents", "other > application" > Requested change:"requirements document", "other applications" > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 2, page 3 line 14 > Rationale/Explanation of issue:text editing/formating > Requested change:Need to have a formal section introduction > or take it out > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 2, page 4 line 17 > Rationale/Explanation of issue: simplify the text and make it generic > "Control Information: the information the governs for instance the QoS > treatment to be applied to a flow or aggregate, including the > service class, > flow administration, and any associated security or > accounting information." > > Requested change:"Control information: information that governs the > treatment to be applied to a flow or aggregate" > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 3, page 5 line 10 > Rationale/Explanation of issue: simplify the text > "A basic goal should be to re-use these wherever possible, > and to focus > requirements work at an early stage on those areas where a > new solution is > needed (e.g. an especially simple one). We also try to avoid defining > requirements related to internal implementation aspects." > Requested change:"A basis goal should be to re-use the > proposed architecture > wherever possibleâEUR > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 3, page 6 line 29 > Rationale/Explanation of issue: What about the NSIS > responder? we should not > impose where that function is hosted > âEURoeThe placement of the NSIS Initiators and NSIS Forwarders > is not fixed.âEUR > Requested change: âEURoeThe placement of the NSIS Initiators, > responders and NSIS > Forwarders is not fixed.âEUR > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 3, page 8 line 39 > Rationale/Explanation of issue: âEURoe the protection of > non-signaling messages âEURĤ > corresponding application layer protocolâEUR. > It could confuse people on point #7 âEURoeprotection of > non-signaling messages is > outside the scope of the protocolâEUR. > Requested change: > Either we put it in the annex as is or suggest to reword it as: > âEURoeThe NSIS Forwarder need to have sufficient information to > be able to > uniquely identify a specific user flow even when security > mechanisms are > applied to that flowâEUR > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 5.1.1 > Rationale/Explanation of issue: âEURoeMUST be applicable for different > technologiesâEUR IsnâEUR(tm)t the requirement about having > different types of services > that could be signaled with the NSIS protocol? It is probably > best to reword > it for more clarity > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 5.2.2 > Rationale/Explanation of issue: Typo error.âEURoeNo constraint > MUST be posed the > signaling and NSIS Forwarders to > be in the data path.âEUR > Requested change: could be simply reworded to "independence > of the signaling > path and the data path" > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 5.3.3 page 13 line 41 > Rationale/Explanation of issue: Typo error.âEURoethe network > nodes can locally > repair this type errorâEUR > Requested change: âEURoethe network nodes can locally repair > this type of errorâEUR > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 5.3.3 page 14 line 3 > Rationale/Explanation of issue: âEURoeService upgrade available: > If a previously > requested better service becomes available.âEUR > We might want to have this notification sent even if the > service was not > asked for it. The decision of sending or not the notification > is a policy > issue but we need to make sure that we can send the notification. > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 5.3.4 page 14 line 30 > Rationale/Explanation of issue: rewording - âEURoeto also get a > description of > what amount of resources a request is possibleâEUR > Requested change: âEURoeto also get a description of what amount > of available > requested resources are availableâEUR > > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 5.4.1 page 15 line 14 > Rationale/Explanation of issue: rewording - âEURnote that a > provider or that > particular services requestedâEUR > Requested change: âEURoenote that the provider of the particular > requested > serviceâEUR > > > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 3 > Section: 5.4.2 page 15 line 18 > Rationale/Explanation of issue: rewording - âEURSHOULD > possible to add and > remove local domain information" > Requested change: "It SHOULD be possible to add and remove > local domain > informationâEUR > > > Issue Name: ? > Submitter name: Cedric Aoun > Submitter email address: cedric.aoun@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 5.4.5 page 16 line 3 > Rationale/Explanation of issue: âEURoeHowever, the network MUST > NOT know that a > relationship between the grouped flows exists. There MUST NOT be any > transactional semantic associated with the grouping. It is > only meant for > optimization purposes and each reservation MUST be handled > separately from > each other.âEUR > > We need to have a MAY for having semantics to group flows > that are bundled. > I agree that the flows could have independent properties and > associated > resource reservations could still be taken down or processed > independently. > The usefulness of grouping these flows is primarily to tear > down all their > associated states at the same time without repeating the tear > down message > several time (i.e. command aggregation) and to minimize the > size of the > message data. > > Regards > Cedric > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Jan 23 03:46:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00394 for ; Thu, 23 Jan 2003 03:46:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N95Hh07163 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 04:05:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N958J07156; Thu, 23 Jan 2003 04:05:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N94pJ07121 for ; Thu, 23 Jan 2003 04:04:51 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00352 for ; Thu, 23 Jan 2003 03:45:53 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0N8pct01050 for ; Thu, 23 Jan 2003 10:51:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 10:49:18 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:49:18 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:49:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 23 Jan 2003 10:49:16 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcK+MeBu7CcoPPYsRgecFueB3p8UTwEila2Q To: , X-OriginalArrivalTime: 23 Jan 2003 08:49:17.0602 (UTC) FILETIME=[50434020:01C2C2BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0N94pJ07122 Subject: [NSIS] Issues 24 & 25 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Vlora, I agree with your comments. br, John > -----Original Message----- > From: ext Vlora Rexhepi (ELN) [mailto:Vlora.Rexhepi@eln.ericsson.se] > Sent: 17 January, 2003 16:07 > To: nsis@ietf.org > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Hi, > > Some minor comments on the draft: > > 1. In Section 5 on Requirements, it is written: > "This section defines more detailed requirements for > a signaling solution, respecting the framework,..." > framework is mentioned without any reference, so it might > be confusing. This is also the case for Section 5.1. 5.5.4 > and 10.2 under 2). > > 2. If we consider the 2 layer-model and the separation between > the transport protocol and the signaling application we might > want to re-formulate the requirement on "5.1.7 NSIS MUST be > application independent", such that it is clear that this is > the requirement about the higher than network layer applications. > My worry is related to the paragraph: > " > The requirement relates to the way the signaling interacts with > upper layer functions (users, applications, and QoS > administration), > and lower layer technologies. > " > as the signaling application layer functions can also be seen > as "upper layer functions", in which case we can't say that the > protocol is application independent. > I suggest to change this into: > "The requirement relates to the way the signaling interacts with > upper (than NSIS protocol) layer functions (users, applications, > and QoS administration), and lower (than NSIS) layer > technologies." > > Does this make sense? > > Regards, > Vlora > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Jan 23 03:51:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00493 for ; Thu, 23 Jan 2003 03:51:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N9AIj08192 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 04:10:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N9AAJ08157; Thu, 23 Jan 2003 04:10:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N999J08066 for ; Thu, 23 Jan 2003 04:09:09 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00441 for ; Thu, 23 Jan 2003 03:50:05 -0500 (EST) 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 h0N8qV019231 for ; Thu, 23 Jan 2003 10:52:31 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 10:53:31 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:53:31 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:53:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 23 Jan 2003 10:53:22 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcLCaVU7OLLNCx1aSVi5WtfMcPaHegAUxJOw To: , X-OriginalArrivalTime: 23 Jan 2003 08:53:31.0249 (UTC) FILETIME=[E772B610:01C2C2BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0N99cJ08107 Subject: [NSIS] Issues 8 - 14 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Kuntal, Comments in line: > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: 2 > Document Section: 2 > Rationale/Explanation of issue: Definition of RMF should also mention > about de-allocation > > Requested change: > Resource Management Function (RMF): An abstract concept, representing the > management of resources in a domain or a node. This includes admission > control and resource allocation/de-allocation. I think we need to say "This may include admission control and resource allocation/de-allocation." > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: > Document Section: 2 > Rationale/Explanation of issue: The current definition of > Provisioning > has unnecessary texts. For example it says LSP initiation in > MPLS is a > matter of provisioning. IMO, it's not entirely correct, LSPs can be > initiated by a LER based on it's internal logic which may be > configured > by suitable provisioning mechanism. > > Requested change: > Provisioning: the act of configuring an NE for allocating resources to a > flow or aggregate of flows. OK > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: > Document Section: 2 > Rationale/Explanation of issue: QoS technology definition > needs a bit of > correction, e.g. MPLS is not really a QoS technology, it is more used > for Traffic Engineering. > > Requested change: > QoS Technology: a generic term for a set of protocols, standards and > mechanisms that can be used within a QoS domain/subdomain to > manage the > QoS provided to flows or aggregates that traverse the domain. > An example > QoS technology is DiffServ. A QoS technology is associated > with certain > QoS provisioning techniques. OK > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: > Document Section: 2 > Rationale/Explanation of issue: The document states that NSIS is not > restricted to QoS signaling only, it also covers signaling > required for > other purposes such as ....not mentioned! > The requirements are based on the fact that a signal is > initiated from > an NSIS initiator for allocation of network resources. It > would be nice > to see some examples of non-QoS signals that require allocation of > network resources in the internet. We can try to add some. > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: > Document Section: 4.1 > Rationale/Explanation of issue: > " 6. NSIS assumes to operate with networks using standard ("normal") > L3 routing. Where "normal" is not specified more exactly > on purpose." > > this is very vague assumption. Not sure which routing scheme is > considered "normal". If some are normal then which ones are > "abnormal"? > > Requested change: > 6. NSIS assumes to operate with networks using standard L3 routing. OK > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: > Document Section: 5.2.1 > Rationale/Explanation of issue: > "5.2.1 The placement of NSIS Initiator, Forwarder, Responder > MUST be free" > > MUST be free of what? > > Requested change: > 5.2.1 The placement of NSIS Initiator, Forwarder, and > Responder anywhere > in the network MUST be allowed" How about: MUST be possible. > Issue Name: > Submitter name: Kuntal Chowdhury > Submitter email address: kuntal@iqmail.net > Date first submitted: 03-01-22 > Reference: - > Document: draft-ietf-nsis-req-06.txt > Comment type: E > Priority: > Document Section: 5.2.2 > Rationale/Explanation of issue: > "5.2.2 No constraint MUST be posed the signaling and NSIS > Forwarders to > be in the data path. " > > Need to rephrase this requirement. > > Requested change: > 5.2.2 There MUST not be any constraint to always require the NSIS > forwarder to be on the data path. I am not sure still about this requirement, does anyone have comments? Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 23 03:51:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00510 for ; Thu, 23 Jan 2003 03:51:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N9AMa08208 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 04:10:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N9ADJ08172; Thu, 23 Jan 2003 04:10:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N99hJ08118 for ; Thu, 23 Jan 2003 04:09:44 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00453 for ; Thu, 23 Jan 2003 03:50:44 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0N8uUt05201 for ; Thu, 23 Jan 2003 10:56:30 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 10:54:10 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:54:10 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:54:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Thu, 23 Jan 2003 10:54:09 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcLCantpFa8Y0eUYQhW73ma92YEUYgAUnbJA To: , X-OriginalArrivalTime: 23 Jan 2003 08:54:09.0857 (UTC) FILETIME=[FE75D310:01C2C2BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0N99iJ08119 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Kuntal, In principle, I like this generalization - what do others thik? br, John > -----Original Message----- > From: ext Kuntal Chowdhury [mailto:kuntal@iqmail.net] > Sent: 23 January, 2003 00:40 > To: nsis@ietf.org > Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Hi all, > There is a need to capture the scope of signaling (NSIS) in all 3G > wireless networks besides UMTS (e.g. need to cover cdma2000). > Otherwise, > it gives a false impression that, the NSIS requirements are UMTS > centric. I read the sections 10.2 and 10.3. There is a good > similarity > between 3GPP and 3GPP2 IP networks. The following is my attempt to > generalize the Figure: > > +--------+ > +----------| P-CSCF |-------> SIP signaling > / +--------+ > / SIP : > : +--------+ +----------------+ > : | Policy | | NSIS Forwarder | > : +--------+ +----------------+ > : : | > : : COPS | > : : | > +----+ +--------+ | > | UE |----------| Access |------------+ +----+ > +----+ | Gateway|----------------------| ER | > +--------+ +----+ > > I also agree with Louis that UE and/or the Access Gateway are > the most > natural candidates for NSIS initiator. Therefore I changed the above > figure to reflect that. There is also similarity between > UMTS/GPRS and > cdma2000 radio link QoS setup e.g. UMTS creates different > radio bearers > with different QoS needs and in cdma2000 the same is done > with multiple > service instances. If my suggestion is agreeable, then I will > be happy > to provide updated text for section 10.2 and 10.3. > > Regards, > Kuntal > > > > Hamer, Louis-Nicolas [CAR:DR13:EXCH] wrote: > > All, > > > > Issue Name: ? > > Submitter name: Louis-Nicolas Hamer > > Submitter email address: nhamer@nortelnetworks.com > > Date first submitted: 22/01/2003 > > Reference: none > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: 2 > > Section: 10.3 > > > > > > I have a few comments on section 10.3 UMTS access. > > Sorry for sending the late comments. > > > > Section 10.3 provides a good description of the UMTS access overall > > architecture for 3GPP release 5. But, it then speculates on how NSIS > > could fit into the 3GPP release 6, which is still not yet > defined by the > > way. > > Although, I agree NSIS could indeed have a place in 3GPP release 6, > > I can't agree with the way it is depicted in the draft currently. > > > > First, I am not convinced the PCF is the right place to > locate the NSIS > > Initiator. Why not consider the GGSN? Or the UE? > > Secondly, if it would be located in the PCF (or the GGSN for that > > matter), what > > would be the value-added? I personally think the important > section of > > the network > > where nsis signaling would be needed is at the access > level, not in the > > backbone network. > > So why originate NSIS after the access network? Value is > limited IMHO. > > > > I think having this example, as it is currently is not > acceptable. I > > propose > > we clean it up: > > -maybe we can agree on a more acceptable example > usage of nsis > > in UMTS access? > > -maybe we could instead list all of the possible > usages (instead > > of listing only one) > > -or strip out the example all together (I would > prefer not too). > > > > I am not sure who contributed this section, so I guess in order to > > achieve closure, it would be best > > if the contributors contacted me directly or through the > mailing list. > > Unless the chair (or someone else) has a better way forward. > > > > Cheers, > > > > L-N > > > > > > > > > -----Original Message----- > > > From: Anders.P.Bergsten@telia.se > [mailto:Anders.P.Bergsten@telia.se] > > > Sent: Wednesday, January 22, 2003 3:23 AM > > > To: john.loughney@nokia.com; nsis@ietf.org > > > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > > > > > > > John, > > > > > > here are some of my issues to the document. Sorry for posting > > > them late. > > > > > > Issue Name: > > > Submitter name: Anders Bergsten > > > Submitter email address: anders.p.bergsten@telia.se > > > Date first submitted: 03-01-20 > > > Reference: - > > > Document: draft-ietf-nsis-req-06.txt > > > Comment type: T > > > Priority: 2 > > > Document Section: 2, pg 3, last paragraph > > > Rationale/Explanation of issue: Definition of > > > Receiver-initiated signaling protocol seems flawed. The > > > definition states that the NSIS responder _initiates_ the > > > reservation on behalf of the receiver. According to the > > > definition of NSIS Responder, the NSIS Responder _responds_ > > > to NSIS messages. The NSIS Responder does not initiate a > > > message, hence, the definition is flawed. The definition of > > > Receiver-initiated signaling protocol should be defined by > > > where the NSIS Initiator is situated, not where the NSIS > > > Responder is situated. Therefore I propose a change to > > > something similar to the below. > > > > > > Requested change: > > > "Receiver-initiated signaling protocol: A receiver-initiated > > > signaling protocol is a protocol where the resources that the > > > signaling protocol should reserve is situated topologically > > > closer to the source than the NSIS Initiator is. This means > > > is that the resource management functions need to be > > > processed from the NSIS Initiator back towards the sender." > > > > > > > > > Issue Name: > > > Submitter name: Anders Bergsten > > > Submitter email address: anders.p.bergsten@telia.se > > > Date first submitted: 03-01-20 > > > Reference: - > > > Document: draft-ietf-nsis-req-06.txt > > > Comment type: T > > > Priority: 2 (?) > > > Document Section: 5.2.2 > > > Rationale/Explanation of issue: The section contain two > > > different and possibly opposing requirement. The title says > > > "No constraint MUST be posed on the signaling..." and page > > > 12, paragraph 5 says "... NSIS signaling used between those > > > virtual routers MUST follow the same path as the data". These > > > are two different requirements where the second actually pose > > > a contraint on the signaling path. > > > > > > Requested change: I personally prefer the second requirement > > > and propose to use only that. This requirement states that it > > > is some contraint on the path followed, which I think is > > > good. I think it also sufficiently covers both the "bandwidth > > > broker" and on-path alternatives to signaling. If people > > > still prefer the first, I would like the requirement to state > > > the following: "The only constraint on the signaling and NSIS > > > forwarders is that they follow the correct AS-path" (or some > > > equivilant term for AS-path). > > > > > > > > > Issue Name: > > > Submitter name: Anders Bergsten > > > Submitter email address: anders.p.bergsten@telia.se > > > Date first submitted: 03-01-13 > > > Reference: - > > > Document: draft-ietf-nsis-req-06.txt > > > Comment type: T > > > Priority: 2 > > > Document Section: 5.3.4 > > > Rationale/Explanation of issue: "A request for service MUST > > > be answered at least with a yes or no". This does not state > > > by whom the reply should be sent, neither is it clear enough > > > on how to be interpreted. The only thing this adds to me is > > > uncertainty - there is a risk that someone interpretes this > > > as "if I have sent a request I can expect a reply", ie "The > > > network MUST answer a request for service". This is > > > impossible to promise, since packets can be lost. > > > > > > Requested change: I prefer to keep the requirement in the > > > title and let that be the requirement. This requirement is > > > slightly different than what is written within the text, and > > > it talks about "success" of a service. If the requirement in > > > the text should be interpreted as "A NSIS responder MUST > > > answer a request for service", I want that stated. Thus, I > > > request one of two resolutions to this issue: > > > 1) Use only the requirement in the title (only a > > > success needs to be reported) and remove the "clarifying" > > > requirement in the text. > > > 2) Add information on WHO must answer to the request > > > (Something along, "The NSIS responder MUST reply with at > > > least a yes/no"). > > > > > > > > > Issue Name: > > > Submitter name: Anders Bergsten > > > Submitter email address: anders.p.bergsten@telia.se > > > Date first submitted: 03-01-20 > > > Reference: - > > > Document: draft-ietf-nsis-req-06.txt > > > Comment type: T > > > Priority: 2 > > > Document Section: 5.4.5 > > > Rationale/Explanation of issue: The requirement ("the network > > > MUST NOT know that a relationship between the group flows > > > exists", etc) in last paragraph of the section is a very hard > > > requirement to meet up with, I think. The interaction between > > > routing and state maintainance causes some problems here. I > > > start with a pure on-data-path signaling scenario. If a > > > router is to maintain state and get a group of state > > > requests, it must assume that they actually belong to him, > > > otherwise it does not make sense. This requires either that > > > the previous node does group flows together that have a > > > relation with next-hop node or that the node can force > > > relationship onto a group of flows (this method is used by > > > MPLS), where we control the path. If we do not allow for "the > > > network" to know relationships between flows, a node cannot > > > assume that the resource belongs to him and need to have a > > > method to find the right owner of the flow - which may be > > > harder to solve than allowing a node to know a r! elationship > > > between flows. > > > Requested change: Not sure how to resolve the issue, > > > unfortunately. The best thing would be to remove the > > > paragraph and leave only the requirement on that NSIS MAY > > > group flows. > > > > > > > > > Then I have a general comment about the use of MUST/SHOULD... > > > I feel there are too many requirements that are MUSTs, and I > > > am not sure that it is understood how these requirements is > > > met up by a protocol (ie what is the cost for having to > > > implement this). For example, what is the implications of > > > this requirement "State MUST be addressed independent of flow > > > identification"? I would request that the MUSTs/SHOULDs etc > > > is not to be interpreted as in RFC2119 as I believe that > > > would be hard to find a protocol that match all the MUSTs. I > > > would request to use must/should/may instead so that > > > subsequent work do not interprete them as "hard" > > > requirements, but rather as indications of requirement. > > > > > > Anders > > > > > > > -----Original Message----- > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > Sent: den 8 januari 2003 02:04 > > > > To: nsis@ietf.org > > > > Cc: mankin@psg.com > > > > Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > > > > > > > > > > Dear all, > > > > > > > > Marcus Brunner has submitted an updated version of the > > > > requirements document. He feels that he has addressed all of > > > > the remaining open issues, and we feel that it is ready for > > > > WG last call. There are a number of editorial nits, but > > > > otherwise the document is in good shape. > > > > > > > > Therefore, I am asking the working group to review the > > > > document and submit any issues found. > > > > > > > > The working group last call will last until Wednesday January > > > > 22nd, 4 PM Pacific Coast Time. > > > > > > > > I will send a subsequent mail outlining the procedure for > > > > submitting issues. > > > > > > > > thanks, > > > > John > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 23 03:59:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00653 for ; Thu, 23 Jan 2003 03:59:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N9HRG08574 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 04:17:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N9HFJ08566; Thu, 23 Jan 2003 04:17:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N9GoJ08532 for ; Thu, 23 Jan 2003 04:16:50 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00635 for ; Thu, 23 Jan 2003 03:57:51 -0500 (EST) From: maarten.buchli@alcatel.be Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id h0N91HG13318 for ; Thu, 23 Jan 2003 10:01:17 +0100 Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt To: nsis@ietf.org Date: Thu, 23 Jan 2003 10:01:15 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/23/2003 10:01:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, I have been contributing on the section on UMTS. Looking at it again I agree it is indeed a somewhat limited example. Therefore, I propose to all possible usages. In that case I think we should mention: 1. NSIS initiator in the UE 2. NSIS initiator in the Access gateway 3. NSIS initiator in the PCF Also, I agree also that we should generalize the example beyond UMTS, e.g. 3G wireless in general. Any input on this text would be welcomed. What do you think? regards, Maarten Kuntal Chowdhury @ietf.org on 22/01/2003 23:39:39 Sent by: nsis-admin@ietf.org To: nsis@ietf.org cc: Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Hi all, There is a need to capture the scope of signaling (NSIS) in all 3G wireless networks besides UMTS (e.g. need to cover cdma2000). Otherwise, it gives a false impression that, the NSIS requirements are UMTS centric. I read the sections 10.2 and 10.3. There is a good similarity between 3GPP and 3GPP2 IP networks. The following is my attempt to generalize the Figure: +--------+ +----------| P-CSCF |-------> SIP signaling / +--------+ / SIP : : +--------+ +----------------+ : | Policy | | NSIS Forwarder | : +--------+ +----------------+ : : | : : COPS | : : | +----+ +--------+ | | UE |----------| Access |------------+ +----+ +----+ | Gateway|----------------------| ER | +--------+ +----+ I also agree with Louis that UE and/or the Access Gateway are the most natural candidates for NSIS initiator. Therefore I changed the above figure to reflect that. There is also similarity between UMTS/GPRS and cdma2000 radio link QoS setup e.g. UMTS creates different radio bearers with different QoS needs and in cdma2000 the same is done with multiple service instances. If my suggestion is agreeable, then I will be happy to provide updated text for section 10.2 and 10.3. Regards, Kuntal Hamer, Louis-Nicolas [CAR:DR13:EXCH] wrote: > All, > > Issue Name: ? > Submitter name: Louis-Nicolas Hamer > Submitter email address: nhamer@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 10.3 > > > I have a few comments on section 10.3 UMTS access. > Sorry for sending the late comments. > > Section 10.3 provides a good description of the UMTS access overall > architecture for 3GPP release 5. But, it then speculates on how NSIS > could fit into the 3GPP release 6, which is still not yet defined by the > way. > Although, I agree NSIS could indeed have a place in 3GPP release 6, > I can't agree with the way it is depicted in the draft currently. > > First, I am not convinced the PCF is the right place to locate the NSIS > Initiator. Why not consider the GGSN? Or the UE? > Secondly, if it would be located in the PCF (or the GGSN for that > matter), what > would be the value-added? I personally think the important section of > the network > where nsis signaling would be needed is at the access level, not in the > backbone network. > So why originate NSIS after the access network? Value is limited IMHO. > > I think having this example, as it is currently is not acceptable. I > propose > we clean it up: > -maybe we can agree on a more acceptable example usage of nsis > in UMTS access? > -maybe we could instead list all of the possible usages (instead > of listing only one) > -or strip out the example all together (I would prefer not too). > > I am not sure who contributed this section, so I guess in order to > achieve closure, it would be best > if the contributors contacted me directly or through the mailing list. > Unless the chair (or someone else) has a better way forward. > > Cheers, > > L-N > > > > > -----Original Message----- > > From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia.se] > > Sent: Wednesday, January 22, 2003 3:23 AM > > To: john.loughney@nokia.com; nsis@ietf.org > > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > > > > John, > > > > here are some of my issues to the document. Sorry for posting > > them late. > > > > Issue Name: > > Submitter name: Anders Bergsten > > Submitter email address: anders.p.bergsten@telia.se > > Date first submitted: 03-01-20 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: 2 > > Document Section: 2, pg 3, last paragraph > > Rationale/Explanation of issue: Definition of > > Receiver-initiated signaling protocol seems flawed. The > > definition states that the NSIS responder _initiates_ the > > reservation on behalf of the receiver. According to the > > definition of NSIS Responder, the NSIS Responder _responds_ > > to NSIS messages. The NSIS Responder does not initiate a > > message, hence, the definition is flawed. The definition of > > Receiver-initiated signaling protocol should be defined by > > where the NSIS Initiator is situated, not where the NSIS > > Responder is situated. Therefore I propose a change to > > something similar to the below. > > > > Requested change: > > "Receiver-initiated signaling protocol: A receiver-initiated > > signaling protocol is a protocol where the resources that the > > signaling protocol should reserve is situated topologically > > closer to the source than the NSIS Initiator is. This means > > is that the resource management functions need to be > > processed from the NSIS Initiator back towards the sender." > > > > > > Issue Name: > > Submitter name: Anders Bergsten > > Submitter email address: anders.p.bergsten@telia.se > > Date first submitted: 03-01-20 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: 2 (?) > > Document Section: 5.2.2 > > Rationale/Explanation of issue: The section contain two > > different and possibly opposing requirement. The title says > > "No constraint MUST be posed on the signaling..." and page > > 12, paragraph 5 says "... NSIS signaling used between those > > virtual routers MUST follow the same path as the data". These > > are two different requirements where the second actually pose > > a contraint on the signaling path. > > > > Requested change: I personally prefer the second requirement > > and propose to use only that. This requirement states that it > > is some contraint on the path followed, which I think is > > good. I think it also sufficiently covers both the "bandwidth > > broker" and on-path alternatives to signaling. If people > > still prefer the first, I would like the requirement to state > > the following: "The only constraint on the signaling and NSIS > > forwarders is that they follow the correct AS-path" (or some > > equivilant term for AS-path). > > > > > > Issue Name: > > Submitter name: Anders Bergsten > > Submitter email address: anders.p.bergsten@telia.se > > Date first submitted: 03-01-13 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: 2 > > Document Section: 5.3.4 > > Rationale/Explanation of issue: "A request for service MUST > > be answered at least with a yes or no". This does not state > > by whom the reply should be sent, neither is it clear enough > > on how to be interpreted. The only thing this adds to me is > > uncertainty - there is a risk that someone interpretes this > > as "if I have sent a request I can expect a reply", ie "The > > network MUST answer a request for service". This is > > impossible to promise, since packets can be lost. > > > > Requested change: I prefer to keep the requirement in the > > title and let that be the requirement. This requirement is > > slightly different than what is written within the text, and > > it talks about "success" of a service. If the requirement in > > the text should be interpreted as "A NSIS responder MUST > > answer a request for service", I want that stated. Thus, I > > request one of two resolutions to this issue: > > 1) Use only the requirement in the title (only a > > success needs to be reported) and remove the "clarifying" > > requirement in the text. > > 2) Add information on WHO must answer to the request > > (Something along, "The NSIS responder MUST reply with at > > least a yes/no"). > > > > > > Issue Name: > > Submitter name: Anders Bergsten > > Submitter email address: anders.p.bergsten@telia.se > > Date first submitted: 03-01-20 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: 2 > > Document Section: 5.4.5 > > Rationale/Explanation of issue: The requirement ("the network > > MUST NOT know that a relationship between the group flows > > exists", etc) in last paragraph of the section is a very hard > > requirement to meet up with, I think. The interaction between > > routing and state maintainance causes some problems here. I > > start with a pure on-data-path signaling scenario. If a > > router is to maintain state and get a group of state > > requests, it must assume that they actually belong to him, > > otherwise it does not make sense. This requires either that > > the previous node does group flows together that have a > > relation with next-hop node or that the node can force > > relationship onto a group of flows (this method is used by > > MPLS), where we control the path. If we do not allow for "the > > network" to know relationships between flows, a node cannot > > assume that the resource belongs to him and need to have a > > method to find the right owner of the flow - which may be > > harder to solve than allowing a node to know a r! elationship > > between flows. > > Requested change: Not sure how to resolve the issue, > > unfortunately. The best thing would be to remove the > > paragraph and leave only the requirement on that NSIS MAY > > group flows. > > > > > > Then I have a general comment about the use of MUST/SHOULD... > > I feel there are too many requirements that are MUSTs, and I > > am not sure that it is understood how these requirements is > > met up by a protocol (ie what is the cost for having to > > implement this). For example, what is the implications of > > this requirement "State MUST be addressed independent of flow > > identification"? I would request that the MUSTs/SHOULDs etc > > is not to be interpreted as in RFC2119 as I believe that > > would be hard to find a protocol that match all the MUSTs. I > > would request to use must/should/may instead so that > > subsequent work do not interprete them as "hard" > > requirements, but rather as indications of requirement. > > > > Anders > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: den 8 januari 2003 02:04 > > > To: nsis@ietf.org > > > Cc: mankin@psg.com > > > Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > > > > > > > Dear all, > > > > > > Marcus Brunner has submitted an updated version of the > > > requirements document. He feels that he has addressed all of > > > the remaining open issues, and we feel that it is ready for > > > WG last call. There are a number of editorial nits, but > > > otherwise the document is in good shape. > > > > > > Therefore, I am asking the working group to review the > > > document and submit any issues found. > > > > > > The working group last call will last until Wednesday January > > > 22nd, 4 PM Pacific Coast Time. > > > > > > I will send a subsequent mail outlining the procedure for > > > submitting issues. > > > > > > thanks, > > > John > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 23 11:04:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11334 for ; Thu, 23 Jan 2003 11:04:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NGN8c04247 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 11:23:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NGMnJ04220; Thu, 23 Jan 2003 11:22:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NEr0J30175 for ; Thu, 23 Jan 2003 09:53:00 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08664 for ; Thu, 23 Jan 2003 09:33:51 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0NEb6E21702; Thu, 23 Jan 2003 09:37:07 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 09:36:02 -0500 Message-ID: From: "Louis-Nicolas Hamer" To: "'maarten.buchli@alcatel.be'" , nsis@ietf.org Cc: "'kuntal@iqmail.net'" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Thu, 23 Jan 2003 09:36:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C2EC.C07727A0" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C2EC.C07727A0 Content-Type: text/plain Maarten, Sounds like we are in agreement. I also agree with the generalizations to cover cdma2000 from Kuntal. I will try to sync up with Kuntal to generate some proposed text to generalize the example. Cheers, L-N > -----Original Message----- > From: maarten.buchli@alcatel.be [mailto:maarten.buchli@alcatel.be] > Sent: Thursday, January 23, 2003 4:01 AM > To: nsis@ietf.org > Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Hi all, > > I have been contributing on the section on UMTS. Looking at > it again I agree it is indeed a somewhat limited example. > Therefore, I propose to all possible usages. In that case I > think we should mention: 1. NSIS initiator in the UE 2. NSIS > initiator in the Access gateway 3. NSIS initiator in the PCF > > Also, I agree also that we should generalize the example > beyond UMTS, e.g. 3G wireless in general. Any input on this > text would be welcomed. > > What do you think? > > regards, > Maarten > > > > > > > Kuntal Chowdhury @ietf.org on 22/01/2003 23:39:39 > > Sent by: nsis-admin@ietf.org > > > To: nsis@ietf.org > cc: > Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Hi all, > There is a need to capture the scope of signaling (NSIS) in > all 3G wireless networks besides UMTS (e.g. need to cover > cdma2000). Otherwise, it gives a false impression that, the > NSIS requirements are UMTS centric. I read the sections 10.2 > and 10.3. There is a good similarity between 3GPP and 3GPP2 > IP networks. The following is my attempt to generalize the Figure: > > +--------+ > +----------| P-CSCF |-------> SIP signaling > / +--------+ > / SIP : > : +--------+ +----------------+ > : | Policy | | NSIS Forwarder | > : +--------+ +----------------+ > : : | > : : COPS | > : : | > +----+ +--------+ | > | UE |----------| Access |------------+ +----+ > +----+ | Gateway|----------------------| ER | > +--------+ +----+ > > I also agree with Louis that UE and/or the Access Gateway are > the most natural candidates for NSIS initiator. Therefore I > changed the above figure to reflect that. There is also > similarity between UMTS/GPRS and cdma2000 radio link QoS > setup e.g. UMTS creates different radio bearers with > different QoS needs and in cdma2000 the same is done with > multiple service instances. If my suggestion is agreeable, > then I will be happy to provide updated text for section 10.2 > and 10.3. > > Regards, > Kuntal > > > > Hamer, Louis-Nicolas [CAR:DR13:EXCH] wrote: > > All, > > > > Issue Name: ? > > Submitter name: Louis-Nicolas Hamer > > Submitter email address: nhamer@nortelnetworks.com > > Date first submitted: 22/01/2003 > > Reference: none > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: 2 > > Section: 10.3 > > > > > > I have a few comments on section 10.3 UMTS access. > > Sorry for sending the late comments. > > > > Section 10.3 provides a good description of the UMTS access overall > > architecture for 3GPP release 5. But, it then speculates on > how NSIS > > could fit into the 3GPP release 6, which is still not yet > defined by > > the way. Although, I agree NSIS could indeed have a place in 3GPP > > release 6, I can't agree with the way it is depicted in the draft > > currently. > > > > First, I am not convinced the PCF is the right place to locate the > > NSIS Initiator. Why not consider the GGSN? Or the UE? > Secondly, if it > > would be located in the PCF (or the GGSN for that matter), what > > would be the value-added? I personally think the important > section of > > the network > > where nsis signaling would be needed is at the access > level, not in the > > backbone network. > > So why originate NSIS after the access network? Value is > limited IMHO. > > > > I think having this example, as it is currently is not > acceptable. I > > propose we clean it up: > > -maybe we can agree on a more acceptable example > usage of nsis > > in UMTS access? > > -maybe we could instead list all of the possible > usages (instead > > of listing only one) > > -or strip out the example all together (I would > prefer not too). > > > > I am not sure who contributed this section, so I guess in order to > > achieve closure, it would be best if the contributors contacted me > > directly or through the mailing list. Unless the chair (or someone > > else) has a better way forward. > > > > Cheers, > > > > L-N > > > > > > > > > -----Original Message----- > > > From: Anders.P.Bergsten@telia.se > > [mailto:Anders.P.Bergsten@telia.se] > > > Sent: Wednesday, January 22, 2003 3:23 AM > > > To: john.loughney@nokia.com; nsis@ietf.org > > > Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > > > > > > > John, > > > > > > here are some of my issues to the document. Sorry for posting > > > them late. > > > > > > Issue Name: > > > Submitter name: Anders Bergsten > > > Submitter email address: anders.p.bergsten@telia.se > > > Date first submitted: 03-01-20 > > > Reference: - > > > Document: draft-ietf-nsis-req-06.txt > > > Comment type: T > > > Priority: 2 > > > Document Section: 2, pg 3, last paragraph > > > Rationale/Explanation of issue: Definition of > > > Receiver-initiated signaling protocol seems flawed. The > > > definition states that the NSIS responder _initiates_ the > > > reservation on behalf of the receiver. According to the > > > definition of NSIS Responder, the NSIS Responder _responds_ > > > to NSIS messages. The NSIS Responder does not initiate a > > > message, hence, the definition is flawed. The definition of > > > Receiver-initiated signaling protocol should be defined by > > > where the NSIS Initiator is situated, not where the NSIS > > > Responder is situated. Therefore I propose a change to > > > something similar to the below. > > > > > > Requested change: > > > "Receiver-initiated signaling protocol: A receiver-initiated > > > signaling protocol is a protocol where the resources that the > > > signaling protocol should reserve is situated topologically > > > closer to the source than the NSIS Initiator is. This means > > > is that the resource management functions need to be > > > processed from the NSIS Initiator back towards the sender." > > > > > > > > > Issue Name: > > > Submitter name: Anders Bergsten > > > Submitter email address: anders.p.bergsten@telia.se > > > Date first submitted: 03-01-20 > > > Reference: - > > > Document: draft-ietf-nsis-req-06.txt > > > Comment type: T > > > Priority: 2 (?) > > > Document Section: 5.2.2 > > > Rationale/Explanation of issue: The section contain two > > > different and possibly opposing requirement. The title says > > > "No constraint MUST be posed on the signaling..." and page > > > 12, paragraph 5 says "... NSIS signaling used between those > > > virtual routers MUST follow the same path as the data". These > > > are two different requirements where the second actually pose > > > a contraint on the signaling path. > > > > > > Requested change: I personally prefer the second requirement > > > and propose to use only that. This requirement states that it > > > is some contraint on the path followed, which I think is > > > good. I think it also sufficiently covers both the "bandwidth > > > broker" and on-path alternatives to signaling. If people > > > still prefer the first, I would like the requirement to state > > > the following: "The only constraint on the signaling and NSIS > > > forwarders is that they follow the correct AS-path" (or some > > > equivilant term for AS-path). > > > > > > > > > Issue Name: > > > Submitter name: Anders Bergsten > > > Submitter email address: anders.p.bergsten@telia.se > > > Date first submitted: 03-01-13 > > > Reference: - > > > Document: draft-ietf-nsis-req-06.txt > > > Comment type: T > > > Priority: 2 > > > Document Section: 5.3.4 > > > Rationale/Explanation of issue: "A request for service MUST > > > be answered at least with a yes or no". This does not state > > > by whom the reply should be sent, neither is it clear enough > > > on how to be interpreted. The only thing this adds to me is > > > uncertainty - there is a risk that someone interpretes this > > > as "if I have sent a request I can expect a reply", ie "The > > > network MUST answer a request for service". This is > > > impossible to promise, since packets can be lost. > > > > > > Requested change: I prefer to keep the requirement in the > > > title and let that be the requirement. This requirement is > > > slightly different than what is written within the text, and > > > it talks about "success" of a service. If the requirement in > > > the text should be interpreted as "A NSIS responder MUST > > > answer a request for service", I want that stated. Thus, I > > > request one of two resolutions to this issue: > > > 1) Use only the requirement in the title (only a > > > success needs to be reported) and remove the "clarifying" > > > requirement in the text. > > > 2) Add information on WHO must answer to the request > > > (Something along, "The NSIS responder MUST reply with at > > > least a yes/no"). > > > > > > > > > Issue Name: > > > Submitter name: Anders Bergsten > > > Submitter email address: anders.p.bergsten@telia.se > > > Date first submitted: 03-01-20 > > > Reference: - > > > Document: draft-ietf-nsis-req-06.txt > > > Comment type: T > > > Priority: 2 > > > Document Section: 5.4.5 > > > Rationale/Explanation of issue: The requirement ("the network > > > MUST NOT know that a relationship between the group flows > > > exists", etc) in last paragraph of the section is a very hard > > > requirement to meet up with, I think. The interaction between > > > routing and state maintainance causes some problems here. I > > > start with a pure on-data-path signaling scenario. If a > > > router is to maintain state and get a group of state > > > requests, it must assume that they actually belong to him, > > > otherwise it does not make sense. This requires either that > > > the previous node does group flows together that have a > > > relation with next-hop node or that the node can force > > > relationship onto a group of flows (this method is used by > > > MPLS), where we control the path. If we do not allow for "the > > > network" to know relationships between flows, a node cannot > > > assume that the resource belongs to him and need to have a > > > method to find the right owner of the flow - which may be > > > harder to solve than allowing a node to know a r! elationship > > > between flows. > > > Requested change: Not sure how to resolve the issue, > > > unfortunately. The best thing would be to remove the > > > paragraph and leave only the requirement on that NSIS MAY > > > group flows. > > > > > > > > > Then I have a general comment about the use of MUST/SHOULD... > > > I feel there are too many requirements that are MUSTs, and I > > > am not sure that it is understood how these requirements is > > > met up by a protocol (ie what is the cost for having to > > > implement this). For example, what is the implications of > > > this requirement "State MUST be addressed independent of flow > > > identification"? I would request that the MUSTs/SHOULDs etc > > > is not to be interpreted as in RFC2119 as I believe that > > > would be hard to find a protocol that match all the MUSTs. I > > > would request to use must/should/may instead so that > > > subsequent work do not interprete them as "hard" > > > requirements, but rather as indications of requirement. > > > > > > Anders > > > > > > > -----Original Message----- > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > Sent: den 8 januari 2003 02:04 > > > > To: nsis@ietf.org > > > > Cc: mankin@psg.com > > > > Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > > > > > > > > > > Dear all, > > > > > > > > Marcus Brunner has submitted an updated version of the > > > > requirements document. He feels that he has addressed all of > > > > the remaining open issues, and we feel that it is ready for > > > > WG last call. There are a number of editorial nits, but > > > > otherwise the document is in good shape. > > > > > > > > Therefore, I am asking the working group to review the > > > > document and submit any issues found. > > > > > > > > The working group last call will last until Wednesday January > > > > 22nd, 4 PM Pacific Coast Time. > > > > > > > > I will send a subsequent mail outlining the procedure for > > > > submitting issues. > > > > > > > > thanks, > > > > John > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C2C2EC.C07727A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt

Maarten,

Sounds like we are in agreement. I also agree with = the generalizations to cover cdma2000 from Kuntal.
I will try to sync up with Kuntal to generate
some proposed text to generalize the example.


Cheers,

L-N

> -----Original Message-----
> From: maarten.buchli@alcatel.be [mailto:maarten.buchli@alcatel.= be]
> Sent: Thursday, January 23, 2003 4:01 AM
> To: nsis@ietf.org
> Subject: Re: [NSIS] WG Last Call on = draft-ietf-nsis-req-06.txt
>
>
> Hi all,
>
> I have been contributing on the section on = UMTS. Looking at
> it again I agree it is indeed a somewhat = limited example.
> Therefore, I propose to all possible usages. In = that case I
> think we should mention: 1. NSIS initiator in = the UE 2. NSIS
> initiator in the Access gateway 3. NSIS = initiator in the PCF
>
> Also, I agree also that we should generalize = the example
> beyond UMTS, e.g. 3G wireless in general. Any = input on this
> text would be welcomed.
>
> What do you think?
>
> regards,
> Maarten
>
>
>
>
>
>
> Kuntal Chowdhury = <kuntal@iqmail.net>@ietf.org on 22/01/2003 23:39:39
>
> Sent by:    = nsis-admin@ietf.org
>
>
> To:    nsis@ietf.org
> cc:
> Subject:    Re: [NSIS] WG Last = Call on draft-ietf-nsis-req-06.txt
>
>
> Hi all,
> There is a need to capture the scope of = signaling (NSIS) in
> all 3G wireless networks besides UMTS (e.g. = need to cover
> cdma2000). Otherwise, it gives a false = impression that, the
> NSIS requirements are UMTS centric. I read the = sections 10.2
> and 10.3. There is a good similarity between = 3GPP and 3GPP2
> IP networks. The following is my attempt to = generalize the Figure:
>
>          = ;            = ;       +--------+
>          = ;        +----------| P-CSCF = |-------> SIP signaling
>          = ;       = /           = +--------+
>          = ;      / = SIP            = :
>          = ;     = :            = ; +--------+         = +----------------+
>          = ;     = :            = ; | Policy |         | NSIS = Forwarder |
>          = ;     = :            = ; +--------+         = +----------------+
>          = ;     = :            = ;     = :            = ;     |
>          = ;     = :            = ;     : = COPS            = |
>          = ;     = :            = ;     = :            = |
>          = ;   = +----+          = +--------+          &n= bsp; |
>          = ;   | UE |----------| Access = |------------+      +----+
>          = ;   = +----+          | = Gateway|----------------------| ER |
>          = ;            = ;       = +--------+          &n= bsp;        +----+
>
> I also agree with Louis that UE and/or the = Access Gateway are
> the most natural candidates for NSIS initiator. = Therefore I
> changed the above figure to reflect that. There = is also
> similarity between UMTS/GPRS and cdma2000 radio = link QoS
> setup e.g. UMTS creates different radio bearers = with
> different QoS needs and in cdma2000 the same is = done with
> multiple service instances. If my suggestion is = agreeable,
> then I will be happy to provide updated text = for section 10.2
> and 10.3.
>
> Regards,
> Kuntal
>
>
>
> Hamer, Louis-Nicolas [CAR:DR13:EXCH] = wrote:
> > All,
> >
> > Issue Name: ?
> > Submitter name: Louis-Nicolas Hamer
> > Submitter email address: = nhamer@nortelnetworks.com
> > Date first submitted: 22/01/2003
> > Reference: none
> > Document: = draft-ietf-nsis-req-06.txt
> > Comment type: T
> > Priority:  2
> > Section: 10.3
> >
> >
> > I have a few comments on section 10.3 UMTS = access.
> > Sorry for sending the late = comments.
> >
> > Section 10.3 provides a good description = of the UMTS access overall
> > architecture for 3GPP release 5. But, it = then speculates on
> how NSIS
> > could fit into the 3GPP release 6, which = is still not yet
> defined by
> > the way. Although, I agree NSIS could = indeed have a place in 3GPP
> > release 6, I can't agree with the way it = is depicted in the draft
> > currently.
> >
> > First, I am not convinced the PCF is the = right place to locate the
> > NSIS Initiator. Why not consider the GGSN? = Or the UE?
> Secondly, if it
> > would be located in the PCF (or the GGSN = for that matter), what
> > would be the value-added? I personally = think the important
> section of
> > the network
> > where nsis signaling would be needed is at = the access
> level, not in the
> > backbone network.
> > So why originate NSIS after the access = network? Value is
> limited IMHO.
> >
> > I think having this example, as it is = currently is not
> acceptable. I
> > propose we clean it up:
> = >         -maybe we can = agree on a more acceptable example
> usage of nsis
> > in UMTS access?
> = >         -maybe we could = instead list all of the possible
> usages (instead
> > of listing only one)
> = >         -or strip out the = example all together (I would
> prefer not too).
> >
> > I am not sure who contributed this = section, so I guess in order to
> > achieve closure, it would be best if the = contributors contacted me
> > directly or through the mailing list. = Unless the chair (or someone
> > else) has a better way forward.
> >
> > Cheers,
> >
> > L-N
> >
> >
> >
> >  > -----Original = Message-----
> >  > From: = Anders.P.Bergsten@telia.se
> > [mailto:Anders.P.Bergsten@teli= a.se]
> >  > Sent: Wednesday, January 22, = 2003 3:23 AM
> >  > To: john.loughney@nokia.com; = nsis@ietf.org
> >  > Subject: RE: [NSIS] WG Last = Call on draft-ietf-nsis-req-06.txt
> >  >
> >  >
> >  > John,
> >  >
> >  > here are some of my issues to = the document. Sorry for posting
> >  > them late.
> >  >
> >  > Issue Name:
> >  > Submitter name: Anders = Bergsten
> >  > Submitter email address: = anders.p.bergsten@telia.se
> >  > Date first submitted: = 03-01-20
> >  > Reference: -
> >  > Document: = draft-ietf-nsis-req-06.txt
> >  > Comment type: T
> >  > Priority:  2
> >  > Document Section: 2, pg 3, last = paragraph
> >  > Rationale/Explanation of issue: = Definition of
> >  > Receiver-initiated signaling = protocol seems flawed. The
> >  > definition states that the NSIS = responder _initiates_ the
> >  > reservation on behalf of the = receiver. According to the
> >  > definition of NSIS Responder, = the NSIS Responder _responds_
> >  > to NSIS messages. The NSIS = Responder does not initiate a
> >  > message, hence, the definition = is flawed. The definition of
> >  > Receiver-initiated signaling = protocol should be defined by
> >  > where the NSIS Initiator is = situated, not where the NSIS
> >  > Responder is situated. = Therefore I propose a change to
> >  > something similar to the = below.
> >  >
> >  > Requested change:
> >  > "Receiver-initiated = signaling protocol: A receiver-initiated
> >  > signaling protocol is a = protocol where the resources that the
> >  > signaling protocol should = reserve is situated topologically
> >  > closer to the source than the = NSIS Initiator is. This means
> >  > is that the resource management = functions need to be
> >  > processed from the NSIS = Initiator back towards the sender."
> >  >
> >  >
> >  > Issue Name:
> >  > Submitter name: Anders = Bergsten
> >  > Submitter email address: = anders.p.bergsten@telia.se
> >  > Date first submitted: = 03-01-20
> >  > Reference: -
> >  > Document: = draft-ietf-nsis-req-06.txt
> >  > Comment type: T
> >  > Priority:  2 (?)
> >  > Document Section: 5.2.2
> >  > Rationale/Explanation of issue: = The section contain two
> >  > different and possibly opposing = requirement. The title says
> >  > "No constraint MUST be = posed on the signaling..." and page
> >  > 12, paragraph 5 says "... = NSIS signaling used between those
> >  > virtual routers MUST follow the = same path as the data". These
> >  > are two different requirements = where the second actually pose
> >  > a contraint on the signaling = path.
> >  >
> >  > Requested change: I personally = prefer the second requirement
> >  > and propose to use only that. = This requirement states that it
> >  > is some contraint on the path = followed, which I think is
> >  > good. I think it also = sufficiently covers both the "bandwidth
> >  > broker" and on-path = alternatives to signaling. If people
> >  > still prefer the first, I would = like the requirement to state
> >  > the following: "The only = constraint on the signaling and NSIS
> >  > forwarders is that they follow = the correct AS-path" (or some
> >  > equivilant term for = AS-path).
> >  >
> >  >
> >  > Issue Name:
> >  > Submitter name: Anders = Bergsten
> >  > Submitter email address: = anders.p.bergsten@telia.se
> >  > Date first submitted: = 03-01-13
> >  > Reference: -
> >  > Document: = draft-ietf-nsis-req-06.txt
> >  > Comment type: T
> >  > Priority:  2
> >  > Document Section: 5.3.4
> >  > Rationale/Explanation of issue: = "A request for service MUST
> >  > be answered at least with a yes = or no". This does not state
> >  > by whom the reply should be = sent, neither is it clear enough
> >  > on how to be interpreted. The = only thing this adds to me is
> >  > uncertainty - there is a risk = that someone interpretes this
> >  > as "if I have sent a = request I can expect a reply", ie "The
> >  > network MUST answer a request = for service". This is
> >  > impossible to promise, since = packets can be lost.
> >  >
> >  > Requested change: I prefer to = keep the requirement in the
> >  > title and let that be the = requirement. This requirement is
> >  > slightly different than what is = written within the text, and
> >  > it talks about = "success" of a service. If the requirement in
> >  > the text should be interpreted = as "A NSIS responder MUST
> >  > answer a request for = service", I want that stated. Thus, I
> >  > request one of two resolutions = to this issue:
> >  = >       1) Use only the requirement in = the title (only a
> >  > success needs to be reported) = and remove the "clarifying"
> >  > requirement in the text.
> >  = >       2) Add information on WHO must = answer to the request
> >  > (Something along, "The = NSIS responder MUST reply with at
> >  > least a yes/no").
> >  >
> >  >
> >  > Issue Name:
> >  > Submitter name: Anders = Bergsten
> >  > Submitter email address: = anders.p.bergsten@telia.se
> >  > Date first submitted: = 03-01-20
> >  > Reference: -
> >  > Document: = draft-ietf-nsis-req-06.txt
> >  > Comment type: T
> >  > Priority:  2
> >  > Document Section: 5.4.5
> >  > Rationale/Explanation of issue: = The requirement ("the network
> >  > MUST NOT know that a = relationship between the group flows
> >  > exists", etc) in last = paragraph of the section is a very hard
> >  > requirement to meet up with, I = think. The interaction between
> >  > routing and state maintainance = causes some problems here. I
> >  > start with a pure on-data-path = signaling scenario. If a
> >  > router is to maintain state and = get a group of state
> >  > requests, it must assume that = they actually belong to him,
> >  > otherwise it does not make = sense. This requires either that
> >  > the previous node does group = flows together that have a
> >  > relation with next-hop node or = that the node can force
> >  > relationship onto a group of = flows (this method is used by
> >  > MPLS), where we control the = path. If we do not allow for "the
> >  > network" to know = relationships between flows, a node cannot
> >  > assume that the resource = belongs to him and need to have a
> >  > method to find the right owner = of the flow - which may be
> >  > harder to solve than allowing a = node to know a r! elationship
> >  > between flows.
> >  > Requested change: Not sure how = to resolve the issue,
> >  > unfortunately. The best thing = would be to remove the
> >  > paragraph and leave only the = requirement on that NSIS MAY
> >  > group flows.
> >  >
> >  >
> >  > Then I have a general comment = about the use of MUST/SHOULD...
> >  > I feel there are too many = requirements that are MUSTs, and I
> >  > am not sure that it is = understood how these requirements is
> >  > met up by a protocol (ie what = is the cost for having to
> >  > implement this). For example, = what is the implications of
> >  > this requirement "State = MUST be addressed independent of flow
> >  > identification"? I would = request that the MUSTs/SHOULDs etc
> >  > is not to be interpreted as in = RFC2119 as I believe that
> >  > would be hard to find a = protocol that match all the MUSTs. I
> >  > would request to use = must/should/may instead so that
> >  > subsequent work do not = interprete them as "hard"
> >  > requirements, but rather as = indications of requirement.
> >  >
> >  > Anders
> >  >
> >  > > -----Original = Message-----
> >  > > From: = john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> >  > > Sent: den 8 januari 2003 = 02:04
> >  > > To: nsis@ietf.org
> >  > > Cc: mankin@psg.com
> >  > > Subject: [NSIS] WG Last = Call on draft-ietf-nsis-req-06.txt
> >  > >
> >  > >
> >  > > Dear all,
> >  > >
> >  > > Marcus Brunner has = submitted an updated version of the
> >  > > requirements = document.  He feels that he has addressed all of
> >  > > the remaining open issues, = and we feel that it is ready for
> >  > > WG last call.  There = are a number of editorial nits, but
> >  > > otherwise the document is = in good shape.
> >  > >
> >  > > Therefore, I am asking the = working group to review the
> >  > > document and submit any = issues found.
> >  > >
> >  > > The working group last = call will last until Wednesday January
> >  > > 22nd, 4 PM Pacific Coast = Time.
> >  > >
> >  > > I will send a subsequent = mail outlining the procedure for
> >  > > submitting issues.
> >  > >
> >  > > thanks,
> >  > > John
> >  > > = _______________________________________________
> >  > > nsis mailing list
> >  > > nsis@ietf.org
> >  > > https://www1.ietf.org/mailman/listinfo/nsis=
> >  > >
> >  > = _______________________________________________
> >  > nsis mailing list
> >  > nsis@ietf.org
> >  > https://www1.ietf.org/mailman/listinfo/nsis=
> >  >
> >
>
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
>  https://www1.ietf.org/mailman/listinfo/nsis=
>
>
>
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis=
>

------_=_NextPart_001_01C2C2EC.C07727A0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 23 17:31:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22344 for ; Thu, 23 Jan 2003 17:31:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NMo8931645 for nsis-archive@odin.ietf.org; Thu, 23 Jan 2003 17:50:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NMo0J31638; Thu, 23 Jan 2003 17:50:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NMlDJ31477 for ; Thu, 23 Jan 2003 17:47:13 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22087 for ; Thu, 23 Jan 2003 17:27:58 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0NMVJE10295; Thu, 23 Jan 2003 16:31:23 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DPTLADYZ; Thu, 23 Jan 2003 16:31:19 -0600 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VSN2S1PP; Thu, 23 Jan 2003 16:31:19 -0600 Message-ID: <3E306C22.2020203@iqmail.net> Date: Thu, 23 Jan 2003 16:26:42 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] Issues 8 - 14 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John, Please see my comments line. Regards, Kuntal john.loughney@nokia.com wrote: > Hi Kuntal, > > Comments in line: > > > Issue Name: > > Submitter name: Kuntal Chowdhury > > Submitter email address: kuntal@iqmail.net > > Date first submitted: 03-01-22 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: E > > Priority: 2 > > Document Section: 2 > > Rationale/Explanation of issue: Definition of RMF should also mention > > about de-allocation > > > > Requested change: > > Resource Management Function (RMF): An abstract concept, representing > the > > management of resources in a domain or a node. This includes admission > > control and resource allocation/de-allocation. > > I think we need to say > > "This may include admission control and resource > allocation/de-allocation." > I agree. The "may" sounds better. > > Issue Name: > > Submitter name: Kuntal Chowdhury > > Submitter email address: kuntal@iqmail.net > > Date first submitted: 03-01-22 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: > > Document Section: 2 > > Rationale/Explanation of issue: The current definition of > > Provisioning > > has unnecessary texts. For example it says LSP initiation in > > MPLS is a > > matter of provisioning. IMO, it's not entirely correct, LSPs can be > > initiated by a LER based on it's internal logic which may be > > configured > > by suitable provisioning mechanism. > > > > Requested change: > > Provisioning: the act of configuring an NE for allocating resources to a > > flow or aggregate of flows. > > OK > > > Issue Name: > > Submitter name: Kuntal Chowdhury > > Submitter email address: kuntal@iqmail.net > > Date first submitted: 03-01-22 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: > > Document Section: 2 > > Rationale/Explanation of issue: QoS technology definition > > needs a bit of > > correction, e.g. MPLS is not really a QoS technology, it is more used > > for Traffic Engineering. > > > > Requested change: > > QoS Technology: a generic term for a set of protocols, standards and > > mechanisms that can be used within a QoS domain/subdomain to > > manage the > > QoS provided to flows or aggregates that traverse the domain. > > An example > > QoS technology is DiffServ. A QoS technology is associated > > with certain > > QoS provisioning techniques. > > OK > > > Issue Name: > > Submitter name: Kuntal Chowdhury > > Submitter email address: kuntal@iqmail.net > > Date first submitted: 03-01-22 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: > > Document Section: 2 > > Rationale/Explanation of issue: The document states that NSIS is not > > restricted to QoS signaling only, it also covers signaling > > required for > > other purposes such as ....not mentioned! > > The requirements are based on the fact that a signal is > > initiated from > > an NSIS initiator for allocation of network resources. It > > would be nice > > to see some examples of non-QoS signals that require allocation of > > network resources in the internet. > > We can try to add some. > Thanks. > > Issue Name: > > Submitter name: Kuntal Chowdhury > > Submitter email address: kuntal@iqmail.net > > Date first submitted: 03-01-22 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: T > > Priority: > > Document Section: 4.1 > > Rationale/Explanation of issue: > > " 6. NSIS assumes to operate with networks using standard ("normal") > > L3 routing. Where "normal" is not specified more exactly > > on purpose." > > > > this is very vague assumption. Not sure which routing scheme is > > considered "normal". If some are normal then which ones are > > "abnormal"? > > > > Requested change: > > 6. NSIS assumes to operate with networks using standard L3 routing. > > OK > > > Issue Name: > > Submitter name: Kuntal Chowdhury > > Submitter email address: kuntal@iqmail.net > > Date first submitted: 03-01-22 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: E > > Priority: > > Document Section: 5.2.1 > > Rationale/Explanation of issue: > > "5.2.1 The placement of NSIS Initiator, Forwarder, Responder > > MUST be free" > > > > MUST be free of what? > > > > Requested change: > > 5.2.1 The placement of NSIS Initiator, Forwarder, and > > Responder anywhere > > in the network MUST be allowed" > > How about: > > MUST be possible. > Sounds good to me. > > Issue Name: > > Submitter name: Kuntal Chowdhury > > Submitter email address: kuntal@iqmail.net > > Date first submitted: 03-01-22 > > Reference: - > > Document: draft-ietf-nsis-req-06.txt > > Comment type: E > > Priority: > > Document Section: 5.2.2 > > Rationale/Explanation of issue: > > "5.2.2 No constraint MUST be posed the signaling and NSIS > > Forwarders to > > be in the data path. " > > > > Need to rephrase this requirement. > > > > Requested change: > > 5.2.2 There MUST not be any constraint to always require the NSIS > > forwarder to be on the data path. > > I am not sure still about this requirement, does anyone have comments? > > Thanks, > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Jan 25 22:59:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02793 for ; Sat, 25 Jan 2003 22:59:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0Q4ItP28466 for nsis-archive@odin.ietf.org; Sat, 25 Jan 2003 23:18:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q4IoJ28459; Sat, 25 Jan 2003 23:18:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PHHLJ31089 for ; Sat, 25 Jan 2003 12:17:21 -0500 Received: from titan.tele.pw.edu.pl (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25782 for ; Sat, 25 Jan 2003 11:57:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by titan.tele.pw.edu.pl (Postfix) with ESMTP id D985C3B6B7 for ; Sat, 25 Jan 2003 18:00:33 +0100 (CET) Received: from aquila (zttstaff-dhcp118.tele.pw.edu.pl [194.29.169.118]) by titan.tele.pw.edu.pl (Postfix) with ESMTP id B1DA33B67B for ; Sat, 25 Jan 2003 18:00:28 +0100 (CET) Message-ID: <410-2200316251792126@aquila> From: "Art-QoS" To: nsis@ietf.org Date: Sat, 25 Jan 2003 18:09:21 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 titan Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0PHHLJ31090 Subject: [NSIS] Reminder: Art-QoS, Architectures for Quality of Service in the Internet Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We apologize if you recieve multiple copies of this message. We would like to remind you that the paper submission deadline for Art-QoS 2003 conference is coming soon (on February 1st, 2003). Below we enclose the electronic version of the CFP. You can find further information on the web site www.tele.pw.edu.pl/art-qos CALL FOR PAPERS Art-QoS 2003 Workshop on ARCHITECTURES FOR QUALITY OF SERVICE IN THE INTERNET jointly held with THE FINAL AQUILA IST SEMINAR Warsaw, Poland, March 24-25, 2003 Organised by: Institute of Telecommunications Warsaw University of Technology, Poland WORKSHOP PURPOSE The Workshop is organised for bringing together the researchers working on providing Quality of Service (QoS) into IP-based networks. The intention is to discuss architectural and traffic control mechanisms aspects supporting end-to-end QoS. The Workshop is organised jointly with the Final Seminar of the AQUILA IST project. The AQUILA (Adaptive Resource Control for QoS Using an IP-based Layered Architecture) project started in December 1999 with 12 partners from 6 countries (Austria, Finland, Germany, Greece, Italy and Poland). The project has defined a comprehensive framework for the support of QoS in IP-based networks. The proposed solutions were implemented in the form of prototypes and tested in the AQUILA trial sites, in Helsinki, Vienna and Warsaw. During the Workshop there are planned two special sessions devoted to AQUILA. More information about the project one can find at www.ist-aquila.org. CONFERENCE TOPICS The list of the topics includes (but is not limited to) - Architectures for QoS IP - QoS IP Mechanisms - Performance Evaluation - Internet Traffic Modelling - Traffic Control and Engineering - Traffic Measurements - Testing Results - QoS Requirements - Transport Protocols (TCP, UDP) over IP QoS - Inter-domain QoS - QoS in IPv.6 WORKSHOP VENUE The Workshop will be held in the Sheraton Warsaw Hotel situated near the centre of Warsaw: www.sheraton.pl PROCEEDINGS EDITION All accepted papers will be published in the form of a book, in the Lecture Notes in Computer Science (LNCS) series by Springer-Verlag. Remark that the paper publication is conditioned by paper presentation at the Workshop. PAPER SUBMISSION Authors are kindly invited to submit full paper describing original research as well as results of laboratory and real network trials. The paper (with max. 12 single-spaced pages) should be written in English and submitted not later than February 1st, 2003. Please send the paper in the form of PS or PDF file. The authors will be notified about the paper acceptance not later than February 20th, 2003. The deadline for camera-ready copy is March 1st, 2003. The papers should be submitted to the following e-mail address: art-qos@tele.pw.edu.pl For the submitted paper and camera-ready manuscript please use the Springer-Verlag instructions for authors at: www.springer.de/comp/lncs/authors.html WORKSHOP REGISTRATION Information about the registration is available at the www.tele.pw.edu.pl/art-qos ACCOMMODATION For the conference participants the organisers booked the rooms in the Sheraton Warsaw Hotel with special price (125 EUR + 7% VAT for single room). The hotel registration form one can find at www.tele.pw.edu.pl/art-qos. The special rates are guaranteed for the reservations not later than March 3rd. IMPORTANT DATES Full paper due: February 1, 2003 Notification of acceptance due: February 20, 2003 Camera-ready paper due: March 1, 2003 CORRESPONDENCE ADDRESS Halina Tarasiuk Institute of Telecommunications Warsaw University of Technology Ul. Nowowiejska 15/19 00-665 Warsaw, Poland Phone: (+48 22) 660 73 96 Fax: (+48 22) 660 75 64 E-mail: art-qos@tele.pw.edu.pl PROGRAM COMMITTEE Co-chairs Wojciech Burakowski, Warsaw University of Technology, Poland Berthold Koch, Siemens AG, Germany Members Jose Brazio, Telecommunications Institute Lisbon, Portugal Andrzej Dabrowski, Warsaw University of Technology, Poland Franco Davoli, University of Genua, Italy Gerald Eichler, T-Systems Nova, Germany Hermann Granzer, Siemens AG, Germany Ulrich Hofmann, Salzburg Research, Austria Heinrich Hussmann, Dresden University of Technology, Germany Laszlo Jereb, Budapest University of Technology and Economics, Hungary Yannis Karadimas, Q-Systems, Greece Ilkka Norros, VTT Information Technology, Finland James Roberts, France Telecom R&D, France Stefano Salsano, University of Roma "Tor Vergata", Italy Paulo de Sousa ,European Commission Phuoc Tran-Gia, University of Wuerzburg, Germany Iakovos S. Venieris, National Technical University of Athens, Greece Manuel Villen Altamirano, Telefonica I+D, Spain Jozef Wozniak, Technical University of Gdansk, Poland LOCAL ORGANISING COMMITTEE Andrzej Bak, Andrzej Beben, Marek Dabrowski, Monika Fudala, Halina Tarasiuk (chair), Elzbieta Tarwacka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 27 10:08:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17207 for ; Mon, 27 Jan 2003 10:08:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RFSx228130 for nsis-archive@odin.ietf.org; Mon, 27 Jan 2003 10:28:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RFSqJ28120; Mon, 27 Jan 2003 10:28:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCwDJ18670 for ; Mon, 27 Jan 2003 07:58:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14327; Mon, 27 Jan 2003 07:37:15 -0500 (EST) Message-Id: <200301271237.HAA14327@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Jan 2003 07:37:14 -0500 Subject: [NSIS] I-D ACTION:draft-mcdonald-nsis-ntlp-considerations-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Design Considerations for an NSIS Transport Layer Protocol Author(s) : A. McDonald, R. Hancock, E. Hepworth Filename : draft-mcdonald-nsis-ntlp-considerations-00.txt Pages : 18 Date : 2003-1-24 A framework for NSIS is in preparation, and will identify a split into two layers. The lower layer, referred to as the NSIS Transport Layer Protocol (NTLP) provides generic support for different types of path coupled signalling, including QoS signalling. This document discusses issues to be considered in the design of an NSIS Transport Layer Protocol (NTLP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-ntlp-considerations-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcdonald-nsis-ntlp-considerations-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mcdonald-nsis-ntlp-considerations-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-24113153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-nsis-ntlp-considerations-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-nsis-ntlp-considerations-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-24113153.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jan 27 17:50:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29824 for ; Mon, 27 Jan 2003 17:50:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RNBdN24835 for nsis-archive@odin.ietf.org; Mon, 27 Jan 2003 18:11:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RNBPJ24828; Mon, 27 Jan 2003 18:11:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RN9cJ24779 for ; Mon, 27 Jan 2003 18:09:38 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29755 for ; Mon, 27 Jan 2003 17:48:27 -0500 (EST) Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0RMptY01487 for ; Mon, 27 Jan 2003 16:51:55 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c001.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXY6QJF3; Mon, 27 Jan 2003 16:51:55 -0600 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DRS1X1CR; Mon, 27 Jan 2003 16:51:55 -0600 Message-ID: <3E35B6ED.8020301@iqmail.net> Date: Mon, 27 Jan 2003 16:47:09 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Here is an attempt to generalize the scope of NSIS in 3G wireless networks. The following is the suggested update/re-write of section 10.2 and 10.3. Issue Name: 7 Submitter name: Louis-Nicolas Hamer and Kuntal Chowdhury Submitter email address: nhamer@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 Section: 10.2 & 10.3 Proposed text: 10.2 3G Wireless Networks In this scenario, the user is using the packet services of a 3rd generation wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The region between the End Host and the Edge Node (Edge Router) connecting the wireless network to another QoS domain is considered to be a single QoS domain. The issues in such an environment regarding QoS include: 1) 3G wireless networks provide their own QoS technology with specialized parameters to co-ordinate the QoS provided by both the radio access and wired access networks. Provisioning of QoS technologies within a 3G wireless network can be described mainly in terms of calling bearer classes, service options and service instances. These QoS technologies need to be invoked with suitable parameters when higher layers trigger a request for QoS. Therefore these involve mapping of the requested higher layer QoS parameters onto specific bearer classes or service instances. The request for allocation of resources might be triggered by signaling at the IP level that passes across the wireless system, and possibly other QoS domains. Typically, wireless network specific messages are invoked to setup the underlying bearer classes or service instances in parallel with the IP layer QoS negotiation, to allocate resources within the radio access network. 2) The IP signaling messages are initiated by the NSIS initiator and interpreted by the NSIS Forwarder. The most efficient placement of the NSIS Initiator and NSIS Forwarder has not been determined in 3G wireless networks, but a few potential scenarios can be envisioned. The NSIS Initiator could be located at the End Host e.g. UE or MS (triggered by applications), the Access Gateway or at a node that is not directly on the data path, such as a policy server. The Access Gateway could act as a proxy NSIS Initiator on behalf of the UE/MS or an End Host. The Policy Server that manages per-flow/aggregate resources within its QoS domain (e.g. the 3G wireless network) may act as a proxy NSIS Initiator for the UE/MS or the Access Gateway. Depending on the placement of the NSIS Initiator, the NSIS Forwarder may be located at an appropriate point in the 3G wireless network. 3) The need for re-negotation of the resource needs in a new 3G wireless domain due to UE/MS mobility. In this case the NSIS Initiators and the NSIS Forwarders will have to detect mobility events and trigger re-negotiation of resources autonomously. 10.3 An example scenario for a 3G wireless network The 3G wireless access scenario is shown in Figure 1. The Proxy-Call State Control Function (P-CSCF) is the outbound SIP proxy (only used in IMS). The Access Gateway is the egress router of the 3G wireless domain and it connects the radio access network to the Edge Router (ER) of the backbone IP network. The Policy Server is the entity responsible for managing the resource allocations/de-allocations in the 3G wireless domain. It is also responsible for the policy-based control of the end-user service. The Policy Server also controls the Access Gateway to open and close the gates and to configure per-flow policies, i.e. to authorize or forbid user traffic. The P-CSCF (only used in IMS) and the Access Gateway communicate with the Policy Server, for network resource allocation/de-allocation decisions. The User Equipment (UE) or the Mobile Station (MS) consists of a Mobile Terminal (MT) and Terminal Equipment (TE), e.g. a laptop. +--------+ +--------->| P-CSCF |-------> SIP signaling / +--------+ / SIP | | +--------+ | | Policy | +----------------+ | | Server |<------->| NSIS Forwarder |<---> | +--------+ +----------------+ | | ^ | |COPS | | | | +------+ +---------+ | | UE/MS|----------| Access |<-----------+ +----+ +------+ | Gateway |----------------------| ER | +---------+ +----+ Figure 1: 3G wireless access scenario The Policy Server has all the required QoS information for per-flow or aggregate admission control in 3G wireless networks. It receives resource allocation/de-allocation requests from the P-CSCF and/or Access Gateway etc. and responds with policy decisions. Hence the Policy Server may be a candidate entity to host the functionality of the NSIS Initiator, initiating the "NSIS" QoS signaling towards the core IP network. On the other hand, the UE/MS may act as the NSIS Initiator or the Access Gateway may act as a Proxy NSIS Initiator on behalf of the UE/MS. In the former case, the P-CSCF/Policy Server has to do the mapping from codec types and media descriptors (derived from SIP/SDP signaling) to IP traffic descriptor. In the latter case, the UE/MS may use any appropriate QoS signaling mechanism as the NSIS Initiator. If the Access Gateway is acting as the Proxy NSIS initiator on behalf of the UE/MS, then it may have to do the mapping of parameters from radio access specific QoS to IP QoS traffic parameters before forwarding the request to the NSIS Forwarder. The NSIS Forwarder is currently not part of the standard 3G wireless architecture. However, to achieve end-to-end QoS a NSIS Forwarder is needed such that the NSIS Initiators can request a QoS connection to the IP network. As in the previous example, the NSIS Forwarder could manage a set of pre-provisioned resources in the IP network, i.e. bandwidth pipes, and the NSIS Forwarder performs per-flow admission control into these pipes. In this way, a connection can be made between two 3G wireless access networks, and hence, end-to-end QoS can be achieved. In this case the NSIS Initiator and NSIS Forwarder are clearly two separate logical entities. The Access Gateway or/and the Edge Router in Fig.1 may contain the NSIS Forwarder functionality, depending upon the placement of the NSIS Initiator as discussed in scenario 2 in section 10.2. This use case clearly illustrates the need for an "NSIS" QoS signaling protocol between NSIS Initiator and NSIS Forwarder. An important application of such a protocol may be its use in the end-to-end establishment of a connection with specific QoS characteristics between a mobile host and another party (e.g. end host or content server). _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jan 28 09:33:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26635 for ; Tue, 28 Jan 2003 09:33:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SEsWO23839 for nsis-archive@odin.ietf.org; Tue, 28 Jan 2003 09:54:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SEsQJ23827; Tue, 28 Jan 2003 09:54:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SC6xJ13244 for ; Tue, 28 Jan 2003 07:06:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21879; Tue, 28 Jan 2003 06:45:33 -0500 (EST) Message-Id: <200301281145.GAA21879@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Jan 2003 06:45:33 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-threats-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Security Threats for NSIS Author(s) : H. Tschofenig, D. Kroeselberg Filename : draft-ietf-nsis-threats-01.txt Pages : 15 Date : 2003-1-27 This threats document provides a detailed analysis of the security threats relevant for the NSIS working group. It motivates and helps to understand various security considerations in the NSIS Requirements, Framework and Protocol proposals. This document does not describe vulnerabilities of specific NSIS protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-threats-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-threats-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-27132631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-threats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-threats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-27132631.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jan 28 11:17:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29629 for ; Tue, 28 Jan 2003 11:17:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SGcuS32702 for nsis-archive@odin.ietf.org; Tue, 28 Jan 2003 11:38:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGckJ32684; Tue, 28 Jan 2003 11:38:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGc0J32638 for ; Tue, 28 Jan 2003 11:38:00 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29589 for ; Tue, 28 Jan 2003 11:16:26 -0500 (EST) From: maarten.buchli@alcatel.be Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id h0SGJrs04410; Tue, 28 Jan 2003 17:19:53 +0100 Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt To: nsis@ietf.org Cc: Kuntal Chowdhury Date: Tue, 28 Jan 2003 17:19:50 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/28/2003 17:19:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, The proposed text seems fine to me, it has made the text more generic and well readable. Only one remark: correct the sentence under bullet 3) of section 10.2 Thanks, Maarten Kuntal Chowdhury @ietf.org on 27/01/2003 23:47:09 Sent by: nsis-admin@ietf.org To: nsis@ietf.org cc: Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Hi all, Here is an attempt to generalize the scope of NSIS in 3G wireless networks. The following is the suggested update/re-write of section 10.2 and 10.3. Issue Name: 7 Submitter name: Louis-Nicolas Hamer and Kuntal Chowdhury Submitter email address: nhamer@nortelnetworks.com Date first submitted: 22/01/2003 Reference: none Document: draft-ietf-nsis-req-06.txt Comment type: T Priority: 2 Section: 10.2 & 10.3 Proposed text: 10.2 3G Wireless Networks In this scenario, the user is using the packet services of a 3rd generation wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The region between the End Host and the Edge Node (Edge Router) connecting the wireless network to another QoS domain is considered to be a single QoS domain. The issues in such an environment regarding QoS include: 1) 3G wireless networks provide their own QoS technology with specialized parameters to co-ordinate the QoS provided by both the radio access and wired access networks. Provisioning of QoS technologies within a 3G wireless network can be described mainly in terms of calling bearer classes, service options and service instances. These QoS technologies need to be invoked with suitable parameters when higher layers trigger a request for QoS. Therefore these involve mapping of the requested higher layer QoS parameters onto specific bearer classes or service instances. The request for allocation of resources might be triggered by signaling at the IP level that passes across the wireless system, and possibly other QoS domains. Typically, wireless network specific messages are invoked to setup the underlying bearer classes or service instances in parallel with the IP layer QoS negotiation, to allocate resources within the radio access network. 2) The IP signaling messages are initiated by the NSIS initiator and interpreted by the NSIS Forwarder. The most efficient placement of the NSIS Initiator and NSIS Forwarder has not been determined in 3G wireless networks, but a few potential scenarios can be envisioned. The NSIS Initiator could be located at the End Host e.g. UE or MS (triggered by applications), the Access Gateway or at a node that is not directly on the data path, such as a policy server. The Access Gateway could act as a proxy NSIS Initiator on behalf of the UE/MS or an End Host. The Policy Server that manages per-flow/aggregate resources within its QoS domain (e.g. the 3G wireless network) may act as a proxy NSIS Initiator for the UE/MS or the Access Gateway. Depending on the placement of the NSIS Initiator, the NSIS Forwarder may be located at an appropriate point in the 3G wireless network. 3) The need for re-negotation of the resource needs in a new 3G wireless domain due to UE/MS mobility. In this case the NSIS Initiators and the NSIS Forwarders will have to detect mobility events and trigger re-negotiation of resources autonomously. 10.3 An example scenario for a 3G wireless network The 3G wireless access scenario is shown in Figure 1. The Proxy-Call State Control Function (P-CSCF) is the outbound SIP proxy (only used in IMS). The Access Gateway is the egress router of the 3G wireless domain and it connects the radio access network to the Edge Router (ER) of the backbone IP network. The Policy Server is the entity responsible for managing the resource allocations/de-allocations in the 3G wireless domain. It is also responsible for the policy-based control of the end-user service. The Policy Server also controls the Access Gateway to open and close the gates and to configure per-flow policies, i.e. to authorize or forbid user traffic. The P-CSCF (only used in IMS) and the Access Gateway communicate with the Policy Server, for network resource allocation/de-allocation decisions. The User Equipment (UE) or the Mobile Station (MS) consists of a Mobile Terminal (MT) and Terminal Equipment (TE), e.g. a laptop. +--------+ +--------->| P-CSCF |-------> SIP signaling / +--------+ / SIP | | +--------+ | | Policy | +----------------+ | | Server |<------->| NSIS Forwarder |<---> | +--------+ +----------------+ | | ^ | |COPS | | | | +------+ +---------+ | | UE/MS|----------| Access |<-----------+ +----+ +------+ | Gateway |----------------------| ER | +---------+ +----+ Figure 1: 3G wireless access scenario The Policy Server has all the required QoS information for per-flow or aggregate admission control in 3G wireless networks. It receives resource allocation/de-allocation requests from the P-CSCF and/or Access Gateway etc. and responds with policy decisions. Hence the Policy Server may be a candidate entity to host the functionality of the NSIS Initiator, initiating the "NSIS" QoS signaling towards the core IP network. On the other hand, the UE/MS may act as the NSIS Initiator or the Access Gateway may act as a Proxy NSIS Initiator on behalf of the UE/MS. In the former case, the P-CSCF/Policy Server has to do the mapping from codec types and media descriptors (derived from SIP/SDP signaling) to IP traffic descriptor. In the latter case, the UE/MS may use any appropriate QoS signaling mechanism as the NSIS Initiator. If the Access Gateway is acting as the Proxy NSIS initiator on behalf of the UE/MS, then it may have to do the mapping of parameters from radio access specific QoS to IP QoS traffic parameters before forwarding the request to the NSIS Forwarder. The NSIS Forwarder is currently not part of the standard 3G wireless architecture. However, to achieve end-to-end QoS a NSIS Forwarder is needed such that the NSIS Initiators can request a QoS connection to the IP network. As in the previous example, the NSIS Forwarder could manage a set of pre-provisioned resources in the IP network, i.e. bandwidth pipes, and the NSIS Forwarder performs per-flow admission control into these pipes. In this way, a connection can be made between two 3G wireless access networks, and hence, end-to-end QoS can be achieved. In this case the NSIS Initiator and NSIS Forwarder are clearly two separate logical entities. The Access Gateway or/and the Edge Router in Fig.1 may contain the NSIS Forwarder functionality, depending upon the placement of the NSIS Initiator as discussed in scenario 2 in section 10.2. This use case clearly illustrates the need for an "NSIS" QoS signaling protocol between NSIS Initiator and NSIS Forwarder. An important application of such a protocol may be its use in the end-to-end establishment of a connection with specific QoS characteristics between a mobile host and another party (e.g. end host or content server). _______________________________________________ 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 mailnull@www1.ietf.org Tue Jan 28 12:47:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02177 for ; Tue, 28 Jan 2003 12:47:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SI8pR07088 for nsis-archive@odin.ietf.org; Tue, 28 Jan 2003 13:08:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SI8ZJ07077; Tue, 28 Jan 2003 13:08:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SI5oJ06353 for ; Tue, 28 Jan 2003 13:05:50 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02090 for ; Tue, 28 Jan 2003 12:44:15 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0SHlFY25832; Tue, 28 Jan 2003 11:47:16 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXWL7838; Tue, 28 Jan 2003 11:47:16 -0600 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DRS1X1MD; Tue, 28 Jan 2003 11:47:16 -0600 Message-ID: <3E36C103.8060800@iqmail.net> Date: Tue, 28 Jan 2003 11:42:27 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: maarten.buchli@alcatel.be CC: nsis@ietf.org Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Maarten, Thanks for pointing out the inconsistency in bullet 3 in section 10.2. How about: 3) The need for re-negotiation of resources in a new 3G wireless domain due to UE/MS mobility. In this case the NSIS Initiator and the NSIS Forwarder should detect mobility events and autonomously trigger re-negotiation of resources. Regards, Kuntal maarten.buchli@alcatel.be wrote: > Hi, > > The proposed text seems fine to me, it has made the text more generic and > well readable. > Only one remark: correct the sentence under bullet 3) of section 10.2 > > Thanks, > Maarten > > > > > > Kuntal Chowdhury @ietf.org on 27/01/2003 23:47:09 > > Sent by: nsis-admin@ietf.org > > > To: nsis@ietf.org > cc: > Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Hi all, > Here is an attempt to generalize the scope of NSIS in 3G wireless networks. > The > following is the suggested update/re-write of section 10.2 and 10.3. > > Issue Name: 7 > Submitter name: Louis-Nicolas Hamer and Kuntal Chowdhury > Submitter email address: nhamer@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 10.2 & 10.3 > > Proposed text: > > 10.2 3G Wireless Networks > > In this scenario, the user is using the packet services of a 3rd > generation wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The > region between the End Host and the Edge Node (Edge Router) > connecting the wireless network to another QoS domain is considered > to be a single QoS domain. > > The issues in such an environment regarding QoS include: > > 1) 3G wireless networks provide their own QoS technology with > specialized parameters to co-ordinate the QoS provided by both the > radio access and wired access networks. Provisioning of QoS > technologies within a 3G wireless network can be described mainly > in terms of calling bearer classes, service options and service > instances. These QoS technologies need to be invoked with suitable > parameters when higher layers trigger a request for QoS. Therefore > these involve mapping of the requested higher layer QoS parameters > onto specific bearer classes or service instances. The request for > allocation of resources might be triggered by signaling at the IP > level that passes across the wireless system, and possibly other > QoS domains. Typically, wireless network specific messages are > invoked to setup the underlying bearer classes or service instances > in parallel with the IP layer QoS negotiation, to allocate resources > within the radio access network. > > 2) The IP signaling messages are initiated by the NSIS initiator and > interpreted by the NSIS Forwarder. The most efficient placement of the > NSIS Initiator and NSIS Forwarder has not been determined in 3G > wireless > networks, but a few potential scenarios can be envisioned. The NSIS > Initiator could be located at the End Host e.g. UE or MS (triggered by > applications), the Access Gateway or at a node that is not directly on > the data path, such as a policy server. The Access Gateway could act as > a proxy NSIS Initiator on behalf of the UE/MS or an End Host. The > Policy > Server that manages per-flow/aggregate resources within its QoS domain > (e.g. the 3G wireless network) may act as a proxy NSIS Initiator for > the > UE/MS or the Access Gateway. Depending on the placement of the NSIS > Initiator, the NSIS Forwarder may be located at an appropriate > point in the 3G wireless network. > > 3) The need for re-negotation of the resource needs in a new 3G > wireless > domain due to UE/MS mobility. In this case the NSIS Initiators and the > NSIS Forwarders will have to detect mobility events and trigger > re-negotiation of resources autonomously. > > > 10.3 An example scenario for a 3G wireless network > > The 3G wireless access scenario is shown in Figure 1. The Proxy-Call > State Control Function (P-CSCF) is the outbound SIP proxy (only used > in IMS). The Access Gateway is the egress router of the 3G wireless > domain and it connects the radio access network to the Edge Router > (ER) of the backbone IP network. The Policy Server is the entity > responsible for managing the resource allocations/de-allocations in > the 3G wireless domain. It is also responsible for the policy-based > control of the end-user service. The Policy Server also controls the > Access Gateway to open and close the gates and to configure per-flow > policies, i.e. to authorize or forbid user traffic. The P-CSCF (only > used in IMS) and the Access Gateway communicate with the Policy Server, > for network resource allocation/de-allocation decisions. The User > Equipment (UE) or the Mobile Station (MS) consists of a Mobile Terminal > (MT) and Terminal Equipment (TE), e.g. a laptop. > > > +--------+ > +--------->| P-CSCF |-------> SIP signaling > / +--------+ > / SIP | > | +--------+ > | | Policy | +----------------+ > | | Server |<------->| NSIS Forwarder |<---> > | +--------+ +----------------+ > | | ^ > | |COPS | > | | | > +------+ +---------+ | > | UE/MS|----------| Access |<-----------+ +----+ > +------+ | Gateway |----------------------| ER | > +---------+ +----+ > > Figure 1: 3G wireless access scenario > > The Policy Server has all the required QoS information for per-flow > or aggregate admission control in 3G wireless networks. It receives > resource allocation/de-allocation requests from the P-CSCF and/or > Access Gateway etc. and responds with policy decisions. Hence the > Policy Server may be a candidate entity to host the functionality > of the NSIS Initiator, initiating the "NSIS" QoS signaling towards the > core IP network. On the other hand, the UE/MS may act as the NSIS > Initiator or the Access Gateway may act as a Proxy NSIS Initiator > on behalf of the UE/MS. In the former case, the P-CSCF/Policy Server > has to do the mapping from codec types and media descriptors (derived > from SIP/SDP signaling) to IP traffic descriptor. In the latter > case, the UE/MS may use any appropriate QoS signaling mechanism as the > NSIS Initiator. If the Access Gateway is acting as the Proxy > NSIS initiator on behalf of the UE/MS, then it may have to do the > mapping of parameters from radio access specific QoS to IP QoS > traffic parameters before forwarding the request to the NSIS Forwarder. > > The NSIS Forwarder is currently not part of the standard 3G wireless > architecture. However, to achieve end-to-end QoS a NSIS Forwarder is > needed such that the NSIS Initiators can request a QoS connection to > the IP network. As in the previous example, the NSIS Forwarder > could manage a set of pre-provisioned resources in the IP network, > i.e. bandwidth pipes, and the NSIS Forwarder performs per-flow > admission > control into these pipes. In this way, a connection can be made between > two 3G wireless access networks, and hence, end-to-end QoS can be > achieved. In this case the NSIS Initiator and NSIS Forwarder are > clearly two separate logical entities. The Access Gateway or/and the > Edge Router in Fig.1 may contain the NSIS Forwarder functionality, > depending upon the placement of the NSIS Initiator as discussed in > scenario 2 in section 10.2. This use case clearly illustrates the need > for an "NSIS" QoS signaling protocol between NSIS Initiator and NSIS > Forwarder. An important application of such a protocol may be its use > in the end-to-end establishment of a connection with specific QoS > characteristics between a mobile host and another party (e.g. end host > or content server). > > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Jan 28 13:06:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02541 for ; Tue, 28 Jan 2003 13:06:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SIRfx07821 for nsis-archive@odin.ietf.org; Tue, 28 Jan 2003 13:27:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SIRWJ07812; Tue, 28 Jan 2003 13:27:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SIQ4J07757 for ; Tue, 28 Jan 2003 13:26:04 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02520 for ; Tue, 28 Jan 2003 13:04:29 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0SI6vn26363 for ; Tue, 28 Jan 2003 20:06:57 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 28 Jan 2003 20:07:58 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Jan 2003 20:07:58 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Jan 2003 20:07:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 28 Jan 2003 20:07:57 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcLG9mCCS7YORm+PT5aSFPuuTKaH+QAAbJ1w To: X-OriginalArrivalTime: 28 Jan 2003 18:07:57.0797 (UTC) FILETIME=[2FEBD950:01C2C6F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SIQ4J07758 Subject: [NSIS] Interim Meeting Agenda Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Here is my proposed agenda. Anyone with comments or suggestions, please send them. br, John NSIS Interim Meeting Monday Intro WG update Charter update Requirements update http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-06.txt Framework update http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-01.txt lunch Security threats update http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt NSIS Authentication, Authorization and Accounting Issues Implications of trust relationships for NSIS signaling Tuesday Starting Protocol Work NSIS Transport Layer Protocol (NTLP) Functionality http://www.ietf.org/internet-drafts/draft-brunner-nsis-ntlp-func-00.txt Design Considerations for an NSIS Transport Layer Protocol http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-ntlp-considerations-00.txt Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for modifications on RFC2205 http://www.ietf.org/internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-00.txt Wednesday Mobility issues other topics? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jan 28 14:46:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04962 for ; Tue, 28 Jan 2003 14:46:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SK7Ia14461 for nsis-archive@odin.ietf.org; Tue, 28 Jan 2003 15:07:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SK7EJ14437; Tue, 28 Jan 2003 15:07:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SK6DJ14020 for ; Tue, 28 Jan 2003 15:06:13 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04912 for ; Tue, 28 Jan 2003 14:44:36 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 19:48:06 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF66BC@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Interim Meeting Agenda Date: Tue, 28 Jan 2003 19:48:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , john, there have been scattered discussions in the distant and recent past about the necessity to cope with a wide variety of signalling applications (concerns about the ability to extend or mix together applications, the fact that some applications may have very different performance requirements for the NTLP from others, the question of whether the signalling application space could be given more structure - e.g. might there be common components for things like authorisation and so on). i know qos is the only issue on our plate at the moment, but it might be helpful to have an hour or less of mind-broadening at some point. maybe contingent on people saying they have points that need to be made in this area. cheers, robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 28 January 2003 10:08 > To: nsis@ietf.org > Subject: [NSIS] Interim Meeting Agenda > > > Hi all, > > Here is my proposed agenda. Anyone with comments or > suggestions, please send them. > > br, > John > > NSIS Interim Meeting > > Monday > > Intro > WG update > Charter update > Requirements update > http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-06.txt > Framework update > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-01.txt > lunch > Security threats update > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt > NSIS Authentication, Authorization and Accounting Issues > Implications of trust relationships for NSIS signaling > > Tuesday > > Starting Protocol Work > NSIS Transport Layer Protocol (NTLP) Functionality > > http://www.ietf.org/internet-drafts/draft-brunner-nsis-ntlp-fu nc-00.txt Design Considerations for an NSIS Transport Layer Protocol http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-ntlp-considerations-00.txt Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for modifications on RFC2205 http://www.ietf.org/internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-00.txt Wednesday Mobility issues other topics? _______________________________________________ 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 mailnull@www1.ietf.org Tue Jan 28 14:46:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04976 for ; Tue, 28 Jan 2003 14:46:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SK7Kx14479 for nsis-archive@odin.ietf.org; Tue, 28 Jan 2003 15:07:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SK7GJ14452; Tue, 28 Jan 2003 15:07:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SK6GJ14024 for ; Tue, 28 Jan 2003 15:06:16 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04915 for ; Tue, 28 Jan 2003 14:44:39 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 19:48:09 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF66BD@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Tue, 28 Jan 2003 19:48:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] layer split summary? opinions? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, as christmas fades into the past and the interim meeting looms, i'd like to re-emphasise some of the core questions that need to be considered and resolved to allow us to make progress on the framework, beyond where we are now (and hence are pretty crucial to making protocol progress as well). the most important of these is: where does the NTLP/NSLP boundary lie - in other words (I think) what functionality do we see as both (a) common to a large proportion of 'signalling' problems, and (b) something that has to be implemented 'low down' in the stack for some reason. if anyone has any thoughts at all on any aspects of this question, now would be a good time to raise them, especially if you disagree with any of the directions implied in the (rather long) summary below. personally, i'd like to see the way forward on these questions finalised - at least in broad outline - in enough time to update documents for IETF#56. cheers, robert h. ========================================= here are some of the facets of this question. there seems to be either agreement or at least no disagreement that *) the NTLP shouldn't have much more interesting message types than 'send data' (i.e. it shouldn't have a 'reserve' message for example) *) the NTLP at one node should be able to use information visible at 'its' layer to send a message to the next NTLP node, rather than relying on the upper layer to work out routing *) the NTLP shouldn't have concepts of sender or receiver 'initiation' e.g. of a signalling transaction; it only needs to discover its peers downstream but may need to be able to send messages upstream as well. (see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02315.html for more details). as well as these, there is at least in my head a basic assumption that traditional transport-layer like functionality (segmentation, congestion control, all the different aspects of reliability and so on) should be in the NTLP. On the other hand, some people clearly have doubts about whether these properties are needed for NSIS signalling at all. there are some more difficult questions, where views diverge more strongly: *) can we assume that NSLP peers are connected by a single NTLP 'hop' or might the connection run over more than one 'hop' concatenated together? (not assuming a connection oriented model here, just couldn't think of a better word.) does this non-end-to-end-ness of the NTLP restrict what functionality we should attempt to give it? *) should the NTLP provide a state management service to signalling applications (crudely, should it provide a capability like 'create some state over there' or should it just provide the capability 'send some data over there')? some people think 'obviously yes' some think 'obviously no'. (see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02389.html) *) should the NTLP contain some flow identification information similar to the 5-tuple or not (for NAT and policy routing reasons)? the framework currently says yes, but there have been objections. (see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02394.html). In addition, there are things we haven't really discussed at all yet in the context of layer splitting; in particular, the role (or not) of the NTLP in scoping where messages are allowed to go, detecting and handling mobility events, what gets modified to cope with the path-decoupled case, error and failure condition detection and handling. =================================================================== _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jan 28 17:29:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10120 for ; Tue, 28 Jan 2003 17:29:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SMoqv26574 for nsis-archive@odin.ietf.org; Tue, 28 Jan 2003 17:50:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SMojJ26559; Tue, 28 Jan 2003 17:50:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SMnLJ26472 for ; Tue, 28 Jan 2003 17:49:21 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10067 for ; Tue, 28 Jan 2003 17:27:41 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0SMXdg22961 for ; Wed, 29 Jan 2003 00:33:39 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Jan 2003 00:31:10 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 29 Jan 2003 00:31:10 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 29 Jan 2003 00:31:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Interim Meeting Agenda Date: Wed, 29 Jan 2003 00:31:09 +0200 Message-ID: Thread-Topic: [NSIS] Interim Meeting Agenda Thread-Index: AcLHBi8y0721ejt9Q++BJ42hY+1MPwAFqZ1g To: , X-OriginalArrivalTime: 28 Jan 2003 22:31:10.0406 (UTC) FILETIME=[F50CBE60:01C2C71C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SMnLJ26473 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Robert, > there have been scattered discussions in the distant and > recent past about the necessity to cope with a wide variety > of signalling applications (concerns about the ability to > extend or mix together applications, the fact that some > applications may have very different performance requirements > for the NTLP from others, the question of whether the > signalling application space could be given more structure - > e.g. might there be common components for things like > authorisation and so on). > > i know qos is the only issue on our plate at the moment, but > it might be helpful to have an hour or less of > mind-broadening at some point. maybe contingent on people > saying they have points that need to be made in this area. That is a good point. My suggest is to leave some time on Monday to discuss it. However, we would need some folks to prepare some discussion topics on it. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jan 28 22:12:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15033 for ; Tue, 28 Jan 2003 22:12:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T3Y0310758 for nsis-archive@odin.ietf.org; Tue, 28 Jan 2003 22:34:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T3XjJ10747; Tue, 28 Jan 2003 22:33:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T3WLJ10710 for ; Tue, 28 Jan 2003 22:32:21 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15003 for ; Tue, 28 Jan 2003 22:10:33 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0T3BpG25603; Wed, 29 Jan 2003 14:11:51 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0T3E1E07067; Wed, 29 Jan 2003 14:14:02 +1100 (EST) Received: from ericsson.com.au (EFBM100K6Q8F69N [138.85.177.127]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ3550JJ; Wed, 29 Jan 2003 14:13:57 +1100 Message-ID: <3E3746E9.8000607@ericsson.com.au> Date: Wed, 29 Jan 2003 14:13:45 +1100 From: Brian Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kuntal Chowdhury CC: nsis@ietf.org Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt References: <3E35B6ED.8020301@iqmail.net> In-Reply-To: <3E35B6ED.8020301@iqmail.net> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Kuntal. I would suggest some small tweaking in the wording as follows (the changes are in the parts between the <>): 2) The IP signaling messages are initiated by the NSIS initiator and interpreted by the NSIS Forwarder. The most efficient placement of the NSIS Initiator and NSIS Forwarder has not been determined in 3G wireless networks, but a few potential scenarios can be envisioned. The NSIS Initiator could be located at the End Host e.g. UE or MS (triggered by applications), the Access Gateway or at a node that is not directly on the data path, such as a policy server. The Access Gateway could act as a proxy NSIS Initiator on behalf of the UE/MS or an End Host. The Policy per-flow/aggregate resources within its QoS domain (e.g. the 3G wireless network) may act as a proxy NSIS Initiator for the UE/MS or the Access Gateway. Depending on the placement of the NSIS Initiator, the NSIS Forwarder may be located at an appropriate point in the 3G wireless network. 10.3 An example scenario for a 3G wireless network The 3G wireless access scenario is shown in Figure 1. The Proxy-Call State Control Function (P-CSCF) is the outbound SIP proxy (only used in IMS). The Access Gateway is the egress router of the 3G wireless domain and it connects the radio access network to the Edge Router (ER) of the backbone IP network. /brian Kuntal Chowdhury wrote: > Hi all, > Here is an attempt to generalize the scope of NSIS in 3G wireless > networks. The following is the suggested update/re-write of section > 10.2 and 10.3. > > Issue Name: 7 > Submitter name: Louis-Nicolas Hamer and Kuntal Chowdhury > Submitter email address: nhamer@nortelnetworks.com > Date first submitted: 22/01/2003 > Reference: none > Document: draft-ietf-nsis-req-06.txt > Comment type: T > Priority: 2 > Section: 10.2 & 10.3 > > Proposed text: > > 10.2 3G Wireless Networks > > In this scenario, the user is using the packet services of a 3rd > generation wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The > region between the End Host and the Edge Node (Edge Router) > connecting the wireless network to another QoS domain is considered > to be a single QoS domain. > > The issues in such an environment regarding QoS include: > > 1) 3G wireless networks provide their own QoS technology with > specialized parameters to co-ordinate the QoS provided by both the > radio access and wired access networks. Provisioning of QoS > technologies within a 3G wireless network can be described mainly > in terms of calling bearer classes, service options and service > instances. These QoS technologies need to be invoked with suitable > parameters when higher layers trigger a request for QoS. Therefore > these involve mapping of the requested higher layer QoS parameters > onto specific bearer classes or service instances. The request for > allocation of resources might be triggered by signaling at the IP > level that passes across the wireless system, and possibly other > QoS domains. Typically, wireless network specific messages are > invoked to setup the underlying bearer classes or service instances > in parallel with the IP layer QoS negotiation, to allocate resources > within the radio access network. > > 2) The IP signaling messages are initiated by the NSIS initiator and > interpreted by the NSIS Forwarder. The most efficient placement of the > NSIS Initiator and NSIS Forwarder has not been determined in 3G > wireless > networks, but a few potential scenarios can be envisioned. The NSIS > Initiator could be located at the End Host e.g. UE or MS (triggered by > applications), the Access Gateway or at a node that is not directly on > the data path, such as a policy server. The Access Gateway could > act as > a proxy NSIS Initiator on behalf of the UE/MS or an End Host. The > Policy > Server that manages per-flow/aggregate resources within its QoS domain > (e.g. the 3G wireless network) may act as a proxy NSIS Initiator > for the > UE/MS or the Access Gateway. Depending on the placement of the NSIS > Initiator, the NSIS Forwarder may be located at an appropriate > point in the 3G wireless network. > > 3) The need for re-negotation of the resource needs in a new 3G > wireless > domain due to UE/MS mobility. In this case the NSIS Initiators and the > NSIS Forwarders will have to detect mobility events and trigger > re-negotiation of resources autonomously. > > > 10.3 An example scenario for a 3G wireless network > > The 3G wireless access scenario is shown in Figure 1. The Proxy-Call > State Control Function (P-CSCF) is the outbound SIP proxy (only used > in IMS). The Access Gateway is the egress router of the 3G wireless > domain and it connects the radio access network to the Edge Router > (ER) of the backbone IP network. The Policy Server is the entity > responsible for managing the resource allocations/de-allocations in > the 3G wireless domain. It is also responsible for the policy-based > control of the end-user service. The Policy Server also controls the > Access Gateway to open and close the gates and to configure per-flow > policies, i.e. to authorize or forbid user traffic. The P-CSCF (only > used in IMS) and the Access Gateway communicate with the Policy > Server, > for network resource allocation/de-allocation decisions. The User > Equipment (UE) or the Mobile Station (MS) consists of a Mobile > Terminal > (MT) and Terminal Equipment (TE), e.g. a laptop. > > > +--------+ > +--------->| P-CSCF |-------> SIP signaling > / +--------+ > / SIP | > | +--------+ > | | Policy | +----------------+ > | | Server |<------->| NSIS Forwarder |<---> > | +--------+ +----------------+ > | | ^ > | |COPS | > | | | > +------+ +---------+ | > | UE/MS|----------| Access |<-----------+ +----+ > +------+ | Gateway |----------------------| ER | > +---------+ +----+ > > Figure 1: 3G wireless access scenario > > The Policy Server has all the required QoS information for per-flow > or aggregate admission control in 3G wireless networks. It receives > resource allocation/de-allocation requests from the P-CSCF and/or > Access Gateway etc. and responds with policy decisions. Hence the > Policy Server may be a candidate entity to host the functionality > of the NSIS Initiator, initiating the "NSIS" QoS signaling towards the > core IP network. On the other hand, the UE/MS may act as the NSIS > Initiator or the Access Gateway may act as a Proxy NSIS Initiator > on behalf of the UE/MS. In the former case, the P-CSCF/Policy Server > has to do the mapping from codec types and media descriptors (derived > from SIP/SDP signaling) to IP traffic descriptor. In the latter > case, the UE/MS may use any appropriate QoS signaling mechanism as the > NSIS Initiator. If the Access Gateway is acting as the Proxy > NSIS initiator on behalf of the UE/MS, then it may have to do the > mapping of parameters from radio access specific QoS to IP QoS > traffic parameters before forwarding the request to the NSIS > Forwarder. > > The NSIS Forwarder is currently not part of the standard 3G wireless > architecture. However, to achieve end-to-end QoS a NSIS Forwarder is > needed such that the NSIS Initiators can request a QoS connection to > the IP network. As in the previous example, the NSIS Forwarder > could manage a set of pre-provisioned resources in the IP network, > i.e. bandwidth pipes, and the NSIS Forwarder performs per-flow > admission > control into these pipes. In this way, a connection can be made > between > two 3G wireless access networks, and hence, end-to-end QoS can be > achieved. In this case the NSIS Initiator and NSIS Forwarder are > clearly two separate logical entities. The Access Gateway or/and the > Edge Router in Fig.1 may contain the NSIS Forwarder functionality, > depending upon the placement of the NSIS Initiator as discussed in > scenario 2 in section 10.2. This use case clearly illustrates the need > for an "NSIS" QoS signaling protocol between NSIS Initiator and NSIS > Forwarder. An important application of such a protocol may be its use > in the end-to-end establishment of a connection with specific QoS > characteristics between a mobile host and another party (e.g. end host > or content server). > > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Jan 29 09:16:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20020 for ; Wed, 29 Jan 2003 09:16:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TEbt329677 for nsis-archive@odin.ietf.org; Wed, 29 Jan 2003 09:37:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TEbmJ29670; Wed, 29 Jan 2003 09:37:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TEabJ28982 for ; Wed, 29 Jan 2003 09:36:37 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19946 for ; Wed, 29 Jan 2003 09:14:37 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0TEI8KV027543; Wed, 29 Jan 2003 15:18:09 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7M4HD2N; Wed, 29 Jan 2003 15:18:08 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Jan 2003 15:18:08 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB894@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 400b3c4c 9ffcebbb af2b1b25 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Wed, 29 Jan 2003 15:15:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert First of all I would like to mention that I am in favor of using (a migrating version of) RSVP as NTLP. Meaning that NTLP should mainly support the transport layer features that are at the moment supported by RSVP, while transport layer features that are not supported by RSVP should not be supported by the NTLP. Please see my further comments in line: >> there seems to be either agreement or at least no disagreement that >> *) the NTLP shouldn't have much more interesting message types >> than 'send data' (i.e. shouldn't have a 'reserve' message for example) Yes, but a certain message for example could be used for "reserve" and "refresh" of a NTLP state and another one for "teardown" of the NTLP state. >> *) the NTLP at one node should be able to use information visible >> at 'its' layer to send a message to the next NTLP node, rather >> than relying on the upper layer to work out routing If the way of using this information is similar to the way used by RSVP, i.e., path-coupled signaling, then I agree! >> *) the NTLP shouldn't have concepts of sender or receiver >> 'initiation' e.g. of a signaling transaction; it only needs >> to discover its peers downstream but may need to be able to send messages upstream as well. >> (see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02315.html >> for more details). Agree! >> as well as these, there is at least in my head a basic assumption that >> traditional transport-layer like functionality (segmentation, congestion >> control, all the different aspects of reliability and so on) should be in >> the NTLP. On the other hand, some people clearly have doubts about >> whether these properties are needed for NSIS signalling at all. I think that such transport-layer like functions should not be a part of the NTLP! Such functions should be accomplished as much as possible by NSLPs. NTLP should mainly support the transport layer features that are at the moment supported by RSVP, while transport layer features that are not supported by RSVP should not be supported by the NTLP. >> there are some more difficult questions, where views diverge more strongly: >> *) can we assume that NSLP peers are connected by a single NTLP 'hop' or >> might the connection run over more than one 'hop' concatenated >> together? (not assuming a connection oriented model here, just couldn't >> think of a better word.) does this non-end-to-end-ness of the >> NTLP restrict what functionality we should attempt to give it? If we want to develop a flexible NTLP that can be used by different NSLPs I think that we should allow that the connection between two NSLP peers runs over more than one NTLP "hop". >> *) should the NTLP provide a state management service to signalling >> applications (crudely, should it provide a capability like 'create >> some state over there' or should it just provide the capability 'send >> some data over there')? some people think 'obviously yes' some think 'obviously no'. >> (see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02389.html) If we consider that the connection between two NSLP peers runs over more than one NTLP "hop" then I think that the NTLP should be able to provide "NTLP" state management. Now regarding the state management service to signaling applications, I think that it should be left open. A signaling application may use either the NTLP state management or provide its own state management. >> *) should the NTLP contain some flow identification information >> similar to the 5-tuple or not (for NAT and policy routing reasons)? >> the framework currently says yes, but there have been objections. >> (see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02394.html). If the NTLP will provide "NTLP" soft state management then I think that flow identification and state identification information will be necessary! Moreover, you need the flow identification to be able to differentiate between different signaling applications that are running on the same node and are supported by the NTLP. >> In addition, there are things we haven't really discussed at all >> yet in the context of layer splitting; in particular, the role (or not) >> of the NTLP in scoping where messages are allowed to go, detecting >> and handling mobility events, what gets modified to cope with the >> path-decoupled case, error and failure condition detection and handling. Again, NTLP should mainly support the transport layer features that are at the moment supported by RSVP while transport layer features that are not supported by RSVP should not be supported by the NTLP. Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jan 29 09:50:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20637 for ; Wed, 29 Jan 2003 09:50:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TFBv531953 for nsis-archive@odin.ietf.org; Wed, 29 Jan 2003 10:11:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TFBkJ31938; Wed, 29 Jan 2003 10:11:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TF8TJ31804 for ; Wed, 29 Jan 2003 10:08:29 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20575 for ; Wed, 29 Jan 2003 09:46:29 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0TEnwAv011192; Wed, 29 Jan 2003 15:49:58 +0100 (MET) 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.2655.55) id DY52HDW9; Wed, 29 Jan 2003 15:49:58 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Jan 2003 15:49:58 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB895@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: f71e34fb 9ffcebbb af2b1b25 00000138 From: "Georgios Karagiannis (ELN)" To: "'Henning Schulzrinne'" Cc: "'Hancock, Robert'" , nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Wed, 29 Jan 2003 15:46:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi >> First of all I would like to mention that I am in favor >> of using (a migrating version of) RSVP as NTLP. >> Meaning that NTLP should mainly support the transport >> layer features that are at the moment supported by RSVP, >> while transport layer features that are not supported by >> RSVP should not be supported by the NTLP. > >It would be helpful for the discussion if you could state a technical >reason for this opinion. In my opinion we should try to reuse as much as possible the existing transport layer solutions provided by RSVP. In this way we could reuse the current RSVP design experience and RSVP protocol specification and shorten the time that is needed to standardize NTLP. I think that the flexibility and modularity requirement can be fulfilled by the two level architecture concept. New features will have to be supported by NSLPs. Of course we could try to invent a completely new protocol that will be able to support many features, and which probably will not be deployed on a large scale. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jan 29 10:50:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22346 for ; Wed, 29 Jan 2003 10:50:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TGCDm03877 for nsis-archive@odin.ietf.org; Wed, 29 Jan 2003 11:12:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TGBvJ03844; Wed, 29 Jan 2003 11:11:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TEn1J30198 for ; Wed, 29 Jan 2003 09:49:01 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20221 for ; Wed, 29 Jan 2003 09:27:02 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0TEUUPI003494 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Jan 2003 09:30:31 -0500 (EST) Message-ID: <3E37E597.5080408@cs.columbia.edu> Date: Wed, 29 Jan 2003 09:30:47 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" CC: "'Hancock, Robert'" , nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: <2B06CD3FC17AF64587BC7A7617B230C0CBB894@enleent103.nl.eu.ericsson.se> In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB894@enleent103.nl.eu.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > First of all I would like to mention that I am in favor > of using (a migrating version of) RSVP as NTLP. > Meaning that NTLP should mainly support the transport > layer features that are at the moment supported by RSVP, > while transport layer features that are not supported by > RSVP should not be supported by the NTLP. > It would be helpful for the discussion if you could state a technical reason for this opinion. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jan 29 15:24:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28747 for ; Wed, 29 Jan 2003 15:24:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TKkMj21545 for nsis-archive@odin.ietf.org; Wed, 29 Jan 2003 15:46:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TKiaJ21461; Wed, 29 Jan 2003 15:44:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TKh4J21402 for ; Wed, 29 Jan 2003 15:43:04 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28683 for ; Wed, 29 Jan 2003 15:20:56 -0500 (EST) Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0TKOJp11714; Wed, 29 Jan 2003 14:24:22 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c001.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXY6R1CQ; Wed, 29 Jan 2003 14:24:20 -0600 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DRS1XFAM; Wed, 29 Jan 2003 14:24:19 -0600 Message-ID: <3E38374F.6010202@iqmail.net> Date: Wed, 29 Jan 2003 14:19:27 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Williams CC: nsis@ietf.org Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt References: <3E35B6ED.8020301@iqmail.net> <3E3746E9.8000607@ericsson.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Brian, Yes, I agree with your updates. I will revise the proposed text with your comments. Regards, Kuntal Brian Williams wrote: > Hi Kuntal. > I would suggest some small tweaking in the wording as follows (the > changes are in the parts between the <>): > > 2) The IP signaling messages are initiated by the NSIS initiator and > interpreted by the NSIS Forwarder. The most efficient placement of the > NSIS Initiator and NSIS Forwarder has not been determined in 3G wireless > networks, but a few potential scenarios can be envisioned. The NSIS > Initiator could be located at the End Host e.g. UE or MS (triggered by > applications), the Access Gateway or at a node that is not directly on > the data path, such as a policy server. The Access Gateway could act as > a proxy NSIS Initiator on behalf of the UE/MS or an End Host. The Policy > per-flow/aggregate resources respect to the session> within its QoS domain (e.g. the 3G wireless > network) may act as a proxy NSIS Initiator for the UE/MS or the Access > Gateway. Depending on the placement of the NSIS Initiator, the NSIS > Forwarder may be located at an appropriate point in the 3G wireless > network. > > 10.3 An example scenario for a 3G wireless network > > The 3G wireless access scenario is shown in Figure 1. The Proxy-Call > State Control Function (P-CSCF) is the outbound SIP proxy (only used in > IMS). The Access Gateway is the egress router of the 3G wireless domain > and it connects the radio access network to the Edge Router (ER) of the > backbone IP network. responsible for controlling bearer level resource > allocations/de-allocations in relation to session level services eg SIP. > The Policy Decision Function may also control the Access Gateway to open > and close the gates and to configure per-flow policies, i.e. to > authorize or forbid user traffic.> > /brian > > Kuntal Chowdhury wrote: > >> Hi all, >> Here is an attempt to generalize the scope of NSIS in 3G wireless >> networks. The following is the suggested update/re-write of section >> 10.2 and 10.3. >> >> Issue Name: 7 >> Submitter name: Louis-Nicolas Hamer and Kuntal Chowdhury >> Submitter email address: nhamer@nortelnetworks.com >> Date first submitted: 22/01/2003 >> Reference: none >> Document: draft-ietf-nsis-req-06.txt >> Comment type: T >> Priority: 2 >> Section: 10.2 & 10.3 >> >> Proposed text: >> >> 10.2 3G Wireless Networks >> >> In this scenario, the user is using the packet services of a 3rd >> generation wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The >> region between the End Host and the Edge Node (Edge Router) >> connecting the wireless network to another QoS domain is considered >> to be a single QoS domain. >> >> The issues in such an environment regarding QoS include: >> >> 1) 3G wireless networks provide their own QoS technology with >> specialized parameters to co-ordinate the QoS provided by both the >> radio access and wired access networks. Provisioning of QoS >> technologies within a 3G wireless network can be described mainly >> in terms of calling bearer classes, service options and service >> instances. These QoS technologies need to be invoked with suitable >> parameters when higher layers trigger a request for QoS. Therefore >> these involve mapping of the requested higher layer QoS parameters >> onto specific bearer classes or service instances. The request for >> allocation of resources might be triggered by signaling at the IP >> level that passes across the wireless system, and possibly other >> QoS domains. Typically, wireless network specific messages are >> invoked to setup the underlying bearer classes or service instances >> in parallel with the IP layer QoS negotiation, to allocate resources >> within the radio access network. >> >> 2) The IP signaling messages are initiated by the NSIS initiator and >> interpreted by the NSIS Forwarder. The most efficient placement of the >> NSIS Initiator and NSIS Forwarder has not been determined in 3G >> wireless >> networks, but a few potential scenarios can be envisioned. The NSIS >> Initiator could be located at the End Host e.g. UE or MS (triggered by >> applications), the Access Gateway or at a node that is not directly on >> the data path, such as a policy server. The Access Gateway could >> act as >> a proxy NSIS Initiator on behalf of the UE/MS or an End Host. The >> Policy >> Server that manages per-flow/aggregate resources within its QoS domain >> (e.g. the 3G wireless network) may act as a proxy NSIS Initiator >> for the >> UE/MS or the Access Gateway. Depending on the placement of the NSIS >> Initiator, the NSIS Forwarder may be located at an appropriate >> point in the 3G wireless network. >> >> 3) The need for re-negotation of the resource needs in a new 3G >> wireless >> domain due to UE/MS mobility. In this case the NSIS Initiators and the >> NSIS Forwarders will have to detect mobility events and trigger >> re-negotiation of resources autonomously. >> >> >> 10.3 An example scenario for a 3G wireless network >> >> The 3G wireless access scenario is shown in Figure 1. The Proxy-Call >> State Control Function (P-CSCF) is the outbound SIP proxy (only used >> in IMS). The Access Gateway is the egress router of the 3G wireless >> domain and it connects the radio access network to the Edge Router >> (ER) of the backbone IP network. The Policy Server is the entity >> responsible for managing the resource allocations/de-allocations in >> the 3G wireless domain. It is also responsible for the policy-based >> control of the end-user service. The Policy Server also controls the >> Access Gateway to open and close the gates and to configure per-flow >> policies, i.e. to authorize or forbid user traffic. The P-CSCF (only >> used in IMS) and the Access Gateway communicate with the Policy >> Server, >> for network resource allocation/de-allocation decisions. The User >> Equipment (UE) or the Mobile Station (MS) consists of a Mobile >> Terminal >> (MT) and Terminal Equipment (TE), e.g. a laptop. >> >> >> +--------+ >> +--------->| P-CSCF |-------> SIP signaling >> / +--------+ >> / SIP | >> | +--------+ >> | | Policy | +----------------+ >> | | Server |<------->| NSIS Forwarder |<---> >> | +--------+ +----------------+ >> | | ^ >> | |COPS | >> | | | >> +------+ +---------+ | >> | UE/MS|----------| Access |<-----------+ +----+ >> +------+ | Gateway |----------------------| ER | >> +---------+ +----+ >> >> Figure 1: 3G wireless access scenario >> >> The Policy Server has all the required QoS information for per-flow >> or aggregate admission control in 3G wireless networks. It receives >> resource allocation/de-allocation requests from the P-CSCF and/or >> Access Gateway etc. and responds with policy decisions. Hence the >> Policy Server may be a candidate entity to host the functionality >> of the NSIS Initiator, initiating the "NSIS" QoS signaling towards the >> core IP network. On the other hand, the UE/MS may act as the NSIS >> Initiator or the Access Gateway may act as a Proxy NSIS Initiator >> on behalf of the UE/MS. In the former case, the P-CSCF/Policy Server >> has to do the mapping from codec types and media descriptors (derived >> from SIP/SDP signaling) to IP traffic descriptor. In the latter >> case, the UE/MS may use any appropriate QoS signaling mechanism as the >> NSIS Initiator. If the Access Gateway is acting as the Proxy >> NSIS initiator on behalf of the UE/MS, then it may have to do the >> mapping of parameters from radio access specific QoS to IP QoS >> traffic parameters before forwarding the request to the NSIS >> Forwarder. >> >> The NSIS Forwarder is currently not part of the standard 3G wireless >> architecture. However, to achieve end-to-end QoS a NSIS Forwarder is >> needed such that the NSIS Initiators can request a QoS connection to >> the IP network. As in the previous example, the NSIS Forwarder >> could manage a set of pre-provisioned resources in the IP network, >> i.e. bandwidth pipes, and the NSIS Forwarder performs per-flow >> admission >> control into these pipes. In this way, a connection can be made >> between >> two 3G wireless access networks, and hence, end-to-end QoS can be >> achieved. In this case the NSIS Initiator and NSIS Forwarder are >> clearly two separate logical entities. The Access Gateway or/and the >> Edge Router in Fig.1 may contain the NSIS Forwarder functionality, >> depending upon the placement of the NSIS Initiator as discussed in >> scenario 2 in section 10.2. This use case clearly illustrates the need >> for an "NSIS" QoS signaling protocol between NSIS Initiator and NSIS >> Forwarder. An important application of such a protocol may be its use >> in the end-to-end establishment of a connection with specific QoS >> characteristics between a mobile host and another party (e.g. end host >> or content server). >> >> >> >> >> _______________________________________________ >> 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 mailnull@www1.ietf.org Thu Jan 30 01:40:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10487 for ; Thu, 30 Jan 2003 01:40:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TNXNS00627 for nsis-archive@odin.ietf.org; Wed, 29 Jan 2003 18:33:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TNXFJ00620; Wed, 29 Jan 2003 18:33:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TNWbJ00569 for ; Wed, 29 Jan 2003 18:32:37 -0500 Received: from arb-exchange1.cetaceannetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03116 for ; Wed, 29 Jan 2003 18:10:28 -0500 (EST) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Jan 2003 18:02:03 -0500 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9368D@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Georgios Karagiannis (ELN)'" , "'Hancock, Robert'" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Wed, 29 Jan 2003 18:01:53 -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-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , My 2 cents are in line. Regards, Ilya Freytsis -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Wednesday, January 29, 2003 9:15 AM To: 'Hancock, Robert' Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Hi Robert First of all I would like to mention that I am in favor of using (a migrating version of) RSVP as NTLP. Meaning that NTLP should mainly support the transport layer features that are at the moment supported by RSVP, while transport layer features that are not supported by RSVP should not be supported by the NTLP. Please see my further comments in line: >> there seems to be either agreement or at least no disagreement that >> *) the NTLP shouldn't have much more interesting message types >> than 'send data' (i.e. shouldn't have a 'reserve' message for example) Yes, but a certain message for example could be used for "reserve" and "refresh" of a NTLP state and another one for "teardown" of the NTLP state. >> *) the NTLP at one node should be able to use information visible >> at 'its' layer to send a message to the next NTLP node, rather >> than relying on the upper layer to work out routing If the way of using this information is similar to the way used by RSVP, i.e., path-coupled signaling, then I agree! >> *) the NTLP shouldn't have concepts of sender or receiver >> 'initiation' e.g. of a signaling transaction; it only needs >> to discover its peers downstream but may need to be able to send messages upstream as well. >> (see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02315.html >> for more details). Agree! >> as well as these, there is at least in my head a basic assumption that >> traditional transport-layer like functionality (segmentation, congestion >> control, all the different aspects of reliability and so on) should be in >> the NTLP. On the other hand, some people clearly have doubts about >> whether these properties are needed for NSIS signalling at all. I think that such transport-layer like functions should not be a part of the NTLP! Such functions should be accomplished as much as possible by NSLPs. NTLP should mainly support the transport layer features that are at the moment supported by RSVP, while transport layer features that are not supported by RSVP should not be supported by the NTLP. [Ilya] I would argue that from the strictly layer separation perspective it is beneficial to put as much common transport functionality into NTLP as possible and do not duplicate it in various NSLPs. >> there are some more difficult questions, where views diverge more strongly: >> *) can we assume that NSLP peers are connected by a single NTLP 'hop' or >> might the connection run over more than one 'hop' concatenated >> together? (not assuming a connection oriented model here, just couldn't >> think of a better word.) does this non-end-to-end-ness of the >> NTLP restrict what functionality we should attempt to give it? If we want to develop a flexible NTLP that can be used by different NSLPs I think that we should allow that the connection between two NSLP peers runs over more than one NTLP "hop". >> *) should the NTLP provide a state management service to signalling >> applications (crudely, should it provide a capability like 'create >> some state over there' or should it just provide the capability 'send >> some data over there')? some people think 'obviously yes' some think 'obviously no'. >> (see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02389.html) If we consider that the connection between two NSLP peers runs over more than one NTLP "hop" then I think that the NTLP should be able to provide "NTLP" state management. Now regarding the state management service to signaling applications, I think that it should be left open. A signaling application may use either the NTLP state management or provide its own state management. >> *) should the NTLP contain some flow identification information >> similar to the 5-tuple or not (for NAT and policy routing reasons)? >> the framework currently says yes, but there have been objections. >> (see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02394.html). If the NTLP will provide "NTLP" soft state management then I think that flow identification and state identification information will be necessary! Moreover, you need the flow identification to be able to differentiate between different signaling applications that are running on the same node and are supported by the NTLP. [Ilya] I am not sure that I follow to Georgios' logic here but I share the rational in Robert's message (referenced above) for having "flow routing information" in NTLP. >> In addition, there are things we haven't really discussed at all >> yet in the context of layer splitting; in particular, the role (or not) >> of the NTLP in scoping where messages are allowed to go, detecting >> and handling mobility events, what gets modified to cope with the >> path-decoupled case, error and failure condition detection and handling. Again, NTLP should mainly support the transport layer features that are at the moment supported by RSVP while transport layer features that are not supported by RSVP should not be supported by the NTLP. Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 30 01:41:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10542 for ; Thu, 30 Jan 2003 01:41:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TMcPO30179 for nsis-archive@odin.ietf.org; Wed, 29 Jan 2003 17:38:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TMcBJ30160; Wed, 29 Jan 2003 17:38:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TMZrJ29460 for ; Wed, 29 Jan 2003 17:35:53 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02115 for ; Wed, 29 Jan 2003 17:13:43 -0500 (EST) Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0TMHCp24354 for ; Wed, 29 Jan 2003 16:17:12 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c001.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXY6RFL0; Wed, 29 Jan 2003 16:17:12 -0600 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DRS1XFCF; Wed, 29 Jan 2003 16:17:12 -0600 Message-ID: <3E3851C4.30806@iqmail.net> Date: Wed, 29 Jan 2003 16:12:20 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt References: <3E35B6ED.8020301@iqmail.net> <3E3746E9.8000607@ericsson.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Here is the updated text for issue# 7. I incorporated the comments from Maarten and Brian. ------------------------------------------------------------------------------ 10.2 3G Wireless Networks In this scenario, the user is using the packet services of a 3rd generation wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The region between the End Host and the Edge Node (Edge Router) connecting the wireless network to another QoS domain is considered to be a single QoS domain. The issues in such an environment regarding QoS include: 1) 3G wireless networks provide their own QoS technology with specialized parameters to co-ordinate the QoS provided by both the radio access and wired access networks. Provisioning of QoS technologies within a 3G wireless network can be described mainly in terms of calling bearer classes, service options and service instances. These QoS technologies need to be invoked with suitable parameters when higher layers trigger a request for QoS. Therefore these involve mapping of the requested higher layer QoS parameters onto specific bearer classes or service instances. The request for allocation of resources might be triggered by signaling at the IP level that passes across the wireless system, and possibly other QoS domains. Typically, wireless network specific messages are invoked to setup the underlying bearer classes or service instances in parallel with the IP layer QoS negotiation, to allocate resources within the radio access network. 2) The IP signaling messages are initiated by the NSIS initiator and interpreted by the NSIS Forwarder. The most efficient placement of the NSIS Initiator and NSIS Forwarder has not been determined in 3G wireless networks, but a few potential scenarios can be envisioned. The NSIS Initiator could be located at the End Host e.g. UE or MS (triggered by applications), the Access Gateway or at a node that is not directly on the data path, such as a Policy Decision Function. The Access Gateway could act as a proxy NSIS Initiator on behalf of the UE/MS or an End Host. The Policy Decision Function that controls per-flow/aggregate resources with respect to the session within its QoS domain (e.g. the 3G wireless network) may act as a proxy NSIS Initiator for the UE/MS or the Access Gateway. Depending on the placement of the NSIS Initiator, the NSIS Forwarder may be located at an appropriate point in the 3G wireless network. 3) The need for re-negotiation of resources in a new 3G wireless domain due to UE/MS mobility. In this case the NSIS Initiator and the NSIS Forwarder should detect mobility events and autonomously trigger re-negotiation of resources. 10.3 An example scenario for 3G wireless networks The 3G wireless access scenario is shown in Figure 1. The Proxy-Call State Control Function (P-CSCF) is the outbound SIP proxy (only used in IMS). The Access Gateway is the egress router of the 3G wireless domain and it connects the radio access network to the Edge Router (ER) of the backbone IP network. The Policy Decision Function (PDF)is an entity responsible for controlling bearer level resource allocations/ de-allocations in relation to session level services e.g. SIP. The Policy Decision Function may also control the Access Gateway to open and close the gates and to configure per-flow policies, i.e. to authorize or forbid user traffic. The P-CSCF (only used in IMS) and the Access Gateway communicate with the Policy Decision Function, for network resource allocation/de-allocation decisions. The User Equipment (UE) or the Mobile Station (MS) consists of a Mobile Terminal (MT) and Terminal Equipment (TE), e.g. a laptop. +--------+ +--------->| P-CSCF |---------> SIP signaling / +--------+ / SIP | | | | +-----+ +----------------+ | | PDF |<---------->| NSIS Forwarder |<---> | +-----+ +----------------+ | | ^ | | | | | | | |COPS | | | | +------+ +---------+ | | UE/MS|----------| Access |<-----------+ +----+ +------+ | Gateway |------------------| ER | +---------+ +----+ Figure 1: 3G wireless access scenario The PDF has all the required QoS information for per-flow or aggregate admission control in 3G wireless networks. It receives resource allocation/de-allocation requests from the P-CSCF and/or Access Gateway etc. and responds with policy decisions. Hence the PDF may be a candidate entity to host the functionality of the NSIS Initiator, initiating the "NSIS" QoS signaling towards the backbone IP network. On the other hand, the UE/MS may act as the NSIS Initiator or the Access Gateway may act as a Proxy NSIS Initiator on behalf of the UE/MS. In the former case, the P-CSCF/PDF has to do the mapping from codec types and media descriptors (derived from SIP/SDP signaling) to IP traffic descriptor. In the latter case, the UE/MS may use any appropriate QoS signaling mechanism as the NSIS Initiator. If the Access Gateway is acting as the Proxy NSIS initiator on behalf of the UE/MS, then it may have to do the mapping of parameters from radio access specific QoS to IP QoS traffic parameters before forwarding the request to the NSIS Forwarder. The NSIS Forwarder is currently not part of the standard 3G wireless architecture. However, to achieve end-to-end QoS a NSIS Forwarder is needed such that the NSIS Initiators can request a QoS connection to the IP network. As in the previous example, the NSIS Forwarder could manage a set of pre-provisioned resources in the IP network, i.e. bandwidth pipes, and the NSIS Forwarder performs per-flow admission control into these pipes. In this way, a connection can be made between two 3G wireless access networks, and hence, end-to-end QoS can be achieved. In this case the NSIS Initiator and NSIS Forwarder are clearly two separate logical entities. The Access Gateway or/and the Edge Router in Fig.1 may contain the NSIS Forwarder functionality, depending upon the placement of the NSIS Initiator as discussed in scenario 2 in section 10.2. This use case clearly illustrates the need for an "NSIS" QoS signaling protocol between NSIS Initiator and NSIS Forwarder. An important application of such a protocol may be its use in the end-to-end establishment of a connection with specific QoS characteristics between a mobile host and another party (e.g. end host or content server). --------------------------------------------------------------------------------- -Kuntal Brian Williams wrote: > Hi Kuntal. > I would suggest some small tweaking in the wording as follows (the > changes are in the parts between the <>): > > 2) The IP signaling messages are initiated by the NSIS initiator and > interpreted by the NSIS Forwarder. The most efficient placement of the > NSIS Initiator and NSIS Forwarder has not been determined in 3G wireless > networks, but a few potential scenarios can be envisioned. The NSIS > Initiator could be located at the End Host e.g. UE or MS (triggered by > applications), the Access Gateway or at a node that is not directly on > the data path, such as a policy server. The Access Gateway could act as > a proxy NSIS Initiator on behalf of the UE/MS or an End Host. The Policy > per-flow/aggregate resources respect to the session> within its QoS domain (e.g. the 3G wireless > network) may act as a proxy NSIS Initiator for the UE/MS or the Access > Gateway. Depending on the placement of the NSIS Initiator, the NSIS > Forwarder may be located at an appropriate point in the 3G wireless > network. > > 10.3 An example scenario for a 3G wireless network > > The 3G wireless access scenario is shown in Figure 1. The Proxy-Call > State Control Function (P-CSCF) is the outbound SIP proxy (only used in > IMS). The Access Gateway is the egress router of the 3G wireless domain > and it connects the radio access network to the Edge Router (ER) of the > backbone IP network. responsible for controlling bearer level resource > allocations/de-allocations in relation to session level services eg SIP. > The Policy Decision Function may also control the Access Gateway to open > and close the gates and to configure per-flow policies, i.e. to > authorize or forbid user traffic.> > /brian > > Kuntal Chowdhury wrote: > >> Hi all, >> Here is an attempt to generalize the scope of NSIS in 3G wireless >> networks. The following is the suggested update/re-write of section >> 10.2 and 10.3. >> >> Issue Name: 7 >> Submitter name: Louis-Nicolas Hamer and Kuntal Chowdhury >> Submitter email address: nhamer@nortelnetworks.com >> Date first submitted: 22/01/2003 >> Reference: none >> Document: draft-ietf-nsis-req-06.txt >> Comment type: T >> Priority: 2 >> Section: 10.2 & 10.3 >> >> Proposed text: >> >> 10.2 3G Wireless Networks >> >> In this scenario, the user is using the packet services of a 3rd >> generation wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The >> region between the End Host and the Edge Node (Edge Router) >> connecting the wireless network to another QoS domain is considered >> to be a single QoS domain. >> >> The issues in such an environment regarding QoS include: >> >> 1) 3G wireless networks provide their own QoS technology with >> specialized parameters to co-ordinate the QoS provided by both the >> radio access and wired access networks. Provisioning of QoS >> technologies within a 3G wireless network can be described mainly >> in terms of calling bearer classes, service options and service >> instances. These QoS technologies need to be invoked with suitable >> parameters when higher layers trigger a request for QoS. Therefore >> these involve mapping of the requested higher layer QoS parameters >> onto specific bearer classes or service instances. The request for >> allocation of resources might be triggered by signaling at the IP >> level that passes across the wireless system, and possibly other >> QoS domains. Typically, wireless network specific messages are >> invoked to setup the underlying bearer classes or service instances >> in parallel with the IP layer QoS negotiation, to allocate resources >> within the radio access network. >> >> 2) The IP signaling messages are initiated by the NSIS initiator and >> interpreted by the NSIS Forwarder. The most efficient placement of the >> NSIS Initiator and NSIS Forwarder has not been determined in 3G >> wireless >> networks, but a few potential scenarios can be envisioned. The NSIS >> Initiator could be located at the End Host e.g. UE or MS (triggered by >> applications), the Access Gateway or at a node that is not directly on >> the data path, such as a policy server. The Access Gateway could >> act as >> a proxy NSIS Initiator on behalf of the UE/MS or an End Host. The >> Policy >> Server that manages per-flow/aggregate resources within its QoS domain >> (e.g. the 3G wireless network) may act as a proxy NSIS Initiator >> for the >> UE/MS or the Access Gateway. Depending on the placement of the NSIS >> Initiator, the NSIS Forwarder may be located at an appropriate >> point in the 3G wireless network. >> >> 3) The need for re-negotation of the resource needs in a new 3G >> wireless >> domain due to UE/MS mobility. In this case the NSIS Initiators and the >> NSIS Forwarders will have to detect mobility events and trigger >> re-negotiation of resources autonomously. >> >> >> 10.3 An example scenario for a 3G wireless network >> >> The 3G wireless access scenario is shown in Figure 1. The Proxy-Call >> State Control Function (P-CSCF) is the outbound SIP proxy (only used >> in IMS). The Access Gateway is the egress router of the 3G wireless >> domain and it connects the radio access network to the Edge Router >> (ER) of the backbone IP network. The Policy Server is the entity >> responsible for managing the resource allocations/de-allocations in >> the 3G wireless domain. It is also responsible for the policy-based >> control of the end-user service. The Policy Server also controls the >> Access Gateway to open and close the gates and to configure per-flow >> policies, i.e. to authorize or forbid user traffic. The P-CSCF (only >> used in IMS) and the Access Gateway communicate with the Policy >> Server, >> for network resource allocation/de-allocation decisions. The User >> Equipment (UE) or the Mobile Station (MS) consists of a Mobile >> Terminal >> (MT) and Terminal Equipment (TE), e.g. a laptop. >> >> >> +--------+ >> +--------->| P-CSCF |-------> SIP signaling >> / +--------+ >> / SIP | >> | +--------+ >> | | Policy | +----------------+ >> | | Server |<------->| NSIS Forwarder |<---> >> | +--------+ +----------------+ >> | | ^ >> | |COPS | >> | | | >> +------+ +---------+ | >> | UE/MS|----------| Access |<-----------+ +----+ >> +------+ | Gateway |----------------------| ER | >> +---------+ +----+ >> >> Figure 1: 3G wireless access scenario >> >> The Policy Server has all the required QoS information for per-flow >> or aggregate admission control in 3G wireless networks. It receives >> resource allocation/de-allocation requests from the P-CSCF and/or >> Access Gateway etc. and responds with policy decisions. Hence the >> Policy Server may be a candidate entity to host the functionality >> of the NSIS Initiator, initiating the "NSIS" QoS signaling towards the >> core IP network. On the other hand, the UE/MS may act as the NSIS >> Initiator or the Access Gateway may act as a Proxy NSIS Initiator >> on behalf of the UE/MS. In the former case, the P-CSCF/Policy Server >> has to do the mapping from codec types and media descriptors (derived >> from SIP/SDP signaling) to IP traffic descriptor. In the latter >> case, the UE/MS may use any appropriate QoS signaling mechanism as the >> NSIS Initiator. If the Access Gateway is acting as the Proxy >> NSIS initiator on behalf of the UE/MS, then it may have to do the >> mapping of parameters from radio access specific QoS to IP QoS >> traffic parameters before forwarding the request to the NSIS >> Forwarder. >> >> The NSIS Forwarder is currently not part of the standard 3G wireless >> architecture. However, to achieve end-to-end QoS a NSIS Forwarder is >> needed such that the NSIS Initiators can request a QoS connection to >> the IP network. As in the previous example, the NSIS Forwarder >> could manage a set of pre-provisioned resources in the IP network, >> i.e. bandwidth pipes, and the NSIS Forwarder performs per-flow >> admission >> control into these pipes. In this way, a connection can be made >> between >> two 3G wireless access networks, and hence, end-to-end QoS can be >> achieved. In this case the NSIS Initiator and NSIS Forwarder are >> clearly two separate logical entities. The Access Gateway or/and the >> Edge Router in Fig.1 may contain the NSIS Forwarder functionality, >> depending upon the placement of the NSIS Initiator as discussed in >> scenario 2 in section 10.2. This use case clearly illustrates the need >> for an "NSIS" QoS signaling protocol between NSIS Initiator and NSIS >> Forwarder. An important application of such a protocol may be its use >> in the end-to-end establishment of a connection with specific QoS >> characteristics between a mobile host and another party (e.g. end host >> or content server). >> >> >> >> >> _______________________________________________ >> 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 mailnull@www1.ietf.org Thu Jan 30 04:28:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22930 for ; Thu, 30 Jan 2003 04:28:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0U9oIE17776 for nsis-archive@odin.ietf.org; Thu, 30 Jan 2003 04:50:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U9oAJ17769; Thu, 30 Jan 2003 04:50:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U9m3J17664 for ; Thu, 30 Jan 2003 04:48:03 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22902 for ; Thu, 30 Jan 2003 04:25:40 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0U9TCAv000853; Thu, 30 Jan 2003 10:29:12 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7M4NH3R; Thu, 30 Jan 2003 10:29:12 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 10:19:41 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB896@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 6caf0912 9ffcebbb af2b1b25 00000138 From: "Georgios Karagiannis (ELN)" To: "'Freytsis, Ilya'" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Thu, 30 Jan 2003 10:28:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Ilya Please see my comment in line! >> I think that such transport-layer like functions should not >> be a part of the NTLP! >> Such functions should be accomplished as much as possible by NSLPs. >> NTLP should mainly support the transport layer features >> that are at the moment supported by RSVP, while transport layer features >> that are not supported by RSVP should not be supported by >> the NTLP. [Ilya] I would argue that from the strictly layer separation perspective it is beneficial to put as much common transport functionality into NTLP as possible and do not duplicate it in various NSLPs. I think that we should introduce only the necessary main common transport functionality into NTLP. In my opinion RSVP provides the main transport functionality that we need in NTLP. Features such as segmentation, congestion control, non duplication of signaling messages, etc. are specific and needed for some NSLP type, but not for all NSLP types. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 30 08:28:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27322 for ; Thu, 30 Jan 2003 08:28:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UDoYP32420 for nsis-archive@odin.ietf.org; Thu, 30 Jan 2003 08:50:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDoNJ32411; Thu, 30 Jan 2003 08:50:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDneJ32375 for ; Thu, 30 Jan 2003 08:49:40 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27285 for ; Thu, 30 Jan 2003 08:27:13 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0UDUgKV018135; Thu, 30 Jan 2003 14:30:42 +0100 (MET) 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.2655.55) id DY5SD1PG; Thu, 30 Jan 2003 14:30:42 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 14:29:52 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB897@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 99ba4724 9ffcebbb af2b1b25 00000138 From: "Georgios Karagiannis (ELN)" To: "'Henning Schulzrinne'" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Thu, 30 Jan 2003 14:21:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear Henning Please see my comments in line: [georgios-previous] Features such as segmentation, congestion [georgios-previous] control, non duplication of signaling messages, etc. [georgios-previous] are specific and needed for some NSLP type, [georgios-previous] but not for all NSLP types. [Henning] Can you identify the types that need it and the types that don't? For the moment I would want to mention that the NTLP that I need to use does not need such features. [Henning] Are you advocating that NSLP become a full-fledged transport protocol [Henning] for 'some' NSLP types, essentially an application-layer TCP or SCTP? No, if an application needs TCP or SCTP features, then these applications should probably use the TCP or SCTP protocols, e.g., below NTLP. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 30 09:00:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28710 for ; Thu, 30 Jan 2003 09:00:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UEM3q05436 for nsis-archive@odin.ietf.org; Thu, 30 Jan 2003 09:22:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UELMJ05332; Thu, 30 Jan 2003 09:21:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UEKkJ05171 for ; Thu, 30 Jan 2003 09:20:46 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28573 for ; Thu, 30 Jan 2003 08:58:18 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0UE1mKV028203; Thu, 30 Jan 2003 15:01:48 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7M4PQL6; Thu, 30 Jan 2003 15:01:48 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 15:01:48 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB899@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 1ec77845 9ffcebbb af2b1b25 00000138 From: "Georgios Karagiannis (ELN)" To: "'Henning Schulzrinne'" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Thu, 30 Jan 2003 14:52:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear Henning >> However, your statement does add a requirement to >> NTLP: namely, that it should be able to use either 'raw' IP >> or an existing transport >> mechanism, such as UDP, TCP or SCTP (or possibly one of the emerging >> UDP-like, congestion-controlled protocols being discussed in TSVAREA). Yes I agree! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 30 17:49:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12531 for ; Thu, 30 Jan 2003 17:49:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UMqgJ03209 for nsis-archive@odin.ietf.org; Thu, 30 Jan 2003 17:52:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UMqYJ03199; Thu, 30 Jan 2003 17:52:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UMmAJ03066 for ; Thu, 30 Jan 2003 17:48:10 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12422 for ; Thu, 30 Jan 2003 17:44:26 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 22:47:59 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF671D@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "Georgios Karagiannis (ELN)" , "'Henning Schulzrinne'" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Thu, 30 Jan 2003 22:47:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, some points on terminology and trying to clarify exactly what question is being discussed: 1. The framework describes 'the NSIS transport layer' as *everything* below the signalling application layer and above the IP layer (e.g. figs 2/3). What we (or at least, I) am trying to discover is what functionality should be in this layer, *however* it is structured internally. 2. suggesting that a 'simple' basic NTLP sublayer of some sort could be run over TCP (or SCTP) is a very interesting design constraint for that sublayer. (In the purest form, where the sublayer operates entirely over one or more TCP connections, I suspect it is an engineering impossibility, mainly for addressing/peer discovery reasons. This is one reason why the framework document does not draw such a strict layered picture.) But it's a question about designing the NTLP, *not* what functionality it should encapsulate. (Shameless plug: We have tried to list some of the issues about this and other possible approaches in http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-ntlp-considerations-00.txt.) 3. *Whatever* of these approaches is taken, it doesn't affect the apparent consensus that an NSLP should be able to call on some combination of lower layers (whatever you call them) which provide these classic transport-like functions. (What I get from Georgios is that he'd like them to be somehow optional to use. But I'll write a separate mail on that.) I'd like to proceed on the basis that the assumption in (3) is correct. Cheers, Robert H. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 30 January 2003 13:52 > To: 'Henning Schulzrinne' > Cc: nsis@ietf.org > Subject: RE: [NSIS] layer split summary? opinions? > > > Dear Henning > > >> However, your statement does add a requirement to > >> NTLP: namely, that it should be able to use either 'raw' IP > >> or an existing transport > >> mechanism, such as UDP, TCP or SCTP (or possibly one of > the emerging > >> UDP-like, congestion-controlled protocols being discussed > in TSVAREA). > > Yes I agree! > > Best Regards, > Georgios > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jan 30 17:52:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12605 for ; Thu, 30 Jan 2003 17:52:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UMtO403279 for nsis-archive@odin.ietf.org; Thu, 30 Jan 2003 17:55:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UMtLJ03272; Thu, 30 Jan 2003 17:55:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UMmKJ03073 for ; Thu, 30 Jan 2003 17:48:20 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12425 for ; Thu, 30 Jan 2003 17:44:35 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 22:48:09 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF671E@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "Georgios Karagiannis (ELN)" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Thu, 30 Jan 2003 22:48:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Georgios, all: On the question of whether to include transport features (congestion control, segmentation, etc.) as part of our NTLP work. You previously stated: > For the moment I would want to mention that the NTLP that I need > to use does not need such features. and: > In my opinion we should try to reuse as much as possible > the existing transport layer solutions provided by RSVP. > In this way we could reuse the current RSVP design experience > and RSVP protocol specification and shorten the time that > is needed to standardize NTLP. Firstly, I don't know the full story, but my impression of the 'RSVP[2205] design experience' is that if you don't put these features in at the start, you have to put them in later (rfc2961). [A similar point can be made about security, i.e. 2747.] Secondly, it is frequently stressed that the IETF strives to develop protocols which function robustly in all possible environments, i.e. open networks subject to overload, misconfiguration of individual elements, constrained links, malicious traffic, and so on (see also RFC3426). I don't see this requirement being relaxed just because we are starting from parts of an existing protocol. In other words, even if you don't think you need these features in your protocol today, someone will use it next year in an environment where they do - by which time it could be too late. This has been the experience for other network problems in the past (it's happened in interior and exterior routing protocols, SIP), I don't see why signalling protocols should be immune. Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 31 03:55:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01647 for ; Fri, 31 Jan 2003 03:55:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0V8wjd11310 for nsis-archive@odin.ietf.org; Fri, 31 Jan 2003 03:58:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V8wcJ11302; Fri, 31 Jan 2003 03:58:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V8vpJ11275 for ; Fri, 31 Jan 2003 03:57:51 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01642 for ; Fri, 31 Jan 2003 03:53:54 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h0V8v0604589; Fri, 31 Jan 2003 09:57:21 +0100 (MET) Subject: Re: [NSIS] layer split summary? opinions? To: "Hancock, Robert" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 31 Jan 2003 09:56:58 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/31/2003 09:57:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert, all, Please see some (Georgios/Ilya/Henning-aware) comments inline. Sven "Hancock, Robert" @ietf.org on 28/01/2003 20:48:06 Sent by: nsis-admin@ietf.org To: nsis@ietf.org cc: Subject: [NSIS] layer split summary? opinions? dear all, as christmas fades into the past and the interim meeting looms, i'd like to re-emphasise some of the core questions that need to be considered and resolved to allow us to make progress on the framework, beyond where we are now (and hence are pretty crucial to making protocol progress as well). the most important of these is: where does the NTLP/NSLP boundary lie - in other words (I think) what functionality do we see as both (a) common to a large proportion of 'signalling' problems, and (b) something that has to be implemented 'low down' in the stack for some reason. if anyone has any thoughts at all on any aspects of this question, now would be a good time to raise them, especially if you disagree with any of the directions implied in the (rather long) summary below. personally, i'd like to see the way forward on these questions finalised - at least in broad outline - in enough time to update documents for IETF#56. cheers, robert h. ========================================= here are some of the facets of this question. there seems to be either agreement or at least no disagreement that *) the NTLP shouldn't have much more interesting message types than 'send data' (i.e. it shouldn't have a 'reserve' message for example) [Sven] I agree. *) the NTLP at one node should be able to use information visible at 'its' layer to send a message to the next NTLP node, rather than relying on the upper layer to work out routing [Sven] I agree. I am just wondering here if whatever processing happens at the NSLP layer can change the destination address for the NTLP. In other words, does the interface between NSLP and NTLP allow updating NTLP objects/fields? *) the NTLP shouldn't have concepts of sender or receiver 'initiation' e.g. of a signalling transaction; it only needs to discover its peers downstream but may need to be able to send messages upstream as well. (see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02315.html for more details). [Sven] I agree with the first sentence. I am not so sure about the second part. This is obviously used for reverse routing the message over the forward path but I think this will definitely not be needed for all NSLPs. Also, does it imply keeping state or could it also mean that NTLP would support some kind of record/explicit route object as well as these, there is at least in my head a basic assumption that traditional transport-layer like functionality (segmentation, congestion control, all the different aspects of reliability and so on) should be in the NTLP. On the other hand, some people clearly have doubts about whether these properties are needed for NSIS signalling at all. there are some more difficult questions, where views diverge more strongly: *) can we assume that NSLP peers are connected by a single NTLP 'hop' or might the connection run over more than one 'hop' concatenated together? (not assuming a connection oriented model here, just couldn't think of a better word.) does this non-end-to-end-ness of the NTLP restrict what functionality we should attempt to give it? [Sven] Does this mean that we need a kind of transparent way to send messages through NTLP peers without looking at them in the NSLP layer (like router alert, or rather the inverse of it). In that case it wouldn't even matter whether there was an NSLP peer above or not. I find the suggestion of non-end-to-endness for NTLP interesting. Does it mean NSLP will always provide the end-to-end aspects? In that case, is it possible that there is a different src/dst @ in NSLP and NTLP? *) should the NTLP provide a state management service to signalling applications (crudely, should it provide a capability like 'create some state over there' or should it just provide the capability 'send some data over there')? some people think 'obviously yes' some think 'obviously no'. (see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02389.html) [Sven] I would be inclined to say no. I would say NTLP just gets a message from A to B without leaving intermediate state. *) should the NTLP contain some flow identification information similar to the 5-tuple or not (for NAT and policy routing reasons)? the framework currently says yes, but there have been objections. (see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02394.html ). [Sven] I would say yes for the reasons you point out (NAT, ...) I am wondering however how potential NSLP objects are treated if this happens. In addition, there are things we haven't really discussed at all yet in the context of layer splitting; in particular, the role (or not) of the NTLP in scoping where messages are allowed to go, detecting and handling mobility events, what gets modified to cope with the path-decoupled case, error and failure condition detection and handling. =================================================================== _______________________________________________ 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 mailnull@www1.ietf.org Fri Jan 31 04:51:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02387 for ; Fri, 31 Jan 2003 04:51:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0V9sQk14620 for nsis-archive@odin.ietf.org; Fri, 31 Jan 2003 04:54:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V9sLJ14611; Fri, 31 Jan 2003 04:54:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V9reJ14573 for ; Fri, 31 Jan 2003 04:53:40 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02353 for ; Fri, 31 Jan 2003 04:49:42 -0500 (EST) 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 h0V9rFAv026630; Fri, 31 Jan 2003 10:53:15 +0100 (MET) 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.2655.55) id DY5SJ5MW; Fri, 31 Jan 2003 10:53:15 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Jan 2003 10:50:07 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB89A@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 4b8d64ca 9ffcebbb 32fc239c 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Fri, 31 Jan 2003 10:52:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert Please see my comment in line! >> Firstly, I don't know the full story, but my impression of >> the 'RSVP[2205] design experience' is that if you don't put >> these features in at the start, you have to put them in later >> (rfc2961). The goal of providing the bundling of messages in RFC 2961 was to mainly reduce the processing overhead requirements of refresh messages. In my opinion if the bundling of refresh messages and the exponential back-off procedures are needed then they could be provided by the NSLP that needs them. Not all NSLPs will need such features. >> [A similar point can be made about security, i.e. 2747.] Regarding RFC2747, I agree! Anyway RFC2205 refers to the RSVP Cryptographic Authentication work that is currently included in RFC2747. >> Secondly, it is frequently stressed that the IETF strives to develop protocols >> which function robustly in all possible environments, i.e. open networks >> subject to overload, misconfiguration of individual elements, constrained >> links, malicious traffic, and so on (see also RFC3426). I don't see this >> requirement being relaxed just because we are starting from parts of an >> existing protocol. >> In other words, even if you don't think you need these features in your >> protocol today, someone will use it next year in an environment where they >> do - by which time it could be too late. This has been the experience for >> other network problems in the past (it's happened in interior and exterior >> routing protocols, SIP), I don't see why signalling protocols should be immune. I agree that NSIS (NTLP + NSLP) in combination with other IETF existing protocols e.g., TCP, SCTP, that can operate below NTLP should function robustly in all possible environments. This does not mean that NTLP should reinvent all the features that TCP or SCTP can provide. In my opinion additional features that have be provided by NSIS (for some environments) and are not supported by TCP, SCTP or NTLP, should be provided by NSLP. Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 31 09:29:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07645 for ; Fri, 31 Jan 2003 09:29:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VEXIN29152 for nsis-archive@odin.ietf.org; Fri, 31 Jan 2003 09:33:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VEXEJ29109; Fri, 31 Jan 2003 09:33:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDS5J30615 for ; Thu, 30 Jan 2003 08:28:05 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26499 for ; Thu, 30 Jan 2003 08:05:39 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0UD984x027975 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jan 2003 08:09:09 -0500 (EST) Message-ID: <3E3923FF.8050709@cs.columbia.edu> Date: Thu, 30 Jan 2003 08:09:19 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" CC: "'Freytsis, Ilya'" , nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: <2B06CD3FC17AF64587BC7A7617B230C0CBB896@enleent103.nl.eu.ericsson.se> In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB896@enleent103.nl.eu.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [Ilya] I would argue that from the strictly layer separation perspective it > is beneficial to put as much common transport functionality into NTLP as > possible and do not duplicate it in various NSLPs. > Features such as segmentation, congestion > control, non duplication of signaling messages, etc. > are specific and needed for some NSLP type, > but not for all NSLP types. Can you identify the types that need it and the types that don't? Are you advocating that NSLP become a full-fledged transport protocol for 'some' NSLP types, essentially an application-layer TCP or SCTP? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 31 09:29:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07659 for ; Fri, 31 Jan 2003 09:29:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VEXJO29174 for nsis-archive@odin.ietf.org; Fri, 31 Jan 2003 09:33:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VEXGJ29124; Fri, 31 Jan 2003 09:33:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UE8oJ01374 for ; Thu, 30 Jan 2003 09:08:50 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27997 for ; Thu, 30 Jan 2003 08:46:22 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0UDnqHA015189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jan 2003 08:49:53 -0500 (EST) Message-ID: <3E392D8B.6040900@cs.columbia.edu> Date: Thu, 30 Jan 2003 08:50:03 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" CC: nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: <2B06CD3FC17AF64587BC7A7617B230C0CBB897@enleent103.nl.eu.ericsson.se> In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB897@enleent103.nl.eu.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > For the moment I would want to mention that the NTLP that I need > to use does not need such features. I'm afraid I can't parse this. > > [Henning] Are you advocating that NSLP become a full-fledged transport protocol > [Henning] for 'some' NSLP types, essentially an application-layer TCP or SCTP? > > No, if an application needs TCP or SCTP features, then these applications > should probably use the TCP or SCTP protocols, e.g., below NTLP. That's what I've been advocating. Part of the discussion problem seems to be that some people say "NTLP" and mean "whatever 'transport' layer NSIS invents including the transport below", others mean "whatever sits on top of either IP or TCP/SCTP". We should agree on one definition. A different way of phrasing the confusion is that some people see NTLP as an interface to the higher layer (NSLP) above - it describes all of the services that the NSIS-new-stuff adds plus any underlying existing transport protocol offers. Other people, possibly guided by the 'P' at the end, see it as a protocol, i.e., describe only the services that this layer adds on top of whatever L3/L4 mechanism is below. The re-use of the word transport can't help but add to misunderstandings, but we probably lack the language supply to fix that particular problem. (We have used the term messaging layer in one context, but that term has its own set of problems.) However, your statement does add a requirement to NTLP: namely, that it should be able to use either 'raw' IP or an existing transport mechanism, such as UDP, TCP or SCTP (or possibly one of the emerging UDP-like, congestion-controlled protocols being discussed in TSVAREA). > > Best Regards, > Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 31 09:29:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07673 for ; Fri, 31 Jan 2003 09:29:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VEXLr29188 for nsis-archive@odin.ietf.org; Fri, 31 Jan 2003 09:33:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VEXHJ29139; Fri, 31 Jan 2003 09:33:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UHg6J17984 for ; Thu, 30 Jan 2003 12:42:06 -0500 Received: from titan.tele.pw.edu.pl (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05171 for ; Thu, 30 Jan 2003 12:38:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by titan.tele.pw.edu.pl (Postfix) with ESMTP id 7D7193B70B for ; Thu, 30 Jan 2003 18:41:58 +0100 (CET) Received: from aquila (zttstaff-dhcp118.tele.pw.edu.pl [194.29.169.118]) by titan.tele.pw.edu.pl (Postfix) with ESMTP id 3342B3B6F2 for ; Thu, 30 Jan 2003 18:40:28 +0100 (CET) Message-ID: <410-220031430174138230@aquila> From: "Art-QoS" To: nsis@ietf.org Date: Thu, 30 Jan 2003 18:41:38 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 titan Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UHg6J17989 Subject: [NSIS] Final deadline for Art-QoS, Architectures for Quality of Service in the Internet Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We apologize if you recieve multiple copies of this message. We would like to inform you that the final paper submission deadline for the Workshop on Architectures for the Quality of Service Internet 2003 is February 6, 2003. You can find further information on the web site www.tele.pw.edu.pl/art-qos _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 31 09:29:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07686 for ; Fri, 31 Jan 2003 09:29:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VEXMg29202 for nsis-archive@odin.ietf.org; Fri, 31 Jan 2003 09:33:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VEXIJ29165; Fri, 31 Jan 2003 09:33:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UNCFJ04463 for ; Thu, 30 Jan 2003 18:12:15 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12909 for ; Thu, 30 Jan 2003 18:07:18 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0UNAE4x024497 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jan 2003 18:10:17 -0500 (EST) Message-ID: <3E39B0DF.4050304@cs.columbia.edu> Date: Thu, 30 Jan 2003 18:10:23 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: "Georgios Karagiannis (ELN)" , nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: <76C92FBBFB58D411AE760090271ED41805DF671E@rsys002a.roke.co.uk> In-Reply-To: <76C92FBBFB58D411AE760090271ED41805DF671E@rsys002a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > In other words, even if you don't think you need these features in > your protocol today, someone will use it next year in an environment > where they do - by which time it could be too late. This has been the > experience for other network problems in the past (it's happened in > interior and exterior routing protocols, SIP), I don't see why > signalling protocols should be immune. While SIP is not a network-layer reservation protocol, I think some of the lessons learned there apply here as well. (While UDP will likely remain part of the protocol, its sphere of use has been shrinking continuously.) - MTU discovery and fragmentation is a pain. Even if you think that the message is small enough to fit 'near' where you are, it might get bigger along the way, as error indications, signatures and other things are added. This makes it very different from a run-of-the-mill IP packet that just gets its TTL bumped. Even if you can estimate the size of the message you send, you don't always know how big the response is going to be. - Even if you can reasonably assume that normal (QOS) signaling traffic is low volume, with retries after failures, this is no longer the case. - Wherever some notion of trust is involved, most systems talk to relatively few other systems in practice, so that the setup overhead for TCP is modest, removing one of the major TCP/SCTP problems that motivated UDP in the case of application-layer signaling. - People like TLS. Yes, you can use IPsec, but once you talk to implementors, nobody wants to rely on it being available and configurable, given a choice. I'm sure there are other lessons and not all apply here, but we should, I believe, look around more recent design efforts in the IETF as well. Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 31 10:40:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09859 for ; Fri, 31 Jan 2003 10:40:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VFi3T01318 for nsis-archive@odin.ietf.org; Fri, 31 Jan 2003 10:44:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VFhjJ01304; Fri, 31 Jan 2003 10:43:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VFgWJ01278 for ; Fri, 31 Jan 2003 10:42:32 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09807 for ; Fri, 31 Jan 2003 10:38:27 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0VFevk28017 for ; Fri, 31 Jan 2003 17:40:57 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 31 Jan 2003 17:41:59 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 31 Jan 2003 17:41:59 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 31 Jan 2003 17:41:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 31 Jan 2003 17:41:58 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLJNa7tVnFRB5SZTC+YAU9HcBeOdQACRtoA To: X-OriginalArrivalTime: 31 Jan 2003 15:41:59.0859 (UTC) FILETIME=[4B05D030:01C2C93F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0VFgWJ01279 Subject: [NSIS] NSIS Interim Meeting Registration Deadline Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, If you are planning on attending the NSIS interim meeting, please send me mail. I need to know an accurate headcount by Tuesday February 4th, in order to ensure we have the proper room arrangements, etc. Also, we can probably eat for one or more of the lunches in the Faculty House (buffet, white table-cloth, no suit/tie required :-)) if people are willing to pay $14: http://www.columbia.edu/cu/fachouse/dining.html Otherwise, there's a self-serve cafeteria with custom-made sandwiches and hot entrees in the next building. So let me know your preference. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jan 31 11:05:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10778 for ; Fri, 31 Jan 2003 11:05:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VG9Sc03043 for nsis-archive@odin.ietf.org; Fri, 31 Jan 2003 11:09:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VG9IJ03034; Fri, 31 Jan 2003 11:09:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VG8xJ03012 for ; Fri, 31 Jan 2003 11:08:59 -0500 Received: from arb-exchange1.cetaceannetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10773 for ; Fri, 31 Jan 2003 11:04:54 -0500 (EST) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Jan 2003 11:09:02 -0500 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9368F@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Henning Schulzrinne'" , "Georgios Karagiannis (ELN)" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Fri, 31 Jan 2003 11:09:02 -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-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, January 30, 2003 8:50 AM To: Georgios Karagiannis (ELN) Cc: nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? That's what I've been advocating. Part of the discussion problem seems to be that some people say "NTLP" and mean "whatever 'transport' layer NSIS invents including the transport below", others mean "whatever sits on top of either IP or TCP/SCTP". We should agree on one definition. A different way of phrasing the confusion is that some people see NTLP as an interface to the higher layer (NSLP) above - it describes all of the services that the NSIS-new-stuff adds plus any underlying existing transport protocol offers. Other people, possibly guided by the 'P' at the end, see it as a protocol, i.e., describe only the services that this layer adds on top of whatever L3/L4 mechanism is below. [Ilya] It seems to me that both definitions and views (since they are related) can be useful depending on what is being discussed. When the NTLP/NSLP split is discussed viewing NTLP as services to NSLP is meaningful. On the other hand one cannot discuss the details of the NTLP behavior independent on what it is sitting on top of. Regards, Ilya Freytsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis