From exim@www1.ietf.org Sat Apr 3 13:14:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28751 for ; Sat, 3 Apr 2004 13:14:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ped-0006Oh-4C for nsis-archive@odin.ietf.org; Sat, 03 Apr 2004 13:14:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33IE3Ar024592 for nsis-archive@odin.ietf.org; Sat, 3 Apr 2004 13:14:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9peb-0006OE-KC; Sat, 03 Apr 2004 13:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9pdx-0006J8-7l for nsis@optimus.ietf.org; Sat, 03 Apr 2004 13:13:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28696 for ; Sat, 3 Apr 2004 13:13:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9pdv-00008H-00 for nsis@ietf.org; Sat, 03 Apr 2004 13:13:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9pcm-00001J-00 for nsis@ietf.org; Sat, 03 Apr 2004 13:12:09 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1B9pcI-0007ib-00 for nsis@ietf.org; Sat, 03 Apr 2004 13:11:38 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i33IBaQ04906; Sat, 3 Apr 2004 20:11:37 +0200 (MEST) Received: from verena (cert-lnxek2-137.esn.sbs.de [149.246.36.137]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i33IBaD26831; Sat, 3 Apr 2004 20:11:36 +0200 (MEST) Message-Id: <200404031811.i33IBaD26831@mail2.siemens.de> From: "Hannes Tschofenig" To: , "'James M. Polk'" Cc: Date: Sat, 3 Apr 2004 20:13:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQZp2EeHZbf9a4cTquwXcL5IqG2VA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] Questions regarding Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 fred, hi james, your draft has recently been mentioned in the nsis wg. i have read the draft and came across a few issues: - the details between the preemption defined in and seem to be a bit different. have you compared them? - in section 2.1 you talk about notifying the end hosts about preemption (somewhere in the network). also section 1.5 says something similar: "All callers on the preempted call must be informed that the call has been preempted, and the call must make way for the higher precedence call." this might be of interest for the qos nslp work in nsis or even for nat/firewall work?? - type 1 encryption what do you consider 'type 1 encryption'? - authorization in section 1.2 you say: "Since the act of preemption or consideration of alternative bandwidth sources is part and parcel of the problem of providing bandwidth, and the authorization step in bandwidth provision also affects the choice of networks that may be authorized to be considered." i am not quite sure what you mean with ... also affects the choice of networks....". could you elaborate? sounds a bit like qos routing. regarding section 2.3.5.2 i suspect that the typical procedure is as follows: a user adds a priority level in his qos request. the authenticated request is processed at the first router and forwarded to the "policy decision point" together with the qos parameters and the indicated priority level. as part of the authorization procedure the request is granted or rejected. if it is granted then the request (including the priority level) is forwarded along the path. is this right? a minor issue: there is a bug in section 2.3.3 - the relationship between ipsec encrypted traffic and rsvp signaling. you might want to take a look at section 5.4 of http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-04.t xt ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 6 10:48:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23003 for ; Tue, 6 Apr 2004 10:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArru-00058d-NL for nsis-archive@odin.ietf.org; Tue, 06 Apr 2004 10:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36Em2HZ019739 for nsis-archive@odin.ietf.org; Tue, 6 Apr 2004 10:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArrt-000589-W5; Tue, 06 Apr 2004 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArr6-00051f-2u for nsis@optimus.ietf.org; Tue, 06 Apr 2004 10:47:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22940 for ; Tue, 6 Apr 2004 10:47:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BArr3-0002tu-00 for nsis@ietf.org; Tue, 06 Apr 2004 10:47:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BArF8-00079w-00 for nsis@ietf.org; Tue, 06 Apr 2004 10:07:59 -0400 Received: from smtp0.libero.it ([193.70.192.33]) by ietf-mx with esmtp (Exim 4.12) id 1BAr2L-0004dj-00 for nsis@ietf.org; Tue, 06 Apr 2004 09:54:45 -0400 Received: from libero.it (172.16.1.107) by smtp0.libero.it (7.0.027-DD01) id 404F12F4003A0C0B for nsis@ietf.org; Tue, 6 Apr 2004 15:54:14 +0200 Date: Tue, 6 Apr 2004 15:54:14 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Elena Scialpi" To: "nsis" X-XaM3-API-Version: 4.1 (B27) X-type: 0 X-SenderIP: 193.204.86.188 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] About GIMPS! Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, In the framework of NSIS there are 2 approaches: -sender= -initiated approach is when the sender of the data flow requests and main= tains the treatment for that flow; -receiver-initiated approach the re= ceiver of the data flow requests and maintains the treatment for tha= t flow. I think that in GIMPS (http://www.ietf.org/internet-drafts/d= raft-ietf-nsis-ntlp-01.txt ) there is only the second approach ( the s= ame approach used in RSVP). What's "Routing State and Messaging Associ= ation Maintainance" in sender-initiated approach ? Thanks for your r= eplies, Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 6 14:32:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15299 for ; Tue, 6 Apr 2004 14:32:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvMO-0001LU-L5 for nsis-archive@odin.ietf.org; Tue, 06 Apr 2004 14:31:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36IVisn005166 for nsis-archive@odin.ietf.org; Tue, 6 Apr 2004 14:31:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvMD-000194-KI; Tue, 06 Apr 2004 14:31:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAtkY-0001dz-P2 for nsis@optimus.ietf.org; Tue, 06 Apr 2004 12:48:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04920 for ; Tue, 6 Apr 2004 12:48:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAtkX-0007Ra-00 for nsis@ietf.org; Tue, 06 Apr 2004 12:48:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAtAt-0006MX-00 for nsis@ietf.org; Tue, 06 Apr 2004 12:11:45 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BAsjz-0002dG-00 for nsis@ietf.org; Tue, 06 Apr 2004 11:43:55 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i36FhqAh008748 for ; Tue, 6 Apr 2004 17:43:52 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Apr 2004 17:43:52 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <2CQB9XMS>; Tue, 6 Apr 2004 17:44:20 +0200 Message-ID: From: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'Elena Scialpi'" , nsis Subject: RE: [NSIS] About GIMPS! Date: Tue, 6 Apr 2004 17:46:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 06 Apr 2004 15:43:52.0411 (UTC) FILETIME=[F62622B0:01C41BED] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 Elena, I do not think so, GIMPS supports sender-initiated signaling application as well. There is an example of operation in 3.3. As I understand, messaging association is needed for connection mode and may be used also for datagram mode transport. But these states can be set for both directions and used in both sender and receiver initiated case. Storing backward routing states are needed for receiver initiated reservation (RSVP-like case). In sender-initiated case storing routing states are probably not needed, unless backward messages have to follow the same path as forward messages. Please tell me if I am not right, best regards, Attila -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Elena Scialpi Sent: Tuesday, April 06, 2004 3:54 PM To: nsis Subject: [NSIS] About GIMPS! Hi all, In the framework of NSIS there are 2 approaches: -sender-initiated approach is when the sender of the data flow requests and maintains the treatment for that flow; -receiver-initiated approach the receiver of the data flow requests and maintains the treatment for that flow. I think that in GIMPS (http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt ) there is only the second approach ( the same approach used in RSVP). What's "Routing State and Messaging Association Maintainance" in sender-initiated approach ? Thanks for your replies, Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 6 14:33:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15427 for ; Tue, 6 Apr 2004 14:33:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvNN-0002Sn-LN for nsis-archive@odin.ietf.org; Tue, 06 Apr 2004 14:32:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36IWjUb009445 for nsis-archive@odin.ietf.org; Tue, 6 Apr 2004 14:32:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvNN-0002SA-Fy; Tue, 06 Apr 2004 14:32:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAu8l-0005gA-0G for nsis@optimus.ietf.org; Tue, 06 Apr 2004 13:13:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07380 for ; Tue, 6 Apr 2004 13:13:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAu8j-0002Xe-00 for nsis@ietf.org; Tue, 06 Apr 2004 13:13:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAtqe-0000OG-00 for nsis@ietf.org; Tue, 06 Apr 2004 12:54:53 -0400 Received: from smtp0.libero.it ([193.70.192.33]) by ietf-mx with esmtp (Exim 4.12) id 1BAtRi-0004IE-00 for nsis@ietf.org; Tue, 06 Apr 2004 12:29:06 -0400 Received: from libero.it (172.16.1.107) by smtp0.libero.it (7.0.027-DD01) id 404F12F4003AA11E; Tue, 6 Apr 2004 18:28:35 +0200 Date: Tue, 6 Apr 2004 18:28:34 +0200 Message-Id: Subject: RE: [NSIS] About GIMPS! MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Elena Scialpi" To: "attila\.bader" Cc: "nsis" X-XaM3-API-Version: 4.1 (B27) X-type: 0 X-SenderIP: 193.204.86.188 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Figure 4 (http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.t= xt ) shows message sequence at state setup. The draft says that Gimp= s-query is sent downstream and Gimps-response upstream. in sender-init= iated case Gimps-query is sent upstream and Gimps-response downstream.=0D = Are you agree with me? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 6 14:35:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15623 for ; Tue, 6 Apr 2004 14:35:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvPf-0004zl-Ge for nsis-archive@odin.ietf.org; Tue, 06 Apr 2004 14:35:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36IZ75h018663 for nsis-archive@odin.ietf.org; Tue, 6 Apr 2004 14:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvPY-0004bz-6X; Tue, 06 Apr 2004 14:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuJ5-0007zH-KA for nsis@optimus.ietf.org; Tue, 06 Apr 2004 13:24:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03136 for ; Tue, 6 Apr 2004 12:32:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAtUz-0005hh-00 for nsis@ietf.org; Tue, 06 Apr 2004 12:32:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAswJ-0003q7-00 for nsis@ietf.org; Tue, 06 Apr 2004 11:56:41 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BAsGS-0007L5-00 for nsis@ietf.org; Tue, 06 Apr 2004 11:13:24 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i36FDNY19233; Tue, 6 Apr 2004 17:13:23 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i36FDNQ01697; Tue, 6 Apr 2004 17:13:23 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 6 Apr 2004 17:12:35 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FA8@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Elena Scialpi'" , nsis Subject: RE: [NSIS] About GIMPS! Date: Tue, 6 Apr 2004 17:13:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 elena, > Hi all, > > > In the framework of NSIS there are 2 approaches: > > -sender-initiated approach is when the sender of the data > flow requests and maintains the > treatment for that flow; > -receiver-initiated approach the receiver of the data flow > requests and maintains the treatment > for that flow. > > I think that in GIMPS > (http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt ) > there is only the second approach ( the same approach used in RSVP). > > What's "Routing State and Messaging Association Maintainance" > in sender-initiated approach ? > you need to take a look at the nslps with regard to their approach dealing with sender- vs. receiver-oriented approaches. if you decouple the authorization aspects from the signaling aspects then the concepts of sender- vs. receiver-initiated "something" are less obvious in a path-coupled signaling protocol. i personally think that the definitions of these two terms is rather fuzzy (even in the framework). with path-coupled signaling only the sender is able to start signaling. 'maintaining the treatment for a flow' is also difficult to understand in the light of our mobility discussions or the recently discussed preemption issues. ciao hannes > > Thanks for your replies, > Elena > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 00:47:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11576 for ; Wed, 7 Apr 2004 00:47:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB4xr-00048Q-S7 for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 00:47:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i374l3Gf015892 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 00:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB4xq-00047Y-VH; Wed, 07 Apr 2004 00:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB4xa-0003y0-IP for nsis@optimus.ietf.org; Wed, 07 Apr 2004 00:46:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11379 for ; Wed, 7 Apr 2004 00:46:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB4xX-0000KB-00 for nsis@ietf.org; Wed, 07 Apr 2004 00:46:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB4KF-0002Cp-00 for nsis@ietf.org; Wed, 07 Apr 2004 00:06:08 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BB3BV-0002dm-00 for nsis@ietf.org; Tue, 06 Apr 2004 22:53:02 -0400 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i372hs86027615; Wed, 7 Apr 2004 10:43:57 +0800 (SGT) From: "Cheng Hong" To: "'Tschofenig Hannes'" , "'Elena Scialpi'" , "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 10:52:12 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <008401c41c4b$53702580$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685FA8@mchp905a.mch.sbs.de> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Hannes, > if you decouple the authorization aspects from the signaling=20 > aspects then > the concepts of sender- vs. receiver-initiated "something"=20 > are less obvious > in a path-coupled signaling protocol. i personally think that the I think if we further decouple the messaging association establishing procedure (GIMPS) from the actual signaling (NSLP signaling), the sender-init vs. receiver-init would be less important. With the current = text in GIMPS, there is still a subtle difference, e.g. in D-mode, = sender-init could send NSLP message with the "GIMPS-query" message.=20 As for the messaging association establishment, it is a GIMPS level signaling. According to the text in section 4.3, it has to be initiated = from upstream. What is lacking is how this process is triggered (maybe out of scope). What I am not so sure is that if it is triggered by a message = sent by the receiver, e.g. a BU from a MN, could we call it receiver = initiated? > definitions of these two terms is rather fuzzy (even in the=20 > framework). with > path-coupled signaling only the sender is able to start signaling. Do you mean the GIMPS signaling described above? I feel it depends on = what we took as "signaling": NSLP or NSLP+NTLP. But, overall (for NTLP and = NSLP), it is quite true. cheers Cheng Hong=20 > 'maintaining the treatment for a flow' is also difficult to=20 > understand in > the light of our mobility discussions or the recently=20 > discussed preemption > issues.=20 >=20 > ciao > hannes >=20 >=20 > >=20 > > Thanks for your replies, > > Elena > > =20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 02:40:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17084 for ; Wed, 7 Apr 2004 02:40:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB6jD-00049R-II for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 02:40:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i376e3VO015956 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 02:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB6jC-00048u-HR; Wed, 07 Apr 2004 02:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB6ia-00042r-O1 for nsis@optimus.ietf.org; Wed, 07 Apr 2004 02:39:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16852 for ; Wed, 7 Apr 2004 02:39:21 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB6iW-0005FD-00 for nsis@ietf.org; Wed, 07 Apr 2004 02:39:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB5ow-0004iY-00 for nsis@ietf.org; Wed, 07 Apr 2004 01:41:55 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BB4aN-0004dd-00 for nsis@ietf.org; Wed, 07 Apr 2004 00:22:47 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i374Mkh29072; Wed, 7 Apr 2004 07:22:47 +0300 (EET DST) X-Scanned: Wed, 7 Apr 2004 07:22:26 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i374MQuv021849; Wed, 7 Apr 2004 07:22:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00qKUqUw; Wed, 07 Apr 2004 07:22:25 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i374MMs03621; Wed, 7 Apr 2004 07:22:23 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Apr 2004 07:22:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2004 07:22:19 +0300 Message-ID: Thread-Topic: GIMPS etc. planning (was: RE: Plans for the protocol drafts) Thread-Index: AcQXKaic3T0IptGkSSKJQEcaiCLjagFLh64g To: , X-OriginalArrivalTime: 07 Apr 2004 04:22:20.0025 (UTC) FILETIME=[EACCF690:01C41C57] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Potential 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: quoted-printable Hi Robert, > *) a review to look for nice-to-have functionality to remove. > *) set up common guidelines on message formats (with the NSLP > people). > *) define some sort of (abstracted) API between NSLPs and > GIMPS (not technically part of the standard but necessary to > clarify some of our thinking). > *) clarify what bits of NAT handling functionality go where > (in conjunction with the NATFW NSLP people), and whether the > NATFW NSLP has any special requirements on GIMPS. > *) start work on some of the error conditions (reboot handling, > last-node problem and so on). That sounds good. =20 > So far as mechanisms for progress are concerned, I can=20 > certainly see the value in something like an interim, if=20 > enough people want to come (I'm less of a fan of wide-open > conference calls until we have really precisely defined > issues to be finalised, but that may just be a personal=20 > issue).=20 >=20 > Siemens would be happy to host such a meeting in Europe, > probably the UK. May is a nice month here, at least=20 > sometimes. In the meantime, any input on the current draft=20 > would of course be appreciated... Is there any interest in an interm meeting? We need to schedule it soon, as there must be a 30 prior announcement of any interim meeting. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 05:36:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02119 for ; Wed, 7 Apr 2004 05:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB9TV-00054X-EJ for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 05:36:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i379a1T7019498 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 05:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB9TU-00053w-DK; Wed, 07 Apr 2004 05:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB9TB-00053a-T4 for nsis@optimus.ietf.org; Wed, 07 Apr 2004 05:35:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02114 for ; Wed, 7 Apr 2004 05:35:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB9T8-0002Zj-00 for nsis@ietf.org; Wed, 07 Apr 2004 05:35:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB8Y6-0002Qp-00 for nsis@ietf.org; Wed, 07 Apr 2004 04:36:43 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BB7J5-0002Bb-00 for nsis@ietf.org; Wed, 07 Apr 2004 03:17:07 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i377H6B18889; Wed, 7 Apr 2004 09:17:06 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i377H5Q24256; Wed, 7 Apr 2004 09:17:06 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 09:16:17 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FAD@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Cheng Hong'" , "'Elena Scialpi'" , "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 09:16:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 cheng, > Hi Hannes, > > > > > if you decouple the authorization aspects from the signaling > > aspects then > > the concepts of sender- vs. receiver-initiated "something" > > are less obvious > > in a path-coupled signaling protocol. i personally think that the > > I think if we further decouple the messaging association establishing > procedure (GIMPS) from the actual signaling (NSLP signaling), the > sender-init vs. receiver-init would be less important. With > the current text > in GIMPS, there is still a subtle difference, e.g. in D-mode, > sender-init > could send NSLP message with the "GIMPS-query" message. i still cannot get used to the d-mode vs. c-mode terminology. anyway, the d-mode vs. c-mode issues are also orthogonal to this discussion. > > As for the messaging association establishment, it is a GIMPS level > signaling. According to the text in section 4.3, it has to be > initiated from > upstream. What is lacking is how this process is triggered > (maybe out of > scope). What I am not so sure is that if it is triggered by a > message sent > by the receiver, e.g. a BU from a MN, could we call it > receiver initiated? this is part of our mobility discussions. i don't know whether we should call something receiver-initiated only if the data receiver triggers some actions (after an initial exchange already took place). in the mobility case we even have scenarios where nodes in the middle could trigger something. > > > > definitions of these two terms is rather fuzzy (even in the > > framework). with > > path-coupled signaling only the sender is able to start signaling. > > Do you mean the GIMPS signaling described above? I feel it > depends on what > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > NTLP and NSLP), > it is quite true. the data sender has to send the first message in nearly all cases. for the receiver-behind a nat things are a bit different but this might not fit into the sender- vs. receiver-initiated "something" terminology either. i suggest to deprecate the sender- and receiver-initiated terminology. what matters at the end is - who has to provide information for authorizion - what is he authorized for - to which entity is authorization required - who triggers reauthorization - what credentials are used for authorization - how long is authorization valid - and finally the different levels of authorization (for qos resource, for triggering certain actions, ... ) since some of these issues have a relationship to mobility i would encourage everyone to take a look at the mobility draft (and the nslps) and to post their opinion. ciao hannes > > > cheers > > Cheng Hong > > > > 'maintaining the treatment for a flow' is also difficult to > > understand in > > the light of our mobility discussions or the recently > > discussed preemption > > issues. > > > > ciao > > hannes > > > > > > > > > > Thanks for your replies, > > > Elena > > > > > > > > > > > > _______________________________________________ > > > 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 exim@www1.ietf.org Wed Apr 7 06:52:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05794 for ; Wed, 7 Apr 2004 06:52:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAf4-0003UC-6o for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 06:52:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Aq2b9013401 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 06:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAf2-0003Tf-RO; Wed, 07 Apr 2004 06:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAf0-0003TF-Jw for nsis@optimus.ietf.org; Wed, 07 Apr 2004 06:51:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05770 for ; Wed, 7 Apr 2004 06:51:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBAew-0001rd-00 for nsis@ietf.org; Wed, 07 Apr 2004 06:51:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB9DV-0000nk-00 for nsis@ietf.org; Wed, 07 Apr 2004 05:19:32 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BB8Ly-0000lb-00 for nsis@ietf.org; Wed, 07 Apr 2004 04:24:10 -0400 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i378FD74008247; Wed, 7 Apr 2004 16:15:16 +0800 (SGT) From: "Cheng Hong" To: "'Tschofenig Hannes'" , "'Elena Scialpi'" , "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 16:23:31 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <000101c41c79$9c691750$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685FAD@mchp905a.mch.sbs.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Hannes, Please see a few more comments inline: > > > > > if you decouple the authorization aspects from the signaling > > > aspects then > > > the concepts of sender- vs. receiver-initiated "something"=20 > > > are less obvious > > > in a path-coupled signaling protocol. i personally think that the > >=20 > > I think if we further decouple the messaging association=20 > establishing=20 > > procedure (GIMPS) from the actual signaling (NSLP signaling), the=20 > > sender-init vs. receiver-init would be less important. With the=20 > > current text in GIMPS, there is still a subtle difference, e.g. in=20 > > D-mode, sender-init > > could send NSLP message with the "GIMPS-query" message.=20 >=20 > i still cannot get used to the d-mode vs. c-mode terminology.=20 > anyway, the d-mode vs. c-mode issues are also orthogonal to=20 > this discussion. True. This has nothing to do with D-mode vs C-mode. It is rather = sender-init vs. receiver-init. For a sender-init case, it could send NSLP message directly using a GIMPS-query message without a messaging association to = be setup beforehand. For receiver-init signaling, it is not possible to do = so. > >=20 > > As for the messaging association establishment, it is a GIMPS level=20 > > signaling. According to the text in section 4.3, it has to be=20 > > initiated from upstream. What is lacking is how this process is=20 > > triggered (maybe out of > > scope). What I am not so sure is that if it is triggered by a=20 > > message sent > > by the receiver, e.g. a BU from a MN, could we call it=20 > > receiver initiated? >=20 > this is part of our mobility discussions. i don't know=20 > whether we should call something receiver-initiated only if=20 > the data receiver triggers some actions (after an initial=20 > exchange already took place). in the mobility case we even=20 > have scenarios where nodes in the middle could trigger something.=20 With mobility scenarios, this would be more intersting. There could be different triggers flying around. The issue would be "do we treat these mobility signaling part of NSIS signaling"? If not, the signaling would = be almost always sender-init, since the first GIMPS message is always sent = out from the sender. If yes, then, the signaling could be initiated anyway (sender/receiver/middle node) > >=20 > > > definitions of these two terms is rather fuzzy (even in the > > > framework). with > > > path-coupled signaling only the sender is able to start signaling. > >=20 > > Do you mean the GIMPS signaling described above? I feel it > > depends on what > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for=20 > > NTLP and NSLP), > > it is quite true. >=20 > the data sender has to send the first message in nearly all cases.=20 Please see above. > for the receiver-behind a nat things are a bit different but=20 > this might not fit into the sender- vs. receiver-initiated=20 > "something" terminology either.=20 Agree. Add in the NAT makes it more confusing for now. > i suggest to deprecate the sender- and receiver-initiated=20 > terminology. what matters at the end is > - who has to provide information for authorizion=20 > - what is he authorized for > - to which entity is authorization required > - who triggers reauthorization > - what credentials are used for authorization > - how long is authorization valid > - and finally the different levels of authorization (for qos=20 > resource, for triggering certain actions, ... ) This is a good list. But I feel some of the issues could be separated = for NTLP(GIMPS) and NSLP. Most of the authorization issues would be related = to NSLP, e.g. authorization for qos, etc. As for the GIMPS, the issue is = more focused on the "routing state maintenance" and "messaging association". Therefore, the things to be sort out are:=20 -who and when setup the messaging association (including nodes auth. = issues) -what triggers the setup of messaging association (interactions with = NSLP or routing stack) -What is the interaction for "routing state" and "messaging association (related to mobility) > since some of these issues have a relationship to mobility i=20 > would encourage everyone to take a look at the mobility draft=20 > (and the nslps) and to post their opinion.=20 Is the new version of the mobility draft available now? cheers Cheng Hong > ciao > hannes >=20 >=20 > >=20 > >=20 > > cheers > >=20 > > Cheng Hong > >=20 > >=20 > > > 'maintaining the treatment for a flow' is also difficult to > > > understand in > > > the light of our mobility discussions or the recently=20 > > > discussed preemption > > > issues.=20 > > >=20 > > > ciao > > > hannes > > >=20 > > >=20 > > > >=20 > > > > Thanks for your replies, > > > > Elena > > > > =20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 07:13:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09087 for ; Wed, 7 Apr 2004 07:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAzK-0001vI-TJ for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 07:12:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37BCwjG007388 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 07:12:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAzK-0001up-Kb; Wed, 07 Apr 2004 07:12:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAyN-0001jL-CH for nsis@optimus.ietf.org; Wed, 07 Apr 2004 07:11:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09047 for ; Wed, 7 Apr 2004 07:11:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBAyK-0004ls-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:11:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB9nR-0004Nv-00 for nsis@ietf.org; Wed, 07 Apr 2004 05:56:39 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1BB8gG-0003kT-00 for nsis@ietf.org; Wed, 07 Apr 2004 04:45:08 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id i378iqCi026184; Wed, 7 Apr 2004 10:44:52 +0200 (MET DST) Message-ID: <002f01c41c7c$98edf2f0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Elena Scialpi" Cc: "nsis" References: Subject: Re: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 10:44:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 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 Elena The GIMPS query and response messages are used to support the interaction between two neighboring NTLP hops. This can occur in both scenarios, i.e., sender and receiver initiated. GIMPS does not use the sender initiated and receiver initiated concpets in its operation. There is however, a possible requirement on GIMPS in case of receiver initiated operation (see also section 8.14 of the GIMPS draft): "Receiver initiated signaling applications need to have reverse path state set up in the network. Should this be done by GIMPS carrying out the discovery for the specific signaling application (which requires the flow sender to know what signaling applications are going to be used), or should the discovery attempt to find every GIMPS node and the signaling applications they support?" The sender-initiated and receiver-initiated concepts are mainly used by the QoS-NSLP operation and applied among the NI (NSIS Initiator), the NFs (NSIS Forwarders) and NR (NSIS Responder). Best Regards, Georgios ----- Original Message ----- From: "Elena Scialpi" To: "attila.bader" Cc: "nsis" Sent: Tuesday, April 06, 2004 6:28 PM Subject: RE: [NSIS] About GIMPS! > > Figure 4 (http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt ) shows message sequence > at state setup. > > The draft says that Gimps-query is sent downstream and Gimps-response upstream. > > in sender-initiated case Gimps-query is sent upstream and Gimps-response downstream. > > Are you agree with me? > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 07:15:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09325 for ; Wed, 7 Apr 2004 07:15:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBB1L-0002ZR-Mr for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 07:15:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37BF3Gt009751 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 07:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBB1K-0002W2-F2; Wed, 07 Apr 2004 07:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBB0c-0002QS-S6 for nsis@optimus.ietf.org; Wed, 07 Apr 2004 07:14:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09140 for ; Wed, 7 Apr 2004 07:14:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBB0c-0004yZ-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:14:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB9pI-0004gi-00 for nsis@ietf.org; Wed, 07 Apr 2004 05:58:34 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BB8k0-0003zB-00 for nsis@ietf.org; Wed, 07 Apr 2004 04:49:01 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <2M89N6JY>; Wed, 7 Apr 2004 09:48:31 +0100 Message-ID: From: "Hancock, Robert" To: "'Cheng Hong'" , "'Tschofenig Hannes'" , "'Elena Scialpi'" , "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 09:48:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, if people want to see the reasoning which went into the current framework split, it is still written down in http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-receiver-00.txt the essential points are: a) does a protocol have any asymmetry in operation (i.e. client/server, initiator/responder, whatever) b) if so, does that asymmetry have any coupling to the direction of the data flow the argument of the above i-d (reflected in the framework and the subsequent protocol designs) is that these questions have to be considered independently for the NTLP (GIMPS) and NSLPs (signalling applications). Specifically for GIMPS, there is asymmetry in the discovery phase, because only the upstream node can initiate the process (that's a consequence of IP routing) as Cheng says below. (Whether you want to call this sender or receiver initiated is just a terminology issue.) If we can think of ways to make discovery possible in both directions, we might incorporate them. However, once the message routing state is set up, GIMPS tries as hard as possible to hide this asymmetry from the signalling applications. They can make their own decisions about whether aspects of their protocol should be directional and whether to tie that to data flow direction. What is definitely the case is that GIMPS punts on what initiates the discovery process in the first place. This is a trigger from the OS or a particular signalling application, or network management, or whatever. Signalling application developers need to say what kicks off this part of the process. Does this answer the question? r. > -----Original Message----- > From: Cheng Hong [mailto:hcheng@psl.com.sg] > Sent: Wednesday, April 07, 2004 03:52 > To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis' > Subject: RE: [NSIS] About GIMPS! > > > Hi Hannes, > > > > > if you decouple the authorization aspects from the signaling > > aspects then > > the concepts of sender- vs. receiver-initiated "something" > > are less obvious > > in a path-coupled signaling protocol. i personally think that the > > I think if we further decouple the messaging association establishing > procedure (GIMPS) from the actual signaling (NSLP signaling), the > sender-init vs. receiver-init would be less important. With > the current text > in GIMPS, there is still a subtle difference, e.g. in D-mode, > sender-init > could send NSLP message with the "GIMPS-query" message. > > As for the messaging association establishment, it is a GIMPS level > signaling. According to the text in section 4.3, it has to be > initiated from > upstream. What is lacking is how this process is triggered > (maybe out of > scope). What I am not so sure is that if it is triggered by a > message sent > by the receiver, e.g. a BU from a MN, could we call it > receiver initiated? > > > > definitions of these two terms is rather fuzzy (even in the > > framework). with > > path-coupled signaling only the sender is able to start signaling. > > Do you mean the GIMPS signaling described above? I feel it > depends on what > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > NTLP and NSLP), > it is quite true. > > > cheers > > Cheng Hong > > > > 'maintaining the treatment for a flow' is also difficult to > > understand in > > the light of our mobility discussions or the recently > > discussed preemption > > issues. > > > > ciao > > hannes > > > > > > > > > > Thanks for your replies, > > > Elena > > > > > > > > > > > > _______________________________________________ > > > 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 exim@www1.ietf.org Wed Apr 7 07:15:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09350 for ; Wed, 7 Apr 2004 07:15:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBB1N-0002dU-Pq for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 07:15:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37BF5CH010110 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 07:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBB1N-0002cx-KU; Wed, 07 Apr 2004 07:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBB13-0002SH-Us for nsis@optimus.ietf.org; Wed, 07 Apr 2004 07:14:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09230 for ; Wed, 7 Apr 2004 07:14:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBB13-00053I-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:14:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB9qw-0004xX-00 for nsis@ietf.org; Wed, 07 Apr 2004 06:00:15 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1BB8o4-0004IP-00 for nsis@ietf.org; Wed, 07 Apr 2004 04:53:12 -0400 Received: by jazz.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id i378qfbU019722 for ; Wed, 7 Apr 2004 17:52:41 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id i378qf208045 for ; Wed, 7 Apr 2004 17:52:41 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id i378qfq06000 for ; Wed, 7 Apr 2004 17:52:41 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml21) id i378qfJ21046 for nsis@ietf.org; Wed, 7 Apr 2004 17:52:41 +0900 (JST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by soml21.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id i378qeD21040 for ; Wed, 7 Apr 2004 17:52:40 +0900 (JST) Date: Wed, 07 Apr 2004 17:52:41 +0900 From: Takako Sanda To: nsis@ietf.org Subject: Re: [NSIS] About GIMPS! In-Reply-To: References: Message-Id: <20040407174853.000B.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.02 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, I have an additional questions about GIMPS state. Section 4.1 of GIMPS draft says the GIMPS layer maintains message routing state by using primary key consists of {flow routing info, session id, signaling application id}. However, when a signaling application data is QUERY, which used for finding out available resources, it may not contain flow information or session id. This case GIMPS cannot maintain routing state as above though QUERY message requires RESPONSE which should be forwarded peer-to-peer back to QUERY sender by using NSLP level routing association (section 3.5.2 of QoS NSLP draft). So, I think alternative state management method may be required. If I have any misunderstandings, please point them out. Best Regards, Takako Sanda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 07:42:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13067 for ; Wed, 7 Apr 2004 07:42:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBRX-0003Pr-BX for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 07:42:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Bg7W4013132 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 07:42:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBRV-0003Od-Vw; Wed, 07 Apr 2004 07:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBR0-0003Gd-Qg for nsis@optimus.ietf.org; Wed, 07 Apr 2004 07:41:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12886 for ; Wed, 7 Apr 2004 07:41:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBR0-0000y9-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:41:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBAV6-0000sP-00 for nsis@ietf.org; Wed, 07 Apr 2004 06:41:46 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BB95v-0007Hr-00 for nsis@ietf.org; Wed, 07 Apr 2004 05:11:39 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i379BdK24128; Wed, 7 Apr 2004 11:11:39 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i379BdQ19546; Wed, 7 Apr 2004 11:11:39 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 11:10:50 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FB3@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Hancock, Robert'" , "'Cheng Hong'" , "'Elena Scialpi'" , "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 11:11:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, i guess we all agree that there is asymmetry in the discovery phase. i only have problems with the "original definition" of sender- vs. receiver-initiated reservations. the do not fit into the nsis picture. ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Wednesday, April 07, 2004 10:49 AM > To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis' > Subject: RE: [NSIS] About GIMPS! > > > dear all, > > if people want to see the reasoning which went into the current > framework split, it is still written down in > http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-r > eceiver-00.txt > > the essential points are: > a) does a protocol have any asymmetry in operation (i.e. > client/server, > initiator/responder, whatever) > b) if so, does that asymmetry have any coupling to the direction of > the data flow > > the argument of the above i-d (reflected in the framework and the > subsequent protocol designs) is that these questions have to be > considered independently for the NTLP (GIMPS) and NSLPs (signalling > applications). > > Specifically for GIMPS, there is asymmetry in the discovery phase, > because only the upstream node can initiate the process (that's a > consequence of IP routing) as Cheng says below. (Whether you want > to call this sender or receiver initiated is just a terminology > issue.) If we can think of ways to make discovery possible in both > directions, we might incorporate them. However, once the message > routing state is set up, GIMPS tries as hard as possible to hide > this asymmetry from the signalling applications. They can make their > own decisions about whether aspects of their protocol should be > directional and whether to tie that to data flow direction. > > What is definitely the case is that GIMPS punts on what initiates the > discovery process in the first place. This is a trigger from the > OS or a particular signalling application, or network management, > or whatever. Signalling application developers need to say what > kicks off this part of the process. > > Does this answer the question? > > r. > > > -----Original Message----- > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > Sent: Wednesday, April 07, 2004 03:52 > > To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis' > > Subject: RE: [NSIS] About GIMPS! > > > > > > Hi Hannes, > > > > > > > > > if you decouple the authorization aspects from the signaling > > > aspects then > > > the concepts of sender- vs. receiver-initiated "something" > > > are less obvious > > > in a path-coupled signaling protocol. i personally think that the > > > > I think if we further decouple the messaging association > establishing > > procedure (GIMPS) from the actual signaling (NSLP signaling), the > > sender-init vs. receiver-init would be less important. With > > the current text > > in GIMPS, there is still a subtle difference, e.g. in D-mode, > > sender-init > > could send NSLP message with the "GIMPS-query" message. > > > > As for the messaging association establishment, it is a GIMPS level > > signaling. According to the text in section 4.3, it has to be > > initiated from > > upstream. What is lacking is how this process is triggered > > (maybe out of > > scope). What I am not so sure is that if it is triggered by a > > message sent > > by the receiver, e.g. a BU from a MN, could we call it > > receiver initiated? > > > > > > > definitions of these two terms is rather fuzzy (even in the > > > framework). with > > > path-coupled signaling only the sender is able to start signaling. > > > > Do you mean the GIMPS signaling described above? I feel it > > depends on what > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > > NTLP and NSLP), > > it is quite true. > > > > > > cheers > > > > Cheng Hong > > > > > > > 'maintaining the treatment for a flow' is also difficult to > > > understand in > > > the light of our mobility discussions or the recently > > > discussed preemption > > > issues. > > > > > > ciao > > > hannes > > > > > > > > > > > > > > Thanks for your replies, > > > > Elena > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > -- > > Visit our website at www.roke.co.uk > > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to > Roke Manor Research Ltd and must not be passed to any third > party without > permission. This communication is for information only and > shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 07:48:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13901 for ; Wed, 7 Apr 2004 07:48:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBXJ-0005Dk-Ph for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 07:48:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Bm5PJ020023 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 07:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBXJ-0005Bk-9o; Wed, 07 Apr 2004 07:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBX5-00053D-8U for nsis@optimus.ietf.org; Wed, 07 Apr 2004 07:47:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13764 for ; Wed, 7 Apr 2004 07:47:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBX4-0001oF-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:47:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBAgG-00022B-00 for nsis@ietf.org; Wed, 07 Apr 2004 06:53:17 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BB9EY-0000tq-00 for nsis@ietf.org; Wed, 07 Apr 2004 05:20:34 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <2M80KDMK>; Wed, 7 Apr 2004 10:20:05 +0100 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes'" , "'Cheng Hong'" , "'Elena Scialpi'" , "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 10:20:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 guess you are referring to nsis-fw 3.3.1. it's true that it is not very precise, but that is because the issue it is trying to describe is very broad. it just tries to point out that there will be choices to be made in signalling application design and these choices will have some consequences; and that the NTLP will not constrain those choices. (Which is all that the framework can say anyway.) (anyway, it still isn't too late for people to suggest clarification text!) r. > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Wednesday, April 07, 2004 10:11 > To: Hancock, Robert; 'Cheng Hong'; 'Elena Scialpi'; 'nsis' > Subject: RE: [NSIS] About GIMPS! > > > hi robert, > > i guess we all agree that there is asymmetry in the discovery phase. > i only have problems with the "original definition" of sender- vs. > receiver-initiated reservations. the do not fit into the nsis > picture. > > ciao > hannes > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Wednesday, April 07, 2004 10:49 AM > > To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis' > > Subject: RE: [NSIS] About GIMPS! > > > > > > dear all, > > > > if people want to see the reasoning which went into the current > > framework split, it is still written down in > > http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-r > > eceiver-00.txt > > > > the essential points are: > > a) does a protocol have any asymmetry in operation (i.e. > > client/server, > > initiator/responder, whatever) > > b) if so, does that asymmetry have any coupling to the direction of > > the data flow > > > > the argument of the above i-d (reflected in the framework and the > > subsequent protocol designs) is that these questions have to be > > considered independently for the NTLP (GIMPS) and NSLPs (signalling > > applications). > > > > Specifically for GIMPS, there is asymmetry in the discovery phase, > > because only the upstream node can initiate the process (that's a > > consequence of IP routing) as Cheng says below. (Whether you want > > to call this sender or receiver initiated is just a terminology > > issue.) If we can think of ways to make discovery possible in both > > directions, we might incorporate them. However, once the message > > routing state is set up, GIMPS tries as hard as possible to hide > > this asymmetry from the signalling applications. They can make their > > own decisions about whether aspects of their protocol should be > > directional and whether to tie that to data flow direction. > > > > What is definitely the case is that GIMPS punts on what > initiates the > > discovery process in the first place. This is a trigger from the > > OS or a particular signalling application, or network management, > > or whatever. Signalling application developers need to say what > > kicks off this part of the process. > > > > Does this answer the question? > > > > r. > > > > > -----Original Message----- > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > Sent: Wednesday, April 07, 2004 03:52 > > > To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis' > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > if you decouple the authorization aspects from the signaling > > > > aspects then > > > > the concepts of sender- vs. receiver-initiated "something" > > > > are less obvious > > > > in a path-coupled signaling protocol. i personally > think that the > > > > > > I think if we further decouple the messaging association > > establishing > > > procedure (GIMPS) from the actual signaling (NSLP signaling), the > > > sender-init vs. receiver-init would be less important. With > > > the current text > > > in GIMPS, there is still a subtle difference, e.g. in D-mode, > > > sender-init > > > could send NSLP message with the "GIMPS-query" message. > > > > > > As for the messaging association establishment, it is a > GIMPS level > > > signaling. According to the text in section 4.3, it has to be > > > initiated from > > > upstream. What is lacking is how this process is triggered > > > (maybe out of > > > scope). What I am not so sure is that if it is triggered by a > > > message sent > > > by the receiver, e.g. a BU from a MN, could we call it > > > receiver initiated? > > > > > > > > > > definitions of these two terms is rather fuzzy (even in the > > > > framework). with > > > > path-coupled signaling only the sender is able to start > signaling. > > > > > > Do you mean the GIMPS signaling described above? I feel it > > > depends on what > > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > > > NTLP and NSLP), > > > it is quite true. > > > > > > > > > cheers > > > > > > Cheng Hong > > > > > > > > > > 'maintaining the treatment for a flow' is also difficult to > > > > understand in > > > > the light of our mobility discussions or the recently > > > > discussed preemption > > > > issues. > > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > > > > > > Thanks for your replies, > > > > > Elena > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > -- > > > > Visit our website at www.roke.co.uk > > > > Registered Office: Roke Manor Research Ltd, Siemens House, > > Oldbury, Bracknell, > > Berkshire. RG12 8FZ > > > > The information contained in this e-mail and any attachments > > is confidential to > > Roke Manor Research Ltd and must not be passed to any third > > party without > > permission. This communication is for information only and > > shall not create or > > change any contractual relationship. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 07:52:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14419 for ; Wed, 7 Apr 2004 07:52:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBbA-0006Jz-A1 for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 07:52:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Bq41j024299 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 07:52:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBb8-0006Hd-Ty; Wed, 07 Apr 2004 07:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBav-0006E5-9O for nsis@optimus.ietf.org; Wed, 07 Apr 2004 07:51:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14383 for ; Wed, 7 Apr 2004 07:51:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBau-0002Rc-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:51:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBAmf-0002kO-00 for nsis@ietf.org; Wed, 07 Apr 2004 06:59:55 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BB9Iv-0001kg-00 for nsis@ietf.org; Wed, 07 Apr 2004 05:25:05 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i3792oK13456; Wed, 7 Apr 2004 11:02:50 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3792mQ07749; Wed, 7 Apr 2004 11:02:48 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 11:02:00 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FB2@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Cheng Hong'" , "'Elena Scialpi'" , "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 11:02:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 cheng, please find some comments inline: > Hi Hannes, > > Please see a few more comments inline: > > > > > > > > if you decouple the authorization aspects from the signaling > > > > aspects then > > > > the concepts of sender- vs. receiver-initiated "something" > > > > are less obvious > > > > in a path-coupled signaling protocol. i personally > think that the > > > > > > I think if we further decouple the messaging association > > establishing > > > procedure (GIMPS) from the actual signaling (NSLP signaling), the > > > sender-init vs. receiver-init would be less important. With the > > > current text in GIMPS, there is still a subtle > difference, e.g. in > > > D-mode, sender-init > > > could send NSLP message with the "GIMPS-query" message. > > > > i still cannot get used to the d-mode vs. c-mode terminology. > > anyway, the d-mode vs. c-mode issues are also orthogonal to > > this discussion. > > True. This has nothing to do with D-mode vs C-mode. It is > rather sender-init > vs. receiver-init. For a sender-init case, it could send NSLP message > directly using a GIMPS-query message without a messaging > association to be > setup beforehand. For receiver-init signaling, it is not > possible to do so. this issue effectively boils down to a security question: - in which cases can you attach a nslp payload to the "discovery" message? - how do you secure messages where you do not know the next node processing this message? - what nslp applications do not require security mechanisms? - do you know your next peer? - if you know him then why don't you address him. > > > > > > > As for the messaging association establishment, it is a > GIMPS level > > > signaling. According to the text in section 4.3, it has to be > > > initiated from upstream. What is lacking is how this process is > > > triggered (maybe out of > > > scope). What I am not so sure is that if it is triggered by a > > > message sent > > > by the receiver, e.g. a BU from a MN, could we call it > > > receiver initiated? > > > > this is part of our mobility discussions. i don't know > > whether we should call something receiver-initiated only if > > the data receiver triggers some actions (after an initial > > exchange already took place). in the mobility case we even > > have scenarios where nodes in the middle could trigger something. > > With mobility scenarios, this would be more intersting. There could be > different triggers flying around. The issue would be "do we > treat these > mobility signaling part of NSIS signaling"? we do not treat mobility signaling as part of nsis. nsis signaling needs to work in a mobile environment. If not, the > signaling would be > almost always sender-init, since the first GIMPS message is > always sent out > from the sender. If yes, then, the signaling could be initiated anyway > (sender/receiver/middle node) > > > > > > > > > definitions of these two terms is rather fuzzy (even in the > > > > framework). with > > > > path-coupled signaling only the sender is able to start > signaling. > > > > > > Do you mean the GIMPS signaling described above? I feel it > > > depends on what > > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > > > NTLP and NSLP), > > > it is quite true. > > > > the data sender has to send the first message in nearly all cases. > > Please see above. > > > > for the receiver-behind a nat things are a bit different but > > this might not fit into the sender- vs. receiver-initiated > > "something" terminology either. > > Agree. Add in the NAT makes it more confusing for now. > > > i suggest to deprecate the sender- and receiver-initiated > > terminology. what matters at the end is > > - who has to provide information for authorizion > > - what is he authorized for > > - to which entity is authorization required > > - who triggers reauthorization > > - what credentials are used for authorization > > - how long is authorization valid > > - and finally the different levels of authorization (for qos > > resource, for triggering certain actions, ... ) > > This is a good list. But I feel some of the issues could be > separated for > NTLP(GIMPS) and NSLP. certainly true. > Most of the authorization issues would > be related to > NSLP, e.g. authorization for qos, etc. i fully agree with you. unfortunately, there is some interworking between them. entirely separating is insecure as we saw with the man-in-the-middle attacks for tunneled authentication. As for the GIMPS, the > issue is more > focused on the "routing state maintenance" and "messaging > association". true. with version -00 of the gimps draft intermediaries have been introduced with have no nslp part at the same host. with version -01 this was removed again. this has major security implications. > Therefore, the things to be sort out are: > -who and when setup the messaging association (including > nodes auth. issues) > > -what triggers the setup of messaging association > (interactions with NSLP or > routing stack) > -What is the interaction for "routing state" and "messaging > association > (related to mobility) true. i guess that this is what we do at the moment. we updated the text on the qos nslp with regard to security. the nat/fw issues contain a fair amount of security issues (and additional issues are in discussion). based on the issues we discover in this area input will be provided to the ntlp. > > > > > since some of these issues have a relationship to mobility i > > would encourage everyone to take a look at the mobility draft > > (and the nslps) and to post their opinion. > > Is the new version of the mobility draft available now? the draft is already pretty new. ciao hannes > > cheers > > Cheng Hong > > > > > ciao > > hannes > > > > > > > > > > > > > cheers > > > > > > Cheng Hong > > > > > > > > > > 'maintaining the treatment for a flow' is also difficult to > > > > understand in > > > > the light of our mobility discussions or the recently > > > > discussed preemption > > > > issues. > > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > > > > > > Thanks for your replies, > > > > > Elena > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 exim@www1.ietf.org Wed Apr 7 07:54:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14742 for ; Wed, 7 Apr 2004 07:54:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBd4-0006ov-3k for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 07:54:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Bs25F026212 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 07:54:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBd3-0006oe-V7; Wed, 07 Apr 2004 07:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBcq-0006mo-1G for nsis@optimus.ietf.org; Wed, 07 Apr 2004 07:53:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14585 for ; Wed, 7 Apr 2004 07:53:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBcp-0002kb-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:53:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBArS-0003YB-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:04:52 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BB9UY-0002hT-00 for nsis@ietf.org; Wed, 07 Apr 2004 05:37:06 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i379b6Y11868; Wed, 7 Apr 2004 11:37:06 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i379b6Q23595; Wed, 7 Apr 2004 11:37:06 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 11:36:17 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FB4@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Hancock, Robert'" , "'Cheng Hong'" , "'Elena Scialpi'" , "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 11:36:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, i think there is no value in changing the text since the definition itself is (my personal opinion) not helpful anyway. hence, my suggestion is therefore to modify a possible question regarding sender- vs. receiver-oriented into the details of the protocol. for example, is the data sender able to authorize a qos reservation or the data receiver? for rsvp it was claimed that it is the data receiver since the sender does not know how much resources the receiver will request (due to the adspec functionality). if you defer the authorization decision a bit - after receiving the RESV message - then again it would be possible for the sender to provide the authorization. other proposals have been provided in the past. something which matters is the following. does the qos nslp allow both the data sender and the data receiver to provide authorization information. for the current draft the answer is: no (using some assumptions, see below). only the query and the reserve messages carry a POLICY_DATA object. my assumption is that the data receiver returns a response message (and does not return a reserve after receiving a query) or it does not return a reserve after receiving a reserve message. ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Wednesday, April 07, 2004 11:20 AM > To: Tschofenig Hannes; 'Cheng Hong'; 'Elena Scialpi'; 'nsis' > Subject: RE: [NSIS] About GIMPS! > > > hi, > > i guess you are referring to nsis-fw 3.3.1. it's true that > it is not very precise, but that is because the issue it is > trying to describe is very broad. it just tries to point out > that there will be choices to be made in signalling application > design and these choices will have some consequences; and that > the NTLP will not constrain those choices. (Which is all that > the framework can say anyway.) > > (anyway, it still isn't too late for people to suggest clarification > text!) > > r. > > > -----Original Message----- > > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Wednesday, April 07, 2004 10:11 > > To: Hancock, Robert; 'Cheng Hong'; 'Elena Scialpi'; 'nsis' > > Subject: RE: [NSIS] About GIMPS! > > > > > > hi robert, > > > > i guess we all agree that there is asymmetry in the > discovery phase. > > i only have problems with the "original definition" of sender- vs. > > receiver-initiated reservations. the do not fit into the nsis > > picture. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: Wednesday, April 07, 2004 10:49 AM > > > To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis' > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > dear all, > > > > > > if people want to see the reasoning which went into the current > > > framework split, it is still written down in > > > http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-r > > > eceiver-00.txt > > > > > > the essential points are: > > > a) does a protocol have any asymmetry in operation (i.e. > > > client/server, > > > initiator/responder, whatever) > > > b) if so, does that asymmetry have any coupling to the > direction of > > > the data flow > > > > > > the argument of the above i-d (reflected in the framework and the > > > subsequent protocol designs) is that these questions have to be > > > considered independently for the NTLP (GIMPS) and NSLPs > (signalling > > > applications). > > > > > > Specifically for GIMPS, there is asymmetry in the discovery phase, > > > because only the upstream node can initiate the process (that's a > > > consequence of IP routing) as Cheng says below. (Whether you want > > > to call this sender or receiver initiated is just a terminology > > > issue.) If we can think of ways to make discovery possible in both > > > directions, we might incorporate them. However, once the message > > > routing state is set up, GIMPS tries as hard as possible to hide > > > this asymmetry from the signalling applications. They can > make their > > > own decisions about whether aspects of their protocol should be > > > directional and whether to tie that to data flow direction. > > > > > > What is definitely the case is that GIMPS punts on what > > initiates the > > > discovery process in the first place. This is a trigger from the > > > OS or a particular signalling application, or network management, > > > or whatever. Signalling application developers need to say what > > > kicks off this part of the process. > > > > > > Does this answer the question? > > > > > > r. > > > > > > > -----Original Message----- > > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > > Sent: Wednesday, April 07, 2004 03:52 > > > > To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis' > > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > if you decouple the authorization aspects from the signaling > > > > > aspects then > > > > > the concepts of sender- vs. receiver-initiated "something" > > > > > are less obvious > > > > > in a path-coupled signaling protocol. i personally > > think that the > > > > > > > > I think if we further decouple the messaging association > > > establishing > > > > procedure (GIMPS) from the actual signaling (NSLP > signaling), the > > > > sender-init vs. receiver-init would be less important. With > > > > the current text > > > > in GIMPS, there is still a subtle difference, e.g. in D-mode, > > > > sender-init > > > > could send NSLP message with the "GIMPS-query" message. > > > > > > > > As for the messaging association establishment, it is a > > GIMPS level > > > > signaling. According to the text in section 4.3, it has to be > > > > initiated from > > > > upstream. What is lacking is how this process is triggered > > > > (maybe out of > > > > scope). What I am not so sure is that if it is triggered by a > > > > message sent > > > > by the receiver, e.g. a BU from a MN, could we call it > > > > receiver initiated? > > > > > > > > > > > > > definitions of these two terms is rather fuzzy (even in the > > > > > framework). with > > > > > path-coupled signaling only the sender is able to start > > signaling. > > > > > > > > Do you mean the GIMPS signaling described above? I feel it > > > > depends on what > > > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > > > > NTLP and NSLP), > > > > it is quite true. > > > > > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > 'maintaining the treatment for a flow' is also difficult to > > > > > understand in > > > > > the light of our mobility discussions or the recently > > > > > discussed preemption > > > > > issues. > > > > > > > > > > ciao > > > > > hannes > > > > > > > > > > > > > > > > > > > > > > Thanks for your replies, > > > > > > Elena > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > -- > > > > > > Visit our website at www.roke.co.uk > > > > > > Registered Office: Roke Manor Research Ltd, Siemens House, > > > Oldbury, Bracknell, > > > Berkshire. RG12 8FZ > > > > > > The information contained in this e-mail and any attachments > > > is confidential to > > > Roke Manor Research Ltd and must not be passed to any third > > > party without > > > permission. This communication is for information only and > > > shall not create or > > > change any contractual relationship. > > > > > > > -- > > Visit our website at www.roke.co.uk > > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to > Roke Manor Research Ltd and must not be passed to any third > party without > permission. This communication is for information only and > shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 08:50:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17643 for ; Wed, 7 Apr 2004 08:50:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBCVJ-00016g-0M for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 08:50:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Co49R004237 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 08:50:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBCVH-00015G-Tf; Wed, 07 Apr 2004 08:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBCV3-000103-4W for nsis@optimus.ietf.org; Wed, 07 Apr 2004 08:49:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17546 for ; Wed, 7 Apr 2004 08:49:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBCV1-00008s-00 for nsis@ietf.org; Wed, 07 Apr 2004 08:49:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBBQw-0000xe-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:41:31 -0400 Received: from smtp2.libero.it ([193.70.192.52]) by ietf-mx with esmtp (Exim 4.12) id 1BBAUu-0000ok-00 for nsis@ietf.org; Wed, 07 Apr 2004 06:41:32 -0400 Received: from libero.it (172.16.1.107) by smtp2.libero.it (7.0.027-DD01) id 404F13FC003C5FCE for nsis@ietf.org; Wed, 7 Apr 2004 12:41:36 +0200 Date: Wed, 7 Apr 2004 12:41:03 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Elena Scialpi" To: "nsis" X-XaM3-API-Version: 4.1 (B27) X-type: 0 X-SenderIP: 193.204.86.188 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] A stupid question! Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I've question for you: In NSIS there are many divisions : -NTLP = and NSLP; -sender-initiated and received-initiated; -NTLP in GIMPS and = transport protocol. Why ? Only for flexibility of the protocol? Could= you give me, in few words , the main reasons for this divisions! Exus= e my stupid question, thanks, Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 10:04:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23477 for ; Wed, 7 Apr 2004 10:04:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDeu-00054M-Kv for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 10:04:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37E4460019465 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 10:04:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDer-0004zK-3J; Wed, 07 Apr 2004 10:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDe5-0004SD-PU for nsis@optimus.ietf.org; Wed, 07 Apr 2004 10:03:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23331 for ; Wed, 7 Apr 2004 10:03:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBDe3-0000KC-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:03:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBCW5-0000Mz-00 for nsis@ietf.org; Wed, 07 Apr 2004 08:50:54 -0400 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBTm-0001R1-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:44:26 -0400 Received: from HP11517441532 (dhcp192-244.enst.fr [137.194.192.244]) by infres.enst.fr (Postfix) with SMTP id 094922FE7; Wed, 7 Apr 2004 13:44:19 +0200 (MEST) Message-ID: <009b01c41c95$a9a871b0$f4c0c289@HP11517441532> From: "Thanh Tra LUU" To: "Takako Sanda" Cc: References: <20040407174853.000B.SANDA.TAKAKO@jp.panasonic.com> Subject: Re: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 13:44:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Takako, In this case, D-mode (or C mode) can be used. I don't understand why the message does not contain the flow information, nslp-id. The message needs routing as the data packets so flow information and nslp-id are necessary. For session-id, it can be created for each query message and the state is not maintained on any intermediate nodes. Nary Tra, ENST, Paris. ----- Original Message ----- From: "Takako Sanda" To: Sent: Wednesday, April 07, 2004 10:52 AM Subject: Re: [NSIS] About GIMPS! > Hi all, > > I have an additional questions about GIMPS state. > > Section 4.1 of GIMPS draft says the GIMPS layer maintains message > routing state by using primary key consists of {flow routing info, > session id, signaling application id}. > However, when a signaling application data is QUERY, which used for > finding out available resources, it may not contain flow information or > session id. This case GIMPS cannot maintain routing state as above > though QUERY message requires RESPONSE which should be forwarded > peer-to-peer back to QUERY sender by using NSLP level routing > association (section 3.5.2 of QoS NSLP draft). > So, I think alternative state management method may be required. > > If I have any misunderstandings, please point them out. > > Best Regards, > Takako Sanda > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 10:06:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23837 for ; Wed, 7 Apr 2004 10:06:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDgo-0005vN-V8 for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 10:06:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37E62Sq022734 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 10:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDgo-0005uX-OJ; Wed, 07 Apr 2004 10:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDgI-0005bP-HJ for nsis@optimus.ietf.org; Wed, 07 Apr 2004 10:05:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23586 for ; Wed, 7 Apr 2004 10:05:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBDgG-0000am-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:05:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBCXz-0000dF-00 for nsis@ietf.org; Wed, 07 Apr 2004 08:52:52 -0400 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBYH-0001yh-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:49:05 -0400 Received: from HP11517441532 (dhcp192-244.enst.fr [137.194.192.244]) by infres.enst.fr (Postfix) with SMTP id E0BC42FCC; Wed, 7 Apr 2004 13:49:03 +0200 (MEST) Message-ID: <00a101c41c96$52af0350$f4c0c289@HP11517441532> From: "Thanh Tra LUU" To: "Tschofenig Hannes" Cc: "'nsis'" References: <2A8DB02E3018D411901B009027FD3A3F04685FB3@mchp905a.mch.sbs.de> Subject: Re: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 13:49:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Hannes, i think there is no asymmetric routing here. In the mode receiver-initiator, the recevier maintains the forward state ( Resv state in RSVP). However, the sender must discover the data path in anycase and there in only one data path (sender -> receiver). Nary Tra, ENST, Paris. ----- Original Message ----- From: "Tschofenig Hannes" To: "'Hancock, Robert'" ; "'Cheng Hong'" ; "'Elena Scialpi'" ; "'nsis'" Sent: Wednesday, April 07, 2004 11:11 AM Subject: RE: [NSIS] About GIMPS! > hi robert, > > i guess we all agree that there is asymmetry in the discovery phase. > i only have problems with the "original definition" of sender- vs. > receiver-initiated reservations. the do not fit into the nsis picture. > > ciao > hannes > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Wednesday, April 07, 2004 10:49 AM > > To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis' > > Subject: RE: [NSIS] About GIMPS! > > > > > > dear all, > > > > if people want to see the reasoning which went into the current > > framework split, it is still written down in > > http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-r > > eceiver-00.txt > > > > the essential points are: > > a) does a protocol have any asymmetry in operation (i.e. > > client/server, > > initiator/responder, whatever) > > b) if so, does that asymmetry have any coupling to the direction of > > the data flow > > > > the argument of the above i-d (reflected in the framework and the > > subsequent protocol designs) is that these questions have to be > > considered independently for the NTLP (GIMPS) and NSLPs (signalling > > applications). > > > > Specifically for GIMPS, there is asymmetry in the discovery phase, > > because only the upstream node can initiate the process (that's a > > consequence of IP routing) as Cheng says below. (Whether you want > > to call this sender or receiver initiated is just a terminology > > issue.) If we can think of ways to make discovery possible in both > > directions, we might incorporate them. However, once the message > > routing state is set up, GIMPS tries as hard as possible to hide > > this asymmetry from the signalling applications. They can make their > > own decisions about whether aspects of their protocol should be > > directional and whether to tie that to data flow direction. > > > > What is definitely the case is that GIMPS punts on what initiates the > > discovery process in the first place. This is a trigger from the > > OS or a particular signalling application, or network management, > > or whatever. Signalling application developers need to say what > > kicks off this part of the process. > > > > Does this answer the question? > > > > r. > > > > > -----Original Message----- > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > Sent: Wednesday, April 07, 2004 03:52 > > > To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis' > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > if you decouple the authorization aspects from the signaling > > > > aspects then > > > > the concepts of sender- vs. receiver-initiated "something" > > > > are less obvious > > > > in a path-coupled signaling protocol. i personally think that the > > > > > > I think if we further decouple the messaging association > > establishing > > > procedure (GIMPS) from the actual signaling (NSLP signaling), the > > > sender-init vs. receiver-init would be less important. With > > > the current text > > > in GIMPS, there is still a subtle difference, e.g. in D-mode, > > > sender-init > > > could send NSLP message with the "GIMPS-query" message. > > > > > > As for the messaging association establishment, it is a GIMPS level > > > signaling. According to the text in section 4.3, it has to be > > > initiated from > > > upstream. What is lacking is how this process is triggered > > > (maybe out of > > > scope). What I am not so sure is that if it is triggered by a > > > message sent > > > by the receiver, e.g. a BU from a MN, could we call it > > > receiver initiated? > > > > > > > > > > definitions of these two terms is rather fuzzy (even in the > > > > framework). with > > > > path-coupled signaling only the sender is able to start signaling. > > > > > > Do you mean the GIMPS signaling described above? I feel it > > > depends on what > > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > > > NTLP and NSLP), > > > it is quite true. > > > > > > > > > cheers > > > > > > Cheng Hong > > > > > > > > > > 'maintaining the treatment for a flow' is also difficult to > > > > understand in > > > > the light of our mobility discussions or the recently > > > > discussed preemption > > > > issues. > > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > > > > > > Thanks for your replies, > > > > > Elena > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > -- > > > > Visit our website at www.roke.co.uk > > > > Registered Office: Roke Manor Research Ltd, Siemens House, > > Oldbury, Bracknell, > > Berkshire. RG12 8FZ > > > > The information contained in this e-mail and any attachments > > is confidential to > > Roke Manor Research Ltd and must not be passed to any third > > party without > > permission. This communication is for information only and > > shall not create or > > change any contractual relationship. > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 10:17:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26988 for ; Wed, 7 Apr 2004 10:17:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDrX-0003s8-9C for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 10:17:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37EH7dh014871 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 10:17:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDrW-0003q7-NZ; Wed, 07 Apr 2004 10:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDqi-0003MQ-Jt for nsis@optimus.ietf.org; Wed, 07 Apr 2004 10:16:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26525 for ; Wed, 7 Apr 2004 10:16:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBDqg-0002Kd-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:16:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBCxH-0002f4-00 for nsis@ietf.org; Wed, 07 Apr 2004 09:19:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBBb2-0002SQ-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:51:57 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBBaw-0003wv-LE for nsis@ietf.org; Wed, 07 Apr 2004 07:51:50 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i37BpX9r061250 for ; Wed, 7 Apr 2004 13:51:38 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i37BmABj061002 for ; Wed, 7 Apr 2004 13:48:10 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i37BmA9h061001; Wed, 07 Apr 2004 13:48:10 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 83F8A120EAA; Wed, 7 Apr 2004 13:48:08 +0200 (CEST) Date: Wed, 07 Apr 2004 13:48:06 +0200 From: Martin Stiemerling To: john.loughney@nokia.com, robert.hancock@roke.co.uk, nsis@ietf.org Subject: Re: [NSIS] Potential Interim Meeting Message-ID: <2147483647.1081345686@[10.1.1.109]> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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, An interim meeting would be good to have at end of May , but only if we have intermediate I-D versions beforehand. So I'm in favour of doing an interim. Martin --On Mittwoch, 7. April 2004 7:22 Uhr +0300 john.loughney@nokia.com wrote: | Hi Robert, | |> *) a review to look for nice-to-have functionality to remove. |> *) set up common guidelines on message formats (with the NSLP |> people). |> *) define some sort of (abstracted) API between NSLPs and |> GIMPS (not technically part of the standard but necessary to |> clarify some of our thinking). |> *) clarify what bits of NAT handling functionality go where |> (in conjunction with the NATFW NSLP people), and whether the |> NATFW NSLP has any special requirements on GIMPS. |> *) start work on some of the error conditions (reboot handling, |> last-node problem and so on). | | That sounds good. | |> So far as mechanisms for progress are concerned, I can |> certainly see the value in something like an interim, if |> enough people want to come (I'm less of a fan of wide-open |> conference calls until we have really precisely defined |> issues to be finalised, but that may just be a personal |> issue). |> |> Siemens would be happy to host such a meeting in Europe, |> probably the UK. May is a nice month here, at least |> sometimes. In the meantime, any input on the current draft |> would of course be appreciated... | | Is there any interest in an interm meeting? We need to schedule | it soon, as there must be a 30 prior announcement of any | interim meeting. | | John | | _______________________________________________ | nsis mailing list | nsis@ietf.org | https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 10:20:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27825 for ; Wed, 7 Apr 2004 10:20:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDuO-0005lv-Df for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 10:20:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37EK4et022172 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 10:20:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDuO-0005lI-72; Wed, 07 Apr 2004 10:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDtq-0005Os-Vg for nsis@optimus.ietf.org; Wed, 07 Apr 2004 10:19:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27518 for ; Wed, 7 Apr 2004 10:19:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBDto-0002v4-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:19:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBD5o-0003TO-00 for nsis@ietf.org; Wed, 07 Apr 2004 09:27:49 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BBBec-00034I-00 for nsis@ietf.org; Wed, 07 Apr 2004 07:55:38 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i37BtbAh016121 for ; Wed, 7 Apr 2004 13:55:37 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 13:55:37 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <2CQC2H5Y>; Wed, 7 Apr 2004 13:56:08 +0200 Message-ID: From: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'Takako Sanda'" , nsis@ietf.org Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 13:57:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 07 Apr 2004 11:55:37.0438 (UTC) FILETIME=[3DB8D7E0:01C41C97] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 Takako Sanda, Yes, I think you are right, if sender would like to receive RESPONSE transported back by NTLP pear-to-pear, QUERY should contain SESSION_ID. But RESPONSE can also be sent directly to sender, if sender address is known by e.g. NSLP layer. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Takako Sanda > Sent: Wednesday, April 07, 2004 10:53 AM > To: nsis@ietf.org > Subject: Re: [NSIS] About GIMPS! > > > Hi all, > > I have an additional questions about GIMPS state. > > Section 4.1 of GIMPS draft says the GIMPS layer maintains message > routing state by using primary key consists of {flow routing info, > session id, signaling application id}. > However, when a signaling application data is QUERY, which used for > finding out available resources, it may not contain flow > information or > session id. This case GIMPS cannot maintain routing state as above > though QUERY message requires RESPONSE which should be forwarded > peer-to-peer back to QUERY sender by using NSLP level routing > association (section 3.5.2 of QoS NSLP draft). > So, I think alternative state management method may be required. > > If I have any misunderstandings, please point them out. > > Best Regards, > Takako Sanda > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 13:21:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14243 for ; Wed, 7 Apr 2004 13:21:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGjZ-0002YV-UU for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 13:21:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HL5YY009819 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 13:21:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGjZ-0002Xq-FR; Wed, 07 Apr 2004 13:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGjB-0002RI-EN for nsis@optimus.ietf.org; Wed, 07 Apr 2004 13:20:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14097 for ; Wed, 7 Apr 2004 13:20:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGj9-0000H3-00 for nsis@ietf.org; Wed, 07 Apr 2004 13:20:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFUq-0005Jw-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:01:49 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BBE3u-0004Mc-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:29:59 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <2M89N6X7>; Wed, 7 Apr 2004 15:29:22 +0100 Message-ID: From: "Hancock, Robert" To: "'Thanh Tra LUU'" , Tschofenig Hannes Cc: "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 15:29:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , A clarification: when we (I) mention 'asymmetry', we are not talking about asymmetry in the IP routing (which we know happens, and we know is handled by the message routing mechanisms in GIMPS). We are talking about asymmetry in the signalling protocol, e.g. in that the two ends of the signalling conversation may have different 'roles'. That is a point that would arise even if we had symmetric routing at the IP level, in fact. r. > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr] > Sent: Wednesday, April 07, 2004 12:49 > To: Tschofenig Hannes > Cc: 'nsis' > Subject: Re: [NSIS] About GIMPS! > > > hi Hannes, > > i think there is no asymmetric routing here. In the mode > receiver-initiator, > the recevier maintains the forward state ( Resv state in > RSVP). However, the > sender must discover the data path in anycase and there in > only one data > path (sender -> receiver). > > Nary Tra, > ENST, Paris. > > ----- Original Message ----- > From: "Tschofenig Hannes" > To: "'Hancock, Robert'" ; "'Cheng Hong'" > ; "'Elena Scialpi'" ; "'nsis'" > > Sent: Wednesday, April 07, 2004 11:11 AM > Subject: RE: [NSIS] About GIMPS! > > > > hi robert, > > > > i guess we all agree that there is asymmetry in the discovery phase. > > i only have problems with the "original definition" of sender- vs. > > receiver-initiated reservations. the do not fit into the > nsis picture. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: Wednesday, April 07, 2004 10:49 AM > > > To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis' > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > dear all, > > > > > > if people want to see the reasoning which went into the current > > > framework split, it is still written down in > > > http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-r > > > eceiver-00.txt > > > > > > the essential points are: > > > a) does a protocol have any asymmetry in operation (i.e. > > > client/server, > > > initiator/responder, whatever) > > > b) if so, does that asymmetry have any coupling to the > direction of > > > the data flow > > > > > > the argument of the above i-d (reflected in the framework and the > > > subsequent protocol designs) is that these questions have to be > > > considered independently for the NTLP (GIMPS) and NSLPs > (signalling > > > applications). > > > > > > Specifically for GIMPS, there is asymmetry in the discovery phase, > > > because only the upstream node can initiate the process (that's a > > > consequence of IP routing) as Cheng says below. (Whether you want > > > to call this sender or receiver initiated is just a terminology > > > issue.) If we can think of ways to make discovery possible in both > > > directions, we might incorporate them. However, once the message > > > routing state is set up, GIMPS tries as hard as possible to hide > > > this asymmetry from the signalling applications. They can > make their > > > own decisions about whether aspects of their protocol should be > > > directional and whether to tie that to data flow direction. > > > > > > What is definitely the case is that GIMPS punts on what > initiates the > > > discovery process in the first place. This is a trigger from the > > > OS or a particular signalling application, or network management, > > > or whatever. Signalling application developers need to say what > > > kicks off this part of the process. > > > > > > Does this answer the question? > > > > > > r. > > > > > > > -----Original Message----- > > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > > Sent: Wednesday, April 07, 2004 03:52 > > > > To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis' > > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > if you decouple the authorization aspects from the signaling > > > > > aspects then > > > > > the concepts of sender- vs. receiver-initiated "something" > > > > > are less obvious > > > > > in a path-coupled signaling protocol. i personally > think that the > > > > > > > > I think if we further decouple the messaging association > > > establishing > > > > procedure (GIMPS) from the actual signaling (NSLP > signaling), the > > > > sender-init vs. receiver-init would be less important. With > > > > the current text > > > > in GIMPS, there is still a subtle difference, e.g. in D-mode, > > > > sender-init > > > > could send NSLP message with the "GIMPS-query" message. > > > > > > > > As for the messaging association establishment, it is a > GIMPS level > > > > signaling. According to the text in section 4.3, it has to be > > > > initiated from > > > > upstream. What is lacking is how this process is triggered > > > > (maybe out of > > > > scope). What I am not so sure is that if it is triggered by a > > > > message sent > > > > by the receiver, e.g. a BU from a MN, could we call it > > > > receiver initiated? > > > > > > > > > > > > > definitions of these two terms is rather fuzzy (even in the > > > > > framework). with > > > > > path-coupled signaling only the sender is able to > start signaling. > > > > > > > > Do you mean the GIMPS signaling described above? I feel it > > > > depends on what > > > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > > > > NTLP and NSLP), > > > > it is quite true. > > > > > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > 'maintaining the treatment for a flow' is also difficult to > > > > > understand in > > > > > the light of our mobility discussions or the recently > > > > > discussed preemption > > > > > issues. > > > > > > > > > > ciao > > > > > hannes > > > > > > > > > > > > > > > > > > > > > > Thanks for your replies, > > > > > > Elena > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > -- > > > > > > Visit our website at www.roke.co.uk > > > > > > Registered Office: Roke Manor Research Ltd, Siemens House, > > > Oldbury, Bracknell, > > > Berkshire. RG12 8FZ > > > > > > The information contained in this e-mail and any attachments > > > is confidential to > > > Roke Manor Research Ltd and must not be passed to any third > > > party without > > > permission. This communication is for information only and > > > shall not create or > > > change any contractual relationship. > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 13:22:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14466 for ; Wed, 7 Apr 2004 13:22:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGkT-0003Sz-Nb for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 13:22:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HM1WD013300 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 13:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGkT-0003SQ-GA; Wed, 07 Apr 2004 13:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGjt-0002jK-3z for nsis@optimus.ietf.org; Wed, 07 Apr 2004 13:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14167 for ; Wed, 7 Apr 2004 13:21:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGjq-0000Hz-00 for nsis@ietf.org; Wed, 07 Apr 2004 13:21:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFV4-0005M6-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:02:03 -0400 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBE4O-0004Rd-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:30:24 -0400 Received: from HP11517441532 (dhcp192-244.enst.fr [137.194.192.244]) by infres.enst.fr (Postfix) with SMTP id E317D3022; Wed, 7 Apr 2004 16:30:20 +0200 (MEST) Message-ID: <00e701c41cac$da621470$f4c0c289@HP11517441532> From: "Thanh Tra LUU" To: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= Cc: References: Subject: Re: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 16:30:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi Attila, if i dont miss something, QoS-NSLP can use other protocols than NTLP as a transport protocol (ex UDP, TCP). in the case you mention, NSLP receiver = (or any signaling entities) can directly send a message to sender (or any signaling entities) using TCP,UDP, SCTP. Nary Tra, ENST, Paris. ----- Original Message ----- From: "Attila B=E1der (IJ/ETH)" To: "'Takako Sanda'" ; Sent: Wednesday, April 07, 2004 1:57 PM Subject: RE: [NSIS] About GIMPS! > > Hi Takako Sanda, > > Yes, I think you are right, if sender would like to receive RESPONSE transported back by NTLP pear-to-pear, QUERY should contain SESSION_ID. B= ut RESPONSE can also be sent directly to sender, if sender address is known = by e.g. NSLP layer. > > Best regards, Attila _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 13:22:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14484 for ; Wed, 7 Apr 2004 13:22:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGkW-0003bm-1I for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 13:22:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HM2OX013518 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 13:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGkU-0003V8-Hb; Wed, 07 Apr 2004 13:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGjz-0002yS-Rc for nsis@optimus.ietf.org; Wed, 07 Apr 2004 13:21:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14194 for ; Wed, 7 Apr 2004 13:21:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGjx-0000J5-00 for nsis@ietf.org; Wed, 07 Apr 2004 13:21:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFVU-0005Pz-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:02:29 -0400 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBE5K-0004W8-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:31:22 -0400 Received: from HP11517441532 (dhcp192-244.enst.fr [137.194.192.244]) by infres.enst.fr (Postfix) with SMTP id 9C1C1302B; Wed, 7 Apr 2004 16:31:21 +0200 (MEST) Message-ID: <00e801c41cac$fe92e950$f4c0c289@HP11517441532> From: "Thanh Tra LUU" To: "Tschofenig Hannes" Cc: "'nsis'" References: <2A8DB02E3018D411901B009027FD3A3F04685FB7@mchp905a.mch.sbs.de> Subject: Re: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 16:31:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Hannes, the asymmetric routing is mentioned in nsis requirements . so i think it is clear here. Is it right that routing record is not used in GIMPS ? Nary Tra, ENST, Paris ----- Original Message ----- From: "Tschofenig Hannes" To: "'Thanh Tra LUU'" Cc: "'nsis'" Sent: Wednesday, April 07, 2004 4:04 PM Subject: RE: [NSIS] About GIMPS! > hi nary, > > with asymmetric routes and path-coupled signaling the first message > (discovery) needs to be sent from the data sender. > > if you would like to send signaling messages back (from the receiver to the > sender) along the same path then you need to either > - establish some information at each intermediate node or > - do something like record route > to allow your messages to travel back along the same path. > > ciao > hannes > > > hi Hannes, > > > > i think there is no asymmetric routing here. In the mode > > receiver-initiator, > > the recevier maintains the forward state ( Resv state in > > RSVP). However, the > > sender must discover the data path in anycase and there in > > only one data > > path (sender -> receiver). > > > > Nary Tra, > > ENST, Paris. > > > > ----- Original Message ----- > > From: "Tschofenig Hannes" > > To: "'Hancock, Robert'" ; "'Cheng Hong'" > > ; "'Elena Scialpi'" ; "'nsis'" > > > > Sent: Wednesday, April 07, 2004 11:11 AM > > Subject: RE: [NSIS] About GIMPS! > > > > > > > hi robert, > > > > > > i guess we all agree that there is asymmetry in the discovery phase. > > > i only have problems with the "original definition" of sender- vs. > > > receiver-initiated reservations. the do not fit into the > > nsis picture. > > > > > > ciao > > > hannes > > > > > > > > > > -----Original Message----- > > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > Sent: Wednesday, April 07, 2004 10:49 AM > > > > To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis' > > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > > > > dear all, > > > > > > > > if people want to see the reasoning which went into the current > > > > framework split, it is still written down in > > > > http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-r > > > > eceiver-00.txt > > > > > > > > the essential points are: > > > > a) does a protocol have any asymmetry in operation (i.e. > > > > client/server, > > > > initiator/responder, whatever) > > > > b) if so, does that asymmetry have any coupling to the > > direction of > > > > the data flow > > > > > > > > the argument of the above i-d (reflected in the framework and the > > > > subsequent protocol designs) is that these questions have to be > > > > considered independently for the NTLP (GIMPS) and NSLPs > > (signalling > > > > applications). > > > > > > > > Specifically for GIMPS, there is asymmetry in the discovery phase, > > > > because only the upstream node can initiate the process (that's a > > > > consequence of IP routing) as Cheng says below. (Whether you want > > > > to call this sender or receiver initiated is just a terminology > > > > issue.) If we can think of ways to make discovery possible in both > > > > directions, we might incorporate them. However, once the message > > > > routing state is set up, GIMPS tries as hard as possible to hide > > > > this asymmetry from the signalling applications. They can > > make their > > > > own decisions about whether aspects of their protocol should be > > > > directional and whether to tie that to data flow direction. > > > > > > > > What is definitely the case is that GIMPS punts on what > > initiates the > > > > discovery process in the first place. This is a trigger from the > > > > OS or a particular signalling application, or network management, > > > > or whatever. Signalling application developers need to say what > > > > kicks off this part of the process. > > > > > > > > Does this answer the question? > > > > > > > > r. > > > > > > > > > -----Original Message----- > > > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > > > Sent: Wednesday, April 07, 2004 03:52 > > > > > To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis' > > > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > > if you decouple the authorization aspects from the signaling > > > > > > aspects then > > > > > > the concepts of sender- vs. receiver-initiated "something" > > > > > > are less obvious > > > > > > in a path-coupled signaling protocol. i personally > > think that the > > > > > > > > > > I think if we further decouple the messaging association > > > > establishing > > > > > procedure (GIMPS) from the actual signaling (NSLP > > signaling), the > > > > > sender-init vs. receiver-init would be less important. With > > > > > the current text > > > > > in GIMPS, there is still a subtle difference, e.g. in D-mode, > > > > > sender-init > > > > > could send NSLP message with the "GIMPS-query" message. > > > > > > > > > > As for the messaging association establishment, it is a > > GIMPS level > > > > > signaling. According to the text in section 4.3, it has to be > > > > > initiated from > > > > > upstream. What is lacking is how this process is triggered > > > > > (maybe out of > > > > > scope). What I am not so sure is that if it is triggered by a > > > > > message sent > > > > > by the receiver, e.g. a BU from a MN, could we call it > > > > > receiver initiated? > > > > > > > > > > > > > > > > definitions of these two terms is rather fuzzy (even in the > > > > > > framework). with > > > > > > path-coupled signaling only the sender is able to > > start signaling. > > > > > > > > > > Do you mean the GIMPS signaling described above? I feel it > > > > > depends on what > > > > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > > > > > NTLP and NSLP), > > > > > it is quite true. > > > > > > > > > > > > > > > cheers > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > 'maintaining the treatment for a flow' is also difficult to > > > > > > understand in > > > > > > the light of our mobility discussions or the recently > > > > > > discussed preemption > > > > > > issues. > > > > > > > > > > > > ciao > > > > > > hannes > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your replies, > > > > > > > Elena > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > > > > > > -- > > > > > > > > Visit our website at www.roke.co.uk > > > > > > > > Registered Office: Roke Manor Research Ltd, Siemens House, > > > > Oldbury, Bracknell, > > > > Berkshire. RG12 8FZ > > > > > > > > The information contained in this e-mail and any attachments > > > > is confidential to > > > > Roke Manor Research Ltd and must not be passed to any third > > > > party without > > > > permission. This communication is for information only and > > > > shall not create or > > > > change any contractual relationship. > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 13:25:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15444 for ; Wed, 7 Apr 2004 13:25:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGnb-0005ci-49 for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 13:25:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HPFW3021608 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 13:25:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGnZ-0005Yl-F5; Wed, 07 Apr 2004 13:25:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGn4-0005My-H3 for nsis@optimus.ietf.org; Wed, 07 Apr 2004 13:24:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15148 for ; Wed, 7 Apr 2004 13:24:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGn2-0000uI-00 for nsis@ietf.org; Wed, 07 Apr 2004 13:24:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFe0-0006xm-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:11:17 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BBEM5-0005xW-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:48:41 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i37EmbPA009044 for ; Wed, 7 Apr 2004 16:48:41 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 16:48:37 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <2CQCJ8T1>; Wed, 7 Apr 2004 16:49:06 +0200 Message-ID: From: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'Thanh Tra LUU'" Cc: nsis@ietf.org Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 16:51:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 Apr 2004 14:48:37.0551 (UTC) FILETIME=[68C063F0:01C41CAF] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Nary Tra, I am afraid that using other transport protocol than NTLP would not be = NSIS compliant. Instead NTLP should support this function, see 5.1.5 of = QoS-NSLP draft: "The forwarding of the RESPONSE message along the path does not necessarily imply the existence of NTLP reverse-path state at every node. For example, the NTLP may have a mechanism to pass a message directly from the egress to the ingress of a region of QNEs that do not store per-flow reverse-path state." Best regards, Attila > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr] > Sent: Wednesday, April 07, 2004 4:30 PM > To: Attila B=E1der (IJ/ETH) > Cc: nsis@ietf.org > Subject: Re: [NSIS] About GIMPS! >=20 >=20 > hi Attila, >=20 > if i dont miss something, QoS-NSLP can use other protocols=20 > than NTLP as a > transport protocol (ex UDP, TCP). in the case you mention,=20 > NSLP receiver (or > any signaling entities) can directly send a message to sender (or any > signaling entities) using TCP,UDP, SCTP. >=20 > Nary Tra, > ENST, Paris. >=20 > ----- Original Message ----- > From: "Attila B=E1der (IJ/ETH)" > To: "'Takako Sanda'" ; > Sent: Wednesday, April 07, 2004 1:57 PM > Subject: RE: [NSIS] About GIMPS! >=20 >=20 > > > > Hi Takako Sanda, > > > > Yes, I think you are right, if sender would like to receive = RESPONSE > transported back by NTLP pear-to-pear, QUERY should contain=20 > SESSION_ID. But > RESPONSE can also be sent directly to sender, if sender=20 > address is known by > e.g. NSLP layer. > > > > Best regards, Attila >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 13:27:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15734 for ; Wed, 7 Apr 2004 13:27:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGpN-0006YP-16 for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 13:27:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HR4vV025188 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 13:27:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGpM-0006Xo-NS; Wed, 07 Apr 2004 13:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGod-0006DP-8Z for nsis@optimus.ietf.org; Wed, 07 Apr 2004 13:26:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15661 for ; Wed, 7 Apr 2004 13:26:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGob-0001Cv-00 for nsis@ietf.org; Wed, 07 Apr 2004 13:26:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFh5-0007VL-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:14:29 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BBEQb-0006KJ-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:53:21 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i37ErKY05420; Wed, 7 Apr 2004 16:53:20 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i37ErKQ19374; Wed, 7 Apr 2004 16:53:20 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 16:52:31 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FC0@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Elena Scialpi'" , nsis Subject: RE: [NSIS] A stupid question! Date: Wed, 7 Apr 2004 16:52:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 elena, there are no stupid questions. > I've question for you: > > In NSIS there are many divisions : > > -NTLP and NSLP; > -sender-initiated and received-initiated; > -NTLP in GIMPS and transport protocol. > > Why ? Only for flexibility of the protocol? > Could you give me, in few words , the main reasons for this divisions! the two -layer split was introduced because a number of "applications" (e.g., qos, nat/fw, ....) seem to use common functionality in path-coupled signaling. people tend to group those things together and to avoid thinking about the same issues again and again for "applications" sharing the same functionality. furthermore, there is the code-reuse argument. (there is certainly more....) the terms sender-initiated and received-initiated reservation is a historical left-over. it would be good to receive some comments on how people would like to see the authorization procedure to happen. we have written a draft which tried to trigger some discussion (please take a look at: http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-aaa-issues-01.pdf) different transport protocols in gimps: different transport protocols have different properties and may be used in different environments and in different parts of the end-to-end path. one size does not fit all scenarios. does this make sense to you? ciao hannes > > Exuse my stupid question, thanks, > Elena > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 13:27:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15736 for ; Wed, 7 Apr 2004 13:27:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGpN-0006ZQ-Fc for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 13:27:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HR5bw025227 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 13:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGpN-0006Yl-Aa; Wed, 07 Apr 2004 13:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGod-0006Db-VX for nsis@optimus.ietf.org; Wed, 07 Apr 2004 13:26:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15667 for ; Wed, 7 Apr 2004 13:26:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGob-0001D7-00 for nsis@ietf.org; Wed, 07 Apr 2004 13:26:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFh9-0007W6-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:14:33 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BBEQi-0006Ks-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:53:28 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i37ErRY05530; Wed, 7 Apr 2004 16:53:27 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i37ErRQ19503; Wed, 7 Apr 2004 16:53:27 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 16:52:38 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FC1@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Hancock, Robert'" , "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 16:53:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, regarding asymmetry of operation: i also agree that there is some asymmetry in operation in various ways. not only end-to-end but also between neighboring nodes. many security protocols are asymmetric (e.g., tls). how could this observation of operational asymmetry help us for authorization issues ( i avoid the sender- vs. receiver- initiated reservations for a moment)? ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Wednesday, April 07, 2004 4:29 PM > To: 'Thanh Tra LUU'; Tschofenig Hannes > Cc: 'nsis' > Subject: RE: [NSIS] About GIMPS! > > > A clarification: when we (I) mention 'asymmetry', > we are not talking about asymmetry in the IP routing > (which we know happens, and we know is handled by the > message routing mechanisms in GIMPS). > > We are talking about asymmetry in the signalling protocol, > e.g. in that the two ends of the signalling conversation > may have different 'roles'. That is a point that would > arise even if we had symmetric routing at the IP level, > in fact. > > r. > > > -----Original Message----- > > From: Thanh Tra LUU [mailto:luu@enst.fr] > > Sent: Wednesday, April 07, 2004 12:49 > > To: Tschofenig Hannes > > Cc: 'nsis' > > Subject: Re: [NSIS] About GIMPS! > > > > > > hi Hannes, > > > > i think there is no asymmetric routing here. In the mode > > receiver-initiator, > > the recevier maintains the forward state ( Resv state in > > RSVP). However, the > > sender must discover the data path in anycase and there in > > only one data > > path (sender -> receiver). > > > > Nary Tra, > > ENST, Paris. > > > > ----- Original Message ----- > > From: "Tschofenig Hannes" > > To: "'Hancock, Robert'" ; "'Cheng Hong'" > > ; "'Elena Scialpi'" ; "'nsis'" > > > > Sent: Wednesday, April 07, 2004 11:11 AM > > Subject: RE: [NSIS] About GIMPS! > > > > > > > hi robert, > > > > > > i guess we all agree that there is asymmetry in the > discovery phase. > > > i only have problems with the "original definition" of sender- vs. > > > receiver-initiated reservations. the do not fit into the > > nsis picture. > > > > > > ciao > > > hannes > > > > > > > > > > -----Original Message----- > > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > Sent: Wednesday, April 07, 2004 10:49 AM > > > > To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis' > > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > > > > dear all, > > > > > > > > if people want to see the reasoning which went into the current > > > > framework split, it is still written down in > > > > http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-r > > > > eceiver-00.txt > > > > > > > > the essential points are: > > > > a) does a protocol have any asymmetry in operation (i.e. > > > > client/server, > > > > initiator/responder, whatever) > > > > b) if so, does that asymmetry have any coupling to the > > direction of > > > > the data flow > > > > > > > > the argument of the above i-d (reflected in the > framework and the > > > > subsequent protocol designs) is that these questions have to be > > > > considered independently for the NTLP (GIMPS) and NSLPs > > (signalling > > > > applications). > > > > > > > > Specifically for GIMPS, there is asymmetry in the > discovery phase, > > > > because only the upstream node can initiate the process > (that's a > > > > consequence of IP routing) as Cheng says below. > (Whether you want > > > > to call this sender or receiver initiated is just a terminology > > > > issue.) If we can think of ways to make discovery > possible in both > > > > directions, we might incorporate them. However, once the message > > > > routing state is set up, GIMPS tries as hard as possible to hide > > > > this asymmetry from the signalling applications. They can > > make their > > > > own decisions about whether aspects of their protocol should be > > > > directional and whether to tie that to data flow direction. > > > > > > > > What is definitely the case is that GIMPS punts on what > > initiates the > > > > discovery process in the first place. This is a trigger from the > > > > OS or a particular signalling application, or network > management, > > > > or whatever. Signalling application developers need to say what > > > > kicks off this part of the process. > > > > > > > > Does this answer the question? > > > > > > > > r. > > > > > > > > > -----Original Message----- > > > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > > > Sent: Wednesday, April 07, 2004 03:52 > > > > > To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis' > > > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > > if you decouple the authorization aspects from the signaling > > > > > > aspects then > > > > > > the concepts of sender- vs. receiver-initiated "something" > > > > > > are less obvious > > > > > > in a path-coupled signaling protocol. i personally > > think that the > > > > > > > > > > I think if we further decouple the messaging association > > > > establishing > > > > > procedure (GIMPS) from the actual signaling (NSLP > > signaling), the > > > > > sender-init vs. receiver-init would be less important. With > > > > > the current text > > > > > in GIMPS, there is still a subtle difference, e.g. in D-mode, > > > > > sender-init > > > > > could send NSLP message with the "GIMPS-query" message. > > > > > > > > > > As for the messaging association establishment, it is a > > GIMPS level > > > > > signaling. According to the text in section 4.3, it has to be > > > > > initiated from > > > > > upstream. What is lacking is how this process is triggered > > > > > (maybe out of > > > > > scope). What I am not so sure is that if it is triggered by a > > > > > message sent > > > > > by the receiver, e.g. a BU from a MN, could we call it > > > > > receiver initiated? > > > > > > > > > > > > > > > > definitions of these two terms is rather fuzzy (even in the > > > > > > framework). with > > > > > > path-coupled signaling only the sender is able to > > start signaling. > > > > > > > > > > Do you mean the GIMPS signaling described above? I feel it > > > > > depends on what > > > > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > > > > > NTLP and NSLP), > > > > > it is quite true. > > > > > > > > > > > > > > > cheers > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > 'maintaining the treatment for a flow' is also difficult to > > > > > > understand in > > > > > > the light of our mobility discussions or the recently > > > > > > discussed preemption > > > > > > issues. > > > > > > > > > > > > ciao > > > > > > hannes > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your replies, > > > > > > > Elena > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > > > > > > -- > > > > > > > > Visit our website at www.roke.co.uk > > > > > > > > Registered Office: Roke Manor Research Ltd, Siemens House, > > > > Oldbury, Bracknell, > > > > Berkshire. RG12 8FZ > > > > > > > > The information contained in this e-mail and any attachments > > > > is confidential to > > > > Roke Manor Research Ltd and must not be passed to any third > > > > party without > > > > permission. This communication is for information only and > > > > shall not create or > > > > change any contractual relationship. > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -- > > Visit our website at www.roke.co.uk > > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to > Roke Manor Research Ltd and must not be passed to any third > party without > permission. This communication is for information only and > shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 13:43:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17254 for ; Wed, 7 Apr 2004 13:43:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH50-0005xu-Rp for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 13:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HhE6b022854 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 13:43:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH4v-0005vc-Pi; Wed, 07 Apr 2004 13:43:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH48-000572-Oa for nsis@optimus.ietf.org; Wed, 07 Apr 2004 13:42:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16882 for ; Wed, 7 Apr 2004 13:42:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBH46-0003MH-00 for nsis@ietf.org; Wed, 07 Apr 2004 13:42:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBG5X-0001xJ-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:39:46 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BBEb1-00076d-00 for nsis@ietf.org; Wed, 07 Apr 2004 11:04:08 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i37F46B18398; Wed, 7 Apr 2004 17:04:07 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i37F46Q01211; Wed, 7 Apr 2004 17:04:06 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 17:03:18 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FC2@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 17:03:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi nary, > hi Hannes, > > the asymmetric routing is mentioned in nsis requirements . so > i think it is > clear here. > > Is it right that routing record is not used in GIMPS ? version -01 says that the record route has been removed (see section 9.1 - change history; bullet 10). ciao hannes > > Nary Tra, > ENST, Paris > > ----- Original Message ----- > From: "Tschofenig Hannes" > To: "'Thanh Tra LUU'" > Cc: "'nsis'" > Sent: Wednesday, April 07, 2004 4:04 PM > Subject: RE: [NSIS] About GIMPS! > > > > hi nary, > > > > with asymmetric routes and path-coupled signaling the first message > > (discovery) needs to be sent from the data sender. > > > > if you would like to send signaling messages back (from the > receiver to > the > > sender) along the same path then you need to either > > - establish some information at each intermediate node or > > - do something like record route > > to allow your messages to travel back along the same path. > > > > ciao > > hannes > > > > > hi Hannes, > > > > > > i think there is no asymmetric routing here. In the mode > > > receiver-initiator, > > > the recevier maintains the forward state ( Resv state in > > > RSVP). However, the > > > sender must discover the data path in anycase and there in > > > only one data > > > path (sender -> receiver). > > > > > > Nary Tra, > > > ENST, Paris. > > > > > > ----- Original Message ----- > > > From: "Tschofenig Hannes" > > > To: "'Hancock, Robert'" ; > "'Cheng Hong'" > > > ; "'Elena Scialpi'" ; "'nsis'" > > > > > > Sent: Wednesday, April 07, 2004 11:11 AM > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > > hi robert, > > > > > > > > i guess we all agree that there is asymmetry in the > discovery phase. > > > > i only have problems with the "original definition" of > sender- vs. > > > > receiver-initiated reservations. the do not fit into the > > > nsis picture. > > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > -----Original Message----- > > > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > > Sent: Wednesday, April 07, 2004 10:49 AM > > > > > To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis' > > > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > > > > > > > dear all, > > > > > > > > > > if people want to see the reasoning which went into > the current > > > > > framework split, it is still written down in > > > > > http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-r > > > > > eceiver-00.txt > > > > > > > > > > the essential points are: > > > > > a) does a protocol have any asymmetry in operation (i.e. > > > > > client/server, > > > > > initiator/responder, whatever) > > > > > b) if so, does that asymmetry have any coupling to the > > > direction of > > > > > the data flow > > > > > > > > > > the argument of the above i-d (reflected in the > framework and the > > > > > subsequent protocol designs) is that these questions > have to be > > > > > considered independently for the NTLP (GIMPS) and NSLPs > > > (signalling > > > > > applications). > > > > > > > > > > Specifically for GIMPS, there is asymmetry in the > discovery phase, > > > > > because only the upstream node can initiate the > process (that's a > > > > > consequence of IP routing) as Cheng says below. > (Whether you want > > > > > to call this sender or receiver initiated is just a > terminology > > > > > issue.) If we can think of ways to make discovery > possible in both > > > > > directions, we might incorporate them. However, once > the message > > > > > routing state is set up, GIMPS tries as hard as > possible to hide > > > > > this asymmetry from the signalling applications. They can > > > make their > > > > > own decisions about whether aspects of their protocol > should be > > > > > directional and whether to tie that to data flow direction. > > > > > > > > > > What is definitely the case is that GIMPS punts on what > > > initiates the > > > > > discovery process in the first place. This is a > trigger from the > > > > > OS or a particular signalling application, or network > management, > > > > > or whatever. Signalling application developers need > to say what > > > > > kicks off this part of the process. > > > > > > > > > > Does this answer the question? > > > > > > > > > > r. > > > > > > > > > > > -----Original Message----- > > > > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > > > > Sent: Wednesday, April 07, 2004 03:52 > > > > > > To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis' > > > > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > > > > > > if you decouple the authorization aspects from > the signaling > > > > > > > aspects then > > > > > > > the concepts of sender- vs. receiver-initiated "something" > > > > > > > are less obvious > > > > > > > in a path-coupled signaling protocol. i personally > > > think that the > > > > > > > > > > > > I think if we further decouple the messaging association > > > > > establishing > > > > > > procedure (GIMPS) from the actual signaling (NSLP > > > signaling), the > > > > > > sender-init vs. receiver-init would be less important. With > > > > > > the current text > > > > > > in GIMPS, there is still a subtle difference, e.g. > in D-mode, > > > > > > sender-init > > > > > > could send NSLP message with the "GIMPS-query" message. > > > > > > > > > > > > As for the messaging association establishment, it is a > > > GIMPS level > > > > > > signaling. According to the text in section 4.3, it > has to be > > > > > > initiated from > > > > > > upstream. What is lacking is how this process is triggered > > > > > > (maybe out of > > > > > > scope). What I am not so sure is that if it is > triggered by a > > > > > > message sent > > > > > > by the receiver, e.g. a BU from a MN, could we call it > > > > > > receiver initiated? > > > > > > > > > > > > > > > > > > > definitions of these two terms is rather fuzzy > (even in the > > > > > > > framework). with > > > > > > > path-coupled signaling only the sender is able to > > > start signaling. > > > > > > > > > > > > Do you mean the GIMPS signaling described above? I feel it > > > > > > depends on what > > > > > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > > > > > > NTLP and NSLP), > > > > > > it is quite true. > > > > > > > > > > > > > > > > > > cheers > > > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > 'maintaining the treatment for a flow' is also > difficult to > > > > > > > understand in > > > > > > > the light of our mobility discussions or the recently > > > > > > > discussed preemption > > > > > > > issues. > > > > > > > > > > > > > > ciao > > > > > > > hannes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your replies, > > > > > > > > Elena > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > > > > > > > > > > > > > > -- > > > > > > > > > > Visit our website at www.roke.co.uk > > > > > > > > > > Registered Office: Roke Manor Research Ltd, Siemens House, > > > > > Oldbury, Bracknell, > > > > > Berkshire. RG12 8FZ > > > > > > > > > > The information contained in this e-mail and any attachments > > > > > is confidential to > > > > > Roke Manor Research Ltd and must not be passed to any third > > > > > party without > > > > > permission. This communication is for information only and > > > > > shall not create or > > > > > change any contractual relationship. > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 13:47:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17961 for ; Wed, 7 Apr 2004 13:47:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH8w-0007gZ-Nu for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 13:47:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HlH75029524 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 13:47:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH8t-0007ff-Pj; Wed, 07 Apr 2004 13:47:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGzO-0001hz-A8 for nsis@optimus.ietf.org; Wed, 07 Apr 2004 13:37:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09745 for ; Wed, 7 Apr 2004 12:48:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGE1-0003DM-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:48:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBEmt-0000px-00 for nsis@ietf.org; Wed, 07 Apr 2004 11:16:24 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BBDfs-0000Xz-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:05:04 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i37E53B18679; Wed, 7 Apr 2004 16:05:03 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i37E53Q20707; Wed, 7 Apr 2004 16:05:03 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 16:04:14 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FB7@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: [NSIS] About GIMPS! Date: Wed, 7 Apr 2004 16:04:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi nary, with asymmetric routes and path-coupled signaling the first message (discovery) needs to be sent from the data sender. if you would like to send signaling messages back (from the receiver to the sender) along the same path then you need to either - establish some information at each intermediate node or - do something like record route to allow your messages to travel back along the same path. ciao hannes > hi Hannes, > > i think there is no asymmetric routing here. In the mode > receiver-initiator, > the recevier maintains the forward state ( Resv state in > RSVP). However, the > sender must discover the data path in anycase and there in > only one data > path (sender -> receiver). > > Nary Tra, > ENST, Paris. > > ----- Original Message ----- > From: "Tschofenig Hannes" > To: "'Hancock, Robert'" ; "'Cheng Hong'" > ; "'Elena Scialpi'" ; "'nsis'" > > Sent: Wednesday, April 07, 2004 11:11 AM > Subject: RE: [NSIS] About GIMPS! > > > > hi robert, > > > > i guess we all agree that there is asymmetry in the discovery phase. > > i only have problems with the "original definition" of sender- vs. > > receiver-initiated reservations. the do not fit into the > nsis picture. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: Wednesday, April 07, 2004 10:49 AM > > > To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis' > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > dear all, > > > > > > if people want to see the reasoning which went into the current > > > framework split, it is still written down in > > > http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-r > > > eceiver-00.txt > > > > > > the essential points are: > > > a) does a protocol have any asymmetry in operation (i.e. > > > client/server, > > > initiator/responder, whatever) > > > b) if so, does that asymmetry have any coupling to the > direction of > > > the data flow > > > > > > the argument of the above i-d (reflected in the framework and the > > > subsequent protocol designs) is that these questions have to be > > > considered independently for the NTLP (GIMPS) and NSLPs > (signalling > > > applications). > > > > > > Specifically for GIMPS, there is asymmetry in the discovery phase, > > > because only the upstream node can initiate the process (that's a > > > consequence of IP routing) as Cheng says below. (Whether you want > > > to call this sender or receiver initiated is just a terminology > > > issue.) If we can think of ways to make discovery possible in both > > > directions, we might incorporate them. However, once the message > > > routing state is set up, GIMPS tries as hard as possible to hide > > > this asymmetry from the signalling applications. They can > make their > > > own decisions about whether aspects of their protocol should be > > > directional and whether to tie that to data flow direction. > > > > > > What is definitely the case is that GIMPS punts on what > initiates the > > > discovery process in the first place. This is a trigger from the > > > OS or a particular signalling application, or network management, > > > or whatever. Signalling application developers need to say what > > > kicks off this part of the process. > > > > > > Does this answer the question? > > > > > > r. > > > > > > > -----Original Message----- > > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > > Sent: Wednesday, April 07, 2004 03:52 > > > > To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis' > > > > Subject: RE: [NSIS] About GIMPS! > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > if you decouple the authorization aspects from the signaling > > > > > aspects then > > > > > the concepts of sender- vs. receiver-initiated "something" > > > > > are less obvious > > > > > in a path-coupled signaling protocol. i personally > think that the > > > > > > > > I think if we further decouple the messaging association > > > establishing > > > > procedure (GIMPS) from the actual signaling (NSLP > signaling), the > > > > sender-init vs. receiver-init would be less important. With > > > > the current text > > > > in GIMPS, there is still a subtle difference, e.g. in D-mode, > > > > sender-init > > > > could send NSLP message with the "GIMPS-query" message. > > > > > > > > As for the messaging association establishment, it is a > GIMPS level > > > > signaling. According to the text in section 4.3, it has to be > > > > initiated from > > > > upstream. What is lacking is how this process is triggered > > > > (maybe out of > > > > scope). What I am not so sure is that if it is triggered by a > > > > message sent > > > > by the receiver, e.g. a BU from a MN, could we call it > > > > receiver initiated? > > > > > > > > > > > > > definitions of these two terms is rather fuzzy (even in the > > > > > framework). with > > > > > path-coupled signaling only the sender is able to > start signaling. > > > > > > > > Do you mean the GIMPS signaling described above? I feel it > > > > depends on what > > > > we took as "signaling": NSLP or NSLP+NTLP. But, overall (for > > > > NTLP and NSLP), > > > > it is quite true. > > > > > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > 'maintaining the treatment for a flow' is also difficult to > > > > > understand in > > > > > the light of our mobility discussions or the recently > > > > > discussed preemption > > > > > issues. > > > > > > > > > > ciao > > > > > hannes > > > > > > > > > > > > > > > > > > > > > > Thanks for your replies, > > > > > > Elena > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > -- > > > > > > Visit our website at www.roke.co.uk > > > > > > Registered Office: Roke Manor Research Ltd, Siemens House, > > > Oldbury, Bracknell, > > > Berkshire. RG12 8FZ > > > > > > The information contained in this e-mail and any attachments > > > is confidential to > > > Roke Manor Research Ltd and must not be passed to any third > > > party without > > > permission. This communication is for information only and > > > shall not create or > > > change any contractual relationship. > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 13:58:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20638 for ; Wed, 7 Apr 2004 13:58:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHJK-0004fn-VR for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 13:58:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Hw2Tk017959 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 13:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHJK-0004f4-EW; Wed, 07 Apr 2004 13:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH8n-0007YX-Px for nsis@optimus.ietf.org; Wed, 07 Apr 2004 13:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10407 for ; Wed, 7 Apr 2004 12:56:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGLw-0004B6-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:56:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBEtK-0001jw-00 for nsis@ietf.org; Wed, 07 Apr 2004 11:23:03 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BBDrC-0002QQ-00 for nsis@ietf.org; Wed, 07 Apr 2004 10:16:46 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i37EGjK08263; Wed, 7 Apr 2004 16:16:45 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i37EGjQ07041; Wed, 7 Apr 2004 16:16:45 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 16:15:56 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FBB@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: fred@cisco.com, "'James M. Polk'" Cc: nsis@ietf.org Subject: RE: [NSIS] Questions regarding Date: Wed, 7 Apr 2004 16:16:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 would like to add something to my question with regard to the difference between the sip based preemption approach (draft-ietf-sip-resource-priority-03.txt) and the rsvp preemption approach (rfc2751): draft-ietf-sip-resource-priority-03.txt defines a scheme based on : - enumerations of <'namespace' '.' 'priority value'> pairs. rfc2751 defines a scheme based on: - a preemption priority - a defending priority - and a merging strategy how do they match to each other? which approach would you suggest for the qos nlsp (or for nsis in general)? ciao hannes > -----Original Message----- > From: Tschofenig Hannes > Sent: Saturday, April 03, 2004 8:14 PM > To: fred@cisco.com; 'James M. Polk' > Cc: nsis@ietf.org > Subject: [NSIS] Questions regarding > > > > hi fred, hi james, > > your draft has recently been mentioned in the nsis wg. i have > read the draft > and came across a few issues: > > - the details between the preemption defined in > and seem > to be a bit > different. have you compared them? > > - in section 2.1 you talk about notifying the end hosts about > preemption > (somewhere in the network). also section 1.5 says something similar: > "All callers on the preempted call must be informed that > the call has been preempted, and the call must make way for the > higher precedence call." > > this might be of interest for the qos nslp work in nsis or even for > nat/firewall work?? > > - type 1 encryption > > what do you consider 'type 1 encryption'? > > - authorization > > in section 1.2 you say: > "Since the act of preemption or > consideration of alternative bandwidth sources is part and > parcel of > the problem of providing bandwidth, and the authorization step in > bandwidth provision also affects the choice of networks that may be > authorized to be considered." > > i am not quite sure what you mean with ... also affects the choice of > networks....". > could you elaborate? sounds a bit like qos routing. > > regarding section 2.3.5.2 i suspect that the typical procedure is as > follows: > > a user adds a priority level in his qos request. the > authenticated request > is processed at the first router and forwarded to the "policy decision > point" together with the qos parameters and the indicated > priority level. as > part of the authorization procedure the request is granted or > rejected. if > it is granted then the request (including the priority level) > is forwarded > along the path. is this right? > > a minor issue: there is a bug in section 2.3.3 - the > relationship between > ipsec encrypted traffic and rsvp signaling. you might want to > take a look at > section 5.4 of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-p roperties-04.t xt ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 14:49:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26518 for ; Wed, 7 Apr 2004 14:49:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBI6j-0004Jd-9A for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 14:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37In5H0016590 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 14:49:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBI6i-0004Ix-FZ; Wed, 07 Apr 2004 14:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBI3m-0003Az-6y for nsis@optimus.ietf.org; Wed, 07 Apr 2004 14:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25588 for ; Wed, 7 Apr 2004 14:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBI3g-0004kr-00 for nsis@ietf.org; Wed, 07 Apr 2004 14:45:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBH8T-00048E-00 for nsis@ietf.org; Wed, 07 Apr 2004 13:46:51 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BBGC7-0002tH-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:46:31 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i37GkUB19029; Wed, 7 Apr 2004 18:46:31 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i37GkTi07899; Wed, 7 Apr 2004 18:46:29 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 18:45:40 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FC6@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'fred@cisco.com'" Cc: "'James M. Polk'" , nsis@ietf.org Subject: RE: [NSIS] Questions regarding Date: Wed, 7 Apr 2004 18:46:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 fred, thanks for your response. a quick question to better understand the sip-based approach: i thought that the preemption mechanism is also applicable for sip proxies which handle a large number of calls. now, in emergency cases they might need to drop certain calls. the 'resource-priority' element(s) could be used for it. since architectures (such as the 3gpp) are also using sip as a qos signaling protocol (together with some other mechanism) it seems to be reasonable to compare these two approaches (at least at an abstract level). i might, however, be totally wrong. the sip scenario you describe is somewhat different (and seems to concern the end hosts -users only). what can we learn from (in particular with regard to preemption)? the separation into a namespace and a priority value seems to be useful. ciao hannes > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, April 07, 2004 6:28 PM > To: Tschofenig Hannes > Cc: 'James M. Polk'; nsis@ietf.org > Subject: Re: [NSIS] Questions regarding > > > > Tschofenig Hannes wrote: > > i would like to add something to my question with regard to > the difference > > between the sip based preemption approach > > (draft-ietf-sip-resource-priority-03.txt) and the rsvp > preemption approach > > (rfc2751) > > > > draft-ietf-sip-resource-priority-03.txt defines a scheme based on : > > - enumerations of <'namespace' '.' 'priority value'> pairs. > > > > rfc2751 defines a scheme based on: > > - a preemption priority > > - a defending priority > > - and a merging strategy > > > > how do they match to each other? > > which approach would you suggest for the qos nlsp (or for > nsis in general)? > > > I think you're comparing apples and orangutans. > > The preemption question in SIP is between two calls to the > same device. > If Alice is calling Bob when Bob is talking with Carol, in some > circumstances you would like Bob and Carol to hang up and have Bob's > phone immediately ring with Alice's call. This is not a bandwidth > question, it is a question of the urgency of Alice's call vs the one > currently in progress. > > In addition, if Alice is calling Bob and is using an unusual > DSCP (DISA > wants to use multiple DSCP values instead of a single EF code point), > Bob should be using the same DSCP value Alice does. The Resource > Priority header, by corelated configuration, tells Bob what > DSCP value > to use. > > The question being looked at in capacity admission concerns > choices in > how a finite amount of bandwidth migh be used. If Alice calls > Bob at a > time that some bottleneck link is using all of the bandwidth it is > configured to use for that aggregate of applications (might > be voice or > video, or potentially other real-time applications), it might be > preferable for Carol and Dick's call to be dropped entirely > rather than > simply lose the equivalent of a call's bandwidth distributed > across all > of the ambient calls. > > Capacity admission is a network layer question. The other, > whatever you > choose to call it, is an application layer question. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 7 15:42:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28626 for ; Wed, 7 Apr 2004 15:42:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBIw0-0002AP-0g for nsis-archive@odin.ietf.org; Wed, 07 Apr 2004 15:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Jg3ng008330 for nsis-archive@odin.ietf.org; Wed, 7 Apr 2004 15:42:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBIvy-00028b-3K; Wed, 07 Apr 2004 15:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHgV-0001nZ-SV for nsis@optimus.ietf.org; Wed, 07 Apr 2004 14:21:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23972 for ; Wed, 7 Apr 2004 14:21:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBHgT-00021B-00 for nsis@ietf.org; Wed, 07 Apr 2004 14:21:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBGu6-0001yf-00 for nsis@ietf.org; Wed, 07 Apr 2004 13:31:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BBFuN-0005gY-00 for nsis@ietf.org; Wed, 07 Apr 2004 12:28:11 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2004 08:36:39 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i37GRbGF017718; Wed, 7 Apr 2004 09:27:37 -0700 (PDT) Received: from cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ARV28975; Wed, 7 Apr 2004 09:27:36 -0700 (PDT) Message-ID: <40742BF8.8030201@cisco.com> Date: Wed, 07 Apr 2004 09:27:36 -0700 From: Fred Baker Reply-To: fred@cisco.com Organization: Cisco Systems, IOS Technologies Division User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: "'James M. Polk'" , nsis@ietf.org Subject: Re: [NSIS] Questions regarding References: <2A8DB02E3018D411901B009027FD3A3F04685FBB@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685FBB@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > i would like to add something to my question with regard to the difference > between the sip based preemption approach > (draft-ietf-sip-resource-priority-03.txt) and the rsvp preemption approach > (rfc2751) > > draft-ietf-sip-resource-priority-03.txt defines a scheme based on : > - enumerations of <'namespace' '.' 'priority value'> pairs. > > rfc2751 defines a scheme based on: > - a preemption priority > - a defending priority > - and a merging strategy > > how do they match to each other? > which approach would you suggest for the qos nlsp (or for nsis in general)? I think you're comparing apples and orangutans. The preemption question in SIP is between two calls to the same device. If Alice is calling Bob when Bob is talking with Carol, in some circumstances you would like Bob and Carol to hang up and have Bob's phone immediately ring with Alice's call. This is not a bandwidth question, it is a question of the urgency of Alice's call vs the one currently in progress. In addition, if Alice is calling Bob and is using an unusual DSCP (DISA wants to use multiple DSCP values instead of a single EF code point), Bob should be using the same DSCP value Alice does. The Resource Priority header, by corelated configuration, tells Bob what DSCP value to use. The question being looked at in capacity admission concerns choices in how a finite amount of bandwidth migh be used. If Alice calls Bob at a time that some bottleneck link is using all of the bandwidth it is configured to use for that aggregate of applications (might be voice or video, or potentially other real-time applications), it might be preferable for Carol and Dick's call to be dropped entirely rather than simply lose the equivalent of a call's bandwidth distributed across all of the ambient calls. Capacity admission is a network layer question. The other, whatever you choose to call it, is an application layer question. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 8 10:05:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18832 for ; Thu, 8 Apr 2004 10:05:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBa9q-0007O6-EX for nsis-archive@odin.ietf.org; Thu, 08 Apr 2004 10:05:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38E5Ufe028375 for nsis-archive@odin.ietf.org; Thu, 8 Apr 2004 10:05:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBa9n-0007Ku-3w; Thu, 08 Apr 2004 10:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBa9K-00072F-0y for nsis@optimus.ietf.org; Thu, 08 Apr 2004 10:04:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18587 for ; Thu, 8 Apr 2004 10:04:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBa9H-0004o7-00 for nsis@ietf.org; Thu, 08 Apr 2004 10:04:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBXmN-0004K6-00 for nsis@ietf.org; Thu, 08 Apr 2004 07:33:09 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BBVrV-0003u8-00 for nsis@ietf.org; Thu, 08 Apr 2004 05:30:17 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <2M89N7PC>; Thu, 8 Apr 2004 10:29:47 +0100 Message-ID: From: "Hancock, Robert" To: =?iso-8859-1?Q?=27Attila_B=E1der_=28IJ/ETH=29=27?= , "'Thanh Tra LUU'" Cc: nsis@ietf.org Subject: RE: [NSIS] About GIMPS! Date: Thu, 8 Apr 2004 10:29:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi, I think I understand this but I'll check: An upstream RESPONSE sent via the NTLP will always be sent peer-to-peer using the NTLP per-flow routing state. HOWEVER what can be done in practice is quite flexible. An example (for one scenario): A node wishing to send such a response may be participating in more than one signalling session for a given flow: - a session which visits the domain-internal nodes for a particular administrative domain, which don't store reverse path state, and - a session which only visits domain-edge nodes, possibly for the entire path, and these nodes do store reverse path state (pointing to 'previous edge node') Upstream messages can't in general be sent for the first session. They can be sent for the second, and will use normal NTLP mechanisms to do so. The way the routing state is set up will ensure that the messages skip the interior nodes (and it doesn't require the NSLP to provide e.g. sender addresses explicitly to do so). [Conceptually, the routing state management here is nearly identical to that which was bolted on to RSVP in RFC3175, although obviously a lot of the details are different.] r. > -----Original Message----- > From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] > Sent: Wednesday, April 07, 2004 15:51 > To: 'Thanh Tra LUU' > Cc: nsis@ietf.org > Subject: RE: [NSIS] About GIMPS! >=20 >=20 > Hi Nary Tra, >=20 > I am afraid that using other transport protocol than NTLP=20 > would not be NSIS compliant. Instead NTLP should support this=20 > function, see 5.1.5 of QoS-NSLP draft: >=20 > "The forwarding of the RESPONSE message along the path does not > necessarily imply the existence of NTLP reverse-path state at = every > node. For example, the NTLP may have a mechanism to pass a message > directly from the egress to the ingress of a region of QNEs that = do > not store per-flow reverse-path state." >=20 > Best regards, Attila >=20 >=20 >=20 > > -----Original Message----- > > From: Thanh Tra LUU [mailto:luu@enst.fr] > > Sent: Wednesday, April 07, 2004 4:30 PM > > To: Attila B=E1der (IJ/ETH) > > Cc: nsis@ietf.org > > Subject: Re: [NSIS] About GIMPS! > >=20 > >=20 > > hi Attila, > >=20 > > if i dont miss something, QoS-NSLP can use other protocols=20 > > than NTLP as a > > transport protocol (ex UDP, TCP). in the case you mention,=20 > > NSLP receiver (or > > any signaling entities) can directly send a message to=20 > sender (or any > > signaling entities) using TCP,UDP, SCTP. > >=20 > > Nary Tra, > > ENST, Paris. > >=20 > > ----- Original Message ----- > > From: "Attila B=E1der (IJ/ETH)" > > To: "'Takako Sanda'" ;=20 > > > Sent: Wednesday, April 07, 2004 1:57 PM > > Subject: RE: [NSIS] About GIMPS! > >=20 > >=20 > > > > > > Hi Takako Sanda, > > > > > > Yes, I think you are right, if sender would like to=20 > receive RESPONSE > > transported back by NTLP pear-to-pear, QUERY should contain=20 > > SESSION_ID. But > > RESPONSE can also be sent directly to sender, if sender=20 > > address is known by > > e.g. NSLP layer. > > > > > > Best regards, Attila > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 8 10:37:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22879 for ; Thu, 8 Apr 2004 10:37:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBadx-0004DJ-Px for nsis-archive@odin.ietf.org; Thu, 08 Apr 2004 10:36:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38EabUH016196 for nsis-archive@odin.ietf.org; Thu, 8 Apr 2004 10:36:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBadw-0004BK-8Z; Thu, 08 Apr 2004 10:36:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBad0-0002y9-1h for nsis@optimus.ietf.org; Thu, 08 Apr 2004 10:35:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22625 for ; Thu, 8 Apr 2004 10:35:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBacq-0000uD-00 for nsis@ietf.org; Thu, 08 Apr 2004 10:35:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBYNR-0000Jw-00 for nsis@ietf.org; Thu, 08 Apr 2004 08:11:26 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1BBWI8-0000HI-00 for nsis@ietf.org; Thu, 08 Apr 2004 05:57:48 -0400 Received: by jazz.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id i389vDJS013984 for ; Thu, 8 Apr 2004 18:57:13 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id i389vGo27942 for ; Thu, 8 Apr 2004 18:57:16 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id i389vGQ03233 for ; Thu, 8 Apr 2004 18:57:16 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml25) id i389vFr07144 for nsis@ietf.org; Thu, 8 Apr 2004 18:57:15 +0900 (JST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by soml25.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id i389vEW07138; Thu, 8 Apr 2004 18:57:14 +0900 (JST) Date: Thu, 08 Apr 2004 18:57:15 +0900 From: Takako Sanda To: nsis@ietf.org Subject: Re: [NSIS] GIMPS state management (was: RE: About GIMPS!) > merged Cc: nsis@ietf.org In-Reply-To: References: Message-Id: <20040408181613.39A1.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.02 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, Nary Tra and Attila, Thank you for answering. But I still have some confusion. Please let me confirm. - Does every signaling application message caused by data sending (or depend on some data flows)? I thought that FRI contains, for example, IP address of "data sender". If this understanding is correct, "Hancock, Robert" wrote: > The underlying assumption (in the current version of GIMPS) > is that *every* signalling application message (including a > QoS-NSLP QUERY as an example) will contain both the FRI (which > has the flow-id N-tuple inside it) and the SID. means, every signaling application message have to related to some data flow. Or, is my understanding incorrect? - Is QUERY only sent by data sender or receiver. I thought that QUERY can be sent by any QNE without special request, i.e. any QNE can send QUERY for just checking available resources within certain message scoping. In this case, I thought QUERY doesn't need to carry any flow id or session id (if my first understanding was correct)... Sorry if I am annoying you with stupid questions. --Takako _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 8 11:02:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25513 for ; Thu, 8 Apr 2004 11:02:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBb2g-0003tR-QS for nsis-archive@odin.ietf.org; Thu, 08 Apr 2004 11:02:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38F2A6d014951 for nsis-archive@odin.ietf.org; Thu, 8 Apr 2004 11:02:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBb2Y-0003sd-40; Thu, 08 Apr 2004 11:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBb1Z-0003ft-9J for nsis@optimus.ietf.org; Thu, 08 Apr 2004 11:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25471 for ; Thu, 8 Apr 2004 11:00:57 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBb1W-0003jP-00 for nsis@ietf.org; Thu, 08 Apr 2004 11:00:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBYxa-0003yq-00 for nsis@ietf.org; Thu, 08 Apr 2004 08:48:46 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BBWdk-00042w-00 for nsis@ietf.org; Thu, 08 Apr 2004 06:20:08 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38AK2807033 for ; Thu, 8 Apr 2004 13:20:03 +0300 (EET DST) X-Scanned: Thu, 8 Apr 2004 13:19:45 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i38AJjfM013800 for ; Thu, 8 Apr 2004 13:19:45 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00dK2D1D; Thu, 08 Apr 2004 13:19:42 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38AJgF00384 for ; Thu, 8 Apr 2004 13:19:42 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Apr 2004 13:18:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2004 13:18:19 +0300 Message-ID: Thread-Topic: Interim Meeting Thread-Index: AcQdUtBJdl3LxIBbRuaWtrGGumgH+A== To: X-OriginalArrivalTime: 08 Apr 2004 10:18:19.0416 (UTC) FILETIME=[D0672180:01C41D52] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [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: quoted-printable Hi all, It seems that there is some interest in having an interim meeting. Most = likely, the meeting would be held in the UK possibly on the following dates: 24-28 May=20 or 1-4 June The goal would be to progress the current WG documents. Please let me know if you are interested in attending, and which dates are acceptable. If I get enough responses, then I'll start to schedule the meeting. However, we do need to get commitment from the current draft editors that they can publish draft updates beforehand. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 8 14:19:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08380 for ; Thu, 8 Apr 2004 14:19:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBe7B-00009l-Kc for nsis-archive@odin.ietf.org; Thu, 08 Apr 2004 14:19:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38IJ1ar000601 for nsis-archive@odin.ietf.org; Thu, 8 Apr 2004 14:19:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBe7A-00009a-UQ; Thu, 08 Apr 2004 14:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBe6Y-0008V5-NP for nsis@optimus.ietf.org; Thu, 08 Apr 2004 14:18:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08364 for ; Thu, 8 Apr 2004 14:18:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBe6P-0000b2-00 for nsis@ietf.org; Thu, 08 Apr 2004 14:18:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBbX1-000664-00 for nsis@ietf.org; Thu, 08 Apr 2004 11:33:33 -0400 Received: from mtahqs3.ncr.disa.mil ([164.117.144.157] helo=pfwhqs1.ncr.disa.mil) by ietf-mx with esmtp (Exim 4.12) id 1BBZJ1-0005pb-00 for nsis@ietf.org; Thu, 08 Apr 2004 09:10:55 -0400 Received: from mtahqs3.ncr.disa.mil by pfwhqs1.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 8 Apr 2004 09:15:17 -0400 Received: by mtahqs3.ncr.disa.mil with Internet Mail Service (5.5.2657.72) id <2H4HGD8X>; Thu, 8 Apr 2004 09:10:25 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D0765125E@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: fred@cisco.com Cc: nsis@ietf.org, "'James M. Polk'" , "'Tschofenig Hannes'" Subject: RE: [NSIS] Questions regarding Date: Thu, 8 Apr 2004 09:10:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Fred, I would like to know how SIP P-R and RSVP work together to have priority level and QoS information forwarded across a MLPP network domain. Thanks, An -----Original Message----- From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] Sent: Wednesday, April 07, 2004 10:16 AM To: fred@cisco.com; 'James M. Polk' Cc: nsis@ietf.org Subject: RE: [NSIS] Questions regarding hi all, i would like to add something to my question with regard to the difference between the sip based preemption approach (draft-ietf-sip-resource-priority-03.txt) and the rsvp preemption approach (rfc2751): draft-ietf-sip-resource-priority-03.txt defines a scheme based on : - enumerations of <'namespace' '.' 'priority value'> pairs. rfc2751 defines a scheme based on: - a preemption priority - a defending priority - and a merging strategy how do they match to each other? which approach would you suggest for the qos nlsp (or for nsis in general)? ciao hannes > -----Original Message----- > From: Tschofenig Hannes > Sent: Saturday, April 03, 2004 8:14 PM > To: fred@cisco.com; 'James M. Polk' > Cc: nsis@ietf.org > Subject: [NSIS] Questions regarding > > > > hi fred, hi james, > > your draft has recently been mentioned in the nsis wg. i have > read the draft > and came across a few issues: > > - the details between the preemption defined in > and seem > to be a bit ... > > > regarding section 2.3.5.2 i suspect that the typical procedure is as > follows: > > a user adds a priority level in his qos request. the > authenticated request > is processed at the first router and forwarded to the "policy decision > point" together with the qos parameters and the indicated > priority level. as > part of the authorization procedure the request is granted or > rejected. if > it is granted then the request (including the priority level) > is forwarded > along the path. is this right? > ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 8 16:43:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21469 for ; Thu, 8 Apr 2004 16:43:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgMa-00029c-Pw for nsis-archive@odin.ietf.org; Thu, 08 Apr 2004 16:43:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38Kh4sl008272 for nsis-archive@odin.ietf.org; Thu, 8 Apr 2004 16:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgMZ-00028m-LR; Thu, 08 Apr 2004 16:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgMB-0001ZF-NB for nsis@optimus.ietf.org; Thu, 08 Apr 2004 16:42:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21257 for ; Thu, 8 Apr 2004 16:42:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBgM6-00014Y-00 for nsis@ietf.org; Thu, 08 Apr 2004 16:42:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBdZg-0005IA-00 for nsis@ietf.org; Thu, 08 Apr 2004 13:44:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBbVJ-0005hW-00 for nsis@ietf.org; Thu, 08 Apr 2004 11:31:45 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBaz1-0003yq-KO; Thu, 08 Apr 2004 10:58:23 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <2M80KTHT>; Thu, 8 Apr 2004 15:57:39 +0100 Message-ID: From: "Hancock, Robert" To: "'Takako Sanda'" , nsis@ietf.org Cc: nsis@ietf.org Subject: RE: [NSIS] GIMPS state management (was: RE: About GIMPS!) > merge d Date: Thu, 8 Apr 2004 15:57:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 Takako, as Hannes says, there are no stupid questions. please see below. > -----Original Message----- > From: Takako Sanda [mailto:sanda.takako@jp.panasonic.com] > Sent: Thursday, April 08, 2004 10:57 > To: nsis@ietf.org > Cc: nsis@ietf.org > Subject: Re: [NSIS] GIMPS state management (was: RE: About GIMPS!) > > merged > > > Hi Robert, Nary Tra and Attila, > > > Thank you for answering. > > But I still have some confusion. Please let me confirm. > > - Does every signaling application message caused by data sending (or > depend on some data flows)? Basically yes: there are classes of signalling message which are not about specific data flows (you could regard network management or routing protocol messages as being in this class, for example). Such messages are *not* in the scope of NSIS. > I thought that FRI contains, for example, IP address of "data sender". > If this understanding is correct, > > "Hancock, Robert" wrote: > > The underlying assumption (in the current version of GIMPS) > > is that *every* signalling application message (including a > > QoS-NSLP QUERY as an example) will contain both the FRI (which > > has the flow-id N-tuple inside it) and the SID. > > means, every signaling application message have to related to > some data > flow. > Or, is my understanding incorrect? No, you are quite right. [Actually, to confuse matters a bit, we have identified one message in the NATFW NSLP which is not really about a data flow but which is about finding an address to use for a data flow. If - as seems quite possible - this message turns out to need routing in a different way, GIMPS will have to be tweaked to handle it. But that isn't in the current drafts.] > > - Is QUERY only sent by data sender or receiver. > I thought that QUERY can be sent by any QNE without special > request, i.e. > any QNE can send QUERY for just checking available resources within > certain message scoping. In this case, I thought QUERY doesn't need to > carry any flow id or session id (if my first understanding > was correct)... In one sense, you are right. In another sense, you are not. If you send a QUERY message with *no* FRI at all, how is any device to know what resources you are actually interested in? For example, if it was sent with unspecified destination address, you would basically be asking "what resources are available in the Internet?" The FRI needs to have at least enough information in it to define the topological path in the network you are asking about. (It could be made more specific later, e.g. leaving out higher layer information at first - provided you are sure that this higher layer information will not affect the routing. But the FRI can be changed during a session anyway. This also got raised on the Reserve/Commit thread recently.) > > > Sorry if I am annoying you with stupid questions. > > --Takako > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 9 00:20:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26438 for ; Fri, 9 Apr 2004 00:20:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBnUq-0003DJ-Ap for nsis-archive@odin.ietf.org; Fri, 09 Apr 2004 00:20:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i394K4aM012348 for nsis-archive@odin.ietf.org; Fri, 9 Apr 2004 00:20:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBnUp-0003Cj-1V; Fri, 09 Apr 2004 00:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBj7k-0007AV-9d for nsis@optimus.ietf.org; Thu, 08 Apr 2004 19:39:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09876 for ; Thu, 8 Apr 2004 19:39:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBj7h-0005jm-00 for nsis@ietf.org; Thu, 08 Apr 2004 19:39:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBi0R-0005o5-00 for nsis@ietf.org; Thu, 08 Apr 2004 18:28:22 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfzP-0004uf-00 for nsis@ietf.org; Thu, 08 Apr 2004 16:19:07 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2004 12:27:48 +0000 Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id i38KIXn3005082; Thu, 8 Apr 2004 13:18:33 -0700 (PDT) Message-Id: <6.0.3.0.2.20040408121452.050a3660@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 08 Apr 2004 12:57:23 -0700 To: "Nguyen, An" From: Fred Baker Subject: RE: [NSIS] Questions regarding Cc: nsis@ietf.org, "'James M. Polk'" , "'Tschofenig Hannes'" In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D0765125E@emshqs1.ncr.disa. mil> References: <7F18415E4D63CB45BB9B3A591F68D12D0765125E@emshqs1.ncr.disa.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 09:10 AM 04/08/04 -0400, Nguyen, An wrote: >I would like to know how SIP P-R and RSVP work together to have priority >level and QoS information forwarded across a MLPP network domain. I think that's discussed in the document you refer to on the subject line... I'm going to go over material here that was discussed on 24 March and 2 April with Peter Fonash and others of your organization. IIRC correctly, you were there on 24 March too, but we didn't get to talk directly. In most real-time applications, and specifically in voice and video, the application-application discussion includes both session layer control transactions and data plane information exchange. In the session layer, one opens and closes sessions, finds peers to have sessions with, and so on. In the PSTN, this is the province of SS7, H.320/H.242/etc, and so on. The data plane in the PSTN is the circuit that carries voice-or-whatever. In the PSTN, once one gets a circuit to put one's voice-or-whatever on, a circuit is a circuit is a circuit. In the IP context, the control plane is SIP/SDR, and the data plane is RTP. Both ride on IP. SIP and SS7 have serious differences that I don't want to gloss over (you will recall me discussing very carefully the difference between a PSTN switch, which controls capacity and routing, and a SIP proxy, which is ignorant of routing and capacity), but in this context can be compared pretty easily. The question before the house in SS7 is "who gets a circuit", and the SS7 exchange carries policy tidbits that assert "if there is an issue, I'm special, prefer me". The result of the SS7 exchange is one of two things: if there is capacity (a circuit) available in the network and if the called handset is not in use, or (military MLPP case and one could imagine the case on telephones that have a call-waiting feature with appropriate signals available to the user) if the called terminal can be convinced to make itself available, a circuit is assigned and the call goes through. Otherwise, it doesn't. The question before the house in SIP is "who gets to have a chat with the remote terminal". Note that this is a policy question, and doesn't automatically have any knowledge of network loading or routing; hence, the addition of RFC 3312, which provides a way to go to a separate signaling protocol (RSVP) that is able to trace network routing and determine whether capacity exists to support the policy. The SIP Resource Priority Header contains information that allows someone to say "if there is an issue, I'm special, prefer me". There is also a capability in the RSVP policy blob to assert a verifiable identity, concerning which the network may conclude the same regarding capacity decisions. The combination of the two protocols implements something analogous to what SS7 does in the PSTN. In the PSTN, IF there is capacity AND the remote handset can be made available THEN the call is placed; OTHERWISE it is refused. In SIP, IF the remote handset can be made available THEN the call is placed, but it may not have sufficient capacity on some trunk in the network to provide adequate call quality. In SIP+RSVP as described in RFC 3312, IF there is capacity AND the remote handset can be made available THEN the call is placed; OTHERWISE it is refused, either by SIP refusing the call or by RSVP rejecting the capacity admission. There remains a difference; in the PSTN, once a circuit is routed, it is in place and capacity is assured until SS7 makes it go away. In the IP world, routing is completely separate from application behavior, and can change without the end system knowing that happened. Therefore, when routing changes, capacity calculations can change. In such a case, RSVP follows the routing, and can result in the call's status changing (in an MLPP world, in it being preempted) in mid-flight. The data plane in the IP network is very different from anything in the world of circuits, however, in that packets compete statistically for capacity and biasing that in favor of one class of traffic over another requires marking them in some way and the network doing something specific to implement that behavior. DISA (Mike Pierce) and NCS (Janet Gunn) are arguing fairly strongly that it is insufficient to use the EF PHB and actually say "capacity is capacity is capacity" as is done in the circuit world. Rather, they would like to have varied DSCP values. I think I understand the reasons they are asking for this; I also think the case has not been proven. In the presence of capacity-aware CAC, as Mike's latest Assured Service Requirements draft calls for and as I have asserted is necessary, the varied DSCP values don't hurt, but I don't see how they really help. BUT: if we do have multiple DSCP values, when Alice calls Bob with a certain resource priority, Alice plans to send her packets to Bob using the elevated DSCP value in the data plane, and Bob would be well advised to do the same. The Resource Priority blob in the SIP message communicates to Bob that he should do so and guides him as to which value to select. The discussion in NSIS wants to replace RSVP in all of the above with NSIS, which I'm all for some day when NSIS decides to produce a deployable result. That result has to meet the requirements of the system being discussed: the ability to aggregate calls, manage policy, and so on and so forth. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 9 01:35:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28804 for ; Fri, 9 Apr 2004 01:35:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBofQ-0001Ky-R0 for nsis-archive@odin.ietf.org; Fri, 09 Apr 2004 01:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i395Z44V005135 for nsis-archive@odin.ietf.org; Fri, 9 Apr 2004 01:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBofN-0001KG-HR; Fri, 09 Apr 2004 01:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBof7-0001Je-Hn for nsis@optimus.ietf.org; Fri, 09 Apr 2004 01:34:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28760 for ; Fri, 9 Apr 2004 01:34:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBof0-0001m9-00 for nsis@ietf.org; Fri, 09 Apr 2004 01:34:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBoaU-0001WG-00 for nsis@ietf.org; Fri, 09 Apr 2004 01:29:59 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 1BBoXV-0001FC-00 for nsis@ietf.org; Fri, 09 Apr 2004 01:26:53 -0400 Received: from ns.sait.samsung.co.kr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 75D6A1F50C; Fri, 9 Apr 2004 14:26:10 +0900 (KST) Received: from 127.0.0.1 by 127.0.0.1(smtpfilter) with ESMTP; Fri, 09 Apr 2004 14:26:09 +0900 (KST) Received: from LocalHost (unknown [75.2.47.28]) by ns.sait.samsung.co.kr (Postfix) with SMTP id:241781F3C4; Fri, 9 Apr 2004 14:26:09 +0900 (KST) From: "Sung Hyuck Lee" To: , Subject: RE: [NSIS] Interim Meeting Date: Fri, 9 Apr 2004 14:26:08 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KSSdkIGxpa2UgdG8gYXR0ZW5kIE5TSVMgaW50ZXJpbSBtZWV0aW5nIGluIHRo ZSBVSywgYW5kIGl0IA0Kd291bGQgYmUgZ3JlYXQgaWYgdGhlIGludGVyaW0gbWVldGluZyB3aWxs IGJlIGhlbGQgb24gDQpKdW5lIDF0aCAtIDR0aC4NCg0KUmVnYXJkcywNCihLYW0tc2EtaGFwLW5p LWRhKQ0KDQpTdW5nLUh5dWNrIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IG5zaXMtYWRtaW5AaWV0Zi5vcmcgW21haWx0bzpuc2lzLWFkbWluQGlldGYub3JnXU9uIEJl aGFsZiANCj4gT2Ygam9obi5sb3VnaG5leUBub2tpYS5jb20NCj4gU2VudDogVGh1cnNkYXksIEFw cmlsIDA4LCAyMDA0IDc6MTggUE0NCj4gVG86IG5zaXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW05T SVNdIEludGVyaW0gTWVldGluZw0KPiANCj4gDQo+IEhpIGFsbCwNCj4gDQo+IEl0IHNlZW1zIHRo YXQgdGhlcmUgaXMgc29tZSBpbnRlcmVzdCBpbiBoYXZpbmcgYW4gaW50ZXJpbSANCj4gbWVldGlu Zy4gTW9zdCBsaWtlbHksIHRoZSBtZWV0aW5nDQo+IHdvdWxkIGJlIGhlbGQgaW4gdGhlIFVLIHBv c3NpYmx5IG9uIHRoZSBmb2xsb3dpbmcgZGF0ZXM6DQo+IA0KPiAyNC0yOCBNYXkgDQo+IG9yDQo+ IDEtNCBKdW5lDQo+IA0KPiBUaGUgZ29hbCB3b3VsZCBiZSB0byBwcm9ncmVzcyB0aGUgY3VycmVu dCBXRyBkb2N1bWVudHMuDQo+IA0KPiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGFyZSBpbnRl cmVzdGVkIGluIGF0dGVuZGluZywgYW5kIHdoaWNoDQo+IGRhdGVzIGFyZSBhY2NlcHRhYmxlLiAg SWYgSSBnZXQgZW5vdWdoIHJlc3BvbnNlcywgdGhlbiBJJ2xsIHN0YXJ0DQo+IHRvIHNjaGVkdWxl IHRoZSBtZWV0aW5nLg0KPiANCj4gSG93ZXZlciwgd2UgZG8gbmVlZCB0byBnZXQgY29tbWl0bWVu dCBmcm9tIHRoZSBjdXJyZW50IGRyYWZ0IGVkaXRvcnMNCj4gdGhhdCB0aGV5IGNhbiBwdWJsaXNo IGRyYWZ0IHVwZGF0ZXMgYmVmb3JlaGFuZC4NCj4gDQo+IHRoYW5rcywNCj4gSm9obg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbnNpcyBt YWlsaW5nIGxpc3QNCj4gbnNpc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uc2lzDQo+IA0KPiA= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 9 07:24:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23045 for ; Fri, 9 Apr 2004 07:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBu77-0002O8-Ux for nsis-archive@odin.ietf.org; Fri, 09 Apr 2004 07:24:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39BO1Wl009166 for nsis-archive@odin.ietf.org; Fri, 9 Apr 2004 07:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBu76-0002NY-UT; Fri, 09 Apr 2004 07:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBu6T-0002M0-Hl for nsis@optimus.ietf.org; Fri, 09 Apr 2004 07:23:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22987 for ; Fri, 9 Apr 2004 07:23:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBu6S-0001Ig-00 for nsis@ietf.org; Fri, 09 Apr 2004 07:23:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBu5e-00019Z-00 for nsis@ietf.org; Fri, 09 Apr 2004 07:22:31 -0400 Received: from [203.169.90.42] (helo=127.0.0.1) by ietf-mx with smtp (Exim 4.12) id 1BBu3V-0000rt-00 for nsis@ietf.org; Fri, 09 Apr 2004 07:20:18 -0400 From: "Cheng Hong" To: , Subject: RE: [NSIS] Interim Meeting Date: Fri, 9 Apr 2004 19:19:21 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <007e01c41e24$84a9c130$2a5aa9cb@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal X-GCMulti: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi John, I am also quite intersted in this Intrim meeting. But 1-4 of June would = not be possible for me since there is another conference I need to attend = during that week. Is there any other candidate dates for the meeting? Generally May would = be a busy month with IEEE802 and 3GPP meetings, and June would be better. best regards Cheng Hong > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On=20 > Behalf Of john.loughney@nokia.com > Sent: Thursday, April 08, 2004 6:18 PM > To: nsis@ietf.org > Subject: [NSIS] Interim Meeting >=20 >=20 > Hi all, >=20 > It seems that there is some interest in having an interim=20 > meeting. Most likely, the meeting would be held in the UK=20 > possibly on the following dates: >=20 > 24-28 May=20 > or > 1-4 June >=20 > The goal would be to progress the current WG documents. >=20 > Please let me know if you are interested in attending, and=20 > which dates are acceptable. If I get enough responses, then=20 > I'll start to schedule the meeting. >=20 > However, we do need to get commitment from the current draft=20 > editors that they can publish draft updates beforehand. >=20 > thanks, > John >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 9 13:31:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09139 for ; Fri, 9 Apr 2004 13:31:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzqK-0006IU-L2 for nsis-archive@odin.ietf.org; Fri, 09 Apr 2004 13:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39HV43P024201 for nsis-archive@odin.ietf.org; Fri, 9 Apr 2004 13:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzqG-0006Hq-WA; Fri, 09 Apr 2004 13:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzpO-0006Gu-6E for nsis@optimus.ietf.org; Fri, 09 Apr 2004 13:30:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09115 for ; Fri, 9 Apr 2004 13:30:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBzpJ-0004Yu-00 for nsis@ietf.org; Fri, 09 Apr 2004 13:30:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBzoG-0004SR-00 for nsis@ietf.org; Fri, 09 Apr 2004 13:28:58 -0400 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BBzmT-0004Ft-00 for nsis@ietf.org; Fri, 09 Apr 2004 13:27:05 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i39HQC1Y015447 for ; Fri, 9 Apr 2004 13:26:27 -0400 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 40703259000F8BCB; Fri, 9 Apr 2004 13:22:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Questions regarding Date: Fri, 9 Apr 2004 13:26:12 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A06BD77FF@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [NSIS] Questions regarding Thread-Index: AcQd6f6cNbkmX/eKSK2hsEy/mUwAFAAa3AkQ From: "Roy, Radhika R, ALABS" To: "Fred Baker" , "Nguyen, An" , "Tschofenig Hannes" , "James M. Polk" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, all: Some quick clarifications ... I wonder whether we also consider the following in terms of SIP: 1. SIP signaling messages may indicate priorities how calls need to be handled. However, SDP may contain multiple media: Audio, Video, and/or Data. Again, each media may need to be dealt with different priorities (e.g., audio - highest, data - second highest, vide - least priority). The media level differentiation in priority in SIP, I guess, is yet to be standardized. 2. If the SDP contains only one media (e.g., audio) and the call level priority can also be mapped directly to media. So, RSVP can also take care of reservation of audio media in terms of priority. 3. If SDP contains multiple media, how does RSVP will take of media level differentiation in priority in reservation of resources, if something else does not help in differentiating priority of each media? Of course, media policies can be used to define this, however, it would be better if there is a standard to define so. 4. If all media of SDP get the same priority, however, there may not be any problems (may not always be realistic if high-bandwidth video is there). Best regards, Radhika R. Roy -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Fred Baker Sent: Thursday, April 08, 2004 3:57 PM To: Nguyen, An Cc: nsis@ietf.org; 'James M. Polk'; 'Tschofenig Hannes' Subject: RE: [NSIS] Questions regarding At 09:10 AM 04/08/04 -0400, Nguyen, An wrote: >I would like to know how SIP P-R and RSVP work together to have priority=20 >level and QoS information forwarded across a MLPP network domain. I think that's discussed in the document you refer to on the subject=20 line... I'm going to go over material here that was discussed on 24 March=20 and 2 April with Peter Fonash and others of your organization. IIRC=20 correctly, you were there on 24 March too, but we didn't get to talk directly. In most real-time applications, and specifically in voice and video, the application-application discussion includes both session layer control=20 transactions and data plane information exchange. In the session layer, one=20 opens and closes sessions, finds peers to have sessions with, and so on. In=20 the PSTN, this is the province of SS7, H.320/H.242/etc, and so on. The data=20 plane in the PSTN is the circuit that carries voice-or-whatever. In the=20 PSTN, once one gets a circuit to put one's voice-or-whatever on, a circuit=20 is a circuit is a circuit. In the IP context, the control plane is SIP/SDR, and the data plane is RTP.=20 Both ride on IP. SIP and SS7 have serious differences that I don't want to=20 gloss over (you will recall me discussing very carefully the difference=20 between a PSTN switch, which controls capacity and routing, and a SIP=20 proxy, which is ignorant of routing and capacity), but in this context can=20 be compared pretty easily. The question before the house in SS7 is "who gets a circuit", and the SS7=20 exchange carries policy tidbits that assert "if there is an issue, I'm=20 special, prefer me". The result of the SS7 exchange is one of two things:=20 if there is capacity (a circuit) available in the network and if the called=20 handset is not in use, or (military MLPP case and one could imagine the=20 case on telephones that have a call-waiting feature with appropriate=20 signals available to the user) if the called terminal can be convinced to=20 make itself available, a circuit is assigned and the call goes through.=20 Otherwise, it doesn't. The question before the house in SIP is "who gets to have a chat with the=20 remote terminal". Note that this is a policy question, and doesn't=20 automatically have any knowledge of network loading or routing; hence, the=20 addition of RFC 3312, which provides a way to go to a separate signaling protocol (RSVP) that is able to trace network routing and determine whether=20 capacity exists to support the policy. The SIP Resource Priority Header=20 contains information that allows someone to say "if there is an issue, I'm=20 special, prefer me". There is also a capability in the RSVP policy blob to=20 assert a verifiable identity, concerning which the network may conclude the=20 same regarding capacity decisions. The combination of the two protocols implements something analogous to what=20 SS7 does in the PSTN. In the PSTN, IF there is capacity AND the remote=20 handset can be made available THEN the call is placed; OTHERWISE it is=20 refused. In SIP, IF the remote handset can be made available THEN the call=20 is placed, but it may not have sufficient capacity on some trunk in the=20 network to provide adequate call quality. In SIP+RSVP as described in RFC=20 3312, IF there is capacity AND the remote handset can be made available=20 THEN the call is placed; OTHERWISE it is refused, either by SIP refusing the call or by RSVP rejecting the capacity admission. There remains a=20 difference; in the PSTN, once a circuit is routed, it is in place and=20 capacity is assured until SS7 makes it go away. In the IP world, routing is=20 completely separate from application behavior, and can change without the=20 end system knowing that happened. Therefore, when routing changes, capacity=20 calculations can change. In such a case, RSVP follows the routing, and can=20 result in the call's status changing (in an MLPP world, in it being=20 preempted) in mid-flight. The data plane in the IP network is very different from anything in the=20 world of circuits, however, in that packets compete statistically for=20 capacity and biasing that in favor of one class of traffic over another=20 requires marking them in some way and the network doing something specific=20 to implement that behavior. DISA (Mike Pierce) and NCS (Janet Gunn) are=20 arguing fairly strongly that it is insufficient to use the EF PHB and=20 actually say "capacity is capacity is capacity" as is done in the circuit=20 world. Rather, they would like to have varied DSCP values. I think I=20 understand the reasons they are asking for this; I also think the case has=20 not been proven. In the presence of capacity-aware CAC, as Mike's latest Assured Service Requirements draft calls for and as I have asserted is=20 necessary, the varied DSCP values don't hurt, but I don't see how they=20 really help. BUT: if we do have multiple DSCP values, when Alice calls Bob with a=20 certain resource priority, Alice plans to send her packets to Bob using the=20 elevated DSCP value in the data plane, and Bob would be well advised to do=20 the same. The Resource Priority blob in the SIP message communicates to Bob=20 that he should do so and guides him as to which value to select. The discussion in NSIS wants to replace RSVP in all of the above with NSIS,=20 which I'm all for some day when NSIS decides to produce a deployable=20 result. That result has to meet the requirements of the system being=20 discussed: the ability to aggregate calls, manage policy, and so on and so=20 forth.=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 9 14:07:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10508 for ; Fri, 9 Apr 2004 14:07:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0P8-0000vA-Bt for nsis-archive@odin.ietf.org; Fri, 09 Apr 2004 14:07:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39I726e003526 for nsis-archive@odin.ietf.org; Fri, 9 Apr 2004 14:07:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0P7-0000tr-Ao; Fri, 09 Apr 2004 14:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0O9-0000su-Ug for nsis@optimus.ietf.org; Fri, 09 Apr 2004 14:06:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10321 for ; Fri, 9 Apr 2004 14:05:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC0O6-0000OS-00 for nsis@ietf.org; Fri, 09 Apr 2004 14:05:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC0Mk-0000HH-00 for nsis@ietf.org; Fri, 09 Apr 2004 14:04:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BC0La-00003D-00 for nsis@ietf.org; Fri, 09 Apr 2004 14:03:22 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Apr 2004 11:03:59 -0700 Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id i39I2iBC020749; Fri, 9 Apr 2004 11:02:45 -0700 (PDT) Message-Id: <6.0.3.0.2.20040409105457.0585b0b0@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 09 Apr 2004 11:02:16 -0700 To: "Roy, Radhika R, ALABS" From: Fred Baker Subject: RE: [NSIS] Questions regarding Cc: "Nguyen, An" , "Tschofenig Hannes" , "James M. Polk" , In-Reply-To: <34DA635B184A644DA4588E260EC0A25A06BD77FF@ACCLUST02EVS1.ugd .att.com> References: <34DA635B184A644DA4588E260EC0A25A06BD77FF@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 01:26 PM 04/09/04 -0400, Roy, Radhika R, ALABS wrote: >3. If SDP contains multiple media, how does RSVP will take of media level >differentiation in priority in reservation of resources, if something else >does not help in differentiating priority of each media? I'm not the list moderator, but I'll say something that I'll bet the list moderator is thinking: If this is an NSIS requirement, the point on *this* list should be to ensure that NSIS (GIMP/NSLP) meets the requirement. I understand the working group to not so much be thinking about RSVP as a protocol to replace it, hopefully in a manner that is interoperable at some level. I'd suggest that discussion of the NCS/MLPP near-term operational requirements, which have wandered from SIP to SIPPING to IEPREP to TSVWG, not be particularly brought here except to ensure that those needs will be met by NSIS when NSIS is done. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 9 15:33:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15200 for ; Fri, 9 Apr 2004 15:33:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1kR-00045W-ET for nsis-archive@odin.ietf.org; Fri, 09 Apr 2004 15:33:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39JX7qY015710 for nsis-archive@odin.ietf.org; Fri, 9 Apr 2004 15:33:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1kL-00045G-92; Fri, 09 Apr 2004 15:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1jp-0003xn-J3 for nsis@optimus.ietf.org; Fri, 09 Apr 2004 15:32:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15119 for ; Fri, 9 Apr 2004 15:32:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC1jl-0001Cx-00 for nsis@ietf.org; Fri, 09 Apr 2004 15:32:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC1fN-0000gl-00 for nsis@ietf.org; Fri, 09 Apr 2004 15:27:53 -0400 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BC1YF-00004v-00 for nsis@ietf.org; Fri, 09 Apr 2004 15:20:31 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i39JJZVc031541 for ; Fri, 9 Apr 2004 14:19:52 -0500 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 40703259000FD182; Fri, 9 Apr 2004 15:15:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Questions regarding Date: Fri, 9 Apr 2004 15:19:52 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A06BFC361@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [NSIS] Questions regarding Thread-Index: AcQeXOEC0HqbMjDUSBekym/ayb7qZAACToHg From: "Roy, Radhika R, ALABS" To: "Fred Baker" Cc: "Nguyen, An" , "Tschofenig Hannes" , "James M. Polk" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Fred: We are in agreement. The main points are as follows: 1. Applications level signaling schemes (e.g., NSIS protocols) need to understand the implications between the call level priority (e.g., SIP) vs. media (e.g., SDP) level priority. 2. The complexities for comparisons of different priority levels between the circuit-switched PSTN network vs. Packet-switched IP network along with the application level call signaling protocols (e.g., ISUP, SIP) that are used. In this way, we would help us to rationalize how we should address different aspects of NSIS protocols. br, Radhika -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Friday, April 09, 2004 2:02 PM To: Roy, Radhika R, ALABS Cc: Nguyen, An; Tschofenig Hannes; James M. Polk; nsis@ietf.org Subject: RE: [NSIS] Questions regarding At 01:26 PM 04/09/04 -0400, Roy, Radhika R, ALABS wrote: >3. If SDP contains multiple media, how does RSVP will take of media level=20 >differentiation in priority in reservation of resources, if something else=20 >does not help in differentiating priority of each media? I'm not the list moderator, but I'll say something that I'll bet the list=20 moderator is thinking: If this is an NSIS requirement, the point on *this*=20 list should be to ensure that NSIS (GIMP/NSLP) meets the requirement. I=20 understand the working group to not so much be thinking about RSVP as a=20 protocol to replace it, hopefully in a manner that is interoperable at some=20 level. I'd suggest that discussion of the NCS/MLPP near-term operational=20 requirements, which have wandered from SIP to SIPPING to IEPREP to TSVWG,=20 not be particularly brought here except to ensure that those needs will be=20 met by NSIS when NSIS is done.=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 12 19:04:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23803 for ; Mon, 12 Apr 2004 19:04:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDATf-0004Uq-Dw for nsis-archive@odin.ietf.org; Mon, 12 Apr 2004 19:04:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CN4VYQ017284 for nsis-archive@odin.ietf.org; Mon, 12 Apr 2004 19:04:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDATA-0004RR-BP; Mon, 12 Apr 2004 19:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDASW-0004Pu-5d for nsis@optimus.ietf.org; Mon, 12 Apr 2004 19:03:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23741 for ; Mon, 12 Apr 2004 19:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDASR-0002Qw-00 for nsis@ietf.org; Mon, 12 Apr 2004 19:03:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDA51-0000Wx-00 for nsis@ietf.org; Mon, 12 Apr 2004 18:39:04 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BD9Xu-0006F7-00 for nsis@ietf.org; Mon, 12 Apr 2004 18:04:50 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <2M80L8DJ>; Mon, 12 Apr 2004 23:03:50 +0100 Message-ID: From: "Hancock, Robert" To: "Roy, Radhika R, ALABS" , Fred Baker Cc: "Nguyen, An" , nsis@ietf.org Subject: RE: [NSIS] Questions regarding Date: Mon, 12 Apr 2004 23:03:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , A very brief comment on the RSVP/NSIS relationship/interchangeability: So far as I can tell, everything we have done so far in NSIS is compatible with the concept of using it as a side-by-side alternative to RSVP, at least so far as relationship with other higher-layer protocols (like SIP) is concerned. The differences from RSVP are to do with wanting different performance/complexity tradeoffs and different types of flexibility within the protocol. In particular, I've read mlpp-that-works and believe that we could do "s/RSVP/NSIS", except that we don't have all the RFC numbers yet ;-). The main point is that NSIS signalling is tied to the data plane in exactly the same way as RSVP (which also makes interoperability easy to consider, except when route changes start moving the interoperation point around ...) However, while I've tried to understand whether the MLPP discussions help us to work out where within the NSIS protocol suite to put priority and pre-emption (which is where this conversation started), so far I've failed to find any guidance on that subject. (One interesting question would be "Is there any experience about whether the priority/pre-emption model of RFC3181 is a good match for operational requirements or not?") robert h. > -----Original Message----- > From: Roy, Radhika R, ALABS [mailto:rrroy@att.com] > Sent: Friday, April 09, 2004 20:20 > To: Fred Baker > Cc: Nguyen, An; Tschofenig Hannes; James M. Polk; nsis@ietf.org > Subject: RE: [NSIS] Questions regarding > > > > Hi, Fred: > > We are in agreement. > > The main points are as follows: > > 1. Applications level signaling schemes (e.g., NSIS protocols) need to > understand the implications between the call level priority > (e.g., SIP) > vs. media (e.g., SDP) level priority. > > 2. The complexities for comparisons of different priority > levels between > the circuit-switched PSTN network vs. Packet-switched IP network along > with the application level call signaling protocols (e.g., ISUP, SIP) > that are used. > > In this way, we would help us to rationalize how we should address > different aspects of NSIS protocols. > > br, > Radhika > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, April 09, 2004 2:02 PM > To: Roy, Radhika R, ALABS > Cc: Nguyen, An; Tschofenig Hannes; James M. Polk; nsis@ietf.org > Subject: RE: [NSIS] Questions regarding > > > > At 01:26 PM 04/09/04 -0400, Roy, Radhika R, ALABS wrote: > >3. If SDP contains multiple media, how does RSVP will take of media > level > >differentiation in priority in reservation of resources, if something > else > >does not help in differentiating priority of each media? > > I'm not the list moderator, but I'll say something that I'll bet the > list > moderator is thinking: If this is an NSIS requirement, the point on > *this* > list should be to ensure that NSIS (GIMP/NSLP) meets the > requirement. I > understand the working group to not so much be thinking about > RSVP as a > protocol to replace it, hopefully in a manner that is interoperable at > some > level. > > I'd suggest that discussion of the NCS/MLPP near-term operational > requirements, which have wandered from SIP to SIPPING to IEPREP to > TSVWG, > not be particularly brought here except to ensure that those > needs will > be > met by NSIS when NSIS is done. > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 13 02:31:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22088 for ; Tue, 13 Apr 2004 02:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDHRo-0008OJ-B5 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 02:31:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D6V4qc032256 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 02:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDHRm-0008NL-4j; Tue, 13 Apr 2004 02:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDHRN-0008GU-G5 for nsis@optimus.ietf.org; Tue, 13 Apr 2004 02:30:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22017 for ; Tue, 13 Apr 2004 02:30:34 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDHRJ-00063e-00 for nsis@ietf.org; Tue, 13 Apr 2004 02:30:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDHOq-0005p1-00 for nsis@ietf.org; Tue, 13 Apr 2004 02:28:01 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BDHNb-0005lC-00 for nsis@ietf.org; Tue, 13 Apr 2004 02:26:44 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D6QEO04977; Tue, 13 Apr 2004 09:26:14 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 09:26:05 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3D6Q5j6030582; Tue, 13 Apr 2004 09:26:05 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00o7KrgJ; Tue, 13 Apr 2004 09:26:03 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D6Pps14454; Tue, 13 Apr 2004 09:25:51 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 09:25:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Questions regarding Date: Tue, 13 Apr 2004 09:25:49 +0300 Message-ID: Thread-Topic: [NSIS] Questions regarding Thread-Index: AcQeXf7C1DKJjWIhSSGWOSH6Z0KCvACwfDUQ To: , Cc: , , , X-OriginalArrivalTime: 13 Apr 2004 06:25:50.0588 (UTC) FILETIME=[2A51A3C0:01C42120] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Fred & Roy, Catching up after a long weekend: > At 01:26 PM 04/09/04 -0400, Roy, Radhika R, ALABS wrote: > >3. If SDP contains multiple media, how does RSVP will take of media = level=20 > >differentiation in priority in reservation of resources, if something = else=20 > >does not help in differentiating priority of each media? >=20 > I'm not the list moderator, but I'll say something that I'll bet the = list=20 > moderator is thinking: If this is an NSIS requirement, the point on = *this*=20 > list should be to ensure that NSIS (GIMP/NSLP) meets the requirement. = I=20 > understand the working group to not so much be thinking about RSVP as = a=20 > protocol to replace it, hopefully in a manner that is interoperable at = some=20 > level. Agreed - MLPP should be discussed on TSVWG, generally - the point of = discussing it on NSIS is to see what, if anything, needs to be done with NSIS = protocols =20 > I'd suggest that discussion of the NCS/MLPP near-term operational=20 > requirements, which have wandered from SIP to SIPPING to IEPREP to = TSVWG,=20 > not be particularly brought here except to ensure that those needs = will be=20 > met by NSIS when NSIS is done.=20 Agreed. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 13 06:05:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01972 for ; Tue, 13 Apr 2004 06:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDKmt-00021c-Eb for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 06:05:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DA53X1007770 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 06:05:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDKmr-00020t-Qv; Tue, 13 Apr 2004 06:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDKmn-00020F-UH for nsis@optimus.ietf.org; Tue, 13 Apr 2004 06:04:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01937 for ; Tue, 13 Apr 2004 06:04:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDKmi-0002l5-00 for nsis@ietf.org; Tue, 13 Apr 2004 06:04:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDKl9-0002au-00 for nsis@ietf.org; Tue, 13 Apr 2004 06:03:15 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BDKiS-0002O8-00 for nsis@ietf.org; Tue, 13 Apr 2004 06:00:29 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3DA0IAh003103 for ; Tue, 13 Apr 2004 12:00:19 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Apr 2004 12:00:18 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <25RJMGTC>; Tue, 13 Apr 2004 12:00:19 +0200 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Interim Meeting Date: Tue, 13 Apr 2004 12:04:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Apr 2004 10:00:18.0628 (UTC) FILETIME=[2044B840:01C4213E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 am also interested in the interim meeting and it seems that both period is OK for me, best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Thursday, April 08, 2004 12:18 PM > To: nsis@ietf.org > Subject: [NSIS] Interim Meeting > > > Hi all, > > It seems that there is some interest in having an interim > meeting. Most likely, the meeting > would be held in the UK possibly on the following dates: > > 24-28 May > or > 1-4 June > > The goal would be to progress the current WG documents. > > Please let me know if you are interested in attending, and which > dates are acceptable. If I get enough responses, then I'll start > to schedule the meeting. > > However, we do need to get commitment from the current draft editors > that they can publish draft updates beforehand. > > 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 exim@www1.ietf.org Tue Apr 13 12:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19070 for ; Tue, 13 Apr 2004 12:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDQV5-000088-9q for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 12:11:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DGB3Ut000500 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 12:11:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDQV3-000074-MS; Tue, 13 Apr 2004 12:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDQU6-00006E-B2 for nsis@optimus.ietf.org; Tue, 13 Apr 2004 12:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19005 for ; Tue, 13 Apr 2004 12:09:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDQU4-0005f8-00 for nsis@ietf.org; Tue, 13 Apr 2004 12:10:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDQT3-0005bK-00 for nsis@ietf.org; Tue, 13 Apr 2004 12:08:57 -0400 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BDQSA-0005Uk-00 for nsis@ietf.org; Tue, 13 Apr 2004 12:08:02 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3DG79CZ014236 for ; Tue, 13 Apr 2004 11:07:24 -0500 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 4070325900174261; Tue, 13 Apr 2004 12:03:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Questions regarding Date: Tue, 13 Apr 2004 12:07:19 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A06C321C5@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [NSIS] Questions regarding Thread-Index: AcQeXf7C1DKJjWIhSSGWOSH6Z0KCvACwfDUQABQlCcA= From: "Roy, Radhika R, ALABS" To: Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, John: Yes, you are right. What NSIS protocols need to do is as follows: 1. Differentiation in call level priority 2. Differentiation in priority level for each media of a given call = level priority Best regards, Radhika -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Tuesday, April 13, 2004 2:26 AM To: fred@cisco.com; Roy, Radhika R, ALABS Cc: nguyena@ncs.gov; hannes.tschofenig@siemens.com; jmpolk@cisco.com; nsis@ietf.org Subject: RE: [NSIS] Questions regarding Hi Fred & Roy, Catching up after a long weekend: > At 01:26 PM 04/09/04 -0400, Roy, Radhika R, ALABS wrote: > >3. If SDP contains multiple media, how does RSVP will take of media = level=20 > >differentiation in priority in reservation of resources, if something = else=20 > >does not help in differentiating priority of each media? >=20 > I'm not the list moderator, but I'll say something that I'll bet the = list=20 > moderator is thinking: If this is an NSIS requirement, the point on = *this*=20 > list should be to ensure that NSIS (GIMP/NSLP) meets the requirement. = I=20 > understand the working group to not so much be thinking about RSVP as = a=20 > protocol to replace it, hopefully in a manner that is interoperable at = some=20 > level. Agreed - MLPP should be discussed on TSVWG, generally - the point of = discussing it on NSIS is to see what, if anything, needs to be done with NSIS = protocols =20 > I'd suggest that discussion of the NCS/MLPP near-term operational=20 > requirements, which have wandered from SIP to SIPPING to IEPREP to = TSVWG,=20 > not be particularly brought here except to ensure that those needs = will be=20 > met by NSIS when NSIS is done.=20 Agreed. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 13 17:17:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09341 for ; Tue, 13 Apr 2004 17:17:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUzv-0003g8-Hf for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 16:59:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DKxBZk014139 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 16:59:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTvx-0005Pa-Jx; Tue, 13 Apr 2004 15:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTnG-0004DF-RE for nsis@optimus.ietf.org; Tue, 13 Apr 2004 15:42:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02330 for ; Tue, 13 Apr 2004 15:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTnF-0001YT-00 for nsis@ietf.org; Tue, 13 Apr 2004 15:42:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTlV-0001NW-00 for nsis@ietf.org; Tue, 13 Apr 2004 15:40:13 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDTk8-0001BY-00 for nsis@ietf.org; Tue, 13 Apr 2004 15:38:48 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2004 11:47:16 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3DJcEKj009412; Tue, 13 Apr 2004 12:38:14 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA13322; Tue, 13 Apr 2004 12:38:13 -0700 (PDT) Message-Id: <4.3.2.7.2.20040413142158.02747eb8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Apr 2004 14:38:27 -0500 To: Tschofenig Hannes , "'fred@cisco.com'" From: "James M. Polk" Subject: RE: [NSIS] Questions regarding Cc: nsis@ietf.org In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685FC6@mchp905a.mch.sbs. de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Sorry for the late reply to this message (real work got in the way :-( comments in-line At 06:46 PM 4/7/2004 +0200, Tschofenig Hannes wrote: >hi fred, > >thanks for your response. a quick question to better understand the >sip-based approach: > >i thought that the preemption mechanism is also applicable for sip proxies >which handle a large number of calls. The Resource Priority header is not intended to preempt SIP Requests or Responses (although someone could build a proxy to do this), but a Proxy could easy (conceptually at least) make processing decisions as to which messages to process before others (especially in times where the Proxy is approaching its own load capacity maximum). >now, in emergency cases they might >need to drop certain calls. Several responses to this (from different situations): 1) Proxies don't generate the SIP BYE message unless the Proxy is a B2BUA (which means it isn't really a Proxy) - so Proxies (as of right now) don't have a good way of telling UAs that any call should be preempted/terminated 2) without the Proxy being Dialog Stateful (Via and Record Route headers placed into a session set-up message prior to the preemption event needing to take place), the Proxy has no way of knowing about the emergency nature of the new call(s) to preempt the older non-emergency calls. This is an architectural decision of a domain. Remember, proxies are generally thought of as stateless, meaning they can't track down calls to preempt any because they don't remember them. If the Proxy is only transaction stateful (only the Via headers are used during session establishment), then the session set-up can be only interrupted prior to the session being established (which I don't classify as a preemption event, but more of an error event, because RTP hasn't started flowing). >the 'resource-priority' element(s) could be used >for it. given the above constraints and considerations in the Voice architecture of that domain, this is true >ciao >hannes cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 13 17:44:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11511 for ; Tue, 13 Apr 2004 17:44:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVXf-0004CH-Nw for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 17:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DLY3sp016119 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 17:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVJJ-0007Ht-Db; Tue, 13 Apr 2004 17:19:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUvx-0002C4-IT for nsis@optimus.ietf.org; Tue, 13 Apr 2004 16:55:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07270 for ; Tue, 13 Apr 2004 16:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDUvv-0001V4-00 for nsis@ietf.org; Tue, 13 Apr 2004 16:55:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDUoi-0000jo-00 for nsis@ietf.org; Tue, 13 Apr 2004 16:47:37 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDUgs-0007f2-00 for nsis@ietf.org; Tue, 13 Apr 2004 16:39:30 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 Apr 2004 12:49:10 +0000 Received: from CSCOAMERA19540.cisco.com (tky-vpn-client-231-11.cisco.com [10.70.231.11]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3DKcr2P016251; Tue, 13 Apr 2004 13:38:54 -0700 (PDT) Message-Id: <6.0.3.0.2.20040414043725.05bbb1c0@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 14 Apr 2004 04:38:07 +0800 To: "Roy, Radhika R, ALABS" From: Fred Baker Subject: RE: [NSIS] Questions regarding Cc: , In-Reply-To: <34DA635B184A644DA4588E260EC0A25A06C321C5@ACCLUST02EVS1.ugd .att.com> References: <34DA635B184A644DA4588E260EC0A25A06C321C5@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 12:07 PM 04/13/04 -0400, Roy, Radhika R, ALABS wrote: >What NSIS protocols need to do is as follows: > >1. Differentiation in call level priority > >2. Differentiation in priority level for each media of a given call level >priority that for an authenticated user. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 13 17:53:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11947 for ; Tue, 13 Apr 2004 17:53:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVeI-00072B-KR for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 17:40:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DLesiD027034 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 17:40:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVT1-0002qD-FF; Tue, 13 Apr 2004 17:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVGy-0005eX-6v for nsis@optimus.ietf.org; Tue, 13 Apr 2004 17:16:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09122 for ; Tue, 13 Apr 2004 17:16:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVGv-0003e7-00 for nsis@ietf.org; Tue, 13 Apr 2004 17:16:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDV8P-0002kJ-00 for nsis@ietf.org; Tue, 13 Apr 2004 17:07:58 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDUyM-0001m7-00 for nsis@ietf.org; Tue, 13 Apr 2004 16:57:34 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Apr 2004 13:07:15 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3DKv1GF009076; Tue, 13 Apr 2004 13:57:01 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA23308; Tue, 13 Apr 2004 13:56:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20040413143839.0395cf00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Apr 2004 15:57:13 -0500 To: "Hannes Tschofenig" , From: "James M. Polk" Cc: In-Reply-To: <200404031811.i33IBaD26831@mail2.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Re: Questions regarding Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hannes Again, sorry for the late response - and I noticed several of your questions haven't been answered yet, so I'll make an attempt at answering each (I hope), though 1 is deferred and 1 is being researched as I send this At 08:13 PM 4/3/2004 +0200, Hannes Tschofenig wrote: >hi fred, hi james, > >your draft has recently been mentioned in the nsis wg. i have read the draft >and came across a few issues: > >- the details between the preemption defined in > and seem to be a bit >different. have you compared them? Fred answered this well. There is session set-up signaling that has preemption possible only at the endpoints. And there is session set-up signaling that requests (within the SDP as specified in RFC 3312) that an appropriate amount of BW be guaranteed between the two UAs prior to the final SIP signaling acceptance of the set-up (the final 200 OK). If the control plane signaling fails to establish the bandwidth, the domain can use local policy to determine whether it wishes to have the session set-up (as best effort) anyway. MLPP networks will generally *not* want this functionality in the new call set-up. I think those domain might consider (well down the road, meaning years from now) that the preempted call have the choice to "stay up" in a best effort mode (but this can only apply to the case where the call between Carol and Dave was interrupted to make way for the higher priority call between Alice and Bob). I have my thoughts on how endpoint preemption will evolve too, but that is not an NSIS or RSVP discussion. >- in section 2.1 you talk about notifying the end hosts about preemption >(somewhere in the network). also section 1.5 says something similar: >"All callers on the preempted call must be informed that > the call has been preempted, and the call must make way for the > higher precedence call." > >this might be of interest for the qos nslp work in nsis or even for >nat/firewall work?? It should be. This is a case we're arguing is vital. The scenario is this: 3 G.711 calls exist over a 256kbps WAN link (the phones cannot support any other codec in this example) when a 4th caller signals for a call to be established across that same link. Obviously ~ 80kbps more capacity does not exist, but SIP wouldn't know that. SIP, if it is the only means of call establishment and control, will set up the call, thereby reducing the quality of all 4 calls traversing that circuit. The users won't know what happened, just that voice reception quality just tanked. Diffserv does not have a feedback mechanism for real-time communications (ECN isn't used for RTP, and RTCP isn't and shouldn't be relied upon for effective endpoint feedback here either). We're arguing in the above quoted section of mlpp-that-works that the callers should be informed when "something happened to their call" (like a tone, a chime, or a warning signal). If RSVP were to be in place in the above example, the 4th call would only be set-up if it is at a higher priority that at least one of the existing calls (thus preempting one of that 3 calls - and providing positive user feedback to that event), otherwise that 4th caller would receive the equivalent of a busy signal (because although the application layer can set up the call in SIP, the RESV would error due to lack of BW available somewhere in the path). >- type 1 encryption > >what do you consider 'type 1 encryption'? This is a US DOD standard that is not public information, requires a high level of security clearance to discuss, requires a long process of manufacturer clearance to attempt to build and produce products that qualify, and do not use publicly available or publicly known encryption algorithms. I believe DES, 3DES and AES are the "Type 3" algorithms >- authorization > >in section 1.2 you say: >"Since the act of preemption or > consideration of alternative bandwidth sources is part and parcel of > the problem of providing bandwidth, and the authorization step in > bandwidth provision also affects the choice of networks that may be > authorized to be considered." > >i am not quite sure what you mean with ... also affects the choice of >networks....". >could you elaborate? sounds a bit like qos routing. I'll let Fred elaborate on this facet >regarding section 2.3.5.2 i suspect that the typical procedure is as >follows: > >a user adds a priority level in his qos request. the authenticated request >is processed at the first router and forwarded to the "policy decision >point" together with the qos parameters and the indicated priority level. as >part of the authorization procedure the request is granted or rejected. if >it is granted then the request (including the priority level) is forwarded >along the path. is this right? generally yes, but if each router must send a query back to some central server (the PDP), this might get a little slow. Our plan is for this to occur in the LDP in the router. Obviously this cannot be too complicated a decision or a list of possibilities too long (else the LDP will become overburdened). >a minor issue: there is a bug in section 2.3.3 - the relationship between >ipsec encrypted traffic and rsvp signaling. you might want to take a look at >section 5.4 of >http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-04.t >xt I'm reviewing this section with other now, and will respond soon to this section's text >ciao >hannes cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 13 18:41:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16298 for ; Tue, 13 Apr 2004 18:41:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWL3-00067A-C6 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 18:25:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DMP5CH023498 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 18:25:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWFB-0004PW-R3; Tue, 13 Apr 2004 18:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDW9E-0001Pf-GC for nsis@optimus.ietf.org; Tue, 13 Apr 2004 18:12:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14140 for ; Tue, 13 Apr 2004 18:12:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDW9A-000146-00 for nsis@ietf.org; Tue, 13 Apr 2004 18:12:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVqX-0007Nj-00 for nsis@ietf.org; Tue, 13 Apr 2004 17:53:35 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDVbn-0005iD-00 for nsis@ietf.org; Tue, 13 Apr 2004 17:38:19 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 13 Apr 2004 13:48:00 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3DLbjew024351; Tue, 13 Apr 2004 14:37:46 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA16621; Tue, 13 Apr 2004 14:37:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20040413160044.0374dd58@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Apr 2004 16:34:40 -0500 To: "Roy, Radhika R, ALABS" , From: "James M. Polk" Subject: RE: [NSIS] Questions regarding Cc: In-Reply-To: <34DA635B184A644DA4588E260EC0A25A06C321C5@ACCLUST02EVS1.ugd .att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 12:07 PM 4/13/2004 -0400, Roy, Radhika R, ALABS wrote: >Hi, John: > >Yes, you are right. > >What NSIS protocols need to do is as follows: > >1. Differentiation in call level priority > >2. Differentiation in priority level for each media of a given call level >priority certainly these aren't the only 2 requirements involving this particular effort, but a good high level start some other aspects that need to be considered are: - is the initiator authorized to use a particular priority level? - is the system designed to authorize ranges of priority levels, or just a specific level at a time? - how will NSIS & SIP interact to synchronize the control and application layer prioritization? - what's the treatment/behavior of preemption (where and how can it occur)? - are endpoints and nodes notified of preemption events? - if either are, how are endpoints and/or nodes informed of preemption events? - is there more than one type of preemption? - if so, how many other types of preemptions can there be (and what behavior with there be for each)? the list above goes on quite a bit >Best regards, >Radhika > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: Tuesday, April 13, 2004 2:26 AM >To: fred@cisco.com; Roy, Radhika R, ALABS >Cc: nguyena@ncs.gov; hannes.tschofenig@siemens.com; jmpolk@cisco.com; >nsis@ietf.org >Subject: RE: [NSIS] Questions regarding > > > >Hi Fred & Roy, > >Catching up after a long weekend: > > > At 01:26 PM 04/09/04 -0400, Roy, Radhika R, ALABS wrote: > > >3. If SDP contains multiple media, how does RSVP will take of media level > > >differentiation in priority in reservation of resources, if something > else > > >does not help in differentiating priority of each media? > > > > I'm not the list moderator, but I'll say something that I'll bet the list > > moderator is thinking: If this is an NSIS requirement, the point on *this* > > list should be to ensure that NSIS (GIMP/NSLP) meets the requirement. I > > understand the working group to not so much be thinking about RSVP as a > > protocol to replace it, hopefully in a manner that is interoperable at > some > > level. > >Agreed - MLPP should be discussed on TSVWG, generally - the point of >discussing >it on NSIS is to see what, if anything, needs to be done with NSIS protocols > > > I'd suggest that discussion of the NCS/MLPP near-term operational > > requirements, which have wandered from SIP to SIPPING to IEPREP to TSVWG, > > not be particularly brought here except to ensure that those needs will be > > met by NSIS when NSIS is done. > >Agreed. > >thanks, >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 13 18:55:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17123 for ; Tue, 13 Apr 2004 18:55:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWfd-00015z-66 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 18:46:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DMkLEl004212 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 18:46:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWbT-0008Vp-PS; Tue, 13 Apr 2004 18:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWQ0-0006dY-6t for nsis@optimus.ietf.org; Tue, 13 Apr 2004 18:30:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15723 for ; Tue, 13 Apr 2004 18:30:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDWPw-0002U2-00 for nsis@ietf.org; Tue, 13 Apr 2004 18:30:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDWCu-0001Dw-00 for nsis@ietf.org; Tue, 13 Apr 2004 18:16:42 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDVs9-0007Vu-00 for nsis@ietf.org; Tue, 13 Apr 2004 17:55:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Apr 2004 14:04:56 +0000 Received: from CSCOAMERA19540.cisco.com (tky-vpn-client-231-11.cisco.com [10.70.231.11]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3DLscGG021042; Tue, 13 Apr 2004 14:54:40 -0700 (PDT) Message-Id: <6.0.3.0.2.20040414053733.057b3670@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 14 Apr 2004 05:49:58 +0800 To: "James M. Polk" , "Hannes Tschofenig" From: Fred Baker Cc: In-Reply-To: <4.3.2.7.2.20040413143839.0395cf00@localhost> References: <200404031811.i33IBaD26831@mail2.siemens.de> <4.3.2.7.2.20040413143839.0395cf00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Re: Questions regarding Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 03:57 PM 04/13/04 -0500, James M. Polk wrote: >>- authorization >> >>in section 1.2 you say: >>"Since the act of preemption or >> consideration of alternative bandwidth sources is part and parcel of >> the problem of providing bandwidth, and the authorization step in >> bandwidth provision also affects the choice of networks that may be >> authorized to be considered." >> >>i am not quite sure what you mean with ... also affects the choice of >>networks....". >>could you elaborate? sounds a bit like qos routing. > >I'll let Fred elaborate on this facet The entire paragraph is: 1.2 Definition of Call Admission Traditionally, in the PSTN, "Call Admission Control", or CAC, has had the responsibility of determining whether a caller has permission (an identified subscriber, with identify attested to by appropriate credentials, is authorized) to use an available circuit. MLPP, or any emergency telephone service, creates two feedback paths in the algorithm: if a caller is authorized to use a higher precedence and is asserting that the advanced precedence applies to a given call, he may also be authorized to use other networks, or the PSTN may be obligated to preempt a call if possible and necessary to create appropriate bandwidth, or it may be authorized to use a guard band of bandwidth that other callers are not. At the completion of CAC, however, the caller either has a circuit that he or she is authorized to use, or has no circuit. Since the act of preemption or consideration of alternative bandwidth sources is part and parcel of the problem of providing bandwidth, the authorization step in bandwidth provision also affects the choice of networks that may be authorized to be considered. The three cannot be separated. The CAC procedure finds available bandwidth that the caller is authorized to use and preemption may in some networks be part of making that happen. In the PSTN, which is the context of this paragraph, there is in fact the potential for call routing. In the Internet, at least at this point, call routing is not one of the options. >>a minor issue: there is a bug in section 2.3.3 Thanks for pointing that out. That's the reason we post documents for open discussion... _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 13 22:56:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26151 for ; Tue, 13 Apr 2004 22:56:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDaXq-0004T5-AS for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 22:54:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E2sY5W017169 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 22:54:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDaUR-00043Y-M0; Tue, 13 Apr 2004 22:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDaPg-0003Zn-Mr for nsis@optimus.ietf.org; Tue, 13 Apr 2004 22:46:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25817 for ; Tue, 13 Apr 2004 22:46:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDaPd-0003gs-00 for nsis@ietf.org; Tue, 13 Apr 2004 22:46:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDaOj-0003bW-00 for nsis@ietf.org; Tue, 13 Apr 2004 22:45:09 -0400 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BDaNt-0003QN-00 for nsis@ietf.org; Tue, 13 Apr 2004 22:44:17 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3E2hjBM029653 for ; Tue, 13 Apr 2004 22:43:47 -0400 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 4070325900190E40; Tue, 13 Apr 2004 22:39:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Re: Questions regarding Date: Tue, 13 Apr 2004 22:43:47 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A06C615B4@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [NSIS] Re: Questions regarding Thread-Index: AcQhqR3rW6/zSWeVTdmzFHaAC4KDiAAHeiMg From: "Roy, Radhika R, ALABS" To: "Fred Baker" , "James M. Polk" , "Hannes Tschofenig" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Good points. Inline [RRR] -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Fred Baker Sent: Tuesday, April 13, 2004 5:50 PM To: James M. Polk; Hannes Tschofenig Cc: nsis@ietf.org Subject: [NSIS] Re: Questions regarding ... In the PSTN, which is the context of this paragraph, there is in fact the=20 potential for call routing. In the Internet, at least at this point, call=20 routing is not one of the options. ... [RRR] Right. Another problem in the PSTN may be is this: No separation between call and connection. In the Internet/SIP environment, we can separate between call and connection. Even, we can apply two level of CAC: 1. SIP layer CAC - resources of SIP entities (e.g., CPU/port capacity of proxies) and 2. IP layer CAC - resources of IP routers (e.g., bandwidth, delay, jitter). [RRR] For example, SIP resources reservation RFC provides indication when resources reservation needs to be started, and is not involved how resources of SIP layer and IP layer are reserved. As soon as resources of both layers are reserved, it is assumed that somehow an indication is provided that the resources reservation is complete, and then the ringing tone and other SIP signaling messages start to continue. It may be noted that the SIP layer does not know how long it will take to complete the resources reservation. As result, it is needed to stop the retransmissions of the SIP signaling messages using an ack of the provisional responses like PRACK. This is the contribution of this RFC. [RRR] This point shows that there is a need to bridge the above gap of QoS signaling mechanisms between the SIP layer and the IP layer. I believe that NSIS protocols are the right things to bridge the gap of the QoS signaling. [RRR] NSIS protocols need to fit into two layers of CAC of the Internet/SIP along with all priorities/pre-emption as we are discussing.. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 13 23:51:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29610 for ; Tue, 13 Apr 2004 23:51:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDbJi-0003NW-Cf for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 23:44:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E3i2tT012982 for nsis-archive@odin.ietf.org; Tue, 13 Apr 2004 23:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDbDx-0002S6-VN; Tue, 13 Apr 2004 23:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDanq-0007Ai-FX for nsis@optimus.ietf.org; Tue, 13 Apr 2004 23:11:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26687 for ; Tue, 13 Apr 2004 23:11:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDanm-0006JC-00 for nsis@ietf.org; Tue, 13 Apr 2004 23:11:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDalA-00065G-00 for nsis@ietf.org; Tue, 13 Apr 2004 23:08:22 -0400 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BDajL-0005lw-00 for nsis@ietf.org; Tue, 13 Apr 2004 23:06:27 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3E35WBL000533 for ; Tue, 13 Apr 2004 23:05:58 -0400 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 40703259001916CB; Tue, 13 Apr 2004 23:01:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Questions regarding Date: Tue, 13 Apr 2004 23:05:57 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A06C615BD@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [NSIS] Questions regarding Thread-Index: AcQhn5lcjn4sbUOMSm6OOs1YpkBMywAKwtiA From: "Roy, Radhika R, ALABS" To: "James M. Polk" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Good points. In addition to call-level and media-level priority, I find that your items 3 and 4 are critical. However, I have provided some indications how we can proceed for all the items that you have indicated. Inline [RRR]. -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Tuesday, April 13, 2004 5:35 PM To: Roy, Radhika R, ALABS; john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Questions regarding At 12:07 PM 4/13/2004 -0400, Roy, Radhika R, ALABS wrote: >Hi, John: > >Yes, you are right. > >What NSIS protocols need to do is as follows: > >1. Differentiation in call level priority > >2. Differentiation in priority level for each media of a given call level=20 >priority certainly these aren't the only 2 requirements involving this particular effort, but a good high level start [RRR] Right. some other aspects that need to be considered are: 1- is the initiator authorized to use a particular priority level? [RRR} It is taken care of today as can be seen used in RADIUS/DIAMETER protocol. For example, NSIS/SIP entities can check with the AAA server to make sure of the authorization. 2- is the system designed to authorize ranges of priority levels, or just a=20 specific level at a time? [RRR] We can start looking as pointed above. 3- how will NSIS & SIP interact to synchronize the control and application=20 layer prioritization? [RRR] In response of another email of Fred Baker, I have provided some hints how we can address this. It may be a good starting point. 4- what's the treatment/behavior of preemption (where and how can it occur)? [RRR] A logical answer of this question will be to start at the sources based on some policies. For example, it can be SIP proxies in the case of SIP protocol. Similar is the case for the NSIS-aware entities. 5- are endpoints and nodes notified of preemption events? [RRR] Why not if it is possible? 6- if either are, how are endpoints and/or nodes informed of preemption events? [RRR] A kind of pre-emption notification message. 7- is there more than one type of preemption? [RRR] May be depending types of call pre-emption made. 8- if so, how many other types of preemptions can there be (and what=20 behavior with there be for each)? [RRR] We can start with a reasonable set. the list above goes on quite a bit >Best regards, >Radhika > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: Tuesday, April 13, 2004 2:26 AM >To: fred@cisco.com; Roy, Radhika R, ALABS >Cc: nguyena@ncs.gov; hannes.tschofenig@siemens.com; jmpolk@cisco.com; >nsis@ietf.org >Subject: RE: [NSIS] Questions regarding > > > >Hi Fred & Roy, > >Catching up after a long weekend: > > > At 01:26 PM 04/09/04 -0400, Roy, Radhika R, ALABS wrote: > > >3. If SDP contains multiple media, how does RSVP will take of media level > > >differentiation in priority in reservation of resources, if something=20 > else > > >does not help in differentiating priority of each media? > > > > I'm not the list moderator, but I'll say something that I'll bet the list > > moderator is thinking: If this is an NSIS requirement, the point on *this* > > list should be to ensure that NSIS (GIMP/NSLP) meets the requirement. I > > understand the working group to not so much be thinking about RSVP as a > > protocol to replace it, hopefully in a manner that is interoperable at=20 > some > > level. > >Agreed - MLPP should be discussed on TSVWG, generally - the point of=20 >discussing >it on NSIS is to see what, if anything, needs to be done with NSIS protocols > > > I'd suggest that discussion of the NCS/MLPP near-term operational > > requirements, which have wandered from SIP to SIPPING to IEPREP to TSVWG, > > not be particularly brought here except to ensure that those needs will be > > met by NSIS when NSIS is done. > >Agreed. > >thanks, >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 14 07:17:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17333 for ; Wed, 14 Apr 2004 07:17:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDiKm-0005Ry-Ks for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 07:13:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EBDa5C020936 for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 07:13:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDiGL-0004QH-8N; Wed, 14 Apr 2004 07:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDiC0-0003Bw-8A for nsis@optimus.ietf.org; Wed, 14 Apr 2004 07:04:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16839 for ; Wed, 14 Apr 2004 07:04:29 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDiBv-0007Sr-00 for nsis@ietf.org; Wed, 14 Apr 2004 07:04:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDiAw-0007Mq-00 for nsis@ietf.org; Wed, 14 Apr 2004 07:03:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDiAa-0007H5-00 for nsis@ietf.org; Wed, 14 Apr 2004 07:03:04 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3EB34H10185 for ; Wed, 14 Apr 2004 14:03:04 +0300 (EET DST) X-Scanned: Wed, 14 Apr 2004 14:02:55 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3EB2ts0019045 for ; Wed, 14 Apr 2004 14:02:55 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00r3A7jv; Wed, 14 Apr 2004 14:02:54 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3EB2mF06107 for ; Wed, 14 Apr 2004 14:02:49 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 14 Apr 2004 14:02:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2004 14:02:16 +0300 Message-ID: Thread-Topic: Interim Meeting Thread-Index: AcQdUtBJdl3LxIBbRuaWtrGGumgH+AEvFnmA To: X-OriginalArrivalTime: 14 Apr 2004 11:02:16.0568 (UTC) FILETIME=[F2BF1780:01C4220F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Interim Meeting proposal Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, It seems that June 1st - 3rd would be the best dates for the interim meeting. The earlier dates conflict with the SIPPING, etc. interim meeting. Cornelia mentioned that the 3rd would not be good for her, so perhaps we can schedule some of the discussions around her needs. Robert Hancock has said that Roke Manor Research Ltd can host the = meeting. Robert, can you provide information on accomodations, nearby airports, = etc? thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 14 07:41:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18206 for ; Wed, 14 Apr 2004 07:41:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDiiq-0001rr-N6 for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 07:38:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EBcS3O007167 for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 07:38:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDiaf-0008TT-NY; Wed, 14 Apr 2004 07:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDiWH-0006y4-A2 for nsis@optimus.ietf.org; Wed, 14 Apr 2004 07:25:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17623 for ; Wed, 14 Apr 2004 07:25:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDiWG-0002Dz-00 for nsis@ietf.org; Wed, 14 Apr 2004 07:25:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDiVM-00027z-00 for nsis@ietf.org; Wed, 14 Apr 2004 07:24:33 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDiUq-00021G-00 for nsis@ietf.org; Wed, 14 Apr 2004 07:24:00 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2004 03:32:37 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3EBNR2O003193; Wed, 14 Apr 2004 04:23:28 -0700 (PDT) Received: from stealth-10-32-245-156.cisco.com (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOC31462; Wed, 14 Apr 2004 04:23:26 -0700 (PDT) Date: Wed, 14 Apr 2004 07:23:20 -0400 From: David Oran To: "Roy, Radhika R, ALABS" , john.loughney@nokia.com cc: nsis@ietf.org Subject: RE: [NSIS] Questions regarding Message-ID: <2147483647.1081927400@[10.32.245.156]> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A06C321C5@ACCLUST02EVS1.ugd.att.com> References: <34DA635B184A644DA4588E260EC0A25A06C321C5@ACCLUST02EVS1.ugd.att. com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Tuesday, April 13, 2004 12:07 PM -0400 "Roy, Radhika R, ALABS" wrote: > Hi, John: > > Yes, you are right. > > What NSIS protocols need to do is as follows: > > 1. Differentiation in call level priority > uh, don't think so. NSIS doesn't know a "call" from a hole in the ground > 2. Differentiation in priority level for each media of a given call level > priority > modulo needing both preemption and holding precedence, and possibly a restoration precedence too, yes. note that the identifier space can't be private to the protocol layer either. It needs to be a "first class object" that is both read/write through the application interface to NSIS protocols in hosts. Dave. > Best regards, > Radhika > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, April 13, 2004 2:26 AM > To: fred@cisco.com; Roy, Radhika R, ALABS > Cc: nguyena@ncs.gov; hannes.tschofenig@siemens.com; jmpolk@cisco.com; > nsis@ietf.org > Subject: RE: [NSIS] Questions regarding > > > > Hi Fred & Roy, > > Catching up after a long weekend: > >> At 01:26 PM 04/09/04 -0400, Roy, Radhika R, ALABS wrote: >> > 3. If SDP contains multiple media, how does RSVP will take of media >> > level differentiation in priority in reservation of resources, if >> > something else does not help in differentiating priority of each >> > media? >> >> I'm not the list moderator, but I'll say something that I'll bet the >> list moderator is thinking: If this is an NSIS requirement, the point >> on *this* list should be to ensure that NSIS (GIMP/NSLP) meets the >> requirement. I understand the working group to not so much be thinking >> about RSVP as a protocol to replace it, hopefully in a manner that is >> interoperable at some level. > > Agreed - MLPP should be discussed on TSVWG, generally - the point of > discussing it on NSIS is to see what, if anything, needs to be done with > NSIS protocols >> I'd suggest that discussion of the NCS/MLPP near-term operational >> requirements, which have wandered from SIP to SIPPING to IEPREP to >> TSVWG, not be particularly brought here except to ensure that those >> needs will be met by NSIS when NSIS is done. > > Agreed. > > 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 exim@www1.ietf.org Wed Apr 14 08:11:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19529 for ; Wed, 14 Apr 2004 08:11:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjBt-0007Or-37 for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 08:08:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EC8Tcw028431 for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 08:08:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDj4f-0005sG-TI; Wed, 14 Apr 2004 08:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDizl-00053p-AA for nsis@optimus.ietf.org; Wed, 14 Apr 2004 07:55:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18882 for ; Wed, 14 Apr 2004 07:55:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDizk-0006Ao-00 for nsis@ietf.org; Wed, 14 Apr 2004 07:55:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDiyo-00060U-00 for nsis@ietf.org; Wed, 14 Apr 2004 07:54:58 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BDixw-0005ih-00 for nsis@ietf.org; Wed, 14 Apr 2004 07:54:04 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <2M893B3Q>; Wed, 14 Apr 2004 12:53:21 +0100 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Interim Meeting proposal Date: Wed, 14 Apr 2004 12:53:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, I will post a link with info on Monday. In the meantime, people who think they may need visas might like to check the following: Nationals of some countries may need a visa to visit the UK. Details are available on the surprisingly helpful and well designed UK Visa Website http://www.ukvisas.gov.uk/ which tells you what you need to do depending on your nationality and current residence. Usually you can apply from the country of your current residence, and sometimes by post. Although the process is not necessarily lengthy, leave yourself plenty of time; in particular, please tell us **as soon as possible** if you need a letter of invitation or other information from us. Cheers, r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, April 14, 2004 12:02 > To: nsis@ietf.org > Subject: [NSIS] Interim Meeting proposal > > > Hi all, > > It seems that June 1st - 3rd would be the best dates for the interim > meeting. The earlier dates conflict with the SIPPING, etc. interim > meeting. > > Cornelia mentioned that the 3rd would not be good for her, so > perhaps we > can schedule some of the discussions around her needs. > > Robert Hancock has said that Roke Manor Research Ltd can host > the meeting. > Robert, can you provide information on accomodations, nearby > airports, etc? > > 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 exim@www1.ietf.org Wed Apr 14 08:20:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19908 for ; Wed, 14 Apr 2004 08:20:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjJu-0000U1-L1 for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 08:16:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ECGkcs001843 for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 08:16:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjEL-00084q-IL; Wed, 14 Apr 2004 08:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDj6E-0006EB-3h for nsis@optimus.ietf.org; Wed, 14 Apr 2004 08:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19160 for ; Wed, 14 Apr 2004 08:02:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDj6D-00073c-00 for nsis@ietf.org; Wed, 14 Apr 2004 08:02:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDj5N-0006wm-00 for nsis@ietf.org; Wed, 14 Apr 2004 08:01:46 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BDj4P-0006oo-00 for nsis@ietf.org; Wed, 14 Apr 2004 08:00:45 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3EC0hn29562; Wed, 14 Apr 2004 14:00:44 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3EC0hc18047; Wed, 14 Apr 2004 14:00:43 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Apr 2004 13:59:52 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FE4@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'David Oran'" Cc: nsis@ietf.org Date: Wed, 14 Apr 2004 14:00:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] radius/qos question Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 dave, in the meeting minutes i recorded a small comment on radius and qos authorization: " Dave: People often want to envelope authorization. Radius is no tightly synchronized to provide this functionality ; COPS is. " could you provide more details on your thoughts about the relationship between radius/qos vs. cops/qos? thanks in advance. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 14 08:20:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19976 for ; Wed, 14 Apr 2004 08:20:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjLZ-0000rp-1q for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 08:18:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ECITBQ003319 for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 08:18:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjEM-000858-Bk; Wed, 14 Apr 2004 08:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDj72-0006Ms-IH for nsis@optimus.ietf.org; Wed, 14 Apr 2004 08:03:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19178 for ; Wed, 14 Apr 2004 08:03:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDj71-00079i-00 for nsis@ietf.org; Wed, 14 Apr 2004 08:03:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDj62-00072a-00 for nsis@ietf.org; Wed, 14 Apr 2004 08:02:27 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BDj55-0006pB-00 for nsis@ietf.org; Wed, 14 Apr 2004 08:01:27 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <2M80MQAR>; Wed, 14 Apr 2004 13:00:56 +0100 Message-ID: From: "Hancock, Robert" To: "'David Oran'" , "Roy, Radhika R, ALABS" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Questions regarding Date: Wed, 14 Apr 2004 13:00:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, > > Yes, you are right. > > > > What NSIS protocols need to do is as follows: > > > > 1. Differentiation in call level priority > > > uh, don't think so. NSIS doesn't know a "call" from a hole in > the ground NSIS fundamentally knows about flows (unicast, unidirectional, defined by an ntuple), and signalling applications can map these to things called "NSIS sessions" how they like. How these get mapped to 'calls' is something I would assume is an upper-layer issue in the call endpoints (especially e.g. if a 'call' is a duplex thing). > > > 2. Differentiation in priority level for each media of a > given call level > > priority > > > modulo needing both preemption and holding precedence, and possibly a > restoration precedence too, yes. > > note that the identifier space can't be private to the protocol layer > either. It needs to be a "first class object" that is both read/write > through the application interface to NSIS protocols in hosts. This is an important point. I assume the expectation is that this identifier would need to be communicated in non-NSIS protocols e.g. between the user application peers. Are there any established requirements for such identifiers (e.g. which node is expected to allocate them, at what stage during a call does each end need to know about them)? This could have interesting impacts on the NSIS protocol design details. [There has been some discussion of what identifier space to use in the NATFW signalling application drafts, specifically whether to use the NSIS session id or the flow identification N-tuple. But I don't think there are any firm conclusions on that yet.] r. > > Dave. > > > Best regards, > > Radhika _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 14 13:16:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07515 for ; Wed, 14 Apr 2004 13:16:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnc3-0003Q7-2U for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 12:51:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EGpl68013133 for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 12:51:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnCJ-0005J9-2v; Wed, 14 Apr 2004 12:25:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmtl-0001iC-K6 for nsis@optimus.ietf.org; Wed, 14 Apr 2004 12:06:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03359 for ; Wed, 14 Apr 2004 12:05:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmtk-0003gU-00 for nsis@ietf.org; Wed, 14 Apr 2004 12:06:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmsm-0003f8-00 for nsis@ietf.org; Wed, 14 Apr 2004 12:05:01 -0400 Received: from smail3.alcatel.fr ([62.23.212.56]) by ietf-mx with esmtp (Exim 4.12) id 1BDms3-0003bO-00 for nsis@ietf.org; Wed, 14 Apr 2004 12:04:16 -0400 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i3EG3ZJ5022104; Wed, 14 Apr 2004 18:03:35 +0200 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004041418033366:4344 ; Wed, 14 Apr 2004 18:03:33 +0200 Message-ID: <407D60D6.7010208@alcatel.fr> Date: Wed, 14 Apr 2004 18:03:34 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: Tschofenig Hannes Cc: "'David Oran'" , nsis@ietf.org Subject: Re: [NSIS] radius/qos question References: <2A8DB02E3018D411901B009027FD3A3F04685FE4@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685FE4@mchp905a.mch.sbs.de> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/14/2004 18:03:33, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/14/2004 18:03:35, Serialize complete at 04/14/2004 18:03:35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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 hannes, you will find some answers to your question in this document: http://www.ietf.org/rfc/rfc3127.txt?number=3127 but take it cautiously: it dates back to 2001 and time went by meanwhile, especially concerning COPS... thanks, yacine Tschofenig Hannes wrote: > hi dave, > > in the meeting minutes i recorded a small comment on radius and qos > authorization: > > " > Dave: People often want to envelope authorization. Radius is no tightly > synchronized to provide this functionality ; COPS is. > " > > could you provide more details on your thoughts about the relationship > between radius/qos vs. cops/qos? > > thanks in advance. > > ciao > hannes > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 14 13:18:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07621 for ; Wed, 14 Apr 2004 13:18:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnlO-0006DU-OJ for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 13:01:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EH1QF8023880 for nsis-archive@odin.ietf.org; Wed, 14 Apr 2004 13:01:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnCV-0005Qb-Ps; Wed, 14 Apr 2004 12:25:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDn0X-0003E5-U8 for nsis@optimus.ietf.org; Wed, 14 Apr 2004 12:13:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03665 for ; Wed, 14 Apr 2004 12:12:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDn0W-00040V-00 for nsis@ietf.org; Wed, 14 Apr 2004 12:13:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmzb-0003yu-00 for nsis@ietf.org; Wed, 14 Apr 2004 12:12:04 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BDmzK-0003xU-00 for nsis@ietf.org; Wed, 14 Apr 2004 12:11:46 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i3EGBjs25479; Wed, 14 Apr 2004 18:11:45 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3EGBjc12507; Wed, 14 Apr 2004 18:11:45 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Apr 2004 18:10:55 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FEC@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yacine.El_Mghazli@alcatel.fr'" Cc: "'David Oran'" , nsis@ietf.org Subject: RE: [NSIS] radius/qos question Date: Wed, 14 Apr 2004 18:11:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 yacine, thanks for pointing me to this document. i have read it some time ago (years). i should certainly take a look at it again. maybe dave was referring to some issues in this document. i don't know. ciao hannes > -----Original Message----- > From: Yacine.El_Mghazli@alcatel.fr > [mailto:Yacine.El_Mghazli@alcatel.fr] > Sent: Wednesday, April 14, 2004 6:04 PM > To: Tschofenig Hannes > Cc: 'David Oran'; nsis@ietf.org > Subject: Re: [NSIS] radius/qos question > > > hi hannes, > > you will find some answers to your question in this document: > http://www.ietf.org/rfc/rfc3127.txt?number=3127 > > but take it cautiously: it dates back to 2001 and time went by > meanwhile, especially concerning COPS... > > thanks, > yacine > > > > > > Tschofenig Hannes wrote: > > hi dave, > > > > in the meeting minutes i recorded a small comment on radius and qos > > authorization: > > > > " > > Dave: People often want to envelope authorization. Radius > is no tightly > > synchronized to provide this functionality ; COPS is. > > " > > > > could you provide more details on your thoughts about the > relationship > > between radius/qos vs. cops/qos? > > > > thanks in advance. > > > > ciao > > hannes > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:14:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25772 for ; Thu, 15 Apr 2004 10:14:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7MV-0005I7-Tp for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 09:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDv3Rl020339 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 09:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Gg-0003f2-Bq; Thu, 15 Apr 2004 09:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7C5-0001kL-71 for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:46:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23629 for ; Thu, 15 Apr 2004 09:46:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7C3-0003gU-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7B3-0003YX-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:45:14 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BE7AH-0003TN-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:44:25 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDiOI10074; Thu, 15 Apr 2004 15:44:24 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDiNc05518; Thu, 15 Apr 2004 15:44:23 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:43:32 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686003@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'James M. Polk'" , fred@cisco.com Cc: nsis@ietf.org Date: Thu, 15 Apr 2004 15:43:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] RE: Questions regarding Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 james, thanks for your detailed response. please see my comments inline: > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Tuesday, April 13, 2004 10:57 PM > To: Tschofenig Hannes; fred@cisco.com > Cc: nsis@ietf.org > Subject: Re: Questions regarding > > > > Hannes > > Again, sorry for the late response - and I noticed several of your > questions haven't been answered yet, so I'll make an attempt > at answering > each (I hope), though 1 is deferred and 1 is being researched > as I send this > > At 08:13 PM 4/3/2004 +0200, Hannes Tschofenig wrote: > >hi fred, hi james, > > > >your draft has recently been mentioned in the nsis wg. i > have read the draft > >and came across a few issues: > > > >- the details between the preemption defined in > > and > seem to be a bit > >different. have you compared them? > > Fred answered this well. There is session set-up signaling that has > preemption possible only at the endpoints. And there is > session set-up > signaling that requests (within the SDP as specified in RFC > 3312) that an > appropriate amount of BW be guaranteed between the two UAs > prior to the > final SIP signaling acceptance of the set-up (the final 200 > OK). If the > control plane signaling fails to establish the bandwidth, the > domain can > use local policy to determine whether it wishes to have the > session set-up > (as best effort) anyway. MLPP networks will generally *not* want this > functionality in the new call set-up. I think those domain > might consider > (well down the road, meaning years from now) that the > preempted call have > the choice to "stay up" in a best effort mode (but this can > only apply to > the case where the call between Carol and Dave was > interrupted to make way > for the higher priority call between Alice and Bob). > > I have my thoughts on how endpoint preemption will evolve > too, but that is > not an NSIS or RSVP discussion. > thanks. i guess i now understand the differences much better. > > >- in section 2.1 you talk about notifying the end hosts > about preemption > >(somewhere in the network). also section 1.5 says something similar: > >"All callers on the preempted call must be informed that > > the call has been preempted, and the call must make > way for the > > higher precedence call." > > > >this might be of interest for the qos nslp work in nsis or even for > >nat/firewall work?? > > It should be. This is a case we're arguing is vital. The > scenario is this: > 3 G.711 calls exist over a 256kbps WAN link (the phones > cannot support any > other codec in this example) when a 4th caller signals for a > call to be > established across that same link. Obviously ~ 80kbps more > capacity does > not exist, but SIP wouldn't know that. SIP, if it is the only > means of call > establishment and control, will set up the call, thereby reducing the > quality of all 4 calls traversing that circuit. The users > won't know what > happened, just that voice reception quality just tanked. > Diffserv does not > have a feedback mechanism for real-time communications (ECN > isn't used for > RTP, and RTCP isn't and shouldn't be relied upon for > effective endpoint > feedback here either). > > We're arguing in the above quoted section of mlpp-that-works that the > callers should be informed when "something happened to their > call" (like a > tone, a chime, or a warning signal). If RSVP were to be in > place in the > above example, the 4th call would only be set-up if it is at a higher > priority that at least one of the existing calls (thus > preempting one of > that 3 calls - and providing positive user feedback to that event), > otherwise that 4th caller would receive the equivalent of a > busy signal > (because although the application layer can set up the call > in SIP, the > RESV would error due to lack of BW available somewhere in the path). > thanks for your explanations. > > >- type 1 encryption > > > >what do you consider 'type 1 encryption'? > > This is a US DOD standard that is not public information, > requires a high > level of security clearance to discuss, requires a long process of > manufacturer clearance to attempt to build and produce products that > qualify, and do not use publicly available or publicly known > encryption > algorithms. > > I believe DES, 3DES and AES are the "Type 3" algorithms i was just curious - some fancy encryption stuff. > > > >- authorization > > > >in section 1.2 you say: > >"Since the act of preemption or > > consideration of alternative bandwidth sources is part > and parcel of > > the problem of providing bandwidth, and the authorization step in > > bandwidth provision also affects the choice of networks > that may be > > authorized to be considered." > > > >i am not quite sure what you mean with ... also affects the choice of > >networks....". > >could you elaborate? sounds a bit like qos routing. > > I'll let Fred elaborate on this facet > > > >regarding section 2.3.5.2 i suspect that the typical procedure is as > >follows: > > > >a user adds a priority level in his qos request. the > authenticated request > >is processed at the first router and forwarded to the > "policy decision > >point" together with the qos parameters and the indicated > priority level. as > >part of the authorization procedure the request is granted > or rejected. if > >it is granted then the request (including the priority > level) is forwarded > >along the path. is this right? > > generally yes, but if each router must send a query back to > some central > server (the PDP), this might get a little slow. Our plan is > for this to > occur in the LDP in the router. Obviously this cannot be too > complicated a > decision or a list of possibilities too long (else the LDP > will become > overburdened). i agree with you but it might be more difficult to have intermediate routers to decide by their own. if we speak about different levels of priorities in rsvp then there must be a way to figure out whether one is entitled to indicate a certain priority level. why wouldn't i always set a high priority. i once heard that people belonging to some governmental agencies can give their phone calls higher priority (which might be useful in emergency cases) by dialing some special numbers (passcodes or something similar). i don't know whether this is actually true but it sounds like role-based access control to me and possibly useful. are you aware of something like this? > > > >a minor issue: there is a bug in section 2.3.3 - the > relationship between > >ipsec encrypted traffic and rsvp signaling. you might want > to take a look at > >section 5.4 of > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec- properties-04.t >xt > I'm reviewing this section with other now, and will respond soon to this > section's text i can also send you text, if you want. >ciao >hannes ciao hannes > cheers, > James ******************* Truth is not to be argued... it is to be presented _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:14:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25803 for ; Thu, 15 Apr 2004 10:14:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7P7-0005xs-Ep for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 09:59:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDxjYk022914 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 09:59:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Gi-0003fG-7k; Thu, 15 Apr 2004 09:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7D2-0002N2-Fw for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:47:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23736 for ; Thu, 15 Apr 2004 09:47:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7D0-0003oL-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:47:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7CD-0003hq-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:25 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BE7BG-0003aG-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:45:26 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDjOI11083 for ; Thu, 15 Apr 2004 15:45:24 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDjOc06559 for ; Thu, 15 Apr 2004 15:45:24 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:44:33 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686005@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Thu, 15 Apr 2004 15:44:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Security Threats for NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, i am currently trying to incorporate your comments regarding the security threats for nsis. i will address the different issues separate mails (since most of them are not related to each other). it also helps to have the discussions more focused. ciao hannes ps: i will also go through the comments of michael richardson once more. further issues might follow! _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:14:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25823 for ; Thu, 15 Apr 2004 10:14:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7QI-000742-Mh for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:00:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FE0wJT027138 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:00:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Gi-0003fj-N3; Thu, 15 Apr 2004 09:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7D4-0002N6-O2 for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:47:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23739 for ; Thu, 15 Apr 2004 09:47:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7D2-0003of-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:47:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7CK-0003iv-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:32 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BE7BQ-0003bc-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:45:36 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDjZn18603 for ; Thu, 15 Apr 2004 15:45:35 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDjYc06785 for ; Thu, 15 Apr 2004 15:45:34 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:44:43 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686006@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Thu, 15 Apr 2004 15:45:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Security Threats for NSIS : Insecure Parameter Exchange and Negot iation Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, > 3.4 Insecure Parameter Exchange and Negotiation > I think this threat is very important to consider. But is there > any way to handle it except in the context of a security protocol > (unless you rely on static policies)? You can always mount a > downgrading attack on the authentication process itself, at > which point you are finished. yes. typically one has to repeat the parameters again after a security association has been established. if the weakest mechanism is resistant against a real-time attack (i.e., a cryptomechanism which can be broken in realtime before the negotiation is completed) then the modification will be discovered. you can find an example of this in: http://www.ietf.org/rfc/rfc3329.txt ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:14:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25871 for ; Thu, 15 Apr 2004 10:14:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7SI-0001AI-TA for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:03:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FE32dW004461 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Gj-0003gp-7z; Thu, 15 Apr 2004 09:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7D5-0002NV-Da for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23742 for ; Thu, 15 Apr 2004 09:47:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7D3-0003ok-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:47:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7CM-0003jG-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:35 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Ba-0003cB-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:45:46 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDjjI11467 for ; Thu, 15 Apr 2004 15:45:45 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDjic06970 for ; Thu, 15 Apr 2004 15:45:44 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:44:54 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686008@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Thu, 15 Apr 2004 15:45:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Security Threats for NSIS: Unprotected Authorization Information Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, a comment related to the authorization information: > 4.5 Unprotected Authorization Information > > Returning an unprotected authorization token to > the end host might allow an adversary (for example an eavesdropper) > to steal resources. An adversary might also use the token to monitor > communication patterns. Finally, an untrustworthy end host might > also modify the token content. > Doesn't this just mean that the token passing protocol is broken? > (i.e. shouldn't we be able to avoid this happening by using strong > protocols? or are these protocols particularly hard to secure?) it depends what you call broken. it might work in some environments and it depends on some assumptions. people often propose it (and we also included the possibility for it in the qos nslp since it is applicable to the 3gpp). it is necessary to protect the token itself to avoid people to create their own tokens. this, however, does not protect someone stealing your token which flies over the air interface (without additional protection). ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:14:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25892 for ; Thu, 15 Apr 2004 10:14:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7TP-00029B-Dp for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:04:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FE4B9k008242 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:04:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Gk-0003hE-0t; Thu, 15 Apr 2004 09:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7D6-0002Nh-9U for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:47:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23745 for ; Thu, 15 Apr 2004 09:47:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7D4-0003op-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:47:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7CN-0003jS-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:36 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Ba-0003cC-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:45:46 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDjjn18784 for ; Thu, 15 Apr 2004 15:45:45 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDjic06965 for ; Thu, 15 Apr 2004 15:45:44 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:44:54 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686007@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Thu, 15 Apr 2004 15:45:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Security Threats for NSIS : Combining Signaling and SA Establishm ent Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, a comment with regard to section 4.2: > 4. NSIS-Specific Threat Scenarios > 4.2 Combining Signaling and SA Establishment > > When a signaling message arrives at an NSIS-aware network element, ... > protection are described in [AN97] and in [ALN00]. > I found this paragraph quite hard to follow (even though I think > I know what you are trying to say). Part of the problem is that > you are talking about the *threat* of flooding but the section > title is referring to imperfections in a particular class of > solution. > There is room for a more structured analysis of the flooding problem > (especially in the light of concerns about RAO handling expressed on > Monday). Flooding needs a layered defence and protection happens at > several levels. based on the received comment i have changed the original text from: " 4.2 Combining Signaling and SA Establishment This scenario describes attacks that allow an adversary to flood an NSIS node with bogus signaling messages to cause a denial of service attack. When a signaling message arrives at an NSIS-aware network element, certain processing is required. If this message contains security objects such as digital signatures, and no security association is already available, then some additional processing is required for the cryptographic verification. Because NSIS signaling should not require extra roundtrips between two NSIS peers, it is difficult to provide the DoS protection mechanisms commonly found in authentication and key agreement protocols. Signaling messages can be idempotent, which means that they contain the same amount of information as the original message. An example would be a refresh message that is equivalent to a create message. This property allows a refresh message to create new state along a new path, although no previous state is available. For this to work, specific classes of cryptographic mechanisms supporting this behavior are needed. An example is a scheme based on digital signatures, which, however, should be used with care due to possible denial of service attacks. Problems with using these types of exchanges with public key based protection are described in [AN97] and in [ALN00]. In addition to the threat scenario described above, an incoming signaling message might require time consuming processing (computations, state maintenance, timer setting, etc.) and communication with third-party nodes such as policy servers, LDAP servers, etc. If an adversary is able to transmit a large number of signaling messages (for example, with QoS reservation requests) with invalid credentials, then the verifying node may not be able to process other reservation messages from legitimate users. Further attacks may be enabled by injecting error messages or forcing the creation of error messages to extract additional information. " to: " 4.2 Flooding This section describes attacks that allow an adversary to flood an NSIS node with bogus signaling messages to cause a denial of service attack. We will discuss this threat a different layers in the NSIS protocol suite: - Processing of Router Alert Options The processing of Router Alert Option requires a router to do some additional processing by receiving packets with IP options, which might lead to additional delay for legitimate requests, or even to reject of them. A router being flooded with a large number of bogus messages requires resources (e.g., CPU processing due to the context switching) before finding out that these messages have to be dropped. - Force NTLP to-do more processing Some protocol fields might allow an adversary to force an NTLP node to execute more processing. Additionally it might be possible to interfere with the flow control or congestion control procedure. Certain attacks can be mounted against transport layer protocols by flooding a node with bogus requests or even to finish the handshake phase to establish a transport layer association. These types of threats are also addressed in Section 4.11. Furthermore, it might be possible to force the NTLP node to perform some computations or signaling message exchanges by injecting "trigger" events (which are unprotected). - Force NSLP to-do more processing An adversary might benefit from flooding an NSLP node with messages which must be stored (e.g., due to fragmentation handling) before verifying the correctness of signaling messages. Furthermore, causing memory allocation and computational efforts might allow an adversary to do harm to NSIS entities. If a signaling message contains, for example, a digital signature then some additional processing is required for the cryptographic verification. An adversary can easily create a random bit sequence instead of a digital signature to force an NSIS node into heavy computation. Idempotent signaling messages are particularly vulnerable against this type of attack. Idempotent refers to messages which contain the same amount of information as the original message. An example would be a refresh message that is equivalent to a create message. This property allows a refresh message to create new state along a new path, although no previous state is available. For this to work, specific classes of cryptographic mechanisms supporting this behavior are needed. An example is a scheme based on digital signatures, which, however, should be used with care due to possible denial of service attacks. Problems with the usage of public key based cryptosystems in protocols are described in [AN97] and in [ALN00]. In addition to the threat scenario described above, an incoming signaling message might trigger communication with third-party nodes such as policy servers, LDAP servers or AAA servers. If an adversary is able to transmit a large number of signaling messages (for example, with QoS reservation requests) with invalid credentials, then the verifying node may not be able to process other reservation messages from legitimate users. " do you think that this text is more useful now? should i move this section to the denial of service section? ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:15:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25951 for ; Thu, 15 Apr 2004 10:15:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Uw-0002nC-1K for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:05:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FE5kTQ010729 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:05:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Gk-0003i8-KB; Thu, 15 Apr 2004 09:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7D7-0002Nk-Nb for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:47:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23754 for ; Thu, 15 Apr 2004 09:47:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7D5-0003p0-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:47:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7CP-0003jo-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:37 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Bg-0003cI-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:45:52 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i3FDjps08718 for ; Thu, 15 Apr 2004 15:45:51 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDjic06966 for ; Thu, 15 Apr 2004 15:45:44 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:44:54 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686009@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Thu, 15 Apr 2004 15:45:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Security Threats for NSIS : Denial of Service Attacks Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, a question regarding dos attacks: > 4.8 Denial of Service Attacks > > - Path Finding > > This threat scenario includes potential DoS attacks that exist when > the reservation setup is split into two phases, i.e., path and > reservation (as used, for example, in receiver-based reservation > setup). In this case, assuming that the node transmitting the path > message is not charged for the path message itself, it may be able > to generate a large number of reservation requests (possibly in a > Is this really specifically about reservation requests? It sounds > generically like a threat caused by any message which can be sent > without direct cost. (In particular, referring to reservation > requests rather than messsages in general makes it sound like > this is a threat to the resource pool, whereas I think it is a > threat to the control plane.) i should change the description from " - Path Finding This threat scenario includes potential DoS attacks that exist when the reservation setup is split into two phases, i.e., path and reservation (as used, for example, in receiver-based reservation setup). In this case, assuming that the node transmitting the path message is not charged for the path message itself, it may be able to generate a large number of reservation requests (possibly in a distributed fashion). Charging is activated only after successful verification of the reservation request. The reservations are, however, never intended to be successful for various reasons: the destination node cannot be reached; it is not responding; or it simply rejects the reservation. An adversary can succeed because state has already been allocated along the path for various processing tasks including path pinning. " to " Some signaling protocols establish state (e.g., routing state) and perform some actions (e.g., querying resources) at a number of nodes (NSIS forwarders) without requiring authorization (or even proper authentication) based on a single message (e.g., PATH message in RSVP). An adversary can utilize this fact to transmit a large number of signaling messages to allocate state at nodes along the path and to cause resource consumption. An NSIS responder might not be able to determine the NSIS initiator and might even tend to respond to such a signaling message with a corresponding reservation message. " is this text more useful? ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:15:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26015 for ; Thu, 15 Apr 2004 10:15:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Vg-00032L-Do for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:06:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FE6WsC011669 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:06:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Gl-0003jt-Bo; Thu, 15 Apr 2004 09:51:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7D9-0002Nu-44 for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:47:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23763 for ; Thu, 15 Apr 2004 09:47:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7D7-0003pC-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:47:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7CQ-0003k4-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:39 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Bq-0003cO-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:02 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i3FDk1s09036 for ; Thu, 15 Apr 2004 15:46:01 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDjuc07225 for ; Thu, 15 Apr 2004 15:45:56 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:45:05 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468600A@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Thu, 15 Apr 2004 15:45:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Security Threats for NSIS : Attacks against the Transport Mechani sm Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, a comment regarding section 4.11: > 4.11 Attacks against the Transport Mechanism > > I think we can now refer to the split layer architecture as a > decision within the group (after all, it's in the charter) and is > as defined in the framework. > A reference to RFC2385 might be helpful background. regarding the reference RFC2385 ( Protection of BGP Sessions via the TCP MD5 Signature Option). i guess we should not introduce new pointers to certain solutions. rfc2385 is one particular solution approach. regarding the overall comment i have changed the text from: " 4.11 Attacks against the Transport Mechanism In [BL01] a two-level architecture is proposed, which suggests splitting an NSIS protocol into layers: a signaling message transport-specific layer and an application-specific layer. This architectural assumption is also considered within the NSIS framework [HF+03]. Most of the threats described in this document are applicable to the application-specific part (i.e., signaling QoS or middlebox-specific information). There are, however, some threats that are applicable to the transport of signaling messages. Network or transport layer protocols lacking protection mechanisms are vulnerable to certain attacks such as header manipulation, DoS, spoofing of identities, session hijacking, unexpected aborts, etc. Malicious nodes can attack the congestion control mechanism to force NSIS nodes into a congestion avoidance state. In the case in which existing protocols are used for exchanging NSIS signaling messages, known threats scenarios applicable to these protocols are relevant. " to " 4.11 Attacks against the NTLP In [BL01] a two-level architecture is proposed, which suggests splitting an NSIS protocol into layers: a signaling message transport-specific layer and an application-specific layer. More details can be found in the NSIS framework [HF+03]. Most of the threats described in this document are applicable to the NSLP application-specific part (e.g., QoS NSLP). There are, however, some threats that are applicable to the NTLP. Network and transport layer protocols lacking protection mechanisms are vulnerable to certain attacks such as header manipulation, DoS, spoofing of identities, session hijacking, unexpected aborts, etc. Malicious nodes can attack the congestion control mechanism to force NSIS nodes into a congestion avoidance state. Threats which address parts of the NTLP which are not related to attacks against the usage transport layer protocols are covered in various sections throughout this document, such as in Section 4.2. In the case in which existing transport layer protocols are used for exchanging NSIS signaling messages, security vulnerabilities know to these protocols need to be considered. A detailed threat description of these protocols is outside the scope of this document. " do you think that this is more appropriate? ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:15:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26087 for ; Thu, 15 Apr 2004 10:15:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7X7-0004DS-Nj for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:08:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FE81S0016187 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7LV-0004xw-As; Thu, 15 Apr 2004 09:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Dq-0002cd-S4 for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:48:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23787 for ; Thu, 15 Apr 2004 09:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Do-0003sY-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:48:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7Cu-0003nO-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:47:08 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BE7By-0003fl-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:10 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDk9I12019 for ; Thu, 15 Apr 2004 15:46:09 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDk4c07447 for ; Thu, 15 Apr 2004 15:46:04 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:45:13 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468600B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Thu, 15 Apr 2004 15:45:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Security Threats for NSIS : Man-in-the-Middle Attacks Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, comments regarding Man-in-the-Middle attacks: > 3.1 Man-in-the-Middle Attacks > > Note also that a > denial of service attack on a signaling protocol exists when no > separation between SA establishment and signaling protection takes > place. > I don't know whether this is just saying that SA establishment needs > DoS protection (true), or a more subtle point about DoS protection > being harder without the separation because the first stage is more > expensive (as you say later). In either case, the text doesn't seem > to be needed here. > The discovery procedure, in particular, is vulnerable to a > number of such attacks. > You haven't defined what a discovery procedure is. And even if the > protocols do have discovery procedures (which is not fixed, at least > at this threats stage of the lifecycle), the vulnerability is more > fundamental in the functionality. since the sentence with "Note also ..." seems to useless i suggest to simply delete it. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:17:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26241 for ; Thu, 15 Apr 2004 10:17:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7XS-0004gO-Vb for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:08:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FE8Mud017984 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:08:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7LW-0004yW-1L; Thu, 15 Apr 2004 09:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Dt-0002dF-N9 for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23790 for ; Thu, 15 Apr 2004 09:48:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Dr-0003sx-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:48:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7Cx-0003nv-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:47:12 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BE7C3-0003gV-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:15 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDkEn19371 for ; Thu, 15 Apr 2004 15:46:14 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDkEc07684 for ; Thu, 15 Apr 2004 15:46:14 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:45:23 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468600C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: nsis@ietf.org Date: Thu, 15 Apr 2004 15:45:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Security Threats for NSIS : Identity Spoofing Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, a question regarding identity spoofing: > 4.4 Identity Spoofing > > The ability for an adversary to inject data traffic that matches a > certain flow identifier established by a legitimate user often > requires the ability also to receive the data traffic. This is, > however, true only if the flow identifier consists of values that > contain addresses used for routing. If we imagine using attributes > of a flow identifier that do not require such a property, then > identity spoofing and injecting traffic are much easier. An > adversary can use a nearly arbitrary endpoint identifier to achieve > the desired result. Obviously, though, the endpoint identifiers are > not irrelevant, because the messages have to travel the same path > through the network. > This implication of this is that flow identifiers should be hard to > spoof usefully (e.g. they should contain destination addresses). > This would be an important point to capture and propagate through into > the signalling protocol security analysis. you are right. the flow id should certainly contain a destination address (particulary a destination address is need to have something like path-coupled signaling). i guess we can state that the source address is not necessarily verified. a response message is only routed backwards (along the nodes where state was established) but there is no check for the source address (something like a return-routability) in an end-to-end fashion. hence, it might be possible that an entity includes a spoofed source address. based on robert's and cornelia's comments i have tried to rewrite the section: Changed from : " 4.4 Identity Spoofing Identity spoofing relevant for NSIS occurs in two forms: first, identity spoofing can happen during the establishment of a security association based on a weak authentication mechanismn and, second, it can consist of spoofing data traffic. In the first case, Eve, acting as an adversary, may claim to be the registered user Alice by spoofing Alice's identity. Eve thereby causes the network to charge Alice for the network resources consumed. This type of attack is possible if authentication is based on a simple username identifier (i.e., in absence of cryptographic authentication), or if authentication is provided for hosts, and multiple users have access to a single host. This attack could also be classified as theft of service. In the second case, an adversary may be able to exploit the established flow identifiers (required for QoS and middlebox communication [Midcom] specific signaling protocols). Some identifiers, among others, IP addresses, transport protocol identifiers, port numbers, and flow labels (see [RFC1809] and [RC+03]), are transported in these protocols. Modification of these flow identifiers allows adversaries to exploit or to render ineffective quality of service reservations or policy rules at middleboxes. An adversary could mount an attack by modifying the flow identifier of a signaling message. NSIS signaling messages contain some sort of flow identifier, which is associated with a specified behavior (e.g., a particular flow experiences QoS treatment or allows packets to traverse a firewall). An adversary might, therefore, use IP spoofing and inject data packets to benefit from previously installed flow identifiers. The following threat is carried out by spoofing the identity of transmitted data traffic. The spoofed identity is the IP source address. For this attack to be successful, accounting records are collected based on the IP source address and not on a SPI due to IPsec protection. After the network receives a properly protected reservation request, transmitted by the legitimate user Alice, Traffic Selectors are installed at the corresponding devices (for example, the edge router). These Traffic Selectors are used for flow identification and allow data traffic originated from a given source address to be matched and assigned to a particular QoS reservation. The adversary Eve now spoofs the IP address of the Alice. In addition, Alice's host may be crashed by the adversary with a denial of service attack or may lose connectivity, for example, because of mobility considerations. If both nodes are located at the same link and use the same IP address, then obviously a duplicate IP address will be detected. Assuming that only Eve is now present at the link, she is able to receive and transmit data (for example RTP data traffic) that receives preferential QoS treatment based on the previous reservation. Depending on the installed Traffic Selector granularity, Eve might have more possibilities to exploit the QoS reservation or a pin-holed firewall. Assuming the soft state paradigm, whereby periodic refresh messages are required, the absence of Alice will not be detected until the next signaling message appears and forces Eve to respond with a protected signaling message. Again, this attack is applicable not just to QoS traffic, but the existence of a QoS reservation increases its impact, because this type of traffic is more expensive. The same attack is also applicable to a Middlebox protocol. The ability for an adversary to inject data traffic that matches a certain flow identifier established by a legitimate user often requires the ability also to receive the data traffic. This is, however, true only if the flow identifier consists of values that contain addresses used for routing. If we imagine using attributes of a flow identifier that do not require such a property, then identity spoofing and injecting traffic are much easier. An adversary can use a nearly arbitrary endpoint identifier to achieve the desired result. Obviously, though, the endpoint identifiers are not irrelevant, because the messages have to travel the same path through the network. Data traffic marking based on DiffServ is such an example. Whenever an ingress router uses only marked incoming data traffic for admission control procedures, then various attacks are possible. These problems have been known in the DiffServ community for a long time and have been documented in various DiffServ-related documents. The IPsec protection of DiffServ Code Points is described in Section 6.2 of [RFC2745]. Related security issues (for example denial of service attacks) are described in Section 6.1 of the same document. " to " 4.4 Identity Spoofing Identity spoofing relevant for NSIS occurs in three forms: first, identity spoofing can happen during the establishment of a security association based on a weak authentication mechanism. Second, an adversary can modify the flow identifier carried within a signaling message and third, it can spoof data traffic. In the first case, Eve, acting as an adversary, may claim to be the registered user Alice by spoofing Alice's identity. Eve thereby causes the network to charge Alice for the network resources consumed. This type of attack is possible if authentication is based on a simple username identifier (i.e., in absence of cryptographic authentication), or if authentication is provided for hosts, and multiple users have access to a single host. This attack could also be classified as theft of service. In the second case, an adversary may be able to exploit the established flow identifiers (required for QoS and NAT/FW NSLP). These identifiers are, among others, IP addresses, transport protocol type (UDP, TCP), port numbers, and flow labels (see [RFC1809] and [RC+03]). Modification of these flow identifiers allows adversaries to exploit or to render ineffective quality of service reservations or policy rules at middleboxes. An adversary could mount an attack by modifying the flow identifier of a signaling message. In the third case, an adversary may spoof data traffic. NSIS signaling messages contain some sort of flow identifier, which is associated with a specified behavior (e.g., a particular flow experiences QoS treatment or allows packets to traverse a firewall). An adversary might, therefore, use IP spoofing and inject data packets to benefit from previously installed flow identifiers. We will provide an example of the latter threat. After NSIS nodes along the path between the NSIS initiator and the NSIS receiver processes a properly protected reservation request, transmitted by the legitimate user Alice, a QoS reservation is installed at the corresponding NSIS nodes (for example, the edge router). The flow identifier is used for flow identification and allows data traffic originated from a given source to be assigned to this QoS reservation. The adversary Eve now spoofs the IP address of the Alice. In addition, Alice's host may be crashed by the adversary with a denial of service attack or may lose connectivity, for example, because of mobility considerations. If Eve is able to perform address spoofing then she is able to receive and transmit data (for example RTP data traffic) that receives preferential QoS treatment based on the previous reservation. Depending on the installed flow identifier granularity, Eve might have more possibilities to exploit the QoS reservation or a pin-holed firewall. Assuming the soft state paradigm, whereby periodic refresh messages are required, the absence of Alice will not be detected until a refresh message is required and forces Eve to respond with a protected signaling message. Again, this attack is applicable not just to QoS traffic and the same attack is also applicable to a Firewall control protocol, with a different consequence. The ability for an adversary to inject data traffic that matches a certain flow identifier established by a legitimate user and to get some benefit from injecting that traffic often requires the ability also to receive the data traffic or to have one's correspondent receive it. For example, an adversary in an ad hoc network observes a NAT/Firewall signaling message towards a corporate network. After the signaling message exchange was successful user Alice is allowed to traverse the company firewall based on the establish packet filter to contact her internal mail server. Now, adversary Eve, which was monitoring the signaling exchange is able to build a data packet towards this mail server which will pass the company firewall. The packet will hit the mail server and cause some actions and the mail server will reply with some response messages. Depending on the exact location of the adversary and the degree of routing asymmetry the adversary might even see the response messages. Note that for this attack to work Alice does not need to participate in the exchange of signaling messages. If we imagine using attributes of a flow identifier that is not related to source and destination addresses. As an example, we could think of a flow identifier where only the 21-bit Flow ID is used (without source and destination IP address). Identity spoofing and injecting traffic is much easier since a packet only needs to be marked and an adversary can use a nearly arbitrary endpoint identifier to achieve the desired result. Obviously, though, the endpoint identifiers are not irrelevant, because the messages have to hit some nodes in the network where NSIS signaling messages installed state (e.g., in the above example they would have to hit the same firewall.) Data traffic marking based on DiffServ is such an example. Whenever an ingress router uses only marked incoming data traffic for admission control procedures, then various attacks are possible. These problems have been known in the DiffServ community for a long time and have been documented in various DiffServ-related documents. The IPsec protection of DiffServ Code Points is described in Section 6.2 of [RFC2745]. Related security issues (for example denial of service attacks) are described in Section 6.1 of the same document. " ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:17:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26318 for ; Thu, 15 Apr 2004 10:17:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Zc-0005pv-Nv for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:10:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEAaro022428 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:10:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7LW-0004ye-Fw; Thu, 15 Apr 2004 09:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Dy-0002gI-Ap for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:48:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23794 for ; Thu, 15 Apr 2004 09:48:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Dw-0003tY-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:48:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7D0-0003oR-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:47:15 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BE7CF-0003i8-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:27 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDkQn19555 for ; Thu, 15 Apr 2004 15:46:26 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDkQc07908 for ; Thu, 15 Apr 2004 15:46:26 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:45:35 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468600D@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Thu, 15 Apr 2004 15:45:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Security Threats for NSIS : Relevant Communications Models Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 got a number of comments with regard to section 2 (Relevant Communications Models). fixing this section is a bit more complex than specific security threats: i went through some ietf drafts which consider security threats, trust models and related issues. after this list you will find my conclusion. here is a brief overview: ------------ IPv6 Neighbor Discovery trust models and threats draft-ietf-send-psreq-04 - an informal definition of trust is given - three threat model are presented. ------------ Security Considerations for 6to4 draft-ietf-v6ops-6to4-security-01.txt - no trust model provided. - detailed threat descriptions provided ------------ Threats Introduced by Rserpool and Requirements for Security in response to Threats - no trust model provided. - each section is divided into Threat, Effect and Requirement ------------ Generic Threats to Routing Protocols draft-ietf-rpsec-routing-threats-04 - no trust model provided. - threat definition and different threat sources provided. ------------ DDP/RDMAP Security draft-ietf-rddp-security-01.txt - definition of Partial Trust Taxonomy given. - Attacks and Countermeasures provided. - resources and architecture defined ------------ PANA Threat Analysis and Security Requirements draft-ietf-pana-threats-eval-04.txt - trust relationships described but term trust not defined. - security requirements are attached to each threat ------------ Security Threats and Risks for OPES draft-ietf-opes-threats-03 - discusses threats - no trust, no requirements and no countermeasures. ------------ Mobility Support in IPv6 draft-ietf-mobileip-ipv6-24.txt - attached to the main protocol as part of the security consideration section - discusses threats and their countermeasures - very specific and was (as we all know) provided after the protocol was nearly finished. ------------ Security Framework for Provider Provisioned Virtual Private Networks draft-ietf-l3vpn-security-framework-00.txt - a trust model is not mentioned although a Security Reference Model is provided - discusses threats and Countermeasures - detailed security requirements (for user and for provider) ------------ Securing Block Storage Protocols over IP draft-ietf-ips-security-19.txt - describes security requirements and security protection in detail - security threats are briefly mentioned as part of the security requirements ------------ Threat Analysis of the Domain Name System draft-ietf-dnsext-dns-threats-06.txt - lists known threats against the dns directory. - threats are detailed since they are described on a known protocol ------------ Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis draft-ietf-dhc-v4-threat-analysis-00 - threats are detailed since they are described on a known protocol - security Requirements are discussed. ------------ Security Threat for Content Internetworking draft-ietf-cdi-threat-00.txt - trust model included - threats distinguish between insider and outsider threats ------------ here is my conclusion from browsing through various security drafts: - only a few drafts describe a trust model - the term trust is almost never defined; if it is defined then there is a rather informal non-technical definition of it. - i could not find a place which made a difference between threats and attacks - some drafts are very specific about their threats (since they point to existing protocols; which are already in use for a long time) what can we learn for our work: - we started with our security efforts very early. this has some benefits but also some drawbacks: advantage: we start with security discussions quite early and considered various issues quite early disadvantage: since the focus of our work shifted a bit over the last few years it was difficult to keep the work synchronized. the security threats work is always something behind. we could possibly keep it ongoing until the last protocol is finished - the threats document address the nsis protocol suite. it is generic and cannot cover current activities in the qos nslp, nat/fw nslp and also in the ntlp. these document must provide some additional information about their threats and particuarly about the countermeasures. regarding some issues of these protocols the work is not finished (and hence it would be difficult to have all these issues covered in the threats document already). - it is hard to discuss trust models since they are highly application specific. therefore, they are included in the nat/fw nslp and in the qos nslp. the work there is still ongoing since they are not trivial. the ntlp does not make sense without the nslps (at least from the current gimps draft). hence it is useful to consider the relationship between the ntlp and the nslps together with respect to their trust model and their security properties. i know that the definition of trust raises long philosophical discussions. i have attended several projects which came across this issue. typically the outcome of these discussions is rather disappointing. hence, i would suggest that we do not work on our flavor of trust definition. - we decided not to include * security requirements (since they can be found in the security requirements document) * solution specific aspects (such as countermeasures) in the threats document the main intention with section 2 was to provide an overview of the security work in nsis, to provide some convient names for some communication pattern which are typical (intra-domain, inter-domain, etc.) and to provide the possible trust relationships in a high-level fashion (end-to-middle, middle-to-middle, etc.). it seems that people did not like this approach with regard to section 2. are there some proposals what we could do? i think we should do the following: - we should polish the individual threats (see other mails) - we should not include security requirements - we should not include solutions aspects - we should clearly point the main intention of the document and that additional information is found in the related documents - we should do something with section 2 (i hope to receive some comments) ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 10:17:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26364 for ; Thu, 15 Apr 2004 10:17:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7c9-0007NU-AC for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:13:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEDDaH028353 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 10:13:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7LW-0004ym-TD; Thu, 15 Apr 2004 09:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Dz-0002gM-Ve for nsis@optimus.ietf.org; Thu, 15 Apr 2004 09:48:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23797 for ; Thu, 15 Apr 2004 09:48:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Dy-0003tn-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:48:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7D7-0003pH-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:47:22 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Cd-0003kH-00 for nsis@ietf.org; Thu, 15 Apr 2004 09:46:51 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDkmI12797 for ; Thu, 15 Apr 2004 15:46:49 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3FDkjc08267 for ; Thu, 15 Apr 2004 15:46:45 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Apr 2004 15:45:55 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468600E@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Kappler Cornelia'" , nsis@ietf.org Date: Thu, 15 Apr 2004 15:46:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] RE: comments on NSIS Security Threats ID Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 cornelia, please see some comments inline: > -----Original Message----- > From: Kappler Cornelia [mailto:cornelia.kappler@siemens.com] > Sent: Friday, March 12, 2004 8:35 PM > To: Tschofenig Hannes; nsis@ietf.org > Subject: comments on NSIS Security Threats ID > > Hi Hannes, > > my comments mostly relate to the structure of Sec 4 (along similar lines as Robert was suggesting), and to problems I have understanding identity spoofing of flow identifieres. See below. > > Cornelia > ---------------------- > > *4. NSIS Specific Threat Scenarios > > This Section describes "threat scenarios in terms of attacks on and security deficiencies in the NSIS signaling protocol". I find it hard sometimes in subsequent subsections to pick out what the attack is, and (particularly) what the security deficiencies allowing the attack are. May be you could add sentences clearly stating this, rather than mentioning it in passing. i went through other ietf drafts on security and noticed that these terms (threats and attacks) are used interchangeable in many cases. i will, however, try to find a definition somewhere and see how that would be helpful for the draft. > > In addition to Theats and Security Deficiencies may be you should add (in a structured fashion) what possible remedies are. In most subsections this is mentioned but not everywhere. Also I think the fact that you also discuss remedies should be mentioned in the intro to Sec 4. i actually tried hard to remove all solution specific aspects (or counter-measures). it was a request to remove them. > > Subsection headings sometimes contain possible security deficiencies ("Combined Signaling and SA Establishment") and sometimes threats ("Eavesdropping and Traffic Analysis"). Could you streamline this (i.e. either one or the other) i will go through the titels again and try to align them. > > * 4.2 "Combined Signaling and SA Establishment" > > It took me some time to understand the problem. To my current understanding it is the assumption that one doesnt want to introduce extra roundtrip times to establish SAs. I.e. somehow the SA needs to be established as soon as an NSIS message arrives from an unknown NE, without further interaction wiht this NE. But is this assumption valid? Do we expect the number of possible peer-NEs is so large that the costs for an additional roundtrip to establish the SA is too big? > > I dont understand the sentence "For this to work, specific classes of cryptographic mechanisms supporting this type of behaviour are needed". What is "this to work"? Do you mean (previous sentence) "allow refresh messages to create new state along a new path" to work _in a secure way_? Furthermore what specifically is "this type of behaviour"? In the text above no "behaviour" was described. i have tried to fix this section. you can find a change-proposal in a separate mail. > > * 4.3 "Eavesdropping and Traffic Analysis" > > I cant find what the security deficiencies are that allow this kind of threat. It only says integrity protection does NOT help against it. But why would anybody think it does??? Adding a kind of secured checksum (that is what integrity protection does, doesnt it?) of course doesnt help. the ability to eavesdrop signaling traffic (for various reasons) is a threat. whether people would like to address it is another story. might might remember steve bellovin speaking about confidentiality protection. he argued that it is required. it is true that the paragraph: " Note that this threat scenario is not mitigated by applying integrity protection to the messages, which is often considered sufficient for signaling protocols. " might be somewhat trivial. i will remove it. > > The 3rd paragraph introduces exploitation of the spoofing of flow identifiers. The remaining paragraphs of 4.3 all seem to discuss this problem in more detail. It took me some time to realize this, may be you could add an explaining sentence. i guess that the subsequent issues refer to the section 4.4 (identity spoofing): > > 2nd last paragraph of 4.3: "The ability...to inject data atraffic..requires the ability to also receive the data traffic. This is, however, true only if the flow identifier consists of a value that contains addresses used for routing." Doesnt seem to make sense. I can picture various scenarios where I am able to receive data traffic not really destined to me, independent of the structure of the flow identifier...!? > > The same paragraph continues: "If ... using...a flow identifier that do not require such a property (CK: i.e. addresses used for routing I assume?? Or ability to receive data traffic? But this I think is independent of the structure of the flow identifier) then ...injecting traffic are much easier." Doesnt make sense to me either (I may just have problems catching on...) > > The final paragraph contains the DiffServ example but I dont see how it relates to the rest. Where is the spoofed flow identifier in the example? May be you could be more explicit...> > robert also gave comments to this issue. you can find a first attempt of a text proposal in a separate mail. > * 4.6 Missing Non-Repudiation > last paragraph "because it public-key" -> "because public-key" > fixed. > * 4.8 Denial of Service Attacks > In the "path-finding" scenario, what is a possible remedy? two possible strategries: - life with it. - avoid it by authenticating and authorizing nodes, sender-initiated reservations, do not allocate state, .... that's subject for a discussion in nslp drafts. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 11:36:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01035 for ; Thu, 15 Apr 2004 11:36:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8oL-0003Qe-Ab for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 11:29:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FFTrBl013174 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 11:29:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8if-0001cL-9b; Thu, 15 Apr 2004 11:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8bF-0007aM-QC for nsis@optimus.ietf.org; Thu, 15 Apr 2004 11:16:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29886 for ; Thu, 15 Apr 2004 11:16:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8bE-0004px-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:16:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8aS-0004jl-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:15:32 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BE8Zg-0004Uo-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:14:44 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <20CQRBB7>; Thu, 15 Apr 2004 16:14:04 +0100 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Security Threats for NSIS : Insecure Parameter Exchang e and Negot iation Date: Thu, 15 Apr 2004 16:14:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ok, i think we agree: the rule "if you want to negotiate security, don't allow include any mechanism which can be attacked in real time as an option (regardless of who you think you are negotiating with)" is an example of what i would call a static policy. then I think there are two questions: 1. i think the sentence "Hence, without binding the negotiation process to the legitimate parties and protecting it, an NSIS protocol might be only as secure as the weakest mechanism provided (e.g., weak authentication), and the benefits of defining configuration parameters and a negotiation protocol are lost." is possibly misleading. isn't it the point that the "NSIS protocol" *is always* "only as secure as the weakest mechanism provided", regardless of how the negotiation is wrapped up. 2. although the document is (I think rightly) steering clear of suggesting what the solutions to address the threat should be, i think a reference to something like sipsec-agree is still helpful, because it explains a concrete example of the threat in much more detail (as well as providing a solution). One could add something like "For example, this threat arises in the negotiation of security mechanisms for SIP; a discussion of the threat and a solution are provided in [3329]." r. > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, April 15, 2004 14:45 > To: 'nsis@ietf.org' > Subject: [NSIS] Security Threats for NSIS : Insecure > Parameter Exchange > and Negot iation > > > hi all, > > > 3.4 Insecure Parameter Exchange and Negotiation > > > I think this threat is very important to consider. But is there > > any way to handle it except in the context of a security protocol > > (unless you rely on static policies)? You can always mount a > > downgrading attack on the authentication process itself, at > > which point you are finished. > > yes. typically one has to repeat the parameters again after a security > association has been established. > if the weakest mechanism is resistant against a real-time > attack (i.e., a > cryptomechanism which can be broken in realtime before the > negotiation is > completed) then the modification will be discovered. > > you can find an example of this in: > http://www.ietf.org/rfc/rfc3329.txt > > ciao > hannes > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 12:08:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02159 for ; Thu, 15 Apr 2004 12:08:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9EZ-0002lk-Ty for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 11:56:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FFuxJG010639 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 11:56:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE95t-0000Sw-JU; Thu, 15 Apr 2004 11:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8tX-0004mX-Pd for nsis@optimus.ietf.org; Thu, 15 Apr 2004 11:35:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00974 for ; Thu, 15 Apr 2004 11:35:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8tW-0006tl-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:35:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8sr-0006pG-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:34:34 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BE8s9-0006fj-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:33:49 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <20CQRB2C>; Thu, 15 Apr 2004 16:33:17 +0100 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Security Threats for NSIS : Combining Signaling and SA Establishm ent Date: Thu, 15 Apr 2004 16:33:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , i think the new text is much better. teeny comments: the paragraph at the start: > - Processing of Router Alert Options > > The processing of Router Alert Option requires a router to do some > additional processing by receiving packets with IP options, > which might lead > to additional delay for legitimate requests, or even to > reject of them. A ^ [nit] insert "some"? > router being flooded with a large number of bogus messages requires > resources (e.g., CPU processing due to the context switching) i would remove the () part > before finding > out that these messages have to be dropped. and then add something like "If the protocol is based on using interception for message delivery this threat cannot be completely eliminated, but the protocol design should attempt to limit the processing that has to be done on the RAO-bearing packet so it is at most comparable to that for an arbitrary packet addressed directly to one of the router interfaces." (or something.) [The point I think was not so much that the interception, whether done by RAO insertion or any other method like protocol filtering, was expensive, but more that it provided a mechanism to allow arbitrary people to get the router to process the rest of the message as well. At least, that is the impression I got from the discussion during the meeting. To some extent this is also covered in your NTLP paragraph, the specific point here is the "require routers to process intercepted messages" aspect.] i would keep this separate from the DoS section (both are long enough). r. > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, April 15, 2004 14:45 > To: 'nsis@ietf.org' > Subject: [NSIS] Security Threats for NSIS : Combining Signaling and SA > Establishm ent > > > hi all, > > a comment with regard to section 4.2: > > > 4. NSIS-Specific Threat Scenarios > > > 4.2 Combining Signaling and SA Establishment > > > > When a signaling message arrives at an NSIS-aware > network element, > ... > > protection are described in [AN97] and in [ALN00]. > > > I found this paragraph quite hard to follow (even though I think > > I know what you are trying to say). Part of the problem is that > > you are talking about the *threat* of flooding but the section > > title is referring to imperfections in a particular class of > > solution. > > > There is room for a more structured analysis of the flooding problem > > (especially in the light of concerns about RAO handling expressed on > > Monday). Flooding needs a layered defence and protection happens at > > several levels. > > > based on the received comment i have changed the original text from: > > " > 4.2 Combining Signaling and SA Establishment > > This scenario describes attacks that allow an adversary to > flood an > NSIS node with bogus signaling messages to cause a denial > of service > attack. > > When a signaling message arrives at an NSIS-aware network element, > certain processing is required. If this message contains security > objects such as digital signatures, and no security association is > already available, then some additional processing is required for > the cryptographic verification. Because NSIS signaling should not > require extra roundtrips between two NSIS peers, it is > difficult to > provide the DoS protection mechanisms commonly found in > authentication and key agreement protocols. Signaling messages can > be idempotent, which means that they contain the same amount of > information as the original message. An example would be a refresh > message that is equivalent to a create message. This > property allows > a refresh message to create new state along a new path, > although no > previous state is available. For this to work, specific classes of > cryptographic mechanisms supporting this behavior are needed. An > example is a scheme based on digital signatures, which, however, > should be used with care due to possible denial of service > attacks. > Problems with using these types of exchanges with public key based > protection are described in [AN97] and in [ALN00]. > > In addition to the threat scenario described above, an incoming > signaling message might require time consuming processing > (computations, state maintenance, timer setting, etc.) and > communication with third-party nodes such as policy servers, LDAP > servers, etc. If an adversary is able to transmit a large > number of > signaling messages (for example, with QoS reservation > requests) with > invalid credentials, then the verifying node may not be able to > process other reservation messages from legitimate users. > > Further attacks may be enabled by injecting error messages or > forcing the creation of error messages to extract additional > information. > > > " > > to: > > " > 4.2 Flooding > > This section describes attacks that allow an adversary to > flood an NSIS node > with bogus signaling messages to cause a denial of service attack. > > We will discuss this threat a different layers in the NSIS > protocol suite: > > - Processing of Router Alert Options > > The processing of Router Alert Option requires a router to do some > additional processing by receiving packets with IP options, > which might lead > to additional delay for legitimate requests, or even to > reject of them. A > router being flooded with a large number of bogus messages requires > resources (e.g., CPU processing due to the context switching) > before finding > out that these messages have to be dropped. > > - Force NTLP to-do more processing > > Some protocol fields might allow an adversary to force an NTLP node to > execute more processing. Additionally it might be possible to > interfere with > the flow control or congestion control procedure. > > Certain attacks can be mounted against transport layer > protocols by flooding > a node with bogus requests or even to finish the handshake phase to > establish a transport layer association. These types of > threats are also > addressed in Section 4.11. > > Furthermore, it might be possible to force the NTLP node to > perform some > computations or signaling message exchanges by injecting > "trigger" events > (which are unprotected). > > - Force NSLP to-do more processing > > An adversary might benefit from flooding an NSLP node with > messages which > must be stored (e.g., due to fragmentation handling) before > verifying the > correctness of signaling messages. > > Furthermore, causing memory allocation and computational > efforts might allow > an adversary to do harm to NSIS entities. If a signaling > message contains, > for example, a digital signature then some additional > processing is required > for the cryptographic verification. An adversary can easily > create a random > bit sequence instead of a digital signature to force an NSIS > node into heavy > computation. > > Idempotent signaling messages are particularly vulnerable > against this type > of attack. Idempotent refers to messages which contain the > same amount of > information as the original message. An example would be a > refresh message > that is equivalent to a create message. This property allows a refresh > message to create new state along a new path, although no > previous state is > available. For this to work, specific classes of > cryptographic mechanisms > supporting this behavior are needed. An example is a scheme > based on digital > signatures, which, however, should be used with care due to > possible denial > of service attacks. > > Problems with the usage of public key based cryptosystems in > protocols are > described in [AN97] and in [ALN00]. > > In addition to the threat scenario described above, an > incoming signaling > message might trigger communication with third-party nodes > such as policy > servers, LDAP servers or AAA servers. If an adversary is able > to transmit a > large number of signaling messages (for example, with QoS reservation > requests) with invalid credentials, then the verifying node > may not be able > to process other reservation messages from legitimate users. > > " > > > do you think that this text is more useful now? > should i move this section to the denial of service section? > > > ciao > hannes > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 12:10:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02218 for ; Thu, 15 Apr 2004 12:10:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9Hb-0003hm-1S for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 12:00:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FG07aE014235 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 12:00:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE96t-000152-Id; Thu, 15 Apr 2004 11:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8zH-0006f7-4I for nsis@optimus.ietf.org; Thu, 15 Apr 2004 11:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01184 for ; Thu, 15 Apr 2004 11:41:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8zG-0007Ou-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:41:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8yP-0007LA-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:40:18 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BE8xd-0007Bn-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:39:29 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <20CQRBJ5>; Thu, 15 Apr 2004 16:38:58 +0100 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Security Threats for NSIS : Attacks against the Transp ort Mechani sm Date: Thu, 15 Apr 2004 16:38:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 like the new text. some minor points in line: > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, April 15, 2004 14:45 > To: 'nsis@ietf.org' > Subject: [NSIS] Security Threats for NSIS : Attacks against the > Transport Mechani sm > > > hi all, > > a comment regarding section 4.11: > > > 4.11 Attacks against the Transport Mechanism > > > > I think we can now refer to the split layer architecture as a > > decision within the group (after all, it's in the charter) and is > > as defined in the framework. > > > A reference to RFC2385 might be helpful background. > > regarding the reference RFC2385 ( Protection of BGP Sessions > via the TCP MD5 > Signature Option). i guess we should not introduce new > pointers to certain > solutions. rfc2385 is one particular solution approach. again, i think it is interesting because of the threat description that it contains (rather than the particular solution it describes). > > regarding the overall comment i have changed the text from: [snip] > to > > " > > 4.11 Attacks against the NTLP > > In [BL01] a two-level architecture is proposed, which > suggests splitting an > NSIS protocol into layers: a signaling message > transport-specific layer and > an application-specific layer. More details can be found in the NSIS > framework [HF+03]. Most of the threats described in this document are > applicable to the NSLP application-specific part (e.g., QoS > NSLP). There > are, however, some threats that are applicable to the NTLP. > > Network and transport layer protocols lacking protection > mechanisms are > vulnerable to certain attacks such as header manipulation, > DoS, spoofing of > identities, session hijacking, unexpected aborts, etc. > Malicious nodes can > attack the congestion control mechanism to force NSIS nodes into a > congestion avoidance state. > > Threats which address parts of the NTLP which are not related > to attacks > against the usage transport layer protocols are covered in ^^^^^ use of (?) > various sections > throughout this document, such as in Section 4.2. > > In the case in which existing transport layer protocols are used for > exchanging NSIS signaling messages, security vulnerabilities > know to these ^^^^^^^ known for? > protocols need to be considered. A detailed threat > description of these > protocols is outside the scope of this document. > " > > do you think that this is more appropriate? > > > ciao > hannes > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 12:27:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02760 for ; Thu, 15 Apr 2004 12:27:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9LC-0004CV-L5 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 12:03:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FG3oq1016142 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 12:03:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE96v-000176-3O; Thu, 15 Apr 2004 11:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE90F-000798-9J for nsis@optimus.ietf.org; Thu, 15 Apr 2004 11:42:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01220 for ; Thu, 15 Apr 2004 11:42:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE90E-0007TJ-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:42:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8zJ-0007PR-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:41:14 -0400 Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BE8yY-0007HD-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:40:26 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3FFY1oS031214 for ; Thu, 15 Apr 2004 10:39:54 -0500 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 40703259001DED79; Thu, 15 Apr 2004 11:35:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Questions regarding Date: Thu, 15 Apr 2004 11:39:54 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A06CAEED0@ACCLUST02EVS1.ugd.att.com> Thread-Topic: RE: [NSIS] Questions regarding Thread-Index: AcQi/+NCWKp9TKDzSYWd28Vn8fo1Og== From: "Roy, Radhika R, ALABS" To: "James M. Polk" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, all: I do not think that things will be just like what has been stated below. = Here are the points: 1. In SIP INVITE message, SDP describes what codecs are. For example, it = may be G.711 codec. Per specifications of G.711 codec, there is a = standard what are the performance characteristics of G.711 in terms of = end-to-end delay between the codec, bandwidth, delay jitter and losses. 2. Like all other functional requirements, a SIP UA also expects that = the commitment of the above performance requirements must be met. 3. If the quality between the codecs is not delivered, there is a breach = of "contract" so far acceptance of the call is concerned. So, before acceptance of the call the following needs to happen: a. The SIP Layer entities (e.g., proxies) need to make sure that there = are sufficient resources (e.g., CPU capacity, ports) in the end-to-end = path. b. The IP network layer needs to make sure that ingress access network, = backbone network, and egress access network all together in the = end-to-end path has the resources to meet the performance requirements = (end-to-end delay/bandwidth/jitter/losses). c. It is important to note that item c does not have the end-to-end = knowledge of delay/jitter/losses. That is, an entity that has the = knowledge of end-to-end SIP/application layer performance requirements = will divide the QoS requirements into three areas (access network, = backbone network, and egress network) so that end-to-end performance = requirements at the SIP layer is met. The above description clearly shows where and how the NSIS protocol = needs to play the role acting bridging the gap between the SIP = application layer and the IP network layer. Best regards, Radhika R. Roy AT&T SoIP Network Architect 732 420 1580 > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Tuesday, April 13, 2004 10:57 PM >SIP, if it is the only means of call establishment and control, will = set up the call, thereby reducing the quality of all 4 calls traversing = that >circuit. The users won't know what happened, just that voice reception = quality just tanked.=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 12:30:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03063 for ; Thu, 15 Apr 2004 12:30:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9i8-0004ZN-0W for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 12:27:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FGRV79017549 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 12:27:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9NK-0004v8-01; Thu, 15 Apr 2004 12:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE984-0001ad-BC for nsis@optimus.ietf.org; Thu, 15 Apr 2004 11:50:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01450 for ; Thu, 15 Apr 2004 11:50:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE983-0000Nk-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:50:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE97C-0000Jh-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:49:23 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BE96S-00009i-00 for nsis@ietf.org; Thu, 15 Apr 2004 11:48:36 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <20CRLJRD>; Thu, 15 Apr 2004 16:48:04 +0100 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Security Threats for NSIS : Relevant Communications Mo dels Date: Thu, 15 Apr 2004 16:47:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , [snip] > i think we should do the following: > - we should polish the individual threats (see other mails) yes > - we should not include security requirements ok > - we should not include solutions aspects i think references to solutions could be useful (because they often clarify the threats), provided this is clearly the reason for referring to them > - we should clearly point the main intention of the document and that > additional information is found in the related documents this is the absolutely crucial aspect. i agree with what you propose ("the threats document address the nsis protocol suite...") but I guess we need a commitment from "The Management" that they think so too. > - we should do something with section 2 (i hope to receive > some comments) provided the above aspects are made clear in it, probably not much different needs to be done. (It would be nice to have at least some definition of the word "trust", even if it was "'trust' is used informally with its normal English meaning".) r. > > ciao > hannes > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 15 13:42:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08255 for ; Thu, 15 Apr 2004 13:42:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAnW-00077m-8d for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 13:37:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FHbA8A027371 for nsis-archive@odin.ietf.org; Thu, 15 Apr 2004 13:37:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAXy-0003KH-G7; Thu, 15 Apr 2004 13:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAVJ-0002TF-Rr for nsis@optimus.ietf.org; Thu, 15 Apr 2004 13:18:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05792 for ; Thu, 15 Apr 2004 13:18:19 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAVH-0001Xi-00 for nsis@ietf.org; Thu, 15 Apr 2004 13:18:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEAUG-0001Tf-00 for nsis@ietf.org; Thu, 15 Apr 2004 13:17:17 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BEATR-0001Pp-00 for nsis@ietf.org; Thu, 15 Apr 2004 13:16:25 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FHGIn09093; Thu, 15 Apr 2004 20:16:19 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 20:16:17 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3FHGHD3015864; Thu, 15 Apr 2004 20:16:17 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00afMp9q; Thu, 15 Apr 2004 20:16:15 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FHGDs04545; Thu, 15 Apr 2004 20:16:13 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 20:16:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Security Threats for NSIS : Relevant Communications Models Date: Thu, 15 Apr 2004 20:16:12 +0300 Message-ID: Thread-Topic: [NSIS] Security Threats for NSIS : Relevant Communications Models Thread-Index: AcQjBtE1bk9X46okQaKAXfB87sMDbAABljUA To: , , X-OriginalArrivalTime: 15 Apr 2004 17:16:13.0053 (UTC) FILETIME=[5A58C2D0:01C4230D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Robert, > > i think we should do the following:=20 > > - we should polish the individual threats (see other mails) > yes >=20 > > - we should not include security requirements > ok >=20 > > - we should not include solutions aspects > i think references to solutions could be useful (because they often > clarify the threats), provided this is clearly the reason for=20 > referring to them I agree - we can point to solutions, but point out that we are=20 using them as examples, not as solutions. =20 > > - we should clearly point the main intention of the document and = that > > additional information is found in the related documents > this is the absolutely crucial aspect. i agree with what you > propose ("the threats document address the nsis protocol suite...") > but I guess we need a commitment from "The Management" that they think > so too. That is the word that Allison gave me. Threats document should be = mostly refering to the FW document, not the protocol docs. =20 > > - we should do something with section 2 (i hope to receive=20 > > some comments) > provided the above aspects are made clear in it, probably not much > different needs to be done. (It would be nice to have at least some > definition of the word "trust", even if it was "'trust' is used=20 > informally with its normal English meaning".) OK John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 16 10:28:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12304 for ; Fri, 16 Apr 2004 10:28:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUEu-000602-DK for nsis-archive@odin.ietf.org; Fri, 16 Apr 2004 10:22:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GEMiXD023062 for nsis-archive@odin.ietf.org; Fri, 16 Apr 2004 10:22:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEU8R-0003fw-Dp; Fri, 16 Apr 2004 10:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEU2r-0000p2-1J for nsis@optimus.ietf.org; Fri, 16 Apr 2004 10:10:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10819 for ; Fri, 16 Apr 2004 10:10:13 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEU2o-0000Om-Q9 for nsis@ietf.org; Fri, 16 Apr 2004 10:10:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEU24-0000MP-00 for nsis@ietf.org; Fri, 16 Apr 2004 10:09:28 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BEU1Z-0000Jf-00 for nsis@ietf.org; Fri, 16 Apr 2004 10:08:57 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3GE8sI8020756; Fri, 16 Apr 2004 16:08:54 +0200 To: nsis@ietf.org Cc: "McDonald, Andrew" , "Georgios Karagiannis" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 16 Apr 2004 16:08:50 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/16/2004 16:08:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [NSIS] question to the wg on make before break Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, During the early review session at the last IETF meeting, we got a question on the support of make-before-break reservation. The concept of make-before-break was introduced in RFC3209 (RSVP-TE) as a way to move traffic to a new LSP before tearing down the old LSP. This essentially requires one of two situations: 1. Pre-setup a reservation on a "future path": this requires explicit routing capability (and a way to figure out the future path). We would like to request the WG view on: - whether this should be supported - if yes, whether this is a functionality that should be supported by the NSLP. One aspect to consider here is what make-before-break scenario you would like to support: a. reserve on a diverse path between two peer QNEs: this would require GIMPS to support explicit routing and the API to support the request for "diverse-route-protect". Do we want this? b. reserve on a diverse path bypassing the peer QNE (make-before-break in case of QNE failure): this requires a way for the QoS NSLP to figure out a future peer QNE and a way to ask GIMPS to set up a connection to it (API issue). Do we want this? 2. Keep the data on the old path while the reservation on the new path is being set up: this requires route pinning but it doesn't seem to put additional requirements on either NTLP or NSLP (only on the forwarding function in the data plane): NSIS signalling always follows the current L3 route. However, it only helps when a better route becomes available, not when the current one fails. Cheers, Sven _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 16 20:28:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22637 for ; Fri, 16 Apr 2004 20:28:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdbu-0000Vc-Hq for nsis-archive@odin.ietf.org; Fri, 16 Apr 2004 20:23:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H0N6Gp001956 for nsis-archive@odin.ietf.org; Fri, 16 Apr 2004 20:23:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdXy-0006p7-F9; Fri, 16 Apr 2004 20:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdPh-0004I5-Fu for nsis@optimus.ietf.org; Fri, 16 Apr 2004 20:10:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21754 for ; Fri, 16 Apr 2004 20:10:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEdPf-00059m-D3 for nsis@ietf.org; Fri, 16 Apr 2004 20:10:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEdOf-00056r-00 for nsis@ietf.org; Fri, 16 Apr 2004 20:09:25 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BEdNi-00053V-00; Fri, 16 Apr 2004 20:08:26 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3H07fN15099; Fri, 16 Apr 2004 17:07:41 -0700 (PDT) Message-Id: <200404170007.i3H07fN15099@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, nsis@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 16 Apr 2004 17:07:41 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-9.1 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Subject: [NSIS] RFC 3726 on Requirements for Signaling Protocols Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3726 Title: Requirements for Signaling Protocols Author(s): M. Brunner, Ed. Status: Informational Date: April 2004 Mailbox: brunner@netlab.nec.de Pages: 42 Characters: 98020 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-nsis-req-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3726.txt This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined. For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. This document is a product of the Next Steps in Signaling Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040416170617.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3726 --OtherAccess Content-Type: Message/External-body; name="rfc3726.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040416170617.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Apr 17 08:46:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06227 for ; Sat, 17 Apr 2004 08:46:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEp8D-0008Am-G5 for nsis-archive@odin.ietf.org; Sat, 17 Apr 2004 08:41:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3HCfDLd031416 for nsis-archive@odin.ietf.org; Sat, 17 Apr 2004 08:41:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEp4B-0006uF-BN; Sat, 17 Apr 2004 08:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEp0J-0005tv-4Q for nsis@optimus.ietf.org; Sat, 17 Apr 2004 08:33:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05827 for ; Sat, 17 Apr 2004 08:33:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEp0H-0005q5-T8 for nsis@ietf.org; Sat, 17 Apr 2004 08:33:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEozB-0005gk-00 for nsis@ietf.org; Sat, 17 Apr 2004 08:31:53 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BEoyF-0005Yy-00 for nsis@ietf.org; Sat, 17 Apr 2004 08:30:56 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i3HCUrs18699; Sat, 17 Apr 2004 14:30:53 +0200 (MEST) Received: from verena (cert-lnxek1-6.esn.sbs.de [149.246.36.6]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i3HCUqS08940; Sat, 17 Apr 2004 14:30:53 +0200 (MEST) Message-Id: <200404171230.i3HCUqS08940@mail2.siemens.de> From: "Hannes Tschofenig" To: "'Hancock, Robert'" , Subject: RE: [NSIS] Security Threats for NSIS : Attacks against the Transp ort Mechani sm Date: Sat, 17 Apr 2004 14:33:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQi/60jqTi3cIXwT6+8wV8PLQCcqgBaN2eg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi robert, fixed the text. i will think about including a reference to RFC 2385 (or something similar). has someone else an opinion on this issue? ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Donnerstag, 15. April 2004 17:39 > To: Tschofenig Hannes; 'nsis@ietf.org' > Subject: RE: [NSIS] Security Threats for NSIS : Attacks > against the Transp ort Mechani sm > > i like the new text. some minor points in line: > > > -----Original Message----- > > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Thursday, April 15, 2004 14:45 > > To: 'nsis@ietf.org' > > Subject: [NSIS] Security Threats for NSIS : Attacks against the > > Transport Mechani sm > > > > > > hi all, > > > > a comment regarding section 4.11: > > > > > 4.11 Attacks against the Transport Mechanism > > > > > > I think we can now refer to the split layer architecture as a > > > decision within the group (after all, it's in the > charter) and is as > > > defined in the framework. > > > > > A reference to RFC2385 might be helpful background. > > > > regarding the reference RFC2385 ( Protection of BGP > Sessions via the > > TCP MD5 Signature Option). i guess we should not introduce new > > pointers to certain solutions. rfc2385 is one particular solution > > approach. > > again, i think it is interesting because of the threat > description that it contains (rather than the particular > solution it describes). > > > > > regarding the overall comment i have changed the text from: > [snip] > > to > > > > " > > > > 4.11 Attacks against the NTLP > > > > In [BL01] a two-level architecture is proposed, which suggests > > splitting an NSIS protocol into layers: a signaling message > > transport-specific layer and an application-specific layer. More > > details can be found in the NSIS framework [HF+03]. Most of the > > threats described in this document are applicable to the NSLP > > application-specific part (e.g., QoS NSLP). There are, > however, some > > threats that are applicable to the NTLP. > > > > Network and transport layer protocols lacking protection mechanisms > > are vulnerable to certain attacks such as header manipulation, DoS, > > spoofing of identities, session hijacking, unexpected aborts, etc. > > Malicious nodes can > > attack the congestion control mechanism to force NSIS nodes into a > > congestion avoidance state. > > > > Threats which address parts of the NTLP which are not related to > > attacks against the usage transport layer protocols are covered in > ^^^^^ > use of (?) > > various sections > > throughout this document, such as in Section 4.2. > > > > In the case in which existing transport layer protocols are > used for > > exchanging NSIS signaling messages, security > vulnerabilities know to > > these > ^^^^^^^ > known for? > > protocols need to be considered. A detailed threat description of > > these protocols is outside the scope of this document. > > " > > > > do you think that this is more appropriate? > > > > > > ciao > > hannes > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -- > > Visit our website at www.roke.co.uk > > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to Roke Manor Research Ltd and must not be > passed to any third party without permission. This > communication is for information only and shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Apr 17 08:47:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06292 for ; Sat, 17 Apr 2004 08:47:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEpBp-0000V7-Rh for nsis-archive@odin.ietf.org; Sat, 17 Apr 2004 08:44:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3HCiviG001910 for nsis-archive@odin.ietf.org; Sat, 17 Apr 2004 08:44:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEp4B-0006uN-QC; Sat, 17 Apr 2004 08:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEp0L-0005tx-Cq for nsis@optimus.ietf.org; Sat, 17 Apr 2004 08:33:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05837 for ; Sat, 17 Apr 2004 08:33:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEp0K-0005qN-6O for nsis@ietf.org; Sat, 17 Apr 2004 08:33:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEozO-0005iO-00 for nsis@ietf.org; Sat, 17 Apr 2004 08:32:07 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BEoyS-0005b6-00 for nsis@ietf.org; Sat, 17 Apr 2004 08:31:08 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3HCV6n04163; Sat, 17 Apr 2004 14:31:06 +0200 (MEST) Received: from verena (cert-lnxek1-6.esn.sbs.de [149.246.36.6]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i3HCV5S09037; Sat, 17 Apr 2004 14:31:05 +0200 (MEST) Message-Id: <200404171231.i3HCV5S09037@mail2.siemens.de> From: "Hannes Tschofenig" To: "'Hancock, Robert'" , Subject: RE: [NSIS] Security Threats for NSIS : Combining Signaling and SA Establishm ent Date: Sat, 17 Apr 2004 14:33:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQi/t5P5PW/d829RhiSI7gIb9rZcgBZpzmA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi robert, i also got the impression during the last ietf meeting that people worry about the fact that an arbitrary person can cause a router todo some processing. i have fixed the typos and added the other sentence. ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Donnerstag, 15. April 2004 17:33 > To: Tschofenig Hannes; 'nsis@ietf.org' > Subject: RE: [NSIS] Security Threats for NSIS : Combining > Signaling and SA Establishm ent > > i think the new text is much better. > > teeny comments: > > the paragraph at the start: > > > - Processing of Router Alert Options > > > > The processing of Router Alert Option requires a router to do some > > additional processing by receiving packets with IP options, which > > might lead to additional delay for legitimate requests, or even to > > reject of them. A > ^ > [nit] insert "some"? > > > router being flooded with a large number of bogus messages requires > > resources (e.g., CPU processing due to the context switching) > > i would remove the () part > > > before finding > > out that these messages have to be dropped. > > and then add something like "If the protocol is based on > using interception for message delivery this threat cannot be > completely eliminated, but the protocol design should attempt > to limit the processing that has to be done on the > RAO-bearing packet so it is at most comparable to that for an > arbitrary packet addressed directly to one of the router > interfaces." (or something.) > > [The point I think was not so much that the interception, > whether done by RAO insertion or any other method like > protocol filtering, was expensive, but more that it provided > a mechanism to allow arbitrary people to get the router to > process the rest of the message as well. At least, that is > the impression I got from the discussion during the meeting. > To some extent this is also covered in your NTLP paragraph, > the specific point here is the "require routers to process > intercepted messages" aspect.] > > i would keep this separate from the DoS section (both are > long enough). > > r. > > > -----Original Message----- > > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Thursday, April 15, 2004 14:45 > > To: 'nsis@ietf.org' > > Subject: [NSIS] Security Threats for NSIS : Combining > Signaling and SA > > Establishm ent > > > > > > hi all, > > > > a comment with regard to section 4.2: > > > > > 4. NSIS-Specific Threat Scenarios > > > > > 4.2 Combining Signaling and SA Establishment > > > > > > When a signaling message arrives at an NSIS-aware > > network element, > > ... > > > protection are described in [AN97] and in [ALN00]. > > > > > I found this paragraph quite hard to follow (even though > I think I > > > know what you are trying to say). Part of the problem is that you > > > are talking about the *threat* of flooding but the > section title is > > > referring to imperfections in a particular class of solution. > > > > > There is room for a more structured analysis of the > flooding problem > > > (especially in the light of concerns about RAO handling > expressed on > > > Monday). Flooding needs a layered defence and protection > happens at > > > several levels. > > > > > > based on the received comment i have changed the original text from: > > > > " > > 4.2 Combining Signaling and SA Establishment > > > > This scenario describes attacks that allow an adversary > to flood an > > NSIS node with bogus signaling messages to cause a denial of > > service > > attack. > > > > When a signaling message arrives at an NSIS-aware > network element, > > certain processing is required. If this message contains > security > > objects such as digital signatures, and no security > association is > > already available, then some additional processing is > required for > > the cryptographic verification. Because NSIS signaling > should not > > require extra roundtrips between two NSIS peers, it is > difficult to > > provide the DoS protection mechanisms commonly found in > > authentication and key agreement protocols. Signaling > messages can > > be idempotent, which means that they contain the same amount of > > information as the original message. An example would be > a refresh > > message that is equivalent to a create message. This property > > allows > > a refresh message to create new state along a new path, > although no > > previous state is available. For this to work, specific > classes of > > cryptographic mechanisms supporting this behavior are needed. An > > example is a scheme based on digital signatures, which, however, > > should be used with care due to possible denial of > service attacks. > > Problems with using these types of exchanges with public > key based > > protection are described in [AN97] and in [ALN00]. > > > > In addition to the threat scenario described above, an incoming > > signaling message might require time consuming processing > > (computations, state maintenance, timer setting, etc.) and > > communication with third-party nodes such as policy > servers, LDAP > > servers, etc. If an adversary is able to transmit a > large number of > > signaling messages (for example, with QoS reservation > > requests) with > > invalid credentials, then the verifying node may not be able to > > process other reservation messages from legitimate users. > > > > Further attacks may be enabled by injecting error messages or > > forcing the creation of error messages to extract additional > > information. > > > > > > " > > > > to: > > > > " > > 4.2 Flooding > > > > This section describes attacks that allow an adversary to flood an > > NSIS node with bogus signaling messages to cause a denial > of service > > attack. > > > > We will discuss this threat a different layers in the NSIS protocol > > suite: > > > > - Processing of Router Alert Options > > > > The processing of Router Alert Option requires a router to do some > > additional processing by receiving packets with IP options, which > > might lead to additional delay for legitimate requests, or even to > > reject of them. A router being flooded with a large number of bogus > > messages requires resources (e.g., CPU processing due to > the context > > switching) before finding out that these messages have to > be dropped. > > > > - Force NTLP to-do more processing > > > > Some protocol fields might allow an adversary to force an > NTLP node to > > execute more processing. Additionally it might be possible to > > interfere with the flow control or congestion control procedure. > > > > Certain attacks can be mounted against transport layer protocols by > > flooding a node with bogus requests or even to finish the handshake > > phase to establish a transport layer association. These types of > > threats are also addressed in Section 4.11. > > > > Furthermore, it might be possible to force the NTLP node to perform > > some computations or signaling message exchanges by injecting > > "trigger" events (which are unprotected). > > > > - Force NSLP to-do more processing > > > > An adversary might benefit from flooding an NSLP node with messages > > which must be stored (e.g., due to fragmentation handling) before > > verifying the correctness of signaling messages. > > > > Furthermore, causing memory allocation and computational > efforts might > > allow an adversary to do harm to NSIS entities. If a > signaling message > > contains, for example, a digital signature then some additional > > processing is required for the cryptographic verification. An > > adversary can easily create a random bit sequence instead > of a digital > > signature to force an NSIS node into heavy computation. > > > > Idempotent signaling messages are particularly vulnerable > against this > > type of attack. Idempotent refers to messages which contain > the same > > amount of information as the original message. An example > would be a > > refresh message that is equivalent to a create message. > This property > > allows a refresh message to create new state along a new path, > > although no previous state is available. For this to work, specific > > classes of cryptographic mechanisms supporting this behavior are > > needed. An example is a scheme based on digital signatures, which, > > however, should be used with care due to possible denial of service > > attacks. > > > > Problems with the usage of public key based cryptosystems > in protocols > > are described in [AN97] and in [ALN00]. > > > > In addition to the threat scenario described above, an incoming > > signaling message might trigger communication with > third-party nodes > > such as policy servers, LDAP servers or AAA servers. If an > adversary > > is able to transmit a large number of signaling messages > (for example, > > with QoS reservation > > requests) with invalid credentials, then the verifying node > may not be > > able to process other reservation messages from legitimate users. > > > > " > > > > > > do you think that this text is more useful now? > > should i move this section to the denial of service section? > > > > > > ciao > > hannes > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -- > > Visit our website at www.roke.co.uk > > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to Roke Manor Research Ltd and must not be > passed to any third party without permission. This > communication is for information only and shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Apr 17 08:48:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06355 for ; Sat, 17 Apr 2004 08:48:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEpCs-00013g-W5 for nsis-archive@odin.ietf.org; Sat, 17 Apr 2004 08:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3HCk2tc004062 for nsis-archive@odin.ietf.org; Sat, 17 Apr 2004 08:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEp57-0007P3-Dd; Sat, 17 Apr 2004 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEp43-0006f2-Mo for nsis@optimus.ietf.org; Sat, 17 Apr 2004 08:36:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06018 for ; Sat, 17 Apr 2004 08:36:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEp42-0006JP-GT for nsis@ietf.org; Sat, 17 Apr 2004 08:36:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEp39-0006DX-00 for nsis@ietf.org; Sat, 17 Apr 2004 08:36:00 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BEp2s-00067D-00 for nsis@ietf.org; Sat, 17 Apr 2004 08:35:42 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3HCZfn06117; Sat, 17 Apr 2004 14:35:41 +0200 (MEST) Received: from verena (cert-lnxek1-6.esn.sbs.de [149.246.36.6]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i3HCZeS10810; Sat, 17 Apr 2004 14:35:40 +0200 (MEST) Message-Id: <200404171235.i3HCZeS10810@mail2.siemens.de> From: "Hannes Tschofenig" To: "'Hancock, Robert'" , Subject: RE: [NSIS] Security Threats for NSIS : Insecure Parameter Exchang e and Negot iation Date: Sat, 17 Apr 2004 14:38:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQi/DRuVdBVE5V5RvKOgI/k+K6WnQBYIRxQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi robert, > ok, i think we agree: the rule "if you want to negotiate > security, don't allow include any mechanism which can be > attacked in real time as an option (regardless of who you > think you are negotiating with)" is an example of what i > would call a static policy. > > then I think there are two questions: > > 1. i think the sentence "Hence, without binding the > negotiation process to the legitimate parties and > protecting it, an > NSIS protocol might be only as secure as the weakest mechanism > provided (e.g., weak authentication), and the benefits of defining > configuration parameters and a negotiation protocol are lost." > > is possibly misleading. isn't it the point that the "NSIS > protocol" *is > always* "only as secure as the weakest mechanism provided", > regardless of how the negotiation is wrapped up. you can even provide a negotiation mechanism which is insecure at all or you could provide no mechanisms for negotiating anything or you move the negotiation into a separate protocol (e.g., you mandate ikev2 and ikev2 provides mechanisms for negotiation). what about changing the above sentence to: " Hence, without binding the negotiation process to the legitimate parties and protecting it, the threat of a downgrading attack might be introduced. This might cause weaker security mechanisms or inadequate parameters to be selected. " > > 2. although the document is (I think rightly) steering clear > of suggesting what the solutions to address the threat should > be, i think a reference to something like sipsec-agree is > still helpful, because it explains a concrete example of the > threat in much more detail (as well as providing a solution). i also thought so some time ago when i included more specific examples. that was before i had to remove all those solution specific aspects again, since people asked me todo so. if there are no objections that i will add a reference and mention that this is an example. > One could add something like "For example, this threat arises > in the negotiation of security mechanisms for SIP; a > discussion of the threat and a solution are provided in [3329]." i personally have no objections against including it. ciao hannes > > r. > > > -----Original Message----- > > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Thursday, April 15, 2004 14:45 > > To: 'nsis@ietf.org' > > Subject: [NSIS] Security Threats for NSIS : Insecure > > Parameter Exchange > > and Negot iation > > > > > > hi all, > > > > > 3.4 Insecure Parameter Exchange and Negotiation > > > > > I think this threat is very important to consider. But is there > > > any way to handle it except in the context of a security protocol > > > (unless you rely on static policies)? You can always mount a > > > downgrading attack on the authentication process itself, at > > > which point you are finished. > > > > yes. typically one has to repeat the parameters again after > a security > > association has been established. > > if the weakest mechanism is resistant against a real-time > > attack (i.e., a > > cryptomechanism which can be broken in realtime before the > > negotiation is > > completed) then the modification will be discovered. > > > > you can find an example of this in: > > http://www.ietf.org/rfc/rfc3329.txt > > > > ciao > > hannes > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -- > > Visit our website at www.roke.co.uk > > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, > Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is > confidential to > Roke Manor Research Ltd and must not be passed to any third party > without > permission. This communication is for information only and shall not > create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Apr 18 00:44:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17188 for ; Sun, 18 Apr 2004 00:44:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF45K-0000q2-BL for nsis-archive@odin.ietf.org; Sun, 18 Apr 2004 00:39:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3I4dEps003215 for nsis-archive@odin.ietf.org; Sun, 18 Apr 2004 00:39:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF41F-0007Gg-T6; Sun, 18 Apr 2004 00:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF3s7-00052I-Pp for nsis@optimus.ietf.org; Sun, 18 Apr 2004 00:25:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15196 for ; Sun, 18 Apr 2004 00:25:31 -0400 (EDT) From: rfc-editor@rfc-editor.org Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF3s5-00060u-66 for nsis@ietf.org; Sun, 18 Apr 2004 00:25:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF3rH-0005rP-00 for nsis@ietf.org; Sun, 18 Apr 2004 00:24:44 -0400 Received: from hqemgate02.nvidia.com ([216.228.112.145]) by ietf-mx with esmtp (Exim 4.12) id 1BF3qK-0005Wi-00 for nsis@ietf.org; Sun, 18 Apr 2004 00:23:44 -0400 Received: from hqemfe01.nvidia.com (Not Verified[172.16.228.45]) id ; Sat, 17 Apr 2004 21:23:09 -0700 Received: from mail pickup service by hqemfe01.nvidia.com with Microsoft SMTPSVC; Sat, 17 Apr 2004 21:23:06 -0700 Received: from hqemgate00.nvidia.com ([216.228.112.144]) by hqemfe01.nvidia.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 17 Apr 2004 19:27:43 -0700 Received: from optimus.ietf.org (Not Verified[132.151.6.22]) id ; Sat, 17 Apr 2004 19:27:42 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1ou-00060K-7m; Sat, 17 Apr 2004 22:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdPj-0004I8-Om for ietf-announce@optimus.ietf.org; Fri, 16 Apr 2004 20:10:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21759 for ; Fri, 16 Apr 2004 20:10:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEdPh-0005A0-IG for ietf-announce@ietf.org; Fri, 16 Apr 2004 20:10:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEdOf-000570-00 for ietf-announce@ietf.org; Fri, 16 Apr 2004 20:09:26 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BEdNi-00053V-00; Fri, 16 Apr 2004 20:08:26 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3H07fN15099; Fri, 16 Apr 2004 17:07:41 -0700 (PDT) Message-Id: <200404170007.i3H07fN15099@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, nsis@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 16 Apr 2004 17:07:41 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-MM-Tags: TRUSTED X-OriginalArrivalTime: 18 Apr 2004 02:27:43.0662 (UTC) FILETIME=[BAB67CE0:01C424EC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Subject: [NSIS] RFC 3726 on Requirements for Signaling Protocols Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3726 Title: Requirements for Signaling Protocols Author(s): M. Brunner, Ed. Status: Informational Date: April 2004 Mailbox: brunner@netlab.nec.de Pages: 42 Characters: 98020 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-nsis-req-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3726.txt This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined. For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. This document is a product of the Next Steps in Signaling Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute .. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040416170617.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3726 --OtherAccess Content-Type: Message/External-body; name="rfc3726.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040416170617.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 19 02:20:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19191 for ; Mon, 19 Apr 2004 02:20:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFS7b-00078T-7r for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 02:19:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3J6JBUS027430 for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 02:19:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFS3a-0005Kk-Et; Mon, 19 Apr 2004 02:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFS1K-0003v5-L0 for nsis@optimus.ietf.org; Mon, 19 Apr 2004 02:12:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18051 for ; Mon, 19 Apr 2004 02:12:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFS1G-0002Fk-Q3 for nsis@ietf.org; Mon, 19 Apr 2004 02:12:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFS0I-00022b-00 for nsis@ietf.org; Mon, 19 Apr 2004 02:11:38 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1BFRzN-0001cv-00 for nsis@ietf.org; Mon, 19 Apr 2004 02:10:41 -0400 Received: by jazz.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id i3J69mW0025482; Mon, 19 Apr 2004 15:09:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id i3J69l413945; Mon, 19 Apr 2004 15:09:47 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id i3J69kH20644; Mon, 19 Apr 2004 15:09:46 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml23) id i3J69kH29938; Mon, 19 Apr 2004 15:09:46 +0900 (JST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by soml23.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id i3J69kq29933; Mon, 19 Apr 2004 15:09:46 +0900 (JST) Date: Mon, 19 Apr 2004 15:09:48 +0900 From: Takako Sanda To: sven.van_den_bosch@alcatel.be Subject: Re: [NSIS] question to the wg on make before break Cc: nsis@ietf.org, "McDonald, Andrew" , "Georgios Karagiannis" , Toyoki Ue In-Reply-To: References: Message-Id: <20040419150727.84F9.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.02 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Sven, My opinions are in line. > 1. Pre-setup a reservation on a "future path": this requires explicit > routing capability (and a way to figure out the future path). We would like > to request the WG view on: > - whether this should be supported RFC3583 ("Requirement of a QoS Solution for Mobile IP") requires minimizing the interruption in QoS at the time of handover in Section 3.1-1. And section 3.2-1 says "The QoS mechanism for Mobile IP SHOULD take advantage of these mobility protocols for the optimized operation." This means that, I think, at least QoS for Mobile IP requires pre-setup though discussion of requirements from mobility point of view may be a bit early in this stage of NSIS WG. > - if yes, whether this is a functionality that should be supported by the > NSLP. One aspect to consider here is what make-before-break scenario you > would like to support: > a. reserve on a diverse path between two peer QNEs: this would > require GIMPS to support explicit routing and the API to support the > request for "diverse-route-protect". Do we want this? > b. reserve on a diverse path bypassing the peer QNE > (make-before-break in case of QNE failure): this requires a way for the QoS > NSLP to figure out a future peer QNE and a way to ask GIMPS to set up a > connection to it (API issue). Do we want this? For a), I may not fully understand what diverse-route-protect means. For b), may be yes. It will depend on what kind of mechanism is used for pre-setup. If QNE(NSLP) can find future path and CRN earlier than NTLP, b) will be required. > 2. Keep the data on the old path while the reservation on the new path is > being set up: this requires route pinning but it doesn't seem to put > additional requirements on either NTLP or NSLP (only on the forwarding > function in the data plane): NSIS signalling always follows the current L3 > route. However, it only helps when a better route becomes available, not > when the current one fails. This should be supported as "basic method" for make-before-break. Pre-setup may be failed or may not be available. For these cases, 2) should be supported as a backup method. Cheers, Takako _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 19 02:58:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21138 for ; Mon, 19 Apr 2004 02:58:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFSfS-0007qh-Gl for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 02:54:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3J6sAxa030166 for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 02:54:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFSaU-0006jM-Rs; Mon, 19 Apr 2004 02:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFSYf-0006KS-E0 for nsis@optimus.ietf.org; Mon, 19 Apr 2004 02:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20700 for ; Mon, 19 Apr 2004 02:47:06 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFSYb-0002Hj-Jf for nsis@ietf.org; Mon, 19 Apr 2004 02:47:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFSXh-00022R-00 for nsis@ietf.org; Mon, 19 Apr 2004 02:46:10 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BFSWk-0001mw-00 for nsis@ietf.org; Mon, 19 Apr 2004 02:45:10 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3J6jAk09330 for ; Mon, 19 Apr 2004 09:45:10 +0300 (EET DST) X-Scanned: Mon, 19 Apr 2004 09:44:57 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3J6ivdr020170 for ; Mon, 19 Apr 2004 09:44:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00gSc4YV; Mon, 19 Apr 2004 09:44:55 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3J6ios18372 for ; Mon, 19 Apr 2004 09:44:50 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Apr 2004 09:43:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RFC 3726 on Requirements for Signaling Protocols Date: Mon, 19 Apr 2004 09:43:48 +0300 Message-ID: Thread-Topic: [NSIS] RFC 3726 on Requirements for Signaling Protocols Thread-Index: AcQkEhWnAjs/ewH9QgW5i8CfvSgNuwBx3zGQ To: X-OriginalArrivalTime: 19 Apr 2004 06:43:48.0409 (UTC) FILETIME=[AB3A9290:01C425D9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Good news! > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 3726 >=20 > Title: Requirements for Signaling Protocols > Author(s): M. Brunner, Ed. > Status: Informational > Date: April 2004 > Mailbox: brunner@netlab.nec.de > Pages: 42 > Characters: 98020 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-nsis-req-09.txt >=20 > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3726.txt >=20 Thanks to Markus for seeing this through and the rest of the working = group who commented, sent text, etc. for this document. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 19 06:29:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01584 for ; Mon, 19 Apr 2004 06:29:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVvY-0001b4-T9 for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 06:23:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JAN08M006127 for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 06:23:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVrh-0000qY-En; Mon, 19 Apr 2004 06:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVng-0008NC-S0 for nsis@optimus.ietf.org; Mon, 19 Apr 2004 06:14:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00966 for ; Mon, 19 Apr 2004 06:14:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFVnc-0001mE-QB for nsis@ietf.org; Mon, 19 Apr 2004 06:14:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFVmf-0001Zl-00 for nsis@ietf.org; Mon, 19 Apr 2004 06:13:49 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BFVll-0001BJ-00 for nsis@ietf.org; Mon, 19 Apr 2004 06:12:53 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 19 Apr 2004 11:12:23 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Date: Mon, 19 Apr 2004 11:12:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Interim Meeting Logistics Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, Information about all sorts of things to do with the interim meeting location, hotels, airports, phone sockets etc. can be found at: http://nsis.srmr.co.uk/interim.html Please note the warning about registering and booking hotels early. All the best, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 19 12:31:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21831 for ; Mon, 19 Apr 2004 12:31:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbdr-0000Wl-Qm for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 12:29:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JGT7Oo002018 for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 12:29:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbW7-0006xM-DR; Mon, 19 Apr 2004 12:21:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbSF-0005fL-3z for nsis@optimus.ietf.org; Mon, 19 Apr 2004 12:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20585 for ; Mon, 19 Apr 2004 12:17:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFbSD-0006kU-KJ for nsis@ietf.org; Mon, 19 Apr 2004 12:17:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFbRD-0006Wt-00 for nsis@ietf.org; Mon, 19 Apr 2004 12:16:04 -0400 Received: from fi-hs27135.zapsurf.com.sg ([203.169.78.135] helo=127.0.0.1) by ietf-mx with smtp (Exim 4.12) id 1BFbQJ-00066w-00 for nsis@ietf.org; Mon, 19 Apr 2004 12:15:08 -0400 From: "Cheng Hong" To: , Cc: "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] question to the wg on make before break Date: Tue, 20 Apr 2004 00:14:03 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <000001c42629$57ed4a60$874ea9cb@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-GCMulti: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Sven, My understanding is that the two cases differs on whether there is an IP connectivity on the alternative path before the session transition (so called break). The case 1) is when there is no such IP connectivity available, and case 2) is when there is such IP connectivity.=20 For the case 1), it would require certain assistance for the signaling, = e.g. the path "prediction", or proxy assistance, etc., to signal over the new path. While for case 2), it is more like the multi-homed cases, and the requirements would be similar to that. I think both of the cases have typical usages, e.g. case 1) would be = common with the FMIP deployments, and case 2) could be a common multimode = terminal handover process. Therefore, they should all be supported by the NSIS (NSLP+NTLP) As for the case 1a), if I did not get it wrong, the = "diverse-route-protect" is the same requirement for the multi-home cases, and the similar what = we have discussed before. For the case 1b), I am not very sure about the use cases. Do you mean = that the QNE could specify avoiding inclusion of another QNE on the new path = to the GMIP? cheers Cheng Hong =20 > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On=20 > Behalf Of sven.van_den_bosch@alcatel.be > Sent: Friday, April 16, 2004 10:09 PM > To: nsis@ietf.org > Cc: McDonald, Andrew; Georgios Karagiannis > Subject: [NSIS] question to the wg on make before break >=20 >=20 > Hi all, >=20 > During the early review session at the last IETF meeting, we=20 > got a question on the support of make-before-break=20 > reservation. The concept of make-before-break was introduced=20 > in RFC3209 (RSVP-TE) as a way to move traffic to a new LSP=20 > before tearing down the old LSP. This essentially requires=20 > one of two situations: 1. Pre-setup a reservation on a=20 > "future path": this requires explicit routing capability (and=20 > a way to figure out the future path). We would like to=20 > request the WG view on: > - whether this should be supported > - if yes, whether this is a functionality that should be=20 > supported by the NSLP. One aspect to consider here is what=20 > make-before-break scenario you would like to support: > a. reserve on a diverse path between two peer QNEs:=20 > this would require GIMPS to support explicit routing and the=20 > API to support the request for "diverse-route-protect". Do we=20 > want this? > b. reserve on a diverse path bypassing the peer QNE=20 > (make-before-break in case of QNE failure): this requires a=20 > way for the QoS NSLP to figure out a future peer QNE and a=20 > way to ask GIMPS to set up a connection to it (API issue). Do=20 > we want this? >=20 > 2. Keep the data on the old path while the reservation on the=20 > new path is being set up: this requires route pinning but it=20 > doesn't seem to put additional requirements on either NTLP or=20 > NSLP (only on the forwarding function in the data plane):=20 > NSIS signalling always follows the current L3 route. However,=20 > it only helps when a better route becomes available, not when=20 > the current one fails. >=20 > Cheers, > Sven >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 19 15:07:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02085 for ; Mon, 19 Apr 2004 15:07:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFdy7-00053U-9o for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 14:58:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JIwBkH019424 for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 14:58:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFdqF-0003xL-88; Mon, 19 Apr 2004 14:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFdgp-0002Ho-Oy for nsis@optimus.ietf.org; Mon, 19 Apr 2004 14:40:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00474 for ; Mon, 19 Apr 2004 14:40:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFdgn-0003GC-00 for nsis@ietf.org; Mon, 19 Apr 2004 14:40:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFdg7-00031v-00 for nsis@ietf.org; Mon, 19 Apr 2004 14:39:36 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BFdf2-0002WU-00 for nsis@ietf.org; Mon, 19 Apr 2004 14:38:28 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Apr 2004 10:49:20 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3JIbn8k029230; Mon, 19 Apr 2004 11:37:53 -0700 (PDT) Received: from stealth-10-32-245-156.cisco.com (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOF56738; Mon, 19 Apr 2004 11:37:47 -0700 (PDT) Date: Mon, 19 Apr 2004 14:37:44 -0400 From: "David R. Oran" To: sven.van_den_bosch@alcatel.be, nsis@ietf.org cc: "McDonald, Andrew" , Georgios Karagiannis Subject: Re: [NSIS] question to the wg on make before break Message-ID: <2147483647.1082385464@[10.32.245.156]> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========AF73B5CD41709C9FE0F9==========" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --==========AF73B5CD41709C9FE0F9========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Friday, April 16, 2004 4:08 PM +0200 sven.van_den_bosch@alcatel.be=20 wrote: > Hi all, > > During the early review session at the last IETF meeting, we got a > question on the support of make-before-break reservation. The concept of > make-before-break was introduced in RFC3209 (RSVP-TE) as a way to move > traffic to a new LSP before tearing down the old LSP. This essentially > requires one of two situations: > 1. Pre-setup a reservation on a "future path": this requires explicit > routing capability (and a way to figure out the future path). We would > like to request the WG view on: > - whether this should be supported I think the answer should be yes, but I don't understand the comment about=20 needing explicit routing to make this work (at least as the term is used in = the MPLS world). Could you elaborate? > - if yes, whether this is a functionality that should be supported by the > NSLP. Hmmm, this may be another of those pesky "between the layers" things. Why=20 should this have to be invented separately for QoS, NAT/Firewall, or other=20 NSLPs? > One aspect to consider here is what make-before-break scenario you > would like to support: > a. reserve on a diverse path between two peer QNEs: this would > require GIMPS to support explicit routing and the API to support the > request for "diverse-route-protect". Do we want this? Supporting disjoint path constraints, all other things being equal, is a=20 good idea. In fact, it might be a good idea to think through a way to=20 express a variety of constraints since disjoint path is only one of a=20 number of possibilities. I do believe that disjoint path as a constraint=20 does require at least route recording, and possibly explicit routing (in=20 the sense of pre-computed and source routed). One thing to consider here is = if this gets into the nether world of backing NSIS into a complete QoS=20 routing protocol which will make PNNI look like a walk in the park. > b. reserve on a diverse path bypassing the peer QNE > (make-before-break in case of QNE failure): this requires a way for the > QoS NSLP to figure out a future peer QNE and a way to ask GIMPS to set up > a connection to it (API issue). Do we want this? > Won't this happen correctly as a side effect of next-hop selection? If not, = then there's something about the architecture I must misunderstand. > 2. Keep the data on the old path while the reservation on the new path is > being set up: this requires route pinning but it doesn't seem to put > additional requirements on either NTLP or NSLP (only on the forwarding > function in the data plane): NSIS signalling always follows the current = L3 > route. However, it only helps when a better route becomes available, not > when the current one fails. > Right - that's one reason I don't think we can retain the single-path model = of routing that NSIS assumes today. NSIS needs access to the RIBs as well as the FIBs, it seems, unless the=20 routing system puts alternate path info in the FIB along with the active=20 path info. Again, striking a bblance between just managing resources on the = single best path that routing tells NSIS about and diving full depth into=20 QoS routing is going to be an interesting juggling act. Not to mention keeping C-mode and D-mode straight and having a good=20 interface for D-mode that allows NSIS to express forwarding constraints to=20 the routing layer... Dave. > Cheers, > Sven > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --==========AF73B5CD41709C9FE0F9========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAhBx4jWaEtlTdKuYRAkx1AJ9E9RBasXwD8lMi6s2ZK9uBXBqsxwCg38O1 /nEn6E7tVI5sTmGCnlDtnes= =jrAf -----END PGP SIGNATURE----- --==========AF73B5CD41709C9FE0F9==========-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 19 15:36:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04564 for ; Mon, 19 Apr 2004 15:36:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeWm-0004Kj-K6 for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 15:34:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JJY01x016643 for nsis-archive@odin.ietf.org; Mon, 19 Apr 2004 15:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeSy-0003j9-Mx; Mon, 19 Apr 2004 15:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeQQ-0002vx-TH for nsis@optimus.ietf.org; Mon, 19 Apr 2004 15:27:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03994 for ; Mon, 19 Apr 2004 15:27:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeQP-0006pJ-EJ for nsis@ietf.org; Mon, 19 Apr 2004 15:27:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFePe-0006b5-00 for nsis@ietf.org; Mon, 19 Apr 2004 15:26:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BFeOt-0006IE-00 for nsis@ietf.org; Mon, 19 Apr 2004 15:25:51 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 19 Apr 2004 12:26:14 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3JJPJ7t018115; Mon, 19 Apr 2004 12:25:19 -0700 (PDT) Received: from stealth-10-32-245-156.cisco.com (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOF61990; Mon, 19 Apr 2004 12:25:17 -0700 (PDT) Date: Mon, 19 Apr 2004 15:25:14 -0400 From: David Oran To: "Roy, Radhika R, ALABS" , "James M. Polk" cc: nsis@ietf.org Subject: RE: [NSIS] Questions regarding Message-ID: <2147483647.1082388314@[10.32.245.156]> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A06CAEED0@ACCLUST02EVS1.ugd.att.com> References: <34DA635B184A644DA4588E260EC0A25A06CAEED0@ACCLUST02EVS1.ugd.att. com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Thursday, April 15, 2004 11:39 AM -0400 "Roy, Radhika R, ALABS" wrote: > Hi, all: > > I do not think that things will be just like what has been stated below. > Here are the points: > > 1. In SIP INVITE message, SDP describes what codecs are. For example, it > may be G.711 codec. Per specifications of G.711 codec, there is a > standard what are the performance characteristics of G.711 in terms of > end-to-end delay between the codec, bandwidth, delay jitter and losses. > There is? Even if I'm streaming to/from a file store, like a voicemail server? I don't think so -please point me to the part of G.711 which specifies these things. > 2. Like all other functional requirements, a SIP UA also expects that the > commitment of the above performance requirements must be met. > Well, just to quibble, but I think it's the application on top of the SIP UA that cares, not the SIP UA itself, since the UA has no idea whether SIP is being used for realtime-constrained applications. > 3. If the quality between the codecs is not delivered, there is a breach > of "contract" so far acceptance of the call is concerned. > > So, before acceptance of the call the following needs to happen: > > a. The SIP Layer entities (e.g., proxies) need to make sure that there > are sufficient resources (e.g., CPU capacity, ports) in the end-to-end > path. > How can the SIP proxies ascertain this? Are you assuming a bandwidth-broker architecture where the proxies have close-coupled state with the bandwidth brokers? Dave. > b. The IP network layer needs to make sure that ingress access network, > backbone network, and egress access network all together in the > end-to-end path has the resources to meet the performance requirements > (end-to-end delay/bandwidth/jitter/losses). > > c. It is important to note that item c does not have the end-to-end > knowledge of delay/jitter/losses. That is, an entity that has the > knowledge of end-to-end SIP/application layer performance requirements > will divide the QoS requirements into three areas (access network, > backbone network, and egress network) so that end-to-end performance > requirements at the SIP layer is met. > > The above description clearly shows where and how the NSIS protocol needs > to play the role acting bridging the gap between the SIP application > layer and the IP network layer. > > Best regards, > > Radhika R. Roy > AT&T SoIP Network Architect > 732 420 1580 > >> From: James M. Polk [mailto:jmpolk@cisco.com] >> Sent: Tuesday, April 13, 2004 10:57 PM > >> SIP, if it is the only means of call establishment and control, will set >> up the call, thereby reducing the quality of all 4 calls traversing that >> circuit. The users won't know what happened, just that voice reception >> quality just tanked. > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 20 02:51:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26988 for ; Tue, 20 Apr 2004 02:51:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFp4y-0001lT-5e for nsis-archive@odin.ietf.org; Tue, 20 Apr 2004 02:50:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K6o0xa006783 for nsis-archive@odin.ietf.org; Tue, 20 Apr 2004 02:50:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFp19-0000ra-0R; Tue, 20 Apr 2004 02:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFozy-0000QK-9V for nsis@optimus.ietf.org; Tue, 20 Apr 2004 02:44:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26622 for ; Tue, 20 Apr 2004 02:44:47 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFozu-0007J0-GU for nsis@ietf.org; Tue, 20 Apr 2004 02:44:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFoz3-00073E-00 for nsis@ietf.org; Tue, 20 Apr 2004 02:43:54 -0400 Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx with esmtp (Exim 4.12) id 1BFoyO-0006nT-00 for nsis@ietf.org; Tue, 20 Apr 2004 02:43:12 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3K6hAQP029722; Tue, 20 Apr 2004 08:43:11 +0200 Subject: RE: [NSIS] question to the wg on make before break To: "Cheng Hong" Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 20 Apr 2004 08:43:08 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/20/2004 08:43:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 Cheng Hong, Thanks for your comments. Please find some replies below (inline). Best regards, Sven "Cheng Hong" on 19/04/2004 18:14:03 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, cc: "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] question to the wg on make before break Hi Sven, My understanding is that the two cases differs on whether there is an IP connectivity on the alternative path before the session transition (so called break). The case 1) is when there is no such IP connectivity available, and case 2) is when there is such IP connectivity. Sven>> I don't think that is what I meant. In the first case, the idea is to have a reservation on the new path in place when the old path needs to be torn down and so you can immediately move the traffic to this new path. The issue here is that you need a way to find out where this future path is going to be (and how to reserve on it). In the second case, you just keep the traffic on the old path after the route change while you are making the reservation on the new path. The issue here is not with the signalling (which follows the normal L3) but with the data which needs to be kept on the old path somehow. Also, this is obviously not a good solution when the old path has a failure. For the case 1), it would require certain assistance for the signaling, e.g. the path "prediction", or proxy assistance, etc., to signal over the new path. While for case 2), it is more like the multi-homed cases, and the requirements would be similar to that. I think both of the cases have typical usages, e.g. case 1) would be common with the FMIP deployments, and case 2) could be a common multimode terminal handover process. Therefore, they should all be supported by the NSIS (NSLP+NTLP) As for the case 1a), if I did not get it wrong, the "diverse-route-protect" is the same requirement for the multi-home cases, and the similar what we have discussed before. For the case 1b), I am not very sure about the use cases. Do you mean that the QNE could specify avoiding inclusion of another QNE on the new path to the GMIP? Sven>> The assumption is that case 1 also works with failures. 1a allows you to protect against NE failures, 1b also protects against QNE failures (compare it to link and node protection with MPLS FRR). cheers Cheng Hong > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of sven.van_den_bosch@alcatel.be > Sent: Friday, April 16, 2004 10:09 PM > To: nsis@ietf.org > Cc: McDonald, Andrew; Georgios Karagiannis > Subject: [NSIS] question to the wg on make before break > > > Hi all, > > During the early review session at the last IETF meeting, we > got a question on the support of make-before-break > reservation. The concept of make-before-break was introduced > in RFC3209 (RSVP-TE) as a way to move traffic to a new LSP > before tearing down the old LSP. This essentially requires > one of two situations: 1. Pre-setup a reservation on a > "future path": this requires explicit routing capability (and > a way to figure out the future path). We would like to > request the WG view on: > - whether this should be supported > - if yes, whether this is a functionality that should be > supported by the NSLP. One aspect to consider here is what > make-before-break scenario you would like to support: > a. reserve on a diverse path between two peer QNEs: > this would require GIMPS to support explicit routing and the > API to support the request for "diverse-route-protect". Do we > want this? > b. reserve on a diverse path bypassing the peer QNE > (make-before-break in case of QNE failure): this requires a > way for the QoS NSLP to figure out a future peer QNE and a > way to ask GIMPS to set up a connection to it (API issue). Do > we want this? > > 2. Keep the data on the old path while the reservation on the > new path is being set up: this requires route pinning but it > doesn't seem to put additional requirements on either NTLP or > NSLP (only on the forwarding function in the data plane): > NSIS signalling always follows the current L3 route. However, > it only helps when a better route becomes available, not when > the current one fails. > > Cheers, > Sven > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 20 03:40:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29001 for ; Tue, 20 Apr 2004 03:40:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFpoL-0002uD-76 for nsis-archive@odin.ietf.org; Tue, 20 Apr 2004 03:36:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K7ar7s011157 for nsis-archive@odin.ietf.org; Tue, 20 Apr 2004 03:36:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFpct-0000rt-2h; Tue, 20 Apr 2004 03:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFpWp-00087w-Ep for nsis@optimus.ietf.org; Tue, 20 Apr 2004 03:18:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28202 for ; Tue, 20 Apr 2004 03:18:46 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFpWn-0000Xl-73 for nsis@ietf.org; Tue, 20 Apr 2004 03:18:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFpVx-0000HY-00 for nsis@ietf.org; Tue, 20 Apr 2004 03:17:54 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BFpVA-00001p-00 for nsis@ietf.org; Tue, 20 Apr 2004 03:17:04 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3K7GwQP013914; Tue, 20 Apr 2004 09:16:58 +0200 Subject: Re: [NSIS] question to the wg on make before break To: "David R. Oran" Cc: nsis@ietf.org, "McDonald, Andrew" , Georgios Karagiannis X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 20 Apr 2004 09:16:56 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/20/2004 09:16:57 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=4EBBE4EFDFB64BBD8f9e8a93df938690918c4EBBE4EFDFB64BBD" Content-Disposition: inline X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --0__=4EBBE4EFDFB64BBD8f9e8a93df938690918c4EBBE4EFDFB64BBD Content-type: text/plain; charset=us-ascii Hi Dave, Thanks for your comments. I have tried to address them inline. Best regards, Sven "David R. Oran" on 19/04/2004 20:37:44 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, nsis@ietf.org cc: "McDonald, Andrew" , Georgios Karagiannis Subject: Re: [NSIS] question to the wg on make before break --On Friday, April 16, 2004 4:08 PM +0200 sven.van_den_bosch@alcatel.be wrote: > Hi all, > > During the early review session at the last IETF meeting, we got a > question on the support of make-before-break reservation. The concept of > make-before-break was introduced in RFC3209 (RSVP-TE) as a way to move > traffic to a new LSP before tearing down the old LSP. This essentially > requires one of two situations: > 1. Pre-setup a reservation on a "future path": this requires explicit > routing capability (and a way to figure out the future path). We would > like to request the WG view on: > - whether this should be supported I think the answer should be yes, but I don't understand the comment about needing explicit routing to make this work (at least as the term is used in the MPLS world). Could you elaborate? Sven>> Hm, I may have jumped to conclusions here (I am afraid I have a history of MPLS traffic engineering work). What I meant is that we cannot rely on 'normal layer 3 routing' to make the reservation on the 'future path'. I suppose any policy-based routing mechanism will work. > - if yes, whether this is a functionality that should be supported by the > NSLP. Hmmm, this may be another of those pesky "between the layers" things. Why should this have to be invented separately for QoS, NAT/Firewall, or other NSLPs? Sven>> In my opinion, if we choose to support this kind of functionality, it should be requested by the NSLP over the API but implemented at the NTLP (at least for case 1a). For case 1b, I think it becomes a different matter because you need the NSLP to be detect its future peer (at the risk of being blasphemous I would say you need a peer discovery mechanism that allows you to search on future paths). One thing that may alleviate the problem is that it is likely (in C-mode) that a QNE already has a connection to the future peer (because it was a peer for other destinations) > One aspect to consider here is what make-before-break scenario you > would like to support: > a. reserve on a diverse path between two peer QNEs: this would > require GIMPS to support explicit routing and the API to support the > request for "diverse-route-protect". Do we want this? Supporting disjoint path constraints, all other things being equal, is a good idea. In fact, it might be a good idea to think through a way to express a variety of constraints since disjoint path is only one of a number of possibilities. I do believe that disjoint path as a constraint does require at least route recording, and possibly explicit routing (in the sense of pre-computed and source routed). One thing to consider here is if this gets into the nether world of backing NSIS into a complete QoS routing protocol which will make PNNI look like a walk in the park. Sven>> I don't know if the GIMPS designers want to go there. > b. reserve on a diverse path bypassing the peer QNE > (make-before-break in case of QNE failure): this requires a way for the > QoS NSLP to figure out a future peer QNE and a way to ask GIMPS to set up > a connection to it (API issue). Do we want this? > Won't this happen correctly as a side effect of next-hop selection? If not, then there's something about the architecture I must misunderstand. Sven>> I think the next-hop selection will automatically find the new next hop but only after a while. So this mechanism will not allow making the reservation in advance at the new next hop QNE. > 2. Keep the data on the old path while the reservation on the new path is > being set up: this requires route pinning but it doesn't seem to put > additional requirements on either NTLP or NSLP (only on the forwarding > function in the data plane): NSIS signalling always follows the current L3 > route. However, it only helps when a better route becomes available, not > when the current one fails. > Right - that's one reason I don't think we can retain the single-path model of routing that NSIS assumes today. NSIS needs access to the RIBs as well as the FIBs, it seems, unless the routing system puts alternate path info in the FIB along with the active path info. Again, striking a bblance between just managing resources on the single best path that routing tells NSIS about and diving full depth into QoS routing is going to be an interesting juggling act. Sven>> I know of one proposal (I think it was draft-walton-...) where a suggestion was made to extend BGP reachability with alternate paths (well reachability information technically I guess). At the time there were also some individual drafts on BGP extension for QoS routing. Is any of this still alive? Not to mention keeping C-mode and D-mode straight and having a good interface for D-mode that allows NSIS to express forwarding constraints to the routing layer... Dave. > Cheers, > Sven > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --0__=4EBBE4EFDFB64BBD8f9e8a93df938690918c4EBBE4EFDFB64BBD Content-type: application/octet-stream; name="C.DTF" Content-Disposition: attachment; filename="C.DTF" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAoRGFy d2luKQ0KDQppRDhEQlFGQWhCeDRqV2FFdGxUZEt1WVJBa3gxQUo5RTlSQmFzWHdEOGxNaTZzMlpL OXVCWEJxc3h3Q2czOE8xDQovbkVuNkU3dFZJNXNUbUdDbmxEdG5lcz0NCj1qckFmDQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg0K --0__=4EBBE4EFDFB64BBD8f9e8a93df938690918c4EBBE4EFDFB64BBD-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 20 03:54:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29614 for ; Tue, 20 Apr 2004 03:54:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFpyG-0006cP-1r for nsis-archive@odin.ietf.org; Tue, 20 Apr 2004 03:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K7l8Ne025441 for nsis-archive@odin.ietf.org; Tue, 20 Apr 2004 03:47:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFpuI-0005UK-8B; Tue, 20 Apr 2004 03:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFpqC-000475-VV for nsis@optimus.ietf.org; Tue, 20 Apr 2004 03:38:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28874 for ; Tue, 20 Apr 2004 03:38:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFpqA-0005ZG-2Y for nsis@ietf.org; Tue, 20 Apr 2004 03:38:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFppJ-0005Jw-00 for nsis@ietf.org; Tue, 20 Apr 2004 03:37:54 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BFpoR-0004pL-00 for nsis@ietf.org; Tue, 20 Apr 2004 03:36:59 -0400 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i3K7RfCX020766; Tue, 20 Apr 2004 15:27:53 +0800 (SGT) From: "Cheng Hong" To: Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] question to the wg on make before break Date: Tue, 20 Apr 2004 15:36:04 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <000701c426aa$2605b2e0$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Sven, Please see some further comments below cheers Cheng Hong > My understanding is that the two cases differs on whether > there is an IP connectivity on the alternative path before > the session transition (so called break). The case 1) is when > there is no such IP connectivity available, and case 2) is > when there is such IP connectivity. > > Sven>> I don't think that is what I meant. In the first case, > the idea > Sven>> is > to have a reservation on the new path in place when the old > path needs to be torn down and so you can immediately move > the traffic to this new path. The issue here is that you need > a way to find out where this future path is going to be (and > how to reserve on it). Agree. This is what the "make before break" needs to achieve. But, does it mean that after finding out the future path, we could do signaling over it immediately(having L3 connectivity)? I think in a FMIP case, it may not be true. And another question I have is regarding the role of NSIS in the "finding of the future path". Is that going to be part of the NSIS? >In the second case, you just keep the > traffic on the old path after the route change while you are > making the reservation on the new path. The issue here is not > with the signalling (which follows the normal L3) but with > the data which needs to be kept on the old path somehow. > Also, this is obviously not a good solution when the old path > has a failure. I would say I got a bit confused here. I don't know how the "route change" is defined, but sounds like this is to delay the actual data path transition. Obviously this is not always possible, due to physical limitations. In a multi-mode/homed mobile terminal, this maybe possible. But, if we take a closer look at the issue (with the supported case, e.g. multi-home), is it equivalent to the case when the new path is available before the "route change" happens? The reservation on the new path could be made as the data remains on the old path. Maybe this is also covered in the first case. > For the case 1), it would require certain assistance for the > signaling, e.g. the path "prediction", or proxy assistance, > etc., to signal over the new path. While for case 2), it is > more like the multi-homed cases, and the requirements would > be similar to that. > > I think both of the cases have typical usages, e.g. case 1) > would be common with the FMIP deployments, and case 2) could > be a common multimode terminal handover process. Therefore, > they should all be supported by the NSIS > (NSLP+NTLP) > > As for the case 1a), if I did not get it wrong, the > "diverse-route-protect" is the same requirement for the > multi-home cases, and the similar what we have discussed before. > > For the case 1b), I am not very sure about the use cases. Do > you mean that the QNE could specify avoiding inclusion of > another QNE on the new path to the GMIP? > > Sven>> The assumption is that case 1 also works with > failures. 1a allows > you to protect against NE failures, 1b also protects against > QNE failures (compare it to link and node protection with MPLS FRR). > > > cheers > > Cheng Hong > > > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On Behalf Of > > sven.van_den_bosch@alcatel.be > > Sent: Friday, April 16, 2004 10:09 PM > > To: nsis@ietf.org > > Cc: McDonald, Andrew; Georgios Karagiannis > > Subject: [NSIS] question to the wg on make before break > > > > > > Hi all, > > > > During the early review session at the last IETF meeting, we got a > > question on the support of make-before-break reservation. > The concept > > of make-before-break was introduced in RFC3209 (RSVP-TE) as > a way to > > move traffic to a new LSP before tearing down the old LSP. This > > essentially requires one of two situations: 1. Pre-setup a > reservation > > on a "future path": this requires explicit routing capability (and > > a way to figure out the future path). We would like to > > request the WG view on: > > - whether this should be supported > > - if yes, whether this is a functionality that should be > > supported by the NSLP. One aspect to consider here is what > > make-before-break scenario you would like to support: > > a. reserve on a diverse path between two peer QNEs: > > this would require GIMPS to support explicit routing and the > > API to support the request for "diverse-route-protect". Do we > > want this? > > b. reserve on a diverse path bypassing the peer QNE > > (make-before-break in case of QNE failure): this requires a > > way for the QoS NSLP to figure out a future peer QNE and a > > way to ask GIMPS to set up a connection to it (API issue). Do > > we want this? > > > > 2. Keep the data on the old path while the reservation on > the new path > > is being set up: this requires route pinning but it doesn't seem to > > put additional requirements on either NTLP or NSLP (only on the > > forwarding function in the data plane): NSIS signalling > always follows > > the current L3 route. However, it only helps when a better route > > becomes available, not when the current one fails. > > > > Cheers, > > Sven > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 20 08:45:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14008 for ; Tue, 20 Apr 2004 08:45:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFuV0-0007Ex-W4 for nsis-archive@odin.ietf.org; Tue, 20 Apr 2004 08:37:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KCbEwE027823 for nsis-archive@odin.ietf.org; Tue, 20 Apr 2004 08:37:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFuQv-0005YM-Oo; Tue, 20 Apr 2004 08:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFuM3-0003wo-Li for nsis@optimus.ietf.org; Tue, 20 Apr 2004 08:28:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13177 for ; Tue, 20 Apr 2004 08:27:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFuM2-0005U0-BM for nsis@ietf.org; Tue, 20 Apr 2004 08:27:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFuL1-0005EM-00 for nsis@ietf.org; Tue, 20 Apr 2004 08:26:56 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BFuK1-0004kn-00 for nsis@ietf.org; Tue, 20 Apr 2004 08:25:53 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Apr 2004 13:25:14 +0100 Message-ID: From: "Hancock, Robert" To: "'sven.van_den_bosch@alcatel.be'" , "David R. Oran" Cc: nsis@ietf.org, "McDonald, Andrew" , Georgios Karagiannis Subject: RE: [NSIS] question to the wg on make before break Date: Tue, 20 Apr 2004 13:25:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 (non-in-line) comments on this question, mainly from an NTLP perspective. 1. The current message routing mechanism is fundamentally incapable of sending messages along anything other than the current 'active' path. in large part, this is a consequence of having to live with NSIS-unaware nodes *and* not wanting to do explicit routing. Or, to put it the other way round: with explicit routing you can do anything (but then you need a route calculator somewhere); if you don't have explicit routing, and some nodes are not NSIS aware, then primary path is all you can have (since the D mode message is only sensitive to the FIB at such nodes). So, one question would be: do you want these capabilities only in a fully-NSIS-aware network or in a network which includes NSIS-unaware nodes? (if the former, there are several options; if the latter, ER is I think all that can be used.) 2. Is there any structured definition anywhere of what sort of routing diversity we would be trying to achieve or live with? Once you go away from a single path, there would seem to be a lot of ways of having more than one. I assume there is such a taxonomy e.g. from MPLS or PNNI or SDH/SONET work, but I'm not sure how applicable it is here: isn't it all based on setting up route sets with particular protection properties, rather than setting up state along those route sets? To put it another way: in the 'single path' case, the basic NSIS position is a) routing defines where the flow goes (its path); b) signalling sets up state along the flow's path In the multi-path case, is there the same split? Or are people assuming the signalling is going to do part of (a)? Some of the discussion below (e.g. distinguishing between whether the backup path goes to the same QNE or goes to a different one, or imposing disjointness contraints) seems to me to come into category (a), which (at least initially) I would regard as out of scope for NSIS. 3. Some design issues: Firstly, I don't see the C/D split as a problem here. For the bulk of the protocol, the operation doesn't need to depend on how the next peer was discovered (although you may need to bind a particular messaging association to the discovery mechanism in some cases). More importantly, what I think the discussion implies is that we need to hold open the concept of GIMPS allowing multiple message routing mechanisms (of which 'send along the path of a real flow and intercept' is just the first). That is something that is already partly on the table (since one of the NATFW messages may need a slightly different message routing mechanism from ordinary NSIS messages). It may be that this modularisation is enough flexibility for the first versions - provided people can define just what 'sending a message along the backup path' really means, and we get the boundary round the message routing method concept right, we can reserve a place for it without actually designing all the details. robert h. > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Tuesday, April 20, 2004 08:17 > To: David R. Oran > Cc: nsis@ietf.org; McDonald, Andrew; Georgios Karagiannis > Subject: Re: [NSIS] question to the wg on make before break > > > Hi Dave, > > Thanks for your comments. I have tried to address them inline. > > Best regards, > Sven > > > > > > "David R. Oran" on 19/04/2004 20:37:44 > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, nsis@ietf.org > cc: "McDonald, Andrew" , Georgios > Karagiannis > Subject: Re: [NSIS] question to the wg on make before break > > > --On Friday, April 16, 2004 4:08 PM +0200 > sven.van_den_bosch@alcatel.be > wrote: > > > Hi all, > > > > During the early review session at the last IETF meeting, we got a > > question on the support of make-before-break reservation. > The concept of > > make-before-break was introduced in RFC3209 (RSVP-TE) as a > way to move > > traffic to a new LSP before tearing down the old LSP. This > essentially > > requires one of two situations: > > 1. Pre-setup a reservation on a "future path": this > requires explicit > > routing capability (and a way to figure out the future > path). We would > > like to request the WG view on: > > - whether this should be supported > I think the answer should be yes, but I don't understand the > comment about > needing explicit routing to make this work (at least as the > term is used in > the MPLS world). Could you elaborate? > > Sven>> Hm, I may have jumped to conclusions here (I am afraid I have a > history of MPLS traffic engineering work). What I meant is > that we cannot > rely on 'normal layer 3 routing' to make the reservation on > the 'future > path'. I suppose any policy-based routing mechanism will work. > > > - if yes, whether this is a functionality that should be > supported by the > > NSLP. > Hmmm, this may be another of those pesky "between the layers" > things. Why > should this have to be invented separately for QoS, > NAT/Firewall, or other > NSLPs? > > Sven>> In my opinion, if we choose to support this kind of > functionality, > it should be requested by the NSLP over the API but > implemented at the NTLP > (at least for case 1a). For case 1b, I think it becomes a > different matter > because you need the NSLP to be detect its future peer (at the risk of > being blasphemous I would say you need a peer discovery mechanism that > allows you to search on future paths). One thing that may > alleviate the > problem is that it is likely (in C-mode) that a QNE already has a > connection to the future peer (because it was a peer for other > destinations) > > > One aspect to consider here is what make-before-break scenario you > > would like to support: > > a. reserve on a diverse path between two peer QNEs: this would > > require GIMPS to support explicit routing and the API to support the > > request for "diverse-route-protect". Do we want this? > Supporting disjoint path constraints, all other things being > equal, is a > good idea. In fact, it might be a good idea to think through a way to > express a variety of constraints since disjoint path is only one of a > number of possibilities. I do believe that disjoint path as a > constraint > does require at least route recording, and possibly explicit > routing (in > the sense of pre-computed and source routed). One thing to > consider here is > if this gets into the nether world of backing NSIS into a complete QoS > routing protocol which will make PNNI look like a walk in the park. > > Sven>> I don't know if the GIMPS designers want to go there. > > > b. reserve on a diverse path bypassing the peer QNE > > (make-before-break in case of QNE failure): this requires a > way for the > > QoS NSLP to figure out a future peer QNE and a way to ask > GIMPS to set up > > a connection to it (API issue). Do we want this? > > > Won't this happen correctly as a side effect of next-hop > selection? If not, > then there's something about the architecture I must misunderstand. > > Sven>> I think the next-hop selection will automatically find > the new next > hop but only after a while. So this mechanism will not allow > making the > reservation in advance at the new next hop QNE. > > > 2. Keep the data on the old path while the reservation on > the new path is > > being set up: this requires route pinning but it doesn't seem to put > > additional requirements on either NTLP or NSLP (only on the > forwarding > > function in the data plane): NSIS signalling always follows > the current > L3 > > route. However, it only helps when a better route becomes > available, not > > when the current one fails. > > > Right - that's one reason I don't think we can retain the > single-path model > of routing that NSIS assumes today. > > NSIS needs access to the RIBs as well as the FIBs, it seems, > unless the > routing system puts alternate path info in the FIB along with > the active > path info. Again, striking a bblance between just managing > resources on the > single best path that routing tells NSIS about and diving > full depth into > QoS routing is going to be an interesting juggling act. > > Sven>> I know of one proposal (I think it was > draft-walton-...) where a > suggestion was made to extend BGP reachability with alternate > paths (well > reachability information technically I guess). At the time > there were also > some individual drafts on BGP extension for QoS routing. Is > any of this > still alive? > > Not to mention keeping C-mode and D-mode straight and having a good > interface for D-mode that allows NSIS to express forwarding > constraints to > the routing layer... > > Dave. > > > Cheers, > > Sven > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 21 05:50:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07619 for ; Wed, 21 Apr 2004 05:50:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGELb-0004x2-Ux for nsis-archive@odin.ietf.org; Wed, 21 Apr 2004 05:48:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L9mp33019023 for nsis-archive@odin.ietf.org; Wed, 21 Apr 2004 05:48:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGEGv-0002s8-4o; Wed, 21 Apr 2004 05:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGEAv-0000Wb-1i for nsis@optimus.ietf.org; Wed, 21 Apr 2004 05:37:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06935 for ; Wed, 21 Apr 2004 05:37:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGEAr-0003xd-Dp for nsis@ietf.org; Wed, 21 Apr 2004 05:37:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGE9z-0003qq-00 for nsis@ietf.org; Wed, 21 Apr 2004 05:36:53 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BGE9K-0003jn-00 for nsis@ietf.org; Wed, 21 Apr 2004 05:36:10 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3L9aAPA016310 for ; Wed, 21 Apr 2004 11:36:10 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Apr 2004 11:36:09 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Apr 2004 11:36:13 +0200 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'Hancock, Robert'" , "'sven.van_den_bosch@alcatel.be'" , "David R. Oran" Cc: nsis@ietf.org, "McDonald, Andrew" , Georgios Karagiannis Subject: RE: [NSIS] question to the wg on make before break Date: Wed, 21 Apr 2004 11:41:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 21 Apr 2004 09:36:09.0670 (UTC) FILETIME=[13ED4660:01C42784] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, This feature is interesting but I am wondering if we can think of it in the current phase of NSIS. As far as I know WG agreed to cocentrate on on-path signaling. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Hancock, Robert > Sent: Tuesday, April 20, 2004 2:25 PM > To: 'sven.van_den_bosch@alcatel.be'; David R. Oran > Cc: nsis@ietf.org; McDonald, Andrew; Georgios Karagiannis > Subject: RE: [NSIS] question to the wg on make before break > > > hi, > > Some (non-in-line) comments on this question, mainly from an > NTLP perspective. > > 1. The current message routing mechanism is fundamentally > incapable of sending messages along anything other than the > current 'active' path. > > in large part, this is a consequence of having to live with > NSIS-unaware nodes *and* not wanting to do explicit routing. > Or, to put it the other way round: with explicit routing you > can do anything (but then you need a route calculator somewhere); > if you don't have explicit routing, and some nodes are not > NSIS aware, then primary path is all you can have (since the > D mode message is only sensitive to the FIB at such nodes). > > So, one question would be: do you want these capabilities only > in a fully-NSIS-aware network or in a network which includes > NSIS-unaware nodes? (if the former, there are several options; > if the latter, ER is I think all that can be used.) > > 2. Is there any structured definition anywhere of what sort > of routing diversity we would be trying to achieve or live with? > Once you go away from a single path, there would seem to be a > lot of ways of having more than one. > > I assume there is such a taxonomy e.g. from MPLS or PNNI or > SDH/SONET work, but I'm not sure how applicable it is here: > isn't it all based on setting up route sets with particular protection > properties, rather than setting up state along those route sets? > > To put it another way: in the 'single path' case, the basic > NSIS position is > a) routing defines where the flow goes (its path); > b) signalling sets up state along the flow's path > > In the multi-path case, is there the same split? Or are people > assuming the signalling is going to do part of (a)? Some of the > discussion below (e.g. distinguishing between whether the backup > path goes to the same QNE or goes to a different one, or imposing > disjointness contraints) seems to me to come into category (a), > which (at least initially) I would regard as out of scope for > NSIS. > > 3. Some design issues: Firstly, I don't see the C/D split as > a problem here. For the bulk of the protocol, the operation > doesn't need to depend on how the next peer was discovered > (although you may need to bind a particular messaging association > to the discovery mechanism in some cases). > > More importantly, what I think the discussion implies is that > we need to hold open the concept of GIMPS allowing multiple > message routing mechanisms (of which 'send along the path of > a real flow and intercept' is just the first). That is something > that is already partly on the table (since one of the NATFW messages > may need a slightly different message routing mechanism from > ordinary NSIS messages). > > It may be that this modularisation is enough flexibility for > the first versions - provided people can define just what 'sending > a message along the backup path' really means, and we get the > boundary round the message routing method concept right, we > can reserve a > place for it without actually designing all the details. > > robert h. > > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be > > [mailto:sven.van_den_bosch@alcatel.be] > > Sent: Tuesday, April 20, 2004 08:17 > > To: David R. Oran > > Cc: nsis@ietf.org; McDonald, Andrew; Georgios Karagiannis > > Subject: Re: [NSIS] question to the wg on make before break > > > > > > Hi Dave, > > > > Thanks for your comments. I have tried to address them inline. > > > > Best regards, > > Sven > > > > > > > > > > > > "David R. Oran" on 19/04/2004 20:37:44 > > > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, nsis@ietf.org > > cc: "McDonald, Andrew" , Georgios > > Karagiannis > > Subject: Re: [NSIS] question to the wg on make before break > > > > > > --On Friday, April 16, 2004 4:08 PM +0200 > > sven.van_den_bosch@alcatel.be > > wrote: > > > > > Hi all, > > > > > > During the early review session at the last IETF meeting, we got a > > > question on the support of make-before-break reservation. > > The concept of > > > make-before-break was introduced in RFC3209 (RSVP-TE) as a > > way to move > > > traffic to a new LSP before tearing down the old LSP. This > > essentially > > > requires one of two situations: > > > 1. Pre-setup a reservation on a "future path": this > > requires explicit > > > routing capability (and a way to figure out the future > > path). We would > > > like to request the WG view on: > > > - whether this should be supported > > I think the answer should be yes, but I don't understand the > > comment about > > needing explicit routing to make this work (at least as the > > term is used in > > the MPLS world). Could you elaborate? > > > > Sven>> Hm, I may have jumped to conclusions here (I am > afraid I have a > > history of MPLS traffic engineering work). What I meant is > > that we cannot > > rely on 'normal layer 3 routing' to make the reservation on > > the 'future > > path'. I suppose any policy-based routing mechanism will work. > > > > > - if yes, whether this is a functionality that should be > > supported by the > > > NSLP. > > Hmmm, this may be another of those pesky "between the layers" > > things. Why > > should this have to be invented separately for QoS, > > NAT/Firewall, or other > > NSLPs? > > > > Sven>> In my opinion, if we choose to support this kind of > > functionality, > > it should be requested by the NSLP over the API but > > implemented at the NTLP > > (at least for case 1a). For case 1b, I think it becomes a > > different matter > > because you need the NSLP to be detect its future peer (at > the risk of > > being blasphemous I would say you need a peer discovery > mechanism that > > allows you to search on future paths). One thing that may > > alleviate the > > problem is that it is likely (in C-mode) that a QNE already has a > > connection to the future peer (because it was a peer for other > > destinations) > > > > > One aspect to consider here is what make-before-break scenario you > > > would like to support: > > > a. reserve on a diverse path between two peer QNEs: > this would > > > require GIMPS to support explicit routing and the API to > support the > > > request for "diverse-route-protect". Do we want this? > > Supporting disjoint path constraints, all other things being > > equal, is a > > good idea. In fact, it might be a good idea to think > through a way to > > express a variety of constraints since disjoint path is > only one of a > > number of possibilities. I do believe that disjoint path as a > > constraint > > does require at least route recording, and possibly explicit > > routing (in > > the sense of pre-computed and source routed). One thing to > > consider here is > > if this gets into the nether world of backing NSIS into a > complete QoS > > routing protocol which will make PNNI look like a walk in the park. > > > > Sven>> I don't know if the GIMPS designers want to go there. > > > > > b. reserve on a diverse path bypassing the peer QNE > > > (make-before-break in case of QNE failure): this requires a > > way for the > > > QoS NSLP to figure out a future peer QNE and a way to ask > > GIMPS to set up > > > a connection to it (API issue). Do we want this? > > > > > Won't this happen correctly as a side effect of next-hop > > selection? If not, > > then there's something about the architecture I must misunderstand. > > > > Sven>> I think the next-hop selection will automatically find > > the new next > > hop but only after a while. So this mechanism will not allow > > making the > > reservation in advance at the new next hop QNE. > > > > > 2. Keep the data on the old path while the reservation on > > the new path is > > > being set up: this requires route pinning but it doesn't > seem to put > > > additional requirements on either NTLP or NSLP (only on the > > forwarding > > > function in the data plane): NSIS signalling always follows > > the current > > L3 > > > route. However, it only helps when a better route becomes > > available, not > > > when the current one fails. > > > > > Right - that's one reason I don't think we can retain the > > single-path model > > of routing that NSIS assumes today. > > > > NSIS needs access to the RIBs as well as the FIBs, it seems, > > unless the > > routing system puts alternate path info in the FIB along with > > the active > > path info. Again, striking a bblance between just managing > > resources on the > > single best path that routing tells NSIS about and diving > > full depth into > > QoS routing is going to be an interesting juggling act. > > > > Sven>> I know of one proposal (I think it was > > draft-walton-...) where a > > suggestion was made to extend BGP reachability with alternate > > paths (well > > reachability information technically I guess). At the time > > there were also > > some individual drafts on BGP extension for QoS routing. Is > > any of this > > still alive? > > > > Not to mention keeping C-mode and D-mode straight and having a good > > interface for D-mode that allows NSIS to express forwarding > > constraints to > > the routing layer... > > > > Dave. > > > > > Cheers, > > > Sven > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 21 07:45:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13665 for ; Wed, 21 Apr 2004 07:45:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGG7F-0002HT-5q for nsis-archive@odin.ietf.org; Wed, 21 Apr 2004 07:42:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LBg9Cs008752 for nsis-archive@odin.ietf.org; Wed, 21 Apr 2004 07:42:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGG1K-00007F-Cy; Wed, 21 Apr 2004 07:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGFwI-0006vJ-Qg for nsis@optimus.ietf.org; Wed, 21 Apr 2004 07:30:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12885 for ; Wed, 21 Apr 2004 07:30:49 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGFwI-0002wI-6V for nsis@ietf.org; Wed, 21 Apr 2004 07:30:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGFvT-0002pF-00 for nsis@ietf.org; Wed, 21 Apr 2004 07:30:00 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGFv5-0002hI-00 for nsis@ietf.org; Wed, 21 Apr 2004 07:29:35 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LBTXd06048 for ; Wed, 21 Apr 2004 14:29:33 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 14:29:11 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3LBTBGx017818 for ; Wed, 21 Apr 2004 14:29:11 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00XzjLkz; Wed, 21 Apr 2004 14:29:09 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LBSqs25139 for ; Wed, 21 Apr 2004 14:28:52 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 14:28:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2004 14:28:30 +0300 Message-ID: Thread-Topic: Results of the early reviews Thread-Index: AcQnk8W/PMEeaMibR+uHF7RieuEvBw== To: X-OriginalArrivalTime: 21 Apr 2004 11:28:30.0867 (UTC) FILETIME=[C5FE4E30:01C42793] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Results of the early reviews Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I'd like to request that the NSIS document editors summarize explicitly = the results of=20 the early reviews from IETF 59. In practice, it would be good to go = point-by-point=20 response to the questions raised in the early reviews. We need to = verify that the issues raised have been responded to. Could the editors give an estimate when they can provide this by? thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 21 08:12:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15649 for ; Wed, 21 Apr 2004 08:12:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGVj-0003Ay-IQ for nsis-archive@odin.ietf.org; Wed, 21 Apr 2004 08:07:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LC7RJr012193 for nsis-archive@odin.ietf.org; Wed, 21 Apr 2004 08:07:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGRQ-0001aK-Vl; Wed, 21 Apr 2004 08:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGKW-0006sa-JB for nsis@optimus.ietf.org; Wed, 21 Apr 2004 07:55:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14233 for ; Wed, 21 Apr 2004 07:55:50 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGGKV-0006VC-J6 for nsis@ietf.org; Wed, 21 Apr 2004 07:55:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGGJY-0006MC-00 for nsis@ietf.org; Wed, 21 Apr 2004 07:54:52 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BGGJF-0006F9-00 for nsis@ietf.org; Wed, 21 Apr 2004 07:54:33 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LBsF426253; Wed, 21 Apr 2004 14:54:15 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 14:54:12 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3LBsCf8005047; Wed, 21 Apr 2004 14:54:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00MY827F; Wed, 21 Apr 2004 14:54:11 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LBs9F08552; Wed, 21 Apr 2004 14:54:09 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 14:53:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2004 14:53:48 +0300 Message-ID: Thread-Topic: [NSIS] Security Threats for NSIS : Combining Signaling and SA Establishm ent Thread-Index: AcQi/t5P5PW/d829RhiSI7gIb9rZcgBZpzmAAMxgRyA= To: , , X-OriginalArrivalTime: 21 Apr 2004 11:53:49.0119 (UTC) FILETIME=[4EF12CF0:01C42797] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Input to the Threats & Security Properities document Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I have been discussing with our ADs about progressing the Threats = documents. In summary, we need to get it completed as soon as possible. Security threats should be presented clearly and provide an answer to = Steve's question on the Framework. =20 Framework can point to the threats document. If we cannot provide = complete answers to Steve's questions, then we should point out that they are hard problems which = need solving. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 21 10:14:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23602 for ; Wed, 21 Apr 2004 10:14:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGIO4-0004s3-NI for nsis-archive@odin.ietf.org; Wed, 21 Apr 2004 10:07:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LE7evY018699 for nsis-archive@odin.ietf.org; Wed, 21 Apr 2004 10:07:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI8x-0004Nk-3k; Wed, 21 Apr 2004 09:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI1B-0000DG-1b for nsis@optimus.ietf.org; Wed, 21 Apr 2004 09:44:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20678 for ; Wed, 21 Apr 2004 09:43:58 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGI19-0000H3-6K for nsis@ietf.org; Wed, 21 Apr 2004 09:43:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGI0A-00007f-00 for nsis@ietf.org; Wed, 21 Apr 2004 09:42:58 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BGHzf-0007mZ-00 for nsis@ietf.org; Wed, 21 Apr 2004 09:42:27 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3LDgOQP029543; Wed, 21 Apr 2004 15:42:24 +0200 Subject: Re: [NSIS] Results of the early reviews To: john.loughney@nokia.com Cc: X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 21 Apr 2004 15:42:23 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/21/2004 15:42:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 propose to provide this information (in a mail) with the release of v3 of the qos-nslp draft. In addition, the change history will refer to early review comments that triggered updates in the document. Would that be OK? Best regards, Sven john.loughney@nokia.com@ietf.org on 21/04/2004 13:28:30 Sent by: nsis-admin@ietf.org To: cc: Subject: [NSIS] Results of the early reviews Hi all, I'd like to request that the NSIS document editors summarize explicitly the results of the early reviews from IETF 59. In practice, it would be good to go point-by-point response to the questions raised in the early reviews. We need to verify that the issues raised have been responded to. Could the editors give an estimate when they can provide this by? 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 exim@www1.ietf.org Wed Apr 21 12:29:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00586 for ; Wed, 21 Apr 2004 12:29:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKJ3-0002yV-TA for nsis-archive@odin.ietf.org; Wed, 21 Apr 2004 12:10:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGAb5m011420 for nsis-archive@odin.ietf.org; Wed, 21 Apr 2004 12:10:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzh-00034t-PM; Wed, 21 Apr 2004 11:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJV6-0000nH-Hf for nsis@optimus.ietf.org; Wed, 21 Apr 2004 11:19:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27087 for ; Wed, 21 Apr 2004 11:18:58 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJV5-0000TL-K4 for nsis@ietf.org; Wed, 21 Apr 2004 11:18:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJUA-0000KD-00 for nsis@ietf.org; Wed, 21 Apr 2004 11:18:03 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGJTG-0000AV-00 for nsis@ietf.org; Wed, 21 Apr 2004 11:17:06 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LFGxd18155; Wed, 21 Apr 2004 18:16:59 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 18:16:29 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3LFGTr4002500; Wed, 21 Apr 2004 18:16:29 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00DoZqHN; Wed, 21 Apr 2004 18:16:23 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LFGGF24046; Wed, 21 Apr 2004 18:16:16 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 18:15:21 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 18:15:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Results of the early reviews Date: Wed, 21 Apr 2004 18:15:20 +0300 Message-ID: Thread-Topic: [NSIS] Results of the early reviews Thread-Index: AcQnpxjAD/Dk4bz6RaiqH/N+v48mMQAC6OCw To: Cc: X-OriginalArrivalTime: 21 Apr 2004 15:15:21.0378 (UTC) FILETIME=[767D7820:01C427B3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Sven, > I propose to provide this information (in a mail) with the release of = v3 of > the qos-nslp draft. In addition, the change history will refer to = early > review comments that triggered updates in the document. Would=20 > that be OK? As long as you can have a blow-by-blow account of how the comments have = been addressed, that is fine. For example, you could reply to Dave's email = and say point 2 is addressed in section 3.1, paragraph 3 - for example. What is the timeframe for getting the draft out? Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 22 02:23:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04423 for ; Thu, 22 Apr 2004 02:23:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXX9-0005K3-Ja for nsis-archive@odin.ietf.org; Thu, 22 Apr 2004 02:18:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M6I338020442 for nsis-archive@odin.ietf.org; Thu, 22 Apr 2004 02:18:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXSH-00011A-HY; Thu, 22 Apr 2004 02:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXIB-0000nd-6U for nsis@optimus.ietf.org; Thu, 22 Apr 2004 02:02:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22640 for ; Thu, 22 Apr 2004 02:02:32 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGXI7-0000zu-Jv for nsis@ietf.org; Thu, 22 Apr 2004 02:02:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGXH9-0000oB-00 for nsis@ietf.org; Thu, 22 Apr 2004 02:01:31 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BGXG7-0000Qn-00 for nsis@ietf.org; Thu, 22 Apr 2004 02:00:27 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3M60MQP028455; Thu, 22 Apr 2004 08:00:24 +0200 Subject: RE: [NSIS] Results of the early reviews To: Cc: X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 22 Apr 2004 08:00:22 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/22/2004 08:00:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 will do as you suggest. We are currently working on the draft, which is scheduled to be submitted on May 8 (3 weeks before the meeting). Best regards, Sven on 21/04/2004 17:15:20 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: Subject: RE: [NSIS] Results of the early reviews Hi Sven, > I propose to provide this information (in a mail) with the release of v3 of > the qos-nslp draft. In addition, the change history will refer to early > review comments that triggered updates in the document. Would > that be OK? As long as you can have a blow-by-blow account of how the comments have been addressed, that is fine. For example, you could reply to Dave's email and say point 2 is addressed in section 3.1, paragraph 3 - for example. What is the timeframe for getting the draft out? Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 22 04:03:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10467 for ; Thu, 22 Apr 2004 04:03:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGZ7X-0004Al-Qk for nsis-archive@odin.ietf.org; Thu, 22 Apr 2004 03:59:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M7xhoR016024 for nsis-archive@odin.ietf.org; Thu, 22 Apr 2004 03:59:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGZ36-0001t0-7j; Thu, 22 Apr 2004 03:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYv9-0006WC-FH for nsis@optimus.ietf.org; Thu, 22 Apr 2004 03:46:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09638 for ; Thu, 22 Apr 2004 03:46:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGYv5-0000uM-4a for nsis@ietf.org; Thu, 22 Apr 2004 03:46:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGYuB-0000gr-00 for nsis@ietf.org; Thu, 22 Apr 2004 03:45:56 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BGYtg-0000Se-00 for nsis@ietf.org; Thu, 22 Apr 2004 03:45:24 -0400 Received: from ccrle.nec.de (unknown [222.106.49.115]) by ftp.ccrle.nec.de (Postfix) with ESMTP id E009CF674; Thu, 22 Apr 2004 09:50:23 +0200 (CEST) Message-ID: <40877804.1050900@ccrle.nec.de> Date: Thu, 22 Apr 2004 16:45:08 +0900 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org, "McDonald, Andrew" , Georgios Karagiannis Subject: Re: [NSIS] question to the wg on make before break References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 sven.van_den_bosch@alcatel.be wrote: > Hi all, > > During the early review session at the last IETF meeting, we got a question > on the support of make-before-break reservation. The concept of > make-before-break was introduced in RFC3209 (RSVP-TE) as a way to move > traffic to a new LSP before tearing down the old LSP. This essentially > requires one of two situations: > 1. Pre-setup a reservation on a "future path": this requires explicit > routing capability (and a way to figure out the future path). We would like > to request the WG view on: > - whether this should be supported No, it should not be suported. Makes NSIS more complex. You can still implement make-before-break on (application-level) if you like to. So creating a new session before you close the old one. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 22 18:19:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07022 for ; Thu, 22 Apr 2004 18:19:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmFD-0006wZ-2N for nsis-archive@odin.ietf.org; Thu, 22 Apr 2004 18:00:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MM0VMS026687 for nsis-archive@odin.ietf.org; Thu, 22 Apr 2004 18:00:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlw9-0006Ze-9X; Thu, 22 Apr 2004 17:40:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGl6g-0001gS-34 for nsis@optimus.ietf.org; Thu, 22 Apr 2004 16:47:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28637 for ; Thu, 22 Apr 2004 16:47:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGl6b-00061R-JD for nsis@ietf.org; Thu, 22 Apr 2004 16:47:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGl5Q-0005iF-00 for nsis@ietf.org; Thu, 22 Apr 2004 16:46:21 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BGl4T-000593-00 for nsis@ietf.org; Thu, 22 Apr 2004 16:45:22 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Apr 2004 21:44:43 +0100 Message-ID: From: "Hancock, Robert" To: john.loughney@nokia.com, Hannes.Tschofenig@siemens.com, nsis@ietf.org Date: Thu, 22 Apr 2004 21:44:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] RE: Input to the Threats & Security Properities document Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, Steve's comments basically relate to the problem of flooding the processing capabilities of interior nodes with signalling messages. The next threats document will contain a discussion of the flooding problem in some detail (text already posted). The framework notes specifically the necessity of DoS-resistance of the NTLP, and in addition refers (normatively, in fact) to the threats document. There are clearly many things one can do in the protocol development to mitigate this threat. However, I don't believe they can usefully be described in the framework without including a lot of other information about NTLP design options which the framework deliberately leaves open (indeed, in the past there has been strenuous objection from within the WG to including such information). The information should go in the protocol designs. Under these circumstances, I don't at the moment see what should usefully be added in the framework itself. If people think there is stuff to be added, or that the existing stuff could be explained better, please speak up. (There will be an update to address some comprehensibility issues anyway.) cheers, r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, April 21, 2004 13:54 > To: Hannes.Tschofenig@siemens.com; Hancock, Robert; nsis@ietf.org > Subject: Input to the Threats & Security Properities document > > > Hi all, > > I have been discussing with our ADs about progressing the > Threats documents. In summary, we need > to get it completed as soon as possible. > > Security threats should be presented clearly and provide an > answer to Steve's question on the Framework. > Framework can point to the threats document. If we cannot > provide complete answers to Steve's > questions, then we should point out that they are hard > problems which need solving. > > thanks, > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 23 06:50:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27156 for ; Fri, 23 Apr 2004 06:50:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGyDT-0005M2-Tm for nsis-archive@odin.ietf.org; Fri, 23 Apr 2004 06:47:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NAlVlc020567 for nsis-archive@odin.ietf.org; Fri, 23 Apr 2004 06:47:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGy7C-0004CY-SX; Fri, 23 Apr 2004 06:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGy1D-0002VZ-TK for nsis@optimus.ietf.org; Fri, 23 Apr 2004 06:34:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26592 for ; Fri, 23 Apr 2004 06:34:47 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGy17-0006Uj-Rk for nsis@ietf.org; Fri, 23 Apr 2004 06:34:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGy0B-0006FK-00 for nsis@ietf.org; Fri, 23 Apr 2004 06:33:47 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGxzF-0005yp-00 for nsis@ietf.org; Fri, 23 Apr 2004 06:32:49 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NAWpY05671 for ; Fri, 23 Apr 2004 13:32:51 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 13:32:48 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3NAWmKP030735 for ; Fri, 23 Apr 2004 13:32:48 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00tYEGmU; Fri, 23 Apr 2004 13:32:46 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NAWeF03909 for ; Fri, 23 Apr 2004 13:32:40 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 13:31:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Apr 2004 13:31:57 +0300 Message-ID: Thread-Topic: [NSIS] Interim Meeting Logistics Thread-Index: AcQl+6OrF7opaeVGTTCOl8B+4j6NfwDInoWw To: X-OriginalArrivalTime: 23 Apr 2004 10:31:58.0528 (UTC) FILETIME=[34D3F400:01C4291E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Tentative Interim Meeting schedule Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Here is the tentative schedule. Please comment, as I will be looking to officially announce it early next week. John NSIS Interim Meeting June 1st - 3rd, 2004 Location: Roke Manor Research, Romsey UK More information at: http://nsis.srmr.co.uk/interim.html Tentative schedule Tueday June 1st - QoS NSLP=20 - Support for intserv / diffserv models Wednesday June 2rd - NTLP/GIMPS=20 - NAT / FW NSLP Thursday June 3rd (half-day) - Security / AAA - Mobility _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 23 10:31:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11866 for ; Fri, 23 Apr 2004 10:31:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1eJ-0001tN-1R for nsis-archive@odin.ietf.org; Fri, 23 Apr 2004 10:27:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NERR53007258 for nsis-archive@odin.ietf.org; Fri, 23 Apr 2004 10:27:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1XB-0007vq-Bp; Fri, 23 Apr 2004 10:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1RO-0004wL-Qj for nsis@optimus.ietf.org; Fri, 23 Apr 2004 10:14:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10555 for ; Fri, 23 Apr 2004 10:14:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1RL-0003Bk-VI for nsis@ietf.org; Fri, 23 Apr 2004 10:14:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1QR-0002wH-00 for nsis@ietf.org; Fri, 23 Apr 2004 10:13:07 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BH1PR-0002fC-00 for nsis@ietf.org; Fri, 23 Apr 2004 10:12:06 -0400 Received: from [10.2.2.202] (ns3.icafe.spacenet.de [195.30.184.97]) by ftp.ccrle.nec.de (Postfix) with ESMTP id D220EF674; Fri, 23 Apr 2004 16:16:58 +0200 (CEST) Date: Fri, 23 Apr 2004 16:11:47 +0200 From: Martin Stiemerling To: nsis@ietf.org Cc: john.loughney@nokia.com Subject: Re: [NSIS] Results of the early reviews Message-ID: <2147483647.1082736706@[10.2.2.202]> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 NATFW NSLP we haven't received many comment up to now, i.e., only from Alex Zinnin. John has requested the early review team to take another look on the NATFWW NSLP document at this time. Regards, Martin --On Mittwoch, 21. April 2004 14:28 Uhr +0300 john.loughney@nokia.com wrote: | Hi all, | | I'd like to request that the NSIS document editors summarize explicitly | the results of the early reviews from IETF 59. In practice, it would be | good to go point-by-point response to the questions raised in the early | reviews. We need to verify that the issues raised have been responded to. | | Could the editors give an estimate when they can provide this by? | | 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 exim@www1.ietf.org Sat Apr 24 08:17:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11334 for ; Sat, 24 Apr 2004 08:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHM50-0004hB-EY for nsis-archive@odin.ietf.org; Sat, 24 Apr 2004 08:16:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3OCGM05018037 for nsis-archive@odin.ietf.org; Sat, 24 Apr 2004 08:16:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHLyw-00035b-C3; Sat, 24 Apr 2004 08:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHLxn-0002if-Nd for nsis@optimus.ietf.org; Sat, 24 Apr 2004 08:08:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11008 for ; Sat, 24 Apr 2004 08:08:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHLxm-0000ho-Mg for nsis@ietf.org; Sat, 24 Apr 2004 08:08:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHLwn-0000IW-00 for nsis@ietf.org; Sat, 24 Apr 2004 08:07:54 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BHLvf-0007dk-00 for nsis@ietf.org; Sat, 24 Apr 2004 08:06:43 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3OC6cM25901; Sat, 24 Apr 2004 14:06:38 +0200 (MEST) Received: from verena (cert-lnxmlhm1-3.esn.sbs.de [149.246.220.3]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i3OC6bM26375; Sat, 24 Apr 2004 14:06:37 +0200 (MEST) Message-Id: <200404241206.i3OC6bM26375@mail2.siemens.de> From: "Hannes Tschofenig" To: , Date: Sat, 24 Apr 2004 14:09:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQmP9t2xp7QDGmfS0iFI0DDsZvWrQDswROg In-Reply-To: <2147483647.1082385464@[10.32.245.156]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] Early review team question: QoS NSLP + AAA Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 dave, hi all, i have a question regarding two of your comments in your early review team mail http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg03809.html: " - Policy control may involve "envelope resource utilitzation" policy in addition to simple AAA. This means that hard synchronization with the AAA policy state and the NSLP element may be necessary. - Is there a need for explicit teardown invoked by the AAA element? " could you describe what you mean with the first item? is this related to your statement about RADIUS and QoS handling? regarding the second item: i think there is a need for such an explicit teardown invoked by a aaa element. if you have something like a pre-paid card and your credits expire then it might be useful to send a message to the initiator of the qos reservation that the reservation will experience a teardown soon (with an indication of the reason). the aaa server would not directly send a message to the initiator - instead network elements along the path would provide this functionality. preemption might be another reason for a notification sent to the initiator. in certain mobility scenarios it might also be helpful to send a notification to the initiator. as an example consider a mobile network which cannot support the qos reservation anymore . ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Apr 25 04:38:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18239 for ; Sun, 25 Apr 2004 04:38:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHf70-0000q0-5U for nsis-archive@odin.ietf.org; Sun, 25 Apr 2004 04:35:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3P8Zgjs003221 for nsis-archive@odin.ietf.org; Sun, 25 Apr 2004 04:35:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHewk-0006P0-U8; Sun, 25 Apr 2004 04:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHev9-0005dj-HA for nsis@optimus.ietf.org; Sun, 25 Apr 2004 04:23:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17387 for ; Sun, 25 Apr 2004 04:23:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHev6-0005Ov-Qg for nsis@ietf.org; Sun, 25 Apr 2004 04:23:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHeu6-00056k-00 for nsis@ietf.org; Sun, 25 Apr 2004 04:22:23 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BHetJ-0004nH-00 for nsis@ietf.org; Sun, 25 Apr 2004 04:21:33 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Apr 2004 00:33:32 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3P8L2W9006476; Sun, 25 Apr 2004 01:21:03 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOJ86560; Sun, 25 Apr 2004 01:21:01 -0700 (PDT) Date: Sun, 25 Apr 2004 04:20:54 -0400 From: "David R. Oran" To: Hannes Tschofenig , nsis@ietf.org Message-ID: <773B0F68AD3AD4AD78BC2B12@[10.32.245.156]> In-Reply-To: <200404241206.i3OC6bM26375@mail2.siemens.de> References: <200404241206.i3OC6bM26375@mail2.siemens.de> X-Mailer: Mulberry/3.1.3 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========B193313792091EFAF5BA==========" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Re: Early review team question: QoS NSLP + AAA Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --==========B193313792091EFAF5BA========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Saturday, April 24, 2004 2:09 PM +0200 Hannes Tschofenig=20 wrote: > hi dave, > hi all, > > i have a question regarding two of your comments in your early review = team > mail > http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg03809.ht > ml: > Sure. Thanks for asking. > " > - Policy control may involve "envelope resource utilization" policy in > addition to simple AAA. This means that hard synchronization with the AAA > policy state and the NSLP element may be necessary. > - Is there a need for explicit teardown invoked by the AAA element? > " > > could you describe what you mean with the first item? is this related to > your statement about RADIUS and QoS handling? > Well, RADIUS is only one of a number of possible AAA=20 protocols/architectures for enforcing policy on admission control. Others=20 include COPS-RSVP and DIAMETER. My comment relates to having enough state=20 synchronizaton among sources/sinks, network elements, and a policy control=20 element to enforce envelope utilization bounds. The policy server (I prefer = that term in this context to AAA server since it is doing more than=20 statelessly authorizing requests) knows, for any given authenticated=20 source/sink of traffic in its domain of control, the aggregate of resource=20 (bandwidth, public IP addresses, etc.) that source/sink is permitted and=20 keeps track of admission control decisions in order to enforce that upper=20 bound. From the point of view of NSIS, I believe this requires, at a=20 minimum, the kind of "policy object" support found in RSVP. Beyond that, I=20 believe handling pre-authorization state would be useful, as would some=20 form of cut/paste and replay protection on the policy state in the=20 protocol. I know I keep hammering on this, but I believe this is *yet another* of=20 these common protocol elements which reside ABOVE the transport, but BELOW=20 the NLSPs. Having different AAA and resource policy control mechanisms in the=20 different NLSPs strikes me as bad in many ways - performance and=20 consistency among them. > regarding the second item: i think there is a need for such an explicit > teardown invoked by a aaa element. if you have something like a pre-paid > card and your credits expire then it might be useful to send a message to > the initiator of the qos reservation that the reservation will experience > a teardown soon (with an indication of the reason). Yes, I think we agree on this. The exact machinery is probably a creature=20 of the AAA/policy control protocol and not NSIS itself though. I have a=20 personal preference for escrow-based authorization rather than explicit=20 teardown for pre-paid style applications, but there are enough other=20 examples where explicit teardown is useful that the point holds. > the aaa server would > not directly send a message to the initiator - instead network elements > along the path would provide this functionality. also agree. > preemption might be > another reason for a notification sent to the initiator. in certain > mobility scenarios it might also be helpful to send a notification to the > initiator. as an example consider a mobile network which cannot support > the qos reservation anymore . > Sure. I have been working on a scheme for near-optimal handling of=20 preemption events which requires more protocol machinery than simple=20 teardown notification but notification is needed anyway so let's start=20 there. Dave. > ciao > hannes > --==========B193313792091EFAF5BA========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAi3TrjWaEtlTdKuYRAkLGAKCVQpnado6hNtEJA9HcKu29SGtDWwCg1jGM wSOA2rO9liDMNUX7lRnEoro= =2PB0 -----END PGP SIGNATURE----- --==========B193313792091EFAF5BA==========-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 26 02:51:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26751 for ; Mon, 26 Apr 2004 02:51:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzuL-0000EQ-0s for nsis-archive@odin.ietf.org; Mon, 26 Apr 2004 02:48:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q6m0xI000875 for nsis-archive@odin.ietf.org; Mon, 26 Apr 2004 02:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzna-0006zU-8N; Mon, 26 Apr 2004 02:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzlJ-0006FH-9X for nsis@optimus.ietf.org; Mon, 26 Apr 2004 02:38:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25975 for ; Mon, 26 Apr 2004 02:38:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHzlF-0004BL-Ih for nsis@ietf.org; Mon, 26 Apr 2004 02:38:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHzkG-000411-00 for nsis@ietf.org; Mon, 26 Apr 2004 02:37:37 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BHzk9-0003qw-00 for nsis@ietf.org; Mon, 26 Apr 2004 02:37:29 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3Q6bRM00095; Mon, 26 Apr 2004 08:37:27 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i3Q6bRZ04725; Mon, 26 Apr 2004 08:37:27 +0200 (MEST) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id IAA02059; Mon, 26 Apr 2004 08:37:26 +0200 (MET DST) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Apr 2004 08:36:59 +0200 Message-ID: <4D486782CA36D4118A530000D11EA42A02B56C89@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: john.loughney@nokia.com, nsis@ietf.org Subject: AW: [NSIS] Tentative Interim Meeting schedule Date: Mon, 26 Apr 2004 08:36:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi John,=20 would it be possible to exchange NAT FW and Mobility so I can attend = Mobility on Wednesday (I have to leave Wed late afternoon). Best regards, Cornelia > -----Urspr=FCngliche Nachricht----- > Von: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] Im=20 > Auftrag von john.loughney@nokia.com > Gesendet: Freitag, 23. April 2004 12:32 > An: nsis@ietf.org > Betreff: [NSIS] Tentative Interim Meeting schedule >=20 >=20 > Hi all, >=20 > Here is the tentative schedule. Please comment, as I will be=20 > looking to > officially announce it early next week. >=20 > John >=20 > NSIS Interim Meeting > June 1st - 3rd, 2004 > Location: Roke Manor Research, Romsey UK >=20 > More information at: > http://nsis.srmr.co.uk/interim.html >=20 > Tentative schedule >=20 > Tueday June 1st > - QoS NSLP=20 > - Support for intserv / diffserv models >=20 > Wednesday June 2rd >=20 > - NTLP/GIMPS=20 > - NAT / FW NSLP >=20 > Thursday June 3rd (half-day) >=20 > - Security / AAA > - Mobility >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 26 06:13:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08561 for ; Mon, 26 Apr 2004 06:13:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI31c-00050Y-AC for nsis-archive@odin.ietf.org; Mon, 26 Apr 2004 06:07:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QA7i8c019235 for nsis-archive@odin.ietf.org; Mon, 26 Apr 2004 06:07:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2yz-000419-AK; Mon, 26 Apr 2004 06:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2tw-0002sh-73 for nsis@optimus.ietf.org; Mon, 26 Apr 2004 05:59:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07922 for ; Mon, 26 Apr 2004 05:59:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI2ts-0000QF-Gs for nsis@ietf.org; Mon, 26 Apr 2004 05:59:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI2sv-0000Fd-00 for nsis@ietf.org; Mon, 26 Apr 2004 05:58:46 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BI2rz-0007hV-00 for nsis@ietf.org; Mon, 26 Apr 2004 05:57:47 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Apr 2004 10:57:17 +0100 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Tentative Interim Meeting schedule Date: Mon, 26 Apr 2004 10:57:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, minor comment: there is some discussion on whether there are application-generic functionalities outside the transport. the specific item that made me think about this is the 'intserv/diffserv' agenda point: does this include handling mlpp and 2-phase operation? or should it be generalised to qos-models which do this? or should there be an even more wide-ranging discussion? r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, April 23, 2004 11:32 > To: nsis@ietf.org > Subject: [NSIS] Tentative Interim Meeting schedule > > > Hi all, > > Here is the tentative schedule. Please comment, as I will be > looking to > officially announce it early next week. > > John > > NSIS Interim Meeting > June 1st - 3rd, 2004 > Location: Roke Manor Research, Romsey UK > > More information at: > http://nsis.srmr.co.uk/interim.html > > Tentative schedule > > Tueday June 1st > - QoS NSLP > - Support for intserv / diffserv models > > Wednesday June 2rd > > - NTLP/GIMPS > - NAT / FW NSLP > > Thursday June 3rd (half-day) > > - Security / AAA > - Mobility > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 26 06:53:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10361 for ; Mon, 26 Apr 2004 06:53:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI3gF-0007Gw-AZ for nsis-archive@odin.ietf.org; Mon, 26 Apr 2004 06:49:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QAnh8t027940 for nsis-archive@odin.ietf.org; Mon, 26 Apr 2004 06:49:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI3am-00062J-B4; Mon, 26 Apr 2004 06:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI3Yb-0005Lw-FN for nsis@optimus.ietf.org; Mon, 26 Apr 2004 06:41:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09627 for ; Mon, 26 Apr 2004 06:41:44 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI3YX-0001Gy-46 for nsis@ietf.org; Mon, 26 Apr 2004 06:41:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI3XI-0000uT-00 for nsis@ietf.org; Mon, 26 Apr 2004 06:40:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BI3Vr-0000cF-02 for nsis@ietf.org; Mon, 26 Apr 2004 06:38:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BI3Ki-0006Ge-La for nsis@ietf.org; Mon, 26 Apr 2004 06:27:28 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QAROs05409; Mon, 26 Apr 2004 13:27:24 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 13:27:18 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3QARIlY023480; Mon, 26 Apr 2004 13:27:18 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ZrpTWt; Mon, 26 Apr 2004 13:27:17 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QAQnJ10875; Mon, 26 Apr 2004 13:26:55 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 13:25:31 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Tentative Interim Meeting schedule x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Apr 2004 13:25:31 +0300 Message-ID: Thread-Topic: [NSIS] Tentative Interim Meeting schedule Thread-Index: AcQrdq5KCSBT42pRSkemXxgqkUz3NAAACXpQ To: , X-OriginalArrivalTime: 26 Apr 2004 10:25:31.0628 (UTC) FILETIME=[CD74F2C0:01C42B78] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Robert, > minor comment: there is some discussion on whether there are > application-generic functionalities outside the transport. >=20 > the specific item that made me think about this is the > 'intserv/diffserv' agenda point: does this include handling > mlpp and 2-phase operation? or should it be generalised to > qos-models which do this? or should there be an even more > wide-ranging discussion? I think this falls into the general 'intserv/diffserv' discussions wrt what the QoS application supports.=20 My feeling is that NSIS needs to be able to signaling existing IETF QoS models (intserv/diffserv). Dave Oran also made the point in Seoul about RSVP's TSPEC being a 'complete' representation of a=20 QoS model. What I'd like to discuss at the interim meeting with regards to the QoS application is what is needed to support in the Qspec. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Apr 26 13:05:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03010 for ; Mon, 26 Apr 2004 13:05:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9PG-00059j-Jb for nsis-archive@odin.ietf.org; Mon, 26 Apr 2004 12:56:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QGuYxa019810 for nsis-archive@odin.ietf.org; Mon, 26 Apr 2004 12:56:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9C9-00013y-5h; Mon, 26 Apr 2004 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI95e-00075M-Cc for nsis@optimus.ietf.org; Mon, 26 Apr 2004 12:36:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01159 for ; Mon, 26 Apr 2004 12:36:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI95c-0003m8-QY for nsis@ietf.org; Mon, 26 Apr 2004 12:36:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI94a-0003fy-00 for nsis@ietf.org; Mon, 26 Apr 2004 12:35:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BI947-0003bE-00 for nsis@ietf.org; Mon, 26 Apr 2004 12:34:46 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QGY3W9020158; Mon, 26 Apr 2004 09:34:03 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOK29977; Mon, 26 Apr 2004 09:33:59 -0700 (PDT) Date: Mon, 26 Apr 2004 12:33:58 -0400 From: "David R. Oran" To: john.loughney@nokia.com, robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] Tentative Interim Meeting schedule Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.3 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========7F0520279047E88E24D5==========" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --==========7F0520279047E88E24D5========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Monday, April 26, 2004 1:25 PM +0300 john.loughney@nokia.com wrote: > Hi Robert, > >> minor comment: there is some discussion on whether there are >> application-generic functionalities outside the transport. >> >> the specific item that made me think about this is the >> 'intserv/diffserv' agenda point: does this include handling >> mlpp and 2-phase operation? or should it be generalised to >> qos-models which do this? or should there be an even more >> wide-ranging discussion? > I think these things are in fact *orthogonal* to the QoS model and in fact=20 have broader semantics than QoS. My partial list includes: - precedence and preemption - separation of reserve and commit phases - fate sharing - policy control for AAA and envelope resource utilization These all strike me as things which are not really part of the transport,=20 but which are identical or nearly so across NLSPs, and may in fact need=20 explicit coordination across NLSPs. There are also some gray areas: - route recording and explicit routing (this might belong directly in the=20 transport, or between the transport and the NLSPs) - resource sharing (this might not gain much abstracted from the NLSP) > I think this falls into the general 'intserv/diffserv' discussions > wrt what the QoS application supports. > I'm not sure if we're talking about the same thing here. In fact, diffserv=20 is mostly about *not* doing QoS signaling, so I'm already lost when you=20 talk about this being related to NLSP-dependent versus independent=20 functions. > My feeling is that NSIS needs to be able to signaling existing > IETF QoS models (intserv/diffserv). Do we have a rigorous definition of what constitutes a "QoS model"? I think = not...ergo, I have some ramblings below which if nothing else might shed=20 light on how *I* think about this stuff. > Dave Oran also made the point > in Seoul about RSVP's TSPEC being a 'complete' representation of a > QoS model. What I'd like to discuss at the interim meeting with > regards to the QoS application is what is needed to support > in the Qspec. > I think there are multiple dimensions to this: a) how you as a host describe your traffic via the control plane signaling b) how you describe the binding between the described traffic and the=20 packets it applies to, so the data plane can do the right classification c) how a NE describes what it is capable to doing with traffic that arrives d) how a concatenation of NEs describe to a host how they collectively will = treat the traffic when offered. My comment about a TSPEC being a "complete traffic description" applies=20 only to (a). In addition, a TSPEC may be an *overdescription* of the=20 traffic in the sense that if certain properties of the description are not=20 honored, I'm still happy to have the traffic admitted. Things that may=20 violate the stated properties include: - a drop rate > zero - a delay bound higher than some constant K for at least one packet - a delay bound higher than k for some fraction of packets statistically=20 lower than x percent I recall Henning saying in Seoul that what we may really be talking about=20 with QoS models is how to relate the various parameters of a traffic=20 description to the service properties of the various network elements. I=20 agree with this view. Another dimension of the mapping of the traffic description to the service=20 is when you need to map down to classification and scheduling limitations=20 of actual implementations and of various layer 2 QoS mechanics. Just to give one example, assume you have an L2 which has a slotted=20 scheduler (e.g 802.11, DOCSIS). If you can't describe the traffic properly, = you have to do slot size and slot rate allocation which is highly=20 pessimistic. It is really advantageous to be able to tell if the traffic=20 source is CBR with a fixed packetization, because this (common) subcase can = in fact result in optimal resource usage in a slotted L2. So, continuing=20 this example using a TSPEC as the traffic description, you can detect CBR=20 by a TSPEC where (peak rate =3D token bucket rate) and (minimum policed = size=20 =3D burst size). With this you can safely set the slot rate to the token=20 bucket rate and slot size =3D burst size and never miss a scheduled slot=20 (once you achieve initial phase lock on packet arrivals). I think there's a lot of work yet to do on this, and what I've seen so far=20 in the QoS model work doesn't seem to map terribly well onto my=20 understanding of what needs to be done. Continuing on this general theme, what is done today with intserv is that=20 there are only two "QoS models", the controlled load and guaranteed=20 service. The controlled load service is parameter-less; the guaranteed=20 service has a single parameter - the deterministic upper delay bound. If=20 people are saying we need more flexibility than that I won't necessarily=20 disagree, but the work has to have a degree of rigor and not fall into the=20 trap of micro-optimization, where the ATM traffic models have sometimes=20 wound up. Lastly, I do think that the RSVP machinery where all a NE can do to report=20 what it will do with traffic is to reduce the TSPEC envelope it is willing=20 to honor via an ADSPEC is likely inadequate. It does not capture the=20 ability to report service properties as I noted above. It would be nice to=20 have something which could report the actual service properties that a=20 given flow will get if admitted. (Sorry for all the rambling above - if it isn't helpful then just ignore=20 it). Dave. > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --==========7F0520279047E88E24D5========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAjTn3jWaEtlTdKuYRAnGJAJ9Y3lk+vkHqip0I5cD5bqF6lbqYnQCgohVH kAlAoEzJoutSHye0MKappKY= =5Reo -----END PGP SIGNATURE----- --==========7F0520279047E88E24D5==========-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 27 07:50:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24172 for ; Tue, 27 Apr 2004 07:50:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIR3T-00040g-03 for nsis-archive@odin.ietf.org; Tue, 27 Apr 2004 07:47:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RBlEXR015399 for nsis-archive@odin.ietf.org; Tue, 27 Apr 2004 07:47:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQjz-0001Ba-2r; Tue, 27 Apr 2004 07:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQi0-0000ln-Je for nsis@optimus.ietf.org; Tue, 27 Apr 2004 07:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23150 for ; Tue, 27 Apr 2004 07:25:01 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIQhw-0001Uf-5c for nsis@ietf.org; Tue, 27 Apr 2004 07:25:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQhA-0001Hu-00 for nsis@ietf.org; Tue, 27 Apr 2004 07:24:12 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIQgL-000118-00 for nsis@ietf.org; Tue, 27 Apr 2004 07:23:22 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RBN6v24418; Tue, 27 Apr 2004 14:23:06 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 14:21:49 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3RBLntd004358; Tue, 27 Apr 2004 14:21:49 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00NQ7t19; Tue, 27 Apr 2004 14:14:27 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RBEKH17306; Tue, 27 Apr 2004 14:14:20 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 14:14:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Tentative Interim Meeting schedule Date: Tue, 27 Apr 2004 14:14:14 +0300 Message-ID: Thread-Topic: [NSIS] Tentative Interim Meeting schedule Thread-Index: AcQrWr/97NSdlWQoT9q4P8tcDCHNBQA7e75A To: , X-OriginalArrivalTime: 27 Apr 2004 11:14:15.0728 (UTC) FILETIME=[C6C4F300:01C42C48] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Cornelia, > would it be possible to exchange NAT FW and Mobility so I can=20 > attend Mobility on Wednesday (I have to leave Wed late afternoon). Well, right now the NAT & FW work has higher priority, that is why it is scheduled before the mobility, just in case we run short of time. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 27 09:09:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29061 for ; Tue, 27 Apr 2004 09:09:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISGB-0006Bz-GF for nsis-archive@odin.ietf.org; Tue, 27 Apr 2004 09:04:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RD4ROF023798 for nsis-archive@odin.ietf.org; Tue, 27 Apr 2004 09:04:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIS86-00044o-K7; Tue, 27 Apr 2004 08:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIS2O-0002rl-CO for nsis@optimus.ietf.org; Tue, 27 Apr 2004 08:50:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27973 for ; Tue, 27 Apr 2004 08:50:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIS2J-0005gC-0u for nsis@ietf.org; Tue, 27 Apr 2004 08:50:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIS1I-0005S1-00 for nsis@ietf.org; Tue, 27 Apr 2004 08:49:06 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BIS0m-0005EN-00 for nsis@ietf.org; Tue, 27 Apr 2004 08:48:32 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 27 Apr 2004 15:48:33 +0300 Date: Tue, 27 Apr 2004 15:48:31 +0300 (EEST) From: Jukka MJ Manner To: John Loughney , nsis@ietf.org cc: kireeti@juniper.net, adrian@olddog.co.uk Subject: Re: [NSIS] FW: draft-ietf-nsis-signalling-analysis-03.txt In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Dear all, It seems no one has had problems with the proposed change, neither do I have issues with it - it looks good to me. In addition to that change, Allison commented about Section 3 that suggested too heavily to use TCP with RSVP. I think Section 3 has good information, but could be edited a bit in the "message it tries to give". In order to get this item finalized once and for all, I propose the following: 1. Make the change of text as suggested by Adrian in this email 2. Change Section 3 as follows (by removing text that suggests to use TCP with RSVP, this is an analysis draft, not a new spec): a) Remove first sentece of last paragraph in Sec 3.1, starting with "In summary, in trying to introduce..." b) Remove last sentence/paragraph of Sec 3.3 c) Remove last paragraph of Sec 3.5 3. Make minor edits, e.g. check the references I could do these changes as soon as I get an "OK" from the WG, and submit the draft. Would we need a new WG Last Call? Regards, Jukka On Fri, 12 Mar 2004 john.loughney@nokia.com wrote: > Hi all, > > Here is text that I recieved from Kireeti Kompella & Adrian Farrel. > Please review and comment if anyone disagrees. > > thanks! > John > > == forwarded text == > > Here is the text that Adrian had in replacement of sections 2.2.10 > through 2.2.12, with minor mods from me. > > As a whole, this document seems primarily to be more of a "Compendium > of Extensions to RSVP and Other Quality of Service Signaling > Protocols" rather than an Analysis of the same. It is useful as > such, but one might consider a change of title. > > Kireeti. > ------- > > == BEGIN ORIGINAL TEXT == > > 2.2.10. MPLS Traffic Engineering > > RSVP-TE [RFC3209] specifies the extension to RSVP for establishing > explicitly routed LSPs in MPLS networks using RSVP as a signaling > protocol. RSVP-TE is intended for use by label switching routers (as > well as hosts) to establish and maintain LSP-tunnels and to reserve > network resources for such LSP-tunnels. RFC3209 defines a new Hello > message (for rapid node failure detection), new C-Types > (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION (here a session > is implicitly defined as the set of packets that are assigned the > same MPLS label value at the originating node of an LSP-tunnel), > SENDER_TEMPLATE, and FILTER_SPEC objects, and the following 5 new > objects: > > 1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path > messages, encapsulating a concatenation of hops which constitutes > the explicitly routed path. Using this object, the paths taken by > label-switched RSVP-MPLS flows can be pre-determined, independent > of conventional IP routing. > > 2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can > create a Path message with a LABEL_REQUEST object. A node that > sends a LABEL_REQUEST object MUST be ready to accept and correctly > process a LABEL object in the corresponding Resv messages. > > 3) LABEL object. Each node that receives a Resv message containing a > LABEL object uses that label for outgoing traffic associated with > this LSP tunnel. > > 4) SESSION_ATTRIBUTE object, which can be added to Path messages to > aid in session identification and diagnostics. Additional control > information, such as setup and hold priorities, resource > affinities and local-protection, are also included in this object. > > 5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in > both Path and Resv messages. It is used to collect detailed path > information and is useful for loop detection and for diagnostics. > > Section 5 of RFC3270 further specifies the extensions to RSVP to > establish LSPs supporting DiffServ in MPLS networks, introducing a > new DIFFSERV Object (applicable in the Path messages) and using pre- > configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping". > > > 2.2.11. GMPLS RSVP: Provision Optical Networks > > [RFC3473] is developed on top of RSVP-TE. It enables network > operations to provision data-path within optical networks. It > defines a Notify message (for general event notification), which may > contain notifications being sent, with respect to each listed > session, both upstream and downstream. Notify messages can be used > together with Notify Request object for expedited notification of > failures and other events to nodes responsible for restoring failed > LSPs. A Notify message is sent without the router alert option. > Besides, a number of new RSVP-TE (sub)objects are defined in GMPLS > RSVP-TE for general uses of MPLS: (for label management:) > > - a Generalized Label Request Object; > - Bandwidth Encoding carried in SENDER_TSPEC and FLOWSPEC objects, > Generalized Label Object; > - a Waveband Switching Object; > - a Suggested Label Object; > - a Label Set Object; (to support bidirectional LSP setup:) > - an Upstream_Label object; (to support uni- and bi-directional > Explicit Label Control:) > - a Label ERO subobject; > - a Label RRO subobject, which is included in RROs as described in > [RFC3209]; (To Control Channel Separation:) > - IF_ID RSVP_HOP objects (IPv4 & v6); > - IF_ID ERROR_SPEC objects (IPv4 & v6); (to support rapid failure > notification:) > - a Acceptable Label Set object to support Notification on Label > Error; > - a Notify Request object, which may be inserted in Path or Resv > messages to indicate where a notification of LSP failure is to be > sent; (for fault handling:) > - a Restart_Cap Object; (for administrative purposes:) > - an Admin Status Object, which is used to notify each node along the > path of the status of the LSP. > > Since RSVP-TE does not provide a way to indicate an unnumbered link > in its Explicit Route and Record Route Objects, [KoRe03] specifies > extensions to RSVP-TE to support (point-to-point) unnumbered links, > namely, > > - an Unnumbered Interface ID Subobject, which is a new subobject of > the Explicit Route Object (ERO) used to specify unnumbered links; > - an LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to > form or use an identifier for the Forwarding Adjacency; > - a new subobject of the Record Route Object, used to record that the > LSP path traversed an unnumbered link. > > > 2.2.12. GMPLS Interworking with ITU and OIF > > [LiPe02] proposes additional extensions to GMPLS RSVP-TE to support > the capabilities of an Automatically Switched Optical Network (ASON, > an architecture developed by ITU-T SG15). To support Soft Permanent > Connection (SPC), it uses GENERALIZED_UNI object defined by [OIF- > UNI-1.0] but introduces a new subtype: SPC_LABEL. In addition, a Call > identifier (CALL_ID) object is used in logical call/connection > separation, which are used together with a new Call capability > (CALL_OPS) object for complete call/connection separation. Besides > new error codes, 3 new C-types are defined for the SESSION object: > UNI_IPv6 SESSION, ENNI_IPv4 SESSION and ENNI_IPv6 SESSION. > > Optical Internetworking Forum (OIF) UNI 1.0 signaling ([OIF-UNI-1.0]) > supports [RFC2205, RFC2961, RFC3209, Berg03] in a limited way. 10 > types of RSVP(-TE) messages are supported, but used in a slightly > different way. For example, only FF style is supported; States are > always deleted explicitly; a state timer expiration will not deleted > the state, rather triggers a tear down message; any RSVP message must > be dropped silently when fails security validation. Besides new > error codes, a few new (sub)objects are introduced, including > [Berg03]: > > - a new C-type for ACCEPTABLE_LABEL_SET; > - a new C-type for ADMIN_STATUS; > - a new C-type for LABEL_SET; > - a new C-type for RECOVER_LABEL; > - a new C-type for RESTART_CAP; > - a new C-type for UPSTEAM_LABEL; > - a UNI_IPv4_SESSION object, combined with > LSP_TUNNEL_IPv4_SENDER_TEMPLATE object to uniquely identify a > connection at a local UNI; > - a GENERALIZED_LABEL_REQUEST object; > - a GENERALIZED_UNI_ATTRIBUTES object, which contains one or more new > SOURCE_TNA, DESTINATION_TNA, DIVERSITY, EGRESS_LABEL, SERVICE_LEVEL > subobjects. EGRESS_LABEL can be used to specify either uni- or > bi-directional connections; > - a SONET/SDH_SENDER_TSPEC object. > > == END ORIGINAL TEXT == > > > == BEGIN NEW TEXT == > > 2.2.10. MPLS Traffic Engineering > > RSVP-TE [RFC3209] specifies the core extensions to RSVP for > establishing constraint-based explicitly routed LSPs in MPLS networks > using RSVP as a signaling protocol. RSVP-TE is intended for use by > label switching routers (as well as hosts) to establish and maintain > LSP-tunnels and to reserve network resources for such LSP-tunnels. > > RFC3209 defines a new Hello message (for rapid node failure > detection). > > RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and > LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC > objects. Here a session is the association of LSPs that support the > LSP-tunnel. The traffic on an LSP can be classified as the set of > packets that are assigned the same MPLS label value at the > originating node of an LSP-tunnel. > > The following 5 new objects are also defined. > > 1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path > messages, encapsulating a concatenation of hops which constitutes > the explicitly routed path. Using this object, the paths taken by > label-switched RSVP-MPLS flows can be pre-determined, independent > of conventional IP routing. > > 2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can > create a Path message with a LABEL_REQUEST object. A node that > sends a LABEL_REQUEST object MUST be ready to accept and correctly > process a LABEL object in the corresponding Resv messages. > > 3) LABEL object. Each node that receives a Resv message containing a > LABEL object uses that label for outgoing traffic associated with > this LSP tunnel. > > 4) SESSION_ATTRIBUTE object, which can be added to Path messages to > aid in session identification and diagnostics. Additional control > information, such as setup and holding priorities, resource > affinities and local-protection, are also included in this object. > > 5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in > both Path and Resv messages. It is used to collect detailed path > information and is useful for loop detection and for diagnostics. > > Section 5 of [RFC3270] further specifies the extensions to RSVP to > establish LSPs supporting DiffServ in MPLS networks, introducing a > new DIFFSERV Object (applicable in the Path messages) and using pre- > configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping". > > RSVP-TE provides a way to indicate an unnumbered link in its Explicit > Route and Record Route Objects through [RFC3477]. This specifies the > following extensions. > > - An Unnumbered Interface ID Subobject, which is a subobject of the > Explicit Route Object (ERO) used to specify unnumbered links; > - An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to > form or use an identifier for an unnumbered Forwarding Adjacency; > - A new subobject of the Record Route Object, used to record that the > LSP path traversed an unnumbered link. > > 2.2.11. GMPLS RSVP: Provisioning for Multiple Switching Types > > GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE. It enables the > provisioning of data-paths within networks supporting a variety of > switching types including packet and cell switching networks, layer > two networks, TDM networks and photonic networks. > > It defines the new Notify message (for general event notification), > which may contain notifications being sent, with respect to each > listed LSP, both upstream and downstream. Notify messages can be used > for expedited notification of failures and other events to nodes > responsible for restoring failed LSPs. A Notify message is sent > without the router alert option. > > A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for > general uses of MPLS: > > - a Generalized Label Request Object; > - a Generalized Label Object; > - a Suggested Label Object; > - a Label Set Object; (to restrict label choice) > - an Upstream_Label object; (to support bi-directional LSPs) > - a Label ERO subobject; > - IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in > out of band signaling or in bundled links); > - IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify interfaces in > out of band signaling or in bundled links); > - an Acceptable Label Set object (to support negotiation of label > values in particular for bidirecitonal LSPs) > - a Notify Request object (may be inserted in a Path or Resv message > to indicate to where a notification of LSP failure is to be sent) > - a Restart_Cap Object (used on Hello messages to identify recovery > capabilities) > - an Admin Status Object (to notify each node along the path of the > status of the LSP, and to control that state). > > 2.2.12. GMPLS Operation at UNI and E-NNI Reference Points > > The ITU-T defines nework reference points that separate > administrative or operational parts of the network. The reference > points are designated as: > - User to Network Interfaces (UNIs) if they lie between the user > or user network and the core network. > - External Network to Network Interfaces (E-NNIs) if they lie > between peer networks, network domains, or subnetworks. > > GMPLS is applicable to the UNI and E-NNI without further > modification, and no new messages, objects or C-Types are required. > See [OVERLAY]. > > 2.2.13. MPLS and GMPLS Future Extensions > > At the time of writing MPLS and GMPLS are being extended by the MPLS > and CCAMP Working Groups to support additional sophisticated > functions. This will inevitably lead to the introduction of new > C-Types for existing objects, and to the requirement for new objects > (CNums). It is possible that new messages will also be introduced. > > Some of the key features and functions being introduced include: > > - Protection and restoration. Features will be developed to provide > - end-to-end protection > - segment protection > - various protection schemes (1+1, 1:1, 1:n) > - support of extra traffic on backup LSPs > - Diverse path establishment for protection and load sharing > - Point-to-mulitpoint path establishment > - Inter-area and inter-AS path establishment > - with explicit path control > - with bandwidth reservation > - with path diversity > - Support for the requirements of ASON signaling as defined by the > ITU-T, including call and connection separation > - Crankback during LSP setup. > > > Additional references > > [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered > Links in Resource Reservation Protocol - Traffic > Engineering (RSVP-TE)", RFC 3477, January 2003. > > [OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and > Rekhter, Y., "GMPLS UNI: RSVP Support for the > Overlay Model", draft-ietf-ccamp-gmpls-overlay- > 03.txt, February 2004, work in progress. > > > == END NEW TEXT == > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 27 10:02:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01606 for ; Tue, 27 Apr 2004 10:02:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISw3-00056M-7G for nsis-archive@odin.ietf.org; Tue, 27 Apr 2004 09:47:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RDlhCP019604 for nsis-archive@odin.ietf.org; Tue, 27 Apr 2004 09:47:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIStS-0004VP-KL; Tue, 27 Apr 2004 09:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISl1-0002h1-6D for nsis@optimus.ietf.org; Tue, 27 Apr 2004 09:36:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00315 for ; Tue, 27 Apr 2004 09:36:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISkv-0007g1-Fq for nsis@ietf.org; Tue, 27 Apr 2004 09:36:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISjl-0007bk-00 for nsis@ietf.org; Tue, 27 Apr 2004 09:35:03 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BISj6-0007Yy-00 for nsis@ietf.org; Tue, 27 Apr 2004 09:34:20 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3RDY6M00490; Tue, 27 Apr 2004 15:34:06 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i3RDY5M17626; Tue, 27 Apr 2004 15:34:05 +0200 (MEST) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA10944; Tue, 27 Apr 2004 15:34:04 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Apr 2004 15:33:35 +0200 Message-ID: <4D486782CA36D4118A530000D11EA42A022C7D7E@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'David R. Oran'" , john.loughney@nokia.com, HANCOCK ROBERT , nsis@ietf.org Subject: AW: [NSIS] Tentative Interim Meeting schedule Date: Tue, 27 Apr 2004 15:33:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Dave,=20 in this reply I summarize the current state of discussion in the group = of people trying to write an ID on QSpec template (mostly Jerry Ash, = Attila Bader and myself). So this is QSpec and not actual QoS Model = work. I also have inline comments. By nature of the work we are currently doing we cannot say whether = other NSLPs besides QoS NSLP are in need of reserve/commit, priority = etc. I would assume so, it would be very interesting to hear comments = from the NAT people.=20 The goal of the QSpec is defining a _generic set of parameters_ for use = for authors of QSpecs. The QSpec contains both QoS Description and = Control Information. The token bucket is one example of such a generic = parameter. Another examples are priority of a flow or reserve/commit = functionality.=20 Now there is the interesting issue whether all QNEs MUST (or SHOULD) be = able to understand these generic parameters. We came to the conclusion = this is going to far. It is, for starters, sufficient to give QSpec = developers a common language so they can at least understand each other = and possibly translate QSpecs, e.g. at domain borders. So generic = parameters SHOULD be used if applicable. QSpec authors are however free = to define their own additional parameters if need be. The other interesting issue is where functionality such as priority and = reserve/commit is located. There are two somewhat contradictory = guidelines:=20 (i) locate it as far down the NSIS "layer model" (NTLP - NSLP - (QoS) = Models) as necessary to make it accessible to all functionality who may = have need to use it. This also _may_ easy coordination among NSLPs = (Although I am not sure whether e.g. locating reserve/commit in e.g. a = "common NSLP layer" (which we dont have yet and presumably never will = have) would help coordinating reserve/commit for resource reservation = and pinhole-opening for the same flow. Prerequisite is some way of = coordinating session identifiers, or at least associating different = NSLP sessions with each other, which we do not have yet either).=20 (ii) locating it where it makes sense regarding the processing. E.g. = for the priority information we figure it needs to be processed in the = Resource Mangement Function (RMF) (see Fig 1 of QoS NSLP), because it = is the RMF that knows resources are scarce, and who needs to consult = priority information and find out what to do. So prio information is = best stored in the RMF and therefore best located in the QSpec. The solution we propose (at least for QoS NSLP it is a solution. It = does not help with NAT) that we make our generic "Priority" parameter a = "SHOULD use" - and one may even think making it a "SHOULD implement in = QNEs". So even if some QoS Models dont need it, its implementation and = processing would be uniform across QoS Models. More inline. > -----Urspr=FCngliche Nachricht----- > Von: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] Im=20 > Auftrag von David R. Oran > Gesendet: Montag, 26. April 2004 18:34 > An: john.loughney@nokia.com; robert.hancock@roke.co.uk; nsis@ietf.org > Betreff: RE: [NSIS] Tentative Interim Meeting schedule >=20 >=20 >=20 >=20 > --On Monday, April 26, 2004 1:25 PM +0300=20 > john.loughney@nokia.com wrote: >=20 > > Hi Robert, > > > >> minor comment: there is some discussion on whether there are > >> application-generic functionalities outside the transport. > >> > >> the specific item that made me think about this is the > >> 'intserv/diffserv' agenda point: does this include handling > >> mlpp and 2-phase operation? or should it be generalised to > >> qos-models which do this? or should there be an even more > >> wide-ranging discussion? > > > I think these things are in fact *orthogonal* to the QoS=20 > model and in fact=20 > have broader semantics than QoS. My partial list includes: > - precedence and preemption > - separation of reserve and commit phases > - fate sharing > - policy control for AAA and envelope resource utilization >=20 > These all strike me as things which are not really part of=20 > the transport,=20 > but which are identical or nearly so across NLSPs, and may in=20 > fact need=20 > explicit coordination across NLSPs. >=20 > There are also some gray areas: > - route recording and explicit routing (this might belong=20 > directly in the=20 > transport, or between the transport and the NLSPs) > - resource sharing (this might not gain much abstracted from the = NLSP) >=20 > > I think this falls into the general 'intserv/diffserv' discussions > > wrt what the QoS application supports. > > > I'm not sure if we're talking about the same thing here. In=20 > fact, diffserv=20 > is mostly about *not* doing QoS signaling, so I'm already=20 > lost when you=20 > talk about this being related to NLSP-dependent versus independent=20 > functions. Cornelia:=20 One could think of using NSIS to signal to edge nodes of DiffServ = domains that they should reserve that many resources for a specific = PHB. >=20 > > My feeling is that NSIS needs to be able to signaling existing > > IETF QoS models (intserv/diffserv). > Do we have a rigorous definition of what constitutes a "QoS=20 > model"? I think=20 > not...ergo, I have some ramblings below which if nothing else=20 > might shed=20 > light on how *I* think about this stuff. >=20 >=20 > > Dave Oran also made the point > > in Seoul about RSVP's TSPEC being a 'complete' representation of a > > QoS model. What I'd like to discuss at the interim meeting with > > regards to the QoS application is what is needed to support > > in the Qspec. > > > I think there are multiple dimensions to this: > a) how you as a host describe your traffic via the control=20 > plane signaling > b) how you describe the binding between the described traffic and the = > packets it applies to, so the data plane can do the right=20 > classification > c) how a NE describes what it is capable to doing with=20 > traffic that arrives > d) how a concatenation of NEs describe to a host how they=20 > collectively will=20 > treat the traffic when offered. Cornelia: Actually we are addressing these different dimensions in the QSpec ID = (Except (b) which is part of the NSIS flow ID) >=20 > My comment about a TSPEC being a "complete traffic=20 > description" applies=20 > only to (a). In addition, a TSPEC may be an *overdescription* of the=20 > traffic in the sense that if certain properties of the=20 > description are not=20 > honored, I'm still happy to have the traffic admitted. Things=20 > that may=20 > violate the stated properties include: > - a drop rate > zero > - a delay bound higher than some constant K for at least one packet > - a delay bound higher than k for some fraction of packets=20 > statistically=20 > lower than x percent Cornelia: We QSpec people think that if the token bucket and whatever other = generic parameters we offer are not sufficient for what you want to = signal you can define your own parameters (for the domain you are = responsible for). We are careful to define too many parameters. Details = need to be discussed. >=20 > I recall Henning saying in Seoul that what we may really be=20 > talking about=20 > with QoS models is how to relate the various parameters of a traffic=20 > description to the service properties of the various network=20 > elements. I=20 > agree with this view. Cornelia:=20 I think a QoS Model (or: QoS Signaling Model) should describe how the = QSpec parameters relate to the underlying QoS Architecture or = provisioning model. This is why we need guidelines for QoS Models (to = make clear how to do this), and possibly some QoS Model examples. = However I think work on concrete mapping of traffic description to = network element handling quickly gets beyond the nsis charter. >=20 > Another dimension of the mapping of the traffic description=20 > to the service=20 > is when you need to map down to classification and scheduling=20 > limitations=20 > of actual implementations and of various layer 2 QoS mechanics. >=20 > Just to give one example, assume you have an L2 which has a slotted=20 > scheduler (e.g 802.11, DOCSIS). If you can't describe the=20 > traffic properly,=20 > you have to do slot size and slot rate allocation which is highly=20 > pessimistic. It is really advantageous to be able to tell if=20 > the traffic=20 > source is CBR with a fixed packetization, because this=20 > (common) subcase can=20 > in fact result in optimal resource usage in a slotted L2. So,=20 > continuing=20 > this example using a TSPEC as the traffic description, you=20 > can detect CBR=20 > by a TSPEC where (peak rate =3D token bucket rate) and (minimum=20 > policed size=20 > =3D burst size). With this you can safely set the slot rate to=20 > the token=20 > bucket rate and slot size =3D burst size and never miss a=20 > scheduled slot=20 > (once you achieve initial phase lock on packet arrivals). >=20 > I think there's a lot of work yet to do on this, and what=20 > I've seen so far=20 > in the QoS model work doesn't seem to map terribly well onto my=20 > understanding of what needs to be done. Cornelia:=20 Even if this needs to be done, in my view it is (beyond may be = examples, see above) not nsis business. >=20 > Continuing on this general theme, what is done today with=20 > intserv is that=20 > there are only two "QoS models", the controlled load and guaranteed=20 > service. The controlled load service is parameter-less; the=20 > guaranteed=20 > service has a single parameter - the deterministic upper=20 > delay bound. If=20 > people are saying we need more flexibility than that I won't=20 > necessarily=20 > disagree, but the work has to have a degree of rigor and not=20 > fall into the=20 > trap of micro-optimization, where the ATM traffic models have=20 > sometimes=20 > wound up. >=20 > Lastly, I do think that the RSVP machinery where all a NE can=20 > do to report=20 > what it will do with traffic is to reduce the TSPEC envelope=20 > it is willing=20 > to honor via an ADSPEC is likely inadequate. It does not capture the=20 > ability to report service properties as I noted above. It=20 > would be nice to=20 > have something which could report the actual service=20 > properties that a=20 > given flow will get if admitted. >=20 > (Sorry for all the rambling above - if it isn't helpful then=20 > just ignore=20 > it). >=20 > Dave. > > thanks, > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Apr 27 12:02:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09172 for ; Tue, 27 Apr 2004 12:02:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUxV-0002Rr-0t for nsis-archive@odin.ietf.org; Tue, 27 Apr 2004 11:57:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RFvKQw009407 for nsis-archive@odin.ietf.org; Tue, 27 Apr 2004 11:57:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUkh-000841-0Z; Tue, 27 Apr 2004 11:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUZu-0004mx-VE for nsis@optimus.ietf.org; Tue, 27 Apr 2004 11:32:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07525 for ; Tue, 27 Apr 2004 11:32:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUZr-00067t-Oj for nsis@ietf.org; Tue, 27 Apr 2004 11:32:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUZ1-00065S-00 for nsis@ietf.org; Tue, 27 Apr 2004 11:32:04 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BIUYM-0005yl-00 for nsis@ietf.org; Tue, 27 Apr 2004 11:31:22 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Apr 2004 16:30:51 +0100 Message-ID: From: "Hancock, Robert" To: "'Jukka MJ Manner'" , John Loughney , nsis@ietf.org Cc: kireeti@juniper.net, adrian@olddog.co.uk Subject: RE: [NSIS] FW: draft-ietf-nsis-signalling-analysis-03.txt Date: Tue, 27 Apr 2004 16:30:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , jukka, on your point (2a) it would seem to make more sense to remove the whole of the final paragraph (the rest doesn't make much sense without the first sentence, and in the other sections you've removed the whole equivalent paragraph). i'd be happy with these changes. in each case, either it's obvious from the preceding discussion that the functionality is similar to what is in standard transport protocols or it isn't; saying so explicitly doesn't add anything, and saying that re-using the standard transport protocols is the right design approach is not appropriate in this document anyway. r. > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Tuesday, April 27, 2004 13:49 > To: John Loughney; nsis@ietf.org > Cc: kireeti@juniper.net; adrian@olddog.co.uk > Subject: Re: [NSIS] FW: draft-ietf-nsis-signalling-analysis-03.txt > > > > Dear all, > > It seems no one has had problems with the proposed change, > neither do I > have issues with it - it looks good to me. > > In addition to that change, Allison commented about Section 3 that > suggested too heavily to use TCP with RSVP. I think Section 3 > has good > information, but could be edited a bit in the "message it > tries to give". > > In order to get this item finalized once and for all, I propose the > following: > > 1. Make the change of text as suggested by Adrian in this email > > 2. Change Section 3 as follows (by removing text that > suggests to use TCP > with RSVP, this is an analysis draft, not a new spec): > > a) Remove first sentece of last paragraph in Sec 3.1, > starting with "In > summary, in trying to introduce..." > > b) Remove last sentence/paragraph of Sec 3.3 > > c) Remove last paragraph of Sec 3.5 > > 3. Make minor edits, e.g. check the references > > I could do these changes as soon as I get an "OK" from the > WG, and submit > the draft. Would we need a new WG Last Call? > > Regards, > Jukka > > On Fri, 12 Mar 2004 john.loughney@nokia.com wrote: > > > Hi all, > > > > Here is text that I recieved from Kireeti Kompella & Adrian Farrel. > > Please review and comment if anyone disagrees. > > > > thanks! > > John > > > > == forwarded text == > > > > Here is the text that Adrian had in replacement of sections 2.2.10 > > through 2.2.12, with minor mods from me. > > > > As a whole, this document seems primarily to be more of a > "Compendium > > of Extensions to RSVP and Other Quality of Service Signaling > > Protocols" rather than an Analysis of the same. It is useful as > > such, but one might consider a change of title. > > > > Kireeti. > > ------- > > > > == BEGIN ORIGINAL TEXT == > > > > 2.2.10. MPLS Traffic Engineering > > > > RSVP-TE [RFC3209] specifies the extension to RSVP for > establishing > > explicitly routed LSPs in MPLS networks using RSVP as a signaling > > protocol. RSVP-TE is intended for use by label switching > routers (as > > well as hosts) to establish and maintain LSP-tunnels and > to reserve > > network resources for such LSP-tunnels. RFC3209 defines > a new Hello > > message (for rapid node failure detection), new C-Types > > (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION > (here a session > > is implicitly defined as the set of packets that are assigned the > > same MPLS label value at the originating node of an LSP-tunnel), > > SENDER_TEMPLATE, and FILTER_SPEC objects, and the following 5 new > > objects: > > > > 1) EXPLICIT_ROUTE object (ERO), which is incorporated > into RSVP Path > > messages, encapsulating a concatenation of hops which > constitutes > > the explicitly routed path. Using this object, the > paths taken by > > label-switched RSVP-MPLS flows can be pre-determined, > independent > > of conventional IP routing. > > > > 2) LABEL_REQUEST object. To establish an LSP tunnel, the > sender can > > create a Path message with a LABEL_REQUEST object. A node that > > sends a LABEL_REQUEST object MUST be ready to accept > and correctly > > process a LABEL object in the corresponding Resv messages. > > > > 3) LABEL object. Each node that receives a Resv message > containing a > > LABEL object uses that label for outgoing traffic > associated with > > this LSP tunnel. > > > > 4) SESSION_ATTRIBUTE object, which can be added to Path > messages to > > aid in session identification and diagnostics. > Additional control > > information, such as setup and hold priorities, resource > > affinities and local-protection, are also included in > this object. > > > > 5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object > may appear in > > both Path and Resv messages. It is used to collect > detailed path > > information and is useful for loop detection and for > diagnostics. > > > > Section 5 of RFC3270 further specifies the extensions to RSVP to > > establish LSPs supporting DiffServ in MPLS networks, > introducing a > > new DIFFSERV Object (applicable in the Path messages) > and using pre- > > configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping". > > > > > > 2.2.11. GMPLS RSVP: Provision Optical Networks > > > > [RFC3473] is developed on top of RSVP-TE. It enables network > > operations to provision data-path within optical networks. It > > defines a Notify message (for general event > notification), which may > > contain notifications being sent, with respect to each listed > > session, both upstream and downstream. Notify messages > can be used > > together with Notify Request object for expedited notification of > > failures and other events to nodes responsible for > restoring failed > > LSPs. A Notify message is sent without the router alert option. > > Besides, a number of new RSVP-TE (sub)objects are > defined in GMPLS > > RSVP-TE for general uses of MPLS: (for label management:) > > > > - a Generalized Label Request Object; > > - Bandwidth Encoding carried in SENDER_TSPEC and > FLOWSPEC objects, > > Generalized Label Object; > > - a Waveband Switching Object; > > - a Suggested Label Object; > > - a Label Set Object; (to support bidirectional LSP setup:) > > - an Upstream_Label object; (to support uni- and bi-directional > > Explicit Label Control:) > > - a Label ERO subobject; > > - a Label RRO subobject, which is included in RROs as > described in > > [RFC3209]; (To Control Channel Separation:) > > - IF_ID RSVP_HOP objects (IPv4 & v6); > > - IF_ID ERROR_SPEC objects (IPv4 & v6); (to support rapid failure > > notification:) > > - a Acceptable Label Set object to support Notification on Label > > Error; > > - a Notify Request object, which may be inserted in Path or Resv > > messages to indicate where a notification of LSP > failure is to be > > sent; (for fault handling:) > > - a Restart_Cap Object; (for administrative purposes:) > > - an Admin Status Object, which is used to notify each > node along the > > path of the status of the LSP. > > > > Since RSVP-TE does not provide a way to indicate an > unnumbered link > > in its Explicit Route and Record Route Objects, [KoRe03] > specifies > > extensions to RSVP-TE to support (point-to-point) > unnumbered links, > > namely, > > > > - an Unnumbered Interface ID Subobject, which is a new > subobject of > > the Explicit Route Object (ERO) used to specify > unnumbered links; > > - an LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to > > form or use an identifier for the Forwarding Adjacency; > > - a new subobject of the Record Route Object, used to > record that the > > LSP path traversed an unnumbered link. > > > > > > 2.2.12. GMPLS Interworking with ITU and OIF > > > > [LiPe02] proposes additional extensions to GMPLS RSVP-TE > to support > > the capabilities of an Automatically Switched Optical > Network (ASON, > > an architecture developed by ITU-T SG15). To support > Soft Permanent > > Connection (SPC), it uses GENERALIZED_UNI object defined by [OIF- > > UNI-1.0] but introduces a new subtype: SPC_LABEL. In > addition, a Call > > identifier (CALL_ID) object is used in logical call/connection > > separation, which are used together with a new Call capability > > (CALL_OPS) object for complete call/connection > separation. Besides > > new error codes, 3 new C-types are defined for the > SESSION object: > > UNI_IPv6 SESSION, ENNI_IPv4 SESSION and ENNI_IPv6 SESSION. > > > > Optical Internetworking Forum (OIF) UNI 1.0 signaling > ([OIF-UNI-1.0]) > > supports [RFC2205, RFC2961, RFC3209, Berg03] in a limited way. 10 > > types of RSVP(-TE) messages are supported, but used in a slightly > > different way. For example, only FF style is supported; > States are > > always deleted explicitly; a state timer expiration will > not deleted > > the state, rather triggers a tear down message; any RSVP > message must > > be dropped silently when fails security validation. Besides new > > error codes, a few new (sub)objects are introduced, including > > [Berg03]: > > > > - a new C-type for ACCEPTABLE_LABEL_SET; > > - a new C-type for ADMIN_STATUS; > > - a new C-type for LABEL_SET; > > - a new C-type for RECOVER_LABEL; > > - a new C-type for RESTART_CAP; > > - a new C-type for UPSTEAM_LABEL; > > - a UNI_IPv4_SESSION object, combined with > > LSP_TUNNEL_IPv4_SENDER_TEMPLATE object to uniquely identify a > > connection at a local UNI; > > - a GENERALIZED_LABEL_REQUEST object; > > - a GENERALIZED_UNI_ATTRIBUTES object, which contains > one or more new > > SOURCE_TNA, DESTINATION_TNA, DIVERSITY, EGRESS_LABEL, > SERVICE_LEVEL > > subobjects. EGRESS_LABEL can be used to specify either uni- or > > bi-directional connections; > > - a SONET/SDH_SENDER_TSPEC object. > > > > == END ORIGINAL TEXT == > > > > > > == BEGIN NEW TEXT == > > > > 2.2.10. MPLS Traffic Engineering > > > > RSVP-TE [RFC3209] specifies the core extensions to RSVP for > > establishing constraint-based explicitly routed LSPs in > MPLS networks > > using RSVP as a signaling protocol. RSVP-TE is intended > for use by > > label switching routers (as well as hosts) to establish > and maintain > > LSP-tunnels and to reserve network resources for such > LSP-tunnels. > > > > RFC3209 defines a new Hello message (for rapid node failure > > detection). > > > > RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and > > LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and > FILTER_SPEC > > objects. Here a session is the association of LSPs that > support the > > LSP-tunnel. The traffic on an LSP can be classified as the set of > > packets that are assigned the same MPLS label value at the > > originating node of an LSP-tunnel. > > > > The following 5 new objects are also defined. > > > > 1) EXPLICIT_ROUTE object (ERO), which is incorporated > into RSVP Path > > messages, encapsulating a concatenation of hops which > constitutes > > the explicitly routed path. Using this object, the > paths taken by > > label-switched RSVP-MPLS flows can be pre-determined, > independent > > of conventional IP routing. > > > > 2) LABEL_REQUEST object. To establish an LSP tunnel, the > sender can > > create a Path message with a LABEL_REQUEST object. A node that > > sends a LABEL_REQUEST object MUST be ready to accept > and correctly > > process a LABEL object in the corresponding Resv messages. > > > > 3) LABEL object. Each node that receives a Resv message > containing a > > LABEL object uses that label for outgoing traffic > associated with > > this LSP tunnel. > > > > 4) SESSION_ATTRIBUTE object, which can be added to Path > messages to > > aid in session identification and diagnostics. > Additional control > > information, such as setup and holding priorities, resource > > affinities and local-protection, are also included in > this object. > > > > 5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object > may appear in > > both Path and Resv messages. It is used to collect > detailed path > > information and is useful for loop detection and for > diagnostics. > > > > Section 5 of [RFC3270] further specifies the extensions > to RSVP to > > establish LSPs supporting DiffServ in MPLS networks, > introducing a > > new DIFFSERV Object (applicable in the Path messages) > and using pre- > > configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping". > > > > RSVP-TE provides a way to indicate an unnumbered link in > its Explicit > > Route and Record Route Objects through [RFC3477]. This > specifies the > > following extensions. > > > > - An Unnumbered Interface ID Subobject, which is a > subobject of the > > Explicit Route Object (ERO) used to specify unnumbered links; > > - An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to > > form or use an identifier for an unnumbered Forwarding > Adjacency; > > - A new subobject of the Record Route Object, used to > record that the > > LSP path traversed an unnumbered link. > > > > 2.2.11. GMPLS RSVP: Provisioning for Multiple Switching Types > > > > GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE. It > enables the > > provisioning of data-paths within networks supporting a > variety of > > switching types including packet and cell switching > networks, layer > > two networks, TDM networks and photonic networks. > > > > It defines the new Notify message (for general event > notification), > > which may contain notifications being sent, with respect to each > > listed LSP, both upstream and downstream. Notify > messages can be used > > for expedited notification of failures and other events to nodes > > responsible for restoring failed LSPs. A Notify message is sent > > without the router alert option. > > > > A number of new RSVP-TE (sub)objects are defined in > GMPLS RSVP-TE for > > general uses of MPLS: > > > > - a Generalized Label Request Object; > > - a Generalized Label Object; > > - a Suggested Label Object; > > - a Label Set Object; (to restrict label choice) > > - an Upstream_Label object; (to support bi-directional LSPs) > > - a Label ERO subobject; > > - IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in > > out of band signaling or in bundled links); > > - IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify > interfaces in > > out of band signaling or in bundled links); > > - an Acceptable Label Set object (to support negotiation of label > > values in particular for bidirecitonal LSPs) > > - a Notify Request object (may be inserted in a Path or > Resv message > > to indicate to where a notification of LSP failure is > to be sent) > > - a Restart_Cap Object (used on Hello messages to > identify recovery > > capabilities) > > - an Admin Status Object (to notify each node along the > path of the > > status of the LSP, and to control that state). > > > > 2.2.12. GMPLS Operation at UNI and E-NNI Reference Points > > > > The ITU-T defines nework reference points that separate > > administrative or operational parts of the network. The reference > > points are designated as: > > - User to Network Interfaces (UNIs) if they lie between the user > > or user network and the core network. > > - External Network to Network Interfaces (E-NNIs) if they lie > > between peer networks, network domains, or subnetworks. > > > > GMPLS is applicable to the UNI and E-NNI without further > > modification, and no new messages, objects or C-Types > are required. > > See [OVERLAY]. > > > > 2.2.13. MPLS and GMPLS Future Extensions > > > > At the time of writing MPLS and GMPLS are being extended > by the MPLS > > and CCAMP Working Groups to support additional sophisticated > > functions. This will inevitably lead to the introduction of new > > C-Types for existing objects, and to the requirement for > new objects > > (CNums). It is possible that new messages will also be > introduced. > > > > Some of the key features and functions being introduced include: > > > > - Protection and restoration. Features will be developed > to provide > > - end-to-end protection > > - segment protection > > - various protection schemes (1+1, 1:1, 1:n) > > - support of extra traffic on backup LSPs > > - Diverse path establishment for protection and load sharing > > - Point-to-mulitpoint path establishment > > - Inter-area and inter-AS path establishment > > - with explicit path control > > - with bandwidth reservation > > - with path diversity > > - Support for the requirements of ASON signaling as > defined by the > > ITU-T, including call and connection separation > > - Crankback during LSP setup. > > > > > > Additional references > > > > [RFC3477] Kompella, K. and Y. Rekhter, > "Signalling Unnumbered > > Links in Resource Reservation Protocol - Traffic > > Engineering (RSVP-TE)", RFC 3477, January 2003. > > > > [OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and > > Rekhter, Y., "GMPLS UNI: RSVP Support for the > > Overlay Model", draft-ietf-ccamp-gmpls-overlay- > > 03.txt, February 2004, work in progress. > > > > > > == END NEW TEXT == > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 28 08:13:13 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10405 for ; Wed, 28 Apr 2004 08:13:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInUD-00011E-0y for nsis-archive@odin.ietf.org; Wed, 28 Apr 2004 07:44:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SBiK5r003916 for nsis-archive@odin.ietf.org; Wed, 28 Apr 2004 07:44:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInME-0007cT-Vb; Wed, 28 Apr 2004 07:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIiJ9-0004IQ-99 for nsis@optimus.ietf.org; Wed, 28 Apr 2004 02:12:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10803 for ; Wed, 28 Apr 2004 02:12:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIiJ3-0005S8-MF for nsis@ietf.org; Wed, 28 Apr 2004 02:12:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIiI5-0005GE-00 for nsis@ietf.org; Wed, 28 Apr 2004 02:11:31 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BIiHC-00054q-00 for nsis@ietf.org; Wed, 28 Apr 2004 02:10:34 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 28 Apr 2004 09:10:36 +0300 Date: Wed, 28 Apr 2004 09:10:36 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] FW: draft-ietf-nsis-signalling-analysis-03.txt In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Agreed. Jukka On Tue, 27 Apr 2004, Hancock, Robert wrote: > jukka, > > on your point (2a) it would seem to make more sense to remove > the whole of the final paragraph (the rest doesn't make much > sense without the first sentence, and in the other sections > you've removed the whole equivalent paragraph). > > i'd be happy with these changes. in each case, either it's > obvious from the preceding discussion that the functionality > is similar to what is in standard transport protocols or it > isn't; saying so explicitly doesn't add anything, and saying > that re-using the standard transport protocols is the right > design approach is not appropriate in this document anyway. > > r. > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: Tuesday, April 27, 2004 13:49 > > To: John Loughney; nsis@ietf.org > > Cc: kireeti@juniper.net; adrian@olddog.co.uk > > Subject: Re: [NSIS] FW: draft-ietf-nsis-signalling-analysis-03.txt > > > > > > > > Dear all, > > > > It seems no one has had problems with the proposed change, > > neither do I > > have issues with it - it looks good to me. > > > > In addition to that change, Allison commented about Section 3 that > > suggested too heavily to use TCP with RSVP. I think Section 3 > > has good > > information, but could be edited a bit in the "message it > > tries to give". > > > > In order to get this item finalized once and for all, I propose the > > following: > > > > 1. Make the change of text as suggested by Adrian in this email > > > > 2. Change Section 3 as follows (by removing text that > > suggests to use TCP > > with RSVP, this is an analysis draft, not a new spec): > > > > a) Remove first sentece of last paragraph in Sec 3.1, > > starting with "In > > summary, in trying to introduce..." > > > > b) Remove last sentence/paragraph of Sec 3.3 > > > > c) Remove last paragraph of Sec 3.5 > > > > 3. Make minor edits, e.g. check the references > > > > I could do these changes as soon as I get an "OK" from the > > WG, and submit > > the draft. Would we need a new WG Last Call? > > > > Regards, > > Jukka > > > > On Fri, 12 Mar 2004 john.loughney@nokia.com wrote: > > > > > Hi all, > > > > > > Here is text that I recieved from Kireeti Kompella & Adrian Farrel. > > > Please review and comment if anyone disagrees. > > > > > > thanks! > > > John > > > > > > == forwarded text == > > > > > > Here is the text that Adrian had in replacement of sections 2.2.10 > > > through 2.2.12, with minor mods from me. > > > > > > As a whole, this document seems primarily to be more of a > > "Compendium > > > of Extensions to RSVP and Other Quality of Service Signaling > > > Protocols" rather than an Analysis of the same. It is useful as > > > such, but one might consider a change of title. > > > > > > Kireeti. > > > ------- > > > > > > == BEGIN ORIGINAL TEXT == > > > > > > 2.2.10. MPLS Traffic Engineering > > > > > > RSVP-TE [RFC3209] specifies the extension to RSVP for > > establishing > > > explicitly routed LSPs in MPLS networks using RSVP as a signaling > > > protocol. RSVP-TE is intended for use by label switching > > routers (as > > > well as hosts) to establish and maintain LSP-tunnels and > > to reserve > > > network resources for such LSP-tunnels. RFC3209 defines > > a new Hello > > > message (for rapid node failure detection), new C-Types > > > (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION > > (here a session > > > is implicitly defined as the set of packets that are assigned the > > > same MPLS label value at the originating node of an LSP-tunnel), > > > SENDER_TEMPLATE, and FILTER_SPEC objects, and the following 5 new > > > objects: > > > > > > 1) EXPLICIT_ROUTE object (ERO), which is incorporated > > into RSVP Path > > > messages, encapsulating a concatenation of hops which > > constitutes > > > the explicitly routed path. Using this object, the > > paths taken by > > > label-switched RSVP-MPLS flows can be pre-determined, > > independent > > > of conventional IP routing. > > > > > > 2) LABEL_REQUEST object. To establish an LSP tunnel, the > > sender can > > > create a Path message with a LABEL_REQUEST object. A node that > > > sends a LABEL_REQUEST object MUST be ready to accept > > and correctly > > > process a LABEL object in the corresponding Resv messages. > > > > > > 3) LABEL object. Each node that receives a Resv message > > containing a > > > LABEL object uses that label for outgoing traffic > > associated with > > > this LSP tunnel. > > > > > > 4) SESSION_ATTRIBUTE object, which can be added to Path > > messages to > > > aid in session identification and diagnostics. > > Additional control > > > information, such as setup and hold priorities, resource > > > affinities and local-protection, are also included in > > this object. > > > > > > 5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object > > may appear in > > > both Path and Resv messages. It is used to collect > > detailed path > > > information and is useful for loop detection and for > > diagnostics. > > > > > > Section 5 of RFC3270 further specifies the extensions to RSVP to > > > establish LSPs supporting DiffServ in MPLS networks, > > introducing a > > > new DIFFSERV Object (applicable in the Path messages) > > and using pre- > > > configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping". > > > > > > > > > 2.2.11. GMPLS RSVP: Provision Optical Networks > > > > > > [RFC3473] is developed on top of RSVP-TE. It enables network > > > operations to provision data-path within optical networks. It > > > defines a Notify message (for general event > > notification), which may > > > contain notifications being sent, with respect to each listed > > > session, both upstream and downstream. Notify messages > > can be used > > > together with Notify Request object for expedited notification of > > > failures and other events to nodes responsible for > > restoring failed > > > LSPs. A Notify message is sent without the router alert option. > > > Besides, a number of new RSVP-TE (sub)objects are > > defined in GMPLS > > > RSVP-TE for general uses of MPLS: (for label management:) > > > > > > - a Generalized Label Request Object; > > > - Bandwidth Encoding carried in SENDER_TSPEC and > > FLOWSPEC objects, > > > Generalized Label Object; > > > - a Waveband Switching Object; > > > - a Suggested Label Object; > > > - a Label Set Object; (to support bidirectional LSP setup:) > > > - an Upstream_Label object; (to support uni- and bi-directional > > > Explicit Label Control:) > > > - a Label ERO subobject; > > > - a Label RRO subobject, which is included in RROs as > > described in > > > [RFC3209]; (To Control Channel Separation:) > > > - IF_ID RSVP_HOP objects (IPv4 & v6); > > > - IF_ID ERROR_SPEC objects (IPv4 & v6); (to support rapid failure > > > notification:) > > > - a Acceptable Label Set object to support Notification on Label > > > Error; > > > - a Notify Request object, which may be inserted in Path or Resv > > > messages to indicate where a notification of LSP > > failure is to be > > > sent; (for fault handling:) > > > - a Restart_Cap Object; (for administrative purposes:) > > > - an Admin Status Object, which is used to notify each > > node along the > > > path of the status of the LSP. > > > > > > Since RSVP-TE does not provide a way to indicate an > > unnumbered link > > > in its Explicit Route and Record Route Objects, [KoRe03] > > specifies > > > extensions to RSVP-TE to support (point-to-point) > > unnumbered links, > > > namely, > > > > > > - an Unnumbered Interface ID Subobject, which is a new > > subobject of > > > the Explicit Route Object (ERO) used to specify > > unnumbered links; > > > - an LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to > > > form or use an identifier for the Forwarding Adjacency; > > > - a new subobject of the Record Route Object, used to > > record that the > > > LSP path traversed an unnumbered link. > > > > > > > > > 2.2.12. GMPLS Interworking with ITU and OIF > > > > > > [LiPe02] proposes additional extensions to GMPLS RSVP-TE > > to support > > > the capabilities of an Automatically Switched Optical > > Network (ASON, > > > an architecture developed by ITU-T SG15). To support > > Soft Permanent > > > Connection (SPC), it uses GENERALIZED_UNI object defined by [OIF- > > > UNI-1.0] but introduces a new subtype: SPC_LABEL. In > > addition, a Call > > > identifier (CALL_ID) object is used in logical call/connection > > > separation, which are used together with a new Call capability > > > (CALL_OPS) object for complete call/connection > > separation. Besides > > > new error codes, 3 new C-types are defined for the > > SESSION object: > > > UNI_IPv6 SESSION, ENNI_IPv4 SESSION and ENNI_IPv6 SESSION. > > > > > > Optical Internetworking Forum (OIF) UNI 1.0 signaling > > ([OIF-UNI-1.0]) > > > supports [RFC2205, RFC2961, RFC3209, Berg03] in a limited way. 10 > > > types of RSVP(-TE) messages are supported, but used in a slightly > > > different way. For example, only FF style is supported; > > States are > > > always deleted explicitly; a state timer expiration will > > not deleted > > > the state, rather triggers a tear down message; any RSVP > > message must > > > be dropped silently when fails security validation. Besides new > > > error codes, a few new (sub)objects are introduced, including > > > [Berg03]: > > > > > > - a new C-type for ACCEPTABLE_LABEL_SET; > > > - a new C-type for ADMIN_STATUS; > > > - a new C-type for LABEL_SET; > > > - a new C-type for RECOVER_LABEL; > > > - a new C-type for RESTART_CAP; > > > - a new C-type for UPSTEAM_LABEL; > > > - a UNI_IPv4_SESSION object, combined with > > > LSP_TUNNEL_IPv4_SENDER_TEMPLATE object to uniquely identify a > > > connection at a local UNI; > > > - a GENERALIZED_LABEL_REQUEST object; > > > - a GENERALIZED_UNI_ATTRIBUTES object, which contains > > one or more new > > > SOURCE_TNA, DESTINATION_TNA, DIVERSITY, EGRESS_LABEL, > > SERVICE_LEVEL > > > subobjects. EGRESS_LABEL can be used to specify either uni- or > > > bi-directional connections; > > > - a SONET/SDH_SENDER_TSPEC object. > > > > > > == END ORIGINAL TEXT == > > > > > > > > > == BEGIN NEW TEXT == > > > > > > 2.2.10. MPLS Traffic Engineering > > > > > > RSVP-TE [RFC3209] specifies the core extensions to RSVP for > > > establishing constraint-based explicitly routed LSPs in > > MPLS networks > > > using RSVP as a signaling protocol. RSVP-TE is intended > > for use by > > > label switching routers (as well as hosts) to establish > > and maintain > > > LSP-tunnels and to reserve network resources for such > > LSP-tunnels. > > > > > > RFC3209 defines a new Hello message (for rapid node failure > > > detection). > > > > > > RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and > > > LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and > > FILTER_SPEC > > > objects. Here a session is the association of LSPs that > > support the > > > LSP-tunnel. The traffic on an LSP can be classified as the set of > > > packets that are assigned the same MPLS label value at the > > > originating node of an LSP-tunnel. > > > > > > The following 5 new objects are also defined. > > > > > > 1) EXPLICIT_ROUTE object (ERO), which is incorporated > > into RSVP Path > > > messages, encapsulating a concatenation of hops which > > constitutes > > > the explicitly routed path. Using this object, the > > paths taken by > > > label-switched RSVP-MPLS flows can be pre-determined, > > independent > > > of conventional IP routing. > > > > > > 2) LABEL_REQUEST object. To establish an LSP tunnel, the > > sender can > > > create a Path message with a LABEL_REQUEST object. A node that > > > sends a LABEL_REQUEST object MUST be ready to accept > > and correctly > > > process a LABEL object in the corresponding Resv messages. > > > > > > 3) LABEL object. Each node that receives a Resv message > > containing a > > > LABEL object uses that label for outgoing traffic > > associated with > > > this LSP tunnel. > > > > > > 4) SESSION_ATTRIBUTE object, which can be added to Path > > messages to > > > aid in session identification and diagnostics. > > Additional control > > > information, such as setup and holding priorities, resource > > > affinities and local-protection, are also included in > > this object. > > > > > > 5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object > > may appear in > > > both Path and Resv messages. It is used to collect > > detailed path > > > information and is useful for loop detection and for > > diagnostics. > > > > > > Section 5 of [RFC3270] further specifies the extensions > > to RSVP to > > > establish LSPs supporting DiffServ in MPLS networks, > > introducing a > > > new DIFFSERV Object (applicable in the Path messages) > > and using pre- > > > configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping". > > > > > > RSVP-TE provides a way to indicate an unnumbered link in > > its Explicit > > > Route and Record Route Objects through [RFC3477]. This > > specifies the > > > following extensions. > > > > > > - An Unnumbered Interface ID Subobject, which is a > > subobject of the > > > Explicit Route Object (ERO) used to specify unnumbered links; > > > - An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to > > > form or use an identifier for an unnumbered Forwarding > > Adjacency; > > > - A new subobject of the Record Route Object, used to > > record that the > > > LSP path traversed an unnumbered link. > > > > > > 2.2.11. GMPLS RSVP: Provisioning for Multiple Switching Types > > > > > > GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE. It > > enables the > > > provisioning of data-paths within networks supporting a > > variety of > > > switching types including packet and cell switching > > networks, layer > > > two networks, TDM networks and photonic networks. > > > > > > It defines the new Notify message (for general event > > notification), > > > which may contain notifications being sent, with respect to each > > > listed LSP, both upstream and downstream. Notify > > messages can be used > > > for expedited notification of failures and other events to nodes > > > responsible for restoring failed LSPs. A Notify message is sent > > > without the router alert option. > > > > > > A number of new RSVP-TE (sub)objects are defined in > > GMPLS RSVP-TE for > > > general uses of MPLS: > > > > > > - a Generalized Label Request Object; > > > - a Generalized Label Object; > > > - a Suggested Label Object; > > > - a Label Set Object; (to restrict label choice) > > > - an Upstream_Label object; (to support bi-directional LSPs) > > > - a Label ERO subobject; > > > - IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in > > > out of band signaling or in bundled links); > > > - IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify > > interfaces in > > > out of band signaling or in bundled links); > > > - an Acceptable Label Set object (to support negotiation of label > > > values in particular for bidirecitonal LSPs) > > > - a Notify Request object (may be inserted in a Path or > > Resv message > > > to indicate to where a notification of LSP failure is > > to be sent) > > > - a Restart_Cap Object (used on Hello messages to > > identify recovery > > > capabilities) > > > - an Admin Status Object (to notify each node along the > > path of the > > > status of the LSP, and to control that state). > > > > > > 2.2.12. GMPLS Operation at UNI and E-NNI Reference Points > > > > > > The ITU-T defines nework reference points that separate > > > administrative or operational parts of the network. The reference > > > points are designated as: > > > - User to Network Interfaces (UNIs) if they lie between the user > > > or user network and the core network. > > > - External Network to Network Interfaces (E-NNIs) if they lie > > > between peer networks, network domains, or subnetworks. > > > > > > GMPLS is applicable to the UNI and E-NNI without further > > > modification, and no new messages, objects or C-Types > > are required. > > > See [OVERLAY]. > > > > > > 2.2.13. MPLS and GMPLS Future Extensions > > > > > > At the time of writing MPLS and GMPLS are being extended > > by the MPLS > > > and CCAMP Working Groups to support additional sophisticated > > > functions. This will inevitably lead to the introduction of new > > > C-Types for existing objects, and to the requirement for > > new objects > > > (CNums). It is possible that new messages will also be > > introduced. > > > > > > Some of the key features and functions being introduced include: > > > > > > - Protection and restoration. Features will be developed > > to provide > > > - end-to-end protection > > > - segment protection > > > - various protection schemes (1+1, 1:1, 1:n) > > > - support of extra traffic on backup LSPs > > > - Diverse path establishment for protection and load sharing > > > - Point-to-mulitpoint path establishment > > > - Inter-area and inter-AS path establishment > > > - with explicit path control > > > - with bandwidth reservation > > > - with path diversity > > > - Support for the requirements of ASON signaling as > > defined by the > > > ITU-T, including call and connection separation > > > - Crankback during LSP setup. > > > > > > > > > Additional references > > > > > > [RFC3477] Kompella, K. and Y. Rekhter, > > "Signalling Unnumbered > > > Links in Resource Reservation Protocol - Traffic > > > Engineering (RSVP-TE)", RFC 3477, January 2003. > > > > > > [OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and > > > Rekhter, Y., "GMPLS UNI: RSVP Support for the > > > Overlay Model", draft-ietf-ccamp-gmpls-overlay- > > > 03.txt, February 2004, work in progress. > > > > > > > > > == END NEW TEXT == > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 28 11:45:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22779 for ; Wed, 28 Apr 2004 11:45:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqyA-0001Ek-58 for nsis-archive@odin.ietf.org; Wed, 28 Apr 2004 11:27:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SFRU2n004754 for nsis-archive@odin.ietf.org; Wed, 28 Apr 2004 11:27:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqmN-0007ds-5m; Wed, 28 Apr 2004 11:15:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqHy-0003bi-9O for nsis@optimus.ietf.org; Wed, 28 Apr 2004 10:43:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19325 for ; Wed, 28 Apr 2004 10:43:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqHY-0003PV-Fd for nsis@ietf.org; Wed, 28 Apr 2004 10:43:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqFi-00035B-00 for nsis@ietf.org; Wed, 28 Apr 2004 10:41:35 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BIqDR-0002dW-00 for nsis@ietf.org; Wed, 28 Apr 2004 10:39:13 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3SEdDWR005665 for ; Wed, 28 Apr 2004 16:39:13 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Apr 2004 16:39:13 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Apr 2004 16:39:16 +0200 Message-ID: From: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'David R. Oran'" , john.loughney@nokia.com, robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] Tentative Interim Meeting schedule Date: Wed, 28 Apr 2004 16:19:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 28 Apr 2004 14:39:13.0221 (UTC) FILETIME=[930F3750:01C42D2E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 Dave, Thank you for your comments, they are very useful, we will use them for the QoS model template draft. One comment regarding "diffserv is usually *not* doing QoS signaling": Our QoS model proposal, RMD, uses a lightweight QoS signaling within Diffserv domain for making per-DSCP aggregated reservations within DiffServ routers. So this is something new that we want to do with NSIS. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On > Behalf Of David > R. Oran > Sent: Monday, April 26, 2004 6:34 PM > To: john.loughney@nokia.com; robert.hancock@roke.co.uk; nsis@ietf.org > Subject: RE: [NSIS] Tentative Interim Meeting schedule > > > > > --On Monday, April 26, 2004 1:25 PM +0300 > john.loughney@nokia.com wrote: > > > Hi Robert, > > > >> minor comment: there is some discussion on whether there are > >> application-generic functionalities outside the transport. > >> > >> the specific item that made me think about this is the > >> 'intserv/diffserv' agenda point: does this include handling > >> mlpp and 2-phase operation? or should it be generalised to > >> qos-models which do this? or should there be an even more > >> wide-ranging discussion? > > > I think these things are in fact *orthogonal* to the QoS > model and in fact > have broader semantics than QoS. My partial list includes: > - precedence and preemption > - separation of reserve and commit phases > - fate sharing > - policy control for AAA and envelope resource utilization > > These all strike me as things which are not really part of > the transport, > but which are identical or nearly so across NLSPs, and may in > fact need > explicit coordination across NLSPs. > > There are also some gray areas: > - route recording and explicit routing (this might belong > directly in the > transport, or between the transport and the NLSPs) > - resource sharing (this might not gain much abstracted from the NLSP) > > > I think this falls into the general 'intserv/diffserv' discussions > > wrt what the QoS application supports. > > > I'm not sure if we're talking about the same thing here. In > fact, diffserv > is mostly about *not* doing QoS signaling, so I'm already > lost when you > talk about this being related to NLSP-dependent versus independent > functions. > > > My feeling is that NSIS needs to be able to signaling existing > > IETF QoS models (intserv/diffserv). > Do we have a rigorous definition of what constitutes a "QoS > model"? I think > not...ergo, I have some ramblings below which if nothing else > might shed > light on how *I* think about this stuff. > > > > Dave Oran also made the point > > in Seoul about RSVP's TSPEC being a 'complete' representation of a > > QoS model. What I'd like to discuss at the interim meeting with > > regards to the QoS application is what is needed to support > > in the Qspec. > > > I think there are multiple dimensions to this: > a) how you as a host describe your traffic via the control > plane signaling > b) how you describe the binding between the described traffic and the > packets it applies to, so the data plane can do the right > classification > c) how a NE describes what it is capable to doing with > traffic that arrives > d) how a concatenation of NEs describe to a host how they > collectively will > treat the traffic when offered. > > My comment about a TSPEC being a "complete traffic > description" applies > only to (a). In addition, a TSPEC may be an *overdescription* of the > traffic in the sense that if certain properties of the > description are not > honored, I'm still happy to have the traffic admitted. Things > that may > violate the stated properties include: > - a drop rate > zero > - a delay bound higher than some constant K for at least one packet > - a delay bound higher than k for some fraction of packets > statistically > lower than x percent > > I recall Henning saying in Seoul that what we may really be > talking about > with QoS models is how to relate the various parameters of a traffic > description to the service properties of the various network > elements. I > agree with this view. > > Another dimension of the mapping of the traffic description > to the service > is when you need to map down to classification and scheduling > limitations > of actual implementations and of various layer 2 QoS mechanics. > > Just to give one example, assume you have an L2 which has a slotted > scheduler (e.g 802.11, DOCSIS). If you can't describe the > traffic properly, > you have to do slot size and slot rate allocation which is highly > pessimistic. It is really advantageous to be able to tell if > the traffic > source is CBR with a fixed packetization, because this > (common) subcase can > in fact result in optimal resource usage in a slotted L2. So, > continuing > this example using a TSPEC as the traffic description, you > can detect CBR > by a TSPEC where (peak rate = token bucket rate) and (minimum > policed size > = burst size). With this you can safely set the slot rate to > the token > bucket rate and slot size = burst size and never miss a > scheduled slot > (once you achieve initial phase lock on packet arrivals). > > I think there's a lot of work yet to do on this, and what > I've seen so far > in the QoS model work doesn't seem to map terribly well onto my > understanding of what needs to be done. > > Continuing on this general theme, what is done today with > intserv is that > there are only two "QoS models", the controlled load and guaranteed > service. The controlled load service is parameter-less; the > guaranteed > service has a single parameter - the deterministic upper > delay bound. If > people are saying we need more flexibility than that I won't > necessarily > disagree, but the work has to have a degree of rigor and not > fall into the > trap of micro-optimization, where the ATM traffic models have > sometimes > wound up. > > Lastly, I do think that the RSVP machinery where all a NE can > do to report > what it will do with traffic is to reduce the TSPEC envelope > it is willing > to honor via an ADSPEC is likely inadequate. It does not capture the > ability to report service properties as I noted above. It > would be nice to > have something which could report the actual service > properties that a > given flow will get if admitted. > > (Sorry for all the rambling above - if it isn't helpful then > just ignore > it). > > Dave. > > 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 exim@www1.ietf.org Wed Apr 28 12:30:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26657 for ; Wed, 28 Apr 2004 12:30:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrn0-00088Y-Gi for nsis-archive@odin.ietf.org; Wed, 28 Apr 2004 12:20:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SGK20p031268 for nsis-archive@odin.ietf.org; Wed, 28 Apr 2004 12:20:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrbS-0004Ih-Ud; Wed, 28 Apr 2004 12:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrQE-0001Ns-F7 for nsis@optimus.ietf.org; Wed, 28 Apr 2004 11:56:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23639 for ; Wed, 28 Apr 2004 11:56:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrQB-00029S-Ve for nsis@ietf.org; Wed, 28 Apr 2004 11:56:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrNY-0001dp-00 for nsis@ietf.org; Wed, 28 Apr 2004 11:53:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrLw-0001JL-01 for nsis@ietf.org; Wed, 28 Apr 2004 11:52:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIrHT-0002fZ-80 for nsis@ietf.org; Wed, 28 Apr 2004 11:47:27 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Apr 2004 08:00:01 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3SFkjSu015085; Wed, 28 Apr 2004 08:46:46 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOM11103; Wed, 28 Apr 2004 08:46:43 -0700 (PDT) Date: Wed, 28 Apr 2004 11:46:42 -0400 From: "David R. Oran" To: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ=2FETH=29?= , john.loughney@nokia.com, robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] Tentative Interim Meeting schedule Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.3 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========8CBB7998245055A7AB5A==========" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --==========8CBB7998245055A7AB5A========== Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Wednesday, April 28, 2004 4:19 PM +0200 "Attila B=E1der (IJ/ETH)"=20 wrote: > Hi Dave, > > Thank you for your comments, they are very useful, we will use them for > the QoS model template draft. > > One comment regarding "diffserv is usually *not* doing QoS signaling": > > Our QoS model proposal, RMD, uses a lightweight QoS signaling within > Diffserv domain for making per-DSCP aggregated reservations within > DiffServ routers. So this is something new that we want to do with NSIS. > I don't understand how you do this with a path-coupled signaling protocol.=20 You'd need something which runs over a spanning tree of the entire domain=20 to do this. Ditto for something somebody mentioned earlier in the thread=20 about distributing diffserv class allocations and classification state to=20 all the edge devices of a diffserv domain. I do understand how you can use path-coupled signaling to indicate a given=20 flow is to simply be bound into a particular Diffserv aggregate and to keep = track of committed bandwidth in that aggregate on a particular path. There=20 are some pretty tricky data plane things you need to make this work (e.g.=20 hierarchical policer/shapers), but it can be done. Is this actually what=20 you intend? I also don't quite know what you mean by "lightweight QoS signaling".=20 There's nothing lightweight about NSIS! Are you referring to the admission=20 control decision and the amount of state installed being lightweight?=20 There's a subtle difference between the signaling being lightweight and the = computation and state installed being lightweight. Sorry if I'm confused. I don't want to inject useless noise here. Dave. > Best regards, Attila > >> -----Original Message----- >> From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On >> Behalf Of David >> R. Oran >> Sent: Monday, April 26, 2004 6:34 PM >> To: john.loughney@nokia.com; robert.hancock@roke.co.uk; nsis@ietf.org >> Subject: RE: [NSIS] Tentative Interim Meeting schedule >> >> >> >> >> --On Monday, April 26, 2004 1:25 PM +0300 >> john.loughney@nokia.com wrote: >> >> > Hi Robert, >> > >> >> minor comment: there is some discussion on whether there are >> >> application-generic functionalities outside the transport. >> >> >> >> the specific item that made me think about this is the >> >> 'intserv/diffserv' agenda point: does this include handling >> >> mlpp and 2-phase operation? or should it be generalised to >> >> qos-models which do this? or should there be an even more >> >> wide-ranging discussion? >> > >> I think these things are in fact *orthogonal* to the QoS >> model and in fact >> have broader semantics than QoS. My partial list includes: >> - precedence and preemption >> - separation of reserve and commit phases >> - fate sharing >> - policy control for AAA and envelope resource utilization >> >> These all strike me as things which are not really part of >> the transport, >> but which are identical or nearly so across NLSPs, and may in >> fact need >> explicit coordination across NLSPs. >> >> There are also some gray areas: >> - route recording and explicit routing (this might belong >> directly in the >> transport, or between the transport and the NLSPs) >> - resource sharing (this might not gain much abstracted from the NLSP) >> >> > I think this falls into the general 'intserv/diffserv' discussions >> > wrt what the QoS application supports. >> > >> I'm not sure if we're talking about the same thing here. In >> fact, diffserv >> is mostly about *not* doing QoS signaling, so I'm already >> lost when you >> talk about this being related to NLSP-dependent versus independent >> functions. >> >> > My feeling is that NSIS needs to be able to signaling existing >> > IETF QoS models (intserv/diffserv). >> Do we have a rigorous definition of what constitutes a "QoS >> model"? I think >> not...ergo, I have some ramblings below which if nothing else >> might shed >> light on how *I* think about this stuff. >> >> >> > Dave Oran also made the point >> > in Seoul about RSVP's TSPEC being a 'complete' representation of a >> > QoS model. What I'd like to discuss at the interim meeting with >> > regards to the QoS application is what is needed to support >> > in the Qspec. >> > >> I think there are multiple dimensions to this: >> a) how you as a host describe your traffic via the control >> plane signaling >> b) how you describe the binding between the described traffic and the >> packets it applies to, so the data plane can do the right >> classification >> c) how a NE describes what it is capable to doing with >> traffic that arrives >> d) how a concatenation of NEs describe to a host how they >> collectively will >> treat the traffic when offered. >> >> My comment about a TSPEC being a "complete traffic >> description" applies >> only to (a). In addition, a TSPEC may be an *overdescription* of the >> traffic in the sense that if certain properties of the >> description are not >> honored, I'm still happy to have the traffic admitted. Things >> that may >> violate the stated properties include: >> - a drop rate > zero >> - a delay bound higher than some constant K for at least one packet >> - a delay bound higher than k for some fraction of packets >> statistically >> lower than x percent >> >> I recall Henning saying in Seoul that what we may really be >> talking about >> with QoS models is how to relate the various parameters of a traffic >> description to the service properties of the various network >> elements. I >> agree with this view. >> >> Another dimension of the mapping of the traffic description >> to the service >> is when you need to map down to classification and scheduling >> limitations >> of actual implementations and of various layer 2 QoS mechanics. >> >> Just to give one example, assume you have an L2 which has a slotted >> scheduler (e.g 802.11, DOCSIS). If you can't describe the >> traffic properly, >> you have to do slot size and slot rate allocation which is highly >> pessimistic. It is really advantageous to be able to tell if >> the traffic >> source is CBR with a fixed packetization, because this >> (common) subcase can >> in fact result in optimal resource usage in a slotted L2. So, >> continuing >> this example using a TSPEC as the traffic description, you >> can detect CBR >> by a TSPEC where (peak rate =3D token bucket rate) and (minimum >> policed size >> =3D burst size). With this you can safely set the slot rate to >> the token >> bucket rate and slot size =3D burst size and never miss a >> scheduled slot >> (once you achieve initial phase lock on packet arrivals). >> >> I think there's a lot of work yet to do on this, and what >> I've seen so far >> in the QoS model work doesn't seem to map terribly well onto my >> understanding of what needs to be done. >> >> Continuing on this general theme, what is done today with >> intserv is that >> there are only two "QoS models", the controlled load and guaranteed >> service. The controlled load service is parameter-less; the >> guaranteed >> service has a single parameter - the deterministic upper >> delay bound. If >> people are saying we need more flexibility than that I won't >> necessarily >> disagree, but the work has to have a degree of rigor and not >> fall into the >> trap of micro-optimization, where the ATM traffic models have >> sometimes >> wound up. >> >> Lastly, I do think that the RSVP machinery where all a NE can >> do to report >> what it will do with traffic is to reduce the TSPEC envelope >> it is willing >> to honor via an ADSPEC is likely inadequate. It does not capture the >> ability to report service properties as I noted above. It >> would be nice to >> have something which could report the actual service >> properties that a >> given flow will get if admitted. >> >> (Sorry for all the rambling above - if it isn't helpful then >> just ignore >> it). >> >> Dave. >> > thanks, >> > John >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> --==========8CBB7998245055A7AB5A========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAj9HjjWaEtlTdKuYRAtvVAJwJOoL1ehScaaeLl5aJaWqOkITC+gCgjGf6 k01/D8IftA/q7pZgp5sWDKs= =8KYp -----END PGP SIGNATURE----- --==========8CBB7998245055A7AB5A==========-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 28 13:29:51 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01287 for ; Wed, 28 Apr 2004 13:29:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIseR-0003xL-8c for nsis-archive@odin.ietf.org; Wed, 28 Apr 2004 13:15:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHFFmL015201 for nsis-archive@odin.ietf.org; Wed, 28 Apr 2004 13:15:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsUY-0000uf-Gc; Wed, 28 Apr 2004 13:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsHQ-0006Ow-9R for nsis@optimus.ietf.org; Wed, 28 Apr 2004 12:51:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28208 for ; Wed, 28 Apr 2004 12:51:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsHN-0006Os-7S for nsis@ietf.org; Wed, 28 Apr 2004 12:51:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsGW-0006ML-00 for nsis@ietf.org; Wed, 28 Apr 2004 12:50:33 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BIsFs-0006JV-00 for nsis@ietf.org; Wed, 28 Apr 2004 12:49:52 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3SGnqWR008207 for ; Wed, 28 Apr 2004 18:49:52 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Apr 2004 18:49:52 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Apr 2004 18:49:56 +0200 Message-ID: From: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'David R. Oran'" , john.loughney@nokia.com, robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] Tentative Interim Meeting schedule Date: Wed, 28 Apr 2004 18:49:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 28 Apr 2004 16:49:52.0674 (UTC) FILETIME=[D3BCD020:01C42D40] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Dave,=20 In our concept edge nodes administrate per flow states, interior nodes = only per DSCP states. There are two type of messages: per domain and = intradomain messages. For per domain meassages the next hop is the next = edge router and intention is to use reliable transport for these. = Intradomain messages are transported in datagram mode following the = data path within the domain. They simply add, remove, refresh resource = units for each DSCP in interior nodes, not knowing which flow it = belongs to. In case of e.g. unsuccessful reservation int. node marks = the corresponding field of the reservation message notyfying egress = edge node which have per-flow info and handles the problem.=20 You are right, I understand under simple signaling interior node = functionality, admission control and datagram transport in the domain. Best regards, Attila > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Wednesday, April 28, 2004 5:47 PM > To: Attila B=E1der (IJ/ETH); john.loughney@nokia.com; > robert.hancock@roke.co.uk; nsis@ietf.org > Subject: RE: [NSIS] Tentative Interim Meeting schedule >=20 >=20 > --On Wednesday, April 28, 2004 4:19 PM +0200 "Attila B=E1der = (IJ/ETH)"=20 > wrote: >=20 > > Hi Dave, > > > > Thank you for your comments, they are very useful, we will=20 > use them for > > the QoS model template draft. > > > > One comment regarding "diffserv is usually *not* doing QoS=20 > signaling": > > > > Our QoS model proposal, RMD, uses a lightweight QoS signaling = within > > Diffserv domain for making per-DSCP aggregated reservations within > > DiffServ routers. So this is something new that we want to=20 > do with NSIS. > > > I don't understand how you do this with a path-coupled=20 > signaling protocol.=20 > You'd need something which runs over a spanning tree of the=20 > entire domain=20 > to do this. Ditto for something somebody mentioned earlier in=20 > the thread=20 > about distributing diffserv class allocations and=20 > classification state to=20 > all the edge devices of a diffserv domain. >=20 > I do understand how you can use path-coupled signaling to=20 > indicate a given=20 > flow is to simply be bound into a particular Diffserv=20 > aggregate and to keep=20 > track of committed bandwidth in that aggregate on a=20 > particular path. There=20 > are some pretty tricky data plane things you need to make=20 > this work (e.g.=20 > hierarchical policer/shapers), but it can be done. Is this=20 > actually what=20 > you intend? >=20 > I also don't quite know what you mean by "lightweight QoS signaling". = > There's nothing lightweight about NSIS! Are you referring to=20 > the admission=20 > control decision and the amount of state installed being lightweight? = > There's a subtle difference between the signaling being=20 > lightweight and the=20 > computation and state installed being lightweight. >=20 > Sorry if I'm confused. I don't want to inject useless noise here. >=20 > Dave. >=20 > > Best regards, Attila > > > >> -----Original Message----- > >> From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On > >> Behalf Of David > >> R. Oran > >> Sent: Monday, April 26, 2004 6:34 PM > >> To: john.loughney@nokia.com; robert.hancock@roke.co.uk;=20 > nsis@ietf.org > >> Subject: RE: [NSIS] Tentative Interim Meeting schedule > >> > >> > >> > >> > >> --On Monday, April 26, 2004 1:25 PM +0300 > >> john.loughney@nokia.com wrote: > >> > >> > Hi Robert, > >> > > >> >> minor comment: there is some discussion on whether there are > >> >> application-generic functionalities outside the transport. > >> >> > >> >> the specific item that made me think about this is the > >> >> 'intserv/diffserv' agenda point: does this include handling > >> >> mlpp and 2-phase operation? or should it be generalised to > >> >> qos-models which do this? or should there be an even more > >> >> wide-ranging discussion? > >> > > >> I think these things are in fact *orthogonal* to the QoS > >> model and in fact > >> have broader semantics than QoS. My partial list includes: > >> - precedence and preemption > >> - separation of reserve and commit phases > >> - fate sharing > >> - policy control for AAA and envelope resource utilization > >> > >> These all strike me as things which are not really part of > >> the transport, > >> but which are identical or nearly so across NLSPs, and may in > >> fact need > >> explicit coordination across NLSPs. > >> > >> There are also some gray areas: > >> - route recording and explicit routing (this might belong > >> directly in the > >> transport, or between the transport and the NLSPs) > >> - resource sharing (this might not gain much abstracted=20 > from the NLSP) > >> > >> > I think this falls into the general 'intserv/diffserv'=20 > discussions > >> > wrt what the QoS application supports. > >> > > >> I'm not sure if we're talking about the same thing here. In > >> fact, diffserv > >> is mostly about *not* doing QoS signaling, so I'm already > >> lost when you > >> talk about this being related to NLSP-dependent versus independent > >> functions. > >> > >> > My feeling is that NSIS needs to be able to signaling existing > >> > IETF QoS models (intserv/diffserv). > >> Do we have a rigorous definition of what constitutes a "QoS > >> model"? I think > >> not...ergo, I have some ramblings below which if nothing else > >> might shed > >> light on how *I* think about this stuff. > >> > >> > >> > Dave Oran also made the point > >> > in Seoul about RSVP's TSPEC being a 'complete'=20 > representation of a > >> > QoS model. What I'd like to discuss at the interim meeting with > >> > regards to the QoS application is what is needed to support > >> > in the Qspec. > >> > > >> I think there are multiple dimensions to this: > >> a) how you as a host describe your traffic via the control > >> plane signaling > >> b) how you describe the binding between the described=20 > traffic and the > >> packets it applies to, so the data plane can do the right > >> classification > >> c) how a NE describes what it is capable to doing with > >> traffic that arrives > >> d) how a concatenation of NEs describe to a host how they > >> collectively will > >> treat the traffic when offered. > >> > >> My comment about a TSPEC being a "complete traffic > >> description" applies > >> only to (a). In addition, a TSPEC may be an=20 > *overdescription* of the > >> traffic in the sense that if certain properties of the > >> description are not > >> honored, I'm still happy to have the traffic admitted. Things > >> that may > >> violate the stated properties include: > >> - a drop rate > zero > >> - a delay bound higher than some constant K for at least one = packet > >> - a delay bound higher than k for some fraction of packets > >> statistically > >> lower than x percent > >> > >> I recall Henning saying in Seoul that what we may really be > >> talking about > >> with QoS models is how to relate the various parameters of=20 > a traffic > >> description to the service properties of the various network > >> elements. I > >> agree with this view. > >> > >> Another dimension of the mapping of the traffic description > >> to the service > >> is when you need to map down to classification and scheduling > >> limitations > >> of actual implementations and of various layer 2 QoS mechanics. > >> > >> Just to give one example, assume you have an L2 which has a = slotted > >> scheduler (e.g 802.11, DOCSIS). If you can't describe the > >> traffic properly, > >> you have to do slot size and slot rate allocation which is highly > >> pessimistic. It is really advantageous to be able to tell if > >> the traffic > >> source is CBR with a fixed packetization, because this > >> (common) subcase can > >> in fact result in optimal resource usage in a slotted L2. So, > >> continuing > >> this example using a TSPEC as the traffic description, you > >> can detect CBR > >> by a TSPEC where (peak rate =3D token bucket rate) and (minimum > >> policed size > >> =3D burst size). With this you can safely set the slot rate to > >> the token > >> bucket rate and slot size =3D burst size and never miss a > >> scheduled slot > >> (once you achieve initial phase lock on packet arrivals). > >> > >> I think there's a lot of work yet to do on this, and what > >> I've seen so far > >> in the QoS model work doesn't seem to map terribly well onto my > >> understanding of what needs to be done. > >> > >> Continuing on this general theme, what is done today with > >> intserv is that > >> there are only two "QoS models", the controlled load and = guaranteed > >> service. The controlled load service is parameter-less; the > >> guaranteed > >> service has a single parameter - the deterministic upper > >> delay bound. If > >> people are saying we need more flexibility than that I won't > >> necessarily > >> disagree, but the work has to have a degree of rigor and not > >> fall into the > >> trap of micro-optimization, where the ATM traffic models have > >> sometimes > >> wound up. > >> > >> Lastly, I do think that the RSVP machinery where all a NE can > >> do to report > >> what it will do with traffic is to reduce the TSPEC envelope > >> it is willing > >> to honor via an ADSPEC is likely inadequate. It does not=20 > capture the > >> ability to report service properties as I noted above. It > >> would be nice to > >> have something which could report the actual service > >> properties that a > >> given flow will get if admitted. > >> > >> (Sorry for all the rambling above - if it isn't helpful then > >> just ignore > >> it). > >> > >> Dave. > >> > thanks, > >> > John > >> > > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >> > >> >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Apr 28 13:31:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01408 for ; Wed, 28 Apr 2004 13:31:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsmB-00064q-AU for nsis-archive@odin.ietf.org; Wed, 28 Apr 2004 13:23:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHNFEW023358 for nsis-archive@odin.ietf.org; Wed, 28 Apr 2004 13:23:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsWX-0001jb-C3; Wed, 28 Apr 2004 13:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsPA-0008EE-9x for nsis@optimus.ietf.org; Wed, 28 Apr 2004 12:59:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28641 for ; Wed, 28 Apr 2004 12:59:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsP7-0006oL-7a for nsis@ietf.org; Wed, 28 Apr 2004 12:59:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsOA-0006lv-00 for nsis@ietf.org; Wed, 28 Apr 2004 12:58:26 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BIsNg-0006if-00 for nsis@ietf.org; Wed, 28 Apr 2004 12:57:56 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SGvLW9017273; Wed, 28 Apr 2004 09:57:22 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOM19666; Wed, 28 Apr 2004 09:57:19 -0700 (PDT) Date: Wed, 28 Apr 2004 12:57:18 -0400 From: David Oran To: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ=2FETH=29?= , john.loughney@nokia.com, robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] Tentative Interim Meeting schedule Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable --On Wednesday, April 28, 2004 6:49 PM +0200 "Attila B=E1der (IJ/ETH)"=20 wrote: > Hi Dave, > > In our concept edge nodes administrate per flow states, interior nodes > only per DSCP states. There are two type of messages: per domain and > intradomain messages. For per domain meassages the next hop is the next > edge router and intention is to use reliable transport for these. > Intradomain messages are transported in datagram mode following the data > path within the domain. They simply add, remove, refresh resource units > for each DSCP in interior nodes, not knowing which flow it belongs to. In > case of e.g. unsuccessful reservation int. node marks the corresponding > field of the reservation message notyfying egress edge node which have > per-flow info and handles the problem. > I'd have to ponder this pretty hard to figure out how it's supposed to=20 work. I'll read you spec. One quick question though - how are the domain=20 boundaries determined? This was the hardest part of doing the RSVP=20 aggregation work. > You are right, I understand under simple signaling interior node > functionality, admission control and datagram transport in the domain. > > Best regards, Attila > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 29 04:21:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13158 for ; Thu, 29 Apr 2004 04:21:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6jq-0007dZ-Ls for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 04:17:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T8Hkq5029355 for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 04:17:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6Wj-0003rM-7z; Thu, 29 Apr 2004 04:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6Tb-0002tA-GB for nsis@optimus.ietf.org; Thu, 29 Apr 2004 04:00:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12200 for ; Thu, 29 Apr 2004 04:00:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ6TT-00026r-P8 for nsis@ietf.org; Thu, 29 Apr 2004 04:00:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6SX-0001x4-00 for nsis@ietf.org; Thu, 29 Apr 2004 03:59:54 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1BJ6Ra-0001gq-00 for nsis@ietf.org; Thu, 29 Apr 2004 03:58:54 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id i3T7whCi001745; Thu, 29 Apr 2004 09:58:43 +0200 (MET DST) Message-ID: <00b601c42dbf$cb3220c0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "David Oran" , "=?iso-8859-1?Q?Attila_B=E1der_\=28IJ/ETH\=29?=" , , , References: Subject: Re: [NSIS] Tentative Interim Meeting schedule Date: Thu, 29 Apr 2004 09:58:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by utrhcs.cs.utwente.nl id i3T7whCi001745 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Dave Thank you for showing interest on the concept of using NSIS for signaling Diffserv routers. Regarding the issue on how the domain boundaries are determined we are using the following. The boundaries of a Diffserv domain are known by configuration. Furthermo= re, there might be different ways of selecting, for each flow, the Diffserv ingress and Diffserv egress node= s. One of them is to select, for each flow, the ingress and egress nodes th= at are located in the data path used by the flow. Best regards, Georgios ----- Original Message -----=20 From: "David Oran" To: "Attila B=E1der (IJ/ETH)" ; ; ; Sent: Wednesday, April 28, 2004 6:57 PM Subject: RE: [NSIS] Tentative Interim Meeting schedule > --On Wednesday, April 28, 2004 6:49 PM +0200 "Attila B=E1der (IJ/ETH)" > wrote: > > > Hi Dave, > > > > In our concept edge nodes administrate per flow states, interior node= s > > only per DSCP states. There are two type of messages: per domain and > > intradomain messages. For per domain meassages the next hop is the ne= xt > > edge router and intention is to use reliable transport for these. > > Intradomain messages are transported in datagram mode following the d= ata > > path within the domain. They simply add, remove, refresh resource uni= ts > > for each DSCP in interior nodes, not knowing which flow it belongs to. In > > case of e.g. unsuccessful reservation int. node marks the correspondi= ng > > field of the reservation message notyfying egress edge node which hav= e > > per-flow info and handles the problem. > > > I'd have to ponder this pretty hard to figure out how it's supposed to > work. I'll read you spec. One quick question though - how are the domai= n > boundaries determined? This was the hardest part of doing the RSVP > aggregation work. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 29 04:42:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14156 for ; Thu, 29 Apr 2004 04:42:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ75l-00057o-FQ for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 04:40:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T8ePAK019674 for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 04:40:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6yg-0002hs-NP; Thu, 29 Apr 2004 04:33:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6rs-0001Dr-5d for nsis@optimus.ietf.org; Thu, 29 Apr 2004 04:26:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13356 for ; Thu, 29 Apr 2004 04:25:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ6rk-0006Jk-CM for nsis@ietf.org; Thu, 29 Apr 2004 04:25:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6qt-0006AY-00 for nsis@ietf.org; Thu, 29 Apr 2004 04:25:03 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BJ6qK-0005yt-00 for nsis@ietf.org; Thu, 29 Apr 2004 04:24:28 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Apr 2004 09:23:53 +0100 Message-ID: From: "Hancock, Robert" To: "'David R. Oran'" , john.loughney@nokia.com, nsis@ietf.org Date: Thu, 29 Apr 2004 09:23:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] common signalling application functions (was RE: Tentative Interi m Meeting schedule) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , changed the subject line to match the subject ;-) Dear all, These are some thoughts about how to handle this question of cross-application common functions. We can say that for at least some of the functions in Dave's list below, the impact of the function on the protocol stack is that there is some object to be carried in [some of the] signalling messages which expresses (for example) priority, or the binding between different sessions, or whatever. The current default assumption in NSLP design is that each NSLP spec should define its own objects for all the non-GIMPS functionality that it needs. The worry is that this will lead to a proliferation of nearly similar objects which are processed by different applications in subtly different ways. (I can sympathise with that concern, although I'm not sure it's totally avoidable.) Here is a modified approach: - it should be possible to use a single object definition in multiple applications - the implication is that there should be a single identifier space for NSLP objects (one IANA registry for the T values in the TLV format) - extensibility rules about mandatoriness/optionality will probably have to be common between different applications and encoded separately from the object types - the NSIS (NSLP:TLV object) structure will look quite similar to the Diameter (Application:AVP object) structure. What do people think about this? Supplementary questions would be: where should this sort of structural information be stated; where and how should the common objects be defined; and which people are working on defining them. NOTE: This approach still wouldn't guarantee that, for example, a signalling exchange about NAT and QoS requirements for a specific flow would use the same MLPP values; that coordination would still have to be done between the signalling applications. Indeed, it might not be possible to bind the signalling applications together that tightly, if only because the NAT and QoS processing were taking place on different nodes. Guaranteeing that such binding took place wherever it was logically possible would need non-trivial changes to GIMPS, and I'm not sure that is what is really being asked for. We are just encouraging the applications to use the same language. robert h. > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Monday, April 26, 2004 17:34 > To: john.loughney@nokia.com; Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] Tentative Interim Meeting schedule > > >> minor comment: there is some discussion on whether there are > >> application-generic functionalities outside the transport. > >> > >> the specific item that made me think about this is the > >> 'intserv/diffserv' agenda point: does this include handling > >> mlpp and 2-phase operation? or should it be generalised to > >> qos-models which do this? or should there be an even more > >> wide-ranging discussion? > > > I think these things are in fact *orthogonal* to the QoS > model and in fact > have broader semantics than QoS. My partial list includes: > - precedence and preemption > - separation of reserve and commit phases > - fate sharing > - policy control for AAA and envelope resource utilization > > These all strike me as things which are not really part of > the transport, > but which are identical or nearly so across NLSPs, and may in > fact need > explicit coordination across NLSPs. > > There are also some gray areas: > - route recording and explicit routing (this might belong > directly in the > transport, or between the transport and the NLSPs) > - resource sharing (this might not gain much abstracted from the NLSP) > [snipped stuff about qos definition] _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 29 05:02:20 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14988 for ; Thu, 29 Apr 2004 05:02:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7OW-0000an-3G for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 04:59:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T8xlSN002213 for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 04:59:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7FH-0006v9-Qb; Thu, 29 Apr 2004 04:50:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7DF-0006Xh-Ib for nsis@optimus.ietf.org; Thu, 29 Apr 2004 04:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14385 for ; Thu, 29 Apr 2004 04:48:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ7D7-0002JE-32 for nsis@ietf.org; Thu, 29 Apr 2004 04:48:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ7CD-00029Y-00 for nsis@ietf.org; Thu, 29 Apr 2004 04:47:06 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BJ7Bv-0001zW-00 for nsis@ietf.org; Thu, 29 Apr 2004 04:46:47 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3T8knAh028059 for ; Thu, 29 Apr 2004 10:46:49 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 10:46:49 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Apr 2004 10:46:55 +0200 Message-ID: From: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'Georgios Karagiannis'" , David Oran , john.loughney@nokia.com, robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] Tentative Interim Meeting schedule Date: Thu, 29 Apr 2004 10:46:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 29 Apr 2004 08:46:49.0604 (UTC) FILETIME=[82E50C40:01C42DC6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Dave, Thank you we would be happy to receive comments about RMD.=20 http://www.ietf.org/internet-drafts/draft-bader-rmd-qos-model-00.txt As Georgios said the basic solution for determination of edge nodes is = manual configuration. If GIMPS offered a mechanism for determintion of = aggregaration boundaries I think we could use it also for RMD. Best regards, Attila > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Thursday, April 29, 2004 9:59 AM > To: David Oran; Attila B=E1der (IJ/ETH); john.loughney@nokia.com; > robert.hancock@roke.co.uk; nsis@ietf.org > Subject: Re: [NSIS] Tentative Interim Meeting schedule >=20 >=20 > Hi Dave >=20 > Thank you for showing interest on the concept of using NSIS > for signaling Diffserv routers. Regarding the issue on how the domain > boundaries are > determined we are using the following. >=20 > The boundaries of a Diffserv domain are known by=20 > configuration. Furthermore, > there might be different ways of > selecting, for each flow, the Diffserv ingress and Diffserv=20 > egress nodes. > One of them is to select, for each flow, the ingress and=20 > egress nodes that > are located in the data path > used by the flow. >=20 > Best regards, > Georgios >=20 > ----- Original Message -----=20 > From: "David Oran" > To: "Attila B=E1der (IJ/ETH)" ; > ; ;=20 > > Sent: Wednesday, April 28, 2004 6:57 PM > Subject: RE: [NSIS] Tentative Interim Meeting schedule >=20 >=20 > > --On Wednesday, April 28, 2004 6:49 PM +0200 "Attila B=E1der = (IJ/ETH)" > > wrote: > > > > > Hi Dave, > > > > > > In our concept edge nodes administrate per flow states,=20 > interior nodes > > > only per DSCP states. There are two type of messages: per=20 > domain and > > > intradomain messages. For per domain meassages the next=20 > hop is the next > > > edge router and intention is to use reliable transport for these. > > > Intradomain messages are transported in datagram mode=20 > following the data > > > path within the domain. They simply add, remove, refresh=20 > resource units > > > for each DSCP in interior nodes, not knowing which flow=20 > it belongs to. > In > > > case of e.g. unsuccessful reservation int. node marks the=20 > corresponding > > > field of the reservation message notyfying egress edge=20 > node which have > > > per-flow info and handles the problem. > > > > > I'd have to ponder this pretty hard to figure out how it's=20 > supposed to > > work. I'll read you spec. One quick question though - how=20 > are the domain > > boundaries determined? This was the hardest part of doing the RSVP > > aggregation work. >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 29 05:47:34 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16346 for ; Thu, 29 Apr 2004 05:47:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ84T-0001PL-4N for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 05:43:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T9h9v3005396 for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 05:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7zX-0000G1-0d; Thu, 29 Apr 2004 05:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7p2-00069v-Oz for nsis@optimus.ietf.org; Thu, 29 Apr 2004 05:27:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15887 for ; Thu, 29 Apr 2004 05:27:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ7ou-00018V-CV for nsis@ietf.org; Thu, 29 Apr 2004 05:27:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ7nu-0000y7-00 for nsis@ietf.org; Thu, 29 Apr 2004 05:26:03 -0400 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1BJ7n5-0000f7-00 for nsis@ietf.org; Thu, 29 Apr 2004 05:25:11 -0400 Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Thu, 29 Apr 2004 11:13:30 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Apr 2004 11:13:27 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF699@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] common signalling application functions (was RE: Tenta tive Interi m Meeting schedule) Date: Thu, 29 Apr 2004 11:12:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Robert, |Here is a modified approach: |- it should be possible to use a single object definition | in multiple applications |- the implication is that there should be a single identifier | space for NSLP objects (one IANA registry for the T values=20 | in the TLV format) That's a good idea. |- extensibility rules about mandatoriness/optionality will | probably have to be common between different applications | and encoded separately from the object types This allows to combine different objects as required by a=20 specific NSLP application, right? Then it is a good idea too. |where should this sort of structural information be stated |where and how should the common objects be defined; and which=20 |people are working on defining them. Two approaches come to my mind: - a single toolbox doc containing all basic rules, data=20 formats and parameters ever specified for any NSLP. - NSLP application specs referring to toolbox contents. or - a spec of basic rules and data formats. - NSLPs defining parameters and cross-referencing if one=20 re-uses a parameter of another. The first would be the cleaner approach, but it creates a=20 lot of ongoing maintenance acitivty. The latter better suits=20 to WG's of limited lifetime. It however requires some=20 mechanism to prevent repeated specification of the same=20 feature. If a simple an reliable mechanism to prevent this=20 can be designed, I'd tend to the second approach.=20 Regards, R=FCdiger =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 29 06:10:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17620 for ; Thu, 29 Apr 2004 06:10:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8Qk-0006Sw-Cm for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 06:06:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TA6AmQ024847 for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 06:06:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8Kn-00058k-Nm; Thu, 29 Apr 2004 06:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8AD-0002Yd-N5 for nsis@optimus.ietf.org; Thu, 29 Apr 2004 05:49:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16379 for ; Thu, 29 Apr 2004 05:48:58 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ8A4-0004eI-VJ for nsis@ietf.org; Thu, 29 Apr 2004 05:48:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ897-0004Us-00 for nsis@ietf.org; Thu, 29 Apr 2004 05:47:57 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BJ88b-0004Lk-00 for nsis@ietf.org; Thu, 29 Apr 2004 05:47:25 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3T9lOv05144; Thu, 29 Apr 2004 12:47:24 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 12:47:09 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3T9l9Lr027862; Thu, 29 Apr 2004 12:47:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 003KvNht; Thu, 29 Apr 2004 12:47:09 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3T9l8H29688; Thu, 29 Apr 2004 12:47:08 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 12:47:06 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] common signalling application functions (was RE: Tentative Interi m Meeting schedule) Date: Thu, 29 Apr 2004 12:47:06 +0300 Message-ID: Thread-Topic: [NSIS] common signalling application functions (was RE: Tentative Interi m Meeting schedule) Thread-Index: AcQtzqD8fnwla11zTIKIqizKd2s5ZgAACFzA To: , Cc: X-OriginalArrivalTime: 29 Apr 2004 09:47:06.0399 (UTC) FILETIME=[EEAC2AF0:01C42DCE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Robert & R=FCdiger, Just a general comment: > |Here is a modified approach: > |- it should be possible to use a single object definition > | in multiple applications > |- the implication is that there should be a single identifier > | space for NSLP objects (one IANA registry for the T values=20 > | in the TLV format) >=20 > That's a good idea. >=20 > |- extensibility rules about mandatoriness/optionality will > | probably have to be common between different applications > | and encoded separately from the object types >=20 > This allows to combine different objects as required by a=20 > specific NSLP application, right? Then it is a good idea too. >=20 > |where should this sort of structural information be stated > |where and how should the common objects be defined; and which=20 > |people are working on defining them. >=20 > Two approaches come to my mind: > - a single toolbox doc containing all basic rules, data=20 > formats and parameters ever specified for any NSLP. > - NSLP application specs referring to toolbox contents. >=20 > or > - a spec of basic rules and data formats. > - NSLPs defining parameters and cross-referencing if one=20 > re-uses a parameter of another. >=20 > The first would be the cleaner approach, but it creates a=20 > lot of ongoing maintenance acitivty. The latter better suits=20 > to WG's of limited lifetime. It however requires some=20 > mechanism to prevent repeated specification of the same=20 > feature. If a simple an reliable mechanism to prevent this=20 > can be designed, I'd tend to the second approach.=20 The 2nd approach doesn't sound very different from how Diameter was designed, with multiple application support. Would that be a good analogy, or were you thinking of something different? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 29 06:23:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18518 for ; Thu, 29 Apr 2004 06:23:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8cN-0002DL-Cc for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 06:18:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TAIBgQ008496 for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 06:18:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8ZK-0000hx-38; Thu, 29 Apr 2004 06:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8Xh-0000B5-CD for nsis@optimus.ietf.org; Thu, 29 Apr 2004 06:13:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17767 for ; Thu, 29 Apr 2004 06:13:13 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ8XY-0001Ru-KB for nsis@ietf.org; Thu, 29 Apr 2004 06:13:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ8WO-00018G-00 for nsis@ietf.org; Thu, 29 Apr 2004 06:12:01 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BJ8VL-0000rd-00 for nsis@ietf.org; Thu, 29 Apr 2004 06:10:55 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TAAuG22997; Thu, 29 Apr 2004 13:10:56 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 13:10:44 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3TAAiNH018985; Thu, 29 Apr 2004 13:10:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00INDrxE; Thu, 29 Apr 2004 13:10:42 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TAAeH17412; Thu, 29 Apr 2004 13:10:40 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 13:09:57 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] common signalling application functions (was RE: Tentative Interi m Meeting schedule) Date: Thu, 29 Apr 2004 13:09:58 +0300 Message-ID: Thread-Topic: [NSIS] common signalling application functions (was RE: Tentative Interi m Meeting schedule) Thread-Index: AcQtzqD8fnwla11zTIKIqizKd2s5ZgAACFzAAADIgWA= To: , Cc: X-OriginalArrivalTime: 29 Apr 2004 10:09:58.0058 (UTC) FILETIME=[203EB8A0:01C42DD2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Robert, > The 2nd approach doesn't sound very different from how Diameter > was designed, with multiple application support. Would that > be a good analogy, or were you thinking of something different? R=FCdiger's mail arrived first, so I didn't see your mail where you suggested it was Diameter-like ... Anyhow, I support your suggestion. Dave, would this address your concerns at all? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 29 06:26:38 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18689 for ; Thu, 29 Apr 2004 06:26:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8g8-000335-C8 for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 06:22:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TAM47g011712 for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 06:22:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8aL-0001OT-NZ; Thu, 29 Apr 2004 06:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8YX-0000SG-4x for nsis@optimus.ietf.org; Thu, 29 Apr 2004 06:14:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17933 for ; Thu, 29 Apr 2004 06:14:05 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ8YO-0001go-CM for nsis@ietf.org; Thu, 29 Apr 2004 06:14:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ8XN-0001M8-00 for nsis@ietf.org; Thu, 29 Apr 2004 06:13:01 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BJ8Vk-0000yJ-00 for nsis@ietf.org; Thu, 29 Apr 2004 06:11:20 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TABKG23498; Thu, 29 Apr 2004 13:11:20 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 13:11:03 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3TAB3Nx019655; Thu, 29 Apr 2004 13:11:03 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00XKfxA6; Thu, 29 Apr 2004 13:11:01 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TAAoH17614; Thu, 29 Apr 2004 13:10:50 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 13:10:48 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 13:10:48 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] FW: draft-ietf-nsis-signalling-analysis-03.txt Date: Thu, 29 Apr 2004 13:10:49 +0300 Message-ID: Thread-Topic: [NSIS] FW: draft-ietf-nsis-signalling-analysis-03.txt Thread-Index: AcQsVpr1Ye++kpWBTsS/a7OXzMm89ABe49kg To: , Cc: , X-OriginalArrivalTime: 29 Apr 2004 10:10:48.0372 (UTC) FILETIME=[3E3C0740:01C42DD2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Jukka, > It seems no one has had problems with the proposed change,=20 > neither do I=20 > have issues with it - it looks good to me.=20 >=20 > In addition to that change, Allison commented about Section 3 that=20 > suggested too heavily to use TCP with RSVP. I think Section 3=20 > has good=20 > information, but could be edited a bit in the "message it=20 > tries to give". >=20 > In order to get this item finalized once and for all, I propose the=20 > following: >=20 > 1. Make the change of text as suggested by Adrian in this email >=20 > 2. Change Section 3 as follows (by removing text that=20 > suggests to use TCP=20 > with RSVP, this is an analysis draft, not a new spec): >=20 > a) Remove first sentece of last paragraph in Sec 3.1,=20 > starting with "In=20 > summary, in trying to introduce..." >=20 > b) Remove last sentence/paragraph of Sec 3.3 >=20 > c) Remove last paragraph of Sec 3.5 >=20 > 3. Make minor edits, e.g. check the references >=20 > I could do these changes as soon as I get an "OK" from the WG, and = submit=20 > the draft. Would we need a new WG Last Call? I support your proposal. I think we can send it directly to the AD for=20 AD review. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Apr 29 13:49:04 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16422 for ; Thu, 29 Apr 2004 13:49:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFYq-0003Ma-LT for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 13:43:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3THh0tq012916 for nsis-archive@odin.ietf.org; Thu, 29 Apr 2004 13:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFFe-00071A-Cz; Thu, 29 Apr 2004 13:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJEqj-0001sx-QU for nsis@optimus.ietf.org; Thu, 29 Apr 2004 12:57:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13744 for ; Thu, 29 Apr 2004 12:57:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJEqe-0000BI-OK for nsis@ietf.org; Thu, 29 Apr 2004 12:57:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEpn-0007j2-00 for nsis@ietf.org; Thu, 29 Apr 2004 12:56:27 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJEpR-0007T6-00 for nsis@ietf.org; Thu, 29 Apr 2004 12:56:05 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2004 09:08:57 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TGtZW9028086; Thu, 29 Apr 2004 09:55:36 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AON36030; Thu, 29 Apr 2004 09:55:32 -0700 (PDT) Date: Thu, 29 Apr 2004 12:55:31 -0400 From: David Oran To: john.loughney@nokia.com, Ruediger.Geib@t-systems.com, robert.hancock@roke.co.uk cc: nsis@ietf.org Subject: RE: [NSIS] common signalling application functions (was RE: Tentative Interi m Meeting schedule) Message-ID: <7AF5E12E40F7EC3FCC973D94@[10.32.245.156]> In-Reply-To: References: X-Mailer: Mulberry/3.1.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable --On Thursday, April 29, 2004 1:09 PM +0300 john.loughney@nokia.com wrote: > Robert, > >> The 2nd approach doesn't sound very different from how Diameter >> was designed, with multiple application support. Would that >> be a good analogy, or were you thinking of something different? > > R=FCdiger's mail arrived first, so I didn't see your mail where > you suggested it was Diameter-like ... > > Anyhow, I support your suggestion. Dave, would this address your > concerns at all? > It solves the pragmatic problems of encoding and abstract syntax, but by=20 itself does not ensure that the design of the common functions is in fact=20 carefully done with the goal of generality and extensibility across NLSPs. So, this is progress, yes. Many of these common functions have impact similar to designing an NLSP=20 itself. It would be good if we could tackle them directly with people=20 identified to do the work and ensure it meets the needs of the NLSPs we=20 know about and that the specification is clean clear, and all that other=20 good stuff. I think we still need further discussion of the related problem of ordering = among NLSPs so that things like NAT translations and QoS flow classifiers=20 work together and don't need multiple RTTs to establish state. Dave. > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 30 03:20:19 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00412 for ; Fri, 30 Apr 2004 03:20:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJSFh-00089r-08 for nsis-archive@odin.ietf.org; Fri, 30 Apr 2004 03:16:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U7G4cJ031330 for nsis-archive@odin.ietf.org; Fri, 30 Apr 2004 03:16:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJSAn-0007SH-SD; Fri, 30 Apr 2004 03:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJS8e-00074u-OQ for nsis@optimus.ietf.org; Fri, 30 Apr 2004 03:08:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29997 for ; Fri, 30 Apr 2004 03:08:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJS8X-0003qG-DX for nsis@ietf.org; Fri, 30 Apr 2004 03:08:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJS7a-0003jo-00 for nsis@ietf.org; Fri, 30 Apr 2004 03:07:43 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BJS6d-0003dJ-00 for nsis@ietf.org; Fri, 30 Apr 2004 03:06:43 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 30 Apr 2004 10:06:46 +0300 Date: Fri, 30 Apr 2004 10:06:46 +0300 (EEST) From: Jukka MJ Manner To: Xiaoming Fu , nsis@ietf.org cc: kireeti@juniper.net, adrian@olddog.co.uk Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] Analysis draft almost done Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, I have pretty much done all edits for a (final?) version of the Analysis draft. One thing that I came up was that while going through the list of references, two clear groups of references were not used currently. I wonder if anyone could tell me whether some critical information will be missing if the references are removed. The question is about multicast and optical UNI networking. If some, or all, of these references are needed, where should they be mentioned, or would there be a need for another paragraph, or two? The unused references are: - Multicast: [Fu02] X. Fu, et al, "Analysis on RSVP Regarding Multicast". Internet Draft, Work in Progress, October 2002 (draft-fu-rsvp-multicast- analysis-01.txt). [RFC2362] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, and V. Jacobson, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June, 1998. [RN98] B. Rajagopalan and R. Nair. "Multicast Routing with Resource Reservation". Journal of High Speed Networks, 7(2), pp. 113-139, July 1998. - Optical networking: [OIF-UNI-1.0] Optical Internetworking Forum (OIF) Implementation Agreement OIF-UNI-01.0, User Network Interface (UNI) 1.0 Signaling Specification, Oct. 2001. [RFC3476] B. Rajagopalan, "Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP- TE) Extensions for Optical UNI Signaling", RFC 3476, March 2003. I hope to get feedback soon on this issue, so that I can finalize the draft and submit it. If I don't get feedback within a few days, I will just remove all of those references. Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 30 03:41:31 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01000 for ; Fri, 30 Apr 2004 03:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJSbS-0002y0-Rg for nsis-archive@odin.ietf.org; Fri, 30 Apr 2004 03:38:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U7cY3O011389 for nsis-archive@odin.ietf.org; Fri, 30 Apr 2004 03:38:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJSX3-000252-8s; Fri, 30 Apr 2004 03:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJSTv-0001eI-W1 for nsis@optimus.ietf.org; Fri, 30 Apr 2004 03:30:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00698 for ; Fri, 30 Apr 2004 03:30:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJSTq-0006EM-7U for nsis@ietf.org; Fri, 30 Apr 2004 03:30:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJSSt-00068J-00 for nsis@ietf.org; Fri, 30 Apr 2004 03:29:43 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BJSSA-00062V-00 for nsis@ietf.org; Fri, 30 Apr 2004 03:28:58 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 30 Apr 2004 10:28:59 +0300 Date: Fri, 30 Apr 2004 10:28:58 +0300 (EEST) From: Jukka MJ Manner To: adrian@olddog.co.uk cc: Xiaoming Fu , kireeti@juniper.net, nsis@ietf.org In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] Re: Analysis draft almost done Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 Thanks. Actually, [OIF-UNI-1.0] was mentioned in the old text, but RFC3476 was not used anywhere. I just wanted to make sure I don't remove anything usefull. Regards, Jukka On Fri, 30 Apr 2004, Adrian Farrel wrote: > Jukka, > > > - Optical networking: > > > > [OIF-UNI-1.0] Optical Internetworking Forum (OIF) Implementation > > Agreement OIF-UNI-01.0, User Network Interface (UNI) 1.0 Signaling > > Specification, Oct. 2001. > > > > [RFC3476] B. Rajagopalan, "Documentation of IANA Assignments for > > Label Distribution Protocol (LDP), Resource ReSerVation Protocol > > (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP- > > TE) Extensions for Optical UNI Signaling", RFC 3476, March 2003. > > My mistake. > I should have removed these when doing the GMPLS edits. > You can strike them. > > Thanks, > Adrian > > PS I assume that if I copied NSIS it would bounce > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Apr 30 10:59:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06014 for ; Fri, 30 Apr 2004 10:59:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZHp-0002vy-Cd for nsis-archive@odin.ietf.org; Fri, 30 Apr 2004 10:46:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UEkjqB011278 for nsis-archive@odin.ietf.org; Fri, 30 Apr 2004 10:46:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZ9N-000192-9n; Fri, 30 Apr 2004 10:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYzi-0008BQ-Ok for nsis@optimus.ietf.org; Fri, 30 Apr 2004 10:28:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04469 for ; Fri, 30 Apr 2004 10:27:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYzg-0005KZ-CL for nsis@ietf.org; Fri, 30 Apr 2004 10:28:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYyh-0005Ia-00 for nsis@ietf.org; Fri, 30 Apr 2004 10:27:00 -0400 Received: from smail3.alcatel.fr ([62.23.212.56]) by ietf-mx with esmtp (Exim 4.12) id 1BJYxj-0005FU-00 for nsis@ietf.org; Fri, 30 Apr 2004 10:25:59 -0400 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i3UEOILD015478; Fri, 30 Apr 2004 16:24:18 +0200 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004043016241658:4445 ; Fri, 30 Apr 2004 16:24:16 +0200 Message-ID: <40926190.7080007@alcatel.fr> Date: Fri, 30 Apr 2004 16:24:16 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: David Oran Cc: john.loughney@nokia.com, Ruediger.Geib@t-systems.com, robert.hancock@roke.co.uk, nsis@ietf.org, Tschofenig Hannes Subject: Re: [NSIS] common signalling application functions (was RE: Tentative Interi m Meeting schedule) References: <7AF5E12E40F7EC3FCC973D94@[10.32.245.156]> In-Reply-To: <7AF5E12E40F7EC3FCC973D94@[10.32.245.156]> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/30/2004 16:24:16, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/30/2004 16:24:18 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable dear all, I participated into the design of the AAA in the QoS-NSLP together with hannes. I tend to agree that this should fall into the so-called 'common sig app functions' block. moreover when examinating the dave's list of targetted applications, we could even narrow the scope of such a common block to AAA (at large... let's say 'policy'). concerning the design alternative (r=FCdiger mentions 'toolbox' vs. cross-ref between NSLPs), IMO the first one should lead to a cleaner design and avoid doing twice the same thing. I have finally a couple of comments/questions: 1) did you consider integrating such a generic 'toolbox' into GIMPS ? or maybe the WG wants GIMPS to keep strictly relating to transport ? I would suggest to copy the RSVP design here: a generic POLICY=5FDATA TLV in GIMPS, which contains a list of Policy Element (PE) objects. those PEs would be designed separately and I'm pretty sure a couple of already RFCed PEs could even be re-used as is. 2) does the working group think that the design of such generic objects will come together with some kind of framework ? authz protocols ? requirements ? thanks, yacine David Oran wrote: > --On Thursday, April 29, 2004 1:09 PM +0300 john.loughney@nokia.com > wrote: >=20 >> Robert, >>=20 >>> The 2nd approach doesn't sound very different from how Diameter=20 >>> was designed, with multiple application support. Would that be a >>> good analogy, or were you thinking of something different? >>=20 >>=20 >> R=FCdiger's mail arrived first, so I didn't see your mail where you >> suggested it was Diameter-like ... >>=20 >> Anyhow, I support your suggestion. Dave, would this address your=20 >> concerns at all? >>=20 > It solves the pragmatic problems of encoding and abstract syntax, but > by itself does not ensure that the design of the common functions is > in fact carefully done with the goal of generality and extensibility > across NLSPs. >=20 > So, this is progress, yes. >=20 > Many of these common functions have impact similar to designing an > NLSP itself. It would be good if we could tackle them directly with > people identified to do the work and ensure it meets the needs of the > NLSPs we know about and that the specification is clean clear, and > all that other good stuff. >=20 > I think we still need further discussion of the related problem of=20 > ordering among NLSPs so that things like NAT translations and QoS > flow classifiers work together and don't need multiple RTTs to > establish state. >=20 > Dave. >=20 >=20 >> John >>=20 >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F nsis = mailing list=20 >> nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 >=20 >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F nsis = mailing list=20 > nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis